Bug 528108 - Review Request: Vuurmuur - Firewall manager built on top of iptables
Summary: Review Request: Vuurmuur - Firewall manager built on top of iptables
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-09 06:45 UTC by Stjepan Gros
Modified: 2009-11-25 15:32 UTC (History)
5 users (show)

Fixed In Version: 0.7-7.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-23 19:09:07 UTC
mtasaka: fedora-review+
dennis: fedora-cvs+


Attachments (Terms of Use)

Description Stjepan Gros 2009-10-09 06:45:59 UTC
Spec URL: http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur.spec
SRPM URL: http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur-0.7-0.fc11.src.rpm
Description:

Vuurmuur is a powerful middle-end/front-end for netfilter/iptables aimed
at system-administrators who need a decent firewall, but don't have netfilter
specific knowledge.

The program is basicly split into three pieces. One piece (the middle-end)
converts humanly-readable rules, hosts, groups, networks, zones, interfaces
and services into a iptables ruleset (or optional into a bash-script). The
second part is a little daemon that converts the netfiler logs to easy
readable logs, that reflect all the predefined objects described above. The
third part is a Ncurses-based Gui (the front-end) in which one can manage
the firewall. Most important here is the real-time feedback. Logs can be
viewed in real-time, using colours for easy interpretation. Also, the current
connections can be viewed in real-time. Filtering possibilities make it easy
to monitor specific hosts or services.

Comment 1 Dave Ludlow 2009-10-12 15:17:58 UTC
### I'm looking for a sponsor.  Submitted as a comment only as suggested by http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Reviewing_Packages.

*************************
*** Possible Problems ***
*************************

MUST: rpmlint must be run on every package. The output should be posted in the review.
 $ rpmlint Vuurmuur-0.7-0.fc11.src.rpm Vuurmuur.spec
 1 packages and 1 specfiles checked; 0 errors, 0 warnings.

 $ rpmlint *.rpm 
 Vuurmuur.x86_64: W: incoherent-version-in-changelog 0.7-1 ['0.7-0.fc11', '0.7-0']
 Vuurmuur-daemon.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/vuurmuur
 Vuurmuur-daemon.x86_64: W: service-default-enabled /etc/rc.d/init.d/vuurmuur
 Vuurmuur-daemon.x86_64: E: no-status-entry /etc/rc.d/init.d/vuurmuur
 Vuurmuur-daemon.x86_64: E: subsys-not-used /etc/rc.d/init.d/vuurmuur
 Vuurmuur-daemon.x86_64: W: incoherent-init-script-name vuurmuur ('vuurmuur-daemon', 'vuurmuur-daemond')
 Vuurmuur-devel.x86_64: W: no-dependency-on Vuurmuur/Vuurmuur-libs/libVuurmuur
 Vuurmuur-devel.x86_64: W: no-documentation
 5 packages and 0 specfiles checked; 3 errors, 5 warnings.

MUST: The package must meet the Packaging Guidelines.
 http://fedoraproject.org/wiki/Packaging/Guidelines#Tags
  The Vendor tag should not be used. It is set automatically by the build system.
  Consider replacing 0.7 in the Source0 tag to %{version}.
 http://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment

MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}
 It does not

MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.
 An automake reference is missing, possibly others.  See SHOULD: run in mock

SHOULD: The reviewer should test that the package builds in mock.
 It does not.  /var/tmp/rpm-tmp.ZPXJhA: line 43: aclocal: command not found

SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
 A quick test seems OK, other than the TUI seems to have "Yes" and "No" swapped in the exit confirmation dialog.  Looks like an upstream issue.
 
*************************
*** Items not checked ***
*************************

MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch.
 Unknown, other than x86_64.

**************************
*** Items that look OK ***
**************************

MUST: The package must be named according to the Package Naming Guidelines.
 It is.

MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption.
 It does.

MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines.
 GPLv2

MUST: The License field in the package spec file must match the actual license.
 GPLv2

MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
 It does, and it is.

MUST: The spec file must be written in American English.
 It is.

MUST: The spec file for the package MUST be legible.
 It is.

MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task.
 md5sum=bad91aafcbea5e3a434440f88d722778 for both packaged and upstream sources.

MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture.
 Built on my x86_64 without issue.

MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
 It does.

MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
 It does.

MUST: Packages must NOT bundle copies of system libraries.
 It doesn't.

MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker.
 It's not.

MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.
 No directories are created by the spec file outside of the build root.

MUST: A Fedora package must not list a file more than once in the spec file's %files listings.
 It doesn't

MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.
 They aren't set explicitly by the .spec file, but the default inherited perms should do.

MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
 It does.

MUST: Each package must consistently use macros.
 Other than the 0.7 in the Source0 line, it does

MUST: The package must contain code, or permissable content.
 It does

MUST: Large documentation files must go in a -doc subpackage.
 The docs aren't large.

MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.
 The skel and zones info appears to be required configuration, not documentation.
 
MUST: Header files must be in a -devel package.
 They are

MUST: Static libraries must be in a -static package.
 None exist

MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).
 No .pc files

MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
 They do

MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.
 Packages contain no such files.

MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section.
 Not a GUI

MUST: Packages must not own files or directories already owned by other packages.
 OK

MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
 It does

MUST: All filenames in rpm packages must be valid UTF-8.
 They are

SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
 Included.

SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
 No translations appear to be available. (vuurmuur_conf-0.7/po/* scanned without success)

SHOULD: The package should compile and build into binary rpms on all supported architectures.
 Unable to test, but it doesn't appear to be arch dependent.

SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
 Sane.

SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.
 These are caught by library dependencies automagically.

SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg.
 Unused.

SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
 It doesn't.

### I'm looking for a sponsor.  Submitted as a comment only as suggested by http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Reviewing_Packages.

Comment 2 Mamoru TASAKA 2009-11-04 18:05:55 UTC
Some random remarks from one of the sponsor members:

A. Summary, description, etc
* EVR (Epoch-Version-Release)
  - For formally released (i.e. non-snapshot) package, the release
    number must begin with 1%{?dist}, and then be incremented
    every time you modify your spec file (and should be reset
    to 1%{?dist} then version is upgrade):
    https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Package_Release

* Vendor
  - "Vendor" item should be removed on Fedora. Fedora buildsystem (koji)
    automatically sets this value.

* License
  - The license tag for this package should be "GPLv2+". ref:
    https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#.22or_later_version.22_licenses

* BR (BuildRequires)
  - This package does not build.
    http://koji.fedoraproject.org/koji/taskinfo?taskID=1787887

    Please try to rebuild your srpm with mock:
    https://fedoraproject.org/wiki/Extras/MockTricks
    to check if all needed BuildRequires are included.
    ( Note: perhaps "BR: libtool automake ncurses-devel" are also needed
            for this package )

* Dependency between subpackages
  - All subpacakges other than "Vuurnuur" binary rpm should have
    "Requires: %{name} = %{version}-%{release}":
    https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package

B. %prep, %build
* Working directory
  - At the beginning of %build, %install, the working directory is
    %{_builddir}/%{name}-%{version} (by default, unless you explicitly change
    this value at %setup).
    So I suggest to write something like:
--------------------------------------------------------------
%build
cd libvuurmuur-%{version}
LIBVUDIR=$(pwd)

%configure --with-plugindir=%{_libdir}/vuurmuur/plugins
sed ...
....
make %{?_smp_mflags}

cd ../vuurmuur-%{version}
%configure --with-libvuurmuur-includes=${LIBVUDIR}/src ....
.....
---------------------------------------------------------------
    Also I suggest not to repeat somewhat long 
    "%{_builddir}/%{name}-%{version}/libvuurmuur-%{version}" string and
    use some variable.

* Parallel make
  - Support parallel make unless impossible:
    https://fedoraproject.org/wiki/Packaging/Guidelines#Parallel_make
    If parallel make cannot be supported, please write some comments
    on the spec file.

C %install
* About the following lines
---------------------------------------------------------------
cd %{_builddir}/%{name}-%{version}/vuurmuur-%{version}
make install DESTDIR=$RPM_BUILD_ROOT
for i in `find %{_builddir}/%{name}-%{version}/vuurmuur-%{version}/skel -name .keep`
do
	rm -rf $i
done
---------------------------------------------------------------
  - Would you explain why .keep files under %_builddir (not $RPM_BUILD_ROOT) 
    have to be removed after the installation is already done by the above line?

* %{_initddir}
  - Use %{_initddir} instead of %{_sysconfdir}/rc.d/init.d:
    https://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscripts_on_the_filesystem

D. Scriptlets
* SysVinit scrptlets related dependency
  - Add proper Requires(post) or to to -daemon subpackage:
    https://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscripts_in_spec_file_scriptlets

E. %files
* plugin
  - From libvuurmuur-0.7/src/backendapi.c:
---------------------------------------------------------------
   137          if(snprintf(plugin_location, sizeof(plugin_location), "%s/plugins/lib%s.so", conf.plugdir, plugin_name) >= (int)sizeof(plugin_location))
   138          {
   143              return(-1);
   144          }
   146          plugin->handle = open_plugin(debuglvl, plugin_location);
   147          if(!plugin->handle)
   148          {
   151              return(-1);
   152          }
---------------------------------------------------------------
    Like this, usually plugins are expected to have the names of libfoo.so,
    not libfoo.so.X.Y as these are plugins, not libraries.
    So splitting %{_libdir}/vuurmuur/plugins/libtextdir.so.* and
    %{_libdir}/vuurmuur/plugins/libtextdir.so into defferent subpackages is
    perhaps nonsense (and plugin files should not be packaged in -devel
    subpackage).

    Note that usually %{_libdir}/libbar.so have to be installed in XXX-devel
    package, however plugin files named libfoo.so can be installed in non-devel
    package 

* Manfile
  - Files under %_mandir are automatically marked as %doc
  - Files under %{_mandir}/ru/ should be marked as %lang(ru).

* Static archive
  - Static archives (*.a files) must not be packages unless needed:
    https://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries_2

* Duplicate files
-----------------------------------------------------------------
$ rpm -qlp *rpm | sort | uniq -d
/usr/share/man/man8/vuurmuur_conf.8.gz
/usr/share/man/ru/man8/vuurmuur_conf.8.gz
/usr/share/vuurmuur/config
/usr/share/vuurmuur/config/config.conf.sample
/usr/share/vuurmuur/config/vuurmuur_conf.conf.sample
/usr/share/vuurmuur/help
/usr/share/vuurmuur/help/vuurmuur-fr.hlp
/usr/share/vuurmuur/help/vuurmuur-ru.UTF-8.hlp
/usr/share/vuurmuur/help/vuurmuur-ru.hlp
/usr/share/vuurmuur/help/vuurmuur.hlp
-----------------------------------------------------------------
  - These files are installed in more than 2 packages. Please fix
    %files list so that all files are listed only once.

F. And more...
From rpmlint:
* Vuurmuur-daemon.i686: W: service-default-enabled /etc/rc.d/init.d/vuurmuur
  - vuurmuur service is enabled by default after install, which is
    usually not desired. The line
-----------------------------------------------------------------
     9  # chkconfig: 345 91 9
-----------------------------------------------------------------
    should be changed to:
-----------------------------------------------------------------
# chkconfig: - 91 9
-----------------------------------------------------------------
    https://fedoraproject.org/wiki/Packaging/SysVInitScript#.23_chkconfig:_line

* Vuurmuur-daemon.i686: E: no-status-entry /etc/rc.d/init.d/vuurmuur
  - "status" option should usually be supported.

* %{_localstatedir}/log/vuurmuur
  - From %{_sysconfdir}/logrotate.d/vuurmuur, vuurmuur service creates
    log files under %{_localstatedir}/log/vuurmuur, however no package
    seems to own this directory, which is perhaps wrong. Please make
    this directory owned by some package.

When you modify your spec file, please post the URLs new spec file/srpm
on this bug.

Comment 3 Mamoru TASAKA 2009-11-13 16:33:27 UTC
ping?

Comment 4 Stjepan Gros 2009-11-14 22:06:30 UTC
Ok, here is the changed packet. There are few clarifications/notes:

C. %install

I'm removing .keep files in %{_buildroot} because they are not installed with the usual 'make install' command but those directories are marked as %doc.


Spec URL: http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur-0.7-2.fc11.src.rpm

Comment 5 Mamoru TASAKA 2009-11-15 16:51:55 UTC
(In reply to comment #4)
> C. %install
> 
> I'm removing .keep files in %{_buildroot} because they are not installed with
> the usual 'make install' command but those directories are marked as %doc.

- Ah, thank you. My additional comments will follow.

Comment 6 Mamoru TASAKA 2009-11-15 18:33:17 UTC
For -2:

! BuildRequires
  - It is up to you, however usually all BuildRequires are
    written in the main package section.

* Parallel make
  - Still parallel make is missing in two places (if possible,
    please enable it)
---------------------------------------------------------
    90  sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
    91  sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
    92  make
   116  sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
   117  sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
   118  make
---------------------------------------------------------

* Timestamp
  - Please consider to use:
---------------------------------------------------------
make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
---------------------------------------------------------
    to keep timestamps on installed files. This method usually works
    for Makefiles generated by recent autotools.

* Directory ownership issue
  - Some directories are not owned by any packages, ref:
    https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership
    https://fedoraproject.org/wiki/Packaging:UnownedDirectories#Common_Mistakes
    On i686:
----------------------------------------------------------
/usr/lib/vuurmuur/plugins/
/usr/share/vuurmuur/
/usr/share/vuurmuur/config/
----------------------------------------------------------
    ! Note
      At least with rpm >= 4.7, $ rpm -ivv *.rpm will show such information
      like
----------------------------------------------------------
D: Vuurmuur-0.7-2.fc12.i686: Header SHA1 digest: OK (84243c0b26f8e16c6b9f0bd2d14909735bf4f266)
D:   install: Vuurmuur-0.7-2.fc12 has 10 files, test = 0
D: opening  db index       /var/lib/rpm/Triggername create mode=0x42
Vuurmuur-0.7-2.fc12
D: ========== Directories not explicitly included in package:
D:          0 /usr/lib/
D:          1 /usr/lib/vuurmuur/plugins/
D:          2 /usr/share/doc/
D: ==========
D: /usr/lib/vuurmuur directory created with perms 0755, no context.
D: /usr/lib/vuurmuur/plugins directory created with perms 0755, no context.
D: fini      120777  1 (   0,   0)        20 /usr/lib/libvuurmuur.so.0;4b003ba3 
D: fini      100755  1 (   0,   0)    255652 /usr/lib/libvuurmuur.so.0.6.0;4b003ba3 
----------------------------------------------------------
    See the lines which shows "directory created with perms 0755, no context."

* Service
-----------------------------------------------------------
[root@localhost ~]# service vuurmuur status
vuurmuur は停止しています
vuurmuur_log は停止しています
[root@localhost ~]# service vuurmuur start 
Starting vuurmuur:Error (-1): could not open configfile '/etc/vuurmuur/config.conf': No such file or directory (in: init_config).
Initializing config failed.
                                                           [失敗]

-----------------------------------------------------------
  ( Well, "は停止しています" is "is stopped", "失敗" is "FAILED",
    currently due to the bug in initscripts (bug 537682)
    I cannot change these messages into English... )
  - I think it is preferable to install the default /etc/vuurmuur/config.conf
    file (Fedora prefers that the package works as it is by default)

Comment 7 Stjepan Gros 2009-11-15 19:56:07 UTC
Ok, I fixed all except the default configuration part. The problem is that it is very hard to create default configuration that would allow vuurmuur to start without any user intervention. The reason is that at least one rule has to be defined (otherwise, vuurmuur refuses to start), which, in turn, requires that at least one interface is defined. This is very hard to do in general case.

So, I added some configuration files, and switched services from shared directory to /etc/vuurmuur but the user has to start vuurmuur_conf tool to create initial configuration. What I can do is include check in init.d script to notify user about this in case it tries to start vuurmuur without configuring it first.

Is this OK?

Comment 8 Mamoru TASAKA 2009-11-16 15:37:09 UTC
Well, sounds good, however I want to check what you actually
want to do anyway. 

Note that I think %_sysconfdir/vuurmuur/config.conf should be
marked (included) as %ghost.

Comment 9 Stjepan Gros 2009-11-16 16:47:48 UTC
I just noticed that this check was already included in the init.d script but it wasn't working because it requires some basic configuration to be present, which now is.

I didn't specify %ghost for config.conf because it is installed.

Here is the new package:

Spec URL: http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur-0.7-2.fc11.src.rpm

Comment 11 Mamoru TASAKA 2009-11-17 18:17:08 UTC
For -3:

* Parallel make
-------------------------------------------------------------------
   110  cd ../vuurmuur_conf-%{version}
   111  %configure \
   112          --with-libvuurmuur-includes=${LIBVUDIR}/src/ \
   113          --with-libvuurmuur-libraries=${LIBVUDIR}/src/.libs/
   114  
   115  # Configure ignores --disable-rpath so we have to solve it this way
   116  sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
   117  sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
   118  make %{?_smp_mflags}
-------------------------------------------------------------------
  - With koji this parallel make (line 118) failed with -j4:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=1812437

    For this part please disable parallel make and comment on the spec file
    that parallel make fails on this part.

* -daemon <-> -tui
(In reply to comment #7)
> So, I added some configuration files, and switched services from shared
> directory to /etc/vuurmuur but the user has to start vuurmuur_conf tool to
> create initial configuration. 
  - Well, then 
    * it seems more logical that -daemon subpackage should have 
      "Requires: %{name}-tui = %{version}-%{release}" (in such case
      "Requires: %{name} = %{version}-%{release}" on -daemon subpackage
      is no longer needed because -tui subpackage already depends on
      the main package).

    * Or maybe -daemon and -tui subpackages should just be unified.

* Directory ownership issue
  - Still the following directories are not owned by any packages:
--------------------------------------------------------------------
%{_libdir}/vuurmuur/plugins/
--------------------------------------------------------------------

Comment 12 Stjepan Gros 2009-11-18 07:58:45 UTC
Ok, I disabled parallel make and also fixed an error in init.d script (by mistake it source named's configuration file, this was leftover from the template). I also fixed directory ownership.

Now, for this daemon vs. tui stuff, it's a bit tricky actually. Namely, you can run daemon without tui package. There is potential scenario in which you run daemon on one machine and you do configuration on another one, syncing in some way between the two. Now, if this will be used or not, I don't know, but IMHO, I would always install least I can. Anyway, I can do it anyway you think it should be done.

Spec URL: http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur-0.7-4.fc11.src.rpm

Comment 13 Mamoru TASAKA 2009-11-18 16:46:04 UTC
(In reply to comment #12)
> There is potential scenario in which you run
> daemon on one machine and you do configuration on another one, syncing in some
> way between the two.

- Well, I will admit it.

> Spec URL: http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur.spec
> SRPM URL:
> http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur-0.7-4.fc11.src.rpm  

Checked -5 (-4 is 404)
* Macros in %changelog
Vuurmuur.src:272: W: macro-in-%changelog %{_libdir}
Vuurmuur.src:281: W: macro-in-%changelog %{_datadir}
- In %changelog, please use %% instead of % so that macros won't be
  expanded, i.e.
----------------------------------------------------------
- Fixed ownership of the directory %%{_libdir}/vuurmuur/plugins
----------------------------------------------------------

----------------------------------------------------------
    This package (Vuurmuur) is APPROVED by mtasaka
----------------------------------------------------------

Comment 14 Stjepan Gros 2009-11-19 08:19:03 UTC
I messed up versioning and skipped unintentionally over release 4. Anyway, continuing with 6. Changelog is now fixed, here are new SRPM and spec file and I'm going to request CVS entry next.

Spec URL: http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur.spec
SRPM URL:
http://www.zemris.fer.hr/~sgros/stuff/fedora/vuurmuur/Vuurmuur-0.7-6.fc11.src.rpm

Comment 15 Stjepan Gros 2009-11-19 08:20:36 UTC
New Package CVS Request
=======================
Package Name: vuurmuur
Short Description: Firewall manager built on top of iptables
Owners: sgros
Branches: F-12
InitialCC: sgros

Comment 16 Jason Tibbitts 2009-11-19 23:05:04 UTC
Could you please clarify whether you wish this package to be named withan upper- or lower-case 'V' and reset the fedora-cvs flag?  The ticket summary as well as the spec and package name in comment #14 use initial upper case, but your CVS request uses lower case.  Everything should match.  (Personally I prefer lower case to match the binaries and libraries that you install, but in the end it's up to you.)

Comment 17 Stjepan Gros 2009-11-20 08:02:34 UTC
Well, upstream mixes letters too. It uses uppercase V for the main archive, while lower case v for archives within this archive. So, srpm and spec file are with upper case V, while binary rpms start with lower case v. I also prefer small caps but maybe in this case it should be better to use upper case V for CVS?

I'll wait for sponsor's comment on this before changing fedora-cvs flag again.

Comment 18 Stjepan Gros 2009-11-20 08:05:05 UTC
Ups, sorry. I should think a bit before posting as I just now realized everything ends up in upper case V. So, it's probably better that it is upper case in CVS after all. I'm changing fedora-cvs flag and here is CVS request again.

New Package CVS Request
=======================
Package Name: Vuurmuur
Short Description: Firewall manager built on top of iptables
Owners: sgros
Branches: F-12
InitialCC: sgros

Comment 19 Dennis Gilmore 2009-11-20 22:45:29 UTC
CVS Done

Comment 20 Mamoru TASAKA 2009-11-23 03:06:54 UTC
For build failure on F-12:

Please recheck my comment 11. Disabling parallel make should be
done under vuurmuur_conf-%{version} directory, not under
libvuurmuur-%{version} directory.

Comment 21 Fedora Update System 2009-11-23 16:21:28 UTC
Vuurmuur-0.7-7.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/Vuurmuur-0.7-7.fc12

Comment 22 Mamoru TASAKA 2009-11-23 19:09:07 UTC
Closing.

Comment 23 Fedora Update System 2009-11-25 15:32:17 UTC
Vuurmuur-0.7-7.fc12 has been pushed to the Fedora 12 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.