Spec URL: http://golotop.de/kxstitch.spec SRPM URL: http://golotop.de/kxstitch-0.8.4.1-1.fc13.src.rpm xml file for the mime type database: http://golotop.de/kxstitch.xml (Upstream uses the kde 3 database for mime type handling, so I wrote this xml file for the recent Fedora versions. Upstream received this file and will include it soon. Until then I provide it for the package on my own.) Description: KXStitch can be used to create cross stitch pattern from scratch. It is also possible to convert existing images to cross stitch pattern or scan one with a Sane supported scanner. --- I packaged this for a friend recently and then found out that KXStitch is listed in the Packaging Survey May 2009. The package builds in mock here and rpmlint has the following output: rpmlint kxstitch.spec ../RPMS/x86_64/kxstitch-0.8.4.1-1.fc13.x86_64.rpm ../SRPMS/kxstitch-0.8.4.1-1.fc13.src.rpm kxstitch.spec: W: no-cleaning-of-buildroot %clean kxstitch.spec: W: no-buildroot-tag kxstitch.spec: W: no-%clean-section kxstitch.src: W: no-cleaning-of-buildroot %clean kxstitch.src: W: no-buildroot-tag kxstitch.src: W: no-%clean-section 2 packages and 1 specfiles checked; 0 errors, 6 warnings. As far as I understand the Packaging Guidelines, these warnings do not apply for Fedora. This is my first package and so I need a sponsor.
I found a mistake in the %files section (some directories were not owned by the package) and corrected a typo in the description. Here are the new links: SPEC URL: http://golotop.de/kxstitch.spec SRPM URL: http://golotop.de/kxstitch-0.8.4.1-2.fc13.src.rpm
Hi Golo, here are some initial comments on your package: - Drop the leading article "A" from the Summary to keep it concise. - Adapt Source0 according to http://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net - You can drop BR: qt3-devel, ImageMagick-devel, libjpeg-devel, kernel-headers. They are not required or automatically added as dependencies. - Don't compress the manpage manually. rpmbuild does it for you. Thus, remove the gzip and rm lines in %install, and replace %doc %{_mandir}/man1/kxstitch.1.gz with %{_mandir}/man1/kxstitch.1* (no %doc prefix here). - If you put anything into %{_datadir}/icons, you must update the GTK icon cache. See http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Icon_Cache - Drop INSTALL from %files as it's not of much use in a binary package. - Please add empty lines between the %changelog entries to increase legibility.
Martin, thank you very much for your comments and remarks. I really appreciate your help. I updated the package and here are the new URLs SPEC URL: http://golotop.de/kxstitch.spec SRPM URL: http://golotop.de/kxstitch-0.8.4.1-3.fc14.src.rpm One thing is a little bit strange: I added the kernel-headers to the BRs because otherwise the package could not be build in mock on my F13 machine. I followed your advice and removed it and now it builds smoothly, however, I tested it only on my F14 machine. Most likely I made something wrong, but I will investigate on this further and try it again on my F13 machine.
(In reply to comment #3) > thank you very much for your comments and remarks. I really appreciate your > help. You're welcome. > I updated the package and here are the new URLs OK, fine. The new package looks pretty clean now. Just two minor cosmetic issues: - I suggest to use the plural in the Summary (pattern => patterns). - Add a final dot to the %description. $ rpmlint /var/lib/mock/fedora-14-x86_64/result/*.rpm kxstitch.src: W: no-cleaning-of-buildroot %clean kxstitch.src: W: no-buildroot-tag kxstitch.src: W: no-%clean-section 3 packages and 0 specfiles checked; 0 errors, 3 warnings. These warnings can be ignored if you plan to maintain the package for Fedora only. However, EPEL <= 5 still requires the missing items mentioned above. > One thing is a little bit strange: I added the kernel-headers to the BRs > because otherwise the package could not be build in mock on my F13 machine. I > followed your advice and removed it and now it builds smoothly, however, I > tested it only on my F14 machine. Yes, these kind of things happen from time to time, and can't be reproduced later on. Anyway, the package builds fine for F13 too: http://koji.fedoraproject.org/koji/taskinfo?taskID=2584994 As you probably already know, joining the Fedora packager group isn't an automatic process but requires some initial work to convince a sponsor to approve you. It's important to familiarize yourself with the packaging guidelines and show it by doing some informal reviews of other packager's submissions. That's a crucial thing because you're allowed to formally review, packages once you're sponsored. And, of course, you shouldn't mess up your own packages. So you should know what you're doing. :) If you don't have a sponsor yet, I can sponsor you if you're willing to informally review two or three package submissions. Just choose an uncommented review request ticket (e.g. bug #634025) and comment on the packages according to the review guidelines: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines There are a lot of further things to consider, but these are the most important ones.
New URLs: SPEC URL: http://golotop.de/kxstitch.spec SRPM URL: http://golotop.de/kxstitch-0.8.4.1-4.fc14.src.rpm Concerning the output of rpmlint: I think I will keep it like this for the moment because honestly I am not so sure if the typical REHL user is interested in this package. But if anyone asks for it I will of course change it. I am aware of the fact that I have to show my understanding of the Packaging Guidelines and I already started participating (see https://bugzilla.redhat.com/show_bug.cgi?id=647076 and https://bugzilla.redhat.com/show_bug.cgi?id=592628). Now that I now that my package follows the Guidelines more or less I will start doing some informal reviews. Hopefully I can convince you that sponsoring me is the right thing to do. ;)
(In reply to comment #5) > Concerning the output of rpmlint: I think I will keep it like this for the > moment because honestly I am not so sure if the typical REHL user is interested > in this package. That's no problem. You can freely choose the distro branches you're planning to maintain a package for. > I am aware of the fact that I have to show my understanding of the Packaging > Guidelines and I already started participating (see > https://bugzilla.redhat.com/show_bug.cgi?id=647076 and > https://bugzilla.redhat.com/show_bug.cgi?id=592628). Now that I now that my > package follows the Guidelines more or less I will start doing some informal > reviews. OK, thanks for the info. Let me know once you've posted your first informal review. I will have a look at your comments then. > Hopefully I can convince you that sponsoring me is the right thing to do. ;) We will see. :) Since you don't have to know every little detail of the guidelines to get sponsored, and since you'll continuously learn by doing afterwards, it's sufficient to show that you're heading in the right direction. Just don't feel discouraged if your comments get corrected or criticized by other packagers. That's part of the learning process. If you have any questions, feel free to send me an email.
Removed the FE-NEEDSPONSOR block since I got sponsored.
Hi Golo, as long as the .desktop file needs the current amount of changes, I recommend to provide your own one, e.g. via a heredoc in the spec file. This is much more reliable since the modifications to the original file applied by sed might silently fail, e.g. due to mismatching patterns. Once the upstream developers provide a cleaned-up version, you can simplify your spec file again. Also, ensure that the HTML documentation gets installed in %{_defaultdocdir}/%{name}-%{version}/HTML. Currently it's located directly below %{_defaultdocdir}. See [1] for possible pitfalls in conjunction with %doc and %{_defaultdocdir}. [1] http://fedoraproject.org/wiki/Packaging_tricks#Installing_documentation:_2_paths
Martin, I really appreciate your help on this. Providing the .desktop file is absolutely no problem since I wrote a new version for upstream and so I have the whole file here. Concerning the second point we already discussed that it is correct like that, however %{_defaultdocdir} should better be replaced by %{_kde4_docdir}. So here another try: SPEC URL: http://golotop.de/kxstitch.spec SRPM URL: http://golotop.de/kxstitch-0.8.4.1-5.fc13.src.rpm
Hi Golo, here's the formal review. Since I couldn't find any further blocking issues, your package is ready to be added to the Fedora now. The next step is to request a Git repository with the distro branches you're planning to maintain. See the following wiki page for further information: https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure $ rpmlint /var/lib/mock/fedora-14-i386/result/*.rpm kxstitch.src: W: no-cleaning-of-buildroot %clean kxstitch.src: W: no-buildroot-tag kxstitch.src: W: no-%clean-section 3 packages and 0 specfiles checked; 0 errors, 3 warnings. The avove warnings can be ignored since this package is to be maintained for Fedora only. --------------------------------- key: [+] OK [.] OK, not applicable [X] needs work --------------------------------- [+] MUST: The package must be named according to the Package Naming Guidelines. [+] MUST: The spec file name must match the base package %{name}. [+] MUST: The package must meet the Packaging Guidelines. [+] MUST: The package must be licensed with a Fedora approved license. GPLv2+ according to source file headers [+] MUST: The License field in the package spec file must match the actual license. [+] MUST: The file containing the text of the license(s) for the package must be included in %doc. COPYING is present [+] MUST: The spec file must be written in American English. [+] MUST: The spec file for the package MUST be legible. [+] MUST: The sources used to build the package must match the upstream source. $ md5sum kxstitch-0.8.4.1.tar.gz* 7feeafd526a4ea2a563a8f183fbfd12e kxstitch-0.8.4.1.tar.gz 7feeafd526a4ea2a563a8f183fbfd12e kxstitch-0.8.4.1.tar.gz.1 [+] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2628056 [.] MUST: If the package does not successfully compile, build or work ... [+] MUST: All build dependencies must be listed in BuildRequires. [+] MUST: The spec file MUST handle locales properly. [.] MUST: Packages storing shared library files (not just symlinks) must call ldconfig in %post and %postun. [+] MUST: Packages must NOT bundle copies of system libraries. [.] MUST: If the package is designed to be relocatable, ... [+] MUST: A package must own all directories that it creates. [+] MUST: A Fedora package must not list a file more than once in %files. [+] MUST: Permissions on files must be set properly. [+] MUST: Each package must consistently use macros. [+] MUST: The package must contain code, or permissable content. [.] MUST: Large documentation files must go in a -doc subpackage. [+] MUST: Files in %doc must not affect the runtime of the application. [.] MUST: Header files must be in a -devel package. [.] MUST: Static libraries must be in a -static package. [.] MUST: library files with a suffix (e.g. libfoo.so.1.1), must go in a -devel package. [.] MUST: devel packages must require the base package using a fully versioned dependency [+] MUST: Packages must NOT contain any .la libtool archives. [+] MUST: Packages containing GUI applications must include a %{name}.desktop file [+] MUST: .desktop files must be properly installed with desktop-file-install/-validate in the %install section. [+] MUST: Packages must not own files or directories already owned by other packages. [+] MUST: All filenames in rpm packages must be valid UTF-8. [.] SHOULD: If the source package does not include license text(s) as a separate file ... [+] SHOULD: The reviewer should test that the package builds in mock. [+] SHOULD: The package should compile and build into binary rpms on all supported architectures. [+] SHOULD: The reviewer should test that the package functions as described. [+] SHOULD: If scriptlets are used, those scriptlets must be sane. [.] SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. [.] SHOULD: pkgconfig(.pc) should be placed in a -devel pkg. [+] SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. [+] SHOULD: your package should contain man pages for binaries/scripts. ---------------- Package APPROVED ----------------
New Package SCM Request ======================= Package Name: kxstitch Short Description: Program to create cross stitch patterns Owners: golfu Branches: f13 f14 InitialCC:
The requested package name does not match the package name in the ticket summary. Please either correct the ticket summary or submit a new SCM request; then, re-raise the fedora-cvs flag.
Sorry for the confusion! I didn't know yet that the system is case-sensitive. KXStitch is the upstream name. However, I think kxstitch is more appropriate as package name. -> Summary changed accordingly.
Git done (by process-git-requests).
kxstitch-0.8.4.1-5.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kxstitch-0.8.4.1-5.fc13
kxstitch-0.8.4.1-5.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kxstitch-0.8.4.1-5.fc14
kxstitch-0.8.4.1-5.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kxstitch'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/kxstitch-0.8.4.1-5.fc13
kxstitch-0.8.4.1-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
kxstitch-0.8.4.1-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.