After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782227 - tests fail because `g_type_init` is deprecated
tests fail because `g_type_init` is deprecated
Status: RESOLVED FIXED
Product: planner
Classification: Other
Component: Build
unspecified
Other Linux
: Normal normal
: ---
Assigned To: planner-maint
planner-maint
: 742488 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-05-05 15:01 UTC by Andrew Miloradovsky
Modified: 2017-05-14 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tests: fix the `g_type_init` deprecation warnings (1.83 KB, patch)
2017-05-05 15:03 UTC, Andrew Miloradovsky
rejected Details | Review
‘g_type_init’ is deprecated (1.89 KB, patch)
2017-05-06 18:54 UTC, Ahmed Baïzid
none Details | Review
required Glib 2.35, to clean up g_type_init calls (3.85 KB, patch)
2017-05-08 08:51 UTC, Andrew Miloradovsky
none Details | Review
required Glib 2.35, to clean up g_type_init calls (3.22 KB, patch)
2017-05-08 12:03 UTC, Andrew Miloradovsky
none Details | Review
required Glib 2.36, to clean up g_type_init calls (3.22 KB, patch)
2017-05-08 12:22 UTC, Andrew Miloradovsky
rejected Details | Review
g_type_init() has been deprecated since GLib 2.36. (3.10 KB, patch)
2017-05-14 21:31 UTC, Ahmed Baïzid
committed Details | Review

Description Andrew Miloradovsky 2017-05-05 15:01:00 UTC
(since the warnings are treated as errors)

Solved as described here:

- https://askubuntu.com/questions/262574/how-to-correct-glib-2-35-x-g-type-init-is-deprecated-error-when-compiling-from

The patch is in the way...
Comment 1 Andrew Miloradovsky 2017-05-05 15:03:36 UTC
Created attachment 351206 [details] [review]
tests: fix the `g_type_init` deprecation warnings
Comment 2 Andrew Miloradovsky 2017-05-05 15:07:44 UTC
By the way, `make distcheck` fails with the exact same error, but I'm not yet sure how to fix that.
Comment 3 Ahmed Baïzid 2017-05-06 18:23:27 UTC
These are not errors, just warnings.

But Planner considers warnings as errors (strange but legal). So make some_targets fail. This is bug 703067.
Comment 4 Andrew Miloradovsky 2017-05-06 18:35:49 UTC
Sure, but the tests fail because of those warnings-errors; it may be due to GCC's default behavior or whatever, and the proposed patch is to fix that in a clean way.

Planner's own macros is another story: this Glib version check should be present anyways.
Comment 5 Andrew Miloradovsky 2017-05-06 18:43:59 UTC
By the way, thanks for pointing this out: this is the same bug (but solved differently)

https://bugzilla.gnome.org/show_bug.cgi?id=742488
Comment 6 Ahmed Baïzid 2017-05-06 18:54:12 UTC
Created attachment 351265 [details] [review]
‘g_type_init’ is deprecated

This patch is simpler. Planner code does not have to remember GLib history. Current Planner have to cope with current GLib. g_init() story is dead years ago, it is not actual.
Comment 7 Andrew Miloradovsky 2017-05-06 19:00:23 UTC
Yes it doesn't have to. But then one should update the configuration scripts checking glib version too, not just remove those calls from the C files and imply that Planner cannot compile with an ancient versions of glib :)
Comment 8 Ahmed Baïzid 2017-05-06 19:00:57 UTC
*** Bug 742488 has been marked as a duplicate of this bug. ***
Comment 9 Ahmed Baïzid 2017-05-06 19:22:29 UTC
Who is wasting time compiling new Planner with old Gnome/GTK+/GLIb ?

Planner is in bad need of such expertise.

But he should reverse his path. The situation is worse than : "Oh, external libraries changed... Planner has to take care of that". It is : "Planner does not fit the current Gnome  environment". It lags years of coding behind.
Comment 10 Andrew Miloradovsky 2017-05-06 19:36:10 UTC
I don't really care how it will be resolved as long as it will, but general idea is that when one changes the interface so that it is no longer compatible with an older versions of a library used, it's probably wise to update the stated (version) requirements too. While just saying "it's so old nobody ever going to notice the difference" is probably not.

Even README says "GLIB 2.6.0" -- fix that, and configure.ac, of leave the if-macros.
Comment 11 Ahmed Baïzid 2017-05-06 20:04:02 UTC
I agree : It has to be solved. It should have been.

There is two threads here. One has to separate them. Comment 2, introduced a bug in a bug using the "By the way" formula. The Planner Bugzilla has got a Build Component (https://bugzilla.gnome.org/buglist.cgi?component=Build&product=planner).

Bug 782227, comment 4 : Warnings turned to errors is by no way some default behavior. It is deliberate : acinclude.m4, line 47.

    $ grep -n 'Werror' acinclude.m4
Comment 12 Andrew Miloradovsky 2017-05-06 20:34:05 UTC
- the error in distcheck I mentioned isn't solved by either of the patches proposed so far

- Werror as such should probably not be removed, it doesn't break anything else

- upgrading the interface to at least Glib 2.35.0, and not inserting the macros, is a better solution -- cleaner and solves the "side bug" without hassle

- but it is a little bit more work to do than there is in your patch: `grep -R g_type_init .` and `grep -R 2.6.0 .` (from the sources' root)

PS: I personally have no intentions for an exhaustive solution at the moment
Comment 13 Ahmed Baïzid 2017-05-07 09:40:02 UTC
The "make distcheck" failure is another bug. 

This is bug 782227. The title is : tests fail because `g_type_init` is deprecated.

The "warnings are errors" is not a bug, it is a choice. make, make check succeed without changing any code, just by configuration.

    $ ./configure --enable-compile-warnings=no
    $ make ; make dist

My patch doe not correct an inexistent bug. It cleans up the code, preparing the transition to GNOME 3.
Comment 14 Andrew Miloradovsky 2017-05-07 12:51:21 UTC
Call it a failure or issue instead of a bug, the meaning is the same (and I don't want to discuss it here, move on if you disagree).
Those warnings exist for a reason and should be fixed too, not just disabled (if disabled then temporarily, not committed).
And you should do that in a consistent way (see above).

No need to repeat the title to me, do you think I am unaware?
The only reason I keep talking about the distcheck warning-error is because it's the only advantage of upgrading to a new glib I see, in what you state you are trying to do.
And, by the way, transition to GNOME 3 is much much more work to do than just cutting out four or five function calls, as far as I can tell. But sure you know all of that.

PS: it's getting increasingly harder for me to restrain myself from an ad hominem, I feel like this is what you are trying to do too.
Why don't you talk about the modifications to your patch I'm pointing you to, instead of trying to make me a fool? You are free to leave the last comment.
Comment 15 Andrew Miloradovsky 2017-05-07 13:29:09 UTC
To restate my point: the (exact) issue/bug may be solved two ways:

0. minimal way: leaving the required glib version intact but wrapping the version-specific code into a macros, so that it doesn't trigger the warnings on newer systems

1. exhaustive way: update the required glib version to a newer one (>= 2.35), and simply remove the obsolete code, so that it (even theoretically) simply refuses to build with an older glib

The former is simpler. -- The latter is better, but needs to update README, configure.ac, and maybe some other files referring to the older version of Glib (>= 2.6.0).
Comment 16 Andrew Miloradovsky 2017-05-08 08:51:59 UTC
Created attachment 351327 [details] [review]
required Glib 2.35, to clean up g_type_init calls
Comment 17 Andrew Miloradovsky 2017-05-08 08:57:25 UTC
PS: Sure one might just squash these two patches.
But it's possibly better to retain the intermediate step than save one log entry.
Comment 18 Ahmed Baïzid 2017-05-08 11:48:14 UTC
Review of attachment 351327 [details] [review]:

You should not remove the SCANGOBJ_OPTIONS variable in docs/libplanner/Makefile.am.
The GTK-Doc makefile is quite standard, it is a template from https://git.gnome.org/browse/gtk-doc/tree/examples/Makefile.am.

Something as simple, as :

    @@ -13 +13 @@ DOC_SOURCE_DIR=../../libplanner
    -SCANGOBJ_OPTIONS=--type-init-func="g_type_init()" 
    +SCANGOBJ_OPTIONS=

is enough.

Source : https://developer.gnome.org/gtk-doc-manual/unstable/settingup_automake.html.en
Comment 19 Andrew Miloradovsky 2017-05-08 12:03:17 UTC
Created attachment 351345 [details] [review]
required Glib 2.35, to clean up g_type_init calls
Comment 20 Alexandre Franke 2017-05-08 12:12:41 UTC
(In reply to Andrew Miloradovsky from comment #19)
> required Glib 2.35

Can you make that 2.36 by the way? 2.35 is an unstable release (odd number).
Comment 21 Andrew Miloradovsky 2017-05-08 12:22:28 UTC
Created attachment 351346 [details] [review]
required Glib 2.36, to clean up g_type_init calls
Comment 22 Ahmed Baïzid 2017-05-08 12:45:53 UTC
Review of attachment 351346 [details] [review]:

The situation : make check fails.

  calendar-test.c:20:9: error: ‘g_type_init’ is deprecated
  cc1: all warnings being treated as errors

Applying patches 351206 and 351346 : make check succeeds.

The patches do the job. They are neat.

+1, though I'd prefer them squashed.
Comment 23 Andrew Miloradovsky 2017-05-08 13:13:33 UTC
You may think of the former patch as the minimally necessary solution.
And the latter as being a cleanup, unrelated to a particular bug/issue.
Comment 24 Alexandre Franke 2017-05-14 17:37:21 UTC
Review of attachment 351206 [details] [review]:

That would be the way to go if we cared about keeping compatibility with a very ancient version of glib. Given how old even 2.36 is, we don’t really care in this instance, not even to have that in the git history.
Comment 25 Alexandre Franke 2017-05-14 17:37:28 UTC
Review of attachment 351265 [details] [review]:

Yes, that’s the way to go. This patch lacks documentation update though.
Comment 26 Alexandre Franke 2017-05-14 17:39:04 UTC
Review of attachment 351346 [details] [review]:

Yep, since we don’t care about the previous patch this one is based on, that would be good if it applied on master. So either update this one (to squash it with previous one as Ahmed suggests) or update Ahmed’s patch with the bits that are here and not there.
Comment 27 Andrew Miloradovsky 2017-05-14 18:49:00 UTC
Apparently I cannot disable notifications about this particular "bug", I don't believe it needed 26 comments. -- Do whatever you prefer. I don't really care whose name will be shown on the commit, if ever. And I'm not going to follow the thread anymore.
Comment 28 Alexandre Franke 2017-05-14 18:57:41 UTC
(In reply to Andrew Miloradovsky from comment #27)
> Apparently I cannot disable notifications about this particular "bug",

You should have been able to do it. One has to click “Edit” next to the CC list, select the relevant address and check “Remove selected CC”.

> I
> don't believe it needed 26 comments. -- Do whatever you prefer. I don't
> really care whose name will be shown on the commit, if ever.

Well it sure wasn’t a very complex issue, but even after those 26 comments the patches weren’t ready… We’re getting there though!

> And I'm not
> going to follow the thread anymore.

I unsubscribed you.
Comment 29 Ahmed Baïzid 2017-05-14 21:31:43 UTC
Created attachment 351842 [details] [review]
g_type_init() has been deprecated since GLib 2.36.

Removed attachment 351265 [details] [review].
Squashed attachment 351206 [details] [review] and attachment 351346 [details] [review].
Changed the commit message a little.
The author remains Andrew.
Comment 30 Ahmed Baïzid 2017-05-14 21:40:14 UTC
Review of attachment 351206 [details] [review]:

Obsoleted by attachment 351842 [details] [review].
Comment 31 Ahmed Baïzid 2017-05-14 21:43:12 UTC
Review of attachment 351346 [details] [review]:

Obsoleted by attachment 351842 [details] [review].
Comment 32 Alexandre Franke 2017-05-14 21:46:51 UTC
Review of attachment 351842 [details] [review]:

Thanks to you both, pushed.