Automatic updates on Linux

• Dec 9, 2018 - 06:00
Reported version
3.x-dev
Type
Functional
Frequency
Few
Severity
S5 - Suggestion
Status
closed
Regression
No
Workaround
No
Project
MuseScore

MuseScore provides an AppImage as the official download format on Linux. The current AppImage is type 1. If this was upgraded to a type 2 AppImage then it could benefit from many of the new AppImage features, including automatic updates (e.g. via AppImageLauncher).

Creating the original AppImage was a herculean effort, but thankfully tools now exist to do the job automaticially. This means all the custom shell scripts in build/Linux+BSD/portable can be removed and replaced with a single command to run linuxdeploy on MuseScore's compiled binary, making use of linuxdeploy's official plugins for AppImages and Qt.

Comments

• Jan 6, 2019 - 19:08

See also
https://musescore.org/en/node/280926
and updated info in a comment here:
https://musescore.org/en/node/281324

By the way, linuxdeploy also works, when using its qt-plugin, but for some reasons I can't understand it does not include printsupport plugin and I couldn't find a way to stop it inserting (additional) Qt translations and copied library copyright info.
With linuxdeployqt and a successive call to appimagetool to create the AppImage and include the updating info I was able to create an AppImage, which should however still be tested under different environments.

EDIT:
The build finished and here is the resulting AppImage:
https://bintray.com/antoniobl/musescore-custom-nightlies/MuseScore_3_Po…

Reply

• Nov 9, 2019 - 12:33
Status PR created ⇒ fixed

Fixed in branch master, commit 684f641b80

_AppImage: Improve build scripts

  • fix #279707 automatic updates on Linux
    • except for Nightly Builds as this would require
      changes on the Nightly server (see PR #4757)
  • fix #271232 create type2 AppImage
  • Bundle with linuxdeploy
  • Shared Recipe for all architectures

linuxdeploy detects library dependencies and automatically puts
them in the AppImage. This makes the copy-libs scripts redundant._

Reply

• Nov 9, 2019 - 20:10

@dmitrio95, that's true for nightly builds but not for stable releases.

Basically, the updater software needs to know where to look for the latest version. GitHub Releases has an API to get the latest version, but OSU OSL is just a dumb webserver so some extra effort is required.

For stable releases, simply upload the zsync files to the GitHub Releases page alongside the main AppImage file. See this example.

For nightlies, you need to provide a stable URL that always points to the latest version. For example:

http://ftp.osuosl.org/.../MuseScore-LATEST-x86_64.AppImage
http://ftp.osuosl.org/.../MuseScore-LATEST-x86_64.AppImage.zsync

These links could be 302 temporary redirects to the most recent build on the nightlies page. However, you don't own the OSU OSL server so you probably can't create 302 redirects.

Instead of using redirects, you could simply make a second copy (or symlink) of the latest nightly files at the above locations. This is what PR 4757 attempts to do, but I can't test it because I don't have SSH credentials for the OSU OSL server.

Reply

• Nov 14, 2019 - 01:14
Status fixed ⇒ active
Reported version 3.0 ⇒ 3.x-dev

3.3.1 and 3.3.2 have been released but automatic updates didn't work for some reason. Looking in the build log for 3.3.2, it appears that the zsync delta update file was created but not uploaded to OSUOSL.

  • The zsync file is listed here in the code. The build log shows it exists.
  • The file should be uploaded here in the code, but the build log shows this didn't happen.

It might have something to do with this regex in osuosl.sh. Notice how it tries to read the architecture from the filename, and it assumes the filename ends in .AppImage. This is not true for the zysync file (it ends .AppImage.zsync). However, I would have expected to see "Error: unrecognised architecture" but we don't see this for some reason.

Maybe its not possible to call the osuosl.sh script twice? If that's the case then PR #4757 should fix it, but it needs somebody with OSUOSL credentials to test it.

Reply

• Nov 14, 2019 - 08:44

It looks like the condition

[[ -f build.release/MuseScore*.AppImage.zsync ]]

evaluates to false (or rather to exit code 1) since the asterisk sign seems to be not expanded inside the double brackets condition, and -f condition checks for the presence of literally build.release/MuseScore*.AppImage.zsync file which clearly does not exist. If single brackets syntax is used ([ -f build.release/MuseScore*.AppImage.zsync ]) then this asterisk gets expanded and -f operand has a correct filename to check for a presence of zsync file (but will fail if more than one file has a name corresponding to that pattern).

Still fixing the condition will likely result in the "unrecognized architecture" issue so that would probably need fixing too.

Reply

• Nov 25, 2020 - 08:21
Status PR created ⇒ fixed

Fixed in branch 3.x, commit e452b3ac6a

_Partial fix #279707: First steps towards automatic updates on Linux

Creates a zsync delta update file for AppImages but doesn't yet upload
it to a server._

Reply

• Dec 1, 2020 - 14:01

This is working now in the nightlies. It hopefully also works in stable releases, but since 3.6 is the first version with the update metadata, we won't know if it actually works until there is something to update to (i.e. 3.6.1 or higher is released).

Next challenge is to bundle the updater software inside the AppImage itself, firstly to update via command line, and then via the GUI like Sparkle on macOS or WinSparkle on Windows.

Reply

Fix version
3.6.0