Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 615144 - gnome2-utils.eclass: gnome2_disable_deprecation_warning also kills GIMP_DISABLE_DEPRECATED
Summary: gnome2-utils.eclass: gnome2_disable_deprecation_warning also kills GIMP_DISAB...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL: https://bugzilla.gnome.org/show_bug.c...
Whiteboard:
Keywords:
Depends on:
Blocks: gnome2.eclass 614914
  Show dependency tree
 
Reported: 2017-04-10 08:37 UTC by Pacho Ramos
Modified: 2017-09-12 13:24 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2017-04-10 08:37:26 UTC
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
Comment 1 Mart Raudsepp gentoo-dev 2017-04-10 21:48:14 UTC
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
Comment 2 Mart Raudsepp gentoo-dev 2017-04-10 22:10:59 UTC
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.
Comment 3 Sebastian Pipping gentoo-dev 2017-04-10 23:17:19 UTC
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 :)
Comment 4 Pacho Ramos gentoo-dev 2017-04-12 09:43:19 UTC
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
Comment 5 Pacho Ramos gentoo-dev 2017-04-12 09:48:19 UTC
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 :/
Comment 6 Sebastian Pipping gentoo-dev 2017-04-12 10:29:42 UTC
(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
Comment 7 Pacho Ramos gentoo-dev 2017-04-12 10:51:49 UTC
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.
Comment 8 Sebastian Pipping gentoo-dev 2017-04-12 12:00:37 UTC
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)?
Comment 9 Pacho Ramos gentoo-dev 2017-04-20 07:13:43 UTC
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).
Comment 10 Sebastian Pipping gentoo-dev 2017-08-26 19:50:12 UTC
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?
Comment 11 Sebastian Pipping gentoo-dev 2017-09-12 11:57:47 UTC
I think I'll close this.  Please feel free to re-open as you see fits, okay?
Comment 12 Pacho Ramos gentoo-dev 2017-09-12 13:24:07 UTC
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