Created attachment 82964 [details] glib: fix deprecation symbols for gtk+ 3.10 In gtk 3.10 there some symbols removed and poppler fails to build without disabling deprecated symbols. The patch attached fix the deprecated symbols. The symbols are available since 3.0, so this should be safe.
why does it fail to build? it should give just compile warnings, that we should silence, but I don't think we need to change the code for symbols deprecated in a gtk+ version higher than the required one
(In reply to comment #1) > why does it fail to build? it should give just compile warnings, that we > should silence, but I don't think we need to change the code for symbols > deprecated in a gtk+ version higher than the required one At least in GNOME, jhbuild disables deprecated symbols by default. I saw 2 options: 1. Add an option in jhbuild to not check deprecated symbols. 2. Migrate the old API to the new one. In the long term, (2) is better IMVHO. The changes I applied are the ones suggested in the migration guide from gtk+2 to Gtk+3: https://developer.gnome.org/gtk3/stable/checklist-named-icons.html They did not bite before, but it is supposed to be part of the migration.
(In reply to comment #2) > (In reply to comment #1) > > why does it fail to build? it should give just compile warnings, that we > > should silence, but I don't think we need to change the code for symbols > > deprecated in a gtk+ version higher than the required one > > At least in GNOME, jhbuild disables deprecated symbols by default. > > I saw 2 options: > 1. Add an option in jhbuild to not check deprecated symbols. > 2. Migrate the old API to the new one. > > In the long term, (2) is better IMVHO. > > The changes I applied are the ones suggested in the migration guide from > gtk+2 to Gtk+3: > https://developer.gnome.org/gtk3/stable/checklist-named-icons.html > > They did not bite before, but it is supposed to be part of the migration. We depend on 3.0 and fortunately stock icons are present in 3.0. It's very unfortunate that stock icons are deprecated in 3.10, but I don't think we should migrate our code for an unstable gtk version that hasn't even been released yet. I will keep using stock icons while they are available because they fail at compile time, not like the string you used, where a typo will not be caught by the compiler. Given the amount of gtk symbols that are being deprecated lately I don't think jhbuild should disable deprecated api by default, and I recommend you to change that configuration in your .jhbuildrc if possible.
(In reply to comment #2) > (In reply to comment #1) > > why does it fail to build? it should give just compile warnings, that we > > should silence, but I don't think we need to change the code for symbols > > deprecated in a gtk+ version higher than the required one > > At least in GNOME, jhbuild disables deprecated symbols by default. Sorry, but that is not accurate. jhbuild doesn't do that by default. FWIW, just in case, I made a sanity check: <API> fredp, ping <API> although probably jjardon also knows that <fredp> pong <API> fredp, here: <API> https://bugs.freedesktop.org/show_bug.cgi?id=67278#c2 <API> it says that "jhbuild disables deprecated symbols by default" <API> that sounds really wrong to me <fredp> well, we don't <fredp> I thought maybe the jhbuildrc we publish along tarballs does, but not even. > I saw 2 options: > 1. Add an option in jhbuild to not check deprecated symbols. Well, as I said, the problem is not at jhbuild. After doing some searching I found that poppler is hardcoding GTK_DISABLE_DEPRECATED at glib/demo/Makefile.am. More about the previous chat, that include some suggestions: <API> fredp, ok, thanks, just wanted a sanity check <fredp> so perhaps there is a wiki page that hints at --disable-deprecated <fredp> I'll check <API> fredp, well, I think that this poppler fault <API> from his Makefile.am, have just found this: <API> INCLUDES = \ <API> -I$(top_srcdir)/glib \ <API> -I$(top_builddir)/glib \ <API> $(GTK_TEST_CFLAGS) \ <API> $(POPPLER_GLIB_DISABLE_DEPRECATED) \ <API> -DGTK_DISABLE_DEPRECATED \ <API> $(POPPLER_GLIB_DISABLE_SINGLE_INCLUDES) <API> they are hardcoding -DGTK_DISABLE_DEPRECATED <API> imho, that should be added(or not) at POPPLER_GLIB_DISABLE_DEPRECATED, that is the one that is filled on the configure.ac <walters> IMO all of those things should just be deleted <walters> the new way of handing deprecations is just better in every way <API> walters, perhaps a new gnome goal? * API checking, just in case that goal already exists <walters> sure, though there's not that many projects using them still i don't think <API> walters, well, at least poppler is ;) <API> and they blame jhbuild <API> in any case, thanks for the feedback, I will comment on the bug * walters did https://git.gnome.org/browse/libbonobo/commit/?id=fef13a371fc91f6d9b42518126c2a8b459fdf0e8 a while ago for example
(In reply to comment #4) > [...] > Well, as I said, the problem is not at jhbuild. After doing some searching I > found that poppler is hardcoding GTK_DISABLE_DEPRECATED at > glib/demo/Makefile.am. More about the previous chat, that include some > suggestions: This was already fixed on July 30: http://cgit.freedesktop.org/poppler/poppler/commit/?id=ef9d861486d54fb3dcf7b8bca01bd44c3b3361a9 However, it seems it came just after the 2.24.0 release. That might explain why people are still having problems with this.
> This was already fixed on July 30: > > http://cgit.freedesktop.org/poppler/poppler/commit/ > ?id=ef9d861486d54fb3dcf7b8bca01bd44c3b3361a9 > > However, it seems it came just after the 2.24.0 release. That might explain > why people are still having problems with this. I hit this bug while using jhbuild today, I'm new to jhbuild, but given the fix it's already in master, shouldn't be picked up by jhbuild? or does jhbuild build the last tag revision on master? .. any know a quick workaround fix for jhbuild for this bug? Regards,
(In reply to comment #6) > > This was already fixed on July 30: > > > > http://cgit.freedesktop.org/poppler/poppler/commit/ > > ?id=ef9d861486d54fb3dcf7b8bca01bd44c3b3361a9 > > > > However, it seems it came just after the 2.24.0 release. That might explain > > why people are still having problems with this. > > I hit this bug while using jhbuild today, I'm new to jhbuild, but given the > fix it's already in master, shouldn't be picked up by jhbuild? or does > jhbuild build the last tag revision on master? .. any know a quick > workaround fix for jhbuild for this bug? jhbuild in gnome modulesets uses poppler from tarball, not from the master. It is needed a new poppler release and bump the version in the modulesets.
(In reply to comment #7) > (In reply to comment #6) > > I hit this bug while using jhbuild today, I'm new to jhbuild, but given the > > fix it's already in master, shouldn't be picked up by jhbuild? or does > > jhbuild build the last tag revision on master? .. any know a quick > > workaround fix for jhbuild for this bug? > > jhbuild in gnome modulesets uses poppler from tarball, not from the master. > It is needed a new poppler release and bump the version in the modulesets. Ok, thanks for the quick response, that is indeed the clean fix, but for anyone that don't want to wait, this is what I've just done to build from poppler master: - Convert the poppler repo from tarball to git in /modulesets/gnome-suites-core-deps-3.10.modules inside the jhbuild checkout. Will attach a diff showing what changed. - Make jhbuild obey the aforementioned local file by putting the following line into your ~/.config/jhbuildrc file: use_local_modulesets = True With above my jhbuild progresses and builds poppler from master.
Created attachment 84184 [details] [review] Changes to /modulesets/gnome-suites-core-deps-3.10.modules Convert poppler from tarball repo to git repo, so it builds from master.
I think the right solution is to add a patch for the current poppler tarball to jhbuild.
It seems a fix has already been commited to jhbuild to fix this issue, see: https://git.gnome.org/browse/jhbuild/commit/?id=63788a02879b5a8d41ae9eda882b009323aa5b55
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.