Bug 457288

Builds fine; rpmlint says:
  snobol.x86_64: W: devel-file-in-non-devel-package /usr/lib/snobol4/snotypes.h
and the same for several other headers.  The point of this package is to produce C code so this makes sense, although I then wonder if it shouldn't have a dependency on gcc.

  snobol.x86_64: E: only-non-binary-in-usr-lib
Is there anything arch-specific in /usr/lib?  Would /usr/share be a better place for those files?

There's also a README file in /usr/lib/ which is a duplicate of what's in the docdir.

I note that the compiler is called like "gcc -O3 -O2 -g -pipe..." which looks a bit odd, although I've confirmed that at least current gcc will ignore the -O3 in this case, but you might consider patching out the -O3 entirely.

Can you comment on why the debuginfo generation is broken.  I know it is turned off because the package would be empty, but it would be better to know why it is empty as that may be a bug that needs fixing.

* source files match upstream:
   53503e412953ddf31149cd36aa3cd7ce164c2a149e33309fe7c583be54c791ae  
   snobol4-1.1.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
o compiler flags are appropriate (well, there's an extra -O3 which is currently 
   ignored).
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
? debuginfo package is disabled for unknown reasons.
X rpmlint has a valid complaint.
? final provides and requires are sane:
   snobol = 4.1.1-1.fc10
   snobol(x86-64) = 4.1.1-1.fc10
  =
   libgdbm.so.2()(64bit)
  Would a gcc dependency be in order?
* %check is not present, but there are some tests run as part of the build 
   process which seem to succeed (see timing.out).
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
X README file is duplicated.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are present in the main package because this is a compiler.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.

I have investigate some works in the packages ant have uploaded 
the most recent releases.

I have some monor issue if I'm trying to set the soname because the test suite fails, if I do it.

Perhaps someone have a idea for the readon of the failure.

Uploaded stuff:

Spec URL: http://www.herr-schmitt.de/pub/snobol/snobol.spec
SRPM URL: http://www.herr-schmitt.de/pub/snobol/snobol-4.1.1-2.fc9.src.rpm

So I guess you know that fails to build.  It's odd; the regression test passes, the timing test includes this in its output:
  timing run of genc.sno:
  ERROR: genc.sno output is bad; compare timdir.22167/stdout with snobol4.c
and the build log has:
  ./timing > timing.out
  ./xsnobol4: error while loading shared libraries: libsnobol-4.1.1.so: cannot 
   open shared object file: No such file or directory

Maybe the problem is that LD_LIBRARY_PATH needs to be set when "timing" is called as well?

I was able to fix the outstanding issues.

Uploaded stuff:

Spec URL: http://www.herr-schmitt.de/pub/snobol/snobol.spec
SRPM URL: http://www.herr-schmitt.de/pub/snobol/snobol-4.1.1-3.fc9.src.rpm

-------

This does build, but rpmlint complains about many undefined-non-weak-symbols (for things that should be in libm and such).  I don't know if this is a real issue or not.

It also complains:
  snobol-devel.x86_64: E: no-ldconfig-symlink /usr/lib64/libsnobol.so
and indeed libsnobol.so seems to be just a file instead of the expected symlink.    There's also this near the end of the build:
  *** WARNING: identical binaries are copied, not linked:
          /usr/lib64/libsnobol.so.4
     and  /usr/lib64/libsnobol.so

Seems that the install command doesn't seem to preserve symlinks.

Thank you for your feedback.

A new release of the package can find at:

Spec URL: http://www.herr-schmitt.de/pub/snobol/snobol.spec
SRPM URL: http://www.herr-schmitt.de/pub/snobol/snobol-4.1.1-4.fc9.src.rpm

This builds but fails to install.  I think I just fixed this myself last time and forgot to comment on it:
  Requires:	snobol=${version}
You really want a '%' there, and spaces around the '='.  This causes some missing dependency issues when you try to install the -devel package.

The undefined-non-weak symbol complaints are still there, but otherwise there are no rpmlint issues.  Please fix the above typo when you check in (unless you like receiving those broken dependency reports, I guess).

APPROVED

(In reply to comment #7)
> This builds but fails to install.  I think I just fixed this myself last time
> and forgot to comment on it:

Can you tell me any error message. I have try to install on my system without any error message.

>   Requires: snobol=${version}
> You really want a '%' there, and spaces around the '='.  This causes some
> missing dependency issues when you try to install the -devel package.
 
This issue should be fixed.

> The undefined-non-weak symbol complaints are still there, but otherwise there
> are no rpmlint issues.  Please fix the above typo when you check in (unless you
> like receiving those broken dependency reports, I guess).

How do you generate this messages about the undef. non-weak symbols?

New stuff:

Spec URL: http://www.herr-schmitt.de/pub/snobol/snobol.spec
SRPM URL: http://www.herr-schmitt.de/pub/snobol/snobol-4.1.1-5.fc9.src.rpm

-------

The error was simply a broken dependency; the -devel package depended on a package named "snobol=${version}" (i.e. nothing was expanded).

I no longer have the -4 rpm to test but I could re-introduce the typo if needed.

To get the undefined-non-weak-symbol complaints, install the package and run "rpmlint snobol".  You should see 30 of them, at least on x86_64.

Thank you for your hint. I have tried to minimize the count of undef. non-weak symbols.

Unfortunately, It's not possible to remove all, but afaik this is not a blocker to approve a package.

New stuff:

Spec URL: http://www.herr-schmitt.de/pub/snobol/snobol.spec
SRPM URL: http://www.herr-schmitt.de/pub/snobol/snobol-4.1.1-5.fc9.src.rpm

This is still approved; you are welcome to make your CVS request at any time.

I did build the -5 package and there are indeed fewer undefined-non-weak-symbol complaints which, as you noted, are not blockers.  There's also this:
  snobol.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libsnobol.so.4.1.1 
   /lib64/libdl.so.2
which is odd but also not a blocker.

New Package CVS Request
=======================
Package Name:snobol
Short Description: snobol - Macro Implementation of SNOBOL4 in C
Owners:s4504kr
Branches:F-9, F-8
InitialCC:
Packager Commits: yes

cvs done.

Imported and built