Re: RFS: presage
Paul Wise wrote:
> Wouldn't it be better to merge your patches upstream and release a
new version?
Yes, definitely. Patches have been sent upstream and integrated into
presage-0.8.4, which has just been released.
> I'm not sure if debian/patches/fix-shlib-calls-exit.patch is correct,
> shouldn't you replace exit(1) with return 1?
This patch fixed a warning in the obsolete smoothed count statistical
predictor, which was superseded by the generalized smoothed n-gram
statistical predictor. Upstream has removed code for this obsolete
smoothed count predictor from the tarball distribution.
> debian/patches/version-shared-library-symbols.patch only seems to
> patch generated files.
Yes, the debian patch itself modified the generated Makefile.in files.
(I generated the debian patch by taking a diff of the generated
Makefile.in, in order to avoid having to run autoreconf for the debian
package). However, the patch I sent upstream correctly changes the
source Makefile.am files.
presage-0.8.4 has proper symbol versioning, so this debian patch is no
longer required.
> Is it a good idea to install documentation in latex format as well as
> HTML? I would have thought that HTML would be enough for everyone who
> wants to read the documentation.
Done, only HTML documentation is now installed.
> You might also want to push presage into distributions like
> OpenEmbedded/SHR, which are used on phones like the OpenMoko
> Freerunner.
That's a great idea!
I ported presage to the Maemo platform some time back when I had a
working Nokia N770 (ARM arch), so it shouldn't be too hard to get it to
build for OpenEmbedded.
I might look at pushing presage into OpenEmbedded after it is accepted
in Debian ;-)
> I don't think every package needs to install THANKS, NEWS.gz,
> README.gz, TODO.gz, AUTHORS since some of them will be automatically
> installed.
Ok, I removed those files from all packages except for libpresage1 package.
> /usr/share/presage/python_binding.txt doesn't look like it needs to be
> installed in python-presage, nor libpresage-doc.
Done, removed python_binding.txt.
> resources/presage.png indicates it was generated by inkscape but I
> don't see the SVG source code for it.
Fixed, source is shipped in presage.svg.
> What is the point of installing /var/lib/presage in libpresage-data?
> Only root can modify files there and I doubt root will be using
> presage.
I changed the location where data files in the libpresage-data package
are installed to /usr/share/presage.
> Should the symbols file not be more specific about which symbols are
present?
According to the dpkg-gensymbols man page, in section "MAINTAINING
SYMBOLS FILES", "Using symbol patterns", "symver":
"Well maintained libraries have versioned symbols where each version
corresponds to the upstream version where the symbol got added. If
that's the case, you can use a symver pattern to match any symbol
associated to the specific version."
libpresage now ships a linker version script that versions all
exported symbols, hence the .symbols file uses the (symver) tag rather
than duplicating the versioned symbols information defined in the upstream
libpresage.map linker version script.
> I could be wrong, but I don't think the -dev package needs to
> explicitly depend on libc6-dev.
Done, I removed the libc6-dev dependency.
> libpresage-doc uses /usr/share/doc/presage-doc rather than
> /usr/share/doc/libpresage-doc to store the docs, which is slightly
> confusing.
Fixed.
> The manual pages in the
> presage/presage-gprompter/presage-pyprompter/python-presage packages
> mention that the full documentation is available in info format, but
> no info format documentation is installed.
Fixed, removed reference to info documentation from man pages.
> What do you think about merging
presage/presage-gprompter/presage-pyprompter?
I would rather not do that, for the following reasons:
1) dependencies
presage package only depends on libpresage1 (which in turn depends on
libpresage-data and very few other packages -basically, ncurses and
sqlite-), whereas gprompter pulls in all the GTK and X dependencies.
Pyprompter also depends on python-presage package, which in turn pulls
in all the Python and wxWidget dependencies.
presage package is meant to only contain the basic tools needed to
generate language models and resources used by the presage predictive
engine.
2) upstream
upstream long term plans might include splitting gprompter and
pyprompter into separate projects. This would allow presage, gprompter,
pyprompter to be released independently and would cleanly separate the
presage predictive text engine from applications using it.
Perhaps, in light of 2), it would be better to rename presage-gprompter
and presage-pyprompter packages to gprompter and pyprompter respectively?
> /usr/share/presage/getting_started.txt probably belongs in
> /usr/share/doc/presage/
Done.
> Remaining warnings:
>
> pyversions: missing XS-Python-Version in control file, fall back to
> debian/pyversions
> pyversions: missing debian/pyversions file, fall back to supported
versions
These warnings are harmless. I want the presage python extension module
to be compiled for all supported python versions. I am not providing a
pyversions file to let python-support build for all supported python
versions.
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> /usr/share/cdbs/1/rules/buildcore.mk:104: WARNING:
> DEB_DH_INSTALL_ARGS is a deprecated variable
The rules file does invoke dh_clean directly, nor does it use
DEB_DH_INSTALL_ARGS. These warnings seem to come from CDBS. They don't
seem to cause any problems. I think they can be ignored.
> dpkg-gencontrol: warning: package python-presage: unused substitution
> variable ${python:Versions}
Not sure where this warning is coming from. The variable is not used
anywhere in the control file.
> dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if
> "debian/libpresage1/usr/lib/libpresage.so.1.1.1" were not uselessly
> linked against it (they use none of its symbols).
I believe the -ldl flag is being passed in by libtool. It's not
explicitly passed in by the presage build system. I could track down
where this is occurring in libtool and patch it. Is this required to get
the package sponsored?
The updated package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/presage
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/p/presage/presage_0.8.4-1.dsc
Cheers,
- Matteo
Reply to: