I've watched app-doc/gimp-help compiling. It takes hours. The CPU was almost idle, not only beacause it runs on one thread only. The thread was also showing almost 0 CPU usage despite /var/tmp/portage is on a RAM drive. I don't know why this runs so slow. No, I'm not swapping. I've 128GB of RAM. Apart from the upper suggestions: It's compiling all available languages. Use flags for languages would be great to shorten that. I'd appreciate a package downloading those files precompiled, as there is no matter on which hardware the documentation is read.
The ebuild reports that emake is set with -j1 because of the following bugs: 1. https://bugs.gentoo.org/677198 2. https://bugs.gentoo.org/876205 That's why it takes so long to compile.
This confirms the desire to have that package prebuild as it is build on all systems bitwise the same. A workaround for now is something like (You can substitute chromium with another package that compiles for hours.) emerge --deep -newuse --update --exclude=app-doc/gimp-help --exclude=chromium --keep-going=y --backtrack=120 @world and then emerge -1 chromium and having that started in another terminal emerge -1 app-doc/gimp-help This should safe about an hour of time.
I'm thinking about pre-build gimp-help for gimp-3.0 or early if upstream will supply (I need to check if feature request already exist or not). Actualy it's available online but I also prefer to have offline variant. But what the reason you try to build help for every available language? It should rely on system LINGUAS or/and L10N settings. Could you please provide you /etc/portage/make.conf file?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a9cac53fc6e22aaaa9f8df98fe0d1b1e198d3730 commit a9cac53fc6e22aaaa9f8df98fe0d1b1e198d3730 Author: Sergey Torokhov <torokhov-s-a@yandex.ru> AuthorDate: 2023-05-05 21:33:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-05 22:38:14 +0000 app-doc/gimp-help: 2.10.34 revision bump 1. Add BDEPEND 'gnome-base/librsvg' to build Quickreference PDF files. 2. Force LINGUAS="en" if isn't specified in /etc/portage/make.conf to avoid of building all languages. 3. Force 'emake -j1' on install phase to prevent race condition when docs for several languages are built. Closes: https://bugs.gentoo.org/891709 Closes: https://bugs.gentoo.org/905693 Signed-off-by: Sergey Torokhov <torokhov-s-a@yandex.ru> Closes: https://github.com/gentoo/gentoo/pull/30887 Signed-off-by: Sam James <sam@gentoo.org> ...-2.10.34.ebuild => gimp-help-2.10.34-r1.ebuild} | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+)
(In reply to Larry the Git Cow from comment #4) > 2. Force LINGUAS="en" if isn't specified in /etc/portage/make.conf > to avoid of building all languages. IMHO this isn't the correct fix. The real problem is that the ebuild doesn't have an "nls" USE flag. So we must distinguish two cases here: 1. Users with "-nls" in their settings. These don't expect any translations to be built, and they may not have set LINGUAS. Obviously the ebuild shouldn't build any documentation other than English in this case. 2. Users with "+nls". I'd expect these to assign some value to LINGUAS. The ebuild should not override that value (even if it's empty of unset). Therefore, I'd suggest to replace pkg_setup() by the following very simple function: pkg_setup() { use nls || export LINGUAS="en" #891709 } I would go so far and say that we don't need a warning there.
Looking into configure.ac, it may be even cleaner to drop pkg_setup() altogether, and pass $(usev !nls ALL_LINGUAS=en) to econf instead.
(In reply to Ulrich Müller from comment #5) > (In reply to Larry the Git Cow from comment #4) > > 2. Force LINGUAS="en" if isn't specified in /etc/portage/make.conf > > to avoid of building all languages. > > IMHO this isn't the correct fix. > > The real problem is that the ebuild doesn't have an "nls" USE flag. So we > must distinguish two cases here: > > 1. Users with "-nls" in their settings. These don't expect any translations > to be built, and they may not have set LINGUAS. Obviously the ebuild > shouldn't build any documentation other than English in this case. > > 2. Users with "+nls". I'd expect these to assign some value to LINGUAS. The > ebuild should not override that value (even if it's empty of unset). > > Therefore, I'd suggest to replace pkg_setup() by the following very simple > function: > > pkg_setup() { > use nls || export LINGUAS="en" #891709 > } > > I would go so far and say that we don't need a warning there. The problem is that if LINGUAS isn't set then documentation for ALL languages are built. I checked it by commenting own LINGUAS setting. The "export LINGUAS=en" is applied (if isn't setup) only for build env in and doesn't affect system settings globaly, isn't it? I wasn't affected this issue because I use system LINGUAS="en ru ru_RU" L10N=${LINGUAS}, so I alway got only "en, ru" gimp-help documentation.
(In reply to Sergey Torokhov from comment #7) > The problem is that if LINGUAS isn't set then documentation for ALL > languages are built. That's not a problem, but exactly how LINGUAS is supposed to work. The current ebuild (nor the upstream build system) doesn't distinguish between LINGUAS being unset and being empty. This means that the user has no good way to specify that he wants to build _all_ supported languages. (He could list them explicitly, but that's not a setting that's applicable tree-wide.) We also had several discussions on this on the mailing list. For example this: https://archives.gentoo.org/gentoo-dev/message/38914ce4a7a228d2d29fb623346fba10 "LINGUAS maintains the standard gettext behaviour and will now work as expected with all package managers. It controls which language translations are built and installed. An unset value means all available, an empty value means none, and a value can be an unordered list of gettext language codes, with or without country codes."
From this point of view it's reasonable. I realy didn't provide for such build switch. Great thanks for prepared patch!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=243ee473e2e6153ba2d927c9e781150221d72d6e commit 243ee473e2e6153ba2d927c9e781150221d72d6e Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2023-05-07 06:04:00 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2023-05-07 13:35:22 +0000 app-doc/gimp-help: Add IUSE="nls" and fix LINGUAS logic Follow standard gettext behavior: - USE="-nls": build only English documentation (and ignore LINGUAS) - USE="nls" and unset LINGUAS: build all available languages - USE="nls" and empty LINGUAS: build only English - USE="nls" and nonempty LINGUAS: build listed languages if supported See also the following mailing list posting for an explanation: https://archives.gentoo.org/gentoo-dev/message/38914ce4a7a228d2d29fb623346fba10#L29 Bug: https://bugs.gentoo.org/891709 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-doc/gimp-help/gimp-help-2.10.34-r1.ebuild | 65 ----------------------- app-doc/gimp-help/gimp-help-2.10.34-r2.ebuild | 75 +++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 65 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d421ff667732643838e1379c0e29cc7f3bafccd4 commit d421ff667732643838e1379c0e29cc7f3bafccd4 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-23 20:32:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-23 20:33:06 +0000 app-doc/gimp-help: fix pkg_setup/python-any-r1 use See https://forums.gentoo.org/viewtopic-p-8810860.html. Bug: https://bugs.gentoo.org/891709 Bug: https://bugs.gentoo.org/905693 Signed-off-by: Sam James <sam@gentoo.org> app-doc/gimp-help/gimp-help-2.10.34-r2.ebuild | 2 ++ 1 file changed, 2 insertions(+)
