Bug 987738

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.

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. ***