CUPS Snap - Call for Testing

@fossfreedom Great!! Thanks for actually trying the hack! On my first glance I thought you had simply GIMPed a screenshot (Do not trust any photo which you did not GIMP by yourself). But having proven that you can run a “Printers” -only G-C-C is a great step!

As we need this only for distros with a snapped CUPS, we should create a Snap from it, with the snapcraft.yaml grabbing the original gnome-control-center upstream code and a script applying the modifications to let it build “Printers”-only. I would host this Snap on OpenPrinting, as an “accessory” for the CUPS Snap.

Could you tell the steps and supply the patches with which you succeeded to modify G-C-C this way? And your future change to remove the sidebar … Thanks in advance.

1 Like

@fossfreedom Is G-C-C actually shipped by gnome-shell? As I see Ubuntu it is a separate source Debian package, with only G-C-C in it …

This is the code changes I’ve done to get the upstream GCC code (main) to work on lunar.

Yes - GCC is a dependency of gnome-shell

'fraid my snapcraft knowledge is fairly basic - dont think I can help with packaging this as a snap.

@fossfreedom Great, thanks for the link. Seems that you also have taken care of removing all unnecessary dependencies. Does your change also already remove the sidebar?

The snapping is no problem. I could do that.

@fossfreedom, and before making this official, we should rename it, a little strange to name something system-config-printer if it is something completely different, also with the background that there are many LTS/enterprise distros arround which still use the original system-config-printer.

Yep the sidebar has gone.

At the moment this builds an executable called gnome-control-center with gnome-control-center schemas that just displays the printer module.

So please do give it a try and let me know your thoughts. If it does everything that is needed we can then look at tidying up things like unique schema names, a better name for the project/snap.

Open to suggestions!

You should not call it gnome-control-center because the old gnome-control-center is still useful.
may be gnome-control-printer?

Due to me organizing a conference in India I am currently a lot in contact with @rs2009 and he tells that for Ubuntu’s flavors (and naturally also for many other distros) a problem can also be that G-C-C uses libadwaita by default, which displays badly on non-GNOME desktops. He suggests here to do something libadwaita-free and I suggested to him to try to re-use Mohit Verma’s code which he is applying to G-C-C. So perhaps we can get this also somehow into our printer setup tool project. And then “gnome-control-printers” is perhaps also not a good name …

Fair enough.

Sounds like now this is going to be a completely standalone project rather than a patch ontop of GCC.

I am not familiar with Mohit’s code base (where it is etc) you are referring to. Please can you link to it here please.

Here we go:
The first link points to a branch which has only modifications for the main view (no change on the “Add Printer” part), the second has the same changes in the main view plus the Printer Application support UI in the “Add Printer” part, but this one not yet actually working, only UI demo.

Note that in these branches all commits from Mohit are at the top, so one can easily extract a patch with all changes. This I did for the G-C-C in the PPA.

For Ubuntu Studio, that’s already a non-starter as KDE Plasma is the desktop. For Edubuntu, it uses whatever is provided by the ubuntu-desktop-minimal seed, so I’m not worried there.

For KDE/Qt-based distros, as long as they do not change their printer setup tool (is there one in KDE’s Settings app?) a small separate program, like we had with system-config-printer, would probably the best stop-gab solution. To get this done re-using Mohit Verma’s work on GNOME Control Center would be to get it into a simple GTK application (libgtk would easily happen to be also on KDE/Qt-based distros as many apps use it).

@fossfreedom @rs2009 WDYT? Could we work together with Mohit, to get a simple GTK-based app which does not require significant parts of GNOME and especially not libadwaita?

There is, and I just gave it a test with the CUPS snap. Seems to work, although the driver seemed to default to the wrong tray, but that’s just a configuration error on my end.

EDIT: That might be an error. No matter how much I change the settings in the KDE system settings, they will not take. That’s a problem.

My concern at this point is that there’s no transitional package. The old CUPS .deb package (and its dependencies/recommends) was completely ripped-out of my system dev system without warning instead of transitionally installing the CUPS snap. To get things working again, I had to manually install the CUPS snap. This won’t affect new installations, but upgrades will be affected. I hope this is resolved soon otherwise we’re going to get a lot of bug reports from people who don’t exactly know what’s going on with regards to this thread.

The transitional package is high on my list and for sure Ubuntu 23.10 will come with it. I told earlier in this thread how this package will look like.

1 Like

That’s great news, and I indeed saw that above.

My concern isn’t that it won’t happen, my concern is that we get people testing things prematurely and open bug reports and then get anxious when things don’t get fixed in a timely manner and then get concerned that they won’t ever be fixed. Recently, I got a direct email practically scolding me for not attending to a bug (that wasn’t even within my purview to begin with) that was filed in May for something in mantic.

What happens is, when we get something that affects all flavors, people test before beta release and notice issues and file bugs, being unaware of threads like this. Most of the public assumes that official Ubuntu flavors are separate distributions with separate or additional repositories, which we know isn’t true. Theses people wouldn’t even think to look here for information regarding why, when they’re upgrading via do-release-upgrade -d (even though that’s unsupported) that they’re suddenly missing their printing system. This is when we get unnecessary bug reports (death by 1,000 papercuts) and angry direct emails.

My point is that, removing cups from the desktop-common seed prior to the availability of a transitional package was, quite frankly, premature and, to use a colloquialism, “putting the cart before the horse.”

(N.B. The issue about the public assuming that official Ubuntu flavors being separate distributions from Ubuntu is something I’ve been trying to combat for years since becoming a flavor lead. It’s something even my own team had to switch paradigm on.)


If you release an ISO without the old cups but only with the new snap cups it is obvious that users will open bugs because the new cups is incomplete and does not offer all the functions of the old one.

Hmm, there’s an update ?

@fthx OK, I was very busy, thanks for reminding me.

We have decided to revert to DEB-package based printing and move the switchover out to Ubuntu 24.10.

We are now already long after Feature Freeze and shortly before User Interface Freeze and the desktop integration has taken longer than expected. Especially also the needs of printer setup tools for the flavors need some additional time. Also GNOME Control Center is undergoing a major UI modernization and we need to merge with it. And for providing the Common Print Dialog backends in Snap, the session D-Bus support in snapd needs to get finally released.

To not do high-impact changes in an LTS we will skip 24.04 LTS and do the switchover in 24.10 at the earliest. For the time being I keep the DEB package as much in sync as possible with Debian’s packages.

I will continue coordinating the desktop integration on the upstream level with my Google-Summer-of-Code contributors and keep in touch with upstream on upcoming conferences (seems that next year I need to also attend Akademy?).

On the Ubuntu side I will concentrate on Ubuntu Core Desktop. This distribution is an immutable all-Snap distribution and requires printing and scanning support via Snap. In addition, it has no flavors (yet) and its first release is not earlier than the 24.04 classic Ubuntu release. So here we have enough time to finish the “Printers” module in GNOME Control Center (and that is all printer setup tool we need), to add CPDB frontend support to the GNOME content provider Snaps, to get the Chromium print dialog CPDB-enabled (perhaps also some others), to assure that Snaps of apps use the desktop portal for printing whenever possible, have the scanning support for Snap (Scanner Applications) ready, having Snap release automation in place …

Then when Ubuntu Core Desktop does its printing and scanning well, we will look into the classic Ubuntu, …

This way we avoid what we have seen with the Firefox Snap in Ubuntu 22.04 LTS and @local-optimum’s (in)famous 4 posts on the Ubuntu blog, which should not get followed by 4 posts by me.

But please, have the CUPS Snap in mind and in the time being I am on it and regularly publishing new stuff for testing, in my PPA and naturally also in Ubuntu Core Desktop. I will keep you posted in the OpenPrinting News.

Sorry for the inconvenience with this attempt to launch the switchover and for any disappointment that we will move out the switchover to later.


Thanks for these explanations.
So, if I do install snap cups stack along deb stack, the snap stack is preferred?