keybinder @0.3.0: update to version 0.3.1, add new port/subport keybinder-3.0, remove py26-keybinder

[dbevans (David B. Evans)]

keybinder is now at version 0.3.1.

In addition, the deprecated py26-keybinder subport could be removed as requested by petr in #49355.

The keybinder-3.0 issue has been moved to #52590

[dbevans (David B. Evans)]

Patch attached that updates keybinder to version 0.3.1 as follows

• fetch from github since previous download site is missing version 0.3.1
• update description to clarify this is a GTK2 app
• configure using autogen.sh to generate an updated configure file
• add the necessary build dependencies
• patch configure.ac to remove the use of deprecated GNOME_COMMON_INIT removed in gnome-common @3.18.0
• patch configure.ac to override the standard python install locations with the MacPorts version specific ones
• fix argument in configure.args in Portfile that specifies the absolute path to pygtk-codegen-2.0 to work when configuring with autogen.sh
• remove subport py26-keybindings

Additional patch attached to update py-graveyard to obsolete py26-keybinder

I haven't looked at keybinder-3.0. Not sure whether this should be a subport or a new port. I'm leaning toward new port since it is maintained as a separate github project.

[dbevans (David B. Evans)]

Patch for all issues except adding a new keybiinder-3.0 port

[dbevans (David B. Evans)]

The keybinder-3.0 issue has been moved to separate ticket #52590 for clarity.

[dbevans (David B. Evans)]

Updated patch to enable the build of gtk-doc API docs. GNOME libraries usually include pre-built API docs in the tarball but, since we are now building from scrath, we need to build them ourselves.

[dbevans (David B. Evans)]

Patch to py-graveyard to obsolete py26-keybinder (typo fixed)

[dbevans (David B. Evans)]

Proposed patch updated to enable gtk-docs per GNOME library common usage

[ryandesign (Ryan Carsten Schmidt)]

Is running autogen.sh really necessary? Would using the ​release download avoid that need?

[dbevans (David B. Evans)]

Replying to ryandesign@…:

Is running autogen.sh really necessary? Would using the ​release download avoid that need?

Unfortunately not. As with many github projects (and properly too), the files that are generated by running autogen.sh (configure, etc) are not included in the repo and (I just double checked) the release tar ball is identical to the repo contents. The benefit of this is that you generate configure, etc using the autotools version provided by the build system, not the developer system. Eliminates a possible problem if the autotools used to generate the tarball are really out of date.

The commit hash that I used is identical to the release tag you mention.

[dbevans (David B. Evans)]

Committed in r154011.