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: liblrdf
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189313
------- Additional Comments From green@redhat.com 2006-04-23 08:31 EST ------- Thanks for looking at this. Updated bits here:
Spec URL: http://people.redhat.com/green/FE/FC5/liblrdf.spec SRPM URL: http://people.redhat.com/green/FE/FC5/liblrdf-0.4.0-4.src.rpm
(In reply to comment #2)
- Until raptor-devel will be good, this one BuildRequires: libxslt-devel
I've submitted a fixed raptor spec file.
- Run rpmlint on the binary rpms:
Lots of output, in particular because the included "examples" %doc directory contains arch-dependent files (it MUST NOT), including unfinished libtool based executables in the hidden .libs directory, object files, and dependency meta data files in the hidden .deps directory.
I've removed examples from the doc list, and added a README.fedora file to point people at the SRPM for example source code.
- rpmqfcheck.pl /home/qa/tmp/rpm/RPMS/liblrdf-0.4.0-3.i386.rpm
Orphaned dir: /usr/share/ladspa Orphaned dir: /usr/share/ladspa/rdf
I'm not sure who should own these directories. Perhaps this package should own /usr/share/ladspa/rdf, and ladspa could own /usr/share/ladspa - although there's no real need to install the ladspa package when using ladspa plugins. Suggestions?
- Source0 would be directly downloadable if in the form:
Fixed.
- Static libraries should not be included.
Fixed. Configured with --disable-static.
- Noticable compiler warnings:
showdefaults.c:42: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' setting_test.c:43: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'
This is from the example directory, which is ignored now.
lrdf.c:596: warning: pointer targets in passing argument 1 of 'raptor_new_uri' differ in signedness lrdf.c:597: warning: pointer targets in passing argument 1 of 'raptor_new_uri' differ in signedness
I will push this upstream rather than try to handle it here. It's a signed-vs-unsigned char thing.