Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 182122 - Review Request: multitail
Review Request: multitail
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
Depends On:
  Show dependency treegraph
Reported: 2006-02-20 12:51 EST by Folkert van Heusden
Modified: 2012-02-28 08:15 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-14 11:31:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
limburgher: fedora‑cvs+

Attachments (Terms of Use)
Suggested specfile patch (1.58 KB, patch)
2006-02-22 14:44 EST, Jason Tibbitts
no flags Details | Diff
Specfile patch - missing changelog entry, convert make to macro, ... (876 bytes, patch)
2006-02-23 10:51 EST, Jose Pedro Oliveira
no flags Details | Diff

  None (edit)
Description Folkert van Heusden 2006-02-20 12:51:48 EST
Spec Name or Url: http://www.vanheusden.com/multitail/multitail.spec
SRPM Name or Url: http://www.vanheusden.com/multitail/multitail-3.8.6-0.src.rpm
Description: Lets you view several logfiles at once in a window, with colors and filtering.
Comment 1 Folkert van Heusden 2006-02-20 12:53:28 EST
MultiTail lets you view one or multiple files like the original tail program.
The difference is that it creates multiple windows on your console (with
ncurses). It can also monitor wildcards: if another file matching the wildcard
has a more recent modification date, it will automatically switch to that file.
That way you can, for example, monitor a complete directory of files. Merging of
2 or even more logfiles is possible. It can also use colors while displaying the
logfiles (through regular expressions), for faster recognition of what is
important and what not. It can also filter lines (again with regular
expressions). It has interactive menus for editing given regular expressions and
deleting and adding windows. One can also have windows with the output of shell
scripts and other software. When viewing the output of external software,
MultiTail can mimic the functionality of tools like 'watch' and such.
Comment 2 udo 2006-02-20 13:17:39 EST
Please remove gcc and make from BuildRequires
Comment 3 Folkert van Heusden 2006-02-20 13:21:50 EST
Comment 4 udo 2006-02-20 13:24:30 EST
# rpmlint /usr/src/redhat/SRPMS/multitail-3.8.6-0.src.rpm
W: multitail strange-permission multitail-3.8.6.tgz 0750
Comment 5 Jason Tibbitts 2006-02-20 23:02:09 EST
I wanted to provide a full review for this, but the links to the spec and srpm
are invalid (no permissions).
Comment 6 Folkert van Heusden 2006-02-21 03:59:46 EST
oh darn :-(
Ok, I fixed the permissions.
Comment 7 Jason Tibbitts 2006-02-22 12:00:45 EST
Umm, I was in the process of reviewing this.  Why did it get closed?
Comment 8 Folkert van Heusden 2006-02-22 12:07:20 EST
I have no idea. Should I resubmit it?
Comment 9 Jason Tibbitts 2006-02-22 14:43:27 EST
OK, the bug is repoened and back in shape.  Now, onto the review:

Release: should start at 1 and should include disttag.
Don't set Vendor: in extras packages.
Buildroot should include user ID.
Requires: ncurses is not necessary; rpm will pick up the dependency.
Suggest using %setup -q for a quieter build.
Suggest fixing up line endings in HTML files to quiet rpmlint.
Pass %{optflags} to make.
Add the release to the most recent changelog entry.

I will attach a patch to fix these and to put the spec more into line with the
Extras template.

I don't know what it hurts, but as in a previous comment, rpmlint complains
about the permissions on the source tarball.  I suggest changing the permisions
on the tarball in the srpm to 0644.

Please consider including the actual text of the license in your tarball.  (The
package submitter is supposed to bug upstream to do this, but you're the
upstream so I guess I'm supposed to bug you.)

Good stuff:
After building with the patched spec, rpmlint is silent and the package builds
in mock (development, i386 and x86_64).
Source file matches upstream.
License is appropriate and matches source.

Fix up the above issues and I'll approve the package, or let me know what you
disagree with and we'll figure something out.
Comment 10 Jason Tibbitts 2006-02-22 14:44:27 EST
Created attachment 125051 [details]
Suggested specfile patch
Comment 11 Jose Pedro Oliveira 2006-02-22 15:35:54 EST
Two more minor suggestions:

* We only need to override CFLAGS (no need to override the value of CC).
  The following line resolves the distro CFLAGS inheritance problem:

     CFLAGS="%{optflags}" make %{?_smp_mflags}

* We can also drop the %doc tag from the man page entry in the %files section.
  (rpm automatically tags manpages as doc files).

Everything else looks good with Jason's patch applied.


PS - And the package can also be updated to version 3.8.7 ;)
Comment 12 Jason Tibbitts 2006-02-22 15:51:55 EST
Thanks; I had tried a different setting of CFLAGS but that broke the build. 
Everything works with your method.  I also didn't realize that manpages were
automatically tagged as %doc.

I also notice that 3.8.7 includes the license text in the tarball so I think
Folkert is on top of things.
Comment 13 Folkert van Heusden 2006-02-22 16:18:55 EST
My guess is that that build problem is caused by the 'VERSION' define not being
set if omitted from the CFLAGS variable. Suggestions for generic fixes are
welcome but I would like to keep it somewhere in the Makefiles-parts as I then
only have to set it in one place when I release a new version.
Comment 14 Jose Pedro Oliveira 2006-02-22 16:31:46 EST
(In reply to comment #12)
> Thanks; I had tried a different setting of CFLAGS but that broke the build. 
> Everything works with your method.  I also didn't realize that manpages were
> automatically tagged as %doc.

No problem. I have been maintaining my own multitail specfile for several years
now ;)

Comment 15 Folkert van Heusden 2006-02-23 02:08:14 EST
Ok, my good friend Udo van den Heuvel fixed the suggested changes and I've
uploaded the new spec and srpm-file to my site:
Comment 16 Jose Pedro Oliveira 2006-02-23 09:35:49 EST

Please do the following:
  * apply the changes mentioned in comment #11,
  * drop one of the summary lines (there are two of them),
  * drop the INSTALL file from the %doc line,
  * and drop desktop_vendor definition line (not used in the specfile)

Comment 17 Folkert van Heusden 2006-02-23 10:21:31 EST
Done except the man-page thing: the packager told me that if he does that, then
rpm complains about found files that are not mentioned in the %files-section.
Comment 18 Folkert van Heusden 2006-02-23 10:23:33 EST
spec at previous location
Comment 19 Jose Pedro Oliveira 2006-02-23 10:50:03 EST
(In reply to comment #17)
> Done except the man-page thing: the packager told me that if he does that, then
> rpm complains about found files that are not mentioned in the %files-section.

Never saw that complain. Which version of rpm/distro is he using?
For RedHat/Fedora distros is safe to remove the %doc tag from man pages
file entries.

You also forgot to add the changelog entry (and the last one is missing the
release entry; rpmlint complains about these omissions). It is also custom to
mention the bugzilla entry in changelog entries.

Comment 20 Jose Pedro Oliveira 2006-02-23 10:51:15 EST
Created attachment 125112 [details]
Specfile patch - missing changelog entry, convert make to macro, ...
Comment 21 udo 2006-02-23 10:56:04 EST
I am using FC4.
rpm 4.4.1.
Comment 22 Jason Tibbitts 2006-02-23 11:07:11 EST
Too many people in this review....

I get clean builds after taking out the %doc tag, but just on the file in
%{_mandir}.  You will certainly see problems if you remove it from the other line.

Jose's being picky about change "make" to a macro, but everything else in the
spec is using them so it makes sense for consistency.  He's right about the
changelogs, they should be kept consistent and the release tag needs to appear
for each change.

I would like to get this package done and out the door.  With Jose's last patch,
I'm ready to approve.  Let me do a couple of final mock builds first.
Comment 23 Folkert van Heusden 2006-02-23 12:04:21 EST
Hopefully this one is the final, fingers crossed! :-)
Comment 24 Jose Pedro Oliveira 2006-02-23 12:23:02 EST

The above line gives my approval (one vote for approval). As there is at least
one more reviewer he will also cast his vote. As Jason has taken the lead in the
review process he will be the one given the final approval.


Just a picky note in the second changelog entry - the update statement release
number doesn't match the the one in the changelog entry header (2 != 3). This
can be corrected later.
Comment 25 Jason Tibbitts 2006-02-23 12:41:56 EST
Yes, I agree, but do be careful about the changelog entries when you check in.

Comment 26 Jason Tibbitts 2006-03-07 22:04:36 EST
It turns out that a sponsor is needed here.  I cannot sponsor, so I'm not sure
what should happen to this package.
Comment 27 Jose Pedro Oliveira 2006-03-08 15:59:47 EST
I will sponsor Folkert.

Importing the following SRPM
d05b27f3dcfee11ebd8f856ab8dadab3  multitail-3.8.7-3.src.rpm
with the tarball
b216c9e0d598e3e048b2c6738a54ba08  multitail-3.8.7.tgz

Comment 28 Jose Pedro Oliveira 2006-03-14 11:31:01 EST
Closnig this ticket.
multitail 3.8.7 already in the mirrors.
multitail 3.8.9 will appear shortly (next push).
Comment 29 Jon Stanley 2012-02-27 16:31:45 EST
Package Change Request
Package Name: multitail
New Branches: EL-5 EL-6
Owners: jstanley

Current maintainer does not wish to maintain in EPEL (will continue in Fedora) - see bug 797925.
Comment 30 Gwyn Ciesla 2012-02-28 08:15:50 EST
Git done (by process-git-requests).

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