Spec URL: http://www.matbooth.co.uk/fedora/brazil.spec SRPM URL: http://www.matbooth.co.uk/fedora/brazil-2.3-1.fc8.src.rpm Description: Brazil is as an extremely small footprint HTTP stack and flexible architecture for adding URL based interfaces to arbitrary applications and devices from Sun Research Labs. This package contains the core set of classes that are not dependent on any other external java libraries. This package is submitted because it is a dependency of eclipse-epic (another new package I am about to submit and will link to shortly). Only the core classes are built and packaged because that is all the needed for eclipse-epic and I didn't want to cause dependencies of all brazil's ancilliary classes to unnecessarily become dependencies for eclipse-epic. And I'm thinking that if demand occurs in the future for the full gamut of brazil classes, I can easily add a brazil-extras sub-package(s) or something. --- I notice that some other Java libs (jdom for example) use the "Development/Libraries/Java" group however this yields a non-standard group rpmlint warning, so I've just used "Development/Libraries" for now. I hope this is fine. Rpmlint on the source rpm gives the following: brazil.src: W: strange-permission get-brazil.sh 0755 This is merely the script that grabs the source from Sun's Download Centre, which is deliberately executable. It can safely be ignored. There's also a minor error in the javadoc generation, but I didn't think it was really worth patching out a single comment line from the source, especially when it doesn't appear to adversely affect it in any way. --- This is the first of two packages I am submitting, the second is dependent on this one. These are my first packages so I'm also looking for sponsorship. While I've been working on this package I've given some pre-reviews on bug #417711 and bug #420161 and I'm planning to do more as time permits. Thanks for your time.
The other new package review I've requested that depends on this package is, predictably enough, bug #426884.
This currently doesn't build on Rawhide because of bug 439168. :-(
(In reply to comment #2) > This currently doesn't build on Rawhide because of bug 439168. :-( Updating findutils seems to fix it, though.
I've updated this package according to the newly approved Java guidelines. The spec also now builds a demo rpm containing sample brazil projects. The spec and srpm are as follows: Spec URL: http://www.matbooth.co.uk/fedora/brazil.spec SRPM URL: http://www.matbooth.co.uk/fedora/brazil-2.3-2.fc9.src.rpm Rpmlint is now silent on all packages.
I'll take this.
Nice job, Mat! A very clean package. Here's my review. Everything's good to go pending spot's legal approval of the fetching (see the last question below, spot). Assuming that is given the go-ahead, this package is APPROVED. MUST items that either have comments or need looking into: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * verify source and patches (md5sum matches upstream, know what the patches do) - the tarball I created using your script didn't have the same md5sum as yours, but a recursive diff of the exploded tarball resulted in no differences so I'll assume it's a timestamp thing ? specfile is legible - two grammar nit-picks (feel free to ignore my pedantry if you wish ;) : "URL based" -> "URL-based" "java" -> "Java" Questions: - does upstream not provide any build mechanism? - have you considered offering upstream your build.xml? - your signal-handling patch doesn't affect runtime, right? - is the script for fetching the source acceptable to Fedora "legal" (CCing spot)? To download myself I had to click through to accept the SPL.
(In reply to comment #6) > Nice job, Mat! A very clean package. Here's my review. Everything's good to > go pending spot's legal approval of the fetching (see the last question below, > spot). Assuming that is given the go-ahead, this package is APPROVED. > Thanks. :-) > MUST items that either have comments or need looking into: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > * verify source and patches (md5sum matches upstream, know what the patches do) > - the tarball I created using your script didn't have the same md5sum as > yours, but a recursive diff of the exploded tarball resulted in no > differences so I'll assume it's a timestamp thing I didn't try md5sum, but you're right. The sum changes every time I run the download script. It strips out all the pre-built binaries and source that isn't used in the build or is licenced differently before tarballing. This can be done at build time instead if it's a problem. > ? specfile is legible > - two grammar nit-picks (feel free to ignore my pedantry if you wish ;) : > "URL based" -> "URL-based" > "java" -> "Java" > No problem, I'll change them. > Questions: > > - does upstream not provide any build mechanism? Yes, but their ant script is incomplete (missing Javadoc build, mostly). I think it'll be easier to maintain a separate script than to massively patch upstream's in this case. > - have you considered offering upstream your build.xml? I have now. I may shoot an email at their mailing list about it... > - your signal-handling patch doesn't affect runtime, right? That's the real question. I have only ever used brazil as part of the EPIC Perl Eclipse plugin and since that is the only package that uses it, I've only tested it as part of that. The is no, as far as I can tell. Eclipse is able to stop and start the brazil server and CGI process without problem for my CGI Perl projects. The reason for patch was to get it building on GCJ, however it does build without the patch on the OpenJDK. What would be the right thing do here, drop support for GCJ in favour of less modifications to the upstream code? > - is the script for fetching the source acceptable to Fedora "legal" (CCing > spot)? To download myself I had to click through to accept the SPL. I wanted to make it an easy and automated process, since I'm lazy like that. The SPL licence is included in the main package and the source files are each headed with licence information, though alternative download instructions could be included if I fail a Spot check. :-) Thanks for your time. PS, did you mean to assign the bug to me?
(In reply to comment #7) > The reason for patch was to get it building on GCJ, however it does build > without the patch on the OpenJDK. What would be the right thing do here, drop > support for GCJ in favour of less modifications to the upstream code? I think what you've done is fine. If someone notices problems with brazil on its own, we can always revert the patch. Please post new URLs when you have them for the grammatical changes (if you're going to change them ... they're not blockers). spot: I'm putting the ball in your court here for a decision on the click-through situation.
(In reply to comment #8) > Please post new URLs when you have them for the grammatical changes (if you're > going to change them ... they're not blockers). > Sure, I was just waiting to see if I needed to change anything else. SPEC and SRPM are as follows: Spec URL: http://www.matbooth.co.uk/fedora/brazil.spec SRPM URL: http://www.matbooth.co.uk/fedora/brazil-2.3-3.fc9.src.rpm
Thanks, Mat. Outside of spot's thoughts on the click-through situation, this is APPROVED.
Script is fine, sorry it took so long. :)
Thanks Tom and Andrew for all your help.
New Package CVS Request ======================= Package Name: brazil Short Description: Extremely small footprint Java HTTP stack Owners: mbooth Branches: F-9 InitialCC: Cvsextras Commits: yes
I assume from comment #10 this is approved, so setting the fedora-review flag to +. ;) cvs done.
I'd like an F-8 branch of this to support the F-8 branch of eclipse-epic. See: https://bugzilla.redhat.com/show_bug.cgi?id=426884#c28 Package Change Request ====================== Package Name: brazil New Branches: F-8
cvs done.
Built for all requested branches. Closing.