[Pkg-silc-devel] Next steps!

[Daniel Kahn Gillmor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue 2007-05-22 10:07:08 -0400, Jérémy Bobbio wrote:

> 1. Alioth
> ---------
>
> The Alioth project has been created and is now ready to be used. :)

great, thanks!

> Another mailling-list, pkg-silc-commits [1] has been created which
> should receive SVN commit notifications.  I strongely suggest that we
> all subscribe to it.

subscribed.

> Which are:
>  * from the main archive: silc-toolkit, silky

schultmc, do you want to continue with this packaging strategy or
should we try a fresh start using debhelper/cdbs/dpatch/whatever?  Is
there a reason to stick with/modify the existing stuff?

>  * from dkg's repository: silc-client, silc-server

please let's *really* not start with this packaging.  These packages
are in bad state, should be completely overhauled.  I don't think we'd
be doing ourselves any favors to import it as-is.

> I would also like to see if the upstream for Kopete SILC plugin [1], who
> currently provide their own Debian package [2], would let us go one with
> their packaging.  If they agree, we definetely should import their
> current package as well.
>
> [1] http://brokenpipe.de/SILC/
> [2] http://www.brokenpipe.de/debian/pool/main/k/

This sounds good to me, though i've never used it myself.  If we can
build it with dependencies on the silc-toolkit, that'd be even better,
because it's one less copy of the silc code to have to maintain.


> 3a. Update silc-toolkit and silc-client
> ---------------------------------------
>
> silc-toolkit and silc-client are outdated ATM.  Last upstream versions
> are:
>  * SILC Toolkit 1.1 beta 5
>  * SILC Client 1.1 beta 3

Should we be packaging the beta versions?  They do seem close to an
official release, so maybe doing packaging would be worthwhile now.  i
tend to be leery about packaging stuff that's terribly unstable.

> 3b. Fix silky
> -------------
>
> silky is currently quite broken.
>
> My current intution is that it might be related to a mixup between
> "guchar" and "gchar" usage all through the code.
>
> Sounds like something doable but quite tedious to do.
>
> Upstream development seems unfortunately completely stopped.  A
> responsible move in this regard would be to remove the package from the
> archive.  But I don't advocate for such solution as: silky would be
> usuable without the segfaults and we don't have any other alternatives
> currently.

ugh.  i don't know what to say about this, as i've never used silky.
thanks for looking into it as far as you have.

> 3c. Get silc-toolkit in perfect shape if it's not already
> ---------------------------------------------------------
>
> silc-toolkit will be the first shared library that I'll be responsible
> for.  I started reading dancer's "Debian Library Packaging guide" [1]
> with this in mind.
>
> I didn't took the time (yet) to compare the current silc-toolkit package
> with the best practices mentioned in this guide, but I would really like
> to convince pidgin maintainers to enable the SILC plugin.
>
> So we should be able convince them and whatever is needed to do so.
>
> [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

i'd also consider using dh-make, which has very reasonable suggestions
for packaging libraries.  The biggest concern i'd have with what i've
seen from the package is how we figure out the official library
version number.

given that upstream can't even get it sorted out in a single web page,
this might be tricky:

 http://silcnet.org/general/news/?item=toolkit_20070510_1

> 3d. Have irssi-plugin-silc ready

this is my holy grail.  If we could get silc-toolkit and irssi-dev in
shape to build irssi-plugin-silc cleanly, we'd have the
best-practices command-line client.

If silc-toolkit satifisfies the pidgen maintainers, we'd have a very
decent GUI client.  With those things running, i wouldn't mind
dropping silky and the monolithic silc-client from debian entirely.

> SILC Client 1.1 beta 3 finally contain the ability to build the irssi
> plugin without the previous complexity that it was before.

> I would enjoy to see silc-client producing a binary package
> "irssi-plugin-silc" quite soon using solely upstream tarball.
>
> But it will not be completely correct regarding the Debian policy as we
> should normally be using the irssi-dev package as a dependancy instead
> of the source copy present in upstream tarball.
>
> My investigation showed that irssi-dev is currently missing the ability
> to produce Perl modules needed for a complete out of tree build of the
> SILC plugin.
>
> This will be quite some work to change both irssi-dev and the upstream
> source code to achieve Debian policy compliance.  So I suggest that we
> upload a initial version first, immediately adding an "important" bug
> mentionning the code duplication issue.

Sounds like you've looked into it farther than i have.  I agree that
it's a bug to rely on the source copy in the silc upstream tarball,
and would prefer to see it built cleanly.  It definitely merits an
"important" bug.

You didn't mention anything about silc-server, which has its own, uh,
interesting set of issues, including:

 * it should be built against silc-toolkit, instead of using its own
   internal copy of the library

 * it currently does its own logrotation, which seems like
   unmaintainable overkill: better to have it use a standard logrotate
   ruleset.

 * it doesn't appear to close all of its file descriptors when it
   daemonizes itself, which means you can't cleanly log out of an ssh
   session after doing a standard /etc/init.d/silc-server restart

 * the current packaging doesn't restart the server after an upgrade
   (or start the server after an installation), which is different
   from most debian servers.  It also doesn't use debconf or craft a
   reasonable initial config file.

 * silcd has some weird permissions requirements which i don't
   entirely think are worthwhile.  I've removed one of them in my
   1.0.4-2 packaging, but we might want to make other changes as well.

thanks for getting this rolling, Jérémy.

       --dkg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGU350iXTlFKVLY2URAmowAKDABuIhqaAdUD7K2eplVf1xzMC+rwCgnKbU
JkXmgKrnch69mPCHTWw7Zs0=
=2aIF
-----END PGP SIGNATURE-----