[gentoo-java] migration-overlay entering main tree

[gentoo-java] migration-overlay entering main tree

[Joshua Nichols]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Over this past weekend, I put migration-overlay into the main tree:

Everything related to it is currently sitting in package.mask:

# Joshua Nichols<nichoj@gentoo.org> (24 Jun 2006)
# Masked for testing changes to Java
> >=dev-java/java-config-1.3
dev-java/java-config-wrapper
> >dev-java/javatoolkit-0.1.0
> >=dev-java/ant-core-1.6.5-r13
> >=dev-java/ant-tasks-1.6.5-r2
> >=dev-java/jikes-1.22-r12
> >=dev-java/eclipse-ecj-3.1-r13
=dev-java/blackdown-jdk-1.3.1-r23
=dev-java/blackdown-jdk-1.4.1-r12
=dev-java/blackdown-jdk-1.4.2.03-r12
=dev-java/blackdown-jre-1.3.1-r20
=dev-java/blackdown-jre-1.4.1-r12
=dev-java/blackdown-jre-1.4.2.03-r11
=dev-java/ibm-jdk-bin-1.4.2.04-r10
=dev-java/ibm-jdk-bin-1.5.0-r11
=dev-java/ibm-jre-bin-1.4.2.05
=dev-java/jrockit-jdk-bin-1.4.2.10
=dev-java/jrockit-jdk-bin-1.5.0.06
=dev-java/kaffe-1.1.7
=dev-java/sun-jdk-1.4.2.12
=dev-java/sun-jdk-1.5.0.07
=dev-java/sun-jre-bin-1.4.2.12
=dev-java/sun-jre-bin-1.5.0.07



To try it out, add the above entry to /etc/portage/package.unmask.

If you were already using migration-overlay, you'll want to remove it
from PORTDIR_OVERLAY.

If you weren't, you'll need to follow the instructions at:
http://www.gentoo.org/proj/en/java/java-upgrade.xml

I would like to unmask these packages in the next few days. At that
point, I'd like to 'officially' announce it, as in put it on the front
page, send to -announce, etc.

- - Josh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEnwIP8ATTzZyw6sMRAmDxAJ9hhm5+wz5naNhd0A1dK7CK3DFdtgCeMk0l
o3eKCNjaFqpMP/r9bvUb1+0=
=y5Il
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Greg Tassone]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

On Sun, 2006-06-25 at 16:37 -0500, Joshua Nichols wrote:
> Over this past weekend, I put migration-overlay into the main tree:
> 
> Everything related to it is currently sitting in package.mask:

Thanks for doing this, and for the E-mail update.  I've been noticing
the changes in migration-overlay this weekend. :-)

FYI:  For some reason (at least in my mail client) some extra chars
(like this: "> ") appear at the beginning of a few lines in your list
(below).  Folks should be aware that certain packages won't be visible
unless they remove these extra characters from the front of the
applicable lines.

The corrected list should appear something like this:

#----------------------------------------
# Joshua Nichols<nichoj@gentoo.org> (24 Jun 2006)
# Masked for testing changes to Java
>=dev-java/java-config-1.3
dev-java/java-config-wrapper
>dev-java/javatoolkit-0.1.0
>=dev-java/ant-core-1.6.5-r13
>=dev-java/ant-tasks-1.6.5-r2
>=dev-java/jikes-1.22-r12
>=dev-java/eclipse-ecj-3.1-r13
=dev-java/blackdown-jdk-1.3.1-r23
=dev-java/blackdown-jdk-1.4.1-r12
=dev-java/blackdown-jdk-1.4.2.03-r12
=dev-java/blackdown-jre-1.3.1-r20
=dev-java/blackdown-jre-1.4.1-r12
=dev-java/blackdown-jre-1.4.2.03-r11
=dev-java/ibm-jdk-bin-1.4.2.04-r10
=dev-java/ibm-jdk-bin-1.5.0-r11
=dev-java/ibm-jre-bin-1.4.2.05
=dev-java/jrockit-jdk-bin-1.4.2.10
=dev-java/jrockit-jdk-bin-1.5.0.06
=dev-java/kaffe-1.1.7
=dev-java/sun-jdk-1.4.2.12
=dev-java/sun-jdk-1.5.0.07
=dev-java/sun-jre-bin-1.4.2.12
=dev-java/sun-jre-bin-1.5.0.07
#---------------------------------------

Another note:  You list sun-jdk-1.5.0.07 and my system does have it
installed (it appeared in migration-overlay a week or two ago).
However, the ebuild appears to have been deleted from the overlay and it
is NOT anywhere in the main Portage tree.  Unless you still need to add
it something must have gone wrong.  Just FYI...


> I would like to unmask these packages in the next few days. At that
> point, I'd like to 'officially' announce it, as in put it on the front
> page, send to -announce, etc.

Sounds good to me.  They seem to be working well so my vote is "the
sooner the better".

Thanks again for all of the hard work!

~ Greg T.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-java] migration-overlay entering main tree

[Joshua Nichols]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Tassone wrote:
> FYI:  For some reason (at least in my mail client) some extra chars
> (like this: "> ") appear at the beginning of a few lines in your list
> (below).  Folks should be aware that certain packages won't be visible
> unless they remove these extra characters from the front of the
> applicable lines.
> 
- -snip-
Yeah, I noticed that after sending it. Of course, you can look at
/usr/portage/profiles/package.mask, and pull the appropriate entries
from there.

> 
> Another note:  You list sun-jdk-1.5.0.07 and my system does have it
> installed (it appeared in migration-overlay a week or two ago).
> However, the ebuild appears to have been deleted from the overlay and it
> is NOT anywhere in the main Portage tree.  Unless you still need to add
> it something must have gone wrong.  Just FYI...
There's a lag between when something gets committed to CVS, and when it
propogates to all the rsync mirrors.

> 
> Sounds good to me.  They seem to be working well so my vote is "the
> sooner the better".
Indeed. I mostly want to make sure everything got into place fine. So...
to help with this, I ask everyone try re-merging the packages formally
in the overlay (now in the package.mask), to make sure all the distfiles
and packages are there, and that the system continues to work.

- - Josh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEnxVg8ATTzZyw6sMRAjpeAJ9CYdFgfUNnmJsIYkmNAlO1qDL8eQCggOLL
3CYTo5PFYcQwkeT7UhbphIQ=
=9JDa
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Caster]

Joshua Nichols wrote:
> Indeed. I mostly want to make sure everything got into place fine. So...
> to help with this, I ask everyone try re-merging the packages formally
> in the overlay (now in the package.mask), to make sure all the distfiles
> and packages are there, and that the system continues to work.
> 

Missing ebuilds in the tree (checked also
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-java/ and not there
either, so I guess not rsync lag problem?)

dev-java/ant-tasks-1.6.5-r2
ibm-jdk-bin 1.4.2.05 and 1.5.0.02 (were my bumps bad?) - the existing
1.5.0-r11 has broken digest because IBM changed the files (bug 130533)

Missing distfile/wrong version? of java-config-wrapper (bug 138015)

I think many people get the whole migration stuff pulled just because
they used java 1.5 faq to have 1.5 VM with generation-1. It tells you to
# echo "=dev-java/sun-jdk-1.5*" >> /etc/portage/package.unmask
which overrides your package.mask for 1.5.0.07 which then tries to pull
everything... Well at least more testers for us :)

Caster

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Caster]

Joshua Nichols wrote:
> Indeed. I mostly want to make sure everything got into place fine. So...
> to help with this, I ask everyone try re-merging the packages formally
> in the overlay (now in the package.mask), to make sure all the distfiles
> and packages are there, and that the system continues to work.

Oops, another problem, missing patch in files dir?

>>> Emerging (4 of 22) dev-java/ant-core-1.6.5-r13 to /
>>> checking ebuild checksums ;-)
>>> checking auxfile checksums ;-)
>>> checking miscfile checksums ;-)
>>> checking apache-ant-1.6.5-src.tar.bz2 ;-)
 * Using: sun-jdk-1.5
>>> Unpacking source...
>>> Unpacking apache-ant-1.6.5-src.tar.bz2 to
/var/tmp/portage/ant-core-1.6.5-r13/work

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
 *   /usr/portage/dev-java/ant-core/files/build.sh-exit-fix.patch.gz
 *   ( build.sh-exit-fix.patch.gz )


!!! ERROR: dev-java/ant-core-1.6.5-r13 failed.
Call stack:
  ebuild.sh, line 1540:   Called dyn_unpack
  ebuild.sh, line 711:   Called src_unpack
  ebuild.sh, line 1249:   Called java-ant-2_src_unpack
  java-ant-2.eclass, line 73:   Called ant_src_unpack
  ant-core-1.6.5-r13.ebuild, line 33:   Called epatch
'/usr/portage/dev-java/ant-core/files/build.sh-exit-fix.patch.gz'
  eutils.eclass, line 192:   Called die

!!! Cannot find $EPATCH_SOURCE!
!!! If you need support, post the topmost build error, and the call
stack if relevant.

!!! When you file a bug report, please include the following information:
GENTOO_VM=sun-jdk-1.5  CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.5.0.07"
JAVACFLAGS="-source 1.4 -target 1.4" COMPILER=""
and of course, the output of emerge --info


Caster
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Joshua Nichols]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Caster wrote:
> Joshua Nichols wrote:
>> Indeed. I mostly want to make sure everything got into place fine. So...
>> to help with this, I ask everyone try re-merging the packages formally
>> in the overlay (now in the package.mask), to make sure all the distfiles
>> and packages are there, and that the system continues to work.
>>
> 
> Missing ebuilds in the tree (checked also
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-java/ and not there
> either, so I guess not rsync lag problem?)
> 
> dev-java/ant-tasks-1.6.5-r2
> ibm-jdk-bin 1.4.2.05 and 1.5.0.02 (were my bumps bad?) - the existing
> 1.5.0-r11 has broken digest because IBM changed the files (bug 130533)

Whoops. Was sitting uncommitted in my tree. Should be fixed in CVS, and
will take a bit to propogate.

> Missing distfile/wrong version? of java-config-wrapper (bug 138015)

Fixed in CVS too.

> I think many people get the whole migration stuff pulled just because
> they used java 1.5 faq to have 1.5 VM with generation-1. It tells you to
> # echo "=dev-java/sun-jdk-1.5*" >> /etc/portage/package.unmask
> which overrides your package.mask for 1.5.0.07 which then tries to pull
> everything... Well at least more testers for us :)

That's what you get for using package.mask stuff without using precise
verion atoms :-D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEn8jz8ATTzZyw6sMRAvMnAJ4l3QXChk5qzRvuNGaU0ai/T1PP1wCdF119
8nfXHsTq6KlLKoTgWKQQ6/E=
=Vx1p
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Joshua Nichols]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Caster wrote:
> Joshua Nichols wrote:
>> Indeed. I mostly want to make sure everything got into place fine. So...
>> to help with this, I ask everyone try re-merging the packages formally
>> in the overlay (now in the package.mask), to make sure all the distfiles
>> and packages are there, and that the system continues to work.
> 
> Oops, another problem, missing patch in files dir?
> 
>>>> Emerging (4 of 22) dev-java/ant-core-1.6.5-r13 to /
>>>> checking ebuild checksums ;-)
>>>> checking auxfile checksums ;-)
>>>> checking miscfile checksums ;-)
>>>> checking apache-ant-1.6.5-src.tar.bz2 ;-)
>  * Using: sun-jdk-1.5
>>>> Unpacking source...
>>>> Unpacking apache-ant-1.6.5-src.tar.bz2 to
> /var/tmp/portage/ant-core-1.6.5-r13/work
> 
>  * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
>  *
>  *   /usr/portage/dev-java/ant-core/files/build.sh-exit-fix.patch.gz
>  *   ( build.sh-exit-fix.patch.gz )
> 
> 
> !!! ERROR: dev-java/ant-core-1.6.5-r13 failed.
> Call stack:
>   ebuild.sh, line 1540:   Called dyn_unpack
>   ebuild.sh, line 711:   Called src_unpack
>   ebuild.sh, line 1249:   Called java-ant-2_src_unpack
>   java-ant-2.eclass, line 73:   Called ant_src_unpack
>   ant-core-1.6.5-r13.ebuild, line 33:   Called epatch
> '/usr/portage/dev-java/ant-core/files/build.sh-exit-fix.patch.gz'
>   eutils.eclass, line 192:   Called die
> 
> !!! Cannot find $EPATCH_SOURCE!
> !!! If you need support, post the topmost build error, and the call
> stack if relevant.
> 
> !!! When you file a bug report, please include the following information:
> GENTOO_VM=sun-jdk-1.5  CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.5.0.07"
> JAVACFLAGS="-source 1.4 -target 1.4" COMPILER=""
> and of course, the output of emerge --info
> 
> 
> Caster

Fixed as well. It seems that at some point, the patch was gzipped living
in filss/. This generally a bad thing (tm), and was fixed at some point
_after_ it was pulled into axxo-overlay way back when, so it was still
pointing to the gzipped version.

- - Josh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEn8lI8ATTzZyw6sMRAr85AJ9vRPXVzEnlQcSuIl8OX7q+fCzaxgCfZJMI
meQW8FtMRaSFU7zsVC5+/SQ=
=HWys
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Ivan Yosifov]

Am Montag, 26. Juni 2006 00:37 schrieb Joshua Nichols:
> Over this past weekend, I put migration-overlay into the main tree:
>
> Everything related to it is currently sitting in package.mask:
>
> # Joshua Nichols<nichoj@gentoo.org> (24 Jun 2006)
> # Masked for testing changes to Java
>
> > >=dev-java/java-config-1.3
>
> dev-java/java-config-wrapper
>
> > >dev-java/javatoolkit-0.1.0
> > >=dev-java/ant-core-1.6.5-r13
> > >=dev-java/ant-tasks-1.6.5-r2
> > >=dev-java/jikes-1.22-r12
> > >=dev-java/eclipse-ecj-3.1-r13
>
> =dev-java/blackdown-jdk-1.3.1-r23
> =dev-java/blackdown-jdk-1.4.1-r12
> =dev-java/blackdown-jdk-1.4.2.03-r12
> =dev-java/blackdown-jre-1.3.1-r20
> =dev-java/blackdown-jre-1.4.1-r12
> =dev-java/blackdown-jre-1.4.2.03-r11
> =dev-java/ibm-jdk-bin-1.4.2.04-r10
> =dev-java/ibm-jdk-bin-1.5.0-r11
> =dev-java/ibm-jre-bin-1.4.2.05
> =dev-java/jrockit-jdk-bin-1.4.2.10
> =dev-java/jrockit-jdk-bin-1.5.0.06
> =dev-java/kaffe-1.1.7
> =dev-java/sun-jdk-1.4.2.12
> =dev-java/sun-jdk-1.5.0.07
> =dev-java/sun-jre-bin-1.4.2.12
> =dev-java/sun-jre-bin-1.5.0.07
>
>
>
> To try it out, add the above entry to /etc/portage/package.unmask.
>
> If you were already using migration-overlay, you'll want to remove it
> from PORTDIR_OVERLAY.
>
> If you weren't, you'll need to follow the instructions at:
> http://www.gentoo.org/proj/en/java/java-upgrade.xml
>
> I would like to unmask these packages in the next few days. At that
> point, I'd like to 'officially' announce it, as in put it on the front
> page, send to -announce, etc.
>
> - Josh

By the way, will you be mergeing migration-packages to the main tree too ?

-- 
Cheers,
Ivan Yosifov.
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Joshua Nichols]

Ivan Yosifov wrote:
> By the way, will you be mergeing migration-packages to the main tree too ?

Not immediately, and not at once. migration-packages is essentially the
same as java-experimental, except it is using the new eclasses and
tools. So, once we're over the initial bump of the merge, we will resume
regular version bumps / bug fixing / introducing new packages.

Josh
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Caster]

Just some cosmetic stuff I've run into, not deserves a bug (or even 3
bugs) I guess :)

- java-check-environment says "Please refer to
https://projects.gentooexperimental.org/expj/wiki/ for details" - this
should point to http://www.gentoo.org/proj/en/java/java-upgrade.xml now
I think?

- as we talked on IRC, java-config-1 -s should now refuse to set user
vm, and probably all JRE's could drop gen-1 env because they can't be
used for building anyway

- when user runs e.g. javac with a JRE, he gets:

javac
Want too run
/home/caster/.gentoo/java-config-2/current-user-vm//{,jre}/bin/javac but
it does not exist or is not executable
Broken vm install

Maybe make this more user friendly? Fix typo "want too" and change to
something like "Broken VM installation or you are trying to use JDK
functionality (e.g. compiling) from JRE."

Caster
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Wiktor Wandachowicz]

Well, I unmasked the packages and tried to do the dumbest thing
under the Sun (pun intended): upgrade the system WITHOUT reading
the migration guide ;). I believe this is something that quite a bit of
[careless] users would do. I expected problems, but in the end I've
found none (!)

And I really like the new java-config working in the "old" fashion too :)
It hides the java-config-1 / java-config-2 complexity from the less
knowledgeable users.

Great job, guys!


Here's the overview of steps taken:


# emerge -pvuD sun-jdk

These are the packages that would be merged, in order:

Calculating dependencies... done!
[blocks B     ] <dev-java/java-config-1.3 (is blocking
dev-java/java-config-wrapper-0.9-r2)
[ebuild     U ] perl-core/Test-Harness-2.62 [2.56] USE="-minimal" 0 kB
[ebuild  N    ] dev-java/java-config-wrapper-0.9-r2  0 kB
[ebuild  NS   ] dev-java/java-config-2.0.24  0 kB
[ebuild     U ] dev-java/java-config-1.3.0-r2 [1.2.11-r1] 0 kB
[ebuild     U ] app-admin/eselect-compiler-2.0.0_rc2-r1 [2.0.0_rc2]
USE="-hardened" 0 kB
[ebuild    fU ] dev-java/sun-jdk-1.5.0.07 [1.5.0.06-r2] USE="X alsa
doc nsplugin -jce" 0 kB

Total size of downloads: 0 kB

# emerge -C java-config

# emerge -avuD sun-jdk

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] perl-core/Test-Harness-2.62 [2.56] USE="-minimal" 0 kB
[ebuild  N    ] dev-java/java-config-wrapper-0.9-r2  0 kB
[ebuild  N    ] dev-java/java-config-2.0.24  0 kB
[ebuild  N    ] dev-java/java-config-1.3.0-r2  0 kB
[ebuild     U ] app-admin/eselect-compiler-2.0.0_rc2-r1 [2.0.0_rc2]
USE="-hardened" 0 kB
[ebuild    fU ] dev-java/sun-jdk-1.5.0.07 [1.5.0.06-r2] USE="X alsa
doc nsplugin -jce" 0 kB

Total size of downloads: 0 kB

Would you like to merge these packages? [Yes/No]

... all went well ...

# java -version
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_07-b03, mixed mode)

# javac -version
javac 1.5.0_07
javac: no source files
Usage: javac <options> <source files>

# which java
/usr/bin/java

# which javac
/usr/bin/javac

# java-config -L
*) Sun JDK 1.5.0.07 [sun-jdk-1.5] (/usr/share/java-config-2/vm/sun-jdk-1.5)


So, the dumbest case seems to be covered. I hope this helps :)

Now I'm looking into setting a sun-jdk-1.4.2 on amd64 as the system
and/or build VM. I *know* it's not meant to be used as a Java plugin for
64-bit firefox, but it could be used for 32-bit firefox-bin. And with multilib
profile in place and emul-* libraries it should work without problems.
I will send an update on this case soon.

Cheers,
Wiktor
-- 
Registered Linux user #390131 (http://counter.li.org)
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Wiktor Wandachowicz]

> Now I'm looking into setting a sun-jdk-1.4.2 on amd64 as the system
> and/or build VM. I *know* it's not meant to be used as a Java plugin for
> 64-bit firefox, but it could be used for 32-bit firefox-bin. And with multilib
> profile in place and emul-* libraries it should work without problems.
> I will send an update on this case soon.

Ok, so here's the update.

I have firefox-bin installed on amd64 architecture. It works, but uses the
Blackdown JDK 1.4.2 in form of emul-linux-x86-java-1.4.2.03-r1 package.
This package puts a link to its Java plugin for 32-bit Firefox in
/usr/lib32/nsbrowser/plugins directory.

As I already mentioned on the Forums [1] it's possible to run 32-bit
Firefox in 64-bit environment with 32-bit Java plug-in from sun-jdk-1.4.2.

Here's what I did:

echo "=dev-java/sun-jdk-1.4.2* doc jce -nsplugin" >> /etc/portage/package.use
echo "=app-emulation/emul-linux-x86-java-1.4* -nsplugin" >>
/etc/portage/package.use
emerge -av emul-linux-x86  # to get rid of Blackdown Java plugin
emerge -av =sun-jdk-1.4*
mkdir -p /usr/lib32/nsbrowser/plugins
cd /usr/lib32/nsbrowser/plugins
ln -s /opt/sun-jdk-1.4.2.12/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so

After restarting firefox-bin in its about:config I was happy to see:

  Java(TM) Plug-in 1.4.2_12-b03

instead of Blackdown's. So I did it again ;)

Now, the questions. Could it be possible to support 32-bit sun-jdk in amd64
environment for 32-bit firefox-bin (only)? In a way similar to the
emul-linux-x86
package does? I know how to handle that situation manually, but it's not the
optimal solution (or did I miss something?)

Cheers,
Wiktor

[1] http://forums.gentoo.org/viewtopic-t-416912.html

--
Registered Linux user #390131 (http://counter.li.org)
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Joshua Nichols]

Caster wrote:
> Just some cosmetic stuff I've run into, not deserves a bug (or even 3
> bugs) I guess :)
>
> - java-check-environment says "Please refer to
> https://projects.gentooexperimental.org/expj/wiki/ for details" - this
> should point to http://www.gentoo.org/proj/en/java/java-upgrade.xml now
> I think?
>
>   
Fixed.
> - as we talked on IRC, java-config-1 -s should now refuse to set user
> vm, and probably all JRE's could drop gen-1 env because they can't be
> used for building anyway
>   
I think it's probably a good thing, but I'm not fluent in python enough
to patch it up.
> - when user runs e.g. javac with a JRE, he gets:
>
> javac
> Want too run
> /home/caster/.gentoo/java-config-2/current-user-vm//{,jre}/bin/javac but
> it does not exist or is not executable
> Broken vm install
>
> Maybe make this more user friendly? Fix typo "want too" and change to
> something like "Broken VM installation or you are trying to use JDK
> functionality (e.g. compiling) from JRE."
>
>   
Wording should be better with java-config-2.0.25.
> Caster
>   

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Wiktor Wandachowicz]

Here are my experiences with Java upgrade on a second machine, done step
after step like in the Java Upgrade Guide. Sorry for the length, but I wanted
to be as specific as possible.

After unmasking packages, I removed sun-jdk-1.4*, sun-jdk-1.5* and java-config.
Then I emerged java-config-1* and java-config-2*. All was fine. After emerging
the first JVM I've noticed an error:

# emerge -av =sun-jdk-1.4*
...
!!! ERROR: The active vm could not be found
 *  After installing sun-jdk-1.4.2.12 this
 *  was set as the default JVM to run.
 * No valid generation-1 system-vm set, setting to sun-jdk-1.4.2.12

Nothing serious that a simple "/usr/sbin/env-update && source /etc/profile"
couldn't resolve. And only after two last commands the "java-check-environment"
was able to report success with generation_1_system_vm. I double checked
via "java-config-1 -L" and "java-config-2 -L" that only one JVM was present at
the moment. All was fine.

Then I emerged sun-jdk-1.5 and run the "java-1.5-fixer". Now it became
interesting, because the tool reported *twice* missing packages:

# java-1.5-fixer
 * You need to emerge portage-utils.
# emerge -av portage-utils
 * You need to emerge >=javatoolkit-0.1.6
# emerge -av javatoolkit
# java-1.5-fixer

Well, that's was a little surprise, because the Guide didn't mention these
two packages at all. Not actually confusing for me, but the Guide could at
least explain that need. Less fluent Gentooers can be surprised and
completely unnecessary topics on the forums may arise.

Another intriguing thing was the output while emerging javatoolkit. I've seen:
...
>>> /usr/share/doc/javatoolkit-9.9.9/
>>> /usr/share/doc/javatoolkit-9.9.9/sun-fetch/
>>> /usr/share/doc/javatoolkit-9.9.9/sun-fetch/AUTHORS
>>> /usr/share/doc/javatoolkit-9.9.9/sun-fetch/README
>>> /usr/share/doc/javatoolkit-9.9.9/COPYING
>>> /usr/share/doc/javatoolkit-9.9.9/NEWS
>>> /usr/share/doc/javatoolkit-9.9.9/findclass/
>>> /usr/share/doc/javatoolkit-9.9.9/findclass/AUTHORS
>>> /usr/share/doc/javatoolkit-9.9.9/findclass/README
>>> /usr/share/doc/javatoolkit-9.9.9/AUTHORS
>>> /usr/share/doc/javatoolkit-9.9.9/README
>>> /usr/share/doc/javatoolkit-9.9.9/ChangeLog
>>> /usr/share/doc/javatoolkit-9.9.9/TODO

even though I installed javatoolkit-0.1.9 and not -0.9.9

Last problematic thing I've noticed was the number and order of
packages java-fixer was about to repair:

# java-1.5-fixer
 * Generating a list of jars which ant uses ...                          [ ok ]
 * Checking for > 1.4 bytecode in ant jars ...                           [ ok ]
 * Generating a list of jars in the system ...                           [ ok ]
 * Checking for > 1.4 bytecode in system jars ...                        [ ok ]
 * Attempting to fix broken packages ...
 * Packages to fix this run:
=dev-db/hsqldb-1.7.3.1-r2 =dev-db/hsqldb-1.7.3.1-r2
=dev-db/hsqldb-1.7.3.1-r2 =dev-java/servletapi-2.3-r2
=sys-libs/db-4.3.29

I turned out that even though hsqldb was listed three times, it still
depended on servletapi, which was scheduled fourth. So it broke:

classes:
    [javac] Compiling 111 source files to
/var/tmp/portage/hsqldb-1.7.3.1-r2/work/hsqldb/classes
    [javac] /var/tmp/portage/hsqldb-1.7.3.1-r2/work/hsqldb/src/org/hsqldb/Servlet.java:73:
cannot access javax.servlet.ServletConfig
    [javac] bad class file:
/var/tmp/portage/hsqldb-1.7.3.1-r2/work/hsqldb/lib/servlet.jar(javax/servlet/ServletConfig.class)
    [javac] class file has wrong version 49.0, should be 48.0
    [javac] Please remove or make sure it appears in the correct
subdirectory of the classpath.
    [javac] import javax.servlet.ServletConfig;
    [javac]                      ^
    [javac] 1 error

I needed to remerge servletapi manually and restart java-1.5-fixer. Which,
of course, built hsqldb three times :-( Which was, of course, unnecessary.
How about at least making the packages that java-1.5-fixer is going to fix
unique? And how about figuring a better ordering of packages?

After all the above I think I've finally migrated my machine to Generation-2.
Whoopiee!

In general all was fun and problems were minor IMHO. But migration was
not automatic, like some users would like it to see. Maybe some things
coul dbe improved before stabilization?

HTH,
Wiktor Wandachowicz

-- 
Registered Linux user #390131 (http://counter.li.org)
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] migration-overlay entering main tree

[Joshua Nichols]

Wiktor Wandachowicz wrote:
>
> Then I emerged sun-jdk-1.5 and run the "java-1.5-fixer". Now it became
> interesting, because the tool reported *twice* missing packages:
>
> # java-1.5-fixer
> * You need to emerge portage-utils.
> # emerge -av portage-utils
> * You need to emerge >=javatoolkit-0.1.6
> # emerge -av javatoolkit
> # java-1.5-fixer
>
> Well, that's was a little surprise, because the Guide didn't mention
> these
> two packages at all. Not actually confusing for me, but the Guide
> could at
> least explain that need. Less fluent Gentooers can be surprised and
> completely unnecessary topics on the forums may arise.
>

Granted, the messages could be improved a bit. It's not mentioned in the
guide, because a) java-1.5-fixer may not be required and b) it's pretty
straight forward to emerge these if you don't have them.

> Another intriguing thing was the output while emerging javatoolkit.
> I've seen:
> ...
>>>> /usr/share/doc/javatoolkit-9.9.9/
>>>> /usr/share/doc/javatoolkit-9.9.9/sun-fetch/
>>>> /usr/share/doc/javatoolkit-9.9.9/sun-fetch/AUTHORS
>>>> /usr/share/doc/javatoolkit-9.9.9/sun-fetch/README
>>>> /usr/share/doc/javatoolkit-9.9.9/COPYING
>>>> /usr/share/doc/javatoolkit-9.9.9/NEWS
>>>> /usr/share/doc/javatoolkit-9.9.9/findclass/
>>>> /usr/share/doc/javatoolkit-9.9.9/findclass/AUTHORS
>>>> /usr/share/doc/javatoolkit-9.9.9/findclass/README
>>>> /usr/share/doc/javatoolkit-9.9.9/AUTHORS
>>>> /usr/share/doc/javatoolkit-9.9.9/README
>>>> /usr/share/doc/javatoolkit-9.9.9/ChangeLog
>>>> /usr/share/doc/javatoolkit-9.9.9/TODO
>
> even though I installed javatoolkit-0.1.9 and not -0.9.9
Freaky. I can't say that I've seen that before.

>
> Last problematic thing I've noticed was the number and order of
> packages java-fixer was about to repair:
>
> # java-1.5-fixer
> * Generating a list of jars which ant uses
> ...                          [ ok ]
> * Checking for > 1.4 bytecode in ant jars
> ...                           [ ok ]
> * Generating a list of jars in the system
> ...                           [ ok ]
> * Checking for > 1.4 bytecode in system jars
> ...                        [ ok ]
> * Attempting to fix broken packages ...
> * Packages to fix this run:
> =dev-db/hsqldb-1.7.3.1-r2 =dev-db/hsqldb-1.7.3.1-r2
> =dev-db/hsqldb-1.7.3.1-r2 =dev-java/servletapi-2.3-r2
> =sys-libs/db-4.3.29
>
> I turned out that even though hsqldb was listed three times, it still
> depended on servletapi, which was scheduled fourth. So it broke:
>
> classes:
>    [javac] Compiling 111 source files to
> /var/tmp/portage/hsqldb-1.7.3.1-r2/work/hsqldb/classes
>    [javac]
> /var/tmp/portage/hsqldb-1.7.3.1-r2/work/hsqldb/src/org/hsqldb/Servlet.java:73:
>
> cannot access javax.servlet.ServletConfig
>    [javac] bad class file:
> /var/tmp/portage/hsqldb-1.7.3.1-r2/work/hsqldb/lib/servlet.jar(javax/servlet/ServletConfig.class)
>
>    [javac] class file has wrong version 49.0, should be 48.0
>    [javac] Please remove or make sure it appears in the correct
> subdirectory of the classpath.
>    [javac] import javax.servlet.ServletConfig;
>    [javac]                      ^
>    [javac] 1 error
>
> I needed to remerge servletapi manually and restart java-1.5-fixer.
> Which,
> of course, built hsqldb three times :-( Which was, of course,
> unnecessary.
> How about at least making the packages that java-1.5-fixer is going to
> fix
> unique? And how about figuring a better ordering of packages?
>

If you let it keep running, it would have eventually gotten to
servletapi, rebuilt that successfully, then retried hsqldb. As for why
it's listed 3 times, I'm not quite sure. It _should_ be filtering
duplicates as I recall.

> After all the above I think I've finally migrated my machine to
> Generation-2.
> Whoopiee!
>
> In general all was fun and problems were minor IMHO. But migration was
> not automatic, like some users would like it to see. Maybe some things
> coul dbe improved before stabilization?
>

I don't believe it would be possible to have a migration that was
totally automated, to be honest. There are a number of pitfalls as is,
like not having all the new Java  packages unmasked and keyworded, user
used 1.5 at some point and needs to recompile everything with 1.4, etc.

> HTH,
> Wiktor Wandachowicz
>
- Josh
-- 
gentoo-java@gentoo.org mailing list