Bug#933386: ncurses-term: Packaged alacritty terminfo file conflicts with official one
Package: ncurses-term Version: 6.1+20190713-1 Severity: important Dear Maintainer, The latest version of this package bundles a terminfo file for the alacritty terminal emulator (/usr/share/terminfo/a/alacritty). This terminfo file is also provided by the official alacritty repo, when built and installed with cargo-deb: $ cargo deb --install --manifest-path alacritty/Cargo.toml ... Preparing to unpack .../alacritty_0.3.3_amd64.deb ... Unpacking alacritty (0.3.3) ... dpkg: error processing archive /home/rlue/tmp/alacritty/target/debian/alacritty_0.3.3_amd64.deb (--install): trying to overwrite '/usr/share/terminfo/a/alacritty', which is also in package ncurses-term 6.1+20190713-1 Processing triggers for mime-support (3.62) ... Errors were encountered while processing: /home/rlue/tmp/alacritty/target/debian/alacritty_0.3.3_amd64.deb cargo-deb: installation failed, because dpkg -i returned error I am not sure whether this constitutes an issue in the official ncurses-term debian package or in alacritty’s cargo-deb packaging configuration, but I am assuming it is the former. In any case, I have filed an issue on alacritty’s GitHub tracker for cross-referencing purposes: https://github.com/jwilm/alacritty/issues/2685 Thanks for your time and consideration. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ncurses-term depends on: ii ncurses-base 6.1+20190713-1 ncurses-term recommends no packages. ncurses-term suggests no packages. -- no debconf information
Bug#907178: gimp-plugin-registry: resynthesizer not appearing in menu Filters/Enhance
Package: gimp-plugin-registry Version: 9.20180625 Followup-For: Bug #907178 Dear Maintainer, I experienced this issue yesterday. Posted on reddit about it, where someone suggested that installing gimp-python would fix the issue: https://www.reddit.com/r/debian/comments/bto0q0/gimp_heal_selection_filter_doesnt_show_even/ep1m53t/ Tried it, and it worked! Please add gimp-python as a dependency of gimp-plugin-registry. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp-plugin-registry depends on: ii gimp 2.10.8-2 ii libatk1.0-0 2.30.0-2 ii libbabl-0.1-00.1.62-1 ii libc62.28-10 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libfribidi0 1.0.5-3.1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgegl-0.4-00.4.12-2 ii libgimp2.0 2.10.8-2 ii libglib2.0-0 2.58.3-1 ii libgtk2.0-0 2.24.32-3 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjson-glib-1.0-0 1.4.4-2 ii liblcms2-2 2.9-3 ii liblqr-1-0 0.4.2-2.1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpangoft2-1.0-01.42.4-6 ii libstdc++6 8.3.0-6 ii libtiff-tools4.0.10-4 ii libtiff5 4.0.10-4 ii python 2.7.16-1 ii xdg-utils1.1.3-1 Versions of packages gimp-plugin-registry recommends: ii gimp-gmic 2.4.5-1 Versions of packages gimp-plugin-registry suggests: pn icc-profiles -- no debconf information
Bug#921224: anki: Syncing to AnkiWeb fails with Unknown response code: 400
Package: anki
Version: 2.1.7+dsfg-1
Severity: normal
Dear Maintainer,
The current version of Anki (2.1.7) fails to sync with AnkiWeb,
and gives the following traceback:
Syncing failed:
Traceback (most recent call last):
File "/usr/share/anki/aqt/sync.py", line 348, in run
self._sync()
File "/usr/share/anki/aqt/sync.py", line 373, in _sync
self.hkey = self.server.hostKey(*self.auth)
File "/usr/share/anki/anki/sync.py", line 574, in hostKey
badAuthRaises=False)
File "/usr/share/anki/anki/sync.py", line 556, in req
self.assertOk(r)
File "/usr/share/anki/anki/sync.py", line 495, in assertOk
raise Exception("Unknown response code: %s" % resp.status_code)
Exception: Unknown response code: 400
After uninstalling via APT and then re-installing version 2.1.8 via
tarball (from ankisrs.net), syncing succeeds.
Any idea when 2.1.8 will be migrated to testing?
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages anki depends on:
ii libjs-jquery3.3.1~dfsg-1
pn libjs-jquery-flot
pn libjs-jquery-ui
pn libjs-mathjax
ii libqt5core5a5.11.3+dfsg-2
ii python3 3.7.2-1
ii python3-bs4 4.6.3-2
pn python3-decorator
ii python3-distutils 3.7.2-3
pn python3-markdown
pn python3-pyaudio
ii python3-pyqt5 5.11.3+dfsg-1+b3
ii python3-pyqt5.qtwebchannel 5.11.3+dfsg-1+b3
ii python3-pyqt5.qtwebengine 5.11.3+dfsg-1+b3
ii python3-requests2.20.0-2
pn python3-send2trash
Versions of packages anki recommends:
pn python3-matplotlib
Versions of packages anki suggests:
pn dvipng
pn lame
ii mpv 0.29.1-1
Bug#913045: [Pkg-alsa-devel] Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
Hi Elimar, Sorry for the radio silence. I thought I responded in a previous email, but I guess it never went through? I believe the issue goes deeper than simply setting soundcard priority. I’m experiencing it on two different machines, and I’m trying (and failing) to play sound out of the default device. Desktop: $ cat /proc/asound/cards 0 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xf7e14000 irq 50 1 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7e1 irq 48 2 [U0x46d0x81b]: USB-Audio - USB Device 0x46d:0x81b USB Device 0x46d:0x81b at usb-:00:14.0-1, high speed Laptop: $ cat /proc/asound/cards 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xe124 irq 127 Both the .asoundrc you suggested and the one given by Pedro Silva solve the problem for me, but it would be nice not to need an .asoundrc to play sound out of the default (or only) sound device. Given that this is happening on a machine with only one sound card device, and that it was working in 1.1.6-1, is there any chance we could have this issue reopened? (FWIW, I’m working against libasound2-plugins 1.1.7-2; don’t know how to upgrade to 1.1.7-3, since I’m on testing and not unstable. Happy to help with any additional debugging.) —Ryan On 2018 Nov 06, Elimar Riesebieter wrote: > * Ryan Lue [2018-11-06 18:51 +0800]: > > > Package: libasound2 > > Version: 1.1.7-1 > > Severity: important > > > > Dear Maintainer, > > > > Please forgive my lack of familiarity with ALSA. > > > > I use sox in a script to play an mp3 via STDIN, using the > > AUDIODRIVER=alsa environment variable. Since upgrading libasound2 from > > 1.1.6-1 to 1.1.7-1 this morning, the script now gives the following > > error: > > > > ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave > > play FAIL formats: can’t open output file `default’: snd_pcm_open > > error: No such file or directory > > > > I ran speaker-test to try to isolate the problem. The output is below: > > > > speaker-test 1.1.6 > > > > Playback device is default > > Stream parameters are 48000Hz, S16_LE, 1 channels > > Using 16 octaves of pink noise > > ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave > > Playback open error: -2,No such file or directory > > > > Sound works throughout the rest of the system – I assume via PulseAudio? > > > > I’m happy to provide any other information to help diagnose the problem. > > libasound2-plugins 1.1.7-2 and alsa-utils 1.1.7-1 should arrive soon > in testing. Please update them first and come back to this bug > report. > > Thanks for your patience > > Elimar > -- > Obviously the human brain works like a computer. > Since there are no stupid computers humans can't be stupid. > There are just a few running with Windows or even CE ;-)
Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
Package: libasound2 Version: 1.1.7-1 Severity: important Dear Maintainer, Please forgive my lack of familiarity with ALSA. I use sox in a script to play an mp3 via STDIN, using the AUDIODRIVER=alsa environment variable. Since upgrading libasound2 from 1.1.6-1 to 1.1.7-1 this morning, the script now gives the following error: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave play FAIL formats: can’t open output file `default’: snd_pcm_open error: No such file or directory I ran speaker-test to try to isolate the problem. The output is below: speaker-test 1.1.6 Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave Playback open error: -2,No such file or directory Sound works throughout the rest of the system – I assume via PulseAudio? I’m happy to provide any other information to help diagnose the problem. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libasound2 depends on: ii libasound2-data 1.1.7-1 ii libc62.27-8 libasound2 recommends no packages. Versions of packages libasound2 suggests: ii libasound2-plugins 1.1.6-1+b1 -- no debconf information
Bug#836206: lolcat: shebang should not use env
Package: lolcat Version: 42.0.99-1 Followup-For: Bug #836206 Can confirm that this bug is still present in Debian Buster. Recently posted an issue with lolcat on GitHub https://github.com/busyloop/lolcat/issues/76 but no one there appears to be actively involved in maintaining the Debian package. Any chance of seeing this fixed sometime soon? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lolcat depends on: ii ruby 1:2.5.1 ii ruby-paint0.8.6-2 ii ruby-trollop 2.0-2 lolcat recommends no packages. lolcat suggests no packages. -- no debconf information
Bug#898392: fcitx: default cangjie package (fcitx-table-cangjie) does not add input method
Package: fcitx Version: 1:4.2.9.6-2 Severity: normal Tags: l10n There are currently four variants of cangjie tables for fcitx: * fcitx-table-cangjie * fcitx-table-cangjie-big * fcitx-table-cangjie-3 * fcitx-table-cangjie-5 While the latter three packages add new input methods to the fcitx menu, the first one does not. I am posting this bug at the suggestion of Boyuan Yang, a “de factor contributor/maintainer of fcitx in Debian”. https://groups.google.com/d/msg/fcitx/85q7fn-4kZg/5umJZnX7AgAJ As a suggestion, perhaps all variants of cangjie could be unified under a single fcitx-table-cangjie metapackage? Also, it’s not clear to me what the difference between any of these variants are. Perhaps some simple documentation belonging to the metapackage could help in that regard. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fcitx depends on: ii fcitx-bin 1:4.2.9.6-2 ii fcitx-data 1:4.2.9.6-2 ii fcitx-modules 1:4.2.9.6-2 Versions of packages fcitx recommends: ii fcitx-config-gtk 0.4.10-1 ii fcitx-frontend-fbterm 0.2.0-2+b2 ii fcitx-ui-classic 1:4.2.9.6-2 ii im-config [im-switch] 0.34-1 Versions of packages fcitx suggests: pn fcitx-m17n pn fcitx-tools -- no debconf information
Bug#887932: firmware-iwlwifi: Bluetooth not working
Package: firmware-iwlwifi Version: 20161130-3 Followup-For: Bug #887932 Just a quick follow-up on my last message: Downgrading to 20161130-3 allows bluetooth devices to connect, BUT Wi-Fi performance is severely degraded when bluetooth is connected. Better than nothing, though. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.130 -- no debconf information
Bug#887932: firmware-iwlwifi: Bluetooth not working
Package: firmware-iwlwifi Followup-For: Bug #887932 I’d like to add that upgrading from stretch (20161130-3) to buster (20170823-1) broke bluetooth on my machine. I suspect the symptoms were different — I don’t use GNOME, but ‘hciconfig -a’ did report my Bluetooth adapter. However, ‘bluetoothctl’ would fail unpredictably in a couple places: 1. On a fresh boot with no devices connected, I could ‘power on’, ‘scan on’, and even sometimes ‘pair ’, but ‘connect ’ would time out (‘hci0 command tx timeout’). 2. But more often, I could only ‘power on’ and ‘scan on’, and then ‘devices’ always turned up empty. I have an Intel 8260 WiFi/Bluetooth adapter (from a ThinkPad T460). Downgrading to the stretch version (20161130-3) fixes the problem. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.130 -- no debconf information
Bug#898234: fcitx-libpinyin: In Bopomofo, left half of keyboard won't initiate Chinese input
Package: fcitx-libpinyin Version: 0.5.3-1 Severity: important Tags: l10n I recently upgraded from stretch to buster, and discovered that fcitx-zhuyin was superseded by fcitx-libpinyin. When typing in “Bopomofo (LibPinyin)”, keys in the leftmost four columns of the keyboard ([1234qwerasdfzxcv]) produce literal characters from the base system keyboard layout, instead of the starting zhuyin input. For instance, if I type “su3cl3” (for ㄋㄧˇㄏㄠˇ / 你好), I expect to see exactly those Zhuyin characters in the candidate window, along with the candidate Chinese characters. Instead, I get this: https://youtu.be/uWE-WLnUh4E The first character appears as a literal ‘s’, and Zhuyin input does not begin until the following character (“ㄧ”). The “c” is also interpreted as a literal Latin “c” at first, and then becomes a “ㄏ” only after the next character is entered. However, if I enter the word in reverse order (final-then-inital) followed by the tone (as in, “us3” / “ㄧㄋˇ”), then it recognizes “s” as the Zhuyin “ㄋ” immediately. (Unfortunately, typing each word in reverse order is impractically cumbersome.) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fcitx-libpinyin depends on: ii libc62.27-3 ii libdbus-1-3 1.12.6-2 ii libfcitx-config4 1:4.2.9.6-2 ii libfcitx-qt5-1 1.2.2-2 ii libfcitx-utils0 1:4.2.9.6-2 ii libgcc1 1:8.1.0-1 ii libglib2.0-0 2.56.1-2 ii libpinyin-data 2.2.0-1 ii libpinyin13 2.2.0-1 ii libqt5core5a 5.10.1+dfsg-5 ii libqt5dbus5 5.10.1+dfsg-5 ii libqt5gui5 5.10.1+dfsg-5 ii libqt5network5 5.10.1+dfsg-5 ii libqt5webenginewidgets5 5.10.1+dfsg-3 ii libqt5widgets5 5.10.1+dfsg-5 ii libstdc++6 8.1.0-1 fcitx-libpinyin recommends no packages. fcitx-libpinyin suggests no packages. -- no debconf information
Bug#898233: fcitx-libpinyin: No Traditional Chinese for Bopomofo (Zhuyin)
Package: fcitx-libpinyin Version: 0.5.3-1 Severity: important Tags: l10n Dear Maintainer, I recently upgraded from stretch to buster, and discovered that fcitx-zhuyin was superseded by fcitx-libpinyin. With “Bopomofo (LibPinyin)”, the candidate character menu (and output) appears in Simplified Chinese. I have tried selecting “Traditional Chinese” from fcitx’s taskbar menu, but that does not change the behavior of the program. (Moreover, Traditional Chinese should be the default setting for the Bopomofo input method, since it is used predominantly in Taiwan.) I did not encounter this problem with “Bopomofo (Zhuyin)”. I’m not sure if this is important, but the only other fcitx input method I have installed is fcitx-table-cangjie5. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fcitx-libpinyin depends on: ii libc62.27-3 ii libdbus-1-3 1.12.6-2 ii libfcitx-config4 1:4.2.9.6-2 ii libfcitx-qt5-1 1.2.2-2 ii libfcitx-utils0 1:4.2.9.6-2 ii libgcc1 1:8.1.0-1 ii libglib2.0-0 2.56.1-2 ii libpinyin-data 2.2.0-1 ii libpinyin13 2.2.0-1 ii libqt5core5a 5.10.1+dfsg-5 ii libqt5dbus5 5.10.1+dfsg-5 ii libqt5gui5 5.10.1+dfsg-5 ii libqt5network5 5.10.1+dfsg-5 ii libqt5webenginewidgets5 5.10.1+dfsg-3 ii libqt5widgets5 5.10.1+dfsg-5 ii libstdc++6 8.1.0-1 fcitx-libpinyin recommends no packages. fcitx-libpinyin suggests no packages. -- no debconf information
