Bug 471915 - Review Request: jbossweb2 - JBoss Web Server based on Apache Tomcat
Review Request: jbossweb2 - JBoss Web Server based on Apache Tomcat
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Permaine Cheung
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2008-11-17 12:08 EST by David Walluck
Modified: 2010-12-03 10:39 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 04:14:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Walluck 2008-11-17 12:08:23 EST
Spec URL: <http://fedorapeople.org/~dwalluck/jbossweb2.spec>
SRPM URL: <http://fedorapeople.org/~dwalluck/jbossweb2-2.1.1-2.jpp5.src.rpm>
Description:
JBoss Web Server is an enterprise ready web server designed for medium
and large applications, based on the Apache Tomcat. It is meant to be
used as a replacement for the standard Web servers on all major
platforms. JBoss Web Server provides organizations with a single
deployment platform for Java Server Pages (JSP) and Java Servlet
technologies, Microsoft .NET, PHP, and CGI. It uses a genuine high
performance hybrid technology that incorporates the best of the most
recent OS technologies for processing high volume data, while keeping
all the reference Java specifications. It supports both in and out of
the process execution of CGI and PHP scripts, as well as .NET
applications. The hybrid technology model offers the best from
threading and event processing models, and that makes the JBoss Web
Server one of the fastest and most scalable web servers in the market.
Comment 1 Permaine Cheung 2008-11-18 16:52:25 EST
I'll take this one.
Comment 2 Permaine Cheung 2008-11-18 17:18:44 EST
There are a few BuildRequires in this package that doesn't exist in Fedora, here's what I'm seeing in a mock build:

No Package Found for javamail_1_3_1_api
No Package Found for wsdl4j16
No Package Found for jbossas >= 0:4.2.0
Comment 3 David Walluck 2008-11-19 12:08:50 EST
We really need to get the geronimo API's into Fedora. Alternatively, we could update existing Fedora packages with these provides. For now, I will simply change javamail_1_3_1_api to javamail.

I will change wsdl4j16 to wsdl4j (1.5.2). Then, jbossweb just needs to be able to build against this version as we don't require wsdl4j at runtime.

The jbossas dependency can be removed. The jboss logging sources are bundled along with jbossweb. There is a question as to whether these should be removed and we should be them as an external dependency first.
Comment 5 Permaine Cheung 2008-11-19 15:43:03 EST
I still can't build with the new srpm in mock with rawhide, I'm getting:

    [javac] 182. ERROR in /builddir/build/BUILD/jbossweb2-2.1.1/java/org/apache/catalina/ant/jmx/JMXAccessorTask.java (at line 42)
    [javac]     import javax.management.remote.JMXConnector;
    [javac]            ^^^^^^^^^^^^^^^^^^^^^^^
    [javac] The import javax.management.remote cannot be resolved
    [javac] ----------
    [javac] 183. ERROR in /builddir/build/BUILD/jbossweb2-2.1.1/java/org/apache/catalina/ant/jmx/JMXAccessorTask
    [javac] .java (at line 43)
    [javac]     import javax.management.remote.JMXConnectorFactory;
    [javac]            ^^^^^^^^^^^^^^^^^^^^^^^
    [javac] The import javax.management.remote cannot be resolved
    [javac] ----------
    [javac] 184. ERROR in /builddir/build/BUILD/jbossweb2-2.1.1/java/org/apache/catalina/ant/jmx/JMXAccessorTask.java (at line 44)
    [javac]     import javax.management.remote.JMXServiceURL;
    [javac]            ^^^^^^^^^^^^^^^^^^^^^^^
    [javac] The import javax.management.remote cannot be resolved

....
and a few others.

Does it needs a BR on mx4j or some other package?
Comment 6 David Walluck 2008-11-19 16:52:02 EST
I built the RPM in rawhide x86_64. What JDK is being used? tomcat6 doesn't have a requirement on mx4j, so I suspect it might be a JDK5 vs. JDK6 issue.
Comment 7 Permaine Cheung 2008-11-19 17:34:02 EST
I was trying to build it in rawhide i386.
Looking at root.log, here are some of the packages installed:
DEBUG util.py:250:   java-1.5.0-gcj-devel    i386       1.5.0.0-22.fc10  fedora             46 k
DEBUG util.py:250:   java-1.5.0-gcj          i386       1.5.0.0-22.fc10  fedora            132 k
DEBUG util.py:250:   java-1.6.0-openjdk      i386       1:1.6.0.0-2b12.fc10  fedora             29 M

the java-devel is the 1.5.0 gcj one, so it's the JDK5 vs. JDK6 then?
Was yours built with JDK 6?
Comment 8 Permaine Cheung 2008-11-20 08:22:00 EST
I tried a rawhide x86_64 build and it builds successfully, and from root.log, these packages installed:

DEBUG util.py:250:   java-1.5.0-gcj-devel    x86_64     1.5.0.0-22.fc10  fedora             46 k
DEBUG util.py:250:   java-1.6.0-openjdk-devel  i386       1:1.6.0.0-2b12.fc10  fedora             12 M
DEBUG util.py:250:   java-1.5.0-gcj          x86_64     1.5.0.0-22.fc10  fedora            132 k
DEBUG util.py:250:   java-1.6.0-openjdk      i386       1:1.6.0.0-2b12.fc10  fedora             29 M

I wonder if openjdk-devel get installed on this buildroot randomly.
I tried another i386 build, and it still fails as mentioned above.
Comment 9 David Walluck 2008-11-20 10:27:51 EST
Why is it only pulled in on x86_64 when it should be the default on i386 also? Is there really something that requires that explicitly or does it have something to do with comps.xml (or who can we ask)?

The larger problem is that we will have to force this so that other archs work as well. There's no consistency in the build roots, so we are always forced to change from JPackage to require JDK6.

Since we don't have a better solution right now, I will make the JDK change and upload again.
Comment 10 Permaine Cheung 2008-11-20 14:26:06 EST
I'm not sure it's only pulled in on x64_64 because of some explicit Requires: or it has to do with comps.xml. I'm not sure who we can ask either.
Comment 12 Permaine Cheung 2008-11-21 14:06:11 EST
Naming - OK
Legal - OK 
Licensing - OK  - LGPLv3
No inclusion of pre-built binaries or libraries - OK, removed in %prep
verify any sources and patches :
* Should the TOMCAT_CFG file be set to /etc/jbossweb/jbossweb2.conf instead of /etc/jbossweb/jbossweb.conf in jbossweb2-2.1-tool-wrapper.script?
verify that the license stated in the spec file matches the actual license of the software - OK
skim the summary and description for typos and oddities - OK
make sure that the correct build root is used - OK
ensure that macro usage is consistent - OK
* rpmlint output:

[pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.src.rpm
jbossweb2.src:86: E: hardcoded-library-path in /lib/lsb/init-functions
jbossweb2.src:87: E: hardcoded-library-path in /lib/lsb/init-functions
jbossweb2.src:145: W: unversioned-explicit-provides jsp21
jbossweb2.src:173: W: unversioned-explicit-provides servlet6
jbossweb2.src:174: W: unversioned-explicit-provides servlet25
jbossweb2.src: W: non-standard-group Networking/Daemons

[pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.noarch.rpm
jbossweb2.noarch: E: non-standard-gid /var/cache/jbossweb2/temp jbossweb
jbossweb2.noarch: E: non-standard-dir-perm /var/cache/jbossweb2/temp 0775
jbossweb2.noarch: E: non-standard-gid /var/lib/jbossweb2/webapps jbossweb
jbossweb2.noarch: E: non-standard-dir-perm /var/lib/jbossweb2/webapps 0775
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/webapps /var/lib/jbossweb2/webapps
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/conf /etc/jbossweb2
jbossweb2.noarch: W: dangling-symlink /usr/share/jbossweb2/lib /usr/share/java/jbossweb2
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/lib /usr/share/java/jbossweb2
jbossweb2.noarch: E: non-standard-gid /var/cache/jbossweb2/work jbossweb
jbossweb2.noarch: E: non-standard-dir-perm /var/cache/jbossweb2/work 0775
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/work /var/cache/jbossweb2/work
jbossweb2.noarch: E: non-standard-gid /etc/jbossweb2/tomcat-users.xml jbossweb
jbossweb2.noarch: E: non-readable /etc/jbossweb2/tomcat-users.xml 0660
jbossweb2.noarch: E: non-standard-gid /var/log/jbossweb2 jbossweb
jbossweb2.noarch: E: non-standard-dir-perm /var/log/jbossweb2 0775
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/temp /var/cache/jbossweb2/temp
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/logs /var/log/jbossweb2
jbossweb2.noarch: E: non-standard-gid /etc/jbossweb2/Catalina/localhost jbossweb
jbossweb2.noarch: E: non-standard-dir-perm /etc/jbossweb2/Catalina/localhost 0775
jbossweb2.noarch: W: non-standard-group Networking/Daemons
jbossweb2.noarch: W: dangerous-command-in-%preun rm
jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}

[pcheung@tonka result]$ rpmlint jbossweb2-admin-webapps-2.1.1-4.2.fc10.noarch.rpm
jbossweb2-admin-webapps.noarch: W: no-documentation
jbossweb2-admin-webapps.noarch: W: non-standard-group System Environment/Applications

[pcheung@tonka result]$ rpmlint jbossweb2-docs-webapp-2.1.1-4.2.fc10.noarch.rpm
jbossweb2-docs-webapp.noarch: W: no-documentation
jbossweb2-docs-webapp.noarch: W: non-standard-group System Environment/Applications

[pcheung@tonka result]$ rpmlint jbossweb2-javadoc-2.1.1-4.2.fc10.noarch.rpm

[pcheung@tonka result]$ rpmlint jbossweb2-jsp-2.1-api-2.1.1-4.2.fc10.noarch.rpm
jbossweb2-jsp-2.1-api.noarch: W: no-documentation
jbossweb2-jsp-2.1-api.noarch: W: non-standard-group Internet/WWW/Dynamic Content

[pcheung@tonka result]$ rpmlint jbossweb2-lib-2.1.1-4.2.fc10.noarch.rpm 
jbossweb2-lib.noarch: W: no-documentation
jbossweb2-lib.noarch: W: dangling-relative-symlink /usr/share/java/jbossweb2/jbossweb2-servlet-2.5-api-2.1.1.jar ../jbossweb2-servlet-2.5-api-2.1.1.jar
jbossweb2-lib.noarch: W: dangling-relative-symlink /usr/share/java/jbossweb2/jbossweb2-jsp-2.1-api-2.1.1.jar ../jbossweb2-jsp-2.1-api-2.1.1.jar
jbossweb2-lib.noarch: W: non-standard-group Development/Compilers
jbossweb2-lib.noarch: W: dangerous-command-in-%preun rm

[pcheung@tonka result]$ rpmlint jbossweb2-servlet-2.5-api-2.1.1-4.2.fc10.noarch.rpm
jbossweb2-servlet-2.5-api.noarch: W: no-documentation
jbossweb2-servlet-2.5-api.noarch: W: non-standard-group Internet/WWW/Dynamic Content

[pcheung@tonka result]$ rpmlint jbossweb2-webapps-2.1.1-4.2.fc10.noarch.rpm
jbossweb2-webapps.noarch: W: no-documentation
jbossweb2-webapps.noarch: W: non-standard-group System Environment/Applications

Changelog - OK
Tags - OK
Requires - OK
BuildRequires - OK
Summary & description - OK
Encoding - OK
Documentation - OK
Initscripts
* Following https://fedoraproject.org/wiki/Packaging/SysVInitScript, this needs the following :
# This is for /sbin/service
Requires(preun): initscripts

and also a # description line following right after chkconfig: line

Why does the init script use the lsb/init-functions instead of the regular one?

File and Directory ownership - OK
Users and Groups:
* Should the shell for jbossweb /sbin/nologin?
Web Applications - OK
* Should the default TOMCAT_USER be jbossweb2(instead of tomcat) in /etc/jbossweb/jbossweb2.2.1.init?

No Files or Directories under /srv - OK

All patches should have an upstream bug link or comment:
* Please add comments for the patches

The BuildRequires and Requires section in the Java packaging guidelines have the following:
At a minimum, Java packages MUST:

BuildRequires: java-devel [>= specific_version] 
BuildRequires:  jpackage-utils

Requires:  java >= specific_version
Requires:  jpackage-utils

For historical reasons, when specifying versions 1.6.0 or greater, an epoch of 1 must be included. Example:

Requires: java >= 1:1.6.0

Please update the BR and R to the above format.
Comment 13 David Walluck 2008-11-21 14:33:48 EST
I fixed TOMCAT_CFG (which was wrong in both scripts) and TOMCAT_USER.

The initscript is an LSB initscript (for cross-distro compatibility). I don't know that LSB is against Fedora policy in any way. LSB does not require chkconfig or service, but I added the description line just in case.

I added comments to the Patch lines in the spec. There are no corresponding upstream bugs.

I used java-1.6.0 and java-1.6.0-devel which has the same effect but avoids the epoch mess mentioned.

The JDK is also set to /usr/lib/jvm/java-1.6.0, but I wonder if this won't work if java-devel is not installed, and it's not required. Does setting it to /usr/lib/jvm/jre-1.6.0 in /etc/sysconfig/jbossweb2 work as expected?
Comment 15 David Walluck 2008-11-24 10:22:11 EST
Here are my justifications for rpmlint warnings. If it's the same warning/error I don't list it twice.

[pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.src.rpm
jbossweb2.src:86: E: hardcoded-library-path in /lib/lsb/init-functions
jbossweb2.src:87: E: hardcoded-library-path in /lib/lsb/init-functions

This file is in /lib on both i386 and x86_64.

jbossweb2.src:145: W: unversioned-explicit-provides jsp21
jbossweb2.src:173: W: unversioned-explicit-provides servlet6
jbossweb2.src:174: W: unversioned-explicit-provides servlet25

The versions are in the names.

jbossweb2.src: W: non-standard-group Networking/Daemons

Fedora allows any Group tag.

[pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.noarch.rpm
jbossweb2.noarch: E: non-standard-gid /var/cache/jbossweb2/temp jbossweb
jbossweb2.noarch: E: non-standard-dir-perm /var/cache/jbossweb2/temp 0775
jbossweb2.noarch: E: non-standard-gid /var/lib/jbossweb2/webapps jbossweb
jbossweb2.noarch: E: non-standard-dir-perm /var/lib/jbossweb2/webapps 0775

This is correct since it's a daemon, if we agree on the perms.

jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/webapps
/var/lib/jbossweb2/webapps
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/conf
/etc/jbossweb2
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/lib
/usr/share/java/jbossweb2
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/work
/var/cache/jbossweb2/work
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/temp
/var/cache/jbossweb2/temp
jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/logs
/var/log/jbossweb2

I am not sure how to fix these, or what the actual problem is.

jbossweb2.noarch: E: non-readable /etc/jbossweb2/tomcat-users.xml 0660

This file contains passwords, so it should not be world readable.

jbossweb2.noarch: W: dangerous-command-in-%preun rm

# clean tempdir and workdir on removal or upgrade
/bin/rm -rf /var/cache/jbossweb2/work/* /var/cache/jbossweb2/temp/*

This allows the rpm to be removed cleanly, but it's not typical to do this. What do you think?

jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}

This uses a variable in case the name of the script is changed, but since NAME is NAME="$(basename $0)", it is fine.

[pcheung@tonka result]$ rpmlint
jbossweb2-admin-webapps-2.1.1-4.2.fc10.noarch.rpm
jbossweb2-admin-webapps.noarch: W: no-documentation

Documentation is in the main package.

[pcheung@tonka result]$ rpmlint jbossweb2-lib-2.1.1-4.2.fc10.noarch.rpm 
jbossweb2-lib.noarch: W: dangling-relative-symlink
/usr/share/java/jbossweb2/jbossweb2-servlet-2.5-api-2.1.1.jar
../jbossweb2-servlet-2.5-api-2.1.1.jar
jbossweb2-lib.noarch: W: dangling-relative-symlink
/usr/share/java/jbossweb2/jbossweb2-jsp-2.1-api-2.1.1.jar
../jbossweb2-jsp-2.1-api-2.1.1.jar

This is because the links are actually in another package, but jbossweb2-lib Requires that package, so it's fine.

jbossweb2-lib.noarch: W: dangerous-command-in-%preun rm

if [ "$1" = "0" ]; then
    /bin/rm -f /usr/share/java/jbossweb2/\[commons-collections-tomcat5\].jar \
        /usr/share/java/jbossweb2/\[commons-dbcp-tomcat5\].jar \
        /usr/share/java/jbossweb2/\[commons-pool-tomcat5\].jar \
        /usr/share/java/jbossweb2/\[ecj\].jar >/dev/null 2>&1
fi

This is to clean dangling symlinks. Is it valid?
Comment 16 Permaine Cheung 2008-11-27 08:19:29 EST

(In reply to comment #15)
> Here are my justifications for rpmlint warnings. If it's the same warning/error
> I don't list it twice.
> 
> [pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.src.rpm
> jbossweb2.src:86: E: hardcoded-library-path in /lib/lsb/init-functions
> jbossweb2.src:87: E: hardcoded-library-path in /lib/lsb/init-functions
> 
> This file is in /lib on both i386 and x86_64.
> 
> jbossweb2.src:145: W: unversioned-explicit-provides jsp21
> jbossweb2.src:173: W: unversioned-explicit-provides servlet6
> jbossweb2.src:174: W: unversioned-explicit-provides servlet25
> 
> The versions are in the names.
> 
> jbossweb2.src: W: non-standard-group Networking/Daemons
> 
> Fedora allows any Group tag.
> 
> [pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.noarch.rpm
> jbossweb2.noarch: E: non-standard-gid /var/cache/jbossweb2/temp jbossweb
> jbossweb2.noarch: E: non-standard-dir-perm /var/cache/jbossweb2/temp 0775
> jbossweb2.noarch: E: non-standard-gid /var/lib/jbossweb2/webapps jbossweb
> jbossweb2.noarch: E: non-standard-dir-perm /var/lib/jbossweb2/webapps 0775
> 
> This is correct since it's a daemon, if we agree on the perms.
Should the perm be 0755?

> 
> jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/webapps
> /var/lib/jbossweb2/webapps
> jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/conf
> /etc/jbossweb2
> jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/lib
> /usr/share/java/jbossweb2
> jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/work
> /var/cache/jbossweb2/work
> jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/temp
> /var/cache/jbossweb2/temp
> jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/logs
> /var/log/jbossweb2
> 
> I am not sure how to fix these, or what the actual problem is.
> 
These seems to be ok.

> jbossweb2.noarch: E: non-readable /etc/jbossweb2/tomcat-users.xml 0660
> 
> This file contains passwords, so it should not be world readable.
> 
> jbossweb2.noarch: W: dangerous-command-in-%preun rm
> 
> # clean tempdir and workdir on removal or upgrade
> /bin/rm -rf /var/cache/jbossweb2/work/* /var/cache/jbossweb2/temp/*
> 
> This allows the rpm to be removed cleanly, but it's not typical to do this.
> What do you think?
Hmm... ff the content of these directories are not cleaned, do they just sit there and the rpm can't be removed?


> 
> jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
> jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
> jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
> jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME}
> 
> This uses a variable in case the name of the script is changed, but since NAME
> is NAME="$(basename $0)", it is fine.
> 
> [pcheung@tonka result]$ rpmlint
> jbossweb2-admin-webapps-2.1.1-4.2.fc10.noarch.rpm
> jbossweb2-admin-webapps.noarch: W: no-documentation
> 
> Documentation is in the main package.
> 
> [pcheung@tonka result]$ rpmlint jbossweb2-lib-2.1.1-4.2.fc10.noarch.rpm 
> jbossweb2-lib.noarch: W: dangling-relative-symlink
> /usr/share/java/jbossweb2/jbossweb2-servlet-2.5-api-2.1.1.jar
> ../jbossweb2-servlet-2.5-api-2.1.1.jar
> jbossweb2-lib.noarch: W: dangling-relative-symlink
> /usr/share/java/jbossweb2/jbossweb2-jsp-2.1-api-2.1.1.jar
> ../jbossweb2-jsp-2.1-api-2.1.1.jar
> 
> This is because the links are actually in another package, but jbossweb2-lib
> Requires that package, so it's fine.
> 
> jbossweb2-lib.noarch: W: dangerous-command-in-%preun rm
> 
> if [ "$1" = "0" ]; then
>     /bin/rm -f /usr/share/java/jbossweb2/\[commons-collections-tomcat5\].jar \
>         /usr/share/java/jbossweb2/\[commons-dbcp-tomcat5\].jar \
>         /usr/share/java/jbossweb2/\[commons-pool-tomcat5\].jar \
>         /usr/share/java/jbossweb2/\[ecj\].jar >/dev/null 2>&1
> fi
> 
> This is to clean dangling symlinks. Is it valid?

Do they need to be removed explicitly? don't they get removed automatically during rpm -e?

One thing that's still there is the shell for jbossweb is /bin/sh instead of /sbin/nologin.
Comment 17 Tom "spot" Callaway 2008-12-25 16:51:29 EST
Blocking against FE-Legal on advice from Red Hat Legal counsel. I'll get more information after the holiday break.
Comment 18 Tom "spot" Callaway 2009-01-11 16:40:33 EST
So, the key problem that Red Hat Legal identified was with the licensing on the JSON code (java/org/apache/tomcat/util/json/JSON*):

/*
Copyright (c) 2002 JSON.org

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

The Software shall be used for Good, not Evil.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
*/

The sentence "The Software shall be used for Good, not Evil." makes it non-free, as it is impossible for us to abide by that use-case restriction. We hit this once before with a different package, and tried to contact the copyright holder, but he was unwilling to alter the line (changing "shall" to "should" would suffice to make it a suggestion rather than a legal requirement). Either this code needs to be removed (from both the source and the binary RPM) or JSON.org needs to relicense it without that sentence.

In addition to that, the license tag is incorrect on the package, there is no LGPLv3 code in this package that I could see, all of it is either Apache 2.0, LGPLv2+ or the non-free license I mentioned above. Remember that the presense of LICENSING/COPYING does not signal license versioning in the case of GPL/LGPL.

Ignoring the "Evil" license, the License tag should be:

License: LGPLv2+ and ASL 2.0
Comment 19 Elliott Baron 2009-01-13 13:51:14 EST
I came across this problem with the JSON license before. There is an Apache licensed source zip available from http://www.json.org/java/apache.zip.
I'm not sure how it came about, it's not referenced on the main page, I came across it in an Apache mailing list - http://www.nabble.com/JSON-License-td5252908.html.
Comment 20 Andrew Overholt 2009-01-29 16:39:20 EST
Is this Apache-licensed zip acceptable?  We have another package that has yet to be submitted for review because it needs this json library.
Comment 21 Tom "spot" Callaway 2009-02-27 09:37:57 EST
Sure. That zip is ASL 2.0, which is fine.

Since JSON seems to be useful for multiple projects, would it make sense to package it separately?
Comment 22 Andrew Overholt 2009-02-27 11:54:43 EST
(In reply to comment #21)
> Sure. That zip is ASL 2.0, which is fine.

Awesome!
 
> Since JSON seems to be useful for multiple projects, would it make sense to
> package it separately?

Yes.
Comment 23 Tom "spot" Callaway 2009-02-27 11:57:53 EST
So, the logical followup is that someone should make a JSON package, get it reviewed, then have this package pull out its local copy and depend on the JSON package. This will also prevent odd things like having eclipse bits depend on a JBoss Web Server. ;)

It should be a trivial package, feel free to poke me when it is ready for review.
Comment 24 Andrew Overholt 2009-02-27 14:56:01 EST
You are completely correct.
Comment 25 Tom "spot" Callaway 2009-03-12 11:37:18 EDT
(In reply to comment #24)
> You are completely correct.  

Is any progress being made on a JSON package for Fedora (and fixing jbossweb2 to use that JSON package)?
Comment 26 Andrew Overholt 2009-03-12 11:46:59 EDT
(In reply to comment #25)
> (In reply to comment #24)
> > You are completely correct.  
> 
> Is any progress being made on a JSON package for Fedora (and fixing jbossweb2
> to use that JSON package)?  

I know nothing about jbossweb2 but I figure I can bite the bullet and make a JSON package.  After EclipseCon (week after next) I'll have time to do it.
Comment 27 Milos Jakubicek 2009-05-14 19:05:32 EDT
Any progress on the JSON package?
Moreover: will this package provide jboss-common-jdbc-wrapper.jar? (the spec and SRPMs are not available anymore)
Comment 28 Andrew Overholt 2009-05-15 08:33:32 EDT
The JSON package is done (although I may have forgotten to build it ... will check).  I don't know about the JBoss JAR.
Comment 29 Andrew Overholt 2009-05-15 08:33:59 EDT
I did build it:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1304544
Comment 30 Milos Jakubicek 2009-05-15 20:59:19 EDT
Great, let's move with this review forwards then:)

I'd appreciate somebody (probably the reporter;) to make a scratch build again so that I can find out whether jbossweb2 will provide jboss-common-jdbc-wrapper.jar which I need to update mysql-connector-java from a years-old-and-nothing-providing version to current. Thanks in advance.
Comment 31 Milos Jakubicek 2009-05-15 21:03:26 EDT
...just forgot: Andrew, would you mind building and releasing json as an update for F9/10/11? It will enable doing the same with jbossweb2 later on, thanks.
Comment 32 Andrew Overholt 2009-05-19 08:42:02 EDT
(In reply to comment #31)
> ...just forgot: Andrew, would you mind building and releasing json as an update
> for F9/10/11? It will enable doing the same with jbossweb2 later on, thanks.  

How would you like to be a co-maintainer?  Then you can do it and help out when I suck at maintaining :)
Comment 33 Milos Jakubicek 2009-05-19 12:08:05 EDT
Heh...ok ;) Request done in pkgdb.
Comment 34 Milos Jakubicek 2009-07-26 15:28:59 EDT
Ping...where does it stuck?
Comment 35 Jerry James 2009-08-25 13:03:54 EDT
The latest findbugs needs mysql-connector-java 5.1.7 or later (supposedly; I'm looking at a potential way to dodge that bullet), which needs this work done first (see comment 30).  Is there anything I can do to help move this forward?
Comment 36 Tom "spot" Callaway 2009-11-30 20:07:22 EST
I'm going to lift FE-Legal here, on the assumption that this package will use the ASL 2.0 JSON package.
Comment 37 Alexander Kurtakov 2010-10-07 09:19:19 EDT
Is this package still worked on?
David, Permaine?
Comment 38 Alexander Kurtakov 2010-12-03 04:14:45 EST
I'm closing the bug because of no activity in a long period. Please reopen or open a new one when this package is ready for review again.

Note You need to log in before you can comment on or make changes to this bug.