Repository navigation
[Take over request]: Passing snap to GIMP project #447
Description
What changes would you like?
Hi. I am one of the packagers from upstream GIMP. Following this note (https://github.com/snapcrafters#how-to-take-over-your-snap), I would like to request, in the name of the project, to I and other interested GIMP devs taking over all the packaging files in this repo and the gimp entry on Snap Store.
Actually both belongs to Snapcrafters, which have been doing a good downstream job by the way but I am personally interrested in making that packaging format official.
We have a WIP branch that creates working nightly snaps on our CI by using snapcraft remote-build (https://gitlab.gnome.org/GNOME/gimp/-/commits/bruno/test-s), since seems to be impossible to build snaps other way on Docker.
For GIMP stable and GIMP unstable (preview), however, I talked with the GIMP maintainer (@Jehan) and we naturally agreed that the ideal would be to releasing these channels in a co-maintenance model like we do in our official flatpak from Flathub: we maintain and decide things about it but we are not alone there if we need for help. Would be nice to have this relation here too.
Any extra information?
So, to summarize, GIMP project would like:
- Change publisher name to GIMP in Snap Store (Can this repo be configured to publish snaps using GIMP's Ubuntu One account?)
- Take owership over these packaging files. This implies in conforming them do our style, principles etc, e.g.: we will remove non-vanilla additions like GMIC for sure and maybe OpenVINO
Activity
jnsgruk commentedon Jul 29, 2025
Hi there! Thanks for reaching out!
Firstly this is a pretty exciting development, and I think having the snap fully adopted/maintained by the upstream would be a positive step for the package and for the users of the snap - many of the issues we see reported at this point are in fact upstream issues and not related to packaging (there are certainly a few packaging issues, but they're being tracked).
Once we agree - the actual transfer of the snap in the Snap Store is relatively simple - and we should probably work toward "Verified Publisher" status if we do that.
On GMIC and OpenVINO - we need to think carefully about this. The last time I looked, there were 300,000+ weekly active installs of the
gimpsnap, so we should be careful about unceremoniously removing functionality, and perhaps come up with the right way for users to keep hold of that functionality if they move to an officially owned snap?One route here is through the "tracks" mechanism - we (snapcrafters + canonical + GIMP) could maintain a track such as
openvino/stablewhich builds on a more stripped out "base" snap and adds the functionality - or we could get more creative with things like content snaps - the same likely applies to GMIC.Let me know what you think.
(@merlijn-sebrechts / @frenchwr this seems like something you might be interested in)
jnsgruk commentedon Jul 29, 2025
I should also add, any such transition should probably be publicised to your community and ours - we would probably look to a Discourse post or similar if there were going to be any major changes - we made a similar post last week about
obs-studio: https://discourse.ubuntu.com/t/a-call-for-testing-major-updates-to-the-obs-studio-snap/64872frenchwr commentedon Jul 29, 2025
I agree this is an exciting development!
The OpenVINO plugins are already delivered over the content interface - one reason we designed it this way was to minimize the support overhead for the
gimpsnap. There are a few parts in thesnapcraft.yamlfor the OpenVINO command-chain scripts but that could be re-worked to be more generic. I guess we could do something similar for GMIC, but I have less experience with that plugin.brunvonlope commentedon Jul 29, 2025
Thanks for the feedback .Yeah, if there is some generic way to make content snaps interact with GIMP snap without needing to list them in the snapcraft.yaml that would be really nice. On flatpak, we use a generic extension point on which GMIC and any other plugin can "mount": https://github.com/flathub/org.gimp.GIMP/blob/07ccca7eaab81eacea4ead572953c8931db4294e/org.gimp.GIMP.json#L64
Jehan commentedon Jul 29, 2025
Just a small comment about why we have this policy: basically we don't want to be in over our head. Our project is GIMP (not more and not less) and that's simply the only thing we want to ship and support. This is why our official package must be as full-featured as possible and no official package must ever contain any third-party code. If we do this, we are basically throwing a message out that these plug-ins are kinda official and therefore it's OK to ask us to support these. We don't want this. And this part is not up for discussion IMO.
Now GIMP is definitely a platform for further development, this is important to us, and both these plug-ins are good plug-ins and probably widely appreciated (the OpenVino one is the AI plug-in by Intel, isn't it?). We'd love it if they could still be shipped for the official Snap, simply separately (and we would not take over maintainership for these! Only for the main vanilla GIMP). As @brunvonlope says, this is possible in Flatpak with the concept of "extensions", and it looks like the "tracks" and/or "content snaps" concepts in Snap may be the equivalent concepts? If so, that's likely what we want.
For sure. If there was a way for people who had the previous version of GIMP to move automatically (at the next update after the maintenance change) into GIMP + the G'MIC + OpenVino snaps, it seems fair. Yet any new installation of GIMP should be Vanilla GIMP only. Then it would be a perfect migration.
I assume that software installers with Snap support would be able to list any "content snaps" (or tracks) available for a base Snap? That's how new users would discover that they can install G'MIC, OpenVino or any other third-party plug-in which wishes to be available for our Snap.
For instance GNOME Software is able to display all Flatpak extensions for our package on Flathub. For instance it is also possible to install G'MIC (and a few other plug-ins, such as Resynthesizer, etc.) for the official Flatpak too, directly from GNOME Software. Simply we don't maintain this flatpak (someone else does and simply uses the Extension point which we make available in our package rules), and it is not installed by default. What we'd like is for the same to happen on Snap, with whatever method is adapted there. 🙂
brunvonlope commentedon Jul 29, 2025
@Jehan Seems that no yet:
Gravando.2025-07-29.150440.mp4
jnsgruk commentedon Jul 29, 2025
Not as yet - but not out of the question.
I think whatever happens you'd need something in snapcraft.yaml to allow plugins over a content interface.
Perhaps @frenchwr could take a look delivering GMIC and OpenVINO using just content snaps? I'm a bit short on time over the next few weeks - but I think that's the mostly likely route to be successful.
merlijn-sebrechts commentedon Jul 29, 2025
@brunvonlope
I think that's definitely possible.
I think the best approach would be for us to transfer everything to you, and give you an easy way to contact us if you have more questions or need help. We have a Matrix room that I can invite you to and, depending on the platform, you could tag us if you experience any issues.
That would mean:
Is that what you are looking for?
brunvonlope commentedon Jul 29, 2025
@merlijn-sebrechts Last case scenario, yes. On GIMP GitLab CI we have infra for doing that (at least with snapcraft remote-build).
I say "last case scenario" mainly because what I envionsed in the description seems more community friendly IMO.
merlijn-sebrechts commentedon Jul 29, 2025
@brunvonlope I'm not 100% following. Do you mean that you would prefer the source and build pipeline remains here and only the publisher name in the Snap Store changes?
The main idea is that this organization is just for the snaps published under our name and maintained by us. It's quite different from FlatHub in that regard.
One of the difficulties with how this organization is set up at the moment is that
We can easily change the name of the publisher in the store. I don't think this would require a change in our tooling. But having separate permissions on a single repository in this organization would be difficult with our current tooling, and might be confusing for other Snapcrafters.
I'm open to thinking how we could do something more hybrid like FlatHub does, but I want to confirm first that that is truly what you want.
brunvonlope commentedon Jul 29, 2025
@merlijn-sebrechts Yes, that is what I meant.
What would change 🆕:
What would not change 🛑:
jnsgruk commentedon Jul 30, 2025
Hmm okay, I also misunderstood. I think splitting it in this way might get quite complicated; I don't know that we can prevent the rest of snapcrafters from contributing to just this snap very easily - and we'd end up with an odd management burden to add/remove "official" GIMP maintainers I think?
It feels like the first thing to do is prove out a way of adding OpenVINO and GMIC over a generic
gimp-plugins(or similar) content interface?build/linux: Add Snap maintenance README like Flatpak and MSIX
brunvonlope commentedon Aug 26, 2025
Hi. What is the progress here regarding the content plugins?
On our side, we already have fully functional snaps being created on our CI without relying on remote-builder: https://gitlab.gnome.org/GNOME/gimp/-/tree/master/build/linux/snap?ref_type=heads so GIMP team will be able to publish without needing this repo.
15 remaining items
jnsgruk commentedon Oct 7, 2025
@Jehan / @brunvonlope the PR is merged, and there is now a new build with our changes on the
latest/candidatechannel: #467Do you want me to push that to
latest/stablenow, or would you rather wait until you folks are in control of the snap? 🙂brunvonlope commentedon Oct 7, 2025
@jnsgruk We need to await canonical/openvino-toolkit-snap#24 to be merged I think.
Would ou mind allowing us to do a last revision on this repo with a MR? I would like to backport the snapcraft.yaml from upstream gimp-3-0 (which is based on yours but have some fixes and cleanups) to this repo, since we don't have ways to do that until the infra is ready for GIMP 3.1.2
jnsgruk commentedon Oct 7, 2025
Yep of course!
jnsgruk commentedon Oct 7, 2025
My intention is to archive this repo once the transfer is complete, but I think it's worth getting the two to look the same just before we do that.
brunvonlope commentedon Oct 7, 2025
Thanks. Created #468 for that purpose.
brunvonlope commentedon Oct 8, 2025
@jnsgruk Thanks for the testing on the latest revision. Can I update the description mentioning the 2 plugins that now are not included anymore (as some other things like outdated icon, screenshots, etc)?
jnsgruk commentedon Oct 8, 2025
You should be able to login to https://snapcraft.io/gimp/listing and update the details now that you're a collaborator on the snap :)
brunvonlope commentedon Oct 9, 2025
@jnsgruk Done. Is there something missing to we complete the pass over?
jnsgruk commentedon Oct 10, 2025
I'll poke the Store team and get back to you, sorry for the delay here, I don't think there is anything else we need from you at this point 🙂
jnsgruk commentedon Oct 10, 2025
@brunvonlope @Jehan we have lift-off!
Thank you both very much for your collaboration - if you're comfortable I think it's time for me to put a banner on the README here and mark the repo as archived?
brunvonlope commentedon Oct 10, 2025
@jnsgruk Thank you for you and the past snapcrafters hard work over the following years. That wouldn't be possible without you. We will make a nice blog post about this on gimp.org. 🤗
Just one last thing: I noticed that GIMP is appearing twice, as developer and publisher. Do you know how can we fix this? (I noticed that other official snaps like Inkscape and Krita display only the publisher name.)
jnsgruk commentedon Oct 10, 2025
Hmm, that's a great question! I think it might be because of some of the metadata which you could experiment with tweaking, but that's probably a question to ask on the snapcraft.io forum - I don't have an answer to hand.
brunvonlope commentedon Oct 10, 2025
Ok, maybe gnome-infra/dns#75 will help.
Any case, feel free to archive this project and thanks again