When trying to use the diff command on any config file for which there was a change during an update, it doesn't do anything. I have to manually diff the ._cfg file and the current config always and replace them that way. Reproducible: Always
dispatch-conf does not have a "diff" command. Do you mean "merge" (m)?
(In reply to Mike Gilbert from comment #1) > dispatch-conf does not have a "diff" command. Do you mean "merge" (m)? https://gitweb.gentoo.org/proj/portage.git/tree/bin/dispatch-conf#n512
Ah, so the "l" command. It works fine for me. Have you customized /etc/dispatch-conf.conf at all? Any strange pager settings (LESS env var)?
> Have you customized /etc/dispatch-conf.conf at all? No I haven't. > Any strange pager settings (LESS env var)? These are my less settings from the env var "-R -M --shift 5". Also is my assumption about the "l" command correct? I expect it to show me the diff between ._cfg0000_filename and filename.
I think the "l" command is only useful after you have run the "m" (merge) command. Running "l" after "m" should produce output like this: > --- /etc/._cfg0000_mlocate-cron.conf 2023-07-21 10:24:26.783493956 -0400 > +++ /etc/._mrg0000_mlocate-cron.conf 2023-07-22 17:08:44.085754978 -0400 > @@ -3,7 +3,7 @@ > > # ionice class to run at: see -c in ionice(1) > # you have to install sys-apps/util-linux manually > -IONICE_CLASS="4" > +IONICE_CLASS="2" > > # ionice priority to run at: see -n in ionice(1) > IONICE_PRIORITY="7" > > >> (1 of 1) -- /etc/mlocate-cron.conf > >> q quit, h help, n next, e edit-new, z zap-new, u use-new > m merge, t toggle-merge, l look-merge:
Also, dispatch-conf should immediately show you a diff as soon as you run it. No explicit command is requited. That output should look like this: > --- /etc/mlocate-cron.conf 2020-04-12 12:00:36.143350196 -0400 > +++ /etc/._cfg0000_mlocate-cron.conf 2023-07-22 17:15:07.618235065 -0400 > @@ -5,5 +5,7 @@ > # you have to install sys-apps/util-linux manually > IONICE_CLASS="2" > > +# some new setting > + > # ionice priority to run at: see -n in ionice(1) > IONICE_PRIORITY="7" > > >> (1 of 1) -- /etc/mlocate-cron.conf > >> q quit, h help, n next, e edit-new, z zap-new, u use-new > m merge, t toggle-merge, l look-merge:
> Also, dispatch-conf should immediately show you a diff as soon as you run it. Interesting, this doesn't happen in my case. I just directly get the output: > >> (1 of 1) -- /etc/mlocate-cron.conf > >> q quit, h help, n next, e edit-new, z zap-new, u use-new > m merge, t toggle-merge, l look-merge: and nothing else.
Does it work if you bypass less by setting PAGER=cat? eg. PAGER=cat dispatch-conf
> Does it work if you bypass less by setting PAGER=cat? It doesn't and changing the setting as pager="cat" in /etc/dispatch-conf.conf doesn't do anything either.
As someone who has also been running into this issue I might have a lead? I think the issue is because dispatch-conf is invoking the pager with root's default shell (which for many is /sbin/nologin) here: https://github.com/gentoo/portage/blob/9e6451c88e3da11e0eb7b0bd6b1497c5ca4fb67f/bin/dispatch-conf#L328 And that's causing dispatch-conf to print out an unassuming little nologin message at the top with the pager silently failing. > This account is currently not available. > > >> (1 of 1) -- /etc/rsyncd.conf > >> q quit, h help, n next, e edit-new, z zap-new, u use-new > m merge, t toggle-merge, l look-merge:
I just got a chance to try temporarily changing the default shell for root and it does seem to work with the default shell set to bash or anything other than nologin or false. Now I get the diff upon running dispatch-conf and when I set it back to nologin, it no longer works again. So it seems to be an issue with python's spawn() function (only the pager uses it and the other subshells use os.system()) using the default login shell (which for root is often /sbin/nologin).
(In reply to Jacob Abel from comment #11) > I just got a chance to try temporarily changing the default shell for root > and it does seem to work with the default shell set to bash or anything > other than nologin or false. > > Now I get the diff upon running dispatch-conf and when I set it back to > nologin, it no longer works again. So it seems to be an issue with python's > spawn() function (only the pager uses it and the other subshells use > os.system()) using the default login shell (which for root is often > /sbin/nologin). it makes sense as per their own-made spawn_shell() func here: https://github.com/gentoo/portage/blob/9e6451c88e3da11e0eb7b0bd6b1497c5ca4fb67f/bin/dispatch-conf#L577-L587 as it seems to be by design, but clearly didn't consider the /sbin/nologin case. Thanks for your work looking into this!
Created attachment 899815 [details, diff] Proposed fix for issue I slapped this patch together today. It seems to resolve the issue for me. Let me know if it helps.
Created attachment 899818 [details, diff] Resubmition of the proposed fix for the issue Please ignore the previous patch. I accidentally submitted a slightly older revision since I forgot to commit my updated change. This has the up-to-date patch in it.
(In reply to Jacob Abel from comment #14) > Created attachment 899818 [details, diff] [details, diff] > Resubmition of the proposed fix for the issue > > Please ignore the previous patch. I accidentally submitted a slightly older > revision since I forgot to commit my updated change. > > This has the up-to-date patch in it. Looks good, but more compact like this: if shell_basename in ("nologin", "false"):
Created attachment 899823 [details, diff] v3 Proposed Fix Ah good catch, that is far cleaner. I've updated it.
I don't understand why we are looking at the SHELL environment variable in the first place. I think we should instead call "/bin/sh" unconditionally to match the behavior of os.system(). What benefit is there to calling some alternative shell?
(In reply to Mike Gilbert from comment #17) > I don't understand why we are looking at the SHELL environment variable in > the first place. > > I think we should instead call "/bin/sh" unconditionally to match the > behavior of os.system(). What benefit is there to calling some alternative > shell? Based on the blame that appears to have been the original behavior but was changed to explicitly use spawn(). https://github.com/gentoo/portage/commit/d11c0ac819a7509332f5277099ad2b6e969c8414
(In reply to Mike Gilbert from comment #17) > I don't understand why we are looking at the SHELL environment variable in > the first place. > > I think we should instead call "/bin/sh" unconditionally to match the > behavior of os.system(). What benefit is there to calling some alternative > shell? In retrospect I suppose using "/bin/sh" unconditionally is probably reasonable here. This shell is mainly used to pipe the user's diff command to their pager command.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=892f5408a6ff1aa899cc62a10ec07af57001f5d0 commit 892f5408a6ff1aa899cc62a10ec07af57001f5d0 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-08-13 01:14:14 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-08-14 14:43:09 +0000 dispatch-conf: ignore SHELL in spawn_shell There is no need to use SHELL here, and this can actually cause problems when SHELL is set to "nologin" or "false". Look for sh in PATH instead. Bug: https://bugs.gentoo.org/910560 Signed-off-by: Mike Gilbert <floppym@gentoo.org> bin/dispatch-conf | 30 +++++++++++------------------- 1 file changed, 11 insertions(+), 19 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=02d0e00a1ba811b39140d10e17488f7fc3916534 commit 02d0e00a1ba811b39140d10e17488f7fc3916534 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-11 01:30:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-11 01:30:30 +0000 sys-apps/portage: add 3.0.66 Closes: https://bugs.gentoo.org/435066 Closes: https://bugs.gentoo.org/907061 Closes: https://bugs.gentoo.org/910560 Closes: https://bugs.gentoo.org/933433 Closes: https://bugs.gentoo.org/934220 Closes: https://bugs.gentoo.org/934514 Closes: https://bugs.gentoo.org/934784 Closes: https://bugs.gentoo.org/935830 Closes: https://bugs.gentoo.org/936273 Closes: https://bugs.gentoo.org/937384 Closes: https://bugs.gentoo.org/937485 Closes: https://bugs.gentoo.org/937740 Closes: https://bugs.gentoo.org/937888 Closes: https://bugs.gentoo.org/937891 Closes: https://bugs.gentoo.org/938127 Closes: https://bugs.gentoo.org/933499 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.66.ebuild | 227 +++++++++++++++++++++++++++++++++ 2 files changed, 228 insertions(+)
