* [gentoo-dev] Last rites: media-gfx/gmic
@ 2023-10-26 1:00 Marek Szuba
2023-10-26 1:29 ` [gentoo-dev] " Jonas Stein
0 siblings, 1 reply; 7+ messages in thread
From: Marek Szuba @ 2023-10-26 1:00 UTC (permalink / raw)
To: gentoo-dev, gentoo-dev-announce
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-dev] Re: Last rites: media-gfx/gmic
2023-10-26 1:00 [gentoo-dev] Last rites: media-gfx/gmic Marek Szuba
@ 2023-10-26 1:29 ` Jonas Stein
2023-10-26 3:41 ` Eli Schwartz
2023-10-27 11:24 ` Marek Szuba
0 siblings, 2 replies; 7+ messages in thread
From: Jonas Stein @ 2023-10-26 1:29 UTC (permalink / raw)
To: gentoo-dev; +Cc: Marek Szuba
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
2023-10-26 1:29 ` [gentoo-dev] " Jonas Stein
@ 2023-10-26 3:41 ` Eli Schwartz
2023-10-27 11:52 ` Marek Szuba
2023-10-27 11:24 ` Marek Szuba
1 sibling, 1 reply; 7+ messages in thread
From: Eli Schwartz @ 2023-10-26 3:41 UTC (permalink / raw)
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-dev] Re: Last rites: media-gfx/gmic
2023-10-26 1:29 ` [gentoo-dev] " Jonas Stein
2023-10-26 3:41 ` Eli Schwartz
@ 2023-10-27 11:24 ` Marek Szuba
2023-10-31 6:50 ` Zoltan Puskas
1 sibling, 1 reply; 7+ messages in thread
From: Marek Szuba @ 2023-10-27 11:24 UTC (permalink / raw)
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
2023-10-26 3:41 ` Eli Schwartz
@ 2023-10-27 11:52 ` Marek Szuba
0 siblings, 0 replies; 7+ messages in thread
From: Marek Szuba @ 2023-10-27 11:52 UTC (permalink / raw)
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
2023-10-27 11:24 ` Marek Szuba
@ 2023-10-31 6:50 ` Zoltan Puskas
2023-10-31 7:05 ` Sam James
0 siblings, 1 reply; 7+ messages in thread
From: Zoltan Puskas @ 2023-10-31 6:50 UTC (permalink / raw)
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
2023-10-31 6:50 ` Zoltan Puskas
@ 2023-10-31 7:05 ` Sam James
0 siblings, 0 replies; 7+ messages in thread
From: Sam James @ 2023-10-31 7:05 UTC (permalink / raw)
To: gentoo-dev
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]]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-10-31 7:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-26 1:00 [gentoo-dev] Last rites: media-gfx/gmic Marek Szuba
2023-10-26 1:29 ` [gentoo-dev] " Jonas Stein
2023-10-26 3:41 ` Eli Schwartz
2023-10-27 11:52 ` Marek Szuba
2023-10-27 11:24 ` Marek Szuba
2023-10-31 6:50 ` Zoltan Puskas
2023-10-31 7:05 ` Sam James
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox