[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Bug 182305] Review Request: pyspi - Python bindings for AT-SPI



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: pyspi - Python bindings for AT-SPI


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182305





------- Additional Comments From toshio tiki-lounge com  2006-03-04 02:40 EST -------
I cannot sponsor you.  But I thought I'd do a review of the package and maybe
it would help get someone else to look things over and sponsor you sooner.

rpmlint:
src.rpm:
W: pyspi strange-permission pyspi.spec 0600
- You can change the mode to 0644 but this shouldn't harm anything.

x86_64.rpm:
W: pyspi no-version-in-last-changelog
- Changelogs in FE contain package version information like so:
    * Tue Feb 14 2006 Zack Cerza <zcerza redhat com> - 0.5.4-1

Needswork:
* Source should be a full URL to the upstream source:
 
http://people.redhat.com/zcerza/dogtail/releases/rpm_inst/%{name}-%{version}.tar.gz

* Description is short.  Perhaps something like this:
'''
  at-spi allows assistive technologies to access GTK-based applications.  It
  exposes the internals of applications for automation, so tools such as screen
  readers and scripting interfaces can query and interact with GUI controls.

  The pyspi binding allows the python language to be used to script at-spi
  aware applications (currently GTK+ based.)
'''

* Requires: at-spi is not needed as rpm finds the dependency automatically.
  Requires: python is not needed in FC4+ (rpm generates a requirement for:
    python(abi) = 2.4
  I'm not sure about FC3 but that's in maintence mode so you probably want
  to drop this explicit requirement from the spec file as well.

Minor:
* The FE preferred BuildRoot is
  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
  The id -u at the end ensures that two people rebuilding the package on a
  multi-user machine will not conflict with each other.
* Usual group for python libraries is Development/Languages
* You may use the %{dist} tag at the end of Release to make releases for
  several Core releases easier.

Good:
Went through the whole checklist.  Here are the highlights:
* Follows naming guidelines
* spec name matches base package name
* License is LGPL and properly reflected in tarball, spec, and package.
* The spec is quite understandable
* Source matches upstream tarball
* Builds on x86_64
* Permissions set correctly
* %clean cleans buildroot
* Consistently uses macros
* Documentation from the tarball is included
* Does not own files owned by another package
* No scriptlets
* Builds in mock
* Not understanding how at-spi is supposed to work, I didn't actually see if
  pyspi does anything useful.  I was able to load it up in the python
  interpreter and instantiate various atspi objects without segfaults,
  introspect them, and generally realize how foreign at-spi is to me.  I'll
  look at dogtail next and see what I can do with the combination of packages.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]