GNOME Bugzilla – Bug 762780
app.vala:370.5-370.40: error: Vte.Terminal.set_color_cursor_foreground is not available in vte-2.91 0.43.3. Use vte-2.91 >= 0.44
Last modified: 2016-04-15 16:47:24 UTC
vte (vte-0-44 branch) is broken in jhbuild: VALAC vte_2_91_vala.stamp app.vala:370.5-370.40: error: Vte.Terminal.set_color_cursor_foreground is not available in vte-2.91 0.43.3. Use vte-2.91 >= 0.44 terminal.set_color_cursor_foreground(App.Options.get_color_cursor_foreground()); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Compilation failed: 1 error(s), 0 warning(s) Not sure what to do about this, nor even sure where the 0.43.3 is coming from, that's really weird as this is a completely clean build, the version number should be 0.43.90... my best guess is that it's using the vte bindings shipped by vala, which I built against vte 0.43.3 because jhbuild always builds vala before vte.
Please revert https://git.gnome.org/browse/jhbuild/commit/?id=d79e78c0b2860a8fb56be5cae7e0d8d7ffd5bf54 when this is fixed. Bonus points if someone fixes this before the next GNOME release.
Also to be clear, there are maybe two be two different bugs that need fixed here: (a) wrong vte bindings being used to compile app.vala(?), and (b) seems impossible to use a since tag for the next stable release in an unstable release(?).
Created attachment 322540 [details] [review] build: Pass --disable-since-check to internal valac build
is app.vala being compiled with the in-tree .vapi?
(In reply to Ben from comment #4) > is app.vala being compiled with the in-tree .vapi? My guess is it's being compiled with vala's vapi, not the in-tree vapi, as I have no other way to explain why 0.43.3 is in the error message when compiling vte 0.43.90. Rico, does it make sense to delete the vapi shipped by vala, if they're interchangeable? Anyway, I'm unsure how any application can know whether it's getting the vte bindings from vte or the vte bindings from vala.
The vte-2.91 vapi only exists in vte not vala's vapi collection, and yes it is using the just-built one, not an installed one, or it wouldn't know anything about the new function. This all works for me here btw (valac --version says 0.30.0.3), and on build.g.o too, apparently.
(In reply to Christian Persch from comment #6) > The vte-2.91 vapi only exists in vte not vala's vapi collection, and yes it > is using the just-built one, not an installed one, or it wouldn't know > anything about the new function. OK you're right... I saw vte-2.90 in the vala repository and got confused.
Where exactly is vala getting the vte version from, anyway? There's no mention of it in the gir or vapi files, here.
Could it be using the vte-2.91 vapi already installed in the install prefix?
Rico's patch looks sane and should fix the problem, even if we don't understand this fully... can we land it?
Unfortunately older valac versions don't know that option, so we'll need a configure check too.
*** Bug 763349 has been marked as a duplicate of this bug. ***
It gets the vte version from the pkg-config file, in ~/jhbuild/install/lib/pkgconfig/vte-2.91.pc Maybe we should set PKG_CONFIG_PATH? Also, I think the version in configure.ac needs to be updated to 0.46.0 because we have since: annotations with 0.46
Would be really good to get this fixed in time for 3.20, so we can revert https://git.gnome.org/browse/jhbuild/commit/?id=d79e78c0b2860a8fb56be5cae7e0d8d7ffd5bf54 (In reply to Ben from comment #13) > It gets the vte version from the pkg-config file, in > ~/jhbuild/install/lib/pkgconfig/vte-2.91.pc Good find. > Maybe we should set PKG_CONFIG_PATH? > > Also, I think the version in configure.ac needs to be updated to 0.46.0 > because we have since: annotations with 0.46 It's expected that the since: annotation matches the next stable release. Anyway, --disable-since-check should take care of that.
(In reply to Michael Catanzaro from comment #14) > (In reply to Ben from comment #13) > > It gets the vte version from the pkg-config file, in > > ~/jhbuild/install/lib/pkgconfig/vte-2.91.pc > > Good find. Note, this is easy to workaround in jhbuild by configuring it to uninstall vte before building it, like we do for evolution. I plan to do this soon. (In reply to Rico Tzschichholz from comment #3) > Created attachment 322540 [details] [review] [review] > build: Pass --disable-since-check to internal valac build With my release team hat on, to get vte and Terminal building from git master again, I'm planning to push this tomorrow, unless Christian objects. I can't imagine why anyone would ever want since-check if it doesn't understand GNOME's stable/unstable numbering scheme.
As per comment 11, we need a configure check for this flag, since older vala doesn't understand the option.
Created attachment 325054 [details] [review] build: pass --disable-since-check to internal valac build With configure check.
Can someone look at this bug? And once fixed also update jhbuild modules to build correct branches for 3.20 and 3.22.
*** Bug 764779 has been marked as a duplicate of this bug. ***
Christian, are you going to push this fix also in vte-0-44 branch?
If you want it there, please cherry-pick -x it onto vte-0-44.