FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 12-31-2009, 06:25 AM
Paul Johnson
 
Default stock openjdk vs. epel

On Fri, Jun 5, 2009 at 2:06 PM, Rex Dieter <rdieter@math.unl.edu> wrote:
> Rex Dieter wrote:
>
>> OK, found it, I'll go knock some skulls @ epel.
>
> Bug filed,
> https://bugzilla.redhat.com/show_bug.cgi?id=504189
>
> folks poked, hopefully will see a resolution soonish.
>
> -- Rex
>

Still no java browser plugin for Centos? I've been reading the web
all night on this, getting angry. I can't find any explanation about
why EPEL did have a working browser plugin, but then Centos introduced
versions of those same packages that had the plugin removed. Not to
mention the fact that Centos keeps the older version (b09) of
java-1.6.0, and yet yum seems to think it is a newer version.

So far, the only adequate approach I've found is to install the
java-1.6.0-openjdk packages that used to be in EPEL repositories.
Every yum update fails after that because yum tries to install the
versions from Centos updates, but those updates fail because they
don't satisfy the plugin requirement. That's not great because there
are some security fixes that come along with the Centos version.

It just seems silly to leave it this way. Are the experts just sick
of dealing with each other?

I've been looking at the SRPM files for the competing
java-1.6.0-openjdk packages from Centos and EPEL trying to figure how
to make a plugin package in the EPEL style but from the java base in
Centos.

Well, I'm sorry if these words are too critical. I appreciate the
efforts everyone has been making on this.

pj


--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2009, 12:43 PM
Mathieu Baudier
 
Default stock openjdk vs. epel

> Still no java browser plugin for Centos? *I've been reading the web
> all night on this, getting angry. *I can't find any explanation about
> why EPEL did have a working browser plugin, but then Centos introduced
> versions of those same packages that had the plugin removed. *Not to
> mention the fact that Centos keeps the older version (b09) of
> java-1.6.0, and yet yum seems to think it is a newer version.

Java support is indeed problematic as I pointed out in a recent thread
on this list (subject "Recent Java OpenJDK RPMs").
Don't get me wrong, I appreciate that RHEL supports specific certified
Java apps, but as soon as one wants to do more (e.g. developing Java
apps using recent Eclipse versions, see [1]...), it becomes
problematic.

Regarding your issue, currently my approach is to build the latest
version locally using the IcedTea build harness:
http://icedtea.classpath.org/wiki/RhelBuildInstructions

There is still a problem with the Java plugin on x86_64 though (see
[2], not happening on i386) and I build the other plugin using the
following configure command (to be adapted with your number of CPUs):

export JAVA_HOME=/usr/lib/jvm/java-1.6.0
./configure --with-openjdk --with-parallel-jobs=4 --enable-npplugin
export JAVA_HOME=
make

However see comments #7 and following of [1] for possible problems
with this plugin. It works ok for me for what I need (but very
slowly).

There was not much reaction on [2]. I strongly suspect that this is an
issue with how the x86_64 version of xulrunner is compiled (because of
the -fPIC error message). I haven't digged further yet, since the
other plugin satisfies my need.

/usr/bin/ld:
/usr/lib64/xulrunner-sdk-1.9/sdk/lib/libxpcomglue_s.a(nsThreadUtils.o):
relocation R_X86_64_PC32 against `nsIThreadManager::COMTypeInfo<int>::kIID' can
not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

Anyhow, I definitely need a recent OpenJDK RPM to go in production.
That's why I posted the previous thread ("Recent Java OpenJDK RPMs"):
I know that this won't be an easy task to do it myself, so I'm first
trying to identify similar efforts.

I did not know that there had been an EPEL packaged OpenJdk.
Would you be kind enough to point me to the SRPM you found?

I'll keep the list posted on my progress.
Comments and ideas more than welcome!

Cheers,

Mathieu

[1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=401
[2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=405
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2009, 01:14 PM
 
Default stock openjdk vs. epel

>> Still no java browser plugin for Centos? *I've been reading the web
>> all night on this, getting angry. *I can't find any explanation about
>> why EPEL did have a working browser plugin, but then Centos introduced
>> versions of those same packages that had the plugin removed. *Not to
>> mention the fact that Centos keeps the older version (b09) of
>> java-1.6.0, and yet yum seems to think it is a newer version.
>
> Java support is indeed problematic as I pointed out in a recent thread
> on this list (subject "Recent Java OpenJDK RPMs").
<snip>
> Regarding your issue, currently my approach is to build the latest
> version locally using the IcedTea build harness:
> http://icedtea.classpath.org/wiki/RhelBuildInstructions
<snip>
I agree with the original poster. Not having the java plugin is fine on
servers, but for users here who *do* use it as a desktop, my choices are
to either not update openjdk or install Sun's Java, which makes openjdk
pointless.

mark

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2009, 02:05 PM
Mathieu Baudier
 
Default stock openjdk vs. epel

> I agree with the original poster. Not having the java plugin is fine on
> servers, but for users here who *do* use it as a desktop, my choices are
> to either not update openjdk or install Sun's Java,

Indeed, installing Sun JDK is an alternative.
I already tried it with the following procedure:

sudo yum erase *gcj*
sudo yum erase *openjdk*
sudo sh jdk-6u17-linux-x64-rpm.bin

But then I had to:
sudo ln -s /usr/java/default/jre/lib/amd64/libnpjp2.so
/usr/lib64/mozilla/plugins/libnpjp2.so
in order to get the browser plugin to work (thanks to [1])

Did you face a similar issue?
Or did I do something wrong?

> which makes openjdk
> pointless.

Our policy is to use exclusively FLOSS software that we can possibly
rebuild, and are free to redistribute etc.
Especially for Java which is our main platform.
That's the point of OpenJdk for us. Unfortunately, as I put
previously, the provided implementation has blocking issues, even on
the server/headless side.

I do believe that with Java now GPL, Linux+Java can be a great platform.
But there are years of parallel development paths and, if I can put it
that way, mutual distrust, that need to be overcome.
So it is still a bit painful (but much much better than a few years ago!).

I have the feeling that Red Hat is supporting Java on the long term,
e.g. with their ownership of JBoss, and their contributions to
OpenJdk/IcedTea (for example the very interesting work of Gary Benson
on alternative architectures such as PPC, see [2]).

So I'm very excited to see how Java support will look like on RHEL/CentOS 6...

[1] http://blog.taragana.com/index.php/archive/how-to-install-enable-java-plugin-applets-in-firefox-on-centos-5/
[2] http://gbenson.net/
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2009, 06:36 PM
Paul Johnson
 
Default stock openjdk vs. epel

On Thu, Dec 31, 2009 at 8:14 AM, <m.roth@5-cent.us> wrote:
>>> Still no java browser plugin for Centos? *I've been reading the web
>>> all night on this, getting angry. *I can't find any explanation about
>>> why EPEL did have a working browser plugin, but then Centos introduced
>>> versions of those same packages that had the plugin removed. *Not to
>>> mention the fact that Centos keeps the older version (b09) of
>>> java-1.6.0, and yet yum seems to think it is a newer version.

> I agree with the original poster. Not having the java plugin is fine on
> servers, but for users here who *do* use it as a desktop, my choices are
> to either not update openjdk or install Sun's Java, which makes openjdk
> pointless.
>
> * * * mark
>

As luck would have it, I have copies of the java-1.6.0 b12 EPEL RPMS
that were offered before Centos added java-1.6.0 b09 as an "upgrade"
on my home page.

The SRPM is here

http://pj.freefaculty.org/Centos/5/i386/epel-source/packages

And the RPMS EPEL had offered are here

http://pj.freefaculty.org/Centos/5/i386/epel/packages

The RedHat/Centos version b09 is heavily patched for some security
things and also to disable the plugin (why??). The Epel version is
b12, newer, but not so security patched.


--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2009, 07:36 PM
R P Herrold
 
Default stock openjdk vs. epel

On Thu, 31 Dec 2009, Mathieu Baudier wrote:

> I do believe that with Java now GPL, Linux+Java can be a great platform.
> But there are years of parallel development paths and, if I can put it
> that way, mutual distrust, that need to be overcome.
> So it is still a bit painful (but much much better than a few years ago!).

A partial Java implementation, mostly GPLv2 -- see the
""CLASSPATH" EXCEPTION TO THE GPL" in the License file;
lacking in a FOSS conformance testing suite needed to
permit reproduceable testing of the result

It's not there yet; Sun's future is up in the air, and given
the pushback on the Innodb (prior Oracle acquisition, left to
largely rot since) backend / MySQL 'merger hold' concerns by
the EU's anti-trust review organ, it remains to be seen if
this will turn out well.

See also this post:
http://jeremy.zawodny.com/blog/archives/011481.html
by a rather prominent former Yahooian/MySQL maven

Ellison trotting the penguins out on the stage and being
tossed a softball question by the then-most prominent MSFT
covering analyst at Goldman Sachs, showed him as 'gaming'
Linux. Have you seen a lot of good and community oriented
support of OEL 2 out there since ORCL started using some
un-modified CentOS images in their SRPM rebuild efforts?

my $0.02

-- Russ herrold
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2009, 08:27 PM
Les Mikesell
 
Default stock openjdk vs. epel

Mathieu Baudier wrote:
>
> I do believe that with Java now GPL, Linux+Java can be a great platform.
> But there are years of parallel development paths and, if I can put it
> that way, mutual distrust, that need to be overcome.
> So it is still a bit painful (but much much better than a few years ago!).
>
> I have the feeling that Red Hat is supporting Java on the long term,
> e.g. with their ownership of JBoss, and their contributions to
> OpenJdk/IcedTea (for example the very interesting work of Gary Benson
> on alternative architectures such as PPC, see [2]).

Given that it could have been trivial to include Sun Java ages ago, or at least
not intentionally break the jpackage installation methods, I think Red Hat has
done more damage to java than any other company and don't see that turning
around even if they try at this late date.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-31-2009, 08:33 PM
John R Pierce
 
Default stock openjdk vs. epel

Les Mikesell wrote:
> Given that it could have been trivial to include Sun Java ages ago, or at least
> not intentionally break the jpackage installation methods, I think Red Hat has
> done more damage to java than any other company and don't see that turning
> around even if they try at this late date.
>

no, it wasn't trivial due to primarily licensing reasons.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 01-01-2010, 12:13 PM
Mathieu Baudier
 
Default stock openjdk vs. epel

> As luck would have it, I have copies of the java-1.6.0 b12 EPEL RPMS
> that were offered before Centos added java-1.6.0 b09 as an "upgrade"
> on my home page.

A lot of luck (or foresight...) indeed!

I used these old EPEL SRPMs + my experience of building the OpenJDK on
CentOS (see previous mails) in order to adapt the latest Fedora 12
OpenJdk SRPMs (Java 1.6.0 b16, using IcedTea 1.6).

It basically boils down to:
- remove visualvm and its netbeans dependency
- remove X11 patch
- workaround the plugin compilation issue (see previous mails) on
x86_64 (the EPEL SRPM was really helpful here)

You can download an SRPM from here:
http://www.argeo.org/linux/argeo-el/5/plus/SRPMS/
http://www.argeo.org/linux/argeo-el/5/plus/SRPMS/java-1.6.0-openjdk-1.6.0.0-33.b16.el5.argeo.1.src.rpm

And rebuild it with:
rpmbuild --rebuild java-1.6.0-openjdk-1.6.0.0-33.b16.el5.argeo.1.src.rpm
(after having properly set up your RPM build environment:
http://wiki.centos.org/HowTos/SetupRpmBuildEnvironment)

You need to have the EPEL repo installed.

I could build it and test it on x86_64 but not on i386 (I'm abroad
with my x86_64 laptop, and changing the --target did not work, I'll
have a look at it when I'm back in the office next week).

I'm currently uploading the x86_64 RPMs but my connection is very bad,
so it may take the whole day (or have to wait until next week as well
if it fails)

The spec file can be seen here:
https://www.argeo.org/svn/dependencies/trunk/org.argeo.dep.rpm/centos/java-1.6.0-openjdk/java-1.6.0-openjdk.spec

As well as the two original spec files I merged:
https://www.argeo.org/svn/dependencies/trunk/org.argeo.dep.rpm/centos/java-1.6.0-openjdk/java-1.6.0-openjdk-fedora.spec
https://www.argeo.org/svn/dependencies/trunk/org.argeo.dep.rpm/centos/java-1.6.0-openjdk/java-1.6.0-openjdk-epel.spec

(you will have to accept our autogenerated SSL certificate)

A few disclaimers/comments:
- free software, no warranty, etc.
- this upgrades the base java-1.6.0-openjdk package thus you are not
in line with upstream anymore if you install it (I am considering to
package a version which could be installed in parallel)
- this is my first serious SRPM hacking, so comments/critics from more
experienced people are welcome!
- we are upgrading our infrastructure so the links above are subject
to change within the next few months. I'll keep the list posted about
what becomes of this (either contributing it to a third party repo, or
host it if nobody wants it)
- the tests failed and I deactivated hem (just as the EPEL package did
at the time). At first sight, it has to do with X11, so maybe part of
the X11 patch is needed after all. I'll try to have a look someday
(lesser priority though since we don't do much AWT, so help would be
welcome here if it is deemed important)

Many thanks again for your help!

Cheers,

Mathieu
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 01-01-2010, 03:53 PM
Les Mikesell
 
Default stock openjdk vs. epel

John R Pierce wrote:
> Les Mikesell wrote:
>> Given that it could have been trivial to include Sun Java ages ago, or at least
>> not intentionally break the jpackage installation methods, I think Red Hat has
>> done more damage to java than any other company and don't see that turning
>> around even if they try at this late date.
>>
>
> no, it wasn't trivial due to primarily licensing reasons.

As it turned out, all they had to do to get the license of their choice was to
ask. Sun is (was...) responsible for more open source code than anyone. But,
Red Hat distributed Netscape back when they didn't like the license. And Debian
included Sun Java in the base distribution once redistribution was allowed where
Red Hat only put it in the update stream for paid subscribers. And in any case,
it would have been trivial to remain compatible with the jpackage nosrc rpms or
include them so users could deal with the license requirements without any other
hassles.

But the worst damage to java was from distributing a non-standard and mostly
non-working version. I doubt if that damage can be undone even if they are
actually willing now to distribute something that makes the OS irrelevant and
applications portable.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 09:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org