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 758741 - Cope with vapi change in gobject-2.0
Cope with vapi change in gobject-2.0
Status: RESOLVED FIXED
Product: folks
Classification: Platform
Component: general
git master
Other Linux
: Normal major
: Unset
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2015-11-27 15:05 UTC by Emmanuele Bassi (:ebassi)
Modified: 2016-01-05 08:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Cope with the vapi change in GObjectClass.list_properties() (2.09 KB, patch)
2015-11-27 15:05 UTC, Emmanuele Bassi (:ebassi)
rejected Details | Review
inpect: Fix build with vala git master (1.50 KB, patch)
2015-11-27 15:12 UTC, Rico Tzschichholz
committed Details | Review

Description Emmanuele Bassi (:ebassi) 2015-11-27 15:05:07 UTC
See attached patch.
Comment 1 Emmanuele Bassi (:ebassi) 2015-11-27 15:05:35 UTC
Created attachment 316389 [details] [review]
Cope with the vapi change in GObjectClass.list_properties()

Previously, list_properties() was declared as:

  public unowned ParamSpec[] list_properties()

which leaks, as the underlying C API returns a (transfer container)
array of GParamSpec instances.

The gobject-2.0 vapi has been changed to declare:

  public (unowned ParamSpec)[] list_properties()

which does not leak, but breaks compilation with the existing variable
declarations:

  unowned ParamSpec[] properties =
    persona.get_class().list_properties();

In order to unbreak the build, we need to match the declaration in the
vapi:

  (unowned ParamSpec)[] properties =
    persona.get_class().list_properties();

This requires bumping up the Vala dependency to master.
Comment 2 Emmanuele Bassi (:ebassi) 2015-11-27 15:08:28 UTC
I've tagged vala in gnome-continuous before the gobject-2.0.vapi change, in the meantime.
Comment 3 Rico Tzschichholz 2015-11-27 15:12:22 UTC
Created attachment 316391 [details] [review]
inpect: Fix build with vala git master
Comment 4 Emmanuele Bassi (:ebassi) 2015-11-27 15:16:55 UTC
Rico's patch is likely the safer choice with regards to supporting older versions of Vala.

Whichever patch gets selected, let me know, and I'll untag vala from gnome-continuous.
Comment 5 Philip Withnall 2015-11-30 21:55:31 UTC
Review of attachment 316389 [details] [review]:

Let’s go with Rico’s patch.
Comment 6 Philip Withnall 2015-11-30 21:55:35 UTC
Review of attachment 316391 [details] [review]:

Thanks for the patch, please commit to master!
Comment 7 Rico Tzschichholz 2015-12-01 07:17:01 UTC
Attachment 316391 [details] pushed as 50df98c - inpect: Fix build with vala git master
Comment 8 Daniel Stone 2015-12-09 19:40:52 UTC
Unfortunately, current 3.18.x jhbuild is broken for me on that exact spot:
utils.vala:129.27-131.52: error: Invalid assignment from owned expression to unowned variable
utils.vala:134.43-134.52: error: The name `properties' does not exist in the context of `Folks.Inspect.Utils.print_individual'
      foreach (unowned ParamSpec pspec in properties)
                                          ^^^^^^^^^^
utils.vala:173.27-175.49: error: Invalid assignment from owned expression to unowned variable
utils.vala:178.43-178.52: error: The name `properties' does not exist in the context of `Folks.Inspect.Utils.print_persona'
      foreach (unowned ParamSpec pspec in properties)
                                          ^^^^^^^^^^
utils.vala:214.27-216.47: error: Invalid assignment from owned expression to unowned variable
utils.vala:219.43-219.52: error: The name `properties' does not exist in the context of `Folks.Inspect.Utils.print_persona_store'
      foreach (unowned ParamSpec pspec in properties)
                                          ^^^^^^^^^^

folks master (ironically at 50df98c9f1), vala 0.30 branch (50e9c5f3c7). The obvious hack to just make the ParamSpec owned fixes the build, but is probably wildly incorrect.

Can someone with editbugs permission please reopen?
Comment 9 Philip Withnall 2015-12-09 21:02:46 UTC
Rico?
Comment 10 Philip Withnall 2016-01-04 22:48:30 UTC
commit 4e1d57e6fbc6ec0aa068fa30de1aa29e6514327f
Author: Philip Withnall <philip@tecnocode.co.uk>
Date:   Mon Jan 4 22:46:38 2016 +0000

    inspect: Remove conditional compilation in favour of ‘var’
    
    This copies the array but at least it compiles happily on all versions
    of Vala.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=758741

 tools/inspect/utils.vala | 27 ++++++---------------------
 1 file changed, 6 insertions(+), 21 deletions(-)
Comment 11 Rico Tzschichholz 2016-01-05 07:21:55 UTC
Hmm, I guess I missed the previous comments here.

@philip: Although I assume you didn't try to reproduce the problem? So this "revert" should not be needed at all! Meaning it works fine with vala 0.30.0 and 0.30-git.

https://git.gnome.org/browse/vala/commit/?h=0.30&id=c43ae0d6322845193a50bf2fd5a5619eb6423e7e
Comment 12 Philip Withnall 2016-01-05 08:59:14 UTC
(In reply to Rico Tzschichholz from comment #11)
> Hmm, I guess I missed the previous comments here.
> 
> @philip: Although I assume you didn't try to reproduce the problem? So this
> "revert" should not be needed at all! Meaning it works fine with vala 0.30.0
> and 0.30-git.
> 
> https://git.gnome.org/browse/vala/commit/?h=0.
> 30&id=c43ae0d6322845193a50bf2fd5a5619eb6423e7e

I vaguely tried to reproduce it, but spending several hours recompiling all combinations of folks, Vala and Valadoc is not my idea of a fun evening.