Spec URL: http://rhl.fedorapeople.org/sketch.spec SRPM URL: http://rhl.fedorapeople.org/sketch-0.3.2-1.fc15.src.rpm Description: Sketch is a small, simple system for producing line drawings of two- or three-dimensional solid objects and scenes. It began as a way to make illustrations for a textbook after we could find no suitable tool for this purpose. Existing scene processors emphasized GUIs and/or photo-realism, both un-useful to us. We wanted to produce finely wrought, mathematically-based illustrations with no extraneous detail. The input language is reminiscent of PSTricks, so will be easy to learn for current PSTricks users.
is this your first package ?
indeed.
please start reading. https://fedoraproject.org/wiki/Category:Package_Maintainers I think no need the flowing lines. BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: gcc BuildRequires: flex BuildRequires: bison your spec file is missing changelog. please post here the link of a koji scratch build of your package.
Why is it not necessary? The makefile they create uses those things, if they are for some reason missing... http://koji.fedoraproject.org/koji/taskinfo?taskID=3117116
(In reply to comment #4) > Why is it not necessary? The makefile they create uses those things, if they > are for some reason missing... This isn't required because we have a list of packages installed by default into rpmbuildroot. However explicitly listing them (as you did) is harmless and isn't an issue. > http://koji.fedoraproject.org/koji/taskinfo?taskID=3117116 * Youd package doesn't use CFLAGS - this is a blocker. * Missing COPYING in %doc - this ia a strong requirement. * Also adding Doc as %doc sounds like a generally good idea (as well as "readme" and "updates.htm" files). * What's the purpose of the Data directory? Is it required for normal application's operation or not? I think these are jus an examples so they should be packaged as %doc but I'm not sure. * Correct licensing tag should be GPLv3+ not a "GPLv3 (or later)".
Ok, i've updated the spec file and the srpm, and posted the rpms as well. http://rhl.fedorapeople.org the Data directory looks like examples, and the Doc directory will eventually be broken out into it's own package sketch-docs, right now I am not building it, as I cannot get them to build currently (I suspect they depend on texlive 2010), and the data there is a carbon copy of what is provided on the sketch website. let me know if tehre are any more problems.
Ok, i've updated the spec file and the srpm, and posted the rpms as well. http://rhl.fedorapeople.org the Data directory looks like examples, and the Doc directory will eventually be broken out into it's own package sketch-docs, right now I am not building it, as I cannot get them to build currently (I suspect they depend on texlive 2010), and the data there is a carbon copy of what is provided on the sketch website. let me know if there are any more problems.
sorry and here is the koji build against dist-f15
http://koji.fedoraproject.org/koji/taskinfo?taskID=3122219
The only thing that stands out to me so far is the missing Changelog entry
Updated to add changelog: http://rhl.fedorapeople.org/sketch.spec Corresponding SRPM: http://rhl.fedorapeople.org/sketch-0.3.2-1.fc15.src.rpm Corresponding Koji Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3162258 rpmlint output: 0 packages and 1 specfiles checked; 0 errors, 0 warnings.
I can't sponsor you but I can suggest some fixes to your spec. You still need to update your License tag per comment 5. You don't need BuildRoot unless you're planning on building for EPEL <= 5 You don't need %clean unless you're planning on building for EPEL, in fact leaving it in without the accompanying "rm -rf %{buildroot}" is worse. You don't need "rm -rf %{buildroot}" in %install unless you're planning to build for EPEL <= 5. I assume that since you're manually installing the binary that this package lacks a "make install" target? All of your "%doc" items can be listed space separated on one line. You need to add one empty line between your changelog entries, e.g.: %changelog * Mon Jun 26 2011 Ryan H. Lewis <me> 1.0-3 - Added ChangeLog * Mon Jun 9 2011 Ryan H. Lewis <me> 1.0-2 - Fixes https://bugzilla.redhat.com/show_bug.cgi?id=711547#c5 * Mon Jun 7 2011 Ryan H. Lewis <me> 1.0-1 - Created initial spec file
all fixed, not sure why the licence tag ended up 'unfixed' again, but I did fix that once...
Hey Ryan. Was there another version of the package with the fixes from comment 12?
Yes: http://rhl.fedorapeople.org Updated: http://rhl.fedorapeople.org/sketch.spec Corresponding SRPM: http://rhl.fedorapeople.org/sketch-0.3.2-1.fc15.src.rpm the links aren't changing at all, just the content. I'm making sure to update the srpm whenever I modify the spec file... (see timestamps).
I think what Kevin was referring to is that you've incremented the releases appropriately in the changelog but "Release:" in your spec file (and therefore the resulting SRPM) is still "1". Some other thoughts... 1. I would remove "%check" since it's empty. 2. This only aids readability, but I always leave two empty lines between major sections in the spec file, i.e: Between %prep, %build, %install, %files, etc. 3. The last line in your %files section has "#doc Doc/" instead of "%doc Doc/", is this intentional?
Ok. I've made these changes, and i've uploaded it to http://rhl.fedorapeople.org spec and srpm, with the new version. at this point repeating koji builds is useless, as nothing is changing but minor details. in regards to your question 3. please read: https://bugzilla.redhat.com/show_bug.cgi?id=711547#c6 I am not sure what the compile issue is with the documentation, I asked the maintainer and they are now using OS X, but again, the information provided there is no different than what is on the web, so once I do get the docs compiling I can break out a sketch-docs sub package.
(In reply to comment #17) > in regards to your question 3. please read: > https://bugzilla.redhat.com/show_bug.cgi?id=711547#c6 > > I am not sure what the compile issue is with the documentation, I asked the > maintainer and they are now using OS X, but again, the information provided > there is no different than what is on the web, so once I do get the docs > compiling I can break out a sketch-docs sub package. That's fine, I would handle this by leaving the % on the front of doc so it doesn't look like a mistake (sure rpmlint will complain but we know why it's there) and put a comment above it with a brief description on why it's currently commented out. Really, it's a best practice to put in comments any time you're doing something non-standard so Proven Packagers, co-maintainers, or possible future owners of the package will know why you did something. Richard
Forgot to say, now we just need to find you a sponsor (if you don't already have one). If you haven't done so recently it wouldn't hurt to email the devel list with a polite request for sponsorship. Richard
I will be sponsoring Ryan.
Ok, so the % has been added, version bumped, spec and new srpm uploaded to fedorapeople.org, again: http://rhl.fedorapeople.org what do I need to do next, as you can see luke has offered to sponsor me, is this package approved yet?
Luke will have to do the full guideline checklist but I'd say you're in pretty good shape. Make sure you're good on everything at: http://fedoraproject.org/wiki/Join_the_package_collection_maintainers Paying specific attention to: http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored It wouldn't hurt to do some informal reviews on other open (unassigned) review requests. Richard
great. I've re-read the above link, it appears i've done everything I can for now. I informed Luke that he needs to do the 'full review,' I did an informal review of a font package: https://bugzilla.redhat.com/show_bug.cgi?id=714408 which was unassigned, but then got assigned, and accepted and is now located here: https://admin.fedoraproject.org/pkgdb/acls/name/tlomt-league-gothic-fonts
We'll all I can tell you is to be patient... I had to learn that the hard way as well :) It can be frustrating when you're excited about becoming a contributor and things seem to be moving at a snail's pace. Richard
MUST Items: [X] rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.[1] sketch.x86_64: W: summary-ended-with-dot C A 3D Scene Description Translator. sketch.x86_64: W: spelling-error 0%description -l en_US un -> UN, nu, in sketch.x86_64: W: unstripped-binary-or-object /usr/bin/sketch sketch.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/sketch-0.3.2/Data/hand.sk sketch.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/sketch-0.3.2/Data/buggy.sk sketch.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/sketch-0.3.2/Data/cone.sk sketch.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/sketch-0.3.2/Data/2tori.sk sketch.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/sketch-0.3.2/COPYING.txt sketch.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/sketch-0.3.2/Data/bunny.sk sketch.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/sketch-0.3.2/Data/test.sk sketch.x86_64: W: no-manual-page-for-binary sketch 1 packages and 0 specfiles checked; 0 errors, 11 warnings. [X] The package must be named according to the Package Naming Guidelines . [X] The spec file name must match the base package 100%{name}, in the format %{name}.spec unless your package has an exemption. [2] . [X] The package must meet the Packaging Guidelines . [X] The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . [X] The License field in the package spec file must match the actual license. [3] [X] If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in 100%doc.[4] [X] The spec file must be written in American English. [5] [X] The spec file for the package MUST be legible. [6] [X] The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. [X] The package MUST successfully compile and build into binary rpms on at least one primary architecture. [7] [X] If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. [8] [X] All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. [X] The spec file MUST handle locales properly. This is done by using the 100%find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9] [X] Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in 100%post and %postun. [10] [X] Packages must NOT bundle copies of system libraries.[11] [X] If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [12] [X] A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [13] [X] A Fedora package must not list a file more than once in the spec file's 100%files listings. (Notable exception: license texts in specific situations)[14] [X] Permissions on files must be set properly. Executables should be set with executable permissions, for example. [15] [X] Each package must consistently use macros. [16] [X] The package must contain code, or permissable content. [17] [X] Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [18] [X] If a package includes something as 100%doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [18] [X] Header files must be in a -devel package. [19] [X] Static libraries must be in a -static package. [20] [X] If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [19] [X] In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: 100%{name}%{?_isa} = %{version}-%{release} [21] [X] Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[20] [X] Packages containing GUI applications must include a 100%{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [22] [X] Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [23] [X] All filenames in rpm packages must be valid UTF-8. [24] SHOULD Items: [_] If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [25] [_] The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. [26] [_] The reviewer should test that the package builds in mock. [27] [_] The package should compile and build into binary rpms on all supported architectures. [28] [_] The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. [_] If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. [29] [_] Usually, subpackages other than devel should require the base package using a fully versioned dependency. [21] [_] The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. [30] [_] 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. [31] [_] your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.[32] Minor whitespace nitpick: there are some stray tab characters after some of the fields. Other than that, the package looks good. APPROVED Next step, file an SCM admin request: http://fedoraproject.org/wiki/Package_SCM_admin_requests
New Package SCM Request ======================= Package Name: sketch Short Description: A 3D Scene Description Translator. Owners: rhl Branches: f14 f15 el4 el5 el6 InitialCC:
Git done (by process-git-requests).
sketch-0.3.2-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/sketch-0.3.2-6.fc15
sketch-0.3.2-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/sketch-0.3.2-6.fc14
sketch-0.3.2-6.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/sketch-0.3.2-6.el6
sketch-0.3.2-6.fc14 has been pushed to the Fedora 14 testing repository.
sketch-0.3.2-6.fc14 has been pushed to the Fedora 14 stable repository.
sketch-0.3.2-6.fc15 has been pushed to the Fedora 15 stable repository.
sketch-0.3.2-6.el6 has been pushed to the Fedora EPEL 6 stable repository.