Bug#995013: csh: Certain input locks shell up and consumes all memory
Package: csh Version: 20110502-6 Severity: normal Hi, Certain arguments cause csh to lock up and endlessly consume memory until killed. I'm guessing this happens during parsing because the code doesn't have to actually be executed. The most I've been able to narrow it down is that it happens when a command line contains both a backslash and an unquoted ܠ (U+0720 SYRIAC LETTER LAMADH). Examples that trigger it: true \ܠ if (0) true \ܠ true \ foo bar baz ܠ true '\' ܠ Examples that don't trigger it: true ܠ true \ 'ܠ' I didn't manage to reproduce this on OpenBSD but I didn't try very hard. (This problem was found while fuzzing another piece of software.) -- System Information: Debian Release: 11.0 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-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 csh depends on: ii libbsd0 0.11.3-1 ii libc62.31-13 csh recommends no packages. csh suggests no packages. -- no debconf information
Bug#994949: linux-image-5.14.0-1-amd64: amdgpu and other problems during boot resulting in unusable machine
Hi Vincent, thank you for the fast reply! Could you please try if booting with the 'mem_encrypt=off' kernel command line helps? yes - this helps! dmesg still shows: ``` [ 10.737426] amd64_edac: Unknown symbol amd_unregister_ecc_decoder (err -2) [ 10.737641] amd64_edac: Unknown symbol amd_register_ecc_decoder (err -2) ``` It seems that other WARNINGS/problems just disappeared. Regards Jan
Bug#994594: ITP: time-decode -- timestamp decoder and converter
Package: wnpp Severity: wishlist Owner: Jan Gru X-Debbugs-Cc: debian-de...@lists.debian.org, debian-security-to...@lists.debian.org * Package name: time-decode Version : 3.1.1 Upstream Author : Corey Forman * URL : https://github.com/digitalsleuth/time_decode * License : MIT Programming Lang: Python Description : timestamp decoder and converter time-decode provides the functionality to decode various timestamps and UUIDs to aid digital forensics and incident response processes. The supported formats range from common ones, like Unix epochs, WebKit/Chrome timestamps and Microsoft's FILETIME to more exotic formats like LDAP/Active Directory timestamps and Metasploit payload UUIDs. In addition, even timestamps used by some social media services, like Twitter, are included. ** Relevance of the package In most DFIR investigations temporal information is particularly important. Analysts often stumble over various timestamps and need to convert and normalize them quickly. While toolkits like plaso can help with the normalization of logfiles in bulk, Debian's package archives lack tooling for the convenient conversion of single timestamps of either known or unknown format. Given this finding and my experience from using it, time-decode seems to be an valuable prospective package to round off Debian's collection of forensic tools. ** Maintainenace plan I suggest to maintain time-decode inside the pkg-security-team's repository on salsa, since most of the packages related to forensics live there. However, I am looking for a sponsor for this package - ideally a member of the pkg-security-team.
Bug#994224: please add pipewire-pulse as option
Package: plasma-pa Version: 4:5.21.5-2 Hi, please add pulseaudio | pipewire-pulse as other option to plasma-pa dependencies. Nice Greetings Jan Koester
Bug#994102: unistd.h: non-null check not correct for getcwd()
On Sun, 2021-09-12 00:16:01 +0200, Aurelien Jarno wrote: > On 2021-09-11 22:06, Jan-Benedict Glaw wrote: > > Until glibc's Bugzilla issue is finally resolved > > (https://sourceware.org/bugzilla/show_bug.cgi?id=26545), maybe the > > Debian package could be changed to drop the access attribute? > > No. Once we have patched it, we will have to differ from upstream almost > forever, and we want to avoid that. I already have sent a patch [1], I > am waiting for feedback. Sure, but I hope Debian's libc6-dev won't keep the instrumentation enabled even after the patch is accepted upstream to remove it, waiting for the next upstream glibc to be pulled for libc6 / libc-dev? In the meantime, I'll probably rebuild the containers to locally patch it away. Thanks, Jan-Benedict -- signature.asc Description: PGP signature
Bug#994102: unistd.h: non-null check not correct for getcwd()
Package: libc6-dev Version: 2.32-2 Current getcwd() is declared as: /usr/include/unistd.h: 513:/* Get the pathname of the current working directory, 514: and put it in SIZE bytes of BUF. Returns NULL if the 515: directory couldn't be determined or SIZE was too small. 516: If successful, returns BUF. In GNU, if BUF is NULL, 517: an array is allocated with `malloc'; the array is SIZE 518: bytes long, unless SIZE == 0, in which case it is as 519: big as necessary. */ 520:extern char *getcwd (char *__buf, size_t __size) __THROW __wur 521:__attr_access ((__write_only__, 1, 2)); Documentation (man page) states: As an extension to the POSIX.1-2001 standard, glibc's getcwd() allo- cates the buffer dynamically using malloc(3) if buf is NULL. In this case, the allocated buffer has the length size unless size is zero, when buf is allocated as big as necessary. The caller should free(3) the returned buffer. The current check doesn't accept the NULL pointer with recent GCC versions and breaks, for example, building GCC from sources due to fixincl.c using NULL as the buffer argument so it doesn't need to allocate on its own: [all 2021-09-11 18:34:38] make[1]: Entering directory '/var/lib/laminar/run/gcc-bfin-elf/6/toolchain-build/build-x86_64-pc-linux-gnu/fixincludes' [all 2021-09-11 18:34:38] /usr/lib/gcc-snapshot/bin/gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings -pedantic -Wno-long-long -Werror -DHAVE_CONFIG_H -I. -I../../../gcc/fixincludes -I../include -I../../../gcc/fixincludes/../include ../../../gcc/fixincludes/fixincl.c [all 2021-09-11 18:34:39] ../../../gcc/fixincludes/fixincl.c: In function 'process': [all 2021-09-11 18:34:39] ../../../gcc/fixincludes/fixincl.c:1356:7: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull] [all 2021-09-11 18:34:39] 1356 | fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n", [all 2021-09-11 18:34:39] | ^~~ [all 2021-09-11 18:34:39] 1357 |pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN), [all 2021-09-11 18:34:39] | ~ [all 2021-09-11 18:34:39] 1358 |erno, xstrerror (erno)); [all 2021-09-11 18:34:39] |~~~ [all 2021-09-11 18:34:39] In file included from ../../../gcc/fixincludes/system.h:192, [all 2021-09-11 18:34:39] from ../../../gcc/fixincludes/fixlib.h:29, [all 2021-09-11 18:34:39] from ../../../gcc/fixincludes/fixincl.c:24: [all 2021-09-11 18:34:39] /usr/include/unistd.h:520:14: note: in a call to function 'getcwd' declared with attribute 'access (write_only, 1, 2)' [all 2021-09-11 18:34:39] 520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur [all 2021-09-11 18:34:39] | ^~ [all 2021-09-11 18:34:39] cc1: all warnings being treated as errors [all 2021-09-11 18:34:39] make[1]: *** [Makefile:76: fixincl.o] Error 1 [all 2021-09-11 18:34:39] make[1]: Leaving directory '/var/lib/laminar/run/gcc-bfin-elf/6/toolchain-build/build-x86_64-pc-linux-gnu/fixincludes' [all 2021-09-11 18:34:39] make: *** [Makefile:2854: all-build-fixincludes] Error 2 (That's from a not-yet publically announced auto-builder that does build GCC/Binutils, Linux Kernel, NetBSD and SIMH to check for them being buildable for a good number of configurations.) For comparison, with libc6-dev at 2.31-16, declaration was like this: 504:/* Get the pathname of the current working directory, 505: and put it in SIZE bytes of BUF. Returns NULL if the 506: directory couldn't be determined or SIZE was too small. 507: If successful, returns BUF. In GNU, if BUF is NULL, 508: an array is allocated with `malloc'; the array is SIZE 509: bytes long, unless SIZE == 0, in which case it is as 510: big as necessary. */ 511:extern char *getcwd (char *__buf, size_t __size) __THROW __wur; Until glibc's Bugzilla issue is finally resolved (https://sourceware.org/bugzilla/show_bug.cgi?id=26545), maybe the Debian package could be changed to drop the access attribute? Thanks, Jan-Benedict -- signature.asc Description: PGP signature
Bug#994078: budgie-keyboard-autoswitch-applet: The package should depend on xdotool
Package: budgie-keyboard-autoswitch-applet Version: 1.1.0-1 Severity: normal Dear Maintainer, when I installed, it did not work. When doing "budgie-panel --replace &" I have seen a following error: ... File "/usr/lib/python3.9/subprocess.py", line 1821, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] Adresář nebo soubor neexistuje: '/usr/bin/xdotool' I have fixed it by doing: sudo apt install xdotool I believe that the package should depend on xdotool. There are also reports from Ubuntu with the same problem. With best regards, Jan W -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages budgie-keyboard-autoswitch-applet depends on: ii gir1.2-budgie-1.0 10.5.2-4 ii gir1.2-glib-2.01.68.0-2 ii gir1.2-gtk-3.0 3.24.30-3 ii gir1.2-peas-1.01.30.0-3 ii python33.9.2-3 ii python3-gi 3.40.1-2 ii python3-psutil 5.8.0-1 ii wmctrl 1.07-7+b1 ii x11-utils 7.7+5 budgie-keyboard-autoswitch-applet recommends no packages. budgie-keyboard-autoswitch-applet suggests no packages.
Bug#993128: libvpx6: Unable to use camera or share screen on WebRTC conferences
Hello Ramacher, Could you please retry with 1.10.0-2 which is now available in unstable? This new version fixed encoding VP8 with ffmpeg for me. I no longer get the "ABI version mismatch" error. Thank you! ~ Jan
Bug#993222: ffmpeg: Having libvpx 1.10.0-1 installed gives "ABI version mismatch" error
Package: ffmpeg Version: 7:4.4-5 Severity: normal Dear Maintainer, A recent apt-upgrade installed the latest version of libvpx, 1.10.0-1, on my system. The next time I tried to encode a video with VP8, it gave the error message "Failed to initialize encoder: ABI version mismatch". Downgrading to the previous version, 1.9.0-1, fixed the issue. FFmpeg should declare its incompatibility with 1.10.0-1 so the package gets kept back. Besides that, no issues with the package. Thank you for maintaining it! Sincerely, Jan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ffmpeg depends on: ii libavcodec587:4.4-5 ii libavdevice58 7:4.4-5 ii libavfilter77:4.4-5 ii libavformat58 7:4.4-5 ii libavutil56 7:4.4-5 ii libc6 2.31-17 ii libpostproc55 7:4.4-5 ii libsdl2-2.0-0 2.0.14+dfsg2-3 ii libswresample3 7:4.4-5 ii libswscale5 7:4.4-5 ffmpeg recommends no packages. Versions of packages ffmpeg suggests: pn ffmpeg-doc -- no debconf information
Bug#992560: mariadb-client-core-10.5: erases mysql client command history
Package: mariadb-client-core-10.5 Version: 1:10.5.11-1 Severity: important Dear Maintainer, After upgrading from Debian buster to bullseye, and running the mysql command line client for the first time, the command line history is wiped, leaving a .mysql_history devoid of entries. This is rather inconvenient, particularly in multi-user environments, where multiple .mysql_history files must be recovered from backups. The bug seems to be related to the regression from GNU readline to BSD EditLine as the linked command line/history manager library. This regression is not apparent in upstream, at least as they package mariadb-client-core-10.5 for buster (versions up to and including: 1:10.5.12+maria~buster). As far as I can tell, there are two apparent fixes, one apparently technically (if not policy-wise) easy, the other rather labor intensive. Easy fix: revert the regression from readline to EditLine, so that the client library uses readline, as upstream does. More labor intensive fix: 1) Prompt the user upon first use of the command for how to handle the situation. 2) Provide conversion for the command line history from readline format to the current EditLine format, whatever that may be. 3) Automatically back up the command line history when the user chooses to start with a fresh history file. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-client-core-10.5 depends on: ii libc6 2.31-13 ii libedit23.1-20191231-2+b1 ii libmariadb3 1:10.5.11-1 ii libncurses6 6.2+20201114-2 ii libssl1.1 1.1.1k-1 ii libstdc++6 10.2.1-6 ii libtinfo6 6.2+20201114-2 ii mariadb-common 1:10.5.11-1 ii zlib1g 1:1.2.11.dfsg-2 mariadb-client-core-10.5 recommends no packages. mariadb-client-core-10.5 suggests no packages. -- no debconf information
Bug#992524: deborphan: missing orphaner
Package: deborphan Version: 1.7.34 Severity: normal Dear Maintainer, After upgrading to deborphan 1.7.34 (after bullseye release) I noticed that the orphaner binary is no longer being included. There's no mention of it in the changelog, nor is there another package. Is it just a case of MIA? -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-rt-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_BE.UTF-8, LC_CTYPE=en_BE.UTF-8 (charmap=UTF-8), LANGUAGE=en_BE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages deborphan depends on: ii libc6 2.31-16 Versions of packages deborphan recommends: ii apt 2.3.8 ii dialog1.3-20201126-1 ii gettext-base 0.21-4 deborphan suggests no packages. -- debconf-show failed
Bug#991714: linux-image-5.10.0-8-arm64: RPi 4 (8 GB) - CPU stuck in highest speed
Package: src:linux Version: 5.10.46-3 Severity: critical Justification: breaks the whole system Dear Maintainer, Looking into the instability of my RPi 4 (8GB) showed the CPU constantly in the highest clock setting with a load of 0 and 99.5%+ idle state. The instability was 1st discovered after updates in januari, but unable to get researched until now. (so no clue which kernel version triggered it, I expect a 5.x kernel, as on 4.9 it was stable) I tried setting the default govenour (performance, tad optimistic for an arm) to ondemand, powersave and schedutil and install cpufreqd, but cpufreqd reports no cpufreq support. The CPU reports to be full-time in the highest speed. Only way to limit the highest speed is to set arm_freq in /boot/firmware/config.txt to a lower max cpu freq. (testing with 1000 now) Running fulltime at 1500 MHz causes the device to crash several times a day. (housing is very hot) I expected the CPU to run in the lowest speed most of the time, as it's almost fulltime idle. Somehow the kernel doesn't use the governor setting. The issue is not seen on my RPi3 systems (same kernel, same config, gouvenour defaults to schedutil there), so I'd guess it's either an RPi4 or specifically a specific RPi 4 8 GB issue. -- Package-specific info: ** Version: Linux version 5.10.0-8-arm64 (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.46-3 (2021-07-28) ** Command line: video=HDMI-A-1:1280x1024M@60 dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x5e78c29f bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:B8:7F:26 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 console=ttyS1,115200 root=/dev/sda1 rw fsck.repair=yes net.ifnames=0 rootwait ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [ 22.247985] mc: Linux media interface: v0.10 [ 22.260008] bcm2835_audio bcm2835_audio: card created with 8 channels [ 22.313119] videodev: Linux video capture interface: v2.00 [ 22.328566] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 22.330090] usbcore: registered new interface driver brcmfmac [ 22.357834] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present! [ 22.359215] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin [ 22.362740] cryptd: max_cpu_qlen set to 1000 [ 22.364355] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt [ 22.368338] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4]) [ 22.368822] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present! [ 22.373047] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4]) [ 22.373234] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) [ 22.373552] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4]) [ 22.373680] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 22.373784] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 22.373889] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 22.373962] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 22.374258] checking generic (3e6c7000 50) vs hw (0 ) [ 22.374264] fb0: switching to vc4drmfb from simple [ 22.375966] Console: switching to colour dummy device 80x25 [ 22.380163] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned. [ 22.405236] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned. [ 22.411921] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 [ 22.498091] Adding 8388948k swap on /dev/sda2. Priority:-2 extents:1 across:8388948k FS [ 22.498288] Console: switching to colour frame buffer device 160x64 [ 22.530659] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device [ 22.533470] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 22.534245] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.clm_blob [ 22.539177] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Sep 18 2020 02:27:58 version 7.45.221 (3a6d3a0 CY) FWID 01-bbd9282b [ 22.756347] Bluetooth: Core ver 2.22 [ 22.756479] NET: Registered protocol family 31 [ 22.756484] Bluetooth: HCI device and connection manager initialized [ 22.756799] Bluetooth: HCI socket layer initialized [ 22.756811] Bluetooth: L2CAP socket layer initialized [ 22.756839] Bluetooth: SCO socket layer initialized [ 22.796142] Bluetooth: HCI UART driver ver 2.3 [ 22.796159] Bluetooth: HCI UART protocol H4 registered [ 22.796255] Bluetooth: HCI UART protocol LL registered [ 22.796259] Bluetooth: HCI UART protocol ATH3K registered [ 22.796309]
Bug#990706: libsnmp-dev shall depend/recommend libsnmp-perl because mib2c requires it
Package: libsnmp-dev Version: 5.9+dfsg-3+b1 Severity: normal Dear Maintainer, libsnmp-dev contains mib2c script which gives following output if libsnmp-perl package is not installed: |$ ./mib2c | |ERROR: You don't have the SNMP perl module installed. Please obtain |this by getting the latest source release of the net-snmp toolkit from |http://www.net-snmp.org/download/ . Once you download the source and |unpack it, the perl module is contained in the perl/SNMP directory. |See the README file there for instructions. | |$ After installing libsnmp-perl mib2c seems to start up properly (save for some uninitialized variables warnings in SNMP.pm which are probaly upstream issue) Could you consider adding appropriate dependency/reccomendation to the libsnmp-dev package? Regards Jan Górski -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-updates'), (71, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsnmp-dev depends on: ii libc6-dev 2.30-7 ii libnetsnmptrapd40 5.9+dfsg-3+b1 ii libpci-dev1:3.5.2-1 ii libsensors4-dev [libsensors-dev] 1:3.5.0-3 ii libsnmp40 5.9+dfsg-3+b1 ii libssl-dev1.1.1d-0+deb10u6 ii libwrap0-dev 7.6.q-28 ii procps2:3.3.15-2 libsnmp-dev recommends no packages. libsnmp-dev suggests no packages. -- no debconf information
Bug#990325: evolution: Duplicate to #986218
Package: evolution Version: 3.38.3-1 Followup-For: Bug #990325 Dear Maintainer, Bug #990325 seems to be a duplicate to #986218. Best regards Jan -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/6 CPU threads) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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-12 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 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.32.1-2 ii libxml22.9.10+dfsg-6.7 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 ii network-manager 1.30.0-2 -- debconf information excluded
Bug#990457: [Pkg-nagios-devel] Bug#990457: monitoring-plugins-contrib: Too many things in the same package leads to recommends being ignored most of the time
Hi Gabriel, Am 29.06.21 um 19:34 schrieb Gabriel Filion: I would like to suggest breaking up this package into smaller binary packages that are focused on one application/service per package. This way one could install only the checks that are required with their individual requirements. as you may have read the documentation and used our suggested way to solve your problem by not installing the recommands automatically, our plan worked out. Anyway ... if you would like to do the work to draft such a package split, you can send MRs via https://salsa.debian.org/nagios-team/pkg-nagios-plugins-contrib/, which would be very welcomed. With kind regards, Jan.
Bug#990361: swig4.0 not compatible with nodejs12
Package: swig4.0 Version: 4.0.2-1 Unfortunately, the last released upstream swig version lacked support for nodejs12, which is the version that bullseye ships. I've identified the following four patches from upstream that are needed on top of 4.0.2: 554aeead5 Introduce macros to support both Handle and Local types 26fc996ad Replace Handle with Local depending on Node.js version 113d78a08 Add support for Node.js v12 0e36b5d6f Fixes for node v12.0-12.5 They apply cleanly and resolve the issues I was seeing with building mraa against Debian's swig4.0. Would be great if the bullseye swig package could still be fixed for use with the bullseye nodejs package.
Bug#990302: ITP: bulk-extractor -- A stream-based forensics tool for triage and cross-evidence analysis, which scans the media and extracts recognizable content
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org, debian-security-to...@lists.debian.org Owner: Jan Gru Severity: wishlist * Package name: bulk-extractor Version : 1.6.0 Upstream Author : Simson L. Garfinkel * URL : https://github.com/simsong/bulk_extractor * License : MIT and CC0 Programming Lang: C++, Python (and Java for the BEViewier, probably not packaged) Description : A stream-based forensics tool for triage and cross-evidence analysis, which scans the media and extracts recognizable content bulk_extractor is a program for bulk data extraction and analysis, it carves for relevant features such as email addresses, credit card numbers, URLs, and other types of information from digital evidence files in a stream-based manner by parallelized processing blocks to omit disk seeking. ** Why is this package relevant? It is a useful tool for forensic investigations, because it is way more than just another file carver. The program provides several unusual capabilities including: - It finds email addresses, URLs and credit card numbers that other tools miss because it can process compressed data (like ZIP, PDF and GZIP files) and incomplete or partially corrupted data. - It can carve JPEGs, office documents and other kinds of files out of fragments of compressed data. It will detect and carve encrypted RAR files. - It builds word lists based on all of the words found within the data, even those in compressed files that are in unallocated space. Those word lists can be useful for password cracking. - It is multi-threaded; running bulk_extractor on a computer with twice the number of cores typically makes it complete a run in half the time. - It creates histograms showing the most common email addresses, URLs, domains, search terms and other kinds of information on the drive. The program is authored by the renowned forensics researcher Simson L. Garfinkel, who is probably most recognized for his work on DFXML at the Naval Postgraduate School (NPS) and the National Institute of Standards and Technology (NIST). It provides rich documentation -- for the end-users as well as for potential contributors [0]. To sum it up, bulk_extractor has great potential for improving triage and automatation workflows within digital forensics and should be therefore included in Debian's package sources. ** Resolved issues bulk_extractor is already packaged in Kali [1], but had licensing issues until recently. To be more precise, it linked code with OpenSSL while not explicitly permitting it and used a the modified MIT-license from the JSON-project, which is considered non-free and not DFSG-compliant. To overcome this issues I resolved this issues in cooperation with upstream by sending two recent patches [2], which were already accepted. ** Maintanance plan I plan to maintain it within the pkg-security-team's repository on salsa, where a lot of forensics packages live [3]. I am looking for a sponsor of this package, who would be ideally a member of the a/m team. Best regards Jan [0] See http://digitalcorpora.org/downloads/bulk_extractor/BEUsersManual.pdf, https://digitalcorpora.s3.amazonaws.com/downloads/bulk_extractor/BEProgrammersManual.pdf and https://digitalcorpora.s3.amazonaws.com/downloads/bulk_extractor/BEWorkedExamplesStandalone.pdf [1] See https://tools.kali.org/forensics/bulk-extractor [2] See https://github.com/simsong/bulk_extractor/issues/168, https://github.com/simsong/bulk_extractor/pull/169 and https://github.com/simsong/bulk_extractor/pull/170 [3] See https://salsa.debian.org/pkg-security-team/
Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11
Hello Adrian, hello Samuel, My reading of the code is that it was intended to be -t = set_byte(t, (j-1)%4, sbox[get_byte(k,j)]); +t = set_byte(t, (j-1+4)%4, sbox[get_byte(k,j)]); It's looking good, I have uploaded 1:1.0-10 to unstable, hopefully this was the only issue still affecting other archs. glad, you found this value range issue to make aeskeyfind work on the other architectures! Thanks a lot for working on this! Best regards Jan
Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11
Hello Adrian, hello Samuel, great news! On 10.06.21 03:50, Samuel Henrique wrote: Hello all, Everything about this bug looks like better compiler optimization hitting code with a latent bug, and as expected using either gcc-9 or -O2 "fixes" the problem. Glad, that you could identify the source of the issue and find a workaround! Actually I've stumbled over a similar issue regarding a fork of aeskeyfind a while back, but unfortunately I had not found time yet to check it [0]. Thank you very much for your finding and the explaination! I have uploaded a workaround for this issue (removing the -O4 flag, keeping -O2). It's not an ideal solution but it's better than leaving it broken with -O4, I will be asking the release team to unblock the migration to testing. I appreciate your quick patch, Samuel. Hope, that the workaround will find its way into frozen testing. Thanks! The investment of the time in the autopkgtests was obviously not for nothing... See you Jan [0] https://github.com/makomk/aeskeyfind/issues/2
Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11
Hello Samuel, thank you for your reply. On 07.06.21 17:16, Samuel Henrique wrote: Control: severity -1 normal Hello Jan, Thanks for the detailed explanation and for pushing your integration tests. I have pushed them[0] to the main repo (with the same changes we discussed in the rsakeyfind MR) making use of the "-t 50" parameter. So the package can have integ tests even before we get to solve the problem, I hope you don't mind. Absolutely not, thanks for merging! It looks like it's not gonna be very easy to debug this, and considering the way the package works[1], I'm lowering the severity to normal and I'll likely not gonna try to fix it (anybody reading this please feel free to submit MRs). You could consider to raise the default threshold via a patch as a workaround until the bug can be fixed. What do you think of this proposal? In order to debug this you will probably have to get a stacktrace for two runs of aeskeyfind against the same dump file, one for each version of glibc (or whatever is the suspect), and compare them to see where's the difference in computation occurring for the xor variables. This is gonna be quite complicated as those variables get changed inside a loop (for the chunks of memory retrieved) and you're only interested in one of those iterations (maybe the dump can be simplified to contain only the key). I bet it would be an interesting and cool investigation, but one would have to have enough time for it, so don't feel pressured to do so, the fact that you found the issue and contributed the integ tests already put the package in a much better position. Thanks for the hints. It seems to be challenging and time consuming, indeed. I will put it on my backlog, maybe I will find time to tackle it, but I can't promise that. If someone wants to tackle the issue, it would be great to keep us updated here in this thread. Best regards Jan
Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11
Hello Samuel, On Sat, 29 May 2021 14:06:18 +0100 Samuel Henrique wrote: > > That's a great catch! > I'm bumping the severity as this "makes the package in question > unusable or mostly so". thanks for getting back to me regarding this bug. Since there is just an offset in the values used for key identification, which stems from the `xor_count_256` respectively `xor_count_128`-variable, the package is still kind of usable, if the default threshold is raised -- either manually via `-t 50`or via a patch during compile time. Nevertheless, this should be fixed in a proper way, I think. > I believe you accidentally pasted the same link twice when talking > about two different functions. Yes, this was a faux pas -- sorry for that! The second suspicious function, which I mentioned in my previous message, seems to be `key_core(...)` in `aes.h`. You can find it here [1]. The two referenced functions basically perform the heavy lifting of aeskeyfind's compuations. > Could you submit your tests so we can confirm any fix applied (if we do so)? > I would like to use your tests with git-bisect to make sure this > regression wasn't caused by one of our patches. I am very confident, that the Debian's patches applied during the packaging are fine, since I checked the results of the unmodified upstream source also, which I built by myself and got the same erroneous results. Therefore it looks like to me, that the error stems from some changes related to glibc 2.31-11 (or maybe even the kernel in Version 5.10.0.6). The tests, that I created and which led to uncovering this issue can be found here: https://salsa.debian.org/jgru/aeskeyfind/-/commit/04c9a6038a047fa97e527cc05346416b98949c4c You can get and run those tests with the following commands: ``` git clone g...@salsa.debian.org:jgru/aeskeyfind.git git checkout add-autopkgtests autopkgtest --debug -- schroot sid-amd64 ``` If you remove line 62 of `debian/tests/helpers/ test_aes_extraction.sh` [3] you can preserve the resulting dump for manual testing. If you add `-t 50`to line 56 of `debian/tests/helpers/ test_aes_extraction.sh` [4] the tests will succeed. > > It's possible that this bug also affects rsakeyfind, so I would > appreciate it if you could run your test against that package as well > (I assume it must be easy since they are so similar). > I performed similar tests regarding rsakeyfind and have to say, that this software is not affected at all. Please refer to my merge request containing the autopkgtests for rsakeyfind at [5]. If you have any ideas on how to debug this issue in a targeted manner, please get back to me. Thanks for tackling this problem! Best regards, Jan --- [1] https://salsa.debian.org/pkg-security-team/aeskeyfind/-/blob/debian/master/aes.h#L12 [2] https://citpsite.s3.amazonaws.com/memory-content/src/aeskeyfind-1.0.tar.gz [3] https://salsa.debian.org/jgru/aeskeyfind/-/blob/add-autopkgtests/debian/tests/helpers/test_aes_extraction.sh#L62 [4] https://salsa.debian.org/jgru/aeskeyfind/-/blob/add-autopkgtests/debian/tests/helpers/test_aes_extraction.sh#L56 [5] https://salsa.debian.org/pkg-security-team/rsakeyfind/-/merge_requests/2?commit_id=e7d030704f56c84ff48893883af2c5cc46414c4b
Bug#989411: podman: Please add zsh completion to podman package.
Package: podman Version: 3.0.1+dfsg1-2 Severity: wishlist Tags: patch X-Debbugs-Cc: k...@wrzask.pl Dear Maintainer, * What led up to the situation? I'm using zsh, completion for podman is not installed by the package (only bash completion is included). Solution is simple: $ podman completion zsh -f /usr/share/zsh/vendor-completions/_podman ... will produce the completion file in a proper location for zsh autolads. -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.16.3-microsoft-standard-WSL2 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages podman depends on: ii conmon 2.0.25+ds1-1 ii containernetworking-plugins 0.9.0-1+b3 ii crun 0.17+dfsg-1 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-12 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1 ii runc 1.0.0~rc93+ds1-5 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1+b2 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b4 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 -- no debconf information
Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11
Package: aeskeyfind Version: 1:1.0-8 Severity: important Tags: upstream Dear Maintainer, I was in the process of creating autopkgtests for aeskeyfind and discovered, that using aeskeyfind with kernel 5.10.0.6 and glibc 2.31-11 leads to wrong results. Existing AES-keys are not found, although they are and extracted by aeskeyfind on kernel 5.4.0.73 and glibc 2.27 at least. Further testing revelead, that the values of the variables named xor_count_128 and xor_count_256 are higher in the failing setup. This seems to stem from the following two functions: https://salsa.debian.org/pkg-security-team/aeskeyfind/-/blob/debian/master/util.h#L25 https://salsa.debian.org/pkg-security-team/aeskeyfind/-/blob/debian/master/util.h#L25 Unfortunately there is no upstream maintainer, so that I file a bug on Debian's BTS, since it is a serious issue for the functionality of the package. A temporary workaround is to set the threshold higher to overcome the miscalculated xor_count_*. Best regards, Jan -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/1 CPU thread) 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 aeskeyfind depends on: ii libc6 2.31-11 aeskeyfind recommends no packages. aeskeyfind suggests no packages. -- no debconf information
Bug#988588: ftp.debian.org: please REJECT rust-rustls-native-certs from NEW queue
Package: ftp.debian.org Severity: normal The package rust-rustls-native-certs I uploaded 3 days ago contains a diff from upstream which may be a bad idea (changing a dependency to an older version). I'm currently not sure what's the best way to fix the issue, so I can't just upload an updated version. Therefore, please REJECT the upload.
Bug#988012: Bug#988190: unblock: diaspora-installer/0.7.14.0+debian2
Am 14.05.21 um 12:46 schrieb Pirate Praveen: Tracker says it will be auto removed by May 25 and 15 more days are needed for migration. Does it mean, this missed bullseye? 0.7.14.0+debian2+nmu2 would have been in time. Cheers, Jan.
Bug#985336: #985336 not fixed (anymore)
reopen 985336 thx As 0.7.15.0+debian does not incorporate the changes done by 0.7.14.0+debian2+nmu1 and 0.7.14.0+debian2+nmu2 (where are the changelogs?) this bug is present in 0.7.15.0+debian again! Cheers, Jan. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK--
Bug#988012: unblock: diaspora-installer/0.7.14.0+debian2+nmu2
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package diaspora-installer I prepared a fix for #986286 and uploaded it to unstable, this fixed the problem that the Gemfile.lock included unavailable software versions. Gunnar Wolf also fixed #985336 by adding the dependenciy of tzdata. Both are RC bugs. Beside that, there seems to be some other minor fixes in the debdiff, which seems to be part of nmu1. Those are (beside the small fix of the unitfile) documentational fixes. [ Reason ] Fixeing two RC bugs. [ Impact ] The package can not be installed without a fixed #986286. [ Tests ] I did run autopkg tests locally. [ Risks ] I see no higher risk for users compared to 0.7.14.0+debian2 [ Checklist ] [ ] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock diaspora-installer/0.7.14.0+debian2+nmu2
Bug#987488: unblock: ircci/20210314-1
Hi Daniel, Am 28.04.21 um 18:52 schrieb Daniel Echeverri: I will go to work in this, but I'm not sure how is the best way in the case. Could you give a orientation? I think I can't make a complete debdiff because in version unstable I bumped debhelper to 13 and this change is not accepted at this stage of the release. I think you need to prepare a new package version where you revert the debhelper bump. Anyway ... in this case I would ask RM for a pre-approval before uploading the new package to unstable (see bugs.debian.org/987178 for an example). This may save time for possible reupload, if RM requests more changes. Cheers, Jan. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK--
Bug#987586: ITP: regripper -- perform forensic analysis of registry hives
Package: wnpp Severity: wishlist Owner: Jan Gru X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: regripper Version : 3.0 Upstream Author : Harlan Carvey * URL : https://github.com/keydet89/RegRipper3.0 * License : MIT Programming Lang: Perl Description : Regripper - perform forensic analysis of registry hives Bcc: Jan Gru Regripper is a popular tool to perform forensic analysis of Windows Registry files. It can be used to surgically extract, translate, and display information (both data and metadata) from Registry-formatted files via plugins in the form of Perl-scripts. ** Why is this package relevant? Regripper has an ancestral place in digital forensics and incident response with open source tools. Right now there are no other Debian packages providing similiar functionality. It was developed by the renowned author Harlan Carvey [fn:1]. It provides the capability to parse and analyze offline Windows registry files, which house a lot of valuable information needed in DFIR work. Regripper is the goto tool for performing open source DFIR work on Windows systems [fn:2]. There exist numerous guides dealing with the installation procedure of regripper on Linux systems [fn:3]. Therefore is a need for a regripper package. I am using it myself on a regular basis to perform DFIR work. ** Maintenance plan I want to suggest to maintain regripper inside the pkg-security-team's repository on salsa, where a lot of forensics packages live [fn:4]. I am looking for a sponsor for this package - ideally a member of the pkg-security-team. ** Footnotes [fn:1] E.g. see https://www.sans.org/blog/book-review-windows-forensic-analysis/ [fn:2] And even giants like Autopsy rely on regripper for registry parsing, see https://www.sleuthkit.org/autopsy/features.php [fn:3] See https://medium.com/@virtual_alloc/installing-regripper-v2-8-on-ubuntu-e30dfb41192c, https://blog.dfir.fi/tools/2020/02/19/install-regripper.html, https://thegreycorner.com/2010/04/25/running-regripper-on-linux.html to name a few [fn:4] See https://salsa.debian.org/pkg-security-team/
Bug#986286: diaspora-installer: fails to install: Your bundle is locked to mimemagic (0.3.5), but that version could not be found
Hi there,
based on https://github.com/diaspora/diaspora/pull/8231 I adjusted
diaspora-download.sh to change Gemfile.lock accordingly and uploaded the
package 0.7.14.0+debian2+nmu2 to DELAYED/5. The diff is attached.
Cheers, Jan.
--
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--
commit 0e50f2ba851d216c801029a27c7fda9e6ff15160
Author: Jan Wagner
Date: Sun Apr 25 23:53:28 2021 +0200
Fix #986286
diff --git a/debian/changelog b/debian/changelog
index 719be1d..11ec0b5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+diaspora-installer (0.7.14.0+debian2+nmu2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Adjust diaspora-download.sh to modify Gemfile.lock so mimemagic (0.3.10)
+is used (beside nokogiri (~> 1) and rake), upstream change 79133df
+(Closes: #986286)
+
+ -- Jan Wagner Sun, 25 Apr 2021 23:33:26 +0200
+
diaspora-installer (0.7.14.0+debian2+nmu1) unstable; urgency=medium
* Non-maintainer upload
diff --git a/diaspora-download.sh b/diaspora-download.sh
index 2318c4a..ffa1ff2 100755
--- a/diaspora-download.sh
+++ b/diaspora-download.sh
@@ -43,7 +43,7 @@ cp -r ${diaspora_cache}/${diaspora_archive}/public/* ${diaspora_user_home}/publ
chown -R ${diaspora_user}: ${diaspora_user_home}/public
chown -R ${diaspora_user}: ${diaspora_user_home}/app-assets
# Remove BUNDLED WITH from Gemfile.lock to allow using packaged bundler
-head -n -3 ${diaspora_cache}/${diaspora_archive}/Gemfile.lock > ${diaspora_home}/Gemfile.lock
+head -n -3 ${diaspora_cache}/${diaspora_archive}/Gemfile.lock | sed "s/mimemagic (0.3.5)/mimemagic (0.3.10)\n nokogiri (~> 1)\n rake/" > ${diaspora_home}/Gemfile.lock
echo "Copying source tarball to ${diaspora_user_home}/public..."
cp -f ${diaspora_cache}/diaspora-${diaspora_version}.tar.gz ${diaspora_user_home}/public/source.tar.gz
Bug#987488: unblock: ircci/20210314-1
Hi there, Am 25.04.21 um 09:35 schrieb Graham Inggs: Control: retitle -1 unblock: ircii/20210314-1 Contro: tags -1 + moreinfo Hi Jan On Sat, 24 Apr 2021 at 16:21, Jan Wagner wrote: [ Risks ] While the diffstat looks huge, a significant part is removed code. This debdiff is unreviewable. Please provide a filtered debdiff along with the command used to filter it. ++ Bump Debhelper-compat to 13. Bumping the debehlper compat level is not accepted at this stage of the release [1]. Please revert this change. security stated, that ircii might not qualify to be released with bullseye (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987537#10). I think I would leave it up to Daniel, who did the QA upload, if it's worth to work on this. If nobody is caring about ircii in bullseye, we should close this bug here. With kind regards, Jan.
Bug#987488: (no subject)
user debian-rele...@lists.debian.org usertags -1 + bsp-2021-04-AT-Salzburg thank you
Bug#986908: unblock: snort 2.9.15.1-5
Control: tags -1 - moreinfo
Hi there,
Am 22.04.21 um 11:03 schrieb Javier Fernandez-Sanguino:
On Mon, 19 Apr 2021 at 23:24, Chris Hofstaedtler <mailto:z...@debian.org>> wrote:
> $ debdiff snort_2.9.15.1-4_i386.deb snort_2.9.15.1-5_i386.deb
[..]
The debdiff does not seem to show any actual packaging changes. Are
you sure you diffed the correct files?
Apologies, I sent a debdiff of the binary packages. I will send a
debdiff of the source packages soon.
here is the debdiff between 2.9.15.1-4 and 2.9.15.1-5.
Cheers, Jan.
--
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--
diff -Nru snort-2.9.15.1/debian/changelog snort-2.9.15.1/debian/changelog
--- snort-2.9.15.1/debian/changelog 2020-12-06 17:23:14.0 +0100
+++ snort-2.9.15.1/debian/changelog 2021-04-10 22:55:04.0 +0200
@@ -1,3 +1,30 @@
+snort (2.9.15.1-5) unstable; urgency=medium
+
+ * debian/snort-common.{preinst,postinst,postrm}:
+- Handle using dpkg-maintscript-helper mv_conffile the relocation
+ of the cronjob /etc/cron.daily/5snort to /etc/cron.daily/snort-common
+ instead of moving it manually to prevent dpkg from prompting the
+ user upon upgrades from older snort version. Thank you
+ Chris Hofstaedtler for the tip (Closes: #984614)
+ * debian/control: Add Pre-Depends: dpkg (>= 1.17.14) as we
+are now using dpkg-maintscript-helper
+ * debian/snort-common.{postrm,preinst},
+debian/snort.{postinst,postrm,preinst,prerm}:
+Add DEBIAN_SCRIPT_DEBUG to all maintainer scripts
+ * debian/snort.logrotate: Correct name of the alert files (snort.alert
+and not 'alert') this error prevented files from being properly
+logrotated
+ * configure.in: Added patch to check if rpc/rpc.h is required and is
+provided by libtirpc-dev to warn Ubuntu users that libtirpc-dev is
+required.
+Note: not added libtirpc-dev to Build-Depends as Debian's glibc6-dev
+includes the RPC headers (LP: #1906572)
+ * debian/patches/decoding_do_not_assume_ipv4: Add patch provided by Hugh
+Davenport to not assume that all raw packets are IPv4 packets.
+(Closes: 633066)
+
+ -- Javier Fernández-Sanguino Peña Sat, 10 Apr 2021
22:55:04 +0200
+
snort (2.9.15.1-4) unstable; urgency=high
* debian/snort.docs, debian/snort-doc.docs debian/rules: Add README.csv and
@@ -21,6 +48,9 @@
* debian/rules, debian/snort-common-libraries.dirs, debian/patches/config:
Do not use multi-arch directories for the Snort libraries, instead, locate
all
of the compiled under libraries /usr/lib/snort (Closes: #962275)
+ This fixes the error "FATAL ERROR: /etc/snort/snort.conf(271) Could not stat
+ dynamic module path "/usr/lib/i386-linux-gnu/snort_dynamicpreprocessor/": No
+ such file or directory" (LP: #1901466, #1902405, #1905164)
* debian/rules: Drop configure options which are not anymore relevant
* debian/po:
- Update Dutch translation, thanks to Frans Spiesschaert (Closes: #961214)
@@ -101,7 +131,8 @@
(LP: #1570517, #1484733, #1398969, #1310182, #1273021, #1231833)
(LP: #1222754, #1215408, #1207981, #1207237, #1181514, #1175892)
(LP: #1175264, #1161358, #1158169, #1116013, #1065121, #1064478)
-(LP: #1061459, #1031917)
+(LP: #1061459, #1031917, #1905137, #1897344, #1896849, #1882601)
+(LP: #1881141, #1877638)
- Add also debugging messages as, based on the number of reports in
Ubuntu, there seems to be many cases where the users install the
package (with high debconf priority) and the proper network interface
diff -Nru snort-2.9.15.1/debian/control snort-2.9.15.1/debian/control
--- snort-2.9.15.1/debian/control 2020-12-06 17:23:14.0 +0100
+++ snort-2.9.15.1/debian/control 2021-04-10 22:55:04.0 +0200
@@ -65,7 +65,7 @@
Package: snort-common
Architecture: all
-Pre-Depends: adduser (>= 3.11), ${misc:Pre-Depends}
+Pre-Depends: adduser (>= 3.11), dpkg (>= 1.17.14), ${misc:Pre-Depends}
Depends:
perl,
debconf (>= 0.2.80) | debconf-2.0,
diff -Nru snort-2.9.15.1/debian/patches/decoding_do_not_assume_ipv4
snort-2.9.15.1/debian/patches/decoding_do_not_assume_ipv4
--- snort-2.9.15.1/debian/patches/decoding_do_not_assume_ipv4 1970-01-01
01:00:00.0 +0100
+++ snort-2.9.15.1/debian/patches/decoding_do_not_assume_ipv4 2021-04-10
22:55:04.0 +0200
@@ -0,0 +1,48 @@
+Description: Do not assume IPv4 packets when decoding
+ When using Snort on a interface without a link level layer, for example a
+ AIYIA tunnel for IPv6 through SixXs, then snort assumes that the packets will
+ be IPv4. I have a patch that adds a check on the IP version number in the
+ header, and if it is not an
Bug#987178: [pre-approval] unblock: monitoring-plugins/2.3.1-1
Control: tags -1 - moreinfo Am 21.04.21 um 23:06 schrieb Sebastian Ramacher: On 2021-04-19 10:03:12 +0200, Jan Wagner wrote: Package: release.debian.org User:release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package monitoring-plugins 2.3.1-1 The new package is already uploaded to experimental as 2.3.1-1~exp2, but I did not upload 2.3.1-1 unto unstable yet. I'm waiting here for an approval. > ACK. Please remove the moreinfo tag once the new version is available in unstable. 2.3.1-1 is uploaded to unstable. Many thanks, Jan.
Bug#984944: evolution: Unable to print in 3.38.3, fixed in 3.38.4
Package: evolution Version: 3.38.3-1 Followup-For: Bug #984944 Dear Maintainer, I’m rather unhappy to report so late in the release cycle that printing e-mails from Evolution is broken in version 3.38.3, which is the candidate for Bullseye. Trying to print an e-mail to a printer results in a “printer not found” error message, trying to print to a PDF will create “file not found”. I can trigger this bug on two different boxes. Some corresponding upstream bugs appear to be (at least) * https://gitlab.gnome.org/GNOME/evolution/-/issues/1404 * https://gitlab.gnome.org/GNOME/evolution/-/issues/1141 * https://bugs.webkit.org/show_bug.cgi?id=202363 The suggested workaround $ WEBKIT_FORCE_SANDBOX=0 evolution works for me. I consider being unable to print mail a serious flaw. Best regards Jan -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/6 CPU threads) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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-11 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-3 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.30.6-1 ii libxml22.9.10+dfsg-6.3+b1 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-1 ii network-manager 1.30.0-2 -- debconf information excluded
Bug#986563: [Pkg-nagios-devel] Bug#986563: monitoring-plugins-contrib: check_ssl_cert Renegotiation test broken with STARTTLS
Package: nagios-plugins-contrib Version: 34.20210407+1 Hi Slavko, Am 07.04.21 um 14:52 schrieb Slavko: The currently shipped check_ssl_cert has broken Renegotiation test, which uses plain ports with STARTTLS certificate checks. It was fixed by upstream, see https://github.com/matteocorti/check_ssl_cert/issues/272 in the 2.0.1 version. thanks for bringing this to our attention. It was fixed with upload 34.20210407+1. Cheers, Jan.
Bug#907308: Upstream bug
The bug occurs on all systems with sufficiently new GNU libc, not just Debian, so it is an upstream bug. Unfortunately the mailing list mentioned on the linked homepage is dead (even the server is) and I failed to find any other, more recent continuation or fork of the project.
Bug#985370: apache2: HEAD requests are empty when mod_ratelimit is enabled
Package: apache2 Version: 2.4.38-3+deb10u4 Severity: normal Dear Maintainer, I have set up a site with mod_ratelimit enabled. Then HEAD requests sent by curl are logged as sent (with some size), anyway curl reports url: (52) Empty reply from server Disabling the rate limit (while keeping the mod loaded) makes HEAD requests work OK. -- Package-specific info: -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apache2 depends on: ii apache2-bin2.4.38-3+deb10u4 ii apache2-data 2.4.38-3+deb10u4 ii apache2-utils 2.4.38-3+deb10u4 ii dpkg 1.18.22 ii lsb-base 9.20161125 ii mime-support 3.60 pn perl:any ii procps 2:3.3.12-3+deb9u1 Versions of packages apache2 recommends: ii ssl-cert 1.0.38 Versions of packages apache2 suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii elinks [www-browser] 0.12~pre6-12 ii firefox-esr [www-browser]78.8.0esr-1~deb10u1 ii links [www-browser] 2.14-2 ii w3m [www-browser]0.5.3-34 Versions of packages apache2-bin depends on: ii libapr1 1.6.5-1+b1 ii libaprutil1 1.6.1-4 ii libaprutil1-dbd-sqlite3 1.6.1-4 ii libaprutil1-ldap 1.6.1-4 ii libbrotli1 1.0.7-2+deb10u1 ii libc62.28-10 ii libcurl4 7.64.0-4+deb10u1 ii libjansson4 2.12-1 ii libldap-2.4-22.4.47+dfsg-3+deb10u6 ii liblua5.2-0 5.2.4-1.1+b1 ii libnghttp2-141.36.0-2+deb10u1 ii libpcre3 2:8.39-2 ii libssl1.11.1.1d-0+deb10u5 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 pn perl:any ii zlib1g 1:1.2.11.dfsg-1 Versions of packages apache2-bin suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii elinks [www-browser] 0.12~pre6-12 ii firefox-esr [www-browser]78.8.0esr-1~deb10u1 ii links [www-browser] 2.14-2 ii w3m [www-browser]0.5.3-34 Versions of packages apache2 is related to: ii apache2 2.4.38-3+deb10u4 ii apache2-bin 2.4.38-3+deb10u4 -- no debconf information
Bug#985145: unblock: nagios-check-xmppng/0.3.2-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package nagios-check-xmppng
I am upstream of the packaged plugin and received a bug report [1] just
a few days before the end of the soft freeze. The bugfix is quite
minimal and just removes a certificate statistic check. I tested the
plugin against a set of XMPP servers with the Python version in testing
and it worked fine.
[1] https://git.dittberner.info/jan/check_xmppng/issues/2
[ Reason ]
The package that is currently in testing still has the bug and only
works on XMPP servers that allow non TLS connections. The new version
fixes the broken TLS handling.
[ Impact ]
The users will have a version of the plugin that will not be usable to
check working TLS functionality of their XMPP servers.
[ Tests ]
I tested against a set of XMPP servers (my own one and the server of the
upstream bug reporter). Piuparts is happy and I tested the package
installation on a workstation machine that uses Debian testing.
[ Risks ]
Code changes are quite trivial, the risk is minimal from my point of
view and will only affect the package itself.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
-
unblock nagios-check-xmppng/0.3.2-3
diff -Nru nagios-check-xmppng-0.3.0/changes.md
nagios-check-xmppng-0.3.2/changes.md
--- nagios-check-xmppng-0.3.0/changes.md2016-06-18 21:24:23.0
+0200
+++ nagios-check-xmppng-0.3.2/changes.md2021-03-07 14:14:06.0
+0100
@@ -1,5 +1,13 @@
# change log
+## version 0.3.2 2021-03-07
+
+* remove brokebn CA certificate statistics
+
+## version 0.3.1 2019-06-23
+
+* move to new project location
+
## version 0.3.0 2016-06-18
* add alternative --hostname parameter to make check_xmpp compatible with
diff -Nru nagios-check-xmppng-0.3.0/check_xmppng
nagios-check-xmppng-0.3.2/check_xmppng
--- nagios-check-xmppng-0.3.0/check_xmppng 2016-06-18 21:24:23.0
+0200
+++ nagios-check-xmppng-0.3.2/check_xmppng 2021-03-07 14:14:06.0
+0100
@@ -2,7 +2,7 @@
# -*- coding: utf-8 -*-
#
# Nagios compatible check for XMPP servers.
-# Copyright (C) 2015-2016 Jan Dittberner
+# Copyright (C) 2015-2021 Jan Dittberner
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -31,7 +31,7 @@
import nagiosplugin
__author__ = "Jan Dittberner"
-__version__ = "0.2"
+__version__ = "0.3.2"
NS_IETF_XMPP_SASL = 'urn:ietf:params:xml:ns:xmpp-sasl'
@@ -335,14 +335,6 @@
context.load_verify_locations(**kwargs)
else:
context.load_default_certs()
-stats = context.cert_store_stats()
-if stats['x509_ca'] == 0:
-_LOG.info(
-"tried to load CA certificates from default locations, but"
-" could not find any CA certificates.")
-raise XmppException('no CA certificates found')
-else:
-_LOG.debug('certificate store statistics: %s', stats)
return context
def initiate_tls(self):
diff -Nru nagios-check-xmppng-0.3.0/debian/changelog
nagios-check-xmppng-0.3.2/debian/changelog
--- nagios-check-xmppng-0.3.0/debian/changelog 2021-01-05 18:30:11.0
+0100
+++ nagios-check-xmppng-0.3.2/debian/changelog 2021-03-08 18:24:39.0
+0100
@@ -1,9 +1,30 @@
-nagios-check-xmppng (0.3.0-1.1) unstable; urgency=medium
+nagios-check-xmppng (0.3.2-3) unstable; urgency=medium
- * Non maintainer upload by the Reproducible Builds team.
- * No source change upload to rebuild on buildd with .buildinfo files.
+ * Source only upload for migration to testing
- -- Holger Levsen Tue, 05 Jan 2021 18:30:11 +0100
+ -- Jan Dittberner Mon, 08 Mar 2021 18:24:39 +0100
+
+nagios-check-xmppng (0.3.2-2) unstable; urgency=medium
+
+ * Re-upload to unstable
+
+ -- Jan Dittberner Sun, 07 Mar 2021 15:17:20 +0100
+
+nagios-check-xmppng (0.3.2-1) experimental; urgency=medium
+
+ * New upstream version
+ * debian/control:
+- Change priority from deprecated extra to optional
+- Switch VCS-URL and VCS-Browser to new URLs
+- Bump Standards-Version to 4.5.1
+- Update to debhelper 12
+ * add debian/watch
+ * Fix "Don't depend on nagios3 which has been removed from unstable"
+by dropping the nagios3 suggests (Closes: #846873)
+ * Fix "Change icinga dependency to icinga2" by dropping the icinga suggests
+(Closes: #933258)
+
+ -- Jan Dittberner Sun, 07 Mar 2021 15:00:32 +0100
nagios-check-xmppng (0.3.0-1) unstable; urgency=medium
diff -Nru nagios-check-xmppng-0.3.0/debian/compat
nagios-check-xmppng-0.3.2/debian/compat
--- nagios-check-xmppng-0.3.0/debian/compat
Bug#984873: linux-image-5.10.0-4-arm64: RPi4 8 GB lost USB support (doesn't start with / on USB device)
Package: src:linux Version: 5.10.19-1 Severity: critical Justification: breaks the whole system Dear Maintainer, Updating from linux-image-5.9.0-4-arm64 to linux-image-5.10.0-3/4-arm64 resulted in a non-booting system due to missing/incorrect USB support for the RPi4 8GB. (system has / on USB SSD) Only method to get the system booting again is to change config.txt to boot the available 5.9.0-4 kernel. System came up as expected. With the 5.10 kernels I tested (-3 and -4 packages) the boot halted after detecting the partitions on mmcblk1 , on 5.9.0-4 it continues to detect the storange via USB and boots from it. Regards, Jan Huijsmans -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information Device Tree model: Raspberry Pi 4 Model B Rev 1.4 ** PCI devices: not available ** USB devices: Bus 002 Device 002: ID 0578:0578 Intrinsix Corp. KingSpec Z3-128 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 413c:2003 Dell Computer Corp. Keyboard SK-8115 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (1001, 'testing'), (100, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.9.0-4-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.ISO8859-15, LC_CTYPE=en_US.ISO8859-15 (charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO8859-15), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-5.10.0-4-arm64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.139 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.10.0-4-arm64 recommends: ii apparmor 2.13.6-9 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.10.0-4-arm64 suggests: pn debian-kernel-handbook pn linux-doc-5.10 Versions of packages linux-image-5.10.0-4-arm64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x ii firmware-brcm8021120210208-3 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#983645: laminard killed with SIGSEGV (was: Bug#983645: laminard: SIGPIPE kills it)
Hi Ruben!
On Tue, 2021-03-02 23:41:30 +0100, Jan-Benedict Glaw wrote:
> SIGPIPE was a red herring, it happens ever so often and is ignored.
> But there's a SIGSEGV:
[...]
My impression is that access to the logWatchers isn't locked, so
incoming log output (from some run) are pushed by iterating over
current logWatchers. However, if a logWatcher goes away, it's still
referenced during the push loop.
287 void Http::notifyLog(std::string job, uint run, std::string log_chunk, bool
eot)
288 {
289 for(LogWatcher* lw : logWatchers) {
290 if(lw->job == job && lw->run == run) {
291 lw->pendingOutput.push_back(kj::mv(log_chunk));
292 lw->fulfiller->fulfill(kj::mv(eot));
293 }
294 }
295 }
Seems it's quite easily triggered by having a job that logs _lots_ of
lines and playing with a browser's reload button...
MfG, JBG
--
signature.asc
Description: PGP signature
Bug#983645: laminard killed with SIGSEGV (was: Bug#983645: laminard: SIGPIPE kills it)
On Tue, 2021-03-02 16:27:27 +0100, meskio wrote:
> Quoting Jan-Benedict Glaw (2021-03-02 14:44:33)
> > > If you are able to test your laminar with systemd tell me if your problem
> > > persist there.
> >
> > I'll try to pin down in which circumstances this actually happens.
>
> Good luck with it. If you don't find anything we can open an issue upstream,
> Oliver is pretty responsive and helpful.
SIGPIPE was a red herring, it happens ever so often and is ignored.
But there's a SIGSEGV:
(gdb) run -v
Starting program: /usr/sbin/laminard -v
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
laminard version 1.0 started
rpc.cpp:55: info: RPC queue; jobName = binutils-vax-linux-gnu
[Detaching after fork from child process 21674]
laminar.cpp:672: info: Started job; run->name = binutils-vax-linux-gnu;
run->build = 8; ctx->name = default
Program received signal SIGSEGV, Segmentation fault.
Http::notifyLog (this=this@entry=0x5560aa10, job="binutils-vax-linux-gnu",
run=run@entry=8, log_chunk="", eot=, eot@entry=false) at
/usr/include/kj/memory.h:224
224 in /usr/include/kj/memory.h
(gdb) bt
#0 Http::notifyLog (this=this@entry=0x5560aa10,
job="binutils-vax-linux-gnu", run=run@entry=8, log_chunk="", eot=, eot@entry=false) at /usr/include/kj/memory.h:224
#1 0x5557ccd9 in operator() (n=, b=,
__closure=0x7fffd020) at ./src/laminar.cpp:659
#2 std::__invoke_impl,
int)::&, char const*, long unsigned int> (__f=...)
at /usr/include/c++/10/bits/invoke.h:60
#3 std::__invoke_r,
int)::&, char const*, long unsigned int>
(__fn=...) at /usr/include/c++/10/bits/invoke.h:110
#4 std::_Function_handler, int)::
>::_M_invoke(const std::_Any_data &, const char *&&, unsigned long &&)
(__functor=..., __args#0=,
__args#1=) at /usr/include/c++/10/bits/std_function.h:291
#5 0x555bb11d in std::function::operator()(char const*, unsigned long) const (__args#1=,
__args#0=, this=0x55859778) at
/usr/include/c++/10/bits/std_function.h:622
#6 operator() (__closure=0x55859760, sz=) at
./src/server.cpp:151
#7 0x555bc219 in kj::_::MaybeVoidCaller >::apply):: >
(in=@0x7fffd568: 4, func=...)
at /usr/include/kj/async-prelude.h:134
#8 kj::_::TransformPromiseNode, long unsigned int,
Server::handleFdRead(kj::AsyncInputStream*, char*, std::function)::,
kj::_::PropagateException>::getImpl(kj::_::ExceptionOrValue &) (
this=0x55859740, output=...) at /usr/include/kj/async-inl.h:401
#9 0x77cd1502 in
kj::_::TransformPromiseNodeBaseoperator()
(__closure=0x7fffd928, __closure=0x7fffd928) at src/kj/async.c++:703
#10
kj::_::RunnableImpl
>::run(void) (this=0x7fffd920) at src/kj/exception.h:302
#11 0x77c4af9b in kj::_::runCatchingExceptions (runnable=warning: RTTI
symbol not found for class
'kj::_::RunnableImpl'
...) at src/kj/exception.c++:1023
#12 0x77cd06fa in
kj::runCatchingExceptions
> (func=...) at src/kj/common.h:514
#13 kj::_::TransformPromiseNodeBase::get (this=, output=...) at
src/kj/async.c++:703
#14 0x77cd51e9 in kj::_::ChainPromiseNode::fire (this=0x558a3ba0)
at src/kj/async.c++:855
#15 0x77cd0e3c in kj::EventLoop::turn (this=0x55609f98) at
src/kj/async.c++:373
#16 0x77cd60c5 in kj::_::waitImpl (node=..., result=..., waitScope=...)
at src/kj/async.c++:440
#17 0x555ba1cc in kj::Promise::wait (waitScope=...,
this=0x7fffe490) at /usr/include/kj/async-inl.h:902
#18 Server::start (this=0x5560a1e0) at ./src/server.cpp:56
#19 0x5557aeba in main (argc=, argv=) at
./src/main.cpp:98
(gdb) bt full
#0 Http::notifyLog (this=this@entry=0x5560aa10,
job="binutils-vax-linux-gnu", run=run@entry=8, log_chunk="", eot=, eot@entry=false) at /usr/include/kj/memory.h:224
lw = 0x5585f290
__for_range = std::set with 1 element = {[0] = 0x5585f290}
Python Exception value has been optimized out:
__for_begin =
Python Exception value has been optimized out:
__for_end =
#1 0x5557ccd9 in operator() (n=, b=,
__closure=0x7fffd020) at ./src/laminar.cpp:659
s = "yes\n"
run =
this = 0x5564b310
Python Exception value has been optimized out:
run =
this =
Python Exception value has been optimized out:
s =
#2 std::__invoke_impl,
int)::&, char const*, long unsigned int> (__f=...)
at /usr/include/c++/10/bits/invoke.h:60
No locals.
#3 std::__invoke_r,
int)::&, char const*, long unsigned int>
(__fn=...) at /usr/include/c++/10/bits/invoke.h:110
No locals.
#4 std::_Function_handler, int)::
>::_M_invoke(const std::_Any_data &, const char *&&, unsigned long &&)
(__functor=...,
Bug#983645: laminard: SIGPIPE kills it
On Tue, 2021-03-02 16:27:27 +0100, meskio wrote: > Quoting Jan-Benedict Glaw (2021-03-02 14:44:33) > > I do not think that SysV init has something to do with the SIGPIPE. > > It's probably being a close()d / shutdown()ed FD (at the browser side) > > while it tries to chunk-send data. > > > > However, with systemd you'd probably get a restart of laminard. You > > may observe a failed / missing run, but because daemon(1) won't do > > a restart, laminard dies for me without getting a recovery by restart. > > At least on my case this is not the problem. I see the laminard hasn't being > restarted in my server for the last 20 days, and I do run several jobs per > day > and some of them I do watch them while they play. But there might be > something > different on my setup. > > > > If you are able to test your laminar with systemd tell me if your problem > > > persist there. > > > > I'll try to pin down in which circumstances this actually happens. > > Good luck with it. If you don't find anything we can open an issue upstream, > Oliver is pretty responsive and helpful. I had quite a few runs in parallel, and over the day it was like 700 or something in that order. The database was quite busy following stdout/stderr from all the builds and even watching the logs (or downloading them as a whole) took noticeable time. I guess it was in such a situation that GETs were aborted (tabs closed / reloaded). MfG, JBG -- signature.asc Description: PGP signature
Bug#983645: laminard: SIGPIPE kills it
Hi! On Tue, 2021-03-02 14:01:13 +0100, meskio wrote: > Quoting Jan-Benedict Glaw (2021-02-27 23:31:57) > > I gave laminar a try, but laminard dies on SIGPIPE: [...] > From that report I guess you use sysv-init instead of systemd isn't it? Maybe > the SIGPIPE error is also related to that. I have to say I didn't test it on > any > other setup than systemd. I don't have at hand a sysv-init system, I'll try > to > setup one. > > If you are able to test your laminar with systemd tell me if your problem > persist there. So by now, I'm quite convinced that you don't "see" these errors because systemd just restarts laminard. Just started to pull the Debian source and the upstream and realized that the Debian package is nearly about the same as GIT master. That's great news! Thanks for providing a really up-to-date package! :) MfG, JBG -- signature.asc Description: PGP signature
Bug#983645: laminard: SIGPIPE kills it
Hi meskio! On Tue, 2021-03-02 14:01:13 +0100, meskio wrote: > Jan-Benedict, thanks for the report. > Quoting Jan-Benedict Glaw (2021-02-27 23:31:57) > > I gave laminar a try, but laminard dies on SIGPIPE: > > > > (gdb) bt > > #0 0x7f7f95d53da3 in __GI___writev (fd=16, iov=0x7ffdebf13860, > > iovcnt=3) at ../sysdeps/unix/sysv/linux/writev.c:26 > > #1 0x7f7f963d8269 in non-virtual thunk to kj::(anonymous > > namespace)::AsyncStreamFd::write(kj::ArrayPtr > const> const>) () at src/kj/async-inl.h:403 > > #2 0x7f7f96487dc6 in kj::(anonymous > > namespace)::HttpOutputStreamoperator() > > (__closure=0x56237a1a5410) at src/kj/compat/http.c++:1661 > > #3 kj::_::MaybeVoidCaller > > >::apply > namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr > kj::ArrayPtr >):: > (func=..., func=..., > > in=...) at ./src/kj/async-prelude.h:148 > > #4 kj::_::TransformPromiseNode, kj::_::Void, > > kj::(anonymous > > namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr > kj::ArrayPtr >)::, > > kj::_::PropagateException>::getImpl(kj::_::ExceptionOrValue &) > > (this=0x56237a1a53f0, output=...) at ./src/kj/async-inl.h:401 > > #5 0x7f7f9638c502 in > > kj::_::TransformPromiseNodeBaseoperator() > > (__closure=0x7ffdebf14188, __closure=0x7ffdebf14188) at src/kj/async.c++:703 > > #6 > > kj::_::RunnableImpl > > >::run(void) (this=0x7ffdebf14180) at src/kj/exception.h:302 > > #7 0x7f7f96305f9b in kj::_::runCatchingExceptions (runnable=warning: > > RTTI symbol not found for class > > 'kj::_::RunnableImpl' > > ...) at src/kj/exception.c++:1023 > > #8 0x7f7f9638b6fa in > > kj::runCatchingExceptions > > > (func=...) at src/kj/common.h:514 > > #9 kj::_::TransformPromiseNodeBase::get (this=, output=...) > > at src/kj/async.c++:703 > > #10 0x7f7f963901e9 in kj::_::ChainPromiseNode::fire > > (this=0x56237a1b2cd0) at src/kj/async.c++:855 > > #11 0x7f7f9638be3c in kj::EventLoop::turn (this=0x56237a17df98) at > > src/kj/async.c++:373 > > #12 0x7f7f963910c5 in kj::_::waitImpl (node=..., result=..., > > waitScope=...) at src/kj/async.c++:440 > > #13 0x562378dde1cc in kj::Promise::wait (waitScope=..., > > this=0x7ffdebf14cf0) at /usr/include/kj/async-inl.h:902 > > #14 Server::start (this=0x56237a17e1e0) at ./src/server.cpp:56 > > #15 0x562378d9eeba in main (argc=, argv=) > > at ./src/main.cpp:98 > > > > > > This is while one job is running and I'm following it's build log on > > the /jobs/xxx/nn page. Quite easy to reproduce. > > I'm using laminar myself and I haven't seeing this issue. Can you provide an > example job that produces this issue for you? This was while I was setting things up to do CI builds for binutils/gas/gdb/gcc. I observed crashing laminard with any job, though not in a clear reproducible way. My impression is that this is in conjunction with logs and reloads (browser tab.) So testing this hypothesis would mean "reload the browser tab" while following the log, or reload the (raw) log file frequently while it is still being appended by the run. > > (Another small issue: /var/log/laminar.log isn't pre-created and > > daemon drops permissions before creating the file, so it fails > > creating it altogether.) > > From that report I guess you use sysv-init instead of systemd isn't it? Maybe > the SIGPIPE error is also related to that. I have to say I didn't test it on > any > other setup than systemd. I don't have at hand a sysv-init system, I'll try > to > setup one. Right, that's an older Debian (unstable) system updated to what's current right now, but I tried to keep systemd out of that box. I do not think that SysV init has something to do with the SIGPIPE. It's probably being a close()d / shutdown()ed FD (at the browser side) while it tries to chunk-send data. However, with systemd you'd probably get a restart of laminard. You may observe a failed / missing run, but because daemon(1) won't do a restart, laminard dies for me without getting a recovery by restart. > If you are able to test your laminar with systemd tell me if your problem > persist there. I'll try to pin down in which circumstances this actually happens. MfG, JBG -- signature.asc Description: PGP signature
Bug#983645: laminard: SIGPIPE kills it
Package: laminard Version: Hi! I gave laminar a try, but laminard dies on SIGPIPE: (gdb) bt #0 0x7f7f95d53da3 in __GI___writev (fd=16, iov=0x7ffdebf13860, iovcnt=3) at ../sysdeps/unix/sysv/linux/writev.c:26 #1 0x7f7f963d8269 in non-virtual thunk to kj::(anonymous namespace)::AsyncStreamFd::write(kj::ArrayPtr const>) () at src/kj/async-inl.h:403 #2 0x7f7f96487dc6 in kj::(anonymous namespace)::HttpOutputStreamoperator() (__closure=0x56237a1a5410) at src/kj/compat/http.c++:1661 #3 kj::_::MaybeVoidCaller >::apply >):: > (func=..., func=..., in=...) at ./src/kj/async-prelude.h:148 #4 kj::_::TransformPromiseNode, kj::_::Void, kj::(anonymous namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr >)::, kj::_::PropagateException>::getImpl(kj::_::ExceptionOrValue &) (this=0x56237a1a53f0, output=...) at ./src/kj/async-inl.h:401 #5 0x7f7f9638c502 in kj::_::TransformPromiseNodeBaseoperator() (__closure=0x7ffdebf14188, __closure=0x7ffdebf14188) at src/kj/async.c++:703 #6 kj::_::RunnableImpl >::run(void) (this=0x7ffdebf14180) at src/kj/exception.h:302 #7 0x7f7f96305f9b in kj::_::runCatchingExceptions (runnable=warning: RTTI symbol not found for class 'kj::_::RunnableImpl' ...) at src/kj/exception.c++:1023 #8 0x7f7f9638b6fa in kj::runCatchingExceptions > (func=...) at src/kj/common.h:514 #9 kj::_::TransformPromiseNodeBase::get (this=, output=...) at src/kj/async.c++:703 #10 0x7f7f963901e9 in kj::_::ChainPromiseNode::fire (this=0x56237a1b2cd0) at src/kj/async.c++:855 #11 0x7f7f9638be3c in kj::EventLoop::turn (this=0x56237a17df98) at src/kj/async.c++:373 #12 0x7f7f963910c5 in kj::_::waitImpl (node=..., result=..., waitScope=...) at src/kj/async.c++:440 #13 0x562378dde1cc in kj::Promise::wait (waitScope=..., this=0x7ffdebf14cf0) at /usr/include/kj/async-inl.h:902 #14 Server::start (this=0x56237a17e1e0) at ./src/server.cpp:56 #15 0x562378d9eeba in main (argc=, argv=) at ./src/main.cpp:98 This is while one job is running and I'm following it's build log on the /jobs/xxx/nn page. Quite easy to reproduce. (Another small issue: /var/log/laminar.log isn't pre-created and daemon drops permissions before creating the file, so it fails creating it altogether.) Thanks, Jan-Benedict -- signature.asc Description: PGP signature
Bug#983249: offlineimap3: sequence item 1: expected str instance, bytes found
Package: offlineimap3
Version: 0.0~git20210105.00d395b+dfsg-3
Severity: important
Dear Maintainer,
offlineimap fails with:
sequence item 1: expected str instance, bytes found
while trying to sync an imap folder with
pythonfile = ~/.config/offlineimap.py
that looks up username and password:
remoteusereval = get_username("account")
while get_username returns a string, the value gets converted into bytes in
/usr/share/offlineimap3/offlineimap/repository/IMAP.py
...
def getuser(self):
...
if user is not None:
return localeval.eval(user).encode('UTF-8')
due to that, the following fails:
/usr/share/offlineimap3/offlineimap/imapserver.py
...
def __plainhandler(self, response):
tries to mix bytes and strings:
retval = NULL.join((authz, authc, passwd))
This has been fixed upstream in
https://github.com/OfflineIMAP/offlineimap3/pull/50
in the same way it was fixed for passwords in
debian/patches/0001-Right-format-for-password-from-remotepassfile.patch
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages offlineimap3 depends on:
ii python3 3.9.1-1
ii python3-distro1.5.0-1
ii python3-imaplib2 2.57-5.2
offlineimap3 recommends no packages.
offlineimap3 suggests no packages.
-- no debconf information
>From fa080b8d92944a1692a44e982292ffde8066950a Mon Sep 17 00:00:00 2001
From: Konstantinos Natsakis <5933427+knatsa...@users.noreply.github.com>
Date: Mon, 8 Feb 2021 23:40:32 +0200
Subject: [PATCH] BUG: Right format for username using remoteusereval
Similarly to 7a4285370f338a6653e8bb1a8fb99e3703683b6f, reading the username
using remoteusereval returns a bytes objects instead an utf-8 string.
This patch includes support for both string and bytes objects.
Signed-off-by: Konstantinos Natsakis
<5933427+knatsa...@users.noreply.github.com>
---
offlineimap/repository/IMAP.py | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/offlineimap/repository/IMAP.py b/offlineimap/repository/IMAP.py
index b732243..e90d30c 100644
--- a/offlineimap/repository/IMAP.py
+++ b/offlineimap/repository/IMAP.py
@@ -206,12 +206,23 @@ def getuser(self):
Returns: Returns the remoteusereval or remoteuser or netrc user value.
"""
-localeval = self.localeval
-
if self.config.has_option(self.getsection(), 'remoteusereval'):
user = self.getconf('remoteusereval')
if user is not None:
-return localeval.eval(user).encode('UTF-8')
+l_user = self.localeval.eval(user)
+
+# We need a str username
+if isinstance(l_user, bytes):
+return l_user.decode(encoding='utf-8')
+elif isinstance(l_user, str):
+return l_user
+
+# If is not bytes or str, we have a problem
+raise OfflineImapError("Could not get a right username format
for"
+ " repository %s. Type found: %s. "
+ "Please, open a bug." %
+ (self.name, type(l_user)),
+ OfflineImapError.ERROR.FOLDER)
if self.config.has_option(self.getsection(), 'remoteuser'):
# Assume the configuration file to be UTF-8 encoded so we must not
Bug#983088: unblock: nitrokey-app/1.4.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: patryk@cisek.email Please unblock package nitrokey-app [ Reason ] nitrokey-app has been removed out of testing since the dependency libnitrokey had a RC bug which was fixed but migrated near the deadline. I rebuilt the app to ensure compability with the new lib version but the reupload to avoid bugs caused that I missed the deadline for bullseye. nitrokey-app has been for a long time in testing/unstable and there was no bug I know of that are a reason not to include it in bullseye. I hope that it is possible to allow the migration of the package. [ Impact ] nitrokey-app is a package to allow the usage of Nitrokeys which are open-hardware and open-source crypto usb gadgets. The cooperation between the developer team and me as maintainer was always nice and helpful so it would be a shame if the package could not be included in bullseye so Debian users can easily use it. [ Risks ] The program is justed a helper tool for specific users. Up to my knowledge it has no implications for other users. The tools normaly is executed with user rights, access to priviliged tasks is done by udev. unblock nitrokey-app/1.4.2-1
Bug#982847: [Pkg-nagios-devel] Bug#982847: monitoring-plugins-standard: check_pgsql check of database name is too strict
forwarded 982847
https://github.com/monitoring-plugins/monitoring-plugins/issues/1660
forwarded 982847
https://github.com/monitoring-plugins/monitoring-plugins/issues/1661
thanks
Hi Florian,
thanks for bringing this to our attention.
Am 15.02.21 um 11:16 schrieb Florian Lohoff:
> diff --git a/plugins/check_pgsql.c b/plugins/check_pgsql.c
> index 11ce691..88cd029 100644
> --- a/plugins/check_pgsql.c
> +++ b/plugins/check_pgsql.c
> @@ -69,7 +69,6 @@ int process_arguments (int, char **);
> int validate_arguments (void);
> void print_usage (void);
> void print_help (void);
> -int is_pg_dbname (char *);
> int is_pg_logname (char *);
> int do_query (PGconn *, char *);
>
> @@ -344,11 +343,7 @@ process_arguments (int argc, char **argv)
> pgport = optarg;
> break;
> case 'd': /* database name */
> - if (!is_pg_dbname (optarg)) /* checks length and valid
> chars */
> - usage2 (_("Database name is not valid"),
> optarg);
> - else /* we know length, and know optarg is terminated,
> so us strcpy */
> - strcpy (dbName, optarg);
> - break;
> + strcpy (dbName, optarg);
> case 'l': /* login name */
> if (!is_pg_logname (optarg))
> usage2 (_("User name is not valid"), optarg);
> @@ -408,45 +403,6 @@ validate_arguments ()
> return OK;
> }
are you sure it's a good idea to remove the break?
> @@ -344,11 +343,7 @@ process_arguments (int argc, char **argv)
>pgport = optarg;
> break;
> case 'd': /* database name */
> - if (!is_pg_dbname (optarg)) /* checks length and
> valid chars */
> - usage2 (_("Database name is not valid"),
> optarg);
> - else /* we know length, and know optarg is
> terminated, so us strcpy */
> - strcpy (dbName, optarg);
> - break;
> + snprintf(dbName, NAMEDATALEN, "%s", optarg);
> case 'l': /* login name */
> if (!is_pg_logname (optarg))
> usage2 (_("User name is not valid"), optarg);
same here.
Many thanks, Jan.
Bug#946049: Delay pools in squid4
Hello. I found upstream bugreport here: https://bugs.squid-cache.org/show_bug.cgi?id=4913 Regards, J.K.
Bug#982554: dpkg: dpkg-deb fails to extract package contents on FAT32 devices
To add some data for your information: # dpkg -D100 --install /var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb (Reading database ... 370596 files and directories currently installed.) Preparing to unpack .../linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb ... Unpacking linux-image-5.10.0-3-amd64 (5.10.13-1) over (5.10.12-1) ... D000100: setupvnamevbs main='/.' tmp='/..dpkg-tmp' new='/..dpkg-new' D000100: tarobject already exists D000100: tarobject directory exists D000100: setupvnamevbs main='/boot' tmp='/boot.dpkg-tmp' new='/boot.dpkg-new' D000100: tarobject already exists D000100: tarobject directory exists D000100: setupvnamevbs main='/boot/System.map-5.10.0-3-amd64' tmp='/boot/System.map-5.10.0-3-amd64.dpkg-tmp' new='/boot/System.map-5.10.0-3-amd64.dpkg-new' D000100: tarobject already exists D000100: tarobject file open size=83 D000100: tarobject file hash=e0a6c09212a19ed48183a052eab847e7 D000100: tarobject nondirectory, 'link' backup dpkg: error processing archive /var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb (--install): unable to make backup link of './boot/System.map-5.10.0-3-amd64' before installing new version: Operation not permitted D000100: setupvnamevbs main='/boot/System.map-5.10.0-3-amd64' tmp='/boot/System.map-5.10.0-3-amd64.dpkg-tmp' new='/boot/System.map-5.10.0-3-amd64.dpkg-new' D000100: cu_installnew not restoring D000100: secure_remove '/boot/System.map-5.10.0-3-amd64.dpkg-new' unlink OK dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb # ln System.map-5.10.0-3-amd64 System.map-5.10.0-3-amd64.bak ln: failed to create hard link 'System.map-5.10.0-3-amd64.bak' => 'System.map-5.10.0-3-amd64': Operation not permitted # mount | grep boot /dev/sda1 on /boot type vfat (rw,noatime,nodiratime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) On Thu, 11 Feb 2021 20:04:39 +0100 Jan Luca Naumann wrote: > Package: dpkg > Version: 1.20.7.1 > Severity: important > > On EFI computer it is possible to use the ESP partition directly as > /boot. But dpkg has problems to upgrade packages, e.g. the linux-image > packages, then since it tries to create hardlinks as backup of existing > files. This is not supported for FAT32 partitions. > > dpkg should include some check if the target device systems may not > support hard links so /boot on FAT32 is supported.
Bug#982554: dpkg: dpkg-deb fails to extract package contents on FAT32 devices
Package: dpkg Version: 1.20.7.1 Severity: important On EFI computer it is possible to use the ESP partition directly as /boot. But dpkg has problems to upgrade packages, e.g. the linux-image packages, then since it tries to create hardlinks as backup of existing files. This is not supported for FAT32 partitions. dpkg should include some check if the target device systems may not support hard links so /boot on FAT32 is supported. -- Package-specific info: System tainted due to merged-usr-via-aliased-dirs. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.31-9 ii liblzma5 5.2.5-1.0 ii libselinux1 3.1-2+b2 ii tar 1.32+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.1.20 pn debsig-verify -- no debconf information
Bug#982548: wpasupplicant: Missing support for WPA-EAP-SUITE-B(-192)
Package: wpasupplicant
Version: 2:2.4-1
Severity: normal
Tags: patch
It was observed that Debian's wpa_supplicant is not able to connect to connect
to networks with key_mgmt WPA-EAP-SUITE-B and/or WPA-EAP-SUITE-B-192 (aka
WPA3-Enterprise 192-bit mode). The upstream wpa_supplicant supports this since
2.4. Following is seen when trying to load a config with this kind of
configuration:
1613046731.169674: Line: 3 - start of a new network block
1613046731.169679: ssid - hexdump_ascii(len=11):
41 50 38 34 30 2d 57 50 41 32 33 AP840-WPA23
1613046731.169692: proto: 0x2
1613046731.169696: Line 9: invalid key_mgmt 'WPA-EAP-SUITE-B-192'
1613046731.169699: Line 9: no key_mgmt values configured.
1613046731.169701: key_mgmt: 0x0
1613046731.169704: Line 9: failed to parse key_mgmt 'WPA-EAP-SUITE-B-
192'.
1613046731.169708: ieee80211w=2 (0x2)
The used config was:
ctrl_interface=/run/wpa_supplicant
ctrl_interface_group=root
network={
ssid="AP840-WPA23"
scan_ssid=1
proto=RSN
key_mgmt=WPA-EAP-SUITE-B-192
ieee80211w=1
pairwise=GCMP-256
group=GCMP-256
group_mgmt=BIP-GMAC-256
eap=TLS
identity="anonymous"
ca_cert="/home/user/rsa3072-ca.crt"
client_cert="/home/user/rsa3072-user.crt"
private_key="/home/user/rsa3072-user.key"
private_key_passwd="wifi"
}
The problem can be solved by adding following two lines to the files in
debian/config/wpasupplicant/
CONFIG_SUITEB=y
CONFIG_SUITEB192=y
This is also breaking the support for these kind of networks in
network-manager.
--
Jan Fuchs
development engineer
Simon Wunderlich Systementwicklung & Beratung
Herrenstr. 6, 08523 Plauen, VAT-ID: DE 279397655
Bug#981845: closed by Peter Colberg (Re: Bug#981845: Please update cgit package, it's 4 years old already)
Great, thanks for the explanation! On Tue, Feb 9, 2021 at 3:54 AM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > This is an automatic notification regarding your Bug report > which was filed against the cgit package: > > #981845: Please update cgit package, it's 4 years old already > > It has been closed by Peter Colberg . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Peter Colberg < > pe...@colberg.org> by > replying to this email. > > > -- > 981845: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981845 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Peter Colberg > To: Jan Kosiaty , 981845-d...@bugs.debian.org > Cc: > Bcc: > Date: Mon, 8 Feb 2021 21:45:04 -0500 > Subject: Re: Bug#981845: Please update cgit package, it's 4 years old > already > Hi Jan, > > On Thu, Feb 04, 2021 at 04:14:55PM +0100, Jan Kosiaty wrote: > > Subject: cgit package is 4 years old > > Package: cgit > > Version: 1.1+git2.10.2-3+deb9u1 > > Severity: normal > > From the version it looks like you are using Debian 9 (stretch) > "oldstable". For stable releases, Debian generally only provides > security updates. > > For a newer cgit, I suggest upgrading to Debian 10 (buster) "stable". > In a few months time, you may further upgrade to Debian 11 (bullseye), > which is currently "testing" and will then become the next "stable". > > For an overview of cgit versions available in Debian, please see > > https://packages.debian.org/cgit > > Regards, > Peter > > > -- Forwarded message -- > From: Jan Kosiaty > To: sub...@bugs.debian.org > Cc: > Bcc: > Date: Thu, 4 Feb 2021 16:14:55 +0100 > Subject: Please update cgit package, it's 4 years old already > Subject: cgit package is 4 years old > Package: cgit > Version: 1.1+git2.10.2-3+deb9u1 > Severity: normal >
Bug#947696:
Severity: normal I intend to addopt daemontools. Best Regards, Jan Mojzis
Bug#982135: Acknowledgement (ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C)
The packaging is ready in my personal repository: https://salsa.debian.org/janmojzis/bearssl <https://salsa.debian.org/janmojzis/bearssl> … and prefered final location is: https://salsa.debian.org/debian/bearssl <https://salsa.debian.org/debian/bearssl> Jan
Bug#982136: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C
Package: wnpp Severity: wishlist Owner: Jan Mojzis * Package name: bearssl Version : 0.6 Upstream Author : Thomas Pornin * URL : https://bearssl.org * License : MIT Programming Lang: C Description : BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C. It aims at offering the following features: - Be correct and secure. In particular, insecure protocol versions and choices of algorithms are not supported, by design; cryptographic algorithm implementations are constant-time by default. - Be small, both in RAM and code footprint. For instance, a minimal server implementation may fit in about 20 kilobytes of compiled code and 25 kilobytes of RAM. - Be highly portable. BearSSL targets not only “big” operating systems like Linux and Windows, but also small embedded systems and even special contexts like bootstrap code. - Be feature-rich and extensible. SSL/TLS has many defined cipher suites and extensions; BearSSL should implement most of them, and allow extra algorithm implementations to be added afterwards, possibly from third parties Library doesn't have compatible API with mainstream OpenSSL. And it's not intended as an OpenSSL 1-1 replacement. I'm using this software and I'm going to maintain using https://salsa.debian.org/. I need sponsor.
Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C
Package: wnpp Severity: wishlist Owner: Jan Mojzis * Package name: bearssl Version : 0.6 Upstream Author : Thomas Pornin * URL : https://bearssl.org * License : MIT Programming Lang: C Description : BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C. It aims at offering the following features: - Be correct and secure. In particular, insecure protocol versions and choices of algorithms are not supported, by design; cryptographic algorithm implementations are constant-time by default. - Be small, both in RAM and code footprint. For instance, a minimal server implementation may fit in about 20 kilobytes of compiled code and 25 kilobytes of RAM. - Be highly portable. BearSSL targets not only “big” operating systems like Linux and Windows, but also small embedded systems and even special contexts like bootstrap code. - Be feature-rich and extensible. SSL/TLS has many defined cipher suites and extensions; BearSSL should implement most of them, and allow extra algorithm implementations to be added afterwards, possibly from third parties Library doesn't have compatible API with mainstream OpenSSL. And it's not intended as an OpenSSL 1-1 replacement. I'm using this software and I'm going to maintain using https://salsa.debian.org/. I need sponsor.
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Dear Debian developers, maintainers etc. I use Debian for many years. My primary and only installation for work is unstable installed in 2003 and i updated this one *many times*. I love Debian because of freedom from more points of view. One PoV is possibility to choose software component which i prefer. Because i don't like systemd (other story) i use sysvinit not on my computer only but on many our servers too. My fault is, they are without popcon, so not in stats (will fix it, i promise). When i read about maintainer which broke thing (on my system too) and rejected fix because... i still don't know why, i feel very sad. I don't think this is a fair community work which is great otherwise. So thanks Matthew and others they did not throw us overboard. I use orphan-sysvinit-scripts now. Not best solution imho, but it is others fault. Shame. Sorry for some emotions and peace. Regards, J.
Bug#981845: Please update cgit package, it's 4 years old already
Subject: cgit package is 4 years old Package: cgit Version: 1.1+git2.10.2-3+deb9u1 Severity: normal
Bug#980928: npm: Installing any package gives "npm ERR! current.merge is not a function"
Package: npm Version: 7.4.0+ds-1~bpo10+2 Severity: grave Justification: renders package unusable Tried out via, e.g., "npm install serialport" inside a debian:buster-slim container. Happens with both "npm node-*" as well only the required node-packages takes from backports. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.18-lp152.60-default (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages npm depends on: ii ca-certificates 20200601~deb10u1 ii node-abbrev 1.1.1-1 ii node-agent-base 6.0.2-1~bpo10+1 ii node-ajv5.0.0-1 ii node-ansi 0.3.0-3 ii node-ansi-regex 3.0.0-1 ii node-ansi-styles3.2.1-1 ii node-ansistyles 0.1.3-1 ii node-aproba 1.2.0-1 ii node-archy 1.0.0-2 ii node-are-we-there-yet 1.1.4-1 ii node-asap 2.0.6-1 ii node-asn1 0.2.3-1 ii node-assert-plus1.0.0-1 ii node-asynckit 0.4.0-2 ii node-aws-sign2 0.7.1-1 ii node-aws4 1.8.0-1 ii node-balanced-match 0.4.2-1 ii node-bcrypt-pbkdf 1.0.1-1 ii node-brace-expansion1.1.8-1 ii node-builtins 1.0.3-1 ii node-cacache15.0.5+~cs13.9.21-1~bpo10+1 ii node-caseless 0.12.0-1 ii node-chalk 2.3.0-2 ii node-chownr 1.1.3-5~bpo10+1 ii node-clone 2.1.2-1 ii node-color-convert 1.9.0-3 ii node-color-name 1.1.3-1 ii node-colors 1.1.2-1 ii node-columnify 1.5.4-1 ii node-combined-stream1.0.7-1 ii node-concat-map 0.0.1-1 ii node-console-control-strings1.1.0-1 ii node-core-util-is 1.0.2-1 ii node-dashdash 1.14.1-2 ii node-debug 4.3.1+~cs4.1.5-1~bpo10+1 ii node-defaults 1.0.3-1 ii node-delayed-stream 0.0.5-1 ii node-delegates 1.0.0-1 ii node-depd 1.1.2-1 ii node-ecc-jsbn 0.1.1-1 ii node-encoding 0.1.12-2 ii node-err-code 1.1.2+dfsg-1 ii node-extend 3.0.2-1 ii node-extsprintf 1.3.0-1 ii node-fast-deep-equal1.0.0-1 ii node-forever-agent 0.6.1-1 ii node-form-data 2.3.2-2 ii node-fs.realpath1.0.0-1 ii node-function-bind 1.1.1+ds-2 ii node-gauge 2.7.4-1 ii node-getpass0.1.7-1 ii node-glob 7.1.3-2 ii node-graceful-fs4.1.11-1 ii node-gyp6.1.0-3~bpo10+1 ii node-har-schema 2.0.0-1 ii node-har-validator 5.1.0-1 ii node-has-flag 2.0.0-1 ii node-http-signature 1.2.0-1 ii node-https-proxy-agent 5.0.0-2~bpo10+1 ii node-iconv-lite 0.4.13-2 ii node-imurmurhash0.1.4-1 ii node-indent-string 3.2.0-1 ii node-inflight 1.0.6-1 ii node-inherits 2.0.3-1 ii node-ini1.3.5-1 ii node-ip 1.1.5-3 ii node-ip-regex 3.0.0-1 ii node-is-typedarray 1.0.0-2 ii node-isarray2.0.4-1 ii node-isexe 2.0.0-4 ii node-isstream 0.1.2+dfsg-1 ii node-jsbn 1.1.0-1 ii node-json-parse-better-errors 1.0.2+~2.3.1-1~bpo10+1 ii node-json-schema0.2.3-1 ii node-json-schema-traverse 0.3.1-1 ii node-json-stable-stringify 1.0.1-1 ii node-json-stringify-safe5.0.1-1 ii node-jsonparse 1.3.1-6 ii node-jsonstream 1.3.2-1 ii node-jsprim 1.4.0-1 ii node-leven 2.1.0-2 ii node-lockfile 1.0.4-1 ii node-mime 2.4.0-1 ii node-mime-types 2.1.21-1 ii node-minimatch 3.0.4-3 ii node-mkdirp 1.0.4-3~bpo10+2 ii node-ms 2.1.1-1 ii node-mute-stream0.0.8-1 ii node-nopt 3.0.6-3 ii node-normalize-package-data 2.4.0-1 ii node-npm-bundled1.0.3-1 ii node-npm-package-arg6.1.1-1~bpo10+1 ii
Bug#980403: libpam-pkcs11: pam_pkcs11.so is in wrong directory
Package: libpam-pkcs11 Version: 0.6.11-3 Severity: important Dear Maintainer, PAM looks for modules in /lib/x86_64-linux-gnu/security, but this package installs pam_pkcs11.so in /lib/security. Creating a symlink to /lib/x86_64-linux-gnu/security/pam_pkcs11.so makes this module work. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/8 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: default Versions of packages libpam-pkcs11 depends on: ii libc6 2.31-9 ii libcurl4 7.74.0-1 ii libldap-2.4-2 2.4.56+dfsg-1 ii libpam0g 1.4.0-2 ii libpcsclite1 1.9.0-1 ii libssl1.1 1.1.1i-1 libpam-pkcs11 recommends no packages. libpam-pkcs11 suggests no packages. -- no debconf information
Bug#980180: Missing support for Intel Elkhart Lake Ethernet
Package: linux-image-amd64 Version: 5.10.4-1 In order to support the Ethernet controller found on Intel Elkhart Lake SOCs which are STMMAC-based, CONFIG_DWMAC_INTEL and dependencies are needed. Please enable.
Bug#979851: fp-compiler-3.2.0: missing backslash in postinst, line 68
Package: fp-compiler-3.2.0 Version: 3.2.0+dfsg-9 Severity: normal Dear Maintainer, Installation of the package fails, line 68 of the postinst script misses a backslash at the end of the line Best wishes, Jan -- System Information: Debian Release: bullseye/sid APT prefers experimental APT policy: (800, 'experimental'), (500, 'master'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.5-xanmod1 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fp-compiler-3.2.0 depends on: hi binutils 2.35.1-7 ii debconf [debconf-2.0] 1.5.74 ii fp-units-rtl-3.2.0 3.2.0+dfsg-9 ii libc6 2.31-9 Versions of packages fp-compiler-3.2.0 recommends: ii fp-utils-3.2.0 3.2.0+dfsg-9 Versions of packages fp-compiler-3.2.0 suggests: ii fp-docs-3.2.0 3.2.0+dfsg-9 -- debconf information excluded
Bug#975115: Info received (Wrong API version string in Debian packaged tbsync extension)
Ok - so - the API string in buster is actually:
$ rgrep "2\.4"
dav/content/provider.js:static getApiVersion() { return "2.4"; }
eas/content/provider.js:static getApiVersion() { return "Beta 2.4"; }
dpkg/content/tbsync.jsm: apiVersion: "Beta 2.4",
So now EAS complains for me :-) But since I don't need that, I removed
it. But IMHO neither webext-eas4tbsync nor webext-tbsync should be
"Beta". I guess it's fixed for sid, where webext-tbsync is newer and
webext-eas4tbsync got a "version bump to 2.4" in 1.20-2.
HTH
Jan-Marek
Bug#979443: chromium: desktop GUI locks up as Xorg process goes to 100%
Michel and I just prepared an security update for unstable and buster-security which changes the default to "desktop". This should be soon in the archive. Best, Jan Am 11.01.21 um 15:14 schrieb Steve A.: > After three full days of use, the desktop has not frozen again, and the > Xorg process has remained below 7% CPU use. Should I modify the menu to > include the alternate launch command, or is there a beta version of > chromium you would like me to try? > > Steve > > > Steve A. wrote on 1/8/21 6:32 AM: >> Thanks, Jan. I killed chromium, upgraded to 87* again, and >> re-launched with the recommended command last night. The user is back >> on this morning and I'm monitoring from another machine. >> >> Steve >> >> >> Jan Luca Naumann wrote on 1/7/21 2:30 AM: >>> Dear Steve, >>> >>> with the upgrade to 87.* we included the ANGLE library which manages the >>> OpenGL access of chromium. Maybe this is the cause of your problem. >>> >>> Could you try to launch "$ chromium --use-gl=desktop"? This should >>> disable the usage of ANGLE. >>> >>> Best, >>> Jan >>> OpenPGP_signature Description: OpenPGP digital signature
Bug#975115: Wrong API version string in Debian packaged tbsync extension
Hi everyone,
just installed webext-dav4tbsync on buster (incl. tbsync 2.18-1~deb10u1)
and was bitten by this bug.
Then I downloaded tbsync 2.18 from TB addons, unzip'ed both tbsync xpi
and ran a diff on them:
Only in orig/: CONTRIBUTORS.md
Only in orig/: LICENSE
Only in orig/: README.md
Only in orig/_locales: Readme.txt
diff -urb orig/content/modules/providers.js
dpkg/content/modules/providers.js
--- orig/content/modules/providers.js 2020-08-28 18:07:42.0 +0200
+++ dpkg/content/modules/providers.js 2020-10-16 13:38:49.0 +0200
@@ -14,10 +14,10 @@
defaultProviders: {
"dav" : {
name: "CalDAV & CardDAV",
- homepageUrl: "https://addons.thunderbird.net/addon/dav-4-tbsync/"},
+ homepageUrl:
"https://tbsync.jobisoft.de/beta/TB78/DAV-4-TbSync.xpi"},
"eas" : {
name: "Exchange ActiveSync",
- homepageUrl: "https://addons.thunderbird.net/addon/eas-4-tbsync/"},
+ homepageUrl:
"https://tbsync.jobisoft.de/beta/TB78/EAS-4-TbSync.xpi"},
},
loadedProviders: null,
diff -urb orig/content/tbsync.jsm dpkg/content/tbsync.jsm
--- orig/content/tbsync.jsm 2020-10-16 12:50:02.0 +0200
+++ dpkg/content/tbsync.jsm 2020-10-16 13:38:49.0 +0200
@@ -27,7 +27,7 @@
addon: null,
version: 0,
debugMode: false,
- apiVersion: "2.4",
+ apiVersion: "Beta 2.4",
prefs: Services.prefs.getBranch("extensions.tbsync."),
diff -urb orig/manifest.json dpkg/manifest.json
--- orig/manifest.json 2020-10-16 13:40:28.0 +0200
+++ dpkg/manifest.json 2020-10-16 13:38:49.0 +0200
@@ -1,13 +1,14 @@
{
"applications": {
"gecko": {
+ "update_url": "https://tbsync.jobisoft.de/beta/TB78/update-tbsync.json;,
"id": "tbs...@jobisoft.de",
"strict_min_version": "78.0",
"strict_max_version": "78.*"
}
},
"manifest_version": 2,
- "name": "TbSync",
+ "name": "TbSync [Beta Release Channel]",
"version": "2.18",
"author": "John Bieling",
"homepage_url": "https://github.com/jobisoft/TbSync;,
After that I replaced the dpkg included tbs...@jobisoft.de.xpi with the
TB addons download and got no more error.
HTH
Jan-Marek
Bug#979683: sysrqd: daemon is binding to all addresses when only one is given in the config
Package: sysrqd Version: 14-1+b2 Severity: normal Dear Maintainer, version of sysrqd packaged in Debian has bug in check of inet_aton() return value. You already have a fix for it in your upstream: https://github.com/jd/sysrqd/commit/0e087c65200f5bbea8c22faea1a4643a1035cb85 Can you please update sysrqd package, so this patch will get to the Debian? I think, someone may consider this even as a security issue: If admin tries to configure sysrqd to listen only on local ip address (e.g. management network), sysrqd will instead bind to all addresses - including the publicly available. Thank you, Jan -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages sysrqd depends on: ii libc6 2.28-10 sysrqd recommends no packages. sysrqd suggests no packages. -- no debconf information
Bug#979135: chromium: GPU hw-accel: ANGLE libs cause a lot of errors and warnings
The reason I prefer at the moment the way to change the order in the code is that there it is checked if the desktop implementation is an allowed choice. I do not know what the behavior would be if this is not a valid choice for some case but we use the command line flag. The patch still allows to use "--use-gl=" in /etc/chromium.d/default-flags if people want to use something else for their installation. Best, Jan Am 09.01.21 um 08:03 schrieb Sedat Dilek: > Hi, > > Jan Luca is working on a patch "Use desktop gl implementation as default"... > > What about placing "--use-gl=desktop" in /etc/chromium.d/default-flags > as an alternative? > > # Default for GPU hardware-acceleration (Debian bug #979135) > export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --use-gl=desktop" > > Cannot say if this is wanted behaviour - to enable GPU hw-accel by default? > Looks like a safer methon when GPU hw-accel is wanted. > > In my logs I found references to Skia renderer... > > [ chrome://flags ] > > Skia API for compositing > If enabled, the display compositor will use Skia as the graphics API > instead of OpenGL ES. – Mac, Windows, Linux, Android > Here set to "Default" > > [ chrome://gpu ] > Graphics Feature Status > Skia Renderer: Enabled > > Cannot judge when not using ANGLE libs if there is a fallback to OpenGL ES. > Might be OpenGL ES renderer is the better choice? > > I have not looked for the parameters and cannot say I will play with them. > > ( BTW, I played with Vulkan support enabled - slow performance here > with Intel Sandy Bridge GPU. ) > > Regards, > - Sedat - > > [1] https://salsa.debian.org/janluca-guest/chromium/-/commits/angle_fix > [2] https://wiki.archlinux.org/index.php/chromium#Force_GPU_acceleration > [3] https://wiki.archlinux.org/index.php/chromium#Hardware_video_acceleration > OpenPGP_signature Description: OpenPGP digital signature
Bug#979533: chromium: New 87.0.4280.141 (CVE-2020-15995 CVE-2020-16043 CVE-2021-21106 CVE-2021-21107 CVE-2021-21108 CVE-2021-21109 CVE-2021-21110 CVE-2021-21111 CVE-2021-21112 CVE-2021-21113 CVE-2021-
Michel is preparing an new version and I update the buster branch as soon as the unstable version is uploaded. Best, Jan On Thu, 07 Jan 2021 21:01:43 +0100 Salvatore Bonaccorso wrote: > Source: chromium > Version: 87.0.4280.88-0.4 > Severity: grave > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > Control: found -1 87.0.4280.88-0.4~deb10u1 > > Hi > > Please see > https://chromereleases.googleblog.com/2021/01/stable-channel-update-for-desktop.html > here is a new round of CVE fixes for chromium accordingly. > > CVE-2020-15995 seems a bit unclear, it was previously marked to affect > only Chrome on Android, but now appears to affect as well us. > > Regards, > Salvatore > > OpenPGP_signature Description: OpenPGP digital signature
Bug#979443: chromium: desktop GUI locks up as Xorg process goes to 100%
Dear Steve, with the upgrade to 87.* we included the ANGLE library which manages the OpenGL access of chromium. Maybe this is the cause of your problem. Could you try to launch "$ chromium --use-gl=desktop"? This should disable the usage of ANGLE. Best, Jan On Wed, 6 Jan 2021 11:00:00 -0800 "Steve A." wrote: > Package: chromium > Version: 87.0.4280.88-0.4~deb10u1 > Severity: grave > Tags: a11y > Justification: renders package unusable > > Dear Maintainer, > > Subsequent to an upgrade from 83.0.4103.116-1~deb10u3 to > 87.0.4280.88-0.4~deb10u1, the desktop GUI randomly freezes, including > the clock. This occurred three times over the course of two days. > Doing a ssh from another machine, and then running top, showed the Xorg > process pegged at 100%. Killing just the chromium process did not > resolve the locking problem, and the only way to recover was to kill all > processes for the GUI user. Chromium was rolled back to > 83.0.4103.116-1~deb10u3 and there have been no freezes in over two days. > > > -- System Information: > Debian Release: 10.7 >APT prefers stable-updates >APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-13-amd64 (SMP w/16 CPU cores) > Kernel taint flags: TAINT_WARN > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages chromium depends on: > ii chromium-common 87.0.4280.88-0.4~deb10u1 > ii libasound2 1.1.8-1 > ii libatk-bridge2.0-0 2.30.0-5 > ii libatk1.0-0 2.30.0-2 > ii libatspi2.0-02.30.0-7 > ii libavcodec58 7:4.1.6-1~deb10u1 > ii libavformat587:4.1.6-1~deb10u1 > ii libavutil56 7:4.1.6-1~deb10u1 > ii libc62.28-10 > ii libcairo21.16.0-4 > ii libcups2 2.2.10-6+deb10u4 > ii libdbus-1-3 1.12.20-0+deb10u1 > ii libdrm2 2.4.97-1 > ii libevent-2.1-6 2.1.8-stable-4 > ii libexpat12.2.6-2+deb10u1 > ii libflac8 1.3.2-3 > ii libfontconfig1 2.13.1-2 > ii libfreetype6 2.9.1-3+deb10u2 > ii libgbm1 18.3.6-2+deb10u1 > ii libgcc1 1:8.3.0-6 > ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 > ii libglib2.0-0 2.58.3-2+deb10u2 > ii libgtk-3-0 3.24.5-1 > ii libharfbuzz0b2.3.1-1 > ii libicu63 63.1-6+deb10u1 > ii libjpeg62-turbo 1:1.5.2-2+deb10u1 > ii libjsoncpp1 1.7.4-3 OpenPGP_signature Description: OpenPGP digital signature
Bug#977101: knot: duplicate zones, segfault when generating new DNSSEC keys
We have tried to reproduce your issue but we were not able to crash the daemon. Maybe some logs or details of your approach could help us. Also, move this issue to 'https://gitlab.nic.cz/knot/knot-dns/-/issues' would be good idea. Thanks for your report
Bug#973848: security update of chromium in Debian stable?
Hey, I have got a successful buster build half an hour ago :) As soon as [1] is fixed or at least worked around (so we do not release a version with a regression), I think we could do the update. I will contact the security team now to discuss the update. Best, Jan [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977870 Am 28.12.20 um 12:37 schrieb Tomas Pospisek: > Hi Jan Luca, > > are you working on or respectively are you planing to do the stable build? > > (I am not sure if I would be able to get access to a powerful enough > machine to do the build and get up to speed within reasonable time on how > to build chromium and on how to do it efficiently so that I do not have > to wait 24 hours for the build to proceed and fail again before I > apply the next fix...?) > > Greetings! > *t OpenPGP_signature Description: OpenPGP digital signature
Bug#973848: security update of chromium in Debian stable?
Hey, parallel to Michel's very nice work to get chromium into unstable (thanks to him!), I tried to build the current version in a buster chroot. At the moment I struggle that there seems a difference how SFINAE[1] in a special case [2] is handled different between buster's and unstable's clang version. Since I had not so much time I have not found a fix to work around this. If people are more experienced with C++ templates than me, I would be happy to share the problem and the build log ;) Best, Jan [1] https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error [2] In file included from ../../third_party/blink/common/privacy_budget/identifiability_metric_builder.cc:5: In file included from ../../third_party/blink/public/common/privacy_budget/identifiability_metric_builder.h:9: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/vector:60: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algobase.h:64: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_pair.h:59: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/move.h:55: /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/type_traits:2046:15: error: only enumeration types have underlying types typedef __underlying_type(_Tp) type; ^ ../../third_party/blink/public/common/privacy_budget/identifiable_token.h:121:40: note: in instantiation of template class 'std::underlying_type >' requested here typename U = typename std::underlying_type::type, Am 23.12.20 um 12:13 schrieb Tomas Pospisek: > Hi all, > > now that sid has seen an update of Chromium to v87 (hooray and thanks > everybody!) does anybody know it there's activity or plans towards > updating chromium in Debian stable? > > Chromium from sid is not installable in Debian stable due to > > Depends: libc6 (>= 2.29) > > whereas stable has 2.28. > > I'm not sure what the correct procedure would be to kickstart the Debian > stable update? > > *t OpenPGP_signature Description: OpenPGP digital signature
Bug#973848: chromium: Unsupported version, many security bugs unfixed
Hey, I have uploaded my stuff to https://salsa.debian.org/janluca-guest/chromium We can meet in IRC or Matrix. I am janluca on irc.oftc.net. Best, Jan On Mon, 14 Dec 2020 13:59:53 +0100 Michel Le Bihan wrote: > Hello, > > My work is in this repo: > https://salsa.debian.org/mimi8/chromium/-/tree/master > > I'm updating the commit every time I make a change. Making a new commit > for each file doesn't really make sense, since those are separate files > anyway. > > > There is another repo from another person that also started work: > https://github.com/berkley4/ungoogled-chromium-debian/commits/87.0.4280.88 > > And another one somebody told me about yesterday: > https://www.zap.org.au/git-browser/debian-packages/pkg-chromium-browser.git/ > > Could you please commit your work to a fork of the Chromium repo on > Salsa so we can compare patches? > > Also, maybe we could meet on IRC/XMPP/Matrix or somewhere? > > Michel Le Bihan >
Bug#973848: chromium: Unsupported version, many security bugs unfixed
Hallo everybody, I have done some of the work as well since I have not seen your message about your efforts. I have uploaded a working build for unstable to mentors including updated version of the patches: https://mentors.debian.net/package/chromium/ This version is using the vendor-shipped version of libvpx which should be changed but maybe we can put together the work done so far in a Git repo and fixes the remaining stuff? Best, Jan On Sun, 13 Dec 2020 14:45:01 -0800 David Worsham wrote: > Hi there, > > Thank you for all of the great work on this so far! > > I'm interested in helping with this effort, and very familiar with C++ code > and processes in Google code (though not specifically Chromium). I have > gotten the 83/84 versions in unstable/experimental building locally in a > container as a sanity check. I also have a fork on salsa to work from > now: https://salsa.debian.org/arbreng/chromium > > However, I am very new to Debian packaging and so not sure what the "ideal" > workspace setup and workflow is for this kind of work. I just kinda made > things up as I went along yesterday. If one of ya'll could walk me through > it that would be greatly appreciated - I only know what I learned from > the debian Wiki. I know how to build and hack on Chromium itself -- it's > just the packaging bits that are still a bit mystifying to me. > > Thanks again for all the effort!
Bug#977294: nagios-plugins-contrib: (another) check_uptime is shipped with monitoring-plugins 2.3
Package: nagios-plugins-contrib Severity: normal Monitoring Plugins ships a check_uptime since version 2.3, see https://github.com/monitoring-plugins/monitoring-plugins/commits/v2.3/plugins-scripts/check_uptime.pl I would suggest to remove check_uptime from the package. If removing is not an option, we should rename the script. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK-- signature.asc Description: OpenPGP digital signature
Bug#976218: [Pkg-nagios-devel] Bug#976218: nagios-plugins-contrib: diff for NMU version 27.20200511+1+nmu1
Hi Christoph, Am 07.12.20 um 22:05 schrieb Christoph Biedl: > Okay, I've removed the upload from the queue as I really like to avoid > disrupting the maintainers' workflow by doing a NMU. However, I'd > appreciate if you could deal with this pretty soon as it is delaying the > testing migration of a fairly important package. Perhaps upload a new > check-ssl only and keep the rest for a later one? many thanks for helping out. I uploaded a package yesterday in evening. Cheers, Jan. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-@ s+:()>- a+ C$ UL$ P+ L$ !E--- W+++$ N+++ o++ K++ !w---? O M+ !V- PS+ PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y+ --END GEEK CODE BLOCK-- signature.asc Description: OpenPGP digital signature
Bug#943888: [Pkg-nagios-devel] Bug#943888: check_libs: ignores deleted mmaped files
tags 943888 + unreproducible moreinfo thanks Hi Felix, thanks for reporting. Am 31.10.19 um 13:37 schrieb Felix Geyer: > To reproduce on buster with systemd (but obviously applies to other > processes as well): > apt install --reinstall libseccomp2 > # /usr/lib/nagios/plugins/check_libs > No upgraded libs linked in running processes When running this on buster with package 27.20200511+1: # /usr/lib/nagios/plugins/check_libs The following processes have libs linked that were upgraded: systemd-logind (662), systemd (11284, 11282) I guess this was fixed with 27.20200511+1 by: * [45d41ae] check_libs is now a symlink to check_libs_ng With kind regards, Jan. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK--
Bug#976218: [Pkg-nagios-devel] Bug#976218: nagios-plugins-contrib: diff for NMU version 27.20200511+1+nmu1 (was: Bug#976218: file breaks nagios-plugins-contrib autopkgtest: SSL_CERT UNKNOWN www.debian
Hi Chirstoph, thanks for taking care. Am 07.12.20 um 08:09 schrieb Christoph Biedl: > to resolve this issue, I've prepared a NMU for nagios-plugins-contrib > (versioned as 27.20200511+1+nmu1), and uploaded it to DELAYED/5. Please > feel free to tell me if I should delay it longer. 1.124.0 is already integrated into VCS (https://salsa.debian.org/nagios-team/pkg-nagios-plugins-contrib/-/commit/6827b67108fcaafb5c73de8d7b44d71b2a7e6cf3), so you can delay this a bit more. Actually I'm working hard to get the latest VCS into unstable but I have to work on some other issues as well. Thanks, Jan. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK--
Bug#954961: [Pkg-nagios-devel] Bug#954961: /usr/lib/nagios/plugins/check_mailq: check_mailq doesn't recognize options -W and -C: Unknown option
Hi Humberto, thanks for reporting, Am 25.03.20 um 21:47 schrieb Humberto Flores III: > * What led up to the situation? > # /usr/lib/nagios/plugins/check_mailq -w 100 -c 200 -W 10 -C 20 > > > * What was the outcome of this action? > Unknown option: W > Unknown option: C while added the feature with https://github.com/monitoring-plugins/monitoring-plugins/commit/664be83730ff97368e8bfcf5e1fc4db2435d2c3a#diff-179d0007b238d07b3718fda62c6c8ae417378b36bdafd902dc78e86c14d7d9fb it was removed by https://github.com/monitoring-plugins/monitoring-plugins/commit/6fc70bc896b1c871eba2fb3cbb9bf693d86744a0 trying to fix https://github.com/monitoring-plugins/monitoring-plugins/commit/6fc70bc896b1c871eba2fb3cbb9bf693d86744a0 I've to dig into this a little further. Cheers, Jan. signature.asc Description: OpenPGP digital signature
Bug#972454: Confirmed fix 2.13-1 on aarch64
Thanks for the fix Jeremy. Sorry I couldn't test sooner. I see unstable has been updated to 2.13-1 and I can confirm the package now installs correctly with a 5.9 kernel on aarch64 (correct arch name instead of arm64). --- Jan Huijsmans huysm...@koffie.nu ... cannot activate /dev/brain, no response from main coffee server
Bug#953668: [Pkg-rust-maintainers] Bug#953668: cargo fails to find default X.509 certificates to validate https on powerpc
Hi, On Thu, Mar 12, 2020 at 11:07:08AM +0100, Fabian Grünbichler wrote: > I am not sure whether we want to work around it in cargo (by defaulting > to that location, for example), but this is related to > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927889 > > libgit2 picks up an installed ca-certificates if available in the > build-env, but does not build-depend on it. if it was available, it sets > the default CA certificate location accordingly (at build time), and > cargo works. if it was not available, the certs provided by > ca-certificates need to be passed in explicitly by any user of libgit2. As the bug is fixed in libgit2, and cargo links to the most recent version of libgit2, I think this ticket can be closed, right? (I'm hesitating to close it myself as didn't verify it really works as expected, now.) Jan
Bug#929335: [Pkg-nagios-devel] Bug#929335: nagios-plugins-contrib FTCBFS: multiple reasons
Hi Helmut, Am 21.05.19 um 22:04 schrieb Helmut Grohne: > nagios-plugins-contrib fails to build from source. The first failure is > installing Build-Depends as python and python-debian are not cross > satisfiable. Since these are only used for scripts, we can annotate them > with :native. Then, check_varnish is configured without --host. The > attached patch uses dh_auto_configure to fix that. Finally, > check_memcached hard codes the build architecture pkg-config. The > attached patch makes nagios-plugins-contrib cross buildable. Please > consider applying it. I commited the changes into VCS beside the changes about varnish, as this plugin was removed in the VCS. Cheers, Jan. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK--
Bug#975630: ITP: condure -- HTTP/WebSocket connection manager
Package: wnpp Severity: wishlist Owner: Jan Niehusmann * Package name: condure Version : 1.1.0 Upstream Author : Justin Karneges * URL : https://github.com/fanout/condure/ * License : Apache-2.0 Programming Lang: Rust Description : HTTP/WebSocket connection manager Condure is a service that manages network connections on behalf of server applications, in order to allow controlling the connections from multiple processes. Applications communicate with Condure over ZeroMQ. Condure can only manage connections for protocols it knows about. Currently this is HTTP/1 and WebSockets. See Supported protocols. The project was inspired by Mongrel2. The existing package pushpin supports condure as an alternative to mongrel2, and it looks like upstream is slowly migrating from mongrel2 to condure. As a rust software, this will be packaged as part of the debian-rust team.
Bug#975003: mount refuses to mount cifs from fstab with Unknown mount option "symfollow"
Hello. Older versions of binary packages: https://snapshot.debian.org/binary/libmount1/ https://snapshot.debian.org/binary/mount/ It works for me and davfs. For autofs/cifs have to reboot probably. Regards, JK
Bug#835596: [debian-mysql] Bug#835596: Bug#835596: [mariadb-10.0] Please ship support-files/mysqld_multi.server.sh
Hi, Am 22.11.20 um 17:22 schrieb Otto Kekäläinen: > And if you find out there are no code changes needed, maybe submit an > addition to the README's so the next users have an easier time > figuring out how to properly run multi-instnances? sorry, I'm not using this szenario anymore. So I don't have any system to test. Sorry, Jan.
Bug#975206: zurl: FTBFS: Error: need libzmq >= 2.0!
Control: reassign -1 libzmq3-dev 4.3.3-3 Control: forcemerge 975151 -1 This FTBFS was caused by a missing dependency in libzmq3-dev 4.3.3-3, which was already fixed in libzmq3-dev 4.3.3-4. On Thu, Nov 19, 2020 at 10:57:00AM +0100, Lucas Nussbaum wrote: > Source: zurl > Version: 1.11.0-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201119 ftbfs-bullseye [...] > > Checking for Qt >= 5.2.0 ... yes > > Checking for libzmq >= 2.0 ... > > * [pkg-config libzmq --exists] > > * returned: 1 > > -> no > > > > Error: need libzmq >= 2.0!
Bug#972454: Bug confirmed on arm64 as well
Hi, Was preparing a report for this bug when I found it already logged. Yesterday I found this issue as wel on arm64. Solution: Build 3.11 from source. Attachement: make.log --- Jan Huijsmans huysm...@koffie.nu ... cannot activate /dev/brain, no response from main coffee server DKMS make.log for xtables-addons-3.9 for kernel 5.9.0-2-arm64 (aarch64) Tue Nov 17 08:02:58 CET 2020 make: Entering directory '/usr/src/linux-headers-5.9.0-2-arm64' make -C /usr/src/linux-headers-5.9.0-2-arm64 -f /usr/src/linux-headers-5.9.0-2-common/Makefile modules test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2; \ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) make -f /usr/src/linux-headers-5.9.0-2-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.9/build/extensions \ single-build= \ need-builtin=1 need-modorder=1 make -f /usr/src/linux-headers-5.9.0-2-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.9/build/extensions/ACCOUNT \ \ need-builtin= \ need-modorder=1 make -f /usr/src/linux-headers-5.9.0-2-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.9/build/extensions/pknock \ \ need-builtin= \ need-modorder=1 gcc-10 -Wp,-MMD,/var/lib/dkms/xtables-addons/3.9/build/extensions/.compat_xtables.o.d -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/10/include -I/usr/src/linux-headers-5.9.0-2-common/arch/arm64/include -I./arch/arm64/include/generated -I/usr/src/linux-headers-5.9.0-2-common/include -I./include -I/usr/src/linux-headers-5.9.0-2-common/arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I/usr/src/linux-headers-5.9.0-2-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-5.9.0-2-common/include/linux/kconfig.h -include /usr/src/linux-headers-5.9.0-2-common/include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DCC_USING_PATCHABLE_FUNCTION_ENTRY -DKASAN_SHADOW_SCALE_SHIFT=3 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -fno-asynchronous- unwind-tables -Wno-psabi -mabi=lp64 -mbranch-protection=pac-ret+leaf+bti -Wa,-march=armv8.4-a -DARM64_ASM_ARCH='"armv8.4-a"' -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g -fpatchable-function-entry=2 -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=/usr/src/linux-headers-5.9.0-2-common/= -Wno-packed-not-aligned -m stack-protector-guard=sysreg -mstack-protector-guard- reg=sp_el0 -mstack-protector-guard-offset=1272 -DMODULE -DKBUILD_BASENAME='"compat_xtables"' -DKBUILD_MODNAME='"compat_xtables"' -c -o /var/lib/dkms/xtables-addons/3.9/build/extensions/compat_xtables.o /var/lib/dkms/xtables-addons/3.9/build/extensions/compat_xtables.c gcc-10 -Wp,-MMD,/var/lib/dkms/xtables-addons/3.9/build/extensions/.xt_CHAOS.o.d -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/10/include -I/usr/src/linux-headers-5.9.0-2-common/arch/arm64/include -I./arch/arm64/include/generated -I/usr/src/linux-headers-5.9.0-2-common/include -I./include -I/usr/src/linux-headers-5.9.0-2-common/arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I/usr/src/linux-headers-5.9.0-2-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-5.9.0-2-common/include/linux/kconfig.h -include /usr/src/linux-headers-5.9.0-2-common/include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DCC_USING_PATCHABLE_FUNCTION_ENTRY -DKASAN_SHADOW_SCALE_SHIFT=3 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -fno-asynchronous-unwind -tables -Wno-psabi -mabi=lp64 -mbranch-protection=pac-ret+leaf+bti -Wa,-march=armv8.4-a -DARM64_ASM_ARCH='"armv8.4-a"' -
Bug#972070: bluez-obexd: Failure to browse files, Failed to execute program org.bluez.obex: No such file or directory
I noticed the same bug when file transfer via BT would not work anymore. Some research brought up a very similar, resolved bug in the Gentoo bug tracker [1]. The cause of the problem appears to be a non-working placeholder in the binary path of the obex service file (/usr/share/dbus-1/services/org.bluez.obex.service): > Exec=@libexecdir@/obexd instead of > Exec=/usr/lib/bluetooth/obexd [1] https://bugs.gentoo.org/show_bug.cgi?id=698394#c6 Regards, Jan
Bug#974193: linux-image-5.9.0-1-amd64: sunrpc.transports sysctl contains binary data
Package: src:linux Version: 5.9.1-1 Severity: minor Dear Maintainer, The sunrpc.transports sysctl looks emtpy when directly queried with sysctl, but a closer inspection of /proc/sys/sunrpc/transports reveals a list of null bytes. Even weirder, sysctl -a does produce a different set of random(?) characters each time. I would expect an output such as: sunrpc.transports = tcp 1048576 sunrpc.transports = udp 32768 instead of this weirdness. $ /sbin/sysctl sunrpc.transports | cat -A ; od -c /proc/sys/sunrpc/transports ; /sbin/sysctl -a 2>/dev/null | grep -a sunrpc.transports sunrpc.transports = $ 000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 020 \0 \0 \0 \0 \0 \0 026 sunrpc.transports = �]� $ /sbin/sysctl -a 2>/dev/null | grep -a sunrpc.transports sunrpc.transports = �� $ /sbin/sysctl -a 2>/dev/null | grep -a sunrpc.transports sunrpc.transports = �vo� Last week I updated this system to Debian testing (from stable). -- Package-specific info: ** Version: Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.1-1 (2020-10-17) ** Command line: BOOT_IMAGE=/vmlinuz-5.9.0-1-amd64 root=/dev/mapper/gallumbits--vg-root ro security=selinux selinux=1 enforcing=0 quiet splash ** Not tainted ** Kernel log: [106119.880235] wlp3s0: associate with 10:8c:cf:45:c8:30 (try 1/3) [106119.882096] wlp3s0: RX AssocResp from 10:8c:cf:45:c8:30 (capab=0x431 status=0 aid=4) [106119.883865] wlp3s0: associated [106119.985055] wlp3s0: Limiting TX power to 17 dBm as advertised by 10:8c:cf:45:c8:30 [107923.048112] Rekeying PTK for STA 10:8c:cf:45:c8:30 but driver can't safely do that. [109750.489728] Rekeying PTK for STA 10:8c:cf:45:c8:30 but driver can't safely do that. [110774.623556] wlp3s0: Connection to AP 10:8c:cf:45:c8:30 lost [110775.552659] wlp3s0: authenticate with 10:8c:cf:45:c8:3f [110775.564745] wlp3s0: send auth to 10:8c:cf:45:c8:3f (try 1/3) [110775.573867] wlp3s0: authenticated [110775.577549] wlp3s0: associate with 10:8c:cf:45:c8:3f (try 1/3) [110775.579184] wlp3s0: RX AssocResp from 10:8c:cf:45:c8:3f (capab=0x111 status=0 aid=2) [110775.581302] wlp3s0: associated [110775.663930] wlp3s0: Limiting TX power to 17 dBm as advertised by 10:8c:cf:45:c8:3f [112547.826793] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [113700.390630] input: MX Anywhere 2 Keyboard as /devices/virtual/misc/uhid/0005:046D:B013.0008/input/input35 [113700.391394] input: MX Anywhere 2 Mouse as /devices/virtual/misc/uhid/0005:046D:B013.0008/input/input36 [113700.391973] hid-generic 0005:046D:B013.0008: input,hidraw4: BLUETOOTH HID v0.07 Keyboard [MX Anywhere 2] on f8:63:3f:ad:9b:60 [114348.207660] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [116132.560788] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [117919.948857] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [119733.414499] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [121561.843725] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [123385.320312] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [123388.358737] wlp3s0: deauthenticated from 10:8c:cf:45:c8:3f (Reason: 15=4WAY_HANDSHAKE_TIMEOUT) [123389.351694] wlp3s0: authenticate with 10:8c:cf:45:c8:30 [123389.364570] wlp3s0: send auth to 10:8c:cf:45:c8:30 (try 1/3) [123389.370529] wlp3s0: authenticated [123389.371314] wlp3s0: associate with 10:8c:cf:45:c8:30 (try 1/3) [123389.373066] wlp3s0: RX AssocResp from 10:8c:cf:45:c8:30 (capab=0x431 status=0 aid=5) [123389.374380] wlp3s0: associated [123389.419363] wlp3s0: Limiting TX power to 17 dBm as advertised by 10:8c:cf:45:c8:30 [123420.689422] wlp3s0: disconnect from AP 10:8c:cf:45:c8:30 for new auth to 10:8c:cf:45:c8:3f [123420.706046] wlp3s0: authenticate with 10:8c:cf:45:c8:3f [123420.719214] wlp3s0: send auth to 10:8c:cf:45:c8:3f (try 1/3) [123420.725049] wlp3s0: authenticated [123420.731234] wlp3s0: associate with 10:8c:cf:45:c8:3f (try 1/3) [123420.733363] wlp3s0: RX ReassocResp from 10:8c:cf:45:c8:3f (capab=0x111 status=0 aid=4) [123420.737478] wlp3s0: associated [123420.765964] wlp3s0: Limiting TX power to 17 dBm as advertised by 10:8c:cf:45:c8:3f [125243.819212] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [127015.155167] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [128799.543331] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [130601.937152] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [132400.352431] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [134225.821021] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely do that. [136038.256243] Rekeying PTK for STA 10:8c:cf:45:c8:3f but driver can't safely
Bug#973468: gnome-shell-extension-multi-monitors: Broken by GNOME 3.38
Package: gnome-shell-extension-multi-monitors Version: 20-1 Severity: important Dear Maintainer, The extension does not work with GNOME 3.38. There is initial code in the upstream git repository to enable the extension for GNOME 3.38, but I am unsure how well it works: https://github.com/spin83/multi-monitors-add-on/issues/137 Thanks, Jan Medlock -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell-extension-multi-monitors depends on: ii gnome-shell 3.38.1-1 gnome-shell-extension-multi-monitors recommends no packages. gnome-shell-extension-multi-monitors suggests no packages. -- no debconf information
Bug#783052: cadaver: remote globbing patch
tags 333431 + patch tags 783052 + patch thanks Hi, attached is a patch that fixes these two bugs. There's also an updated package available here[1b][1s] which contains one further cosmetic change to the configure script, see debdiff[2] and the changelog stanza: = cadaver (0.23.3-2.2) unstable; urgency=low * Non-maintainer upload. * (configure) Allow building with more recent versions of libneon. Previous versions were claiming to build with the bundled libneon 0.29.1, but used the more recent system one (0.30) anyway because build of the bundled version failed without aborting the overall compilation. This change thus only documents the (well-seasoned) status quo. * Fix quoting issues. Closes: #333431, #783052. -- Jan Nordholz Tue, 27 Oct 2020 15:07:59 +0100 = Feel free to adopt, adapt, upload, whatever you feel like. Jan [1b]: https://mc.svnsa.tu-berlin.de/deb/cadaver_0.23.3-2.2_amd64.deb [1s]: https://mc.svnsa.tu-berlin.de/deb/cadaver_0.23.3-2.2.dsc [2]: https://mc.svnsa.tu-berlin.de/deb/cadaver_0.23.3-2.2.debdiff -- Prof. Dr.-Ing. Jan Nordholz Sichere und vertrauenswürdige netzangebundene Systemarchitekturen Technische Universität Berlin / Physikalisch-Technische Bundesanstalt Raum 03.22, Salzufer 11, 10587 Berlin Tel.: +49 30 3481 7321
Bug#972927: Kernel 5.9.1-1 - NIC problem
Package: linux 5.9.1-1 Version: 5.9.1-1 After upgrade to Kernel 5.9.0-1-amd64 I have only one NIC eno1 ( eno2, eno3 and eno4 are gone) on my Super Micro A2SDi-4C-HLN4F. = eno2, eno3 and eno4 are missing Thanks Jan Vecek Oct 26 03:15:43vecinoap rsyslogd: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd. [v8.2008.0] Oct 26 03:15:43 vecinoap rsyslogd: [origin software="rsyslogd" swVersion="8.2008.0" x-pid="577" x-info="https://www.rsyslog.com;] start Oct 26 03:15:43 vecinoap rsyslogd: action 'action-0-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2008.0 try https://www.rsyslog.com/e/2007 ] Oct 26 03:15:43 vecinoap rsyslogd: action 'action-0-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2008.0 try https://www.rsyslog.com/e/2359 ] Oct 26 03:15:43 vecinoap kernel: [0.00] Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.1-1 (2020-10-17) Oct 26 03:15:43 vecinoap kernel: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-1-amd64 root=UUID=f21aabf7-bd6d-4e92-b7f5-1a36a05c2db7 ro quiet Oct 26 03:15:43 vecinoap kernel: [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Oct 26 03:15:43 vecinoap kernel: [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Oct 26 03:15:43 vecinoap kernel: [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' Oct 26 03:15:43 vecinoap kernel: [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Oct 26 03:15:43 vecinoap kernel: [0.00] x86/fpu: xstate_offset[3]: 576, xstate_sizes[3]: 64 Oct 26 03:15:43 vecinoap kernel: [0.00] x86/fpu: xstate_offset[4]: 640, xstate_sizes[4]: 64 Oct 26 03:15:43 vecinoap kernel: [0.00] x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format. Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-provided physical RAM map: Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x-0x000997ff] usable Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x00099800-0x0009] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x0010-0x76fa2fff] usable Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x76fa3000-0x76fb2fff] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x76fb3000-0x7d2dcfff] usable Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x7d2dd000-0x7ddb9fff] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x7ddba000-0x7de95fff] usable Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x7de96000-0x7e1defff] ACPI NVS Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x7e1df000-0x7f23] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x7f24-0x7f7f] usable Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x7f80-0x7fff] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0xfd00-0xfe7f] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0xff00-0x] reserved Oct 26 03:15:43 vecinoap kernel: [0.00] BIOS-e820: [mem 0x0001-0x00027fff] usable Oct 26 03:15:43 vecinoap kernel: [0.00] NX (Execute Disable) protection: active Oct 26 03:15:43 vecinoap kernel: [0.00] SMBIOS 3.0.0 present. Oct 26 03:15:43 vecinoap kernel: [0.00] DMI: Supermicro Super Server/A2SDi-4C-HLN4F, BIOS 1.2 11/05/2019 Oct 26 03:15:43 vecinoap kernel: [0.00] tsc: Detected 2200.000 MHz processor Oct 26 03:15:43 vecinoap kernel: [0.000575] last_pfn = 0x28 max_arch_pfn = 0x4 Oct 26 03:15:43 vecinoap kernel: [0.000687] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT Oct 26 03:15:43 vecinoap kernel: [0.000763] last_pfn = 0x7f800 max_arch_pfn = 0x4 Oct 26 03:15:43 vecinoap kernel: [0.005158] found SMP MP-table at [mem 0x000fcdc0-0x000fcdcf] Oct 26 03:15:43 vecinoap kernel: [0.005418] Using GB pages for direct mapping Oct 26 03:15:43 vecinoap kernel: [0.006257] RAMDISK: [mem 0x3476b000-0x363acfff] Oct 26 03:15:43 vecinoap kernel: [0.006264] ACPI: Early table checksum verification disab
Bug#972428: anymeal FTCBFS: abuses AC_CHECK_FILE
On Mon, 19 Oct 2020, Boyuan Yang wrote: Hi, 在 2020-10-19星期一的 18:33 +0100，Jan Wedekind写道： Hi Boyuan, hi Helmut, I have incorporated the bug fixes for cross-platform build. I also have made other changes in the meantime. Boyuan, can you please upload the new version to Debian unstable. You can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.10-1.dsc Kind regards Jan Wedekind It's now uploaded. Best, Boyuan Yang Hi Boyuan, Thank you for reviewing and uploading. Kind regards Jan
Bug#594573: Translation Anymeal to Russian
Hi, The translation would need updating anyway, because I did a lot of changes to the user interface. Regards Jan On Mon, 19 Oct 2020, tony mancill wrote: Hello, On Mon, Oct 19, 2020 at 04:01:37PM +0300, Сергей Савин wrote: Hello. I don't have a copy. I have checked and the most recent build of anymeal I have is from an upload in May of 2008 (0.30-7), and I can't find a copy of the patch on my system. I apologize for dropping the ball on this. tony 19.10.2020 03:42, Paul Wise пишет: On Tue, Aug 24, 2010 at 20:34, Sergey Savin wrote: I've translated program Anymeal from Debian lenny repository to Russian. I send you ru.po file. Please, include it to the package anymeal in debian lenny repository. Sergey, your Russian translation of Anymeal appears to have been lost. If you do not have a copy of the translation, please let us know. If you do have a copy of the translation: If you have a GitHub account, please update it for the latest version and file an issue requesting it be included into the upstream project. https://github.com/wedesoft/anymeal/issues Otherwise, you could attach it to a mail and send to the Debian bug: 594...@bugs.debian.org PS: the bug that was filed about your translation is available here: https://bugs.debian.org/594573
Bug#972428: anymeal FTCBFS: abuses AC_CHECK_FILE
Hi Boyuan, hi Helmut, I have incorporated the bug fixes for cross-platform build. I also have made other changes in the meantime. Boyuan, can you please upload the new version to Debian unstable. You can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.10-1.dsc Kind regards Jan Wedekind [1]: https://mentors.debian.net/package/anymeal/
Bug#594573: Translation Anymeal to Russian
Hi, I don't have a copy either. This bug is 10 years old and got woken up by my new release of AnyMeal. Kind regards Jan Am 19. Oktober 2020 14:01:37 GMT+01:00 schrieb "Сергей Савин" : >Hello. I don't have a copy. > >19.10.2020 03:42, Paul Wise пишет: >> On Tue, Aug 24, 2010 at 20:34, Sergey Savin wrote: >> >>> I've translated program Anymeal from Debian lenny repository to >Russian. >>> I send you ru.po file. >>> Please, include it to the package anymeal in debian lenny >repository. >> Sergey, your Russian translation of Anymeal appears to have been >lost. >> >> If you do not have a copy of the translation, please let us know. >> >> If you do have a copy of the translation: >> >> If you have a GitHub account, please update it for the latest version >> and file an issue requesting it be included into the upstream >project. >> >> https://github.com/wedesoft/anymeal/issues >> >> Otherwise, you could attach it to a mail and send to the Debian bug: >> >> 594...@bugs.debian.org >> >> PS: the bug that was filed about your translation is available here: >> >> https://bugs.debian.org/594573 >> -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Bug#972346: sagemath-common: Sagemath does not work with Cantor, sage-env binary is needed
Thank you for the detailed analysis. On Fri, 16 Oct 2020 12:25:53 -0400 John Scott wrote: > On Friday, October 16, 2020 11:29:14 AM EDT Jan Kriho wrote: > > The launcher scripts is dependent on sage-env binary which sets env for > > executing further commands > Note that even if sage-env were to be available, I don't think Cantor would be > able to find it. It appears to invoke `sage --root` to figure out where to > look, > but the output is empty. I see, so the sage-env binary won't be called anyway. > Cantor could be doing things in a more clean way regardless though. Instead of > fiddling with $SAGE_ROOT in a shell script, it could use the one-liner > sage --ipython3 -i --simple-prompt > > or use /usr/bin/sage --sh for the shebang in the script and call sage-ipython This actually looks like a way better option. I have made a quick test with it, and it looks like it works like it's supposed to. Should the bug be reassigned to Cantor upstream?
Bug#972346: sagemath-common: Sagemath does not work with Cantor, sage-env binary is needed
Package: sagemath-common Version: 9.2~beta12-1 Severity: normal X-Debbugs-Cc: erbur...@gmail.com Dear Maintainer, Cantor is a front-end for several math SW. However recently it stopped working for Sage with following error in the terminal: out: "/usr/share/cantor/sagebackend/cantor-execsage: line 13: exec: sage- ipython: not found\r\n" The launcher scripts is dependent on sage-env binary which sets env for executing further commands: ``` #!/usr/bin/env bash export SAGE_ROOT="$($1 --root)" if [[ -f $SAGE_ROOT"/bin/sage-env" ]]; then . "$SAGE_ROOT/bin/sage-env" >&2 elif [[ -f $SAGE_ROOT"/local/bin/sage-env" ]]; then . "$SAGE_ROOT/local/bin/sage-env" >&2 elif [[ -f $SAGE_ROOT"/src/bin/sage-env" ]]; then . "$SAGE_ROOT/src/bin/sage-env" >&2 fi exec sage-ipython -i --simple-prompt ``` Please consider re-adding the binary back to the package. Regards, Jan Kriho -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (950, 'testing'), (900, 'unstable'), (850, 'experimental'), (800, 'stable'), (775, 'oldstable'), (500, 'oldoldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sagemath-common depends on: ii python3 3.8.2-3 sagemath-common recommends no packages. sagemath-common suggests no packages. -- no debconf information
