1 Dec 2004 10:58
1 Dec 2004 13:22
1 Dec 2004 13:27
Re: ibm/blackdown 1.4.2
I could but I would not spam everybody with these specsBut it could be interesting to clearly open access for external contribution to jpackage and give this information on the jpackage.org web site. I'm sur there will be some people that would like to contribute to jpackage sometimes, like me, but doesn't have access of jpackage team... Le ven 26/11/2004 à 17:24, Henri Gomez a écrit : > What about sending the spec and patches on this list instead ? > > Regards > > > On Fri, 26 Nov 2004 11:11:08 +0100, DiSToAGe <distoage@...> wrote: > > I have posted the source packages of jdk ibm-1.4.2 and blackdown-1.4.2 I > > just created, to www.jpackage.org/incoming/jpackage. If you are > > interested ... > > -- -- "Perhaps one day "computer science" will, like Yugoslavia, get broken up into its component parts. That might be a good thing. Especially if it meant independence for my native land, hacking." (hackers and Painters) [ Paul Graham ]
1 Dec 2004 13:28
Re: AW: [patch] update tomcat 5 RPM to 5.0.28
Fernando Nasser wrote: > OK, I am removing my objection to this. > > We may be even be using the Servlet API 2.4 from some other source > (Geronimo or Classpath) or eventually Tomcat folks will wise up and > separate the 'jakarta-servletapi' from Tomcat and release it as a > tar ball instead of pointing people to the CVS tree. > > So, although I don't like the "unprefixed" subpackages as a norm, in > this case we may be better off doing it as we may still hope to not > have to build these together with Tomcat. > > And we avoid the Obsoletes... This is the main reason for my suggesting it. It's more future proof. If we do go with tomcat5-servletapi (which Obsoletes servletapi5) and then the Jakarta folks release servletapi as a separate tarball then our options will be limited: we wouldn't be able to recreate the servletapi5 source package (which would have to Obsolete tomcat5-servletapi) as we'd end up with an Obsoletes loop. Gary
1 Dec 2004 13:53
tomcat + security manager
I have started using jpackage some weeks ago and one of problems that I found is like the reported at this message : http://lists.zarb.org/pipermail/jpackage-discuss/2004-August/010691.html I did not found a bugzilla system to report the solution, then I'm sending to the list. When running with security manager tomcat use the definitions at conf/catalina.policy. That file gives AllPermission to directories {common,shared,server}/- like this : grant codeBase "file:${catalina.home}/common/-" { permission java.security.AllPermission; }; JPackage uses a lot of links in this directories pointing to files on /usr/share/java. The JVM resolves the links before checking for permissions, and then the linked packages does not have any permissions. There are 2 possible solutions to be used : grant codeBase "file:/usr/share/java/-" { permission java.security.AllPermission; }; or scan the tomcat directories for links, resolve them and create permissions for all real jar files. I prefer the second option and I'm using it in my systems. I have one(Continue reading)
1 Dec 2004 15:22
Re: tomcat + security manager
I'd be interested in seeing the scripts. I do a lot of work with the security manager, but the systems I use it on are solaris and thus not using JPackage. Thanks, Jason On Wed, 1 Dec 2004 10:53:32 -0200, Ivan F. Martinez <ml@...> wrote: > I have started using jpackage some weeks ago and one of problems that I > found is like the reported at this message : > > http://lists.zarb.org/pipermail/jpackage-discuss/2004-August/010691.html > > I did not found a bugzilla system to report the solution, then I'm > sending to the list. > > When running with security manager tomcat use the definitions at > conf/catalina.policy. > > That file gives AllPermission to directories {common,shared,server}/- > like this : > grant codeBase "file:${catalina.home}/common/-" { > permission java.security.AllPermission; > }; > > JPackage uses a lot of links in this directories pointing to files on > /usr/share/java. The JVM resolves the links before checking for > permissions, and then the linked packages does not have any permissions. > > There are 2 possible solutions to be used : > grant codeBase "file:/usr/share/java/-" {(Continue reading)
1 Dec 2004 15:58
Re: ibm/blackdown 1.4.2
On 1 Dec 2004, at 12:27, DiSToAGe wrote: > But it could be interesting to clearly open access for external > contribution to jpackage and give this information on the jpackage.org > web site Why not put them up on your own site and send the link to the list? That's what I did and they got inIt's also how Fedora.us seems to work most of the time. Carwyn
1 Dec 2004 17:05
Re: AW: [patch] update tomcat 5 RPM to 5.0.28
Le mardi 30 novembre 2004 à 14:43 -0500, Fernando Nasser a écrit : > OK, I am removing my objection to this. > > We may be even be using the Servlet API 2.4 from some other source > (Geronimo or Classpath) or eventually Tomcat folks will wise up and > separate the 'jakarta-servletapi' from Tomcat and release it as a tar > ball instead of pointing people to the CVS tree. > > So, although I don't like the "unprefixed" subpackages as a norm, in > this case we may be better off doing it as we may still hope to not have > to build these together with Tomcat. > > And we avoid the Obsoletes... You can always get by with a Provides: and have your package require the virtual. This way once you move to another implementation (or just have a parallel implementation in the tree) you just move the virtual without doing complex naming magic. I dislike unprefixed names (we have a few in the tree). It makes very difficult to associate rpms with srpms (now again virtuals are sometimes difficult to associate with actual packages, so I may just be blinded by past habits) Regards, -- -- Nicolas Mailhot
(Continue reading)
1 Dec 2004 17:00
Re: Packaging process
Le mardi 30 novembre 2004 à 12:04 +1100, Tim Nelson a écrit : > Hmm. Well, I need tocmat4 as part of my job, so I'd have no > problems justifying putting time into that to my bosses here, but putting > in other stuff, I'm not so sure about (and everything else I need seems > to work, thanks to the JPackage project!) The contribution perimeter is strictly up to each member, ie sitting on one package only is all right (you do end up fixing your package deps now and then though). What's not ok is getting membership the time of one commit and never doing anything again afterwards, be it for other packages or the package you've just submitted. If it's all right with you I'll put on your name for approval. Regards, -- -- Nicolas Mailhot
_______________________________________________ JPackage-discuss mailing list JPackage-discuss@... https://www.zarb.org/mailman/listinfo/jpackage-discuss
1 Dec 2004 16:55
Re: jmxtools alternatives ?
Le mercredi 01 décembre 2004 à 13:22 +0100, R.Apel@... a écrit : > We currently have alternatives for > jmxri > jmxremoteri > > Should there also be alternatives for > jmxtoolsri ? When I created the jmxri alternative there was no working alternative for jmxtools. If mx4j-tools is able to accomodate the needs of the packages that need jmx-tools now (from memory, one of the avalon of logging packages) then by all means let's create the alternative. Please just check it works before creating the alternative;) Cheers, -- -- Nicolas Mailhot
_______________________________________________ JPackage-discuss mailing list JPackage-discuss@... https://www.zarb.org/mailman/listinfo/jpackage-discuss
RSS Feed