Bug 560176

Not reviewing yet, but is it really a good idea for this package to use such a generic name like /usr/bin/bar?

repoquery shows that nothing else in Fedora in is providing /usr/bin/bar, so I'm not sure what we'd be saving that name for.  Also, given that this is a command line utility, given it a more complex name makes it more difficult to use at the command line.

What's next, a package that provides /usr/bin/foo? :D

But really, the name of the project is a bit.. general.

Well, the name of the project is clpbar ("Command Line Progress Bar").
At least /usr/bin/clpbar would be a little bit less generic.


> I'm not sure what we'd be saving that name for.

Why would we want to occupy the name for this tool?

$ bar
============================================================
$

> Also, given that this is a command line utility, given
> it a more complex name makes it more difficult to
> use at the command line.    

alias clpbar=/usr/bin/command-line-progress-bar
alias bar=command-line-progress-bar
alias di=debuginfo-install

;)

(In reply to comment #4)
> Well, the name of the project is clpbar ("Command Line Progress Bar").
> At least /usr/bin/clpbar would be a little bit less generic.
> 
> 
> > I'm not sure what we'd be saving that name for.
> 
> Why would we want to occupy the name for this tool?
> 
> $ bar
> ============================================================
> $
> 
> > Also, given that this is a command line utility, given
> > it a more complex name makes it more difficult to
> > use at the command line.    
> 
> alias clpbar=/usr/bin/command-line-progress-bar
> alias bar=command-line-progress-bar
> alias di=debuginfo-install
> 
> ;)    

So why not install all of the GNU coreutils with program prefix of 'g' or better yet 'gnu-coreutils-' and require people to select the commands they want via shell aliases?  I mean, at some point in time someone might want to port the BSD ls command to Fedora and then we'd have a difficult time naming commands.

I'm not trying to defend the name 'bar' for this command.  To me, we should install programs as named by the authors unless they conflict with something else already part of the system.  Reserving command names for possible future use seems a bit subjective and pointless.

That said, I'll work up a change to this package and repost because I really don't care what the name is so long as the package can enter Fedora and I don't need to keep carrying it along on the side.

New SRPM and spec file posted:

http://dcantrel.fedorapeople.org/clpbar/clpbar.spec
http://dcantrel.fedorapeople.org/clpbar/clpbar-1.10.9-2.fc12.src.rpm

Review

[+] rpmlint messages can be ignored.

rakesh@simu SPECS]$ rpmlint /home/rakesh/rpmbuild/SRPMS/clpbar-1.10.9-2.fc12.src.rpm
clpbar.src: W: spelling-error %description -l en_US stderr -> std err, std-err, stander
clpbar.src: E: no-spec-file
1 packages and 0 specfiles checked; 1 errors, 1 warnings.
[rakesh@simu SPECS]$ rpmlint -i /home/rakesh/rpmbuild/SRPMS/clpbar-1.10.9-2.fc12.src.rpm
clpbar.src: W: spelling-error %description -l en_US stderr -> std err, std-err, stander
The value of this tag appears to be misspelled. Please double-check.

clpbar.src: E: no-spec-file
No spec file was specified in your RPM building. Please specify a valid SPEC
file to build a valid RPM package.

1 packages and 0 specfiles checked; 1 errors, 1 warnings.

[+] Spec name ok

[rakesh@simu SPECS]$ rpmls /home/rakesh/clpbar-1.10.9-2.fc12.src.rpm 
-rw-rw-r--  bar-1.10.9-clpbar.patch
-rw-rw-r--  bar_1.10.9.tar.gz
-rw-r--r--  clpbar.1.in
-rw-rw-r--  clpbar.spec


[rakesh@simu SPECS]$ 
[rakesh@simu SPECS]$ rpmlint /home/rakesh/rpmbuild/RPMS/x86_64/clpbar-1.10.9-2.fc12.x86_64.rpm
clpbar.x86_64: W: spelling-error %description -l en_US stderr -> std err, std-err, stander
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
[rakesh@simu SPECS]$ rpmlint /home/rakesh/rpmbuild/RPMS/x86_64/clpbar-debuginfo-1.10.9-2.fc12.x86_64.rpm
clpbar-debuginfo.x86_64: E: empty-debuginfo-package
1 packages and 0 specfiles checked; 1 errors, 0 warnings.

[-] Debuginfo empty



[rakesh@simu SPECS]$ rpmls /home/rakesh/rpmbuild/RPMS/x86_64/clpbar-debuginfo-1.10.9-2.fc12.x86_64.rpm
[rakesh@simu SPECS]$ du -sh  /home/rakesh/rpmbuild/RPMS/x86_64/clpbar-debuginfo-1.10.9-2.fc12.x86_64.rpm
4.0K	/home/rakesh/rpmbuild/RPMS/x86_64/clpbar-debuginfo-1.10.9-2.fc12.x86_64.rpm
[rakesh@simu SPECS]$ 


[+] Build - ok

http://koji.fedoraproject.org/koji/taskinfo?taskID=2189136

[+] source ok
from srpm (sha1sum)

[rakesh@simu ~]$ sha1sum bar_1.10.9.tar.gz 
324d5e199f07e8d299253a8748a5aec9a6381315  bar_1.10.9.tar.gz
[rakesh@simu ~]$ sha1sum rpmbuild/SOURCES/bar_1.10.9.tar.gz 
324d5e199f07e8d299253a8748a5aec9a6381315  rpmbuild/SOURCES/bar_1.10.9.tar.gz

[+] name fine
[+] URL fine
[+] license ok (copy present) and source has marking
[+] source tree ok (no binaries present)
[+] archs - fine
[+] spec file legible and in american english
[+] BR's ok
[+] %files ok
[+] folders owned - ok

/usr/share/doc/clpbar-1.10.9

[+] %clean section ok
[+] filenames - ok (valid)
[+] checks included - ok

Summary: Fix the empty debuginfo generated ?

Thanks,

Also, source code does not include license blocks on top and COPYING file mentions GPLv2 license. May you confirm with upstream about license bits and request them to include it into code if possible ?

Thanks,

> Fix the empty debuginfo generated ?

That's because the package doesn't use our global %optflags and additionally adds -s to strip the programs.

https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags

The upstream for clpbar seems long dead, the latest version came out 3 years ago and the CVS is empty.

See http://sourceforge.net/projects/clpbar/files/

Have you ever send bar-1.10.9-clpbar.patch to upstream, this patch is not a fedora specific patch.

New SRPM and spec posted:

http://dcantrel.fedorapeople.org/clpbar/clpbar.spec
http://dcantrel.fedorapeople.org/clpbar/clpbar-1.10.9-2.fc12.src.rpm

Issues addressed:

1) The debuginfo package contains debug information now (removed the LDFLAGS override).
2) The Makefile does not override the RPM opt flags.

Answers to other questions or statements made:
1) "The upstream for clpbar seems long dead, the latest version came out 3 years
ago and the CVS is empty."

This is true.  I'm not sure the author ever used the SourceForge CVS service.  He may just have uploaded tarballs for release.  I emailed him for clarification.

It is also true that there have been no releases in 3 years, but that does not mean the project is dead or not useful.  procps often goes years between actual releases.

2) "Have you ever send bar-1.10.9-clpbar.patch to upstream, this patch is not a
fedora specific patch."

I have not and would prefer not to.  The patch itself just changes the source to install the application as 'clpbar' instead of 'bar' (and man page as 'clpbar.1' instead of 'bar.1'), so in that respect I would consider it Fedora-specific.  However, he does carry Debian-specific packaging information in the upstream source, so I will ask if he is interested in our packaging changes.

2) "Also, source code does not include license blocks on top and COPYING file
mentions GPLv2 license. May you confirm with upstream about license bits and
request them to include it into code if possible ?"

The COPYING file is actually the LGPL version 2, not the GPL version 2.  It is true that his source files do not have any license boilerplate.  I asked the author for clarification on the issue.  My reason for considering the entire package LGPLv2 is the fact that the COPYING file is included in the source and the debian/copyright file in the source tree confirms this.  The package is or was included with Debian at some point, but I do not know how to check if it is still part of Debian or not.


Thanks for the review feedback.

Correction:

http://dcantrel.fedorapeople.org/clpbar/clpbar.spec
http://dcantrel.fedorapeople.org/clpbar/clpbar-1.10.9-3.fc12.src.rpm

I emailed the author today and here's his reply:

> David Cantrell wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>.
>> Michael,
>>.
>> I would like to package up clpbar for inclusion in Fedora Linux.
>
> Cool!
>
>> Looking at
>> the sourceforge download page for the project, the latest version appears.
>> to be 1.10.9.  If I am looking in the wrong location for project source, let.
>> me know.
>
> You got it.
>
>> Some other questions:
>>.
>> 1) The COPYING file indicates the GNU LGPL version 2 or any later version,
>> however none of the source files include the LGPL license boilerplate.  In
>> fact, there's no boilerplate text in the files.  Does the LGPL license.
>> cover the entire project?
>
> It covers the entire project, yes.
>
>> 2) Is there are an upstream source repository?  The CVS repository on the
>> sourceforge project page is empty.
>
> I don't have a repository, but I've kept the download page up-to-date.
> (Bar is pretty stable now and nothing has changed for nearly a year.)
>
> Michael


So, he confirmed that LGPLv2 covers the entire project and that he does not use version control, but just makes releases.

Any updates on this review?

Sorry for delay in replying .. was bit unwell.

I APPROVE your package.

Thanks,

New Package CVS Request
=======================
Package Name: clpbar
Short Description: Show information about a data transfer
Owners: dcantrel
Branches: F-13 EL-6
InitialCC:

CVS Done