Bug 211319

This is my first package to Fedora and im seeking a sponsor.

A quick review of the spec file (I have not installed this application yet):

- The spec file has strange file permissions (750); should be 644
- spec file naming incorrect; should only be "anduttey-client.spec"

SPEC FILE INNARDS:
- spec file format is a bit messy: use "rpmdev-newspec" available from
rpmdevtools in Extras to create a template
- Packager tag should not be present
- "AutoReqProv: no" is present; why? Under normal circumstances this should
never be used.
- License: GPL v2  - should just be GPL (the "v2" not necessary)
- Invalid Group: System Environment/Applications  --- should be Applications/System
- Release tag is invalid: no %{?dist} tag present
- Vendor tag should not be present (set by Fedora buildsys)

- Inconsistent use of RPM_BUILD_ROOT tags, see:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-f3d77b27a5d29dfc1f5600ef3fc836f2e317badf

- %pre and %post scripts are too long, and incorrect (chkconfig and user parts;
I haven't checked the anduttey-specifc stuff): see
http://fedoraproject.org/wiki/Packaging/Guidelines#head-220f87f993c84311859884f2a033a8706a2c7d7c

------- For instance:
<snip>
# Registering services
if [ -f "/sbin/chkconfig" ]
   then
   /sbin/chkconfig --level 3 andutteyed on
   /sbin/chkconfig --level 5 andutteyed on
fi
</snip>

This should be placed in the andutteyed init.d script as defaults for chkconfig,
and should not be managed by your spec file.
Your specfile can then simply register the service with something like:
/sbin/chkconfig --add andutteyed


- %install section: no build root cleanup
--- %install section: install procedure seems to simply dump everything in the
buildroot. Also: Refrain from using /opt; rather use standard directories. Place
executable binaries in /usr/bin (using macros such as %{buildroot}%{_bindir}, etc

--- %pre and %post scripts create new user account and starts/stops service, but
there is no %preun and %postun to "remove" these effects on the system, so the
package is never cleanly uninstalled

--- %files: section is messy; you can use %defattr much more effectively and
remove most of the %attr statements

--- %files: your are using hard-coded paths (e.g. /usr/share/man/man1/*); use
macros instead

--- Changelog inconsistent with release tag

This spec file needs a lot of work. I am also unsure of the requirements of this
package -- does it require the anduttey-server package (which is on the upstream
website)? If this package isn't useful without the -server package, it might be
a good idea to first add the -server to Fedora Extras. 

(In reply to comment #2)
> package -- does it require the anduttey-server package (which is on the upstream
> website)? If this package isn't useful without the -server package, it might be
> a good idea to first add the -server to Fedora Extras. 

Aah, sorry, didn't read your description properly; I see there's a "standalone"
mode. Please ignore that comment. :-)

Some more things (note, I have not yet installed this package):

* package builds in mock (FC6, i386)

* rpmlint output:
W: andutteye-client summary-ended-with-dot Andutteye Software Suite Monitoting
agent.
W: andutteye-client spelling-error-in-description availble available
E: andutteye-client description-line-too-long Andutteye-client the client part
of Andutteye Software Suite Monitoring solution.
E: andutteye-client description-line-too-long With the andutteye client you can
monitor your operatingsystem, retrive statistics
E: andutteye-client description-line-too-long can be used in standalone mode or
connected to a Andutteye Software Suite server
W: andutteye-client non-standard-group System Environment/Applications
W: andutteye-client no-version-in-last-changelog
W: andutteye-client invalid-license GPL v2
W: andutteye-client conffile-without-noreplace-flag /etc/profile.d/aesurveillance.sh
E: andutteye-client non-standard-uid /opt/andutteye/bin andutteye
E: andutteye-client non-standard-gid /opt/andutteye/bin andutteye
E: andutteye-client dir-or-file-in-opt /opt/andutteye/bin
E: andutteye-client non-standard-dir-perm /opt/andutteye/bin 0770
E: andutteye-client non-standard-uid /opt/andutteye/var andutteye
E: andutteye-client non-standard-gid /opt/andutteye/var andutteye
E: andutteye-client dir-or-file-in-opt /opt/andutteye/var
E: andutteye-client non-standard-dir-perm /opt/andutteye/var 0770
E: andutteye-client non-standard-uid
/opt/andutteye/backbone/andutteye-api-aix.pl andutteye
....
[snip]
.....
(its very long)

These need to be addressed. Most of rpmlint's issues have to do with the points
I mentioned in comment #2. To add to that:
- no %doc is present in %files. This should *at least* include the LICENSE file
(with correct permissions) that is included in the source tarball; adding the
README is a good idea also ;-)

Thanx for the input. I have done my best to correct the spec file to meet your
suggestions, hopefully it looks a little better now. Let me know if there are
more things that must be corrected. I have uploaded a new specfile for you to
validate. Im also planning to add the server, syslog, cache, management
packages, but the client package is the smallest, easiest to install and can be
used in standalone mode so i thought it could be a good start.

http://www.andutteye.com/download/anduttey-client.spec

(In reply to comment #5)
> packages, but the client package is the smallest, easiest to install and can be
> used in standalone mode so i thought it could be a good start.
Good plan, makes sense :-)

The spec file looks better, but my primary concern is that it doesn't meet the
packaging guidelines (http://fedoraproject.org/wiki/Packaging/Guidelines) and
the review guidelines (http://fedoraproject.org/wiki/Packaging/ReviewGuidelines).
Both of those pages provide a wealth of information and tips, and you might also
find the following useful for your scriplets inside the spec file:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

Use rpmlint on the package (it is available from Extras), and try to fix as many
of the problems as you can. To get more information from rpmlint, use the -i
option (it gives a brief description of all problems, and may suggest possible
fixes). Feel free to ask if you need help.

Thanx for all input! Hopefully it will go smoother on future packets when i have
learned the Fedora standard correctly :-). Is this the right way to go if one
wants to change locations on the software when the packed software in the Source
tarbundle? have different locations defined?

<snip>
%install
mkdir -p %{buildroot}%{andutteye_bin_dir}
install -m 0755 opt/andutteye/backbone/andutteye-api-linux.pl  
%{buildroot}%{andutteye_bin_dir}
install -m 0755 opt/andutteye/bin/andutteyed                            
%{buildroot}%{andutteye_bin_dir}
install -m 0755 opt/andutteye/utils/*                          
%{buildroot}%{andutteye_bin_dir}
install -m 0644 opt/andutteye/LICENSE                           
rm -rf %{buildroot}/opt/andutteye
</snip>

Thanx in advance.

The spec file so far (Note haven tried to install with this yet!)

http://www.andutteye.com/download/andutteye-client.spec

(In reply to comment #7)
> Thanx for all input! Hopefully it will go smoother on future packets when i have
> learned the Fedora standard correctly :-). 

We all learn this way... :-) You'll find that Fedora's package guidelines will
assist you greatly in making quality packages for other distributions also,
should the need ever arise.

>Is this the right way to go if one
> wants to change locations on the software when the packed software in the Source
> tarbundle? have different locations defined?
> 
> <snip>
> %install
> mkdir -p %{buildroot}%{andutteye_bin_dir}
> install -m 0755 opt/andutteye/backbone/andutteye-api-linux.pl  
> %{buildroot}%{andutteye_bin_dir}
> install -m 0755 opt/andutteye/bin/andutteyed                            
> %{buildroot}%{andutteye_bin_dir}
> install -m 0755 opt/andutteye/utils/*                          
> %{buildroot}%{andutteye_bin_dir}
> install -m 0644 opt/andutteye/LICENSE                           
> rm -rf %{buildroot}/opt/andutteye
> </snip>
> 

You can do it this way, but *if* your source tarball has a makefile, try to
rather create an "install target" patch for it; its cleaner, and allows you to
add (submit) it to the upstream source. In your case, this is fine (since the
upstream source does not have any such makefile). 

A few comments:
* don't use %{andutteye_*_dir}; use one of the standard macros, like %{_bindir};
you can find documentation on these macros in /usr/share/doc/rpm-4.4.2; they are
 defined in code in /usr/lib/rpm/macros. In short:
    %_prefix            /usr
    %_exec_prefix       %{_prefix}
    %_bindir            %{_exec_prefix}/bin
    %_sbindir           %{_exec_prefix}/sbin
    %_libexecdir        %{_exec_prefix}/libexec
    %_datadir           %{_prefix}/share
    %_sysconfdir        %{_prefix}/etc
    %_sharedstatedir    %{_prefix}/com
    %_localstatedir     %{_prefix}/var
    %_libdir            %{_exec_prefix}/lib
    %_includedir        %{_prefix}/include
    %_oldincludedir     /usr/include
    %_infodir           %{_prefix}/info
    %_mandir            %{_prefix}/man

* Use -p for "install" and "cp" commands, to preserve timestamps. See:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-0239576e441f9ef53d175c4aec8c12868dffb5ab

* Insert a "rm -rf %{buildroot}" command as the first line of %install

* The final line in %install, "rm -rf %{buildroot}/opt/andutteye", should not be
necessary, since the directory isn't created

* In your %files section: %doc %{andutteye_doc_dir}/LICENSE, etc - the
%{andutteye_doc_dir} is not necessary, as %doc automatically places these files
in the correct dir (/usr/share/doc/%{name}-%{version}-${release})

* Also in %files, rather use the standard dir macros

This is looking much better! :-) From now on, please increment the release tag
for each subsequent spec publishing (and check that the changelog
version-release info matches that of the spec ;-) )
Also, for other people to participate in the review, it will be necessary to
build SRPMs for each release as well, so everything can be tested.
Good luck!

As said before, thanx for the fast and good replies and input!! I agree that the
spec file looks more "clean" now. I have now tried to build on it, installed,
reinstalled and uninstalled the software, looks fine in AES point of view. Let
me know if i shall correct anything else in the spec. Release tag and changelog
should be in sync now ;). 

I have uploaded new files, here.
http://www.andutteye.com/download/andutteye-client.spec
http://www.andutteye.com/download/andutteye-client-2.3-9.src.rpm

Ok, some comments:
* Don't hard-code your %{andutteye_*_dir} paths - this is actually what I meant
by using the standard macros. If you want to define these directories as your
own macros (i.e. you want to you the %{andutteye_*_dir} macros), then change
their definitions so that they use the default macros. Hard-coded directories
are problematic; for example:
<snip>
%define   andutteye_cfg_dir   /etc/andutteye
%define   andutteye_doc_dir   /usr/share/doc/andutteye
</snip>
...this is incorrect, as RPM will allocate a documentation directory
automatically to your package, based on its version-release info, and it will
not be "/usr/share/doc/andutteye". And what if the system's configuration
directory isn't /etc? Unlikely, yes, but it *is* possible.

Rather do something like:
%define andutteye_cfg_dir %{_sysconfdir}/andutteye

In my opinion, though, I would not use the andutteye_*_dir macros at all, as
they add unnecessary complexity to the spec file; instead of using
%{andutteye_cfg_dir}, for instance, something like %{_syconfdir}/andutteye is
more readable for to other maintainers (and end-users recompiling your package),
since almost all other packages use this method. It definitately makes the
%files section more readable.

* For your documentation, you do not have to (and shouldn't) explicitly copy the
files to a doc dir instal %install. Just flag the files as %doc entries in the
%files section, and RPM will sort it out automagically :-). For example:
%doc opt/andutteye/LICENSE opt/andutteye/README

* When installing the application, it generates a lot of noise; this seems to be
because of the "andutteyd" and "andutteye-api-linux.pl" script calls in %post.
The final package should be quiet during installation, so rather redirect this
output to /dev/null

* On the %post scripts: I haven't checked exactly what these two scripts do, but
they seem to generate a quite a few settings-files; shouldn't these rather be
called during %install? (as Fedora systems should provide a similar baseline for
detection) You're the expert here, of course, so I might be missing the point
completely ;-).

* The %post scripts complained when I installed the program on my system:
<snip>
WARNING!! Needed binary:lspci wasnt found in the users $PATH add a path
otherwhise andutteye wont work correctly
WARNING!! Needed binary:ifconfig wasnt found in the users $PATH add a path
otherwhise andutteye wont work correctly
</snip>

On my system:
$ whereis lspci
lspci: /sbin/lspci /usr/share/man/man8/lspci.8.gz
$ whereis ifconfig
ifconfig: /sbin/ifconfig /usr/share/man/man8/ifconfig.8.gz

Also:
$ rpm -qf /sbin/ifconfig
net-tools-1.60-73
$ rpm -qf /sbin/lspci
pciutils-2.2.3-4

If these two program are needed for andutteyed to function, you need to add
those two packages (net-tools and pciutils) to "Requires" in the spec file. (I
notice you also use /bin/netstat, which is also part of the net-tools package).
The path-issue can be fixed in a variety of ways, like adding it to the
andutteye-user's PATH, or applying a patch. Also what about calling this script
in %install (as I suggested above)?

* In your %post script, for upgrades:
<snip>
/etc/init.d/andutteyed start
</snip>

The package should check whether the andutteyed daemon is currently running,
before starting it (maybe the user DOESN't want to have it running at the
moment?) Adding "reload" or "condrestart" options to /etc/init.d/andutteyed
would be the best solution (and would help to keep rpmlint quiet :-) )

* The package places a log file (andutteye.log) in /var/cache/andutteye; this
should go in /var/log

* The pid file in /var/run has a typo ;-) (/var/run/anduttyed.pid)

* From rpmlint:

E: andutteye-client sourced-script-with-shebang /etc/profile.d/aemonitoring.sh
This text file contains a shebang, but is meant to be sourced, not executed.
-- Solution: remove the shebang

E: andutteye-client executable-sourced-script /etc/profile.d/aemonitoring.sh 0755
This text file has executable bit set, but is meant to be sourced, not
executed.
-- Solution: change the file permission to 0644

W: andutteye-client no-reload-entry /etc/init.d/andutteyed
In your init script (/etc/rc.d/init.d/your_file), you don't
have a 'reload' entry, which is necessary for good functionality.
-- See comment about %post upgrade script, above

Thanx for the input and the snip codes, its a great help to know what the things
should be changed to. I think its close now, i have implemented all of your
changes above... almost :).

Good idea with the baseline configuration. -genconfig creates a configuration
based on your system, which processes that are started, which filesystems that
are mounted etc and crates a config. But with a baseline the user can get
examples on all types of the AES monitor framework, which can be an even better
start to learn the design and how it workes. The user can always execute
andutteyed -genconfig manually to rediscover the system and create a new
configuration. The generation phase creates, and andutteyed only uses one config
file that is located under /etc/andutteye/andutteyed.conf.

The andutteye <-> api communication is initiated when andutteyed (that contains
the AES logic) needs the recive some information from the operatingsystem. The
enviroment parameters set in /etc/profile.d/aemonitoring.sh is setting which os
(and which os api to use) andutteyed is running on.

I have uploaded new packages and spec file, rpmlint is now silent. Hopefully a
good thing ;). I have two questions though.

The agent is running as the normal andutteye user and dont have permission to
create and append to a log file under /var/log. What approach should i use to
over come that?

The andutteye user should have /sbin in its PATH so that all statistics can be
retrived. This is only nessasary if the agent is connected to a AES server
though. What is the best approach for this?

New packages and spec file.

http://www.andutteye.com/download/andutteye-client.spec
http://www.andutteye.com/download/andutteye-client-2.3-10.src.rpm

Many improvements! :-) This is really coming along well.
Your 2 questions:
 > The agent is running as the normal andutteye user and dont have permission to
> create and append to a log file under /var/log. What approach should i use to
> over come that?

You can create the log file during %install (using touch or something similar),
and change its ownership to the andutteye user, or you can create a "andutteye"
or "andutteyed" subdir in /var/log, with ownership set to the andutteyed user;
in this case you can simply own the directory itself in %files. 

You also need to create a entry in /etc/logrotate.d to control the size of the
log file(s); this can also be used to set ownership/permissions, etc (look at
existing configurations in /etc/logrotate.d for examples; yum has a simple but
effective entry, ppp as well).

> The andutteye user should have /sbin in its PATH so that all statistics can be
> retrived. This is only nessasary if the agent is connected to a AES server
> though. What is the best approach for this?

The user account that gets created should actually be a system account, i.e. not
one that a "normal" user can be used to log in as. You can use something like:
%pre
# Create system account
/usr/sbin/useradd -g andutteye \
     -c "Andutteye Software Suite monitoring server" -r -M -s '' \
     -d %{_localstatedir}/cache/andutteye andutteye &>/dev/null || :

Note the -r flag there (for creating a system account), and setting the home
directory to /var/cache/andutteye. Since this service is then started as a
system account by init, it *should* include /sbin/ in its PATH... Let me know
how it goes - I'm very rusty on this, so if anyone knows better, please advise.

Some other stuff:
* %doc entries: permissions are incorrect (0644, should be 0755)
  - by the way, you can (if you like) place all the doc entries in one %doc
statement, by seperating them with spaces

* Man pages are installed in the wrong location (they are not accessible).
Suggested fix:
%install
  [...snip...]
mkdir -p %{buildroot}%{_mandir}/man1
install -p -m 0755 usr/share/man/man1/* %{buildroot}%{_mandir}/man1
  [...snip...]
%files
  [...snip...]
%{_mandir}/man1/*
  [...snip...]

* I've been delaying mentioning this, but your Source statement needs to have
some sort of information on HOW to obtain the source tarball. Usually this is
done by specifying the full URL where the source file(s) can be downloaded, i.e. 

Source0:
http://www.andutteye.com/download/andutteye-client-%{version}-%{release}.tar.gz

There is a slight problem here, though. I've noticed that you increment a
"release" tag of the source tarball for each successive RPM build (to
synchronize the two releases). This is your choice, of course (you're the
author, after all), but does anything actually change in the tar.gz release? It
would be easier to maintain this package if you leave the "release" tag to
indicate *RPM* releases, and just keep a "version" tag for the tarball (this is
how it usually works, anyhow).

So, in short, how it usually works:
RPM packages foo-1.3-1, foo-1.3-5, foo-1.3-6 all use the same source: foo-1.3.tar.gz
The different "release" tags merely state that something specific to the RPM has
changed, not the upstream program. In this fashion, if the source tarball
changes (say, to foo-1.3.1.tar.gz), the RPM's release tag is reset, so the RPM
package becomes foo-1.3.1-1.tar.gz.
Notice that the release tag only shows changes in the RPM itself (specfile
changes, etc), not changes in the upstream source. And everytime the source
changes, RPM's release tag goes back to 1. 
This is a packaging rule in Fedora, so if you decide to keep the "-release" in
the upstream tarball, you have to put that into your "Version" tag in the spec,
and change the "-" character to something else, perhaps a '.'. In other words,
for the tarball andutteye-client-2.3-7.tar.gz (on the website), the resulting
RPM package should be something like:
andutteye-client-2.3.7-1.noarch.rpm
or
andutteye-client-2.3_7-1.noarch.rpm

* rpmlint isn't silent (run it on the binary rpm, not the .src.rpm :-) ), but a
lot of the output has to do with the andutteye user account, as well as the
man-page stuff. Some interesting entries that need to be addressed:

E: andutteye-client non-readable /etc/andutteye/andutteyed.conf 0640
W: andutteye-client non-conffile-in-etc /etc/andutteye/andutteyed.conf

-- change the permissions for this file, and mark it as %conf in %files

W: andutteye-client service-default-enabled /etc/init.d/andutteyed

-- I don't have enough experience to comment on this. Depending on the service,
it may or may not be a good thing to have this specific service enabled by
default. In your case, I'm leaning towards "ok", but I'm sure your sponsor will
be able to advise you better on this.

Thanx for the good input Francois. I have corrected the package after your input
above. The logrotate program works, aswell as the installation. Still problem
with adding /sbin to the users PATH. 

I tried your workaround Francois but it didnt work. It seemed that the user
didnt get any .bash_profile at all. Also as you mention above, maybe i shall
remove the default add of the service? Let me know if you find something else to
correct.

http://www.andutteye.com/download/andutteye-client.spec
http://www.andutteye.com/download/andutteye-client-2.3-11.src.rpm

It's too bad this never saw any further review activity.  The links in comment
#14 are dead, and as I check the upstream site I don't even see any release
beyond 2.2.

So what should happen now?  If there's still a desire to get this package into
the distribution, go ahead and post some fresh packages and someone will take a
look.  Otherwise I guess we should just close this ticket.

The project and software are very much alive as you can se on Roadmap and 
timeline on the development site (By clicking bugtracker on andutteye.com). 
Francois and me did much work on this in a short amount of time, then nothing 
happend. I got the impression that the first submit of a software could take a 
long time but as it should take this long time to get more attention to it i 
wouldnt belive. Since last time i had to change hostingprovider and website so 
the links above was broken but isnt anymore. I still want to provide andutteye 
to the community if there still is intrest from Fedora. In coming version 3.0 
of Andutteye many features that doesnt exist at all in systemsmanagement 
softwares out there are being deployed that im sure of that the community 
should think was fun to use and play with. 

Please let me know if i can assist in any way or update the spec or software 
in any way.

Some remarks for 2.3-11:

* First, rpmlint:
---------------------------------------------------
W: andutteye-client spurious-executable-perm /usr/share/man/man1/andutteyed.1.gz
W: andutteye-client spurious-executable-perm
/usr/share/doc/andutteye-client-2.3/README
E: andutteye-client non-standard-uid /var/cache/andutteye andutteye
E: andutteye-client non-standard-gid /var/cache/andutteye andutteye
W: andutteye-client spurious-executable-perm
/usr/share/doc/andutteye-client-2.3/LICENSE
E: andutteye-client non-standard-uid /usr/bin/andutteyed andutteye
E: andutteye-client non-standard-gid /usr/bin/andutteyed andutteye
W: andutteye-client spurious-executable-perm /usr/share/man/man1/postandutteye.1.gz
E: andutteye-client non-standard-uid /var/log/andutteye andutteye
E: andutteye-client non-standard-gid /var/log/andutteye andutteye
E: andutteye-client non-standard-uid /etc/andutteye/andutteyed.conf andutteye
E: andutteye-client non-standard-gid /etc/andutteye/andutteyed.conf andutteye
E: andutteye-client incoherent-logrotate-file /etc/logrotate.d/andutteyed
E: andutteye-client non-standard-uid /usr/bin/andutteye-api-linux.pl andutteye
E: andutteye-client non-standard-gid /usr/bin/andutteye-api-linux.pl andutteye
E: andutteye-client non-standard-uid /usr/bin/postandutteye andutteye
E: andutteye-client non-standard-gid /usr/bin/postandutteye andutteye
W: andutteye-client dangerous-command-in-%postun userdel
W: andutteye-client service-default-enabled /etc/init.d/andutteyed
E: andutteye-client incoherent-subsys /etc/init.d/andutteyed andutteyed}
W: andutteye-client service-default-enabled /etc/init.d/andutteyed
W: andutteye-client incoherent-init-script-name andutteyed
------------------------------------------------------
   - While many of these rpmlint can be ignored in my opinion,
     some of them should be fixed.
 
   SUMMARY:
   - Please fix the permission of the documents and man files
     (all these files should have 0644 permission)
   - Why should the 3 scripts under /usr/bin should have
     (owner:group) = (andutteye:andutteye)?
     These scripts are not setuid'ed or setgid'ed, so the 
     euid/egid of the process using these scripts are the same
     as the real uid/gid, so anyway it should be okay
     with (owner:group) = (root:root)
   - Does andutteye user edit/modify the config file
     /etc/andutteye/andutteyed.conf when andutteyed daemon is
     running or something else happens?
     If the config is to be editted by sysadmin anyway,
     then the (owner:group) of this conf file should be okay
     with (root:root).
   - Please remove /usr/sbin/userdel, /usr/sbin/groupdel completely.
     Current Fedora policy is that "userdel groupdel must not
     be done automatically by rpm and these should be done
     manually by sysadmin".
   - Currently when andutteye-client is installed, it automatically
     enables andutteyed service on level 345 as
--------------------------------------------------
# chkconfig: 345 90 10 
--------------------------------------------------
     , which is bad. sysadmin should manually set the level where
     andutteyed should be enabled. Please change to
--------------------------------------------------
# chkconfig: - 90 10 
--------------------------------------------------

* groupadd/useradd
  - Please consider if the failure of groupadd or useradd
    command should be ignored (i.e. consider if
--------------------------------------------------
groupadd ..... || :
--------------------------------------------------
    is okay... You can refer to the suggestion by
    Ville:
    http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups )
  - And add the proper Requires(pre).. etc
    (Please check: the section "Services" of
     http://fedoraproject.org/wiki/Packaging/ScriptletSnippets )

* Macros
  - For directory where services scripts are to be installed,
    please use %_initrddir (= /etc/rc.d/init.d), not
    /etc/init.d
  - /usr/sbin -> %_sbindir

* sourced file
  - Well, %{_sysconfdir}/profile.d/aemonitoring.sh is source'd
    also by normal user (like /etc/profile.d/less.sh).
    Is it needed? If not, please move this file to
   %{_sysconfdir}/andutteye/, for example.

ping?

ping again?

ping again?

This bug will be closed if no response will be received from
the reported within one week.

CLOSING

If someone wants to import this package into Fedora, please
file a new review request, thank you.