These are potentially computed from inside each subdir, and in addition
due to what appears to be a regression in GNU make 4.4, where it is
reevaluating variables that contain $(shell) functions, many times (in
the order of thousands, this was slowing down the build, were on the
Debian amd64 build daemons it went from 5m with GNU make 4.3 to 2h40m
with GNU make 4.4. Although the bulk of the slow down has been fixed
with previous commits, the remaining optimizations are only to avoid
this potentially happening again in the future, and to reduce useless
duplicate work.
Instead of trying to cache the values from within make itself, where
programming this there is extremely painful, and does not seem to be
able to greatly reduce the number of calls, because the build system
is going to be called multiple times for different targets. Simply
externalize the generation into several shell scripts, that we call
to generate a make fragment that then we include from the various
Makefiles.
For a Debian build with GNU make 4.3, this reduces the amount of total
pkg-config calls from around ~1600 to 128, for dpkg-buildflags from
~1100 down to 6, and for dpkg-parsechangelog from ~56 to 17, but the
slow down is not as significant there anyway.
For a Debian build with GNU make 4.4, this reduces the amount of total
pkg-config calls from around ~2600 to 128, for dpkg-buildflags from
~2800 down to 6, and for dpkg-parsechangelog from ~350 to 21.
For a Debian build with GNU make 4.4, this reduces the build time
on this system from 2m10s to ~ 1m30s.
Change-Id: I427d0ea5106dc6ed1ff9e664ccdba2fa0725b7d0
(cherry picked from commit 7dbe24e4e5)
(cherry picked from commit 47205d8824)
Starting with GNU make 4.4, build time have massively regressed
where before they would take 5m on amd64 now can take 2h40m. While this
seems clearly broken, the release notes are filled with notices for
breaking changes, and in particular the one for passing all make
variables down to the invoked programs executed via the «shell» GNU make
function, so it is not clear what is expected breakage and what is not.
This has been reported in Debian, but not yet upstream, and while it
seems like a clear regression, it's not clear what will be the upstream
take on it. For now apply workarounds that do not change semantics, and
which do not regress with older GNU make versions.
Use the GNU make «origin» function instead of «?=» which defaults to
defining a variable as a recursive one. Coerce already defined variables
into simple ones to avoid GNU make re-evaluating these variables for
each «shell» function invocation.
Ref: https://bugs.debian.org/1092051
Change-Id: I076fc05dd616918473a22e7e942fecfdc9851d47
(cherry picked from commit 887fb40f3f)
(cherry picked from commit 4c114ab9af)
The markdown package seems dead upstream, and the packaging situation
in Debian is not very good either. It currently has an RC bug which
means rtpengine itself is marked for autoremoval from testing. While
we could fix the RC bug for the markdown package, it's probably better
to switch implementation instead to something that is more lively. That
would be the discount implementation for example.
Change-Id: I25334f1539090d5e2d8008f460a7459713241d7c
These will be shared between userspace and kernel space and so the
definitions must be part of the kernel includes.
Change-Id: Iabf7a4ecff3638ea1765a6d7341bb24e9955b509
Switch all memory buffers used for RTP I/O from generic stack or heap
allocated memory to the bufferpool implementation. Use a per-thread
bufferpool to minimise lock contention.
This commit is just a one-for-one swap and doesn't use the bufferpool's
reference counting semantics yet.
Change-Id: I9cba4ec97bd0afcd374bf6c0be2b608a46e73e57
This package has been obsoleted and the functionality has been
incorporated into the primary daemon.
Change-Id: I7b4aea5c1b8c7ed1216b35e2e1a4f72c254d0303
Follow-up for commit eea3824725, remove further files and configuration
related to rtpengine-iptables removal.
Change-Id: I3bc9a2a452bd41fb346b7479e8b00e4cdedb93a6
As we now natively support nftables, we no longer need to rely on the
iptables helper script. We can completely remove it.
Change-Id: I214bfee6ada534754141cb86bb50e87556de977d
*) Remove packaging for -gpu packages
*) Remove build profile restrictions, except for the build dependency
itself
*) Remove script to generate dh fragments for -gpu packages
*) Convert --cudecs switch to a path argument pointing to the .so
*) Don't link against libcudecs during build
*) Only include the single types.h header needed for usage as a plugin
*) Resolve all symbols during startup after loading the .so
Change-Id: Ide99eec2156d5d3be8c40594391cb1603add4b16
Capabilities listed in the ambient set must also be included in the
bounding set.
Change-Id: Iac8a97f6ba4f5446430ec2678092f768aeb8bb25
Related-to: I172bd30c9fbe488574e9cc015ba552e805c95fe6
If the kernel module is loaded automatically/implicitly through
insertion of an iptables rule, it gets loaded with only the default
module parameters. Add a modprobe.d fragment to handle this case.
Change-Id: I08659e2f0db8fed401cbcce6edee51e942da1f3e
Pandoc is available even on stretch, and unlike ronn is
actively maintained.
Fix -- markdown escaping.
Use __x__ for bold, and *x* for italics.
Remove .8.ronn symlinks.
Change-Id: Iff70e2b405f3b9ede856abf94d42fc51afb9f809
Sipwise Jenkins Builder
Guillem Jover
Victor Seva
Richard Fuchs
Chris Hofstaedtler
Michael Prokop
Victor Seva