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