On 2023/02/07 16:31:08 +0100, Omar Polo <op@omarpolo.com> wrote:
> On 2023/02/07 15:33:19 +0100, Christian Weisgerber <naddy@mips.inka.de> wrote:
> > Oh noes, I can't apply afresh1's perl 5.36.0 patch to the OpenBSD
> > src tree!
> >
> > $ cd /usr/src
> > $ got patch -n ~/perl-5.36.0.patch
> > got: Result too large
> >
> > afresh1 already warned me that OpenBSD patch(1) doesn't cope and
> > GNU patch is required, so this isn't surprising.  I thought I'd
> > still report it, though.
> >
> > Here's the offender:
> > https://cvs.afresh1.com/~andrew/perl-update/perl-5.36.0.patch.gz
> 
> that's a nice diff!
> 
> the ERANGE error comes from got-read-patch.c:460:
> 
> 	458	if (imsg_compose(&ibuf, GOT_IMSG_PATCH_LINE, 0, 0, -1,
> 	459	    line, strlen(line) + 1) == -1)
> 	460	        err = got_error_from_errno(
> 	461	            "imsg_compose GOT_IMSG_PATCH_LINE");
> 
> the line in question is 24722 bytes long, so it's too big for imsg.
> 
> Now, sending the (parsed) lines of the diff via imsg one at a time is
> not a great idea.  It is like this because I wanted to have the
> parsing in a separate helper (everything got parses is in a separate
> helper, would seem strange to hadle patches in the main process,
> although they're trivial to parse.)  Maybe i should set up a pipe or a
> temp file between the two processes and just send the offsets via
> imsg.  could even batch like we're doing with the tree entries.
> 
> will take a look once i'm done with the first round of sha256 patches,
> thanks! :)
> 
> (i'm curious why patch(1) fails tho...)

actually it's worse.  patch fails due to:

patch: **** malformed patch at line 392134: RCS file: gnu/usr.bin/perl/cpan/IO-Compress/t/files/testfile1.odt

and that's a... odt?  it's a binary files with various NUL bytes in
it.

	-^@...
	+^@...

got-read-patch is currently using strlen in send_line so that would
silently fails, thinking it had applied the correct when it didn't.

adding this too to my todo list.