Update gnumeric @0.10.17 to 0.12.4

[c.herbig@…]

Needs the new goffice @0.10.4 port first ​#39717

[c.herbig@…]

Wow, I should stop doing this at 2 in the morning. It should have been gnumeric @1.10.17 to 1.12.4 However, it already needs to be revised to comply with the + depends_run port:yelp that devans added to the gnome apps. Also, perhaps I should have filed separate tickets for the whitespace changes and then for the updates?

[c.herbig@…]

So, to do one thing clearly at a time, here is a portfile that tidies up the whitespace for the existing gnumeric port file.

[c.herbig@…]

changes whitespace

[c.herbig@…]

Can somebody add haspatch to this please?

[neverpanic (Clemens Lang)]

It already has the haspatch keyword?

[c.herbig@…]

Replying to cal@…:

It already has the haspatch keyword?

Um, of course, I knew that! I was just testing you...

Yeah, ok, I've gotta just eat this one, I have no idea why I thought this one didn't have haspatch, and thus felt compelled to correct it.

From now on, I promise I will stop attending to these matters in the wee hours of the morning.

[c.herbig@…]

Perhaps devans should be cc'd on this one since they are doing the gnome stuff.

[c.herbig@…]

If you're not interested in the trivial whitespace changes, I could just submit the changes that do the actual version updates...

[c.herbig@…]

Well, here is a diff based on my portfile for gnumeric 1.12.4

Notable changes to gnumeric: Gtk3 based, uses gsettings, no more gconf, and various improvements to Excel file and function compatibility.

[c.herbig@…]

updates to 1.12.4 (some metadata changes too)

[neverpanic (Clemens Lang)]

There's nothing wrong with your patches, but apparently nobody has had any time to review and apply them yet. Please provide whitespace changes as separate diffs (but not necessarily separate tickets).

I currently have no time to take care of this one, but if nobody takes this ticket, consider dropping a mail to the macports-dev list.

[c.herbig@…]

Replying to cal@…:

There's nothing wrong with your patches, but apparently nobody has had any time to review and apply them yet. Please provide whitespace changes as separate diffs (but not necessarily separate tickets).

I currently have no time to take care of this one, but if nobody takes this ticket, consider dropping a mail to the macports-dev list.

Would it help at all if I offered to take maintainership (along with open maintainer)? I'm not really a programmer, but I am interested in keeping this and goffice up to date with the latest point releases, especially when updates deal with file compatibility.

[neverpanic (Clemens Lang)]

Replying to c.herbig@…:

Would it help at all if I offered to take maintainership (along with open maintainer)? I'm not really a programmer, but I am interested in keeping this and goffice up to date with the latest point releases, especially when updates deal with file compatibility.

While it wouldn't immediately help with this ticket, it would certainly help to speed up future updates. If nobody has taken care of this by Thursday, I'll find some free time to do it.

[c.herbig@…]

Meanwhile, I am making new .diff files from the latest portfile from MacPorts, since the version in my local repository is already out of sync for how this should all be.

[c.herbig@…]

whitespace changes

[c.herbig@…]

version, deps update

[c.herbig@…]

Here are the latest .diffs that I made. Hopefully no more patch errors or $ ID$ line changes from my copy being out of sync with the MacPorts one. Basically, the whitespace changes justify everything to 5 tabs so that it doesn't get bunched up into the long_description. I regrouped some of the metadata in a way that seems more logical to myself.

The gconf lines have been removed since gnumeric does not use gconf at all anymore. I played with the std=gnu89, and for me at least, the config phase was smart enough to deal with that on its own. All of the other dependencies seem to be taken care of by gtk3/goffice.

[su-v]

AFAIU the dependency on py*-gobject needs to be changed to py*-gobject3 for Python support in GTK3-based Gnumeric.

[c.herbig@…]

Replying to suv-sf@…:

AFAIU the dependency on py*-gobject needs to be changed to py*-gobject3 for Python support in GTK3-based Gnumeric.

Can you provide a reference, or other port file examples?

I have experimented with py33-gobject3, and it seemed to compile, but I was not aware of any other changes.

[su-v]

Replying to c.herbig@…:

Replying to suv-sf@…:

AFAIU the dependency on py*-gobject needs to be changed to py*-gobject3 for Python support in GTK3-based Gnumeric.

Can you provide a reference, or other port file examples?

No reference - this was simply based on monitoring the output of the configure phase for a local "devel" port of Gnumeric 1.12.4:

With py27-gobject already installed, but not py27-gobject3, Gnumeric 1.12.4 is configured without Python support:

	Perl Support:		yes (using perl)
	Python Support:		Missing pygobject

After activating py27-gobject3 (installed independently), Gnumeric 1.12.4 is configured with Python support:

	Perl Support:		yes (using perl)
	Python Support:		yes (using /opt/local/bin/python2.7)

[c.herbig@…]

Replying to suv-sf@…:

Replying to c.herbig@…:

Replying to suv-sf@…:

AFAIU the dependency on py*-gobject needs to be changed to py*-gobject3 for Python support in GTK3-based Gnumeric.

Can you provide a reference, or other port file examples?

No reference - this was simply based on monitoring the output of the configure phase for a local "devel" port of Gnumeric 1.12.4:

With py27-gobject already installed, but not py27-gobject3, Gnumeric 1.12.4 is configured without Python support:

	Perl Support:		yes (using perl)
	Python Support:		Missing pygobject

After activating py27-gobject3 (installed independently), Gnumeric 1.12.4 is configured with Python support:

	Perl Support:		yes (using perl)
	Python Support:		yes (using /opt/local/bin/python2.7)

Good enough for me. I'll change that.

[c.herbig@…]

Replying to suv-sf@…:

AFAIU the dependency on py*-gobject needs to be changed to py*-gobject3 for Python support in GTK3-based Gnumeric.

Changing the pyX-gobject to pyX-gobject3 will kill the python25 variant, there seems to be no py25-gobject3. I personally am OK with this since python 2.5 is obsolete, but I just wanted to mention this in case anybody else is depending on it.

[c.herbig@…]

updated Python deps. Marked 25 as obsolete, added 33 as experimental

[c.herbig@…]

I haven't removed it from the portfile yet, but the following config argument is now no longer recognized: --disable-schema-install

[c.herbig@…]

Removed --disable-schema-install from configure options. Also wrapped the post-activate calls inside catch. It quelled an error that started appearing for update-desktop-database, even though it didn't actually seem to break the port.

[c.herbig@…]

After repeatedly trying, then talking to the gnumeric devs, I removed the experimental python33 variant.

[c.herbig@…]

Tidy based on last official gnumeric portfile revisions

[neverpanic (Clemens Lang)]

Enabled introspection and committed in r109236.

[c.herbig@…]

Replying to cal@…:

Enabled introspection and committed in r109236.

Thank you. Not to beat a dead horse, but what is introspection and/or why are we wanting it in everything/should I be trying to enable it in other ports I play with?

[neverpanic (Clemens Lang)]

gobject-introspection is a tool used in GNOME to generate a description of the C APIs available in a software. This description (stored in .typelib and .gir files) is the official method to access these APIs in a number of languages such as Python, Vala and JavaScript. Since those languages are getting more common in GNOME software these days, we are trying to build every GNOME package with introspection enabled.