FYI. It's got some nice changes that I became aware of when trying to actually work on an app using it.
I assume that you'll want this patched with the enchant patch so we aren't taking a step backwards from 2.0.4-r1. I'll try and get the patch to work and test thing s out and post an ebuild.
iirc there's a cvs branch enchant enabled
Yes that is the gtkspell3 module. It has some other feature changes as well. They are sorting some things out before releasing it.
Have you made any progress in this? I need this version as dependency.
No I haven't. The 2.0.4 enchant patch does not fit into 2.0.5 and I don't have time to try and manually patch it and get a new diff.
Is it not a possiblity to just release a non-enchant-ized 2.0.5?
I think thats a regression, so not a good idea. I wonder why you need 2.0.5 lucas, it's API stable isn't it .. older versions likely would do ?
A possible solution would be to take a snapshot from the enchant enhanced tree.
foser: a newer version of net-im/kf depends on it, but i see that after patching configure script, kf works also with the older version.
rizzo: by the way, if you have no objection, i'll add myself to metadata.xml of net-im/kf as a maintainer.
Lukas feel free to take over net-im/kf.
Now gtkspell-2.0.6 is out.
foser I don't think of it as a regression, since the enchant stuff isn't even in their gtkspell2 tree. It was added by us. From an API point of view nothing is lost if gtkspell uses aspell vs enchant anyway, and no apps should expect it since gtkspell doesn't come with it.
Created attachment 34310 [details]
FWIW, here is an ebuild for 2.0.6, based off of 2.0.4 without the patches, and
including support for internationalization with gettext, which is new in 2.0.6.
that would be a regression afaic, since this version isn't really needed i'd rather wait for an enchant enabled release.
Created attachment 41774 [details, diff]
Patch to enable enchant in gtkspell-2.0.7. Please test and report back.
$ cvs -z3 -d:pserver:email@example.com:/cvsroot/gtkspell co -r
$ cvs -z3 -d:pserver:firstname.lastname@example.org:/cvsroot/gtkspell co
$ mv gtkspell3/gtkspell-3.0.pc.in gtkspell3/gtkspell-2.0.pc.in
$ grep -rIl gtkspell-3.0 gtkspell3 | xargs sed -i -s -e
$ sed -i -e 's:3.0.0cvs:2.0.7:' gtkspell3/configure.ac
$ diff -rupdN -x CVS -x COPYING -x .cvsignore -x ChangeLog gtkspell2 gtkspell3
The playing around with .pc files and versions is necessary to ensure that this
patched gtkspell still fills the 2.0 slot pkgconfig-wise.
This may become a problem if and when gtkspell3 diverges API-wise from
gtkspell2 - this has not happened yet; the only change to headers is licensing
(GPL to LGPL).
Changes to ebuild:
* add enchant dep
* license is now LGPL-2.1 (!!)
* apply patch, autoconf is already in ebuild
I ran up against bug 58161 (.so not being appended to solibs): if this is a
general problem (and not a problem with my system) then run libtoolize -f ||
die before autoconf.
Created attachment 41775 [details]
Just a note that the newer tomboy releases prefer to have at least gtkspell-2.0.9, since there is some fix in 2.0.9 that they use. I can dig up details of what exactly was fixed if people would like.
You will be waiting for quite a while for an enchant-enabled release. I've been speaking with noif (the gtkspell developer) probably every week about it since I'm waiting for it to work on gaim's spell checking methods. There is much that needs discussion and decision before he'll even venture a guess at an ETA for gtkspell3.
Restating my desire to just abandon the enchant patch and add gtkspell-2.0.8 to portage. The enchant patch is not supported in gtkspell2 upstream nor here.
Resistance is futile.
Just putting my vote for the enchantless release. In generall Gentoo should aim for vanilla releases as much as possible.
foser: Why did you add the patch? In what way would it be a regression to remove it. Is there any pacakge depending on the patch?
I'm not a dev, but what happened to this part of the Dev Handbook:
> Try to not make ebuilds preform unnecessary steps. Packaging unsupported patches
> as an "addition" is a bad idea unless they are thoroughly tested by you, widely
> used, and audited for security vulnerabilities.
In the end, the gtkspell enchant patch is not supported upstream, not supported here, apparently not supported by enchant itself (the apparent source of our original patch, but it hasn't been updated since Dec. 2003), and I wonder if other distros support it either (debian doesn't, and googling didn't turn up much else).
Bottom line: let's admit that we can't support this patch -- which we haven't for over a year -- and go back to the vanilla gtkspell. If someone is really interested/bored/whatever, then make a separate ebuild for gtkspell-3 (preferably SLOTted), and maybe we can help the upstream devs with gtkspell3 more than we will by getting stuck on a year-and-a-half old patch.
Created attachment 55405 [details]
OK, so I went ahead and did it myself, and while doing so found a packaging bug
which affects gtkspell2 as well.. Here's an ebuild for a vanilla gtkspell2,
with a patch for gtk-doc detection and installation of the .devhelp file.
Created attachment 55406 [details, diff]
Created attachment 55407 [details]
And here's an ebuild for gtkspell3 from cvs. I just checked out the code from
cvs and tarballed the module directory as-is; the date is based on the most
recently changed files. This needs two patches, see below.
Created attachment 55408 [details, diff]
This does the same thing as the 2.0-gtk-doc.patch, but for the cvs sources.
Created attachment 55409 [details, diff]
This patch makes sure that everything is parallel-installable, to allow for the
separate ebuild SLOT.
In the end, I don't know whether this should be imported to the tree (p.mask'ed
of course) or not, but maybe someone will find it helpful.
Re comment 12: the COPYING file in the CVS sources is still GPL-2.
Forgot to mention that enchant needs to be bumped (manually atm) to 1.1.6 for the 3.0 ebuild; it requires an API introduced in that version. A simple rename and digest wfm.
Actually, an enchant bump was already requested in bug 87370.
Comment #18 said it perfectly for me.
Here is a rework of Dom L.'s enchanting of gtkspell.
(I've emailed this to dom as well.)
Hopefully I can get 2.0.10 in my desktop now ;)
Created attachment 59633 [details, diff]
Patches enchat 2.0.10 to use enchant
(In reply to comment #29)
> Created an attachment (id=59633) 
> Patches enchat 2.0.10 to use enchant
I'd rather see our gtkspell2 package purged of the enchant taint.
well, for what it's worth the patch is pretty simple.
The only two files of note that get patched are configure.ac and gtkspell.c
All I really want is gtkspell 2.0.10 in my portage.
If needed, I'll make sure the patch applies to all the gtkspell2s.
Don, if I were to make an ebuild option for using enchant or not, would that
satisfy everyone and allow gtkspell 2.0.10 to go into portage?
gtkspell 2.0.11 is now available.
Created attachment 64099 [details]
Crafted a GtkSpell 2.0.11 ebuild, no support for Enchant.
Please, whatever you just DECIDE already, GtkSpell 2.0.4 was released in the
beginning of 2003!
gtkspell-2.0.11 has been added with the patch from drew (and a minor bugfix to it)
Fails to compile for me with this error:
../gtkspell/.libs/libgtkspell.so: undefined reference to `enchant_dict_add_to_pwl'
However, I believe that to fix that we should just replace this function (in the
patch) with enchant_dict_add_to_personal (PWL stands for personal word list).
Created attachment 64834 [details, diff]
Okay, sorry, I was too quick to jump to conclusions. Here's the deal:
enchant_dict_add_to_personal was deprecated in enchant-1.1.6 in favour of
enchant_dict_add_to_pwl (which the patch uses). I think that gtkspell-2.0.11
should just depend on >=enchant-1.1.6, and that enchant-1.1.6 should be marked
stable (current stable version for x86 is 1.1.5).
I updated the enchant dep in gtkspell, thanks for catching that.
Works perfectly for me, on x86.