Bug 469470 - Review Request: mausezahn - A fast versatile packet generator
Review Request: mausezahn - A fast versatile packet generator
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-01 00:51 EDT by Vivek Shah
Modified: 2009-08-12 16:56 EDT (History)
5 users (show)

See Also:
Fixed In Version: 0.34.9-1.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-11 12:05:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mtasaka: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Vivek Shah 2008-11-01 00:51:03 EDT
Spec URL: http://bonii.fedorapeople.org/spec/mz.spec
SRPM URL: http://bonii.fedorapeople.org/srpms/mz-0.34.5-1.fc9.src.rpm
Description: 
Mausezahn  is  a  free fast traffic generator written in C which allows you to 
send nearly every possible and impossible packet. Mausezahn can also be used 
for example as didactical  tool  in  network labs  or  for security audits 
including penetration and DoS testing. As traffic generator Mausezahn is for 
example used test  IP  multicast  or VoIP  networks. Speeds close to the 
Ethernet limit are reachable (depending on the HW platform).
Comment 1 Vivek Shah 2008-11-01 01:10:48 EDT
I had a successful Koji scratch build. Here is the task ID
http://koji.fedoraproject.org/koji/taskinfo?taskID=914103
Comment 2 manuel wolfshant 2008-11-01 04:52:19 EDT
I am quite sure that trying to install the binary under the name "mz" will meet reluctance. How about renaming it to mausezahn ?
Comment 3 Vivek Shah 2008-11-01 07:36:43 EDT
As far as Package Naming guidelines are concerned the package name must match the upstream tarball and be consistent with the name in case it is packaged under different distros in case another package with the same name does not(which does not exist as of now even in the Review queues). This software exists in Debian under the name 'mz' so I feel it is reasonable to continue with the package name 'mz'.
Comment 4 manuel wolfshant 2008-11-01 13:18:47 EDT
I was speaking about the binary application's name (i.e. /bin/mz <--> /bin/mausezahn), not the package name.
Comment 5 Vivek Shah 2008-11-01 23:21:10 EDT
But why would I want to split the binary name from mz to mausezahn when it is not causing any conflict with biaries of any other package and not keep the binary name consistent with the package name and the manual page.
Comment 6 manuel wolfshant 2008-11-01 23:33:25 EDT
Because 
a) two letter commands are a scarce resource
b) http://www.google.ro/search?q=mz returns nothing useful on the first page while http://www.google.ro/search?q=mausezahn contains only useful stuff.
Comment 8 Vivek Shah 2008-11-02 08:38:07 EST
So in this case although there are no such pertinent conflicts but one might arise in the future, the only solution that crops up is to work with upstream rather than patching up Makefile/renaming binaries as this might cause distro specific inconsistencies. I will mail upstream right away and see if the binaries and manuals can be renamed.
Comment 9 manuel wolfshant 2008-11-02 16:51:39 EST
Or simply use

  make install INSTALL="%{__install} -p" DESTDIR=$RPM_BUILD_ROOT
  mv $RPM_BUILD_ROOT%{_sbindir}/%{name} $RPM_BUILD_ROOT%{_sbindir}/mausezahn
  mv $RPM_BUILD_ROOT%{_mandir}/man1/%{name} $RPM_BUILD_ROOT%{_mandir}/man1/mausezahn

  %files
  %defattr(-,root,root,-)
  %{_sbindir}/mausezahn
  %{_mandir}/man1/mausezahn*


and be done with it
Comment 10 Vivek Shah 2008-11-07 11:01:54 EST
I have talked with upstream and am going to add the reply from the mz maintainer

-------------- Reply of Mausezahn maintainer (Herbert Haas) -------------------

I decided to stick on "mz" because not only other distros have already
included it that way, many users got already used to that abbreviation, and
finally "mz" gives the idea of a quick (small, fast, efficient) tool.

I don't expect any collisions with other tools that name. There are 676
possibilities of 2-letter names and most people tend to use longer names for
marketing purposes. Also nobody searches for "mz" in Google, I think, rather
one would look for "Mausezahn"...

I asked Debian Maintainers for their opinion and they also had no problem
with "mz".

Thus, in order not to confuse the already established audience I think it is
better to stick on "mz".

Hope you can deal with that ;-)

---------------------------- End of reply -------------------------------------

I am not completely sure about renaming the binary and the manpage because:
He claims it goes as mz in a lot of distros and the binary goes into /usr/sbin/ and I would not want to cause distro confusion for a common software.

Please suggest before I upload an updated SRPM and SPEC
Comment 11 Patrice Dumas 2008-11-10 11:28:19 EST
(In reply to comment #10)

> I don't expect any collisions with other tools that name. There are 676
> possibilities of 2-letter names

This looks like a joke to me. 676 is so small compared with the number 
of free software packages and command-line applications.

> I asked Debian Maintainers for their opinion and they also had no problem
> with "mz".

That's a bit strange, since in general debian maintainers tend to be
aware of those issues.

> Please suggest before I upload an updated SRPM and SPEC

I don't have much to suggest. Tibbs is working on a guideline that should
prevent such use of names, but there is no guarantee that it will be agreed
by the FPC.
Comment 12 Patrice Dumas 2008-11-10 11:35:14 EST
(In reply to comment #10)

> Please suggest before I upload an updated SRPM and SPEC

Something I forgot to say is that currently using mz is not against the 
guidelines, so you could find a reviewer wanting to accept the 
package as-is. It won't be me, but there are plenty of fedora packagers
and some don't care a bit about generic names.
Comment 13 Vivek Shah 2008-11-10 23:34:52 EST
Well I too agree with the issues in the short name for mz and if something which must have been caught in Debian did not get caught there doesn't mean we will do the same as well. I will be uploading the updated SPEC and SRPM with the man page and binary renamed to mausezahn
Comment 14 Vivek Shah 2008-11-23 05:57:08 EST
I have modified the package binary and manpage as per your suggestions.
Please assign it to yourself and review it.

Spec URL: http://bonii.fedorapeople.org/spec/mz.spec
SRPM URL: http://bonii.fedorapeople.org/srpms/mz-0.34.5-2.fc9.src.rpm
Comment 15 Patrice Dumas 2008-11-23 08:44:39 EST
I don't know if you are speaking about me, but to me the package name is
still too short, si I wouldn't accept th epackage. Besides I have only jumped 
on the review because I try to avoid inflation of short and generic names
in fedora, not because I am interested in doing the review.
Comment 16 Vivek Shah 2008-11-23 23:40:00 EST
Now this becomes a bit misleading and confusing, if you see my comments above I had raised the same question about renaming the binaries and manpage without renaming the package name and was suggested to rename the binaries and manpage and get done with it.
Comment 17 Patrice Dumas 2008-11-24 04:00:15 EST
You cannot change the package name if upstream does not, so what you propose is the best you can do. I don't think that this package should enter fedora until the
upstream maintainer changes the name, though. Especially with his reasoning showing that he cares only about 625 packages...

Manuel made comments about the changes in the binary names, but it was not my comments...
Comment 18 Vivek Shah 2008-11-27 02:41:25 EST
I am currently considering of changing the package name to mausezahn and all associated files like manpages. Since upstream is not keen to change the package name which I do not see as happening in near future, I think the best foot forward would be to rename the package on our side and push it into Fedora.
Comment 19 manuel wolfshant 2008-12-12 14:52:28 EST
if you change the package name I'll try to make time and review it. currently I am _very_ busy at work
Comment 20 Jason Tibbitts 2009-03-12 01:36:11 EDT
Did anything ever happen here?  It's been three months now since wolfy's comment.  I guess I'll go ahead and close this soon if there's no further progress.
Comment 21 Vivek Shah 2009-03-16 06:41:10 EDT
Hi Jason,
         Thanks for pinging me. I am currently very busy at work. I will be packaging and filing under a different name for this package as per suggestions.
Comment 22 Mamoru TASAKA 2009-07-06 12:13:16 EDT
Well, the newest srpm is the one written in comment 14,
right?
(Personally I would prefer that srpm is also to renamed as "mausezahn")
Comment 23 Vivek Shah 2009-07-07 11:12:05 EDT
Hi Mamoru,
          Yes the newest srpm is the one mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=469470#c14.

I have a few doubts here:
1. Should I only rename the package name to mausezahn ?
2. Should the binaries and manpages be renamed to mausezahn ?
3. Should the contents of man pages which refer to mz be renamed to mausezahn ?
4. The docs contain a pdf manual as well which contains references to mz. In that case that needs to be removed as well ?
Comment 24 Vivek Shah 2009-07-07 11:12:56 EDT
Aargh. The comment 14 hyperlink came out all wrong in my previus note.
Comment 25 Mamoru TASAKA 2009-07-07 12:18:21 EDT
To comment 23:

In my opinion:
1.2: necessary
3. preferable (I would do so), however instead you can write an additional
   note (like "README.Fedora") to notify Fedora mausezahn users that the
   binaries/srpm are renamed to "mausezahn" even if it is called as "mz" 
   in the included documents.
4. see above
Comment 26 Vivek Shah 2009-07-18 04:21:38 EDT
Updated the package as per comment 23

Please find it here:
Spec URL: http://bonii.fedorapeople.org/spec/mausezahn.spec
SRPM URL: http://bonii.fedorapeople.org/srpms/mausezahn-0.34.6-1.fc9.src.rpm
Comment 27 manuel wolfshant 2009-07-18 07:15:03 EDT
Small ( mostly cosmetic - there are several double spaces and a missing long infinitive ) suggested modification for the description:

Mausezahn is a free fast traffic generator written in C which allows you to 
send nearly every possible and impossible packet. Mausezahn can also be used 
for example as didactical tool in  network labs or for security audits 
including penetration and DoS testing. As traffic generator Mausezahn is for 
example used to test IP multicast or VoIP networks. Speeds close to the 
Ethernet limit are reachable (depending on the HW platform).



Successful scratch builds:
- F-10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1483696 
- rawhide/i386: http://koji.fedoraproject.org/koji/taskinfo?taskID=1483679


I suggest to consolidate the content of /usr/share/doc/mausezahn and /usr/share/doc/mausezahn-0.34.6 in a single directory. It's a bit unusual to have two different doc dirs.
Comment 28 Vivek Shah 2009-07-18 08:24:37 EDT
Thanks for the review. Updated the spec and srpm as per comment 27

Please find it here:
Spec URL: http://bonii.fedorapeople.org/spec/mausezahn.spec
SRPM URL: http://bonii.fedorapeople.org/srpms/mausezahn-0.34.6-2.fc9.src.rpm
Comment 29 R P Herrold 2009-07-18 10:48:01 EDT
On this namespace conflict issue, I was think that you had packaged [re-] mezzanine, Michael Jennings [also the Enlightenment WM environment's author] Linux based RPM package management and building system, developed as far back as in the 'LinuxCare' days.

Certainly there is a known Linux space namespace ambiguity.

-- Russ herrold
Comment 30 Mamoru TASAKA 2009-07-22 14:41:51 EDT
Some initial comments:

* Dependency
  - "python-matplotlib" seems to be needed for view_rtp_avg.py, however
    this is installed as a document
    ( i.e. if you install the binary rpm by $ rpm -ivh --excludedocs ,
      this python script is not instaled )
    We usually avoid to add dependency for document files.
    Would you explain why you want to add this dependency?

* make build log more verbose
  - build.log shows
----------------------------------------------------------------
    52  + make -j4
    53  Scanning dependencies of target mz
    54  [ 11%] [ 11%] [ 22%] [ 22%] Building C object src/CMakeFiles/mz.dir/mz.o
    55  Building C object src/CMakeFiles/mz.dir/layer1.o
    56  Building C object src/CMakeFiles/mz.dir/layer3.o
    57  Building C object src/CMakeFiles/mz.dir/layer2.o
----------------------------------------------------------------
    This output is not useful. For example we cannot check if
    Fedora specific compilation flags are correctly honored
    ( And actually currently this is not correctly honored:
      see below).
    Please add "VERBOSE=1" as a option to make. ref:
    https://fedoraproject.org/wiki/Packaging/cmake#Specfile_Usage

* Fedora specific compilation flags
  https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags
  - Actually "make VERBOSE=1" shows Fedora specific compilation
    flags are not correctly honored:
---------------------------------------------------------------
[ 11%] [ 11%] [ 16%] [ 22%] Building C object src/CMakeFiles/mz.dir/layer2.o
cd /builddir/build/BUILD/mz-0.34.6/src && /usr/bin/gcc   -I/builddir/build/BUILD/mz-0.34.6/. -I/builddir/build/BUILD/mz-0.34.6/.. -I/builddir/build/BUILD/mz-0.34.6   -o CMakeFiles/mz.dir/layer2.o   -c /builddir/build/BUILD/mz-0.34.6/src/layer2.c
Building C object src/CMakeFiles/mz.dir/mz.o
Building C object src/CMakeFiles/mz.dir/layer1.o
Building C object src/CMakeFiles/mz.dir/layer3.o
cd /builddir/build/BUILD/mz-0.34.6/src && /usr/bin/gcc   -I/builddir/build/BUILD/mz-0.34.6/. -I/builddir/build/BUILD/mz-0.34.6/.. -I/builddir/build/BUILD/mz-0.34.6   -o CMakeFiles/mz.dir/layer1.o   -c /builddir/build/BUILD/mz-0.34.6/src/layer1.c
---------------------------------------------------------------
    As the result the debuginfo rpm is incomplete.

* %files
  - Usually "INSTALL" file is for people who want to build and install
    a package by themselves and not needed for people using rpm.
  - Please remove unneeded %doc line.
Comment 31 Vivek Shah 2009-07-25 11:30:54 EDT
Hi Mamoru,
          Thanks for the review.

* Dependency:
I wanted to keep python-matplotlib in the "Requires" field since the view_rtp_avg.py needs it. Even though it may be installed as a doc, I thought a user might not want to hunt for dependency to make it work ie why I put in the "Requires" field and the doc files are not substantial as well to split into a -doc package.

On a related question, if I install the package with --excludedocs does it prevent files put under %doc from installing or does it not include contents put under %files under %{_defaultdocdir}

Will be fixing the other issues as you outlined.
Comment 32 Mamoru TASAKA 2009-07-25 13:59:34 EDT
(In reply to comment #31)

> * Dependency:
> I wanted to keep python-matplotlib in the "Requires" field since the
> view_rtp_avg.py needs it. Even though it may be installed as a doc, I thought a
> user might not want to hunt for dependency to make it work ie why I put in the
> "Requires" field and the doc files are not substantial as well to split into a
> -doc package.

- Okay, then I will leave this dependency to what you (as the
  maintainer) think.

> On a related question, if I install the package with --excludedocs does it
> prevent files put under %doc from installing or does it not include contents
> put under %files under %{_defaultdocdir}

- $ rpm --excludedocs will not install the files marked as %doc,
  and all files under %_defaultdocdir are automatically marked
  as %doc .
Comment 33 Vivek Shah 2009-07-26 12:03:01 EDT
Hi Mamoru,
          With Fedora specific flags turned on, I can see there are buffer overflow issues in the program. I have notified upstream about it. Will be patching them up and then update the srpm in a couple of days. It needs to fixed I believe before it goes in the repos more so since the program needs root privileges to run.
Comment 34 Vivek Shah 2009-08-02 02:49:27 EDT
Updated the spec and srpm

Please find it here:
Spec URL: http://bonii.fedorapeople.org/spec/mausezahn.spec
SRPM URL: http://bonii.fedorapeople.org/srpms/mausezahn-0.34.8-1.fc9.src.rpm
Comment 35 Mamoru TASAKA 2009-08-03 11:46:43 EDT
Well, 

(In reply to comment #34)
> Spec URL: http://bonii.fedorapeople.org/spec/mausezahn.spec
> SRPM URL: http://bonii.fedorapeople.org/srpms/mausezahn-0.34.8-1.fc9.src.rpm  

This does not build (at least) on x86_64:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1576215

From diff:
--------------------------------------------------------------
diff -uNr mausezahn-0.34.6-2.fc9.src/mz-0.34.6/CMakeLists.txt mausezahn-0.34.8-1.fc9.src/mz-0.34.8/CMakeLists.txt
--- mausezahn-0.34.6-2.fc9.src/mz-0.34.6/CMakeLists.txt 2008-09-05 17:16:54.000000000 +0900
+++ mausezahn-0.34.8-1.fc9.src/mz-0.34.8/CMakeLists.txt 2009-07-30 01:33:28.000000000 +0900
@@ -5,6 +5,8 @@
        cmake_policy(SET CMP0003 NEW)
 endif(COMMAND cmake_policy)
 
+SET(CMAKE_C_FLAGS "-Wall -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -
fasynchronous-unwind-tables")
+
 ADD_CUSTOM_TARGET(uninstall
        COMMAND ${CMAKE_COMMAND} -E echo Use 'xargs rm < install_manifest.txt' to uninstall this program
        )
@@ -13,3 +15,6 @@
 
 add_subdirectory (src)
 add_subdirectory (doc)
+
+
+
---------------------------------------------------------------------

Well, this CMAKE_C_FLAGS is wrong on x86_64, and on rawhide even
on "i686" (on rawhide build target is for i686, x86_64, ppc, ppc64).
Comment 36 Vivek Shah 2009-08-04 13:20:53 EDT
Updated the spec and srpm

Please find it here:
Spec URL: http://bonii.fedorapeople.org/spec/mausezahn.spec
SRPM URL: http://bonii.fedorapeople.org/srpms/mausezahn-0.34.8-2.fc9.src.rpm  

Had a successful scratch build
http://koji.fedoraproject.org/koji/taskinfo?taskID=1580758
Comment 37 Mamoru TASAKA 2009-08-05 12:23:09 EDT
Well,

----------------------------------------------------
[root@localhost ~]# mausezahn 

Mausezahn 0.34.7 - (C) 2007-2009 by Herbert Haas - http://www.perihel.at/sec/mz/
|
----------------------------------------------------
Maybe it is better to fix src/mz.h (this version is 0.34.8), however
I will leave this to you.

----------------------------------------------------
  This package (mausezahn) is APPROVED by mtasaka
----------------------------------------------------
Comment 38 Vivek Shah 2009-08-05 14:43:14 EDT
Thanks for the review Mamoru, I will fix the copyright before the import.
Comment 39 Vivek Shah 2009-08-05 14:47:47 EDT
New Package CVS Request
=======================
Package Name: mausezahn
Short Description: A fast versatile packet generator
Owners: bonii
Branches: F-10 F-11
InitialCC: bonii
Comment 40 Jason Tibbitts 2009-08-05 18:43:38 EDT
CVS done.
Comment 41 Fedora Update System 2009-08-08 12:36:34 EDT
mausezahn-0.34.9-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/mausezahn-0.34.9-1.fc10
Comment 42 Fedora Update System 2009-08-08 12:36:42 EDT
mausezahn-0.34.9-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mausezahn-0.34.9-1.fc11
Comment 43 Fedora Update System 2009-08-10 17:39:06 EDT
mausezahn-0.34.9-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mausezahn'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8412
Comment 44 Fedora Update System 2009-08-10 17:50:02 EDT
mausezahn-0.34.9-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mausezahn'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8443
Comment 45 Mamoru TASAKA 2009-08-11 12:05:43 EDT
Closing.
Comment 46 Fedora Update System 2009-08-12 16:52:01 EDT
mausezahn-0.34.9-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 47 Fedora Update System 2009-08-12 16:56:36 EDT
mausezahn-0.34.9-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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