Hi,
There have been a few discussions about this in the past but no action. With feature freeze approaching for F21, I think this is a good time to address this.
I will be orphaning java-1.5.0-gcj in Fedora on April 8th. If anyone wants to take over, please let me know. Please do keep in mind though that we really should just remove GCJ (despite the effect it will have on pdftk) as preferred by one of the primary authors of it (Andrew Haley): https://lists.fedoraproject.org/pipermail/devel/2014-March/196535.html https://lists.fedoraproject.org/pipermail/devel/2014-March/196895.html https://lists.fedoraproject.org/pipermail/devel/2014-March/197157.html
Deepak
----- Original Message -----
From: "Deepak Bhole" dbhole@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, April 4, 2014 2:01:18 PM Subject: Orphaning java-1.5.0-gcj
Hi,
There have been a few discussions about this in the past but no action. With feature freeze approaching for F21, I think this is a good time to address this.
I will be orphaning java-1.5.0-gcj in Fedora on April 8th. If anyone wants to take over, please let me know.
Hi,
I've been quiet on this so far, but since we are finally at the "take action" point, I should chime in. I (jvanalte in FAS) am currently a committer for this package, but it is not useful to me and so I don't intend to take it over. In fact, I am not even interested in staying on as co-maintainer if someone else does take it over. Just didn't want anyone to have expectations otherwise. I tend to agree that its time has passed and would be happy to see it retired from Fedora.
cheers, jon
There have been a few discussions about this in the past but no action. With feature freeze approaching for F21, I think this is a good time to address this.
I will be orphaning java-1.5.0-gcj in Fedora on April 8th. If anyone wants to take over, please let me know. Please do keep in mind though that we really should just remove GCJ (despite the effect it will have on pdftk) as preferred by one of the primary authors of it (Andrew Haley):
How does this affect the bring up of new architectures, I seem to remember when doing the various variants of ARM we needed this for bringup of the newer releases, is that still the case or is there other means of achieving that?
Peter
On 04/07/2014 03:23 PM, Peter Robinson wrote:
There have been a few discussions about this in the past but no action. With feature freeze approaching for F21, I think this is a good time to address this.
I will be orphaning java-1.5.0-gcj in Fedora on April 8th. If anyone wants to take over, please let me know. Please do keep in mind though that we really should just remove GCJ (despite the effect it will have on pdftk) as preferred by one of the primary authors of it (Andrew Haley):
How does this affect the bring up of new architectures, I seem to remember when doing the various variants of ARM we needed this for bringup of the newer releases, is that still the case or is there other means of achieving that?
As of JDK8, OpenJDK can be cross-compiled. Not before time, either.
Andrew.
* Andrew Haley aph@redhat.com [2014-04-07 13:29]:
On 04/07/2014 03:23 PM, Peter Robinson wrote:
There have been a few discussions about this in the past but no action. With feature freeze approaching for F21, I think this is a good time to address this.
I will be orphaning java-1.5.0-gcj in Fedora on April 8th. If anyone wants to take over, please let me know. Please do keep in mind though that we really should just remove GCJ (despite the effect it will have on pdftk) as preferred by one of the primary authors of it (Andrew Haley):
How does this affect the bring up of new architectures, I seem to remember when doing the various variants of ARM we needed this for bringup of the newer releases, is that still the case or is there other means of achieving that?
As of JDK8, OpenJDK can be cross-compiled. Not before time, either.
Ownership released, package retired in rawhide. I accidentally hit retire on F20 as well. I'll get that addressed, as we will support it for the length for F19/20.
Deepak
Andrew.
On Mon, 2014-04-07 at 18:29 +0100, Andrew Haley wrote:
On 04/07/2014 03:23 PM, Peter Robinson wrote:
There have been a few discussions about this in the past but no action. With feature freeze approaching for F21, I think this is a good time to address this.
I will be orphaning java-1.5.0-gcj in Fedora on April 8th. If anyone wants to take over, please let me know. Please do keep in mind though that we really should just remove GCJ (despite the effect it will have on pdftk) as preferred by one of the primary authors of it (Andrew Haley):
How does this affect the bring up of new architectures, I seem to remember when doing the various variants of ARM we needed this for bringup of the newer releases, is that still the case or is there other means of achieving that?
As of JDK8, OpenJDK can be cross-compiled. Not before time, either.
Andrew.
I just got mails that this broke the lasso-java package I maintain. I do not know the java bindings much, I care only for the python bindings and the C library really, but I compiled the java bindings in if someone wanted to use it.
What is the path forward here ? Should I just drop the java bindings ? Or do I just get some other dependency in ? note I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage.
Simo.
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage.
You can't just "pull" packages. You'll have to properly "Obsoletes: lasso-java" it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh)
A side note: I believe we generally start release numbering at 1 instead of 0, but of course it doesn't hurt anything...
-- Stanislav Ochotnicky sochotnicky@redhat.com Software Engineer - Developer Experience
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On 14 April 2014 08:44, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage.
You can't just "pull" packages. You'll have to properly "Obsoletes: lasso-java" it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh)
Not "Requires: java-headless" ?
On Mon 14 Apr 2014 10:24:46 AM CEST Mat Booth wrote:
On 14 April 2014 08:44, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage.
You can't just "pull" packages. You'll have to properly "Obsoletes: lasso-java" it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh)
Not "Requires: java-headless" ?
Haha, you are right. I am violating guidelines I myself proposed :-) Aaaaa
-- Stanislav Ochotnicky sochotnicky@redhat.com Software Engineer - Developer Experience
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On Mon, 2014-04-14 at 09:24 +0100, Mat Booth wrote:
On 14 April 2014 08:44, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage.
You can't just "pull" packages. You'll have to properly "Obsoletes: lasso-java" it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh)
Not "Requires: java-headless" ?
It may be better I guess, I will change it before pushing a build unless someone tells me otherwise.
Simo.
Thanks a lot, I will push this patch and rebuild in rawhide.
Simo.
On Mon, 2014-04-14 at 09:44 +0200, Stanislav Ochotnicky wrote:
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage.
You can't just "pull" packages. You'll have to properly "Obsoletes: lasso-java" it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh)
A side note: I believe we generally start release numbering at 1 instead of 0, but of course it doesn't hurt anything...
differences between files attachment (0001-Use-OpenJDK-instead-of-GCJ-for-java-bindings.patch) From ef5fd12e46974858b25c2aa032e943514a0bf921 Mon Sep 17 00:00:00 2001 From: Stanislav Ochotnicky sochotnicky@redhat.com Date: Mon, 14 Apr 2014 09:42:19 +0200 Subject: [PATCH] Use OpenJDK instead of GCJ for java bindings
lasso.spec | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lasso.spec b/lasso.spec index e96e39b..d060cf0 100644 --- a/lasso.spec +++ b/lasso.spec @@ -11,7 +11,7 @@ Summary: Liberty Alliance Single Sign On Name: lasso Version: 2.4.0 -Release: 0%{?dist} +Release: 1%{?dist} License: GPLv2+ Group: System Environment/Libraries Source: https://dev.entrouvert.org/attachments/download/3874/lasso-2.4.0.tar.gz @@ -55,8 +55,10 @@ Perl language bindings for the lasso (Liberty Alliance Single Sign On) library. %package java Summary: Liberty Alliance Single Sign On (lasso) Java bindings Group: Development/Libraries -BuildRequires: java-devel, jpackage-utils -Requires: jre-gcj, jpackage-utils +BuildRequires: java-devel +BuildRequires: jpackage-utils +Requires: java +Requires: jpackage-utils Requires: %{name}%{?_isa} = %{version}-%{release}
%description java @@ -197,6 +199,9 @@ rm -fr %{buildroot}%{_defaultdocdir}/%{name} %endif
%changelog +* Mon Apr 14 2014 Stanislav Ochotnicky sochotnicky@redhat.com - 2.4.0-1 +- Use OpenJDK instead of GCJ for java bindings
- Sat Jan 11 2014 Simo Sorce simo@redhat.com 2.4.0-0
- Update to final 2.4.0 version
- Drop all patches, they are now included in 2.4.0
-- Stanislav Ochotnicky sochotnicky@redhat.com Software Engineer - Developer Experience
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On Mon, 2014-04-14 at 09:44 +0200, Stanislav Ochotnicky wrote:
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage.
You can't just "pull" packages. You'll have to properly "Obsoletes: lasso-java" it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh)
A side note: I believe we generally start release numbering at 1 instead of 0, but of course it doesn't hurt anything...
Ok the patch worked fine for building on my F20, which I did as a test, however it failed the build in rawhide.
The only clue I can get is this: configure: WARNING: unable to include <jni.h>
however I got the same warning in F20 w/o causing the build to fail.
Here build fails in the sense that the configure script thinks there is no java available at all and just skips building the jni stuff and then rpm fails to find the .so and .jar files.
Help ?
Simo.
On 04/14/2014 07:32 AM, Simo Sorce wrote:
Ok the patch worked fine for building on my F20, which I did as a test, however it failed the build in rawhide.
The only clue I can get is this: configure: WARNING: unable to include <jni.h>
What's in the configure log file regarding this?
Ok the patch worked fine for building on my F20, which I did as a test, however it failed the build in rawhide.
The only clue I can get is this: configure: WARNING: unable to include <jni.h>
What's in the configure log file regarding this?
This is solved now, AFAIK. The configure script had some custom code to detect Java version by parsing output of "java -version", which didn't work because OpenJDK >= 8 has slightly different output format.
An analogous change was needed in javapackages:
https://github.com/mizdebsk/javapackages/commit/494fea0
-- Mikolaj
On 04/07/2014 07:29 PM, Andrew Haley wrote:
As of JDK8, OpenJDK can be cross-compiled. Not before time, either.
It seems to me that support is fairly limited—you cannot compile Hotspot across different operating systems, but perhaps across CPU architectures.
In the context of GCJ obsolescence, it might be good enough, but it's still a bit disappointing.
On 04/30/2014 12:07 PM, Florian Weimer wrote:
On 04/07/2014 07:29 PM, Andrew Haley wrote:
As of JDK8, OpenJDK can be cross-compiled. Not before time, either.
It seems to me that support is fairly limited—you cannot compile Hotspot across different operating systems, but perhaps across CPU architectures.
I didn't know that. It makes some sense, though, given that differ OSs have different toolsets.
Andrew.
devel@lists.stg.fedoraproject.org
-
Andrew Haley -
Deepak Bhole -
Florian Weimer -
Jon VanAlten -
Mat Booth -
Mikolaj Izdebski -
Peter Robinson -
Samuel Sieb -
Simo Sorce -
Stanislav Ochotnicky