Current ebuild [gimp-help-2.10.0.ebuild] is pegged at python 2.7. When executed, ebuild will compile all defined (18 different) languages. Python 3 ability can be achieved by applying patch attached to gimp-help gitlab issue #201 (https://gitlab.gnome.org/GNOME/gimp-help/-/issues/201). Language ability is added by adjusting the ebuild file. (see attachments). Reproducible: Always
Created attachment 642390 [details, diff] patch to ebuild to add language and py3 ability
Created attachment 642392 [details, diff] patch file to gimp-help sources to enable python 3 building
The urgency if this is doubtful as long as every release version of gimp itself depends on py27 anyway. So might as well wait for upstream to commit this to their repository.
(In reply to Andreas Sturmlechner from comment #3) > The urgency if this is doubtful as long as every release version of gimp > itself depends on py27 anyway. So might as well wait for upstream to commit > this to their repository. media-gfx/gimp is currently being shown as py2.7 or py3.6 -> .8. app-doc/gimp-help was pinned to py2.7 ONLY. Point of this was to add py3 ability as well as adding ability to select/limit language(previous was to build all languages). Yeah, no rush.......
> LANGUAGE As I know l10n.eclass isn't used now in gentoo package ebuilds and all available languages should be built. It's was gentoo QA requirement. > PYTHON3 The <gimp-2.99 depends only on python2.7 and there is no package gimp-help-9999 in the portage where this patch could be applicable. Anyway great thanks for information about patch. I want to left this issue open until gimp-2.99.2 will be released and this patch become useful to build appropriate gimp-help version.
Method for languages was derived from app-office/libreoffice and www-client/firefox. Changes do not use the l10n.eclass. Doing a eix on gimp gives... media-gfx/gimp Available versions: (2) 2.8.22-r2^t ~2.9.8-r1^t 2.10.14-r1^t 2.10.18-r1^t **9999*l^t {aalib alsa altivec aqua bzip2 curl dbus debug doc exif gnome heif javascript jpeg jpeg2k lcms lua mng openexr pdf png postscript python smp svg test tiff udev unwind vector-icons webp wmf xpm CPU_FLAGS_PPC="altivec" CPU_FLAGS_X86="mmx sse" PYTHON_SINGLE_TARGET="+python2_7 python3_6 python3_7 python3_8"} Homepage: https://www.gimp.org/ Description: GNU Image Manipulation Program I didn't think to try on the 9999 ebuild but that can be attempted. One thing I encountered was that the documentation wasn't "hooked into" gimp. It still directs to url for online docs.
ping.
(In reply to Michał Górny from comment #7) > ping. Sorry for silence. I was on vacations. I'll investigate this and others relayed py2 issues next week.
(In reply to Scott Furry from comment #6) > Method for languages was derived from app-office/libreoffice and > www-client/firefox. Changes do not use the l10n.eclass. There is no need to use l10n.eclass the languages to build help are choosed according to make.conf options LINGUAS and L10N="${LINGUAS}". And as I mentioned above the eliminating of this eclass was the Gentoo QA requirement. Currently I test the patch. Thanks again for link for it. I'll create a github PR soon.
After cleanup of 2.8.x we don't need app-doc/gimp-help-2.8.2 any longer, right? Then it is a waste of time to patch that to py3, rather stabilise 2.10.0-r1 afterwards.
(In reply to Andreas Sturmlechner from comment #10) > After cleanup of 2.8.x we don't need app-doc/gimp-help-2.8.2 any longer, > right? Then it is a waste of time to patch that to py3, rather stabilise > 2.10.0-r1 afterwards. IMHO, ideally, gimp help documentation would be apart of the gimp package and installed with a USE flag (e.g. "docs", "help"). This is not the case. For reasons I can only assume, gimp help is a separate package. However,... Currently, gimp package as installed ignores any installed help documentation outright. Pressing [F1] in gimp causes it to open a browser tab to access the online version of gimp-help. In short, internet access is needed to read gimp help as gimp package is installed. If there is will to fix this oversight, the gimp-help package needs to be brought up to current expectations - Py3 for starters. Integration with gimp package can be handled at a later date. As I stated in comments before: - l10n.eclass IS NOT USED - usage of "L10N" keyword from make.conf works (I have it setup and installed locally using non en_US and no problems) - again, method employed in ebuild patch submitted uses processes found in other firefox and libreoffice ebuilds in order to determine/install language specific. I am at a total loss to understand why any bug report (especially one with patches attached) moves slower than melting glaciers - but that's just my frustration with the process coming through. (/rant)
(In reply to Andreas Sturmlechner from comment #10) > After cleanup of 2.8.x we don't need app-doc/gimp-help-2.8.2 any longer, > right? Then it is a waste of time to patch that to py3, rather stabilise > 2.10.0-r1 afterwards. I removed 2.8.2 and 2.10.0 (previous that depend on python-2) in pull request as last already is candidate for removal.
(In reply to Scott Furry from comment #11) > IMHO, ideally, gimp help documentation would be apart of the gimp package > and installed with a USE flag (e.g. "docs", "help"). This is not the case. > For reasons I can only assume, gimp help is a separate package. However,... Yes, it's separate package and isn't part of build process media-gfx/gimp package. I don't want to rebuild entire gimp just to have local help docs that isn't a part of gimp source tarball. Also now it has python3 dependency while gimp doesn't depend on it. > Currently, gimp package as installed ignores any installed help > documentation outright. Pressing [F1] in gimp causes it to open a browser > tab to access the online version of gimp-help. In short, internet access is > needed to read gimp help as gimp package is installed. Please, try setup "Edit - Preferences - Help System - User manual: Use a locally installed copy" > If there is will to fix this oversight, the gimp-help package needs to be > brought up to current expectations - Py3 for starters. Integration with gimp > package can be handled at a later date. gimp-2.10.x will not be compatible with python3. I only could drop python-2 dependency for that. > As I stated in comments before: > - l10n.eclass IS NOT USED > - usage of "L10N" keyword from make.conf works (I have it setup and > installed locally using non en_US and no problems) > - again, method employed in ebuild patch submitted uses processes found in > other firefox and libreoffice ebuilds in order to determine/install language > specific. I assume the firefox and libreoffice teams have own reasons to handle available language to be installed via use flags. > I am at a total loss to understand why any bug report (especially one with > patches attached) moves slower than melting glaciers - but that's just my > frustration with the process coming through. (/rant) Initially there wasn't urgency to migrate from python-2 but recently this process was required to be accelerated.
(In reply to Sergey Torokhov from comment #13) > (In reply to Scott Furry from comment #11) > > I am at a total loss to understand why any bug report (especially one with > > patches attached) moves slower than melting glaciers - but that's just my > > frustration with the process coming through. (/rant) > > Initially there wasn't urgency to migrate from python-2 but recently this > process was required to be accelerated. And you mentioned that you were also on vacation or taking time off. Totally understandable. Those types of delays are quite understood. My frustration stems from ANY bug that is filed seems to languish until a senior dev/maintainer makes noises. In the interim, bug reports keep accumulating... Again, just my frustration with the process. Iterative learning doesn't seem practical given the above.
(In reply to Scott Furry from comment #14) > My frustration stems from ANY bug that is filed seems to languish until a > senior dev/maintainer makes noises. In the interim, bug reports keep > accumulating... > Again, just my frustration with the process. Iterative learning doesn't seem > practical given the above. We generally need a lot more help. Please feel free (genuinely) to adopt e.g. a maintainer-needed package and ping on IRC if things are not handled.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=95b8c676dfeb51f8f54e008a058436b6e5832ab1 commit 95b8c676dfeb51f8f54e008a058436b6e5832ab1 Author: Sergey Torokhov <torokhov-s-a@yandex.ru> AuthorDate: 2020-08-20 22:10:27 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-09-16 08:04:11 +0000 app-doc/gimp-help: 2.10.0, fix build using python3 Closes: https://bugs.gentoo.org/725940 Signed-off-by: Sergey Torokhov <torokhov-s-a@yandex.ru> Signed-off-by: Joonas Niilola <juippis@gentoo.org> .../gimp-help/files/gimp-help-2.10.0-python3.patch | 297 +++++++++++++++++++++ app-doc/gimp-help/gimp-help-2.10.0-r1.ebuild | 36 +++ 2 files changed, 333 insertions(+)
