Skip Menu |

This queue is for tickets about the Net-RawIP CPAN distribution.

Report information
The Basics
Id: 39252
Status: resolved
Priority: 0/
Queue: Net-RawIP

People
Owner: SAPER [...] cpan.org
Requestors: he [...] NetBSD.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.25



Subject: Fix for memory_leak test
Date: Sat, 13 Sep 2008 17:40:04 +0200 (CEST)
To: bug-Net-RawIP [...] rt.cpan.org
From: Havard Eidnes <he [...] NetBSD.org>
Hi, while packaging up a new version of the Net::RawIP package for NetBSD's pkgsrc system, I encountered two problems, one of which I think I have a reasonable patch for. On some platforms the Proc::ProcessTable may not support the "size" attribute, so the test would croak/fail. This test for the capability before embarking on the test proper: --- t/memory_leak.t.orig 2007-04-03 12:59:40.000000000 +0200 +++ t/memory_leak.t @@ -13,6 +13,12 @@ eval { if ($@) { plan skip_all => "Proc::ProcessTable is needed for this test"; } +eval { + my $s = get_process_size($$); +}; +if ($@) { + plan skip_all => "Proc::ProcessTable does not return process size"; +} else { plan tests => $tests; } The other problem is with the iflist test which is not portable (on NetBSD, the loopback interface is named lo0, but the test expects it to be named just lo, so the test failed). I don't have a portable patch for this problem, though. Best regards, - Havard
RT-Send-CC: saper [...] cpan.org
Hello, he@NetBSD.org wrote: Show quoted text
> while packaging up a new version of the Net::RawIP package for > NetBSD's pkgsrc system, I encountered two problems, one of which > I think I have a reasonable patch for. > > On some platforms the Proc::ProcessTable may not support the > "size" attribute, so the test would croak/fail. This test for > the capability before embarking on the test proper:
Indeed, I see similar failures on FreeBSD. Thanks for your patch, it's applied. Show quoted text
> The other problem is with the iflist test which is not portable > (on NetBSD, the loopback interface is named lo0, but the test > expects it to be named just lo, so the test failed). I don't > have a portable patch for this problem, though.
This should already be fixed in version 0.24: the test now looks for the names "lo" and "lo0". This is marginally better, but should at least work on most if not all Unix systems. -- Close the world, txEn eht nepO.
This is now fixed in version 0.25 Thanks for your report. -- Close the world, txEn eht nepO.