Bug#1053117: r8152 driver unable to bring up RTL8156BG
Package: linux-image-6.5.0-1-amd64 Version: 6.5.3-1 The r8152 driver is unable to bring up a RTL8156BG device. It's able to enumerate and present some info, but actually passing packets fails. I will note that the RTL8156BG firmware is not in the the firmware-realtek package, unlike its sister chips. The RTL8156BG can be found in the Framework Ethernet Module.
Bug#1053116: cdc_ncm driver fails to bring up RTL8156BG
Package: linux-image-6.1.0-11-amd64-unsigned Version: 6.1.38-4 The cdc_ncm driver is able to enumerate an RTL8156BG device, and glean some capabilities, but it is unable to fully bring up and utilize it, for unknown errors. (The systemd log doesn't contain any details, just a generic failed message.) This chipset can be found in the Framework Ethernet Module. Note that Ubuntu and Fedora are able to use cdc_ncm with the RTL8156BG, with some quirks. (Namely, it comes up in half-duplex mode.) So I'm pretty sure this is a Debian-specific bug.
Bug#1037549: Support for RTL8156BG broken
Package: linux-image-6.1.0-9-amd64 Version: 6.1.27-1 Currently, Debian tries to use the cdc_ncm driver with the RTL8156BG, which fails without useful error. (ifup says the interface doesn't exist, neither systemd nor dmesg log anything notable, ip addr reports a mac address.) I think it's supposed to use the r8152 driver, but the magic strings to use it are missing, and firmware-realtek might not have the correct blob. Additional notes for this diagnostic journey can be found at https://community.frame.work/t/responded-debian-11-ethernet-expansion-card-doesnt-work-after-install/24482/8 Based on my exploration of the kernel.org repos, this might need to be fixed by Realtek itself.
Bug#971881: gnome-shell: cursor disappearing
Package: gnome-shell Version: 3.38.0-2 Severity: normal X-Debbugs-Cc: ja...@ivyleav.es GPU: Radeon RX 580 Series (POLARIS10, DRM 3.38.0, 5.8.0-2-amd64, LLVM 10.0.1) Driver: amdgpu I built this computer a few weeks ago, and the cursor has been glitching the entire time (trails, bounding boxes). This week, it stopped rendering all together. It happens on Xorg and Wayland, does not happen in gdm or sway, so I'm concluding that it has to do with gnome-shell. Setting sofware cursor in xorg's configuration file causes the cursor to render but the graphic does not move (but the underlying logical cursor still does, eg hot corners still work). -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, 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 gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 ii evolution-data-server3.36.4-1 ii gir1.2-accountsservice-1.0 0.6.55-3 ii gir1.2-atspi-2.0 2.38.0-2 ii gir1.2-freedesktop 1.66.0-1 ii gir1.2-gcr-3 3.38.0-1 ii gir1.2-gdesktopenums-3.0 3.38.0-2 ii gir1.2-gdm-1.0 3.38.0-2 ii gir1.2-geoclue-2.0 2.5.6-1 ii gir1.2-glib-2.0 1.66.0-1 ii gir1.2-gnomebluetooth-1.03.34.3-2 ii gir1.2-gnomedesktop-3.0 3.38.0-2 ii gir1.2-gtk-3.0 3.24.23-1 ii gir1.2-gweather-3.0 3.36.1-1 ii gir1.2-ibus-1.0 1.5.22-5 ii gir1.2-mutter-7 3.38.0-2 ii gir1.2-nm-1.01.26.2-1 ii gir1.2-nma-1.0 1.8.30-1 ii gir1.2-pango-1.0 1.46.2-1 ii gir1.2-polkit-1.00.105-29 ii gir1.2-rsvg-2.0 2.50.0+dfsg-1 ii gir1.2-soup-2.4 2.72.0-2 ii gir1.2-upowerglib-1.00.99.11-2 ii gjs 1.66.0-1 ii gnome-backgrounds3.38.0-1 ii gnome-settings-daemon3.38.0-2 ii gnome-shell-common 3.38.0-2 ii gsettings-desktop-schemas3.38.0-2 ii gstreamer1.0-pipewire0.3.12-1 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-3 ii libcairo21.16.0-4 ii libecal-2.0-13.36.4-1 ii libedataserver-1.2-243.36.4-1 ii libgcr-base-3-1 3.38.0-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libgirepository-1.0-11.66.0-1 ii libgjs0g 1.66.0-1 ii libgles2 1.3.2-1 ii libglib2.0-0 2.66.0-2 ii libglib2.0-bin 2.66.0-2 ii libgnome-autoar-0-0 0.2.4-2 ii libgnome-desktop-3-193.38.0-2 ii libgraphene-1.0-01.10.2-1 ii libgtk-3-0 3.24.23-1 ii libical3 3.0.8-2 ii libjson-glib-1.0-0 1.6.0-1 ii libmutter-7-03.38.0-2 ii libnm0 1.26.2-1 ii libpango-1.0-0 1.46.2-1 ii libpangocairo-1.0-0 1.46.2-1 ii libpolkit-agent-1-0 0.105-29 ii libpolkit-gobject-1-00.105-29 ii libpulse-mainloop-glib0 13.0-5 ii libpulse013.0-5 ii libsecret-1-00.20.3-1 ii libsystemd0 246.6-1 ii libwayland-server0 1.18.0-2~exp1.1 ii libx11-6 2:1.6.12-1 ii libxfixes3 1:5.0.3-2 ii python3 3.8.2-3 Versions of packages gnome-shell recommends: ii bolt 0.9-1 ii chrome-gnome-shell10.1-5 ii gdm3 3.38.0-2 ii gkbd-capplet 3.26.1-1 ii gnome-control-center 1:3.38.0-2 ii gn
Bug#944104: Please install binary to /usr/bin
On Mon, Nov 4, 2019, at 07:04, Dmitry Smirnov wrote: > Package: conmon > Version: 2.0.2-1 > Severity: normal > > "conmon" installs its executable to "/usr/libexec/podman/conmon" > which is not where executable should be in Debian. > > Please ensure FHS compliance. > > Why not "/usr/bin/conmon"? 1. As I understand it, libexec is an acceptable place for binaries if they're not supposed to be called by the user. Conmon is not meant to be run by the user, but is somewhat internal to the container runtime. (I'll concede, this is debatable, and I'm not familiar with the intricacies if applying Debian policy.) 2. The conmon package exists in Debian because it is a dependency of podman (not yet packaged), and podman searches in specific places for conmon. Changing this list of places can be surprisingly difficult (as I discovered when I tried to add a /usr/local path upstream).
Bug#930781: python3-socks: Deprecation warning emitted on import
Package: python3-socks Version: 1.6.8+dfsg-1 Severity: normal Dear Maintainer, PySocks 1.6.8 has a deprecated import and a warning is emitted on import. This is triggered by importing requests, an extremely common HTTP library. It has been fixed in upstream 1.7.0 This happens for any software that uses requests, whether or not they depend on PySocks. It just happens for every application that uses it as soon as python3-socks is installed on a system. In addition, this warning becomes user-visible if the application surfaces warnings in some way (in a log or on stdout). -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-socks depends on: ii python3 3.7.3-1 python3-socks recommends no packages. python3-socks suggests no packages. -- no debconf information
Bug#894245: Salt, Tornado Incompatibility, and ZMQ Timeline
With the acceptance of pyzmq 17 into unstable and testing, this should be fixed. However, further problems have since been revealed; see below for further information. On Wed, May 2, 2018 at 11:34 AM, Jamie Bliss wrote: > > Hokay, so, > > Both #893817 and #896921 fall into the category "Tornado 5 incompatibility". Thomas's #893817 is specifically a ZeroMQ/Tornado 5 incompatibility which has since been fixed, but doing so revealed my #896921. To explain: > > * February 10: ZeroMQ release pyzmq 17.0.0 to PyPI > * March 22: Thomas files #893817 utilizing python3-zmq 16.0.2-2+b1, which is current for debian at the time > * March 30: pyzmq 17.0.0-1 is accepted into debian unstable > * April 4: pyzmq 17.0.0-1 is migrated to debian testing > * April 25: I file #896921 utilizing the new python3-zmq, revealing the new problem > > Upstream is tracking general Tornado5 problems at https://github.com/saltstack/salt/issues/45790 as mentioned previously. The pull request https://github.com/saltstack/salt/pull/47106 should fix my #896921. It was merged April 25 into 2017.7, so should make it into the next point releases for 2017.7 and 2018.3. > > Thanks, > Jamie
Bug#893817: Satl, Tornado incompatibility, and ZMQ Timeline
Hokay, so, Both #893817 and #896921 fall into the category "Tornado 5 incompatibility". Thomas's #893817 is specifically a ZeroMQ/Tornado 5 incompatibility which has since been fixed, but doing so revealed my #896921. To explain: * February 10: ZeroMQ release pyzmq 17.0.0 to PyPI * March 22: Thomas files #893817 utilizing python3-zmq 16.0.2-2+b1, which is current for debian at the time * March 30: pyzmq 17.0.0-1 is accepted into debian unstable * April 4: pyzmq 17.0.0-1 is migrated to debian testing * April 25: I file #896921 utilizing the new python3-zmq, revealing the new problem Upstream is tracking general Tornado5 problems at https://github.com/saltstack/salt/issues/45790 as mentioned previously. The pull request https://github.com/saltstack/salt/pull/47106 should fix my #896921. It was merged April 25 into 2017.7, so should make it into the next point releases for 2017.7 and 2018.3. Thanks, Jamie
Bug#896921: salt-minion does not start: TypeError: add_accept_handler() got an unexpected keyword argument 'io_loop'
Package: salt-minion Version: 2017.7.4+dfsg1-1 salt-minion in testing is no longer able to start due to API bugs: # salt-minion -l debug [DEBUG ] Reading configuration from /etc/salt/minion [DEBUG ] Including configuration from '/etc/salt/minion.d/_schedule.conf' [DEBUG ] Reading configuration from /etc/salt/minion.d/_schedule.conf [DEBUG ] Using cached minion ID from /etc/salt/minion_id: cayde7 [DEBUG ] Configuration file path: /etc/salt/minion [WARNING ] Insecure logging configuration detected! Sensitive data may be logged. [INFO] Setting up the Salt Minion "cayde7" [DEBUG ] Created pidfile: /var/run/salt-minion.pid [WARNING ] /usr/lib/python3/dist-packages/salt/minion.py:802: DeprecationWarning: zmq.eventloop.ioloop is deprecated in pyzmq 17. pyzmq now works with default tornado and asyncio eventloops. zmq.eventloop.ioloop.install() [DEBUG ] Using selector: EpollSelector [INFO] Starting up the Salt Minion [DEBUG ] AsyncEventPublisher PUB socket URI: /var/run/salt/minion/minion_event_166db1290b_pub.ipc [DEBUG ] AsyncEventPublisher PULL socket URI: /var/run/salt/minion/minion_event_166db1290b_pull.ipc [INFO] Starting pull socket on /var/run/salt/minion/minion_event_166db1290b_pull.ipc Process Process-1: Traceback (most recent call last): File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap self.run() File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3/dist-packages/salt/scripts.py", line 138, in minion_process minion.start() File "/usr/lib/python3/dist-packages/salt/cli/daemons.py", line 347, in start self.minion.tune_in() File "/usr/lib/python3/dist-packages/salt/minion.py", line 896, in tune_in self._bind() File "/usr/lib/python3/dist-packages/salt/minion.py", line 814, in _bind io_loop=self.io_loop, File "/usr/lib/python3/dist-packages/salt/utils/event.py", line 1019, in __init__ self.publisher.start() File "/usr/lib/python3/dist-packages/salt/transport/ipc.py", line 517, in start io_loop=self.io_loop, TypeError: add_accept_handler() got an unexpected keyword argument 'io_loop'
Bug#760343: Python3 Package?
Thanks for getting this into jessie. I noticed there isn't a a python3-protobuf package to go with the python-protobuf package. Since 2.6.0 added Python 3 support, shouldn't this be available?
