Re: Can I get a volunteer?

On Fri, Oct 31, 2003 at 12:37:03PM -0500, Scott Brickner wrote:

> The first thing I'd like to package is Apache Maven. Though I'm not a
> huge fan of it, yet, it's used by too many of the Apache projects now to
> ignore. It looks like it does a fair job of installing itself, if you
> can get the pieces in the right places.

Maven is going to be v. hard as a first package - I'd suggest you start
with something simpler - maybe one of the components needed to build it
if we haven't packaged it already.  I'm going to release configLog4j
jrefactory and xjavadoc shortly should be enough to start building
xdoclet I believe - which is a Maven build require.

Paul

_______________________________________________
JPackage-discuss mailing list
JPackage-discuss@...
https://zarb.org/mailman/listinfo/jpackage-discuss

New fastutil release

Dear packagers,
here's the spec file for the new fastutil releases. As always, I tried
to follow carefully current packaging policies.

Greetings,

			seba

P.S.: You'd better have 512MB when building fastutil.

_______________________________________________
JPackage-discuss mailing list
JPackage-discuss@...
https://zarb.org/mailman/listinfo/jpackage-discuss

Re: New fastutil release

On Sat, 2003-11-01 at 13:21, Sebastiano Vigna wrote:

> here's the spec file for the new fastutil releases. As always, I tried
> to follow carefully current packaging policies.

Thanks, currently building.  I did the following tweaks:
- BuildRequires: java-javadoc
- Save .spec in UTF-8
- Removed macros from Source URL

> * Fri Nov 01 2003 Sebastiano Vigna [...]

Huh, Fri Nov 01?  It's Sat Nov 01 over here :)

_______________________________________________
JPackage-discuss mailing list
JPackage-discuss@...
https://zarb.org/mailman/listinfo/jpackage-discuss

Re: New fastutil release

On Sat, 2003-11-01 at 13:04, Ville Skyttä wrote:
> On Sat, 2003-11-01 at 13:21, Sebastiano Vigna wrote:

> - Save .spec in UTF-8

I was just wondering which could be non-ASCII characters
in a spec file, and then I realised 8^).

> - Removed macros from Source URL
> 

I noticed you did that also to MG4J. Why are such macros problematic?

> > * Fri Nov 01 2003 Sebastiano Vigna [...]
> 
> Huh, Fri Nov 01?  It's Sat Nov 01 over here :)

Oops. It was late..

--

-- 
Ciao,

						seba

_______________________________________________
JPackage-discuss mailing list
JPackage-discuss@...
https://zarb.org/mailman/listinfo/jpackage-discuss

Location for JNI *.so files?

Folks, what do you think, where should we install various JNI *.so
libraries?  The policy doc mentions %{_jnidir} as /usr/lib/java but no
package AFAICS currently creates such a dir and the policy talks about
"JNI jar repository", not *.so.  Also, "it is declined in -ext"?  Huh?
Nicolas, if you have this figured out, could you clarify?

Debian installs into /usr/lib/jni:
http://www.debian.org/doc/packaging-manuals/java-policy/x105.html
http://www.debian.org/doc/packaging-manuals/java-policy/c36.html
(see the bottom of the latter link)

/usr/lib isn't searched by default, for example the current
java-1.4.2-sun searches only from the following:

  /usr/lib/jvm/java-1.4.2-sun-1.4.2.02/jre/lib/i386/client
  /usr/lib/jvm/java-1.4.2-sun-1.4.2.02/jre/lib/i386
  /usr/lib/jvm/java-1.4.2-sun-1.4.2.02/jre/../lib/i386
  [+ whatever is in LD_LIBRARY_PATH]

Does anybody know if there's a way to affect this search path
(java.library.path) in a system wide .properties file somewhere?  I'd
hate to clutter the global LD_LIBRARY_PATH since this is java-only
stuff.

I have a couple of packages sort of ready to roll once we have figured
this out (dependencies for RH/FC are/will be available from fedora.us):
- wx4j:  http://wx4j.sourceforge.net/
- jpcsc: http://www.linuxnet.com/middle.html

policytool crash?

On my RH9 box, policytool from Sun's 1.4.2_02 crashes right away from
the startup, and the one from Sun's 1.3.1_09 either crashes or hangs
consuming all CPU.

Can anybody reproduce?  What about when using vendor RPMs?

_______________________________________________
JPackage-discuss mailing list
JPackage-discuss@...
https://zarb.org/mailman/listinfo/jpackage-discuss

Re: New fastutil release

On Sat, 2003-11-01 at 14:32, Sebastiano Vigna wrote:

> > - Removed macros from Source URL
>
> I noticed you did that also to MG4J. Why are such macros problematic?

Personal preference, I want to be able to copy-paste the URLs from
specfiles to a browser or wget command line without having to excercise
my brain and fingers in deciphering the macros.

URLs with macros are known to bitrot, and serve no real purpose anyway. 
IMNSHO the only sane options are:
- Use full, macroless URLs.
- Use macros in SourceX and PatchX as much as it makes sense to, but do
  *not* use URLs there when doing this.

Not everybody agrees though.

_______________________________________________
JPackage-discuss mailing list
JPackage-discuss@...
https://zarb.org/mailman/listinfo/jpackage-discuss

Re: Location for JNI *.so files?

Le sam 01/11/2003 à 13:49, Ville Skyttä a écrit :
> Folks, what do you think, where should we install various JNI *.so
> libraries? 

Normal libdir

>  The policy doc mentions %{_jnidir} as /usr/lib/java but no
> package AFAICS currently creates such a dir and the policy talks about
> "JNI jar repository", not *.so.

Sure. The aim is to avoid putting jars that depend on arch-specific .so
in /usr/share, since one could have share nfs-mounted but not lib.

I'm pretty sure at least the mysql connector I packaged uses this.

>   Also, "it is declined in -ext"?  Huh?
> Nicolas, if you have this figured out, could you clarify?

jnidir rules are exactly the same as javadir rules except the root is
/usr/lib not /usr/share

> Debian installs into /usr/lib/jni:
> http://www.debian.org/doc/packaging-manuals/java-policy/x105.html
> http://www.debian.org/doc/packaging-manuals/java-policy/c36.html
> (see the bottom of the latter link)
> 
> /usr/lib isn't searched by default, for example the current
> java-1.4.2-sun searches only from the following:
> 
>   /usr/lib/jvm/java-1.4.2-sun-1.4.2.02/jre/lib/i386/client

Re: Location for JNI *.so files?

On Sat, 2003-11-01 at 16:03, Nicolas Mailhot wrote:
> Le sam 01/11/2003 à 13:49, Ville Skyttä a écrit :

> >  The policy doc mentions %{_jnidir} as /usr/lib/java but no
> > package AFAICS currently creates such a dir and the policy talks about
> > "JNI jar repository", not *.so.
> 
> Sure. The aim is to avoid putting jars that depend on arch-specific .so
> in /usr/share, since one could have share nfs-mounted but not lib.

Ah, ok.

> > Does anybody know if there's a way to affect this search path
> > (java.library.path) in a system wide .properties file somewhere?  I'd
> > hate to clutter the global LD_LIBRARY_PATH since this is java-only
> > stuff.
> 
> It is not. JNI is often used for stuff like db drivers (it plugs into
> the C db connector) and you do not want to install your mysql/pg/oracle
> .so in a java-specific dir just because a java jar also happens to use
> it.

Native C db libraries and the like without JNI are clearly a different
thing, they should be installed in the normal system locations.  We're
not distributing them, and I'm talking about java-only JNI *.so, they
may interact with whatever normal system libraries installed in the
"normal" locations.

> If jvms do not search in the usual .so locations, it's a jvm bug.

Re: Can I get a volunteer?

Paul Nasrat wrote:
> On Fri, Oct 31, 2003 at 12:37:03PM -0500, Scott Brickner wrote:
>  
> 
>>The first thing I'd like to package is Apache Maven. Though I'm not a
>>huge fan of it, yet, it's used by too many of the Apache projects now to
>>ignore. It looks like it does a fair job of installing itself, if you
>>can get the pieces in the right places.
> 
> 
> Maven is going to be v. hard as a first package - I'd suggest you start
> with something simpler - maybe one of the components needed to build it
> if we haven't packaged it already.  I'm going to release configLog4j
> jrefactory and xjavadoc shortly should be enough to start building
> xdoclet I believe - which is a Maven build require.
> 
> Paul

Yes, and given that it uses a "repository" to hold all the jars required 
for its dependencies, theres a complex issue there with how this 
repository relates to the other jars that jpackage rpm's provide...or is 
this just a red herring?

--

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu