[libvoikko] HFST support to libvoikko in Debian and Ubuntu?

[Timo Jyrinki]

This is mostly to the people planning to do the packaging work -
Børre, Tino, ... - also, the libvoikko list can be dropped at some
point when it soon starts to be very specific to packaging only. I'll
join the #hfst channel too at least

2016-01-09 22:42 GMT+02:00 Gaup Børre <borre.gaup at uit.no>:
> When building libvoikko, only hfstospell is needed.
> For the dictionaries, hfst is needed.

Right, that means hfstospell is a good place to begin as libvoikko
could already be built with that support even if there were no
dictionaries available at the same time yet.

>> Harri has an existing packaging for hfstospell which can be used as a
>> baseline: https://github.com/voikko/debian-packages/tree/master/.
> hfst has been packaged by apertium. Those packages might be used as
> baseline for hfst?

Sure if they have debian/ directory they could be helpful.

Now that apertium has been mentioned, and Tino's packages, and even
more people are being CC:d, mostly what is needed for you to decide
who all are going to work on the official Debian packagings, based on
what initial packaging, and where (in which git repo) the co-operation
will happen. And technical details like whether to do "debian/" only
git repo (like my Qt packagings
http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/log/?h=ubuntu) or
use upstream/debian/master branches (like my voikko related packagings
http://anonscm.debian.org/cgit/collab-maint/libvoikko.git/).
Regardless, everythin packaging related needs to happen under debian/
and the rest is just unmodified upstream sources, a release
preferably. See the bottom of this post for my (example) workflow.

What happened with me and Harri years ago that Harri did initial
packaging, I took it and refined it to meet all the Debian policies,
Harri merged the changes back to his "upstream offered packaging"
repositories, and from time to time when he updates something related
to latest development I can again utilize the changes to save some
time. There are sometimes needs that the external packagers have that
are not suitable as is in the packaging that goes to Debian/Ubuntu, so
there might be some delta to be kept for practical reasons.

> I could try to give a hand with this work. I've been using Debian and
> Kubuntu for many years. I have no experience with real packaging, but
> have sometimes repackaged some software for my own needs when necessary.

Welcome to world of packaging! At least having seen some debian/
directory contents helps already.

Most of the time is often spend in testing and fixing all the little
details, and getting know to the tools (and selecting tools in the
first place).

For example I'm hosting the packaging at Debian git collab-maint [1]
so that other Debian Developers and Maintainers can help. Though
Alioth collab-maint rights [2] do require at least DM status [3] which
is of course a good goal to have if going to spend more time with
Debian. Mentors site [4] is a good site to use for uploads for
newcomers, although actual code/packaging hosting would need to be
done somewhere else.

[1] http://anonscm.debian.org/cgit/collab-maint/libvoikko.git/
[2] https://wiki.debian.org/Alioth/PackagingProject
[3] https://wiki.debian.org/DebianMaintainer
[4] http://mentors.debian.net/

I'm using gbp tool [5] to manage it although I don't like all aspects
of the tool. When I start to think I've everything needed committed
(or at least git add:d), I do gbp buildpackage -S -sa to generate a
source package (.dsc) and then I use pbuilder [6] to build it. Without
pbuilder it's almost impossible to be certain the dependencies are
correct etc and that the package would build correctly.

[5] https://wiki.debian.org/PackagingWithGit
[6] https://wiki.ubuntu.com/PbuilderHowto

At the end of a pbuilder build, I check the lintian errors and
warnings, by going into the reported pbuilder result directory and
running for example lintian -i -I filename.dsc. All lintian reported
problems need to be fixed before considering an upload to Debian.

It's learning these tools and iterating on the small details that
takes time. One extra important (to Debian) file is debian/copyright
[7]. It needs to be 100% correct and represent all licenses and
copyright holders in the files in the upstream code and packaging.
'licensecheck' tool from 'devscripts' package is invaluable here
although not necessarily enough. licensecheck -r --copyright * is a
good start to grasp how much might be missing from the copyright file.

[7] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

And what really makes the "months" timeline which needs a lot of
patience is the fact that the NEW queue handling is often lacking
enough volunteers so the queue will take a lot of time even after
everything is ready.

Anyway, as seen, I can give tips, and have fun if you take the time to
jump to the world of packaging!

-Timo