Page MenuHomeFreeBSD

periodic: Make daily diff(1) output as small is possible
ClosedPublic

Authored by michaelo on Nov 24 2023, 8:21 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 21, 12:06 PM
Unknown Object (File)
Thu, Nov 21, 8:19 AM
Unknown Object (File)
Apr 12 2024, 5:03 AM
Unknown Object (File)
Apr 9 2024, 2:02 AM
Unknown Object (File)
Apr 8 2024, 9:51 PM
Unknown Object (File)
Apr 8 2024, 4:24 PM
Unknown Object (File)
Apr 7 2024, 11:02 PM
Unknown Object (File)
Apr 7 2024, 10:37 PM

Details

Summary

Make, by default, daily diff(1) ignore whitespace changes and the unified output a
context of zero (0) lines. This reduces output of unrelated lines in e-mails
delivered to root.

PR: 270266
Approved by: jrm (mentor), emaste, karels
MFC after: 1 month
Relnotes: yes

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Please add someone additionally for review you think is approriate.

Folks, you have some spare cycles to look at this?

jrm added reviewers: emaste, karels, netchild.

Seems fine to ignore these kinds of whitespace changes and have shorter emails by not providing diff context, but let's hear from a few others who have touched these files.

This revision is now accepted and ready to land.Dec 4 2023, 4:52 PM

I might suggest that the change in periodic.conf be done in a separate commit - i.e., add the infrastructure for daily_diff_flags first, then make use of it.

share/man/man5/periodic.conf.5
26

update prior to commit

I might suggest that the change in periodic.conf be done in a separate commit - i.e., add the infrastructure for daily_diff_flags first, then make use of it.

I thought of this as well. Will split.

Will split.

Great. That will allow us to have the infrastructure in stable/14 and stable/13, but not change the default within the branch.

Also make sure there's a Relnotes: YES

Seems OK. I wouldn't object to -U 1 either, but for most of these things context is probably unimportant.

This revision now requires review to proceed.Dec 4 2023, 6:49 PM

This one is to be merged to stable branches since it does not change default
behavior.

Looks like this changes behavior by adding -u to the last 3 daily scripts. But I'm not sure why this should be MFCed. Or you could omit daily_diff_flags from /etc/defaults/rc.conf and set defaults in the scripts that currently use -u if the variable hadn't been set.

Will split.

Great. That will allow us to have the infrastructure in stable/14 and stable/13, but not change the default within the branch.

Also make sure there's a Relnotes: YES

Split as expected. One can go into all branches and the change will remain on main (15).

Looks like this changes behavior by adding -u to the last 3 daily scripts. But I'm not sure why this should be MFCed. Or you could omit daily_diff_flags from /etc/defaults/rc.conf and set defaults in the scripts that currently use -u if the variable hadn't been set.

This one won't be MFC'd. But diff(1) without an option will default to -u as far as I can see. This change is intended for 15 only. The introduction of the flag for all branches.

Looks good (assuming the commit title is updated). Thanks.

This revision is now accepted and ready to land.Dec 4 2023, 8:17 PM

This one won't be MFC'd. But diff(1) without an option will default to -u as far as I can see. This change is intended for 15 only. The introduction of the flag for all branches.

mike@pughole$ diff /tmp/[xy]
1a2

hi

mike@pughole$ diff -u /tmp/[xy]

  • /tmp/x 2023-12-04 15:35:49.864258000 -0600

+++ /tmp/y 2023-12-04 15:35:56.220759000 -0600
@@ -1 +1,2 @@
here
+hi

michaelo retitled this revision from periodic: Make diff(1) flags configurable and output as small is possible to periodic: Make diff(1) output as small is possible.Dec 5 2023, 11:07 AM
michaelo edited the summary of this revision. (Show Details)
This revision now requires review to proceed.Dec 5 2023, 11:07 AM

This one won't be MFC'd. But diff(1) without an option will default to -u as far as I can see. This change is intended for 15 only. The introduction of the flag for all branches.

mike@pughole$ diff /tmp/[xy]
1a2

hi

mike@pughole$ diff -u /tmp/[xy]

  • /tmp/x 2023-12-04 15:35:49.864258000 -0600

+++ /tmp/y 2023-12-04 15:35:56.220759000 -0600
@@ -1 +1,2 @@
here
+hi

Can you reformat your message? I cannot read it or I do not understand what you are trying to say.

Sorry, apparently parts were interpreted as markdown, but it was the output of diff and diff -u. My point was that -u is not the default, and is more verbose than the default. WIth the current change, it no longer matters.

Sorry, apparently parts were interpreted as markdown, but it was the output of diff and diff -u. My point was that -u is not the default, and is more verbose than the default. WIth the current change, it no longer matters.

Alright so this makes sense to you?

This revision is now accepted and ready to land.Dec 5 2023, 2:00 PM

Sorry, apparently parts were interpreted as markdown, but it was the output of diff and diff -u. My point was that -u is not the default, and is more verbose than the default. WIth the current change, it no longer matters.

Alright so this makes sense to you?

Using -U 0 makes sense. I don't see why it should be changed to -u before that though, that is not an improvement

This revision now requires review to proceed.Dec 7 2023, 5:46 PM

Should this contain the periodic.conf* changes? I would have thought they'd be in the other review only, and now I think they conflict.

Should this contain the periodic.conf* changes? I would have thought they'd be in the other review only, and now I think they conflict.

No, this is correct. The other one is a MFC'able preprequisite, but this might not be backported, it does not apply anything, but just introduces the flag for daily diff. This applies minimal diff flags to all scripts, effectively. This review cannot be merged into main until the other one isn't merged.

Should this contain the periodic.conf* changes? I would have thought they'd be in the other review only, and now I think they conflict.

No, this is correct. The other one is a MFC'able preprequisite, but this might not be backported, it does not apply anything, but just introduces the flag for daily diff. This applies minimal diff flags to all scripts, effectively. This review cannot be merged into main until the other one isn't merged.

Sorry, I hadn't noticed that security_status_diff_flags already existed, so I confused the two flags variables. Now that I see what it is used for, I'm a bit apprehensive about changing it. @emaste, what do you think? Also, the change to security_status_diff_flags is unrelated to the other changes, so should be in a separate commit.

Should this contain the periodic.conf* changes? I would have thought they'd be in the other review only, and now I think they conflict.

No, this is correct. The other one is a MFC'able preprequisite, but this might not be backported, it does not apply anything, but just introduces the flag for daily diff. This applies minimal diff flags to all scripts, effectively. This review cannot be merged into main until the other one isn't merged.

Sorry, I hadn't noticed that security_status_diff_flags already existed, so I confused the two flags variables. Now that I see what it is used for, I'm a bit apprehensive about changing it. @emaste, what do you think? Also, the change to security_status_diff_flags is unrelated to the other changes, so should be in a separate commit.

It is not unrelated. The issue says "diff" output, it does not say "daily diff" output. The point is to consistently reduce the diff output. Security happended to have a flag, daily not. That is why you are/were confused. Do you still think that it should be two commits one containing the word "daily" the other one "security"?

It is not unrelated. The issue says "diff" output, it does not say "daily diff" output. The point is to consistently reduce the diff output. Security happended to have a flag, daily not. That is why you are/were confused. Do you still think that it should be two commits one containing the word "daily" the other one "security"?

The two changes are similar, but one changes the setting of a variable that affects security scripts, the other uses a different, new variable in daily scripts. They don't interact. Yes, I think they should be two commits. For example, if there is objection to the security change, it is easier to revert if it is a separate commit.

It is not unrelated. The issue says "diff" output, it does not say "daily diff" output. The point is to consistently reduce the diff output. Security happended to have a flag, daily not. That is why you are/were confused. Do you still think that it should be two commits one containing the word "daily" the other one "security"?

The two changes are similar, but one changes the setting of a variable that affects security scripts, the other uses a different, new variable in daily scripts. They don't interact. Yes, I think they should be two commits. For example, if there is objection to the security change, it is easier to revert if it is a separate commit.

Moved out to a separate review. Will update this one shortly.

This is now rebased on top of https://reviews.freebsd.org/D42900. Here is variable
modified. This truly introduces a change in behavior.

michaelo retitled this revision from periodic: Make diff(1) output as small is possible to periodic: Make daily diff(1) output as small is possible.Dec 15 2023, 3:09 PM
michaelo edited the summary of this revision. (Show Details)

Does this need rebasing again (-u was moved)? Otherwise looks good.

Does this need rebasing again (-u was moved)? Otherwise looks good.

Yes, it does. Will do.

This revision is now accepted and ready to land.Dec 15 2023, 5:20 PM