[gentoo-dev] Last rites: media-gfx/gmic

[gentoo-dev] Last rites: media-gfx/gmic

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 446 bytes --]

Upstream uses a massive home-made Makefile which has since the beginning
required massive amounts of patching to make it behave reasonably
(as well as to fix the problems which ostensibly led upstream to
abandoning CMake, and which they immediately re-introduced in their NIH
solution) and which if anything have only got worse since then. One,
optional, reverse dependency in the tree.
Removal on 2023-11-26. Bug #916289.

-- 
Marecki

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-dev] Re: Last rites: media-gfx/gmic

[Jonas Stein]

Hi Marecki,

this is a very powerful package with many users.
Thank you for maintaining it till now.

Could you address the exact problems to upstream, so they are aware and 
can improve it?
I think not only Gentoo, but also other distributions suffer if it does 
not build smooth.

Looks to me as if the package is not broken now, but there is a lack of 
manpower to update it. 30 days is the minimum for a removal.

I suggest to keep it for a few more months.

On  2023-10-26 03:00, Marek Szuba wrote:
> Upstream uses a massive home-made Makefile which has since the beginning
> required massive amounts of patching to make it behave reasonably
> (as well as to fix the problems which ostensibly led upstream to
> abandoning CMake, and which they immediately re-introduced in their NIH
> solution) and which if anything have only got worse since then. One,
> optional, reverse dependency in the tree.
> Removal on 2023-11-26. Bug #916289.

-- 
Best,
Jonas

Re: [gentoo-dev] Re: Last rites: media-gfx/gmic

[Eli Schwartz]

On 10/25/23 9:29 PM, Jonas Stein wrote:
> Hi Marecki,
> 
> this is a very powerful package with many users.
> Thank you for maintaining it till now.
> 
> Could you address the exact problems to upstream, so they are aware and
> can improve it?
> I think not only Gentoo, but also other distributions suffer if it does
> not build smooth.
> 
> Looks to me as if the package is not broken now, but there is a lack of
> manpower to update it. 30 days is the minimum for a removal.
> 
> I suggest to keep it for a few more months.


It's difficult to tell whether the problems were reported upstream since
upstream has deleted the repository and purged all issues, PRs, commits,
tags, and anything else whatsoever back in April.

The commit message is elucidative: "Clean repository".

Per https://github.com/GreycLab/gmic/issues/1#issuecomment-1521421747

"""
Yes, my fault. I've completely messed up (mainly because I'm still a git
novice after all these years!). I had to delete/recreate the repository
from scratch.
"""

This is of course either untrue or every kind of over-reaction, and
users have commented there to the effect of being willing to help sort
things out but there has been radio silence. It is long past the 90 days
where outright github-level recovery is possible.

I think this also offers some compelling arguments against maintainers
being willing to  deal with the challenges of this software -- this is a
pretty steep social cost to investing time and effort into caring about,
using, or maintaining such software.

I suppose it's always possible to orphan the package and let it rot
until it gets last-rited for not working. Marecki -- is there any
specific concern that it's likely to rot quickly if it lacks a maintainer?


-- 
Eli Schwartz

Re: [gentoo-dev] Re: Last rites: media-gfx/gmic

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 3247 bytes --]

On 2023-10-26 04:41, Eli Schwartz wrote:

> This is of course either untrue or every kind of over-reaction, and 
> users have commented there to the effect of being willing to help
> sort things out but there has been radio silence.

...which, sadly, has been my _overall_ experience with G'MIC upstream.

> I think this also offers some compelling arguments against
> maintainers being willing to  deal with the challenges of this
> software -- this is a pretty steep social cost to investing time and
> effort into caring about, using, or maintaining such software.

Given where this package has come from, I have got a nagging feeling
that its maintainers suffer from a problem that is fairly common among
computational scientists (and before anyone gets offended, a quick
reminder that I myself am in fact a computational scientist... Plus just
have a look at what many sci-* ebuilds have to look like) - namely that
however brilliant they might be at devising algorithms, they are rather
less adept at developing actual software.

Consider some of the issues I have come up against while maintaining 
this package (disclaimer: I haven't checked if any of these have been 
fixed in Git since the release of 3.3.1:

  - the reason for the megapatch, i.e. features being enabled 
automagically depending on the presence/absence of dependencies at build 
time. Not that big of a problem for end-users but very much 
distro-unfriendly;

  - one of the alleged reasons for G'MIC upstream to have switched from 
CMake to a hand-crafted Makefile (and one which said Makefile still 
fails to fix), namely building without X11 support. Given all that is 
needed to address the issue is something along the lines of "if !X11 
CFLAGS+=-Dcimg_display=0", I simply do not understand why this remains open;

- the use of RPATH="." with shared libraries in spite of it being widely 
considered a security risk, and apparently without any actual reason 
(media-gfx/gmic appears to work perfectly well with the relevant linker 
flag patched out);

- the use of backslash-whitespace construct in the hand-crafted Makefile 
causes build issues on systems with grep 3.8 or newer. For the record, 
GNU grep-3.8 was released over a year ago and Gentoo is now on 3.11;

- downright broken target dependency chains, even with -j1 (that bit 
falls under "if anything, the handcrafted Makefile has got worse since 
its introduction");

- a rather quirky way of locating the GIMP plug-in directory, including 
attempting to write to that directory when it hasn't been located - or 
even when the GIMP plug-in is not to be built.

I rest my case.

> Marecki -- is there any specific concern that it's likely to rot
> quickly if it lacks a maintainer?

The megapatch has to be updated on a fairly regular basis so at the very 
least, we would end up without updates. On top of that we have got the 
usual problems cropping up every time we add a new gcc/clang version, 
having to support MUSL (let's be honest, even among the more mature 
projects testing against non-glibc is rare), slibtool... So yes, I 
consider media-gfx/gmic very likely to rot quickly without continuous 
maintenance.

-- 
Marecki

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-dev] Re: Last rites: media-gfx/gmic

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 1613 bytes --]

On 2023-10-26 02:29, Jonas Stein wrote:

> this is a very powerful package with many users.

...but sadly, very few maintainers. It was m-n when I took it over 3 
years ago, as apparently no-one found it worth looking after following 
the disbanding of the Graphics project - and that was back when upstream 
still used CMake! Telling the truth I wasn't exactly interested either, 
it's just that it happened to be an optional dependency of 
media-gfx/darktable.

> Thank you for maintaining it till now.

You're very welcome!

> Could you address the exact problems to upstream, so they are aware and 
> can improve it?
> I think not only Gentoo, but also other distributions suffer if it does 
> not build smooth.

I used to do that. It seemed to have little to no effect so in the end I 
just gave up.

> Looks to me as if the package is not broken now, but there is a lack of 
> manpower to update it. 30 days is the minimum for a removal.

There are two outstanding QA issues (ignored LDFLAGS and pre-stripped 
binaries) in 3.3.1 pertaining to USE=gimp and USE=qt5. Prior to adding 
that version I tried to leverage qmake-utils.eclass in the Qt parts of 
the package, which hopefully would have got rid of these issues - but 
resulted in a wall of actual errors. This has been the last straw as far 
as me maintaining G'MIC is concerned.

> I suggest to keep it for a few more months.

Fine by me if someone actually maintains it. I've just dropped 
media-gfx/gmic back to m-n to make it clear that I do not intend to 
block it from being reactivated.

-- 
Marecki


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: Last rites: media-gfx/gmic

[Zoltan Puskas]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

On Fri, Oct 27, 2023 at 12:24:32PM +0100, Marek Szuba wrote:
> On 2023-10-26 02:29, Jonas Stein wrote:
> 
> > this is a very powerful package with many users.
> 
> ...but sadly, very few maintainers. It was m-n when I took it over 3 years
> ago, as apparently no-one found it worth looking after following the
> disbanding of the Graphics project - and that was back when upstream still
> used CMake! Telling the truth I wasn't exactly interested either, it's just
> that it happened to be an optional dependency of media-gfx/darktable.
> 
> > Thank you for maintaining it till now.
> 
> You're very welcome!
> 
> > Could you address the exact problems to upstream, so they are aware and
> > can improve it?
> > I think not only Gentoo, but also other distributions suffer if it does
> > not build smooth.
> 
> I used to do that. It seemed to have little to no effect so in the end I
> just gave up.
> 
> > Looks to me as if the package is not broken now, but there is a lack of
> > manpower to update it. 30 days is the minimum for a removal.
> 
> There are two outstanding QA issues (ignored LDFLAGS and pre-stripped
> binaries) in 3.3.1 pertaining to USE=gimp and USE=qt5. Prior to adding that
> version I tried to leverage qmake-utils.eclass in the Qt parts of the
> package, which hopefully would have got rid of these issues - but resulted
> in a wall of actual errors. This has been the last straw as far as me
> maintaining G'MIC is concerned.
> 
> > I suggest to keep it for a few more months.
> 
> Fine by me if someone actually maintains it. I've just dropped
> media-gfx/gmic back to m-n to make it clear that I do not intend to block it
> from being reactivated.
> 
> -- 
> Marecki
> 

This is quite a loss. Ever since the dropping the gimp-resynthesizer plugin (due
to Python2 deprecation) gmic was the last package to provide "heal selection"
functionality in GIMP. Losing gmic will put GIMP behind other image editing
software by a significant margin.

I'm wondering if we could collaborate with other distro developers on building
and improving the state of this package. E.g. Debian seems to be packaging gmic
by itself and also for gimp and krita. I wonder if it's possible to build the
gimp plugin portion only and not deal with gmic QT frontend?

Zoltan


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: Last rites: media-gfx/gmic

[Sam James]

Zoltan Puskas <zoltan@sinustrom.info> writes:

> [[PGP Signed Part:Undecided]]
> On Fri, Oct 27, 2023 at 12:24:32PM +0100, Marek Szuba wrote:
>> On 2023-10-26 02:29, Jonas Stein wrote:
>> 
>> > this is a very powerful package with many users.
>> 
>> ...but sadly, very few maintainers. It was m-n when I took it over 3 years
>> ago, as apparently no-one found it worth looking after following the
>> disbanding of the Graphics project - and that was back when upstream still
>> used CMake! Telling the truth I wasn't exactly interested either, it's just
>> that it happened to be an optional dependency of media-gfx/darktable.
>> 
>> > Thank you for maintaining it till now.
>> 
>> You're very welcome!
>> 
>> > Could you address the exact problems to upstream, so they are aware and
>> > can improve it?
>> > I think not only Gentoo, but also other distributions suffer if it does
>> > not build smooth.
>> 
>> I used to do that. It seemed to have little to no effect so in the end I
>> just gave up.
>> 
>> > Looks to me as if the package is not broken now, but there is a lack of
>> > manpower to update it. 30 days is the minimum for a removal.
>> 
>> There are two outstanding QA issues (ignored LDFLAGS and pre-stripped
>> binaries) in 3.3.1 pertaining to USE=gimp and USE=qt5. Prior to adding that
>> version I tried to leverage qmake-utils.eclass in the Qt parts of the
>> package, which hopefully would have got rid of these issues - but resulted
>> in a wall of actual errors. This has been the last straw as far as me
>> maintaining G'MIC is concerned.
>> 
>> > I suggest to keep it for a few more months.
>> 
>> Fine by me if someone actually maintains it. I've just dropped
>> media-gfx/gmic back to m-n to make it clear that I do not intend to block it
>> from being reactivated.
>> 
>> -- 
>> Marecki
>> 
>
> This is quite a loss. Ever since the dropping the gimp-resynthesizer plugin (due
> to Python2 deprecation) gmic was the last package to provide "heal selection"
> functionality in GIMP. Losing gmic will put GIMP behind other image editing
> software by a significant margin.
>
> I'm wondering if we could collaborate with other distro developers on building
> and improving the state of this package. E.g. Debian seems to be packaging gmic
> by itself and also for gimp and krita. I wonder if it's possible to build the
> gimp plugin portion only and not deal with gmic QT frontend?

https://github.com/GreycLab/gmic/issues/17 indicates upstream are open
to PRs at least.

>
> Zoltan
>
> [[End of PGP Signed Part]]