Bug 524119 - Review Request: nmon - Nigel's performance MONitor for Linux
Review Request: nmon - Nigel's performance MONitor for Linux
Status: CLOSED DUPLICATE of bug 915337
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
NotReady
:
Depends On:
Blocks: 714194
  Show dependency treegraph
 
Reported: 2009-09-17 18:25 EDT by Dylan Swift
Modified: 2013-10-19 10:42 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 915337 (view as bug list)
Environment:
Last Closed: 2013-02-25 10:37:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Corrected spec file (1.20 KB, application/octet-stream)
2010-08-09 21:55 EDT, d. johnson
no flags Details

  None (edit)
Description Dylan Swift 2009-09-17 18:25:45 EDT
Spec URL: http://sites.google.com/site/nmonfedora/home/nmon-12d-1-src-rpm/nmon-12d-1.src.rpm?attredirects=0
SRPM URL: http://sites.google.com/site/nmonfedora/home/nmon-12d-1-src-rpm/nmon.spec?attredirects=0
Description: This systems administrator, tuner, benchmark tool gives you a huge amount of
important performance information in one go. The data can be accessed in two
ways:
1. On screen (console/terminal based using curses)
2. Dump to CSV file (data can be accessed using 'nmon analyser excel 2000
spreadsheet', added to rrd database, or read via your own tools)

This is my first package and I am seeking a sponsor

I also need hosting space
Comment 1 Susi Lehtola 2009-09-18 09:33:06 EDT
- Drop the 'rm' statements from %prep, they are not necessary.

- Drop the patch and the hard link, they are not necessary. Instead, just compile the program manually in %build (the makefile is trivial and badly written) with
 gcc $RPM_OPT_FLAGS -D JFS -D GETUSER -D LARGEMEM -o nmon lmon%{version}.c

- In %install, just run
 rm -rf $RPM_BUILD_ROOT
 install -D -p -m 755 nmon $RPM_BUILD_ROOT%{_bindir}/nmon
Comment 2 Susi Lehtola 2009-09-18 09:34:41 EDT
- Add %{?dist} to your release tag.

- Drop the explicit Require, it's automatically picked up by rpm.
http://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires
Comment 3 Dominik 'Rathann' Mierzejewski 2009-09-18 09:42:21 EDT
(In reply to comment #1)
> - Drop the patch and the hard link, they are not necessary. Instead, just
> compile the program manually in %build (the makefile is trivial and badly
> written) with
>  gcc $RPM_OPT_FLAGS -D JFS -D GETUSER -D LARGEMEM -o nmon lmon%{version}.c
> 
> - In %install, just run
>  rm -rf $RPM_BUILD_ROOT
>  install -D -p -m 755 nmon $RPM_BUILD_ROOT%{_bindir}/nmon  

I believe it is better to fix the build system and send the fixes upstream. That way other distributions won't have to invent their own workarounds. And since this software is really simple to build, it shouldn't be too difficult to fix the default build target and add an install target to the Makefile.
Comment 4 Susi Lehtola 2009-09-18 09:51:31 EDT
Yes, but IMHO that patch does not fix the brokenness of the upstream makefile, it's still hopelessly complicated. (Actually, I'm missing -lncurses in the compile command in comment #2).

Just a simple makefile would do:

**

CC=cc
CFLAGS=-g -O2 -Wall
LDFLAGS=-lncurses
EXTRADEFS=

default: nmon
nmon: nmon.c
        $(CC) $(CFLAGS) -D JFS -D GETUSER -D LARGEMEM $(EXTRADEFS) $(LDFLAGS) -o nmon nmon.c

**


Normally, one would just run
 $ make
and if one is on special architectures, like power or mainframe which need special definitions, one would run e.g.
 $ make EXTRADEFS="-D POWER"
Comment 5 Dylan Swift 2009-09-18 18:35:52 EDT
Thanks for the input Dominik & Jussi. I have implemented the changes in Jussi's comments and will refer Nigel (the original author) back to your comments Dominik as he has 'control' of the makefile. 

Jussi - if I add %{?dist} to the release tag then the src rpm becomes labelled with the os version. Is this normal? because this would mean having to release a different version for each current version of Fedora, where I think that the spec file could be modified to support all versions (adding any necessary changes when new releases are made).

Does anyone know the normal method for testing this on alternate distributions. I have a qemu vm running Fedora 11, and have found a few issues which may or may not be to do with the new OS, or this particular installation, namely gcc builds with debug info in the rpm, rather than in a seperate rpm. I don't know if this is a rpmbuild or gcc issue. This does require fixing as it is issued as a warning when running rpmlint on the binary rpm files.
Comment 6 Susi Lehtola 2009-09-19 10:16:57 EDT
(In reply to comment #5)
> Thanks for the input Dominik & Jussi. I have implemented the changes in Jussi's
> comments and will refer Nigel (the original author) back to your comments
> Dominik as he has 'control' of the makefile. 
> 
> Jussi - if I add %{?dist} to the release tag then the src rpm becomes labelled
> with the os version. Is this normal? because this would mean having to release
> a different version for each current version of Fedora, where I think that the
> spec file could be modified to support all versions (adding any necessary
> changes when new releases are made).

Yes, it is. The spec file is completely general, and if you build e.g. a .f11 srpm on Fedora 10 you'll get out a .f10 RPM.

> Does anyone know the normal method for testing this on alternate distributions.
> I have a qemu vm running Fedora 11, and have found a few issues which may or
> may not be to do with the new OS, or this particular installation, namely gcc
> builds with debug info in the rpm, rather than in a seperate rpm. I don't know
> if this is a rpmbuild or gcc issue. This does require fixing as it is issued as
> a warning when running rpmlint on the binary rpm files.  

Do you have redhat-rpm-config installed?
Comment 7 Dylan Swift 2009-09-19 14:57:31 EDT
> Yes, it is. The spec file is completely general, and if you build e.g. a .f11
> srpm on Fedora 10 you'll get out a .f10 RPM.

Aha! Of Course! (somewhere, a light comes on)

So just to clarify, what you're saying is that even if the f10 & f11 SRPMS are identical, there still needs to be two seperate SRPMS, rather than one without the %{?dist} tag?

That now begs another question - do I need to change this 'review request' submission from rawhide to Fedora 10, and then submit another for Fedora 11?

> Do you have redhat-rpm-config installed?  

I do now, thanks. That has sorted it out.
Comment 8 Susi Lehtola 2009-09-19 16:53:20 EDT
(In reply to comment #7)
> > Yes, it is. The spec file is completely general, and if you build e.g. a .f11
> > srpm on Fedora 10 you'll get out a .f10 RPM.
> 
> Aha! Of Course! (somewhere, a light comes on)
> 
> So just to clarify, what you're saying is that even if the f10 & f11 SRPMS are
> identical, there still needs to be two seperate SRPMS, rather than one without
> the %{?dist} tag?

Not exactly. The RPMs built on different distributions from the same SRPM will be different. But in the review it is generally enough that the package builds in the development tree (rawhide).
 
> That now begs another question - do I need to change this 'review request'
> submission from rawhide to Fedora 10, and then submit another for Fedora 11?

No. The %{?dist} tag is a SHOULD item, and comes from the fact that once the package has been approved and imported in Fedora CVS, you won't be able to build the package for e.g. Fedora 10 and Fedora 11, since the build system won't allow you to tag multiple spec files with the same version and release.

> > Do you have redhat-rpm-config installed?  
> 
> I do now, thanks. That has sorted it out.  

Funny, it should have been part of the standard package set for some time now..
Comment 9 Dylan Swift 2009-09-20 04:05:18 EDT
> > So just to clarify, what you're saying is that even if the f10 & f11 SRPMS are
> > identical, there still needs to be two seperate SRPMS, rather than one without
> > the %{?dist} tag?
> 
> Not exactly. The RPMs built on different distributions from the same SRPM will
> be different. But in the review it is generally enough that the package builds
> in the development tree (rawhide).

That still confuses me - why then have different SRPMS if they contain the same course and SPEC files?

> > That now begs another question - do I need to change this 'review request'
> > submission from rawhide to Fedora 10, and then submit another for Fedora 11?
> 
> No. The %{?dist} tag is a SHOULD item, and comes from the fact that once the
> package has been approved and imported in Fedora CVS, you won't be able to
> build the package for e.g. Fedora 10 and Fedora 11, since the build system
> won't allow you to tag multiple spec files with the same version and release.

so does that mean it is only possible to add new packages to rawhide and not to currently supported distributions (f10 & f11)

also surely it is the other way around, a single SPEC file (in a single SRPM) for multiple distributions?

> > > Do you have redhat-rpm-config installed?  
> > 
> > I do now, thanks. That has sorted it out.  
> 
> Funny, it should have been part of the standard package set for some time now.. 

I had built a minimal F11 in a VM, and must have unchecked something I shouldn't have (though surely redhat-rpm-config should still have been immutable?). I think I will rebuild the VM using the defined minimum, and not muck about with the kickstart. Then I shall use mock to test the build rather than just the OS in the VM.

Thanks for your help so far.
Comment 10 Susi Lehtola 2009-09-20 04:15:01 EDT
(In reply to comment #9)
> > Not exactly. The RPMs built on different distributions from the same SRPM will
> > be different. But in the review it is generally enough that the package builds
> > in the development tree (rawhide).
> 
> That still confuses me - why then have different SRPMS if they contain the same
> course and SPEC files?

Who said anything about having to have multiple SRPMs? :)
When you generate an srpm, the %{?dist} tag in the Release field gets evaluated to the value it has on the distribution. So even though the SRPMs generated on Fedora 10 and Fedora 11 were identical in their content, they still would get different versions.

But if you built the Fedora 10 SRPM on Fedora 11, you would get out Fedora 11 RPMs.

> > No. The %{?dist} tag is a SHOULD item, and comes from the fact that once the
> > package has been approved and imported in Fedora CVS, you won't be able to
> > build the package for e.g. Fedora 10 and Fedora 11, since the build system
> > won't allow you to tag multiple spec files with the same version and release.
> 
> so does that mean it is only possible to add new packages to rawhide and not to
> currently supported distributions (f10 & f11)

No. If you don't use the %{?dist} tag, then you can add e.g. the -1 release to F10, the -2 release to F11 and the -3 release to rawhide. With the dist tag, you can have e.g. -3%{?dist} in all of the distros, since they will be evaluated as different (-3.fc10, -3.fc11 and -3.fc12).

> also surely it is the other way around, a single SPEC file (in a single SRPM)
> for multiple distributions?

The whole idea of the %{?dist} tag is to make this possible within the limitations of the build system. Once again: even though the spec file were identical on all of the distributions, the release tag of the RPMs/SRPMs generated from it have different revisions since %{?dist} is evaluted to e.g. fc11.
Comment 11 Dylan Swift 2009-09-20 05:29:45 EDT
> > That still confuses me - why then have different SRPMS if they contain the > same
> > course and SPEC files?
> 
> Who said anything about having to have multiple SRPMs? :)
> When you generate an srpm, the %{?dist} tag in the Release field gets 
> evaluated
> to the value it has on the distribution. So even though the SRPMs generated on
> Fedora 10 and Fedora 11 were identical in their content, they still would get
> different versions.

when I run rpmbuild -ba I get an SRPM file with the %{?dist} tag in the filename. So when I run on my f10 machine I get one file, when I run on my f11 machine I get another.

> But if you built the Fedora 10 SRPM on Fedora 11, you would get out Fedora 11
> RPMs.

Understood

> > > No. The %{?dist} tag is a SHOULD item, and comes from the fact that once 
> the
> > > package has been approved and imported in Fedora CVS, you won't be able to
> > > build the package for e.g. Fedora 10 and Fedora 11, since the build system
> > > won't allow you to tag multiple spec files with the same version and 
> release.
> >
> > so does that mean it is only possible to add new packages to rawhide and 
> not to
> > currently supported distributions (f10 & f11)
> 
> No. If you don't use the %{?dist} tag, then you can add e.g. the -1 release to
> F10, the -2 release to F11 and the -3 release to rawhide. With the dist tag,
> you can have e.g. -3%{?dist} in all of the distros, since they will be
> evaluated as different (-3.fc10, -3.fc11 and -3.fc12).
> 
> > also surely it is the other way around, a single SPEC file (in a single 
> SRPM)
> > for multiple distributions?
> 
> The whole idea of the %{?dist} tag is to make this possible within the
> limitations of the build system. Once again: even though the spec file were
> identical on all of the distributions, the release tag of the RPMs/SRPMs
> generated from it have different revisions since %{?dist} is evaluted to e.g.
> fc11.

but if the %{?dist} tag is irrelevant to the binary (the system building the binary determines that) then why have the %{?dist} tag in the SRPM?

Ultimately what I need to know is what do I upload nmon-12d-1-f10.srpm or nmon-12d-1-f11.srpm or does it not matter?

I haven't attempted to build on f12 yet - I don't have a copy of the latest. Should I be worried about that?


thanks again for your help on this.
Comment 12 Martin Gieseking 2009-09-21 10:09:05 EDT
(In reply to comment #11)
> Ultimately what I need to know is what do I upload nmon-12d-1-f10.srpm or
> nmon-12d-1-f11.srpm or does it not matter?

You can use either of them. To put it simply, it's not the filename that matters here but the contents of the file.

 
> I haven't attempted to build on f12 yet - I don't have a copy of the latest.
> Should I be worried about that?

No, you don't need to worry about that and you don't need to install several Fedora releases either. With the koji build system it's possible to create scratch builds for various targets and Fedora versions. See http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Scratch_builds_2 for instance.
You can also use mock to build rpms for different Fedora/EPEL releases on your current system. Install mock, then use ls /etc/mock to get a list of available, pre-configured targets.
Comment 13 Mamoru TASAKA 2009-10-11 11:25:17 EDT
Well, then what is the status of this bug?
Where is the latest srpm?
Comment 14 Dylan Swift 2009-10-11 14:01:12 EDT
Hi Mamoru,

I hope to be able to upload this very soon - I've been stalled by other work!

Dylan
Comment 15 Mamoru TASAKA 2010-07-04 10:45:59 EDT
What is the status of this bug?
Comment 16 Dylan Swift 2010-07-12 03:55:30 EDT
Hi Mamoru,

I'm currently trying to re-package the latest version (13g). 

I am still stuck as to how to proceed to get this package sponsored. Is there anyone who has any guidance on what to do next to get sponsored?

In the meantime I will try to get a binary rpm available somewhere online for those who are keen to use the package outside of the fedora repos.

Rgds

Dylan
Comment 17 Ankur Sinha (FranciscoD) 2010-07-12 04:10:54 EDT
(In reply to comment #16)
> Hi Mamoru,
> 
> I'm currently trying to re-package the latest version (13g). 
> 
> I am still stuck as to how to proceed to get this package sponsored. Is there
> anyone who has any guidance on what to do next to get sponsored?
> 
> In the meantime I will try to get a binary rpm available somewhere online for
> those who are keen to use the package outside of the fedora repos.
> 
> Rgds
> 
> Dylan    

google is your friend :)

https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

Ankur
Comment 18 Dylan Swift 2010-07-12 05:53:02 EDT
Thanks Ankur,

now I understand that *I* need to be sponsored, not the package!

I'll get to work on that.

Dylan
Comment 19 d. johnson 2010-08-09 21:55:45 EDT
Created attachment 437742 [details]
Corrected spec file

After using the attached spec file, rpmlint only complains a little:

$ rpmlint *.rpm
nmon.src: W: spelling-error %description -l en_US analyser -> analyzer, analysis, analyst
nmon.x86_64: W: spelling-error %description -l en_US analyser -> analyzer, analysis, analyst
nmon.x86_64: W: no-manual-page-for-binary nmon
3 packages and 0 specfiles checked; 0 errors, 3 warnings.

The author really needs to include a copy of the license file, and a man page of some sort in the package itself.

Archiving off http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmon+Manual would be better than nothing.
Comment 20 Dylan Swift 2010-08-18 18:27:31 EDT
Thanks d. johnson for the spec file. I shall take a look over the next couple of days & hope to get back to you over this coming weekend.

I have a man page ready to put in - I chose not to use the wiki as that is for nmon, and this package is actually from nmon for linux. I didn't want to pollute the manpage with any options that might not be available in the linux version event though they ultimately come from the same source. However I think I may now take a better look at the nmon wiki and see if there is some useful content.

Dylan
Comment 21 Troels Arvin 2010-11-25 06:17:13 EST
Is there a way to help moving this RFE forward? I use nmon on all my Linuxes and find that it's a very valuable tool. So it would be nice to have it available as a simple "yum install nmon" option.
Comment 22 Ankur Sinha (FranciscoD) 2011-03-13 16:06:46 EDT
(In reply to comment #20)
> Thanks d. johnson for the spec file. I shall take a look over the next couple
> of days & hope to get back to you over this coming weekend.
> 
> I have a man page ready to put in - I chose not to use the wiki as that is for
> nmon, and this package is actually from nmon for linux. I didn't want to
> pollute the manpage with any options that might not be available in the linux
> version event though they ultimately come from the same source. However I think
> I may now take a better look at the nmon wiki and see if there is some useful
> content.
> 
> Dylan


Ping Dylan?
Comment 23 Dylan Swift 2011-03-13 19:04:16 EDT
Ping Ankur,

gosh I'm so sorry folks, I hadn't realised so much time had passed! (lots of work trips, and a new baby consumed all my spare cycles) 

Let me see if I can't get something together in the next week.

Dylan
Comment 24 Susi Lehtola 2011-12-16 05:13:21 EST
Ping Dylan?
Comment 25 Dylan Swift 2011-12-16 06:08:32 EST
Pong, 

Hi Jussi

I have just been learning a lot about building rpms (at work) so I plan to get this up to the latest version soon. 

I did discover someone else packaging this I thought it was dag wieers, but I can't locate the package now so you might have better luck finding it elsewhere.

Dylan
Comment 27 David Juran 2012-04-04 08:53:48 EDT
Starting with rpmlint:
nmon.src: W: spelling-error %description -l en_US analyser -> analyses, analyzer, analysand
UK vs. US spelling. I guess...

nmon.src: W: spelling-error %description -l en_US rrd -> red, rd, rid
OK

But really, I would exchange the entire description section for something short and concise like "System administrator's tuner and benchmark tool. Can be used interactivly through curses-based CLI or export CSV data"

nmon.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/nmon-14g/Documentation.txt
Fix it in the %prep section with sed: sed -i 's/\r//' src/somefile or dos2unix. 

nmon.x86_64: W: no-manual-page-for-binary nmon
http://fedoraproject.org/wiki/Packaging/Guidelines#Man_pages
Comment 28 Maxim Burgerhout 2012-07-03 09:02:35 EDT
Is someone still working on this? I am not a sponsor, but I'm willing to take over if no-one else is interested in this RR anymore.
Comment 29 Maxim Burgerhout 2012-07-05 18:50:38 EDT
If someone here can review this properly, I'm willing to maintain this. Updated spec, RPM and SRPM below. I added the manpage from the Debian package. I'll try to add more information to that in later versions.

If approved, I'll maintain for current Fedora's, starting with 16, EPEL5 and EPEL6.

SPEC: http://wzzrd.fedorapeople.org/nmon/nmon.spec
RPM:  http://wzzrd.fedorapeople.org/nmon/nmon-14g-2.fc17.x86_64.rpm
SRPM: http://wzzrd.fedorapeople.org/nmon/nmon-14g-2.fc17.src.rpm
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4221999

As far is the patch is concerned: it's tiny and I'll ask upstream to merge it. It just swaps out the reference to 'ksh' in the main screen for a more generic 'shell'.

If the original requestor still wants to handle this, I'll happily step back.
Comment 30 Dylan Swift 2012-07-12 08:03:11 EDT
Maxim,

I'm happy for anyone else to run with this. I only stopped as I didn't seem to be getting anywhere.  

I also found that there is also a version of nmon in Dag Wiers repositories, so I'm not sure if this is warranted anymore? If it is then perhaps Dag's rpm specs could provide help in getting this packaged.

Cheers

Dylan
Comment 31 Maxim Burgerhout 2012-07-24 08:47:40 EDT
Interesting. Is there a policy concerning packages that are in commonly used third party repositories? Should I preferably leave it alone now that it is in repoforge?
Comment 32 Robin Lee 2012-09-30 03:05:29 EDT
Hi, Maxim.

If you want to take over this package, you should open a new issue and mark this as duplicated. I will review it then.
Comment 33 Palle Ravn 2013-02-24 10:32:50 EST
What is the status of this package? In case the process has stalled I would like to take over, if that's okay.
Comment 34 Terje Røsten 2013-02-24 13:58:01 EST
Palle, please take it, open a new requset and close this as duplicate.
Comment 35 Palle Ravn 2013-02-25 10:35:11 EST
I made a new request at https://bugzilla.redhat.com/show_bug.cgi?id=915337, I can however not close this one?
Comment 36 Terje Røsten 2013-02-25 10:37:37 EST

*** This bug has been marked as a duplicate of bug 915337 ***

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