Spec URL: http://cicku.me/dput.spec SRPM URL: http://cicku.me/dput-0.9.6.4-1.fc20.src.rpm Description: This is the debian package upload tool, or dput. dput has been developed because dupload, the only tool for doing uploads, has quite a few open bug reports and the code is in my opinion not very clean. Fedora Account System Username: cicku
1. Should /etc/bash_completion.d/dput be marked %config? It really isn't one, and no other bash_completion.d files are marked as such on my F19 box: for i in /etc/bash_completion.d/*;do printf "%02x %s\n" $(rpm -q --qf "%{fileflags}\n" -f $i) $i;done|grep -v ^00 2. Trivial consistency nit: 'install ... dput' has a trailing slash in the destination dir; no other install has a trailing slash. 3. The mkdirs ... are they necessary? Review guidelines state that "A package must own all directories that it creates". I think it's safe to remove everything except the two %{_datadir/%{name} ones, because the rest are owned by the filesystem package. (Even bash_completion.d, despite the messy rpm -qif /etc/bash_completion.d|grep ^Name).
1. If I don't mark it as %config I'm afraid rpmlint will shout. But it's right to not mark them as they are not conf files. I remember someone has marked it as %config, or maybe I forget, whatever. 2. Fixed. For issue 3, you can review my spec again: Spec URL: http://cicku.me/dput.spec SRPM URL: http://cicku.me/dput-0.9.6.4-2.fc20.src.rpm Not sure if you are packager now, if you get approved later, please continue.
[ disclaimer#1: I'm not a packager yet; I'm just trying to learn the ropes ] [ disclaimer#2: total n00b, so my interpretation of the guidelines may be off ] That said... 1. Thanks for removing the %config. I'm pretty sure that's the right thing to do, and the rpmlint non-conffile-in-etc warning is ignorable. 2. Thanks. 3. I'm sorry, I was totally, embarrassedly confused about directory ownership. Your original mkdirs were in fact fine, and probably preferable to the mix of -D in some but not all install commands. Again, I'm really sorry for my confusion. But: 4. You removed the gzip actions, and changed the man page install commands to write .gz files. I do not think that does what you think it does. (As in: yes, the files are named .gz, but they are not actually gzip'ed). Also, your -2 srpm seems to be corrupt (cpio: premature end of file). The sha1sum of my download is f33fce1a2cb4faab5504cc663649ca0ed0f4e63c.
(In reply to Ed Santiago from comment #4) Oh I forgot to cleanup my brain ;) Manpage should be installed to destdit mandir/man1 with install. Then RPM will automatically gzip them. Fixed. Spec URL: http://cicku.me/dput.spec SRPM URL: http://cicku.me/dput-0.9.6.4-3.fc20.src.rpm
My observations: 1) description could be improved Inspiration can be found in upstream: http://anonscm.debian.org/gitweb/?p=collab-maint/dput.git;a=blob;f=debian/control;hb=HEAD . 2) license: there are "and above" in copyright notices, I think it should be GPLv2+ 3) incorrect FSF address in /usr/bin/dput and /usr/bin/dcut, upstream should be notified 4) missing build requires python2-devel or python3-devel Here it is not so clear, what to do with it. There are *.py and *.pyc files in /usr/share/dput/, and this directory doesn't distinguish the python version. Proper directory could be %{python_sitelib} or %{python3_sitelib}, but these files are used as "plugins" and the code expects them in /usr/share/dput. Am I right these files should remain there? (I'm not python programmer.) I that case it could be just used python-devel as the build dependency (= using default python BR).
(In reply to František Dvořák from comment #6) > My observations: > > 1) description could be improved > > Inspiration can be found in upstream: > http://anonscm.debian.org/gitweb/?p=collab-maint/dput.git;a=blob;f=debian/ > control;hb=HEAD . Thanks, anonscm sometimes can't be accessed. I will change the description later. > 4) missing build requires python2-devel or python3-devel > > Here it is not so clear, what to do with it. > > There are *.py and *.pyc files in /usr/share/dput/, and this directory > doesn't distinguish the python version. Proper directory could be > %{python_sitelib} or %{python3_sitelib}, but these files are used as > "plugins" and the code expects them in /usr/share/dput. Am I right these > files should remain there? (I'm not python programmer.) > > I that case it could be just used python-devel as the build dependency (= > using default python BR). Well, I don't think this is a problem. This is not a python module, can't be used in system-wide, so we don't need to store it under python_sitelib, see my another package "git-cola". Do you want to review it? ;)
Yes, I can review it. :-) Do you plan to push it to EPEL? I can imagine dput could be useful also there (RHEL or RHEL-based server working with Debian packages...).
(In reply to František Dvořák from comment #8) > Yes, I can review it. :-) > > Do you plan to push it to EPEL? I can imagine dput could be useful also > there (RHEL or RHEL-based server working with Debian packages...). Sure, why not ;) I only don't include support for EL5 of all my packages.
Yes, EL6 is OK. It should not need the modifications. Waiting for the new version. :-) -- František
(In reply to František Dvořák from comment #10) > Yes, EL6 is OK. It should not need the modifications. Waiting for the new > version. :-) -- František Uh...New version? N-2 was released 1.5 years ago, N-1 released 0.5 years ago, awaiting what?
No, I just mean the new specfile/srpm, addressing the issues in comment #6.
(In reply to František Dvořák from comment #12) > No, I just mean the new specfile/srpm, addressing the issues in comment #6. Sorry, after a moment's indecision, I decide to close this bug and package dput-ng to replace this old tool. Please review that one when I'm ready ;) Ref: http://dput-ng.debian.net/
*** Bug 1063075 has been marked as a duplicate of this bug. ***