Bug#1014900: bullseye-pu: package node-moment/2.29.1+ds-2+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
node-moment is vulnerable to ReDoS (#1014845, CVE-2022-31129)
[ Impact ]
Medium security issue
[ Tests ]
Sadly there is no test in this package.
[ Risks ]
Low risk, patch is trivial
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
Regexp improvement
Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index d0566a3b..829c6ec2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-moment (2.29.1+ds-2+deb11u2) bullseye; urgency=medium
+
+ * Fix ReDoS (Closes: #1014845, CVE-2022-31129)
+
+ -- Yadd Wed, 13 Jul 2022 21:12:52 +0200
+
node-moment (2.29.1+ds-2+deb11u1) bullseye; urgency=medium
* Avoid loading path-looking locales from fs (Closes: #1009327,
diff --git a/debian/patches/CVE-2022-31129.patch
b/debian/patches/CVE-2022-31129.patch
new file mode 100644
index ..e10777fa
--- /dev/null
+++ b/debian/patches/CVE-2022-31129.patch
@@ -0,0 +1,42 @@
+Description: Fix ReDoS
+Author: Khang Vo (doublevkay)
+Origin: upstream, https://github.com/moment/moment/commit/9a3b5894
+Bug: https://github.com/moment/moment/security/advisories/GHSA-wc69-rhjr-hc9g
+Bug-Debian: https://bugs.debian.org/1014845
+Forwarded: not-needed
+Reviewed-By: Yadd
+Last-Update: 2022-07-13
+
+--- a/dist/moment.js
b/dist/moment.js
+@@ -2434,7 +2434,7 @@
+ function preprocessRFC2822(s) {
+ // Remove comments and folding whitespace and replace multiple-spaces
with a single space
+ return s
+-.replace(/\([^)]*\)|[\n\t]/g, ' ')
++.replace(/\([^()]*\)|[\n\t]/g, ' ')
+ .replace(/(\s\s+)/g, ' ')
+ .replace(/^\s\s*/, '')
+ .replace(/\s\s*$/, '');
+--- a/moment.js
b/moment.js
+@@ -2440,7 +2440,7 @@
+ function preprocessRFC2822(s) {
+ // Remove comments and folding whitespace and replace multiple-spaces
with a single space
+ return s
+-.replace(/\([^)]*\)|[\n\t]/g, ' ')
++.replace(/\([^()]*\)|[\n\t]/g, ' ')
+ .replace(/(\s\s+)/g, ' ')
+ .replace(/^\s\s*/, '')
+ .replace(/\s\s*$/, '');
+--- a/src/lib/create/from-string.js
b/src/lib/create/from-string.js
+@@ -147,7 +147,7 @@
+ function preprocessRFC2822(s) {
+ // Remove comments and folding whitespace and replace multiple-spaces
with a single space
+ return s
+-.replace(/\([^)]*\)|[\n\t]/g, ' ')
++.replace(/\([^()]*\)|[\n\t]/g, ' ')
+ .replace(/(\s\s+)/g, ' ')
+ .replace(/^\s\s*/, '')
+ .replace(/\s\s*$/, '');
diff --git a/debian/patches/series b/debian/patches/series
index b59ca1ed..48b9eff0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
CVE-2022-24785.patch
+CVE-2022-31129.patch
Bug#1014899: root subvolume should be @rootfs for Debian
Source: timeshift Version: 22.06.1-0.1 Severity: normal I realize the current released d-i (bullseye) can install system to btrfs. The released d-i uses @rootfs subvolume and recent grub can cope with this arrangement on Debian. This is nice but this arrangement is different from Ubuntu which uses @ subvolume. It will be nice to patch timeshift source to use @rootfs instead of @ on Debian. Osamu -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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
Bug#1014898: ITP: gcompat -- The GNU C library compatibility layer for musl
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gcompat Version : 1.0.0 Upstream Author : A. Wilcox * URL : https://git.adelielinux.org/adelie/gcompat * License : Expat Programming Lang: C Description : The GNU C library compatibility layer for musl The gcompat provides glibc-compatible APIs for use on musl libc systems. . This library is designed to be used for binaries that are already compiled against glibc. It does not contain any headers, and cannot be used to build software that requires glibc. It is instead recommended that any software that requires glibc APIs be modified to become more portable. . This library can optionally be compiled with other libraries to make a single, unfied solution. This can include fts, libucontext, obstack, and others. . gcompat additionally provides a loader stub. This is a small library that has the same name as the glibc dynamic linker on glibc platforms; when a binary is run that uses glibc as its dynamic linker, the stub will run, redirecting it to use musl and automatically preloading the gcompat library.
Bug#1014897: dh_installalternatives: support substitution variables
Package: debhelper
Version: 13.8
Severity: wishlist
Dear Maintainer,
It would be awesome if dh_installalternatives supported substitution variables,
e.g., ${DEB_HOST_MULTIARCH}.
Thanks!
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debhelper depends on:
ii autotools-dev20220109.1
ii dh-autoreconf20
ii dh-strip-nondeterminism 1.13.0-1
ii dpkg 1.21.9
ii dpkg-dev 1.21.9
ii dwz 0.14-1
ii file 1:5.41-4
ii libdebhelper-perl13.8
ii libdpkg-perl 1.21.9
ii man-db 2.10.2-1
ii perl 5.34.0-5
ii po-debconf 1.0.21+nmu1
debhelper recommends no packages.
Versions of packages debhelper suggests:
pn dh-make
-- no debconf information
Bug#1014690: llvmlite breaks numba autopkgtest: segmentation fault
Hi, I know there's some problems with some of numba's autopkgtests but I couldn't reproduce the segmentation fault. llvmlite's tracker suggests that the tests are passing now? Did you find a solution or is this likely to be a random problem? Diane On Sun, 2022-07-10 at 13:10 +0200, Paul Gevers wrote: > Source: llvmlite, numba > Control: found -1 llvmlite/0.38.1-2 > Control: found -1 numba/0.55.2+dfsg-1 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of llvmlite the autopkgtest of numba fails in > testing when that autopkgtest is run with the binary packages of > llvmlite from unstable. It passes when run with only packages from > testing. In tabular form: > > pass fail > llvmlite from testing 0.38.1-2 > numba from testing 0.55.2+dfsg-1 > all others from testing from testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of llvmlite 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=llvmlite > > https://ci.debian.net/data/autopkgtest/testing/arm64/n/numba/23504675/log.gz > > [*] Testing with python3.9: > /usr/lib/python3/dist-packages/numba/tests/npyufunc/test_gufunc.py:5: > DeprecationWarning: numpy.core.umath_tests is an internal NumPy > module > and should not be imported. It will be removed in a future NumPy > release. > import numpy.core.umath_tests as ut > /usr/lib/python3/dist- > packages/numba/tests/test_llvm_version_check.py:1: > DeprecationWarning: the imp module is deprecated in favour of > importlib; > see the module's documentation for alternative uses > import imp > skipped CUDA tests > skipped CUDA tests > Parallel: 9022. Serial: 652 > test (numba.tests.gdb.test_array_arg.Test) ... skipped 'needs > subprocess > harness' > test (numba.tests.gdb.test_basic.Test) ... skipped 'needs subprocess > harness' > test (numba.tests.gdb.test_break_on_symbol.Test) ... skipped 'needs > subprocess harness' > test (numba.tests.gdb.test_conditional_breakpoint.Test) ... skipped > 'needs subprocess harness' > test_axis (numba.tests.npyufunc.test_gufunc.TestGUFunc) ... ok > test_axis (numba.tests.npyufunc.test_gufunc.TestDynamicGUFunc) ... ok > test_basic_gufunc > (numba.tests.npyufunc.test_ufuncbuilding.TestGUfuncBuilding) ... ok > test_basic_gufunc > (numba.tests.npyufunc.test_ufuncbuilding.TestGUfuncBuildingJitDisable > d) > ... ok > test_basic_ufunc > (numba.tests.npyufunc.test_ufuncbuilding.TestUfuncBuilding) ... ok > test_basic_ufunc > (numba.tests.npyufunc.test_ufuncbuilding.TestUfuncBuildingJitDisabled > ) > ... ok > test_documentation_example1 > (numba.tests.doc_examples.test_rec_array.TestExample) ... ok > test_docstring (numba.tests.npyufunc.test_gufunc.TestGUFunc) ... ok > test_broadcasting (numba.tests.npyufunc.test_ufunc.TestUFuncs) ... ok > test_dynamic_ufunc_like > (numba.tests.npyufunc.test_gufunc.TestDynamicGUFunc) ... ok > test_dynamic_scalar_output > (numba.tests.npyufunc.test_gufunc.TestDynamicGUFunc) > Note that scalar output is a 0-dimension array that acts as ... ok > test_documentation_example2 > (numba.tests.doc_examples.test_rec_array.TestExample) ... ok > test_dynamic_matmul > (numba.tests.npyufunc.test_gufunc.TestDynamicGUFunc) > ... ok > Fatal Python error: Segmentation fault > > Current thread 0xac447010 (most recent call first): > File > "/usr/lib/python3/dist- > packages/numba/tests/doc_examples/test_typed_list_usage.py", > line 34 in test_ex_inferred_list_jit > File "/usr/lib/python3.9/unittest/case.py", line 550 in > _callTestMethod > File "/usr/lib/python3.9/unittest/case.py", line 592 in run > File "/usr/lib/python3.9/unittest/case.py", line 651 in __call__ > File "/usr/lib/python3/dist-packages/numba/testing/main.py", line > 664 > in __call__ > File "/usr/lib/python3.9/multiprocessing/pool.py", line 125 in > worker > File "/usr/lib/python3.9/multiprocessing/process.py", line 108 in > run > File "/usr/lib/python3.9/multiprocessing/process.py", line 315 in > _bootstrap > File "/usr/lib/python3.9/multiprocessing/popen_fork.py", line 71 > in > _launch > File "/usr/lib/python3.9/multiprocessing/popen_fork.py", line 19 > in > __init__ > File "/usr/lib/python3.9/multiprocessing/context.py", line 277 in > _Popen > File "/usr/lib/python3.9/multiprocessing/process.py", line 121 in > start > File "/usr/lib/python3.9/multiprocessing/pool.py", line 326 in > _repopulate_pool_static >
Bug#1014896: dh-python: Please provide mechanism to pass environment variable into pybuild-invoked commands
Package: dh-python Severity: wishlist Version: 5.20220403 X-Debbugs-CC: pi...@debian.org stefa...@debian.org c.schoen...@t-online.de Dear dh-python maintainers, First of all, thanks for the hard work in developing dh-python and pybuild. When integrating pybuild into pyproject-based packaging that uses pdm-pep517 as build backend, I found some need that pybuild does not seem to satisfy. If I understand correctly, it seems that pybuild will strip all unknown environment variables before invoking the actual build commands. For example, with following debian/rules snippet: include /usr/share/dpkg/pkg-info.mk export PYBUILD_NAME=autorefs export PYBUILD_SYSTEM=pyproject export PDM_PEP517_VERSION = $(DEB_VERSION_UPSTREAM) %: dh $@ --buildsystem=pybuild During package building, the "PDM_PEP517_VERSION" variable will not appear in the environment variable list when invoking "pythonX.Y -m build". This makes python3-pdm-pep517 confused when the package version cannot be recognized [1] using scm tags during Debian packaging. An example would be [2], where the version string ends up as 0.0.0. As a result, I am wondering if we could set up some mechanism to pass packager-specified environment variables to the actual build program. It could be something like this: include /usr/share/dpkg/pkg-info.mk export PYBUILD_NAME=autorefs export PYBUILD_SYSTEM=pyproject export PYBUILD_ENVVAR_PDM_PEP517_VERSION = $(DEB_VERSION_UPSTREAM) %: dh $@ --buildsystem=pybuild ...and eventually "pythonX.Y -m build" invocation will read "PDM_PEP517_VERSION = x.y.z" in its environment variable list. Please let me know whether this design is reasonable, or if you have some better solution in solving the issue of [2]. I know that adding package- specific patches could be a solution, but allowing packager to explicitly pass package version through environment variable could be more elegant. Thanks, Boyuan Yang [1] https://github.com/pdm-project/pdm-pep517#dynamic-project-version [2] https://salsa.debian.org/python-team/packages/mkdocs-autorefs/-/tree/bc79abd711f2cfe627d2d9c852379d7b571b4aa9 signature.asc Description: This is a digitally signed message part
Bug#1014822: inkscape-textext: Missing dependency on python3-cssselect
Dear Antonio, On Wed, Jul 13, 2022 at 07:52:50AM -0600, Antonio Russo wrote: > > Hello Kumar, > > Could you please elaborate what exactly fails without > python3-cssselect installed? > > I just confirmed here on stable that, installed or > not, python3-cssselect did not have any immediate > effect on the behavior of inkscape-textex. > > My original guess was the python3-cssselect might > be pulling in another dependency I missed, but this > package does not pull in any dependencies (besides > python itself). > > Moreover, the string cssselect does not even appear > in the textext repository, so this is not a direct > dependency.. > > Is it possible that something else was upgraded > or installed at the same time cssselect was installed? Here is the inkscape traceback I get without python3-cssselect: Traceback (most recent call last): File "/usr/share/inkscape/extensions/textext/__main__.py", line 1, in from textext.base import * File "/usr/share/inkscape/extensions/textext/base.py", line 100, in import inkex File "/usr/share/inkscape/extensions/inkex/__init__.py", line 11, in from .extensions import * File "/usr/share/inkscape/extensions/inkex/extensions.py", line 34, in from .elements import ( File "/usr/share/inkscape/extensions/inkex/elements/__init__.py", line 10, in from ._base import ShapeElement, BaseElement File "/usr/share/inkscape/extensions/inkex/elements/_base.py", line 38, in from ..styles import Style, Classes File "/usr/share/inkscape/extensions/inkex/styles.py", line 33, in from .css import ConditionalRule File "/usr/share/inkscape/extensions/inkex/css.py", line 27, in import cssselect ModuleNotFoundError: No module named 'cssselect' This is in Inkscape's file, so you are possibly correct in that this is not a bug with inkscape-textext. However, it triggered only with inkscape-textext. > P.S.: I notice that you are running a system with > stable, testing, and unstable packages installed. > This might contribute to weird dependency issues. > > I'd recommend removing the stable repository > and possibly purging obsolete packages afterwards, > though I doubt this has anything to do with > this bug. I would like to believe that this isn't the case, but if you are certain that there is something in my system causing this, please do close the bug, or suggest if this can be reassigned to inkscape. Thank you. Kumar
Bug#1009733: src:exempi: fails to migrate to testing for too long: FTBFS on armel and armhf
On 2022-05-29 17:53 +0200, Paul Gevers wrote: > Hi, > > On Sat, 16 Apr 2022 00:21:46 +0200 Michael Biebl wrote: > > Dear arm porters, > > > > can you please take a look at this? > > Ping from the Release Team. This package is a key package (so the RC bug > can't be "fixed" by removal from testing). I did take a look at this, but the logs from different builds were quite confusing and it was not at all obvious what the actual problem was. I left it for a mo to deal with somthing easier... I have failed to get back to it so far, and won't for at least another month (on holiday away from computers). Ah, but I see Bernhard has fixed it in the meantime. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1014843: opengnb: typo in the package description
control: tags -1 pending Hi, Thanks for your report and patch. The bug will fix in the next relase. Regards. 在 2022/7/13 13:47, Frank Dietrich 写道: Source: opengnb Version: 1.2.9.0-1 Severity: minor Tags: patch X-Debbugs-Cc: frank.dietr...@gmx.li Dear Maintainer, in the package description is a tiny typo. Please find a patch below. diff -ur opengnb-1.2.9.0/debian/control opengnb-1.2.9.0-patch/debian/control --- opengnb-1.2.9.0/debian/control 2022-06-21 11:21:22.0 +0200 +++ opengnb-1.2.9.0-patch/debian/control2022-07-13 07:40:49.627212347 +0200 @@ -22,7 +22,7 @@ OpenGNB can add many nodes and LANs together into one big VPN. OpenGNB supports public index nodes to forward net packages. . - OpenRNB support the following platforms: + OpenGNB support the following platforms: Linux, FreeBSD, OpenBSD, and macOS. . OpenGNB uses UDP by default. With the software gnb_udp_over_tcp cheers Frank -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- 肖盛文 xiao sheng wen https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com Debian salsa: https://salsa.debian.org/atzlinux-guest GnuPG Public Key: 0x00186602339240CB OpenPGP_signature Description: OpenPGP digital signature
Bug#1014887: Followup:
Looking at the source code in
https://github.com/cz172638/v4l-utils/blob/master/utils/ir-ctl/ir-ctl.c:
The file-read buffer is in read_file, at line 192:
char line[1024];
and when input is fetched in line 212,
while (fgets(line, sizeof(line), input)) {
the loop assumes that each call returns a complete line. It does *NOT*
allow for the possibility that the line is longer than this buffer. (See
https://en.cppreference.com/w/c/io/fgets for an illustration of this
truncation and continuation.)
The most common fixes can be seen at
https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152445
Note that using the POSIX getline() function instead of fgets()
automagically deals with this for you (though it does put the buffer in
the heap rather than on the stack, so you're responsible for free()ing it).
Is that sufficient to get this fixed, or do you need me to submit a
formal pull request?
--
/_ Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
/ https://www.amazon.com/dp/B09WJ3H657/
() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!
Bug#1014376: OpenVPN 2.6 in Debian
Upstream here: - Dropping of --cipher is not a sudden change in 2.6. OpenVPN 2.5 was already warning about this. Furthermore unless you have a OpenVPN 2.3 peer (quite old 2.4.0 come out 2016) or deliberately configured 2.4+ in a wacky way, server and client will negotiate AES-256-GCM. So proper VPN configurations should not be affected. More details about the cipher negotiation can be read here: https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst - OpenVPN master is a development branch, so even our branch should be stable at all time, it is not as well tested. The version that is in Debian *additionally* uses an experimental patch set on top of that. From my understand as well, this version was never intended to make into any stable distribution but was more for testing/getting it stable. For the deprecations and changes. OpenVPN 2.5 already drops --ciphers if not set to avoid using/allowing BF-CBC. OpenSSL 3.0 just accelerated the process and I backported a number of patches from master to the 2.5 to address the most pressing issues with OpenSSL 3.0. Just reverting 65f6da8ee in master is a really bad idea as other parts of OpenVPN (especially with the DCO patches on top) already make assumptions that --cipher no longer specifies a valid cipher. Furthermore, the configs are broken that rely on this. You should rather advise users to use compat-mode instead (https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/generic-options.rst) Arne
Bug#1014836: remrun: Source-only upload is needed
On Tue, Jul 12, 2022 at 04:50:57PM -0400, Boyuan Yang wrote: > Source: remrun > Version: 0.2.0-1 > Severity: important > X-Debbugs-CC: r...@debian.org > > Dear Debian remrun package maintainer, > > According to https://tracker.debian.org/pkg/remrun , your package needs > another source-only upload to be able to migrate to Debian Testing. Please > consider making another package upload to solve this problem. Thanks! Thanks for taking an interest in remrun, and thanks for the delayed NMU! The truth is I actually noticed this a couple of days ago (yeah, I know, I *really* should have noticed it three days after the original upload...) and I started working on minor upstream updates before uploading a new Debian version. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1013204: markdown-it-py: FTBFS with flit < 3.4 (<3.3?)
On Wed, 22 Jun 2022 14:13:29 +0200 Bastian Germann wrote: > On Sat, 18 Jun 2022 17:58:24 -0500 "David (Plasma) Paul" > wrote: > > markdown-it-py fails to build from source with versions of flit > > earlier than 3.4 according to the package's pyproject.toml.[0] > > Attached is a patch to fix the declared build dependency on flit in > > the debian/control file to match the supported versions listed in > > the package's pyproject.toml file. > > > > [0] However, I was able to get markdown-it-py to build with flit > > 3.3.0-1~bpo11+1, so maybe the value in the pyproject.toml file is > > higher than it strictly needs to be. Regardless of what the actual > > exact minimum value is, I can confirm that flit 3.0.0 is > > insufficient. > > Please do not file RC bugs when a bookworm/sid only package does not > build for bullseye-backports. If you want a backport please express > that intend otherwise this is invalid. Apologies for the being overzealous with regards to Build-Depends versioning. I will file this sort of report as a wishlist severity bug in the future. Sorry for overstepping. FWIW, my original reasoning for filing this bug went like this: For the sake of ensuring bootstrappability of any release N of Debian by the previous Debian release N-1, the build-dependencies of any release N source package ought to be satisfiable solely by some combination of (A) binary packages from the release N-1 binary archive (B) binary packages built from release N source packages using build-dependencies consisting solely of some combination of A and B In order to aid in this bootstrapping process, the allowed versions of the declared build dependencies of release N source packages should be constrained such that combinations of A and B which satisify the declared dependencies but fail to build the package are eliminated. Again, I'm sorry for being a nuisance and I will try to do better in the future. -- Plasma
Bug#1014879: Please do not depend on gnome-remote-desktop
On Wed, 13 Jul 2022 22:51:05 +0200 Jeremy Bicha wrote: > Please see https://launchpad.net/bugs/1980606 (which was mentioned in > the debian/changelog). > > Without that dependency, the app crashes. The above mentioned bug, in addition to being related to a different distribution, doesn't seem to be reproducible. The original author themselves mentions conflicts with other packages from a third-party repository, which should already invalidate any such report. I'm currently running gnome-control-center 1:42.3-1 with an empty (equivs generated) gnome-remote-desktop and I don't have any issues, nor did I have them with previous versions. > If you want to keep gnome-remote-desktop from running, why don't you > mask and disable the systemd user services? > > You could also lockdown the gsettings values. See > https://help.gnome.org/admin/system-admin-guide/stable/dconf-lockdown.html > for some basic documentation on how to do that. I believe that would > show the Remote Desktop Sharing option in the Settings app but it > would be impossible to turn the switch on. This imposes an unreasonable burden to users who simply want to avoid having an additional, unnecessary, non-essential service for which a gnome component only provides an optional interface. The proper solution would be to remove gnome-remote-desktop as a dependency and ideally add it as a recommended or suggested package. > I'll probably close this bug. Please don't. Thanks, Marco
Bug#1014894: firmware-amd-graphics: With the firmware installed Teamviewer unable to start with segfault error
Package: firmware-amd-graphics Version: 20210818-1 Severity: normal Dear Maintainer, On my older laptop ASUS F5RL on boot I was having a warning of a missing firmware for Raderon graphics, I installed this firmware and the warning disappeared, system is working ok, but I have problems with at least two programs: Teamviewer - it fails to start, giving a "segfault" error and a wine program which is also fails to start, giving another error (I'll provide it if needed). Once I delete the firmware package and update initramfs both programs begin to work properly. Graphic card installed is ATI Radeon Xpress 1100 I tried to install two previous versions of the firmware: 20210315-3 and 20190114-2 - the result was the same. I know the laptop is quite old but still working. Please consider a fix. Thanks. -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 5.10.0-16-686 (SMP w/2 CPU threads) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.140 -- no debconf information -- Best regards, Eugene.
Bug#1014832: libdecaf: Source-only upload is needed
X-Debbugs-CC: be...@debian.org Hi, 在 2022-07-13星期三的 20:12 +0200，Dennis Filder写道： > X-Debbugs-CC: Boyuan Yang > > On Tue, Jul 12, 2022 at 04:43:07PM -0400, Boyuan Yang wrote: > > > According to https://tracker.debian.org/pkg/libdecaf , you package needs > > another source-only upload to be able to migrate to Debian Testing. > > Please > > consider making another upload. > > Will that actually fix it? Or will it just break again on the > affected platforms due to still-missing cmake, cmake-data and/or > libssl1.1? This is a one-time effort, and you will not be affected by this issue as long as libdecaf does not go through the NEW queue again. * Currently you had a problematic non-source-only upload solely due to passing the NEW queue with an uploaded arch:all binary package (libdecaf- doc). * The solution would be a no-change source-only upload. Please read https://wiki.debian.org/SourceOnlyUpload for more information. * I have no idea about what is "still-missing cmake cmake-data and/or libssl1.1". According to https://buildd.debian.org/status/package.php?p=libdecaf , your package builds successfully on all release architectures, which is good enough for Testing migration. You _may_ dig into BD-Unstallable issues for non-release architectures. That is another story about python2.7 (see below). * That being said, your package build-depends on python2.7, and this should be fixed as soon as possible. For now, this does not block your package from migrating to Debian Testing as long as the non-source-only upload problem is fixed. TL;DR: Please consider making a new source-only upload now so that we can close this bug. It would be perfect if you could work with upstream author to drop python2.7 build-dependency, but that is not strictly required for now. Let me know if you have any other questions. Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1014893: libsqlite3-dev: unsatisfiable dependency libc6-dev
Package: libsqlite3-dev
Version: 3.39.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
The dependency on libc6-dev of libsqlite3-dev is unsatisfiable on some
architectures. Some glibc architectures use a different soname (e.g.
ia64, kfreebsd-any). It also poses a problem to musl where the package
is simply called musl-dev. The one thing they have in common is
providing libc-dev. Please consider applying the attached patch to
generalize the dependency.
Helmut
diff --minimal -Nru sqlite3-3.39.0/debian/changelog
sqlite3-3.39.0/debian/changelog
--- sqlite3-3.39.0/debian/changelog 2022-07-07 00:04:47.0 +0200
+++ sqlite3-3.39.0/debian/changelog 2022-07-13 23:53:26.0 +0200
@@ -1,3 +1,10 @@
+sqlite3 (3.39.0-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * libsqlite3-dev: Generalize libc6-dev dependency to libc-dev. (Closes: #-1)
+
+ -- Helmut Grohne Wed, 13 Jul 2022 23:53:26 +0200
+
sqlite3 (3.39.0-2) unstable; urgency=medium
* Compile with -DSQLITE_ALLOW_ROWID_IN_VIEW to re-enable rowid for views
diff --minimal -Nru sqlite3-3.39.0/debian/control sqlite3-3.39.0/debian/control
--- sqlite3-3.39.0/debian/control 2022-01-06 19:16:04.0 +0100
+++ sqlite3-3.39.0/debian/control 2022-07-13 23:53:24.0 +0200
@@ -64,7 +64,7 @@
Suggests: sqlite3-doc
Section: libdevel
Architecture: any
-Depends: libsqlite3-0 (= ${binary:Version}), ${misc:Depends}, libc6-dev
+Depends: libsqlite3-0 (= ${binary:Version}), ${misc:Depends}, libc-dev
Multi-Arch: same
Description: SQLite 3 development files
SQLite is a C library that implements an SQL database engine.
Bug#1014892: O: isa-support -- prevent installation on processors without required instructions
Package: wnpp Severity: normal Control: affects -1 src:isa-support I'm giving up the isa-support package. It was an attempt to handle packages that can't be reasonably ported to an arch's baseline, and to let them gracefully refuse to install rather than crash at runtime. Alas, it failed. While it works ok for the initial install when using command-line tools, a failed _upgrade_ (ie, when an existing package gains an ISA requirement) leaves the system in a state that's not trivial to recover from by a newbie user or a simplicistic clicky-clicky interface. I assumed that "apt -f install" translates to a similarly simply operation in a GUI, but this doesn't seem to be the case. On the other hand, there's no straightforward alternate solution. Maintainers of packages that depend on isa-support don't seem to be thrilled to migrate away from it, thus I can't remove the package immediately. Perhaps someone has a better idea...?
Bug#1014891: timeshift: New upstream release 22.06.3
Package: timeshift Version: 22.06.1-0.1 Severity: normal X-Debbugs-CC: s...@swm1.com Dear Debian timeshift package maintainers, A new upstream release is available at https://github.com/linuxmint/timeshift/releases/tag/22.06.3 . Please consider packaging it. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#991358: guile-2.2 should not be in bookworm
Sorry for the noise, I am just a buit curious ... Thorsten
Bug#1014450: usernames have a 32 character limit
On Wed, 2022-07-13 at 23:09 +0200, Marc Haber wrote: > On Wed, Jul 13, 2022 at 04:50:20PM -0400, Matt Barry wrote: > > On Wed, 2022-07-13 at 22:44 +0200, Marc Haber wrote: > > > On Wed, Jul 06, 2022 at 12:32:16PM +0200, Marc Haber wrote: > > > > the useradd documentation says that a user name has a 32 > > > > character > > > > limit. We should enforce this as well. > > > > > > Matt, would you want to take a quick plunge at this as well? > > > You're > > > still deeply acquained with the entire name checking stuff > > > anyway. > > > > Sure. There actually is a test for this, and it passes (ie. fails > > in > > every instance, for a 33 character name) - I think because useradd > > fails? We might as well check it though, I'll take a look. > > If we are ok with erroring out with a useradd error message, and the > output is not offensively ugly, I'm fine with that, and we can just > close this bug as fixed in 3.122. I am not emotional about this. I would apply that patch at some point; it isn't urgent, but it is cleaner.
Bug#1008082: Beginning work
On Wed, Jul 13, 2022 at 11:00:11PM +0200, Marc Haber wrote: > The expire dates are controlled by useradd's configuration file > /etc/login.defs, and the format is documented, so there is nothing too > wrong by just grepping the information from there. For a non-system > account, we would re-establish the default expiration value, or we could > save the expiration date in a state file and read it from there. Otoh, > for a system account, we should probably just disable account expiration > and document that adduser as a policy layer does not handle system > accounts with an expiration date. Sounds reasonable. > We're going to need state for some requested features anyway, sooner or > later. > > The nologin shell has the nice advantage of denying login _with_ _a_ > _message_ should somebody be able to log in to the account by some other > means that might be allowed by weird PAM and ssh stuff. I would like to > do that anyway, albeid not being strictly necessary. Sure. I had thought that expiry would be sufficient. However, if you are saving state after locking, it is simple enough to use the nologin shell as another hardening step. > I'd like to claim that feature and work on it if you're ok with that. > I'm going to create a branch deluser-lock and push frequently, so you > can review what I am doing. I reserve the right to force-push that > branch though. Proceed, of course! Slowness on my part shouldn't hold things up! ;) Best, -- Jason Franklin
Bug#1014450: usernames have a 32 character limit
On Wed, 2022-07-13 at 23:11 +0200, Marc Haber wrote: > On Wed, Jul 13, 2022 at 04:50:20PM -0400, Matt Barry wrote: > > There actually is a test for this, and it passes (ie. fails in > > every instance, for a 33 character name) > > Does it also fail reasonably prettily for a < 32 character UTF-8 name > that is > 32 bytes when encoded? (new patch) /h/d/adduser $ sudo adduser adduser: Usernames must be no more than 32 bytes in length; note that if you are using Unicode characters, the character limit will be less than 32. In the 3.121, the IEEE check will squash it. In 3.22: ~/h/d/adduser $ sudo adduser --allow-all-names Allowing use of questionable username. Adding user `' ... Adding new group `' (1023) ... groupadd: '' is not a valid group name adduser: `/sbin/groupadd -g 1023 ' returned error code 3. Exiting. so, not ideal, but it does error.
Bug#1014450: usernames have a 32 character limit
On Wed, Jul 13, 2022 at 04:50:20PM -0400, Matt Barry wrote: > There actually is a test for this, and it passes (ie. fails in > every instance, for a 33 character name) Does it also fail reasonably prettily for a < 32 character UTF-8 name that is > 32 bytes when encoded? 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#1014450: usernames have a 32 character limit
On Wed, Jul 13, 2022 at 04:50:20PM -0400, Matt Barry wrote: > On Wed, 2022-07-13 at 22:44 +0200, Marc Haber wrote: > > On Wed, Jul 06, 2022 at 12:32:16PM +0200, Marc Haber wrote: > > > the useradd documentation says that a user name has a 32 character > > > limit. We should enforce this as well. > > > > Matt, would you want to take a quick plunge at this as well? You're > > still deeply acquained with the entire name checking stuff anyway. > > Sure. There actually is a test for this, and it passes (ie. fails in > every instance, for a 33 character name) - I think because useradd > fails? We might as well check it though, I'll take a look. If we are ok with erroring out with a useradd error message, and the output is not offensively ugly, I'm fine with that, and we can just close this bug as fixed in 3.122. I am not emotional about this. 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#1014879: Please do not depend on gnome-remote-desktop
On Wed, Jul 13, 2022 at 10:51:05PM +0200, Jeremy Bicha wrote: > On Wed, Jul 13, 2022 at 6:27 PM Josh Triplett wrote: > > gnome-control-center 1:42.3-1 adds a dependency on gnome-remote-desktop, > > Please see https://launchpad.net/bugs/1980606 (which was mentioned in > the debian/changelog). > > Without that dependency, the app crashes. > > Perhaps the gsettings schemas could be split to a separate package but > I believe the code assumes that gnome-remote-desktop is available. So > we would just have a different bug. That does indeed seem like a bug, and I'd be happy for this bug to be repurposed to that effect: "gnome-control-center should work without gnome-remote-desktop installed". (Having the schemas installed doesn't seem like a problem.) > If you want to keep gnome-remote-desktop from running, why don't you > mask and disable the systemd user services? That would be my next logical path, but in general I try to minimize the number of things I have to have installed-and-disabled, so it seemed worth first seeing if this could become a Recommends. And it sounds like the answer is that first gnome-control-center would need a fix to not require it.
Bug#1008082: Beginning work
On Wed, Jul 13, 2022 at 04:46:53PM -0400, Jason Franklin wrote: > On Wed, Jul 13, 2022 at 10:18:55PM +0200, Marc Haber wrote: > > If adduser --lock sets the shell to nologin, how would we restore the > > account? Setting shell to /bin/bash, allowing --unlock a --shell option? > > Or should we finally introduce a state directory /var/lib/adduser and > > save the shell here? > > I assume you mean to clarify the behavior of "deluser --lock" here. Yes, of course. Stupid me. > Giving this some thought, I would not go the route of changing any of > the user's attributes like the login shell. > > My understanding is that truly locking an account requires two things: > 1. Place a "!" in front of the password field in /etc/shadow. > 2. Expire the account. > > The first makes the password invalid in a way that is easily reversible. > The commands "usermod -L foo" and "usermod -U foo" will disable and then > re-enable password authentication for user "foo" in this manner. > > The second requires setting the user's EXPIRE_DATE to 1. This should > disable other forms of authentication without modifying any info we > would want to save (except for the expire date). > > See usermod(8) and shadow(5) for more info on locking and expiry. > > The minimal satisfactory fix would be just a "--lock" option for the > deluser command which does both of the above. To undo this, an admin > would run "usermod -U foo" and then set the expire date for the account > according to site policy. I am not sure if there is a convenient command > for doing the latter. The expire dates are controlled by useradd's configuration file /etc/login.defs, and the format is documented, so there is nothing too wrong by just grepping the information from there. For a non-system account, we would re-establish the default expiration value, or we could save the expiration date in a state file and read it from there. Otoh, for a system account, we should probably just disable account expiration and document that adduser as a policy layer does not handle system accounts with an expiration date. We're going to need state for some requested features anyway, sooner or later. The nologin shell has the nice advantage of denying login _with_ _a_ _message_ should somebody be able to log in to the account by some other means that might be allowed by weird PAM and ssh stuff. I would like to do that anyway, albeid not being strictly necessary. > > Should we do that in adduser, or should we have a new binary moduser? > > Not sure how to answer this one. > > Like I say above, adding only the "--lock" option to deluser minimally > satisfies this new requirement. > > I would say it's up to you! :) That was a stupid question on my side. The primary use of lock / unlock is going to be package maintainer scripts, hence lock is a function of deluser, and unlock one of adduser. I'd like to claim that feature and work on it if you're ok with that. I'm going to create a branch deluser-lock and push frequently, so you can review what I am doing. I reserve the right to force-push that branch though. Greetings Marc
Bug#994540: transition: imagemagick
Hi On 2021-09-29 10:38:07 +0200, jo...@mister-muffin.de wrote: > In-reply-to: > From: Johannes Schauer Marin Rodrigues > > Hi, > > On Sun, 26 Sep 2021 21:27:19 +0200 Sebastian Ramacher > wrote: > > On 2021-09-17 12:51:37 +, Bastien Roucariès wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > Imagemagick changes some internal structures. Upstream bump so (safe), so > > > ask > > > for a rebuilt. > > > > Do all reverse dependencies build fine with the new Imagemagick version? > > If not, have bugs been filed? > > I have rebuilt all 399 source packages that have at least one binary produced > by src:imagemagick in their build dependency installation closure. Of those, > 16 > packages FTBFS with the imagemagick version form experimental but succeed with > the version from unstable. Of those, only one package (src:wand) is in the > list > from https://release.debian.org/transitions/html/auto-imagemagick.html I filed > this failure as #995290 and will investigate the other 15 instances as well. > But since those source packages are not part of the transition, they should > probably not block this bug. This transition completly dropped off my radar, sorry! What's the current status of the preparations? Have the bugs been filed? Cheers -- Sebastian Ramacher
Bug#1014879: Please do not depend on gnome-remote-desktop
On Wed, Jul 13, 2022 at 6:27 PM Josh Triplett wrote: > gnome-control-center 1:42.3-1 adds a dependency on gnome-remote-desktop, Please see https://launchpad.net/bugs/1980606 (which was mentioned in the debian/changelog). Without that dependency, the app crashes. Perhaps the gsettings schemas could be split to a separate package but I believe the code assumes that gnome-remote-desktop is available. So we would just have a different bug. If you want to keep gnome-remote-desktop from running, why don't you mask and disable the systemd user services? You could also lockdown the gsettings values. See https://help.gnome.org/admin/system-admin-guide/stable/dconf-lockdown.html for some basic documentation on how to do that. I believe that would show the Remote Desktop Sharing option in the Settings app but it would be impossible to turn the switch on. I'll probably close this bug. Thank you, Jeremy Bicha
Bug#1014450: usernames have a 32 character limit
On Wed, 2022-07-13 at 22:44 +0200, Marc Haber wrote: > Hi, > > On Wed, Jul 06, 2022 at 12:32:16PM +0200, Marc Haber wrote: > > the useradd documentation says that a user name has a 32 character > > limit. We should enforce this as well. > > Matt, would you want to take a quick plunge at this as well? You're > still deeply acquained with the entire name checking stuff anyway. Sure. There actually is a test for this, and it passes (ie. fails in every instance, for a 33 character name) - I think because useradd fails? We might as well check it though, I'll take a look. mb signature.asc Description: This is a digitally signed message part
Bug#1014450: usernames have a 32 character limit
Hi, On Wed, Jul 06, 2022 at 12:32:16PM +0200, Marc Haber wrote: > the useradd documentation says that a user name has a 32 character > limit. We should enforce this as well. Matt, would you want to take a quick plunge at this as well? You're still deeply acquained with the entire name checking stuff anyway. Greetings Marc
Bug#1008082: Beginning work
On Wed, Jul 13, 2022 at 10:18:55PM +0200, Marc Haber wrote: > are you progressing here? If not, I'd like to tackle this with some low > priority. Unfortunately, I have not made any progress on this yet. Too many personal things in the way... > If adduser --lock sets the shell to nologin, how would we restore the > account? Setting shell to /bin/bash, allowing --unlock a --shell option? > Or should we finally introduce a state directory /var/lib/adduser and > save the shell here? I assume you mean to clarify the behavior of "deluser --lock" here. Giving this some thought, I would not go the route of changing any of the user's attributes like the login shell. My understanding is that truly locking an account requires two things: 1. Place a "!" in front of the password field in /etc/shadow. 2. Expire the account. The first makes the password invalid in a way that is easily reversible. The commands "usermod -L foo" and "usermod -U foo" will disable and then re-enable password authentication for user "foo" in this manner. The second requires setting the user's EXPIRE_DATE to 1. This should disable other forms of authentication without modifying any info we would want to save (except for the expire date). See usermod(8) and shadow(5) for more info on locking and expiry. The minimal satisfactory fix would be just a "--lock" option for the deluser command which does both of the above. To undo this, an admin would run "usermod -U foo" and then set the expire date for the account according to site policy. I am not sure if there is a convenient command for doing the latter. > Should we do that in adduser, or should we have a new binary moduser? Not sure how to answer this one. Like I say above, adding only the "--lock" option to deluser minimally satisfies this new requirement. I would say it's up to you! :) -- Jason Franklin
Bug#1008082: Beginning work
On Thu, May 26, 2022 at 09:34:30AM -0400, Jason Franklin wrote: > I plan to start work on this issue in the next few days. > > Let me know if this conflicts with anyone's plans! Hi Jason, are you progressing here? If not, I'd like to tackle this with some low priority. If adduser --lock sets the shell to nologin, how would we restore the account? Setting shell to /bin/bash, allowing --unlock a --shell option? Or should we finally introduce a state directory /var/lib/adduser and save the shell here? Should we do that in adduser, or should we have a new binary moduser? Greetings Marc
Bug#1014845: [Pkg-javascript-devel] Bug#1014845: node-moment: CVE-2022-31129
Hi Yadd, On Wed, Jul 13, 2022 at 09:14:56PM +0200, Yadd wrote: > On 13/07/2022 08:38, Salvatore Bonaccorso wrote: > > Source: node-moment > > Version: 2.29.3+ds-1 > > Severity: grave > > Tags: security upstream > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > > > > Hi, > > > > The following vulnerability was published for node-moment. > > > > CVE-2022-31129[0]: > > | moment is a JavaScript date library for parsing, validating, > > | manipulating, and formatting dates. Affected versions of moment were > > | found to use an inefficient parsing algorithm. Specifically using > > | string-to-date parsing in moment (more specifically rfc2822 parsing, > > | which is tried by default) has quadratic (N^2) complexity on specific > > | inputs. Users may notice a noticeable slowdown is observed with inputs > > | above 10k characters. Users who pass user-provided strings without > > | sanity length checks to moment constructor are vulnerable to (Re)DoS > > | attacks. The problem is patched in 2.29.4, the patch can be applied to > > | all affected versions with minimal tweaking. Users are advised to > > | upgrade. Users unable to upgrade should consider limiting date lengths > > | accepted from user input. > > > > > > If you fix the vulnerability please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > Hi, > > here is the debdiff Thanks! I think it should be enough IMHO as well in this case to push the fix out via the next bullseye point release (now though a couple of weeks away as the counter restarted). Thank you for your work! Salvatore
Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea
Hi, On Fri, 8 Jul 2022 11:36:51 +0200 Raphael Hertzog wrote: > On Wed, 06 Jul 2022, Bernhard Schmidt wrote: > > > As such I really believe that this git snapshot should have stayed in > > > experimental. Why was it uploaded to unstable before its upstream > > > release? > > > > I respectfully disagree. This is what unstable/testing is for. 2.6 is to be > > released really soon, it contains breaking changes which we need to iron out > > / document with both upstream and Debian packaging. This can't wait until > > the last minute before the freeze. The 2.6 upload was influenced by OpenSSL > > 3.0, but this was definitely not the only reason to do this. The current snapshot actually is missing one important commit to better support OpenSSL 3: https://github.com/OpenVPN/openvpn/commit/88342ed8277c579704c0 This is a recommendation from one of the upstream developers here: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1975574/comments/3 Could we try at least to get a newer snapshot which includes the mentioned upstream commit? Another thing worrying this upstream maintainer was the fact that we seem to have experimental OpenVPN dco code which has been constantly improved: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1975574/comments/6 > If you were aware of regressions to iron out, it would have made sense to > file an RC bug to avoid the migration to testing until it has matured in > unstable. > > I understand it's always a trade off and that not all Debian developers > put the bar at the same level, but keeping testing "constantly usable" > has been something of a goal for a long time. I do not see the current version as unusable but a version with important breaking changes, and those will hit users at some point. > > This could be discussed with upstream. > > I certainly encourage you to discuss with upsream on whether they believe > a git snapshot ought to be delivered to unstable/testing (and thus > ultimately ubuntu too). As Raphael mentioned, upstream is against distros using snapshots from the master branch, however I do understand the reasons to do it earlier. >From the Debian perspective, I believe the important thing here is to make sure we ship 2.6 in the next release. -- Lucas Kanashiro
Bug#1014890: RFP: python3-looseversion -- Version numbering for anarchists and software realists
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org * Package name: python3-looseversion Version : 1.0.1 Upstream Author : Chris Markiewicz * URL : https://github.com/effigies/looseversion * License : Python Programming Lang: Python Description : Version numbering for anarchists and software realists A backwards/forwards-compatible fork of distutils.version.LooseVersion, for times when PEP-440 isn't what you need. . The goal of this package is to be a drop-in replacement for the original LooseVersion. It implements an identical interface and comparison logic to LooseVersion. The only major change is that a looseversion.LooseVersion is comparable to a distutils.version.LooseVersion, which means tools should not need to worry whether all dependencies that use LooseVersion have migrated. . If you are simply comparing versions of Python packages, consider moving to packaging.version.Version, which follows PEP-440. LooseVersion is better suited to interacting with heterogeneous version schemes that do not follow PEP-440. This package would be useful as we plan for adding support for Python 3.12 which would remove distutils.version.LooseVersion and some packages would need to "adjust" somehow. In our DataLad project we likely would just go the way of using this LooseVersion instead of coming up with some "more proper" solution.
Bug#1014889: Xorg radeon driver [Xpress 200M]: cannot run GNOME system apps, "r300 FP: Compiler Error: ../src/gallium/drivers/r300/compiler/r300_fragprog_emit.c::emit_alu(): Too many ALU instructions
Package: xserver-xorg-video-radeon Version: 1:19.1.0-3 Severity: important X-Debbugs-Cc: dmayr@gmail.com Dear Maintainer, while using the Xorg `radeon` driver [ATi Xpress 200M onboard chip, `r300`], it's not possible to run GNOME system apps (e.g. gnome-control-center, gnome- software, other systems apps). This happens when booting Debian Testing (bookworm) with GNOME and GDM, choosing the Xorg session over Wayland, otherwise there's no hardware acceleration (wayland defaults to Mesa llvmpipe with this chip). The error message when running these applications from the terminal is: ``` r300 FP: Compiler Error: ../src/gallium/drivers/r300/compiler/r300_fragprog_emit.c::emit_alu(): Too many ALU instructions Using a dummy shader instead``` After several iterations of the error message, applications segfault. For GDM and the Xorg session to work properly, the package `firmware-amd- graphics` is required. I had tried this on Debian Stable before (bullseye), but GDM crashed upon launch. I suspect that the underlying cause could eventually be somewhat related, as lacking the nonfree AMD firmware disables hardware acceleration (no modesetting possible), but installing it segfaults GDM and/or GNOME when using the `radeon` driver in Debian bullseye, or segfaults GNOME apps on Debian bookworm. Please let me know what additional information you require from me to begin pinpointing the probable causes of this problem. -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RC410M [Mobility Radeon Xpress 200M] [1002:5a62] /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 344 Jul 13 13:10 10-radeon.conf /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.18.0-2-686-pae (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.50.20220615) #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) Xorg X server log files on system: -- -rw-r--r-- 1 dmayr dmayr 31810 Jul 12 21:43 /home/dmayr/.local/share/xorg/Xorg.1.log -rw-r--r-- 1 dmayr dmayr 33925 Jul 12 21:47 /home/dmayr/.local/share/xorg/Xorg.3.log -rw-r--r-- 1 dmayr dmayr 31871 Jul 12 23:45 /home/dmayr/.local/share/xorg/Xorg.2.log -rw-r--r-- 1 dmayr dmayr 31257 Jul 13 14:11 /home/dmayr/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/dmayr/.local/share/xorg/Xorg.0.log): -- [57.921] (--) Log file renamed from "/home/dmayr/.local/share/xorg/Xorg.pid-1696.log" to "/home/dmayr/.local/share/xorg/Xorg.0.log" [57.928] X.Org X Server 1.21.1.3 X Protocol Version 11, Revision 0 [57.928] Current Operating System: Linux easynote-mx430 5.18.0-2-686-pae #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) i686 [57.929] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.18.0-2-686-pae root=UUID=852b8315-785b-4564-b9e8-c02319fda1d1 ro quiet splash [57.929] xorg-server 2:21.1.3-2+b1 (https://www.debian.org/support) [57.929] Current version of pixman: 0.40.0 [57.929]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [57.929] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [57.929] (==) Log file: "/home/dmayr/.local/share/xorg/Xorg.0.log", Time: Wed Jul 13 13:53:38 2022 [57.937] (==) Using config directory: "/etc/X11/xorg.conf.d" [57.937] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [57.941] (==) No Layout section. Using the first Screen section. [57.941] (==) No screen section available. Using defaults. [57.941] (**) |-->Screen "Default Screen Section" (0) [57.941] (**) | |-->Monitor "" [57.942] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [57.942] (**) | |-->Device "Radeon" [57.942] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [57.942] (==) Automatically adding devices [57.942] (==) Automatically enabling devices [57.942] (==) Automatically adding GPU devices [57.942] (==) Automatically binding GPU devices [57.942] (==) Max clients allowed: 256, resource mask: 0x1f [57.942] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [57.942]Entry deleted from font path. [57.942] (==) FontPath set to:
Bug#1014845: [Pkg-javascript-devel] Bug#1014845: node-moment: CVE-2022-31129
On 13/07/2022 08:38, Salvatore Bonaccorso wrote:
Source: node-moment
Version: 2.29.3+ds-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team
Hi,
The following vulnerability was published for node-moment.
CVE-2022-31129[0]:
| moment is a JavaScript date library for parsing, validating,
| manipulating, and formatting dates. Affected versions of moment were
| found to use an inefficient parsing algorithm. Specifically using
| string-to-date parsing in moment (more specifically rfc2822 parsing,
| which is tried by default) has quadratic (N^2) complexity on specific
| inputs. Users may notice a noticeable slowdown is observed with inputs
| above 10k characters. Users who pass user-provided strings without
| sanity length checks to moment constructor are vulnerable to (Re)DoS
| attacks. The problem is patched in 2.29.4, the patch can be applied to
| all affected versions with minimal tweaking. Users are advised to
| upgrade. Users unable to upgrade should consider limiting date lengths
| accepted from user input.
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
Hi,
here is the debdiff
Best regards,
Yadddiff --git a/debian/changelog b/debian/changelog
index d0566a3b..3bf1ca51 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-moment (2.29.1+ds-2+deb11u2) bullseye-security; urgency=medium
+
+ * Fix ReDoS (Closes: #1014845, CVE-2022-31129)
+
+ -- Yadd Wed, 13 Jul 2022 21:12:52 +0200
+
node-moment (2.29.1+ds-2+deb11u1) bullseye; urgency=medium
* Avoid loading path-looking locales from fs (Closes: #1009327,
diff --git a/debian/patches/CVE-2022-31129.patch
b/debian/patches/CVE-2022-31129.patch
new file mode 100644
index ..e10777fa
--- /dev/null
+++ b/debian/patches/CVE-2022-31129.patch
@@ -0,0 +1,42 @@
+Description: Fix ReDoS
+Author: Khang Vo (doublevkay)
+Origin: upstream, https://github.com/moment/moment/commit/9a3b5894
+Bug: https://github.com/moment/moment/security/advisories/GHSA-wc69-rhjr-hc9g
+Bug-Debian: https://bugs.debian.org/1014845
+Forwarded: not-needed
+Reviewed-By: Yadd
+Last-Update: 2022-07-13
+
+--- a/dist/moment.js
b/dist/moment.js
+@@ -2434,7 +2434,7 @@
+ function preprocessRFC2822(s) {
+ // Remove comments and folding whitespace and replace multiple-spaces
with a single space
+ return s
+-.replace(/\([^)]*\)|[\n\t]/g, ' ')
++.replace(/\([^()]*\)|[\n\t]/g, ' ')
+ .replace(/(\s\s+)/g, ' ')
+ .replace(/^\s\s*/, '')
+ .replace(/\s\s*$/, '');
+--- a/moment.js
b/moment.js
+@@ -2440,7 +2440,7 @@
+ function preprocessRFC2822(s) {
+ // Remove comments and folding whitespace and replace multiple-spaces
with a single space
+ return s
+-.replace(/\([^)]*\)|[\n\t]/g, ' ')
++.replace(/\([^()]*\)|[\n\t]/g, ' ')
+ .replace(/(\s\s+)/g, ' ')
+ .replace(/^\s\s*/, '')
+ .replace(/\s\s*$/, '');
+--- a/src/lib/create/from-string.js
b/src/lib/create/from-string.js
+@@ -147,7 +147,7 @@
+ function preprocessRFC2822(s) {
+ // Remove comments and folding whitespace and replace multiple-spaces
with a single space
+ return s
+-.replace(/\([^)]*\)|[\n\t]/g, ' ')
++.replace(/\([^()]*\)|[\n\t]/g, ' ')
+ .replace(/(\s\s+)/g, ' ')
+ .replace(/^\s\s*/, '')
+ .replace(/\s\s*$/, '');
diff --git a/debian/patches/series b/debian/patches/series
index b59ca1ed..48b9eff0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
CVE-2022-24785.patch
+CVE-2022-31129.patch
Bug#1014888: ITP: libutil-h2o-perl -- module to turn hashrefs into objects with accessors for keys
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org
* Package name: libutil-h2o-perl
Version : 0.18
Upstream Author : Hauke D
* URL : https://metacpan.org/release/Util-H2O
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : module to turn hashrefs into objects with accessors for keys
The Util::H2O module allows you to turn hashrefs into objects, so that
instead of $hash->{key} you can write $hash->key, plus you get protection
from typos. In addition, options are provided that allow you to whip up
really simple classes.
The package will be maintained under the umbrella of the Debian Perl Group.
--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
signature.asc
Description: Digital Signature
Bug#1014874: kicad: FTBFS with opencascade 7.6
Hi Carsten, sorry for the buzz, it seems that I messed up on the opencascade packaging side,at least for that missing include file. I'll keep you updated once I have more information… -- tobi
Bug#1014874: kicad: FTBFS with opencascade 7.6
Hi Carsten, sorry for the buzz, it seems that I messed up on the opencascade packaging side,at least for that missing include file. I'll keep you updated once I have more information… -- tobi
Bug#1014618: tpot: FTBFS in unstable
Control: tags -1 + patch
On Friday, July 08 2022, Steve Langasek wrote:
> Hi Christian,
>
> While trying to get the tpot package built in Ubuntu, I've found that it
> fails to build in both Debian and Ubuntu:
>
> [...]
> ==
> FAIL: Assert that the TPOTClassifier score function outputs a known score for
> a fixed pipeline.
> --
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/tmp/tpot-0.11.7+dfsg/.pybuild/cpython3_3.10_tpot/build/tests/tpot_tests.py",
> line 642, in test_score_2
> assert np.allclose(known_score, score)
> AssertionError
>
> --
> Ran 249 tests in 87.864s
>
> FAILED (SKIP=1, failures=1)
> E: pybuild pybuild:369: test: plugin distutils failed with: exit code=1: cd
> /tmp/tpot-0.11.7+dfsg/.pybuild/cpython3_3.10_tpot/build; python3.10 -m nose
> -v --ignore-files nn_tests.py --exclude test_log_file_verbose_3 --exclude
> test_sample_weight_func
> dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.10" returned
> exit code 13
> [...]
>
> (https://launchpad.net/ubuntu/+source/tpot/0.11.7+dfsg-3/+build/23574118)
>
> I have no insights into the cause of this build regression, sorry!
There's a PR filed upstream that fixes this problem:
https://github.com/EpistasisLab/tpot/pull/1215
I've backported it, and the build now succeeds.
MR: https://salsa.debian.org/science-team/tpot/-/merge_requests/1
Cheers,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/
signature.asc
Description: PGP signature
Bug#1014324: rustc-mozilla 1.59.0+dfsg1-1~deb11u1 flagged for acceptance
package release.debian.org tags 1014324 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: rustc-mozilla Version: 1.59.0+dfsg1-1~deb11u1 Explanation: new upstream version to support building of newer firefox-esr and thunderbird versions
Bug#1014327: cargo-mozilla 0.57.0-7~deb11u1 flagged for acceptance
package release.debian.org tags 1014327 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: cargo-mozilla Version: 0.57.0-7~deb11u1 Explanation: new source package to support building of newer firefox-esr and thunderbird versions
Bug#1014308: llvm-toolchain-13 13.0.1-6~deb11u1 flagged for acceptance
package release.debian.org tags 1014308 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: llvm-toolchain-13 Version: 13.0.1-6~deb11u1 Explanation: new source package to support building of newer firefox-esr and thunderbird versions
Bug#1014326: rust-cbindgen 0.23.0-1~deb11u1 flagged for acceptance
package release.debian.org tags 1014326 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: rust-cbindgen Version: 0.23.0-1~deb11u1 Explanation: new upstream version to support building of newer firefox-esr and thunderbird versions
Bug#1014832: libdecaf: Source-only upload is needed
X-Debbugs-CC: Boyuan Yang On Tue, Jul 12, 2022 at 04:43:07PM -0400, Boyuan Yang wrote: > According to https://tracker.debian.org/pkg/libdecaf , you package needs > another source-only upload to be able to migrate to Debian Testing. Please > consider making another upload. Will that actually fix it? Or will it just break again on the affected platforms due to still-missing cmake, cmake-data and/or libssl1.1? Regards, Dennis.
Bug#1014874: kicad: FTBFS with opencascade 7.6
Hello Seth, Am Wed, Jul 13, 2022 at 05:10:27PM +0200 schrieb Tobias Frost: > Source: kicad > Version: 6.0.6+dfsg-1 > Severity: important > > Dear maintainers, > > I'm currently preparing the opencascade library transition and > KiCAD is FTBFS with opencascade 7.6 > > Once the transition starts, this bug will become RC. > > In file included from /build/kicad-6.0.6+dfsg/plugins/3d/oce/loadmodel.cpp:45: > /usr/include/opencascade/TDocStd_Document.hxx:31:10: fatal error: > TDocStd_FormatVersion.hxx: No such file or directory >31 | #include > | ^~~ > compilation terminated. > > Full build log attached. as I'm not building KiCad constantly anymore and the discussion of KiCad issue has moved mostly into GitLab I'm not up to date if the issue above is already fixed within the current upstream code in the branch 6.0 or what is needed to get cherry-picked into the Debian packaging.. I can see a lot of new commits since the relase of 6.0.6 but I've seen nothing regarding a handling of a bumped version of opencascade 7.6. Any serious tip about how to fix this issue? The full build log that is mentioned above can be found within the issue in tghe Debian BTS. https://bugs.debian.org/1014874 Regards and Thanks! Carsten
Bug#1013896: qtbase-opensource-src: Use KDE Qt as upstream instead of qt.io
On Wed, 13 Jul 2022 21:02:02 +0300 Dmitry Shachnev wrote: > > I expect users to complain if something doesn't work. > > Also note that now we get releases from Qt every couple of months, so sooner > or later we will get most of the patches this way (and it will be easier to > deal with the remaining ones). > Eventually yeah, but it can be a long while because a bunch of these patches are backports from Qt 6 by the KDE team and upstream Qt doesn't bother to backport to 5.x. Shmerl.
Bug#1014829: kerberos-configs: consider setting rdns=false by default
Andreas> According to [1], the upstream implicit default of "rdns = Andreas> true" is there for historical reasons only, and upstream Andreas> suggests to consider setting it to "false": Andreas> """ Consider setting rdns to false in order to reduce your Andreas> dependence on precisely correct DNS information for service Andreas> hostnames. Turning this flag off means that service Andreas> hostnames will be canonicalized through forward name Andreas> resolution (which adds your domain name to unqualified Andreas> hostnames, and resolves CNAME records in DNS), but not Andreas> through reverse address lookup. The default value of this Yeah, this makes sense. Thanks for reporting this. I will try to get to this and getting krb5 1.20 into unstable by end of DebConf. I'm not at the conference, but that's a good time frame to give myself a deadline.
Bug#1013896: qtbase-opensource-src: Use KDE Qt as upstream instead of qt.io
On Mon, Jul 11, 2022 at 04:22:01PM -0400, Shmerl wrote: > I know Wayland Qt patches are critical for stable Plasma experience, > but I'm not an expert on all of these. Wayland patches are applied, as I said. > May be some communication between upstream KDE developers and Debian > team would be good here? Expecting users to know what patches are important > isn't a very reliable method. I expect users to complain if something doesn't work. Also note that now we get releases from Qt every couple of months, so sooner or later we will get most of the patches this way (and it will be easier to deal with the remaining ones). -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1014886: RFP: tvision -- modern port of Turbo Vision, a framework for text-based user interfaces
Package: wnpp Severity: wishlist * Package name: tvision Upstream Author : Borland → magiblot * URL : https://github.com/magiblot/tvision * License : Public Domain → MT Programming Lang: C++ Description : modern port of Turbo Vision, a framework for text-based user interfaces So someone finally did the work to beat Turbo Vision into working on modern platforms, modern compilers, and full-fledged Unicode support. It had been released into Public Domain by Borland/Inprise but ports since then sucked. It'd be great if someone packaged this so we know what its pressure is :p There's also two pieces by same author built atop Turbo Vision: * turbo -- an editor * tvterm -- a widget to put a terminal into a TV window
Bug#1014885: Conflict: unknown-field Go-Import-Path x missing-xs-go-import-path-for-golang-package
Package: lintian Version: 2.115.2 Severity: important X-Debbugs-Cc: eribe...@debian.org Dear Maintainer, When doing a QA revision over the package "gox", I received the warning: W: gox source: unknown-field Go-Import-Path However, the right field name is XS-Go-Import-Path, not Go-Import-Path. The field is present in debian/control on gox: XS-Go-Import-Path: github.com/mitchellh/gox If the XS-Go-Import-Path filed is removed, the following message is shown: I: gox source: missing-xs-go-import-path-for-golang-package The Debian bug #984719 explains how much the XS-Go-Import-Path field is needed. Regards, Eriberto
Bug#1014884: statsmodels: FTBFS on mipsel (pythran shifted tolerances)
Source: statsmodels Version: 0.13.2+dfsg-2 Severity: serious Justification: FTBFS Control: forwarded -1 https://github.com/statsmodels/statsmodels/issues/8341 mipsel is failing to build statsmodels 0.13.2+dfsg-2. Problem seems to be another shift in tolerance requirements triggered by scipy using pythran, similar to Bug#1014278. In this case the discrepancy is mild, gets error 1.12443388e-12, but expects 1e-12. Could be worked around by relaxing the tolerance to 2e-12 The error message is TestGMMStOneiterOLS_Linear.test_basic _ self = def test_basic(self): res1, res2 = self.res1, self.res2 # test both absolute and relative difference rtol, atol = self.params_tol assert_allclose(res1.params, res2.params, rtol=rtol, atol=0) > assert_allclose(res1.params, res2.params, rtol=0, atol=atol) E AssertionError: E Not equal to tolerance rtol=0, atol=1e-12 E E Mismatched elements: 1 / 13 (7.69%) E Max absolute difference: 1.12443388e-12 E Max relative difference: 1.53607078e-12 Ex: array([ 6.195478e-02, 2.712120e-03, 3.083947e-02, 4.216306e-02, E -9.629347e-02, 1.328993e-01, -5.420948e-02, 8.058085e-02, E 2.075915e-01, 2.282237e-01, 2.226915e-01, 3.228747e-01, E 4.235357e+00]) Ey: array([ 6.195478e-02, 2.712120e-03, 3.083947e-02, 4.216306e-02, E -9.629347e-02, 1.328993e-01, -5.420948e-02, 8.058085e-02, E 2.075915e-01, 2.282237e-01, 2.226915e-01, 3.228747e-01, E 4.235357e+00]) ../.pybuild/cpython3_3.10_statsmodels/build/statsmodels/sandbox/regression/tests/test_gmm.py:207: AssertionError
Bug#1014883: RFP: Rambox -- all-in-one workspace organizer (Electron Based)
Package: wnpp Severity: wishlist * Package name : Rambox (or Rambox App) Version : 2.0.6 * URL : https://github.com/ramboxapp/download (it has the source code in this repository, and also a .deb package that works with debian perfectly) * License : GPL Description : Electron based workspace simplifier Rambox is an application to organise different Web-based apps like discord or slack into one single Electron application. It would be a very good addition to debian since there is no package like it on the repositories, and there is a clear demand for these kind of apps. (They claim they have at least 80K users)
Bug#1014865: [Pkg-raspi-maintainers] Bug#1014865: raspi-firmware dependencies
On woensdag 13 juli 2022 15:41:25 CEST Jiri Kastner wrote: > raspi-firmware should depend on following packages: > - firmware-brcm80211 > - firmware-misc-nonfree > - bluez-firmware I'd object to the use (and implementation) of the word 'depend'. A recommends or suggests seems more appropriate. signature.asc Description: This is a digitally signed message part.
Bug#948712: [Pkg-raspi-maintainers] Bug#948712: Bug#948712: Pinebook Pro also uses this chip
On woensdag 13 juli 2022 09:58:29 CEST Ben Hutchings wrote: > > > Is this about the /lib/firmware/brcm/brcmfmac434* files? > > So long as those files are in linux-firmware.git, it should be fine to > ship them in firmware-brcm80211. If they aren't, they should be added > there first. https://github.com/raspberrypi/linux/issues/4723 seems relevant. I didn't dive into it too much, but AFAICT you need to convince the RPi folks to upstream those files. Good luck with that! signature.asc Description: This is a digitally signed message part.
Bug#1014878: gtk4: FTBFS with nocheck profile; python3-gi missing from build-deps
Control: patch -1 On Wed, 13 Jul 2022 18:17:27 +0200 Evangelos Ribeiro Tzaras wrote: > Source: gtk4 > Version: 4.6.5+ds-1pureos2 > Severity: normal > > Dear Maintainer, > > while building gtk4 in PureOS (hence the -) we ran into a FTBFS when using nocheck: > python3-gi is missing when building with nocheck, see: > > ../../../testsuite/introspection/meson.build:1:0: ERROR: python3 is missing modules: gi > > from > https://lists.community.puri.sm/pipermail/librem5-builds/2022-July/003824.html > > Patch attached -- Cheers, Evangelos PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19 diff --git a/debian/control.in b/debian/control.in index 4b611f9352..6be477143f 100644 --- a/debian/control.in +++ b/debian/control.in @@ -63,7 +63,7 @@ Build-Depends: adwaita-icon-theme , meson (>= 0.59), pkg-config, python3-docutils , - python3-gi (>= 3.40) , + python3-gi (>= 3.40), sassc, ttf-bitstream-vera , wayland-protocols (>= 1.23) [linux-any],
Bug#1014882: RM: faulthandler -- RoQA; Dangling Cruft in Experimental
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear Debian FTP Masters, Please remove faulthandler/3.1-1 ( https://tracker.debian.org/pkg/faulthandler ) from Debian Experimental. It is a python2-only package and nowadays completely useless. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1014866: freecad: FTBFS with opencascade 7.6
This could be actually a packaging problem in opencascade -- I'm currently investigating and will update ASAP. -- tobi
Bug#1003225: on resume, tries to openat() mountpoint of remote nfs mounts that are not yet available, thus delaying network configuration
On Mon, Jul 11, 2022 at 10:47:26AM +0300, Martin-Éric Racine wrote: > On Thu, 6 Jan 2022 18:38:47 +0100 Michael Biebl wrote: > > On 06.01.22 17:26, Andras Korn wrote: > > > Package: systemd-timesyncd > > > Version: 249.7-1 > > > Severity: normal > > > Tags: upstream > > > > > > Hi, > > > > > > I noticed that it took a while for the network to become available after > > > my > > > laptop wakes up from suspend. > > > > > > I traced the problem to systemd-timesyncd. > > > > > > I use dhcpcd5, which ships /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf, > which > > > contains the line "systemctl try-restart systemd-timesyncd.service || :". > > > > That file is not shipped by systemd. Why does it restart timesyncd? > > Why does it so blockingly? Why does it restart timesyncd when the > > network is still down? > > This is dhcpcd's attempt at adding the NTP servers received via DHCP options > to > timesyncd's configuration and restarting timesyncd to use them. This should > only happen once the network has been raised, though, since this is an exit > hook. Is there any particular reason you can't invoke systemctl with --no-block here? András -- Buy an atlas and see the world.
Bug#1014881: ITP: libsyntax-keyword-multisub-perl -- multiple subroutine dispatch syntax extension
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libsyntax-keyword-multisub-perl Version : 0.02 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Syntax-Keyword-MultiSub * License : Artistic or GPL-1+ Programming Lang: Perl Description : multiple subroutine dispatch syntax extension Syntax::Keyword::MultiSub provides a new keyword, multi, to put before subroutine declarations, which permits multiple distinct function bodies to be provided, which take different parameters. A call to a multi sub will invoke whichever function body best fits the arguments passed. Currently this module can only make dispatching decisions based on the number of arguments as compared to the number of signature parameters each body was expecting. It requires perl version 5.26 or above, in order to get enough support from signatures. Note also enabling this module does not enable the signatures feature; you must do that independently. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1014879: Please do not depend on gnome-remote-desktop
Package: gnome-control-center Version: 1:42.3-1 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org gnome-control-center 1:42.3-1 adds a dependency on gnome-remote-desktop, a daemon for remote desktop sharing. I'd like to avoid installing that on my system, for the same reason I avoid installing even an inert sshd: avoiding mistakes where it could end up running unexpectedly. I appreciate that gnome *metapackages* aren't designed for people to pick-and-choose components, and I would understand if a gnome metapackage had this dependency (though I'd really appreciate it if it did not have a hard dependency). But gnome-control-center is not a metapackage; it's a concrete package containing one of the core required components of a GNOME desktop. I'd appreciate it if it didn't have a hard dependency on gnome-remote-desktop.
Bug#1014431: popularity-contest: automatically create hostid if not specified in popularity-contest.conf
On Wed, Jul 06, 2022 at 12:05:49AM +0200, Ansgar wrote: > Package: popularity-contest > Version: 1.73 > Severity: wishlist > > It would be nice if it was not required to have host-specific data in > the configuration file (MY_HOSTID). > If no MY_HOSTID is specified, popularity-contest could for example > generate an application-specific MY_HOSTID from the machine-id as > described for libsystemd's `sd_id128_get_machine_app_specific` > function (i.e., HMAC-SHA256 of a application ID for > popularity-contents keyed by the machine-id). Hello Ansgar, What is the life cycle of the machine-id ? How would that work while fulfilling all the goal of MY_HOSTID ? What would be the advantage ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory
Am 12.07.22 um 20:54 schrieb Salvatore Bonaccorso: personally i would prefer if we can do it a regular kernel-team upload, there were some other changes pending. Will ping Ben on IRC to ask. Otherwise I guess the NMU is fine. I've seen the upload. Thank you both! OpenPGP_signature Description: OpenPGP digital signature
Bug#1014880: sftp_readdir_async: Assertion `offset == 0' failed on OPENDIR when mounted through nfs
Package: sshfs Version: 3.7.1+repack-2 Severity: grave Justification: renders package unusable Given the following setup: - remote directory mounted to /mnt/incoming on server using the following options: sshfs -d --debug librarian@archive:/mnt/incoming /mnt/incoming -o rw,delay_connect,transform_symlinks,idmap=user,allow_other,uid=1011,gid=1011,identityfile=/home/librarian/.ssh/id_rsa,dev,suid,dir_cache=no - /mnt/incoming bind-mounted to /srv/nfs/incoming - /srv/nfs/incoming exported through nfsv4 - /srv/nfs/incoming nfsv4-mounted on workstation on /net/media/incoming Listing the contents of /mnt/incoming or the bind-mounted version on /srv/nfs/incoming works without problems, as does accessing files residing in these directories. Attempting to access the nfs-exported version of this filesystem from a workstation leads to sshfs aborting with the following assertion: [00035] OPENDIR [00035] HANDLE 17bytes (0ms) unique: 66, success, outsize: 32 unique: 68, opcode: READDIRPLUS (44), nodeid: 1, insize: 80, pid: 0 sshfs: ../sshfs.c:2216: sftp_readdir_async: Assertion `offset == 0' failed. Aborted When mounted with the directory cache enabled (dir_cache=yes) this assertion occurs in cache_readdir instead. -- System Information: Debian Release: 11.4 APT prefers stable APT policy: (700, 'stable'), (600, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.39-1-pve (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sshfs depends on: ii fuse3 3.10.3-2 ii libc6 2.31-13+deb11u3 ii libfuse3-3 3.10.3-2 ii libglib2.0-02.66.8-1 ii openssh-client 1:8.4p1-5+deb11u1 sshfs recommends no packages. sshfs suggests no packages. -- no debconf information
Bug#1014878: gtk4: FTBFS with nocheck profile; python3-gi missing from build-deps
Source: gtk4 Version: 4.6.5+ds-1pureos2 Severity: normal Dear Maintainer, while building gtk4 in PureOS (hence the -) we ran into a FTBFS when using nocheck: python3-gi is missing when building with nocheck, see: ../../../testsuite/introspection/meson.build:1:0: ERROR: python3 is missing modules: gi from https://lists.community.puri.sm/pipermail/librem5-builds/2022-July/003824.html -- System Information: Debian Release: bookworm/sid APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#989462: Info received (About bumping Vagrant box disk image to 1TB)
Thanks for mapping it out. Do you have any contact to upstream? If so, could you request the new release? I can update the package. Emmanuel Kasper: Hi I took some time to revisit this bug in regards to vagrant libvirt developments. I see vagrant-libvirt upstream has merged in virtio-scsi support, which we needed for discard (https://github.com/vagrant-libvirt/vagrant-libvirt/pull/692/commits) So the next steps should be: - upstream to release a new version of libvirt with virtio-scsi support - Debian to package it - change the libvirt vagrant box to use virtio-scsi. It should be enough to set the disk bus to scsi then vagrant-libvirt will set the controller type to virtio-iscsi by default - add the `discard` option so that deleted disk blocks in the VM are also deleted in the file disk image - finally bump the disk image size in the build process
Bug#1014872: Failure to load kernel modules at boot time
Control: tags -1 + moreinfo On Wed, 13 Jul 2022 16:59:50 +0200 Eduardo Casais wrote: Package: systemd Version: 247.3-7 Dear Maintainers, At boot time, linux produces a series of error messages stating that a kernel module cannot be loaded. Inspecting the output of journalctl, I find the following lines: Jun 29 16:53:25 AREPPIM001 systemd-modules-load[218]: Failed to insert module 'firewire_sbp2': Key was rejected by service systemd-modules-load is only the messenger here, not the cause. What happens if you try to load the module manually via modprobe/insmod? What kernel are your using (hint: please use reportbug next time so this information is added automatically). I don't see this kernel module being shipped by the official Debian kernel. Have you manually set up your system to load the firewire_sbp2 module? This is not the default configuration. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1014876: Please make it possible to override /etc/tmpreaper.conf from a user configfile
Package: tmpreaper Version: 1.6.17 Severity: wishlist Hi, I think you should add something like [ -r /etc/default/tmpreaper ] && . /etc/default/tmpreaper at the bottom of /etc/tmpreaper.conf. Currently, every upgrade that adds some new setting to tmpreaper.conf requires the user to re-edit the file if they had modified it -- either to re-add SHOWWARNING=false, or to add the new option (in the most recent case, RUNFROMCRON=true) to it. I happen to want to set SHOWWARNING=false AND RUNFROMCRON=true, and the suggested modification would make my life easier without, I think, breaking anything. Thanks András -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (350, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.15 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages tmpreaper depends on: ii debconf [debconf-2.0] 1.5.79 ii libc6 2.33-7 ii libmount1 2.38-4devuan1 tmpreaper recommends no packages. tmpreaper suggests no packages. -- Configuration Files: /etc/tmpreaper.conf changed [not included] -- debconf information excluded -- Healthy people live longer - but they spend more time jogging.
Bug#640651: please set default FIRST_SYSTEM_UID=1 and FIRST_SYSTEM_GID=1
Control: tags -1 - help + wontfix Control: outlook -1 wontfix thanks On Tue, Mar 08, 2022 at 09:07:53AM +0100, Marc Haber wrote: > There have been only two people requesting this functionality in over a > decade. Making these settings preseedable would mean that adduser.conf > could no longer be a conffile, which means that a lot of error-prione > code is needed to handle local changes to the file. The adduser maintainers have decided to remove debconf from adduser. Therefore, no more work is going to go into this bugreport. Hence, wontfix. Greetings Marc
Bug#1014875: freecad: FTBFS on armel and armhf: error: ‘GL_PROJECTION’ was not declared in this scope;
Package: freecad Version: 0.20+dfsg1-2 Severity: serious Tags: ftbfs Justification: FTBFS Freecad FTBFS on the buildds, see https://buildd.debian.org/status/package.php?p=freecad build logs indicate this error: cd /<>/debian/build-py3/src/Mod/Fem/App && /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DFC_USE_VTK -DFem_EXPORTS -DH5_BUILT_AS_DYNAMIC_LIB -DHAVE_CONFIG_H -DHAVE_LIMITS_H -DMPICH_SKIP_MPICXX -DMPI_NO_CPPBIND -DOMPI_SKIP_MPICXX -DQT_CORE_LIB -DQT_NO_DEBUG -DQT_XML_LIB -D_FILE_OFFSET_BITS=64 -D_MPICC_H -Dkiss_fft_scalar=double -I/<>/debian/build-py3/src/Mod/Fem/App/Fem_autogen/include -I/<>/debian/build-py3 -I/<>/debian/build-py3/src -I/<>/src -I/<>/debian/build-py3/src/Mod/Fem/App -I/usr/include/opencascade -I/<>/src/3rdParty/salomesmesh/inc -isystem /usr/include/arm-linux-gnueabihf/qt5 -isystem /usr/include/arm-linux-gnueabihf/qt5/QtCore -isystem /usr/lib/arm-linux-gnueabihf/qt5/mkspecs/linux-g++ -isystem /usr/include/arm-linux-gnueabihf/qt5/QtXml -isystem /usr/include/vtk-9.1 -isystem /usr/include/jsoncpp -isystem /usr/lib/arm-linux-gnueabihf/openmpi/include -isystem /usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi -isystem /usr/include/hdf5/serial -isystem /usr/include/freetype2 -Wall -Wextra -Wno-write-strings -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -fpermissive -I/usr/include/python3.10 -flto -Wno-overloaded-virtual -O2 -g -DNDEBUG -fPIC -pthread -I/usr/include/hdf5/openmpi -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi -Wno-pedantic -fPIC -fopenmp -std=gnu++17 -MD -MT src/Mod/Fem/App/CMakeFiles/Fem.dir/FemSetElementsObject.cpp.o -MF CMakeFiles/Fem.dir/FemSetElementsObject.cpp.o.d -o CMakeFiles/Fem.dir/FemSetElementsObject.cpp.o -c /<>/src/Mod/Fem/App/FemSetElementsObject.cpp /<>/src/Gui/Quarter/QuarterWidget.cpp: In member function ‘virtual void SIM::Coin3D::Quarter::QuarterWidget::paintEvent(QPaintEvent*)’: /<>/src/Gui/Quarter/QuarterWidget.cpp:869:18: error: ‘GL_PROJECTION’ was not declared in this scope; did you mean ‘GL_LOCATION’? 869 | glMatrixMode(GL_PROJECTION); | ^ | GL_LOCATION /<>/src/Gui/Quarter/QuarterWidget.cpp:869:5: error: ‘glMatrixMode’ was not declared in this scope 869 | glMatrixMode(GL_PROJECTION); | ^~~~ /<>/src/Gui/Quarter/QuarterWidget.cpp:910:5: error: ‘glPushAttrib’ was not declared in this scope 910 | glPushAttrib(GL_MULTISAMPLE_BIT_EXT); | ^~~~ /<>/src/Gui/Quarter/QuarterWidget.cpp:912:5: error: ‘glPopAttrib’ was not declared in this scope 912 | glPopAttrib(); | ^~~ -- tobi -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 freecad depends on: ii freecad-python3 0.20+dfsg1-2 Versions of packages freecad recommends: ii calculix-ccx 2.19-1 ii graphviz 2.42.2-7 Versions of packages freecad suggests: pn povray -- no debconf information
Bug#520037: adduser: could --force-badname permit non-ASCII usernames?
Adduser 3.122 will include a major rework of the check name infrastructure including a new --allow-all-names option that allows all user and group names that useradd will allow. This bug will close with the 3.122 upload. Please feel free to reopen this bug with an explanation why the changes do not reflect your intention. Greetings Marc
Bug#774046: [adduser] weak username check provided by --force-badname does not match useradd capability
Adduser 3.122 will include a major rework of the check name infrastructure including a new --allow-all-names option that allows all user and group names that useradd will allow. This bug will close with the 3.122 upload. Please feel free to reopen this bug with an explanation why the changes do not reflect your intention. Greetings Marc
Bug#440801: adduser: Option --firstuid no longer applied to GID's of new users' user
On Tue, Mar 08, 2022 at 05:10:38PM +0100, Marc Haber wrote: > I do not particularly like the idea of overloading the first_U_id > option. Would it help you to have firstgid and lastgid options? --firstgid and --lastgid will be implemented soon. until nobody objects, I'll consider this change fixing this bug, and will close it with the upload. Greetings Marc
Bug#398802: Preseeding adduser/homedir-permission doesn't appear to work
Control: tags -1 wontfix thanks Hi, On Wed, Nov 15, 2006 at 05:21:38PM +0100, Olaf van der Spek wrote: > I've put "adduser adduser/homedir-permission boolean false" in > preseed.cfg, but /etc/adduser.conf contains "DIR_MODE=0755". > The preseed entry appears to be ignored. the adduser maintainers have decided to remove Debconf support, therefore preseeding will no longer be possible. The advice is to disable account generation in debian-installer and create the user account after installation. Greetings Marc
Bug#1014872: Failure to load kernel modules at boot time
Package: systemd Version: 247.3-7 Dear Maintainers, At boot time, linux produces a series of error messages stating that a kernel module cannot be loaded. Inspecting the output of journalctl, I find the following lines: Jun 29 16:53:25 AREPPIM001 systemd-modules-load[218]: Failed to insert module 'firewire_sbp2': Key was rejected by service Jun 29 16:53:25 AREPPIM001 systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE Jun 29 16:53:25 AREPPIM001 systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. Jun 29 16:53:25 AREPPIM001 systemd[1]: Failed to start Load Kernel Modules. Jun 29 16:53:30 AREPPIM001 systemd-modules-load[442]: Failed to insert module 'firewire_sbp2': Key was rejected by service Jun 29 16:53:30 AREPPIM001 systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE Jun 29 16:53:30 AREPPIM001 systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. Jun 29 16:53:30 AREPPIM001 systemd[1]: Failed to start Load Kernel Modules. Jun 29 16:53:35 AREPPIM001 systemd-modules-load[458]: Failed to insert module 'firewire_sbp2': Key was rejected by service Jun 29 16:53:35 AREPPIM001 systemd-fsck[456]: /dev/sda7: clean, 10088/720896 files, 376406/2880512 blocks Jun 29 16:53:35 AREPPIM001 systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE Jun 29 16:53:35 AREPPIM001 systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. Jun 29 16:53:35 AREPPIM001 systemd[1]: Failed to start Load Kernel Modules. All three attempts at loading the module firewire_sbp2 take place during the same boot sequence. The error was definitely introduced by Bullseye / Debian 11, since the same machine under Buster / Debian 10 did not exhibit this behaviour: Jun 21 16:06:42 AREPPIM001 kernel: firewire_ohci :02:01.1: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x2 ... Jun 21 16:06:42 AREPPIM001 kernel: firewire_core :02:01.1: created device fw0: GUID 314fc000300d2430, S400 ... Jun 21 16:06:42 AREPPIM001 systemd-modules-load[204]: Inserted module 'firewire_sbp2' The machine is running Linux 5.10.0-15-686-pae #1 SMP Debian 5.10.120-1 (2022-06-09) i686 GNU/Linux. Note: A previous version of this message was already sent which erroneously specified "system2" as the package affected. Sincerely Eduardo Casais
Bug#1014814: [Pkg-privacy-maintainers] Bug#1014814: ITP: onionprobe -- test/monitor tool for Tor Onion Services sites
Control: tags -1 + pending Packaging lives at [1], initial upload done, now in NEW. Cheers, Georg [1] https://salsa.debian.org/pkg-privacy-team/onionprobe
Bug#1014837: distro-info-data: update ELTS data
Hi, On Tue, 12 Jul 2022, Thorsten Glaser wrote: > 10 Busterbuster2017-06-17 2019-07-06 2022-08-14 > 2024-06-30 2026-06-30 > 11 Bullseye bullseye 2019-07-06 2021-08-14 2024-08-14 > > However, ELTS support got prolonged: see > https://deb.freexian.com/extended-lts/docs/debian-8-support/ and > https://deb.freexian.com/extended-lts/docs/debian-9-support/ for more. > > change jessie eol-elts to 2025-06-30 > change stretch eol-elts to 2027-06-30 > > We don’t know about buster ELTS yet, nor if the other LTS data changed, > but Raphaël would know ☻ For buster, the dates are well aligned with the half-year so we will continue with end of LTS as already documented (2024-06-30) and end of ELTS will be 2029-06-30 (~10 years of support). For bullseye, things are not defined yet. Cheers, -- Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47 https://www.freexian.com
Bug#1014871: reportbug: is being confusing with the -r option
Package: reportbug Version: 11.5.0 Severity: normal after submitting a bug failed, i changed my mta config, and subsequently ran "reportbug -r /tmp/reportbug-..." as instructed. as the mail was already in its final state, i immediately exited the editor, which lead to this weird interaction: No changes were made in the editor. Report will be sent to Debian Bug Tracking System Submit this report on reportbug (e to edit) [y|n|a|c|E|i|l|m|p|q|d|t|?]? y Report is unchanged. Edit this report or quit [E|q|s|?]? s Sending empty report anyway... Sending message via /usr/sbin/sendmail... firstly, in the given case it's rather pointless (and therefore confusing) to say that the report is unchanged. to give an accurate account, it would have to create a pristine report template from scratch and compare the contents. secondly, it says "sending empty report", which would be confusing even if this wasn't a perfectly finalized report, as it actually means "sending unmodified generated report" or some such. -- Package-specific info: ** Environment settings: EDITOR="sensible-editor" PAGER="sensible-pager" EMAIL="Oswald Buddenhagen " INTERFACE="text" ** /home/ossi/.reportbugrc: reportbug_version "2.3" mode advanced ui text no-cc -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt2.5.1 ii python33.10.4-1+b1 ii python3-reportbug 11.5.0 ii sensible-utils 0.0.17 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.79 ii debsums 3.0.2 pn dlocate pn emacs-bin-common ii file 1:5.41-4 ii gnupg2.2.35-3 ii masqmail [mail-transport-agent] 0.3.4-1 ii python3-urwid2.1.2-2+b1 pn reportbug-gtk ii xdg-utils1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.5.1 ii file 1:5.41-4 ii python33.10.4-1+b1 ii python3-apt2.3.0+b1 ii python3-debian 0.1.44 ii python3-debianbts 3.2.3 ii python3-requests 2.27.1+dfsg-1 ii sensible-utils 0.0.17 python3-reportbug suggests no packages. -- Configuration Files: /etc/reportbug.conf changed: submit query-bts check-available cc config-files compress verify -- no debconf information
Bug#1014870: perlrdf: Source-only upload is needed
Source: perlrdf Version: 0.004-3 Severity: important X-Debbugs-CC: d...@jones.dk Dear Debian perlrdf package maintainer, According to https://tracker.debian.org/pkg/perlrdf , your package needs another source-only upload to be able to migrate to Debian Testing. Please consider making another package upload to solve this problem. Thanks! Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1014869: reportbug: support calling sendmail without envelope address
Package: reportbug Version: 11.5.0 Severity: wishlist sendmail just rejected to send my report, because the current user didn't have permission to set a return address. this is actually quite expected, and using the sendmail -f option is rather unusual. i suggest not doing that by default, or at least allowing the envelopefrom option being empty (note: i didn't check whether that's already the case - but the reportbug.conf manual does not mention it). -- Package-specific info: ** Environment settings: EDITOR="sensible-editor" PAGER="sensible-pager" EMAIL="Oswald Buddenhagen " INTERFACE="text" ** /home/ossi/.reportbugrc: reportbug_version "2.3" mode advanced ui text no-cc -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt2.5.1 ii python33.10.4-1+b1 ii python3-reportbug 11.5.0 ii sensible-utils 0.0.17 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.79 ii debsums 3.0.2 pn dlocate pn emacs-bin-common ii file 1:5.41-4 ii gnupg2.2.35-3 ii masqmail [mail-transport-agent] 0.3.4-1 ii python3-urwid2.1.2-2+b1 pn reportbug-gtk ii xdg-utils1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.5.1 ii file 1:5.41-4 ii python33.10.4-1+b1 ii python3-apt2.3.0+b1 ii python3-debian 0.1.44 ii python3-debianbts 3.2.3 ii python3-requests 2.27.1+dfsg-1 ii sensible-utils 0.0.17 python3-reportbug suggests no packages. -- Configuration Files: /etc/reportbug.conf changed: submit query-bts check-available cc config-files compress verify -- no debconf information
Bug#1014868: python3-pyaudio: needs patch for python 3.10
Package: python3-pyaudio Version: 0.2.11-1.4 Severity: normal pyaudio started throwing this message: SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats https://stackoverflow.com/questions/70344884/pyaudio-write-systemerror-py-ssize-t-clean-macro-must-be-defined-for-format explains it and links to a solution (https://git.skeh.site/skeh/pyaudio/commit/2ee560056ec889ea7cd3ce1801b796b0939dd540). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pyaudio depends on: ii libc6 2.33-7 ii libportaudio2 19.6.0-1.2 ii python33.10.4-1+b1 python3-pyaudio recommends no packages. Versions of packages python3-pyaudio suggests: pn python-pyaudio-doc -- no debconf information
Bug#57280: Reassign this bug
Control: tags -1 wontfix thanks On Sat, Oct 08, 2005 at 12:39:29PM +0200, Marc Haber wrote: > On Fri, Oct 07, 2005 at 02:31:40PM +0200, Christian Perrier wrote: > > The analysis of this bug report shows that the user reporting it wants > > to have the choice, possibly during an initial install, to either use > > user groups or add all users to the default "users" group. > > > > passwd, while reconfigured, relies on adduser for this. One solution > > could be a debconf-based configurable option to either use "users" > > groups or the "users" group by default with adduser. > > > > I would give a quite low priority to this. After all, the creation of > > a first user can be skipped in new installs... > > This is opening a can of worms which might lead to the requirement of > having all adduser.conf options be settable through debconf. I'd > rather not do this with the current adduser stuff and leave that to > the rewrite which is necessary anyway. Tagging this wontfix. The adduser maintainers have decided to deprecate and eventually remove the debconf part from adduser, hence there will be no work going into this. Greetings Marc
Bug#290623: adduser should never use "nogroup" as a user's group
Control: Severity -1 wishlist
On Sun, Sep 02, 2007 at 05:27:29PM +0200, Joerg Hoh wrote:
> On Sun, Jun 24, 2007 at 11:56:31AM +0200, Joerg Hoh wrote:
> >
> > In my opinion any package who wants to use an unprivileged user ("nouser")
> > or
> > group ("nogroup") should create a separate user for that usage (see the
> > www-data user for httpd). In any other way there maybe conflicts/security
> > implications when 2 processes are there with with privileges dropped and
> > now
> > using "nouser:nogroup".
>
> I'll tag it as wontfix.
I think that in absence of advice from Policy, base-passwd sets the way
to go for this. And this is
(/usr/share/doc/base-passwd/users-and-groups.txt.gz):
nobody, nogroup
Daemons that need not own any files sometimes run as
user nobody and group nogroup, although using a
dedicated user is far preferable. Thus, no files on a
system should be owned by this user or group.
Since adduser is not in the situation to tell a package maintainer what
to do, nogroup is still the valid default that saves GID resources
instead of changing the default to "usergroups" for system users. This
was "discussed" on debian-devel in July 2022,
https://lists.debian.org/debian-devel/2022/07/msg00027.html, with not
much interest from the developer community. I'd take that as consent of
the project that the current default is fine and that we should not
change it just for the sake of changing it.
I'm open to more and new arguments and I would also accept advice from
the Technical Committee in this matter, but for the time being this is
going to stay at wontfix.
Greetings
Marc
Bug#1014867: wolfssl: Update to latest upstream version
Source: wolfssl Version: 5.2.0-2 Severity: important Hi, Please update to the latest wolfssl upstream release which is 5.4.0 currently. 5.3.0 was not released to the Debian archive at all. Thanks for maintaining wolfssl, Bastian
Bug#1013801: gopsutil and slinkwatch/ifplugo
fixed 1013801 golang-github-satta-ifplugo/0.0~git20200508.ca679be-6 reassign 1013818 golang-github-satta-ifplugo fixed 1013818 golang-github-satta-ifplugo/0.0~git20200508.ca679be-6 thanks Setting these bugs to fixed. * golang-github-satta-ifplugo is ready for gopsutil v3. * slinkwatch does not need to depend on gopsutil at all; it uses golang-github-satta-ifplugo, which until the latest version did not state a dependency in its -dev package on gopsutil to be pulled in transitively in the slinkwatch build. Will upload a version of the slinkwatch package that drops the gopsutil dependency altogether soon. Cheers Sascha OpenPGP_signature Description: OpenPGP digital signature
Bug#1014865: raspi-firmware dependencies
Package: raspi-firmware Version: 1.20220331+ds-2 Severity: normal Tags: d-i raspi-firmware should depend on following packages: - firmware-brcm80211 - firmware-misc-nonfree - bluez-firmware all packages above provide /lib/firmware/brcm files bluez-firmware is needed to use bluetooth (tested with zero v2) -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.18.0-2-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages raspi-firmware depends on: ii dosfstools 4.2-1 ii dpkg1.21.9 raspi-firmware recommends no packages. raspi-firmware suggests no packages. -- Configuration Files: /etc/default/raspi-firmware changed: ROOTPART=LABEL=RASPIROOT -- no debconf information
Bug#1014860: buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u1
On 13/07/2022 12:55, Emilio Pozuelo Monfort wrote: debdiff attached. Now for real (thanks Paul). Cheers, Emiliodiff -Nru llvm-toolchain-13-13.0.1/debian/changelog llvm-toolchain-13-13.0.1/debian/changelog --- llvm-toolchain-13-13.0.1/debian/changelog 2022-06-16 12:00:08.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/changelog 2022-07-06 16:28:45.0 +0200 @@ -1,3 +1,11 @@ +llvm-toolchain-13 (1:13.0.1-6~deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * Backport to buster. + * Don't install libclang grpc proto libs, they are not built in buster. + + -- Emilio Pozuelo Monfort Wed, 06 Jul 2022 16:28:45 +0200 + llvm-toolchain-13 (1:13.0.1-6~deb11u1) bullseye; urgency=medium * Non-maintainer upload. diff -Nru llvm-toolchain-13-13.0.1/debian/libclang-X.Y-dev.install.in llvm-toolchain-13-13.0.1/debian/libclang-X.Y-dev.install.in --- llvm-toolchain-13-13.0.1/debian/libclang-X.Y-dev.install.in 2022-06-04 15:29:01.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/libclang-X.Y-dev.install.in 2022-07-06 16:28:17.0 +0200 @@ -7,8 +7,3 @@ usr/lib/llvm-@LLVM_VERSION@/lib/libclang.so usr/lib/llvm-@LLVM_VERSION@/lib/libclang-@LLVM_VERSION@*.so usr/lib/llvm-@LLVM_VERSION@/lib/libfindAllSymbols.a - -# clangd grpc architectures -[amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] usr/lib/llvm-@LLVM_VERSION@/lib/libRemoteIndexProto.a -[amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] usr/lib/llvm-@LLVM_VERSION@/lib/libRemoteIndexServiceProto.a -[amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] usr/lib/llvm-@LLVM_VERSION@/lib/libMonitoringServiceProto.a
Bug#1014864: distinguish between root and postmaster aliases
Package: opensmtpd Version: 6.8.0p2-3 I have to distinguish between root and postmaster EMails on my servers, so the common option Root and postmaster mail recipient: in the installation menu for opensmtpd (and others) is not help- ful. I have to manually fix this again and again. Would it be possible to focus on the postmaster alias and ignore the root alias? Thank you very much Harri
Bug#1014863: ITP: python-aiormq -- pure Python AMQP client library (Python 3)
Package: wnpp Severity: wishlist Owner: Guilherme de Paula Xavier Segundo X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com * Package name: python-aiormq Version : 6.3.4 Upstream Author : Dmitry Orlov * URL : https://github.com/mosquito/aiormq * License : Apache-2.0 Programming Lang: Python Description : pure Python AMQP client library (Python 3) This program is a pure Python AMQP 0.9.1 asynchronous client library. . Features: Connecting by URL. Buffered queue for received frames. Only PLAIN auth mechanism support. Publisher confirms support. Transactions support. Channel based asynchronous locks. Tracking unroutable messages. Full SSL/TLS support. Python type hints. Uses pamqp as an AMQP 0.9.1 frame encoder/decoder. . This package installs the library for Python 3. It will be maintained within the Debian Python Team.
Bug#1014862: vdr-plugin-markad: FTBFS: Cannot find (any matches for) "command/markad"
Source: vdr-plugin-markad Version: 0.1.4+git20180120-3 Severity: serious Tags: ftbfs Justification: fails to build from source Hi, vdr-plugin-markad recently started to FTBFS: [...] debian/rules override_dh_auto_install make[1]: Entering directory '/build/vdr-plugin-markad-0.1.4+git20180120' # Do nothing make[1]: Leaving directory '/build/vdr-plugin-markad-0.1.4+git20180120' dh_install dh_install: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_install: warning: Cannot find (any matches for) "command/markad" (tried in ., debian/tmp) dh_install: warning: vdr-markad missing files: command/markad dh_install: error: missing files, aborting make: *** [debian/rules:10: binary] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 Andreas vdr-plugin-markad_0.1.4+git20180120-3.log.gz Description: application/gzip
Bug#1014675: thunderbird: Upgrade breaks NNTP
Today's unstable update to 102.0.2-1 breaks NNTP completely for me. Reading the upstream bug link, I tried to disable master password, then it was somehow able to connect to one server, but never to others (I have 3 NNTP accounts in my profile). So this is a quite major regression... Milan
Bug#1014860: buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-llvm-t...@lists.alioth.debian.org This backports LLVM 13 to buster, for Firefox/Thunderbird ESR 102. The changes from the bullseye backport are minimal, debdiff attached. I have already uploaded the package, but let me know if you have any comments. Cheers, Emilio
Bug#1013236: atop should not listen on 0.0.0.0 by default
On Sun, Jun 19, 2022 at 05:18:58PM +, Witold Baryluk wrote:
> $ sudo ss -lnp | awk '$5 ~ /\[::\]|0\.0\.0\.0:|\*:/ { print $0; }' | grep atop
> ??? UNCONN 0 0 0.0.0.0:255
>0.0.0.0:*users:(("atop",pid=2185,fd=3))
> $
Interesting, that does not show up in netstat -tulpen. Please note that
ss -nlp shows an actually listening socket with a protocol:
udpUNCONN 00
[::]:5355 [::]:*
users:(("systemd-resolve",pid=1070,fd=13))
tcpLISTEN 020
127.0.0.1:5870.0.0.0:*
users:(("exim4",pid=2123,fd=4))
While the "listening" socket reported by ss has "???" as a protocol.
According to strace, atop's fd 4 is opened to read from /sys/devices/virtual/net
Is it possible that ss is misdetecting this?
What syscalls should I be grepping for in atop's sources?
Greetings
Marc
Bug#851875: atop not installable if process accounting is stopped
On Tue, Jan 26, 2021 at 08:25:24AM +0100, Marc Haber wrote: > can you verify that this issue still applies to the current version of > atop, 2.6.0? I would appreciate that. No answer in 18 months. I intend to close this by the End of August 2022. Greetings Marc
Bug#1014859: lintian: coloured background can be horrible depending on the colour scheme
Package: lintian Version: 2.115.2 Severity: minor Starting with… 2.115 I believe, lintian emits tag names with a white font and coloured background. The resulting rendering is very dependent on the terminal and colour palette the user is using, and for me the yellow and green background renders with a very poor contrast making them unreadable. See the attached screenshot for an example. -- 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#1014793: linux-image-5.10.0-16-amd64: Kernel crashes while serving NFS
Control: tags -1 + moreinfo Hello Arne, On Tue, Jul 12, 2022 at 08:14:22AM +0200, Arne Nordmark wrote: > > Package: src:linux > Version: 5.10.127-1 > Severity: normal > > Dear Maintainer, > > The new kernel in Debian 11.4 seems unstable and crashes when serving NFS. > On two different computers, these lockups happens within minutes, typically > when a client runs firefox on an NFS-mounted home directory. Typically the > servers lock up without any printout, but on one occasion, the following was > logged: > > jul 10 08:35:13 ano4 kernel: general protection fault, probably for > non-canonical address 0x2f48514544455145: [#1] SMP PTI > jul 10 08:35:13 ano4 kernel: CPU: 2 PID: 1244 Comm: nfsd Not tainted > 5.10.0-16-amd64 #1 Debian 5.10.127-1 > jul 10 08:35:13 ano4 kernel: Hardware name: System manufacturer System > Product Name/P5Q DELUXE, BIOS 220105/21/2009 > jul 10 08:35:13 ano4 kernel: RIP: 0010:fsnotify+0x2d9/0x570 > jul 10 08:35:13 ano4 kernel: Code: 78 08 44 0b 30 44 0b 68 40 48 83 c1 01 48 > 83 f9 04 75 d9 66 66 66 66 90 44 8b 4c 24 1c 44 89 e8 f7 d0 45 21 f1 41 85 > c1 74 4f <49> 8b 3f 48 8b 07 48 85 c0 0f 84 0a 01 00 00 48 8d 7c 24 38 44 89 > jul 10 08:35:13 ano4 kernel: RSP: 0018:abe901fa3bc8 EFLAGS: 00010202 > jul 10 08:35:13 ano4 kernel: RAX: bab6aebe RBX: 0001 > RCX: 0004 > jul 10 08:35:13 ano4 kernel: RDX: 00035a00 RSI: 0001 > RDI: 2f48514544455145 > jul 10 08:35:13 ano4 kernel: RBP: abe901fa3c20 R08: 0001 > R09: 0002 > jul 10 08:35:13 ano4 kernel: R10: 0002 R11: 0002 > R12: 0002 > jul 10 08:35:13 ano4 kernel: R13: 45495141 R14: 424d6757 > R15: 2f48514544455145 > jul 10 08:35:13 ano4 kernel: FS: () > GS:939527d0() knlGS: > jul 10 08:35:13 ano4 kernel: CS: 0010 DS: ES: CR0: > 80050033 > jul 10 08:35:13 ano4 kernel: CR2: 560b8cee4000 CR3: 0001034da000 > CR4: 000406e0 > jul 10 08:35:13 ano4 kernel: Call Trace: > jul 10 08:35:13 ano4 kernel: __fsnotify_parent+0xe7/0x2d0 > jul 10 08:35:13 ano4 kernel: ? ext4_buffered_write_iter+0xce/0x160 [ext4] > jul 10 08:35:13 ano4 kernel: ? do_iter_readv_writev+0x152/0x1b0 > jul 10 08:35:13 ano4 kernel: do_iter_write+0xc8/0x1b0 > jul 10 08:35:13 ano4 kernel: nfsd_vfs_write+0x175/0x510 [nfsd] > jul 10 08:35:13 ano4 kernel: nfsd4_write+0x135/0x1b0 [nfsd] > jul 10 08:35:13 ano4 kernel: nfsd4_proc_compound+0x40d/0x680 [nfsd] > jul 10 08:35:13 ano4 kernel: nfsd_dispatch+0xd3/0x180 [nfsd] > jul 10 08:35:13 ano4 kernel: svc_process_common+0x3d4/0x6d0 [sunrpc] > jul 10 08:35:13 ano4 kernel: ? nfsd_svc+0x320/0x320 [nfsd] > jul 10 08:35:13 ano4 kernel: svc_process+0xb7/0xf0 [sunrpc] > jul 10 08:35:13 ano4 kernel: nfsd+0xe8/0x140 [nfsd] > jul 10 08:35:13 ano4 kernel: ? nfsd_destroy+0x60/0x60 [nfsd] > jul 10 08:35:13 ano4 kernel: kthread+0x11b/0x140 > jul 10 08:35:13 ano4 kernel: ? __kthread_bind_mask+0x60/0x60 > jul 10 08:35:13 ano4 kernel: ret_from_fork+0x22/0x30 > jul 10 08:35:13 ano4 kernel: Modules linked in: dm_snapshot dm_bufio tun > cpufreq_ondemand cpufreq_powersave cpufreq_conservative cpufreq_userspace > aes_generic libaes crypto_simd cryptd glue_helper cbc cts rpcsec_gss_krb5 > sit tunnel4 ip_tunnel nft_nat sch_fq_codel rc_pinnacl > e_pctv_hd em28xx_rc rc_core si2157 si2168 i2c_mux em28xx_dvb dvb_core > snd_hda_codec_analog snd_hda_codec_generic ledtrig_audio ivtv_alsa > tuner_simple tuner_types snd_hda_codec_hdmi wm8775 snd_hda_intel tda9887 > tda8290 snd_intel_dspcfg tea5767 soundwire_intel tuner > soundwire_generic_allocation snd_soc_core snd > _compress soundwire_cadence cx25840 snd_hda_codec ivtv snd_hda_core > snd_hwdep soundwire_bus em28xx kvm_intel radeon tveeprom snd_pcm cx2341x kvm > ttm videodev snd_timer snd irqbypass soundcore drm_kms_helper mc serio_raw > evdev cec i2c_algo_bit iTCO_wdt intel_pmc_bxt iTCO_vendor_support pcspkr > watchdog sg acpi_ > cpufreq asus_atk0110 button nft_chain_nat nf_nat nft_reject_inet > nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_counter nft_ct > jul 10 08:35:13 ano4 kernel: nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 > coretemp firewire_sbp2 nf_tables nfnetlink loop nfsd parport_pc ppdev > nfs_acl lockd lp auth_rpcgss parport grace drm fuse sunrpc configfs > ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid4 > 56 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq > libcrc32c crc32c_generic raid0 multipath linear dm_mod raid1 md_mod sd_mod > hid_generic t10_pi ata_generic crc_t10dif crct10dif_generic st > crct10dif_common usbhid pata_marvell hid ahci libahci mpt3sas firewire_ohci > firewire_core aic7xxx > crc_itu_t libata skge ehci_pci uhci_hcd scsi_transport_spi lpc_ich i2c_i801 > sky2 ehci_hcd psmouse i2c_smbus raid_class scsi_transport_sas usbcore > scsi_mod usb_common floppy > jul 10 08:35:13 ano4 kernel: ---[ end trace
Bug#1014858: libpodofo: CVE-2020-18971
Source: libpodofo X-Debbugs-CC: t...@security.debian.org Severity: normal Tags: security Hi, The following vulnerability was published for libpodofo. CVE-2020-18971[0]: | Stack-based Buffer Overflow in PoDoFo v0.9.6 allows attackers to cause | a denial of service via the component 'src/base/PdfDictionary.cpp:65'. https://sourceforge.net/p/podofo/tickets/48/ If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-18971 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-18971 Please adjust the affected versions in the BTS as needed.
Bug#1014857: ansible: CVE-2021-3533
Source: ansible X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for ansible. CVE-2021-3533[0]: | A flaw was found in Ansible if an ansible user sets ANSIBLE_ASYNC_DIR | to a subdirectory of a world writable directory. When this occurs, | there is a race condition on the managed machine. A malicious, non- | privileged account on the remote machine can exploit the race | condition to access the async result data. This flaw affects Ansible | Tower 3.7 and Ansible Automation Platform 1.2. This was reported at Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1956477 It needs to be checked if this was reported/fixed upstream. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-3533 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3533 Please adjust the affected versions in the BTS as needed.
