Bug#1006888: RFP: sasl-xoauth2 -- XOAUTH2 plugin for libsasl2
I would like to second this RFP. I recently received a notification from Google warning me that they are phasing out password authentication, which (in the case of my account) will stop working on May 30. Once that happens, OAuth2 will be the only supported GMail SMTP authentication mechanism. This in turn means sasl-xoauth2 (or equivalent) will become a hard requirement to be able to use GMail SMTP from Postfix, for example.
Bug#1006842: ovmf 2022.02-1 makes TPM unusable in Windows guests
Package: ovmf Version: 2022.02-1 Severity: important Control: fixed -1 2021.11-1 An ovmf regression somewhere between 2021.11-1 and 2022.02-1 makes it impossible to use a TPM in Windows guest VMs (tested with various Windows 11 builds). The Windows Device Manager shows the TPM as defective, with the error "This device cannot start. (Code 10) A protocol error was detected between the driver and the device". tpm.msc shows no TPM is available. One consequence is that Windows 11 refuses to install with ovmf 2022.02-1, since the Windows 11 installer demands a functional TPM. Steps to reproduce using qemu-system-x86 1:6.2+dfsg-2 and swtpm 0.7.1-1: # mkdir /tmp/tpm # swtpm socket --tpm2 --tpmstate dir=/tmp/tpm --ctrl type=unixio,path=/tmp/tpm/sock & # qemu-system-x86_64 -enable-kvm -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd -chardev socket,id=tpm,path=/tmp/tpm/sock -tpmdev emulator,id=tpm,chardev=tpm -device tpm-tis,tpmdev=tpm … With ovmf 2021.11-1, the TPM is functional in Windows using the above parameters; with 2022.02-1, it is not. Switching to "tpm-crb" doesn't seem to make any difference. In Linux guests the TPM appears to be functional, although the guest kernel outputs the following messages with 2022.02-1: tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1, rev-id 1) tpm tpm0: A TPM error (256) occurred attempting the self test tpm tpm0: starting up the TPM manually With 2021.11-1, the kernel only outputs the first line - no errors.
Bug#1006500: Missing bnx2x firmware 7.13.21.0 renders NIC unusable with Linux 5.16
Package: firmware-bnx2x Version: 20210818-1 Severity: grave On Linux 5.16, the bnx2x module requests firmware 7.13.21.0: # modinfo bnx2x filename: /lib/modules/5.16.0-2-amd64/kernel/drivers/net/ethernet/broadcom/bnx2x/bnx2x.ko firmware: bnx2x/bnx2x-e2-7.13.21.0.fw firmware: bnx2x/bnx2x-e1h-7.13.21.0.fw firmware: bnx2x/bnx2x-e1-7.13.21.0.fw This firmware is not present in the firmware-bnx2x package. Now, my understanding is that the bnx2x module can fall back to an earlier version (7.13.15.0) as needed, but in practice that might not actually help, because update-initramfs only looks for the firmware version from the module information and doesn't include any other version: # update-initramfs -u W: Possible missing firmware /lib/firmware/bnx2x/bnx2x-e2-7.13.21.0.fw for module bnx2x W: Possible missing firmware /lib/firmware/bnx2x/bnx2x-e1h-7.13.21.0.fw for module bnx2x W: Possible missing firmware /lib/firmware/bnx2x/bnx2x-e1-7.13.21.0.fw for module bnx2x Since no firmware is included in the initramfs, the bnx2x module unsurprisingly fails to initialize on boot: kernel: bnx2x :02:00.1: firmware: failed to load bnx2x/bnx2x-e2-7.13.21.0.fw (-2) kernel: bnx2x :02:00.1: Direct firmware load for bnx2x/bnx2x-e2-7.13.21.0.fw failed with error -2 kernel: bnx2x :02:00.1: firmware: failed to load bnx2x/bnx2x-e2-7.13.15.0.fw (-2) kernel: bnx2x :02:00.1: Direct firmware load for bnx2x/bnx2x-e2-7.13.15.0.fw failed with error -2 Adding insult to injury, it doesn't look like it's possible to recover from this state - as far as I could tell, once bnx2x fails to initialize, it's game over until the next reboot, even if the module is unloaded and reloaded, and even if the PCI device is removed and rescanned. This basically means that, when booting current Debian Unstable with Linux 5.16, bnx2x NICs become *permanently unusable*, potentially locking users and admins out of the system. My suggested short-term fix would be to update the firmware-bnx2x package to include the 7.13.21.0 firmware version. There's also a discussion to be had with regard to update-initramfs, which should perhaps try harder to find potentially compatible firmware versions - indeed, if update-initramfs had included 7.13.15.0, I believe this issue would have been avoided. For those affected, here's the workaround I used: 1. Manually download the 7.13.21.0 firmware files from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/bnx2x 2. Put the files in /lib/firmware/bnx2x 3. Run update-initramfs -u 4. Reboot
Bug#848945: #848945 Empty rpool leaves ZFS systems unbootable
By the way, for those who don't like patching packaged files, here's a workaround for manually overriding the root= parameter from /etc/default/grub: GRUB_FS=manual GRUB_DISABLE_LINUX_UUID=true GRUB_DEVICE=ZFS=yourpoolname/path/to/your/root/dataset
Bug#848945: #848945 Empty rpool leaves ZFS systems unbootable
Control: found -1 2.04-18 I just hit this bug. It rendered my system unbootable because my root ZFS pool has the new zstd compression feature enabled, and it looks like grub-probe choked on that. There are two things that I found highly frustrating here: - While my root (/) is on ZFS, my /boot is not, precisely to try to avoid issues like these. In this setup GRUB doesn't need to be able to read the zpool - all that matters is the name of the pool, which can be trivially determined without the need for any kind of subtle low-level probing. It seems like as long as the bootloader/kernel/initrd itself is not stored on ZFS, GRUB should Just Work regardless of the low-level zpool details (such as zpool features). That is not presently the case because /etc/grub.d/10_linux insists on using grub-probe and grub-probe insists on using its own custom low-level ZFS read code just to figure out the name of the zpool. That's just... silly. - The error handling here is appalling. In my case update-grub (grub-mkconfig) *did not even display a single error message*. The "unknown filesystem" error from grub-probe is being swallowed somehow, and /etc/grub.d/10_linux doesn't check that the returned `rpool` looks valid. update-grub will happily generate an obviously garbage, unbootable config with a syntactically invalid root=ZFS= kernel parameter and everything will look fine at first... until you try to reboot! At the very least an error message should be displayed; ideally update-grub should refuse to generate a new config altogether, to avoid replacing a working config with a broken one. By the way, here are steps to reproduce to make grub-probe choke on a ZFS pool with zstd enabled: # dd if=/dev/zero of=/tmp/pool bs=1 count=1 seek=$((128*1024*1024)) # zpool create testpool /tmp/pool # zfs set compression=zstd testpool # /usr/sbin/grub-probe --device /tmp/pool --target=fs_label /usr/sbin/grub-probe: error: unknown filesystem. If the "zfs set compression" step is omitted, grub-probe works. Tested with zfs 2.0.3-8.
Bug#949235: ip netns add race condition can wreak havoc in mount points
Hi Luca, On Fri, 27 Nov 2020 at 18:09, Luca Boccassi wrote: > Can reproduce the issue - sent a patch to use flock(): > > https://patchwork.ozlabs.org/project/netdev/patch/20201127180651.80283-1-bl...@debian.org/ > > Please test it as well, cannot reproduce anymore once the fix is in. Sorry for the delay. I can confirm that I cannot reproduce anymore with your patch (commit 975c494 in the iproute2 git repo). Thanks for the fix!
Bug#963797: qemu user-mode networking (SLIRP) DNS doesn't work without resolv.conf
Package: qemu-system-x86 Version: 1:5.0-5 resolv.conf(5) states: > If [/etc/resolv.conf] does not exist, only the name server on the local > machine will be queried, and the search list contains the local domain name > determined from the hostname. qemu user-mode networking (a.k.a SLIRP, a.k.a -netdev user) doesn't seem to follow this convention. Indeed, if the host doesn't have /etc/resolv.conf (or if it's empty), qemu is unable to answer DNS queries from the guest VM. The workaround is to create a valid /etc/resolv.conf with a "nameserver 127.0.0.1" line.
Bug#949235: ip netns add race condition can wreak havoc in mount points
Package: iproute2
Version: 4.20.0-2
Severity: important
Control: found -1 5.4.0-1
The ipnetns.c:netns_add() function sets up the /var/run/netns mount
point in a way that is fragile to race conditions if the routine is
entered to by multiple processes at the same time.
If the race condition is triggered, some kind of mount point recursion
explosion seems to happen, messing up the entire system in
"interesting" ways. For example, /proc/self/mountinfo ends up with
tons of duplicate entries, and the mountinfo file itself becomes so
large that the entire system tends to slow down. Also, subsequent
netns add commands might fail with the following error message (note
that this doesn't always happen):
mount --bind /run/netns /run/netns failed: No space left on device
Since it is a race condition, the issue is hard to reproduce on its
own, but it is possible to force it to happen by using strace to
inject an artificial delay in the mount() system call. See below.
I observed this race condition happen multiple times on a real
production system during the boot process. This is because this
particular system sets up network namespaces using systemd units.
Because systemd is designed to start units in parallel, and due to
cold caches, multiple units running "netns add" end up synchronizing
with each other, making it quite likely the race condition will be
triggered.
STEPS TO REPRODUCE
Do NOT follow this procedure on a system you care about. This
procedure WILL mess up your system and likely require you to reboot!
1. Start from a fresh system that never ran "netns add" since boot (or
just unmount /var/run/netns manually). I can reproduce it on Debian
Buster (iproute2 4.20.0-2) as well as latest Sid (5.4.0-1).
2. Run the following bash script:
---
for i in {0..9}
do
strace -e trace=mount -e inject=mount:delay_exit=100 ip
netns add "testnetns$i" 2>&1 | tee "$i.log" &
done
wait
---
3. Look at /proc/self/mountinfo. Hilarity ensues.
If you increase the count in the script you might even get to see some
"mount failed: No space left on device" errors.
WORKAROUND
Make sure that the first "netns add" command that runs after boot
cannot run in parallel with any other "netns add" command. flock(1)
might be useful here. I guess setting up the /var/run/netns point
manually during boot, before any "netns add" command runs, might also
work.
Bug#947211: Regression in libsoxr0 0.1.3-2 makes ffmpeg segfault
Package: libsoxr0 Version: 0.1.3-2 Control: fixed -1 0.1.3-1 Steps to reproduce: $ sox -n -r 44100 test.wav synth 1 sine 1000 $ ffmpeg -i test.wav -filter:a "aresample=48000:resampler=soxr" testout.wav ffmpeg version 4.2.1-2 Copyright (c) 2000-2019 the FFmpeg developers built with gcc 9 (Debian 9.2.1-15) configuration: --prefix=/usr --extra-version=2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared libavutil 56. 31.100 / 56. 31.100 libavcodec 58. 54.100 / 58. 54.100 libavformat58. 29.100 / 58. 29.100 libavdevice58. 8.100 / 58. 8.100 libavfilter 7. 57.100 / 7. 57.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 5.100 / 5. 5.100 libswresample 3. 5.100 / 3. 5.100 libpostproc55. 5.100 / 55. 5.100 Input #0, wav, from 'test.wav': Duration: 00:00:01.00, bitrate: 1411 kb/s Stream #0:0: Audio: pcm_s32le ([1][0][0][0] / 0x0001), 44100 Hz, mono, s32, 1411 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s32le (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help Segmentation fault (core dumped) Stack trace: Thread 1 "ffmpeg" received signal SIGSEGV, Segmentation fault. __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:416 416 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory. (gdb) bt #0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:416 #1 0x706c6dcd in memcpy (__len=3556, __src=, __dest=0x0) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 #2 _soxr_interleave_f (data_type=, dest0=0x556386c0, src=, n=889, ch=1, seed=0x55635e00) at ./src/data-io.c:204 #3 0x706c260f in soxr_output_1ch (p=p@entry=0x55635ce0, i=i@entry=0, dest=dest@entry=0x7fffd1a0, len=, len@entry=1146, separated=separated@entry=true) at ./src/soxr.c:664 #4 0x706c3e71 in soxr_process (p=p@entry=0x55635ce0, in=in@entry=0x7fffcf80, ilen0=, ilen0@entry=1024, idone0=idone0@entry=0x7fffcee8, out=out@entry=0x7fffd1a0, olen=olen@entry=1146, odone0=0x7fffcef0) at ./src/soxr.c:794 #5 0x763bdba3 in process (c=0x55635ce0, dst=0x7fffd1a0, dst_size=1146, src=0x7fffcf80, src_size=1024, consumed=0x7fffcf7c) at src/libswresample/soxr_resample.c:90 #6 0x763be5b3 in resample (s=s@entry=0x5561d900, out_param=out_param@entry=0x7fffd870, out_count=out_count@entry=1146, in_param=in_param@entry=0x556208d0, in_count=in_count@entry=1024) at src/libswresample/swresample.c:537 #7 0x763bef3e in swr_convert_internal (s=s@entry=0x5561d900, out=out@entry=0x55620f30, out_count=out_count@entry=1146, in=in@entry=0x556206b0, in_count=in_count@entry=1024) at src/libswresample/swresample.c:646 #8 0x763bfa8c in swr_convert_internal (in_count=1024, in=0x556206b0, out_count=1146, out=0x55620f30, s=0x5561d900) at src/libswresample/swresample.c:589 #9 swr_convert (s=0x5561d900, out_arg=0x55636440, out_count=out_count@entry=1146, in_arg=, in_count=, in_count@entry=1024) at src/libswresample/swresample.c:766 #10 0x77ccd67f in filter_frame (inlink=inlink@entry=0x556333c0, insamplesref=) at src/libavfilter/af_aresample.c:217 #11 0x77d238ad in ff_filter_frame_framed (frame=, link=0x556333c0) at src/libavfilter/avfilter.c:1071 #12 ff_filter_frame_to_filter (link=0x556333c0) at src/libavfilter/avfilter.c:1219 #13 ff_filter_activate_default (filter=) at src/libavfilter/avfilter.c:1268 #14 ff_filter_activate (filter=) at src/libavfilter/avfilter.c:1430 #15 0x77d26a7b in ff_filter_graph_run_once (graph=graph@entry=0x55619e40) at src/libavfilter/avfiltergraph.c:1454 #16 0x77d286f8 in push_frame (graph=0x55619e40) at src/libavfilter/buffersrc.c:187 #17
Bug#944759: When using include, nft shows the wrong file name in errors
Package: nftables Version: 0.9.2-2 Severity: minor $ cat > nftables.conf <
Bug#943849: geoipupdate does not create the database directory
Package: geoipupdate Version: 4.0.6-1 After installing geoipupdate, the bundled cron job fails with: # /usr/bin/geoipupdate Error preparing to update: database directory is not available: stat /var/lib/GeoIP: no such file or directory Workaround: # mkdir /var/lib/GeoIP Seems like that command should be run as part of package installation.
Bug#943601: astraceroute unusable because of lack of GeoIP database
Package: netsniff-ng Version: 0.6.5-1+b2 Severity: important # astraceroute --dev eth0 --host debian.org Cannot open GeoIP6 city database, try --update! # astraceroute --update Cannot open or create file /usr/share/netsniff-ng/country4.dat.gz! No such file or directory. # mkdir /usr/share/netsniff-ng # astraceroute --update Cannot get /GeoIP.dat.gz from mirrors! (Further investigation reveals it's trying to resolve some "cryptoism.org" domain, which doesn't exist.) This is despite the fact that I have geoip-database, geoip-database-extra and geoipupdate packages installed.
Bug#943558: jq crashes violently if --jsonargs is not valid JSON
Package: jq
Version: 1.6-1
Severity: minor
This works, because "foo" is a valid JSON value:
$ jq --null-input '$ARGS' --jsonargs '"foo"'
{
"positional": [
"foo"
],
"named": {}
}
But if the passed-in value is not a valid JSON value, jq crashes violently:
$ jq --null-input '$ARGS' --jsonargs foo
{
"positional": [
jq: src/jv_print.c:223: jv_dump_term: Assertion `0 && "Invalid value"' failed.
Aborted (core dumped)
jq should fail more gracefully with a proper error message when an
invalid jsonargs is passed.
Bug#942734: bs1770gain does not escape file names properly in XML output
Package: bs1770gain Version: 0.6.5-1 Steps to reproduce: $ sox -n '1 & 2.wav' synth 1 sine 1000 $ bs1770gain --xml --suppress-progress . | xmllint - -:3: parser error : xmlParseEntityRef: no name ^ Correct escaping would be "1 2.wav". This is a regression from bs1770gain 0.5.2-2, which did escape file names.
Bug#942704: Breaking changes to bs1770gain XML output between 0.5 and 0.6
Package: bs1770gain Version: 0.6.5-1 Steps to reproduce: $ sox -n file.wav synth 1 sine 1000 $ bs1770gain --xml --suppress-progress --sample-peak . In contrast, version 0.5 used to return something like this: There are at least two breaking changes to the XML output format between 0.5 and 0.6: The element disappeared and the "factor" attribute was renamed to "amplitude". As a result, programs that consume bs1770gain 0.5 XML output are likely to break when bs1770gain is upgraded to 0.6. I couldn't find any mention of this breaking change anywhere in the bs1770gain website nor in the Debian changelog. One could argue that a warning should be displayed to the user during the package upgrade process so that they are not caught off-guard when their consumer programs break. I'm also wondering if that means bs1770gain 0.6 should be in a separate package altogether so that existing 0.5 packages won't be automatically upgraded?
Bug#942702: bs1770gain --help misspells --suppress-progress
Package: bs1770gain Version: 0.6.5-1 Severity: minor $ bs1770gain --help [...] --suppress-progess: suppress printing processing progress The correct spelling is --suppress-progress.
Bug#942701: bs1770gain outputs invalid XML when --xml is used
Package: bs1770gain Version: 0.6.5-1 Steps to reproduce: $ sox -n file.wav synth 1 sine 1000 $ bs1770gain --xml . | xmllint - -:6: parser error : PCDATA invalid Char value 8 30% ^ -:6: parser error : PCDATA invalid Char value 8 30% [...] The problem is that progress information is being output directly to stdout even in XML mode, which confuses the parser. The solution is to use --suppress-progress: $ bs1770gain --suppress-progress --xml . | xmllint - [...] The end result is that --xml is unusable without --suppress-progress. (This is a regression from previous versions of bs1770gain, which did not output progress information.) What would make most sense IMHO is to only output progress information to stderr to avoid confusing whatever program is consuming stdout. Even better would be to only output progress information if stderr is a TTY. Or, at the very least, --suppress-progress should be the default when --xml is used.
Bug#926598: xmlstarlet fo --omit-decl exits with non-zero code
Package: xmlstarlet Version: 1.6.1-2 Steps to reproduce: $ echo '' | xmlstarlet fo --omit-decl; echo $? Expected result: 0 Actual result: 5 What's really weird is that the returned error code is always identical to the number of bytes written to the output. This bug seems to only occur if --omit-decl is used.
Bug#910451: closed by Petter Reinholdtsen (Bug#910451: fixed in bs1770gain 0.5.2-1)
Yes, I just installed 0.5.2-2 and the segfault appears to be gone. Thank you!
Bug#910451: closed by Petter Reinholdtsen (Fixed in version 0.5.0)
This bug is not fixed in version 0.5.1-3 and can still be reproduced using the exact same steps as described above (and below). In fact I had already verified that it still occurs in upstream 0.5.0 (see message #10). $ sox -n sine.wav synth 1 sine 1000 $ ffmpeg -i sine.wav sine.mp3 $ bs1770gain sine.mp3 analyzing ... [1/1] "sine.mp3": Segmentation fault (core dumped)
Bug#916055: prometheus-node-exporter pulls disks out of standby every 15 minutes
Package: prometheus-node-exporter Version: 0.16.0+ds-2 Severity: normal Release 0.16.0+ds-2 of prometheus-node-exporter introduces a regression in which, as long as the package is installed in the machine, drives that are in stand by mode (i.e. spun down) will be woken up every 15 minutes. This is unsurprising because this release introduces a new scheduled job that runs smartmon.sh every 15 minutes, and smartmon.sh will happily wake up hard drives to check on them (it does not pass the --nocheck=standby option to smartctl). The clean fix would be to make smartmon.sh pass the --nocheck=standby option to smartctl. A more immediate workaround is to disable the feature entirely: # systemctl disable prometheus-node-exporter-smartmon.timer
Bug#910470: parallel: Crashes on empty input when --shuf is used
Package: parallel Version: 20161222-1 Severity: normal Dear Maintainer, To reproduce: $ : | parallel --will-cite --shuf echo Modification of non-creatable array value attempted, subscript -1 at /usr/bin/parallel line 6359. Basically, if there is no input (i.e. nothing to do) and --shuf is used, parallel crashes. If the --shuf option isn't used, it correctly does nothing and exits successfully. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages parallel depends on: ii perl 5.26.2-7 ii procps 2:3.3.15-2 ii sysstat 12.0.1-1 parallel recommends no packages. parallel suggests no packages. -- no debconf information
Bug#910451: bs1770gain segfaults on MP3 files
Same outcome with 0.5.0 manually built from upstream. Stack trace with 0.5.0: #0 0x555d78b0 in () #1 0x77da900e in av_buffer_unref () at /usr/lib/x86_64-linux-gnu/libavutil.so.56 #2 0x76a0d4c5 in av_packet_unref (pkt=pkt@entry=0x555bd300) at src/libavcodec/avpacket.c:595 #3 0x76a930f8 in decode_simple_internal (frame=0x555bd480, avctx=0x555bb640) at src/libavcodec/decode.c:377 #4 0x76a930f8 in decode_simple_receive_frame (frame=, avctx=) at src/libavcodec/decode.c:594 #5 0x76a930f8 in decode_receive_frame_internal (avctx=avctx@entry=0x555bb640, frame=frame@entry=0x555bd480) at src/libavcodec/decode.c:612 #6 0x76a95bbb in avcodec_receive_frame (avctx=0x555bb640, frame=0x555bd480) at src/libavcodec/decode.c:726 #7 0x76a95e7b in compat_decode (avctx=0x555bb640, frame=0x555bd480, got_frame=0x7fffd910, pkt=0x555ba9a0) at src/libavcodec/decode.c:782 #8 0xf3a4 in frame_reader_run (n=0x555ba960) at ffsox_frame_reader.c:277 #9 0xf633 in ffsox_engine_run (e=0x7fffd9a0, node=0x555ba960) at ffsox_engine.c:33 #10 0x5556147d in ffsox_sox_reader_read (sa=0x55599410, buf=0x555c91c0, len=8192) at ffsox_sox_reader.c:117 #11 0x55561a0c in drain (e=0x555bdb90, obuf=0x555c91c0, osamp=0x7fffda98) at ffsox_sox_read_handler.c:56 #12 0x763bd933 in drain_effect (n=0, chain=0x555963e0) at effects.c:352 #13 0x763bd933 in sox_flow_effects (chain=, callback=0x0, client_data=0x0) at effects.c:445 #14 0xdae4 in ffsox_analyze (ac=0x7fffdda0, ai=-1, vi=-1) at ffsox_analyze.c:164 #15 0xa77a in bs1770gain_tree_analyze (tree=0x7fffde60, odirname=0x0, options=0x7fffdeb0) at bs1770gain_tree.c:155 #16 0x8f96 in main (argc=2, argv=0x7fffe0e8) at bs1770gain.c:1053 On Sat, 6 Oct 2018 at 15:58, Etienne Dechamps wrote: > > Package: bs1770gain > Version: 0.4.12-3+b1 > Severity: important > > --- Please enter the report below this line. --- > bs1770gain segfaults when running on most MP3 files. (Other formats, > like FLAC, appear to work fine.) > > Steps to reproduce: > $ sox -n sine.wav synth 1 sine 1000 > ... > $ ffmpeg -i sine.wav sine.mp3 > ... > $ bs1770gain sine.mp3 > analyzing ... > [1/1] "sine.mp3": Segmentation fault (core dumped) > > GDB stacktrace with debug symbols: > > analyzing ... > [1/1] "sine.mp3": > Program received signal SIGSEGV, Segmentation fault. > 0x555d08b0 in ?? () > (gdb) bt > #0 0x555d08b0 in () > #1 0x77da900e in av_buffer_unref () at > /usr/lib/x86_64-linux-gnu/libavutil.so.56 > #2 0x76a0d4c5 in av_packet_unref > (pkt=pkt@entry=0x555b6300) at src/libavcodec/avpacket.c:595 > #3 0x76a930f8 in decode_simple_internal > (frame=0x555b6480, avctx=0x555b4640) at > src/libavcodec/decode.c:377 > #4 0x76a930f8 in decode_simple_receive_frame > (frame=, avctx=) at > src/libavcodec/decode.c:594 > #5 0x76a930f8 in decode_receive_frame_internal > (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480) > at src/libavcodec/decode.c:612 > #6 0x76a95bbb in avcodec_receive_frame (avctx=0x555b4640, > frame=0x555b6480) at src/libavcodec/decode.c:726 > #7 0x76a95e7b in compat_decode > (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480, > got_frame=got_frame@entry=0x7fffd964, > pkt=pkt@entry=0x555b39a0) at src/libavcodec/decode.c:782 > #8 0x76a9624d in avcodec_decode_audio4 > (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480, > got_frame_ptr=got_frame_ptr@entry=0x7fffd964, > avpkt=avpkt@entry=0x555b39a0) at src/libavcodec/decode.c:838 > #9 0xd5e2 in frame_reader_run (n=0x555b3960) at > ffsox_frame_reader.c:172 > #10 0xdb0c in ffsox_machine_run (m=m@entry=0x7fffd9d0, > node=, node@entry=0x55592410) > at ffsox_machine.c:30 > #11 0xf4be in ffsox_sox_reader_read > (sa=sa@entry=0x55592410, buf=, len=) > at ffsox_sox_reader.c:117 > #12 0xf5a2 in drain (e=, obuf= out>, osamp=0x7fffdac8) at ffsox_sox_read_handler.c:56 > #13 0x763bd933 in drain_effect (n=0, chain=0x5558f3e0) at > effects.c:352 > #14 0x763bd933 in sox_flow_effects > (chain=chain@entry=0x5558f3e0, callback=callback@entry= > 0x0, client_data=client_data@entry=0x0) at effects.c:445 > #15 0xc704 in ffsox_analyze (ac=ac@entry=0x7fffdde0, > ai=, vi=) at ffsox_analyze.c:159 > #16 0xa6ae in bs1770gain_tree_analyze (tree= out>, odirname=0x0, options=0x7fffdef0) at bs1770gain_tree.c:14
Bug#910451: bs1770gain segfaults on MP3 files
Package: bs1770gain Version: 0.4.12-3+b1 Severity: important --- Please enter the report below this line. --- bs1770gain segfaults when running on most MP3 files. (Other formats, like FLAC, appear to work fine.) Steps to reproduce: $ sox -n sine.wav synth 1 sine 1000 ... $ ffmpeg -i sine.wav sine.mp3 ... $ bs1770gain sine.mp3 analyzing ... [1/1] "sine.mp3": Segmentation fault (core dumped) GDB stacktrace with debug symbols: analyzing ... [1/1] "sine.mp3": Program received signal SIGSEGV, Segmentation fault. 0x555d08b0 in ?? () (gdb) bt #0 0x555d08b0 in () #1 0x77da900e in av_buffer_unref () at /usr/lib/x86_64-linux-gnu/libavutil.so.56 #2 0x76a0d4c5 in av_packet_unref (pkt=pkt@entry=0x555b6300) at src/libavcodec/avpacket.c:595 #3 0x76a930f8 in decode_simple_internal (frame=0x555b6480, avctx=0x555b4640) at src/libavcodec/decode.c:377 #4 0x76a930f8 in decode_simple_receive_frame (frame=, avctx=) at src/libavcodec/decode.c:594 #5 0x76a930f8 in decode_receive_frame_internal (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480) at src/libavcodec/decode.c:612 #6 0x76a95bbb in avcodec_receive_frame (avctx=0x555b4640, frame=0x555b6480) at src/libavcodec/decode.c:726 #7 0x76a95e7b in compat_decode (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480, got_frame=got_frame@entry=0x7fffd964, pkt=pkt@entry=0x555b39a0) at src/libavcodec/decode.c:782 #8 0x76a9624d in avcodec_decode_audio4 (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480, got_frame_ptr=got_frame_ptr@entry=0x7fffd964, avpkt=avpkt@entry=0x555b39a0) at src/libavcodec/decode.c:838 #9 0xd5e2 in frame_reader_run (n=0x555b3960) at ffsox_frame_reader.c:172 #10 0xdb0c in ffsox_machine_run (m=m@entry=0x7fffd9d0, node=, node@entry=0x55592410) at ffsox_machine.c:30 #11 0xf4be in ffsox_sox_reader_read (sa=sa@entry=0x55592410, buf=, len=) at ffsox_sox_reader.c:117 #12 0xf5a2 in drain (e=, obuf=, osamp=0x7fffdac8) at ffsox_sox_read_handler.c:56 #13 0x763bd933 in drain_effect (n=0, chain=0x5558f3e0) at effects.c:352 #14 0x763bd933 in sox_flow_effects (chain=chain@entry=0x5558f3e0, callback=callback@entry= 0x0, client_data=client_data@entry=0x0) at effects.c:445 #15 0xc704 in ffsox_analyze (ac=ac@entry=0x7fffdde0, ai=, vi=) at ffsox_analyze.c:159 #16 0xa6ae in bs1770gain_tree_analyze (tree=, odirname=0x0, options=0x7fffdef0) at bs1770gain_tree.c:141 #17 0x808a in main (argc=, argv=0x7fffe118) at bs1770gain.c:970 --- System information. --- Architecture: Kernel: Linux 4.18.0-1-amd64 Debian Release: buster/sid 500 unstable-debug deb.debian.org 500 unstabledeb.debian.org 500 stretch packagecloud.io 500 stable www.ubnt.com 1 experimental-debug deb.debian.org 1 experimentaldeb.debian.org --- Package information. --- Depends (Version) | Installed ===-+-= libavcodec58(>= 7:4.0) | 7:4.0.2-2 OR libavcodec-extra58 (>= 7:4.0) | libavformat58(>= 7:4.0) | 7:4.0.2-2 libavutil56 (>= 7:4.0) | 7:4.0.2-2 libc6 (>= 2.14) | 2.27-6 libsox3(>= 14.4.2~) | 14.4.2-3 libswresample3 (>= 7:4.0) | 7:4.0.2-2 Package's Recommends field is empty. Package's Suggests field is empty.
Bug#883380: systemd 235 segfaults when using BindPaths or BindReadOnlyPaths
Package: systemd Version: 235-3 Severity: important Tags: patch upstream fixed-upstream After upgrading to systemd 235-3 I ran into the exact issue described at https://github.com/systemd/systemd/issues/7055 That is, systemd segfaults when trying to start a unit that makes use of BindPaths or BindReadOnlyPaths. Fortunately it's the child process that segfaults, not the main systemd process itself - but it still makes it impossible to start the unit. A trivial one-line fix is available at https://github.com/yuwata/systemd/commit/a8cabc612b16834260831a8163ae4b479b5c33a5 In the mean time, a workaround is to rollback to systemd 234-3.
Bug#874136: Upgrading to libtorrent 1.1.0 or 1.1.1 can corrupt torrent filenames
Package: libtorrent-rasterbar9 Version: 1.1.1-1+b2 Severity: serious Due to a bug in libtorrent 1.1.0 and 1.1.1, renaming a torrent (or, more worryingly, loading a torrent that was renamed in the past) can result in filename corruption, where subdirectories appear out of nowhere. See: http://dev.deluge-torrent.org/ticket/2898 Because this bug also affects torrents that were added *before* the upgrade, it can create a complete mess where pieces of torrents get scattered everywhere. Recovering from such a "disaster" can be tricky and time-consuming. Please upload a fixed version of the package, either by cherry-picking the fix (https://github.com/arvidn/libtorrent/pull/1524) or by upgrading to libtorrent >=1.1.2.
Bug#798080: mysql-server-5.6: service stop hangs forever on systemd
Package: mysql-server-5.6 Version: 5.6.25-3 Severity: important "systemctl stop mysql" hangs forever after I upgraded from MySQL 5.5 to 5.6. The systemd journal shows the following: Sep 05 10:53:45 zyklos.edechamps.fr systemd[1]: Stopping MySQL Community Server... Sep 05 10:53:45 zyklos.edechamps.fr mysqld_safe[14465]: Could not open required defaults file: /etc/mysql/debian.cnf Sep 05 10:53:45 zyklos.edechamps.fr mysqld_safe[14465]: Fatal error in defaults handling. Program aborted Sep 05 10:53:45 zyklos.edechamps.fr mysqld_safe[14465]: 150905 10:53:45 mysqld_safe Number of processes running now: 1 Sep 05 10:53:45 zyklos.edechamps.fr mysqld_safe[14465]: 150905 10:53:45 mysqld_safe mysqld process hanging, pid 14781 - killed Sep 05 10:53:45 zyklos.edechamps.fr mysqld_safe[14465]: 150905 10:53:45 mysqld_safe mysqld restarted Digging further, I took a look at the offending file: $ ls -l /etc/mysql/debian.cnf -rw--- 1 root root 333 Oct 26 2011 /etc/mysql/debian.cnf Then I tried to fix its permissions so that mysqld_safe (which is running as the mysql user) can access it: # chown root:mysql /etc/mysql/debian.cnf # chmod 640 /etc/mysql/debian.cnf Unfortunately, that seems to only have moved the problem elsewhere: Sep 05 10:54:50 zyklos.edechamps.fr systemd[1]: Stopping MySQL Community Server... Sep 05 10:54:50 zyklos.edechamps.fr mysqld_safe[15017]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed Sep 05 10:54:50 zyklos.edechamps.fr mysqld_safe[15017]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' Sep 05 10:54:50 zyklos.edechamps.fr mysqld_safe[15017]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists! Sep 05 10:54:50 zyklos.edechamps.fr mysqld_safe[15017]: 150905 10:54:50 mysqld_safe Number of processes running now: 1 Sep 05 10:54:50 zyklos.edechamps.fr mysqld_safe[15017]: 150905 10:54:50 mysqld_safe mysqld process hanging, pid 15334 - killed Sep 05 10:54:50 zyklos.edechamps.fr mysqld_safe[15017]: 150905 10:54:50 mysqld_safe mysqld restarted Error 2 is ENOENT (No such file or directory). I find this puzzling, because the file *does* exist (even after I started the stop operation): $ ls -l /var/run/mysqld/mysqld.sock srwxrwxrwx 1 mysql mysql 0 Sep 5 10:54 /var/run/mysqld/mysqld.sock Even more puzzling, the following works, even if I run it as the mysql user: # /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf shutdown For now, I have come up with the following workaround: # chown root:mysql /etc/mysql/debian.cnf # chmod 640 /etc/mysql/debian.cnf # cat > /etc/systemd/system/mysql.service.d/workaround-shutdown-bug.conf < socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost user = debian-sys-maint password = socket = /var/run/mysqld/mysqld.sock basedir = /usr -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mysql-server-5.6 depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.57 ii init-system-helpers1.23 ii initscripts2.88dsf-59.2 ii libaio10.3.110-1 ii libc6 2.19-19 ii libdbi-perl1.633-1 ii libgcc11:5.2.1-16 ii libstdc++6 5.2.1-16 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian14 ii mysql-client-5.6 5.6.25-3 ii mysql-common 5.6.25-3 ii mysql-server-core-5.6 5.6.25-3 ii passwd 1:4.2-3 ii perl 5.20.2-6 ii psmisc 22.21-2.1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages mysql-server-5.6 recommends: ii libhtml-template-perl 2.95-2 Versions of packages mysql-server-5.6 suggests: ii mailutils [mailx] 1:2.99.98-2+b1 pn tinyca -- debconf information: mysql-server/no_upgrade_when_using_ndb: mysql-server-5.6/really_downgrade: false mysql-server/password_mismatch: mysql-server-5.6/nis_warning: mysql-server-5.6/postrm_remove_databases: false mysql-server-5.6/start_on_boot: true mysql-server/error_setting_password:
