Hi, and sorry for the slow response!

We package third-party GIMP plugins in their own packages. Would you be willing to maintain it in Fedora? I see that you have an account, and I would be willing to sponsor and mentor you.

I can give it a try.
Where do I start?

Cool!

Here’s the “extended version”, the New Package Process for New Contributors: https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/

I’d be happy to help you through the process, you can find contact information on my Fedora Wiki User page: https://fedoraproject.org/wiki/User:Nphilipp

NB: I’m extending the wiki page right now because the info template I use doesn’t support new-fangled items like Matrix IDs. Let me know your preferred way of communicating outside of Bugzilla and once we’ve established that, I would close this ticket – we will need to have one for the package review, but this one can’t be reused for the purpose.

No worries, no hurry.
I know what you mean (we seem to keep ourselves pretty busy - similarly another mini-wiki https://github.com/fontforge/designwithfontforge.com/issues/253).  ;-P

Time to go do some reading....

Hi Nils, it was quite a bit to read, but finally got through reading it.
Also added a self-test to fix-ca so it should also help verify the plugin works with the various CPU types.

Hi!

Again, sorry for the slow response but GIMP wise I’ve been busy with the upgrade to version 3 (well, the RC meanwhile) in Fedora 41+ (and the gimp3 package in earlier releases). Have you tested the plugin with the new version?

I noticed you built the bleeding edge GIMP3 RC1, which sort of makes sense for the delay. That is a big jump ahead, especially as the API is still in a state of flux.

I think I'm one patch ahead of you and would need to backtrack one patch to match-up with the latest Fedora GIMP3 (20241027), or backtrack two patches to match-up with the earlier GIMP3 (20241011). The latest HEAD I have right follows another recent API change. If you're going to standardize on 20241027, then we can use the commit of Oct 9th (https://github.com/JoesCat/gimp3-fix-ca/commits/master/).

I'll have to load a fresh Fedora 41+ just to be for sure. Will try tonight if I can....

NOTE: You'll seem 'make check' in the RPM spec file, but it doesn't work since 'gimp -i' still needs some attention (https://gitlab.gnome.org/GNOME/gimp/-/issues/12042), but I think it may be a while before that is resolved since the gimp team are chasing bigger issues for now.

FYI, you also have activity here - but I don't know how far along it is, as I'm not following along that closely (https://github.com/bootchk/resynthesizer/tree/resynthesizer3).

Ran into some problems trying to compile in Fedora 41+ gimp3 environment - will analyze further.

okay...so there's a RC1. Where I'm at, at the moment:
I've managed to succeed in building and running gimp3-fix-ca, and also plugin-gimp-fourier for gimp3 (https://github.com/rpeyron/plugin-gimp-fourier/tree/gimp2.99), but this is on Mageia9, with download of git clones of babl, gegl, and gimp3-RC1. I have run into problems with building both gimp3-fix-ca and plugin-gimp-fourier on Fedora 41+

Improvements needed for fix-ca.c is to add this near the top:
```
#include <stddef.h> /* GTK3 needs define size_t */
```
This helps get it to build beyond gtk size_t problems.
Both programs seem to require adding a (GimpRunImageFunc)() description to gimp_image_procedure_new() which looks like this:
```
    procedure = gimp_image_procedure_new (plug_in, name,
                                          GIMP_PDB_PROC_TYPE_PLUGIN,
                                          (GimpRunImageFunc)(fixca_run), NULL, NULL);
```
At this point they build, but seems that gcc14 is optimizing the heck out of these programs, which doesn't happen if I do it with gcc12 on Mageia9

At this point in time, I'm trying to find some sort of solution where Fedora41+ gcc14 isn't optimizing variables out of existence.

This patch can help with fourier.c as it's simpler.
---------------------------------- fourier.c ----------------------------------
@@ -467,7 +467,7 @@ fourier_create_procedure(GimpPlugIn *plug_in,
     // One for all procedure with dialog
     procedure = gimp_image_procedure_new(plug_in, name,
                                          GIMP_PDB_PROC_TYPE_PLUGIN,
-                                         fourier_run, NULL, NULL);
+                                         (GimpRunImageFunc)(fourier_run), NULL, NULL);
 
     gimp_procedure_set_image_types(procedure, "RGB");
     gimp_procedure_set_sensitivity_mask(procedure,
@@ -504,7 +504,7 @@ fourier_create_procedure(GimpPlugIn *plug_in,
     // Forward without dialog
     procedure = gimp_image_procedure_new(plug_in, name,
                                          GIMP_PDB_PROC_TYPE_PLUGIN,
-                                         fourier_run, FOURIER_DATA_DIR, NULL);
+                                         (GimpRunImageFunc)(fourier_run), FOURIER_DATA_DIR, NULL);
 
     gimp_procedure_set_image_types(procedure, "RGB");
     gimp_procedure_set_sensitivity_mask(procedure,
@@ -527,7 +527,7 @@ fourier_create_procedure(GimpPlugIn *plug_in,
     // Inverse without dialog
     procedure = gimp_image_procedure_new(plug_in, name,
                                          GIMP_PDB_PROC_TYPE_PLUGIN,
-                                         fourier_run, FOURIER_DATA_INV, NULL);
+                                         (GimpRunImageFunc)(fourier_run), FOURIER_DATA_INV, NULL);
 
     gimp_procedure_set_image_types(procedure, "RGB");
     gimp_procedure_set_sensitivity_mask(procedure,
@@ -677,7 +677,7 @@ fourier_run(GimpProcedure *procedure,
             GimpProcedureConfig *config,
             gpointer run_data)
 {
-  GimpDrawable *drawable;
+  GimpDrawable *drawable = NULL;
   gboolean inverse = FALSE;
   gboolean new_layer = FALSE;
------------------------

fix-ca.c is a little more complicated. You can manage to compile if you disable HAVE_GETTEXT in fix-ca-config.h by commenting it out with either leading '//#define HAVE_GETTEXT 1' or wrapping it '/*#define HAVE_GETTEXT 1 */'
and then also applying these edits:

@@ -17,12 +17,7 @@
  * along with this program. If not, see <https://www.gnu.org/licenses/>.
  */
 
+#include <stddef.h> /* GTK3 needs define size_t */
 #include <string.h>
 #include <math.h>
 
@@ -180,7 +184,7 @@ fixca_create_procedure (GimpPlugIn *plug_in,
 
     procedure = gimp_image_procedure_new (plug_in, name,
                                           GIMP_PDB_PROC_TYPE_PLUGIN,
-                                          fixca_run, NULL, NULL);
+                                          (GimpRunImageFunc)(fixca_run), NULL, NULL);
 
     gimp_procedure_set_image_types (procedure, "RGB*");
     gimp_procedure_set_sensitivity_mask (procedure,

----------------
which then allows you to compile and install, but running seems to run into <optimized out> variables.

Hi Nils,
This is ready for gimp-3.0-RC1.
Release 0.1 created.
I did a git clone of babl, gegl and gimp, built these and installed these first,
then built and installed gimp3-fix-ca, and it works ok for Mageia, Ubuntu 24.10.
Knowing it builds and runs ok on Mageia and Ubuntu (if babl, gegl, gimp built first), I expect the process can be repeated similarly on Fedora 41+, or 40+ which I will try-out later/soon/weekend.

(In reply to joescat from comment #10)
> Hi Nils,
> This is ready for gimp-3.0-RC1.
> Release 0.1 created.
> I did a git clone of babl, gegl and gimp, built these and installed these
> first,
> then built and installed gimp3-fix-ca, and it works ok for Mageia, Ubuntu
> 24.10.
> Knowing it builds and runs ok on Mageia and Ubuntu (if babl, gegl, gimp
> built first), I expect the process can be repeated similarly on Fedora 41+,
> or 40+ which I will try-out later/soon/weekend.

The next step for getting this into Fedora would be uploading the SRPM and SPEC file somewhere and opening a "Package Review" ticket. Let me know if you need help there!

I started tinkering with https://copr.fedorainfracloud.org/coprs/joescat/gimp3-fix-ca/ where the copr link was mentioned in "packaging guidelines", but this also seemed to run into needing to upload a SRPM and spec file somewhere first.....

...so I just created a branch and put the spec file and SRPM here:
https://github.com/JoesCat/gimp3-fix-ca/tree/fedora_rpm_spec/ in folder "fedora"
would this simple method be sufficient?
...or should I be looking further into the fedorainfracloud?

Oops, I dropped the ball on this.

- COPR is Fedora’s "less red tape" build system. Packages there still have to be free/open source software, but they don’t have to adhere to the full set of packaging guidelines and you don’t have to go through a formal review to create a repo there. You can build a package you want to review for inclusion in Fedora proper there (this is always a good idea), but it’s not a prerequisite. To build a package in COPR, you only need to be able to upload an SRPM of it, which it then builds.
- The Fedora package review requires a public place for the spec and SRPM files, to which you point in the review ticket. This can be on COPR, or on fedorapeople, or on another website.

I’ll close this ticket now as it’s not an issue with the main "gimp" package. If you’re interested in getting this in as a proper Fedora package, again, I’m happy with sponsoring you as a packager and reviewing it. In this case, please contact me via email to my Red Hat address (hover over my user name here for it) or ping me on Matrix: I’m @nphilipp:fedora.im and hang out in the Fedora Devel room (https://matrix.to/#/#devel:fedoraproject.org) among other places.

Hi Nils,
Thanks, but I'll pass on being a packager, while I was waiting for reply, I was enrolled in the mailing lists and the amount of email coming through caused me to miss a couple of important emails that needed a response sooner than I discovered them - the email onslaught is like drinking water from a fire hydrant, so I wouldn't be able to remain a packager for very long.
It's great that you asked - thanks, but at risk of missing emails needing attention, I'll have to pass.

During the wait, seems that gimp3-fix-ca got some notice in the forums, and Librearts:
https://gimpchat.com/viewtopic.php?f=9&t=21621
https://librearts.org/2025/05/week-recap-18-may-2025/

...in the meantime, I'll work on another gimp3-plugin, but at the moment have a big project to finish first before I touch this: https://github.com/JoesCat/gimp-refocus-it/issues/1

...any yes, eventually https://github.com/JoesCat/gimp-plugin-astronomy, but still waiting to see if there is any more activity with original author.


If someone wants to be a packager for gimp3-fix-ca, I'd be happy to help, but based on the amount of email in the lists, I can't be one, as a helper - gimp3-fix-ca includes a md5sum 'make check' to verify it's working correctly, so it should make it easier to test on other architectures, like 390, arm, other.
On the other hand, it probably is too slow to run on fedoraproject checks, as it does take time for gimp to load and run before you can run the plugin, so you may want to skip 'make check'.

Thanks Nils.

Joe