Spec URL: http://fedorapeople.org/cgit/praiskup/public_git/pybugz.git/tree/pybugz.spec SRPM URL: http://fedorapeople.org/cgit/praiskup/public_git/pybugz.git/tree/pybugz-0.10git69cd7-1.fc17.src.rpm Hi! I'm trying to finish packaging of PyBugz. Packaging started Pierre (see the changelog) and with his ACK, I'm continuing on this. This is alternative tool for python-bugzilla. It is mostly used by Gentoo developers ATM. The project does not tend to be used for scripting (imo) — it is targeted to be more like faster-than-web interface for bugzilla. Thanks for review! Pavel
Hi Pavel, Why did you decide to rename the binary from bugz to pybugz? * Changing the command name makes it harder to follow upstream documentation[1] and instructions found on the web[2]. * "pybugz" is take more keystrokes to type than "bugz" [1]: The Usage/Workflow section at https://github.com/williamh/pybugz [2]: http://wiki.koha-community.org/wiki/Pybugz_configuration
Spec URL: http://fedorapeople.org/cgit/praiskup/public_git/pybugz.git/plain/pybugz.spec SRPM URL: http://fedorapeople.org/cgit/praiskup/public_git/pybugz.git/plain/pybugz-0.10git69cd7-1.fc17.src.rpm I have corrected the links to allow automatic fedora-review run. Scott, I renamed it to pybugz because we have already installed the 'bugzilla' tool (it should be documented in changelog): sudo yum install -y '*bin/bugzilla' And bugz/bugzilla -> I found it too overlapping name. Pavel
I'm thinking about it again and it could really mislead users. I'll probably switch it back to the name 'bugz'. Pavel
Switched back to 'bugz'.
(In reply to comment #4) Hi Pavel, Independent from this package review, you might want to take a look at this pull request I just made: https://github.com/williamh/pybugz/pull/41 this allows the creation of "gnomebugz", "kdebugz" aliases to the "bugz" binary. The same idea could be applied to the 'bugzilla' binary to reduce Tab completion clashes with 'bugz'.
Pavel, Defining "debug_package" to %{nul} shouldn't be necessary. Certainly no debuginfo packages were generated for any of my pure Python packages or when I built pybugz.spec locally. Was that added on purpose? Suggested patch: Requires: python2 BuildRequires: python2-devel -# we don't need debuginfo package -%global debug_package %{nil} - %if ! 0%{?rhel}
For your convenience, I've collected all my suggested changes to your spec file here: http://scottt.tw/fedora/pybugz.spec Detailed review of the spec file: 1. Version naming (BIG one) Per http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag, please put the git revision in the release tag. In particular, as a "Post-Release package" of the form %{X}.%{posttag}. This is obviously very important to maintaining proper version sequences and upgrade paths. I recommend you treat this heavily patched snapshot based on 69cd7 as a post "0.10" release (Though it's actually more recent than 0.10.1 upstream): @@ -1,7 +1,11 @@ +%global gitrev 69cd7 +%global posttag git%{gitrev} +%global snapshot %{version}%{posttag} + Name: pybugz Summary: Command line interface for Bugzilla written in Python -Version: 0.10git69cd7 -Release: 1%{?dist} +Version: 0.10 +Release: 1.%{posttag}%{?dist} Group: Applications/Communications License: GPLv2 URL: https://github.com/williamh/pybugz @@ -10,9 +14,6 @@ BuildArch: noarch Requires: python2 BuildRequires: python2-devel -# we don't need debuginfo package -%global debug_package %{nil} - %if ! 0%{?rhel} # no bash-completion for RHEL %global bash_completion 1 @@ -25,12 +26,12 @@ BuildRequires: bash-completion pkgconfig # There is possible to download upstream tarball generated by github, but it is # quite old now. For HOWTO obtain correct tarball see the "prepare-tarball.sh" # script. -Source0: %{name}-%{version}.tar.gz +Source0: %{name}-%{snapshot}.tar.gz # follow https://github.com/praiskup/pybugz changes (until accepted by upstream) -Patch0: %{name}-%{version}-downstream.patch +Patch0: %{name}-%{snapshot}-downstream.patch # make the installation better satisfy RHEL / Fedora purposes -Patch1: %{name}-%{version}-rhel-fedora-cust.patch +Patch1: %{name}-%{snapshot}-rhel-fedora-cust.patch %description Pybugz was conceived as a tool to speed up the work-flow for Gentoo Linux @@ -40,7 +41,7 @@ quickly. Developers alike can easily extract attachments and close bugs comfortably from the command line. %prep -%setup -q +%setup -q -n %{name}-%{snapshot} %patch0 -p1 -b .downstream %patch1 -p1 -b .rhel-fedora-cust @@ -55,7 +56,7 @@ comfortably from the command line. %if %{?bash_completion} # find the proper directory to install bash-completion script mkdir -p %{buildroot}%{bash_cmpl_dir} - cp %{_builddir}/%{name}-%{version}/contrib/bash-completion \ + cp %{_builddir}/%{name}-%{snapshot}/contrib/bash-completion \ %{buildroot}%{bash_cmpl_dir}/bugz %endif The changelog would also need an update to match the new version scheme to avoid rpmlint errors. 2. Defining "debug_package" to %{nul} shouldn't be necessary. As stated in comment #6. 3. The "prepare-tarball.sh" script mentioned in the spec file is no where to be found. I'll approve this package once the problems above are addressed.
Spec URL: http://fedorapeople.org/cgit/praiskup/public_git/pybugz.git/plain/pybugz.spec SRPM URL: http://fedorapeople.org/cgit/praiskup/public_git/pybugz.git/plain/pybugz-0.10-1.git89df2.fc17.src.rpm Hi again, thank you very much for your comments! > 1. Version naming (BIG one) This is fixed, > 2. Defining "debug_package" to %{nul} shouldn't be necessary. > As stated in comment #6. removed - it was kind of artifact from 2010, > 3. The "prepare-tarball.sh" script mentioned in the spec file is no where to > found. I'm not sure if I understood you correct, is it enough to mention it here? http://fedorapeople.org/cgit/praiskup/public_git/pybugz.git/plain/ As this file is not used as a source file (used only by hand if any), I don't want to mention it in spec, or should I? Thanks, Pavel (written in PyBugz ;)
(In reply to comment #8) > > 3. The "prepare-tarball.sh" script mentioned in the spec file is no where to > > found. > > I'm not sure if I understood you correct, is it enough to mention it here? > http://fedorapeople.org/cgit/praiskup/public_git/pybugz.git/plain/ > > As this file is not used as a source file (used only by hand if any), I don't > want to mention it in spec, or should I? I'd recommend you check "prepare-tarball.sh" into git along with the spec file after this review passes and have a comment in the spec near the "Source0" line mentioning how to run "prepare-tarball.sh".
Formal review (assuming "prepare-tarball.sh" is handled like suggested in comment #9): Package Review ============== Key: [x] = Pass [!] = Fail [-] = Not applicable [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package contains no bundled libraries. [x]: Changelog in prescribed format. [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Sources contain only permissible code or content. [x]: %config files are marked noreplace or the reason is justified. [x]: Each %files section contains %defattr if rpm < 4.4 [x]: Macros in Summary, %description expandable at SRPM build time. [-]: Package contains desktop file if it is a GUI application. [x]: Development files must be in a -devel package [x]: Package requires other packages for directories it uses. [x]: Package uses nothing in %doc for runtime. [x]: Package is not known to require ExcludeArch. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package complies to the Packaging Guidelines [x]: Spec file lacks Packager, Vendor, PreReq tags. [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 is included in %doc. [x]: License field in the package spec file matches the actual license. [x]: Package consistently uses macro is (instead of hard-coded directory names). [x]: Package is named using only allowed ASCII characters. [x]: Package is named according to the Package Naming Guidelines. [x]: No %config files under /usr. [x]: Package does not generate any conflict. Note: Package contains no Conflicts: tag(s) [x]: Package do not use a name that already exist [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: Package installs properly. [x]: Package is not relocatable. [x]: Requires correct, justified where necessary. [x]: CheckResultdir [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file is legible and written in American English. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [-]: Package contains systemd file(s) if in need. [x]: File names are valid UTF-8. [-]: Large documentation must go in a -doc subpackage. Note: Documentation size is 30720 bytes in 2 files. [x]: Packages must not store files under /srv, /opt or /usr/local Python: [x]: Package contains BR: python2-devel or python3-devel [x]: Binary eggs must be removed in %prep [x]: Python eggs must not download any dependencies during the build process. [x]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python ===== SHOULD items ===== Generic: [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Dist tag is present. [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Final provides and requires are sane (rpm -q --provides and rpm -q --requires). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [x]: The placement of pkgconfig(.pc) files are correct. [x]: SourceX tarball generation or download is documented. The prepare-tarball.sh script should be checked into git after this package passes review. [x]: SourceX / PatchY prefixed with %{name}. [x]: SourceX is a working URL. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Spec use %global instead of %define. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Spec file according to URL is the same as in SRPM. [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Rpmlint ------- Checking: pybugz-0.10-1.git89df2.fc19.src.rpm pybugz-0.10-1.git89df2.fc19.noarch.rpm pybugz.src: W: invalid-url Source0: pybugz-0.10-git89df2.tar.gz This invalid-url warning is fine as long as people know where to find prepare-tarball.sh 2 packages and 0 specfiles checked; 0 errors, 1 warnings. Rpmlint (installed packages) ---------------------------- # rpmlint pybugz 1 packages and 0 specfiles checked; 0 errors, 0 warnings. # echo 'rpmlint-done:' Approved.
Thanks! fedora-cvs flag requested
(In reply to comment #11) Pavel, I think you also changed the fedora-review flag from '+' to '?' unintentionally. I've changed it back.
(In reply to comment #11) Pavel, Besides setting the "fedroa-cvs" flag to "?", you should also fill out a copy the "New Package SCM Request" template from http://fedoraproject.org/wiki/Package_SCM_admin_requests#New_Packages and post that as comment on this bug. I believe the git repo creation process can't work without this step. Remember that "Owners:" should list your FAS username.
New Package SCM Request ======================= Package Name: pybugz Short Description: Command line interface for Bugzilla written in Python Owners: praiskup Branches: f17 f18 el6 InitialCC: praiskup
Git done (by process-git-requests).
pybugz-0.10-4.git683dd.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/pybugz-0.10-4.git683dd.fc18
pybugz-0.10-4.git683dd.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/pybugz-0.10-4.git683dd.fc17
pybugz-0.10-4.git683dd.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/pybugz-0.10-4.git683dd.el6
Thanks for all your help Scott, I reverted my downstream changes and edited the manpage/code a little to allow users more easily adopt pybugs to Red Hat bugzilla. I'll update the package once something is pushed upstream. I created the {f17,f18,el6} updates already ~> closing NEXTRELEASE according to PG. Pavel
pybugz-0.10-4.git683dd.fc17 has been pushed to the Fedora 17 stable repository.
pybugz-0.10-4.git683dd.el6 has been pushed to the Fedora EPEL 6 stable repository.