[OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available

Ian Goldberg ian at cypherpunks.ca
Sat Jul 28 14:23:59 EDT 2007


On Fri, Jul 27, 2007 at 07:51:25PM -0400, Greg Troxel wrote:
> I don't mean to rant, but I'm trying to package pidgin-otr and having a
> harder time than seems necessary.  I'm experienced enough at packaging
> that I suspect others are too.
> 
> 1) at http://www.cypherpunks.ca/otr/ it says that there is
> 
>    OTR plugin for Pidgin (formerly known as gaim)
> 
> and the file is http://www.cypherpunks.ca/otr/gaim-otr-3.0.0.tar.gz But
> this file is a plugin for gaim (1.5), not for pidgin (which to me
> implies 2.0).  The headline should indicate clearly that this is for
> gaim 1.5.X.

We're just waiting for the final release version of 3.1.0 to be ready,
which looks like Aug 1 plus or minus a day or two.  All that's left is
some tidying of some of the documentation.  At that point, the old
versions will come off the website.

> 2) There is no obvious way to find out the list of files available for
> download.  Simply putting them all in
> http://www.cypherpunks.ca/otr/download/ and enabling indexing would help
> a lot.

As a rule, the webserver's indexing is off, but you make a good point,
and I'll ponder this.

> 3) It seems that pidgin has been out for a while, so it never occured to
> me that there is no released otr plugin based on the beta one that's
> been around for ever.  If this is really the case the top-level web page
> should explain it - I expected to find pidgin-otr-3.0.0 and haven't been
> able to.

As above, pidgin-otr-3.1.0 will appear next week.

> 4) I found Ian's message about preview2, and downloaded it.  It would be
> good to use 3.1.0a2 to follow normal conventions for prerelease
> software, and to have the directory name match the version name, so that
> packaging software that assumes it will match won't need adjusting.
> Right now 3.1.0-preview2 unpacks into 3.1.0.

I did that sort of on purpose; -preview2 isn't meant to be an alpha
release.  It's meant to be something which structurally will be
identical to the upcoming release.  That way, packagers can see if
there's something broken that I'd need to fix before the 3.1.0 actual
release.

> 5) pidgin-otr-3.1.0 seems to need libotr-3.1.0.  While this might really
> be necessary, it would be really nice to decouple gui issues from core
> protocol issues, and to only depend on released libraries - even for
> unreleased plugins.  It's awkward to test pidgin-otr-3.1.0 while not
> breaking gaim-otr-3.0.0 on the same system.  (I'd hope that 3.1.0 is API
> and ABI compatible, but you'll forgive me for not being confident in
> this given all of the above.)

Indeed, installing libotr-3.1.0 will not break an existing
gaim-otr-3.0.0.  pidgin-otr-3.1.0 naturally requires libotr-3.1.0, since
it uses the library's new features.

> <pause to update libotr to 3.1.0-preview2, allowing for changing the
> name and pointing pkgsrc at the unpacked location>
> 
> 
> I really appreciate all the work that's gone into OTR, and I use it
> daily.  Sorry if I'm sounding cranky, but a bit more care in making
> things packaging friendly and being careful to avoid confusion would
> make it more likely that more people can get OTR more easily.
> 
> 
> The good news is that after updating libotr (which only needed a version
> change and a single new .h), and adjusting the former gaim-otr package
> for pidgin-otr (naming changes only), the plugin works.  This is on
> NetBSD-current on i386 with pretty recent gnome/gtk/glib/etc and pidgin
> 2.0.1.  Just to be clear, this is a full test of the plugin as built by
> the packaging system, and my only real issues were 4 and 5 above, both
> quite minor.

So when pidgin-otr-3.1.0 and libotr-3.1.0 get released for real next
week, they'll build cleanly on NetBSD?  That's good to know.

Thanks!

   - Ian



More information about the OTR-dev mailing list