Add snapcraft.yaml and snap-utils

[iamjameswalters]

Here's my snapcraft.yaml, along with a couple of scripts borrowed from @flexiondotorg's Yaru-MATE GTK theme and icon theme snaps. It built successfully, though I haven't tested the snap it produced yet.

Pertains to #27

[lah7]

Thank you for working on this! Once I get confirmation of the snap name, I can start working on this too.

There are a few things I will need to read in the documentation, since I'm not satisfied the build side follows the best practices of packaging:

• The compiled files are being pulled remotely (Launchpad), but it should build from source.
• The version is hardcoded, I'd like it integrated with GitHub so maintenance is as simple as "promoting" a version on Snapcraft to stable. ubuntu-mate-welcome's snapcraft.yml may be useful here.

An alternate could be to adapt our build scripts to process the files into the right places, and place gtk-update-icon-update inside the YAML, to keep things tidy in the repo.

I'm not too sure what's happening with the parts section, as it looks like it's going to result in the same output, but performed several times. (Edit: I missed the colour suffix) If the idea is to offer single colour choice, it looks like Channels might be way to go. However, if it remains the case that snap themes cannot be selected in MATE's Appearance or Welcome, then the snap might as well as remain an all-in-one "compatibility" snap. < 32 MB for all colours compressed is better then 65 MiB uncompressed (and that's just one colour!)

So, it's a good starting point. Let's use this branch/PR for development prior to merging, in which our progress will be squashed into one commit.

[lah7]

I think I have the "build from source" steps just about working, but it's taking so long to build because of the virtualized environment.

In order for me to set up GitHub integration to explore those options, I need snapcraft.yaml to be in the repository, so I'll merge into a temporary branch.

[lah7]

After spending a few hours working on this today, I've decided that I'll ditch the "proper" build process and go with your original intention to pull the debs. Mainly because I just want it to "work" reliably and I don't wish to spend any more time setting up the snap after today.

I seem to having trouble getting the files to actually be included in the snap, or I get messages like:

+ snapcraftctl set-version 21.04.6.4-15-g8094c4a
Unable to set version: it was already set in the 'pull' step.

It's also looking like building Yaru-MATE isn't working properly as it outputs errors running an inkscape command.

Oh well. I'm just going to leave this attempt in the snapcraft branch and start again in a new branch snapcraft-2.

---

Instead of debs, I'll attach a complete, compressed copy in the release assets, so it'll easier to pull a complete set. If anything, this project just takes ages to build due to the sheer volume of themes/colours to process -- and that's even with me running the virtual machine in a RAM disk and temporarily processing one colour only. So, it might be for the best that this snap literally grabs and dumps.

I haven't figured out if I can still just create builds in Snapcraft without needing to use the CLI, or if Launchpad can be used.

[iamjameswalters]

One thing you might try--if you still wanted to try and get the snap to build from scratch--is running snapcraft with more resources, if you have it to spare. You can do so with some environment variables.

But if you're going to build the debs anyway, may as well consume them. 🙂

I don't know if there's a way to trigger snap builds from Launchpad, but you can use snapcraft remote-build to execute a build on Launchpad's build farm, and I suppose you might rig that up on a cronjob or something. Or, perhaps write a Github Action to do it upon new releases. 🤔

[lah7]

My system definitely has the resources, but Ubuntu isn't my host OS. 🙂 Limited (virtual) disk space and an unresponsive multipass were bottlenecks today. Only now I discovered you can use --use-lxd which is much quicker for this environment.

I tried remote building too, but the builds were failing via Launchpad too, even though local builds did succeed. Not sure if Snapcraft's server throwing Gateway Timeout could have stirred trouble. 😒

I see that ubuntu-mate-dev have a snap recipe page on Launchpad, and I could've swore I've seen the button to create recipes too at some point, but can't find it now. 🕵🏼 🔍 🤔

The snapcraft-action looks very useful for our use case, thanks for the tip!

[lah7]

Success! 🎉 ubuntu-mate-colours is live, and it works with the Firefox snap! 🌍 🔥

Just needs one additional step, which I'll add to the README:

sudo snap connect firefox:gtk-3-themes ubuntu-mate-colours:gtk-3-themes

I'll figure out the logistics of handling updates the next time there is a new release for this project. Now, if only I could have advised myself 9 hours ago to not attempt the build way. It was a learning experience, so nothing lost. 🎓

[iamjameswalters]

Huzzah! Glad this is done. Hopefully this will put things on good ground going into Jammy with Firefox shipping as a snap.

And concerning the connections: I think iterations of this incantation have made the round in several places, but here's the version from the Yaru MATE snap readme of a few bash loops to plug the theme in everywhere:

for PLUG in $(snap connections | grep gtk-common-themes:gtk-3-themes | awk '{print $2}'); do sudo snap connect ${PLUG} gtk-theme-yaru-mate:gtk-3-themes; done
for PLUG in $(snap connections | grep gtk-common-themes:gtk-2-themes | awk '{print $2}'); do sudo snap connect ${PLUG} gtk-theme-yaru-mate:gtk-2-themes; done
for PLUG in $(snap connections | grep gtk-common-themes:icon-themes | awk '{print $2}'); do sudo snap connect ${PLUG} icon-theme-yaru-mate:icon-themes; done

[lah7]

I did some testing in 21.10 and it seems that "plugging" the snaps is going to be necessary regardless of which order the snaps were installed. I've suggested ubuntu-mate/ubuntu-mate-welcome-legacy#101 which should help make this seamless for Ubuntu MATE users.

I'll update the README here so users coming here know about the situation.

[JGCarroll]

Just thought I'd drop some potential pointers to help push this snap a bit further.

There was a Snapcraft action mentioned above that could be used, I'd just thought I'd highlight there's actually a first party upstream action too which you might prefer for officialness, https://github.com/snapcore/action-build and https://github.com/snapcore/action-publish

Regarding the autoconnection, I'm under the impression there's been work recently mostly motivated around themes to create what's known as "greedy plugs". Currently, the majority of snaps will have a default theme provider in their snapcraft.yaml, pointing to gtk-common-themes, the relationship is intrinsically one to one and there is usually only one provider for the plug at a time. The greedy plug allows every theme snap to be consumed at once, hopefully preventing having to handle connections manually or push the logic into other executables.

Requesting autoconnections involves going onto the forums, https://forum.snapcraft.io, making a request that'll go to a public vote, and if it's successful, the change is handled entirely server side. Because I've not done theme snaps myself I can't be super specific on what exactly needs to be done, but I'm sure the people there would be willing to help if there was anything more involved.

There's some background reading if you're interested, as well as some preview of the future of theme support in snapd. https://snapcraft.io/blog/snaps-and-themes-on-the-path-to-seamless-desktop-integration

[iamjameswalters]

Aha, thanks for dropping by @MrCarroll !

That post mentions the plan for snapd to automatically detect if the installed theme is available on the snap store and download it, and I've seen the demo from a year ago showing this working--we've been trying to figure out: has this made it into snapd yet? Or is @lah7 's suggestion to have Ubuntu MATE Welcome install the snap alongside the deb of the theme still the way to go for now?

[JGCarroll]

I think the theme integration daemon is currently still blocked until the user daemon support in snapd isn't considered experimental. I've no idea how long this might take and so for now it's likely better to handle this with Ubuntu Mate's own tooling until snapd can figure it out itself.

At least with the greedy plug set by the store, the worry is only about the installation and removal of the snap rather than having to reapply the connections any time a new snap may be added, and the greedy plug would be needed by the theme integration daemon too when that finally arrives.