2.0.17 and deprecated GTK APIs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

2.0.17 and deprecated GTK APIs

Greg Troxel
I just filed a bug about this; building 2.0.17 on NetBSD with pkgsrc
results in a GTK deprecation warning which with -Werror is fatal.

I wonder what the path/timeframe is from the 2.0.18 beta to the actual
2.0.18 release.  (pkgsrc only packages releases, unless we conclude that
an upstream is so troubled that no releases will ever come.)

Greg, N1DAM

Reply | Threaded
Open this post in threaded view
|

Re: 2.0.17 and deprecated GTK APIs

Andy Stewart-2
On 2/28/20 9:39 AM, Greg Troxel wrote:
> I just filed a bug about this; building 2.0.17 on NetBSD with pkgsrc
> results in a GTK deprecation warning which with -Werror is fatal.
>
> I wonder what the path/timeframe is from the 2.0.18 beta to the actual
> 2.0.18 release.  (pkgsrc only packages releases, unless we conclude that
> an upstream is so troubled that no releases will ever come.)
>
> Greg, N1DAM
>

Hi Greg,

I'd probably update the country file information and that's all.  I can't
replicate a NetBSD error here, but if you have a suggested patch, I can give it
a try.

73,

Andy

--
Andy Stewart (KB1OIQ)
Vice President: PART of Westford, MA (WB1GOF)
Founder: Chelmsford Linux Meetup Group
Founder: Worcester Linux Users' Group


Reply | Threaded
Open this post in threaded view
|

Re: 2.0.17 and deprecated GTK APIs

Greg Troxel
Andy Stewart <[hidden email]> writes:

> On 2/28/20 9:39 AM, Greg Troxel wrote:
>> I just filed a bug about this; building 2.0.17 on NetBSD with pkgsrc
>> results in a GTK deprecation warning which with -Werror is fatal.
>>
>> I wonder what the path/timeframe is from the 2.0.18 beta to the actual
>> 2.0.18 release.  (pkgsrc only packages releases, unless we conclude that
>> an upstream is so troubled that no releases will ever come.)
>
> I'd probably update the country file information and that's all.  I
> can't replicate a NetBSD error here, but if you have a suggested
> patch, I can give it a try.

Does master/head still use these?

  GTypeDebugFlags
  GTimeVal

I am getting warnings that they are deprecated, and so if they are in
use it seems they should be adapted to what gtk wants now.

Are you building against gtk2 2.24 and glib2 2.62?  I wonder if this is
about new glib, not new gtk.  We did update to 2.62.4 and I think that
was the change that caused this error.

Reply | Threaded
Open this post in threaded view
|

Re: 2.0.17 and deprecated GTK APIs

Joshua Wood
Hi all,

Ran into the same thing on modern Slackware. GTimeVal has been deprecated for a while now.

Thanks,
JK

On Fri, Feb 28, 2020, 09:30 Greg Troxel <[hidden email]> wrote:
Andy Stewart <[hidden email]> writes:

> On 2/28/20 9:39 AM, Greg Troxel wrote:
>> I just filed a bug about this; building 2.0.17 on NetBSD with pkgsrc
>> results in a GTK deprecation warning which with -Werror is fatal.
>>
>> I wonder what the path/timeframe is from the 2.0.18 beta to the actual
>> 2.0.18 release.  (pkgsrc only packages releases, unless we conclude that
>> an upstream is so troubled that no releases will ever come.)
>
> I'd probably update the country file information and that's all.  I
> can't replicate a NetBSD error here, but if you have a suggested
> patch, I can give it a try.

Does master/head still use these?

  GTypeDebugFlags
  GTimeVal

I am getting warnings that they are deprecated, and so if they are in
use it seems they should be adapted to what gtk wants now.

Are you building against gtk2 2.24 and glib2 2.62?  I wonder if this is
about new glib, not new gtk.  We did update to 2.62.4 and I think that
was the change that caused this error.

Reply | Threaded
Open this post in threaded view
|

Re: 2.0.17 and deprecated GTK APIs

Andy Stewart-2
In reply to this post by Greg Troxel
On 2/28/20 10:30 AM, Greg Troxel wrote:

> Andy Stewart <[hidden email]> writes:
>
>> On 2/28/20 9:39 AM, Greg Troxel wrote:
>>> I just filed a bug about this; building 2.0.17 on NetBSD with pkgsrc
>>> results in a GTK deprecation warning which with -Werror is fatal.
>>>
>>> I wonder what the path/timeframe is from the 2.0.18 beta to the actual
>>> 2.0.18 release.  (pkgsrc only packages releases, unless we conclude that
>>> an upstream is so troubled that no releases will ever come.)
>>
>> I'd probably update the country file information and that's all.  I
>> can't replicate a NetBSD error here, but if you have a suggested
>> patch, I can give it a try.
>
> Does master/head still use these?
>
>    GTypeDebugFlags
>    GTimeVal
>
> I am getting warnings that they are deprecated, and so if they are in
> use it seems they should be adapted to what gtk wants now.
>
> Are you building against gtk2 2.24 and glib2 2.62?  I wonder if this is
> about new glib, not new gtk.  We did update to 2.62.4 and I think that
> was the change that caused this error.
>

I just checked my system, and I have gtk2 2.24.32-1ubuntu1 installed.
For glib2, I have version 2.56.4-0ubuntu0.18.04.4.

I rebuilt the source code and saw no issues with these revs on Ubuntu 18.04.4.

Andy

--
Andy Stewart (KB1OIQ)
Vice President: PART of Westford, MA (WB1GOF)
Founder: Chelmsford Linux Meetup Group
Founder: Worcester Linux Users' Group


Reply | Threaded
Open this post in threaded view
|

Re: 2.0.17 and deprecated GTK APIs

Greg Troxel
In reply to this post by Joshua Wood
Joshua Wood <[hidden email]> writes:

> Ran into the same thing on modern Slackware. GTimeVal has been deprecated
> for a while now.

Can you post what versions of gtk2 and glib2 you have?

When you build xlog against those, does it fail, and are you doing
something to let the deprecated warnings be warnings and not errors?

On my system, I have

gtk2+-2.24.32 (released 2018-01-18, but still current)
glib2-2.62.4 (released 2019-12-19)

FWIW:
  2.64.0 was released on 2020-02-27
  2.62.0 was released on 2019-09-05
  2.60.0 was released on 2019-03-04
  2.58.0 was released on 2018-09-13
  2.56.0 was released on 2018-03-12


It seems that the issue is the combination of

  gtk2+ 2.24.32 uses glib2 features that are marked deprecated

  xlog ends up turning on -Werror which together with the default of
  -wdeprecated-declarations results in a compile error


So to fix this, we need one of

  gtk2+ has a release which doesn't use deprecated glib2 features

  xlog copes with recent releases of both without erroring

  xlog changes to gtk3, because it is becoming clear that gtk2 is not
  longer maintained


Reply | Threaded
Open this post in threaded view
|

Re: 2.0.17 and deprecated GTK APIs

Joshua Wood
Hi,

I'm running gtk+2-2.24.32 and glib2-2.62.4 as well. It did break for me when trying to build with that combo. I ended up sed'ing -Werror out of the configure script, which was the only way I could find to make it build.

Thanks,
JK

On Fri, Feb 28, 2020, 18:57 Greg Troxel <[hidden email]> wrote:
Joshua Wood <[hidden email]> writes:

> Ran into the same thing on modern Slackware. GTimeVal has been deprecated
> for a while now.

Can you post what versions of gtk2 and glib2 you have?

When you build xlog against those, does it fail, and are you doing
something to let the deprecated warnings be warnings and not errors?

On my system, I have

gtk2+-2.24.32 (released 2018-01-18, but still current)
glib2-2.62.4 (released 2019-12-19)

FWIW:
  2.64.0 was released on 2020-02-27
  2.62.0 was released on 2019-09-05
  2.60.0 was released on 2019-03-04
  2.58.0 was released on 2018-09-13
  2.56.0 was released on 2018-03-12


It seems that the issue is the combination of

  gtk2+ 2.24.32 uses glib2 features that are marked deprecated

  xlog ends up turning on -Werror which together with the default of
  -wdeprecated-declarations results in a compile error


So to fix this, we need one of

  gtk2+ has a release which doesn't use deprecated glib2 features

  xlog copes with recent releases of both without erroring

  xlog changes to gtk3, because it is becoming clear that gtk2 is not
  longer maintained

Reply | Threaded
Open this post in threaded view
|

Re: 2.0.17 and deprecated GTK APIs

Greg Troxel
In reply to this post by Andy Stewart-2
On 2020-02-28 18:57, Andy Stewart wrote:

> I just checked my system, and I have gtk2 2.24.32-1ubuntu1 installed.
> For glib2, I have version 2.56.4-0ubuntu0.18.04.4.
>
> I rebuilt the source code and saw no issues with these revs on Ubuntu
> 18.04.4.

Thanks for checking.

Your glib2 is quite old, but you are running Ubuntu 18.04, which is LTS
aka "intentionally running code that was released 2 years ago, with
micro updates only", as I understand it.  Perfectly fine for you to do
that of course, but xlog building in that environment merely shows that
it builds with 2ish-year-old code.  (1.5 in this case, as it seems up to
date with 2.56, but not moved to 2.58 from 2018-09, which is the LTS plan.)

As I see it, the latest formal release of a package should always build
ok when each dependency is the latest formal release of that dependency,
and ideally somewhat older.  If not, a release that does build is
overdue.  (Presumably 18.04 people use the xlog that was current when
18.04 was released, as the LTS plan would indicate, but it also seems
that newer ones and even master/head is ok.)

We have two reports (me on NetBSD/pkgsrc and KC0BUF on slackware) that
xlog fails with up-to-date glib2.  So it's pretty clearly not an
OS/packaging environment problem, and it's also clear by inspection from
the gtk2 headers.

So it seems the thing to do is either to turn off -Werror, or less
drastically to add -Wno-deprecated-declarations into configure.ac.  (I
am using a pkgsrc facility to basically edit flags on the fly, which is
good for working around upstream issues, but obviously not something
that can apply to xlog.)   Reading configure.ac, that seems easy.
My control file lines are:

# Work around https://savannah.nongnu.org/bugs/index.php?57920
_WRAP_EXTRA_ARGS.CC+=   -Wno-deprecated-declarations
CWRAPPERS_APPEND.cc+=   -Wno-deprecated-declarations

which is indeed the same thing for two different wrapper methods.

I can send a patch if that's helpful, given that above.

Plus perhaps file a bug with gtk2 that the latest release fails with
glib2.  This feels like tilting at windmills; it is very hard to even
find their bugtracker and the whole situation seems hard to follow.
(Which I don't enjoy saying as I have been a gtk fan for at least 20
years.)   Which leads to needing to change xlog to gtk3.

73 de n1dam