ports/96613: misc/linux-opengroupware doesn't install or run

[Mike Durian]

>Number:         96613
>Category:       ports
>Synopsis:       misc/linux-opengroupware doesn't install or run
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 01 18:50:14 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Mike Durian
>Release:        FreeBSD 6.1-PRERELEASE i386
>Organization:
>Environment:
System: FreeBSD oak.shadetreesoftware.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #2: Fri Feb 10 17:36:07 MST 2006 root at oak.shadetreesoftware.com:/usr/obj/usr/src/sys/SHADETREE i386


	
>Description:
	There must be something strange about my machine, as other people
	apparently can install and run linux-opengroupware, but I can't
	figure out how they do it.  I've run into a number of problems
	trying to get this port installed an running.

	1) In the Makefile, CPIOFLAGS includes --no-absolute-filenames.  This
	   option is not supported by cpio on my system:

	   # /usr/bin/cpio --no-absolute-filenames
	   cpio: unrecognized option `--no-absolute-filenames'

	   cpio does support --absolute-filenames, which makes me think the
	   condition you are looking for is the default.  I worked around
	   this by removing --no-absolute-filenames from CPIOFLAGS

	2) The ogo.sh and zideshow.sh start script try to use su(1) with
	   the -c option to specify a command to run.  The -c option does
	   not specify a command.  It specifies a login class.

	   Ah, I found it.  At one point, -c was not an su(1) option.
	   It would be passed to /bin/sh to interpret.  However, the
	   CVS logs show FreeBSD added the -c option to su(1) back in
	   October of 1997.  At first it was conditionalized by LOGIN_CAP,
	   but that was removed in 1.34.2.4 back in June 2002.  The
	   opengroupware port wasn't created until October 2003, so I'm
	   not sure how it ever worked (I must be missing something
	   in the su(1) CVS logs).

	   I worked around this by removing the -c argument and removing the
	   comments.  As in:

	   su -l ${OGO_USER} \
	           ./WOApps/OpenGroupware.woa/ix86/linux-gnu/gnu-fd-nil/OpenGroupware -WOHttpAllowHost '(localhost, you.yourdomain.org)' >>${LOG} 2>&1 &

	3) Then I ran into unresolved libraries.  OpenGroupware wants to link
	   against libssl.so.0.9.6, but all I have in /compat/linux/lib
	   is libssl.so.0.9.6b.  The port does create a symbolic link for
	   libssl.so.9.6 that points to libssl.so.0.9.6b, so I created a
	   new one for libssl.so.0.9.6.

	   The same thing applies to libcrypt.0.9.6.

	4) Now I can start OpenGroupware by hand, but when I try to start
	   it via the ogo.sh script, I get the following error in
	   /var/log/opengroupware/ogo.log:

	   ./WOApps/OpenGroupware.woa/ix86/linux-gnu/gnu-fd-nil/OpenGroupware: ./WOApps/OpenGroupware.woa/ix86/linux-gnu/gnu-fd-nil/OpenGroupware: cannot execute binary file

	   I think the "cannot execute binary file" message comes from bash(1),
	   but I cannot tell if it is the linux bash or the FreeBSD native
	   bash I've installed.  I can't figure out why it would be displayed
	   either as OpenGroupware has 755 privileges.

>How-To-Repeat:
	Try to install and run misc/linux-opengroupware from the ports
	collection.
>Fix:

	I've listed some partial fixes above, but now I'm stuck with the
	"cannot execute binary file" error.  I'm not sure what to do next.


>Release-Note:
>Audit-Trail:
>Unformatted: