This isn't compiling correctly under mock against development.
build.log reports:

checking for mount... /bin/mount
checking for umount... /bin/umount
checking ldap.h usability... no
checking ldap.h presence... no
checking for ldap.h... no
configure: error: Could not locate LDAP headers.
error: Bad exit status from /var/tmp/rpm-tmp.13491 (%build)

-jef

Build failure under mock is fixed in 0.21-2, in the same location.

Okay it builds in mock I'll start the formal review this evening.
A couple of small questions about the build.log

There is a check for xmlto which fails. Is this spurious or does this represent
some sort of optional functinality which could be turned on if xmlto was one of
the buildrequires? 

There is also a check for gfortran, is that just buildtime noise or would there
be something fortran specific that would be built if gfortran was available at
build time?

xmlto is used to convert the doc from xml to html if it's available, but there's
an already-formatted copy which is used if xmlto isn't found.

The check for gfortran must be noise -- there's nothing in there that would use
it if it were found.

Looking over the specfile some more in context to the Packaging Guidelines...
<spec quote>
BuildPrereq: dbus-devel >= 0.22, libselinux-devel, libxml2-devel
BuildPrereq: pam-devel, python-devel
BuildPrereq: cyrus-sasl-devel, krb5-devel, openldap-devel
Prereq: /sbin/chkconfig
</quote>
Should the BuildPrereq tags be replaced with BuildRequires?
http://www.fedoraproject.org/wiki/PackagingGuidelines#head-c00c7e039df9f68a709ce2ceee6a5454edf16f8c

And should the Prereq for chkconfig in the scriptlets be cast as a pair of tags:
Requires(pre) Requires(post) since its called in both pre and post scriptlets?
http://www.fedoraproject.org/wiki/PackagingGuidelines#head-24e6fc168588eeaa2f8000bf5516fc56dcfcf461

And since you also use /sbin/service in the preun script don't you also need a
Requires(pre): /sbin/service ?


rpmlint on mock built packages returns with what looks like spurious errors:

rpmlint oddjob-0.21-2.i386.rpm
  E: oddjob executable-marked-as-config-file /etc/rc.d/init.d/oddjobd
  W: oddjob incoherent-init-script-name oddjobd
rpmlint oddjob-devel-0.21-2.i386.rpm
  W: oddjob-devel no-documentation
rpmlint oddjob-libs-0.21-2.i386.rpm
  returns clean

-jef

Okay, I've updated to 0.21-3 with these changes, same location as before.  Thanks!

so actually if xmlto is added the docs are newly generated? i am not sure whats
the best way to go there then. regenerate the docs to be sure they match and
work properly... or use the prebuilt ones. just a thought ;)

The only difference that they should ever have is due to different stylesheets
-- the make rules should guarantee that.  But I supposed the package could pass
"--disable-xml-docs" to avoid even trying.  Opinions?

Sorry for the delay, I should be able to pick this backup this evening and get
further along on the mandatory review items.

-jef

uhm i dont actually see 0.21-3 at http://people.redhat.com/nalin/oddjob/extras/
Can you clarify where 0.21-3 is so I can grab it this evening?

-jef

After venturing a guess i found it for you, it's in
http://people.redhat.com/nalin/oddjob/ (without the extras) :-)

Formal Review Summary for 0.21-3:
No blockers according to the review guidelines.
But I haven't tested the intended functionality beyond checking that the service
script starts and stops correctly.  I'd like to test the provided sample, but
I'm sure I completely understand how to test it based on the text provided at
http://people.redhat.com/nalin/oddjob/.

I'll start a 48 hour clock on this approval. If someone is intereested in taking
the provided sample configuration in the docs for a spin and wants to report
back in the meantime please go ahead. 

Full Review:
- GOOD: rpmlint must be run on every package. The output should be posted in the
review.
all messages appear bogus
rpmlint oddjob-0.21-3.i386.rpm
E: oddjob executable-marked-as-config-file /etc/rc.d/init.d/oddjobd
W: oddjob incoherent-init-script-name oddjobd
rpmlint oddjob-devel-0.21-3.i386.rpm
W: oddjob-devel no-documentation
rpmlint oddjob-libs-0.21-3.i386.rpm
(no output)

- GOOD: The package is named according to the PackageNamingGuidelines.
- GOOD: The spec file name matches the base package %{name}, in the format
%{name}.spec
- GOOD: The package meets the PackagingGuidelines.
- GOOD: The package is licensed BSD 
- GOOD: The License field in the package spec file matches the actual license.
- GOOD: 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.
- GOOD: The spec file must be written in American English.
- GOOD: The spec file for the package MUST be legible. If the reviewer is unable
to read the spec file, it will be impossible to perform a review. Fedora Extras
is not the place for entries into the Obfuscated Code Contest ([WWW]
http://www.ioccc.org/).
- GOOD: The sources used to build the package must match the upstream source
105265e2cdf9f2370373ee5432a5b4cd  oddjob-0.21-1.tar.gz
- GOOD: The package must successfully builds on fedora-core-development i386 in mock
- GOOD: A package does not contain any BuildRequires that are listed in the
exceptions section of PackagingGuidelines.
- GOOD: All other Build dependencies are listed in BuildRequires.
- GOOD: No locale files. 
- GOOD: libs subpackage has correct post/postun scriplets
- GOOD: not designed to be relocatable, 
- GOOD: All the directories created in all subpackages are owned.
- GOOD: A package must not contain any duplicate files in the %files listing.
- GOOD: Permissions on files must be set properly. Executables should be set
with executable permissions, for example. Every %files section must include a
%defattr(...) line.
- GOOD: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
- GOOD: Each package must consistently use macros, as described in the macros
section of PackagingGuidelines.
- GOOD: The package must contain code, or permissable content. This is described
in detail in the code vs. content section of PackagingGuidelines.
- GOOD: no Large documentation files. 
- GOOD: 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.
- GOOD: Header files or static libraries must be in a -devel package.
- GOOD: Files used by pkgconfig (.pc files) must be in a -devel package.
- GOOD: 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.
- GOOD: In the vast majority of cases, devel packages must require the base
package using a fully versioned dependency.
- GOOD: Packages must NOT contain any .la libtool archives, these should be
removed in the spec.
- GOOD: No GUI applications 
- GOOD: Packages must not own files or directories already owned by other packages.

As you've noted, the sample configurations provided under /usr/share/doc are for
a not-particularly-useful sample service.

The sample script (usr/lib/oddjob/oddjob-sample.sh) is configured for oddjobd
(etc/oddjobd.conf.d/oddjobd-sample.conf) and the system-wide copy of D-BUS
(etc/dbus-1/system.d/oddjob-sample.conf).  (Uncovered a bug in the default
sample here, fixed it in 0.22).

After installation of these files, a restart of both the messagebus and oddjobd
services will be required to make both daemons reread their respective
configurations.

That done, a client can invoke the service using either:
  oddjob_request -s com.redhat.oddjob.sample -o /com/redhat/oddjob/sample -i
com.redhat.oddjob.sample sample
or, using the more standard D-BUS client tool:
  dbus-send --system --print-reply --dest=com.redhat.oddjob.sample
/com/redhat/oddjob/sample com.redhat.oddjob.sample.sample

The script indicated in the configuration will be run with superuser privileges,
and the client will receive its exit status and whatever it output to stdout and
stderr.

(In reply to comment #13)
> (Uncovered a bug in the default
> sample here, fixed it in 0.22).


Let me roll up binaries of 0.22 and make sure the sample works as you describe
and I will then approve 0.22 for cvs import.

-jef

Sorry real life caught up with me this week.  I'll be looking at finishing this
review up this weekend.

-jef

No worries.  I've been tweaking the build setup and code so that they'll build
with the version of dbus in FC3 and RHEL4 if a certain piece of SELinux-specific
functionality which I really, really want gets backported.  I'll have 0.23 up in
the usual places soonish.

Okay sorry it took so long. Marking this as APPROVED for FE devel

I just built local binaries of 0.23 under mock against the development trees. No
important changes in the spec file since 0.22 that need review
and the md5sums in the 0.23 src.rpm match the upstream source md5sum
df4a8c74dc972ede3c829b42da388f1b  oddjob-0.23-1.tar.gz

Once i move the example configs over to the system locations   
the example command in comment #11 appears to work as i expect. 

As an aside, this looks like a very good tool for sysadmins, but I think there
will need to be a little more polish associated with the documentation and
perhaps another example or two to help people walk through getting more familiar
with scripting dbus actions through oddjob

Back to the provided example
as user:
oddjob_request -s com.redhat.oddjob.sample -o /com/redhat/oddjob/sample -i
com.redhat.oddjob.sample sample
com.redhat.oddjob.Error.ACL: ACL does not allow access

as root
oddjob_request -s com.redhat.oddjob.sample -o /com/redhat/oddjob/sample -i
com.redhat.oddjob.sample sample
Error org.freedesktop.DBus.Error.SELinuxSecurityContextUnknown: Could not
determine security context for ':1.3'.
[env]
ODDJOB_OBJECT_PATH=/com/redhat/oddjob/sample
ODDJOB_INTERFACE_NAME=com.redhat.oddjob.sample
ODDJOB_METHOD_NAME=sample
ODDJOB_SERVICE_NAME=com.redhat.oddjob.sample
[id]
uid=0(root) gid=0(root) groups=0(root)
[vmstat]
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0    136   7588  34068 205392    0    0   160    67  169   401 10  3 84  3

-jef

Okay, the build system seems to like 0.24 (0.23 didn't quite build against FC3,
and it's my intention to keep it building with releases of D-BUS which are that
old, all the way up to 1.0).  Once the packages show up on the public servers,
I'll go ahead and mark this as resolved with resolution NEXTTRELEASE.

The circular dependency between the main package and the -libs package
is odd. The main package has an implicit dependency on the library
SONAME in the -libs package. The -libs package has an explicit dependency
on the main package. The initial import (tagged oddjob-0_23-1) has an
indirect dependency from the -devel package to the main package and
from there to the -libs package via the automatic SONAME dep. Instead,
it should have been just -devel requires -libs, not -devel requires
main package and not -libs requires main package.