Bug 439310 - Review Request: gnue-common - GNU Enterprise Common Base
Review Request: gnue-common - GNU Enterprise Common Base
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: manuel wolfshant
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-27 20:01 EDT by Aaron S. Hawley
Modified: 2008-05-04 16:02 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-04 16:02:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
wolfy: fedora‑review+
kevin: fedora‑cvs+

Attachments (Terms of Use)
failed build log for gnue-common-0.6.9-1.src.rpm (94.77 KB, text/plain)
2008-03-28 06:45 EDT, manuel wolfshant
no flags Details

  None (edit)
Description Aaron S. Hawley 2008-03-27 20:01:00 EDT
Spec URL: https://agave.garden.org/~aaronh/rpm/gnue-common.spec
SRPM URL: https://agave.garden.org/~aaronh/rpm/gnue-common-0.6.9-1.src.rpm
GNU Enterprise Common Library for use with the GNUe tools GNUe-Common
provides a set of images and classes that GNUe-Forms, GNUe-Reports,
GNUe-Appserver and GNUe-Designer and others are dependent upon.  It
implements a database-abstraction layer that provides support for most
major databases. A builtin XML-to-Object parser and Object-to-XML
marshaller are used by Forms, Reports, and Designer to save and read
Forms/Report definitions to and from an XML file. It also defines and
implements an RPC abstraction layer that will allow server processes
to define their public methods once and have them available to CORBA,
XML-RPC, SOAP, and DCOM clients.
Comment 1 Bill Nottingham 2008-03-27 22:19:37 EDT
You may want to fix the cert on your web server...
Comment 2 manuel wolfshant 2008-03-28 06:44:40 EDT
There are a couple of fixes needed:
- the easy ones:
 --prefix=/usr should be converted to --prefix=%_prefix. 
 the package cannot be noarch since it installs files to %{_libdir}

- the ugly one: the package does not build in mock. I have attached the log of
the failed build.
Comment 3 manuel wolfshant 2008-03-28 06:45:40 EDT
Created attachment 299447 [details]
failed build log for gnue-common-0.6.9-1.src.rpm

failed build log for gnue-common-0.6.9-1.src.rpm
Comment 4 Aaron S. Hawley 2008-03-31 00:17:44 EDT
I've changed the SPEC and SRPM files:

Spec URL: https://agave.garden.org/~aaronh/rpm/gnue-common.spec
SRPM URL: https://agave.garden.org/~aaronh/rpm/gnue-common-0.6.9-1.src.rpm

finI didn't think to use a macro in the %install section for the --prefix
setting.  It is fixed.

I've kept it at noarch by using the python_sitelib macro described at:


The mock problem appears to be related to find-debuginfo.sh running, when it
shouldn't run since noarch is set.  Wierd.  I've tried applying brute force by
adding %define debug_package %{nil} at the top of the specfile.  I can't get
mock to work in a fedora-devel-i386, but it builds successfully in mock using

I have modified the spec and source rpm by including a few patches I had forgotten.
Comment 5 Mamoru TASAKA 2008-03-31 01:57:12 EDT
(In reply to comment #3)
> Created an attachment (id=299447) [edit]
> failed build log for gnue-common-0.6.9-1.src.rpm
> failed build log for gnue-common-0.6.9-1.src.rpm

This is bug 439168.
Comment 6 manuel wolfshant 2008-03-31 06:12:17 EDT
Aaron, please increment the release tag each time you modify the spec file and
submit a new rpm for review.

In fedora>=9, a .egg-info is created and it must also be included in the binary
rpm. Your %files section misses that and this leads to
  error: Installed (but unpackaged) file(s) found:
which is easy fixable.

The "Require python>2.3" is not an error, but even Fedora 7 provides python 2.5.
Taking into account that rpmbuild adds automatically "python-abi = <version>" as
a requires, I suggest to completely drop this condition.
Some of the files included as doc are marked as executable and therefore they
bring in some rpmlint warnings and unneeded deps:
gnue-common.noarch: W: spurious-executable-perm
gnue-common.noarch: W: doc-file-dependency
/usr/share/doc/gnue-common-0.6.9/pdftable-example.py /usr/bin/env

rpmlint also gives this warnings:
   gnue-common.noarch: W: conffile-without-noreplace-flag
   gnue-common.noarch: W: conffile-without-noreplace-flag /etc/gnue/sample.gnue.conf
Please examine if these files need or not this flag.

And last but not least, could you please instruct me how can I test that the
application works ?
Comment 7 Aaron S. Hawley 2008-04-01 17:14:14 EDT
"Application"?  That's like asking someone to test glibc.  Try executing the
sample python code and examples in the GNU Enterprise Developer's Guide at:


Or in the Open Office document intalled at

For extra credit create a GNU Enterprise database in MySQL or PostgreSQL.  I'm
working on packaging other tools of GNU Enterprise that depened on gnue-common.
 Those will be the better test.

I've explained in a specfile comment why the sample configuration files should
have noreplace -- users couldn't really use them for anything important, and
they upstream authors should be able to update them.

I added to the release tag this time:

Spec URL: https://agave.garden.org/~aaronh/rpm/gnue-common.spec
SRPM URL: https://agave.garden.org/~aaronh/rpm/gnue-common-0.6.9-2.src.rpm
Comment 8 manuel wolfshant 2008-04-02 14:00:08 EDT
The -2.src.rm you have made available still includes the previous version of the
spec file. The uploaded spec is OK however and using it makes mock happy.

No, a couple of small issues:
The correct license, according to the .py files included in the tar.gz is GPLv2+.
It would be awesome if you could use a single directory for all docs. Now some
of them are under /usr/share/doc/gnue-common while others are in
/usr/share/doc/gnue-common-0.6.9/. Not mandatory, but nicer.
The changelog has a "%config" (second to last line in release 2) which triggers
a rpmlint warning, please replace it with "%%config".

Otherwise everything seems fine, I'll post a full review as soon as I manage to
verify that it works.
Comment 9 Aaron S. Hawley 2008-04-03 12:35:49 EDT
License changed, and put the docs under a single directory using a bit of a
hack.     I didn't know you could run rpmlint on SRPM files.  Good to know.

Spec URL: http://agave.garden.org/~aaronh/rpm/gnue-common.spec
SRPM URL: http://agave.garden.org/~aaronh/rpm/gnue-common-0.6.9-3.src.rpm
Comment 10 manuel wolfshant 2008-04-04 18:40:41 EDT
Package Review based on version
https://agave.garden.org/~aaronh/rpm/gnue-common-0.6.9-2.src.rpm + my memories
of spec 0.6.9-3 (which I've read but not preserved)
I cannot check 0.6.9-3, neither  https://agave.garden.org/ nor 
http://agave.garden.org/ seem to be up for the momen

 - = N/A
 x = Check
 ! = Problem
 ? = Not evaluated

 [x] Package is named according to the Package Naming Guidelines.
 [x] Spec file name must match the base package %{name}, in the format %{name}.spec.
 [x] Package meets the Packaging Guidelines.
 [x] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Tested on: devel/x86_64
 [x] Rpmlint output:
source RPM: empty
binary RPM:
gnue-common.noarch: W: conffile-without-noreplace-flag
gnue-common.noarch: W: conffile-without-noreplace-flag /etc/gnue/sample.gnue.conf
--> ignorable given the comments in the spec
 [x] Package is not relocatable.
 [x] Buildroot is correct (%{_tmppath}/%{name}-%{version}-%{release}-root)
 [x] Package is licensed with an open-source compatible license and meets other
legal requirements as defined in the legal section of Packaging Guidelines.
 [x] License field in the package spec file matches the actual license.
     License type:GPLv2+
 [x] If (and only if) the source package includes the text of the license(s) in
its own file, then that file, containing the text of the license(s) for the
package is included in %doc.
 [x] Spec file is legible and written in American English.
 [x] Sources used to build the package matches the upstream source, as provided
in the spec URL.
     SHA1SUM of package:4fe0472e345ef5b544a4db8cf44b104a6ba45f3d 
 [x] Package is not known to require ExcludeArch
 [x] All build dependencies are listed in BuildRequires, except for any that are
listed in the exceptions section of Packaging Guidelines.
 [-] The spec file handles locales properly.
 [-] ldconfig called in %post and %postun if required.
 [x] Package must own all directories that it creates.
 [x] Package requires other packages for directories it uses.
 [x] Package does not contain duplicates in %files.
 [x] Permissions on files are set properly.
 [x] Package has a %clean section, which contains rm -rf %{buildroot} (or
 [x] Package consistently uses macros.
 [x] Package contains code, or permissable content.
 [-] Large documentation files are in a -doc subpackage, if required.
 [x] Package uses nothing in %doc for runtime.
 [-] Header files in -devel subpackage, if present.
 [-] Static libraries in -devel subpackage, if present.
 [-] Package requires pkgconfig, if .pc files are present.
 [-] Development .so files in -devel subpackage, if present.
 [-] Fully versioned dependency in subpackages, if present.
 [x] Package does not contain any libtool archives (.la).
 [-] Package contains a properly installed %{name}.desktop file if it is a GUI
 [x] Package does not own files or directories owned by other packages.

 [x] Latest version is packaged.
 [x] Package does not include license text files separate from upstream.
 [-] Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
 [x] Reviewer should test that the package builds in mock.
     Tested on: devel/x86_64
 [x] Package should compile and build into binary rpms on all supported
     Tested on:all archs supported by koji scratch build
 [?] Package functions as described.
 [x] Scriptlets must be sane, if used.
 [-] The placement of pkgconfig(.pc) files is correct.
 [-] File based requires are sane.

=== Issues ===
Everything seems OK so far.
I still have to verify functionality.
Comment 11 Aaron S. Hawley 2008-04-05 14:14:44 EDT
Those files should be accessible, now.
Comment 12 manuel wolfshant 2008-04-05 19:37:22 EDT
Everything seems OK, I used it for a very simple test program which did actually
work as intended, so the package is APPROVED.

Just for the record: I did not say anything about including the INSTALL file
(which we usually do not ship) only because of the last three lines in it.
Comment 13 Aaron S. Hawley 2008-04-06 16:37:38 EDT
Manuel, thanks again for my sponsorship and for reviewing this package.  I'm not
part of the GNU Enterprise project, but your work will likely be seen as a
gracious contribution to the GNU Enterprise project.

New Package CVS Request
Package Name: gnue-common
Short Description: GNU Enterprise Common Base
Owners: ashawley
Branches: F-7 F-8
Cvsextras Commits: yes
Comment 14 Kevin Fenzi 2008-04-08 14:06:22 EDT
cvs done.
Comment 15 Aaron S. Hawley 2008-05-04 16:02:42 EDT

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