Spec URL: http://www.sequestered.net/~cquinn/vcsh.spec SRPM URL: http://www.sequestered.net/~cquinn/vcsh-1.3-1.fc18.src.rpm Description: vcsh allows you to have several git repositories, all maintaining their working trees in $HOME without clobbering each other. That, in turn, means you can have one repository per config set (zsh, vim, ssh, etc), picking and choosing which configs you want to use on which machine. Fedora Account System Username: kb1jwq lint output: rpmlint vcsh.spec ../RPMS/noarch/vcsh-1.3-1.fc18.noarch.rpm ../SRPMS/vcsh-1.3-1.fc18.src.rpm vcsh.noarch: W: spelling-error Summary(en_US) config -> con fig, con-fig, configure vcsh.noarch: W: spelling-error Summary(en_US) homedirs -> homers vcsh.noarch: W: spelling-error %description -l en_US config -> con fig, con-fig, configure vcsh.noarch: W: spelling-error %description -l en_US configs -> con figs, con-figs, configure vcsh.src: W: spelling-error Summary(en_US) config -> con fig, con-fig, configure vcsh.src: W: spelling-error Summary(en_US) homedirs -> homers vcsh.src: W: spelling-error %description -l en_US config -> con fig, con-fig, configure vcsh.src: W: spelling-error %description -l en_US zsh -> sh, ssh, ash vcsh.src: W: spelling-error %description -l en_US configs -> con figs, con-figs, configure
It's worth pointing out that this is my first package, and I need a sponsor.
Hi Corey: Initial comments: if you don't want ship the package to el5: - %clean is not needed - BuildRoot is not needed - cleaning of buildroot in %install is not needed - %defattr is not needed
Thanks for the feedback! My current plan is to ship it to EL5, EL6, Rawhide, and current stable. Bearing that in mind, does any of that advice still apply?
No, if you want to maintain this in one spec, still apply. If you create 2 or 3 spec for Fedora/EPEL5,6, you may delete these lines in Fedora spec.
@Corey, in order to get a willing sponsor, you should participate in a few of informal reviews
> - %defattr is not needed True, and it isn't needed for EL5 anymore either, because RPM is new enough. It can be dropped from the spec file. > %{_docdir}/vcsh/README.md > %doc LICENSE CONTRIBUTORS changelog This is somewhat unfortunate, because it creates two different doc dirs and an additional "unowned" directory: $ rpmls -p vcsh-1.3-1.fc19.noarch.rpm|grep doc drwxr-xr-x /usr/share/doc/vcsh-1.3 -rw-r--r-- /usr/share/doc/vcsh-1.3/CONTRIBUTORS -rw-r--r-- /usr/share/doc/vcsh-1.3/LICENSE -rw-r--r-- /usr/share/doc/vcsh-1.3/changelog -rw-r--r-- /usr/share/doc/vcsh/README.md -rw-r--r-- /usr/share/doc/vcsh/hooks => /usr/share/doc/vcsh is not included. Even if it may sound pedantic, it would look better, if all doc files were put into the same dir. https://fedoraproject.org/wiki/Packaging:UnownedDirectories https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership > %{_datadir}/zsh A comment in the spec file would be very good here, because this line includes directories, which belong into the zsh package. That's based on the following guideline: https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function A more readable notation for inclusion of a full directory tree uses adds a trailing slash, btw: %{_datadir}/zsh/ > /usr/share/zsh/site-functions/vendor-completions/_vcsh This is the same file as /usr/share/zsh/site-functions/_vcsh and no other package owns that directory already, so this may need a closer look during review. $ repoquery --whatprovides /usr/share/zsh/site-functions/vendor-completions $ > install -D -m 0644 _vcsh %{buildroot}%{_datadir}/zsh/site-functions/_vcsh https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps > mv %{buildroot}%{_datadir}/zsh/vendor-completions > %{buildroot}%{_datadir}/zsh/site-functions Since spec files are scripts, preferably one would comment on why this installed directory is moved.
Hi, Are you still interested in this?
Hi, I've started packaging vcsh on my own and ended up merging my work with what's already been done here :). It's also based on a more recent version from a couple days ago. I've taken care of packaging issues with a patch I haven't sent to the upstream, because the upstream project apparently maintains separate branches for packaging. So the patch would probably not land in the master branch. Source RPM and SPEC: https://bitbucket.org/dridi/fedora_packages/downloads
So, it's been a month... https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
It's been a little more than a month and a week, I'll submit a new review request.
I have submitted the new review request. *** This bug has been marked as a duplicate of bug 1018492 ***
Looks like this was taken care of ages ago; sorry for my going dark!