| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We used to use a self-hosted macOS CI runner but since we were only
using that for Nightly builds, we frequently ran into situations where
some issue was only appearing there which meant that while for the PR
the CI succeeded, it would fail after the change had been merged in.
As this is not a desirable situation, this commit makes sure that we are
using the same macOS runner for all CI runs. For simplicity we are using
the Azure hosted ones for that purpose.
|
|
|
|
f999081ab82d0a70843036bd2ebb2629921facde enabled the MySQL plugin for Qt.
Turns out its master dependency (libmysql) cannot be built for x86:
https://github.com/microsoft/vcpkg/issues/11214
This issue leaves us with two choices:
1. Get rid of x86 builds altogether.
2. x64 builds with MySQL plugin, x86 ones without. Potential confusion.
We asked on our Matrix channel whether anyone used official x86 releases.
Nobody did, which is a very good thing considering x86 (32 bit) CPUs are no more.
In addition to that, Microsoft dropped the platform with Windows 10 2004.
|
|
|
|
The automatic upgrade from VS2019 to VS2022 broke our build and in order
to prevent that in the future, we now pin the used VS version to 2022.
Later upgrades will have to be performed explicitly.
|
|
The gRPC implementation never left the experimental state and never
reached a properly stable state to the point where we would feel good
about enabling it by default. In addition to that, there has been no
further attempts at finding and fixing the encountered issues in the
implementation (except #3947 but that was discontinued).
As such we had an essentially unmaintained piece of code in our server
implementation that was known to be buggy and that nobody wanted to fix.
In addition to that the implementation itself could not be considered
very clean or elegant and therefore only represented a few smelly
corners in our code base.
For this reason, we decided to remove the gRPC support entirely from
Mumble (for now).
What we hope to gain by that is:
- Prevent people from building unstable server versions and then coming
to us complaining that it crashed/misbehaved
- Removing (essentially) dead code
- Reduce the RPC implementation complexity
That last piece is crucial: By removing gRPC support we reduce the
amount of supported RPC frameworks to only one (ignoring DBus for now).
Our future plans include a refactoring of how RPC is being handled and
implemented and only having to worry about maintaining compatibility
with one RPC system is much easier than having to worry about two (with
(slightly) different APIs).
Once the RPC implementation has been rewritten, more RPC backends may be
reintroduced and in that process we might investigate adding a proper
gRPC implementation to the code (that then hopefully is more stable than
the current one).
Fixes #4567
Fixes #4197
Fixes #3496
Fixes #3429
Fixes #3265
|
|
This PR streamlines the settings format on all OS and (hopefully) increases the readability
of the settings file A LOT (more or less self-explaining settings identifiers instead of some
weird terms or variable names only understood by the core devs themselves (if at all)).
In addition to and surrounding this feature, several changes, improvements and fixes on
the general topic of handling settings are included as well. See individual commit messages
for details.
Fixes #1940
As an aside: This change is an important step towards being able to provide portable Mumble
installations.
|
|
This flag makes sure that the verbose output of running the test cases
is not shown, unless the test fails. In that case the full output is
displayed (for that test case).
|
|
|
|
We can't enable the elevation option by default, since it can only be
used when the binary is properly signed (otherwise Windows would just
hard-crash the application).
However, we're only using AppVeyor to build release artifacts and have
the signing process included in the automation. Therefore, it makes
sense to enable this option on all AppVeyor builds.
|
|
These are much easier to read and match default behaviour in git.
|
|
|
|
|
|
ef045be7fe04657e27141922000d84a144b75c26 changed how the
mumble-version.py script works, but these two scripts have not been
adapted to it yet. This commit fixes that.
|
|
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.
|
|
|
|
|
|
The packaging of the AppImage did not yield usable binaries for a long
time now but it does take up a significant amount of time in the Linux
CI and (more importantly) tends to fail every now and then causing the
entire build to fail with it.
For this reason, we will no longer bundle an AppImage at least until we
properly fixed the underlying issues and are able to produce working
AppImages again.
|
|
|
|
This commit also ensures we only use variables defined in the configuration file(s).
WixSharp is updated to the latest version.
|
|
This commit introduces a new plugin framework into the codebase of the
Mumble client. Note that "plugin" here really refers to a (more or less)
general purpose plugin and is therefore not to be confused with the
previously available positional data plugins (only responsible for
fetching positional data from a running game and passing that to
Mumble).
The plugin interface is written in C, removing the compiler-dependence
the old "plugins" had. Instead plugins can now be written in an
arbitrary language as long as that language is capable of being compiled
into a shared library and also being capable of being C-compatible.
As already indicated a plugin is essentially a shared library that
provides certain functions that allow Mumble to interface with it.
Inside Mumble the so-called PluginManager is responsible for managing
the plugins and relaying events to the respective callbacks. Plugins
themselves can also interact with Mumble on their own initiative by
using the provided API functions.
Fixes #2455
Fixes #2148
Fixes #1594
Fixes #2051
Fixes #3742
Fixes #4575
Fixes #4751
|
|
Apparently the first commit (59ae429972c16c377135bcccfee646b7df446933)
did not include all files.
Furthermore the used script tended to produce funny results in certain
cases. This has been fixed and as a result thereof a few more changes
were made in this second run.
|
|
On our self-hosted macOS runner we were seeing issues due to the
workspace not being cleaned up after each run, causing the next one to
fail.
This commit makes sure that Azure will clean the entire workspace of any
remaining files, before starting a new job.
Ref: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#workspace
|
|
In this mode the sametext heuristic is disabled which _should_ fix the
issue of the Weblate PR's CI failing because of Weblate not applying
such heuristics.
|
|
The variable holding the directory to change into to run the tests in,
had a typo in its name, causing the cd to fail. Therefore no tests were
found and run.
|
|
Now the stages building, testing and releasing are separate steps in all
CI runs, allowing to see more quickly where something failed and how
long each stage took.
|
|
On Linux (using shared library dependencies) this reduced the average
compilation time to about 50% of the originally needed time.
|
|
translation files
* Replace the Linux bash script `scripts/updatetranslations.sh` with a platform independent python script
* Update all translation files with text changes (translation source texts)
* Drop the ts file numerus fixup which was a Transifex workaround
See the individual, ordered commits for extensive explanation on the plural forms and numerus hack, its removal, and reasoning for updating all ts files rather than just one.
Updating all ts files will significantly reduce the diffs in translation PRs from Weblate (/Transifex/Manual), and split concerns.
After this change we still use mumble_en.ts as a base, but this can probably be dropped with additional work afterwards too to simplify and clean up the whole process.
As our ts files are mostly very outdated (even the translation source text in the files was previously only updated with translation updates) the translation update is split into multiple commits, gradually enabling heuristics on lupdate to like we used them before, to make it more obvious what is an update vs what is automatic filling.
This PR is a preparation within the context of #4727 to simplify the PR diffs of Weblate translation update PRs like the first PR #4776 where formatting changes were mixed in making it very hard to identify if the platform change actually changed anything or not.
|
|
The powershell download is incredibly slow, so we use aria2 instead that
promises to be fast.
|
|
The bash script is not platform independent. The python script is.
I invested way too much time trying to run the sh script on WSL (Windows Subsystem for Linux), installing Qt packages, but in the end still failing.
I also implemented a bat script calling lupdate with the same parameters as the sh script, but having one platform independent script is preferable to having two separate scripts for the same activity.
The python script will call lupdate to update the ts files like the sh script did,
and commit the changes if any were made.
Furthermore it checks that the ts files have no local changes before running,
and after updating reset the git index, add commit the files.
The reset operation is added so only the ts files are being committed.
Contrary to the previous script this one disables all heuristics so those can be applied as separate changes, so they will be visible.
|
|
We don't use Travis anymore and thus we don't need that dir anymore
either.
|
|
Tests that require an active internet connection will now be omitted on
CI as they recently caused a bunch of CI jobs to fail just because some
external server was unreachable.
|
|
This PR updates the copyright notices of all files. For doing so
it introduces a script that can do this automatically.
Furthermore a few files that are no longer needed got removed.
|
|
The timeout has been increased for the Windows CI builds. The new
timeouts are:
- x64: 90 minutes
- x86: 120 minutes
x86 has the higher timeout because it always takes quite a bit longer
than the x64 build.
The timeout was increased as we frequently see the CI job being
cancelled because it did not finish within the default 60 minutes
timeout.
|
|
This was done by running scripts/updateLicenseHeaders.py and then
manually editing the LICENSE file.
|
|
ba5e7bc352c979b1b90ca1cb8771d180cd6293f0 introduced such a hardening of
the CI scripts for the Windows runs. This commit adds this
functionality to the macOS script as well.
This simply causes the script to retry a download several times before
giving up. This mitigates temporary network errors (saving us a manual
restart of the CI).
|
|
The issue was introduced in ab6b6d142c3a40bd8beaa3cfdb1d16ad2002a5ed and is only cosmetic.
More specifically, the volume name is set to "Mumble " (trailing space at the end) because the version string is empty.
|
|
We often see a CI job failing because the download of part of the build
env has failed (it usually succeeds once it has been restarted). This
commit makes sure that this is tried several times before giving up.
|
|
The exit code of native commands (7zip in this case) was simply
ignored. Thus this commit makes sure these now cause the script to abort
and set the exit code accordingly.
|
|
|
|
The option replaces "--project" and allows to specify the desired string format:
- "full": The default. Prints version + suffix (e.g. "1.4.0~2021-02-14~g973cee211~snapshot").
- "version": Only prints the version (e.g. "1.4.0").
- "suffix": Only prints the suffix (e.g. "~2021-02-14~g973cee211~snapshot").
The main reason for implementing this new option is the suffix-only output.
It will be passed to CMake in a future commit, for better filename control.
|
|
Our script on the server now bumps the build number for every new version + commit combination.
Each combination is associated to a unique build number and vice versa.
The previous system didn't cause collisions, but it was very fragile.
For example, the build number got de-synced between OSes a few days ago.
It probably happened due to at least a build being restarted after the build number bump.
With the new system there should be no problems anymore, as the build number is permanent for a given identifier.
|
|
I have no idea why but these changes make this work on my Windows 10 VM.
If this really solves the issue then this is a perfect illustration for
why batch is weird.
|
|
On Windows (Batch) the syntax was correct, but mumble-version.py was not being executed due to the path using a slash instead of a backslash.
On UNIX (Bash) the syntax was incorrect: https://unix.stackexchange.com/questions/88452/concatenating-two-variables-with-an-underscore
Co-authored-by: Robert Adam <dev@robert-adam.de>
|
|
This fixes the last build failure, which was due to the job's display name containing spaces.
"x86_64" is changed to "x64" as the latter appears to be the most common identifier for the architecture, at least for Windows.
|
|
Turns out environment variables cannot be exported globally:
"/.ci/azure-pipelines/main.yml (Line: 7, Col: 1): Unexpected value 'env'"
It has to be done for each step that makes use of the variable.
Furthermore if a variable is not defined on Azure, the expansion
$(MY_VARIABLE) does not resolve to an empty String (as is the case e.g.
in Bash) but this expression is then taken literally without any
expansion at all. Therefore we have to make sure that the
BUILD_NUMBER_TOKEN variable is always defined. Thus we define it in
main-pr.yml as for PRs we don't define it on Azure.
In order for these variables to not interfere with each other, the
variable name inside the scripts was prefixed with MUMBLE_
|
|
BUILD_NUMBER_TOKEN has to be manually exported because it's a secret variable: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#secret-variables
Also, the version sent to our endpoint has to be different for each job, we want the build number to increase a single time for each pipeline.
|
|
Provide more information on translation changes.
|
