Spec: http://rojekti.fi/files/paco/paco.spec SRPM: http://rojekti.fi/files/paco/paco-2.0.9-1.fc14.src.rpm Description: After the installation of a source package with "./configure && make && make install", one is usually left with having no idea of what it was installed and where it all went, making it difficult to uninstall the package in the future. Paco was written to solve this problem in a quite simple fashion. When installing a package from sources, paco wraps the "make install" command (or whatever command or group of commands are needed to install the files into the system), and saves installation information into a text database. This is my first package and I need a sponsor. (There is a very old previous request for the same application at bug 184008. I've been adviced to create a new request.)
*** Bug 184008 has been marked as a duplicate of this bug. ***
Just some comment on your spec file: - rpmlint output: [fab@laptop021 SRPMS]$ rpmlint paco-2.0.9-1.fc14.src.rpm paco.src: E: description-line-too-long C After the installation of a source package with "./configure && make && make install", one is usually left with having no idea of what it was installed and where it all went, making it difficult to uninstall the package in the future. paco.src: E: description-line-too-long C When installing a package from sources, paco wraps the "make install" command (or whatever command or group of commands are needed to install the files into the system), and saves installation information into a text database. paco.src: E: description-line-too-long C Paco has many usage options for removing packages, looking at package files, file counts, sorting, missing files, etc. Run "paco -h" on the command line, or "man paco" for more information. paco.src:13: W: configure-without-libdir-spec 1 packages and 0 specfiles checked; 3 errors, 1 warnings. [fab@laptop021 x86_64]$ rpmlint paco* paco.x86_64: E: description-line-too-long C After the installation of a source package with "./configure && make && make install", one is usually left with having no idea of what it was installed and where it all went, making it difficult to uninstall the package in the future. paco.x86_64: E: description-line-too-long C When installing a package from sources, paco wraps the "make install" command (or whatever command or group of commands are needed to install the files into the system), and saves installation information into a text database. paco.x86_64: E: description-line-too-long C Paco has many usage options for removing packages, looking at package files, file counts, sorting, missing files, etc. Run "paco -h" on the command line, or "man paco" for more information. paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit.5 paco.x86_64: E: incorrect-fsf-address /usr/share/doc/paco-2.0.9/COPYING paco.x86_64: W: no-manual-page-for-binary ocap 2 packages and 0 specfiles checked; 4 errors, 2 warnings. - Development .so files needs to go to a -devel subpackage - ChangeLog file is missing in %doc
I've taken your comments into account and made some changes to the spec file. The new files are here: Spec: http://rojekti.fi/files/paco/paco-2.spec SRPM: http://rojekti.fi/files/paco/paco-2.0.9-1.fc15.src.rpm What I've done: * Fixed the description text. * Changed the "Group" to "Applications/System", since I think that makes more sense for than "Development/Tools". * Included the ChangeLog file. Here's the new rpmlint output: [veeti@veeti-pc SPECS]$ rpmlint ../SRPMS/paco-2.0.9-1.fc15.src.rpm paco.src:13: W: configure-without-libdir-spec 1 packages and 0 specfiles checked; 0 errors, 1 warnings. I assume that this is just a false positive, since the description has a line with the text ./configure inside it. [veeti@veeti-pc SPECS]$ rpmlint ../RPMS/x86_64/paco-2.0.9-1.fc15.x86_64.rpm paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit.5 paco.x86_64: E: incorrect-fsf-address /usr/share/doc/paco-2.0.9/COPYING paco.x86_64: W: no-manual-page-for-binary ocap 1 packages and 0 specfiles checked; 1 errors, 2 warnings. What should I do about the incorrect FSF address? Patch the COPYING file? As for the libpaco-log library, I don't think that it's a "development file", since it's an essential component of the paco application. From the paco website: "How does it perform this magic? It is accomplished using the LD_PRELOAD method, which preloads a shared library before installation using the environment variable LD_PRELOAD. During installation, this library catches the system calls that cause filesystem alterations (such as open, link, rename, ...), and logs the created files." Thanks!
I realized something yesterday - I had completely ignored the "gpaco" GUI frontend included in paco. So I started tinkering around with subpackages (using the existing cmake package as an example), and added a "paco-gui" subpackage to the spec. So the newest files can be found here: SPEC: http://rojekti.fi/files/paco/3/paco.spec SRPM: http://rojekti.fi/files/paco/3/paco-2.0.9-3.fc15.src.rpm (Better late than never, right?) I'm not completely sure about the subpackage's name: should it be paco-gui or gpaco (as the actual executable is called gpaco)? In addition, I've patched the license file to fix the FSF address error, and there's also another patch there to make the gpaco.desktop file more compliant. I've e-mailed the author about those. And that's not all - I've also fixed a line in the %files section that was causing some dependency problems with i686 builds. Thanks to Rex and Kevin for their help in the devel mailing list! Here's the latest rpmlint output straight out of the oven: [veeti@veeti-pc SPECS]$ rpmlint paco.spec paco.spec:20: W: configure-without-libdir-spec 0 packages and 1 specfiles checked; 0 errors, 1 warnings. Same as before - false positive (?) from the package description. [veeti@veeti-pc x86_64]$ rpmlint paco-2.0.9-3.fc15.x86_64.rpm paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit.5 paco.x86_64: W: no-manual-page-for-binary ocap 1 packages and 0 specfiles checked; 0 errors, 2 warnings. [veeti@veeti-pc x86_64]$ rpmlint paco-gui-2.0.9-3.fc15.x86_64.rpm paco-gui.x86_64: W: no-documentation paco-gui.x86_64: W: no-manual-page-for-binary gpaco 1 packages and 0 specfiles checked; 0 errors, 2 warnings.
Hi Veeti, here are some comments on your latest package: - if you don't plan to maintain the package for EPEL < 6, you can drop all the buildroot stuff (BuildRoot field, %clean section, initial cleaning of the buildroot in %install) - you should ask upstream to properly apply the GPL by adding the text given in COPYING to the source files: <one line to give the program's name and a brief idea of what it does.> Copyright (C) <year> <name of author> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. ... Without these information it's not clear what license is actually intended (GPL+, GPLv2, GPLv2+). Currently, it's actually GPL+ as relying on COPYING is not sufficient. Also see the information given here: http://fedoraproject.org/wiki/Licensing:Main - The rpmlint warning shared-lib-calls-exit should be fixed upstream. - I suggest to prefix the patch file names with the package name to avoid conflicts and to easily find the patches in the source directory: paco-fix-fsf-address.patch paco-fix-desktop-file.patch - Giving the full icon path in the .desktop file is fine, but it's recommended to simply use the basename of the icon file: http://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files - It's common practice to list all BuildRequires at the top part of the spec file, e.g. below BuildRoot or the PatchXXX lines -- even those of the subpackages. This allows to get an overview of the direct dependencies easily. - You should preserve the timestamp of file ChangeLog, e.g. with iconv -f iso8859-1 -t utf-8 ChangeLog > ChangeLog.conv && \ touch -r ChangeLog ChangeLog.conv && \ mv -f ChangeLog.conv ChangeLog - Directory %{_datadir}/paco/ only contains README, faq.txt, and pacorc. README is already packaged as %doc, and pacorc is installed in /etc. Thus, I recommend to drop %{_datadir}/paco/ completely. You can add faq.txt as %doc as well. - Please be a bit more verbose in %files. This helps to avoid adding unwanted files and gives a better overview of the package's content: %{_bindir}/ocap %{_bindir}/paco* %{_bindir}/rpm2paco %{_bindir}/superpaco %{_libdir}/libpaco-log.so.* %{_mandir}/man5/pacorc.5* %{_mandir}/man8/*.8*
- As has already been stated on fedora-devel, it is generally preferred to delete the files you don't want to ship at the end of %install, instead of excluding them in %files. - The usual convention is to apply any patches directly after %setup, unless the patches do not operate on pristine source files. Please convert the ChangeLog at the end of the %prep phase, after the patches have been applied. - It is also advisable to version the patches, e.g. Patch0: paco-2.0.9-fix-fsf-address.patch since often you might have to rebase these, and having a different content of the patch file in different branches (e.g. f14 vs f15) might be confusing. - You should ship %{_libdir}/*.so %{_libdir}/pkgconfig in a -devel package, since these can be used to compile against paco. Or do you have any specific reason why you don't want to ship these? PS. If you're on IRC, please join #fedora.fi on IRCNet.
Hi! Thank you for your comments. > if you don't plan to maintain the package for EPEL < 6, you can drop all the buildroot stuff (BuildRoot field, %clean section, initial cleaning of the buildroot in %install) I do plan on maintaining this for EL5 (although I think that would require dropping the GUI subpackage on that branch, since the GTK+ version there is way too old). > you should ask upstream to properly apply the GPL by adding the text given in COPYING to the source files I'll e-mail him about this. > Giving the full icon path in the .desktop file is fine, but it's recommended to simply use the basename of the icon file The reason I added the full path to the desktop file was that the basename didn't work for me (the icon didn't show up with the menu entry). I came to the conclusion that the icon should be installed somewhere in the /usr/share/icons tree instead of /usr/share/pixmaps for that to work - please correct me if I'm wrong. > As has already been stated on fedora-devel, it is generally preferred to delete the files you don't want to ship at the end of %install, instead of excluding them in %files. Is there any specific advantage/reason/logic for doing this? I've changed the spec to do this, but to me using an "exclude" command in the files section seems more logical (and easier to understand) than just removing those files during %install. As for the shared library, my understanding is that it's not meant to be used by other applications - it's only designed for internal use by paco to log installations (and that would probably explain the exit calls in the library too). paco doesn't install any header files either. However, I might be missing something here. In any case, I've fixed all the other stuff you've mentioned. Here's the new spec and SRPM: SPEC: http://rojekti.fi/files/paco/4/paco.spec SRPM: http://rojekti.fi/files/paco/4/paco-2.0.9-4.fc15.src.rpm Changelog: * Sun Jul 17 2011 Veeti Paananen <veeti.paananen> - 2.0.9-4 - Prefixed patch files with package name and version - Moved build requirements in spec file to the top - Preserve the changelog file's timestamp when converting to UTF-8 - Removed /usr/share/paco since the same files are already installed elsewhere - Added faq.txt to documentation - More verbose file listings - Moved file exclusions to rm statements in install section - Moved patch statements to directly after setup Nothing new in rpmlint.
Whoops, I guess those lines were wrapped for a reason. Sorry about the overflowing text.
(In reply to comment #7) > > Giving the full icon path in the .desktop file is fine, but it's recommended to simply use the basename of the icon file > > The reason I added the full path to the desktop file was that the basename > didn't work for me (the icon didn't show up with the menu entry). I came to the > conclusion that the icon should be installed somewhere in the /usr/share/icons > tree instead of /usr/share/pixmaps for that to work - please correct me if I'm > wrong. Nope, /usr/share/pixmaps works just fine. > > As has already been stated on fedora-devel, it is generally preferred to delete the files you don't want to ship at the end of %install, instead of excluding them in %files. > > Is there any specific advantage/reason/logic for doing this? I've changed the > spec to do this, but to me using an "exclude" command in the files section > seems more logical (and easier to understand) than just removing those files > during %install. %exclude is usually only used, when you want to use wildcards in the %files section of a given (sub)package, but at the same time place a specific file in another subpackage. For instance: %files %defattr(-,root,root,-) %{_bindir}/foo-* %exclude %{_bindir}/foo-bar %files bar %defattr(-,root,root,-) %{_bindir}/foo-bar Freeminded use of %excludes can lead to trouble, since you might end up with files that are not packaged altogether... > As for the shared library, my understanding is that it's not meant to be used > by other applications - it's only designed for internal use by paco to log > installations (and that would probably explain the exit calls in the library > too). paco doesn't install any header files either. However, I might be missing > something here. ... but the existence of pkgconfig stuff would lead to think the contrary, would it not? Please contact upstream to clarify this issue.
> Nope, /usr/share/pixmaps works just fine Well, upstream has already adopted the absolute path after my patch - so I think that we should just keep it this way. I'll send another e-mail about the library.
Some clarification from upstream about licensing and the static library: > Yes, the intended version for paco is GPLv2. > libpaco-log is meant to be used only by the paco command line > executable and not by any other application. I added a pkgconfig file > just for the configure script to be able to detect any older instance > of paco on the system. It's a dirty trick, I know, but it doesn't harm > anything.
(In reply to comment #11) > Some clarification from upstream about licensing and the static library: > > > Yes, the intended version for paco is GPLv2. > > > libpaco-log is meant to be used only by the paco command line > > executable and not by any other application. I added a pkgconfig file > > just for the configure script to be able to detect any older instance > > of paco on the system. It's a dirty trick, I know, but it doesn't harm > > anything. ... okay. So the install system is broken, the development stuff should not be installed. ** Please note that you are currently mixing styles, which is not allowed. http://fedoraproject.org/wiki/Packaging/Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS ** If you want to get sponsored, you need to demonstrate your knowledge of the Fedora guidelines, most importantly http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/ReviewGuidelines In addition to the Packaging Guidelines, there are a bunch of language / application specific guidelines that are linked to in the Packaging Guidelines. Here are some tricks of the trade: http://fedoraproject.org/wiki/Packaging_tricks http://fedoraproject.org/wiki/Packaging/ScriptletSnippets http://fedoraproject.org/wiki/Common_Rpmlint_issues I will sponsor you if you have at least one other submission and perform a couple of informal reviews of packages of other people. (Martin might be a willing sponsor as well.) Please review only packages *not* marked with FE-NEEDSPONSOR, as I will have to do the full formal review after you to check that you have got everything correctly. Once I have sponsored you you will be able to do formal reviews of your own.
I'm not sure whether paco-gui is the best name for the GUI package; I would just name it gpaco. You can do this by specifying %package -n gpaco instead of %package gui and the thing for %files as well. ** rpmlint output: paco.src:23: W: configure-without-libdir-spec paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit.5 paco.x86_64: W: no-manual-page-for-binary ocap paco-gui.x86_64: W: no-documentation paco-gui.x86_64: W: no-manual-page-for-binary gpaco 4 packages and 0 specfiles checked; 0 errors, 5 warnings. The configure-without-libdir-spec warning is probably caused by the ./configure in the %description, and is as such erroneus. Since this is a C++ program, there's no need to call exit, as one can throw exceptions instead. However, this change would need to be done by upstream. Other warnings are OK. ** MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK MUST: The spec file for the package is legible and macros are used consistently. NEEDSWORK - Macro styles mixed. - Please remove the unnecessary empty lines in -gui, e.g., the empty line at the start of the %description ends up in the result rpm as well. MUST: The package must be named according to the Package Naming Guidelines. OK MUST: The spec file name must match the base package %{name}. OK MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines. OK MUST: The License field in the package spec file must match the actual license. NEEDSWORK - As stated by Martin above in comment #5, the license is somewhat badly defined. - gpaco/about.cc defines a GPLv2+ license, so do lib/paco/getopt.h and lib/paco/getopt.cc. - License tag should reflect the license of the result, which is anyway in this case GPL+ + GPLv2+ = GPLv2+. - Please change License tag to GPLv2+ and ask upstream to add proper license headers in every source code file. MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. OK $ md5sum paco-2.0.9.tar.bz2 ../SOURCES/paco-2.0.9.tar.bz2 d2debbea1b11156470f7fd849bb93c80 paco-2.0.9.tar.bz2 d2debbea1b11156470f7fd849bb93c80 ../SOURCES/paco-2.0.9.tar.bz2 MUST: The package MUST successfully compile and build into binary rpms. OK MUST: The spec file MUST handle locales properly. N/A MUST: Optflags are used and time stamps preserved. OK MUST: Packages containing shared library files must call ldconfig. OK MUST: A package must own all directories that it creates or require the package that owns the directory. OK MUST: Files only listed once in %files listings. OK MUST: Debuginfo package is complete. OK MUST: Permissions on files must be set properly. OK MUST: Large documentation files must go in a -doc subpackage. N/A MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. OK MUST: Header files must be in a -devel package. N/A MUST: Static libraries must be in a -static package. N/A MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. N/A MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. N/A MUST: Packages does not contain any .la libtool archives. OK MUST: Desktop files are installed properly. OK MUST: No file conflicts with other packages and no general names. OK SHOULD: %{?dist} tag is used in release. OK SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. OK SHOULD: The package builds in mock. OK EPEL: Clean section exists. OK EPEL: Buildroot cleaned before install. OK EPEL: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. N/A ** This package is in pretty good shape, so you'll just need to do another submission and a couple of informal reviews as instructed in comment #12.
New spec and SRPM: SPEC: http://rojekti.fi/files/paco/5/paco.spec SRPM: http://rojekti.fi/files/paco/5/paco-2.0.9-5.fc15.src.rpm Changelog: * Mon Jul 18 2011 Veeti Paananen <veeti.paananen> - 2.0.9-5 - Replaced build root variables with the build root macro - Renamed GUI subpackage to gpaco after the upstream name - Changed license to GPLv2+ - Removed empty line in gpaco description rpmlint: [veeti@veeti-pc SRPMS]$ rpmlint paco-2.0.9-5.fc15.src.rpm paco.src:22: W: configure-without-libdir-spec 1 packages and 0 specfiles checked; 0 errors, 1 warnings. [veeti@veeti-pc x86_64]$ rpmlint paco-2.0.9-5.fc15.x86_64.rpm gpaco-2.0.9-5.fc15.x86_64.rpm paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit.5 paco.x86_64: W: no-manual-page-for-binary ocap gpaco.x86_64: W: spelling-error Summary(en_US) paco -> capo, pace, pact gpaco.x86_64: W: spelling-error %description -l en_US paco -> capo, pace, pact gpaco.x86_64: W: no-documentation gpaco.x86_64: W: no-manual-page-for-binary gpaco 2 packages and 0 specfiles checked; 0 errors, 6 warnings. ---------- I'll check the package wishlist for anything that I would be interested in and look for packages I can comment on. Right now I've left comments on these: bug 713923, bug 714491, bug 714543, bug 714899, bug 716580, bug 717337
I've packaged a C++ wrapper library for libcurl called cURLpp and the review request is at bug 723053. I'll try to find some packages that I could informally review more thoroughly than the comments I've left so far.
New spec and SRPM: Spec: http://rojekti.fi/files/paco/6/paco.spec SRPM: http://rojekti.fi/files/paco/6/paco-2.0.9-6.fc15.src.rpm Changelog: * Tue Jul 19 2011 Veeti Paananen <veeti.paananen> - 2.0.9-6 - Add default file attributes to gpaco subpackage - Removed unnecessary recursive flags from rm commands to delete unwanted files Nothing new in rpmlint.
I've made a thorough informal review at bug 722914 (hopefully I did it right!). I'll try to find a couple of more packages to go through later.
Since you have also reviewed bug 705319, I have sponsored you in pkgdb. You seem to have addressed all the issues I raised, so I have to declare this package APPROVED Proceed by requesting git branches. http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
Cool, thanks! New Package SCM Request ======================= Package Name: paco Short Description: A source code package organizer for Unix/Linux Owners: vpaan Branches: f14 f15 el5 el6 InitialCC:
Git done (by process-git-requests).
Package Change Request ====================== Package Name: paco New Branches: f16 Owners: vpaan
paco-2.0.9-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/paco-2.0.9-6.fc15
paco-2.0.9-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/paco-2.0.9-6.fc14
paco-2.0.9-6.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/paco-2.0.9-6.el6
paco-2.0.9-7.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/paco-2.0.9-7.el5
paco-2.0.9-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/paco-2.0.9-6.fc16
paco-2.0.9-7.el5 has been pushed to the Fedora EPEL 5 testing repository.
paco-2.0.9-6.fc14 has been pushed to the Fedora 14 stable repository.
paco-2.0.9-6.fc15 has been pushed to the Fedora 15 stable repository.
paco-2.0.9-6.el6 has been pushed to the Fedora EPEL 6 stable repository.
paco-2.0.9-7.el5 has been pushed to the Fedora EPEL 5 stable repository.
paco-2.0.9-6.fc16 has been pushed to the Fedora 16 stable repository.