cryptodotis / irssi-otr

LibOTR functionality in Irssi.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Packaging

DrWhax opened this issue · comments

Provide packaging for .deb's and RPM's.

Someone from the otr-dev list is willing to package it for fedora \o/
Still searching for a deb packager!

Wouldn't the existing package work for this?

http://packages.qa.debian.org/i/irssi-plugin-xmpp.html

If this is not a complete rewrite, then porting the package should be relatively trivial.

I think you mean to add irssi-xmpp support to irssi-otr? It might even work out of the box, not sure. Worth testing indeed!

Er. That's not what I meant at all, sorry, I meant to point to:

http://packages.qa.debian.org/i/irssi-plugin-otr.html

The maintainer of that package should probably be contacted directly.

So, we did, a year ago, then he popped up about a month ago for a short while and now he's gone again... :-/

Well in any case this work is still there, we can just reuse the debian/ directory from that project... I'd be happy to work out the logistical details on the debian side, as I am a debian member.

I've exchanged email with a Fedora packager saying that we should probably change name for the package because, at the moment, "irssi-plugin-otr" does MORE and is bound to libotr3 as well.

So we might want to change the naming scheme to I don,t know "irssi-plugin-otr4" to indicate 4.x support

Thoughts?

What does plugin-otr do that otr4 doesn't?

irssi-plugin-otr4 seems fine, although note that libotr is called libotr5 in debian, confusingly enough.

Is that the entire package from ulim together with xchat/weechat-otr?

FYI, I created an Arch Linux package for the git version.
It's available in the AUR:
https://aur.archlinux.org/packages/irssi-otr4-git/

I'll wait for the next "official" version to come out to create a "versioned" package.

sweet! thanks so much!

Yeah, the current Debian package also builds xchat-otr. We could use a different name, but in any case we need to talk to the current maintainer.

Yeah, imho, it's quite odd that they allowed something like xchat/irssi-otr under an irssi-otr package name, quite confusing. Anyway, I agree it should change name's. Irssi-otr meanwhile got packaged into fedora core 18 (https://people.redhat.com/pwouters/otr/) with the name irssi-plugin-otr. Which make's sense, however, it got the same name under ubuntu, but that; s still the old package. I guess we should ping distro package maintainers if they are willing to deprecate the old packages.

It's actually quite common: sometimes a "source package" is used to generate multiple "binary packages" which have actually different names. The irssi-plugin-otr binary package doesn't support xchat-otr, but both packages are built from the same source package.

Actually, it seems that this issue was already mentionned with the current package maintainer, here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695150

I'll followup there and try to ping.

Oh, and what would be the version number when we go stable here? We go boldly to 1.0? Or we followup with the previous upstream (0.3) and release 0.4?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Going to 1.0.

That is the goal since right now it's tagged as 1.0-alpha1

Thanks!

anarcat:

Oh, and what would be the version number when we go stable here? We
go boldly to 1.0? Or we followup with the previous upstream (0.3)
and release 0.4?

— Reply to this email directly or view it on GitHub
#11 (comment).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCgAGBQJQx5yZAAoJEELoaioR9I027MIIALa28n3KzRTZhH3wi2C58KSr
UMbyvXRLAMlId0dVAxOm01/3UXNrypcEGJsnAvSFBEu4DuuEulh2alpIxyEy6YF9
kZXvhWkZQXqiTLYGNJLwFE7t3yqJeR0QNLK858UazFe7XklFRqXZE1FPU9xUH8x6
jk/uFML3gc6ab15U8il2Cda3MV3ssj+n85oC+YtuWbYfeOKLOod1iMZv/FX1oLiF
ZG7xe4fPYZ/4Y9rgC5NCQNRg5MdsVtHNK7OaQyHQNqN1e4cz6ktabzqPe6f1PsrG
WHTM3xUs8pEYkuq3MV3hdmlzK2gB/66BuIhaWh3wDJmPkEpXQp4cY602IxQwp6w=
=Ni/V
-----END PGP SIGNATURE-----

I assume this is now about other packaging systems since Debian is mostly done and followed up in a dupe (#26).

Correct, I think we should ping our other package maintainers at some point to provide an up-to-date package!