The concept of RELEASE_ID was dropped with PR #5401 in commit 6caa808e6.
Thus, drop its leftovers from the documentation.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
GNUInstallDirs is already used in cmake/install-paths.cmake. This fixes
arch-independent files ending up in $prefix/share instead of /usr/share.
This is required on multiarch/cross layouts setting the prefix to e.g.
/usr/x86_64-pc-linux-gnu or /usr/i686-pc-linux-gnu.
GNUInstallDirs is already used in cmake/install-paths.cmake. This fixes
arch-independent files ending up in $prefix/share instead of /usr/share.
This is required on multiarch/cross layouts setting the prefix to e.g.
/usr/x86_64-pc-linux-gnu or /usr/i686-pc-linux-gnu.
OS packages (at least on Linux and BSDs) prefer prepackaged libraries to
bundled/statically linked versions where possible.
Introduce rnnoise (default ON) and make bundled-rnnoise default to
it's value; this retains current behaviour.
This way, rnnoise=OFF disables use of RNNoise completely and a simple
bundled-rnnoise=OFF requires the system's library.
Tested on OpenBSD 7.0-CURRENT.
OS packages (at least on Linux and BSDs) prefer prepackaged libraries to
bundled/statically linked versions where possible.
Introduce `rnnoise` (default `ON`) and make `bundled-rnnoise` default to
it's value; this retains current behaviour.
This way, `rnnoise=OFF` disables use of RNNoise completely and a simple
`bundled-rnnoise=OFF` requires the system's library.
Tested on OpenBSD 7.0-CURRENT.
Move the declaration/definition of `iMessage` to where it is used,
otherwise the build fails with
```
src/mumble/AudioWizard.cpp:95:10: error: variable 'iMessage' set but not used [-Werror,-Wunused-but-set-variable]
quint32 iMessage = Settings::LogNone;
^
1 error generated.
```
Build-tested on OpenBSD 7.0-CURRENT using
```
$ cc --version
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.0
Thread model: posix
InstalledDir: /usr/bin
```
There is an additional `elemsize` argument
(https://man.openbsd.org/kvm_getprocs.3):
Only the first elemsize bytes of each array entry are returned.
Complete OpenBSD signature:
```
struct kinfo_proc *
kvm_getprocs(kvm_t *kd, int op, int arg, size_t elemsize, int *cnt);
```
Linux, FreeBSD and NetBSD have the same four-argument signature:
```
struct kinfo_proc *
kvm_getprocs(kvm_t *kd, int op, int arg, int *cnt);
```
Build-tested on OpenBSD 7.0-CURRENT.
kvm_getprocs(3) on Linux and FreeBSD
(https://www.freebsd.org/cgi/man.cgi?kvm_getprocs) has
```
KERN_PROC_PROC all processes, without threads
...
```
OpenBSD (https://man.openbsd.org/kvm_getprocs.3) and
NetBSD (https://man.openbsd.org/kvm_getprocs.3) however only know
```
KERN_PROC_KTHREAD
all processes (user-level plus kernel threads)
KERN_PROC_ALL
all user-level processes
...
```
and
```
KERN_PROC_ALL all processes
KERN_PROC_PID processes with process id arg
...
```
respectively, thus fall back to KERN_PROC_ALL where needed.
Build-tested on OpenBSD 7.0-CURRENT.
NB: The first hunk around kvm_openfiles(3) is from `clang-format`.
(should've have happened in the commit introducing this line, I guess.)
Move the declaration/definition of `iMessage` to where it is used,
otherwise the build fails with
```
src/mumble/AudioWizard.cpp:95:10: error: variable 'iMessage' set but not used [-Werror,-Wunused-but-set-variable]
quint32 iMessage = Settings::LogNone;
^
1 error generated.
```
Build-tested on OpenBSD 7.0-CURRENT using
```
$ cc --version
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.0
Thread model: posix
InstalledDir: /usr/bin
```
When using the BanEditor to manually create a new Ban entry, it was
really easy to get the "mask" property wrong, which had the effect of
apparently not performing any action at all, when clicking on the "Add"
button.
The underlying problem was most likely that the "mask" field defaults to
128, which is only valid for IPv6 addresses. When entering an IPv4
address, the mask would be considered invalid (through some internal
wizardry) and thus the Ban would not be added.
However, the user was not presented with any kind of error message that
would have hinted at the problem.
This commit tackles this issue by first of all validating that the
entered IP address is valid. If it is not, then the respective input
field will be colored red. If it is, the mask spin box's maximum value
will automatically be set to the correct maximum value for the used IP
address flavor (32 for IPv4 and 128 for IPv6).
That way the user can only ever press "Add", if they entered a valid IP
address alongside a valid mask. Thus, pressing "Add" should now always
add the respective ban.
Fixes#3986
When using the BanEditor to manually create a new Ban entry, it was
really easy to get the "mask" property wrong, which had the effect of
apparently not performing any action at all, when clicking on the "Add"
button.
The underlying problem was most likely that the "mask" field defaults to
128, which is only valid for IPv6 addresses. When entering an IPv4
address, the mask would be considered invalid (through some internal
wizardry) and thus the Ban would not be added.
However, the user was not presented with any kind of error message that
would have hinted at the problem.
This commit tackles this issue by first of all validating that the
entered IP address is valid. If it is not, then the respective input
field will be colored red. If it is, the mask spin box's maximum value
will automatically be set to the correct maximum value for the used IP
address flavor (32 for IPv4 and 128 for IPv6).
That way the user can only ever press "Add", if they entered a valid IP
address alongside a valid mask. Thus, pressing "Add" should now always
add the respective ban.
Fixes#3986
Having a separate RELEASE_ID just unnecessarily complicates drafting
releases. Plus, now that we are using different build numbers for every
new build anyway, a separate release ID is really not necessary.
Having a separate RELEASE_ID just unnecessarily complicates drafting
releases. Plus, now that we are using different build numbers for every
new build anyway, a separate release ID is really not necessary.
This is done, since the underlying framework for how channel listeners
are handled (more specifically: where they are stored) will be changed
in an upcoming PR. This upcoming change will cause listener persistence
to only apply to registered users. Thus, if the current persistence
feature was to be retained, that would mean that when introducing this
change, we'd remove a feature from Mumble.
As that is not a great thing to do, we'll remove the feature now that it
is still unreleased and then the upcoming change will introduce
persistence for some users instead of taking it away from others.
Furthermore, this PR fixes a little bug that made it possible for channel listeners
to be shown multiple times in the UI.
Tracy (wolfpld/tracy) is a profiler that is aimed at
having a very low impact on the runtime performance and is thus suitable
to be used in production systems to figure out what is going on and how
the code is performing.
For the time being, this commit instruments only the server code.
Furthermore, the instrumentation is performed in a rather minimalistic
way that should suffice to start profiling audio and control message
processing but is definitely far from being complete. Further
instrumentation will be added on-demand.
