[MUSE HUB] Muse Hub is packaged as .deb which excludes non deb-based Linux distributions

[sberla365]

I am running Fedora 36 and having the Muse Hub packaged as a deb is a bit of mess. I tried to unpack the deb file and manually install the files in the correct locations. This brought to permission issues (which are solved through a native installer) and had to run MH through sudo. The experience was horrible anyway. After having downloaded some sounds, they appear as not downloaded (get) in MH after restarting the application. The fonts are loaded in MU4 though.

I have repackaged the deb to rpm using alien but installing the converted rpm reports a missing dependency liblttng-ust.so.0()(64bit) The dependency is part of lttng-ust which is installed in Fedora but in its version liblttng-ust.so.1()(64bit) and it is not recognised.

My suggestion, although I am not a developer and have no experience in programming, would be to package the Hub as a universal package, such as appimage (which is already done with musescore). This would allow compatibility across linux distros and ensure the shipment of the required libraries.

[EB2000]

Hi! I have a similar problem, as I am using a fedora 35. I could create a rpm with alien: sudo alien --to-rpm --scripts muse-hub.deb I had to install lttng-ust to fix depencies. Fortunately for me, fedora 35 still uses .0 version, and not .1. Maybe you could try installing the fedora 35 packages for lttng. I also had to --force the installation of muse-hub.rpm, but this should be okay.

After all of this, I could run muse-hub: a brightly coloured window appears, offering several choices of instruments. Unfortunately, I couldn't download any instrument: when I try, I get the very unhelpful error: Something went wrong, please try again later

I'll open another bugreport about these problems. But please tell me if you manage to get muse-hub working on a fedora!

Éric Brunet

[amminadabz]

If possible, it would be best to distribute MuseHub as a distro-agnostic package. Flatpak is the favorite of most everyone that doesn't work for Canonical, at least that's my impression, and its certainly my favorite.

If a Flatpak isn't possible, then I'd consider an .rpm and a .deb to be the minimum for any application, and the Arch-based folks can maintain their own repackaged repos.

It's important to make these packages available soon, especially if you want to be well tested on the distros that will become dominant in the future: Ubuntu is falling out of favor as the Beginner's Distro and Fedora-based and Arch-based distros are on the rise among end users. I'm an engineer, not a developer, so while I feel qualified to report bugs in adequate detail, I don't feel confident enough to finagle a deb into an rpm.

tl;dr: Flatpak plz

[sberla365]

@EB2000 I don't want to mess up dependencies by installing older versions on top of the new ones. I got Muse Hub to work to some extent by extracting its content with the dpkg-deb command and then sudo copied every file in the right target destination. The only issue I have so far is that the Hub itself does not auto update. To download the sounds however, I must run sudo muse-hub-service before starting Hub. That is a horrible workaround but at least I get to have Hub to download sounds.

[sberla365]

I am also in favour of Flatpak but I would be happy with whatever universal package the developers feel comfortable working with. Appimage is not my favourite and I don't use snaps but I would be ok with both if that offered access for all Linux users. But seeing MuseScore packaged as appimage, makes me think that the competences are there already to quickly and easily have Hub packaged that way. I would also be happy with installing from tarball with an installer script. (but I don't know in that case how it works with dependencies). Deb and rpm ok too but it would mean more work for the developers, as they would have to package and test two builds

[EB2000]

@sberla365 Good for you, you managed to make it work. I could install cleanly the muse-hub packages, but it doesn't work: it fails at downloading anything, see my bug #14325. I am really curious at what is so different between our two systems. Could you post, as an attachment, the contents of your logs /srv/muse-hub/logs/current.txt and of the instruments database /srv/muse-hub/downloads/Instruments/.instruments ? (I am assuming that you downloaded all the instruments.)

Thanks, Éric Brunet

[sberla365]

@EB2000 Here are my logs. I downloaded everything but choir.

current.7.txt

I am having troubles uploading -instruments, I will try later. Have you tried invoking the systemd service through sudo muse-hub.service and running sudo muse-hub-sevice before opening Hub? I cannot download (or even have my downloaded instruments recognised in the Hub) if I don't run muse-hub-service as sudo

[sberla365]

Also, there was an update to Hub yesterday and tantacrul said we should run the latest of everything to make sounds work. The download link is on the .org announcement

[EB2000]

Thanks! I think I am using the latest muse-hub (0.9.9.295) and, yes, the background service is running. I managed to make it work by doing two things: allowing connections to my computer from the outside on my router (UPnP) and by adding a /etc/ssl/certs/ca-certificates.crt file. Not sure what did the trick; it works, I am not changing anything anymore until I have downloaded everything. Thanks for the current7.txt; don't bother with the .instrument; I don't seem to need it anymore.

[iamtesch]

Currently, non-deb systems are not supported; this is a known issue. We plan to have official non-deb system support in a future release.

As mentioned in #14325, the certificate linking change is the important one to get it working.
sudo ln -s /etc/ssl/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt

I would advise against manually copying files around, as this is not a stable approach and can lead to the hub getting out of sync with the downloads (and causing more hard to debug issues :) )

[charlesneimog]

Hiii, some update about this topic and .rpm packages?

Thanks!

[quotepilgrim]

I have managed to successfully install Muse Hub on Fedora 37 with alien and rpmrebuild. I converted it to RPM with sudo alien --to-rpm --scripts Muse_Hub.deb, then used rpmrebuild -pe muse-hub-1.0.0.392-2.x86_64.rpm to remove the conflicting files the rpm command complained about when I tried to install the package from the %files section in the spec file. Finally, I installed it with sudo rpm -i --nodeps ~/rpmbuild/RPMS/x86_64/muse-hub-1.0.0.392-2.x86_64.rpm. Bear in mind the generated RPM's filename may differ for you.

The --nodeps argument was necessary because it complained about a missing file from lttng-ust even though I have the package installed and the file exists. After installing, the muse-hub service should be enabled with systemctl enable muse-hub and then systemctl start muse-hub. The service needs to be running in order to use Muse Sounds in MuseScore, for instance.

[charlesneimog]

Thank you very much!

It works for me too!!!!

[charlesneimog]

@quotepilgrim What is the version of Musescore that are you using, I was able to install Muse-Hub, but could not use it inside Musescore. Thanks!

(muse-hub is running)...

[quotepilgrim]

@charlesneimog The latest 4.0.0 AppImage, I've just downloaded it today and figured out this whole process. You can enable Muse Sounds under "view > playback setup". If it's greyed out, the service probably isn't running, so make sure it is with systemctl start muse-hub

[frafra]

It still seems that Musescore is not able to discover muse-hub-service here on Fedora 36. Certificates are fine, and Muse Hub is able to download the data. I tried to use strace -e trace=network ./MuseScore-4.0.0-x86_64.AppImage to better understand what could have gone wrong, but I haven't got anything worth noting.

[cesarizu]

I had to manually "unzip" musesampler-linux-0.3.1.17.zip found somewhere inside /srv/muse-hub/downloads/Installers/, which is actually a .tar.gz file onto /usr/local/lib64/ to make it work.

(version number in the file might differ)

[cesarizu]

One liner to do that, run as root (or with sudo): tar zxf "$(find /srv/muse-hub/downloads/Installers/ -name "musesampler-linux*.tar.zip")" -C /usr/local/lib64/ --keep-newer-files

[aspiers]

I tried the alien approach detailed above on openSUSE Tumbleweed but had no luck so far. I managed to build and rebuild the muse-hub rpm, but trying to install it yielded:

error: Failed dependencies:
    liblttng-ust.so.0()(64bit) is needed by muse-hub-1.0.0.392-2.x86_64

Unlike @quotepilgrim, my system has version 1 of liblttng-ust rather than 0:

-rwxr-xr-x 1 root root 489K Oct  4 19:39 /usr/lib64/liblttng-ust.so.1.0.0*

Overriding this with --nodeps allowed installation, but then the service fails to start:

Dec 17 00:17:29 aegean systemd[1]: Started Muse Hub Helper Service.
Dec 17 00:17:29 aegean muse-hub-service[3541]: Stack overflow.
Dec 17 00:17:29 aegean muse-hub-service[3541]: Repeat 174473 times:
Dec 17 00:17:29 aegean muse-hub-service[3541]: --------------------------------
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher+RunningInstance+WatchedDirectory.Write(System.Text.StringBuilder, Boolean)
Dec 17 00:17:29 aegean muse-hub-service[3541]: --------------------------------
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher+RunningInstance+WatchedDirectory.GetPath(Boolean, System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher+RunningInstance.AddDirectoryWatchUnlocked(WatchedDirectory, System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher+RunningInstance.AddDirectoryWatchUnlocked(WatchedDirectory, System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher+RunningInstance.AddDirectoryWatchUnlocked(WatchedDirectory, System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher+RunningInstance..ctor(System.IO.FileSystemWatcher, Microsoft.Win32.SafeHandles.SafeFileHandle, System.String, Boolean, System.IO.NotifyFilters, System.Threading.CancellationToken)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher.StartRaisingEvents()
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher.StartRaisingEventsIfNotDisposed()
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.IO.FileSystemWatcher.set_EnableRaisingEvents(Boolean)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.TryEnableFileSystemWatcher()
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.CreateFileChangeToken(System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.FileProviders.PhysicalFileProvider.Watch(System.String)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Configuration.FileConfigurationProvider.<.ctor>b__1_0()
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Primitives.ChangeToken+ChangeTokenRegistration`1[[System.__Canon, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]..ctor(System.Func`1<Microsoft.Extensions.Primitives.IChangeToken>, System.Action`1<System.__Canon>, System.__Canon)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Primitives.ChangeToken.OnChange(System.Func`1<Microsoft.Extensions.Primitives.IChangeToken>, System.Action)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Configuration.FileConfigurationProvider..ctor(Microsoft.Extensions.Configuration.FileConfigurationSource)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Configuration.Json.JsonConfigurationProvider..ctor(Microsoft.Extensions.Configuration.Json.JsonConfigurationSource)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Configuration.Json.JsonConfigurationSource.Build(Microsoft.Extensions.Configuration.IConfigurationBuilder)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Hosting.HostBuilder.BuildAppConfiguration()
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Microsoft.Extensions.Hosting.HostBuilder.Build()
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Program+<<Main>$>d__0.MoveNext()
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[[Program+<<Main>$>d__0, Muse.Service, Version=1.0.0.392, Culture=neutral, PublicKeyToken=null]](<<Main>$>d__0 ByRef)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.Int32, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].Start[[Program+<<Main>$>d__0, Muse.Service, Version=1.0.0.392, Culture=neutral, PublicKeyToken=null]](<<Main>$>d__0 ByRef)
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Program.<Main>$(System.String[])
Dec 17 00:17:29 aegean muse-hub-service[3541]:    at Program.<Main>(System.String[])
Dec 17 00:17:29 aegean systemd[1]: Started Process Core Dump (PID 3553/UID 0).
Dec 17 00:17:29 aegean systemd-coredump[3554]: Process 3541 (Muse.Service) of user 0 dumped core.

                                               Module linux-vdso.so.1 with build-id 970de97f7d924e6cb173826b468c62f9b9823963
                                               Module libicui18n.so.71 with build-id 6e0626096dd138390c38fd4b458a6d32fe60a73a
                                               Module libicudata.so.71 with build-id ebd95a91f2e475033431922b125ef73f06b64c3f
                                               Module libicuuc.so.71 with build-id a705117f4d248b308cbb6ca389ed2200fc0b9e9a
                                               Module libSystem.Native.so with build-id 548efd216c4ff31a0f12afc1230c1adb83e82768
                                               Module libclrjit.so with build-id 76621d87c473f812e6b8a8ab7a603696870a1676
                                               Module librt.so.1 with build-id 171849d55d724288e7caaa0dc35144c446d727da
                                               Module libcoreclr.so with build-id ef0ddda91ebee8c2e34c71b868309023abb3fc24
                                               Module libhostpolicy.so with build-id 9f51fac0df7192c2e1d758ad2fa4735b4d2f55c1
                                               Module libhostfxr.so with build-id 44ac737f5dd4c1f89d74b8102c9844de264123fd
                                               Module ld-linux-x86-64.so.2 with build-id b7d99dc295f74348b9ecbd1f2113c99e4e44af7f
                                               Module libc.so.6 with build-id 8ad4b412bfd8652bf0aef6a72fc69d27544287de
                                               Module libgcc_s.so.1 with build-id e89ad2ad12dd6e8d97dd5f6ba53607a0b28592b8
                                               Module libm.so.6 with build-id 83bd89671653f9bd07c6ed75b54b25b433e03b0f
                                               Module libstdc++.so.6 with build-id 7a436b925867386356c0f62aa821c2b4c774bb30
                                               Module libdl.so.2 with build-id fa31f94cb2c76a30e88ee2b098bb5cde20db2cdb
                                               Module libpthread.so.0 with build-id bb45cc90f80de5167e8483c9b4290077e9103d53
                                               Module Muse.Service with build-id 94f8e8a984f521f76b60d7fe6dcdc0988484586e
                                               Stack trace of thread 3541:
                                               #0  0x00007fddac3536bc __pthread_kill_implementation (libc.so.6 + 0xa96bc)
                                               #1  0x00007fddac3006f6 raise (libc.so.6 + 0x566f6)
                                               #2  0x00007fddac2e9814 abort (libc.so.6 + 0x3f814)
                                               #3  0x00007fddabfb99db n/a (libcoreclr.so + 0x5129db)
                                               #4  0x00007fddabfb9910 n/a (libcoreclr.so + 0x512910)
                                               #5  0x00007fddabc9d451 n/a (libcoreclr.so + 0x1f6451)
                                               #6  0x00007fddabd7ae38 n/a (libcoreclr.so + 0x2d3e38)
                                               #7  0x00007fddabf82dc1 n/a (libcoreclr.so + 0x4dbdc1)
                                               #8  0x00007fddabf84aa5 n/a (libcoreclr.so + 0x4ddaa5)
                                               #9  0x00007fddabf84876 n/a (libcoreclr.so + 0x4dd876)
                                               #10 0x00007fddabfc0346 n/a (libcoreclr.so + 0x519346)
                                               #11 0x00007fdd32f97ae1 n/a (n/a + 0x0)

I'm not sure if that was caused by the wrong version of liblttng-ust but the stack trace seems to suggest otherwise.

In any case, while starting the service via systemd fails in this manner, weirdly it works if I su to root and manually run muse-hub-service. At that point it fails with a certificate error until I run:

ln -s /var/lib/ca-certificates/ca-bundle.pem /etc/ssl/certs/ca-certificates.crt

Then restarting it seems happy, and I can then run muse-hub non-root to get the downloader UI, which seems to be successfully downloading sounds.

[charlesneimog]

In my machine it is possible to download all sounds, but Musescore is not recognizing the Music Sounds.

I am on Fedora 37!

[aspiers]

In my machine it is possible to download all sounds, but Musescore is not recognizing the Music Sounds.

I had this too, until I ran the command from @cesarizu above and then did sudo ldconfig to make sure the linker picked up the library (although this may well be overkill). This shows it working:

$ ldconfig -p | grep Muse    
    libMuseSamplerCoreLib.so (libc6,x86-64) => /usr/local/lib64/libMuseSamplerCoreLib.so

Then after restarting MuseScore it worked! My old scores sound amazing, so happy to hear this after waiting so eagerly for so long. Massive kudos to the MS team for this incredible leap forwards!

[charlesneimog]

For me, if I save one score on Windows with MuseSounds, I am able to use musesonds on fedora. :)

[MTRNord]

While a lot of the above is about fedora in general, I am using fedora silverblue, so I am partially bound to the Flatpak ecosystem. It would be nice if this could also be integrated with the existing flatpak. :) I assume it may need some extra work there, though, as Flatpaks usually are somewhat isolated to each other.

[eshom]

Another solution would be to create an AppImage for Muse Hub. There is one for MuseScore, so why not Muse Hub?

It also might be a good idea to request MuseScore package maintainers from Fedora/openSUSE etc. to package Muse Hub too, if it's not too much trouble, and add it as a recommended package (becasue it is not an actual dependency for MuseScore.

[LGFae]

Incidentally, could someone point out to me where the code for musehub is? I've tried searching for it in this repo and in the others musescore repos but just couldn't find it. I was planning on just compiling/installing it myself to use it on my machine.

[sherlockholmestech]

Incidentally, could someone point out to me where the code for musehub is? I've tried searching for it in this repo and in the others musescore repos but just couldn't find it. I was planning on just compiling/installing it myself to use it on my machine.

Sadly it is closed-source (as of now).

[EB2000]

It also might be a good idea to request MuseScore package maintainers from Fedora/openSUSE etc. to package Muse Hub too, if it's not too much trouble, and add it as a recommended package (because it is not an actual dependency for MuseScore.

Actually, the simplest solution would be for distributions to package the sound files and the muse-sampler library, and to skip musehub entirely.

As far as I understand, musehub's purpose is to download, install and check for updates sound files and the library. This is exactly the role of the package manager in any distribution.

The one originality of muse-hub is to also be a bittorrent server: this means that when you download a sound file, it might come from the computer of another user of muse-hub. Also, when other people download a sound file, it might come from your computer. Bandwidth is being shared between all users. Now, that made a lot of sense in early stages: those files are huge, and everybody downloading them at once could have strained the musescore servers without the bittorrent trick. But if the sound files are packaged by fedora/opensuse/debian/ubuntu/etc., they will be on their servers, not musescore's, and I don't understand the point of musehub anymore. Could someone enlighten me ?

[huantianad]

Sadly it is closed-source (as of now).

I wonder why this fact seems to be so hidden. MuseScore has been so praised because it is a FOSS app, and yet they create this proprietary app that is required if you want to use extra features, but don’t announce that it’s closed source at all! It feels quite dishonest, there no mention of it being closed on the website or in any announcement I can see.

The quite basic support for Linux could be chalked up to simply not caring about Linux as much in general, but I can’t help but assume the worst and say they don’t want to distribute the components directly because they would like people locked into their ecosystem.

once again, that would be assuming the worst. I hope as much as anyone else that then simply haven’t gotten to making the app open source yet.

[MarcSabatella]

The status of Muse Sounds and Muse Hub as closed source is no secret, it’s been public knowledge for well over a year since first announced on the forums. So rather than speculate, you might amwabt to just search out the previous announcements and discussions over the past year or two.

[LGFae]

The status of Muse Sounds and Muse Hub as closed source is no secret, it’s been public knowledge for well over a year since first announced on the forums.

Apologies if this sounds harsh, but being in the forums is not the same as being publicly recognized by the project itself. Musescore likes to market itself as being free and open source, yet it won't clearly disclose a very relevant part of its software is closed source. Saying "you can find out if you search the forums" is not a decent answer to this.

In my opinion, musescore can be fully open source, stop marking itself as such, or put a clear, explicit, visible disclaimer that Muse Hub is not open source. What's currently happening is that musescore wishes to benefit from the publicity of being open source, without fully being so.

[jeetee]

Muse Hub is not MuseScore and entirely optional, just like any VST is entirely optional or any soundfont is.

In the meantime, the Muse Hub team has their own support tracker at https://musehub.zendesk.com/ so you might want to consider adding your voices to the existing tickets over there and/or create a new one there if relevant.

[MarcSabatella]

How is posting to the forums not stating this publicly? Where else were you expecting to see relevant statements posted? The forums have always been the primary means of communication for the MuseScore project, since even before the release of 1.0.

Anyhow, as mentioned, Muse Hub is not MuseScore. MuseScore is fully open source. The fact other non open source apps also happen to be released by the same company isn’t new - it’s been this way since the mobile apps released a decade ago.

[LGFae]

Where else were you expecting to see relevant statements posted?

In the Muse Hub website's front page, in the musescore website's front page, in the official announcements of musescore 4. I am not claiming the information is not available, I am claiming it is not as publicized as some other things. In particular, I really think a disclaimer in the Muse Hub website itself, or in the links to it from musescore4, should exist. As it stands, musescore4 will just happily forward you over, and you won't really know you are now suddenly dealing with non-open-software, because musescore markets itself as such.

Furthermore, musescore has also attached its brand to the Muse Hub software. So it appears to me that, for an outsider, it is a reasonable assumption that, well, since Muse Hub is sort of part of the musescore ecosystem, it is also open source, no? Which leads me to...

Anyhow, as mentioned, Muse Hub is not MuseScore. MuseScore is fully open source. The fact other non open source apps also happen to be released by the same company isn’t new - it’s been this way since the mobile apps released a decade ago.

I do not have a problem with this; I even have multiple proprietary softwares running in my system. My problem is the public marketing. Sure, you put it in the forums, which is the place everyone who follows the project would look at for this. But, what about everyone else? For example, I don't really follow the project, I just use the software. I was sure Muse Hubs would be somewhere in the musescores repos, since everyone always praises musescore for being open source, and like I said earlier, Muse Hub appears to be part of the Musescore overall ecosystem.

If you want to make it closed source, sure, go for it. I don't have a big problem with that. But I really do believe there should be a visible disclaimer somewhere in this whole thing, and not simply "in the forums".

In any case, I apologize for derailing the conversion; this issue wasn't really about this in the first place.

[leha-bot]

We may just write a proper RPM for Fedora, but I can't find the actual sources. Are they open at all and which kind of license??

UPD: missed the statement about the proprietariness. Don't surprised.

I suggest to avoid the direct launching the deb and use the Flatpak or similar things.

[xvitaly]

By the way, there is a packaged version of Muse Score in the Fedora repository:

sudo dnf install mscore

[charlesneimog]

version 3.6 not 4

[xvitaly]

version 3.6 not 4

Yes. Most distributions prohibit updating packages to major versions in released branches.

[amminadabz]

To get things back on topic and see how things are progressing:

@iamtesch Has there been any progress made on an RPM or distro-agnostic package? Is there a plan for Hub to become open-source in the future so that it can be repackaged and hosted in distro repositories?

[xvitaly]

in the future so that it can be repackaged and hosted in distro repositories?

All packages in distribution repositories must be built from sources.

[tobfos2611]

I have managed to successfully install Muse Hub on Fedora 37 with alien and rpmrebuild. I converted it to RPM with sudo alien --to-rpm --scripts Muse_Hub.deb, then used rpmrebuild -pe muse-hub-1.0.0.392-2.x86_64.rpm to remove the conflicting files the rpm command complained about when I tried to install the package from the %files section in the spec file. Finally, I installed it with sudo rpm -i --nodeps ~/rpmbuild/RPMS/x86_64/muse-hub-1.0.0.392-2.x86_64.rpm. Bear in mind the generated RPM's filename may differ for you.

The --nodeps argument was necessary because it complained about a missing file from lttng-ust even though I have the package installed and the file exists. After installing, the muse-hub service should be enabled with systemctl enable muse-hub and then systemctl start muse-hub. The service needs to be running in order to use Muse Sounds in MuseScore, for instance.

When I try installing, I get: file /usr/bin from install of muse-hub-1.0.0.392-2.x86_64 conflicts with file from package filesystem-3.18-2.fc37.x86_64 file /usr/lib from install of muse-hub-1.0.0.392-2.x86_64 conflicts with file from package filesystem-3.18-2.fc37.x86_64

[frafra]

When I try installing, I get: file /usr/bin from install of muse-hub-1.0.0.392-2.x86_64 conflicts with file from package filesystem-3.18-2.fc37.x86_64 file /usr/lib from install of muse-hub-1.0.0.392-2.x86_64 conflicts with file from package filesystem-3.18-2.fc37.x86_64

There are some folders that should be excluded, like the /usr/bin, as they are claimed by filesystem. Just delete them from the spec file and try again. It worked for me in Fedora 36, together with unpacking musesampler, using ldconfig and starting the service.

Edit: text in italics has been added afterward

[xvitaly]

Just delete them and try again.

Don't do this. You will break the system. Also, no one should use the alien tool as it always creates bogus RPMS.

[frafra]

Just delete them and try again.

Don't do this. You will break the system. Also, no one should use alien.

I meant from the spec file, when using rpmrebuild, as mentioned in the previous comments. I clarified my comment.

alien is not a great solution, but I have musescore 4 working on Fedora 36 :) User not familiar with RPM that are not comfortable with the possibility of having to fix their system because of a problematic package should avoid this discussion entirely until a proper RPM is released.

[quotepilgrim]

Also, no one should use the alien tool as it always creates bogus RPMS.

I have used alien + rpmrebuild for multiple packages, and it never caused any issues on my system, so I would argue it's probably safe most of the time. YMMV, of course.

[eshom]

On openSUSE Tumbleweed, I followed the steps suggested above with alien + rpmrebuild.

Then the following hacks were required for me:

1. Ignore liblttng-ust dependency warning during rpm package install.
2. Symlink ca-bundle.pem: /etc/ssl/ca-bundle.pem -> /var/lib/ca-certificates/ca-bundle.pem
3. Symlink libMuseSamplerCoreLib.so: /usr/lib64/libMuseSamplerCoreLib.so -> /usr/lib/libMuseSamplerCoreLib.so
4. Disable systemd service: muse-hub.service # systemctl disable muse-hub (Might as well remove it during rpmrebuild stage.

And then you need to run muse-hub-service manually as root (think twice before doing this - see below). The systemd service did not work for me. I also don't see any point enabling the service in the first place. You only need to download the instrument once, and when you want to update instruments. No point having it in the background 24/7.

In addition, why muse-hub-service needs root in the first place. Because it downloads to /srv/muse-hub/? MuseScore and Muse Hub ought to work fine downloading instruments to user's home directory under .local/share/muse-hub or something similar that would make sense. Probably need to make this a separate issue.

Similar concern for macOS: https://musehub.zendesk.com/hc/en-gb/community/posts/8359290491805 Raised here: https://musehub.zendesk.com/hc/en-gb/community/posts/8450771193629-MuseHub-runs-with-excessive-privileges-on-Linux-and-MacOS-posing-a-serious-security-threat

[EB2000]

I also don't see any point enabling the service in the first place. You only need to download the instrument once, and when you want to update instruments. No point having it in the background 24/7.

This. It looks like muse-hub serves no purpose other than downloading and updating the instruments and the library. All these functions should be done by the package managers of each distribution. In other words, fedora, opensuse, and all the other distributions should simply provide the packages musescore-MuseSound-[Strings|Brass|Woodwinds|Choir|Percussion|Keys|Harp].noarch.rpm, as well as musescore-MuseSound-Library.x86-64.rpm. Each time the MuseSounds are improved, an updated package can be shipped. Then, MuseHub can be completely skipped.

I think it is not a very good idea anyway to package a closed-source program running as root all the time as a system service.

Or is Muse Hub doing something else that I am not aware of ?

[LGFae]

I think it is not a very good idea anyway to package a closed-source program running as root all the time as a system service.

Agreed, and I don't think most distributions would take kindly to this either...

Incidentally, merely making the source available (not even full open source, as per the official definition) would already go a long way to solving most of these problems, since each distribution could then simply download the code, patch it according to its need, and make their package themselves. They could also create a service with the correct permissions according to the distribution's idiosyncrasies.

It would also lessen the burden of musescore's team, since they would no longer have to package it themselves anymore.

[quotepilgrim]

I also don't see any point enabling the service in the first place. You only need to download the instrument once, and when you want to update instruments. No point having it in the background 24/7.

Well, when I first tested it, Muse Sounds didn't work when I didn't have the service running. Maybe the issue was caused by something else, I dunno. If it works without having the service running, I agree, there's no reason to have it running.

[EB2000]

Well, when I first tested it, Muse Sounds didn't work when I didn't have the service running. Maybe the issue was caused by something else, I dunno. If it works without having the service running, I agree, there's no reason to have it running.

Right now, I am running MuseScore 4.0 AppImage on a fedora linux 37, and I enjoy Muse Sounds even though Muse-Hub is not even installed.

In details: I tried MuseScore Beta in early November while I was on fedora 36. I managed with some difficulty to have Muse-Hub installed and working, and could download the instruments and the library. When I upgraded to fedora 37, I had to remove muse-hub because of some conflict. But I still have on disk the /srv/muse-hub directory, and the /usr/lib/libMuseSamplerCoreLib.so library. Those might not be the latest versions (date: November 5 for the instruments, November 4 for the library), but they are working right now.

[amminadabz]

All these functions should be done by the package managers of each distribution. In other words, fedora, opensuse, and all the other distributions should simply provide the packages musescore-MuseSound-[Strings|Brass|Woodwinds|Choir|Percussion|Keys|Harp].noarch.rpm, as well as musescore-MuseSound-Library.x86-64.rpm. Each time the MuseSounds are improved, an updated package can be shipped. Then, MuseHub can be completely skipped.

I don't disagree with this stance, but I am under the impression that MuseSounds itself is closed-source (correct me if I'm wrong), so we come back to the same problem that others have pointed out: you can't repackage what you don't have the code for.

[huantianad]

Has there been any official statement about muse hub regarding this? It's hard to think of any other reason why it's locked down other than to maintain control and prevent things like proper distro tailored distribution.