3:01 p.m.
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
3:23 p.m.
----- Original Message -----
From: "Deepak Bhole" <dbhole(a)redhat.com>
To: devel(a)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
9:23 a.m.
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
12:29 p.m.
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.
1 p.m.
* Andrew Haley <aph(a)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.
1:42 p.m.
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.
--
Simo Sorce * Red Hat, Inc * New York
2:44 a.m.
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(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
3:24 a.m.
On 14 April 2014 08:44, Stanislav Ochotnicky <sochotnicky(a)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" ?
--
Mat Booth
http://fedoraproject.org/get-fedora
3:31 a.m.
On Mon 14 Apr 2014 10:24:46 AM CEST Mat Booth wrote:
On 14 April 2014 08:44, Stanislav Ochotnicky
<sochotnicky(a)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(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
8:47 a.m.
On Mon, 2014-04-14 at 09:24 +0100, Mat Booth wrote:
On 14 April 2014 08:44, Stanislav Ochotnicky
<sochotnicky(a)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.
--
Simo Sorce * Red Hat, Inc * New York
8:38 a.m.
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(a)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(a)redhat.com> - 2.4.0-1
+- Use OpenJDK instead of GCJ for java bindings
+
* Sat Jan 11 2014 Simo Sorce <simo(a)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(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
Simo Sorce * Red Hat, Inc * New York
9:32 a.m.
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.
--
Simo Sorce * Red Hat, Inc * New York
2:33 p.m.
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?
2:23 a.m.
> 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
6:07 a.m.
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.
--
Florian Weimer / Red Hat Product Security Team
4:16 a.m.
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.
3641
days inactive
3668
days old
15 comments
10 participants
participants (10)
-
Andrew Haley -
Deepak Bhole -
Florian Weimer -
Jon VanAlten -
Mat Booth -
Mikolaj Izdebski -
Peter Robinson -
Samuel Sieb -
Simo Sorce -
Stanislav Ochotnicky