[Bug 286851] Review Request: kaya - A Statically typed, imperative programming-language

[bugzilla at redhat.com]

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

Summary: Review Request: kaya - A Statically typed, imperative programming-language


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





------- Additional Comments From tibbs at math.uh.edu  2008-04-29 16:12 EST -------
Yes, that does build.  I believ this is very close now; just a few bits left.

First, some compiler flag issues:
Could you explain the CFLAGS bit in %build?  It seems to have no effect.

This package just seems to do its own random stuff with compiler flags, which is
troubling.  It ignores the ones we pass to the configure call, but that can at
least superficially be fixed with this hack at the end of %prep:
  sed -i -e 's/^\(EXTRAGCCOPTS=\).*$/\1"%optflags"/' \
         -e 's/^  EXTRAGCCOPTS.*stack-protector.*/  true/' configure.ac
Things still build with this hack (and the test suite passes) but it seems that
these options get passed through to the compiler itself and that causes a pile
of warnings (and the debuginfo package still comes out empty when enabled, which
strangely, means it has even less data than it would without this hack).

So, if the standard compiler flags don't work, could you document that
somewhere?  Could you also document the need to disable the debuginfo package
instead of just disabling it?  Random hacks like that need some sort of comment
in the specfile.

The documentation is about 60% of the size of the package.  Some basic manpages
are useful but I'm not sure it's worth putting all of the development
documentation in with the main package.  Have you considered splitting it out to
a subpackage?

* source files match upstream:
   1c8a817d6435475793e6d662c96c04d68b894b4602d3e65f25291938e955332e  
   kaya-0.4.0.tgz
* 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.
? compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
   kaya = 0.4.0-4.fc9
  =
   libgc.so.1()(64bit)
   libgcc_s.so.1()(64bit)
   libgcc_s.so.1(GCC_3.0)(64bit)
   libgcrypt.so.11()(64bit)
   libgcrypt.so.11(GCRYPT_1.2)(64bit)
   libgmp.so.3()(64bit)
   libncurses.so.5()(64bit)
   libpcre.so.0()(64bit)
   libreadline.so.5()(64bit)
   libstdc++.so.6()(64bit)
   libstdc++.so.6(CXXABI_1.3)(64bit)
   libstdc++.so.6(GLIBCXX_3.4)(64bit)
   libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
   libutil.so.1()(64bit)
   libz.so.1()(64bit)
* %check is present and all tests pass.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
? documentation is pretty large; maybe a separate -doc package would be useful.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* 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, or are watching someone who is.