Bug#421868: cups-pdf: gs hangs eating all memory when printing certain files
Package: cups-pdf Version: 2.4.2-3 Severity: critical Tags: patch Justification: breaks the whole system Hi! When printing certain files via cups-pdf, gs runs forever using all cpu and slowly eating all memory. In consequence the system becomes unresponsive after a few seconds and therefore unusable. If you think this bug is not critical, please tell me, so I know better next time. A typical example in our environment would be a MS Excel user printing to the cups-pdf printer using dim borderlines. If you'd like an example .ps file I can provide one. Actually this seems to be a bug in gs-esp, but since I managed to fix it in cups-pdf, I file it against cups-pdf. I could fix it by adding -c .setpdfwrite in the config: GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=%s -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f %s I removed the -c save pop, since /usr/share/doc/gs-esp/Use.htm [Improving Performance] suggests that it is not needed. I don't really understand why this fix works and probably this has to be fixed in gs, too. But the default of gs should be changed anyway as far as I understand the -c .setpdfwrite option. I don't think it is the same bug as #267423 since for me gs never finishes. Kind Regards, Christopher Zimmermann -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20.5 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421586: libconfig-general-perl: Undefined subroutine
Package: libconfig-general-perl Version: 2.33-1 Severity: grave Justification: renders package unusable Hi! I hope reporting a grave bug is appropriate. Maybe I missed an important point. Anyway here is what I experienced when upgrading: [EMAIL PROTECTED]:~/downloads% sudo dpkg -i libconfig-general-perl_2.31-3_all.deb dpkg - warning: downgrading libconfig-general-perl from 2.33-1 to 2.31-3. (Reading database ... 104591 files and directories currently installed.) Preparing to replace libconfig-general-perl 2.33-1 (using libconfig-general-perl_2.31-3_all.deb) ... Unpacking replacement libconfig-general-perl ... Setting up libconfig-general-perl (2.31-3) ... [EMAIL PROTECTED]:~/downloads% perl -w -e 'use Config::General; my $conf = ParseConfig(/dev/null);' [EMAIL PROTECTED]:~/downloads% sudo dpkg -i libconfig-general-perl_2.33-1_all.deb (Reading database ... 104593 files and directories currently installed.) Preparing to replace libconfig-general-perl 2.31-3 (using libconfig-general-perl_2.33-1_all.deb) ... Unpacking replacement libconfig-general-perl ... Setting up libconfig-general-perl (2.33-1) ... [EMAIL PROTECTED]:~/downloads% perl -w -e 'use Config::General; my $conf = ParseConfig(/dev/null);' Undefined subroutine main::ParseConfig called at -e line 1. [EMAIL PROTECTED]:~/downloads% I can reproduce this with 2.32-1 or 2.33-1 on amd64 testing and i386 etch. Using the 'OOP way' described in `perldoc Config::General` the behavior is similar. As you can see I could easily work around this bug by downgrading. Kind Regards, Christopher Zimmermann -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20.5 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libconfig-general-perl depends on: ii perl 5.8.8-7Larry Wall's Practical Extraction libconfig-general-perl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370644: grub: workaround
Package: grub Version: 0.97-10 Followup-For: Bug #370644 Hi! This patch fixes the issue for instant. But there is still work to be done till this lockold feature does it's job right. What if the default entry is not the first one like with default = 2? line 935-936: # do not lockold for the first entry [ $counter -eq 1 ] do_lockold=false Should memtest be locked by lockold? BSD kernels lack the lockold feature at all. Here is the (paranoic) workaround enabling lockold for memtest and bsd even if they might be the default: --- update-grub 2006-06-07 11:52:19.0 +0200 +++ update-grub 2006-06-07 12:04:24.0 +0200 @@ -884,7 +884,7 @@ else kernel=/boot/loader fi -write_kernel_entry$grub_root_device $kerneltrue +write_kernel_entry$grub_root_device $kerneltrue $lockold ;; esac @@ -967,7 +967,7 @@ echo Found kernel: $kernel 2 write_kernel_entry $kernelVersion $grub_root_device \ - $kernel $currentOpt $initrd false + $kernel $currentOpt $initrd false $lockold fi done fi Hope this helps. Regards, Christopher -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16.20 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
