Bug#1068644: gnutls-bin: "Fatal error: The encryption algorithm is not supported" appeared with 3.8.5 upgrade

On 2024-04-08 18:30, Andreas Metzler wrote: >> It fails with "*** Fatal error: The encryption algorithm is not supported." > > Thank you and sorry. I have done a bisect and will try reverting the > offending upstream commit as a hotfix. Thank you for the quick fix. I've just updated the

Bug#1068644: gnutls-bin: "Fatal error: The encryption algorithm is not supported" appeared with 3.8.5 upgrade

Package: gnutls-bin Version: 3.8.5-1 Severity: normal X-Debbugs-Cc: none, Sanjoy Mahajan File: /usr/bin/gnutls-cli After dist-upgrading today, exim4 could no longer talk to my usual outgoing mail server. I reproduced the problem using just gnutls-cli. The problem started after today's upgrade

Bug#1058452: tex-common: "fmtutil failed" in post-installation script

[Sorry for the resend -- my mailer [emacs+notmuch] had mangled the To: header in the first attempt] On 2023-12-13 23:10, Norbert Preining wrote: > On Wed, 13 Dec 2023, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: >> Is it fine to close the case? > > Actually no, the packages should have

Bug#1058452: tex-common: "fmtutil failed" in post-installation script

On 2023-12-13 23:10, Norbert Preining wrote: > On Wed, 13 Dec 2023, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: >> Is it fine to close the case? > > Actually no, the packages should have proper dependencies that this > cannot happen. > > Hilmar, please bump the minimal dep on tl-base to

Bug#1058452: tex-common: "fmtutil failed" in post-installation script

On 2023-12-12 20:48, Norbert Preining wrote: > The log contains > > fmtutil [WARNING]: inifile pdfxmltex.ini for pdfxmltex/pdftex not found. > fmtutil [WARNING]: inifile xmltex.ini for xmltex/pdftex not found. > > These seem to be missing Right. Upgrading the texlive-base (2023.20231007-1 =>

Bug#1058452: tex-common: "fmtutil failed" in post-installation script

On 2023-12-12 19:40, Preuße, Hilmar wrote: > These files are in texlive-base > > hille@debian:~$ apt-file search xmltex.ini > texlive-base: > /usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdfxmltex.ini > texlive-base: >

Bug#1054398: bing: error "not enough hosts were found to perform the bandwidth analysis"

On 2023-10-27 09:07, Patrick Matthäi wrote: > What happens if you use bing 192.168.7.123 192.168.7.1 > > where .1 is your gw and .123 your own ipv4 in this subnet instead of > localhost It doesn't seem very happy. Here's a log. There are a bunch of errors or at least messages surrounding

Bug#1054398: bing: error "not enough hosts were found to perform the bandwidth analysis"

Package: bing Version: 1.3.5-5 Severity: grave X-Debbugs-Cc: none, Sanjoy Mahajan Bing has not worked for me for many versions. bing 1.1 works fine, but 1.3 in all versions that I've tried for years always fails. Here's the log from a typical example ("gw" is the router on the loc

Bug#884987: etckeeper: /etc/cron.daily/etckeeper reports "abort: path contains illegal component: .hg/undo.dirstate"

found 884987 1.18.18-1.1 found 884987 1.18.20-1 thanks I still regularly see this bug even after version 1.18.14-1. In Message #41 , I sent it in a full reportbug report for version 1.18.18-1.1 . I am now seeing it with version

Bug#884987: etckeeper: /etc/cron.daily/etckeeper reports "abort: path contains illegal component: .hg/undo.dirstate"

Package: etckeeper Version: 1.18.18-1.1 Severity: normal X-Debbugs-Cc: none, Sanjoy Mahajan This bug may be worth reopening. I have it with version 1.18.18-1.1 seeing exactly what was reported in Message #5 of the report <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884987#5> --

Bug#977147: texlive-base: "texdoc asymptote" pulls up an ancient version of the documentation

On 2020-12-12 09:05, Norbert Preining wrote: >> "texdoc asymptote" starts up a viewer with documentation for asymptote >> 1.79 and in (I think) Chinese. Meanwhile, I'm using asymptote 2.68. > Indeed, the asymptote doc is not linked into the texmf tree and thus not > found by texdoc. I faintly

Bug#977147: texlive-base: "texdoc asymptote" pulls up an ancient version of the documentation

Package: texlive-base Version: 2020.20200925-1 Severity: normal X-Debbugs-Cc: none, Sanjoy Mahajan File: /usr/bin/texdoc "texdoc asymptote" starts up a viewer with documentation for asymptote 1.79 and in (I think) Chinese. Meanwhile, I'm using asymptote 2.68. In case it's usef

Bug#948236: elpa-org: org-notmuch.el disappeared

> I will force merge this bug with #948027 momentarily, which will close > this bug. Ah, somehow I missed that report when I was checking whether this issue had been reported. But I'm glad that it's all fixed. (I had been afraid that the org-notmuch.el file had DFSG issues and am happy that it

Bug#948236: elpa-org: org-notmuch.el disappeared

Package: elpa-org Version: 9.3+dfsg-1 Severity: normal My .emacs used to load org-notmuch.el, via (load "org-notmuch") but that line stopped working. It seems that elpa-org 9.1.14 had the needed file, /usr/share/emacs/site-lisp/elpa-src/org-9.1.14/org-notmuch.el (see the list at

Bug#939581: firefox: problem seems to be solved with 69.0.2-1

I'm now using firefox 69.0.2-1 (amd64), and the problem seems to have solved itself (or maybe Mozilla noticed and fixed it?). That is, the print dialog now selects (by highlighting in blue) my CUPS default printer as its default printer. -Sanjoy

Bug#939581: firefox: default printer is now the first one in CUPS list (not the last one used)

Package: firefox Version: 69.0-1 Severity: normal Firefox no longer remembers the last printer used. Rather, the print dialog always offers the first one on the list as the default, even after printing to a different printer. On my system, for example, the CUPS default is lj400 and is the

Bug#919497: emacs-el: shell-mode history completion gets confused by bash syntax for fd redirection

Package: emacs-el Version: 1:26.1+1-3 Severity: normal File: /usr/share/emacs/26.1/lisp/shell.el.gz (I think that this is an Emacs bug, rather than a Debian packaging bug. I am using Emacs 26.1, amd64.) In shell-mode, the command history can get confused by bash's syntax for fd redirection, e.g.

Bug#867035: context: fatal file format error

On 2018-11-27 08:50, Hilmar Preuße wrote: > Currently all packages in Debian testing seem to be consistent. So I'd > assume that your issue is gone. Can we close that bug now? I retested it just now, just to be sure, and all is well. So, close away. -Sanjoy

Bug#912438: auctex: ConTeXt source no longer recognized automatically

Package: auctex Version: 11.91-1 Severity: normal Recently, ConTeXt files stopped being recognized as such automatically. To reproduce the problem, start a clean emacs and load the test file: % emacs -q -nw C-x C-f test.tex My test.tex is: \starttext \input knuth \stoptext In the

Bug#884987: reworked patch from Redhat's bugzilla

> But the patch there doesn't apply to the Debian > /etc/etckeeper/pre-commit.d/20warn-problem-files But the following reworked version of the patch does apply. It has fixed the problem for me. --- etc/etckeeper/pre-commit.d/20warn-problem-files 2016-07-18 01:01:39.0 +0200 +++

Bug#884987: etckeeper: /etc/cron.daily/etckeeper reports "abort: path contains illegal component: .hg/undo.dirstate"

Package: etckeeper Version: 1.18.7-1 Severity: normal I get a daily cron email with the following warnings/errors: /etc/cron.daily/etckeeper: abort: path contains illegal component: .hg/undo.dirstate abort: path contains illegal component: .hg/undo.backup.dirstate It seems not to be a

Bug#687421: printer-driver-hpcups: cannot set reverse-order printing in ppd

On 2017-10-30 13:19, Brian Potkin wrote: >> The printer is an HP PSC 2710 all-in-one scanner/fax/inkjet printer. >> I'm filing the bug against printer-driver-hpcups because the PPD has >> this line: > > HP Photosmart 2700? Pretty much -- it was actually a PhotoSmart

Bug#877888: closed by Brian Potkin <claremont...@gmail.com> (Re: Bug#877888: cups-bsd: lpq and lp ignore the PRINTER environment variable)

> Thanks for doing that. As it happens, cups 2.2.5 is now in unstable so I > re-tested. None of the issues we both observed appear to be present in > this version. I have not looked closely to find the cause of the fix but > it is a good note on which to close this report. Maybe it was this

Bug#877888: cups-bsd: lpq and lp ignore the PRINTER environment variable

On 2017-10-11 18:52, Brian Potkin wrote: > When it came to unstable (only /etc/cups/lpoptions existing) I obtained > the same as you did. > > It would be good if you would test some of my observations and report > before the bug is forwarded upstream. Brian, I've

Bug#877888: cups-bsd: lpq and lp ignore the PRINTER environment variable

Package: cups-bsd Version: 2.2.4-7 Severity: normal File: /usr/bin/lpq lpq and lp are no longer paying attention to the PRINTER environment variable. (The cups(1) manpage says that PRINTER is used except for setuid binaries. But lpq and lp are not setuid.) Here is a commented log with lpq:

Bug#856573: twm + chromium on amd64 produces the problem (Re: chromium: pulldown menus not working (not pulling down))

On 2017-03-02 09:28, Sanjoy Mahajan <san...@olin.edu> wrote: > Package: chromium > Version: 56.0.2924.76-4 I also see the problem with chromium 59. I've just noticed that the problem happens only when my window manager is twm or ctwm (I also tested fvwm and x-window-manager, whi

Bug#856573: chromium: pulldown menus not working (not pulling down)

Package: chromium Version: 56.0.2924.76-4 Severity: normal On chromium 56 and 55 (and maybe 54, but I forget now), pulldown menus do not work. To reproduce it, I start chromium with a clean profile: $ mv ~/.config/chromium/ ~/.config/chromium-backup-while-testing $ rm -fr /tmp/chrome-debug/ $

Bug#850444: auctex: context mode doesn't show subsubsections in outline

Package: auctex Version: 11.89-1 Severity: normal In context mode, very low-level headings don't appear in an outline view. Here is a minimal example (test.tex) cut here - \starttext \chapter{level 1} \section{level 2} \subsection{level 3}

Bug#836252: asymptote: only full-page figures produced with pdflatex engine

Package: asymptote Version: 2.38-1 Severity: normal After updating to TL 2016, my usual invocation of asymptote started producing full-page figures (the size of US letter paper), rather than the size requested in the .asy file. For example, as with this file: size(100); draw(unitsquare);

Bug#826751: apt: download even not on AC power

Package: apt Version: 1.2.12 Severity: wishlist File: /usr/lib/apt/apt.systemd.daily Dear Maintainer, On my last laptop, I appreciated the forbearance of the daily apt cron run, which exited on battery power. This laptop fortunately has an SSD, and the apt run doesn't produce much battery

Bug#823701: powertop: fails to find cache file that might be misnamed

Package: powertop Version: 2.8-1 Severity: normal Powertop is looking for, but cannot find, /var/cache/powertop/saved_parameters.powertop Here is an example # powertop Loaded 100 prior measurements Cannot load from file /var/cache/powertop/saved_parameters.powertop File will be loaded

Bug#815940: maxima: info files not where maxima expects them

Package: maxima Version: 5.37.3-1 Severity: normal When asking maxima for help, it tries to find info files like /usr/share/doc/maxima/info/./maxima.info-1. Here is an example: $ maxima Maxima 5.37.3 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.12 Distributed

Bug#807769: systemd: /tmp mounted as tmpfs without user asking for it

Michael Biebl writes: > Have you read the comments in /etc/tmpfiles.d/tmp.conf ? > You previously already had tmpfs-on-/tmp under sysvinit as you've set it > in /etc/default/rcS. I don't think so. See the current /etc/default/rcS below. It is also the version almost from the

Bug#807769: systemd: /tmp mounted as tmpfs without user asking for it

You're right, the /etc/default/tmpfs does set RAMTMP. However, /etc/fstab doesn't have an entry for /tmp (I don't have any partitions other than /, except for /boot/efi). That may explain why my /tmp wasn't on tmpfs until some action much after the boot forced that to happen even though /tmp

Bug#807769: systemd: /tmp mounted as tmpfs without user asking for it

Package: systemd Version: 228-2 Severity: normal -- Package-specific info: -- BEGIN ATTACHMENTS -- /tmp/tmp.7IxkS3mmju/systemd-delta.txt /tmp/tmp.7IxkS3mmju/systemd-analyze-dump.txt /tmp/tmp.7IxkS3mmju/dsh-enabled.txt /etc/fstab -- END ATTACHMENTS -- * What led up to the situation? A bunch

Bug#807780: auctex: Error running timer `font-latex-jit-lock-force-redisplay'

Package: auctex Version: 11.87-3+deb8u1 Severity: normal File: /usr/share/emacs/site-lisp/auctex/font-latex.el Dear Maintainer, -- Package-specific info: Content of '/usr/share/emacs/site-lisp/auctex'

Bug#797098: asymptote: old-gs-use-epswrite patch fails with gs in testing/unstable

Package: asymptote Version: 2.35-1 Severity: normal When running asymptote on a figure with 3d objects (three.asy) and using TeX labels, the call to 'gs' fails, e.g. $ asy -noprc -render=0 -k -v -v -tex pdflatex -f pdf -V -wait merry-go-round ... gs -q -dBATCH -P -dSAFER -sDEVICE=epswrite

Bug#780224: imagemagick: compare no longer terminates output with \n

I disagree with the developers' reasoning (programs also like newlines), but thank you for the useful workaround. -Sanjoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780224: imagemagick: compare no longer terminates output with \n

Package: imagemagick Version: 8:6.8.9.9-5 Severity: normal Dear Maintainer, -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org compare: ImageMagick 6.8.9-9 Q16 i586 2015-01-05

Bug#764430: xpdf: fi ligature not rendered on attached page

Package: xpdf Version: 3.03-17+b1 Severity: normal Viewing the attached file with xpdf missing-fi.pdf shows a page image with blank space instead of the fi in the text Limitations of first generation... (the second reference in the References section). A screenshot is also attached -- see the

Bug#708550: auctex: fails when first visited file is plain tex (rather than latex or context)

Tested here, and it solves the problem. Thank you. You probably know the following, but installing auctex gives the following: $ dpkg -i /home/sanjoy/admin/auctex/auctex_11.87-1.1_all.deb /home/sanjoy/admin/auctex/preview-latex-style_11.87-1.1_all.deb ... Setting up auctex (11.87-1.1)

Bug#640515: printing works with 3.03-16

Sanjoy Mahajan san...@olin.edu writes: I applied the fix-globalparams-clash.patch from #658264 to xpdf 3.03-9, rebuilt the packages, and printing now works again (without the patch, it would crash whenever I tried to print). Printing now also works with the latest xpdf (3.03-16), without

Bug#707596: maxima: 1000!^0.01 produces i.nfE+142498684

The problem is also present in the latest maxima (5.32.1-1): $ maxima Maxima 5.32.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.10 (a.k.a. GCL) ... (%i1) 1000!^0.01; (%o1)i.nfE+6166368 I am happy to report it upstream. Actually, I just did:

Bug#733675: dictionaries-common: ispell-buffer misses misspellings in tex mode

Hi, again, found the real commit to blame (and the author, me :-(), http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/110817 Great work debugging. I'll happily test any proposed changes. -Sanjoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of

Bug#733675: dictionaries-common: ispell-buffer misses misspellings in tex mode

Thank you for the bisection and further information. I do not have much spare time these days, do not know when I will be able to look at this in depth. I know the feeling. I will also try to look into it. Best, -Sanjoy -- To UNSUBSCRIBE, email to

Bug#733675: dictionaries-common: ispell-buffer misses misspellings in tex mode

a) Which spellchecker you are using under emacs (`ispell-program-name')? aspell b) Does this problem appears also for emacs23? (I could not reproduce it with wheezy emacs23). This should help discarding if the problem is in emacs24 search functions because both use similar ispell.el. Yes.

Bug#733675: dictionaries-common: ispell-buffer misses misspellings in tex mode

Package: dictionaries-common Version: 1.20.4 Severity: normal The following file contains two misspellings that are missed by M-x ispell-buffer (in emacs24-24.3+1-2+b1). To reproduce, start emacs with emacs -q -nw file.tex and then M-x ispell-buffer and it'll report no errors. --- cut here

Bug#732555: ghostscript: gs 9.05 doesn't handle slightly broken pdf file as well as gs 9.10

Jonas Smedegaard d...@jones.dk writes: Your own tests indicate that indeed a newer gs is a fix for this bug. Please, however, let's discuss only the actual bug in this bugreport. Sure. I just didn't want others to waste time trying to debug something that has been fixed upstream. A separate

Bug#728444: is there an unbreaks tag for once xpdf is fixed?

On upgraing to the latest fontconfig, aptitude wants to uninstall xpdf, which is reasonable since xpdf doesn't work with the latest fontconfig. I am tempted to let aptitude have its way, but I want xpdf back once it gets fixed. Is that possibility automated in any way, e.g. an unbreaks tag once

Bug#725066: dot2tex: failed import of _noncomma with pyparsing 2.0.1 (patch included)

Package: dot2tex Version: 2.8.7+repack-1 Severity: normal dot2tex fails (I think since pyparsing got upgraded to 2.0.1) with ImportError: cannot import name _noncomma: $ dot2tex -f tikz -c --autosize --docpreamble \input /home/sanjoy/sfse/fig/dot_template fig/circular-acceleration-group.dot

Bug#719281: mupdf: man page should refer to mutool instead of mupdfclean etc.

Package: mupdf Version: 1.2-2 Severity: normal The man page for mupdf needs this diff: --- mupdf.1 2013-08-09 21:09:49.0 -0400 +++ mupdf.1 2013-08-09 21:10:18.0 -0400 @@ -85,8 +85,7 @@ Sending a \fBSIGHUP\fR signal to the mupdf process will also cause the viewed file to

Bug#711377: emacs24: crashed with free(): invalid next size (fast) error

Package: emacs24 Version: 24.3+1-1 Severity: normal Emacs crashed with the following memory-management error: *** Error in `emacs': free(): invalid next size (fast): 0x09f493f0 *** === Backtrace: = /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x75e62)[0xb6047e62]

Bug#710735: cups: ambiguous ref to /etc/cups/lpoptions

Package: cups Version: 1.5.3-5 Severity: normal [Same as closed Bug#463752 on former cupsys-client package] I misinterpreted this statement in the manpage for lpoptions: When run by the root user, lpoptions gets and sets default options and instances for all users in the

Bug#707596: maxima: 1000!^0.01 produces i.nfE+142498684

Package: maxima Version: 5.30.0-4 Severity: normal Here's a transcript: $ maxima Maxima 5.30.0 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (a.k.a. GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William

Bug#577526: lprm works for me with current testing (1.5.3-2.15)

I just tried it with the same printer using current testing (cups-bsd 1.5.3-2.15). lprm cancels the job successfully. Great! -Sanjoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697701: graphviz: dot: assertion failure in dot_position

Package: graphviz Version: 2.26.3-12 Severity: normal The attached input file, also copied below, crashed dot: $ dot storyboard/dot-crashes-on-this.dot Warning: DC was already in a rankset, ignored in cluster G Warning: A was already in a rankset, ignored in cluster G dot:

Bug#697654: python-moinmoin: backports pkg needs python-werkzeug = 0.7

Package: python-moinmoin Version: 1.9.4-8+deb7u1~bpo60+1 Severity: normal On my Debian server, which runs squeeze plus squeeze backports, I was running python-moinmoin 1.9.4-8+deb7u1~bpo60+1 from squeeze backports. After the recent security upgrade, moinmoin stopped working. The webserver

Bug#687421: printer-driver-hpcups: cannot set reverse-order printing in ppd

Package: printer-driver-hpcups Version: 3.12.6-3 Severity: normal From Bug#522595 (closed by Brian Potkin): This bug report was submitted against a version of CUPS that is no longer supported in Debian. Fair enough. I just retested it with cups 1.5.3-1 and cups-filters 1.0.18-2+b1 (both from

Bug#612975: cups: gs run by pdftopdf filter gives floating point exception

Nowadays you would be looking at cups-filters or ghostscript. So please try the present testing/unstable packages and report back to us. I just printed the file with the same command line. It came out fine. I'm updating daily from testing (and pulling from unstable when needed):

Bug#663712: cups: printing fails with ERROR: undefined (HP LaserJet 4600)

try printing again with the latest package versions and let us know how you go on. I retried the three methods of printing, each of which had problems before. Here's what happened with each one: 1. lp -o fitplot file.pdf This method now works fine. Progress! 2. pdftops -paper match

Bug#674090: texlive-binaries: updmap cannot find TLUtils.pm

try aptitude install texlive-base/unstable texlive-common/unstable texlive-doc-base/unstable I tried something similar, namely: aptitude install -t unstable texlive and all the packages seem to be working well. -- -Sanjoy -- To UNSUBSCRIBE, email to

Bug#674090: texlive-binaries: updmap cannot find TLUtils.pm

Norbert, How do you come to this line ... I have unshift (@INC, /usr/share/texlive/tlpkg); Good question. I didn't change anything in updmap by hand. But then I don't understand how it became different. I went through the texlive-binaries-*.deb files in the /var/cache/apt/archives/,

Bug#674090: texlive-binaries: updmap cannot find TLUtils.pm

Package: texlive-binaries Version: 2012.20120516-1 Severity: normal Configuring tex-common always fails for me now when updmap-sys runs: Setting up tex-common (3.11) ... Running mktexlsr. This may take some time... done. Running mtxrun --generate. This may take some time... done. Running

Bug#640515: printing works again with patch from #658264

I applied the fix-globalparams-clash.patch from #658264 to xpdf 3.03-9, rebuilt the packages, and printing now works again (without the patch, it would crash whenever I tried to print). -- -Sanjoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of

Bug#645360: org-mode: outline-demote incorrectly demotes leaf nodes

Package: org-mode Version: 7.7-2 Severity: normal Here's my test file, call it c.org: * a ** aa *** aaa I put the cursor at the beginning of the file (at the * in the first line). Then I type C-c C- (i.e. outline-demote). The result is ** a *** aa *** aaa I expected that the last line (the

Bug#598896: workaround using driconf

From the KDE forums at http://forum.kde.org/viewtopic.php?f=111t=91663 (post by octavsly on Nov 27, 2010), I got the idea of making a .drirc using driconf and setting No for Enable limited ARB_gfragment_shader support on 915/945. This configuration change fixed the i915_program_error roblem for

Bug#639339: different from bug 583487

msg #20 Did you try printing the pdf from bug 583487? I also tried that pdf file and it printed fine. I printed it from xpdf using 'lp -o fitplot -o PageSize=letter' as the print command. -- -Sanjoy `Until lions have their historians, tales of the hunt shall always glorify the hunters.'

Bug#601732: xserver-xorg-video-intel: render error upon S3 wakeup

I don't think the fix in https://bugzilla.kernel.org/show_bug.cgi?id=15544 solved the problem for me. That fix was in 2.6.35-rc2, but the problem happened for me even with the 2.6.36 kernel. However, the good news is that the error is now gone; or rather the error shows up but is cleared so

Bug#588317: patch to fix FTBFS

I was getting the same errors trying to rebuild cups. cups (see cups-1.4.7/.pc/reactivate_recommended_driver.patch/scheduler/cups-driverd.cxx, line 1996) checks, in the *Product line in the ppd, that the product name ends with a right parenthesis. The warnings come from ppds where the product

Bug#635842: likely fix for your backend crash

Norbert, As you write, cups became completely unusable, as the lpd backend just happens to die with a strange error. For me the problem started with the upgrade to 1.4.7. I had a slightly different symptom, namely that the socket backend would die with status -8 (crashed), but only on my HP PSC

Bug#631581: -exec is also broken

A related error is that -exec no longer works. For example: $ xpdf -remote /home/sanjoy/sfmbook -exec goBackward Error: file not found: 'goBackward' The problem is because, in /usr/bin/xpdf, -exec is not listed as a switch that takes a further argument. For me the following diff fixes

Bug#629863: isc-dhcp-client: error dhcping means no routes are installed

Package: isc-dhcp-client Version: 4.1.1-P1-17 Severity: grave File: /sbin/dhclient-script Today I noticed that ifup using dhcp kept failing, and I had to add the routes manually. The problem was in running dhclient, which would give an error when executing the following shell command from

Bug#525619: xserver-xorg-video-intel: screen blank after returning to vt7

I see you're running 2.6.37, and it looks like there were some more backlight fixes lately, so you might want to try latest 2.6.38-rc from experimental. Thanks, I've just now looked at the shortlog entry related to the backlight. However, my backlight is fine: It turns off upon suspend and

Bug#614831: poppler-utils: page rotation not correct

Package: poppler-utils Version: 0.12.4-1.2 Severity: normal File: /usr/bin/pdftoppm pdftoppm doesn't test for page rotation correctly. It assumes that any non-zero rotation is a 90-degree rotation. However, that test fails if the rotation is 180. I just tracked down the problem line in the

Bug#525619: xserver-xorg-video-intel: screen blank after returning to vt7

could we please get an update, with either squeeze or higher? Alas, yes: I still see the problem. It happens every couple days where the screen is blank (but the backlight is on). A few days ago I had started filling out a new Debian bug report, but then got the hang again, rebooted, and lost

Bug#533090: Acknowledgement (xserver-xorg-video-intel: X server crashed, now virtual consoles not working)

I haven't seen the GPU hang recently (running testing/unstable). Instead when it crashes after S3 resume, the screen is off but the backlight is on (and the GPU s otherwise working fine). See Bug#525619. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of

Bug#612975: Acknowledgement (cups: gs run by pdftopdf filter gives floating point exception)

I rebuilt the ghostscript packages with debugging and installed these: ghostscript-x_8.71~dfsg2-10_i386.deb ghostscript-doc_8.71~dfsg2-10_all.deb ghostscript-cups_8.71~dfsg2-10_i386.deb ghostscript_8.71~dfsg2-10_i386.deb Then I reran the failing gs command in gdb. It gave this backtrace:

Bug#606340: downgrading worked for me

Downgrading xserver-xorg-video-intel to 2.13.0-3 solved the same problem for me (Thinkpad T60 with Intel 945GM graphics). I suspected that it would work based on the Debian Changelog entry for 2.13.0-4: * Fail intel_pci_probe if we don't have a kernel mode setting driver. This allows the X

Bug#603777: xpdf: munmap_chunk(): invalid pointer detected by glibc

Package: xpdf Version: 3.02-11 Severity: normal File: /usr/bin/xpdf I was viewing a pdf file (slides.pdf) with xpdf, switched to full-screen mode, then quickly switched back, and xpdf crashed with the following message. If I can attach documents to a bug report, and someone tells me how (I never

Bug#601732: xserver-xorg-video-intel: render error upon S3 wakeup

Reassigning to the kernel source package for now; I guess it would be good to confirm you're having the issue with the kernel shipped in experimental… I pretty much am running that kernel. I compiled 2.6.36 by taking the config file from the linux-image-2.6.36-rc6 package in experimental,

Bug#601732: xserver-xorg-video-intel: render error upon S3 wakeup

Package: xserver-xorg-video-intel Version: 2:2.12.0+shadow-2 Severity: normal This is the same problem I saw in bugzilla.kernel.org/show_bug.cgi?id=15544: Upon waking up from S3 sleep, the screen came back very close to black (with just enough brightness that I could make out where my Emacs

Bug#598896: no problems on my x201s

Using LIBGL_ALWAYS_SOFTWARE=1 does work around the error for me; it's still there without that environment setting (I'm using the i915 driver w/ 945GM chipset). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#589787: xserver-xorg-video-intel: render error and then server crashes

Not sure it's going to help, but well, having an updated bug status would be nice. For a week or so I've been running xserver-xorg-video-intel 2.12.0+shadow-2 (and shadow-1 for a week before that). Good news: The problem has not reappeared. -- To UNSUBSCRIBE, email to

Bug#598896: python-visual: i915_program_error: Exceeded max instructions

Package: python-visual Version: 1:5.12-1.1+b2 Severity: grave Using VPython (python-visual in Debian) now always produces i915_program_error: Exceeded max instructions For example, $ python /usr/share/doc/python-visual/examples/doublependulum.py i915_program_error: Exceeded max

Bug#287800: gnuplot: mp terminal won't allow prologues:=-1

Bastien ROUCARIES roucaries.bast...@gmail.com wrote: Upstream of gnuplot ask about precision about the prologue:=-1 stuff. Upstream does not found any documentation about this parameter set to -1. Could you help ? I looked at the metapost manual (v1.208), which is

Bug#597007: gnuplot: pdfcairo terminal misinterprets | in filename

Package: gnuplot Version: 4.4.0-1 Severity: normal The 'pdfcairo' terminal misinterprets a | in the output filename. An example: $ cat cmds set term pdfcairo set output | cat plot sin(x) $ gnuplot cmds $ ls -l total 12 -rw-r--r-- 1 sanjoy sanjoy 7503 Sep 15 14:33 | cat

Bug#589787: xserver-xorg-video-intel: render error and then server crashes

Is this reproducible with 2.12.0 from experimental? I am trying 2.12.0 now. But I get several problems: 1. One time it wouldn't resume from S3 sleep. 2. Regularly the mouse does not work. I'll try some more tests and see what I can reproduce and capture in the log and be back in touch in a

Bug#589787: xserver-xorg-video-intel: render error and then server crashes

Is this reproducible with 2.12.0 from experimental? I will try that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#525619: xserver-xorg-video-intel: screen blank after returning to vt7

In both cases, the backlight was still on, but the screen was blank. And switching back to vt1 or any other non-X vt, then back to vt7, did not solve it. However, putting the laptop into S3 sleep and then resuming solved the problem. can you still reproduce this with latest intel driver and

Bug#577526: cups-bsd: lprm doesn't take effect without restarting cups

Package: cups-bsd Version: 1.4.3-1 Severity: normal File: /usr/bin/lprm When I cancel a job with lprm, it doesn't go away until I restart cups. Here's a transcript: # lpq psc is ready and printing RankOwner Job File(s) Total Size active sanjoy 1238

Bug#576543: xpdf-reader: Invalid command syntax: 'zoomFitPage' / 'zoomFitWidth'

The xpdf binary expects the file libpng.so.3. Created a symlink for that file in /lib to /lib/libpng12.so.0.43.0. It works and pressing 'z' works as expected. Before fixing it by making the symlink, did you also notice that scrolling (with the downarrow key) was very sluggish? I had that

Bug#564159: xserver-xorg-video-intel: crashed with assertion failure

I've been running current kernels and libdrm (2.4.18 from unstable) and haven't seen the problem recur. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#564946: xserver-xorg-video-intel: screen flickers, tears, turns pink

At least the flickering and 'screen turns to pink' issues are a kernel bug (or multiple kernel bugs). Adding i915.powersave=0 to the kernel command line should work around that. Thanks. That fixed the pink screen and the flickering (and the 'tearing'). -- To UNSUBSCRIBE, email to

Bug#564946: xserver-xorg-video-intel: screen flickers, tears, turns pink

Package: xserver-xorg-video-intel Version: 2:2.9.1-2 Severity: grave The flickering in #56 has returned since I upgraded the X server and kernel a couple days ago (I'm tracking 'unstable'). Now it flickers a once or twice per minute. In addition, one of the Firefox windows often gets

Bug#522249: iceweasel: reproducible segfault at a particular URL

The link is still there, two lines above the Long shot title. But clicking on it and then printing worked fine just now (iceweasel 3.5.6-1). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#543281: stty ioctl problems with debian-el again

; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Sanjoy Mahajan san...@mrao.cam.ac.uk To: Debian Bug Tracking System sub...@bugs.debian.org Subject: none X-Debbugs-Cc: none, Sanjoy Mahajan san...@mit.edu stty: standard input: Inappropriate ioctl for device I

Bug#558459: cups: printing fails with cupsRasterOpen failed msg

You are right. I just found the same message: [Job 1026] psc: symbol lookup error: psc: undefined symbol: _ZN13GfxColorSpace5parseEP6Object -Sanjoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#558776: powertop: reported power usage is too high (210.6 W on a T60)

Package: powertop Version: 1.11-1 Severity: normal For the last few months I've noticed that powertop reports that my laptop is consuming 210.6 W and that the battery will last 0.3 hours. Those values are not correct. 'acpi' says that the battery will last four more hours, which agrees with my

Bug#523969: xserver-xorg: crash and assertion failure after running mplayer

Julien Cristau jcris...@debian.org wrote: It's quite likely that this is fixed with newer libdrm and/or xserver-xorg-video-intel. Can you confirm? I'm now using libdrm 2.4.15-1 and xserver-xorg-video-intel 2.9.1-1, and I just retested the .mp4 files on my system (not sure which .mp4 file I

Bug#558459: cups: printing fails with cupsRasterOpen failed msg

Package: cups Version: 1.4.2-2 Severity: grave Since an 'aptitude dist-upgrade' a couple hours ago, printing hasn't worked. For example, 'lp file.pdf' always failed with a message like the following in the error_log [Job 1026] prnt/hpcups/HPCupsFilter.cpp 485: cupsRasterOpen failed, fd = 0 The

  1   2   >