- 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

- 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

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

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"

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.

(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?

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

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

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

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

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

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

Well, then what is the status of this bug?
Where is the latest srpm?

Hi Mamoru,

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

Dylan

What is the status of this bug?

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

(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

Thanks Ankur,

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

I'll get to work on that.

Dylan

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.

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

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.

(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?

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

Ping Dylan?

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

Seems like a nice app, created an update spec:

spec: http://terjeros.fedorapeople.org/nmon/nmon.spec
srpm: http://terjeros.fedorapeople.org/nmon/nmon-14g-1.fc16.src.rpm
koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=3893484

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

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.

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.

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

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?

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.

What is the status of this package? In case the process has stalled I would like to take over, if that's okay.

Palle, please take it, open a new requset and close this as duplicate.

I made a new request at https://bugzilla.redhat.com/show_bug.cgi?id=915337, I can however not close this one?

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