Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 179040 - Review Request: socat
Summary: Review Request: socat
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
: 179039 (view as bug list)
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-01-26 20:26 UTC by Paul Wouters
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-23 02:47:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Failed build log (deleted)
2006-02-27 17:15 UTC, John Mahowald
no flags Details
FC5 mock build log for socat-1.4.3.1-1.src.rpm (deleted)
2006-05-15 10:55 UTC, Paul Howarth
no flags Details
FC5/x86_64 failed build log (deleted)
2006-05-25 11:54 UTC, Gilboa Davara
no flags Details

Description Paul Wouters 2006-01-26 20:26:13 UTC
Spec Name or Url: ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat.spec
SRPM Name or Url: ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat-1.4.3.0-1.src.rpm
Description: 
socat is a relay for bidirectional data transfer between two independent data
channels. Each of these data channels may be a file, pipe, device (serial line
etc. or a pseudo terminal), a socket (UNIX, IP4, IP6 - raw, UDP, TCP), an
SSL socket, proxy CONNECT connection, a file descriptor (stdin etc.), the GNU
line editor (readline), a program, or a combination of two of these.

Comment 1 Paul Wouters 2006-01-26 20:29:03 UTC
*** Bug 179039 has been marked as a duplicate of this bug. ***

Comment 2 Gabriel Somlo 2006-01-27 00:26:56 UTC
Summary and %description should both start with a capital letter

> %setup -q -n "%{name}-%{mversion}"

use '%setup -q' and get rid of %{mversion}

> export DESTDIR=%{buildroot}
> %{__make} DESTDIR=%{buildroot} install

The 'export DESTDIR' line is redundant, unless you have a broken makefile.

Comment 3 Paul Wouters 2006-01-27 01:09:33 UTC
the mversion is needed because the version is 1.4.3.0 but it untars in socat-1.4/
not socat-1.4.3.0.

export removed, captials fixed....

Spec Name or Url: ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat.spec
SRPM Name or Url:
ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat-1.4.3.0-2.src.rpm
Description: 


Comment 4 John Mahowald 2006-02-27 17:13:56 UTC
1.4.3.0 got Archived, update to latest 1.4.3.1.

Doesn't build on x86_64:
In file included from socat.c:14:
compat.h:114:4: error: #error "HAVE_BASIC_SIZE_T is out of range:" HAVE_BASIC_SIZE_T

Comment 5 John Mahowald 2006-02-27 17:15:49 UTC
Created attachment 125330 [details]
Failed build log

Comment 6 jlbartos 2006-05-09 22:11:53 UTC
When using rpm's configure macro results in:
checking for i686-redhat-linux-gnu-gcc... no
which in turn puts:
checking for equivalent simple type of size_t... 0 /* unknown, taking default */
and
checking for basic type of struct stat.st_dev... 0 /* unknown, taking default */
in config.h
which causes the error in comment #4.
Either changing the two lines in config.h or not passing
i686-redhat-linux-gnu-gcc to %configure allows for compiling.

Comment 7 Paul Wouters 2006-05-10 01:56:02 UTC
so 1.4.3.1 compiles fine for me on x86_64 without any changes.

I've updated the spec and source.rpm:
Spec Name or Url: ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat.spec
SRPM Name or Url:
ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat-1.4.3.1-1.src.rpm

This is on my desktop x86_64 FC4 system with  gcc-4.0.2-8.fc4 and
glibc-2.3.90-12 (the glibc might be one from rawhide)


checking for equivalent simple type of size_t... 6 /* unsigned long */
checking for equivalent simple type of mode_t... 4 /* unsigned int */
checking for equivalent simple type of pid_t... 3 /* int */
checking for equivalent simple type of uid_t... 4 /* unsigned int */
checking for equivalent simple type of gid_t... 4 /* unsigned int */
checking for equivalent simple type of time_t... 5 /* long */
checking for equivalent simple type of socklen_t... 4 /* unsigned int */
checking for equivalent simple type of off64_t... 5 /* long */
checking for basic type of struct stat.st_dev... 6 /* unsigned long */
checking for basic type of struct stat.st_ino... 6 /* unsigned long */
checking for basic type of struct stat.st_nlink... 6 /* unsigned long */
checking for basic type of struct stat.st_size... 5 /* long */
checking for basic type of struct stat.st_blksize... 5 /* long */
checking for basic type of struct stat.st_blocks... 5 /* long */
checking for basic type of struct stat64.st_dev... 6 /* unsigned long */
checking for basic type of struct stat64.st_ino... 6 /* unsigned long */
checking for basic type of struct stat64.st_nlink... 6 /* unsigned long */
checking for basic type of struct stat64.st_size... 5 /* long */
checking for basic type of struct stat64.st_blksize... 5 /* long */
checking for basic type of struct stat64.st_blocks... 5 /* long */
checking for basic type of struct rlimit.rlim_max... 6 /* unsigned long */

If the package is approved, I can run a build on the fedora x86_64 machine to
verify this reported issue further.


Comment 8 Ralf Corsepius 2006-05-10 04:10:41 UTC
* The sources are incomplete. They ship a configure script, but don't ship its
sources (configure.in/configure.ac).
As this package is GPL'ed, this can be read as violation of the GPL (shipping a
crippled package)

* Permissions on many source files are broken. This can result into weird
side-effects on *debug-info-rpms

Comment 9 Paul Wouters 2006-05-12 01:58:48 UTC
Some more packages only put configure.in/configure.ac in their development (CVS)
tree, and just put the configure script and not the autoconf/automake in.
Sometimes this is done to prevent dependancies on autoconfig/automake. I don't
think it is a big issue for building this package.

permissions on the debug rpm files after install is 644 for files and 755 for
directories. So everyone can read everything. What is exactly going wrong?


Comment 10 Ralf Corsepius 2006-05-12 04:16:52 UTC
(In reply to comment #9)
> Some more packages only put configure.in/configure.ac in their development (CVS)
> tree, and just put the configure script and not the autoconf/automake in.
Yes, there exist a broken packages and incompetent maintainers.

> Sometimes this is done to prevent dependancies on autoconfig/automake. I don't
> think it is a big issue for building this package.
I consider this as blocker for 2 reasons:

1. LEGAL
This configure script is clearly autoconf generated. The package claims to be
GPL'ed but ships incomplete sources.

I.e. I consider this package not to be GPL compliant and not to be OSI complaint.


2. TECHNICAL

2.1 It is hardly possible to fix/maintain packages with incomplete sources.
You might know where the source file might be located, but will the person to
adapt this package to FC8 in 2 years still know?

2.2 A package being maintained upstream this way, justifies strong doubts on the
code's quality.

Comment 11 Paul Howarth 2006-05-12 07:16:26 UTC
(In reply to comment #9)
> Some more packages only put configure.in/configure.ac in their development (CVS)
> tree, and just put the configure script and not the autoconf/automake in.
> Sometimes this is done to prevent dependancies on autoconfig/automake. I don't
> think it is a big issue for building this package.

In addition to Ralf's comments, which I agree with, I'd add that it's normal
practice to ship the configure.in/configure.ac and that these do not introduce
buildreqs on autotools if the timestamps on the files are correct, i.e.
configure is later than the files used to generate it.

> permissions on the debug rpm files after install is 644 for files and 755 for
> directories. So everyone can read everything. What is exactly going wrong?

I was going to look into this but the package
(ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat-1.4.3.1-1.src.rpm)
doesn't build for me on my FC5 i386 desktop, with the same failure mode as in
Comment #4.


Comment 12 Paul Wouters 2006-05-12 20:03:04 UTC
Can someone give me a complete log of the build failure mentioned in #4. As I
said, on my X86_64 FC4, it just builds.

I'll contact upstream to ask for inclusion of configure.in/configure/ac

Comment 13 Paul Howarth 2006-05-15 10:55:32 UTC
Created attachment 129046 [details]
FC5 mock build log for socat-1.4.3.1-1.src.rpm

(In reply to comment #12)
> Can someone give me a complete log of the build failure mentioned in #4. As I

> said, on my X86_64 FC4, it just builds.

FC5 mock build log attached.

Comment 14 Paul Wouters 2006-05-19 04:23:15 UTC
upstream will add configure.in/ac in his next release.

I am still investigating why mock builds fail, but my FC4 x86_64 builds fine.

Comment 15 Gilboa Davara 2006-05-25 11:49:01 UTC
I'm getting the same error (as the mock build) on FC5/x86_64.

-However-, when I try to manually build the source tar.bz2, (configure
--prefix=/usr && make -j 8) it builds just fine.


Comment 16 Gilboa Davara 2006-05-25 11:54:22 UTC
Created attachment 129980 [details]
FC5/x86_64 failed build log

Comment 17 Paul Wouters 2006-08-04 16:01:59 UTC
I have upgraded to socat-1.5.0.0. This now includes the proper configure.in, so
that issue is resolved.
Can someone test if it builds properly under mock now?

ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat-1.5.0.0-1.src.rpm
ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat.spec

Comment 18 Jason Tibbitts 2006-08-19 01:32:33 UTC
This does build fine in mock (x86_64, rawhide).  rpmlint says:

W: socat doc-file-dependency /usr/share/doc/socat-1.5.0.0/proxy.sh /bin/bash
W: socat doc-file-dependency /usr/share/doc/socat-1.5.0.0/proxyecho.sh /bin/bash
W: socat doc-file-dependency /usr/share/doc/socat-1.5.0.0/daemon.sh /bin/sh
W: socat doc-file-dependency /usr/share/doc/socat-1.5.0.0/ftp.sh /bin/sh
W: socat doc-file-dependency /usr/share/doc/socat-1.5.0.0/gatherinfo.sh /bin/sh
W: socat doc-file-dependency /usr/share/doc/socat-1.5.0.0/mail.sh /bin/sh
  Documentation should not be executable.

I'll go ahead and work up a full review.

Comment 19 Jason Tibbitts 2006-08-19 03:44:56 UTC
So all of the problems I see arise from those six executable bits of
documentation.  A quick chmod should fix them up.

* source files match upstream:
   84b709de13e236198a4606fb4b80e123  socat-1.5.0.0.tar.bz2
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible.  License text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* debuginfo package looks complete.
X rpmlint is silent.
X final provides and requires are sane:
   socat = 1.5.0.0-1.fc6
  =
   /bin/bash
X   /bin/sh
   libcrypto.so.6()(64bit)
   libncurses.so.5()(64bit)
   libreadline.so.5()(64bit)
   libssl.so.6()(64bit)
   libutil.so.1()(64bit)
* %check is not present; no test suite upstream.
* no shared libraries are added to the regular linker search paths.
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
X file permissions are appropriate (executable documentation)
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.

Comment 20 Ryan Hill 2006-08-19 04:04:18 UTC
re: the build error, we recently had a user encounter the same thing with
socal-1.4.3.1.  i don't know if the causes are the same, but thought you might
find it helpful in some way.

https://bugs.gentoo.org/show_bug.cgi?id=133527

Comment 21 Paul Wouters 2006-08-20 06:39:27 UTC
Thanks for the information! glad to see it builds with mock now.

I've fixed the documentation execute bits in the example shellscripts. I added a
few more examples that i hadn't noticed were added. New specfile and rpms
available at:

ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat-1.5.0.0-2.src.rpm
ftp://ftp.xelerance.com/socat/binaries/fedora/4/SRPMS/socat.spec

Thanks again!

Comment 22 Jason Tibbitts 2006-08-21 23:48:31 UTC
Everything builds fine and now rpmlint is silent.  The issues I had are fixed.

APPROVED


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