Spec URL: http://rakesh.gnulinuxcentar.org/ntop.spec SRPM URL: http://rakesh.gnulinuxcentar.org/ntop-3.3-3.fc8.src.rpm Description: ntop is a network traffic probe that shows the network usage, similar to what the popular top Unix command does. ntop is based on libpcap and it has been written in a portable way in order to virtually run on every Unix platform and on Win32 as well. ntop users can use a a web browser (e.g. netscape) to navigate through ntop (that acts as a web server) traffic information and get a dump of the network status. In the latter case, ntop can be seen as a simple RMON-like agent with an embedded web interface. The use of: * a web interface * limited configuration and administration via the web interface * reduced CPU and memory usage (they vary according to network size and traffic) make ntop easy to use and suitable for monitoring various kind of networks. This is my second package and I am still seeking a sponsor.
I have reopened this https://bugzilla.redhat.com/show_bug.cgi?id=219025 , as previous contributor Bernard Johnson had no time continue his good work. The issue mentioned in comment #117 in above request has been resolved. The problem was created by https://svn.ntop.org/trac/changeset/3112 which was an attempt to fix it long back. There is also a related closed bug here: https://bugzilla.redhat.com/show_bug.cgi?id=389631 And as mentioned there: ntop defined free to ntop_safefree which required l-value as argument.
*** Bug 219025 has been marked as a duplicate of this bug. ***
Just to recap our recent discussion on IRC: You can drop the %if 0%{?fedora} >= 7 conditional stuff, since we no longer support any release where it would trigger. The specfile should consistently use either the macro forms like "%{__mv}" or the regular "mv"; I personally prefer the non-macro forms because it's less typing, but it's up to you. I went ahead and built the package; rpmlint has many complaints. Ignoring non-standard-{gid,dir-perm,executable-perm} and such, I see: E: binary-or-shlib-defines-rpath /usr/sbin/ntop ['/usr/lib64'] E: binary-or-shlib-defines-rpath /usr/lib64/libntopreport-3.3.so ['/usr/lib64'] These need to be fixed. The information at http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath should help. W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so static_ntop W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so welcome W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so setAdminPassword W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so usage W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so welcome W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so showUsers W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so addURL W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so doAddURL W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so doChangeFilter W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so addUser W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so doAddUser W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so deleteUser W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so showURLs W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so deleteURL W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so addDefaultAdminUser W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so changeFilter W: undefined-non-weak-symbol /usr/lib64/libntopreport-3.3.so handleNtopConfig W: undefined-non-weak-symbol /usr/lib64/libntop-3.3.so static_ntop W: undefined-non-weak-symbol /usr/lib64/libntop-3.3.so welcome W: undefined-non-weak-symbol /usr/lib64/libntop-3.3.so setAdminPassword W: undefined-non-weak-symbol /usr/lib64/libntop-3.3.so usage W: undefined-non-weak-symbol /usr/lib64/libntop-3.3.so welcome It seems that libntopreport isn't linked against libntop, and libntop isn't linked against some other library. Which seems odd, but isn't necessarily problem as long as all of the executables that use them are linked properly or provide the proper symbols. W: unused-direct-shlib-dependency /usr/lib64/libntopreport-3.3.so /lib64/libpcre.so.0 W: unused-direct-shlib-dependency /usr/lib64/libntopreport-3.3.so /usr/lib64/mysql/libmysqlclient_r.so.15 W: unused-direct-shlib-dependency /usr/lib64/libntopreport-3.3.so /lib64/libnsl.so.1 W: unused-direct-shlib-dependency /usr/lib64/libntopreport-3.3.so /usr/lib64/libsensors.so.4 W: unused-direct-shlib-dependency /usr/lib64/libntopreport-3.3.so /usr/lib64/libnetsnmp.so.15 W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /usr/lib64/librrd_th.so.2 W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /lib64/libcrypt.so.1 W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /lib64/libnsl.so.1 W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /lib64/libssl.so.7 W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /usr/lib64/libsensors.so.4 These indicate that the ntop libs are linked against various other libraries but don't actually call them. It's not strictly necessary to fix these as they're only inefficient, but there's some info at http://fedoraproject.org/wiki/PackageMaintainers/CommonRpmlintIssues#unused-direct-shlib-dependency if you're interested.
> E: binary-or-shlib-defines-rpath /usr/sbin/ntop ['/usr/lib64'] > E: binary-or-shlib-defines-rpath /usr/lib64/libntopreport-3.3.so ['/usr/lib64'] >These need to be fixed. The information at I was not able to reproduce on my m/c. Will try to check on 64 bit m/c > W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /lib64/ libcrypt.so.1 > W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /lib64/ libnsl.so.1 > W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /lib64/ libssl.so.7 > W: unused-direct-shlib-dependency /usr/lib64/libntop-3.3.so /usr/lib64/ libsensors.so.4 >These indicate that the ntop libs are linked against various other libraries Fixed. >You can drop the %if 0%{?fedora} >= 7 conditional stuff Fixed. Spec URL: http://rakesh.gnulinuxcentar.org/ntop.spec SRPM URL: http://rakesh.gnulinuxcentar.org/ntop-3.3-3.fc8.src.rpm Will update soon on rpath. -- Rakesh Pandit
> Will update soon on rpath. Fixed Spec URL: http://rakesh.gnulinuxcentar.org/ntop.spec SRPM URL: http://rakesh.gnulinuxcentar.org/ntop-3.3-3.fc8.src.rpm There is one more warning which comes: ntop.i386: W: dangerous-command-in-%postun userdel Actually, this one cleans ntop username which was created while installing ntop. It look to me Okay. -- Regards Rakesh Pandit
(In reply to comment #5) > There is one more warning which comes: > ntop.i386: W: dangerous-command-in-%postun userdel > > Actually, this one cleans ntop username which was created while installing > ntop. It look to me Okay. Actually it's not OK. We don't remove users/groups created in packages. See http://fedoraproject.org/wiki/Packaging/UsersAndGroups
>Actually it's not OK. We don't remove users/groups cre ted in packages. See > ttp://fedoraproject.org/wiki/Packaging/UsersAndGroups Thanks for pointing out. Fixed Updated: Spec URL: http://rakesh.gnulinuxcentar.org/ntop.spec SRPM URL: http://rakesh.gnulinuxcentar.org/ntop-3.3-3.fc8.src.rpm
Corrected release number: SRPM: http://rakesh.fedorapeople.org/srpm/ntop-3.3-4.fc8.src.rpm SPEC: http://rakesh.fedorapeople.org/spec/ntop.spec
Removing needsponsor, I have sponsored Rakesh.
Created attachment 312813 [details] A modified patch A modified ntop-am.patch that applies even with --fuzz=0.
Doh, I haven't sent the comment describing the attachment, sorry. Here's the thing - the ntop-am.patch did not apply due to --fuzz=0 being used in rawhide and thus ntop did not build cleanly. I've modified the patch to make things work again.
Thanks for your work ;-) I will apply it and rebuild soon.
Update !!! Spec URL: http://people.redhat.com/pvrabec/rpms/ntop.spec SRPM URL: http://people.redhat.com/pvrabec/rpms/ntop-3.3.6-1.fc9.src.rpm
Peter thanks!! It went out of my mind for long now.
I will update package today evening IST
Hi Rakesh, I think there is no need to package update if package proposed by me pass the review. I hope this tool will be available in F10 so we need to finish the review as soon as possible. Is it OK?
No it is not okay. You assigned request to yourself first, so you where supposed to review request. I thought you wanted to review. Review was submitted by me. So, if you really want to help , you are welcome. Best way would have been to submit a patch. But as you have built then it is okay. I would update with proper changelog mentioning your contribution and Jakub's contribution. But, if I am right about process, until and unless I say that I am not interested in this package further or i don't respond quickly as and when needed, you are not supposed to duplicate the package and say "this is my package and review it" I am and will be happy to own and maintain this package. In case you want to co-maintain you are welcome -- there is a procedure for everything.
(In reply to comment #17) > No it is not okay. > > But, if I am right about process, until and unless I say that I am not > interested in this package further or i don't respond quickly as and when > needed, you are not supposed to duplicate the package and say "this is my > package and review it" > > I am and will be happy to own and maintain this package. In case you want to > co-maintain you are welcome -- there is a procedure for everything. You are right. However, if somebody comes and informally review Peter srpm and approve it it is still an interesting data point, though, in te end it is your package that will have to be formally reviewed and approved. It would even be acceptable if you said, instead of 'not ok' something along, 'reviewer, you can review Peter package as if I had prposed it myself'. But you seem to prefer that you resubmit somethin for the review and it is your choice, and since you are th esubmitter it has to be accepted by the reviewer (but as I said just above anybody can still comment on Peter package). @Peter: a review should never ever be done in a hurry. If the package does'nt make F10 launch, it will be in the updates. In my opinion this is especially true for this review since it was first entered 2 years ago...
I looked at the package, everything seems ok, except that -devel package is not build (which was explained by pvrabec to be ok) and there is small error in the init script. There are followin tests in main run of initscript: [ -x $ntop ] || exit 1 [ -r "/etc/ntop.conf" ] || exit 1 [ -r "/var/lib/ntop/ntop_pw.db" ] || exit 1 that should be moved in the start function instead. Also error codes can be more precise, as 2nd and 3rd test failure indicates that the service is not configured. So, correct version is [ -x $ntop ] || exit 1 [ -r "/etc/ntop.conf" ] || exit 6 [ -r "/var/lib/ntop/ntop_pw.db" ] || exit 6 placed at the begining of start() function. Except for this small problem, the package is ready for fedora.
hey I'm sorry I didn't want to make a review, so reassigning to me was my fault. I wanted to push this further. What do you suggest to do now? I can provide new package ASAP. Then we(you or me) can import into cvs. I'll appreciate if I can be maintainer or co-maintainer.
@patrice Thanks for clarification. I am happy that peter is interested. Actually I was confused, because peter assigned request to himself first and also proposed the package. @peter I am also sorry for creating confusion. I would be very happy if you would rebuild clearing the above thing mentioned by Michal. Lets work on it collectively. Please, you may like to be co-maintainer
here we go Spec URL: http://people.redhat.com/pvrabec/rpms/ntop.spec SRPM URL: http://people.redhat.com/pvrabec/rpms/ntop-3.3.6-2.fc9.src.rpm
Just updated the changelog mentioning Jakub H's patch update. SRPM: http://rakesh.fedorapeople.org/srpm/ntop-3.3.6-3.fc9.src.rpm SPEC: http://rakesh.fedorapeople.org/spec/ntop.spec
some more init script tuning Spec URL: http://people.redhat.com/pvrabec/rpms/ntop.spec SRPM URL: http://people.redhat.com/pvrabec/rpms/ntop-3.3.6-4.fc9.src.rpm
so "much" tuning that I made small but important typo.(time to go home :) ) Spec URL: http://people.redhat.com/pvrabec/rpms/ntop.spec SRPM URL: http://people.redhat.com/pvrabec/rpms/ntop-3.3.6-5.fc9.src.rpm
New Package CVS Request ======================= Package Name: ntop Short Description: A network traffic probe similar to the UNIX top command Owners: rakesh, pvrabec Branches: InitialCC: Cvsextras Commits: yes
Branches where missing: New Package CVS Request ======================= Package Name: ntop Short Description: A network traffic probe similar to the UNIX top command Owners: rakesh pvrabec Branches: F-8 F-9 InitialCC:rakesh pvrabec Cvsextras Commits: yes
Michal: I can't seem to find you in the packager group. Have you been sponsored? Only folks in the packager group can formally approve package reviews. Is your account under another name/address in that group?
*** Bug 458770 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > Michal: I can't seem to find you in the packager group. > Have you been sponsored? Only folks in the packager group can formally approve > package reviews. > > Is your account under another name/address in that group? Hi, I've just created fedoraprojec account (my fault, being 2 years with redhat without this account is blame) and have been added to packager group. Thanks for your notice.
cvs done. Do consider EPEL branches here if this package builds/works there.
@peter I have started doing initial import now. May you add yourself to page: https://admin.fedoraproject.org/pkgdb/packages/name/ntop
@peter You are automatically added already:-) @Kevin Yes, will consider adding to EPEL branches.
ntop-3.3.6-5.fc8 has been submitted as an update for Fedora 8
ntop-3.3.6-5.fc9 has been submitted as an update for Fedora 9
Package Change Request ====================== Package Name: ntop New Branches: EL-5
cvs done.
OK, this is now built in the EL-5 branch.
https://admin.fedoraproject.org/pkgdb/packages/name/ntop @Richard Thanks Richard May you add yourself as owner of that branch. I will release ownership for EL-5.
ntop-3.3.6-5.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
ntop-3.3.6-5.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.