Bug#1025761: opendrop FTBFS with sundials 6.4.1
Source: opendrop Version: 3.3.1-3 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=opendrop=3.3.1-3%2Bb3 ... In file included from include/opendrop/younglaplace.hpp:135, from opendrop/fit/younglaplace/.checkpoints/shape.cpp:763: include/opendrop/younglaplace_detail.hpp: In constructor 'opendrop::younglaplace::YoungLaplaceShape::YoungLaplaceShape(realtype)': include/opendrop/younglaplace_detail.hpp:54:23: error: too few arguments to function '_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)' 54 | nv = N_VNew_Serial(4); | ~^~~ In file included from include/opendrop/younglaplace.hpp:10: /usr/include/nvector/nvector_serial.h:85:26: note: declared here 85 | SUNDIALS_EXPORT N_Vector N_VNew_Serial(sunindextype vec_length, SUNContext sunctx); | ^ include/opendrop/younglaplace_detail.hpp:56:27: error: too few arguments to function '_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)' 56 | nv_DBo = N_VNew_Serial(4); | ~^~~ /usr/include/nvector/nvector_serial.h:85:26: note: declared here 85 | SUNDIALS_EXPORT N_Vector N_VNew_Serial(sunindextype vec_length, SUNContext sunctx); | ^ include/opendrop/younglaplace_detail.hpp:78:31: error: too few arguments to function 'void* ERKStepCreate(ARKRhsFn, realtype, N_Vector, SUNContext)' 78 | arkode_mem = ERKStepCreate(arkrhs, RCONST(0.0), nv); | ~^ In file included from include/opendrop/younglaplace.hpp:9: /usr/include/arkode/arkode_erkstep.h:76:23: note: declared here 76 | SUNDIALS_EXPORT void* ERKStepCreate(ARKRhsFn f, realtype t0, | ^ include/opendrop/younglaplace_detail.hpp:97:35: error: too few arguments to function 'void* ERKStepCreate(ARKRhsFn, realtype, N_Vector, SUNContext)' 97 | arkode_mem_DBo = ERKStepCreate(arkrhs_DBo, RCONST(0.0), nv_DBo); | ~^ /usr/include/arkode/arkode_erkstep.h:76:23: note: declared here 76 | SUNDIALS_EXPORT void* ERKStepCreate(ARKRhsFn f, realtype t0, | ^ include/opendrop/younglaplace_detail.hpp: In member function 'realtype opendrop::younglaplace::YoungLaplaceShape::volume(realtype)': include/opendrop/younglaplace_detail.hpp:334:37: error: too few arguments to function '_generic_N_Vector* N_VMake_Serial(sunindextype, realtype*, SUNContext)' 334 | N_Vector nv_vol = N_VMake_Serial(1, data); | ~~^ /usr/include/nvector/nvector_serial.h:89:26: note: declared here 89 | SUNDIALS_EXPORT N_Vector N_VMake_Serial(sunindextype vec_length, realtype *v_data, SUNContext sunctx); | ^~ include/opendrop/younglaplace_detail.hpp:337:41: error: too few arguments to function 'void* ERKStepCreate(ARKRhsFn, realtype, N_Vector, SUNContext)' 337 | void *arkode_mem_vol = ERKStepCreate(arkrhs_vol, RCONST(0.0), nv_vol); | ~^ /usr/include/arkode/arkode_erkstep.h:76:23: note: declared here 76 | SUNDIALS_EXPORT void* ERKStepCreate(ARKRhsFn f, realtype t0, | ^ include/opendrop/younglaplace_detail.hpp: In member function 'realtype opendrop::younglaplace::YoungLaplaceShape::surface_area(realtype)': include/opendrop/younglaplace_detail.hpp:371:38: error: too few arguments to function '_generic_N_Vector* N_VMake_Serial(sunindextype, realtype*, SUNContext)' 371 | N_Vector nv_surf = N_VMake_Serial(1, data); |~~^ /usr/include/nvector/nvector_serial.h:89:26: note: declared here 89 | SUNDIALS_EXPORT N_Vector N_VMake_Serial(sunindextype vec_length, realtype *v_data, SUNContext sunctx); | ^~ include/opendrop/younglaplace_detail.hpp:374:42: error: too few arguments to function 'void* ERKStepCreate(ARKRhsFn, realtype, N_Vector, SUNContext)' 374 | void *arkode_mem_surf = ERKStepCreate(arkrhs_surf, RCONST(0.0), nv_surf); | ~^~~ /usr/include/arkode/arkode_erkstep.h:76:23: note: declared here 76 | SUNDIALS_EXPORT void* ERKStepCreate(ARKRhsFn f, realtype t0, | ^ include/opendrop/younglaplace_detail.hpp: In instantiation of 'opendrop::younglaplace::YoungLaplaceShape::YoungLaplaceShape(realtype) [with realtype = double]': opendrop/fit/younglaplace/.checkpoints/shape.cpp:2760:79: required from here include/opendrop/younglaplace_detail.hpp:90:43: error: invalid conversion from 'int' to 'ARKODE_ERKTableID' [-fpermissive] 90 | flag = ERKStepSetTableNum(arkode_mem,
Bug#1025760: ITP: level-zero -- oneAPI Level Zero
Package: wnpp Severity: wishlist Owner: Timo Aaltonen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: level-zero Version : 1.8.8 Upstream Author : Intel * URL : https://github.com/oneapi-src/level-zero * License : MIT Programming Lang: C++ Description : oneAPI Level Zero The oneAPI Level Zero (Level Zero) provides low-level direct-to-metal interfaces that are tailored to the devices in a oneAPI platform. Level Zero supports broader language features such as function pointers, virtual functions, unified memory, and I/O capabilities while also providing fine-grain explicit controls needed by higher-level runtime APIs.
Bug#1025759: chromium: Chromium libpng bug causes entire system to reboot
Package: chromium Version: 107.0.5304.121-1~deb11u1 Severity: important X-Debbugs-Cc: kamalamalama...@gmail.com When leaving Chromium idle for some time, my entire system will reboot at random. When checking "/var/log/syslog.1" it gives me the following output: "ec 3 20:31:31 kamalamalamalam chromium.desktop[6031]: libpng warning: iCCP: known incorrect sRGB profile Dec 3 20:31:31 kamalamalamalam chromium.desktop[6031]: libpng warning: iCCP: known incorrect sRGB profile Dec 3 20:31:36 kamalamalamalam chromium.desktop[10572]: *** stack smashing detected ***: terminated Dec 3 21:05:40 kamalamalamalam chromium.desktop[10868]: *** stack smashing detected ***: terminated" After this the log begins to resemble what it'd look like if I restarted my system. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common107.0.5304.121-1~deb11u1 ii libasound2 1.2.4-1.1 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-02.36.0-2 ii libatomic1 10.2.1-6 ii libatspi2.0-0 2.38.0-4 ii libbrotli1 1.0.9-2+b2 ii libc6 2.31-13+deb11u5 ii libcairo2 1.16.0-5 ii libcups2 2.3.3op2-3+deb11u2 ii libdbus-1-31.12.24-0+deb11u1 ii libdouble-conversion3 3.1.5-6.1 ii libdrm22.4.104-1 ii libevent-2.1-7 2.1.12-stable-1 ii libexpat1 2.2.10-2+deb11u5 ii libflac8 1.3.3-2+deb11u1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1+deb11u1 ii libgbm120.3.5-1 ii libgcc-s1 10.2.1-6 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libjpeg62-turbo1:2.0.6-4 ii libjsoncpp24 1.9.4-4 ii liblcms2-2 2.12~rc1-2 ii libminizip11.1-8+b1 ii libnspr4 2:4.29-1 ii libnss32:3.61-1+deb11u2 ii libopenjp2-7 2.4.0-3 ii libopus0 1.3.1-0.1 ii libpango-1.0-0 1.46.2-3 ii libpng16-161.6.37-3 ii libpulse0 14.2-2 ii libre2-9 20210201+dfsg-1 ii libsnappy1v5 1.1.8-1 ii libstdc++6 10.2.1-6 ii libwebp6 0.6.1-2.1 ii libwebpdemux2 0.6.1-2.1 ii libwebpmux30.6.1-2.1 ii libwoff1 1.0.2-1+b1 ii libx11-6 2:1.7.2-1 ii libxcb11.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage11:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxkbcommon0 1.0.3-2 ii libxml22.9.10+dfsg-6.7+deb11u3 ii libxnvctrl0470.141.03-1~deb11u1 ii libxrandr2 2:1.5.1-1 ii libxslt1.1 1.1.34-4+deb11u1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backen 1.8.0-1 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages chromium recommends: ii
Bug#1020809: aespipe: reproducible-builds: build path embedded in /usr/bin/aespipe
tags 661079 + pending patch tags 1020809 + pending patch thanks I've just uploaded aespipe 2.4d-1.1 to DELAYED/10: aespipe (2.4d-1.1) unstable; urgency=medium . * Non-maintainer upload. * Move to dpkg-buildflags(1) in debian/rules: - Ensure that the stack is not executable. (Closes: #661079) - Make the build reproducible by setting -fdebug-prefix-map. (Closes: #1020809) The full debdiff is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diffstat for aespipe-2.4d aespipe-2.4d changelog | 10 ++ rules | 22 ++ 2 files changed, 16 insertions(+), 16 deletions(-) diff -Nru aespipe-2.4d/debian/changelog aespipe-2.4d/debian/changelog --- aespipe-2.4d/debian/changelog 2016-11-28 11:39:38.0 + +++ aespipe-2.4d/debian/changelog 2022-12-08 17:14:21.0 + @@ -1,3 +1,13 @@ +aespipe (2.4d-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Move to dpkg-buildflags(1) in debian/rules: +- Ensure that the stack is not executable. (Closes: #661079) +- Make the build reproducible by setting -fdebug-prefix-map. + (Closes: #1020809) + + -- Chris Lamb Thu, 08 Dec 2022 17:14:21 + + aespipe (2.4d-1) unstable; urgency=medium * New upstream release diff -Nru aespipe-2.4d/debian/rules aespipe-2.4d/debian/rules --- aespipe-2.4d/debian/rules 2016-11-10 23:50:56.0 + +++ aespipe-2.4d/debian/rules 2022-12-08 17:14:21.0 + @@ -1,22 +1,15 @@ #!/usr/bin/make -f #export DH_VERBOSE=1 -CFLAGS = -Wall -g +export DEB_BUILD_MAINT_OPTIONS=hardening=-pie reproducible=-fixfilepath,+fixdebugpath + +DPKG_EXPORT_BUILDFLAGS = 1 +include /usr/share/dpkg/buildflags.mk + DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) -ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) - CFLAGS += -O0 -else -# needed because of gcc-4.0 problems (#325131) -ifneq (,$(filter $(DEB_HOST_ARCH),arm hppa)) - CFLAGS += -O1 -else - CFLAGS += -O2 -endif -endif - ifeq ($(DEB_HOST_ARCH),amd64) DEBIAN_OPTIMIZE := amd64 endif @@ -25,16 +18,13 @@ DEBIAN_OPTIMIZE := x86 endif -CFLAGS += -no-pie -LDFLAGS += -no-pie - config.status: configure dh_testdir ln -sf /usr/share/misc/config.sub . ln -sf /usr/share/misc/config.guess . - CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" ./configure \ + ./configure \ --host=$(DEB_HOST_GNU_TYPE) \ --build=$(DEB_BUILD_GNU_TYPE) \ --prefix=/usr \
Bug#1024278: libgssglue: autopkgtest failure with pkgconf
Hey Simon, On Thu, Nov 17, 2022 at 12:46:19PM +0100, Sebastian Ramacher wrote: > > I see. If so, it would be good if pkgconf was made consistent with > > pkg-config here, if the intention is to replace it. > > This discussion needs to happen with the pkgconf maintainer / upstream. > But since this is the only package where the extra whitespace seems to > be an issue, I'd just be pragmatic on the libgssglue side. Could we be pragmatic here and fix it in Debian in the meantime? It'd be a shame if we had a couple of packages autoremoved from testing due to this, if it's basically a one character change somewhere. Kind regards and thanks Philipp Kern
Bug#1013933: Keep xsane out of Debian releases
Please consider reducing the severity of the bug to allow the inclusion of xsane in the next stable release. xsane has no equivalent software available. Its GUI allows you to use advanced features of SANE not available graphically in other GUIs. xsane is usable in the currently packaged version (removed in testing due to this bug). It does not have any bug that prevent me from using it on a daily basis. At https://popcon.debian.org/by_inst xsane is ranked 2346, by comparison sane is ranked 7457. Its development is low in the last years, the last commit is from 6 months ago ( https://gitlab.com/sane-project/frontend/xsane ), but this is not a reason to remove a software that is useful, usable, popular and no equivalent available. Thank you very much.
Bug#1025755: bullseye-pu: package dovecot-fts-xapian/1.4.9a-1+deb11u1
On Thu, Dec 08, 2022 at 06:59:10PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: Joseph Nahmias
>
> * Generate dependency on dovecot ABI in use during build.
> Technique stolen from dovecot-antispam packaging.
> Thanks to Ron Lee (Closes: #1009794)
>
> debdiff of the change in the dependencies:
> Depends: libc6 (>= 2.14), libgcc-s1 (>= 3.0), libicu67 (>= 67.1-1~),
> libstdc++6 (>= 5.2), libxapian30 (>= [-1.4.17~)-] {+1.4.17~),
> dovecot-abi-2.3.abiv13+}
>
> This ensures that on bullseye -> bookworm upgrades dovecot-fts-xapian
> will be upgraded at the same time as dovecot-core.
>
> It also fixes the less severe issue that dovecot-fts-xapian is
> a plugin that was not previously depending on what it is a plugin for.
The debdiff is now attached.
cu
Adrian
diff -Nru dovecot-fts-xapian-1.4.9a/debian/changelog
dovecot-fts-xapian-1.4.9a/debian/changelog
--- dovecot-fts-xapian-1.4.9a/debian/changelog 2021-06-24 16:09:17.0
+0300
+++ dovecot-fts-xapian-1.4.9a/debian/changelog 2022-12-08 18:49:00.0
+0200
@@ -1,3 +1,12 @@
+dovecot-fts-xapian (1.4.9a-1+deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Generate dependency on dovecot ABI in use during build.
+Technique stolen from dovecot-antispam packaging.
+Thanks to Ron Lee (Closes: #1009794)
+
+ -- Adrian Bunk Thu, 08 Dec 2022 18:49:00 +0200
+
dovecot-fts-xapian (1.4.9a-1) unstable; urgency=medium
* [2da6c89] d/watch: allow non-numbers in version
diff -Nru dovecot-fts-xapian-1.4.9a/debian/control
dovecot-fts-xapian-1.4.9a/debian/control
--- dovecot-fts-xapian-1.4.9a/debian/control2021-06-23 05:10:41.0
+0300
+++ dovecot-fts-xapian-1.4.9a/debian/control2022-12-08 18:48:53.0
+0200
@@ -18,7 +18,7 @@
Architecture: any
Provides: fts-xapian
Enhances: dovecot-imapd, dovecot-pop3d
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, dovecot-abi-${dovecot:ABI-Version}
Description: full-text search for dovecot using xapian
This project provides a straightforward and simple way to configure
full-text search (FTS) for Dovecot, leveraging the efforts of the
diff -Nru dovecot-fts-xapian-1.4.9a/debian/rules
dovecot-fts-xapian-1.4.9a/debian/rules
--- dovecot-fts-xapian-1.4.9a/debian/rules 2021-06-23 05:10:41.0
+0300
+++ dovecot-fts-xapian-1.4.9a/debian/rules 2022-12-08 18:48:53.0
+0200
@@ -5,5 +5,9 @@
override_dh_auto_install:
dh_auto_install --destdir=debian/tmp
+override_dh_gencontrol: DOVECOT_ABI_VERSION = $(shell cat
/usr/share/dovecot/dovecot-abi)
+override_dh_gencontrol:
+ dh_gencontrol -- -V'dovecot:ABI-Version=$(DOVECOT_ABI_VERSION)'
+
%:
dh $@
Bug#1025758: bullseye-pu: package efitools/1.9.2-2~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: Debian UEFI Maintainers * Fix occasional FTBFS due to incorrect dependency. Closes: #1010996. 1.9.2-1 parallel build was flaky: https://tests.reproducible-builds.org/debian/history/arm64/efitools.html diff -Nru efitools-1.9.2/debian/changelog efitools-1.9.2/debian/changelog --- efitools-1.9.2/debian/changelog 2019-12-23 20:39:27.0 +0200 +++ efitools-1.9.2/debian/changelog 2022-12-08 19:01:40.0 +0200 @@ -1,3 +1,20 @@ +efitools (1.9.2-2~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Rebuild for bullseye. + + -- Adrian Bunk Thu, 08 Dec 2022 19:01:40 +0200 + +efitools (1.9.2-2) unstable; urgency=medium + + [ Steve McIntyre ] + * Fix occasional FTBFS due to incorrect dependency. +Closes: #1010996. Thanks to Adrian Bunk for the patch! + + * Team upload + + -- Steve McIntyre <93...@debian.org> Tue, 24 May 2022 18:44:35 + + efitools (1.9.2-1) unstable; urgency=medium [ Luca Boccassi ] diff -Nru efitools-1.9.2/debian/patches/fix-deps.patch efitools-1.9.2/debian/patches/fix-deps.patch --- efitools-1.9.2/debian/patches/fix-deps.patch1970-01-01 02:00:00.0 +0200 +++ efitools-1.9.2/debian/patches/fix-deps.patch2022-05-24 20:48:58.0 +0300 @@ -0,0 +1,15 @@ +Description: Fix a typo in the %-blacklist.esl rule + This sometimes resulted in FTBFS. +Author: Adrian Bunk + +--- efitools-1.9.2.orig/Make.rules efitools-1.9.2/Make.rules +@@ -71,7 +71,7 @@ endif + %.hash: %.efi hash-to-efi-sig-list + ./hash-to-efi-sig-list $< $@ + +-%-blacklist.esl: %.crt cert-to-efi-hash-list ++%-blacklist.esl: %.crt cert-to-efi-sig-list + ./cert-to-efi-sig-list $< $@ + + %-hash-blacklist.esl: %.crt cert-to-efi-hash-list diff -Nru efitools-1.9.2/debian/patches/series efitools-1.9.2/debian/patches/series --- efitools-1.9.2/debian/patches/series2019-12-23 20:39:27.0 +0200 +++ efitools-1.9.2/debian/patches/series2022-05-24 20:48:58.0 +0300 @@ -1 +1,2 @@ makefile-enable-harden-local-files.patch +fix-deps.patch
Bug#1025757: dyssol FTBFS with sundials 6.4.1
Source: dyssol Version: 1.0.2+ds2-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=dyssol=1.0.2%2Bds2-1%2Bb1 ... /<>/EquationSolvers/DAESolver.cpp: In member function ‘bool CDAESolver::SetModel(CDAEModel*)’: /<>/EquationSolvers/DAESolver.cpp:56:30: error: too few arguments to function ‘void* IDACreate(SUNContext)’ 56 | m_pIDAmem = IDACreate(); | ~^~ In file included from /<>/EquationSolvers/DAESolver.cpp:4: /usr/include/ida/ida.h:107:23: note: declared here 107 | SUNDIALS_EXPORT void *IDACreate(SUNContext sunctx); | ^ /<>/EquationSolvers/DAESolver.cpp:71:38: error: too few arguments to function ‘_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)’ 71 | m_vectorVars = N_VNew_Serial(nVarsCnt); | ~^~ In file included from /<>/EquationSolvers/DAESolver.cpp:7: /usr/include/nvector/nvector_serial.h:85:26: note: declared here 85 | SUNDIALS_EXPORT N_Vector N_VNew_Serial(sunindextype vec_length, SUNContext sunctx); | ^ /<>/EquationSolvers/DAESolver.cpp:72:38: error: too few arguments to function ‘_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)’ 72 | m_vectorDers = N_VNew_Serial(nVarsCnt); | ~^~ /usr/include/nvector/nvector_serial.h:85:26: note: declared here 85 | SUNDIALS_EXPORT N_Vector N_VNew_Serial(sunindextype vec_length, SUNContext sunctx); | ^ /<>/EquationSolvers/DAESolver.cpp:73:38: error: too few arguments to function ‘_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)’ 73 | m_vectorATols = N_VNew_Serial(nVarsCnt); | ~^~ /usr/include/nvector/nvector_serial.h:85:26: note: declared here 85 | SUNDIALS_EXPORT N_Vector N_VNew_Serial(sunindextype vec_length, SUNContext sunctx); | ^ /<>/EquationSolvers/DAESolver.cpp:74:38: error: too few arguments to function ‘_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)’ 74 | m_vectorId= N_VNew_Serial(nVarsCnt); | ~^~ /usr/include/nvector/nvector_serial.h:85:26: note: declared here 85 | SUNDIALS_EXPORT N_Vector N_VNew_Serial(sunindextype vec_length, SUNContext sunctx); | ^ /<>/EquationSolvers/DAESolver.cpp:96:45: error: too few arguments to function ‘_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)’ 96 | N_Vector vConstrVars = N_VNew_Serial(nVarsCnt); |~^~ /usr/include/nvector/nvector_serial.h:85:26: note: declared here 85 | SUNDIALS_EXPORT N_Vector N_VNew_Serial(sunindextype vec_length, SUNContext sunctx); | ^ /<>/EquationSolvers/DAESolver.cpp:129:29: error: too few arguments to function ‘_generic_SUNMatrix* SUNDenseMatrix(sunindextype, sunindextype, SUNContext)’ 129 | m_A = SUNDenseMatrix(nVarsCnt, nVarsCnt); | ~~^~~~ In file included from /usr/include/sunlinsol/sunlinsol_dense.h:36, from /<>/EquationSolvers/DAESolver.cpp:6: /usr/include/sunmatrix/sunmatrix_dense.h:79:27: note: declared here 79 | SUNDIALS_EXPORT SUNMatrix SUNDenseMatrix(sunindextype M, sunindextype N, SUNContext sunctx); | ^~ /<>/EquationSolvers/DAESolver.cpp:131:31: error: too few arguments to function ‘_generic_SUNLinearSolver* SUNLinSol_Dense(N_Vector, SUNMatrix, SUNContext)’ 131 | m_LS = SUNLinSol_Dense(m_vectorVars, m_A); |~~~^~~ /usr/include/sunlinsol/sunlinsol_dense.h:58:33: note: declared here 58 | SUNDIALS_EXPORT SUNLinearSolver SUNLinSol_Dense(N_Vector y, SUNMatrix A, SUNContext sunctx); | ^~~ /<>/EquationSolvers/DAESolver.cpp: In member function ‘bool CDAESolver::Calculate(realtype, realtype)’: /<>/EquationSolvers/DAESolver.cpp:157:45: error: too few arguments to function ‘_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)’ 157 | vConsistVars = N_VNew_Serial( static_cast(m_pModel->GetVariablesNumber()) ); | ~^ /usr/include/nvector/nvector_serial.h:85:26: note: declared here 85 | SUNDIALS_EXPORT N_Vector N_VNew_Serial(sunindextype vec_length, SUNContext sunctx); | ^ /<>/EquationSolvers/DAESolver.cpp:158:45: error: too few arguments to function ‘_generic_N_Vector* N_VNew_Serial(sunindextype, SUNContext)’ 158 | vConsistDers = N_VNew_Serial(
Bug#1025756: bullseye-pu: package nvidia-graphics-drivers/470.161.03-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
A huge bunch of CVEs has been fixed upstream in the supported branches
of the proprietary nvidia driver. This is probably related to the
release of an open source variant of the kernel module (with the
proprietary bits being restricted to a firmware blob).
So let's upload a new upstream release to stable.
This is not a backport from sid (which has already a 510 driver which is
not suitable for stable since it drops support for certain cards), but
an equivalent package to the already -pu'ed tesla-470 driver of the same
version.
Packaging changes include the addition some new substitutions that are
needed for the packaging of above mentioned open source kernel module
(and are included here in order to mimimize the diff between different
driver series maintained in different releases).
The (tesla-)470 driver also includes the removal of make-kpkg support
and the simplification of the -source package to only support
module-assistant. This change was only backported to 470 but not older
series since only the 470 tesla driver has sufficient upstream support
life left to be included in bookworm.
The changelog diff looks huge due to rewrapping of long lines, but
the relevant changelog entries are only
+nvidia-graphics-drivers (470.161.03-1) bullseye; urgency=medium
+
+ * New upstream production branch release 470.161.03 (2022-11-22).
+* Fixed CVE-2022-34670, CVE-2022-34674, CVE-2022-34675, CVE-2022-34677,
+ CVE-2022-34679, CVE-2022-34680, CVE-2022-34682, CVE-2022-42254,
+ CVE-2022-42255, CVE-2022-42256, CVE-2022-42257, CVE-2022-42258,
+ CVE-2022-42259, CVE-2022-42260, CVE-2022-42261, CVE-2022-42262,
+ CVE-2022-42263, CVE-2022-42264. (Closes: #1025279)
+ https://nvidia.custhelp.com/app/answers/detail/a_id/5415
+- Fixed a bug that caused the Xorg server to crash if an NvFBC capture
+ session is started while video memory is full.
+* Improved compatibility with recent Linux kernels. (Closes: #1024852)
+ * New upstream Tesla release (amd64 only) 470.141.10 (2022-10-19).
+
+ [ Andreas Beckmann ]
+ * Refresh patches.
+ * Add missing #includes to fix kernel module build for ppc64el.
+ * Rename the internally used ARCH variable which might clash on externally
+set values.
+ * Use substitutions for ${nvidia-kernel} and friends (510.108.03-1).
+ * Try to compile a kernel module at package build time (510.108.03-1).
+ * Upload to bullseye.
+
+ -- Andreas Beckmann Thu, 08 Dec 2022 17:30:11 +0100
+
+nvidia-graphics-drivers (470.141.03-3) UNRELEASED; urgency=medium
+
+ * Backport get_task_ioprio changes from 510.85.02, acpi changes from
+510.85.02 and 515.65.01, drm_frambuffer.h changes from 515.76 to fix
+kernel module build for Linux 6.0. (Closes: #1021974, #1022738)
+
+ -- Andreas Beckmann Mon, 24 Oct 2022 18:00:40 +0200
+
+nvidia-graphics-drivers (470.141.03-2) unstable; urgency=medium
+
+ * Add support for unversioned Tesla packages (tesla 510.85.02-1).
+(Closes: #1020697)
+ * Switch *-source to a modern module-assistant based template.
+ * Drop support for kernel-package and make-kpkg, gone since stretch.
+
+ -- Andreas Beckmann Tue, 27 Sep 2022 14:18:14 +0200
debian/README.source
| 49 +--
debian/bug-control.mk
| 8 +-
debian/build-module-packages.sh.in
| 2 +-
debian/changelog
| 741
debian/control
| 30 +-
debian/control.in
| 34 +-
debian/control.kmod
| 6 +-
debian/control.md5sum
| 8 +-
debian/libglx-nvidia0.lintian-overrides.in
| 1 +
debian/module/debian/README.Debian
| 11 -
debian/module/debian/clean
| 7 -
debian/module/debian/{control.template.binary.in =>
control.modules.in.binary.in} | 16 +-
debian/module/debian/genchanges
| 21 --
debian/module/debian/{install.template.in => install.modules.in.in}
| 0
debian/module/debian/kernel-version
| 40 ---
debian/module/debian/patches/0009-backport-pci-dma-changes-from-470.129.06.patch
| 12 +-
debian/module/debian/patches/bashisms.patch
| 2 +-
debian/module/debian/patches/cc_version_check-gcc5.patch
Bug#1022573: lxqt-session is affected by procps transition
On 2022-12-07 10:02:52 +0800, ChangZhuo Chen wrote: > On Tue, Dec 06, 2022 at 11:37:15PM +0100, Sebastian Ramacher wrote: > > On 2022-12-07 00:30:30 +0800, ChangZhuo Chen wrote: > > > Hi, > > > > > > lxqt-session is also affected by procps transition, and there is > > > untested patch [0] available. > > > > Please avoid an upload until we get the current lxqt situation settled. > > I'd prefer to not entangle lxqt with the procps transition. > > No problem. We will wait for lxqt transition first. The libfm-qt and liblxqt transitions are done. There is no risk of entanglement any longer. Cheers -- Sebastian Ramacher
Bug#1004488: Update grpc to new upstream version 1.37
Hi Pirate, On Thu, Dec 8, 2022 at 12:27 PM Pirate Praveen wrote: > I can see protobuf 1.21 has migrated to testing. Any other blockers to > upload grpc to unstable? Release Manager decision [1]? :) Cheers, Laszlo/GCS [1] https://bugs.debian.org/1025541
Bug#1025755: bullseye-pu: package dovecot-fts-xapian/1.4.9a-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Joseph Nahmias
* Generate dependency on dovecot ABI in use during build.
Technique stolen from dovecot-antispam packaging.
Thanks to Ron Lee (Closes: #1009794)
debdiff of the change in the dependencies:
Depends: libc6 (>= 2.14), libgcc-s1 (>= 3.0), libicu67 (>= 67.1-1~), libstdc++6
(>= 5.2), libxapian30 (>= [-1.4.17~)-] {+1.4.17~), dovecot-abi-2.3.abiv13+}
This ensures that on bullseye -> bookworm upgrades dovecot-fts-xapian
will be upgraded at the same time as dovecot-core.
It also fixes the less severe issue that dovecot-fts-xapian is
a plugin that was not previously depending on what it is a plugin for.
Bug#1025739: hmmer2: missing source for configure
Control: tags -1 moreinfo Hi Helmut Am Thu, Dec 08, 2022 at 09:57:56AM +0100 schrieb Helmut Grohne: > The source code for the file configure in the source tarball is missing. > This violates DFSG #2. I agree that this configure script looks auto generated but IMHO it can be considered machine readable and editable with some effort. I could imagine that it is hard to edit for your cross-building effort. However, this is the first time a FTBFS bug is filed for the lack of some configure.ac file. Am I missing something our should this be discussed on debian-devel list first since this might end up in a MBF. Kind regards Andreas. -- http://fam-tille.de
Bug#1017881: ITA: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes
Hi Sean, Sean Whitton writes: > I only sponsor out of git, I don't need any .dscs :) So, it's ready? Sorry for the delay. I've used the new package for a couple of days, and everything seems to be working, so I'd say that yes, it is ready. Here's the git link again, for your convenience: https://salsa.debian.org/skangas/unclutter-xfixes Thanks again for sponsoring this package.
Bug#1025754: bullseye-pu: package containerd/1.4.13~ds1-1~deb11u3
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: contain...@packages.debian.org, z...@debian.org
Control: affects -1 + src:containerd
[ Reason ]
Backport patch for CVE-2022-23471.
https://github.com/containerd/containerd/security/advisories/GHSA-2qjp-425j-52j9
> A bug was found in containerd's CRI implementation where a user can exhaust
> memory on the host.
[ Impact ]
[ Tests ]
No new test is added, but the patch is simple and easy to review.
It is taken from upstream 1.5 release branch without modification.
[ Risks ]
Code 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 ]
See attachment
[ Other info ]
No
diff -Nru containerd-1.4.13~ds1/debian/changelog
containerd-1.4.13~ds1/debian/changelog
--- containerd-1.4.13~ds1/debian/changelog 2022-06-07 03:07:20.0
+0800
+++ containerd-1.4.13~ds1/debian/changelog 2022-12-08 10:24:34.0
+0800
@@ -1,3 +1,9 @@
+containerd (1.4.13~ds1-1~deb11u3) bullseye; urgency=medium
+
+ * CVE-2022-23471: CRI plugin: Fix goroutine leak during Exec
+
+ -- Shengjing Zhu Thu, 08 Dec 2022 10:24:34 +0800
+
containerd (1.4.13~ds1-1~deb11u2) bullseye-security; urgency=high
* CVE-2022-31030: CRI plugin: Host memory exhaustion through ExecSync
diff -Nru containerd-1.4.13~ds1/debian/patches/0011-CVE-2022-23471.patch
containerd-1.4.13~ds1/debian/patches/0011-CVE-2022-23471.patch
--- containerd-1.4.13~ds1/debian/patches/0011-CVE-2022-23471.patch
1970-01-01 08:00:00.0 +0800
+++ containerd-1.4.13~ds1/debian/patches/0011-CVE-2022-23471.patch
2022-12-08 10:24:34.0 +0800
@@ -0,0 +1,56 @@
+From: Danny Canter
+Date: Mon, 28 Nov 2022 14:45:34 -0800
+Subject: CVE-2022-23471
+
+Origin: backport, https://github.com/containerd/containerd/commit/6cd11527
+---
+ .../cri/pkg/streaming/remotecommand/httpstream.go | 15 ---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git
a/vendor/github.com/containerd/cri/pkg/streaming/remotecommand/httpstream.go
b/vendor/github.com/containerd/cri/pkg/streaming/remotecommand/httpstream.go
+index 0417a1a..9177fa7 100644
+---
a/vendor/github.com/containerd/cri/pkg/streaming/remotecommand/httpstream.go
b/vendor/github.com/containerd/cri/pkg/streaming/remotecommand/httpstream.go
+@@ -33,6 +33,7 @@ limitations under the License.
+ package remotecommand
+
+ import (
++ gocontext "context"
+ "encoding/json"
+ "errors"
+ "fmt"
+@@ -132,7 +133,7 @@ func createStreams(req *http.Request, w
http.ResponseWriter, opts *Options, supp
+
+ if ctx.resizeStream != nil {
+ ctx.resizeChan = make(chan remotecommand.TerminalSize)
+- go handleResizeEvents(ctx.resizeStream, ctx.resizeChan)
++ go handleResizeEvents(req.Context(), ctx.resizeStream,
ctx.resizeChan)
+ }
+
+ return ctx, true
+@@ -425,7 +426,7 @@ WaitForStreams:
+ // supportsTerminalResizing returns false because v1ProtocolHandler doesn't
support it.
+ func (*v1ProtocolHandler) supportsTerminalResizing() bool { return false }
+
+-func handleResizeEvents(stream io.Reader, channel chan<-
remotecommand.TerminalSize) {
++func handleResizeEvents(ctx gocontext.Context, stream io.Reader, channel
chan<- remotecommand.TerminalSize) {
+ defer runtime.HandleCrash()
+ defer close(channel)
+
+@@ -435,7 +436,15 @@ func handleResizeEvents(stream io.Reader, channel chan<-
remotecommand.TerminalS
+ if err := decoder.Decode(); err != nil {
+ break
+ }
+- channel <- size
++
++ select {
++ case channel <- size:
++ case <-ctx.Done():
++ // To avoid leaking this routine, exit if the http
request finishes. This path
++ // would generally be hit if starting the process fails
and nothing is started to
++ // ingest these resize events.
++ return
++ }
+ }
+ }
+
diff -Nru containerd-1.4.13~ds1/debian/patches/series
containerd-1.4.13~ds1/debian/patches/series
--- containerd-1.4.13~ds1/debian/patches/series 2022-06-07 03:07:20.0
+0800
+++ containerd-1.4.13~ds1/debian/patches/series 2022-12-08 10:24:34.0
+0800
@@ -8,3 +8,4 @@
0008-Add-RPi1-RPi0-workaround.patch
0009-CVE-2022-31030.patch
0010-CVE-2022-24769.patch
+0011-CVE-2022-23471.patch
Bug#1025753: FTBFS: Java compilation error (cannot find symbols)
Source: jruby-openssl Version: 0.9.21-4 Severity: serious Tags: ftbfs Dear Maintainer, jruby-openssl currently fails to build with the following error message: [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[74,25] cannot find symbol symbol: class ChannelDescriptor location: package org.jruby.util.io [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[75,25] cannot find symbol symbol: class ChannelStream location: package org.jruby.util.io [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[76,25] cannot find symbol symbol: class FileExistsException location: package org.jruby.util.io [INFO] 3 errors Tested in pbuilder on my Sid system. Same error seemed to happen when the package got synced to Ubuntu [1] Btw, looks like the problematic imports are gone in latest upstream [2] so this might be resolved by upgrading to newer release :) [1] https://launchpad.net/ubuntu/+source/jruby-openssl/0.9.21-4/+build/24611214 [2] https://github.com/jruby/jruby-openssl/blob/master/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/3 CPU threads; PREEMPT) 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 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#77313: URL to cron src (will be temporarily? closed)
Hello, as Javier wrote it thirteen years ago, The cron package is maintained through a version control system. This information needs an update: today, you can read information about this package at https://tracker.debian.org/pkg/cron and interact with the VCS repository at https://salsa.debian.org/debian/cron.git Unfortunately, a patch wich was useful in year 2009 cannot be applied safely on our current version of cron's source, as we are using a more and more heavily patched derivative of Vixie's cron (version 3). Any help to improve cron is appreciated. However I shall close this bug report today, in order to increase the signal/noise rate of the bugs list targetting cron. So, feel free to reopen it if you believe that it deserves attention. Best regards, Georges. On Fri, 9 Jan 2009 14:27:55 +0100 Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= wrote: > [...] > The cron package is maintained through Alioth, please take a look at > svn://svn.debian.org/pkg-cron/ > or > http://svn.debian.org/wsvn/pkg-cron > > > Regards > > Javier > > > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1022404: raqm: diff for NMU version 0.7.0-4.1
Also, I suggest bumping harbuzz in Build-Depends. I don't know the exact version needed, setting it to 5.2 is probably ok. Thank you, Jeremy Bicha
Bug#1025752: RM: racon [armel armhf i386 mipsel hppa kfreebsd-amd64 m68k powerpc sh4 x32] -- ROM; Build-Depends not available on 32 bits
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ra...@packages.debian.org, 1025...@bugs.debian.org Control: affects -1 + src:racon Hi, since the predependency libthread-pool-dev is not available any more on 32bit architectures the package should be removed for these architectures. Please also remove it on kfreebsd-amd64 due to issues with cmake. Thanks a lot for your work as ftpmaster Andreas.
Bug#15258: Closing #15258 (cron SHOUTS!)
Hello, debian developers have lived with a version of cron daemon which kept shouting for 22 years, maybe some of them silently created scripts which depend on that shouting behaviour. As bug report #15258 has got no activity for 22 years, in order to improve the signal/noise rate of the bugs list against cron, I shall close this bug report. Please feel free to reopen it if you believe that it deserves attention. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1025751: manpages.d.o pages have json-ld objects double-encoded as strings
Package: manpages.debian.org
Severity: minor
[Please do not Cc: me, as I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
While I’m not sure if it perhaps /is/ an accepted practice,
I’d venture to guess that the way manpages.debian.org encodes
JSON-LD objects as strings /and then/ encodes the resulting
strings as JSON strings /yet again,/ is going to confuse some
of the processing tools out there.
Consider, e. g. (split for readability):
"{\"@context\":\"http://schema.org\",\"@type\":\"BreadcrumbList\";,
\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,
\"item\":{\"@type\":\"Thing\",\"@id\":\"/contents-unstable.html\",
\"name\":\"unstable\"}},{\"@type\":\"ListItem\",\"position\":2,
\"item\":{\"@type\":\"Thing\",\"@id\":\"/unstable/acl/index.html\",
\"name\":\"acl\"}},{\"@type\":\"ListItem\",\"position\":3,
\"item\":{\"@type\":\"Thing\",\"@id\":\"\",\"name\":\"getfacl(1)\"}}]}"
— https://manpages.debian.org/unstable/acl/getfacl.1.en.html
Versus, say, https://en.wikipedia.org/wiki/JSON-LD (which
I presume is the correct usage):
{"@context":"https:\/\/schema.org","@type":"Article","name":"JSON-LD",
"url":"https:\/\/en.wikipedia.org\/wiki\/JSON-LD",
"sameAs":"http:\/\/www.wikidata.org\/entity\/Q6108942",
"mainEntity":"http:\/\/www.wikidata.org\/entity\/Q6108942",
"author":{"@type":"Organization",
"name":"Contributors to Wikimedia projects"},
"publisher":{"@type":"Organization","name":"Wikimedia Foundation, Inc.",
"logo":{"@type":"ImageObject",
"url":"https:\/\/www.wikimedia.org\/static\/images\/wmf-hor-googpub.png"}},
"datePublished":"2011-12-30T17:43:17Z",
"dateModified":"2022-11-15T22:34:49Z",
"headline":"a method of encoding Linked Data using JSON"}
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#1022126: mpt3sas broken with xen dom0
Control: tag -1 =upstream signature.asc Description: This is a digitally signed message part.
Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player
On Thu, Dec 01, 2022 at 09:35:15PM +0100, Helmar Gerloni wrote: > The package builds and runs on amd64. I was not able to build it on i386 > because of missing libswt-gtk-4-java. That's not a problem, upstream of that package has dropped support for 32-bit and unless it somehow comes back, tuxguitar will stay BD-Uninstallable on those architectures. Because of the off chance the dependences _do_ come back, it's better to leave them enabled instead of explicitly dropping in debian/control. > I don't know if it builds on other architectures; probably not > out-of-the-box. The previous versions were ok, I tested arm64 and it fails the same way amd64 does. Which is: [ERROR] Plugin org.apache.maven.plugins:maven-antrun-plugin:1.7 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-antrun-plugin:jar:1.7 has not been downloaded from it before. Sounds like you missed a build dependency... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Bug#1025747: linux-image-5.10.0-19: linux-image-5.10.0-19 not boot with XEN (mpt3sas error)
Control: forwarded -1 https://lore.kernel.org/linux-scsi/y1jkuktjvyrow...@eldamar.lan/ Control: merge -1 1022126 On Thursday, 8 December 2022 15:27:49 CET Dröszler Gábor wrote: > Package: src:linux > Version: 5.10.149-2 > Severity: important > > Debian Bullseye not boot with XEN, linux-image-5.10.0-19. That's a know problem, merging with the others signature.asc Description: This is a digitally signed message part.
Bug#1023183: mpt3sas driver does not load
Control: severity -1 important Control: forwarded -1 https://lore.kernel.org/linux-scsi/y1jkuktjvyrow...@eldamar.lan/ Control: merge -1 1022126 On Monday, 31 October 2022 13:44:05 CET Taavi Ansper wrote: > Yes we are using xen virtualization Merging it with 1022126 then signature.asc Description: This is a digitally signed message part.
Bug#1025740: sudo: autopkgtest fails because of missing git
Control: tags -1 confirmed thanks On Thu, Dec 08, 2022 at 04:42:10PM +0100, Marc Haber wrote: > autopkgtest --user debci . -- lxc --sudo autopkgtest-unstable-amd64 > shows the same issue like you see. Try this patch: 4 [46/4891]mh@salida:~/packages/sudo/sudo (master *%|u=) $ cat debian/patches/dont-create-ChangeLog --- a/Makefile.in +++ b/Makefile.in @@ -235,17 +235,7 @@ depend: siglist.c signame.c --file $(top_builddir)/src/Makefile ChangeLog: - if test -d $(srcdir)/.hg; then \ - if hg log -R $(srcdir) --template=changelog -r "sort(branch(.) or follow(), -date)" > $@.tmp; then \ - mv -f $@.tmp $(srcdir)/$@; \ - else \ - rm -f $@.tmp; \ - fi; \ - elif test -d $(srcdir)/.git; then \ - $(scriptdir)/log2cl.pl -R $(srcdir)/.git > $(srcdir)/$@; \ - elif test ! -f $(srcdir)/$@; then \ - echo "ChangeLog data not available" > $(srcdir)/$@; \ - fi + true config.status: @if [ ! -s config.status ]; then \ With this one, autopkgtest --user debci . -- lxc --sudo autopkgtest-unstable-amd64 gets as far as the other variants. Greetings Marc
Bug#1025701: ovmf 2022.11 breaks virtio-blk drive usage
Hello, Paquet : ovmf Version : 2022.11-1 État: installé With 2022.11, virtio-blk drive is no longer recognized. Reverting to 2022.08 is a workaround to solve the issue. With 2022.11, the debian entry disappears from Tianocore "Boot Manager Menu". Here is a copy of the menu list : Boot Manager Menu Device Path: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x,0x0) UEFI QEMU DVD-ROM QM5 UEFI Misc Device UEFI PXEv4 (MAC:B8ADCAFE) UEFI PXEv4 (MAC:B8ADCAFE) 2 UEFI PXEv6 (MAC:B8ADCAFE) UEFI HTTPv4 (MAC:B8ADCAFE) UEFI HTTPv6 (MAC:B8ADCAFE) EFI Internal Shell Once in EFI Shell, it is possible to access debian directory and boot the VM FS0: cd EFI\debian grubx64.efi VM is booted through this script : https://github.com/platu/inetdoc/blob/master/guides/vm/files/ovs-startup.sh Once the VM is up, we get : etu@vm0:~$ sudo dmesg -HT | grep vd [jeu. 8 déc. 16:55:13 2022] virtio_blk virtio2: [vda] 125829120 512-byte logical blocks (64.4 GB/60.0 GiB) [jeu. 8 déc. 16:55:13 2022] vda: vda1 vda2 vda3 [jeu. 8 déc. 16:55:14 2022] EXT4-fs (vda2): mounted filesystem with ordered data mode. Quota mode: none. [jeu. 8 déc. 16:55:16 2022] EXT4-fs (vda2): re-mounted. Quota mode: none. [jeu. 8 déc. 16:55:16 2022] Adding 999420k swap on /dev/vda3. Priority:-2 extents:1 across:999420k FS Is there any hint to reinstate boot manager menu entry ? Regards, -- - Philippe Latu -- https://inetdoc.net
Bug#1025750: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.161.03-1~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
A huge bunch of CVEs has been fixed upstream in the supported branches
of the proprietary nvidia driver. This is probably related to the
release of an open source variant of the kernel module (with the
proprietary bits being restricted to a firmware blob).
So let's upload a new upstream release to stable.
This is a rebuild of the package from sid with no further changes.
Packaging changes include the addition some new substitutions that are
needed for the packaging of above mentioned open source kernel module
(and are included here in order to mimimize the diff between different
driver series maintained in different releases).
The (tesla-)470 driver also includes the removal of make-kpkg support
and the simplification of the -source package to only support
module-assistant. This change was only backported to 470 but not older
series since only the 470 tesla driver has sufficient upstream support
life left to be included in bookworm.
The changelog diff looks huge due to rewrapping of long lines, but
the relevant changelog entries are only
+nvidia-graphics-drivers-tesla-470 (470.161.03-1~deb11u1) bullseye;
urgency=medium
+
+ * Rebuild for bullseye.
+
+ -- Andreas Beckmann Thu, 08 Dec 2022 15:30:30 +0100
+
+nvidia-graphics-drivers-tesla-470 (470.161.03-1) unstable; urgency=medium
+
+ * New upstream production branch release 470.161.03 (2022-11-22).
+* Fixed CVE-2022-34670, CVE-2022-34674, CVE-2022-34675, CVE-2022-34677,
+ CVE-2022-34679, CVE-2022-34680, CVE-2022-34682, CVE-2022-42254,
+ CVE-2022-42255, CVE-2022-42256, CVE-2022-42257, CVE-2022-42258,
+ CVE-2022-42259, CVE-2022-42260, CVE-2022-42261, CVE-2022-42262,
+ CVE-2022-42263, CVE-2022-42264. (Closes: #1025285)
+ https://nvidia.custhelp.com/app/answers/detail/a_id/5415
+- Fixed a bug that caused the Xorg server to crash if an NvFBC capture
+ session is started while video memory is full.
+* Improved compatibility with recent Linux kernels.
+ * New upstream Tesla release (amd64 only) 470.141.10 (2022-10-19).
+
+ [ Andreas Beckmann ]
+ * Refresh patches.
+ * Add missing #includes to fix kernel module build for ppc64el.
+ * Rename the internally used ARCH variable which might clash on externally
+set values.
+ * Use substitutions for ${nvidia-kernel} and friends (510.108.03-1).
+ * Try to compile a kernel module at package build time (510.108.03-1).
+
+ -- Andreas Beckmann Thu, 08 Dec 2022 15:18:42 +0100
+
+nvidia-graphics-drivers-tesla-470 (470.141.03-3) unstable; urgency=medium
+
+ * Backport get_task_ioprio changes from 510.85.02, acpi changes from
+510.85.02 and 515.65.01, drm_frambuffer.h changes from 515.76 to fix
+kernel module build for Linux 6.0. (Closes: #1021974, #1022738)
+
+ -- Andreas Beckmann Mon, 24 Oct 2022 18:00:40 +0200
+
+nvidia-graphics-drivers-tesla-470 (470.141.03-2) unstable; urgency=medium
+
+ * Rebuild as Tesla 470 driver.
+
+ -- Andreas Beckmann Tue, 27 Sep 2022 16:37:25 +0200
+
+nvidia-graphics-drivers (470.141.03-2) unstable; urgency=medium
+
+ * Add support for unversioned Tesla packages (tesla 510.85.02-1).
+(Closes: #1020697)
+ * Switch *-source to a modern module-assistant based template.
+ * Drop support for kernel-package and make-kpkg, gone since stretch.
+
+ -- Andreas Beckmann Tue, 27 Sep 2022 14:18:14 +0200
debian/README.source
| 49 +--
debian/bug-control.mk
| 8 +-
debian/build-module-packages.sh.in
| 2 +-
debian/changelog
| 761 +---
debian/control
| 27 +-
debian/control.in
| 34 +-
debian/control.kmod
| 6 +-
debian/control.md5sum
| 8 +-
debian/gbp.conf
| 2 +-
debian/libglx-nvidia0.lintian-overrides.in
| 1 +
debian/module/debian/README.Debian
| 11 -
debian/module/debian/clean
| 7 -
debian/module/debian/{control.template.binary.in =>
control.modules.in.binary.in} | 16 +-
debian/module/debian/genchanges
| 21 --
debian/module/debian/{install.template.in => install.modules.in.in}
| 0
debian/module/debian/kernel-version
| 40 ---
Bug#710523: i18nspector: Please i18n man page
Hello Jakub, thanks for the update. On Thu, Dec 08, 2022 at 12:17:38AM +0100, Jakub Wilk wrote: > * Helge Kreutzmann , 2022-11-06 09:25: > > > > Please add a framework for providing localized man pages, > > > > possibly using po4a or similar tools. > > > > > > I don't plan to add such a framework upstream, at least for the time > > > being. Of course, the Debian maintainer is free to implement it on > > > his own if he wishes so. :) > > > > Is this still the case (see also below)? > > I'd expect that i18nspector users know English, so this doesn't sound to me > like a good investment. I'm not sure. Maybe non-english speaking users simply did not use the tool so far? Or maybe you did not hear from them? I translation, native and non native users are working, and lowering barriers is not too bad. > Moreover, I no longer have any use for i18nspector, so my motivation to hack > on it has dropped to near-zero. I don't plan to add any new features. > Sorry! I understand. If this changes, I can most certainly provide patches, but I would only invest the time if those have a chance of being integrated. But of course I don't know if/which translators would actually translate the man page. I might do it for German, but it is quite big (which is good). Again, thanks for the update. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1025749: l10n stats pages: query clause to get ISO languages is too restrictive
Package: www.debian.org
X-Debbugs-CC: debian-l10n-de...@lists.debian.org,debian-i...@lists.debian.org
Usertag: scripts
Severity: wishlist
Hello,
To get the list of languages and countries, many of l10n pages (such
as podebconf¹ templates and/or po files²), make use (among others) of
«dgettext» utility (see related scripts here³⁴):
This is fine and a very convenient way to centralize resources, but the
current clause used by these commands to display languages is a bit
restrictive in the way it just queries for ISO 639-3 domain which is a
standard which does not include so called «collective languages» (eg.,
«ber» for bereber languages).
Full explanation can be read here⁵ but in brief, what Wikipedia says is
that ISO 639-3 is not a superset of ISO 639-2, so if we just query
inside one, we are discarding others:
While ISO 639-2 includes three-letter identifiers for collective
languages, these codes are excluded from ISO 639-3. Hence ISO 639-3 is
not a superset of ISO 639-2.
So, since this commit⁶ done 11 years ago, replacing ISO 639 for ISO
639-3, now some languages are not properly showing their localized names
in PO stats pages, because the ISO 639-3 code table does not include
them (this is by design), for instance, see the stats page for PO files²:
aym — Unknown language
bh — Unknown language
ber — Unknown language
bos_DE — Unknown language
bos_ES — Unknown language
bos_FI — Unknown language
bos_FR — Unknown language
bos_HU — Unknown language
bos_IT — Unknown language
bos_LT — Unknown language
bos_NL — Unknown language
bos_SV — Unknown language
bos_TR — Unknown language
(...)
There are 65 more languages displayed as «Unknown language» despite
they are fully translated in their respective iso-codes packages,
and this happens because of this query clause inside «dtc.def»:
if ($lang_fullname ne '') {
$lang_fullname = dgettext("iso_639_3", "$lang_fullname");
} else {
return qq();
}
So I wonder if we can do something to improve this clause to get a more
inclusive query that can match a higher number of domain ISO codes, and
not limiting the scope to just one standard that discards many others :-)
Some questions/thoughts regarding this:
Can «dgettext» return/query/output several or more that one ISO
standard? That would be great and facilitate things here.
As for «dgettext», it looks to me that just returns one string, but
maybe some magic can be done before getting «Unknown language» (ie.,
perform an additional query to ISO 639-2 before).
Hope the problematic is clear and we can get a nice solution for this.
¹https://www.debian.org/international/l10n/po-debconf/index.en.html
²https://www.debian.org/international/l10n/po/index.en.html
³https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/international/l10n/dtc.def
⁴https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/international/l10n/scripts/fix-files.sh
⁵https://en.wikipedia.org/wiki/ISO_639-3#Collective_languages
⁶https://salsa.debian.org/webmaster-team/webwml/-/commit/2bb96f31eabe559e1b68313efcbaaa7af3be19d4
Kind regards,
--
Camaleón
Bug#1025740: sudo: autopkgtest fails because of missing git
Control: tags -1 - moreinfo Control: tags -1 confirmed Control: retitle -1 autopkgtest fails because of missing git if called directly thanks On Thu, Dec 08, 2022 at 02:34:50PM +0100, Gioele Barabucci wrote: > I think this is the normal behavior: `autopkgtest-build-lxc` is cycling > through all lxc-create backends. At the end it (silently) settles on "dir": > the basic backend that stores lxc images in plain directories. After that it > starts downloading all needed files. I eventually aborted the debootstrap after like three hours, finally found the docs on ci.debian.net and pointed the build towards my local mirror with env debci_mirror. I cannot reproduce the issue you are reporting. Both autopkgtest --user debci sudo -- lxc --sudo autopkgtest-unstable-amd64 (using the version that is currently in unstable) and autopkgtest --user debci ../build-area/sudo_1.9.12p1-1~_amd64.changes (checked out and built from current git head) start running the tests and fail in 03-getroot-ldap, which is the same issue that I am seeing in debspawn. autopkgtest --user debci . -- lxc --sudo autopkgtest-unstable-amd64 shows the same issue like you see. I won't be able to investigate this before the weekend (unless my curiosity and procrastination tendencies force me away from the things I am supposed to be doing). And I'll need the help of someone more familiar with autopkgtest to figure this out. Greetings Marc
Bug#1025748: libreoffice-help-en-us: change depends to www-browser instead of naming particular browsers?
Package: libreoffice-help-en-us Version: 1:7.0.4-4+deb11u4 Severity: wishlist I use chrome and brave as my web browsers, but have to install firefox or epiphany because of this package. It seems nicer to depend on the virtual www-browser so then the numerous browsers that are in the debian repos (not even counting my case of using third-party repos) could be used, rather than forcing someone to install a browser they won't actually use. Obviously, this is a tiny feature request, but I also don't see any downsides. Thank you for your consideration. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-help-en-us depends on: ii epiphany-browser 3.38.2-1+deb11u3 ii libreoffice-common [libreoffice-l10n-en-us] 1:7.0.4-4+deb11u4 ii libreoffice-help-common 1:7.0.4-4+deb11u4 Versions of packages libreoffice-help-en-us recommends: ii libreoffice-core 1:7.0.4-4+deb11u4 libreoffice-help-en-us suggests no packages. -- no debconf information
Bug#1025372: RFS: nss-tls/1.1-1.1 [NMU] -- utility like nslookup(1), but uses libnss_tls.so instead of DNS
On Sat, Dec 03, 2022 at 11:53:23AM +0100, Gioele Barabucci wrote: > I am looking for a sponsor for a NMU of the package "nss-tls": > nss-tls (1.1-1.1) unstable; urgency=medium > . >* Non-maintainer upload. >* d/libnss-tls.nss: Install NSS service `tls` via dh_installnss > (Closes: #1024688) Hi! Could you please follow the NMU procedure? This is not a high-severity or urgent bug, thus I see no reason to skip the rules. The Policy has details, but in short: please post to a bug (in this case #1024688) that you intend to do a NMU, adding a debdiff of the proposed changes (in this case, the Salsa merge request should be enough). Only then the clock starts ticking, which is 10 days for regular NMUs. Of course, if you believe the maintainer won't react, uploading to DELAYED/10 (which in this case is done by a sponsor) will fulfill this requirement while not requiring you to remember to do an action in the future. But in either case, the intent-to-NMU mail is still required. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Bug#1025735: linux-image-6.0.0-5-amd64: Logitech camera only uses USB 1.1 (Full speed), not enough bandwidth
Control: tag -1 upstream On Thursday, 8 December 2022 12:48:08 CET Marco Moock wrote: > > Has it worked properly before with an older kernel? If so, which? > > No, it is a general problem. Tagging the bug accordingly On Thursday, 8 December 2022 09:39:40 CET Marco Moock wrote: >My Logitech Inc. QuickCam Communicate STX USB Webcam 046d:08d7 can't >use USB 2.0, although the manufacturer says it supports it. > >That causes that the bandwidth is not enough for the higher >resolutions. This results in a faulty image in certain applications >like Firefox or Microsoft Edge. > >Message in dmesg >[ 193.679885] gspca_main: gspca_zc3xx-2.14.0 probing 046d:08d7 This should be reported upstream. ~/dev/kernel.org/linux$ scripts/get_maintainer.pl drivers/media/usb/gspca/zc3xx.c Hans Verkuil (odd fixer:GSPCA USB WEBCAM DRIVER) Mauro Carvalho Chehab (maintainer:MEDIA INPUT INFRASTRUCTURE (V4L/DVB)) linux-me...@vger.kernel.org (open list:GSPCA USB WEBCAM DRIVER) linux-ker...@vger.kernel.org (open list) Those are the people/MLs you should write to wrt this issue. Once you've done that, please report the URL of that discussion so that we can track its progress too. signature.asc Description: This is a digitally signed message part.
Bug#1025745: libhdf4: add support for loongarch64
Control: tags -1 pending Thanks for the patch, it's applied in git and forwarded upstream. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1025309: jamin: FTBFS with fftw3 (3.3.10-1)
On 12/2/22 13:03, Bas Couwenberg wrote: The attached patch resolves the issue by changing the dependency to libfftw3-dev. The patch is applied in git: https://salsa.debian.org/multimedia-team/jamin/-/commit/92a3958d9af04a8b1e3a8f9c6b39ce946976810f Jonas has removed himself from Uploaders leaving the package without an active maintainer. It should probably be removed as the last maintainer upload was in 2017. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1025746: vienna-rna: FTBFS: Package 'RNAlib2', required by 'virtual:world', not found
Source: vienna-rna Version: 2.4.17+dfsg-2 Severity: serious Tags: ftbfs sid bookworm Justification: fails to build from source (but built successfully in the past) Hi, vienna-rna recently started to FTBFS, this is probably related to a change in the toolchain or a build dependency: ... checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for RNAlib2 >= 2.2.0... no checking for RNAlib2 >= 2.0... no configure: error: Package requirements (RNAlib2 >= 2.0) were not met: Package 'RNAlib2', required by 'virtual:world', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables VRNA2_CFLAGS and VRNA2_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. configure: error: ./configure failed for src/Kinfold ... Andreas vienna-rna_2.4.17+dfsg-2.log.gz Description: application/gzip
Bug#1025734: [Pkg-kde-extras] Bug#1025734: Segvault on startup
Sandro Knauß schrieb am Thu 08. Dec, 14:07 (+0100): > Hi, > > I cannot reproduce the failure for my setup. Do you use KDE Plasma as Desktop > Environment? It may be that a indirect dependency is installed at my setup > and > not at yours. I update the QML dependencies with -2, please try again with > that version. I use AwesomeWM with X11. It seams have to do something with QML. I forgot to send these messages I get on startup with the first mail: ``` % neochat QSystemTrayIcon::setVisible: No Icon set QQmlApplicationEngine failed to load component qrc:/main.qml:29:5: Type RoomPage unavailable qrc:/RoomPage.qml:569:17: Type FancyEffectsContainer unavailable qrc:/FancyEffectsContainer.qml:7:1: module "QtQuick.Particles" is not installed zsh: segmentation fault (core dumped) neochat ``` -- Freiheit heißt, die Wahl zu haben, wessen Sklave man ist. signature.asc Description: PGP signature
Bug#1025745: libhdf4: add support for loongarch64
Package: libhdf4
Version: 4.2.15-5
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64
Dear maintainers,
I have added support for loongarch64 in libhdf4 source package.
The results of test-units(make check) all passed.
Please consider applying the attached patch.
thanks,
Dandan Zhang
diff --git a/hdf/src/hconv.h b/hdf/src/hconv.h
index 7f0cf0d..d0c4cdf 100644
--- a/hdf/src/hconv.h
+++ b/hdf/src/hconv.h
@@ -59,7 +59,7 @@
/* CONSTANT DEFINITIONS */
/*/
/* Generally Big-Endian machines */
-#if !defined(INTEL86) && !defined(MIPSEL) && !defined(DEC_ALPHA) && !defined(I860) && !defined(SUN386) && !(defined(__ia64) && !(defined(hpux) || defined(__hpux))) && !defined(__x86_64__) && !(defined(__powerpc__) && defined(__LITTLE_ENDIAN__)) && !defined(__aarch64__) && !defined(__ARM_EABI__) && !defined(__riscv)
+#if !defined(INTEL86) && !defined(MIPSEL) && !defined(DEC_ALPHA) && !defined(I860) && !defined(SUN386) && !(defined(__ia64) && !(defined(hpux) || defined(__hpux))) && !defined(__x86_64__) && !(defined(__powerpc__) && defined(__LITTLE_ENDIAN__)) && !defined(__aarch64__) && !defined(__ARM_EABI__) && !defined(__riscv) && !defined(__loongarch64)
# define UI8_IN DFKnb1b /* Unsigned Integer, 8 bits */
# define UI8_OUTDFKnb1b
# define SI16_INDFKnb2b /* S = Signed */
diff --git a/hdf/src/hdfi.h b/hdf/src/hdfi.h
index bdb94cc..f5ec978 100644
--- a/hdf/src/hdfi.h
+++ b/hdf/src/hdfi.h
@@ -84,6 +84,7 @@
#define DFMT_SH 0x4441
#define DFMT_SHEB 0x
#define DFMT_RISCV640x4441
+#define DFMT_LOONGARCH640x4441
/* I/O library constants */
#define UNIXUNBUFIO 1
@@ -1087,6 +1088,58 @@ typedef long hdf_pint_t; /* an integer the same size as a pointer
#endif /* Linux/aarch64 */
+#if defined (__linux__) && defined (__loongarch64)
+
+#ifdef GOT_MACHINE
+If you get an error on this line more than one machine type has been defined.
+Please check your Makefile.
+#endif
+#define GOT_MACHINE 1
+
+#include
+#include /* for unbuffered file I/O */
+#include
+#include
+#include /* for character macros */
+
+#define DF_MT DFMT_LOONGARCH64
+
+typedef void VOID;
+typedef void *VOIDP;
+typedef char *_fcd;
+typedef char char8;
+typedef unsigned char uchar8;
+typedef signed char int8;
+typedef unsigned char uint8;
+typedef short int int16;
+typedef unsigned short int uint16;
+typedef int int32;
+typedef unsigned int uint32;
+typedef int intn;
+typedef unsigned int uintn;
+typedef float float32;
+typedef doublefloat64;
+typedef int intf; /* size of INTEGERs in Fortran compiler */
+typedef long hdf_pint_t; /* an integer the same size as a pointer */
+#define FNAME_POST_UNDERSCORE
+#define _fcdtocp(desc) (desc)
+#define FILELIB UNIXBUFIO
+
+#ifndef BIG_LONGS
+#define BIG_LONGS
+#endif
+
+/* JPEG #define's - Look in the JPEG docs before changing - (Q) */
+
+/* Determine the memory manager we are going to use. Valid values are: */
+/* MEM_DOS, MEM_ANSI, MEM_NAME, MEM_NOBS. See the JPEG docs for details on */
+/* what each does */
+#define JMEMSYS MEM_ANSI
+#define HAVE_STDC
+#define INCLUDES_ARE_ANSI
+
+#endif /* Linux/loongarch64 */
+
#if defined (__linux__) && defined (__riscv) && (__riscv_xlen == 64)
#ifdef GOT_MACHINE
diff --git a/mfhdf/libsrc/netcdf.h.in b/mfhdf/libsrc/netcdf.h.in
index d8e8b0b..6de3477 100644
--- a/mfhdf/libsrc/netcdf.h.in
+++ b/mfhdf/libsrc/netcdf.h.in
@@ -293,7 +293,7 @@ typedef doublencdouble;
/*
* Variables/attributes of type NC_LONG should use the C type 'nclong'
*/
-#if defined __alpha || (_MIPS_SZLONG == 64) || defined __ia64 || (defined __sun && defined _LP64) || defined AIX5L64 || defined __x86_64__ || defined __powerpc64__ || (defined __sparc__ && defined __arch64__) || defined __s390x__ || defined __aarch64__ || (defined __riscv && __riscv_xlen == 64)
+#if defined __alpha || (_MIPS_SZLONG == 64) || defined __ia64 || (defined __sun && defined _LP64) || defined AIX5L64 || defined __x86_64__ || defined __powerpc64__ || (defined __sparc__ && defined __arch64__) || defined __s390x__ || defined __aarch64__ || (defined __riscv && __riscv_xlen == 64) || defined __loongarch64
/*
* LP64 (also known as 4/8/8) denotes long and pointer as 64 bit types.
* http://www.unix.org/version2/whatsnew/lp64_wp.html
diff --git a/mfhdf/ncgen/ncgen.l b/mfhdf/ncgen/ncgen.l
index cdaf0af..b19c82b 100644
--- a/mfhdf/ncgen/ncgen.l
+++ b/mfhdf/ncgen/ncgen.l
@@ -113,7 +113,7 @@ FloatInf|Infinity|Inf{/* float missing values */
yyerror(errstr);
}
-#if defined __alpha || (_MIPS_SZLONG == 64) || defined __ia64
Bug#1025740: sudo: autopkgtest fails because of missing git
On 08/12/22 13:25, Marc Haber wrote: On Thu, Dec 08, 2022 at 01:17:34PM +0100, Gioele Barabucci wrote: On 08/12/22 13:11, Marc Haber wrote: As of 2022-12-08 this can be reproduced with the following commands: $ sudo autopkgtest-build-lxc debian sid $ autopkgtest . -- lxc --sudo autopkgtest-sid I have never used lxc, but this looks like erroring out: [14/4914]mh@salida:~ $ sudo autopkgtest-build-lxc debian sid lxc-create: autopkgtest-sid.new: ../src/lxc/storage/btrfs.c: btrfs_create: 938 Inappropriate ioctl for device - Failed to create btrfs subvolume "/var/lib/lxc/autopkgtest-sid.new/rootfs" lxc-create: autopkgtest-sid.new: ../src/lxc/storage/zfs.c: zfs_create: 735 Failed to create zfs dataset "zfs:lxc/autopkgtest-sid.new": lxc-create: autopkgtest-sid.new: ../src/lxc/utils.c: run_command_internal: 1609 Failed to exec command lxc-create: autopkgtest-sid.new: ../src/lxc/storage/lvm.c: do_lvm_create: 165 Failed to create logical volume "autopkgtest-sid.new": Volume group "lxc" not found Cannot process volume group lxc lxc-create: autopkgtest-sid.new: ../src/lxc/storage/lvm.c: lvm_create: 623 Error creating new logical volume "lvm:/dev/lxc/autopkgtest-sid.new" of size "1073741824 bytes" debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-sid-amd64 ... Downloading debian minimal ... I: Retrieving InRelease I think this is the normal behavior: `autopkgtest-build-lxc` is cycling through all lxc-create backends. At the end it (silently) settles on "dir": the basic backend that stores lxc images in plain directories. After that it starts downloading all needed files. If you ignore the initial warnings and let it finish, autopkgtest-build-lxc will (should...) eventually create the base image. Regards, -- Gioele Barabucci
Bug#946979: JavaScript list on lists.debian.org
Hi, I fully support this request Cheers. Yadd -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Bug#1025743: Acknowledgement (libfftw3-dev: Tests fails)
reassign 1025743 gsequencer thanks On 08 déc. 2022 13:18, "Debian Bug Tracking System" wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1025743: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025743. I did this bug report too quickly. The guilty is gsequencer. Christian
Bug#1025744: greetd - FTBFS with new version of rust-nix.
Package: greetd
Version: 0.8.0-1
Severity: important
I have updated rust-nix in experimental, and intend to do so in unstable
soon, the code in your package builds fine with the new version, but
the Cargo dependencies don't allow it to be used. The attached patch
updates the Debian and Cargo dependencies in your package to be consistent
with each other.
I may NMU this later.diff -Nru greetd-0.8.0/debian/changelog greetd-0.8.0/debian/changelog
--- greetd-0.8.0/debian/changelog 2022-10-03 05:22:59.0 +
+++ greetd-0.8.0/debian/changelog 2022-12-08 13:04:43.0 +
@@ -1,3 +1,12 @@
+greetd (0.8.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Consistently depend on version 0.24 or greater of the nix crate in both
+Debian packaging and Cargo.toml. 0.24 seems to be the minimum version
needed
+to build the patched source code.
+
+ -- Peter Michael Green Thu, 08 Dec 2022 13:04:43 +
+
greetd (0.8.0-1) unstable; urgency=medium
* Initial release (Closes: #1010247).
diff -Nru greetd-0.8.0/debian/control greetd-0.8.0/debian/control
--- greetd-0.8.0/debian/control 2022-10-03 05:22:59.0 +
+++ greetd-0.8.0/debian/control 2022-12-08 13:04:02.0 +
@@ -6,7 +6,7 @@
debhelper-compat (= 13),
dh-cargo,
# greetd & greetd_ipc
- librust-nix-dev (>= 0.19),
+ librust-nix-dev (>= 0.24),
librust-pam-sys-dev (>= 0.5.6),
librust-users-dev (>= 0.11.0),
librust-serde-derive-dev (>= 1.0),
diff -Nru greetd-0.8.0/debian/patches/relax_deps.patch
greetd-0.8.0/debian/patches/relax_deps.patch
--- greetd-0.8.0/debian/patches/relax_deps.patch2022-10-03
05:22:59.0 +
+++ greetd-0.8.0/debian/patches/relax_deps.patch2022-12-08
13:03:31.0 +
@@ -4,22 +4,26 @@
Description: Relax deps to avoid packaging extra versions
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
a/agreety/Cargo.toml
-+++ b/agreety/Cargo.toml
-@@ -13,4 +13,4 @@
+Index: greetd-0.8.0/agreety/Cargo.toml
+===
+--- greetd-0.8.0.orig/agreety/Cargo.toml
greetd-0.8.0/agreety/Cargo.toml
+@@ -13,4 +13,4 @@ inish = { path = "../inish"}
rpassword = "5.0"
getopts = "0.2"
enquote = "1.0.3"
-nix = "0.19"
-+nix = "~0.25.0"
a/greetd/Cargo.toml
-+++ b/greetd/Cargo.toml
-@@ -11,7 +11,7 @@
++nix = ">= 0.24.0"
+Index: greetd-0.8.0/greetd/Cargo.toml
+===
+--- greetd-0.8.0.orig/greetd/Cargo.toml
greetd-0.8.0/greetd/Cargo.toml
+@@ -11,7 +11,7 @@ repository = "https://git.sr.ht/~kennyle
debug = []
[dependencies]
-nix = "0.19"
-+nix = "~0.25.0"
++nix = ">= 0.24.0"
pam-sys = "0.5.6"
users = "0.11.0"
serde = { version = "1.0", features = ["derive"] }
Bug#1024993: sbuild: SUDO_FORCE_REMOVE=yes has no effect anymore
Version: 0.81.2+deb11u1 El 8/12/22 a las 10:45, Johannes Schauer Marin Rodrigues escribió: I'm not able to reproduce your problem when building src:neutron. At which point is the build attempting to remove the sudo package? When it was happening, it happened at the end of the package build, when the build-dependencies are being uninstalled. After double-checking now, I'm unable to reproduce it myself, and I don't know why it happened to me before. Closing as invalid. Sorry for the noise, I wrongly believed this was a general problem. Thanks a lot.
Bug#1025743: libfftw3-dev: Tests fails
Package: libfftw3-dev Version: 3.3.10-1 Severity: serious Dear Maintainer, As tests fails, fftw3 is stuck in unstable. >From >https://ci.debian.net/data/autopkgtest/testing/amd64/g/gsequencer/29127797/log.gz , | autopkgtest: WARNING: package gsequencer is not installed though it should be | autopkgtest: WARNING: package libags-dev is not installed though it should be | autopkgtest: WARNING: package libags-audio-dev is not installed though it should be | autopkgtest: WARNING: package libags-gui-dev is not installed though it should be | autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install on test deps directly for further data about failing dependencies in test logs | ags-integration-functional-test FAIL badpkg | blame: gsequencer | badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. | autopkgtest [01:16:05]: summary | ags-integration-unit-test FAIL badpkg | blame: gsequencer | badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. | ags-integration-functional-test FAIL badpkg | blame: gsequencer | badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. ` Christian -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.11 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libfftw3-dev depends on: ii libfftw3-bin 3.3.10-1 ii libfftw3-double3 3.3.10-1 ii libfftw3-long33.3.10-1 ii libfftw3-quad33.3.10-1 ii libfftw3-single3 3.3.10-1 libfftw3-dev recommends no packages. Versions of packages libfftw3-dev suggests: pn libfftw3-doc -- no debconf information
Bug#1025742: (WW) Option "-listen" for file descriptors is deprecated
Package: xwayland Version: 2:22.1.5-1 When XWalyand starts by a compositor (Mutter, KWin) - deprecated option "-listen" is used. That produces warnings in log like this: |kwin_wayland_wrapper[4038]: (WW) Option "-listen" for file descriptors is deprecated|| ||kwin_wayland_wrapper[4038]: Please use "-listenfd" instead.|| ||...|| ||org.gnome.Shell.desktop[131375]: (WW) Option "-listen" for file descriptors is deprecated|| ||org.gnome.Shell.desktop[131375]: Please use "-listenfd" instead.|| ||...|| ||gnome-shell[132400]: (WW) Option "-listen" for file descriptors is deprecated|| ||gnome-shell[132400]: Please use "-listenfd" instead.| That happens because there is no |xwayland.pc| file in the xwayland package or any other Debian's package. That file is present upstream and contains important information for compositors build systems to be aware of the new option and use it instead of the deprecated one: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/593 Support of that in Mutter: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1682 In KWin: https://invent.kde.org/plasma/kwin/-/merge_requests/739 If no |xwayland.pc| file found, compositors are built with an old deprecated option in use, thus is the problem. To solve this, I suggest to pick up the missing |xwayland.pc| file from the upstream here or in some other (-dev?) package: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xwayland/xwayland.pc.in Can be reproduced on Debian Sid and earlier, or any other derivatives (Ubuntu, etc.)
Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size
On 08/12/2022 at 13:05, Bastian Blank wrote: Hibernation does not work on any modern x86 machine Why ?
Bug#964761: Creating btrfs subvolumes with setup-storage fails in certain conditions
Thanks a lot for the patch. I hoped it would be that easy. I've already applied the patch. https://github.com/faiproject/fai/commit/8bf5ef41461edf9c64fb1e8095fd12d4789cc6f4 The upcoming release FAI 6.0 will include it. -- regards Thomas
Bug#946979: lists.debian.org: Have a mailing list archive for the JavaScript team.
Hello On Fri, 25 Mar 2022 23:35:59 +0530 Nilesh Patra wrote: Name: debian-js Rationale: Debian has over a thousand Javascript and related packages, most of which are maintained by the Debian Javascript team. Having this mailing list will help in better collaboration and discuss regarding upload plans for key packages which have a number of reverse-deps. It will also enable our users to have discussions regarding JS packages in a more effective mannger. We are currently using a alioth list, but due to high volumes of processing mails and other issues (like breaking DKIM sigs), we wish to request a l.d.o for the same. Short description: Using Debian for Javascript related packages and discussion around it Long Description: The Debian Javascript Packaging Team to coordinate about packaging software and their libraries/applications written in the Javascript programming language. Category: Developers Subscription Policy: open Post Policy: open Web Archive: yes This request has been pending for so long (~3 years). Anything blocking this? I would very much like to see this happen as it would create a space for clutter free discussions :) This would enable more developers to join as many avoid subscribing to the list due to massive amount of automated mails. Thanks -- Mohammed Bilal 2D65 BC1E B966 5A6E 97F9 730A B3F5 9452 8521 9E1F OpenPGP_signature Description: OpenPGP digital signature
Bug#1025740: sudo: autopkgtest fails because of missing git
On Thu, Dec 08, 2022 at 01:17:34PM +0100, Gioele Barabucci wrote: > On 08/12/22 13:11, Marc Haber wrote: > > > As of 2022-12-08 this can be reproduced with the following commands: > > > > > > $ sudo autopkgtest-build-lxc debian sid > > > $ autopkgtest . -- lxc --sudo autopkgtest-sid > > > > I cannot currently reproduce this since autopkgtestest lxc wants some > > kind of btrfs setup which I don't have. > > Strange. On my unstable installation I did not have to set up btrfs in any > way. I see that `lxc` Suggests `btrfs-progs`, but that's it. I have never used lxc, but this looks like erroring out: [14/4914]mh@salida:~ $ sudo autopkgtest-build-lxc debian sid lxc-create: autopkgtest-sid.new: ../src/lxc/storage/btrfs.c: btrfs_create: 938 Inappropriate ioctl for device - Failed to create btrfs subvolume "/var/lib/lxc/autopkgtest-sid.new/rootfs" lxc-create: autopkgtest-sid.new: ../src/lxc/storage/zfs.c: zfs_create: 735 Failed to create zfs dataset "zfs:lxc/autopkgtest-sid.new": lxc-create: autopkgtest-sid.new: ../src/lxc/utils.c: run_command_internal: 1609 Failed to exec command lxc-create: autopkgtest-sid.new: ../src/lxc/storage/lvm.c: do_lvm_create: 165 Failed to create logical volume "autopkgtest-sid.new": Volume group "lxc" not found Cannot process volume group lxc lxc-create: autopkgtest-sid.new: ../src/lxc/storage/lvm.c: lvm_create: 623 Error creating new logical volume "lvm:/dev/lxc/autopkgtest-sid.new" of size "1073741824 bytes" debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-sid-amd64 ... Downloading debian minimal ... I: Retrieving InRelease The machine in question HAS lvm, but no lxc VG. Where would I configure basic things like the mirror to download from or the VG to be used? Sorry for having to show my ignorance, just using debspawn has always been easier for me (but it of course costs time, so I am interested in learning about other autopkg backends). Maybe I have missed the autopkgtests docs, what I have found is less than helpful. 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#1025741: stubby: Outdated stubby.yml file
Package: stubby Version: 1.6.0-3 Severity: wishlist Dear Maintainer, stubby.yml packaged in getdns 1.6.0 is outdated as some of the default upstream resolvers are now retired (namely the "dnsovertls*.sinodun.com" Servers). There are a lot of changes in the optional upstreams section too Regards, -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux bookworm/sid Release:n/a Codename: bookworm Architecture: armv7l Kernel: Linux 5.15.76-v7+ (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages stubby depends on: ii libbsd0 0.11.7-1 ii libc62.35-2+rpi1 ii libgetdns10 1.6.0-3 ii libidn2-02.3.3-1 ii libssl3 3.0.7-1 ii libunbound8 1.17.0-1 ii libyaml-0-2 0.2.5-1 stubby recommends no packages. stubby suggests no packages. -- no debconf information
Bug#1025740: sudo: autopkgtest fails because of missing git
On 08/12/22 13:11, Marc Haber wrote: As of 2022-12-08 this can be reproduced with the following commands: $ sudo autopkgtest-build-lxc debian sid $ autopkgtest . -- lxc --sudo autopkgtest-sid I cannot currently reproduce this since autopkgtestest lxc wants some kind of btrfs setup which I don't have. Strange. On my unstable installation I did not have to set up btrfs in any way. I see that `lxc` Suggests `btrfs-progs`, but that's it. Regards, -- Gioele Barabucci
Bug#1025740: sudo: autopkgtest fails because of missing git
Control: tags -1 moreinfo help thanks On Thu, Dec 08, 2022 at 12:52:48PM +0100, Gioele Barabucci wrote: > autopkgtest currently fails with the following error message: > > Can't exec "git": No such file or directory at ../scripts/log2cl.pl line 40. > ../scripts/log2cl.pl: unable to run git log: No such file or directory at > ../scripts/log2cl.pl line 40. > make[2]: *** [Makefile:236: ChangeLog] Error 2 > make[2]: Leaving directory > '/tmp/autopkgtest-lxc.fhuumvs8/downtmp/build.mkq/real-tree/build-simple' > dh_auto_install: error: cd build-simple && make -j1 install > DESTDIR=/tmp/autopkgtest-lxc.fhuumvs8/downtmp/build.mkq/real-tree/debian/sudo > AM_UPDATE_INFO_DIR=no returned exit code 2 > make[1]: *** [debian/rules:63: override_dh_auto_install] Error 2 > make[1]: Leaving directory > '/tmp/autopkgtest-lxc.fhuumvs8/downtmp/build.mkq/real-tree' > make: *** [debian/rules:42: binary] Error 2 > dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned > exit status 2 > blame: . > badpkg: rules build failed with exit code 2 > autopkgtest [12:39:44]: ERROR: erroneous package: rules build failed with > exit code 2 in a null autopkgtest invoked inside debspawn, the build succeeds without error even with git not present. autopkgtest 03-getroot-ldap fails here as well since dpkg-configure slapd fails. I need to investgate that; I guess that's because of the incomplete init that a debspawn container here. And it looks like your autopkgtest doesn't get that far yet. > As of 2022-12-08 this can be reproduced with the following commands: > > $ sudo autopkgtest-build-lxc debian sid > $ autopkgtest . -- lxc --sudo autopkgtest-sid I cannot currently reproduce this since autopkgtestest lxc wants some kind of btrfs setup which I don't have. 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#1025257: chkrootkit: Add possibility to skip large directory scans in find
control: tags -1 - patch thanks On Thu, 1 Dec 2022, 15:06 Peter Gervai, wrote: Hi - > Would be nice to skip extremely large >directories which the admin choose to skip in >the scan. >Typical examples are /var/lib/backuppc or >similar backup dirs, or various large mounts. > not sure i would use this feature myself, but doesnt seem unreasonable. are there other use cases than large files? (I think most people use chkrootkit via the daily cron job - how does this interact with that?) does the patch apply against the version of chkrootkit with the - many tens of - existing debian patches? also, can you add autopktests for the new feature and add the option to the man page too(i didnt find what was written in the patch to the 'help' output very clear, if you could find a clearer explanation of what this is for that would help too). if you do all that, ill take a closer look. The following patch contains only a few changes in the find calls where it > uses a complete root dir scan. > I hope I was successful doing it POSIX safe, but please check. > i havent looked in detail but i think there are some issues that need fixing: ` ...` should be replaced by $(...). And variables look like they need quoting. you can use shellcheck to spot some of these issues. ...chkrootkit is itself full of issues like this, but we should be making it better with every patch. > (Sidenote: I see you commented out '-o' at the end of the $findargs, is it > correct this way?) > i dont know, but you should provide a recommendation as part of the patch. i wouldnt be surprised if it was an error - it wouldnt be the first bit if dubious code spotted in chkrootkit. But equally why would it end in -o ?
Bug#1024577: libzypp: diff for NMU version 17.25.7-2.3
Control: tags 1024577 + patch
[Replace XX with correct value]
Hello Mike,
I've prepared an NMU for libzypp (versioned as 17.25.7-2.3) and
uploaded it, non-delayed as LowThresholdNmu.
Kind regards
Andreas
diff -Nru libzypp-17.25.7/debian/changelog libzypp-17.25.7/debian/changelog
--- libzypp-17.25.7/debian/changelog 2022-10-06 22:17:51.0 +0200
+++ libzypp-17.25.7/debian/changelog 2022-12-08 12:07:05.0 +0100
@@ -1,3 +1,11 @@
+libzypp (17.25.7-2.3) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * 1010_gpgme-pkg_search_module.diff: Fix FTBFS against libgpgme-dev >=
+1.18.0-2 by using pkg_search_module(). Closes: #1024577
+
+ -- Andreas Metzler Thu, 08 Dec 2022 12:07:05 +0100
+
libzypp (17.25.7-2.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru libzypp-17.25.7/debian/patches/1010_gpgme-pkg_search_module.diff libzypp-17.25.7/debian/patches/1010_gpgme-pkg_search_module.diff
--- libzypp-17.25.7/debian/patches/1010_gpgme-pkg_search_module.diff 1970-01-01 01:00:00.0 +0100
+++ libzypp-17.25.7/debian/patches/1010_gpgme-pkg_search_module.diff 2022-12-08 12:07:05.0 +0100
@@ -0,0 +1,45 @@
+Description: Use pkg-config to lacte gpgme
+Author: Andreas Metzler
+Bug-Debian: https://bugs.debian.org/1024577
+Origin: vendor
+Last-Update: 2022-12-08
+
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -218,17 +218,14 @@
+ # static case: Assert libsolv.a ist the last one linked
+ SET(LibSolv_LIBRARIES ${LibSolv_LIBRARIES} ${LIBSOLV_LIBRARY})
+ ENDIF()
+ ENDIF( LIBSOLV_SRCDIR AND LIBSOLV_BUILDDIR )
+
+-FIND_PACKAGE(Gpgme REQUIRED)
+-IF ( NOT GPGME_PTHREAD_FOUND )
+- MESSAGE( FATAL_ERROR " gpgme not found" )
+-ELSE()
+- INCLUDE_DIRECTORIES( ${GPGME_INCLUDES} )
+- LINK_DIRECTORIES(${GPGME_LIBRARY_DIR})
+-ENDIF()
++pkg_search_module(GPGME REQUIRED gpgme>=1.8.0)
++MESSAGE(STATUS "found gpgme ${GPGME_VERSION}" )
++INCLUDE_DIRECTORIES( ${GPGME_INCLUDE_DIRS} )
++LINK_DIRECTORIES(${GPGME_LIBRARY_DIRS})
+
+ FIND_PACKAGE(OpenSSL REQUIRED)
+
+ FIND_PACKAGE(Udev)
+ IF ( NOT UDEV_FOUND )
+--- a/zypp/CMakeLists.txt
b/zypp/CMakeLists.txt
+@@ -926,11 +926,11 @@
+ TARGET_LINK_LIBRARIES(${LIBNAME} ${LibSolv_LIBRARIES} )
+ TARGET_LINK_LIBRARIES(${LIBNAME} ${OPENSSL_LIBRARIES} )
+ TARGET_LINK_LIBRARIES(${LIBNAME} ${CRYPTO_LIBRARIES} )
+ TARGET_LINK_LIBRARIES(${LIBNAME} ${SIGNALS_LIBRARY})
+ TARGET_LINK_LIBRARIES(${LIBNAME} ${Boost_THREAD_LIBRARY})
+- TARGET_LINK_LIBRARIES(${LIBNAME} ${GPGME_PTHREAD_LIBRARIES})
++ TARGET_LINK_LIBRARIES(${LIBNAME} ${GPGME_LIBRARIES})
+ target_link_libraries(${LIBNAME} ${SIGCPP_LIBRARIES})
+ target_link_libraries(${LIBNAME} ${LIBGLIB_LIBRARIES})
+ target_link_libraries(${LIBNAME} ${YAML_CPP_LIBRARIES})
+
+ IF (ENABLE_ZSTD_COMPRESSION)
diff -Nru libzypp-17.25.7/debian/patches/series libzypp-17.25.7/debian/patches/series
--- libzypp-17.25.7/debian/patches/series 2022-10-06 22:17:48.0 +0200
+++ libzypp-17.25.7/debian/patches/series 2022-12-08 12:01:08.0 +0100
@@ -3,3 +3,4 @@
1004_fix-fastcgi-includes.patch
0001-Add-missing-includes-for-GCC-11-bsc-1181874.patch
0001-Fix-building-with-GCC-12.x-release.patch
+1010_gpgme-pkg_search_module.diff
signature.asc
Description: PGP signature
Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size
On Thu, Dec 08, 2022 at 11:35:43AM +0100, Jan Kowalsky wrote: > So: please set a default again which is reasonable for laptops and > workstations. We always recommend debian for desktops to our customers. > But if many things are not really suitable for Desktops people will > avoid debian. The current default is suitable. Hibernation does not work on any modern x86 machine and you don't want to have huge swap on desktop machines as it only adds latency. Bastian -- Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, "The Conscience of the King", stardate 2818.9
Bug#1025735: linux-image-6.0.0-5-amd64: Logitech camera only uses USB 1.1 (Full speed), not enough bandwidth
Am 08.12.2022 schrieb Diederik de Haas : > Has it worked properly before with an older kernel? If so, which? No, it is a general problem.
Bug#1025740: sudo: autopkgtest fails because of missing git
Package: src:sudo Version: 1.9.11p3-3~ autopkgtest currently fails with the following error message: Can't exec "git": No such file or directory at ../scripts/log2cl.pl line 40. ../scripts/log2cl.pl: unable to run git log: No such file or directory at ../scripts/log2cl.pl line 40. make[2]: *** [Makefile:236: ChangeLog] Error 2 make[2]: Leaving directory '/tmp/autopkgtest-lxc.fhuumvs8/downtmp/build.mkq/real-tree/build-simple' dh_auto_install: error: cd build-simple && make -j1 install DESTDIR=/tmp/autopkgtest-lxc.fhuumvs8/downtmp/build.mkq/real-tree/debian/sudo AM_UPDATE_INFO_DIR=no returned exit code 2 make[1]: *** [debian/rules:63: override_dh_auto_install] Error 2 make[1]: Leaving directory '/tmp/autopkgtest-lxc.fhuumvs8/downtmp/build.mkq/real-tree' make: *** [debian/rules:42: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 blame: . badpkg: rules build failed with exit code 2 autopkgtest [12:39:44]: ERROR: erroneous package: rules build failed with exit code 2 As of 2022-12-08 this can be reproduced with the following commands: $ sudo autopkgtest-build-lxc debian sid $ autopkgtest . -- lxc --sudo autopkgtest-sid Regards, -- Gioele Barabucci
Bug#1024954: librcsb-core-wrapper: (autopkgtest) needs update for python3.11: initialization of CorePyWrap raised unreported exception
Hi again, On Mon, Nov 28, 2022 at 08:05:35PM +0530, Nilesh Patra wrote: > On Sun, 27 Nov 2022 22:26:31 +0100 Paul Gevers wrote: > > Source: librcsb-core-wrapper > > Version: 1.005-10 > > We are in the transition of adding python3.11 as a supported Python > > version [0]. > > [...] > > [0] https://bugs.debian.org/1021984 > > [1] https://qa.debian.org/excuses.php?package=python3-defaults > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/libr/librcsb-core-wrapper/28726239/log.gz > > > > Testing with python3.11: > > Traceback (most recent call last): > >File "", line 1, in > > SystemError: initialization of CorePyWrap raised unreported exception > > autopkgtest [17:14:04]: test autodep8-python3 > > There are a few similar bug reports with same error messages which aren't > helpful and > I am not quite sure as to how to debug errors like these. I did try to check > this using > gdb but I don't get anything helpful from this either. > > I also found similar bug reports on a few git hub projects, without any > closure/conclusion, > for instance this one[1] > > Could someone on the list please help fix this/point towards the right > direction to check so > this can be debugged ny further? Similar report is also filed for tagpy (Bug#1025201) -- could someone please help in fixing these? > [1]: https://github.com/hsnr-gamera/gamera-4/issues/54 -- Best, Nilesh signature.asc Description: PGP signature
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hi Fab,
please keep debian-cr...@lists.debian.org in the loop. Full quoting.
On Thu, Dec 08, 2022 at 08:29:52AM +0100, Fab Stz wrote:
> Not sure this fits your issue and if this could work.
>
> I used to produce android-builds that are sort of 'target' builds (and not
> host builds). There is a specific qmake to be called when building with a
> target-build. That qmake is in the bin directory of the target build. And
> that
> qmake uses the "target_qt.conf" file which should contain the path you expect.
Before we delve into this, I'd like to clarify terminology. I'm going to
assume that when you say "target" you mean "host" in GNU terminology and
when you say "host" you mean "build" in GNU terminology. Please correct
me if I got that wrong.
I think this is similar to what I called "a" and I'll call your variant
"a2" to ease comparison. In both cases, there is a specific qmake (either
a binary in case of a2 or a wrapper script in case of a). Both reference
separate qtconf. In case of qt5, the wrapper injects a -qtconf argument.
The aspect where this differ is the location. In a2 you have the
standard qmake6 name on a non-$PATH directory whereas in a, you a
different executable name on $PATH.
> However, for now, not all path are there and especially the Plugins dir isn't
> there. They will be once this is merged:
>
> https://codereview.qt-project.org/c/qt/qtbase/+/436758/19/cmake/
> QtQmakeHelpers.cmake
>
> Maybe a solution could be to run qmake by specifying your own target_qt.conf
> that has the values you need ?
I think we're closer that you might expect. For most non-Debian
ecosystems, you need a specific target_qt.conf due to the need for
sysroots. It is specific to the combination of build architecture and
host architecture (in Qt terminology: host architecture and target
architecture). However, cross building on Debian has done away with sysroots
and replaced them with multiarch. As such, we can remove the build
architecture (in Qt terminology: host architecture) from the
configuration and just use the existing
/usr/lib/${DEB_HOST_MULTIARCH}/qt6/qt6.conf. This is what we do for qt5
already.
To me this reinforces the view that we should rather go for a wrapper
than have our build matrix explode into O(n^2) (for n being the count of
architectures).
Let me give an example:
$ dpkg --print-architecture
amd64
$ sudo dpkg --add-architecture armhf
$ sudo apt update
...
$ sudo apt install qmake6:armhf
...
$ qmake6 -qtconf /usr/lib/arm-linux-gnueabihf/qt6/qt6.conf -query
QT_INSTALL_PLUGINS
/usr/lib/arm-linux-gnueabihf/qt6/plugins
$
And to do proposal a, we'd have a wrapper
/usr/bin/arm-linux-gnueabihf-qmake6 (just like the one for qt5) that
would inject the -qtconf argument. So that would become:
$ arm-linux-gnueabihf-qmake6 -query QT_INSTALL_PLUGINS
/usr/lib/arm-linux-gnueabihf/qt6/plugins
$
And then we could point Qt6::qmake at this path.
In order to support other workflows, we can also have a separate
directory with a symlink to this named just qmake6 to support the
sysroot approach.
I'd like to get some reply from Patrick before moving forward with this
though. And it would be super awesome if this could be included in
bookworm, so time isn't infinite here.
Helmut
Bug#1025739: hmmer2: missing source for configure
Source: hmmer2 Version: 2.3.2+dfsg-7 Severity: serious Justification: DFSG #2 Hi, The source code for the file configure in the source tarball is missing. This violates DFSG #2. Helmut
Bug#1025735: linux-image-6.0.0-5-amd64: Logitech camera only uses USB 1.1 (Full speed), not enough bandwidth
On Thursday, 8 December 2022 09:39:40 CET Marco Moock wrote: > Package: src:linux > Version: 6.0.10-2 > >My Logitech Inc. QuickCam Communicate STX USB Webcam 046d:08d7 can't >use USB 2.0, although the manufacturer says it supports it. Has it worked properly before with an older kernel? If so, which? signature.asc Description: This is a digitally signed message part.
Bug#1025738: swtpm: New upstream version
Source: swtpm Version: 0.7.1-1 Severity: wishlist Please import the new upstream version 0.8.0 to Debian.
Bug#1025334: Update binary package and XS-Go-Import-Path to match go.mod
On Sat, Dec 3 2022 at 01:59:47 AM +08:00:00 +08:00:00, Shengjing Zhu
wrote:
On Sat, Dec 3, 2022 at 1:54 AM Shengjing Zhu wrote:
On Sat, Dec 3, 2022 at 1:42 AM Pirate Praveen
wrote:
>
> Package: golang-github-cespare-xxhash
> Version: 2.1.1-2
>
> When building gitaly I get,
>
>
src/gitlab.com/gitlab-org/gitlab/vendor/github.com/prometheus/client_golang/prometheus/desc.go:22:2:
> cannot find package "github.com/cespare/xxhash/v2" in any of:
>
>
/<>/_build/src/gitlab.com/gitlab-org/gitlab/vendor/github.com/cespare/xxhash/v2
> (vendor tree)
> /usr/lib/go-1.19/src/github.com/cespare/xxhash/v2 (from
$GOROOT)
> /<>/_build/src/github.com/cespare/xxhash/v2
(from
> $GOPATH
>
> even though golang-github-cespare-xxhash-dev is installed.
>
> I think the import path and binary package name should be bumped
to
> match go.mod:
> module github.com/cespare/xxhash/v2
>
> so binary package should be golang-github-cespare-xxhash-v2-dev.
Though
> I'm not 100% sure about the XS-Go-Import-Path as I think it should
> match without a change there.
No. The Go compiler can find it automatically. Please see the
detail at
https://lists.debian.org/debian-go/2020/06/msg9.html
I think you may have done some non-standard magic in your package.
And you can find there are many packages which use
github.com/cespare/xxhash/v2 in the code.
https://codesearch.debian.net/search?q=filetype%3Ago+github.com%2Fcespare%2Fxxhash%2Fv2=1
But they are built successfully, including the
golang-github-prometheus-client-golang package.
I think the problem comes when a module in vendor tries to find this
module. The following lines fixes the error.
mkdir -p ${BUILDDIR}/vendor/github.com/cespare/xxhash
ln -s /usr/share/gocode/src/github.com/cespare/xxhash
${BUILDDIR}/vendor/github.com/cespare/xxhash/v2
here github.com/prometheus/client_golang is added in vendor because
gitlab (and gitaly) need golang-github-golang-protobuf-1-5-dev which
currently not possible to get via apt. Yes, this is a work around until
we fix the conflict.
Bug#1004488: Update grpc to new upstream version 1.37
On Fri, 9 Sep 2022 14:58:28 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > Hi, > > On Sat, Aug 27, 2022 at 2:09 PM Pirate Praveen wrote: > > Any update of the protobuf transition? We have just 4 months for > > bookworm transition freeze [1] so giving more time for people to fix > > broken packages is better than giving less time I think :) > It's my bad that it's me who tries to fix those broken packages. > Could do it now, just need to submit bugs/patches. > Unfortunately I won't have time for those this weekend. But I will do > it next week. Hi Laszlo, I can see protobuf 1.21 has migrated to testing. Any other blockers to upload grpc to unstable? thanks praveen > Regards, > Laszlo/GCS > >
Bug#1025737: pybuild-plugin-autopkgtest: missing support for custom tests
Package: pybuild-plugin-autopkgtest
Version: 5.20221205
Severity: normal
Control: affects -1 python-moderngl python-moderngl-glcontext
python-moderngl-window
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear fellow DPT members,
the autopkgtest runner ignores PYBUILD_TEST_CUSTOM, which breaks the
test suite for the moderngl packages; they need to be run in a virtual X
server with xvfb-run.
Relevant excerpt from d/rules (not released yet):
export PYBUILD_TEST_CUSTOM = 1
export PYBUILD_TEST_ARGS = xvfb-run -a {interpreter} -m pytest -k "not
test_mass_create"
Relevant excerpt from autopkgtest session:
autopkgtest [12:06:27]: test pybuild-autopkgtest: pybuild-autopkgtest
autopkgtest [12:06:27]: test pybuild-autopkgtest: [---
I: pybuild base:240: cd /tmp/autopkgtest.sRSdq8/autopkgtest_tmp/build;
python3.11 -m pytest xvfb-run -a python3.11 -m pytest -k "not test_mass_create"
ERROR: usage: __main__.py [options] [file_or_dir] [file_or_dir] [...]
__main__.py: error: unrecognized arguments: -a python3.11
inifile: None
rootdir: /tmp/autopkgtest.sRSdq8/autopkgtest_tmp/build
E: pybuild pybuild:386: test: plugin autopkgtest failed with: exit code=4:
cd /tmp/autopkgtest.sRSdq8/autopkgtest_tmp/build; python3.11 -m pytest xvfb-run
-a {interpreter} -m pytest -k "not test_mass_create"
I: pybuild base:240: cd /tmp/autopkgtest.sRSdq8/autopkgtest_tmp/build;
python3.10 -m pytest xvfb-run -a python3.10 -m pytest -k "not test_mass_create"
ERROR: usage: __main__.py [options] [file_or_dir] [file_or_dir] [...]
__main__.py: error: unrecognized arguments: -a python3.10
inifile: None
rootdir: /tmp/autopkgtest.sRSdq8/autopkgtest_tmp/build
E: pybuild pybuild:386: test: plugin autopkgtest failed with: exit code=4:
cd /tmp/autopkgtest.sRSdq8/autopkgtest_tmp/build; python3.10 -m pytest xvfb-run
-a {interpreter} -m pytest -k "not test_mass_create"
make: *** [/tmp/xwsr3ehK08/run:4: pybuild-autopkgtest] Error 13
pybuild-autopkgtest: error: /tmp/xwsr3ehK08/run pybuild-autopkgtest
returned exit code 2
autopkgtest [12:06:28]: test pybuild-autopkgtest: ---]
Cheers
Timo
-BEGIN PGP SIGNATURE-
iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmORxicACgkQ+C8H+466
LVlKwAwA05iW6qCF59RV8cONsyhTFs+t2KWG7leG7HENnodEr8QwOUCyspQ/u0se
4zXMKFRFIpjR9NRvNR+s7IjIkxYPcF5kKDvAsevxUD4BdjA+aoF6/jIg5ShDyGG4
FTZtVGJFIePMgt7kcndI0UmieXNBNxmdzODc4Weh7zlqpZoMn/NhrtLY6VcJgp4C
z+XxahB00MIbqXWQnVMP/itSdTHrWXJmJ8I49O/bkyLp1jgT4yDslJ5+VDIhYWHr
Y3I2qDT5f417yTjl0j0PG9ddKN9nQBlj49eAQkUd7RPuCBFcrh6lwqNLdXXZ7g8N
5UMKc9GUzZiat6mvcOQ+M1O+z8d4/R5tm9oDzqlpSdR/OdprxBZh7Ia7thBdjGmw
oTxIFFH6RaVil3n13kMwfqOWo7ELXZk5yg3mmoPG4U9Kp9Dziy/wGlAfKysfbtJZ
jWb3jr9KAE/b0qweYNI0hyenByC0KMCXCk9Vn9Opzpm2lJUi4YblDywApgyt1jN2
4hWSWtrH
=U/f8
-END PGP SIGNATURE-
Bug#1025318: Acknowledgement (nextcloud-desktop: libGL error: failed to load driver: i915 (Segmentation fault))
> Debian Bug Tracking System 於2022年12月2日 21:57寫道： > > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1025318: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025318. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > ownCloud for Debian maintainers > > > If you wish to submit further information on this problem, please > send it to 1025...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1025318: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025318 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#1025736: nodejs: Always segfaults on riscv64
Package: nodejs Version: 18.12.1+dfsg-2+0.riscv64.1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: davidventura27+deb...@gmail.com Dear Maintainer, * What led up to the situation? Trying to execute nodejs in any condition under riscv64. * What exactly did you do (or not do) that was effective (or ineffective)? I ran `nodejs --help`, but the problem is not limited to the `--help` flag. * What was the outcome of this action? A segmentation fault: ``` root@debian:~/checkout# node --help [159/1912] Segmentation fault (core dumped) ``` * What outcome did you expect instead? Nodejs would execute. * Extra notes: I am testing riscv64 inside qemu: ``` qemu-system-riscv64 -machine virt -cpu sifive-u54 -smp 4 -m 2G -device virtio-blk-device,drive=hd -drive file=overlay.qcow2,if=none,id=hd -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -object rng-random,filename=/dev/urandom,id=rng -device virtio-rng-device,rng=rng -append root=LABEL=rootfs console=ttyS0,115200 -netdev type=tap,id=net,ifname=tap0,vhost=on -device virtio-net-pci,netdev=net -nographic ``` Nodejs version (from unreleased/main) ``` root@debian:~/checkout# apt-cache policy nodejs nodejs: Installed: 18.12.1+dfsg-2+0.riscv64.1 Candidate: 18.12.1+dfsg-2+0.riscv64.1 Version table: *** 18.12.1+dfsg-2+0.riscv64.1 500 500 http://deb.debian.org/debian-ports unreleased/main riscv64 Packages 100 /var/lib/dpkg/status ``` Configured cpuinfo: ``` root@debian:~/checkout# cat /proc/cpuinfo processor : 0 hart: 0 isa : rv64imafdc mmu : sv57 processor : 1 hart: 1 isa : rv64imafdc mmu : sv57 processor : 2 hart: 2 isa : rv64imafdc mmu : sv57 processor : 3 hart: 3 isa : rv64imafdc mmu : sv57 ``` Captured backtrace with gdb: ``` root@debian:~/checkout# gdb node -c /tmp/core-node.17623.debian.1670493754 GNU gdb (Debian 12.1-4) 12.1 Reading symbols from node... (No debugging symbols found in node) [New LWP 17623] [New LWP 17624] [New LWP 17625] [New LWP 17627] [New LWP 17626] [New LWP 17628] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1". Core was generated by `node --help'. Program terminated with signal SIGSEGV,
Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size
Hi all, we do second this. While we always installed workstations automatically with debian preseeding and the default receipts (lvm encrypted) we noticed the defaults suddenly changed in bullseye. I would support the assumption that for server installations this is not a big issue since one (at least we) do special partitioning any way for servers. So: please set a default again which is reasonable for laptops and workstations. We always recommend debian for desktops to our customers. But if many things are not really suitable for Desktops people will avoid debian. Thanks Jan -- datenkollektiv.net OHG Böhmische Str. 14 01099 Dresden Tel: (0351) 41 88 66 00 E-Mail: carsten.ungewit...@datenkollektiv.net http://www.datenkollektiv.net Registergericht: Amtsgericht Dresden HRA 11427
Bug#1005219: minidlna: Floods logfile with 'minidlna.c:166: error: accept(http): Too many open files'
Package: minidlna Followup-For: Bug #1005219 Version 1.3.0 has a confirmed socket leak that should be fixed in 1.3.1 with https://sourceforge.net/p/minidlna/git/ci/2c66335a9b63387728496e2fea4fbefc080ceebe/ Btw. 1.3.2 is out. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, mingw64-amd64, mingw64-i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages minidlna depends on: ii adduser3.129 ii init-system-helpers1.65.2 ii libavformat59 7:5.1.2-1 ii libavutil577:5.1.2-1 ii libc6 2.36-5 ii libexif12 0.6.24-1+b1 ii libflac12 1.4.2+ds-2 ii libid3tag0 0.15.1b-14 ii libjpeg62-turbo1:2.1.2-1+b1 ii libogg01.3.5-1 ii libsqlite3-0 3.40.0-1 ii libvorbis0a1.3.7-1 ii lsb-base 11.5 ii sysvinit-utils [lsb-base] 3.05-7 minidlna recommends no packages. minidlna suggests no packages.
Bug#1017082: neomutt: (security) The sender’s timezone is exposed in the Date: header
Hello, On Sat, Aug 13, 2022 at 11:41:49AM +0200, debbug.neom...@sideload.33mail.com wrote: > Package: neomutt > Version: 20201127+dfsg.1-1.2 > Severity: normal > Tags: upstream > X-Debbugs-Cc: debbug.neom...@sideload.33mail.com > > The “Date:” field is added after the user instructs neomutt to send > their message, so there is no opportunity for the user to edit the > timestamp of the message. Perhaps rightly so, for RFC-compliance. But > the timestamp that mutt generates exposes the timezone of the > author. It’s too much information. E.g. this reveals to the recipient > and all mail servers enroute that the sender is physically in the > central Europe timezone: > > Date: Fri, 12 Aug 2022 13:21:24 +0200 > > This exposes the presence of senders in the eastern US timezone: > > Date: Fri, 12 Aug 2022 13:21:24 -0400 I suggest to unset the local_date_header configuration option. From the manual: 3.171. local_date_header Type: boolean Default: yes If set, the date in the Date header of emails that you send will be in your local timezone. If unset a UTC date will be used instead to avoid leaking information about your current location. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1024993: sbuild: SUDO_FORCE_REMOVE=yes has no effect anymore
Hi Santiago,
Quoting Santiago Vila (2022-11-28 14:41:50)
> During a rebuild of all packages in bookworm I noticed that setting
> SUDO_FORCE_REMOVE=yes in the environment does not seem to have any
> effect anymore.
>
> This happens, for example, when building "neutron":
>
> [...]
> Removing sudo (1.9.11p3-2) ...
> You have asked that the sudo package be removed,
> but no root password has been set.
> Without sudo, you may not be able to gain administrative privileges.
>
> If you would prefer to access the root account with su(1)
> or by logging in directly,
> you must set a root password with "sudo passwd".
>
> If you have arranged other means to access the root account,
> and you are sure this is what you want,
> you may bypass this check by setting an environment variable
> (export SUDO_FORCE_REMOVE=yes).
>
>
> I have this in my .sbuildrc:
>
> $ENV{'SUDO_FORCE_REMOVE'} = 'yes';
>
> If I remember well, this used to work in the past.
>
> Is this a regression?
> Is there a way to fix this without using sbuild from bookworm? (not
> tested yet)
I'm not able to reproduce your problem when building src:neutron. At which
point is the build attempting to remove the sudo package?
The issue sounds like an environment variable you set is not passed on to one
of the processes started by sbuild. Did you make sure to have SUDO_FORCE_REMOVE
added to your environment filter so that it gets passed on like so:
use Dpkg::Build::Info;
$environment_filter = [Dpkg::Build::Info::get_build_env_allowed(),
'SUDO_FORCE_REMOVE']
Thanks!
cheers, josch
Bug#964761: Creating btrfs subvolumes with setup-storage fails in certain conditions
Hello,
the bug can be solved with the attached patch.
Regards
Christoph
--- fai-5.10.3.orig/lib/setup-storage/Commands.pm
+++ fai-5.10.3/lib/setup-storage/Commands.pm
@@ -349,7 +349,7 @@ sub build_btrfs_commands {
next unless ($config eq "BTRFS");
#create BTRFS RAIDs
-foreach my $id (keys %{ $FAI::configs{$config}{volumes} }) {
+foreach my $id (::numsort(keys %{ $FAI::configs{$config}{volumes} })) {
#reference to current btrfs volume
my $vol = (\%FAI::configs)->{$config}->{volumes}->{$id};
signature.asc
Description: This is a digitally signed message part
Bug#1024619: sbuild: useradd/groupadd change breaks autopkgtest LXD mode
Hi guys, Quoting Antoine Beaupré (2022-11-23 16:28:30) > I can confirm sbuild-qemu is also broken in the same way right now in > bookworm/sid. > > I tested the patch provided, and confirm that it fixes the issue on my side. thank you so much for finding this issue and fixing it so quickly! I uploaded a new version of sbuild with this patch and hope this fixes the issue. I'm sorry for this having taken so long. Currently, everybody seems to be down with some sickness around here (including me) and that's why things took much longer than they should've. In general, please feel free to NMU sbuild if I don't get to do an upload in time. I very much welcome NMUs. :) Thank you for your help! cheers, josch
Bug#1025389:
@Felix There is i915g gallium driver in mesa, that replaced old classic unmantained and removed upstream i915, but i915g is currently not enabled in Debian mesa package.
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Thu, 18 Nov 2021 13:32:58 +0100 Thomas Goirand wrote: > On 11/18/21 7:15 AM, Tomas Pospisek wrote: > > On Thu, 18 Nov 2021, Thomas Goirand wrote: > > > >> On 11/17/21 11:01 AM, Tomas Pospisek wrote: (...) > >> Hopefully, we can have the automation to sign DKMS modules in a non-leaf > >> package. I would strongly suggest we get a package with a very explicit > >> name in it, like "dkms-automatic-mok-signing" so it would do the work. I > >> would absolutely *not* go the path of disabling secure boot when a DKMS > >> module gets installed... > > > > Since I have not looked further I am *guessing* that Ubuntu does the > > automatic creation of the MOK key in the shim-signed package. So I think > > it should be possible to lift Ubuntu's work out of there and also put it > > into the shim-signed package, into postinst or so. > > > > *t > > As I understand, doing updates of shim-signed requires a signature from > Microsoft, so probably it's not the best place to do some change. https://salsa.debian.org/efi-team/shim-signed/-/tree/master/ The efi binaries are signed but not the package itself. Modifying the package postinst and its update-secureboot-policy script are fine. > > As for module automatic signatures, maybe this could go into the dkms > package itself, with some kind of configuration? Again, just a > suggestion... :) > https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/openssl.cnf https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/update-secureboot-policy This ubuntu update-secureboot-policy has a --new-key flag to generate the MOK in /var/lib/shim-signed/mok/. https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/debian/shim-signed.postinst calls update-secureboot-policy --new-key on configure. It also sign the dkms modules. Cheers, Alban
Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles
Hi Ross, > Should we consider adding "Conflicts: firewalld" to cloud-init before > the freeze? That's not optimal of course, but it'd prevent a user from > ending up in this situation for now. Is there a way to bypass "Conflicts" and install such packages anyway, in case the user finds a way to customize the configuration in a way that fits their needs? For example, on one of my systems I kept cloud-init installed for now, but I disabled and masked cloud-init.service. Cheers! Guillaume
Bug#1017524: [DRE-maint] Bug#1017524: status?
On 23/11/22 04:48 PM, Cédric Boutillier wrote: > Hi, > > I recently looked at failures in jekyll. > > Jekyll is broken in several ways in unstable due to version constraints > on the dependencies. One can easily relax the > version dependency on mercenary in the gemdeps (no changes needed). > > One would need a newer version of jekyll to fix most of them. But the > blocking point seems that even the latest jekyll release requires > ruby-liquid < 5, whereas we have 5.4. https://github.com/jekyll/jekyll/pull/9030 I could see ~9 month old open pull request to update to liquid 5. --abhijith
Bug#927255: powerpc-utils is uninstallable
Hi Lance! On 12/7/22 22:18, Lance Albertson wrote: Any idea when you'll be able to get this pushed out? Will try to get it done today. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1024686: Re : Bug#1024686: gkrellm: Crashes since reboot
Le 08/12/2022 01:35:18, Bernhard Übelacker a écrit : > Hello Nicolas, > the given backtrace points to below source locations. > Does starting gkrellm from a terminal maybe give some more output? > Maybe you could also temporarily disable or move this > gkrellm plugin to some safe directory. I disabled the plugin and gkrellm runs. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Bug#1025735: linux-image-6.0.0-5-amd64: Logitech camera only uses USB 1.1 (Full speed), not enough bandwidth
Package: src:linux
Version: 6.0.10-2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
My Logitech Inc. QuickCam Communicate STX USB Webcam 046d:08d7 can't
use USB 2.0, although the manufacturer says it supports it. It is not
a hardware problem, I have the same camera 2 times and I tried
different port and computers. It even happens on different machines.
The port definitely supports USB 2.0, I have verified that with
another USB device.
That causes that the bandwidth is not enough for the higher
resolutions. This results in a faulty image in certain applications
like Firefox or Microsoft Edge.
Message in dmesg
[ 193.679885] gspca_main: gspca_zc3xx-2.14.0 probing 046d:08d7
[ 194.761490] input: gspca_zc3xx as
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.5/input/input17
[ 194.761984] usbcore: registered new interface driver gspca_zc3xx
[ 195.504579] usbcore: registered new interface driver snd-usb-audio
[ 668.959675] gspca_zc3xx 1-1.5:1.0: alt 6 - bandwidth not wide enough, trying
again
##After I connected the camera
[ 3752.435797] usb 1-1.5: new full-speed USB device number 7 using ehci-pci
* What exactly did you do (or not do) that was effective (or
ineffective)?
Ineffective: Use another USB port, use another camera (same model) on the
same machine
* What was the outcome of this action?
Same situation, camera only uses USB 1.1. Picture disturbed, camera not
usable with high resolution.
* What outcome did you expect instead?
The camera should use USB 2.0 to provide enough bandwidth.
*** End of the template - remove these template lines ***
-- Package-specific info:
** Version:
Linux version 6.0.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC
Debian 6.0.10-1 (2022-11-26)
** Command line:
BOOT_IMAGE=/vmlinuz-6.0.0-5-amd64
root=UUID=7f90848d-f699-427b-a2ab-985f37001ee1 ro
** Tainted: OE (12288)
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[ 184.833843] systemd[1]: File System Check on Root Device was skipped because
of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root).
[ 184.837297] systemd[1]: Starting Journal Service...
[ 184.907298] fuse: init (API version 7.36)
[ 184.988373] systemd[1]: Starting Load Kernel Modules...
[ 184.990394] systemd[1]: Starting Remount Root and Kernel File Systems...
[ 184.990751] systemd[1]: Repartition Root Disk was skipped because no trigger
condition checks were met.
[ 184.992013] systemd[1]: Starting Coldplug All udev Devices...
[ 184.995366] systemd[1]: Started Journal Service.
[ 185.106308] EXT4-fs (dm-0): re-mounted. Quota mode: none.
[ 185.359611] systemd-journald[488]: Received client request to flush runtime
journal.
[ 185.526550] lp: driver loaded but no devices found
[ 185.561658] ppdev: user-space parallel port driver
[ 191.939072] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 191.939864] sd 1:0:0:0: Attached scsi generic sg1 type 0
[ 191.940148] sr 2:0:0:0: Attached scsi generic sg2 type 5
[ 191.940410] sd 3:0:0:0: Attached scsi generic sg3 type 0
[ 191.950839] at24 0-0050: supply vcc not found, using dummy regulator
[ 191.951561] at24 0-0050: 256 byte spd EEPROM, read-only
[ 191.951694] at24 0-0051: supply vcc not found, using dummy regulator
[ 191.952404] at24 0-0051: 256 byte spd EEPROM, read-only
[ 191.952558] at24 0-0052: supply vcc not found, using dummy regulator
[ 191.953839] at24 0-0052: 256 byte spd EEPROM, read-only
[ 191.954006] at24 0-0053: supply vcc not found, using dummy regulator
[ 191.955293] at24 0-0053: 256 byte spd EEPROM, read-only
[ 192.052397] iTCO_vendor_support: vendor-support=0
[ 192.100384] input: PC Speaker as /devices/platform/pcspkr/input/input10
[ 192.337184] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms
ovfl timer
[ 192.337300] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules
[ 192.337622] RAPL PMU: hw unit of domain package 2^-16 Joules
[ 192.338363] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules
[ 192.363978] iTCO_wdt iTCO_wdt.1.auto: Found a Cougar Point TCO device
(Version=2, TCOBASE=0x0460)
[ 192.364289] iTCO_wdt iTCO_wdt.1.auto: initialized. heartbeat=30 sec
(nowayout=0)
[ 192.541131] input: HP WMI hotkeys as /devices/virtual/input/input11
[ 193.314923] mc: Linux media interface: v0.10
[ 193.316580] snd_hda_intel :00:1b.0: bound :00:02.0 (ops
i915_audio_component_bind_ops [i915])
[ 193.483036] videodev: Linux video capture interface: v2.00
[ 193.529810] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC662 rev1:
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[ 193.529964] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=1
(0x15/0x0/0x0/0x0/0x0)
[ 193.530392] snd_hda_codec_realtek hdaudioC0D0:
Bug#1025734: Segvault on startup
Package: neochat Version: 22.09-1 Severity: normal Hi, when I start neochat, it crashes immediately with a coredump: ``` PID: 1482308 (neochat) UID: 1000 (joerg) GID: 1000 (joerg) Signal: 11 (SEGV) Timestamp: Thu 2022-12-08 00:18:11 CET (8h ago) Command Line: neochat Executable: /usr/bin/neochat Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/awesome.service Unit: user@1000.service User Unit: awesome.service Slice: user-1000.slice Owner UID: 1000 (joerg) Boot ID: b80f61c3f2ba4263b281a0c292f5fd16 Machine ID: 523cb54753234ed08c13ec497d0d3b64 Hostname: zenbook Storage: /var/lib/systemd/coredump/core.neochat.1000.b80f61c3f2ba4263b281a0c292f5fd16.1482308.167045509100.zst (present) Size on Disk: 2.5M Message: Process 1482308 (neochat) of user 1000 dumped core. Module libsystemd.so.0 from deb systemd-252.2-1.amd64 Module libudev.so.1 from deb systemd-252.2-1.amd64 Stack trace of thread 1482308: #0 0x7f39bc3a07a7 _ZN7QWidgetD2Ev (libQt5Widgets.so.5 + 0x1a07a7) #1 0x7f39bc706fad n/a (libQt5Widgets.so.5 + 0x506fad) #2 0x7f39bc7065c2 n/a (libQt5Widgets.so.5 + 0x5065c2) #3 0x7f39bc6e5d0b _ZN15QSystemTrayIconD1Ev (libQt5Widgets.so.5 + 0x4e5d0b) #4 0x7f39bd5d59b3 n/a (libKF5Notifications.so.5 + 0x329b3) #5 0x7f39bd5ce2a5 _ZN19KStatusNotifierItemD2Ev (libKF5Notifications.so.5 + 0x2b2a5) #6 0x55971fb0a7c7 n/a (neochat + 0x9d7c7) #7 0x7f39bb6dafee _ZN14QObjectPrivate14deleteChildrenEv (libQt5Core.so.5 + 0x2dafee) #8 0x7f39bb6e6db4 _ZN7QObjectD2Ev (libQt5Core.so.5 + 0x2e6db4) #9 0x7f39bb25d435 __run_exit_handlers (libc.so.6 + 0x3e435) #10 0x7f39bb25d5aa __GI_exit (libc.so.6 + 0x3e5aa) #11 0x7f39bb246191 __libc_start_call_main (libc.so.6 + 0x27191) #12 0x7f39bb246245 __libc_start_main_impl (libc.so.6 + 0x27245) #13 0x55971faf0d71 n/a (neochat + 0x83d71) Stack trace of thread 1482310: #0 0x7f39bb31b0af __GI___poll (libc.so.6 + 0xfc0af) #1 0x7f39bac7b9ae n/a (libglib-2.0.so.0 + 0x549ae) #2 0x7f39bac7bacc g_main_context_iteration (libglib-2.0.so.0 + 0x54acc) #3 0x7f39bb7094b6 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x3094b6) #4 0x7f39bb6b019b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2b019b) #5 0x7f39bb4cab17 _ZN7QThread4execEv (libQt5Core.so.5 + 0xcab17) #6 0x7f39bc901487 n/a (libQt5DBus.so.5 + 0x17487) #7 0x7f39bb4cbcd1 n/a (libQt5Core.so.5 + 0xcbcd1) #8 0x7f39bb2a7fd4 start_thread (libc.so.6 + 0x88fd4) #9 0x7f39bb32866c __clone3 (libc.so.6 + 0x10966c) ELF object binary architecture: AMD x86-64 [New LWP 1482308] [New LWP 1482310] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `neochat'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f39bc3a07a7 in QWidget::~QWidget (this=this@entry=0x55971fe80d30, __in_chrg=) at kernel/qwidget.cpp:1478 Download failed: Invalid argument. Continuing without source file ./src/widgets/kernel/qwidget.cpp. 1478kernel/qwidget.cpp: Inappropriate ioctl for device. [Current thread is 1 (Thread 0x7f39b656ca00 (LWP 1482308))] #0 0x7f39bc3a07a7 in QWidget::~QWidget (this=this@entry=0x55971fe80d30, __in_chrg=) at kernel/qwidget.cpp:1478 d = 0x55971fe80d70 blocked = d = blocked = manager = it = end = i = apriv = w = window = e = repaintManager = e = #1 0x7f39bc706fad in QSystemTrayIconSys::~QSystemTrayIconSys (this=0x55971fe80d30, __in_chrg=) at util/qsystemtrayicon_x11.cpp:76 No locals. #2 QSystemTrayIconSys::~QSystemTrayIconSys (this=0x55971fe80d30, __in_chrg=) at util/qsystemtrayicon_x11.cpp:76 No locals. #3 0x7f39bc7065c2 in QSystemTrayIconPrivate::destroyIcon (this=0x55971fe7f650) at util/qsystemtrayicon_x11.cpp:278 No locals. #4 QSystemTrayIconPrivate::destroyIcon (this=0x55971fe7f650) at util/qsystemtrayicon_x11.cpp:272 No locals. #5 QSystemTrayIconPrivate::remove_sys (this=0x55971fe7f650) at util/qsystemtrayicon_x11.cpp:269 No locals. #6 0x7f39bc6e5d0b in QSystemTrayIcon::~QSystemTrayIcon (this=this@entry=0x7f39a80128a0, __in_chrg=) at util/qsystemtrayicon.cpp:182
Bug#1025733: libxmlada: unsatisfiable buil-dependency on unicode-data
Source: libxmlada Version: 22.0.0-3 Severity: serious Hi, libxmlada build-depends (in Build-Depends-Arch) on unicode-data (>= 14~), unicode-data (<< 15~) but the version of unicode-data in sid is 15.0.0-1. -Ralf.
