from:"Sanjoy Mahajan"

Bug#1074583: upstream has provided a one-line patch to fix it

2024-07-08 Thread Sanjoy Mahajan

Upstream has a one-line patch to fix this issue, which I've tested with
success.  The commit id is given in the github issue:


-Sanjoy

Bug#1074583: reported upstream too

2024-07-04 Thread Sanjoy Mahajan

I've also just reported this issue upstream, as it happens with the
latest upstream version.  Link to github issue:

https://github.com/getmail6/getmail6/issues/199

Bug#1074583: getmail6: fails at startup with "TypeError: IMAP4_SSL.init()" after change to python3.12

2024-07-01 Thread Sanjoy Mahajan

Package: getmail6
Version: 6.19.01-1
Severity: grave

getmail6 now crashes at startup with the error shown below in the
transcript.  It works fine with Python 3.11:

  $ python3.11 /usr/bin/getmail --rcfile=rc-inbox
  getmail version 6.19.01
  Copyright (C) 1998-2024 Charles Cazabon and others. Licensed under GNU GPL 
version 2.
  SimpleIMAPSSLRetriever:san...@mit.edu@outlook.office365.com:993:
0 messages (0 bytes) retrieved, 0 skipped

My system (mostly running 'unstable') just changed to Python 3.12 a day
or so ago, and getmail6 has failed since then (but not before).  Thus, I
suspect something is now incompatible between the getmail code and
Python 3.12's expectations.

Here is promised failure transcript with Python 3.12:

  $ /usr/bin/getmail --rcfile=rc-inbox
  getmail version 6.19.01
  Copyright (C) 1998-2024 Charles Cazabon and others. Licensed under GNU GPL 
version 2.
  SimpleIMAPSSLRetriever:san...@mit.edu@outlook.office365.com:993:

  Exception: please read docs/BUGS and include the following information in any 
bug report:

getmail version 6.19.01
Python version 3.12.4 (main, Jun 12 2024, 19:06:53) [GCC 13.2.0]

  Unhandled exception follows:
  File "/usr/bin/getmail", line 1077, in main
  success = go(configs, options.idle, options.only_account)
^^^
  File "/usr/bin/getmail", line 188, in go
  retriever.initialize(options)
  File "/usr/lib/python3/dist-packages/getmailcore/_retrieverbases.py", 
line 1807, in initialize
  self._connect()
  File "/usr/lib/python3/dist-packages/getmailcore/_retrieverbases.py", 
line 714, in _connect
  self.conn = imaplib.IMAP4_SSL(
  ^^
TypeError: IMAP4_SSL.__init__() takes from 1 to 3 positional arguments but 
5 were given

  Please also include configuration information from running getmail
  with your normal options plus "--dump".


-- System Information:
Debian Release: sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages getmail6 depends on:
ii  python3  3.12.2-1

getmail6 recommends no packages.

getmail6 suggests no packages.

-- no debconf information

Bug#1072743: pdfxup: --pages option fails if page range omits start or end of range

2024-06-09 Thread Sanjoy Mahajan

Dear Nicolas,

I found a small bug in the TL pdfxup (on Debian) and filed a Debian bug
report.  The Debian TL maintainers suggested that I discuss it with you
as upstream, as the bug is likely upstream.

The bug report is in the Debian BTS:


But here is a copy of that report:

The man entry for pdfxup says that --pages can handle an omitted start
or end of range, e.g. "--pages 2-" or "--pages -5".  However, using the
following pdf file as a test (it's one page long) gives an error
if either the start or end of the range is omitted.

Omitting the end of the range:

$ pdfxup --pages 1- /usr/share/cups/data/default-testpage.pdf
-> processing options 
/usr/bin/pdfxup: line 405: [[: 1-: syntax error: operand expected (error token 
is "-")
   /usr/share/cups/data/default-testpage.pdf has 1 page(s); pages 1- do not 
exist.
/usr/bin/pdfxup: line 405: [[: 1-: syntax error: operand expected (error token 
is "-")
   /usr/share/cups/data/default-testpage.pdf has 1 page(s); pages 1- do not 
exist.
   No pages to include. Aborting.

Omitting the start of the range also fails:

$ pdfxup --pages -1 /usr/share/cups/data/default-testpage.pdf
Error: option '--pages' expects a range, not '-1'.
Aborting.

But omitting both start and end works as described in the man page:

$ pdfxup --pages - /usr/share/cups/data/default-testpage.pdf
-> processing options 
-> computing bounding box.
-> producing final file 
   final scale: 95.35675%
-> cleaning 


I am happy to test any patches.

Best regards,
-Sanjoy

Bug#1072743: texlive-extra-utils: pdfxup: --pages option fails if page range omits start or end of range

2024-06-08 Thread Sanjoy Mahajan

Yes, I'll be happy to discuss it with upstream.
Should I CC you?  Or just update the Debian bug as needed?

-Sanjoy

On 2024-06-07 15:48, Preuße, Hilmar  wrote:

> On 07.06.2024 13:09, Sanjoy Mahajan wrote:
>
> Hi,
>
>> The man entry for pdfxup says that --pages can handle an omitted start
>> or end of range, e.g. "--pages 2-" or "--pages -5".  However, using the
>> following pdf file as a test (it's one page long) gives an error
>> if either the start or end of the range is omitted.
>> 
> Are you willing to discuss this with the upstream author?
>
> https://www.ctan.org/tex-archive/support/pdfxup
>
> Thanks,
>Hilmar
> -- 
> sigfault

Bug#1072743: texlive-extra-utils: pdfxup: --pages option fails if page range omits start or end of range

2024-06-07 Thread Sanjoy Mahajan

Package: texlive-extra-utils
Version: 2024.20240401-2
Severity: normal
File: /usr/bin/pdfxup

The man entry for pdfxup says that --pages can handle an omitted start
or end of range, e.g. "--pages 2-" or "--pages -5".  However, using the
following pdf file as a test (it's one page long) gives an error
if either the start or end of the range is omitted.

Omitting the end of the range:

$ pdfxup --pages 1- /usr/share/cups/data/default-testpage.pdf
-> processing options 
/usr/bin/pdfxup: line 405: [[: 1-: syntax error: operand expected (error token 
is "-")
   /usr/share/cups/data/default-testpage.pdf has 1 page(s); pages 1- do not 
exist.
/usr/bin/pdfxup: line 405: [[: 1-: syntax error: operand expected (error token 
is "-")
   /usr/share/cups/data/default-testpage.pdf has 1 page(s); pages 1- do not 
exist.
   No pages to include. Aborting.

Omitting the start of the range also fails:

$ pdfxup --pages -1 /usr/share/cups/data/default-testpage.pdf
Error: option '--pages' expects a range, not '-1'.
Aborting.

But omitting both start and end works as described in the man page:

$ pdfxup --pages - /usr/share/cups/data/default-testpage.pdf
-> processing options 
-> computing bounding box.
-> producing final file 
   final scale: 95.35675%
-> cleaning 



-- System Information:
Debian Release: sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-extra-utils depends on:
ii  libfile-homedir-perl   1.006-2
ii  libunicode-linebreak-perl  0.0.20190101-1+b7
ii  libyaml-tiny-perl  1.74-1
ii  python33.11.8-1
ii  tex-common 6.18
ii  texlive-base   2024.20240401-2
ii  texlive-binaries   2024.20240313.70630+ds-2
ii  texlive-latex-base 2024.20240401-2
ii  texlive-luatex 2024.20240401-2
ii  texlive-plain-generic  2024.20240401-2

Versions of packages texlive-extra-utils recommends:
ii  ghostscript10.03.1~dfsg-1
ii  liblog-log4perl-perl   1.57-1
ii  ruby   1:3.1+nmu1
ii  texlive-latex-recommended  2024.20240401-2

Versions of packages texlive-extra-utils suggests:
ii  chktex1.7.9-1
ii  default-jre-headless  2:1.17-75
ii  dvidvi1.0-10.2
ii  dvipng1.15-1.1+b2
ii  fragmaster1.7-11
ii  lacheck   1.26-17
ii  latexdiff 1.3.2-1
ii  latexmk   1:4.85-1
ii  purifyeps 1.1-3
pn  xindy 

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.15.3

Versions of packages texlive-extra-utils is related to:
ii  tex-common6.18
ii  texlive-binaries  2024.20240313.70630+ds-2

-- no debconf information

Bug#1071595: it was a printer firmware problem

2024-05-22 Thread Sanjoy Mahajan

I have just updated the printer's firmware (from a 2015 to a 2020 one).
Now it prints in duplex mode with no complaints.  So, it was almost
certainly a printer bug rather than a CUPS bug.

-- 
-Sanjoy

Bug#1071595: cups: contortions needed to use duplex printing on HP Laserjet M402dn

2024-05-21 Thread Sanjoy Mahajan

Package: cups
Version: 2.4.7-1.2+b1
Severity: normal
X-Debbugs-Cc: none, Sanjoy Mahajan 

When using CUPS (lp), I couldn't get duplex printing to work on the
newly arrived (used) HP Laserjet M402dn.  The documents come out single
sided even though I had (1) set the print queue's default options to
include two-sided-long-edge (via the web interface on port 631), (2) had
specified sides=two-sided-long-edge on the command line, and (3) had set
the printer's default (via the EWS) to duplex (long edge).

Meanwhile, the printer hardware works fine: My wife's Mac, also running
CUPS, prints duplex with no problem, and sending a PDF directly to the
printer using netcat gives duplex output too.

The problem seems to be the following, from the cups error_log (see
attached 1.log for the full output for that job):

D [21/May/2024:20:53:32 +0200] [Job 12731]  unsupported-attributes-tag 
D [21/May/2024:20:53:32 +0200] [Job 12731] sides keyword two-sided-long-edge
D [21/May/2024:20:53:32 +0200] [Job 12731]  end-of-attributes-tag 
D [21/May/2024:20:53:32 +0200] [Job 12731] Unable to do two-sided printing, 
setting sides to \'one-sided\'.

However, the printer itself knows it can do two-sided printing.  Also
from the error_log:

D [21/May/2024:20:53:32 +0200] [Job 12731] media-col-supported 1setOf keyword 
media-size,media-top-margin,media-left-margin,media-right-margin,media-bottom-margin,media-type,media-source,media-source-properties,duplex-supported

And I've attached the result of running ipptool to get the printer attributes:

$ ipptool -tv ipp://NPI4CFED8.lan:631/ipp/print get-printer-attributes.test > 
attributes.txt

It contains

media-col-supported (1setOf keyword) = 
media-size,media-top-margin,media-left-margin,media-right-margin,media-bottom-margin,media-type,media-source,media-source-properties,duplex-supported

I've worked around the problem by setting the following default options
(from /etc/cups/lpoptions):

Default lj402 sides=DuplexNoTumble

This new setting of the "sides" keyword seems to confuse cups enough
that it doesn't bother to forcibly revert to one-sided output.  And the
printer hardware's configuration of printing duplex now takes over.

For reference ,here are the printer's lpoptions:

$ lpoptions -l
PageSize/Media Size: 100x150mm 184x260mm 195x270mm 4x6 5x8 *A4 A5 A6 B5 B6 
DoublePostcardRotated Env10 EnvC5 EnvDL EnvMonarch Executive FanFoldGermanLegal 
ISOB5 Legal Letter Oficio Postcard Statement roc16k Custom.WIDTHxHEIGHT
InputSlot/Media Source: *Auto Manual Tray1 Tray2
MediaType/Media Type: *Stationery StationeryLightweight ExtraLight Intermediate 
Midweight StationeryHeavyweight ExtraHeavy Transparency Labels 
StationeryLetterhead Envelope StationeryPreprinted StationeryPrepunched 
StationeryColored StationeryBond Recycled Rough
cupsPrintQuality/cupsPrintQuality: Draft *Normal
ColorModel/Output Mode: *Gray
Duplex/Duplex: None *DuplexNoTumble DuplexTumble
OutputBin/OutputBin: *FaceDown



-- System Information:
Debian Release: sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client2.4.7-1.2+b1
ii  cups-common2.4.7-1.2
ii  cups-core-drivers  2.4.7-1.2+b1
ii  cups-daemon2.4.7-1.2+b1
ii  cups-filters   1.28.17-4
ii  cups-ppdc  2.4.7-1.2+b1
ii  cups-server-common 2.4.7-1.2
ii  debconf [debconf-2.0]  1.5.86
ii  ghostscript10.03.1~dfsg~git20240518-1
ii  libavahi-client3   0.8-13+b2
ii  libavahi-common3   0.8-13+b2
ii  libc6  2.38-11
ii  libcups2t642.4.7-1.2+b1
ii  libgcc-s1  14.1.0-1
ii  libstdc++6 14.1.0-1
ii  libusb-1.0-0   2:1.0.27-1
ii  poppler-utils  24.02.0-5
ii  procps 2:4.0.4-4

Versions of packages cups recommends:
ii  avahi-daemon  0.8-13+b2
ii  colord1.4.7-1+b1

Versions of packages cups suggests:
ii  cups-bsd2.4.7-1.2+b1
ii  foomatic-db 20230202-1
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-15
ii  smbclient   2:4.20.1+dfsg-1
ii  udev256~rc2-3

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd

-- 
-Sanjoy

"An error can never become true however many times you r

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

2024-04-08 Thread Sanjoy Mahajan

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 packages to 3.8.5-2
and have re-tested: The connection works fine now.

-- 
-Sanjoy

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

2024-04-08 Thread Sanjoy Mahajan

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 of the various gnutls
packages.  They were upgraded from 3.8.4-2 to 3.8.5-1.

The following command with the given input lines reproduces the problem:

  $ gnutls-cli -V -d 9 --starttls --crlf --port 587 -V outgoing.mit.edu
  EHLO randomhost
  STARTTLS
  ctrl-D [to send EOF]

It fails with "*** Fatal error: The encryption algorithm is not supported."

(I haven't tried it with other outgoing servers, but this one definitely
shows the problem.)

The problem goes away after downgrading the relevant packages to 3.8.4-2 :

  # apt install gnutls-bin=3.8.4-2 gnutls-doc=3.8.4-2 
libgnutls-dane0t64=3.8.4-2 libgnutls-openssl27t64=3.8.4-2 
libgnutls28-dev=3.8.4-2 libgnutls30t64=3.8.4-2

(My sources.list includes the snapshots repos

  deb [check-valid-until=no] 
http://snapshot.debian.org/archive/debian/20240329T213539Z/ unstable main
  deb-src [check-valid-until=no] 
http://snapshot.debian.org/archive/debian/20240329T213539Z/ unstable main

)

The lines around the fatal error message with 3.8.5-1 are:

  |<4>| HSK[0x5632451d5260]: SERVER HELLO DONE (14) was received. Length 0[0], 
frag offset 0, frag length: 0, sequence: 0
  |<3>| ASSERT: ../../lib/buffers.c[get_last_packet]:1130
  |<3>| ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1374
  |<3>| ASSERT: ../../../lib/nettle/pk.c[_wrap_nettle_pk_encrypt]:773
  |<3>| ASSERT: ../../../lib/auth/rsa.c[_gnutls_gen_rsa_client_kx]:288
  |<3>| ASSERT: ../../lib/kx.c[_gnutls_send_client_kx_message]:379
  |<3>| ASSERT: ../../lib/handshake.c[handshake_client]:3183
  *** Fatal error: The encryption algorithm is not supported.
  |<5>| REC: Sending Alert[2|80] - Internal error
  |<5>| REC[0x5632451d5260]: Preparing Packet Alert(21) with length: 2 and min 
pad: 0
  |<9>| ENC[0x5632451d5260]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
  |<5>| REC[0x5632451d5260]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
  *** Handshake has failed
  |<5>| REC[0x5632451d5260]: Start of epoch cleanup
  |<5>| REC[0x5632451d5260]: End of epoch cleanup
  |<5>| REC[0x5632451d5260]: Epoch #0 freed
  |<5>| REC[0x5632451d5260]: Epoch #1 freed


I've kept my packages at 3.8.4-2 for now,n but I can do more debug tests
if needed (by upgrading, testing, and downgrading).

-Sanjoy


-- System Information:
Debian Release: sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnutls-bin depends on:
ii  libc6   2.37-15.1
ii  libgnutls-dane0t64  3.8.5-1
ii  libgnutls30t64  3.8.5-1
ii  libtasn1-6  4.19.0-3+b2

gnutls-bin recommends no packages.

gnutls-bin suggests no packages.

-- no debconf information

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

2023-12-13 Thread Sanjoy Mahajan

[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 proper dependencies that this
> cannot happen.
>
> Hilmar, please bump the minimal dep on tl-base to the required level.

Agreed.  That's what I was getting at (in my convoluted way) in my
previous email, about not being okay to close the case.

-Sanjoy

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

2023-12-13 Thread Sanjoy Mahajan

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 the required level.

Agreed.  That's what I was getting at (in my convoluted way) in my
previous email, about not being okay to close the case.

-Sanjoy

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

2023-12-13 Thread Sanjoy Mahajan

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 => 2023.20231207-1)
(suggested by Hilmar Preuße) has resurrected them.

-Sanjoy

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

2023-12-13 Thread Sanjoy Mahajan

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: 
> /usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/xmltex.ini
>
> They were in texlive-formats-extra before the latest uploaded; different 
> path, hence no file conflict.
>
>> Versions of packages texlive-binaries recommends:
>> ii  dvisvgm   3.1.2+ds-1
>> ii  texlive-base  2023.20231007-1
>> 
> Upgrading texlive-base to 2023.20231207-1 should solve your issue.

I've just tested that solution, and it works fine: tex-common now has no
problems.  Thank you!

-Sanjoy

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

2023-10-27 Thread Sanjoy Mahajan

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 some bandwidth information.  The dots
at the end were ongoing when I ctrl-Ced it.

# bing 192.168.7.165 192.168.7.1
Found 2 key hosts
0: 192.168.7.165 (192.168.7.165)
1: 192.168.7.1 (192.168.7.1)
--
Using 10 data payload sizes:
44 205 367 529 691 852 1014 1176 1338 1500 
--
ttl=1 probe_res=2 host=192.168.7.165
 --bing.c:740--  -> hit
  adding host 192.168.7.165 at ttl 0
ttl=1 probe_res=2 host=192.168.7.1
 --bing.c:740--  -> hit
  adding host 192.168.7.1 at ttl 1
Found 2 hosts
0: 0 - 192.168.7.165 (insight.lan/192.168.7.165)
1: 1 - 192.168.7.1 (gw/192.168.7.1)


 0 192.168.7.1650.004 ms, 1.000/2 ,  80.0%,   
0.0%
 |   8361.29Kb/s, 845.78 us (  884 bytes), 1.000/2
 | 11.78Mb/s,   1.50 ms ( 2216 bytes)
 1 192.168.7.1  1.509 ms, 0.981/7 ,  30.0%,   
0.0%

Round 1 hinvalid:  11 (55.0%), linvalid:   0 (0.0%), redo:   0 (0.0%), total:   
11 (55.0%)
RTT status for method 0
0: (  0.008) (  0.008) (  0.014) (  0.033) (  0.010) (  0.009) (  0.009)
0.008  (  0.013)0.009  
1:1.747 1.901  (  2.531) (  2.996)2.463 2.546 2.808 
3.196  (  4.566)3.817  
Host level regression errors for method 0
0: - - - - - - -   
-0. -   -0. 
1:0.11310.0480 - -   -0.0513   -0.1874   -0.1459
0.0217 -0.2018 
Link level rtt differences for method 0
1: - - - - - - -
3.1880 -3.8080 
Link level regression errors for method 0
1: - - - - - - -   
-0. -   -0. 


 0 192.168.7.1650.004 ms, 1.000/2 ,  80.0%,   
0.0%
 |   .-- b/s, ---.-- ms (- bytes), -.---/--
 | 13.38Mb/s,   1.54 ms ( 2573 bytes)
 1 192.168.7.1  1.543 ms, 0.938/8 ,  20.0%,   
0.0%

Round 2 hinvalid:  10 (50.0%), linvalid:   0 (0.0%), redo:   0 (0.0%), total:   
10 (50.0%)
RTT status for method 0
0: (  0.008) (  0.008) (  0.014) (  0.033) (  0.010) (  0.009) (  0.009)
0.008  (  0.013)0.009  
1:1.747 1.901 1.981 2.180 2.463 2.546  (  2.808) (  
3.196)2.792 3.817  
Host level regression errors for method 0
0: - - - - - - -   
-0. -   -0. 
1:0.09400.0550   -0.0592   -0.05450.0343   -0.0757 - 
-   -0.41240.4184 
Link level rtt differences for method 0
1: - - - - - - - 
- -3.8080 
Link level regression errors for method 0
1: - - - - - - - 
- - - 


 0 192.168.7.1650.004 ms, 1.000/2 ,  80.0%,   
0.0%
 |   4133.97Kb/s, ---.-- ms (- bytes), 1.000/2
 | 14.50Mb/s,   1.56 ms ( 2831 bytes)
 1 192.168.7.1  1.566 ms, 0.910/9 ,  10.0%,   
0.0%

Round 3 hinvalid:   9 (45.0%), linvalid:   0 (0.0%), redo:   0 (0.0%), total:   
 9 (45.0%)
RTT status for method 0
0: (  0.008) (  0.008) (  0.014) (  0.033) (  0.010) (  0.009) (  0.009)
0.008  (  0.013)0.009  
1:1.747 1.901 1.981 2.180 2.463 2.546  (  2.602)
2.562 2.792 3.817  
Host level regression errors for method 0
0: - - - - - - -   
-0. -   -0. 
1:0.07910.0550   -0.0443   -0.02460.0792   -0.0160 -   
-0.3585   -0.30780.5379 
Link level rtt differences for method 0
1: - - - - - - -
2.5540 -3.8080 
Link level regression errors for method 0
1: - - - - - - -   
-0. -   -0. 


 0 192.168.7.1650.004 ms, 1.000/2 ,  80.0%,   
0.0%
 |   4133.97Kb/s, ---.-- ms (- bytes), 1.000/2
 | 14.85Mb/s,   1.56 ms ( 2894 bytes)
 1 192.168.7.1  1.564 ms, 0.902/9 ,  10.0%,   
0.0%

Round 4 hinvalid:   9 (45.0%), linvalid:   0 (0.0%), redo:   0 (0.0%), total:   
 9 (45.0%)
RTT status for method 0
0: (  0.008) (  0.008) (  0.014) (  0.033) (  0.010) (  0.009) (  0.009)
0.008  (  0.013)0.009  
1:1.747 1.901 1.981 2.180 2.463  (  2.546)2.515 
2.562 2.792 3.817  
Host level regression errors for method 0
0: - - - - - - -   
-0. -   -0.

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

2023-10-23 Thread Sanjoy Mahajan

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 local network).
It always fails with the error "not enough hosts were found to perform
the bandwidth analysis".

# bing localhost gw
Found 2 key hosts
0: localhost (127.0.0.1)
1: gw (192.168.7.1)
--
Using 10 data payload sizes:
44 205 367 529 691 852 1014 1176 1338 1500 
--
ttl=1 probe_res=2 host=127.0.0.1
 --bing.c:740--  -> hit
  adding host localhost at ttl 0
ttl=1 probe_res=2 host=192.168.7.1
bing: error: at ttl 1 the return path from gw went through the 192.168.7.165 
interface instead of 192.168.7.165 for the other hosts
Found 1 hosts
0: 0 - localhost (insight.lan/127.0.0.1)
bing: not enough hosts were found to perform the bandwidth analysis


-- System Information:
Debian Release: sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bing depends on:
ii  libc6  2.37-12

bing recommends no packages.

bing suggests no packages.

-- no debconf information

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

2023-02-28 Thread Sanjoy Mahajan

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 1.18.20-1 .

The bug is not a life-altering problem, but thank you for reopening it.

-Sanjoy

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

2022-12-14 Thread Sanjoy Mahajan

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>

-- System Information:
Debian Release: sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages etckeeper depends on:
ii  darcs  2.14.5-1+b1
ii  debconf [debconf-2.0]  1.5.80
ii  git1:2.38.1-1
ii  mercurial  6.3.1-2

Versions of packages etckeeper recommends:
ii  cron [cron-daemon]  3.0pl1-154

Versions of packages etckeeper suggests:
ii  sudo  1.9.11p3-2

-- Configuration Files:
/etc/etckeeper/etckeeper.conf changed:
VCS="hg"
GIT_COMMIT_OPTIONS=""
HG_COMMIT_OPTIONS=""
BZR_COMMIT_OPTIONS=""
DARCS_COMMIT_OPTIONS="-a"
HIGHLEVEL_PACKAGE_MANAGER=apt
LOWLEVEL_PACKAGE_MANAGER=dpkg
PUSH_REMOTE=""


-- debconf information:
  etckeeper/purge: true

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

2020-12-12 Thread Sanjoy Mahajan

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 remember it was in former times, strange.

It used to work.  I had always run "texdoc asymptote" and got the
current documentation, at least until asymptote 2.44.  I'm not sure when
the problem showed up, however, as I'd pinned asymptote to that version
until a week ago (due to a backwards-incompatible change in asymptote's
behavior that would have messed up my next textbook's figures).

> I will fix it.
>
> basically
>   mkdir -p /usr/share/texmf/doc/support/asymptote/
>   ln -s ../../../../doc/asymptote/asymptote.pdf 
> /usr/share/texmf/doc/support/asymptote/asymptote.pdf
>   mktexlsr /usr/share/texmf/
> should (it did here) make
>   texdoc asymptote
> bring up the correct doc.

That works here too.  Thank you.

-Sanjoy

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

2020-12-11 Thread Sanjoy Mahajan

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 useful, here's an strace output until the wrong manual is
found:

$ strace -qq -s 1000 -f -e trace=execve texdoc asymptote
execve("/usr/bin/texdoc", ["texdoc", "asymptote"], 0x7ffe75400b18 /* 44 vars 
*/) = 0
execve("/home/sanjoy/bin/texlua", ["texlua", "/usr/bin/texdoc", "asymptote"], 
0x7fff446f0010 /* 44 vars */) = -1 ENOENT (No such file or directory)
execve("/usr/local/bin/texlua", ["texlua", "/usr/bin/texdoc", "asymptote"], 
0x7fff446f0010 /* 44 vars */) = -1 ENOENT (No such file or directory)
execve("/usr/bin/texlua", ["texlua", "/usr/bin/texdoc", "asymptote"], 
0x7fff446f0010 /* 44 vars */) = 0
[pid 775048] execve("/bin/sh", ["sh", "-c", "which realpath >/dev/null 2>&1"], 
0x55e1019b97c0 /* 52 vars */) = 0
[pid 775049] execve("/usr/bin/which", ["which", "realpath"], 0x563ab7e94e98 /* 
52 vars */) = 0
[pid 775048] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=775049, 
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=775048, si_uid=1000, 
si_status=0, si_utime=0, si_stime=0} ---
[pid 775050] execve("/bin/sh", ["sh", "-c", "realpath '/usr/bin/texdoc'"], 
0x55e1019b97c0 /* 52 vars */) = 0
[pid 775051] execve("/usr/bin/realpath", ["realpath", "/usr/bin/texdoc"], 
0x55d2f1e08e98 /* 52 vars */) = 0
[pid 775050] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=775051, 
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=775050, si_uid=1000, 
si_status=0, si_utime=0, si_stime=0} ---
[pid 775052] execve("/bin/sh", ["sh", "-c", "(xdg-open 
\"/usr/share/texlive/texmf-dist/doc/support/asymptote-manual-zh-cn/asymptote-manual-zh-cn.pdf\")
 &"], 0x55e1019b97c0 /* 52 vars */) = 0
[pid 775047] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=775052, 
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[pid 775053] execve("/usr/bin/xdg-open", ["xdg-open", 
"/usr/share/texlive/texmf-dist/doc/support/asymptote-manual-zh-cn/asymptote-manual-zh-cn.pdf"],
 0x561e70330128 /* 52 vars */) = 0

[and so on]


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 3432 Dec  9 19:31 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jun  8  2020 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Sep 26 16:41 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Sep 26 16:41 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r-

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

2020-01-06 Thread Sanjoy Mahajan

> 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
was simply just upstream doing funny stuff with filenames.)

-Sanjoy

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

2020-01-05 Thread Sanjoy Mahajan

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
),

but the newer elpa-org 9.3 does not
(see the list at
From poking around in the upstream org-mode git repo, it seems that the
upstream file is now called ./contrib/lisp/ol-notmuch.el (i.e. with
"ol-" instead of "org-" as the filename prefix).  Alas, my git skills
are too weak to say for sure.

Because of the (possible) name change, the -notmuch.el file didn't make
it into the current Debian package?

-Sanjoy


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-org depends on:
ii  dh-elpa-helper  2.0.2
ii  elpa-htmlize1.55-1
ii  emacsen-common  3.0.4

Versions of packages elpa-org recommends:
ii  emacs  1:26.1+1-4
ii  emacs-gtk [emacs]  1:26.1+1-4

Versions of packages elpa-org suggests:
pn  ditaa  
pn  org-mode-doc   
ii  texinfo6.7.0.dfsg.2-5
ii  texlive-fonts-recommended  2019.20191208-4
ii  texlive-latex-extra2019.20191208-1

-- no debconf information

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

2020-01-03 Thread Sanjoy Mahajan

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)

2019-09-06 Thread Sanjoy Mahajan

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 printer
that I usually use.  601lab, however, is the first one in nthe CUPS list
(due perhaps to the ASCII ordering) and in the list given in the Firefox
print dialog.  If I print (e.g. with ctrl-P), I'm offered 601lab as the
highlighted choice.  I then scroll down to lj400, hit return twice, and
it prints to lj400.  So far, so good.

But when I print again, I'm still offered 601lab as the highlighted
default.  According to the Mozilla support pages, Firefox should
remember the last printer used -- and it used to do so until maybe one
or two updates ago: I've had this problem with Firefox 68 and 69 at
least, and maybe earlier.

Also as recommended in the Mozilla support pages, I tried resetting the
print_printer setting in about:config and also setting it to lj400.
Neither approach worked.  Rather, as soon as I typed ctrl-P, the setting
reverted to 601lab in front of my eyes (I tried to print the
about:config page with the print_printer line).  And then the print
dialog appeared with 601lab highlighted.

The same change happened if I tried to print another tab.  I couldn't
see the print_printer setting change in front of my eyes, but, when I
returned to the about:config tab, the setting had indeed changed to
601lab.

I could also reproduce the problem starting Firefox with a fresh
profile.  Thus, I think that the behavior is a bug.

-Sanjoy


-- Package-specific info:

-- Extensions information
Name: Adblock Plus - free ad blocker
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled

Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Status: user-disabled

Name: Default theme
Location: /usr/lib/firefox/omni.ja
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled

Name: eBay
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled

Name: Firebug
Location: /usr/share/xul-ext/firebug
Status: app-disabled

Name: Firefox Monitor
Location: /usr/lib/firefox/browser/features/fxmoni...@mozilla.org.xpi
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Status: enabled

Name: Flash Block (Plus)
Location: ${PROFILE_EXTENSIONS}/jid1-n8wh2cbfc2q...@jetpack.xpi
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Status: enabled

Name: Ghostery  Privacy Ad Blocker
Location: ${PROFILE_EXTENSIONS}/fire...@ghostery.com.xpi
Status: user-disabled

Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled

Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Status: user-disabled

Name: Twitter
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled

Name: Web Compat
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Status: enabled

Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox/browser/omni.ja
Status: enabled

-- Plugins information

-- Addons package information

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox depends on:
ii  debianutils   4.8.6.3
ii  fontconfig2.13.1-2+b1
ii  libasound21.1.8-1
ii  libatk1.0-0   2.33.3+really2.32.0-4
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.9.1-4
ii  libgcc1   1:9.2.1-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0

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

2019-01-16 Thread Sanjoy Mahajan

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. by "command 2> filename", and sometimes inserts a
space between the fd and the ">".

Here is a minimal example.

  $ emacs -q -nw
  M-x shell
  echo 2> /dev/null
  !echo
  M-p [to get the previous command in the history]

and the *shell* buffer looks like:

  $ echo 2> /dev/null

  $ !echo
  echo 2> /dev/null   [so far, so good]

  $ echo 2 > /dev/null  [that spells trouble!]

The problem is the space inserted between the "2" and the ">", which of
course changes the meaning of the command.

-Sanjoy

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-el depends on:
ii  emacs-common  1:26.1+1-3

emacs-el recommends no packages.

emacs-el suggests no packages.

-- no debconf information

Bug#867035: context: fatal file format error

2018-11-27 Thread Sanjoy Mahajan

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

2018-10-31 Thread Sanjoy Mahajan

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 Emacs modeline (I'm using 25.2.2) you'll see "(TeX)" --
i.e. plain TeX rather than ConTeXt.

A workaround is to load context.el by hand:

  M-: (load "context")
  C-x C-v test.tex

Now the modeline correctly shows "(ConTeXt-en/P)"

-Sanjoy

-- Package-specific info:

Content of '/usr/share/emacs/site-lisp/auctex'

e2418263a7bd30d35d13116faef63f95  /usr/share/emacs/site-lisp/auctex/bib-cite.el
87b6a5b269a26c1a0f522ba3c4ec222e  /usr/share/emacs/site-lisp/auctex/context.el
5ac2595246062777c61ed4104a93cf61  
/usr/share/emacs/site-lisp/auctex/context-en.el
0a6bd12930a5771f6b89fcf16d479b08  
/usr/share/emacs/site-lisp/auctex/context-nl.el
d6f4d66582bbdd12eb0a295f87418b69  
/usr/share/emacs/site-lisp/auctex/font-latex.el
f176261b5a5511cbe1401ee72ffb8947  
/usr/share/emacs/site-lisp/auctex/images/amstex.xpm
d33121019448617a3ad3bcafdeb8db40  
/usr/share/emacs/site-lisp/auctex/images/bibtex.xpm
1a43d6438010bceb374ab0a5f2bd05a8  
/usr/share/emacs/site-lisp/auctex/images/dropdown.xpm
41f1ae0341ae2e307d92a7b8b815f868  
/usr/share/emacs/site-lisp/auctex/images/dvipdf.xpm
2e4b8669b0168f32247411be3f999437  
/usr/share/emacs/site-lisp/auctex/images/dvips.xpm
55f7600cadc3a209e94bacf6bbc42a7c  
/usr/share/emacs/site-lisp/auctex/images/error.xpm
79b958849511c67d6b13ef9f5b3673e8  
/usr/share/emacs/site-lisp/auctex/images/execbibtex.xpm
a8570e26e9f96b6f527cdbe218d6c55f  
/usr/share/emacs/site-lisp/auctex/images/execdvips.xpm
e647bc601aef2dc71b134a989df1adff  
/usr/share/emacs/site-lisp/auctex/images/execerror.xpm
4610ec6133f89ceb441c43dfee077361  
/usr/share/emacs/site-lisp/auctex/images/execpdftex.xpm
c9cd1fc9fe4fd122cbf900fae654a67b  
/usr/share/emacs/site-lisp/auctex/images/exectex.xpm
6a6b9af945d4735f048ea8e475f8d9b8  
/usr/share/emacs/site-lisp/auctex/images/execviewdvi.xpm
466466f6d1867510b058a9c184ffce5d  
/usr/share/emacs/site-lisp/auctex/images/execviewpdf.xpm
39d8ccaffb40b0c118e000f45272db05  
/usr/share/emacs/site-lisp/auctex/images/execviewps.xpm
c29ad797273fd27201a40bd939a95fe0  
/usr/share/emacs/site-lisp/auctex/images/exec.xpm
6767e2583c668dcb47495197b9e8cb65  
/usr/share/emacs/site-lisp/auctex/images/gv.xpm
ff9c61ef5148a0cacd5422d7c0d99396  
/usr/share/emacs/site-lisp/auctex/images/jumpdvi.xpm
ece6608586b591f50f20d17cdb316a1c  
/usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-off.xpm
b1f10de33dcf1b5ca9ac6155c13683a3  
/usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-on.xpm
44e35faa18ab34f3c13ac3b0082bcc47  
/usr/share/emacs/site-lisp/auctex/images/pdftex.xpm
84673eb20ac3be7bf0eb4e84e23e828f  
/usr/share/emacs/site-lisp/auctex/images/prverr16.xpm
59e6a0dddb00ab16c4209a2e4c6e283d  
/usr/share/emacs/site-lisp/auctex/images/prverr20.xpm
225929f8131bdd7b9b8207494a59619a  
/usr/share/emacs/site-lisp/auctex/images/prverr24.xpm
e1b3c9d6a6eb6fb6f096736cdfc059cf  
/usr/share/emacs/site-lisp/auctex/images/prvtex12.xpm
cc4101ee6a3ab6a1f4e9991b91b3ff0b  
/usr/share/emacs/site-lisp/auctex/images/prvtex16.xpm
d4dbe057a8d3b2facd61cf7583c1e97c  
/usr/share/emacs/site-lisp/auctex/images/prvtex20.xpm
28ac0855d853f606dd91e3cfacaa8a14  
/usr/share/emacs/site-lisp/auctex/images/prvtex24.xpm
0dac3d8eb00c902037cc5fa6a03e53e3  
/usr/share/emacs/site-lisp/auctex/images/prvtex-cap-up.xpm
6ce704103821329336489e990bc6f267  
/usr/share/emacs/site-lisp/auctex/images/prvwrk12.xpm
5607f4e8bc0eb555206e6a3542205f45  
/usr/share/emacs/site-lisp/auctex/images/prvwrk14.xpm
878a72cde3bb6f0ea6d586cff56e619c  
/usr/share/emacs/site-lisp/auctex/images/prvwrk16.xpm
41811748a97673381115957d42a6529b  
/usr/share/emacs/site-lisp/auctex/images/prvwrk20.xpm
9690511307f3693e6f28e4db93fdc58c  
/usr/share/emacs/site-lisp/auctex/images/prvwrk24.xpm
e30a80ecb0711ceb42a2ca966ad74bbb  
/usr/share/emacs/site-lisp/auctex/images/pspdf.xpm
5cc696e2c69ae401c0c223d84d013c8e  
/usr/share/emacs/site-lisp/auctex/images/sep.xpm
e975868b87770a0e1a404292a314d246  
/usr/share/emacs/site-lisp/auctex/images/spell.xpm
861fc288565e624ce8b34c1fc42e3496  
/usr/share/emacs/site-lisp/auctex/images/tex.xpm
8147722e0061799437edf36d4466e5ab  
/usr/share/emacs/site-lisp/auctex/images/viewdvi.xpm
67d7ed652615a027038610f8370ba172  
/usr/share/emacs/site-lisp/auctex/images/viewpdf.xpm
000ba76725a4fb8489916250544310c7  
/usr/share/emacs/site-lisp/auctex/images/viewps.xpm
338158cc358b16daf9b58ee54bd14bad  
/usr/share/emacs/site-lisp/auctex/images/view.xpm
2cef3e02b54c2d0100d6cc009f26eca6  /usr/share/emacs/site-lisp/auctex/latex.el
c8c776d8b945271c79bb93186d71c4a0  
/usr/share/emacs/site-lisp/auctex/multi-prompt.el
e3324dacb995c956e200d1214c0bc30e  /usr

Bug#884987: reworked patch from Redhat's bugzilla

2018-02-04 Thread Sanjoy Mahajan

> 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
+++ etc/etckeeper/pre-commit.d/20warn-problem-files	2017-08-12 10:36:13.360410731 +0200
@@ -1,19 +1,20 @@
 #!/bin/sh
 set -e
 
-exclude_internal () {
-	egrep -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
-}
+# (Note that when using this, the find expression must end with 
+# -print or -exec, else the excluded directories will actually be
+# printed!)
+NOVCS='. -path ./.git -prune -o -path ./.bzr -prune -o -path ./.hg -prune -o -path ./_darcs -prune -o'
 
 if [ "$VCS" = bzr ] || [ "$VCS" = darcs ]; then
-	special=$(find . ! -type d ! -type f ! -type l | exclude_internal) || true
-	hardlinks=$(find . -type f ! -links 1 | exclude_internal ) || true
+	special=$(find $NOVCS ! -type d ! -type f ! -type l -print) || true
+	hardlinks=$(find $NOVCS -type f ! -links 1 -print) || true
 elif [ "$VCS" = hg ]; then
-	special=$(find . ! -type d ! -type f ! -type l | exclude_internal) || true
-	hardlinks=$(find . -type f ! -links 1 -exec hg status {} \; | exclude_internal ) || true
+	special=$(find $NOVCS ! -type d ! -type f ! -type l -print) || true
+	hardlinks=$(find $NOVCS -type f ! -links 1 -exec hg status {} \; -print) || true
 elif [ "$VCS" = git ]; then
-	special=$(find . ! -type d ! -type f ! -type l -exec git ls-files --exclude-standard --cached --others {} + | exclude_internal) || true
-	hardlinks=$(find . -type f ! -links 1 -exec git ls-files --exclude-standard --cached --others {} + | exclude_internal) || true
+	special=$(find $NOVCS ! -type d ! -type f ! -type l -exec git ls-files --exclude-standard --cached --others {} + -print) || true
+	hardlinks=$(find $NOVCS -type f ! -links 1 -exec git ls-files --exclude-standard --cached --others {} + -print) || true
 else
 	special=""
 fi

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

2017-12-22 Thread Sanjoy Mahajan

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 Debian-specific problem:



But the patch there doesn't apply to the Debian
/etc/etckeeper/pre-commit.d/20warn-problem-files

-Sanjoy

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages etckeeper depends on:
ii  darcs  2.12.5-1
ii  debconf [debconf-2.0]  1.5.65
ii  git1:2.15.1-1
ii  mercurial  4.4.1-1

Versions of packages etckeeper recommends:
ii  cron [cron-daemon]  3.0pl1-128.1

Versions of packages etckeeper suggests:
ii  sudo  1.8.21p2-2

-- Configuration Files:
/etc/etckeeper/etckeeper.conf changed:
VCS="hg"
GIT_COMMIT_OPTIONS=""
HG_COMMIT_OPTIONS=""
BZR_COMMIT_OPTIONS=""
DARCS_COMMIT_OPTIONS="-a"
HIGHLEVEL_PACKAGE_MANAGER=apt
LOWLEVEL_PACKAGE_MANAGER=dpkg
PUSH_REMOTE=""


-- debconf information:
  etckeeper/purge: true

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

2017-10-30 Thread Sanjoy Mahajan

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 2710:



> I reckon page management is more the province of the pdftopdf filter
> than the hpcups driver. Anyway, I set up a print queue and did (as
> root) on unstable:
>
>  cupsfilter -p /etc/cups/ppd/2700.ppd -m application/vnd.cups-pdf 
> /etc/services > test.pdf
>
> with *DefaultOutputOrder: "reverse" in the PPD. The PDF shows the pages
> in reverse order. Perhaps you could actually print some small file to
> the printer, which I cannot do, to test this observation.

I wrote "was" above, because in the intervening years I gave away the
PSC 2710 (and now use a USB scanning stick for that functionality).  So,
I am in the same boat as you are.

-Sanjoy

Bug#877888: closed by Brian Potkin (Re: Bug#877888: cups-bsd: lpq and lp ignore the PRINTER environment variable)

2017-10-15 Thread Sanjoy Mahajan

> 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 commit?



-Sanjoy

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

2017-10-14 Thread Sanjoy Mahajan

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 reproduced your results.  Below is the log.  The only difference
from yours is that my usual printer is called lj400 instead of pcl.  All
tests were run as a regular user starting from no /etc/cups/lpoptions or
~/.cups/lpoptions (restarting cups after moving /etc/cups/lpoptions to
/etc/cups/lpoptions.bak, just in case).

  $ lpstat -a
  lj400 accepting requests since Fri 13 Oct 2017 09:49:03 PM EDT
  [and many others listed]

  $ lpq
  lpq: Error - no default destination available.

  $ PRINTER=lj400 lpq
  lpq: Error - PRINTER environment variable names non-existent destination 
"lj400".

  $ lpq -Plj400
  lj400 is ready
  no entries

  $ PRINTER=lj400 lp /etc/nsswitch.conf 
  lp: Error - scheduler not responding.

  $ lpoptions -d lj400
  [options displayed]

  $ lpq
  lpq: Error - no default destination available.

  $ PRINTER=xxx lpq
  lpq: Error - PRINTER environment variable names non-existent destination 
"xxx".

  $ lpq -Plj400
  lj400 is ready
  no entries

  $ PRINTER=lj400 lp /etc/nsswitch.conf
  lp: Error - scheduler not responding.

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

2017-10-06 Thread Sanjoy Mahajan

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:

  $ lpq 
  lj400 is ready  /* my default destination */
  no entries
  $ PRINTER=mh371 printenv PRINTER 
  mh371   /* to show that the environment variable inherits */
  $ PRINTER=mh371 lpq
  lj400 is ready  /* but lpq ignores it */
  no entries
  $ lpq -Pmh371
  mh371 is ready  /* to show that mh371 is a known destination */
  no entries

And for lp:

  $ PRINTER=mh371 lp /usr/share/hplip/data/ps/testpage.ps.gz
  request id is lj400-2890 (1 file(s))

It went to the default destination despite the environment setting.

Here is my /etc/cups/lpoptions:

Default lj400 fitplot=true PageSize=Letter sides=two-sided-long-edge
Dest lj400/gs fitplot=true PageSize=Letter pdftops-renderer=gs 
sides=two-sided-long-edge
Dest mh235 fitplot=true PageSize=Letter sides=two-sided-long-edge
Dest mh271 fitplot=true PageSize=Letter sides=two-sided-long-edge
Dest mh271/duplex fitplot=true PageSize=Letter sides=two-sided-long-edge
Dest mh271/saver fitplot=true number-up=2 PageSize=Letter 
sides=two-sided-long-edge
Dest mh371 PageSize=Letter sides=two-sided-long-edge
Dest mitx duplex=duplexnotumble
Dest psc outputorder=reverse PageSize=Letter PrintoutMode=High

-Sanjoy

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups-bsd depends on:
ii  cups-client  2.2.4-7
ii  cups-common  2.2.4-7
ii  debconf  1.5.63
ii  libc62.24-17
ii  libcups2 2.2.4-7

cups-bsd recommends no packages.

Versions of packages cups-bsd suggests:
ii  cups  2.2.4-7
ii  update-inetd  4.44

-- debconf information:
  cups-bsd/setuplpd: false

--

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

2017-07-13 Thread Sanjoy Mahajan

On 2017-03-02 09:28, Sanjoy Mahajan  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, which work
fine) and even then only on amd64 (i386 is fine, even with twm/ctwm).

-Sanjoy

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

2017-03-02 Thread Sanjoy Mahajan

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/
$ chromium --user-data-dir=/tmp/chrome-debug &

Once chromium starts, I visit /tmp/dropdowntest.html (attached) by
typing /tmp/dropdowntest.html into the url bar.

It displays fine (see attached screenshot).  However, clicking on the
menu button ("Fresh Milk") does not bring forth the menu.  Instead, the
slightly gray color of the lower half of the button icon moves to the
upper half (while the mouse button is held down).  But the selection
remains "Fresh Milk."  By using the up- and down-arrow keys, I can
select a different item ("Old Cheese", "Hot Bread").  But that's the
only way.

A similar problem is that clicking on the the three vertical dots in the
upper-right-hand corner no longer pulls down a menu (it does nothing
instead).  I can still get to the settings page by hand, using
chrome://settings/, and I can exit etc. using other chrome magic urls.

I believe that the two problems (pulldown menus and the main three-dots
menu) are similar because they started happening together, either with
chromium 55 or 54.

(I don't have a google account, so I haven't submitted an upstream bug report.)

-Sanjoy

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libavcodec-extra57   7:3.2.4-1
ii  libavformat577:3.2.4-1
ii  libavutil55  7:3.2.4-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8
ii  libdbus-1-3  1.10.16-1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.0-2
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3+b2
ii  libgcc1  1:6.3.0-6
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-1
ii  libgtk2.0-0  2.24.31-2
ii  libharfbuzz0b1.4.2-1
ii  libicu57 57.1-5
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.3.0-6
ii  libvpx4  1.6.1-2
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Title: My Page






Fresh Milk
Old Cheese
Hot Bread

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

2017-01-06 Thread Sanjoy Mahajan

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}

\subsubsection{level 4}

\stoptext
 cut here -

To reproduce the problem:

0. emacs -q
1. C-x C-f test.tex
2. M-x outline-minor-mode
3. C-c @ C-t

The problem: The subsubsection (level 4) is not visible (see
screenshot), even though it is listed in the buffer-local variable
'ConTeXt-section-list', which has the value

(("part" 0)
 ("chapter" 1)
 ("section" 2)
 ("subsection" 3)
 ("subsubsection" 4)
 ("title" 1)
 ("subject" 2)
 ("subsubject" 3)
 ("subsubsubject" 4))

If I lie to auctex by forcing it to use latex mode (and then outline
minor mode), the subsubsection is visible in the outline.

-- Package-specific info:

Content of '/usr/share/emacs/site-lisp/auctex'

72956085188f8e07e615bfdf1cbff3de  /usr/share/emacs/site-lisp/auctex/bib-cite.el
b291b23d4f921c96526273da63c9f4c3  /usr/share/emacs/site-lisp/auctex/context.el
5ac2595246062777c61ed4104a93cf61  
/usr/share/emacs/site-lisp/auctex/context-en.el
0a6bd12930a5771f6b89fcf16d479b08  
/usr/share/emacs/site-lisp/auctex/context-nl.el
b44150a1be5adae6194605374a8c8174  
/usr/share/emacs/site-lisp/auctex/font-latex.el
f176261b5a5511cbe1401ee72ffb8947  
/usr/share/emacs/site-lisp/auctex/images/amstex.xpm
d33121019448617a3ad3bcafdeb8db40  
/usr/share/emacs/site-lisp/auctex/images/bibtex.xpm
1a43d6438010bceb374ab0a5f2bd05a8  
/usr/share/emacs/site-lisp/auctex/images/dropdown.xpm
41f1ae0341ae2e307d92a7b8b815f868  
/usr/share/emacs/site-lisp/auctex/images/dvipdf.xpm
2e4b8669b0168f32247411be3f999437  
/usr/share/emacs/site-lisp/auctex/images/dvips.xpm
55f7600cadc3a209e94bacf6bbc42a7c  
/usr/share/emacs/site-lisp/auctex/images/error.xpm
79b958849511c67d6b13ef9f5b3673e8  
/usr/share/emacs/site-lisp/auctex/images/execbibtex.xpm
a8570e26e9f96b6f527cdbe218d6c55f  
/usr/share/emacs/site-lisp/auctex/images/execdvips.xpm
e647bc601aef2dc71b134a989df1adff  
/usr/share/emacs/site-lisp/auctex/images/execerror.xpm
4610ec6133f89ceb441c43dfee077361  
/usr/share/emacs/site-lisp/auctex/images/execpdftex.xpm
c9cd1fc9fe4fd122cbf900fae654a67b  
/usr/share/emacs/site-lisp/auctex/images/exectex.xpm
6a6b9af945d4735f048ea8e475f8d9b8  
/usr/share/emacs/site-lisp/auctex/images/execviewdvi.xpm
466466f6d1867510b058a9c184ffce5d  
/usr/share/emacs/site-lisp/auctex/images/execviewpdf.xpm
39d8ccaffb40b0c118e000f45272db05  
/usr/share/emacs/site-lisp/auctex/images/execviewps.xpm
c29ad797273fd27201a40bd939a95fe0  
/usr/share/emacs/site-lisp/auctex/images/exec.xpm
6767e2583c668dcb47495197b9e8cb65  
/usr/share/emacs/site-lisp/auctex/images/gv.xpm
ff9c61ef5148a0cacd5422d7c0d99396  
/usr/share/emacs/site-lisp/auctex/images/jumpdvi.xpm
ece6608586b591f50f20d17cdb316a1c  
/usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-off.xpm
b1f10de33dcf1b5ca9ac6155c13683a3  
/usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-on.xpm
44e35faa18ab34f3c13ac3b0082bcc47  
/usr/share/emacs/site-lisp/auctex/images/pdftex.xpm
84673eb20ac3be7bf0eb4e84e23e828f  
/usr/share/emacs/site-lisp/auctex/images/prverr16.xpm
59e6a0dddb00ab16c4209a2e4c6e283d  
/usr/share/emacs/site-lisp/auctex/images/prverr20.xpm
225929f8131bdd7b9b8207494a59619a  
/usr/share/emacs/site-lisp/auctex/images/prverr24.xpm
e1b3c9d6a6eb6fb6f096736cdfc059cf  
/usr/share/emacs/site-lisp/auctex/images/prvtex12.xpm
cc4101ee6a3ab6a1f4e9991b91b3ff0b  
/usr/share/emacs/site-lisp/auctex/images/prvtex16.xpm
d4dbe057a8d3b2facd61cf7583c1e97c  
/usr/share/emacs/site-lisp/auctex/images/prvtex20.xpm
28ac0855d853f606dd91e3cfacaa8a14  
/usr/share/emacs/site-lisp/auctex/images/prvtex24.xpm
0dac3d8eb00c902037cc5fa6a03e53e3  
/usr/share/emacs/site-lisp/auctex/images/prvtex-cap-up.xpm
6ce704103821329336489e990bc6f267  
/usr/share/emacs/site-lisp/auctex/images/prvwrk12.xpm
5607f4e8bc0eb555206e6a3542205f45  
/usr/share/emacs/site-lisp/auctex/images/prvwrk14.xpm
878a72cde3bb6f0ea6d586cff56e619c  
/usr/share/emacs/site-lisp/auctex/images/prvwrk16.xpm
41811748a97673381115957d42a6529b  
/usr/share/emacs/site-lisp/auctex/images/prvwrk20.xpm
9690511307f3693e6f28e4db93fdc58c  
/usr/share/emacs/site-lisp/auctex/images/prvwrk24.xpm
e30a80ecb0711ceb42a2ca966ad74bbb  
/usr/share/emacs/site-lisp/auctex/images/pspdf.xpm
5cc696e2c69ae401c0c223d84d013c8e  
/usr/share/emacs/site-lisp/auctex/images/sep.xpm
e975868b87770a0e1a404292a314d246  
/usr/share/emacs/site-lisp/auctex/images/spell.xpm
861fc288565e624ce8b34c1fc42e3496  
/usr/share/emacs/site-lisp/auctex/images/tex.xpm
8147722e0061799437edf36d4466e5ab  
/usr/share/emacs/site-lisp/auctex/images/viewdvi.xpm
67d7ed652615a027038610f8370ba172  
/usr/share/emacs/site-lisp/auctex/images/viewpdf.xpm

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

2016-08-31 Thread Sanjoy Mahajan

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);
  dot("A", (0.5,0.5));

run through

$ asy -k -vvv -noprc -render=0 -f pdf -tex pdflatex -V -wait "test"

Without the typeset text (the "A"), it works fine, as it does using the
latex engine ("-tex latex").

This problem, I have found, has been reported on the asymptote bug
tracker and extensively discussed.  It seems that a change in the
graphicx package caused the problem.

See the discussion here:



The fix is linked from there and is:



For Debian, it just means patching plain.asy (adding a few lines).

That patch also fixes another problem with using asymptote and TL 2016:
that luatex 0.95 (and hence lualatex), which is in TL 2016, uses
\page(height|width) rather than \pdfpage(height|width), which the older
luatexs accepted.

To see that problem, try

$ asy -k -vvv -noprc -render=0 -f pdf -tex lualatex -V -wait "test"

and you get complaints about those commands being undefined.

The patch works for me, at least in my limited testing so far.

-Sanjoy


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages asymptote depends on:
ii  freeglut3 2.8.1-3
ii  ghostscript   9.19~dfsg-2
ii  imagemagick   8:6.8.9.9-7.2
ii  install-info  6.1.0.dfsg.1-8
ii  libc6 2.23-5
ii  libfftw3-double3  3.3.4-2+b1
ii  libgc1c2  1:7.4.2-8
ii  libgcc1   1:6.1.1-11
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgsl2   2.1+dfsg-2
ii  libncurses5   6.0+20160625-1
ii  libosmesa611.2.2-1
ii  libreadline6  6.3-8+b4
ii  libsigsegv2   2.10-5
ii  libstdc++66.1.1-11
ii  libtinfo5 6.0+20160625-1
ii  python2.7.11-2
ii  python-pil3.3.0-1
ii  python-pil.imagetk3.3.0-1
ii  tex-common6.05
ii  texlive-binaries  2016.20160513.41080-6
ii  texlive-latex-base2016.20160819-2
ii  texlive-pstricks  2016.20160819-1
ii  xdg-utils 1.1.1-1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages asymptote recommends:
ii  asymptote-doc  2.38-1

Versions of packages asymptote suggests:
ii  evince [pdf-viewer]   3.20.1-1
ii  gv [pdf-viewer]   1:3.7.4-1
ii  mupdf [pdf-viewer]1.9a+ds1-1.2
ii  okular [pdf-viewer]   4:16.04.2-1
ii  xpdf [pdf-viewer] 3.04-1+b1
ii  zathura-pdf-poppler [pdf-viewer]  0.2.6-1

-- no debconf information

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

2016-06-08 Thread Sanjoy Mahajan

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 drain.

Thus, could the apt.systemd.daily script incorporate an option like
"DownloadEvenOnBatteryPower" (false by default)?  For now, I comment out
the two checks as shown in the following diff.  But whenever the script
is updated upstream, I lose my change.

--- /usr/lib/apt/apt.systemd.daily  2016-05-11 10:48:22.0 -0400
+++ /usr/lib/apt/apt.systemd.daily  2016-06-08 11:29:04.117437843 -0400
@@ -357,7 +357,7 @@
 set -x
 fi
 
-check_power || exit 0
+# check_power || exit 0
 
 # check if we can lock the cache and if the cache is clean
 if which apt-get >/dev/null 2>&1 && ! eval apt-get check $XAPTOPT $XSTDERR ; 
then
@@ -410,7 +410,7 @@
 do_cache_backup $BackupArchiveInterval
 
 # ensure we don't do this on battery
-check_power || exit 0
+# check_power || exit 0
 
 # include default system language so that "apt-get update" will
 # fetch the right translated package descriptions


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.114
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.20-6
ii  gnupg2  2.1.11-7
ii  gpgv1.4.20-6
ii  init-system-helpers 1.34
ii  libapt-pkg5.0   1.2.12
ii  libc6   2.22-9
ii  libgcc1 1:6.1.1-4
ii  libstdc++6  6.1.1-4

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.7.5-3
ii  dpkg-dev1.18.7
ii  python-apt  1.1.0~beta2
ii  synaptic0.83+b1

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/apt/apt.systemd.daily (from apt package)

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

2016-05-07 Thread Sanjoy Mahajan

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 after taking minimum number of measurement(s) with 
battery only 
 [etc.]

The following seemed to fix it:

# cd /var/cache/powertop
# ln -s saved_results.powertop saved_parameters.powertop

Now running powertop doesn't produce the warning:

  # powertop
  Loaded 102 prior measurements
  RAPL device for cpu 0
  [etc.]

-Sanjoy

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages powertop depends on:
ii  libc6 2.22-7
ii  libgcc1   1:5.3.1-14
ii  libncurses5   6.0+20160319-1
ii  libncursesw5  6.0+20160319-1
ii  libnl-3-200   3.2.27-1
ii  libnl-genl-3-200  3.2.27-1
ii  libpci3   1:3.3.1-1.1
ii  libstdc++65.3.1-14
ii  libtinfo5 6.0+20160319-1

powertop recommends no packages.

Versions of packages powertop suggests:
pn  cpufrequtils   
ii  laptop-mode-tools  1.69.2-1

-- no debconf information

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

2016-02-25 Thread Sanjoy Mahajan

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 under the GNU Public License. See the file COPYING.
  Dedicated to the memory of William Schelter.
  The function bug_report() provides bug reporting information.
  (%i1) ??binomial;

   0: binomial  (Combinatorial Functions)
   ... [stuff snipped]
   18: var_negative_binomial  (Functions and Variables for discrete 
distributions)
  Enter space-separated numbers, `all' or `none': 0

  Maxima encountered a Lisp error:

   Condition in MACSYMA-TOP-LEVEL [or a callee]: INTERNAL-SIMPLE-ERROR: Cannot 
open the file /usr/share/doc/maxima/info/./maxima.info-1.

  Automatically continuing.
  To enable the Lisp debugger set *debugger-hook* to nil.

The info files are actually in /usr/share/info

  $ ls /usr/share/info/maxima*
  /usr/share/info/maxima.info-1.gz  /usr/share/info/maxima.info-3.gz
  /usr/share/info/maxima.info-2.gz  /usr/share/info/maxima.info.gz

and are put there by maxima-doc:

  $ dpkg -S /usr/share/info/maxima.info-1.gz 
  maxima-doc: /usr/share/info/maxima.info-1.gz

Making symlinks fixes it:

  # cd /usr/share/doc/maxima/info
  # ln -s /usr/share/info/maxima.info-1.gz
  etc.

-Sanjoy


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages maxima depends on:
ii  libc6 2.21-9
ii  libgmp10  2:6.1.0+dfsg-2
ii  libreadline6  6.3-8+b4
ii  libx11-6  2:1.6.3-1

Versions of packages maxima recommends:
ii  gnuplot-x11   4.6.6-3
ii  maxima-share  5.37.3-1

Versions of packages maxima suggests:
ii  maxima-doc5.37.3-1
ii  maxima-emacs  5.37.3-1
pn  texmacs   
ii  tk [wish] 8.6.0+9
pn  xmaxima   

-- no debconf information

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

2015-12-13 Thread Sanjoy Mahajan

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 already existed as a subdirectory of / (on the /
partition).

> Please also attach /etc/default/tmpfs

# Configuration for tmpfs filesystems mounted in early boot, before
# filesystems from /etc/fstab are mounted.  For information about
# these variables see the tmpfs(5) manual page.

# /run is always mounted as a tmpfs on systems which support tmpfs
# mounts.

# mount /run/lock as a tmpfs (separately from /run).  Defaults to yes;
# set to no to disable (/run/lock will then be part of the /run tmpfs,
# if available).
#RAMLOCK=yes

# mount /run/shm as a tmpfs (separately from /run).  Defaults to yes;
# set to no to disable (/run/shm will then be part of the /run tmpfs,
# if available).
#RAMSHM=yes

# mount /tmp as a tmpfs.  Defaults to no; set to yes to enable (/tmp
# will be part of the root filesystem if disabled).  /tmp may also be
# configured to be a separate mount in /etc/fstab.
RAMTMP=yes

# Size limits.  Please see tmpfs(5) for details on how to configure
# tmpfs size limits.
#TMPFS_SIZE=20%VM
#RUN_SIZE=10%
#LOCK_SIZE=5242880 # 5MiB
#SHM_SIZE=
#TMP_SIZE=

# Mount tmpfs on /tmp if there is less than the limit size (in kiB) on
# the root filesystem (overriding RAMTMP).
#TMP_OVERFLOW_LIMIT=1024

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

2015-12-13 Thread Sanjoy Mahajan

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 beginning (according to etckeeper),
although I might well have modified it just before installing etckeeper.

> This setting was migrated when systemd was installed.
> Are you saying this setting was incorrectly migrated?

No.

> Can you attach your /etc/default/rcS?

Here it is:

#
# /etc/default/rcS
#
# Default settings for the scripts in /etc/rcS.d/
#
# For information about these variables see the rcS(5) manual page.
#
# This file belongs to the "initscripts" package.

# delete files in /tmp during boot older than x days.
# '0' means always, -1 or 'infinite' disables the feature
TMPTIME=-1

# spawn sulogin during boot, continue normal boot if not used in 30 seconds
#SULOGIN=no

# do not allow users to log in until the boot has completed
#DELAYLOGIN=no

# be more verbose during the boot process
#VERBOSE=no

# automatically repair filesystems with inconsistencies during boot
#FSCKFIX=no

> As for your question:
> If you want to get rid of tmpfs-on-/tmp, run systemctl disable tmp.mount

Thank you.  That seems reasonable.

> and then rm /etc/tmpfiles.d/tmp.conf

That will stop any tmp cleaning, which I don't like, but is a separate
issue from getting rid of tmpfs-on-/tmp.

-Sanjoy

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

2015-12-12 Thread Sanjoy Mahajan

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'

3366a99dd44e27fa57e0bcc130c4fa1c  /usr/share/emacs/site-lisp/auctex/bib-cite.el
0cbe483d1a5567ea46a104f4f1cd7784  /usr/share/emacs/site-lisp/auctex/context.el
6674b961058a19d2ff2f15c9d6d39272  
/usr/share/emacs/site-lisp/auctex/context-en.el
f5ed983cd477814f04e4a63affd4f323  
/usr/share/emacs/site-lisp/auctex/context-nl.el
b133f33d0c97e1ac061d9e5c88774781  
/usr/share/emacs/site-lisp/auctex/font-latex.el
f176261b5a5511cbe1401ee72ffb8947  
/usr/share/emacs/site-lisp/auctex/images/amstex.xpm
d33121019448617a3ad3bcafdeb8db40  
/usr/share/emacs/site-lisp/auctex/images/bibtex.xpm
1a43d6438010bceb374ab0a5f2bd05a8  
/usr/share/emacs/site-lisp/auctex/images/dropdown.xpm
41f1ae0341ae2e307d92a7b8b815f868  
/usr/share/emacs/site-lisp/auctex/images/dvipdf.xpm
2e4b8669b0168f32247411be3f999437  
/usr/share/emacs/site-lisp/auctex/images/dvips.xpm
55f7600cadc3a209e94bacf6bbc42a7c  
/usr/share/emacs/site-lisp/auctex/images/error.xpm
79b958849511c67d6b13ef9f5b3673e8  
/usr/share/emacs/site-lisp/auctex/images/execbibtex.xpm
a8570e26e9f96b6f527cdbe218d6c55f  
/usr/share/emacs/site-lisp/auctex/images/execdvips.xpm
e647bc601aef2dc71b134a989df1adff  
/usr/share/emacs/site-lisp/auctex/images/execerror.xpm
4610ec6133f89ceb441c43dfee077361  
/usr/share/emacs/site-lisp/auctex/images/execpdftex.xpm
c9cd1fc9fe4fd122cbf900fae654a67b  
/usr/share/emacs/site-lisp/auctex/images/exectex.xpm
6a6b9af945d4735f048ea8e475f8d9b8  
/usr/share/emacs/site-lisp/auctex/images/execviewdvi.xpm
466466f6d1867510b058a9c184ffce5d  
/usr/share/emacs/site-lisp/auctex/images/execviewpdf.xpm
39d8ccaffb40b0c118e000f45272db05  
/usr/share/emacs/site-lisp/auctex/images/execviewps.xpm
c29ad797273fd27201a40bd939a95fe0  
/usr/share/emacs/site-lisp/auctex/images/exec.xpm
6767e2583c668dcb47495197b9e8cb65  
/usr/share/emacs/site-lisp/auctex/images/gv.xpm
ff9c61ef5148a0cacd5422d7c0d99396  
/usr/share/emacs/site-lisp/auctex/images/jumpdvi.xpm
ece6608586b591f50f20d17cdb316a1c  
/usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-off.xpm
b1f10de33dcf1b5ca9ac6155c13683a3  
/usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-on.xpm
44e35faa18ab34f3c13ac3b0082bcc47  
/usr/share/emacs/site-lisp/auctex/images/pdftex.xpm
84673eb20ac3be7bf0eb4e84e23e828f  
/usr/share/emacs/site-lisp/auctex/images/prverr16.xpm
59e6a0dddb00ab16c4209a2e4c6e283d  
/usr/share/emacs/site-lisp/auctex/images/prverr20.xpm
30dc2ada41625cb24ea459bd62f7386c  
/usr/share/emacs/site-lisp/auctex/images/prverr24.xbm
225929f8131bdd7b9b8207494a59619a  
/usr/share/emacs/site-lisp/auctex/images/prverr24.xpm
40feb30f80d3606f32ba54b57ba18af5  
/usr/share/emacs/site-lisp/auctex/images/prvtex12.xbm
e1b3c9d6a6eb6fb6f096736cdfc059cf  
/usr/share/emacs/site-lisp/auctex/images/prvtex12.xpm
32406fc4b893b48d2996c424f61ea238  
/usr/share/emacs/site-lisp/auctex/images/prvtex16.xbm
cc4101ee6a3ab6a1f4e9991b91b3ff0b  
/usr/share/emacs/site-lisp/auctex/images/prvtex16.xpm
d4dbe057a8d3b2facd61cf7583c1e97c  
/usr/share/emacs/site-lisp/auctex/images/prvtex20.xpm
f25ba1b984b095c9c561e5443f3d77a3  
/usr/share/emacs/site-lisp/auctex/images/prvtex24.xbm
28ac0855d853f606dd91e3cfacaa8a14  
/usr/share/emacs/site-lisp/auctex/images/prvtex24.xpm
0dac3d8eb00c902037cc5fa6a03e53e3  
/usr/share/emacs/site-lisp/auctex/images/prvtex-cap-up.xpm
6ce704103821329336489e990bc6f267  
/usr/share/emacs/site-lisp/auctex/images/prvwrk12.xpm
5607f4e8bc0eb555206e6a3542205f45  
/usr/share/emacs/site-lisp/auctex/images/prvwrk14.xpm
878a72cde3bb6f0ea6d586cff56e619c  
/usr/share/emacs/site-lisp/auctex/images/prvwrk16.xpm
41811748a97673381115957d42a6529b  
/usr/share/emacs/site-lisp/auctex/images/prvwrk20.xpm
254fc07db6a03a8a24f762135a403433  
/usr/share/emacs/site-lisp/auctex/images/prvwrk24.xbm
9690511307f3693e6f28e4db93fdc58c  
/usr/share/emacs/site-lisp/auctex/images/prvwrk24.xpm
e30a80ecb0711ceb42a2ca966ad74bbb  
/usr/share/emacs/site-lisp/auctex/images/pspdf.xpm
5cc696e2c69ae401c0c223d84d013c8e  
/usr/share/emacs/site-lisp/auctex/images/sep.xpm
861fc288565e624ce8b34c1fc42e3496  
/usr/share/emacs/site-lisp/auctex/images/tex.xpm
8147722e0061799437edf36d4466e5ab  
/usr/share/emacs/site-lisp/auctex/images/viewdvi.xpm
67d7ed652615a027038610f8370ba172  
/usr/share/emacs/site-lisp/auctex/images/viewpdf.xpm
000ba76725a4fb8489916250544310c7  
/usr/share/emacs/site-lisp/auctex/images/viewps.xpm
338158cc358b16daf9b58ee54bd14bad  
/usr/share/emacs/site-lisp/auctex/images/view.xpm
ef93273a386e6ec57dbc85d21d2476db  /usr/share/emacs/site-lisp/auctex/latex.el
d041aec17bb42693eafa65f25cbf5a7d  
/usr/share/emacs/site-lisp/auctex/multi-prompt.el
d41d8cd98f00b204e9800998ecf8427e  /usr/share/emacs/site-lisp/auctex/.nosearch
d717ca14

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

2015-12-12 Thread Sanjoy Mahajan

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 of reasonably important iceweasel-downloaded .pdf files in /tmp
suddenly disappeared.  I feared that I had misconfigured the
/etc/tmpfiles.d/tmp.conf and allowed automatic cleaning, but that file
was correct (prevented /tmp cleaning):

  # Automatically migrated from TMPTIME in /etc/default/rcS
  #d /var/tmp 1777 root root -
  d /tmp 1777 root root -

The syslog at around the time of the oldest remaining /tmp file showed
what had instead happened:

  Dec 11 07:24:57 insight dbus[671]: [system] Activating via systemd: service 
name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
  Dec 11 07:24:57 insight systemd[1]: tmp.mount: Directory /tmp to mount over 
is not empty, mounting anyway.
  Dec 11 07:24:57 insight systemd[1]: Mounting Temporary Directory...
  Dec 11 07:24:57 insight systemd[1]: Mounted Temporary Directory.
  Dec 11 07:24:57 insight systemd[1]: Starting Hostname Service...
  Dec 11 07:24:57 insight dbus[671]: [system] Successfully activated service 
'org.freedesktop.hostname1'
  Dec 11 07:24:57 insight systemd[1]: Started Hostname Service.

I had run 'hostnamectl' at around 7:24am, which activated the
org.freedesktop.hostname1 service, which then, via the 'PrivateTmp=yes'
line in dbus-org.freedesktop.hostname1.service used tmp.mount, which put
/tmp on tmpfs.

I got back my /tmp files by unmounting /tmp, so all was well.  But how
should I prevent it from happening again?  I don't want /tmp on tmpfs.
Should I just set PrivateTmp=no in that config?

I read bug #779902 and the patch in its msg #32
, but I am
still confused about whether setting it to No has other bad effects.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-2+b1
ii  libaudit1   1:2.4.4-4
ii  libblkid1   2.27.1-1
ii  libc6   2.19-22
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.4-3
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-1
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.4-3
ii  libsystemd0 228-2
ii  mount   2.27.1-1
ii  sysv-rc 2.88dsf-59.2
ii  util-linux  2.27.1-1

Versions of packages systemd recommends:
ii  dbus1.10.4-1
ii  libpam-systemd  228-2

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  228-2

-- no debconf information

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

2015-08-27 Thread Sanjoy Mahajan

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 -sOutputFile=/dev/null 
merry-go-round_.ps
  sfopen: gs_parse_file_name failed.
  sfopen: gs_parse_file_name failed.
./base/gsicc_manage.c:1084: gsicc_open_search(): Could not find 
default_gray.icc 
  | ./base/gsicc_manage.c:1690: gsicc_set_device_profile(): cannot find device 
profile
  /usr/share/asymptote/plain_Label.asy: 670.23: reading array of length 3 with 
out-of-bounds index 3

Running 'gs' as above on the intermediate .ps file produces the same
message plus the stderr (which isn't shown above), whose first line is
"Unknown device: epswrite."

In testing/unstable, ghostscript is 9.16, in which epswrite is
deprecated.  Asymptote 2.35 (the version in testing/unstable) in Debian
should therefore drop the 'old-gs-use-epswrite' patch.

-Sanjoy


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.0.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages asymptote depends on:
ii  freeglut3 2.8.1-2
ii  ghostscript   9.16~dfsg-2
ii  imagemagick   8:6.8.9.9-5
ii  install-info  6.0.0.dfsg.1-3
ii  libc6 2.19-19
ii  libfftw3-double3  3.3.4-2
ii  libgc1c2  1:7.2d-6.4
ii  libgcc1   1:5.1.1-14
ii  libgl1-mesa-glx [libgl1]  10.6.3-1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgsl0ldbl   1.16+dfsg-4
ii  libncurses5   6.0+20150810-1
ii  libosmesa610.6.3-1
ii  libreadline6  6.3-8+b3
ii  libsigsegv2   2.10-4+b1
ii  libstdc++65.1.1-14
ii  libtinfo5 6.0+20150810-1
ii  python2.7.9-1
ii  python-pil2.9.0-1
ii  python-pil.imagetk2.9.0-1
ii  tex-common6.02
ii  texlive-binaries  2015.20150524.37493-5
ii  texlive-latex-base2015.20150810-1
ii  texlive-pstricks  2015.20150810-1
ii  xdg-utils 1.1.0~rc1+git20111210-7.4
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages asymptote recommends:
ii  asymptote-doc  2.35-1

Versions of packages asymptote suggests:
ii  epdfview [pdf-viewer]  0.1.8-3
ii  evince [pdf-viewer]3.16.1-1
ii  gv [pdf-viewer]1:3.7.4-1
ii  mupdf [pdf-viewer] 1.7-1
ii  okular [pdf-viewer]4:4.14.2-3
ii  xpdf [pdf-viewer]  3.03-17+b1
ii  zathura [pdf-viewer]   0.3.3-2

-- no debconf information

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

2015-05-17 Thread Sanjoy Mahajan

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

2015-03-12 Thread Sanjoy Mahajan

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 http://www.imagemagick.org
convert:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org
composite:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org
conjure:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org
display:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org
identify:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org
import:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org
mogrify:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org
montage:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org
stream:  ImageMagick 6.8.9-9 Q16 i586 2015-01-05 http://www.imagemagick.org

'compare' now no longer terminates its output with a newline.  For
example, here's a shell transcript (captured in my Emacs shell buffer,
with $ as the shell prompt):

$ compare -metric PSNR /tmp/tmp.jzBigUzj59/{a,b}/023.png /tmp/q.png
87.1388$ compare -metric mae /tmp/tmp.jzBigUzj59/{a,b}/023.png /tmp/q.png
0.032295 (4.9279e-07)$

I expected it to look like this:

$ compare -metric PSNR /tmp/tmp.jzBigUzj59/{a,b}/023.png /tmp/q.png
87.1388
$ compare -metric mae /tmp/tmp.jzBigUzj59/{a,b}/023.png /tmp/q.png
0.032295 (4.9279e-07)
$

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.16-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages imagemagick depends on:
ii  imagemagick-6.q16  8:6.8.9.9-5

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information

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

2014-10-07 Thread Sanjoy Mahajan

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 gray semi-transparent ellipse
marking the relevant spot.

The page views fine with mupdf (v1.5) or gv (using gs 9.06).  It also
views fine after converting to ps with pdftops and viewing the ps with gv.

-Sanjoy



missing-fi.pdf
Description: file showing missing "fi"



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.14-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xpdf depends on:
ii  libc6 2.19-11
ii  libgcc1   1:4.9.1-16
ii  libpoppler46  0.26.5-1
ii  libstdc++64.9.1-16
ii  libx11-6  2:1.6.2-3
ii  libxm42.3.4-5+b1
ii  libxt61:1.1.4-1

Versions of packages xpdf recommends:
ii  cups-bsd   1.7.5-1
ii  gsfonts-x110.22
ii  poppler-data   0.4.7-1
ii  poppler-utils  0.26.5-1

xpdf suggests no packages.

-- no debconf information

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

2014-05-15 Thread Sanjoy Mahajan

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) ...
  ERROR: auctex is broken - called emacs-package-install as a new-style add-on, 
but has no compat file.
  ...

(11.87-1.1 is just 11.87-1 + the patch)

-Sanjoy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#640515: printing works with 3.03-16

2014-01-27 Thread Sanjoy Mahajan

Sanjoy Mahajan  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 the
patch mentioned above (I am on i386).  Maybe this bug can be closed?

-Sanjoy

-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2014-01-20 Thread Sanjoy Mahajan

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:

https://sourceforge.net/p/maxima/bugs/2680/

-Sanjoy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2014-01-13 Thread Sanjoy Mahajan

> 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2014-01-12 Thread Sanjoy Mahajan

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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2014-01-04 Thread Sanjoy Mahajan

> 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.  I did the above steps but with emacs replaced by emacs23, which is
emacs 23.4.1 (from 23.4+1-4.1+b1).

-Sanjoy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2013-12-30 Thread Sanjoy Mahajan

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 --
% b/a.d
msucle
imaginging
--- cut here --

However, with the following slightly modified file, it does find the
errors:

--- cut here --
%   a.d
msucle
imaginging
--- cut here --

I ran both of them with "M-x ispell-buffer-with-debug", and am including
the diff between the respective *ispell-debug* buffers at the end of
this message.  The base file (first file in the diff) is the one that
works, and the second file is the one that fails.

The first diff is this line:

+ispell-region: First skip: /a.d at (pos,line,column): (4,1,3).

Thus, with the failing file, it spots a comment, skips over some stuff,
and then (as you can see later in the diff), keeps commenting out the
remaining lines.

With the working file, it doesn't spot the comment, and then finds the
spelling errors.  I think that's actually a second bug.  I put the point
at the beginning of the working file, and executed "(re-search-forward
(ispell-begin-skip-region-regexp)" and it did not match.  But it matched
using the failing file.  

I suspect that with the failing file, it (correctly) matches the
comment, and then incorrectly thinks that the rest of the file is
comments.  In the working file, it (incorrectly) fails to match, but
then does not conclude that the rest of the file is comments, so it
finds the spelling mistakes.

If I start emacs with "emacs -Q -nw", then the bug doesn't happen.  So,
it is a problem with the dictionaries-common version of ispell.el, in
comparison to the regular Emacs 24.3.1 version of ispell.el

I suspect the problem is in ispell-region() but cannot figure out where.

Despite the following information in
/usr/share/doc/dictionaries-common/README.emacs.gz

  Force disabling of dictionaries-common emacsen-stuff
  

  If you want to always use original {ispell,flyspell}.el instead of
  those provided by Debian dictionaries-common you should edit the
  file

  /etc/emacs/site-start.d/50dictionaries-common.el

  and add your flavor to the `skip-emacs-flavors-list' list.

I couldn't convince "emacs -q -nw" to load the generic ispell even after
I added "emacs24" to the "skip-emacs-flavors-list" list.  The startup
message showed that it was skipping the dictionaries-common stuff for my
flavor, but somehow it was still on the load path (and I cannot figure
out how).

-Sanjoy


diff -U0 simple-ok-ispell-buffer.log simple-ispell-debug-buffer.log
--- simple-ok-ispell-buffer.log 2013-12-30 15:57:21.434713562 -0500
+++ simple-ispell-debug-buffer.log  2013-12-30 15:53:41.630979165 -0500
@@ -30,0 +31 @@
+ispell-region: First skip: /a.d at (pos,line,column): (4,1,3).
@@ -32 +33 @@
-ispell-region: string pos (1->8), eol: 8, [in-comment]: [nil], [add-comment]: 
[nil], [string]: [^%   a.d
+ispell-region: string pos (1->4), eol: 8, [in-comment]: [nil], [add-comment]: 
[nil], [string]: [^% b
@@ -34,2 +35,2 @@
-ispell-region: string pos (8->8), eol: 15, [in-comment]: [nil], [add-comment]: 
[nil], [string]: [nil]
-ispell-region: string pos (9->15), eol: 15, [in-comment]: [nil], 
[add-comment]: [nil], [string]: [^msucle
+ispell-region: string pos (8->8), eol: 15, [in-comment]: [%], [add-comment]: 
[%], [string]: [nil]
+ispell-region: string pos (9->15), eol: 15, [in-comment]: [%], [add-comment]: 
[%], [string]: [^%msucle
@@ -37,2 +38,2 @@
-ispell-region: string pos (15->15), eol: 26, [in-comment]: [nil], 
[add-comment]: [nil], [string]: [nil]
-ispell-region: string pos (16->26), eol: 26, [in-comment]: [nil], 
[add-comment]: [nil], [string]: [^imaginging
+ispell-region: string pos (15->15), eol: 26, [in-comment]: [%], [add-comment]: 
[%], [string]: [nil]
+ispell-region: string pos (16->26), eol: 26, [in-comment]: [%], [add-comment]: 
[%], [string]: [^%imaginging
@@ -40 +41 @@
-ispell-region: string pos (26->26), eol: 27, [in-comment]: [nil], 
[add-comment]: [nil], [string]: [nil]
+ispell-region: string pos (26->26), eol: 27, [in-comment]: [%], [add-comment]: 
[%], [string]: [nil]



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.11-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dictionaries-common depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  libtext-iconv-perl 1.7-5+b1

dictionaries-common recommends no packages.

Versions of packages dictionaries-common suggests:
ii  emacsen-common  2.0.5
ii  ispell  3.3.02-6
pn  jed-extra   

-- debconf information:
* dictionaries-common/default-is

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

2013-12-18 Thread Sanjoy Mahajan

Jonas Smedegaard  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 bugreport - http://bugs.debian.org/723719 - tracks packaging 
> of newer upstream release.

I'll cross my fingers for a newer lcms2.

-Sanjoy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2013-12-08 Thread Sanjoy Mahajan

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
xpdf is fixed such that my daily "aptitude dist-upgrade" will somehow
know to offer to install the fixed xpdf?

-- 
-Sanjoy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2013-09-30 Thread Sanjoy Mahajan

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 > 
fig/circular-acceleration-group.dottex
  Traceback (most recent call last):
File "/usr/bin/dot2tex", line 2, in 
  from dot2tex.dot2tex import main
File "/usr/lib/pymodules/python2.7/dot2tex/__init__.py", line 36, in 

  import dot2tex as d2t
File "/usr/lib/pymodules/python2.7/dot2tex/dot2tex.py", line 47, in 
  import dotparsing
File "/usr/lib/pymodules/python2.7/dot2tex/dotparsing.py", line 26, in 

  from pyparsing import  (Literal, CaselessLiteral, Word, Upcase, 
OneOrMore, ZeroOrMore,
  ImportError: cannot import name _noncomma

See  for more on this
issue.  I fixed it with the diff below:

--- dotparsing.py   2009-10-05 07:57:02.0 -0400
+++ dotparsing.py   2013-09-30 21:20:44.0 -0400
@@ -26,7 +26,7 @@
 from pyparsing import  (Literal, CaselessLiteral, Word, Upcase, OneOrMore, 
ZeroOrMore,
 Forward, NotAny, delimitedList, oneOf, Group, Optional, Combine, alphas, 
nums,
 restOfLine, cStyleComment, nums, alphanums, printables, empty, 
quotedString,
-ParseException, ParseResults, CharsNotIn, _noncomma, dblQuotedString, 
QuotedString, ParserElement,
+ParseException, ParseResults, CharsNotIn, dblQuotedString, QuotedString, 
ParserElement,
 Suppress,Regex,removeQuotes)
 
 dot_keywords = ['graph', 'subgraph', 'digraph', 'node', 'edge', 'strict']



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.10-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dot2tex depends on:
ii  graphviz  2.26.3-15+b1
ii  python2.7.5-5
ii  python-pyparsing  2.0.1+dfsg1-1
ii  python-support1.0.15

Versions of packages dot2tex recommends:
ii  pgf  2.10-1
ii  preview-latex-style  11.87-1
ii  texlive-latex-base   2013.20130918-1
ii  texlive-pstricks 2013.20130918-1

dot2tex suggests no packages.

-- 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#719281: mupdf: man page should refer to mutool instead of mupdfclean etc.

2013-08-09 Thread Sanjoy Mahajan

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 be reloaded automatically, for use in e.g. build scripts.
 .SH SEE ALSO
-.BR mupdfclean (1),
-.BR mupdfdraw (1),
-.BR mupdfshow (1).
+.BR mutool (1),
+.BR mudraw (1).
 .SH AUTHOR
 MuPDF is Copyright 2006-2012 Artifex Software, Inc.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.9-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mupdf depends on:
ii  libc6 2.17-7
ii  libfreetype6  2.4.9-1.1
ii  libjbig2dec0  0.11+20120125-1
ii  libjpeg8  8d-1
ii  libopenjpeg2  1.3+dfsg-4.6
ii  libx11-6  2:1.6.0-1
ii  libxext6  2:1.3.2-1
ii  zlib1g1:1.2.8.dfsg-1

mupdf recommends no packages.

Versions of packages mupdf suggests:
ii  mupdf-tools  1.2-2

-- no debconf information

-- 
-Sanjoy


Save Long Wharf Park in Boston Harbor!


Six reasoning tools to make hard problems easy.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2013-06-06 Thread Sanjoy Mahajan

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]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x76ba0)[0xb6048ba0]
emacs[0x81f9185]
emacs[0x82003d4]
emacs[0x81fe7e0]
emacs[0x81feb91]
emacs[0x818fe7a]
emacs[0x81c3f0b]
emacs[0x818f9e5]
emacs[0x818ee26]
emacs[0x818f168]
emacs[0x8192041]
emacs[0x81c4905]
emacs[0x818f9e5]
emacs[0x818fcca]
emacs[0x81c3f0b]
emacs[0x818f9e5]
emacs[0x818fcca]
emacs[0x8190d63]
emacs[0x818ff17]
emacs[0x81c3f0b]
emacs[0x818f9e5]
emacs[0x818fcca]
emacs[0x8190d63]
emacs[0x818ff17]
emacs[0x81c3f0b]
emacs[0x818f9e5]
emacs[0x818fcca]
emacs[0x81c3f0b]
emacs[0x818f9e5]
emacs[0x818fcca]
emacs[0x81c3f0b]
emacs[0x818f9e5]
emacs[0x818fcca]
emacs[0x8190d63]
emacs[0x819029f]
emacs[0x81c7509]
emacs[0x818e59a]
emacs[0x81c7181]
emacs[0x81cabd9]
emacs[0x80643a5]
emacs[0x8127cda]
emacs[0x81293fa]
emacs[0x812af7e]
emacs[0x818e480]
emacs[0x8120185]
emacs[0x818e395]
emacs[0x8120e12]
emacs[0x812110a]
emacs[0x805af48]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf5)[0xb5feb8f5]
emacs[0x805bbed]
=== Memory map: 
08048000-08264000 r-xp  08:02 1861197/usr/bin/emacs24-x
08264000-08265000 r--p 0021b000 08:02 1861197/usr/bin/emacs24-x
08265000-088e6000 rw-p 0021c000 08:02 1861197/usr/bin/emacs24-x
09eab000-0b702000 rw-p  00:00 0  [heap]
b38e4000-b38e5000 rw-p  00:00 0 
b397a000-b3a3b000 rw-p  00:00 0 
b3a3b000-b3b74000 rw-p  00:00 0 
b3c84000-b3cab000 rw-p  00:00 0 
b3cdf000-b3d58000 rw-p  00:00 0 
b3da-b3e2c000 rw-p  00:00 0 
b3e66000-b3f27000 rw-p  00:00 0 
b3f2e000-b3f55000 rw-p  00:00 0 
b3f55000-b3f86000 rw-p  00:00 0 
b3f86000-b3fe8000 r--p  08:02 3441066
/usr/share/fonts/truetype/asana-math/Asana-Math.otf
b3fe8000-b42c9000 rw-p  00:00 0 
b42e1000-b438a000 r--p  08:02 3654475
/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
b438a000-b443f000 r--p  08:02 3654476
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
b443f000-b450 rw-p  00:00 0 
b450-b4521000 rw-p  00:00 0 
b4521000-b460 ---p  00:00 0 
b4609000-b4624000 r-xp  08:02 4579412
/lib/i386-linux-gnu/libgcc_s.so.1
b4624000-b4625000 rw-p 0001a000 08:02 4579412
/lib/i386-linux-gnu/libgcc_s.so.1
b4648000-b465d000 rw-p  00:00 0 
b4678000-b467d000 r-xp  08:02 4579970
/lib/i386-linux-gnu/i686/cmov/libnss_dns-2.17.so
b467d000-b467e000 r--p 4000 08:02 4579970
/lib/i386-linux-gnu/i686/cmov/libnss_dns-2.17.so
b467e000-b467f000 rw-p 5000 08:02 4579970
/lib/i386-linux-gnu/i686/cmov/libnss_dns-2.17.so
b467f000-b46ff000 rw-s  00:04 98305  /SYSV (deleted)
b46ff000-b470 ---p  00:00 0 
b470-b4f0 rw-p  00:00 0  [stack:4499]
b4f0-b4f21000 rw-p  00:00 0 
b4f21000-b500 ---p  00:00 0 
b5003000-b5005000 r-xp  08:02 4580191/lib/libnss_mdns4_minimal.so.2
b5005000-b5006000 rw-p 1000 08:02 4580191/lib/libnss_mdns4_minimal.so.2
b5006000-b502a000 rw-p  00:00 0 
b502a000-b5049000 r--s  08:02 2147369/usr/share/mime/mime.cache
b5049000-b509b000 r--p  08:02 3654478
/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
b509b000-b509c000 ---p  00:00 0 
b509c000-b589c000 rw-p  00:00 0  [stack:4498]
b589c000-b58cb000 r-xp  08:02 2033652
/usr/lib/i386-linux-gnu/libbluray.so.1.1.0
b58cb000-b58cc000 r--p 0002f000 08:02 2033652
/usr/lib/i386-linux-gnu/libbluray.so.1.1.0
b58cc000-b58cd000 rw-p 0003 08:02 2033652
/usr/lib/i386-linux-gnu/libbluray.so.1.1.0
b58cd000-b58cf000 r-xp  08:02 4580040
/lib/i386-linux-gnu/i686/cmov/libutil-2.17.so
b58cf000-b58d r--p 1000 08:02 4580040
/lib/i386-linux-gnu/i686/cmov/libutil-2.17.so
b58d-b58d1000 rw-p 2000 08:02 4580040
/lib/i386-linux-gnu/i686/cmov/libutil-2.17.so
b58d1000-b58df000 r-xp  08:02 4579821
/lib/i386-linux-gnu/libudev.so.0.13.0
b58df000-b58e r--p d000 08:02 4579821
/lib/i386-linux-gnu/libudev.so.0.13.0
b58e-b58e1000 rw-p e000 08:02 4579821
/lib/i386-linux-gnu/libudev.so.0.13.0
b58e1000-b58e3000 r-xp  08:02 2802959
/usr/lib/i386-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so (deleted)
b58e3000-b58e4000 r--p 1000 08:02 2802959
/usr/lib/i386-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so (deleted)
b58e4000-b58e5000 rw-p 2000 08:02 2802959
/usr/lib/i386-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so (deleted)
b58e5000-b58e6000 r-xp  08:02 2802916
/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so 
(deleted)
b58e6000-b58e7000 r--p 1000 08:02 2802916

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

2013-06-01 Thread Sanjoy Mahajan

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 /etc/cups/lpoptions file.

I thought that, if root uses lpoptions, those options apply to the user
ids listed in /etc/cups/lpoptions.  A few other packages that have that
kind of behavior, although I admit that it's not common.

When I looked at the lpoptions file itself, I realized what the
manpage meant.  To clarify, perhaps the man page should read:

   When run by the root user, lpoptions gets and sets default
   options and instances for all users, storing the data in the
   /etc/cups/lpoptions file.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.8-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cups depends on:
ii  adduser3.113+nmu3
ii  bc 1.06.95-6
ii  cups-client1.5.3-5
ii  cups-common1.5.3-5
ii  cups-filters   1.0.18-2.1
ii  cups-ppdc  1.5.3-5
ii  debconf [debconf-2.0]  1.5.50
ii  dpkg   1.16.10
ii  ghostscript9.05~dfsg-6.3
ii  libavahi-client3   0.6.31-2
ii  libavahi-common3   0.6.31-2
ii  libc-bin   2.17-3
ii  libc6  2.17-3
ii  libcups2   1.5.3-5
ii  libcupscgi11.5.3-5
ii  libcupsimage2  1.5.3-5
ii  libcupsmime1   1.5.3-5
ii  libcupsppdc1   1.5.3-5
ii  libdbus-1-31.6.10-1
ii  libgcc11:4.8.0-7
ii  libgnutls262.12.20-6
ii  libgssapi-krb5-2   1.10.1+dfsg-5
ii  libkrb5-3  1.10.1+dfsg-5
ii  libldap-2.4-2  2.4.31-1+nmu2
ii  libpam0g   1.1.3-9
ii  libpaper1  1.1.24+nmu2
ii  libslp11.2.1-9
ii  libstdc++6 4.8.0-7
ii  libusb-1.0-0   2:1.0.15-1
ii  lsb-base   4.1+Debian11
ii  poppler-utils  0.18.4-6
ii  procps 1:3.3.4-2
ii  ssl-cert   1.0.32

Versions of packages cups recommends:
ii  avahi-daemon   0.6.31-2
ii  colord 0.1.21-4
ii  foomatic-filters   4.0.17-1
ii  ghostscript-cups   9.05~dfsg-6.3
ii  printer-driver-gutenprint  5.2.9-1

Versions of packages cups suggests:
ii  cups-bsd   1.5.3-5
ii  cups-pdf   2.6.1-9
ii  foomatic-db20130517-1
ii  hplip  3.13.4-1
ii  printer-driver-hpcups  3.13.4-1
ii  smbclient  2:3.6.15-1
ii  udev   175-7.2

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: ipp, ipp14, lpd, socket, usb, snmp, dnssd


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2013-05-09 Thread Sanjoy Mahajan

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 Schelter.
  The function bug_report() provides bug reporting information.
  (%i1) 1000!^0.01;
  (%o1)   i.nfE+142498684

I think that it should have instead given a reasonable answer (around
10^26) or complained that the floating-point range got overflowed by
1000!.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages maxima depends on:
ii  gnuplot-x11   4.6.0-8
ii  libc6 2.13-38
ii  libgmp10  2:5.0.5+dfsg-2
ii  libreadline6  6.2+dfsg-0.1
ii  libx11-6  2:1.5.0-1

Versions of packages maxima recommends:
iu  maxima-share  5.30.0-4

Versions of packages maxima suggests:
iu  maxima-doc5.30.0-4
iu  maxima-emacs  5.30.0-4
pn  texmacs   
ii  tk8.5 [wish]  8.5.11-2
pn  xmaxima   

-- 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#577526: lprm works for me with current testing (1.5.3-2.15)

2013-03-14 Thread Sanjoy Mahajan

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

2013-01-08 Thread Sanjoy Mahajan

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: position.c:136: dot_position: Assertion `rank(g, 2, nsiter2(g)) == 0' 
failed.
  Aborted (core dumped)

(Uncommenting the three commented-out lines turns the assertion failure
into a segmentation fault.)  I haven't managed to compile 2.28 to test
whether the newer dot also fails on this input.

The file:

digraph G {
  subgraph cluster_DC {
DC;
  }

  subgraph cluster_A {
2;
3;
A;
  }

  {rank=same;
  DC;
  A;
  S;
  PR;
  DA;
  PB;
  EC;
  SP;
  }

1 [label="dinner-\nparty\nrecipe"];
2 [label="infinite\nresistive\ngrid\n(horizontal)"];
3 [label="resistive\nladder"];
// 39 [label="P_human"];
1 -> PR ;
// S -> 39 ;
// A -> 3 ;
3 -> 2 ;
}

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages graphviz depends on:
ii  libc6   2.13-37
ii  libcdt4 2.26.3-12
ii  libcgraph5  2.26.3-12
ii  libexpat1   2.1.0-1
ii  libgd2-xpm  2.0.36~rc1~dfsg-6.1
ii  libgraph4   2.26.3-12
ii  libgvc5 2.26.3-12
ii  libgvpr12.26.3-12
ii  libx11-62:1.5.0-1
ii  libxaw7 2:1.0.10-2
ii  libxmu6 2:1.1.1-1
ii  libxt6  1:1.1.3-1

Versions of packages graphviz recommends:
ii  ttf-liberation  1.07.2-6

Versions of packages graphviz suggests:
ii  graphviz-doc  2.28.0-1
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.2

-- no debconf information

-- 
-Sanjoy


Save Long Wharf Park in Boston Harbor!


Six reasoning tools to make hard problems easy.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2013-01-07 Thread Sanjoy Mahajan

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 (cherokee) log files had this error:

  2013-01-07 20:48:32,231 WARNING MoinMoin.log:139 using logging configuration 
read from built-in fallback in MoinMoin.log module!
  Traceback (most recent call last):
File "/usr/share/moin/server/moin.fcgi", line 44, in 
  app = make_application(shared=True)  # <-- adapt here as needed
File "/usr/lib/pymodules/python2.6/MoinMoin/web/serving.py", line 82, in 
make_application
  from MoinMoin.wsgiapp import application
File "/usr/lib/pymodules/python2.6/MoinMoin/wsgiapp.py", line 14, in 

  from MoinMoin.web.contexts import AllContext, Context, XMLRPCContext
File "/usr/lib/pymodules/python2.6/MoinMoin/web/contexts.py", line 16, in 

  from MoinMoin import i18n, error, user, config, wikiutil
File "/usr/lib/pymodules/python2.6/MoinMoin/user.py", line 32, in 
  from werkzeug.security import safe_str_cmp as safe_str_equal
  ImportError: cannot import name safe_str_cmp

It seems that werkzeug.security contains safe_str_cmp only from version
0.7.  See the documentation of werkzeug.security.safe_str_cmp in
.  However, in squeeze,
python-werkzeug is only at version 0.6.2-1 (and the wheezy version of
python-werkzeug, namely 0.8.3, isn't in backports).

I worked around the problem by downgrading to the python-moinmoin in
squeeze (1.9.3-1+squeeze4) and changing /moin_static194/ to
/moin_static193/ in cherokee's config file.

Is a better solution to backport python-werkzeug?  I tried recompiling
it from the source package, but it required upgrading many other
packages so I just took the shortcut above.

-Sanjoy

-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.5.2-linode45 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-moinmoin depends on:
ii  python  2.6.6-3+squeeze7 interactive high-level object-orie
ii  python-parsedatetime0.8.7-2  Python module to parse human-reada
ii  python-pygments 1.3.1+dfsg-1 syntax highlighting package writte
ii  python-support  1.0.10   automated rebuilding support for P
ii  python-werkzeug 0.6.2-1  collection of utilities for WSGI a

Versions of packages python-moinmoin recommends:
ii  cherokee [httpd-cgi]   1.0.8-5+squeeze1  Very fast, flexible and easy to co
ii  fckeditor  1:2.6.6-1squeeze1 rich text format javascript web ed
ii  postfix [mail-transpor 2.7.1-1+squeeze1  High-performance mail transport ag
ii  python-xapian  1.2.7-1~bpo60+1   Xapian search engine interface for
ii  python-xappy   0.5-4 easy-to-use interface to the Xapia

Versions of packages python-moinmoin suggests:
pn  antiword   (no description available)
pn  catdoc (no description available)
pn  docbook-dsssl  (no description available)
pn  poppler-utils | xpdf-utils (no description available)
pn  python-4suite-xml  (no description available)
ii  python-docutils   0.7-2  utilities for the documentation of
pn  python-flup(no description available)
pn  python-gdchart (no description available)
pn  python-ldap(no description available)
pn  python-mysqldb (no description available)
pn  python-openid  (no description available)
pn  python-pyxmpp  (no description available)
pn  python-tz  (no description available)
pn  python-xml (no description available)
pn  smbfs  (no description available)
ii  wamerican [wordlist]  6-3American English dictionary words 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2012-09-12 Thread Sanjoy Mahajan

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 testing/unstable).  The problem is the same -- repeated below for
convenience:

With or without the magic line

  *DefaultOutputOrder: "reverse"

in /etc/cups/psc.ppd, the pages come out in 'normal' order (first page
first).  However, the lp option '-o output-order=reverse' does reverse
the order. e.g. this works fine:

  lp -o output-order=reverse -o page-ranges=123-184 book-indexing.pdf

(but it doesn't matter whether the ppd has the DefaultOutputOrder line).

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:

  *cupsFilter: "application/vnd.cups-raster 0 hpcups"

and hpcups is in the printer-driver-hpcups package.



-- Package-specific info:
$ hp-check -r

HP Linux Imaging and Printing System (ver. 3.12.6)
Dependency/Version Check Utility ver. 15

Copyright (c) 2001-14 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1.
Compile-time
check
mode
(-c
or
--compile):
Use
this
mode
before
compiling
the
HPLIP
supplied
tarball
(.tar.gz
or
.run)
to
determine
if
the
proper
dependencies
are
installed
to
successfully
compile
HPLIP.
2.
Run-time
check
mode
(-r
or
--run):
Use
this
mode
to
determine
if
a
distro
supplied
package
(.deb,
.rpm,
etc)
or
an
already
built
HPLIP
supplied
tarball
has
the
proper
dependencies
installed
to
successfully
run.
3.
Both
compile-
and
run-time
check
mode
(-b
or
--both)
(Default):
This
mode
will
check
both
of
the
above
cases
(both
compile-
and
run-time
dependencies).

Check
types:
a.
EXTERNALDEP
-
External
Dependencies
b.
GENERALDEP
-
General
Dependencies
(required
both
at
compile
and
run
time)
c.
COMPILEDEP
-
Compile
time
Dependencies
d.
[All
are
run-time
checks]
PYEXT
SCANCONF
QUEUES
PERMISSION

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

Saving output in log file: /home/sanjoy/writing-HOWTOS/hp-check.log

Initializing. Please wait...
warning: debian-testing version is not supported. Using debian-6.0.5 versions 
dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 3.2.0-3-686-pae #1 SMP Thu Jun 28 08:56:46 UTC 2012 GNU/Linux
 Host: approx
 Proc: 3.2.0-3-686-pae #1 SMP Thu Jun 28 08:56:46 UTC 2012 GNU/Linux
 Distribution: debian testing

---
| HPLIP CONFIGURATION |
---

HPLIP-Version: HPLIP 3.12.6
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian 
distro  testing version 

Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.12.6

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip-doc/HTML
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv

# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=yes
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=yes
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.12.6
restricted-build=no
ui-toolkit=qt4
qt3=no
qt4=yes
policy-kit=yes
hpijs-only-build=no
lite-build=no
udev-acl-rules=yes
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no


Current contents of '/var/lib/hp/hplip.state' file:
Plugins are not installed. Could not access file: No such file or directory

Current contents of '~/.hplip/hplip.conf' file:
[installation]
date_time = 09/12/2012 11:11:32
version = 3.12.6


 


--
|  External Dependencies |
--

 gs   Ghostscript   REQUIRED7.05
9.05OK -
 network  Network-wget  OPTIONAL-   
1.13.4  OK -
 dbus DBus  REQUIRED-   
1.6.0   OK -
 scanimageShell-ScanningOPTIONAL1.0 
1.0.22  OK -
 policykitAdmin-Policy-frameworkOPTIONAL-   
0.105   OK -
 xsaneSANE-GUI  O

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

2012-08-27 Thread Sanjoy Mahajan

> 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 file.pdf - | lp -o fitplot

   This one is improved: Now all pages print, and the pink boxes are
   pink (rather than green).  But the pages are still too small, taking
   up roughly the upper left one-quarter of the page.  And the second
   page comes out mangled; I've attached a b/w scan (the colors are
   okay, but the placement of part of the text block is wrong).

3. pdftops -paper letter file.pdf - | lp -o raw

   This one got better in that the pink box on page 4 is now pink.  But
   only the first 4 pages printed (out of 10).  But there was no error in
   the cups error_log or any error reported by the printer.

The pdftops in methods 2 and 3 is /usr/bin/pdftops from this package:

  poppler-utils  0.18.4-3

Maybe what remains of this bug should be reassigned to poppler-utils?
Actually, that's not right.  The ps file produced in method 2, via
"pdftops -paper match file.pdf -", looks fine in gs.  But when that ps
file is sent to the printer, then the second page comes out mangled, and
the pages are too small.  So that still seems like a cups-filter
problem.

In method 3, I'm not sure what the failure point is, since it sends the
postscript directly to the printer with lp -o raw.  The failure to print
pages 5-10 then seems like a printer problem (but there's no error
reported anywhere, so it's hard to find out more).

-Sanjoy



page2-mangled.pdf
Description: mangled page 2 from second printing method

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

2012-08-27 Thread Sanjoy Mahajan

> 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):

  ghostscript 9.05~dfsg-6
  cups-filters1.0.18-2+b1

-Sanjoy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2012-05-25 Thread Sanjoy Mahajan

> 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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2012-05-23 Thread Sanjoy Mahajan

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/, thinking
that an old package's version of the file was left lying around.  But
they all have your line.

So, for now I'll just reinstall texlive-binaries and see whether updmap
gets fixed.  

Hmm, no it's still the same.

Oh, that's because updmap is a symlink to
/usr/share/texlive/texmf/scripts/tetex/updmap.pl, which is from
texlive-base.  So, let me investigate earlier versions of texlive-base.

I therefore unpacked each of the .deb's into it's own directory tree,
and then ran

$ find -name updmap.pl | xargs grep INC

And voila:

 
./texlive-base_2011.20120424-1_all.deb/usr/share/texlive/texmf/scripts/tetex/updmap.pl:
  unshift (@INC, "$TEXMFROOT/tlpkg");

So, the texlive-base_2011.20120424-1_all.deb has the wrong line in
updmap.pl.  But probably the newest version has the correct line.

However, when I try to install the newest version, I get:

# aptitude install texlive-base/unstable
The following packages will be upgraded: 
  texlive-base{b} [2011.20120424-1 -> 2012.20120516-1]  
The following partially installed packages will be configured:
  maxima-doc  maxima-emacs  maxima-share  tex-common  texlive-binaries  
1 packages upgraded, 0 newly installed, 0 to remove and 10 not upgraded.
Need to get 14.2 MB of archives. After unpacking 374 kB will be freed.
The following packages have unmet dependencies:
 texlive-base : Depends: texlive-common (>= 2012.20120516-1) but 
2011.20120424-1 is installed.
Depends: texlive-doc-base (>= 2012.20120516) but 
2011.20120424-1 is installed.

-- 
-Sanjoy



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2012-05-22 Thread Sanjoy Mahajan

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 updmap-sys. This may take some time... 
  updmap-sys failed. Output has been stored in
  /tmp/updmap.U1Bxx9vW
  Please include this file if you report a bug.

  Sometimes, not accepting conffile updates in /etc/texmf/updmap.d
  causes updmap-sys to fail.  Please check for files with extension
  .dpkg-dist or .ucf-dist in this directory

There are no .dpkg-dist or .ucf-dist in /etc/texmf/updmap.d.

Here is /tmp/updmap.U1Bxx9vW:

  Can't locate TeXLive/TLUtils.pm in @INC (@INC contains: //tlpkg /etc/perl 
/usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 
/usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 
/usr/local/lib/site_perl .) at /usr/bin/updmap line 21.
  BEGIN failed--compilation aborted at /usr/bin/updmap line 21.

Looking at /usr/bin/updmap, the problem line is

  use TeXLive::TLUtils qw(mkdirhier mktexupd win32);

Looking farther up, @INC is set in lines 14-15:

  chomp($TEXMFROOT = `kpsewhich -var-value=TEXMFROOT`);
  unshift (@INC, "$TEXMFROOT/tlpkg");

But "kpsewhich -var-value=TEXMFROOT" produces "/", which explains why
@INC contains //tlpkg rather than /usr/share/texlive/tlpkg.  The latter
would enable finding TLUtils.pm at
/usr/share/texlive/tlpkg/TeXLive/TLUtils.pm

I couldn't figure out understand why "kpsewhich -var-value=TEXMFROOT"
produces "/", or whether that's the correct output.  My guess was that
it should be /usr/share/texlive.

-Sanjoy

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages texlive-binaries depends on:
ii  dpkg1.16.3
ii  ed  1.6-1
ii  install-info4.13a.dfsg.1-10
ii  libc6   2.13-32
ii  libfontconfig1  2.9.0-3
ii  libfreetype62.4.9-1
ii  libgcc1 1:4.7.0-8
ii  libgraphite31:2.3.1-0.2
ii  libkpathsea62011.20120410-1
ii  libpng12-0  1.2.49-1
ii  libpoppler130.16.7-3
ii  libptexenc1 2011.20120410-1
ii  libstdc++6  4.7.0-8
ii  libx11-62:1.4.99.901-2
ii  libxaw7 2:1.0.10-2
ii  libxmu6 2:1.1.1-1
ii  libxpm4 1:3.5.10-1
ii  libxt6  1:1.1.3-1
ii  perl5.14.2-9
ii  tex-common  3.11
ii  texlive-common  2011.20120424-1
ii  zlib1g  1:1.2.7.dfsg-1

Versions of packages texlive-binaries recommends:
ii  luatex  0.70.1-3
ii  python  2.7.2-10
ii  ruby4.8
ii  ruby1.8 [ruby]  1.8.7.352-2
ii  texlive-base2011.20120424-1
ii  tk8.4 [wish]8.4.19-4
ii  tk8.5 [wish]8.5.11-1

texlive-binaries suggests no packages.

-- 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#640515: printing works again with patch from #658264

2012-05-08 Thread Sanjoy Mahajan

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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2011-10-14 Thread Sanjoy Mahajan

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 leaf node "aaa") would become a
fourth-level heading, i.e. " aaa".  Instead, the fourth * that I was
hoping for looks like it became a space.

-Sanjoy

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages org-mode depends on:
ii  dpkg  1.16.1
ii  emacs23   23.3+1-1.1
ii  install-info  4.13a.dfsg.1-8

org-mode recommends no packages.

Versions of packages org-mode suggests:
pn  ditaa
pn  easypg   
pn  remember-el  

-- 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#598896: workaround using driconf

2011-10-06 Thread Sanjoy Mahajan

>From the KDE forums at
 (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 me.  For example, running

  python /usr/share/doc/python-visual/examples/doublependulum.py 

from the visual python package did not give any errors.

My ~/.drirc file is:





















-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#639339: different from bug 583487

2011-08-30 Thread Sanjoy Mahajan

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.'  --African Proverb



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2011-08-23 Thread Sanjoy Mahajan

I don't think the fix in 
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 the system doesn't hang.  I don't know
exactly which kernel solved the problem.  I think it was 2.6.38.  What I
noticed different in the dmesg log is that, ever since I stopped
experiencing hangs, the following line showed up implying that the error
is being cleared automatically:

[1099952.207172] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, 
masking

Here's a few more lines of context from the current dmesg output (Debian
2.6.39 kernel):

[830137.389798] [drm:intel_opregion_setup], graphic opregion physical addr: 0x0
[830137.389804] [drm:intel_opregion_setup], ACPI OpRegion not supported!
[830137.390304] render error detected, EIR: 0x0010
[830137.390308] page table error
[830137.390311]   PGTBL_ER: 0x0001
[830137.390316] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, 
masking
[830137.390328] render error detected, EIR: 0x0010
[830137.390331] page table error
[830137.390335]   PGTBL_ER: 0x0001
[830137.390407] [drm:drm_crtc_helper_set_mode], [CRTC:4]
[830137.390415] [drm:intel_sdvo_debug_write], SDVOB: W: 05 00 00
   (SDVO_CMD_SET_ACTIVE_OUTPUTS)

-- 
-Sanjoy

`Until lions have their historians, tales of the hunt shall always
 glorify the hunters.'  --African Proverb



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#635842: likely fix for your backend crash

2011-08-03 Thread Sanjoy Mahajan

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 2710 printer (not on the Xerox laserprinters at work).  I suspect
that the cause in your case is the same as in mine; thus, you should be
able to use the fix that I describe below.

The Arch linux bug forum at 
pointed me to a fix that is in cups upstream (1.4.8 and 1.5.0):



Those versions are not yet in the Debian archives, so I applied the
upstream patch to 1.4.7.  However, before I could recompile cups, I
needed to fix a FTBFS due to a problem in some of the ppd files in the
hp-ppd package.  See BTS #588317 for the report and my patch to fix that
problem.

Then cups recompiled fine.  (Although I had to omit my usual -j3 flag or
else the build failed.  But that problem will be the subject of a
separate bug report, if I can reproduce it reliably.)

-Sanjoy



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#588317: patch to fix FTBFS

2011-08-03 Thread Sanjoy Mahajan

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 lines don't have those parentheses.

For me the following diff for the hp-ppd package allows cups to build:

diff -r 5cf6416a38b9 -r 2599e570d9aa cups-o-matic/HP_DeskJet_350C.ppd
--- a/cups-o-matic/HP_DeskJet_350C.ppd  Wed Aug 03 15:52:01 2011 -0400
+++ b/cups-o-matic/HP_DeskJet_350C.ppd  Wed Aug 03 15:52:52 2011 -0400
@@ -19,7 +19,7 @@
 *LanguageEncoding: ISOLatin1
 *PCFileName:   "COM.PPD"
 *Manufacturer: "HP"
-*Product:  "DeskJet 350C"
+*Product:  "(DeskJet 350C)"
 *cupsVersion:  1.0
 *cupsManualCopies: True
 *cupsModelNumber:  2
diff -r 5cf6416a38b9 -r 2599e570d9aa 
cups-o-matic/HP_DeskJet_600C_Photo_Series.ppd
--- a/cups-o-matic/HP_DeskJet_600C_Photo_Series.ppd Wed Aug 03 15:52:01 
2011 -0400
+++ b/cups-o-matic/HP_DeskJet_600C_Photo_Series.ppd Wed Aug 03 15:52:52 
2011 -0400
@@ -19,7 +19,7 @@
 *LanguageEncoding: ISOLatin1
 *PCFileName:   "COM.PPD"
 *Manufacturer: "HP"
-*Product:  "DeskJet 600C Series Photo"
+*Product:  "(DeskJet 600C Series Photo)"
 *cupsVersion:  1.0
 *cupsManualCopies: True
 *cupsModelNumber:  2
diff -r 5cf6416a38b9 -r 2599e570d9aa cups-o-matic/HP_DeskJet_600C_Series.ppd
--- a/cups-o-matic/HP_DeskJet_600C_Series.ppd   Wed Aug 03 15:52:01 2011 -0400
+++ b/cups-o-matic/HP_DeskJet_600C_Series.ppd   Wed Aug 03 15:52:52 2011 -0400
@@ -19,7 +19,7 @@
 *LanguageEncoding: ISOLatin1
 *PCFileName:   "COM.PPD"
 *Manufacturer: "HP"
-*Product:  "DeskJet 600C Series"
+*Product:  "(DeskJet 600C Series)"
 *cupsVersion:  1.0
 *cupsManualCopies: True
 *cupsModelNumber:  2
diff -r 5cf6416a38b9 -r 2599e570d9aa cups-o-matic/HP_DeskJet_630C.ppd
--- a/cups-o-matic/HP_DeskJet_630C.ppd  Wed Aug 03 15:52:01 2011 -0400
+++ b/cups-o-matic/HP_DeskJet_630C.ppd  Wed Aug 03 15:52:52 2011 -0400
@@ -19,7 +19,7 @@
 *LanguageEncoding: ISOLatin1
 *PCFileName:   "COM.PPD"
 *Manufacturer: "HP"
-*Product:  "DeskJet 630/632C"
+*Product:  "(DeskJet 630/632C)"
 *cupsVersion:  1.0
 *cupsManualCopies: True
 *cupsModelNumber:  2
diff -r 5cf6416a38b9 -r 2599e570d9aa cups-o-matic/HP_DeskJet_800C_Series.ppd
--- a/cups-o-matic/HP_DeskJet_800C_Series.ppd   Wed Aug 03 15:52:01 2011 -0400
+++ b/cups-o-matic/HP_DeskJet_800C_Series.ppd   Wed Aug 03 15:52:52 2011 -0400
@@ -19,7 +19,7 @@
 *LanguageEncoding: ISOLatin1
 *PCFileName:   "COM.PPD"
 *Manufacturer: "HP"
-*Product:  "DeskJet 800C Series"
+*Product:  "(DeskJet 800C Series)"
 *cupsVersion:  1.0
 *cupsManualCopies: True
 *cupsModelNumber:  2
diff -r 5cf6416a38b9 -r 2599e570d9aa cups-o-matic/HP_DeskJet_900C_Series.ppd
--- a/cups-o-matic/HP_DeskJet_900C_Series.ppd   Wed Aug 03 15:52:01 2011 -0400
+++ b/cups-o-matic/HP_DeskJet_900C_Series.ppd   Wed Aug 03 15:52:52 2011 -0400
@@ -19,7 +19,7 @@
 *LanguageEncoding: ISOLatin1
 *PCFileName:   "COM.PPD"
 *Manufacturer: "HP"
-*Product:  "DeskJet 900C Series"
+*Product:  "(DeskJet 900C Series)"
 *cupsVersion:  1.0
 *cupsManualCopies: True
 *cupsModelNumber:  2
diff -r 5cf6416a38b9 -r 2599e570d9aa cups-o-matic/HP_DeskJet_990C.ppd
--- a/cups-o-matic/HP_DeskJet_990C.ppd  Wed Aug 03 15:52:01 2011 -0400
+++ b/cups-o-matic/HP_DeskJet_990C.ppd  Wed Aug 03 15:52:52 2011 -0400
@@ -19,7 +19,7 @@
 *LanguageEncoding: ISOLatin1
 *PCFileName:   "COM.PPD"
 *Manufacturer: "HP"
-*Product:  "DeskJet 990C"
+*Product:  "(DeskJet 990C)"
 *cupsVersion:  1.0
 *cupsManualCopies: True
 *cupsModelNumber:  2



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#631581: -exec is also broken

2011-07-13 Thread Sanjoy Mahajan

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
that problem as well as the problem of an empty filename supplied within
single quotes.

--- /usr/bin/xpdf   2011-06-21 19:01:57.0 -0400
+++ /usr/bin/xpdf   2011-07-13 13:35:06.0 -0400
@@ -25,7 +25,7 @@
 cmd="xpdf.real"
 while [ "$#" -gt "0" ]; do
 case "$1" in
--z|-g|-geometry|-remote|-rgb|-papercolor|-eucjp|-t1lib|-ps|-paperw|-paperh)
+
-z|-g|-geometry|-remote|-rgb|-papercolor|-eucjp|-t1lib|-ps|-paperw|-paperh|-exec)
cmd="$cmd $1 $2" && shift ;;
 -title)
 title="$2" ;;
@@ -74,7 +74,11 @@
 file="$(echo $many | cut -d\' -f$n)"
 done
 elif [ "$file" = "" ] || [ "$cat" = "cat" ]; then
-eval $cmd \'$file\' $pages
+if [ "$file" = "" ]; then
+   eval $cmd
+else
+   eval $cmd \'$file\' $pages
+fi
 else
 tmp=$(tempfile -p "$(basename "$file")" -s .pdf)
 test "$cat" = "" || $cat "$file" > "$tmp"



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2011-06-08 Thread Sanjoy Mahajan

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
/sbin/dhclient-script:

  ip -4 addr add 192.168.101.18/255.255.255.0 broadcast 192.168.101.255 dev 
wlan0 label wlan0

The error was:

  Error: an inet prefix is expected rather than "192.168.101.18/255.255.255.0".

In the address, the information after the slash needs to be the number
of "1" bits in the netmask, rather than the netmask itself.  The
following hacky diff fixes it for me, but I doubt it's the best fix:

--- /sbin/dhclient-script   2011-05-19 02:13:42.0 -0400
+++ /sbin/dhclient-script   2011-06-08 19:17:00.0 -0400
@@ -140,6 +140,7 @@
 fi
 if [ -n "$new_subnet_mask" ]; then
 new_mask="/$new_subnet_mask"
+new_mask_bits=`echo "$new_subnet_mask" | awk -F. '{print 
($1+$2+$3+$4)/255*8;}'`
 fi
 if [ -n "$alias_subnet_mask" ]; then
 alias_mask="/$alias_subnet_mask"
@@ -209,7 +210,7 @@
[ "$old_ip_address" != "$new_ip_address" ] ||
[ "$reason" = "BOUND" ] || [ "$reason" = "REBOOT" ]; then
 # new IP has been leased or leased IP changed => set it
-ip -4 addr add ${new_ip_address}${new_mask} ${new_broadcast_arg} \
+ip -4 addr add ${new_ip_address}/${new_mask_bits} 
${new_broadcast_arg} \
 dev ${interface} label ${interface}
 
 if [ -n "$new_interface_mtu" ]; then


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.38-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages isc-dhcp-client depends on:
ii  debianutils  4   Miscellaneous utilities specific t
ii  iproute  20110315-1  networking and traffic control too
ii  isc-dhcp-common  4.1.1-P1-17 common files used by all the isc-d
ii  libc62.13-4  Embedded GNU C Library: Shared lib

isc-dhcp-client recommends no packages.

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd  (no description available)
pn  resolvconf (no description available)

-- Configuration Files:
/etc/dhcp/dhclient.conf changed:
supersede domain-name "mit.edu";
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
netbios-name-servers, netbios-scope, interface-mtu;


-- debconf-show failed

-- 
-Sanjoy

`Until lions have their historians, tales of the hunt shall always
 glorify the hunters.'  --African Proverb



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2011-02-23 Thread Sanjoy Mahajan

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 0.12.4
source package.  However, I also find that it's fixed upstream at
poppler.freedesktop.org.  Here's that commit:

commit 0cb07d645527f25997f5e1b104a6be92441d8ffa
Author: Albert Astals Cid 
Date:   Thu Feb 18 23:27:20 2010 +

Only swap w with h if rotation is 90 or 270

diff --git a/utils/pdftoppm.cc b/utils/pdftoppm.cc
index e5d3ba0..5b318be 100644
--- a/utils/pdftoppm.cc
+++ b/utils/pdftoppm.cc
@@ -18,7 +18,7 @@
 // Copyright (C) 2009 Michael K. Johnson 
 // Copyright (C) 2009 Shen Liang 
 // Copyright (C) 2009 Stefan Thomas 
-// Copyright (C) 2009 Albert Astals Cid 
+// Copyright (C) 2009, 2010 Albert Astals Cid 
 // Copyright (C) 2010 Adrian Johnson 
 //
 // To see a description of the changes please see the Changelog file that
@@ -308,7 +308,7 @@ int main(int argc, char *argv[]) {
 }
 pg_w = pg_w * (x_resolution / 72.0);
 pg_h = pg_h * (y_resolution / 72.0);
-if (doc->getPageRotate(pg)) {
+if ((doc->getPageRotate(pg) == 90) || (doc->getPageRotate(pg) == 270)) {
   tmp = pg_w;
   pg_w = pg_h;
   pg_h = tmp;


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.37 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages poppler-utils depends on:
ii  libc6   2.11.2-11Embedded GNU C Library: Shared lib
ii  libfontconfig1  2.8.0-2.1generic font configuration library
ii  libgcc1 1:4.4.5-12   GCC support library
ii  libpoppler5 0.12.4-1.2   PDF rendering library
ii  libstdc++6  4.4.5-12 The GNU Standard C++ Library v3
ii  libxml2 2.7.8.dfsg-2 GNOME XML library

Versions of packages poppler-utils recommends:
ii  ghostscript  9.01~dfsg-1 interpreter for the PostScript lan

poppler-utils suggests no packages.

-- no debconf information

-- 
-Sanjoy

`Until lions have their historians, tales of the hunt shall always
 glorify the hunters.'  --African Proverb



-- 
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

2011-02-23 Thread Sanjoy Mahajan

> 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
turns on upon resume.  The problem is the display itself, which is blank
upon resume (maybe 1 time out of 10).

 seems similar.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2011-02-22 Thread Sanjoy Mahajan

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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2011-02-22 Thread Sanjoy Mahajan

> 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 track of the report -- which I just found and
am appending the version info from it.

When the problem happens, the backlight is on but the screen is blank,
and I can do everything except see what is on the screen -- so I can
switch to vt1, log in as root, and cleanly reboot.  However, I found
nothing interesting in any of the log files, whether Xorg.0.log, the
syslog, xdm.log, or /var/log/messages.

Since then I've added "drm.debug=14 log_buf_len=16M" to all grub
boot-command lines (copied from a Fedora "debugging X" page).  I've also
prepared a script to run (typing blind and loggin in as root) when the
problem next happens in order to get more debugging info:

  d=/root/debug-blank-display
  mkdir -p $d
  dmesg > $d/dmesg.log
  cp -p /var/log/Xorg.0.log $d/
  mount -t debugfs none /sys/kernel/debug
  dd if=/dev/mem of=$d/gpu_rom.dd bs=64k skip=12 count=1
  intel_gpu_dump > $d/gpu_dump.log

Anything to add or subtract from that script?

And here's what was in the half-finished bug report from Feb 20:

Package: xserver-xorg-video-intel
Version: 2:2.14.0-4
Severity: normal

Every few days (so perhaps ten S3 suspend/resume cycles) the following
happens.  

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.37 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib
ii  libdrm-intel1 2.4.23-3   Userspace interface to intel-speci
ii  libdrm2   2.4.23-3   Userspace interface to kernel DRM 
ii  libpciaccess0 0.12.1-1   Generic PCI access library for X
ii  libudev0  166-1  libudev shared library
ii  libx11-6  2:1.4.1-4  X11 client-side library
ii  libx11-xcb1   2:1.4.1-4  Xlib/XCB interface library
ii  libxcb-aux0   0.3.6-1utility libraries for X C Binding 
ii  libxcb-dri2-0 1.7-2  X C Binding, dri2 extension
ii  libxcb1   1.7-2  X C Binding
ii  libxext6  2:1.2.0-2  X11 miscellaneous extension librar
ii  libxfixes31:4.0.5-1  X11 miscellaneous 'fixes' extensio
ii  libxv12:1.0.6-1  X11 Video extension library
ii  libxvmc1  2:1.0.6-1  X11 Video extension library
ii  xserver-xorg-core [xorg-video 2:1.9.4-2  Xorg X server - core server




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2011-02-12 Thread Sanjoy Mahajan

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:

  Starting program: /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH 
-sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts 
-sMediaType=Automatic -sOutputType=0 -r600x600 -dDEVICEWIDTHPOINTS=612 
-dDEVICEHEIGHTPOINTS=792 -dcupsMediaType=-1 -dcupsBitsPerColor=8 
-dcupsColorOrder=0 -dcupsColorSpace=17 -scupsPageSizeName=Letter -c -f -_ < 
pdftopdfoutput.pdf > gs.stdout 2> gs.stderr
  [Thread debugging using libthread_db enabled]
  [New Thread 0xb6913b70 (LWP 11655)]
  [Thread 0xb6913b70 (LWP 11655) exited]
  [New Thread 0xb6913b70 (LWP 11656)]
  [Thread 0xb6913b70 (LWP 11656) exited]

  Program received signal SIGFPE, Arithmetic exception.
  0xb79c5903 in clist_playback_band () from /usr/lib/libgs.so.8
  (gdb) bt
  #0  0xb79c5903 in clist_playback_band () from /usr/lib/libgs.so.8
  #1  0xb79c9ad4 in clist_playback_file_bands () from /usr/lib/libgs.so.8
  #2  0xb79c9d58 in clist_render_rectangle () from /usr/lib/libgs.so.8
  #3  0xb79ca007 in clist_rasterize_lines () from /usr/lib/libgs.so.8
  #4  0xb79ca40a in clist_get_bits_rectangle () from /usr/lib/libgs.so.8
  #5  0xb79d8fe0 in ?? () from /usr/lib/libgs.so.8
  #6  0xb7b9620d in gx_default_get_bits () from /usr/lib/libgs.so.8
  #7  0xb79bc84b in gdev_prn_get_bits () from /usr/lib/libgs.so.8
  #8  0xb7b10955 in ?? () from /usr/lib/libgs.so.8
  #9  0xb7ba in cups_print_pages () from /usr/lib/libgs.so.8
  #10 0xb79bd425 in gdev_prn_output_page () from /usr/lib/libgs.so.8
  #11 0xb7b991ce in gx_forward_output_page () from /usr/lib/libgs.so.8
  #12 0xb7b2b353 in gs_output_page () from /usr/lib/libgs.so.8
  #13 0xb7926eaf in ?? () from /usr/lib/libgs.so.8
  #14 0xb78f84ee in ?? () from /usr/lib/libgs.so.8
  #15 0xb78f9560 in gs_interpret () from /usr/lib/libgs.so.8
  #16 0xb78ed4a8 in gs_main_run_string_end () from /usr/lib/libgs.so.8
  #17 0xb78ed902 in gs_main_run_string_with_length () from /usr/lib/libgs.so.8
  #18 0xb78ed95a in gs_main_run_string () from /usr/lib/libgs.so.8
  #19 0xb78ee6d0 in ?? () from /usr/lib/libgs.so.8
  #20 0xb78ef478 in ?? () from /usr/lib/libgs.so.8
  #21 0xb78f067b in gs_main_init_with_args () from /usr/lib/libgs.so.8
  #22 0xb78f172e in gsapi_init_with_args () from /usr/lib/libgs.so.8
  #23 0x0804891e in main (argc=22, argv=0xb964) at ./psi/dxmainc.c:84

I then realized that I had forgotten to install the libgs8 built with
debugging.  So I did that:

  dpkg -i libgs8_8.71~dfsg2-10_i386.deb 

Now gs did not throw a floating point exception.  Instead the program
exited with status 01:

  Starting program: /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH 
-sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts 
-sMediaType=Automatic -sOutputType=0 -r600x600 -dDEVICEWIDTHPOINTS=612 
-dDEVICEHEIGHTPOINTS=792 -dcupsMediaType=-1 -dcupsBitsPerColor=8 
-dcupsColorOrder=0 -dcupsColorSpace=17 -scupsPageSizeName=Letter -c -f -_ < 
pdftopdfoutput.pdf > gs.stdout 2> gs.stderr
  [Thread debugging using libthread_db enabled]
  [New Thread 0xb688cb70 (LWP 11701)]
  [Thread 0xb688cb70 (LWP 11701) exited]
  [New Thread 0xb688cb70 (LWP 11702)]
  [Thread 0xb688cb70 (LWP 11702) exited]

  Program exited with code 01.

The stderr (captured in gs.stderr) showed a different problem:

  GPL Ghostscript 8.71: ./base/gxclrast.c(1958): Bad op ff band y0 = 2345 file 
pos 4096 buf pos 2589/4096
 0: df 04 02 09 00 00 00 00 00 ff
10: ff ff ff 30 00 00 00 00 30 00
20: 00 00 00 30 00 00 00 00 df 01
30: 03 00 00 00 00 00 df 01 03 06
40: 0e 01 00 00 80 3f 00 00 80 3f
50: 00 d9 e0 0e e6 48 4b 00 e3 4c
60: 99 00 e2 50 32 6e e3 73 67 00
70: f0 da df 04 02 09 00 00 00 00
80: 00 00 00 00 00 04 04 24 20 b2
90: 0e d0 15 00 00 00 06 00 18 00
   100: 00 06 00 1f 80 00 03 00 0f f0
   110: 00 03 80 0f ff 00 01 80 0f ff
   120: f0 01 c0 03 ff ff 81 c0 00 1f
   130: ff ff e0 00 03 ff ff e0 00 00
   140: 79 ff f0 00 00 1e 1f f0 00 00
   150: 0f 01 f0 00 00 03 80 00 00 00
   160: 01 c0 00 00 00 00 70 00 00 00
   170: 00 38 00 00 00 00 1c 00 00 00
   180: 00 0e 00 00 00 00 0e 00 00 00
   190: 00 07 00 0f 80 00 03 80 1f f8
   200: 00 03 c0 1f ff 80 01 c0 1f ff
   210: fc 01 e0 0f ff ff c1 e0 0e 1f
   220: ff ff f0 06 00 ff ff f0 03 00
   230: 0f ff f0 01 00 00 7f f0 01 80
   240: 00 07 e0 00 c0 00 00 00 00 60
   250: 00 00 00 9c e8 21 9a 12 04 06
   260: 34 23 b4 0e 84 18 3e 54 1d 3a
   270: 74 4f 1e 83 e9 b3 a8 e9 38 40
   280: fb 69 e9 d0 7e ef e5 d2 25 3f
   290: 74 1c 20 6f c5 d3 7d 3a 7f 1b
   300: 77 44 57 be d0 4f 66 c5 d2 7f
   310: 7a bf b4 9f db 4a d7 b0 ad fb
   320: 15 0d 76 99 16 16 d3 1e 18 4d
   330: 1d 03 71 6a 1a 90 4b ff f7 00
   340: 10 01 9c d8 21 bb 12 00 df 01
   350: 03 06 2

Bug#606340: downgrading worked for me

2010-12-15 Thread Sanjoy Mahajan

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 server to fall back to the vesa driver instead.
 
I had messages about not finding the vesa driver.  (I'm sorry that I
didn't keep that Xorg log.)

-Sanjoy



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2010-11-16 Thread Sanjoy Mahajan

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 managed to figure it out), I'll attach the pdf file to
the BTS entry.

*** glibc detected *** xpdf: munmap_chunk(): invalid pointer: 0x09f46148 ***
=== Backtrace: =
/lib/i686/cmov/libc.so.6(+0x6b281)[0x404e2281]
/lib/i686/cmov/libc.so.6(+0x6c4fe)[0x404e34fe]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x403f9701]
xpdf[0x8070b74]
xpdf[0x8060f20]
xpdf[0x806f217]
xpdf[0x8070039]
xpdf[0x807032b]
xpdf[0x8063205]
/usr/lib/libXt.so.6(XtCallCallbackList+0x12a)[0x405ca3fa]
/usr/lib/libXm.so.2(_XmDrawingAreaInput+0x4d)[0x400a799d]
/usr/lib/libXt.so.6(+0x45231)[0x40602231]
/usr/lib/libXt.so.6(+0x454a0)[0x406024a0]
/usr/lib/libXt.so.6(_XtTranslateEvent+0x65f)[0x40602caf]
/usr/lib/libXt.so.6(XtDispatchEventToWidget+0x5e2)[0x405d89c2]
/usr/lib/libXt.so.6(+0x1bf8d)[0x405d8f8d]
/usr/lib/libXt.so.6(XtDispatchEvent+0xa7)[0x405d7f27]
/usr/lib/libXt.so.6(XtAppMainLoop+0x44)[0x405d80d4]
xpdf[0x8071c22]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x4048dc76]
xpdf[0x8051131]
=== Memory map: 
08048000-0808 r-xp  08:02 5063628/usr/bin/xpdf
0808-08084000 rw-p 00037000 08:02 5063628/usr/bin/xpdf
08084000-0808a000 rw-p  00:00 0 
09eb7000-0a1a9000 rw-p  00:00 0  [heap]
4000-4001b000 r-xp  08:02 2133689/lib/ld-2.11.2.so
4001b000-4001c000 r--p 0001a000 08:02 2133689/lib/ld-2.11.2.so
4001c000-4001d000 rw-p 0001b000 08:02 2133689/lib/ld-2.11.2.so
4001d000-4001e000 r-xp  00:00 0  [vdso]
4001e000-40021000 rw-p  00:00 0 
40037000-40166000 r-xp  08:02 5064181/usr/lib/libXm.so.2.0.1
40166000-40178000 rw-p 0012e000 08:02 5064181/usr/lib/libXm.so.2.0.1
40178000-4017a000 rw-p  00:00 0 
4017a000-4031f000 r-xp  08:02 5069805/usr/lib/libpoppler.so.5.0.0
4031f000-4033d000 rw-p 001a5000 08:02 5069805/usr/lib/libpoppler.so.5.0.0
4033d000-4033e000 rw-p  00:00 0 
4033e000-40427000 r-xp  08:02 5064361/usr/lib/libstdc++.so.6.0.13
40427000-4042b000 r--p 000e9000 08:02 5064361/usr/lib/libstdc++.so.6.0.13
4042b000-4042c000 rw-p 000ed000 08:02 5064361/usr/lib/libstdc++.so.6.0.13
4042c000-40433000 rw-p  00:00 0 
40433000-40457000 r-xp  08:02 2133701/lib/i686/cmov/libm-2.11.2.so
40457000-40458000 r--p 00023000 08:02 2133701/lib/i686/cmov/libm-2.11.2.so
40458000-40459000 rw-p 00024000 08:02 2133701/lib/i686/cmov/libm-2.11.2.so
40459000-40476000 r-xp  08:02 2130002/lib/libgcc_s.so.1
40476000-40477000 rw-p 0001c000 08:02 2130002/lib/libgcc_s.so.1
40477000-405b7000 r-xp  08:02 2134220/lib/i686/cmov/libc-2.11.2.so
405b7000-405b9000 r--p 0013f000 08:02 2134220/lib/i686/cmov/libc-2.11.2.so
405b9000-405ba000 rw-p 00141000 08:02 2134220/lib/i686/cmov/libc-2.11.2.so
405ba000-405bd000 rw-p  00:00 0 
405bd000-4060b000 r-xp  08:02 5069133/usr/lib/libXt.so.6.0.0
4060b000-4060f000 rw-p 0004d000 08:02 5069133/usr/lib/libXt.so.6.0.0
4060f000-40728000 r-xp  08:02 5064660/usr/lib/libX11.so.6.3.0
40728000-4072c000 rw-p 00118000 08:02 5064660/usr/lib/libX11.so.6.3.0
4072c000-4072d000 rw-p  00:00 0 
4072d000-40734000 r-xp  08:02 5063239/usr/lib/libSM.so.6.0.1
40734000-40735000 rw-p 6000 08:02 5063239/usr/lib/libSM.so.6.0.1
40735000-40749000 r-xp  08:02 5063963/usr/lib/libICE.so.6.3.0
40749000-4074b000 rw-p 00013000 08:02 5063963/usr/lib/libICE.so.6.3.0
4074b000-4074c000 rw-p  00:00 0 
4074c000-40753000 r-xp  08:02 5072828/usr/lib/libXp.so.6.2.0
40753000-40754000 rw-p 6000 08:02 5072828/usr/lib/libXp.so.6.2.0
40754000-40762000 r-xp  08:02 5076631/usr/lib/libXext.so.6.4.0
40762000-40763000 rw-p d000 08:02 5076631/usr/lib/libXext.so.6.4.0
40763000-407d6000 r-xp  08:02 5063941/usr/lib/libfreetype.so.6.6.0
407d6000-407da000 rw-p 00073000 08:02 5063941/usr/lib/libfreetype.so.6.6.0
407da000-407db000 rw-p  00:00 0 
407db000-407ee000 r-xp  08:02 5066835/usr/lib/libz.so.1.2.3.4
407ee000-407ef000 rw-p 00013000 08:02 5066835/usr/lib/libz.so.1.2.3.4
407ef000-4081f000 r-xp  08:02 5066468/usr/lib/liblcms.so.1.0.18
4081f000-40821000 rw-p 0002f000 08:02 5066468/usr/lib/liblcms.so.1.0.18
40821000-40823000 rw-p  00:00 0 
40823000-40842000 r-xp  08:02 3542155/usr/lib/libjpeg.so.62.0.0
40842000-40843000 rw-p 0001e000 08:02 3542155/usr/lib/libjpeg.so.62.0.0
40843000-40866000 r-xp  08:02 2130978/lib/libpng12.so.0.44.0
40866000-40867000 rw-p 00022000 08:02 2130978/lib/libpng12.so.0.44.0
40867000-40883000 r-xp  08:02 5064298/usr/lib/l

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

2010-10-30 Thread Sanjoy Mahajan

> 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,
then doing

  yes "" | make oldconfig

and building the 2.6.36 package.

How can one tell whether the bug is in xserver-xorg-video-intel or in
the kernel?

-Sanjoy



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2010-10-28 Thread Sanjoy Mahajan

Package: xserver-xorg-video-intel
Version: 2:2.12.0+shadow-2
Severity: normal

This is the same problem I saw in
: 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 window was).  I'm
running vanilla 2.6.36.  The hardware is a Thinkpad T60 with Intel
graphics.

Here is the relevant piece from the syslog:

Oct 28 13:18:19 approx kernel: [175817.958246] render error detected, EIR: 
0x0010
Oct 28 13:18:19 approx kernel: [175817.958248] page table error
Oct 28 13:18:19 approx kernel: [175817.958250]   PGTBL_ER: 0x0012
Oct 28 13:18:19 approx kernel: [175817.958264] [drm:i915_report_and_clear_eir] 
*ERROR* EIR stuck: 0x0010, masking
Oct 28 13:18:19 approx kernel: [175817.958274] render error detected, EIR: 
0x0010
Oct 28 13:18:19 approx kernel: [175817.958276] page table error
Oct 28 13:18:19 approx kernel: [175817.958277]   PGTBL_ER: 0x0012

Soon after that, but before I rebooted, the xdm log got these messages:

Thu Oct 28 13:19:29 2010 xdm info (pid 1850): sourcing /etc/X11/xdm/Xreset
Thu Oct 28 13:19:32 2010 xdm info (pid 1850): sourcing /etc/X11/xdm/Xreset
*** glibc detected *** -:0 : double free or corruption (out): 
0x096039a0 ***
=== Backtrace: =
/lib/i686/cmov/libc.so.6(+0x6b281)[0xb74ba281]
/lib/i686/cmov/libc.so.6(+0x6cad8)[0xb74bbad8]
/lib/i686/cmov/libc.so.6(cfree+0x6d)[0xb74bebbd]
/lib/libpam.so.0(+0x7911)[0xb759c911]
/lib/libpam.so.0(+0x1e7a)[0xb7596e7a]
/lib/libpam.so.0(pam_end+0x39)[0xb7597a09]
-:0 [0x8052f1f]
-:0 [0x8053743]
-:0 [0x804fb80]
-:0 [0x804efaf]
-:0 [0x8050817]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7465c76]
-:0 [0x804c571]
=== Memory map: 
08048000-08063000 r-xp  08:02 5063170/usr/bin/xdm
08063000-08065000 rw-p 0001b000 08:02 5063170/usr/bin/xdm
08065000-08066000 rw-p  00:00 0 
095a6000-09635000 rw-p  00:00 0  [heap]
b6fe2000-b6fff000 r-xp  08:02 2133642/lib/libgcc_s.so.1
b6fff000-b700 rw-p 0001c000 08:02 2133642/lib/libgcc_s.so.1
b700-b7021000 rw-p  00:00 0 
b7021000-b710 ---p  00:00 0 
b711a000-b7124000 r-xp  08:02 2134531
/lib/i686/cmov/libnss_files-2.11.2.so
b7124000-b7125000 r--p 9000 08:02 2134531
/lib/i686/cmov/libnss_files-2.11.2.so
b7125000-b7126000 rw-p a000 08:02 2134531
/lib/i686/cmov/libnss_files-2.11.2.so
b7126000-b712e000 r-xp  08:02 2134509
/lib/i686/cmov/libnss_nis-2.11.2.so
b712e000-b712f000 r--p 8000 08:02 2134509
/lib/i686/cmov/libnss_nis-2.11.2.so
b712f000-b713 rw-p 9000 08:02 2134509
/lib/i686/cmov/libnss_nis-2.11.2.so
b7147000-b714e000 r-xp  08:02 2134515/lib/i686/cmov/librt-2.11.2.so
b714e000-b714f000 r--p 6000 08:02 2134515/lib/i686/cmov/librt-2.11.2.so
b714f000-b715 rw-p 7000 08:02 2134515/lib/i686/cmov/librt-2.11.2.so
b715-b7165000 r-xp  08:02 2134513
/lib/i686/cmov/libpthread-2.11.2.so
b7165000-b7166000 r--p 00014000 08:02 2134513
/lib/i686/cmov/libpthread-2.11.2.so
b7166000-b7167000 rw-p 00015000 08:02 2134513
/lib/i686/cmov/libpthread-2.11.2.so
b7167000-b7169000 rw-p  00:00 0 
b7169000-b71a r-xp  08:02 9051679/lib/libdbus-1.so.3.4.0
b71a-b71a1000 r--p 00037000 08:02 9051679/lib/libdbus-1.so.3.4.0
b71a1000-b71a2000 rw-p 00038000 08:02 9051679/lib/libdbus-1.so.3.4.0
b71a2000-b71b5000 r-xp  08:02 2134532/lib/i686/cmov/libnsl-2.11.2.so
b71b5000-b71b6000 r--p 00012000 08:02 2134532/lib/i686/cmov/libnsl-2.11.2.so
b71b6000-b71b7000 rw-p 00013000 08:02 2134532/lib/i686/cmov/libnsl-2.11.2.so
b71b7000-b71b9000 rw-p  00:00 0 
b71be000-b71c4000 r-xp  08:02 2134501
/lib/i686/cmov/libnss_compat-2.11.2.so
b71c4000-b71c5000 r--p 6000 08:02 2134501
/lib/i686/cmov/libnss_compat-2.11.2.so
b71c5000-b71c6000 rw-p 7000 08:02 2134501
/lib/i686/cmov/libnss_compat-2.11.2.so
b71c6000-b71cf000 r-xp  08:02 2134546
/lib/security/pam_gnome_keyring.so
b71cf000-b71d rw-p 8000 08:02 2134546
/lib/security/pam_gnome_keyring.so
b71d-b71dc000 r-xp  08:02 2133614/lib/security/pam_unix.so
b71dc000-b71dd000 rw-p c000 08:02 2133614/lib/security/pam_unix.so
b71dd000-b71e9000 rw-p  00:00 0 
b71e9000-b71ed000 r-xp  08:02 5069232/usr/lib/libXfixes.so.3.1.0
b71ed000-b71ee000 rw-p 3000 08:02 5069232/usr/lib/libXfixes.so.3.1.0
b71ee000-b71f6000 r-xp  08:02 5064756/usr/lib/libXcursor.so.1.0.2
b71f6000-b71f7000 rw-p 7000 08:02 5064756/usr/lib/libXcursor.so.1.0.2
b71f8000-b71fa000 r-xp  08:02 5063710
/usr/lib/libck-connector.so.0.0.0
b71fa000-b71fb000 rw-p 1000 08:02 5063710
/usr/lib/libck-connector.so.0.0.0
b71fb000-b71fd000 r-xp  08:02 2131917
/lib/security/pam_ck_connector.so
b71fd000-b71fe000

Bug#598896: no problems on my x201s

2010-10-09 Thread Sanjoy Mahajan

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 listmas...@lists.debian.org

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

2010-10-02 Thread Sanjoy Mahajan

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 instructions

A seemingly related problem is that the rendering is *very* choppy.  The
pendulum leaps roughly from one extreme to the other, without going
through intermediate positions.  This choppiness makes VPython nearly
unusuable for displaying simulations.

It shouldn't be so jerky and slow.  The hardware is a Thinkpad T60 w/
Intel integrated graphics (945GM).  Several years ago, on much slower
CPU and graphics hardware, I didn't see this problem.

That was with earlier versions of VPython and the X server, but I don't
think VPython itself is responsible.  There's a discussion on the
vpython mailing list at

  

Rather, I suspect that hardware acceleration isn't working.

The X server pieces are

  xserver-xorg-video-intel 2.12.0+shadow-2
  xserver-xorg-core1.7.7-7
  xserver-xorg 7.5+7

Let me know the proper place to report this bug, if you know!

-Sanjoy

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.35.3 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-visual depends on:
ii  libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii  libboost-python1.42.0   1.42.0-4 Boost.Python Library
ii  libboost-signals1.42.0  1.42.0-4 managed signals and slots library 
ii  libboost-thread1.42.0   1.42.0-4 portable C++ multi-threading
ii  libc6   2.11.2-6 Embedded GNU C Library: Shared lib
ii  libcairo2   1.8.10-6 The Cairo 2D vector graphics libra
ii  libcairomm-1.0-11.8.4-3  C++ wrappers for Cairo (shared lib
ii  libfontconfig1  2.8.0-2.1generic font configuration library
ii  libfreetype62.4.2-2  FreeType 2 font engine, shared lib
ii  libgcc1 1:4.4.4-17   GCC support library
ii  libgl1-mesa-glx [libgl1 7.7.1-4  A free implementation of the OpenG
ii  libglade2-0 1:2.6.4-1library to load .glade files at ru
ii  libglademm-2.4-1c2a 2.6.7-2  C++ wrappers for libglade2 (shared
ii  libglib2.0-02.24.2-1 The GLib library of C routines
ii  libglibmm-2.4-1c2a  2.24.2-1 C++ wrapper for the GLib toolkit (
ii  libglu1-mesa [libglu1]  7.7.1-4  The OpenGL utility library (GLU)
ii  libgtk2.0-0 2.20.1-1+b1  The GTK+ graphical user interface 
ii  libgtkglext11.2.0-1.1OpenGL Extension to GTK+ (shared l
ii  libgtkglextmm-x11-1.2-0 1.2.0-4  C++ bindings for GtkGLExt (Shared 
ii  libgtkmm-2.4-1c2a   1:2.20.3-1   C++ wrappers for GTK+ (shared libr
ii  libice6 2:1.0.6-1X11 Inter-Client Exchange library
ii  libpango1.0-0   1.28.1-1 Layout and rendering of internatio
ii  libpangomm-1.4-12.26.2-1 C++ Wrapper for pango (shared libr
ii  libpng12-0  1.2.44-1 PNG library - runtime
ii  libsigc++-2.0-0c2a  2.2.4.2-1type-safe Signal Framework for C++
ii  libsm6  2:1.1.1-1X11 Session Management library
ii  libstdc++6  4.4.4-17 The GNU Standard C++ Library v3
ii  libx11-62:1.3.3-3X11 client-side library
ii  libxml2 2.7.7.dfsg-4 GNOME XML library
ii  libxmu6 2:1.0.5-2X11 miscellaneous utility library
ii  libxrender1 1:0.9.6-1X Rendering Extension client libra
ii  libxt6  1:1.0.7-1X11 toolkit intrinsics library
ii  python  2.6.6-3  interactive high-level object-orie
ii  python-central  0.6.16+nmu1  register and build utility for Pyt
ii  python-numpy1:1.4.1-4Numerical Python adds a fast array
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

python-visual recommends no packages.

Versions of packages python-visual suggests:
ii  idle  2.6.6-3IDE for Python using Tkinter (defa

-- 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#589787: xserver-xorg-video-intel: render error and then server crashes

2010-10-02 Thread Sanjoy Mahajan

> 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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2010-09-20 Thread Sanjoy Mahajan

Bastien ROUCARIES  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
/usr/share/doc/texlive-doc/metapost/base/mpman.pdf on my Debian
'unstable' system.  Indeed, prologues:=-1 is not one of the options.  

This bug  was reported in 2004 and I
think back then metapost did not automatically output the
HiResBoundingBox unless prologues:=-1 was set.  With that setting it
would output the high-precision box as the BoundingBox itself (which I
think violates some Adobe standard or recommendation).

Now (2010) it seems to output both the BoundingBox (with coordinates
rounded to the the nearest PostScript point) and the HiResBoundingBox
with the full info, without needing a special prologues setting.

So, I think you can safely close this bug.

I'm CCing the main metapost developer in case this is not right.

-Sanjoy

-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2010-09-15 Thread Sanjoy Mahajan

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
  -rw-r--r-- 1 sanjoy sanjoy   49 Sep 15 14:33 cmds

So, instead of sending the pdf file to the stdout (as it correctly does
if the terminal is "post"), it created a pdf file named "| cat".

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.35.3 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gnuplot depends on:
ii  gnuplot-nox   4.4.0-1A command-line driven interactive 
ii  gnuplot-x11   4.4.0-1A command-line driven interactive 

gnuplot recommends no packages.

Versions of packages gnuplot suggests:
pn  gnuplot-doc(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#589787: xserver-xorg-video-intel: render error and then server crashes

2010-07-24 Thread Sanjoy Mahajan

> 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 couple weeks.

-Sanjoy



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2010-07-21 Thread Sanjoy Mahajan

> 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

2010-04-20 Thread Sanjoy Mahajan

>> 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 kernel (with
> kernel mode setting)?

I see a similar, perhaps identical problem.

Twice now (today and a few days ago), the laptop has woken up with the
screen almost completely black.  I can barely see the windows, but the
laptop is otherwise fine; for example, I can edit in Emacs if I could do
it all without reading the characters.  Cycling S3 sleep doesn't restore
the brightness, nor does restarting xdm and the X server -- I need to
reboot and then the screen is back to normal brightness.

This is with xserver-xorg-video-intel 2.9.1-3 and kernel 2.6.33 (vanilla).
I imagine that it has KMS -- I didn't do anything special to disable
that when I compiled the kernel.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2010-04-12 Thread Sanjoy Mahajan

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  1238r01-divide-and-conquer-intro-cd 413696 bytes
# lprm
# lpq
psc is ready and printing
RankOwner   Job File(s) Total Size
1st sanjoy  1238r01-divide-and-conquer-intro-cd 413696 bytes
# lprm 1238
lprm: Job #1238 is already canceled - can't cancel.
# lpq
psc is ready and printing
RankOwner   Job File(s) Total Size
1st sanjoy  1238r01-divide-and-conquer-intro-cd 413696 bytes
# /etc/init.d/cups restart
Restarting Common Unix Printing System: cupsd.
# lpq   /* now it's gone! */
psc is ready
no entries

The printer is a HP PSC 2710.  I'm not totally sure the job has gone
away even after restarting cups, because the printer itself shows a
"printing" icon on the small LCD display, and I often also must cancel
the job with the physical "cancel" button on the printer control
panel.

-Sanjoy

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.33 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cups-bsd depends on:
ii  cups-client   1.4.3-1Common UNIX Printing System(tm) - 
ii  cups-common   1.4.3-1Common UNIX Printing System(tm) - 
ii  debconf [debconf-2.0] 1.5.30 Debian configuration management sy
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib
ii  libcups2  1.4.3-1Common UNIX Printing System(tm) - 
ii  update-inetd  4.36   inetd configuration file updater

cups-bsd recommends no packages.

Versions of packages cups-bsd suggests:
ii  cups  1.4.3-1Common UNIX Printing System(tm) - 

-- debconf information:
  cups-bsd/setuplpd: false



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2010-04-11 Thread Sanjoy Mahajan

> 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
problem in addition to the problem with 'z'.

The lenny version (3.02-1.4+lenny1) works fine on both counts.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

2010-02-28 Thread Sanjoy Mahajan

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

1 2 >

1 - 100 of 188 matches

Mail list logo