FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.0 2018-01-11T15:01:48Z 2018-01-11T15:01:48Z Kyle Evans kevans@FreeBSD.org 2018-01-11T15:01:48Z urn:sha1:21ab148d783814f0157935e3fd210b2f22cdb00f Plan A mmap()'s the entire input file and operates on it in memory. The map(2) call succeeded, so we shouldn't need to bother checking for the NUL byte as long as we're within our buffer space. This was clearly intentional to match "the behavior of the original code", but it creates a discrepancy between Plan A and Plan B that doesn't seem sensible and it's not inherently wrong to allow a NUL byte. This change was motivated by the gemspec in net/rubygem-grpc failing to patch, despite the patch being generated with diff, because a NUL byte was used as a delimiter in the header briefly in an otherwise text file. An alternative was considered: to fallback to plan B if plan A won't process the entire file due to a NUL byte, but I deemed this to be the better option since plan A isn't failing due to memory limitations and will fail later on if it's really dealing with a file it shouldn't be. PR: 224842 (exp-run) Reported by: swills Reviewed by: emaste, pfg MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D13738 2017-12-21T16:25:33Z Pedro F. Giffuni pfg@FreeBSD.org 2017-12-21T16:25:33Z urn:sha1:76df519fe099c90ba2188cd1ca6846181b24b4b2 Fix adding and removing files with git-style a/ b/ diffs: only skip six letters if they actually match "--- a/" and "+++ b/" instead of laxer checks. Obtained from: OpenBSD (CVS 1.59) 2017-12-21T16:19:10Z Pedro F. Giffuni pfg@FreeBSD.org 2017-12-21T16:19:10Z urn:sha1:c844f14e37e57b9f259fb60423456b297b3951e1 Obtained from: OpenBSD (CVS 1.64) 2017-11-22T03:44:19Z Kyle Evans kevans@FreeBSD.org 2017-11-22T03:44:19Z urn:sha1:bc4f0fe3588183058f52c53f9cf59b77e19842db Patches with very little context (-U0 and -U1) could get misapplied if the file to be patched changes and a hunk is no longer applicable. Matching with fuzz would be attempted and default to a match when we unexpectedly ran out of context. This also affected patches with higher levels of context but had limited actual context due to the hunk being located near the beginning/end of file. PR: 74127, 223545 (exp-run) Reviewed by: emaste, pfg Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D12631 2017-11-20T19:49:47Z Pedro F. Giffuni pfg@FreeBSD.org 2017-11-20T19:49:47Z urn:sha1:8a16b7a18f5d0b031f09832fd7752fba717e2a97 Mainly focus on files that use BSD 3-Clause license. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point. 2017-11-08T23:11:15Z Kyle Evans kevans@FreeBSD.org 2017-11-08T23:11:15Z urn:sha1:752e881db7398b10410d26c7d69176ec998d9c3b r325365 caused several ports to fail to patch correctly. Revert it for the time being until an exp-run can be completed. Requested by: antoine Approved by: emaste (implicit) 2017-11-03T17:04:30Z Kyle Evans kevans@FreeBSD.org 2017-11-03T17:04:30Z urn:sha1:ed3b30599370432f6ac501e36099f597f5999d27 Patches with very little context (-U0 and -U1) could get misapplied if the file to be patched changes and a hunk is no longer applicable. Matching with fuzz would be attempted and default to a match when we unexpectedly ran out of context. PR: 74127 Reviewed by: emaste, pfg Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D12631 2017-10-31T00:07:04Z Bryan Drewery bdrewery@FreeBSD.org 2017-10-31T00:07:04Z urn:sha1:ea825d02749f382c3f7e17f28247f20a48733eab Sponsored by: Dell EMC Isilon 2017-10-09T14:50:02Z Kyle Evans kevans@FreeBSD.org 2017-10-09T14:50:02Z urn:sha1:4835edfa0d452a9d75eeb73c3414d563ec9909f9 Patches like file.txt attached to PR 190195 with a final line formed like ">(EOL)" could cause a copy past the end of the current line buffer. In the case of PR 191641, this caused a duplicate line to be copied into the resulting file. Instead of running past the end, treat it as if it were a blank line. PR: 191641 Reviewed by: cem, emaste, pfg Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D12609 2017-07-02T21:00:30Z Pedro F. Giffuni pfg@FreeBSD.org 2017-07-02T21:00:30Z urn:sha1:85823a601c1ede44a844edde4f1d18643903ce54 Sometimes patches coming from other places have extra a/ and b/ directories prepended to filenames. Obtained from: OpenBSD (CVS rev. 1.57, 1.58)