Debian has automated building tools that handle source trees directly.
It is expected that you can pick up a source tarball, and with the
appropriate debian/ subtree, a successful build can be produced using
the `debuild` tool. This depends on all the build steps having been
included as part of the debian/rules file (see: `man debuild`).

This commit ensures there is no need to manually run autogen.sh
on a locally extracted source tarball prior to building for Debian.
This is accomplished by adding the `intltoolize` command to the
override_dh_auto_configure step in d/rules.

There is no need to add the `autoreconf` command due to dh-autoreconf
always handling that prior to the dh_auto_configure step.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

This reverts commit d39d928b.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

There is no sense in parsing and storting networks whose country codes
cannot be found in the ISO-3166-x country code table. This avoids side
effects in applications using the location database, and introduces
another sanity check to compensate bogus RIR data.

On location02, this affects some networks from APNIC (country code: ZZ)
as well as a bunch of smaller allocations within the RIPE region still
tagged to CS or YU (Yugoslavia). To my surprise, no network tagged as SU
(Soviet Union) was found - while the NIC for .su TLD is still
operational. :-)

Applying this patch causes the countries to be processed before
update_whois() is called. In case no countries are present in the SQL
table, this check is silently omitted.

Fixes: #12510
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

The IP range given in an inetnum object apparently not necessarily
matches distinct subnet boundaries. As a result, the current attempt to
calculate its CIDR mask resulted in faulty subnets not covering the
entire IP range.

This patch leaves the task of enumerating subnets to the ipaddress
module itself, which handles things much more robust. Since the output
may contain of several subnets, a list for the inetnum key is necessary
as well as a loop over them when conducting the SQL statements.

Fixes: #12595

Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

This was a potential memory leak.
Reported-by: Gisle Vanem <gisle.vanem@gmail.com>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Specifing the CC and LD flags is not required because perl MakeMaker
takes care of this.

Fixes #12574.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

This caused to gain the following error when building:

Only one of PREFIX or INSTALL_BASE can be given. Not both.

Using INSTALLDIRS=vendor is the common way to get the modules installed
into the right directories.

Fixes #12573.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

These are nothing to worry about, which is why debug log facility is
more suitable here than informational or warning.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

2002::/16 is an anycast prefix for 6to4 scenarios, as specified in RFC
3068. We currently process an announcement from Hurricane Electric for
it, and since it is an anycast network, multiple entities across the
world announce it as well.

Thereof, it does not make sense to include it in the database - as of
today, we do not have a country for it, either.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Fixes: #12549
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Fixes: #12554
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

We used to simply take the first element from the stack after we have
split a network. That is wrong because it is not passing through any
filters and no further subnet checks. It could have therefore been
that the tree was not entirely flat.
Reported-by: Arne Fitzenreiter <arne_f@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

This cannot happen and generated a compiler warning
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

The list was otherwise not sorted
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

When we check the result for any overlaps, we can cut this short
by walking through both lists from start to end and remember the
last network that we checked.

The next one will by definition be strictly greater and therefore
we do not need to check anything before this any more.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Everything is encoded in IPv6 anyways...
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

The list was unfortunately halved in size every time an element
was taken from it, which was great for performance, but shortened
the result substantially.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

This is helpful because very often we walk through a list in
order and are most interested in the last element.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>