Snaps officially supported by Canonical

The following is a (non-exhaustive) list of snaps published from the “Canonical” account on the Snap store, with links to their respective maintainer(s), code repositories, and bug trackers:


The list should be kept up-to-date, in alphabetical order, and with supporting entries for packaging metadata and official maintainers. Adding a new snap to the above list means there’s commitment from Canonical to maintain and support it.

Initially, the snap can be uploaded under a personal account, with its ownership subsequently transferred to the shared canonical account. Through the use of the accounts’ collaboration feature, any number of developers can contribute to it and upload new versions.

If a snap needs to be removed:

  • strikethrough its name using [s]snapname[/s]
  • provide a reason for its removal, and why maintenance is no longer being provided
  • add a timestamp for when it was removed

This document was created as the outcome of this conversation.

I’ve recently read a complaint elsewhere about Chromium being behind by 2 versions. The comment included “I thought they would be kept up-to-date.”. This is of course a reasonable expectation for snaps published by Canonical, as discussed in the thread that made us create this page, and is also part of the above statement.

But then, what’s the process we are following to not allow these supported snaps to linger behind? Do we have scheduled maintenance time for them and go around regularly making sure they remain up-to-date? Something else?

Also, this list was put in place last August. Has it really not changing since then, or do we need a process to keep it up-to-date too?

/cc @evan @kenvandine @popey

Yes, I’d like us to maintain a table of high-profile applications, their snap version, and the released upstream version. I will fold this into our regular comms.

@evan That sounds good regardless, but note that this topic is not about high-profile applications. This is about snaps that Canonical claims to support by itself. This topic and the associated one mentioned above have the background.

Regarding chromium specifically, I promoted the latest stable version to the stable channel today (see call for testing), and prior to that it had been in the candidate channel for 6 days, to allow for actual user testing and feedback (of which there hasn’t been this time around, but there usually is).

I’m usually on top of the chromium updates and I keep all the channels up-to-date. The perception of lagging behind recently is I think a combination of EOY holidays + build farm outages (chromium is quite a beast to build). We are now back to normal.


@oSoMoN Thanks for confirming it, and thanks for the update. I did notice your forum post and had already reported back to the user saying it was up-to-date now.

My main concern here is that we establish a trustable process to ensure we consistently keep these snaps up-to-date, or otherwise report that they are unsupported somehow.

1 Like

Could the above page please be updated to let people know where to file bugs in these packages? It’s not obvious at all where an end user with issues is to file an bug or get support on a snap Canonical are delivering.

I have added links to bugs for the snaps I maintain (chromium and libreoffice).


Where should issues with canonical-livepatch be reported?

1 Like

There is a BUGS section in the help output:

If possible I would like to see all non-proprietary snaps’ source repo and bug tracker published by Canonical to be available. For example: GNU Hello: No localization; Where's the source?

I would like to add the assuming source repo of the hello snap: to the list.