As noticed by gimp maintainers, gnome2-utils.eclass is killing GIMP_DISABLE_DEPRECATED leading to compilation failures (#614914). When contacting gimp upstream, they stated we shouldn't kill that variable: https://bugzilla.gnome.org/show_bug.cgi?id=781070#c3 Then, maybe we should exclude that variable from that sedding... or maybe there are other possible approaches I am forgetting now
If gimp has such a fundamentally different approach to *_DISABLE_DEPRECATED than gnome, then one might think maybe gimp ebuilds shouldn't use gnome2.eclass or call gnome2_disable_deprecation_warning from gnome2-utils? Then again, that might mean they end up not filtering out all the other *_DISABLE_DEPRECATED that needs to be filtered out to ensure compiling successfully in the future
In case we want to whitelist it instead, does anyone know how to do that in that sed? Regexp isn't exactly quite my forté. And maybe the other stuff that has _DISABLE_DEPRECATED doesn't get its own usages filtered out by that sed due to a different build system approach. But I'd need to take a look inside the other tarballs to really remember, we did this stuff like around the time gtk2.18 or something was a thing and gtk3 in its earlier development releases.
Hi! How do you feel about adding some switch to control if gnome2_src_configure calls gnome2_disable_deprecation_warning or not? For the sed expression, one could do a trick like -e 's:-DGIMP_DISABLE_DEPRECATED:-DGIMP__DISABLE__DEPRECATED:g' \ -e 's:-D[A-Z_]+_DISABLE_DEPRECATED:$(/bin/true):g' \ -e 's:-DGIMP__DISABLE__DEPRECATED:-DGIMP_DISABLE_DEPRECATED:g' \ to have it bypass removal. Just an idea :)
This was added some years ago: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/gnome2-utils.eclass?r1=1.29&sortdir=down&pathrev=MAIN&logsort=cvs&r2=1.30 But I think that before that we were needing to had a lot of similar calls on splitted ebuilds... then, probably this needed since earlier times
Anyway, I am unsure gimp is doing the "expected" thing per: http://www.murrayc.com/permalink/2011/01/18/avoiding-use-of-deprecated-api/ But, parent bug 614914 is referring to the live version, then, maybe the final tarballs are being properly generated and not facing the issue :/
(In reply to Pacho Ramos from comment #5) > But, parent bug 614914 is referring to the live version, then, maybe the > final tarballs are being properly generated and not facing the issue :/ I'm afraid the next release of Gimp will ship with this problem; the live ebuild just made it show earlier. I'd be happy to turn my previous patch [1] around to ifdef-away the other half of the collision (given that "plug-in[s] can never include gimpcompatenums.h" [2]). Shall I try that? [1] https://614914.bugs.gentoo.org/attachment.cgi?id=469518 [2] https://bugzilla.gnome.org/show_bug.cgi?id=781070#c5
The problem I see to that approach is that, if gimp upstream keeps using GIMP_DISABLE_DEPRECATED in a different way than suggested in http://www.murrayc.com/permalink/2011/01/18/avoiding-use-of-deprecated-api/ this issue will reappear again and again in the future as they won't care. Then, I wouldn't start patching it downstream :/ Anyway, reading the macro from gnome-common and its deprecation: https://git.gnome.org/browse/gnome-common/tree/macros2/gnome-common.m4#n17 https://git.gnome.org/browse/gnome-common/commit/?id=b62c76f204a8cae64dc2c3c33828d27c1a2581e5 https://bugzilla.gnome.org/show_bug.cgi?id=735417 It seems that, in the future (maybe with a next eapi bump) we could reduce the sed to that known cases for compat with old packages. For newer packages, it seems that all will need to move to the usage of AM_MAINTAINER_MODE instead of _DISABLE_DEPRECATED route and, then, gimp upstream will, indeed, be able to use it in a different way than we were expected.
I'm having trouble following in detail. Are you saying that *_DISABLE_DEPRECATED is deprecated in general by now and that once Gimp starts to apply that the problem resolves (because they would then have to fix the enu collisions themselves as part of the process)?
Well, I think that, since the _DISABLE_DEPRECATED usage we are covering with the eclass is deprecated, gimp upstream is not going to stop using it. Then, from my point of view, I think that, in your side, I would try to workaround it at ebuild level (either not using gnome2_src_prepare or trying to bypass the sedding). And in our side (eclass level) we probably could move in the future to drop the old instances (the ones listed in the old gnome-common macros) and not all (for compat with old packages that could still use that instances).
For the bump to Gimp 2.9.6 (bug #628904) I went with the protect-patch-restore approach now: https://github.com/gentoo/gentoo/commit/f77a6f6f98e8b134706bf90cdf2de7e046b2eab0#diff-25900b9833c986af27c7481ad780fa37R97 I'm happy to move to something cleaner as available. How do you want to proceed?
I think I'll close this. Please feel free to re-open as you see fits, okay?
I would keep it open to suggest to change how gnome2_disable_deprecation_warning works in the future (probably for eapi7) I would suggest to make it fit https://bugs.gentoo.org/show_bug.cgi?id=615144#c7 , in summary, instead of killing all variables, kill only the known ones that were used in the past as listed in gnome-common macros