Hide Forgot
Spec URL: http://www.flyn.org/SRPMS/cgilib.spec SRPM URL: http://www.flyn.org/SRPMS/cgilib-0.6-1.fc9.src.rpm Description: The cgilib library provides a C library for creating Common Gateway Interface (CGI) programs. The CGI is a way to create dynamic web pages. It defines rules for interaction between a program and the web server while the server talks to the client.
This fails to build in mock for me: + aclocal /var/tmp/rpm-tmp.72081: line 30: aclocal: command not found error: Bad exit status from /var/tmp/rpm-tmp.72081 (%build) If you're going to run the autotools, you at least need to have a build dependency on them. The autotools patch seems significant, renaming a bunch of documentation files. Is there any point to it? It seems like a gratuitous difference from upstream.
Spec URL: http://www.flyn.org/SRPMS/cgilib.spec SRPM URL:http://www.flyn.org/SRPMS/cgilib-0.6-2.fc9.src.rpm This version simplifies the autotools patch. It no longer attempts to conform to GNU's standards. The package also now BuildRequires the autotools programs.
%files for the -devel package has no %defattr cgilib.x86_64: W: file-not-utf8 /usr/share/doc/cgilib-0.6/readme The character encoding of this file is not UTF-8. Consider converting it in the specfile's %prep section for example using iconv(1). please also consider preserve installed and/or modified files timestamps: - above iconv operation - make install target please explain why do you need to use autotools patch. You need to contact upstream for such modifications, anyway it should not be handled in the spec file. As I see it radically changes the source package.
Any update? It's been over a month since the last comment.
I am working to get the autotools patch upstream.
Please clear the whiteboard when you believe this is ready for a review.
Cgilib 0.7 was just released with the autotools patch applied: Spec URL: http://www.flyn.org/SRPMS/cgilib.spec SRPM URL: http://www.flyn.org/SRPMS/cgilib-0.7-1.fc10.src.rpm
I do not see rest of the points from comment #3 fixed.
- Set defattr for devel package. - Convert README to UTF-8 as original is ISO-8859 and has invalid characters. Spec URL: http://www.flyn.org/SRPMS/cgilib.spec SRPM URL: http://www.flyn.org/SRPMS/cgilib-0.7-2.fc10.src.rpm
Sorry for the late reply. There are a few problems with this package: 1. The same functionality this package provides is offered by a package already in Fedora libcgi, moreover the library cgilib provides conflicts with the library from libcgi. Library name has to be renamed one suggestion could be libcgilib. 2. Header files (aux and cgi) are too generic to be placed in {_includedir}. They need to be placed under a subdirectory (cgilib) of {_includedir}.
*** Bug 511387 has been marked as a duplicate of this bug. ***
Could someone update the status of this ticket? It's been idle for quite some time and now someone else has submitted cgilib for review.
Sent an email privately to W. Michael Petullo (mike), no response in two days.
If there's no response by Jul 21 (one week after my ping) then I'll reopen Gary's ticket and close this one.
Regarding reopening #511387, that's fine. I pushed hard for a while to get this in Fedora. In fact, I wrote the original autotools patch and helped the upstream maintainer with autotools before he integrated the patch for 0.7. That being said, I do not have a good solution to the issues raised on the fedora-packaging mailing list; see: https://www.redhat.com/archives/fedora-packaging/2009-February/msg00047.html especially: > Unrelated to this, libcgi maintainer should not have chosen to use libcgi.so.1 as the > soname without upstream's approval. -- Mr. Mierzejewski (later in this mail thread) Progress was stuck because 1) I don't think that we should ship a shared library name that is different that what upstream intends 2) we can't have two packages with the same shared library name and 3) I did not feel like asking the developer to rename his project due to one distribution's preferences. I'd like to see cgilib packaged. I just did not have the time to work through this. I did invest a lot of time to get my autotools work in, so I would like to cgilib in Fedora eventually.
I'm not an experienced enough packager to know what the right solution is. I would like to see cgilib included, as I have another package (in fact, the reason I became a Fedora packager) that depends on it, yet I don't want to package this incorrectly. The package I created was based on the guidelines at https://fedoraproject.org/wiki/Packaging:Conflicts#Library_Name_Conflicts , but obviously that is too simplistic for this case. Where do we go from here?
Ping? Any progress here? Or we can close this review?
Stalled Review. Closing per: https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews If you ever want to continue with this review, please reopen or submit new review.