Update to 0.4 release. Add Qt 5 toolkit support. Patch search path for linguisttools binaries. Create a new slave port mail/trojita-qt4 for Qt 4 toolkit support and connect it in mail/Makefile. Build tests: # portlint -C # make DEVELOPER=yes stage check-orphans package install deinstall clean # poudriere testport ... on amd64 for head, stable/10, releng/9.2, releng/8.4 Runtime tests: on stable/10 amd64 Thanks! Fix: Patch attached with submission follows:
Responsible Changed From-To: freebsd-ports-bugs->mandree I'll take it.
State Changed From-To: open->closed Committed, with minor changes. Thanks!
Note that I converted line endings from CRLF ("dos" or "Windows"-style) to Unix style in all files. Please make sure to submit future patches with Unix (LF-only) line ends.
On Sun, 23 Mar 2014 18:16:38 +0100 Matthias Andree <mandree@FreeBSD.org> wrote: > Note that I converted line endings from CRLF ("dos" or "Windows"-style) > to Unix style in all files. > > Please make sure to submit future patches with Unix (LF-only) line ends. Sorry for this trouble! But I have actually no idea where those CRLFs come from. I do not use Windows, just FreeBSD exclusively. Emacs and Git both use and show (of course) LF line endings. I configured them to highlight non-Unix line endings and whitespace issues. First I thought Gnats stored it wrong, but I verified my submitted patch. The local stored file (directly from Git) and the downloaded patch from Gnats web interface both use Unix LF line endings. I really do not know where this comes from. But from my side everything looks alright like always. I never had any complain about something like this. I am sorry! And thank you for your very quick commit! -- Kind regards
Am 23.03.2014 19:06, schrieb Marco Bröder: > On Sun, 23 Mar 2014 18:16:38 +0100 > Matthias Andree <mandree@FreeBSD.org> wrote: > >> Note that I converted line endings from CRLF ("dos" or "Windows"-style) >> to Unix style in all files. >> >> Please make sure to submit future patches with Unix (LF-only) line ends. > > Sorry for this trouble! But I have actually no idea where those CRLFs come > from. I do not use Windows, just FreeBSD exclusively. > > Emacs and Git both use and show (of course) LF line endings. I configured > them to highlight non-Unix line endings and whitespace issues. > > First I thought Gnats stored it wrong, but I verified my submitted patch. > The local stored file (directly from Git) and the downloaded patch from > Gnats web interface both use Unix LF line endings. Interesting. I used wget on FreeBSD 9.2 to fetch the patch from the GNATS web interface, and the patch appears to have double line spacing there, too.
On Sun, 23 Mar 2014 19:42:55 +0100 Matthias Andree <mandree@FreeBSD.org> wrote: > Interesting. > > I used wget on FreeBSD 9.2 to fetch the patch from the GNATS web > interface, and the patch appears to have double line spacing there, > too. I verified everything locally stored on my side is in Unix EoL. It would be a big surprise if not. So that is not the problem. I have something new learned. Firefox behaves strangely. Yesterday I downloaded the Gnats stored patch via `Save Link As' and verified it with Emacs, Vi, Diffuse and Kate. All of them showed Unix LF EoL. Today I did the same, but via `Save Page As' from opened site https://www.freebsd.org/cgi/query-pr.cgi?pr=187370&getpatch=2 and now, that file actually has CR/LF EoL. I do not know why it was different yesterday. So the Gnats stored patch is indeed not the same as my locally stored. Either Gnats or my MUA modified the patch. It was sent with base64 encoding. And looking at the MIME specification it specifies that any extra-alphabetic characters must be ignored by a compliant decoder, although most implementations use a CR/LF newline pair to delimit encoded lines. There it is! My MUA (Claws Mail) seems to use LF not CR/LF (the extracted file from email has LF EoL). It looks like Gnats is the culprit, because it uses CR/LF. So base64 encoded email attachments are _not_ usable with Gnats. Lesson learned. -- Kind regards