When doing an "emerge --config" the einfo (presumably elog, ewarn, ..., too) messages are not written to an elog file in /var/log/portage/elog/ like it is done in all other ebuild phases. Reproducible: Always Steps to Reproduce: The simplest test that doesn't change anything in your system would be: 1. emerge --config sys-libs/timezone-data 2. elogv Actual Results: Step 1 writes " * Assuming your /etc/localtime symlink is what you want; skipping update." on the screen and into a file in /var/log/portage/ but no elog file. Step 2 says: There aren't any elog files on /var/log/portage/elog Expected Results: Step 1 writing an elog file. Step 2 showing the elog file with the message.
Please share the output of the following command: portageq envvar PORTAGE_ELOG_CLASSES
einfo messages are only saved to the /var/log/portage/elog directory if PORTAGE_ELOG_CLASSES contains "info". The default setting for PORTAGE_ELOG_CLASSES is "log warn error". Please re-open if you can reproduce the issue with "info" in PORTAGE_ELOG_CLASSES.
(In reply to Mike Gilbert from comment #1) > Please share the output of the following command: > > portageq envvar PORTAGE_ELOG_CLASSES The output is info log warn error qa
Can really nobody reproduce this with miy timezone-data example above? And if so, what could I possibly do (have configured) wrong?
I can reproduce it.
It seems like we're missing a call to the elog_process function here. We can add it in the action_config function before it calls the clean phase.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=7dfc36f8e6691851b33014e507db8a42c8f35315 commit 7dfc36f8e6691851b33014e507db8a42c8f35315 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2024-12-18 22:34:32 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2024-12-19 01:24:45 +0000 action_config: Call elog_process Bug: https://bugs.gentoo.org/904702 Signed-off-by: Zac Medico <zmedico@gentoo.org> NEWS | 2 ++ lib/_emerge/actions.py | 1 + 2 files changed, 3 insertions(+)
Tried portage-9999 and can confirm: The bug is fixed. Thanks! What's the correct workflow now: Should I mark this bug as resolved or will it be resolved "automatically" when bug 939444 is resolved?
(In reply to Horst Prote from comment #8) > What's the correct workflow now: Should I mark this bug as resolved or will > it be resolved "automatically" when bug 939444 is resolved? We will take care of updating the status once this is included in a Portage release.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03f41049a0fe0632eabd8cddaaca898e45943201 commit 03f41049a0fe0632eabd8cddaaca898e45943201 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-01-22 00:29:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-22 00:30:02 +0000 sys-apps/portage: add 3.0.67 Closes: https://bugs.gentoo.org/703520 Closes: https://bugs.gentoo.org/707980 Closes: https://bugs.gentoo.org/904702 Closes: https://bugs.gentoo.org/906044 Closes: https://bugs.gentoo.org/923530 Closes: https://bugs.gentoo.org/938164 Closes: https://bugs.gentoo.org/939299 Closes: https://bugs.gentoo.org/940120 Closes: https://bugs.gentoo.org/942512 Closes: https://bugs.gentoo.org/942760 Closes: https://bugs.gentoo.org/945382 Closes: https://bugs.gentoo.org/945861 Closes: https://bugs.gentoo.org/946326 Closes: https://bugs.gentoo.org/947822 Closes: https://bugs.gentoo.org/948067 Closes: https://bugs.gentoo.org/939444 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.67.ebuild | 231 +++++++++++++++++++++++++++++++++ 2 files changed, 232 insertions(+)
(In reply to Horst Prote from comment #8) > Tried portage-9999 and can confirm: The bug is fixed. > Thanks! > > What's the correct workflow now: Should I mark this bug as resolved or will > it be resolved "automatically" when bug 939444 is resolved? The latter :)
