The current stardict-3.0.1 ebuild will build stardict with qqwry support, but won't download and install the required QQWry.Dat file. So, I've added a qqwry useflag that installs it. qqwry is some type of IP database. However, it appears to be in chinese language, or something like that. Considering that some people might find it useful, I think the useflag is the way to go. I've also added a "dodoc" command to add some documentation that is not installed by "make install". These are just 4 plaintext files. I'm attaching a diff to the current ebuild. Please take a look and update the ebuild in portage. It could also be possible to add a useflag to download and install WyabdcRealPeopleTTS, or maybe it would be better to add a new ebuild for it. It's a huge pack (81MB) of wav files. See http://stardict.sourceforge.net/download.php Well, in addition to these improvements, I think we can also do some cleanup. The "files/stardict-gentoo.patch" file can be safely deleted, because it is for stardict-1.3. There is also "files/stardict-gtk24.patch" which is for stardict-2.4.2, but does not follow the same naming convention of other patches. So I suggest to either rename this file or remove it and the 2.4.2 ebuild.
Created attachment 149891 [details, diff] stardict-3.0.1.ebuild.diff My proposed changes. They work for me.
Oh, I just found that "play" command gives corrupted sound here, while "aplay" works well. Maybe we should write a patch to change the default "play" to "aplay"?
Thank you for report Denilson. Take a look at just committed stardict-3.0.1-r1 it should contain most of fixes you suggest. The only change I've decided to ignore was to change play to aplay as I failed to reproduce/experience any problems with play and that is play bug in any case. If there is anything else we could improve, fill in new bugs! Thank you again.
(In reply to comment #3) > If there is anything else we could improve, fill in new bugs! I hope you don't mind if I post more comments/improvements in this bug (and reopen it). And these are really just small improvements (one about festival use flag, and another about qqwry use flag). Right now I wonder about the usefulness of festival useflag. It only adds a dependency, nothing else. So, maybe someone tries to enable this useflag, and only then finds that the plugin has not been built. Maybe that conditional message should be made unconditional. Maybe the useflag could be removed. I think that there should be an explanation why the festival plugin is disabled. Does it fail to compile? Does it segfault? I remember I read somewhere the reason why it is disabled (maybe inside stardict sources/docs?), but unfortunately I've already forgot why. $ euse -i festival [- ] festival (app-dicts/stardict): Enable festival text to speach plugin Hum... The festival description is a lie! The plugin is *not* being enabled. ;) $ euse -i qqwry [- ] qqwry (app-dicts/stardict): Enable QQWry plugin, which provides information about geographical position, owner, etc. for IP address I think you should say that qqwry displays information in chinese language. Otherwise, people will just enable it, look at that strange language, say WTF?, and then disable it. That's all. Thank you for improving stardict on portage.
(In reply to comment #4) > Right now I wonder about the usefulness of festival useflag. Yes it just enables dependency... I see no problem with this. > I think that there should be an explanation why the festival plugin is > disabled. Does it fail to compile? Does it segfault? This's is described, read comments inside ebuild :) > $ euse -i festival > [- ] festival (app-dicts/stardict): > Enable festival text to speach plugin > > Hum... The festival description is a lie! The plugin is *not* being enabled. Ok, I've changed wording so now it does not states that we install plugin. > $ euse -i qqwry > [- ] qqwry (app-dicts/stardict): > Enable QQWry plugin, which provides information about geographical position, > owner, etc. for IP address > I think you should say that qqwry displays information in chinese language. Ok, I've added this too. Fixed again. Enjoy. :)
hmm, cleaning up the ebuild is good but unconditionally checking the use flag of a library not necessarily installed (no hard dependency on libgnome, only with gnome use flag) is really really bad as it breaks the ebuild for people not having installed gnome (or libgnome)
(In reply to comment #6) > but unconditionally checking the use flag of a library not necessarily > installed (no hard dependency on libgnome, only with gnome use flag) is really > really bad as it breaks the ebuild for people not having installed gnome (or > libgnome) This was reported this morning in bug #219631 and was already fixed.
