Tag: bug

PNGtools 0.4

Wow, this is a blast from the past. When I wrote the pngchunks command in 2003, I had never seen a 64 bit machine, and knew enough to check that an int was the right size, but not enough to just use the guaranteed-to-be-32-bit version from day 1. I’d pretty much forgotten about this code until I got pinged about this Debian bug. The bug reporter is entirely right, this was lame.

PNGtools 0.4 should be 64 bit safe. The pngchunks command works on my 64 bit machines at least.

A historical note from November 2020: this code is quite old, but still actively used. I have therefore converted the old subversion repository to git and it is hosted at https://github.com/mikalstill/pngtools. I will monitor there for issues and patches and try my best to remember what I was thinking 20 years ago…

Weird paramiko problem

I had a strange paramiko problem the other day. Sometimes executing a command through a channel (via the exec_command() call) would result in an exit code being returned, but no stdout or stderr. This was for a command I was absolutely sure always returns output, and it wasn’t consistent — I’d run batches of commands and about 10% of them would fail, but not always on the same machine and not always at the same time. I spent ages looking at my code, and the code for the command running at the other end of the channel.

Then it occurred to me that this seemed a lot like a race condition. I started looking at the code for the paramiko Channel class, and ended up deciding that the answer was to check that the eof_received member variable was true before trying to close the channel.

It turns out this just works. I’ve my code running commands for a couple of days now and have had zero more instances of the “no output, but did exit” error. So, there you go. Its a shame that member variable doesn’t have accessors and isn’t documented though. I guess that makes my code a little more fragile than I would be happy with.

ImageMagick bug?

Subject: imagemagick: If the trailing character of a montage label option is a percent sign, the output image is erroneous
Package: imagemagick
Version: 6:6.2.3.6-3
Severity: normal

*** Please type your report below this line ***

Executing this command line:

montage -geometry +10+10 -tile 2 -label "-sepia-tone 15%%" \
ImageMagick_Chapter5_Insert20a.jpg -label "-sepia-tone 35%%" \
ImageMagick_Chapter5_Insert20b.jpg -label "-sepia-tone 55%%" \
ImageMagick_Chapter5_Insert20c.jpg -label "-sepia-tone 75%%" \
ImageMagick_Chapter5_Insert20d.jpg ImageMagick_Chapter5_Insert20.jpg

Whereas this command line:

montage -geometry +10+10 -tile 2 -label "-sepia-tone 15%% " \
ImageMagick_Chapter5_Insert20a.jpg -label "-sepia-tone 35%%" \
ImageMagick_Chapter5_Insert20b.jpg -label "-sepia-tone 55%%" \
ImageMagick_Chapter5_Insert20c.jpg -label "-sepia-tone 75%%" \
ImageMagick_Chapter5_Insert20d.jpg ImageMagick_Chapter5_Insert20.jpg

Produces the expected output:

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
    APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
    Architecture: i386 (i686)
    Shell:  /bin/sh linked to /bin/bash
    Kernel: Linux 2.6.11
    Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

    Versions of packages imagemagick depends on:
    ii  libmagick6                   6:6.2.3.6-3 Image manipulation library

    imagemagick recommends no packages.

    -- no debconf information

Why Debian?

Why do I use Debian? Well, one of the reasons is the bug reporting. I think I just found two bugs in ImageMagick, one a simple documentation bug, and the other a functionality bug. With Debian, I can just run the reportbug command from the command line with the name of the package, and walk through the simple bug reporting process, instead of having to fight my way through mailing lists for the dozens of different packages I have installed. It’s nice.