On 9 August 2018 at 19:01, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: > Jonas Gorski <jonas.gorski@xxxxxxxxx> writes: > >> On 9 August 2018 at 18:15, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: >>> Jonas Gorski <jonas.gorski@xxxxxxxxx> writes: >>> >>>> On 9 August 2018 at 17:28, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote: >>>>> Michael Büsch <m@xxxxxxx> writes: >>>>> >>>>>> strncpy might not NUL-terminate the string, if the name equals the buffer size. >>>>>> Use strlcpy instead. >>>>>> >>>>>> Signed-off-by: Michael Buesch <m@xxxxxxx> >>>>>> Cc: stable@xxxxxxxxxxxxxxx >>>>> >>>>> This is weird, with all the patches you submitted last week I get this >>>>> if I download the patch from patchwork: >>>>> >>>>> $ git am -s 1.mbox >>>>> Patch is empty. Was it split wrong? >>>>> >>>>> But if I download the patch directly from my IMAP folder I have no >>>>> problems: >>>>> >>>>> $ git am -s 1.mbox >>>>> Applying: b43/leds: Ensure NUL-termination of LED name string >>>>> >>>>> This happens even without my custom patchwork script so this has >>>>> something to do with the patchwork server, but it's not obvious to me >>>>> what triggers it. IIRC I have not seen anything like this before. It >>>>> seems that you didn't use git-send-email, I strongly suggest to use that >>>>> just to avoid problems like this. >>>> >>>> Looks like patchwork mishandles the pgp signature, the patchwork mbox has >>>> >>>>> Content-Type: multipart/signed; micalg=pgp-sha512; >>>>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" >>>> >>>> as the only content-type (and the boundary is nowhere to be found), >>>> while the one in my inbox has >>>> >>>>> Content-Type: multipart/signed; micalg=pgp-sha512; >>>>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; >>>>> protocol="application/pgp-signature" >>>>> >>>>> --Sig_/EN90ciRq4eWXDUcnZABQ0Ak >>>>> Content-Type: text/plain; charset=US-ASCII >>>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> When I remove the Content-Type: line(s) from the mbox from patchwork, >>>> git recognises it again as a patch. I guess git am ignores everything >>>> until the boundary, which got dropped by patchwork, so it never finds >>>> the actual patch. >>> >>> Awesome, thanks for debugging this! It would be great if someone could >>> report this to the patchwork maintainers, I don't have the time right >>> now. >> >> Silly question, but who *are* the maintainers? I just spend several >> minutes on https://patchwork.kernel.org/ and google, and failed to >> find any contact information. > > Not a silly question at all. I'm not sure what's the preferred way to > report bugs but at least I found this: > > http://jk.ozlabs.org/projects/patchwork/ > > I guess they use the github tracker: > > https://github.com/getpatchwork/patchwork/issues/ Going through the issues, I guess this is already fixed in master with https://github.com/getpatchwork/patchwork/commit/e27ff061dc01e51967a978884a5c59152863ab9c and queued for the next 2.1 release (or not? the stable/2.1 branch also contains a version bump to 2.2 ... ) I have still no idea who runs the patchwork instance at patchwork.kernel.org though. Regards Jonas
