Bug#1071711: libecal-2.0-2: No -dev package for libecal-2.0-2

2024-05-23 Thread E Harris
Package: libecal-2.0-2
Version: 3.46.4-2
Severity: normal

It appears that there is no -dev package for libecal-2.0.
How to build apps that depend on it?


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

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

Versions of packages libecal-2.0-2 depends on:
ii  libc6  2.36-9+deb12u7
ii  libcamel-1.2-643.46.4-2
ii  libedataserver-1.2-27  3.46.4-2
ii  libglib2.0-0   2.74.6-2+deb12u2
ii  libical3   3.0.16-1+b1

libecal-2.0-2 recommends no packages.

libecal-2.0-2 suggests no packages.

-- no debconf information



Bug#1069125: zfs-dkms: Update stable version to fix data corruption bug

2024-04-16 Thread E Harris
Package: zfs-dkms
Version: 2.1.11-1
Severity: important
Tags: upstream

OpenZFS version 2.1.14 (or later) contains an important data corruption
bugfix for prior versions.  Since stable still has 2.1.11, it would seem
that upgrading the zfs version to 2.1.14 or latest 2.1.15 is warranted?

See release notes here: https://github.com/openzfs/zfs/releases

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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  dkms   3.0.10-8+deb12u1
ii  file   1:5.44-3
ii  libc6-dev [libc-dev]   2.36-9+deb12u4
ii  libpython3-stdlib  3.11.2-1+b1
ii  lsb-release12.0-1
ii  perl   5.36.0-7+deb12u1
ii  python3-distutils  3.11.2-3

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  6.1.85-1
ii  zfs-zed 2.1.11-1
ii  zfsutils-linux  2.1.11-1

Versions of packages zfs-dkms suggests:
ii  debhelper  13.11.4

-- debconf-show failed



Bug#1062600: ffmpeg: mp3 decoding reports error (junk in stream) when there is none

2024-02-01 Thread E Harris
Package: ffmpeg
Version: 7:5.1.4-0+deb12u1
Severity: normal

When using avcodec_receive_frame() via libchromaprint1 and fpcalc to decode
mp3 files, some mp3 files are reported as having errors when there are none,
it has just reached end of file.

The error returned from libchromaprint1 via fpcalc is:

ERROR: Error decoding audio frame (End of file)

and results from avcodec_receive_frame() returning a negative value in some
circumstances when reaching the end of input.

mp3val and mp3diags report no problems with the mp3 files in question.

Processing the same input file using ffmpeg also seems to report no errors
or warnings even with -loglevel debug:

Test Command: ffmpeg -i test.mp3 -loglevel debug out.pcm


Opening an input file: test.mp3.
[NULL @ 0x555999b62940] Opening 'test.mp3' for reading
[file @ 0x555999b63180] Setting default whitelist 'file,crypto,data'
[mp3 @ 0x555999b62940] Format mp3 probed with size=4096 and score=51
[mp3 @ 0x555999b62940] Skipping 0 bytes of junk at 0.
[mp3 @ 0x555999b62940] Before avformat_find_stream_info() pos: 0 bytes 
read:65664 seeks:2 nb_streams:1
[mp3 @ 0x555999b62940] All info found
[mp3 @ 0x555999b62940] Estimating duration from bitrate, this may be inaccurate
[mp3 @ 0x555999b62940] After avformat_find_stream_info() pos: 21504 bytes 
read:65664 seeks:2 frames:50
Input #0, mp3, from 'test.mp3':
  Duration: 00:01:08.05, start: 0.00, bitrate: 128 kb/s
  Stream #0:0, 50, 1/14112000: Audio: mp3, 44100 Hz, stereo, fltp, 128 kb/s
Successfully opened the file.
Parsing a group of options: output url out.pcm.
Successfully parsed a group of options.
Opening an output file: out.pcm.
[file @ 0x555999b73940] Setting default whitelist 'file,crypto,data'
Successfully opened the file.
Stream mapping:
  Stream #0:0 -> #0:0 (mp3 (mp3float) -> adpcm_ima_alp (native))
Press [q] to stop, [?] for help
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it 
occurs once at the start per stream)
detected 4 logical cores
[graph_0_in_0_0 @ 0x555999b78180] Setting 'time_base' to value '1/44100'
[graph_0_in_0_0 @ 0x555999b78180] Setting 'sample_rate' to value '44100'
[graph_0_in_0_0 @ 0x555999b78180] Setting 'sample_fmt' to value 'fltp'
[graph_0_in_0_0 @ 0x555999b78180] Setting 'channel_layout' to value 'stereo'
[graph_0_in_0_0 @ 0x555999b78180] tb:1/44100 samplefmt:fltp samplerate:44100 
chlayout:stereo
[format_out_0_0 @ 0x555999b79380] Setting 'sample_fmts' to value 's16'
[format_out_0_0 @ 0x555999b79380] Setting 'channel_layouts' to value 
'mono|stereo'
[format_out_0_0 @ 0x555999b79380] auto-inserting filter 'auto_aresample_0' 
between the filter 'Parsed_anull_0' and the filter 'format_out_0_0'
[AVFilterGraph @ 0x555999b659c0] query_formats: 4 queried, 6 merged, 3 already 
done, 0 delayed
[auto_aresample_0 @ 0x555999b7abc0] [SWR @ 0x555999b8de40] Using fltp 
internally between filters
[auto_aresample_0 @ 0x555999b7abc0] ch:2 chl:stereo fmt:fltp r:44100Hz -> ch:2 
chl:stereo fmt:s16 r:44100Hz
Output #0, alp, to 'out.pcm':
  Metadata:
encoder : Lavf59.27.100
  Stream #0:0, 0, 1/44100: Audio: adpcm_ima_alp, 44100 Hz, stereo, s16, 352 kb/s
Metadata:
  encoder : Lavc59.37.100 adpcm_ima_alp
[out_0_0 @ 0x555999b78f80] EOF on sink link out_0_0:default.=2.32e+04x
No more output streams to write to, finishing.
size=2931kB time=00:01:08.04 bitrate= 352.8kbits/s speed= 212x
video:0kB audio:2931kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: 0.000666%
Input file #0 (test.mp3):
  Input stream #0:0 (audio): 2605 packets read (1088784 bytes); 2605 frames 
decoded (3000960 samples); 
  Total: 2605 packets (1088784 bytes) demuxed
Output file #0 (out.pcm):
  Output stream #0:0 (audio): 2931 frames encoded (3000960 samples); 2931 
packets muxed (3000960 bytes); 
  Total: 2931 packets (3000960 bytes) muxed
[AVIOContext @ 0x555999b73a40] Statistics: 3000980 bytes written, 0 seeks, 12 
writeouts
2605 frames successfully decoded, 0 decoding errors
[AVIOContext @ 0x555999b6b540] Statistics: 1121680 bytes read, 2 seeks


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

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

Versions of packages ffmpeg depends on:
ii  libavcodec597:5.1.4-0+deb12u1
ii  libavdevice59   7:5.1.4-0+deb12u1
ii  libavfilter87:5.1.4-0+deb12u1
ii  libavformat59   7:5.1.4-0+deb12u1
ii  libavutil57 7:5.1.4-0+deb12u1
ii  libc6   2.36-9+deb12u3
ii  libpostproc56   7:5.1.4-0+deb12u1
ii  libsdl2-2.0-0   2.26.5+dfsg-1
ii  libswresample4  7:5.1.4-0+deb12u1
ii 

Bug#1062584: libchromaprint1: Incorrect handling of end of input file

2024-02-01 Thread E Harris
Package: libchromaprint1
Version: 1.5.1-2+b1
Severity: normal

There seems to be a bug in libchromaprint1 that is causing errors to
sometimes be reported when normal end of file has been reached.  This
then causes errors to be reported from fpcalc, which breaks picard
fingerprint calculation and submission in certain cases.

mp3val on the mp3 source reports no problems, so I don't think the
files that trigger this are actually damaged in any way.

The error being returned (via fpcalc) is:

ERROR: Error decoding audio frame (End of file)

This seems to stem from the inline FFmpegAudioReader::Read() in
src/audio/ffmpeg_audio_reader.h


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

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

Versions of packages libchromaprint1 depends on:
ii  libavcodec59  7:5.1.4-0+deb12u1
ii  libavutil57   7:5.1.4-0+deb12u1
ii  libc6 2.36-9+deb12u3
ii  libgcc-s1 12.2.0-14
ii  libstdc++612.2.0-14

libchromaprint1 recommends no packages.

libchromaprint1 suggests no packages.

-- no debconf information



Bug#1062583: poc-streamer: mp3-cut shortens output unexpectedly

2024-02-01 Thread E Harris
Package: poc-streamer
Version: 0.4.2-7
Severity: normal

When using mp3cut to take the whole file, repeated invocations shorten the
output unexpectedly.

Example:

> mp3cut -o test2.mp3 test.mp3
Writing to test2.mp3
Extracting 00:00:00+000-00:00:00+000 from test.mp3
test2.mp3 written
> mp3cut -o test3.mp3 test2.mp3
Writing to test3.mp3
Extracting 00:00:00+000-00:00:00+000 from test2.mp3
test3.mp3 written
> mp3cut -o test4.mp3 test3.mp3
Writing to test4.mp3
Extracting 00:00:00+000-00:00:00+000 from test3.mp3
test4.mp3 written
> ls -l *.mp3
-rw-r- 1 1000 1008 1088784 Feb  1 20:25  test.mp3
-rwxr- 1 1000 1008 1087602 Feb  1 20:38  test2.mp3
-rwxr- 1 1000 1008 1086348 Feb  1 20:38  test3.mp3
-rwxr- 1 1000 1008 1085094 Feb  1 20:38  test4.mp3

As you can see from this output, each invocation is causing data to be lost
(each file is successively smaller) even though the full file is supposed
to be copied.


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

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

Versions of packages poc-streamer depends on:
ii  libc6   2.36-9+deb12u3
ii  libfl2  2.6.4-8.2

poc-streamer recommends no packages.

poc-streamer suggests no packages.

-- no debconf information



Bug#1062530: libchromaprint-tools: fpcalc often gives decoding error when fingerprinting audio files

2024-02-01 Thread E Harris
Package: libchromaprint-tools
Version: 1.5.1-2+b1
Severity: normal

I'm fairly often seeing fpcalc giving the following error when fingerprinting
mp3 audio files (via picard) even when there doesn't appear to be any problem
with the file (mp3val reports no problems with the files):

ERROR: Error decoding audio frame (End of file)

The fingerprint still seems to be generated, but picard ignores the
fingerprint because fpcalc is also returning rc = 3.

I think that this might be caused by a problem within the ffmpeg libs that
fpcalc is using?


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

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

Versions of packages libchromaprint-tools depends on:
ii  libavcodec59 7:5.1.4-0+deb12u1
ii  libavformat597:5.1.4-0+deb12u1
ii  libavutil57  7:5.1.4-0+deb12u1
ii  libc62.36-9+deb12u3
ii  libchromaprint1  1.5.1-2+b1
ii  libgcc-s112.2.0-14
ii  libstdc++6   12.2.0-14
ii  libswresample4   7:5.1.4-0+deb12u1

libchromaprint-tools recommends no packages.

libchromaprint-tools suggests no packages.

-- no debconf information



Bug#1061228: xzgv does not support displaying avif images

2024-01-20 Thread E Harris
Package: xzgv
Version: 0.9.2-2+b1
Severity: normal

xzgv does not seem to support displaying avif images.
When trying to display one, it shows an error dialog with "Couldn't load image!"

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

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

Versions of packages xzgv depends on:
ii  libc62.36-9+deb12u3
ii  libexif120.6.24-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk2.0-0  2.24.33-2
ii  libx11-6 2:1.8.4-2+deb12u2

xzgv recommends no packages.

xzgv suggests no packages.

-- debconf-show failed



Bug#1061227: xzgv does not display heic images

2024-01-20 Thread E Harris
Package: xzgv
Version: 0.9.2-2+b1
Severity: normal

xzgv does not seem to support displaying heic images.
When trying to display them, it shows an error dialog "Couldn't load image".

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

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

Versions of packages xzgv depends on:
ii  libc62.36-9+deb12u3
ii  libexif120.6.24-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk2.0-0  2.24.33-2
ii  libx11-6 2:1.8.4-2+deb12u2

xzgv recommends no packages.

xzgv suggests no packages.

-- debconf-show failed



Bug#1061225: gthumb ignores quicktime video orientation on playback

2024-01-20 Thread E Harris
Package: gthumb
Version: 3:3.12.2-3+b1
Severity: normal

gthumb appears to ignore quicktime video orientation on playback, causing
the playback to have the wrong orientation.

I have many videos that were recorded on an iphone in standard letterbox
format, but that play back upside-down when viewed with gthumb.

VLC and other players seem to play them back just fine.

ExifTool reports these tags for these videos:

"Composite:Rotation": 180
"QuickTime:MatrixStructure": "1 0 0 0 1 0 0 0 1"

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

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

Versions of packages gthumb depends on:
ii  gsettings-desktop-schemas   43.0-1
ii  gthumb-data 3:3.12.2-3
ii  libbrasero-media3-1 3.12.3-2
ii  libc6   2.36-9+deb12u3
ii  libcairo2   1.16.0-7
ii  libchamplain-0.12-0 0.12.20-1+b1
ii  libchamplain-gtk-0.12-0 0.12.20-1+b1
ii  libclutter-1.0-01.26.4+dfsg-4
ii  libclutter-gtk-1.0-01.8.4-4+b1
ii  libcolord2  1.4.6-2.2
ii  libexiv2-27 0.27.6-1
ii  libgcc-s1   12.2.0-14
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libgl1-mesa-dri 22.3.6-1+deb12u1
ii  libglib2.0-02.74.6-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3+deb12u1
ii  libgstreamer1.0-0   1.22.0-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libheif11.15.1-1
ii  libjpeg62-turbo 1:2.1.5-2
ii  liblcms2-2  2.14-2
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpangocairo-1.0-0 1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libraw200.20.2-2.1
ii  librsvg2-2  2.54.7+dfsg-1~deb12u1
ii  libsecret-1-0   0.20.5-3
ii  libsoup2.4-12.74.3-1
ii  libstdc++6  12.2.0-14
ii  libtiff64.5.0-6+deb12u1
ii  libwebkit2gtk-4.0-372.42.4-1~deb12u1
ii  libwebp71.2.4-0.2+deb12u1
ii  libx11-62:1.8.4-2+deb12u2
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages gthumb recommends:
ii  libgphoto2-6   2.5.30-1
ii  libgphoto2-port12  2.5.30-1

gthumb suggests no packages.

-- debconf-show failed



Bug#1059463: ejabberd logging as process "sh", appearing to be shell connections?

2023-12-26 Thread E Harris
Package: ejabberd
Version: 23.01-1
Severity: normal

I've noticed that ejabberd is logging some messages with the process name "sh" 
rather than ejabberd.
When I first noticed these, I was concerned that there might have been an 
unauthorized shell service
backdoor setup to compromise the system.
Why are these logged with this misleading and concerning service name?

Example:

Dec 26 04:04:41 somehost sh[5311]: 2023-12-26 04:04:41.724966-06:00 [info] 
(<0.980.1>) Accepted connection 127.0.0.1:49934 -> 127.0.0
.1:5269
Dec 26 04:04:45 somehost sh[5311]: 2023-12-26 04:04:45.911985-06:00 [info] 
Closing inbound s2s connection 127.0.0.1 -> somehost.com: Stream closed by 
local host: not well-formed (invalid token) (not-well-formed)


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

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

Versions of packages ejabberd depends on:
ii  adduser 3.134
ii  debconf [debconf-2.0]   1.5.82
ii  erlang-asn1 1:25.2.3+dfsg-1
ii  erlang-base [erlang-abi]1:25.2.3+dfsg-1
ii  erlang-base64url1.0.1-6
ii  erlang-crypto   1:25.2.3+dfsg-1
ii  erlang-goldrush 0.2.0-8
ii  erlang-idna 6.1.1-4
ii  erlang-inets1:25.2.3+dfsg-1
ii  erlang-jiffy1.1.1-1
ii  erlang-jose 1.11.5-1
ii  erlang-lager3.9.2-2
ii  erlang-mnesia   1:25.2.3+dfsg-1
ii  erlang-odbc 1:25.2.3+dfsg-1
ii  erlang-os-mon   1:25.2.3+dfsg-1
ii  erlang-p1-acme  1.0.22-1
ii  erlang-p1-cache-tab 1.0.30-2
ii  erlang-p1-eimp  1.0.22-2
ii  erlang-p1-mqtree1.0.15-2
ii  erlang-p1-pkix  1.0.9-2
ii  erlang-p1-stringprep1.0.29-2
ii  erlang-p1-stun  1.2.7-1
ii  erlang-p1-tls   1.1.16-2
ii  erlang-p1-utils 1.0.25-2
ii  erlang-p1-xml   1.1.49-2
ii  erlang-p1-xmpp  1.6.1-1
ii  erlang-p1-yaml  1.0.36-1
ii  erlang-p1-yconf 1.0.15-1
ii  erlang-p1-zlib  1.0.12-2
ii  erlang-public-key   1:25.2.3+dfsg-1
ii  erlang-ssl  1:25.2.3+dfsg-1
ii  erlang-syntax-tools 1:25.2.3+dfsg-1
ii  erlang-unicode-util-compat  0.7.0-4
ii  erlang-xmerl1:25.2.3+dfsg-1
ii  init-system-helpers 1.65.2
ii  openssl 3.0.11-1~deb12u2
ii  ucf 3.0043+nmu1

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
ii  apparmor 3.0.8-3
pn  apparmor-utils   
ii  ejabberd-contrib 0.2023.01.25~dfsg0-1
pn  erlang-luerl 
pn  erlang-p1-mysql  
pn  erlang-p1-oauth2 
pn  erlang-p1-pam
pn  erlang-p1-pgsql  
pn  erlang-p1-sip
pn  erlang-p1-sqlite3
pn  erlang-redis-client  
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  libunix-syslog-perl  1.1-4+b1
pn  yamllint 

-- Configuration Files:
/etc/default/ejabberd changed [not included]
/etc/ejabberd/inetrc [Errno 13] Permission denied: '/etc/ejabberd/inetrc'
/etc/ejabberd/modules.d/README.modules [Errno 13] Permission denied: 
'/etc/ejabberd/modules.d/README.modules'

-- debconf information excluded



Bug#1057966: ntpsec-ntpdate not fully compatible with ntpdate, causes adjtimex --host breakage

2023-12-10 Thread E Harris
Package: ntpsec-ntpdate
Version: 1.2.2+dfsg1-1+deb12u1
Severity: normal

When attempting to use adjtimex --host command, it fails due to current
ntpdate not being fully compatible with previous ntpdate package.

# adjtimex --host 66.118.228.14
ntpdate: -p is no longer supported.
ntpdig: querying 66.118.228.14 (66.118.228.14)
cannot understand ntpdate output


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

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

Versions of packages ntpsec-ntpdate depends on:
ii  netbase6.4
ii  ntpsec-ntpdig  1.2.2+dfsg1-1+deb12u1

ntpsec-ntpdate recommends no packages.

ntpsec-ntpdate suggests no packages.

-- debconf-show failed



Bug#1057965: adjtimex --host not working with change to ntpsec-ntpdate

2023-12-10 Thread E Harris
Package: adjtimex
Version: 1.29-11+b1
Severity: normal

When trying to use the adjtimex --host option, it fails with:

# adjtimex --host 66.118.228.14
ntpdate: -p is no longer supported.
ntpdig: querying 66.118.228.14 (66.118.228.14)
cannot understand ntpdate output

This seems to be caused by the change to replace the ntpdate package with
ntpsec-ntpdate, which is not fully compatible.


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

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

Versions of packages adjtimex depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u3
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

adjtimex recommends no packages.

Versions of packages adjtimex suggests:
pn  ntpdate  

-- debconf-show failed



Bug#1057887: bind9 named logging for category rpz misses some rpz log messages

2023-12-10 Thread E Harris
Package: bind9
Version: 1:9.18.19-1~deb12u1
Severity: normal

When bind9/named is configured to log category rpz messages to a file, some
rpz log messages are not captured and sent to the intended destination.

Example:

Add the following stanza in named.conf.options:

logging {
channel rpzlog {
file "/var/log/named/rpz.log" versions unlimited size 100m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
category rpz { rpzlog; };
};

With this configuration for logging, most rpz log messages are properly
sent to the intended file (NXDOMAIN items), but some rpz messages are not.
So far, the ones that seem not to be properly captured by this log destination
are rpz "passthru" lookups.

Example log messages that end up in the default syslog/journald rather than
the configured log file:

Dec 10 01:29:41 somehostn named[327739]: client @0x7fee327a6568 127.0.0.1#35809 
(some.domain.name): rpz QNAME PASSTHRU rewrite some.domain.name/A/IN via 
some.domain.name.rpz.local
Dec 10 01:29:41 somehost named[327739]: client @0x7fee32785768 127.0.0.1#35809 
(some.domain.name): rpz QNAME PASSTHRU rewrite some.domain.name//IN via 
some.domain.name.rpz.local

Example rpz entry that generates log entries that fail to go to the rpz 
category/destination:
some.domain.name   CNAME   rpz-passthru.

Example rpz entry that generates log entries that do go to the proper rpz 
category/destination:
other.domain.name  CNAME   .


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

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

Versions of packages bind9 depends on:
ii  adduser3.134
ii  bind9-libs 1:9.18.19-1~deb12u1
ii  bind9-utils1:9.18.19-1~deb12u1
ii  debconf [debconf-2.0]  1.5.82
ii  dns-root-data  2023010101
ii  init-system-helpers1.65.2
ii  iproute2   6.1.0-3
ii  libc6  2.36-9+deb12u3
ii  libcap21:2.66-4
ii  libfstrm0  0.6.1-1
ii  libjson-c5 0.16-2
ii  liblmdb0   0.9.24-1
ii  libmaxminddb0  1.7.1-1
ii  libnghttp2-14  1.52.0-1+deb12u1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libssl33.0.11-1~deb12u2
ii  libsystemd0252.19-1~deb12u1
ii  libuv1 1.44.2-1
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  lsb-base   11.6
ii  netbase6.4
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.18.19-1~deb12u1
ii  dnsutils   1:9.18.19-1~deb12u1
ii  resolvconf 1.91+nmu1
ii  ufw0.36.2-1

-- Configuration Files:
/etc/bind/db.root [Errno 13] Permission denied: '/etc/bind/db.root'
/etc/bind/named.conf changed [not included]
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options [Errno 13] Permission denied: 
'/etc/bind/named.conf.options'

-- debconf-show failed



Bug#1038937: nq package out of date with upstream, 0.5 was released more than a year ago

2023-06-23 Thread E Harris
Package: nq
Version: 0.3.1-4
Severity: normal

nq 0.5 was released March 26, 2022 and contains several bug fixes and 
improvements.
nq 0.3.1 was released March 7, 2018, and is what is in all of stable, testing, 
and unstable.
Please update this package.

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

Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.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 nq depends on:
ii  libc6  2.31-13+deb11u6

nq recommends no packages.

nq suggests no packages.

-- no debconf information



Bug#1035525: sendmail-bin: Change log level of saslauthd failed auth attempts

2023-05-04 Thread E Harris
Package: sendmail-bin
Version: 8.15.2-22
Severity: normal
Tags: upstream

It seems to be a pretty big security issue that there is no coherent 
reporting/logging
of failed auth login attempts when using saslauthd with sendmail.

The saslauthd log lines for failed auth attempts are similar to this:

May 04 13:32:49 somehost saslauthd[2996]: : auth failure: 
[user=mailtest] [service=smtp] [realm=somerealm] [mech=pam] [reason=PAM auth 
error]

But saslauthd does not report the ip address that originated the auth attempt
(probably because it doesn't know it?), and sendmail (by default) doesn't seem
to report the failed auth attempt at all.

This deficiency prevents trying to take active steps (for example using 
fail2ban) to
try to protect against repeated brute force auth hacking attempts.

I think that sendmail may already have the ability to report AUTH failures, but 
that those
are only enabled with high log levels that include lots of other log spam.

It seems to me that a failed auth login should be reported by default by 
sendmail,
since it both knows the IP the attempt originated from, as well as the status 
of the
auth attempt, and I would like to see this reporting enabled in the standard 
packages.

If there is a way to easily indicate that the auth attempt is for a user that 
doesn't
even exist, that would be even better, as that would be a pretty clear 
indication of a
potential hack attempt.

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.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 sendmail-bin depends on:
ii  debconf  1.5.77
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u5
ii  libdb5.3 5.3.28+dfsg1-0.8
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  liblockfile1 1.17-1+b1
ii  libnsl2  1.3.0-2
ii  libsasl2-2   2.1.27+dfsg-2.1+deb11u1
ii  libssl1.11.1.1n-0+deb11u4
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  procps   2:3.3.17-5
ii  sendmail-base8.15.2-22
ii  sendmail-cf  8.15.2-22

sendmail-bin recommends no packages.

Versions of packages sendmail-bin suggests:
ii  libsasl2-modules  2.1.27+dfsg-2.1+deb11u1
ii  openssl   1.1.1n-0+deb11u4
ii  sasl2-bin 2.1.27+dfsg-2.1+deb11u1
ii  sendmail-doc  8.15.2-22

Versions of packages libmilter1.0.1 depends on:
ii  libc6  2.31-13+deb11u5

-- no debconf information



Bug#990623: Cmake in Bullseye can't find Postgresql that ships with Bullseye

2021-07-02 Thread Timothy E. Harris

Package: cmake
Version: 3.18.4-2|
|

|Cmake in bullseye can't find |the postgresql-13 version which ships in 
bullseye.
This is because |lines 89/90 of 
/usr/share/cmake-3.18/Modules/FindPostgreSQL.cmake has this:|


|set(PostgreSQL_KNOWN_VERSIONS ${PostgreSQL_ADDITIONAL_VERSIONS}
        "12" "11" "10" "9.6" "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" 
"8.3" "8.2" "8.1" "8.0")

|

|changing it to|

|set(PostgreSQL_KNOWN_VERSIONS ${PostgreSQL_ADDITIONAL_VERSIONS}
        "13" "12" "11" "10" "9.6" "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" 
"8.4" "8.3" "8.2" "8.1" "8.0")

|

|is sufficient to correct the problem.|


Bug#984515: fail2ban: Pattern from named-refused.conf filter failing to match log lines

2021-03-04 Thread E Harris
Package: fail2ban
Version: 0.10.2-2.1
Severity: normal

There is a problem in the regex matching for the optional named-refused filter.

Log messages from named that should be matched by this filter are not being 
matched because the log pattern for the host is different than expected.

Specifically, it seems to be a problem with the prefregex portion of the 
pattern.
An example log line is:

Mar  4 07:32:52 myhost named[1390966]: client @0x7ff989af9780 124.81.141.74#53 
(.): query (cache) './ANY/IN' denied

The stock prefregex is causing match failures because of the '@0x7ff989af9780 ' 
portion of the log message.


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

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

Versions of packages fail2ban depends on:
ii  lsb-base  10.2019051400
ii  python3   3.7.3-1

Versions of packages fail2ban recommends:
ii  iptables   1.8.2-4
ii  nftables   0.9.0-2
ii  python 2.7.16-1
ii  python3-pyinotify  0.9.6-1
ii  python3-systemd234-2+b1
ii  whois  5.4.3

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
pn  monit
ii  rsyslog [system-log-daemon]  8.1901.0-1
ii  sqlite3  3.27.2-3+deb10u1

-- no debconf information



Bug#816119: testdisk: include qphotorec

2021-03-02 Thread Timothy E. Harris
The only reason the Qphotorec GUI is not built with the current bullseye 
7.1-5 testdisk packaging is that the necessary Qt libraries:


qtbase5-dev and qttools5-dev-tools

are not listed as Build-Depends.  Adding them to the control file and 
building results in the testdisk package which includes the qphotorec 
binary and desktop file.




Bug#966829: linux-image-4.19.0-9-amd64: USB subsystem hangs with 4.19.0/buster series kernels

2020-08-02 Thread E Harris
Package: src:linux
Version: 4.19.118-2+deb10u1
Severity: important

Since upgrading to buster from stretch several months ago (in Feb 2020), I
have been experiencing unpredictable but repeated hangs of USB devices. 
The hangs are somewhat random, and have occurred anywhere from a few hours
after boot to a week or more after boot, with it happening most commonly
after about 2-3 days.

Although this sometimes occurs right after a device reports a read error or
other USB transaction that does not immediately complete, that does not seem
to always be the case.  Often there are also USB device resets near a hang,
I am not sure if they may be a contributing factor, or just a result of the
hang.

I haven't reported this problem before now because the problem isn't easy
to reproduce in a predictable manner, and I have been trying to narrow 
down if it might be device related.  Although it does seem to happen more
frequently on a device that currently has unreadable sectors, it also 
occurs with other devices that do not have read errors.

The hangs have at least once seemed to occur with USB devices other than 
USB harddrives (once was with a USB bluetooth 4.0 adapter).

Since I have several external USB3 hard drives when these hangs occur, it 
tends to cause filesystem lockups which then cause hard process hangs of 
anything that attempts access to those filesystems.  Due to the way linux
VFS works, the only solution to get the system back into a normal 
state is a reboot.  In all cases, a soft reboot (not hard powered off of 
either the machine or USB devices) has gotten things working again, which
leads me to believe that it is not actually a problem with any USB device,
but with the Linux kernel USB subsystem itself.

This also occurred with linux-image-4.19.0-8-amd64, and I am upgrading to 
linux-image-4.19.0-10-amd64 now.

I had no experiences of this type with the older stretch series of kernels
(4.9.0 series), which ran for years on this exact same hardware (with the
exception of one hard drive which has been replaced) with no problems.
In fact, while trying to narrow this problem down, I rebooted and ran
stretch kernel linux-image-4.9.0-12-amd64 for a few weeks and again
had no problems, even though read errors on the device mentioned above
occurred several times (I was using ddrescue to recover data at that time).

The tainted kernel is caused by the zfs drivers, which are used in a zfs
zpool on top of LUKS encrypted drives.

The USB3 cards in use are based on the NEC uPD720200 and uPD720201 chips.
I tried replacing the USB3 PCIe cards with known good ones, no difference.
So I put the original ones back in.

Here are the kernel log messages surrounding a typical hang:

[770583.827725] usb 2-4: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[770614.676494] usb 2-4: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[770614.702802] sd 9:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_TIME_OUT 
driverbyte=DRIVER_OK
[770614.702819] sd 9:0:0:0: [sdf] tag#0 CDB: Read(16) 88 00 00 00 00 00 de e1 
05 a0 00 00 00 b0 00 00
[770614.702827] print_req_error: I/O error, dev sdf, sector 3739288992
[770645.393118] usb 2-4: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[770645.418426] sd 9:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_TIME_OUT 
driverbyte=DRIVER_OK
[770645.418437] sd 9:0:0:0: [sdf] tag#0 CDB: Read(16) 88 00 00 00 00 00 de e1 
05 40 00 00 00 58 00 00
[770645.418440] print_req_error: I/O error, dev sdf, sector 3739288896
[770663.557525] INFO: task rclone:397934 blocked for more than 120 seconds.
[770663.557537]   Tainted: P   OE 4.19.0-9-amd64 #1 Debian 
4.19.118-2+deb10u1
[770663.557541] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[770663.557547] rclone  D0 397934   7932 0x
[770663.557556] Call Trace:
[770663.557576]  ? __schedule+0x2a2/0x870
[770663.557586]  schedule+0x28/0x80
[770663.557594]  io_schedule+0x12/0x40
[770663.557603]  blk_mq_get_tag+0x115/0x260
[770663.557610]  ? finish_wait+0x80/0x80
[770663.557618]  blk_mq_get_request+0xc1/0x3c0
[770663.557625]  blk_mq_make_request+0x131/0x530
[770663.557634]  generic_make_request+0x1a4/0x400
[770663.557642]  submit_bio+0x45/0x130
[770663.557812]  vdev_disk_io_start+0x603/0x6d0 [zfs]
[770663.557957]  zio_vdev_io_start+0x108/0x330 [zfs]
[770663.558097]  zio_nowait+0xc3/0x150 [zfs]
[770663.558242]  vdev_raidz_io_start+0x13a/0x2d0 [zfs]
[770663.558381]  zio_vdev_io_start+0x108/0x330 [zfs]
[770663.558525]  ? vdev_config_sync+0x180/0x180 [zfs]
[770663.558685]  zio_nowait+0xc3/0x150 [zfs]
[770663.558829]  ? vdev_config_sync+0x180/0x180 [zfs]
[770663.558972]  vdev_mirror_io_start+0x8b/0x160 [zfs]
[770663.559118]  ? spa_config_enter+0xb2/0x100 [zfs]
[770663.559256]  zio_vdev_io_start+0x2d0/0x330 [zfs]
[770663.559280]  ? tsd_get_by_thread+0x2a/0x40 [spl]
[770663.559417]  zio_nowait+0xc3/0x150 [zfs]
[770663.559537]  arc_read+0x617/0xa50 [zfs]
[770663.559659]  ? 

Bug#966652: coreutils: chmod/chgrp/chown causes ctime change even when no change needed

2020-08-01 Thread E Harris
Package: coreutils
Version: 8.30-3
Severity: normal
Tags: upstream

GNU chmod/chgrp/chown have an issue that causes the ctime to change on every
file, even when no change to the mode/ownership was made.  This is a problem
for backup and file-integrity checking software that uses the ctime (since 
it cannot be trivially reset to hide a file change, unlike mtime) to detect
if changes might have been made to a file.

> stat test
  File: test
  Size: 0   Blocks: 0  IO Block: 4096   regular empty file
Device: fd05h/64773dInode: 10424846Links: 1
Access: (0640/-rw-r-)  Uid: ( 1000/ user)   Gid: ( 1000/ user)
Access: 2020-08-01 02:06:51.555950597 -0500
Modify: 2020-08-01 02:06:51.555950597 -0500
Change: 2020-08-01 02:32:00.176824460 -0500
 Birth: -
> chmod -c g+r test
> stat test
  File: test
  Size: 0   Blocks: 0  IO Block: 4096   regular empty file
Device: fd05h/64773dInode: 10424846Links: 1
Access: (0640/-rw-r-)  Uid: ( 1000/ user)   Gid: ( 1000/ user)
Access: 2020-08-01 02:06:51.555950597 -0500
Modify: 2020-08-01 02:06:51.555950597 -0500
Change: 2020-08-01 02:34:09.273579189 -0500
 Birth: -

You can see that the -c option did not report that the file was changed,
since the g+r bit was already set, however the ctime still did change.

Similar results occur when using chown and chgrp.

chmod/chown/chgrp are very commonly used with -R to ensure that an entire
directory tree has ownership and permissions set correctly, but with this
bug also causes every file in that tree to now be considered "changed" even
when most or all may not actually have been.

If these utilities were just blindly setting the mode/owner of files, then
this behavior might be able to be justified.  But since these utilities
already have a -c flag, and actually do the necessary work/stat beforehand
to see if a change is needed, I can't see any reason why it should still be 
causing a ctime change on files that do not require any changes.

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information



Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog

2020-05-01 Thread E Harris
Package: libreoffice-common
Version: 1:6.1.5-3+deb10u5
Severity: normal

Using LibreOffice results in many AppArmor audit log messages marked as 
"ALLOWED".
These messages repeat many times during normal use of the app, resulting in 
quite a bit of log spam.

Perhaps this is the result of the user's home directory being mounted in an 
alternate location?

A small sampling of messages (obfuscated):

May  1 17:19:49 host kernel: [ 9201.656675] audit: type=1400 
audit(1588371589.713:822): apparmor="ALLOWED" operation="mknod" 
profile="libreoffice-soffice" 
name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 
comm="configmgrWriter" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
May  1 17:19:49 host kernel: [ 9201.657039] audit: type=1400 
audit(1588371589.713:823): apparmor="ALLOWED" operation="open" 
profile="libreoffice-soffice" 
name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 
comm="configmgrWriter" requested_mask="wrc" denied_mask="wrc" fsuid=1000 
ouid=1000
May  1 17:19:49 host kernel: [ 9201.657107] audit: type=1400 
audit(1588371589.717:824): apparmor="ALLOWED" operation="file_lock" 
profile="libreoffice-soffice" 
name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 
comm="configmgrWriter" requested_mask="wk" denied_mask="wk" fsuid=1000 ouid=1000
May  1 17:19:49 host kernel: [ 9201.670903] audit: type=1400 
audit(1588371589.729:825): apparmor="ALLOWED" operation="rename_src" 
profile="libreoffice-soffice" 
name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 
comm="configmgrWriter" requested_mask="wrd" denied_mask="wrd" fsuid=1000 
ouid=1000
May  1 17:19:49 host kernel: [ 9201.670926] audit: type=1400 
audit(1588371589.729:826): apparmor="ALLOWED" operation="rename_dest" 
profile="libreoffice-soffice" 
name="/raid/home/user/.config/libreoffice/4/user/registrymodifications.xcu" 
pid=16453 comm="configmgrWriter" requested_mask="wc" denied_mask="wc" 
fsuid=1000 ouid=1000

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

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

Versions of packages libreoffice-common depends on:
ii  libnumbertext-data 1.0.5-1
ii  libreoffice-style-colibre  1:6.1.5-3+deb10u5
ii  libreoffice-style-tango1:6.1.5-3+deb10u5
ii  ure6.1.5-3+deb10u5

Versions of packages libreoffice-common recommends:
ii  apparmor2.13.2-10
ii  fonts-liberation2   2.00.5-1
ii  libexttextcat-data  3.4.5-1
ii  python3-uno 1:6.1.5-3+deb10u5
ii  xdg-utils   1.1.3-1

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-colibre [libreoffice-style]  1:6.1.5-3+deb10u5
ii  libreoffice-style-tango [libreoffice-style]1:6.1.5-3+deb10u5

Versions of packages python3-uno depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libpython3.7  3.7.3-2+deb10u1
ii  libreoffice-core  1:6.1.5-3+deb10u5
ii  libstdc++68.3.0-6
ii  python3   3.7.3-1
ii  python3.7 3.7.3-2+deb10u1
ii  uno-libs3 6.1.5-3+deb10u5
ii  ure   6.1.5-3+deb10u5

-- Configuration Files:
/etc/libreoffice/soffice.sh changed:
FILE_LOCKING=auto
OPENGL_SUPPORT=no


-- no debconf information



Bug#951827: libimage-exiftool-perl: Current version of exiftool writes incorrect Quicktime Rotation values to HEIC files

2020-02-21 Thread E Harris
Package: libimage-exiftool-perl
Version: 11.87-1
Severity: normal
Tags: upstream

When trying to modify the Quicktime Rotation values in HEIC/HEIF files, the 
values written have an incorrect offset (4320 degress).

This problem has been reported to the upstream maintainer, who reports it is 
fixed in release 11.88 (current) of the upstream package.

Please update the package to the latest version to include this and other bug
fixes.

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

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

Versions of packages libimage-exiftool-perl depends on:
ii  perl  5.28.1-6

Versions of packages libimage-exiftool-perl recommends:
ii  libarchive-zip-perl1.64-1
ii  libposix-strptime-perl 0.13-1+b5
ii  libunicode-linebreak-perl  0.0.20190101-1

libimage-exiftool-perl suggests no packages.

-- debconf-show failed



Bug#918478: Digikam imageeditor blank screen patch, backported from Digikam 6.0

2019-11-09 Thread Timothy E. Harris
Because this bug affected me, I backported the patch from Digikam 6.0 to 
the buster digikam version


Applies cleanly & fixes the problem.

--- a/core/app/main/digikamapp.cpp
+++ b/core/app/main/digikamapp.cpp
@@ -497,7 +497,6 @@
 MetadataHubMngr::instance()->requestShutDown();
 
 DXmlGuiWindow::closeEvent(e);
-e->accept();
 }
 
 void DigikamApp::autoDetect()
--- a/core/libs/widgets/mainview/dxmlguiwindow.cpp
+++ b/core/libs/widgets/mainview/dxmlguiwindow.cpp
@@ -209,10 +209,18 @@
 
 void DXmlGuiWindow::closeEvent(QCloseEvent* e)
 {
-if(fullScreenIsActive())
+if (fullScreenIsActive())
 slotToggleFullScreen(false);
 
+if (!testAttribute(Qt::WA_DeleteOnClose))
+{
+setVisible(false);
+e->ignore();
+return;
+}
+
 KXmlGuiWindow::closeEvent(e);
+e->accept();
 }
 
 void DXmlGuiWindow::setFullScreenOptions(int options)
--- a/core/utilities/imageeditor/main/imagewindow.cpp
+++ b/core/utilities/imageeditor/main/imagewindow.cpp
@@ -254,14 +254,13 @@
 
 KSharedConfig::Ptr config = KSharedConfig::openConfig();
 KConfigGroup group= config->group(configGroupName());
-saveMainWindowSettings(group);
-saveSettings();
 
 d->rightSideBar->setConfigGroup(KConfigGroup(, "Right Sidebar"));
 d->rightSideBar->saveState();
 
+saveSettings();
+
 DXmlGuiWindow::closeEvent(e);
-e->accept();
 }
 
 void ImageWindow::showEvent(QShowEvent*)
--- a/core/utilities/importui/main/importui.cpp
+++ b/core/utilities/importui/main/importui.cpp
@@ -964,11 +964,9 @@
 
 void ImportUI::closeEvent(QCloseEvent* e)
 {
-DXmlGuiWindow::closeEvent(e);
-
 if (dialogClosed())
 {
-e->accept();
+DXmlGuiWindow::closeEvent(e);
 }
 else
 {
--- a/core/utilities/lighttable/lighttablewindow.cpp
+++ b/core/utilities/lighttable/lighttablewindow.cpp
@@ -249,7 +249,6 @@
 writeSettings();
 
 DXmlGuiWindow::closeEvent(e);
-e->accept();
 }
 
 void LightTableWindow::showEvent(QShowEvent*)
--- a/core/utilities/queuemanager/main/queuemgrwindow.cpp
+++ b/core/utilities/queuemanager/main/queuemgrwindow.cpp
@@ -164,8 +164,8 @@
 }
 
 writeSettings();
+
 DXmlGuiWindow::closeEvent(e);
-e->accept();
 }
 
 void QueueMgrWindow::setupUserArea()


Bug#902168: [synaptic] Get Changelog doesn't follow apt.conf path

2018-06-22 Thread Timothy E. Harris

Package: synaptic
Version: 0.84.2
Severity: normal

--- Please enter the report below this line. ---

I maintain the repositories for MX Linux, and I just built a patched 
version of Synaptic so it could get changelogs from both Debian & MX 
repositories.  It works, but fragmenting the builds of Synaptic this way 
is hardly optimal.  This is likely to be an issue for other debian based 
distros.
Instead of hardcoding the changelog paths I believe a better solution 
would be to query apt-config for 
Acquire::Changelogs::URI::Origin::origin() as several distributions are 
now putting their paths there. That would eliminate the per distro 
dpatch kludge currently in use and enable new distributions to easily 
use an /etc/apt/apt.conf.d/ fragment file to get their changelog path 
included in Synaptic.

My system returns this list of paths that distros are already including:
Acquire::Changelogs::URI::Origin::Debian 
"http://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog;;
Acquire::Changelogs::URI::Origin::Tanglu 
"http://metadata.tanglu.org/changelogs/@CHANGEPATH@_changelog;;
Acquire::Changelogs::URI::Origin::Ubuntu 
"http://changelogs.ubuntu.com/changelogs/pool/@CHANGEPATH@/changelog;;
Acquire::Changelogs::URI::Origin::Ultimedia 
"http://packages.ultimediaos.com/changelogs/pool/@CHANGEPATH@/changelog.txt;;
Acquire::Changelogs::URI::Origin::MX repository 
"http://mxrepo.com/mx/repo/pool/@CHANGEPATH@.changelog;;


--- System information. ---
Architecture:
Kernel: Linux 4.15.0-1-amd64

Debian Release: 9.4
500 stretch repo.antixlinux.com
500 stable-updates ftp.us.debian.org
500 stable security.debian.org
500 stable ftp.us.debian.org
500 mx mxrepo.com

--- Package information. ---
Depends (Version) | Installed
=-+-==
libapt-inst2.0 (>= 0.8.16~exp12) | 1.4.8
libapt-pkg5.0 (>= 1.1~exp9) | 1.4.8
libatk1.0-0 (>= 1.12.4) | 2.22.0-1
libc6 (>= 2.14) | 2.24-11+deb9u3
libcairo-gobject2 (>= 1.10.0) | 1.14.8-1
libcairo2 (>= 1.2.4) | 1.14.8-1
libept1.5.0 | 1.1+nmu3+b1
libgcc1 (>= 1:3.0) | 1:6.3.0-18+deb9u1
libgdk-pixbuf2.0-0 (>= 2.22.0) | 2.36.5-2+deb9u2
libglib2.0-0 (>= 2.16.0) | 2.50.3-2
libgnutls30 (>= 3.5.0) | 3.5.8-5+deb9u3
libgtk-3-0 (>= 3.3.16) | 3.22.11-1
libpango-1.0-0 (>= 1.14.0) | 1.40.5-1
libpangocairo-1.0-0 (>= 1.14.0) | 1.40.5-1
libpcre2-8-0 | 10.22-3
libstdc++6 (>= 5.2) | 6.3.0-18+deb9u1
libvte-2.91-0 | 0.46.1-1
libx11-6 | 2:1.6.4-3
libxapian30 | 1.4.3-2
zlib1g (>= 1:1.1.4) | 1:1.2.8.dfsg-5
hicolor-icon-theme | 0.15-1
policykit-1 | 0.105-18


Recommends (Version) | Installed
==-+-=
libgtk2-perl (>= 1:1.130) | 2:1.2499-1
rarian-compat | 0.8.1-6+b1
xdg-utils | 1.1.1-1+deb9u1


Suggests (Version) | Installed
==-+-===
dwww |
menu | 2.1.47+b1
deborphan | 1.7.28.8-0.3+b1
apt-xapian-index | 0.49
tasksel |
software-properties-gtk |



Bug#884344: ejabberd: After updating to latest erlang packages, ejabberd refuses to start

2017-12-16 Thread E Harris
uI was already running loglevel 4, and changing it to 5 gave no additional 
info.  There was nothing in the error.log or crash.log either, in fact those 
files hadn't even been opened, as the timestamps were still of times 
pre-upgrade.


However, your hint to look for firewall issues was a good one.

Looks like this was a problem with ejabberdctl using ipv6 by default.  We 
don't use ipv6 here, so had no rules loaded for ipv6, and the default 
iptables policy was set to drop.  Since Debian configures ipv6 addresses 
automatically I guess it was trying to use ipv6 anyway and never fell 
back to using ipv4.


Apologies for the error.  But this failure mode should probably give 
something more useful that just a timeout with no useful messages.  Perhaps 
it should emit a message to say that ejabberdctl couldn't contact the 
daemon?


Thanks.



Bug#884344: ejabberd: After updating to latest erlang packages, ejabberd refuses to start

2017-12-14 Thread E Harris
I am not using AppArmor, but I reconfirmed that by no results being found 
from "dmesg | grep -i apparmor".


I killed all the epmd processes (there were two) and as far as I know 
ejabberd is my only erlang process.  Restarting after killing the epmd 
processes results in two new epmd processes, but ejabberd still times out, 
and the server doesn't answer.


The related processes that are running:

3700069 ?Ss 0:00 /bin/sh -c /usr/sbin/ejabberdctl start && 
/usr/sbin/ejabberdctl started
3700070 ?S  0:00 /bin/bash /usr/sbin/ejabberdctl start
3699902 ?Ss 0:00 /usr/bin/epmd -systemd
3700502 ?S  0:00 /usr/bin/epmd -names


Here is all that is in the ejabberd.log from a start attempt:

2017-12-14 18:03:49.040 [info] <0.31.0> Application lager started on node 
ejabberd@kinison
2017-12-14 18:03:49.188 [info] <0.31.0> Application crypto started on node 
ejabberd@kinison
2017-12-14 18:03:49.256 [info] <0.31.0> Application sasl started on node 
ejabberd@kinison
2017-12-14 18:03:49.314 [info] <0.31.0> Application asn1 started on node 
ejabberd@kinison
2017-12-14 18:03:49.315 [info] <0.31.0> Application public_key started on node 
ejabberd@kinison
2017-12-14 18:03:49.357 [info] <0.31.0> Application ssl started on node 
ejabberd@kinison
2017-12-14 18:03:49.436 [info] <0.31.0> Application fast_yaml started on node 
ejabberd@kinison
2017-12-14 18:03:49.539 [info] <0.31.0> Application fast_tls started on node 
ejabberd@kinison
2017-12-14 18:03:49.614 [info] <0.31.0> Application fast_xml started on node 
ejabberd@kinison
2017-12-14 18:03:49.650 [info] <0.31.0> Application stringprep started on node 
ejabberd@kinison
2017-12-14 18:03:49.669 [info] <0.31.0> Application cache_tab started on node 
ejabberd@kinison
2017-12-14 18:03:50.469 [info] <0.31.0> Application mnesia started on node 
ejabberd@kinison

There is nothing indicating any info about failure in the ejabberd.log.


On Thu, 14 Dec 2017, Philipp Huebner wrote:


Hi,

since the security patch in Erlang should not have any impact for
ejabberd and because I don't have this problem on my Stretch ejabberd
servers I doubt it is a generic issue and thus I will lower the severity.

Please make sure that epmd and all other erlang processes are stopped
before trying to start ejabberd again. If necessary, kill them manually.

Please also check whether AppArmor is enabled (dmesg | grep -i
apparmor). Have you tried rebooting the server yet?

Without access to your ejabberd logs + dmesg I cannot really help you.

Regards,
--
.''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
 `-






Bug#884344: ejabberd: After updating to latest erlang packages, ejabberd refuses to start

2017-12-14 Thread E Harris
Package: ejabberd
Version: 16.09-4
Severity: grave
Justification: renders package unusable

Just updated my system to the latest security updates for erlang packages, 
and after doing so, ejabberd refuses to start.  Continually gives a 
"timeout" from systemd:

Dec 14 02:02:53 myhost systemd[1]: Failed to start A distributed, 
fault-tolerant Jabber/XMPP server.
Dec 14 02:02:53 myhost systemd[1]: ejabberd.service: Unit entered failed state.
Dec 14 02:02:53 myhost systemd[1]: ejabberd.service: Failed with result 
'timeout'.

There doesn't seem to be anything useful to troubleshoot the problem in the
systemd logs.

Erlang packages that were updated that may be related to this breakage are:

erlang-asn1 erlang-base erlang-corba erlang-crypto erlang-dev erlang-diameter 
erlang-doc erlang-edoc erlang-eldap erlang-erl-docgen erlang-eunit erlang-ic 
erlang-ic-java erlang-inets erlang-jinterface erlang-manpages erlang-mnesia 
erlang-nox erlang-odbc erlang-os-mon erlang-parsetools erlang-percept
erlang-public-key erlang-runtime-tools erlang-snmp erlang-ssh erlang-ssl 
erlang-syntax-tools erlang-tools erlang-xmerl

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

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

Versions of packages ejabberd depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  erlang-asn11:19.2.1+dfsg-2+deb9u1
ii  erlang-base [erlang-abi-17.0]  1:19.2.1+dfsg-2+deb9u1
ii  erlang-crypto  1:19.2.1+dfsg-2+deb9u1
ii  erlang-inets   1:19.2.1+dfsg-2+deb9u1
ii  erlang-jiffy   0.14.8+dfsg-1
ii  erlang-lager   3.2.4-1
ii  erlang-mnesia  1:19.2.1+dfsg-2+deb9u1
ii  erlang-odbc1:19.2.1+dfsg-2+deb9u1
ii  erlang-p1-cache-tab1.0.4-2
ii  erlang-p1-iconv1.0.2-2
ii  erlang-p1-stringprep   1.0.6-2
ii  erlang-p1-tls  1.0.7-2+deb9u1
ii  erlang-p1-utils1.0.5-3
ii  erlang-p1-xml  1.1.15-2
ii  erlang-p1-yaml 1.0.6-2
ii  erlang-p1-zlib 1.0.1-4
ii  erlang-public-key  1:19.2.1+dfsg-2+deb9u1
ii  erlang-ssl 1:19.2.1+dfsg-2+deb9u1
ii  erlang-syntax-tools1:19.2.1+dfsg-2+deb9u1
ii  erlang-xmerl   1:19.2.1+dfsg-2+deb9u1
ii  init-system-helpers1.48
ii  lsb-base   9.20161125
ii  openssl1.1.0f-3+deb9u1
ii  ucf3.0036

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
pn  apparmor 
pn  apparmor-utils   
ii  ejabberd-contrib 0.2016.09.12~dfsg0-2
pn  erlang-luerl 
pn  erlang-p1-mysql  
pn  erlang-p1-oauth2 
pn  erlang-p1-pam
pn  erlang-p1-pgsql  
pn  erlang-p1-sip
pn  erlang-p1-sqlite3
pn  erlang-p1-stun   
pn  erlang-redis-client  
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u3
ii  libunix-syslog-perl  1.1-2+b6
pn  yamllint 

-- Configuration Files:
/etc/ejabberd/inetrc [Errno 13] Permission denied: '/etc/ejabberd/inetrc'
/etc/ejabberd/modules.d/README.modules [Errno 13] Permission denied: 
'/etc/ejabberd/modules.d/README.modules'

-- debconf information excluded



Bug#880229: qbittorrent fills /tmp filesystem causing other programs to fail

2017-10-30 Thread E Harris
Package: qbittorrent
Version: 3.3.7-3
Severity: critical
Justification: breaks unrelated software

qbittorrent seems to be writing some torrent data to /tmp, which ended up 
filling the filesystem, and causing severe system stability and data loss.   
The data loss and stability issues stem both from other programs being 
unable to write to /tmp, as well as causing anything else that lives on the 
same filesystem to be unable to operate properly.

On my system, /tmp lives on the root filesystem, but if /tmp had been using 
shmfs (as some people do), the whole system could have become unusable from 
filling memory.

I found some links that suggests that it is actually an issue in libtorrent,
but I'm filing the bug against qbittorrent since I'm unsure of the 
relationship of libtorrent-rasterbar9 (which is what qbittorrent is using) 
vs the standard libtorrent 0.16.13 which they claim fixes the issue.

https://github.com/qbittorrent/qBittorrent/issues/994
https://qbforums.shiki.hu/index.php?topic=2221.0

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

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

Versions of packages qbittorrent depends on:
ii  geoip-database 20170512-1
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libc6  2.24-11+deb9u1
ii  libgcc11:6.3.0-18
ii  libqt5core5a   5.7.1+dfsg-3+b1
ii  libqt5dbus55.7.1+dfsg-3+b1
ii  libqt5gui5 5.7.1+dfsg-3+b1
ii  libqt5network5 5.7.1+dfsg-3+b1
ii  libqt5widgets5 5.7.1+dfsg-3+b1
ii  libqt5xml5 5.7.1+dfsg-3+b1
ii  libstdc++6 6.3.0-18
ii  libtorrent-rasterbar9  1.1.1-1+b1
ii  python 2.7.13-2
ii  zlib1g 1:1.2.8.dfsg-5

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
pn  qbittorrent-dbg  

-- no debconf information



Bug#878504: libmp3-tag-perl: MP3/Tag.pm line 2611 produces a deprecated warning

2017-10-14 Thread E Harris
Package: libmp3-tag-perl
Version: 1.13-1
Severity: normal
Tags: upstream

When using MP::Tag, the current version of perl shipped with Debian stretch
produces a deprecation warning about a regex in Tag.pm:

Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/(\\%(?:\\=)?(\w|\\{ <-- HERE 
(?:\w|\\[^\w\\{}]|\\[\\{}])*\\}|\\\W))/ at /usr/share/perl5/MP3/Tag.pm line 
2611.

This appears to be a known problem in the upstream, and is fixed in version
1.14, however the base for the current Debian package is 1.13.

More info and a fix is at:

https://rt.cpan.org/Public/Bug/Display.html?id=105165

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

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

Versions of packages libmp3-tag-perl depends on:
ii  perl  5.24.1-3+deb9u1

Versions of packages libmp3-tag-perl recommends:
ii  libimage-exiftool-perl  10.40-1
ii  libmp3-info-perl1.24-1.2

Versions of packages libmp3-tag-perl suggests:
pn  texlive-latex-extra  

-- no debconf information



Bug#859623: Acknowledgement (handbrake-cli: Encoding a DVD with Closed Captions (Text [CC]) stream in mkv format fails)

2017-04-08 Thread E Harris
I've now had a chance to try the encode with the same source and command 
line on the official release 1.0.3 CLI binary for OSX and it does not have 
the problem with the Closed Captioning track and mkv output, so that looks 
like a smoking gun that this is a library version/packaging issue.




Bug#859623: handbrake-cli: Encoding a DVD with Closed Captions (Text [CC]) stream in mkv format fails

2017-04-05 Thread E Harris
Package: handbrake-cli
Version: 1.0.3+ds1-1
Severity: important

When attempting to encode a video from a DVD image using a mkv output format
and also containing a Closed Captioning stream fails to mux properly and 
produces errors.  A subtitle track of the same type as stream 3 from the 
following seems to be required to produce the error (list is from the 
handbrake-cli log):

  + subtitle tracks:
+ 1, English (iso639-2: eng) (Bitmap)(VOBSUB)
+ 2, Francais (Forced Caption) (iso639-2: fra) (Bitmap)(VOBSUB)
+ 3, Closed Captions (iso639-2: eng) (Text)(CC)

During the encode, an error similar to the following is produced in the log:

[matroska @ 0x7ff3f9596780] Subtitle codec 94212 is not supported.

Following that error which is only produced once, thousands of error messages
similar to the following are produced:

ERROR: avformatMux: track 2, av_interleaved_write_frame failed with error 
'Function not implemented'
ERROR: avformatMux: track 0, av_interleaved_write_frame failed with error 
'Function not implemented'
ERROR: avformatMux: track 0, av_interleaved_write_frame failed with error 
'Function not implemented'
ERROR: Last error repeated 2 times
ERROR: avformatMux: track 1, av_interleaved_write_frame failed with error 
'Function not implemented'
ERROR: avformatMux: track 1, av_interleaved_write_frame failed with error 
'Function not implemented'

Doing the encode using exactly the same options except using '-f mp4' output 
format instead of '-f mkv' seems to work fine.  Likewise, leaving the Closed
Captions (Text [CC]) subtitle track out of the encode also seems to work 
properly.

An example command line that produces the problem with this subtitle stream
type is as follows:

HandBrakeCLI --title 1 --quality 22 -f mkv -e x264 --audio 1 --aencoder ca_aac 
--ab 160 --subtitle 1,3 --input source_dvd/ --output ./output.mkv

In searching the forums for a similar error, the only reference I found was 
this link which references a prior version of handbrake and which suggests 
the problem might be due to a libavformat version mismatch with the binary:

https://forum.handbrake.fr/viewtopic.php?f=10=32082

I haven't yet been able to get all the dependencies to get handbrake to
build from source on my system, so I don't know if the "fix" suggested in 
that link works in this case.


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

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

Versions of packages handbrake-cli depends on:
ii  libass5 1:0.13.4-2
ii  libavcodec577:3.2.4-1~bpo8+1
ii  libavfilter67:3.2.4-1~bpo8+1
ii  libavformat57   7:3.2.4-1~bpo8+1
ii  libavresample3  7:3.2.4-1~bpo8+1
ii  libavutil55 7:3.2.4-1~bpo8+1
ii  libbluray2  1:1.0.0-2
ii  libc6   2.19-18+deb8u7
ii  libdvdnav4  5.0.1-1
ii  libdvdread4 5.0.0-1
ii  libjansson4 2.9-1
ii  libsamplerate0  0.1.8-8
ii  libswscale4 7:3.2.4-1~bpo8+1
ii  libtheora0  1.1.1+dfsg.1-6
ii  libvorbis0a 1.3.4-2
ii  libvorbisenc2   1.3.4-2
ii  libx264-148 2:0.148.2748+git97eaef2-1~bpo8+1
ii  libx265-95  2.1-2+b2
ii  libxml2 2.9.1+dfsg1-5+deb8u4

handbrake-cli recommends no packages.

handbrake-cli suggests no packages.

-- no debconf information



Bug#779386: libtiff-tools: tiff2pdf is generating corrupted pdf files

2015-02-27 Thread E Harris
Package: libtiff-tools
Version: 4.0.3-12.1
Severity: important

When converting tiff files that contain a jpeg image to pdf using tiff2pdf, the 
output pdf 
seems to be corrupted and incomplete.  

$ tiff2pdf Page0001.tif  Page0001.pdf
$

No errors are produced from the tiff2pdf program.

When using xpdf to view the corrupted pdf, it reports:
Corrupt JPEG data: 3549610 extraneous bytes before marker 0xd9
And only displays part of the image.

Viewing the tiff in gimp or other tools it appears just fine.

I was having this problem with the wheezy version (4.0.2-6+deb7u3)
which is why I updated to the version in testing (4.0.3-12.1) but it is 
showing the same behavior.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libtiff-tools depends on:
ii  libc62.19-13
ii  libjbig0 2.0-2+deb7u1
ii  libjpeg62-turbo  1:1.3.1-11
ii  liblzma5 5.1.1alpha+20120614-2
ii  libtiff5 4.0.3-12.1
ii  zlib1g   1:1.2.7.dfsg-13

libtiff-tools recommends no packages.

Versions of packages libtiff-tools suggests:
pn  libtiff-opengl  none

-- no debconf information


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



Bug#584976: openerp-server: New database can not be created if locale is en_US (not UTF-8)

2010-06-07 Thread Timothy E. Harris

Package: openerp-server
Version: 5.0.10-1
Severity: important
Tags: sid patch squeeze

After installing openerp-server, openerp-client,  posgresql, then 
creating the

required postrgresql user openerp, I opened openerp-client and got the
expected:
No database found, you must create one !
message.
Selecting File - Databases - New database, filling in the fields and 
clicking

OK results in the error message:
Error during database creation ! Could not create database.

var/log/postgresql/postgresql-8.4-main.log contains:
2010-06-07 19:54:34 EDT ERROR:  encoding UTF8 does not match locale en_US
2010-06-07 19:54:34 EDT DETAIL:  The chosen LC_CTYPE setting requires \
encoding LATIN1. 2010-06-07
19:54:34 EDT STATEMENT:  CREATE DATABASE mytestdb ENCODING 'unicode' \
TEMPLATE template0

Some research found that the database encoding when creating a new
database is hard-coded in openerp-server to 'unicode'. Postgresql accepts
unicode if the locale (when postgresql is installed) is a UTF type or the C
locale but it only accepts LATIN1 if another locale type is found.

The attached patch queries the locale and sets the encoding for database
creation accordingly.


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

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages openerp-server depends on:
ii  adduser   3.112  add and remove users and groups
ii  debconf [debconf-2.0] 1.5.29 Debian configuration 
management sy
ii  python2.5.4-9An interactive high-level 
object-o

ii  python-libxslt1   1.1.26-3   Python bindings for libxslt1
ii  python-lxml   2.2.6-1pythonic binding for the 
libxml2 a

ii  python-psycopg2   2.0.14-1   Python module for PostgreSQL
ii  python-pychart1.39-7 Python library for creating 
high q
ii  python-pydot  1.0.2-1Python interface to 
Graphviz's dot
ii  python-reportlab  2.4-1  ReportLab library to create 
PDF do
ii  python-tz 2010b-1Python version of the Olson 
timezo


Versions of packages openerp-server recommends:
ii  ghostscript  8.71~dfsg-3 The GPL Ghostscript 
PostScript/PDF

ii  graphviz 2.26.3-4rich set of graph drawing tools
ii  postgresql   8.4.4-1 object-relational SQL 
database (su
ii  postgresql-client-8.4 [postg 8.4.4-1 front-end programs for 
PostgreSQL

ii  python-imaging   1.1.7-1+b1  Python Imaging Library
ii  python-matplotlib0.99.1.2-3  Python based plotting 
system in a
ii  python-openssl   0.10-1  Python wrapper around the 
OpenSSL

ii  python-pyparsing 1.5.2-2 Python parsing module

Versions of packages openerp-server suggests:
ii  openerp-client5.0.10-1   Enterprise Resource 
Management (cl


-- debconf-show failed

Author: Timothy E. Harris maintai...@mepiscommunity.org
Description: Fix bug that prevents creating a new database if the locale is not a UTF-8 one.

Index: openerp-server-5.0.10/bin/service/web_services.py
===
--- openerp-server-5.0.10.orig/bin/service/web_services.py	2010-06-06 10:00:23.0 -0400
+++ openerp-server-5.0.10/bin/service/web_services.py	2010-06-06 10:01:26.0 -0400
@@ -38,6 +38,7 @@
 import sql_db
 import tools
 import locale
+import re
 from cStringIO import StringIO
 
 logging.basicConfig()
@@ -64,11 +65,15 @@
 self._pg_psw_env_var_is_set = False # on win32, pg_dump need the PGPASSWORD env var
 
 def _create_empty_database(self, name):
+if re.search('utf|UTF', locale.getdefaultlocale()[1]):
+db_encoding = 'unicode'
+else:
+db_encoding = 'LATIN1'
 db = sql_db.db_connect('template1')
 cr = db.cursor()
 try:
 cr.autocommit(True) # avoid transaction block
-cr.execute(CREATE DATABASE %s ENCODING 'unicode' TEMPLATE template0  % name)
+cr.execute(CREATE DATABASE %s ENCODING '%s' TEMPLATE template0  %(name, db_encoding))
 finally:
 cr.close()
 


Bug#166515: emigration

2006-12-03 Thread Tom E. Harris

I have a new Yahoo account now, but of course I cannot access Zothique
Nights without my own permission!
To the developing world, it's a medicine chest. John Borland goes to the
edge of theory.
If I'm lucky, this book will hit my mailbox at approximately the same
time as I get the CAS Poems III, enabling me to go on a real CAS binge.
activity, as you can see, is low.
It's a ridiculous situation.

R

*MAKU* IMMENSE COVERAGE *MAKU*

Trade Date:   Monday, December 4, 2006
Company Name: MAKEUP LIMITED (OTC BB:MAKU.OB)
Symbol:   MAKU
Last Trade:   $0.61
MAKU Target:  $2

Why get in MAKU? Don't if profit is not in your vocabulary.

JUST WATCH MAKU TRADE NEXT MONDAY, DECEMBER 4TH!

R

I'm as much to blame as anyone, but at least there is still an active
forum out there for CAS fans. John Borland goes to the edge of theory.
com are good places to search for used books. The Tennessee Titans
cornerback had two critical interceptions against the New York Giants on
Sunday, then scored himself a familiar ride on Thursday. i'm surprised
that this Cthulhu Cult hasn't generated more motivation. to those who
have already officially joined, thank you!
Attempts to find out from them what the problem was proved futile. I'd
have liked to email the members to tell them what was going on, but
again I can't get to the members page to retrieve anyone's email
address.
I make no claims to being an expert, of course.
Even if no one can help, I thought you all might be amused by this
ironic situation. Thanks to Babelfish, I could cope with all major-ish
western Indo-European languages, inc. com for the complete story. Nous,
payer pour le non professionnalisme et les conneries des autres, certes
pas !
Google has decided to close the shop on this project. i will use the
interlibrary lone, but it would be nice to have my own collection. the
apathy of routine hunts man continually. In a way it's like CAS, you
don't read him for plot but for the language.
Scott and I have both gone over the proofs and sent them back to Night
Shade. Unfortunately, even though I am owner and moderator, I cannot
gain access to the group to approve anyone!
Anyone else have a suggestion?
com are good places to search for used books.
In many ways Zothique Nights was the predecessor to this forum, and
apparently the birth of this Eldritch Forum was also the demise of the
once mighty Zothique Nights! Commentary by Bruce Schneier. But fear not:
There's always another giant accelerator on the horizon.
I make no claims to being an expert, of course. The Tennessee Titans
cornerback had two critical interceptions against the New York Giants on
Sunday, then scored himself a familiar ride on Thursday. Commentary by
Bruce Schneier. Thanks to Babelfish, I could cope with all major-ish
western Indo-European languages, inc. I'm in Portland Oregon and never
seem to be able to schedule a visit to the places hosting such events.
Basically, Yahoo deleted my account about a year ago, without
explanation.
I make no claims to being an expert, of course. i'm surprised that this
Cthulhu Cult hasn't generated more motivation.



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



Bug#309792: exim4-config: Rewriting via /etc/email-addresses should be configurable to apply to only non-local mail.

2005-05-19 Thread Steven E. Harris
Package: exim4-config
Version: 4.50-6
Severity: normal

At present exim applies the /etc/email-addresses rewriting mechanism
to all mail sent through the MTA. This causes interference with a
setup that permits both local exchange of mail among local users and
mail sent out to remote destinations either by the remote_smtp or
remote_smtp_smarthost transports.

Note that in the configuration captured in this report represents a
smarthost setup. Any mail not destined for a local user must be sent
out through the designated smarthost. I have another computer that can
make direct SMTP connections to non-local hosts and hence does not use
the smarthost setup, but it suffers the same problem reported here.

When I send a message out from my computer to a remote recipient, I
want any mention of my local user name and host replaced with my
externally-visible email address; I have this mapping defined as
expected in /etc/email-addresses. However, for local mail, I do not
want my From address to be rewritten. The local messages do get
delivered properly, but if the recipient replies without editing the
To address, the message goes out to my externally-visible address
unnecessarily. Also, the rewriting in this case changes the facts: The
local messages look like they came from a remote sender, despite being
sent from a local account.

Supporting this rewrite-only-for-non-local scheme requires that the
/etc/email-addresses rewrite rule be moved to the transport's
headers_rewrite entry, as suggested in the Exim FAQ (Q0803). I use
this technique in an older hand-crafted exim.conf on Cygwin and it
works as desired. I'm just surprised to see that the Debian
exim4-config package doesn't offer this choice.

There is an optional facility offered now to mask the local host name
with an alternate visible host name. When selected, this option adds
a headers_rewrite entry to the remote_smtp* transports. This option
does not support my scheme; my computer is not visible externally and
is not meant to receive non-local messages directly.

Though I can't provide a patch today for the debconf mechanism, I can
at least sketch some proposed changes.

  o For setups that permit non-local outbound mail, ask the user
whether he wants per-user rewriting (via /etc/email/addresses),
global rewriting (the current visible host option), or no
rewriting.
  o If either of the first two rewriting options are chosen above,
place an appropriate headers_rewrite entry in each of the
remote_smtp* transports.
  o Remove the current global /etc/email-addresses rewrite rule.

I found mention of a similar proposal in Bug 229911, but the
submitter's proposal to limit the /etc/email-addresses rewriting was
not properly addressed in the discussion that followed.


-- Package-specific info:
Exim version 4.50 #1 built 17-Apr-2005 19:12:46
Copyright (c) University of Cambridge 2004
Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
Support for: iconv() IPv6 GnuTLS
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis 
nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='debutant.sehlabs.com'
dc_local_interfaces='127.0.0.1'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='mail.panix.com'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_readhost=''
mailname:localhost.localdomain

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages exim4-config depends on:
ii  adduser   3.63   Add and remove users and groups
ii  debconf [debconf-2.0] 1.4.49 Debian configuration management sy
ii  passwd1:4.0.3-34 change and administer password and

-- debconf information:
  exim4/dc_noalias_regenerate: false
* exim4/dc_smarthost: mail.panix.com
  exim4/dc_relay_domains:
* exim4/dc_relay_nets:
* exim4/mailname: localhost.localdomain
* exim4/dc_local_interfaces: 127.0.0.1
* exim4/dc_minimaldns: false
  exim4/exim3_upgrade: true
* exim4/dc_other_hostnames: debutant.sehlabs.com
* exim4/dc_eximconfig_configtype: mail sent by smarthost; received via SMTP or 
fetchmail
  exim4/no_config: true
* exim4/hide_mailname: false
* exim4/dc_postmaster: seh
* exim4/dc_readhost:
* exim4/use_split_config: true
  exim4/exim4-config-title:


-- 
To UNSUBSCRIBE, email to [EMAIL