On Sat, 2025-04-12 at 00:05 +0200, Yoann Congal wrote: > Le lun. 7 avr. 2025 à 16:42, Martin Wilck <mwi...@suse.com> a écrit : > > > > On Mon, 2025-04-07 at 12:53 +0200, Yoann Congal wrote: > > > Hello, > > > > > > Le lun. 7 avr. 2025 à 12:32, Martin Wilck <mwi...@suse.com> a > > > écrit : > > > > > > > > On Mon, 2025-04-07 at 10:53 +0200, Martin Wilck wrote: > > > > > On Fri, 2025-04-04 at 14:29 +0200, Sofiane HAMAM wrote: > > > > > > From: Kéléfa Sané <kelefa.s...@smile.fr> > > > > > > > > > > > > When checking out the git repos, sometimes, target > > > > > > docs/man/dmmp_strerror.3 is newer that the prerequisite > > > > > > libdmmp/libdmmp.h this leads to a non reproducible > > > > > > behavior: > > > > > > Sometimes, the timestamps are updated in the manpages, > > > > > > sometimes > > > > > > not. > > > > > > > > > > > > Signed-off-by: Yoann Congal <yoann.con...@smile.fr> > > > > > > Signed-off-by: Sofiane HAMAM <sofiane.ha...@smile.fr> > > > > > > Signed-off-by: Kelefa Sane <kelefa.s...@smile.fr> > > > > > > --- > > > > > > libdmmp/Makefile | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/libdmmp/Makefile b/libdmmp/Makefile > > > > > > index 7e0e2509..187bcb8c 100644 > > > > > > --- a/libdmmp/Makefile > > > > > > +++ b/libdmmp/Makefile > > > > > > @@ -20,7 +20,7 @@ CFLAGS += $(LIB_CFLAGS) - > > > > > > fvisibility=hidden > > > > > > LIBDEPS += $(shell $(PKG_CONFIG) --libs json-c) - > > > > > > L$(mpathcmddir) - > > > > > > lmpathcmd -lpthread > > > > > > > > > > > > all: $(LIBS) doc > > > > > > -.PHONY: doc clean install uninstall check speed_test > > > > > > dep_clean > > > > > > +.PHONY: doc clean install uninstall check speed_test > > > > > > dep_clean docs/man/dmmp_strerror.3 > > > > > > > > > > > > > > > > I've seen the issue you refer to, but this is not the right > > > > > solution. > > > > > It will cause the time stamps of the man pages to be > > > > > regenerated > > > > > on > > > > > every build. > > > > > > > > After investigating this some more: AFAICS, your patch 1/2 > > > > fixes > > > > the > > > > erratic behavior in the (normal) case where > > > > KBUILD_BUILD_TIMESTAMP > > > > is > > > > not set and git is available. Previously, in this case, the > > > > kernel- > > > > doc > > > > script would have substituted the current date for > > > > KBUILD_BUILD_TIMESTAMP (yielding "April 2025" today). With your > > > > fix, > > > > KBUILD_BUILD_TIMESTAMP is correctly set to "August 2024". > > > > > > > > We need to create a commit that updates the man page time > > > > stamps to > > > > "August 2024". I'll do this. > > > > > > > > Once this is done, the build rule does the right thing, AFAICS. > > > > While > > > > it will rewrite the man pages if the libdmmp.h timestamp is > > > > updated, it > > > > won't apply any real changes (visible in "git diff" or "git > > > > status") > > > > unless libdmmp.h has actually changed. > > > > > > > > Am I overlooking something? > > > > > > Depending on the order the files are written on disk during the > > > git > > > clone/archive extraction (is dmmp_strerror.3 written before or > > > after > > > libdmmp.h ?), the build rule will either run or not. > > > But, as you wrote, with your latest patch, it does not matter at > > > all > > > because the rewritten timestamp will be exactly the same. > > > > > > Apart from this little quirk without any consequence, it looks > > > good > > > to me. > > > > > > The only future problem I can imagine is if libdmmp.h is updated > > > without updating the timestamps (again). > > > In this case, we will either get the timestamps from the sources > > > or > > > from git. > > > > That shouldn't happen because as soon as someone changes libdmmp.h > > and > > runs "make", the timestamps will be updated. Even if it does, the > > worst > > possible outcome is an outdated timestamp in the man pages, which > > we've > > seem to have had for several years now. > > Also, the actual content of libdmmp.h has hardly changed over > > years. > > > > If someone can contribute a better fix, we'll apply it happily. But > > I'd > > rather not want to have to check in the man pages after every > > build. > > Our (Yocto project) situation is quite different: We build from > scratch every time and the sources are only kept during the > compilation, erased after. > So we will use in our integration the 2 patches of this series to > force a reproducible build of the manpages. > > Thanks!
Can I take this as an acked-by: from your part? Or @Ben could you give it a review? Martin
