Bug#1069181: sd: typo in description: defualts -> defaults
Package: sd Version: 0.80.really.0.7.6-1+deb12u1 Severity: minor Tags: patch Please replace "defualts" in the package description with "defaults". Thank you & greetings, * -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sd depends on: ii libc6 2.36-9+deb12u4 ii libgcc-s1 12.2.0-14 sd recommends no packages. sd suggests no packages.
Bug#1068582: python3-mercantile: dpkg fails upgrading from mercantile 1.1.5
Package: python3-mercantile
Version: 1.2.1-1
Severity: normal
The new "python3-mercantile" package contains files conflicting with the
old "mercantile" package but the package metadata doesn't specify this,
so upgrading from the old package fails:
Unpacking python3-mercantile (1.2.1-1) over (1.1.5-1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-fL3mNH/44-python3-mercantile_1.2.1-1_all.deb (--unpack):
trying to overwrite '/usr/bin/mercantile', which is also in package
mercantile 1.1.5-1
See
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces.
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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-mercantile depends on:
ii python33.11.6-1
ii python3-attr 23.2.0-2
ii python3-certifi2023.11.17-1
ii python3-chardet5.2.0+dfsg-1
ii python3-click 8.1.7-1
ii python3-coverage 7.2.7+dfsg1-1+b1
ii python3-docopt 0.6.2-6
ii python3-hypothesis 6.98.4-1
ii python3-idna 3.6-2
ii python3-iniconfig 1.1.1-2
ii python3-packaging 23.2-1
ii python3-pluggy 1.4.0-1
ii python3-py 1.11.0-2
ii python3-pydocstyle 6.3.0-1.1
ii python3-pyparsing 3.1.1-1
ii python3-requests 2.31.0+dfsg-1
ii python3-snowballstemmer2.2.0-4
ii python3-sortedcontainers 2.4.0-2
ii python3-toml 0.10.2-1
ii python3-typing-extensions 4.10.0-1
ii python3-urllib31.26.18-2
ii python3-zipp 1.0.0-6
python3-mercantile recommends no packages.
python3-mercantile suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1068463: procyon: Untrusted code execution via cwd in classpath
Package: procyon-decompiler Version: 0.6.0-1 Tags: security Severity: grave In the default configuration, procyon prepends current working directory to the java classpath. This is done in the shell script /usr/bin/procyon, which sets, apparently by mistake, CLASSPATH=$CLASSPATH:..., where $CLASSPATH is a usually empty environment variable - and empty string in this context is interpreted as a current working directory by java. This is potentially dangerous, especially with a decompiler, which is supposed to deal with untrusted code. In a possible bad scenario, a user (without CLASSPATH environment variable, which is the debian default) might try to decompile an untrusted malicious jar: wget ".../bad.jar" jar xf bad.jar procyon ... Regardless of what command line arguments are given to procyon, if the extracted jar contained e.g. the jcommander class, then it will get executed.
Bug#1068290: python3-fastkml: ImportError since python3-pygeoif 1.4.0
Hi,
On Wed, Apr 03, 2024 at 12:29:36AM +0100, Tomas Janousek wrote:
I believe this is because both shapely and pygeoif deprecated
asShape/as_shape respectively. The function is now called just "shape"
in both.
[…]
I think it might be okay to just patch fastkml/geometry.py to
from shapely.geometry import shape as asShape
…
from pygeoif.geometry import shape as asShape
but it needs to be tested more thoroughly.
Yep, almost that. The following seems to work well (makes my CI pass):
https://github.com/liskin/liscopridge/commit/c44c3e6054af5a12bdf24d5687b6478d39480194#diff-e8ae9ced1dd6c13b4566c8a4a669116272e05115ce64aa743658523f4455ad5fR11
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1068290: python3-fastkml: ImportError since python3-pygeoif 1.4.0
Package: python3-fastkml
Version: 0.12-3
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: t...@nomi.cz
Dear Maintainer,
Since python3-pygeoif 1.4.0-1 appeared in Debian testing, fastkml cannot
be imported at all:
In [1]: import fastkml
---
ImportError Traceback (most recent call last)
File /usr/lib/python3/dist-packages/fastkml/geometry.py:39
38 from shapely.geometry import Polygon
---> 39 from shapely.geometry import asShape
40 from shapely.geometry.polygon import LinearRing
ImportError: cannot import name 'asShape' from 'shapely.geometry'
(/usr/lib/python3/dist-packages/shapely/geometry/__init__.py)
During handling of the above exception, another exception occurred:
ImportError Traceback (most recent call last)
Cell In[1], line 1
> 1 import fastkml
File /usr/lib/python3/dist-packages/fastkml/__init__.py:34
32 from .atom import Contributor
33 from .atom import Link
---> 34 from .kml import KML
35 from .kml import Data
36 from .kml import Document
File /usr/lib/python3/dist-packages/fastkml/kml.py:46
44 import fastkml.atom as atom
45 import fastkml.config as config
---> 46 import fastkml.gx as gx
48 from .base import _BaseObject
49 from .base import _XMLObject
File /usr/lib/python3/dist-packages/fastkml/gx.py:92
89 from pygeoif.geometry import GeometryCollection
91 from .config import GXNS as NS
---> 92 from .geometry import Geometry
94 logger = logging.getLogger(__name__)
97 class GxGeometry(Geometry):
File /usr/lib/python3/dist-packages/fastkml/geometry.py:46
44 from pygeoif.geometry import MultiPoint, MultiLineString,
MultiPolygon
45 from pygeoif.geometry import LinearRing
---> 46 from pygeoif.geometry import as_shape as asShape
48 import logging
50 from pygeoif.geometry import GeometryCollection
ImportError: cannot import name 'as_shape' from 'pygeoif.geometry'
(/usr/lib/python3/dist-packages/pygeoif/geometry.py)
I believe this is because both shapely and pygeoif deprecated
asShape/as_shape respectively. The function is now called just "shape"
in both.
Unfortunately, fastkml doesn't have a newer release compatible with
recent pygeoif (or shapely) versions. There's only been a steady stream
of 1.0.alphas, most of which are broken in various ways (I have a
project that depends on fastkml so its CI has been notifying me of ways
my project breaks with those alphas and I tried to work around these for
a while but recently gave up and just pinned fastkml to 0.12).
I think it might be okay to just patch fastkml/geometry.py to
from shapely.geometry import shape as asShape
…
from pygeoif.geometry import shape as asShape
but it needs to be tested more thoroughly.
Also, fastkml 0.12 explicitly depends on pygeoif < 1.0, for good reason
apparently, so it's a bit unfortunate that this dependency is relaxed in
the Debian package. :-(
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages python3-fastkml depends on:
ii python33.11.6-1
ii python3-dateutil 2.9.0-2
ii python3-pkg-resources 68.1.2-2
ii python3-pygeoif1.4.0-1
python3-fastkml recommends no packages.
python3-fastkml suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1067811: mirror submission for mirror.leitecastro.com
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.leitecastro.com Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Tomas Leite Castro Country: PT Portugal Location: Lisbon Trace Url: http://mirror.leitecastro.com/debian/project/trace/ Trace Url: http://mirror.leitecastro.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.leitecastro.com/debian/project/trace/mirror.leitecastro.com
Bug#1066029: secnet: please correct long description that says that hippotat is not packaged
Package: secnet Version: 0.6.7 Severity: minor The secnet long description reads: > secnet works well with userv-ipif (allowing it to run without needing root > privilege) and hippotat (not currently in Debian) However hippotat seems to be packaged: https://packages.debian.org/search?keywords=hippotat Please correct the description. Thanks a lot! *t -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages secnet depends on: ii init-system-helpers1.65.2 pn libadns1 ii libc6 2.36-9+deb12u4 ii libgmp10 2:6.2.1+dfsg1-1.1 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages secnet recommends: ii python3 3.11.2-1+b1 secnet suggests no packages.
Bug#1065490: mirror submission for mirror.leitecastro.com
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.leitecastro.com Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Tomas Leite Castro Country: PT Portugal Location: Lisbon Comment: This mirror is connected to a 20Gbps lagg and is IPv6 enabled. Syncs every hour from "syncproxy.eu.debian.org" Trace Url: http://mirror.leitecastro.com/debian/project/trace/ Trace Url: http://mirror.leitecastro.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.leitecastro.com/debian/project/trace/mirror.leitecastro.com
Bug#887035: cron: one "easy" way to get cron output
Nice, thanks a lot Georges!!! *t On Thu, 29 Feb 2024, Georges Khaznadar wrote: Hello Tomas, with the current version of cron in trixie, - the build was done with debugging active - man cron provides information about the `-x` flag. So, I close the bug report. Please feel free to reopen it when necessary, or send another bug report if something doe not fulfill your needs. Best regards, Georges. On Fri, 22 Jul 2022 15:59:17 +0200 Tomas Pospisek wrote: @Georges Khaznadar : what do you think about: 1. enabling debugging by default? 2. documenting `-x` ? If Debian would enable the "debbugging feature" of its cron by default, then this would add this overhead in a few places: if ( (DebugFlags & (mask) ) ) printf message; Since DebugFlags is 0 by default, this will ad an overhead of about two machine instructions I guess to a few places, which is a neglible waste/slowdown IMHO. With the "debugging feature" enabled Debian's cron will gain the very nice features: a) for the sysadmin to be able to debug what cron is doing and why and b) use the sysadmin being able to use Debian's cron in docker and kubernetes. IMHO a huge gain that costs nothing.
Bug#1064252: linux-image-6.1.0-17-amd64: CONFIG_SYSTEM_TRUSTED_KEYS="y" is in the default config "y"
Package: src:linux Version: 6.1.69-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: foren...@wi.rr.com In the default config-6.1.0-17-amd64, there is a line: CONFIG_SYSTEM_TRUSTED_KEYS="y" It is impossible to change it from y in menuconfig. Then, it creates 'error no rule to make y. -- Package-specific info: ** Version: Linux version 6.1.0-17-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) ** Command line: BOOT_IMAGE=/vmlinuz-6.1.0-17-amd64 root=UUID=b8970480-c02f-4e13-83ea-99242beaa8c1 ro quiet ** Not tainted ** Kernel log: [850617.148769] sda: unable to read partition table [850617.148860] sd 6:0:0:0: [sda] Attached SCSI disk [850617.204217] sd 6:0:0:0: [sda] Synchronizing SCSI cache [850617.444223] sd 6:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [850617.716182] usb 2-7.4: new high-speed USB device number 11 using xhci_hcd [850617.888733] usb 2-7.4: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 2.09 [850617.888746] usb 2-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [850617.888748] usb 2-7.4: Product: SSK Storage [850617.888750] usb 2-7.4: Manufacturer: SSK [850617.888752] usb 2-7.4: SerialNumber: DD564198838B8 [850617.892008] scsi host6: uas [850617.892602] scsi 6:0:0:0: Direct-Access SSK 0209 PQ: 0 ANSI: 6 [850617.894762] sd 6:0:0:0: Attached scsi generic sg1 type 0 [850617.894982] sd 6:0:0:0: [sda] Spinning up disk... [850618.428107] usb 2-7.4: USB disconnect, device number 11 [850618.924215] .ready [850618.924291] sd 6:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [850618.924296] sd 6:0:0:0: [sda] Sense not available. [850618.924302] sd 6:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [850618.924304] sd 6:0:0:0: [sda] Sense not available. [850618.924314] sd 6:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B) [850618.924316] sd 6:0:0:0: [sda] 0-byte physical blocks [850618.924321] sd 6:0:0:0: [sda] Write Protect is off [850618.924324] sd 6:0:0:0: [sda] Mode Sense: 00 00 00 00 [850618.924328] sd 6:0:0:0: [sda] Asking for cache data failed [850618.924333] sd 6:0:0:0: [sda] Assuming drive cache: write through [850618.924342] sd 6:0:0:0: [sda] Preferred minimum I/O size 4096 bytes not a multiple of physical block size (0 bytes) [850618.924345] sd 6:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (0 bytes) [850618.924995] sd 6:0:0:0: [sda] Attached SCSI disk [854882.880440] usb 2-7.3: USB disconnect, device number 5 [854884.327593] usb 2-7.3: new low-speed USB device number 12 using xhci_hcd [854884.457279] usb 2-7.3: New USB device found, idVendor=047d, idProduct=1020, bcdDevice= 1.08 [854884.457289] usb 2-7.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [854884.457292] usb 2-7.3: Product: Kensington Expert Mouse [854884.463747] input: Kensington Expert Mouse as /devices/pci:00/:00:14.0/usb2/2-7/2-7.3/2-7.3:1.0/0003:047D:1020.0004/input/input21 [854884.464101] hid-generic 0003:047D:1020.0004: input,hidraw2: USB HID v1.11 Mouse [Kensington Expert Mouse] on usb-:00:14.0-7.3/input0 [860266.405755] audit: type=1400 audit(1707886801.612:37): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=178977 comm="cupsd" capability=12 capname="net_admin" [880247.840603] wlp4s0: Connection to AP 00:90:7f:4a:10:b1 lost [880459.847171] wlp4s0: authenticate with 00:90:7f:4a:10:b1 [880459.850240] wlp4s0: send auth to 00:90:7f:4a:10:b1 (try 1/3) [880459.879928] wlp4s0: authenticated [880459.881486] wlp4s0: associate with 00:90:7f:4a:10:b1 (try 1/3) [880459.888498] wlp4s0: RX AssocResp from 00:90:7f:4a:10:b1 (capab=0x511 status=0 aid=1) [880459.893044] wlp4s0: associated [880459.970372] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready [880460.156234] wlp4s0: Limiting TX power to 21 (24 - 3) dBm as advertised by 00:90:7f:4a:10:b1 [966628.811480] wlp4s0: Connection to AP 00:90:7f:4a:10:b1 lost [966840.859629] wlp4s0: authenticate with 00:90:7f:4a:10:b1 [966840.862710] wlp4s0: send auth to 00:90:7f:4a:10:b1 (try 1/3) [966840.891711] wlp4s0: authenticated [966840.894718] wlp4s0: associate with 00:90:7f:4a:10:b1 (try 1/3) [966840.898366] wlp4s0: RX AssocResp from 00:90:7f:4a:10:b1 (capab=0x511 status=0 aid=1) [966840.903409] wlp4s0: associated [966840.943963] wlp4s0: Limiting TX power to 21 (24 - 3) dBm as advertised by 00:90:7f:4a:10:b1 [966840.973030] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready [1053031.509002] wlp4s0: deauthenticated from 00:90:7f:4a:10:b1 (Reason: 3=DEAUTH_LEAVING) [1053245.065573] wlp4s0: authenticate with 00:90:7f:4a:10:b1 [1053245.068633] wlp4s0: send auth to 00:90:7f:4a:10:b1 (try 1/3)
Bug#1040416: linux-image-6.1.0-17-amd64: External log helps
Package: src:linux Followup-For: Bug #1040416 X-Debbugs-Cc: foren...@wi.rr.com I had been having random loss of entire volumes of XFS, for 20 years. A compromise is to format with an external log on the same drive. I use 100MB log per 1TB data. So, in 'gdisk' (GPTFdisk) you can specify to make a partition of the entire drive (-) any amount, or + any amount. Or any size partition you wish +(-) any amount. I partiotion a 2TB drive the entire drive (-) 220mb. I make a partition for the remainder of the drive (-) 20mb, for a 200MB log. The last 20MB is superstition. XFS formats well using the defaults. For external log, it's 'mkfs.xfs -l logdev=/dev/nvme2n1p2 /dev/nvme2n1p1. Logdev= is a mount option, so be sure to include it. Also, don't permit XFS volumes to exceed 80% capacity. Here's the tradeoff. Almost any problem with a XFS file system can be nuked by zeroing the log. Internal logs cause problems when zeroing. External logs zero every time. You lose some metadata, but that's not usually a big deal. There are a few things to examine in formatting (mkfs.xfs). '-m crc=1' is the default. If you specify '-m crc=0', it's just insanity! It's not designed to work without that. But, mechanical drives had their own crc checking. So, no one needed 2. Another thing is XFS is so fast it heats drives. So, you can look at the SMART data, with 'smartctl', or some Windows program, and check the hottest temperature the drive has endured, and also its overall health. -- Package-specific info: ** Version: Linux version 6.1.0-17-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) ** Command line: BOOT_IMAGE=/vmlinuz-6.1.0-17-amd64 root=UUID=b8970480-c02f-4e13-83ea-99242beaa8c1 ro quiet ** Not tainted ** Kernel log: [850617.148769] sda: unable to read partition table [850617.148860] sd 6:0:0:0: [sda] Attached SCSI disk [850617.204217] sd 6:0:0:0: [sda] Synchronizing SCSI cache [850617.444223] sd 6:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [850617.716182] usb 2-7.4: new high-speed USB device number 11 using xhci_hcd [850617.888733] usb 2-7.4: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 2.09 [850617.888746] usb 2-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [850617.888748] usb 2-7.4: Product: SSK Storage [850617.888750] usb 2-7.4: Manufacturer: SSK [850617.888752] usb 2-7.4: SerialNumber: DD564198838B8 [850617.892008] scsi host6: uas [850617.892602] scsi 6:0:0:0: Direct-Access SSK 0209 PQ: 0 ANSI: 6 [850617.894762] sd 6:0:0:0: Attached scsi generic sg1 type 0 [850617.894982] sd 6:0:0:0: [sda] Spinning up disk... [850618.428107] usb 2-7.4: USB disconnect, device number 11 [850618.924215] .ready [850618.924291] sd 6:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [850618.924296] sd 6:0:0:0: [sda] Sense not available. [850618.924302] sd 6:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [850618.924304] sd 6:0:0:0: [sda] Sense not available. [850618.924314] sd 6:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B) [850618.924316] sd 6:0:0:0: [sda] 0-byte physical blocks [850618.924321] sd 6:0:0:0: [sda] Write Protect is off [850618.924324] sd 6:0:0:0: [sda] Mode Sense: 00 00 00 00 [850618.924328] sd 6:0:0:0: [sda] Asking for cache data failed [850618.924333] sd 6:0:0:0: [sda] Assuming drive cache: write through [850618.924342] sd 6:0:0:0: [sda] Preferred minimum I/O size 4096 bytes not a multiple of physical block size (0 bytes) [850618.924345] sd 6:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (0 bytes) [850618.924995] sd 6:0:0:0: [sda] Attached SCSI disk [854882.880440] usb 2-7.3: USB disconnect, device number 5 [854884.327593] usb 2-7.3: new low-speed USB device number 12 using xhci_hcd [854884.457279] usb 2-7.3: New USB device found, idVendor=047d, idProduct=1020, bcdDevice= 1.08 [854884.457289] usb 2-7.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [854884.457292] usb 2-7.3: Product: Kensington Expert Mouse [854884.463747] input: Kensington Expert Mouse as /devices/pci:00/:00:14.0/usb2/2-7/2-7.3/2-7.3:1.0/0003:047D:1020.0004/input/input21 [854884.464101] hid-generic 0003:047D:1020.0004: input,hidraw2: USB HID v1.11 Mouse [Kensington Expert Mouse] on usb-:00:14.0-7.3/input0 [860266.405755] audit: type=1400 audit(1707886801.612:37): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=178977 comm="cupsd" capability=12 capname="net_admin" [880247.840603] wlp4s0: Connection to AP 00:90:7f:4a:10:b1 lost [880459.847171] wlp4s0: authenticate with 00:90:7f:4a:10:b1 [880459.850240] wlp4s0: send auth to 00:90:7f:4a:10:b1 (try 1/3) [880459.879928] wlp4s0: authenticated [880459.881486] wlp4s0: associate with
Bug#1063759: tracker: Please update project homepage URL
Source: tracker Version: 3.4.2-1 Severity: minor Please update the project's homepage. The homepage that is declared in the debian/control file, https://wiki.gnome.org/Projects/Tracker, leads to a "This page does not exist yet" page. The project seems to have a maintained and working homepage at https://tracker.gnome.org/. Thanks a lot, greetings, *t -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1061534: mirror submission for mirror.leitecastro.com
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.leitecastro.com Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Tomas Leite Castro Country: PT Portugal Location: Lisbon Comment: I'm hosting /debian and /debian-cd. Would it be possible to get push syncs from debian directly? I also have space for /debian-backports and /debian-archive. Unfortunately I could not find a working mirror here in Portugal that supports rsync and has these mirrors. Best regards, Tomás Trace Url: http://mirror.leitecastro.com/debian/project/trace/ Trace Url: http://mirror.leitecastro.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.leitecastro.com/debian/project/trace/mirror.leitecastro.com
Bug#960779: ITA: compton -- compositor for X11, based on xcompmgr
Hi Phil,
On Thu, Jan 25, 2024 at 12:28:56PM +, Phil Wyett wrote:
I am interested in 'compton' and would like to adopt it and remove a small part
of the QA
Teams workload from them.
[…]
I use this package now daily as an alternative to the in built XFCE compositor,
so the
health of this package is important to me.
I'm wondering whether you're aware of
https://tracker.debian.org/pkg/picom, which is an actively maintained
fork of compton (although, IME, with a focus on being pretty rather than
on quality and performance).
It's more or less a drop-in replacement for compton, so it should be
super easy for you to try it out for a few days. Personally I've had all
sorts of trouble with it in the past (memory leaks, flicker, and a
massive performance degradation that still hasn't been fixed despite
being reported years ago [1]), so I've been using
https://github.com/liskin/compton/tree/debian/sid, which is a somewhat
random snapshot from a time where everything I need works and nothing is
broken yet.
[1]: https://github.com/yshui/picom/issues/381#issuecomment-956359184
Just thought it'd be useful to fill you in, in case you haven't heard
about picom.
Regards,
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1059464: notepadqq: fix description "designed by developers"
Source: notepadqq Version: 2.0.0~beta1-4 Severity: minor Tags: patch The package's description should read gramatically ... correctly: Notepadqq is a text editor designed by developers, for developers. instead of: Notepadqq is a text editor designed from developers, for developers. Thanks & have nice christmas holidays! *t -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-15-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1058670: python3-poetry: fail with Can't instantiate abstract class IsolatedEnv with abstract methods executable, scripts_dir
Control: severity 1058670 important
Control: forwarded 1058670 https://github.com/python-poetry/poetry/issues/8803
Hi,
On Thu, Dec 14, 2023 at 12:14:12PM +0200, George Shuklin wrote:
According to github bug: https://github.com/python-poetry/poetry/issues/8458 it
is caused by conflict (interactions?) with python3-build package.
python3-build 0.10.0-1
Indeed, as https://github.com/python-poetry/poetry/issues/8803 explains,
poetry 1.7.1 needs python3-build ^= 1.0.3 [1], yet the Debian
python3-poetry package just depends on python3-build without any version
constraints and python3-build is still at 0.10.0-1 in Debian unstable.
Additionally, python3-poetry version 1.6.1+dfsg-2 also has an unbounded
dependency on python3-build despite its
/usr/lib/python3/dist-packages/poetry-1.6.1.dist-info/METADATA clearly
specifying the dependency as "Requires-Dist: build (>=0.10.0,<0.11.0)".
Something is seriously wrong with dh_python it seems :-(
[1]: https://github.com/python-poetry/poetry/blob/1.7.1/pyproject.toml#L37
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1059356: python3-poetry: No module named 'poetry_plugin_export'
Package: python3-poetry
Version: 1.7.1+dfsg-1
Severity: important
Poetry fails whenever it tries to list the available sub-commands, which
it does whenever invoked without arguments or when asked to do so
("list"):
$ poetry
No module named 'poetry_plugin_export'
$ poetry list
No module named 'poetry_plugin_export'
I believe this is because it depends [1] on poetry-plugin-export, but
that dependency is completely ignored in the Debian package (shouldn't
the build fail if that dep is unavailable? I don't see that dep being
patched away anywhere in debian/).
That dependency has been there for a while (since 1.2.0 [2]) but it
"worked" without it as the export sub-command was being discovered at
runtime. Since [3], that dependency is an actual hard dependency, and
thus the Debian packaging will have to catch up.
(But I'd really love to also understand wtf is going on with the
dependency being silently ignored for a year and a half.)
[1]: https://github.com/python-poetry/poetry/blob/1.7.1/pyproject.toml#L36
[2]:
https://github.com/python-poetry/poetry/commit/d52780c53723ac397f4e854a1d62d6cc1015e1ce
[3]:
https://github.com/python-poetry/poetry/commit/f59728d74b1252a0105ce5b8062f8fa28535084f
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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-poetry depends on:
ii python3 [python3-supported-min] 3.11.4-5+b1
ii python3-build0.10.0-1
ii python3-cachecontrol 0.13.1-1
ii python3-cleo 2.1.0-2
ii python3-crashtest0.4.1-1
ii python3-dulwich 0.21.6-1+b1
ii python3-fastjsonschema 2.19.0-1
ii python3-importlib-metadata 4.12.0-1
ii python3-installer0.7.0+dfsg1-2
ii python3-keyring 24.3.0-1
ii python3-lockfile 1:0.12.2-3
ii python3-packaging23.2-1
ii python3-pexpect 4.8.0-4
ii python3-pkginfo 1.8.2-2
ii python3-platformdirs 4.1.0-1
ii python3-poetry-core 1.8.1-1
ii python3-pyproject-hooks 1.0.0-2
ii python3-requests 2.31.0+dfsg-1
ii python3-requests-toolbelt1.0.0-2
ii python3-shellingham 1.5.4-1
ii python3-tomli2.0.1-2
ii python3-tomlkit 0.12.1-1
ii python3-trove-classifiers2023.9.19-1
ii python3-virtualenv 20.25.0+ds-1
python3-poetry recommends no packages.
python3-poetry suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1058753: python3-ruff: FileNotFoundError when invoked via python3 -m ruff
Package: python3-ruff
Version: 0.0.291+dfsg1-1
Severity: normal
$ python3 -m ruff
Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
File "/usr/lib/python3/dist-packages/ruff/__main__.py", line 34, in
ruff = find_ruff_bin()
^^^
File "/usr/lib/python3/dist-packages/ruff/__main__.py", line 30, in
find_ruff_bin
raise FileNotFoundError(path)
FileNotFoundError: /home/tomi/.local/bin/ruff
This is because Debian patches sysconfig [1], so the first
`sysconfig.get_path("scripts")` invocation in `find_ruff_bin` returns
"/usr/local/bin" instead of "/usr/bin" (which upstream expected,
presumably).
[1]:
https://salsa.debian.org/cpython-team/python3/-/blob/af1ddcd55b57a6468121c8776003e57f6f73bca5/debian/patches/sysconfig-debian-schemes.diff
[2]:
https://salsa.debian.org/jelmer/ruff/-/blob/333a90b61f4e99acc74c5e1308982044b95a4af6/python/ruff/__main__.py#L13
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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-ruff depends on:
ii python3 3.11.4-5+b1
python3-ruff recommends no packages.
python3-ruff suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1057968: python3-flake8: cannot import name 'missing_whitespace_around_operator' from 'pycodestyle'
Package: python3-flake8
Version: 5.0.4-4
Severity: normal
flake8 is today broken ($subj) in Debian testing because pycodestyle
2.11 isn't API-compatible with 2.10 and python3-pycodestyle 2.11.1-1
migrated to testing before python3-flake8 6.1.0-1 did. The relevant
upstream change is this one:
https://github.com/PyCQA/flake8/commit/9786562feb573d30c73f18e1a0a6685c8584e9b5
Note that upstream does specify an upper bound on pycodestyle, but the
Debian python3-flake8 package does not. If it had, it would probably
prevent this scenario where one package migrated to testing and the
other didn't. (Well, I hope it would, but I don't know enough about
Debian to be sure.)
(Feel free to close this but please do consider whether that upper bound
would be appropriate. Presumably a similar problem might affect
python3-pyflakes but that didn't migrate yet.)
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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-flake8 depends on:
ii python3 3.11.4-5+b1
ii python3-importlib-metadata 4.12.0-1
ii python3-mccabe 0.7.0-1
ii python3-pycodestyle 2.11.1-1
ii python3-pyflakes2.5.0-1
ii python3-setuptools 68.1.2-2
python3-flake8 recommends no packages.
python3-flake8 suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1057187: mirror submission for deb.bbxnet.sk
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: deb.bbxnet.sk Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Maintainer: Tomas Havlas Country: SK Slovakia Location: Slovakia Sponsor: BBXNET https://bbxnet.sk/ Trace Url: http://deb.bbxnet.sk/debian/project/trace/ Trace Url: http://deb.bbxnet.sk/debian/project/trace/ftp-master.debian.org Trace Url: http://deb.bbxnet.sk/debian/project/trace/deb.bbxnet.sk
Bug#1053310: Fixes for stable/oldstable?
On Tue, 31 Oct 2023, Andreas Metzler wrote:
On 2023-10-31 Tomas Pospisek wrote:
[...]
PS: I'd prefer this bugreport to be open as long as the stable and
oldstable packages are still vulnerable...
Hello Thomas,
The Debian BTS does not use a simple open/close logic, it tracks which
specific versions a bug applies to. If you look at
https://bugs.debian.org/cgi-bin/1053310 there is both textual info
("Found in version exim4/4.94.2-7 Fixed in version exim4/4.97~RC2-2")
and a nice graph in red and green to display this and the overview pages
can also show bugs applying to specific distributions. (Menu items at
the bottom of the page.) e.g.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;package=exim4-base
does not show this bug under "Resolved bugs".
Alright, thank you. Every time I see those "found in"/"fixed in"
bugreport pages I'm at a loss to be 100% clear in what precise state those
bugsreport are. Oh well. Many, many thanks for the explanations!
*t
Bug#1053310: Fixes for stable/oldstable?
Hi Salvatore, thanks a lot for your reply (more below): On Tue, 31 Oct 2023, Salvatore Bonaccorso wrote: Hi Tomas, On Tue, Oct 31, 2023 at 11:07:06AM +0100, Tomas Pospisek wrote: Hello Exim maintainers, this ticket, asking for packages with fixes for CVE-2023-42117 and other security relavant issues is closed. However only a package for unstable has been released: https://security-tracker.debian.org/tracker/CVE-2023-42117 all other Debian releases (stable, oldstable) still seem to be carrying the vulnerable Exim4 version. What is the status of releasing fixed Exims for Debian stable, oldstable? Is anybody working on it? Is help needed? Fixes for CVE-2023-42117 and CVE-2023-42119 are right now considered no-dsa (see comment on the security-tracker about it), and are going to be fixed in the next point releases. The notes say: *** [bookworm] - exim4 (Only an issue if Exim4 run behind an untrusted proxy-protocol proxy) [bullseye] - exim4 (Only an issue if Exim4 run behind an untrusted proxy-protocol proxy) [buster] - exim4 (Only an issue if Exim4 run behind an untrusted proxy-protocol proxy) https://www.zerodayinitiative.com/advisories/ZDI-23-1471/ https://bugs.exim.org/show_bug.cgi?id=3031 https://www.openwall.com/lists/oss-security/2023/09/29/5 https://www.openwall.com/lists/oss-security/2023/10/01/4 https://exim.org/static/doc/security/CVE-2023-zdi.txt *** So I think I can parse from those that CVE-2023-42117 is only critical when exim is run behind a "untrusted proxy-protocol proxy". Questions if you will: * what does "no-dsa" mean? DSA seems to mean Debian Security Announce. Does it mean there is no DSA for that problem yet? What does it mean when a CVE is considered "no-dsa" then? That no DSA will be released for it? * what is a "untrusted proxy-protocol proxy" in the context of a mail transport agent? So exim shouldn't be used behind an untrusted socks proxy? Well I have no real control who connects how to a public MTA... anybody can connect to it to try his luck sending me email. That includes untrusted socks proxies... So to wrap I it /seems/ that I'm probably fine, however the details are so terse that my assessement seems to be rather shaky... Does this help? A bit. Thanks a lot Best greetings! *t
Bug#1053310: Fixes for stable/oldstable?
Hello Exim maintainers, this ticket, asking for packages with fixes for CVE-2023-42117 and other security relavant issues is closed. However only a package for unstable has been released: https://security-tracker.debian.org/tracker/CVE-2023-42117 all other Debian releases (stable, oldstable) still seem to be carrying the vulnerable Exim4 version. What is the status of releasing fixed Exims for Debian stable, oldstable? Is anybody working on it? Is help needed? *t PS: I'd prefer this bugreport to be open as long as the stable and oldstable packages are still vulnerable...
Bug#1041419: ca-certificates-java: workaround
Package: ca-certificates-java Followup-For: Bug #1041419 X-Debbugs-Cc: foren...@wi.rr.com There are actually 2 of each of these files, differing only in 7+7 and 8+7 openjdk-17-jre_17.0.7+7-1~deb12u1_amd64.deb openjdk-17-jre_17.0.8+7-1~deb12u1_amd64.deb openjdk-17-jre-headless_17.0.7+7-1~deb12u1_amd64.deb openjdk-17-jre-headless_17.0.8+7-1~deb12u1_amd64.deb So I purged the partially configured files, and downloaded them again with apt-get -d install I did updatedb and locate to find the full names, and used dpkg -i --force-depends for both of the 8+7 versions, ran apt-get -f install dpkg --configure --pending and there are no more errors. -- System Information: Debian Release: 12.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE 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 ca-certificates-java depends on: ii ca-certificates 20230311 ii default-jre-headless [java8-runtime-headless] 2:1.17-74 ii openjdk-17-jre-headless [java8-runtime-headless] 17.0.8+7-1~deb12u1 ca-certificates-java recommends no packages. ca-certificates-java suggests no packages. -- Configuration Files: /etc/default/cacerts [Errno 13] Permission denied: '/etc/default/cacerts' -- no debconf information
Bug#624438: network-manager: workaround
On Wed, 2021-11-17 at 04:42 -0500, tomas k wrote: > Package: network-manager > Followup-For: Bug #624438 > X-Debbugs-Cc: foren...@wi.rr.com > > Dear Maintainer, > > I've been dealing with this problem with one upgrade--buster to > bullseye--and one new > install of bullseye 11. It seems I must install the correct firmware, > which I already knew, load the driver with modporobe, and then > reboot. > > But there is still the problem that it will lose the wifi interface > with subsequent reboots. I have not demonstrated that with the > new install, but with the upgrade I did. > > So, work needs to be done, because it's not as simple as installing > a few packages to get the interface set up once and for all. And > this type of behavior is very unlike modern Debian, so users have no > experience with it. > > I'm not positive it's even a nm bug. But nm cannot find the wifi > interface, > because it doesn't exist. > It doesn't exist because the firmware isn't loading. Intel's newest wifi chips "Killer" have no specific support in stable. And make sure your PCIe slots aren't stomping on each other. I always put wifi in the first slot. There's also github.com Intel wifi drivers > *** Reporter, please consider answering these questions, where > appropriate *** > > * What led up to the situation? > * What exactly did you do (or not do) that was effective (or > ineffective)? > * What was the outcome of this action? > * What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: 11.1 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), > (500, 'proposed-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-9-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 /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages network-manager depends on: > ii adduser 3.118 > ii dbus 1.12.20-2 > ii libaudit1 1:3.0-2 > ii libbluetooth3 5.55-3.1 > ii libc6 2.31-13+deb11u2 > ii libcurl3-gnutls 7.74.0-1.3+b1 > ii libglib2.0-0 2.66.8-1 > ii libgnutls30 3.7.1-5 > ii libjansson4 2.13.1-1.1 > ii libmm-glib0 1.14.12-0.2 > ii libndp0 1.6-1+b1 > ii libnewt0.52 0.52.21-4+b3 > ii libnm0 1.30.0-2 > ii libpsl5 0.21.0-1.2 > ii libreadline8 8.1-1 > ii libselinux1 3.1-3 > ii libsystemd0 247.3-6 > ii libteamdctl0 1.31-1 > ii libudev1 247.3-6 > ii libuuid1 2.36.1-8 > ii policykit-1 0.105-31 > ii udev 247.3-6 > ii wpasupplicant 2:2.9.0-21 > > Versions of packages network-manager recommends: > ii dnsmasq-base [dnsmasq-base] 2.85-1 > ii iptables 1.8.7-1 > ii libpam-systemd 247.3-6 > ii modemmanager 1.14.12-0.2 > ii ppp 2.4.9-1+1 > ii wireless-regdb 2020.04.29-2 > > Versions of packages network-manager suggests: > ii isc-dhcp-client 4.4.1-2.3 > pn libteam-utils > > -- no debconf information
Bug#1041419: ca-certrificates-java: circular dependencies
Package: ca-certrificates-java Severity: normal X-Debbugs-Cc: foren...@wi.rr.com How do I solve this: dpkg: error processing package ca-certificates-java (--configure): installed ca-certificates-java package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of openjdk-17-jre-headless:amd64: openjdk-17-jre-headless:amd64 depends on ca-certificates-java (>= 20190405~); however: Package ca-certificates-java is not configured yet. dpkg: error processing package openjdk-17-jre-headless:amd64 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of openjdk-17-jre:amd64: openjdk-17-jre:amd64 depends on openjdk-17-jre-headless (= 17.0.7+7-1~deb12u1); however: Package openjdk-17-jre-headless:amd64 is not configured yet. dpkg: error processing package openjdk-17-jre:amd64 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of default-jre: default-jre depends on openjdk-17-jre; however: Package openjdk-17-jre:amd64 is not configured yet. dpkg: error processing package default-jre (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: ca-certificates-java openjdk-17-jre-headless:amd64 openjdk-17-jre:amd64 default-jre E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 12.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE 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#929685: ca-certificates-java: What is the resolution to this bug
Package: ca-certificates-java Followup-For: Bug #929685 X-Debbugs-Cc: foren...@wi.rr.com What is tyhe resolution to this bug? -- System Information: Debian Release: 12.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE 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 ca-certificates-java depends on: ii ca-certificates 20230311 ii default-jre-headless [java8-runtime-headless] 2:1.17-74 iu openjdk-17-jre-headless [java8-runtime-headless] 17.0.7+7-1~deb12u1 ca-certificates-java recommends no packages. ca-certificates-java suggests no packages. -- Configuration Files: /etc/default/cacerts [Errno 13] Permission denied: '/etc/default/cacerts' -- no debconf information
Bug#1040149: systemd: services considered running after mainpid has exited
Package: systemd
Version: 253.5-1
Severity: important
Tags: upstream
X-Debbugs-Cc: t...@nomi.cz
Since
https://github.com/systemd/systemd-stable/commit/ae83e97a51519ca33e70d7ba142cb3ed24212825,
services with ExitType=main (the default) and KillMode=process (not the
default, but used in e.g. libvirtd.service) are considered active even
after the main process has exited.
This is clearly a bug, reported multiple times to systemd: [1], [2] that
has since been fixed upstream [3] and many distros (Fedora, Arch,
openSUSE, NixOS) are carrying the patch even before a systemd-stable
release [4] because it's quite a serious bug that breaks libvirtd socket
activation among other things.
[1]: https://github.com/systemd/systemd/issues/28030
[2]: https://github.com/systemd/systemd/issues/27953
[3]: https://github.com/systemd/systemd/pull/28000
[4]: https://github.com/systemd/systemd-stable/issues/302
Minimal reproducer:
systemd-run --quiet --collect --wait --property=KillMode=process -- sh -c
'sleep 20 &'
This should not return immediately, but instead blocks for 30 seconds in
the affected versions of systemd.
Less minimal reproducer:
1. install libvirt-daemon, libvirt-clients
2. make sure the default network is up (which it wouldn't be if you're
trying to do this inside another libvirt VM due to IP range conflict)
3. wait until the `/usr/sbin/libvirtd --timeout 120` process terminates
4. `systemctl status libvirtd.service` still says "active (running)"
5. `virsh connect` hangs indefinitely
Can we please get the fix [3] added to Debian as well?
(Also, I believe Luca is a maintainer of v252-stable, where the fix also
needs to be backported. v252.11 currently in Debian testing and
stable-proposed-updates is affected as well. I tried to highlight this
issue a week ago [5] but I understand GitHub notifications are easy to
miss.)
[5]: https://github.com/systemd/systemd/pull/28000#issuecomment-1608296400
-- Package-specific info:
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 systemd depends on:
ii libacl12.3.1-3
ii libaudit1 1:3.0.9-1
ii libblkid1 2.38.1-5+b1
ii libc6 2.37-3
ii libcap21:2.66-4
ii libcryptsetup122:2.6.1-4
ii libfdisk1 2.38.1-5+b1
ii libgcrypt201.10.2-2
ii libkmod2 30+20230519-1
ii liblz4-1 1.9.4-1
ii liblzma5 5.4.1-0.2
ii libmount1 2.38.1-5+b1
ii libp11-kit00.24.1-2
ii libseccomp22.5.4-1+b3
ii libselinux13.4-1+b6
ii libssl33.0.9-1
ii libsystemd-shared 253.5-1
ii libsystemd0253.5-1
ii libzstd1 1.5.5+dfsg2-1
ii mount 2.38.1-5+b1
ii systemd-dev253.5-1
Versions of packages systemd recommends:
ii dbus [default-dbus-system-bus] 1.14.8-1
ii systemd-timesyncd [time-daemon] 253.5-1
Versions of packages systemd suggests:
ii libfido2-11.13.0-1
pn libqrencode4
pn libtss2-esys-3.0.2-0
pn libtss2-mu0
pn libtss2-rc0
ii polkitd 122-4
pn systemd-boot
pn systemd-container
pn systemd-homed
ii systemd-resolved 253.5-1
pn systemd-userdbd
Versions of packages systemd is related to:
pn dbus-user-session
pn dracut
ii initramfs-tools0.142
pn libnss-systemd
ii libpam-systemd 253.5-1
ii udev 253.5-1
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1038946: please add a long description
Instead of solely having a short description that says "$FOO is a $BAZ for $BAR" where it's not immediately clear without particular knowledge what $FOO and $BAR are, please add a short text, that explains what $FOO and $BAR actually do. Something like: "Xapp is an application that does . xdg-desktop-portal allows you to do this and that. This package adds infrastructure to support Xapp via xdg-desktop-portal on Cinnamon, MATE and Xfce." Thanks, *t
Bug#1038946: please add a long description
On Mon, 26 Jun 2023, Fabio Fantoni wrote: Il 26/06/2023 12:30, Tomas Pospisek ha scritto: Instead of solely having a short description that says "$FOO is a $BAZ for $BAR" where it's not immediately clear without particular knowledge what $FOO and $BAR are, please add a short text, that explains what $FOO and $BAR actually do. Something like: "Xapp is an application that does . xdg-desktop-portal allows you to do this and that. This package adds infrastructure to support Xapp via xdg-desktop-portal on Cinnamon, MATE and Xfce." Thanks, *t Thanks for reply, long description was already added to git of the package: https://salsa.debian.org/cinnamon-team/xdg-desktop-portal-xapp/-/blob/debian/latest/debian/control Description: Xapp's Cinnamon, MATE and Xfce backends for xdg-desktop-portal xdg-desktop-portal-xapp provides an implementation for the desktop-agnostic xdg-desktop-portal service for Cinnamon, MATE and Xfce. This allows sandboxed applications to request services and information from outside the sandbox in the MATE, Xfce and Cinnamon environments. I taken as base the upstream one (for mint packages) and tried to improve it but suggestions on further improvements are appreciated I think the long description on Salsa is fine. Thanks a lot Fabio! *t
Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue
On Fri, 2023-06-09 at 13:32 +0200, Pascal Hambourg wrote: > On 09/06/2023 at 01:27, tomas k wrote: > > > > I'm on a different system than the problem one. For years I have > > had to boot knoppix > > and run a chroot to change a password I've forgotten, because I use > > a separate usr partition, > > and rescue thinks it's the root directory. Butr without etc it's > > not going to work. > > Rescue mode does not "think" anything about any partition. It is up > to > the user to select the proper root partition, although I admit this > might be improved by providing more information about available > partitions to the user. > > With /usr-merged layout (default since buster IIRC), a separate /usr > must be mounted before running any program. The initramfs mounts a > separate /usr before running init, but the installer rescue mode did > not > before running a shell. This feature has been added to bookworm > installer (rescue 1.86) but not backported to bullseye installer > AFAIK. > That explains it. I can't open the root patitiion, because rescue system says it's not a root partition until I try what is actually /usr. But, I have finally given up separate /usr, and just lumped it in with the pile. But in bookworm it should work? > > My suggestion is, if a user wants a separate usr, to place a hidden > > flag file in root, the presence of which > > informs the system to mount THAT partition AND look in /etc/fstab, > > and mount usr. > > /etc/fstab already exists in the root filesystem, so no need to > create a > flag file.
Bug#1037974: ddcci-dkms: code fails to build and package fails to install with Linux 6.3 headers
Hi I successfully applied patch from https://aur.archlinux.org/packages/ddcci-driver-linux-dkms and compiled without error. Tomas
Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue
Package: debian-installer Severity: critical Tags: d-i Justification: breaks the whole system X-Debbugs-Cc: foren...@wi.rr.com Dear Maintainer, I'm on a different system than the problem one. For years I have had to boot knoppix and run a chroot to change a password I've forgotten, because I use a separate usr partition, and rescue thinks it's the root directory. Butr without etc it's not going to work. Most recently, I just wanted to install grub from the Debian install DVD, nothing else, but once again, with separate usr, no root shell. So I tried to go through the install and just skip to install grub, but it wouldn't allow it, because previous steps were skipped. ThAT FIASCO cost me 4 hours, about the same amount of time it would take to fix the rescue system. My suggestion is, if a user wants a separate usr, to place a hidden flag file in root, the presence of which informs the system to mount THAT partition AND look in /etc/fstab, and mount usr. I'd really like this back the way it was, but I realize /bin is now symlinks. Thanks for all the help. -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1036077: please reassign to xserver
Since this seems to be a xserver problem, could you please reassign the ticket to the correct xserver package? *t
Bug#1033799: pasystray: please update to 0.8.2 (fixes broken output switching with wireplumber)
Package: pasystray
Version: 0.7.1-1+b1
Severity: normal
https://github.com/christophgysin/pasystray/pull/166 got merged a
couple weeks ago, fixing serious issues making pasystray unusable with
wireplumber and bluetooth headphones.
These fixes got released in
https://github.com/christophgysin/pasystray/releases/tag/0.8.2 – can we
have that updated in Debian as well? Thanks!
(I'm reporting this from a system with pasystray on hold at 0.7.1-1+b1,
as that's the last version that works fine.)
-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-security'), (500, 'testing-debug'), (500,
'stable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 pasystray depends on:
ii adwaita-icon-theme 43-1
ii libavahi-client30.8-9
ii libavahi-common30.8-9
ii libavahi-glib1 0.8-9
ii libayatana-appindicator3-1 0.5.92-1
ii libc6 2.36-8
ii libglib2.0-02.74.6-1
ii libgtk-3-0 3.24.37-2
ii libnotify4 0.8.1-1
ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1
ii libpulse0 16.1+dfsg1-2+b1
ii libx11-62:1.8.4-2
pasystray recommends no packages.
Versions of packages pasystray suggests:
pn paman
pn paprefs
ii pavucontrol 5.0-2
pn pavumeter
pn pulseaudio-module-zeroconf
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#941966: Hibernate bug still occuring?
Hi Thorsten, does the bug you described in https://bugs.debian.org/941966 still occur? I.e.: * do you still have that system? * did you maybe upgrade it to a more recent bullseye kernel? Greetings, *t
Bug#970819: Hibernate bug still occuring?
Hi Cameron, does the bug you described in https://bugs.debian.org/970819 still occur? I.e.: * do you still have that system? * did you maybe upgrade it from Debian buster to bullseye? Greetings, *t
Bug#929077: Hibernate bug still occuring?
Hi Chris, does the bug you described in https://bugs.debian.org/929077 still occur? I.e.: * do you still have that system? * did you maybe upgrade it from Debian buster to bullseye? Greetings, *t
Bug#1032612: gnome-control-center: wifi can be shut down to save power disables wifi
Package: gnome-control-center Version: 1:3.38.4-1 Severity: normal Tags: upstream X-Debbugs-Cc: foren...@wi.rr.com Dear Maintainer, In gnome-control-center> power, there is an option with a switch "wifi can be turned off to save power", which means if I turn the switch off, wifi will not be turned off to save power. But in actuality, disabling that option turns wifi off. TYurning wifi back one reactivates the troublesome switch. I would expect the switch to function that if you turn it off, wifi stays on all the time. I know you guys work hard on this stuff. Kudos to you! See what you can do about this. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-control-center depends on: ii accountsservice0.6.55-3 ii apg2.2.3.dfsg.1-5+b2 ii colord 1.4.5-3 ii desktop-base 11.0.3 ii desktop-file-utils 0.26-1 ii gnome-control-center-data 1:3.38.4-1 ii gnome-desktop3-data3.38.5-3 ii gnome-settings-daemon 3.38.2-1 ii gsettings-desktop-schemas 3.38.0-2 ii libaccountsservice00.6.55-3 ii libatk1.0-02.36.0-2 ii libc6 2.31-13+deb11u5 ii libcairo2 1.16.0-5 ii libcheese-gtk253.38.0-3 ii libcheese8 3.38.0-3 ii libcolord-gtk1 0.1.26-2 ii libcolord2 1.4.5-3 ii libcups2 2.3.3op2-3+deb11u2 ii libepoxy0 1.5.5-1 ii libfontconfig1 2.13.1-4.2 ii libgdk-pixbuf-2.0-02.42.2+dfsg-1+deb11u1 ii libglib2.0-0 2.66.8-1 ii libgnome-bluetooth13 3.34.3-2 ii libgnome-desktop-3-19 3.38.5-3 ii libgoa-1.0-0b 3.38.0-3 ii libgoa-backend-1.0-1 3.38.0-3 ii libgsound0 1.0.2-5 ii libgtk-3-0 3.24.24-4+deb11u2 ii libgtop-2.0-11 2.40.0-2 ii libgudev-1.0-0 234-1 ii libhandy-1-0 1.0.3-2 ii libibus-1.0-5 1.5.23-2 ii libkrb5-3 1.18.3-6+deb11u3 ii libmalcontent-0-0 0.10.0-2 ii libmm-glib01.14.12-0.2 ii libnm0 1.30.6-1+deb11u1 ii libnma01.8.30-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-01.46.2-3 ii libpolkit-gobject-1-0 0.105-31+deb11u1 ii libpulse-mainloop-glib014.2-2 ii libpulse0 14.2-2 ii libpwquality1 1.4.4-1 ii libsecret-1-0 0.20.4-2 ii libsmbclient 2:4.13.13+dfsg-1~deb11u5 ii libsoup2.4-1 2.72.0-2 ii libudisks2-0 2.9.2-2+deb11u1 ii libupower-glib30.99.11-2 ii libwacom2 1.8-2 ii libwayland-server0 1.18.0-2~exp1.1 ii libx11-6 2:1.7.2-1 ii libxi6 2:1.7.10-1 ii libxml22.9.10+dfsg-6.7+deb11u3 Versions of packages gnome-control-center recommends: ii cracklib-runtime 2.9.6-3.4 ii cups-pk-helper0.2.6-1+b1 ii gkbd-capplet 3.26.1-1 ii gnome-online-accounts 3.38.0-3 ii gnome-user-docs 3.38.2-1 ii gnome-user-share 3.34.0-2 ii iso-codes 4.6.0-1 ii libcanberra-pulse 0.30-7 ii libnss-myhostname 247.3-7+deb11u1 ii malcontent-gui0.10.0-2 ii network-manager-gnome 1.20.0-3 ii policykit-1 0.105-31+deb11u1 ii pulseaudio-module-bluetooth 14.2-2 ii realmd0.16.3-3 ii rygel 0.40.0-1 ii rygel-tracker 0.40.0-1 ii system-config-printer-common 1.5.14-1 Versions of packages gnome-control-center suggests: ii gnome-software 3.38.1-1 ii gstreamer1.0-pulseaudio 1.18.4-2+deb11u1 pn libcanberra-gtk-module ii libcanberra-gtk3-module 0.30-7 ii x11-xserver-utils7.7+8 -- no debconf information
Bug#1031969: python3.10-venv: python3-venv no longer installable since python3-distutils 3.11.2-2
Package: python3.10-venv
Version: 3.10.10-2
Severity: normal
Today's apt full-upgrade removed python3.10-venv and it can't be
installed any more, as it depends on python3.10-distutils which isn't
provided by python3-distutils any more. Up until today, everything
worked—I had both 3.10 and 3.11 venvs lying around and working fine.
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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.10-venv depends on:
ii python3-pip-whl 23.0+dfsg-2
ii python3-setuptools-whl 66.1.1-1
ii python3.10 3.10.10-2
pn python3.10-distutils
python3.10-venv recommends no packages.
python3.10-venv suggests no packages.
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1030332: libcamera0.0.3:amd64: crashes wireplumber/pipewire sometimes when camera appears
Hi,
On Fri, Feb 03, 2023 at 12:06:38PM +0100, Dylan Aïssi wrote:
What versions of pipewire and wireplumber do you use?
I'm on testing, so the latest:
ii pipewire:amd64 0.3.65-1
amd64audio and video processing engine multimedia server
ii pipewire-libcamera:amd64 0.3.65-1
amd64audio and video processing engine multimedia server
ii wireplumber 0.4.13-1
amd64modular session / policy manager for PipeWire
Can you try to reproduce with libcamera 0.0.4 in experimental? But because of
a soname change, you would need to rebuild pipewire against the new libcamera.
I looked at the commits and diff between 0.0.3 and 0.0.4 yesterday and
it seemed that testing 0.0.4 would be a waste of time, but suppose I can
try it someday. Although I've since realised that I don't really need
pipewire-libcamera on this hardware (or, well, any sort of camera
support in pipewire at all…) so it's a bit of a low priority for me (and
I'll understand if you treat it the same; just wanted to post the
backtrace somewhere for reference really).
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1030332: libcamera0.0.3:amd64: crashes wireplumber/pipewire sometimes when camera appears
Package: libcamera0.0.3 Version: 0.0.3-4 Severity: normal When a USB camera appears (usbguard allow-device …, or just echo 1 >/sys/…/authorized), the pipewire and/or wireplumber processes sometimes segfault in libcamera. Not always, but doing usbguard block-device followed by usbguard allow-device a couple times makes them crash eventually. I can reproduce this with the integrated camera on two different ThinkPads made a couple years apart, the T25 and P14s Gen2i. Backtraces from coredumpctl debug follow: Core was generated by `/usr/bin/wireplumber'. Program terminated with signal SIGSEGV, Segmentation fault. #0 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_S_left (__x=) at /usr/include/c++/12/bits/stl_function.h:407 407 operator()(const _Tp& __x, const _Tp& __y) const [Current thread is 1 (Thread 0x7fd067eb16c0 (LWP 1508236))] (gdb) bt #0 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_S_left(std::_Rb_tree_node_base*) (__x=) at /usr/include/c++/12/bits/stl_function.h:407 #1 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_M_lower_bound(std::_Rb_tree_node > > >*, std::_Rb_tree_node_base*, unsigned long const&) (__k=@0x7fd067eaff08: 20736, __y=0x7fd05c002e20, __x=0x21, this=0x7fd05c002e18) at /usr/include/c++/12/bits/stl_tree.h:1952 #2 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::lower_bound(unsigned long const&) (__k=@0x7fd067eaff08: 20736, this=0x7fd05c002e18) at /usr/include/c++/12/bits/stl_tree.h:1270 #3 std::map >, std::less, std::allocator > > > >::lower_bound(unsigned long const&) (__x=@0x7fd067eaff08: 20736, this=0x7fd05c002e18) at /usr/include/c++/12/bits/stl_map.h:1307 #4 std::map >, std::less, std::allocator > > > >::operator[](unsigned long const&) (__k=@0x7fd067eaff08: 20736, this=0x7fd05c002e18) at /usr/include/c++/12/bits/stl_map.h:507 #5 libcamera::DeviceEnumeratorUdev::addV4L2Device(unsigned long) (this=0x7fd05c000e10, devnum=) at ../src/libcamera/device_enumerator_udev.cpp:306 #6 0x7fd075efe10f in libcamera::DeviceEnumeratorUdev::addUdevDevice(udev_device*) (this=0x7fd05c000e10, dev=0x7fd05c0037d0) at ../src/libcamera/device_enumerator_udev.cpp:113 #7 0x7fd075efed03 in libcamera::DeviceEnumeratorUdev::udevNotify() (this=0x7fd05c000e10) at ../src/libcamera/device_enumerator_udev.cpp:340 #8 0x7fd075d7092c in libcamera::Signal<>::emit() (this=) at ../include/libcamera/base/signal.h:153 #9 libcamera::EventDispatcherPoll::processNotifiers(std::vector > const&) (this=0x7fd05c0012e0, pollfds=) at ../src/libcamera/base/event_dispatcher_poll.cpp:281 #10 0x7fd075d70dc2 in libcamera::EventDispatcherPoll::processEvents() (this=0x7fd05c0012e0) at ../src/libcamera/base/event_dispatcher_poll.cpp:169 #11 0x7fd075d79809 in libcamera::Thread::exec() (this=this@entry=0x56119d05f840) at ../src/libcamera/base/thread.cpp:341 #12 0x7fd075e52507 in libcamera::CameraManager::Private::run() (this=0x56119d05f830) at ../src/libcamera/camera_manager.cpp:122 #13 0x7fd075ad44a3 in std::execute_native_thread_routine(void*) (__p=0x56119cfa2aa0) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:82 #14 0x7fd079377fd4 in start_thread (arg=) at ./nptl/pthread_create.c:442 #15 0x7fd0793f78d0 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100 Core was generated by `/usr/bin/pipewire'. Program terminated with signal SIGSEGV, Segmentation fault. #0 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_S_left (__x=) at /usr/include/c++/12/bits/stl_function.h:407 407 operator()(const _Tp& __x, const _Tp& __y) const [Current thread is 1 (Thread 0x7fe1d62986c0 (LWP 1507832))] (gdb) bt #0 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_S_left (__x=) at /usr/include/c++/12/bits/stl_function.h:407 #1 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_M_lower_bound (__k=@0x7fe1d6297008: 20738, __y=0x7fe1cc010f30, __x=0x10001, this=0x7fe1cc010f28) at /usr/include/c++/12/bits/stl_tree.h:1952 #2 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::lower_bound (__k=@0x7fe1d6297008: 20738, this=0x7fe1cc010f28) at /usr/include/c++/12/bits/stl_tree.h:1270 #3 std::map >, std::less, std::allocator > > > >::lower_bound (__x=@0x7fe1d6297008: 20738, this=0x7fe1cc010f28) at /usr/include/c++/12/bits/stl_map.h:1307 #4 std::map >, std::less, std::allocator > > > >::operator[] (__k=@0x7fe1d6297008: 20738, this=0x7fe1cc010f28) at /usr/include/c++/12/bits/stl_map.h:507 #5 libcamera::DeviceEnumeratorUdev::addV4L2Device (this=0x7fe1cc012130, devnum=) at ../src/libcamera/device_enumerator_udev.cpp:306 #6 0x7fe1d9fa810f in libcamera::DeviceEnumeratorUdev::addUdevDevice (this=0x7fe1cc012130, dev=0x7fe1cc012790) at ../src/libcamera/device_enumerator_udev.cpp:113 #7
Bug#1027927: pipx: cannot install python application
Hi,
On Thu, Jan 05, 2023 at 01:19:58AM +0800, ChangZhuo Chen wrote:
We have the following error when runuing install command "pipx install
httpie":
[…]
/home/czchen/.local/pipx/venvs/httpie/bin/python: No module named pip
I ran into a similar issue now that python3.11 arrived as the default in
testing, and wiping ~/.local/pipx helped. That's probably because pipx
keeps a shared venv in ~/.local/pipx/shared but doesn't check whether
that venv's python version matches the one you're currently using.
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1027483: thank you!
and I guess #1027483 can be closed as it is still open along with #1027430 ? On Wed, 25 Jan 2023, Tomas Pospisek wrote: Woah guys, a new Debian stable kernel came my way and finally sound works again consistently. Many, many, many thanks to you for bisecting, patching and shipping the fix. Muito, muito obrigado! *t
Bug#1027483: thank you!
Woah guys, a new Debian stable kernel came my way and finally sound works again consistently. Many, many, many thanks to you for bisecting, patching and shipping the fix. Muito, muito obrigado! *t
Bug#1029389: nautilus: umount usb xfs with external log damages log
Package: nautilus Version: 3.38.2-1+deb11u1 Severity: normal Tags: upstream X-Debbugs-Cc: foren...@wi.rr.com I used the eject option for a usb drive with a xfs file system and external log. The drive wouldn't mount subsequently, and advised using xfs_repair. xfs_repair advised mounting the drive, and if that was not possible, to zero the log, losing all meta data, and possibly causing corruption. I could not mount the drive, so I zeroed the log with xfs_repair. Subsequently, thew drive could be mounted (NVMe drive inside usb enclosure). Experimenting, I tried using umount from the shell, and it properly unmounted the drive, which could then be mounted without issue. Granted this is currently a rare situation. But with the possibility of 4TB usb drives presently, and the advantages of the xfs for use with huge numbers of files (I use the drive in question to maintain the i386 and amd64 arches of the Debian mirror with ftpsync) and the advantages of external log feature, it might become more common. Thanks for all the help. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nautilus depends on: ii bubblewrap 0.4.1-3 ii desktop-file-utils 0.26-1 ii gsettings-desktop-schemas 3.38.0-2 ii gvfs1.46.2-1 ii libatk1.0-0 2.36.0-2 ii libc6 2.31-13+deb11u4 ii libcairo-gobject2 1.16.0-5 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1 ii libgexiv2-2 0.12.1-1 ii libglib2.0-02.66.8-1 ii libglib2.0-data 2.66.8-1 ii libgnome-autoar-0-0 0.2.4-3 ii libgnome-desktop-3-19 3.38.5-3 ii libgstreamer-plugins-base1.0-0 1.18.4-2 ii libgstreamer1.0-0 1.18.4-2.1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libnautilus-extension1a 3.38.2-1+deb11u1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libselinux1 3.1-3 ii libtracker-sparql-2.0-0 2.3.6-2 ii nautilus-data 3.38.2-1+deb11u1 ii shared-mime-info2.0-1 ii tracker 2.3.6-2 ii tracker-extract 2.3.5-2.1 ii tracker-miner-fs2.3.5-2.1 Versions of packages nautilus recommends: ii gnome-sushi 3.38.0-1 ii gvfs-backends 1.46.2-1 ii libgdk-pixbuf2.0-bin 2.42.2+dfsg-1+deb11u1 ii librsvg2-common 2.50.3+dfsg-1 Versions of packages nautilus suggests: ii eog 3.38.2-1 ii evince [pdf-viewer] 3.38.2-1 ii nautilus-extension-brasero 3.12.2-6 ii nautilus-sendto 3.8.6-3.1 ii totem 3.38.0-2 ii vlc [mp3-decoder] 3.0.17.4-0+deb11u1 ii xdg-user-dirs 0.17-2 -- no debconf information
Bug#1029071: enable pam_umask usergroups by default
Package: libpam-modules Version: 1.4.0-9+deb11u1 Followup-For: Bug #583958 This bug has not yet been resolved and is still causing problems in 2023. The setting for UMASK is not respected for logins on tty as well as via SSH or SSHFS. I have spent the last 10 years manually adding this configuration to the file with every new Debian install: echo "session optional pam_umask.so usergroups" >> /etc/pam.d/common-session This line of code is present in most GNU/Linux distributions by default and solves the problem. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 libpam-modules depends on: ii debconf [debconf-2.0] 1.5.77 ii libaudit1 1:3.0-2 ii libc6 2.31-13+deb11u5 ii libcrypt1 1:4.4.18-4 ii libdb5.3 5.3.28+dfsg1-0.8 ii libnsl21.3.0-2 ii libpam-modules-bin 1.4.0-9+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libselinux13.1-3 ii libtirpc3 1.3.1-1+deb11u1 libpam-modules recommends no packages.
Bug#1014369: Regression: incorrect icon used in 0.8.0
Dear maintainer,
On Tue, Jul 05, 2022 at 11:27:35AM +1000, Konomi Kitten wrote:
After updating pasystray to 0.8.0 from 0.7.1 the icon displayed in the systray
no longer respects the theme set by the user. I've reported this bug upstream
[1].
[1] https://github.com/christophgysin/pasystray/issues/161
https://github.com/christophgysin/pasystray/releases/tag/0.8.1 was
released a couple weeks ago with a fix for this issue:
https://github.com/christophgysin/pasystray/commit/1f72c621cd40bb9d2bb691b9fa7b8f136bd2352d
Can we get this updated in Debian? Thx!
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1020415: bcron-start terminated 111 status
Hi Georges,
issue with crond, we are currently having is that main process some
times hangs with high single core cpu usage. When its happens, jobs are
often delayed or not executed at all. We are talking about about 1300
user crontabs. Some are empty one, some are using up to 10 jobs. However
this is happening irregularly. Only solution I have found is to restart
crond via init script. I was able to catch what it is doing with strace:
rt_sigprocmask(SIG_BLOCK, [HUP USR1 USR2 PIPE ALRM CHLD TSTP URG VTALRM
PROF WINCH IO], [], 8) = 0
openat(AT_FDCWD, "/run/systemd/userdb/",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 5
fstat(5, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
getdents64(5, 0x557caf6dd300 /* 3 entries */, 32768) = 96
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 6
connect(6, {sa_family=AF_UNIX,
sun_path="/run/systemd/userdb/io.systemd.DynamicUser"},
45) = 0
epoll_create1(EPOLL_CLOEXEC) = 7
timerfd_create(CLOCK_MONOTONIC, TFD_CLOEXEC|TFD_NONBLOCK) = 8
epoll_ctl(7, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=2881333152,
u64=93993945638816}}) = 0
epoll_ctl(7, EPOLL_CTL_ADD, 6, {0, {u32=2943150768,
u64=93994007456432}}) = 0
getdents64(5, 0x557caf6dd300 /* 0 entries */, 32768) = 0
close(5) = 0
epoll_ctl(7, EPOLL_CTL_MOD, 6, {EPOLLIN|EPOLLOUT, {u32=2943150768,
u64=93994007456432}}) = 0
timerfd_settime(8, TFD_TIMER_ABSTIME, {it_interval={tv_sec=0,
tv_nsec=0}, it_value={tv_sec=15696950, tv_nsec=229181000}}, NULL) = 0
epoll_wait(7, [{EPOLLOUT, {u32=2943150768, u64=93994007456432}}], 4,
0) = 1
sendto(6, "{\"method\":\"io.systemd.UserDataba"..., 133,
MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 133
epoll_ctl(7, EPOLL_CTL_MOD, 6, {EPOLLIN, {u32=2943150768,
u64=93994007456432}}) = 0
epoll_wait(7, [{EPOLLIN, {u32=2943150768, u64=93994007456432}}], 4,
0) = 1
recvfrom(6, "{\"error\":\"io.systemd.UserDatabas"..., 131080,
MSG_DONTWAIT, NULL, NULL) = 66
epoll_ctl(7, EPOLL_CTL_MOD, 6, {0, {u32=2943150768,
u64=93994007456432}}) = 0
epoll_wait(7, [], 4, 0) = 0
epoll_wait(7, [], 4, 0) = 0
epoll_ctl(7, EPOLL_CTL_DEL, 6, NULL) = 0
close(6) = 0
close(7) = 0
close(8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 5
lseek(5, 0, SEEK_CUR) = 0
fstat(5, {st_mode=S_IFREG|0644, st_size=217418, ...}) = 0
read(5, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 4096
Last 3 lines are repeated for each cron user (in the matter of fact it
iterates for about 20 users, and then the whole top part of strace is
repeated). Can it be caused by number of orphan crontabs?
((domainname.cz) ORPHAN (no passwd entry)) To run user cron jobs there
is some wrapper script for PHP, which configures some variables for PHP
interpreter such as open_basedir etc. It is simple bash script, which
actually launches defined task. But problem is within main crond proess:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
437055 root 20 0 67828 63792 2748 R 90.9 0.0 1000:40 cron
On older hosting server (debian 7 even 8) we had same issue few years
ago and installation of bcron seemed to fix this issue.
Best regards Tomas
On 09. 12. 22 15:16, Georges Khaznadar wrote:
Dear Thomas,
Tomas Hodek a écrit :
I have been using Debian on servers for many years, but this is first time I
had to file bug report, so i am quite newbie in how to properly debug
package.
Please can you remind me why you could not use cron for your crontabs?
As I understand cron's internals a little better than bcron's, I might
be able to fix the issue which prevents you from using cron?
Here is an excerpt of your latest message about this issue:
Our issue with cron was not yet reported, since I did not found any
regularity and have no test environment where I was able to
reproduce this issue. Only thing I know for sure is the fact that
cron process sometimes eats 1 whole CPU core and then jobs are not
being executed correctly. Normal CPU usage is mere percents. Restart
of daemon fixes it.
I suppose that there is some significant difference between your set of
cron jobs and cron jobs other debian users are running majoritarily, as
nobody complains about a similar issue.
I wonder whether you have a few commands in some cron job which can have
a long life time and require many computing force? Could you know which
children commands were executed when you saw high CPU usage? cron puts
no limit (in duration or cpu & memory usage) for children processes.
But if RFH will not help with finding and issue, this package is no
longer usable for users, so marki
Bug#1020415: bcron-start terminated 111 status
Hello, only workaround I was able to create is to restart crond after a while :) But did not find any solution to make bcron to work. Fact, that no one reported any problems must be if not much people uses it - I had same issue even on clean install. It is possible, no one noticed it... because of something. I have been using Debian on servers for many years, but this is first time I had to file bug report, so i am quite newbie in how to properly debug package. But if RFH will not help with finding and issue, this package is no longer usable for users, so marking it obsolete seems to only a reasonable choice. But it is not up to me, and I think it would be better to someone to look at this issue, who has better understanding of how systemd and c++ (I think bcron is written in it) programming works. However your helps is really appreciated Thanks Tomas On 08. 12. 22 20:03, Georges Khaznadar wrote: Dear Hodek, have you found a workaround to manage your cron jobs? Let me summarize the current situation: - you raised bug report 1020415 three months ago, based on your experience with bcron version 0.11-9, which is part of debian/stable aka bullseye; version 0.11-9 has been released in March 2020, so it was more than two years ago (the upload was made by Dmitry Bogatov, signed by Andreas Henriksson) - both of us could check that this version is buggy, and cannot be launched properly by systemd within a debian/bullseye system - I took the responsability of this package in June 2022, and uploaded some new releases (0.11.10 to 0.11-17). bcron 0.11-17 migrated to debian/testing on Tue, 28 Jun 2022. Those changes allowed me to close a few bugs (#983799, #984576 and #1012852), and introduce a pre-dependency from bcron to cron-daemon-common, in order to enable users to switch easier between cron, bcron and cronie in the future. At that time, nobody complained about bcron's wrong startup. - I am receiving now repeated warnings from Ubuntu's automaton, which states that the last version of bcron cannot entrer Ubuntu's future stable release. Here are a few possible reactions: - I can orphan the package bcron (it would be orphaned twice!) - I can raise a RFH (request for help) bugreport ... and hope. - I can try to enforce the postinst, prerm and postrm scripts which did work within debian/buster, and inhibit the normal build of the package, regarding dh_sysuser and dh_runit, as you could check that launching bcron by hand was effective. If I do so, I must prominently state for future users than bcron must be considered as obsolete, and recommend using cron (or cronie in the future?) Any thoughts? Thank you in advance for your feedback. Best regards, Georges.
Bug#592276: evolution freezes when importing large backup
Package: evolution Version: 3.38.3-1 Followup-For: Bug #592276 X-Debbugs-Cc: foren...@wi.rr.com Dear Maintainer, I upgraded evolution with a routine system upgrade, to upgrade with new packages. The upgraded version uses a different mail format. I expected the existing email tree to be converted to the new format. No such luck. The upgrade just blew the tree away. But I made a full backup before the upgrade just in case. The backup is in the old format. When I try to import it, the machine freezes with a message in the bottom bar that it is scanning a certain directory. After 2 to 3 minutes, a dialog box pops up saying that evolution has stopped responding. If I click "Wait", and go do something else for a while, when I come back, the dialog is back in a few seconds, with the same message in the bottom bar, scanning directory such and such. But it's the same directory in the message as before. The laptop is one of the fastest Lenovo from 2016, so processor power shouldn't be an issue. The drive is a SSD, so it's fast too: 450MB/s Diagnostics show no problem with memory (memtrester run 10 cycles), or anything else. I think hardware error is not an issue. If I leave it running overnight, it's the same the next night. Never had this problem before. So, I think it can be traced to the new mail format and the conversion neccesary of the backup file data. It appears to import the raw data in the backup, but it fails somewhere after that. The backup is huge (100-150MB), and I haven't archived anything ever (5-7years). And, the trash might have been quite loaded, as I have emptied it only once. I'd say there are at least 20,000 messages in the backup. I don't know if that matters. I've tried purging evolution and reinstalling. Same problem. I'm experienced with Debian, since woody. But I cannot solve this problem. Thank you for all the help. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution depends on: ii dbus 1.12.20-2 ii evolution-common 3.38.3-1 ii evolution-data-server 3.38.3-1 ii libc6 2.31-13+deb11u4 ii libcamel-1.2-623.38.3-1 ii libclutter-gtk-1.0-0 1.8.4-4 ii libecal-2.0-1 3.38.3-1 ii libedataserver-1.2-25 3.38.3-1 ii libevolution 3.38.3-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libical3 3.0.9-2 ii libnotify4 0.7.9-3 ii libsoup2.4-1 2.72.0-2 ii libwebkit2gtk-4.0-37 2.36.7-1~deb11u1 ii libxml22.9.10+dfsg-6.7+deb11u2 ii psmisc 23.4-2 Versions of packages evolution recommends: ii evolution-plugin-bogofilter 3.38.3-1 ii evolution-plugin-pstimport 3.38.3-1 ii evolution-plugins3.38.3-1 ii yelp 3.38.3-1 Versions of packages evolution suggests: pn evolution-ews pn evolution-plugins-experimental ii gnupg 2.2.27-2+deb11u2 ii network-manager 1.30.6-1+deb11u1 -- no debconf information
Bug#1025514: xfsprogs: Allow by-uuid link in mount option logdev
Package: xfsprogs Version: 5.10.0-4 Severity: wishlist Tags: upstream X-Debbugs-Cc: foren...@wi.rr.com Is there any way for mkfs.xfs to give the external log a UUID, so external drives with externaL logs can be mounted from fstab even if the partition device files change letters? -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfsprogs depends on: ii libblkid1 2.36.1-8+deb11u1 ii libc6 2.31-13+deb11u4 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libedit23.1-20191231-2+b1 ii libicu6767.1-7 ii libinih153-1+b2 ii libuuid12.36.1-8+deb11u1 ii python3 3.9.2-3 xfsprogs recommends no packages. Versions of packages xfsprogs suggests: ii acl 2.2.53-10 pn attr pn quota pn xfsdump -- no debconf information
Bug#989943: Problem still occuring in unattenden-upgrades from bullseye
Package: unattended-upgrades
Version: 2.8
Followup-For: Bug #989943
X-Debbugs-Cc: Michael Vogt
Hi,
I'm still seeing this problem in unattended-upgrades from Debian bullseye.
Thanks a lot for unattended-upgrades and the maintainance!!!
*t
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-22-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages unattended-upgrades depends on:
ii debconf [debconf-2.0] 1.5.77
ii lsb-base 11.1.0
ii lsb-release11.1.0
ii python33.9.2-3
ii python3-apt2.2.1
ii python3-dbus 1.2.16-5
ii python3-distro-info1.0
ii ucf3.0043
ii xz-utils 5.2.5-2.1~deb11u1
Versions of packages unattended-upgrades recommends:
ii cron [cron-daemon] 3.0pl1-137
Versions of packages unattended-upgrades suggests:
ii bsd-mailx 8.1.2-0.20180807cvs-2
pn needrestart
ii nullmailer [mail-transport-agent] 1:2.2-3
pn powermgmt-base
ii python3-gi 3.38.0-2
-- debconf information:
* unattended-upgrades/enable_auto_updates: true
unattended-upgrades/origins_pattern:
"origin=Debian,codename=${distro_codename},label=Debian-Security";
Bug#998950: mailsync: diff for NMU version 5.2.7-3.1
On Thu, 3 Nov 2022, Marcos Talau wrote: Control: tags 998950 + patch Control: tags 998950 + pending Dear maintainer, I've prepared an NMU for mailsync (versioned as 5.2.7-3.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Many, many thanks Marcos! *t
Bug#1003974: Screenshot of missing icons in Impress
see previous email in this bugreport for context
Bug#1003974: libreoffice-impress: Some icons do not get displayed in Impress
Hello Nicolas and Libre Office maintainers, (Not sure what's going on, I'm submitting this bug report for the third time since for unknown reason it doesn't make it into the BTS) My Libre Office Impress is not displaying some icons - see attached screenshot that I will send in the next email. I think this *might* be the same problem as Nicolas reported. I also have XFCE as a desktop, like Nicolas does. I have the libreoffice-gtk3 (1:7.4.1-1~bpo11+2) integration library installed. My libreoffice package is from bullseye-backports running on a bullseye system. I did not have the problems with the icons with the package from the bullseye distro (that is with the 1:7.0.4-4+deb11u4 packages). Thank you for the libreoffice packages dear maintainers! *t -- Package-specific info: -- System Information: Debian Release: 11.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-impress depends on: ii libbox2d2.3.02.3.1+ds-7 ii libc62.31-13+deb11u4 ii libepoxy01.5.5-1 ii libetonyek-0.1-1 0.1.9-4 ii libgcc-s110.2.1-6 ii libodfgen-0.1-1 0.1.8-2 ii libreoffice-common 1:7.4.1-1~bpo11+2 ii libreoffice-core 1:7.4.1-1~bpo11+2 ii libreoffice-draw 1:7.4.1-1~bpo11+2 ii librevenge-0.0-0 0.0.4-6+b1 ii libstaroffice-0.0-0 0.0.7-1 ii libstdc++6 10.2.1-6 ii libuno-cppu3 1:7.0.4-4+deb11u4 ii libuno-cppuhelpergcc3-3 1:7.4.1-1~bpo11+2 ii libuno-sal3 1:7.4.1-1~bpo11+2 ii libuno-salhelpergcc3-3 1:7.0.4-4+deb11u4 ii ucf 3.0043 ii uno-libs-private 1:7.4.1-1~bpo11+2 libreoffice-impress recommends no packages. Versions of packages libreoffice-impress suggests: ii bluez 5.55-3.1 Versions of packages libreoffice-core depends on: ii fontconfig 2.13.1-4.2 ii fonts-opensymbol2:102.12+LibO7.4.1-1~bpo11+2 ii libabsl20200923 0~20200923.3-2 ii libboost-filesystem1.74.0 1.74.0-9 ii libboost-iostreams1.74.01.74.0-9 ii libboost-locale1.74.0 1.74.0-9 ii libc6 2.31-13+deb11u4 ii libcairo2 1.16.0-5 ii libclucene-contribs1v5 2.3.3.4+dfsg-1+b1 ii libclucene-core1v5 2.3.3.4+dfsg-1+b1 ii libcups22.3.3op2-3+deb11u2 ii libcurl3-gnutls 7.74.0-1.3+deb11u3 ii libdbus-1-3 1.12.24-0+deb11u1 ii libdconf1 0.38.0-2 ii libeot0 0.01-5+b1 ii libepoxy0 1.5.5-1 ii libexpat1 2.2.10-2+deb11u5 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1+deb11u1 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.8-1 ii libgpgmepp6 1.14.0-1+b2 ii libgraphite2-3 1.3.14-1 ii libgstreamer-plugins-base1.0-0 1.18.4-dmo1 ii libgstreamer1.0-0 1.18.4-2.1 ii libharfbuzz-icu02.7.4-1 ii libharfbuzz0b 2.7.4-1 ii libhunspell-1.7-0 1.7.0-3 ii libhyphen0 2.8.8-7 ii libice6 2:1.0.10-1 ii libicu6767.1-7 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-2 2.12~rc1-2 ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1 ii libmythes-1.2-0 2:1.2.4-3+b1 ii libnspr42:4.29-1 ii libnss3 2:3.61-1+deb11u2 ii libopenjp2-72.4.0-3 ii libpng16-16 1.6.37-3 ii libpoppler102 20.09.0-3.1+deb11u1 ii libraptor2-02.0.14-1.2 ii librdf0 1.0.17-1.1+b1 ii libreoffice-common 1:7.4.1-1~bpo11+2 ii librevenge-0.0-00.0.4-6+b1 ii libsm6 2:1.2.3-1 ii libstdc++6 10.2.1-6 ii libtiff54.2.0-1+deb11u1 ii libuno-cppu31:7.0.4-4+deb11u4 ii libuno-cppuhelpergcc3-3 1:7.4.1-1~bpo11+2 ii libuno-sal3 1:7.4.1-1~bpo11+2 ii libuno-salhelpergcc3-3 1:7.0.4-4+deb11u4 ii libwebp60.6.1-2.1 ii libx11-62:1.7.2-1 ii libx11-xcb1 2:1.7.2-1 ii libxext62:1.3.3-1.1 ii libxinerama12:1.1.4-2 ii libxml2
Bug#1003974: similar bugs having to do with icons not appearing
Hi bug reporters and Libre Office maintainers, there's a number of bugs related to Icon rendering that seem to be simlar or identical. Herewith I'm posting to them to crosslink them. I have however *not* looked at them in depth. Here are the bug reports: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661818 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969977 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003974 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972280 The idea of posting to all of them/crosslinking them is the hope that maybe the reporters and or maintainers can verify that they are the same and/or find workarounds or root causes/fixes to all of them... *t
Bug#1020415: bcron-start terminated 111 status
Hi Georges no, problem is with fresh install of stable. Tomas On 28. 09. 22 15:35, Georges Khaznadar wrote: Hi Thomas, The issue with bcron appears when you switch from oldstable to stable, doesn't it? Maybe it comes from a fuzzy integration of bcron with systemd. Have you tried to switch back to SysVinit? Here is an e-mail thread about switching Bullseye to SysVinit, which is two years old: https://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-August/002351.html Please can you check whether bcron behaves better when managed by SysVinit? Thank you in advance for your feedback. Best regards, Georges. Tomas Hodek a écrit : Hi about acl, it is strange, since package acl was not installed (thought this package is required to manipulate acl) this was all tested on current stable version (0.11-9) getfacl crontabs/ # file: crontabs/ # owner: cron # group: cron # flags: --t user::rwx group::--- other::--- permissions before bcron install: drwx-wx--T 2 root crontab 4096 Feb 22 2021 crontabs so I chaneged them to: drwx-T 2 cron cron 4096 Sep 27 08:27 crontabs After upgrade to debian/testing acl changed: getfacl crontabs/ # file: crontabs/ # owner: root # group: crontab # flags: --t user::rwx user:cron:rwx group::-wx group:cron:rwx mask::rwx other::--- However I still get error in syslog: daemon: bcron-start: client (pid 798) exited with 111 status, exiting Also tried to chown whole directory as mentioned, but issue remains same. == Our issue with cron was not yet reported, since I did not found any regularity and have no test environment where I was able to reproduce this issue. Only thing I know for sure is the fact that cron process sometimes eats 1 whole CPU core and then jobs are not being executed correctly. Normal CPU usage is mere percents. Restart of daemon fixes it. Tomas On 26. 09. 22 19:01, Georges Khaznadar wrote: Hi Thomas, thank you for your investigation work. The modifications which I made, since version 0.11-9 which was maintained by Dmitri Bogdanov, are aiming to prepare a transition from cron (whose upstream is no longer maintained) to cronie (not for tomorrow, but at some time later). For such a transition to be feasible, all cron equivalents used in debian must share a common base, so now bcron depends on the package cron-daemon-common (like cron). However, bcron has a peculiarity: the directory /var/spool/cron/crontabs/ must be given to user cron and group cron, while other cron-like packages give this directory to user root and group crontab. In order to let users install cron-like packages back and forth, postinst and prerm routines of bcron are modifying access control lists (ACLs) when bcron is installed and when it is purged. From what you wrote, I suspect that the access control lists are not correctly tuned, so, maybe, schedulers cannot do exactly the same job when launched by systemd than when they are launched manually. I fair that the difference list between versions 0.09-13 and 0.11-17 may be too long to be useful. Please can you check whether the version 0.11-9 available in debian/stable can currently fulfill your needs? Another question, if you do not mind: please try to install the last version from testing (0.11-17), then make a: # chmod -R cron:cron /var/spool/cron/crontabs/ and check whether this can fix the spurious behavior? Thank you in advance for your feedback. = By the way, you wrote that you had been "forced to install bcron instead of default cron package since the default one sometimes failed to execute all configured jobs" ... Did you post bug reports about it, against cron? This package, whose popcon score is two thousand bigger than bcron, has a list of 87 open bugs. I began to fix a few of them four months ago, and my progress is slow, because I want to write a test for each bug I fix, in order to prevent regressions in the future. The page https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=cron does not allow me to view precisely whether some of the bug reports come from you. I you have reported some, please tell me which they are. Best regards, Georges. Tomas Hodek a écrit : Hi Georges, I have tried to enter log messages as requested (also included header files for syslog library), recompiled etc... But i am not able to get any relevant informations from syslog - nothing is written. Am I missing something? I have also made fresh install of debian 11 and even with no additional software bcron-start is exitting with 111 status. When upgraded to testing release same problem: apt-cache policy bcron bcron: Installed: 0.11-17 Candidate: 0.11-17 Version table: *** 0.11-17 550 500 http://deb.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status 0.11-9 500 500 http://deb.debian.org/debian bullseye/main amd6
Bug#1020415: bcron-start terminated 111 status
ar/run/bcron-start.clientpid Sep 21 13:27:12 hostname daemon: [pid 2363944] bcron-start: debug: unlinking clientpidfile /var/run/bcron-start.clientpid Sep 21 13:27:12 hostname daemon: [pid 2363944] bcron-start: debug: child terminated, exiting Sep 21 13:27:12 hostname daemon: [pid 2363944] bcron-start: debug: unlink_clientpidfile /var/run/bcron-start.clientpid Sep 21 13:27:12 hostname daemon: [pid 2363944] bcron-start: debug: unlinking clientpidfile /var/run/bcron-start.clientpid On 27. 09. 22 10:11, Georges Khaznadar wrote: Dear Thomas, I made a mistake, when I read your first bug report: as your APT policy was based on 'stable', you were reporting about the current stable version, 0.11-9. So the misbehavior which motivates your report, was introduced before I adopted the package. This is weird, since version 0.11-9 passed to stable for one year, an no bug report was reported between 2020-03-18 when this version entered testing and 2021-08-14, when bullseye became stable. Please can you make a test with version 0.11-17, which is currently in testing ? I would prefer a lot to fix the problem in the last version (if it is still there), even if studying the version in bullseye may shed some light on the bug. Best regards, Georges. Tomas Hodek a écrit : Hi about acl, it is strange, since package acl was not installed (thought this package is required to manipulate acl) this was all tested on current stable version (0.11-9) getfacl crontabs/ # file: crontabs/ # owner: cron # group: cron # flags: --t user::rwx group::--- other::--- permissions before bcron install: drwx-wx--T 2 root crontab 4096 Feb 22 2021 crontabs so I chaneged them to: drwx-T 2 cron cron 4096 Sep 27 08:27 crontabs After upgrade to debian/testing acl changed: getfacl crontabs/ # file: crontabs/ # owner: root # group: crontab # flags: --t user::rwx user:cron:rwx group::-wx group:cron:rwx mask::rwx other::--- However I still get error in syslog: daemon: bcron-start: client (pid 798) exited with 111 status, exiting Also tried to chown whole directory as mentioned, but issue remains same. == Our issue with cron was not yet reported, since I did not found any regularity and have no test environment where I was able to reproduce this issue. Only thing I know for sure is the fact that cron process sometimes eats 1 whole CPU core and then jobs are not being executed correctly. Normal CPU usage is mere percents. Restart of daemon fixes it. Tomas On 26. 09. 22 19:01, Georges Khaznadar wrote: Hi Thomas, thank you for your investigation work. The modifications which I made, since version 0.11-9 which was maintained by Dmitri Bogdanov, are aiming to prepare a transition from cron (whose upstream is no longer maintained) to cronie (not for tomorrow, but at some time later). For such a transition to be feasible, all cron equivalents used in debian must share a common base, so now bcron depends on the package cron-daemon-common (like cron). However, bcron has a peculiarity: the directory /var/spool/cron/crontabs/ must be given to user cron and group cron, while other cron-like packages give this directory to user root and group crontab. In order to let users install cron-like packages back and forth, postinst and prerm routines of bcron are modifying access control lists (ACLs) when bcron is installed and when it is purged. From what you wrote, I suspect that the access control lists are not correctly tuned, so, maybe, schedulers cannot do exactly the same job when launched by systemd than when they are launched manually. I fair that the difference list between versions 0.09-13 and 0.11-17 may be too long to be useful. Please can you check whether the version 0.11-9 available in debian/stable can currently fulfill your needs? Another question, if you do not mind: please try to install the last version from testing (0.11-17), then make a: # chmod -R cron:cron /var/spool/cron/crontabs/ and check whether this can fix the spurious behavior? Thank you in advance for your feedback. = By the way, you wrote that you had been "forced to install bcron instead of default cron package since the default one sometimes failed to execute all configured jobs" ... Did you post bug reports about it, against cron? This package, whose popcon score is two thousand bigger than bcron, has a list of 87 open bugs. I began to fix a few of them four months ago, and my progress is slow, because I want to write a test for each bug I fix, in order to prevent regressions in the future. The page https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=cron does not allow me to view precisely whether some of the bug reports come from you. I you have reported some, please tell me which they are. Best regards, Georges. Tomas Hodek a écrit : Hi Georges, I have tried to enter log messages as requested (also included header fil
Bug#1020415: bcron-start terminated 111 status
Hi about acl, it is strange, since package acl was not installed (thought this package is required to manipulate acl) this was all tested on current stable version (0.11-9) getfacl crontabs/ # file: crontabs/ # owner: cron # group: cron # flags: --t user::rwx group::--- other::--- permissions before bcron install: drwx-wx--T 2 root crontab 4096 Feb 22 2021 crontabs so I chaneged them to: drwx-T 2 cron cron 4096 Sep 27 08:27 crontabs After upgrade to debian/testing acl changed: getfacl crontabs/ # file: crontabs/ # owner: root # group: crontab # flags: --t user::rwx user:cron:rwx group::-wx group:cron:rwx mask::rwx other::--- However I still get error in syslog: daemon: bcron-start: client (pid 798) exited with 111 status, exiting Also tried to chown whole directory as mentioned, but issue remains same. == Our issue with cron was not yet reported, since I did not found any regularity and have no test environment where I was able to reproduce this issue. Only thing I know for sure is the fact that cron process sometimes eats 1 whole CPU core and then jobs are not being executed correctly. Normal CPU usage is mere percents. Restart of daemon fixes it. Tomas On 26. 09. 22 19:01, Georges Khaznadar wrote: Hi Thomas, thank you for your investigation work. The modifications which I made, since version 0.11-9 which was maintained by Dmitri Bogdanov, are aiming to prepare a transition from cron (whose upstream is no longer maintained) to cronie (not for tomorrow, but at some time later). For such a transition to be feasible, all cron equivalents used in debian must share a common base, so now bcron depends on the package cron-daemon-common (like cron). However, bcron has a peculiarity: the directory /var/spool/cron/crontabs/ must be given to user cron and group cron, while other cron-like packages give this directory to user root and group crontab. In order to let users install cron-like packages back and forth, postinst and prerm routines of bcron are modifying access control lists (ACLs) when bcron is installed and when it is purged. From what you wrote, I suspect that the access control lists are not correctly tuned, so, maybe, schedulers cannot do exactly the same job when launched by systemd than when they are launched manually. I fair that the difference list between versions 0.09-13 and 0.11-17 may be too long to be useful. Please can you check whether the version 0.11-9 available in debian/stable can currently fulfill your needs? Another question, if you do not mind: please try to install the last version from testing (0.11-17), then make a: # chmod -R cron:cron /var/spool/cron/crontabs/ and check whether this can fix the spurious behavior? Thank you in advance for your feedback. = By the way, you wrote that you had been "forced to install bcron instead of default cron package since the default one sometimes failed to execute all configured jobs" ... Did you post bug reports about it, against cron? This package, whose popcon score is two thousand bigger than bcron, has a list of 87 open bugs. I began to fix a few of them four months ago, and my progress is slow, because I want to write a test for each bug I fix, in order to prevent regressions in the future. The page https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=cron does not allow me to view precisely whether some of the bug reports come from you. I you have reported some, please tell me which they are. Best regards, Georges. Tomas Hodek a écrit : Hi Georges, I have tried to enter log messages as requested (also included header files for syslog library), recompiled etc... But i am not able to get any relevant informations from syslog - nothing is written. Am I missing something? I have also made fresh install of debian 11 and even with no additional software bcron-start is exitting with 111 status. When upgraded to testing release same problem: apt-cache policy bcron bcron: Installed: 0.11-17 Candidate: 0.11-17 Version table: *** 0.11-17 550 500 http://deb.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status 0.11-9 500 500 http://deb.debian.org/debian bullseye/main amd64 Packages Tomas On 24. 09. 22 17:23, Georges Khaznadar wrote: Dear Thomas, can you give me more information? The error code 111 can be throwed from many parts of bcron's code, as you can see by launching `grep 111 *.c` in the directory of bcron's source. Most errors come with an informative string, like ... bcron-update.c:die1sys(111, "Could not change directory"); Some of them do not come with an extra string: -8<-- $ grep -n "111)" *.c bcron-exec.c:69:exit(111); bcron-exec.c:85:exit(111); bcron-exec.c:136: die_oom(111); bcron-exec.c:139: exit(111); bcron-exec.c:385:die_oom
Bug#1020415: bcron-start terminated 111 status
Hi Georges, I have tried to enter log messages as requested (also included header files for syslog library), recompiled etc... But i am not able to get any relevant informations from syslog - nothing is written. Am I missing something? I have also made fresh install of debian 11 and even with no additional software bcron-start is exitting with 111 status. When upgraded to testing release same problem: apt-cache policy bcron bcron: Installed: 0.11-17 Candidate: 0.11-17 Version table: *** 0.11-17 550 500 http://deb.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status 0.11-9 500 500 http://deb.debian.org/debian bullseye/main amd64 Packages Tomas On 24. 09. 22 17:23, Georges Khaznadar wrote: Dear Thomas, can you give me more information? The error code 111 can be throwed from many parts of bcron's code, as you can see by launching `grep 111 *.c` in the directory of bcron's source. Most errors come with an informative string, like ... bcron-update.c:die1sys(111, "Could not change directory"); Some of them do not come with an extra string: -8<-- $ grep -n "111)" *.c bcron-exec.c:69:exit(111); bcron-exec.c:85:exit(111); bcron-exec.c:136: die_oom(111); bcron-exec.c:139: exit(111); bcron-exec.c:385:die_oom(111); bcrontab.c:135:die_oom(111); bcron-update.c:147: die_oom(111); bcron-update.c:216:die_oom(111); crontabs.c:45: die_oom(111); job.c:34:die_oom(111); job.c:40:die_oom(111); -8<-- Unfortunately, I could not reproduce the bug you are describing. Maybe you can help me? It should be possible to send some message to syslog just before lines like bcron-exec.c:69:, bcron-exec.c:85:, and so on, by recompiling bcron-exec.c with some changes, like: syslog(LOG_ERR, "Hello, this is line 69"); exit(111); instead of : exit(111); in file bcron-exec.c, line 69, and so on. Then you should know better the reason why schedulers' child fails. Thank you in advance for any information about it. Best regards, Georges. Tomas Hodek a écrit : Package: bcron Version: 0.11-9 Severity: important Dear Maintainer, init script /etc/init.d/bcron-sched should start schedulers, but child fails with 111 status code. When launching /usr/sbin/bcron-start manually from terminal it runs successfully. Only relevant thing in syslog is: daemon: bcron-start: client (pid 2363945) exited with 111 status, exiting We have about 800 user crontabs in system, if it matters anything. On some older machine, we are using version 0.09-13 without any issues. However in the past we were also forced to install bcron instead of default cron package since the default one sometimes failed to execute all configured jobs. (bcron had no such as issue) -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/50 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 bcron depends on: ii libbg2 2.04+dfsg-2.1 ii libc6 2.31-13+deb11u3 ii runit-helper2.10.3 ii sysuser-helper 1.3.5.1 ii ucspi-unix 1.0-1 Versions of packages bcron recommends: ii daemon 0.7-1 ii postfix [mail-transport-agent] 3.5.13-0+deb11u1 ii runit 2.1.2-41 Versions of packages bcron suggests: pn anacron pn runit-init
Bug#1020415: bcron-start terminated 111 status
Package: bcron Version: 0.11-9 Severity: important Dear Maintainer, init script /etc/init.d/bcron-sched should start schedulers, but child fails with 111 status code. When launching /usr/sbin/bcron-start manually from terminal it runs successfully. Only relevant thing in syslog is: daemon: bcron-start: client (pid 2363945) exited with 111 status, exiting We have about 800 user crontabs in system, if it matters anything. On some older machine, we are using version 0.09-13 without any issues. However in the past we were also forced to install bcron instead of default cron package since the default one sometimes failed to execute all configured jobs. (bcron had no such as issue) -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/50 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 bcron depends on: ii libbg2 2.04+dfsg-2.1 ii libc6 2.31-13+deb11u3 ii runit-helper2.10.3 ii sysuser-helper 1.3.5.1 ii ucspi-unix 1.0-1 Versions of packages bcron recommends: ii daemon 0.7-1 ii postfix [mail-transport-agent] 3.5.13-0+deb11u1 ii runit 2.1.2-41 Versions of packages bcron suggests: pn anacron pn runit-init
Bug#1020279: hcloud-cli: please package a newer version (wish: --label suport)
Package: hcloud-cli Version: 1.13.0-2+b6 Severity: wishlist X-Debbugs-Cc: Thorsten Alteholz Hi, thanks for packaging hcloud-cli. I'd be glad if a more recent hcloud-cli version would be available in Debian, specifically one > 1.16, because that version supports the `--label` flag on server commands, which I need to do categorize Hetzner resources. Thanks for the hcloud package! *t -- System Information: Debian Release: 11.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-18-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hcloud-cli depends on: ii libc6 2.31-13+deb11u4 hcloud-cli recommends no packages. hcloud-cli suggests no packages. -- no debconf information
Bug#1019425: dkms 3.0.6-2 not signing modules
Hi,
On Wed, Sep 14, 2022 at 09:52:22PM +0200, Holger Schröder wrote:
The patch does not work for me. The modules are signed again with the
patch but at boot time they are not accepted and I end up at the
initramfs prompt. zfs module not loaded in my case.
Note that there have been several changes committed upstream related to
signing modules on Debian/Ubuntu: https://github.com/dell/dkms/compare/v3.0.6...master
Specifically,
https://github.com/dell/dkms/commit/8d60956f6dcda0679066954215eb8be4045413b4
and
https://github.com/dell/dkms/commit/3ca52f8769bdf7ebdc83735355fff7c5c0664152
look relevant here. Might be worth testing that in preference to the
patch posted here.
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1017761: java.lang.ClassNotFoundException: org.jpype.classloader.DynamicClassLoader
Package: python3-jpype
Version: 1.4.0-2
Severity: normal
Due to how the org.jpype.jar is packaged
(https://salsa.debian.org/python-team/packages/python-jpype/-/commit/44a8befe0b856609a4095f5d9e3979752e367ad8),
jpype.startJVM() doesn't work out of the box as documented in upstream
documentation:
$ python3 -c 'import jpype; jpype.startJVM()'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/jpype/_core.py", line 218, in
startJVM
_jpype.startup(jvmpath, tuple(args),
SystemError: java.lang.ClassNotFoundException:
org.jpype.classloader.DynamicClassLoader
This is because it's expected to be in
/usr/lib/python3/dist-packages/org.jpype.jar
(https://github.com/jpype-project/jpype/blob/24a2b95aefc2a59e7cf2c362a92ee5c6b13eb94f/native/common/jp_classloader.cpp#L74)
and Debian unfortunately only moves the jar, but doesn't patch jpype to
look for it in the new location.
As a workaround, one can explicitly add the jar to classpath:
$ python3 -c 'import jpype;
jpype.startJVM(classpath=["/usr/share/java/org.jpype.jar"])'
Unfortunately, this isn't documented anywhere.
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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-jpype depends on:
ii default-jre 2:1.11-72
ii default-jre-headless [java6-runtime-headless] 2:1.11-72
ii libc6 2.34-3
ii libgcc-s1 12.1.0-8
ii libstdc++612.1.0-8
ii openjdk-11-jre-headless [java6-runtime-headless] 11.0.16+8-1
ii python3 3.10.5-3
ii python3-numpy [python3-numpy-abi9]1:1.21.5-1+b1
python3-jpype recommends no packages.
python3-jpype suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#887035: cron: Patch by Greek adapted for cron 3.0pl1-137
Hi Georges, first off: this patch is completely irrelevant IMHO. We should not be discussing it. What's relevant is [1]. On Sun, 24 Jul 2022, Georges Khaznadar wrote: two remarks: 1) most of Greek's patches which you adapted is about making cron installable without the package syslog. That is what it claims but not what it does AFAICS. What it does is adapt the `log_it` function so that it takes a `priority` parameter. But again. This patch is irrelevant. [1] is relevant IMO. Were are the parts about "log-to-stdout-when-in-foreground"? It's at [2]. But it's irrelevant. [1] is relevant. I see that one patch modifies debian/patches/series, mentioning the file log-to-stdout-when-in-foreground, but that file is provided nowhere by the set of patches. Again see [2]. But it's irrelevant. [1] is relevant. By the way, do you know who is "Greek"? No She or he did not reply to questions which I submitted about Bug#887014 ... It's been 4 years since this bug has been filed so "Greek" might have moved on since. Is "Greek" a pseudonyme of yours? No 2) I shall not patch cron 3.0pl1-137. You can do it if you want, for your own usage, of course. If I modify debian's cron package, I must do it in the testing distribution, so please propose patches targetting at least cron 3.0pl1-147. Then, if the modification you are wishing is accepted in debian/testing, I can create a backport to use in debian/bullseye later, for example a release such as cron 3.0pl1-149~bpo11+1, to be published in bullseye-backports. Ack. However I do not want that patch to be included because as I said as far as I can see it does *not* activate output to STDOUT, contrary to what the origianl message by "Greek" claims. That patch is irrelevant, I have only posted it in case somebody is interested in using it. But I am *not* interested in it. I am interested in [1] only. Thanks! *t [1] - enable debugging logs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887035#15/ [2] - debian/patches: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=887035;filename=log-to-stdout-when-in-foreground;msg=25 Best regards, Georges. Tomas Pospisek a écrit : Package: cron Version: 3.0pl1-137 Followup-For: Bug #887035 X-Debbugs-Cc: Georges Khaznadar If anybody wants to use Greek's patch (see [1] and [2]) then I'm attaching my version of it adapted to cron 3.0pl1-137 (the version in Debian bullseye). It comes in two parts: one is the patch and one is cron-3.0pl1/debian/patches/log-to-stdout-when-in-foreground to satisfy the Debian build infrastructure. Use the patch like this to build a new, patched cron package: apt-get source cron sudo apt-get build-dep cron patch -p0 < cron-syslog-fix-and-foreground-stdout.for-new-cron.debianized.patch cp log-to-stdout-when-in-foreground cron-3.0pl1/debian/patches cd cron-3.0pl1 && dpkg-buildpackage -rfakeroot *t [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887035#5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=887035;filename=cron-syslog-fix-and-foreground-stdout.patch;msg=5 -- Package-specific info: --- EDITOR: --- /usr/bin/editor: /usr/bin/vim.gtk3 --- /usr/bin/crontab: -rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab --- /var/spool/cron: drwxr-xr-x 3 root root 4096 Apr 10 2021 /var/spool/cron --- /var/spool/cron/crontabs: drwx-wx--T 2 root crontab 4096 Feb 22 2021 /var/spool/cron/crontabs --- /etc/cron.d: drwxr-xr-x 2 root root 4096 Jul 22 15:03 /etc/cron.d --- /etc/cron.daily: drwxr-xr-x 2 root root 4096 Jul 11 09:33 /etc/cron.daily --- /etc/cron.hourly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.hourly --- /etc/cron.monthly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.monthly --- /etc/cron.weekly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.weekly -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cron depends on: ii adduser 3.118 ii debianutils 4.11.2 ii init-system-helpers 1.60 ii libc62.31-13+deb11u3 ii libpam-runtime 1.4.0-9+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libselinux1 3.1-3 ii lsb-base 11.1.0 ii sensible-utils 0.0.14 Versions of packages cron recommends: ii msmtp-mta [mail-transport-agent] 1.8.11-2.1 Versions of packages cron suggests: ii anacron2.3-30 pn checksecurity ii logrotate 3.18.0-2+deb11u1 Versions of packages cron is related to: pn libnss-l
Bug#887035: cron: one "easy" way to get cron output
Hello Georges, On Fri, 22 Jul 2022, Georges Khaznadar wrote: Would it seem reasonable, for your needs, to find two separate binary packages in Debian, "cron" and let us say, "cron-debug"? Both package would be built from the same source, the first one with no special build parameter, the second one with debugging activated (and output to stdout activated by the switch -f)? * yes, having a separate package would be fine * in case you want to go with a separate package than I'd suggest `cron-log-to-stderr` as the name because that makes it explicit what that package is about. * however why not keep it in one single package and just make the debug feature available? * as is the `-f` switch will *not* activate output to STDOUT. The patch provided by `Greek` [1] does *not* make `-f` log to STDOUT (instead the main function of the patch is to add the `priority` parameter to the `log_it` function that does the logging to STDERR and to syslog). * the command line option that switches on logging to STDERR is `-x what_to_log`. Again, I'd argue to make the `-x` aka "debugging output" *feature* available by default (it will *not* make cron log to STDERR by default. That needs to be done explicitly by supplying the `-x` switch) and continue with a single package. It there any technical reason why the "debugging output" *feature* should not be available? Thanks a lot for caring about this issue! *t [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=887035;filename=cron-syslog-fix-and-foreground-stdout.patch;msg=5 (I've snipped off the rest of the toplevel posting.)
Bug#887035: cron: Patch by Greek adapted for cron 3.0pl1-137
Package: cron
Version: 3.0pl1-137
Followup-For: Bug #887035
X-Debbugs-Cc: Georges Khaznadar
If anybody wants to use Greek's patch (see [1] and [2]) then I'm attaching my
version of it adapted to cron 3.0pl1-137 (the version in Debian bullseye).
It comes in two parts: one is the patch and one is
cron-3.0pl1/debian/patches/log-to-stdout-when-in-foreground to satisfy
the Debian build infrastructure.
Use the patch like this to build a new, patched cron package:
apt-get source cron
sudo apt-get build-dep cron
patch -p0 <
cron-syslog-fix-and-foreground-stdout.for-new-cron.debianized.patch
cp log-to-stdout-when-in-foreground cron-3.0pl1/debian/patches
cd cron-3.0pl1 && dpkg-buildpackage -rfakeroot
*t
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887035#5
[2]
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=887035;filename=cron-syslog-fix-and-foreground-stdout.patch;msg=5
-- Package-specific info:
--- EDITOR:
--- /usr/bin/editor:
/usr/bin/vim.gtk3
--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab
--- /var/spool/cron:
drwxr-xr-x 3 root root 4096 Apr 10 2021 /var/spool/cron
--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Feb 22 2021 /var/spool/cron/crontabs
--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Jul 22 15:03 /etc/cron.d
--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Jul 11 09:33 /etc/cron.daily
--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.hourly
--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.monthly
--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.weekly
-- System Information:
Debian Release: 11.4
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8),
LANGUAGE=de_CH:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cron depends on:
ii adduser 3.118
ii debianutils 4.11.2
ii init-system-helpers 1.60
ii libc62.31-13+deb11u3
ii libpam-runtime 1.4.0-9+deb11u1
ii libpam0g 1.4.0-9+deb11u1
ii libselinux1 3.1-3
ii lsb-base 11.1.0
ii sensible-utils 0.0.14
Versions of packages cron recommends:
ii msmtp-mta [mail-transport-agent] 1.8.11-2.1
Versions of packages cron suggests:
ii anacron2.3-30
pn checksecurity
ii logrotate 3.18.0-2+deb11u1
Versions of packages cron is related to:
pn libnss-ldap
pn libnss-ldapd
pn libpam-ldap
pn libpam-mount
pn nis
pn nscd
-- no debconf information
diff -u -r orig/cron-3.0pl1/cron.c cron-3.0pl1/cron.c
--- orig/cron-3.0pl1/cron.c 2022-07-19 12:18:36.0 +0200
+++ cron-3.0pl1/cron.c 2022-07-19 14:24:39.0 +0200
@@ -122,12 +122,12 @@
} else if (!stay_foreground) {
switch (fork()) {
case -1:
- log_it("CRON",getpid(),"DEATH","can't fork");
+ log_it(LOG_ERR, "CRON",getpid(),"DEATH","can't fork");
exit(0);
break;
case 0:
/* child process */
- log_it("CRON",getpid(),"STARTUP","fork ok");
+ log_it(LOG_INFO, "CRON",getpid(),"STARTUP","fork ok");
(void) setsid();
freopen("/dev/null", "r", stdin);
freopen("/dev/null", "w", stdout);
@@ -281,18 +281,18 @@
/* Run on actual reboot, rather than cron restart */
if (access(REBOOT_FILE, F_OK) == 0) {
/* File exists, return */
- log_it("CRON", getpid(),"INFO",
+ log_it(LOG_INFO, "CRON", getpid(),"INFO",
"Skipping @reboot jobs -- not system startup");
return;
}
/* Create the file */
if ((rbfd = creat(REBOOT_FILE, S_IRUSR & S_IWUSR)) < 0) {
/* Bad news, bail out */
- log_it("CRON",getpid(),"DEATH","Can't create reboot check
file");
+ log_it(LOG_ERR, "CRON",getpid(),"DEATH","Can't create reboot
check file");
exit(0);
} else {
close(rbfd);
- log_it("CRON", getpid(),"INFO", "Running @reboot jobs");
+ log_it(LOG_INFO, "CRON", getpid(),"INFO", "Running @reboot
jobs");
}
Debug(DMISC, ("[%d], running reboot jobs\n", getpid()));
for (u = db->head; u != NULL; u = u->next) {
diff -u -r orig/cron-3.0pl1/cron.h cron-3.0pl1/cron.h
--- orig/cron-3.0pl1/cron.h 2022-07-19 12:18:36.0 +0200
+++ cron-3.0pl1/cron.h 2022-07-19 14:24:39.0 +0200
@@ -144,6 +144,20 @@
#define
Bug#887035: cron: one "easy" way to get cron output
Package: cron Version: 3.0pl1-137 Followup-For: Bug #887035 X-Debbugs-Cc: Greek , Javier Fernández-Sanguino Peña , Georges Khaznadar Instead of patching cron, an easy way to get cron output to stdout is to: * rebuild it with debugging enabled: $ apt-get source cron $ apt-get build-dep cron $ cd cron-3.0pl1 $ DEB_BUILD_OPTIONS=debug dpkg-buildpackage -rfakeroot * use the undocumented `-x` option of Debian's cron to start it: # cron -f -L 15 -x misc (I found the `misc` debug log the most suiting) * wrap the whole thing to redirect stderr to stdout: $ cat run-cron #!/bin/sh exec cron -f -L 15 -x misc 2>&1 @Georges Khaznadar : what do you think about: 1. enabling debugging by default? 2. documenting `-x` ? If Debian would enable the "debbugging feature" of its cron by default, then this would add this overhead in a few places: if ( (DebugFlags & (mask) ) ) printf message; Since DebugFlags is 0 by default, this will ad an overhead of about two machine instructions I guess to a few places, which is a neglible waste/slowdown IMHO. With the "debugging feature" enabled Debian's cron will gain the very nice features: a) for the sysadmin to be able to debug what cron is doing and why and b) use the sysadmin being able to use Debian's cron in docker and kubernetes. IMHO a huge gain that costs nothing. ? *t -- Package-specific info: --- EDITOR: --- /usr/bin/editor: /usr/bin/vim.gtk3 --- /usr/bin/crontab: -rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab --- /var/spool/cron: drwxr-xr-x 3 root root 4096 Apr 10 2021 /var/spool/cron --- /var/spool/cron/crontabs: drwx-wx--T 2 root crontab 4096 Feb 22 2021 /var/spool/cron/crontabs --- /etc/cron.d: drwxr-xr-x 2 root root 4096 Jul 22 15:03 /etc/cron.d --- /etc/cron.daily: drwxr-xr-x 2 root root 4096 Jul 11 09:33 /etc/cron.daily --- /etc/cron.hourly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.hourly --- /etc/cron.monthly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.monthly --- /etc/cron.weekly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.weekly -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cron depends on: ii adduser 3.118 ii debianutils 4.11.2 ii init-system-helpers 1.60 ii libc62.31-13+deb11u3 ii libpam-runtime 1.4.0-9+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libselinux1 3.1-3 ii lsb-base 11.1.0 ii sensible-utils 0.0.14 Versions of packages cron recommends: ii msmtp-mta [mail-transport-agent] 1.8.11-2.1 Versions of packages cron suggests: ii anacron2.3-30 pn checksecurity ii logrotate 3.18.0-2+deb11u1 Versions of packages cron is related to: pn libnss-ldap pn libnss-ldapd pn libpam-ldap pn libpam-mount pn nis pn nscd -- no debconf information
Bug#1014631: docker.io: No networking in rootless docker with firewalld
Hi,
On Sat, Jul 09, 2022 at 05:01:55PM +0800, Shengjing Zhu wrote:
I just checked that Docker 22.06 has bumped godbus to 5.0.6,
https://github.com/moby/moby/blob/22.06/vendor.mod
So it would be an issue for upstream too.
We will backport patch if they fix it in the 22.06 branch.
Fixed in master: https://github.com/moby/moby/pull/43793
Cherry-picked into 22.06: https://github.com/moby/moby/pull/43813
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1014631: docker.io: No networking in rootless docker with firewalld
Hi,
On Sat, Jul 09, 2022 at 05:01:55PM +0800, Shengjing Zhu wrote:
I just checked that Docker 22.06 has bumped godbus to 5.0.6,
https://github.com/moby/moby/blob/22.06/vendor.mod
So it would be an issue for upstream too.
Indeed they have. I must've been looking at an outdated vendor.conf,
silly me. I'll try to reproduce the issue with moby master and update
the upstream report accordingly. Thanks for pointing this out!
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1014631: docker.io: No networking in rootless docker with firewalld
Package: docker.io
Version: 20.10.14+dfsg1-1+b1
Severity: normal
Dear Maintainer,
When running the docker daemon rootless, it still attempts to detect and
use firewalld. If it succeeds (and with the godbus/dbus Debian builds
against, it does; more on that later), iptables rules for NAT (necessary
for traffic to be routed out of the docker0 bridge) are set up in the
host network namespace instead of the network namespace dockerd runs in,
so networking doesn't work. This is what the traffic looks like on the
slirp4netns tap0 in the dockerd namespace:
15:30:41.600319 IP 172.17.0.2.52323 > 10.0.2.3.53: 1825+ A? deb.debian.org.
(32)
15:30:41.606028 ARP, Request who-has 172.17.0.2 tell 10.0.2.2, length 28
No reply, obviously, 172.17.0.2 is connected to the bridge, it's meant
to be masqueraded when forwarded to tap0.
Running
nsenter -U --preserve-credentials -n -m -t $(cat
$XDG_RUNTIME_DIR/docker.pid) /usr/sbin/iptables-save
gives no output whatsoever, because there are no rules inside the net namespace.
Now the important bit: this issue can only be reproduced with
godbus/dbus 5.0.5+ which it's built against in Debian, but docker/moby
upstream vendors 5.0.3 so the issue isn't reproducible with their
builds. The reason older godbus/dbus "works" is because it fails to
connect to dbus from inside the _user_ namespace. This is because it's
uid 0 in that namespace, it tells dbus it's uid 0 (AUTH EXTERNAL
30\r\n), and from dbus' point of view it's obviously not uid 0, so it
rejects the connection, and dockerd thinks there's no firewalld and
correctly uses iptables as it should inside a network namespace.
But this auth issue is "fixed" in godbus/dbus 5.0.5
(https://github.com/godbus/dbus/pull/265), so if docker is built with
that (it is in Debian), network doesn't work inside any containers.
I've reported the issue upstream nonetheless: https://github.com/moby/moby/issues/43781,
as I believe firewalld detection shouldn't be attempted at all when
running in rootless mode, as it makes no sense to set up iptables rules
in the host network namespace while the bridge is in another network
namespace. It will probably (understandably) be low-priority for them
since it happens to work fine with the version of godbus/dbus they
vendor in the moby repo. So it might be worth coming up with a fix in
Debian, as it's Debian packaging of docker breaking things now.
It's also worth noting that there is a workaround: when I create a shell
wrapper for dockerd which does mount --bind /dev/null /run/dbus/system_bus_socket
before invoking dockerd, networking works again, and nothing else seems
to break (I haven't done much testing though, it may break still).
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages docker.io depends on:
ii adduser 3.121
ii containerd 1.6.6~ds1-1
ii init-system-helpers 1.64
ii iptables 1.8.8-1
ii libc62.33-7
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libsystemd0 251.2-7
ii lsb-base 11.2
ii runc 1.1.3+ds1-2
ii tini 0.19.0-1
Versions of packages docker.io recommends:
ii apparmor 3.0.4-2
ii ca-certificates 20211016
pn cgroupfs-mount
ii git 1:2.35.1-1
pn needrestart
ii xz-utils 5.2.5-2.1
Versions of packages docker.io suggests:
pn aufs-tools
ii btrfs-progs5.18.1-1
ii debootstrap1.0.126+nmu1
pn docker-doc
ii e2fsprogs 1.46.5-2
pn rinse
ii rootlesskit1.0.1-1
pn xfsprogs
pn zfs-fuse | zfsutils-linux
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1011128: cryptsetup-suspend: key-slot in crypttab leads to infinite wall of errors when resuming
Package: cryptsetup-suspend
Version: 2:2.4.3-1
Severity: normal
cryptsetup luksResume doesn't accept --key-slot according to the manpage
and indeed, when /usr/lib/cryptsetup/functions:resume_mapping supplies
that option, cryptsetup immediately fails and
/usr/lib/cryptsetup/functions:resume_device just loops forever.
(I have no idea why cryptsetup luksResume doesn't accept --key-slot or
if it ever did, and I suspect the absence of that option makes resume
slower than it needs to be, but slow resume is better than no resume… :-))
-- Package-specific info:
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 cryptsetup-suspend depends on:
ii cryptsetup-initramfs 2:2.4.3-1
ii initramfs-tools-core 0.141
ii kbd 2.3.0-3
ii libc6 2.33-7
ii libcryptsetup12 2:2.4.3-1
ii systemd 250.4-1
cryptsetup-suspend recommends no packages.
cryptsetup-suspend suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1011026: linux-headers-amd64: cannot install/upgrade to 5.17.6 on amd64
Package: linux-headers-amd64
Version: 5.17.6-1
Severity: normal
linux-headers-amd64=5.17.6-1 depends on linux-headers-5.17.0-2-amd64=5.17.6-1,
but there's only 5.17.6-1+b1 in the amd64 archive as of today.
This results in:
# apt install linux-headers-5.17.0-2-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
linux-headers-amd64 (5.17.6-1)
The following packages will be upgraded:
linux-headers-5.17.0-2-amd64 (5.17.6-1 => 5.17.6-1+b1)
1 upgraded, 0 newly installed, 1 to remove and 84 not upgraded.
Need to get 963 kB of archives.
After this operation, 12.3 kB disk space will be freed.
On another Debian instance, where linux-headers-amd64 is still at
5.17.3-1, it looks like this:
# apt install linux-image-amd64 linux-headers-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
linux-headers-amd64 : Depends: linux-headers-5.17.0-2-amd64 (= 5.17.6-1)
but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
# apt policy linux-headers-5.17.0-2-amd64
linux-headers-5.17.0-2-amd64:
Installed: (none)
Candidate: 5.17.6-1+b1
Version table:
5.17.6-1+b1 990
500 https://deb.debian.org/debian unstable/main amd64 Packages
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 linux-headers-amd64 depends on:
ii linux-headers-5.17.0-2-amd64 5.17.6-1
linux-headers-amd64 recommends no packages.
linux-headers-amd64 suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1010599: "org.gnome.Shell@x11.service: Stop job pending for unit, delaying automatic restart." filling disk
Package: gnome-shell-common
Version: 3.38.6-1~deb11u1
Severity: normal
Tags: patch
Dear Maintainer,
TL;DR: org.gnome.Shell@x11.service wants to restart after 0ms, but fails -
filling disk. Please increase to at least a few milliseconds.
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I think the X server was killed, pulseaudio logged:
pulseaudio[350117]: X connection to :1 broken (explicit kill or server
shutdown).
Then org.gnome.Shell@x11.service wanted to restart and RestartSec=0ms in
/lib/systemd/user/org.gnome.Shell@x11.service causes filled logs.
This happens "sometimes" in our computer labs (we have about 100
student computers).
* What exactly did you do (or not do) that was effective (or
ineffective)?
Don't know exactly what happened, but the result log spamming is a DoS.
* What was the outcome of this action?
This time - during the first ~2 minutes, the following log message was repeated
4 million times (half a gigabyte) before giving up:
2022-05-05T09:39:17+02:00 ochre systemd[350085]: org.gnome.Shell@x11.service:
Stop job pending for unit, delaying automatic restart.
2022-05-05T09:39:17+02:00 ochre systemd[350085]: org.gnome.Shell@x11.service:
Stop job pending for unit, delaying automatic restart.
... 4 million identical lines later ...
2022-05-05T09:41:29+02:00 ochre systemd[350085]: org.gnome.Shell@x11.service:
Stop job pending for unit, delaying automatic restart.
2022-05-05T09:41:29+02:00 ochre systemd[350085]: org.gnome.Shell@x11.service:
Stop job pending for unit, delaying automatic restart.
2022-05-05T09:41:29+02:00 ochre systemd[350085]: Looping too fast. Throttling
execution a little.
2022-05-05T09:41:29+02:00 ochre systemd[1]: user@{user-id}.service: State
'stop-sigterm' timed out. Killing.
2022-05-05T09:41:29+02:00 ochre systemd[1]: user@{user-id}.service: Killing
process 350085 (systemd) with signal SIGKILL.
2022-05-05T09:41:29+02:00 ochre systemd[1]: user@{user-id}.service: Killing
process 350506 (gsd-smartcard) with signal SIGKILL.
... more processes killed ...
/lib/systemd/user/org.gnome.Shell@x11.service has:
# Do not wait before restarting the shell
RestartSec=10ms
# Kill any stubborn child processes after this long
TimeoutStopSec=5
My guess is that it took 2 minutes to give up instead of 5 seconds, because it
was busy spamming these log messages.
* What outcome did you expect instead?
"A few" log messages before giving up.
Attached is a patch to change from 0ms to 10ms, which should give no
user-noticable slowdown but would in this case reduce the amount of log
messages from 4 million to either about 13k (100/s for just over 2 minutes) or
to 500 (100/s for 5s if it gives up when it should).
The patch does not fix the original problem, but should reduce problems caused
by it.
-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-14-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC,
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/bash
Init: systemd (via /run/systemd/system)
Versions of packages gnome-shell-common depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2
gnome-shell-common recommends no packages.
gnome-shell-common suggests no packages.
-- no debconf information
--- org.gnome.Shell@x11.service-orig2022-05-05 10:24:01.996927942 +0200
+++ org.gnome.Shell@x11.service 2022-05-05 10:24:21.300877802 +0200
@@ -34,6 +34,6 @@
# On X11 we want to restart on-success (Alt+F2 + r) and on-failure.
Restart=always
# Do not wait before restarting the shell
-RestartSec=0ms
+RestartSec=10ms
# Kill any stubborn child processes after this long
TimeoutStopSec=5
Bug#1004837: XFCE Window Buttons not visible after Debian upgrade
Hi,
Apologies, the debdiff I just sent have wrong date info in a patch tag.
The patch currently attached should be ok.
With regards,
Tomas "trosos" Tinteradiff -Nru xfce4-panel-4.16.2/debian/changelog xfce4-panel-4.16.2/debian/changelog
--- xfce4-panel-4.16.2/debian/changelog 2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/changelog 2022-04-28 16:20:27.0 +0200
@@ -1,3 +1,10 @@
+xfce4-panel (4.16.2-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix upstream bug #188: some windows do not appear in the panel.
+
+ -- Tomas Tintera Thu, 28 Apr 2022 16:20:27 +0200
+
xfce4-panel (4.16.2-1) unstable; urgency=medium
* New upstream version 4.16.2
diff -Nru xfce4-panel-4.16.2/debian/patches/series xfce4-panel-4.16.2/debian/patches/series
--- xfce4-panel-4.16.2/debian/patches/series 2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/series 2022-04-28 16:20:27.0 +0200
@@ -1,2 +1,3 @@
01_support-non-multiarch-modules.patch
02_pager-size-for-viewport.patch
+03_disconnect-size-allocate.patch
diff -Nru xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch
--- xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch 1970-01-01 01:00:00.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch 2022-04-28 16:20:27.0 +0200
@@ -0,0 +1,46 @@
+Origin: upstream, https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/66/diffs
+Date: Thu, 28 Apr 2022 16:20:27 +0200
+Subject: Fix some window buttons not appearing in the panel
+
+This is a backport of an upstream fix to odd behavior of the tasklist widget
+where closing a window would not reposition remaining window buttons and/or
+where new window buttons would not appear.
+
+Bug-Debian: https://bugs.debian.org/1004837
+Bug: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188
+Applied-Upstream: https://gitlab.xfce.org/xfce/xfce4-panel/-/commit/9881894b9588d36da69901f15215009c8debf1ac
+
+---
+
+--- xfce4-panel-4.16.2.orig/plugins/tasklist/tasklist-widget.c
xfce4-panel-4.16.2/plugins/tasklist/tasklist-widget.c
+@@ -2871,20 +2871,6 @@ xfce_tasklist_button_geometry_changed2 (
+
+
+
+-static gboolean
+-xfce_tasklist_button_size_allocate (GtkWidget *widget,
+-GdkRectangle *allocation,
+-gpointer user_data)
+-{
+- XfceTasklistChild *child = user_data;
+- /* Make sure the icons have the correct size */
+- xfce_tasklist_button_icon_changed (child->window, child);
+-
+- return TRUE;
+-}
+-
+-
+-
+ #ifdef GDK_WINDOWING_X11
+ static void
+ xfce_tasklist_button_geometry_changed (WnckWindow*window,
+@@ -3560,8 +3546,6 @@ xfce_tasklist_button_new (WnckWindow *
+ G_CALLBACK (xfce_tasklist_button_button_release_event), child);
+
+ /* monitor window changes */
+- g_signal_connect (G_OBJECT (child->button), "size-allocate",
+- G_CALLBACK (xfce_tasklist_button_size_allocate), child);
+ g_signal_connect (G_OBJECT (window), "icon-changed",
+ G_CALLBACK (xfce_tasklist_button_icon_changed), child);
+ g_signal_connect (G_OBJECT (window), "name-changed",
Bug#1004837: XFCE Window Buttons not visible after Debian upgrade
Control: tags -1 + patch
Control: tags -1 + fixed-upstream
Hi maintainer,
having the same upgrade experience as the original poster, this prevents me
from promoting users to upgrade yet.
This is probably an upstream bug #188, which has been fixed this February:
https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188
Could you please backport the upstream fix, as in the provided debpatch?
Best regards,
Tomasdiff -Nru xfce4-panel-4.16.2/debian/changelog xfce4-panel-4.16.2/debian/changelog
--- xfce4-panel-4.16.2/debian/changelog 2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/changelog 2022-04-28 16:20:27.0 +0200
@@ -1,3 +1,10 @@
+xfce4-panel (4.16.2-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix upstream bug #188: some windows do not appear in the panel.
+
+ -- Tomas Tintera Thu, 28 Apr 2022 16:20:27 +0200
+
xfce4-panel (4.16.2-1) unstable; urgency=medium
* New upstream version 4.16.2
diff -Nru xfce4-panel-4.16.2/debian/patches/series xfce4-panel-4.16.2/debian/patches/series
--- xfce4-panel-4.16.2/debian/patches/series 2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/series 2022-04-28 16:20:27.0 +0200
@@ -1,2 +1,3 @@
01_support-non-multiarch-modules.patch
02_pager-size-for-viewport.patch
+03_disconnect-size-allocate.patch
diff -Nru xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch
--- xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch 1970-01-01 01:00:00.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch 2022-04-28 16:20:27.0 +0200
@@ -0,0 +1,46 @@
+Origin: upstream, https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/66/diffs
+Date: Thu, 31 Oct 2019 17:20:31 +0100
+Subject: Fix some window buttons not appearing in the panel
+
+This is a backport of an upstream fix to odd behavior of the tasklist widget
+where closing a window would not reposition remaining window buttons and/or
+where new window buttons would not appear.
+
+Bug-Debian: https://bugs.debian.org/1004837
+Bug: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188
+Applied-Upstream: https://gitlab.xfce.org/xfce/xfce4-panel/-/commit/9881894b9588d36da69901f15215009c8debf1ac
+
+---
+
+--- xfce4-panel-4.16.2.orig/plugins/tasklist/tasklist-widget.c
xfce4-panel-4.16.2/plugins/tasklist/tasklist-widget.c
+@@ -2871,20 +2871,6 @@ xfce_tasklist_button_geometry_changed2 (
+
+
+
+-static gboolean
+-xfce_tasklist_button_size_allocate (GtkWidget *widget,
+-GdkRectangle *allocation,
+-gpointer user_data)
+-{
+- XfceTasklistChild *child = user_data;
+- /* Make sure the icons have the correct size */
+- xfce_tasklist_button_icon_changed (child->window, child);
+-
+- return TRUE;
+-}
+-
+-
+-
+ #ifdef GDK_WINDOWING_X11
+ static void
+ xfce_tasklist_button_geometry_changed (WnckWindow*window,
+@@ -3560,8 +3546,6 @@ xfce_tasklist_button_new (WnckWindow *
+ G_CALLBACK (xfce_tasklist_button_button_release_event), child);
+
+ /* monitor window changes */
+- g_signal_connect (G_OBJECT (child->button), "size-allocate",
+- G_CALLBACK (xfce_tasklist_button_size_allocate), child);
+ g_signal_connect (G_OBJECT (window), "icon-changed",
+ G_CALLBACK (xfce_tasklist_button_icon_changed), child);
+ g_signal_connect (G_OBJECT (window), "name-changed",
Bug#1008813: ITP: cargo-strip -- subcommand that reduces the size of Rust binaries
On 02.04.22 03:46, Josenilson Ferreira da Silva wrote: Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com * Package name: cargo-strip Version : 0.2.2 Upstream Author : Guillaume Valadon * URL : https://github.com/guedou/cargo-strip/issues * License : MIT/X, Programming Lang: rust Description : subcommand that reduces the size of Rust binaries subcommand that reduces the size of Rust binaries As of Rust 1.59, the charge command is now able to remove a binary. This can be activated in your Cargo.toml. "the charge command is now able to remove a binary". You mean like `rm /usr/local/bin/foobar`? I /think/ that's not what you wanted to express? *t
Bug#1008575: Wi-Fi works with loglevel=3 but not without
I wrote: Wi-Fi stops working after upgrading from -12- to linux-image-5.10.0-13-amd64 (iwlwifi: probe of :00:14.3 failed with error -110)) So in order to get more debug info, I set `loglevel=3` in grub in the kernel command line. That changed two things: * now while booting I get to see the line on screen: iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) That wouldn't get displayed previously when booting without `loglevel=3` * now Wi-Fi actually works! kernel logs say: Mar 29 09:03:29 enfi kernel: [4.631274] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-59.ucode Mar 29 09:03:29 enfi kernel: [4.631282] iwlwifi :00:14.3: api flags index 2 larger than supported by driver Mar 29 09:03:29 enfi kernel: [4.631290] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 65.3.35.22 Mar 29 09:03:29 enfi kernel: [4.631539] iwlwifi :00:14.3: loaded firmware version 59.601f3a66.0 QuZ-a0-hr-b0-59.ucode op_mode iwlmvm Mar 29 09:03:29 enfi kernel: [4.631551] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) [...] Mar 29 09:03:29 enfi kernel: [4.893787] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x354 Repeatedly switching back and forth between booting kernel ...-13 with or without `loglevel=3` will alternate between working and non-working Wi-Fi. *t On Mon, 28 Mar 2022, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1008575: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008575. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 1008...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 1008575: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008575 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1008575: linux-image-5.10.0-13-amd64: Wi-Fi stops working after upgrading from -12- to linux-image-5.10.0-13-amd64 (iwlwifi: probe of 0000:00:14.3 failed with error -110)
Package: src:linux Version: 5.10.106-1 Severity: important Dear Kernel maintainers and other Debian users that maybe have the same problem, After upgrading from linux-image-5.10.0-12-amd64 to linux-image-5.10.0-13-amd64 the iwlwifi is unable to initialise the Intel Corporation Wi-Fi 6 AX201 (rev 20) Wi-Fi device. Before: [4.549794] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-59.ucode [4.549800] iwlwifi :00:14.3: api flags index 2 larger than supported by driver [4.549808] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 65.3.35.22 [4.550084] iwlwifi :00:14.3: loaded firmware version 59.601f3a66.0 QuZ-a0-hr-b0-59.ucode op_mode iwlmvm [4.550099] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) After: [4.481502] iwlwifi: probe of :00:14.3 failed with error -110 The bug looks remotely similar to: https://bugs.debian.org/976110 https://bugs.debian.org/1003026 https://bugs.debian.org/976110 I've given the bug the severity: important, because this laptop is mostly used for being online and thus without that function is becomes more or less useless. I'll check whether I find something upstream. And report back. *t -- Package-specific info: ** Version: Linux version 5.10.0-12-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.2) #1 SMP Debian 5.10.103-1 (2022-03-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-12-amd64 root=UUID=2fd78bce-bb85-4405-82b5-2779947d695e ro quiet ** Not tainted ** Kernel log: ** Model information sys_vendor: HP product_name: HP ENVY Laptop 17-cg1xxx product_version: Type1ProductConfigId chassis_vendor: HP chassis_version: Chassis Version bios_vendor: Insyde bios_version: F.12 board_vendor: HP board_name: 8822 board_version: 49.36 ** Loaded modules: ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg bnep binfmt_misc dm_crypt dm_mod snd_soc_skl_hda_dsp snd_soc_hdac_hdmi snd_soc_dmic mei_hdcp intel_rapl_msr x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_sof_xtensa_dsp snd_sof snd_sof_intel_hda snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi irqbypass ledtrig_audio intel_cstate intel_uncore snd_hda_intel joydev snd_intel_dspcfg soundwire_intel soundwire_generic_allocation btusb iwlmvm snd_soc_core btrtl btbcm btintel snd_compress pcspkr soundwire_cadence bluetooth mac80211 serio_raw efi_pstore hp_wmi snd_hda_codec libarc4 wmi_bmof snd_hda_core snd_hwdep iwlwifi soundwire_bus uvcvideo jitterentropy_rng snd_pcm videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common drbg snd_timer videodev snd ansi_cprng iTCO_wdt intel_pmc_bxt iTCO_vendor_support cfg80211 ee1004 watchdog soundcore ecdh_generic mmc_block mc ecc mei_me mei rfkill hid_multitouch ucsi_acpi processor_thermal_device typec_ucsi intel_rapl_common intel_soc_dts_iosf typec tpm_crb int3403_thermal tpm_tis int340x_thermal_zone tpm_tis_core ac tpm intel_hid sparse_keymap rng_core soc_button_array int3400_thermal acpi_pad evdev acpi_thermal_rel intel_pmc_core msr parport_pc ppdev lp parport fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod i915 i2c_algo_bit nvme crc32_pclmul spi_pxa2xx_platform crc32c_intel drm_kms_helper nvme_core hid_generic dw_dmac ahci dw_dmac_core libahci t10_pi rtsx_pci_sdmmc ghash_clmulni_intel crc_t10dif libata mmc_core cec crct10dif_generic drm aesni_intel scsi_mod xhci_pci xhci_hcd libaes crct10dif_pclmul crypto_simd crct10dif_common usbcore cryptd glue_helper vmd rtsx_pci i2c_i801 intel_lpss_pci i2c_smbus intel_lpss idma64 usb_common i2c_hid fan wmi hid battery video button ** PCI devices: :00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01) Subsystem: Hewlett-Packard Company 11th Gen Core Processor Host Bridge/DRAM Registers [103c:8822] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- :00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Iris Xe Graphics [103c:8822] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915
Bug#1006738: vpnc-scripts: doesn't detect systemd-resolved, overwrites stub /etc/resolv.conf instead
Package: vpnc-scripts
Version: 0.1~git20210402-1
Severity: normal
Tags: patch upstream
vpnc-script uses the deprecated /usr/bin/systemd-resolve command which
is no longer shipped in Debian's systemd (the new one is called
resolvectl), so vpnc-script fails to detect resolved and overwrites
/etc/resolv.conf instead. This then results in the changes not coming
into effect as most apps use libnss_resolve directly instead of
/etc/resolv.conf.
(Also, it fails to reverse the changes later, but this may be just
because I don't run it as root. There's no such problem when resolved is
detected, though.)
There's a pending merge request to upstream which fixes the issue here:
https://gitlab.com/openconnect/vpnc-scripts/-/merge_requests/38
I've pinged them to merge it, but it might be sensible to apply it to
Debian if they don't as Debian is one of the first distros to drop the
compat systemd-resolve symlink.
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 vpnc-scripts depends on:
ii iproute2 5.16.0-2
ii net-tools 1.60+git20181103.0eebece-1
vpnc-scripts recommends no packages.
Versions of packages vpnc-scripts suggests:
pn dnsmasq
ii openssh-server 1:8.8p1-1
pn resolvconf
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#782181: shutter: The Shutter windows lack distinguishing X roles and instance names
Unfortunately I have taken the Wayland plunge since I opened that bug request, which means I can no longer use Shutter for screenshots, nor do I have it installed. To check if this has been fixed, just open Shutter and open some dialogs, then check all their class IDs, instance IDs and roles using "xprop". If they have distinguishable instance IDs or roles so they can be targeted and treated differently by the WM, then this bug is fixed. -- *Tomas E. Sandven* On Mon, Feb 21, 2022 at 1:42 AM Paul Wise wrote: > On Thu, 09 Apr 2015 04:46:18 +0200 Tomas Sandven wrote: > > > I am trying to configure the way Shutter acts in my i3 window manager. I > > want to specify the main Shutter window, the one with "Session" in the > > title, but all the windows in Shutter have the same X instance name and > > class name, and none of them have a role (WM_WINDOW_ROLE) specified. > > A new version of shutter was reintroduced into Debian unstable. Please > install it and check if the issue still occurs. If it still occurs, > please file a new bug with the upstream project on GitHub and let us > know the bug URL or mark the bug as forwarded yourself. If the issue no > longer occurs please let us know or close the bug yourself. > > https://shutter-project.org/contribute/ > https://www.debian.org/Bugs/server-control > https://www.debian.org/Bugs/Developer#closing > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Bug#991597: pulseaudio: Please enable GStreamer support
Hi all,
On Wed, Aug 04, 2021 at 09:55:44AM +0200, Laurent Bigonville wrote:
Le 3/08/21 à 18:46, Felipe Sateler a écrit :
Does that mean that enabling it, would only add some dependencies
but not actually do anything?
Yes, a (soft) dependency should probably be added against
gstreamer1.0-plugins-bad, but as I said, the needed version (>= 1.19)
is not yet in debian
There's gstreamer 1.20 in unstable and testing now, so there's a chance
it would finally do something useful if enabled. :-)
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#915379: anacron.service: should probably use KillMode=process
Hi again,
On Sat, Dec 25, 2021 at 08:27:58PM +, Tomas Janousek wrote:
This entry in the systemd 250 NEWS gives me hope this might be fixed
in a nice way eventually:
* A new service unit file setting ExitType= has been added that
specifies when to assume a service has exited. By default systemd
only watches the main process of a service. By setting
ExitType=cgroup it can be told to wait for the last process in a
cgroup instead.
I'll probably experiment with it once systemd 250 lands in testing,
unless someone beats me to it.
I can confirm that using ExitType=cgroup fixes the issue as well—systemd
now waits for all processes spawned by anacron to exit.
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1003887: terminology: outputs error on start: Could not fetch a node located at 0x40000004529e
Package: terminology Version: 1.9.0-2 Severity: minor When starting terminology I see: ``` ERR<148513>:elementary ../src/lib/elementary/efl_ui_focus_manager_calc.c:1529 _efl_ui_focus_manager_calc_efl_ui_focus_manager_manager_focus_set() Could not fetch a node located at 0x4004529e ## Copy & Paste the below (until EOF) into a terminal, then hit Enter eina_btlog << EOF /lib/x86_64-linux-gnu/libeina.so.1 0x7f2e06086ebc 0x7f2e0605a000 /lib/x86_64-linux-gnu/libeina.so.1 0x7f2e060880c1 0x7f2e0605a000 /lib/x86_64-linux-gnu/libeina.so.1 0x7f2e060896f3 0x7f2e0605a000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05ebe24e 0x7f2e05b61000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05eb8552 0x7f2e05b61000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05ebb925 0x7f2e05b61000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05eb915a 0x7f2e05b61000 /usr/bin/terminology 0x55cc71f83d73 0x55cc71f2c000 /usr/bin/terminology 0x55cc71f878bd 0x55cc71f2c000 /lib/x86_64-linux-gnu/libeo.so.1 0x7f2e057b28e2 0x7f2e0579b000 /lib/x86_64-linux-gnu/libeo.so.1 0x7f2e057ad090 0x7f2e0579b000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05e8cd45 0x7f2e05b61000 /lib/x86_64-linux-gnu/libecore_evas.so.1 0x7f2e05b405b9 0x7f2e05b2d000 /lib/x86_64-linux-gnu/ecore_evas/engines/x/v-1.25/module.so 0x7f2e00fb3429 0x7f2e00fa7000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e06120480 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e06129642 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e06122439 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e0612130c 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e0611bef6 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e0611c6e5 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e06122295 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e061215cc 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e0611c7d7 0x7f2e060fa000 /usr/bin/terminology 0x55cc71f4d16e 0x55cc71f2c000 /usr/bin/terminology 0x55cc71f4169d 0x55cc71f2c000 /lib/x86_64-linux-gnu/libc.so.6 0x7f2e057e9d0a 0x7f2e057c3000 /usr/bin/terminology 0x55cc71f416da 0x55cc71f2c000 EOF ``` This is not very nice, but terminology still works. Thus I'm assigning a severitfy of "minor". Piping that to eina_btlog gives: ``` /lib/x86_64-linux-gnu/libeina.so.1 | ??/?? : 32655 @ _eina_semaphore_free() /lib/x86_64-linux-gnu/libeina.so.1 | ??/?? : 32655 @ eina_log_print_cb_stdout() /lib/x86_64-linux-gnu/libeina.so.1 | ??/?? : 32655 @ eina_log_print() /lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ efl_ui_focus_manager_calc_update_order() y/lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ efl_ui_focus_manager_focus_set() /lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ efl_ui_focus_manager_calc_update_order() /lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ efl_ui_focus_manager_pop_history_stack() /usr/bin/terminology | ??/?? : 32655 @ MD5Final() /usr/bin/terminology | ??/?? : 32655 @ MD5Final() /lib/x86_64-linux-gnu/libeo.so.1| ??/?? : 32655 @ efl_provider_unregister() /lib/x86_64-linux-gnu/libeo.so.1| ??/?? : 32655 @ efl_event_callback_legacy_call() /lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ elm_win_rotation_with_resize_set() /lib/x86_64-linux-gnu/libecore_evas.so.1| ??/?? : 32655 @ _ecore_evas_focus_device_set() /lib/x86_64-linux-gnu/ecore_evas/engines/x/v-1.25/module.so | /: 0 @ () /lib/x86_64-linux-gnu/libecore.so.1 | ??/?? : 0 @ ecore_main_fd_handler_active_set() /lib/x86_64-linux-gnu/libecore.so.1 | ??/?? : 0 @ efl_loop_message_handler_message_call() /lib/x86_64-linux-gnu/libecore.so.1 | ??/?? : 0 @ efl_loop_timeout() /lib/x86_64-linux-gnu/libecore.so.1 | ??/?? : 0 @ efl_loop_message_process() /lib/x86_64-linux-gnu/libecore.so.1 | ??/??
Bug#973570: fzf: keybinding files should be installed under /etc
Hi,
On Fri, Jun 18, 2021 at 02:30:03PM +1000, Jai Flack wrote:
On Sun, 21 Feb 2021 17:11:28 +0100 Jonas Smedegaard wrote:
Debian Policy §12.6 says that /usr/share/doc/*/examples/ is "for the
benefit of the system administrator and users as documentation only."
Notice the final part of "documentation only".
That is a good point; as they are intended for use I'll move them out of
doc/. This is also good opportinity to install the bash completions by
default and maybe the Vim plugin if it's not too intrusive.
It's worth noting that completion of command-line arguments of fzf
itself is only a secondary purpose of
/usr/share/bash-completion/completions/fzf, the primary purpose being
augmenting completion of other commands to use fzf, as described here:
https://github.com/junegunn/fzf#fuzzy-completion-for-bash-and-zsh
This primary purpose, however, isn't active via the bash-completion
autoloading. As things currently stand, it only becomes active after one
types fzf a presses Tab, which is probably not a good experience. So I
believe the note in /usr/share/doc/fzf/README.Debian about the
completion being installed by default is incorrect, and should be
reverted and the path corrected to
/usr/share/bash-completion/completions/fzf (rather than
/usr/share/doc/fzf/examples/completion.bash, which is still in
README.Debian).
Alternatively, the file can be installed into /etc/bash_completion.d,
which is the compat (no autoload) dir for old-style bash-completion
modules, so it will indeed get loaded unconditionally. I'd personally
prefer the former solution, though.
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1003252: AttributeError: install_layout
Package: python3-setuptools
Version: 58.2.0-1
Severity: normal
X-Debbugs-CC: debian-pyt...@lists.debian.org
Since setuptools 60+ is out with SETUPTOOLS_USE_DISTUTILS defaulting to
"local", pip install --editable in --system-site-packages venvs fails:
$ docker run --rm -it debian:sid
# apt update
# apt install git python3-setuptools python3-pip python3-venv
# cd /tmp
# git clone https://github.com/platformdirs/platformdirs
# cd platformdirs
# python3 -m venv --system-site-packages --without-pip .venv
# .venv/bin/python -m pip install -e .
Obtaining file:///tmp/platformdirs
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing wheel metadata ... done
Installing collected packages: platformdirs
Running setup.py develop for platformdirs
ERROR: Command errored out with exit status 1:
command: /tmp/platformdirs/.venv/bin/python -c 'import sys,
setuptools, tokenize; sys.argv[0] = '"'"'/tmp/platformdirs/setup.py'"'"';
__file__='"'"'/tmp/platformdirs/setup.py'"'"';f=getattr(tokenize,
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop
--no-deps
cwd: /tmp/platformdirs/
Complete output (30 lines):
running develop
Traceback (most recent call last):
File "", line 1, in
File "/tmp/platformdirs/setup.py", line 5, in
setup()
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
153, in setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py",
line 148, in setup
dist.run_commands()
File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py",
line 967, in run_commands
self.run_command(cmd)
File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py",
line 985, in run_command
cmd_obj.ensure_finalized()
File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py",
line 107, in ensure_finalized
self.finalize_options()
File "/usr/lib/python3/dist-packages/setuptools/command/develop.py",
line 52, in finalize_options
easy_install.finalize_options(self)
File
"/usr/lib/python3/dist-packages/setuptools/command/easy_install.py", line 293,
in finalize_options
self.set_undefined_options(
File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py",
line 287, in set_undefined_options
src_cmd_obj.ensure_finalized()
File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py",
line 107, in ensure_finalized
self.finalize_options()
File
"/usr/lib/python3/dist-packages/setuptools/command/install_lib.py", line 17, in
finalize_options
self.set_undefined_options('install',('install_layout','install_layout'))
File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py",
line 290, in set_undefined_options
setattr(self, dst_option, getattr(src_cmd_obj, src_option))
File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py",
line 103, in __getattr__
raise AttributeError(attr)
AttributeError: install_layout
ERROR: Command errored out with exit status 1:
/tmp/platformdirs/.venv/bin/python -c 'import sys, setuptools, tokenize;
sys.argv[0] = '"'"'/tmp/platformdirs/setup.py'"'"';
__file__='"'"'/tmp/platformdirs/setup.py'"'"';f=getattr(tokenize,
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop
--no-deps Check the logs for full command output.
This happens even though setuptools 60 isn't in Debian yet, because pip
downloads latest setuptools for pep517 installs that require setuptools
in the build-system section of pyproject.yaml, but then fails to
actually use that version fully (this is a bug in pip:
https://github.com/pypa/pip/issues/6264).
I'll explain what's going on in detail further down, but first I'll
present a simpler reproducer that illustrates why this might be a bug in
Debian's setuptools packaging as well:
$ docker run --rm -it debian:sid
# apt update
# apt install git python3-setuptools python3-pip
# cd /tmp
# git clone https://github.com/platformdirs/platformdirs
# cd platformdirs
# SETUPTOOLS_USE_DISTUTILS=local python3 setup.py install
running install
Traceback (most recent call last):
…
File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line
103, in __getattr__
raise AttributeError(attr)
AttributeError: install_layout
Here we are explicitly using Debian's setuptools package, just telling it
to use the
Bug#978650: podman: Failing by default?
Package: podman Followup-For: Bug #978650 X-Debbugs-Cc: Antonio Terceiro , Reinhard Tartler , Andrej Shadura Debian's podman isn't able to resolve short names out of the box. It seems however that upstream is (I have not verified that - I'm infering that from looking at an example [1]). Behaving differently from vanilla upstream will mean that recipes working out of the box with upstream will fail on Debian. I respect and consider valid the argument about the security aspect of using short-names brought forward by Reinhard in [2]. What I'd like to question is the weighting of: * convenience * being compatible with upstream versus * security aspect We gain securty by breaking convenience and compatibility with upstream. That's the price we pay here for that bit of security. Now let's consider the security part. It's a given that if you are using a random container image then you *will* get a random container image. Which is maybe not a very wise thing to do. However *are* people using random images without a second thought? And additionaly: do we want to protect people from using random images from the internet? It is a given that Unix is giving you the gun and if you point it at your foot and pull the trigger then the result will be bad. Being a Unix system admin one *must* be traditionally careful. How is this different with short-names? Why do we now have to protect the admin or the user? I think just like with everything else, recipes on the internet do *not* include random short-names but instead standard ones, such as official python or debian images. Also users are aware that installing a random container will execute random code on one's system. Therefore I'd like to argue that going with upstream behavior would be the better setting. Whichever way the argument goes: thanks a lot for maintaining podman! *t [1] https://github.com/ansible-community/ansible-bender/blob/master/simple-playbook.yaml [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978650#90 -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.0.25+ds1-1.1 ii containernetworking-plugins 0.9.0-1+b6 ii golang-github-containers-common 0.33.4+ds1-1 ii init-system-helpers 1.60 ii iptables 1.8.7-1 ii libc62.31-13+deb11u2 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1+deb11u1 ii runc 1.0.0~rc93+ds1-5+b2 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1+b6 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7 ii slirp4netns 1.0.1-2 ii tini 0.19.0-1 ii uidmap1:4.8.1-1 Versions of packages podman suggests: pn containers-storage ii docker-compose 1.25.0-1 -- Configuration Files: /etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Keine Berechtigung: '/etc/cni/net.d/87-podman-ptp.conflist' -- no debconf information
Bug#922499: spamassassin: sa-update fails with error "Cannot open file ..."
Hi Noah and ticket participants, I've been recently getting the Cannot open file /var/lib/spamassassin/3.004002/updates_spamassassin_org/1896304.tar.gz: No such file or directory at /usr/bin/sa-update line 1600. error from cron. Since you wrote: I believe that the fix from https://svn.apache.org/viewvc/spamassassin/branches/3.4/sa-update.raw?r1=1842326=1842325=1842326 should be sufficient and easily backportable. please allow me to ask: is there a particular reason why you don't publish a package with the patch applied? This is not meant as a critique or application of pressure but as a attempt to understand. * is there a need to test the patch and report back on whether it works? * is it that you do not want to do the work to release an updated package (which is completely legitimate to me). In which case would it be OK if somebody else pushed (NMU...) a patched version? For context: I certainly can patch my local spamassassin version however I guess it'd be more helpful, if all users of spamassasin would get the fix. That said, my system is still running oldstable, so maybe it's just not worth the effort and the better path forward is just to upgrade to the bullseye... Thanks a lot!!! (And I wish everybody nice holiday and soon a happy and good new year!) *t
Bug#1002573: follow-up 4
Hi Detlev, On Mon, 27 Dec 2021, detlev schmidtke wrote: and I do not agree that this is a sole kernel problem fstrim --verbose should report something, anything * there still isn't a text only output (as opposed to an image) of what you are seeing in the bugreport. So people that get emails from this bugreport tendentially do not know what you are talking about. Again: please add a text-only output of what the problem is to the bug report * Debian's bug tracking system is a bit weird in that by default (as far as I know) only the package maintainer gets an email. The ticket now being assigned to the kernel, the maintainer of linux-utils did not get any notice about what you wrote above. You have to include him explicitly (which I've done in this email). *t
Bug#1002573: please include console output in text form
Hi nst0022, I have reassigned your bugreport to the correct package, namely util-linux. Please when filing a bug report, assign the bug to the correct package in the first place, otherwise: * you'll be generating triage work for others * your bug report won't be seen by the maintainers and therefore be possibly useles Also please do *not* attach screenshots, when you can copy/paste text. Images are not searchable as oposed to text, which easily is. Also images are harder to manage (how do I cite text in your image?). So could you please write a follow up to your report, that includes the *text* only (no screen shot). Thanks, *t
Bug#915379: anacron.service: should probably use KillMode=process
Hi,
On Fri, Feb 26, 2021 at 09:08:18AM +0100, Marc Haber wrote:
Worse. If the receiving side does post-DATA checking of the message, and
systemd sends SIGKILL to the exim process on the sending side, the
receiving side might continue delivery without the sending side noticing
the confirmation (it's already dead by then). During the next exim queue
run, the message will be delivered a second time.
In this case, 5 seconds of extra wait would probably not be enough.
This entry in the systemd 250 NEWS gives me hope this might be fixed in
a nice way eventually:
* A new service unit file setting ExitType= has been added that
specifies when to assume a service has exited. By default systemd
only watches the main process of a service. By setting
ExitType=cgroup it can be told to wait for the last process in a
cgroup instead.
I'll probably experiment with it once systemd 250 lands in testing,
unless someone beats me to it.
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#1001461: network-manager-openconnect: the problem is not having installed the network-manager-openconnect-gnome package
Package: network-manager-openconnect Version: 1.2.6-1 Followup-For: Bug #1001461 When I try to a VPN connection by executing `nm-connection-editor`, after pressing the button "Create..." I see in the console: ** (nm-connection-editor:27682): WARNING **: 15:31:07.165: Could not load editor VPN plugin for ?org.freedesktop.NetworkManager.openconnect? (missing plugin file "/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-vpn-plugin-openconnect-editor.so"). (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.165: gtk_widget_get_parent: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): GLib-GObject-CRITICAL **: 15:31:07.165: g_object_set_data: assertion 'G_IS_OBJECT (object)' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.165: gtk_notebook_insert_page: assertion 'GTK_IS_WIDGET (child)' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.166: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.167: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): libnm-CRITICAL **: 15:31:07.167: ((libnm/nm-vpn-editor.c:49)): assertion '' failed ** Message: 15:31:07.167: Cannot save connection due to error: Invalid setting VPN: unspecified error (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.167: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): libnm-CRITICAL **: 15:31:07.191: ((libnm/nm-vpn-editor.c:49)): assertion '' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.191: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): libnm-CRITICAL **: 15:31:07.191: ((libnm/nm-vpn-editor.c:49)): assertion '' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.191: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): libnm-CRITICAL **: 15:31:07.210: ((libnm/nm-vpn-editor.c:49)): assertion '' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.210: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed when I search for `/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-vpn-plugin-openconnect-editor.so` I see that it is in the package network-manager-openconnect-gnome. Since I am running Xfce it is not self-evident that I have to install a package that says that it is for Gnome. So I think that it'd be optimal to: * add a note to the package description saying: "you'll probably need the network-manager-openconnect-gnome package as well, if you want to manage the connections from the GUI" * maybe add a "Suggests: network-manager-openconnect-gnome" to the package? * and the nm-applet should not fail silently if it doesn't find an editor component, but instead it should say so: "I could not find the VPN editor component. Did you install the network-manager-openconnect-gnome package?" *t -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-openconnect depends on: ii adduser 3.118 ii libc62.31-13+deb11u2 ii libglib2.0-0 2.66.8-1 ii libnm0 1.30.0-2 ii libopenconnect5 8.10-2+b1 ii network-manager 1.30.0-2 ii openconnect 8.10-2+b1 network-manager-openconnect recommends no packages. network-manager-openconnect suggests no packages. -- no debconf information
Bug#1001461: network-manager-openconnect: doesn't have a VPN tab to configure the VPN gateway
Package: network-manager-openconnect Version: 1.2.6-1 Severity: important Hi, after installing network-manager-openconnect there's no VPN tab in the configuration dialog and so I can't enter the VPN gateway address anywhere to set up the VPN connection. I did restart NM via sudo systemctl restart NetworkManager and I did also restart the nm-applet via killall nm-applet; nohup nm-applet & but no luck. What I do: * click on the applet * click on "VPN Connections" * click on "Add a VPN connection..." * select "Cisco AnyConnect or openconnect (OpenConnect)" (I can also select Juniper, PaloAlto or Pulse - there won't be a VPN tab in either case) * click on "Create..." * the config dialog is shown * only "General", "Proxy", "IPv4 Settings", "IPv6 Settings" tabs are shown * there's no place I found to enter the VPN gateway * also whatever I do in that dialog, the "Save" button is always greyed out -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-openconnect depends on: ii adduser 3.118 ii libc62.31-13+deb11u2 ii libglib2.0-0 2.66.8-1 ii libnm0 1.30.0-2 ii libopenconnect5 8.10-2+b1 ii network-manager 1.30.0-2 ii openconnect 8.10-2+b1 network-manager-openconnect recommends no packages. network-manager-openconnect suggests no packages. -- no debconf information
Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]
On 06.12.21 20:43, Noah Meyerhans wrote: On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote: So what's happening with chromium in both sid and stable? I saw on d-release that it was removed from testing (#998676 and #998732), with a discussion about ending security support for it in stable. The problem really is lack of maintenance. In my opinion, chromium deserves an active *team* to support it in Debian. <...> The security team doesn't have the bandwidth to do it themselves, they need a team to help them. Sorry for a silly question, but whatʼs so wrong with the build done by linuxmint.com [1], so Debian needs a whole team to duplicate their effort? Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my (limited) experience. Well, you can start with the fact that the Mint chromium source packages don't even include the chromium source, let alone the sources for all the other things they build (NodeJS, and more). The biggest difficulty, as far as I can tell from my look at Chromium from several months ago, is that our patch set [1] needs a lot of attention with every chromium release. Mint doesn't apply any patches at all to the source, at least none of any real complexity. One lesson we may take from Mint, though, is that it's not worth trying to patch Chromium as much as we'd like. Anything that we can do to simplify the Chromium packaging will help us keep the package up-to-date, which in turn will help us keep our users safer. In my opinion, we should be pretty aggressive about dropping as many of the Chromium patches as possible, even if that means we link against bundled/vendored dependencies. Legal/licensing considerations are still important and I don't know if we actually *can* ship builds based on the bundled stuff. But based on the number of patches we have to disable various things [2] or build against system dependencies [3], I can't help but think we'd have an easier time keeping this package fresh if we could drop some of those. noah 1. https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series 2. https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable 3. https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system I'd also like to point out, that the ungoogled-chromium project has some overlap in goals with Debian and it'd possibly be interessing to join forces: https://github.com/ungoogled-software/ungoogled-chromium-debian (I have been running an ungoogled-chromium for a while (ca. a year ago?), however at that time their chrome wasn't extremely stable so I gave up again. Does anybody have experience using it recently?) *t
Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages
Rustam wrote on 12 Oct 2021: Hi Guillem, Any news on the proposed patch? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664#49 Can it be merged already? ;) Ubuntu packages are already using zstd compression. So tools like Mainline don't work on Debian any more, see e.g. https://github.com/bkw777/mainline/issues/121 More than that: AFAIU Ubuntu has in fact switched its default compressor to zstd [1], so Debian's tools haven't been able to understand Ubuntu's freshly generated packages from 2021-06-14 on. I have applied [2] Bálint's commit to *current* dpkg from git: * there was a trivial merge conflict in man/deb.pod, which is easily fixed [3] * in my dpkg git repo and zstd branch I have changed the patch author (including the merge conflict fix) back from me to Bálint [3], which might not be the right/clean way to do things, but that's a minor thing I can fix if Guillem would want that * dpkg-buildpackage built the patched package fine * I only did a smoketest with the resulting dpkg : `dpkg -x sbsigntool_0.9.4-2ubuntu1_amd64.deb foodir` [4] which successfully unpacked Ubuntu's zstd compressed sbsigntool package into the foodir directory So I am reporting that Bálint's patch [4] applies cleanly (with a trivially to solve merge conflict (see above)) and works (again see above for the minimal testing I did), has been in production in Ubuntu since 2021-04-14 and zstd is beeng used as default compressor in Ubtuntu since 2021-06-14. Of course I would welcome it very much if Debian's tools would be compatible and allow to work with Ubtuntu's packages. Concrete point in case: it would have made my life easier figuring out Ubuntu's mechanism to sign user-generated modules [5]. Thanks a lot to all involved! For Guillem's work on dpkg, Bálint for the patch and all others for their contributions here and in Ubuntu!!! Greets, *t [1] http://changelogs.ubuntu.com/changelogs/pool/main/d/dpkg/dpkg_1.20.9ubuntu2/changelog [2] https://salsa.debian.org/tpo/dpkg/-/tree/zstd [3] https://salsa.debian.org/tpo/dpkg/-/commit/e7cb231bc289d356f563c1e2c761d94c85aa7055 [4] https://packages.ubuntu.com/impish/amd64/sbsigntool/download [5] https://salsa.debian.org/rbalint/dpkg/-/commit/eb38de93eeb9524a54e80525c480df249828e84f [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939392
Bug#1000160: firmware: failed to load nouveau/nvc3_fuc084 and nvc3_fuc084d
Package: xserver-xorg-video-nouveau Version: 1:1.0.17-1 Severity: normal Tags: upstream I continually receive failure messages to load the firmware: [ 4138.126756] nouveau :03:00.0: firmware: failed to load nouveau/nvc3_fuc084 (-2) [ 4138.126762] nouveau :03:00.0: Direct firmware load for nouveau/nvc3_fuc084 failed with error -2 [ 4138.126771] nouveau :03:00.0: firmware: failed to load nouveau/nvc3_fuc084d (-2) [ 4138.126773] nouveau :03:00.0: Direct firmware load for nouveau/nvc3_fuc084d failed with error -2 [ 4138.126774] nouveau :03:00.0: msvld: unable to load firmware data [ 4138.126776] nouveau :03:00.0: msvld: init failed, -19 System description: ~$ dmesg | grep nvidia [5.758958] audit: type=1400 audit(1637254492.947:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=737 comm="apparmor_parser" [5.758962] audit: type=1400 audit(1637254492.947:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=737 comm="apparmor_parser" ~$ lspci | grep VGA 03:00.0 VGA compatible controller: NVIDIA Corporation GF106GL [Quadro 2000] (rev a1) OS: Debian GNU/Linux 11 (bullseye) x86_64 Host: 0606AD5 ThinkStation S30 Kernel: 5.10.0-9-amd64 Resolution: 1920x1200, 1680x1050 Twin Display DE: Xfce 4.16 CPU: Intel Xeon E5-1607 0 (4) @ 3.000GHz GPU: NVIDIA Quadro 2000 Memory: 3698MiB / 32064MiB Thanks for your help Tomas -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106GL [Quadro 2000] [10de:0dd8] (rev a1) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 673 Jul 17 18:33 72-wacom-options.conf /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.10.0-9-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.2) #1 SMP Debian 5.10.70-1 (2021-09-30) Xorg X server log files on system: -- -rw-r--r-- 1 root root 77039 Nov 18 20:08 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 6.147] X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 [ 6.147] Build Operating System: linux Debian [ 6.147] Current Operating System: Linux luna 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 [ 6.147] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-9-amd64 root=UUID=d1e1a232-915b-4a5c-9f1b-1c03f1688679 ro quiet [ 6.147] Build Date: 13 April 2021 04:07:31PM [ 6.147] xorg-server 2:1.20.11-1 (https://www.debian.org/support) [ 6.147] Current version of pixman: 0.40.0 [ 6.147]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 6.147] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 6.147] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 18 17:54:53 2021 [ 6.153] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 6.153] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 6.161] (==) No Layout section. Using the first Screen section. [ 6.161] (==) No screen section available. Using defaults. [ 6.161] (**) |-->Screen "Default Screen Section" (0) [ 6.161] (**) | |-->Monitor "" [ 6.162] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 6.162] (==) Automatically adding devices [ 6.162] (==) Automatically enabling devices [ 6.162] (==) Automatically adding GPU devices [ 6.162] (==) Max clients allowed: 256, resource mask: 0x1f [ 6.166] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 6.166]Entry deleted from font path. [ 6.171] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 6.171] (==) ModulePath set to "/usr/lib/xorg/modules" [ 6.171] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 6.171]
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Thu, 18 Nov 2021, Thomas Goirand wrote: On 11/17/21 11:01 AM, Tomas Pospisek wrote: Our instructions on Secure Boot [1] are a bit scatterbrained and do not specify precisely where the key should exist at. I was the one who wrote them, after *A LOT* of research about it on the internet. It was hard to find, really. I just explained how to sign, with no intention to have this automated (at the time), so no wonder there's no standard path... I did not intend my characterisation of the instructions as a critique of your work. I am extremely happy that you actually *did* the work for all of us so we can stand on the shoulders of what you did. Very much +1 and many thanks really!!! (And thanks & cheers to the Debian EFI Team as well :-D ) I would edit those instruction so that they create the key at the same location Ubuntu has its MOK keys. However I would prefer not to collide with some tools or automation or scripts that do the same at the same place. Please go ahead, and explain that this is the Ubuntu path. Done. I think it'd be preferable if Debian created (or however Ubuntu does it) it's key automatically at that same place as Ubuntu has them, which would make most of the instructions in the wiki [1] unnecessary and would make the user experience much easier and smoother since the (upstream) virtualbox package could install and sign it's modules by itself without any user interaction, just like it happens under Ubuntu (?). ? Well, to begin with, I wonder why the upstream virtualbox package is pushing its compiled modules at the wrong location, but yeah, sure! I guess one can always talk to upstream... Hopefully, we can have the automation to sign DKMS modules in a non-leaf package. I would strongly suggest we get a package with a very explicit name in it, like "dkms-automatic-mok-signing" so it would do the work. I would absolutely *not* go the path of disabling secure boot when a DKMS module gets installed... Since I have not looked further I am *guessing* that Ubuntu does the automatic creation of the MOK key in the shim-signed package. So I think it should be possible to lift Ubuntu's work out of there and also put it into the shim-signed package, into postinst or so. *t
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Wed, 17 Nov 2021, Tomas Pospisek wrote: I would edit those [wiki] instruction so that they create the key at the same location Ubuntu has its MOK keys. However I would prefer not to collide with some tools or automation or scripts that do the same at the same place. [...] [1] https://wiki.debian.org/SecureBoot I just updated the instructions accordingly with a pointer to this bug report in case Debian would generate the MOK key automatically in the future. *t
Bug#999829: mayavi2: Mayavi 4.7.1-2+b2 do not start in GNU/Debian Bullseye with apt installation
Package: mayavi2
Version: 4.7.1-2+b2
Severity: important
Tags: upstream
-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 mayavi2 depends on:
ii libc6 2.31-13+deb11u2
ii libjs-jquery3.5.1+dfsg+~3.5.5-7
ii python3 3.9.2-3
ii python3-apptools4.5.0-1.1
ii python3-configobj 5.0.6-4
ii python3-envisage4.9.0-2.1
ii python3-numpy [python3-numpy-abi9] 1:1.19.5-1
ii python3-pkg-resources 52.0.0-4
ii python3-pyface 6.1.2-2
ii python3-pygments2.7.1+dfsg-2.1
ii python3-traits 5.2.0-2+b3
ii python3-traitsui6.1.3-3
ii python3-vtk77.1.1+dfsg2-8
mayavi2 recommends no packages.
Versions of packages mayavi2 suggests:
ii ipython3 7.20.0-1
ii python3-scipy 1.6.0-2
Bug description:
I have a stable GNU / Debian 11 installation (Bullseye), and I have installed
Mayavi 4.7.1-2+b2 from the repositories but the software do not work from the
GUI. I get errors in the console like this:
~$ mayavi2
08:07:07: Debug: Adding duplicate image handler for 'Windows bitmap file'
08:07:07: Debug: Adding duplicate image handler for 'Windows bitmap file'
/usr/lib/python3/dist-packages/pyface/ui/wx/clipboard.py:25:
wxPyDeprecationWarning: Call to deprecated item. Use wx.DataFormat instead.
PythonObjectFormat = wx.CustomDataFormat('PythonObject')
/usr/lib/python3/dist-packages/pyface/wx/drag_and_drop.py:99:
wxPyDeprecationWarning: Call to deprecated item. Use wx.DataFormat instead.
PythonObject = wx.CustomDataFormat('PythonObject')
Exception occurred in traits notification handler.
Please check the log file for details.
Exception occurred in traits notification handler for object:
,
trait: application, old value: None, new value:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/traits/trait_notifiers.py", line 654, in
_dispatch_change_event
self.dispatch(handler, *args)
File "/usr/lib/python3/dist-packages/traits/trait_notifiers.py", line 553, in
dispatch
handler(*args)
File "/usr/lib/python3/dist-packages/traits/traits_listener.py", line 498, in
handle_simple
self.next.register(new)
File "/usr/lib/python3/dist-packages/traits/traits_listener.py", line 464, in
register
value = getattr(self, type)(new, name, False)
File "/usr/lib/python3/dist-packages/traits/traits_listener.py", line 738, in
_register_simple
return next.register(getattr(object, name))
File "/usr/lib/python3/dist-
packages/envisage/ui/workbench/workbench_application.py", line 140, in
_gui_default
return GUI(splash_screen=self.splash_screen)
File "/usr/lib/python3/dist-packages/pyface/ui/wx/gui.py", line 60, in
__init__
self._splash_screen.open()
File "/usr/lib/python3/dist-packages/pyface/i_splash_screen.py", line 79, in
open
super(MSplashScreen, self).open()
File "/usr/lib/python3/dist-packages/pyface/i_window.py", line 202, in open
self._create()
File "/usr/lib/python3/dist-packages/pyface/i_widget.py", line 112, in
_create
self.control = self._create_control(self.parent)
File "/usr/lib/python3/dist-packages/pyface/ui/wx/splash_screen.py", line 69,
in _create_control
splash_screen = wx.SplashScreen(
AttributeError: module 'wx' has no attribute 'SplashScreen'
Exception occurred in traits notification handler for object:
<__main__.MayaviApp object at 0x7f8e73098860>, trait: application, old value:
None, new value:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/traits/trait_notifiers.py", line 654, in
_dispatch_change_event
self.dispatch(handler, *args)
File "/usr/lib/python3/dist-packages/traits/trait_notifiers.py", line 553, in
dispatch
handler(*args)
File "/usr/lib/python3/dist-packages/traits/traits_listener.py", line 498, in
handle_simple
self.next.register(new)
File "/usr/lib/python3/dist-packages/traits/traits_listener.py", line 464, in
register
value = getattr(self, type)(new, name, False)
File "/usr/lib/python3/dist-packages/traits/traits_listener.py", line 738, in
_register_simple
return next.register(getattr(object, name))
File "/usr/lib/python3/dist-
packages/envisage/ui/workbench/workbench_application.py", line 140, in
_gui_default
return GUI(splash_screen=self.splash_screen)
File "/usr/lib/python3/dist-packages/pyface/ui/wx/gui.py", line 60, in
__init__
