Bug#1067630: Fix arbitrary Lisp execution vulnerability (CVE-2024-30202)

[Benjamin Moody]

Dear maintainers:

This bug report refers to a couple of distinct issues:

1. Evaluating arbitrary Lisp code when a file is opened.

2. Evaluating arbitrary LaTeX code in various circumstances.

While the second issue is important to consider, I'd like to
focus on the first part.  This is a grave security issue
affecting Debian stable, and the fix is simple.


To check whether or not you have a vulnerable version of
org-mode, create a file called "foo.org" containing the following
text:

#+MACRO: x (eval (syntax-propertize-rules ((insert (upcase "vulnerable\n")

Then open foo.org in Emacs.  If the word "VULNERABLE" appears,
you are using a vulnerable version.


Below is the patch from Emacs 29.3 that fixes this bug.  It
applies cleanly against the version in bookworm (1:28.2+1-15):

diff --git a/lisp/org/org-macro.el b/lisp/org/org-macro.el
index 776d162..0be51ee 100644
--- a/lisp/org/org-macro.el
+++ b/lisp/org/org-macro.el
@@ -109,6 +109,13 @@ previous one, unless VALUE is nil.  Return the updated 
list."
   (let ((new-templates nil))
 (pcase-dolist (`(,name . ,value) templates)
   (let ((old-definition (assoc name new-templates)))
+;; This code can be evaluated unconditionally, as a part of
+;; loading Org mode.  We *must not* evaluate any code present
+;; inside the Org buffer while loading.  Org buffers may come
+;; from various sources, like received email messages from
+;; potentially malicious senders.  Org mode might be used to
+;; preview such messages and no code evaluation from inside the
+;; received Org text should ever happen without user consent.
 (when (and (stringp value) (string-match-p "\\`(eval\\>" value))
   ;; Pre-process the evaluation form for faster macro expansion.
   (let* ((args (org-macro--makeargs value))
@@ -121,7 +128,7 @@ previous one, unless VALUE is nil.  Return the updated 
list."
  (cadr (read value))
(error
  (user-error "Invalid definition for macro %S" name)
-   (setq value (eval (macroexpand-all `(lambda ,args ,body)) t
+   (setq value `(lambda ,args ,body
 (cond ((and value old-definition) (setcdr old-definition value))
  (old-definition)
  (t (push (cons name (or value "")) new-templates)

Source: 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=befa9fcaae29a6c9a283ba371c3c5234c7f644eb

Please add this patch to the Emacs source package, and make a
security update, as soon as possible.

Bug#1060322: panic on poweroff

[Benjamin Moody]

> This happens with linux-image-5.10.0-26-amd64 (5.10.197-1).
> It does not happen with linux-image-5.10.0-27-amd64 (5.10.205-2).

Sorry, I of course meant to say the problem does *not* occur in
5.10.0-26.  It is a regression in 5.10.0-27.

Benjamin

Bug#1060322: linux-image-5.10.0-27-amd64: Panic on poweroff after upgrade from 5.10.0-26 to 5.10.0-27

[Benjamin Moody]

Package: src:linux
Version: 5.10.205-2
Severity: normal
X-Debbugs-Cc: benjamin.mo...@gmail.com

Dear Maintainer,

When I shut the machine down, it hits what looks like a kernel panic.
This happens with linux-image-5.10.0-26-amd64 (5.10.197-1).
It does not happen with linux-image-5.10.0-27-amd64 (5.10.205-2).

The messages scroll by very quickly, and the machine shuts off
immediately afterwards, so I can't read the messages and I have
no idea what they say.  Nothing is logged in /var/log/kern.log,
/var/log/debug, /var/log/messages, /var/log/syslog, or
/var/log/daemon.log.

Any ideas on how to troubleshoot would be welcome.

Hardware is a Thinkpad Helix 2nd generation.

-- Package-specific info:
** Version:
Linux version 5.10.0-27-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.205-2 (2023-12-31)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-27-amd64 
root=UUID=b5d1c7d2-b38b-475e-a0c8-5715770117e1 ro acpi.ec_no_wakeup=1 
intel_iommu=off quiet

** Tainted: I (2048)
 * workaround for bug in platform firmware applied

** Kernel log:
[   18.756638] intel_rapl_common: Found RAPL domain package
[   18.756640] intel_rapl_common: Found RAPL domain core
[   18.756642] intel_rapl_common: Found RAPL domain uncore
[   18.756643] intel_rapl_common: Found RAPL domain dram
[   18.780473] iwlwifi :06:00.0: Detected Intel(R) Dual Band Wireless AC 
7265, REV=0x210
[   18.796156] iwlwifi :06:00.0: Applying debug destination EXTERNAL_DRAM
[   18.796925] iwlwifi :06:00.0: Allocated 0x0040 bytes for firmware 
monitor.
[   18.848187] iTCO_vendor_support: vendor-support=0
[   18.852282] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   18.852347] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by 
hardware/BIOS
[   18.860820] iwlwifi :06:00.0: base HW address: 34:13:e8:4d:47:39
[   18.902943] rt286 i2c-INT343A:00: ASoC: sink widget DMIC1 overwritten
[   18.902953] rt286 i2c-INT343A:00: ASoC: source widget DMIC1 overwritten
[   18.922816] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   18.923168] thermal thermal_zone9: failed to read out thermal zone (-61)
[   18.926812] input: broadwell-rt286 Headset as 
/devices/platform/broadwell-audio/sound/card1/input29
[   18.960350] iwlwifi :06:00.0 wlp6s0: renamed from wlan0
[   19.029718] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: 
(null)
[   19.029725] ext4 filesystem being mounted at /boot supports timestamps until 
2038 (0x7fff)
[   19.198680] audit: type=1400 audit(1704814874.081:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=756 comm="apparmor_parser"
[   19.202994] audit: type=1400 audit(1704814874.085:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=755 
comm="apparmor_parser"
[   19.202999] audit: type=1400 audit(1704814874.085:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=755 comm="apparmor_parser"
[   19.206226] audit: type=1400 audit(1704814874.085:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=753 comm="apparmor_parser"
[   19.209635] audit: type=1400 audit(1704814874.089:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/redshift" pid=754 
comm="apparmor_parser"
[   19.209640] audit: type=1400 audit(1704814874.089:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=759 comm="apparmor_parser"
[   19.210724] audit: type=1400 audit(1704814874.093:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=758 comm="apparmor_parser"
[   19.215283] audit: type=1400 audit(1704814874.097:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=761 
comm="apparmor_parser"
[   19.215288] audit: type=1400 audit(1704814874.097:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=761 
comm="apparmor_parser"
[   19.215292] audit: type=1400 audit(1704814874.097:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=761 
comm="apparmor_parser"
[   19.335808] input: ACPI Virtual Keyboard Device as 
/devices/virtual/input/input30
[   19.612655] IPMI message handler: version 39.2
[   19.627458] ipmi device interface
[   19.653289] ipmi_si: IPMI System Interface driver
[   19.653414] ipmi_si: Unable to find any System Interface(s)
[   19.705884] mc: Linux media interface: v0.10
[   19.736819] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   19.736947] videodev: Linux video capture interface: v2.00
[   19.842638] usb-storage 2-1:1.0: USB Mass Storage device detected
[   19.848785] Bluetooth: Core ver 2.22
[   19.848820] NET: Registered protocol family 31
[   19.848821] 

Bug#699001: elpa-notmuch should depend on notmuch

[Benjamin Moody]

Package: elpa-notmuch
Version: 0.31.4-2
Followup-For: Bug #699001

Dear Maintainer,

The notmuch-emacs package has been replaced with elpa-notmuch.
However, this bug still seems relevant; M-x notmuch doesn't work if
notmuch isn't installed.  elpa-notmuch should at least have a
"Recommends: notmuch", or more likely a "Depends".

I have no idea whether the version coupling issue is still relevant.

Bug#1041365: mpd: Please enable the ffmpeg filter plugin

[Benjamin Moody]

Package: mpd
Version: 0.23.12-1+b1
Severity: wishlist
X-Debbugs-Cc: benjamin.mo...@gmail.com

Dear Maintainer,

Recent versions of mpd support an "ffmpeg" filter plugin, which allows
processing the audio using libavfilter.

Currently this feature is not available in Debian, because libavfilter
is not installed at build time.  It would be nice to add this feature,
which (as far as I can tell) simply requires adding 'libavfilter-dev'
to Build-Depends.

This does unfortunately add some sizable extra dependencies /
recommendations, which you might not want if you're running mpd on a
tiny headless server, but I'd guess most desktop systems have
libavfilter installed already.

Benjamin

Bug#1019849: python3-virtualenv: Please do not depend on python3-pip

[Benjamin Moody]

Package: python3-virtualenv
Version: 20.4.0+ds-2+deb11u1
Severity: normal

Dear Maintainer,

In older versions of Debian, python-virtualenv and python3-virtualenv
did not depend on the python-pip or python3-pip packages (only
python-pip-whl).

It is convenient to be able to install and use virtualenv *without*
having /usr/bin/pip and /usr/bin/pip3 installed, so that one does not
accidentally install stuff into ~/.local/lib while intending to use a
virtualenv prefix.

(I don't know of any reason a user would ever want to invoke the
/usr/bin/pip binary in connection with using virtualenv.)

It's not apparent why this dependency was added, since
python3-virtualenv now depends on *both* python3-pip and
python-pip-whl.  And the basic functionality, at least, of
/usr/bin/virtualenv works correctly after forcibly removing the
python3-pip package.

So please remove this dependency, or downgrade to a Suggests at best.

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/40 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 python3-virtualenv depends on:
ii  python-pip-whl  20.3.4-4+deb11u1
ii  python3 3.9.2-3
ii  python3-appdirs 1.4.4-1
ii  python3-distlib 0.3.2+really+0.3.1-0.1
ii  python3-distutils   3.9.2-1
ii  python3-filelock3.0.12-2
ii  python3-importlib-metadata  1.6.0-2
ii  python3-pip 20.3.4-4+deb11u1
ii  python3-pkg-resources   52.0.0-4
ii  python3-six 1.16.0-2

python3-virtualenv recommends no packages.

python3-virtualenv suggests no packages.

-- debconf-show failed

Bug#1016534: Bug #1016534: osk-sdl: "failed to open iris" cannot use it

[Benjamin Moody]

I noticed this too, although on my system (Intel HD Graphics 5300) it
seems to work with or without iris_dri.so.  However, I also needed to
patch SDL, because SDL's hardcoded pixel format (DRM_FORMAT_ARGB)
is not supported.

I also noticed that it would be better to use 'dri_inst' here instead
of 'copy_exec'; on amd64 just as on arm64, there are many *_dri.so
files that are duplicates (hard links, actually.)

Bug#1016146: osk-sdl: Physical keypresses visible on console after exiting

[Benjamin Moody]

Package: osk-sdl
Version: 0.67-1
Severity: normal
Tags: patch
X-Debbugs-Cc: benjamin.mo...@gmail.com

Dear Maintainer,

If osk-sdl is invoked from initramfs via 'osk-sdl-keyscript', and I
enter the passphrase using the *physical* keyboard, the keys I press
are echoed on the Linux console and are visible after osk-sdl exits.

(This is separate from the fact that osk-sdl itself logs hardware
keypresses when invoked with -v, which is a problem with the keyscript
in version 0.61.1-2 but has been fixed in 0.67-1.)

This appears to be a known bug in SDL
(https://github.com/libsdl-org/SDL/issues/2418); it's not clear to me
if this is somehow device-dependent.

A workaround is to do this:

--- osk-sdl-0.67/debian/initramfs/scripts/osk-sdl-keyscript
+++ osk-sdl-0.67/debian/initramfs/scripts/osk-sdl-keyscript
@@ -9,7 +9,13 @@
 
 plymouth hide-splash 2>/dev/null
 
+ttymode=$(stty -g)
+stty -echo -icanon min 0 time 0
+
 /usr/bin/osk-sdl -k -d "${CRYPTTAB_SOURCE}" -n "${CRYPTTAB_NAME}" -c 
/etc/osk.conf
 
+cat >/dev/null
+stty "$ttymode"
+
 plymouth show-splash 2>/dev/null
 

(Tested by rebuilding osk-sdl 0.67-1 on bullseye.)

'scripts/local-top/osk-sdl' probably has the same problem (as well as
the -v issue); I haven't tried it.

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, 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 osk-sdl depends on:
ii  cryptsetup2:2.3.7-1+deb11u1
ii  cryptsetup-initramfs  2:2.3.7-1+deb11u1
ii  fonts-dejavu-core 2.37-2
ii  libc6 2.31-13+deb11u3
ii  libcryptsetup12   2:2.3.7-1+deb11u1
ii  libegl1   1.3.2-1
ii  libgcc-s1 10.2.1-6
ii  libgl11.3.2-1
ii  libgles2  1.3.2-1
ii  libsdl2-2.0-0 2.0.14+dfsg2-3+deb11u1+bm1
ii  libsdl2-ttf-2.0-0 2.0.15+dfsg1-1
ii  libstdc++610.2.1-6

osk-sdl recommends no packages.

osk-sdl suggests no packages.

-- no debconf information

Bug#1014299: linux-image-5.10.0-15-amd64: No audio on Thinkpad Helix 2 (broadwell-rt286); "firmware ready timeout"

[Benjamin Moody]

The problem seems to be related to the IOMMU.

With kernel 5.10.0-16-amd64:

intel_iommu=off: sound and video both working
intel_iommu=on,intgpu_off (Debian default): video working, sound broken
intel_iommu=on: sound and video both broken

With kernel 4.19.0-21-amd64:

intel_iommu=off (Debian default): sound and video both working
intel_iommu=on,igfx_off: video working, sound broken
intel_iommu=on: sound working, video broken

So a workaround is to set 'intel_iommu=off' on the kernel command line.

However, given that the old driver (snd-soc-sst-haswell-pcm) works
with 'intel_iommu=on', perhaps this can be fixed for the new driver
(snd-soc-catpt) as well.

Bug#1014299: linux-image-5.10.0-15-amd64: No audio on Thinkpad Helix 2 (broadwell-rt286); "firmware ready timeout"

[Benjamin Moody]

Package: src:linux
Version: 5.10.120-1
Severity: normal
X-Debbugs-Cc: benjamin.mo...@gmail.com

Dear Maintainer,

On a Thinkpad Helix 2, the internal audio devices (speaker,
microphone, and headset port) work with kernel 4.19.0-20-amd64
(4.19.235-1), but are broken with kernel 5.10.0-15-amd64 (5.10.120-1).

For example:

pasuspender -- aplay -D plughw:CARD=broadwellrt286,DEV=0 \
 /usr/share/sounds/alsa/Front_Left.wav

This command works as expected on 4.19.0-20-amd64; on 5.10.0-15-amd64
it gives the error:

aplay: main:830: audio open error: Invalid argument

On the newer kernel, the following messages appear in dmesg:

intel_catpt INT3438:00: firmware: direct-loading firmware intel/IntcSST2.bin
intel_catpt INT3438:00: firmware ready timeout
intel_catpt INT3438:00: boot firmware failed: -110
intel_catpt INT3438:00: ASoC: error at snd_soc_pcm_component_pm_runtime_get 
on catpt-platform: -110
 Codec: ASoC: BE open failed -110
 System PCM: ASoC: failed to start some BEs -110

It looks like the broadwell-rt286 and other "soc" audio drivers were
somewhat restructured between these two kernel releases and I'm
guessing that's when this bug was introduced.

(Confusingly, the keyboard/dock (at least the "Ultrabook Pro" version)
has its own internal speaker which appears as a USB audio device.
That device seems to work properly, but is not so useful since it
doesn't have a headphone port or a microphone.)


-- Package-specific info:
** Version:
Linux version 5.10.0-15-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.120-1 (2022-06-09)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-15-amd64 
root=UUID=b5d1c7d2-b38b-475e-a0c8-5715770117e1 ro acpi.ec_no_wakeup=1 quiet

** Tainted: IOE (14336)
 * workaround for bug in platform firmware applied
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   17.359747] input: Wacom HID 5014 Finger as 
/devices/pci:00/INT3432:00/i2c-0/i2c-WCOM5014:00/0018:056A:5014.0003/input/input25
[   17.369935] wacom 0018:056A:5014.0003: hidraw2: I2C HID v1.00 Device 
[WCOM5014:00 056A:5014] on i2c-WCOM5014:00
[   17.370134] input: broadwell-rt286 Headset as 
/devices/platform/broadwell-audio/sound/card1/input23
[   17.419836] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: 
(null)
[   17.419875] ext4 filesystem being mounted at /boot supports timestamps until 
2038 (0x7fff)
[   17.426114] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input19
[   17.426838] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input20
[   17.468644] input: HDA Intel HDMI HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.0/sound/card0/input21
[   17.468932] input: Wacom HID 114 Pen as 
/devices/pci:00/INT3433:00/i2c-1/i2c-WCOM0009:00/0018:056A:0114.0005/input/input27
[   17.469009] input: HDA Intel HDMI HDMI/DP,pcm=10 as 
/devices/pci:00/:00:03.0/sound/card0/input22
[   17.469108] wacom 0018:056A:0114.0005: hidraw3: I2C HID v1.00 Mouse 
[WCOM0009:00 056A:0114] on i2c-WCOM0009:00
[   17.505093] iwlwifi :06:00.0: Detected Intel(R) Dual Band Wireless AC 
7265, REV=0x210
[   17.519332] iwlwifi :06:00.0: Applying debug destination EXTERNAL_DRAM
[   17.520172] iwlwifi :06:00.0: Allocated 0x0040 bytes for firmware 
monitor.
[   17.530215] iwlwifi :06:00.0: base HW address: 34:13:e8:4d:47:39
[   17.590916] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   17.591280] thermal thermal_zone10: failed to read out thermal zone (-61)
[   17.602813] iwlwifi :06:00.0 wlp6s0: renamed from wlan0
[   17.637654] audit: type=1400 audit(1656861896.225:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=736 comm="apparmor_parser"
[   17.640988] audit: type=1400 audit(1656861896.229:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=731 comm="apparmor_parser"
[   17.644701] audit: type=1400 audit(1656861896.233:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/redshift" pid=733 
comm="apparmor_parser"
[   17.648641] audit: type=1400 audit(1656861896.237:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=743 comm="apparmor_parser"
[   17.652794] audit: type=1400 audit(1656861896.241:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=734 
comm="apparmor_parser"
[   17.652803] audit: type=1400 audit(1656861896.241:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=734 comm="apparmor_parser"
[   17.652845] audit: type=1400 audit(1656861896.241:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 

Bug#1009193: manpages-dev: wrong _POSIX_C_SOURCE value in unlocked_stdio(3), flockfile(3)

[Benjamin Moody]

Package: manpages-dev
Version: 5.10-1
Severity: normal
Tags: patch

Dear Maintainer,

the manpages unlocked_stdio(3) and flockfile(3) indicate that
_POSIX_C_SOURCE should be defined with a value of 199309L in
order to obtain prototypes for:
 - flockfile
 - ftrylockfile
 - funlockfile
 - getc_unlocked
 - getchar_unlocked
 - putc_unlocked
 - putchar_unlocked

"_POSIX_C_SOURCE >= 199309L" should instead be "_POSIX_C_SOURCE >=
199506L".  This seems to be the case for glibc 2.24 (stretch) as well
as glibc 2.31 (bullseye).


--- manpages-5.10.orig/man3/flockfile.3
+++ manpages-5.10/man3/flockfile.3
@@ -42,7 +42,7 @@
 .PP
 All functions shown above:
 .RS 4
-/* Since glibc 2.24: */ _POSIX_C_SOURCE\ >=\ 199309L
+/* Since glibc 2.24: */ _POSIX_C_SOURCE\ >=\ 199506L
 || /* Glibc versions <= 2.23: */ _POSIX_C_SOURCE
 || /* Glibc versions <= 2.19: */ _BSD_SOURCE || _SVID_SOURCE
 .RE
--- manpages-5.10.orig/man3/unlocked_stdio.3
+++ manpages-5.10/man3/unlocked_stdio.3
@@ -73,7 +73,7 @@
 .BR putc_unlocked (),
 .BR putchar_unlocked ():
 .RS 4
-/* Since glibc 2.24: */ _POSIX_C_SOURCE\ >=\ 199309L
+/* Since glibc 2.24: */ _POSIX_C_SOURCE\ >=\ 199506L
 || /* Glibc versions <= 2.23: */ _POSIX_C_SOURCE
 || /* Glibc versions <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE
 .RE


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/50 CPU threads)
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 manpages-dev depends on:
ii  manpages  5.10-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.9.4-2

-- no debconf information

Bug#975272: osinfo-db: Indicate support for virtio in RHEL 8.0 and later

[Benjamin Moody]

Package: osinfo-db
Version: 0.20181120-1+deb10u1
Severity: normal

Dear Maintainer,

When creating a virtual machine using virt-manager, it prompts me to
select the operating system, and tries to select appropriate hardware,
based on what libosinfo knows about what devices are supported.

The consequence of this is that if I select "rhel-7.6" or
"rhel-7-unknown" as the OS, virt-manager will select virtio disk and
network devices.

However, if I select "rhel-8.0" or "rhel-8-unknown" or "rhel-unknown",
then virt-manager will select less efficient virtual devices (IDE disk
drive and e1000 network card.)

(It also won't include a virtual RNG device, which is arguably a bug
in virt-manager - I think adding a virtual RNG should be harmless for
OSes that don't support it, so it should be included unconditionally.)

It'd be possible to fix this and similar issues by constantly updating
the stable version of osinfo-db as new OSes are released.  However, it
would be wise to be more future-proof by default.  For OSes that are
*not yet released* (as RHEL 8.0 was not yet released at the time
osinfo-db was uploaded for Debian 10), in the absence of other
information, it seems best to assume they will support the same
hardware as the previous version.

(In particular, for RHEL, it seems unlikely that RHEL 9 will drop
support for the virtio devices that are provided by qemu in RHEL 8,
and so forth.)

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

Kernel: Linux 4.19.152-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#947833: Emergency shell unusable with root login disabled

[Benjamin Moody]

In bug #802211, Michael Biebl writes:
> Systemd now provides a mechanism to set the desired behaviour.
> It is now up to the installer or admin to set this up accordingly.

I think the mechanism he's referring to is to set an environment
variable SYSTEMD_SULOGIN_FORCE=1, which will cause systemd to
invoke sulogin with the --force option (i.e., if the root account
is locked or has no password, then log in without asking for a
password.)  See .

Personally I'm not sure this is the best idea - it'd be better to ask
for the username and password of somebody allowed to use sudo.  But if
that's too complicated/fragile to implement easily, then falling back
to root access on the console without a password is probably better
than making the system completely unusable (unless you can boot from
an alternate device or modify the bootloader arguments.)

So in the absence of a better solution, the installer probably ought
to enable SYSTEMD_SULOGIN_FORCE=1 if the administrator chooses not to
set a root password.

Bug#961681: Bug #961681: octave 5.2.0 and java child processes

[Benjamin Moody]

This should now be fixed upstream:
https://savannah.gnu.org/bugs/?func=detailitem_id=58641

Bug#961681: Bug #961681: octave 5.2.0 and java child processes

[Benjamin Moody]

> - Why does the stack overflow when the JVM is loaded from Octave, and
>   not when the JVM is launched "normally"?  (What is that worker
>   thread doing that would cause it to use any appreciable amount of
>   stack space?)
>
> - Why, on bullseye, is it unable to create the worker thread in the
>   first place?  (The error message suggests that pthread_create
>   doesn't like the specified attributes for some reason - why is
>   that?)  And again, why only in Octave?

It appears that the answers to both questions are the same: because
Octave uses a (relatively speaking) huge thread-local storage area,
and, at least when using glibc, this size must be included in the
"thread stack size" that is requested when calling pthread_create.

If I use gdb to break on pthread_create:

- when running octave 5.2.0 on bullseye: __static_tls_size = 156736

- when running octave 4.4.1 on buster: __static_tls_size = 95296

- when running a simple Java test program: __static_tls_size = 4160

which would seem to explain all of these issues.

(OpenJDK 8 seems to use a somewhat larger stack size by default than
OpenJDK 11 does - 233472 vs 139264 bytes.  I'm not sure why this is
different from the stackSize passed to the Thread constructor, but it
is.)

So should this be considered a bug in OpenJDK, or in Octave?

I don't think it's reasonable to expect Octave to limit its use of
thread-local storage in order to fit an arbitrary undocumented limit
that was picked out of thin air by the Java developers.  On the other
hand, it's not entirely unreasonable for Java to attempt to avoid
allocating a huge stack when it creates an internal worker thread that
doesn't need one.

(At the same time, I do think it is wrong for OpenJDK not to account
for the possibility of failure in this case.  If the reaper thread
crashes, that should cause waitFor to fail with an exception, but not
to hang.)

I don't know whether pthreads has any way to create a thread *without*
giving it a copy of the global static TLS area, and I don't know
whether that would work at all even if it were possible.  I also don't
know if there's any remotely portable way for a program to find out
the size of its own static TLS area.  So I have no idea how difficult
it would be to fix this bug at the OpenJDK level.

Certainly it seems that the simplest fix would be for Octave to set
the jdk.lang.processReaperUseDefaultStackSize property.

Bug#961681: Bug #961681: octave 5.2.0 and java child processes

[Benjamin Moody]

It seems that a possible workaround is to set the property
"jdk.lang.processReaperUseDefaultStackSize" to "true".  If that
property is "true", then the worker thread uses the "default" stack
size, whatever that is; if not, then the worker thread uses a stack
size of 128 * 1024.

https://sources.debian.org/src/openjdk-11/11.0.7+10-3/src/java.base/share/classes/java/lang/ProcessHandleImpl.java/#L81

This property can be defined either by setting the environment
variable JAVA_TOOL_OPTIONS, or by calling java.lang.System.setProperty
before starting any processes:

JAVA_TOOL_OPTIONS=-Djdk.lang.processReaperUseDefaultStackSize=true
octave -q -W -f --eval 'b = javaObject("java.lang.ProcessBuilder",
{"/bin/true"}); p = b.start(); p.waitFor()'

octave -q -W -f --eval 'javaMethod("setProperty", "java.lang.System",
"jdk.lang.processReaperUseDefaultStackSize", "true"); b =
javaObject("java.lang.ProcessBuilder", {"/bin/true"}); p = b.start();
p.waitFor()'

seems to work on buster or bullseye.

This doesn't answer the questions of:

- Why does the stack overflow when the JVM is loaded from Octave, and
  not when the JVM is launched "normally"?  (What is that worker
  thread doing that would cause it to use any appreciable amount of
  stack space?)

- Why, on bullseye, is it unable to create the worker thread in the
  first place?  (The error message suggests that pthread_create
  doesn't like the specified attributes for some reason - why is
  that?)  And again, why only in Octave?

  (I think the "OutOfMemoryError" is a red herring and that is simply
  the exception that Java always uses when pthread_create fails.)

Bug#961681: Bug #961681: octave 5.2.0 and java child processes

[Benjamin Moody]

Control: found 961681 5.2.0-2

On bullseye, with octave 5.2.0-2 and openjdk-11-jre-headless
11.0.7+9-1, "b.start()" fails:

$ octave -W -q -f
octave:1> b = javaObject("java.lang.ProcessBuilder", {"/bin/true"});
OpenJDK 64-Bit Server VM warning: Archived non-system classes are
disabled because the java.system.class.loader property is specified
(value = "org.octave.OctClassLoader"). To use archived non-system
classes, this property must be not be set
octave:2> p = b.start();
[14.392s][warning][os,thread] Failed to start thread - pthread_create
failed (EINVAL) for attributes: stacksize: 136k, guardsize: 0k,
detached.
error: [java] java.lang.OutOfMemoryError: unable to create native
thread: possibly out of memory or process/resource limits reached

(This appears to be the same issue as
.)

If I install the openjdk-8-jdk package from stretch, and force
octave 5.2.0-2 to use that instead, by running:

  # rm /usr/lib/jvm/default-java
  # ln -s java-8-openjdk-amd64/ /usr/lib/jvm/default-java
  # ln -s ../jre/lib/amd64/server/ /usr/lib/jvm/java-8-openjdk-amd64/lib/server

then there is no "Archived non-system classes" warning, and
"b.start()" suceeds, but "p.waitFor()" hangs as before.

Bug#961681: octave: StackOverflowError in Java process reaper

[Benjamin Moody]

Package: octave
Version: 4.4.1-5
Severity: normal

Dear Maintainer,

I don't know whether this is a bug in Octave or a bug in OpenJDK (or
both), but if an Octave program loads a Java library that creates a
subprocess, it results in an unhandled StackOverflowError, and trying
to get the exit status of the subprocess causes the entire program to
hang.

On Debian stretch (octave 4.0.3-3, openjdk-8-jre 8u252-b09-1~deb9u1):

$ octave -W -q -f
octave:1> b = javaObject('java.lang.ProcessBuilder', {'/bin/true'});
octave:2> p = b.start();
octave:3> p.waitFor()
ans = 0

On Debian buster (octave 4.4.1-5, openjdk-11-jre 11.0.7+10-3~deb10u1):

$ octave -W -q -f
octave:1> b = javaObject('java.lang.ProcessBuilder', {'/bin/true'});
OpenJDK 64-Bit Server VM warning: Archived non-system classes are disabled 
because the java.system.class.loader property is specified (value = 
"org.octave.OctClassLoader"). To use archived non-system classes, this property 
must be not be set
octave:2> p = b.start();

Exception: java.lang.StackOverflowError thrown from the 
UncaughtExceptionHandler in thread "process reaper"
octave:3> p.waitFor()

causes octave to hang.

(I have no idea what the "Archived non-system classes are disabled"
thing means, but it appears unrelated.)

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

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

Versions of packages octave depends on:
ii  libamd21:5.4.0+dfsg-1
ii  libarpack2 3.7.0-2
ii  libasound2 1.1.8-1
ii  libatlas3-base [liblapack.so.3]3.10.3-8
ii  libblas3 [libblas.so.3]3.8.0-2
ii  libbz2-1.0 1.0.6-9.2~deb10u1
ii  libc6  2.28-10
ii  libcamd2   1:5.4.0+dfsg-1
ii  libccolamd21:5.4.0+dfsg-1
ii  libcholmod31:5.4.0+dfsg-1
ii  libcolamd2 1:5.4.0+dfsg-1
ii  libcxsparse3   1:5.4.0+dfsg-1
ii  libfftw3-double3   3.3.8-2
ii  libfftw3-single3   3.3.8-2
ii  libfltk-gl1.3  1.3.4-9
ii  libfltk1.3 1.3.4-9
ii  libfreetype6   2.9.1-3+deb10u1
ii  libgcc11:8.3.0-6
ii  libgl1 1.1.0-1
ii  libglpk40  4.65-2
ii  libglu1-mesa [libglu1] 9.0.0-2.1+b3
ii  libgomp1   8.3.0-6
ii  libklu11:5.4.0+dfsg-1
ii  liblapack3 [liblapack.so.3]3.8.0-2
ii  liboctave6 4.4.1-5
ii  libopenblas-base [liblapack.so.3]  0.3.5+ds-3
ii  libportaudio2  19.6.0-1
ii  libqhull7  2015.2-4
ii  libqrupdate1   1.1.2-3
ii  libqscintilla2-qt5-13  2.10.4+dfsg-2.1
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u3
ii  libqt5help55.11.3-4
ii  libqt5network5 5.11.3+dfsg1-1+deb10u3
ii  libqt5opengl5  5.11.3+dfsg1-1+deb10u3
ii  libqt5printsupport55.11.3+dfsg1-1+deb10u3
ii  libqt5sql5 5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u3
ii  libsndfile11.0.28-6
ii  libstdc++6 8.3.0-6
ii  libsuitesparseconfig5  1:5.4.0+dfsg-1
ii  libumfpack51:5.4.0+dfsg-1
ii  libx11-6   2:1.6.7-1
ii  octave-common  4.4.1-5
ii  texinfo6.5.0.dfsg.1-4+b1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages octave recommends:
ii  default-jre-headless  2:1.11-71
ii  epstool   3.09-1
ii  gnuplot-qt [gnuplot-x11]  5.2.6+dfsg1-1+deb10u1
ii  libatlas3-base3.10.3-8
ii  libopenblas-base  0.3.5+ds-3
ii  octave-doc4.4.1-5
ii  pstoedit  3.73-1+b1

Versions of packages octave suggests:
ii  liboctave-dev  4.4.1-5

-- debconf-show failed

Bug#947989: libgtk-3-0: Mouse button presses ignored at edge of screen

[Benjamin Moody]

Package: libgtk-3-0
Version: 3.24.5-1
Severity: normal

Dear Maintainer,

If a GTK window is placed adjacent to the top or left edge of the
screen, it sometimes fails to handle mouse clicks.

For example, with the standard MATE panel configuration, the
"Applications" menu is in the top left corner.  Yet, if I move the
mouse to coordinates (0, 10) and try to click the button, then
sometimes, nothing happens.

On the other hand, 'xdotool mousemove 0 10 click 1' works as expected.

The problem seems to be that, if the mouse cursor is "pushed" against
the edge of the screen, the XInput 2 extension sometimes reports a
*negative* sub-pixel position, and even though the event is correctly
delivered to the X client, GTK doesn't recognize the negative position
as belonging to a widget.

A test program is below.  If I run that program, then click several
times while sliding the pointer along the left edge of the screen, I
see output like:

XI_ButtonPress at 0, 71.670608520507812
 -> 1 pressed at 0, 71.670608520507812
XI_ButtonPress at 0, 88.633712768554688
 -> 1 pressed at 0, 88.633712768554688
XI_ButtonPress at -0.9815216064453125, 111.44589233398438
XI_ButtonPress at 0, 130.43672180175781
 -> 1 pressed at 0, 130.43672180175781
XI_ButtonPress at -0.9422607421875, 135.76339721679688
XI_ButtonPress at -0.935089111328125, 149.22447204589844

indicating that Xlib receives the button-press events, but GTK doesn't
transmit them to the widget.

This problem appears to affect the top and left edges of the screen,
but not the right or bottom edges.

Not sure if this should be considered a bug in GTK, a bug in X, a bug
in libinput, or even a bug in MATE, but it's rather annoying.

This is using:
* xserver-xorg-core 2:1.20.4-1
* xserver-xorg-input-libinput 0.28.2-2
* libinput10 1.12.6-2

 Example program 
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 

int XNextEvent(Display *dpy, XEvent *ev)
{
  static int (*real_XNextEvent)(Display *dpy, XEvent *ev);
  static int xi2extension;
  int op, evt, err;
  XIDeviceEvent *devev;

  if (!real_XNextEvent) {
real_XNextEvent = dlsym(RTLD_NEXT, "XNextEvent");
if (XQueryExtension(dpy, "XInputExtension", , , ))
  xi2extension = op;
  }

  (*real_XNextEvent)(dpy, ev);

  if (ev) {
if (ev->type == ButtonPress) {
  printf("ButtonPress at %d, %d\n", ev->xbutton.x, ev->xbutton.y);
}
if (ev->type == GenericEvent
&& ev->xgeneric.extension == xi2extension
&& ev->xgeneric.evtype == XI_ButtonPress) {
  if (XGetEventData(dpy, >xcookie)) {
devev = ev->xcookie.data;
printf("XI_ButtonPress at %.17g, %.17g\n",
   devev->event_x, devev->event_y);
  }
  /* welp, guess if gdk doesn't call XFreeEventData then we leak. */
}
  }

  return 0;
}

static gboolean button_press(GtkWidget *w, GdkEventButton *ev)
{
  printf(" -> %d pressed at %.17g, %.17g\n", ev->button, ev->x, ev->y);
  return FALSE;
}

int main(int argc, char **argv)
{
  void *window, *da;
  gtk_init(, );
  window = gtk_window_new(GTK_WINDOW_POPUP);
  da = gtk_drawing_area_new();
  gtk_widget_add_events(da, GDK_BUTTON_PRESS_MASK);
  g_signal_connect(da, "button-press-event", G_CALLBACK(button_press), NULL);
  gtk_container_add(window, da);
  gtk_widget_show_all(window);
  gtk_window_parse_geometry(window, "300x300+0+0");
  gtk_main();
  return 0;
}


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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.30.1-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcolord2   1.4.3-4
ii  libcups2 2.2.10-6+deb10u1
ii  libepoxy01.5.3-0.1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-common  3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  librest-0.7-00.8.1-1
ii  libsoup2.4-1 2.64.2-2
ii  libwayland-client0   1.16.0-1
ii  libwayland-cursor0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   

Bug#946555: lsof: Incomplete/misleading output regarding non-POSIX file locks

[Benjamin Moody]

Package: lsof
Version: 4.91+dfsg-1
Severity: normal

Dear Maintainer,

The output of lsof is misleading when it comes to "flock" and "OFD"
file locks on Linux.

Background: there are three types of advisory file locks in Linux:

- "flock" or "BSD" locks, which are created by the flock system call.
  These are associated with a particular *open file description*, so
  they are inherited by child processes.

- "fcntl" or "POSIX" locks, which are created by the fcntl system call
  with the F_SETLK or F_SETLKW option.  These are associated with a
  particular *process ID*, so they are not inherited by child
  processes.

- "OFD" locks, which are created by the fcntl system call with the
  F_OFD_SETLK or F_OFD_SETLKW option.  These are like flock locks in
  that they are associated with an open file description, but they are
  like fcntl locks in that they apply to a particular range of bytes.

The kernel reports all of these locks via /proc/locks, and lsof parses
that file and tries to indicate which processes are currently holding
locks on which files.

However, the information in /proc/locks is incomplete and in some
cases inaccurate: for flock and OFD locks, it tells you that *some
process* is holding a lock on the file, but it doesn't tell you which
one(s), since the lock may have been inherited across a fork.  The
proc(5) manpage states:

Because OFD locks are not owned by a single process (since
multiple processes may have file descriptors that refer to the
same open file description), the value -1 is displayed in [the
process ID field] for OFD locks.  (Before kernel 4.14, a bug meant
that the PID of the process that initially acquired the lock was
displayed instead of the value -1.)

The manpage doesn't mention that exactly the same "bug" also applies
to flock locks.

As far as I can see, this does appear to be a limitation of the
kernel: I don't know of any way that lsof could possibly figure out
which processes, or which file descriptors, are associated with a
particular lock.

So although I believe this is a bug in lsof, I don't think it is one
that lsof can fix by itself.

Nonetheless, it's a limitation that probably should be better
documented, and perhaps lsof's output could be improved to reflect
this uncertainty - for example, it could display a '?' in the lock
column to indicate "*some* process has a lock on this file; this
particular process might or might not."


Here is an example program:

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
int fd1, fd2, fd3, fd4, status;
pid_t child;
struct flock fl = { 0 };
char cmd[100];

fd1 = open("/tmp/file1", O_RDWR | O_CREAT, 0600);
fd2 = open("/tmp/file1", O_RDWR | O_CREAT, 0600);
fd3 = open("/tmp/file2", O_RDWR | O_CREAT, 0600);
fd4 = open("/tmp/file2", O_RDWR | O_CREAT, 0600);
if (fd1 < 0 || fd2 < 0 || fd3 < 0 || fd4 < 0)
err(1, "open");

if (flock(fd1, LOCK_SH))
err(1, "flock");

fl.l_type = F_WRLCK;
if (fcntl(fd3, F_OFD_SETLKW, ))
err(1, "fcntl");

child = fork();
if (child < 0)
err(1, "fork");
else if (child == 0) {
snprintf(cmd, sizeof(cmd), "lsof -p %d,%d -a -d 3-99",
 getppid(), getpid());
system(cmd);
}
else {
wait();
}
return 0;
}

Running this program produces:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
a.out   5615 benjamin3uR  REG   0,440 517883 /tmp/file1
a.out   5615 benjamin4uR  REG   0,440 517883 /tmp/file1
a.out   5615 benjamin5u   REG   0,440 517884 /tmp/file2
a.out   5615 benjamin6u   REG   0,440 517884 /tmp/file2
a.out   5616 benjamin3u   REG   0,440 517883 /tmp/file1
a.out   5616 benjamin4u   REG   0,440 517883 /tmp/file1
a.out   5616 benjamin5u   REG   0,440 517884 /tmp/file2
a.out   5616 benjamin6u   REG   0,440 517884 /tmp/file2

The flock lock is indicated (with an "R") for the parent process, but
not for the child process; the OFD lock is not indicated at all.  (If
you run the same program on an older kernel, it will show a "W" in the
fourth and fifth lines.)

To be *really* precise, file descriptors 3 and 5 are the ones holding
the locks; those FDs should have an "R" or "W" next to them while 4
and 6 shouldn't.


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

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

Versions of packages lsof depends on:
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

lsof recommends no packages.

Bug#925307: vagrant-lxc: Network broken with lxc's default configuration

[Benjamin Moody]

Package: vagrant-lxc
Version: 1.2.1-3
Severity: normal

Dear Maintainer,

With the default configuration of the lxc package, vagrant-lxc does
not work, apparently because the container does not have a network
interface by default.  It simply gives an error message such as:

There was an error executing ["sudo", "/usr/bin/env", "lxc-attach", 
"--name", "vagrant_default_1553281852428_28054", "--namespaces", 
"NETWORK|MOUNT", "--", "/sbin/ip", "-4", "addr", "show", "scope", "global", 
"eth0"]


I was able to work around this by following the instructions at
:

 - create /etc/default/lxc-net containing

USE_LXC_BRIDGE="true"

 - create /etc/lxc/default.conf containing

lxc.network.type = veth
lxc.network.link = lxcbr0
lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:xx:xx:xx

 - run 'service lxc-net restart'

However, it took a bit of tinkering to figure out that this was
necessary (probably because I'm not very familiar with lxc.)
Preferably, the vagrant-lxc package should do whatever is needed to
configure virtual networking for its own containers, independent of
lxc's configuration; or at least, it should document the required
configuration steps in README.Debian.


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

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

Versions of packages vagrant-lxc depends on:
ii  lxc  1:2.0.7-2+deb9u2
ii  redir3.1-1~exp1
ii  ruby 1:2.3.3
ii  sudo 1.8.19p1-2.1
ii  vagrant  1.9.1+dfsg-1+deb9u2

vagrant-lxc recommends no packages.

vagrant-lxc suggests no packages.

-- no debconf information

Bug#924052: debhelper: dh_auto_test should prefer 'make check' over 'make test'

[Benjamin Moody]

Package: debhelper
Version: 10.2.5
Severity: wishlist

Dear Maintainer,

If a package is built using make, dh_auto_test should prefer to run
'make check' (which is the GNU standard [1]) rather than 'make test'.

This is doubly true for packages that use automake [2], but I think it
would make sense for all packages using makefiles.

The reason I see for preferring 'make check' is that it's common to
have a test program named 'test.c', 'test.sh', etc., and thus 'make
test' is an instruction to compile the test program rather than to run
it.  I suspect that this (combined with the fact that old versions of
make didn't support the notion of phony targets) is the reason for
GNU's choice of 'make check'.

That is to say, I suspect 'check' was chosen deliberately because it
was (and is) a less common term, and thus less ambiguous.

Note, I'm not proposing that dh_auto_test should ignore the 'test'
target; rather, in cases where *both* 'test' and 'check' are defined
(possibly by implicit rules), 'check' is the one that should be used
by default.

A third possibility would be to run 'make test check', on the
assumption that it's unlikely to be harmful to run both targets.
('make test check' would be better than 'make test && make check',
since the makefile might define the two as aliases of each other.)

There is of course no way to have a single rule that works for every
package.  However, my suspicion is:

- Packages for which 'make check' runs the test suite, and 'make test'
  incidentally does something different, are more common than packages
  for which 'make test' runs the test suite, and 'make check'
  incidentally does something different.

- The least surprising behavior would be to follow the behavior of
  automake and the GNU standards.

The second point is a matter of opinion, but the first is in principle
a testable hypothesis...


[1] GNU Coding Standards: Standard Targets for Users
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html

[2] Automake manual: Support for test suites
https://www.gnu.org/software/automake/manual/html_node/Tests.html


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

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

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.28-5
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg 1.18.25
ii  dpkg-dev 1.18.25
ii  file 1:5.30-1+deb9u2
ii  libdpkg-perl 1.18.25
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-3+deb9u5
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#907121: Fixed upstream

[Benjamin Moody]

Control: tags 907121 + patch

This issue appears to have been fixed upstream:
https://github.com/aptly-dev/aptly/commit/86dc10028f4f2a045797c9d3b072c7a034c257f7

Here's a slightly modified version of the above patch, which will fix
the issue for version 1.3.0:

--- aptly-1.3.0+ds1.orig/deb/format.go
+++ aptly-1.3.0+ds1/deb/format.go
@@ -4,6 +4,7 @@ import (
"bufio"
"errors"
"io"
+   "sort"
"strings"
"unicode"
 )
@@ -166,8 +167,16 @@ func (s Stanza) WriteTo(w *bufio.Writer,
}
}

-   for field, value := range s {
-   err := writeField(w, field, value, isRelease)
+   // Print extra fields in deterministic order (alphabetical)
+   keys := make([]string, len(s))
+   i := 0
+   for field := range s {
+   keys[i] = field
+   i++
+   }
+   sort.Strings(keys)
+   for _, field := range keys {
+   err := writeField(w, field, s[field], isRelease)
if err != nil {
return err
}

Bug#898772: qemu: Keys still get stuck when window loses focus

[Benjamin Moody]

Control: found 898772 1:3.1+dfsg-4

This bug does affect qemu 1:3.1+dfsg-4, except that the list of
known modifier keys is expanded to include "META_L" and "META_R".
The issue is thus somewhat less severe but still present.

An easy way to see the problem is that if a qemu window is
focused, and the user holds down the "G" key while pressing
Super+Tab, the guest OS will continue to believe that "G" is
pressed even after the window loses focus.

Here is a patch to fix this issue for qemu 3.1:

--- qemu-3.1+dfsg.orig/ui/gtk.c
+++ qemu-3.1+dfsg/ui/gtk.c
@@ -122,17 +122,6 @@

 #define HOTKEY_MODIFIERS(GDK_CONTROL_MASK | GDK_MOD1_MASK)

-static const int modifier_keycode[] = {
-Q_KEY_CODE_SHIFT,
-Q_KEY_CODE_SHIFT_R,
-Q_KEY_CODE_CTRL,
-Q_KEY_CODE_CTRL_R,
-Q_KEY_CODE_ALT,
-Q_KEY_CODE_ALT_R,
-Q_KEY_CODE_META_L,
-Q_KEY_CODE_META_R,
-};
-
 static const guint16 *keycode_map;
 static size_t keycode_maplen;

@@ -187,7 +176,7 @@

 bool external_pause_update;

-bool modifier_pressed[ARRAY_SIZE(modifier_keycode)];
+bool modifier_pressed[Q_KEY_CODE__MAX];
 bool ignore_keys;

 DisplayOptions *opts;
@@ -432,8 +421,8 @@
 !qemu_console_is_graphic(vc->gfx.dcl.con)) {
 return;
 }
-for (i = 0; i < ARRAY_SIZE(modifier_keycode); i++) {
-qcode = modifier_keycode[i];
+for (i = 0; i < ARRAY_SIZE(s->modifier_pressed); i++) {
+qcode = i;
 if (!s->modifier_pressed[i]) {
 continue;
 }
@@ -1144,10 +1133,8 @@
 trace_gd_key_event(vc->label, key->hardware_keycode, qcode,
(key->type == GDK_KEY_PRESS) ? "down" : "up");

-for (i = 0; i < ARRAY_SIZE(modifier_keycode); i++) {
-if (qcode == modifier_keycode[i]) {
-s->modifier_pressed[i] = (key->type == GDK_KEY_PRESS);
-}
+if (qcode >= 0 && qcode < ARRAY_SIZE(s->modifier_pressed)) {
+s->modifier_pressed[qcode] = (key->type == GDK_KEY_PRESS);
 }

 qemu_input_event_send_key_qcode(vc->gfx.dcl.con, qcode,

Bug#919629: firefox-esr: crash on loading meet.google.com video conference

[Benjamin Moody]

Package: firefox-esr
Version: 60.3.0esr-1~deb9u1
Severity: normal

Dear Maintainer,

Firefox crashes when trying to join a Google video conference.

Upon loading the URL (https://meet.google.com/xxx--xxx), the page
is briefly displayed, and a dialog pops up asking for permission to
access the microphone.  After perhaps half a second, it gives
"Gah. Your tab just crashed."

As best I can figure from the Firefox crash report, it crashes at
0x33e12c0 in libxul.so
 = media/webrtc/trunk/webrtc/base/task_queue_libevent.cc:320

The crash report is at
https://crash-stats.mozilla.com/report/index/e4db2583-c89f-4f0b-95fc-e5ac30190117

(okay, apparently it automatically uploads all of this to mozilla,
that's a little disturbing...)

I can try to dig deeper, but any tips on how to diagnose the problem
would be welcome.  Note I am not the meeting organizer, and you
apparently need to be a "G Suite Administrator" to organize meetings.

Bug#915055: binutils-mingw-w64: Nondeterminism in DLL import libraries

[Benjamin Moody]

Package: binutils-mingw-w64
Version: 2.27.90.20161231-1+7.4
Severity: normal
Tags: patch

Dear Maintainer,

When building a Windows DLL and accompanying import library using
'i686-w64-mingw32-ld' or 'x86_64-w64-mingw32-ld', the import library
includes build timestamps as well as UID/GID, which makes it difficult
to build a reproducible package.

A simple test:

  export SOURCE_DATE_EPOCH=0
  echo 'int foo(){return 42;}' > foo.c
  i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--out-implib=foo1.dll.a
  mv foo.dll foo1.dll
  sleep 1
  i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--out-implib=foo2.dll.a
  mv foo.dll foo2.dll
  diff foo1.dll foo2.dll  # succeeds
  diff foo1.dll.a foo2.dll.a  # fails

>From what I can tell, it should be easy to fix this by setting the
BFD_DETERMINISTIC_OUTPUT flag when creating the import library:

--- a/ld/pe-dll.c
+++ b/ld/pe-dll.c
@@ -2736,6 +2736,7 @@
 
   bfd_set_format (outarch, bfd_archive);
   outarch->has_armap = 1;
+  outarch->flags |= BFD_DETERMINISTIC_OUTPUT;
 
   /* Work out a reasonable size of things to put onto one line.  */
   ar_head = make_head (outarch);


(I've tested this patch on stretch, using binutils-source 2.28-5,
binutils-mingw-w64 7.4, gcc-mingw-w64 6.3.0-14+19.3.)

I can't think of any reason that this should cause compatibility
issues, since (unlike "normal" ar archives) the import library that is
generated in this way doesn't correspond to any "real" object files.
Thus, I can't think of any reason not to enable deterministic mode
unconditionally in this case.

I do, however, note the comment in bsd_write_armap (bfd/archive.c):

  "Some linkers may require that the archive filesystem modification
  time is less than (or near to) the archive map timestamp.  Those
  linkers should not be used with deterministic mode.  (GNU ld and
  Gold do not have this restriction.)"

I don't know if this comment has any relevance to MinGW or any other
Windows compilers.  (It seems unlikely, since timestamps in Windows
filesystems have historically been such a mess to begin with.)


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

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

Versions of packages binutils-mingw-w64 depends on:
ii  binutils-mingw-w64-i6862.28-5+7.4+b4
ii  binutils-mingw-w64-x86-64  2.28-5+7.4+b4

binutils-mingw-w64 recommends no packages.

binutils-mingw-w64 suggests no packages.

-- debconf-show failed

Bug#907726: virtualenv: automatically downloads untrusted code

[Benjamin Moody]

Package: virtualenv
Version: 15.1.0+ds-1
Severity: normal

Dear Maintainer,

The man page for virtualenv does not mention the --no-download option,
and does not indicate that the program's default behavior - i.e., upon
invoking 'virtualenv foo' - is to automatically download and install
code from the Internet.  (Whether or not virtualenv per se actually
executes any of that code, I'm not sure.)

This default behavior is a bad idea, to begin with...

 - there's no guarantee that the code downloaded is free software

 - there's no guarantee that the code downloaded won't change its
   behavior from one day to the next

 - there isn't even any authentication of the code's authorship,
   beyond verifying the TLS certificate of 'pypi.python.org'

...which of course are also problems with many typical uses of pip,
but in that case the user is at least arguably making a deliberate
choice.

This is a major change in behavior, compared to the behavior of
virtualenv in jessie; and it's one that violates (at least) my
expectations as a Debian user.

That said, I'm sure some people would say that this is exactly what
virtualenv is "supposed" to do.

At a minimum, this behavior should be documented, along with the
option needed to obtain the old sane behavior.


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

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

Versions of packages virtualenv depends on:
ii  python3 3.5.3-1
ii  python3-virtualenv  15.1.0+ds-1

virtualenv recommends no packages.

virtualenv suggests no packages.

-- debconf-show failed

Bug#907121: aptly: Order of fields in Packages/Sources is unpredictable

[Benjamin Moody]

Package: aptly
Version: 1.3.0-5~bpo9+1
Severity: wishlist

Dear Maintainer,

When using aptly to publish a package repository, some of the metadata
fields in the Packages and/or Sources files are written in an
unpredictable (and probably non-deterministic) order.  This is mildly
annoying because it makes it difficult to compare two versions of the
file (e.g., with diff).

Example:

  $ apt-get source hello
  $ aptly repo create foo
  $ aptly repo add foo hello_2.10-1.dsc
  $ aptly publish repo -distribution foo -skip-signing foo debian
  $ grep '^[A-Z]' .aptly/public/debian/dists/foo/main/source/Sources
Package: hello
Binary: hello
Version: 2.10-1
Maintainer: Santiago Vila 
Build-Depends: debhelper (>= 9.20120311)
Architecture: any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Directory: pool/main/h/hello
Files:
Package-List:
Homepage: http://www.gnu.org/software/hello/
Checksums-Sha1:
Checksums-Sha256:
Checksums-Sha512:
  $ aptly publish drop foo debian
  $ aptly publish repo -distribution foo -skip-signing foo debian
  $ grep '^[A-Z]' .aptly/public/debian/dists/foo/main/source/Sources
Package: hello
Binary: hello
Version: 2.10-1
Maintainer: Santiago Vila 
Build-Depends: debhelper (>= 9.20120311)
Architecture: any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Directory: pool/main/h/hello
Files:
Homepage: http://www.gnu.org/software/hello/
Checksums-Sha256:
Checksums-Sha512:
Checksums-Sha1:
Package-List:

Notice that the order of the last five fields has changed, even though
the repository has not been modified in any way.

The same problem occurs with Packages files, but less often
(typically, only the 'Homepage' and 'Multi-Arch' fields are randomly
swapped.)

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

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

Versions of packages aptly depends on:
ii  bzip2 1.0.6-8.1
ii  gnupg11.4.21-4+deb9u1
ii  gpgv1 1.4.21-4+deb9u1
ii  libc6 2.24-11+deb9u3
ii  xz-utils  5.2.2-1.2+b1

aptly recommends no packages.

Versions of packages aptly suggests:
ii  graphviz  2.38.0-17

-- debconf-show failed

Bug#898772: qemu: Keys get "stuck" when window loses focus

[Benjamin Moody]

Source: qemu
Version: 1:2.8+dfsg-6+deb9u3
Severity: normal
Tags: patch

Dear Maintainer,

when running qemu in the default graphical mode, it does not correctly
handle what happens when the window loses keyboard focus.

For example:

 * The window manager is configured to switch focus when Super+Tab is
   pressed.

 * A qemu window is focused.

 * I press Super; a KeyPress event is sent to qemu, and the
   corresponding keycode is sent to the guest OS.

 * I press Tab, which is grabbed by the window manager; the WM
   switches focus to another window.

 * I release both keys; the KeyRelease events are now delivered to
   that other window, and not to qemu.

 * The guest OS still believes the Super key is pressed, and will
   continue to believe so until I re-focus the qemu window, and press
   and release Super while the window is focused.

The result can be quite frustrating because qemu doesn't give any
visual indication of what keys it believes are currently pressed, and
in most cases neither does the guest OS.  Fixing the problem requires
the user to realize what has happened (which isn't obvious) and then
to press keys one at a time until they become un-wedged.


It appears that qemu will actually keep track of which "modifier" keys
are pressed, and automatically release *those* particular keys when
the window loses focus.  However:

 - It is limited to left and right Shift, Control, and Alt.

 - It is based on qemu's idea of what physical keycodes correspond to
   modifiers, which may have nothing to do with what keys are actually
   mapped as X modifiers.

 - There's no particular reason that the underlying problem is limited
   to modifiers in the first place (there are plenty of other ways
   that the window can lose focus while one or more keys are pressed.)


Below is a patch to fix this behavior for the SDL interface used in
stretch.

It looks like the latest version of the package, in unstable, has
removed the SDL interface in favor of GTK+.  I haven't tested it, but
from a quick skim of the source, it appears that the GTK+ interface
will have the same problem (see gd_key_event() and
gtk_release_modifiers() in ui/gtk.c.)


--- qemu-2.8+dfsg.orig/ui/sdl.c
+++ qemu-2.8+dfsg/ui/sdl.c
@@ -328,17 +328,6 @@ static void sdl_process_key(SDL_Keyboard
 /* sent when leaving window: reset the modifiers state */
 reset_keys();
 return;
-case 0x2a:  /* Left Shift */
-case 0x36:  /* Right Shift */
-case 0x1d:  /* Left CTRL */
-case 0x9d:  /* Right CTRL */
-case 0x38:  /* Left ALT */
-case 0xb8: /* Right ALT */
-if (ev->type == SDL_KEYUP)
-modifiers_state[keycode] = 0;
-else
-modifiers_state[keycode] = 1;
-break;
 #define QEMU_SDL_VERSION ((SDL_MAJOR_VERSION << 8) + SDL_MINOR_VERSION)
 #if QEMU_SDL_VERSION < 0x102 || QEMU_SDL_VERSION == 0x102 && SDL_PATCHLEVEL < 
14
 /* SDL versions before 1.2.14 don't support key up for caps/num lock. 
*/
@@ -351,6 +340,12 @@ static void sdl_process_key(SDL_Keyboard
 #endif
 }
 
+assert(keycode >= 0 && keycode < ARRAY_SIZE(modifiers_state));
+if (ev->type == SDL_KEYUP)
+modifiers_state[keycode] = 0;
+else
+modifiers_state[keycode] = 1;
+
 /* now send the key code */
 qemu_input_event_send_key_number(dcl->con, keycode,
  ev->type == SDL_KEYDOWN);

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

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

Bug#859103: strip-nondeterminism: does not replace all timestamps in zip archives

[Benjamin Moody]

Package: strip-nondeterminism
Version: 0.034-1
Followup-For: Bug #859103

This is especially annoying because the "local extra field" includes
the file *access* time:

   $ rm -f foo 1.zip 2.zip
   $ touch -d 2015-01-01 foo
   $ zip 1.zip foo
   $ zip 2.zip foo
   $ strip-nondeterminism 1.zip 2.zip
   $ diffoscope 1.zip 2.zip
...
 0010:      0300 1c00 666f  ..fo
-0020: 6f55 5409 0003 50d4 a454 50d4 a454 7578  oUT...P..TP..Tux
+0020: 6f55 5409 0003 50d4 a454 62a1 ba5a 7578  oUT...P..Tb..Zux
 0030: 0b00 0104 e803  04e8 0300 0050 4b01  .PK.
...

(Which makes me think, for testing build reproducibility, it'd be
wise to try one build using noatime and another using
strictatime.  But anyway...)


The problem here is that Archive::Zip::ZipFileMember is not
designed to allow modifying the localExtraField() at all.  From
the man page:

   localExtraField( [ $newField ] )
   localExtraField( [ { field => $newField } ] )
   Gets or sets the extra field that was read from the local header.
   This is not set for a member from a zip file until after the member
   has been written out. The extra field must be in the proper format.

That is to say, before calling $zip->overwrite(),
localExtraField() returns an empty string.  Moreover, for
ZipFileMembers, manually setting the field has no effect - even
if you call overwrite(), then go back and modify the
localExtraFields, then call overwrite() again, it will re-read
the fields from the zip file.

(As far as I can tell, the *only* way to manually specify a
localExtraField using Archive::Zip is to decompress and
recompress each member.)


Here is a rather kludgy patch to make Archive::Zip behave the way
that strip-nondeterminism seems to expect:

--- /usr/share/perl5/Archive/Zip/ZipFileMember.pm
+++ Archive/Zip/ZipFileMember.pm
@@ -43,6 +43,25 @@
   and $self->uncompressedSize == 0);
 }
 
+sub localExtraField {
+my $self = shift;
+
+# If this function is called with an argument, it overrides the
+# original field contents from the source archive.
+if (@_) {
+$self->{'_localExtraFieldUserDefined'} = 1;
+}
+# Otherwise, the value is loaded lazily, the first time it is needed.
+elsif (!defined $self->{'_localExtraFieldUserDefined'}
+   and defined $self->{'externalFileName'}) {
+my $origpos = $self->fh()->tell();
+$self->rewindData();
+$self->fh()->seek($origpos, IO::Seekable::SEEK_SET);
+}
+
+return $self->SUPER::localExtraField(@_);
+}
+
 # Seek to the beginning of the local header, just past the signature.
 # Verify that the local header signature is in fact correct.
 # Update the localHeaderRelativeOffset if necessary by adding the 
possibleEocdOffset.
@@ -156,10 +175,17 @@
 }
 
 if ($extraFieldLength) {
-$bytesRead =
-  $self->fh()->read($self->{'localExtraField'}, $extraFieldLength);
-if ($bytesRead != $extraFieldLength) {
-return _ioError("reading local extra field");
+if ($self->{'_localExtraFieldUserDefined'}) {
+$self->fh()->seek($extraFieldLength, IO::Seekable::SEEK_CUR)
+  or return _ioError("skipping local extra field");
+}
+else {
+$bytesRead =
+  $self->fh()->read($self->{'localExtraField'}, $extraFieldLength);
+if ($bytesRead != $extraFieldLength) {
+return _ioError("reading local extra field");
+}
+$self->{'_localExtraFieldUserDefined'} = 0;
 }
 }
 

Here is a different kludgy approach to work around the issue in
strip-nondeterminism, rewriting the local file headers by hand:

--- /usr/share/perl5/File/StripNondeterminism/handlers/zip.pm
+++ File/StripNondeterminism/handlers/zip.pm
@@ -23,6 +23,7 @@
 
 use File::Temp;
 use Archive::Zip qw/:CONSTANTS :ERROR_CODES/;
+use Fcntl q/SEEK_SET/;
 
 # A magic number from Archive::Zip for the earliest timestamp that
 # can be represented by a Zip file.  From the Archive::Zip source:
@@ -207,11 +208,36 @@
}
$member->cdExtraField(
normalize_extra_fields($member->cdExtraField(), 
CENTRAL_HEADER));
-   $member->localExtraField(
-   normalize_extra_fields($member->localExtraField(), 
LOCAL_HEADER));
}
my $old_perms = (stat($zip_filename))[2] & oct();
$zip->overwrite();
+
+   # Archive::Zip::ZipFileMembers do not allow modifying the
+   # local extra field, so we need to rewrite the local file
+   # headers by hand.  This assumes that normalize_extra_fields
+   # does not change the length of the field(s).
+
+   open(my $fh, '+<', $zip_filename) or die "Unable to open $zip_filename: 
$!";
+   for my $member ($zip->members()) {
+   my $extra_field = 
normalize_extra_fields($member->localExtraField(), LOCAL_HEADER);
+

Bug#888184: tasksel: freezes if there is a conffile prompt

[Benjamin Moody]

Package: tasksel
Version: 3.39
Severity: normal

Dear Maintainer,

It seems that when installing packages using tasksel, if dpkg needs to
ask the user what to do about a configuration file, the tasksel
process freezes with no explanation.

Example:

  debootstrap stretch /var/chroot/stretch-test http://deb.debian.org/debian/
  chroot /var/chroot/stretch-test
touch /etc/magic
tasksel install standard

=> gets to the point of "Configuring libmagic1 (amd64)", and freezes.

Furthermore, tasksel can't be interrupted at that point by ^C, ^Z, or ^\.
It doesn't seem to respond to any terminal input at all.

Bug#887387: linux-image-3.16.0-5-amd64: i915 GPU HANG; no 3D/video acceleration (regression)

[Benjamin Moody]

Package: src:linux
Version: 3.16.51-3+deb8u1
Severity: normal

Dear Maintainer,

Since upgrading 3.16.43-2+deb8u5 to 3.16.51-3+deb8u1, i915 graphics
acceleration is sometimes unavailable.

It seems to be broken about 50% of the time on a cold boot.  I have
not seen the problem occur after a reboot.

The X driver (xserver-xorg-video-intel) states "cannot enable DRI2
whilst forcing software fallbacks", but doesn't give any indication of
why software fallback mode is forced.  glxinfo reports that llvmpipe
is in use.  xvinfo reports the same capabilities as normal, but they
don't work (e.g., mpv --vo=xv shows a black screen.)

The following messages appear in dmesg:

[drm] GPU HANG: ecode -1:0x, reason: Command parser error, iir 
0x8000, action: continue
[drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, 
including userspace.
[drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> 
DRM/Intel
[drm] drm/i915 developers can then reassign to the right component if it's 
not a kernel issue.
[drm] The gpu crash dump is required to analyze gpu hangs, so please always 
attach it.
[drm] GPU crash dump saved to /sys/class/drm/card0/error
i915: render error detected, EIR: 0x0010
i915:   IPEIR: 0x
i915:   IPEHR: 0x
i915:   INSTDONE_0: 0xfffe
i915:   INSTDONE_1: 0x
i915:   INSTDONE_2: 0x
i915:   INSTDONE_3: 0x
i915:   INSTPS: 0x
i915:   ACTHD: 0x
i915: page table error
i915:   PGTBL_ER: 0x0003
[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking
...
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 
0001f001 (valid? 1) head 18000208 tail  start 003eb000 [expected 
003eb000]
[drm:i915_gem_init] *ERROR* Failed to initialize GPU, declaring it wedged
[drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

The system is a Thinkpad X200 with libreboot.


-- Package-specific info:
** Version:
Linux version 3.16.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)

** Command line:
BOOT_IMAGE=/vmlinuz root=UUID=d4a95191-90d7-4f4a-9504-b1254cb12617 ro quiet 
panic=5

** Tainted: CIO (7168)
 * Module from drivers/staging has been loaded.
 * Working around severe firmware bug.
 * Out-of-tree module has been loaded.

** Kernel log:
[   11.276033] [drm:init_ring_common] *ERROR* render ring initialization failed 
ctl 0001f001 (valid? 1) head 18000208 tail  start 003eb000 [expected 
003eb000]
[   11.276045] [drm:i915_gem_init] *ERROR* Failed to initialize GPU, declaring 
it wedged
[   11.361171] psmouse serio1: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 
00 64
[   11.454553] fbcon: inteldrmfb (fb0) is primary device
[   11.632038] usb 1-6: new high-speed USB device number 4 using ehci-pci
[   11.668130] Console: switching to colour frame buffer device 160x50
[   11.670763] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   11.670766] i915 :00:02.0: registered panic notifier
[   11.684059] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[   11.716149] EXT4-fs (sda1): mounting ext3 file system using the ext4 
subsystem
[   11.734179] psmouse serio1: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[   11.738188] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[   11.752698] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/input/input7
[   11.769497] usb 1-6: New USB device found, idVendor=17ef, idProduct=480c
[   11.769501] usb 1-6: New USB device strings: Mfr=1, Product=0, SerialNumber=0
[   11.769504] usb 1-6: Manufacturer: Chicony Electronics Co., Ltd.
[   12.012035] usb 4-1: new full-speed USB device number 2 using uhci_hcd
[   12.184247] usb 4-1: New USB device found, idVendor=08ff, idProduct=2810
[   12.184252] usb 4-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   12.184254] usb 4-1: Product: Fingerprint Sensor
[   12.342396] cfg80211: World regulatory domain updated:
[   12.342401] cfg80211:  DFS Master region: unset
[   12.342403] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   12.342406] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   12.342408] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz, 92000 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[   12.342410] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[   12.342412] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[   12.342415] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[   12.342417] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[   12.342419] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), 

Bug#884183: linux-image-3.16.0-4-amd64: Kernel panic at boot

[Benjamin Moody]

On 12/13/17, Benjamin Moody <benjamin.mo...@gmail.com> wrote:
> Same problem here.  3.16.43-2+deb8u5 works, 3.16.51-2 is broken.
>
> Supermicro H8QM3
>
> Quad-Core AMD Opteron(tm) Processor 8347 HE (fam: 10, model: 02,
> stepping: 03)
>
> Two 3ware 9650SE RAID cards

Sorry I didn't think to look for the duplicate bug reports yesterday.

I can confirm that:

- Version 3.16.51-2 is able to boot if 'numa=off' is specified.

- Version 3.16.51-3~a.test (see
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884069#66) fixes
  the issue.

Bug#884183: linux-image-3.16.0-4-amd64: Kernel panic at boot

[Benjamin Moody]

Package: src:linux
Followup-For: Bug #884183

Same problem here.  3.16.43-2+deb8u5 works, 3.16.51-2 is broken.

Supermicro H8QM3

Quad-Core AMD Opteron(tm) Processor 8347 HE (fam: 10, model: 02,
stepping: 03)

Two 3ware 9650SE RAID cards

I can get the system to boot by doing the following:

  * installing linux-image-3.16.0-4-amd64_3.16.43-2+deb8u5_amd64.deb
 (but booting the kernel and initrd from the 3.16.51-2 package)

  * adding the option 'nosmp'

  * adding the option 'blacklist=3w-9xxx'

If I don't set 'nosmp', the kernel panics immediately.  I don't
currently have a way to get a serial console on this machine, so I
don't have a complete log, but what I can see
(https://nofile.io/f/Nfc2FPR83st/IMG_20171213_144202.jpg) appears to
match the logs reported by Gerald Schroll.

If I set 'nosmp' but not 'blacklist=3w-9xxx', it goes into a seemingly
infinite loop (it appears to be trying to initialize one or both RAID
cards, but eventually times out and then tries again.)

If I set both of those options, the system boots up (slowly), and
eventually launches an emergency shell.  After five minutes, one of
the two RAID devices becomes visible.  (I assume that in this case,
something is loading 3w-9xxx.ko from the root filesystem, which is
version 3.16.43-2+deb8u5.)

In case it is useful, below is the log from the *old, working kernel*
(3.16.43-2+deb8u5).


-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=UUID=9927902d-f34d-44ff-b316-b06fdbab989f ro quiet

** Not tainted

** Kernel log:
[   18.018936] [drm]   HPD2
[   18.018938] [drm]   DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c
[   18.018939] [drm]   Encoders:
[   18.018940] [drm] CRT2: INTERNAL_DAC2
[   18.018942] [drm] DFP2: INTERNAL_DVO1
[   18.083633] [drm] fb mappable at 0xD004
[   18.083638] [drm] vram apper at 0xD000
[   18.083640] [drm] size 786432
[   18.083641] [drm] fb depth is 8
[   18.083643] [drm]pitch is 1024
[   18.083755] fbcon: radeondrmfb (fb0) is primary device
[   18.236979] Console: switching to colour frame buffer device 128x48
[   18.244485] radeon :01:01.0: fb0: radeondrmfb frame buffer device
[   18.244488] radeon :01:01.0: registered panic notifier
[   18.263937] [drm] Initialized radeon 2.39.0 20080528 for :01:01.0 on 
minor 0
[   18.810759] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.810764] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.810780] sd 0:0:0:0: [sda] Invalid command failure
[   18.810787] sd 9:0:0:0: [sdb] Invalid command failure
[   18.810790] sd 9:0:0:0: [sdb]  
[   18.810793] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   18.810795] sd 9:0:0:0: [sdb]  
[   18.810798] Sense Key : Illegal Request [current] 
[   18.810806] sd 0:0:0:0: [sda]  
[   18.810807] sd 9:0:0:0: [sdb]  
[   18.810814] Add. Sense: Invalid command operation code
[   18.810818] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   18.810821] sd 0:0:0:0: [sda]  
[   18.810824] Sense Key : Illegal Request [current] 
[   18.810829] sd 9:0:0:0: [sdb] CDB: 
[   18.810831] ATA command pass through(16): 85 06
[   18.810837] sd 0:0:0:0: [sda]  
[   18.810842]  20
[   18.810844] Add. Sense: Invalid command operation code
[   18.810846] sd 0:0:0:0: [sda] CDB: 
[   18.810848] ATA command pass through(16): 85
[   18.810853]  00
[   18.810855]  06 20 00 05
[   18.810860]  05
[   18.810861]  00 fe 00 00
[   18.810867]  00
[   18.810869]  fe
[   18.810871]  00
[   18.810873]  00
[   18.810874]  00
[   18.810876]  00
[   18.810877]  00
[   18.810879]  00
[   18.810880]  40
[   18.810882]  ef
[   18.810883]  00

[   18.810887]  00
[   18.810889]  00 00 00 40 ef 00
[   18.811173] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.811231] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.811429] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.811498] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.835037] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.835048] sd 0:0:0:0: [sda] Invalid command failure
[   18.835054] sd 0:0:0:0: [sda]  
[   18.835056] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   18.835059] sd 0:0:0:0: [sda]  
[   18.835061] Sense Key : Illegal Request [current] 
[   18.835065] sd 0:0:0:0: [sda]  
[   18.835068] Add. Sense: Invalid command operation code
[   18.835071] sd 0:0:0:0: [sda] CDB: 
[   18.835073] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[   18.835462] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.835732] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   

Bug#881465: Bug#883660: xview: font_find_font () from /usr/lib/libxview.so.3 Segmentation fault Core was generated by `olwmslave'.

[Benjamin Moody]

Control: forcemerge 883660 881465

On 12/6/17, Veek M  wrote:
> Source: xview
> Version: 3.2p1.4-28.2
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
> Not sure
>
> [29018.708980] olwmslave[5196]: segfault at 49cdf010 ip 7f186f2b2910 sp
> 7ffd635dd570 error 4 in libxview.so.3.2.4[7f186f24d000+154000]

Sorry to say, XView is (and always has been) completely broken on
amd64 and other LP64 architectures.  Fixing this is something that is
not likely to happen in the forseeable future.

IIRC, olwm and olvwm (the window managers themselves) do actually work
on amd64 because they don't use the xview library, but olwmslave
*does* use xview so it doesn't work.

I would recommend that you simply use the i386 packages, and I would
recommend that amd64 and other LP64 archs be dropped from the Debian
packages completely.

I see that you already have i386 enabled, but for anybody else reading
this, here's how to enable it and install 32-bit olwm and olvwm (on
unstable):

dpkg --add-architecture i386
apt-get update
apt-get install olwm:i386 olvwm:i386

Bug#881959: python3.5-doc: Please include documentation in info format

[Benjamin Moody]

On 11/16/17, Matthias Klose <d...@debian.org> wrote:
>
> sure, I can fix the description. I don't have any intent to work on
> providing the info docs. Feel free to send a patch for the python3.7
> packages.

Here is a patch to do that.  There are a few minor changes beyond
simply enabling texinfo output:

The version number is added to the name of the info file as well as to
the dir entry, so that multiple versions can be installed
simultaneously.

The images are moved to a subdirectory /usr/share/info/python3.7/,
where the individual files are symbolic links to
/usr/share/doc/python3.7/html/_images/ (assuming that all of the
images referenced by the info document are installed in that location,
which seems to be the case.)

(I'm not at all familiar with sphinx - it may be possible to change
these things through sphinx's configuration rather than editing the
generated .texi file.)

Trailing whitespace is also removed (it's a minor annoyance if, like
me, you have show-trailing-whitespace turned on in emacs by default.)
This should probably be fixed in sphinx or in makeinfo, but it's easy
enough to fix here.

At first I tried simply making /usr/share/info/python3.7 a link to
/usr/share/doc/python3.7/html/_images, but lintian doesn't like that.
(Arguably a bug in lintian.)  This is probably cleaner anyway.
diff -uNr python3.7-3.7.0~a2.orig/debian/PVER-doc.info.in python3.7-3.7.0~a2/debian/PVER-doc.info.in
--- python3.7-3.7.0~a2.orig/debian/PVER-doc.info.in	1969-12-31 19:00:00.0 -0500
+++ python3.7-3.7.0~a2/debian/PVER-doc.info.in	2017-11-27 16:59:32.075212677 -0500
@@ -0,0 +1 @@
+Doc/build/texinfo/@PVER@.info
diff -uNr python3.7-3.7.0~a2.orig/debian/control python3.7-3.7.0~a2/debian/control
--- python3.7-3.7.0~a2.orig/debian/control	2017-09-20 10:09:55.0 -0400
+++ python3.7-3.7.0~a2/debian/control	2017-11-27 16:30:16.930304108 -0500
@@ -16,7 +16,7 @@
   libgpm2 [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64],
   mime-support, netbase, bzip2, time, python3:any,
   net-tools, xvfb, xauth
-Build-Depends-Indep: python3-sphinx
+Build-Depends-Indep: python3-sphinx, texinfo
 Standards-Version: 4.1.0
 Vcs-Browser: https://code.launchpad.net/~doko/python/pkg3.7-debian
 Vcs-Bzr: http://bazaar.launchpad.net/~doko/python/pkg3.7-debian
diff -uNr python3.7-3.7.0~a2.orig/debian/control.in python3.7-3.7.0~a2/debian/control.in
--- python3.7-3.7.0~a2.orig/debian/control.in	2017-09-20 10:09:09.0 -0400
+++ python3.7-3.7.0~a2/debian/control.in	2017-11-27 16:29:50.030044673 -0500
@@ -16,7 +16,7 @@
   libgpm2 [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64],
   mime-support, netbase, bzip2, time, python3@bd_qual@,
   net-tools, xvfb, xauth
-Build-Depends-Indep: python3-sphinx
+Build-Depends-Indep: python3-sphinx, texinfo
 Standards-Version: 4.1.0
 Vcs-Browser: https://code.launchpad.net/~doko/python/pkg@VER@-debian
 Vcs-Bzr: http://bazaar.launchpad.net/~doko/python/pkg@VER@-debian
diff -uNr python3.7-3.7.0~a2.orig/debian/patches/doc-build-texinfo.patch python3.7-3.7.0~a2/debian/patches/doc-build-texinfo.patch
--- python3.7-3.7.0~a2.orig/debian/patches/doc-build-texinfo.patch	1969-12-31 19:00:00.0 -0500
+++ python3.7-3.7.0~a2/debian/patches/doc-build-texinfo.patch	2017-11-27 16:24:09.058754270 -0500
@@ -0,0 +1,27 @@
+Description: Add the option to build Texinfo-format documentation.
+Author: Benjamin Moody <benja...@physionet.org>
+Bug-Debian: https://bugs.debian.org/881959
+Last-Update: 2017-11-27
+
+--- python3.7-3.7.0~a2.orig/Doc/Makefile
 python3.7-3.7.0~a2/Doc/Makefile
+@@ -27,6 +27,7 @@ help:
+ 	@echo "  htmlview   to open the index page built by the html target in your browser"
+ 	@echo "  htmlhelp   to make HTML files and a HTML help project"
+ 	@echo "  latex  to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
++	@echo "  texinfoto make Texinfo files"
+ 	@echo "  text   to make plain text files"
+ 	@echo "  epub   to make EPUB files"
+ 	@echo "  changesto make an overview over all changed/added/deprecated items"
+@@ -72,6 +73,11 @@ latex: build
+ 	@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+ 	  "run these through (pdf)latex."
+ 
++texinfo: BUILDER = texinfo
++texinfo: build
++	@echo "Build finished; the Texinfo files are in build/texinfo."
++	@echo "Run \`make\' in that directory to run these through makeinfo."
++
+ text: BUILDER = text
+ text: build
+ 	@echo "Build finished; the text files are in build/text."
diff -uNr python3.7-3.7.0~a2.orig/debian/patches/series python3.7-3.7.0~a2/debian/patches/series
--- python3.7-3.7.0~a2.orig/debian/patches/series	2017-09-20 09:40:37.0 -0400
+++ python3.7-3.7.0~a2/debian/patches/series	2017-11-27 16:23:32.730403419 -0500
@@ -32,3 +32,4 @@
 pydoc-use-pager.diff
 pyhash.diff
 temporary-changes.diff
+doc-build-texinfo.patch
diff -uNr python3.7-3.7.0

Bug#881959: python3.5-doc: Please include documentation in info format

[Benjamin Moody]

Package: python3.5-doc
Version: 3.5.3-1
Severity: wishlist

Dear Maintainer,

The description for the python3-doc package says

This is the official set of documentation for the interactive
high-level object-oriented language Python 3 (v3.5). All documents
are provided in HTML format, some in info format. The package
consists of nine documents: [...]

This is incorrect; the current package does not include any info
files.  (The python3.{4,5,6}-doc package descriptions do not mention
info.)

However, it seems to be possible (still? again?) to convert the
documentation to info format, as described at
:

> sudo apt-get install python3-sphinx
> cd ~/Desktop
> wget https://www.python.org/ftp/python/3.4.2/Python-3.4.2rc1.tar.xz
> tar -xf Python-3.4.2rc1.tar.xz
> cd Python-3.4.2rc1/Doc/
> sphinx-build -b texinfo -d build/doctrees . build/texinfo
> # extra time to build
> cd build/texinfo/
> makeinfo python.texi
> # extra time for convertation

As such, it would be nice to have this built and included in the
python3.*-doc package (and perhaps python2.7-doc too.)


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

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

Versions of packages python3.5-doc depends on:
ii  libjs-jquery  3.1.1-2
ii  libjs-underscore  1.8.3~dfsg-1

python3.5-doc recommends no packages.

Versions of packages python3.5-doc suggests:
ii  python3.5  3.5.3-1

-- no debconf information

Bug#834420: Fix latex2html init file loading when '.' is not in @INC

[Benjamin Moody]

Control: tags -1 + patch

Here is a patch to fix the init file loading issue (bug #834420).

It appears that the reason this is _not_ currently an FTBFS is that
debhelper sets PERL_USE_UNSAFE_INC=1.

Presumably for the same reason, other packages that use latex2html and
rely on this feature, if they use 'dh', are not currently affected.

And although bug #834423 is a separate issue, presumably debhelper is
also the reason that bug does not occur on stretch.

I generally agree that for a "text processing" tool like latex2html to
load perl code, by default, from a hidden file in the current
directory, is a poor design decision.  Not sure what can be done about
that.

(That said, I wouldn't run latex2html on untrusted input any more than
I would run latex on untrusted input.)
Description: Correctly load init file if it is in the current directory.
 By default, if a file '.latex2html-init' exists in the current
 directory, it is loaded at startup.  Alternatively, the user can
 specify an init file on the command line.
 .
 The previous code would simply 'require' this file, on the assumption
 that the current directory is part of @INC.  On Debian, @INC no
 longer contains '.' by default, so this fails.
 .
 Instead, prepend './' to the init file name, unless it is already an
 absolute path, so that perl will load the desired file (and no other)
 regardless of the value of @INC.

Author: Benjamin Moody <benjamin.mo...@gmail.com>
Bug-Debian: https://bugs.debian.org/834420
Last-Update: 2017-10-25

--- latex2html-2015-debian1.orig/latex2html.pin
+++ latex2html-2015-debian1/latex2html.pin
@@ -434,7 +434,11 @@ if ($INIT_FILE) {
 if (-f $INIT_FILE && -r _) {
 print "Note: Initialising with file: $INIT_FILE\n"
 if ($DEBUG || $VERBOSITY);
-require($INIT_FILE);
+if ($INIT_FILE =~ /^\//) {
+require($INIT_FILE);
+} else {
+require("./$INIT_FILE");
+}
 } else {
 die "Error: Could not find file (-init_file): $INIT_FILE\n";
 }

Bug#879711: bash: Annoying "bad substitution" warning when tab-completing inside backquotes

[Benjamin Moody]

Package: bash
Version: 4.4-5
Severity: minor

Dear Maintainer,

When, at the bash prompt, I type something like:

   g c c  ` / u  b  p k g - c 

I expect this to be completed as:

   $ gcc `/usr/bin/pkg-config

(this is a somewhat silly example, but should give you the idea...)

However, every time I press Tab in this example, it displays a warning
message such as:

   bash: bad substitution: no closing "`" in `/usr

which is extremely annoying, because this message appears in the
middle of the text I'm trying to type.  So my screen looks like this:

   $ gcc `/ubash: bad substitution: no closing "`" in `/usr
   sr/bbash: bad substitution: no closing "`" in `/usr/bin
   in/pkg-cbash: bad substitution: no closing "`" in `/usr/bin/pkg-config
   onfig

This problem has been around for a while, but not forever (just tested
bash 4.2.37 from wheezy and it doesn't have this issue.)

It appears to be independent of whether the bash-completion package is
installed.  I usually disable completion entirely ('complete -r' in my
.bashrc), and that seems to make no difference.


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

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

Versions of packages bash depends on:
ii  base-files   9.9+deb9u1
ii  dash 0.5.8-2.4
ii  debianutils  4.8.1.1
ii  libc62.24-11+deb9u1
ii  libtinfo56.0+20161126-1+deb9u1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- debconf-show failed

Bug#869729: apache2: 'service apache2 restart' sometimes stops without restarting

[Benjamin Moody]

Thanks for your suggestions.  I still don't see any clues about
what's going on.

It seems that it fails if I leave the server running for a while
and then try to restart it, but it works if I've just restarted
it recently.

Here's the output of journalctl:

$ sudo journalctl -u apache2.service | tail
Jul 25 17:54:42 physionet1.ecg.mit.edu systemd[1]: Stopping LSB:
Apache2 web server...
Jul 25 17:54:43 physionet1.ecg.mit.edu apache2[26339]: Stopping web
server: apache2.
Jul 25 17:54:43 physionet1.ecg.mit.edu systemd[1]: Starting LSB:
Apache2 web server...
Jul 25 17:54:44 physionet1.ecg.mit.edu apache2[26363]: Starting web
server: apache2.
Jul 25 17:54:44 physionet1.ecg.mit.edu systemd[1]: Started LSB:
Apache2 web server.
Jul 26 00:02:02 physionet1.ecg.mit.edu apache2[803]: Stopping web
server: apache2.
Jul 27 14:30:48 physionet1.ecg.mit.edu systemd[1]: Starting LSB:
Apache2 web server...
Jul 27 14:30:48 physionet1.ecg.mit.edu apache2[11430]: Starting web
server: apache2.
Jul 27 14:30:51 physionet1.ecg.mit.edu apache2[11439]: Stopping web
server: apache2.
Jul 27 14:30:51 physionet1.ecg.mit.edu systemd[1]: Started LSB:
Apache2 web server.


$ sudo service apache2 status
● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2)
  Drop-In: /lib/systemd/system/apache2.service.d
   └─forking.conf
   Active: inactive (dead) since Thu 2017-07-27 14:30:51 EDT; 3min 22s ago
  Process: 11439 ExecStop=/etc/init.d/apache2 stop (code=exited,
status=0/SUCCESS)
  Process: 11430 ExecStart=/etc/init.d/apache2 start (code=exited,
status=0/SUCCESS)

Jul 27 14:30:48 physionet1.ecg.mit.edu apache2[11430]: Starting web
server: apache2.
Jul 27 14:30:51 physionet1.ecg.mit.edu apache2[11439]: Stopping web
server: apache2.
Jul 27 14:30:51 physionet1.ecg.mit.edu systemd[1]: Started LSB:
Apache2 web server.


The same messages also appear in /var/log/daemon.log and
/var/log/syslog; there's nothing more after 'Started LSB: Apache2
web server'.


apache error log shows a message at shutdown, but nothing for starting up:

$ sudo tail /var/log/apache2/error.log
$ sudo tail /var/log/apache2/error.log.1
[Thu Jul 27 00:13:06.420511 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 00:13:07.421537 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 00:13:08.422584 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 00:13:09.423615 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 00:13:10.424641 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 00:13:11.425616 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 00:13:12.426582 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 00:13:13.427615 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 00:13:14.428661 2017] [mpm_event:error] [pid 20472:tid
140057478371200] AH00485: scoreboard is full, not at MaxRequestWorkers
[Thu Jul 27 14:30:50.574596 2017] [mpm_event:notice] [pid 20472:tid
140057478371200] AH00491: caught SIGTERM, shutting down


Here is the 'term.log' from upgrading deb8u9 -> deb8u10, nothing looks unusual:

Log started: 2017-07-19  15:18:07
(Reading database ... ^M(Reading database ... 5%^M(Reading database
... 10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Re
ading database ... 25%^M(Reading database ... 30%^M(Reading database
... 35%^M(Reading database ... 40%^M(Reading database ... 45%^M(R
eading database ... 50%^M(Reading database ... 55%^M(Reading database
... 60%^M(Reading database ... 65%^M(Reading database ... 70%^M(
Reading database ... 75%^M(Reading database ... 80%^M(Reading database
... 85%^M(Reading database ... 90%^M(Reading database ... 95%^M
(Reading database ... 100%^M(Reading database ... 97551 files and
directories currently installed.)
Preparing to unpack .../apache2-mpm-event_2.4.10-10+deb8u10_amd64.deb ...
Unpacking apache2-mpm-event (2.4.10-10+deb8u10) over (2.4.10-10+deb8u9) ...
Preparing to unpack .../apache2.2-bin_2.4.10-10+deb8u10_amd64.deb ...
Unpacking apache2.2-bin (2.4.10-10+deb8u10) over (2.4.10-10+deb8u9) ...
Preparing to unpack .../apache2_2.4.10-10+deb8u10_amd64.deb ...
Unpacking apache2 (2.4.10-10+deb8u10) over (2.4.10-10+deb8u9) ...
Preparing to unpack .../apache2-bin_2.4.10-10+deb8u10_amd64.deb ...
Unpacking apache2-bin (2.4.10-10+deb8u10) over (2.4.10-10+deb8u9) ...
Preparing to unpack .../apache2-utils_2.4.10-10+deb8u10_amd64.deb ...
Unpacking apache2-utils (2.4.10-10+deb8u10) over (2.4.10-10+deb8u9) ...
Preparing to unpack 

Bug#869729: apache2: 'service apache2 restart' sometimes stops without restarting

[Benjamin Moody]

Package: apache2
Version: 2.4.10-10+deb8u10
Severity: normal

Dear Maintainer,

as the subject line says, sometimes running 'service apache2 restart'
fails to restart apache.  Instead, it *stops* apache without
restarting it, and fails to give any error message.

In addition, sometimes, *upgrading* the apache2 packages causes the
web server to be stopped without restarting.  In fact, I first noticed
this problem when I upgraded to (I think) version 2.4.10-10+deb8u10,
and only noticed a couple hours later that the web server wasn't
running for some reason.  So this seems to be a recent change.

It is not easy to reproduce this issue.  I just ran 'service apache2
restart' several times in a row, as well as reinstalling the packages
using 'apt-get install --reinstall apache2-bin apache2-utils
apache2-data apache2 apache2-mpm-event', and every time the web server
came back as expected.

(I don't know whether 'systemctl' has the same problem.  I manage a
number of heterogeneous systems and use 'service' out of habit.)

This is a heavily customized server with a bunch of weird stuff going
on in its configuration.  However, as far as I'm aware, there's
nothing about the apache configuration that *should* cause it to fail
- when I notice that apache is not running, I log in and run 'service
apache2 restart' again, and it works.


-- Package-specific info:

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

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

Versions of packages apache2 depends on:
ii  apache2-bin2.4.10-10+deb8u10
ii  apache2-data   2.4.10-10+deb8u10
ii  apache2-utils  2.4.10-10+deb8u10
ii  dpkg   1.17.27
ii  lsb-base   4.1+Debian13+nmu1
ii  mime-support   3.58
ii  perl   5.20.2-3+deb8u7
ii  procps 2:3.3.9-9

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.35

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx-cur [www-browser]   2.8.9dev1-2+deb8u1
ii  w3m [www-browser]0.5.3-19+deb8u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.1-3
ii  libaprutil1  1.5.4-1
ii  libaprutil1-dbd-mysql1.5.4-1
ii  libaprutil1-dbd-pgsql1.5.4-1
ii  libaprutil1-dbd-sqlite3  1.5.4-1
ii  libaprutil1-ldap 1.5.4-1
ii  libc62.19-18+deb8u10
ii  libldap-2.4-22.4.40+dfsg-1+deb8u3
ii  liblua5.1-0  5.1.5-7.1
ii  libpcre3 2:8.35-3.3+deb8u4
ii  libssl1.0.0  1.0.1t-1+deb8u6
ii  libxml2  2.9.1+dfsg1-5+deb8u4
ii  perl 5.20.2-3+deb8u7
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx-cur [www-browser]   2.8.9dev1-2+deb8u1
ii  w3m [www-browser]0.5.3-19+deb8u1

Versions of packages apache2 is related to:
ii  apache2  2.4.10-10+deb8u10
ii  apache2-bin  2.4.10-10+deb8u10

-- Configuration Files:
/etc/apache2/apache2.conf changed:
Mutex file:${APACHE_LOCK_DIR} default
PidFile ${APACHE_PID_FILE}
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
HostnameLookups Off
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
Include ports.conf

Options FollowSymLinks
AllowOverride None
Require all denied


AllowOverride None
Require all granted


Options Indexes FollowSymLinks
AllowOverride None
Require all granted

AccessFileName .htaccess

Require all denied

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
IncludeOptional conf.d/*.conf

/etc/apache2/envvars changed:
unset HOME
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
SUFFIX="-${APACHE_CONFDIR##/etc/apache2-}"
else
SUFFIX=
fi
export APACHE_RUN_USER=apache
export APACHE_RUN_GROUP=apache
export APACHE_PID_FILE=/var/run/apache2$SUFFIX.pid
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
export LANG=C
export LANG

/etc/apache2/mods-available/authn_dbd.load changed:
LoadModule auth_pgsql_module 

Bug#802850: Kludge to enable unsharing network in sbuild

[Benjamin Moody]

In case anybody else is interested in doing this, I made the following
hackish patch and it seems to work.  It requires schroot 1.7.0 or
later; I used 1.7.2-3 from experimental, recompiled to run on jessie.

--- sbuild-0.65.2.orig/lib/Sbuild/ChrootSchroot.pm
+++ sbuild-0.65.2/lib/Sbuild/ChrootSchroot.pm
@@ -125,6 +125,9 @@ sub get_command_internal {
'-c', $self->get('Session ID'),
'--run-session',
@{$self->get_conf('SCHROOT_OPTIONS')},
+   '-o', ($user eq 'root'
+  ? 'unshare.net=false'
+  : 'unshare.net=true'),
'-u', "$user", '-p', '--',
@$command);


For this to work, you will also need to add a line to the schroot
config file (e.g. /etc/schroot/chroot.d/jessie-amd64-sbuild-xyzzy):

user-modifiable-keys=unshare.net

Bug#852532: Acknowledgement (olvwm: source code not 64-bit clean, SIGSEGV everywhere)

[Benjamin Moody]

Unless there is an automated way to identify all the cases of
integer/pointer confusion, I don't expect there'll ever be a way to
make libxview work on LP64 systems.  I am less familiar with
olwm/olvwm, but this report is not encouraging.

It seems to me that the most sensible thing to do would be to drop the
amd64 and other LP64 architectures; for folks who are using olwm/olvwm
on amd64, I would recommend installing the i386 version instead (or
x32, when that becomes possible.)

Benjamin

Bug#731998: Multiarchifying libcurl4-*-dev

[Benjamin Moody]

First, note that this issue is more serious in jessie and stretch than
it was in wheezy, because in wheezy, libcurl4-*-dev Depended on a
bunch of packages that were not multiarch-compatible (and thus,
libcurl4-*-dev was not co-installable in practice.)  In jessie,
however, those other packages are merely Suggested.

Here are patches that should fix the issue (for the jessie version;
the same changes ought to work for the stretch/sid versions but I
haven't tried.)

(When I actually tried building these packages, for amd64 and i386, I
found that the curl-config scripts still differed, which was
apparently because I had 'libnghttp2-dev' installed in the amd64 build
system for some reason - it seems curl will use that package if it's
available.  I'm pretty sure that if both builds are done in clean
environments, the curl-config scripts will be identical.  But that's
something to be aware of, and maybe the package should either support
and build-depend on libnghttp2-dev, or explicitly disable it.)

One side issue that I didn't address is that `pkg-config --cflags
libcurl` will now output -I/usr/include/, which is not ideal,
but acceptable (if you're using pkg-config and building for a
"foreign" architecture, you'll probably need to set appropriate
pkg-config environment variables anyway.)
In order to (partially) multi-arch-ify curl-config, remove all mention
of @includedir@ and @libdir@ from the script.  On Debian, the actual
header and library directories are architecture-dependent, but will
always be in the C compiler's default search path, so -I and -L
options are not necessary (and may be harmful in multi-arch
environments.)

Index: curl-7.38.0/curl-config.in
===
--- curl-7.38.0.orig/curl-config.in
+++ curl-7.38.0/curl-config.in
@@ -23,7 +23,6 @@
 
 prefix=@prefix@
 exec_prefix=@exec_prefix@
-includedir=@includedir@
 cppflag_curl_staticlib=@CPPFLAG_CURL_STATICLIB@
 
 usage()
@@ -134,19 +133,11 @@ while test $# -gt 0; do
 else
   CPPFLAG_CURL_STATICLIB=""
 fi
-if test "X@includedir@" = "X/usr/include"; then
-  echo "$CPPFLAG_CURL_STATICLIB"
-else
-  echo "${CPPFLAG_CURL_STATICLIB}-I@includedir@"
-fi
+echo "$CPPFLAG_CURL_STATICLIB"
 ;;
 
 --libs)
-if test "X@libdir@" != "X/usr/lib" -a "X@libdir@" != "X/usr/lib64"; then
-   CURLLIBDIR="-L@libdir@ "
-else
-   CURLLIBDIR=""
-fi
+CURLLIBDIR=""
 if test "X@REQUIRE_LIB_DEPS@" = "Xyes"; then
   echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
 else
@@ -156,7 +147,7 @@ while test $# -gt 0; do
 
 --static-libs)
 if test "X@ENABLE_STATIC@" != "Xno" ; then
-  echo @libdir@/libcurl.@libext@ @LDFLAGS@ @LIBCURL_LIBS@
+  echo -Wl,-Bstatic -lcurl -Wl,-Bdynamic @LDFLAGS@ @LIBCURL_LIBS@
 else
   echo "curl was built with static libraries disabled" >&2
   exit 1
--- curl-7.38.0.orig/debian/rules	2016-11-01 17:38:10.0 -0400
+++ curl-7.38.0/debian/rules	2016-12-14 16:15:53.85200 -0500
@@ -9,9 +9,13 @@
 # enable all hardening options (see #763372)
 export DEB_BUILD_MAINT_OPTIONS:=hardening=+all
 
+DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+
 CONFIGURE_ARGS = -- --disable-dependency-tracking		\
 	--disable-symbol-hiding --enable-versioned-symbols	\
-	--enable-threaded-resolver --with-lber-lib=lber --with-gssapi=/usr
+	--enable-threaded-resolver --with-lber-lib=lber --with-gssapi=/usr \
+	--includedir=/usr/include/$(DEB_HOST_MULTIARCH)
 
 %:
 	dh $@
@@ -72,6 +76,27 @@
 	dh_install -pcurl -plibcurl3 -plibcurl4-openssl-dev -plibcurl4-doc \
 		--sourcedir=debian/tmp
 	sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'`
+# Modify curl-config to make it architecture-independent:
+# 1. In --static-libs output, replace the output of krb5-config (which
+#currently includes architecture-specific paths) with a call at
+#runtime to krb5-config.  Of course, this will only work correctly
+#if the installed libkrb5-dev matches the architecture of the
+#program you're linking, or if libkrb5-dev is made
+#multiarch-compatible at some point in the future.  For dynamic
+#linking this has no impact.
+# 2. In --configure output, replace the architecture-specific paths
+#used for --libdir and --libexecdir with a literal backquoted call
+#to dpkg-architecture.  This is functionally equivalent to the way
+#debhelper actually invokes configure, and indicates to the user
+#(who runs curl-config --configure in order to learn about how the
+#library was compiled) that they are in fact using a multi-arch
+#package.
+# 3. Likewise, replace the architecture name used for --build (and
+#build_alias) with a literal backquoted call to dpkg-architecture.
+	sed -e "/-lcurl /s|`krb5-config 

Bug#846360: libcurl -dev multiarch compatibility

[Benjamin Moody]

This is a duplicate of bug #731998.

Bug#784918: xviewg: XView crashes if _SC_OPEN_MAX > FD_SETSIZE

[Benjamin Moody]

Here is the patch to fix this issue.
Description: Limit number of file descriptors used for select() to FD_SETSIZE.
 The GETDTABLESIZE macro is used to determine the maximum file
 descriptor that can be used with select().  On Linux, the upper limit
 on newly-opened file descriptors (returned, equivalently, by either
 sysconf(_SC_OPEN_MAX), getrlimit(RLIMIT_FSIZE), or getdtablesize())
 is variable, and may be greater than the size of the 'fd_set'
 structure.  In particular, systemd apparently sets the limit to 65536
 by default, whereas glibc's 'fd_set' is only 1024 bits.  Thus, the
 macro should return either the upper limit returned by
 getdtablesize(), or the constant FD_SETSIZE, whichever is smaller.

--- xview-3.2p1.4.orig/lib/libxview/notify/ndet_fd.c
+++ xview-3.2p1.4/lib/libxview/notify/ndet_fd.c
@@ -24,12 +24,14 @@ static char sccsid[] = "@(#)ndet_fd.
 /* performance: global cache of getdtablesize() */
 extern int  dtablesize_cache;
 #ifdef SVR4
-#define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=(int)sysconf(_SC_OPEN_MAX)))
+#define GETDTABLESIZE_MAX() (int)sysconf(_SC_OPEN_MAX)
 #else
-#define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=getdtablesize()))
+#define GETDTABLESIZE_MAX() getdtablesize()
 #endif /* SVR4 */
+#define GETDTABLESIZE() \
+  (dtablesize_cache ? dtablesize_cache : \
+   (dtablesize_cache = (GETDTABLESIZE_MAX() >= FD_SETSIZE \
+? FD_SETSIZE : GETDTABLESIZE_MAX(
 
 static int  ndet_fd_table_size;	/* Number of descriptor slots
 	 * available */
--- xview-3.2p1.4.orig/lib/libxview/notify/ndisdispch.c
+++ xview-3.2p1.4/lib/libxview/notify/ndisdispch.c
@@ -27,12 +27,14 @@ static char sccsid[] = "@(#)ndisdisp
 /* performance: global cache of getdtablesize() */
 int dtablesize_cache = 0;
 #ifdef SVR4
-#define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=(int)sysconf(_SC_OPEN_MAX)))
+#define GETDTABLESIZE_MAX() (int)sysconf(_SC_OPEN_MAX)
 #else
-#define GETDTABLESIZE() \
- (dtablesize_cache?dtablesize_cache:(dtablesize_cache=getdtablesize()))
+#define GETDTABLESIZE_MAX() getdtablesize()
 #endif /* SVR4 */
+#define GETDTABLESIZE() \
+  (dtablesize_cache ? dtablesize_cache : \
+   (dtablesize_cache = (GETDTABLESIZE_MAX() >= FD_SETSIZE \
+? FD_SETSIZE : GETDTABLESIZE_MAX(
 
 pkg_private_data u_int ndis_flags = 0;
 pkg_private_data NTFY_CLIENT *ndis_clients = 0;
--- xview-3.2p1.4.orig/lib/libxview/sel/sel_agent.c
+++ xview-3.2p1.4/lib/libxview/sel/sel_agent.c
@@ -1529,12 +1529,14 @@ block(display, xevent, seconds)
 /* performance: global cache of getdtablesize() */
 extern int  dtablesize_cache;
 #ifdef SVR4
-#define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=(int)sysconf(_SC_OPEN_MAX)))
+#define GETDTABLESIZE_MAX() (int)sysconf(_SC_OPEN_MAX)
 #else
-#define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=getdtablesize()))
+#define GETDTABLESIZE_MAX() getdtablesize()
 #endif /* SVR4 */
+#define GETDTABLESIZE() \
+  (dtablesize_cache ? dtablesize_cache : \
+   (dtablesize_cache = (GETDTABLESIZE_MAX() >= FD_SETSIZE \
+? FD_SETSIZE : GETDTABLESIZE_MAX(
 
 
 /*
--- xview-3.2p1.4.orig/lib/libxview/textsw/txt_filter.c
+++ xview-3.2p1.4/lib/libxview/textsw/txt_filter.c
@@ -62,12 +62,14 @@ static char sccsid[] = "@(#)txt_filt
 extern int  dtablesize_cache;
 
 #ifdef SVR4
-#define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=(int)sysconf(_SC_OPEN_MAX)))
+#define GETDTABLESIZE_MAX() (int)sysconf(_SC_OPEN_MAX)
 #else
-#define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=getdtablesize()))
+#define GETDTABLESIZE_MAX() getdtablesize()
 #endif /* SVR4 */
+#define GETDTABLESIZE() \
+  (dtablesize_cache ? dtablesize_cache : \
+   (dtablesize_cache = (GETDTABLESIZE_MAX() >= FD_SETSIZE \
+? FD_SETSIZE : GETDTABLESIZE_MAX(
 
 
 extern int  errno;
--- xview-3.2p1.4.orig/lib/libxview/ttysw/term_ntfy.c
+++ xview-3.2p1.4/lib/libxview/ttysw/term_ntfy.c
@@ -63,13 +63,15 @@ Pkg_private void ttysw_print_debug_strin
 /* performance: global cache of getdtablesize() */
 extern int  dtablesize_cache;
 
-#if defined(SVR4) || defined(__linux__)
-#define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=(int)sysconf(_SC_OPEN_MAX)))
+#ifdef SVR4
+#define GETDTABLESIZE_MAX() (int)sysconf(_SC_OPEN_MAX)
 #else
+#define GETDTABLESIZE_MAX() getdtablesize()
+#endif /* SVR4 */
 #define GETDTABLESIZE() \
-(dtablesize_cache?dtablesize_cache:(dtablesize_cache=getdtablesize()))
-#endif
+  (dtablesize_cache ? dtablesize_cache : \
+   (dtablesize_cache = (GETDTABLESIZE_MAX() >= FD_SETSIZE \
+? FD_SETSIZE : GETDTABLESIZE_MAX(
 
 Notify_valuettysw_text_destroy();	/* Destroy func for termsw */
 Notify_value

Bug#818821: Fixes for xview build failures on stretch

[Benjamin Moody]

Here are patches to fix these issues.

First, the use of regexp.h as noted by the submitter.

Second, the use of 'union wait' which is apparently also unsupported
by the glibc in stretch.

Third, the manpage preprocessing error.  This is not actually a build
failure (which is presumably a bug in imake.)  And of course, using
'cpp' to preprocess man pages seems like an even worse idea than using
it to preprocess Makefiles.  But, just in case it'll make somebody
happy, here's a patch to fix that issue.
Description: Use POSIX regular expression API in olvwm.
 Do not use the regexp.h functions, which are not available in current
 glibc.

--- xview-3.2p1.4.orig/clients/olvwm-4.1/virtual.c
+++ xview-3.2p1.4/clients/olvwm-4.1/virtual.c
@@ -58,9 +58,19 @@ static regexp_err(int val);
 #define TRUE 1
 #define FALSE 0
 
+#if 1
+#include 
+#define POSIX_REGEXP
+#else
 #include 
+#endif
+
 #ifdef REGEXP
 regexp *expbuf;
+#elif defined(POSIX_REGEXP)
+static regex_t expbuf;
+#else
+static char expbuf[256];
 #endif
 
 #ifdef IDENT
@@ -2146,14 +2156,14 @@ int val;
 }
 }
 
-static char expbuf[256];
-
 static
 rexMatch(string)
 char *string;
 {
 #ifdef REGEXP
 return regexec(expbuf, string);
+#elif defined(POSIX_REGEXP)
+return !regexec(, string, 0, NULL, 0);
 #else
 return step(string,expbuf);
 #endif
@@ -2191,6 +2201,8 @@ char newPattern[256];
 newPattern[j++] = '\0';
 #ifdef REGEXP
 expbuf = regcomp(newPattern);
+#elif defined(POSIX_REGEXP)
+regcomp(, newPattern, 0);
 #else
 #if defined(__linux__) && defined(__GLIBC__)
 /* See comment above.
Description: Use SysV/POSIX APIs/types in place of some old BSD ones.
 Notably, current glibc doesn't support 'union wait'.

--- xview-3.2p1.4.orig/clients/olvwm-4.1/olwm.c
+++ xview-3.2p1.4/clients/olvwm-4.1/olwm.c
@@ -708,7 +708,7 @@ handleChildSignal()
 void
 ReapChildren()
 {
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
 pid_t pid;
 int status;
 #else
@@ -720,7 +720,7 @@ ReapChildren()
 	if (!deadChildren)
 		return;
 
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
 	sighold(SIGCHLD);
 #else
 	oldmask = sigblock(sigmask(SIGCHLD));
@@ -730,7 +730,7 @@ ReapChildren()
 
 	while (1) {
 
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
 pid = waitpid(-1, , WNOHANG);
 #else
 pid = wait3(, WNOHANG, (struct rusage *)0);
@@ -757,7 +757,7 @@ ReapChildren()
 
 	deadChildren = False;
 
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
 	sigrelse(SIGCHLD);
 #else
 (void) sigsetmask(oldmask);
--- xview-3.2p1.4.orig/clients/olwm/olwm.c
+++ xview-3.2p1.4/clients/olwm/olwm.c
@@ -634,7 +634,7 @@ handleChildSignal()
 void
 ReapChildren()
 {
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
 pid_t pid;
 int status;
 #else
@@ -645,7 +645,7 @@ ReapChildren()
 
 	if (!deadChildren)
 		return;
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
 	sighold(SIGCHLD);
 #else
 	oldmask = sigblock(sigmask(SIGCHLD));
@@ -655,7 +655,7 @@ ReapChildren()
 
 	while (1) {
 
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
 pid = waitpid(-1, , WNOHANG);
 #else
 pid = wait3(, WNOHANG, (struct rusage *)0);
@@ -682,7 +682,7 @@ ReapChildren()
 
 	deadChildren = False;
 
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
 	sigrelse(SIGCHLD);
 #else
 (void) sigsetmask(oldmask);
--- xview-3.2p1.4.orig/contrib/examples/notifier/ntfy_pipe.c
+++ xview-3.2p1.4/contrib/examples/notifier/ntfy_pipe.c
@@ -161,7 +161,7 @@ Notify_value
 sigchldcatcher(client, pid, status, rusage)
 Notify_client client; /* the client noted in main() */
 int pid; /* the pid that died */
-#ifdef SVR4
+#ifdef SYSV_WAIT
 int *status;
 #else
 union wait *status; /* the status of the process (unused here) */
@@ -169,7 +169,7 @@ union wait *status; /* the status of the
 struct rusage *rusage; /* resources used by this process (unused) */
 {
 if (WIFEXITED(*status)) {
-#ifdef SVR4
+#ifdef SYSV_WAIT
 printf("Process termined with status %d\n", *status);
 #else
 printf("Process termined with status %d\n", status->w_retcode);
--- xview-3.2p1.4.orig/lib/libxview/base/base.h
+++ xview-3.2p1.4/lib/libxview/base/base.h
@@ -63,6 +63,7 @@
 #define XV_OS_SVR4
 #undef XV_USE_TTCOMPAT
 #define SYSV_UCONTEXT 
+#define SYSV_WAIT
 #define XV_USE_XVFCNTL 
 #endif
  
--- xview-3.2p1.4.orig/lib/libxview/misc/expandname.c
+++ xview-3.2p1.4/lib/libxview/misc/expandname.c
@@ -121,11 +121,11 @@ xv_expand_name(name)
 	length += status;
 }
 (void) close(pivec[0]);
-#ifndef SVR4
+#ifndef SYSV_WAIT
 while (wait((union wait *) & status) != pid);
-#else /* SVR4 */
+#else /* SYSV_WAIT */
 while (wait( & status) != pid);
-#endif /* SVR4 */
+#endif /* SYSV_WAIT */
 ;
 status &= 0377;
 if (status != 0 && status != SIGPIPE) {
--- xview-3.2p1.4.orig/lib/libxview/notify/ndisd_wait.c
+++ xview-3.2p1.4/lib/libxview/notify/ndisd_wait.c
@@ -22,11 +22,11 @@ extern

Bug#784918: xviewg: XView crashes if _SC_OPEN_MAX > FD_SETSIZE

[Benjamin Moody]

Package: xviewg
Version: 3.2p1.4-28.1
Followup-For: Bug #784918

I assume this bug is the same as the one I've just encountered.
Specifically, XView assumes that the maximum file descriptor is
smaller than the number of bits in the 'fd_set' structure.

The former limit can be modified using the 'ulimit' shell command.  On
wheezy, this limit was 1024 by default; on jessie, it's 65536.  (Is
this a systemd thing, or was the default changed for sysvinit too?)

The latter limit is fixed by the C library; it's defined by the
constant FD_SETSIZE, which equals 1024 in glibc.

So:

1. The easy workaround is to run 'ulimit -S -n 1024' in your
   .bash_profile or whatever.

2. To actually fix xview, the GETDTABLESIZE macro should be modified
   to clamp the value to FD_SETSIZE.  I *hope* that is all that's
   needed, have not yet tested it.

3. If there's a possibility that a program actually needs more than
   1024 FDs, then you have a problem.  (Of course, this is not just
   true of xview, but of any program that uses the 'select' function.)

4. It might be appropriate for programs, or XView itself, to work
   around this issue by calling setrlimit() early in program
   execution.

Will provide a patch once I've tested it.

Bug#831349: backintime-common: Missing dependency on 'python-dbus' package

[Benjamin Moody]

Package: backintime-common
Version: 1.0.36-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The current version of backintime seems to require the 'python-dbus'
package:

# /usr/bin/backintime --backup-job
Traceback (most recent call last):
  File "/usr/share/backintime/common/backintime.py", line 26, in 
import config
  File "/usr/share/backintime/common/config.py", line 30, in 
import tools
  File "/usr/share/backintime/common/tools.py", line 27, in 
import dbus
ImportError: No module named dbus

This is not marked as a dependency, so the program is completely
unusable in a default installation (unless you've installed something
else that pulled in python-dbus.)


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

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

Versions of packages backintime-common depends on:
ii  cron3.0pl1-127+deb8u1
pn  python:any  
ii  rsync   3.1.1-3

backintime-common recommends no packages.

Versions of packages backintime-common suggests:
pn  encfs  
pn  sshfs  

-- no debconf information

Bug#826154: libc6-dev: sys/wait.h does not include sys/resource.h

[Benjamin Moody]

Package: libc6-dev
Version: 2.19-18+deb8u4
Severity: normal

Dear Maintainer,

In previous versions of glibc (such as the version used in Debian
wheezy),  would include .  It now does not
do so.  This breaks existing programs for no obvious reason.

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

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

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.19-18+deb8u4
ii  libc6   2.19-18+deb8u4
ii  linux-libc-dev  3.16.7-ckt25-2

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
ii  manpages-dev  3.74-1

-- no debconf information

Bug#741628: Anything known about the cause of this bug?

[Benjamin Moody]

I'm having this problem, but finding I can't reproduce it reliably.
For what it's worth, I do have some very large files present on the
sending and receiving sides, but none of the files that are actually
being transferred are larger than 75 MB.

(In my case, both sender and receiver are running 3.0.9-4 on amd64.)

Does anyone know whether this problem is on the sender or receiver
side, or both?  I am *guessing* that the problem is the sender
producing an invalid zlib bitstream, so that if the server is using
version 3.1.1, a client using 3.0.9 should be able to receive files
without a problem?  But I know nothing about the details of the rsync
protocol.

Benjamin

Bug#820960: iceweasel: history of keyword searches saved, despite preferences

[Benjamin Moody]

Package: iceweasel
Version: 38.7.1esr-1~deb8u1
Severity: normal

Dear Maintainer,

Despite setting preferences that browsing and search history should be
cleared upon exiting Iceweasel, it seems that the history of "keyword"
searches is still being saved somewhere on disk.

Steps to reproduce:

* Start Iceweasel with a fresh profile, no addons.

* Go to Preferences > Privacy.
  Select "Use custom settings for history".
  Check "Clear history when Iceweasel closes".
   (Note that by default, this includes "Browsing and Download
   History", "Active Logins", "Form and Search History", "Cookies",
   and "Cache".)

* Define a search keyword:
  - Go to https://startpage.com
  - Right-click the text input field.
  - Select "Add a Keyword for this Search".
  - Enter "sp" as the keyword and click Save.

* Perform a search:
  - Type "sp fnord" in the URL bar and press Enter.

* Exit Iceweasel and start it again.

* Type "sp" in the URL bar (without pressing Enter.)

Result: the popup suggestion below the URL bar appears as

   fnord - StartPage Web Search
   https://startpage.com/do/search

indicating that information about the previous search (namely, the
title of the results page, which includes the search terms) is somehow
remembered after exiting the browser.

It should go without saying that this is worrisome for users who are
using a shared system and expecting the "clear history" feature to
work as advertised.


-- Package-specific info:

-- Extensions information
Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

-- Plugins information

-- Addons package information
ii  iceweasel  38.7.1esr-1~ amd64Web browser based on Firefox

-- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-updates'), (1, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages iceweasel depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u4
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.8.20-0+deb8u1
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:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u4
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
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  procps2:3.3.9-9
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1.4.4-2
ii  gstreamer1.0-plugins-good  1.4.4-2

Versions of packages iceweasel suggests:
pn  fonts-mathjax  
pn  fonts-oflb-asana-math  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
pn  libgnomeui-0   
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
pn  mozplugger 

-- no debconf information

Bug#819703: Please continue providing a stable, high-quality X screensaver program in Debian

[Benjamin Moody]

To JWZ: if you don't wish to read about issues like this one, please
stop reading Debian bug reports.  There's no need for you to do so; if
and when an issue arises in a Debian bug report that requires action
from you, you _will_ hear about it.

To everyone:

What about renaming the package, along the lines of iceweasel (i.e.,
"fork in name only")?  If JWZ's frustration is due to clueless users
contacting him directly about bugs in Debian, then renaming the
program would presumably help in redirecting those users' complaints
to the place they belong.

Of course, it's important to keep the existing attribution notices
(unless the author prefers otherwise), but adding additional comments
alongside them, reminding users of where to report bugs, would
certainly also be helpful.

Bug#818240: checkbashisms: should warn about test -nt and -ot

[Benjamin Moody]

Package: devscripts
Version: 2.15.3
Severity: normal

Dear Maintainer,

The '-nt' and '-ot' options to the 'test' or '[' command are not
standardized by POSIX.  These options are implemented by both bash and
dash, but their behavior differs between the two shells in regard to
nonexistent files (see the wontfix'ed bug #558989).

Thus, checkbashisms should warn about the use of these options.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.17.26
ii  libc62.19-18+deb8u3
ii  perl 5.20.2-3+deb8u4
ii  python3  3.4.2-2
pn  python3:any  

Versions of packages devscripts recommends:
ii  at  3.1.16-1
ii  curl7.38.0-4+deb8u3
ii  dctrl-tools 2.23
ii  debian-keyring  2015.04.10
ii  dput0.9.6.4
ii  equivs  2.0.9
ii  fakeroot1.20.2-1
ii  file1:5.22+15-2+deb8u1
ii  gnupg   1.4.18-7
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.03-1
ii  libjson-perl2.61-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libparse-debcontrol-perl2.005-4
ii  libsoap-lite-perl   1.11-1
ii  liburi-perl 1.64-1
ii  libwww-perl 6.08-1
ii  lintian 2.5.30+deb8u4
ii  man-db  2.7.0.2-5
ii  patch   2.7.5-1
ii  patchutils  0.3.3-1
ii  python3-debian  0.1.27
ii  python3-magic   1:5.22+15-2+deb8u1
ii  sensible-utils  0.0.9
ii  strace  4.9-2
ii  unzip   6.0-16+deb8u2
ii  wdiff   1.2.2-1
ii  wget1.16-1
ii  xz-utils5.1.1alpha+20120614-2+b3

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20141216cvs-2
ii  build-essential  11.7
pn  cvs-buildpackage 
pn  debbindiff   
pn  devscripts-el
pn  gnuplot  
ii  gpgv 1.4.18-7
ii  libauthen-sasl-perl  2.1600-1
pn  libfile-desktopentry-perl
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
ii  libyaml-syck-perl1.27-2+b2
ii  mutt 1.5.23-3
ii  openssh-client [ssh-client]  1:6.7p1-5+deb8u1
pn  svn-buildpackage 
ii  w3m  0.5.3-19

-- no debconf information

Bug#816058: parallel: existing file descriptors 3-61 are closed

[Benjamin Moody]

Package: parallel
Version: 20130922-1
Severity: normal

Dear Maintainer,

It seems that 'parallel' will (always?) automatically close all file
descriptors in the range 3 to 61 before starting the child process.

For example:

  $ exec 5 /dev/pts/2
  lrwx-- 1 benjamin benjamin 64 Feb 26 19:42 1 -> /dev/pts/2
  lrwx-- 1 benjamin benjamin 64 Feb 26 19:42 2 -> /dev/pts/2
  lr-x-- 1 benjamin benjamin 64 Feb 26 19:42 3 -> /proc/19896/fd
  lr-x-- 1 benjamin benjamin 64 Feb 26 19:42 5 -> /etc/passwd
  $ parallel ls -l << pipe:[222723]
  lrwx-- 1 benjamin benjamin 64 Feb 26 19:42 1 -> /tmp/L6a2EkkAKD.par 
(deleted)
  lrwx-- 1 benjamin benjamin 64 Feb 26 19:42 2 -> /tmp/AEzA3WKNXP.par 
(deleted)
  lr-x-- 1 benjamin benjamin 64 Feb 26 19:42 3 -> /proc/19925/fd

This does not seem like a *useful* feature to me, and is in fact
making my life a bit difficult at the moment.  The only clue in the
source is the comment that "/dev/fd/62 and above are used by bash for
<(cmd)", but there's no explanation given as to why *those* file
descriptors should be treated differently from file descriptors opened
in other ways.  Moreover I don't see any mention of this in the
documentation.

Is there a reason for this behavior?

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

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

Versions of packages parallel depends on:
ii  perl  5.20.2-3+deb8u3
ii  perl-modules  5.20.2-3+deb8u3

parallel recommends no packages.

parallel suggests no packages.

-- no debconf information

Bug#813155: perl: Inconsistent "insecure dependency" errors from backquotes in taint mode

[Benjamin Moody]

Package: perl
Version: 5.20.2-3+deb8u3
Severity: normal

Dear Maintainer,

Perl seems to give spurious "insecure dependency" errors, in some
cases, when two backquote operators are used within the same
expression (for some definition of "expression").  The behavior seems
highly inconsistent.

Note that none of the below are actually insecure; PATH has been set
and the commands are constant strings.

#!/usr/bin/perl -t
$ENV{PATH} = '/bin:/usr/bin';

$a = `printf hello`;# OK
print "a = $a\n";

$b = `printf world`;# OK
print "b = $b\n";

$c = $a . $b;   # OK
print "c = $c\n";

$d = $a . `printf world`;   # OK
print "d = $d\n";

$e = `printf hello` . $b;   # OK
print "e = $e\n";

$f = `printf hello` . `printf world`; # *** Not OK ***
print "f = $f\n";

sub concat { return $_[0] . $_[1]; }

$g = concat($a, `printf world`); # OK
print "g = $g\n";

$h = concat(`printf hello`, `printf world`); # *** Not OK ***
print "h = $h\n";

$i = concat($a, `printf world`, `printf 1`); # *** Not OK ***
print "i = $i\n";

$j = concat(`printf hello`, '') . `printf world`; # *** Not OK ***
print "j = $j\n";

$k = concat(`printf hello`, '') . concat(`printf world`, ''); # *** Not OK ***
print "k = $k\n";

sub cmdout { return `$_[0]`; }

$l = cmdout('printf hello') . cmdout('printf world'); # OK
print "l = $l\n";

$m = `printf hello` . cmdout('printf world'); # OK
print "m = $m\n";

$n = cmdout('printf hello') . `printf world`; # *** Not OK ***
print "n = $n\n";

$o = concat(cmdout('printf hello'), `printf world`); # OK
print "o = $o\n";

$p = cmdout('printf hello', `printf 1`) . 'world'; # OK
print "p = $p\n";

$q = cmdout('printf hello', `printf 1`, `printf 2`) . 'world'; # *** Not OK ***
print "q = $q\n";


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

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

Versions of packages perl depends on:
ii  dpkg  1.17.26
ii  libbz2-1.01.0.6-7+b3
ii  libc6 2.19-18+deb8u2
ii  libdb5.3  5.3.28-9
ii  libgdbm3  1.8.3-13.1
ii  perl-base 5.20.2-3+deb8u3
ii  perl-modules  5.20.2-3+deb8u3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages perl recommends:
ii  netbase  5.3
ii  rename   0.20-3

Versions of packages perl suggests:
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
ii  make4.0-8.1
ii  perl-doc5.20.2-3+deb8u3

-- no debconf information

Bug#809686: cryptsetup: --header plus UUID plus initramfs gives "Requested offset beyond size of device"

[Benjamin Moody]

On 1/2/16, Milan Broz  wrote:
> Note
>> # Userspace crypto wrapper cannot use aes-xts-plain64 (-95).
>> # Using dmcrypt to access keyslot area.
>
> The reason is that you are missing kernel userspace crypto API modules
> in initram (af_alg, algif_skcipher, ...), then cryptsetup fall back to
> using
> dmcrypt-device for keyslot processing (that requires loop driver).

Ah, this makes sense now.  Adding 'algif_skcipher' instead of 'loop'
to /etc/initramfs-tools/modules does the trick.  The cryptsetup error
reporting could be improved, though - I don't recall the exact
message, but it was originally complaining about not being able to
create a loop device.

It might be sensible for the cryptsetup package to add the
algif_skcipher module (or any others that might be needed?) to the
initramfs automatically if a header file is used.

> But the real problem:
>> === broken cryptsetup log ===
>> Enter passphrase for
>> /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e:
>> Requested offset is beyond real size of device
>> /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e.
>
> ...
>> # Key length 64, device size 4040 sectors, header size 4036 sectors.
>
> Here apparently device size 4040 sectors is wrong (too small).

No, this message seems to refer to the size of the header file; the
same size is shown when it works properly.

> Please check where link
> /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e is pointing,
> check with blockdev --getsz .
>
> I would say that udev created link to used loop device instead of your
> ciphertext device.

You're probably right.  Good old udev just doesn't miss a trick.  Of
course, if I actually run 'ls -l
/dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e', either before
or after running cryptsetup, it will be pointing to /dev/sda2... but
DURING cryptsetup it presumably points to that loop device.

It might be wise for cryptsetup to chase the symlink passed on the
command line before doing anything else, or for the initramfs scripts
to do so.

> (In fact, your command is wrong. If the underlying device has no LUKS header
> on it, there cannot be link with LUKS UUID to it! I would guess you have old
> LUKS header on it as well so witout loop activated it work by chance..)

Yep.  I originally created these partitions using a normal luksFormat,
and then made copies of the headers (which, naturally, doesn't change
the UUID.)  As I said before, I like having the header on the disk for
recovery purposes; and I also think it's probably a good idea to
identify the source partition by UUID or some similar labelling
mechanism, though I see how this can be problematic.  I suppose one
option, to avoid problems in the future, would be to change the UUID
stored in the header file.

Benjamin

Bug#809686: cryptsetup: --header plus UUID plus initramfs gives "Requested offset beyond size of device"

[Benjamin Moody]

Package: cryptsetup
Version: 2:1.6.6-5
Severity: normal

Dear Maintainer,

cryptsetup appears to be broken for a particular unusual case: when

 1. a detached LUKS header is specified using --header,

 2. the source device is a symbolic link such as /dev/disk/by-uuid/*,

and cryptsetup is run *from the initramfs*, it fails with the message
"Requested offset is beyond real size of device".

(My reason for doing this, by the way, is so that the LUKS metadata
can be stored within the initramfs and thereby verified by the
bootloader.  I've kept the duplicate header on the encrypted disk
itself to make it easier to recover if necessary.)

In my case, /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e =
/dev/sda2 and /dev/disk/by-uuid/550a445a-80d1-45f3-9527-4378c8740244 =
/dev/sda3.  (These links are correctly created in the initramfs as
well.)

The following cryptsetup commands work after booting Debian:

 - luksOpen /dev/sda3 sda3_crypt

 - luksOpen /dev/disk/by-uuid/550a* sda3_crypt

 - luksOpen --header=/root/luks-hdr-sda3 /dev/sda3 sda3_crypt

 - luksOpen --header=/root/luks-hdr-sda3 /dev/disk/by-uuid/550a* sda3_crypt

The following commands work from the initramfs:

 - luksOpen /dev/sda2 sda2_crypt

 - luksOpen /dev/disk/by-uuid/003b* sda2_crypt

 - luksOpen --header=/root/luks-hdr-sda2 /dev/sda2 sda2_crypt

(although, incidentally, to make the third command work I also had to
add 'loop' to /etc/initramfs-tools/modules - for some reason
cryptsetup-in-initramfs uses a loopback device to read the header
file, although cryptsetup-in-Debian doesn't.  Of course, I also had to
add a hook to copy the header files into the initramfs - see the TODO
in /usr/share/initramfs-tools/hooks/cryptroot.)

The following command, however, does *not* work from the initramfs:

 - luksOpen --header=/root/luks-hdr-sda2 /dev/disk/by-uuid/003b* sda2_crypt


The debug output is as follows:

=== broken cryptsetup log ===
Enter passphrase for /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e: 
Requested offset is beyond real size of device 
/dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e.
Command failed with code 22: Requested offset is beyond real size of device 
/dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e.
# cryptsetup 1.6.6 processing "cryptsetup -T 1 --debug --allow-discards 
--header=/root/luks-hdr-sda2 open --type luks 
/dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e sda2_crypt"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device /root/luks-hdr-sda2 context.
# Trying to open and read device /root/luks-hdr-sda2.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device /root/luks-hdr-sda2.
# Crypto backend (gcrypt 1.6.3) initialized.
# Detected kernel Linux 3.16.0-4-amd64 x86_64.
# Reading LUKS header of size 1024 from device /root/luks-hdr-sda2
# Trying to open device /root/luks-hdr-sda2 without direct-io.
# Key length 64, device size 4040 sectors, header size 4036 sectors.
# Setting ciphertext data device to 
/dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e.
# Trying to open and read device 
/dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e.
# Timeout set to 0 miliseconds.
# Password retry count set to 1.
# Password verification disabled.
# Iteration time set to 1000 miliseconds.
# Activating volume sda2_crypt [keyslot -1] using [none] passphrase.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-crypt version 1.13.0, dm-ioctl version 4.27.0.
# Device-mapper backend running with UDEV support enabled.
# dm status sda2_crypt  OF   [16384] (*1)
# Interactive passphrase entry requested.
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Userspace crypto wrapper cannot use aes-xts-plain64 (-95).
# Using dmcrypt to access keyslot area.
# Allocating a free loop device.
# Trying to open and read device /dev/loop0.
# Calculated device size is 504 sectors (RW), offset 8.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-155
# Udev cookie 0xd4dcfd7 (semid 65536) created
# Udev cookie 0xd4dcfd7 (semid 65536) incremented to 1
# Udev cookie 0xd4dcfd7 (semid 65536) incremented to 2
# Udev cookie 0xd4dcfd7 (semid 65536) assigned to CREATE task(0) with flags 
DISABLE_SUBSYSTEM_RULES DISABLE_DISK_RULES DISABLE_OTHER_RULES (0xe)
# dm create temporary-cryptsetup-155 CRYPT-TEMP-temporary-cryptsetup-155 OF   
[16384] (*1)
# dm reload temporary-cryptsetup-155  OFRW[16384] (*1)
# dm resume temporary-cryptsetup-155  OFRW[16384] (*1)
# temporary-cryptsetup-155: Stacking NODE_ADD (254,0) 0:6 0660 [verify_udev]
# temporary-cryptsetup-155: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4dcfd7 (semid 65536) decremented to 1
# Udev cookie 0xd4dcfd7 (semid 65536) waiting for zero
# Udev cookie 0xd4dcfd7 (semid 65536) destroyed
# temporary-cryptsetup-155: Processing NODE_ADD (254,0) 0:6 0660 [verify_udev]
# 

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Benjamin Moody]

This bug was never fixed, as far as I can tell.  In version
2.88dsf-25, the file '/etc/default/rcS' (which is part of initscripts)
was made into a conffile.  However, '/etc/init.d/rcS' (which is part
of sysv-rc) never was.

The points raised in the original bug report remain valid today.
/etc/init.d/rcS is useful as a way to customize the early boot
sequence - for example, I have been using it to set the global CPU
affinity.  (Which I could have done by editing /etc/default/rcS
instead, but that's less obvious and arguably less flexible.)

Since /etc/init.d/rcS is human-readable and located in /etc, it is
reasonable for an administrator to expect that they can edit it and
have their changes preserved when upgrading the package.  Moreover,
the script is trivial - there's no reason for the file even to exist
if administrators aren't meant to be able to customize it.

Bug#803221: mesa-common-dev: incompatibility (missing typedefs) between gl.h and glext.h

[Benjamin Moody]

Package: mesa-common-dev
Version: 10.3.2-1+deb8u1
Severity: normal

Dear Maintainer,

A number of typedefs that were defined in previous versions of Mesa
are now missing, if  is included before .  The
lack of these definitions breaks existing code.

It seems the current version of glext.h and the current version of
gl.h have a disagreement regarding what types are "supposed" to be
defined for a given version of the API.

Specifically, in version 8.0.5-4+deb7u2, the following 37 types were
defined in the '#ifndef GL_VERSION_1_3_DEPRECATED' section of glext.h:

  PFNGLCLIENTACTIVETEXTUREPROC
  PFNGLMULTITEXCOORD1DPROC
  PFNGLMULTITEXCOORD1DVPROC
  PFNGLMULTITEXCOORD1FPROC
  PFNGLMULTITEXCOORD1FVPROC
  PFNGLMULTITEXCOORD1IPROC
  PFNGLMULTITEXCOORD1IVPROC
  PFNGLMULTITEXCOORD1SPROC
  PFNGLMULTITEXCOORD1SVPROC
  PFNGLMULTITEXCOORD2DPROC
  PFNGLMULTITEXCOORD2DVPROC
  PFNGLMULTITEXCOORD2FPROC
  PFNGLMULTITEXCOORD2FVPROC
  PFNGLMULTITEXCOORD2IPROC
  PFNGLMULTITEXCOORD2IVPROC
  PFNGLMULTITEXCOORD2SPROC
  PFNGLMULTITEXCOORD2SVPROC
  PFNGLMULTITEXCOORD3DPROC
  PFNGLMULTITEXCOORD3DVPROC
  PFNGLMULTITEXCOORD3FPROC
  PFNGLMULTITEXCOORD3FVPROC
  PFNGLMULTITEXCOORD3IPROC
  PFNGLMULTITEXCOORD3IVPROC
  PFNGLMULTITEXCOORD3SPROC
  PFNGLMULTITEXCOORD3SVPROC
  PFNGLMULTITEXCOORD4DPROC
  PFNGLMULTITEXCOORD4DVPROC
  PFNGLMULTITEXCOORD4FPROC
  PFNGLMULTITEXCOORD4FVPROC
  PFNGLMULTITEXCOORD4IPROC
  PFNGLMULTITEXCOORD4IVPROC
  PFNGLMULTITEXCOORD4SPROC
  PFNGLMULTITEXCOORD4SVPROC
  PFNGLLOADTRANSPOSEMATRIXFPROC
  PFNGLLOADTRANSPOSEMATRIXDPROC
  PFNGLMULTTRANSPOSEMATRIXFPROC
  PFNGLMULTTRANSPOSEMATRIXDPROC

In version 10.3.2-1+deb8u1, these types have been moved to the
'GL_VERSION_1_3' section of glext.h, but are not defined in gl.h.
Thus (since gl.h defines GL_VERSION_1_3) these types cannot be used.

Likewise, the following 32 types were previously part of the
'GL_VERSION_1_2_DEPRECATED' section in glext.h:

  PFNGLCOLORTABLEPROC
  PFNGLCOLORTABLEPARAMETERFVPROC
  PFNGLCOLORTABLEPARAMETERIVPROC
  PFNGLCOPYCOLORTABLEPROC
  PFNGLGETCOLORTABLEPROC
  PFNGLGETCOLORTABLEPARAMETERFVPROC
  PFNGLGETCOLORTABLEPARAMETERIVPROC
  PFNGLCOLORSUBTABLEPROC
  PFNGLCOPYCOLORSUBTABLEPROC
  PFNGLCONVOLUTIONFILTER1DPROC
  PFNGLCONVOLUTIONFILTER2DPROC
  PFNGLCONVOLUTIONPARAMETERFPROC
  PFNGLCONVOLUTIONPARAMETERFVPROC
  PFNGLCONVOLUTIONPARAMETERIPROC
  PFNGLCONVOLUTIONPARAMETERIVPROC
  PFNGLCOPYCONVOLUTIONFILTER1DPROC
  PFNGLCOPYCONVOLUTIONFILTER2DPROC
  PFNGLGETCONVOLUTIONFILTERPROC
  PFNGLGETCONVOLUTIONPARAMETERFVPROC
  PFNGLGETCONVOLUTIONPARAMETERIVPROC
  PFNGLGETSEPARABLEFILTERPROC
  PFNGLSEPARABLEFILTER2DPROC
  PFNGLGETHISTOGRAMPROC
  PFNGLGETHISTOGRAMPARAMETERFVPROC
  PFNGLGETHISTOGRAMPARAMETERIVPROC
  PFNGLGETMINMAXPROC
  PFNGLGETMINMAXPARAMETERFVPROC
  PFNGLGETMINMAXPARAMETERIVPROC
  PFNGLHISTOGRAMPROC
  PFNGLMINMAXPROC
  PFNGLRESETHISTOGRAMPROC
  PFNGLRESETMINMAXPROC

These types are now defined under 'GL_ARB_imaging' in glext.h, and are
not defined in gl.h.

The oldest version of Mesa that I have lying around is 6.5.2; in that
version, these typedefs appear in both gl.h and glext.h, and there are
no "deprecated" sections.  I guess that at some point, the deprecated
sections were added to glext.h, and in response, the typedefs - but
not the corresponding prototypes or macros - were removed from gl.h to
avoid redefining them.  (Whereas the smart thing to do would have been
to leave the typedefs alone, and #define GL_VERSION_1_2_DEPRECATED and
GL_VERSION_1_3_DEPRECATED in gl.h.)  Now that the deprecated sections
have been removed, it's broken again.

Bug#794822: webalizer: Man page refers to wrong path ('/etc/webalizer.conf')

[Benjamin Moody]

Package: webalizer
Version: 2.23.05-1
Severity: normal

Dear Maintainer,

From the webalizer manpage:

   o   A default configuration file is  scanned  for.   A  file  named
   webalizer.conf is searched for in the current directory, and if
   found, it's configuration data is parsed.  If the file  is  not
   present in the current directory,  the file /etc/webalizer.conf
   is searched for and, if found, is used instead.

This is wrong; the Debian version has apparently been modified to use
/etc/webalizer/webalizer.conf instead.

(it's is also incorrect, by the way.)

Similarly:

   webalizer.conf  Default configuration file.  Is searched for in the
   current directory and if not found,  in  the  /etc/
   directory.

Although this change is mentioned in README.Debian, the way it is
written suggests that only the '/etc/cron.daily/webalizer' script
deals with the /etc/webalizer subdirectory.  In any case, it is a bug
for the program not to do what the manpage says it does.

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

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

Versions of packages webalizer depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38+deb7u8
ii  libdb5.1   5.1.29-5
ii  libgd2-xpm 2.0.36~rc1~dfsg-6.1+deb7u1
ii  libgeoip1  1.4.8+dfsg-3
ii  libpng12-0 1.2.49-1
ii  zlib1g 1:1.2.7.dfsg-13

webalizer recommends no packages.

Versions of packages webalizer suggests:
ii  apache2-mpm-event [httpd]  2.2.22-13+deb7u5

-- debconf information excluded


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

Bug#793507: linux-image-3.2.0-4-amd64: Repeated BUG: soft lockup followed by system freeze

[Benjamin Moody]

Package: src:linux
Version: 3.2.68-1+deb7u2
Severity: important

Dear Maintainer,

The kernel reported a series of messages of the form BUG: soft lockup:

$ grep BUG /var/log/syslog.1
Jul 23 01:33:00 physionet2 kernel: [08.348031] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:33:28 physionet2 kernel: [36.348024] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:34:08 physionet2 kernel: [76.348025] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:34:36 physionet2 kernel: [555604.348024] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:35:04 physionet2 kernel: [555632.348024] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:35:32 physionet2 kernel: [555660.348025] BUG: soft lockup - CPU#3 
stuck for 23s! [apache2:7555]
...
Jul 23 03:10:12 physionet2 kernel: [561340.348023] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 03:10:12 physionet2 kernel: [561340.532039] BUG: soft lockup - CPU#5 
stuck for 23s! [ATM:30084]
Jul 23 03:10:13 physionet2 kernel: [561340.992064] BUG: soft lockup - CPU#10 
stuck for 22s! [challenge-d:6735]
Jul 23 03:10:13 physionet2 kernel: [561341.084076] BUG: soft lockup - CPU#11 
stuck for 22s! [apcupsd:2873]
Jul 23 03:10:13 physionet2 kernel: [561341.268087] BUG: soft lockup - CPU#13 
stuck for 22s! [ATM:20277]
Jul 23 03:10:40 physionet2 kernel: [561368.072017] BUG: soft lockup - CPU#0 
stuck for 22s! [kswapd0:93]
$ grep BUG /var/log/syslog.1 | wc -l
298

(Full contents of one of these messages shown below.)

As you can see, this happened many times over a period of an hour and
a half.  During this time, the system was still working on some level
(the apache log shows a steady stream of requests), but I have no idea
if anything unusual was going on.  At 03:01:06, the apache log stops.
At 03:10:40, the system log abruptly cuts off in the middle of an
error message.

When I came to look at the machine the next day, it was *mostly*
frozen - neither apache, nor ssh, nor any other network services were
responding; however, it still responded to pings, and nmap still
reported various ports as open.  The console was blank and did not
respond to CapsLock, NumLock, nor Ctrl+Alt+Delete.

I have no idea how to debug this.  Obviously a web search turns up
huge numbers of results for BUG: soft lockup (including other Debian
bugs), but I have no idea if any of them are relevant to my case, nor
have I found any information about how to narrow down the problem.
Please tell me if there is anything I can do to make it possible to
figure out what is going on if this happens in the future.

The first error message:
-
Jul 23 01:33:00 physionet2 kernel: [08.348031] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:33:00 physionet2 kernel: [08.348145] Modules linked in: 
ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables 
ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
iptable_filter ip_tables x_tables nfsd nfs nfs_acl auth_rpcgss fscache lockd 
sunrpc xfs loop cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod 
radeon snd_pcm ttm drm_kms_helper drm snd_page_alloc power_supply snd_timer 
amd64_edac_mod nv_tco snd k10temp i2c_nforce2 i2c_algo_bit edac_mce_amd shpchp 
soundcore edac_core evdev i2c_core mperf pcspkr psmouse serio_raw processor 
thermal_sys button ext4 crc16 jbd2 mbcache sr_mod cdrom sg usbhid mptsas hid 
scsi_transport_sas mptscsih sd_mod crc_t10dif ata_generic e1000e pata_amd 
mptbase e1000 3w_9xxx ohci_hcd sata_nv libata ehci_hcd usbcore scsi_mod 
usb_common [last unloaded: scsi_wait_scan]
Jul 23 01:33:00 physionet2 kernel: [08.348226] CPU 3 
Jul 23 01:33:00 physionet2 kernel: [08.348228] Modules linked in: 
ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables 
ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
iptable_filter ip_tables x_tables nfsd nfs nfs_acl auth_rpcgss fscache lockd 
sunrpc xfs loop cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod 
radeon snd_pcm ttm drm_kms_helper drm snd_page_alloc power_supply snd_timer 
amd64_edac_mod nv_tco snd k10temp i2c_nforce2 i2c_algo_bit edac_mce_amd shpchp 
soundcore edac_core evdev i2c_core mperf pcspkr psmouse serio_raw processor 
thermal_sys button ext4 crc16 jbd2 mbcache sr_mod cdrom sg usbhid mptsas hid 
scsi_transport_sas mptscsih sd_mod crc_t10dif ata_generic e1000e pata_amd 
mptbase e1000 3w_9xxx ohci_hcd sata_nv libata ehci_hcd usbcore scsi_mod 
usb_common [last unloaded: scsi_wait_scan]
Jul 23 01:33:00 physionet2 kernel: [08.348274] 
Jul 23 01:33:00 physionet2 kernel: [08.348278] Pid: 7555, comm: apache2 Not 
tainted 3.2.0-4-amd64 #1 Debian 3.2.68-1+deb7u2 Supermicro H8QM3/H8QM3
Jul 23 01:33:00 physionet2 kernel: [08.348284] RIP: 
0010:[811b671a]  [811b671a] __bitmap_empty+0xa/0x52
Jul 23 01:33:00 physionet2 kernel: [08.348296] RSP: 

Bug#780398: Custom (EC)DHE parameters and Apache 2.2

[Benjamin Moody]

I'd also like to see this issue fixed.  The relevant upstream changes
can be found at https://svn.apache.org/r1527295.

Changing the defaults has the potential to break old buggy clients,
such as those using Java 6.  So I would suggest that the Debian
package continue to use the old default behavior (with a maximum of
1024 bits for DH), but backport the option to override this by
specifying the parameters in the certificate file.

(Which, to be honest, seems more than a little bit kludgy to me, but
that is the approach upstream Apache is taking.)

I don't know much of anything about Apache internals (or about
OpenSSL, for that matter), but these changes look straightforward
enough, so here is a patch that ought to do the job.

I'm not sure how to check whether this patch is really working.
'openssl s_client' is my usual tool for testing such things, and it
doesn't seem to have the option of displaying the parameters used for
key exchange.  However, I can see that if I specify a 2048-bit DH
modulus in the certificate file, and use a DHE ciphersuite, the
ServerKeyExchange and ClientKeyExchange packets are correspondingly
larger.  Likewise if I specify a larger curve and an ECDHE suite.

Benjamin
Description: Allow custom DH and ECDH parameters.
 The parameters used for DH and ECDH are hard-coded by default, and
 the 1024-bit modulus used by default for DH may be too weak to
 provide effective forward secrecy for years to come.  Following the
 behavior of Apache 2.4.7, allow the administrator to specify custom
 parameters by including them in the SSLCertificateFile.
Origin: backport, subset of https://svn.apache.org/r1527295
Bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=49559
Bug-Debian: http://bugs.debian.org/780398

--- apache2-2.2.22.orig/modules/ssl/ssl_engine_init.c
+++ apache2-2.2.22/modules/ssl/ssl_engine_init.c
@@ -1040,10 +1040,14 @@ static void ssl_init_server_certs(server
 const char *rsa_id, *dsa_id;
 #ifndef OPENSSL_NO_EC
 const char *ecc_id;
+EC_GROUP *ecparams;
+int nid;
+EC_KEY *eckey;
 #endif
 const char *vhost_id = mctx-sc-vhost_id;
 int i;
 int have_rsa, have_dsa;
+DH *dhparams;
 #ifndef OPENSSL_NO_EC
 int have_ecc;
 #endif
@@ -1098,6 +1102,33 @@ static void ssl_init_server_certs(server
 #endif
 ssl_die();
 }
+
+/*
+ * Try to read DH parameters from the (first) SSLCertificateFile
+ */
+if ((mctx-pks-cert_files[0] != NULL) 
+(dhparams = ssl_dh_GetParamFromFile(mctx-pks-cert_files[0]))) {
+SSL_CTX_set_tmp_dh(mctx-ssl_ctx, dhparams);
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ Custom DH parameters (%d bits) for %s loaded from %s,
+ BN_num_bits(dhparams-p), vhost_id,
+ mctx-pks-cert_files[0]);
+}
+
+#ifndef OPENSSL_NO_EC
+/*
+ * Similarly, try to read the ECDH curve name from SSLCertificateFile...
+ */
+if ((mctx-pks-cert_files[0] != NULL) 
+(ecparams = ssl_ec_GetParamFromFile(mctx-pks-cert_files[0])) 
+(nid = EC_GROUP_get_curve_name(ecparams)) 
+(eckey = EC_KEY_new_by_curve_name(nid))) {
+SSL_CTX_set_tmp_ecdh(mctx-ssl_ctx, eckey);
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ ECDH curve %s for %s specified in %s,
+ OBJ_nid2sn(nid), vhost_id, mctx-pks-cert_files[0]);
+}
+#endif
 }
 
 static void ssl_init_proxy_certs(server_rec *s,
--- apache2-2.2.22.orig/modules/ssl/ssl_private.h
+++ apache2-2.2.22/modules/ssl/ssl_private.h
@@ -705,6 +705,9 @@ void ssl_pphrase_Handle(server_r
 /**  Diffie-Hellman Parameter Support  */
 DH   *ssl_dh_GetTmpParam(int);
 DH   *ssl_dh_GetParamFromFile(char *);
+#ifndef OPENSSL_NO_EC
+EC_GROUP *ssl_ec_GetParamFromFile(const char *);
+#endif
 
 unsigned char *ssl_asn1_table_set(apr_hash_t *table,
   const char *key,
--- apache2-2.2.22.orig/modules/ssl/ssl_util_ssl.c
+++ apache2-2.2.22/modules/ssl/ssl_util_ssl.c
@@ -451,6 +451,26 @@ BOOL SSL_X509_INFO_load_path(apr_pool_t
 
 /*  _
 **
+**  Custom (EC)DH parameter support
+**  _
+*/
+
+#ifndef OPENSSL_NO_EC
+EC_GROUP *ssl_ec_GetParamFromFile(const char *file)
+{
+EC_GROUP *group = NULL;
+BIO *bio;
+
+if ((bio = BIO_new_file(file, r)) == NULL)
+return NULL;
+group = PEM_read_bio_ECPKParameters(bio, NULL, NULL, NULL);
+BIO_free(bio);
+return (group);
+}
+#endif
+
+/*  _
+**
 **  Extra Server Certificate Chain Support
 **  _
 */
--- apache2-2.2.22.orig/docs/manual/mod/mod_ssl.html.en
+++ apache2-2.2.22/docs/manual/mod/mod_ssl.html.en
@@ -388,12 +388,19 @@ SSLCertificateChainFile /usr/local/apach
 trtha 

Bug#780159: qemu-kvm: exit status is 0 if process is killed

[Benjamin Moody]

Package: qemu-kvm
Version: 1.1.2+dfsg-6+deb7u6
Severity: normal

Dear Maintainer,

As the subject line says, if a qemu process (kvm or qemu-system-*) is
interrupted by a signal (say, by pressing ^C), it still exits with a
status of 0.

Example:

  $ kvm
  ^Cqemu: terminating on signal 2
  $ echo $?
  0

This is extremely annoying when trying to write robust scripts that
invoke qemu - there is no way for the script to know whether the guest
system powered off successfully, or the process was interrupted for some
reason.

Benjamin


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

Bug#780159: qemu-kvm: exit status is 0 if process is killed

[Benjamin Moody]

On 3/9/15, Michael Tokarev m...@tls.msk.ru wrote:
 Indeed it does.  What exit code do you suggest to use in this case?

Really, anything nonzero would be fine; it's not as if qemu exit codes
have any particular significance currently.  I think 128+(signal
number) is somewhat standard.

 Note this has been this way since the Day One, qemu _always_ did that,
 for many years.  So lowering the severity.

Yeah, I know this bug has been around for a long time.  It's just that
only today did it annoy me sufficiently to be worth the effort of
filing a bug report.

Benjamin


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

Bug#742307: xserver-xorg-video-radeon: Radeon HD 6570 (Turks) - severe display corruption esp. after boot

[Benjamin Moody]

To follow up on this issue:

Another person who was having similar problems contacted me privately
(thank you!) and informed me that adding radeon.dpm=1 to the kernel
command line seems to fix the problem.

I've done so, and it now seems to be working perfectly with kernel
3.13.10-1~bpo70+1.

However:

 - the stable kernel is still broken, as it doesn't support the
radeon.dpm option (and I have no idea how hard it would be to
backport);

 - the backports kernel is broken, too, since dpm is not enabled by
default for this card.

Benjamin


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

Bug#745205: live-build: Recompressing initramfs breaks live installer

[Benjamin Moody]

Package: live-build
Version: 3.0.5-1
Severity: normal

Dear Maintainer,

Setting LB_INITRAMFS_COMPRESSION to something other than 'gzip' causes
live-build to recompress the initramfs.  However, when this option is
used in combination with LB_DEBIAN_INSTALLER=live, the result is that
the installer will not rebuild the initramfs for the installed system.
This causes problems if you choose to use encryption when installing,
and possibly also if you choose to use LVM.

I think the reason for this problem is that update-initramfs checks to
see if the currently-installed initrd has a matching sha1sum in
/var/lib/initramfs-tools/.  Since live-build recompresses the initrd,
the sha1sum doesn't match, so update-initramfs refuses to touch it.

If I'm right about this, then it should be a simple matter for the
'chroot_hacks' script to update the sha1sum file after recompressing
the image.

Benjamin


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

Bug#742307: xserver-xorg-video-radeon: Radeon HD 6570 (Turks) - severe display corruption esp. after boot

[Benjamin Moody]

 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)

 Is this still an issue with a newer kernel?  IIRC, this issue was
 fixed a while ago.

Tested with kernel 3.13-0.bpo.1-amd64.  The same problem occurs except
that Ctrl-Alt-Backspace doesn't work either.

I also noticed that the newer kernel wanted an additional firmware
file ('radeon/TURKS_smc.bin') so I upgraded firmware-linux-nonfree to
0.41~bpo70+1.  That also made no difference.

Benjamin


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

Bug#739729: live-build: Live installer CD includes redundant .deb files

[Benjamin Moody]

Package: live-build
Version: 3.0.5-1
Severity: normal
Tags: patch

Dear Maintainer,

When building a CD with the LB_DEBIAN_INSTALLER=live option,
live-build will include a significant number of .deb packages that are
(as far as I can tell) not actually needed for installation.

The 'binary_debian-installer' script contains code designed to avoid
including the .deb files for packages that are already installed in
the live system.  However, the 'rm' command doesn't work due to
improper quoting.

I further noticed that the 'grep' command that is meant to force
certain packages (e.g. grub) to be included as .debs was also
not working as intended.

I believe the below patch fixes these issues:

--- scripts/build/binary_debian-installer.orig  2013-04-30
02:28:19.0 -0400
+++ scripts/build/binary_debian-installer   2014-02-21 16:20:37.0 
-0500
@@ -528,11 +528,11 @@

# Drop the packages already installed that d-i doesn't 
explicitely need
_REMAINING_PACKAGES=$(echo ${DI_FIRMWARE_PACKAGES}
${DI_REQ_PACKAGES} | sed -e 's# #|#g')
-   _REMAINING_PACKAGES=$(sed -n -e 's|Package: ||p'
chroot/var/lib/dpkg/status.tmp | grep -E -v
\^${_REMAINING_PACKAGES}$\)
+   _REMAINING_PACKAGES=$(sed -n -e 's|Package: ||p'
chroot/var/lib/dpkg/status.tmp | grep -E -v
^(${_REMAINING_PACKAGES})\$)

for _PACKAGE in ${_REMAINING_PACKAGES}
do
-   rm -f chroot/binary.deb/archives/${_PACKAGE}_*.deb
+   rm -f chroot/binary.deb/archives/${_PACKAGE}_*.deb
done
else
# Download .debs of the required packages

-- Package-specific info:

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

Kernel: Linux 2.6.32-431.1.2.el6.x86_64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages live-build depends on:
ii  debootstrap  1.0.48+deb7u1

Versions of packages live-build recommends:
ii  cpio2.11+dfsg-0.1
ii  gnu-fdisk   1.2.4-3.1
ii  live-boot-doc   3.0.1-1
ii  live-config-doc 3.0.23-1
ii  live-manual-html [live-manual]  1:3.0.2-1

Versions of packages live-build suggests:
pn  debian-keyring  none
pn  dosfstools  none
pn  git none
ii  gpgv1.4.12-7+deb7u2
pn  loadlin none
pn  memtest86+ | memtest86  none
ii  mtools  4.0.17-1
pn  parted  none
ii  squashfs-tools  1:4.2-5
pn  sudo | fakeroot none
ii  syslinux2:4.05+dfsg-6+deb7u1
pn  uuid-runtimenone
pn  win32-loadernone
pn  xorriso none

-- 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#731998: Multi-arch support in libcurl dev packages

[Benjamin Moody]

 I have a seemingly working patch for curl-config that basically makes it use
 pkg-config internally (I had to patch libcurl.pc as well for the --configure
 thing, but it's not that much of a problem). This means that the -dev packages
 now depend on pkg-config as well, but pkg-config gets installed already anyway
 because of libidn11-dev.

Depending on pkg-config is, I think, a step backwards.  If you have
pkg-config:amd64 installed, then (in the absence of environment
variables) pkg-config will only search for amd64 libraries.  So that
will only work if you have libcurl4-*-dev:amd64 (possibly in addition
to other architectures.)

So (ignoring for the moment the fact that pkg-config currently isn't
multi-arch at all) depending on any pkg-config is wrong (unless
libcurl.pc is moved to /usr/share/pkgconfig, which is also arguably
wrong) and depending on same-arch pkg-config prevents
co-installation.

In contrast, if curl-config is a simple arch-independent script, it
will Just Work for any architecture.  As for pkg-config, you can set
up an 'i386-linux-gnu-pkg-config' wrapper, which most configure
scripts can be made to honor.

 Incidentally, pkg-config is not multi-arch ready yet (#726598) (and possibly
 many of the -dev dependencies of libcurl -dev packages), so this whole 
 exercise
 wouldn't lead to any actual benefit until those are fixed as well.

So I have to wonder how many of those are actually needed for
compiling and linking with libcurl, and whether they could be
downgraded to recommendations.

In any case, I briefly looked through all of the -dev packages that
libcurl4-*-dev depends on.

The following packages are already marked as Multi-Arch: same.

  libldap2-dev
  zlib1g-dev

The following packages already appear to be multi-arch compatible.
(All except krb5-multidev contain .pc files, but those .pc files do
not depend on the architecture except for $libdir.  Since pkg-config
automatically removes -L/usr/lib/triplet, that means the --cflags
and --libs are arch-independent.)

  krb5-multidev
  comerr-dev
  librtmp-dev
  libssh2-1-dev
  libssl-dev
  libidn11-dev (ignoring the dependency on pkg-config)

The following packages are already multi-arch compatible except that
they install scripts similar to curl-config in /usr/bin.  These
scripts could be adapted without much difficulty to be
arch-independent.

  libkrb5-dev
  libnss3-dev
  libnspr4-dev

libgnutls-dev is already multi-arch compatible except for some
weirdness in gnutls.pc (-R/usr/lib/triplet -lgpg-error, which is
probably a bug.)

libgcrypt11-dev and libgpg-error-dev both include binaries in
/usr/bin, which I guess would need to be moved to a separate package.
Both of these packages also include -config scripts.

libtasn1-3-dev is already multi-arch compatible, except that some
anchor names in the generated HTML documentation appear to be
dependent on the build system (a gtk-doc bug?)

libp11-kit-dev has some arch-specific stuff in its .pc file
(p11_module_path and proxy_module).

Benjamin


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

Bug#731998: Multi-arch support in libcurl dev packages

[Benjamin Moody]

I'd really like to see the underlying issue here fixed.  (Specifically
I'd like to have i386 and amd64 -dev packages installed, and usable,
at the same time.)  I'll be happy to provide patches if that will
help.

So from what I can tell there are 4 problems:

1. curl-config --libs: This is pretty trivial to fix; if libcurl is
installed in /usr/lib/x86_64-linux-gnu/, there's no need to include
that path in the linker flags.  Just change curl-config.in to
unconditionally set CURLLIBDIR=.

(As a side issue, it'd also be good if 'pkg-config --libs libcurl'
behaved the same way, i.e. omit -L${libdir} from libcurl.pc.)

2. curl-config --static-libs: Is there a real need to support this
option?  Specifically, is there a situation where it's useful to link
statically with libcurl while linking dynamically with the other
libraries (e.g., -lgssapi_krb5, which in Debian is only available as a
shared library)?  I guess the only way to preserve the exact semantics
of this command would be to rename libcurl.a to (e.g.)
libcurl-static.a, and replace @libdir@/libcurl.@libext@ with
-lcurl-static.  Alternatively it could be changed to something like
-Wl,-Bstatic -lcurl -Wl,-Bdynamic but that might break some weird
configurations.

3. Barely worth mentioning, curl-config --configure: I seriously doubt
anyone is using this option for anything important.  But one way, I
suppose, to more-or-less preserve the semantics would be to replace
the architecture triplets with the literal string $(dpkg-architecture
-qDEB_HOST_MULTIARCH).

4. curlbuild.h: The simplest way to fix this would be to move all of
/usr/include/curl/ to /usr/include/triplet/curl/.  (Is that include
path supported by all C compilers in Debian?  It's a little unclear to
me; some of the multi-arch documents mention that path, while others
imply that there isn't any standard way to do arch-dependent header
files.)  Alternatively, just curlbuild.h could be moved, and curl.h
could be modified to #include curl/curlbuild.h instead of #include
curlbuild.h.

Of course, curl-config --cflags, and pkg-config --cflags libcurl,
should continue to output nothing (the whole exercise is wasted if
curl-config --cflags outputs -I/usr/include/x86_64-linux-gnu.)

The other option would be to replace curlbuild.h with a version that
uses #ifdefs to include the appropriate curlbuild.h for the
architecture.  (This is what Fedora/RHEL have done in their
libcurl-devel packages.)  This could be quite complicated, given the
number of architectures Debian supports.

Benjamin Moody


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

Bug#678229: Copyright

[Benjamin Moody]

 The skins of tilem contain photographs of TI calculators (e.g. file
 ti86.skn includes a jpeg picture of a TI-86 calculator at offset 0x571).

 I assume TI has the copyright for the design of the calculators. Is there
 no copyright issue in using photographs of these products as skins for
 non
 TI software?

I don't know; obviously I'm not a lawyer.  If you have any evidence,
one way or the other, as to whether this is legally permissible,
please let us know.

Some things to consider:

- There are many calculator emulators out there, both for TI
calculators and for other brands, and virtually all of them have user
interfaces that mimic the design of the original calculator to some
extent.  Many are based on photographs, others on line drawings or
computer-generated images with varying levels of realism.

- The actual layout of the keyboard (positions of the calculator keys
and the labels on them) would, I think, be considered functional
rather than creative and therefore not copyrightable.
(Specifically, it could be argued that reproducing the physical
keyboard layout is essential to ensure compatibility with third-party
software.)

- TI is well aware of the existence of third-party emulators (indeed,
TilEm itself was mentioned at one point on the website for the
official TI-83 Plus SDK.)  TI has agressively enforced their
copyrights against people distributing copyrighted ROM images.  I have
never once heard of a complaint concerning the use of a photo of a
calculator, either for use in an emulator or for any other purpose.

- Debian already includes TiEmu, which, like TilEm, includes skins
based on photos of the calculator models it supports.

Benjamin


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

Bug#581622: [qa.debian.org] Please provide a code.google.com redirector

[Benjamin Moody]

I've reported this issue to Google:
http://code.google.com/p/support/issues/detail?id=4042



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

Bug#522241: sox: Don't play correctly .mp3 files

[Benjamin Moody]

Package: sox
Version: 14.2.0-1
Severity: normal

This issue results from a misuse of the libmagic API, which happened
to work anyway in older versions of libmagic.  The patch below will
work with both the current libmagic (5.00-1) and the previous version
(4.26-1).  I haven't looked at older versions.

In any case, relying on libmagic to give the exact MIME type we're
expecting seems like a poor idea.  Shouldn't sox instead use
libmagic's result as a *hint*, and, if the MIME type isn't recognized,
fall back to other means of determining the type?

--- sox-14.2.0/src/formats.c2008-11-01 13:08:04.0 -0400
+++ ../sox-14.2.0/src/formats.c 2009-04-05 15:09:18.0 -0400
@@ -421,7 +421,7 @@
   if (!filetype) {
 static magic_t magic;
 if (!magic) {
-  magic = magic_open(MAGIC_MIME | MAGIC_SYMLINK);
+  magic = magic_open(MAGIC_MIME_TYPE | MAGIC_SYMLINK);
   if (magic)
 magic_load(magic, NULL);
 }



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

Bug#522548: sox: Please add a README.source to the source package

[Benjamin Moody]

Package: sox
Version: 14.2.0-1+b1
Severity: minor

The 'sox' source package includes the original source code as a
tarball within a tarball, making it difficult to modify.  Furthermore,
it is not at all apparent how one would go about building a modified
version of the package (running dpkg-buildpackage overwrites any
changes that have been made to the unpacked source.)

Per Debian Policy section 4.14, packages that are constructed this way
should contain a file, debian/README.source, explaining how everything
works.  It is also recommended that such packages implement a 'patch'
target in debian/rules (sox does not have this either.)

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

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

Versions of packages sox depends on:
ii  libc6  2.9-4 GNU C Library: Shared libraries
ii  libltdl3   1.5.26-4  A system independent dlopen wrappe
ii  libmagic1  5.00-1File type determination library us
ii  libpng12-0 1.2.35-1  PNG library - runtime
ii  libsamplerate0 0.1.7-2   audio rate conversion library
ii  libsox-fmt-alsa14.2.0-1+b1   SoX alsa format I/O library
ii  libsox-fmt-ao  14.2.0-1+b1   SoX Libao format I/O library
ii  libsox-fmt-base14.2.0-1+b1   Minimal set of SoX format librarie
ii  libsox-fmt-oss 14.2.0-1+b1   SoX OSS format I/O library
ii  libsox114.2.0-1+b1   SoX library of audio effects and p
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

sox recommends no packages.

Versions of packages sox suggests:
ii  libsox-fmt-all   14.2.0-1+b1 All SoX format libraries

-- 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#498001: xscreensaver completely fails to work after resizing display with xrandr

[Benjamin Moody]

Thanks!  I didn't realize the Debian package was so far behind.
Indeed, whatever the problem was, it doesn't happen with 5.07.
Although xscreensaver now gives the following warning:

xscreensaver: 22:46:09: WARNING: RANDR and Xinerama report different
xscreensaver: 22:46:09:  screen layouts!  Believing RANDR.

(I'm not sure what that could mean, given that I only have one monitor
and it occurs even if I haven't ever changed the resolution.)

Anyway, I think this was an important enough issue to bring to folks'
attention -- I very much hope it can be fixed before the lenny
release.



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

Bug#498001: xscreensaver completely fails to work after resizing display with xrandr

[Benjamin Moody]

Package: xscreensaver
Version: 5.05-3
Severity: important

At certain times when the screen is resized, xscreensaver gets
confused, and subsequently fails to blank the screen.

Specifically, this happens when changing from 640x480 to 1280x1024.
For example, if I run

xrandr -s 640x480
xrandr -s 1280x1024
xscreensaver-command -activate

xscreensaver fades the screen out as expected, but after doing this,
rather than showing a screensaver or a blank screen, it simply goes
back to showing the existing windows.

Furthermore, if I lock the screen at this point with
'xscreensaver-command -lock', the screen is locked, but still no
screensaver is displayed.  In fact the password-entry dialog box
appears -- over my existing windows -- in the upper left corner of the
screen rather than in the center, as if xscreensaver believes the
screen is still 640x480.

The strange thing is that this only seems to happen after switching
from 640x480 to 1280x1024.  If I switch to 640x480 and activate the
screensaver, it works fine.  If I switch from 1280x1024 to 640x480,
then to 800x600, then back to 1280x1024, it works fine.  When
switching from 640x480 to 1280x1024, though, this problem occurs every
time.

Restarting xscreensaver, or switching to (say) 800x600 and back, fixes
the problem.

This is obviously a serious problem for any user who is relying on
xscreensaver for security, not to mention those who rely on it to
protect their CRTs.

If it makes any difference, I'm using a fairly new Radeon video card
(RV635) which still doesn't have great support from the free-software
drivers; this problem occurs with both the radeon and radeonhd
drivers.

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

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

Versions of packages xscreensaver depends on:
ii  libatk1.0-01.22.0-1  The ATK accessibility toolkit
ii  libc6  2.7-13GNU C Library: Shared libraries
ii  libcairo2  1.6.4-6   The Cairo 2D vector graphics libra
ii  libglade2-01:2.6.2-1 library to load .glade files at ru
ii  libglib2.0-0   2.16.4-2  The GLib library of C routines
ii  libgtk2.0-02.12.11-3 The GTK+ graphical user interface 
ii  libice62:1.0.4-1 X11 Inter-Client Exchange library
ii  libpam0g   1.0.1-4+b1Pluggable Authentication Modules l
ii  libpango1.0-0  1.20.5-1  Layout and rendering of internatio
ii  libsm6 2:1.0.3-2 X11 Session Management library
ii  libx11-6   2:1.1.4-2 X11 client-side library
ii  libxext6   2:1.0.4-1 X11 miscellaneous extension librar
ii  libxinerama1   2:1.0.3-2 X11 Xinerama extension library
ii  libxml22.6.32.dfsg-3 GNOME XML library
ii  libxmu62:1.0.4-1 X11 miscellaneous utility library
ii  libxpm41:3.5.7-1 X11 pixmap library
ii  libxrandr2 2:1.2.3-1 X11 RandR extension library
ii  libxrender11:0.9.4-2 X Rendering Extension client libra
ii  libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii  libxxf86misc1  1:1.0.1-3 X11 XFree86 miscellaneous extensio
ii  libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l
ii  xscreensaver-data  5.05-3data files to be shared among scre

Versions of packages xscreensaver recommends:
ii  libjpeg-progs  6b-14 Programs for manipulating JPEG fil
ii  perl [perl5]   5.10.0-13 Larry Wall's Practical Extraction 
ii  wamerican [wordlist]   6-2.3 American English dictionary words 
ii  xli1.17.0+20061110-2 command line tool for viewing imag

Versions of packages xscreensaver suggests:
ii  dillo [www-browser]0.8.6-3   Small and fast web browser
ii  elinks [www-browser]   0.11.4-2  advanced text-mode WWW browser
ii  epiphany-gecko [www-browse 2.22.3-1  Intuitive GNOME web browser - Geck
ii  fortune-mod [fortune]  1:1.99.1-3.1  provides fortune cookies on demand
ii  iceape-browser [www-browse 1.1.11-1  Iceape Navigator (Internet browser
ii  iceweasel [www-browser]3.0.1-1   lightweight web browser based on M
ii  links2 [www-browser]   2.1pre37-1.1  Web browser running in both graphi
ii  lynx-cur [www-browser] 2.8.7dev9-1.2 Text-mode WWW Browser with NLS sup
pn  qcam | streamernone(no description available)
ii  w3m [www-browser]  0.5.2-2+b1WWW browsable pager with excellent
pn  xdaliclock none(no description available)
pn  xfishtank  none(no description available)
ii  

Bug#495887: libgucharmap-dev should depend on libgconf2-dev

[Benjamin Moody]

Package: libgucharmap-dev
Version: 1:2.22.3-1
Severity: normal

Since libgucharmap uses libgconf, its .pc file states that it requires
gconf-2.0.  Thus, trying to compile a program with libgucharmap in the
normal way, e.g.

cc `pkg-config --cflags --libs gucharmap` foo.c

fails unless libgconf2-dev is also installed on the system.

As this makes libgucharmap-dev effectively unusable without
libgconf2-dev, I feel this merits a 'Depends'.

To be clear, this has nothing to do with build- or other dependencies
for the gucharmap program itself, it relates to compiling programs
that use libgucharmap.

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

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

Versions of packages libgucharmap-dev depends on:
ii  libgtk2.0-dev 2.12.11-3  Development files for the GTK+ lib
ii  libgucharmap6 1:2.22.3-1 Unicode browser widget library (sh

libgucharmap-dev recommends no packages.

libgucharmap-dev suggests no packages.

-- no debconf information



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