Spec Name or Url: http://people.redhat.com/nalin/oddjob/extras/oddjob.spec SRPM Name or Url: http://people.redhat.com/nalin/oddjob/extras/oddjob-0.21-1.src.rpm Description: A method for running privileged applications on behalf of unprivileged clients. Clients issue requests to oddjobd over the system message bus (D-BUS). In addition to access controls provided by D-BUS, the oddjobd server provides an ACL facility to control who can issue requests for helpers.
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.