Bug 457288 - Review Request: snobol - Macro Implementation of SNOBOL4 in C
Review Request: snobol - Macro Implementation of SNOBOL4 in C
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-30 13:29 EDT by Jochen Schmitt
Modified: 2008-09-10 13:58 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-10 13:58:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Jochen Schmitt 2008-07-30 13:29:06 EDT
Spec URL: http://www.herr-schmitt.de/pub/snobol/snobol.spec
SRPM URL: http://www.herr-schmitt.de/pub/snobol/snobol-4.1.1-1.fc9.src.rpm

Description:
NOBOL4, while known primarily as a string language excels at any task
involving symbolic manipulations.  It provides run time typing,
garbage collection, user data types, on the fly compilation.  It's
primary weakness is it's simple syntax, and lack of "structured
programming" and "object oriented" constructs.
Comment 1 Jason Tibbitts 2008-08-16 14:48:38 EDT
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.
Comment 2 Jochen Schmitt 2008-08-17 16:46:02 EDT
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
Comment 3 Jason Tibbitts 2008-08-18 11:30:49 EDT
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?
Comment 4 Jochen Schmitt 2008-08-18 11:56:01 EDT
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

-------
Comment 5 Jason Tibbitts 2008-08-19 19:04:02 EDT
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.
Comment 6 Jochen Schmitt 2008-08-20 10:29:19 EDT
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
Comment 7 Jason Tibbitts 2008-08-20 12:30:44 EDT
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
Comment 8 Jochen Schmitt 2008-08-20 14:22:21 EDT
(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

-------
Comment 9 Jason Tibbitts 2008-08-20 14:28:33 EDT
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.
Comment 10 Jochen Schmitt 2008-08-21 13:10:47 EDT
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
Comment 11 Jason Tibbitts 2008-08-25 19:26:37 EDT
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.
Comment 12 Jochen Schmitt 2008-09-08 12:06:41 EDT
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
Comment 13 Kevin Fenzi 2008-09-09 22:19:00 EDT
cvs done.
Comment 14 Jochen Schmitt 2008-09-10 13:58:15 EDT
Imported and built

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