View previous topic :: View next topic |
Author |
Message |
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Sun Apr 27, 2014 10:05 am Post subject: Philosophy of the Java-Team |
|
|
I have recently done a fresh install of Gentoo (~amd64) and met the following problems:
I wanted to install Netbeans but this didn't work because it depends on Gnu-Classpath
and Gnu-Classpath does not compile with recent versions of Freetype (2.5.3).
The problem persists for about two months now.
(Not to mention the Eclipse-SDK.)
And then there is a Java-Overlay.
What is the philosophy of the Java-Team in regard to the situation I am facing (I want to install
Java-IDEs)? Quit trying with Gentoo and go to the Java-Overlay as any sane user would do? |
|
Back to top |
|
|
Navar Guru
Joined: 20 Aug 2012 Posts: 353
|
Posted: Sun Apr 27, 2014 10:57 am Post subject: |
|
|
Eclipse has been problematic here. See advice from here and elsewhere in the forums.
Unless you need it for multi-user access, it's easy enough to just install your local copy in your home directory and be done with it for auto updating, android development, etc. Or you can try the newer overlay route. I haven't used Netbeans in years, so I couldn't tell you how up to date it is (I believe bleeding edge is probably version 8). On a cursory fast search, I see it's mostly version 7.2 in stable and version 8 keyworded. |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Sun Apr 27, 2014 2:18 pm Post subject: Re: Philosophy of the Java-Team |
|
|
YPenguin wrote: | I have recently done a fresh install of Gentoo (~amd64) and met the following problems:
I wanted to install Netbeans but this didn't work because it depends on Gnu-Classpath
and Gnu-Classpath does not compile with recent versions of Freetype (2.5.3). |
This appears to be https://bugs.gentoo.org/show_bug.cgi?id=504944 which has a patch, I've committed this.
Can you sync in a few hours from now and try again?
YPenguin wrote: | The problem persists for about two months now.
(Not to mention the Eclipse-SDK.)
And then there is a Java-Overlay.
What is the philosophy of the Java-Team in regard to the situation I am facing (I want to install
Java-IDEs)? Quit trying with Gentoo and go to the Java-Overlay as any sane user would do? |
NetBeans should work fine. Eclipse SDK is challenging to build; as evidenced by http://thume.ca/2013/03/29/contributing-to-eclipse/ and https://bugs.gentoo.org/show_bug.cgi?id=325271 it takes a lot of effort and time to get it packaged, it only would really be able to happen if multiple person would help or one person really wants to do nothing but dedicate his/her time to it.
Last edited by TomWij on Wed Apr 30, 2014 9:53 pm; edited 1 time in total |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Sun Apr 27, 2014 6:38 pm Post subject: Eclipse-IDE-bin |
|
|
If it is near to impossible to build from source, then I would suggest to offer
a bin package for the users. The Firefox-maintainers did that and the Open-Office
maintainers did it, too. So it is tolerable in the Gentoo-Tree and solves the need
of most users. |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Sun Apr 27, 2014 7:07 pm Post subject: Re: Eclipse-IDE-bin |
|
|
YPenguin wrote: | If it is near to impossible to build from source, then I would suggest to offer
a bin package for the users. The Firefox-maintainers did that and the Open-Office
maintainers did it, too. So it is tolerable in the Gentoo-Tree and solves the need
of most users. |
Binary packages from upstream aren't tolerated; binary packages that are tolerated, are the ones that are build by Gentoo Developers.
You can find an upstream binary package of dev-util/eclipse-sdk-bin in the Java overlay. |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Mon Apr 28, 2014 11:15 am Post subject: GNU-Classpath |
|
|
I tried to compile GNU Classpath today with same result as before:
gnu_java_awt_peer_gtk_FreetypeGlyphVector.c:45:30: fatal error: freetype/ftglyph.h: No such file or directory
#include <freetype/ftglyph.h>
Did someone remove the bug from Bugzilla ? |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Mon Apr 28, 2014 1:39 pm Post subject: |
|
|
I would personally not question the philosophy of the Java-Team.
Even not the intention.
The will! Maybe the will! Only the will!
https://bugs.gentoo.org/show_bug.cgi?id=384609 _________________
|
|
Back to top |
|
|
khayyam Watchman
Joined: 07 Jun 2012 Posts: 6227 Location: Room 101
|
Posted: Mon Apr 28, 2014 1:47 pm Post subject: |
|
|
aCOSwt wrote: | I would personally not question the philosophy of the Java-Team. |
aCOSwt ... they have a philosophy? What are they, post-deleuzian-quasi-virtualists? :)
off-topic, so no need to reply :)
best ... khay |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Mon Apr 28, 2014 7:12 pm Post subject: |
|
|
Oh come on TomWij! You don't even trust that!
Being said that I appreciate your personal efforts in shaking the sediments...
Do not tell that (One example among several others)
Tom Wijsman in https://bugs.gentoo.org/show_bug.cgi?id=405057 wrote: | 2013-09-16 (reported 2012-02-20)
(In reply to Mike Limansky from comment #4)
> So,
> it's bit strange to block java7 stabilization because of this bug. IMHO, the
> only thing required here is to set DEPENDS on <java7.
There are already such versions stable, please note this blocks <java7 removal. | means an acknowledgment from you and Mike that manpower is the root cause for the stall!
When there is a will, there is a way! _________________
|
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Mon Apr 28, 2014 10:00 pm Post subject: |
|
|
In that same comment #4 Mike has said it is unmaintained; so, he does acknowledge that.
The presence of a whole bug dependency tree that remains unresolved confirms this too.
When you include the part that is resolved you'll see that the willpower has resolved a lot already;
but the limited willpower isn't enough to walk all the ways, the ways needed to take it to the next world.
aCOSwt wrote: | When there is a will, there is a way! |
Willpower is limited, thus the ways one can walk on are limited too.
Spending time on one way, means you can't spent time on another way.
So, if you want duty on the other ways; you'll need more manpower...
Not to forget these are just the Java ways, there are a ton more ways to explore in Gentoo. |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Tue Apr 29, 2014 9:50 am Post subject: GNU-Classpath |
|
|
The problem persists for me.
I have filed the bug again with information on my personal case.
https://bugs.gentoo.org/show_bug.cgi?id=508958
I can not currently say why the fix didn't work for me.
I ran emerge --sync before trying today with same result.
(emerge --sync is the first thing I do each day after starting Linux.)
I did not try a manual patch so far but the Freetype-developers are
unlikely to take back their changes and the problem has got to be solved anyway. |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Tue Apr 29, 2014 10:08 am Post subject: |
|
|
You will want to switch to a different official Gentoo rsync mirror, then sync and try again.
http://www.gentoo.org/main/en/mirrors2.xml
You have an old revision of the ebuild as your build.log doesn't show the patch being applied. |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Wed Apr 30, 2014 9:28 am Post subject: |
|
|
TomWij wrote: | You will want to switch to a different official Gentoo rsync mirror, then sync and try again. |
I have done that and - no - the patch doesn't get applied by the emerge system.
This was today.
Do you know someone with experience in integrating patches into the emerge system who could check this? |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Wed Apr 30, 2014 2:25 pm Post subject: |
|
|
YPenguin wrote: | TomWij wrote: | You will want to switch to a different official Gentoo rsync mirror, then sync and try again. |
I have done that and - no - the patch doesn't get applied by the emerge system.
This was today. |
Is there perhaps something with the Portage tree itself, like wrong permissions? Sometimes such permission errors hide in the long sync output. You could consider to wipe the entire Portage tree and start over...
YPenguin wrote: | Do you know someone with experience in integrating patches into the emerge system who could check this? |
As long as /usr/portage/dev-java/gnu-classpath/gnu-classpath-0.98-r3.ebuild doesn't contain the epatch "${FILESDIR}"/${PF}-freetype-2.5.3-support.patch line inside java_prepare like http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-java/gnu-classpath/gnu-classpath-0.98-r3.ebuild?revision=1.10 does this has nothing to do with such experience. Can you confirm that line is there? Alternatively, feel free to copy the third line $Header to here so we can see which revision? Mine is "v 1.10 2014/04/27 14:18:30 tomwij" like on the link. |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Wed Apr 30, 2014 4:09 pm Post subject: GNU-Classpath |
|
|
My ebuild:
in /usr/portage/dev-java/gnu-classpath
Code: | # Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-java/gnu-classpath/gnu-classpath-0.98-r3.ebuild,v 1.10 2014/04/27 14:18:30 tomwij Exp $
EAPI=4
inherit eutils java-pkg-2 base multilib
MY_P=${P/gnu-/}
DESCRIPTION="Free core class libraries for use with virtual machines and compilers for the Java language"
SRC_URI="mirror://gnu/classpath/${MY_P}.tar.gz"
HOMEPAGE="http://www.gnu.org/software/classpath"
LICENSE="GPL-2-with-linking-exception"
SLOT="0.98"
KEYWORDS="amd64 ppc ppc64 x86 ~amd64-linux ~x86-linux ~x86-macos"
IUSE="alsa debug doc dssi examples gconf gjdoc gmp gtk gstreamer qt4 xml"
RDEPEND="alsa? ( media-libs/alsa-lib )
doc? ( >=dev-java/gjdoc-0.7.9-r2 )
dssi? ( >=media-libs/dssi-0.9 )
gconf? ( gnome-base/gconf )
gjdoc? ( >=dev-java/antlr-2.7.1:0 )
gmp? ( >=dev-libs/gmp-4.2.4 )
gstreamer? (
>=media-libs/gstreamer-0.10.10:0.10
>=media-libs/gst-plugins-base-0.10.10:0.10
x11-libs/gtk+:2
)
gtk? (
>=x11-libs/gtk+-2.8:2
>=dev-libs/glib-2.0
media-libs/freetype
>=x11-libs/cairo-1.1.9
x11-libs/libICE
x11-libs/libSM
x11-libs/libX11
x11-libs/libXrandr
x11-libs/libXrender
x11-libs/libXtst
x11-libs/pango
)
qt4? ( dev-qt/qtgui:4 )
xml? ( >=dev-libs/libxml2-2.6.8 >=dev-libs/libxslt-1.1.11 )"
# java-config >2.1.11 needed for ecj version globbing
# We should make the build not pickup the wrong antlr binary from pccts
DEPEND="app-arch/zip
dev-java/eclipse-ecj
>=dev-java/java-config-2.1.11
gjdoc? ( !!dev-util/pccts )
gtk? (
x11-libs/libXrender
|| ( >=x11-libs/libXtst-1.1.0 <x11-proto/xextproto-7.1 )
x11-proto/xproto
)
>=virtual/jdk-1.5
${RDEPEND}"
RDEPEND=">=virtual/jre-1.5
${RDEPEND}"
S=${WORKDIR}/${MY_P}
java_prepare() {
epatch "${FILESDIR}"/${PF}-freetype-2.5.3-support.patch
}
src_configure() {
# We require ecj anyway, so force it to avoid problems with bad versions of javac
export JAVAC="${EPREFIX}/usr/bin/ecj"
export JAVA="${EPREFIX}/usr/bin/java"
# build takes care of them itself, duplicate -source -target kills ecj
export JAVACFLAGS="-nowarn"
# build system is passing -J-Xmx768M which ecj however ignores
# this will make the ecj launcher do it (seen case where default was not enough heap)
export gjl_java_args="-Xmx768M"
# don't use econf, because it ends up putting things under /usr, which may
# collide with other slots of classpath
local myconf
if use gjdoc; then
local antlr=$(java-pkg_getjar antlr antlr.jar)
myconf="--with-antlr-jar=${antlr}"
fi
ANTLR= ./configure \
$(use_enable alsa) \
$(use_enable debug ) \
$(use_enable examples) \
$(use_enable gconf gconf-peer) \
$(use_enable gjdoc) \
$(use_enable gmp) \
$(use_enable gtk gtk-peer) \
$(use_enable gstreamer gstreamer-peer) \
$(use_enable qt4 qt-peer) \
$(use_enable xml xmlj) \
$(use_enable dssi ) \
$(use_with doc gjdoc) \
--enable-jni \
--disable-dependency-tracking \
--disable-plugin \
--host=${CHOST} \
--prefix="${EPREFIX}"/usr/${PN}-${SLOT} \
--with-ecj-jar=$(java-pkg_getjar --build-only eclipse-ecj-* ecj.jar) \
--disable-Werror \
${myconf}
}
src_install() {
emake DESTDIR="${D}" install
dodoc AUTHORS BUGS ChangeLog* HACKING NEWS README THANKYOU TODO
java-pkg_regjar /usr/${P}/share/classpath/glibj.zip
}
|
|
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Wed Apr 30, 2014 4:18 pm Post subject: |
|
|
Quote: | Is there perhaps something with the Portage tree itself, like wrong permissions? Sometimes such permission errors hide in the long sync output. You could consider to wipe the entire Portage tree and start over... |
I ran emerge --ask netbeans as root (pulling in GNU-Classpath). |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Wed Apr 30, 2014 4:28 pm Post subject: |
|
|
The ebuild looks good, is the eclass perhaps different; see /usr/portage/eclass/java-pkg-2.eclass and /usr/portage/eclass/java-utils-2.eclass which has
Code: | java-pkg-2_src_prepare() {
java-utils-2_src_prepare
}
java-utils-2_src_prepare() {
[[ ${EBUILD_PHASE} == prepare ]] &&
java-pkg_func-exists java_prepare && java_prepare
....
} |
that'll run the java_prepare function and therefore apply the patch.
Are you sure you still get the same build.log as the one you've attached in the bug with this ebuild?
If it is all fine, can you then attach /var/tmp/portage/dev-java/gnu-classpath-0.98-r3/temp/environment to the bug such that I can further investigate what's going on? |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Wed Apr 30, 2014 9:38 pm Post subject: |
|
|
Wow, thank you; as this is a stable ebuild we are required to do minimal changes and therefore no thorough review, it turns out that there is the rather uncommon base eclass on the inherit line that overrides the src_prepare function. Removal of the base eclass on that line fixes this, it wasn't used in the ebuild anyway; still I'm confused as to why we saw different results here, perhaps some difference elsewhere in the Portage stack.
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-java/gnu-classpath/gnu-classpath-0.98-r3.ebuild?r1=1.10&r2=1.11
Can you wait a few hours to let the mirrors update, then sync and try again? |
|
Back to top |
|
|
YPenguin Apprentice
Joined: 26 Apr 2014 Posts: 278 Location: Kenzingen, Germany
|
Posted: Thu May 01, 2014 9:54 am Post subject: Solved |
|
|
The problem with the GNU-Classpath should be solved now.
I installed Netbeans 8 today with no problems including GNU-Classpath as a dependency.
Netbeans seems to be running fine (I use Oracle JDK 7 as Java engine). |
|
Back to top |
|
|
|