Your message dated Sun, 8 Apr 2018 11:26:02 +1200
with message-id <>
and subject line Re: Bug#869382: libwxgtk3.0-0: Drawing sample line test broken
has caused the Debian Bug report #869382,
regarding libwxgtk3.0-0: Drawing sample line test broken
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact

Debian Bug Tracking System
Contact with problems
--- Begin Message ---
Package: libwxgtk3.0-0v5
Version: 3.0.2+dfsg-4
Severity: normal
File: libwxgtk3.0-0

Dear Maintainer,

I was trying to use lines in my application which uses wxGTK. I've found that 
in the drawing sample shipped with wxGTK, the lines screen doesn't seem to give 
the correct visual output.

In the "Testing lines of width 0", the "dot/short dash/long dash/dot dash" 
lines appear visually identical. The same is true for the width 1 test.

In the width 2 testh however, the lines start ot be visually distinct.

It looks like the mapping between wxGTK and the gtk drawing code doesn't quite 
tee up.

To reproduce this install the wx3.0-examples package, navigate to
/usr/share/doc/wx3.0-examples/examples/samples, then copy out the drawing 
example to somewhere writeable, eg ~/tmp/wx/drawing. You need to copy 
sample.xpm as well, into the immediate parent path (eg ~/tmp/wx/). 

Then go into ~/tmp/wx/drawing/, and execute make to build the example. Now 
launch the example (./drawing), then in the file menu, select "Lines screen". 
Observe the incorrectly drawn lines.

I'm unsure if this is an upstream bug or not.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libwxgtk3.0-0v5:amd64 depends on:
ii  libc6                     2.24-11
ii  libcairo2                 1.14.8-1
ii  libgcc1                   1:6.3.0-18
ii  libgdk-pixbuf2.0-0        2.36.5-2
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglib2.0-0              2.50.3-2
ii  libgtk2.0-0               2.24.31-2
ii  libjpeg62-turbo           1:1.5.1-2
ii  libnotify4                0.7.7-2
ii  libpango-1.0-0            1.40.5-1
ii  libpangocairo-1.0-0       1.40.5-1
ii  libpng16-16               1.6.28-1
ii  libsm6                    2:1.2.2-1+b3
ii  libstdc++6                6.3.0-18
ii  libtiff5                  4.0.8-2
ii  libwxbase3.0-0v5          3.0.2+dfsg-4
ii  libx11-6                  2:1.6.4-3
ii  libxxf86vm1               1:1.1.4-1+b2

libwxgtk3.0-0v5:amd64 recommends no packages.

libwxgtk3.0-0v5:amd64 suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message ---
Control: fixed 3.0.4+dfsg-3

On Mon, Jul 24, 2017 at 01:09:32PM +1200, Olly Betts wrote:
> Control: tags -1 upstream
> On Sun, Jul 23, 2017 at 06:10:52PM +1200, Olly Betts wrote:
> > Thanks - I can reproduce this with packages based on which I'm
> > working on (not yet uploaded).
> > 
> > On Sat, Jul 22, 2017 at 11:05:09PM +0100, D Haley wrote:
> > > I'm unsure if this is an upstream bug or not.
> > 
> > I'd imagine it is - we aren't patching anything in this area.
> > 
> > Testing with upstream git master using GTK3, the line patterns look
> > right there.  So this may be fixed upstream but need backporting (or
> > have been backported since  Or it may be a GTK2 vs GTK3
> > bug - I'll try to narrow it down later.
> I've tests all four comibinations, and it's specific to GTK2, and works
> with GTK3.  We're considering a switch to GTK3 for buster, which looks
> like it would fix this.

I've just retested with the latest upload (3.0.4+dfsg-3) and the width 0
lines which are meant to have different patterns now do, so it looks
like this was fixed upstream by 3.0.4 (since I tested above).

Marking as fixed in the version I actually tested, but likely it was
fixed in 3.0.4+dfsg-1.

There are also GTK3 packages now, which we're encouraging people to
migrate to.


--- End Message ---

Reply via email to