Red Hat Bugzilla – Bug 509856
Review Request: qrencode - The libqrencode library and application encodes QR Code symbols (2d barcodes)
Last modified: 2013-10-19 10:42:52 EDT
Spec URL: http://people.redhat.com/bowe/rpms/qrencode/qrencode.spec
SRPM URL: http://people.redhat.com/bowe/rpms/qrencode/qrencode-3.1.0-1.fc11.src.rpm
qrencode is a C application for encoding data in a QR Code symbol, a
kind of 2D symbology that can be scanned by handy terminals such as a
mobile phone with CCD. The capacity of QR Code is up to 7000 digits or
4000 characters, and is highly robust.
IN NEED OF SPONSOR: this is my first package.
This is an unofficial review:
rpmlint of spec file:
$ rpmlint qrencode.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
Building the package:
1) checking pkg-config is at least version 0.9.0... yes
checking for png... configure: error: Package requirements ("libpng12")
were not met:
No package 'libpng12' found
After installing "libpng-devel" it completes so should be added to the
BuildRequires of course.
2) Rpath errors. If you add
%__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
to your ~/.rpmmacros which you do by running "rpmdev-setuptree" then
you get the following...
ERROR 0001: file '/usr/bin/qrencode' contains a standard rpath '/usr/lib64' in [/usr/lib64]
error: Bad exit status from /var/tmp/rpm-tmp.6ynHaY (%install)
missed comment #1 notification. looking now...
hmmm... must be a 64 bit thing... i've got %__arch_install_post as speced, and still seeing a clean build:
>> Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.odUISp
>> extracting debug info from /home/bowe/rpmbuild/BUILDROOT/qrencode->3.1.0-1.fc11.i386/usr/lib/libqrencode.so.3.1.0
>> 230 blocks
>> + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
>> + /usr/lib/rpm/redhat/brp-compress
also, i'm familiar with concept but not implementation, but can't find rpath reference in executable:
[bowe@granny d]$ rpm2cpio /home/bowe/rpmbuild/RPMS/i586/qrencode-3.1.0-1.fc11.i586.rpm | cpio -id
[bowe@granny d]$ readelf -a usr/bin/qrencode | grep -i -e rpath -e lib64
at any rate, blindly added second solution in guidelines.
updated spec file at
updated srpm at
rpath is indeed generally a 64-bit thing. Libtool somehow knows not to add /usr/lib to rpath, but can't figure out not to add /usr/lib64. That's libtool for you. However, when you add hacks like those sed calls over libtool, it's best to also add a comment indicating why it's necessary.
You should not duplicate those doc files between the main and -devel packages.
Are you sure the license is GPLv2 only? It looks like LGPLv2+ to me. The COPYING file contains the LGPL and the source code and upstream web site all says:
* [...] GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or any later version.
which is what we call LGPLv2+.
Fix that up and I can go ahead and do a full review.
sed hacks commented, doc files trimmed (duped COPYING only), and obviously went too quickly when examining licenses... sorry :(.
updated spec file at
updated srpm at
ping... just making sure the ball's in yall's court...
Some random comments
? About enabling tests
- As this package contains tests/ directory, it is usually highly recommended
that you add %check section and execute some test program there.
However for this package to execute test_all.sh under tests/ directory
we have to add "--with-tests" option explicitly to configure
- because without this option some symbols needed for test program are
marked as "static" and these symbols are not included in libqrencode.so.
i.e. when "--with-tests" option is added to configure, it will add
some addtional symbols to libqrencode.so which seems to be used only
the test program in this tarball.
So while I think generally executing test program is preferable, for this
package I am not sure. How do you think?
- Please consider to use
make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
to keep timestamps on installed files as much as possible (especially
on header files).
This method usually works for Makefiles generated from recent autotools.
* pkgconfig file
- Currently I don't see any reason why pkgconfig file should be deleted.
This pkgconfig file may be used by other applications.
- You don't have to add documents to subpackages which are already
included in the main package.
- to me some extra symbols doesn't seem overly burdensome, if the library
doesn't bloat much. never used a %check before, though, so would need
to research it some, and currently under the gun. am willing to add it
in future, but want to incorporate other quick changes.
- pgkconfig kept
- install -p added
- migrated docs from -devel to base package, rpmlint now warns there's no docs. shrug.
updated spec file at
updated srpm at
Well, now this package itself is okay, so:
NOTE: Before being sponsored:
This package will be accepted with another few (or no) work.
But before I accept this package, someone (I am a candidate)
must sponsor you.
Once you are sponsored, you have the right to review other
submitters' review requests and approve the packages formally.
For this reason, the person who want to be sponsored (like you)
are required to "show that you have an understanding
of the process and of the packaging guidelines" as is described
Usually there are two ways to show this.
A. submit other review requests with enough quality.
B. Do a "pre-review" of other person's review request
(at the time you are not sponsored, you cannot do
a formal review)
When you have submitted a new review request or have pre-reviewed other
person's review request, please write the bug number on this bug report
so that I can check your comments or review request.
Fedora package collection review requests which are waiting for someone to
review can be checked on my wiki page:
(Check "No one is reviewing")
Review guidelines are described mainly on:
I will close this bug as NOTABUG within one week if no response
is received from the reporter within ONE WEEK.
yep... at this point, i'm finding myself motivated to maintain this package, but can't find the motivation to carve out some time to learn to review others.
if that's not a fit with the fedora mentality, i'd understand, and may try again later when life has less competing requirements.
Well, as written above I request all submitter who needs sponsorship
to either submit another review request or do at least one pre-review
if _I_ am going to sponsor him/her.
So without it I am not going to sponsor you, however some other sponsor
(sponsors are not only me) may want to sponsor you. So for now I will
revoke the role of reviewing this ticket so that you can find other
sponsor and get sponsored.
Re: comment 16
> if that's not a fit with the fedora mentality, [...]
As another potential sponsor, who has run into this ticket, let me add the following:
For a lower barrier to entry, I approve some packagers' accounts without requiring them to do reviews of stuff they may not have any interest in. You can review a hundred [perhaps trivial] packages and do packaging mistakes in your own packages nevertheless. Sometimes, someone wants to maintain a single package only, but shows off sufficient motivation in becoming a Fedora package contributor. If during the review process such a person is easy to deal with, responsive and open to hints and corrections, that's a chance to get sponsored because of criteria which are unrelated to having done prior reviews. If later on, the person changes attitudes and causes trouble, sponsorship may be revoked.
If, on the contrary, a review -- like this one -- is not trouble-free already, the chance to get sponsored is reduced.
You may find somebody inside Red Hat to sponsor you nevertheless based on other criteria, but during this review your comments/answers have been counterproductive.
It was not my intent to show disrespect, and I greatly appreciate the
time that Steve, Jason, and Mamoru have spent in reviewing my submission.
With the exception of %check, I thought I had willingly implemented all of the suggestions.
By submitting packaging I was already doing for another project, I
hoped to learn to make more compliant packages, and to contribute to
the Fedora project what I think is worthwhile and relevant software,
and my efforts in supporting that software through future releases.
Through the process, I'm learning that the Fedora project greatly values
time spent reviewing the work of others. This seems wise, and could
well be the policy which keeps the system working. I certainly have
respect for the process of peer review.
Due to family, work, repetative stress, circadean rhythms, yadda yadda,
however, it's not something I think I can currently commit to. In my
previous life as a grad student, in my subsequent life as a senile old
man, with hope even next month, my decisions could well be different.
I like to consider OSS and in particular Linux as one of the cathedrals of
our age, a beautiful work of craftmanship to which people devote lifetimes
of effort. My intent wasn't to p*** off its artisans...
Thank you for all of your contributions!
*** This bug has been marked as a duplicate of bug 612533 ***