[Pkg-silc-devel] Next steps!

[Jérémy Bobbio]

On Tue, May 22, 2007 at 07:36:23PM -0400, Daniel Kahn Gillmor wrote:
> > The Alioth project has been created and is now ready to be used. :)
> 
> great, thanks!

The creation of the subversion repository was also requested today.

> >  * 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 find it less tedious to proofread many files that to completely start
again.

Importing the current packages in the repository, even if there are in a
bad shape will also allow us to review the changes together through
commit logs.

> > 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.
> 
> 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.

I will send them a mail right after this one.

> > 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.

If SILC packages inside the Debian archives where all perfectly usuable,
I would answer that we could package beta version in experimental.

But Lenny is far from being released, and we can still break unstable
when we need it. Packaging beta versions can help upstream by providing
more users -> more testing -> more bugs reported.

With svn-buildpackage, I never found that it was a terrible job to
update a package for a new minor upstream version.  We also have 3 DDs in
the team, so bothering someone to actually do the uploads won't be a
problem as well...

> > 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.
>
> 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.

I'll try to dig this issues in the next weeks, if no one else does...

> > 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'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.

dh-make does not help you when you switch a package to a newer upstream
version...  I have read so many angry answers to silent API or ABI
breakage that I would like to get it right.

If I understood correctly, the current "libsilc-1.0-2" scheme should
protect us from silent breakage, but forces everyone to rebuild every
package on a even a nem minor upstream version.

> > 3d. Have irssi-plugin-silc ready
> [...]
> 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.

I was a bit disapointed from my tests.  IIRC, it lacks support for a lot
of interesting feature of the protocol, like key checkings and signing.

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

I had not looked into it.  Thanks for the insights!

Seems there will be some patching to do in silc-server as well.  But
it's always easier to deactivate some code than to write it from
scratch. :)

Cheers,
-- 
Jérémy Bobbio                        .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-silc-devel/attachments/20070523/0fc3e81e/attachment.pgp