[Bug 457288] Review Request: snobol - Macro Implementation of SNOBOL4 in C

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=457288


Jason Tibbitts <tibbs@xxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody@xxxxxxxxxxxxxxxxx    |tibbs@xxxxxxxxxxx




--- Comment #1 from Jason Tibbitts <tibbs@xxxxxxxxxxx>  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.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-package-review

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]