Spec URL: https://github.com/lzap/spec_reviews/raw/master/inih-devel.spec SRPM URL: http://kojipkgs.fedoraproject.org//work/tasks/9778/4579778/inih-devel-r26-1.fc17.x86_64.rpm Description: The inih package provides simple INI file parser which is only a couple of pages of code, and it was designed to be small and simple, so it's good for embedded systems. Fedora Account System Username: lzap http://koji.fedoraproject.org/koji/taskinfo?taskID=4579777 [lzap@lzapx ~]$ rpmlint /home/lzap/rpmbuild/SRPMS/inih-devel-r26-1.f15.src.rpm inih-devel.src: W: invalid-url URL: http://inih.googlecode.com/files/inih_r26.zip HTTP Error 404: Not Found inih-devel.src: W: invalid-url Source0: inih_r26.zip 1 packages and 0 specfiles checked; 0 errors, 2 warnings. [lzap@lzapx ~]$ rpmlint /home/lzap/rpmbuild/RPMS/x86_64/inih-devel-r26-1.fc17.x86_64.rpm inih-devel.x86_64: W: invalid-url URL: http://inih.googlecode.com/files/inih_r26.zip HTTP Error 404: Not Found 1 packages and 0 specfiles checked; 0 errors, 1 warnings. The 404 error is because upstream will be releasing this version shortly. I already tested with this version. I packaged STATIC only version: https://fedorahosted.org/fpc/ticket/216 since this library is meant for embedding.
URL: http://inih.googlecode.com/files/inih_%{version}.zip Source0: inih_%{version}.zip This is wrong. It should be https://fedoraproject.org/wiki/Packaging:SourceURL#Referencing_Source URL: http://inih.googlecode.com/ Source0: http://inih.googlecode.com/files/inih_%{version}.zip ** No headers?! ** Static library must be in -static package. https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Packaging_Static_Libraries
Headers and source URL fixed, thanks! I believe according to the guidelines I should follow this rule: Static libraries only. When a package only provides static libraries you can place all the static library files in the *-devel subpackage. When doing this you also must have a virtual Provide for the *-static package. Therefore I created -devel package which provides -static package. SPEC: https://raw.github.com/lzap/spec_reviews/master/inih-devel.spec RPM: http://kojipkgs.fedoraproject.org//work/tasks/4331/4594331/inih-devel-r26-1.fc19.x86_64.rpm SRPM: http://kojipkgs.fedoraproject.org//work/tasks/4331/4594331/inih-devel-r26-1.fc19.src.rpm https://github.com/lzap/spec_reviews/commit/e3d646ff0f071ad31aedfe0c71da21fe81302ab7 (I forgot to bump release, I apologize for that.).
Keep in mind, if you link to packages from a Koji scratch build, these packages will be crowded after two weeks. This has been happened now... That's why the links to rpm and srpm are 404.
Right, SPEC: https://raw.github.com/lzap/spec_reviews/master/inih-devel.spec SRPM: http://lzap.fedorapeople.org/fedora-packaging/inih-devel/r26-1/inih-devel-r26-1.fc19.src.rpm RPM: http://lzap.fedorapeople.org/fedora-packaging/inih-devel/r26-1/inih-devel-r26-1.fc19.x86_64.rpm
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4724084 $ rpmlint -i -v * inih-devel-debuginfo.i686: I: checking inih-devel-debuginfo.i686: I: checking-url http://inih.googlecode.com/ (timeout 10 seconds) inih-devel-debuginfo.i686: E: empty-debuginfo-package This debuginfo package contains no files. This is often a sign of binaries being unexpectedly stripped too early during the build, rpmbuild not being able to strip the binaries, the package actually being a noarch one but erratically packaged as arch dependent, or something else. Verify what the case is, and if there's no way to produce useful debuginfo out of it, disable creation of the debuginfo package. inih-devel-debuginfo.x86_64: I: checking inih-devel-debuginfo.x86_64: I: checking-url http://inih.googlecode.com/ (timeout 10 seconds) inih-devel-debuginfo.x86_64: E: empty-debuginfo-package This debuginfo package contains no files. This is often a sign of binaries being unexpectedly stripped too early during the build, rpmbuild not being able to strip the binaries, the package actually being a noarch one but erratically packaged as arch dependent, or something else. Verify what the case is, and if there's no way to produce useful debuginfo out of it, disable creation of the debuginfo package. inih-devel.i686: I: checking inih-devel.i686: I: checking-url http://inih.googlecode.com/ (timeout 10 seconds) inih-devel.src: I: checking inih-devel.src: I: checking-url http://inih.googlecode.com/ (timeout 10 seconds) inih-devel.src: I: checking-url http://inih.googlecode.com/files/inih_r26.zip (timeout 10 seconds) inih-devel.src: W: invalid-url Source0: http://inih.googlecode.com/files/inih_r26.zip HTTP Error 404: Not Found The value should be a valid, public HTTP, HTTPS, or FTP URL. inih-devel.x86_64: I: checking inih-devel.x86_64: I: checking-url http://inih.googlecode.com/ (timeout 10 seconds) inih-devel.spec: I: checking-url http://inih.googlecode.com/files/inih_r26.zip (timeout 10 seconds) inih-devel.spec: W: invalid-url Source0: http://inih.googlecode.com/files/inih_r26.zip HTTP Error 404: Not Found The value should be a valid, public HTTP, HTTPS, or FTP URL. 5 packages and 1 specfiles checked; 2 errors, 2 warnings. The Googlecode tarball is downloadable with wget, no problem. The debuginfo package is empty. The EXTRACFLAGS statement seems to doesn't work. I'm wondering if it is possible to get debuginfo for static libraries...? I'm a bit confused about: http://www.debuginfo.com/articles/gendebuginfo.html#debuginfostaticlib
> I'm a bit confused about: > http://www.debuginfo.com/articles/gendebuginfo.html#debuginfostaticlib That's a page about Visual C++. > Name: inih-devel > Provides: inih-static = %{version}-%{release} Wouldn't it be more future-proof to name the src.rpm "inih"? And make it build only a -devel subpackage with a virtual -static package (or vice versa). > Summary: Simple INI file parser Summary: Simple INI file parser library Mentioning the term "library" could be helpful as the package name does not start with "lib".
Sorry for the delay. """ Um, there's little reason to include static libraries in -debuginfo packages, as static libraries always contain the needed symbols to get a backtrace, and are (or at least were on ~RHL9 time frame) including debugging info in the *.a files. """ https://bugzilla.redhat.com/show_bug.cgi?id=209316 Turning off debuginfo as it does not make any sense, or "little". I tried to find more info about that, but could not find anything relevant. >Wouldn't it be more future-proof to name the src.rpm "inih"? I understand, but I have to follow "Packaging Static Libraries". Or did I misinterpret something? Summary fixed. https://github.com/lzap/spec_reviews/commit/2c75164318d9bd69519f60123afd0847c161b1e0 http://koji.fedoraproject.org/koji/taskinfo?taskID=4868819 Please ping me if you want to proceed with the formal review and I will upload SPEC/SRPM files. Thank you.
(In reply to comment #7) > >Wouldn't it be more future-proof to name the src.rpm "inih"? > > I understand, but I have to follow "Packaging Static Libraries". Or did I > misinterpret something? This wouldn't break the packaging guidelines, as far as I can evaluate. The "inih" source rpm doesn't result in a "inih" package, but in "inih-static" only. This way it can uniquely recognized as a static library package. The virtual "inih-devel" package is rather unneeded.
Ok so please confirm if I understand correctly - you recommend to name the src.rpm as inih creating package inih-devel?
Yes, upstream name is "inih", too. IMO, it would be smarter to rename the src.rpm (and the Fedora package git repository) to "inih". I don't see any value in naming the src.rpm "inih-devel".
The build.log: > g++ -I.. -g -O2 -c ../ini.c -o ../ini.o That means it doesn't use Fedora's global optflags yet. They are passed as EXTRACFLAGS=… to Make, but apparently that doesn't work.
Ok since dunst package no more requires inih library, I am closing this since there is no need for this package anymore. Thank you very much for help. Here is the bug that required inih: https://bugzilla.redhat.com/show_bug.cgi?id=852211