Bug 469470

I had a successful Koji scratch build. Here is the task ID
http://koji.fedoraproject.org/koji/taskinfo?taskID=914103

I am quite sure that trying to install the binary under the name "mz" will meet reluctance. How about renaming it to mausezahn ?

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

I was speaking about the binary application's name (i.e. /bin/mz <--> /bin/mausezahn), not the package name.

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.

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.

Also see
http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace

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.

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

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

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

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

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

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

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.

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.

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

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.

if you change the package name I'll try to make time and review it. currently I am _very_ busy at work

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.

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.

Well, the newest srpm is the one written in comment 14,
right?
(Personally I would prefer that srpm is also to renamed as "mausezahn")

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 ?

Aargh. The comment 14 hyperlink came out all wrong in my previus note.

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

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

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.

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

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

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.

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.

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

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.

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

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

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

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

Thanks for the review Mamoru, I will fix the copyright before the import.

New Package CVS Request
=======================
Package Name: mausezahn
Short Description: A fast versatile packet generator
Owners: bonii
Branches: F-10 F-11
InitialCC: bonii

CVS done.

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

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

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

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

Closing.

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.

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.