Bug#1003041: krita: Krita 4.4.2 on bullseye crashes most of the time when I try to apply filters on a transparency layer.
Package: krita Version: 1:4.4.2+dfsg-1: amd64 Dear Maintainer, Krita 4.4.2 on Bullseye crashes most of the time when I try to apply Gaussian Blur or any other filter on a transparency mask unless I disable the preview option. It happens when I try to apply other filters as well. I have tested it by installing Krita on a fresh Debian Bullseye on a virtual machine as well and it happens there as well. Here is the console output of Krita when the crash occurs. safi@safi-pc:~$ krita (process:12176): Gtk-WARNING **: 12:27:33.157: Locale not supported by C library. Using the fallback 'C' locale. Invalid profile : "/usr/share/color/icc/colord/Crayons.icc" "Crayon Colors" Invalid profile : "/usr/share/color/icc/colord/x11-colors.icc" "X11 Colors" Could not set current file 0 "brushes/rake_sparse.png" krita.general: Bundle is broken. File "brushes/rake_sparse.png" is missing Could not set current file 0 "brushes/rock_pitted.gih" krita.general: Bundle is broken. File "brushes/rock_pitted.gih" is missing Could not set current file 0 "brushes/square_rough.png" krita.general: Bundle is broken. File "brushes/square_rough.png" is missing krita.general: Due to missing files and wrong entries in the manifest, "/usr/share/krita/bundles/RGBA_brushes.bundle" will be recreated. QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/Craig_02.png" 0 krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/DA_RGBA bluegreen_small.png" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/DA_RGBA bluegreen_small1.png" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/DA_Triangle grain.png" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/Mountain_Brush_01.png" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/RGBA anim 01.gih" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing Could not set current file 0 "brushes/rake_sparse.png" Could not set current file 0 "brushes/rock_pitted.gih" Could not set current file 0 "brushes/square_rough.png" QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_01_Thick-dry.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_02_Thickpaint.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_03_Rake.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_04_Impasto.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_05_Impasto-details.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_06_Rock.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "preview.png" 0 QBuffer::setBuffer: Buffer is open krita.general: Could not open preview.png krita.lib.store: KoStore: You must open before writing krita.general: Could not write preview.png krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "META-INF/manifest.xml" 0
Bug#1003040: ITP: asdf-astropy -- ASDF serialization support for astropy
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, debian-as...@lists.debian.org * Package name: asdf-astropy Version : 0.1.2 Upstream Author : The ASDF Developers * URL : https://github.com/astropy/asdf-astropy * License : BSD-3-Clause Programming Lang: Python Description : ASDF serialization support for astropy This package includes plugins that provide ASDF serialization support for astropy objects. The plugins are automatically enabled when the package is installed. ASDF (Advanced Scientific Data Format) is a proposed next generation interchange format for scientific data, mainly used by the Space Telescope Science Institude (STScI). It is a new build dependency of the gwcs package. I will maintain it within the Debian Astro team in Salsa: https://salsa.debian.org/debian-astro-team/asdf-astropy Best regards Ole
Bug#1003039: node-terser: Please update node-commander dependency to version 8
Package: node-terser
Version: 4.1.2-9
Severity: important
Tags: patch
Hi,
node-commander 8 changed option parsing. Here is a proposed patch to be
used in replacement of 1001_use_commander_4.patch
Description: support node module commander release 8
same patch than uglifyjs
Author: Yadd
Forwarded: no
Last-Update: 2022-01-03
--- a/bin/uglifyjs
+++ b/bin/uglifyjs
@@ -28,6 +28,15 @@
program.version(info.name + " " + info.version);
program.parseArgv = program.parse;
program.parse = undefined;
+var argv = [];
+process.argv.forEach(function(arg){
+ if(arg.match(/^-([pcmbode]+)$/)) {
+argv = argv.concat(RegExp.$1.split('').map(s => { return '-'+s }));
+ }
+ else argv.push(arg);
+});
+process.argv = argv;
+
if (process.argv.includes("ast")) program.helpInformation = describe_ast;
else if (process.argv.includes("options")) program.helpInformation =
function() {
var text = [];
@@ -65,10 +74,11 @@
program.option("--warn", "Print warning messages.");
program.option("--wrap ", "Embed everything as a function with “exports”
corresponding to “name” globally.");
program.arguments("[files...]").parseArgv(process.argv);
-if (program.configFile) {
-options = JSON.parse(read_file(program.configFile));
+const opts = program.opts();
+if (opts.configFile) {
+options = JSON.parse(read_file(opts.configFile));
}
-if (!program.output && program.sourceMap && program.sourceMap.url != "inline")
{
+if (!opts.output && opts.sourceMap && opts.sourceMap.url != "inline") {
fatal("ERROR: cannot write source map to STDOUT");
}
[
@@ -82,83 +92,83 @@
"toplevel",
"wrap"
].forEach(function(name) {
-if (name in program) {
-options[name] = program[name];
+if (name in opts) {
+options[name] = opts[name];
}
});
-if ("ecma" in program) {
-if (program.ecma != (program.ecma | 0)) fatal("ERROR: ecma must be an
integer");
-options.ecma = program.ecma | 0;
+if ("ecma" in opts) {
+if (opts.ecma != (opts.ecma | 0)) fatal("ERROR: ecma must be an integer");
+options.ecma = opts.ecma | 0;
}
-if (program.beautify) {
-options.output = typeof program.beautify == "object" ? program.beautify :
{};
+if (opts.beautify) {
+options.output = typeof opts.beautify == "object" ? opts.beautify : {};
if (!("beautify" in options.output)) {
options.output.beautify = true;
}
}
-if (program.comments) {
+if (opts.comments) {
if (typeof options.output != "object") options.output = {};
-options.output.comments = typeof program.comments == "string" ?
program.comments : "some";
+options.output.comments = typeof opts.comments == "string" ? opts.comments
: "some";
}
-if (program.define) {
+if (opts.define) {
if (typeof options.compress != "object") options.compress = {};
if (typeof options.compress.global_defs != "object")
options.compress.global_defs = {};
-for (var expr in program.define) {
-options.compress.global_defs[expr] = program.define[expr];
+for (var expr in opts.define) {
+options.compress.global_defs[expr] = opts.define[expr];
}
}
-if (program.keepClassnames) {
+if (opts.keepClassnames) {
options.keep_classnames = true;
}
-if (program.keepFnames) {
+if (opts.keepFnames) {
options.keep_fnames = true;
}
-if (program.mangleProps) {
-if (program.mangleProps.domprops) {
-delete program.mangleProps.domprops;
+if (opts.mangleProps) {
+if (opts.mangleProps.domprops) {
+delete opts.mangleProps.domprops;
} else {
-if (typeof program.mangleProps != "object") program.mangleProps = {};
-if (!Array.isArray(program.mangleProps.reserved))
program.mangleProps.reserved = [];
+if (typeof opts.mangleProps != "object") opts.mangleProps = {};
+if (!Array.isArray(opts.mangleProps.reserved))
opts.mangleProps.reserved = [];
}
if (typeof options.mangle != "object") options.mangle = {};
-options.mangle.properties = program.mangleProps;
+options.mangle.properties = opts.mangleProps;
}
-if (program.nameCache) {
-options.nameCache = JSON.parse(read_file(program.nameCache, "{}"));
+if (opts.nameCache) {
+options.nameCache = JSON.parse(read_file(opts.nameCache, "{}"));
}
-if (program.output == "ast") {
+if (opts.output == "ast") {
options.output = {
ast: true,
code: false
};
}
-if (program.parse) {
-if (!program.parse.acorn && !program.parse.spidermonkey) {
-options.parse = program.parse;
-} else if (program.sourceMap && program.sourceMap.content == "inline") {
+if (opts.parse) {
+if (!opts.parse.acorn && !opts.parse.spidermonkey) {
+options.parse = opts.parse;
+} else if (opts.sourceMap && opts.sourceMap.content == "inline") {
fatal("ERROR: inline source map only works with built-in parser");
}
}
if (~program.rawArgs.indexOf("--rename")) {
options.rename = true;
-} else if (!program.rename) {
+} else if (!opts.rename) {
Bug#990128: libcurl4-gnutls-dev: Un-installable in multiarch environment again in version 7.80.0-3: /usr/bin/curl-config differs
Hello,
a quite similar bug has been reintroduced in version 7.80.0-3 of
libcurl4-gnutls-dev:
The package is again unistallable in multiarch environments due to
differences in libcurl4-gnutls-dev. This time, it is the -L linker
options that contain the architecture triplet (e.g. amd64-linux-gnu, see
attached diff file).
Should this new difference in curl-config be handled by re-opening this
bug report or should I create a new one?
Best regards
Michael Schmeing
--
Michael Schmeing
Kahlhorststraße 36A
23562 Lübeck
E-Mail: mich...@michael-schmeing.de
Tel.: +49 451 30406604
Mobil: +49 176 22961510
--- amd64/usr/bin/curl-config 2021-12-26 17:22:18.0 +0100
+++ i386/usr/bin/curl-config 2021-12-26 17:22:18.0 +0100
@@ -152,7 +152,7 @@
--libs)
CURLLIBDIR=""
if test "Xyes" = "Xno"; then
- echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -L/usr/lib/x86_64-linux-gnu/mit-krb5 -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
+ echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -L/usr/lib/i386-linux-gnu/mit-krb5 -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
else
echo ${CURLLIBDIR}-lcurl
fi
@@ -163,7 +163,7 @@
--static-libs)
if test "Xyes" != "Xno" ; then
- echo -Wl,-Bstatic -lcurl -Wl,-Bdynamic -Wl,-z,relro -Wl,-z,now -lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -L/usr/lib/x86_64-linux-gnu/mit-krb5 -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
+ echo -Wl,-Bstatic -lcurl -Wl,-Bdynamic -Wl,-z,relro -Wl,-z,now -lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -L/usr/lib/i386-linux-gnu/mit-krb5 -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
else
echo "curl was built with static libraries disabled" >&2
exit 1
Bug#811294: ITP: tabview -- curses command-line CSV and list (tabular data) viewer
On Sun, 17 Jan 2016 18:55:20 +0100 Yuri D'Elia wrote: > Package: wnpp > Severity: wishlist > Owner: "Yuri D'Elia" > > * Package name: tabview > Version : 1.4.1 > Upstream Author : Scott Hansen > * URL : https://github.com/firecat53/tabview > * License : MIT > Programming Lang: Python > Description : curses command-line CSV and list (tabular data) viewer > > tabview is both a minimal, stand-alone curses command-line CSV/tabular-data > viewer and a Python module that can be used to view basic Python types > directly > in an interactive spreadsheet. > > The curses interface offers VIM-like keyboard bindings, sorting and full-text > incremental search. > > --- > > There are currently very few alternatives to tabview in debian. I've used "sc" > and "teapot" (not in Debian) to the same extent, however both are complete > spreadsheet programs (with sc requiring an extra "import" step), whereas > tabview allows to just view a csv/tsv file easily. > > tabview is both helpful stand-alone, but also works greatly when used in > combination with ipython or any interactive python session, allowing one to > browse through a large data table visually. To this extent, I'm using tabview > heavily with the scipy stack. > > I'm planning to maintain this package in the python-modules team. > > Hello! I see that you've done some work packaging this module in Debian already: https://salsa.debian.org/python-team/packages/tabview/ I'm currently packaging CleverCSV and tabview is an optional dependency. I was wondering if you were planning on finishing the work for tabview. For what it's worth, I'd be happy to mentor you and sponsor this package if you commit to maintaining it in Debian :) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1003038: mkfs.hfs does not respect the -v option when creating an HFS volume
Package: hfsprogs Version: 540.1.linux3-4 Hello Maintainers, Creating an HFS volume with a volume name other than the default of "untitled" is currently not possible. It does appear that it should be possible. Here is output exhibiting this issue: == # mkfs.hfs -b 512 -v 'grub' -h /tmp/hfs.img Initialized /tmp/hfs.img as a 5120 MB HFS volume # fsck.hfs /tmp/hfs.img ** /tmp/hfs.img Executing fsck_hfs (version 540.1-Linux). ** Checking HFS volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled appears to be OK. == Using -N to print the parameters shows that at least the option parsing allows this: == # mkfs.hfs -N -b 512b -v 'grub' -h /tmp/hfs.img 0 sectors at 512 bytes per sector HFS format parameters: volume name: "grub" block-size: 262144 total blocks: 20480 first free catalog node id: 16 initial catalog file size: 1048576 initial extents file size: 1048576 file clump size: 1048576 == Looking at the package source, I see that HFS volume creation is added as a debian package patch and not part of the upstream source in patch file debian/patches/0005-Re-add-support-for-creating-legacy-HFS-filesystems.patch. The issue appears to be that the volume name passed in as the -v option argument and being written to the hfs parameters struct is being unconditionally overritten in line 325 of the patch file with the default volume name. This can be fixed by swapping the first two aruments to bcopy on that line, however, the comment and the lines directly above it lead me to believe there's potentially more to it. This is causing GRUB HFS tests to fail and it would be nice to get them passing again without disabling the failing test. Thanks, Glenn
Bug#1003037: astra-toolbox: FTBFS: error: parameter packs not expanded with '...'
Source: astra-toolbox Version: 1.8.3-10 Severity: serious Tags: ftbfs Justification: fails to build from source Hi, astra-toolbox recently started to FTBFS, probably due to some updated toolchain package or build dependency.: /usr/bin/nvcc -gencode=arch=compute_35,code=sm_35 -gencode=arch=compute_50,code=sm_50 -gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_60,code=compute_60 -I../build/linux/../.. -I../build/linux/../../include -DASTRA_CUDA -c ../build/linux/../../cuda /3d/mem3d.cu -Xcompiler -fPIC -DPIC -o cuda/3d/.libs/mem3d.o /usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not expanded with '...': 435 | function(_Functor&& __f) | ^ /usr/include/c++/11/bits/std_function.h:435:145: note: '_ArgTypes' /usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not expanded with '...': 530 | operator=(_Functor&& __f) | ^ /usr/include/c++/11/bits/std_function.h:530:146: note: '_ArgTypes' make[2]: *** [Makefile:361: cuda/3d/mem3d.lo] Error 1 Andreas astra-toolbox_1.8.3-10.log.gz Description: application/gzip
Bug#1003036: ITP: golang-github-fatih-camelcase -- Split a camelcase word into a slice of words in Go
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org Package: wnpp Severity: wishlist Owner: "Mason Giles" * Package name : golang-github-fatih-camelcase Version : 1.0.0-1 Upstream Author : Fatih Arslan * URL : https://github.com/fatih/camelcase * License : Expat Programming Lang: Go Description : Split a camelcase word into a slice of words in Go CamelCase is a Go package to split the words of a camelcase type string into a slice of words. It can be used to convert a camelcase word (lower or upper case) into any type of word. As with all Go packages, it should be team-maintained within the Debian Go Packaging Team. This package is part of the dependency tree of an attempt to package LiteIDE: - liteide - gocode - gotools - golang-github-visualfc-fastmod - golang-github-visualfc-goversion - gomodifytags - golang-github-fatih-camelcase (*) - golang-github-fatih-structtag
Bug#1003008: Error 134633601: Error while parsing number"
Control: severity -1 critical On Sun, Jan 02, 2022 at 09:14:54PM +0300, Eugene Berdnikov wrote: > After upgrade grub-legacy from 0.97-78 to 0.97-79 installation fails > with message "Error 134633601: Error while parsing number": > > - > grub> root (hd0,0) > root (hd0,0) > Filesystem type is ext2fs, partition type 0x8065e03 > grub> setup (hd0) > setup (hd0) > Checking if "/boot/grub/stage1" exists... no > Checking if "/grub/stage1" exists... yes > Checking if "/grub/stage2" exists... yes > Checking if "/grub/e2fs_stage1_5" exists... yes > Running "embed /grub/e2fs_stage1_5 (hd-141250989)"... failed (this is not > fatal) > Running "embed /grub/e2fs_stage1_5 (hd-141250989,-"... failed (this is not > fatal) > Running "install /grub/stage1 (hd-141250989) /grub/stage2 p /grub/menu.lst > "... failed > > Error 134633601: Error while parsing number > - > > Observed on all updated hosts (about ten in my own). Rollback to 0.97-78 > resolves the problem (with the same config files). Ugh, sorry about this. I didn't actually change any patches against the upstream code in 0.97-79, so this must have been broken by the mere act of rebuilding it, I think. I'll see if I can construct a suitable test environment. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1002978: Another GPU hang
I rebooted with the GRUB options intel_idle.max_cstate=1 i915.disable_power_well=1 i915.enable_dc=0 which my research shows sometimes helps with these kinds of GPU hangs. For quite some time performance was acceptable, but less than 20 hours later I triggered a GPU hang by switching desktops rapidly in fvwm. I was executing my keyboard equivalents for fvwm's 'Desk 0 9' followed by 'Scroll +0 +100' followed by 'Scroll +0 -100' followed by 'Desk 0 11' in repeated cycling when the system hung. Before the hang, the dmesg output reports three lines with 'perf: interrupt took too long'. These were minor hiccups/freezes that failed to trigger a crash/CPU hang error in the logs. But I consider them related to the problem. I was again changing desktops and moving around my desktops using my keyboard shortcuts mentioned above and the i915 driver could not cope. Back in Jessie this kind of work was routine for me with no fear of triggering kernel stack dumps. The i915 driver appears to have developed major bugs at least with my chipset. I have attached dmesg output capturing boot messages and the crash/hang. The other file contains the output of 'cat /sys/class/drm/card0/error'. I am planning to reboot soon to try another test, since daily GPU hangs will slow my productivity unacceptibly. I need to keep debugging in the hopes that I can find a solution. -- CJ Fearnley | LinuxForce Inc. c...@linuxforce.net | Hosting and Linux Consulting https://www.LinuxForce.net | https://blog.LinuxForce.net [0.00] Linux version 5.10.0-10-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-10-amd64 root=/dev/mapper/precession-root ro quiet pcie_aspm=force intel_idle.max_cstate=1 i915.disable_power_well=1 i915.enable_dc=0 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xbad92fff] usable [0.00] BIOS-e820: [mem 0xbad93000-0xbadd9fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbadda000-0xbade0fff] ACPI data [0.00] BIOS-e820: [mem 0xbade1000-0xbade1fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbade2000-0xbae04fff] reserved [0.00] BIOS-e820: [mem 0xbae05000-0xbae05fff] usable [0.00] BIOS-e820: [mem 0xbae06000-0xbae17fff] reserved [0.00] BIOS-e820: [mem 0xbae18000-0xbae24fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbae25000-0xbae48fff] reserved [0.00] BIOS-e820: [mem 0xbae49000-0xbae8bfff] ACPI NVS [0.00] BIOS-e820: [mem 0xbae8c000-0xbaff] usable [0.00] BIOS-e820: [mem 0xbb80-0xbf9f] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00023fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: BIOSTAR Group H61MU3/H61MU3, BIOS 4.6.4 04/07/2011 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 2394.344 MHz processor [0.000831] e820: update [mem 0x-0x0fff] usable ==> reserved [0.000834] e820: remove [mem 0x000a-0x000f] usable [0.000843] last_pfn = 0x23fe00 max_arch_pfn = 0x4 [0.000847] MTRR default type: uncachable [0.000848] MTRR fixed ranges enabled: [0.000850] 0-9 write-back [0.000851] A-B uncachable [0.000852] C-C write-protect [0.000853] D-E7FFF uncachable [0.000854] E8000-F write-protect [0.000854] MTRR variable ranges enabled: [0.000856] 0 base 0 mask E write-back [0.000857] 1 base 2 mask FC000 write-back [0.000859] 2 base 0BB80 mask FFF80 uncachable [0.000860] 3 base
Bug#1003035: ITP: python-clevercsv -- Mutable set data type that remembers the order of its entries
Package: wnpp Severity: wishlist Owner: Louis-Philippe Véronneau Package name: python-clevercsv Version : 0.7.1 URL : https://github.com/alan-turing-institute/CleverCSV License : Expat Programming Lang: Python Description : Drop-in replacement for the Python csv package with improved dialect detection CleverCSV provides a drop-in replacement for the Python csv package with improved dialect detection for messy CSV files. It also provides a handy command line tool that can standardize a messy file or generate Python code to import it. This package is required to upload deepdiff version 5.6.0. I'm planning to maintain this package in the Python Team. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#967275: Bug#967582: libgtkdatabox: depends on deprecated GTK 2
Hi Graham, nice to hear all this! Klavaro is again linking against the library externally, from release 3.12, see: https://sourceforge.net/p/klavaro/news/2021/04/release-312/ Em dom., 2 de jan. de 2022 às 10:11, Graham Inggs escreveu: > Control: tags -1 + pending fixed-in-experimental > Control: block 967275 by -1 > Control: severity 967275 important > Control: block 967831 by -1 > Control: severity 967831 important > > Hi Felipe > > On Sun, 6 Jun 2021 at 23:42, Felipe Castro wrote: > > Hi, I'm the new upstream maintainer of GtkDatabox and we have released > version 1.0.0 this year, which depends now on GTK3, please update it on > Debian. > > The packages which depend on it are klavaro, xoscope and brp-pacu. > > From those, the only upstream which still depends on old gtkdatabox is > brp-pacu, but there is a fork which has done the upgrade to use the new > GTK3 version at GitHub, see: https://github.com/matthew-dews/brp-pacu > > The problem is that they have not released this new version yet, but I > could provide another fork and release, if that is the case. > > Thanks for your work on these packages! > > I've uploaded libtgkdatabox 1.0.0 to experimental. Once it clears NEW > [1], I will prepare uploads of xoscope and brp-pacu which I have > already tested. klavaro seems to be using an embedded copy of > libgtkdatabox. > > Regards > Graham > > > [1] https://ftp-master.debian.org/new.html >
Bug#715900: Bug fixed in fact!
https://gitee.com/huzheng/stardict-3.0.7/commit/d9d480bdae9c6a95df1662f4a4a34d9de57d78f4 = 不带参数运行这个程序啊！要有正确的输入！ = Hu Zheng 13017203...@139.com 电子名片新出VIP模板啦，快来体验>> 扫一扫, 快速添加名片到手机
Bug#1003034: ITP: obs-scene-collection-manager -- plugin for OBS Studio to generate sets of scenes
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-de...@lists.debian.org, Exeldro * Package name: obs-scene-collection-manager Version : 0.0.2 Upstream Author : Exeldro * URL : https://obsproject.com/forum/resources/scene-collection-manager.1434/ * License : GPL-2 Programming Lang: C++ Description : plugin for OBS Studio to generate sets of scenes This plugin allows the user to generate several sets of scenes to use in different scenarios. To choose and use a set of scenes, just click over a name in a menu. Also is possible to filter, backup and restore scene collections. . The Scene Collection Manager will appear on the main menu and on the Tools menu when installed. . This plugin is compatible with OBS 26 or higher.
Bug#1003033: cowdancer: harden package verification
Source: cowdancer
Version: 0.89
Severity: wishlist
Tags: security
Hey.
I was looking a bit through the code of cowbuilder and qemubuilder.
E.g. for qemubuilder, the manpage already says:
"The possible configuration options are as follows. Others are ignored."
Altough, it seemed in the code it would in fact respect ALLOWUNTRUSTED.
However, it doesn't seem to respect DEBOOTSTRAPOPTS? Taking just these
instead:
debootstrap_command_line[1] = "--arch";
debootstrap_command_line[2] = pc->arch;
debootstrap_command_line[3] = "--foreign";
DEBOOTSTRAP_ADD_PARAM(pc->distribution);
DEBOOTSTRAP_ADD_PARAM(pc->buildplace);
DEBOOTSTRAP_ADD_PARAM(pc->mirror);
DEBOOTSTRAP_ADD_PARAM(NULL);
Especially if one has set something like:
DEBOOTSTRAPOPTS=('--force-check-gpg'
'--keyring=/usr/share/keyrings/debian-archive-keyring.gpg'
'--variant=buildd')
to make sure that gpg signatures with the keyring are really always
used (as far as I understand, debootstrap allows fallback to just
https otherwise).
Does it consider APTKEYRINGS? Or at least just copy the host systems
APT keyrings safely into the VM and use only these?
I haven't checked so much, whether it's already done properly for cowbuilder.
Thanks,
Philippe
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
this is addressed in more detail at https://github.com/dankamongmen/notcurses/issues/2519. i expect to have this fixed within the hour. sorry for the annoyance.
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
reopen 1003009 i added -DBUILD_FFI_LIBRARY=off with the intention of no longer building these three shared objects. looking at it now, however, this CMake variable doesn't actually seem to guard their building and installation, and thus it will not have the desired effect. i'm fixing this upstream, and will build a -3 with the necessary patch. sigh.
Bug#998383: nheko: nheko/{armel,armhf} has unsatisfiable dependency
On Wed, 3 Nov 2021 14:25:41 +0200 Adrian Bunk wrote: Control: reassign -1 src:gst-plugins-good1.0 1.18.5-1 Control: retitle -1 gstreamer1.0-qt5 should again be built on armel/armhf Control: affects -1 nheko On Wed, Nov 03, 2021 at 12:03:20PM +0100, Sebastian Ramacher wrote: > Source: nheko > Version: 0.8.2-2 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > nheko fails to migrate to testing since it depends on gstreamer1.0-qt5. > This package is not available on armel and armhf. With #894076 fixed, gstreamer1.0-qt5 builds again on armel/armhf. I'll submit a MR for that. Hi Adrian, Any progress on this topic? Thanks, _g. OpenPGP_signature Description: OpenPGP digital signature
Bug#952808: Interest in helping maintain clojure-mode
Hello Michael Platt, On Mon 21 Sep 2020 at 08:30AM -04, Michael Platt wrote: > Hi Mr. Whitton, > > I'm looking to do some work to start getting into helping maintain Debian. > I use the OS and very much enjoy it as my everyday development system. I > am also a fan of Emacs and use it for personal development applications, > and Clojure and was looking through the Debian list of packages requesting > maintainers. Obviously I've never done something like this before but I > would be happy to come on board and help out in any way possible with the > packaging. Let me know if you still need someone and don't mind me coming > on to help. I'm sorry you never got a reply to this. Debian's bug tracking system does not copy bug submitters on follow-up messages by default. Are you still interested? -- Sean Whitton signature.asc Description: PGP signature
Bug#1003032: debootstrap: harden signature checking
Package: debootstrap Version: 1.0.126+nmu1 Severity: normal Tags: security Hey there. As far as I understood it, debootstrap defaults neither to --no-check-gpg nor to --force-check-gpg, but instead, if a keyring is speicified for some distribution and if that file is available, it uses (and verifies) these (and hopefully fails if anything fails later on). However, it also: - falls back to https (?) - correct me if I'm wrong, falls back to no verification if no key file was specified for the distribution or the file wasn't found That seems to make to too easy to accidentally install untrusted code. https is generally questionable, given the broken CA-model. There are some 150 CAs in the Mozilla CA bundle, and on top of these thousands of intermediate CAs. It seems far too easy for an attacker to fake a certificate if that's really desired. So my suggestion would be: - defaut to --force-check-gpg - add some --check-gpg-but-fallback-to-https option that is the current behaviour - if either the /usr/share/debootstrap/scripts/ for some distro doesn't name a keyring file or that file isn't readable, fail unless --no-check-gpg is given. Yes, that also includes failure if --check-gpg-but-fallback-to-https was given because likely the keyring file should be just there. Cheers, Philippe
Bug#1003031: RFA: projectile
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:projectile I request an adoptor for the projectile package. I haven't used it for some time, as I'm now using the built-in package.el for everything for which I used to use projectile. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. The package is maintained using git-debrebase, using the workflow described in dgit-maint-debrebase(7). That's been working well, so I'd encourage any adopter to continue using the tool. The package description is: This library enhances Emacs with easy project management and navigation. The concept of a project is simple: just a folder containing a special file. Currently git, mercurial, darcs and bazaar repos are considered projects by default. So are lein, maven, sbt, scons, rebar and bundler projects. If you want to mark a folder manually as a project just create an empty .projectile file in it. . Some of Projectile's features: . * jump to a file in project * jump to files at point in project * jump to a directory in project * jump to a file in a directory * jump to a project buffer * jump to a test in project * toggle between files with same names but different extensions (e.g. `.h` <-> `.c/.cpp`, `Gemfile` <-> `Gemfile.lock`) * toggle between code and its test (e.g. `main.service.js` <-> `main.service.spec.js`) * jump to recently visited files in the project * switch between projects you have worked on * kill all project buffers * replace in project * multi-occur in project buffers * grep in project * regenerate project etags or gtags * visit project in dired * run make in a project with a single key chord -- Sean Whitton signature.asc Description: PGP signature
Bug#904233: RFA: persp-projectile
control: title -1 O: persp-projectile -- integrate perspective.el with projectile Hello, On Sun 22 Jul 2018 at 01:31PM +08, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adoptor for the persp-projectile package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. > > The package description is: > With this library, Emacs will create a separate perspective for each > Projectile project. > . > See the documentation for elpa-persp and elpa-projectile for more > details. I hereby orphan persp-projectile. -- Sean Whitton signature.asc Description: PGP signature
Bug#952807: RFA: cider
control: retitle -1 O: cider -- Clojure IDE for Emacs Hello, On Sat 29 Feb 2020 at 08:28AM -07, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adoptor for CIDER. > > Updating CIDER to new upstream releases is more work than typical Emacs > addons, because it is tightly coupled to Clojure. The current upstream > release, in particular, requires a lot of work to get the -doc packages > to include the new docs. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. > > The package description is: > CIDER is the Clojure(Script) Interactive Development Environment that Rocks > . > While clojure-mode provides Emacs support for editing Clojure source files, > CIDER's cider-mode provides support for interacting with a running Clojure > process for compilation, debugging, looking up definitions and more. I hereby orphan cider. -- Sean Whitton signature.asc Description: PGP signature
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
thanks, this ought be fixed in an hour or two.
Bug#998485: gjiten: FTBFS: configure.in:8: error: AM_INIT_AUTOMAKE expanded multiple times
Hi Ludovic, are you still maintaining this package, or should it be moved to QA maintainance? The FTBFS is trivial to fix, but there is a point that someone should also upgrade to new upstream code (assuming the new upstream is usable). Thanks Adrian On Fri, Nov 05, 2021 at 11:59:03AM +0900, notebook wrote: > Hi, > > maybe it's a good chance to change to the new updated version of gjiten at > https://github.com/DarkTrick/gjiten > > The new version might also encounter packaging problems, but it uses more > recent technology and updates; It's probably more worthful to spend time > there than in the 10 year old package* > > > Regards > Chris - DarkTrick > > > * Yes, I'm trying to promote my updates here :)
Bug#1002986: libguestfs-tools: Depends on guestfs-tools that is not in the archive
* Laurent Bigonville: > It looks like libguestfs-tools version 1:1.46.2-1 in depending on > guestfs-tools that is not in the archive making the package uninstalable > > guestfs-tools is currently stuck in the new queue Right. Let's just wait. (Or do you know of a way to speed this up?) Cheers, -Hilko
Bug#1001308: license clarification
thank you for your rfp, however there's this: Assets (graphics, levels, etc.) are available under Attribution-NonCommercial-ShareAlike 4.0 International therefore the game may not be sold without permission with these intact.
Bug#1002992: sub...@bugs.debian.org
Made a new upload to mentors after syncing my git tree with salsa. Basically means that the VCS headers which was broken now should be OK --alec
Bug#1002591: misdetects socket activated ssh
On Sun, Jan 02, 2022 at 09:25:49PM +0100, Thomas Liske wrote: > Looks like a systemd/cgroup related change in bullseye, buster seems > not to be affected. That sounds correct, I had attributed this behavior to some ssh updates in the past. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#712979: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"
On Sun, 02 Jan 2022, Bastian Venthur wrote: > On 01.01.22 22:05, Don Armstrong wrote: > > I'm currently working on it, but my available time is so minimal, > > that additional help would be welcome. > > Awesome news! Is there some repository to check out? I'd love to help if I > can. Not publicly yet; I need to get more of the architecture in place before it can be reasonably collaborated on. But I hope to have it in a place that others can collaborate with me in the next 6 months or so. -- Don Armstrong https://www.donarmstrong.com Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_]
Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1
Package: elpa-org Version: 9.5.2+dfsh-1 Followup-For: Bug #1002982 Dear Maintainer, After installation, org-version.el is missing (not auto-generated ?) in /usr/share/emacs/site-lisp/elpa-src/org-9.5.2/ and soft-linked in /usr/share/emacs/site-lisp/elpa/org-9.5.2/ Then the elpa-org 9.5.2 loads the org-version.el from default org 9.3 from emacs 27.1 ( /usr/share/emacs/27.1/lisp/org/org-version.el ) To reproduce the loading of the wrong file: emacs -q then in emacs M-x org-reload give the following message: Successfully reloaded Org Org mode version N/A (N/A !!check installation!! @ /usr/share/emacs/site-lisp/elpa/org-9.5.2/) The full text of the *Messages* buffer at the org-reload execution. Note the directory of the loading of org-version (last previous last loading) Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-comint...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-core...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-emacs-lisp...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-eval...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-exp...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-lob...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-ref...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-table...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-tangle...done Loading /usr/share/emacs/27.1/lisp/obarray...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-compat...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-entities...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-faces...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-footnote...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-keys...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-list...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-macro...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-macs...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-pcomplete...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-src...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-table...done Loading /usr/share/emacs/27.1/lisp/org/org-version.el (source)...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org...done The following features were found in load-path, please check if that’s correct: (obarray org-version) Successfully reloaded Org Org mode version N/A (N/A !!check installation!! @ /usr/share/emacs/site-lisp/elpa/org-9.5.2/) *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 elpa-org depends on: ii dh-elpa-helper 2.0.10 ii elpa-htmlize1.56-1 ii emacsen-common 3.0.4 Versions of packages elpa-org recommends: ii emacs 1:27.1+1-3.1 ii emacs-gtk [emacs] 1:27.1+1-3.1+b1 Versions of packages elpa-org suggests: ii ditaa 0.10+ds1-1.2 ii org-mode-doc 9.4.0-2 ii texinfo6.8-3 ii texlive-fonts-recommended 2021.20211217-1 ii texlive-latex-extra2021.20211217-1 -- debconf-show failed
Bug#1003029: xboxdrv: FTBFS with SCons 4.2.0+
Source: xboxdrv
Version: 0.8.8-2
Severity: important
Tags: patch
Hi,
SCons 4.3.0 was released some time ago. I've packaged it and would
like to upload it in the next day or so. Your package FTBFS with that,
for which a patch is attached to fix it.
Regards,
Laszlo/GCS
Description: SCons 4.2.0 no longer has env.has_key()
Check env as an array.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-01-02
---
--- xboxdrv-0.8.8.orig/SConstruct
+++ xboxdrv-0.8.8/SConstruct
@@ -41,7 +41,7 @@ def build_bin2h(target, source, env):
with open(target[0].get_path(), "w") as fout:
fout.write("// autogenerated by scons Bin2H builder, do not edit by hand!\n\n")
-if env.has_key("BIN2H_NAMESPACE"):
+if "BIN2H_NAMESPACE" in env:
fout.write("namespace %s {\n\n" % env["BIN2H_NAMESPACE"])
# write down data
@@ -67,7 +67,7 @@ def build_bin2h(target, source, env):
for src in source], ",\n"))
fout.write("\n}\n\n")
-if env.has_key("BIN2H_NAMESPACE"):
+if "BIN2H_NAMESPACE" in env:
fout.write("} // namespace %s\n\n" % env["BIN2H_NAMESPACE"])
fout.write("/* EOF */\n")
Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content
Package: roundcube Severity: important Tags: security Control: found -1 1.3.17+dfsg.1-1~deb10u1 Control: found -1 1.4.12+dfsg.1-1~deb11u1 Control: fixed -1 1.5.1+dfsg-1 In a recent post roundcube webmail upstream has announced a fix for a cross-site scripting (XSS) vulnerability via HTML messages with malicious CSS content. Upstream fix for the 1.4 LTS branch: https://github.com/roundcube/roundcubemail/commit/b2400a4b592e3094b6c84e6000d512f99ae0eed8 There was no new 1.3 LTS release but AFAICT 1.3 is affected as well and the same fix applies. -- Guilhem. [0] https://roundcube.net/news/2021/12/30/security-update-1.4.13-released https://roundcube.net/news/2021/12/30/update-1.5.2-released signature.asc Description: PGP signature
Bug#1002998: firejail-profiles: telegram-desktop not working with firejail
Yes, that worked! Thank you! On 02/01/2022 15:48, Reiner Herrmann wrote: Hi, On Sun, Jan 02, 2022 at 02:58:26PM +, piorunz wrote: Before upgrade to Testing, everything was working fine. Something is wrong with firejail profile? I request assistance. Thank you. This sounds similar to this upstream issue: https://github.com/netblue30/firejail/issues/4488 This was fixed by adding "whitelist /usr/share/TelegramDesktop" to the telegram.profile. Can you please check if that also works for you? Thanks. Kind regards, Reiner -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Bug#1003026: linux-image-5.15.0-2-amd64: iwlwifi fails to initialize AX201 due to firmware error
Package: src:linux Version: 5.15.5-2 Severity: important Tags: upstream X-Debbugs-Cc: abhijithosk...@gmail.com On the 5.15 and newer kernels (I have tried 5.16-rc7 from experimental), iwlwifi fails to start up, complaining of a firmware error: 5.10.0 kernel works as expected. However, it loads iwlwifi-QuZ-a0-hr-b0-59.ucode. I attempted to force 5.15 to load the above, but that leads to the same result. Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: enabling device (0100 -> 0102) Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: failed to load iwlwifi-QuZ-a0-hr-b0-66.ucode (-2) Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-66.ucode failed with error -2 Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: failed to load iwlwifi-QuZ-a0-hr-b0-65.ucode (-2) Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-65.ucode failed with error -2 Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: failed to load iwlwifi-QuZ-a0-hr-b0-64.ucode (-2) Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-64.ucode failed with error -2 Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-63.ucode Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: api flags index 2 larger than supported by driver Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37 Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: loaded firmware version 63.c04f3485.0 QuZ-a0-hr-b0-63.ucode op_mode iwlmvm Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) Jan 02 13:04:12 littlebox kernel: iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x354 Jan 02 13:04:12 littlebox kernel: iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100 Jan 02 13:04:12 littlebox kernel: iwlwifi :00:14.3: base HW address: 64:79:f0:c8:dc:5a Jan 02 13:04:12 littlebox kernel: iwlwifi :00:14.3 wlo1: renamed from wlan0 ... Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: Microcode SW error detected. Restarting 0x0. Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: Start IWL Error Log Dump: Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: Transport status: 0x004B, valid: 6 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: Loaded firmware version: 63.c04f3485.0 QuZ-a0-hr-b0-63.ucode Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0071 | NMI_INTERRUPT_UMAC_FATAL Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x22F0 | trm_hw_status0 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | trm_hw_status1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004CAD42 | branchlink2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004C2DBC | interruptlink1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004C2DBC | interruptlink2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004C2F1C | data1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x1000 | data2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | data3 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | beacon time Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x00025B0E | tsf low Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | tsf hi Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | time gp1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0002B8A5 | time gp2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0001 | uCode revision type Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x003F | uCode version major Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0xC04F3485 | uCode version minor Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0351 | hw version Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x18C89004 | board version Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x8037FD22 | hcmd Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0002 | isr0 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | isr1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x08F04002 | isr2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x00C37FCC | isr3 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | isr4 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | last cmd Id Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004C2F1C | wait_event Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | l2p_control Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | l2p_duration Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x |
Bug#1003025: gr-iio prevents import of python3-libiio
Package: gr-iio Version: 0.3-9+b4 Severity: normal Dear Maintainer, The gr-iio package installs /usr/lib/python3/dist-packages/iio/__init__.py. As a result when any application evaluates import iio The above listed file is evaluated. However this is usually not what is intended. Instead most applications expect to evaluate the file /usr/lib/python3/dist-packages/iio.py installed by python3-libiio -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/6 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gr-iio depends on: ii libc6 2.31-13+deb11u2 ii libgcc-s1 10.2.1-6 ii libgnuradio-iio1 0.3-9+b4 ii libgnuradio-pmt3.8.2 3.8.2.0-14 ii libgnuradio-runtime3.8.2 3.8.2.0-14 ii liblog4cpp5v5 1.1.3-3 ii libpython3.9 3.9.2-1 ii libstdc++610.2.1-6 ii python3 3.9.2-3 gr-iio recommends no packages. gr-iio suggests no packages. -- no debconf information
Bug#1003024: ITP: libimage-scale-perl -- fast, high-quality fixed-point image resizing
Package: wnpp Severity: wishlist Owner: Paul Gevers X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libimage-scale-perl Version : 0.14 Upstream Author : Andy Grundman * URL : https://metacpan.org/release/Image-Scale * License : GPL2+ Programming Lang: Perl Description : fast, high-quality fixed-point image resizing Image::Scale implements several resizing algorithms with a focus on low overhead, speed and minimal features. Algorithms available are: GD's copyResampled (floating-point) GD's copyResampled fixed-point (useful on embedded devices/NAS devices) GraphicsMagick's assortment of resize filters (floating-point) GraphicsMagick's Triangle filter in fixed-point Supported image formats include JPEG, GIF, PNG, and BMP for input, and JPEG and PNG for output. This module came about because the need to improve the very slow performance of floating-point resizing algorithms on platforms without a floating-point unit, such as ARM devices like the SheevaPlug, and the Sparc-based ReadyNAS Duo. Previously it would take many seconds to resize using GD on the ReadyNAS but the conversion to fixed-point with a little assembly code brings this down to the range of well under 1 second. I intent to maintain this package under the Perl Team umbrella. This package is a dependency of Logitech Squeezebox which I also ITP.
Bug#1003023: ITP: python-django-pint -- Django Quantity Field
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-pint Version : 0.6.3 Upstream Author : Ben Harling * URL : https://github.com/CarliJoy/django-pint/ * License : Expat Programming Lang: Python Description : Django Quantity Field A small Django field extension allowing you to store quantities in certain units and perform conversions easily. Uses pint behind the scenes. Also contains a form field class and form widget that allows a user to choose alternative units to input data. The cleaned_data will output the value in the base_units defined for the field, eg: you specify you want to store a value in grams but will allow users to input either grams or ounces. I intend to maintain this as part of the DPT. -BEGIN PGP SIGNATURE- iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHSFtIRHGZsYWRpQGRl Ymlhbi5vcmcACgkQ/9PIi5l90WrHBAf/RmsRWUfCu8mewsdh+Kiep+Bhd/bCFwxr Lygt22KUY/cHlS8/JjB9MPADqck1Uj8PsauU9WZcuZM0gFa+B7gA3fX0RoBWsten 8rm2k8TSo8am2im7yKjLFx+WXRkaNQ88VJXaiCT9hGQf67TOV2RD+6QjsPkGLZ7L BuTblYpF3NY5I1VpfwZYN41GACNEFTjGOg/LN2whnEkAY1udRIAbT+eX43yrvW5+ FKqpU1rZhGH6DlpeXtaluKYSJ/gFJWv3tvdqAxE1FDiDVprBAXPSAGqC0DfgYeUM cP0mUTkOmWf7i8XY3cUR46wndq7T1cmW/nGpQTv2o4fzloJ4fMAvPQ== =QhJl -END PGP SIGNATURE-
Bug#1003022: websocketpp: FTBFS with SCons 4.2.0+
Source: websocketpp
Version: 0.8.2-3
Severity: important
Tags: patch
Hi,
SCons 4.3.0 was released some time ago. I've packaged it and would
like to upload it in the next day or so. Your package FTBFS with that,
for which a patch is attached to fix it.
Regards,
Laszlo/GCS
Description: SCons 4.2.0 no longer has env_cpp11.has_key()
Check env_cpp11 as an array.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-01-02
---
--- websocketpp-0.8.2.orig/examples/broadcast_server/SConscript
+++ websocketpp-0.8.2/examples/broadcast_server/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs]
prgs += env_cpp11.Program('broadcast_server', ["broadcast_server.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/debug_client/SConscript
+++ websocketpp-0.8.2/examples/debug_client/SConscript
@@ -14,7 +14,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs] + [tls_libs]
prgs += env_cpp11.Program('debug_client', ["debug_client.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/debug_server/SConscript
+++ websocketpp-0.8.2/examples/debug_server/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs]
prgs += env_cpp11.Program('debug_server', ["debug_server.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/dev/SConscript
+++ websocketpp-0.8.2/examples/dev/SConscript
@@ -11,7 +11,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
BOOST_LIBS_CPP11 = boostlibs(['unit_test_framework','system','timer','chrono'],env_cpp11) + [platform_libs] + [polyfill_libs]
prgs += env_cpp11.Program('main', ["main.cpp"], LIBS = BOOST_LIBS_CPP11)
--- websocketpp-0.8.2.orig/examples/echo_client/SConscript
+++ websocketpp-0.8.2/examples/echo_client/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs] + ['z']
prgs += env_cpp11.Program('echo_client', ["echo_client.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/echo_server/SConscript
+++ websocketpp-0.8.2/examples/echo_server/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs]
prgs += env_cpp11.Program('echo_server', ["echo_server.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/echo_server_both/SConscript
+++ websocketpp-0.8.2/examples/echo_server_both/SConscript
@@ -14,7 +14,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs] + [tls_libs]
prgs += env_cpp11.Program('echo_server_both', ["echo_server_both.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/echo_server_tls/SConscript
+++ websocketpp-0.8.2/examples/echo_server_tls/SConscript
@@ -14,7 +14,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs] + [tls_libs]
prgs += env_cpp11.Program('echo_server_tls', ["echo_server_tls.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/external_io_service/SConscript
+++ websocketpp-0.8.2/examples/external_io_service/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] +
Bug#1003021: x11-utils: luit - please upgrade
Package: x11-utils Version: 7.7+5 Severity: normal Dear Maintainer, * The version of luit in x11-utils is very old, and its nominal upstream is defunct. https://lists.x.org/archives/xorg-devel/2018-August/057386.html See this for a summary of the relationship of "xorg luit" to luit: https://invisible-island.net/luit/#metrics * Prior discussion with the package maintainers had no effect. * To remedy the situation, I propose to a) modify x11-utils, making its copy of luit configurable via the alternatives feature (renaming it to "luit1", accessed as "luit") b) to provide an up-to-date package for luit as "luit2", also of course configurable via the alternatives feature. c) After some time, the copy in x11-utils can be replaced by a "recommends". Incidentally, doing this would fix #816289 The point of this bug report is to get feedback on "a" (modify x11-utils). -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads) 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages x11-utils depends on: ii libc6 2.33-1 ii libfontconfig1 2.13.1-4.2 ii libfontenc1 1:1.1.4-1 ii libgl1 1.3.4-2+b1 ii libx11-62:1.7.2-2+b1 ii libx11-xcb1 2:1.7.2-2+b1 ii libxaw7 2:1.0.13.1-20191125 ii libxcb-shape0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxext62:1.3.4-1 ii libxft2 2.3.2-2 ii libxi6 2:1.8-1 ii libxinerama12:1.1.4-2 ii libxkbfile1 1:1.1.0-1 ii libxmu6 2:1.1.2-2+b3 ii libxmuu12:1.1.2-2+b3 ii libxrandr2 2:1.5.2-1 ii libxrender1 1:0.9.10-1 hi libxt6 1:1.2.0-20190617 ii libxtst62:1.2.3-1 ii libxv1 2:1.0.11-1 ii libxxf86dga12:1.1.4-1+b3 ii libxxf86vm1 1:1.1.4-1+b2 x11-utils recommends no packages. Versions of packages x11-utils suggests: ii mesa-utils 8.4.0-1+b2 -- no debconf information
Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)
On Sun, Jan 02, 2022 at 04:31:01PM +0100, Michael Biebl wrote: > On 02.01.22 16:12, Tobias Frost wrote: > > > Filesystem ia an ext4 on a lvm, backed by a raid1. > > Does the file system support xattr and acl? I guess so, but ACLs are nothing I use normally, so I cant tell if I use them correctly... root@thecus:/var/log/journal# touch test.txt root@thecus:/var/log/journal# setfattr -n user.test -v "xattr test string" test.txt root@thecus:/var/log/journal# getfattr test.txt # file: test.txt user.test root@thecus:/var/log/journal# getfacl test.txt # file: test.txt # owner: root # group: systemd-journal user::rw- group::r-x #effective:r-- group:adm:r-x #effective:r-- group:4294967295:r-x#effective:r-- mask::r-- other::r-- Albeith, I cannot set ACLs in /var/log/journal: setfacl --modify="u:unifi:rw" test.txt setfacl: test.txt: Malformed access ACL `user::rw-,user:unifi:rw-,group::r-x,group:adm:r-x,group:4294967295:r-x,mask::rwx,other::r--': Duplicate entries at entry 5 Same command in /var/log works: root@thecus:/var/log# touch test.txt ; setfacl --modify="u:unifi:rw" test.txt root@thecus:/var/log# getfacl test.txt # file: test.txt # owner: root # group: root user::rw- user:unifi:rw- group::r-- mask::rw- other::r-- root@thecus:/var/log# root@thecus:/var/log# ls -lad journal/ drwxr-sr-x+ 3 root systemd-journal 4096 Jan 2 21:33 journal/ root@thecus:/var/log# getfacl journal/ # file: journal/ # owner: root # group: systemd-journal # flags: -s- user::rwx group::r-x group:adm:r-x group:4294967295:r-x mask::r-x other::r-x default:user::rwx default:group::r-x default:group:adm:r-x default:group:4294967295:r-x default:mask::r-x default:other::r-x root@thecus:/var/log# mount | grep journal root@thecus:/var/log#
Bug#1002252: [Pkg-electronics-devel] Bug#1002252: pcb-rnd: FTBFS: dh_auto_test: error: make -j4 test VERBOSE=1 returned exit code 2
severity 1002252 important thanks Lucas Nussbaum writes: > During a rebuild of all packages in sid, your package failed to build > on amd64. It looks like noise from the latest librnd version is causing a pcb-rnd test failure. There is no operational bug in either the library or the application pcb-rnd. Upstream reports this is already fixed in their tree, and will apparently be in the next librnd release due in March. Upstream really hates when I pull patches out of his tree to make off-cycle updates, so unless this actually causes someone an operational problem with the existing binary packages, my intent is to just package the next librnd release as soon as possible. Bdale signature.asc Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, 2 Jan 2022 20:15:01 +0100 Moritz Muehlenhoff wrote: > On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > > How should I handle this? NMU to sid, let people try it out, and > > then deal with buster/bullseye? > > Yeah, let's proceed with unstable first in any case. > > > Upload everything all at once? I'm also > > going to try building for buster, unless the security team doesn't > > think I should bother. > > I saw > https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95 > , but buster now also includes LLVM/clang 11 (it was introduced to > support a more recent Rust toolchain needed for Firefox), so you > might be reduce complexity here further: > https://tracker.debian.org/pkg/llvm-toolchain-11 > > It's in buster-proposed-updates since there hasn't been a point > release since, but for the purposes of buster-security builds, it > doesn't matter (they chroots have been modified to includen > buster-proposed-updates temporarily): Ah, very helpful, thanks! I'll give buster a try (just created the 'v96-buster' branch). Between that and various backports, I think we might be in good shape.
Bug#1002591: misdetects socket activated ssh
Hi Marc, On Sat, 2022-01-01 at 20:55 +0100, Marc Haber wrote: > Sure: > 1 [1/4996]mh@torres:~ $ pgrep ssh > 315675 > 315738 > [2/4997]mh@torres:~ $ sudo cat /proc/315675/cgroup > [sudo] password for mh on torres: > 0::/user.slice/user-1001.slice/session-296.scope > [3/4998]mh@torres:~ $ sudo cat /proc/315738/cgroup > 0::/user.slice/user-1001.slice/session-296.scope > [4/4999]mh@torres:~ $ > thanks! Needrestart should ignore those ssh instances since there is a user slice cgroup. It does not work due to this check[1] in needrestart. [1] https://github.com/liske/needrestart/blob/v3.5/needrestart#L637 Looks like a systemd/cgroup related change in bullseye, buster seems not to be affected. Regards, Thomas > > As a workaround you might blacklist sshd in needrestart but I think > > a > > generic approach handling socket activation services in needrestart > > would be better. Therefore needrestart need a way to detect if the > > process belongs to a socket activated service. > > It is also possible to mask ssh.service entirely in systemd. But of > couse having the heuristic fixed would be better. > > Greetings > Marc >
Bug#908941: unarchiving 908941, reopening 908941
rpyc | 5.0.1-1 | new| source
Bug#1003020: openblas breaks hypre autopkgtest on armhf: test times out after 2:47h
Source: openblas, hypre Control: found -1 openblas/0.3.19+ds-1 Control: found -1 hypre/2.22.1-3 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of openblas the autopkgtest of hypre fails in testing when that autopkgtest is run with the binary packages of openblas from unstable on armhf due to a timeout after 2:47 h. It passes when run with only packages from testing in about 9-12 minutes. In tabular form: passfail openblas from testing0.3.19+ds-1 hypre from testing2.22.1-3 all others from testingfrom testing I copied some of the output at the bottom of this report, but as the test times out, I suspect it just hangs and there's not much useful to see. Currently this regression is blocking the migration of openblas to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=openblas https://ci.debian.net/data/autopkgtest/testing/armhf/h/hypre/17988587/log.gz Building tests for HYPRE rm -f *.o *.obj rm -rf pchdir tca.map *inslog* mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o ij.o ij.c Building ij ... mpicc -o ij ij.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o ij_assembly.o ij_assembly.c Building ij_assembly ... mpicc -o ij_assembly ij_assembly.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o sstruct.o sstruct.c Building sstruct ... mpicc -o sstruct sstruct.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o struct.o struct.c Building struct ... mpicc -o struct struct.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o ams_driver.o ams_driver.c Building ams_driver ... mpicc -o ams_driver ams_driver.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o maxwell_unscaled.o maxwell_unscaled.c Building maxwell_unscaled ... mpicc -o maxwell_unscaled maxwell_unscaled.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o struct_migrate.o struct_migrate.c Building struct_migrate ... mpicc -o struct_migrate struct_migrate.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o sstruct_fac.o sstruct_fac.c Building sstruct_fac ... mpicc -o sstruct_fac sstruct_fac.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o ij_mv.o ij_mv.c Building ij_mv ... mpicc -o ij_mv ij_mv.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include
Bug#1003017: dulwich: autopkgtest regression: src/debian/tests/testsuite3: 10: -m: not found
Source: dulwich Version: 0.20.26-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of dulwich the autopkgtest of dulwich fails in testing when that autopkgtest is run with the binary packages of dulwich from unstable. It passes when run with only packages from testing. In tabular form: passfail dulwichfrom testing0.20.26-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=dulwich https://ci.debian.net/data/autopkgtest/testing/amd64/d/dulwich/17999494/log.gz = Running tests with python3.9 == /tmp/autopkgtest-lxc.n4tqfogv/downtmp/build.r97/src/debian/tests/testsuite3: 10: -m: not found autopkgtest [23:08:36]: test testsuite3 OpenPGP_signature Description: OpenPGP digital signature
Bug#1003016: node-chart.js breaks cacti autopkgtest: did Chart.js just got renamed to chart.js?
Source: node-chart.js Control: found -1 node-chart.js/3.7.0+~0.1.9-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Control: affects -1 cacti python3-ontospy [X-Debbugs-CC: debian...@lists.debian.org python3-onto...@packages.debian.org] Dear maintainer(s), [I'm also the maintainer of the cacti package in Debian] With a recent upload of node-chart.js the autopkgtest of cacti fails in testing when that autopkgtest is run with the binary packages of node-chart.js from unstable. It passes when run with only packages from testing. In tabular form: passfail node-chart.js from testing3.7.0+~0.1.9-1 cacti from testing1.2.19+ds1-2 all others from testingfrom testing I copied some of the output at the bottom of this report. The cacti autopkgtest is a simple recursive web crawl of the web app. The test fails because it can't find Chart.js while it expect it to be there. Chart.js used to be linked in from libjs-chart.js. There is a chart.js in the new version, is that just the renamed version of Chart.js? If that's the case, can a symlink be provided to enable reverse dependencies to just keep on working? (Same for other files that got renamed) Currently this regression is blocking the migration of node-chart.js to testing [1]. Can you please investigate the situation? If you think that reverse Depends should just move on, please clone and reassign the bug to all reverse dependencies that use Chart.js (or other files that got renamed/dropped). More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=node-chart.js https://ci.debian.net/data/autopkgtest/testing/amd64/c/cacti/17997504/log.gz 2022-01-01 21:11:48 - ERROR PHP WARNING: md5_file(/usr/share/cacti/site/lib/../include/js/Chart.js): failed to open stream: No such file or directory in file: /usr/share/cacti/site/lib/functions.php on line: 6072 2022-01-01 21:11:48 - CMDPHP PHP ERROR WARNING Backtrace: (/automation_tree_rules.php[68]:top_header(), /lib/functions.php[4155]:include_once(), /include/top_header.php[34]:html_common_header(), /lib/html.php[2566]:get_md5_include_js(), /lib/functions.php[6089]:get_md5_hash(), /lib/functions.php[6072]:md5_file(), CactiErrorHandler()) OpenPGP_signature Description: OpenPGP digital signature
Bug#1000572: fix
This is now fixed in the master branch https://github.com/faiproject/fai/commit/2726525da7fbcd73ff5e949516890fa80ffb6783 -- viele Grüße Thomas
Bug#959407: Not needed for Debian Python Packages
We now have a more general solution for PEP 517/518 (and PEP 621) based packages in pybuild using a different approach. This package is not needed to support Deiban Python package building. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1003015: Makefile creates a symlink testing/buster -> unstable/sid, while it should be testing/bookworm -> unstable/sid
Package: debian-cd Version: 3.1.35 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The Makefile contains this code: # Make sure unstable/sid points to testing/buster, as there is no build # rule for unstable/sid. unstable-map: $(Q)if [ ! -d $(BASEDIR)/data/sid ] ; then \ ln -s buster $(BASEDIR)/data/sid ; \ fi $(Q)if [ ! -d $(BASEDIR)/tools/boot/sid ] ; then \ ln -s buster $(BASEDIR)/tools/boot/sid ; \ fi This clearly needs to be updated to "bookworm". Regards, Daniel - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: 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 debian-cd depends on: ii apt2.3.13 ii bc 1.07.1-3+b1 ii bzip2 1.0.8-5 ii cpp4:11.2.0-2 ii curl 7.80.0-3 ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg-dev 1.21.1 ii genisoimage9:1.1.11-3.2 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.21.1 ii libfile-slurp-perl .32-1 ii libyaml-libyaml-perl 0.83+ds-1 ii lynx 2.9.0dev.10-1 ii make 4.3-4.1 ii perl [libdigest-sha-perl] 5.32.1-6 ii tofrodos 1.7.13+ds-5 ii wget 1.21.2-2+b1 ii xorriso1.5.4-2 Versions of packages debian-cd recommends: ii dosfstools 4.2-1 ii hfsutils 3.2.6-15 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii mtools 4.0.33-1+really4.0.32-1 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 debian-cd suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmHR/eIACgkQS80FZ8KW 0F13VQ/+LLRXQP6vVxion6boTgg9LEEEnaUPHeprePLNoe5hA0S0wFnIyt3fU/w/ +/QVs4csEpZkLK397gAqR3/au5I/UGzW24lYwMwCtnRdZlwMeYnsRoQx1MPhWerb oX53/kfbesUDT8TOT3TZnNtZg2d2wZlH7+KUA6BrHjlRNFLxYrh7CBYzQ14CxVz0 pCxtyub1RQKUFGhfJ/Sv+C70sStiooECpMoLPmQhvC0XWoZU0E+ZJPkUJTFzeIvJ a3hclib2BNzFTTduPKG8SYgytfTyHKrkZx81J1s9955ZDEMxqoc+QnpuaNFqW2yJ dqyJorijFYki5rnw4p70zzWtX3VDaQkVxtrDPmTmKa9V+HB57/Vw7nk8Jw0KnKxC vdRWYH5WVobeNLdJ5rzgZRhlaeqf99DHFcUhTp7oK9kxheqxlnvKskGdCPvlG+2b ocIx7okMxTWRQYXuzUW0x6U+oQq+2hrTW8Ia9894APNswdsbYw6aNkAydWs2WsOs z/c1wE7M1WdDpYCTGLewIo6kdzaD5NXg4ACwZozJPRjjrdjWvEL/tX7QANbkHxbY G1TRv8I+sWb2uEYRqPEhBX6BA555QJo6srYUuzyYROG/fvOX3moR3AIVY8N+RWiU qKHt63FXf7ClQxY92tq3kpk+jmhIVEaGE2axZ+KBpx0dtcwny9s= =eDGz -END PGP SIGNATURE-
Bug#1003014: make_disc_trees.pl misdetects files missing for debootstrap when a proxy is used to retrieve packages - essentially making the installer ignore packages on the CDROM
Package: debian-cd Version: 3.1.35 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I was recently building custom images using simple-cdd, and for some reason the installer was completely ignoring the packages shipped with the media. With some digging I found the installer reporting: cdrom-detect: Base system not installable from CD, requesting choose-mirror With some more digging I found that make_disc_trees.pl was reporting: 5 files missing for debootstrap, not creating base_installable But the relevant make_disc_tree.log file only contained this at the end: Missing debootstrap-required I: Missing debootstrap-required Using Missing debootstrap-required auto-detected Missing debootstrap-required proxy: Missing debootstrap-required http://127.0.0.1:8000/ So actually there were no packages missing. Disabling the proxy then "fixed" the issue. There were no more complaints by make_disc_trees.pl, and the installer was using all the package put on the CD. So we somehow need to ignore messages like the above, which do not indicate packages missing. Regards, Daniel - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: 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 debian-cd depends on: ii apt2.3.13 ii bc 1.07.1-3+b1 ii bzip2 1.0.8-5 ii cpp4:11.2.0-2 ii curl 7.80.0-3 ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg-dev 1.21.1 ii genisoimage9:1.1.11-3.2 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.21.1 ii libfile-slurp-perl .32-1 ii libyaml-libyaml-perl 0.83+ds-1 ii lynx 2.9.0dev.10-1 ii make 4.3-4.1 ii perl [libdigest-sha-perl] 5.32.1-6 ii tofrodos 1.7.13+ds-5 ii wget 1.21.2-2+b1 ii xorriso1.5.4-2 Versions of packages debian-cd recommends: ii dosfstools 4.2-1 ii hfsutils 3.2.6-15 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii mtools 4.0.33-1+really4.0.32-1 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 debian-cd suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmHR/WUACgkQS80FZ8KW 0F3rbBAAzjD2Il4Oqjxj69IBaJe5luKnFOX8L66WEY6yG05MKGzJfICWKuuATHyy B4wVFRhslM+4LvxcIqsY+V5ruFKssy1QxHRxRC6tQZ2gpwlGn5UzaA7chrPJ/Mgc mEY3zgsiw7HiK0Vf4zBmT21G3op1jzTpoEiey8IPbIhA8KVv3b8agkt/aqTyIUna GlEoxnAqRvcRgtcM0Xkk1JhriPlU6IKSBsvr+0vmMoXzDYC0Yss2WtRP/R8zrmU/ 3ae2yQSXNq8knclIftQQunufDounOgjyTr8WPk2iFVkb9HtEAi/EGbnkiR4i7ssm EXOHh6lyw4SKlEC0Fz3jrvqBoESaDALUFus3vIpwvHZ9oEg9rY9sxU5JYIpgVM6g lVrochACh0gifIiM8fL30FEYhkT1AtYh3AHH59SrzSS5rmUjyE/0GdZKRAwDFRvN RbbcqArFuR3hQmC08GuMrktAQNciwtDpiMhY/IZEvv3uV7R9pKbO+Xw4g8QIGS8+ XutWfsIlJWojm1p2msAZZ39kvz7+6PjNaxhc+mxcd84fYADEOeXifsdIpJUs3aFT yzRToheDrjFoB4ZP79atvE+WJ/e8CZJoKqgmvvoR2BjjIS5TYZHng2ugZihhqMks hEAvVDs0AmHPvvJHcrvVIwuhjWQl+B9dxqH0DeGT7ypPfY7M4Jk= =F62J -END PGP SIGNATURE-
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > How should I handle this? NMU to sid, let people try it out, and then > deal with buster/bullseye? Yeah, let's proceed with unstable first in any case. > Upload everything all at once? I'm also > going to try building for buster, unless the security team doesn't > think I should bother. I saw https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95 , but buster now also includes LLVM/clang 11 (it was introduced to support a more recent Rust toolchain needed for Firefox), so you might be reduce complexity here further: https://tracker.debian.org/pkg/llvm-toolchain-11 It's in buster-proposed-updates since there hasn't been a point release since, but for the purposes of buster-security builds, it doesn't matter (they chroots have been modified to includen buster-proposed-updates temporarily): I'd say if it works out without additional overhead, let's also update buster-security, but it's also important not to overstretch the time/resources, so focusing on bullseye and EOLing buster is also an option for sure. Cheers, Moritz
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 17:11 schrieb Karsten: Basically you can install the self-signed certificate (if you or a trusted party signed it, and you have transmitted it over a secure channel, for instance, via SFTP or SCP) into the trust store (assuming it suits both the TLS server and the signing CA roles - which was set when you created it). Just for understanding - the installation is the public certificate of the server, or must be a special file derived from the private certificate? "It depends" - on how you exactly you generated it - even if you only created it with "openssl req -x509 ...", the openssl configuration files matter. Normally, 1. the client's trust store (OpenSSL on the fetchmail computer) needs the CA certificate, i. e. one with the CA flag set to true in the basicConstraints, or basicContraints missing, see the x509(1ssl) manual page under CERTIFICATE EXTENSIONS. 2. Then, the server needs to present a certificate that is suitable as "SSL Server" (extendedKeyUsage = serverAuth) role. See the x509v3_config(5ssl) manual page for details. If your server's certificate does not fulfill both criteria, you better start over and set up a ca (and store its private key password-protected in a safe place, as you seldomly need it), and a separate server cert signed by your own ca. easy-rsa may help with that. Check /usr/share/doc/easy-rsa, easy-rsa has README files, but no manual page. To check: openssl x509 -noout -text -in whatever.crt # or whatever.pem shows you that, here for a CA certificate: X509v3 Basic Constraints: CA:TRUE ... X509v3 Key Usage: Certificate Sign, CRL Sign The TLS server has X509v3 Basic Constraints: CA:FALSE ... X509v3 Extended Key Usage: TLS Web Server Authentication Some of this may not be enforced in currently shipping fetchmail versions, but since a lot of public foot-shooting was involved in third-party documentation that advised trust-on-first-use schemes without warning people of the dangers involved, future versions might actually tighten things even more, so, f.i. validate CA flags of all but the server certificate. I don't currently use Debian or derivatives as so you need to check [update-]ca-certificates documentation and configuration to be sure that your certificate is (a) put in the right place where update-ca-certificate finds it, (b) "enabled" in configuration and processed into the output trust store, and (c) not in a place where it will be removed on system upgrades. dpkg-reconfigure ca-certificates - possibly with some modified priority option - might be required. That stackexchange link in the earlier message hints that there were changes somewhen in the past, and also be sure to re-check documentation since the answer there is older than Debian 11. No, where does that access happen? The trust store is local to your computer and fetchmail might use your system's DNS resolver (which can have privacy implications) and will connect to the servers you point it to. First you send your certificate to the public CA to sign it. Then an client must connect the CA to proove that the public certificate is correct signed. Correct or wrong? If I am my own CA, I am not sending something anywhere. I install the ca certificate on my clients' trust stores, put its (the CA) private keys on a CD or USB key so it's not left on my computer (let alone on my server), and that's it. I've been doing that for more than a dozen years; for public services however Let's Encrypt is a viable alternative.
Bug#1003012: bash: Corrupted multibyte characters in command substitutions
Package: bash Version: 5.1-2+b3 Severity: critical Justification: breaks unrelated software Tags: patch upstream l10n I've reported this bug on bug-bash: https://lists.gnu.org/archive/html/bug-bash/2022-01/msg0.html only to learn that it's known and not fixed for months (it was known before bullseye was released, so a timely fix would have prevented the bug ever reaching stable): https://savannah.gnu.org/patch/?10035 I'm reporting it as critical because it causes silent data corruption and potentially affects each bash script in the system. Since the bash developers don't seem to take that seriously, I'm asking the Debian maintainers to put out a fixed version ASAP to prevent further damage -- hopefully as a security patch. (I'm no expert in writing exploits, but I think it's quite possible such a bug can be exploited. I hope you don't have to wait for an actual exploit in order to fix the bug.) Both reports listed above contain a patch. They're different, but either one will fix the immediate problem. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages bash depends on: ii base-files 11.1+deb11u2 ii debianutils 4.11.2 ii libc62.31-13+deb11u2 ii libtinfo66.2+20201114-2 Versions of packages bash recommends: ii bash-completion 1:2.11-2 Versions of packages bash suggests: pn bash-doc -- no debconf information
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On 1/2/22 12:53 PM, Mattia Rizzolo wrote: On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: I've got 96.0.4664.110 building on both bullseye and sid Trying it, I see it still build-depends on python-jinja2. That package is now gone, so it's not actually buildable in sid anymore. Correlated, do you know how long do they plan on keeping using python2? That's plainly unsuitable, it really is not going to last much longer in debian. Sorry, I hadn't pushed the commits yet. I just did, but like I said I still need to clean 'em up.
Bug#1003011: xkb-data: character infinity bepo AFNOR variant
Package: xkb-data Version: 2.29-2 Severity: minor Dear Maintainer, the code for the character "∞" for the "French (Bepo, ergonomic, Dvorak way, AFNOR)" (line 630 in the file /usr/share/X11/xkb/symbols/fr) seems wrong. Should be U221E, not UFDD7. Regards. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1003010: fonts-liberation2: please Provides fonts-liberation
Package: fonts-liberation2 Version: 2.1.5-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It would be desirable for fonts-liberation2 to Provides fonts-liberation so as to avoid installing two versions of essentially the same font. - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /bin/dash Init: unable to detect -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmHR8oMACgkQrh+Cd8S0 17Z7+RAAp5YKO9j36vycnMIvKSJP16hMis0Ua8kRKPbQD5yxHZ2esxA924Po5Owr DJPfBbHwiMBnZb4FQjDaHYBg+U7HN2ZWZuDJLFPszQr8p9eR+8GA3Wo2WxDTP9Es YsYia92X2Ay+T4Dq+OhEIQLdL7Dd72s8+BFpDqDWaZ+EAPNgsXFQneKpdCNS3y5w edw8ToH8xaDUnYILjBN7sD1f80RnA2oa6PbauVU+3CS41lsQ4vDZbFyR7Nedtl6n +C+HLmxwDHjd2SrvjCjBKkY7IZWMIzvt0fJb7LAoQ39w7+kqeCeTcbb28T+wjyFB hgPk30LStOgYCB9dQfhajrwt/rL+4/6ICy82BD7TRMOAhyiO8Z9zNViv151aPuMT 6BWSZAM1bjWBdAxDqWgaif9ByZnm7ba/n4NGTOyeQ2MX43HIn21DR1lNypLKsB6J t1q21TdeZNSmVJR02EtUZ6MhgXtCMJZoubb1uMkpQkeNuBv828mI0iqkCwMAnjfx Z2yYXDcaL7swtgBifGMtx4gtLJO54bFZ/7391f/AX7V1F07zFy0yiM1P7FY5jAkB xQ+wHVqGRIeSe0g9j40vQMH9u2T7GkgMCZDcraAiPTREZxUMpSc34o+DgnqOhAfZ 6U9cUH7iMvUfVyID/X3FQASnwjXrV2ALRRG+3tZmuIaTU4GnXKo= =k7Xm -END PGP SIGNATURE-
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
Source: notcurses
Version: 3.0.3+dfsg.1-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/logs.php?pkg=notcurses=3.0.3%2Bdfsg.1-1
...
dh_missing -a -O--buildsystem=cmake
dh_missing: warning: usr/lib/x86_64-linux-gnu/libnotcurses-ffi.so exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/libnotcurses-ffi.so.3 exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/libnotcurses-ffi.so.3.0.3 exists
in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/pkgconfig/notcurses-ffi.pc exists
in debian/tmp but is not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with
files per package)
* dh_install: libnotcurses++-dev (6), libnotcurses++3 (2),
libnotcurses-core-dev (45), libnotcurses-core3 (4), libnotcurses-dev (5),
libnotcurses3 (2), notcurses-bin (18), notcurses-data (10), python3-notcurses
(0)
* dh_installdocs: libnotcurses++-dev (0), libnotcurses++3 (0),
libnotcurses-core-dev (0), libnotcurses-core3 (0), libnotcurses-dev (0),
libnotcurses3 (0), notcurses-bin (0), notcurses-data (0), python3-notcurses (0)
* dh_installman: libnotcurses++-dev (0), libnotcurses++3 (0),
libnotcurses-core-dev (0), libnotcurses-core3 (0), libnotcurses-dev (0),
libnotcurses3 (0), notcurses-bin (0), notcurses-data (0), python3-notcurses (0)
If the missing files are installed by another tool, please file a bug
against it.
When filing the report, if the tool is not part of debhelper itself,
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide
for debhelper (10.6.3+).
(in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary
when only a subset is built
If the omission is intentional or no other helper can take care of this
consider adding the
paths to debian/not-installed.
Remember to be careful with paths containing "x86_64-linux-gnu", where
you might need to
use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in
debian/not-installed
to ensure it works on all architectures (see #961104).
make: *** [debian/rules:14: binary-arch] Error 25
Bug#1003008: Error 134633601: Error while parsing number"
Package: grub-legacy Version: 0.97-79 Severity: Normal After upgrade grub-legacy from 0.97-78 to 0.97-79 installation fails with message "Error 134633601: Error while parsing number": - grub> root (hd0,0) root (hd0,0) Filesystem type is ext2fs, partition type 0x8065e03 grub> setup (hd0) setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd-141250989)"... failed (this is not fatal) Running "embed /grub/e2fs_stage1_5 (hd-141250989,-"... failed (this is not fatal) Running "install /grub/stage1 (hd-141250989) /grub/stage2 p /grub/menu.lst "... failed Error 134633601: Error while parsing number - Observed on all updated hosts (about ten in my own). Rollback to 0.97-78 resolves the problem (with the same config files). Package versions: ii grub-legacy0.97-79 amd64GRand Unified Bootloader (Legacy version) ii grub-common2.04-20 amd64GRand Unified Bootloader (common files) ii libc6-i386 2.33-1 amd64GNU C Library: 32-bit shared libraries for AMD64 Debian version: Debian GNU/Linux bookworm/sid (64bit) -- Eugene Berdnikov
Bug#1003007: libvirt-php FTBFS with PHP 8.1
Source: libvirt-php Version: 0.5.5-3 Severity: serious Tags: ftbfs bookworm sid https://buildd.debian.org/status/fetch.php?pkg=libvirt-php=amd64=0.5.5-3%2Bb1=1641147267=0 ... In file included from ../../src/libvirt-php.c:19: ../../src/libvirt-php.h:161:26: error: expected ‘;’, ‘,’ or ‘)’ before ‘TSRMLS_DC’ 161 | void set_error(char *msg TSRMLS_DC); | ^ ../../src/libvirt-php.h:162:35: error: expected ‘;’, ‘,’ or ‘)’ before ‘TSRMLS_DC’ 162 | void set_error_if_unset(char *msg TSRMLS_DC); | ^ ../../src/libvirt-php.h:163:1: warning: parameter names (without types) in function declaration 163 | void reset_error(TSRMLS_D); | ^~~~ ...
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 02, 2022 at 06:53:51PM +0100, Mattia Rizzolo wrote: > Correlated, do you know how long do they plan on keeping using python2? > That's plainly unsuitable, it really is not going to last much longer in > debian. Current state of the Python 3 upstream migration can be found here: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/python3_migration.md So it sounds like it's almost ready except tests. But the migration doesn't seem like a top priority either, https://bugs.chromium.org/p/chromium/issues/detail?id=941669 dates back to March 2019... Cheers, Moritz
Bug#992649: run-parts in /usr/bin breaks systemd-cron
Hi, I found this bug by luck. I miss the context (why ? UsrMerge ?) I can build systemd-cron like this during the transition: ./configure --runparts="/usr/bin/env run-parts" Greetings, Alexandre Detiste
Bug#1003006: graphviz: please migrate Recommends fonts-liberation to fonts-liberation2
Package: graphviz Version: 2.42.2-5 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please migrate the Recommends on fonts-liberation to fonts-liberation2. Thanks! - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages graphviz depends on: ii libc6 2.33-1 pn libcdt5 pn libcgraph6 ii libexpat1 2.4.2-1 ii libgd3 2.3.0-2 ii libglib2.0-0 2.70.2-1 pn libgts-0.7-5 pn libgvc6 pn libgvpr2 pn liblab-gamut1 ii libx11-6 2:1.7.2-2+b1 pn libxaw7 pn libxmu6 pn libxt6 Versions of packages graphviz recommends: pn fonts-liberation Versions of packages graphviz suggests: pn graphviz-doc pn gsfonts -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmHR6LsACgkQrh+Cd8S0 17bY7BAAhD+QAUuA4J+RbMonwWzR7srTapAgZlLz0YMqTevLE8cXuW+aKJPXVsj7 nCz1CVzCwjt77tuvalN2ZZjSDfs081+fQ82bq4oS5aQC3rfviy38r+/J8ljYBzoS e5ZtlMv11UCrSBy1A/71w4jFA+LVi8sTuxQ7yYX0uhNtxIca9vnnsQ5RyQkjXeZj 5chXAuMe9VsqmGOPF/8K1+HKnRQN7hfNizRGWN2KcqAO7PD/M+dp5mHymV+3f5oK mSuJAXz85/OPEL6zB502TSCe2GpBapSMCAMbJj+aCtbWTKc0FZ3080NywMaFjQQq rp5bILv/2ePitPnS4YsVmS2eo4a+m+P2TXB/YpFppw4YXf62ojyM/FwTWDcZo6fC 1z/7GPJ3J31SNDFuqV5gBLbV7IBmw4vCrCQNysMe4jlKCrZcj5AU4MXDnrKngkwk 1qjRrNdsGrX8YJmjxemR6XyWnwf67UGGYevdf5AR4bC4lG6oUSG2e+ZIVEKPxqFG vrfUrk+nUa0iHRYEnxiVzWfc/QkAPPlHnbZuK4XK0T2QDGyDAVDiO/Lx6LlNuXFP RxgJ8W4W5ERjPoikYOwERclfChuvtKUU3TzKQ6vlv/iSCazHrbpSpreO0JezwrkM VEiTyuR3voUPTrMSlI5vOwGAubGc+8/yfuXAcVBqjmx7lTLEfW8= =exER -END PGP SIGNATURE-
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > > I've got 96.0.4664.110 building on both bullseye and sid Trying it, I see it still build-depends on python-jinja2. That package is now gone, so it's not actually buildable in sid anymore. Correlated, do you know how long do they plan on keeping using python2? That's plainly unsuitable, it really is not going to last much longer in debian. > > the v96 branch of https://salsa.debian.org/dilinger/chromium FWIW, I'm trying to build it myself as well (after injecting an old python-jinja2 and an old python-markupsafe). > Alright, crashes are solved and the packages are now usable. After some > cleanups (listing CVEs in changelogs, This doesn't seem to be done as of the current tip of you v96 branch. > merging/pushing a bunch of > commits in my branch, possibly dropping strong stack protection from > builds to silence warnings from older clang versions, and going through > lintian errors/warnings), it should be ready to upload. TBH, I don't think I am able to judge the appropriateness of most of those changes... Though I suspect I could close most of my eyes and upload it to unstable: can't be much worse than what we have... > How should I handle this? NMU to sid, let people try it out, and then > deal with buster/bullseye? Upload everything all at once? Procedure would be NMU to unstable first, IMHO. > I also haven't heard from anyone on the chromium team yet - should I > add myself as an uploader and do a normal (non-NMU) upload? Do any of > them care? Without hearing from them, adding yourself to Uploaders would be inappropriate. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#916749: systemd-cron: Tries to launch unreachable commands
control: reassign -1 dma Hi, This looks more like normal behaviour. tchet@brix ~ $ [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1 tchet@brix ~ $ echo $? 1 The crontab should maybe have been written this way, to always return "true". [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1 || true I'm assigningg the bug to "dma". dma maintainers can close it if they feel so. Greetings, Package: systemd-cron Version: 1.5.14-2 Severity: important Dear Maintainer, I just switched from cron to systemd cron. I now have every 5 mintes following email : * cron-dma-root-0.service - [Cron] "*/5 * * * * root [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1" Loaded: loaded (/etc/cron.d/dma; generated) Active: failed (Result: exit-code) since Tue 2018-12-18 09:10:03 CET; 74ms ago Docs: man:systemd-crontab-generator(8) Process: 8569 ExecStart=/bin/sh /run/systemd/generator/cron-dma-root-0.sh (code=exited, status=1/FAILURE) Main PID: 8569 (code=exited, status=1/FAILURE) Dec 18 09:10:03 ot-fixe-008 systemd[1]: Starting [Cron] "*/5 * * * * root [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1"... Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Main process exited, code=exited, status=1/FAILURE Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Failed with result 'exit-code'. Dec 18 09:10:03 ot-fixe-008 systemd[1]: Failed to start [Cron] "*/5 * * * * root [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1". Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Triggering OnFailure= dependencies. /usr/sbin/dma does not exist, thus the action should not be executed.
Bug#1002738: Info received (Bug#1002738: redis-server: Default systemd unit file system protection settings prevent writing of logfiles, crashing redis)
Hi Johannes, > TLDR, if you want, feel free to close this ticket, I'll reopen it if > something changes downstream. Thanks for your mail. I'm happy to keep this bug open in case something comes up, but I'm not sure what I would do if we could definitively demonstrate a bug in Redis' unit file. That is to say, the only solution (whatever the cause might turn out to be) would seem to be to remove all of the hardening features from the unit file... hardly the right solution here. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#715900: Bug fixed!
在 2022/1/2 16:21, Hu Zheng 写道: See: https://gitee.com/huzheng/stardict-3.0.7/commit/d9d480bdae9c6a95df1662f4a4a34d9de57d78f4 The bug still partly exist: atzlinux@debian:/tmp/ec50-report/crash$ /usr/lib/stardict-tools/fest2dict asdfasd Segmentation fault atzlinux@debian:/tmp/ec50-report/crash$ echo $? 139 This is fixed: atzlinux@debian:/tmp/ec50-report/crash$ echo asdasdf > /tmp/a atzlinux@debian:/tmp/ec50-report/crash$ /usr/lib/stardict-tools/fest2dict /tmp/a atzlinux@debian:/tmp/ec50-report/crash$ echo $? 0 also see: https://gitee.com/huzheng/stardict-3.0.7/commit/d9d480bdae9c6a95df1662f4a4a34d9de57d78f4#note_8137981 OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1003005: elkcode FTBFS with libxc 5.1.7
Source: elkcode Version: 6.3.2-2 Severity: serious Tags: ftbfs bookworm sid Control: close -1 7.2.42-1 https://buildd.debian.org/status/package.php?p=elkcode=sid ... mpif90 `dpkg-buildflags --get FFLAGS` `dpkg-buildflags --get CPPFLAGS` -Wall -ffast-math -funroll-loops -fopenmp -fallow-argument-mismatch `dpkg-buildflags --get LDFLAGS` -o elk modmain.o modmpi.o libxc_funcs.o libxc.o libxcifc.o modxcifc.o modfxcifc.o moddftu.o modrdm.o modphonon.o modscdft.o modtest.o modrandom.o modstore.o modpw.o modvars.o modtddft.o modgw.o modulr.o modjx.o modomp.o mkl_stub.o mkl_init.o oblas_stub.o oblas_init.o blis_stub.o blis_init.o w90_stub.o modw90.o zfftifc_fftw.o elk.o zbsht.o zfsht.o rbsht.o rfsht.o projsbf.o fsmooth.o nfftifc.o rfinp.o splint.o spline.o wsplint.o wsplintp.o splintwp.o sphcover.o r3frac.o genvsig.o gencfun.o zfpack.o addlorbcnd.o rfint.o sortidx.o gengkvec.o pade.o pades.o rfint0.o zfinp.o symrvf.o genapwfr.o rfcopy.o rhomagsh.o genylmg.o olpaa.o readfermi.o factr.o writechg.o zflmconj.o rminv.o zminv.o rlmrot.o rotrflm.o ztorflm.o rotzflm.o rfmtlm.o genzrm.o gensfacgp.o zmctmu.o zmctm.o hmlfv.o olpfv.o axangsu2.o checkmt.o symrf.o z2mm.o z2mctm.o z2mmct.o writefermi.o findnjcmax.o findscq.o plot1d.o plot2d.o plot3d.o hmllolo.o olprad.o occupy.o findkpt.o zfmtint.o rotrfmt.o forcek.o eveqnfvr.o findsym.o genvbmatk.o wigner3jf.o wigner6j.o mixbroyden.o zftrf.o gensocfr.o getcfgq.o wigner3j.o moke.o sfacinit.o sfacrho.o sfacmag.o gradwfcr2.o symrvfmt.o oepmain.o oepresk.o oepvcl.o oepvclk.o dbxcplot.o writehmlbse.o hmldbse.o hmldbsek.o dielectric_bse.o genidxbse.o writeevbse.o genwfpw.o writewfpw.o getwfpw.o genexpmat.o elnes.o potefield.o eulerrot.o fermisurfbxsf.o symmetry.o findsymcrys.o findsymsite.o plotpt1d.o writedos.o findprimcell.o proj2d.o nonlinopt.o vecplot.o wfcrplot.o energykncr.o eveqnss.o gendmatk.o gensdmat.o ggamt_1.o ggair_1.o ggamt_sp_1.o ggair_sp_1.o ggamt_2a.o ggair_2a.o ggamt_2b.o ggair_2b.o ggamt_sp_2a.o ggair_sp_2a.o ggamt_sp_2b.o ggair_sp_2b.o genspecies.o writeemd.o writeexpmat.o rotdmat.o hrmdmat.o reademd.o emdplot.o rfhkintp.o emdplot3d.o emdplot2d.o emdplot1d.o plotpt3d.o plotpt2d.o writeevsp.o torque.o ssfsmjx.o wxcplot.o effmass.o genlmirep.o ssfext.o sstask.o spiralsc.o genscss.o genfspecies.o writespecies.o exxengy.o exxengyk.o xc_c_tb09.o elfplot.o potplot.o mae.o writestate.o readstate.o rotaxang.o axangrot.o dmatls.o gendmat.o numlist.o sbesseldm.o genvchi0.o genspchi0.o vclcore.o hmlxbse.o hmlxbsek.o genvmatk.o writeepsinv.o putepsinv.o curden.o curdenk.o hflocal.o dielectric.o bdipole.o roteuler.o lopzflm.o eveqnfvz.o rhomag.o hmlaa.o hmlalo.o gencore.o gentau.o gentauk.o hmlistl.o olpistl.o gengclg.o hmlrad.o rhonorm.o rfmtsm.o olplolo.o genshtmat.o allatoms.o rtozflm.o rtozfmt.o gauntyry.o fderiv.o moment.o sctovec.o match.o writeinfo.o rfpack.o gaunt.o readinput.o ztorfmt.o putevecfv.o zfmtinp.o zfcmtinp.o writelinen.o writekpts.o rfmtinp.o brzint.o rhocore.o writelat.o mtdmin.o atpstep.o potcoul.o zfmtconj.o symrfmt.o putpmat.o eveqnz.o olpalo.o checkfsm.o rhoplot.o potnucl.o potxc.o erf.o gradzf.o writegeom.o linengy.o bandstr.o gengvc.o gengclq.o closefiles.o writefsm.o eveqn.o rhomagk.o factnm.o atom.o radnucl.o charge.o genrmesh.o genapwlofr.o wavefmt.o genzrho.o potks.o sbessel.o clebgor.o hermite.o findband.o genbs.o gencfrc.o genws.o chargemt.o gndstate.o addbfsm.o initoep.o orthevsv.o fermisurf.o findswidth.o gradrf.o dos.o gradzfmt.o nuclei.o writesym.o zftzf.o polynm.o rdirac.o zfmtftoc.o rfmtftoc.o gradrfmt.o genzvclmt.o getevalfv.o mixlinear.o gengvec.o putevalfv.o rfmtpack.o zfmtpack.o writestrain.o writeforces.o r3mv.o r3mtv.o r3cross.o r3minv.o r3mdet.o r3mm.o r3mtm.o r3mmt.o r3vo.o symvec.o curdenplot.o hartfock.o eveqnhf.o zpotclmt.o genlofr.o rfinpc.o eveqnit.o genzfrm.o gengqrf.o writepmat.o genwfsv.o writelsj.o writesf.o rzfinp.o genjlgprmt.o gridsize.o sphcrd.o writeiad.o readspecies.o i3mtv.o writeeval.o i3minv.o i3mdet.o genevfsv.o getpmat.o timesec.o mixpack.o mixerifc.o symmat.o rhoinit.o maginit.o rvfcross.o eveqnfv.o energynn.o rfinterp.o rfplot.o geomopt.o ylmroty.o ylmrot.o gcd.o sdelta.o stheta.o sdelta_mp.o stheta_mp.o sdelta_fd.o stheta_fd.o sdelta_sq.o stheta_sq.o sdelta_lr.o stheta_lr.o mossbauer.o gentpmae.o symveca.o massnucl.o wavefcr.o gradwf2.o geomplot.o findngkmax.o reciplat.o genrlmv.o genvmat.o putoccsv.o getoccsv.o curlrvf.o latvstep.o energy.o delevec.o rdiracint.o rzfmtinp.o genstrain.o genstress.o writestress.o rschrodint.o mixadapt.o genffacgp.o genidxlo.o writeengy.o genpmatk.o putevecsv.o getevecsv.o writegclq.o putevalsv.o genppts.o force.o vecfbz.o rfirsm.o gengclgq.o findsymlat.o grad2rfmt.o findqpt.o zftwfir.o symrfir.o symrvfir.o getevalsv.o genjlgpr.o init0.o init1.o init2.o init3.o init4.o genpmat.o putkmat.o getkmat.o genkmat.o genexpmt.o epsinv.o getevecfv.o zfmtctof.o wfplot.o straingkq.o symdmat.o genylmv.o nesting.o eveqnsv.o
Bug#715859: Bug fixed!
Control: tags -1 pending Thanks you for fix this bug in upstream! 在 2022/1/2 16:14, Hu Zheng 写道: See: https://gitee.com/huzheng/stardict-3.0.7/commit/d9d480bdae9c6a95df1662f4a4a34d9de57d78f4 Hu Zheng 13017203...@139.com 电子名片新出VIP模板啦，快来体验>> 扫描二维码添加名片到手机 扫一扫, 快速添加名片到手机 -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》https://www.atzlinux.com 基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x00186602339240CB OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1002975: capnproto: please migrate capnproto 0.8.0 from experimental to unstable -> testing
On Sat, Jan 01, 2022 at 05:12:15PM -0800, tony mancill wrote: Transition request is #1003004. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003004
Bug#1003004: transition: capnproto
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi Release Team, capnproto 0.8.0 has been in experimental for over a year now [1], so there is already an auto-transition page [2]. All of the reverse dependencies *except* for clickhouse should smoothly. clickhouse [3] is FTBFS against 0.8.0, but the package has already been removed from testing due to FTBFS against gcc 11 [4]. Given that clickhouse isn't receiving much attention and we have received requests to update captnproto, we would like to proceed with the transition. Thank you, tony [1] https://tracker.debian.org/pkg/capnproto [2] https://release.debian.org/transitions/html/auto-capnproto.html [3] https://tracker.debian.org/pkg/clickhouse [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996130 Ben file: title = "capnproto"; is_affected = .depends ~ "libcapnp-0.7.0" | .depends ~ "libcapnp-0.8.0"; is_good = .depends ~ "libcapnp-0.8.0"; is_bad = .depends ~ "libcapnp-0.7.0"; signature.asc Description: PGP signature
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 16:07 schrieb Matthias Andree: > Am 02.01.22 um 14:03 schrieb Karsten: >> Am 02.01.22 um 12:15 schrieb Matthias Andree: I am the owner of the domain so nobody is hijacked! >>> Are you the owner of "mydomain.de" or of the unnamed domain you intended >>> not to show to the public? >> Do you want to help with this new certificate issue or discuss the ownership >> of domains? > > In this case, the latter. There are dedicated domain names for everyone > to use for documentation and test purposes, > https://datatracker.ietf.org/doc/html/rfc6761#section-6.5 Aha - O.K. >> With the search "install OpenSSL trust store" i could find this article: >> https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore >> that explains much of the stuff, but not how to use an self-signed >> certificate. > > https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list/ > but check the fine print and lower rated comments, too -- for recent > ca-certificates packages. Thank you - that is very helpful. > Basically you can install the self-signed certificate (if you or a > trusted party signed it, and you have transmitted it over a secure > channel, for instance, via SFTP or SCP) into the trust store (assuming > it suits both the TLS server and the signing CA roles - which was set > when you created it). Just for understanding - the installation is the public certificate of the server, or must be a special file derived from the private certificate? >> >> This worked for more then 5 years with TLS1.2 without any problem. >> Why this must be a problem now? > > Because "working" does not imply "working safely and securely". Yes - but the connection was still encrypted and not plain text. The connection was just not secure against all forms of attacks. >> Take the example Mozilla and please explain why it works without an "OpenSSL >> trust store" ? > > > Mozilla applications ship with their own trust store and do not use > OpenSSL, but incorporate their own TLS library called NSS. O.K. But how this helps to connect to a server with self-signed certificates? >> O.K. Then you have no request to this CA-servers for every connect to a >> server with a certificate, but every private >> server is registered there and every client will request the "trust" once to >> access the server. >> So you can made a profil who is using a server. That's the simple goal of it. > > > No, where does that access happen? The trust store is local to your > computer and fetchmail might use your system's DNS resolver (which can > have privacy implications) and will connect to the servers you point it to. First you send your certificate to the public CA to sign it. Then an client must connect the CA to proove that the public certificate is correct signed. Correct or wrong? > It uses OpenSSL's unless you override that (see man fetchmail for > --ssl... options). I promise to take the time to learn this part about using OpenSSL. > I understand, but too many variables involved and neither of us has time > for guesswork. I don't know how your CA (even if only implied for that > certificate) is set up or whatever else is needed, and I don't intend to > do consulting. I only used this silly OpenSSL command to generate the self-signed certificate and filled the questions OpenSSL asked. It should not be much more complicate to use a local trust store. > Figuratively speaking, you need to learn how to fish, not be given the fish. Fishing get's more and more complex. But it's true and i must learn it. >> When this is a standard procedure, why it is not possible to find existing >> examples how to handle it? >> Why it is still possible to fetch Data with TLS1.2 from the FTP-Server >> without similar problems? > > fetchmail doesn't do FTP, and FTP is being phased out because it's hard > to get right with its two connections, active/passive mode, > firewalls/NAT/conntrack, TLS being added afterwards and I guess it was > superseded by many other protocols that either tunnel through SSH or use > one TLS connection, for instance, DAV. That's the way i thought it is working. TLS is used to establish a secure encrypted connection and afterwards the rest is tunneled through it? Then it is not crucial how complex the protocol is. when two or more ports are needed then more secure connections must be established. > It is probably not about TLS version numbers anyways, but generally > tightened security. You upgraded the entire client system, and that > brought a lot of changes. > https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 > might also be involved. I have to go through each different service that uses encryption, email, ftp, xmpp, etc. Maybe i will find a general better way to manage the certificates for encryption. Thank you for your invested time! karsten
Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi,
On 02-01-2022 14:29, Abou Al Montacir wrote:
If you check on a porter box for ARM or power PC, you will find only arm
or ppc related ifdefs.
So it works for all architectures, but not multiarch.
Isn't multiarch only properly working on some combinations anyways? E.g.
i386 can be multiarch on an amd64 capable computer. And armhf (and
sometimes armel) can be multiarch on (most) arm64 capable hosts? I
understood not all combinations currently (or ever) make sense.
I just checked the configuration on armhf and there wasn't a path to gcc
in the configuration. Shortly after I realized that's probably because
gcc wasn't installed. So while I checked armel, I installed gcc
alongside and after dpkg-reconfigure I got this on armel:
"""
#ifdef cpuaarch64
-Fl/usr/lib/gcc/arm-linux-gnueabi/11
#endif
"""
The cpuaarch64 bit part doesn't look correct, maybe that's because this
is inside an lxc on an arm64 host, so maybe the detection goes wrong.
And then on armel I got:
#ifdef cpuaarch64
-Fl/usr/lib/gcc/arm-linux-gnueabihf/11
#endif
On arm64
#ifdef cpuaarch64
-Fl/usr/lib/gcc/aarch64-linux-gnu/11
#endif
If we can safely suppose that all Debian architectures are using the
very same GCC version and path, then we can remove the ifdef and have a
generic path that works for mutiarch with a minimal effort.
But shouldn't the path depend on for which architecture your building?
However, it is true that if a new gcc version is installed after FPC
then the logic will fall down.
Can't we use a wildcard for the version number? I mean, after 11 comes
12 and 13 and ...
The wildcards work but only for one directory level. This means
/path/to/* and /path/to/prefix* will work, but not /path/to/*/* or
/path/to/prefix*/*
Ack.
If this is judged OK, I propose to close this ticket
As long as we have a new fpc in every Debian release, we're fine in
Debian, but e.g. Ubuntu users may experience issues when they carry the
same fpc over to a new version of Ubuntu that comes with a new gcc
version. So I don't think it's nice.
If we can add a trigger then we can run dpkg-reconfigure
fp-compiler-${VERSION} and get it updated.
I'm not sure your allowed to run dpkg-reconfigure on a trigger as that
requires admin interaction. That sounds weird. As an admin I wouldn't
expect my configuration to get updated (when installing an "unrelated"
package). And we would want to have a trigger on gcc upgrade? I don't
know how triggers work exactly, but wouldn't gcc need to provide the
trigger then?
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1002376: python-aiosqlite: FTBFS: AttributeError: module 'mistune' has no attribute 'BlockGrammar'
On Sunday, 02 January 2022, 13:15 +0100, Benjamin Hof wrote: > compatible to mistune v2 At the moment this is not the case.
Bug#1003003: libqalculate FTBFS on architectures where char is unsigned
Source: libqalculate Version: 3.22.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=libqalculate ... FAIL: unittest == [32m ./tests/variables.batch - 11 tests passed [0m[32m ./tests/units.batch - 13 tests passed [0m[31m Mismatch detected at line 42 char(0xD8) expected ''Ø'' received '"Ø"' [0mRunning all unit tests Running unit tests from 'variables.batch' Running unit tests from 'units.batch' Running unit tests from 'strings.batch' FAIL unittest (exit status: 1) Testsuite summary for libqalculate 3.22.0 # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See src/test-suite.log make[4]: *** [Makefile:835: test-suite.log] Error 1
Bug#1002404: borgbackup: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13
control: close -1 control: severity -1 normal Hello Lucas, I tried on reproducible builds, and I saw some failures some time ago, but I retried today and everything was good. So I presume something in the build-deps got fixed in the meanwhile? e.g. https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/borgbackup_1.1.17-1.rbuild.log.gz G. On Wed, 22 Dec 2021 08:50:10 +0100 Lucas Nussbaum wrote: > Source: borgbackup > Version: 1.1.17-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20211220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > python3 setup.py build_ext --inplace > > Detected and preferring liblz4 over bundled LZ4 > > Detected and preferring libb2 over bundled BLAKE2 > > Detected and preferring libzstd over bundled ZSTD > > Detected and preferring libxxhash over bundled XXHASH > > running build_ext > > skipping 'src/borg/algorithms/msgpack/_packer.cpp' Cython extension > > (up-to-date) > > skipping 'src/borg/algorithms/msgpack/_unpacker.cpp' Cython extension > > (up-to-date) > > skipping 'src/borg/compress.c' Cython extension (up-to-date) > > skipping 'src/borg/crypto/low_level.c' Cython extension (up-to-date) > > skipping 'src/borg/hashindex.c' Cython extension (up-to-date) > > skipping 'src/borg/item.c' Cython extension (up-to-date) > > skipping 'src/borg/chunker.c' Cython extension (up-to-date) > > skipping 'src/borg/algorithms/checksums.c' Cython extension (up-to-date) > > skipping 'src/borg/platform/posix.c' Cython extension (up-to-date) > > skipping 'src/borg/platform/linux.c' Cython extension (up-to-date) > > skipping 'src/borg/platform/syncfilerange.c' Cython extension (up-to-date) > > building 'borg.algorithms.msgpack._packer' extension > > x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g > > -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat > > -Werror=format-security -g -fwrapv -O2 -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > > -D__LITTLE_ENDIAN__=1 -I/usr/include -I/usr/include -I/usr/include > > -I/usr/include -I/usr/include -I/usr/include -I/usr/include/python3.9 -c > > src/borg/algorithms/msgpack/_packer.cpp -o > > build/temp.linux-x86_64-3.9/src/borg/algorithms/msgpack/_packer.o > > x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g > > -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > > build/temp.linux-x86_64-3.9/src/borg/algorithms/msgpack/_packer.o -o > > /<>/src/borg/algorithms/msgpack/_packer.cpython-39-x86_64-linux-gnu.so > > building 'borg.algorithms.msgpack._unpacker' extension > > x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g > > -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat > > -Werror=format-security -g -fwrapv -O2 -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > > -D__LITTLE_ENDIAN__=1 -I/usr/include -I/usr/include -I/usr/include > > -I/usr/include -I/usr/include -I/usr/include -I/usr/include/python3.9 -c > > src/borg/algorithms/msgpack/_unpacker.cpp -o > > build/temp.linux-x86_64-3.9/src/borg/algorithms/msgpack/_unpacker.o > > x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g > > -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > > build/temp.linux-x86_64-3.9/src/borg/algorithms/msgpack/_unpacker.o -o > > /<>/src/borg/algorithms/msgpack/_unpacker.cpython-39-x86_64-linux-gnu.so > > building 'borg.compress' extension > > x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g > > -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat > > -Werror=format-security -g -fwrapv -O2 -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > > -DBORG_USE_LIBLZ4=YES -DBORG_USE_LIBB2=YES -DBORG_USE_LIBZSTD=YES > > -DBORG_USE_LIBXXHASH=YES -DXXH_PRIVATE_API=YES -I/usr/include > > -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include > > -I/usr/include/python3.9 -c src/borg/compress.c -o > > build/temp.linux-x86_64-3.9/src/borg/compress.o > > x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g > > -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > > build/temp.linux-x86_64-3.9/src/borg/compress.o -llz4 -lzstd -o > >
Bug#998244: lists.debian.org: request for debian-math mailing list
Hi Listmasters, Gentle ping on this? Since it has been a while now, and there are interested people, enabling a list will help us. Could you please consider processing the request whenever you have time? Regards, Nilesh On Tue, 14 Dec 2021 15:43:50 + Tobias Hansen wrote: > Hi Cord, > > I am also in favor of the creation of this list. I think we could then close > down debian-science-sagem...@alioth-lists.debian.net and move these > discussions to debian-math. > > Best, > Tobias > > On Sat, 13 Nov 2021 16:45:48 +0530 "Nilesh Patra" wrote: > > Dear list masters, > > > > Since a few people already responded on this bug, and other folks > > already showed interest in joining the team[1], would you please consider to > > process this mailing list request now? > > > > [1]: https://lists.debian.org/debian-science/2021/10/msg00034.html > > > > Thanks a lot for your work, > > Nilesh > > > > > > signature.asc Description: PGP signature
Bug#1002998: firejail-profiles: telegram-desktop not working with firejail
Hi, On Sun, Jan 02, 2022 at 02:58:26PM +, piorunz wrote: > Before upgrade to Testing, everything was working fine. > Something is wrong with firejail profile? > I request assistance. Thank you. This sounds similar to this upstream issue: https://github.com/netblue30/firejail/issues/4488 This was fixed by adding "whitelist /usr/share/TelegramDesktop" to the telegram.profile. Can you please check if that also works for you? Thanks. Kind regards, Reiner signature.asc Description: PGP signature
Bug#1003002: autopkgtest-virt-qemu: Console setup issue on armhf
Package: autopkgtest Version: 5.19 Severity: normal It looks as if one of the necessary consoles is not set up properly on armhf (it worked fine for me on arm64): $ sudo autopkgtest-build-qemu \ --architecture armhf \ --mirror http://deb.debian.org/debian \ unstable armhf.img ... $ autopkgtest libocas -- qemu \ --dpkg-architecture armhf \ -d --show-boot \ armhf.img produces | host login: autopkgtest-virt-qemu: DBG: expect: found "'login prompt on serial console'" | autopkgtest-virt-qemu: DBG: expect: b'ok' | autopkgtest-virt-qemu: DBG: setup_shell(): no default shell on hvc1 or ttyS1 | qemu-system-arm: terminating on signal 15 from pid 1316826 (/usr/bin/python3) | autopkgtest-virt-qemu: DBG: cleanup... | : failure: The VM does not start a root shell on ttyS1 or hvc1 already. The only other supported login mechanism is through --user and --password on the guest ttyS0 [By the way, libocas is just a tiny library with no dependencies that I tend to use as a smoke test.] Best, Christian
Bug#1002979: FTBFS with camlp5 8.00.02
Dear Stéphane, Many thanks for this report. This link gives more details about this specific problem with the old geneweb 6.08: https://issueexplorer.com/issue/camlp5/camlp5/82 The solution would be to migrate to geneweb 7 (see also bug #986285 about the expected migration to geneweb 7). However, this will require a lot of time to implement & test, since geneweb 7 is very different from geneweb 6. As a result, geneweb might be removed from testing for some weeks or months following the landing of the new ocaml/camlp5 in unstable. With best regards, Guillaume Brochu Le dim. 2 janv. 2022 à 00:12, Stéphane Glondu a écrit : > Source: geneweb > Version: 6.08+git20181019+dfsg-3 > Severity: important > Tags: ftbfs > > Dear Maintainer, > > Your package FTBFS with camlp5 8.00.02 with the following error: > > camlp5r pa_extend.cmo q_MLast.cmo -o pa_macro5.ppo pa_macro5.ml > > File "pa_macro5.ml", line 162, characters 51-52: > > While expanding quotation "patt": > > Parse error: end of input expected after [patt] (in [patt_eoi]) > > This was discovered while preparing the transition to OCaml 4.13.1. > > Packages rebuilt with OCaml 4.13.1 are available at: > > https://ocaml.debian.net/transitions/ocaml-4.13.1/ > > > Cheers, > > -- > Stéphane > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled >
Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)
On 02.01.22 16:12, Tobias Frost wrote: Filesystem ia an ext4 on a lvm, backed by a raid1. Does the file system support xattr and acl? OpenPGP_signature Description: OpenPGP digital signature
Bug#1002961: [Pkg-pascal-devel] Bug#1002961: src:castle-game-engine: fails to migrate to testing for too long: FTBFS on armel
Hi Abou, On 02-01-2022 14:22, Abou Al Montacir wrote: The issue is that there seem to be a bug in the compiler. However, I'm not able to understand what kind of issue and cloud not produce a small code that triggers it. Moreover, it seems that the bug itself is triggered only when running the full battery of tests. Then the failing test starts to fail. If the test is ran alone (after a machine reboot, or after a while) then it will succeed, but it one runs it after running the full test suite then it will fail systematically. No clue how to go forward and no enough information to open an upstream compiler bug. Moreover CGE upstream think we should abandon armel (and other non widely used architectures) as a target for CGE, but I think myself it is a good test for the compiler and tend to think we should keep it. I agree with you. However, as a Release Team member, I also want to prevent packages from being out-of-sync for too long. So, what I suggest in this case is to temporarily disable the test on armel until we have figured out how to fix the situation. That way the package can migrate to testing, without making the situation much worse there. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 15:28 schrieb Matthias Andree: >>> Untrue. Messages were fetched without proper protection from >>> MITM/eavesdropping attacks, unless you were using *other* options to >>> ensure authenticity of the server. Which I doubt, else you would have >>> asked specific questions about fetchmail options. >> That's true - but you change the privacy with an voluntary registration at >> an CA-authority. > > I don't see anyone suggested that, but tell me how... It started with Internet browsers wanting confirmation every time an https certificate is not publicly verifiable. The key point of surveillance is to get people to disclose private communications and servers. For example, with Tor, all traffic goes through only one or a few outbound servers, so it's easy to see who is using such evil technology. Packets can be correlated over the time. >> The people that can make MITM/eavesdropping attacks can fake an CA-authority >> too. > > ...that CA certificate would make it into your trust store. There used > to be ill-advised instructions by fourth parties that gave the wrong > advise to download and storing the server's certificate into the trust > store. If the faked CA authority certificate is not in your trust store, > certificate validation will flag the missing trust anchor or issue > "self-signed certificate" errors. This point is not clear. When you have a copy of the downloaded public certificate you can check against it or not? So when somebody tries to fake the certificate without having the private certificate this should be conspicuous. In this case i understand the sense of this trust store. > > In practice, Linux and BSD distros usually deploy the CAs from Mozilla's > CA Program https://blog.mozilla.org/security/category/ca-program/ and > Mozilla have banned CAs that were abusive. This is definitely a coin with two sides. >> Do you think it is possible to make thousands of MITM/eavesdropping attacks >> parallel for every private server? > > > You can safely bet it happens at scale, and million-fold each and every > day. The question is who will make the faked CA authority trustworthy? When possible you should check the fingerprint of the used certificate. After checking this certificate and connection can be trusted. Right? > Company networks with malware-scanning outside proxies, free WiFi sites, > you name it. > > You don't verify, you don't know. Not for every website of course, but for a private account that is used daily. >> Can you please recommend *other* options to ensure more security with self >> signed certificates? > > See my previous messages, put the CA certificate (not private key) that > signed your server's certificate into the OpenSSL trust store of the > computer running fetchmail, or into a local place that you point > fetchmail to. That won't work without reading documentation on how > certification chains and trust delegation work. In the Debian world, > things revolve around update-ca-certificates from the ca-certificates > package. Is there any documentation for DAU's (dumbest presumed user) out there? With examples how to use it? > That's not what I wrote, but the logic you refer to is why fetchmail 6.4 > - finally - forbids unverified certificates by default. > Meaning: No more connection to sites with incomplete certification > chains or where the certification chain cannot be anchored to a trusted CA. I agree (in the meantime) that this is a useful pedagogical method. :-) >> Why have older fetchmail versions made proper trust verification optional? >> :-) > > 6.3 appeared in 2005, before E. Snowden hat blown the whistle and before > web browsers started to flag sites with unverified certification chains > as insecure - and 6.3.X has kept compatibility and defaults. That was good for users like me. > Before this turns into more gossip, I propose to close the bug report > now. Do that by replying to 1002910-cl...@bugs.debian.org instead of the > 1002910@ address. Yes - this is a feature and not a bug. But it would be still wonderful if the lazy users have a chance to use encryption without studying documentation for weeks. Cheers karsten
Bug#1002999: ftp.debian.org: RM: cairodevice -- ROM: Retired upstream
retitle -1 RM: r-cran-cairodevice -- ROM: Retired upstream thanks Somehow I mess the form up more often than not with the emacs helper debian-bug being a little out of whack. Sorry about that. Dirk On 2 January 2022 at 09:00, Dirk Eddelbuettel wrote: | | Package: ftp.debian.org | Severity: normal | | The cairoDevice package (source cairodevice for us, binary | r-cran-cairodevice) was the first 'Cairo' device for R, it has been replaced | by the actively maintained 'Cairo' package (r-cran-cairo for us). It was now | retired at CRAN. We should remove it too. | | The only reverse depends is a meta package. | | Dirk | | -- | https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)
On Sun, Jan 02, 2022 at 03:24:57PM +0100, Michael Biebl wrote: > > Control: tags -1 + moreinfo unreproducible > > On 02.01.22 14:52, Tobias Frost wrote: > > > Please let me know if there are additional details I could supply. > > > > > Can you provide steps how to reproduce the issue? > More details how the container is constructed, which fs is used etc. might > help as well. When I find a way to reproduce, I'll let you know. I ran into it by "apt upgrade" after changing sources.list from buster to bullseye. The container created with debootstrap, possibly a stretch release at that debootstrap time (IIRC). Filesystem ia an ext4 on a lvm, backed by a raid1. > What does > SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --create --prefix /var/log/journal > say? thecus:/home/tobi# machinectl shell ubiquiti Connected to machine ubiquiti. Press ^] three times within 1s to exit session. root@thecus:~# SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --create --prefix /var/log/journal Looking for configuration files in (higher priority first): /etc/tmpfiles.d /run/tmpfiles.d /usr/local/lib/tmpfiles.d /usr/lib/tmpfiles.d /lib/tmpfiles.d SELinux enabled state cached to: disabled Skipping overridden file '/usr/lib/tmpfiles.d/screen-cleanup.conf'. Reading config file "/usr/lib/tmpfiles.d/dbus.conf"… Entry "/var/lib/dbus" does not match any include prefix, skipping. Entry "/var/lib/dbus/machine-id" does not match any include prefix, skipping. Reading config file "/usr/lib/tmpfiles.d/debian.conf"… Entry "/run/shm" does not match any include prefix, skipping. Entry "/run/sendsigs.omit.d" does not match any include prefix, skipping. Entry "/etc/mtab" does not match any include prefix, skipping. Reading config file "/usr/lib/tmpfiles.d/home.conf"… Entry "/home" does not match any include prefix, skipping. Entry "/srv" does not match any include prefix, skipping. Reading config file "/usr/lib/tmpfiles.d/journal-nocow.conf"… Entry "/var/log/journal" matches include prefix "/var/log/journal". Entry "/var/log/journal/0168a64537e84260bcb1172567dbc16e" matches include prefix "/var/log/journal". Entry "/var/log/journal/remote" matches include prefix "/var/log/journal". Reading config file "/usr/lib/tmpfiles.d/legacy.conf"… Entry "/var/lock" does not match any include prefix, skipping. Entry "/run/lock/subsys" does not match any include prefix, skipping. /usr/lib/tmpfiles.d/legacy.conf:24: Ignoring entry r! "/forcefsck" because --boot is not specified. /usr/lib/tmpfiles.d/legacy.conf:25: Ignoring entry r! "/fastboot" because --boot is not specified. /usr/lib/tmpfiles.d/legacy.conf:26: Ignoring entry r! "/forcequotacheck" because --boot is not specified. Reading config file "/usr/lib/tmpfiles.d/passwd.conf"… /usr/lib/tmpfiles.d/passwd.conf:3: Ignoring entry r! "/etc/gshadow.lock" because --boot is not specified. /usr/lib/tmpfiles.d/passwd.conf:4: Ignoring entry r! "/etc/shadow.lock" because --boot is not specified. /usr/lib/tmpfiles.d/passwd.conf:5: Ignoring entry r! "/etc/passwd.lock" because --boot is not specified. /usr/lib/tmpfiles.d/passwd.conf:6: Ignoring entry r! "/etc/group.lock" because --boot is not specified. /usr/lib/tmpfiles.d/passwd.conf:7: Ignoring entry r! "/etc/subuid.lock" because --boot is not specified. /usr/lib/tmpfiles.d/passwd.conf:8: Ignoring entry r! "/etc/subgid.lock" because --boot is not specified. Reading config file "/etc/tmpfiles.d/screen-cleanup.conf"… Entry "/run/screen" does not match any include prefix, skipping. Reading config file "/usr/lib/tmpfiles.d/systemd-nologin.conf"… /usr/lib/tmpfiles.d/systemd-nologin.conf:11: Ignoring entry F! "/run/nologin" because --boot is not specified. Reading config file "/usr/lib/tmpfiles.d/systemd-pstore.conf"… Entry "/var/lib/systemd/pstore" does not match any include prefix, skipping. Reading config file "/usr/lib/tmpfiles.d/systemd-tmp.conf"… Entry "/tmp/systemd-private-7ca11069754049cab705a4d6f1b76e98-*" does not match any include prefix, skipping. Entry "/tmp/systemd-private-7ca11069754049cab705a4d6f1b76e98-*/tmp" does not match any include prefix, skipping. Entry "/var/tmp/systemd-private-7ca11069754049cab705a4d6f1b76e98-*" does not match any include prefix, skipping. Entry "/var/tmp/systemd-private-7ca11069754049cab705a4d6f1b76e98-*/tmp" does not match any include prefix, skipping. /usr/lib/tmpfiles.d/systemd-tmp.conf:17: Ignoring entry R! "/tmp/systemd-private-*" because --boot is not specified. /usr/lib/tmpfiles.d/systemd-tmp.conf:18: Ignoring entry R! "/var/tmp/systemd-private-*" because --boot is not specified. Entry "/var/lib/systemd/coredump/.#core*.7ca11069754049cab705a4d6f1b76e98*" does not match any include prefix, skipping. /usr/lib/tmpfiles.d/systemd-tmp.conf:23: Ignoring entry r! "/var/lib/systemd/coredump/.#*" because --boot is not specified. Reading config file "/usr/lib/tmpfiles.d/systemd.conf"… Entry "/run/user" does not match any include prefix, skipping.
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 14:03 schrieb Karsten: Am 02.01.22 um 12:15 schrieb Matthias Andree: I am the owner of the domain so nobody is hijacked! Are you the owner of "mydomain.de" or of the unnamed domain you intended not to show to the public? Do you want to help with this new certificate issue or discuss the ownership of domains? In this case, the latter. There are dedicated domain names for everyone to use for documentation and test purposes, https://datatracker.ietf.org/doc/html/rfc6761#section-6.5 With the search "install OpenSSL trust store" i could find this article: https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore that explains much of the stuff, but not how to use an self-signed certificate. https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list/ but check the fine print and lower rated comments, too -- for recent ca-certificates packages. Basically you can install the self-signed certificate (if you or a trusted party signed it, and you have transmitted it over a secure channel, for instance, via SFTP or SCP) into the trust store (assuming it suits both the TLS server and the signing CA roles - which was set when you created it). This worked for more then 5 years with TLS1.2 without any problem. Why this must be a problem now? Because "working" does not imply "working safely and securely". Take the example Mozilla and please explain why it works without an "OpenSSL trust store" ? Mozilla applications ship with their own trust store and do not use OpenSSL, but incorporate their own TLS library called NSS. Untrue. Mozilla's certificates are installed for offline use by Debian, Fedora, FreeBSD and derived distros under names such as ca-certificates, ca_root_nss or similar. AFAICS and up to and including OpenSSL 3.0.0, OpenSSL does not perform Online Certificate Status Protocol (OCSP) polls, so no calling home involved to date. O.K. Then you have no request to this CA-servers for every connect to a server with a certificate, but every private server is registered there and every client will request the "trust" once to access the server. So you can made a profil who is using a server. That's the simple goal of it. No, where does that access happen? The trust store is local to your computer and fetchmail might use your system's DNS resolver (which can have privacy implications) and will connect to the servers you point it to. Thanks - but now i still have no idea where to search for the trust store of fetschmail? It uses OpenSSL's unless you override that (see man fetchmail for --ssl... options). Why it is not possible to give the needed commands like before, like openssl req -x509 -newkey rsa:4096 -keyout /etc/exim4/exim.key.pem -out /etc/exim4/exim.cert.pem -days 365 -nodes ? The reason is the lack of understanding what has changed and what must be done and not to bother you. I understand, but too many variables involved and neither of us has time for guesswork. I don't know how your CA (even if only implied for that certificate) is set up or whatever else is needed, and I don't intend to do consulting. Figuratively speaking, you need to learn how to fish, not be given the fish. When this is a standard procedure, why it is not possible to find existing examples how to handle it? Why it is still possible to fetch Data with TLS1.2 from the FTP-Server without similar problems? fetchmail doesn't do FTP, and FTP is being phased out because it's hard to get right with its two connections, active/passive mode, firewalls/NAT/conntrack, TLS being added afterwards and I guess it was superseded by many other protocols that either tunnel through SSH or use one TLS connection, for instance, DAV. It is probably not about TLS version numbers anyways, but generally tightened security. You upgraded the entire client system, and that brought a lot of changes. https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 might also be involved.
Bug#1003000: RM: rgtk2 -- ROM: Retired upstream
Package: ftp.debian.org Severity: normal The RGtk2 package (source rgtk2 for us, binary r-cran-rgtk2) was an important package in its day in bringing a modern and pretty UI framework to R across different OS, and I looked after it for 15 years. It never made the move to Gtk3 though, and usage moved more and more to dashboard in browsers instead. Consequently, RGtk2 was now retired at CRAN. We should remove it too. The only reverse depends is a meta package. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1002999: ftp.debian.org: RM: cairodevice -- ROM: Retired upstream
Package: ftp.debian.org Severity: normal The cairoDevice package (source cairodevice for us, binary r-cran-cairodevice) was the first 'Cairo' device for R, it has been replaced by the actively maintained 'Cairo' package (r-cran-cairo for us). It was now retired at CRAN. We should remove it too. The only reverse depends is a meta package. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#997748: libcomps: FTBFS: There is a syntax error in your configuration file: Missing parentheses in call to 'print'. Did you mean print(os.environ['LD_LIBRARY_PATH'])? (conf.py, line 23)
On Sun, Jan 02, 2022 at 03:36:11PM +0100, Frédéric Pierret wrote: > Yes it's enough. I'm already adding it in libcomps. I should upload soon :) cool! & thank you! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Plastic bottles: made to last forever, designed to throw away. signature.asc Description: PGP signature
Bug#1002998: firejail-profiles: telegram-desktop not working with firejail
Package: firejail-profiles Version: 0.9.66-2 Severity: important X-Debbugs-Cc: pior...@gmx.com Dear Maintainer, I have used telegram-desktop with firejail on Debian 10. Everything was working fine. Two days ago, I updated to Debian Testing. System is clean and everything else is working. Only telegram-desktop is failing to work with firejail profile. Terminal output: $ firejail telegram-desktop Reading profile /etc/firejail/telegram-desktop.profile Reading profile /etc/firejail/telegram.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-devel.inc Reading profile /etc/firejail/disable-exec.inc Reading profile /etc/firejail/disable-interpreters.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/disable-shell.inc Reading profile /etc/firejail/disable-xdg.inc Reading profile /etc/firejail/whitelist-common.inc Reading profile /etc/firejail/whitelist-runuser-common.inc Reading profile /etc/firejail/whitelist-usr-share-common.inc Reading profile /etc/firejail/whitelist-var-common.inc Parent pid 825717, child pid 825720 Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set. Warning: skipping crypto-policies for private /etc Warning: skipping pki for private /etc Warning fcopy: skipping /etc/pulse/client.conf.d/01-enable-autospawn.conf, cannot find inode Private /etc installed in 13.33 ms Private /usr/etc installed in 0.00 ms Child process initialized in 81.10 ms Parent is shutting down, bye... Before upgrade to Testing, everything was working fine. Something is wrong with firejail profile? I request assistance. Thank you. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (100, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail-profiles depends on: ii firejail 0.9.66-2 firejail-profiles recommends no packages. firejail-profiles suggests no packages. -- no debconf information
Bug#999806: pygattlib: Misbuild with multiple supported python versions
Hi Nobuhiro, [...] > Python3.10 has been introduced in Ubuntu, and as part of the rebuild > of packages against 3.10 I noticed that pygattlib misbuilds, linking > both the python3.9 and python3.10 extensions against the same version > of libboost_python instead of linking each against the matching > version. > > The attach patch fixes the build so that each binary extension will > always be built against the matching libboost_python. This bug is causing my dependent package gnome-keysign to drop out of testing soon, so I would be happy to NMU this patch if you are fine with that. Please let me know if you have any objections, otherwise I will prepare a NMU in a week or so. Thanks, and have a happy new year! Sascha
Bug#997748: libcomps: FTBFS: There is a syntax error in your configuration file: Missing parentheses in call to 'print'. Did you mean print(os.environ['LD_LIBRARY_PATH'])? (conf.py, line 23)
Hi, Le 1/2/22 à 15:10, Holger Levsen a écrit : hi, On Sun, Oct 24, 2021 at 01:39:00PM +0200, Lucas Nussbaum wrote: Source: libcomps Version: 0.1.15-4 Severity: serious [...] During a rebuild of all packages in sid, your package failed to build on amd64. [...] Running Sphinx v4.2.0 Configuration error: There is a syntax error in your configuration file: Missing parentheses in call to 'print'. Did you mean print(os.environ['LD_LIBRARY_PATH'])? (conf.py, line 23) make[5]: *** [src/python/docs/CMakeFiles/pydocs.dir/build.make:122: pydocs] Error 2 It seems to me we can fix this bug by simply taking the patch from https://github.com/rpm-software-management/libcomps/commit/5eebd94a7ce855979eb014595256eee17ee6b359 Can someone confirm? I'd be happy to sponsor an upload again :) Yes it's enough. I'm already adding it in libcomps. I should upload soon :) Frédéric OpenPGP_signature Description: OpenPGP digital signature
Bug#1002997: podman: Please provide a default /etc/containers/storage.conf
Package: podman Version: 3.0.1+dfsg1-3+b2 Severity: wishlist Dear Maintainer, I had some problems running the dockerized version of the Unifi controller jacobalberty/unifi-docker with podman on Debian. On a Fedora system, starting the container only takes a few seconds. On a Debian system, it can take about 5 minutes. The reason is that on the Fedora system the mount-option metacopy=on (see [1] for this mount option) is set for the container overlayfs via a default /etc/containers/storage.conf. That makes quite the difference for this specific image because it does a `chown unifi:unifi /usr/lib/unifi` during startup. chown-ing these 6k files is fast with metacopy=on (on Fedora). Without the option (on Debian), I think the files will be copied instead of only their metadata, making it rather slow. So the solution for me was to copy /etc/containers/storage.conf from a Fedora system. If anyone has a similar problem, the file can be extracted from the src rpm of the containers-common package which can be downloaded at [2]. IMO it would be useful if Debian would also include a default /etc/containers/storage.conf. Thanks for considering this! However I'm not sure if metacopy=on is a good idea from a security perspective. Best Philip -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.0.25+ds1-1.1 ii containernetworking-plugins 0.9.0-1+b6 ii 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-13+deb11u2 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1+deb11u1 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1+b6 ii catatonit 0.1.5-2 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7 ii slirp4netns 1.0.1-2 ii uidmap1:4.8.1-1 Versions of packages podman suggests: pn containers-storage pn docker-compose -- no debconf information [1]: https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html#metadata-only-copy-up [2]: https://kojipkgs.fedoraproject.org//packages/containers-common/1/32.fc35/src/containers-common-1-32.fc35.src.rpm
Bug#999806: pygattlib: diff for NMU version 0~20201113-1.1
Control: tags 999806 + pending Dear maintainer, I've prepared an NMU for pygattlib (versioned as 0~20201113-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- diffstat for pygattlib-0~20201113 pygattlib-0~20201113 changelog |8 patches/multiple-boost-python.patch | 27 +++ patches/series |1 + 3 files changed, 36 insertions(+) diff -Nru pygattlib-0~20201113/debian/changelog pygattlib-0~20201113/debian/changelog --- pygattlib-0~20201113/debian/changelog 2020-12-23 09:44:47.0 +0100 +++ pygattlib-0~20201113/debian/changelog 2022-01-02 15:38:19.0 +0100 @@ -1,3 +1,11 @@ +pygattlib (0~20201113-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix misbuild with multiple supported Python3 versions. Closes: #999806 +Thanks to Steve Langasek for the patch. + + -- Mattia Rizzolo Sun, 02 Jan 2022 15:38:19 +0100 + pygattlib (0~20201113-1) unstable; urgency=medium * Initial Release. (Closes: #977950) diff -Nru pygattlib-0~20201113/debian/patches/multiple-boost-python.patch pygattlib-0~20201113/debian/patches/multiple-boost-python.patch --- pygattlib-0~20201113/debian/patches/multiple-boost-python.patch 1970-01-01 01:00:00.0 +0100 +++ pygattlib-0~20201113/debian/patches/multiple-boost-python.patch 2022-01-02 15:37:47.0 +0100 @@ -0,0 +1,27 @@ +Description: fix libboost detection with multiple python versions + pygattlib always links against the first libboost_python.so it finds. + When building for multiple python versions, this is wrong; it should link + against the one matching the version of python we're building for. +Author: Steve Langasek +Bug-Debian: https://bugs.debian.org/999806 +Last-Update: 2022-01-02 + +Index: pygattlib-0~20201113/setup.py +=== +--- pygattlib-0~20201113.orig/setup.py pygattlib-0~20201113/setup.py +@@ -11,12 +11,8 @@ + + + def get_boost_version(out=None): +-if out is None: +-out = subprocess.check_output( +-r"ldconfig -p | grep -E 'libboost_python.*\.so '", shell=True) +- +-ver = os.path.splitext(out.split()[0][3:])[0].decode() +-return ver ++return 'boost_python%s%s' \ ++% (sys.version_info.major, sys.version_info.minor) + + def tests(): + # case: python3-py3x.so diff -Nru pygattlib-0~20201113/debian/patches/series pygattlib-0~20201113/debian/patches/series --- pygattlib-0~20201113/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ pygattlib-0~20201113/debian/patches/series 2022-01-02 15:37:18.0 +0100 @@ -0,0 +1 @@ +multiple-boost-python.patch signature.asc Description: PGP signature
Bug#1001981: [Pkg-privacy-maintainers] Bug#1001981: Bug#1001981: onioncircuits: Doesn't start: Permission denied: '/usr/local/lib/python3.9/dist-packages/usb-0.0.83.dev0.dist-info'
severity 1001981 normal thanks FTR: The original reporter confirmed that removing the Python modules in /usr/local got onioncircuits to start again. So lowering severity as this is likely not a packaging bug breaking onioncircuits for everyone. S. On 23.12.21 12:58, Sascha Steinbiss wrote: > Hi Richard, > > thanks for your report. Let's see what I can do. > >> clicking then launcher results in no visible action. > > This is just in bullseye? Unfortunately I can't reproduce this, > onioncircuits opens fine for me. > >> Starting from shell >> results in this: >> >> rz@rz-debian:~$ onioncircuits > >> PermissionError: [Errno 13] Permission denied: >> '/usr/local/lib/python3.9/dist- >> packages/usb-0.0.83.dev0.dist-info' > > This is quite suspicious. There should no Python code installed by > Debian packages in /usr/local [1]. It looks like something installed > alongside the Debian-provided Python modules is interfering with > operation of the pycountry module, which is a dependency of onioncircuits. > Did you install any Python packages system-wide using pip or other means > other than Debian packaging, maybe even using sudo? This may leave files > around with permissions not including the rz user. > > Can you please try uninstalling these files in > /usr/local/lib/python3.9/dist-packages and try again? Thanks! > > Cheers > Sascha > > [1] See Policy 9.1.2: > https://www.debian.org/doc/debian-policy/ch-opersys.html#site-specific-programs > > ___ > Pkg-privacy-maintainers mailing list > pkg-privacy-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-privacy-maintainers >
Bug#1002996: ITP: python-orjson -- fast, correct JSON library for Python
Package: wnpp Severity: wishlist Owner: Romain Porte X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org, debian-fo...@lists.debian.org, debian-r...@lists.debian.org * Package name : python-orjson Version : 3.6.5 Upstream Author : ijl * URL : https://github.com/ijl/orjson * License : Apache-2.0 OR MIT Programming Lang: Rust Description : fast, correct JSON library for Python This package is added as a dependency to a new release of the gftools tool maintained by myself in the Debian Fonts Team. I intent to maintain this package in the Debian Python Team (or Debian Rust Team depending on how packaging goes).
Bug#926037: systemd: localectl console keymap configuration delayed
On 02.01.22 14:49, Floris Bos wrote: On 1/2/22 2:10 PM, Michael Biebl wrote: On 02.01.22 13:32, Floris Bos wrote: I recall in some cases it is also necessary to regenerate initramfs after a keyboard settings change. E.g. when LUKS encryption is used and the user needs to be able to enter the password to unlock the disks in the console prior to the rest of the system being booted. So just restarting one of the services actually may not be enough. Well, I'm not yet convinced that doing this in localed is the correct place. After all, if you run dpkg-reconfigure console-setup, it doesn't update the initramfs either, or does it? It does on my Ubuntu box. Not certain about upstream Debian. it doesn't OpenPGP_signature Description: OpenPGP digital signature
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 14:24 schrieb Karsten: Am 02.01.22 um 12:28 schrieb Matthias Andree: But it would be helpful for others what must be done to create and install this new "client side certificate" that appears about 2018? I think the certificate issue was there right from the beginning. Definitely no. Mails where fetched for about 5 years without any problem. Untrue. Messages were fetched without proper protection from MITM/eavesdropping attacks, unless you were using *other* options to ensure authenticity of the server. Which I doubt, else you would have asked specific questions about fetchmail options. That's true - but you change the privacy with an voluntary registration at an CA-authority. I don't see anyone suggested that, but tell me how... The people that can make MITM/eavesdropping attacks can fake an CA-authority too. ...that CA certificate would make it into your trust store. There used to be ill-advised instructions by fourth parties that gave the wrong advise to download and storing the server's certificate into the trust store. If the faked CA authority certificate is not in your trust store, certificate validation will flag the missing trust anchor or issue "self-signed certificate" errors. In practice, Linux and BSD distros usually deploy the CAs from Mozilla's CA Program https://blog.mozilla.org/security/category/ca-program/ and Mozilla have banned CAs that were abusive. Do you think it is possible to make thousands of MITM/eavesdropping attacks parallel for every private server? You can safely bet it happens at scale, and million-fold each and every day. The question is who will make the faked CA authority trustworthy? Company networks with malware-scanning outside proxies, free WiFi sites, you name it. You don't verify, you don't know. Can you please recommend *other* options to ensure more security with self signed certificates? See my previous messages, put the CA certificate (not private key) that signed your server's certificate into the OpenSSL trust store of the computer running fetchmail, or into a local place that you point fetchmail to. That won't work without reading documentation on how certification chains and trust delegation work. In the Debian world, things revolve around update-ca-certificates from the ca-certificates package. I'm caring about safety and privacy, that's the reason encryption with private certificates are used. Nonsense. That's the reason why fetchmail 6.4.0 finally broke compatibility with broken sites and finally (far too late) enforces proper X.509 certificate chains to so-called trust anchors. Can you explain this a little bit more please? Using encryption with an self-signed certificate cannot be more nonsense then to use no encryption at all. This makes no sense for me from a logic point. That's not what I wrote, but the logic you refer to is why fetchmail 6.4 - finally - forbids unverified certificates by default. Meaning: No more connection to sites with incomplete certification chains or where the certification chain cannot be anchored to a trusted CA. Why have older fetchmail versions made proper trust verification optional? :-) 6.3 appeared in 2005, before E. Snowden hat blown the whistle and before web browsers started to flag sites with unverified certification chains as insecure - and 6.3.X has kept compatibility and defaults. Before this turns into more gossip, I propose to close the bug report now. Do that by replying to 1002910-cl...@bugs.debian.org instead of the 1002910@ address.
Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)
Control: tags -1 + moreinfo unreproducible On 02.01.22 14:52, Tobias Frost wrote: Please let me know if there are additional details I could supply. Can you provide steps how to reproduce the issue? More details how the container is constructed, which fs is used etc. might help as well. What does SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --create --prefix /var/log/journal say? OpenPGP_signature Description: OpenPGP digital signature
