The current version, 4.5-r1, has dead links all over, I doubt an install is possible. Please go to http://www.dicollecte.org/download.php?prj=fr http://www.dicollecte.org/grammalecte/telecharger.php to see which download and project links should be used. I guess http://www.dicollecte.org/grammalecte/oxt/lo-oo-ressources-linguistiques-fr-v5.7.oxt would be the most convenient download link, currently. I think that another bug report, Bug 607078 can be subsumed under this one. It doesn't make sense to put effort in modifying the old version's ebuild, given the necessity for a new one.
Unfortunately this package has no current maintainer - are you interested? https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
Created attachment 461536 [details] bumped ebuild In the current version for 4.5, there was some renaming happening for the hyph and thes files, with an unclear comment as to why. I prefer to have the ebuild do as little as possible as long as the files are picked up by the client packages (LO, FF, KDE, etc.). In that vein, I would consider any renaming, even to indicate a default variant, as currently is still being done. I'll contact upstream to find out how I can actually test the hyph and thes files, as currently I've only tested the spelling corrector files (in KDE 4/5 and Thunderbird).
Created attachment 461538 [details] metadata.xml under the assumption that I proxy-maintain
(In reply to Michael Palimaka (kensington) from comment #1) > Unfortunately this package has no current maintainer - are you interested? > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Well, I think an update of the package is necessary. The current version is probably only still available on Gentoo mirrors. Also, I think I can do a decent job of getting an ebuild that is close to decent and interact with upstream as needed. However, currently eclasses are still magic for me and I don't have the time or inclination to learn much about them. I took a look today and from https://devmanual.gentoo.org/eclass-reference/myspell-r2.eclass/index.html and https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/myspell.eclass I don't learn much (and wonder whether some of the stuff in the latter file can be trimmed out) on first sight. (Also, for the former, the title is still aspell-eclass, but perhaps they are the same.) So, to answer your question: perhaps. I think it may work because I have a personal interest in the package and it seems simple enough. (I tried proy maintaining a Python package at some point and couldn't put in the effort in the end.)
Created attachment 461602 [details] bumped ebuild In this second try, I've removed all renaming, keeping the variant names intact as intended by upstream, which makes the ebuild as simple as possible. Also, I've put EAPI=6. I've noticed that the installed files are not picked up by LibreOffice(-bin), but the same holds for my other installed spelling packages, so I guess this is a general thing and perhaps even intentional.
(In reply to Erik Quaeghebeur from comment #2) > > I'll contact upstream to find out how I can actually test the hyph and thes > files, as currently I've only tested the spelling corrector files (in KDE > 4/5 and Thunderbird). Upstream doesn't know how to test that. Which packages use the hyphenation and thesaurus? (LibreOffice doesn't pick up any file, so I suppose one is supposed to install a dictionary pack in $HOME.) It would be useful to have someone with actual experience with these myspell packages involved, perhaps a previous maintainer who is willing to write out some relevant stuff?
(In reply to Erik Quaeghebeur from comment #6) > Which packages use the hyphenation and thesaurus? (LibreOffice doesn't pick > up any file, so I suppose one is supposed to install a dictionary pack in > $HOME.) LibreOffice only picks up generic names, which include countries. The thesaurus and hyphenation do not work in LibreOffice now, because a previous maintainer added "_v3" suffixes (and "_v2" suffixes to myspell-en, and probably other suffixes elsewhere too). Your ebuild would not work for the main dictionary, because there is no fr_FR.dic and fr_FR.aff, and the thesaurus and hyphenation would not work, because they do need to be moved to using fr_FR. (I only tested libreoffice-5.2.3.3-r1, the current stable version... maybe newer versions do support simply "fr"... but Firefox, Gedit, etc., would have to be tested too). There should be these files: fr_FR.dic (from fr-toutesvariantes.dic, the most general dictionary) fr_FR.aff (from fr-toutesvariantes.aff, the most general affix file) hyph_fr_FR.dic (from hyph_fr.dic) th_fr_FR.dat (from thes_fr.dat) th_fr_FR.idx (from thes_fr.idx) ... then symlinks to these files using fr_BE, fr_CA, fr_CH, and fr_LU, if you want to support them (as per http://www.dicollecte.org/thread.php?prj=fr&t=266 these files do support variations from other countries, and people who don't want to fill their dictionary list with variants they don't use, can always use INSTALL_MASK). Dealing with the three other variants (fr-moderne, fr-classique, and fr-reforme1990) might be a bit of a pain. I suppose they could be installed as is, for people who really want them (and again, people who don't want them can use INSTALL_MASK so they are not installed). But I don't think they will be detected by LibreOffice, at least. Having separate ebuilds would add to the maintenance cost, and wouldn't solve the default-variant issue, unless also adding an `eselect` module to manage symlinks... There could be new local USE flags, I suppose... They would all still be installed, but a single variant could be selected through the USE flags, to be set as the default...
Ryoto Yayame, thanks for your input. (In reply to Ryoto Yayame from comment #7) > LibreOffice only picks up generic names, which include countries. Indeed, you are correct. (But why is LibreOffice so restrictive? Sigh…) > The thesaurus and hyphenation do not work in LibreOffice now, because a > previous maintainer added "_v3" suffixes (and "_v2" suffixes to myspell-en, > and probably other suffixes elsewhere too). Ok, so I should make sure this is fixed in the version I'm preparing. > (I only tested libreoffice-5.2.3.3-r1, the current stable version... maybe > newer versions do support simply "fr"... but Firefox, Gedit, etc., would > have to be tested too). I'll inquire upstream. Firefox picks up all variants. > There should be these files: > > fr_FR.dic (from fr-toutesvariantes.dic, the most general dictionary) > fr_FR.aff (from fr-toutesvariantes.aff, the most general affix file) I guess it should be fr-classique, as this is the variant recommended by the creators.. > ... then symlinks to these files using fr_BE, fr_CA, fr_CH, and fr_LU, if > you want to support them (as per > http://www.dicollecte.org/thread.php?prj=fr&t=266 these files do support > variations from other countries, and people who don't want to fill their > dictionary list with variants they don't use, can always use INSTALL_MASK). Hmm, INSTALL_MASK does not make sense for multi-user systems. A user-specific solution would be better. (In any case, INSTALL_MASK is practically undocumented, so for ‘unsophisticated’ users like me, it's not obvious how to correctly use it.) > Dealing with the three other variants (fr-moderne, fr-classique, and > fr-reforme1990) might be a bit of a pain. I suppose they could be installed > as is, for people who really want them (and again, people who don't want > them can use INSTALL_MASK so they are not installed). But I don't think they > will be detected by LibreOffice, at least. Having separate ebuilds would add > to the maintenance cost, and wouldn't solve the default-variant issue, > unless also adding an `eselect` module to manage symlinks... There could be > new local USE flags, I suppose... They would all still be installed, but a > single variant could be selected through the USE flags, to be set as the > default... The oxt file the dictionary files are extracted from contains code just for the purpose of making it possible to select the preferred variant in LibreOffice. I think it would be best to try and enable that functionality instead of messing with the dictionary files' names. Multiple ebuilds don't make sense here, I agree. USE flags for the variants have the same downside INSTALL_MASK has. Given that language variant masking should be a per-user thing (on a multi-user system), I'm wondering whether it is possible to have dictionary files be accessed through a directory under ~/.local/ somewhere, which could initially just be a symlink to /usr/share/myspell or /usr/share/hunspell; or be ‘override if present’. (Some programs, such as Kate, seem to look in the hunspell directory and not the myspell one.) An eselect module to manage the symlinks under ~/.local/ would be a nice extra, but not essential.
(In reply to Ryoto Yayame from comment #7) > LibreOffice only picks up generic names, which include countries. I've been investigating a bit. Yes, for files in /usr/share/myspell (or is it /usr/share/hunspell). But, this is because no dictionaries.xcu is associated, which is normally the case when installing the dictionaries as an extension. I'm now trying to find out whether these xcu files (and perhaps some description-containing xml files) can be included in a system-wide fashion. More info: the xcu files contain mappings from files to locales (next to other info).
(In reply to Ryoto Yayame from comment #7) > The thesaurus and hyphenation do not work in LibreOffice now, because a > previous maintainer added "_v3" suffixes (and "_v2" suffixes to myspell-en, > and probably other suffixes elsewhere too). I looked at this and despite the suffixes, the thesaurus and hyphenation is detected. From the LO mailing list, I gathered from RedHat people that they also have such (namely ‘_v2’) suffixes, but that it shouldn't make a difference.
(In reply to Erik Quaeghebeur from comment #9) > (In reply to Ryoto Yayame from comment #7) > > LibreOffice only picks up generic names, which include countries. > I've been investigating a bit. Yes, for files in /usr/share/myspell (or is > it /usr/share/hunspell). Not picking up fr.dic may be an LO bug, as ‘fr’ is a perfectly valid bcp47 tag. > I'm now trying to find out whether these xcu files (and > perhaps some description-containing xml files) can be included in a > system-wide fashion. We can unzip the xto files to subdirectories of /usr/lib64/libreoffice/share/extensions/ to do justice to the content in xto files beyond the plain dictionaries. In this case, for the French dictionaries, it's almost required. I guess this would require a libreoffice use flag for many app-dict/myspell-* ebuilds and ‘complex’ linking to /usr/share/[hunspell,mythes,hyphen]. This goes over my head and I guess would require updating the eclass. Feedback from a Gentoo dev is welcome now. Also, I've just investigated LO for now, but don't know how all other client packages deal (or not) with fr-whatever. I know Firefox and KDE deal with it reasonably well. So input about other DEs and applications (abiword, emacs, vim,… the list is probably large) is welcome.
Created attachment 464338 [details] bumped ebuild Version 6.0.2 is out, so I'm moving forward with that. I've updated the ebuild, also after getting input from LibreOffice developers. The result is that for now, the plan is to install the files to /usr/share/hunspell with the variants modified so that they satisfy bcp47 rules. This should make Firefox display them more nicely. This has been implemented in this version of the ebuild already. Then, I'd need to change the links in /usr/share/myspell so that I remove links to all variants except for the recommended one (which I've renamed to fr in the previous step) and rename those to fr_FR so that LibreOffice picks it up. Trying to support all variants in LibreOffice as the extension does by installing extra Python code is way above my competency, although it can be done in a clean system-wide way, see <https://lists.freedesktop.org/archives/libreoffice/2017-February/076943.html>. However, currently this ebuild fails: * ERROR: app-dicts/myspell-fr-6.0.2::ownDevel failed (prepare phase): * eapply_user (or default) must be called in src_prepare()! * * Call stack: * ebuild.sh, line 767: Called __ebuild_main 'prepare' * phase-functions.sh, line 1007: Called __dyn_prepare * phase-functions.sh, line 382: Called die * The specific snippet of code: * die "eapply_user (or default) must be called in src_prepare()!" So developer guidance on fixing this and telling me how to do the deletion/renaming of the links out of /usr/share/myspell is appreciated.
Created attachment 464370 [details] bumped ebuild I fixed the forgotten eapply_user in src_prepare(). I also dropped the idea to work with modified links for now, as also files in /usr/share/mythes and /usr/share/hyphen need to bow to LibreOffices fickleness. So the attached ebuild is essentially an updated version of the one in-tree with the following corrections: * bcp47-ify the variants so that Firefox and Thunderbird like them * don't add v3 suffix to hyphen, as it needs none and breaks LibreOffice * don't add v3 suffix, but v2 suffix to thesaurus files as LibreOffice needs those I've documented the ebuild, to make clear why what is done. In short: this is an all-over improvement of the current in-tree ebuild and should be put in its stead immediately ;-).
I've added an updated ebuild and metadata file for 6.3 to my overlay: https://github.com/equaeghe/gentoo-overlay/tree/master/app-dicts/myspell-fr Again: this ebuild is a clear improvement over the in-tree one and I'd prefer for it to be included in the tree rather than me maintaining it in an overlay.
At first sight, the pull request does implement any of the lessons learned in this bug. Unless LO has fixed all the bugs related to dictionary detection (AFAIK, it has not), the renamings are really necessary. Also, the variant suffixes need to have a length <8, I think. In any case, please have a look at my 6.3 ebuild and consider implementing the renamings done there.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d3bb5003a8cb2649f71a91373e4006d18db3e9f3 commit d3bb5003a8cb2649f71a91373e4006d18db3e9f3 Author: Marco Scardovi <marco@scardovi.com> AuthorDate: 2021-06-15 13:50:52 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-10-26 05:56:31 +0000 app-dicts/myspell-fr: bump to 7.0 Closes: https://bugs.gentoo.org/607084 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Marco Scardovi <marco@scardovi.com> Signed-off-by: Joonas Niilola <juippis@gentoo.org> app-dicts/myspell-fr/Manifest | 1 + app-dicts/myspell-fr/myspell-fr-7.0.ebuild | 37 ++++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+)
This bug should not have been closed. The current in-tree ebuild makes mistakes that were described in this bug report and fixed in my proposed ebuild. The current in-tree ebuild also points to a download location that does not exist anymore. My ebuild is also now updated for 7.0: https://github.com/equaeghe/gentoo-overlay/tree/master/app-dicts/myspell-fr It uses a working download location and includes all the fixes from this bug report.
Could you make a Github pull request adding that version? Or make a git format-patch type file that can be applied to our git tree? Note that no one gets email notifications for "maintainer-needed" packages, but pull requests for maintainer-needed are handled.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=12027621555a33241b3d3c9280af332dff9ec67c commit 12027621555a33241b3d3c9280af332dff9ec67c Author: Erik Quaeghebeur <gentoo@e3q.eu> AuthorDate: 2022-09-26 04:50:41 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-09-27 11:42:39 +0000 app-dicts/myspell-fr: add corrected 7.0 version as r1 revision Signed-off-by: Erik Quaeghebeur <gentoo@e3q.eu> Closes: https://bugs.gentoo.org/607084 Closes: https://github.com/gentoo/gentoo/pull/27469 Signed-off-by: Joonas Niilola <juippis@gentoo.org> app-dicts/myspell-fr/Manifest | 1 + app-dicts/myspell-fr/metadata.xml | 6 ++- app-dicts/myspell-fr/myspell-fr-7.0-r1.ebuild | 73 +++++++++++++++++++++++++++ 3 files changed, 79 insertions(+), 1 deletion(-)
