Bug#1065178: python3-pil: Installation of python3-pil should not trigger installation of mime-support by default

[Stefan Weil]

Package: python3-pil
Version: 9.4.0-1.1+b1
Severity: normal

Dear Maintainer,

when the package python3-pil is installed (either directly or as a dependency),
it depends on either mime-support or python3-pil.imagetk.

By default, the deprecated package mime-support will be installed.

I think it would be better to install python3-pil.imagetk by default.
Maybe it is sufficient to change the order of the two dependencies.

I noticed this because the host where I tried the installation
has a rule which automatically uninstalls deprecated packages like
mime-support, and that also removed the desired python3-pil.

Regards,
Stefan Weil

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/48 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (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 python3-pil depends on:
ii  libc62.36-9+deb12u4
ii  libfreetype6 2.12.1+dfsg-5+deb12u2
ii  libimagequant0   2.17.0-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  libopenjp2-7 2.5.0-2
ii  libraqm0 0.7.0-4.1
ii  libtiff6 4.5.0-6+deb12u1
ii  libwebp7 1.2.4-0.2+deb12u1
ii  libwebpdemux21.2.4-0.2+deb12u1
ii  libwebpmux3  1.2.4-0.2+deb12u1
ii  libxcb1  1.15-1
ii  python3  3.11.2-1+b1
ii  python3-pil.imagetk  9.4.0-1.1+b1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages python3-pil recommends:
ii  python3-olefile  0.46-3

Versions of packages python3-pil suggests:
pn  python-pil-doc  

-- no debconf information

Bug#1063689: Acknowledgement (linux-image-6.1.0-18-amd64 not usable with NVIDIA GPU)

[Stefan Weil]

Related discussion: https://forums.debian.net/viewtopic.php?t=158200.

Bug#1063689: linux-image-6.1.0-18-amd64 not usable with NVIDIA GPU

[Stefan Weil]

Package: src:linux
Version: 6.1.76-1
Severity: important
X-Debbugs-Cc: s...@weilnetz.de

Dear Maintainer,

on a server with NVIDIA GPU, nvidia-kernel-dkms fails to build the required 
kernel modules
after a kernel update with linux-image-6.1.0-18-amd64 and 
linux-headers-6.1.0-18-amd64.

It looks like the new kernel includes changes that cause a conflict between the 
non-GPL
NVIDIA code and two GPL'ed functions which are now used, but were not used with 
the previous
kernel from Debian stable.

Best regards
Stefan Weil

-- Package-specific info:
** Model information
sys_vendor: primeLine Solutions
product_name: egino s-Series egino BTO
product_version: 0123456789
chassis_vendor: Supermicro
chassis_version: 0123456789
bios_vendor: American Megatrends Inc.
bios_version: 2.1
board_vendor: Supermicro
board_name: H11SSL-i
board_version: 2.00

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
Root Complex [1022:1480]
Subsystem: Super Micro Computer Inc Starship/Matisse Root Complex 
[15d9:1a03]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
PCIe Dummy Host Bridge [1022:1482]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
PCIe Dummy Host Bridge [1022:1482]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 61)
Subsystem: Super Micro Computer Inc H12SSL-i [15d9:790b]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 

01:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] 
Starship/Matisse PTDMA [1022:1498]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PTDMA 
[1022:1498]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

02:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. 
[AMD] Starship/Matisse Reserved SPP [1022:1485]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved 
SPP [1022:1485]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

02:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] 
Starship/Matisse PTDMA [1022:1498]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PTDMA 
[1022:1498]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

02:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Starship USB 
3.0 Host Controller [1022:148c] (prog-if 30 [XHCI])
Subsystem: Super Micro Computer Inc H12SSL-i [15d9:145c]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

40:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
Root Complex [1022:1480]
Subsystem: Super Micro Computer Inc Starship/Matisse Root Complex 
[15d9:1a03]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

40:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
PCIe Dummy Host Bridge [1022:1482]
Control: I/O- Mem- Bu

Bug#1060666: Update to podman-compose from bookworm-backports

[Stefan Weil]

podman-compose 1.0.6-1~bpo12+1 from bookworm-backports works fine.

I suggest to update bookworm to that version.

Bug#1060666: podman-compose: Version is too old and fails to work

[Stefan Weil]

Package: podman-compose
Version: 1.0.3-3
Severity: important
X-Debbugs-Cc: s...@weilnetz.de

Dear Maintainer,

I tried to use the Debian package podman-compose with this code:

https://github.com/UB-Mannheim/quiver-benchmarks/tree/fixes

podman-compose was able to build a container, but each time when
I want to run it with `podman-compose run [...]`, it again builds
a new container, starts the application and terminates again.

I then tried an installation of podman-compose from PyPI.
That newer version works fine.

Therefore I think it would be good to update the version which
is provided by Debian, too.

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-17-amd64 (SMP w/64 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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 podman-compose depends on:
ii  python3 3.11.2-1+b1
ii  python3-dotenv  0.21.0-1
ii  python3-yaml6.0-3+b2

Versions of packages podman-compose recommends:
ii  podman  4.3.1+ds1-8+b1

podman-compose suggests no packages.

-- no debconf information

Bug#1024305: fail2ban: 'allowipv6' not defined in 'Definition'

[Stefan Weil]

I suggest to update /etc/fail2ban/jail.d/defaults-debian.conf to fix 
this bug:



--


# cat /etc/fail2ban/jail.d/defaults-debian.conf
[DEFAULT]
allowipv6 = auto

[sshd]
enabled = true

--


Stefan

Bug#770171: sshd jail fails when system solely relies on systemd journal for logging

[Stefan Weil]

This bug report from 2014 is meanwhile more important than ever.

With the latest stable release Debian marked rsyslog as deprecated (see 
https://wiki.debian.org/Rsyslog).


If a user removes the rsyslog package without removing the related 
logfiles in /var/log, fail2ban silently stops doing its job, because

it looks for failed ssh logins in /var/log/auth which no longer gets
updates. The same applies to other jails which were activated by local 
settings.


If the user not only removes rsyslog but also removes all old files in
/var/log/, fail2ban no longer runs at all but silently fails.

If fail2ban is not working as expected or not running at all, that can 
effect the security of a Debian system. Therefore I suggest to increase 
the priority of this bug report.


My fix for this issue (and also for issue 1024305) is a small 
modification of jail.d/defaults-debian.conf:


--

# cat /etc/fail2ban/jail.d/defaults-debian.conf
[DEFAULT]
allowipv6 = auto
dovecot_backend = systemd
postfix_backend = systemd
sshd_backend = systemd
# ... add more affected backends here

[sshd]
enabled = true

--

I only added the backends which where required for my Debian system. 
Maybe some other jails also must use the systemd backend.


I suggest to update jail.d/defaults-debian.conf and distribute that as a 
security fix.


In addition, rsyslog could be removed from the list of suggested 
packages in future Debian releases.


Stefan

Bug#1032894: psad: Broken symbolic link in documentation

[Stefan Weil]

Package: psad
Version: 2.4.6-3
Severity: minor

Dear Maintainer,

the installed README in the documentation is a symbolic link which points
to a missing file README.md:

# ls -l /usr/share/doc/psad
total 64
-rw-r--r-- 1 root root  3563 Aug  1  2018 BENCHMARK
-rw-r--r-- 1 root root  1248 Jan 31 12:53 changelog.Debian.gz
-rw-r--r-- 1 root root 23122 Aug  1  2018 changelog.gz
-rw-r--r-- 1 root root  4383 Jan 31 12:50 copyright
-rw-r--r-- 1 root root  8385 Aug  1  2018 CREDITS.gz
-rw-r--r-- 1 root root  1687 Aug  1  2018 FW_EXAMPLE_RULES
-rw-r--r-- 1 root root   522 Jan 31 12:35 NEWS.Debian.gz
lrwxrwxrwx 1 root root 9 Jan 31 12:53 README -> README.md
-rw-r--r-- 1 root root  1827 Aug  1  2018 SCAN_LOG

The missing file exists in the source code on GitHub
(https://github.com/mrash/psad), so a fix should be easy.

Regards,
S. W.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (499, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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 psad depends on:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
ii  exim4-daemon-light [mail-transport-agent]  4.96-14
ii  init-system-helpers1.65.2
ii  iproute2   6.1.0-2
ii  iptables   1.8.9-2
ii  libc6  2.36-8
ii  libcarp-clan-perl  6.08-2
ii  libdate-calc-perl  6.4-2
ii  libiptables-chainmgr-perl  1.6-2
ii  libiptables-parse-perl 1.6-3
ii  libnet-ip-perl 1.26-3
ii  libunix-syslog-perl1.1-4+b1
ii  lsb-base   11.6
ii  mailutils [mailx]  1:3.15-3+b2
ii  net-tools  2.10-0.1
ii  perl   5.36.0-7
ii  psmisc 23.6-1
ii  rsyslog [system-log-daemon]8.2302.0-1
ii  sysvinit-utils [lsb-base]  3.06-2
ii  whois  5.5.16

psad recommends no packages.

Versions of packages psad suggests:
pn  fwsnort  

-- no debconf information

Bug#1025818: curl: Command line option -O no longer works as expected

[Stefan Weil]

Package: curl
Version: 7.86.0-2
Severity: normal
X-Debbugs-Cc: s...@weilnetz.de

It looks like there is a regression for curl in bookworm:

The following command no longer works as expected (bullseye was fine):

curl -O -L 
"https://search.maven.org/remotecontent?filepath=org/piccolo2d/piccolo2d-extras/3.0.1/piccolo2d-extras-3.0.1.jar;

Instead of storing the downloaded file as "piccolo2d-extras-3.0.1.jar",
it creates a file named "remotecontent".

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 6.0.0-5-amd64 (SMP w/6 CPU threads; PREEMPT)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages curl depends on:
ii  libc6 2.36-6
ii  libcurl4  7.86.0-2
ii  zlib1g1:1.2.11.dfsg-4.1

curl recommends no packages.

curl suggests no packages.

Bug#1024434: osslsigncode: Fails to sign code with pkcs12

[Stefan Weil]

I could now debug the code and at least see which function fails:

PKCS12_parse failed with
error:0308010C:digital envelope routines::unsupported.

libssl3 no longer provides support by default for some old and unsecure 
algorithms. Such algorithms can be loaded by function OSSL_PROVIDER_load 
or by adding the right "providers" to the configuration of libssl.


I tried that, but failed so far. Maybe Sebastian (cc'ed) can help.

Stefan

Bug#1024434: osslsigncode: Fails to sign code with pkcs12

[Stefan Weil]

Am 19.11.22 um 14:03 schrieb Stephen Kitt:


Since you have a working build, could you run ldd on it and reply with the
result?



Working build:

    linux-vdso.so.1 (0x7ffd29d74000)
    libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 
(0x7f41f5e0)
    libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 
(0x7f41f615e000)

    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f41f5c1f000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f41f7278000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f41f7273000)
    libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 
(0x7f41f7242000)

    libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x7f41f613d000)
    librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x7f41f611e000)
    libssh2.so.1 => /lib/x86_64-linux-gnu/libssh2.so.1 (0x7f41f5bde000)
    libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x7f41f722e000)
    libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 
(0x7f41f5b96000)
    libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 
(0x7f41f580)
    libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7f41f5b44000)
    libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 
(0x7f41f5ae5000)
    liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 
(0x7f41f610e000)

    libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f41f5a2c000)
    libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 
(0x7f41f610)

    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f41f57e3000)
    /lib64/ld-linux-x86-64.so.2 (0x7f41f7292000)
    libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 
(0x7f41f562d000)
    libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 
(0x7f41f55e4000)

    libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x7f41f5563000)
    libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 
(0x7f41f500)
    libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 
(0x7f41f4ecc000)
    libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 
(0x7f41f554d000)

    libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f41f4df2000)
    libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 
(0x7f41f552)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 
(0x7f41f60f8000)
    libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 
(0x7f41f5a1e000)
    libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 
(0x7f41f5503000)
    libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 
(0x7f41f54e)

    libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x7f41f54d4000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 
(0x7f41f54cd000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f41f54bc000)


That differs from the non-working one which does not use 
libcrypto.so.1.1 (that's the only difference).


It looks like libcrypto.so.1.1 is essential: after libssl1.1 (which 
provides libcrypto.so.1.1) was uninstalled, a fresh build also produces 
a failing osslsigncode.


So it works with libssl1, but not with libssl3.

Stefan

Bug#1024434: osslsigncode: Fails to sign code with pkcs12

[Stefan Weil]

Package: osslsigncode
Version: 2.5-2
Severity: normal

Code signing no longer works with the package from Debian bookworm,
while Debian bullseye and a local build based on
https://github.com/mtrojnar/osslsigncode works fine.

Error with bookworm:

stefan@qemu:~$ osslsigncode sign -pkcs12 PATH/sw.p12 -pass PASS -n 'QEMU Setup' 
-i https://qemu.weilnetz.de/ -in qemu-io.exe -out qemu-io.exe.signed -ts 
http://timestamp.digicert.com -h sha256 -verbose -ts 
http://timestamp.comodoca.com
Failed to parse PKCS#12 file: PATH/sw.p12 (Wrong password?)
40493DCA727F:error:0308010C:digital envelope 
routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:373:Global
 default library context, Algorithm (RC2-40-CBC : 0), Properties ()
Failed

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (499, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-4-cloud-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (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 osslsigncode depends on:
ii  libc62.36-5
ii  libcurl3-gnutls  7.86.0-1
ii  libssl3  3.0.7-1

osslsigncode recommends no packages.

osslsigncode suggests no packages.

-- no debconf information

Bug#1009846: nsis: Crash of makensis when size of installed files exceeds 2 GiB

[Stefan Weil]

Package: nsis
Version: 3.08-2
Severity: important
Tags: upstream

All current versions of makensis (which is part of the nsis package) crash
when the total size of the installed files exceeds 2 GiB and compression
option /SOLID is set. I tested both the nsis package which is part of
Debian bullseye and a newer locally built version.

The crash is caused by an 32 bit integer overflow, at least in Source/mmap.cpp.
I observer SIGBUS, SIGSEGV and mmap related error messages, depending on the
files which were to be installed.

The bug can be avoided by removing /SOLID, so instead of whole file compression
only the single installed files get compressed, but that results in a larger
installer.
 
Fixing the bug would require lots of code changes, mainly replacing "int"
by "unsigned int" (which would have a limit at 4 GiB) or "size_t".

A check for integer overflow and aborting with an reasonable error message
would be easier to implement. 

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (499, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-13-cloud-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nsis depends on:
ii  libc62.31-13+deb11u3
ii  libgcc-s110.2.1-6
ii  libstdc++6   10.2.1-6
ii  nsis-common  3.08-2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

nsis recommends no packages.

Versions of packages nsis suggests:
ii  mingw-w64   8.0.0-1
pn  nsis-doc
pn  nsis-pluginapi  
ii  wine [wine] 5.0.3-3

-- no debconf information

Bug#540782: Recent switch to Dwarf2 exception handling breaks compatibility with upstream Mingw-64

[Stefan Weil]

Am 01.12.20 um 21:00 schrieb Stephen Kitt:


Hi Stefan,

Thanks for the feedback, one of the reasons I made the change was to see if
it would cause problems for anyone, before the Debian 11 freeze...

The dilemma I’m faced with now is that MSYS2 and Fedora and others have
switched to Dwarf2 for 32-bit Windows targets, and the Rust ecosystem only
supports that. I toyed with the idea of providing both Dwarf2 and SJLJ
toolchains, but the problem there is that I’d really need to use two
different triplets to avoid mix-ups!

Which packages do you use exactly, and where do you get them from?



Hi Stephen,

for the QEMU build I installed these packages:

mingw64-i686-adwaita-icon-theme mingw64-i686-atk1.0 mingw64-i686-bzip2 
mingw64-i686-cairo mingw64-i686-cogl mingw64-i686-curl 
mingw64-i686-expat mingw64-i686-fontconfig mingw64-i686-freetype2 
mingw64-i686-gdk-pixbuf2.0 mingw64-i686-gettext mingw64-i686-glib2.0 
mingw64-i686-gmp mingw64-i686-gnutls mingw64-i686-gtk3 
mingw64-i686-harfbuzz mingw64-i686-hicolor-icon-theme mingw64-i686-icu 
mingw64-i686-jasper mingw64-i686-jbigkit mingw64-i686-libepoxy 
mingw64-i686-libffi mingw64-i686-libgcrypt mingw64-i686-libgnurx 
mingw64-i686-libgpg-error mingw64-i686-libidn2 
mingw64-i686-libjpeg-turbo mingw64-i686-libpng mingw64-i686-libssh2 
mingw64-i686-libtasn1 mingw64-i686-libunistring mingw64-i686-libusb1.0 
mingw64-i686-libxml2 mingw64-i686-lzo2 mingw64-i686-ncurses 
mingw64-i686-nettle mingw64-i686-nghttp2 mingw64-i686-openssl 
mingw64-i686-p11-kit mingw64-i686-pango1.0 mingw64-i686-pcre 
mingw64-i686-pixman mingw64-i686-sdl2 mingw64-i686-tiff 
mingw64-i686-usbredir mingw64-i686-win-iconv mingw64-i686-xz 
mingw64-i686-zlib


Tesseract builds have a slightly different list of packages:

mingw64-i686-atk1.0 mingw64-i686-bzip2 mingw64-i686-cairo 
mingw64-i686-curl mingw64-i686-expat mingw64-i686-fontconfig 
mingw64-i686-freetype2 mingw64-i686-gdk-pixbuf2.0 mingw64-i686-gettext 
mingw64-i686-giflib mingw64-i686-glib2.0 mingw64-i686-gmp 
mingw64-i686-gtk3 mingw64-i686-harfbuzz mingw64-i686-icu 
mingw64-i686-jasper mingw64-i686-jbigkit mingw64-i686-libarchive 
mingw64-i686-libepoxy mingw64-i686-libffi mingw64-i686-libjpeg-turbo 
mingw64-i686-liblept5 mingw64-i686-libpng mingw64-i686-libssh2 
mingw64-i686-libwebp mingw64-i686-libxml2 mingw64-i686-lz4 
mingw64-i686-lzo2 mingw64-i686-nettle mingw64-i686-nghttp2 
mingw64-i686-openjpeg2 mingw64-i686-openssl mingw64-i686-pango1.0 
mingw64-i686-pcre mingw64-i686-pixman mingw64-i686-tiff 
mingw64-i686-win-iconv mingw64-i686-xz mingw64-i686-zlib


All those packages are available from https://qemu.weilnetz.de/debian/ 
(which also describes how those packages were converted from Cygwin to 
Debian packages).


I see the dilemma, but don't have a good solution up to now.

QEMU mainly uses C code without exceptions, so it might be possible to 
build it with all exceptions disabled which could avoid the dilemma 
unless one of the libraries uses exception handling (I am afraid some do).


Would it be possible to build the toolchain with support for two 
different exception handlers with Dwarf2 by default, but SJLJ as a 
compiler and linker option?


Kind regards,

Stefan

Bug#540782: Recent switch to Dwarf2 exception handling breaks compatibility with upstream Mingw-64

[Stefan Weil]

The recent switch from SJLJ exception handling to Dwarf2 breaks the 
compatibility
with upstream Mingw-w64 which still sticks to SJLJ:
https://sourceforge.net/p/mingw-w64/wiki2/Exception%20Handling/.

It is now no longer possible to use for example the Mingw-w64 cross packages
from Cygwin for cross builds targeting 32 bit Windows on latest Debian.
That's how I generated the Windows binaries for QEMU and Tesseract during
the last years.

Regards,
Stefan W.

Bug#949638: tesseract: uses -march=native

[Stefan Weil]

Adrian, I am afraid that there is a misunderstanding.

The code part which is compiled with -march=native is never executed by
default.

There is a command line option which allows users to select the code
which is used for certain time critical calculations (dot product). A
wrong choice is not a security problem but simply will crash the
application, no matter whether the user selected "native", "avx" or
"neon". That's quite common for other packages including the standard C
library and scientific libraries, too. They all contain optimized
functions which require certain hardware and which crash otherwise.

Regards

Stefan

Bug#949119: Bug fix was not needed

[Stefan Weil]

Hi Paul,

you are right, the Tesseract code uses two files from autoconf-archive.

But those files are part of the Tesseract code base since commit
6b250b58121a9858d3e3019a78a6f7d421bd0fc7 (2018), so Tesseract does not
require a build dependency on autoconf-archive.

Kind regards

Stefan Weil

Bug#949638: tesseract: uses -march=native

[Stefan Weil]

Am 24.01.20 um 21:53 schrieb peter green:

> I still don't think -march=native is appropriate for a binary
> distribution though. If you want to offer different versions of the
> code built with different CPU requirements, that is fine, but please
> don't let them depend on what CPU happens to be in the autobuilder.


Better ideas are welcome.

Tesseract is used for mass processing of books which can take many weeks
or even months. Therefore it is very important that the time critical
code (dot product calculation) runs as fast as possible.

For x86_64 we know the available SIMD instructions (SSE, AVX, ...) which
can be used, add code for all variants and check at runtime what is
supported by the CPU.

For all other architectures (including ARM) there is currently no such
special code, and the default code is rather slow. By using
-march=native for the alternate code, hopefully the compiler will
produce code which runs faster on any machine which is similar to the
build machine. Users who build Tesseract on the machine which is also
used for the mass production will get the best result like that. Users
using a distribution can try the "native" option and either crash the
program or get a possibly faster result.

I see the problem of builds which depend on an autobuilder which may be
different for each build. What would be the best solution for
distributions? Suppress the code using a new configure option or some
magic which detects that the build is for a Debian distribution? Choose
compiler flags manually for the "native" option (that is already
possible, see my previous answer)? Other solutions?

Stefan

Bug#949638: tesseract: uses -march=native

[Stefan Weil]

It is not necessary to patch Tesseract code if for whatever reason
-march=native is completely unwanted.

`make libtesseract_native_la_CXXFLAGS=` will override the extra compiler
flags which are used to produce the native code, so only the default
flags which don't include -march=native will be used.

Stefan

Bug#949638: tesseract: uses -march=native

[Stefan Weil]

> The URL for the patch is 404.

s/tessarect/tesseract/

The fixed URL is https://debdiffs.raspbian.org/main/t/tesseract/.

Stefan

Bug#949638: tesseract: uses -march=native

[Stefan Weil]

Am 24.01.20 um 19:55 schrieb Jeff Breidenbach:

>
> Regarding: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949638
>
> Thank you, Peter.
>
> 1. The URL for the patch is 404.
>
> 2. There may be some subtlety with -march=native, specifically related to
> detection of  SIMD instructions like AVX2. There's been an enormous
> amount of back & forth on this topic in upstream over the years, so
> I'd like
> to take this bug there and let them weigh in.
>
> Jeff


That might be a false alarm.

Tesseract supports two different build systems, one based on cmake, one
based on autoconf.

As far as I know all Linux distributions use the autoconf based build,
so they should not be affected by the existing problems from the cmake
build.

The default autoconf build uses -march=native only if it is supported by
the compiler and only for a single file, but not for the rest of the
code. The code from that single file is not executed by default, but
only if an advanced user runs Tesseract with a special command line
option (-c dotproduct=native).

Stefan

Bug#933878: tesseract: training files are split across libtesseract-dev and tesseract-ocr

[Stefan Weil]

On Sun, 04 Aug 2019 18:49:24 +0100 Julian Gilbey  wrote:
[...]
> At the same time, the training binaries are in tesseract-ocr, such as
> classifier_tester, lstmtraining and so on. Would it not make more
> sense to have *only* /usr/bin/tesseract in tesseract-ocr, and all of
> the other binaries, along with the shell scripts noted above, in a
> separate package called something like tesseract-training?

Hi Julian,

it makes sense to put the executables which are required for training
into an extra package - not for 4.x because that would break existing
installations, but for 5.x.

The training shell scripts are less relevant and might be replaced
in the future by the already existing Python scripts.

In addition, more and more people run Tesseract training without
that scripts. Instead of those scripts, they use the Makefile
provided by https://github.com/tesseract-ocr/tesstrain/.

Regards,
Stefan

Bug#931598: aptitude: Number of broken packages not shown with German locale

[Stefan Weil]

Package: aptitude
Version: 0.8.11-7
Severity: minor
Tags: l10n

If some packages are broken, English and German locale settings show different 
information:

English: #Broken: 34  Disk: ...
German:  #Beschädigt: Disk: ...

So the number (34 in my example) of broken packages is not visible when the 
German translation is used.

This is broken since some years now.

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7fffae098000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7ff1223fe000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7ff1223c4000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7ff122396000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7ff12218f000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7ff122089000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7ff121d81000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7ff121d61000)
libboost_system.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7ff121d5a000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7ff121b2e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7ff121b0d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7ff121989000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ff121806000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7ff1217ea000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ff121629000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7ff12160f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ff1213f1000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7ff1213de000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7ff1211b8000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7ff120fa4000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7ff120f04000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7ff120ede000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7ff120e3d000)
/lib64/ld-linux-x86-64.so.2 (0x7ff122a3)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ff120e38000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7ff120e2c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7ff120e23000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7ff120d05000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7ff120af1000)

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-7
ii  libapt-pkg5.0 1.8.2
ii  libboost-iostreams1.67.0  1.67.0-13
ii  libboost-system1.67.0 1.67.0-13
ii  libc6 2.28-10
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.3.0-6
ii  libncursesw6  6.1+20181013-2
ii  libsigc++-2.0-0v5 2.10.0-1
ii  libsqlite3-0  3.16.2-5+deb9u1
ii  libstdc++68.3.0-6
ii  libtinfo6 6.1+20181013-2
ii  libxapian30   1.4.11-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-13
ii  sensible-utils 0.0.12

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 3.53

-- no debconf information

Bug#900279: iipimage-server: Build package with support for JPEG 2000

[Stefan Weil]

A tagged upstream version 1.1 is now available. It supports JPEG 2000 
using OpenJPEG.


See https://github.com/ruven/iipsrv/releases/tag/iipsrv-1.1 for details.

It would be very helpful to get that version for Debian.

Bug#931147: gdb depends on newer libbabeltrace

[Stefan Weil]

Updating the package libbabeltrace1 from stretch to buster fixes this.

Bug#931147: gdb depends on newer libbabeltrace

[Stefan Weil]

Package: gdb
Version: 8.2.1-2
Severity: important

gdb fails to run when the buster package is installed, but libraries from 
stretch are still installed:

gdb: error while loading shared libraries: libbabeltrace-ctf.so.1: cannot open 
shared object file: No such file or directory

The package dependencies should require newer libraries.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.1-1
ii  libc6   2.28-10
ii  libexpat1   2.2.0-2+deb9u1
ii  libipt2 2.0-2
ii  liblzma55.2.2-1.2+b1
ii  libncursesw66.1+20181013-2
ii  libpython3.73.7.3-2
ii  libreadline77.0-3
ii  libtinfo6   6.1+20181013-2
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.28-10

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Stefan Weil]

Hello Helmut,

I am not sure whether reassigning the bug to mingw-w64-tools is the best
way to get a quick (intermediate) solution. If it helps, I have no
objection, although I thought that patching the pkg-config package would
be easier to fix that special issue.

I agree that a Debian architecture *-w64-mingw32 would be the preferred
solution, but that will take much more time. Nevertheless I am willing
to try that (with your help) and see how how far we can come with
reasonable efforts.

Stefan

CC'ing Steven

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Stefan Weil]

Package: pkg-config
Version: 0.29-6
Severity: important

Dear Maintainer,

recent versions of pkg-config fail to work in cross builds targetting Windows,
so such cross builds no longer work for many users.

Error message when calling i686-w64-mingw32-pkg-config or 
x86_64-w64-mingw32-pkg-config:

Please install dpkg-dev to use pkg-config when cross-building

A simple fix just removes the problematic lines (which I think were introduced 
recently):

--- /usr/share/pkg-config-crosswrapper.orig  2019-01-27 05:56:33.0 +0100
+++ /usr/share/pkg-config-crosswrapper   2019-03-12 17:28:40.721179639 +0100
@@ -11,10 +11,6 @@
   triplet="${basename%-pkg-config}"
   # Normalized multiarch path if any, e.g. i386-linux-gnu for i386
   multiarch="$(dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH 
2>/dev/null)"
-  if [ "$?" != 0 ]; then
-  echo "Please install dpkg-dev to use pkg-config when cross-building" >&2
-  exit 1
-  fi
   # Native multiarch path
   native_multiarch="$(cat /usr/lib/pkg-config.multiarch)"
 
A better fix would skip the multiarch check for *-w64-mingw32 as I don't expect
that Debian will add multiarch support for *-w64-mingw32 in the near future.

Best regards
Stefan Weil


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

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

Versions of packages pkg-config depends on:
ii  libc6 2.28-10
ii  libdpkg-perl  1.19.7
ii  libglib2.0-0  2.58.3-2

pkg-config recommends no packages.

Versions of packages pkg-config suggests:
ii  dpkg-dev  1.19.7

-- no debconf information

Bug#929485: libtensorflow-dev: Missing dependency - package depends on libprotoc-dev

[Stefan Weil]

Package: libtensorflow-dev
Version: 1.10.1+dfsg-A2+b1
Severity: normal

Builds fail because of missing header files if libprotoc-dev is not installed:

/usr/include/tensorflow/core/platform/default/protobuf.h:23:10: fatal 
error: google/protobuf/compiler/importer.h: No such file or directory
 #include "google/protobuf/compiler/importer.h"

The missing file can be found in package libprotoc-dev:

libprotoc-dev: /usr/include/google/protobuf/compiler/importer.h

Installation of that package fixes the build. Therefore I suggest to add it as 
a required package.

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

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

Versions of packages libtensorflow-dev depends on:
ii  libgrpc++-dev1.16.1-1
ii  libprotobuf-dev  3.6.1.3-2
ii  libtensorflow-cc1.10 1.10.1+dfsg-A2+b1
ii  libtensorflow-framework1.10  1.10.1+dfsg-A2+b1
ii  libtensorflow1.101.10.1+dfsg-A2+b1
ii  llvm-7-dev   1:7.0.1-8

libtensorflow-dev recommends no packages.

Versions of packages libtensorflow-dev suggests:
pn  tensorflow-doc  

-- no debconf information

Bug#909039: thunderbird: Crash when starting Thunderbird after latest security update to 1:60.0-3~deb9u1

[Stefan Weil]

Package: thunderbird
Version: 1:60.0-3~deb9u1
Severity: grave
Tags: upstream
Justification: renders package unusable

After the latest security update for Stretch Thunderbird was no longer usable
for one family member because it crashed right after starting.

The reason and the fix are described here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1482248

A local fix is removing or renaming all local mail files which use a wrong
encoding in their file name.



-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u3
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libgtk2.0-0   2.24.31-2
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b2
ii  x11-utils 7.7+3+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 20070829-7
ii  hunspell-fr-classical [hunspell-dictionary]  1:5.7-1
ii  lightning1:60.0-3~deb9u1
ii  myspell-de-at [myspell-dictionary]   20161207-1
ii  myspell-de-ch [myspell-dictionary]   20161207-1
ii  myspell-de-de [myspell-dictionary]   20161207-1

Versions of packages thunderbird suggests:
pn  apparmor  
ii  fonts-lyx 2.2.2-1
ii  libgssapi-krb5-2  1.15-1+deb9u1

-- no debconf information

Bug#906922: `tesseract -l deu --psm 0` dies with sigseg

[Stefan Weil]

On Wed, 22 Aug 2018 12:50:07 +0200 =?utf-8?B?SsO2cmc=?= Sommer
 wrote:
> Package: tesseract-ocr
> Version: 4.00~git2844-607e8fd8-2
> Severity: normal
>
> Hi,
>
> I've got a coredump on running tesseract. If it helps, I can provide the
> image, but I could reproduce this behaviour with different images.
>
> Here are the details of the crash:
>
> PID: 23207 (tesseract)
> UID: 1000 (joerg)
> GID: 1000 (joerg)
> Signal: 11 (SEGV)
> Timestamp: Wed 2018-08-22 12:08:40 CEST (36min ago)
> Command Line: tesseract -l deu --psm 0
Sync/Handy-Bilder/OpenCamera/IMG_20180822_114332.jpg stdout
> Executable: /usr/bin/tesseract

Hi Jörg,

the command line is wrong, as --psm 0 requires -l osd. So using -l osd
instead of -l deu should work for you.

Tesseract was recently fixed to handle that case in a more user friendly
way (see https://github.com/tesseract-ocr/tesseract/pull/1818), so I
think the next update will include that improvement.

Cheers
Stefan

Bug#900279: iipimage-server: Build package with support for JPEG 2000

[Stefan Weil]

Package: iipimage-server
Version: 1.0-1+b1
Severity: important

Contrary to the package description there is currently no support for JPEG 2000.
It was implemented upstream now using the free OpenJPEG library,
but there is currently no tagged release.

I addressed this upstream with issue https://github.com/ruven/iipsrv/issues/153.
Hopefully there will be a tagged version soon which can be used for a new Debian
iipimage-server package with JPEG 2000 support.

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages iipimage-server depends on:
ii  libapache2-mod-fcgid  1:2.3.9-1+b1
ii  libc6 2.24-11+deb9u3
ii  libfcgi0ldbl  2.4.0-8.4+b1
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgomp1  6.3.0-18+deb9u1
ii  libjpeg62-turbo   1:1.5.1-2
ii  libmemcached111.0.18-4.1
ii  libstdc++66.3.0-18+deb9u1
ii  libtiff5  4.0.8-2+deb9u2

Versions of packages iipimage-server recommends:
ii  graphicsmagick-imagemagick-compat [imagemagick]  1.3.25-8
pn  libvips-tools

Versions of packages iipimage-server suggests:
pn  iipimage-doc  
ii  memcached 1.4.33-1

-- Configuration Files:
/etc/apache2/mods-available/iipsrv.conf changed [not included]

-- no debconf information

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

[Stefan Weil]

On Wed, 25 Apr 2018 10:51:09 +0200 Graham Inggs  wrote:
> I agree, and with the upload of leptonlib 1.75.3-4, the tests are now
> run during the build [3], and failure here will result in a failed
> build. Builds of leptonlib were successful on all architectures [4]
> except sparc64, which is notoriously sensitive to unaligned memory access.

Leptonica 1.76.0 built without problems and passed nearly all tests on
sparc64.

With a small fix for a misaligned memory read, only a single failing
test remains:
https://github.com/DanBloomberg/leptonica/pull/342

Bug#849094: Tesseract fixed for BE machines

[Stefan Weil]

The big endian problem in Tesseract which caused a SIGSEGV crash was
fixed with this commit:

https://github.com/tesseract-ocr/tesseract/commit/21d5ce57175e35e9df514e81f9c584f0bb2910ad.

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

[Stefan Weil]

Am 25.04.2018 um 03:37 schrieb Dan Bloomberg:
> There's an endianness.h file in leptonica/src.  Does it say BIG_ENDIAN
> or LITTLE_ENDIAN on your s390?

It says BIG_ENDIAN on my emulated S390X with Debian Testing.

Is arrayaccess.h correct for big endian machines? The 16 and 32 bit
accessors look strange because they swap the words, but not the bytes.

Bug#839695: qemu: Please build qemu with –enable-gtk

[Stefan Weil]

Hi Michael,

QEMU from buster is not usable at all with the default SDL2 user
interface. It is terribly slow (even with KVM enabled) – maybe a
deadlock problem which I have noticed with SDL2 for a long time now.

That means you should go a step further and remove not only GTK3
support, but also SDL2 support. That will be even better for headless
virtual machines.

Regards
Stefan

Bug#891432: redis-server: Missing IPv6 in default installation

[Stefan Weil]

Package: redis-server
Version: 3:3.2.6-1
Severity: important
Tags: ipv6

By default, the redis server only listens on 127.0.0.1, but not on ::1.
If a user has mapped localhost to ::1 only (like it was on my server),
programs which try to connect to the version on localhost won't get a
connection (gitlab in my case).

/etc/redis/redis.conf should bind to both IPv4 and IPv6 addresses.

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

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages redis-server depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u3
ii  libjemalloc1 3.6.0-9.1
ii  lsb-base 9.20161125
ii  redis-tools  3:3.2.6-1

redis-server recommends no packages.

redis-server suggests no packages.

-- Configuration Files:
/etc/redis/redis.conf [Errno 13] Keine Berechtigung: '/etc/redis/redis.conf'

-- no debconf information

Bug#880474: redis-server: Unknown lvalue 'RunTimeDirectory' in section 'Service'

[Stefan Weil]

Package: redis-server
Version: 3:3.2.6-1
Followup-For: Bug #880474

According to bug report #850534, it should be fixed by version 3.2.6-2,
but obviously that version is not available for Debian stable.

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

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages redis-server depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u3
ii  libjemalloc1 3.6.0-9.1
ii  lsb-base 9.20161125
ii  redis-tools  3:3.2.6-1

redis-server recommends no packages.

redis-server suggests no packages.

-- no debconf information

Bug#889141: tesseract-ocr-frk: Improve description for package

[Stefan Weil]

Package: tesseract-ocr-frk
Version: 4.00~git15-45ed289-3
Severity: minor

According to the current description, this package supports "Frankish".
In reality it is not related to Frankish, but simply supports German Fraktur.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

tesseract-ocr-frk depends on no packages.

Versions of packages tesseract-ocr-frk recommends:
ii  tesseract-ocr  4.00~git2188-cdc35338-4

tesseract-ocr-frk suggests no packages.

-- no debconf information

Bug#885789: ocsinventory-agent: Missing /usr/bin/ipdiscover in package

[Stefan Weil]

Package: ocsinventory-agent
Version: 2:2.0.5-1.2
Severity: normal

When building the Debian package, I get this warning:

dh_install: usr/bin/ipdiscover exists in debian/tmp but is not installed to 
anywhere

The executable /usr/bin/ipdiscover is missing indeed in the distributed package.
It is needed to collect information on hosts without an inventory agent,
so it would be good to have it in the package.

The disadvantage is that this would mean different packages for
each architecture.

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

Kernel: Linux 4.9.0-3-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ocsinventory-agent depends on:
ii  debconf [debconf-2.0]1.5.61
ii  libnet-ip-perl   1.26-1
ii  libnet-ssleay-perl   1.80-1
ii  libperl5.24 [libcompress-zlib-perl]  5.24.1-3+deb9u2
ii  libproc-daemon-perl  0.23-1
ii  libwww-perl  6.15-1
ii  libxml-simple-perl   2.22-1
ii  perl 5.24.1-3+deb9u2
ii  po-debconf   1.0.20
ii  ucf  3.0036

Versions of packages ocsinventory-agent recommends:
ii  dmidecode  3.0-4
ii  hdparm 9.51+ds-1
ii  pciutils   1:3.5.2-1

Versions of packages ocsinventory-agent suggests:
ii  nmap   7.40-1
pn  read-edid  
pn  smartmontools  

-- debconf information excluded

Bug#864727: ocsinventory-agent: fails to parse ifconfig output

[Stefan Weil]

Am 22.09.2017 um 18:29 schrieb Frank Nagel:
> Hello,
> 
> the change to IPv4.pm was messed up. Please try the attached patch.

Hello,

that patch works well for me – no warnings in debug mode,
and networks and IP addresses are detected with Debian stable.

Thank you for your efforts.

I would be good to get that in an updated package for stable.

Regards,
Stefan Weil

Bug#864727: ocsinventory-agent: fails to parse ifconfig output

[Stefan Weil]

Package: ocsinventory-agent
Version: 2:2.0.5-1.2
Followup-For: Bug #864727

I got the same problem with our Debian stretch installations.

Santiago's patch raises a new problem which shows only in debug mode:

$ ocsinventory-agent -f --debug
[...]
[debug] Compress::Zlib is available.
[debug] Failed to load
Ocsinventory::Agent::Backend::OS::Linux::Network::IPv4: Regexp modifier
"a" may appear a maximum of twice in regex; marked by <-- HERE in
m/^\s*inet (?ad <-- HERE d?r\s*:\s*)?(\S+)/ at
/usr/share/perl5/Ocsinventory/Agent/Backend/OS/Linux/Network/IPv4.pm
line 14.
Compilation failed in require at (eval 84) line 1.
BEGIN failed--compilation aborted at (eval 84) line 1.
[debug] Ocsinventory::Agent::Backend::IpDiscover ignored
[debug] Ocsinventory::Agent::Backend::OS::AIX ignored
[...]

Kind regards
Stefan Weil


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing-debug'), (500,
'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates'),
(500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ocsinventory-agent depends on:
ii  debconf [debconf-2.0]1.5.61
ii  libnet-ip-perl   1.26-1
ii  libnet-ssleay-perl   1.80-1
ii  libperl5.24 [libcompress-zlib-perl]  5.24.1-3+deb9u1
ii  libproc-daemon-perl  0.23-1
ii  libwww-perl  6.15-1
ii  libxml-simple-perl   2.22-1
ii  perl 5.24.1-3+deb9u1
ii  po-debconf   1.0.20
ii  ucf  3.0036

Versions of packages ocsinventory-agent recommends:
ii  dmidecode  3.0-4
ii  hdparm 9.51+ds-1
ii  pciutils   1:3.5.2-1

Versions of packages ocsinventory-agent suggests:
ii  nmap   7.40-1
ii  read-edid  3.0.2-1+b1
ii  smartmontools  6.5+svn4324-1

-- debconf information excluded

Bug#875637: iipimage-server: Wrong configuration file /etc/apache2/mods-available/iipsrv.conf

[Stefan Weil]

Package: iipimage-server
Version: 1.0-1+b1
Severity: grave
Tags: patch
Justification: renders package unusable

The default installation with Apache2 won't work with the
provided configuration file because that file uses
"Directory" instead of "Location".

A fixed version is shown below.

-- System Information:
Debian Release: 9.1
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages iipimage-server depends on:
ii  libapache2-mod-fcgid  1:2.3.9-1+b1
ii  libc6 2.24-11+deb9u1
ii  libfcgi0ldbl  2.4.0-8.4+b1
ii  libgcc1   1:6.3.0-18
ii  libgomp1  6.3.0-18
ii  libjpeg62-turbo   1:1.5.1-2
ii  libmemcached111.0.18-4.1
ii  libstdc++66.3.0-18
ii  libtiff5  4.0.8-2+deb9u1

Versions of packages iipimage-server recommends:
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u1
pn  libvips-tools

Versions of packages iipimage-server suggests:
pn  iipimage-doc  
pn  memcached 

-- Configuration Files:
/etc/apache2/mods-available/iipsrv.conf changed:
ScriptAlias /iipsrv/ "/usr/lib/iipimage-server/"

   AllowOverride None
   Options None
   
 
   Order allow,deny
   Allow from all
 
 = 2.4>
   Require all granted
 
   
   # Set the module handler
   AddHandler fcgid-script .fcgi

FcgidInitialEnv VERBOSITY "1"
FcgidInitialEnv LOGFILE "/var/log/iipsrv.log"
FcgidInitialEnv MAX_IMAGE_CACHE_SIZE "10"
FcgidInitialEnv JPEG_QUALITY "90"
FcgidInitialEnv MAX_CVT "5000"
FcgidInitialEnv MEMCACHED_SERVERS "localhost"
FcgidIdleTimeout 0
FcgidMaxProcessesPerClass 1


-- no debconf information

Bug#787080: LibreOffice Online with Debian Stretch

[Stefan Weil]

The license issue with JSON in libpoco was fixed recently, see
https://github.com/pocoproject/poco/issues/1614#issuecomment-327629217.

Bug#869220: agrep crash caused by double free

[Stefan Weil]

Package: agrep
Version: 4.17-9
Severity: important
Tags: security patch

The following crash can be reproduced (files can be downloaded with base URL
https://digi.bib.uni-mannheim.de/periodika/reichsanzeiger/ocr/film/tesseract-4.0.0-alpha.20170703/):

$ agrep -2 -l -d '$$' 'Beilage zum Deutſchen' 001-1879/0006.txt 
001-1879/0009.txt 001-1879/0012.txt 001-1879/0008.txt 001-1879/0005.txt 
001-1879/0010.txt 001-1879/0003.txt 001-1879/0007.txt 001-1879/0011.txt 
001-1879/0002.txt 001-1879/0001.txt 001-1879/0004.txt 001-7920/0335.txt 
001-7920/0198.txt 001-7920/0428.txt 001-7920/0006.txt 001-7920/0456.txt 
001-7920/0487.txt 001-7920/0406.txt 001-7920/0096.txt 001-7920/0265.txt 
001-7920/0370.txt 001-7920/0464.txt 001-7920/0364.txt 001-7920/0055.txt 
001-7920/0260.txt 001-7920/0185.txt 001-7920/0389.txt 001-7920/0359.txt 
001-7920/0275.txt 001-7920/0372.txt 001-7920/0345.txt 001-7920/0131.txt 
001-7920/0015.txt 001-7920/0351.txt 001-7920/0009.txt 001-7920/0491.txt 
001-7920/0052.txt 001-7920/0022.txt 001-7920/0241.txt 001-7920/0081.txt 
001-7920/0114.txt
001-1879/0009.txt
001-7920/0114.txt
*** Error in `agrep': double free or corruption (!prev): 0x55be126b8710 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f5c1c88cbcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f5c1c892f96]
/lib/x86_64-linux-gnu/libc.so.6(+0x777de)[0x7f5c1c8937de]
agrep(+0x6de7)[0x55be12168de7]
agrep(+0x13a59)[0x55be12175a59]
agrep(+0xff82)[0x55be12171f82]
agrep(+0x1171c)[0x55be1217371c]
agrep(main+0x41)[0x55be12165db1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f5c1c83c2b1]
agrep(+0x3dfd)[0x55be12165dfd]
=== Memory map: 
55be12162000-55be1218a000 r-xp  08:02 147402 
/usr/bin/agrep
55be1238a000-55be1238b000 r--p 00028000 08:02 147402 
/usr/bin/agrep
55be1238b000-55be1238c000 rw-p 00029000 08:02 147402 
/usr/bin/agrep
55be1238c000-55be1256a000 rw-p  00:00 0 
55be126b7000-55be126d8000 rw-p  00:00 0  [heap]
7f5c1800-7f5c18021000 rw-p  00:00 0 
7f5c18021000-7f5c1c00 ---p  00:00 0 
7f5c1c605000-7f5c1c61b000 r-xp  08:02 131705 
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5c1c61b000-7f5c1c81a000 ---p 00016000 08:02 131705 
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5c1c81a000-7f5c1c81b000 r--p 00015000 08:02 131705 
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5c1c81b000-7f5c1c81c000 rw-p 00016000 08:02 131705 
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5c1c81c000-7f5c1c9b1000 r-xp  08:02 133277 
/usr/lib/x86_64-linux-gnu/libc-2.24.so
7f5c1c9b1000-7f5c1cbb1000 ---p 00195000 08:02 133277 
/usr/lib/x86_64-linux-gnu/libc-2.24.so
7f5c1cbb1000-7f5c1cbb5000 r--p 00195000 08:02 133277 
/usr/lib/x86_64-linux-gnu/libc-2.24.so
7f5c1cbb5000-7f5c1cbb7000 rw-p 00199000 08:02 133277 
/usr/lib/x86_64-linux-gnu/libc-2.24.so
7f5c1cbb7000-7f5c1cbbb000 rw-p  00:00 0 
7f5c1cbbb000-7f5c1cbde000 r-xp  08:02 133162 
/usr/lib/x86_64-linux-gnu/ld-2.24.so
7f5c1cc32000-7f5c1cdcd000 r--p  08:02 135927 
/usr/lib/locale/locale-archive
7f5c1cdcd000-7f5c1cdcf000 rw-p  00:00 0 
7f5c1cdda000-7f5c1cdde000 rw-p  00:00 0 
7f5c1cdde000-7f5c1cddf000 r--p 00023000 08:02 133162 
/usr/lib/x86_64-linux-gnu/ld-2.24.so
7f5c1cddf000-7f5c1cde rw-p 00024000 08:02 133162 
/usr/lib/x86_64-linux-gnu/ld-2.24.so
7f5c1cde-7f5c1cde1000 rw-p  00:00 0 
7fffa0853000-7fffa0874000 rw-p  00:00 0  [stack]
7fffa093-7fffa0932000 r--p  00:00 0  [vvar]
7fffa0932000-7fffa0934000 r-xp  00:00 0  [vdso]
ff60-ff601000 r-xp  00:00 0  
[vsyscall]
Aborted

The code indeed is buggy, and using Valgrind I found this and also
another memory related bug.

Here are the bug fixes for a newer version of agrep:
https://github.com/Wikinaut/agrep/pull/13

Similar changes can be applied to the Debian version:

diff --git a/asearch.c b/asearch.c
index 38ad3fb..d39907c 100644
--- a/asearch.c
+++ b/asearch.c
@@ -254,7 +254,6 @@ Nextchar1file:
{ 
if(FILENAMEONLY && (NEW_FILE || 
!POST_FILTER)) {
num_of_matched++;
-   free_buf(text, buffer);
 
if (agrep_finalfp != 
NULL)

fprintf(agrep_finalfp, "%s", CurrentFileName);
diff --git a/sgrep.c b/sgrep.c
index aadbd23..77340b9 100644
--- a/sgrep.c
+++ 

Bug#856192: License of JSON component

[Stefan Weil]

Am 26.02.2017 um 13:46 schrieb Jochen Sprickerhof:

Parser.h contains the line:

"The Software shall be used for Good, not Evil."

https://github.com/pocoproject/poco/blob/develop/JSON/include/Poco/JSON/Parser.h#L32

This is non-free: https://wiki.debian.org/qa.debian.org/jsonevil

Would be great if you could clear this up with upstream.

Cheers Jochen



I created an issue for POCO:

https://github.com/pocoproject/poco/issues/1614

Bug#787080: LibreOffice Online with Debian Stretch

[Stefan Weil]

Indeed it would be nice to have a Debian package for LibreOffice Online.
I finished installing it manually on Debian Stretch, and it works pretty 
good.


When building I noticed that missing JSON support in package
libpoco-dev is still a problem (see bug report #856192).

Bug#856192: License of JSON component

[Stefan Weil]

See also this comment: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786498#21.

Bug#856192: libpoco-dev: Missing JSON component

[Stefan Weil]

Package: libpoco-dev
Version: 1.7.6+dfsg1-4
Severity: normal

The package does not include the JSON component – it is
explicitly disabled in debian/rules.

That component is needed for LibreOffice Online, for example.

There is a short comment in the changelog of poco:
  * Remove JSON lib, as it's not DFSG-complaint

I did not find any hint why the JSON lib might not be DFSG compliant.

-- System Information:
Debian Release: 9.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libpoco-dev depends on:
ii  libpococrypto46  1.7.6+dfsg1-4
ii  libpocodata461.7.6+dfsg1-4
ii  libpocodatamysql46   1.7.6+dfsg1-4
ii  libpocodataodbc461.7.6+dfsg1-4
ii  libpocodatasqlite46  1.7.6+dfsg1-4
ii  libpocofoundation46  1.7.6+dfsg1-4
ii  libpocomongodb46 1.7.6+dfsg1-4
ii  libpoconet46 1.7.6+dfsg1-4
ii  libpoconetssl46  1.7.6+dfsg1-4
ii  libpocoutil461.7.6+dfsg1-4
ii  libpocoxml46 1.7.6+dfsg1-4
ii  libpocozip46 1.7.6+dfsg1-4

libpoco-dev recommends no packages.

libpoco-dev suggests no packages.

-- no debconf information

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

[Stefan Weil]

On 01/04/17 08:03, Graham Inggs wrote:

On 3 January 2017 at 20:24, Jeff Breidenbach  wrote:

Tesseract 4 is known to not work on big endian. Stefan (on CC) is excited to
take a look if someone can give him access to a big endian machine.


It is possible for non-DDs to request temporary access to porterboxes,
see https://dsa.debian.org/doc/guest-account/



"People who are not yet DMs or NMs will need to find a DD who is willing 
to sponsor their request". That's what I tried to do.


Stefan

Bug#846049: Acknowledgement (icedove: SIGSEGV in JSObject2WrappedJSMap::UpdateWeakPointersAfterGC)

[Stefan Weil]

Maybe this is related:

https://bugzilla.mozilla.org/show_bug.cgi?id=1223078

Did the problems with Thunderbird / Icedove start after November 2015
with that code change?

Stefan

Bug#837952: Acknowledgement (icedove: SIGSEGV in gfxShapedText::DetailedGlyphStore::Get)

[Stefan Weil]

Icedove was running in safe mode, without any extensions.

gdb output (stack traces, registers, disassembly) is appended.

MOZILLA_FIVE_HOME=/usr/lib/icedove
  LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin --safe-mode
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from /usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.
(gdb) r
Starting program: /usr/lib/icedove/icedove-bin --safe-mode
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/b0/7fd302019b514d7f89c4d611170f2857da7947.debug]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/c6/413377496564262e47f01293586a80ca2cf9da.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/4b/4ee36ff05fd0dba70d4a731857d5dc43a9a8fd.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/53/94c64e472dccc4892a9635f1b07dc01e2b886d.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/80/cbeba6673abc6763f2e70881c175447f532801.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/21/6c37f3bd675f0475c5c3500476183de6d84b00.debug]
[New Thread 0x7fffe587e700 (LWP 30911)]
[Thread 0x7fffe587e700 (LWP 30911) exited]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/22/cfb993ebf3c793b860f77e97592da7a403bf42.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/24/9e3e31976de4980a657c235f304ea42716676d.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/f0/0efd825198fe36939c108183503c92282c3247.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/5c/6776b52b90476102f1534d4881da8321980d31.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/f7/325886428d95bc4d25f675065e6b230dbd1004.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/ec/593fda49d00bccc1803c6c005f505c42154b41.debug]
[New Thread 0x7fffe587e700 (LWP 30913)]
[New Thread 0x7fffde7ff700 (LWP 30914)]
[New Thread 0x77fed700 (LWP 30915)]
[New Thread 0x7fffddffe700 (LWP 30916)]
[New Thread 0x7fffdd4ff700 (LWP 30917)]
[New Thread 0x7fffdd2fe700 (LWP 30918)]
[New Thread 0x7fffdd0fd700 (LWP 30919)]
[New Thread 0x7fffdcefc700 (LWP 30920)]
[New Thread 0x7fffdccfb700 (LWP 30921)]
[New Thread 0x7fffdcafa700 (LWP 30922)]
[New Thread 0x7fffdc8f9700 (LWP 30923)]
[New Thread 0x7fffdc6f8700 (LWP 30924)]
[New Thread 0x7fffdb3ff700 (LWP 30925)]
[New Thread 0x7fffda8ff700 (LWP 30926)]
[New Thread 0x7fffda0fe700 (LWP 30927)]
[New Thread 0x7fffe4e64700 (LWP 30928)]
[New Thread 0x7fffd94ff700 (LWP 30929)]
[New Thread 0x7fffd8169700 (LWP 30930)]
[New Thread 0x7fffd7968700 (LWP 30931)]
[New Thread 0x7fffd53ff700 (LWP 30932)]
[New Thread 0x7fffd3e50700 (LWP 30933)]
[New Thread 0x7fffd364f700 (LWP 30934)]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/ba/3e1a3ec172db43a8c535ad3584c8e495d8.debug]
[New Thread 0x7fffd21ff700 (LWP 30935)]
[New Thread 0x7fffd19fe700 (LWP 30936)]
[New Thread 0x7fffd11fd700 (LWP 30937)]
[New Thread 0x7fffd09fc700 (LWP 30938)]
[New Thread 

Bug#837952: icedove: SIGSEGV in gfxShapedText::DetailedGlyphStore::Get

[Stefan Weil]

Package: icedove
Version: 1:45.2.0-4+b1
Severity: normal

This is one of the random crashes which happen frequently
(~ 1 crash every 2 days).

I write a new report because it is the first crash in function 
gfxShapedText::DetailedGlyphStore::Get.


gdb output is available.

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'testing'), (500, 'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3+deb8u1
ii  libasound21.0.28-1
ii  libatk1.0-0   2.21.90-2
ii  libc6 2.23-5
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.10.10-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:6.1.1-11
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.49.6-1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.4-0 1.4.1-2
ii  libicu57  57.1-4
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.25-1
ii  libpango-1.0-01.40.2-1
ii  libpangocairo-1.0-0   1.40.2-1
ii  libpangoft2-1.0-0 1.40.2-1
ii  libpixman-1-0 0.32.6-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-11
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-de-at [hunspell-dictionary]  20131206-5
ii  hunspell-de-ch [hunspell-dictionary]  20131206-5
ii  hunspell-de-de [hunspell-dictionary]  20131206-5
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.2.0-4+b1

Versions of packages icedove suggests:
pn  apparmor  
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.14.3+dfsg-2

-- no debconf information

Bug#827274: segfaults when loading message list after switching mail folders

[Stefan Weil]

On 07/25/16 20:33, Stefan Weil wrote:

Hi Carsten,

one more debug protocol with a similar backtrace of the crashing thread.


Here is a new debug protocol from icedove 1:45.2.0-2+b1.
Icedove was run in safe mode without any extensions.

Could it be that the crashing code is operating with data which is invalid
because it was freed by another thread?

Stefan

MOZILLA_FIVE_HOME=/usr/lib/icedove
  LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin --safe-mode
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from /usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.
(gdb) r
Starting program: /usr/lib/icedove/icedove-bin --safe-mode
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/f5/e784597cb952fdb8fcdc1d4af6d0eb5e4008b5.debug]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/8d/6981338722a7f300c02e051585efb5ba654238.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/cf/bcbb40fd4f33668f799ae7923df82ef2e70d5f.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/4c/b8c17eebbc02f51c7e050633c6cf1ca74001d7.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/6d/1c9345e70313e47b14d725907bfa1e2164a6d0.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/a3/2a0f7aa29eab969b3effc06d8454dc9e6642ab.debug]
[New Thread 0x7fffe5d25700 (LWP 18462)]
[Thread 0x7fffe5d25700 (LWP 18462) exited]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/31/aa3ab4da85bdcc50f51c9b404080f737640c71.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/8c/67ff8263bfab481a435ec2432945f4c0682753.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/4f/49cad5dd8395c9e10226cb24deb3ae062cb424.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/5d/b3b63259b843e85efe7bb89143cf63753e8e87.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/86/bf75c083479eb4cbaad1e29618cffe6f417a09.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/04/40f4e93d601796d899abaa6de47f0197ee99c7.debug]
[New Thread 0x7fffe5d25700 (LWP 18464)]
[New Thread 0x7fffdecff700 (LWP 18465)]
[New Thread 0x77fed700 (LWP 18466)]
[New Thread 0x7fffde4fe700 (LWP 18467)]
[New Thread 0x7fffdd9ff700 (LWP 18468)]
[New Thread 0x7fffdd7fe700 (LWP 18469)]
[New Thread 0x7fffdd5fd700 (LWP 18470)]
[New Thread 0x7fffdd3fc700 (LWP 18471)]
[New Thread 0x7fffdd1fb700 (LWP 18472)]
[New Thread 0x7fffdcffa700 (LWP 18473)]
[New Thread 0x7fffdcdf9700 (LWP 18474)]
[New Thread 0x7fffdcbf8700 (LWP 18475)]
[New Thread 0x7fffdb8ff700 (LWP 18476)]
[New Thread 0x7fffdadff700 (LWP 18477)]
[New Thread 0x7fffda5fe700 (LWP 18478)]
[New Thread 0x7fffdee53700 (LWP 18479)]
[New Thread 0x7fffd99ff700 (LWP 18480)]
[New Thread 0x7fffd8669700 (LWP 18481)]
[New Thread 0x7fffd7e68700 (LWP 18482)]
[New Thread 0x7fffd58ff700 (LWP 18483)]
[New Thread 0x7fffd4350700 (LWP 18484)]
[New Thread 0x7fffd3b4f700 (LWP 18485)]
Dwarf Erro

Bug#831989: icedove: Crash in nsDisplayItem::GetClippedBounds / GetBounds

[Stefan Weil]

Package: icedove
Version: 1:45.1.0-1
Severity: normal

Dear Maintainer,

icedove crashed randomly during normal operation.
The stack differs from two other kinds of random crashes
which I got some days ago.

This is the first time that I see a crash in GetBounds,
nor did I find similar crashes in the net.

Regards
Stefan

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.23-1
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:6.1.1-9
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.48.1-1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.4-0 1.4.1-2
ii  libicu55  55.1-7
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.23-2
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpixman-1-0 0.32.6-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-9
ii  libvpx3   1.5.0-3
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-de-at [hunspell-dictionary]  20131206-5
ii  hunspell-de-ch [hunspell-dictionary]  20131206-5
ii  hunspell-de-de [hunspell-dictionary]  20131206-5
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.1.0-1

Versions of packages icedove suggests:
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.14.2+dfsg-1

-- no debconf information

Bug#831338: icedove: SIGSEGV caused by NULL pointer in js::Shape::fixupShapeTreeAfterMovingGC

[Stefan Weil]

Package: icedove
Version: 1:45.1.0-1~deb8u1
Severity: normal

Dear Maintainer,

while reading e-mails, icedove crashed. Here is the gdb output
(I attached gdb because I was waiting for a different crash):

Program received signal SIGSEGV, Segmentation fault.
js::Shape::fixupShapeTreeAfterMovingGC (this=) at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jspropertytree.cpp:278
278 BaseShape* base = key->base();
(gdb) p key
$1 = (js::Shape *) 0x0
(gdb) l
273 for (KidsHash::Enum e(*kh); !e.empty(); e.popFront()) {
274 Shape* key = e.front();
275 if (IsForwarded(key))
276 key = Forwarded(key);
277 
278 BaseShape* base = key->base();
279 if (IsForwarded(base))
280 base = Forwarded(base);
281 UnownedBaseShape* unowned = base->unowned();
282 if (IsForwarded(unowned))
(gdb) i s
#0  js::Shape::fixupShapeTreeAfterMovingGC (this=) at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jspropertytree.cpp:278
#1  0x727c185b in js::Shape::fixupAfterMovingGC (this=) at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jspropertytree.cpp:309
#2  0x72788921 in UpdateCellPointersTyped
(traceKind=, arena=, trc=0x7fffc2a0) at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jsgc.cpp:2390
#3  UpdateCellPointers (arena=, trc=0x7fffc2a0)
at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jsgc.cpp:2428
#4  js::gc::UpdateCellPointersTask::updateArenas (this=)
at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jsgc.cpp:2601
(gdb) p *this
value has been optimized out
(gdb) up
#1  0x727c185b in js::Shape::fixupAfterMovingGC (this=) at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jspropertytree.cpp:309
309 fixupShapeTreeAfterMovingGC();




-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-13
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:6.1.1-8
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.48.1-1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpixman-1-0 0.32.6-3
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-8
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-de-at [hunspell-dictionary]  20131206-5
ii  hunspell-de-ch [hunspell-dictionary]  20131206-5
ii  hunspell-de-de [hunspell-dictionary]  20131206-5
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.1.0-1~deb8u1

Versions of packages icedove suggests:
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.14.2+dfsg-1

-- no debconf information

Bug#829531: icedove: Icedove closes abruptly

[Stefan Weil]

This older bug report seems to be related:

https://bugzilla.mozilla.org/show_bug.cgi?id=1174997

Bug#829531: icedove: Icedove closes abruptly

[Stefan Weil]

I also experience that sudden terminations of Icedove since some days.
Today I attached gdb to find the reason, got a stack trace and found this
bug report with identical results.

The crash is caused by a NULL pointer access: oldArray = this->objectSet
== NULL.

Details here:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77fbf740 (LWP 19091)]
js::ConstraintTypeSet::sweep (this=this@entry=0x7fffd6081580,
zone=0x7fffcf7a3000, oom=...) at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/vm/TypeInference.cpp:4077
(gdb)
(gdb) i s
#0  js::ConstraintTypeSet::sweep (this=this@entry=0x7fffd6081580,
zone=0x7fffcf7a3000, oom=...)
at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/vm/TypeInference.cpp:4077
#1  0x7294a551 in JSScript::maybeSweepTypes
(this=0x7fffca2b8300, oom=oom@entry=0x7fffc2a0)
at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/vm/TypeInference.cpp:4305
#2  0x7279e405 in SweepThing (oom=0x7fffc2a0,
script=) at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jsgc.cpp:5361
#3  SweepArenaList
(sliceBudget=..., arenasToSweep=0x7fffcf7a34f0)
at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jsgc.cpp:5376
#4  js::gc::GCRuntime::sweepPhase (this=this@entry=0x7fffdf1683f8,
sliceBudget=...) at
/build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jsgc.cpp:5417
#5  0x727a309f in js::gc::GCRuntime::incrementalCollectSlice
(this=this@entry=0x7fffdf1683f8, budget=...,
reason=reason@entry=JS::gcreason::REFRESH_FRAME)
at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6086
...
(gdb) p *this
$5 = { = {flags = 3592946040, objectSet = 0x0},
constraintList = 0x0}
(gdb) l
4072ObjectKey** oldArray = objectSet;
4073   
4074clearObjects();
4075objectCount = 0;
4076for (unsigned i = 0; i < oldCapacity; i++) {
4077ObjectKey* key = oldArray[i];
4078if (!key)
4079continue;
4080if (!IsObjectKeyAboutToBeFinalized()) {
4081ObjectKey** pentry =

Bug#822550: liblept5: leptonica does not work with libgif7 5.1.2

[Stefan Weil]

Package: liblept5
Version: 1.73-1+b2
Severity: important

Dear Maintainer,

the leptonica code refuses to support libgif 5.1.2 because of a
known bug in that version.

Here you can see that the current Debian package was compiled
without working support for gif images:

# strings /usr/lib/liblept.so.5|grep giflib
p@Error in %s: Can't use giflib-5.1.2; suggest 5.1.1 or earlier
Can't use giflib-5.1.2; suggest 5.1.1 or earlier

Debian Stretch includes a patched libgif7 5.1.2 where the problem
was fixed, but as the version check is done at compile time,
patching libgif7 5.1.2 does not help for leptonica.

I suggest to upgrade libgif7 to 5.1.3 (instead of hacking
leptonica to accept 5.1.2) and releasing an updated version
of leptonica which requires libgif7 5.1.3.

See also bug report #812657.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'stable-updates'), (500, 'proposed-updates'), (500, 'testing'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages liblept5 depends on:
ii  libc62.22-6
ii  libgif7  5.1.2-0.3
ii  libjpeg62-turbo  1:1.4.2-2
ii  libopenjp2-7 2.1.0-2.1+b1
ii  libpng16-16  1.6.21-2
ii  libtiff5 4.0.6-1
ii  libwebp5 0.4.4-1+b2
ii  zlib1g   1:1.2.8.dfsg-2+b1

liblept5 recommends no packages.

liblept5 suggests no packages.

-- no debconf information

Bug#810552: Acknowledgement (scite depends on libgl1-mesa-glx)

[Stefan Weil]

There seems to be no hard dependency, but something like
"if UNKNOWN COMPONENT does not exist, then require libGL.so.1":

I removed /usr/lib/x86_64-linux-gnu/libGL.so.1, and
scite still kept working. I also tried "strace -f scite"
and did not see libGL.so.1 in the trace output.

Bug#810552: scite depends on libgl1-mesa-glx

[Stefan Weil]

Package: scite
Version: 3.6.0-1
Severity: normal

Dear Maintainer,

scite was installed on a minimal Debian testing system.
It failed to run because of missing libGL.so.1:

Couldn't open libGL.so.1: libGL.so.1: Kann die Shared-Object-Datei nicht 
öffnen: Datei oder Verzeichnis nicht gefunden

Installation of libgl1-mesa-glx fixed that.

Kind regards,
Stefan

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages scite depends on:
ii  libc62.21-6
ii  libcairo21.14.4-1
ii  libgcc1  1:5.3.1-5
ii  libgdk-pixbuf2.0-0   2.32.3-1
ii  libglib2.0-0 2.46.2-3
ii  libgtk-3-0   3.18.6-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libstdc++6   5.3.1-5

scite recommends no packages.

scite suggests no packages.

-- no debconf information

Bug#805653: liblept4: Wrong file mode in call of fmemopen

[Stefan Weil]

Package: liblept4
Version: 1.72-3
Severity: normal

Dear Maintainer,

liblept4 fails to read any JPEG 2000 file (Jessie) or uses
an inefficient temporary file (1.72-3).

Example output with tesseract + liblept4 1.71-*:

$ tesseract test.jp2 test -l deu-frak hocr
Tesseract Open Source OCR Engine v3.05.00dev with Leptonica
Warning in fgetJp2kResolution: image resolution not found
tesseract: /home/nirgal/openjpeg2-2.1.0/src/lib/openjp2/cio.c:553:
opj_stream_get_number_byte_left: Assertion `p_stream->m_user_data_length
>= (OPJ_UINT64)p_stream->m_byte_offset' failed.

Example output with tesseract + liblept4 1.72-*:

$ tesseract test.jp2 test -l deu-frak hocr
Tesseract Open Source OCR Engine v3.05.00dev with Leptonica
Warning in pixReadMemJp2k: work-around: writing to a temp file
...

Example output with tesseract + liblept4 (fixed):

$ tesseract test.jp2 test -l deu-frak hocr
Tesseract Open Source OCR Engine v3.05.00dev with Leptonica
Info in pixReadStreamJp2k: w = 10032, h = 7280, bps = 8, spp = 1
...

Here is the patch which fixes the problem:

https://github.com/stweil/leptonica/commit/c4386b5d09dbdd1135078a218c167976b3a35eda



-- System Information:
Debian Release: 8.2
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500,
'testing-proposed-updates'), (500, 'stable-updates'), (500,
'proposed-updates'), (500, 'oldstable-updates'), (500,
'oldstable-proposed-updates'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages liblept4 depends on:
ii  libc62.19-18+deb8u1
ii  libgif4  4.1.6-11
ii  libjpeg62-turbo  1:1.3.1-12
ii  libopenjp2-7 2.1.0-2.1
ii  libpng12-0   1.2.50-2+deb8u1
ii  libtiff5 4.0.3-12.3
ii  libwebp5 0.4.3-1.3
ii  zlib1g   1:1.2.8.dfsg-2+b1

liblept4 recommends no packages.

liblept4 suggests no packages.

-- no debconf information

Bug#774622: Crash caused by IPv6 connection

[Stefan Weil]

The crash is triggered by the IPv6 connection used in our test scenario: 
struct sockaddr_in is only sufficient for IPv4, but IPv6 needs struct 
sockaddr_in6.


A better fix than the one given in my initial report would use struct 
sockaddr_storage and cast it either to struct sockaddr_in or to struct 
sockaddr_in6 depending on ss_family.



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

Bug#774622: ssvnc: Crash (stack smashing) of listening vncviewer

[Stefan Weil]

Package: ssvnc
Version: 1.0.29-2+b1
Severity: important

Dear Maintainer,

we experience crashes of the vncviewer (which make it unusable for our 
application).

Test scenario:

* Debian jessie installation
* Two X displays (:0, :1)
* Run viewer: DISPLAY=:1 ssvncviewer -viewonly -listen 0
* Connect server: x11vnc -connect localhost

ssvncviewer forks to serve the connection, but the forked process crashes:

AcceptTcpConnection6: ipv6 connection from: '::1'

(LISTEN) Reverse VNC connection from IP: ::1  2015/01/05 12:54:52
   Hostname: localhost

ssvncviewer -listen: Listening on port 5500
ssvncviewer -listen: Cmdline errors are not reported until a connection comes 
in.


2015/01/05 12:54:52 select() start ...

Proto: RFB 003.008

Connected to RFB server, using protocol version 3.8

SelectSecurityType:
  sec-type[0]1  (rfbSecTypeNone)
Security-Type:   1  (rfbSecTypeNone)  Latency: 0.13 ms
No VNC authentication needed
VNC authentication succeeded (0) for rfbSecTypeNone (RFB 3.8)

Desktop name xxx:0

VNC server default format:
  32 bits per pixel.  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor.  Pixel format:
  32 bits per pixel.  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
geometry: 1596x876+0+0 ycrop: 0
create_image()
try_create_image: shm image create fail: image == NULL
try_create_image: created *non-shm* image: 1600x900
try_create_image: image-bytes_per_line: 6400

*** stack smashing detected ***: /usr/bin/ssvncviewer terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7303f)[0x763b103f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x76434147]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x76434110]
/usr/bin/ssvncviewer[0x42eb98]
/usr/bin/ssvncviewer[0x41faee]
/usr/bin/ssvncviewer[0x4089fb]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7635fb45]
/usr/bin/ssvncviewer[0x408e2f]


I debugged vncviewer and found the cause of the stack smashing in
source file vnc_unixsrc/vncviewer/sockets.c, function SameMaching.

According to http://man7.org/linux/man-pages/man2/getpeername.2.html,
getpeername can increase the value of the supplied addrlen. This new
value is then passed to getsockname which now assumes that myaddr is
larger than it is in reality.

Here is a fixed version of the buggy function:

Bool
SameMachine(int sock)
{
  struct sockaddr_in peeraddr, myaddr;
  int addrlen;

  addrlen = sizeof(struct sockaddr_in);
  getpeername(sock, (struct sockaddr *)peeraddr, addrlen);
  addrlen = sizeof(struct sockaddr_in);
  getsockname(sock, (struct sockaddr *)myaddr, addrlen);

  return (peeraddr.sin_addr.s_addr == myaddr.sin_addr.s_addr);
}

Cheers
Stefan

-- System Information:
Debian Release: 8.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ssvnc depends on:
ii  bind9-host [host]  1:9.9.5.dfsg-7
ii  libc6  2.19-13
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.3.1-11
ii  libsm6 2:1.2.2-1+b1
ii  libssl1.0.01.0.1j-1
ii  libx11-6   2:1.6.2-3
ii  libxaw72:1.0.12-2+b1
ii  libxext6   2:1.3.3-1
ii  libxmu62:1.1.2-1
ii  libxpm41:3.5.11-1+b1
ii  libxt6 1:1.1.4-1+b1
ii  openssh-client 1:6.7p1-3
ii  openssl1.0.1j-1
ii  procps 2:3.3.9-8
ii  psmisc 22.21-2
ii  stunnel4   3:5.06-2
ii  tk 8.6.0+8
ii  xterm  312-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages ssvnc recommends:
ii  default-jre [java5-runtime]2:1.7-52
ii  openjdk-7-jre [java5-runtime]  7u71-2.5.3-2

ssvnc 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#774624: xtightvncviewer: Crash (stack smashing) of listening vncviewer

[Stefan Weil]

Package: tightvnc
Severity: important

TightVNC includes the same bug which was reported for ssvnc
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774622).

As the related source code is also identical, the fix given
in that bug report also applies to package tightvnc.

-- System Information:
Debian Release: 8.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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


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

Bug#774622: Package tightvnc is also affected

[Stefan Weil]

Package ssvnc is based on TightVNC, and Debian's package tightvnc shows 
the same bug.



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

Bug#681380: powertop: Crash (SIGSEGV) on ARM hosts

[Stefan Weil]

Package: powertop
Version: 2.0-0.2
Severity: normal
Tags: upstream patch

Powertop crashes because /proc/cpuinfo on ARM differs from the
usual Intel /proc/cpuinfo, so a function is called with a bad
processor number (-1).

A patch was sent to the powertop mailing list.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: armel (armv6l)

Kernel: Linux 3.1.9+ (PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages powertop depends on:
ii  libc6 2.13-33
ii  libgcc1   1:4.7.1-2
ii  libncursesw5  5.9-10
ii  libnl-3-200   3.2.7-4
ii  libnl-genl-3-200  3.2.7-4
ii  libpci3   1:3.1.9-5
ii  libstdc++64.7.1-2
ii  libtinfo5 5.9-10
ii  zlib1g1:1.2.7.dfsg-13

powertop recommends no packages.

Versions of packages powertop suggests:
pn  cpufrequtils   none
pn  laptop-mode-tools  none

-- no debconf information
From 46702a2bb5f6adb6c4735bebb69ec2828d695ef6 Mon Sep 17 00:00:00 2001
From: Stefan Weil s...@weilnetz.de
Date: Thu, 12 Jul 2012 20:10:32 +0200
Subject: [PATCH] Fix crash on Linux ARM hosts

/proc/cpuinfo on ARM hosts is different and resulted
in a call of handle_one_cpu() with number == -1
which finally raised a SIGSEGV crash (noticed on
Debian Wheezy for ARM).

Fix this by testing the value of number.

After number was used, it is now reset to -1 just to make
sure that the new test also works for a potential 2nd cpu
with unexpected information in /proc/cpuinfo.

Signed-off-by: Stefan Weil s...@weilnetz.de
---

Please note that even with this patch, powertop on ARM will
only work partially: handle_one_cpu() is never called,
so there is no cpu information.

For ARM hosts with a single core cpu (the most common case),
using a case insensitive compare for 'processor' would work.

This is my /proc/cpuinfo:

Processor	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: swp half thumb fastmult vfp edsp java tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2708
Revision	: 0002
Serial		: e16a63c5

For multicore cpus, a better 2nd patch is needed.
If anybody has a /proc/cpuinfo of that kind, please tell me
the format - otherwise I'll have to look in the Linux source.

Regards,
Stefan Weil

 src/cpu/cpu.cpp |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/cpu/cpu.cpp b/src/cpu/cpu.cpp
index 4096835..d08bdcd 100644
--- a/src/cpu/cpu.cpp
+++ b/src/cpu/cpu.cpp
@@ -271,8 +271,11 @@ void enumerate_cpus(void)
 			}
 		}
 		if (strncasecmp(line, bogomips\t, 9) == 0) {
-			handle_one_cpu(number, vendor, family, model);
-			set_max_cpu(number);
+			if (number = 0) {
+handle_one_cpu(number, vendor, family, model);
+set_max_cpu(number);
+number = -1;
+			}
 		}
 	}
 
-- 
1.7.10

Bug#649125: scite: Crash caused by bug in CPP lexer

[Stefan Weil]

Package: scite
Version: 2.25-1
Severity: important

There is a bug in the Scintilla library which parses C, C++ code.
This line of C preprocessor code raises a fatal exception when
it is entered in a C or C++ file opened by SciTE:

#if defined(NAME value

The bug was introduced with Hg changeset 3306:73a86726763b (July 2010)
and only recently fixed (November 2011), so the latest SciTE versions
(from 2.20 up to 3.0.1) contain the bug.

Changeset 3944:933933c7a390 fixes the bug.

-- System Information:
Debian Release: 6.0.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-proposed-updates'), (500, 
'proposed-updates'), (500, 'oldstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages scite depends on:
ii  libc6  2.11.2-10 Embedded GNU C Library: Shared lib
ii  libcairo2  1.8.10-6  The Cairo 2D vector graphics libra
ii  libgcc11:4.4.5-8 GCC support library
ii  libgdk-pixbuf2.0-0 2.24.0-1  GDK Pixbuf library
ii  libglib2.0-0   2.28.6-1  The GLib library of C routines
ii  libgtk2.0-02.24.8-2  GTK+ graphical user interface libr
ii  libpango1.0-0  1.28.3-1+squeeze2 Layout and rendering of internatio
ii  libstdc++6 4.6.2-4   GNU Standard C++ Library v3

scite recommends no packages.

scite 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#629101: geneweb: Preconfigure reports missing /usr/bin/isoquery during installation

[Stefan Weil]

Package: geneweb
Version: 5.02~cvs20091031-8
Severity: normal

During installation of geneweb, it complains about missing /usr/bin/isoquery:

Vorkonfiguration der Pakete ...
/tmp/geneweb.config.107861: 120: /usr/bin/isoquery: not found
/tmp/geneweb.config.107861: 126: /usr/bin/isoquery: not found

The missing file /usr/bin/isoquery is installed later during the installation
process, but obviously the preconfiguration tries to access it before it
is installed.


-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-proposed-updates'), (500, 
'proposed-updates'), (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages geneweb depends on:
ii  adduser 3.112+nmu2   add and remove users and groups
ii  debconf [debconf-2.0]   1.5.36.1 Debian configuration management sy
ii  iso-codes   3.23-1   ISO language, territory, currency,
ii  isoquery1.4-1Search and display various ISO cod
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  perl-base [perl5-base]  5.10.1-17minimal Perl system

geneweb recommends no packages.

Versions of packages geneweb suggests:
ii  epiphany-browser [www 2.30.6-1   Intuitive GNOME web browser
ii  gwsetup   5.02~cvs20091031-8 utilities to configure and manipul
pn  gwtp  none (no description available)
ii  iceweasel [www-browse 3.5.16-5   Web browser based on Firefox
ii  konqueror [www-browse 4:4.4.5-2  advanced file manager, web browser
ii  lynx-cur [www-browser 2.8.8dev.5-1   Text-mode WWW Browser with NLS sup
ii  menu  2.1.44 generates programs menu for all me
ii  w3m [www-browser] 0.5.2-9WWW browsable pager with excellent

-- debconf information:
  geneweb/run_mode: Always on
  geneweb/remainingdir:
  geneweb/remove_databases: false
  geneweb/port: 2317
  geneweb/lang: German



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

Bug#624249: myspell-en-gb: Wrong spelling writeable (correct spelling writable is missing)

[Stefan Weil]

Package: myspell-en-gb
Version: 1:3.3.0-3
Severity: normal

Writeable instead of writable is a very common spelling bug.

myspell-en-gb supports this bug because it does not include the correct
version but only the wrong spelling. That is really bad for a spell-checker.

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-proposed-updates'), (500, 
'proposed-updates'), (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages myspell-en-gb depends on:
ii  dictionaries-common [openoffi 1.5.17 Common utilities for spelling dict

myspell-en-gb recommends no packages.

myspell-en-gb 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#585865: SCiTE with LUA support builds fine on amd64, please re-enable

[Stefan Weil]

Package: scite
Version: 2.03-1
Severity: important

I can confirm that it's possible to build a Debian package for amd64
with support for lua scripting and that this fixes the reported problem.

The compiler warnings (cast from int to pointer) which were the initial
reason why lua support was removed in Debian no longer occur.

How can I help fixing this issue in Debian's SciTE package?

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'stable-proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.37-rc7-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages scite depends on:
ii  libatk1.0-0   1.30.0-1   The ATK accessibility toolkit
ii  libc6 2.11.2-7   Embedded GNU C Library: Shared lib
ii  libcairo2 1.8.10-6   The Cairo 2D vector graphics libra
ii  libfontconfig12.8.0-2.1  generic font configuration library
ii  libfreetype6  2.4.2-2.1  FreeType 2 font engine, shared lib
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libglib2.0-0  2.24.2-1   The GLib library of C routines
ii  libgtk2.0-0   2.20.1-2   The GTK+ graphical user interface 
ii  libpango1.0-0 1.28.3-1   Layout and rendering of internatio
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3

scite recommends no packages.

scite 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#589438: powertop: Crash with new linux kernel (2.6.35)

[Stefan Weil]

Package: powertop
Version: 1.11-1
Severity: normal
Tags: lenny

powertop 1.11-1 is limited to 5000 lines in the kernel config file 
(/boot/config-*).
The latest kernel exceeds this hard coded limit:

# wc /boot/config-2.6.35-rc5-amd64 
  5024   8611 115367 /boot/config-2.6.35-rc5-amd64

Newer versions of powertop increase the limit to 1 but still crash when the
limit is exceeded (see file config.c).

This is a potential security problem (out-of-bounds array access).

I have just sent a patch which fixes the bug to Auke Kok (author of powertop).

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'proposed-updates'), (500, 'experimental'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.35-rc5-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages powertop depends on:
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libncursesw5  5.7+20100313-2 shared libraries for terminal hand

powertop recommends no packages.

Versions of packages powertop suggests:
ii  cpufrequtils  007-1  utilities to deal with the cpufreq
pn  laptop-mode-tools none (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#588696: iceowl: Localizations are missing

[Stefan Weil]

Package: iceowl
Version: 1.0~b1+dfsg-4
Severity: wishlist
Tags: l10n

Iceowl and iceowl-extension only includes the localization for english.
Other languages should be either included or provided in separate packages.
The existing localization packages for iceowl are too old for 
iceowl-1.0~b1+dfsg-4.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'proposed-updates'), (500, 'experimental'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages iceowl depends on:
ii  calendar-timezones  1.0~b1+dfsg-4Timezone Extension for Sunbird/Ice
ii  libasound2  1.0.23-1 shared library for ALSA applicatio
ii  libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii  libbonobo2-02.24.3-1 Bonobo CORBA interfaces library
ii  libc6   2.11.2-2 Embedded GNU C Library: Shared lib
ii  libcairo2   1.8.10-4 The Cairo 2D vector graphics libra
ii  libdbus-1-3 1.2.24-1 simple interprocess messaging syst
ii  libdbus-glib-1-20.86-1   simple interprocess messaging syst
ii  libfontconfig1  2.8.0-2.1generic font configuration library
ii  libfreetype62.3.11-1 FreeType 2 font engine, shared lib
ii  libgcc1 1:4.4.4-6GCC support library
ii  libgconf2-4 2.28.1-3 GNOME configuration database syste
ii  libglib2.0-02.24.1-1 The GLib library of C routines
ii  libgnome2-0 2.30.0-1 The GNOME library - runtime files
ii  libgnomevfs2-0  1:2.24.3-1   GNOME Virtual File System (runtime
ii  libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface 
ii  libjpeg62   6b-16.1  The Independent JPEG Group's JPEG 
ii  libnspr4-0d 4.8.4-1  NetScape Portable Runtime Library
ii  libnss3-1d  3.12.6-2 Network Security Service libraries
ii  liborbit2   1:2.14.18-0.1libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0   1.28.1-1 Layout and rendering of internatio
ii  libpopt01.16-1   lib for parsing cmdline parameters
ii  libsqlite3-03.6.23.1-4   SQLite 3 shared library
ii  libstdc++6  4.4.4-6  The GNU Standard C++ Library v3
ii  libx11-62:1.3.3-3X11 client-side library
ii  libxrender1 1:0.9.5-2X Rendering Extension client libra
ii  libxt6  1:1.0.7-1X11 toolkit intrinsics library
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages iceowl recommends:
ii  calendar-google-provider   1.0~b1+dfsg-4 Google Calendar support for lighti

iceowl 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#559738: aptitude: Aptitude display untranslated Yes/No question,

[Stefan Weil]

The same kind of bug also appears with a german (and french) environments:

LANG=de_DE.UTF-8 aptitude

results in

Aptitude wirklich beenden?
 [ Yes ] [ No ]

and expects 'j' (ja) as answer to terminate aptitude.

I tried to debug it and saw that libcwidget looks for
a translation for Yes (and No) but fails to find one.

Regards,
Stefan Weil



-- Package-specific info:
aptitude 0.6.1.5 compiled at Feb  3 2010 06:34:23
Compiler: g++ 4.4.3
Compiled against:
  apt version 4.8.0
  NCurses version 5.7
  libsigc++ version: 2.2.4.2
  Ept support enabled.
  Gtk+ support disabled.

Current library versions:
  NCurses version: ncurses 5.7.20090803
  cwidget version: 0.5.16
  Apt version: 4.8.0
linux-vdso.so.1 =  (0x7fff1af47000)
libapt-pkg-libc6.9-6.so.4.8 =
/usr/lib/libapt-pkg-libc6.9-6.so.4.8 (0x7f22d06be000)
libncursesw.so.5 = /lib/libncursesw.so.5 (0x7f22d046d000)
liblog4cxx.so.10 = /usr/lib/liblog4cxx.so.10 (0x7f22d007f000)
libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7f22cfe7a000)
libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7f22cfbae000)
libept.so.0 = /usr/lib/libept.so.0 (0x7f22cf936000)
libxapian.so.15 = /usr/lib/libxapian.so.15 (0x7f22cf5e5000)
libz.so.1 = /usr/lib/libz.so.1 (0x7f22cf3ce000)
libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0x7f22cf14)
libboost_iostreams.so.1.40.0 =
/usr/lib/libboost_iostreams.so.1.40.0 (0x7f22cef35000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7f22ced19000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f22cea08000)
libm.so.6 = /lib/libm.so.6 (0x7f22ce786000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f22ce57)
libc.so.6 = /lib/libc.so.6 (0x7f22ce21b000)
libutil.so.1 = /lib/libutil.so.1 (0x7f22ce018000)
libdl.so.2 = /lib/libdl.so.2 (0x7f22cde14000)
libaprutil-1.so.0 = /usr/lib/libaprutil-1.so.0 (0x7f22cdbf)
libdb-4.8.so = /usr/lib/libdb-4.8.so (0x7f22cd876000)
libapr-1.so.0 = /usr/lib/libapr-1.so.0 (0x7f22cd63e000)
libbz2.so.1.0 = /lib/libbz2.so.1.0 (0x7f22cd42d000)
librt.so.1 = /lib/librt.so.1 (0x7f22cd225000)
/lib64/ld-linux-x86-64.so.2 (0x7f22d09a9000)
libuuid.so.1 = /lib/libuuid.so.1 (0x7f22cd02)
libcrypt.so.1 = /lib/libcrypt.so.1 (0x7f22ccde9000)
libexpat.so.1 = /usr/lib/libexpat.so.1 (0x7f22ccbc1000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500,
'proposed-updates'), (500, 'experimental'), (500, 'unstable'), (500,
'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages aptitude depends on:
ii  apt [libapt-pkg-libc6.9 0.7.25.3 Advanced front-end for dpkg
ii  libboost-iostreams1.40. 1.40.0-6+b1  Boost.Iostreams Library
ii  libc6   2.10.2-6 Embedded GNU C Library:
Shared lib
ii  libcwidget3 0.5.16-3 high-level terminal
interface libr
ii  libept0 0.5.30   High-level library for
managing De
ii  libgcc1 1:4.4.2-9GCC support library
ii  liblog4cxx100.10.0-1.1   A logging library for C++
ii  libncursesw55.7+20090803-2   shared libraries for
terminal hand
ii  libsigc++-2.0-0c2a  2.2.4.2-1type-safe Signal Framework
for C++
ii  libsqlite3-03.6.22-1 SQLite 3 shared library
ii  libstdc++6  4.4.2-9  The GNU Standard C++ Library v3
ii  libxapian15 1.0.18-1 Search engine library
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime





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

Bug#546819: splashy: Splashy shows: caught signal 8 (at addr, integer divide by zero)

[Stefan Weil]

The same thing happens on my system with similar packages installed.
I only get this crash with vga=795 (resolution 1280x1024), but not
with vga resolution 640x480.

The crash happens in libdirectfb-1.2.0:

Stack:
(gdb) i s
#0  0x7f13ef04f5db in raise (sig=value optimized out) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:41
#1  0x7f13ef266a29 in signal_handler (num=8, info=0x0, foo=value
optimized out) at ../../../lib/direct/signals.c:411
#2  signal handler called
#3  0x7f13ef6dce53 in dfb_surface_lock_buffer (surface=0xb59830,
role=CSBR_BACK, access=CSAF_CPU_WRITE, ret_lock=0x7f13ec0556c0) at
../../../src/core/surface.c:546
#4  0x7f13ec4949e5 in IDirectFBImageProvider_PNG_RenderTo
(thiz=value optimized out, destination=value optimized out,
dest_rect=value optimized out)
at
../../../interfaces/IDirectFBImageProvider/idirectfbimageprovider_png.c:354
#5  0x7f13f005dcc4 in splashy_change_splash () from /lib/libsplashy.so.1
#6  0x7f13f005ddd5 in ?? () from /lib/libsplashy.so.1
#7  0x7f13f005dfed in splashy_printline_s () from /lib/libsplashy.so.1
#8  0x004026bc in ?? ()
#9  0x004029b9 in ?? ()
#10 0x00402fb5 in ?? ()
#11 0x7f13ef047f9a in start_thread (arg=value optimized out) at
pthread_create.c:300
#12 0x7f13eedbc56d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#13 0x in ?? ()

(gdb) disas dfb_surface_lock_buffer
Dump of assembler code for function dfb_surface_lock_buffer:
0x7f13ef6dce00 dfb_surface_lock_buffer+0: mov%r13,-0x18(%rsp)
0x7f13ef6dce05 dfb_surface_lock_buffer+5: lea0xe8(%rdi),%r13
0x7f13ef6dce0c dfb_surface_lock_buffer+12:mov   
%rbx,-0x30(%rsp)
0x7f13ef6dce11 dfb_surface_lock_buffer+17:mov   
%rbp,-0x28(%rsp)
0x7f13ef6dce16 dfb_surface_lock_buffer+22:mov   
%r12,-0x20(%rsp)
0x7f13ef6dce1b dfb_surface_lock_buffer+27:mov%rdi,%rbx
0x7f13ef6dce1e dfb_surface_lock_buffer+30:mov   
%r14,-0x10(%rsp)
0x7f13ef6dce23 dfb_surface_lock_buffer+35:mov   
%r15,-0x8(%rsp)
0x7f13ef6dce28 dfb_surface_lock_buffer+40:mov%r13,%rdi
0x7f13ef6dce2b dfb_surface_lock_buffer+43:sub$0x38,%rsp
0x7f13ef6dce2f dfb_surface_lock_buffer+47:mov%esi,%ebp
0x7f13ef6dce31 dfb_surface_lock_buffer+49:mov%edx,%r15d
0x7f13ef6dce34 dfb_surface_lock_buffer+52:mov%rcx,%r14
0x7f13ef6dce37 dfb_surface_lock_buffer+55:mov$0x16,%r12d
0x7f13ef6dce3d dfb_surface_lock_buffer+61:callq 
0x7f13ef68e2a0 fusion_skirmish_prev...@plt
0x7f13ef6dce42 dfb_surface_lock_buffer+66:test   %eax,%eax
0x7f13ef6dce44 dfb_surface_lock_buffer+68:jne   
0x7f13ef6dce7e dfb_surface_lock_buffer+126
0x7f13ef6dce46 dfb_surface_lock_buffer+70:add   
0x244(%rbx),%ebp
0x7f13ef6dce4c dfb_surface_lock_buffer+76:xor%edx,%edx
0x7f13ef6dce4e dfb_surface_lock_buffer+78:mov%r15d,%esi
0x7f13ef6dce51 dfb_surface_lock_buffer+81:mov%ebp,%eax
0x7f13ef6dce53 dfb_surface_lock_buffer+83:divl   0x228(%rbx)
0x7f13ef6dce59 dfb_surface_lock_buffer+89:mov%edx,%edx
0x7f13ef6dce5b dfb_surface_lock_buffer+91:movslq
0x22c(%rbx,%rdx,4),%rax
0x7f13ef6dce63 dfb_surface_lock_buffer+99:mov%r14,%rdx
0x7f13ef6dce66 dfb_surface_lock_buffer+102:   mov   
0x1f8(%rbx,%rax,8),%rdi
0x7f13ef6dce6e dfb_surface_lock_buffer+110:   callq 
0x7f13ef68d1b0 dfb_surface_buffer_l...@plt
0x7f13ef6dce73 dfb_surface_lock_buffer+115:   mov%r13,%rdi
0x7f13ef6dce76 dfb_surface_lock_buffer+118:   mov%eax,%r12d
0x7f13ef6dce79 dfb_surface_lock_buffer+121:   callq 
0x7f13ef68df10 fusion_skirmish_dism...@plt
0x7f13ef6dce7e dfb_surface_lock_buffer+126:   mov%r12d,%eax
0x7f13ef6dce81 dfb_surface_lock_buffer+129:   mov   
0x8(%rsp),%rbx
0x7f13ef6dce86 dfb_surface_lock_buffer+134:   mov   
0x10(%rsp),%rbp
0x7f13ef6dce8b dfb_surface_lock_buffer+139:   mov   
0x18(%rsp),%r12
0x7f13ef6dce90 dfb_surface_lock_buffer+144:   mov   
0x20(%rsp),%r13
0x7f13ef6dce95 dfb_surface_lock_buffer+149:   mov   
0x28(%rsp),%r14
0x7f13ef6dce9a dfb_surface_lock_buffer+154:   mov   
0x30(%rsp),%r15
0x7f13ef6dce9f dfb_surface_lock_buffer+159:   add$0x38,%rsp
0x7f13ef6dcea3 dfb_surface_lock_buffer+163:   retq
End of assembler dump.




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

Bug#472574: jack support should be enabled for AMD64

[Stefan Weil]

Hi,

I have the same problem like Frans.

Jack support is still not working with mixxx in Debian Lenny on amd64.
The documentation says that it should be supported.

And this report says that the problem is caused by portaudio19:
https://bugs.launchpad.net/ubuntu/+source/portaudio19/+bug/183011

How can I help to fix this?

Regards

Stefan




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

Bug#472574: jack support should be enabled for AMD64

[Stefan Weil]

Stefan Weil schrieb:
 Hi,

 I have the same problem like Frans.

 Jack support is still not working with mixxx in Debian Lenny on amd64.
 The documentation says that it should be supported.

 And this report says that the problem is caused by portaudio19:
 https://bugs.launchpad.net/ubuntu/+source/portaudio19/+bug/183011

 How can I help to fix this?

 Regards

 Stefan

   

The code in portaudio19-19+svn20071022/src/common/pa_ringbuffer.c
contains support for amd64:

#   elif defined( __i386__ ) || defined( __i486__ ) || defined( __i586__
) || defined( __i686__ ) || defined( __x86_64__ )
#  define PaUtil_FullMemoryBarrier()  asm volatile(mfence:::memory)
#  define PaUtil_ReadMemoryBarrier()  asm volatile(lfence:::memory)
#  define PaUtil_WriteMemoryBarrier() asm volatile(sfence:::memory)

So there is no reason to disable jack support for amd64.

I modified debian/rules to enable jack for amd64, too.
With this modification, mixxx works with jack.

Regards,

Stefan




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

Bug#467127: post-install fails with grub-probe: error: Cannot get the real path of `/dev/sda'

[Stefan Weil]

Robert Millan schrieb:

Please copy-paste the exact command and error you get.


I should mention a point missing in my last mails which maybe is important:
the removable medium must contain a partition with an operating system.

Here is my test scenario (see comments) with system output and error 
messages.


# PC with SATA harddisk, USB card reader, no CF or SD card inserted.

# grub-mkdevicemap
# cat /boot/grub/device.map
(hd0)   /dev/sda


# USB card reader, CF card now inserted.
# The CF card provides an EXT3 partition /dev/sdb1 with DEBIAN Linux.
# Reinstall latest grub-pc (gives same error like upgrade from older 
version).


# LANG=C apt-get --reinstall install grub-pc
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 5 not 
upgraded.

Need to get 0B/1101kB of archives.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Preconfiguring packages ...
(Reading database ... 253220 files and directories currently installed.)
Preparing to replace grub-pc 1.96+20080413-1 (using 
.../grub-pc_1.96+20080413-1_amd64.deb) ...

Unpacking replacement grub-pc ...
Setting up grub-pc (1.96+20080413-1) ...
Updating /boot/grub/grub.cfg ...
Found Debian background: debian-blueish-wallpaper-640x480.png
Found linux image: /boot/vmlinuz-2.6.24-1-amd64
Found initrd image: /boot/initrd.img-2.6.24-1-amd64
Found linux image: /boot/vmlinuz-2.6.22-3-amd64
Found initrd image: /boot/initrd.img-2.6.22-3-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found openSUSE 10.3 (i586) on /dev/sda5
Found Debian GNU/Linux (lenny/sid) on /dev/sda8
Found Debian GNU/Linux (4.0) on /dev/sdb1
dpkg: error processing grub-pc (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
grub-pc
E: Sub-process /usr/bin/dpkg returned an error code (1)



The failing command hierarchy is given here:

/var/lib/dpkg/info/grub-pc.postinst configure
-- /usr/sbin/update-grub
 /etc/grub.d/30_os-prober
-- grub-probe --target=drive --device /dev/sdb1

grub-probe fails like this:

# grub-probe --target=drive --device /dev/sdb1
grub-probe: error: Cannot find a GRUB drive for /dev/sdb1.  Check your 
device.map.


# device.map is unchanged, see previous output




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#467127: post-install fails with grub-probe: error: Cannot get the real path of `/dev/sda'

[Stefan Weil]

A very similar (maybe the same) error occurs with grub-pc 1.96+20080413-1.

post-install fails with grub-probe in these two cases:

1. An earlier installation was done while a removable medium (in my 
case: debian

   installation CDROM) was mounted. The device (/dev/hda) will be listed in
   /boot/grub/device.map. A later upgrade of grub-pc (maybe grub, too) 
fails

   when there is no longer a medium available.

   Possible workaround which enables configure / post-install: mount a 
CROM.


2. An earlier installation was done while a removable media (in my case: 
SD flash card)
   was not in my card reader. So there is no entry for /dev/sda in 
device.map.

   When I upgraded grub-pc while there was a SD card in the card reader,
   grub-probe probed /dev/sda (the flash disk) and failed because of 
the missing entry.


   Possible workaround which enables configure / post-install: remove 
SD card.


Maybe grub-probe should ignore errors from any removable medium.

Stefan Weil




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#467127: post-install fails with grub-probe: error: Cannot get the real path of `/dev/sda'

[Stefan Weil]

Stefan Weil wrote:


2. An earlier installation was done while a removable media (in my 
case: SD flash card)
   was not in my card reader. So there is no entry for /dev/sda in 
device.map.

   When I upgraded grub-pc while there was a SD card in the card reader,
   grub-probe probed /dev/sda (the flash disk) and failed because of 
the missing entry.


   Possible workaround which enables configure / post-install: remove 
SD card.


Maybe grub-probe should ignore errors from any removable medium.

Stefan Weil



Correction: with SD card, this is the call which fails during post-install:
grub-probe --target=drive --device /dev/sdb1

(the SD card is /dev/sdb, and has a partition /dev/sdb1)

grub-mkdevicemap would change device.map from this one:

(hd0)   /dev/sda

into this new one:

(hd0)   /dev/sda
(hd1)   /dev/sdb

/dev/sda is my SATA harddisk. With the new device.map,
post-install will fail when there is no SD card inserted.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#474581: openoffice.org-core: openoffice crashs when opening a document with hyphenation

[Stefan Weil]

Package: openoffice.org-core
Version: 1:2.4.0-3
Severity: important
Tags: patch

openoffice crashs when the first document which is opened contains lines with 
hyphenation
and automatic spell checking is activated.

This is caused by conflicting declarations of array encds in the shared 
libraries
/usr/lib/libhyphen.so.0.1.0 (package libhyphen0 2.3.1-2) and
/usr/lib/openoffice/program/libhunspell.so (package openoffice.org-core, all 
(?) versions).
The crash also occurs with openoffice.org-core 1:2.3.1-5.

The crash occurs in function get_current_cs (from libhunspell.so).
When libhyphen.so.0.1.0 was loaded before libhunspell.so, get_current_cs
iterates on array encds from libhyphen.so.0.1.0. which has less elements than
encds from libhunspell.so. So strcmp is called with a null pointer.

Possible patches:
* add a break statement in get_current_cs for loop
* maybe encds can be declared static
* use identical declarations of encds in both packages

Correct encds in debugger:
(gdb) x/38gx encds
0x2aaabb01c6c0 encds: 0x2aaabae16322  0x2aaabb0193c0
0x2aaabb01c6d0 encds+16:  0x2aaabae16538  0x2aaabb0196c0
0x2aaabb01c6e0 encds+32:  0x2aaabae16542  0x2aaabb0199c0
0x2aaabb01c6f0 encds+48:  0x2aaabae1654c  0x2aaabb019cc0
0x2aaabb01c700 encds+64:  0x2aaabae16556  0x2aaabb019fc0
0x2aaabb01c710 encds+80:  0x2aaabae16560  0x2aaabb01a2c0
0x2aaabb01c720 encds+96:  0x2aaabae1656a  0x2aaabb01a5c0
0x2aaabb01c730 encds+112: 0x2aaabae16574  0x2aaabb01a8c0
0x2aaabb01c740 encds+128: 0x2aaabae1657e  0x2aaabb01abc0
0x2aaabb01c750 encds+144: 0x2aaabae16588  0x2aaabb01aec0
0x2aaabb01c760 encds+160: 0x2aaabae16593  0x2aaabb01b1c0
0x2aaabb01c770 encds+176: 0x2aaabae1659a  0x2aaabb01b4c0
0x2aaabb01c780 encds+192: 0x2aaabae165a1  0x2aaabb01b7c0
0x2aaabb01c790 encds+208: 0x2aaabae165b2  0x2aaabb01bac0
0x2aaabb01c7a0 encds+224: 0x2aaabae165bd  0x2aaabb01bdc0
0x2aaabb01c7b0 encds+240: 0x2aaabae165c8  0x2aaabb01c0c0
0x2aaabb01c7c0 encds+256: 0x2aaabae165d3  0x2aaabb01c3c0
0x2aaabb01c7d0: 0x  0x
0x2aaabb01c7e0 lang2enc:  0x2aaabae165e4  0x2aaabae16364

Wrong encds in debugger:
(gdb) x/36gx encds
0x2aaab8cde9e0 encds: 0x2aaab8adb8e8  0x2aaab8cdc2e0
0x2aaab8cde9f0 encds+16:  0x2aaab8adb8f2  0x2aaab8cdc5e0
0x2aaab8cdea00 encds+32:  0x2aaab8adb8fc  0x2aaab8cdc8e0
0x2aaab8cdea10 encds+48:  0x2aaab8adb906  0x2aaab8cdcbe0
0x2aaab8cdea20 encds+64:  0x2aaab8adb910  0x2aaab8cdcee0
0x2aaab8cdea30 encds+80:  0x2aaab8adb91a  0x2aaab8cdd1e0
0x2aaab8cdea40 encds+96:  0x2aaab8adb924  0x2aaab8cdd4e0
0x2aaab8cdea50 encds+112: 0x2aaab8adb92e  0x2aaab8cdd7e0
0x2aaab8cdea60 encds+128: 0x2aaab8adb938  0x2aaab8cddae0
0x2aaab8cdea70 encds+144: 0x2aaab8adb942  0x2aaab8cddde0
0x2aaab8cdea80 encds+160: 0x2aaab8adb94d  0x2aaab8cde0e0
0x2aaab8cdea90 encds+176: 0x2aaab8adb954  0x2aaab8cde3e0
0x2aaab8cdeaa0 encds+192: 0x2aaab8adb95c  0x2aaab8cde6e0
0x2aaab8cdeab0: 0x  0x
0x2aaab8cdeac0 lang2enc:  0x2aaab8adb967  0x2aaab8adb8e8
0x2aaab8cdead0 lang2enc+16:   0x2aaab8adb96a  0x2aaab8adb8f2
0x2aaab8cdeae0 lang2enc+32:   0x2aaab8adb96d  0x2aaab8adb8e8
0x2aaab8cdeaf0 lang2enc+48:   0x2aaab8adb970  0x2aaab8adb8e8



-- Package-specific info:

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

Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages openoffice.org-core depends on:
ii  fontconfig 2.5.0-2   generic font configuration library
ii  libc6  2.7-10GNU C Library: Shared libraries
ii  libcairo2  1.4.14-1  The Cairo 2D vector graphics libra
ii  libcurl3   7.18.0-1  Multi-protocol file transfer libra
ii  libdb4.6   4.6.21-6  Berkeley v4.6 Database Libraries [
ii  libexpat1  1.95.8-4  XML parsing C library - runtime li
ii  libfreetype6   2.3.5-1+b1FreeType 2 font engine, shared lib
ii  libgcc11:4.3.0-1 GCC support library
ii  libglib2.0-0   2.16.1-2  The GLib library of C routines
ii  libgstreamer-plugins-b 0.10.17-3 GStreamer libraries from the base
ii  libgstreamer0.10-0 0.10.17-2 Core GStreamer libraries and eleme
ii  libgtk2.0-0

Bug#474581: Bugs #465767 and #474581 are identical

[Stefan Weil]

The reason for bug #465767 is described at bug #474581
(conflict between hyphenation and spelling correction code).
Sorry that I did not see your bug report when I wrote my new one.

You can check this by creating a simple document using hyphenation and 
try to load it as first document.


A workaround is to start openoffice with a document without hyphenation.
Then you can load the critical document without a crash.

Stefan




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#345146: wireless-tools: needs libiw28 27+28pre11-1

[Stefan Weil]

Package: wireless-tools
Version: 27+28pre11-1
Severity: normal
Tags: experimental


wireless-tools needs a newer version of libiw28.
Using libiw28 27+28pre9-1 (which satisfies the
current package dependencies) results in this error:

[EMAIL PROTECTED]:~$ /sbin/iwconfig wlan0
wlan0 IEEE 802.11-b  ESSID:WLAN  Nickname:WLAN
/sbin/iwconfig: symbol lookup error: /sbin/iwconfig: undefined symbol:
iw_sawap_ntop

After an update of libiw28, iwconfig works without error.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.14-2-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages wireless-tools depends on:
ii  libc6   2.3.5-8.1GNU C Library: Shared
libraries an
ii  libiw28 27+28pre11-1 Wireless tools - library

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]