Bug 253936

Summary: dns/libidn 1.36 released 22 July 2020
Product: Ports & Packages Reporter: Dennis Clarke <dclarke>
Component: Individual Port(s)Assignee: Hung-Yi Chen <gaod>
Status: New ---    
Severity: Affects Many People CC: freebsd, gaod
Priority: --- Flags: gaod: maintainer-feedback+
Version: Latest   
Hardware: amd64   
OS: Any   
Attachments:
Description Flags
libidn 1.37
none
libidn 1.38 none

Description Dennis Clarke 2021-03-01 14:42:41 UTC
While doing testing with 13.0-BETA4 I see libidn2-2.3.0_1 exists
but libidn-1.35 is still around. Just a thought that is could be
revved up.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Comment 1 Dennis Clarke 2021-07-08 02:15:21 UTC
Did this die or just not worth revving up to 1.36 or maybe 1.37 ?
Comment 2 Leo Vandewoestijne 2021-07-08 12:00:25 UTC
I spot 45 ports which use libidn-1.35,
but I wonder how many truly require the old lib (instead of libidn2).
Comment 3 Leo Vandewoestijne 2021-07-12 12:17:25 UTC
Created attachment 226387 [details]
libidn 1.37

This patch is simpel version upgrade (plus I've adjusted the patches).
And I've changed the order in Makefile (on demand of portfmt & portclippy).

Tested all fine with portlint, poudriere, portfmt, portclippy.
Comment 4 Dennis Clarke 2021-07-12 22:13:40 UTC
(In reply to Leo Vandewoestijne from comment #3)

Looks perfect. Should work just fine and yes I see there are ports that
still want the previous rev library ( as opposed to libidn2 ) and to be
fair this is a trivial matter not even worth thinking about. I have
never had problems with libidn or libidn2 even on strange systems. Just
release it and let the other port maintainers do what they do.
Comment 5 Hung-Yi Chen 2021-07-13 03:48:24 UTC
I agree we can just bump libidn to 1.37. The patch looks good to me.
Comment 6 Leo Vandewoestijne 2021-08-09 11:18:52 UTC
Created attachment 227043 [details]
libidn 1.38

While at it, I also was able to manage the same up to 1.38

Tested successfully in poudriere.