Hi Intrigeri-- On 06/06/2012 10:21 AM, intrigeri wrote: > It looks like things have been improving a lot recently upstream: > a few releases were put out a week ago, that contain tons of new > features and bugfixes. this is great news, thanks for staying on top of it :) > propagate port information across a HUP -- #624500, dkg > ======================================================= > > Debian patch: 08_propagate-dynamic-port-data-across-a-hup.patch > > Net-Server 2.000's Changes entry reads: "Updates to the HUP mechanisms > to make sure we rebind all types of ports correctly." i can confirm that this seems to be fixed with the new upstream version. > IPv6 -- #523846, Carsten Wolff > ============================== > > Debian patches: 05_ipv6-support.patch and 06_cidr-workaround.patch > > Upstream added their own IPv6 support in 2.000. this is sightly different than the debian setup. in particular, there is a new parameter to run(), named "ipv". if ipv => "*", then upstream's new version correctly binds to all matching IPv4 and IPv6 addresses. Debian's ipv6 patches were set up to just grab the first address (either ipv4 or ipv6) that mapped to the requested hostname. And in the new release, ipv apparently defaults to "4", so people who expected debian's default behavior when binding to an IPv6-only address will probably be surprised to find that they are re-mapping to ipv4 again. That said, the sooner we switch to following upstream semantics in general, the better. So i see a few possible ways of dealing with this behavior change: 0) default ipv to "*" instead of 4 in the debian package. This causes us to diverge slightly from upstream, but it provides something closer to the current debian behavior to ease that transition. 1) add a NEWS entry that indicates the change in behavior maybe do both? > reachildren -- RT#65891, Carsten Wolff > ======================================== > > Debian patch: 03_rt-cpan-65891-reap-children.patch > > Net-Server 2.000's Changes entry reads: "Don't loose track of fork and > prefork children on a hup - make sure to actively wait them off". I didn't get a chance to test this, but Carsten seems to have indicated that it was applied upstream. Thanks for doing this work, intrigeri. I hope we can get this into unstable shortly. --dkg PS lintian informs me that there are a couple of pod2man errors that are probably worth fixing and sending upstream.
Attachment:
signature.asc
Description: OpenPGP digital signature