* [gentoo-java] New eclass to support java-virtuals
@ 2007-09-20 11:20 Alistair Bush
2007-09-20 11:37 ` Petteri Räty
[not found] ` <20070920174407.GN31094@supernova>
0 siblings, 2 replies; 5+ messages in thread
From: Alistair Bush @ 2007-09-20 11:20 UTC (permalink / raw
To: gentoo-dev; +Cc: gentoo-java
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
I would like to commit a new java eclass within the next week.
This eclass is designed to support the functionality that Betelgeuse
outlined within a previous post.[1]
As you will be able to see, this eclass is very simple and only uses
functionality that will be provided by the java-utils-2.eclass (see the
attached patch )
Basically all the happens is that a file is created under
/usr/share/java-config-2/virtuals/
that contains (at present) 3 variables. This file is then read by our
java-config-2 application.
The eclass is currently implemented within the java-virtuals overlay for
those who are interested
https://overlays.gentoo.org/svn/proj/java/java-virtuals/
Any suggestions, improvements and of course approvals will be gladly
accepted
Go the All Blacks!!
Alistair
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/48932/focus=48933
On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote:
> We want to implement virtuals for Java at some point and for that we
> need to know the package that provides the virtual because some virtuals
> can be provided by the JDK or normal packages and this affects the JDK
> selection at build time. One option is to call into Portage to find this
> out, but of course Paludis and Pkgcore people most likely don't like
> this approach. One thing that comes to mind is to allow for virtuals to
> install files so we can install the provider information in a format
> easy for us. We need the information in format ${PN}-${SLOT} because
> that's the way we install in /usr/share. So do you think it's ok for
> virtuals to install files (we can of course call the category
> java-virtual/ too), should we call Portage code, or do you have an
> another idea?
[-- Attachment #2: java-utils-2.eclass.patch --]
[-- Type: text/plain, Size: 5873 bytes --]
--- gentoo/cvs/gentoo-x86/eclass/java-utils-2.eclass 2007-08-05 20:17:05.000000000 +1200
+++ gentoo/overlays/java-virtuals/eclass/java-utils-2.eclass 2007-09-12 22:23:53.000000000 +1200
@@ -2196,6 +2286,8 @@
JAVA_PKG_SHAREPATH="${DESTTREE}/share/${JAVA_PKG_NAME}"
JAVA_PKG_SOURCESPATH="${JAVA_PKG_SHAREPATH}/sources/"
JAVA_PKG_ENV="${D}${JAVA_PKG_SHAREPATH}/package.env"
+ JAVA_PKG_VIRTUALS_PATH="${DESTTREE}/share/java-config-2/virtuals"
+ JAVA_PKG_VIRTUAL_PROVIDER="${D}/${JAVA_PKG_VIRTUALS_PATH}/${JAVA_PKG_NAME}"
[[ -z "${JAVA_PKG_JARDEST}" ]] && JAVA_PKG_JARDEST="${JAVA_PKG_SHAREPATH}/lib"
[[ -z "${JAVA_PKG_LIBDEST}" ]] && JAVA_PKG_LIBDEST="${DESTTREE}/$(get_libdir)/${JAVA_PKG_NAME}"
@@ -2220,58 +2312,71 @@
java-pkg_do_write_() {
debug-print-function ${FUNCNAME} $*
java-pkg_init_paths_
- # Create directory for package.env
- dodir "${JAVA_PKG_SHAREPATH}"
- if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" || -f \
- "${JAVA_PKG_DEPEND_FILE}" || -f \
- "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
- # Create package.env
- (
- echo "DESCRIPTION=\"${DESCRIPTION}\""
- echo "GENERATION=\"2\""
-
- [[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
- [[ -n "${JAVA_PKG_LIBRARY}" ]] && echo "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
- [[ -n "${JAVA_PROVIDE}" ]] && echo "PROVIDES=\"${JAVA_PROVIDE}\""
- [[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
- && echo "DEPEND=\"$(cat "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
- [[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
- && echo "OPTIONAL_DEPEND=\"$(cat "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
- echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
- ) > "${JAVA_PKG_ENV}"
-
- # register target/source
- local target="$(java-pkg_get-target)"
- local source="$(java-pkg_get-source)"
- [[ -n ${target} ]] && echo "TARGET=\"${target}\"" >> "${JAVA_PKG_ENV}"
- [[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >> "${JAVA_PKG_ENV}"
-
- # register javadoc info
- [[ -n ${JAVADOC_PATH} ]] && echo "JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
- >> ${JAVA_PKG_ENV}
- # register source archives
- [[ -n ${JAVA_SOURCES} ]] && echo "JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
- >> ${JAVA_PKG_ENV}
-
-
- echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
- [[ -n ${GENTOO_COMPILER} ]] && echo "MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
-
- # extra env variables
- if [[ -n "${JAVA_PKG_EXTRA_ENV_VARS}" ]]; then
- cat "${JAVA_PKG_EXTRA_ENV}" >> "${JAVA_PKG_ENV}" || die
- # nested echo to remove leading/trailing spaces
- echo "ENV_VARS=\"$(echo ${JAVA_PKG_EXTRA_ENV_VARS})\"" \
- >> "${JAVA_PKG_ENV}" || die
- fi
-
- # Strip unnecessary leading and trailing colons
- # TODO try to cleanup if possible
- sed -e "s/=\":/=\"/" -e "s/:\"$/\"/" -i "${JAVA_PKG_ENV}" || die "Did you forget to call java_init ?"
+
+ if [[ $1 != provider ]]; then
+ # Create directory for package.env
+ dodir "${JAVA_PKG_SHAREPATH}"
+ if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" || -f \
+ "${JAVA_PKG_DEPEND_FILE}" || -f \
+ "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
+ # Create package.env
+ (
+ echo "DESCRIPTION=\"${DESCRIPTION}\""
+ echo "GENERATION=\"2\""
+
+ [[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
+ [[ -n "${JAVA_PKG_LIBRARY}" ]] && echo "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
+ [[ -n "${JAVA_PROVIDE}" ]] && echo "PROVIDES=\"${JAVA_PROVIDE}\""
+ [[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
+ && echo "DEPEND=\"$(cat "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
+ [[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
+ && echo "OPTIONAL_DEPEND=\"$(cat "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
+ echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
+ ) > "${JAVA_PKG_ENV}"
+
+ # register target/source
+ local target="$(java-pkg_get-target)"
+ local source="$(java-pkg_get-source)"
+ [[ -n ${target} ]] && echo "TARGET=\"${target}\"" >> "${JAVA_PKG_ENV}"
+ [[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >> "${JAVA_PKG_ENV}"
+
+ # register javadoc info
+ [[ -n ${JAVADOC_PATH} ]] && echo "JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
+ >> ${JAVA_PKG_ENV}
+ # register source archives
+ [[ -n ${JAVA_SOURCES} ]] && echo "JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
+ >> ${JAVA_PKG_ENV}
+
+
+ echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
+ [[ -n ${GENTOO_COMPILER} ]] && echo "MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
+
+ # extra env variables
+ if [[ -n "${JAVA_PKG_EXTRA_ENV_VARS}" ]]; then
+ cat "${JAVA_PKG_EXTRA_ENV}" >> "${JAVA_PKG_ENV}" || die
+ # nested echo to remove leading/trailing spaces
+ echo "ENV_VARS=\"$(echo ${JAVA_PKG_EXTRA_ENV_VARS})\"" \
+ >> "${JAVA_PKG_ENV}" || die
+ fi
+
+ # Strip unnecessary leading and trailing colons
+ # TODO try to cleanup if possible
+ sed -e "s/=\":/=\"/" -e "s/:\"$/\"/" -i "${JAVA_PKG_ENV}" || die "Did you forget to call java_init ?"
+ else
+ debug-print "JAVA_PKG_CLASSPATH, JAVA_PKG_LIBRARY, JAVA_PKG_DEPEND_FILE"
+ debug-print "or JAVA_PKG_OPTIONAL_DEPEND_FILE not defined so can't"
+ debug-print "write package.env."
+ fi
else
- debug-print "JAVA_PKG_CLASSPATH, JAVA_PKG_LIBRARY, JAVA_PKG_DEPEND_FILE"
- debug-print "or JAVA_PKG_OPTIONAL_DEPEND_FILE not defined so can't"
- debug-print "write package.env."
+ dodir "${JAVA_PKG_VIRTUALS_PATH}"
+
+ echo "PROVIDERS=\"${JAVA_VIRTUAL_PROVIDES}\"" \
+ >> ${JAVA_PKG_VIRTUAL_PROVIDER}
+ echo "VM=\"${JAVA_VIRTUAL_VM}\"" \
+ >> ${JAVA_PKG_VIRTUAL_PROVIDER}
+
+ echo "VM_CLASSPATH=\"${JAVA_VIRTUAL_VM_CLASSPATH}\"" \
+ >> ${JAVA_PKG_VIRTUAL_PROVIDER}
fi
}
[-- Attachment #3: java-virtuals-2.eclass --]
[-- Type: text/plain, Size: 410 bytes --]
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# Original Author: Alistair John Bush <ali_bush@gentoo.org>
# Purpose: To provide a default (and only) src_install function
# for ebuilds in the java-virtuals category.
inherit java-utils-2
EXPORT_FUNCTIONS src_install
java-virtuals-2_src_install() {
java-pkg_do_write_ provider
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [gentoo-java] New eclass to support java-virtuals
2007-09-20 11:20 [gentoo-java] New eclass to support java-virtuals Alistair Bush
@ 2007-09-20 11:37 ` Petteri Räty
2007-09-20 11:50 ` Alistair Bush
[not found] ` <20070920174407.GN31094@supernova>
1 sibling, 1 reply; 5+ messages in thread
From: Petteri Räty @ 2007-09-20 11:37 UTC (permalink / raw
To: Alistair Bush; +Cc: gentoo-dev, gentoo-java
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
Alistair Bush kirjoitti:
> I would like to commit a new java eclass within the next week.
>
> This eclass is designed to support the functionality that Betelgeuse
> outlined within a previous post.[1]
>
> As you will be able to see, this eclass is very simple and only uses
> functionality that will be provided by the java-utils-2.eclass (see the
> attached patch )
>
> Basically all the happens is that a file is created under
> /usr/share/java-config-2/virtuals/
> that contains (at present) 3 variables. This file is then read by our
> java-config-2 application.
>
>
> The eclass is currently implemented within the java-virtuals overlay for
> those who are interested
>
> https://overlays.gentoo.org/svn/proj/java/java-virtuals/
>
>
> Any suggestions, improvements and of course approvals will be gladly
> accepted
>
> Go the All Blacks!!
>
> Alistair
>
https://overlays.gentoo.org/svn/proj/java/java-virtuals/java-virtuals/javamail/javamail-1.0.ebuild
Is the JAVA_VIRTUAL variable there some old leftover? I don't see it
used anywhere and it's quite useless as you could use hasq
java-virtuals-2 ${INHERIT} any way.
Regards,
Petteri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [gentoo-java] New eclass to support java-virtuals
2007-09-20 11:37 ` Petteri Räty
@ 2007-09-20 11:50 ` Alistair Bush
0 siblings, 0 replies; 5+ messages in thread
From: Alistair Bush @ 2007-09-20 11:50 UTC (permalink / raw
To: Petteri Räty; +Cc: gentoo-java, gentoo-dev
Petteri Räty wrote:
> Alistair Bush kirjoitti:
>> I would like to commit a new java eclass within the next week.
>>
>> This eclass is designed to support the functionality that Betelgeuse
>> outlined within a previous post.[1]
>>
>> As you will be able to see, this eclass is very simple and only uses
>> functionality that will be provided by the java-utils-2.eclass (see the
>> attached patch )
>>
>> Basically all the happens is that a file is created under
>> /usr/share/java-config-2/virtuals/
>> that contains (at present) 3 variables. This file is then read by our
>> java-config-2 application.
>>
>>
>> The eclass is currently implemented within the java-virtuals overlay for
>> those who are interested
>>
>> https://overlays.gentoo.org/svn/proj/java/java-virtuals/
>>
>>
>> Any suggestions, improvements and of course approvals will be gladly
>> accepted
>>
>> Go the All Blacks!!
>>
>> Alistair
>>
>
> https://overlays.gentoo.org/svn/proj/java/java-virtuals/java-virtuals/javamail/javamail-1.0.ebuild
>
> Is the JAVA_VIRTUAL variable there some old leftover? I don't see it
> used anywhere and it's quite useless as you could use hasq
> java-virtuals-2 ${INHERIT} any way.
>
> Regards,
> Petteri
>
Yes that is a old variable. Please ignore it.
--
gentoo-java@gentoo.org mailing list
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-java] Re: [gentoo-dev] New eclass to support java-virtuals
[not found] ` <20070920174407.GN31094@supernova>
@ 2007-09-20 18:58 ` Alistair Bush
[not found] ` <20070920190909.GP31094@supernova>
0 siblings, 1 reply; 5+ messages in thread
From: Alistair Bush @ 2007-09-20 18:58 UTC (permalink / raw
To: gentoo-dev; +Cc: Donnie Berkholz, gentoo-java
Donnie Berkholz wrote:
> On 23:20 Thu 20 Sep , Alistair Bush wrote:
>> - # Create package.env
>> - (
>> - echo "DESCRIPTION=\"${DESCRIPTION}\""
>> - echo "GENERATION=\"2\""
>> -
>> - [[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
>> - [[ -n "${JAVA_PKG_LIBRARY}" ]] && echo "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
>> - [[ -n "${JAVA_PROVIDE}" ]] && echo "PROVIDES=\"${JAVA_PROVIDE}\""
>> - [[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
>> - && echo "DEPEND=\"$(cat "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> - [[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
>> - && echo "OPTIONAL_DEPEND=\"$(cat "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> - echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
>> - ) > "${JAVA_PKG_ENV}"
>
> Why not use a code block {} instead of a subshell ()?
You would have to ask the original author about that, but point taken.
>
>> - # register target/source
>> - local target="$(java-pkg_get-target)"
>> - local source="$(java-pkg_get-source)"
>> - [[ -n ${target} ]] && echo "TARGET=\"${target}\"" >> "${JAVA_PKG_ENV}"
>> - [[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >> "${JAVA_PKG_ENV}"
>> -
>> - # register javadoc info
>> - [[ -n ${JAVADOC_PATH} ]] && echo "JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
>> - >> ${JAVA_PKG_ENV}
>> - # register source archives
>> - [[ -n ${JAVA_SOURCES} ]] && echo "JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
>> - >> ${JAVA_PKG_ENV}
>> -
>> -
>> - echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
>> - [[ -n ${GENTOO_COMPILER} ]] && echo "MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
>
> I don't understand why all these things are done down here instead of in the
> same code block as $JAVA_PKG_ENV is created.
That to is also historical, and i'm less inclined to changed it. I've
already broken the tree once with a eclass change, breaking this would
completely break java support. It could be updated as part of our
general QA, but I believe that it should be done separately, and not
bundled in with the changes i've made.
>
>> - # Strip unnecessary leading and trailing colons
>> - # TODO try to cleanup if possible
>> - sed -e "s/=\":/=\"/" -e "s/:\"$/\"/" -i "${JAVA_PKG_ENV}" || die "Did you forget to call java_init ?"
>> +
>> + if [[ $1 != provider ]]; then
>
> Could you explain what the next section is supposed to do, as opposed to
> the above section? Are they expected to be mutually exclusive? The
> comments suggest so, since both have a 'Create package.env'. But the
> tests suggest otherwise, since it's not an if...else pair.
normally java-pkg_do_write_ is called to write the package.env out, as
can be seen, and is the default behavior for the function. What I am
adding is the ability to _do_write of a "[virtual|provider].env" file.
While at present it only contains 3 variables, I see no reason why
eventually it will not include other vars that are shared between the
package.env and "virtual.env" ( e.g DESCRIPTION )
Therefore this change can be summarized as
+ if [[ $1 != provider ]]; then
#Do the default package.env behaviour
+ else
+ #Create a "virtual.env" file. This will only be invoked by
+ #ebuilds that inherit java-virtuals.eclass
+ fi
I could very well reflactor the java-pkg_do_write_ function back to its
current state and create a new function java-pkg_do_write_virtual to be
called by java-virtuals-2.eclass.
The documentation could (and will) be updated to more correctly reflect
whats happening.
>
>> + # Create directory for package.env
>> + dodir "${JAVA_PKG_SHAREPATH}"
>> + if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" || -f \
>> + "${JAVA_PKG_DEPEND_FILE}" || -f \
>> + "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
>> + # Create package.env
>> + (
>> + echo "DESCRIPTION=\"${DESCRIPTION}\""
>> + echo "GENERATION=\"2\""
>> +
>> + [[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
>> + [[ -n "${JAVA_PKG_LIBRARY}" ]] && echo "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
>> + [[ -n "${JAVA_PROVIDE}" ]] && echo "PROVIDES=\"${JAVA_PROVIDE}\""
>> + [[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
>> + && echo "DEPEND=\"$(cat "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> + [[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
>> + && echo "OPTIONAL_DEPEND=\"$(cat "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> + echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
>> + ) > "${JAVA_PKG_ENV}"
>
> Thanks,
> Donnie
--
gentoo-java@gentoo.org mailing list
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-java] Re: [gentoo-dev] New eclass to support java-virtuals
[not found] ` <20070920190909.GP31094@supernova>
@ 2007-09-21 5:28 ` Alistair Bush
0 siblings, 0 replies; 5+ messages in thread
From: Alistair Bush @ 2007-09-21 5:28 UTC (permalink / raw
To: gentoo-dev, Donnie Berkholz, gentoo-java
Donnie Berkholz wrote:
> On 06:58 Fri 21 Sep , Alistair Bush wrote:
>> normally java-pkg_do_write_ is called to write the package.env out, as
>> can be seen, and is the default behavior for the function. What I am
>> adding is the ability to _do_write of a "[virtual|provider].env" file.
>> While at present it only contains 3 variables, I see no reason why
>> eventually it will not include other vars that are shared between the
>> package.env and "virtual.env" ( e.g DESCRIPTION )
>>
>> Therefore this change can be summarized as
>>
>> + if [[ $1 != provider ]]; then
>> #Do the default package.env behaviour
>> + else
>> + #Create a "virtual.env" file. This will only be invoked by
>> + #ebuilds that inherit java-virtuals.eclass
>> + fi
>>
>> I could very well reflactor the java-pkg_do_write_ function back to its
>> current state and create a new function java-pkg_do_write_virtual to be
>> called by java-virtuals-2.eclass.
>>
>> The documentation could (and will) be updated to more correctly reflect
>> whats happening.
>
> I'm concerned about code duplication, because that's what it looks like.
> Refactoring might be a good idea.
>
> Thanks,
> Donnie
Ok, thanks for the input Donnie. I will refactor it before goes into the
tree.
Any more input ppl?
Thanks
Alistair
--
gentoo-java@gentoo.org mailing list
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-09-21 5:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-20 11:20 [gentoo-java] New eclass to support java-virtuals Alistair Bush
2007-09-20 11:37 ` Petteri Räty
2007-09-20 11:50 ` Alistair Bush
[not found] ` <20070920174407.GN31094@supernova>
2007-09-20 18:58 ` [gentoo-java] Re: [gentoo-dev] " Alistair Bush
[not found] ` <20070920190909.GP31094@supernova>
2007-09-21 5:28 ` Alistair Bush
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox