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.
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.
Tracy (https://github.com/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.
Rewrite the certificate section to more precisely describe
both alternatives in a more concise manner.
Additionally, remove the references to Let's Encrypt as the
certificate's origin is irrelevant.
Just as we are doing for the copyright-year and project version
information, we now also let cmake insert the project's description into
the plist files. This removes redundancy and should facilitate future
maintenance.
In theory LTO could give us a bit more performance than what we are
currently seeing. Client-side this will probably not be very noticeably
but on the server-side a few drops of extra performance can't hurt.
LTO will be enabled by default in all non-Debug builds. It remains
disabled for Debug builds as this is expected to be the kind of build
that a developer will use when they perform their work and there it is
useful to be able to go through multiple iterations of the program,
without waiting long times on the linker each time.
In theory LTO could give us a bit more performance than what we are
currently seeing. Client-side this will probably not be very noticeably
but on the server-side a few drops of extra performance can't hurt.
LTO will be enabled by default in all non-Debug builds. It remains
disabled for Debug builds as this is expected to be the kind of build
that a developer will use when they perform their work and there it is
useful to be able to go through multiple iterations of the program,
without waiting long times on the linker each time.
As it turns out QByteArray's isNull function is broken, when enabling
LTO (on FreeBSD) as it will always return false.
However, there is no real reason to use isNull instead of isEmpty in
CryptographicHash in the first place, so we use that instead.
