[gentoo-java] Feedback on migration and experimental overlay

[gentoo-java] Feedback on migration and experimental overlay

[Uwe Klosa]

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

Hi

I've been using the migration overlay for about two weeks now and there haven't been any problems. I observed only one thing with the
emerge of ant-1.6.5. When jdk-1.4 and jdk-1.5 are installed with 1.4 being the system vm the emerge of ant used 1.5 for compilation. I
got ridd of that by removing 1.5. I don't know if this is a known issue or if it was only on my system where I had been using 1.5 as
the system vm for quite some time. But this problem occured after migrating to the migration overlay and fixing all 1.5 issues.

This week I installed eclipse-3.2-rc1 from the experimental overlay and had no problems at all. The emerge went fine and the
installation of my plug-ins, too.

The emerge of tomcat-5.5.9 and 5.5.16 didn't work at all. Should I report the errors on bugs.gentoo.org or should I send them by email?

/Uwe

[-- Attachment #2: uwe.klosa.vcf --]
[-- Type: text/x-vcard, Size: 242 bytes --]

begin:vcard
fn:Uwe Klosa
n:Klosa;Uwe
org:Uppsala University;Electronic Publishing Centre
adr:;;;Uppsala;;75120;Sweden
email;internet:uwe.klosa@ub.uu.se
tel;work:+46 (0)18 471 7658
url:http://publications.uu.se/epcentre
version:2.1
end:vcard

Re: [gentoo-java] Feedback on migration and experimental overlay

[Joshua Nichols]

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

Uwe Klosa wrote:
> Hi
> 
> I've been using the migration overlay for about two weeks now and there haven't been any problems. I observed only one thing with the
> emerge of ant-1.6.5. When jdk-1.4 and jdk-1.5 are installed with 1.4 being the system vm the emerge of ant used 1.5 for compilation. I
> got ridd of that by removing 1.5. I don't know if this is a known issue or if it was only on my system where I had been using 1.5 as
> the system vm for quite some time. But this problem occured after migrating to the migration overlay and fixing all 1.5 issues.

Are you positive that you were using a 1.4 JDK for the system vm of
generation 1? java-check-environment _should_ be checking for this, and
warning you about i. If that's not the case, I'd be interested to see if
you could replicate that behavior, because I certainly haven't had this
problem.

> This week I installed eclipse-3.2-rc1 from the experimental overlay and had no problems at all. The emerge went fine and the
> installation of my plug-ins, too.
> 
rc2 is in the overlay, FYI

> The emerge of tomcat-5.5.9 and 5.5.16 didn't work at all. Should I report the errors on bugs.gentoo.org or should I send them by email?

Either work. If you file a bug, please be sure to indicate clearly which
overlay it's from.

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

iD8DBQFEXe+h8ATTzZyw6sMRAi7hAJ9/+ndq4NK3XMjCEpqznLWIYaJPXwCcDIeR
hVI20XBug2JWVTgSMr5craQ=
=2YwG
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Feedback on migration and experimental overlay

[Uwe Klosa]

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



Joshua Nichols wrote:
> Uwe Klosa wrote:
>>> Hi
>>>
>>> I've been using the migration overlay for about two weeks now and there haven't been any problems. I observed only one thing with the
>>> emerge of ant-1.6.5. When jdk-1.4 and jdk-1.5 are installed with 1.4 being the system vm the emerge of ant used 1.5 for compilation. I
>>> got ridd of that by removing 1.5. I don't know if this is a known issue or if it was only on my system where I had been using 1.5 as
>>> the system vm for quite some time. But this problem occured after migrating to the migration overlay and fixing all 1.5 issues.
> 
> Are you positive that you were using a 1.4 JDK for the system vm of
> generation 1? java-check-environment _should_ be checking for this, and
> warning you about i. If that's not the case, I'd be interested to see if
> you could replicate that behavior, because I certainly haven't had this
> problem.
> 

I will try to do that


>>> This week I installed eclipse-3.2-rc1 from the experimental overlay and had no problems at all. The emerge went fine and the
>>> installation of my plug-ins, too.
>>>
> rc2 is in the overlay, FYI
> 

I can see it in my overlay folder but emerge -au eclipse-sdk shows 'nothing to merge'.


>>> The emerge of tomcat-5.5.9 and 5.5.16 didn't work at all. Should I report the errors on bugs.gentoo.org or should I send them by email?
> 
> Either work. If you file a bug, please be sure to indicate clearly which
> overlay it's from.

I will do that.

/Uwe

[-- Attachment #2: uwe.klosa.vcf --]
[-- Type: text/x-vcard, Size: 242 bytes --]

begin:vcard
fn:Uwe Klosa
n:Klosa;Uwe
org:Uppsala University;Electronic Publishing Centre
adr:;;;Uppsala;;75120;Sweden
email;internet:uwe.klosa@ub.uu.se
tel;work:+46 (0)18 471 7658
url:http://publications.uu.se/epcentre
version:2.1
end:vcard

Re: [gentoo-java] Feedback on migration and experimental overlay

[Caster]

Uwe Klosa wrote:
> 
> Joshua Nichols wrote:
>> Uwe Klosa wrote:
>>>> Hi
>>>>
>>>> I've been using the migration overlay for about two weeks now and there haven't been any problems. I observed only one thing with the
>>>> emerge of ant-1.6.5. When jdk-1.4 and jdk-1.5 are installed with 1.4 being the system vm the emerge of ant used 1.5 for compilation. I
>>>> got ridd of that by removing 1.5. I don't know if this is a known issue or if it was only on my system where I had been using 1.5 as
>>>> the system vm for quite some time. But this problem occured after migrating to the migration overlay and fixing all 1.5 issues.

Same here, sun-jdk-1.4 set as system vm both for generation 1 and 2.

# emerge -1 ant-core
Calculating dependencies... done!
>>> Emerging (1 of 1) 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...
<ctrl+c>

>> Are you positive that you were using a 1.4 JDK for the system vm of
>> generation 1? java-check-environment _should_ be checking for this, and
>> warning you about i. If that's not the case, I'd be interested to see if
>> you could replicate that behavior, because I certainly haven't had this
>> problem.
>>
> 

I'm positive, java-check-environment reports no problem.

BTW I thought the new system was to allow 1.5 jdk to be used for builds
that are known to support it. Maybe it's the case of ant-core?

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

Re: [gentoo-java] Feedback on migration and experimental overlay

[Joshua Nichols]

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

Caster wrote:
> Uwe Klosa wrote:
>> Joshua Nichols wrote:
>>> Uwe Klosa wrote:
>>>>> Hi
>>>>>
>>>>> I've been using the migration overlay for about two weeks now and there haven't been any problems. I observed only one thing with the
>>>>> emerge of ant-1.6.5. When jdk-1.4 and jdk-1.5 are installed with 1.4 being the system vm the emerge of ant used 1.5 for compilation. I
>>>>> got ridd of that by removing 1.5. I don't know if this is a known issue or if it was only on my system where I had been using 1.5 as
>>>>> the system vm for quite some time. But this problem occured after migrating to the migration overlay and fixing all 1.5 issues.
> 
> Same here, sun-jdk-1.4 set as system vm both for generation 1 and 2.
> 
> # emerge -1 ant-core
> Calculating dependencies... done!
>>>> Emerging (1 of 1) 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...
> <ctrl+c>
> 
>>> Are you positive that you were using a 1.4 JDK for the system vm of
>>> generation 1? java-check-environment _should_ be checking for this, and
>>> warning you about i. If that's not the case, I'd be interested to see if
>>> you could replicate that behavior, because I certainly haven't had this
>>> problem.
>>>
> 
> I'm positive, java-check-environment reports no problem.
> 
> BTW I thought the new system was to allow 1.5 jdk to be used for builds
> that are known to support it. Maybe it's the case of ant-core?
> 
> Caster

Ah... right. It's not a problem that 1.5 is being used to compile it.
The build.xml files get rewritten to make sure 1.4 bytecode gets compiled.

By chance, have you configured anything in
/etc/java-config-2/build/compilers.conf ? By default, it should use the
lowest possible VM, but it can be configured more finely.

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

iD8DBQFEX+FI8ATTzZyw6sMRAs1oAJ9s2Cc5X4fdXIx1kzi7yoYAhrpESgCeOEGY
Ed69lXH8wKXwixCJS23I5m8=
=of92
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Feedback on migration and experimental overlay

[Caster]

Joshua Nichols wrote:
 > Ah... right. It's not a problem that 1.5 is being used to compile it.
> The build.xml files get rewritten to make sure 1.4 bytecode gets compiled.
> 
> By chance, have you configured anything in
> /etc/java-config-2/build/compilers.conf ? By default, it should use the
> lowest possible VM, but it can be configured more finely.
> 
> Josh

No, didn't change that. It has only the commented example line
#COMPILERS="ecj-3.1 jikes javac"
I don't see how to specify JDK version in there  :)
This is getting confusing, you have generation-1 system VM, generation-2
system VM, this compilers.conf... Any docs that explain how all that
works, what gets used where?  :)
And what means "Enabling generation-2 compatibility ..." line in some
ebuilds? BTW those ebuilds then use jdk-1.4 while ant-core doesn't print
this line and uses jdk-1.5...

Seems ant-tasks is affected as well, and can't be built because of that.
http://bugs.gentoo.org/show_bug.cgi?id=132764

Caster

P.S. Um why doesn't this list have reply-to header pointing to the list
address...

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Feedback on migration and experimental overlay

[Joshua Nichols]

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

Caster wrote:
> Joshua Nichols wrote:
>  > Ah... right. It's not a problem that 1.5 is being used to compile it.
>> The build.xml files get rewritten to make sure 1.4 bytecode gets compiled.
>>
>> By chance, have you configured anything in
>> /etc/java-config-2/build/compilers.conf ? By default, it should use the
>> lowest possible VM, but it can be configured more finely.
>>
>> Josh
> 
> No, didn't change that. It has only the commented example line
> #COMPILERS="ecj-3.1 jikes javac"
> I don't see how to specify JDK version in there  :)

I actually meant compilers.conf, not jdk.conf

> This is getting confusing, you have generation-1 system VM, generation-2
> system VM, this compilers.conf... Any docs that explain how all that
> works, what gets used where?  :)

https://svn.gentooexperimental.org/svn/java/migration/docs/java-user.html

Generation-1 system vm is used by root, and conseuqnently for emerging
packages that are using the old eclasses, ie java-pkg (which would be
most everything at this point).

Generation-2 system vm is used for root.

Generation-2 build vm is configured by the jdk.conf, and is used for
emerging packages which use the new eclasses, ie java-pkg-2.

> And what means "Enabling generation-2 compatibility ..." line in some
> ebuilds? BTW those ebuilds then use jdk-1.4 while ant-core doesn't print
> this line and uses jdk-1.5...

That line is displayed when you have the stuff related to generation-2
installed, ie updated java-config, new vms etc. The new java-config
introduces /usr/bin/java, /usr/bin/jar, etc. These can read GENTOO_VM to
know what vm to be using, so we set that to make sure JAVA_HOME and
/usr/bin/java use the same vm.
> 
> Seems ant-tasks is affected as well, and can't be built because of that.
> http://bugs.gentoo.org/show_bug.cgi?id=132764
> 

Quite aware of the bug now. It didn't happen on the system I was testing
on, but now I'm hitting it as well.

> Caster
> 
> P.S. Um why doesn't this list have reply-to header pointing to the list
> address...
> 

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

iD8DBQFEYI7L8ATTzZyw6sMRAqRwAJ9+NB0LHmFQMSrYx6vYP8rUWpAIeACfQu4R
4k1CE9bqrSInmHsFHyrpfh0=
=f2mP
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Feedback on migration and experimental overlay

[Caster]

Joshua Nichols wrote:
> Caster wrote:
>>> Joshua Nichols wrote:
>>>  > Ah... right. It's not a problem that 1.5 is being used to compile it.
>>>> The build.xml files get rewritten to make sure 1.4 bytecode gets compiled.
>>>>
>>>> By chance, have you configured anything in
>>>> /etc/java-config-2/build/compilers.conf ? By default, it should use the
>>>> lowest possible VM, but it can be configured more finely.
>>>>
>>>> Josh
>>> No, didn't change that. It has only the commented example line
>>> #COMPILERS="ecj-3.1 jikes javac"
>>> I don't see how to specify JDK version in there  :)
> 
> I actually meant compilers.conf, not jdk.conf
> 

I take that as "I actually meant jdk.conf, not compilers.conf" :)
No, didn't change jdk.conf neither, contains only commented examples as
well.

>>> This is getting confusing, you have generation-1 system VM, generation-2
>>> system VM, this compilers.conf... Any docs that explain how all that
>>> works, what gets used where?  :)
> 
> https://svn.gentooexperimental.org/svn/java/migration/docs/java-user.html
> 
> Generation-1 system vm is used by root, and conseuqnently for emerging
> packages that are using the old eclasses, ie java-pkg (which would be
> most everything at this point).
> 
> Generation-2 system vm is used for root.
> 
> Generation-2 build vm is configured by the jdk.conf, and is used for
> emerging packages which use the new eclasses, ie java-pkg-2.
> 

Thanks for explaining.

>>> Seems ant-tasks is affected as well, and can't be built because of that.
>>> http://bugs.gentoo.org/show_bug.cgi?id=132764
>>>
> 
> Quite aware of the bug now. It didn't happen on the system I was testing
> on, but now I'm hitting it as well.
> 

After overlay svn update it's emerged ok, although still using 1.5 jdk.
Just the "By default, it should use the lowest possible VM" doesn't seem
to hold :)

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

[gentoo-java] eselect java broken?

[Caster]

Tried to play a bit with eselect java (using java-experimental and
migration overlays).
Found two problems with that:

- it seems not to be in sync with java-config (neither -1 or -2). While
my user and system vm's are set properly with java-configs, eselect java
show reports:

Current system-vm
  (unset)
Current user-vm
  (unset)


I can set user vm with "eselect java set user x", then "eselect java
show" shows what I set with eselect, but it has no effect on java-config
 nor java -version. I would expect eselect java to be in sync with
java-config-2 ?

- it doesn't allow me to change system vm (as root, of course)
# eselect java set system 1
!!! Error: Sorry, you don't have enough premission to set system
exiting.

Since the new docs mention eselect as alternative to java-config, I
would expect it to work in migration overlay.

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

Re: [gentoo-java] eselect java broken?

[Joshua Nichols]

Caster wrote:
> Tried to play a bit with eselect java (using java-experimental and
> migration overlays).
> Found two problems with that:
>
> - it seems not to be in sync with java-config (neither -1 or -2). While
> my user and system vm's are set properly with java-configs, eselect java
> show reports:
>
> Current system-vm
>   (unset)
> Current user-vm
>   (unset)
>
>
> I can set user vm with "eselect java set user x", then "eselect java
> show" shows what I set with eselect, but it has no effect on java-config
>  nor java -version. I would expect eselect java to be in sync with
> java-config-2 ?
>
> - it doesn't allow me to change system vm (as root, of course)
> # eselect java set system 1
> !!! Error: Sorry, you don't have enough premission to set system
> exiting.
>
> Since the new docs mention eselect as alternative to java-config, I
> would expect it to work in migration overlay.
>
> Caster
>   
There is a good chance they are broken, because I might have forgotten 
about it :-X

Will take a look at it soon...
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] eselect java broken?

[Caster]

OK tried to look at it myself, and the problems mentioned were caused
just by improper paths in the beginning of
/usr/share/eselect/modules/java.eselect
Fixed them, also fixed the "eselect java list" (didn't mark user-vm
properly) - see the attached patch. Listing and changing is now in sync
with java-config-2.

But then I've run into another problem. It allows root to set user-vm as
well as system-vm, while java-config-2 doesn't. java-config-2 then lists
it as active with java-config -L (probably causes other problems too).
There's no way to unset it but removing /root/.gentoo/java-config-2
So, eselect java shouldn't list or allow changing of user-vm for root.
Haven't tried to fix that.

Caster

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] eselect java broken?

[Joshua Nichols]

Caster wrote:
> OK tried to look at it myself, and the problems mentioned were caused
> just by improper paths in the beginning of
> /usr/share/eselect/modules/java.eselect
> Fixed them, also fixed the "eselect java list" (didn't mark user-vm
> properly) - see the attached patch. Listing and changing is now in sync
> with java-config-2.
>
>   
You forgot to attach the patch :)

But it's moot, since I just barely fixed it before seeing your message.
> But then I've run into another problem. It allows root to set user-vm as
> well as system-vm, while java-config-2 doesn't. java-config-2 then lists
> it as active with java-config -L (probably causes other problems too).
> There's no way to unset it but removing /root/.gentoo/java-config-2
> So, eselect java shouldn't list or allow changing of user-vm for root.
> Haven't tried to fix that.
>
>   
Right you are. It should die now if you try to set a user vm as root.

On a related note, it seems that the eselect module sets stuff by hand, 
ie by creating symlinks and whatnot. I'm not sure if this was 
intentional, or if it should be using java-config to do this instead.

In any event, thanks for the report. This is exactly the stuff I want to 
be found and fixed before we merge the migration-overlay into the main tree.

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

Re: [gentoo-java] eselect java broken?

[Caster]

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

Joshua Nichols wrote:
> You forgot to attach the patch :)
> 

Damn :) Here it is.

> But it's moot, since I just barely fixed it before seeing your message.
>> But then I've run into another problem. It allows root to set user-vm as
>> well as system-vm, while java-config-2 doesn't. java-config-2 then lists
>> it as active with java-config -L (probably causes other problems too).
>> There's no way to unset it but removing /root/.gentoo/java-config-2
>> So, eselect java shouldn't list or allow changing of user-vm for root.
>> Haven't tried to fix that.
>>
>>   
> Right you are. It should die now if you try to set a user vm as root.
> 
> On a related note, it seems that the eselect module sets stuff by hand,
> ie by creating symlinks and whatnot. I'm not sure if this was
> intentional, or if it should be using java-config to do this instead.
> 

Using java-config to set stuff would be easy. To list stuff, it would
need to parse its output. I'm not even sure if an user can determine
system-vm with java-config. Maybe use the python functions that
java-config uses?

> In any event, thanks for the report. This is exactly the stuff I want to
> be found and fixed before we merge the migration-overlay into the main
> tree.
> 

Glad to help :)

Caster

[-- Attachment #2: java.eselect.diff --]
[-- Type: text/plain, Size: 1051 bytes --]

--- java.eselect.2.0.22	2006-05-09 19:17:02.000000000 +0200
+++ java.eselect.fixed	2006-05-09 19:16:00.000000000 +0200
@@ -10,8 +10,8 @@
 VERSION=$(svn_date_to_version "${SVN_DATE}" )
 
 VM_BASE=/usr/lib/jvm/
-VM_SYSTEM=/etc/java-config/system-vm
-VM_USER=${HOME}/.gentoo/user-vm
+VM_SYSTEM=/etc/java-config-2/current-system-vm
+VM_USER=${HOME}/.gentoo/java-config-2/current-user-vm
 
 find_targets() {
 	local f
@@ -67,12 +67,14 @@
 		[[ -L ${VM_USER} ]] && user_name=$(sym_to_vm ${VM_USER})
 
 		for (( i = 0 ; i < ${#targets[@]} ; i = i + 1 )) ; do
+			mark="";
 			if [[ ${targets[${i}]} == ${system_name} ]]; then
-				targets[${i}]="${targets[${i}]} $(highlight 'system-vm')"
+				mark="${mark} $(highlight 'system-vm')";
 			fi
-			if [[ ${targets[${i}]} == ${user_user} ]]; then
-				targets[${i}]="${targets[${i}]} $(highlight 'user-vm' )"
+			if [[ ${targets[${i}]} == ${user_name} ]]; then
+				mark="${mark} $(highlight 'user-vm')";
 			fi
+			targets[${i}]="${targets[${i}]} ${mark}"
 		done
 		write_numbered_list "${targets[@]}"
 	else

Re: [gentoo-java] eselect java broken?

[Caster]

I see setting vm is now fixed in svn. Last minor glitch is the "eselect
java list" which shows system-vm but not user-vm, because of wrong
variable name (and if you fix that, it won't show user-vm for a vm that
is both system-vm and user-vm, because first it adds the string for
system-vm and then compares it with just vm name, so it can't match). My
patch covered that.

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

Re: [gentoo-java] eselect java broken?

[Joshua Nichols]

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

Caster wrote:
> I see setting vm is now fixed in svn. Last minor glitch is the "eselect
> java list" which shows system-vm but not user-vm, because of wrong
> variable name (and if you fix that, it won't show user-vm for a vm that
> is both system-vm and user-vm, because first it adds the string for
> system-vm and then compares it with just vm name, so it can't match). My
> patch covered that.
> 
> Caster
Like I mentioned before, I patched it before you attached a patch, and I
hadn't noticed that problem at that time. I will fix it in svn soon enough.

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

iD8DBQFEYeci8ATTzZyw6sMRAjs1AJ46F++4AcURVT2W4C1nH/4cvp2ZiACfU+zJ
RJR9v9cGTO90mmlitseA+5w=
=HzrF
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list