Bug#998909: closed by Debian FTP Masters (reply to Shengjing Zhu ) (Bug#998909: fixed in containerd 1.4.12~ds1-1~deb11u1)
Awesome! Thank you, Shengjing ☺️ OpenPGP_signature Description: OpenPGP digital signature
Bug#998909: containerd: Backport workaround for Raspberry Pi 0/1
Source: containerd Version: 1.4.5~ds1-2 Severity: normal Tags: patch Dear Maintainer, The following bug is present in Debian 11 (Bullseye) (and should be patched in Debian), although only users of Raspberry Pi OS (fka Raspbian) are affected: All releases of Raspberry Pi OS provide a buggy Docker runtime [1] which always pulls Docker images for ARMv7 CPUs instead of ARMv6 CPUs even on Raspberry Pi's with ARM1176JZF-S cores such as Raspberry Pi Zero and Raspberry Pi 1 Model B(+). For example, dash crashes with a segmentation fault when running Debian's Docker image [2] on older Raspberry Pis like this: docker run -ti --rm debian:bullseye /bin/sh Details and workarounds are listed in Docker Pi-hole's issue 245 [3] and containerd's upstream issue 37647 [1]. The bug is in containerd [1] and has been fixed upstream in v1.5 [4]. Unfortunately, Debian 11 (Bullseye) and thus Raspberry Pi OS ship the buggy containerd 1.4.5~ds1-2. The patch itself is very simple and will only affect Raspberry Pi ARMv6 devices [4]. Maybe you could backport this patch to Debian 11 (Bullseye) so that Raspberry Pi OS will pick up the fixed containerd and users will be able to use Docker on older RPi's as intended? Ref.: [1] https://github.com/moby/moby/issues/37647 [2] https://github.com/docker-library/official-images [3] https://github.com/pi-hole/docker-pi-hole/issues/245 [4] https://github.com/containerd/containerd/commit/2055e12953bb538228d8d9fe627fa545d7cf82be
Bug#989221: lvm2: Missing kernel modules for Cache LVs and RAID1 LVs with DM integrity in initrd
Package: lvm2
Version: 2.03.11-2.1
Severity: normal
Tags: patch
To activate Cache LVs or RAID1 LVs with DM integrity on system
boot it is required to add additional kernel modules to the
initial ramdisk. If those modules are not present during boot,
LVs will not be activated and LVM's initrd scripts indicate
this in syslog with messages such as:
lvm[***]: pvscan[***] VG *** skip autoactivation.
Please find the attached patch which adds those missing modules
to the initrd. Instead of adding a dozen of modules precautionary
maybe it should be documented somewhere that modules have to
be added to /etc/initramfs-tools/modules in case of strange
autoactivation issues? Or maybe I am missing something and it is
documented already?
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
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 lvm2 depends on:
ii dmeventd 2:1.02.175-2.1
ii dmsetup 2:1.02.175-2.1
ii init-system-helpers 1.60
ii libaio1 0.3.112-9
ii libblkid1 2.36.1-7
ii libc6 2.31-12
ii libdevmapper-event1.02.1 2:1.02.175-2.1
ii libedit2 3.1-20191231-2+b1
ii libselinux1 3.1-3
ii libsystemd0 247.3-5
ii libudev1 247.3-5
ii lsb-base 11.1.0
Versions of packages lvm2 recommends:
ii thin-provisioning-tools 0.9.0-1
lvm2 suggests no packages.
-- no debconf information
>From 1f1a595dcee4a421ac2aba38bd6de9fdb33ec151 Mon Sep 17 00:00:00 2001
From: Jakob Meng
Date: Sat, 29 May 2021 09:05:01 +0200
Subject: [PATCH] Added modules for Cache and DM integrity LVs to initrd
To activate Cache LVs and RAID1 LVs with DM integrity on system boot it
is required to add additional kernel modules to the initial ramdisk. If
those modules are not present during boot, LVs will not be activated and
LVM's initrd scripts indicate this in syslog with messages such as:
lvm[***]: pvscan[***] VG *** skip autoactivation.
---
debian/initramfs-tools/lvm2/hooks/lvm2 | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/debian/initramfs-tools/lvm2/hooks/lvm2
b/debian/initramfs-tools/lvm2/hooks/lvm2
index 6c186dc5a..4eef98faf 100755
--- a/debian/initramfs-tools/lvm2/hooks/lvm2
+++ b/debian/initramfs-tools/lvm2/hooks/lvm2
@@ -33,6 +33,21 @@ copy_exec /sbin/dmsetup
copy_exec /sbin/lvm
ln -s lvm ${DESTDIR}/sbin/vgchange
-for x in dm_mod dm_snapshot dm_mirror dm_raid raid0 raid1 raid10 raid456; do
+for x in \
+ dm_bio_prison \
+ dm_bufio \
+ dm_cache \
+ dm_cache_smq \
+ dm_integrity \
+ dm_persistent_data \
+ dm_mirror \
+ dm_mod \
+ dm_raid \
+ dm_snapshot \
+ raid0 \
+ raid1 \
+ raid10 \
+ raid456 \
+ ; do
manual_add_modules ${x}
done
--
2.20.1
Bug#959387: [Re] paraview-dev: missing cmake vtk modules in the dev package, cannot use
Hello Anton, that is great news! Keeping VTK and ParaView in sync' is not going to be easy: Sync'ing VTK sources and ParaView's VTK sources and allowing both to be co-installable, increases the maintenance burden for both package maintainers. Especially for Alastair McKinstry, because he would have to copy and adapt all patches from (Debian's) VTK package sources to his ParaView VTK sources. Latest ParaView release is 5.8.1 [1] and that is using a pre-VTK9 development version of VTK [2][3] ?!? The master branch of next ParaView release [4] has VTK 9 [5]. ParaView's release tarballs are published without the VTK subfolder [6], but I am not sure whether that is due to a "bug" [7] of the GitHub release process or if that means it is valid to "mix" different ParaView and VTK releases. ParaView CMakeLists.txt uses VTK's CMake files [8] before considering PARAVIEW_USE_EXTERNAL_VTK [9], hence ParaView requires the VTK subdirectory to be present anyway. For Debian users, it would be beneficial to have VTK and ParaView packages in sync and possibly installed at the same time, because that enables them e.g. 1. run (i)python3 or pvpython and enter 'import vtk' without crashs 2. use find_package(VTK) and find_package(ParaView) in a single CMakeLists.txt without tedious if-else constructs [1] https://gitlab.kitware.com/paraview/paraview/-/tree/v5.8.1 [2] https://gitlab.kitware.com/paraview/paraview/-/commit/ce73a508883c599927967be854ecfbf1562f032f [3] https://gitlab.kitware.com/vtk/vtk/-/blob/da522f73bc0639f8c995b8c89e21d604656f99e2/CMake/vtkVersion.cmake [4] https://gitlab.kitware.com/paraview/paraview [5] https://gitlab.kitware.com/vtk/vtk/-/blob/ae3f586abc4032895ce05e664d4a6ad84f990ef2/CMake/vtkVersion.cmake [6] https://github.com/Kitware/ParaView/releases [7] https://stackoverflow.com/a/34721233/6490710 [8] https://github.com/Kitware/ParaView/blob/v5.8.1/CMakeLists.txt#L98 [9] https://github.com/Kitware/ParaView/blob/v5.8.1/CMakeLists.txt#L218 Best regards Jakob signature.asc Description: OpenPGP digital signature
Bug#959387: [Re] paraview-dev: missing cmake vtk modules in the dev package, cannot use
PPPS: ParaView installs its Python modules as well as all the VTK Python modules as part of its CMake install process. If python3-vtk8 [1] ever enters Debian this might cause file collisions, as both python3-paraview and python3-vtk8 install files to the same locations and hence cannot be co-installed. So either we skip installing VTK Python modules during ParaView install or we install those ParaView's VTK Python modules to a different location by setting e.g. VTK_PYTHON_SITE_PACKAGES_SUFFIX. When skipping VTK Python module install, then we have to make sure that all VTK-related files in ParaView and VTK packages do match exactly and have the same patches applied. Else Python, ParaView or its Python modules might crash or even worse cause silent data and memory corruption bugs. Just calling 'rm -fr debian/tmp/usr/lib/python3*/dist-packages/vtk*' in ParaView's debian/rules is not a proper workaround. ParaView 5.7 from Debian Sid uses a development version of VTK8 (not far from VTK9 release?) [4], while Debian's dedicated VTK8 package [1] is at 8.2, so both VTK versions have many differences. ParaView has CMake flags to build with an external VTK install [6], but this is not supported at least in ParaView 5.7.0 [7]. BTW, these incompatibilities affect older Debian releases as well. For example, install both packages 'paraview-python' [2] and 'python3-vtk7' [3] on Debian 10 (Buster), run pvpython and enter 'import vtk'. ParaView Python will crash. So always remember to enter 'import paraview.vtk' on Debian and Ubuntu [5]. To avoid these bugs, my reworked ParaView package does not allow parallel installs of python3-vtk7 or python3-vtk8 [8]. Both paraview-dev and python3-paraview install a lot (all?) of VTK's headers, libraries and Python modules anyway. Ref.: [1] https://salsa.debian.org/science-team/vtk8/ [2] https://packages.debian.org/buster/paraview-python [3] https://packages.debian.org/buster/python3-vtk7 [4] https://salsa.debian.org/science-team/paraview/-/blob/master/VTK/CMake/vtkVersion.cmake [5] https://blog.kitware.com/import-vtk-or-import-paraview-vtk/ [6] https://github.com/Kitware/ParaView/blob/v5.8.1/CMakeLists.txt#L218 [7] https://github.com/Kitware/ParaView/blob/v5.7.0/CMakeLists.txt#L290 [8] https://git.inf.h-brs.de/jmeng2m/debian-package-paraview/-/blob/debian/5.7.0+ds.1-3/debian/control#L172 signature.asc Description: OpenPGP digital signature
Bug#957660: [Re] paraview: ftbfs with GCC-10
A fix for compiling paraview 5.7.0-4 with gcc10 can be found in bug #959387 [1], esp. [2]. Ref.: [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959387 [2] https://git.inf.h-brs.de/jmeng2m/debian-package-paraview/-/commit/35d8cae30d4e9d1c6da980f2b359b428a5beea89 signature.asc Description: OpenPGP digital signature
Bug#959387: [Re] paraview-dev: missing cmake vtk modules in the dev package, cannot use
PPS: Binary packages can be downloaded here: http://home.infcs.de/~jmeng2m/debian-package-paraview/ They were build using my university's GitLab CI instance and the official debian/buildd:sid docker image. CI file: https://git.inf.h-brs.de/jmeng2m/debian-package-paraview/-/blob/gitlab-ci/.gitlab-ci.yml Build log: https://git.inf.h-brs.de/jmeng2m/debian-package-paraview/-/jobs/421 signature.asc Description: OpenPGP digital signature
Bug#959387: [Re] paraview-dev: missing cmake vtk modules in the dev package, cannot use
PS: I've uploaded a patched package based on ParaView 5.7.0-4 from Debian Sid to https://git.inf.h-brs.de/jmeng2m/debian-package-paraview signature.asc Description: OpenPGP digital signature
Bug#959387: [Re] paraview-dev: missing cmake vtk modules in the dev package, cannot use
Found another problem with the ParaView source package in Debian Sid. The Salsa GitLab Repo of ParaView has Git LFS Pointers, e.g. [1]. The source tarball paraview_5.7.0.orig.tar.xz [2] that has been uploaded to Debian Sid does not have the binary files but the raw Git LFS pointers instead! For example, file VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/tornado.vec in the source tarball is: version https://git-lfs.github.com/spec/v1 oid sha256:dca8105bf888e67a9fe476a563d69ac708925aec519814fb520c6057e5ca0a1f size 1327116 [1] https://salsa.debian.org/science-team/paraview/-/tree/master/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data [2] http://deb.debian.org/debian/pool/main/p/paraview/paraview_5.7.0.orig.tar.xz signature.asc Description: OpenPGP digital signature
Bug#867705: ccache: symlinks for versioned clang
Possible fix attached.
--
Jakob
--- /usr/sbin/update-ccache-symlinks.orig 2018-03-25 20:41:45.0 +
+++ /usr/sbin/update-ccache-symlinks 2018-08-06 12:16:33.059438096 +
@@ -12,6 +12,7 @@
my %old_symlinks; # Current compiler names in /usr/lib/ccache
my %new_symlinks; # Compiler names that should be in /usr/lib/ccache
my @standard_names = qw(cc c++);
+my @clang_names = qw(clang clang-[0-9\.]* clang++ clang++-[0-9\.]* llvm-clang);
my $verbose = 0;
sub consider {
@@ -51,9 +52,12 @@
}
# Find existing clang variants.
-consider "clang";
-consider "clang++";
-consider "llvm-clang";
+foreach my $name (@clang_names) {
+foreach () {
+s|.*/||;
+consider $_;
+}
+}
# Find existing symlinks.
foreach (<$ccache_dir/*>) {
signature.asc
Description: OpenPGP digital signature
Bug#826190: Patch for Jessie's nvidia-kernel-dkms
Just in case anyone wants to build nvidia-kernel-dkms from Jessie with
kernel 4.6, the patch attached might be useful. The original patch has
been taken from http://pastebin.com/hJ2GuLdB.
Kind regards
Jakob
diff -Naur /usr/src/nvidia-current-340.96.orig/conftest.h /usr/src/nvidia-current-340.96/conftest.h
--- /usr/src/nvidia-current-340.96.orig/conftest.h 2015-11-21 02:48:10.0 +0100
+++ /usr/src/nvidia-current-340.96/conftest.h 2016-06-22 22:35:16.325994356 +0200
@@ -664,6 +664,13 @@
#undef NV_NODE_END_PFN_PRESENT
#endif
+/* Implement conftest.sh function get_user_pages_remote */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0)
+ #define NV_GET_USER_PAGES_REMOTE_PRESENT
+#else
+ #undef NV_GET_USER_PAGES_REMOTE_PRESENT
+#endif
+
/* Check for linux/semaphore.h */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,26)
#define NV_LINUX_SEMAPHORE_H_PRESENT
diff -Naur /usr/src/nvidia-current-340.96.orig/conftest_nvidia.sh /usr/src/nvidia-current-340.96/conftest_nvidia.sh
--- /usr/src/nvidia-current-340.96.orig/conftest_nvidia.sh 2015-11-09 06:44:53.0 +0100
+++ /usr/src/nvidia-current-340.96/conftest_nvidia.sh 2016-06-22 22:25:10.407749529 +0200
@@ -773,6 +773,23 @@
compile_check_conftest "$CODE" "NV_ACQUIRE_CONSOLE_SEM_PRESENT" "" "functions"
;;
+get_user_pages_remote)
+#
+# Determine if the function get_user_pages_remote() is
+# present.
+#
+# get_user_pages_remote() was added by:
+# 2016 Feb 12: 1e9877902dc7e11d2be038371c6fbf2dfcd469d7
+#
+CODE="
+#include
+int conftest_get_user_pages_remote(void) {
+get_user_pages_remote();
+}"
+
+compile_check_conftest "$CODE" "NV_GET_USER_PAGES_REMOTE_PRESENT" "" "functions"
+;;
+
console_lock)
#
# Determine if the console_lock() function is present.
diff -Naur /usr/src/nvidia-current-340.96.orig/Kbuild /usr/src/nvidia-current-340.96/Kbuild
--- /usr/src/nvidia-current-340.96.orig/Kbuild 2015-12-15 05:19:18.0 +0100
+++ /usr/src/nvidia-current-340.96/Kbuild 2016-06-22 22:26:47.396740408 +0200
@@ -147,7 +147,8 @@
drm_pci_set_busid \
write_cr4 \
for_each_online_node \
- node_end_pfn
+ node_end_pfn \
+get_user_pages_remote
#
# CFLAGS dependent on the type of builds (e.g. single/muliple module, debug)
diff -Naur /usr/src/nvidia-current-340.96.orig/nv-mm.h /usr/src/nvidia-current-340.96/nv-mm.h
--- /usr/src/nvidia-current-340.96.orig/nv-mm.h 1970-01-01 01:00:00.0 +0100
+++ /usr/src/nvidia-current-340.96/nv-mm.h 2016-06-22 22:23:04.946490291 +0200
@@ -0,0 +1,55 @@
+/***
+Copyright (c) 2016 NVIDIA Corporation
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to
+deal in the Software without restriction, including without limitation the
+rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+sell copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+
+***/
+#ifndef __NV_MM_H__
+#define __NV_MM_H__
+
+/* get_user_pages_remote() was added by:
+ *2016 Feb 12: 1e9877902dc7e11d2be038371c6fbf2dfcd469d7
+ *
+ * The very next commit (cde70140fed8429acf7a14e2e2cbd3e329036653)
+ * deprecated the 8-argument version of get_user_pages for the
+ * non-remote case (calling get_user_pages with current and current->mm).
+ *
+ * The guidelines are: call NV_GET_USER_PAGES_REMOTE if you need the 8-argument
+ * version that uses something other than current and current->mm. Use
+ * NV_GET_USER_PAGES if you are refering to current and current->mm.
+ *
+* Note that get_user_pages_remote() requires the caller to hold a reference on
+* the task_struct (if non-NULL) and the mm_struct. This will always be true
+* when using current and current->mm. If the kernel passes the driver a vma
+* via driver callback, the kernel holds a reference on vma->vm_mm over that
+* callback.
+ */
+
+#if
