A new version of hspell was just released. The build system changed since 0.7, so I went ahead and made a new ebuild, attached below.
Created attachment 48347 [details] hspell-0.9.ebuild
Looking at the WHATSNEW file I realized that hspell is now linked against zlib, so sys-apps/zlib should be added to DEPEND.
This is a much-needed update -- please add the ebuild to Portage.
Works for me nicely.
Created attachment 59470 [details] Another version of 0.9 ebuild
Created attachment 59475 [details] With proper dependencies
Why don't you update portage?
Created attachment 72296 [details] Fixed ebuild for hspell-0.9 Added --enable-fatverb to configure options. Fixed the dependencies to use zlib instead of external gzip process for compressed dictionaries if present on system. Fixed typo in dodoc directive: should be WHATSNEW
Created attachment 75760 [details] Updated metadata.xml Updated metadata.xml to include proper bugzilla herd alias.
Kde 3.5.x need it!: The development package of Hspell is not installed, I couldn't find hspell.h. Spell-checking Hebrew with libhspell will not be available. If you need it, install hspell >= 0.9 from sources see http://www.ivrix.org.il/projects/spell-checker/ or from packages your distribution provides.
*** Bug 114404 has been marked as a duplicate of this bug. ***
no love
In reply to comment#12: Is this because of app-dicts/myspell-he, or because no maintainer was found? Since there is already a new version 1.0 at http://ivrix.org.il/projects/spell-checker/
User requests your input.
In case anyone is interested in this, I made a patch[1] to hspell-1.0 to use automake and libtool, and I submitted it upstream[2]. I would imagine that this may be helpful on several platforms wrt pic/nonpic issues. [1] http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/libs/hspell/hspell-1.0-2.src.patch [2] http://www.ivrix.org.il/bugzilla/show_bug.cgi?id=4
Hello, Before it is removed, can anyone tell us why can't it make its way into portage?
(In reply to comment #16) > Hello, > Before it is removed, can anyone tell us why can't it make its way into > portage? Packages go into/remain in the portage tree when an active Gentoo developer maintains it in the long term. One trigger for removing existing packages is open bugs on packages with no active maintainer. When the package is masked, that causes notices for anyone who uses it - so if there are any active Gentoo developers using it they might take it on. That's why the removal is scheduled for a month after the masking; to give time for someone to step up. Even if no Gentoo developer takes it on, and it is thus removed from the tree, you can still maintain it yourself locally in an overlay so you don't need to lose it - however Gentoo devs won't be supporting it (which is what it means to be in the tree).
Not an issue for the kde team - maybe app-dicts decides to pick this up? toto, Alon or anyone else who is interested: It's really only up to having people, who actually do
Not an issue for the kde team - maybe app-dicts decides to pick this up? toto, Alon or anyone else who is interested: It's really only up to having people, who actually do¹ the work. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2
(In reply to comment #17) > Even if no Gentoo developer takes it on, and it is thus removed from the tree, > you can still maintain it yourself locally in an overlay so you don't need to > lose it - however Gentoo devs won't be supporting it (which is what it means to > be in the tree). We all know that. The question is why this kind of simple package cannot be maintained, as any other simple packages are... When a new version is out some of us (users) opens a bug/feature request and attaching the patch. This way I work with a lot of packages that the gentoo developers aren't so interested of... And it works. Notice how simple this ebuild is... It has nothing special, there is no maintenance work. And the Hebrew user community requires this. When you (gentoo developers) complete portage so you can put several overlay URLs in make.conf, I guess Gentoo will be forked into many overlays that are maintained much better than current tree (base, kde, gnome, Hebrew, X11 etc...). But until then, local overlays are not the answer.
(In reply to comment #19) > The question is why this kind of simple package cannot be maintained, as any > other simple packages are... Actually this is why the treecleaner team has been formed. Developers come, introduce packages to the tree, leave later and since no one else is caring for these packages they simply rot; this cannot be the status quo forever. > Notice how simple this ebuild is... It has nothing special, there is no > maintenance work. And the Hebrew user community requires this. I'm quite sure there are interested, hebrew speaking developers out there... > But until then, local overlays are not the answer. Defintely not. See my previous comment to what is needed.
(In reply to comment #20) > (In reply to comment #19) > > The question is why this kind of simple package cannot be maintained, as any > > other simple packages are... > > Actually this is why the treecleaner team has been formed. Developers come, > introduce packages to the tree, leave later and since no one else is caring > for these packages they simply rot; this cannot be the status quo forever. No they are not... When there are users who care the packages are alive. The latest good example is sys-fs/loop-aes, for the last year I am providing version bumps, all the gentoo developer does is adding the stuff into portage. When I requested it to be stable I got the following response: bug#145283. I also provide bumps of sys-apps/pcsc-lite (last bug#124867) app-crypt/ccid (last bug#145110). There are more... I won't list them all. The conclusion should be not to remove a package if there is no Gentoo developer that promotes it, but remove it if the package it-self does not have supporting user community or upstream stopped development. > > Notice how simple this ebuild is... It has nothing special, there is no > > maintenance work. And the Hebrew user community requires this. > > I'm quite sure there are interested, hebrew speaking developers out there... I guess you cannot judge end-user requirements by the subset that is called "gentoo developers" :) The policy should be centrally outline user requirements and cover it using developers... Not relay on the developers good will... There are always a more interesting packages out there to maintain... And if credit is given to the developer that maintain the most complex/usable packages there is no motivation to support niche packages. > > But until then, local overlays are not the answer. > > Defintely not. See my previous comment to what is needed. It seems that I missed it... Which comment do you refer?
committed this and fixed a few things, the patch does not build. Alon: you are now maintainer, ask me when you want to commit something. Thanks everyone
Thank you so much!!!
Genstef, add yourself to metadata.xml
I see someone added hspell into package.mask, I guess one step before it is going to be deleted from the tree... But I thought that we have saved its life during this bug... What else can be done in order to save its life?
(In reply to comment #25) > I see someone added hspell into package.mask No, someone just fixed the typo in package.mask so it actually has some effect now.
(In reply to comment #26) > (In reply to comment #25) > > I see someone added hspell into package.mask > > No, someone just fixed the typo in package.mask so it actually has some effect > now. > So what can be done in order to remove it fro package.mask?
(In reply to comment #27) > > So what can be done in order to remove it fro package.mask? Are the outstanding bugs fixed in current CVS ? If yes, feel free to ask Alec or myself to remove it from package.mask (as genstef isn't around for a week).
(In reply to comment #27) > So what can be done in order to remove it fro package.mask? I just removed the according package.mask entry.
Isn't p.masked anymore.
Took ownership. Thanks.
