#13180 closed defect (fixed)

gimp-2.10.18

Reported by: ken@… Owned by: ken@…
Priority: normal Milestone: 9.1
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

On 2/21/20 8:57 PM, Ell via gimp-developer-list wrote:

Hey, we're doing a ninja 2.10.18 release. There was an ugly data corruption bug in 2.10.16 (https://gitlab.gnome.org/GNOME/gimp/issues/4643) -- good thing we didn't announce it yet, huh? :) We want to do it later today or tomorrow (more likely). Just a heads up, if you have some last-minute fixes to push.

Well, this wasn't actually supposed to go to the list, but whatever. If anyone is already using 2.10.16, you might want to revert to 2.10.14 for now. There should be a new release soon.

-- Ell

Change History (10)

comment:1 by ken@…, 17 months ago

Owner: changed from blfs-book to ken@…
Status: newassigned

comment:2 by Bruce Dubbs, 17 months ago

The patches seem to be minimal. We can probably create a consolidated patch if they don't release an updated version first. We still have 9 days to our scheduled release.

comment:3 by Douglas R. Reno, 17 months ago

Ouch, I legitimately just built that because I needed it for Gutenprint...

Reverting to 2.10.14 on my system now.

comment:4 by ken@…, 17 months ago

2.10.18 seems to be in the process of uploading - 'LATEST IS' now says 2.10.18 and there is a link for the tarball, but for me that link is not (yet) found.

comment:5 by Bruce Dubbs, 17 months ago

I was just able to download it:

096d04ffb2c4559cb2152f507ff31c9c  gimp-2.10.18.tar.bz2
32 MB

comment:6 by ken@…, 17 months ago

Thanks.

Overview of Changes from GIMP 2.10.16 to GIMP 2.10.18 =====================================================

Core:

  • In gimp:replace, when compositing the same content over itself, i.e., when the input and aux buffers share the same storage and same tile alignment, pass the input buffer directly as output, instead of doing actual processing. In particular, this happens when processing a pass-through group outside of its actual bounds.

User interface:

  • Add new Symbolic-High-Contrast and Symbolic-Inverted-High-Contrast themes, which are automatically-generated high-contrast variants of the (original) Symbolic theme. The contrast factor is settable in the makefile, and is currently at 1.5 for both themes.

  • Rename tools/invert-svg to tools/svg-contrast, which now takes a contrast-factor argument, and adjusts the input SVG contrast, instead of just inverting it. Note that we can still use the tool to invert icons, using a contrast of -1.
  • Allow horizontal scrollbars in all the Preferences dialog tree- views, so that they don't limit the minimal width of the dialog (in particular, the UI- and icon-theme tree-views may contain arbitrarily-long paths).
  • Draw a border around the color FG/BG color areas as a pair of black and white rectangles instead of letting GTK do this. This imporoves the legibility of borders, especially in dark themes.

Tools:

  • In GimpPaintTool, when not snapping brush outline to stroke, make sure to properly snap the cursor position to 15-degree angle multiples in line mode, not only when painting the line, but also during motion.

Plug-ins:

  • Add naive support for CMYK 8-bit PSD files

Updated translations:

  • Basque, Catalan, Danish, Polish, Spanish, Swedish, Ukrainian

Bug fixes:

Developers:

  • Ell, Massimo Valentini

Translators:

  • Alan Mortensen, Anders Jonsson, Asier Sarasua Garmendia, Daniel Korostil, Jordi Mas, Piotr Drąg, Rodrigo Lledó Milanca

Clearly the problem in 2.10.16 was https://gitlab.gnome.org/GNOME/gimp/issues/4643

comment:7 by Bruce Dubbs, 17 months ago

Summary: gimp-2.10.18 or revert to 2.10.14gimp-2.10.18

I was not able to build 2.10.18 without --disable-python.

plug-ins/pygimp/gimpuimodule.c has

#include <pygtk/pygtk.h>

but that is not installed AFAICS with pygtk. There is no mention to that file in my pygtk log.

comment:8 by ken@…, 17 months ago

Didn't see that, I've upgraded from 2.10.16, and on another machine with 2.10.14 and old libmypaint, and done a manual DESTDIR install to measure it, all without any problems.

The only oddity was that the build and tests are a bit larger, but I guess that is related to the several changes.

I have /usr/include/pygtk-2.0/pygtk/pygtk.h

And looking at parts of pygtk-2.0.pc:

# you can use the --variable=pygtkincludedir argument to
# pkg-config to get this value.  You might want to use this to
# install additional headers.
pygtkincludedir=${includedir}/pygtk-2.0
...
Cflags: -I${pygtkincludedir}

And from the build itself: {{{checking for PYGTK... yes checking for pygtk-codegen-2.0... /usr/bin/pygtk-codegen-2.0 checking for pygtk defs... /usr/share/pygtk/2.0/defs }}}

I was going to close this as fixed (r22752), but I'll leave it open since you have this issue.

in reply to:  8 comment:9 by Bruce Dubbs, 17 months ago

Replying to ken@…:

I have /usr/include/pygtk-2.0/pygtk/pygtk.h

I didn't have that. I rechecked my dependencies and did not have libglade. Rebuilt pygtk and I now have it. I guess the gtk.glade module is built by default.

comment:10 by Bruce Dubbs, 17 months ago

Resolution: fixed
Status: assignedclosed

Issue is fixed. Closing.

Note: See TracTickets for help on using tickets.