Bug#1007234: Test suite fails on all but amd64 arches
I don't know familiar you are with debuggers, C, or C arithmetic, so I'm
attaching a diagnostic version of the program and will also explain where I
think the problem lies in case you want to investigate on your own.
If you put this .c file in converter/other/pnmtopalm/ and rebuild and run the
'palmtopnm' executable that results, it should detect the failure and write
some useful diagnostic messages. Tell me what happens.
The problem is in function 'readPackBitsRow16'. The variable 'j' is getting
too large -- absurdly large, apparently because a bit code that is supposed to
encode a negative signed integer is being interpreted as a positive unsigned
one somewhere. It should not be hard to pinpoint where the arithmetic is
generating such a a large number.
--
Bryan Henderson San Jose, California/**
palmtopnm
***
By Bryan Henderson, San Jose, California, June 2004.
Inspired by and using methods from Tbmptopnm by Ian Goldberg
, and Bill Janssen .
Major fixes and new capability added by Paul Bolle
in late 2004 / early 2005.
Bryan's work is contributed to the public domain by its author.
**/
#include
#include
#include "pm_c_util.h"
#include "pnm.h"
#include "shhopt.h"
#include "mallocvar.h"
#include "palm.h"
#include "palmcolormap.h"
enum PalmCompressionType {
COMPRESSION_NONE,
COMPRESSION_RLE,
COMPRESSION_SCANLINE,
COMPRESSION_PACKBITS
};
struct PalmHeader {
unsigned short cols;
unsigned short rows;
unsigned short bytesPerRow;
unsigned short flags;
bool directColor;
/* The header indicates a direct color raster, either by flag
(the old way) or by pixel format (the new way)
*/
bool hasColormap;
bool hasTransparency;
unsigned char pixelSizeCode;
unsigned int pixelSize;
unsigned char version;
unsigned int transparentIndex;
enum PalmCompressionType compressionType;
/* version 3 encoding specific */
unsigned char size;
unsigned char pixelFormat;
unsigned short density;
unsigned long transparentValue;
};
struct DirectPixelFormat {
unsigned int redbits;
unsigned int greenbits;
unsigned int bluebits;
};
struct DirectColorInfo {
struct DirectPixelFormat pixelFormat;
ColormapEntrytransparentColor;
};
struct CmdlineInfo {
/* All the information the user supplied in the command line,
in a form easy for the program to use.
*/
const char * inputFilespec;
unsigned int verbose;
unsigned int rendition;
unsigned int showhist;
unsigned int transparent;
};
static void
parseCommandLine(int argc, const char ** argv,
struct CmdlineInfo *cmdlineP) {
/*
Note that the file spec array we return is stored in the storage that
was passed to us as the argv array.
-*/
optEntry * option_def;
/* Instructions to pm_optParseOptions3 on how to parse our options.
*/
optStruct3 opt;
unsigned int renditionSpec;
unsigned int option_def_index;
MALLOCARRAY_NOFAIL(option_def, 100);
option_def_index = 0; /* incremented by OPTENTRY */
OPTENT3(0, "verbose", OPT_FLAG, NULL,
>verbose, 0);
OPTENT3(0, "showhist",OPT_FLAG, NULL,
>showhist, 0);
OPTENT3(0, "transparent",OPT_FLAG, NULL,
>transparent, 0);
OPTENT3(0, "rendition", OPT_UINT, >rendition,
, 0);
opt.opt_table = option_def;
opt.short_allowed = FALSE; /* We have no short (old-fashioned) options */
opt.allowNegNum = FALSE; /* We may have parms that are negative numbers */
pm_optParseOptions3(, (char **)argv, opt, sizeof(opt), 0);
/* Uses and sets argc, argv, and some of *cmdlineP and others. */
if (renditionSpec) {
if (cmdlineP->rendition < 1)
pm_error("The -rendition value must be at least 1");
} else
cmdlineP->rendition = 1;
if (cmdlineP->transparent && cmdlineP->showhist)
pm_error("You can't specify -showhist with -transparent");
if (argc-1 < 1)
cmdlineP->inputFilespec = "-";
else {
cmdlineP->inputFilespec = argv[1];
if (argc-1 > 1)
pm_error("Too many arguments (%d). The only non-option "
"argument is the file name", argc-1);
Bug#1007234: Test suite fails on all but amd64 arches
I haven't heard of this before. I'm sure this is easy to diagnose for someone who can reproduce it. I can't, since I don't have access to a system other than AMD64. I can tell from reading the code that what is happening is there is a a negative number somewhere that there shouldn't be. My best guess is that the 2's complement arithmetic hack for interpreting the run-length-encoding in the function 'readPackBitsRow16' in converter/other/pnmtopalm/palmtopnm.c isn't doing what it's expected to do. In particular, the line int const signedIncount = (signed char)incountByte might be declaring a positive number, whereas it's supposed to be negative (which means -signedIncount below is negative whereas it is expected to be positive). -- Bryan Henderson San Jose, California
Bug#874427: /usr/bin/pg_config in multiple packages
>that's not a bug, the /usr/bin/pg_config from libpq-dev is moved aside >by postgresql-common's preinst script via dpkg-divert: Thanks; I figured I was missing something like that. >Does "apt-get install --reinstall postgresql-common" fix things? apt-get install --reinstall refuses to run because of the broken dependency (which I can't fix until I get this fixed), so I just did the 'dpkg --install' manually and that fixed it. If you want a post mortem: Before I started, there is no diversion: root@rhino:/tmp# dpkg --search /usr/bin/pg_config postgresql-common, libpq-dev: /usr/bin/pg_config The first reinstallation says it's ignoring the request to rename: root@rhino:/tmp# dpkg --install postgresql-common_165+deb8u2_all.deb (Reading database ... 86016 files and directories currently installed.) Preparing to unpack postgresql-common_165+deb8u2_all.deb ... Adding 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by post\ gresql-common' Ignoring request to rename file '/usr/bin/pg_config' owned by diverting package\ 'postgresql-common' Unpacking postgresql-common (165+deb8u2) over (165+deb8u2) ... Setting up postgresql-common (165+deb8u2) ... Processing triggers for systemd (215-17+deb8u7) ... Processing triggers for man-db (2.7.0.2-5) ... And it did: root@rhino:/tmp# ls /usr/bin/pg_config* /usr/bin/pg_config A second reinstallation is different: root@rhino:/tmp# dpkg --install postgresql-common_165+deb8u2_all.deb (Reading database ... 86017 files and directories currently installed.) Preparing to unpack postgresql-common_165+deb8u2_all.deb ... Leaving 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by pos\ tgresql-common' Unpacking postgresql-common (165+deb8u2) over (165+deb8u2) ... Setting up postgresql-common (165+deb8u2) ... Processing triggers for systemd (215-17+deb8u7) ... Processing triggers for man-db (2.7.0.2-5) ... And now it's fixed: root@rhino:/tmp# dpkg --search /usr/bin/pg_config diversion by postgresql-common from: /usr/bin/pg_config diversion by postgresql-common to: /usr/bin/pg_config.libpq-dev postgresql-common, libpq-dev: /usr/bin/pg_config root@rhino:/tmp# ls /usr/bin/pg_config* /usr/bin/pg_config /usr/bin/pg_config.libpq-dev The only thing I can think of that I did out of the ordinary to cause this is that I don't normally update my system by installing all the new packages at once; I install them a few at a time to limit the damage if something breaks. So I may have updated Postgres packages in a different order than is usual. Anyway, I'm glad to know how this diversion works so if this happens again, I can repair it. -- Bryan Henderson San Jose, California
Bug#874427: /usr/bin/pg_config in multiple packages
Package: postgresql-common Version: 165+deb8u2 Both postgresql-common and libpq-dev install the file /usr/bin/pg_config . That's a bug, isn't it? dpkg --install seems to think so. This was not a problem for me before an attempted update a few days ago; Now I have broken dependencies that I cannot fix because I cannot install the current libpq-dev because of the file conflict. I don't know what changed. -- Bryan Henderson San Jose, California
Bug#852999: ceph: /etc/init.d/ceph reload doesn't work - unescaped backtick
Package: ceph Version: 0.80.7-1~bpo70+1 Severity: normal There are unescaped backticks in /etc/init.d/ceph in function signal_daemon where it does a `cat $pidfile`. This makes reload not work on a remote server because the 'cat' gets done on the local system. It also generates a superfluous "file not found" error message when the server is not running. Because a logrotate cron job does a reload every day, this error message causes cron to generate a daily email to the system administrator. Other instances of "cat $pidfile" in the program have it right. -- System Information: Debian Release: 7.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages ceph depends on: ii binutils 2.22-8+deb7u3 ii ceph-common0.80.7-1~bpo70+1 ii cryptsetup-bin 2:1.4.3-4 ii gdisk 0.8.5-1 ii hdparm 9.39-1+b1 ii libaio10.3.109-3 ii libboost-thread1.49.0 1.49.0-3.2 ii libc6 2.13-38+deb7u11 ii libgcc11:4.7.2-5 ii libgoogle-perftools4 2.0-2 ii libleveldb10+20120530.gitdd0d562-1 ii libnspr4 2:4.12-1+deb7u1 ii libnss32:3.26-1+debu7u2 ii libstdc++6 4.7.2-5 ii libuuid1 2.20.1-5.3 ii multiarch-support 2.13-38+deb7u11 ii parted 2.3-12 ii python 2.7.3-4+deb7u1 ii uuid-runtime 2.20.1-5.3 ii xfsprogs 3.1.7+b1 Versions of packages ceph recommends: ii chrony [time-daemon] 1.24-3.1+deb7u4 ii libcephfs10.80.7-1~bpo70+1 ii librados2 0.80.7-1~bpo70+1 ii librbd1 0.80.7-1~bpo70+1 Versions of packages ceph suggests: ii logrotate 3.8.1-4 -- Configuration Files: /etc/init.d/ceph changed [not included] -- no debconf information
Bug#614423: Upstream now has pkgconfig files
The current Development release of Xmlrpc-c now (starting today) builds and installs pkg-config files. I tried emailing Stéphane Aulery saul...@free.fr about this on November 23, but mx1.free.fr reject my email: host mx1.free.fr [212.27.48.7]: 550 spam detected -- Bryan Henderson San Jose, California -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
