Bug#1082653: directvnc: gets stuck in a loop when remote connection dies
Package: directvnc
Version: 0.7.8-1
Severity: normal
My remote connection died hard, and rebooted. When it came back
up, I discovered my directvnc display was still stuck on the last
image prior to the connection dying. This display didn't time out
and die. strace revealed an endless non-throttled loop of:
[pid 2643] read(4, 0xd972c430, 8192) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 2643] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000},
NULL) = 0
[pid 2643] read(4, 0xd972c430, 8192) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 2643] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000},
NULL) = 0
[pid 2643] read(4, 0xd972c430, 8192) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 2643] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000},
NULL) = 0
[pid 2643] read(4, 0xd972c430, 8192) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 2643] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000},
NULL) = 0
[pid 2643] read(4, 0xd972c430, 8192) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 2643] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000},
NULL) = 0
[pid 2643] read(4, 0xd972c430, 8192) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 2643] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000},
NULL) = 0
lsof shows this:
: 44306,6; sudo lsof -p 2643
COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME
directvnc 2643 root cwdDIR 0,25 4096 2 /
(192.168.1.3:/piroot)
directvnc 2643 root rtdDIR 0,25 4096 2 /
(192.168.1.3:/piroot)
directvnc 2643 root txtREG 0,2552192 28553
/usr/bin/directvnc (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2526640 28498
/usr/lib/aarch64-linux-gnu/directfb-1.7-7/inputdrivers/libdirectfb_linux_input.so
(192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2514352 28495
/usr/lib/aarch64-linux-gnu/directfb-1.7-7/inputdrivers/libdirectfb_input_hub.so
(192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2551416 28517
/usr/lib/aarch64-linux-gnu/directfb-1.7-7/wm/libdirectfbwm_default.so
(192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2514352 28497
/usr/lib/aarch64-linux-gnu/directfb-1.7-7/inputdrivers/libdirectfb_keyboard.so
(192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2514376 28502
/usr/lib/aarch64-linux-gnu/directfb-1.7-7/inputdrivers/libdirectfb_ps2mouse.so
(192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2559912 28516
/usr/lib/aarch64-linux-gnu/directfb-1.7-7/systems/libdirectfb_fbdev.so
(192.168.1.3:/piroot)
directvnc 2643 root memCHR 29,0531 /dev/fb0
directvnc 2643 root memREG 0,25 591960 40994
/usr/lib/aarch64-linux-gnu/libm.so.6 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,25 133448 1915
/usr/lib/aarch64-linux-gnu/libgcc_s.so.1 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,25 2174296 1926
/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2567528 40993
/usr/lib/aarch64-linux-gnu/libdl.so.2 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2563536 28520
/usr/lib/aarch64-linux-gnu/libfusion-1.7.so.7.0.0 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,25 158184 28518
/usr/lib/aarch64-linux-gnu/libdirect-1.7.so.7.0.0 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,25 1651408 40991
/usr/lib/aarch64-linux-gnu/libc.so.6 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,25 133520 6848
/usr/lib/aarch64-linux-gnu/libz.so.1.2.13 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,25 395264 28542
/usr/lib/aarch64-linux-gnu/libjpeg.so.62.3.0 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,2567528 41002
/usr/lib/aarch64-linux-gnu/libpthread.so.0 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,25 1297056 28519
/usr/lib/aarch64-linux-gnu/libdirectfb-1.7.so.7.0.0 (192.168.1.3:/piroot)
directvnc 2643 root memREG 0,25 202912 40988
/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 (192.168.1.3:/piroot)
directvnc 2643 root0r CHR1,3 0t0 4 /dev/null
directvnc 2643 root1u unix 0x947241ed 0t0 19701 type=STREAM
(CONNECTED)
directvnc 2643 root2u unix 0x947241ed 0t0 19701 type=STREAM
(CONNECTED)
directvnc 2643 root3u unix 0x947241ed 0t0 19701 type=STREAM
(CONNECTED)
directvnc 2643 root4u IPv4 34005 0t0 TCP
pi.rather.puzzling.org:43508->met.rather.puzzling.org:5900 (ESTABLISHED)
directvnc 2643 root5u CHR
Bug#980555: closing 980555
reopen 980555 thanks Was closed with no explanation and no answer to my last question. -- Tim Connors
Bug#980555: closing 980555
On Sat, 10 Aug 2024, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > close 980555 > Bug #980555 [src:linux] Missing ec_sys module > Marked Bug as done I'm confused as to why this has been closed, seemingly without explanation (doesn't look to be fixed, and doesn't come with a fixed in version tag)? One person said the bug was no longer relevant for them and their hardware. Neither the original submitter nor other commenters on the bug have confirmed the bug is no longer relevant on their hardware. ec_sys.ko still does not exist in the latest debian kernel, but can be obtained when using other third party kernels, so there's no technical reason stopping it being compiled. -- Tim Connors
Bug#1070783: python3-gpumodules: fails to parse kernel version for +bpo debian backport kernels
Package: python3-gpumodules
Version: 3.8.0-1
Severity: normal
Tags: patch
> uname -a
Linux dirac 6.6.13+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.13-1~bpo12+1
(2024-02-15) x86_64 GNU/Linux
This seems to fix the problem and basic functionality appears to work:
--- /usr/lib/python3/dist-packages/GPUmodules/env.py.old2024-05-09
13:07:32.387667230 +1000
+++ /usr/lib/python3/dist-packages/GPUmodules/env.py2024-05-09
13:07:42.171546939 +1000
@@ -309,7 +309,7 @@
# Check Linux Kernel version
current_kversion_str = release()
-current_kversion = tuple([int(x) for x in re.sub('-.*', '',
current_kversion_str).split('.')])
+current_kversion = tuple([int(x) for x in re.sub('[-+].*', '',
current_kversion_str).split('.')])
LOGGER.debug('Using Linux Kernel: %s', current_kversion_str)
if current_kversion < __required_kversion__:
print('Using Linux Kernel {}, but {} requires > {}.{}.'.format(
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-gpumodules depends on:
ii lshw02.19.git.2021.06.19.996aaad9c7-2+b1
ii python3 3.11.2-1+b1
ii python3-matplotlib 3.6.3-1+b1
ii python3-pandas 1.5.3+dfsg-2
python3-gpumodules recommends no packages.
Versions of packages python3-gpumodules suggests:
ii ricks-amdgpu-utils 3.8.0-1
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/GPUmodules/env.py (from
python3-gpumodules package)
Bug#1069674: openssh-client: multiplexed connections use incorrect DISPLAY etc, but no TOKENS exist to modify the connection socket
Package: openssh-client Version: 1:9.2p1-2+deb12u2 Severity: normal With .ssh/config: ControlMaster auto ControlPath ~/.ssh/cm_master/%r@%h:%p ControlPersist yes Set up the mux master on host a to host c: > echo $DISPLAY :0 > ssh c xterm xterm fires up on host a. Kill that Now, if we arrange for DISPLAY to point to another display (I sshed to another host b, set DISPLAY=:0, verified xterm opened up on that host, then sshed back to my original host a), and try to fire up ssh again: > echo $DISPLAY localhost:11.0 > ssh c xterm xterm fires up on host a instead of host b, which was where $DISPLAY was pointing. OK, so the muxing protocol isn't smart enough to allow DISPLAY to be dynamically set (a bit like bug #931187, ssh not properly acting as if a new connection has been made and handing out /etc/motd properly). So let's work around it by setting ControlPath according to what DISPLAY is being asked for. Hmmmf, there are no appropriate TOKENS. Perhaps there should be a %D TOKEN value for $DISPLAY? Or since I'm sure there's other connection properties that shouldn't be shared between multiplexed connections, can the protocol be modified to allow DISPLAY and other values to be properly set per multiplexed connection? -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 openssh-client depends on: ii adduser 3.134 ii libc6 2.36-9+deb12u4 ii libedit2 3.1-20221030-2 ii libfido2-11.12.0-2+b1 ii libgssapi-krb5-2 1.20.1-2+deb12u1 ii libselinux1 3.4-1+b6 ii libssl3 3.0.11-1~deb12u2 ii passwd1:4.13+dfsg1-1+b1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages openssh-client recommends: ii xauth 1:1.1.2-1 Versions of packages openssh-client suggests: ii keychain 2.8.5-3 pn libpam-ssh pn monkeysphere ii ssh-askpass 1:1.2.4.1-16 -- Configuration Files: /etc/ssh/ssh_config changed [not included] -- no debconf information
Bug#1069660: directvnc: Allow password file to be supplied vs just commandline
Package: directvnc Version: 0.7.8-1 Severity: normal man 1 directvnc: -p, --password password string to be passed to the server for authentication. Use this with care! OK, so what's care? Well, the password is available for all system users and crackers to view with just `ps faux | grep directvnc`. But what if there was a way to supply the password through a file, like on all other vnc servers? Looking at the documentation, I can't see any such way to provide the password through a file. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 directvnc depends on: ii libc6 2.36-9+deb12u4 ii libdirectfb-1.7-7 1.7.7-11 pn libdirectfb-1.7-7t64 ii libjpeg62-turbo 1:2.1.5-2 ii zlib1g1:1.2.13.dfsg-1 Versions of packages directvnc recommends: ii x11proto-core-dev 2022.1-1 ii x11proto-dev [x11proto-core-dev] 2022.1-1 directvnc suggests no packages.
Bug#1066090: psmisc: killall --older-than doesn't work as documented in a container
Package: psmisc
Version: 23.6-1
Severity: normal
killall --older-than 30s restartx11vnc x11vnc vncserver x0tigervncserver
websockify
doesn't kill any processes inside my container, whereas it always used
to work on a VM and on hardware. Removing '--older-than 30s' kills
all such processes. I strongly suspect the culprit is how
/proc/$pid/stat is interpreted:
--older-than case:
3921851 openat(AT_FDCWD, "/proc/3918880", O_RDONLY|O_DIRECTORY) = 3
3921851 openat(3, "stat", O_RDONLY) = 4
3921851 fcntl(4, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
3921851 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=0, ...},
AT_EMPTY_PATH) = 0
3921851 read(4, "3918880 (x11vnc) S 3918875 39184"..., 1024) = 336
3921851 close(4)= 0
3921851 openat(AT_FDCWD, "/proc/uptime", O_RDONLY) = 4
3921851 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=23, ...},
AT_EMPTY_PATH) = 0
3921851 read(4, "82599.37 82599.37\n", 4096) = 18
3921851 close(4)= 0
3921851 close(3)= 0
no such flag:
3960244 openat(AT_FDCWD, "/proc/3918880", O_RDONLY|O_DIRECTORY) = 3
3960244 openat(3, "stat", O_RDONLY) = 4
3960244 fcntl(4, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
3960244 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=0, ...},
AT_EMPTY_PATH) = 0
3960244 read(4, "3918880 (x11vnc) S 1 3918464 366"..., 1024) = 332
3960244 close(4)= 0
3960244 pidfd_send_signal(3, SIGTERM, NULL, 0) = 0
3960244 close(3)= 0
I'm guessing it's looking at field 22 starttime in /proc/$pid/stat?
starttime is seconds since boot. Since the process exists in the
parent system as well, starttime will surely be seconds since host
boot? But /proc/uptime is seconds since container boot.
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 psmisc depends on:
ii libc6 2.36-9+deb12u4
ii libtinfo6 6.4-4
psmisc recommends no packages.
psmisc suggests no packages.
-- no debconf information
Bug#1014625: xterm: screen corruption of scrollback buffer
On Sat, 9 Jul 2022, Thomas Dickey wrote: > On Sat, Jul 09, 2022 at 02:39:41PM +1000, Tim Connors wrote: > > This has happened ever since I changed my hardware -- mostly updating > > my video card to a radeon RX570 -- necessitating new versions of some > > drivers and kernel. While I would happily accept that the video card > > might have some dodgy memory (note to self: find a GPU memory stress > > tester), this corruption has not affected any other program other than > > xterm's scrollback buffer, so I wonder if it's a bug instead. > > > > Screengrabs of the symptom: > > > > https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption.png > > https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption2.png > > > > radeon amdgpu drivers and firmware are the latest version allowed by > > otherwise being on debian stable - ie, > > It looks like the problem is in the drivers (not xterm). > > That could be defective implementation of XCopyArea, for instance. > > https://bugs.freedesktop.org/show_bug.cgi?id=110214 For those following along at home, for debian bullseye, the solution was simply to downgrade back to (old)stable's kernels, but alas that is no longer a solution for debian bookworm - the framebuffer bug is still there in 6.1 and 6.5 kernels. However, one of those bugs somewhere hinted about using xcompmgr. Running that in fvwm has solved my problem (as well as solving excessive CPU usage in mozilla related to it wanting to continually update windows that aren't actually in view). No apparent sideeffects at all, which seems rather strange for something coming out of the shiny new world. I have no idea how xcompmgr fixes this, but it fixes the screen artefacts in xterm nevertheless! -- Tim Connors
Bug#1057843: Guidelines for affected users
Meanwhile, can the ftp admins pull this faulty version? I just managed to download and install this, but fortunately didn't reboot on all of my systems before coming across this bug via LWN via reddit. If you're in such a pickle as myself, you're able to get around it for now by: apt install linux-image-amd64/bookworm-security dpkg --get-selections | grep 6.1.0.14 apt purge linux-image-6.1.0-14-amd64 (probably want to mark that one as uninstallable too, but there's only one of me, surely I'll remember not to install it at a later date??!) and at worst you'll be left on the kernel you're currently running. I am basing this off https://lwn.net/Articles/954285/ "- Stable kernels < 6.5 are affected if they have 91562895f803 (ext4 commit) - Kernels >= 6.5 are not affected, as they will _also_ have 936e114a245b6 (iomap commit)" 91562895f803 is not in 6.1.55-1 that anyone who last updated 3 weeks ago would have encountered, nor in the current bookworm-security version. -- Tim Connors
Bug#1014625: xterm: screen corruption of scrollback buffer
Package: xterm Version: 372-1 Severity: normal I'm getting screen corruption (scattered blocks of blackness) over text in the xterm display when scrolling back. The blocks move with the contents of the scrollback when scrolling. When that text is eventually scrolled off the screen, scrolling back may induce a different corruption pattern. Forcing a redisplay of the contents of the terminal by going to a different virtual desktop and back will get rid of the corruption. This has happened ever since I changed my hardware -- mostly updating my video card to a radeon RX570 -- necessitating new versions of some drivers and kernel. While I would happily accept that the video card might have some dodgy memory (note to self: find a GPU memory stress tester), this corruption has not affected any other program other than xterm's scrollback buffer, so I wonder if it's a bug instead. Screengrabs of the symptom: https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption.png https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption2.png radeon amdgpu drivers and firmware are the latest version allowed by otherwise being on debian stable - ie, firmware-amd-graphics/unstable=20210818-1 xserver-xorg-video-amdgpu/stable=19.1.0-2 (backporting requires upgrading libc) kernel is bullseye-backports = 5.18.2-1~bpo11+1 Both xterm/stable and a backported xterm/unstable exhibit the same symptoms. Video card is: 02:00.0 0300: 1002:67df (rev ef) (prog-if 00 [VGA controller]) 02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 xterm depends on: ii libc6 2.31-13+deb11u3 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1 ii libice6 2:1.0.10-1 ii libtinfo6 6.2+20201114-2 ii libutempter01.2.1-2 ii libx11-62:1.7.2-1 ii libxaw7 2:1.0.13-1.1 ii libxext62:1.3.3-1.1 ii libxft2 2.3.2-2 ii libxinerama12:1.1.4-2 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.2.0-1 ii xbitmaps1.1.1-2.1 Versions of packages xterm recommends: ii x11-utils 7.7+5 Versions of packages xterm suggests: pn xfonts-cyrillic -- no debconf information
Bug#964090: Still getting security policy `PDF' error in 2022
Still getting this error in 2022, despite the bug having been closed years ago, and having never existed in debian stable. 34710,4> mogrify -format pdf -- *png mogrify-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/421. This makes the package rather useless for the vast majority of uses, which is converting trusted data. We're not all running public facing webservers accepting unsanitised data from the public. Some of us use our computers to do useful things too. -- Tim Connors
Bug#1009864: xscreensaver: firefox stops (inhibits) xscreensaver from firing. Needs option to ignore firefox
Package: xscreensaver Version: 5.45+dfsg1-2 Severity: normal All the search results on the internet are for doing the opposite of what I want - people want firefox, when playing a video, to inhibit xscreensaver. It already does that for me. xscreensaver -verbose: xscreensaver-systemd: 23:28:03: uninhibited by "firefox-esr" with cookie DEB56E99 xscreensaver-systemd: 23:28:03: inhibit: unable to get pid of "firefox-esr": No data available xscreensaver-systemd: 23:28:03: inhibited by "firefox-esr" with "video-playing" -> cookie ADCA6C0D xscreensaver-systemd: 23:28:16: uninhibited by "firefox-esr" with cookie ADCA6C0D xscreensaver-systemd: 23:28:16: inhibit: unable to get pid of "firefox-esr": No data available xscreensaver-systemd: 23:28:16: inhibited by "firefox-esr" with "video-playing" -> cookie 57431273 xscreensaver-systemd: 23:28:28: uninhibited by "firefox-esr" with cookie 57431273 xscreensaver-systemd: 23:28:28: inhibit: unable to get pid of "firefox-esr": No data available xscreensaver-systemd: 23:28:28: inhibited by "firefox-esr" with "video-playing" -> cookie B8F2311F xscreensaver-systemd: 23:28:41: uninhibited by "firefox-esr" with cookie B8F2311F xscreensaver-systemd: 23:28:41: inhibit: unable to get pid of "firefox-esr": No data available Only problem is I'm not playing a video. Unfortunately, the net is full of ads, so pretty much every page claims to be "playing a video". I just want to be able to tell xscreensaver to ignore any calls from this list of programs: 1) firefox-esr Oh look at that, end of list. Yes, I know the proper fix is to tell firefox to give me an option to not inhibit the screensaver, but we all know how likely that feature request is to ever be actioned without "CLOSED WONTFIX". In the meantime, you're trusting every application not to be abusive. In this case, firefox is being abusing, and there should be an override to tell the system to ignore it. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-12-amd64 (SMP w/20 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.60 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u3 ii libcrypt11:4.4.18-4 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-2 ii libpam0g 1.4.0-9+deb11u1 ii libpango-1.0-0 1.46.2-3 ii libsystemd0 247.3-7 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.10+dfsg-6.7+deb11u1 ii libxmu6 2:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxt6 1:1.2.0-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.45+dfsg1-2 Versions of packages xscreensaver recommends: ii libjpeg-turbo-progs 1:2.0.6-4 ii perl5.32.1-4+deb11u2 ii wbritish [wordlist] 2019.10.06-1 ii wbritish-huge [wordlist]2019.10.06-1 ii wbritish-insane [wordlist] 2019.10.06-1 ii wbritish-large [wordlist] 2019.10.06-1 ii wbritish-small [wordlist] 2019.10.06-1 ii xfonts-100dpi 1:1.0.4+nmu1.1 Versions of packages xscreensaver suggests: ii chromium [www-browser]100.0.4896.127-1~deb11u1 ii dillo [www-browser] 3.0.5-7 ii falkon [www-browser] 3.1.0+dfsg1-11 ii firefox-esr [www-browser] 91.8.0esr-1~deb11u1 ii fortune-mod [fortune] 1:1.99.1-7.1 pn gdm3 | kdm-gdmcompat ii google-chrome-stable [www-browser]100.0.4896.127-1 ic google-chrome-unstable [www-browser] 84.0.4115.5-1 ii konqueror [www-browser] 4:20.12.0-4 ii links [www-browser] 2.21-1+b1 ii lynx [www-browser]2.9.0dev.6-3~deb11u1 pn qcam | streamer ii vivaldi-stable [www-browser] 5.2.2623.39-1 ii w3m [www-browser] 0.5.3+git20210102-6 pn xdaliclock pn xfishtank ii xscreensaver-data-extra 5.45+dfsg1-2 ii xscreensaver-gl 5.45+dfsg1-2 ii xscreensaver-gl-extra 5.45+dfsg1-2 -- no debconf information
Bug#1009264: hddtemp wakes up non ATA drives
Package: hddtemp Version: 0.3-beta15-54 Severity: normal hddtemp(1) shows that --wake-up is only relevant for ATA drives. My testing confirms this - hddtemp /dev/sdb first returns an incorrect error, but spins up the drive anyway, then it starts to succeed: tconnors@pve:~$ sudo hddtemp /dev/sdb /dev/sdb: SEAGATE ST4000NM0023: drive supported, but it doesn't have a temperature sensor. tconnors@pve:~$ sudo hddtemp /dev/sdb /dev/sdb: SEAGATE ST4000NM0023: 44°C Just like https://www.smartmontools.org/ticket/1586 (I don't believe hddtemp links against smartmontools), there are ways to get the wake status of non ATA disks, and hddtemp should default to not waking up sleeping drives. tconnors@pve:~$ for i in /dev/sd[b-gi-z] ; do echo $i ; sudo sdparm --command=sense $i ; done /dev/sdb /dev/sdb: SEAGATE ST4000NM0023 XMGJ /dev/sdc /dev/sdc: SEAGATE ST4000NM0023 XMGJ /dev/sdd /dev/sdd: SEAGATE ST6000NM0095 DS22 /dev/sde /dev/sde: SEAGATE ST4000NM0023 XMGJ /dev/sdf /dev/sdf: SEAGATE ST6000NM0095 DS22 /dev/sdg /dev/sdg: TOSHIBA MG04SCA60EE DR07 /dev/sdi /dev/sdi: ATA WDC WD10EAVS-32D 1A01 tconnors@pve:~$ for i in /dev/sd[b-gi-z] ; do echo $i ; sudo sg_start -r --pc=3 $i & done ; wait /dev/sdb [1] 1840017 /dev/sdc [2] 1840018 /dev/sdd [3] 1840019 /dev/sde [4] 1840020 /dev/sdf [5] 1840021 /dev/sdg [6] 1840022 /dev/sdi [7] 1840023 Illegal request START STOP UNIT command failed sg_start failed: Illegal request tconnors@pve:~$ for i in /dev/sd[b-gi-z] ; do echo $i ; sudo sdparm --command=sense $i ; done /dev/sdb /dev/sdb: SEAGATE ST4000NM0023 XMGJ Additional sense: Standby condition activated by command /dev/sdc /dev/sdc: SEAGATE ST4000NM0023 XMGJ Additional sense: Standby condition activated by command /dev/sdd /dev/sdd: SEAGATE ST6000NM0095 DS22 Additional sense: Standby condition activated by command /dev/sde /dev/sde: SEAGATE ST4000NM0023 XMGJ Additional sense: Standby condition activated by command /dev/sdf /dev/sdf: SEAGATE ST6000NM0095 DS22 Additional sense: Standby condition activated by command /dev/sdg /dev/sdg: TOSHIBA MG04SCA60EE DR07 Additional sense: Standby condition activated by command /dev/sdi /dev/sdi: ATA WDC WD10EAVS-32D 1A01 -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-12-amd64 (SMP w/20 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hddtemp depends on: ii debconf [debconf-2.0] 1.5.77 ii libc6 2.31-13+deb11u3 ii lsb-base 11.1.0 hddtemp recommends no packages. hddtemp suggests no packages. -- debconf information: * hddtemp/interface: 127.0.0.1 * hddtemp/syslog: 0 * hddtemp/SUID_bit: true * hddtemp/daemon: true * hddtemp/port: 7634
Bug#1004649: needrestart: painfully slow, but just seems to be doing loops over and over again of dpkg-query --search /bin/dash
Package: needrestart Version: 3.5-4 Severity: normal After an upgrade of `xdg-desktop-portal/bullseye-backports` (which needrestart didn't detect should be restarted, BTW: tconnors4388 0.0 0.0 617848 5372 ?Sl2021 2:14 /usr/libexec/xdg-desktop-portal tconnors4396 0.0 0.0 602912 2396 ?Sl2021 0:31 /usr/libexec/xdg-document-portal root4405 0.0 0.0 2572 1684 ?Ss2021 0:00 \_ fusermount -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/738/doc tconnors4411 0.0 0.0 529116 27656 ?Sl2021 8:13 /usr/libexec/xdg-desktop-portal-gtk ) I was wondering why needrestart was taking even longer than usual. So I ran a few 'ps axfu' and discovered it was continually restarting dpkg-query --search /bin/dash over and over again: root 1130884 1.3 0.3 137036 123668 pts/125 S+ 12:41 0:04 | | \_ apt install xdg-desktop-portal/bullseye-backports root 1131701 0.0 0.0 137036 32332 pts/125 S+ 12:41 0:00 | | \_ apt install xdg-desktop-portal/bullseye-backports root 1141619 0.0 0.0 2424 596 pts/125 S+ 12:41 0:00 | | \_ sh -c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true root 1141622 0.3 0.0 29212 23020 pts/125 S+ 12:41 0:01 | | \_ /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart root 1141782 14.3 0.2 83300 77220 pts/125 S+ 12:42 0:45 | | \_ /usr/bin/perl /usr/sbin/needrestart root 1152868 1.0 0.0 12052 6076 pts/125 S+ 12:47 0:00 | | \_ /usr/bin/perl /etc/needrestart/hook.d/10-dpkg /bin/dash root 1152870 99.0 0.3 134264 129920 pts/125 R+ 12:47 0:00 | | \_ dpkg-query --search /bin/dash With /etc/needrestart/hook.d/10-dpkg and dpkg-query --search /bin/dash constantly recycling PIDs (but /usr/sbin/needrestart remaining at the root of the process tree the whole time). After a while, it finally moved onto /bin/bash, and then eventually finished. Since every time I looked, it was executing `dpkg-query --search`, which takes 3 seconds when the filesystem cache is warm on my system, it seems those results should be cached in the /usr/sbin/needrestart process and 10-dpkg hook not asked to keep reprocessing the same file, since they're obviously not able to change when you're at the final step of a dpkg run with the dpkg lock held. -- Package-specific info: needrestart output: Your outdated processes: blueman-applet[5988], blueman-tray[6581], cura[267343], dconf-service[4428], emacs[1624828], file:// Content[497712], firefox-esr[2340505], fvwm[5484], FvwmAnimate[2591535], FvwmButtons[2591539, 2593188], FvwmCommandS[2591537], FvwmPager[2593140, 2593330], gconfd-2[3813503], gnuplot[5473, 5480], gthumb[2057638], gvfs-afc-volume[1396368], gvfsd[4286], gvfsd-dnssd[1396447], gvfsd-http[33183], gvfsd-metadata[1396504], gvfsd-network[1396433], gvfsd-trash[1396378], gvfs-goa-volume[1396363], gvfs-gphoto2-vo[1396358], gvfs-mtp-volume[1396374], gvfs-udisks2-vo[1396062], ibus-daemon[4274], ibus-engine-sim[4415], ibus-extension-[4311], ibus-memconf[4308], ibus-portal[4318], ibus-ui-gtk3[4310], ibus-x11[4316], klauncher[1738491], pasystray[5464], pavucontrol[1395977], pnmixer[5987], pqiv[3247724], Privileged Cont[2341539], procmeter3[5381, 5378], pulseaudio[2475427], RDD Process[2350394], slic3r_main[271311], soffice.bin[3382689], solaar[5989], systemd[3436], teams[3883205, 3883066, 3883390, 3006485, 3883222, 3883061, 3005930, 3006471, 3883067, 3883320, 3005929], trayer[5463], WebExtensions[2341812], xbiff[6196, 7981], xclock[4902, 4903], xdg-desktop-por[4388, 4411], xdg-document-po[4396], xdg-permission-[4400], xload[2593144, 2593343], xmms2d[4141], xmms2-scrobbler[4152], xscreensaver[2443046], xterm[1701718, 531788, 241095, 2866935, 44828, 2893255, 2894250, 2849956, 2786598, 245266, 1528207, 1719135, 21443, 2370287, 2740199, 1132330, 211602, 88413, 2772560, 2375656, 2902583, 1912045, 1781102, 110242, 1478635, 1148690, 3081636, 2847751, 393443, 2439030, 2979687, 2132518, 2607852, 36770, 2354803, 3494011, 1789291, 4158013, 1713740, 1780214, 4887, 2341755, 3891991, 3010070, 1910392, 1375767, 1665193, 2610142, 2577114, 1585541, 3835957, 2738287, 2335579, 455387, 3390674, 1890801, 2411578, 915658, 3521849, 1780344, 1881688, 4888, 3364489, 854647, 1788777, 3015586, 1333721, 1912867, 2353805, 1183448, 1577276, 1147033, 2346460, 3461117, 2414908, 2344642, 1793822, 2340866, 1442080, 247038, 4018243, 5370, 1792550, 3419460, 1050139, 2520658, 2663801, 38535, 3381218, 110127, 2593345, 2854561, 2895087, 2416821, 2534132, 2513780, 1697027, 1696510, 2337920, 464879,
Bug#1003607: luminance-hdr 2.6.0 almost always crashes on startup on files that worked with 2.4.0
Package: luminance-hdr Version: 2.6.0+dfsg-2+b8 Severity: important On bullseye, luminance-hdr almost always crashes on startup on my machine with the following failure (but does succeed in starting up on the occasional old .exr file I still have lying around): 37317,2> luminance-hdr *exr libpng warning: iCCP: known incorrect sRGB profile Min Luminance: 1e-06 Max Luminance: 2.33984 Mapping method: 3 fromLDRPFStoQImage() = 272.595 msec resizeFrame() = 5.021 msec pfscopy() = 0.163 msec pfscopy() = 0.153 msec pfstmo_mantiuk06 (Mode: Contrast Mapping, scaleFactor: 0.1, saturationFactor: 0.8, detailFactor: 0.8) tmo_mantiuk06 = 29.889 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 fromLDRPFStoQImage() = 0.482 msec Black in = 0, Black out = 0, White in = 0.960784, White out = 1, Gamma = 1 gamma_levels() = 1.142 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 fromLDRPFStoQImage() = 1.771 msec pfscopy() = 0.059 msec pfscopy() = 0.049 msec transformColorSpace: Found right match for colorspace conversion transformRGB2XYZ() = 0.564 msec pfstmo_mantiuk08 (saturation factor: 1, contrast enhancement factor: 1, white_y: -2, setluminance: 0) Display function: gamma-gain-black-ambient gamma = 2.2 L_max = 200 L_black = 0.8 E_amb = 60k = 0.01 Display size paramaters: pixels per visual degree = 30 viewing distance = 0.5 [meters] transformColorSpace: Found right match for colorspace conversion transformXYZ2RGB() = 0.476 msec transformColorSpace: Found right match for colorspace conversion transformRGB2XYZ() = 1.667 msec tmo_mantiuk08 = 76.152 msec transformColorSpace: Found right match for colorspace conversion transformXYZ2RGB() = 0.143 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 fromLDRPFStoQImage() = 1.033 msec Black in = 0, Black out = 0, White in = 0.980392, White out = 1, Gamma = 1 gamma_levels() = 0.595 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 fromLDRPFStoQImage() = 0.323 msec pfscopy() = 0.063 msec pfscopy() = 0.185 msec pfstmo_fattal02 (alpha: 1, beta: 0.9. saturation: 1, noise: 0.01, fftsolver: 1) pde residual error: -nan tmo_fattal02 = 551.336 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 fromLDRPFStoQImage() = 5.318 msec Black in = 0, Black out = 0, White in = 0.0196078, White out = 1, Gamma = 1 gamma_levels() = 5.143 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 fromLDRPFStoQImage() = 1.46 msec pfscopy() = 0.187 msec pfscopy() = 0.061 msec pfstmo_ferradans11 (rho: -2, inv_alpha: 5) tmo_ferradans11 = 1017.3 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 fromLDRPFStoQImage() = 1.231 msec Black in = 0.0156863, Black out = 0, White in = 1, White out = 1, Gamma = 1 gamma_levels() = 7.543 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 fromLDRPFStoQImage() = 7.46 msec pfscopy() = 0.092 msec pfscopy() = 0.055 msec pfstmo_drago03 (bias: 0.85) tmo_drago03 = 8.034 msec Min Luminance: 0 Max Luminance: 1 Mapping method: 0 luminance-hdr: ./src/Libpfs/colorspace/rgbremapper.h:95: uint8_t Remapper::operator()(float) const: Assertion `sample >= 0.f' failed. luminance-hdr: ./src/Libpfs/colorspace/rgbremapper.h:95: uint8_t Remapper::operator()(float) const: Assertion `sample >= 0.f' failed. Aborted Whereas if I rebuild 2.4 in a docker image, it loads that image just fine: 37295,32> docker run -ti --rm -e DISPLAY=$DISPLAY -e CWD="$PWD" -v /tmp/.X11-unix/:/tmp/.X11-unix -v /home/tconnors:/home/tconnors luminance-hdr luminance-hdr *exr / /home/tconnors/photos/uncategorised/Tasmania 2021/qiv-2 I18NDIR: /usr/share/luminance-hdr/i18n QLibraryInfo::location(QLibraryInfo::TranslationsPath)): "/usr/share/qt5/translations" Database opened libGL error: MESA-LOADER: failed to retrieve device information libGL error: unable to load driver: amdgpu_dri.so libGL error: driver pointer missing libGL error: failed to load driver: amdgpu libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: radeonsi HdrViewer::mapFrameToImage() [NEW]= 1630.49 msec MainWindow::updateActions( 0 ) resizeFrame() = 5.516 msec pfstmo_mantiuk06 (Mode: Contrast Mapping, scaleFactor: 0.1, saturationFactor: 0.8, detailFactor: 0.8) fromLDRPFStoQImage() = 0.05 msec transformColorSpace: Found right match for colorspace conversion transformRGB2XYZ() = 2.482 msec pfstmo_mantiuk08 (saturation factor: 1, contrast enhancement factor: 1, white_y: -2, setluminance: 0) Display function: gamma-gain-black-ambient gamma = 2.2 L_max = 200 L_black = 0.8 E_amb = 60k = 0.01 Display size paramaters: pixels per visual degree = 30 viewing distance = 0.5 [meters] transformColorSpace: Found right match for colorspace conversion transformXYZ2RGB() = 4.528 msec pfstmo_ma
Bug#980555: Missing ec_sys module
Package: linux-image-amd64 Version: 5.10.84-1 Followup-For: Bug #980555 X-Debbugs-Cc: Bastian Blank , GengYu Rao >> What would you need this module for? It's described as debugging and >> development aid, not something a user wants to use. > EC stands for embedded controller, which can be used to configure fans, > LED lights and other things on laptop. > > I'm trying to use it to control fan speed on my laptop. Basically anyone with a laptop and a default BIOS fan control profile that is awful must resort to ec_sys. For example, my Clevo P15SM needs this: https://github.com/SkyLandTW/clevo-indicator/blob/master/src/clevo-indicator.c It'd be really nice if I could quieten down my laptop from jet-taking-off-at-maximum-throttle when the CPU temperature is only 50! There seems no reason *not* to compile ec_sys as a module when the debian kernel is so full of other debugging modules. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-amd64 depends on: ii linux-image-5.10.0-10-amd64 5.10.84-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information
Bug#954159: pavucontrol: allow multiple instances
Package: pavucontrol Version: 4.0-2 Followup-For: Bug #954159 Upstream bug here: https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues/75 Attracting the usual level of developer interest for a freedesktop project. This seems to be the patch that introduced the broken behaviour: https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/commit/f6ce4fb8db51489f6ab1210593695f465ccb83a0 Behaviour looks pretty entrenched - don't know how hard it would be to put it all under a commandline switch. -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pavucontrol depends on: ii libatkmm-1.6-1v5 2.28.0-3 ii libc62.31-13+deb11u2 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libgcc-s110.2.1-6 ii libglib2.0-0 2.66.8-1 ii libglibmm-2.4-1v52.64.2-2 ii libgtk-3-0 3.24.24-4 ii libgtkmm-3.0-1v5 3.24.2-2 ii libpulse-mainloop-glib0 14.2-2 ii libpulse014.2-2 ii libsigc++-2.0-0v52.10.4-2 ii libstdc++6 10.2.1-6 Versions of packages pavucontrol recommends: ii pulseaudio 14.2-2 pavucontrol suggests no packages. -- no debconf information
Bug#998389: mlocate systemd timer appears to force execution at midnight, and the obvious override doesn't appear to be working
Package: mlocate Version: 0.26-5 Severity: normal The new systemd mlocate.timer causes all of my machines to run mlocate exactly at midnight. Neglecting that the stated rationale for the change to a 24hour splay is a silly idea (the vast majority of people are neither running a cluster, nor aren't at their computers between 2am and 6am), there is no documentation to set otherwise (or return to the more sane system default of being in cron.daily, which is already able to be splayed according the admin's wishes). Random advice on the internet was to chuck this in /etc/systemd/system/mlocate.timer.d/override.conf and reload systemd, but that resulted in no change to execution time: [Timer] AccuracySec=1h OnCalendar=*-*-* 4:00 So what's the correct solution? Can that be documented? -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mlocate depends on: ii adduser 3.118 ii libc62.31-13+deb11u2 mlocate recommends no packages. Versions of packages mlocate suggests: ii nocache 1.1-1+b1 -- Configuration Files: /etc/updatedb.conf changed [not included] -- no debconf information
Bug#926896: sysvinit-utils: pidof is unreliable
On Thu, 21 Oct 2021, Jesse Smith wrote: > "pidof -z " should return all matching processes, > including those in the zombie state. > > The attached patch also cleans up some code we don't need as a result of > this change and updates the man page. > > Please give the attached patch a try and confirm it's working. It's > working here for normal and zombie processes and it seems to be okay for > uninterruptable sleep processes too, but I'd like to have someone else > confirm everything looks right before I push this upstream. It works for basic usage of `pidof find`, `pidof dd`, etc, but I can't confirm nor deny whether it breaks system shutdown for people using sysvinit in the presence of broken remote mounts. -- Tim Connors
Bug#926896: sysvinit-utils: pidof is unreliable
Package: sysvinit-utils Version: 2.96-7 Followup-For: Bug #926896 The broken behaviour introduced by the fix to #719273 is the assumption that all D state processes are stuck. D is indeed "uninterruptable sleep", but uninterruptable in the sense that the process can't respond to a signal until the system call returns. It might still be very responsive, but just doing a lot of IO. For the one limited use-case of pidof at system shutdown (that apparently isn't even the case anymore according to[1]), you can be reasonably sure that D state processes at system shutdown time are indeed stuck (or just flushing a lot of data out to cache). But pidof is used elsewhere. Some processes don't do anything *but* IO - such as find and dd. I wasn't excited to find this morning that I couldn't `pidof find` anymore. Now except for pidof being owned by the sysvinit-utils package, I'd say the behaviour is entirely flipped around from what I'd expect by the principle of least surprise - pidof should do the sane default of checking all processes, and only in the limited shutdown case should there be a flag to invert that behaviour and ignore D state processes (I mean, I know when my NFS mounts go bad, a lot more goes wrong than just pidof - do we really want to patch every sar cron.minute job to ignore D state mounts too? No, let's not special case everything, and fix the root problem of a mount being stuck instead). But sysvinit's purpose is process management, so perhaps the redhat solution of having that binary owned by another package, eg procps, is the correct solution. [1] "Also, at the current time (and IIRC this wasn't the case when we submitted the original patch), start-stop-daemon is a binary not a script, and it doesn't call pidof or killall. Instead it uses its own code, and that code is subject to the same issue where it hangs on stuck NFS partitions. Therefore, as it stands, applying this patch to 'pidof' will no longer resolve the issue; similar changes would have to be made to 'killall'." - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719273#42 -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sysvinit-utils depends on: ii libc6 2.31-13+deb11u2 ii lsb-base 11.1.0 sysvinit-utils recommends no packages. sysvinit-utils suggests no packages. -- no debconf information
Bug#990069: Still broken in ssh 8.4p1-5, libc6 2.31-13
reopen 990069 thanks. With these packages installed: 24573,4> dpkg --get-selections | grep ssh clusterssh install libssh-4:amd64 install libssh-gcrypt-4:amd64 install libssh2-1:amd64 install openssh-client install openssh-server install openssh-sftp-server install ssh-askpass install sshfs install This particular system is sysv, but I think my other machines suffering this same problem were already on systemd by the time I upgraded. 24583,14> sudo grep -e ssh -e libc6 -e Restarting -e '^ [a-z]' -e Services /var/log/apt/term.log Replacing files in old package libc6:amd64 (2.28-10) ... Replacing files in old package libc6:i386 (2.28-10) ... Preparing to unpack .../06-openssh-sftp-server_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Preparing to unpack .../13-openssh-client_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Preparing to unpack .../15-openssh-server_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Preparing to unpack .../0-libc6-dev_2.31-13_amd64.deb ... Unpacking libc6-dev:amd64 (2.31-13) over (2.28-10) ... Preparing to unpack .../libc6_2.31-13_i386.deb ... De-configuring libc6:amd64 (2.28-10) ... Unpacking libc6:i386 (2.31-13) over (2.28-10) ... Preparing to unpack .../libc6_2.31-13_amd64.deb ... Unpacking libc6:amd64 (2.31-13) over (2.28-10) ... Setting up libc6:amd64 (2.31-13) ... Restarting services possibly affected by the upgrade: smbd: restarting...done. openbsd-inetd: restarting...done. exim4: restarting...done. cron: restarting...done. autofs: restarting...done. atd: restarting...done. Services restarted successfully. Setting up libc6:i386 (2.31-13) ... Preparing to unpack .../libc6-dbg_2.31-13_amd64.deb ... Unpacking libc6-dbg:amd64 (2.31-13) over (2.28-10) ... Restarting services possibly affected by the upgrade: samba-ad-dc: stopping...starting...done. smbd: stopping...starting...done. exim4: stopping...starting...done. cron: stopping...starting...done. atd: stopping...starting...done. Services restarted successfully. Preparing to unpack .../137-libssh-gcrypt-4_0.9.5-1+deb11u1_amd64.deb ... Unpacking libssh-gcrypt-4:amd64 (0.9.5-1+deb11u1) over (0.8.7-1+deb10u1) ... At this point, there's: 24572,2> ls -lA /etc/init.d/ssh* -rwxr-xr-x 1 root root 3939 Feb 1 2020 /etc/init.d/ssh -rwxr-xr-x 1 root root 4056 Mar 13 2021 /etc/init.d/ssh.dpkg-new and ssh isn't yet started - I did that manually because I knew the problem was going to arise. -- Tim Connors
Bug#995430: qemu-user-static: creates /core dump spontaneously upon upgrade, even when not in use?
Package: qemu-user-static Version: 1:5.2+dfsg-11 Severity: normal I noticed a /core file in the root directory, dated around about when my machine was upgraded to bullseye. I checked another machine, and it too had the same core file, dated from the upgrade: 24606,4> ls -lA /core -rw--- 1 root root 11542528 Sep 15 00:41 core 0-0-16:27:43, Fri Oct 01 tconnors@fs:/snapshots/dirac/latest (bash) 24607,5> sudo file core core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from '/usr/libexec/qemu-binfmt/s390x-binfmt-P /check /check', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/check', platform: 'x86_64' Working backwards, this was the exact minute this machine was last rebooted, immediately after being dist-upgraded to bullseye. I haven't done anything deliberate to fire up qemu from this machine - I only use it occasionally, and haven't configured it to autostart anything. Certainly never done anything with S390 on these amd64 boxen. -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/24 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.1-1 Versions of packages qemu-user-static suggests: ii sudo 1.9.5p2-3 -- no debconf information
Bug#992121: linux-image-5.10.0-8-amd64: kernel oops and subsequent hard crash in bluetooth bt_sock_poll, regression, upstream patch
On Thu, 12 Aug 2021, Salvatore Bonaccorso wrote: > > https://www.spinics.net/lists/linux-bluetooth/msg88356.html > > > > points to a patch that has supposedly already been applied to > > bluetooth-next, but is definitely not in linux-source-5.10 5.10.46-4 > > (testing). > > > > Current code still reads: > > > > /* cleanup runtime environment */ > > remove_wait_queue(sk_sleep(session->intr_sock->sk), &intr_wait); > > remove_wait_queue(sk_sleep(session->intr_sock->sk), &ctrl_wait); > > wake_up_interruptible(&session->report_queue); > > hidp_del_timer(session); > > > > Second remove_wait_queue should be: ctrl_sock->sk > > Would it be possible that you check if the upstream commit > https://git.kernel.org/linus/cca342d98bef68151a80b024f7bf5f388d1fbdea > fixes the issue? > > It was not yet queued for the 5.10.y series, but if yes, this should > go to stable@ so that we then can pick it up for either cherry-picking > for the next bullseye upload (or a rebase to the latest 5.10.y in a > point release). I've been running it for a few days now, and it seems good to me! -- Tim Connors
Bug#971428: xloadimage: -rotate 0 exhausts memory
Package: xloadimage Version: 4.1-25 Severity: important Pick a random image that's obviously small and can't possibly exhaust any of your resources (eg, 320x240 pixels in size). I marked this as severity important, because if you didn't already know to run xloadimage under ulimit for safety, now you have a crashed desktop. 34831,15> ulimit -S -v 1000 # to not crash your machine in a swap-storm 34832,16> xloadimage -rotate 0 background/zuv7wPb.png background/zuv7wPb.png is 711x1066 PNG image, color type RGB_ALPHA, 8 bit Rotating image by 0 degrees... Memory has been exhausted; operation cannot continue (sorry). Other rotate options work. -rotate 360 works. Just -rotate 0 causes it to request infinite memory. Discovered when it was trying to set my background image: 34844,3> xloadimage -onroot -quiet -border '#001122' -at 671,0 -rotate 0 zuv7wPb.png -at 3103,0 -rotate 0 zuv7wPb.png -at 5663,0 -rotate 0 zuv7wPb.png Memory has been exhausted; operation cannot continue (sorry). -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages xloadimage depends on: ii libc62.28-10 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.36-6 ii libtiff5 4.1.0+git191117-2~deb10u1 ii libx11-6 2:1.6.7-1 xloadimage recommends no packages. xloadimage suggests no packages. -- no debconf information
Bug#471112: optional no warn upon when falling through to a default net
tags 471112 patch
done
For those of us tunneling through to corporate nets for a small subnet,
and otherwise wanting the default case to go through our own internet, the
warning messags stating tsocks is falling through to the default net on
every open() call is pointless.
The included patch gives a .tsocks.conf "fallback = nowarn" option.
All the arguments presented to date that the user might not be expecting
tsocks to fall for example if they're using tor through are moot, because
if people truly aren't expecting it to fall through, then they can either
set "fallback = yes", or keep "fallback = no". If they set it to
"nowarn", then they know that tsocks only tunnels for those networks
defined in .tsocks.conf.
--
Tim ConnorsDescription: this patch accepts fallback = nowarn to suppress the warning
that we're going offnet
Last-update: 2020-06-08
Author: Tim Connors
diff -u tsocks-1.8beta5+ds1/parser.c tsocks-1.8beta5+ds1.patched/parser.c
--- tsocks-1.8beta5+ds1/parser.c 2020-06-03 17:38:58.0 +1000
+++ tsocks-1.8beta5+ds1.patched/parser.c 2020-06-09 15:32:33.578070929 +1000
@@ -522,6 +522,7 @@
"once in configuration file.\n",
lineno, currentcontext->lineno);
} else {
+ if(!strcmp(v, "nowarn")) config->fallback = -1;
if(!strcmp(v, "yes")) config->fallback = 1;
if(!strcmp(v, "no")) config->fallback = 0;
}
diff -u tsocks-1.8beta5+ds1/tsocks.c tsocks-1.8beta5+ds1.patched/tsocks.c
--- tsocks-1.8beta5+ds1/tsocks.c 2020-06-03 17:38:58.0 +1000
+++ tsocks-1.8beta5+ds1.patched/tsocks.c 2020-06-09 15:33:03.686150245 +1000
@@ -295,11 +295,13 @@
if (path->address == NULL) {
if (path == &(config->defaultserver)) {
if (config->fallback) {
-show_msg(MSGERR, "Connection needs to be made "
- "via default server but "
- "the default server has not "
- "been specified. Fallback is 'yes' so "
- "Falling back to direct connection.\n");
+if (config->fallback != -1) {
+ show_msg(MSGERR, "Connection needs to be made "
+"via default server but "
+"the default server has not "
+"been specified. Fallback is 'yes' so "
+"Falling back to direct connection.\n");
+}
return(realconnect(__fd, __addr, __len));
} else {
show_msg(MSGERR, "Connection needs to be made "
diff -u tsocks-1.8beta5+ds1/tsocks.conf.5 tsocks-1.8beta5+ds1.patched/tsocks.conf.5
--- tsocks-1.8beta5+ds1/tsocks.conf.5 2020-06-03 17:38:58.0 +1000
+++ tsocks-1.8beta5+ds1.patched/tsocks.conf.5 2020-06-09 15:34:32.046383013 +1000
@@ -129,7 +129,8 @@
.TP
.I fallback
This directive allows one to fall back to direct connection if no default
-server present in the configuration and fallback = yes.
+server present in the configuration and fallback = yes or fallback = nowarn
+(to suppress a warning about falling back).
If fallback = no or not specified and there is no default server, the
tsocks gives an error message and aborts.
This parameter protects the user against accidentally establishing
Bug#935373: gpsbabel: workaround for "garmin_fit" files that occasionally have "Bad endian field"
OK, just submitted a pull request:
https://github.com/gpsbabel/gpsbabel/pull/401
Thanks.
On Fri, 6 Sep 2019, Jochen Sprickerhof wrote:
> Hi Tim,
>
> thanks for your bug report. Can you send it to upstream as a pull request
> here:
>
> https://github.com/gpsbabel/gpsbabel
>
> Thanks
>
> Jochen
>
> * Tim Connors [2019-08-22 12:22]:
> > Package: gpsbabel
> > Version: 1.6.0+ds-5
> > Severity: normal
> > Tags: patch upstream
> >
> > I have a device that occasionally seems to forget to initialise parts
> > of itself. When it does this, the "garmin_fit" tracks it save aren't
> > readable by gpsbabel. Normally they are. The symptom is:
> >
> > 24874,32> gpsbabel -i garmin_fit -f can\'t-read-0545.fit -o gpx -F
> > /tmp/0545.gpx
> > fit: Bad endian field
> >
> > When run with the attached patch though (which may need to be refined
> > to perhaps require the user to first set a "ignore_endian_errors"
> > flag, or just treat it as Situation Normal and just send the output to
> > the debug logs instead), the output file appears to be entirely valid.
> > The patch ends up just treating the endian uint8 as a boolean:
> >
> > --- a/garmin_fit.cc
> > +++ b/garmin_fit.cc
> > @@ -253,7 +253,7 @@
> > // second byte is endianness
> > def->endian = fit_getuint8();
> > if (def->endian > 1) {
> > -fatal(MYNAME ": Bad endian field\n");
> > +warning(MYNAME ": Bad endian field: %d\n",def->endian);
> > }
> > fit_data.endian = def->endian;
> >
> >
> > The result I get on my two example files are:
> >
> > 0-0-12:11:01, Thu Aug 22 tconnors@weinberg:~/tracks (bash)
> > 24875,33> gpsbabel -i garmin_fit -f can\'t-read-0545.fit -o gpx -F
> > /tmp/0545.gpx
> > fit: Bad endian field: 229
> > fit: Bad endian field: 186
> > 0-0-12:20:08, Thu Aug 22 tconnors@weinberg:~/tracks (bash)
> > 24876,34> gpsbabel -i garmin_fit -f can\'t-read-0545-2.fit -o gpx -F
> > /tmp/0545-2.gpx
> > fit: Bad endian field: 19
> > fit: Bad endian field: 69
> >
> >
> > I'll see whether I can upload an example file exhibiting the problem...
> >
> >
> > -- System Information:
> > Debian Release: 9.8
> > APT prefers stable-updates
> > APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2,
> > 'unstable'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
> > LANGUAGE=en_AU:en (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: sysvinit (via /sbin/init)
> >
> > Versions of packages gpsbabel depends on:
> > ii libc6 2.28-6
> > ii libgcc1 1:8.3.0-6
> > ii libqt5core5a 5.11.3+dfsg1-1
> > ii libshp2 1.4.0-1
> > ii libstdc++68.3.0-6
> > ii libusb-0.1-4 2:0.1.12-30
> > ii zlib1g1:1.2.8.dfsg-5
> >
> > Versions of packages gpsbabel recommends:
> > ii gpsbabel-doc 1.5.4-2
> >
> > gpsbabel suggests no packages.
> >
> > -- no debconf information
>
--
Tim Connors
Bug#935373: gpsbabel: workaround for "garmin_fit" files that occasionally have "Bad endian field"
Package: gpsbabel
Version: 1.6.0+ds-5
Severity: normal
Tags: patch upstream
I have a device that occasionally seems to forget to initialise parts
of itself. When it does this, the "garmin_fit" tracks it save aren't
readable by gpsbabel. Normally they are. The symptom is:
24874,32> gpsbabel -i garmin_fit -f can\'t-read-0545.fit -o gpx -F
/tmp/0545.gpx
fit: Bad endian field
When run with the attached patch though (which may need to be refined
to perhaps require the user to first set a "ignore_endian_errors"
flag, or just treat it as Situation Normal and just send the output to
the debug logs instead), the output file appears to be entirely valid.
The patch ends up just treating the endian uint8 as a boolean:
--- a/garmin_fit.cc
+++ b/garmin_fit.cc
@@ -253,7 +253,7 @@
// second byte is endianness
def->endian = fit_getuint8();
if (def->endian > 1) {
-fatal(MYNAME ": Bad endian field\n");
+warning(MYNAME ": Bad endian field: %d\n",def->endian);
}
fit_data.endian = def->endian;
The result I get on my two example files are:
0-0-12:11:01, Thu Aug 22 tconnors@weinberg:~/tracks (bash)
24875,33> gpsbabel -i garmin_fit -f can\'t-read-0545.fit -o gpx -F
/tmp/0545.gpx
fit: Bad endian field: 229
fit: Bad endian field: 186
0-0-12:20:08, Thu Aug 22 tconnors@weinberg:~/tracks (bash)
24876,34> gpsbabel -i garmin_fit -f can\'t-read-0545-2.fit -o gpx -F
/tmp/0545-2.gpx
fit: Bad endian field: 19
fit: Bad endian field: 69
I'll see whether I can upload an example file exhibiting the problem...
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gpsbabel depends on:
ii libc6 2.28-6
ii libgcc1 1:8.3.0-6
ii libqt5core5a 5.11.3+dfsg1-1
ii libshp2 1.4.0-1
ii libstdc++68.3.0-6
ii libusb-0.1-4 2:0.1.12-30
ii zlib1g1:1.2.8.dfsg-5
Versions of packages gpsbabel recommends:
ii gpsbabel-doc 1.5.4-2
gpsbabel suggests no packages.
-- no debconf information
Bug#808836: dependency on polkit
As per a comment on the upstream bug 1264, why even is there a hard dependency on policy kit? https://github.com/ZoneMinder/ZoneMinder/issues/1264#issuecomment-325999624 Policy kit has a hard dependency on systemd, which drags in a whole bunch of other dependencies that I'd rather not have on my webserver. If it was a recommends or a suggest instead, and the code had an option to use sudo for the service restarting (the standard way of handling privileges in portable trusted code), then this would be good. -- Tim Connors
Bug#901831: ERROR:gl_surface_presentation_helper.cc(161)] GetVSyncParametersIfAvailable() failed
> Hello, > > I have the same problem with chrome 68 and now 69. > > It's very annoying since my /var/log/messages can grow to 500MB per > day... Only 500MB per day? The luxury! > wc .xsession-errors.dirac.$today: 9769343 48847509 1338399239 I don't understand how people can write software this shit and still live with themselves. -- Tim Connors
Bug#911037: blank display at startup: [GFX1-]: Failed to lock new back buffer
On Mon, 15 Oct 2018, Carsten Schoenert wrote:
> Hi,
>
> Am 15.10.18 um 03:21 schrieb Tim Connors:
> > Package: thunderbird
> > Version: 1:60.0-3~deb9u1
> > Severity: important
> >
> > At thunderbird startup, I get a completely blank display, associated
> > with terminal message: [GFX1-]: Failed to lock new back buffer.
> >
> > (I presume this bug should be grave, but how can I be the only person
> > on the planet affected by it? The package is completely unusable to
> > me as of the update.)
>
> if it is related to AppArmor then the answer is simply No because the
> AppArmor profile is disabled by default.
Are you sure? I've never touched anything apparmor related. It strikes
me as a poorly thought out idea ("hey, lets block everything!", "hey,
let's open everything again because it turns out everything is needed for
basic functionality!").
> sudo aa-status --pretty-json | jq .profiles.thunderbird
"enforce"
> ls -lA /etc/apparmor.d/disable/
total 0
> sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird
Disabling /etc/apparmor.d/usr.bin.thunderbird.
> ls -lA /etc/apparmor.d/disable/
total 0
lrwxrwxrwx 1 root root 35 Oct 16 18:33 usr.bin.thunderbird ->
/etc/apparmor.d/usr.bin.thunderbird
> sudo aa-status --pretty-json | jq .profiles.thunderbird
null
And thunderbird works again.
> > At each focus event thereafter, the window flashes, and a system log
> > message is output:
> >
> > Oct 15 12:06:27 weinberg kernel: [233610.647925] audit: type=1400
> > audit(1539565587.008:2707): apparmor="DENIED" operation="mknod"
> > profile="thunderbird" name="/run/shm/org.chromium.viOLay" pid=20087
> > comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=2983 ouid=2983
> >
> > (different /run/shm/ tmp dir everytime)
> >
> > Stale apparmor profile affecting latest security update? Looks like
> > #887973 but that was claimed to have been fixed in a version far far
> > away.
> >
> > /etc/apparmor.d/usr.bin.thunderbird, provided by this version of
> > thunderbird, still references only /dev/shm:
> >
> > owner /dev/shm/org.chromium.* rw, # for Chromium IPC
> >
> >
> > I note also this report:
> > https://lists.dyne.org/lurker/message/20180918.101827.26f69559.de.html
> >
> > But users shouldn't be updating /etc/apparmor.d files that are the
> > responsibility of the package.
>
> Hm, I still don't see what this report is about. It looks like it this
> is related to AppArmor.
But I didn't knowingly install apparmor. If I try to remove it, half my
system disappears (eg, python3). But thunderbird did install
/etc/apparmor.d/usr.bin.thunderbird so thunderbird should make sure the
profile is correct.
Actually, let's try removing apparmor anyway:
> sudo apt purge dh-apparmor libapparmor-perl libapparmor1
> dpkg --get-selections | grep apparmor
> thunderbird
[GFX1-]: Failed to lock new back buffer.
E! Still no go.
The *only* way of getting a working thunderbird appears to be making sure
this symlink exists:
> ls -lA /etc/apparmor.d/disable/
total 0
lrwxrwxrwx 1 root root 35 Oct 16 18:50 usr.bin.thunderbird ->
/etc/apparmor.d/usr.bin.thunderbird
> What have you done to get clearance on this?
> Have you an enabled or a disabled AppArmor profile? I guess you are
> running an active profile for Thunderbird.
>
> Do you have checked if any AddOn is possibly provoking your issues?
>
> https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues
When enforcing (ie, system default)
thunderbird --safe-mode
pops up a dialog that's also black, with a bunch of repeated messages per
focus event:
[GFX1-]: Failed to lock new back buffer.
--
Tim Connors
Bug#911037: blank display at startup: [GFX1-]: Failed to lock new back buffer
Package: thunderbird Version: 1:60.0-3~deb9u1 Severity: important At thunderbird startup, I get a completely blank display, associated with terminal message: [GFX1-]: Failed to lock new back buffer. (I presume this bug should be grave, but how can I be the only person on the planet affected by it? The package is completely unusable to me as of the update.) At each focus event thereafter, the window flashes, and a system log message is output: Oct 15 12:06:27 weinberg kernel: [233610.647925] audit: type=1400 audit(1539565587.008:2707): apparmor="DENIED" operation="mknod" profile="thunderbird" name="/run/shm/org.chromium.viOLay" pid=20087 comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=2983 ouid=2983 (different /run/shm/ tmp dir everytime) Stale apparmor profile affecting latest security update? Looks like #887973 but that was claimed to have been fixed in a version far far away. /etc/apparmor.d/usr.bin.thunderbird, provided by this version of thunderbird, still references only /dev/shm: owner /dev/shm/org.chromium.* rw, # for Chromium IPC I note also this report: https://lists.dyne.org/lurker/message/20180918.101827.26f69559.de.html But users shouldn't be updating /etc/apparmor.d files that are the responsibility of the package. -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages thunderbird depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.28.1-1~bpo9+1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.2.1-6 ii libfontconfig12.13.0-5 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libgtk2.0-0 2.24.31-2 ii libjsoncpp1 1.7.4-3 ii libpango-1.0-01.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-0 1.40.5-1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxext6 2:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc22.21-2.1+b2 ii x11-utils 7.7+3+b1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages thunderbird recommends: ii hunspell-en-au [hunspell-dictionary] 1:5.2.5-1 ii hunspell-en-gb [hunspell-dictionary] 1:5.2.5-1 ii lightning 1:60.0-3~deb9u1 Versions of packages thunderbird suggests: ii apparmor 2.11.0-3+deb9u2 ii fonts-lyx 2.3.1-2-1~bpo9+1 ii libgssapi-krb5-2 1.15-1+deb9u1 -- no debconf information -- Tim Connors
Bug#905694: chromium: *** version in stable/security-updates still has video/ffmpeg bug that was closed 2 months ago
Package: chromium Version: 68.0.3440.75-1~deb9u1 Severity: normal Dear Maintainer, bugs 900533, 902909 have been long closed, but unforuntately that is completely irrelevant for those of us who are running stable and had a security update pushed on us that has broken most the the www's functionality: chromium: Installed: 68.0.3440.75-1~deb9u1 Candidate: 68.0.3440.75-1~deb9u1 Version table: 69.0.3497.12-1 1 1 http://ftp.debian.org/debian experimental/main amd64 Packages 68.0.3440.75-2 5 5 http://mirror.internode.on.net/pub/debian testing/main amd64 Packages 2 http://mirror.internode.on.net/pub/debian unstable/main amd64 Packages *** 68.0.3440.75-1~deb9u1 500 500 http://security.debian.org stable/updates/main amd64 Packages 100 /var/lib/dpkg/status 63.0.3239.84-1~deb9u1 500 500 http://mirror.internode.on.net/pub/debian stable/main amd64 Packages stable/updates is affected by this bug, and testing is uninstallable on a stable system. Downgrading all the way back to 63 is not exactly a secure solution. I have not yet verified whether it is safe to downgrade to a previously cached version 66.0.3359.117-1~deb9u1 that most people won't have available to them. Please ensure the fix is pushed to security updates in a timely fashion - it appears to have taken nearly 2 months so far if I understand the timelines correctly. -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages chromium depends on: ii libasound2 1.1.3-5 ii libatk1.0-0 2.28.1-1~bpo9+1 ii libatomic1 6.3.0-18+deb9u1 ii libavcodec57 7:3.2.12-1~deb9u1 ii libavformat577:3.2.12-1~deb9u1 ii libavutil55 7:3.2.12-1~deb9u1 ii libc62.24-11+deb9u3 ii libcairo21.14.8-1 ii libcups2 2.2.1-8+deb9u2 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdrm2 2.4.91-2~bpo9+1 ii libevent-2.0-5 2.0.21-stable-3 ii libexpat12.2.0-2+deb9u1 ii libflac8 1.3.2-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libicu57 57.1-6+deb9u2 ii libjpeg62-turbo 1:1.5.1-2 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1.1+deb9u1 ii libopenjp2-7 2.1.2-1.1+deb9u2 ii libopus0 1.2~alpha2-1 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libpci3 1:3.5.2-1 ii libpng16-16 1.6.28-1 ii libpulse010.0-1+deb9u1 ii libre2-3 20170101+dfsg-1 ii libsnappy1v5 1.1.3-3 ii libstdc++6 6.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libwebp6 0.5.2-1 ii libwebpdemux20.5.2-1 ii libwebpmux2 0.5.2-1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb1 1.12-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.14-1+deb9u1 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.29-2.1 ii libxss1 1:1.2.2-1 ii libxtst6 2:1.2.3-1 ii x11-utils7.7+3+b1 ii xdg-utils1.1.1-1+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages chromium recommends: ii fonts-liberation 1:1.07.4-2 ii libgl1-mesa-dri 17.3.9-1~bpo9+1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell pn chromium-widevine -- no debconf information
Bug#892080: bash-completion: cvs log ($mode=log) case disappeared?
Package: bash-completion Version: 1:2.1-4.3 Severity: normal I'm sure 'cvs log ' use to tab-complete , but it's clear why it doesn't: log|lo|rlog|rl) mode=log ;; But then no corresponding case for $mode=log. -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages bash-completion depends on: ii bash 4.4-5 ii dpkg 1.18.24 bash-completion recommends no packages. bash-completion suggests no packages. -- no debconf information
Bug#494060: htop: Feature Request: All CPUs display split across left/right
On Thu, 8 Feb 2018, Steve Cotton wrote: > On Thu, Aug 07, 2008 at 10:37:48AM +1000, Tim Connors wrote: > > Package: htop > > Version: 0.7-1 > > Severity: wishlist > > > > It would be nice if there was an option with "All CPUs" that could let > > it split horizontally between the left and right displays (even CPUs > > on left, odd on right) in order to minimise wasted blank space in that > > area at the top. As it is, I define all my CPUs manually, split > > across the left and right displays, but this falls down when I want to > > run htop on a machine with fewer (see bug #494057) or more CPUs. > > Hi Tim, > > This wishlist request is still open in Debian's BTS, but AFAICS it was > implemented in version 1.0 (and packaged as Debian version 1.0-1). Is > there anything left to do? Ah, cool, indeed that works. Yes, please close. -- Tim Connors
Bug#862136: Please add dm-cache/dm-cache-smq if using lvm
> Package: initramfs-tools > Version: 0.128 > Severity: wishlist > > Hi > > I use dmcache in order to speed up a RAID device. > > Please add this module if using lvm If I understand this correctly, this bug should be critical, not wishlist. A user does the obvious thing of adding an lvmcache in front of their root device, running dpkg-reconfigure initramfs-tools, but then finds their system is unbootable. lvm should either refuse to add a cache in front of the LV used currently as "/" (or there should be a bloody prominent message at the top of lvmcache(7), or adding dm_cache, dm_cache_mq and /usr/sbin/cache_check to the initramfs.
Bug#886299: /run/lvm/lvmpolld.socket: connect failed: No such file or directory
Package: lvm2 Version: 2.02.168-2 Severity: normal 498368,50> sudo pvmove -n dirac/home /dev/sda2 /dev/sdb1 /run/lvm/lvmpolld.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmpolld. Proceeding with polling without using lvmpolld. WARNING: Check global/use_lvmpolld in lvm.conf or the lvmpolld daemon state. /dev/sda2: Moved: 0.01% Hmm, did it start (sysvinit system here)? 498325,26> l /etc/rc*/*lvm* lrwxrwxrwx 1 root root 22 Jun 16 2017 /etc/rc0.d/K01lvm2-lvmetad -> ../init.d/lvm2-lvmetad lrwxrwxrwx 1 root root 23 Jun 16 2017 /etc/rc0.d/K01lvm2-lvmpolld -> ../init.d/lvm2-lvmpolld lrwxrwxrwx 1 root root 22 Jun 16 2017 /etc/rc1.d/K01lvm2-lvmetad -> ../init.d/lvm2-lvmetad lrwxrwxrwx 1 root root 23 Jun 16 2017 /etc/rc1.d/K01lvm2-lvmpolld -> ../init.d/lvm2-lvmpolld lrwxrwxrwx 1 root root 22 Oct 17 17:27 /etc/rc2.d/S02lvm2-lvmetad -> ../init.d/lvm2-lvmetad lrwxrwxrwx 1 root root 23 Oct 17 17:27 /etc/rc2.d/S02lvm2-lvmpolld -> ../init.d/lvm2-lvmpolld lrwxrwxrwx 1 root root 22 Oct 17 17:27 /etc/rc3.d/S02lvm2-lvmetad -> ../init.d/lvm2-lvmetad lrwxrwxrwx 1 root root 23 Oct 17 17:27 /etc/rc3.d/S02lvm2-lvmpolld -> ../init.d/lvm2-lvmpolld lrwxrwxrwx 1 root root 22 Oct 17 17:27 /etc/rc4.d/S02lvm2-lvmetad -> ../init.d/lvm2-lvmetad lrwxrwxrwx 1 root root 23 Oct 17 17:27 /etc/rc4.d/S02lvm2-lvmpolld -> ../init.d/lvm2-lvmpolld lrwxrwxrwx 1 root root 22 Oct 17 17:27 /etc/rc5.d/S02lvm2-lvmetad -> ../init.d/lvm2-lvmetad lrwxrwxrwx 1 root root 23 Oct 17 17:27 /etc/rc5.d/S02lvm2-lvmpolld -> ../init.d/lvm2-lvmpolld lrwxrwxrwx 1 root root 22 Jun 16 2017 /etc/rc6.d/K01lvm2-lvmetad -> ../init.d/lvm2-lvmetad lrwxrwxrwx 1 root root 23 Jun 16 2017 /etc/rc6.d/K01lvm2-lvmpolld -> ../init.d/lvm2-lvmpolld lrwxrwxrwx 1 root root 14 Oct 17 17:27 /etc/rcS.d/S06lvm2 -> ../init.d/lvm2 yep: 498481,6> sudo less /var/log/boot ... Thu Jan 4 03:52:03 2018: [] Starting LVM2 poll daemon: lvmpolld^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. Thu Jan 4 03:52:03 2018: /dev/mcelog not active Thu Jan 4 03:52:03 2018: [] Starting LVM2 metadata daemon: lvmetad^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. ... No other failure log messages in /var/log/messages But yet, no lvmpoll: 498327,28> sudo ls -lA /run/lvm total 0 srwx-- 1 root root 0 Jan 4 03:52 lvmetad.socket 0-0-15:00:34, Thu Jan 04 tconnors@dirac:~ (bash) ok, let's restart it: 498328,29> sudo /etc/init.d/lvm2-lvmpolld restart [ ok ] Restarting LVM2 poll daemon: lvmpolld. 0-0-15:00:43, Thu Jan 04 tconnors@dirac:~ (bash) 498329,30> ps axuf | grep lvm root 3204 0.0 0.0 248508 796 ?Ssl 03:52 0:00 /sbin/lvmetad tconnors 17249 0.0 0.0 20164 3000 pts/11 S+ 03:56 0:00 | | \_ man lvmcache tconnors 26929 0.0 0.0 20164 3072 pts/13 S+ 04:36 0:00 | | \_ man lvmcache tconnors 18076 0.0 0.0 11508 1000 pts/19 S+ 15:00 0:00 | \_ grep --color=auto lvm root 17977 0.0 0.0 27308 228 ?Ss 15:00 0:00 /sbin/lvmpolld -t 60 0-0-15:00:47, Thu Jan 04 tconnors@dirac:~ (bash) 498330,31> sudo ls -lA /run/lvm total 0 srwx-- 1 root root 0 Jan 4 03:52 lvmetad.socket srwx-- 1 root root 0 Jan 4 15:00 lvmpolld.socket -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lvm2 depends on: ii dmeventd 2:1.02.137-2 ii dmsetup 2:1.02.137-2 ii init-system-helpers 1.48 ii libblkid1 2.29.2-1 ii libc6 2.24-11+deb9u1 ii libdevmapper-event1.02.1 2:1.02.137-2 ii libdevmapper1.02.12:1.02.137-2 ii liblvm2app2.2 2.02.168-2 ii libreadline5 5.2+dfsg-3+b1 ii libudev1 234-3~bpo9+1 ii lsb-base 9.20161125 lvm2 recommends no packages. Versions of packages lvm2 suggests: pn thin-provisioning-tools -- no debconf information
Bug#797036: iproute2: ss not reporting any listening udp sockets
00 7292 2 dadf7340 0 88: :03B2 : 07 : 00: 00 4725 2 dadf62c0 0 120: :C9D2 : 07 : 00: 1100 8573 2 dadf7b80 0 143: 0000:14E9 : 07 : 00: 1100 8571 2 dadf78c0 0 167: :0801 : 07 : 00: 00 7237 2 dadf6b00 0 183: :E411 : 07 : 00: 00 7246 2 dadf6dc0 0 0-0-18:25:21, Sat Dec 30 tconnors@pi:~ (bash) 9234,6> sudo ss -anu State Recv-Q Send-Q Local Address:Port Peer Address:Port -- Tim Connors
Bug#881892: perl-base: File::Glob(3perl) bsd_glob does not document DEFAULT_FLAGS
Package: perl-base
Version: 5.24.1-3+deb9u2
Severity: normal
In the one argument form of File::Glob::bsd_glob, the default flags
are not documented. They appear to be GLOB_CSH, although the
documentation for GLOB_NOCASE talks about different behaviour on OSX,
ie the one argument form looks to be nearly equivalent to:
$homedir = bsd_glob('~gnat', GLOB_CSH); # !OSX
or
$homedir = bsd_glob('~gnat', GLOB_CSH | GLOB_NOCASE); # OSX
This has supposedly been fixed, but since I don't have the git tree handy, I
can't check what the supposed fix is:
http://grokbase.com/t/perl/perl5-porters/11cybe0n6v/perl-107296-file-glob-bsd-glob-undocumented-default-flags
-- System Information:
Debian Release: 9.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages perl-base depends on:
ii dpkg 1.18.24
ii libc6 2.24-11+deb9u1
perl-base recommends no packages.
Versions of packages perl-base suggests:
ii perl 5.24.1-3+deb9u2
-- no debconf information
Bug#816872: wmbattery: memory leak in wmbattery
> Package: wmbattery > Version: 2.50-1+b1 > Followup-For: Bug #816872 > > Dear Maintainer, > > Memory bug is still present, nice app though overall, thanks. Hi, this just killed my system (13GB RSS, 20GB VMM). Oct 19 22:46:35 dirac kernel: [163443.300793] Killed process 12027 (wmbattery) total-vm:20361464kB, anon-rss:12105144kB, file-rss:728kB, shmem-rss:0kB Since there's no activity on this bug since March 2016, could the maintainers please arrange for this to be removed from debian? -- Tim Connors
Bug#683772: gpscorrelate: provide a --force option to overwrite existing GPS tags
Hi Mònica, A patch has been supplied for this bug a long time ago, but hasn't been acknowledged yet. Are you able to look at this please? -- Tim Connors
Bug#873495: xmms2-scrobbler: Better usage in the manpage
Package: xmms2-scrobbler Version: 0.4.0-4 Severity: normal It would be nice if the manpage showed how to use it, rather than requiring the user to in order 1) google, 2) read the README (it's been a few years since I had to resort to upstream's README, since that information is not usually relevant to packaged software). Possibly just duplicate the information: First, you need to set up XMMS2-Scrobbler's config files. Config values that are specific to the AudioScrobbler server go in ~/.config/xmms2/clients/xmms2-scrobbler/$SERVER_NAME/config. You will usually have .../clients/xmms2-scrobbler/lastfm/config and maybe .../clients/xmms2-scrobbler/librefm/config. These server-specific config files contain your username and password and the URL to use: mkdir ~/.config/xmms2/clients/xmms2-scrobbler/lastfm echo -e "user: foo\npassword: bar\nhandshake_url: http://post.audioscrobbler.com\n"; > \ ~/.config/xmms2/clients/xmms2-scrobbler/lastfm/config For libre.fm, use handshake_url: http://turtle.libre.fm Optionally, if you're behind a proxy, you'll need to tell XMMS2-Scrobbler about that proxy. This information applies to all servers and so goes in .../clients/xmms2-scrobbler/config. echo -e "proxy: my.proxy\nproxy_port: 8080\n" >> \ ~/.config/xmms2/clients/xmms2-scrobbler/config Perhaps the symlink is necessary too. I set it up, but then presumably got bitten by bug #798099 (which has a patch!) -- System Information: Debian Release: 8.8 APT prefers stable APT policy: (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xmms2-scrobbler depends on: ii libc6 2.24-5 ii libcurl37.38.0-4+deb8u5 ii libxmmsclient6 0.8+dfsg-17 xmms2-scrobbler recommends no packages. Versions of packages xmms2-scrobbler suggests: ii xmms2-core 0.8+dfsg-17 -- no debconf information
Bug#865841: smartmontools: induces kernel message: "FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE"
Package: smartmontools Version: 6.5+svn4324-1~bpo8+1 Severity: normal smartd and manual invocations of smartctl on my external Seagate Momentus 5400.5 controller cause this kernel message to spam my syslogs: Jun 25 16:55:28 fs kernel: [1443893.546323] sd 10:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE Jun 25 16:55:28 fs kernel: [1443893.546341] sd 10:0:0:0: [sdf] tag#0 Sense Key : Hardware Error [current] [descriptor] Jun 25 16:55:28 fs kernel: [1443893.546351] sd 10:0:0:0: [sdf] tag#0 Add. Sense: No additional sense information Jun 25 16:55:28 fs kernel: [1443893.546364] sd 10:0:0:0: [sdf] tag#0 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00 The kernel folk keep pointing the finger at userspace, specifically udisks2. I don't believe I'm using udisks2: fs:/home/tconnors# dpkg --get-selections | grep udisk libudisks2-0:amd64 install udisks2 deinstall https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1618678 https://bugs.freedesktop.org/show_bug.cgi?id=98991 https://bugzilla.kernel.org/show_bug.cgi?id=153241 debian bugs 858416 858141 are the udisks equivalent bugs smartctl otherwise seems to work: fs:/home/tconnors# smartctl -a /dev/sdf smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-0.bpo.3-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Seagate Momentus 5400.5 Device Model: ST9160310AS Serial Number:5SV1ELVY LU WWN Device Id: 5 000c50 00e473341 Firmware Version: DE04 User Capacity:160,041,885,696 bytes [160 GB] Sector Size: 512 bytes logical/physical Device is:In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 2.6, 3.0 Gb/s Local Time is:Sun Jun 25 16:59:24 2017 AEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection:(0) seconds. Offline data collection capabilities:(0x73) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. No Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 1) minutes. Extended self-test routine recommended polling time:( 60) minutes. Conveyance self-test routine recommended polling time:( 2) minutes. SCT capabilities: (0x103f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 104 099 006Pre-fail Always - 6393100 3 Spin_Up_Time0x0003 099 092 085Pre-fail Always - 0 4 Start_Stop_Count0x0032 083 083 020Old_age Always - 17605 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 080 060 030Pre-fail Always - 116739584 9 Power_On_Hours 0x0032 073 073 000Old_age Always - 23866 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 1 12 Power_Cycle_Count 0x0032 094 094
Bug#844285: pidgin: steals (warps) mouse cursor (not just focus) when new message comes in [SEC=UNCLASSIFIED]
Fvwm, only relevant configuration:
Style "Pidgin" Sticky
(plus other sensible defaults like focus-follows-mouse, no AutoRaise or
anything silly like that)
I long ago set a plugin option to disable pidgin setting new notifications
because it was so unusable (though this means I don't get notified anymore
other than a tiny little icon on a window that's usually lowered, so on
the whole jabber has become mostly useless to me). I think the option
was:
tools->plugins->message notification->"present conversation window"
("raise conversation window" would have already been off by default).
I'm pretty sure "Set window manager URGENT hint" was already off by
default. I might expect URGENT to focus a window, and I'd definitely
expect that without it, a new window popped up would just follow the
window manager policy for focus, which in my case, doesn't steal
focus or warp the mouse pointer.
Here's message notification plugin's prefs as they now are:
I'm not currently in a position to test setting method_raise back on, or
checking what the defaults are, because our jabber server is broken for
unrelated reasons.
> From: John Paul Adrian Glaubitz
>
> I have been using Pidgin for years and I never observed this behavior on any
> desktop or window manager. Whenever I received a new message (currently using
> KDE), the systray icon changes to indicate a new message. But the cursor focus
> remains unchanged.
>
> Could you give a bit more detail on your environment, particularly which
> desktop
> or window manager you are using? I suspect an issue with your particular
> setup.
>
>
> Package: pidgin
> Followup-For: Bug #844285
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
> Read the bugreport
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
> For what it's worth. I have also been using Pidgin (on XFCE4) for years.
> Never observed the mentioned bug.
>
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
--
Tim Connors
Bug#849373: xmms2: doesn't start: libglib version dependencies
Package: xmms2
Version: 0.8+dfsg-17
Severity: normal
Like bug #522280:
446069,40> xmms2d
xmms2d is build against version 2.50,
but is (runtime) linked against 2.48.
Refusing to start.
But what's most annoying other than the grammatical error is the
complete lack of statement of what it's failed to runtime link
against. Version 2.50 of *what*?
Clearly the the error message should be fixed for the next time this
versioning bug reoccurs to read (I presume I'm looking at a current
version of the source):
if (glib_major_version != GLIB_MAJOR_VERSION ||
glib_minor_version < GLIB_MINOR_VERSION) {
g_print ("xmms2d is built against version %d.%d of libglib,\n"
"but is (runtime) linked against %d.%d.\n"
"Refusing to start.\n",
GLIB_MAJOR_VERSION, GLIB_MINOR_VERSION,
glib_major_version, glib_minor_version);
exit (EXIT_FAILURE);
}
-- System Information:
Debian Release: 8.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages xmms2 depends on:
ii xmms2-client-cli 0.8+dfsg-17
ii xmms2-core0.8+dfsg-17
ii xmms2-icon0.8+dfsg-17
ii xmms2-plugin-alsa [xmms2-plugin-output] 0.8+dfsg-17
ii xmms2-plugin-ao [xmms2-plugin-output] 0.8+dfsg-17
ii xmms2-plugin-ices [xmms2-plugin-output] 0.8+dfsg-17
ii xmms2-plugin-id3v20.8+dfsg-17
ii xmms2-plugin-jack [xmms2-plugin-output] 0.8+dfsg-17
ii xmms2-plugin-mad 0.8+dfsg-17
ii xmms2-plugin-oss [xmms2-plugin-output]0.8+dfsg-17
ii xmms2-plugin-pulse [xmms2-plugin-output] 0.8+dfsg-17
ii xmms2-plugin-vorbis 0.8+dfsg-17
xmms2 recommends no packages.
xmms2 suggests no packages.
-- no debconf information
Bug#844285: pidgin: steals (warps) mouse cursor (not just focus) when new message comes in [SEC=UNCLASSIFIED]
Package: pidgin Version: 2.11.0-0+deb8u1 Severity: grave Tags: security Justification: user security hole Dear Maintainer, Like bugs #399786 and #518339, the mouse is warped to an open conversation window when a new message comes into that conversation. Typing a password at the time, and your password gets entered into that conversation. Never steal focus - there is never any valid reason for it. Especially not something as unimportant as a chat program. There appears to be no setting in preferences or plugins to disable this brain damage. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.4-040804-generic (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pidgin depends on: ii gconf2 3.2.6-3 ii libatk1.0-0 2.14.0-1 ii libc6 2.23-5 ii libcairo2 1.14.0-2.1+deb8u1 ii libdbus-1-3 1.10.10-1 ii libdbus-glib-1-20.102-1 ii libfontconfig1 2.11.0-6.3+deb8u1 ii libfreetype62.5.2-3+deb8u1 ii libgadu31:1.12.0-5 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u5 ii libglib2.0-02.48.0-1~bpo8+1 ii libgstreamer0.10-0 0.10.36-1.5 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libgtkspell02.0.16-1.1 ii libice6 2:1.0.9-1+b1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpurple0 2.11.0-0+deb8u1 ii libsm6 2:1.2.2-1+b1 ii libx11-62:1.6.2-3 ii libxml2 2.9.1+dfsg1-5+deb8u3 ii libxss1 1:1.2.2-1 ii perl-base [perlapi-5.20.2] 5.20.2-3+deb8u6 ii pidgin-data 2.11.0-0+deb8u1 Versions of packages pidgin recommends: ii gstreamer0.10-alsa 0.10.36-2 pn gstreamer0.10-ffmpeg ii gstreamer0.10-plugins-base 0.10.36-2 ii gstreamer0.10-plugins-good 0.10.31-3+nmu4+b1 Versions of packages pidgin suggests: ii libsqlite3-0 3.8.7.1-1+deb8u2 -- no debconf information
Bug#837997: novnc: launch.sh missing
Package: novnc Version: 1:0.4+dfsg+1+20131010+gitf68af8af3d-4 Severity: important utils/launch.sh isn't included in the debian package. Justification for important tag: /usr/share/doc/novnc/README.md.gz refers to launch.sh. All documentation on the web refers to launch.sh. Without it, I don't seem to be able to find a way to launch the server, and thus the package seems unusable. Similar ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/novnc/+bug/1492351 -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages novnc depends on: ii adduser 3.113+nmu3 ii dpkg 1.18.3 ii libjs-swfobject 2.2+dfsg-1 ii python 2.7.9-1 ii python-novnc 1:0.4+dfsg+1+20131010+gitf68af8af3d-4 ii python-numpy 1:1.11.0-1 ii websockify 0.6.0+dfsg1-1 Versions of packages novnc recommends: pn python-nova novnc suggests no packages. -- no debconf information
Bug#805355: Garmin edge 510/810 in gpsbabel
Hi Mikolaj, maintainer, I suspect this bug might be fixed already upstream, but maybe not in a release: http://www.gpsbabel.org/changes.html 2015-03-22 Adapt to Edge 510's mutation of Garmin Fit to deal with sample provided by James Morris. There is no actual release listed after that date in the changelog, but maybe it's implicit in there already being a 1.5.3 already available. -- Tim Connors
Bug#830687: linux-image-4.5.0-0.bpo.2-amd64: livelock on reading /proc/mounts
Package: src:linux
Version: 4.5.4-1~bpo8+1
Severity: normal
NFS seems to have been getting progressively less and less reliable in
kernels>~4.0. The latest manifestation on that for me is that having
an remote NFS machine go down today, and even after it came back up,
50 instances of /usr/lib/sysstat/sadc (5 minute cronjob) and a dozen
df's are stuck on the machine trying to access that remote mount.
What are they stuck on? strace shows they're not succeeding in
reading /etc/mtab = /proc/mounts:
...
open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f67f044e000
read(3, 0-2-19:08:40, Sun Jul 10 root@dirac:/home/tconnors (bash)
73854,15> l /etc/mtab
lrwxrwxrwx 1 root root 12 May 29 17:00 /etc/mtab -> /proc/mounts
Indeed, cat /proc/mounts doesn't return.
73855,16> ps axuf | grep proc.mounts
...
tconnors 23264 0.0 0.0 10632 760 pts/53 D19:00 0:00
| \_ cat /proc/mounts
...
73856,17> cat /proc/23264/stack
[] call_rwsem_down_read_failed+0x14/0x30
[] m_start+0x1d/0x80
[] seq_read+0x16b/0x3a0
[] vfs_read+0x81/0x120
[] SyS_read+0x52/0xc0
[] system_call_fast_compare_end+0xc/0x6b
[] 0x
-- Package-specific info:
** Version:
Linux version 4.5.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc version
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.5.4-1~bpo8+1 (2016-05-13)
** Command line:
BOOT_IMAGE=/vmlinuz-4.5.0-0.bpo.2-amd64 root=/dev/mapper/dirac-root ro
zswap.enabled=1
** Tainted: POE (12289)
* Proprietary module has been loaded.
* Out-of-tree module has been loaded.
* Unsigned module has been loaded (currently expected).
** Kernel log:
[1112649.367575] [] ? filename_lookup+0xb1/0x180
[1112649.367581] [] ? nfs_statfs+0x79/0x180 [nfs]
[1112649.367582] [] ? getname_flags+0x6f/0x1e0
[1112649.367584] [] ? user_statfs+0x3f/0xa0
[1112649.367586] [] ? SYSC_statfs+0x20/0x50
[1112649.367587] [] ? SYSC_newstat+0x39/0x60
[1112649.367589] [] ? system_call_fast_compare_end+0xc/0x6b
[1112649.367592] INFO: task sadc:11346 blocked for more than 120 seconds.
[1112649.367592] Tainted: P OE 4.5.0-0.bpo.2-amd64 #1
[1112649.367593] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[1112649.367594] sadcD 0001 0 11346 11345
0x
[1112649.367596] 8800ca7a5180 880108246140 8803f6414000
8803f6413bb0
[1112649.367597] 81a88a18 81a88a00
0002
[1112649.367599] 815b6451 8800ca7a5180 815b8efc
8803f6413b50
[1112649.367600] Call Trace:
[1112649.367602] [] ? schedule+0x31/0x80
[1112649.367603] [] ? rwsem_down_write_failed+0x20c/0x340
[1112649.367610] [] ? nfs4_proc_lookup_common+0xbf/0x3b0
[nfsv4]
[1112649.367611] [] ? call_rwsem_down_write_failed+0x13/0x20
[1112649.367612] [] ? down_write+0x29/0x40
[1112649.367614] [] ? mnt_set_expiry+0x19/0x30
[1112649.367620] [] ? nfs_d_automount+0xb9/0x1b0 [nfs]
[1112649.367622] [] ? follow_managed+0x131/0x2d0
[1112649.367623] [] ? lookup_fast+0x12b/0x320
[1112649.367625] [] ? walk_component+0x46/0x480
[1112649.367627] [] ? path_lookupat+0x5d/0x110
[1112649.367628] [] ? filename_lookup+0xb1/0x180
[1112649.367633] [] ? nfs_statfs+0x79/0x180 [nfs]
[1112649.367635] [] ? getname_flags+0x6f/0x1e0
[1112649.367637] [] ? user_statfs+0x3f/0xa0
[1112649.367638] [] ? SYSC_statfs+0x20/0x50
[1112649.367640] [] ? SYSC_newstat+0x39/0x60
[1112649.367641] [] ? system_call_fast_compare_end+0xc/0x6b
[1112828.668378] CPU1: Core temperature above threshold, cpu clock throttled
(total events = 3766348)
[1112828.668379] CPU5: Core temperature above threshold, cpu clock throttled
(total events = 3766345)
[1112828.668380] CPU6: Package temperature above threshold, cpu clock throttled
(total events = 5193799)
[1112828.668381] CPU2: Package temperature above threshold, cpu clock throttled
(total events = 5193796)
[1112828.668383] CPU7: Package temperature above threshold, cpu clock throttled
(total events = 5193801)
[1112828.668384] CPU3: Package temperature above threshold, cpu clock throttled
(total events = 5193800)
[1112828.668386] CPU4: Package temperature above threshold, cpu clock throttled
(total events = 5193790)
[1112828.668387] CPU0: Package temperature above threshold, cpu clock throttled
(total events = 5193801)
[1112828.668388] CPU5: Package temperature above threshold, cpu clock throttled
(total events = 5193798)
[1112828.668392] mce_notify_irq: 2 callbacks suppressed
[1112828.668393] mce: [Hardware Error]: Machine check events logged
[1112828.668399] CPU1: Package temperature above threshold, cpu clock throttled
(total events = 5193803)
[1112828.668401] mce: [Hardware Error]: Machine check events logged
[1112828.670364] CPU1: Core temperature/speed normal
[1112828.670365] CPU5: Core temperature/speed normal
[1113128.672718]
Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Missing init-script(s)?
DDs - any news on this? zfsutils_0.6.5.7-8-jessie_amd64.deb from ZoL contained amongst others: -rwxr-xr-x root/root 2871 2016-05-20 08:59 ./etc/init.d/zfs-zed -rwxr-xr-x root/root 5623 2016-05-20 08:59 ./etc/init.d/zfs-mount -rwxr-xr-x root/root 2262 2016-05-20 08:59 ./etc/init.d/zfs-share -rwxr-xr-x root/root 5100 2016-05-20 08:59 ./etc/init.d/zfs-import This was sufficient to ensure my pools were all imported and mounted on the systems I've banished systemd from for reliability reasons. Alas, all that zfsutils-linux in debian contains in the whole of /etc/ are: 168691,5> dpkg -L zfsutils-linux | grep /etc/ /etc/cron.d /etc/cron.d/zfsutils-linux /etc/default /etc/default/zfs /etc/zfs /etc/zfs/zfs-functions (we've also lost: -rw-r--r-- root/root 11305 2016-05-20 08:52 ./etc/bash_completion.d/zfs ) -- Tim Connors
Bug#734688: Logs are not rotated for a month
On Wed, 16 Dec 2015, Michael Gebetsroither wrote: > Package: logrotate > Version: 3.8.7-1+b1 > Followup-For: Bug #734688 > > Dear Maintainer, > > Seconded, the problem still persists in jessie. > Logrotate was practically broken after /var/log got full a month ago. > > There where various .log.1.gz files, most of which where 0 bytes which > stopped logrotate to act on those files completely. > > # grep 'error creating output file' logrotate_force_20151216.log > error: error creating output file /var/log/dpkg.log.1.gz: File exists > error: error creating output file /var/log/alternatives.log.1.gz: File exists > error: error creating output file /var/log/nginx/error.log.1.gz: File exists > error: error creating output file /var/log/nginx/access.log.1.gz: File exists > error: error creating output file /var/log/php5-fpm.log.1.gz: File exists > error: error creating output file /var/log/syslog.1.gz: File exists > error: error creating output file /var/log/daemon.log.1.gz: File exists > error: error creating output file /var/log/auth.log.1.gz: File exists > error: error creating output file /var/log/messages.1.gz: File exists And in my case, it wasn't a 0 byte file - there was syslog.1 and syslog.1.gz, both largish. It is possible gzip simply failed the first time because I ran out of space. 2 observations: 1) logrotate didn't output any diagnostics, or exit non zero. Consequently, I noticed nothing in my cron.daily email for a month. I only noticed when a usb failure meant the syslog file grew enormously, and I saw the top of the messages were from a month prior. 2) All these suggestions of heuristics about deleting a file if 0 sized and created immediately before etc. Why not just, when logrotate finds a base file whose .gz already exists, recursively call itself again to start rotating down to the current file, which can then be compressed and resume where we were? Sorry no patches, already after my bedtime, and this has already been languishing in my todo list for a couple of weeks. -- Tim Connors
Bug#642204: xmms2-plugin-pls: File names in m3u playlist to be imported containing parenthesis will cause an abort of import.
Similarly, a .m3u file containing a blank line also exhibits the same error: 414981,22> cat '/home/tconnors/sshfs/fs/snapshots/dirachome/2016-03-15 08:00:22/home/tconnors/streaming_radio/doublej.m3u' #https://radio.abc.net.au/help/streams http://radio1.internode.on.net:8000/132 #http://live-radio01.mediahubaustralia.com:8034/ #http://live-radio02.mediahubaustralia.com:8034/ http://live-radio01.mediahubaustralia.com/DJDW/mp3/ http://live-radio02.mediahubaustralia.com/DJDW/mp3/ 414982,23> xmms2 stop ; xmms2 clear ; xmms2 addpls '/home/tconnors/sshfs/fs/snapshots/dirachome/2016-03-15 08:00:22/home/tconnors/streaming_radio/doublej.m3u' ; xmms2 play ; sleep 5 ; xmms2 list Total playtime: 0:00:00 xmms2d -vvv gives the following output on that above file: 23:58:34 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'mms' 23:58:34 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'icymetaint' 23:58:34 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'ofa' 23:58:34 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'vorbis' 23:58:34 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'normalize' 23:58:34 DEBUG: ../src/xmms/xform.c:349: Freeing xform 'file' 23:58:34 ERROR: ../src/xmms/xform.c:1341: Couldn't set up chain for 'file:///home/tconnors/sshfs/fs/snapshots/dirachome/2345/home/tconnors/streaming_radio/' (18417) 23:58:34 DEBUG: ../src/xmms/xform.c:349: Freeing xform 'unknown' 23:58:34 DEBUG: ../src/xmms/mediainfo.c:155: got 0 as not resolved 23:58:34 DEBUG: ../src/xmms/ipc.c:288: disconnect was true! 23:58:34 DEBUG: ../src/xmms/ipc.c:404: Destroying client! 23:58:34 DEBUG: ../src/xmms/ipc.c:288: disconnect was true! 23:58:34 DEBUG: ../src/xmms/ipc.c:404: Destroying client! 23:58:34 DEBUG: ../src/xmms/ipc.c:494: Client connected But if I remove the extra newline, 414983,24> cat '/home/tconnors/streaming_radio/doublej.m3u' #https://radio.abc.net.au/help/streams http://radio1.internode.on.net:8000/132 #http://live-radio01.mediahubaustralia.com:8034/ #http://live-radio02.mediahubaustralia.com:8034/ http://live-radio01.mediahubaustralia.com/DJDW/mp3/ http://live-radio02.mediahubaustralia.com/DJDW/mp3/ 414988,29> xmms2 stop ; xmms2 clear ; xmms2 addpls '/home/tconnors/streaming_radio/doublej.m3u' ; xmms2 play ; sleep 5 ; xmms2 list ->[1/13572] - ABC Dig Music () [2/18088] - Double J NSW () [3/18089] - Double J NSW () Total playtime: 0:00:00 it succeeded: 00:03:40 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'normalize' 00:03:40 DEBUG: ../src/xmms/xform.c:634: Collecting metadata from file 00:03:40 DEBUG: ../src/xmms/xform.c:634: Collecting metadata from magic 00:03:40 INFO: ../src/xmms/xform.c:1364: Successfully setup chain for 'file:///home/tconnors/streaming_radio/doublej.m3u' (0) containing file:magic:m3u 00:03:40 DEBUG: ../src/xmms/xform.c:349: Freeing xform 'm3u' 00:03:40 DEBUG: ../src/xmms/xform.c:349: Freeing xform 'magic' 00:03:40 DEBUG: ../src/xmms/xform.c:349: Freeing xform 'file' 00:03:40 DEBUG: ../src/xmms/xform.c:349: Freeing xform 'unknown' 00:03:40 DEBUG: ../src/xmms/playlist.c:190: PLAYLIST: updated chg! ... 00:03:40 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'ofa' 00:03:40 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'vorbis' 00:03:40 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'normalize' 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:220: Using version 7.38.0 of libcurl 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: HTTP/1.1 200 OK 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: Server: nginx/1.7.8 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: Date: Sat, 30 Apr 2016 14:03:40 GMT 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: Content-Type: audio/mpeg 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: Transfer-Encoding: chunked 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: Connection: keep-alive 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: Keep-Alive: timeout=10 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: icy-br: 96 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: icy-genre: Misc 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: icy-name: Double J NSW 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: icy-notice1: This stream requires http://www.winamp.com";>Winamp 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: icy-notice2: SHOUTcast DNAS/posix(linux x64) v2.4.7.256 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: icy-pub: 0 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: icy-url: http://www.abc.net.au/radio 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: Cache-Control: no-cache 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: icy-metaint: 16384 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:492: 00:03:40 DEBUG: ../src/plugins/curl/curl_http.c:300: icy-metadata detected 00:03:40 DEBUG: ../src/xmms/xform.c:1248: Not in one of 4 goal-types 00:03:40 DEBUG: ../src/xmms/xform.c:1158: Trying plugin 'visualization' -- Tim Connors
Bug#798830: dmucs: race condition in start scripts prevents loadavg starting
Package: dmucs
Version: 0.6.1-2.1
Severity: important
I've been wondering for years why dmucs never worked in my network.
Finally traced the start scripts:
if start_server && server_running ; then
...
if start_loadavg && running ; then
start_server and start_loadavg don't create a valid PID file for some
indeterminate time after start-stop-daemon fork off a dmucs/loadavg
process.
+ log_daemon_msg 'Starting dmucs distcc coordinator ' dmucs
+ '[' -z 'Starting dmucs distcc coordinator ' ']'
+ log_daemon_msg_pre 'Starting dmucs distcc coordinator ' dmucs
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ '[' -t 1 ']'
+ '[' xxterm '!=' x ']'
+ '[' xxterm '!=' xdumb ']'
+ '[' -x /usr/bin/tput ']'
+ '[' -x /usr/bin/expr ']'
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ '[' -z ']'
+ FANCYTTY=1
+ case "$FANCYTTY" in
+ true
+ echo -n '[] '
[] + '[' -z dmucs ']'
+ echo -n 'Starting dmucs distcc coordinator : dmucs'
Starting dmucs distcc coordinator : dmucs+ log_daemon_msg_post 'Starting dmucs
distcc coordinator ' dmucs
+ :
+ server_running
+ '[' '!' -f /var/run/dmucs.pid ']'
+ return 1
+ start_server
+ start-stop-daemon --background --make-pidfile --start --pidfile
/var/run/dmucs.pid --exec /usr/sbin/dmucs --
+ errcode=0
+ return 0
+ server_running
+ '[' '!' -f /var/run/dmucs.pid ']'
+ return 1
+ log_end_msg 1
Bugger. Bails out with failure message instead of continuuing on to
start loadavg.
A quick "fix" is to:
if start_server && sleep 5 && server_running ; then
...
if start_loadavg && sleep 5 && running ; then
but surely there's a better way (eg, remove the test entirely, since
I've never seen any other init script do something like this).
-- System Information:
Debian Release: 7.8
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (5, 'testing'), (2,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.17.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dmucs depends on:
ii libc6 2.19-18
ii libgcc1 1:4.9.2-10
ii libstdc++6 4.9.2-10
dmucs recommends no packages.
dmucs suggests no packages.
-- Configuration Files:
/etc/default/dmucs changed:
SERVER=yes
USE_SERVER=dirac
DIETIME=5
/etc/dmucs.conf changed:
dirac 8 10
gamow 2 6
fs 4 3
maxwell 2 2
/etc/init.d/dmucs changed:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
NAME=dmucs
DAEMON=/usr/sbin/loadavg
NAME2=loadavg
DAEMON_WRAPPER=$DAEMON
DESC="dmucs client daemon"
PIDFILE=/var/run/dmucs_loadavg.pid
SERVER_DAEMON=/usr/sbin/dmucs
SERVER_DAEMON_WRAPPER=$SERVER_DAEMON
SERVER_NAME2=dmucs
SERVER_DESC="dmucs distcc coordinator"
SERVER_PIDFILE=/var/run/dmucs.pid
LOGDIR=/var/log/dmucs
test -x $DAEMON || exit 0
test -x $DAEMON_WRAPPER || exit 0
test -x $SERVER_DAEMON || exit 0
test -x $SERVER_DAEMON_WRAPPER || exit 0
. /lib/lsb/init-functions
DODTIME=10 # Time to wait for the server to die, in seconds
# If this value is set too low you might not
# let some servers to die gracefully and
# 'restart' will not work
LOGFILE=$LOGDIR/$NAME.log # Server logfile
DAEMONUSER=nobody
if [ -f /etc/default/$NAME ] ; then
. /etc/default/$NAME
fi
if [ -z "$USE_SERVER" -a ! "$SERVER" = "yes" ]; then
log_warning_msg "please edit /etc/default/$NAME to enable dmucs"
exit 0
fi
DAEMON_OPTS="-s $USE_SERVER"
SERVER_DAEMON_OPTS=""
set -e
running_pid() {
pid=$1
name=$2
[ -z "$pid" ] && return 1
[ ! -d /proc/$pid ] && return 1
cmd=`cat /proc/$pid/cmdline | tr "\000" "\n"|head -n 1 |cut -d : -f 1`
# Is this the expected server
[ "$cmd" != "$name" ] && return 1
return 0
}
running() {
# Check if the process is running looking at /proc
# (works for all users)
# No pidfile, probably no daemon present
[ ! -f "$PIDFILE" ] && return 1
pid=`cat $PIDFILE`
running_pid $pid $DAEMON_WRAPPER || return 1
return 0
}
server_running() {
# Check if the process is running looking at /proc
# (works for all users)
# No pidfile, probably no daemon present
[ ! -f "$SERVER_PIDFILE" ] && return 1
pid=`cat $SERVER_PIDFILE`
running_pid $pid $SERVER_DAEMON_WRAPPER || return 1
return 0
}
start_server() {
start-stop-daemon --background --make-pidfile --start --pidfile
$SERVER_PIDFILE --exec $SERVER_DAEMON -- $SERVER_DAEMON_OPTS
errcode=$?
return $errcode
}
start_loadavg() {
start-stop-daemon --background --make-pidfile --start --pidfile
$PIDFILE --exec $DAEMON -- $DAEMON_OPTS
errcode=$?
return $errcode
}
stop_loadavg() {
start-stop-daemon --make-pidfile --stop --pidfile $PIDFILE --exec
$DAEMON
errcode=$?
return $errcode
}
stop_server() {
start-sto
Bug#795970: systemd is a ridiculous tentacled mess that breaks the rest of the system when it inevitably falls over
On Thu, 20 Aug 2015, Martin Pitt wrote: > Hello, > > this is a conflation of a pointless rant (in the subject), > X.org/graphics driver problems without any details, and swapspace. > There are no actionable items here, thus I close this. > > Please have a look at dmesg, this almost surely sounds like a kernel > or driver problem that causes half of userspace to lock up. "D" is > "uninterruptible kernel sleep" indicating that a read() or similar > operation hangs forever in the kernel. > > It might also be related to swapspace trying to swap out memory to a > terribly slow disk. Either way, not a systemd problem. To quote Brian May on a local LUG mailing list: == Note this error happened in the unpacking phase, not the configuration phase. So I think it is unlikely dpkg has even looked at swapspace' postinst at this point. Also note the previous line is "Processing triggers for systemd". I note that swapspace doesn't have a preinst script. So I would speculate the problem is in the systemd trigger. (this being complicated so far has nothing to do with systemd, but rather the design of dpkg) Looking at /var/lib/dpkg/info/systemd.postinst I would speculate the trigger being called is after /etc/init.d is updated, it calls "systemctl daemon-reload" via a wrapper that checks /run/systemd/system exists first. The only time I have seen this happen myself is when systemd was already broken, because the kernel was too old and didn't have the required features. Possibly nothing wrong with the kernel here, however I have to wonder if systemd was already broken for some reason. Maybe it failed to start up correctly because something else was broken. -- Tim Connors
Bug#783096: fixed in ieee-data 20150531.1
On Sun, 31 May 2015, Luciano Bello wrote: > Source: ieee-data > Source-Version: 20150531.1 > > We believe that the bug you reported is fixed in the latest version of > ieee-data, which is due to be installed in the Debian FTP archive. ... > ieee-data (20150531.1) unstable; urgency=medium > . >* New iab.txt url updated. >* SSL connections disable, since standards.ieee.org uses TLS AIA and > many dowloaders do not support it. Closes: #783096, #779543. >* Files mam.txt and oui36.txt added. Hi, Shouldn't this be pushed to jessie-updates ? -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787820: chromium: Menus appear on wrong xinerama screen (possibly primary screen, unconditionally?)
Package: chromium Version: 43.0.2357.65-1 Severity: normal On a laptop with "main" display being an external screen, but the internal display still referred to as the primary screen, chromium menus appear unconditionally on the primary (laptop internal) screen, regardless of where the mouse is, where the chromium window is, and what the window manager policy is. This is a regression over previous versions, where the menu popped up in the obvious location, perhaps allowing the window manager to choose the appropriate location, or perhaps just following the parent window. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages chromium depends on: ii libasound2 1.0.27.1-2 ii libatk1.0-0 2.12.0-1 ii libc62.19-13 ii libcairo21.14.0-2.1 ii libcups2 1.7.1-2 ii libdbus-1-3 1.6.12-1 ii libexpat12.1.0-4 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.42.0-2 ii libgnome-keyring03.4.1-1 ii libgtk2.0-0 2.24.25-1 ii libharfbuzz0b0.9.29-1 ii libjpeg62-turbo 1:1.3.1-8 ii libnspr4 2:4.10.7-1 ii libnspr4-0d 2:4.10.7-1 ii libnss3 2:3.17-1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpci3 1:3.2.1-3 ii libspeechd2 0.7.1-6.2 ii libspeex11.2~rc1-7 ii libsrtp0 1.4.4+20100615~dfsg-2+deb7u1 ii libstdc++6 4.9.1-19 ii libx11-6 2:1.6.2-3 ii libxcomposite1 1:0.4.4-1 ii libxcursor1 1:1.1.13-1+deb7u1 ii libxdamage1 1:1.1.4-1 ii libxext6 2:1.3.2-1 ii libxfixes3 1:5.0.1-1 ii libxi6 2:1.6.1-1+deb7u1 ii libxml2 2.8.0+dfsg1-7+wheezy4 ii libxrandr2 2:1.4.2-1 ii libxrender1 1:0.9.8-1 ii libxslt1.1 1.1.26-14.1 ii libxss1 1:1.2.2-1 ii libxtst6 2:1.2.2-1+b1 ii x11-utils7.7+2 ii xdg-utils1.1.0~rc1+git20111210-6+deb7u3 chromium recommends no packages. Versions of packages chromium suggests: pn chromium-l10n -- no debconf information -- debsums errors found: sh: 1: /usr/sbin/dpkg-divert: not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784108: grep: optional non-blocking IO
Package: grep Version: 2.10-1 Severity: normal It'd be nice if grep has a non-blocking IO flag, so one could do eg this: tail -F /var/log/apache2/access.log | grep --non-blocking /tmp/ and have it filter in real-time rather than when the output buffer fills up. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grep depends on: ii dpkg 1.17.13 ii install-info 4.13a.dfsg.1-10 ii libc6 2.19-13 grep recommends no packages. Versions of packages grep suggests: ii libpcre3 1:8.31-5 -- no debconf information -- debsums errors found: sh: 1: /usr/sbin/dpkg-divert: not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783706: openshot forcefully keeps screensaver from triggering
Package: openshot Version: 1.4.3-1.1 Severity: normal While I had openshot open, not necessarily rendering or with a project open, I wasn't able to shut off my screen and keep it shut off for more than a few seconds with normal DPMS commands (eg, 'xset dpms force off'). Once I closed openshot, my screensaver functioned normally. I couldn't find anything obvious in the source (eg via references to xdg-screensaver, xset, *screensaver etc), so it's probably buried deep in a library somewhere, but a userspace program has no business deciding such policy. Especially just a video renderer, not a video player. See also an old bug #374644 for xine where they had similar craziness with screensavers. I really hope openshot isn't faking a keystroke! -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openshot depends on: ii fontconfig 2.9.0-7.1 ii gtk2-engines-pixbuf 2.24.25-1 ii librsvg2-common 2.36.1-2 ii melt 0.8.0-4 ii python 2.7.6-2 ii python-gtk2 2.24.0-3+b1 ii python-httplib2 0.7.4-2+deb7u1 ii python-imaging 1.1.7-4+deb7u1 ii python-mlt5 0.8.0-4 ii python-pygoocanvas 0.14.1-1+b3 ii python-support 1.0.15 ii python-xdg 0.19-5 Versions of packages openshot recommends: ii frei0r-plugins 1.1.22git20091109-1.2 pn openshot-doc Versions of packages openshot suggests: pn blender pn inkscape -- no debconf information -- debsums errors found: sh: 1: /usr/sbin/dpkg-divert: not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773575: ntp: CERT VU#852879
Package: ntp Version: 1:4.2.6.p5+dfsg-2 Severity: normal Tags: security Remotely exploitable, ntp user account only: http://www.kb.cert.org/vuls/id/852879 Debian listed as unknown here, but the versions checks out as vulnerable: http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=852879&SearchOrder=4 http://support.ntp.org/bin/view/Main/SecurityNotice -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ntp depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.13 ii libc62.19-12 ii libcap2 1:2.22-1.2 ii libedit2 2.11-20080614-5 ii libopts251:5.12-0.1 ii libssl1.0.0 1.0.1e-2+deb7u13 ii lsb-base 4.1+Debian8+deb7u1 ii netbase 5.0 Versions of packages ntp recommends: ii perl 5.20.1-2 Versions of packages ntp suggests: pn ntp-doc -- Configuration Files: /etc/ntp.conf changed [not included] -- no debconf information -- debsums errors found: sh: 1: /usr/sbin/dpkg-divert: not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765430: ldd: no version information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20)
On Wed, 15 Oct 2014, Andreas Metzler wrote: > On 2014-10-15 Tim Connors wrote: > > Package: libgcrypt20 > > Version: 1.6.2-4 > > Severity: normal > > > > Looks like dependencies on libgpg-error not specified correctly? > [...] > > This breaks the like of pasuspender: > > > > 361712,15> /usr/bin/pasuspender /bin/true > > /usr/bin/pasuspender: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version > > information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20) > > Hello, > You write "This breaks the like of pasuspender". - Are there are > negative effects apart from the warning message? It seems to work, but I'm getting sick of it filling up my inbox with cron messages (being a workaround to a pulseaudio bug of noise increasing over time) -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765430: ldd: no version information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20)
On Thu, 16 Oct 2014, Tim Connors wrote: > On Wed, 15 Oct 2014, Daniel Kahn Gillmor wrote: > > > On 10/14/2014 11:17 PM, Tim Connors wrote: > > > Package: libgcrypt20 > > > Version: 1.6.2-4 > > > Severity: normal > > > > > > Looks like dependencies on libgpg-error not specified correctly? > > > > > > 361711,14> ldd /lib/x86_64-linux-gnu/libgcrypt.so.20 > > > /lib/x86_64-linux-gnu/libgcrypt.so.20: > > > /lib/x86_64-linux-gnu/libgpg-error.so.0: no version information available > > > (required by /lib/x86_64-linux-gnu/libgcrypt.so.20) > > > linux-vdso.so.1 (0x7fff73dfc000) > > > libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 > > > (0x7f328620f000) > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3285e67000) > > > /lib64/ld-linux-x86-64.so.2 (0x7f3286719000) > > > > > > This breaks the like of pasuspender: > > > > > > 361712,15> /usr/bin/pasuspender /bin/true > > > /usr/bin/pasuspender: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version > > > information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20) > > > > fwiw, i don't think this is due to the fact that libgpg-error only > > recently (as of 1.14, i think) adding a GPG_ERROR_1.0 version node in > > its library symbols. > > > > I believe this should just be a warning, and not a hard error, though. > > > > See the discussion with libgpg-error upstream here: > > > > http://thread.gmane.org/gmane.linux.debian.alioth.pkg-gnupg.general/270 > > I don't know whether it's a diagnostic, but I just upgraded libgpg-error0 > from /stable to /unstable (1.10-3.1 to 1.16-2), and that got rid of the > ldd linker warning. Note that in that thread, "Our users will never see the warning message since packages built against the newer gpg-error will depend on it and packages built against the old one will not show the warning either. (I have not actually run any tests to verify this, but I guess you did.)" We do see the warning message, because the likes of a later version of libgcrypt doesn't appear to depend on the required version of libgpg-error (it depends on >= 1.10, whereas it appears from that discussion to have been built against >=1.15). -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765430: ldd: no version information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20)
On Wed, 15 Oct 2014, Daniel Kahn Gillmor wrote: > On 10/14/2014 11:17 PM, Tim Connors wrote: > > Package: libgcrypt20 > > Version: 1.6.2-4 > > Severity: normal > > > > Looks like dependencies on libgpg-error not specified correctly? > > > > 361711,14> ldd /lib/x86_64-linux-gnu/libgcrypt.so.20 > > /lib/x86_64-linux-gnu/libgcrypt.so.20: > > /lib/x86_64-linux-gnu/libgpg-error.so.0: no version information available > > (required by /lib/x86_64-linux-gnu/libgcrypt.so.20) > > linux-vdso.so.1 (0x7fff73dfc000) > > libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 > > (0x7f328620f000) > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3285e67000) > > /lib64/ld-linux-x86-64.so.2 (0x7f3286719000) > > > > This breaks the like of pasuspender: > > > > 361712,15> /usr/bin/pasuspender /bin/true > > /usr/bin/pasuspender: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version > > information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20) > > fwiw, i don't think this is due to the fact that libgpg-error only > recently (as of 1.14, i think) adding a GPG_ERROR_1.0 version node in > its library symbols. > > I believe this should just be a warning, and not a hard error, though. > > See the discussion with libgpg-error upstream here: > > http://thread.gmane.org/gmane.linux.debian.alioth.pkg-gnupg.general/270 I don't know whether it's a diagnostic, but I just upgraded libgpg-error0 from /stable to /unstable (1.10-3.1 to 1.16-2), and that got rid of the ldd linker warning. -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765430: ldd: no version information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20)
Package: libgcrypt20 Version: 1.6.2-4 Severity: normal Looks like dependencies on libgpg-error not specified correctly? 361711,14> ldd /lib/x86_64-linux-gnu/libgcrypt.so.20 /lib/x86_64-linux-gnu/libgcrypt.so.20: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20) linux-vdso.so.1 (0x7fff73dfc000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f328620f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3285e67000) /lib64/ld-linux-x86-64.so.2 (0x7f3286719000) This breaks the like of pasuspender: 361712,15> /usr/bin/pasuspender /bin/true /usr/bin/pasuspender: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20) -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgcrypt20 depends on: ii libc6 2.19-11 ii libgpg-error0 1.10-3.1 ii multiarch-support 2.13-38+deb7u4 libgcrypt20 recommends no packages. Versions of packages libgcrypt20 suggests: pn rng-tools -- no debconf information -- debsums errors found: sh: 1: /usr/sbin/dpkg-divert: not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765331: xserver-xorg-video-intel: occasional hangs in read from /dev/dri/card0 with "AccelMethod" "sna"
Package: xserver-xorg-video-intel Version: 2:2.99.916-1~exp1 Severity: important I'm running xserver-xorg-video-intel/experimental with Option "AccelMethod" "sna" because otherwise operation on haswell is incredibly unreliable (my latest problem being horible display corruption on webbrowsers with text). But I think in all versions of xserver-xorg-video-intel I've run, every now and then when coming home to a suspended screen, it doesn't wake up. I can ssh in and chvt 1, or I can run strace on the xorg process and the strace causes the xorg process to wake up (I think I see futex() calls in the first few lines but my eyes aren't quick enough, and I've not yet managed to remember to redirect the strace log to a file. However, this time, it hasn't woken up. Don't know whether it's the same bug or not, but here we go: 79151,46> strace -f -p 14075 Process 14075 attached with 4 threads - interrupt to quit [pid 14079] futex(0x7ffbe94db344, FUTEX_WAIT_PRIVATE, 503838665, NULL [pid 14078] futex(0x7ffbe94db2d4, FUTEX_WAIT_PRIVATE, 560566957, NULL [pid 14077] futex(0x7ffbe94db264, FUTEX_WAIT_PRIVATE, 759160725, NULL [pid 14075] read(9, 79152,47> l /proc/14075/fd/9 lrwx-- 1 root root 64 Oct 10 00:39 /proc/14075/fd/9 -> /dev/dri/card0 -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jul 3 2013 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2356320 Jul 18 08:25 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104M [GeForce GTX 670MX] [10de:11a1] (rev ff) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 12 -rw-r--r-- 1 root root 220 Jul 11 2013 20-backspace-terminate.conf -rw-r--r-- 1 root root 1842 Jul 7 2013 50-synaptics.conf -rw-r--r-- 1 root root 717 Sep 24 00:12 70-sna-accel.conf KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.14-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.14.15-2~bpo70+1 (2014-08-21) Xorg X server log files on system: -- -rw-r--r-- 1 root root 42264 Jul 9 2013 /var/log/Xorg.2.log -rw-r--r-- 1 root root 57523 Jul 14 2013 /var/log/Xorg.1.log -rw-r--r-- 1 root bumblebee 15344 Aug 30 21:47 /var/log/Xorg.8.log -rw-r--r-- 1 root root 36610 Oct 14 18:11 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 222.721] X.Org X Server 1.16.0 Release Date: 2014-07-16 [ 222.721] X Protocol Version 11, Revision 0 [ 222.721] Build Operating System: Linux
Bug#758288: libkrb5support0 should conflict libk5crypto3 from stable?
Package: libkrb5support0 Version: 1.12.1+dfsg-7 Severity: normal Dear Maintainer, On a somewhat unstable system with pinning back to stable (yes I know, sue me), with libkrb5support0 from unstable, libk5crypto3 from stable/updates and libapache2-mod-php5 from stable/updates: > apt-cache policy libapache2-mod-php5 Installed: 5.4.4-14+deb7u12 Candidate: 5.4.4-14+deb7u12 ... *** 5.4.4-14+deb7u12 0 500 http://security.debian.org/ stable/updates/main amd64 Packages ... > apt-cache policy libk5crypto3 libk5crypto3: Installed: 1.10.1+dfsg-5+deb7u2 Candidate: 1.10.1+dfsg-5+deb7u2 ... *** 1.10.1+dfsg-5+deb7u2 0 500 http://security.debian.org/ stable/updates/main amd64 Packages > apt-cache policy libkrb5support0 libkrb5support0: Installed: 1.12.1+dfsg-7 Candidate: 1.12.1+dfsg-7 Version table: *** 1.12.1+dfsg-7 0 5 http://mirror.internode.on.net/pub/debian/ testing/main amd64 Packages 2 http://mirror.internode.on.net/pub/debian/ unstable/main amd64 Packages ... there's a link error: > sudo /etc/init.d/apache2 restart 17235 (process ID) old priority 0, new priority 19 apache2: Syntax error on line 244 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/php5.load: Cannot load /usr\ /lib/apache2/modules/libphp5.so into server: /usr/lib/x86_64-linux-gnu/libk5crypto.so.3: symbol krb5int_buf_len, version krb5support_0_MIT not \ defined in file libkrb5support.so.0 with link time reference Action 'configtest' failed. The Apache error log may have more information. failed! Please feel free to reassign to the actual package at fault if not this one, but since this was the only package to get pulled in when I installed something from unstable... -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental'), (1, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libkrb5support0 depends on: ii libc6 2.17-97 ii libkeyutils1 1.5.9-5 ii multiarch-support 2.13-38+deb7u3 libkrb5support0 recommends no packages. libkrb5support0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#715367: postr removes photo from list before verifying upload was successful
On Wed, 23 Jul 2014, Alexander Alemayhu wrote: > Hei Tim, > > I have not been able to reproduce #715367[0]. Can you try to reproduce it on > 0.13.1-1 which is available in testing and unstable? > > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715367 Yeah, I uploaded a bunch of photos lastnight with the new version, and one errored out. This time it kept the failed item in the list. I presume the bug has been fixed (or maybe it was just a different kind of connection error). -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753133: postr: flickr API went SSL only today
Package: postr
Version: 0.13-1
Severity: grave
Tags: patch
Justification: renders package unusable
API went SSL only today:
https://www.flickr.com/help/forum/en-us/72157645440333073/
My basic little patch seems to work for the handful of things I've
tried, but I've probably missed something.
Also need to add a dependency on python-openssl. My patch doesn't do
that since I'm a bit clueless.
-- System Information:
Debian Release: 7.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages postr depends on:
ii chromium [www-browser]35.0.1916.153-1~deb7u1
ii google-chrome-unstable [www-browser] 37.0.2054.3-1
ii iceweasel [www-browser] 24.6.0esr-1~deb7u1
ii konqueror [www-browser] 4:4.8.4-2
ii links [www-browser] 2.7-1+deb7u1
ii lynx-cur [www-browser]2.8.8dev.12-2
ii python2.7.6-2
ii python-bsddb3 6.0.1-1+b1
ii python-gconf 2.28.1+dfsg-1
ii python-glade2 2.24.0-3+b1
ii python-gnome2 2.28.1+dfsg-1
ii python-gtk2 2.24.0-3+b1
ii python-nautilus 1.1-3
ii python-twisted-web12.0.0-1
ii w3m [www-browser] 0.5.3-8
postr recommends no packages.
postr suggests no packages.
-- no debconf information
Description: Attempt to move to https API: https://www.flickr.com/help/forum/en-us/72157645440333073/
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: http://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded:
Reviewed-By:
Last-Update:
--- postr-0.13.orig/src/flickrest.py 2014-06-29 20:52:37.0 +1000
+++ postr-0.13/src/flickrest.py 2014-06-29 23:26:15.227424687 +1000
@@ -47,7 +47,7 @@
SIZE_LARGE) = range (0, 5)
class Flickr:
-endpoint = "http://api.flickr.com/services/rest/?";
+endpoint = "https://api.flickr.com/services/rest/?";
def __init__(self, api_key, secret, perms="read"):
self.__methods = {}
@@ -208,7 +208,7 @@
}
self.logger.info("Calling upload")
-return client.upload("http://api.flickr.com/services/upload/";,
+return client.upload("https://api.flickr.com/services/upload/";,
proxy=self.proxy, method="POST",
headers=headers, postdata=form,
progress_tracker=progress_tracker).addCallback(self.__cb, "upload")
@@ -245,7 +245,7 @@
keys = { 'perms': self.perms,
'frob': frob }
self.__sign(keys)
-url = "http://flickr.com/services/auth/?api_key=%(api_key)s&perms=%(perms)s&frob=%(frob)s&api_sig=%(api_sig)s" % keys
+url = "https://flickr.com/services/auth/?api_key=%(api_key)s&perms=%(perms)s&frob=%(frob)s&api_sig=%(api_sig)s" % keys
return {'url': url, 'frob': frob}
return self.auth_getFrob().addCallback(gotFrob)
@@ -299,4 +299,4 @@
elif size == SIZE_LARGE:
suffix = "_b"
-return "http://static.flickr.com/%s/%s_%s%s.jpg"; % (photo.get("server"), photo.get("id"), photo.get("secret"), suffix)
+return "https://static.flickr.com/%s/%s_%s%s.jpg"; % (photo.get("server"), photo.get("id"), photo.get("secret"), suffix)
--- postr-0.13.orig/src/postr.py 2014-06-29 20:52:37.0 +1000
+++ postr-0.13/src/postr.py 2014-06-29 23:26:22.987484867 +1000
@@ -223,11 +223,11 @@
user = client.get_string("/system/http_proxy/authentication_user")
password = client.get_string("/system/http_proxy/authentication_password")
if user and user != "":
-url = "http://%s:%s@%s:%d"; % (user, password, host, port)
+url = "https://%s:%s@%s:%d"; % (user, password, host, port)
else:
-url = "http://%s:%d"; % (host, port)
+url = "https://%s:%d"; % (host, port)
else:
-url = "http://%s:%d"; % (host, port)
+url = "https://%s:%d"; % (host, port)
self.flickr.set_proxy(url)
else:
--- postr-0.13.orig/src/util.py 2014-05-24 05:36:21.0 +1000
+++ postr-0.13/src/util.py 2014-06-29 23:26:29.583536019 +1000
@@ -98,9 +98,9 @@
return load_thumb(page, size)
if int(data.get("iconfarm")) > 0:
-url =
Bug#691130: kaffeine: recording times appear to be encoded as UTC and are out by an hour every DST change
On Mon, 22 Oct 2012, Tim Connors wrote: > Package: kaffeine > Version: 1.2.2-1 > Severity: normal > > At the last daylight saving change, my programs scheduled for > recording in kaffeine have all been adjusted forward by an hour from > where I set them. This would imply they have been stored in UTC > rather than local time. Since TV programs are shown based on > localtime, this just means that everytime daylight saving changes, you > miss all your scheduled programs by an hour. This of course happened > to me 6 months ago, but I didn't realise what had happened then. > > bugs.kde needs a login, so I have not forwarded this bug upstream. This patch is reported to mostly solve the issue, and it looks good to me: http://sourceforge.net/p/kaffeine/mailman/message/31673147/ -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738708: rsync: please include modern --noatime patch
Package: rsync Version: 3.1.0-2 Severity: normal Tags: patch https://bugzilla.samba.org/show_bug.cgi?id=7249#c5 That patch uses the kernel's O_NOATIME feature that has been part of debian since ancient times now. Has none of the drawbacks of the horrible kludges proposed in the past, such as those documented #244168. As an added bonus, decade old bugs such as #244168 can be closed! -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rsync depends on: ii base-files 7.1wheezy4 ii libacl1 2.2.52-1 ii libc6 2.17-93 ii libpopt01.16-7 ii lsb-base4.1+Debian8+deb7u1 ii zlib1g 1:1.2.8.dfsg-1 rsync recommends no packages. Versions of packages rsync suggests: ii openssh-client 1:6.0p1-4 ii openssh-server 1:6.0p1-4 -- 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#738143: pulseaudio: restart clause faulty in init script
Package: pulseaudio Version: 4.0-6~bpo7+1 Severity: normal The restart clause tests for the existence of the pid file, then and only then restarts. pulseaudio_start should be called unconditionally - it's only stop that wants to test for whether the pidfile and process exists. This only affects pulseaudio in system mode, and won't affect users who don't have it configured (which will be the vast majority of users with the default setup). -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental'), (1, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pulseaudio depends on: ii adduser 3.113+nmu3 ii consolekit0.4.5-3.1 ii libasound21.0.25-4 ii libasound2-plugins1.0.25-2 ii libc6 2.17-97 ii libcap2 1:2.22-1.2 ii libdbus-1-3 1.6.8-1+deb7u1 ii libfftw3-33.3.2-3.1 ii libgcc1 1:4.7.2-5 ii libice6 2:1.0.8-2 ii libltdl7 2.4.2-1.1 ii liborc-0.4-0 1:0.4.16-2 ii libpulse0 4.0-6~bpo7+1 ii libsamplerate00.1.8-5 ii libsm62:1.2.1-2 ii libsndfile1 1.0.25-5 ii libspeexdsp1 1.2~rc1-7 ii libstdc++64.7.2-5 ii libsystemd-login0 44-11+deb7u4 ii libtdb1 1.2.10-2 ii libudev0 175-7.2 ii libwebrtc-audio-processing-0 0.1-2 ii libx11-6 2:1.5.0-1+deb7u1 ii libx11-xcb1 2:1.5.0-1+deb7u1 ii libxcb1 1.8.1-2+deb7u1 ii libxtst6 2:1.2.1-1+deb7u1 ii lsb-base 4.1+Debian8+deb7u1 ii udev 175-7.2 Versions of packages pulseaudio recommends: ii gstreamer0.10-pulseaudio 0.10.31-3+nmu1 ii pulseaudio-module-x11 4.0-6~bpo7+1 ii rtkit 0.10-2+wheezy1 Versions of packages pulseaudio suggests: ii paman 0.9.4-1 ii paprefs 0.9.10-1 ii pavucontrol 1.0-1 ii pavumeter 0.9.3-4 ii pulseaudio-utils 4.0-6~bpo7+1 -- Configuration Files: /etc/default/pulseaudio changed: PULSEAUDIO_SYSTEM_START=1 DISALLOW_MODULE_LOADING=0 /etc/pulse/daemon.conf changed: ; daemonize = no ; fail = yes ; allow-module-loading = yes ; allow-exit = yes ; use-pid-file = yes ; system-instance = no ; local-server-type = user ; enable-shm = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB ; lock-memory = no ; cpu-limit = no ; high-priority = yes ; nice-level = -11 realtime-scheduling = yes realtime-priority = 5 ; exit-idle-time = 20 ; scache-idle-time = 20 ; dl-search-path = (depends on architecture) ; load-default-script-file = yes ; default-script-file = /etc/pulse/default.pa ; log-target = auto ; log-level = notice ; log-meta = no ; log-time = no ; log-backtrace = 0 resample-method = speex-float-3 ; resample-method = trivial ; enable-remixing = yes ; enable-lfe-remixing = no ; flat-volumes = yes ; rlimit-fsize = -1 ; rlimit-data = -1 ; rlimit-stack = -1 ; rlimit-core = -1 ; rlimit-as = -1 ; rlimit-rss = -1 ; rlimit-nproc = -1 ; rlimit-nofile = 256 ; rlimit-memlock = -1 ; rlimit-locks = -1 ; rlimit-sigpending = -1 ; rlimit-msgqueue = -1 ; rlimit-nice = 31 ; rlimit-rtprio = 9 ; rlimit-rttime = 100 ; default-sample-format = s16le ; default-sample-rate = 44100 ; alternate-sample-rate = 48000 ; default-sample-channels = 2 ; default-channel-map = front-left,front-right ; default-fragments = 4 ; default-fragment-size-msec = 25 ; enable-deferred-volume = yes ; deferred-volume-safety-margin-usec = 8000 ; deferred-volume-extra-delay-usec = 0 /etc/pulse/default.pa changed: .nofail .fail load-module module-device-restore load-module module-stream-restore load-module module-card-restore load-module module-augment-properties load-module module-switch-on-port-available .ifexists module-udev-detect.so load-module module-udev-detect .else load-module module-detect .endif .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect channels=2 .fail .endif .ifexists module-bluetooth-policy.so load-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so load-module module-bluetooth-discover .endif .ifexists module-esound-protocol-unix.so load-module module-esound-protocol-unix .endif load-module module-native-protocol-unix load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24 load-module module-zeroconf-publish .ifexists module-gconf.so .nofail load-module module-gconf .fail .endif load-module modul
Bug#508867: Ping
Hi, I still see the bug, running -stable. On Tue, 21 Jan 2014, Solveig wrote: > Hi! > Do you still encounter this bug with latest versions? If yes, please > provide up-to-date data, and if not, this bug report might be closed, so > let us know :) > Cheers, > > Solveig > > -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732823: xmms2-client-cli: segfault when dealing with long pathnames
Package: xmms2-client-cli Version: 0.8+dfsg-4 Severity: normal I originally thought this was a UTF-8 bug, but now it looks like a pathname length issue to me: > xmms2 add "/home/tconnors/mp3/Classical/Benjamin Godard, Chloë Hanslip > (violin), Slovak Radio Symphony Orchestra, Kirk Trevor - Godard - Concerto > Romantique, op46 - Violin Concerto No2, op131 - Scènes Poétiques, op46 - > Hanslip-Trevor/01 - Violin Concerto No2, op131 - I Allegro moderato.flac" Segmentation fault And I suspect 'xmms2 add' includes the full pathname when talking to the server (duh, of course it does), because I can be in that directory, and add just the file, and it still crashes. Note that the directory is less than 256 chars, and the total length is more than 256. If I shorten the parent directory name by a number of characters, then some files (the shorter ones) work, and some fail - but the total pathname length is still greater than 256 chars. The boundary seems to be at 272 characters working, 273 failing. If I shorten the pathname so they're all under 272 chars, then all the files work. > pwd | wc 1 2 215 > for i in * ; do xmms2 add "$i" && echo -n +"$(pwd)/$i" || echo -n > -"$(pwd)/$i" ; realpath "$i" | wc ; echo ; done Segmentation fault -/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/01 - Violin Concerto No2, op131 - I Allegro moderato.flac 1 11 273 Segmentation fault -/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/02 - Violin Concerto No2, op131 - II Adagio quasi andante.flac 1 12 278 Segmentation fault -/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/03 - Violin Concerto No2, op131 - III Allegro non troppo.flac 1 12 277 +/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/04 - Concerto Romantique, op35 - I Allegro moderato.flac 1 10 272 Segmentation fault -/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/05 - Concerto Romantique, op35 - II Adagio non troppo.flac 1 11 274 Segmentation fault -/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/06 - Concerto Romantique, op35 - III Canzonetta-Allegretto moderato.flac 1 10 288 +/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/07 - Concerto Romantique, op35 - IV Allegro molto.flac 1 10 270 +/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/08 - Scènes Poétiques, op46 - I Dans les bois.flac 1 11 268 +/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/09 - Scènes Poétiques, op46 - II Dans les champs.flac 1 11 271 +/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/10 - Scènes Poétiques, op46 - III Sur la montagne.flac 1 11 272 +/home/tconnors/mp3/Classical/Benjamin GodardBenaaa/11 - Scènes Poétiques, op46 - IV Au village.flac 1 10 266 -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Bug#714139: and ntp_states too (Was Re: Bug#714139: munin-plugins-core: ntp plugin takes too long when no reserve DNS for one of the peers, causing subsequent plugins to not be queried)
On Wed, 26 Jun 2013, Kenyon Ralph wrote:
> On 2013-06-26T18:00:47+1000, Tim Connors
> wrote:
> > Package: munin-plugins-core
> > Version: 2.0.6-4+deb7u1
> > Severity: normal
> >
> > Investigating why uptime plugin wasn't running, logs were showing the
> > ntp_state was timing out. Running manually, I find one of the dynamic
> > peers isn't returning reverse DNS, and this simple patch fixes it
> > (only 1 second because it's not that critical if you don't resolve
> > successfully, and it tries twice, and you don't want to wait more than
> > 2 seconds when you only have 10 or so seconds to get through all the
> > plugins):
>
> I added 5-second timeouts to the plugin in this commit, and I haven't
> had any more timeout problems:
> https://github.com/munin-monitoring/munin/commit/e2a01b5be031f93fb3e2cdd00a28f1796727cd17
Although 5 seconds is a bit much because it actually turns to 10 seconds
by the time the second retry within libc is attempted (and we only have 60
seconds total to play with in munin-node, by the time we go through all
the other plugins, which might include ntp_states which also has the same
timeout issue.
Since most people have access to a reasonably good caching name server
(even their ISP will respond within 1 second after the first attempt, and
should keep it around for at least 5 minutes so the second and subsequent
lookups will get the cached result), I chose 1 second.
Now, the same bug is in ntp_states, but requires a small rewrite (copying
the DNS code from ntp_states without fixing up the irrelevant function
name; bad me) to fix. Please consider incorporating a variation of that
too... (now I've finally got munin-node consistently taking under 60
seconds!):
--- /usr/share/munin/plugins/ntp_.old 2013-06-10 01:41:52.0 +1000
+++ /usr/share/munin/plugins/ntp_ 2013-11-07 18:12:38.951852117 +1100
@@ -38,6 +38,46 @@
use Net::hostent;
use Socket;
+my $ret = undef;
+
+if (!eval "require Net::DNS;")
+{
+$ret = "Net::DNS not found";
+if (!defined $ARGV[0]) {
+die $ret;
+}
+}
+
+my $resolver = Net::DNS::Resolver->new;
+$resolver->tcp_timeout(1);
+$resolver->udp_timeout(1);
+
+# Takes an address and returns the Internet hostname
+sub make_names {
+my $addr = shift;
+my $host;
+my $packet = $resolver->query($addr);
+
+# Can use core perl routines (from the Socket module) to do
+# the address -> hostname lookup in perls newer than 5.10.1
+# with, but that's all I have to test with right now. So using
+# libnet-dns-perl.
+
+if ($packet) {
+my @answer = $packet->answer;
+foreach my $rr (@answer) {
+if ("PTR" eq $rr->type) {
+$host = $rr->ptrdname;
+}
+}
+}
+
+$host = defined $host ? $host : $addr;
+my $hostname = $host;
+
+return $hostname;
+}
+
my $nodelay = $ENV{'nodelay'} || 0;
if ($ARGV[0] and $ARGV[0] eq "autoconf") {
@@ -67,8 +107,8 @@
$lcid = $lcid - 1;
$name = "LOCAL($lcid)";
} else {
- $name = gethostbyaddr(inet_aton($addr));
- $name = defined $name ? $name->name : $addr;
+ $name = make_names($addr);
+ $name = defined $name ? $name : $addr;
}
$name = lc $name if exists $ENV{"lowercase"};
$name =~ s/[\.\-()]/_/g;
@@ -93,8 +133,8 @@
$lcid = $lcid - 1;
$host = "LOCAL($lcid)"
} else {
- $host = gethostbyaddr(inet_aton($addr));
- $host = defined $host ? $host->name : $addr;
+ $host = make_names($addr);
+ $host = defined $host ? $host : $addr;
}
$host = lc $host if exists $ENV{"lowercase"};
my $host_ = $host;
@@ -127,8 +167,8 @@
$lcid = $lcid - 1;
$host = "LOCAL($lcid)"
} else {
- $host = gethostbyaddr(inet_aton($addr));
- $host = defined $host ? $host->name : $addr;
+ $host = make_names($addr);
+ $host = defined $host ? $host : $addr;
}
$host = lc $host if exists $ENV{"lowercase"};
$host =~ s/[\.\-()]/_/g;
--
Tim Connors
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722127: slrn: description points to wrong upstream
Package: slrn Version: 1.0.0~pre18-1.3 Severity: normal the package description still refers to slrn.org, which appears to be an outdated version that still refers to version 0.9.9 The real upstream appears to be http://slrn.sourceforge.net/ BTW, there is a new version - it would be nice to determine whether it or the patch in 631159 fixes the frequent segfaults that have started appearing recently, such as bug 631159 itself. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages slrn depends on: ii debconf [debconf-2.0] 1.5.49 ii libc6 2.17-92 ii libcanlock22b-6 ii libgnutls-openssl272.12.20-7 ii libslang2 2.2.4-15 ii libuu0 0.5.20-3.3 slrn recommends no packages. Versions of packages slrn suggests: pn metamail pn slrnpull -- Configuration Files: /etc/default/slrn changed [not included] -- debconf information: slrn/getdescs_now: false * shared/mailname: dirac.rather.puzzling.org * shared/news/server: news.rather.puzzling.org slrn/getdescs: manually -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721303: udisks: breaks LVM and deadlocks LVM related IO to system [SEC=UNCLASSIFIED]
Package: udisks Version: 1.0.4-7 Severity: critical Justification: breaks unrelated software lvm snapshot removal has been broken in debian for a few years now. lvremove has a good chance at any moment to deadlock IO to a box. If you happen to be lucky enough to have dmsetup still in cache, you might be able to resume the device, but more often than not, you simply have no choice but to reboot. Which is kinda bad. /lib/udev/rules.d/80-udisks.rules has the following line in it: KERNEL=="dm-*", OPTIONS+="watch" >From https://www.redhat.com/archives/linux-lvm/2010-August/msg00038.html https://bugzilla.redhat.com/show_bug.cgi?id=577798#c5 we see that you can remove that line, and have reliable lvm again. In fact, rhel6 has a similar kernel to debian wheezy, and has commented that line out all together: # Make udevd synthesize a 'change' uevent when last opener of a rw-fd closes the fd - this # should be part of the device-mapper rules # # Disabled as per #738479 # KERNEL=="dm-*", OPTIONS+="watch" (unfortunately we don't have permission to view rhbz#738479, but I suspect it's just a clone of the fc13 bug 577798) Since I believe this bug directly causes debian bugs: 592250 549691 618016 and probably dozens of others, can we just remove that line in /lib/udev/rules.d/80-udisks.rules like they have in RHEL6 until the real race condition is discovered? Marking as critical, because udisks seems to be pulled in by default on debian, seems to be unnecessary, and most definitely breaks unrelated parts of the system (forced reboots on production systems are bad, mmmkay?) -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages udisks depends on: ii dbus 1.6.8-1+deb7u1 ii libatasmart4 0.19-1 ii libc6 2.13-38 ii libdbus-1-31.6.8-1+deb7u1 ii libdbus-glib-1-2 0.100.2-1 ii libdevmapper1.02.1 2:1.02.74-7 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgudev-1.0-0 175-7.2 ii liblvm2app2.2 2.02.95-7 ii libparted0debian1 2.3-12 ii libpolkit-gobject-1-0 0.105-3 ii libsgutils2-2 1.33-1 ii libudev0 175-7.2 ii udev 175-7.2 Versions of packages udisks recommends: ii cryptsetup-bin 2:1.4.3-4 ii dosfstools 3.0.13-1 ii eject 2.1.5+deb1+cvs20081104-13 ii hdparm 9.39-1+b1 ii ntfs-3g 1:2012.1.15AR.5-2.1 ii policykit-1 0.105-3 Versions of packages udisks suggests: ii mdadm 3.2.5-5 pn reiserfsprogs pn xfsprogs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#715367: postr removes photo from list before verifying upload was successful
Package: postr Version: 0.12.4-2.1 Severity: normal Tags: patch Don't remove photo from upload list until upload successful: diff -ru postr-0.12.4.orig/src//postr.py postr-0.12.4/src//postr.py --- postr-0.12.4.orig/src//postr.py 2009-11-05 12:26:54.0 +1100 +++ postr-0.12.4/src//postr.py 2011-11-05 23:19:54.0 +1100 @@ -780,11 +780,6 @@ """Upload worker function, called by the File->Upload callback. As this calls itself in the deferred callback, it takes a response argument.""" -# Remove the uploaded image from the store -if self.current_upload_it: -self.model.remove(self.current_upload_it) -self.current_upload_it = None - it = self.model.get_iter_first() if self.cancel_upload or it is None: self.upload_done() @@ -842,4 +837,14 @@ d.addCallback(self.add_to_set, set_id) if groups: d.addCallback(self.add_to_groups, groups) + +d.addCallback(self.uploaded) d.addCallbacks(self.upload, self.upload_error) + +def uploaded(self,rsp): +# Remove the uploaded image from the store +if self.current_upload_it: +self.model.remove(self.current_upload_it) +self.current_upload_it = None +return rsp -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.9-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postr depends on: ii chromium [www-browser]27.0.1453.110-1~deb7u1 ii google-chrome-unstable [www-browser] 29.0.1547.0-r208345 ii iceweasel [www-browser] 17.0.7esr-1~deb7u1 ii konqueror [www-browser] 4:4.8.4-2 ii links [www-browser] 2.7-1 ii lynx-cur [www-browser]2.8.8dev.12-2 ii python2.7.3-4 ii python-gconf 2.28.1+dfsg-1 ii python-glade2 2.24.0-3+b1 ii python-gtk2 2.24.0-3+b1 ii python-support1.0.15 ii python-twisted-web12.0.0-1 ii w3m [www-browser] 0.5.3-8 postr recommends no packages. postr suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564565: patch for hardcoded keybindings
Just removing the offending keybindings is far less offensive than losing one's hard work in tagging and captioning images (and having them in the right order, since we can't yet reorder the listing!): diff -ru postr-0.12.4.orig/src//postr.glade postr-0.12.4/src//postr.glade --- postr-0.12.4.orig/src//postr.glade 2009-11-05 12:26:54.0 +1100 +++ postr-0.12.4/src//postr.glade 2011-11-05 13:58:02.0 +1100 @@ -43,7 +43,6 @@ _Remove Photos True - True @@ -121,7 +120,6 @@ _Select All True - True -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714139: munin-plugins-core: ntp plugin takes too long when no reserve DNS for one of the peers, causing subsequent plugins to not be queried
Package: munin-plugins-core Version: 2.0.6-4+deb7u1 Severity: normal Investigating why uptime plugin wasn't running, logs were showing the ntp_state was timing out. Running manually, I find one of the dynamic peers isn't returning reverse DNS, and this simple patch fixes it (only 1 second because it's not that critical if you don't resolve successfully, and it tries twice, and you don't want to wait more than 2 seconds when you only have 10 or so seconds to get through all the plugins): --- /usr/share/munin/plugins/ntp_states.old 2013-06-26 17:56:59.971427119 +1000 +++ /usr/share/munin/plugins/ntp_states 2013-06-26 17:55:00.031642347 +1000 @@ -68,6 +68,8 @@ ); my %peers_condition; my $resolver = Net::DNS::Resolver->new; +$resolver->tcp_timeout(1); +$resolver->udp_timeout(1); # Returns a hash whose keys are peer IP addresses and values are # condition numbers. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages munin-plugins-core depends on: ii munin-common 2.0.6-4+deb7u1 ii perl 5.14.2-21 Versions of packages munin-plugins-core recommends: ii libnet-snmp-perl 6.0.1-2 Versions of packages munin-plugins-core suggests: pn libnet-netmask-perl pn libnet-telnet-perl ii python2.7.3-4 ii ruby 1:1.9.3 ii ruby1.8 [ruby-interpreter]1.8.7.358-7 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/munin/plugins/ntp_states (from munin-plugins-core package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#712573: regression: ctrl key continually pressed
Package: xine-ui Version: 0.99.7-1 Severity: normal Looks like bug 506001 (dup with 374644) is back! (I would file this under grave just like it was back then, but I'm actually starting to question my sanity and might wait until confirmation before I do so - how can this bug be back when the problem was so seemingly definitely dealt with back more than 4 years ago?) Fake pressing ctrl (or any other key) randomly every 20 seconds while focus is directed potentially anywhere IS NOT ACCEPTABLE. Please remove all traces of the fake-keypressing code from the source and burn it in a Gamma Ray Burst so it never makes an accidental appearance again. (also explains why when a video is paused, nothing I do can make the screensaver kick in when I desire it to. Stop screwing around with the screensaver without the user's permission!) I don't remember this being a problem when I was running a mixed squeeze/sid environment, so maybe it's only popped up recently upon upgrade of all packages to wheezy? -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xine-ui depends on: ii libc62.13-38 ii libcurl3-gnutls 7.26.0-1+wheezy2 ii libjpeg8 8d-1 ii liblircclient0 0.9.0~pre1-1 ii libpng12-0 1.2.49-1 ii libreadline6 6.2+dfsg-0.1 ii libx11-6 2:1.5.0-1+deb7u1 ii libxext6 2:1.3.1-2+deb7u1 ii libxft2 2.3.1-1 ii libxine2 1.2.2-4 ii libxine2-ffmpeg 1.2.2-4 ii libxine2-x 1.2.2-4 ii libxinerama1 2:1.1.2-1+deb7u1 ii libxtst6 2:1.2.1-1+deb7u1 ii libxv1 2:1.0.7-1+deb7u1 ii libxxf86vm1 1:1.1.2-1+deb7u1 Versions of packages xine-ui recommends: ii xdg-utils 1.1.0~rc1+git20111210-6 xine-ui suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /var/lib/xine/xine.desktop (from xine-ui package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711465: munin-plugins-core: diskstats_latency doesn't handle wraparounds correctly
Package: munin-plugins-core Version: 2.0.6-4 Severity: normal With mail notifications turned on, I frequently get these notifications for latency on all devices: To: munin Subject: Munin notification weinberg weinberg :: weinberg :: Disk latency per device :: Average latency for /dev/base/root WARNINGs: Write IO Wait time is -248.17 (outside range [0:1]). OKs: Read IO Wait time is 0.02. I presume it's a wraparound, and 5 minutes later I get the clear message. Unfortunately, there are a lot of devices, so I get these bogus notifications quite frequently. Also, there seems to be missing documentation about how to configure the warning threshold in plugins.conf. I've tried various permutations of [diskstats] env.latency.*warning [-300:1] etc, but nothing has yet worked for me. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages munin-plugins-core depends on: ii munin-common 2.0.6-4 ii perl 5.14.2-21 Versions of packages munin-plugins-core recommends: ii libnet-snmp-perl 6.0.1-2 Versions of packages munin-plugins-core suggests: pn libnet-netmask-perl pn libnet-telnet-perl ii python2.7.3-4 ii ruby 1:1.9.3 ii ruby1.8 [ruby-interpreter]1.8.7.358-7 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1 -- 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#628843: Bug#659878: cannot set terminal process group (-1): Inappropriate ioctl for device
On Fri, 10 May 2013, Tim Connors wrote: > Actually, the other thing you lose (I presuming caused by acting on bug > #628843) is tty resizing by SIGWINCH. ttys are really useful, it turns > out. > > I have shedloads of up-to-date security patched RHEL5/6 machines, and I've > never come across this problem on them. Yep: > rhel6> su -c -u root 'cat /dev/tty' > Password: > asdasda > asdasda > debian-wheezy> su -c -u root 'cat /dev/tty' > Password: > cat: /dev/tty: No such device or address > > Sorry, marking this bug as RC (pity I missed wheezy!), breaks other > software. As per some comments in #628843, the way this bug was addressed breaks su -c to increase privledges. It also breaks su -c to become a user and execute something interactive. Root isn't going to be doing stupid things and running scripts that have been compromised (if they are, then they've got bigger problems), so what's the problem? (why on earth would root ever su to an untrusted user account?) I think this change should just be backed out, and a prominent warning about the tty exploit placed in the manpage. -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663200: Bug#659878: cannot set terminal process group (-1): Inappropriate ioctl for device
severity 663200 grave thanks On Fri, 10 May 2013, Tim Connors wrote: > > I currently can't find any idea how to fix this issue. > > > > The security issue had to be solved by dropping the controlling > > terminal, so you cannot start a command that would interact with the > > current terminal. I don't have enough terminal handling skills to find > > other way to fix the security issue than by dropping the terminal. > > > > An option could be to keep the controlling terminal when su-ing to root. > > The issue would be less visible in sux (probably used mostly to gain > > root privileges), but even if the risk when su'ing to root is lower, it > > does not smell good. > > Is this just a security risk when suing from root to an unprivledged > account (eg, in init.d scripts), and that unprivledged account injects > keystrokes back into the root shell? If it's not a risk when trying to > get into the root account and running something with -c where you desire > there to be a tty, then maybe you could keep the tty in that situation. > > Or what about providing an extra flag (eg, -C) where the user explicitly > acknoledges that they're happy to take on the risk that you have a > controlling tty and are executing a command with it? Actually, the other thing you lose (I presuming caused by acting on bug #628843) is tty resizing by SIGWINCH. ttys are really useful, it turns out. I have shedloads of up-to-date security patched RHEL5/6 machines, and I've never come across this problem on them. Yep: rhel6> su -c -u root 'cat /dev/tty' Password: asdasda asdasda debian-wheezy> su -c -u root 'cat /dev/tty' Password: cat: /dev/tty: No such device or address Sorry, marking this bug as RC (pity I missed wheezy!), breaks other software. -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663200: Bug#659878: cannot set terminal process group (-1): Inappropriate ioctl for device
> I currently can't find any idea how to fix this issue. > > The security issue had to be solved by dropping the controlling > terminal, so you cannot start a command that would interact with the > current terminal. I don't have enough terminal handling skills to find > other way to fix the security issue than by dropping the terminal. > > An option could be to keep the controlling terminal when su-ing to root. > The issue would be less visible in sux (probably used mostly to gain > root privileges), but even if the risk when su'ing to root is lower, it > does not smell good. Is this just a security risk when suing from root to an unprivledged account (eg, in init.d scripts), and that unprivledged account injects keystrokes back into the root shell? If it's not a risk when trying to get into the root account and running something with -c where you desire there to be a tty, then maybe you could keep the tty in that situation. Or what about providing an extra flag (eg, -C) where the user explicitly acknoledges that they're happy to take on the risk that you have a controlling tty and are executing a command with it? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#419940: old procmail bug for continued fields in message headers
On Thu, 3 May 2007 07:49:00 +0200, Paolo wrote:
> On Thu, Apr 19, 2007 at 05:46:55PM +0200, wrote:
> > > but it's not what it really does, nor it is what RFC 2822 calls
> > > "unfolding". Quote:
> >
> > right, both procmail and formail do the wrong thing here - thanks for
> ...
> > > Converting a newline into a white space does not really concatenate
> > > fields, as it adds an extra space.
>
> well, seems it's a known bug: man procmail:
>
> ...
>The embedded newlines in a continued header should be skipped when
>matching instead of being treated as a single space as they are now.
> ...
>
> so upstream is aware of it; I guess s/\n/ / was just easier than RFC ;)
Yuck. This breaks the deduplication of formail -D (I'm guessing it's
code shared between both formail and procmail):
#avoid duplicated messages
# (if testing, don't do duplicate test)
:0 Whc: msgid.lock
* $ ${TESTMAIL+!}
| formail -D 16384 .msgid.cache
When I get a message via two different systems, which break a long message
id differently:
Message-ID:
Message-ID:
I end up with these two entries in formail, and they aren't deduplicated:
Maintainer:
Could you kindly forward this bug upstream? I know procmail is ... very
mature (this bug was first mentioned on the mailing list in 2000, applying
to a 1994 version of the code):
http://www.mhonarc.org/archive/html/procmail/2000-05/msg00185.html
--
Tim Connors
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689595: xine-ui: 0.99.7-1 pulls in libvdpau1, which crashes upon startup on non nvidia hardware
On Sun, 31 Mar 2013, Tim Connors wrote: > On Mon, 22 Oct 2012, Tim Connors wrote: > > > gzread? > > > Seems to be a timing issue (yay!) > > In one of the other Important "did not start" bugs against xine-ui (this > is a dup of all of them), mention is made of working sometimes with "xine > -V opengl". In running it in quick succession, I was eventually able to > get 'xine -V opengl Doctor\ Who.m2t' (and sdl) to start and continue to > play (about 3 attempts out of 20 though). Have never got any of the other > methods to start. > > This is on a fairly slow 4 core NAS box with an onboard intel video > driver. Running kernel 3.7. It did once work, but I have no idea what > has broken. Um, I did spend the last hour trying to sync up the packages on this little 4 core box vs my main workstation which seems to work, but I didn't think to sync zlib1g despite that very large hint in it failing in gzread(), did I? Anyway, I just upgraded to: [INSTALL] zlib-bin [UPGRADE] zlib1g 1:1.2.3.4.dfsg-3 -> 1:1.2.7.dfsg-13 [UPGRADE] zlib1g-dev 1:1.2.3.4.dfsg-3 -> 1:1.2.7.dfsg-13 (from stable to testing) And it seems to work now. Looks like you need to specify the dependencies a little tighter somewhere in libxine2. -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689595: xine-ui: 0.99.7-1 pulls in libvdpau1, which crashes upon startup on non nvidia hardware
On Mon, 22 Oct 2012, Tim Connors wrote: > Didn't work :( But it might not be in vdpau after all: > > (gdb) run -f > /home/tconnors/movies/kaffeine/Videos_Play_SBS_Cycling_Central_Cycling_News_and_Results_Vid.flv > Starting program: /usr/bin/xine -f > /home/tconnors/movies/kaffeine/Videos_Play_SBS_Cycling_Central_Cycling_News_and_Results_Vid.flv > [Thread debugging using libthread_db enabled] > This is xine (X11 gui) - a free video player v0.99.7. > (c) 2000-2010 The xine Team. > [New Thread 0x70968700 (LWP 29691)] > [New Thread 0x70167700 (LWP 29692)] > [New Thread 0x7fffef966700 (LWP 29693)] > [New Thread 0x7fffef165700 (LWP 29694)] > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object > file: No such file or directory > vo_vdpau: Can't create vdp device : No vdpau implementation. > [New Thread 0x7fffe8f6d700 (LWP 29695)] > [New Thread 0x7fffe826f700 (LWP 29696)] > [New Thread 0x7fffe7a6e700 (LWP 29697)] > [New Thread 0x7fffe6042700 (LWP 29698)] > [New Thread 0x7fffe5674700 (LWP 29699)] > [New Thread 0x7fffe4c70700 (LWP 29702)] > [New Thread 0x7fffd700 (LWP 29703)] > > Program received signal SIGSEGV, Segmentation fault. > 0x7796777d in gzread_i16 (fp=0xcd3e50) at osd.c:851 > 851 osd.c: No such file or directory. > in osd.c > (gdb) bt > #0 0x7796777d in gzread_i16 (fp=0xcd3e50) at osd.c:851 > #1 0x779680b0 in osd_renderer_load_font ( > filename=0xb4bd30 "/usr/share/xine-lib/fonts//sans-20.xinefont.gz", > this=) > at osd.c:875 > #2 osd_set_font (osd=0xb49f00, fontname=, size=20) at > osd.c:1182 > #3 0x0043cb27 in osd_init () at osd.c:153 > #4 0x00411c5e in main (argc=0, argv=) at > main.c:2214 > (gdb) > > gzread? Seems to be a timing issue (yay!) In one of the other Important "did not start" bugs against xine-ui (this is a dup of all of them), mention is made of working sometimes with "xine -V opengl". In running it in quick succession, I was eventually able to get 'xine -V opengl Doctor\ Who.m2t' (and sdl) to start and continue to play (about 3 attempts out of 20 though). Have never got any of the other methods to start. This is on a fairly slow 4 core NAS box with an onboard intel video driver. Running kernel 3.7. It did once work, but I have no idea what has broken. -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562178: icedove: does unnecessary seek without error checking on .signature
On Sat, 9 Mar 2013, Carsten Schoenert wrote:
> Hello Tim,
>
> On Thu, Dec 24, 2009 at 12:59:26AM +1100, Tim Connors wrote:
> > Package: icedove
> > Version: 2.0.0.22-1.1
> > Severity: normal
> >
> > If .signature happens to be a named pipe with a program feeding text
> > into that named pipe, then icedove does *cough* interesting *cough*
> > things:
> >
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> > [pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> >
> > Error checking is good, mmmkay? Reading a .signature file ought not
> > be any more complicated that while (!eof) { sig+=readline }
> >
> > Playing around with seek when unnecessary seems just silly (as well as
> > not very UNIX like).
>
> what about that issue in current versions?
> Or could this bug closed?
It isn't broken in the same way - now it opens and reads the file twice,
before discarding the text:
29581 stat("/home/tconnors/.signature1", {st_mode=S_IFIFO|0644, st_size=0,
...}) = 0
29581 open("/home/tconnors/.signature1", O_RDONLY) = 47
29581 stat("/home/tconnors/.signature1", {st_mode=S_IFIFO|0644, st_size=0,
...}) = 0
29581 close(47) = 0
29581 stat("/home/tconnors/.signature1", {st_mode=S_IFIFO|0644, st_size=0,
...}) = 0
29581 open("/home/tconnors/.signature1", O_RDONLY) = 47
29581 read(47, "TimC\nIf you tried to understand "..., 4096) = 140
29581 read(47, "", 4096)= 0
29581 close(47) = 0
So yep, still broken, but at least not quite as broken. Progress!
--
Tim Connors
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624364: Reproduced bug #624364
unarchive 624364 reopen 624364 found 624364 4.0.0~beta2+dfsg1-3.1 thanks > These temporary files are left by samba_dnsupdate when it fails to get > credentials. > > Traceback (most recent call last): > File "/usr/sbin/samba_dnsupdate", line 485, in > get_credentials(lp) > File "/usr/sbin/samba_dnsupdate", line 120, in get_credentials > creds.get_named_ccache(lp, ccachename) > RuntimeError: kinit for DENEB$@EXAMPLE.ORG failed (Cannot contact any > KDC for requested realm) > > As I'm not running named neither have set correct values for kerberos > get_credentials can't succeed. Reopening this bug because it seems to have gotten auto-archived after you unarchived it. In my case, it's a stock install of samba4 from /testing left in its default unconfigured state (I should get around to it one day), so it should be pretty easy to reproduce! :) -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700157: ibam: doesn't work if battery isn't BAT0
Package: ibam
Version: 1:0.5.2-2.1
Severity: normal
On this machine, there's only /sys/class/power_supply/BAT1, but ibam
only looks for BAT0 according to strace:
strace:
...
open("/sys/class/power_supply/BAT0/present", O_RDONLY) = -1 ENOENT (No such
file or directory)
...
Thus it fails with:
> ibam
No apm data available.
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1,
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.7-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages ibam depends on:
ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy
ii libc6 2.13-35Embedded GNU C Library: Shared lib
ii libgcc1 1:4.7.1-7 GCC support library
ii libstdc++64.7.1-7GNU Standard C++ Library v3
ibam recommends no packages.
Versions of packages ibam suggests:
ii gnuplot 4.4.0-1.1 A command-line driven interactive
-- 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#690201: xine-ui: xine --enqueue can't cope with filename with comma "," in it
tags 690201 patch
thanks.
On Thu, 11 Oct 2012, Tim Connors wrote:
> Package: xine-ui
> Version: 0.99.6-1
> Severity: normal
>
> xine --enqueue splits any filename provided on the commandline if they
> have a comma in the filename.
>
> It does this because --enqueue gets transformed in main.c:main() to
> allocate a session_argv array with mrl=%s and passes that off to the
> session code to interpret in session.c:session_handle_subopt, which
> just stupidly blindly splits every string at every "," via getsubopt()
> right at the top of session_handle_subopt(). There is no way around
> this - you can't even escape commas in the filename with "\" or the
> like. Seems someone forgot that mrls get passed through getsubopt and
> can of course be arbitrary strings so no character should be entitled
> to act as delimeter. The mrl case should be handled via some other
> means - probably via a separate array since ideally you should be able
> to even handle a filename that looks like "token=value". It should be
> easy - only interpret tokens provided via
> S=token1,token2,token3,token4=value,token5 etc, and all other options
> parsed through getopt(), but any other argument should be interpreted
> as a filename.
>
> Continue to support "xine -S mrl=..." for backwards compatibility by
> all means, but xine -S ... --enqueue ... ... should be the preferred
> method.
And it turns out the use of atoa() was pretty poor form too, in that it
nulled out a whole class of valid-in-filename characters. Other uses of
that function seem sane enough, but in handling filenames? Um, no...
Pretty easy fix, attached patch tests out fine here...
Please forward upstream.
--
Tim Connorsdiff -ru /root/apt-source/xine-ui-0.99.7.orig/src/xitk/event.c /root/apt-source/xine-ui-0.99.7.patched,unbuilt/src/xitk/event.c
--- /root/apt-source/xine-ui-0.99.7.orig/src/xitk/event.c 2012-01-19 22:04:00.0 +1100
+++ /root/apt-source/xine-ui-0.99.7.patched,unbuilt/src/xitk/event.c 2012-10-25 17:11:27.585912576 +1100
@@ -1952,7 +1952,7 @@
int dummy_session;
while(startup->session_opts[i])
- (void) session_handle_subopt(startup->session_opts[i++], &dummy_session);
+ (void) session_handle_subopt(startup->session_opts[i++], NULL, &dummy_session);
}
diff -ru /root/apt-source/xine-ui-0.99.7.orig/src/xitk/main.c /root/apt-source/xine-ui-0.99.7.patched,unbuilt/src/xitk/main.c
--- /root/apt-source/xine-ui-0.99.7.orig/src/xitk/main.c 2012-01-19 22:04:00.0 +1100
+++ /root/apt-source/xine-ui-0.99.7.patched,unbuilt/src/xitk/main.c 2012-10-25 17:11:25.097996921 +1100
@@ -1781,7 +1781,7 @@
case 'S':
if(is_remote_running(((session >= 0) ? session : 0)))
- retval = session_handle_subopt(optarg, &session);
+retval = session_handle_subopt(optarg, NULL, &session);
else {
session_argv = (char **) realloc(session_argv, sizeof(char *) * (session_argv_num + 2));
@@ -1933,9 +1933,9 @@
if(_argv[optind]) {
for(i = optind; i < _argc; i++) {
char enqueue_mrl[strlen(_argv[i]) + 256];
-
- snprintf(enqueue_mrl, sizeof(enqueue_mrl), "session=%d,mrl=%s", session, atoa(_argv[i]));
- (void) session_handle_subopt(enqueue_mrl, &session);
+ char *filename = NULL;
+ snprintf(enqueue_mrl, sizeof(enqueue_mrl), "session=%d", session);
+ (void) session_handle_subopt(enqueue_mrl, _argv[i], &session);
}
}
else
diff -ru /root/apt-source/xine-ui-0.99.7.orig/src/xitk/session.c /root/apt-source/xine-ui-0.99.7.patched,unbuilt/src/xitk/session.c
--- /root/apt-source/xine-ui-0.99.7.orig/src/xitk/session.c 2012-01-19 22:04:00.0 +1100
+++ /root/apt-source/xine-ui-0.99.7.patched,unbuilt/src/xitk/session.c 2012-10-25 17:11:24.370021603 +1100
@@ -499,7 +499,7 @@
return 1;
}
-int session_handle_subopt(char *suboptarg, int *session) {
+int session_handle_subopt(char *suboptarg, char* enqueue_mrl, int *session) {
int playlist_first, playlist_last, playlist_clear, playlist_next, playlist_prev, playlist_stop_cont;
int audio_next, audio_prev, spu_next, spu_prev;
int volume, amp, loop, speed_status, time_status;
@@ -634,6 +634,13 @@
}
}
+
+ if (enqueue_mrl != NULL) {
+mrls = (char **) realloc(mrls, sizeof(char *) * (num_mrls + 2));
+
+mrls[num_mrls++] = strdup(enqueue_mrl);
+mrls[num_mrls] = NULL;
+ }
*session = (optsess >= 0) ? optsess : 0;
diff -ru /root/apt-source/xine-ui-0.99.7.orig/src/xitk/session.h /root/apt-source/xine-ui-0.99.7.patched,unbuilt/src/xitk/session.h
--- /root/apt-source/xine-ui-0.99.7.orig/src/xitk/session.h 2009-12-19 11:34:22.0 +1100
+++ /root/apt-source/xine-ui-0.99.7.patched,unbuilt/src/xitk/session.h 2012-10-25 17:11:25.905969537 +1100
@@ -69
Bug#689595: xine-ui: 0.99.7-1 pulls in libvdpau1, which crashes upon startup on non nvidia hardware
On Thu, 4 Oct 2012, Darren Salt wrote: > I demand that Tim Connors may or may not have written... > > > I don't have any nvidia hardware (plain old Intel, TYVM), but xine-ui > > insists on pulling in some nvidia specific vdpau crap and crashing anyway: > > It pulls in nothing nvidia-specific. > > strace here shows libvdpau_r600 being loaded (definitely NOT nvidia...), then > failing due to lack of support for chroma type 4:2:2. Incidentally, gxine > works fine, falling back on Xv. > > For the moment, tell xine ‘-V xv‘ and configure it to use Xv by default...? Didn't work :( But it might not be in vdpau after all: (gdb) run -f /home/tconnors/movies/kaffeine/Videos_Play_SBS_Cycling_Central_Cycling_News_and_Results_Vid.flv Starting program: /usr/bin/xine -f /home/tconnors/movies/kaffeine/Videos_Play_SBS_Cycling_Central_Cycling_News_and_Results_Vid.flv [Thread debugging using libthread_db enabled] This is xine (X11 gui) - a free video player v0.99.7. (c) 2000-2010 The xine Team. [New Thread 0x70968700 (LWP 29691)] [New Thread 0x70167700 (LWP 29692)] [New Thread 0x7fffef966700 (LWP 29693)] [New Thread 0x7fffef165700 (LWP 29694)] Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory vo_vdpau: Can't create vdp device : No vdpau implementation. [New Thread 0x7fffe8f6d700 (LWP 29695)] [New Thread 0x7fffe826f700 (LWP 29696)] [New Thread 0x7fffe7a6e700 (LWP 29697)] [New Thread 0x7fffe6042700 (LWP 29698)] [New Thread 0x7fffe5674700 (LWP 29699)] [New Thread 0x7fffe4c70700 (LWP 29702)] [New Thread 0x7fffd700 (LWP 29703)] Program received signal SIGSEGV, Segmentation fault. 0x7796777d in gzread_i16 (fp=0xcd3e50) at osd.c:851 851 osd.c: No such file or directory. in osd.c (gdb) bt #0 0x7796777d in gzread_i16 (fp=0xcd3e50) at osd.c:851 #1 0x779680b0 in osd_renderer_load_font ( filename=0xb4bd30 "/usr/share/xine-lib/fonts//sans-20.xinefont.gz", this=) at osd.c:875 #2 osd_set_font (osd=0xb49f00, fontname=, size=20) at osd.c:1182 #3 0x0043cb27 in osd_init () at osd.c:153 #4 0x00411c5e in main (argc=0, argv=) at main.c:2214 (gdb) gzread? > > [snip] > > 231989,35> xine -f Cycling\ Central-22.m2t > > This is xine (X11 gui) - a free video player v0.99.7. > > (c) 2000-2010 The xine Team. > > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object > file: No such file or directory > > vo_vdpau: Can't create vdp device : No vdpau implementation. > > Segmentation fault > > That said, that shouldn't be happening... if I move libvdpau_r600.so.1 out of > the way, it fails as above then exits, but no segfault. A backtrace, at > least, is needed to get anywhere with this one. > > Also, the missing library is in nvidia-vdpau-driver (assuming that you're > using the taintware). Intel 965GM? No taintware here... -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691130: kaffeine: recording times appear to be encoded as UTC and are out by an hour every DST change
Package: kaffeine Version: 1.2.2-1 Severity: normal At the last daylight saving change, my programs scheduled for recording in kaffeine have all been adjusted forward by an hour from where I set them. This would imply they have been stored in UTC rather than local time. Since TV programs are shown based on localtime, this just means that everytime daylight saving changes, you miss all your scheduled programs by an hour. This of course happened to me 6 months ago, but I didn't realise what had happened then. bugs.kde needs a login, so I have not forwarded this bug upstream. -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kaffeine depends on: ii kdebase-runtime 4:4.6.5-1+b1 runtime components from the offici ii libc6 2.13-10Embedded GNU C Library: Shared lib ii libgcc1 1:4.7.1-7 GCC support library ii libkdecore5 4:4.6.5-2 KDE Platform Core Library ii libkdeui5 4:4.6.5-2 KDE Platform User Interface Librar ii libkfile4 4:4.6.5-2 File Selection Dialog Library for ii libkio5 4:4.6.5-2 Network-enabled File Management Li ii libqt4-dbus 4:4.8.1-1 Qt 4 D-Bus module ii libqt4-network4:4.8.1-1 Qt 4 network module ii libqt4-sql4:4.8.1-1 Qt 4 SQL module ii libqt4-sql-sqlite 4:4.8.1-1 Qt 4 SQLite 3 database driver ii libqt4-svg4:4.8.1-1 Qt 4 SVG module ii libqt4-xml4:4.8.1-1 Qt 4 XML module ii libqtcore44:4.8.1-1 Qt 4 core module ii libqtgui4 4:4.8.1-1 Qt 4 GUI module ii libsolid4 4:4.6.5-2 Solid Library for KDE Platform ii libstdc++64.7.1-7GNU Standard C++ Library v3 ii libx11-6 2:1.4.99.901-2 X11 client-side library ii libxine1 1:1.1.20-0.1 Xine video/media player library, m ii libxine1-ffmpeg 1:1.1.20-0.1 MPEG-related plugins for libxine1 ii libxine1-x1:1.1.20-0.1 X desktop video output plugins for ii libxss1 1:1.2.0-2 X11 Screen Saver extension library kaffeine recommends no packages. Versions of packages kaffeine suggests: ii libdvdcss21.2.10-0.3 Simple foundation for reading DVDs -- 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#690201: xine-ui: xine --enqueue can't cope with filename with comma "," in it
Package: xine-ui Version: 0.99.6-1 Severity: normal xine --enqueue splits any filename provided on the commandline if they have a comma in the filename. It does this because --enqueue gets transformed in main.c:main() to allocate a session_argv array with mrl=%s and passes that off to the session code to interpret in session.c:session_handle_subopt, which just stupidly blindly splits every string at every "," via getsubopt() right at the top of session_handle_subopt(). There is no way around this - you can't even escape commas in the filename with "\" or the like. Seems someone forgot that mrls get passed through getsubopt and can of course be arbitrary strings so no character should be entitled to act as delimeter. The mrl case should be handled via some other means - probably via a separate array since ideally you should be able to even handle a filename that looks like "token=value". It should be easy - only interpret tokens provided via S=token1,token2,token3,token4=value,token5 etc, and all other options parsed through getopt(), but any other argument should be interpreted as a filename. Continue to support "xine -S mrl=..." for backwards compatibility by all means, but xine -S ... --enqueue ... ... should be the preferred method. -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xine-ui depends on: ii libc6 2.13-10 Embedded GNU C Library: Shared lib ii libcurl3-gnutls7.25.0-1 easy-to-use client-side URL transf ii liblircclient0 0.8.3-5 infra-red remote control support - ii libpng12-0 1.2.44-1+squeeze4 PNG library - runtime ii libreadline6 6.1-3 GNU readline and history libraries ii libx11-6 2:1.4.99.901-2X11 client-side library ii libxext6 2:1.3.0-3 X11 miscellaneous extension librar ii libxft22.1.14-2 FreeType-based font drawing librar ii libxine1 1:1.1.20-0.1 Xine video/media player library, m ii libxine1-ffmpeg1:1.1.20-0.1 MPEG-related plugins for libxine1 ii libxine1-x 1:1.1.20-0.1 X desktop video output plugins for ii libxinerama1 2:1.1.1-3 X11 Xinerama extension library ii libxtst6 2:1.1.0-3 X11 Testing -- Record extension li ii libxv1 2:1.0.5-1 X11 Video extension library ii libxxf86vm11:1.1.0-2 X11 XFree86 video mode extension l Versions of packages xine-ui recommends: ii xdg-utils1.0.2+cvs20100307-2 desktop integration utilities from xine-ui suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /var/lib/xine/xine.desktop (from xine-ui package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689595: xine-ui: 0.99.7-1 pulls in libvdpau1, which crashes upon startup on non nvidia hardware
Package: xine-ui
Version: 0.99.7-1
Severity: important
I don't have any nvidia hardware (plain old Intel, TYVM), but xine-ui
insists on pulling in some nvidia specific vdpau crap and crashing
anyway:
231985,31> sudo aptitude install xine-ui/stable
The following packages will be DOWNGRADED:
xine-ui
The following packages will be REMOVED:
libvdpau1{u} libxine2-x{u}
0 packages upgraded, 0 newly installed, 1 downgraded, 2 to remove and 85 not
upgraded.
Need to get 0 B/1,560 kB of archives. After unpacking 455 kB will be freed.
Do you want to continue? [Y/n/?]
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
dpkg: warning: downgrading xine-ui from 0.99.7-1 to 0.99.6-1.
(Reading database ... 401212 files and directories currently installed.)
Preparing to replace xine-ui 0.99.7-1 (using .../xine-ui_0.99.6-1_amd64.deb) ...
Unpacking replacement xine-ui ...
Processing triggers for man-db ...
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for menu ...
(Reading database ... 401208 files and directories currently installed.)
Removing libxine2-x ...
Removing libvdpau1 ...
Setting up xine-ui (0.99.6-1) ...
Updated the MIME types in xine's menu file.
Processing triggers for menu ...
0-1-21:15:14, Thu Oct 04 tconnors@dirac:~/movies/kaffeine (bash)
231986,32> xine -f Cycling\ Central-22.m2t
This is xine (X11 gui) - a free video player v0.99.6.
(c) 2000-2007 The xine Team.
231988,34> sudo aptitude -t unstable install xine-ui
The following NEW packages will be installed:
libvdpau1{a} libxine2-x{a}
The following packages will be upgraded:
xine-ui
1 packages upgraded, 2 newly installed, 0 to remove and 2440 not upgraded.
Need to get 0 B/1,865 kB of archives. After unpacking 455 kB will be used.
Do you want to continue? [Y/n/?]
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
Selecting previously deselected package libvdpau1.
(Reading database ... 401184 files and directories currently installed.)
Unpacking libvdpau1 (from .../libvdpau1_0.4.1-7_amd64.deb) ...
Selecting previously deselected package libxine2-x.
Unpacking libxine2-x (from .../libxine2-x_1%3a1.2.2-dmo3_amd64.deb) ...
Preparing to replace xine-ui 0.99.6-1 (using .../xine-ui_0.99.7-1_amd64.deb) ...
Unpacking replacement xine-ui ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for menu ...
Processing triggers for man-db ...
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Setting up libvdpau1 (0.4.1-7) ...
Setting up libxine2-x (1:1.2.2-dmo3) ...
Setting up xine-ui (0.99.7-1) ...
Updated the MIME types in xine's menu file.
Processing triggers for menu ...
Current status: 2440 updates [-1].
0-1-21:16:15, Thu Oct 04 tconnors@dirac:~/movies/kaffeine (bash)
231989,35> xine -f Cycling\ Central-22.m2t
This is xine (X11 gui) - a free video player v0.99.7.
(c) 2000-2010 The xine Team.
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object
file: No such file or directory
vo_vdpau: Can't create vdp device : No vdpau implementation.
Segmentation fault
Wh!
-- System Information:
Debian Release: 6.0.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1,
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xine-ui depends on:
ii libc6 2.13-10 Embedded GNU C Library: Shared lib
ii libcurl3-gnutls7.25.0-1 easy-to-use client-side URL transf
ii libjpeg8 8c-2 Independent JPEG Group's JPEG runt
ii liblircclient0 0.8.3-5 infra-red remote control support -
ii libpng12-0 1.2.44-1+squeeze4 PNG library - runtime
ii libreadline6 6.1-3 GNU readline and history libraries
ii libx11-6 2:1.4.99.901-2X11 client-side library
ii libxext6 2:1.3.0-3 X11 miscellaneous extension librar
ii libxft22.1.14-2 FreeType-based font drawing librar
ii libxine2 1:1.2.2-dmo3 Xine media player library, meta-pa
ii libxine2-ffmpeg1:1.2.2-dmo3 MPEG-related plugins for libxine2.
ii libxine2-x 1:1.2.2-dmo3 X desktop video output plugins for
ii libxinerama1 2:1.1.1-3 X11 Xinerama extension library
ii libxtst6 2:1.1.0-3 X11 Testing -- Record extension li
ii libxv1 2:1.0.5-1 X11 V
Bug#688508: ccache: new upstream version, 3.1.8
Package: ccache Version: 3.1.6-1 Severity: normal New release: http://ccache.samba.org/releasenotes.html#_ccache_3_1_8 might fix #656022, #672570, and might help increase cache hits for dependency files. -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ccache depends on: ii libc6 2.13-10 Embedded GNU C Library: Shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime ccache recommends no packages. Versions of packages ccache suggests: pn distcc (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659762: LVM locks up, can't do anything.
severity 659762 important thanks Don't quite know when it's acceptable to mark a bug as critical, but "makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package." is probably satisfied when the system becomes unusable and needs a reboot because / is an LVM (er, most debian machines these days given that it's done at install time) and LVM (and all the filesystems under LVM) has locked up, and so one can't run the dmsetup commands mentioned in previous comments to. I've seen this a couple of times now on different systems running 3.2, so something is fundamentally broken. Anyone else yearn for the days when Linux used to be reliable? -- TimC Adding features does not necessarily increase functionality -- it just makes the manuals thicker. --unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508866: still stale filehandles in 3.2 for atomically renamed files
unarchive 508866 reassign 508866 linux-image-3.2.0-2-amd64 unarchive 508866 reopen 508866 thanks . I failed to notice that this bug had been closed/archived, but indeed not yet really fixed. See later comments on https://bugzilla.kernel.org/show_bug.cgi?id=12557#c15 -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508866: still stale filehandles in 3.2 for atomically renamed files
unarchive 508866 reassign 508866 linux-image-3.2.0-1-amd64 unarchive 508866 reopen 508866 thanks . I failed to notice that this bug had been closed/archived, but indeed not yet really fixed. See later comments on https://bugzilla.kernel.org/show_bug.cgi?id=12557#c15 -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#307827: wdiff / colordiff: word highlighting would also be good
On Tue, 22 May 2012, A. Costa wrote: > Only after the bug was closed did I read T. Connors' post, > from 3/14/2008: > > > Also give wdiff a shot > > > > 'wdiff -a' can be used perhaps to highlight those words. > > Not on my system: > > % dlocate -s wdiff | grep Ver > Version: 1.1.0-2 > % man wdiff | grep -A 1 '\-a,' > -a, --auto-pager > automatically calls a pager > > Perhaps you had meant some other switch or util? Have you tried it? Even if I unset $LESS on my system (which normally contains "-R"), wdiff -a automatically pages to less (hmm, maybe you need to set PAGER to "less" rather than "more" too). And if you don't explicitly pipe to a pager and just let "wdiff -a" do it, then wdiff overstrikes the characters such that less (maybe you need a real terminal like xterm rather than something crappy like gnome-terminal) colourises it correctly. -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670260: libxine1: fullscreen in some xinerama configs not right. Seems to be overriding window manager policy
Package: libxine1 Version: 1:1.1.20-0.1 Severity: normal Xine seems to be wilfully overriding window manager policy to the detriment of xinerama setups. On a 2 head display, with each monitor 1680x1050, (adapt values as appropriate on your monitors), I set up the left hand monitor to be the full left hand display, and the right hand monitor to be a panning display twice the width, such that it can display the same as the left hand monitor, or can be panned across to effectively be the right hand monitor. So as far as applications querying xinerama, I've got a 1680x1050 screen and a 3360x1050 screen overlapping it starting at the same top-left location. I initially set up my 2 displays to be to the side of each other: xrandr --output VGA1 --primary xrandr --output VGA1 --right-of LVDS1 Then I start my window manager (fvwm), which initalises itself based on those side by side windows, and run: xrandr --fb 3360x1050 --output LVDS1 --scale 1x1 --output VGA1 --pos 0x0 --panning 3360x1050+0+0/3360x1050+0+0/0/0/0/0 So the output of xrandr looks like this: Screen 0: minimum 320 x 200, current 3360 x 1050, maximum 8192 x 8192 LVDS1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 367mm x 230mm 1920x1200 59.2 + 1920x1080 59.9 1600x1200 60.0 1680x1050 60.0*59.9 1600x1024 60.2 1400x1050 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1360x768 59.8 60.0 1152x864 60.0 1024x768 60.0 800x60060.3 56.2 640x48059.9 VGA1 connected 3360x1050+0+0 (normal left inverted right x axis y axis) 473mm x 296mm panning 3360x1050+0+0 1680x1050 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x60075.0 60.3 640x48075.0 60.0 720x40070.1 2560x1440 60.0 Other video players have no problem with this - eg. totem and mplayer. If I fullscreen them, then they just seem to ask the window manager to look after maximisation, and then display the video within the viewport defined by that window. And the window manager happily obliges as hands totem either the left hand or right hand half of the display dependant on where the mouse cursor was. Excellent - the window manager is able to do its job. But gxine and xine instead seem to want to maximise to show the video display in the exact centre of the 3360x1050 screen, split across the two monitors (so it might be querying xinerama directly, and looking at the value of the primary screen? Or the biggest? Instead of asking the window manager to do what window managers are meant to do, and you know, manage windows). Worse is that it calculates where to display the video port based on the centre of this 3360x1050 display, but then asks the window manager to maximise the window. Which it does. The two viewports are not in agreement! You get a left half chopped off video displaying in the right hand half of a window opened up on the left hand screen! -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libxine1 depends on: ii libxine1-console1:1.1.20-0.1 libaa/libcaca/framebuffer/directfb ii libxine1-misc-plugins 1:1.1.20-0.1 Input, audio output and post plugi ii libxine1-x 1:1.1.20-0.1 X desktop video output plugins for Versions of packages libxine1 recommends: ii libxine1-ffmpeg 1:1.1.20-0.1 MPEG-related plugins for libxine1 Versions of packages libxine1 suggests: ii gxine 0.5.906-1+b3 the xine video player, GTK+/Gnome ii libxine1-doc [libxine-doc] 1:1.1.20-0.1 Xine video player library, documen ii xine-ui 0.99.6-1 the xine video player, user interf -- 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#582083: patch for grep --color to non-tty output
On Tue, 24 Apr 2012, Jim Meyering wrote:
> Aníbal Monsalve Salazar wrote:
> > Debian bug report is posted at:
> >
> > http://bugs.debian.org/582083
> ...
> >>There's no reason not to obey the user when they ask for "--color",
> >>regardless of whether the output is to a tty or not. They wouldn't
> >>have asked for --color if they didn't want it, and most other gnu
> >>programs assume --color=yes rather than --color=auto when supplied with
> >>just --color. Man and info pages and translations appear to need to
> >>work since they don't imply what the default is. Nice easy patch to
> >>apply!
> >>
> >>[1] New version looks like:
> >>diff -ru grep-2.10//src/main.c /tmp/grep-2.10//src/main.c
> >>--- grep-2.10//src/main.c 2012-04-24 13:11:57.0 +1000
> >>+++ /tmp/grep-2.10//src/main.c 2012-04-24 12:56:47.0 +1000
> >>@@ -2059,7 +2059,7 @@
> >> else
> >> show_help = 1;
> >> } else
> >>- color_option = 2;
> >>+ color_option = 1;
> >> if (color_option == 2)
> >> {
> >> char const *t;
>
> Thanks for the report of the documentation bug and the patch, but the patch
> (changing the meaning of --color from --color=auto to --color=always)
> would break existing usage.
>
> Currently, people can use --color in an always-on alias/function
> or set the GREP_OPTIONS=--color envvar and get colorized output,
> yet not have those ANSI terminal highlighting bytes interfere
> with output that is not to a tty.
>
> If we were to make your proposed change, they'd find those
> color codes in unexpected (and undesirable) places.
Easy to fix! Fix the bug in their login scripts!
> However, this is definitely a documentation bug, and I'd
> appreciate a patch for both --help and grep.texi.
>
> Jim
>
> PS. True, it is undesirable to have grep's --color(with no value)
> default to "auto", when in ls it defaults to "always", but changing
> grep's default now would be too disruptive. We'd have to warn that
> the default is going to change for a year or two before making the
> actual change, and even then, some users would be impacted.
It doesn't take much to change one's .rc files to say
GREP_OPTIONS="--color=auto" rather than "--color"! They should have been
doing that all along (because they were relying on undocumented behaviour
:).
I personally have "GREP_OPTIONS=--color=auto". If the output is a tty,
that works as expected. If the output is a pipe, no color as expected;
all good. If the output is "less -R", I want --color, so I say
"echo test | grep --color es", and I don't get color. That's not what I
asked for!
--
Tim Connors
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
