*** Bug 179039 has been marked as a duplicate of this bug. ***

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.

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: 

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

Created attachment 125330 [details]
Failed build log

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.

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.

* 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

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?

(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.

(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.

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

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.

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.

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.

Created attachment 129980 [details]
FC5/x86_64 failed build log

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

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.

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.

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

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!

Everything builds fine and now rpmlint is silent.  The issues I had are fixed.

APPROVED