[gentoo-dev] last-rite: dev-java/objenesis-test
# Volkmar W. Pogatzki (2022-10-10) # Unused Java library. Removal on 2022-11-10. dev-java/objenesis-test
[gentoo-dev] last-rite: dev-java/byte-buddy-agent
# Volkmar W. Pogatzki (2022-08-22) # Java library without consumers. Removal on 2022-09-22 dev-java/byte-buddy-agent
[gentoo-dev] last-rite: dev-java/airline
# Volkmar W. Pogatzki (2022-02-09) # No longer maintained upstream. # Upstream recommends Airline 2 or Picocli as a replacement. # https://github.com/airlift/airline/#warning-deprecated-warning # Removal in 30 days. dev-java/airline
[gentoo-dev] last-rite: dev-java/jsr223 & java-virtuals/script-api
# Volkmar W. Pogatzki (2022-01-27) # Java-library + java-virtual with no consumers. # Removal in 30 days. java-virtuals/script-api dev-java/jsr223
[gentoo-dev] some java last-rites
# Volkmar W. Pogatzki (2022-01-15) # Java-packages with no consumers and depending on virtual/{jdk,jre}-1.6 # Removal in 30 days. app-emulation/edumips64 dev-java/appframework dev-java/commons-jexl dev-java/cssparser dev-java/felix-bundlerepository dev-java/glassfish-servlet-api dev-java/jacoco dev-java/jargs dev-java/junitperf dev-java/kunststoff dev-java/saxpath dev-java/sun-jaf dev-java/tijmp dev-java/tomcat-jstl-impl dev-java/touchgraph-graphlayout dev-java/trove dev-java/unkrig-nullanalysis dev-java/xmldb dev-util/appinventor dev-util/scala-ide sci-astronomy/healpix
[gentoo-dev] [PATCH] eclass/webapps.eclass: added eapi8 support
Signed-off-by: Miroslav Šulc --- eclass/webapp.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/webapp.eclass b/eclass/webapp.eclass index 5ef7dbce03cf..7bdf28430b48 100644 --- a/eclass/webapp.eclass +++ b/eclass/webapp.eclass @@ -4,14 +4,14 @@ # @ECLASS: webapp.eclass # @MAINTAINER: # web-a...@gentoo.org -# @SUPPORTED_EAPIS: 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 8 # @BLURB: functions for installing applications to run under a web server # @DESCRIPTION: # The webapp eclass contains functions to handle web applications with # webapp-config. Part of the implementation of GLEP #11 case ${EAPI:-0} in - [567]) ;; + [5678]) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac @@ -24,7 +24,7 @@ _WEBAPP_ECLASS=1 # @DESCRIPTION: # An ebuild should use WEBAPP_DEPEND if a custom DEPEND needs to be built, most # notably in combination with WEBAPP_OPTIONAL. -WEBAPP_DEPEND=">=app-admin/webapp-config-1.50.15" +WEBAPP_DEPEND="app-admin/webapp-config" # @ECLASS-VARIABLE: WEBAPP_NO_AUTO_INSTALL # @PRE_INHERIT -- 2.34.1
[gentoo-dev] [PATCH] eclass/java-ant-2.eclass: added eapi8 support
Signed-off-by: Miroslav Šulc --- eclass/java-ant-2.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/java-ant-2.eclass b/eclass/java-ant-2.eclass index 501d17ef229e..438b0dbb5001 100644 --- a/eclass/java-ant-2.eclass +++ b/eclass/java-ant-2.eclass @@ -7,7 +7,7 @@ # @AUTHOR: # kiorky # Petteri Räty -# @SUPPORTED_EAPIS: 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 8 # @PROVIDES: java-utils-2 # @BLURB: eclass for ant based Java packages # @DESCRIPTION: @@ -18,7 +18,7 @@ inherit java-utils-2 multilib case ${EAPI:-0} in - [567]) ;; + [5678]) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac @@ -73,7 +73,7 @@ fi # constructed above. JAVA_ANT_E_DEPEND="${JAVA_ANT_E_DEPEND} ${ANT_TASKS_DEPEND} - >=dev-java/javatoolkit-0.3.0-r2" + dev-java/javatoolkit" # this eclass must be inherited after java-pkg-2 or java-pkg-opt-2 # if it's java-pkg-opt-2, ant dependencies are pulled based on USE flag -- 2.34.1
[gentoo-dev] [PATCH] eclass/java-osgi.eclass: added eapi8 support
Signed-off-by: Miroslav Šulc --- eclass/java-osgi.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/java-osgi.eclass b/eclass/java-osgi.eclass index 74c7c1a07f5c..f2f55772e873 100644 --- a/eclass/java-osgi.eclass +++ b/eclass/java-osgi.eclass @@ -6,7 +6,7 @@ # j...@gentoo.org # @AUTHOR: # Java maintainers -# @SUPPORTED_EAPIS: 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 8 # @PROVIDES: java-utils-2 # @BLURB: Java OSGi eclass # @DESCRIPTION: @@ -16,7 +16,7 @@ # could extend this so that Gentoo Java system would be fully OSGi compliant. case ${EAPI:-0} in - [567]) ;; + [5678]) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac -- 2.34.1
[gentoo-dev] [PATCH] eclass/java-pkg-opt-2.eclass: added eapi8 support
Signed-off-by: Miroslav Šulc --- eclass/java-pkg-opt-2.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/java-pkg-opt-2.eclass b/eclass/java-pkg-opt-2.eclass index 79833c98ea6b..92f2cb53145d 100644 --- a/eclass/java-pkg-opt-2.eclass +++ b/eclass/java-pkg-opt-2.eclass @@ -6,7 +6,7 @@ # j...@gentoo.org # @AUTHOR: # Thomas Matthijs -# @SUPPORTED_EAPIS: 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 8 # @PROVIDES: java-utils-2 # @BLURB: Eclass for package with optional Java support # @DESCRIPTION: @@ -14,7 +14,7 @@ # support. case ${EAPI:-0} in - [567]) ;; + [5678]) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac -- 2.34.1
[gentoo-dev] [PATCH] eclass/java-virtuals-2.eclass: added eapi8 support
Signed-off-by: Miroslav Šulc --- eclass/java-virtuals-2.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/java-virtuals-2.eclass b/eclass/java-virtuals-2.eclass index dedbf2f26195..e929a7e1ceeb 100644 --- a/eclass/java-virtuals-2.eclass +++ b/eclass/java-virtuals-2.eclass @@ -6,14 +6,14 @@ # j...@gentoo.org # @AUTHOR: # Original Author: Alistair John Bush -# @SUPPORTED_EAPIS: 5 6 +# @SUPPORTED_EAPIS: 5 6 8 # @BLURB: Java virtuals eclass # @DESCRIPTION: # To provide a default (and only) src_install function for ebuilds in the # java-virtuals category. case ${EAPI:-0} in - [56]) ;; + [568]) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac @@ -22,7 +22,7 @@ _JAVA_VIRTUALS_2_ECLASS=1 inherit java-utils-2 -DEPEND=">=dev-java/java-config-2.2.0-r3" +DEPEND="dev-java/java-config" RDEPEND="${DEPEND}" S="${WORKDIR}" -- 2.34.1
[gentoo-dev] last-rite: some dev-java/*
# Volkmar W. Pogatzki (2021-11-28) # Libraries without consumers. Removal in 30 days. dev-java/commons-pool dev-java/dict4j dev-java/felix-gogo-command dev-java/jama dev-java/janino dev-java/jchardet dev-java/jcommon dev-java/jdynamite dev-java/jfreesvg dev-java/jgrapht dev-java/jmdns dev-java/jsr225 dev-java/jsr311-api dev-java/jsr322 dev-java/jung dev-java/mojarra dev-java/neuroph dev-java/ognl dev-java/piccolo dev-java/portletapi dev-java/vldocking dev-java/ws-commons-util dev-java/xml-security dev-java/xmpcore
[gentoo-dev] last-rite: dev-java/jss
# Volkmar W. Pogatzki (2021-11-26) # Library without consumers. Removal in 30 days. dev-java/jss
[gentoo-dev] [PATCH 1/1] eclass/java-{utils-2,pkg-2,pkg-simple}: bump to eapi8
Signed-off-by: Miroslav Šulc --- eclass/java-pkg-2.eclass | 4 ++-- eclass/java-pkg-simple.eclass | 4 ++-- eclass/java-utils-2.eclass| 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/eclass/java-pkg-2.eclass b/eclass/java-pkg-2.eclass index b0573eea4d0b..764aa95ba373 100644 --- a/eclass/java-pkg-2.eclass +++ b/eclass/java-pkg-2.eclass @@ -6,7 +6,7 @@ # j...@gentoo.org # @AUTHOR: # Thomas Matthijs -# @SUPPORTED_EAPIS: 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 8 # @PROVIDES: java-utils-2 # @BLURB: Eclass for Java Packages # @DESCRIPTION: @@ -14,7 +14,7 @@ # need to use Java. case ${EAPI:-0} in - [567]) ;; + [5678]) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass index fc006ff2fcc4..26dc06b1a6fa 100644 --- a/eclass/java-pkg-simple.eclass +++ b/eclass/java-pkg-simple.eclass @@ -6,7 +6,7 @@ # j...@gentoo.org # @AUTHOR: # Java maintainers -# @SUPPORTED_EAPIS: 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 8 # @BLURB: Eclass for packaging Java software with ease. # @DESCRIPTION: # This class is intended to build pure Java packages from Java sources @@ -17,7 +17,7 @@ # directory before calling the src_compile function of this eclass. case ${EAPI:-0} in - [567]) ;; + [5678]) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass index 2c93cbdf0eeb..050a5c4847a6 100644 --- a/eclass/java-utils-2.eclass +++ b/eclass/java-utils-2.eclass @@ -6,7 +6,7 @@ # j...@gentoo.org # @AUTHOR: # Thomas Matthijs , Karl Trygve Kalleberg -# @SUPPORTED_EAPIS: 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 8 # @BLURB: Base eclass for Java packages # @DESCRIPTION: # This eclass provides functionality which is used by java-pkg-2.eclass, @@ -18,7 +18,7 @@ # Ant-based packages. case ${EAPI:-0} in - [567]) ;; + [5678]) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac -- 2.34.1
[gentoo-dev] [PATCH 0/1] support for eapi8 in java-pkg-simple.eclass and the eclasses in the chain
hi devs, here is a part eapi8 support for java, in this case java-pkg-simple.eclas and all the eclasses in the chain. i will continue on the other eclasses once this gets merged. i did test these eclasses on several java packages and all seems fine. any comments or improvements are welcome. fordfrog Miroslav Šulc (1): eclass/java-{utils-2,pkg-2,pkg-simple}: bump to eapi8 eclass/java-pkg-2.eclass | 4 ++-- eclass/java-pkg-simple.eclass | 4 ++-- eclass/java-utils-2.eclass| 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) -- 2.34.1
[gentoo-dev] rfc: java-vm-2.eclass eapi 8 support
hello devs, please find attached patch for upgrade of java-vm-2.eclass to support eapi 8. eapi 5 is not used by any package inheriting this eclass so i dropped it. i also attach update of the ebuilds of packages that use this eclass and can be updated to eapi 8 (dev-java/icedtea can't atm, it also inherits another java eclass that does not support eapi 8 yet, and dev-java/gcj-jdk is masked in profiles/releases/17.0/package.mask). all works fine except dev-java/openjdk (all slots) where the configuration phase fails or does not finish correctly. all those packages merge fine with eapi 6 (in-tree ebuilds). openjdk:8 - configuration finishes but no configuration file is created (and hence compilation fails) as during the configuration phase it complains with this: configure: error: Could not find freetype! openjdk:11 and openjdk:17 - configuration fails with this error (i was told by sam it is a known bug): configure: error: unrecognized options: --disable-static i'd like to merge the patches asap (except the broken openjdk) so please let me know if you find anything that could be improved or all's ok. thanks fordfrog diff --git a/eclass/java-vm-2.eclass b/eclass/java-vm-2.eclass index 5f14493f18a1..d24339200ce0 100644 --- a/eclass/java-vm-2.eclass +++ b/eclass/java-vm-2.eclass @@ -4,14 +4,14 @@ # @ECLASS: java-vm-2.eclass # @MAINTAINER: # j...@gentoo.org -# @SUPPORTED_EAPIS: 5 6 +# @SUPPORTED_EAPIS: 6 8 # @BLURB: Java Virtual Machine eclass # @DESCRIPTION: # This eclass provides functionality which assists with installing # virtual machines, and ensures that they are recognized by java-config. case ${EAPI:-0} in - 5|6) ;; + [68]) ;; *) die "EAPI=${EAPI} is not supported" ;; esac @@ -20,8 +20,9 @@ inherit multilib pax-utils prefix xdg-utils EXPORT_FUNCTIONS pkg_setup pkg_postinst pkg_prerm pkg_postrm RDEPEND=" - >=dev-java/java-config-2.2.0-r3 - >=app-eselect/eselect-java-0.4.0" + dev-java/java-config + app-eselect/eselect-java +" DEPEND="${RDEPEND}" export WANT_JAVA_CONFIG=2 diff --git a/dev-java/icedtea-bin/icedtea-bin-3.16.0-r1.ebuild b/dev-java/icedtea-bin/icedtea-bin-3.16.0-r1.ebuild new file mode 100644 index ..79aca0a922b8 --- /dev/null +++ b/dev-java/icedtea-bin/icedtea-bin-3.16.0-r1.ebuild @@ -0,0 +1,132 @@ +# Copyright 1999-2020 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=8 + +inherit java-vm-2 toolchain-funcs + +abi_uri() { + echo "${2-$1}? ( + ${BASE_URI}/${PN}-core-${PV}${3+-r${3}}-${1}.tar.xz + examples? ( ${BASE_URI}/${PN}-examples-${PV}${3+-r${3}}-${1}.tar.xz ) + )" +} + +BASE_URI="https://dev.gentoo.org/~gyakovlev/distfiles"; +SRC_URI=" + doc? ( ${BASE_URI}/${PN}-doc-${PV}.tar.xz ) + source? ( ${BASE_URI}/${PN}-src-${PV}.tar.xz ) + big-endian? ( $(abi_uri ppc64) ) + !big-endian? ( $(abi_uri ppc64le ppc64) ) + $(abi_uri amd64) + $(abi_uri arm) + $(abi_uri arm64) + $(abi_uri x86) +" + +DESCRIPTION="A Gentoo-made binary build of the IcedTea JDK" +HOMEPAGE="http://icedtea.classpath.org"; + +LICENSE="GPL-2-with-classpath-exception" +SLOT="8" +KEYWORDS="-* ~amd64 ~arm ~arm64 ~ppc64 ~x86" +IUSE="+alsa big-endian cups doc examples +gtk headless-awt pulseaudio selinux source" + +REQUIRED_USE="gtk? ( !headless-awt )" + +RESTRICT="preserve-libs strip" +QA_PREBUILT="opt/.*" + +DEPEND="app-arch/xz-utils" + +RDEPEND=" + >=dev-libs/glib-2.60.7:2 + >=media-libs/fontconfig-2.13:1.0 + >=media-libs/freetype-2.9.1:2 + >=media-libs/lcms-2.9:2 + >=sys-apps/baselayout-java-0.1.0-r1 + >=sys-libs/zlib-1.2.11-r2 + virtual/jpeg-compat:62 + alsa? ( >=media-libs/alsa-lib-1.2 ) + cups? ( >=net-print/cups-2.0 ) + gtk? ( + >=dev-libs/atk-2.32.0 + >=x11-libs/cairo-1.16.0 + x11-libs/gdk-pixbuf:2 + >=x11-libs/gtk+-2.24:2 + >=x11-libs/pango-1.42 + ) + selinux? ( sec-policy/selinux-java ) + virtual/ttf-fonts + !headless-awt? ( + media-libs/giflib:0/7 + =media-libs/libpng-1.6* + >=x11-libs/libX11-1.6 + >=x11-libs/libXcomposite-0.4 + >=x11-libs/libXext-1.3 + >=x11-libs/libXi-1.7 + >=x11-libs/libXrender-0.9.10 + >=x11-libs/libXtst-1.2 + ) +" + +PDEPEND="pulseaudio? ( dev-java/icedtea-sound )" + +S="${WORKDIR}" + +pkg_pretend() { + if [[ "$(tc-is-softfloat)" != "no" ]]; then + die "These binaries require a hardfloat system." + fi +} + +src_prepare() { + default + + # I wouldn't normally use -f below but symlinks in the arm files + # make this fail otherwise and any other approach would be tedious. + + if ! use alsa; then + rm -fv */jre/lib/*/libjsoundalsa.* || die + fi + + if use headless-awt; then + rm -fvr */jre/lib/*/lib*{[jx]awt,splashscreen}* \ + */{,jre/}bin/policytool */bin/appletviewer || die + fi +} + +src_install() { + local dest="/opt/${P}" + local ddest="${ED}/${dest#/}" + dodir "${dest}" + + dodoc ${P}-${ABI}/doc/{ASSEMBLY_EXCEPTION,AUTHORS,NEWS,README,THIRD_PARTY_README} + use doc && dodoc -r ${P}/doc/html + + # doins doesn't preserve executable bits. + cp -pRP ${P}-${ABI}/{bin,include,jre
[gentoo-dev] last-rite: dev-java/milton{,-mail}-api
# Volkmar W. Pogatzki (2021-11-14) # java packages without consumers, Removal in 30 days. dev-java/milton-mail-api dev-java/milton-api
[gentoo-dev] last-rite: dev-java/trident, dev-java/okio & dev-java/moshi
# Volkmar W. Pogatzki (2021-11-12) # Libraries with no other consumers. Removal in 30 days. dev-java/trident dev-java/okio dev-java/moshi
[gentoo-dev] last rite: dev-java/mina-core, dev-java/jnr-unixsocket & dev-java/jnr-enxio
# Volkmar W. Pogatzki (2021-11-06) # Libraries with no other consumers. Removal in 30 days. dev-java/mina-core dev-java/jnr-unixsocket dev-java/jnr-enxio
[gentoo-dev] last rite: dev-java/jamon & java-virtuals/interceptor-api
# Volkmar W. Pogatzki (2021-11-01) # Unused library and virtual, removal on 2021-12-01 dev-java/jamon java-virtuals/interceptor-api
[gentoo-dev] last-rite: dev-java/jgoodies-{animation,binding,forms}
# Miroslav Šulc (2021-07-30) # these libs have no consumers, removal in 30 days # see bug: https://bugs.gentoo.org/805152 dev-java/jgoodies-animation dev-java/jgoodies-binding dev-java/jgoodies-forms
[gentoo-dev] last-rite: dev-java/bctsp
# Volkmar W. Pogatzki (2021-06-21) # library with no consumer, removal in 30 days # see https://bugs.gentoo.org/794562 dev-java/bctsp
[gentoo-dev] [rfc] java-pkg-simple.eclass patch to add java modules support
hi guys, here is a patch that should provide initial support for module-info.java in java packages. more info can be found here: https://bugs.gentoo.org/796875 i'd mainly appreciate comments on the style of the patch whether it's ok or what should be improved, though any questions or suggestions related to the specific java issues are welcome too. thanks. fordfrog diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass index 0c3e1af70364..408e1aac44f6 100644 --- a/eclass/java-pkg-simple.eclass +++ b/eclass/java-pkg-simple.eclass @@ -326,7 +326,7 @@ java-pkg-simple_prepend_resources() { # If USE FLAG 'binary' exists and is set, it will just copy # ${JAVA_BINJAR_FILENAME} to ${S} and skip the rest of src_compile. java-pkg-simple_src_compile() { - local sources=sources.lst classes=target/classes apidoc=target/api + local sources=sources.lst classes=target/classes apidoc=target/api moduleinfo # auto generate classpath java-pkg_gen-cp JAVA_GENTOO_CLASSPATH @@ -344,7 +344,14 @@ java-pkg-simple_src_compile() { fi # gather sources - find "${JAVA_SRC_DIR[@]}" -name \*.java > ${sources} + # if target < 9, we need to compile module-info.java separately + # as this feature is not supported before Java 9 + if [[ java-pkg_get-target -lt 9 ]]; then + find "${JAVA_SRC_DIR[@]}" -name \*.java ! -name module-info.java > ${sources} + moduleinfo=$(find "${JAVA_SRC_DIR[@]}" -name module-info.java) + else + find "${JAVA_SRC_DIR[@]}" -name \*.java > ${sources} + fi # create the target directory mkdir -p ${classes} || die "Could not create target directory" @@ -358,6 +365,23 @@ java-pkg-simple_src_compile() { ${classpath:+-classpath ${classpath}} ${JAVAC_ARGS}\ @${sources} + # handle module-info.java separately as it needs at least JDK 9 + if [[ -n ${moduleinfo} ]]; then + if java-pkg_is-vm-version-ge "9" ; then + local tmp_source=${JAVA_PKG_WANT_SOURCE} tmp_target=${JAVA_PKG_WANT_TARGET} + + JAVA_PKG_WANT_SOURCE="9" + JAVA_PKG_WANT_TARGET="9" + ejavac -d ${classes} -encoding ${JAVA_ENCODING} ${JAVAC_ARGS} "${moduleinfo}" + + JAVA_PKG_WANT_SOURCE=${tmp_source} + JAVA_PKG_WANT_TARGET=${tmp_target} + else + ewarn "Need at least JDK 9 to compile module-info.java in src_compile," + ewarn "see https://bugs.gentoo.org/796875"; + fi + fi + # javadoc if has doc ${JAVA_PKG_IUSE} && use doc; then mkdir -p ${apidoc} @@ -422,7 +446,7 @@ java-pkg-simple_src_install() { # It will perform test with frameworks that are defined in # ${JAVA_TESTING_FRAMEWORKS}. java-pkg-simple_src_test() { - local test_sources=test_sources.lst classes=target/test-classes + local test_sources=test_sources.lst classes=target/test-classes moduleinfo local tests_to_run classpath # do not continue if the USE FLAG 'test' is explicitly unset @@ -444,13 +468,38 @@ java-pkg-simple_src_test() { java-pkg-simple_prepend_resources ${classes} "${JAVA_TEST_RESOURCE_DIRS[@]}" # gathering sources for testing - find "${JAVA_TEST_SRC_DIR[@]}" -name \*.java > ${test_sources} + # if target < 9, we need to compile module-info.java separately + # as this feature is not supported before Java 9 + if [[ java-pkg_get-target -lt 9 ]]; then + find "${JAVA_TEST_SRC_DIR[@]}" -name \*.java ! -name module-info.java > ${test_sources} + moduleinfo=$(find "${JAVA_TEST_SRC_DIR[@]}" -name module-info.java) + else + find "${JAVA_TEST_SRC_DIR[@]}" -name \*.java > ${test_sources} + fi + # compile [[ -s ${test_sources} ]] && ejavac -d ${classes} ${JAVAC_ARGS} \ -encoding ${JAVA_ENCODING} ${classpath:+-classpath ${classpath}} \ @${test_sources} + # handle module-info.java separately as it needs at least JDK 9 + if [[ -n ${moduleinfo} ]]; then + if java-pkg_is-vm-version-ge "9" ; then + local tmp_source=${JAVA_PKG_WANT_SOURCE} tmp_target=${JAVA_PKG_WANT_TARGET} + + JAVA_PKG_WANT_SOURCE="9" + JAVA_PKG_WANT_TARGET="9" + ejavac -d ${classes} -encoding ${JAVA_ENCODING} ${JAVAC_ARGS} "${moduleinfo}" + + JAVA_PKG_WANT_SOURCE=${tmp_source} + JAVA_PKG_WANT_TARGET=${tmp_target} + else + ewarn "Need at least JDK 9 to compile module-info.java in src_test," + ewarn "see https://bugs.gentoo.org/796875"; + fi + fi + # grab a set of tests that testing framework will run tests_to_run=$(find "${classes}" -type f\ \( -name "*Test.class"\
[gentoo-dev] last-rite: some java packages
# Volkmar W. Pogatzki (2021-06-21) # libraries without consumers, removal in 30 days dev-java/bytelist dev-java/jcodings dev-java/joni dev-java/jvyamlb
[gentoo-dev] last-rite: xml-commons
# Miroslav Šulc (2021-06-23) # obsolete, no consumers # see bug: https://bugs.gentoo.org/797739 dev-java/xml-commons
[gentoo-dev] last-rite: some java packages
# Volkmar W. Pogatzki (2021-06-20) # no consumer, removal in 30 days # see bug: https://bugs.gentoo.org/796587 # and https://bugs.gentoo.org/561504 dev-java/annogen dev-java/xml-xmlbeans java-virtuals/stax-api dev-java/jsr173 dev-java/jibx-tools
[gentoo-dev] last-rite: dev-java/commons-validator
# Miroslav Šulc (2021-06-13) # no consumer, removal in 30 days # see bug: https://bugs.gentoo.org/785856 dev-java/commons-validator
[gentoo-dev] last-rite: app-editors/jext
# Miroslav Šulc (2021-05-24) # it's just a demo project, not a real app, see disclaimer # at https://github.com/romainguy/jext # removal in 30 days # also removing an obsolete package that has only this dependant # see bug: https://bugs.gentoo.org/791106 app-editors/jext dev-java/jgoodies-looks:1.2
[gentoo-dev] last-rite: dev-java/sun-jimi
# Miroslav Šulc (2021-05-20) # no non-masked consumer, removal in 30 days # see bug: https://bugs.gentoo.org/786852 dev-java/sun-jimi
[gentoo-dev] last-rite: dev-java/squareness-jlf
# Miroslav Šulc (2021-05-20) # no non-masked consumer, removal in 30 days # see bug: https://bugs.gentoo.org/786828 dev-java/squareness-jlf
[gentoo-dev] last-rite: dev-java/werken-xpath
# Miroslav Šulc (2021-05-19) # no consumer, removal in 30 days # see bug: https://bugs.gentoo.org/784065 dev-java/werken-xpath
[gentoo-dev] last-rite: dev-java/freemarker
# Miroslav Šulc (2021-05-16) # no consumer, does not compile, not with jdk-11 # and not even with openjdk:8 # see bug: https://bugs.gentoo.org/790551 dev-java/freemarker
[gentoo-dev] last-rite: dev-java/netty-common
# Miroslav Šulc (2012-05-15) # no consumer, removal in 30 days # see bug: https://bugs.gentoo.org/788364 dev-java/netty-common
Re: [gentoo-dev] last-rite: some java stuff
i'm sorry but this package is pretty old, i could not find a working homepage for it and we have no purpose for it. it would be better if copied to the science overlay. fordfrog Dne 07. 05. 21 v 1:50 Alessandro Barbieri napsal(a): # Miroslav Šulc mailto:fordf...@gentoo.org>> (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786783 <https://bugs.gentoo.org/786783> dev-java/skinlf It's needed for scilab[gui] from the science overlay. It may be worth keeping it or moving it to science
[gentoo-dev] last-rite: some java packages
# Miroslav Šulc (2021-05-05) # no consumers, dead homepage # removal in 30 days # see bug: https://bugs.gentoo.org/787329 app-misc/jitac # Miroslav Šulc (2021-05-05) # last release in 2009 # removal in 30 days # see bug: https://bugs.gentoo.org/787332 app-office/hourglass # Miroslav Šulc (2021-05-05) # no consumers, last release in 2005 # removal in 30 days # see bug: https://bugs.gentoo.org/787368 dev-util/jarwizard # Miroslav Šulc (2021-05-05) # no consumers, last release in 2008 # removal in 30 days # see bug: https://bugs.gentoo.org/787428 media-sound/entagged-tageditor # Miroslav Šulc (2021-05-05) # no consumers, last release in 2009 # removal in 30 days # see bug: https://bugs.gentoo.org/787434 media-sound/protux # Miroslav Šulc (2021-05-05) # no consumers, last release in 2013 # removal in 30 days # see bug: https://bugs.gentoo.org/787638 net-nds/jxplorer # Miroslav Šulc (2021-05-05) # no consumers, last release in 2011 # removal in 30 days # see bug: https://bugs.gentoo.org/787656 sci-physics/jaxodraw # Miroslav Šulc (2021-05-05) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/785400 dev-java/cldc-api
[gentoo-dev] last-rite: dev-java/tagsoup
# Miroslav Šulc (2021-04-30) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/787152 dev-java/tagsoup
[gentoo-dev] last-rite: some java stuff
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786888 dev-java/zeus-jscl # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786864 dev-java/sun-jmx java-virtuals/jmx dev-util/jconfig # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786843 dev-java/sun-httpserver-bin # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786840 dev-java/stax-ex dev-java/xmlstreambuffer # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786831 dev-java/stax2-api # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786756 dev-java/nekohtml dev-java/boilerpipe # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786786 dev-java/spymemcached # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786783 dev-java/skinlf # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786780 dev-java/sblim-cim-client # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786774 dev-java/radeox # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bugs: https://bugs.gentoo.org/786771 dev-java/prefuse # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786768 dev-java/picocontainer # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786753 dev-java/msv dev-java/relaxngcc dev-java/wstx dev-java/jettison # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786744 dev-java/minlog # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786714 dev-java/libmatthew-java # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786711 dev-java/ldapsdk
[gentoo-dev] last-rite: media-sound/bladeenc
# Miroslav Šulc (2021-04-28) # security issues, last release in 2004 # removal in 30 days # see bug: https://bugs.gentoo.org/631394 media-sound/bladeenc
[gentoo-dev] last-rite: dev-java/netty-{codec{,-http},handler}
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786522 dev-java/netty-codec dev-java/netty-codec-http dev-java/netty-handler
[gentoo-dev] last-rite: dev-java/jvmstat
# Miroslav Šulc (2021-04-28) # obsolete, use dev-util/visualvm # removal in 30 days # see bug: https://bugs.gentoo.org/786513 dev-java/jvmstat
[gentoo-dev] last-rite: dev-java/junrar
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786510 dev-java/junrar
[gentoo-dev] last-rite: dev-java/junit-addons
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786507 dev-java/junit-addons
[gentoo-dev] last-rite: dev-java/jstun
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786486 dev-java/jstun
[gentoo-dev] last-rite: dev-java/l2fprod-common & dev-java/jreleaseinfo
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786483 dev-java/l2fprod-common dev-java/jreleaseinfo
[gentoo-dev] last-rite: dev-java/jortho
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786480 dev-java/jortho
[gentoo-dev] last-rite: dev-java/jlibeps
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786441 dev-java/jlibeps
[gentoo-dev] last-rite: dev-java/jisp
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786438 dev-java/jisp
[gentoo-dev] last-rite: dev-java/jinput
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786435 dev-java/jinput
[gentoo-dev] last-rite: dev-java/jid3
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786432 dev-java/jid3
[gentoo-dev] last-rite: dev-java/jebl
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786426 dev-java/jebl
[gentoo-dev] last-rite: dev-java/jdbm
# Miroslav Šulc (2021-04-28) # project abandoned # removal in 30 days # see bug: https://bugs.gentoo.org/786420 dev-java/jdbm
[gentoo-dev] last-rite: dev-java/jdbc2-stdext
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786417 dev-java/jdbc2-stdext
[gentoo-dev] last-rite: dev-java/jcmdline
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786414 dev-java/jcmdline
[gentoo-dev] last-rite: dev-java/jboss-{logmanager,logging}
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786408 dev-java/jboss-logmanager dev-java/jboss-logging
[gentoo-dev] last-rite: dev-java/javolution
# Miroslav Šulc (2021-04-28) # last release in 2017, website is offline # removal in 30 days # see bug: https://bugs.gentoo.org/786381 dev-java/javolution
[gentoo-dev] last-rite: dev-java/jarbundler & dev-java/j2ssh
# Miroslav Šulc (2021-04-28) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/786237 dev-java/jarbundler # Miroslav Šulc (2021-04-28) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/786234 dev-java/j2ssh
[gentoo-dev] last-rite: dev-java/helpgui, dev-java/higlayout
# Miroslav Šulc (2021-04-27) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/786117 dev-java/helpgui # Miroslav Šulc (2021-04-27) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/786120 dev-java/higlayout
[gentoo-dev] last-rite: dev-java/hamcrest-integration
# Miroslav Šulc (2021-04-27) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/786096 dev-java/hamcrest-integration
[gentoo-dev] last-rite: dev-java/fscript, dev-java/fastinfoset
# Miroslav Šulc (2021-04-27) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/786090 dev-java/fscript # Miroslav Šulc (2021-04-27) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/786087 dev-java/fastinfoset
[gentoo-dev] last-rite: dev-java/ehcache
# Miroslav Šulc (2021-04-27) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/785985 dev-java/ehcache
[gentoo-dev] last-rite: dev-java/easymock-classextension, dev-java/httpcomponents-client, dev-java/httpcomponents-core
# Miroslav Šulc (2021-04-27) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/785886 dev-java/easymock-classextension # Miroslav Šulc (2021-04-27) # libraries with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/785883 dev-java/httpcomponents-client dev-java/httpcomponents-core
[gentoo-dev] last-rite: dev-java/dtdparser
# Miroslav Šulc (2021-04-27) # library with no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/785877 dev-java/dtdparser
[gentoo-dev] last-rite: dev-java/commons-fileupload
# Miroslav Šulc (2021-04-26) # no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/785847 dev-java/commons-fileupload
[gentoo-dev] last-rite: dev-java/commons-el
# Miroslav Šulc (2021-04-26) # does not compile with java 1.8, no consumer # removal in 30 days # see bug: https://bugs.gentoo.org/785796 dev-java/commons-el
[gentoo-dev] last-rite: dev-java/velocity-dvsl
# Miroslav Šulc (2021-04-25) # obsolete package, nothing depends on it # removal in 30 days # see bug: https://bugs.gentoo.org/785508 dev-java/velocity-dvsl
[gentoo-dev] last-rite: dev-java/cdegroot-db, dev-java/codemodel, dev-java/istack-commons-buildtools
# Miroslav Šulc (2021-04-25) # nothing depends on it # removal in 30 days # see bug: https://bugs.gentoo.org/785532 dev-java/cdegroot-db # Miroslav Šulc (2021-04-25) # uses depracated classes, not used by anything, # removal in 30 days # see bug: https://bugs.gentoo.org/785415 dev-java/codemodel # Miroslav Šulc (2021-04-25) # seems to be obsolete, nothing uses it # removal in 30 days dev-java/istack-commons-buildtools
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
Dne 22. 04. 21 v 8:37 Kaibo Ma napsal(a): Is there a tracking issue for Java 11 on Bugzilla? Kaibo Ma this is it: https://bugs.gentoo.org/697014 fordfrog
[gentoo-dev] last-rite: dev-java/apt-mirror
# Miroslav Šulc (2021-04-21) # no consumers, last commit 2017 # see: https://bugs.gentoo.org/784836 # removal in 30 days dev-java/apt-mirror
[gentoo-dev] last-rite: dev-java/ant-owanttask
# Miroslav Šulc (2021-04-21) # java library, no consumers # see: https://bugs.gentoo.org/784830 dev-java/ant-owanttask
[gentoo-dev] last-rite: dev-java/ini4j
# Miroslav Šulc (2021-04-21) # java library, no consumers # see: https://bugs.gentoo.org/784812 dev-java/ini4j
[gentoo-dev] last-rite: dev-java/tapestry
# Miroslav Šulc (2021-04-18) # our version is outdated with security issues, new version # uses gradle to build which we don't support atm, # also being a web framework deployable to application servers, # we have no usage for it, and nothing depends on it # removal in 30 days dev-java/tapestry
[gentoo-dev] last-rite: dev-java/classmate
# Miroslav Šulc (2021-04-18) # obsolete deps, not used by any package # removal in 30 days dev-java/classmate
[gentoo-dev] last-rite: dev-java/commons-jelly
# Miroslav Šulc (2021-04-18) # obsolete deps, not used by any package # removal in 30 days dev-java/commons-jelly
[gentoo-dev] last-rite: dev-util/findbugs
# Miroslav Šulc (2021-04-18) # the project has been abandoned and the developement # is now under name SpotBugs # see: https://github.com/findbugsproject/findbugs dev-util/findbugs
[gentoo-dev] last-rite: dev-java/ezmorph & dev-java/ical4j
# Miroslav Šulc (2021-04-18) # obsolete deps, not used by any package # removal in 30 days dev-java/ezmorph dev-java/ical4j
[gentoo-dev] last-rite: dev-java/commons-configuration
# Miroslav Šulc (2021-04-18) # obsolete deps, not used by any package dev-java/commons-configuration
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)
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)
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
[gentoo-dev] last-rite: dev-java/odfdom & dev-java/saaj
# Miroslav Šulc (2021-04-14) # java libraries not used by any other package, # masked for removal dev-java/odfdom dev-java/saaj
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
according to flow's question, here's the update to config files without the obsolete and irrelevant stuff: # grep -r openjdk /etc/portage/* /etc/portage/package.use/multi:dev-java/openjdk gentoo-vm /etc/portage/package.use/multi:dev-java/openjdk-bin gentoo-vm /etc/portage/profile/package.use.mask/multi:dev-java/openjdk:11 -gentoo-vm /etc/portage/profile/package.use.mask/multi:dev-java/openjdk-bin:11 -gentoo-vm fordfrog Dne 14. 04. 21 v 9:45 Miroslav Šulc napsal(a): hi guys, we're still far from unmasking java 11 on gentoo, but i hope it will happen, one day (or another...). currently there is one issue across the whole gentoo tree that is a sure blocker and could and should be easily resolved. as java 11 does not compile bytecode older than 1.6, everything that specifies in deps virtual/(jdk|jre)-1.[2-5] will fail to compile and run. these deps should be lifted up to virtual/(jdk|jre)-1.8. also, packages that depend on virtual/(jdk|jre)-1.[67] should be lifted up to 1.8 as that is the lowest version that we support on gentoo and future versions of java might drop support for 1.6 and 1.7 as well, but it's not a blocker for now. just to get an idea how many ebuilds are affected, here's a short summary: $ git --no-pager grep -Eho "virtual/(jre|jdk)-1.[2-7]" | sort | uniq -c 1 virtual/jdk-1.2 7 virtual/jdk-1.3 68 virtual/jdk-1.4 119 virtual/jdk-1.5 444 virtual/jdk-1.6 136 virtual/jdk-1.7 1 virtual/jre-1.2 7 virtual/jre-1.3 68 virtual/jre-1.4 124 virtual/jre-1.5 460 virtual/jre-1.6 113 virtual/jre-1.7 here's the list of all packages where java 1.5 or older is used: $ git --no-pager grep -Elo "virtual/(jre|jdk)-1.[2-5]" | sed -E "s%/[^/]+$%%g" | sort | uniq app-accessibility/brltty app-accessibility/freetts app-crypt/jacksum app-emacs/jde app-misc/jitac app-office/hourglass app-text/hyperestraier dev-db/db-je dev-db/hsqldb dev-db/qdbm dev-java/ant-contrib dev-java/ant-owanttask dev-java/apple-java-extensions-bin dev-java/apt-mirror dev-java/aspectj dev-java/avalon-framework dev-java/bcel dev-java/bnd-junit dev-java/bndlib dev-java/browserlauncher2 dev-java/bytelist dev-java/cal10n dev-java/cdegroot-db dev-java/cldc-api dev-java/codemodel dev-java/commons-el dev-java/commons-fileupload dev-java/commons-lang dev-java/commons-math dev-java/commons-net dev-java/commons-pool dev-java/commons-validator dev-java/dtdparser dev-java/easymock-classextension dev-java/ehcache dev-java/ezmorph dev-java/fastinfoset dev-java/fscript dev-java/glassfish-persistence dev-java/gnu-classpath dev-java/gson dev-java/hamcrest-integration dev-java/hawtjni-runtime dev-java/helpgui dev-java/higlayout dev-java/htmlcleaner dev-java/ical4j dev-java/jansi dev-java/jarbundler dev-java/java-dep-check dev-java/java-getopt dev-java/javahelp dev-java/java-service-wrapper dev-java/javolution dev-java/jaxen dev-java/jbitcollider-core dev-java/jboss-logmanager dev-java/jcmdline dev-java/jcodings dev-java/jdbc2-stdext dev-java/jdbm dev-java/jebl dev-java/jgoodies-looks dev-java/jid3 dev-java/jinput dev-java/jisp dev-java/jlibeps dev-java/jnr-ffi dev-java/jnr-netdb dev-java/joni dev-java/jortho dev-java/jreleaseinfo dev-java/jstun dev-java/jta dev-java/junit-addons dev-java/junrar dev-java/jvmstat dev-java/jvyamlb dev-java/jzlib dev-java/j2ssh dev-java/ldapsdk dev-java/libg dev-java/libmatthew-java dev-java/l2fprod-common dev-java/miglayout dev-java/minlog dev-java/mockito dev-java/msv dev-java/nekohtml dev-java/odfdom dev-java/osgi-compendium dev-java/osgi-enterprise-api dev-java/osgi-foundation dev-java/pdf-renderer dev-java/picocontainer dev-java/prefuse dev-java/radeox dev-java/resin-servlet-api dev-java/sblim-cim-client dev-java/skinlf dev-java/slf4j-ext dev-java/spymemcached dev-java/squareness-jlf dev-java/stax-ex dev-java/stax2-api dev-java/sun-httpserver-bin dev-java/sun-jai-bin dev-java/sun-jimi dev-java/sun-jms dev-java/sun-jmx dev-java/swingx dev-java/swt dev-java/tagsoup dev-java/tapestry dev-java/validation-api dev-java/werken-xpath dev-java/wsdl4j dev-java/xmlstreambuffer dev-java/xom dev-java/zeus-jscl dev-lang/interprolog dev-lang/R dev-lang/xsb dev-libs/OpenNI dev-libs/OpenNI2 dev-lisp/abcl dev-ruby/rjb dev-tex/tex4ht dev-util/android-sdk-update-manager dev-util/jarwizard dev-util/oprofile games-board/domination games-board/megamek games-puzzle/pauker java-virtuals/jmx media-gfx/freewrl media-gfx/graphviz media-gfx/povtree media-libs/libcaca media-libs/libjpeg-turbo media-libs/libpano13 media-libs/mlt media-sound/entagged-tageditor media-sound/protux media-tv/channeleditor media-video/projectx net-analyzer/munin net-analyzer/neti net-dns/libidn net-libs/NativeThread net-misc/tigervnc net-nds/jxplorer sci-biology/amap sci-libs/cdf sci-libs/libsigrok sci-libs/libsvm sci-libs/plplot sci-misc/netlogo-bin sci-physics/jaxodraw sci-physics/thepeg sys-devel/gettext sys-libs/db i would like to
[gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
hi guys, we're still far from unmasking java 11 on gentoo, but i hope it will happen, one day (or another...). currently there is one issue across the whole gentoo tree that is a sure blocker and could and should be easily resolved. as java 11 does not compile bytecode older than 1.6, everything that specifies in deps virtual/(jdk|jre)-1.[2-5] will fail to compile and run. these deps should be lifted up to virtual/(jdk|jre)-1.8. also, packages that depend on virtual/(jdk|jre)-1.[67] should be lifted up to 1.8 as that is the lowest version that we support on gentoo and future versions of java might drop support for 1.6 and 1.7 as well, but it's not a blocker for now. just to get an idea how many ebuilds are affected, here's a short summary: $ git --no-pager grep -Eho "virtual/(jre|jdk)-1.[2-7]" | sort | uniq -c 1 virtual/jdk-1.2 7 virtual/jdk-1.3 68 virtual/jdk-1.4 119 virtual/jdk-1.5 444 virtual/jdk-1.6 136 virtual/jdk-1.7 1 virtual/jre-1.2 7 virtual/jre-1.3 68 virtual/jre-1.4 124 virtual/jre-1.5 460 virtual/jre-1.6 113 virtual/jre-1.7 here's the list of all packages where java 1.5 or older is used: $ git --no-pager grep -Elo "virtual/(jre|jdk)-1.[2-5]" | sed -E "s%/[^/]+$%%g" | sort | uniq app-accessibility/brltty app-accessibility/freetts app-crypt/jacksum app-emacs/jde app-misc/jitac app-office/hourglass app-text/hyperestraier dev-db/db-je dev-db/hsqldb dev-db/qdbm dev-java/ant-contrib dev-java/ant-owanttask dev-java/apple-java-extensions-bin dev-java/apt-mirror dev-java/aspectj dev-java/avalon-framework dev-java/bcel dev-java/bnd-junit dev-java/bndlib dev-java/browserlauncher2 dev-java/bytelist dev-java/cal10n dev-java/cdegroot-db dev-java/cldc-api dev-java/codemodel dev-java/commons-el dev-java/commons-fileupload dev-java/commons-lang dev-java/commons-math dev-java/commons-net dev-java/commons-pool dev-java/commons-validator dev-java/dtdparser dev-java/easymock-classextension dev-java/ehcache dev-java/ezmorph dev-java/fastinfoset dev-java/fscript dev-java/glassfish-persistence dev-java/gnu-classpath dev-java/gson dev-java/hamcrest-integration dev-java/hawtjni-runtime dev-java/helpgui dev-java/higlayout dev-java/htmlcleaner dev-java/ical4j dev-java/jansi dev-java/jarbundler dev-java/java-dep-check dev-java/java-getopt dev-java/javahelp dev-java/java-service-wrapper dev-java/javolution dev-java/jaxen dev-java/jbitcollider-core dev-java/jboss-logmanager dev-java/jcmdline dev-java/jcodings dev-java/jdbc2-stdext dev-java/jdbm dev-java/jebl dev-java/jgoodies-looks dev-java/jid3 dev-java/jinput dev-java/jisp dev-java/jlibeps dev-java/jnr-ffi dev-java/jnr-netdb dev-java/joni dev-java/jortho dev-java/jreleaseinfo dev-java/jstun dev-java/jta dev-java/junit-addons dev-java/junrar dev-java/jvmstat dev-java/jvyamlb dev-java/jzlib dev-java/j2ssh dev-java/ldapsdk dev-java/libg dev-java/libmatthew-java dev-java/l2fprod-common dev-java/miglayout dev-java/minlog dev-java/mockito dev-java/msv dev-java/nekohtml dev-java/odfdom dev-java/osgi-compendium dev-java/osgi-enterprise-api dev-java/osgi-foundation dev-java/pdf-renderer dev-java/picocontainer dev-java/prefuse dev-java/radeox dev-java/resin-servlet-api dev-java/sblim-cim-client dev-java/skinlf dev-java/slf4j-ext dev-java/spymemcached dev-java/squareness-jlf dev-java/stax-ex dev-java/stax2-api dev-java/sun-httpserver-bin dev-java/sun-jai-bin dev-java/sun-jimi dev-java/sun-jms dev-java/sun-jmx dev-java/swingx dev-java/swt dev-java/tagsoup dev-java/tapestry dev-java/validation-api dev-java/werken-xpath dev-java/wsdl4j dev-java/xmlstreambuffer dev-java/xom dev-java/zeus-jscl dev-lang/interprolog dev-lang/R dev-lang/xsb dev-libs/OpenNI dev-libs/OpenNI2 dev-lisp/abcl dev-ruby/rjb dev-tex/tex4ht dev-util/android-sdk-update-manager dev-util/jarwizard dev-util/oprofile games-board/domination games-board/megamek games-puzzle/pauker java-virtuals/jmx media-gfx/freewrl media-gfx/graphviz media-gfx/povtree media-libs/libcaca media-libs/libjpeg-turbo media-libs/libpano13 media-libs/mlt media-sound/entagged-tageditor media-sound/protux media-tv/channeleditor media-video/projectx net-analyzer/munin net-analyzer/neti net-dns/libidn net-libs/NativeThread net-misc/tigervnc net-nds/jxplorer sci-biology/amap sci-libs/cdf sci-libs/libsigrok sci-libs/libsvm sci-libs/plplot sci-misc/netlogo-bin sci-physics/jaxodraw sci-physics/thepeg sys-devel/gettext sys-libs/db i would like to ask you to revisit your packages where java 1.5 or lower is specified and lift the restriction up to 1.8. you might want to do the same for 1.7 and 1.8 or just leave it for the time when bumping the package. you must do the update in a revbump, as it affects the format of java (.jar) files generated and it would not be picked up if done in-place and would cause an issue in the future that the existing java files would not be supported at the runtime (if not recompiled) due to an obsolete format. the correct ways to specify the dep
[gentoo-dev] last-rite: dev-java/cal10n & dev-java/slf4j-ext
# Miroslav Šulc (2021-04-06) # Last release of dev-java/cal10n in 2013, no consumer # in the tree except dev-java/slf4j-ext which is not # needed by any package aswell. Removal in 30 days. dev-java/cal10n dev-java/slf4j-ext
[gentoo-dev] last rite: media-libs/raul
# Miroslav Šulc (2021-01-09) # media-sound/patchage used to depend on it but the dependency # has been dropped in v1.0.0. There are no other packages in the tree # depending on it. Also having issues compiling it. Removal in 30 days. media-libs/raul
Re: [gentoo-dev] [PATCH 0/2] eclass/java-{utils-2,pkg-simple}.eclass: features and enhancements
hi all, it's committed now: commit a4d773b4c2f433438b00010bbf0981c81e123d1b (HEAD -> master, origin/master, origin/HEAD) Author: Zhang Zongyu Date: Wed Aug 26 00:30:10 2020 +0800 patching ebuild files to support new java-pkg-simple Signed-off-by: Zhang Zongyu Signed-off-by: Miroslav Šulc commit faa407032918b43fafe7d4e1de85dde4d30ba4f2 Author: Zhang Zongyu Date: Wed Aug 26 00:30:09 2020 +0800 java-pkg-simple.eclass and java-utils-2.eclass: features and enhancements 1) support java resources 2) support java main class and launcher 3) enable java-pkg-simple_src_test() 4) support binary jars (both for resolve circular deps and for pkgdiff test) Signed-off-by: Zhang Zongyu Signed-off-by: Miroslav Šulc regards. fordfrog Dne 28. 08. 20 v 19:25 Miroslav Šulc napsal(a): hi all, jfyi, i'm going to commit these changes to the main tree at the end of the weekend if there are no objections. (i've been mentoring this project.) we have some other work that depends on these patches so i'd like to see it in the main tree as soon as possible. regards. fordfrog Dne 25. 08. 20 v 17:46 zongyu napsal(a): Dear all, I am one of the students who attend Gentoo's Google Summer of Code program [1] this year. And this email is attempting to trigger a review for a patch for eclass/java-{utils-2,pkg-simple}.eclass. Java-pkg-simple.eclass is widely used by java packages that do not provide a build.xml for building with java-ant-2.eclass. Although java-pkg-simple.eclass works well right now, it still lacks some features [2], such as installing java resources and providing src_test() function. The patch below is trying to enable some missing features of java-pkg-simple.eclass, including: 1. Since some java packages (e.g. dev-java/commons-io) has java resources bundled in jar files, java-pkg-simple.eclass now has a function java-pkg-simple_prepend_resources() to recognize and install those java resource files; 2. Some java packages have a "main class" so that we can execute the jar file from command line. With "JAVA_MAIN_CLASS" and "JAVA_LAUNCHER_FILENAME", the eclass can deal with the situation properly; 3. Enabling src_test() function with multiple testing frameworks like junit, testng, pkgdiff and so on; 4. Pkgdiff test will compare natively compiled jar file and upstream provided binary jar file, to support the feature the eclass will fetch pre-compiled java jars and accept "JAVA_BINJAR_FILENAME" to identify it. Besides, installing binjar will help resolve circular dependencies, so the eclass also accepts USE="binary" and installs the binary jars now. And for java-utils-2.eclass: 1. To support java-pkg-simple_src_test(), there is a new function etestng() to launch java tests with dev-java/testng. Finally, there is a breaking change to java-pkg-simple. Instead of treating "JAVA_SRC_DIR" as a string of directories separated by spaces, currently the eclass will treat it as an array. A few packages will be affected and fail to build, and the second patch will solve the problem. P.S. This is the first time for me to write a patch for such a huge project and send such an email. I hope this email will meet your requirements, and I would appreciate your every response. Regards, Zhang Zongyu [1] the GSoC program https://summerofcode.withgoogle.com/projects/#4994566568017920 [2] a related bug https://bugs.gentoo.org/564158 zongyu (2): java-pkg-simple.eclass and java-utils-2.eclass: features and enhancements patching ebuild files to support new java-pkg-simple dev-java/juel/juel-2.1.0-r2.ebuild | 2 +- dev-java/piccolo2d/piccolo2d-3.0-r1.ebuild | 2 +- .../swingx-ws-1.0_p20110515-r1.ebuild | 4 +- .../xml-commons/xml-commons-1.4.01.ebuild | 2 +- dev-java/xsdlib/xsdlib-20090415.ebuild | 4 +- eclass/java-pkg-simple.eclass | 379 -- eclass/java-utils-2.eclass | 38 ++ 7 files changed, 395 insertions(+), 36 deletions(-)
[gentoo-dev] last rite: media-sound/traverso
# Miroslav Šulc (2020-08-29) # Upstream has version 1.1.2, but only for Windows, # sources are gone. Removal in 30 days. media-sound/traverso
Re: [gentoo-dev] [PATCH 0/2] eclass/java-{utils-2,pkg-simple}.eclass: features and enhancements
hi all, jfyi, i'm going to commit these changes to the main tree at the end of the weekend if there are no objections. (i've been mentoring this project.) we have some other work that depends on these patches so i'd like to see it in the main tree as soon as possible. regards. fordfrog Dne 25. 08. 20 v 17:46 zongyu napsal(a): Dear all, I am one of the students who attend Gentoo's Google Summer of Code program [1] this year. And this email is attempting to trigger a review for a patch for eclass/java-{utils-2,pkg-simple}.eclass. Java-pkg-simple.eclass is widely used by java packages that do not provide a build.xml for building with java-ant-2.eclass. Although java-pkg-simple.eclass works well right now, it still lacks some features [2], such as installing java resources and providing src_test() function. The patch below is trying to enable some missing features of java-pkg-simple.eclass, including: 1. Since some java packages (e.g. dev-java/commons-io) has java resources bundled in jar files, java-pkg-simple.eclass now has a function java-pkg-simple_prepend_resources() to recognize and install those java resource files; 2. Some java packages have a "main class" so that we can execute the jar file from command line. With "JAVA_MAIN_CLASS" and "JAVA_LAUNCHER_FILENAME", the eclass can deal with the situation properly; 3. Enabling src_test() function with multiple testing frameworks like junit, testng, pkgdiff and so on; 4. Pkgdiff test will compare natively compiled jar file and upstream provided binary jar file, to support the feature the eclass will fetch pre-compiled java jars and accept "JAVA_BINJAR_FILENAME" to identify it. Besides, installing binjar will help resolve circular dependencies, so the eclass also accepts USE="binary" and installs the binary jars now. And for java-utils-2.eclass: 1. To support java-pkg-simple_src_test(), there is a new function etestng() to launch java tests with dev-java/testng. Finally, there is a breaking change to java-pkg-simple. Instead of treating "JAVA_SRC_DIR" as a string of directories separated by spaces, currently the eclass will treat it as an array. A few packages will be affected and fail to build, and the second patch will solve the problem. P.S. This is the first time for me to write a patch for such a huge project and send such an email. I hope this email will meet your requirements, and I would appreciate your every response. Regards, Zhang Zongyu [1] the GSoC program https://summerofcode.withgoogle.com/projects/#4994566568017920 [2] a related bug https://bugs.gentoo.org/564158 zongyu (2): java-pkg-simple.eclass and java-utils-2.eclass: features and enhancements patching ebuild files to support new java-pkg-simple dev-java/juel/juel-2.1.0-r2.ebuild| 2 +- dev-java/piccolo2d/piccolo2d-3.0-r1.ebuild| 2 +- .../swingx-ws-1.0_p20110515-r1.ebuild | 4 +- .../xml-commons/xml-commons-1.4.01.ebuild | 2 +- dev-java/xsdlib/xsdlib-20090415.ebuild| 4 +- eclass/java-pkg-simple.eclass | 379 -- eclass/java-utils-2.eclass| 38 ++ 7 files changed, 395 insertions(+), 36 deletions(-)
[gentoo-dev] last rite: media-libs/slv2
# Miroslav Šulc (2020-08-22) # SLV2 has been replaced by Lilv. The latest and final version # of SLV2 is 0.6.6, released on May 26, 2009. # Removal in 30 days. Bug #735380. media-libs/slv2
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Dne 18. 08. 20 v 19:06 Joonas Niilola napsal(a): On 8/18/20 7:30 PM, Miroslav Šulc wrote: hi, how would be handled cases where you and me agreed that you will take care of pull requests on behalf of sound@ and proaudio@? and what if a package is maintained by multiple maintainers or even some maintainers and a project, each with a different preference? how that would be solved to not bring in some confusion? and how about maintainers that are not gentoo devs? and what if there are packages that have a maintainer that is mia but has the no-accept policy set and some other dev would like to fix a package that has an annoying bug (using a pull request by a contributor) as the reported maintainer is mia, or a contributor might want to maintain the package? and what if a maintainer wants pull requests just for some packages and not for others? and what if a pull request is referenced from a bug at bugzilla but the maintainer does not accept pull requests? One idea for implementation would be to enable the flag in your User: page. Then if any member in a project has it enabled, the project would have it set positive as well. However it doesn't necessary directly translate to you you merging personal PRs -> you merging all of your project PRs. I also thought the project could count Yes's and No's from their members, printing something like "This project has a 66 % probability of handling Github PRs". But that'd look silly. is there a way or would it be possible to get notified on pull requests that are relevant to me? though i get notifications from github, i get tens to hundreds daily and most of them are irrelevant to me so searching for those few that are related to me is really inefficient for me. ... If the current maintainer is MIA, it doesn't change anything from our current situation. At least it doesn't make it any worse than it is, but has advantages for those available. I'm sorry I may have not understood your question correctly here? We can claim maintainer timeout, or ask QA to deal with these situations. It wouldn't change. if a maintainer is mia and does not accept pull requests, there is much lower chance to get his/her package fixed/bumped. i personally do not hesitate to step up and fix a package though i do not maintain it if the bug bothers me and i see no activity from the maintainer. and if i can find a pull request for such a package, it could save me some time. so what i had on my mind is a situation with maintainer mia + no-pull-requests-policy -> worse situation than maintainer mia and yes-pull-requests-policy. I believe toggling the flag per-package basis is too much. Sure I can see the situation where this happens, but the point here is to enable communication between contributor and maintainer. If you're not accepting PRs to some packages, you can close the PR informing contributor about it. It'd be better than leave it to rot for months, years, with no answer. you know much better than me how pull requests are processed and what benefits and problems those bring. for me pull requests are generally good thing but sometimes when i see the quality of them, basic issues not resolved like the missing signed-off-by, contributors not responding and disappearing... i'm just not sure this whole effort will bring some advancement, but i trust your opinion on that as you are the one spending a lot of time on github. anyway, when it comes to this feature mentioned above, if it might be of any use, it can work as an override for package where it is specified and otherwise be undefined. in the end the contributor will be interested in whether the package accepts pull requests, not a dev or project. Your last question wouldn't be any different from a current situation, however other devs/users can inform the contributor that this maintainer can't/doesn't use Github, and the PR can be closed. I'm mostly looking for communication here. I believe being rejected is better than being ignored. The bug can be dealt separately from Github PR. i agree with you, making a contribution and being ignored is demotivating. There's a tool that tells what PRs reference a closed bug, (ie contribution was made, but not accepted/noticed, and the bug was closed regardless of it) https://github.com/wimmuskee/gengee sorry for this flood of questions but atm it brings confusion to me :-) from my point of view and personal preference, i appreciate pull requests from contributors if those are of a decent quality, but for me it's hard to easily find out the relevant pull requests. with the new packages.gentoo.org it might be easier in the future but i'm not sure yet how reliable it is atm as for example the list of outdated packages for proaudio@ (https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated) does not seem to be updated or i misunderstood something. the sa
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Dne 18. 08. 20 v 19:10 Joonas Niilola napsal(a): On 8/18/20 8:06 PM, Joonas Niilola wrote: So I think it's just simplest to enable it per-user per-project basis. We can all edit Project: pages, toggling the flag. If you're willing to look and merge sound@ PRs, you enable it for Sound project. However this might cause a problem when a member who enabled the flag leaves the project, or gets retired. But that's relatively easy to keep a track of. As for non-dev maintainers, they **require** @gentoo.org person/project to proxy for them. It'd be a start to mirror the project/dev option, since they'd be the one committing for non-dev maintainers anyway. Also non-dev maintainers can have their own wiki pages to toggle this. However I'm not aware if the linking is as simple as with @gentoo.org metadata info. Forgot to add, if you have say 1 person and 2 projects assigned as maintainers, where 1 does look for Github PRs and 2 does not, it'd still be flagged as "Yes". Or maybe the majority here wins? i think the approach "one yes beats all no-es" makes more sense as there still is one person who can handle the pull request. up to that, the yes might come from a main maintainer and the no from inactive ones... or the opposite... so i guess it might be better to take it as a hint rather than a rule as the outcome might be various. -- juippis fordfrog
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
hi, how would be handled cases where you and me agreed that you will take care of pull requests on behalf of sound@ and proaudio@? and what if a package is maintained by multiple maintainers or even some maintainers and a project, each with a different preference? how that would be solved to not bring in some confusion? and how about maintainers that are not gentoo devs? and what if there are packages that have a maintainer that is mia but has the no-accept policy set and some other dev would like to fix a package that has an annoying bug (using a pull request by a contributor) as the reported maintainer is mia, or a contributor might want to maintain the package? and what if a maintainer wants pull requests just for some packages and not for others? and what if a pull request is referenced from a bug at bugzilla but the maintainer does not accept pull requests? sorry for this flood of questions but atm it brings confusion to me :-) from my point of view and personal preference, i appreciate pull requests from contributors if those are of a decent quality, but for me it's hard to easily find out the relevant pull requests. with the new packages.gentoo.org it might be easier in the future but i'm not sure yet how reliable it is atm as for example the list of outdated packages for proaudio@ (https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated) does not seem to be updated or i misunderstood something. the same goes for the list of bugs (https://packages.gentoo.org/maintainer/proau...@gentoo.org/bugs) which seems to be missing some bugs as my list with "Assignee: proau...@gentoo.org" has 96 bugs atm compared to 76 bugs at packages.gentoo.org. fordfrog Dne 18. 08. 20 v 14:05 Joonas Niilola napsal(a): Hey, some of you may already have seen the new packages.gentoo.org page, https://packages.gentoo.org/ and the new maintainer pages in it, https://packages.gentoo.org/maintainers If you open a maintainer page, https://packages.gentoo.org/maintainer/juip...@gentoo.org you can see a tab called "pull requests" there, https://packages.gentoo.org/maintainer/juip...@gentoo.org/pull-requests with description saying: "If you also like to help the Gentoo project, you can consider sending a Pull Request via GitHub. Before doing so, you might want to take a look at the wiki page." I'm suggesting of adding a new metadata flag to our Wiki's User:/Project: page which then prints a message to this page saying whether the maintainer (be it project or user), "accepts" or "deals with" Github contributions. The wording can be a bit better, but it'd be there to **notify** our **contributors** whether their time and effort will most likely be wasted making a pull request for this particular maintainer. This note would then be displayed in every package the maintainer is assigned to, https://packages.gentoo.org/packages/media-libs/rlottie/pull-requests I'd imagine a simple switch in Wiki could do it. No need to add anything to ::gentoo repo. The switch can be visible in User:/Project: page, but it doesn't have to. Unspecified metadata flag would print something like "This maintainer hasn't specified whether they handle Github pull requests. If you wish to help using Github, please also open a bug prior to that and link your pull request commit to that bug (add link to glep-66 here)". Or just default it to "No." Note that the bug text could always be displayed nevertheless, since that is still the main channel to communicate with maintainers. It's undeniable we get a lot of pull requests and unfortunate that many are left without any attention to rot. https://github.com/gentoo/gentoo/pulls I think this would serve both parties - devs and contributors, with little to no cost. -- juippis
[gentoo-dev] last rite: x11-libs/flowcanvas
# Miroslav Šulc (2020-08-11) # Package dead. No consumers in the tree. # Removal in 30 days. Bug #735518 x11-libs/flowcanvas
[gentoo-dev] last rite: media-sound/tapiir
# Miroslav Šulc (2020-08-08) # HOMEPAGE dead. # Removal in 30 days. bug #736326 media-sound/tapiir
[gentoo-dev] last rite: media-sound/specimen
# Miroslav Šulc (2020-08-08) # Last release in 2007, HOMEPAGE dead. # Removal in 30 days. bug #736322 media-sound/specimen
[gentoo-dev] last rite: media-sound/jackbeat
# Miroslav Šulc (2020-08-08) # Last release in 2010. # Removal in 30 days. bug #736300 media-sound/jackbeat
[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs due to jlec being MIA
i'll take app-office/scribus. miroslav Dne 05. 08. 20 v 9:24 Michał Górny napsal(a): Hello, The following packages are looking for a new maintainer: [vB] app-backup/cachedir [vB] app-benchmarks/bootchart2 [ B] app-benchmarks/ramspeed [ B] app-office/scribus [vB] dev-lua/luaposix [ b] net-analyzer/zmap [ ] net-libs/czmq [ ] net-vpn/vpncwatch [vB] sys-block/blocks [ ] sys-boot/makebootfat [v ] sys-fs/aufs-headers [vB] sys-fs/aufs-util [vB] sys-fs/bcache-tools [v ] sys-kernel/aufs-sources [vB] sys-kernel/kergen Legend: v - needs version bump b - has trivial (QA) bug reported B - has non-trivial bug reported
[gentoo-dev] Last rite: media-libs/libclalsadrv
# Miroslav Šulc (2019-12-26) # Deprecated by upstream, not used anymore in the tree. # Removal in 30 days. Bug #703196. media-libs/libclalsadrv
[gentoo-dev] Re: HOMEPAGE and DESCRIPTION in ebuilds? (was: Usefulness of HOMEPAGE=https://www.gentoo.org)
hi, it's proly little bit off this topic, but why do we have to copy homepage and description from ebuild to ebuild? wouldn't it be better to move this information to metadata.xml and keep it just there? or does in reality one package really have various homepages and various descriptions for different versions? metadata.xml could also contain more structured data like you outlined, i.e. link to homepage, sources/repository, bug tracker and possibly other. miroslav Dne 04. 12. 19 v 13:36 Michał Górny napsal(a): Hi, Many of Gentoo-originating packages are listing the main Gentoo site as HOMEPAGE. In my opinion, this is suboptimal (not to say 'useless'). I can think of a few uses for HOMEPAGE: 1. providing additional information about the package (before the user chooses it), 2. providing easy access to (additional) documentation, 3. providing easy access to package sources, 4. providing easy access to bug reporting, 5. providing easy access to downloads. A good HOMEPAGE is dedicated to the package in question, and makes it easy to find all the stuff (and all other stuff the user might need). The more effort user needs to put into finding what he needs, the worse HOMEPAGE is. Now, if I consider gentoo.org as a HOMEPAGE for ~90 packages it currently is, it's horribly bad. I suppose that in some cases authors meant to indicate that Gentoo is the package's upstream. However, by going to the main Gentoo site, it's *very hard* to find anything about the package in question. Just please select a totally random package from those listing gentoo.org as HOMEPAGE, then go to gentoo.org and try to find either of the points listed above. If you click 'Downloads', you're certainly not going to find anything relevant. Through 'Support', you may eventually find that tiny Bugzilla button at the bottom... and then try to find the correct Product. You may also find gitweb link somewhere, and try to see if the project has a repo there. Or maybe it's somewhere else, or maybe it existed on somebody's devspace once. My point is: gentoo.org as a HOMEPAGE sucks. Please use something more specific instead. Even link to gitweb would be more helpful because it would at least be relevant to the package in question.
[gentoo-dev] Last rite: dev-java/balloontip
# Miroslav Šulc (2019-12-03) # Project does not exist anymore. # Removal in 30 days. Bug #680452. dev-java/balloontip
[gentoo-dev] rfc: eclass patch for javatoolkit path change
wrt bug https://bugs.gentoo.org/627440 there is a need to update java eclasses to use correctly both current path and the new path. the attached patch should provide that. i also attached updated ebuild with the new path. in the patch i also removed the old "/usr/bin/..." path which is not used anymore. i tested that on some ebuilds and all works fine. any comments and suggestions welcome. fordfrog diff --git a/eclass/java-ant-2.eclass b/eclass/java-ant-2.eclass index 1fd4feb39134..5be76953edd6 100644 --- a/eclass/java-ant-2.eclass +++ b/eclass/java-ant-2.eclass @@ -224,8 +224,13 @@ java-ant_bsfix_files() { files+=( -f "${file}" ) done - local rewriter3="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite-3.py" - local rewriter4="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/build-xml-rewrite" + if [ -e "${EPREFIX}/usr/libexec/javatoolkit" ]; then + local rewriter3="${EPREFIX}/usr/libexec/javatoolkit/xml-rewrite-3.py" + local rewriter4="${EPREFIX}/usr/libexec/javatoolkit/build-xml-rewrite" + else + local rewriter3="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite-3.py" + local rewriter4="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/build-xml-rewrite" + fi if [[ -x ${rewriter4} && ${JAVA_ANT_ENCODING} ]]; then [[ ${JAVA_ANT_REWRITE_CLASSPATH} ]] && local gcp="-g" @@ -375,11 +380,11 @@ java-ant_ignore-system-classes() { # @DESCRIPTION: # Run the right xml-rewrite binary with the given arguments java-ant_xml-rewrite() { - local gen2="${EPREFIX}/usr/bin/xml-rewrite-2.py" local gen2_1="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite-2.py" + local gen2_2="${EPREFIX}/usr/libexec/javatoolkit/xml-rewrite-2.py" # gen1 is deprecated - if [[ -x "${gen2}" ]]; then - ${gen2} "${@}" || die "${gen2} failed" + if [[ -x "${gen2_2}" ]]; then + ${gen2_2} "${@}" || die "${gen2_2} failed" elif [[ -x "${gen2_1}" ]]; then ${gen2_1} "${@}" || die "${gen2_1} failed" else diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass index 4f7eb0356fc9..e32cb572f147 100644 --- a/eclass/java-utils-2.eclass +++ b/eclass/java-utils-2.eclass @@ -2729,10 +2729,13 @@ java-pkg_jar-list() { java-pkg_verify-classes() { #$(find ${D} -type f -name '*.jar' -o -name '*.class') - local version_verify="/usr/bin/class-version-verify.py" + local version_verify_1="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/class-version-verify.py" + local version_verify_2="${EPREFIX}/usr/libexec/javatoolkit/class-version-verify.py" - if [[ ! -x "${version_verify}" ]]; then - version_verify="/usr/$(get_libdir)/javatoolkit/bin/class-version-verify.py" + if [[ -x "${version_verify_1}" ]]; then + local version_verify=${version_verify_1} + else + local version_verify=${version_verify_2} fi if [[ ! -x "${version_verify}" ]]; then # Copyright 1999-2019 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 PYTHON_COMPAT=( python2_7 python3_{5,6,7} ) PYTHON_REQ_USE="xml(+)" inherit distutils-r1 multilib prefix DESCRIPTION="Collection of Gentoo-specific tools for Java" HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Java"; SRC_URI="https://gitweb.gentoo.org/proj/${PN}.git/snapshot/${P}.tar.bz2"; LICENSE="GPL-2" SLOT="0" KEYWORDS="~amd64 ~arm ~arm64 ~ppc64 ~sparc ~x86 ~ppc-aix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris" python_prepare_all() { hprefixify src/py/buildparser src/py/findclass setup.py distutils-r1_python_prepare_all } python_install() { distutils-r1_python_install \ --install-scripts="${EPREFIX}"/usr/libexec/${PN} }
Re: [gentoo-dev] RFC: ant-tasks.eclass patch
Dne 25. 09. 19 v 21:44 Michał Górny napsal(a): On Wed, 2019-09-25 at 20:47 +0200, Miroslav Šulc wrote: ... I don't think you need two branches here. Non-array variable is equivalent to an array with a single element for the purpose of [@], so your 'for' loop will work correctly both for non-array and array. thanks, you're right, i simplified the patch (attached) and all my tests passed. miroslav diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass index 309df084d156..04c6fb5b7d67 100644 --- a/eclass/ant-tasks.eclass +++ b/eclass/ant-tasks.eclass @@ -54,7 +54,9 @@ ANT_TASK_NAME="${PN#ant-}" # @DESCRIPTION: # Specifies JAVA_PKG_NAME (PN{-SLOT} used with java-pkg_jar-from) of the package # that this one depends on. Defaults to the name of ant task, ebuild can -# override it before inheriting this eclass. +# override it before inheriting this eclass. In case there is more than one +# dependency, the variable can be specified as bash array with multiple strings, +# one for each dependency. ANT_TASK_DEPNAME=${ANT_TASK_DEPNAME-${ANT_TASK_NAME}} # @ECLASS-VARIABLE: ANT_TASK_DISABLE_VM_DEPS @@ -105,7 +107,7 @@ S="${WORKDIR}/${MY_P}" # base: performs the unpack, build.xml replacement and symlinks ant.jar from # ant-core # -# jar-dep: symlinks the jar file(s) from dependency package +# jar-dep: symlinks the jar file(s) from dependency package(s) ant-tasks_src_unpack() { [[ -z "${1}" ]] && ant-tasks_src_unpack all @@ -129,9 +131,11 @@ ant-tasks_src_unpack() { # ant.jar to build against java-pkg_jar-from --build-only ant-core ant.jar;; jar-dep) -# get jar from the dependency package +# get jar from the dependency package(s) if [[ -n "${ANT_TASK_DEPNAME}" ]]; then - java-pkg_jar-from ${ANT_TASK_DEPNAME} + for depname in "${ANT_TASK_DEPNAME[@]}"; do + java-pkg_jar-from ${depname} + done fi;; all) ant-tasks_src_unpack base jar-dep;;