#acl PaulHowarth:read,write,admin,revert,delete All:read

=== Monday 31st January 2011 ===

==== Fedora Project ====

 * Became owner of the EPEL-4 branch of `perl-Sub-Exporter` and merged it with the EPEL-5 branch; the build will have to wait a couple of weeks until `perl-Package-Generator` and `perl-Data-OptList` are oushed to EPEL-4 stable

==== Local Packages ====

 * Updated `nmap` to 5.50
 . The updated version includes a new utility `nping`, though it's only available on distributions with `openssl` 0.9.8 or later (Fedora 5 onwards) as it needs the `EVP_sha256` function
 . I also came across a problem when compiling `nmap` for ancient distributions (pre Fedora 2) with `libpcap` 0.7.2 or earlier, despite configuring builds on those releases to use the bundled `libpcap`:
 . {{{
$  ./configure \
    --with-liblua=included \
    --with-libpcap=included \
    --without-nping
...
gcc -c -I/usr/kerberos/include   -I../../nbase -DHAVE_CONFIG_H -DNSOCK_VERSION=\"0.02\" -D_FORTIFY_SOURCE=2 -I../include -I../../libpcap -O2 -g -pipe -march=i386 -mcpu=i686 -Wall   nsock_pcap.c -o nsock_pcap.o
In file included from ../../libpcap/pcap.h:45,
                 from nsock_pcap.h:7,
                 from nsock_pcap.c:12:
../../libpcap/pcap/pcap.h:352: error: conflicting types for `bpf_filter'
/usr/include/net/bpf.h:448: error: previous declaration of `bpf_filter'
../../libpcap/pcap/pcap.h:353: error: conflicting types for `bpf_validate'
/usr/include/net/bpf.h:447: error: previous declaration of `bpf_validate'
}}}
 . What's happening here is that `nsock`'s `configure` script is checking for `<net/bpf.h>` and finding it on the system, despite the fact that we're using the bundled `libpcap`, which doesn't supply that obsolete header file. So the old system `libpcap` header files are included in addition to the much newer bundled `libpcap` header files and we get the conflict above. A simple workaround was to tell the `configure` script that we don't have `<net/bpf.h>`:
 . {{{
$ export ac_cv_header_net_bpf_h=no
$ ./configure ...
}}}
 . I [[http://seclists.org/nmap-dev/2011/q1/353|reported the issue upstream]] in the hope that maybe the `configure` script could be tweaked not to check for this header if the included `libpcap` is being used in future versions.
 * Updated `perl-Parse-CPAN-Meta` to add explicit runtime dependencies on `perl(CPAN::Meta::YAML)` ≥ 0.002 and `perl(JSON::PP)` ≥ 2.27103 as the module loads these dynamically as needed and thus they aren't found by the automatic dependency generator
 * Updated `perl-YAML-Tiny` to 1.47:
  * No functional changes
  * Only depend on the YAML implementations when we are release testing



----