On 2018/03/09 18:39, Steffen Nurpmeso wrote:
> Hello Stuart!
> 
> Thanks for looking into this.
> 
> Stuart Henderson <s...@spacehopper.org> wrote:
>  |On 2018/03/08 17:35, Steffen Nurpmeso wrote:
>  |> This brings in two and a half years of development and bug fixes.
>  |> It has really improved, though a long road is ahead still.
>  |> Changelog etc. at: https://www.sdaoden.eu/code-nail-ann.html
>  ...
>  |> +FIX_EXTRACT_PERMISSIONS=Yes
>  |
>  |You're upstream aren't you - is there a reason for the unusual
>  |permissions in the tar file?
> 
> In a future release i will thus create the balls with a different
> umask(1) so this should then no longer be necessary.
> I gave the credit William (finally) and you (thanks).
> 
>  |It picks up idn2 in preference to idn if present at build, so
>  |WANTLIB/LIB_DEPENDS needs fixing.
> 
> ..Ok.. hmm.  I must say i dislike the entire IDN stuff very very
> much (if 25 years ago the DNS had some extensions to support
> longer labels UTF-8 could be it; even globally), so instead i have
> changed the configuration to prefer IDN over IDN2, and added the
> changeset as a patch for the OpenBSD port.  I really would prefer
> this approach and have no IDN2 around, if possible. ?

Hm - I haven't been keeping close track of IDN, but don't some
DNS registrars (like .de) require IDNA 2008 (i.e. libidn2)?
There was a CVE in curl relating to this a couple of years ago.


>  |$ make port-lib-depends-check
>  |s-nail-14.9.9(mail/s-nail):
>  |Missing lib: idn2.1 (/usr/local/bin/nail) (NOT REACHABLE)
>  |Extra:  idn.17
> 
> Should work now.
> 
> Also i add a fix for a double-free that sneaked into the codebase,
> unfortunately.  We have builtin double-free detection, terrible ...
> 
> Running "make test" does not work because we verify $HOME is an
> accessible directory, which the port framework does not provide.
> (The message is "nail: $HOME is not a directory or not accessible:
> /s-nail-14.9.9_writes_to_HOME", but we do not write, we only
> verify because $HOME is indeed target for several standardized
> files which we possibly would need to address.)  Due to that the
> error messages invalidate the test checksums.

Funnily enough this came up in another list post today.
You can either set PORTHOME as a port Makefile variable, or set
HOME as an environment variable for test. Using ${WRKDIR} for
this is often a good choice.

Reply via email to