Bug 560176 - Review Request: clpbar - Show information about a data transfer
Summary: Review Request: clpbar - Show information about a data transfer
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Rakesh Pandit
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-30 03:23 UTC by David Cantrell
Modified: 2010-05-25 21:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-25 21:19:52 UTC
rpandit: fedora-review+
dennis: fedora-cvs+


Attachments (Terms of Use)

Description David Cantrell 2010-01-30 03:23:18 UTC
Spec URL: http://dcantrel.fedorapeople.org/clpbar/clpbar.spec
SRPM URL: http://dcantrel.fedorapeople.org/clpbar/clpbar-1.10.9-1.fc12.src.rpm
Description:
Bar is a simple tool to process a stream of data and print a display for the
user on stderr showing (a) the amount of data passed, (b) the throughput of the
data transfer, and, if the total size of the data stream is known, (c)
estimated time remaining, percent complete, and a progress bar.  Bar was
originally written for the purpose of estimating the amount of time needed to
transfer large amounts (many, many gigabytes) of data across a network.
(Usually in an SSH/tar pipe.)

NOTES:
1) I named the package 'clpbar' because that's the name of the SourceForge project and the name of the package in Debian.  However, the actual command installed is /usr/bin/bar and the manpage is bar(1).

2) I added a %check section to the spec file even though the packaging guidelines don't say anything about that.

Comment 1 Warren Togami 2010-01-30 04:25:36 UTC
Not reviewing yet, but is it really a good idea for this package to use such a generic name like /usr/bin/bar?

Comment 2 David Cantrell 2010-01-31 00:46:25 UTC
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.

Comment 3 Susi Lehtola 2010-01-31 17:06:02 UTC
What's next, a package that provides /usr/bin/foo? :D

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

Comment 4 Michael Schwendt 2010-01-31 18:44:51 UTC
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

;)

Comment 5 David Cantrell 2010-02-02 01:51:54 UTC
(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.

Comment 7 Rakesh Pandit 2010-05-15 06:43:22 UTC
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,

Comment 8 Rakesh Pandit 2010-05-15 06:48:04 UTC
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,

Comment 9 Michael Schwendt 2010-05-15 09:20:41 UTC
> 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

Comment 10 Chen Lei 2010-05-15 13:16:25 UTC
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.

Comment 11 David Cantrell 2010-05-19 14:19:00 UTC
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.

Comment 13 David Cantrell 2010-05-19 19:44:52 UTC
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.

Comment 14 David Cantrell 2010-05-21 23:20:36 UTC
Any updates on this review?

Comment 15 Rakesh Pandit 2010-05-22 13:54:12 UTC
Sorry for delay in replying .. was bit unwell.

I APPROVE your package.

Thanks,

Comment 16 David Cantrell 2010-05-22 23:26:01 UTC
New Package CVS Request
=======================
Package Name: clpbar
Short Description: Show information about a data transfer
Owners: dcantrel
Branches: F-13 EL-6
InitialCC:

Comment 17 Dennis Gilmore 2010-05-25 21:00:47 UTC
CVS Done


Note You need to log in before you can comment on or make changes to this bug.