SHA256 Checksum mismatch for 601dfc87ff6e.patch.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ce65ecce2d6289f2655867f97a40a84af2f566e9 commit ce65ecce2d6289f2655867f97a40a84af2f566e9 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-10-21 18:14:37 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2022-10-21 18:39:49 +0000 accessibility/wlsunset: unbreak fetch due to Git upgrade => SHA256 Checksum mismatch for 601dfc87ff6e.patch. -2.34.4 +2.34.5 PR: 267257 accessibility/wlsunset/distinfo | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A commit in branch 2022Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d78d3cec4851e7be2f3b434dd04a605bdf60df88 commit d78d3cec4851e7be2f3b434dd04a605bdf60df88 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-10-21 18:14:37 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2022-10-21 18:40:21 +0000 accessibility/wlsunset: unbreak fetch due to Git upgrade => SHA256 Checksum mismatch for 601dfc87ff6e.patch. -2.34.4 +2.34.5 PR: 267257 (cherry picked from commit ce65ecce2d6289f2655867f97a40a84af2f566e9) accessibility/wlsunset/distinfo | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks for reporting.
Created attachment 241187 [details] git diff this same $&!+ again! -2.34.7 +2.38.4 the new hash is 761ac0b7831f8111f3b4950f62d589b953e6e5893b2cae685a62eb59e4336c70, for now does this sort of hara happen very often? seems this one will keep happening and im not trying to chase every upgrade of git on some remote http server, although i too prefer PATCH_SITES over PATCHDIR while it seems this is an obvious case (small patch) where we would simply move 601dfc87ff6e.patch into PATCHDIR, it got me to thinking more broadly any call for a masking-out feature to get added to /usr/ports/Mk/Scripts/checksum.sh? is there already such a canonical feature that dont know about? is there a sensible port infrastructure make target to define for editing a distfile in place, post-fetch and pre-checksum? at any rate, this patch to /usr/ports/accessibility/wlsunset/{Makefile,distinfo} is how in this case i put this hara to bed for good
(In reply to Chad Jacob Milios from comment #4) > does this sort of hara happen very often? Only when upstream is on sourcehut, see https://todo.sr.ht/~sircmpwn/git.sr.ht/368 > any call for a masking-out feature to get added to /usr/ports/Mk/Scripts/checksum.sh? Skipping checksum is undesirable as it prevents mirroring and breaks reproducibility. Opting out only for some files probably requires pre-fetch/post-fetch or overriding _CKSUMFILES. > is there already such a canonical feature that dont know about? The file can be cached on another host e.g., ports 35c4b7b1757e > is there a sensible port infrastructure make target to define for editing a distfile in place, post-fetch and pre-checksum? No.
i consider this an ugly patch for the following reasons, i trust jbeich to do better than i - i made a [possibly, fair?] assumption there is only one such (:M*:-p1) PATCHFILE(S). - i invoked a magic number (48) which could fail or horribly burn the next maintainer, should this get pulled forward to a world or use case where `wc -l $foo` becomes less or greater than it was when i typed 48 i'd like to open a conversation about the "best" way to solve problems "like" this one, but do totally feel free to dismiss this [trivial] problem with a simple solution like another distinfo bump commit or moving 601dfc87ff6e.patch to files/patch-whatever, and merely dismiss me as having had too much coffee this morning
(In reply to Jan Beich from comment #5) > Skipping checksum is undesirable as it prevents mirroring and breaks > reproducibility. Opting out only for some files probably requires > pre-fetch/post-fetch or overriding _CKSUMFILES. oh for sure, i would never suggest skipping checksums, certainly not for whole ports (NO_CHECKSUM) or files (_CKSUMFILES) that then get used in the build. by masking out i meant removing particular data from within a file. i see i did imply removing data from the checksum phase and was nebulous about the fate of that data perhaps ending up in the build. to be clear, im talking about adding a facility for processing/canonicalizing distfiles and/or patchfiles post-fetch and pre-checksum, where the output of said processing is all that gets used in a build. for instance, my attached patch to this port deletes lines 48 and on, if they exist, from 601dfc87ff6e.patch before checksumming and then uses it as modified i can picture a more general facility a port author could opt into for various files or sources of files, that might process such files according to Postel's law after fetching but before checksum and use. if there's any interest in such a facility i could design and implement it. admittedly it is a hypothetical solution in search of a problem; in this one minor case, i'd vote to just move the relatively tiny 601dfc87ff6e.patch into the files/ dir. if there are many other and/or large files coming from Sourcehut or those of its ilk, i for one would appreciate having a choice to use a more optimized solution than mirrors of lesser scale or just bloating files/. accept my apologies for my musings; the facilities currently in place are clearly adequate for this case and most like it. i sought to maybe save your future time on trivial minutiae like yet more otherwise-inconsequential distinfo bump commits. in this case i myself dug out the old patch from distcache.FreeBSD.org and compared it before proceeding. its not the first time, probably not the last and certainly not the biggest distfile ive analyzed to ensure zero meaningful changes perhaps there are others who might experience similar pain points. i'm content with any of the proposed fixes to this occurrence today. just keep me in mind if later on you think we should bubble this idea up.