I think getting a part would be better because then if you ask upstream to make builds it’s really easy for them because they can do it on build.snapcraft.io (which uses Ubuntu 16.04) but if no-one else comments to help you with this you could just use Ubuntu 17.04 (or 17.10 for potentially even more up-to-date dependencies) in an LXD container and make a Snap using that. Then, if you’ve made a working stable snap, you can ask upstream to use this guide to setup building Edge snaps automatically and pushing future releases to other channels.
Also you might want to edit the tag for this post to snap rather than snapcraft
I’d agree with @Ads20000, you’ll probably want something like the qt58/qt57 part extended for cmake. The Gist you mentioned is just one of my experiments, I don’t think it should be actually used in production
The problem with those parts (qt58/qt57) is that they build Qt from scratch which takes some hours. Also, you’ll probably want to modify them to only include the Qt modules you need.
After some more efforts I found out that a Qt version >= 5.6 is only needed when building the master branch, but not the current stable: 2.x
I now have a snapcraft file that uses the desktop-qt5 part and compiles the software: I still have to fiddle around with confinement and other things, but at least the application starts and seems to work (at least in my 5 minutes test)!
cups-control should be enough (the socket is in the cups-client apparmor abstraction, which is used by the cups-control interface-- incidentally, there is a bug in snappy-debug not suggesting interfaces that have rules in included abstractions). This interface is manually connected; does ‘snap interfaces’ show that musecore is connected to this interface? If not, do:
$ sudo snap connect musescore:cups-control
As for the other denial, you need to plugs the ‘network-manager’ interface. Like cups-control, it is also manually connected. Usually (but not always), network-manager denials of this form don’t result in application failure.
They require manual connections for a reason-- both give more access to the system than musecore actually needs, so the user needs to have input as to whether or not they should be connected. cups-control would allow musecore to configure printers and network-manager allows it to configure networking when all musecore needs is to be able to print or see if online.
Eventually musecore should use auto-connectable interfaces like Connectivity or Printing from Portals (or something else, like the ‘network-status’ interface). You are right that it isn’t very user-friendly atm; people are working on addressing the usability concerns so you don’t have to drop to a terminal to perform manual connections-- eg, there are forum topics on improvements to gnome-software to allow users to express their input wrt connections during the install process.
For reference: this GitHub Issue needs resolving for MuseScore to be built automatically on build.snapcraft.io and, thus, directly from upstream with no snapcrafter middleman
The problem with those parts (qt58/qt57) is that they build Qt from scratch which takes some hours. Also, you’ll probably want to modify them to only include the Qt modules you need.