Bug#861865: libtiff5: regression - new warning: Invalid tag "Predictor"
Package: libtiff5 Version: 4.0.3-12.3+deb8u3 Severity: normal Dear Maintainer, As of today, we are getting this warning: Invalid tag "Predictor" (not supported by codec). (_TIFFVGetField) * What led up to the situation? The upgrade of libtiff5:amd from libtiff5:4.0.3-12.3+deb8u2 to 4.0.3-12.3+deb8u3 has caused a new warning to be emitted when creating TIFF files. We know it was this specific package because: * our test server logs from yesterday do not include the warning * a dist-upgrade this morning upgraded only one package: libtiff5 * our test server logs today now include the warning * the test server is running the same jobs as yesterday * we can reproduce the warning with test commands on other servers which have been updated but not when using the same commands on servers which are still running 4.0.3-12.3+deb8u2 The following two commands create a JPG file (a rectangle of solid color) and then convert the JPG to a TIFF. The warning is produced by the second command: $ gm convert -size 100x100 xc:#00 rect.jpg $ gm convert -colorspace RGB rect.jpg rect.tif gm convert: rect.tif: Invalid tag "Predictor" (not supported by codec). (_TIFFVGetField). Both of these commands use the GraphicsMagick 'gm' command but that command is using libtiff. Regards Grant McLean -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_NZ.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libtiff5 depends on: ii libc6 2.19-18+deb8u7 ii libjbig0 2.1-3.1 ii libjpeg62-turbo1:1.3.1-12 ii liblzma5 5.1.1alpha+20120614-2+b3 ii multiarch-support 2.19-18+deb8u7 ii zlib1g 1:1.2.8.dfsg-2+b1 libtiff5 recommends no packages. libtiff5 suggests no packages. -- no debconf information
Bug#812932: udev postinst blocking upgrades in LXC container
On Thu, 2016-01-28 at 02:10 +0100, Michael Biebl wrote: > Am 28.01.2016 um 02:02 schrieb Grant McLean: > > Possibly, but there's no point calling update-rc.d (which calls > > insserv?) on a system where udev is disabled. The udev.postinst script > > already omits some things when udev is disabled. I'm suggesting that it > > could omit calling update-rc.d too. > > Well, there is. You might want to debootstrap a system and later deploy > the image to systems where udev actually needs to run. > How exactly did you "disable udev"? Prior to this problem occurring, we ran a systemctl command to mask out the udev service. The command created symlinks to /dev/null from: /etc/systemd/system/udev.service /etc/systemd/system/systemd-udevd.service After looking through the udev.postinst script we learned that the script considers that udev is 'disabled' on the host if this file exists: /etc/udev/disabled This was the reason for my original suggested addition to the postinst script: [ -e /etc/udev/disabled ] && exit 0 I'm not sure if that file has any significance outside of the udev.postinst script. > If you run "insserv udev", what's the output? # insserv udev insserv: Service mountkernfs has to be enabled to start service udev insserv: exiting now! Which seems reasonable - the udev init script does declare a dependency on mountkernfs and the mountkernfs service is also masked in the container since that function is handled by the LXC startup. Regards Grant
Bug#812932: udev postinst blocking upgrades in LXC container
On Thu, 2016-01-28 at 01:45 +0100, Michael Biebl wrote: > Am 28.01.2016 um 01:33 schrieb Grant McLean: > > On Thu, 2016-01-28 at 00:30 +0100, Michael Biebl wrote: > >> Can you post the output of > >> insserv -s > > > > This is the output from insserv in a container where we experience the > > problem: > > > > # insserv -s > .. > > S:01:S:mountkernfs.sh > > .. > > > + update-rc.d udev defaults > > insserv: Service mountkernfs has to be enabled to start service udev > > insserv: exiting now! > > update-rc.d: error: insserv rejected the script header > > + exit 1 > > This looks like a problem in insserv, not udev. Possibly, but there's no point calling update-rc.d (which calls insserv?) on a system where udev is disabled. The udev.postinst script already omits some things when udev is disabled. I'm suggesting that it could omit calling update-rc.d too. > What is the insserv version you have installed? # apt-cache policy insserv insserv: Installed: 1.14.0-5 Candidate: 1.14.0-5 Version table: *** 1.14.0-5 0 500 http://debian.catalyst.net.nz/debian/ jessie/main amd64 Packages 100 /var/lib/dpkg/status Regards Grant
Bug#812932: udev postinst blocking upgrades in LXC container
Package: udev Version: 215-17+deb8u3 Severity: normal Dear Maintainer, We have a number of LXC containers running Jessie and systemd which are hosted on a physical server which is also running Jessie. A recent new release of systemd and udev packages resulted in the dist-upgrade failing in all the containers with this message: Setting up udev (215-17+deb8u3) ... udev does not support containers, not started. insserv: Service mountkernfs has to be enabled to start service udev insserv: exiting now! update-rc.d: error: insserv rejected the script header dpkg: error processing package udev (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: udev E: Sub-process /usr/bin/dpkg returned an error code (1) We understand that udev does not work inside a container. The package is only installed because it's a dependency of the systemd package. We work around this by blacklisting udev.service so that systemd does not attempt to start it during container startup. During our container build process, the systemd and udev packages do install successfully but this is due to the fact that the rootfs is built by debootstrap in a chroot and the udev.postinst script emits a warning and skips udev startup when run in a chroot. The problem occurs later when we run dist-upgrade in a container and a new version of the udev.postinst is run. Our workaround had two parts: we caused the udev startup to be skipped by setting a flag to indicate udev is disabled and then we edited the udev init script (which wouldn't be run anyway) to remove the dependency on the mountkernfs service: touch /etc/udev/disabled && \ perl -i -p -e 's/^(# Required-Start:).+$/$1/' /etc/init.d/udevs && \ apt-get dist-upgrade The fatal error seems to be occurring in the call to update-rc.d. I think the right approach is to skip this update if udev is disabled (the postinst already contains a check for the flag file /etc/udev/disabled). Unfortunately that is made more complicated by the fact that the call to update-rc.d is automatically added by dh_installinit. Perhaps the simplest situation is to bail out of the postinst script if udev is disabled: [ -e /etc/udev/disabled ] && exit 0 Regards Grant -- Package-specific info: -- System Information: Debian Release: 8.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages udev depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii libacl12.2.52-2 ii libblkid1 2.25.2-6 ii libc6 2.19-18+deb8u2 ii libkmod2 18-3 ii libselinux12.3-2 ii libudev1 215-17+deb8u3 ii lsb-base 4.1+Debian13+nmu1 ii procps 2:3.3.9-9 ii util-linux 2.25.2-6 udev recommends no packages. udev suggests no packages. -- debconf information: udev/reboot_needed: udev/title/upgrade: udev/new_kernel_needed: false udev/sysfs_deprecated_incompatibility: P: /devices/LNXSYSTM:00 E: DEVPATH=/devices/LNXSYSTM:00 E: MODALIAS=acpi:LNXSYSTM: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/ICV0A12:00 E: DEVPATH=/devices/LNXSYSTM:00/ICV0A12:00 E: ID_VENDOR_FROM_DATABASE=Inside Contactless E: MODALIAS=acpi:ICV0A12: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=74999 P: /devices/LNXSYSTM:00/LNXCPU:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:02 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:03 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:04 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:04 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:05 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:05 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:06 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:06 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:07 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:07 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXPWRBN:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00 E: DRIVER=button E: MODALIAS=acpi:LNXPWRBN: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: KEY=10 0 E:
Bug#812932: udev postinst blocking upgrades in LXC container
On Thu, 2016-01-28 at 00:30 +0100, Michael Biebl wrote: > Can you post the output of > insserv -s This is the output from insserv in a container where we experience the problem: # insserv -s K:01:0 6:urandom K:06:0 6:umountfs K:04:0 6:hwclock.sh K:01:0 1 6:apache2-be K:05:0 6:networking K:03:0 1 6:rsyslog K:01:0 1 6:puppet K:04:0 6:umountnfs.sh K:02:0 6:sendsigs K:01:0 1 6:scheduler K:01:0 1 6:nagios-nrpe-server K:08:0:halt K:01:0 1 6:atd K:01:0 1 6:exim4 K:08:6:reboot K:07:0 6:umountroot S:02:S:udev S:10:S:urandom S:08:S:mountall.sh S:09:S:mountall-bootclean.sh S:04:S:hwclock.sh S:02:2 3 4 5:apache2-be S:11:S:networking S:01:2 3 4 5:rsyslog S:01:S:mountkernfs.sh S:03:2 3 4 5:puppet S:12:S:mountnfs.sh S:13:S:mountnfs-bootclean.sh S:02:2 3 4 5:scheduler S:03:S:mountdevsubfs.sh S:05:S:checkroot.sh S:02:2 3 4 5:nagios-nrpe-server S:02:2 3 4 5:atd S:02:2 3 4 5:exim4 S:01:1:killprocs S:01:1 2 3 4 5:motd S:01:S:hostname.sh S:01:1 2 3 4 5:bootlogs S:02:1:single S:02:2 3 4 5:dbus S:04:2 3 4 5:rmnologin S:04:2 3 4 5:rc.local S:02:2 3 4 5:loadcpufreq S:03:2 3 4 5:cpufrequtils S:02:2 3 4 5:rsync S:02:2 3 4 5:ssh S:02:2 3 4 5:cron S:14:S:bootmisc.sh S:07:S:checkroot-bootclean.sh S:06:S:checkfs.sh S:10:S:udev-finish S:14:S:x11-common S:10:S:procps S:01:2 3 4 5:sudo Also I added set -x to udev.postinst and got this output: # /var/lib/dpkg/info/udev.postinst configure && echo 'success!' + update_hwdb + udevadm hwdb --update --usr + addgroup --quiet --system input + [ -z ] + chrooted + stat -c %d/%i / + stat -Lc %d/%i /proc/1/root + [ 64769/5767832 = 64769/5767832 ] + return 1 + in_debootstrap + [ -d /debootstrap/ ] + return 1 + write_interfaces_rules + local devpath + [ -d /sys/class/net/eth0 ] + udevadm test --action=add /sys/class/net/eth0 calling: test version 215 load module index Network interface NamePolicy= disabled on kernel commandline, ignoring. timestamp of '/etc/systemd/network' changed timestamp of '/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Created link configuration context. timestamp of '/etc/udev/rules.d' changed timestamp of '/lib/udev/rules.d' changed read rules file: /lib/udev/rules.d/42-usb-hid-pm.rules read rules file: /lib/udev/rules.d/50-firmware.rules read rules file: /lib/udev/rules.d/50-udev-default.rules read rules file: /lib/udev/rules.d/55-dm.rules read rules file: /lib/udev/rules.d/60-cdrom_id.rules read rules file: /lib/udev/rules.d/60-drm.rules read rules file: /lib/udev/rules.d/60-gnupg.rules read rules file: /lib/udev/rules.d/60-keyboard.rules read rules file: /lib/udev/rules.d/60-persistent-alsa.rules read rules file: /lib/udev/rules.d/60-persistent-input.rules read rules file: /lib/udev/rules.d/60-persistent-serial.rules read rules file: /lib/udev/rules.d/60-persistent-storage-dm.rules read rules file: /lib/udev/rules.d/60-persistent-storage-tape.rules read rules file: /lib/udev/rules.d/60-persistent-storage.rules read rules file: /lib/udev/rules.d/60-persistent-v4l.rules read rules file: /lib/udev/rules.d/61-accelerometer.rules read rules file: /lib/udev/rules.d/64-btrfs.rules read rules file: /lib/udev/rules.d/70-power-switch.rules read rules file: /lib/udev/rules.d/70-uaccess.rules read rules file: /lib/udev/rules.d/71-seat.rules read rules file: /lib/udev/rules.d/73-idrac.rules read rules file: /lib/udev/rules.d/73-seat-late.rules read rules file: /lib/udev/rules.d/75-net-description.rules read rules file: /lib/udev/rules.d/75-persistent-net-generator.rules read rules file: /lib/udev/rules.d/75-probe_mtd.rules read rules file: /lib/udev/rules.d/75-tty-description.rules read rules file: /lib/udev/rules.d/78-sound-card.rules read rules file: /lib/udev/rules.d/80-drivers.rules read rules file: /lib/udev/rules.d/80-net-setup-link.rules read rules file: /lib/udev/rules.d/80-networking.rules read rules file: /lib/udev/rules.d/85-hwclock.rules read rules file: /lib/udev/rules.d/95-udev-late.rules read rules file: /lib/udev/rules.d/99-systemd.rules rules contain 24576 bytes tokens (2048 * 12 bytes), 11225 bytes strings 1828 strings (21697 bytes), 1199 de-duplicated (11102 bytes), 630 trie nodes used IMPORT builtin 'net_id' /lib/udev/rules.d/75-net-description.rules:6 IMPORT builtin 'path_id' /lib/udev/rules.d/80-net-setup-link.rules:5 IMPORT builtin 'path_id' returned non-zero IMPORT builtin 'net_setup_link' /lib/udev/rules.d/80-net-setup-link.rules:11 Config file /lib/systemd/network/99-default.link applies to device eth0 RUN 'net.agent' /lib/udev/rules.d/80-networking.rules:1 RUN '/lib/systemd/systemd-sysctl --prefix=/proc/sys/net/ipv4/conf/$name --prefix=/proc/sys/net/ipv4/neigh/$name --prefix=/proc/sys/net/ipv6/conf/$name --prefix=/proc/sys/net/ipv6/neigh/$name' /lib/udev/rules.d/99-systemd.rules:61 unload module index Unloaded link configuration context. + [ -d /sys/class/net/lo ] + udevadm test --action=add /sys/class/net/lo calling: test version 215 load module index Network interface NamePolicy= disabled on kernel
Bug#595920: lxc-attach does not work
It looks like someone has got the kernel patches working with 3.2 (and later in the thread, 3.3). http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg03397.html It really would be good to get lxc-attach working on a stock kernel. Regards Grant -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621836: exim4: Could not perform immediate configuration
I have this same error. I have a server with ssmtp installed and I wish to replace it with exim. So I tried this command: # apt-get --purge install exim4-daemon-light ssmtp- Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: exim4-base Suggested packages: eximon4 exim4-doc-html exim4-doc-info spf-tools-perl swaks The following packages will be REMOVED: ssmtp* The following NEW packages will be installed: exim4-base exim4-config exim4-daemon-light 0 upgraded, 3 newly installed, 1 to remove and 0 not upgraded. Need to get 0 B/2,079 kB of archives. After this operation, 4,166 kB of additional disk space will be used. Do you want to continue [Y/n]? y E: Could not perform immediate configuration on 'exim4-daemon-light'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) # Adding the -o APT::Immediate-Configure=0 gives the same result. Also the same result with the simpler: apt-get -o APT::Immediate-Configure=0 install exim4 No doubt I could work around this by purging ssmtp first but that will result in the removal of a bunch of packages that depend on an MTA and I'd prefer not to do that. Are there any commands you'd like me to try in order to help debug this situation? Regards Grant -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630042: probably about 25% of all G4 images are not decodable
am I the only person doing G4 compression with debian squeeze? We are also finding some TIFF images unreadable on squeeze - hence my earlier reply in support of your bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630042 The errors we're seeing are when we attempt to read image files that came from a scanner which produces G4 encoded TIFF files (it's a network scanner that uploads TIFF files over FTP). This tends to suggest the problem is with the decoding rather than the encoding. The result is that our client's image processing application is no longer usable on squeeze. Regards Grant -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630042: probably about 25% of all G4 images are not decodable
On Sun, 2011-06-19 at 20:45 -0400, Jay Berkenbilt wrote: Do you know whether the problem occurred after the most recent security update? There was a security fix to some of the code that affects G4. I'm almost certain the problem is related to the security release. We have automated regression testing which was working up until June 10th. On June 11th our logs show a dist-upgrade updated libtiff4 to libtiff4_3.9.4-5+squeeze2_amd64.deb and the tests have been failing ever since. Regards Grant -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630042: Fax4Decode 'Bad code word'
We are seeing a problem which I suspect is a manifestation of the same bug. I have an image called 'scan.tif' which appears perfectly normal when viewed in eog or Gimp. When I try to convert it to PNG with graphicsmagick I get the following error: $ gm convert scan.tif scan.png gm convert: scan.tif: Bad code word at line 63 of strip 19 (x 1535). (Fax4Decode). The conversion command and the source TIFF are part of our application's automated regression test suite. This error appeared following the update of libtiff4 to 3.9.4-5+squeeze2 The source TIFF file was sent to us electronically from a document scanning bureau some years ago. I can supply the image directly to a developer if it would help but would prefer not to attach to a public bug report due to confidential nature of the document in the scan. ImageMagick also now complains about this file: $ identify -verbose scan.tif Image: scan.tif Format: TIFF (Tagged Image File Format) Class: DirectClass Geometry: 1536x2370+0+0 Resolution: 200x200 Print size: 7.68x11.85 Units: PixelsPerInch Type: Bilevel Base type: Bilevel Endianess: MSB Colorspace: RGB Depth: 1-bit Channel depth: gray: 1-bit Channel statistics: Gray: min: 0 (0) max: 1 (1) mean: 0.91813 (0.91813) standard deviation: 0.274167 (0.274167) kurtosis: 7.30366 skewness: -3.05019 Histogram: 298033: ( 0, 0, 0) #00 black 3342287: (255,255,255) #FF white Rendering intent: Undefined Interlace: None Background color: white Border color: rgb(223,223,223) Matte color: grey74 Transparent color: black Compose: Over Page geometry: 1536x2370+0+0 Dispose: Undefined Iterations: 0 Compression: Group4 Orientation: TopLeft Properties: date:create: 2011-06-14T13:41:21+12:00 date:modify: 2011-06-14T13:41:21+12:00 signature: ba226183d39e5667578648d34a557bc7f5f65cb5623652aadc5df338c6627035 tiff:document: /home/grant/eec/00020876.TIFF tiff:photometric: min-is-white tiff:rows-per-strip: 64 Artifacts: verbose: true Tainted: False Filesize: 49.3KB Number pixels: 3.64MB Pixels per second: 40.45MB User time: 0.060u Elapsed time: 0:01.089 Version: ImageMagick 6.6.0-4 2010-11-16 Q16 http://www.imagemagick.org identify: scan.tif: Bad code word at line 4 of strip 19 (x 0). `Fax4Decode' @ warning/tiff.c/TIFFErrors/493. identify: scan.tif: Premature EOL at line 4 of strip 19 (got 0, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Bad code word at line 7 of strip 19 (x 12). `Fax4Decode' @ warning/tiff.c/TIFFErrors/493. identify: scan.tif: Premature EOL at line 7 of strip 19 (got 12, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 10 of strip 19 (got 1564, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 18 of strip 19 (got 1540, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 24 of strip 19 (got 1537, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 28 of strip 19 (got 1537, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 29 of strip 19 (got 1552, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 30 of strip 19 (got 1574, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 31 of strip 19 (got 1537, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Bad code word at line 32 of strip 19 (x 33). `Fax4Decode' @ warning/tiff.c/TIFFErrors/493. identify: scan.tif: Premature EOL at line 32 of strip 19 (got 33, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 33 of strip 19 (got 1538, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Bad code word at line 50 of strip 19 (x 1535). `Fax4Decode' @ warning/tiff.c/TIFFErrors/493. identify: scan.tif: Premature EOL at line 50 of strip 19 (got 1535, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 52 of strip 19 (got 1542, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Line length mismatch at line 59 of strip 19 (got 1537, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. identify: scan.tif: Bad code word at line 63 of strip 19 (x 1535). `Fax4Decode' @ warning/tiff.c/TIFFErrors/493. identify: scan.tif: Premature EOL at line 63 of strip 19 (got 1535, expected 1536). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703. Regards Grant -- To UNSUBSCRIBE, email to
Bug#592305: puppet: Duplicate definition error when - used in class names
Package: puppet
Version: 2.6.0-2
Severity: important
This problem has been fixed upstream in this commit:
http://github.com/MarkusQ/puppet/commit/9569136329f87ee
The bug was apparently inadvertently introduced in a last minute fix.
In previous versions of Puppet, it was allowable to use a dash ('-') in
class names. This functionality broke in the 2.6 release and unfortunately
results in the very misleading Duplicate definition error.
It is possible to work around the problem by changing existing class names
to not include dashes but this could be a huge job for many Puppet users
(such as myself) and it's literally a 1 character change to correct the
problem.
Regards
Grant
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-vserver-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_NZ.UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages puppet depends on:
ii adduser 3.112 add and remove users and groups
ii facter 1.5.7-1 a library for retrieving facts fro
pn libopenssl-ruby none (no description available)
ii libruby [libxmlrpc-ruby] 4.5 Libraries necessary to run Ruby 1.
ii libshadow-ruby1.81.4.1-8 Interface of shadow password for R
ii libxmlrpc-ruby 4.2 transitional dummy package
ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip
ii puppet-common2.6.0-2 Centralized configuration manageme
ii ruby1.8 1.8.7.299-1 Interpreter of object-oriented scr
Versions of packages puppet recommends:
ii libaugeas-ruby1.8 0.3.0-1.1 Augeas bindings for the Ruby langu
ii rdoc 4.4Generate documentation from ruby s
Versions of packages puppet suggests:
pn libselinux-ruby1.8none (no description available)
pn puppet-el none (no description available)
pn vim-puppetnone (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552998: graphicsmagick: Multi-page PDF to TIFFs produces empty files
Package: graphicsmagick Version: 1.3.5-5.2 Severity: normal Given a multi-page PDF, I am using this command to produce a set of TIFF images (1 per page): gm convert -units PixelsPerInch -density 300 -depth 1 -compress Group4 \ test.pdf tif:test.%02d.tif I expect the following output: -rw-r--r-- 1 grant grant 12030 Oct 29 15:24 test.00.tif -rw-r--r-- 1 grant grant 35666 Oct 29 15:24 test.01.tif -rw-r--r-- 1 grant grant 21588 Oct 29 15:24 test.02.tif -rw-r--r-- 1 grant grant 63522 Oct 29 15:24 test.03.tif Instead I get this: -rw-r--r-- 1 grant grant 0 Oct 29 15:24 test.00.tif -rw-r--r-- 1 grant grant 12030 Oct 29 15:24 test.00.tif.0 -rw-r--r-- 1 grant grant 0 Oct 29 15:24 test.01.tif -rw-r--r-- 1 grant grant 35666 Oct 29 15:24 test.01.tif.1 -rw-r--r-- 1 grant grant 0 Oct 29 15:24 test.02.tif -rw-r--r-- 1 grant grant 21588 Oct 29 15:24 test.02.tif.2 -rw-r--r-- 1 grant grant 0 Oct 29 15:24 test.03.tif -rw-r--r-- 1 grant grant 63522 Oct 29 15:24 test.03.tif.3 It seems that the contents of test.00.tif.0 are valid and what I expect to be in test.00.tif (which is there but empty). The conversion works fine on lenny. Thanks Grant -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.28-16-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages graphicsmagick depends on: ii libbz2-1.0 1.0.5-3 high-quality block-sorting file co ii libc6 2.10.1-2 GNU C Library: Shared libraries ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib ii libgomp1 4.4.2-1 GCC OpenMP (GOMP) support library ii libgraphicsmagick3 1.3.5-5.2 format-independent image processin ii libice62:1.0.5-1 X11 Inter-Client Exchange library ii libjasper1 1.900.1-6 The JasPer JPEG-2000 runtime libra ii libjpeg62 6b-15 The Independent JPEG Group's JPEG ii liblcms1 1.18.dfsg-1 Color management library ii libpng12-0 1.2.40-1 PNG library - runtime ii libsm6 2:1.1.1-1 X11 Session Management library ii libtiff4 3.9.1-1 Tag Image File Format (TIFF) libra ii libwmf0.2-70.2.8.4-6.1 Windows metafile conversion librar ii libx11-6 2:1.2.2-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxml22.7.6.dfsg-1 GNOME XML library ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime graphicsmagick recommends no packages. Versions of packages graphicsmagick suggests: pn graphicsmagick-dbgnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546663: ooo-thumbnailer: Does not thumbnail OOo drawing or presentation files
Package: ooo-thumbnailer Version: 0.1~alpha2-1 Severity: normal Tags: patch The default configuration for this package will only cause thumbnails to be created for Word Processor (.odt) documents. The attached patch enables thumbnailing for Drawing (.odg) and Presentation (.odp) files as well. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.28-15-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages ooo-thumbnailer depends on: ii gconf2 2.26.2-3GNOME configuration database syste ii imagemagick 7:6.5.5.3-1 image manipulation programs ii totem-gstreamer 2.26.3-1A simple media player for the GNOM ii unzip6.0-1 De-archiver for .zip files ooo-thumbnailer recommends no packages. ooo-thumbnailer suggests no packages. -- no debconf information --- ooo-thumbnailer.schemas-orig2009-09-14 15:17:58.0 +1200 +++ ooo-thumbnailer.schemas 2009-09-15 09:20:47.0 +1200 @@ -22,5 +22,49 @@ long/ /locale /schema + schema + key/schemas/desktop/gnome/thumbnailers/applicat...@vnd.oasis.opendocument.graphics/enable/key + applyto/desktop/gnome/thumbnailers/applicat...@vnd.oasis.opendocument.graphics/enable/applyto + ownerooo-thumbnailer/owner + typebool/type + defaulttrue/default + locale name=C + short/ + long/ + /locale + /schema + schema + key/schemas/desktop/gnome/thumbnailers/applicat...@vnd.oasis.opendocument.graphics/command/key + applyto/desktop/gnome/thumbnailers/applicat...@vnd.oasis.opendocument.graphics/command/applyto + ownerooo-thumbnailer/owner + typestring/type + default/usr/bin/ooo-thumbnailer %i %o %s/default + locale name=C + short/ + long/ + /locale + /schema + schema + key/schemas/desktop/gnome/thumbnailers/applicat...@vnd.oasis.opendocument.presentation/enable/key + applyto/desktop/gnome/thumbnailers/applicat...@vnd.oasis.opendocument.presentation/enable/applyto + ownerooo-thumbnailer/owner + typebool/type + defaulttrue/default + locale name=C + short/ + long/ + /locale + /schema + schema + key/schemas/desktop/gnome/thumbnailers/applicat...@vnd.oasis.opendocument.presentation/command/key + applyto/desktop/gnome/thumbnailers/applicat...@vnd.oasis.opendocument.presentation/command/applyto + ownerooo-thumbnailer/owner + typestring/type + default/usr/bin/ooo-thumbnailer %i %o %s/default + locale name=C + short/ + long/ + /locale + /schema /schemalist /gconfschemafile
Bug#442120: sshmenu crashing
This may be a problem with version 0.15 of the Ruby GTK bindings ... http://sourceforge.net/mailarchive/forum.php?thread_name=9f8261a9e26872ac858c63e1607c1bd5%40ruby-forum.comforum_name=ruby-gnome2-devel-en I'm running 0.14 in my (Ubuntu Dapper) development environment. I have also tested on Debian unstable (sid) where 0.16.0-7 is the current release of libgtk2-ruby. Regards Grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441466: sshmenu: Missing dependency on libpanel-applet2-ruby
Package: sshmenu Version: 3.13-1 Severity: grave Justification: renders package unusable The sshmenu package includes the relevant files for running the program as a GNOME panel applet, but the libpanel-applet2-ruby package is not listed in the dependencies therefore the applet won't actually work. Both the generic standalone sshmenu and the GNOME-specific sshmenu-gome standalone apps do run. The preferred solution would be to move the gnome-specific files into their own package (e.g.: sshmenu-gnome) and add the libpanel-applet2-ruby package as a dependency to that package. This would allow non-GNOME users to install 'sshmenu' without pulling in GNOME dependencies. Further information: Kevin I've sent you a couple of emails and not had a reply so I'm not sure if you're not receiving them or I'm not getting replies. The points I was making in the emails ... 1. The SSHMenu home page has moved from my personal web site to SourceForge: http://sshmenu.sourceforge.net/ 2. The files I used when creating my informal Debian/Ubuntu packages are here: http://sshmenu.svn.sourceforge.net/viewvc/sshmenu/modules/sshmenu/trunk/deb-files/ 3. Version 3.14 of SSHMenu was released last week 4. My suggested guidelines for packaging SSHMenu are here: http://sshmenu.sourceforge.net/download/install.html You are of course free to ignore them :-) Or better yet, let me know if you think they need revising. Thanks for picking up this package for Debian. Regards Grant -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.1-dirk (SMP w/1 CPU core; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages sshmenu depends on: ii libgtk2-ruby 0.16.0-7 GTK+ bindings for the Ruby languag ii libruby1.81.8.6.36-3 Libraries necessary to run Ruby 1. ii libyaml-ruby 1.8.2-1YAML for Ruby ii ruby 1.8.2-1An interpreter of object-oriented ii ruby1.8 1.8.6.36-3 Interpreter of object-oriented scr ii ssh-askpass-gnome [ssh-askpas 1:4.6p1-5 interactive X program to prompt us sshmenu recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419757: libxml-sax-perl: PI parsing bug fixed in upstream
Release 0.16 of XML::SAX has just been uploaded to CPAN. The only change from 0.15 is a fix for the broken handling of processing instructions. Cheers Grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355067: libgnome2-canvas-perl: Package needs to be recompiled against latest libgnomecanvas
Package: libgnome2-canvas-perl Version: 1.002-1 Severity: grave Justification: renders package unusable The libgnome2-canvas-perl package in Debian unstable was apparently built against version 2.10.0 of libgnomecanvas2, but that library has since been upgraded to 2.12.0. There is a minor API change in the library (requested by the Perl module author). The Perl wrapper code can work with either API but unfortunatelys the API version is detected at compile time. sThe result is that various canvas objects (eg: bezier path) simply don't work and the following messages are written to STDERR: GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0' failed GLib-GObject-CRITICAL **: g_param_spec_boxed: assertion `G_TYPE_IS_BOXED (boxed_type)' failed GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)' failed More details here: http://mail.gnome.org/archives/gtk-perl-list/2005-December/msg00012.html I have confirmed that no patch is required. Simply rebuilding the package resolves the problems. Regards Grant -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (101, 'unstable'), (99, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages libgnome2-canvas-perl depends on: ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libc6 2.3.6-2GNU C Library: Shared libraries an ii libglib-perl 1:1.105-1 Perl interface to the GLib and GOb ii libglib2.0-0 2.8.6-1The GLib library of C routines ii libgnomecanvas2-0 2.12.0-2 A powerful object-oriented display ii libgtk2-perl 1:1.104-1 Perl interface to the 2.x series o ii libgtk2.0-0 2.8.12-1 The GTK+ graphical user interface ii libpango1.0-0 1.10.4-1 Layout and rendering of internatio ii perl 5.8.8-2Larry Wall's Practical Extraction ii perl-base [perlapi-5.8.4] 5.8.8-2The Pathologically Eclectic Rubbis libgnome2-canvas-perl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298975: Regex problems remain for apache in sarge/amd64
Hi maintainers The latest version of apache for amd64 in Sarge seems to be 1.3.33-6 which does not include the fixes to the regex code. I find that simple regexes like this are failing: RedirectMatch ^/app/(.*) http://newserver/$1 This seems to me to be a fairly grave flaw in the stable version. Am I missing some obvious solution? Regards Grant McLean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333427: libxml-simple-perl: XML::Simple::FAQ.pod can't be found by perldoc
Package: libxml-simple-perl Version: 2.14-1 Severity: normal As the author of the XML::Simple module, I get a lot of email enquiries from users. Many of these queries can be addressed by suggesting the user type the command: perldoc XML::Simple::FAQ Unfortunately, this does not work with the packaged version of XML::Simple on Debian because the file has been installed as: /usr/share/doc/libxml-simple-perl/FAQ.pod.gz rather than: /usr/share/perl5/XML/Simple/FAQ.pod of the 133 CPAN modules I have installed from the Debian repositories on my Sarge system, not a single one (other than libxml-simple-perl) has POD files installed under /usr/share/doc. By the way, thanks for taking the time to package my module. Regards Grant McLean -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libxml-simple-perl depends on: ii libxml-libxml-perl1.58-0.3 Perl module for using the GNOME li ii libxml-namespacesupport-perl 1.09-1 Perl module for supporting simple ii libxml-sax-expat-perl 0.37-3 Perl module for a SAX2 driver for ii libxml-sax-perl 0.12-5 Perl module for using and building ii perl 5.8.7-3Larry Wall's Practical Extraction libxml-simple-perl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
