The produced binary as well as the used cmake target was renamed from
"murmurd" and "murmur" respectively to "mumble-server".
The installer code was adapted accordingly.
For most images, this results in far better legibility, especially if they contain text, such as memes or web comics - you currently need to squint at the screen often, because it's always sized down to 480x270.
People with windows smaller than that will get a horizontal scroll. Scrolling is still better than having an image that's illegible because it's too small, and small images will never be scaled up this way.
800x600 should be okay since 1920x1080 is a very common desktop resolution by now.
This is a stopgap measure until images can be sized per client.
Push-to-mute requires a constant button press (not togglable), so reminding them that they are muted is not really useful in that case.
The use case that targets is using push-to-mute to talk to another VOIP client (a game for example) with the same people as in the mumble channel. Without this change the user will get the muted cue each time they use push-to-mute.
The bPosTest variable indicates whether we're in the middle of a test.
It causes the user's direction vector to freeze so that it always "looks" straight ahead.
When completing the wizard, accept() is called and thus the variable is set to false again.
However, when the wizard is closed prematurely, reject() is called instead.
The "bPosTest" variable indicates whether we're in the middle of a test.
It causes the user's direction vector to freeze so that it always "looks" straight ahead.
When completing the wizard, accept() is called and thus the variable is set to false again.
However, when the wizard is closed prematurely, reject() is called instead.
In short: The lock file(s) for the SQLite DB were being discarded as
soon as fork() was called on Unix systems. Thus the DB connection was a
ghost connection and accessing the DB from somewhere else (e.g. CLI)
would likely cause DB corruption because of missing locks.
Because this only happened when calling fork(), Debug builds are
unaffected since they always run in foreground mode which never calls
fork().
The underlying issue here is that an open SQLite connection should
have a read POSIX lock on the database file. Because we were calling
fork() and then _exit() after taking out these locks (which was done
when creating the ServerDB object), the locks were being released.
POSIX locks are super easy to get wrong. This is a nice rant about how
they stink: http://0pointer.de/blog/projects/locking.html
Not having a read lock when you have an open connection probably can
cause all kinds of issues, but with WAL it is particularly bad because
the WAL file is deleted when the last connection closes. The server's
connection to the database is like a ghost connection that nobody
knows about, so any CLI (or other server-external) DB access ended up
deleting the WAL file (i.e. committing everything in it to the main
database). Of course, server still had the WAL file opened. Bad things
happen after that.
The fix is making sure that the ServerDB object is created after the
fork happens so that the locks created by SQLite will not have to cross
the process-boundary, causing them to get deleted basically immediately
after they have been created.
In short: The lock file(s) for the SQLite DB were being discarded as
soon as fork() was called on Unix systems. Thus the DB connection was a
ghost connection and accessing the DB from somewhere else (e.g. CLI)
would likely cause DB corruption because of missing locks.
Because this only happened when calling fork(), Debug builds are
unaffected since they always run in foreground mode which never calls
fork().
The underlying issue here is that an open SQLite connection should
have a read POSIX lock on the database file. Because we were calling
fork() and then _exit() **after** taking out these locks (which was done
when creating the ServerDB object), the locks were being released.
POSIX locks are super easy to get wrong. This is a nice rant about how
they stink: http://0pointer.de/blog/projects/locking.html
Not having a read lock when you have an open connection probably can
cause all kinds of issues, but with WAL it is particularly bad because
the WAL file is deleted when the last connection closes. The server's
connection to the database is like a ghost connection that nobody
knows about, so any CLI (or other server-external) DB access ended up
deleting the WAL file (i.e. committing everything in it to the main
database). Of course, server still had the WAL file opened. Bad things
happen after that.
The fix is making sure that the ServerDB object is created _after_ the
fork happens so that the locks created by SQLite will not have to cross
the process-boundary, causing them to get deleted basically immediately
after they have been created.
For most images, this results in far better legibility, especially if
they contain text, such as memes or web comics - you
currently need to squint at the screen often, because it's always sized
down to 480x270.
People with windows smaller than that will get a horizontal scroll.
Scrolling is still better than having an image that's illegible because
it's too small, and small images will never be scaled up this way.
800x600 should be okay since 1920x1080 is a very common desktop
resolution by now.
This is a stopgap measure until images can be sized per client.
See also #4830.
The commit style checker had a hard-coded assumption that the changes
were made against the master branch. For backports that is not the case
though and that's why the script fails for backports as soon as the
master and the backport branch have diverged.
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Matthaiks <kitynska@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/pl/
Translation: Mumble/Mumble Client
Currently translated at 76.0% (1555 of 2045 strings)
TRANSLATION: Update Korean translation
Currently translated at 71.3% (1459 of 2045 strings)
TRANSLATION: Update Korean translation
Currently translated at 68.8% (1407 of 2045 strings)
TRANSLATION: Update Korean translation
Currently translated at 66.8% (1367 of 2045 strings)
TRANSLATION: Update Korean translation
Currently translated at 65.3% (1337 of 2045 strings)
TRANSLATION: Update Korean translation
Currently translated at 63.9% (1308 of 2045 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Linmalu(린마루) <gkdwns0103@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/ko/
Translation: Mumble/Mumble Client
The units of the settings for positional audio were displayed behind the
SpinBox as an additional label.
This commit removes the labels and instead uses the "suffix" field of
the SpinBoxes to display the unit directly in the SpinBox itself.
In principal this also has the potential to fix the issue of the unit
being placed incorrectly when an right-to-left locale is being used as in
that case Qt should put the suffix on the other side.
Note that this has not been verified though.
PluginComponents uses this check to determine if Qt library is already used so we don't want to force a Qt include.
Unity build triggered this since I believe it moved the header into a different compilation unit or compiled it first.
QT_VERSION requires #include <QtGlobal> before using it.
From: https://stackoverflow.com/questions/24899558/how-to-check-qt-version-to-include-different-header
QT_CORE_LIB is set by CMake
From: https://stackoverflow.com/questions/30840176/what-preprocessor-can-i-used-to-detect-if-qt-is-used-to-build-my-codes
Alternate solution could be using __if_include per https://forum.qt.io/post/564320 . But that appears to require C++17 mode.
Error log:
In file included from src/mumble/CMakeFiles/mumble.dir/Unity/unity_1_cxx.cxx:4:
... /src/mumble/PluginInstaller.cpp: In member function ‘void PluginInstaller::init()’:
... /src/mumble/PluginInstaller.cpp:149:92: error: no matching function for call to ‘QString::QString(mumble_version_t&)’
149 | .arg(pluginVersion == VERSION_UNKNOWN ? "Unknown" : static_cast< QString >(pluginVersion))
Co-authored-by: Robert Adam <dev@robert-adam.de>
lintian ran on the Ubuntu ppa build had the following warning:
dpkg-shlibdeps: warning: debian/mumble/usr/lib/mumble/libcelt0.so.0.7.0 "contains an unresolvable reference to symbol sin: it's probably a plugin"
Celt CMake build was missing the link to the math library.
See for more information:
https://hsf-training.github.io/hsf-training-cmake-webpage/aio/index.html#aside-linking-to-math
Co-authored-by: Robert Adam <dev@robert-adam.de>
These two QEvents are overridden by the defines in X11 causing unity build errors.
In file included from ../src/mumble/GlobalShortcut_unix.h:13,
...
... /src/mumble/CustomElements.cpp: In member function 'virtual bool ChatbarTextEdit::event(
... /src/mumble/CustomElements.cpp:234:29: error: expected unqualified-id before numeric constant
234 | if (evt->type() == QEvent::KeyPress) {
...
... /src/mumble/Log.cpp: In member function 'void LogDocument::finished()':
... /src/mumble/Log.cpp:880:37: error: expected unqualified-id before numeric constant
880 | QEvent *e = new QEvent(QEvent::FontChange);
Moved ${SHARED_HEADERS} from PUBLIC to PRIVATE in target_sources for the main CMakeLists.txt
Rational:
"You don't need to make headers public when using target_sources().
It should be very rare that you ever need to use anything by[sic] PRIVATE with target_sources().
One of the few cases where there might be justification for a non-PRIVATE use would be for a header-only (INTERFACE) library.
Outside of that scenario, I would only use PRIVATE." - Craig Scott
"... Thanks, it works now and the compile time has decreased by 80%." - frozen-void
From: "Unity builds fail for Qt based static libraries" https://gitlab.kitware.com/cmake/cmake/-/issues/20489
Similar discussion here: https://discourse.cmake.org/t/target-sources-and-header-visibility/2096
"The PRIVATE and PUBLIC keywords specify where those corresponding sources should be used.
PRIVATE simply means those sources should only be added to myLib, whereas PUBLIC means those sources should be added to myLib and to any target that links to myLib.
...
In practice, sources will almost always be PRIVATE, since they shouldn't generally be added to anything that links against the target.
...
Do not confuse the PRIVATE , PUBLIC and INTERFACE keywords with whether a header is part of the public API for the library or not, the keywords are specifically for controlling which target(s) the sources are added to in this case."
From: https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/
Error Log:
[237/431] Linking CXX executable tests/TestCrypt
FAILED: tests/TestCrypt
...
... /release/src/shared_autogen/EWIEGA46WW/moc_LogEmitter.cpp:98: multiple definition of 'LogEmitter::metaObject() const';
... /release/src/shared_autogen/EWIEGA46WW/moc_ServerResolver.cpp:98: multiple definition of 'ServerResolver::metaObject() const';
... /release/src/shared_autogen/EWIEGA46WW/moc_LogEmitter.cpp:129: multiple definition of 'LogEmitter::newLogEntry(QString const&)';
... /release/src/shared_autogen/EWIEGA46WW/moc_ServerResolver.cpp:129: multiple definition of 'ServerResolver::resolved()';
... /release/src/shared_autogen/EWIEGA46WW/moc_ServerResolver.cpp:66: multiple definition of 'ServerResolver::qt_static_metacall ...
... /release/src/shared_autogen/EWIEGA46WW/moc_LogEmitter.cpp:67: multiple definition of 'LogEmitter::qt_static_metacall ...
... /release/src/shared_autogen/EWIEGA46WW/moc_ServerResolver.cpp:103: multiple definition of `ServerResolver::qt_metacast ...
... /release/src/shared_autogen/EWIEGA46WW/moc_LogEmitter.cpp:111: multiple definition of `LogEmitter::qt_metacall ...
... /release/src/shared_autogen/EWIEGA46WW/moc_ServerResolver.cpp:111: multiple definition of `ServerResolver::qt_metacall ...
We were seeing errors like
could not access /Volumes/Mumble 1.4.0~2021-05-16~g789f2d79e~snapshot/Mumble.app/Contents/MacOS/Mumble - No space left on device
hdiutil: create failed - No space left on device
every now and then when attempting to package the DMG package for macOS.
Following the trick described at
www.apple.stackexchange.com/a/177071/417917, we now add the
-megabytes option to the call which seems to fix the issue somehow.
This PR also reverts 0b75cd6 which failed to solve the issue.
We were seeing errors like
could not access /Volumes/Mumble 1.4.0~2021-05-16~g789f2d79e~snapshot/Mumble.app/Contents/MacOS/Mumble - No space left on device
hdiutil: create failed - No space left on device
every now and then when attempting to package the DMG package for macOS.
Following the trick described at
https://apple.stackexchange.com/a/177071/417917, we now add the
-megabytes option to the call which seems to fix the issue somehow.
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2045 of 2045 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Matthaiks <kitynska@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/pl/
Translation: Mumble/Mumble Client
Currently translated at 99.9% (2043 of 2045 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2043 of 2045 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2043 of 2045 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2043 of 2045 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2043 of 2045 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2043 of 2045 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2043 of 2045 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2043 of 2045 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2043 of 2045 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Robert Adam <dev@robert-adam.de>
Co-authored-by: Translator <weblate.gledy@aleeas.com>
Co-authored-by: gitgrub <gitgrub.email@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/de/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2045 of 2045 strings)
TRANSLATION: Update Turkish translation
Currently translated at 100.0% (2045 of 2045 strings)
Co-authored-by: Oğuz Ersen <oguzersen@protonmail.com>
Co-authored-by: udo pton <udopton@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/tr/
Translation: Mumble/Mumble Client
