Bug#1068137: Please package newer upstream
Package: olive-editor Version: 20221024+ds-1+b2 Severity: wishlist It would be nice to have a more current snapshop of olive-editor. I tried the packaged version, but I run in numerious audio sync issues and other bugs that made it hard to actually use. A current version from the appimage though has audio that works correctly and most of the bugs I experienced look already fixed. Since there are no stable/official releases, I don't see a reason to rely on snapshot from 2022 and it would be nice to update. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages olive-editor depends on: ii ffmpeg7:6.1.1-3 ii frei0r-plugins1.8.0-1+b2 ii libavcodec-extra60 [libavcodec60] 7:6.1.1-3 ii libavfilter9 7:6.1.1-3 ii libavformat60 7:6.1.1-3 ii libavutil58 7:6.1.1-3 ii libc6 2.38-6 ii libgcc-s1 14-20240315-1 ii libopencolorio2.1t64 [libopencolorio2.1] 2.1.3+dfsg-1.1+b1 ii libopenexr-3-1-30 3.1.5-5.1+b2 ii libopenimageio2.4t64 [libopenimageio2.4] 2.4.17.0+dfsg-1.1+b1 ii libportaudio2 19.6.0-1.2+b2 ii libqt5core5t64 [libqt5core5a] 5.15.10+dfsg-7.2+b1 ii libqt5dbus5t64 [libqt5dbus5] 5.15.10+dfsg-7.2+b1 ii libqt5gui5t64 [libqt5gui5]5.15.10+dfsg-7.2+b1 ii libqt5multimedia5-plugins 5.15.10-2+b2 ii libqt5widgets5t64 [libqt5widgets5]5.15.10+dfsg-7.2+b1 ii libstdc++614-20240315-1 ii libswresample47:6.1.1-3 ii libswscale7 7:6.1.1-3 olive-editor recommends no packages. olive-editor suggests no packages.
Bug#1050692: Outdated configuration file version
Package: syslog-ng-core Version: 4.3.1-2 Severity: normal The configuration file provided in syslog-ng-core has "@version: 3.38", which triggers the following warning on startup: > WARNING: Configuration file format is too old, syslog-ng is running in > compatibility mode. Please update it to use the syslog-ng 4.3 format > at your time of convenience. Followed by: > WARNING: Your configuration file uses an obsoleted keyword, please > update your configuration; keyword='stats_freq', change='Use the stats() > block. E.g. stats(freq(1));', > location='/etc/syslog-ng/syslog-ng.conf:14:3'
Bug#1049983: panic: connection already exists
Package: syncthing
Version: 1.19.2~ds1-2
Severity: normal
With 1.19.2~ds1-2 syncthing panis immediately on the first connection
with the following error:
| goroutine 685 [select]:
|
github.com/syncthing/syncthing/lib/fs.(*BasicFilesystem).watchLoop(0xc0002ec180,
{0x12318d0, 0xc00066f7c0}, {0x1221680, 0x1}, {0xc00270ca00, 0x1, 0x1},
0xc0026a6480, 0xc0005f1080, ...)
| github.com/syncthing/syncthing/lib/fs/basicfs_watch.go:81 +0x13d
| created by github.com/syncthing/syncthing/lib/fs.(*BasicFilesystem).Watch in
goroutine 836
| github.com/syncthing/syncthing/lib/fs/basicfs_watch.go:59 +0x453
| panic: connection already exists
Rolling back to 1.19.2~ds1-1+b5 and keeping everything else the same the
problem disappears...
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages syncthing depends on:
ii init-system-helpers 1.65.2
ii libc62.37-7
syncthing recommends no packages.
syncthing suggests no packages.
Bug#1043252: Ocaml 5.0.0
On Tue, Aug 08 2023, Stéphane Glondu wrote: > Meanwhile, there are things to do: > - generalize the use of ocaml_dune DH buildsystem (~60 packages) > - replace dependencies on ocaml-nox by ocaml, to eventually remove the > transitional package (~174 packages) > - wait for camlp5-buildscripts to pass NEW, so that camlp5 can be > updated (probably required for a new OCaml version) > - wait for OCaml packages to migrate to testing (~65 packages at the moment) Thanks! There's no plan to make 4.x and 5.x co-exist right?
Bug#1043252: Ocaml 5.0.0
Package: ocaml Version: 4.13.1-4 Severity: wishlist Is there any plan to eventually package ocaml 5.0.0? -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ocaml-base depends on: ii libc6 2.37-7 ocaml-base recommends no packages. ocaml-base suggests no packages.
Bug#1043125: Server is out of space
Package: debdelta
Version: 0.67
Severity: normal
Seems like the server hosting deltas has ran out of space on the
2023-08-01:
http://debdeltas.debian.net/logs.txt
| 2023-08-01 13:23:41,248 32034 ERROR append_to_sql_history error while
adding to history
| Traceback (most recent call last):
| File "/srv/debdelta.debian.org/bin/debdeltas_server", line 901, in
append_to_sql_history
| thesqlhistory.add(None, # it is difficult to recover the distribution here
| File "/srv/debdelta.debian.org/bin/deltas_history.py", line 84, in add
| self.sql_connection.execute('INSERT INTO deltas_history VALUES (null, ?,
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)',\
| sqlite3.OperationalError: database or disk is full
I'm unsure where else I could report this.
Bug#1041911: fails to parse regular entries
> Which was simply not do-able with the previous codebase; > so I'm quite stuck in chicken & egg problem and need > to cut the knot somehow. > > I never wrote any unit test before (even at work ...) > so this is my first attempt: > https://github.com/systemd-cron/systemd-cron/blob/master/test/test.py > > I will try to build a corpus of crontabs that triggers all the codepaths. > > Your's will be included. I appreciate your answer. Rest assured I wasn't complaining, just reporting :). I consider this par for the course in unstable (that is: that's exactly what I'm signing up for). And I take this opportunity to thank you for all the work you've done so far. I was an early adopter of systemd-cron and I've been using it and "the" compact user interface for timers for a long time now!
Bug#1041911: fails to parse regular entries
Package: systemd-cron Version: 1.16.1-1 Severity: important Unfortunately 1.16.1 doesn't accept my existing crontab, failing on the already on first line: crontab: unknown schedule in /tmp/crontab_o81kjgn_: */5 * * * * fetch-mail It seems that any entry with a '*' gets rejected -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd-cron depends on: ii cron-daemon-common 3.0pl1-162 ii libc6 2.37-6 ii python3 3.11.4-5 ii systemd [systemd-sysusers] 254~rc3-3 ii systemd-sysv254~rc3-3 systemd-cron recommends no packages. Versions of packages systemd-cron suggests: ii dma [mail-transport-agent] 0.13-1+b1
Bug#1041878: syntax error in crontab(1)
Package: systemd-cron
Version: 1.16-1
Severity: important
% crontab
File "/usr/bin/crontab", line 106
if (not len(job.timespec_month)
^
SyntaxError: '(' was never closed
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.4.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages systemd-cron depends on:
ii cron-daemon-common 3.0pl1-162
ii libc6 2.37-6
ii python3 3.11.4-5
ii systemd [systemd-sysusers] 254~rc2-3
ii systemd-sysv254~rc2-3
systemd-cron recommends no packages.
Versions of packages systemd-cron suggests:
ii dma [mail-transport-agent] 0.13-1+b1
Bug#1034678: Can't be installed with file conflicts with systemd
Package: qbittorrent-nox Version: 4.5.2-2 Severity: important dpkg: error processing archive /var/cache/apt/archives/qbittorrent-nox_4.5.2-2_amd64.deb (--unpack): trying to overwrite '/lib/systemd/systemd', which is also in package systemd 252.6-1 -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qbittorrent-nox depends on: ii libc62.36-9 ii libgcc-s112.2.0-14 ii libqt5core5a 5.15.8+dfsg-7 ii libqt5network5 5.15.8+dfsg-7 ii libqt5sql5 5.15.8+dfsg-7 ii libqt5sql5-sqlite5.15.8+dfsg-7 ii libqt5xml5 5.15.8+dfsg-7 ii libssl3 3.0.8-1 ii libstdc++6 12.2.0-14 ii libtorrent-rasterbar2.0 2.0.8-1+b1 ii zlib1g 1:1.2.13.dfsg-1 qbittorrent-nox recommends no packages. qbittorrent-nox suggests no packages.
Bug#1033057: Temporary directory /var/lib/aide/dailyaidecheck has wrong owner/mode
Package: aide Version: 0.18.1-1 Severity: normal After updating from 0.18-2 to 0.18.1-1, dailyaidecheck doesn't start anymore: dailyaidecheck[102105]: terminated: Temporary directory /var/lib/aide/dailyaidecheck has wrong owner/mode. systemd[1]: dailyaidecheck.service: Main process exited, code=exited, status=1/FAILURE aide is running through systemd. I'm testing it by doing: systemctl reset-failed dailyaidecheck.service systemctl start dailyaidecheck.service /var/lib/aide/dailyaidecheck is created by the script itself, and is left dangling as: drwxr-x--- 2 _aide _aide 4.0K Mar 16 13:02 dailyaidecheck/ -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aide depends on: ii libacl1 2.3.1-3 ii libaudit1 1:3.0.9-1 ii libc6 2.36-8 ii libcap2 1:2.66-3 ii libext2fs21.47.0-2 ii libmhash2 0.9.9.9-9 ii libpcre2-8-0 10.42-1 ii libselinux1 3.4-1+b5 ii zlib1g1:1.2.13.dfsg-1 Versions of packages aide recommends: ii aide-common 0.18.1-1 Versions of packages aide suggests: pn figlet
Bug#1031401: postgrey.service %r specifier deprecated
Source: postgrey Version: 1.37-1.1 Severity: normal systemd complains about %r usage when reloading postgrey's service file: postgrey.service: Specifier '%r' used in unit configuration, which is deprecated. Please update your unit file, as it does not work as intended. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1027068: cryptsetup: syntax error, unexpected ERROR, expecting CCHAR or UNUMBER or AS
On Fri, Dec 30 2022, Konomi wrote: > I just did another round of updates and rebooted and could not > reproduce the bug so I leave it to more experienced users to determine > what should be done. Looks like this was fixed by console-setup 1.214 for #1027247
Bug#1027284: mpfr_custom_get_kind broken in current 4.1.1
Package: libmpfr-dev Version: 4.1.1-1 Severity: important According to https://github.com/CGAL/cgal/issues/7064 mpfr 4.1.1 was updated after-the-fact without a version bump. mpfr 4.1.1 in debian has a broken macro definition of mpfr_custom_get_kind that prevents building against CGAL. Looks like the package needs to be refreshed with the updated upstream's version or apply the patch[0] independently. [0] https://github.com/BrianGladman/mpfr/commit/0ce17bae34a6c54de31b126f969d3ddd72c6bc37 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/16 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 libmpfr-dev:amd64 depends on: ii libgmp-dev 2:6.2.1+dfsg1-1.1 ii libmpfr64.1.1-1 libmpfr-dev:amd64 recommends no packages. Versions of packages libmpfr-dev:amd64 suggests: pn libmpfr-doc
Bug#1027068: cryptsetup: syntax error, unexpected ERROR, expecting CCHAR or UNUMBER or AS
Package: cryptsetup Version: 2:2.6.0-2 Followup-For: Bug #1027068 > There is no occurrence of ‘CCHAR’ or ‘UNUMBER’ in the source, so I > suspect this might be orthogonal to src:cryptsetup. Just FIY I was hit by the same. This happens before the vg password prompt, clearly something I would expect to find in initrd somewhere and sure enough CCHAR/UNUMBER are found inside "loadkeys" from the kbd package. This is run by setupcon: # loadkeys '/etc/console-setup/cached_UTF-8_del.kmap' syntax error, unexpected ERROR, expecting CCHAR or UNUMBER or AS even removing and regenerating the cached keymap results in the same. I wonder if Konomi can reproduce this? Is this possible to reassign this report to console-setup?
Bug#1024147: Please build with --disable-glcanvasegl
Package: libwxgtk3.2-0 Version: 3.2.1+dfsg-1 Severity: normal wxWidgets 3.1+ enables EGL support by default, which also needs to be enabled in GLEW. GLEW 2.2.0 EGL support is disabled (see #1020640 for bug in glew 2.2). This results a failure in creating an opengl context in several programs: see https://github.com/supermerill/SuperSlicer/issues/1093#issuecomment-1046004099 for one example. I'm not sure whether would be the best course of action (ie: patching glew or disabling EGL canvas support in wx). I'm currently rebuilding wx with --disable-glcanvasegl in order to fix this issue. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-4-amd64 (SMP w/16 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 libwxgtk3.2-0:amd64 depends on: ii libc62.36-5 ii libcairo21.16.0-6 ii libegl1 1.5.0-1 ii libfontconfig1 2.13.1-4.5 ii libgcc-s112.2.0-9 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libgl1 1.5.0-1 ii libglib2.0-0 2.74.1-2 ii libgtk-3-0 3.24.34-3 ii libjpeg62-turbo 1:2.1.2-1+b1 ii libnotify4 0.8.1-1 ii libpango-1.0-0 1.50.10+ds-1 ii libpangocairo-1.0-0 1.50.10+ds-1 ii libpangoft2-1.0-01.50.10+ds-1 ii libpng16-16 1.6.38-2 ii libsm6 2:1.2.3-1 ii libstdc++6 12.2.0-9 ii libtiff5 4.4.0-5+b1 ii libwayland-client0 1.21.0-1 ii libwayland-egl1 1.21.0-1 ii libwxbase3.2-0 3.2.1+dfsg-1 ii libx11-6 2:1.8.1-2 ii libxtst6 2:1.2.3-1.1 libwxgtk3.2-0:amd64 recommends no packages. libwxgtk3.2-0:amd64 suggests no packages.
Bug#1023711: Missing python_socks
Package: python3-aiohttp-socks Version: 0.7.1-1 Severity: grave aiohttp-socks 0.7.1 fails to import: >>> import aiohttp_socks Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/aiohttp_socks/__init__.py", line 4, in from python_socks import ( ModuleNotFoundError: No module named 'python_socks' -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/16 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 python3-aiohttp-socks depends on: ii python3 3.10.6-1 ii python3-aiohttp 3.8.3-1 ii python3-attr 22.1.0-1 python3-aiohttp-socks recommends no packages. python3-aiohttp-socks suggests no packages.
Bug#931717: samba: CUPS printing fails with NT_STATUS_LOGON_FAILURE in 4.9.11+dfsg-1
On Mon, Oct 31 2022, Michael Tokarev wrote: >> to 4.9.11+dfsg-1. The error code given by CUPS is >> NT_STATUS_LOGON_FAILURE, although I did not change the smb:// URI so the >> credentials are known to be correct. Downgrading to 4.9.5+dfsg-5 fixes >> the problem. > > Is it still an issue with current samba (4.13 in bullseye and 4.16 in > bookworm and bullseye-backports)? Hi. I'm no longer on the same network/setup, so I cannot re-test this scenario at this moment.
Bug#1020731: Please package the non-color version
Package: fonts-noto-color-emoji Version: 2.038-1 Severity: wishlist Noto also includes a mostly black version called simply "Noto Emoji". https://fonts.google.com/noto/specimen/Noto+Emoji I find this version to be a better up-to-date replacement for fonts-symbola, as well as being more readable when emojis are interspersed with text. Would it be possible to have a package for it? Thanks! -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.11-custom (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
Bug#1016801: 22.2.0~rc1-1 breaks Blender/llvm on AMD gpus
Package: mesa-common-dev Version: 22.2.0~rc1-1 Followup-For: Bug #1016801 Upstream bug report: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6976 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.14-custom (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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 mesa-common-dev:amd64 depends on: ii libdrm-dev 2.4.112-3 ii libgl-dev 1.4.0-1 ii libglx-dev 1.4.0-1 ii libx11-dev 2:1.8.1-2 mesa-common-dev:amd64 recommends no packages. mesa-common-dev:amd64 suggests no packages.
Bug#1016801: 22.2.0~rc1-1 breaks Blender/llvm on AMD gpus
Package: libgl1-mesa-dri Version: 22.2.0~rc1-1 Severity: important Upgrading from 22.1.3-1 to 22.2.0~rc1-1 makes blender crash on startup inside libllvm, I guess due to llvmpipe. Thread 24 "blender:sh4" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff96eff640 (LWP 1240082)] 0x7fffb151aae6 in llvm::AMDGPUArgumentUsageInfo::print(llvm::raw_ostream&, llvm::Module const*) const () from /lib/x86_64-linux-gnu/libLLVM-14.so.1 (gdb) where #0 0x7fffb151aae6 in llvm::AMDGPUArgumentUsageInfo::print(llvm::raw_ostream&, llvm::Module const*) const () at /lib/x86_64-linux-gnu/libLLVM-14.so.1 #1 0x7fffa1ae5318 in () #2 0x7fffa19af4d0 in () #3 0x7fffaf9e6e24 in llvm::AnalysisResolver::addAnalysisImplsPair(void const*, llvm::Pass*) () at /lib/x86_64-linux-gnu/libLLVM-14.so.1 #4 0x7fffa19af488 in () #5 0x7fff96252c60 in () #6 0x002f in () #7 0x in () While keeping libllvm14 the same, I downgraded mesa back to 22.1.3 and the problem is gone. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.14-custom (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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 libgl1-mesa-dri:amd64 depends on: ii libc62.33-8 ii libdrm-amdgpu1 2.4.112-3 ii libdrm-nouveau2 2.4.112-3 ii libdrm-radeon1 2.4.112-3 ii libdrm2 2.4.112-3 ii libelf1 0.187-1 ii libexpat12.4.8-1 ii libgcc-s112.1.0-7 ii libglapi-mesa22.1.3-1 ii libllvm141:14.0.6-2 ii libsensors5 1:3.6.0-7 ii libstdc++6 12.1.0-7 ii libvulkan1 1.3.216.0-1 ii libxcb-dri3-01.15-1 ii libzstd1 1.5.2+dfsg-1 ii zlib1g 1:1.2.11.dfsg-4 libgl1-mesa-dri:amd64 recommends no packages. libgl1-mesa-dri:amd64 suggests no packages.
Bug#1000660: TKIVtk library missing
On Sat, Jul 16, 2022 at 11:39:55AM +0200, Tobias Frost wrote: On Fri, 26 Nov 2021 16:15:32 +0100 Yuri D'Elia wrote: libocct-visualization is supposed to include TKIVtk, but in reality it doesnt. Can you describe your use case a bit? Otherwise, this is on purpose. See #978017 for rationale. I didn't get any message from the BTS, so I only saw this by pure chance now. Anyway, I was trying to compile OCP from cadquery, which does require TKIVtk. I was able to exclude this part from by modifying the sources and get along, so you can say I was partially successful, but if a regular user was supposed to build the package it would have just failed. I agree with #978017 and I'm quite happy about the solution for the dependent packages (also using kicad myself, so the space savings are quite welcome), but this solution breaks part of OCCT. If I would have needed to have it then I would also have to build OCCT from sources, which is.. more than annoying. I'm not sure if Kurt has thought of an solution yet and also did not look into it if it is e.g feasible to put it into its own package. Splitting this into a separate package would make a lot of sense IMHO. Looks like both headers and libraries are separate, so it should be technically possible?
Bug#1010747: closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#1010747: fixed in pyacidobasic 2.11.1-2)
On Wed, May 18 2022, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the shiboken2 package: > > #1010747: Unusable with current python version > > It has been closed by Debian FTP Masters > (reply to Georges Khaznadar > ). This bug was against shiboken2, but was fixed pyacidobasic? I just verified nothing has been fixed in shiboken2 yet.
Bug#1010747: Unusable with current python version
Package: shiboken2 Version: 5.15.2-2+b2 Severity: grave shiboken2 cannot currently be used to build any package due to #1008849. I'm reporting this again as a grave bug, since while #1008849 might be intended to address the underlying issue, it's important to note that the _current_ package is essentially unusable ever since the python 3.10 transition started. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.3-custom (SMP w/16 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 shiboken2 depends on: ii libc6 2.33-7 ii libclang1-13 1:13.0.1-3+b2 ii libgcc-s1 12.1.0-1 ii libqt5core5a 5.15.2+dfsg-16+b1 ii libstdc++612.1.0-1 ii libxml2 2.9.14+dfsg-1 ii libxslt1.11.1.34-4 shiboken2 recommends no packages. shiboken2 suggests no packages.
Bug#1008849: shiboken2 - shiboken_helpers.cmake breaks with every Python transition
On Thu, Apr 21 2022, Yuri D'Elia wrote: > On Thu, Apr 21 2022, Nicholas D Steeves wrote: >> Unfortunately I'm out of time for the near future, but if you'd like I >> can upload an untested 5.15.3 package to experimental for you to test. > > I can definitely help testing this. Ping! ;)
Bug#1008849: shiboken2 - shiboken_helpers.cmake breaks with every Python transition
On Thu, Apr 21 2022, Nicholas D Steeves wrote: > Unfortunately I'm out of time for the near future, but if you'd like I > can upload an untested 5.15.3 package to experimental for you to test. I can definitely help testing this. > To be honest, I won't have time to make the cmake fix for what isn't > even one of my packages. Sorry. Maybe this is something that upstream would be willing to investigate? (yeah, I know that all the rage now is to have pyenvs within dockers so you have 20 copies of everything .. so I'm not holding my breath ;))
Bug#1008849: shiboken2 - Needs tighter dependency on python3
On Wed, Apr 13 2022, Nicholas D Steeves wrote: > I understand, and agree that the issue is real, and that a rebuild is > required. A binNMU is the most expedient solution ;-) Please read > "What are binNMUs?" at the link provided above... Yes, but I wouldn't call this "expedient", since ... > Kurt, this is the point I'm wondering about, because it would be better > if the transition tracker would alert us of outstanding issues rather > than waiting for someone to report breakage. If this isn't feasible, > could you document that fact in the source package? ... we're waiting for somebody to report the unavoidable breakage, since shiboken2 enforces this through a minor version check (we're not hoping it will work - it will just refuse to work). That would be a "grave" bug report from that perspective, not too dissimilar to any ABI breakage rendering downstream users _and_ packages unusable until fixed. > This might be by design. Kurt, do you know? There's also the question > of if pyside2/shiboken2 is even py3.10-ready (I haven't tested yet). Answering this for an hypothetical 3.11 transition, the answer would similarly be "likely doesn't matter - it's worth attempting a build and hope for the best, because the current version is broken". > As a general principle, I worry that this would either reduce > functionality and/or debugging, or introduce regression potential, so > this is not a change I'm willing to make as a team member and not > as one of the primary maintainers/uploaders of pyside2. I understand this. And the documentation around this define is lacking as well. Looking at the sources, it does seem to reduce the number of exported methods, so it is fair to say we might have users that expect the full API to be available and would break if used...
Bug#1008849: shiboken2 - Needs tighter dependency on python3
On Tue, Apr 12 2022, Nicholas D Steeves wrote: >> This also requires that shiboken2 should be currently rebuilt. >> > > Agreed. > >> Either the python3 dependency should be tightened, or FORCE_LIMITED_API >> should be used. > > These are not the only available options. Are you aware of binNMUs? > https://wiki.debian.org/binNMU I'm using it for development, and not being able to work if the minor version changes is a bigger problem than it sounds: I cannot rebuild third-party software which is using shiboken/pyside unless I completely rebuild pyside in parallel. I remember I already had this issue with the 3.9 transition. IMHO if shiboken2 is tied to the minor version, it should depend on the minor version as well so that the whole pyside/shiboken2 so that transitions and downstream dependencies will also be handled as part of the transitions? For example, the current situation is probably breaking packages which are currently build with shiboken. This makes shiboken2 completely useless if you have more than a one minor version of python installed (for example during transition periods). shiboken2 will work only for _one_ minor version. I actually don't use shiboken2 _directly_ myself, but is there any real drawback to build with FORCE_LIMITED_API ?
Bug#1008849: Needs tighter dependency on python3
Package: libshiboken2-py3-5.15 Version: 5.15.2-2+b2 Severity: important shiboken2 depends on a sepecific major+minor version of python. /usr/lib/x86_64-linux-gnu/cmake/Shiboken2-5.15.2/shiboken_helpers.cmake checks for this. As a result, attempting to build any package cmake package using shiboken2 currently fails: -- Found PythonInterp: /usr/bin/python3.10 (found suitable version "3.10.4", minimum required is "3") CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Shiboken2-5.15.2/shiboken_helpers.cmake:468 (message): The detected Python minor version is not compatible with the Python minor version which was used when Shiboken was built. Consider building shiboken with FORCE_LIMITED_API set to '1', so that only the Python major version matters. Built with: '3.9' Detected: '3.10' due to python3 now defaulting to python3.10. One can set PYTHON_EXECUTABLE to the proper version, but that implies that libshiboken2-py3-5.15 should depend on a specific python3 version, not just on any minor version. This also requires that shiboken2 should be currently rebuilt. Either the python3 dependency should be tightened, or FORCE_LIMITED_API should be used.
Bug#1006743: SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats
Source: python-systemd Followup-For: Bug #1006743 This issue currently breaks fail2ban for me, which is now defaulting to python3.10 (via the default python3 dependency).
Bug#1005278: Uninstallable on sid
Package: xserver-xorg-video-amdgpu Version: 21.0.0-2 Severity: normal I'm currently setting up a new system, but cannot install this driver as xorg 2:21.* is now providing xorg-video-abi-25. I'm not seeing any automatic transitions and/or new rebuilds.
Bug#1004091: Starts user services
On Mon, Jan 24 2022, Yves-Alexis Perez wrote: > I assume you're talking about systemd user services or something? I don't > think there's any specific code in lightdm about starting manually pulseaudio, > pipewire or anything, so I don't think there's a way to special cases some > thing. Yes, the issue is that lightdm starts automatically all systemd's user services (anything which is installed in the default.target in /usr/lib/systemd/user/) probably because it is creating a full user session?
Bug#1004091: Starts user services
Package: lightdm Version: 1.26.0-8 Severity: normal The user which is running lightdm starts all "user" services which are enabled by default, which might include pipewire (and I guess pulseaudio), gnupg.. synchthing. I find this behavior undersiderable. pipewire/pulseaudio could probably by used by the theme to provide audio in the session, but most other services only make sense for a real user. It seems like lightdm might befinit from a strictly defined list of services instead of starting a full-fledged user session that results in this behavior. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_USER 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) Versions of packages lightdm depends on: ii adduser3.118 ii dbus 1.12.20-3 ii debconf [debconf-2.0] 1.5.79 ii libaudit1 1:3.0.6-1+b1 ii libc6 2.33-3 ii libgcrypt201.9.4-5 ii libglib2.0-0 2.70.2-1 ii libpam-systemd [logind]250.3-1 ii libpam0g 1.4.0-11 ii libxcb11.14-3 ii libxdmcp6 1:1.1.2-3 ii lightdm-gtk-greeter [lightdm-greeter] 2.0.8-2+b1 ii lsb-base 11.1.0 Versions of packages lightdm recommends: pn xserver-xorg Versions of packages lightdm suggests: pn accountsservice pn upower ii xserver-xephyr 2:21.1.3-1 -- Configuration Files: /etc/lightdm/lightdm.conf changed: [LightDM] [Seat:*] greeter-hide-users=true [XDMCPServer] [VNCServer]
Bug#1004089: Error during install
Package: oomd Severity: normal Unpacking oomd (0.5.0-1+b1) ... dpkg: error processing archive /var/cache/apt/archives/oomd_0.5.0-1+b1_amd64.deb (--unpack): unable to open '/usr/lib/systemd/system/oomd.service.dpkg-new': No such file or directory Errors were encountered while processing: /var/cache/apt/archives/oomd_0.5.0-1+b1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_USER 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) Versions of packages oomd depends on: ii freecad-daily-dep [libc6] 1.0 ii init-system-helpers1.61 ii libc6 2.33-3 ii libgcc-s1 11.2.0-14 ii libjsoncpp25 1.9.5-2 ii libstdc++6 11.2.0-14 ii libsystemd0250.3-1 oomd recommends no packages. oomd suggests no packages.
Bug#1000832: Mention how to turn off GRUB_DISABLE_OS_PROBER warnings
Package: grub2-common Version: 2.06-2 Followup-For: Bug #1000832 IMHO the warning should be suppressed if the value is set (with either value). I had/have: GRUB_DISABLE_OS_PROBER=true in my /etc/default/grub and I still see the warning, despite the fact that I intentionally always disabled osprober.
Bug#1003824: Difference in current filename packaging conventions leads to downloads being ignored by apt
Package: debdelta Version: 0.67 Severity: normal When a package includes a "+" in the version, apt currently saves the file using "+", whereas debdelta saves the file using a % escape: "%2b". Because of this, debdelta can still download/create the deb archive, but apt will fail to recognize its presence in /var/cache/apt/archives, leading to a full download anyway. For reference, the current kicad package in unstable includes a +dfsg version designator. Expected filename: /var/cache/apt/archives/kicad_6.0.1+dfsg-1_amd64.deb file created by debdelta: /var/cache/apt/archives/kicad_6.0.1%2bdfsg-1_amd64.deb -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) 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) Versions of packages debdelta depends on: ii binutils 2.37.50.20220106-2 ii bzip2 1.0.8-5 ii freecad-daily-dep [libc6] 1.0 ii libbz2-1.0 1.0.8-5 ii libc6 2.33-2 ii python33.9.8-1 ii python3-requests 2.25.1+dfsg-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages debdelta recommends: ii bsdiff 4.3-23 pn gnupg2 ii gpg-agent [gnupg-agent] 2.2.27-3 ii python3-apt 2.3.0+b1 ii python3-debian 0.1.42 ii xdelta 1.1.3-10.4 ii xdelta3 3.0.11-dfsg-1+b1 ii xz-utils [lzma] 5.2.5-2 Versions of packages debdelta suggests: pn debdelta-doc -- Configuration Files: /etc/debdelta/sources.conf changed [not included]
Bug#1003722: jupyter-notebook: blank page in firefox
Package: jupyter-notebook Version: 6.4.5-3 Followup-For: Bug #1003722 This should be higher priority. I can confirm I get a JS error upon starting 'jupyter notebook' from the CLI using either Firefox: Uncaught ReferenceError: exports is not defined http://localhost:/static/tree/js/main.min.js?v=1165e50a1bd56de1d3cb2eb1f607c410d26e4dc418d1e016a4a3721ca5d697af4ef59e61b3be7082890269c3728083992695ad6156881a27d4b45d88802a4e8b:13852 Or chrome: marked.js:14 Uncaught ReferenceError: exports is not defined at marked.js:14:1 This happens when loading the default entry page http://localhost:/tree A relevant marked.js bug seems to be #1003601 which seems already fixed. However jupiter might be bundling a broken version? -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) 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) Versions of packages jupyter-notebook depends on: ii init-system-helpers 1.61 ii jupyter-core 4.9.1-1 ii python3 3.9.8-1 ii python3-notebook 6.4.5-3 jupyter-notebook recommends no packages. jupyter-notebook suggests no packages.
Bug#998058: intel-compute-runtime: FTBFS due to 2 failing tests
Package: intel-opencl-icd Followup-For: Bug #998058 Any news?
Bug#811294: ITP: tabview -- curses command-line CSV and list (tabular data) viewer
On Sun, Jan 02 2022, Louis-Philippe Véronneau wrote: > I see that you've done some work packaging this module in Debian already: > > https://salsa.debian.org/python-team/packages/tabview/ > > I'm currently packaging CleverCSV and tabview is an optional dependency. > I was wondering if you were planning on finishing the work for tabview. > > For what it's worth, I'd be happy to mentor you and sponsor this package > if you commit to maintaining it in Debian :) I've contributed to the tabview source itself, but I'm a bit struggling to keep up with the two packages I already maintain. I'd be glad if you could take over on the packaging
Bug#1001654: Can't load/execute several python scripts
Package: weechat-python Version: 3.3-1+b1 Severity: normal With the recent updates of python3-async-timeout/python3-aiohttp packages, I cannot load the weechat-matrix python plugin anymore (among others). Weechat either crashes with an illegal instruction during start, gets stuck forever while loading, and/or crashes with SIGSEGV while quitting. It became unusable. I initially reported the issue against python3-async-timeout, but it's likely these two modules are not directly responsible. There's for sure though some new ABI difference somewhere which is causing problems and leading to crashes. As a test, I rebuilt weechat 3.3 directly from upstream sources using the current version of python3.9-dev (3.9.9-1) and I can now run weechat-matrix without any other problem or change (all dependent python packages such as python3-matrix-nio unchanged). Is a forced rebuild possible in such a scenario? I didn't retry to rebuild the weechat package itself, I compiled from upstream sources. -- System Information: Versions of packages weechat-python depends on: ii libc6 2.33-1 ii libpython3.93.9.9-1 ii weechat-curses 3.3-1+b1 weechat-python recommends no packages. weechat-python suggests no packages.
Bug#1001155: Fails to update when service is masked
On Sat, Dec 11 2021, Ludovic Rousseau wrote: > If you mask both the socket and the service (or just the service) then > you do not have any problem. Exact? > If yes, may I close this bug report? Yes, thank you.
Bug#1001155: Fails to update when service is masked
On Sat, Dec 11 2021, Ludovic Rousseau wrote: > Hello Yuri, > > I got no answer to my questions. Sorry about that, didn't get anything. >> I note I get the same error if I use service(8) instead of >> invoke-rc.d(8) to >> restart pcscd: >> $ sudo service pcscd restart >> Failed to restart pcscd.service: Unit pcscd.service is masked. >> Have you modified invoke-rc.d configuration or something like that? No >> What do you get if you run "sudo invoke-rc.d pcscd restart"? # invoke-rc.d pcscd restart Failed to restart pcscd.service: Unit pcscd.socket is masked. invoke-rc.d: initscript pcscd, action "restart" failed. ○ pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) Docs: man:pcscd(8) but I just noticed reading now the error above I effectively masked the socket without masking the service :/ My bad. I had to install pcscd to use a smart-card reader once in a while, however I noticed that having pcscd running and/or starting anything using pkcs11 was taking _seconds_. I didn't want to remove the service, however I probably disabled socket by tabbing one-too-many times.
Bug#1001155: Fails to update when service is masked
Package: pcscd Version: 1.9.5-1 Severity: normal Errors were encountered while processing: pcscd E: Sub-process /usr/bin/dpkg returned an error code (1) Setting up pcscd (1.9.5-1) ... Failed to restart pcscd.service: Unit pcscd.socket is masked. invoke-rc.d: initscript pcscd, action "restart" failed. ○ pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) Docs: man:pcscd(8) I consider this a bug. During an upgrade, if the service isn't started, the upgrade script shouldn't fail trying to restart it. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) 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) Versions of packages pcscd depends on: ii init-system-helpers 1.60 ii libc6 2.33-0experimental2 ii libccid [pcsc-ifd-handler] 1.4.36-2 ii libpcsclite11.9.5-1 ii libsystemd0 249.7-1 ii libudev1249.7-1 ii lsb-base11.1.0 pcscd recommends no packages. Versions of packages pcscd suggests: ii systemd 249.7-1
Bug#1000664: closed by Piotr Ożarowski (fixed in 3.8.1-2)
On Tue, Nov 30 2021, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the python-aiohttp package: > > #1000664: python-aiohttp 3.7.4 depends on python-async-timeout < 4.0 By the way, it seems that weechat-python still crashes with a IOT signal even when both (or either) are upgraded. I suspect some ABI was broken, perhaps during build? I'll try to rebuild weechat-python locally and see if this resolves the issue while keeping aiohttp/async-timeout at the newest versions.
Bug#892664: dpkg: Please add decompression support for zstd
Package: dpkg Version: 1.20.9 Followup-For: Bug #892664 I'd also love to see zstd support in dpkg. I'm following several PPAs that offer daily builds and since ubuntu's migration to zstd-by-default I can no longer benefit from the pre-built packages. -- Package-specific info: System tainted due to merged-usr-via-aliased-dirs. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads) 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) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.33-0experimental2 ii liblzma5 5.2.5-2 ii libselinux1 3.3-1+b1 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.3.13 pn debsig-verify
Bug#1000664: Breaks weechat-python
Package: python3-async-timeout Version: 4.0.1-1 Severity: normal Version 4.0.1-1 indirectly breaks weechat-python, which crashes with a IOT signal. Downgrading to 3.3-1+b1 unbreaks it. I'm not sure whether there's an issue with async-timeout, in weechat-python, or some module used by weechat-python...
Bug#1000660: TKIVtk library missing
Package: libocct-visualization-7.5 Version: 7.5.1+dfsg1-2 Severity: normal libocct-visualization is supposed to include TKIVtk, but in reality it doesnt. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads) 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) Versions of packages libocct-visualization-7.5:amd64 depends on: ii libc62.32-4 ii libfontconfig1 2.13.1-4.2 ii libfreeimage33.18.0+ds2-6 ii libfreetype6 2.11.0+dfsg-1 ii libgcc-s111.2.0-12 ii libgl1 1.3.4-2+b1 ii libocct-foundation-7.5 7.5.1+dfsg1-2 ii libocct-modeling-algorithms-7.5 7.5.1+dfsg1-2 ii libocct-modeling-data-7.57.5.1+dfsg1-2 ii libstdc++6 11.2.0-12 ii libx11-6 2:1.7.2-2+b1 libocct-visualization-7.5:amd64 recommends no packages. libocct-visualization-7.5:amd64 suggests no packages.
Bug#1000403: linux-image-5.15.0-1-amd64: Bluetooth no longer works with linux 5.15 on an Intel AX201 laptop
On Wed, Nov 24 2021, Salvatore Bonaccorso wrote: > On Wed, Nov 24, 2021 at 03:36:27PM +0100, Yuri D'Elia wrote: >> Package: src:linux >> Version: 5.15.3-1 >> Followup-For: Bug #1000403 >> >> I'd like to report the same, still holding true on the current package >> with a dell 7410 with the AX201. >> >> The 5.16-rc1 has the same problem. > > Thanks for confirming. Would you be possible to bisect the issue to > the introdcing and report it upstream (not checked if there were > already reports about it) and then keep us in the loop? I've found this similar report so far which sounds plausible and includes a patch: https://bugzilla.kernel.org/show_bug.cgi?id=213829 however I didn't have time to investigate/rebuild at the moment. I reverted back to 5.14.
Bug#1000403: linux-image-5.15.0-1-amd64: Bluetooth no longer works with linux 5.15 on an Intel AX201 laptop
Package: src:linux Version: 5.15.3-1 Followup-For: Bug #1000403 I'd like to report the same, still holding true on the current package with a dell 7410 with the AX201. The 5.16-rc1 has the same problem.
Bug#1000170: Not compatible with experimental xserver-xorg-core 21.1.1
Package: xserver-xorg-video-dummy Version: 1:0.3.8-1+b1 Severity: normal xserver-xorg-video-dummy depends on xorg-video-abi-24, but the new release of xorg 21.1 on experimental provides xorg-video-abi-25
Bug#994833: OpenCL programs abort when intel-opencl-icd is installed
Is there any progress on the FTBS? libigc is now at 1.0.8744-2 which breaks 21.32.20609-1, making the icd uninstallable.
Bug#998108: firefox freezes shortly after start
Package: firefox Version: 94.0-1 Followup-For: Bug #998108 Same here, problems started with 93.0-1+b1, and are also present on FF 94. Firefox hangs at random times, doesn't quit properly preventing normal restart, doesn't recognize audio devices correctly. As others noted, FF hangs almost instantly for me when using anything involving media (audio/video playback). --safe-mode doesn't change anything. Disabling all flags for HW acceleration doesn't do anything either. Downgrading to 93.0-1 on the same system fixes the issue.
Bug#998242: cron-failure@.service delivery fails due to DynamicUser with exim
Package: systemd-cron Version: 1.5.17-3 Severity: important cron-failure@ is using DynamicUser=yes, however this causes a silent delivery failure when using exim4: systemd[1]: Starting cron-failure@cron-monthly.service... mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D: Permission denied mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D: Permission denied mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D: Permission denied systemd[1]: cron-failure@cron-monthly.service: Deactivated successfully. systemd[1]: Finished cron-failure@cron-monthly.service. Combined with #992649, this makes systemd-cron silently broken on a debian configuration with the default mta. -- Package-specific info: -- output of systemd-delta -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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) Versions of packages systemd-cron depends on: ii libc6 2.32-4 ii python3 3.9.2-3 ii systemd-sysv 249.5-1 Versions of packages systemd-cron recommends: ii exim4-daemon-light [mail-transport-agent] 4.95-2 systemd-cron suggests no packages.
Bug#996337: upgrade python-click-threading to 0.5.0
Package: python3-click-threading Version: 0.4.4-2 Followup-For: Bug #996337 The priority should probably be changed to important or above, since the functionality of this package is broken currently and breaks software which depends on it. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN 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) Versions of packages python3-click-threading depends on: ii python33.9.2-3 ii python3-click 8.0.2-1 python3-click-threading recommends no packages. python3-click-threading suggests no packages.
Bug#994186: libvkd3d1 uninstallable in experimental
Package: libvkd3d1 Severity: normal Version: 1.2-6 Vesion 1.2-6 is currently uninstallable on debian experimental due to the mesa-vulkan-drivers (< 21) dependency. I assume this should have been >=. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-trunk-amd64 (SMP w/8 CPU threads) 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) Versions of packages libvkd3d1 depends on: ii libc62.32-2 pn libvkd3d-shader1 ii libvulkan1 1.2.189.0-2 ii mesa-vulkan-drivers 21.2.1-2 libvkd3d1 recommends no packages. libvkd3d1 suggests no packages.
Bug#804235: carla packaging
Hi everyone, any progress on this? I noticed carla is now packaged in ubuntu (https://launchpad.net/ubuntu/+source/carla) and I wonder if we could reuse that effort to bring carla to debian too.
Bug#993664: Does not contain LLVMgold.so
Package: llvm-12-linker-tools Version: 1:12.0.1-7 Severity: important Got this error while linking: /usr/bin/ld: /usr/lib/llvm-12/bin/../lib/LLVMgold.so: error loading plugin: /usr/lib/llvm-12/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory The current package of llvm-12-linker-tools does not seem to include LLVMgold.so (only LLVMPolly/libLTO) Is this expected? -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-trunk-amd64 (SMP w/8 CPU threads) 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages llvm-12-linker-tools depends on: ii libc6 2.31-17 ii libgcc-s1 11.2.0-4 ii libllvm12 1:12.0.1-7 ii libstdc++6 11.2.0-4 llvm-12-linker-tools recommends no packages. llvm-12-linker-tools suggests no packages.
Bug#993038: Duplicate file libopen-orted-mpir.so
Package: libopenmpi-dev Version: 4.1.1-2 Severity: important dpkg: error processing archive /var/cache/apt/archives/libopenmpi3_4.1.1-2_amd64.deb (--install): trying to overwrite '/usr/lib/x86_64-linux-gnu/openmpi/lib/libopen-orted-mpir.so', which is also in package libopenmpi-dev:amd64 4.1.1-2
Bug#992443: Shouldn't depend on gvfs-backends
Package: siril Version: 0.99.10.1-1 Severity: normal In the latest package, siril depends on gvfs-backends, however I don't see why this is the case. Siril works fine without gvfs-backends installed. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-trunk-amd64 (SMP w/8 CPU threads) 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) Versions of packages siril depends on: ii libavcodec-extra58 [libavcodec58] 7:4.3.2-0+deb11u2 ii libavformat58 7:4.3.2-0+deb11u2 ii libavutil567:4.3.2-0+deb11u2 ii libc6 2.31-16 ii libcairo2 1.16.0-5 ii libcfitsio93.490-3 ii libconfig9 1.5-0.4 ii libexiv2-270.27.3-3 ii libffms2-4 2.23-5 ii libfftw3-single3 3.3.8-2 ii libgcc-s1 11.2.0-2 ii libgdk-pixbuf-2.0-02.42.6+dfsg-2 ii libglib2.0-0 2.68.3-2 ii libgomp1 11.2.0-2 ii libgsl25 2.7+dfsg-2 ii libgtk-3-0 3.24.30-1 ii libheif1 1.11.0-1 ii libjpeg62-turbo1:2.0.6-4 ii libjson-glib-1.0-0 1.6.2-1 ii libopencv-calib3d4.5 4.5.1+dfsg-5 ii libopencv-core4.5 4.5.1+dfsg-5 ii libopencv-imgproc4.5 4.5.1+dfsg-5 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-01.46.2-3 ii libpng16-161.6.37-3 ii libraw20 0.20.2-1 ii librsvg2-2 2.50.3+dfsg-1 ii libstdc++6 11.2.0-2 ii libswresample3 7:4.3.2-0+deb11u2 ii libswscale57:4.3.2-0+deb11u2 ii libtiff5 4.2.0-1 ii libwcs77.4+ds-2 ii siril-common 0.99.10.1-1 siril recommends no packages. Versions of packages siril suggests: ii gnuplot 5.4.1+dfsg1-1 ii gnuplot-qt [gnuplot] 5.4.1+dfsg1-1
Bug#986005: Newer upstream available: 5.56
Package: bluez Version: 5.55-3 Followup-For: Bug #986005 Upstream is now at 5.58
Bug#986995: linux-image-5.10.0-6-amd64: cdc_acm acm_port_activate fails
On Sun, Apr 25 2021, Yuri D'Elia wrote: > Relevant upstream bug reports: > > https://bugzilla.kernel.org/show_bug.cgi?id=212751 > https://bugzilla.kernel.org/show_bug.cgi?id=212725 FIY the proposed/accepted patch: https://lore.kernel.org/linux-usb/20210421074513.4327-1-oneu...@suse.com/raw fixes the issue.
Bug#986995: linux-image-5.10.0-6-amd64: cdc_acm acm_port_activate fails
Source: linux Version: 5.10.28-1 Followup-For: Bug #986995 I can confirm any device controlled by the acm driver has issues starting with 5.10.28. Sometimes it's possible to just replug the serial device to fix the issue, however for devices that reconnect after reset, there's no work-around. These include most MCU boards, such as arduino. Downgrading to 5.10.0-6 (5.10.26-1) fixes the issue. Relevant upstream bug reports: https://bugzilla.kernel.org/show_bug.cgi?id=212751 https://bugzilla.kernel.org/show_bug.cgi?id=212725
Bug#987003: Newer upstream 0.39
Package: libell-dev Version: 0.36-1 Severity: wishlist Upstream released ell 0.39 -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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) Versions of packages libell-dev:amd64 depends on: ii libell0 0.36-1 libell-dev:amd64 recommends no packages. libell-dev:amd64 suggests no packages.
Bug#986733: Support for pipewire
Package: pulseeffects Severity: wishlist Hi maintainers, Since pipewire is now available in unstable, would it be possible to support for using pulseeffects directly with a pipewire daemon? Would the current package/build already work with pipewire, or would pulseeffects require a different package entirely? Thanks! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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)
Bug#986294: New upstream 0.45 available
Package: rlwrap Version: 0.43-1+b2 Severity: wishlist Dear maintainer, upstream has released 0.45. It would be nice to update due to several bug fixes affecting the current package. Thanks! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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) Versions of packages rlwrap depends on: ii libc6 2.31-11 ii libreadline8 8.1-1 ii libtinfo6 6.2+20201114-2 ii perl 5.32.1-3 ii python3 3.9.2-2 rlwrap recommends no packages. rlwrap suggests no packages.
Bug#986005: Newer upstream available: 5.56
Package: bluez Version: 5.55-3 Severity: wishlist Dear maintainer, there seems to be a newer version of bluez 5.56 available. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, 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) Versions of packages bluez depends on: ii dbus 1.12.20-2 ii init-system-helpers 1.60 ii kmod 28-1 ii libasound2 1.2.4-1.1 ii libc62.31-10 ii libdbus-1-3 1.12.20-2 ii libdw1 0.183-3 ii libglib2.0-0 2.66.8-1 ii libreadline8 8.1-1 ii libudev1 247.3-3 ii lsb-base 11.1.0 ii udev 247.3-3 bluez recommends no packages. Versions of packages bluez suggests: pn pulseaudio-module-bluetooth -- Configuration Files: /etc/bluetooth/main.conf changed [not included]
Bug#985668: Undefined symbol in libfontmanager.so
Package: openjdk-17-jre-headless Version: 17~14-1 Severity: normal Just tried to run "josm" on openjdk-17, but I get the following error: 021-03-21 19:27:07.757 SEVERE: Handled by bug report queue: java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: undefined symbol: hb_font_destroy java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: undefined symbol: hb_font_destroy -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, 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) Versions of packages openjdk-17-jre-headless:amd64 depends on: ii ca-certificates-java 20190909 ii java-common 0.72 ii libasound21.2.4-1.1 ii libc6 2.31-10 ii libcups2 2.3.3op2-3 ii libfontconfig12.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s1 10.2.1-6 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-22.12~rc1-2 ii libnss3 2:3.61-1 ii libpcsclite1 1.9.1-1 ii libstdc++610.2.1-6 ii util-linux2.36.1-7 ii zlib1g1:1.2.11.dfsg-2 openjdk-17-jre-headless:amd64 recommends no packages. Versions of packages openjdk-17-jre-headless:amd64 suggests: ii fonts-dejavu-extra 2.37-2 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei | fonts-wqy-zenhei pn libnss-mdns
Bug#983794: Can't connect to newer cisco APs
Package: src:linux Version: 5.10.13-1 Severity: wishlist Recently our department upgraded some wireless Cisco equipment and as a result I'm no longer able to connect to the wifi network. The relevant part from the kernel shown during association is: RX AssocResp from 4c:a6:4d:54:09:4c (capab=0x1101 status=0 aid=2) HE AP is missing HE capability/operation Searching on LKML I've found already a fix for this issue released a few days ago: https://patchwork.kernel.org/project/linux-wireless/patch/20210223051926.2653301-1-yenlin...@chromium.org/ I wonder if it would be possible to backport this patch on the current kernel. Thanks! -- Package-specific info: ** Version: Linux version 5.10.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.13-1 (2021-02-06) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN 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) Versions of packages linux-image-5.10.0-3-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.139 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.10.0-3-amd64 recommends: pn apparmor pn firmware-linux-free Versions of packages linux-image-5.10.0-3-amd64 suggests: pn debian-kernel-handbook ii grub-efi-amd64 2.04-15 ii linux-doc-5.10 5.10.13-1 Versions of packages linux-image-5.10.0-3-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium ii firmware-intel-sound 20210208-3 pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20210208-3 pn firmware-libertas pn firmware-linux-nonfree ii firmware-misc-nonfree 20210208-3 pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20210208-3 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor
Bug#982688: wireless interface name unstable across reboots
On Mon, Feb 22 2021, Michael Biebl wrote: > iwd will re-initialize your wireless interface when it starts (I think > it unloads the firmware or something like that). At that point, both iwd > and udevd are running and race against each other and usually iwd wins > to claim the device. I was about to clarify the question regarding the devices above (my question was more specific to how devices events are synthesized when interface renaming is involved), but this tidbit actually clarifies the issue. Thing is, I've actually been using UseDefaultInterface=true in iwd.conf as well. So, in this case, does the race actually exist? So talking in general terms, and without requiring the admin to list specific interfaces, if iwd is done After=systemd-udev-settle.service with UseDefaultInterface=true, no double-renaming should happen for the interfaces directly detected during boot?
Bug#982688: wireless interface name unstable across reboots
On Sun, Feb 14 2021, Michael Biebl wrote: >> I'd like, ideally, to keep stable interface names. I'm not sure if this >> is intended, but so far after masking 80-iwd and removing "keep" from >> the NamePolicy it seems that udev is always able to rename the interface >> across reboots. >> >> It might entirely be because iwd started to operate on the original >> device name, but didn't have time to bring it up before the rename >> happens I guess. > > See also > https://iwd.wiki.kernel.org/interface_lifecycle#udev_interface_renaming I don't think there's anything specific to iwd here though. My main point is that the race can technically affect anything that needs to use the interface name during boot: - interface names might change - we're not using dbus - as a result we'd like to rely on "stable" names provided by the udev policy - but there's no way to wait for udev to settle without polling apparently? this somehow contradicts the usefulness of the stable interface names feature. As an example, when loading ipt/nft rulesets I'd like to set the rules *before* the interface is brought up. How to I sequence the service so that this happens after the rename but before the interface is brought up? Looks like I can incur in the same race as iwd.
Bug#982688: wireless interface name unstable across reboots
On Sat, Feb 13 2021, Michael Biebl wrote: >> If I want to keep exiting interface names I'd rather have to do this >> configuration explicitly. > > By masking 80-iwd.link, both udev and iwd race against each other. > Sometimes udev is fast enough to rename the interface, sometimes iwd is > quick enough and claims the interface and udev can't rename anymore, > because the interface is busy. > > TTBOMK this is not really fixable, which is why iwd started to ship 80- > iwd.link in the first place, so no renaming is going to happen. > > I'm not sure what udev can do about this, unfortunately. I see. This highlights a major problem with stable network names though. If there's a speed race against udev during boot, there's no guarantee any other service can use these "stable" names at any point until the events have fully settled. Is it possible to synthesize a target for network interface names, to be reached when all network interface names have settled somehow?
Bug#982688: wireless interface name unstable across reboots
On Sat, Feb 13 2021, Andreas Henriksson wrote: >> Is it possible to synthesize a target for network interface names, to be >> reached when all network interface names have settled somehow? > > As I see it the problem is that you currently have 2 options, but you > configured things to be in a broken middle state. > > Either you don't care about interface names and you disable the udev > rules for wireless interfaces (iwd default config), > or you say that naming is more important than speed to you so you mask > the configuration shipped by iwd and then make iwd wait for udev rules > to be applied. Sure. But then again it's exactly the question I have above: what do I wait "on" in order to ensure interface names have settled? > I've not seen any other practically workable options available right now > without having to do fundamental changes to existing policies in other > software - not udev or iwd (eg. linux, et.al.) I'd like, ideally, to keep stable interface names. I'm not sure if this is intended, but so far after masking 80-iwd and removing "keep" from the NamePolicy it seems that udev is always able to rename the interface across reboots. It might entirely be because iwd started to operate on the original device name, but didn't have time to bring it up before the rename happens I guess.
Bug#935950: fonts-symbola: Much newer version is available at upstream
It seems that the current version is 13.00, released March 2020, at the new URL: https://dn-works.com/ufas/
Bug#979496: Can't connect to wpa2-enterprise 802.1x since 5.10
On Thu, Jan 07 2021, Salvatore Bonaccorso wrote: > Is this potentially the same as > https://lore.kernel.org/keyrings/67250277-7903-2005-b94b-193bce0a3...@markus-regensburg.de/ > ? Excellent catch, same scenario (and even hardware it seems)! I created a new report earlier today: https://bugzilla.kernel.org/show_bug.cgi?id=211073 since I couldn't find any instance of the same in bugzilla.
Bug#979499: Should only Recommend: javascript-common
Package: libjs-popper.js Version: 1.16.1+ds-2 Severity: minor libjs-popper.js shouldn't depend on javascript-common directly, unless a web server is actually required (which isn't). The dependency should be changed to a recommends or less. Thanks.
Bug#979496: Can't connect to wpa2-enterprise 802.1x since 5.10
Package: src:linux Version: 5.10.4-1 Severity: normal Starting with 5.10, kernel dies when attempting to connect to a 802.1x network, showing the following trace: [ 232.661980] Oops: [#5] SMP NOPTI [ 232.661987] CPU: 5 PID: 2131 Comm: iwd Tainted: G DOE 5.10.0-1-amd64 #1 Debian 5.10.4-1 [ 232.661991] Hardware name: LENOVO 20LES1BM00/20LES1BM00, BIOS N25ET55W (1.41 ) 10/20/2020 [ 232.662002] RIP: 0010:public_key_verify_signature+0x13d/0x3b0 [ 232.662009] Code: 48 8b 40 d0 44 89 c2 4c 89 f6 4c 89 ff e8 7b d4 7f 00 85 c0 0f 85 6f 01 00 00 48 8b 75 30 48 c7 c7 12 23 d0 b5 b9 04 00 00 00 a6 0f 97 c0 1c 00 84 c0 75 0b 8b 45 50 85 c0 0f 85 d1 01 00 00 [ 232.662014] RSP: 0018:af0340fbfd58 EFLAGS: 00010246 [ 232.662019] RAX: RBX: 9c4fc5c011c0 RCX: 0004 [ 232.662023] RDX: 9c4fd987bb00 RSI: RDI: b5d02312 [ 232.662027] RBP: af0340fbfe88 R08: 9c4fc3ae6c40 R09: 0008 [ 232.662030] R10: R11: 000a R12: 010e [ 232.662033] R13: 9c4fd987b900 R14: 9c4fd08f1000 R15: 9c4fc5c012c0 [ 232.662039] FS: 7f7d8c23c640() GS:9c510754() knlGS: [ 232.662043] CS: 0010 DS: ES: CR0: 80050033 [ 232.662046] CR2: CR3: 000103b54004 CR4: 003706e0 [ 232.662050] Call Trace: [ 232.662062] ? kfree+0xc3/0x3f0 [ 232.662068] ? software_key_query+0x94/0x180 [ 232.662078] ? keyctl_pkey_params_get+0xe9/0x120 [ 232.662085] asymmetric_key_verify_signature+0x5e/0x80 [ 232.662093] keyctl_pkey_verify+0xaf/0x100 [ 232.662103] do_syscall_64+0x33/0x80 [ 232.662110] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 232.662117] RIP: 0033:0x7f7d8c16e9b9 [ 232.662122] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48 [ 232.662126] RSP: 002b:7ffc26baab28 EFLAGS: 0246 ORIG_RAX: 00fa [ 232.662132] RAX: ffda RBX: 7ffc26baabb0 RCX: 7f7d8c16e9b9 [ 232.662135] RDX: 5629ed907690 RSI: 7ffc26baab30 RDI: 001c [ 232.662139] RBP: 5629ed907690 R08: 5629ed909e1d R09: 002023423321 [ 232.662142] R10: 7ffc26baabb0 R11: 0246 R12: 5629ed909e1d [ 232.662145] R13: 5629ec956b30 R14: 5629ed909dd4 R15: 7ffc26baabb0 [ 232.662152] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device acpi_call(OE) cdc_ether usbnet snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic r8152 mii bnep typec_displayport btusb btrtl btbcm btintel ccm bluetooth algif_aead cbc uvcvideo des_generic libdes ecb videobuf2_vmalloc jitterentropy_rng videobuf2_memops videobuf2_v4l2 algif_skcipher drbg videobuf2_common ansi_cprng videodev ecdh_generic mc sg ecc cmac sha512_ssse3 sha512_generic md4 algif_hash intel_pmc_core_pltdrv af_alg intel_pmc_core snd_soc_sklsnd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi ip6table_nat snd_hda_intel snd_intel_dspcfg soundwire_intel x86_pkg_temp_thermal soundwire_generic_allocation intel_powerclamp binfmt_misc intel_rapl_msr coretemp snd_soc_core ip6table_filter kvm_intel iwlmvm snd_compress ip6_tables kvm soundwire_cadence mac80211 irqbypass libarc4 nls_ascii xt_REDIRECT snd_hda_codec nls_cp437 rapl intel_cstate [ 232.662278] snd_hda_core vfat iptable_nat snd_hwdep iwlwifi i915 intel_uncore fat nf_nat joydev evdev iTCO_wdt ipt_REJECT soundwire_bus intel_pmc_bxt snd_pcm pcspkr nf_reject_ipv4serio_raw iTCO_vendor_support efi_pstore sparse_keymap xt_pkttype tpm_crb intel_wmi_thunderbolt wmi_bmof cfg80211 watchdog snd_timer xt_tcpudp drm_kms_helper hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_als intel_xhci_usb_role_switch hid_sensor_trigger processor_thermal_device ucsi_acpi mei_me cec tpm_tis hid_sensor_iio_common xt_state intel_rapl_common tpm_tis_core industrialio_triggered_buffer kfifo_buf xt_conntrack industrialio mei roles i2c_algo_bit intel_soc_dts_iosf intel_pch_thermal tpm typec_ucsi thinkpad_acpi typec rng_core nvram ledtrig_audio snd soundcore rfkill ac int3403_thermal int3400_thermal acpi_pad int3402_thermal int340x_thermal_zone acpi_thermal_rel button iptable_filter sch_cake i2c_dev drm nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c tcp_bbr fuse configfs efivarfs ip_tables [ 232.662405] x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_plantronics wacom usbhid sd_mod dm_crypt dm_mod hid_sensor_custom hid_sensor_hub hid_generic intel_ishtp_hid hid uas usb_storage scsi_mod crc32_pclmul crc32c_intel ghash_clmulni_intel xhci_pci nvme xhci_hcd aesni_intel libaes crypto_simd cryptd usbcore glue_helper e1000e thunderbolt nvme_core psmouse intel_ish_ipc
Bug#978141: New upstream 12/2020 edition
Package: sauerbraten Version: 0.0.20140302-2 Severity: wishlist Dear maintainer, there seems to be a newer version of sauerbraten available: the "2020 edition". It would be nice to have an update! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/8 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sauerbraten depends on: ii cube2 0.0.20130404+dfsg-1 sauerbraten recommends no packages. sauerbraten suggests no packages.
Bug#976661: Missing symlinks/wrong search path for modules
Package: freecad Version: 0.19~pre1+git20201123.8d73c8f0+dfsg1-1 Severity: important freecad is searching modules in /usr/lib/freecad/Mod, however freecad-common has them in /usr/share/freecad. Startup fails with: Log: Init: starting App::FreeCADInit.py Wrn: No modules found in /usr/lib/freecad/Mod It seems that /usr/lib/freecad already includes some symlinks (for "Gui"), but others are missing. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) 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 not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages freecad depends on: ii freecad-python3 0.19~pre1+git20201123.8d73c8f0+dfsg1-1 Versions of packages freecad recommends: ii calculix-ccx 2.17-1 ii graphviz 2.42.2-4+b2 Versions of packages freecad suggests: pn povray
Bug#975322: broken mlterm 3.9 definitions
On Sat, Nov 21 2020, Sven Joachim wrote: >> If the mlterm package changed that ut-default setting, then providing your >> own termcap settings may have reset the behavior to match the compiled-in >> NON-ut default. > > That seems to have hit the mark. Indeed, if ":ut" is added to Yuri's > termcap example, mlterm works correctly again. > > Yuri, would you like to bring this to the attention of the mlterm > developers? So I think there's another problem here. The reason I had to change ~/.mlterm/termcap was to fix the behavior of F[1-4] keys by making mlterm send a different sequence. mlterm sends ^[OP for F1, but all mlterm terminfo definitions seem to expect \[[11~ ls mlterm* | xargs -l infocmp | grep kf1= kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~, Either all these definitions are broken, or I need some enlightenment? If I remove my customization, bce works as it should, but F[1-4] are broken. Sure I can also add :ut to my ~/.mlterm/termcap, then mlterm sends what the terminfo says, but it doesn't look like I'm fixing the right thing here.
Bug#975322: broken mlterm 3.9 definitions
On Sat, Nov 21 2020, Sven Joachim wrote: >>> mlterm-256color:\ >>> k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~ >>> >>> Removing this (so that mlterm sends it's usual \EOP/*) fixes the >>> background-color rendering. >>> >>> I'm puzzled as of why this override would influence this at all? >> >> It sounds like a problem in mlterm, e.g., in the way it stores the "ut" >> (terminfo "bce") capability. It doesn't appear to read the ncurses >> terminal database, which (since bce worked when I tested it) says it >> does back-color-erase, while the compiled-in termcap says it does not. >> >> If the mlterm package changed that ut-default setting, then providing your >> own termcap settings may have reset the behavior to match the compiled-in >> NON-ut default. > > That seems to have hit the mark. Indeed, if ":ut" is added to Yuri's > termcap example, mlterm works correctly again. > > Yuri, would you like to bring this to the attention of the mlterm > developers? Absolutely. Thanks for helping out on this!
Bug#975322: broken mlterm 3.9 definitions
On Fri, Nov 20 2020, Sven Joachim wrote: > Which version of mlterm do you use? I'm also using mlterm 3.9.0-1. So after some scrambling, I have a custom ~/.mlterm/termcap config to override the sequence sent by F[1-4]: mlterm-256color:\ k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~ Removing this (so that mlterm sends it's usual \EOP/*) fixes the background-color rendering. I'm puzzled as of why this override would influence this at all?
Bug#975322: broken mlterm 3.9 definitions
Package: ncurses-term Version: 6.2+20201114-1 Severity: normal With the latest version, it seems that the mlterm/mlterm3/mlterm-256color definitions are somewhat broken. The background color set by term programs (say, aptitude) is not set correctly anymore. Switching to ncurses-term=6.2+20200918-1 fixes mlterm at least. -- System Information: Versions of packages ncurses-term depends on: ii ncurses-base 6.2+20201114-1
Bug#971032: New upstream dev release available
Package: wine-development Version: 5.5-5 Severity: wishlist The current development package is a bit lagging against upstream. Upstream's wine-development is at 5.18.
Bug#969385: New upstream 1.74
Package: libboost-dev Version: 1.71.0.3 Severity: wishlist It would be nice to have a package for an updated version of boost. I've ran into a couple of packages that expect features from 1.73 already. At the time of writing, upstream is at 1.74
Bug#964437: Fails to install
On Tue, Jul 07 2020, Rémi Vanicat wrote: > Could you show me the line 30 of the file > > /usr/share/emacs/site-lisp/elpa-src/magit-2.99.0/magit-tag.el (require 'magit) > Also please check if there is another version of magit installed in > /root/.emacs.d or in /usr/local/share/emacs/site-lisp/ or even in > /usr/share/emacs/site-lisp/ ? No, but I found the issue after looking deeper :/ It's actually due to the elpa-magit-annex package which does (require 'magit-popup) but still only depends on elpa-magit.
Bug#964437: Fails to install
Package: elpa-magit Version: 2.99.0.git0957.ge8c7bd03-1 Severity: important The newer git version removes the dependency on elpa-magit-popup which seems to be required: ... In toplevel form: magit-tag.el:30:1:Error: Cannot open load file: No such file or directory, magit-popup In toplevel form: magit-worktree.el:30:1:Error: Cannot open load file: No such file or directory, magit-popup ERROR: install script from elpa-magit package failed dpkg: error processing package elpa-magit (--configure): installed elpa-magit package post-installation script subprocess returned error exit status Errors were encountered while processing: elpa-magit
Bug#964257: Correctly handle apostophes in English dictionaries
Package: hunspell-en-us Version: 1:2019.10.06-1 Severity: minor For an embarassingly long time I was wondering why aspell/ispell/hunspell wouldn't handle correctly anything basic with apostrophes, such as "isn't". Turns out I read the explaination, by random chance, here: https://www.emacswiki.org/emacs/InteractiveSpell#toc16 It seems that /usr/share/hunspell/en_US.aff already has the ICONV rules, but doesn't include "'’" in WORDCHARS. I can confirm that those to WORDCHARS makes hunspell actually behave as intended. Shouldn't this be the default for all english dictionaries? (note that while the URL mentions emacs, this does affect the basic hunspell cli as well)
Bug#964078: Error during setup, bad file location
Package: meshio-tools Version: 4.0.16-1 Severity: normal Caught during install: Setting up meshio-tools (4.0.16-1) ... Traceback (most recent call last): File "/usr/bin/pypy3compile", line 186, in main() File "/usr/bin/pypy3compile", line 178, in main py_compile.compile(module, doraise=True) File "/usr/lib/pypy3/lib-python/3/py_compile.py", line 122, in compile source_bytes = loader.get_data(file) File "/frozen importlib._bootstrap_external", line 845, in get_data FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/plugins/paraview-meshio-plugin.py' Also, the symlink is indeed installed into /usr/bin/plugins, which is _probably_ wrong. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/8 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) Versions of packages meshio-tools depends on: ii python3 3.8.2-3 ii python3-meshio 4.0.16-1 meshio-tools recommends no packages. meshio-tools suggests no packages.
Bug#962504: New upstream, package improvements
Package: screenkey Severity: wishlist A new upstream version of screenkey (1.1) is officially available, which should fix bug #962118 as well. Additionally, the package dependencies are incomplete. screenkey should also depend explicitly on required GI interface gir1.2-gtk-3.0. I would also recommend the following packages: fonts-font-awesome gir1.2-appindicator3-0.1 slop I'm thorn whether slop and fonts-font-awesome should be a recommended or be a straight dependency, since the GUI selection behavior depends on it. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-rt-amd64 (SMP w/8 CPU cores; 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=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages screenkey depends on: ii libx11-6 2:1.6.9-2+b1 ii python33.8.2-3 ii python3-cairo 1.16.2-3 ii python3-gi 3.36.0-3 screenkey recommends no packages. screenkey suggests no packages.
Bug#960420: Needs versioned dependency on slop
Package: maim Version: 5.5.3-1 Severity: important I didn't realize maim depended on slop through a dso (I assumed it simply called the binary). slop was updated to 7.5, which broke maim as a result: maim: error while loading shared libraries: libslopy.so.7.4: cannot open shared object file: No such file or directory maim definitely needs a versioned dependency on slop in this case to avoid breaking.
Bug#959201: jami-daemon: dring does not start due to a symbol lookup error
Package: libyaml-cpp0.6 Version: 0.6.3-4 Followup-For: Bug #959201 This ABI breakage also affects blender (indirecly via opencolorio). Version 0.6.3-4 does fix the symbol lookup error, however blender will incur a crash soon after with a segmentation fault. Downgrading libyaml-cpp0.6 to 0.6.2-4 fixes the issue, suggesting that the ABI is still broken somewhere.
Bug#958905: Multiple versions of libocct cannot be installed
Package: opencascade Version: 7.3.3+dfsg1-2 Severity: minor My understanding is that when choosing to include the version in the package name of a library, is that so that we can allow for multiple versions of the library to coexist on the same system. However all libocct-* 7.4 libs break 7.3, which defeats the point of major-minor version in the package name itself. Would it be possible to avoid the Breaks or there's some underlying issue?
Bug#958465: Downgrade dependency on timesyncd | time-daemon to Recommends
Package: systemd Version: 245.5-1 Severity: minor A time-keeping daemon is not always needed (guest OSes being the primary example). I know systemd-timesyncd was built-in up to 245.4-1, but it would be nice to drop the hard dependency nonetheless so that I can avoid masking the service entirely. Thanks!
Bug#939748: Pango 1.44.x drops support for rendering BDF (X11 bitmap) and Type 1 fonts
Package: libpango-1.0-0 Version: 1.44.7-3 Followup-For: Bug #939748 I was wondering why "dunst", suddenly, stopped displaying characters, even though dunst itself didn't change. Looking at the upgrade log, I catch pango, and now I see this. I generally don't use bitmap fonts, but they have their uses. At low resolutions they can't be beaten. Terminus is excellent. I know debian has little to do with this decision, so I'm only here to join in stating that I'm too deeply sorry for this. I'm also not happy at all behind most of the UI and technical decisions behind GTK3. I say that as a big, big lover of GTK2. I'm _even_ using the GTK plaftorm style in QT.
Bug#954420: Python deprecation warning
Package: debdelta
Version: 0.65
Severity: minor
There's a new deprecation warning that popped up recently:
/usr/bin/debdelta-upgrade:5386: DeprecationWarning: isAlive() is deprecated,
use is_alive() instead
while patching_thread.isAlive() or ('a' in DEB_POLICY and no_delta):
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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)
Versions of packages debdelta depends on:
ii binutils 2.34-5
ii bzip2 1.0.8-2
ii libbz2-1.01.0.8-2
ii libc6 2.30-2
ii python3 3.8.2-1
ii python3-requests 2.22.0-2
ii zlib1g1:1.2.11.dfsg-2
Versions of packages debdelta recommends:
ii bsdiff 4.3-21+b1
pn gnupg2
ii gpg-agent [gnupg-agent] 2.2.19-3
ii python3-apt 1.9.10
ii python3-debian 0.1.36
ii xdelta 1.1.3-9.3
ii xdelta3 3.0.11-dfsg-1+b1
ii xz-utils [lzma] 5.2.4-1+b1
Versions of packages debdelta suggests:
pn debdelta-doc
-- Configuration Files:
/etc/debdelta/sources.conf changed [not included]
Bug#498241: no ?action(forbid-version)
Package: aptitude Version: 0.8.12-3 Followup-For: Bug #498241 I encountered this problem today. I'm trying to match all packages which will upgraded on the next run, but turns out to be non-trivial. '~U' includes packages with holds and forbids (and according to the description: "packages that can be upgraded" would be fine). '~aupgrade' still includes forbids though. I understand "forbid" is not an action, but a flag in the package state. We have a search term for the 'auto' flag (~M), why not introduce a search term that can be used to match packages with it?
Bug#950779: Incorrect dependency on "libxcb-xfixes0-dev."
Package: libxcb-xinput-dev Version: 1.13.1-4 Severity: important The new version cannot be installed as it depends on "libxcb-xfixes0-dev." (typo with a trailing dot).
Bug#950614: libqt5core5a conflicts with libqtcore4
On Tue, Feb 04 2020, Nicholas D Steeves wrote: >> This makes libqt5core5a uninstallable for me. I have several programs >> which still depend on libqtcore4. I also still develop on qt4. > > FYI https://lists.debian.org/debian-devel-announce/2017/08/msg6.html > and https://wiki.debian.org/Qt4Removal I'm well aware I'll have to maintain it myself at some point.
Bug#950614: libqt5core5a conflicts with libqtcore4
Package: libqt5core5a Version: 5.12.5+dfsg-8 Severity: normal The latest version of libqt5core5a breaks libqtcore4 (< 4:4.8.7+dfsg-20~), which is any libqtcore4 version currently available in unstable. Is this intentional? This makes libqt5core5a uninstallable for me. I have several programs which still depend on libqtcore4. I also still develop on qt4.
Bug#945490: gs always fails with "Permission denied"
Package: pstoedit Version: 3.74-1+b1 Severity: important Tried pstoedit for the first time today, but I couldn't get it to work. After a few tests, I noticed it would fail to run even when converting a dummy pdf (saved with inkscape) to a ps. The following command: $ pstoedit lay1.pdf lay1.ps Results in === pstoedit: version 3.74 / DLL interface 108 (built: Aug 24 2019 - release build - g++ 9.2.1 20190821 - 64-bit) : Copyright (C) 1993 - 2019 Wolfgang Glunz No explicit output format specified - using plot-ps as derived from suffix of output file *** WARNING - you have selected SAFER, indicating you want Ghostscript to execute in a safer environment, but at the same time have selected DELAYBIND. Unless you use this option with care (and specifically, remember to call .bindnow) it is possible that malicious code may be able to evade the limited security offered by the SAFER option. *** WARNING - you have selected SAFER, indicating you want Ghostscript to execute in a safer environment, but at the same time have selected WRITESYSTEMDICT. Unless you use this option with care and specifically, remember to execute code like: "systemdict readonly pop" it is possible that malicious code may be able to evade the limited security offered by the SAFER option. Error: /invalidfileaccess in --run-- Operand stack: (lay1.pdf) (r) Execution stack: %interp_exit .runexec2 --nostringval-- run --nostringval-- 2 %stopped_push --nostringval-- run run false 1 %stopped_push 1989 1 3 %oparray_pop 1988 1 3 %oparray_pop 1976 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- run --nostringval-- 2 %stopped_push --nostringval-- 1989 1 3 %oparray_pop run Dictionary stack: --dict:730/1684(ro)(G)-- --dict:0/20(G)-- --dict:303/450(L)-- Current allocation mode is local Last OS error: Permission denied Current file position is 89272 GPL Ghostscript 9.50: Unrecoverable error, exit code 1 PostScript/PDF Interpreter finished. Return status 256 executed command : gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dNOEPS "/tmp/psinD1zLI9" The interpreter seems to have failed, cannot proceed ! === "lay1.ps" is created as zero file. It seems that gs doesn't have enough permissions to read the input (?). I cannot it to run even using stdin/out only. But if I explicitly disable gs "SAFER" with $ pstoedit -psarg '-dNOSAFER' in out then I can convert documents as expected. I'm filing this as important, since I don't think explicitly disabling the gs sandbox is the right fix. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-rt-amd64 (SMP w/8 CPU cores; PREEMPT) 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) Versions of packages pstoedit depends on: ii ghostscript 9.50~dfsg-2 ii libc62.29-3 ii libpstoedit0c2a 3.74-1+b1 ii libstdc++6 9.2.1-19 pstoedit recommends no packages. Versions of packages pstoedit suggests: pn xfig | ivtools-bin | tgif | transfig
