Bug#1030111: ITP: libcatmandu-mendeley-perl -- modules wrapping the Mendeley API within the Catmandu framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcatmandu-mendeley-perl
  Version : 0.01
  Upstream Author : Nicolas Steenlant 
* URL : https://metacpan.org/release/Catmandu-Mendeley
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules wrapping the Mendeley API within the Catmandu 
framework

Catmandu::Mendeley contains modules for interfacing with the Mendeley API.

Provides modules:
 Catmandu::Importer::MendeleyCatalog

See also:
 https://dev.mendeley.com/

Catmandu provides a suite of Perl modules to ease the import, storage,
retrieval, export and transformation of metadata records.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1

[Sebastian Andrzej Siewior]

On 2023-01-30 21:57:28 [+], Thorsten Glaser wrote:
> Sebastian Andrzej Siewior dixit:
> 
> >Okay. So I do nothing and just wait for the bpo package to appear which
> >will then solve the problem?
> 
> No, you must fix the problem in xz-utils in bookworm/sid as well.
> It also exists outside of backports.

Then I will update the versions as suggested. My understanding was the
problem persists because the bpo version was not yet updated. The
version in sid did not ship the man-pages.

> bye,
> //mirabilos

Sebastian

Bug#1030110: optuna: FTBFS due to scipy 1.10.0 upload

[Graham Inggs]

Source: optuna
Version: 3.0.5-1
Severity: serious
Tags: ftbfs

Hi Maintainer

optuna currently Build-Depends on:

python3-scipy (>= 1.7.0), python3-scipy (<< 1.9.0)

but this is unsatisfiable since the upload of scipy 1.10.0 to unstable.

Regards
Graham

Bug#1030109: zfp: misses versioned dependencies on numpy

[Graham Inggs]

Source: zfp
Version: 1.0.0-5
Severity: serious
Tags: patch

Hi Maintainer

python3-zfpy misses a dependency on python3-numpy-abi and a versioned
dependency on python3-numpy.

The patch below should ensure these are automatically added correctly.

Regards
Graham


--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@
  cython3,
  gfortran,
  dh-sequence-python3,
+ dh-sequence-numpy3,
  libpython3-all-dev,
  dh-sequence-pkgkde-symbolshelper,
  python3-numpy,

Bug#1013153: camitk: vtk[6,7] removal

[Emmanuel Promayon]

Dear Andreas,

I managed to patch the current CamiTK 5.0.2version  to build with VTK9 
(vtk9-compatibility.patch in attachment).


The build then stopped with the following error:
/build/camitk-5.0.2/imaging/components/dicom/DicomComponent.cpp:40:10: 
fatal error: vtkGDCMImageReader.h: No such file or directory


When this plugin is disabled in d/r (see below), the compilation ends 
with no error, (which is good news!) but all tests failed with the 
following error:
/build/camitk-5.0.2/camitk-build/bin/camitk-testcomponents: error while 
loading shared libraries: libjawt.so: cannot open shared object file: No 
such file or directory


This error seems to be linked with a Java installation problem (maybe 
temporary?)


Let me know what will be the best course of action from this.
Best regards,
Emmanuel

PS: this is the d/r diff to disable the dicom component,
--- a/debian/rules
+++ b/debian/rules
@@ -42,6 +42,7 @@ CMAKE_EXTRA_FLAGS = \
    -DCEP_IMAGING:BOOL=TRUE \
    -DCEP_MODELING:BOOL=TRUE \
    -DCEP_TUTORIALS:BOOL=TRUE \
+   -DCOMPONENT_DICOM:BOOL=FALSE \
    \
    -DAPIDOC_SDK:BOOL=TRUE
--- a/modeling/actions/mml/GenerateModel.cpp
+++ b/modeling/actions/mml/GenerateModel.cpp
@@ -127 +127 @@ void GenerateModel::saveSOFAFile(QString baseFilename) {
-ofstream scnFile(SOFAFileName.toUtf8());
+std::ofstream scnFile(SOFAFileName.toUtf8());
@@ -188 +188 @@ void GenerateModel::saveMMLFiles(QString baseFilename) {
-ofstream lmlofs(lmlFilename.toStdString().c_str());
+std::ofstream lmlofs(lmlFilename.toStdString().c_str());
@@ -235 +235 @@ void GenerateModel::saveMMLFiles(QString baseFilename) {
-ofstream mmlofs(mmlFilename.toStdString().c_str());
+std::ofstream mmlofs(mmlFilename.toStdString().c_str());
@@ -268 +268 @@ void GenerateModel::saveMMLFiles(QString baseFilename) {
-ofstream pmlofs(completePmlFilename.toStdString().c_str(), std::ios_base::trunc);
+std::ofstream pmlofs(completePmlFilename.toStdString().c_str(), std::ios_base::trunc);
--- a/modeling/components/mmlcomponent/MMLComponent.cpp
+++ b/modeling/components/mmlcomponent/MMLComponent.cpp
@@ -80 +80 @@ MMLComponent::MMLComponent(const QString& fileName) : Component(fileName, QFileI
-ofstream ofs(exportedMml.toStdString().c_str());
+std::ofstream ofs(exportedMml.toStdString().c_str());
--- a/sdk/actions/image/multipicking/PickedPixelMap.cpp
+++ b/sdk/actions/image/multipicking/PickedPixelMap.cpp
@@ -165 +165 @@ void PickedPixelMap::savePixelList(QString fileName) {
-ofstream myFile;
+std::ofstream myFile;
deleted file mode 100644
Binary files a/sdk/actions/image/volumerendering/resources/Thumbs.db and /dev/null differ
--- a/sdk/actions/mesh/meshprocessing/MergeMeshs.cpp
+++ b/sdk/actions/mesh/meshprocessing/MergeMeshs.cpp
@@ -338 +338 @@ void MergeMeshs::printKToFile() {
-ofstream mshFile(fileNeigh.toUtf8());
+std::ofstream mshFile(fileNeigh.toUtf8());
--- a/sdk/actions/mesh/meshprocessing/MeshClipping.cpp
+++ b/sdk/actions/mesh/meshprocessing/MeshClipping.cpp
@@ -93,0 +94 @@ QWidget* MeshClipping::getWidget() {
+#if VTK_MAJOR_VERSION < 9  
@@ -95 +96,3 @@ QWidget* MeshClipping::getWidget() {
-
+#else
+vtkRenderWindowInteractor* iren = default3DViewer->getRendererWidget()->renderWindow()->GetInteractor();
+#endif
--- a/sdk/applications/imp/main.cpp
+++ b/sdk/applications/imp/main.cpp
@@ -107 +107 @@ int main(int argc, char* argv[]) {
-
+
--- a/sdk/components/msh/MshExtension.cpp
+++ b/sdk/components/msh/MshExtension.cpp
@@ -72 +72 @@ bool MshExtension::save(Component* component) const {
-ofstream mshFile(meshComp->getFileName().toStdString().c_str());
+std::ofstream mshFile(meshComp->getFileName().toStdString().c_str());
--- a/sdk/components/obj/ObjExtension.cpp
+++ b/sdk/components/obj/ObjExtension.cpp
@@ -90 +90 @@ bool ObjExtension::save(camitk::Component* component) const {
-ofstream objFile(fileName.toUtf8());
+std::ofstream objFile(fileName.toUtf8());
--- a/sdk/components/off/OffExtension.cpp
+++ b/sdk/components/off/OffExtension.cpp
@@ -77 +77 @@ bool OffExtension::save(Component* component) const {
-ofstream offFile(offFilename.toUtf8());
+std::ofstream offFile(offFilename.toUtf8());
--- a/sdk/components/vrml/VRMLComponentExtension.cpp
+++ b/sdk/components/vrml/VRMLComponentExtension.cpp
@@ -80,0 +81 @@ bool VRMLComponentExtension::save(Component* component) const {
+#if VTK_MAJOR_VERSION < 9
@@ -81,0 +83,3 @@ bool VRMLComponentExtension::save(Component* component) const {
+#else
+exporter->SetInput(default3DViewer->getRendererWidget()->renderWindow());
+#endif
deleted file mode 100644
--- a/sdk/libraries/core/viewer/InteractiveViewer.cpp
+++ b/sdk/libraries/core/viewer/InteractiveViewer.cpp
@@ -151,0 +152 @@ void InteractiveViewer::init() {
+#if VTK_MAJOR_VERSION < 9
@@ -152,0 +154,3 @@ void InteractiveViewer::init() {
+#else
+

Bug#1009290: [debian-mysql] Bug#1009290: mariadb-server-10.6: Fails to start on live system

[Daniel Lewart]

Otto, et al,

How about temporarily inserting something like the implementation below of
Arnaud R's workaround somewhere (where?) in mariadb-server(-10.6).postinst?

Thank you!
Daniel Lewart
Urbana, Illinois
---
# Temporary workaround which should be removed after upstream fixes
# https://jira.mariadb.org/browse/MDEV-28751
fstype=$(findmnt -n -o FSTYPE -T /var/lib/mysql)
if [ "$fstype" = overlay ]; then
cat <<- EOF > "${mysql_cfgdir:-/etc/mysql}/mariadb.conf.d/90-live.cnf"
[mysqld]
innodb_flush_method = fsync
EOF
fi

Bug#1030108: libmimalloc2.0: Build type is not specified during configure phase of packages. It kills performance.

[Max Dmitrichenko]

Package: libmimalloc2.0
Version: 2.0.9+ds-1~dbp2
Severity: important
X-Debbugs-Cc: dmitr...@gmail.com

There is no -DCMAKE_BUILD_TYPE release in debian/rules 
override_dh_auto_configure target. The package is built with
CMAKE_BUILD_TYPE equal to None. This renders its performance unusable - 
actually far more worse that even libc's malloc.

I've discovered it when backported this package to bullseye and noticed that 
its performance is awful but local build of the same
version is pretty much good.

Please add this flag until bookworm is completly frozed!


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmimalloc2.0 depends on:
ii  libc6  2.31-13+deb11u5

libmimalloc2.0 recommends no packages.

libmimalloc2.0 suggests no packages.

-- no debconf information

Bug#1030094: linux-headers-amd64: DKMS fails to build - missing evdi-dkms

[Salvatore Bonaccorso]

Control: reassign -1 src:dkms

Hi,

On Mon, Jan 30, 2023 at 09:42:03PM -0500, DAB wrote:
> Package: linux-headers-amd64
> Version: 6.1.7-1
> Severity: normal
> Tags: newcomer
> X-Debbugs-Cc: macda...@gmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> apt upgrade attempted to install linux-headers v 6.1.4 through 6.1.7 failed to
> configure. the error came from DKMS build
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> examining the logs i saw it was something with evdi. i searched and found a
> package evdi-dkms which seemed appropriate. i installed that and it fixed the
> problem.
> 
>* What was the outcome of this action?
> the build failed and prevented boot without reverting to a previous version of
> the kernel
> 
>* What outcome did you expect instead?
> if the package is needed, it should be flagged as a dependency
> 
> *** End of the template - remove these template lines ***

Can you provide the install logs (have a look at
/var/log/apt/term.log* for the given installation/upgrade).

I suspect this is the same as https://bugs.debian.org/1029063
(but for now not merging, until not confirmed).

Regards,
Salvatore

Bug#1030107: zfp: FTBFS with LTO (link time optimization) enabled

[Graham Inggs]

Package: src:zfp
Version: 1.0.0-5
Severity: minor
Tags: ftbfs fixed-upstream
Forwarded: https://github.com/LLNL/zfp/issues/169
User: debian-...@lists.debian.org
Usertags: ftbfs-lto

This package currently fails to build (at least on the amd64
architecture) with link time optimizations enabled.  For a background
for LTO please see

https://wiki.debian.org/ToolChain/LTO

The goal is to enable this optimization by default in an upcoming
Debian release in dpkg-buildflags for 64-bit architectures.  The goal
is to get this package to build with link time optimizations, or to
explicitly disable link time optimizations for this package build.

To reproduce the build failure, enable the lto optimization in
testing/unstable by adding "optimize=+lto" to DEB_BUILD_MAINT_OPTIONS
in the debian/rules file, or if this macro is unset, just set it:

export DEB_BUILD_MAINT_OPTIONS = optimize=+lto

Please try to fix the build with lto enabled, fixing the packaging or
forwarding the issue upstream. If the issue cannot be fixed,
explicitly disallow building the package with lto by adding to your
rules file:

export DEB_BUILD_MAINT_OPTIONS = optimize=-lto

or adding that string to your existing setting of DEB_BUILD_MAINT_OPTIONS.

I've copied what I hope is the relevant part of the build log below.

Regards
Graham


[ 93%] Linking C executable ../bin/zfp
cd /<>/.pybuild/cpython3_3.10/build/utils &&
/usr/bin/cmake -E cmake_link_script CMakeFiles/zfpcmd.dir/link.txt
--verbose=1
/usr/bin/cc -g -O2 -ffile-prefix-map=/<>=. -flto=auto
-ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security
-fdebug-prefix-map=/<>=/usr/src/zfp-1.0.0-5 -Wall
-pedantic -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
-flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now
CMakeFiles/zfpcmd.dir/zfp.c.o -o ../bin/zfp
-Wl,-rpath,/<>/.pybuild/cpython3_3.10/build/lib/x86_64-linux-gnu:
../lib/x86_64-linux-gnu/libzfp.so.1.0.0
cd /<>/.pybuild/cpython3_3.10/build/fortran &&
/usr/bin/cmake -E cmake_symlink_library
../lib/x86_64-linux-gnu/libzFORp.so.1.0.0
../lib/x86_64-linux-gnu/libzFORp.so.1
../lib/x86_64-linux-gnu/libzFORp.so
/usr/bin/cmake -E touch fortran/CMakeFiles/zFORp.dir/zfp.f90.o.provides.build
make[3]: Leaving directory '/<>/.pybuild/cpython3_3.10/build'
[ 93%] Built target zFORp
/usr/bin/ld: /tmp/ccQBYXYU.ltrans0.ltrans.o: in function `main':
/usr/src/zfp-1.0.0-5/utils/zfp.c:76: undefined reference to `sqrt'
/usr/bin/ld: /tmp/ccQBYXYU.ltrans0.ltrans.o:/usr/src/zfp-1.0.0-5/utils/zfp.c:78:
undefined reference to `log10'
collect2: error: ld returned 1 exit status

Bug#1030105: ITP: libcatmandu-lido-perl -- modules for handling LIDO data within the Catmandu framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcatmandu-lido-perl
  Version : 0.10
  Upstream Author : Patrick Hochstenbach
* URL : https://metacpan.org/release/Catmandu-LIDO
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules for handling LIDO data within the Catmandu framework

Catmandu::LIDO contains modules to handle LIDO, an XML Schema for
contributing content to cultural heritage repositories.

This module is based on Catmandu, Lido::XML and XML::Compile

Provides modules:
 Catmandu::Exporter::LIDO
 Catmandu::Importer::LIDO

See also:
 https://metacpan.org/pod/Lido::XML

Catmandu provides a suite of Perl modules to ease the import, storage,
retrieval, export and transformation of metadata records.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030106: ITP: libcatmandu-markdown-perl -- modules for handling markdown data within the Catmandu framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcatmandu-markdown-perl
  Version : 0.011
  Upstream Author : Nicolas Franck 
* URL : https://metacpan.org/release/Catmandu-Markdown
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules for handling markdown data within the Catmandu 
framework

Catmandu::Markdown contains modules to work with markdown data.

Provides modules:
 Catmandu::Fix::markdown_to_html

See also:
 https://metacpan.org/pod/Text::Markdown::Discount

Catmandu provides a suite of Perl modules to ease the import, storage,
retrieval, export and transformation of metadata records.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030104: b4: Please add debian/watch file

[Nicolas Schier]

Package: b4
Version: 0.9.0-1
Severity: wishlist

Dear Héctor,

can you please add a debian/watch file to allow use of uscan and
friends?

I am attaching a patch that works for me and adds debian/watch and
upstream author's gpg key.

Thanks and kind regards,
Nicolas


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-5-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.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 b4 depends on:
ii  python33.11.1-1
ii  python3-dkim   1.0.5-2
ii  python3-dnspython  2.2.1-2
ii  python3-patatt 0.6.2-1
ii  python3-requests   2.28.1+dfsg-1

b4 recommends no packages.

b4 suggests no packages.

-- no debconf information
diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
new file mode 100644
index 000..d49e509
--- /dev/null
+++ b/debian/upstream/signing-key.asc
@@ -0,0 +1,289 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+
+mQINBE64XOsBEAC2CVgfiUwDHSqYPFtWxAEwHMoVDRQL5+Oz5NrvJsGRusoGMi4v
+wnToaNgD4ETPaaXHUAJdyy19BY+TCIZxDd+LR1zmMfzNxgePFjIZ6x4XIUMMyH6u
+jDnDkKJW/RBv262P0CRM9UXHUqyS6z3ijHowReo1FcYOp/isN9piPrKzTNLNoHM2
+re1V5kI8p8rwTuuQD/0xMPs4eqMBlIr7/1E2ePVryHYs5pPGkHIKbC9BN83iV2La
+YhDXqn3E9XhA1G5+nPYFNRrTSEcykoRwDhCuEA51wu2+jj0L09OO4MbzBkSZKASe
+LndRVyI6t0x8ovYXcb7A4u0jiH7gVjcNcJ5NfwFUqaOQOxSluahhI497SJULbKIP
+Pu3cv4/O/3Urn3fQsa689xbbUkSPhfGKG73FYnAuC5vxzBSkOB7iFRBhA37NfN5V
+OhCbWfXipdBDxSYunac6FjArBG1tfaF8BflkQmKLiBuiH5zwkgju5kOzrko5iISL
+0CM4zUTAUWbg1QnPvRjPzoT6tlsCOBY6jZK921Ft+uVjHg424/CVZ9A+kA33+Dfq
+otnzNK4CLNnLT4OEPM6ETxLnA6PyldUjSTUekZ75/Rp+aJHt5v7Q2mqOcB/5ZA6A
++vaBgZAMfCZbU+D1FeXD8NNEQcRDWdqe0S/ZgXdU+IyqyQ3Ie4vqGGYpkQARAQAB
+tDZLb25zdGFudGluIFJ5YWJpdHNldiAoRmVkb3JhKSA8aWNvbkBmZWRvcmFwcm9q
+ZWN0Lm9yZz6JAk8EEwECACIFAk7NMp8CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4B
+AheAACEJEOY+3KkyndB+FiEE3g5m4y8f3QkCZmuW5j7cqTKd0H4SwQ//QME+IJpw
+94FjqBZVzrsG3kpduwmSidKvq2L6mVceGp7iYbtDSoGXu52DHjNilQVV65I8natx
+DM6ZUWktZ0OSSk9WpIRKrAEAD1uBV9gNi2BI3CfeVG5POhoknvjaqmf5Y3CDcrdZ
+jdd3kaCz7GktK0sUjXwzPtwOE4HmQz0caDHIPEDyMazP7m8aUOnwYeUmsbyMHyf8
+tqbOO9A2U5ljJYIXsb5EBf3Kgvf10dnPflKpwNT090jhvbf2KEw97TXFCegKMrG+
+EhwBDHBTct6dHU0O6P8E8PuTqD848pjWxauWT6UwtHyYhhGVZiy0w2z7O0iy4iC2
+Nt57AzwfnwIX5bXbgiJvivTtgDKfy6a2svcqKMiUxTKY6a5CtcYAuJV2WrIfy7uS
+vggeu1LQCb2/kQ3Idaz8TEddPsS+AuxGvRP5ooMk6BWDQR1HvBP4WBJO/RCVB8Yv
+6nZFNOtsWhu2Wv2a5wHAQuic81aKM6ANNr/Aj2ia7bs1WOOxI/7MuGGNjvdJI4Ux
+PtzAfKZGAYyjx/EV2QkHjEJ9wTcpPvJpX5pp9g0iTFK09gVO9BltToG8cEBM5uD9
+li1PJLUzh8k6R8kZhSoFXCEH4HwiOj/aKh/Aaidc23A71noG33AEvFaKF5BjUrL9
+QhclwyxgL9aAiFjH4OWbwTFqjJz0w90KUti0LktvbnN0YW50aW4gUnlhYml0c2V2
+IDxoYmljQHBhcmFub2lkYmVhdmVycy5jYT6JAk4EEwEIADgWIQTeDmbjLx/dCQJm
+a5bmPtypMp3QfgUCWunVAAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDm
+PtypMp3QfsNSEACSFwiOYiUkr19AD9ybk8FNSDlwVzK8DpWpbaVhQrNzHerJYeIA
++m67k2GIWzo0ZibjCgz88aO1mkN67tvTNB37UMUCoYYuwwH4v+yqdxd97eXdpqaI
+pivBnOA+ZFxhUJihrrjY7O4azqJfBlHbPESIEKaZWfuBiLTS18zqbdzuImJCEEK1
+aanXk98UL+Dho5aA86BJN7JDIE8l1siOsGtrKrKbQOqHC3cwpheT0lO1InZv02AT
+Pk53iT7L2DgaSsZ4Fg05oDF8VFiJJFPln9pzXnE51iHH6tXtu/Os4K0ngQg98sYX
+8tQFGloMCX+L+KIG4/LwUNhBiU/Yvp0JzZ1uEVUY2P7qLgnnaxa9guPaG7lve84u
+pTsoXyTzrEQw+TgxJ+ATOUfU6ze7igjHD22/LW4N2Y2jF7+8+igqwHe4S0YFE6Kz
+vLhBVSCGPU1HPdDV2Cq1nOv6K/lvzU36KyKMeAOagGZFXEAUiwu7fur/u8GM+A0T
+96C5RT6W0+/oI61Orm9Y/vzAMPFWpqJ39PtsZz/D/SPJPKlPOlIq98wKL2dy0Y3c
+Vb9ARC/MnWCv2HvQlFQ5rcnfOFeyItv8l2ZazmMct0M6AVR/kI4Q0IbkJGyFkYgv
+S04wm4T6+xyWwGTVBpzg3eJqZ/yq7wzl0r1leUUaT/5Rild2rBTKx+LKl7QmS29u
+c3RhbnRpbiBSeWFiaXRzZXYgPGljb25AbXJpY29uLmNvbT6JAk4EEwEIADgWIQTe
+DmbjLx/dCQJma5bmPtypMp3QfgUCWunU2gIbAwULCQgHAgYVCgkICwIEFgIDAQIe
+AQIXgAAKCRDmPtypMp3QfsFwEACUcFAleVyqsMuCFC61n/mOeapk6TsNCop9sfP6
+4a2bhYM31DRkZHco8xrUB0dZ6OHozzIzIK/v0SzurS3n7gHKfuktbSTvAbJMPubM
+8iXJyaKL/+DGHt6qJynD3tHtSSR4c9aFrlnrn3Gefa3eQrgdNcieQcMCXOdePDHZ
+yWKQ4gfe6zxb63SbMv3Ms25hcmOf+HA1S8fM9bKrHEvebm23+2WOrQR/d5OPRXnW
+Dz9yz+++eWQfdG+FUfxUz7ulOG+C8jxzGjrAWgsvrAq48625GUrvuU2u5BJD2P1I
+WvEpQtFm3XnWvqP0hy5oT2i4hHvPxumY6XuZsBvEQygGajj94xZS5Gn0kqGV5XV/
+I1Z4kY00Ig0KHEG+LL1O+eu2ntfaqS2CZSlwbnfluqdgNNKs6lYsolvpqSCAXVVV
+27pkWo/To3E2RFvU7v33468KijBEHAjWlacmC6Ixs7PRmHiNGWK5Ewn0suzmPBy8
+lFtKBhT0JUyK12vkfrSFHs485TDk3uDQiyYh8lMkSuQIlBN9wfFMyPZTlfInNc7A
+umczplkl6I5qz5rfaxz1uWg9zI7deYAEoOJnaJG74stAXPx+iih2PbOpviXcr/AS
+L33Xg7A6ZF9Q3mmHPLym4q472VOaNj0AjLIUZC76oQdEXJz7Is3A/YSdgEIomBvr
+CGU3R7Q1S29uc3RhbnRpbiBSeWFiaXRzZXYgPGtvbnN0YW50aW5AbGludXhmb3Vu
+ZGF0aW9uLm9yZz6JAlIEEwECACUCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA
+BQJTjeH0AhkBACEJEOY+3KkyndB+FiEE3g5m4y8f3QkCZmuW5j7cqTKd0H50bA//

Bug#935175: ITP: python-pypdf4 -- PDF manipulation library

[Daniel Kahn Gillmor]

On Thu 2023-01-26 21:50:30 +, Martin wrote:
> On 2023-01-12 10:06, Daniel Kahn Gillmor wrote:
>> There was also PyPDF2, which was active up until the end of 2022, but
>> its maintainer is now transitioning it to the python module name
>> "pypdf", which itself is under active development.
>
> This seems to be the most active fork, by far.
> Is it already in Debian?
> Or are you going to package it?

pypdf is already in debian, and version 3.3.0-3 has migrated to testing
already.

  --dkg


signature.asc
Description: PGP signature

Bug#1030103: O: Motion

[MrDave]

Package: wnpp

Severity: wishlist

* Package name: Motion
  Version : 4.3.2
  Upstream Author : MrDave
* URL :https://motion-project.github.io/
* License : GPL
  Programming Lang: C
  Description : Security Camera capture and motion detection.


Canonical developer has provided a patch to resolve ftbfs for the old 
version staged for Bookworm but there is no maintainer to apply it.  
Upstream has multiple versions that build without any errors but not 
able to incorporate into Debian due to abandonment by Debian maintainer.


Related links:

https://tracker.debian.org/pkg/motion

https://bugs.debian.org/1004629

Bug#1029775: pyhst2: FTBFS with setuptools 66: Invalid version: '2020ca'

[Didier 'OdyX' Raboud]

Le lundi, 30 janvier 2023, 18.59:04 h CET Andreas Beckmann a écrit :
> On 28/01/2023 18.09, Didier 'OdyX' Raboud wrote:
> > So. I have a much shorter (and better) patch, that I'll upload to
> > DELAYED/5 in few minutes.
> 
> Thanks alot.

No problem.

Should I push it to unstable?

> There is now a new lintian error (not caused by your patch,
> but by some changed B-D). Since you were looking into
> the python building bits, perhaps you have an idea where this
> is originating from? Notice the difference lib vs. lib64

The code in setup.py does non-Debian stuff around guessing library paths.

A possible patch is attached, I've also pushed it on a branch:

https://salsa.debian.org/science-team/pyhst2/-/merge_requests/2

I have no idea if the resulting package works though.

Best,
OdyXDrop all CUDA-specific library path search

Fixes the superfluous /usr/lib or /usr/lib64 paths in RUNPATH

Author: Didier Raboud 
Origin: vendor

--- a/setup.py
+++ b/setup.py
@@ -261,15 +261,6 @@ def do_pyhst():
 
 cudaconfig = {'home':home, 'nvcc':nvcc,
   'include': pjoin(home, 'include')}
-lib =  pjoin(home, 'lib')
-if os.path.exists(lib+"64") andmath.log(sys.maxsize)/math.log(2) > 60: ##sys.maxint == 2**63-1:
-cudaconfig["lib"] = lib+"64"
-elif os.path.exists(lib+"32") and math.log(sys.maxsize)/math.log(2) < 60:
-cudaconfig["lib"] = lib+"32"
-elif os.path.exists(lib):
-cudaconfig["lib"] = lib
-else:
-print(("No cuda library found "))
 for key, val in cudaconfig.items():
 if not os.path.exists(val):
 raise EnvironmentError('The CUDA %s path could not be located in %s' % (key, val))
@@ -469,9 +460,7 @@ def do_pyhst():
 
 module = Extension('PyHST2_'+version+'/libgputomo',
 sources=sources,
-library_dirs=[CUDA['lib']],
 libraries=['cudart', "cublas", "cuda", "cufft", hdf5_lib],
-runtime_library_dirs=[CUDA['lib']],
 # this syntax is specific to this build system
 # we're only going to use certain compiler args with nvcc and not with gcc
 # the implementation of this trick is in customize_compiler() below
@@ -495,11 +484,8 @@ def do_pyhst():
 module = Extension(name='PyHST2_'+version+'.unsharp3D',
sources=sources ,
depends=[],
-   library_dirs=[CUDA['lib']],
libraries=['cudart','QtGui','QtCore','cudart','tiff'],

-   runtime_library_dirs=[CUDA['lib']],
-   
extra_compile_args={'gcc': ["-std=c99","-g","-fPIC", "-O3","-Wall"],
'nvcc': CUDA["arch"] + [ "--compiler-options",  "-fPIC", "-O3", "-g","-D_FORCE_INLINES" ]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace',"/usr/include/qt4"] )
@@ -518,9 +504,7 @@ def do_pyhst():
 global version
 module = Extension('PyHST2_'+version+'/libprojection',
sources=["PyHST/Cspace/c_hst_project_1over.cu"],
-   library_dirs=[CUDA['lib']],
libraries=['cudart', "cuda", "cufft"],
-   runtime_library_dirs=[CUDA['lib']],
extra_compile_args={'gcc': ["-fPIC", "-O3"],
'nvcc': CUDA["arch"] + ["--compiler-options", "-fPIC,-O3" ,"-D_FORCE_INLINES"]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace']+ hdf5_dirs)
@@ -542,9 +526,7 @@ def do_pyhst():
 
 module = Extension('PyHST2_'+version+'/libwavelets',
sources=sources,
-   library_dirs=[CUDA['lib']],
libraries=["cudart", "cuda", "cublas"],
-   runtime_library_dirs=[CUDA['lib']],
extra_compile_args={'gcc': ["-fPIC", "-O3"],
'nvcc': CUDA["arch"] + ["--compiler-options", "-fPIC,-O3" ,"-D_FORCE_INLINES"]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace'])


signature.asc
Description: This is a digitally signed message part.

Bug#1028273: Acknowledgement (MariaDB systemd: make multiple systemd files compatible with --build=all)

[Otto Kekäläinen]

Control: tags -1 patch

This Debian bug is still waiting for a contributor to dive deep into
it, but it is easier now as there is a draft of one way to potentially
solve it in 
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/29

Bug#996706: [debian-mysql] Bug#996706: mariadb-server-10.5: run directory is not created in multi-instance mode

[Otto Kekäläinen]

Control: tags -1 patch

This Debian bug is still waiting for a contributor to dive deep into
it, but it is easier now as there is a draft of one way to potentially
solve it in 
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/29

Bug#1030100: duplicate ITP of #1030099

[Mason James]

duplicate ITP of #1030099
please close

Bug#1030102: ITP: libcatmandu-ldap-perl -- modules for working with LDAP directories within the Catmandu framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcatmandu-ldap-perl
  Version : 0.0105
  Upstream Author : Nicolas Steenlant 
* URL : https://metacpan.org/release/Catmandu-LDAP
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules for working with LDAP directories within the 
Catmandu framework

Catmandu::LDAP contains modules for working with LDAP directories.

Provides modules:
 Catmandu::Importer::LDAP

See also:
 https://metacpan.org/dist/perl-ldap

Catmandu provides a suite of Perl modules to ease the import, storage,
retrieval, export and transformation of metadata records.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030101: ITP: libcatmandu-inspire-perl -- modules for working with Inspire data within the Catmandu framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcatmandu-inspire-perl
  Version : 0.300
  Upstream Author : Vitali Peil
* URL : https://metacpan.org/release/Catmandu-Inspire
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules for working with Inspire data within the Catmandu 
framework

Catmandu::Inspire contains modules for working with Inspire data.

Provides modules:
 Catmandu::Importer::Inspire

See also:
 http://inspirehep.net

Catmandu provides a suite of Perl modules to ease the import, storage,
retrieval, export and transformation of metadata records.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030100: ITP: libcatmandu-identifier-perl -- namespace for handling identifiers within the Catmandu framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcatmandu-identifier-perl
  Version : 0.15
  Upstream Author : Vitali Peil
* URL : https://metacpan.org/release/Catmandu-Identifier
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : namespace for handling identifiers within the Catmandu 
framework

Catmandu::Identifier contains a namespace for handling identifiers (for
normalization, validation, etc.), e.g. ISBN, ISSN, ORCID.

Catmandu provides a suite of Perl modules to ease the import, storage,
retrieval, export and transformation of metadata records.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029602: Bug report: kernel oops in vmw_fb_dirty_flush()

[Keyu Tao]

Hi Rusin,

Thank you for your timely response. I tested that this bug is not 
reproducible in v6.2-rc5 yesterday.


On 1/31/23 03:54, Zack Rusin wrote:

On Tue, 2023-01-31 at 00:36 +0800, Keyu Tao wrote:

!! External Email

Hi vmwgfx maintainers,

An out-of-bound access in vmwgfx specific framebuffer implementation can
be easily triggered by fbterm (a framebuffer terminal emulator) when it
is going to scroll screen.

With some debugging, it seems that vmw_fb_dirty_flush() cannot handle
the vinfo.yoffset correctly after calling `ioctl(fbdev_fd,
FBIOPAN_DISPLAY, );`, and then subsequent access to the mapped
memory area causes the oops.

As current mainline vmwgfx implementation (in Linux 6.2-rc) has removed
this framebuffer implementation, this bug can be triggered only in Linux
stable. I have tested it with vanilla 6.1.8 and 5.10.165 and they all oops.

This bug is reported in
<
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2
Fcgi-
bin%2Fbugreport.cgi%3Fbug%3D1029602=05%7C01%7Czackr%40vmware.com%7C63862e731c
3b4a97796808db02e03145%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C63810693415592
2769%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
CJXVCI6Mn0%3D%7C2000%7C%7C%7C=uVOtDBAyn%2BDx5w8r1twuKO4Xd0Lma6zCr2ie3lQ%2BRR
E%3D=0> first, and
the maintainer there suggests me to report this issue to upstream :)

Relevant information (for self-compiled Linux 6.1.8):

- /proc/version: Linux version 6.1.8 (tao@mira) (gcc (Debian 10.2.1-6)
10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #7 SMP
PREEMPT_DYNAMIC Mon Jan 30 21:09:02 CST 2023

- Linux distribution: Debian GNU/Linux 11 (bullseye)

- Architecture (uname -mi): x86_64 unknown

- Virtualization software: VMware Fusion 13 Player

- How to reproduce:
    1. Install (or compile) fbterm
    2. Run fbterm under a tty (by a user with read & write permission to
/dev/fb0, usually users in video group), and try to make it scroll (for
example by pressing Enter for a few seconds)
    3. The graphics hang and it oops.



Thanks a lot for the detailed report. Is there any chance that you could try 
any of
the 6.2 rc releases to see if you can reproduce? We removed all of the hand 
rolled
fb code and ported it to drm helpers in change:
df42523c12f8 ("drm/vmwgfx: Port the framebuffer code to drm fb helpers")
which for the first time got into the official kernel in v6.2-rc1 . So any 
kernel
after that shouldn't crash with fbterm, if anyone could verify that'd be much
appreciated.

z

Bug#1030099: ITP: libcatmandu-identifier-perl -- namespace for handling identifiers within the Catmandu framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcatmandu-identifier-perl
  Version : 0.15
  Upstream Author : Vitali Peil
* URL : https://metacpan.org/release/Catmandu-Identifier
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : namespace for handling identifiers within the Catmandu 
framework

Catmandu::Identifier contains a namespace for handling identifiers (for
normalization, validation, etc.), e.g. ISBN, ISSN, ORCID.

Catmandu provides a suite of Perl modules to ease the import, storage,
retrieval, export and transformation of metadata records.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030098: ITP: libcatmandu-i18n-perl -- modules for handling text localisation within the Catmandu framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcatmandu-i18n-perl
  Version : 0.01
  Upstream Author : Nicolas Franck
* URL : https://metacpan.org/release/Catmandu-I18N
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules for handling text localisation within the Catmandu 
framework

Catmandu::I18N contains modules for handling text localisation within the
Catmandu framework

This module uses Locale::Maketext::Lexicon::Gettext
 https://metacpan.org/pod/Locale::Maketext::Lexicon::Gettext

Catmandu provides a suite of Perl modules to ease the import, storage,
retrieval, export and transformation of metadata records.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030092: nvme-cli: nvme list json output contains wrapped-around negative integers

[Daniel Baumann]

Hi Daniel,

thank you for your report - I've just uploaed 2.3 that should indeed fix
it. It would be nice if you could try to confirm it.

Regards,
Daniel

Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration

[Nicholas D Steeves]

Hi Josh,

Thank you for the quick reply, and for updating the maintainer :) I've
tried to write an email that will help you understand the issues with as
quickly as possible, since the final deadline is days away. 'hope it's
not too long or harsh 

As you know, Debian has high standards, and you may remember some of this
from our first review.  When you didn't follow up, I fixed the remaining
issues myself (see 30eb8be to faef886); This time around, please resolve
the issues noted below yourself, before the 5th of February.

If you're short on time and want to take the fastest path, skip to the
paragraph that starts with "If you want".

Upstream has not made a release, so the first changelog point is wrong.
What is really being packaged?

d51515f * Refresh and update patches
  - I would write the following no matter who the original author of the
  patch was: This looks like an attempt to take credit for someone
  else's work by making some some changes that aren't significant for
  the purposes of copyright; this sort of thing will eventually make you
  look bad and/or get you into trouble, so I'm raising it as an issue now.
  The patch was already DEP-3 compliant, and you removed the original
  authorship date.  Also, the "Debian package number" is "-1" for both
  the upstream versions mentioned in this changelog...  Make only the
  required two line change, as well as adding the recommended
  "Last-Update" field.
  Think about it this way:
1) You are the steward of a patch written by and © someone else.  This
will sometimes (but not always) happen if you neglect your package
when it has issues.  Consider reading about Salvaging and NMUs.
2) You should document your changes to the patch[es], and the
reasons for your changes in debian/changelog.
3) Likewise, you are the steward of upstream software, and should
document your changes, reasons for the changes, as well as technical
decisions in d/changelog.
  - The changelog entry needs to say what you did, what you changed, and
  why.  Did you copy this text from somewhere?  I ask because there is
  only one patch.

101827a * Update Std-Ver, no changes required, remove unnecessary 
constraint
  - Should be two commits, and must be two changelog points.  These two
  changelog points must say what one actually did.  Here is a nice
  unambiguous line that was taught to me when I was starting out:

* Declare compliance with Standards-Version x.y.z (no changes required).

  And one can only claim that after verifying that the package is in
  fact Policy version x.y.z-compliant:
https://www.debian.org/doc/debian-policy/upgrading-checklist.html

  Did you verify if the package was Policy version x.y.z compliant?
  With which version?

  As for the second point, you need to say what the "unnecessary
  constraint" was, as well as why it's now unnecessary.  A second reason
  to say what and why is because you don't want it to look like you
  plagiarised a robot's MR:

https://salsa.debian.org/emacsen-team/kotlin-mode/-/merge_requests/1

00a3d78 * Update copyright years
  - To add 2023 requires having made work that meets the minimum
  threshold of originality.

https://en.wikipedia.org/wiki/Threshold_of_originality

I would be happy to help you gain the understanding that is necessary to
write good enough changelog entries to meet that threshold of
originality.  If you need any hints, pointers, or explanations, don't
hesitate to ask.

If you want to stage your changes in a feature branch and have me review
them there, I'd be happy to use that approach[1].  Also, for small
packages, I offer one free git hard reset and/or history rewriting
event, which you may use at any time.


Take care, good luck, and have fun!
Nicholas

[1] 
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow


signature.asc
Description: PGP signature

Bug#1030097: groff: gropdf does not use /etc/papersize in DESC

[Ben Wong]

Package: groff
Version: 1.22.4-9
Severity: normal
Tags: patch
X-Debbugs-Cc: bugs.debian@wongs.net

Dear Maintainer,

The gropdf Perl script has a few bugs.

1. It does not include /etc/papersize as the first place to check for
   the default paper size. The problem is that the "papersize"
   directive in fonts/devpdf/DESC only lists "a4" (or "letter").

papersize a4

   Instead it should look like this:

papersize /etc/papersize a4

2. It does not search each possible papersize listed in DESC, which is
   the documented behaviour in the groff_font manual. The fix for that
   requires editing the Perl script and splitting the papersizes on
   the space character.


To reproduce the problem, try this:

man -Tpdf groff > groff.pdf  &&  pdfinfo groff.pdf | grep size


I have attached two patches, one for each bug. The first changes the
devpdf.am file so that it prepends "/etc/papersize" to the search. The
code was copied from devps.am.

The second patch adds a loop around the check of the $papersz variable
in gropdf.pl. Because another level of indentation was added, the diff
makes it look like more of the code changed than actually did.

Thank you.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages groff depends on:
ii  groff-base  1.22.4-9
ii  libc6   2.36-8
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.3-3
ii  libxaw7 2:1.0.14-1
ii  libxmu6 2:1.1.3-3
ii  libxt6  1:1.2.1-1

Versions of packages groff recommends:
ii  ghostscript  10.0.0~dfsg-9+b1
ii  imagemagick  8:6.9.11.60+dfsg-1.4+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.4+b1
ii  libpaper11.1.28+b1
ii  netpbm   2:11.01.00-2
ii  perl 5.36.0-7
ii  psutils  1.17.dfsg-4

groff suggests no packages.

-- no debconf information
--- font/devpdf/devpdf.am.orig  2023-01-30 19:12:42.600754792 -0800
+++ font/devpdf/devpdf.am   2023-01-30 19:15:00.829075259 -0800
@@ -1,9 +1,9 @@
-# Copyright (C) 2011-2018 Free Software Foundation, Inc.
+# Copyright (C) 2011-2022 Free Software Foundation, Inc.
 #  Original Makefile.sub written
 #  by Deri James 
 #  Automake migration by Bertrand Garrigues
 #
-# Last update: 2017-11-02
+# Last update: 2022-01-30
 #
 # This file is part of groff.
 #
@@ -95,9 +95,9 @@
&& $(RM) $(top_builddir)/font/devpdf/DESC \
&& cat $(devpdf_srcdir)/DESC.in >$(top_builddir)/font/devpdf/DESC \
&& if test "$(PAGE)" = A4; then \
-echo "papersize a4" >>$(top_builddir)/font/devpdf/DESC; \
+echo "papersize /etc/papersize a4" 
>>$(top_builddir)/font/devpdf/DESC; \
   else \
-echo "papersize letter" >>$(top_builddir)/font/devpdf/DESC; \
+echo "papersize /etc/papersize letter" 
>>$(top_builddir)/font/devpdf/DESC; \
   fi
 
 font/devpdf/Foundry:
--- src/devices/gropdf/gropdf.pl.orig   2023-01-30 17:23:40.938310920 -0800
+++ src/devices/gropdf/gropdf.pl2023-01-30 18:55:24.859580795 -0800
@@ -248,39 +248,49 @@
 LoadDesc();
 
 my $unitwidth=$desc{unitwidth};
-my $papersz=$desc{papersize};
-$papersz=lc($fpsz) if $fpsz;
-
 $env{FontHT}=0;
 $env{FontSlant}=0;
 MakeMatrix();
 
-if (substr($papersz,0,1) eq '/' and -r $papersz)
+my $possiblesizes = $desc{papersize};
+$possiblesizes = $fpsz . " " . $possiblesizes if $fpsz;
+my $papersz;
+for $papersz ( split(" ", lc($possiblesizes)) )
 {
-if (open(P,"<$papersz"))
+# Check for "/etc/papersize"
+if (substr($papersz,0,1) eq '/' and -r $papersz)
 {
-   while ()
+   if (open(P,"<$papersz"))
{
-   chomp;
-   s/# .*//;
-   next if $_ eq '';
-   $papersz=$_;
-   last
+   while ()
+   {
+   chomp;
+   s/# .*//;
+   next if $_ eq '';
+   $papersz=$_;
+   last;
+   }
+   close(P);
}
+}
 
-   close(P);
+# Allow height,width specified directly in centimeters, inches, or points.
+if ($papersz=~m/([\d.]+)([cipP]),([\d.]+)([cipP])/)
+{
+   @defaultmb=@mediabox=(0,0,ToPoints($3,$4),ToPoints($1,$2));
+   last;
+}
+# Look $papersz up as a name such as "a4" or "letter".
+elsif (exists($ppsz{$papersz}))
+{
+   @defaultmb=@mediabox=(0,0,$ppsz{$papersz}->[0],$ppsz{$papersz}->[1]);
+   last;
 }
-}
 
-if ($papersz=~m/([\d.]+)([cipP]),([\d.]+)([cipP])/)
-{
-@defaultmb=@mediabox=(0,0,ToPoints($3,$4),ToPoints($1,$2));
-}
-elsif 

Bug#1030096: dask.distributed: autopkgtest failure.

[Peter Green]

Package: dask.distributed
Version: 2022.12.1+ds.1-1
Severity: serious
X-debbugs-cc: 
pkg-grass-de...@lists.alioth.debian.org,debian-science-maintain...@lists.alioth.debian.org

The autopkgtest for dask.distributed is failing.

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask.distributed/30859887/log.gz

deploy/tests/test_local.py::test_remote_access <- ../../../../usr/lib/python3/dist-packages/distributed/deploy/tests/test_local.py 
INTERNALERROR> Traceback (most recent call last):

INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
270, in wrap_session
INTERNALERROR> session.exitstatus = doit(config, session) or 0
INTERNALERROR>  ^
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
324, in _main
INTERNALERROR> config.hook.pytest_runtestloop(session=session)
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 
265, in __call__
INTERNALERROR> return self._hookexec(self.name, self.get_hookimpls(), 
kwargs, firstresult)
INTERNALERROR>

INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 
80, in _hookexec
INTERNALERROR> return self._inner_hookexec(hook_name, methods, kwargs, 
firstresult)
INTERNALERROR>
^
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 
60, in _multicall
INTERNALERROR> return outcome.get_result()
INTERNALERROR>
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 
60, in get_result
INTERNALERROR> raise ex[1].with_traceback(ex[2])
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 
39, in _multicall
INTERNALERROR> res = hook_impl.function(*args)
INTERNALERROR>   ^
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
349, in pytest_runtestloop
INTERNALERROR> item.config.hook.pytest_runtest_protocol(item=item, 
nextitem=nextitem)
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 
265, in __call__
INTERNALERROR> return self._hookexec(self.name, self.get_hookimpls(), 
kwargs, firstresult)
INTERNALERROR>

INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 
80, in _hookexec
INTERNALERROR> return self._inner_hookexec(hook_name, methods, kwargs, 
firstresult)
INTERNALERROR>
^
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 
60, in _multicall
INTERNALERROR> return outcome.get_result()
INTERNALERROR>
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 
60, in get_result
INTERNALERROR> raise ex[1].with_traceback(ex[2])
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 
39, in _multicall
INTERNALERROR> res = hook_impl.function(*args)
INTERNALERROR>   ^
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 
112, in pytest_runtest_protocol
INTERNALERROR> runtestprotocol(item, nextitem=nextitem)
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 
131, in runtestprotocol
INTERNALERROR> reports.append(call_and_report(item, "call", log))
INTERNALERROR>^^
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 
222, in call_and_report
INTERNALERROR> report: TestReport = 
hook.pytest_runtest_makereport(item=item, call=call)
INTERNALERROR>  

INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 
265, in __call__
INTERNALERROR> return self._hookexec(self.name, self.get_hookimpls(), 
kwargs, firstresult)
INTERNALERROR>

INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 
80, in _hookexec
INTERNALERROR> return self._inner_hookexec(hook_name, methods, kwargs, 
firstresult)
INTERNALERROR>
^
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 
55, in _multicall
INTERNALERROR> gen.send(outcome)
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/skipping.py", 
line 265, in pytest_runtest_makereport
INTERNALERROR> rep = outcome.get_result()
INTERNALERROR>   
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 

Bug#1030095: hplip is broken as reported by hp-check (see below). This renders

[Michael Haag]

Package: hplip
Version: 3.21.2+dfsg1-2
Severity: important
X-Debbugs-Cc: haa...@zoho.com

hplip is broken as reported by hp-check (see below). This renders
package unusable.


error: 'cups' package is missing or 'cups' service is not running.
error: 'libcups2' package is missing/incompatible 
error: 'libdbus-1-dev' package is missing/incompatible 
error: 'libjpeg62-turbo-dev' package is missing/incompatible 
error: 'libcups2-dev' package is missing/incompatible 
error: 'cups-bsd' package is missing/incompatible 
error: 'cups-client' package is missing/incompatible 
error: 'libcupsimage2' package is missing/incompatible 
error: 'libcupsimage2-dev' package is missing/incompatible 
error: 'libc6' package is missing/incompatible 
error: 'libusb-1.0.0-dev' package is missing/incompatible 
error: 'libsane-dev' package is missing/incompatible 
error: 'libavahi-client-dev' package is missing/incompatible 
error: 'libavahi-core-dev' package is missing/incompatible 
error: 'libavahi-common-dev' package is missing/incompatible 
error: 'libsnmp-dev' package is missing/incompatible 
error: 'snmp' package is missing/incompatible 
error: 'libssl-dev' package is missing/incompatible 
error: 'python3-pyqt4' package is missing/incompatible 
error: 'gtk2-engines-pixbuf' package is missing/incompatible 
error: 'python3-dev' package is missing/incompatible 
error: 'libtool' package is missing/incompatible 
error: 'libtool-bin' package is missing/incompatible 
error: 'g++' package is missing/incompatible 
error: 'make' package is missing/incompatible 

Missing Optional Dependencies
-
error: 'avahi-utils' package is missing/incompatible 
error: 'python3-dbus.mainloop.qt' package is missing/incompatible 



-- Package-specific info:
Saving output in log file: /home/mhaag/hp-check.log

HP Linux Imaging and Printing System (ver. 3.21.2)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling 
the HPLIP supplied tarball   
(.tar.gz or .run) to determine if the proper dependencies are installed to 
successfully compile HPLIP.
2. Run-time check mode (-r or --run): Use this mode to determine if a distro 
supplied package (.deb, .rpm,
etc) or an already built HPLIP supplied tarball has the proper dependencies 
installed to successfully run.
3. Both compile- and run-time check mode (-b or --both) (Default): This mode 
will check both of the above 
cases (both compile- and run-time dependencies).
  

Check types:
  
a. EXTERNALDEP - External Dependencies  
  
b. GENERALDEP - General Dependencies (required both at compile and run time)
  
c. COMPILEDEP - Compile time Dependencies   
  
d. [All are run-time checks]
  
PYEXT SCANCONF QUEUES PERMISSION
  

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

warning: debian-11 version is not supported. Using debian-10.7 versions 
dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) GNU/Linux
 Host: bullseye
 Proc: 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) GNU/Linux
 Distribution: debian 11
 Bitness: 64 bit


---
| HPLIP CONFIGURATION |
---

HPLIP-Version: HPLIP 3.21.2
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian 
distro  11 version 

Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.21.2

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip
html=/usr/share/doc/hplip-doc
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=no
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=no
foomatic-rip-hplip-install=no

Bug#993787: totem: split out thumbnailer in it's own package

[Mark Harfouche]

Hi All,

I would like to request for this to be the case for a few reasons:

1. It seems that the "thumnailing" functionality is tied to the video
player. This is somewhat problematic since I've had alot of hard time
getting the thumnailer to work, while the video player works wonders. But
since many colleagues of mine want thumbnailing to work, the only resort I
have is to ask them to remove the `totem-common` package altogether, thus
removing totem.

2. It seems that there are many unresolved bugs in ubuntu (and debian)
regarding thumbnailing with totem. It would be good if users had a choice
between different thumbnailers for video, and different video players.
totem-thumbnailer vs ffmpegthumbnailer, totem vs vlc come to mind. Today, I
cannot use totem + ffmpegthumbnailer.

I've asked ubuntu to split the package, but they referred me back to you.

https://answers.launchpad.net/ubuntu/+source/totem/+question/704576

xref: Growing lists of segfaults dating back a long time in ubuntu:
https://bugs.launchpad.net/ubuntu?field.has_patch==Search==totem-video-thumbnailer_reporter=_dupes=on=NEW=INCOMPLETE_WITH_RESPONSE=INCOMPLETE_WITHOUT_RESPONSE=CONFIRMED=TRIAGED=INPROGRESS=FIXCOMMITTED_no_package=

Thank you for your consideration.

Best,

Mark


On Mon, 06 Sep 2021 16:19:05 +0200 Christoph Anton Mitterer <
cales...@scientia.net> wrote:
> Package: totem
> Version: 3.38.1-2
> Severity: wishlist
>
>
> Hi.
>
> 1)
> totem and totem-common contains a lot of stuff,... totem itself, images,
translations
> and also the totem-video-thumbnailer (in totem) and it's related files
(in totem-common).
>
> Would you possibly consider to split that out into a separate package?
> It's used by several others for displaying purposes (I guess at least
nautilus and nemo)
> and thus makes sense to have it installed separtely for people who don't
use totem
> itself.
>
>
> 2)
> What might be even better is what I've been writing about in the end of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+973942#35
>
> Since there are numerous thumbnailers, I guess at least those:
> $ apt-file search /usr/share/thumbnailers/
> atril-common: /usr/share/thumbnailers/atril.thumbnailer
> blender-data: /usr/share/thumbnailers/blender.thumbnailer
> dia-common: /usr/share/thumbnailers/dia.thumbnailer
> evince: /usr/share/thumbnailers/evince.thumbnailer
> ffmpegthumbnailer: /usr/share/thumbnailers/ffmpegthumbnailer.thumbnailer
> geogebra-gnome: /usr/share/thumbnailers/geogebra.thumbnailer
> gnome-font-viewer: /usr/share/thumbnailers/gnome-font-viewer.thumbnailer
> gnome-hwp-support: /usr/share/thumbnailers/hwp-thumbnailer.thumbnailer
> gnome-nds-thumbnailer:
/usr/share/thumbnailers/gnome-nds-thumbnailer.thumbnailer
> gwyddion-common: /usr/share/thumbnailers/gwyddion.thumbnailer
> heif-thumbnailer: /usr/share/thumbnailers/heif.thumbnailer
> icoextract-thumbnailer:
/usr/share/thumbnailers/exe-thumbnailer.thumbnailer
> libgdk-pixbuf2.0-bin:
/usr/share/thumbnailers/gdk-pixbuf-thumbnailer.thumbnailer
> libgsf-bin: /usr/share/thumbnailers/gsf-office.thumbnailer
> librsvg2-common: /usr/share/thumbnailers/librsvg.thumbnailer
> mate-control-center-common:
/usr/share/thumbnailers/mate-font-viewer.thumbnailer
> mcomix: /usr/share/thumbnailers/comicthumb.thumbnailer
> mypaint: /usr/share/thumbnailers/mypaint-ora.thumbnailer
> ooo-thumbnailer: /usr/share/thumbnailers/ooo.thumbnailer
> pentobi: /usr/share/thumbnailers/pentobi.thumbnailer
> qrenderdoc: /usr/share/thumbnailers/renderdoc.thumbnailer
> tiled: /usr/share/thumbnailers/tiled.thumbnailer
> totem-common: /usr/share/thumbnailers/totem.thumbnailer
>
>
> it would be nice if there was a virtual package or so, that all of these
could
> provide and that packages (like nautilus) would then depend on,... maybe
with
> some preference e.g.
> Depends: totem-thumbnailer | freedesktop-thumbnailer
>
> So people would get the standard pics/videos thumbnailer (i.e.
totem-thumbnailer)
> but could also easily find thumbnailers for more "exotic" formats like
blender.
>
>
> Obviously this would affect much more than just totem, and I have no real
idea where
> to repot a wishlist ticket for that.
>

Bug#1030094: linux-headers-amd64: DKMS fails to build - missing evdi-dkms

[DAB]

Package: linux-headers-amd64
Version: 6.1.7-1
Severity: normal
Tags: newcomer
X-Debbugs-Cc: macda...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
apt upgrade attempted to install linux-headers v 6.1.4 through 6.1.7 failed to
configure. the error came from DKMS build

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
examining the logs i saw it was something with evdi. i searched and found a
package evdi-dkms which seemed appropriate. i installed that and it fixed the
problem.

   * What was the outcome of this action?
the build failed and prevented boot without reverting to a previous version of
the kernel

   * What outcome did you expect instead?
if the package is needed, it should be flagged as a dependency

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (100, 
'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
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 linux-headers-amd64 depends on:
ii  linux-headers-6.1.0-2-amd64  6.1.7-1

linux-headers-amd64 recommends no packages.

linux-headers-amd64 suggests no packages.

-- no debconf information

Bug#1030084: heimdal: Please provide systemd units

[Brian May]

Chris Hofstaedtler  writes:

> your packages heimdal-kcm and heimdal-kdc currently ship init.d
> scripts and rely on systemd-sysv-generator(8) to integrate with
> systemd, Debians default init.
>
> Please ship systemd unit files instead of relying on the sysv shim.
> When doing so, you could consider taking advantage of new features,
> like sandboxing.
>
> In case upstream does not ship unit files, maybe what Fedora ships
> could serve as a starting point:
> https://src.fedoraproject.org/rpms/heimdal/tree/rawhide>

My time is somewhat restricted at the moment. If somebody wants to
contribute a tested merge request to
https://salsa.debian.org/debian/heimdal to do this, that would be
appreciated :-)
-- 
Brian May 

Bug#1030093: dgit: can't import python-coverage.

[Peter Green]

Package: dgit

mkdir dgittest
cd dgittest
dget -d 
http://deb.debian.org/debian/pool/main/p/python-coverage/python-coverage_6.5.0+dfsg1-2.dsc
mkdir repo
cd repo
git init
dgit import-dsc ../python-coverage_6.5.0+dfsg1-2.dsc +workingbranch

Dgit metadata in .dsc: NO git hash
using existing python-coverage_6.5.0+dfsg1.orig.tar.xz
using existing python-coverage_6.5.0+dfsg1-2.debian.tar.xz
dpkg-source: info: extracting python-coverage in python-coverage-6.5.0+dfsg1
dpkg-source: info: unpacking python-coverage_6.5.0+dfsg1.orig.tar.xz
dpkg-source: info: unpacking python-coverage_6.5.0+dfsg1-2.debian.tar.xz
warning: gbp pq import failed: subprocess failed with error exit status 1
dgit: trying slow absurd-git-apply...
Traceback (most recent call last):
  File "/usr/bin/gbp", line 149, in 
sys.exit(supercommand())
  File "/usr/bin/gbp", line 145, in supercommand
return module.main(args)
  File "/usr/lib/python3/dist-packages/gbp/scripts/pq.py", line 488, in main
import_pq(repo, current, options)
  File "/usr/lib/python3/dist-packages/gbp/scripts/pq.py", line 374, in 
import_pq
options.upstream_tag)
  File "/usr/lib/python3/dist-packages/gbp/scripts/pq.py", line 335, in 
import_quilt_patches
apply_and_commit_patch(repo, patch, maintainer, patch.topic, name)
  File "/usr/lib/python3/dist-packages/gbp/scripts/common/pq.py", line 313, in 
apply_and_commit_patch
author = {'name': patch.author,
  File "/usr/lib/python3/dist-packages/gbp/patch_series.py", line 181, in author
return self._get_info_field('author')
  File "/usr/lib/python3/dist-packages/gbp/patch_series.py", line 164, in 
_get_info_field
self._read_info()
  File "/usr/lib/python3/dist-packages/gbp/patch_series.py", line 196, in 
_read_info
super(Dep3Patch, self)._read_info()
  File "/usr/lib/python3/dist-packages/gbp/patch_series.py", line 62, in 
_read_info
self._read_git_mailinfo()
  File "/usr/lib/python3/dist-packages/gbp/patch_series.py", line 81, in 
_read_git_mailinfo
for line in open(self.path, 'rb'):
IsADirectoryError: [Errno 21] Is a directory: 
'/home/plugwash/dgittest/repo/.git/dgit/unpack/python-coverage-6.5.0+dfsg1/debian/patches/'
gbp pq import failed: subprocess failed with error exit status 1

I noticed as weird character which mcedit shows as "^L" in 
debian/patches/series, perhaps this is related.

Tested both on my somewhat outdated laptop, and in an up to date sid chroot.

Bug#858496: obexftp: broken symlinks: /usr/share/man/man1/obex{rm, put, ls, get}.1.gz -> obexftp.1.gz

[наб]

Control: found -1 0.24-9

Still the case on sid; there doesn't appear to be a manual at all:
-- >8 --
$ dpkg -L obexftp | grep man
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/obexget.1.gz
/usr/share/man/man1/obexls.1.gz
/usr/share/man/man1/obexput.1.gz
/usr/share/man/man1/obexrm.1.gz
$ ls -ld $(dpkg -L obexftp | grep man)
drwxr-xr-x 40 root root   40 Jan 28 21:19 /usr/share/man
drwxr-xr-x  2 root root 2525 Jan 31 03:20 /usr/share/man/man1
lrwxrwxrwx  1 root root   12 Dec 20 03:01 /usr/share/man/man1/obexget.1.gz -> 
obexftp.1.gz
lrwxrwxrwx  1 root root   12 Dec 20 03:01 /usr/share/man/man1/obexls.1.gz -> 
obexftp.1.gz
lrwxrwxrwx  1 root root   12 Dec 20 03:01 /usr/share/man/man1/obexput.1.gz -> 
obexftp.1.gz
lrwxrwxrwx  1 root root   12 Dec 20 03:01 /usr/share/man/man1/obexrm.1.gz -> 
obexftp.1.gz
$ cat $(dpkg -L obexftp | grep man)
cat: /usr/share/man: Is a directory
cat: /usr/share/man/man1: Is a directory
cat: /usr/share/man/man1/obexget.1.gz: No such file or directory
cat: /usr/share/man/man1/obexls.1.gz: No such file or directory
cat: /usr/share/man/man1/obexput.1.gz: No such file or directory
cat: /usr/share/man/man1/obexrm.1.gz: No such file or directory
-- >8 --

Best,
наб


signature.asc
Description: PGP signature

Bug#1029825: emacs: reduce libgccjit0 related dependencies to optional?

[Rob Browning]

David Bremner  writes:

> OK, but two weeks before the soft freeze is IMHO not a good time for
> this kind of experiment.  We just went through literally months of
> debugging to get native compilation mostly working in emacs and hundreds
> of associated packages. I suspect your proposed change will yield a
> whole bunch of new bugs from people who don't install recommends, and
> then don't understand what is broken.
>
> With that said, I'm not the emacs maintainer, so I will bow out of the
> discussion.

I think you're right.  Even if we decide we want to, there's no time
left for this release, and some of the work might not even be wrt the
emacs packages, proper.

That said, and as you mentioned, we could also consider other/additional
flavors of emacs, but of course those have their own costs.

In any case, happy to discuss adjustments for unstable after the
release.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#1030092: nvme-cli: nvme list json output contains wrapped-around negative integers

[Daniel Swarbrick]

Package: nvme-cli
Version: 2.2.1-4
Severity: normal

Dear Maintainer,

Since the update of nvme-cli to v2.x, the JSON output of an "nvme list"
command contains wrapped-around negative integers for various fields,
e.g.:

{
  "Devices":[
{
  "NameSpace":1,
  "DevicePath":"/dev/nvme0n1",
  "Firmware":"2B0QBXX7",
  "ModelNumber":"Samsung SSD 950 PRO 256GB",
  "SerialNumber":"",
  "UsedBytes":-2147483648,
  "MaximumLBA":500118192,
  "PhysicalSize":-2147483648,
  "SectorSize":512
}
  ]
}

Compare with the output of the previous nvme-cli v1.2:

{
  "Devices" : [
{
  "NameSpace" : 1,
  "DevicePath" : "/dev/nvme0n1",
  "Firmware" : "2B0QBXX7",
  "Index" : 0,
  "ModelNumber" : "Samsung SSD 950 PRO 256GB",
  "ProductName" : "Non-Volatile memory controller: Samsung Electronics Co 
Ltd VMe SSD Controller SM951/PM951 PM963 2.5\" NVMe PCIe SSD",
  "SerialNumber" : "",
  "UsedBytes" : 93811310592,
  "MaximumLBA" : 500118192,
  "PhysicalSize" : 256060514304,
  "SectorSize" : 512
}
  ]
}

The PhysicalSize item appears to be an overflowed int32 in the v2.2.x
output.

Another example of bogus values for a 1TB drive with nvme-cli 2.2.1

{
  "Devices":[
{
  "NameSpace":1,
  "DevicePath":"/dev/nvme0n1",
  "Firmware":"41001131",
  "ModelNumber":"PC711 NVMe SK hynix 1TB",
  "SerialNumber":"",
  "UsedBytes":-2147483648,
  "MaximumLBA":2000409264,
  "PhysicalSize":-2147483648,
  "SectorSize":512
}
  ]
}

Upstream has published new releases of nvme-cli (v2.3) and libnvme
(v1.3) in the last 24 hours, and skimming through the changelog I get
the feeling that this bug may have been resolved by those releases.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_NZ:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nvme-cli depends on:
ii  libc6 2.36-8
ii  libjson-c50.16-2
ii  libnvme1  1.2-3
ii  uuid-runtime  2.38.1-4
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages nvme-cli recommends:
ii  pci.ids  0.0~2023.01.18-1

nvme-cli suggests no packages.

-- no debconf information

Bug#1030091: bluez-tools: bt-obex -s yields "GLib-CRITICAL" errors, works fine otherwise

[наб]

Okay, no it doesn't. The file didn't actually get saved anywhere.

Additionally, I also see
-- >8 --
$ bt-obex -f 00:25:E7:4E:08:7F
FTP session opened
> ls
Segmentation fault
$ bt-obex -f 00:25:E7:4E:08:7F
FTP session opened
> cd dupa
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "ChangeFolder" 
with signature "s" on interface "org.bluez.obex.FileTransfer" doesn't exist

>
-- >8 --

наб


signature.asc
Description: PGP signature

Bug#1030091: bluez-tools: bt-obex -s yields "GLib-CRITICAL" errors, works fine otherwise

[наб]

Package: bluez-tools
Version: 2.0~20170911.0.7cb788c-4
Severity: normal

Dear Maintainer,

I just ran this session:
-- >8 --
$ bt-obex -s
[OBEX Server] OBEX session opened
[OBEX Server] Transfer started

(bt-obex:19575): GLib-CRITICAL **: 02:49:08.224: g_variant_get_type: assertion 
'value != NULL' failed

(bt-obex:19575): GLib-CRITICAL **: 02:49:08.224: g_variant_type_is_subtype_of: 
assertion 'g_variant_type_check (type)' failed

(bt-obex:19575): GLib-CRITICAL **: 02:49:08.225: g_variant_get_uint64: 
assertion 'g_variant_is_of_type (value, G_VARIANT_TYPE_UINT64)' failed
[Transfer Request]
  Name: wrażenie książki!.gif
  Size: 426 bytes
Accept (yes/no)? yes
[OBEX Server] Transfer succeeded
[OBEX Server] OBEX transfer closed
[OBEX Server] OBEX session closed
^C** Message: 02:52:45.252: SIGINT received

(bt-obex:19575): GLib-CRITICAL **: 02:52:45.252: g_atomic_ref_count_dec:
assertion 'old_value > 0' failed
-- >8 --

It did Just Work tho, so idk. Maybe it's not /that/ critical.

Best,
наб


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bluez-tools depends on:
ii  libc6 2.36-6
ii  libglib2.0-0  2.74.1-2
ii  libreadline8  8.2-1.2

Versions of packages bluez-tools recommends:
ii  bluez-obexd  5.66-1

bluez-tools suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

[Helge Deller]

Hi David & Andreas,

On 1/28/23 12:10, David Prévot wrote:

Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit :

On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson  wrote:

Here's a slightly different patch to implement basically the same thing


Unfortunately, even if both patches allow me to build tar on i386, they
also both lead to an FTBFS on amd64.


That's right. glibc headers used by configure complains then that _TIME_BITS=64 
can only be
used if FILE_OFFSET_BITS=64 is defined too (which isn't the case on amd64
as it's not needed there).

So, please use this hunk instead. It compiles for me on amd64 and 32-bit hppa.

export DEB_BUILD_MAINT_OPTIONS = future=+lfs
export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument
ifneq ($(shell dpkg-architecture -qDEB_TARGET_ARCH_BITS),64)
export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64
endif

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk
---
Helge

Bug#1030090: RFS: alien-arena/7.71.3+dfsg-1 [ITA] -- Standalone 3D first person online deathmatch shooter

[Raoul de Raadt]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "alien-arena":

* Package name : alien-arena
Version : 7.71.3+dfsg-1
Upstream contact : Raoul de Raadt 
* URL : https://martianbackup.com
* License : GPL-2.0-or-later, LGPL-2.1-or-later
* Vcs : https://salsa.debian.org/games-team/alien-arena
Section : contrib/games

The source builds the following binary packages:

alien-arena - Standalone 3D first person online deathmatch shooter
alien-arena-server - Dedicated server for Alien Arena

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/alien-arena/

Alternatively, you can download the package with 'dget' using this command:

dget -x 
https://mentors.debian.net/debian/pool/contrib/a/alien-arena/alien-arena_7.71.3+dfsg-1.dsc


Changes since the last upload:

alien-arena (7.71.3+dfsg-1) unstable; urgency=medium
.
[ Phil Morrell ]
* Team upload.
* monitor svn tags for new versions
* use copyright-format 1.0
* use Files-Excluded, drop create-upstream-tarballs
.
[ Raoul de Raadt ]
* Changed copyright file according to 7.71.3
* Removed old patches and exclude adivtab.h
* New upstream version 7.71.3

Regards,

Raoul de Raadt

Bug#1030089: preload: Please provide systemd unit

[Chris Hofstaedtler]

Package: preload
Version: 0.6.4-5+b1
Severity: normal

Hello Jonathan,

preload currently ships an init.d script and relies on
systemd-sysv-generator(8) to integrate with systemd.

Please consider shipping a systemd unit file, instead of relying on the
sysv shim. Fedora apparently used to ship this file, maybe it can serve
as a starting point:
  https://src.fedoraproject.org/rpms/preload/blob/f29/f/preload.service

Thanks,
Chris

Bug#1030088: ITP: tree-sitter-c -- C grammar for tree-sitter

[James McCoy]

Package: wnpp
Severity: wishlist
Owner: James McCoy 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: tree-sitter-c
  Version : 0.20.2
  Upstream Contact: Max Brunsfeld
* URL : https://github.com/tree-sitter/tree-sitter-c
* License : MIT
  Programming Lang: Javascript, C, Rust
  Description : C grammar for tree-sitter

This package provides a tree-sitter parser for C99.

This is needed for Neovim's tests and is one of the tree-sitter parsers
expected to be available.

Bug#1030087: xinetd: Please provide systemd unit

[Chris Hofstaedtler]

Package: xinetd
Version: 1:2.3.15.3-1
Severity: normal

Dear xinetd Maintainers,

your package currently ships an init.d script, and relies on
systemd-sysv-generator(8) for integration with systemd, Debians default
init system.

Please ship a systemd unit, instead of relying on the sysv shim.

Maybe the Fedora unit file can serve as a starting point:
  https://src.fedoraproject.org/rpms/xinetd/blob/f27/f/xinetd.service

Thanks,
Chris

Bug#787243: trousers: diff for NMU version 0.3.15-0.3

[Chris Hofstaedtler]

Control: tags 787243 + patch
Control: tags 787243 + pending


Dear maintainer,

I've prepared an NMU for trousers (versioned as 0.3.15-0.3) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru trousers-0.3.15/debian/changelog trousers-0.3.15/debian/changelog
--- trousers-0.3.15/debian/changelog2022-04-13 14:42:37.0 +
+++ trousers-0.3.15/debian/changelog2023-01-30 22:45:09.0 +
@@ -1,3 +1,11 @@
+trousers (0.3.15-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add systemd service file. Based on patch by Laurent Bigonville.
+(Closes: #787243)
+
+ -- Chris Hofstaedtler   Mon, 30 Jan 2023 22:45:09 +
+
 trousers (0.3.15-0.2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru trousers-0.3.15/debian/rules trousers-0.3.15/debian/rules
--- trousers-0.3.15/debian/rules2022-04-13 14:42:37.0 +
+++ trousers-0.3.15/debian/rules2023-01-30 22:45:09.0 +
@@ -10,3 +10,6 @@
 
 override_dh_strip:
dh_strip --dbg-package=trousers-dbg
+
+override_dh_installsystemd:
+   dh_installsystemd -ptrousers --name=tcsd tcsd.service
diff -Nru trousers-0.3.15/debian/trousers.links 
trousers-0.3.15/debian/trousers.links
--- trousers-0.3.15/debian/trousers.links   1970-01-01 00:00:00.0 
+
+++ trousers-0.3.15/debian/trousers.links   2023-01-30 22:43:58.0 
+
@@ -0,0 +1 @@
+lib/systemd/system/tcsd.service lib/systemd/system/trousers.service
diff -Nru trousers-0.3.15/debian/trousers.tcsd.service 
trousers-0.3.15/debian/trousers.tcsd.service
--- trousers-0.3.15/debian/trousers.tcsd.service1970-01-01 
00:00:00.0 +
+++ trousers-0.3.15/debian/trousers.tcsd.service2023-01-30 
22:43:01.0 +
@@ -0,0 +1,9 @@
+[Unit]
+Description=TCG Core Services Daemon
+
+[Service]
+Type=forking
+ExecStart=/usr/sbin/tcsd
+
+[Install]
+WantedBy=multi-user.target

Bug#1030086: deluge: diff for NMU version 2.0.3-3.3

[Chris Hofstaedtler]

Package: deluge
Version: 2.0.3-3.2
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for deluge (versioned as 2.0.3-3.3) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru deluge-2.0.3/debian/changelog deluge-2.0.3/debian/changelog
--- deluge-2.0.3/debian/changelog   2022-11-12 20:37:10.0 +
+++ deluge-2.0.3/debian/changelog   2023-01-30 23:15:03.0 +
@@ -1,3 +1,10 @@
+deluge (2.0.3-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install upstream-supplied systemd unit files. (Closes: #927197, #966287)
+
+ -- Chris Hofstaedtler   Mon, 30 Jan 2023 23:15:03 +
+
 deluge (2.0.3-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru deluge-2.0.3/debian/control deluge-2.0.3/debian/control
--- deluge-2.0.3/debian/control 2022-11-12 20:37:10.0 +
+++ deluge-2.0.3/debian/control 2023-01-30 23:15:03.0 +
@@ -48,6 +48,7 @@
 
 Package: deluged
 Architecture: all
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${python3:Depends},
  deluge-common (= ${source:Version}),
diff -Nru deluge-2.0.3/debian/deluged.install 
deluge-2.0.3/debian/deluged.install
--- deluge-2.0.3/debian/deluged.install 2022-11-12 20:37:10.0 +
+++ deluge-2.0.3/debian/deluged.install 2023-01-30 23:10:50.0 +
@@ -1,3 +1,4 @@
 usr/bin/deluged
 usr/share/appdata/deluge.appdata.xml
 usr/share/man/man1/deluged.1
+packaging/systemd/deluged.service lib/systemd/system
diff -Nru deluge-2.0.3/debian/deluge-web.install 
deluge-2.0.3/debian/deluge-web.install
--- deluge-2.0.3/debian/deluge-web.install  2022-11-12 20:37:10.0 
+
+++ deluge-2.0.3/debian/deluge-web.install  2023-01-30 23:11:40.0 
+
@@ -1,3 +1,4 @@
 usr/bin/deluge-web
 usr/lib/python*/*-packages/deluge/ui/web/*
 usr/share/man/man1/deluge-web.1
+packaging/systemd/deluge-web.service lib/systemd/system
diff -Nru deluge-2.0.3/debian/patches/series deluge-2.0.3/debian/patches/series
--- deluge-2.0.3/debian/patches/series  2022-11-12 20:37:10.0 +
+++ deluge-2.0.3/debian/patches/series  2023-01-30 23:11:48.0 +
@@ -1,3 +1,4 @@
 new_release_check.patch
 0001-Fix-warning-related-to-gettext.patch
 setuptools-60.patch
+systemd-debian.patch
diff -Nru deluge-2.0.3/debian/patches/systemd-debian.patch 
deluge-2.0.3/debian/patches/systemd-debian.patch
--- deluge-2.0.3/debian/patches/systemd-debian.patch1970-01-01 
00:00:00.0 +
+++ deluge-2.0.3/debian/patches/systemd-debian.patch2023-01-30 
23:15:03.0 +
@@ -0,0 +1,32 @@
+Index: deluge-2.0.3/packaging/systemd/deluge-web.service
+===
+--- deluge-2.0.3.orig/packaging/systemd/deluge-web.service
 deluge-2.0.3/packaging/systemd/deluge-web.service
+@@ -7,8 +7,9 @@ Wants=deluged.service
+ [Service]
+ Type=simple
+ UMask=027
+-
+-ExecStart=/usr/bin/deluge-web -d
++User=debian-deluged
++Group=debian-deluged
++ExecStart=/usr/bin/deluge-web -d -c /var/lib/deluged/config
+ 
+ Restart=on-failure
+ 
+Index: deluge-2.0.3/packaging/systemd/deluged.service
+===
+--- deluge-2.0.3.orig/packaging/systemd/deluged.service
 deluge-2.0.3/packaging/systemd/deluged.service
+@@ -6,8 +6,9 @@ After=network-online.target
+ [Service]
+ Type=simple
+ UMask=007
+-
+-ExecStart=/usr/bin/deluged -d
++User=debian-deluged
++Group=debian-deluged
++ExecStart=/usr/bin/deluged -d -c /var/lib/deluged/config -l 
/var/log/deluged/daemon.log -L info
+ 
+ Restart=on-failure
+ 

Bug#1030085: RM: bcolz -- RoQA; Package went unmaintained upstream and it now fails to build from source

[Diane Trout]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: bc...@packages.debian.org
Control: affects -1 + src:bcolz

The bcolz maintainers declared that the package is unmaintained.

https://github.com/Blosc/bcolz

bcolz's single non-meta pacakge dependency was dask, and the dask developers
declared bcolz deprecated.

https://github.com/dask/dask/issues/8330

And now bcolz has started failing to build from source because of changes in
numpy.

https://buildd.debian.org/status/package.php?p=bcolz=sid

We should probably just remove it.

Diane Trout

Bug#1030084: heimdal: Please provide systemd units

[Chris Hofstaedtler]

Source: heimdal
Version: 7.8.git20221117.28daf24+dfsg-1
Severity: normal

Dear heimdal Maintainers,

your packages heimdal-kcm and heimdal-kdc currently ship init.d scripts
and rely on systemd-sysv-generator(8) to integrate with systemd, Debians
default init.

Please ship systemd unit files instead of relying on the sysv shim. When
doing so, you could consider taking advantage of new features, like
sandboxing.

In case upstream does not ship unit files, maybe what Fedora ships could
serve as a starting point:
  https://src.fedoraproject.org/rpms/heimdal/tree/rawhide


Thanks,
Chris

Bug#1030059: pycirkuit: Fails to run autopkgtest test suite

[Hilmar Preuße]

Am 30.01.2023 um 21:11 teilte Hilmar Preusse mit:

Hi,


A few days ago I uploaded a new TeX Live snapshot. Since
then the test suite of your package fails to run, see [1].

Interestingly I can run the line from the test script without
any issue:

/usr/bin/pycirkuit -t -p -f /usr/share/doc/pycirkuit/examples/*.ckt 
--destination /tmp
First I suspected, that my main system has another set of TeX Live

package, but this was wrong: even after stripping down the main system
to all packages, which are listed in the dep of pycirkuit I could
convert the files, using the command above.

Hilmar
--
sigfault

Bug#1030083: clamav-milter: Please provide clamav-milter.service

[Chris Hofstaedtler]

Package: clamav-milter
Version: 1.0.0+dfsg-6
Severity: normal

Dear clamav Maintainers,

thanks for maintaining clamav in Debian and providing systemd units for
most programs. It appears clamav-milter still has an init.d script but
no systemd unit. Please consider providing a corresponding unit file.

I cant say I understand how the sendmail<->clamav integration works, or
if the service file from Fedora would work in Debian, but maybe this is
a starting point:

  https://src.fedoraproject.org/rpms/clamav/blob/rawhide/f/clamav-milter.systemd

This request is to reduce the list of packages relying on
systemd-sysv-generator(8). If you think systems running systemd do not
benefit from clamav-milter, please override the lintian tag
missing-systemd-service-for-init.d-script .

Many thanks,
Chris

Bug#1030082: Directory missing on ExFAT Drives

[Devin Lieberman]

Package: exfatprogs
Version: Debian 11.6.0, Linux Mint 21,1, Kubuntu 22.04.1

When mounting exfat XQD cards formatted by my Sony FS7, the Clips folder
and MXF video files contained therein do not appear despite still existing.
Upon cd into Clips, ls -la shows the BIM and XML sidecar files created at
the time of recording but not the video files. Writing to the disk causes
all files to similarly disappear. When mounted with mount.exfat-fuse, the
Clips folder appears as do the video files. I'm using a Thinkpad X1 Nano
Gen 2 Intel 1260P. Here's the transcript:

$ ls 563C-69AE/XDROOT/
CUEUP.XML Edit MEDIAPRO.XML  TakeUserData
DISCMETA.XML  General  Sub   Thmbnl
$ sudo umount /dev/sda1
$ sudo mount.exfat-fuse /dev/sda1 131/
FUSE exfat 1.3.0+git20220115
$ ls 131/XDROOT/
Clip   DISCMETA.XML  General   Sub   Thmbnl
CUEUP.XML  Edit  MEDIAPRO.XML  Take  UserData
$ ls 131/XDROOT/Clip/
A002C001_2301282SM01.XML  A002C002_230128WMM01.XML  A002C003_230128UKM01.XML
A002C001_2301282S.MXF A002C002_230128WM.MXF A002C003_230128UK.MXF
A002C001_2301282SR01.BIM  A002C002_230128WMR01.BIM  A002C003_230128UKR01.BIM
$ sudo umount /dev/sda1
$ sudo mount /dev/sda1 131/
$ ls 131/XDROOT/Clip/
A002C001_2301282SM01.XML  A002C002_230128WMM01.XML  A002C003_230128UKM01.XML
A002C001_2301282SR01.BIM  A002C002_230128WMR01.BIM  A002C003_230128UKR01.BIM
$ ls 131/XDROOT/
CUEUP.XML Edit MEDIAPRO.XML  TakeUserData
DISCMETA.XML  General  Sub   Thmbnl

I'm not sure of the solution, this is my first bug report! It's definitely
a bug though! Let me know if you need more information and thank you :)

Bug#1030081: galera-arbitrator-3: Please provide native systemd integration

[Chris Hofstaedtler]

Package: galera-arbitrator-3
Version: 25.3.37-1
Severity: normal

Dear galera-3 Maintainers,

your package galera-arbitrator-3 currently ships an init.d script, and
relies on systemd-sysv-generator(8) to provide native integration with
systemd, Debians default init system.

Please ship systemd unit files instead of relying on the sysv shim. When
doing so, you could also consider taking advantage of available security
features, like sandboxing. This might especially be appropiate for a
daemon listening on network sockets.

Thanks,
Chris

Bug#1030080: zephyr: Please provide native systemd integration

[Chris Hofstaedtler]

Source: zephyr
Version: 3.1.2-1.1
Severity: normal

Dear zephyr Maintainers,

your packages currently ship a number of init.d scripts and then rely on
systemd-sysv-generator(8) to integrate with systemd, Debians default
init system.

Please ship systemd unit files, instead of relying on the sysv shim for
this integration. When doing that, you may also consider taking
advantage of security features, like sandboxing. This may especially be
appropiate for a daemon listening on a network socket.

Thanks,
Chris

Bug#1030079: inetutils-inetd: Please provide native systemd integration

[Chris Hofstaedtler]

Package: inetutils-inetd
Version: 2:2.4-2
Severity: normal

Dear inetutils Maintainer,

your package inetutils-inetd currently ships an init.d script, and
relies on systemd-sysv-generator(8) to integrate with systemd, Debians
default init system.

Please ship systemd units, to provide native integration with systemd
instead of relying on the sysv shim. When doing this, you could also
consider taking advantage of available security features, like
sandboxing. Although sandboxing might be inappropiate for inetd.

Thanks,
Chris

Bug#1030054: kitty: build-time test failures in some environments

[James McCoy]

On Mon, Jan 30, 2023 at 11:31:56AM -0800, Steve Langasek wrote:
> [...]
> ==
> ERROR: test_ssh_shell_integration (kitty_tests.ssh.SSHKitten)
> --
> Traceback (most recent call last):
>   File "/<>/kitty/launcher/../../kitty_tests/ssh.py", line 239, 
> in test_ssh_shell_integration
> pty.wait_till(lambda: 'kitty=fruity' in pty.screen_contents())
> login_shell = 'bash'
> num_lines = 2
> ok_login_shell = 'bash'
> pty = 
> self = 
> sh = 'dash'
> tdir = '/tmp/tmpct5s6c0x'
> val = ''
>   File "/<>/kitty/launcher/../../kitty_tests/__init__.py", line 
> 297, in wait_till
> raise TimeoutError(f'The condition was not met. Screen contents: \n 
> {repr(self.screen_contents())}')
> end_time = 1963.133780143
> q = . at 
> 0x7fd0c33475b0>
> self = 
> TimeoutError: The condition was not met. Screen contents: 
>  'UNTAR_DONE\nbuildd@lcy02-amd64-004:~$ echo 
> "$TERM=fruity"\nunknown=fruity\nbuildd@lcy02-amd64-004:~$ '
> 
> [...]
> 
>   (https://launchpad.net/ubuntu/+source/kitty/0.26.5-2/+build/25419959)
> 
> It appears this works in Debian but not in Ubuntu because Debian's builders
> have an empty $TERM in the build environment, whereas Ubuntu has it set by
> default to 'unknown' (as shown above).

This sounds like the issue I filed upstream[0].  I can cherry-pick the
fix[1] Kovid made.

[0]: https://github.com/kovidgoyal/kitty/issues/5852
[1]: 
https://github.com/kovidgoyal/kitty/commit/e2543e8968496223d760f403b9c683c484f02d2c

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB


signature.asc
Description: PGP signature

Bug#1030063: rrdcached: Please install rrdcached.service/socket

[Chris Hofstaedtler]

Package: rrdcached
Version: 1.5.3-1
Severity: normal

Dear rrdtool Maintainers,

the rrdcached package currently ships an init.d script, and relies on
systemd-sysv-generator(8) to integrate with systemd. This integration
glue code might not stay forever.

Upstream helpfully provides an rrdcached.service file (generated from
etc/rrdcached.service.in). Please install it using dh_installsystemd, to
provide for native systemd integration. It might also be useful to
install rrdcached.socket.

I'll note that upstream provides this file since at least 1.5.3.

Thanks,
Chris

Bug#1029731: libglapi-mesa: Apps fail with 'DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory' after upgrade from 22.3.2-1 to 22.3.3-1

[Andrey Skvortsov]

Dear Maintainer,

Since 22.3.4 is out, I've built 22.3.4 myself and checked currently
available 22.3.4-1 packages from sid. The problem exists in 22.3.4 as well.

Here is link to created upstream issue.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198

The problem is caused by commit included in 22.3.3:

```
commit 2adab724e59c662a046cb1da8bfb3177330e01da
Author: Asahi Lina 
Date:   Wed Dec 21 00:37:31 2022 +0900

kmsro: Fix renderonly_scanout BO aliasing

BOs can only have one handle. If renderonly_create_gpu_import_for_resource
ends up importing a BO that was already mapped for scanout, it will get
the same handle. This leaves us with two renderonly_scanout objects for
one handle, and the first one to be destroyed will free it.

Import the BO map tracking logic from asahi, to avoid aliasing
renderonly_scanout objects. Each actual BO now is only represented by a
single object instance, which is reference counted.

Fixes KWin full-screen PipeWire capture breaking scanout entirely.

```

I reverted it and that solved this problem.

On 23-01-27 00:05, Andrey Skvortsov wrote:
> Package: libglapi-mesa
> Version: 22.3.3-1
> Severity: important
> 
> Dear Maintainer,
> 
> 
> after upgrade from 22.3.2-1 to 22.3.3-1 applications starts to crash
> with following error
> 
> ```
> янв 26 23:41:00 mobian-dev dbus-daemon[1018]: [session uid=1000 pid=1018] 
> Activating service name='org.gnome.Console' requested by ':1.34' (uid=1000 
> pid=1250 comm="/usr/libexec/phosh")
> янв 26 23:41:01 mobian-dev dbus-daemon[1018]: [session uid=1000 pid=1018] 
> Successfully activated service 'org.gnome.Console'
> янв 26 23:41:04 mobian-dev org.gnome.Console[6004]: 
> DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
> янв 26 23:41:04 mobian-dev org.gnome.Console[6004]: 
> DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
> ```
> 
> The system is aarch64 (arm64) Original PinePhone running Phosh. To
> trigger this problem I start and close different applications (mostly
> gtk3 and gtk4) after some time (~3-5 minutes) no application can start.
> 
> Downgrade to 22.3.2-1 fixes this problem.
> 
> ```
> wget 
> https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/mesa-vdpau-drivers_22.3.2-1_arm64.deb
> wget 
> https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libegl-mesa0_22.3.2-1_arm64.deb
> wget 
> https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/mesa-va-drivers_22.3.2-1_arm64.deb
> wget 
> https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libglx-mesa0_22.3.2-1_arm64.deb
> wget 
> https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libglapi-mesa_22.3.2-1_arm64.deb
> wget 
> https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libgl1-mesa-dri_22.3.2-1_arm64.deb
> wget 
> https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libgbm1_22.3.2-1_arm64.deb
> ```
> 
> 
> -- Package-specific info:
> glxinfo:
> 
> DISPLAY is not set.
> 
> /usr/share/bug/xserver-xorg-core/script not available
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing')
> Architecture: arm64 (aarch64)
> Foreign Architectures: armhf
> 
> Kernel: Linux 6.1-sunxi64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_WARN, TAINT_CRAP, 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 libglapi-mesa depends on:
> ii  libc6  2.36-8
> 
> libglapi-mesa recommends no packages.
> 
> libglapi-mesa suggests no packages.
> 
> -- no debconf information

-- 
Best regards,
Andrey Skvortsov

Bug#1029968: Acknowledgement (bttv/v4l: WARNING: CPU: 6 PID: 6164 at mm/vmalloc.c:487 __vmap_pages_range_noflush+0x3e0/0x4d0)

[Dr. David Alan Gilbert]

Upstream 5.17 works
Upstream 5.18 fails

(with intel_iommu=on)

Let the bisect begin.

-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Bug#1028489: transition: boost1.81

[Rene Engelhard]

Hi,

Am 30.01.23 um 19:28 schrieb Anton Gladky:
Just for the record. The full test rebuild has been done (thanks to 
Lucas!).

Results and logs are here:

http://qa-logs.debian.net/2023/01/15/


Just for the record:

It definitely misses packages. Probably those which build-depend on 
boost but don't get a runtime dependency on anything boost'ish (because 
it uses the header parts)


(And e.g. libreoffice is #1029104, not libreoffice 1:7.4.4~rc2-2 
1:7.4.4~rc2-2 SAMEVER Failed Failed SAMERES 0 0 SAMETIME /bin/sh: 1: 
git: not found /bin/sh: 1: git: not found which is expected, we don't 
add the git version into the About box)



Regards,


Rene

Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1

[Thorsten Glaser]

Sebastian Andrzej Siewior dixit:

>Okay. So I do nothing and just wait for the bpo package to appear which
>will then solve the problem?

No, you must fix the problem in xz-utils in bookworm/sid as well.
It also exists outside of backports.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1030062: fonts-eurofurence: Package URL points to malicious website

[bugs]

Package: fonts-eurofurence
Version: 4.0-2
Severity: normal

Dear Maintainer,

The package homepage URL points to a malicious (phishing, malware) 
website (eurofurence.net). The current domain of the organisation is 
eurofurence.org.

Bug#1030061: fonts-monofur: Package URL points to malicious website

[bugs]

Package: fonts-monofur
Version: 1.0-2
Severity: normal

Dear Maintainer,

The package homepage URL points to a malicious (phishing, malware)
website (eurofurence.net). The current domain of the organisation is 
eurofurence.org.

Bug#619442: mtd-utils: please include in armel installer

[Uwe Kleine-König]

Hello,

On Mon, Sep 06, 2021 at 10:08:51AM +0200, Uwe Kleine-König wrote:
> On Thu, Sep 24, 2020 at 07:45:04PM +0200, Bastian Germann wrote:
> > On Wed, 26 Nov 2003 18:56:57 -0500 Jonathan Lane
> >  wrote:
> > > I'm running Debian Squeeze on a Marvell Sheevaplug, and I'd really like 
> > > to install Debian directly to NAND memory.  The mtd-utils package 
> > > contains all the tools needed to do that that aren't already in the 
> > > installer, and the existing method of putting a Debian install on the 
> > > internal NAND is a pain in the rear.  I'm in no real hurry to get this 
> > > fixed right now, but it would be nice for future releases like Wheezy.
> > 
> > Would you like the package to have a udeb version like the one that is
> > referenced at https://wiki.debian.org/DebianInstaller/MTD#MTD_utils ?
> > 
> > Is there still interest in this?
> 
> I have interest. I'm working to unbrick my NAS and having the mtd-utils
> available in the installer would simplify this.

Just quickly talked about this issue in #debian-boot. kibi pointed out
that this would likely require a second build to not introduce a
dependeny on selinux.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#993612: [PATCH v2] of/address: Return an error when no valid dma-ranges are found

[Rob Herring]

On Sat, 28 Jan 2023 17:47:50 +, Mark Brown wrote:
> Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
> converted the parsing of dma-range properties to use code shared with the
> PCI range parser. The intent was to introduce no functional changes however
> in the case where we fail to translate the first resource instead of
> returning -EINVAL the new code we return 0. Restore the previous behaviour
> by returning an error if we find no valid ranges, the original code only
> handled the first range but subsequently support for parsing all supplied
> ranges was added.
> 
> This avoids confusing code using the parsed ranges which doesn't expect to
> successfully parse ranges but have only a list terminator returned, this
> fixes breakage with so far as I can tell all DMA for on SoC devices on the
> Socionext Synquacer platform which has a firmware supplied DT. A bisect
> identified the original conversion as triggering the issues there.
> 
> Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
> Signed-off-by: Mark Brown 
> Cc: Luca Di Stefano 
> Cc: 993...@bugs.debian.org
> Cc: sta...@kernel.org
> ---
> Changes in v2:
> - Don't leak parsed resources.
> - Link to v1: 
> https://lore.kernel.org/r/20230126-synquacer-boot-v1-1-94ed0eb10...@kernel.org
> ---
>  drivers/of/address.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 

Applied, thanks!

Bug#1030060: gforth info manual is not installed

[T. Kurt Bond]

Package: gforth
Version: 0.7.3+dfsg-9+b3

The info manual for gforth is not installed.  The emacs lisp support is, so
the info manual should be also.
-- 
T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io

Bug#1029968: Acknowledgement (bttv/v4l: WARNING: CPU: 6 PID: 6164 at mm/vmalloc.c:487 __vmap_pages_range_noflush+0x3e0/0x4d0)

[Dr. David Alan Gilbert]

This is IOMMU related.

Upstream 6.1 and 5.18 *do* exhibit the bug, but only with intel_iommu=on
where as Debian seems to default it to on.

-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Bug#1030046: Document snakeyaml security expectations

[Markus Koschany]

Hi,

Am Montag, dem 30.01.2023 um 18:44 +0100 schrieb Moritz Muehlenhoff:
> 
> Could we please add a README.Debian.security with something like the
> following
> to make this also visible to users?
> 
> 
> Note that snakeyaml isn't designed to operate on YAML data coming from
> untrusted
> sources, in such cases you need to apply sanitising/exception handling
> yourself.
> 
> Please see https://bitbucket.org/snakeyaml/snakeyaml/wiki/CVE%20&%20NIST.md
> for additional information.
> 

Sure, that's doable. But how do we treat the current and new CVE in stable and
oldstable releases? no-dsa, ignored or keep them open until upstream eventually
fixes them?

Cheers,

Markus


signature.asc
Description: This is a digitally signed message part

Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1

[Thorsten Glaser]

Helge Kreutzmann dixit:

>The problem is that we both upload (conflicting) packages to
>backports. I'm not sure a good solution exists here.

No, you need to fix the package relationships for incremental
and partial upgrades in sid anyway.

As far as I can tell, manpages-fr had the first version of
xz-utils that ships the pages in its Breaks+Replaces, but
xz-utils’ Breaks+Replaces did not cover all versions of
manpages-fr that also shipped the pages.

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1

[Sebastian Andrzej Siewior]

On 2023-01-30 21:51:11 [+0100], Helge Kreutzmann wrote:
> Hello Sebastian,
Hi Helge,

> On Mon, Jan 30, 2023 at 07:53:51PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote:
> > > reopen 1028375
> > > found 1028375 5.4.1-0.0
> > > thanks
> > > 
> > > Patrice Duroux dixit:
> > > 
> > > >Was this supposed to be closed? Or will it be with another manpages-fr 
> > > >bpo?
> 
> So far the manpages-fr bpo has not yet happend. My sponsor intends to
> upload it today and then we need to wait for NEW processing.

okay.

> > > 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1)
> > > so the upload did not fix the problem.
> > > 
> > > As far as I can tell it must be (<< 4.17.0-1~) instead.
> > > (Also do note the tilde, it breaks bpo otherwise.)
> > 
> > Okay. So I add this new suggested version and close 1028375?
> 
> The problem is that we both upload (conflicting) packages to
> backports. I'm not sure a good solution exists here.
> 
> If the freeze continues for quite some time, even 4.18.0-1~ might hit
> backports. (In the last freeze it was the case.).
> 
> This is rather tricky.

Okay. So I do nothing and just wait for the bpo package to appear which
will then solve the problem?

> Greetings
> 
> Helge

Sebastian

Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3

[Francesco Poli]

On Mon, 30 Jan 2023 21:14:53 +0100 Lucas Nussbaum wrote:

> Hi Francesco,

Hi Lucas!   :-)

> 
> On 30/01/23 at 20:45 +0100, Francesco Poli (wintermute) wrote:
[...]
> > Why is UDD outdated w.r.t. the lintian version?
> > Shouldn't UDD be aware of the version currently in testing, or maybe
> > even in unstable?
[...]
> 
> The update to a newer lintian version on the UDD lintian worker is a
> manual process.

Ah, I wasn't aware of that.

> I'll do that soon, but I have some other Debian stuff
> queued up that looks more important.
> Any reason in particular you need the latest version?

Well, one reason is that lintian/2.115.3 is incorrectly complaining
about [many packages], stating that they declare compatibility with a
non-existing Debian Policy version.
This obviously happens, because a new Policy version (4.6.2) has been
released after lintian/2.115.3, and all the updated packages are seen
by lintian/2.115.3 as wrong...

[many packages]: 



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpHhkZgebtFh.pgp
Description: PGP signature

Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1

[Helge Kreutzmann]

Hello Sebastian,
On Mon, Jan 30, 2023 at 07:53:51PM +0100, Sebastian Andrzej Siewior wrote:
> On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote:
> > reopen 1028375
> > found 1028375 5.4.1-0.0
> > thanks
> > 
> > Patrice Duroux dixit:
> > 
> > >Was this supposed to be closed? Or will it be with another manpages-fr bpo?

So far the manpages-fr bpo has not yet happend. My sponsor intends to
upload it today and then we need to wait for NEW processing.

> > 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1)
> > so the upload did not fix the problem.
> > 
> > As far as I can tell it must be (<< 4.17.0-1~) instead.
> > (Also do note the tilde, it breaks bpo otherwise.)
> 
> Okay. So I add this new suggested version and close 1028375?

The problem is that we both upload (conflicting) packages to
backports. I'm not sure a good solution exists here.

If the freeze continues for quite some time, even 4.18.0-1~ might hit
backports. (In the last freeze it was the case.).

This is rather tricky.

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#1029720: [Pkg-nagios-devel] Bug#1029720: Bug#1029720: Bug#1029720: monitoring-plugins-contrib: false positive w bookworm kernel: "running kernel does not match on-disk kernel image'

[Hilmar Preuße]

Am 30.01.2023 um 13:57 teilte Hilmar Preuße mit:

Am 30.01.2023 um 13:10 teilte Jan Wagner mit:


Hi,


thanks for confirming.

As I don't have a bookworm system (with running kernel) at hand, I can't
go deeper into debugging this issue until I get hands on it.


I'm able to reproduce, if that helps.

hille@sid-amd64:~$ /usr/lib/nagios/plugins/check_running_kernel
WARNING: Running kernel does not match on-disk kernel image: [Linux
version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1
SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) != Linux version
6.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP
PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18)]


The message above is correct. When comparing the two lines, one notices
that they are not equal:

Linux version 6.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18)

vs.

Linux version 6.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP
PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18)

Meanwhile I rebooted into the 2nd kernel, which did not solve the issue.

H.
--
sigfault

Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1

[Thorsten Glaser]

Sebastian Andrzej Siewior dixit:

>> As far as I can tell it must be (<< 4.17.0-1~) instead.
>> (Also do note the tilde, it breaks bpo otherwise.)
>
>Okay. So I add this new suggested version and close 1028375?

I think so. 4.17.0-1 was the first version of -fr to not
ship it any more (from reading its changelog), and the tilde
is to permit 4.17.0-1~bpo* to match. It’d need to update
both Breaks and Replaces. (I hope I got this right, too ☺)

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3

[Holger Levsen]

On Mon, Jan 30, 2023 at 09:14:53PM +0100, Lucas Nussbaum wrote:
> Any reason in particular you need the latest version?
 
because lintian 2.116.x is much better than 2.115.x ;)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

None of us are safe until all of us are safe. Vaccinate the world.


signature.asc
Description: PGP signature

Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3

[Lucas Nussbaum]

Hi Francesco,

On 30/01/23 at 20:45 +0100, Francesco Poli (wintermute) wrote:
> Package: qa.debian.org
> Severity: normal
> User: qa.debian@packages.debian.org
> Usertags: udd
> 
> Hi!
> 
> In the [UDD Lintian report] for my package, I read:
> 
> [...]
> | The most recent lintian version known by UDD is 2.115.3
> [...]
> 
> [UDD Lintian report]: 
> 
> However, there are more recent versions of lintian in both unstable
> and testing:
> 
>   $ rmadison lintian | grep 'unstable\|testing'
>   lintian| 2.116.1 | testing| source, all
>   lintian| 2.116.2 | buildd-unstable| source, all
>   lintian| 2.116.2 | unstable   | source, all
> 
> Why is UDD outdated w.r.t. the lintian version?
> Shouldn't UDD be aware of the version currently in testing, or maybe
> even in unstable?
> 
> What's missing?
> Did I fail to understand anything?
> 
> Please make UDD use the latest lintian version from testing or
> unstable, or otherwise clarify my misunderstanding.
> 
> Thanks for your time and dedication!
> Bye.

The update to a newer lintian version on the UDD lintian worker is a
manual process. I'll do that soon, but I have some other Debian stuff
queued up that looks more important.
Any reason in particular you need the latest version?

Lucas

Bug#1030059: pycirkuit: Fails to run autopkgtest test suite

[Hilmar Preusse]

Source: pycirkuit
Version: 0.5.1-1
Severity: important

Dear Maintainer,

Bug submitted as "important" for now, could be RC instead.

A few days ago I uploaded a new TeX Live snapshot. Since
then the test suite of your package fails to run, see [1].

Interestingly I can run the line from the test script without
any issue:

/usr/bin/pycirkuit -t -p -f /usr/share/doc/pycirkuit/examples/*.ckt 
--destination /tmp

When running the test suite like this

"autopkgtest pycirkuit -- schroot unstable-amd64-sbuild"

The test suite fails, although I don't see much output I could use
for debug.

Hilmar

[1] https://qa.debian.org/excuses.php?package=texlive-extra

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1030058: nvme output misquoting

[Antoine Beaupre]

Package: prometheus-node-exporter-collectors
Version: 0.0~git20230110.843e550-1
Severity: normal
Tags: upstream

Since the bookworm upgrade, my logs are full of this:

2023-01-30T15:08:02.764677-05:00 marcos prometheus-node-exporter[3724]: 
ts=2023-01-30T20:08:02.764Z caller=textfile.go:227 level=error 
collector=textfile msg="failed to collect textfile data" file=nvme.prom 
err="failed to parse textfile data from 
\"/var/lib/prometheus/node-exporter/nvme.prom\": text format parsing error in 
line 14: expected float as value, got \"\\\"34564\\\"\""

It looks like a JSON transcoding issue, see also: 
https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/issues/130


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 prometheus-node-exporter-collectors depends on:
ii  moreutils 0.67-1
pn  prometheus-node-exporter  
ii  python3-apt   2.5.2
ii  systemd-sysv  252.4-1

Versions of packages prometheus-node-exporter-collectors recommends:
ii  dbus   1.14.4-1
pn  ipmitool   
ii  jq 1.6-2.1
ii  nvme-cli   2.2.1-4
ii  python33.11.1-1
ii  smartmontools  7.3-1+b1

prometheus-node-exporter-collectors suggests no packages.

Bug#1029214: debian-archive-keyring: bookworm archive signing keys

[Ansgar]

Hi,

On Thu, 2023-01-19 at 18:22 +, Adam D. Barratt wrote:
> We need new archive signing keys for bookworm, so that we can include
> them in the release.

We have in principle a new key prepared. It is now in the frustrating
phase of trying to collect replies from other people that they have
received the recovery share. Or that the share was lost on the way.

I'm not sure how long it will take.

Ansgar

Bug#1029417: gammu: FTBFS in bookworm (undeclared build-dependency on tzdata)

[Santiago Vila]

El 30/1/23 a las 12:36, Boian Bonev escribió:

Before uploading I did purge tzdata from my sbuild chroot and the build
succeeded.


Probably you did a full build, with both arch-dependent packages
and arch-independent packages. In such case sbuild installs all
build-dependencies, the ones in Build-Depends and the ones
in Build-Depends-Indep. That's probably why it worked.

If you already have a clean chroot in which tzdata is not present,
the following two things should both work:

sbuild --arch-all --no-arch-any -d sid gammu
sbuild --arch-any --no-arch-all -d sid gammu

Currently, only the first command works, because tzdata is also
required in the second command but it's only in Build-Depends-Indep.

When adding or removing build-dependencies (this is not really
related to tzdata), it is always a good idea to try those
commands before upload, because we have different autobuilders
for arch-independent packages and for arch-dependent packages
and those two commands are what autobuilders really do.


Please provide some log showing the error.


I believe that with those additional explanations it should not be necessary.
The way sbuild --arch-any --no-arch-all fails on a really clean chroot is 
exactly
what I included in the very first email in this bug report.

About the other things you mention: My summary would be that
this is a bug according to current policy in bookworm
(which I believe we likely will not change just before the release),
and the fact that the bug is not RC just means that the bug
is not so grave that we would want to remove the package if it's not fixed.


While I am always willing to fix low priority stuff, I'd prefer to wait and see
some final resolution before proceeding.


So: It is up to you. I don't plan to NMU or anything like that, but I won't
deny that I will be very happy if we could release bookworm without FTBFS
bugs of any kind (which includes this one), or as few as possible.

Thanks.

Bug#1030057: refpolicy: reproducible builds: tarball embeds user/group/uid/gid of build user

[Vagrant Cascadian]

Source: refpolicy
Version: 2:2.20221101-4
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The source tarball /usr/src/selinux-policy-src.tar.zst embeds the
username, userid, groupname and groupid of the build user:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/refpolicy.html

  
drwxr-xr-x···0·pbuilder1··()·pbuilder1··()0·2023-01-29·04:07:05.00·selinux-policy-src/
  vs.
  
drwxr-xr-x···0·pbuilder2··()·pbuilder2··()0·2023-01-29·04:07:05.00·selinux-policy-src/

The attached patch fixes this by passing arguments to tar in
debian/rules to ensure consistent user, group, uid and gid in the
generated tarball.

Historically, most versions of refpolicy did not have this issue, so
this appears to be a recent regression (possibly triggered by a switch
to "rules-requires-root: no"?):

  https://tests.reproducible-builds.org/debian/history/refpolicy.html

According to my local tests, with this patch applied refpolicy should
become reproducible on tests.reproducible-builds.org!

Thanks for maintaining refpolicy!

live well,
  vagrant
From 7b691da36a702d912cfd647f50cdeed5ca7bd0c6 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 30 Jan 2023 19:49:41 +
Subject: [PATCH] debian/rules: Pass arguments to tar to use a consistent uid
 and gid.

Otherwise the user name, user id, group name and group id are recorded
in selinux-policy-src.tar.zst shipped in the package.

https://reproducible-builds.org/docs/archives/
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 32d70d6..d7feee3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -166,6 +166,6 @@ install-src: conf-src
 	  rm -rf selinux-policy-src/support/__pycache__/; \
 	  find selinux-policy-src -type f -print0 | xargs -0r chmod 0644; \
 	  find selinux-policy-src -type d -print0 | xargs -0r chmod 0755; \
-	  TZ=UTC tar cf - --sort=name --mtime="$(BUILD_DATE)" selinux-policy-src | zstd -9 > $(CURDIR)/debian/tmp/usr/src/selinux-policy-src.tar.zst)
+	  TZ=UTC tar cf - --sort=name --mtime="$(BUILD_DATE)" --owner=0 --group=0 --numeric-owner selinux-policy-src | zstd -9 > $(CURDIR)/debian/tmp/usr/src/selinux-policy-src.tar.zst)
 	rm -rf   $(CURDIR)/debian/tmp/etc/selinux/default/src/
 	touch $@
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1030002: installation-guide: replace http.us.debian.org with deb.debian.org

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Cyril Brulebois, le lun. 30 janv. 2023 04:09:57 +0100, a ecrit:
> Spotted while working on the update for non-free-firmware: the
> installation guide references http.us.debian.org everywhere.

Yes, actually it's an entity that translators turn into a closer mirror.
That said there was a piece of the install-methods chapter that was
using a hardcoded http.us.debian.org, I pushed a fix.

Samuel

Bug#1029602: Bug report: kernel oops in vmw_fb_dirty_flush()

[Zack Rusin]

On Tue, 2023-01-31 at 00:36 +0800, Keyu Tao wrote:
> !! External Email
> 
> Hi vmwgfx maintainers,
> 
> An out-of-bound access in vmwgfx specific framebuffer implementation can
> be easily triggered by fbterm (a framebuffer terminal emulator) when it
> is going to scroll screen.
> 
> With some debugging, it seems that vmw_fb_dirty_flush() cannot handle
> the vinfo.yoffset correctly after calling `ioctl(fbdev_fd,
> FBIOPAN_DISPLAY, );`, and then subsequent access to the mapped
> memory area causes the oops.
> 
> As current mainline vmwgfx implementation (in Linux 6.2-rc) has removed
> this framebuffer implementation, this bug can be triggered only in Linux
> stable. I have tested it with vanilla 6.1.8 and 5.10.165 and they all oops.
> 
> This bug is reported in
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2
> Fcgi-
> bin%2Fbugreport.cgi%3Fbug%3D1029602=05%7C01%7Czackr%40vmware.com%7C63862e731c
> 3b4a97796808db02e03145%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C63810693415592
> 2769%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C2000%7C%7C%7C=uVOtDBAyn%2BDx5w8r1twuKO4Xd0Lma6zCr2ie3lQ%2BRR
> E%3D=0> first, and
> the maintainer there suggests me to report this issue to upstream :)
> 
> Relevant information (for self-compiled Linux 6.1.8):
> 
> - /proc/version: Linux version 6.1.8 (tao@mira) (gcc (Debian 10.2.1-6)
> 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #7 SMP
> PREEMPT_DYNAMIC Mon Jan 30 21:09:02 CST 2023
> 
> - Linux distribution: Debian GNU/Linux 11 (bullseye)
> 
> - Architecture (uname -mi): x86_64 unknown
> 
> - Virtualization software: VMware Fusion 13 Player
> 
> - How to reproduce:
>    1. Install (or compile) fbterm
>    2. Run fbterm under a tty (by a user with read & write permission to
> /dev/fb0, usually users in video group), and try to make it scroll (for
> example by pressing Enter for a few seconds)
>    3. The graphics hang and it oops.
> 

Thanks a lot for the detailed report. Is there any chance that you could try 
any of
the 6.2 rc releases to see if you can reproduce? We removed all of the hand 
rolled
fb code and ported it to drm helpers in change:
df42523c12f8 ("drm/vmwgfx: Port the framebuffer code to drm fb helpers")
which for the first time got into the official kernel in v6.2-rc1 . So any 
kernel
after that shouldn't crash with fbterm, if anyone could verify that'd be much
appreciated.

z

Bug#1029782: Strange Depends entry

[Julian Gilbey]

On Mon, Jan 30, 2023 at 12:16:52PM -0400, Stefano Rivera wrote:
> Hi Julian (2023.01.27_11:10:14_-0400)
> > python3-wrapt | python3 (<< 3.11), python3-wrapt | python3 (>> 3.11).
> > Since python3 will satisfy exactly one of python3 (>> 3.11) and
> > python3 (<< 3.11), this dependency can be simplified to just
> > python3-wrapt.
> 
> FWIW, this comes from:
> dependencies = [
> ...
> "wrapt>=1.14,<2;python_version>='3.11'",
> "wrapt>=1.11,<2;python_version<'3.11'",
> ...
> ]
> 
> But yes, it could be simplified.

Ah, that makes sense; the original dependencies meaningfully depend on
different versions of wrapt depending on the python version.

Best wishes,

   Julian

Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3

[Francesco Poli (wintermute)]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi!

In the [UDD Lintian report] for my package, I read:

[...]
| The most recent lintian version known by UDD is 2.115.3
[...]

[UDD Lintian report]: 

However, there are more recent versions of lintian in both unstable
and testing:

  $ rmadison lintian | grep 'unstable\|testing'
  lintian| 2.116.1 | testing| source, all
  lintian| 2.116.2 | buildd-unstable| source, all
  lintian| 2.116.2 | unstable   | source, all

Why is UDD outdated w.r.t. the lintian version?
Shouldn't UDD be aware of the version currently in testing, or maybe
even in unstable?

What's missing?
Did I fail to understand anything?

Please make UDD use the latest lintian version from testing or
unstable, or otherwise clarify my misunderstanding.

Thanks for your time and dedication!
Bye.

Bug#1030054: kitty: build-time test failures in some environments

[Steve Langasek]

Package: kitty
Followup-For: Bug #1030054
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Control: tags -1 patch

See attached patch.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru kitty-0.26.5/debian/rules kitty-0.26.5/debian/rules
--- kitty-0.26.5/debian/rules   2023-01-04 03:14:15.0 -0800
+++ kitty-0.26.5/debian/rules   2023-01-30 11:29:49.0 -0800
@@ -30,8 +30,8 @@
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
mkdir -p "$(HOME)"
mkdir -p "$(KITTY_RUNTIME_DIRECTORY)"
-   env HOME="$(HOME)" KITTY_RUNTIME_DIRECTORY="$(KITTY_RUNTIME_DIRECTORY)" 
python3 setup.py $(V) build-launcher
-   env HOME="$(HOME)" KITTY_RUNTIME_DIRECTORY="$(KITTY_RUNTIME_DIRECTORY)" 
LC_ALL=C.UTF-8 python3 setup.py $(V) test
+   env HOME="$(HOME)" TERM= 
KITTY_RUNTIME_DIRECTORY="$(KITTY_RUNTIME_DIRECTORY)" python3 setup.py $(V) 
build-launcher
+   env HOME="$(HOME)" TERM= 
KITTY_RUNTIME_DIRECTORY="$(KITTY_RUNTIME_DIRECTORY)" LC_ALL=C.UTF-8 python3 
setup.py $(V) test
 endif
 
 override_dh_auto_install:

Bug#1030055: ITP: python-django-object-actions -- object tools for models in the admin

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-object-actions
  Version : 4.1.0
  Upstream Contact: crccheck 
* URL : https://github.com/crccheck/django-object-actions
* License : Apache2
  Programming Lang: Python
  Description : object tools for models in the admin

 Defining new tool actions is just like defining regular admin actions. The
 major difference is the functions for django-object-actions will take an object
 instance instead of a queryset.
 Tool actions are exposed by putting them in a change_actions attribute in your
 admin.ModelAdmin. You can also add tool actions to the main changelist views
 too. There, you'll get a queryset like a regular admin action.

I intend to maintain this package as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmPYHDgRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpPnwgAonuAn4/qNGmQgbsF0U9Cj44ZamUC7VA0
+AzWPbiPmEhjC+dUh8VGLqQFuOOShsC9hs6U7sV3awqxWN812OSjQvsebzsQI+9y
nz3Ibk3m1wXgdIcjflpjldT9r5OKiu4hmuSAqarIGSn77ajdCWzk7mc1R4Zu1+Yz
o/u8gsnV8eTNw9aLZjScgfkJkFh9nbInEUpkUHL10cJScYV0WDLM9p2BHJfYkpv+
pxhIA7inTqnJhtOyYi7r5gpEX6mskRf5QFwkRZBmSlI/Eh5xy8GsI/8to7rpsSAI
cMw0g77X6WUWlRqUOwRF6n8xe2aoNbJVwgBMybDzV/VWcdSoRWJCVA==
=xWLS
-END PGP SIGNATURE-

Bug#1030054: kitty: build-time test failures in some environments

[Steve Langasek]

Source: kitty
Version: 0.26.5-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar

Hi James,

Since version 0.26.5, kitty has been failing to build from source on Ubuntu
with test failures, even though it builds fine on Debian:

[...]
==
ERROR: test_ssh_shell_integration (kitty_tests.ssh.SSHKitten)
--
Traceback (most recent call last):
  File "/<>/kitty/launcher/../../kitty_tests/ssh.py", line 239, in 
test_ssh_shell_integration
pty.wait_till(lambda: 'kitty=fruity' in pty.screen_contents())
login_shell = 'bash'
num_lines = 2
ok_login_shell = 'bash'
pty = 
self = 
sh = 'dash'
tdir = '/tmp/tmpct5s6c0x'
val = ''
  File "/<>/kitty/launcher/../../kitty_tests/__init__.py", line 
297, in wait_till
raise TimeoutError(f'The condition was not met. Screen contents: \n 
{repr(self.screen_contents())}')
end_time = 1963.133780143
q = . at 
0x7fd0c33475b0>
self = 
TimeoutError: The condition was not met. Screen contents: 
 'UNTAR_DONE\nbuildd@lcy02-amd64-004:~$ echo 
"$TERM=fruity"\nunknown=fruity\nbuildd@lcy02-amd64-004:~$ '

[...]

  (https://launchpad.net/ubuntu/+source/kitty/0.26.5-2/+build/25419959)

It appears this works in Debian but not in Ubuntu because Debian's builders
have an empty $TERM in the build environment, whereas Ubuntu has it set by
default to 'unknown' (as shown above).  But if I build this in either a
Debian or Ubuntu chroot locally, the test fails because of a non-empty TERM
in the environment, causing this test to fail.

Since this only concerns the behavior of a test rather than a problem with
the package's code, it seems the appropriate fix is to set TERM= in the
environment when calling the tests.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability

[Hilmar Preuße]

Control: tags -1 + help

Am 29.01.2023 um 00:00 teilte Frank Heckenbach mit:

Hi,


Classic /tmp write vulnerability: function dir_writable writes to
"/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient
checks.

Harmless demonstration:

% mkfifo /tmp/1
% epspdf /etc/hostname /dev/null  # any non-empty input file will do

hangs indefinitely trying to write to the pipe (as can be seen using
strace).



I sent an E-Mail to upstream, however I don't expect a fast response.
Tagging "help" for know.

Hilmar
--
sigfault

Bug#1030053: rustc: Please add patch to fix FTBFS on sparc64

[John Paul Adrian Glaubitz]

Source: rustc
Version: 1.64.0+dfsg1-1~exp3
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi!

The attached patch is a backport of the commit in [1] which fixes the
rustix (and therefore rustc) FTBFS on sparc64 [2].

Could you apply it for the next rustc upload for version 1.64.x?

Thanks,
Adrian

> [1] 
> https://github.com/bytecodealliance/rustix/commit/85ed94efa3d4ce05ba7edaacc78b37cd8fbf6793
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=rustc=sparc64=1.64.0%2Bdfsg1-1%7Eexp3=1674399404=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/libc/process/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/libc/process/types.rs
@@ -199,7 +199,12 @@ pub enum Signal {
 target_os = "openbsd",
 all(
 any(target_os = "android", target_os = "linux"),
-any(target_arch = "mips", target_arch = "mips64"),
+any(
+target_arch = "mips",
+target_arch = "mips64",
+target_arch = "sparc",
+target_arch = "sparc64"
+),
 )
 )))]
 Stkflt = c::SIGSTKFLT,
@@ -276,7 +281,12 @@ impl Signal {
 target_os = "openbsd",
 all(
 any(target_os = "android", target_os = "linux"),
-any(target_arch = "mips", target_arch = "mips64"),
+any(
+target_arch = "mips",
+target_arch = "mips64",
+target_arch = "sparc",
+target_arch = "sparc64"
+),
 )
 )))]
 c::SIGSTKFLT => Some(Self::Stkflt),
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/libc/termios/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/libc/termios/types.rs
@@ -704,6 +704,8 @@ pub const B200: Speed = c::B200;
 
 /// `B250`
 #[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
 target_os = "dragonfly",
 target_os = "freebsd",
 target_os = "ios",
@@ -715,6 +717,8 @@ pub const B250: Speed = c::B250;
 
 /// `B300`
 #[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
 target_os = "dragonfly",
 target_os = "freebsd",
 target_os = "ios",
@@ -726,6 +730,8 @@ pub const B300: Speed = c::B300;
 
 /// `B350`
 #[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
 target_os = "dragonfly",
 target_os = "freebsd",
 target_os = "ios",
@@ -737,6 +743,8 @@ pub const B350: Speed = c::B350;
 
 /// `B400`
 #[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
 target_os = "dragonfly",
 target_os = "freebsd",
 target_os = "ios",
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/linux_raw/termios/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/linux_raw/termios/types.rs
@@ -338,15 +338,19 @@ pub const B150: Speed = linux_raw_sy
 pub const B200: Speed = linux_raw_sys::general::B200;
 
 /// `B250`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
 pub const B250: Speed = linux_raw_sys::general::B250;
 
 /// `B300`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
 pub const B300: Speed = linux_raw_sys::general::B300;
 
 /// `B350`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
 pub const B350: Speed = linux_raw_sys::general::B350;
 
 /// `B400`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
 pub const B400: Speed = linux_raw_sys::general::B400;
 
 /// `CSIZE`
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/termios/constants.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/termios/constants.rs
@@ -45,6 +45,8 @@ pub use imp::termios::types::B200;
 )))]
 pub use imp::termios::types::B250;
 #[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
 target_os = "dragonfly",
 target_os = "freebsd",
 target_os = "ios",
@@ -54,6 +56,8 @@ pub use imp::termios::types::B250;
 )))]
 pub use imp::termios::types::B300;
 #[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
 target_os = "dragonfly",
 target_os = "freebsd",
 target_os = "ios",
@@ -63,6 +67,8 @@ pub use imp::termios::types::B300;
 )))]
 pub use imp::termios::types::B350;
 #[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
 target_os = "dragonfly",
 target_os = "freebsd",
 target_os = "ios",
@@ -74,6 +80,8 @@ pub use imp::termios::types::B400;
 #[cfg(not(any(target_os = "ios", target_os = "macos", target_os = "openbsd")))]
 pub use imp::termios::types::B460800;
 #[cfg(not(any(
+target_arch = "sparc",
+target_arch 

Bug#1030052: RFS: ffmpegfs/2.13-1~bpo11+1 [ ITP] -- read-only FUSE filesystem which transcodes between audio and video formats on the fly)

[Norbert Schlia]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ffmpegfs":

 * Package name    : ffmpegfs
   Version : 2.13-1~bpo11+1
   Upstream Author : Norbert Schlia 
 * URL : https://nschlia.github.io/ffmpegfs/
 * License : CC0-1.0, GFDL-NIV-1.3 or GPL-3+, GPL-3+
 * Vcs : https://salsa.debian.org/nschlia/ffmpegfs
   Section : utils

The source builds the following binary packages:

  ffmpegfs - Fuse Multi Media Filesystem

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/ffmpegfs/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/ffmpegfs/ffmpegfs_2.13-1~bpo11+1.dsc


Changes since the last upload:

 ffmpegfs (2.13-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.

Bug#1030051: backintime-common: crash on start: python module "packaging" is missing

[Anabelle]

Package: backintime-common
Version: 1.3.3-3
Severity: important
X-Debbugs-Cc: anabellevandenbu...@gmail.com

Dear Maintainer,

backintime fails to launch after installing from aptitude. running `backintime` 
produces the following output:
```
Traceback (most recent call last):
  File "/usr/share/backintime/common/backintime.py", line 28, in 
import config
  File "/usr/share/backintime/common/config.py", line 45, in 
import tools
  File "/usr/share/backintime/common/tools.py", line 37, in 
from packaging.version import Version
ModuleNotFoundError: No module named 'packaging'
```

running `backintime-qt` produces the following output:
```
Traceback (most recent call last):
  File "/usr/share/backintime/qt/app.py", line 35, in 
import qttools
  File "/usr/share/backintime/qt/qttools.py", line 32, in 
from packaging.version import Version
ModuleNotFoundError: No module named 'packaging'
```



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages backintime-common depends on:
ii  cron [cron-daemon]  3.0pl1-156
ii  openssh-client  1:9.1p1-2
ii  python3 3.11.1-1
ii  python3-dbus1.3.2-4
ii  python3-keyring 23.9.3-2
ii  rsync   3.2.7-1

Versions of packages backintime-common recommends:
ii  backintime-qt  1.3.3-3

Versions of packages backintime-common suggests:
pn  encfs   
pn  powermgmt-base  
pn  sshfs   

-- no debconf information

Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1

[Sebastian Andrzej Siewior]

On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote:
> reopen 1028375
> found 1028375 5.4.1-0.0
> thanks
> 
> Patrice Duroux dixit:
> 
> >Was this supposed to be closed? Or will it be with another manpages-fr bpo?
> 
> 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1)
> so the upload did not fix the problem.
> 
> As far as I can tell it must be (<< 4.17.0-1~) instead.
> (Also do note the tilde, it breaks bpo otherwise.)

Okay. So I add this new suggested version and close 1028375?

> bye,
> //mirabilos

Sebastian

Bug#1028489: transition: boost1.81

[Anton Gladky]

Hi Sebastian,

thanks for the information. Let's do it just after release.

Just for the record. The full test rebuild has been done (thanks to Lucas!).
Results and logs are here:

http://qa-logs.debian.net/2023/01/15/

Regards

Anton

Bug#1029566: transition: shibboleth-sp

[Ferenc Wágner]

Sebastian Ramacher  writes:

> ACK, please go ahead.

Great, shibboleth-sp was uploaded and is already fully green in the
transition tracker.  Please schedule the binNMUs for
shibboleth-resolver.
-- 
Thanks,
Feri.

Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1

[Thorsten Glaser]

reopen 1028375
found 1028375 5.4.1-0.0
thanks

Patrice Duroux dixit:

>Was this supposed to be closed? Or will it be with another manpages-fr bpo?

5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1)
so the upload did not fix the problem.

As far as I can tell it must be (<< 4.17.0-1~) instead.
(Also do note the tilde, it breaks bpo otherwise.)

This is not only needed for bpo but also for incremental
updates within sid.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1020641: Repro attempt

[Pásztor János]

Dear Colleagues,

I have done my fair share of tests regarding this, please see my remarks 
below.


Used system:

-8<>8---
root@asgard ~ # more /etc/debian_version
11.6
-8<>8---

dhcpcd & dhcpcd-gtk version

-8<>8---
root@asgard ~ # apt show dhcpcd5
Package: dhcpcd5
Version: 9.4.1-4

root@asgard ~ # apt show dhcpcd-gtk
Package: dhcpcd-gtk
Version: 0.7.8-1
-8<>8---

dhcpcd has been started without the chroot fix, a.k.a. with the current 
debian systemd unit


-8<>8---
root@asgard ~ # systemctl revert dhcpcd.service
Removed "/etc/systemd/system/dhcpcd.service".

root@asgard ~ # systemctl daemon-reload dhcpcd.service

root@asgard ~ # systemctl restart dhcpcd.service
-8<>8---

dhcpcd-gtk has been started from a terminal

-8<>8---
pasja@asgard ~ % dhcpcd-gtk

(dhcpcd-gtk:16980): Gtk-WARNING **: 18:34:48.939: Theme parsing error: 
gtk-widgets.css:1214:18: Not using units is deprecated. Assuming 'px'.

** Message: 18:34:48.956: Connecting ...
** Message: 18:34:48.956: Status changed to down
** Message: 18:34:48.956: Status changed to opened
** Message: 18:34:48.956: Connected to dhcpcd-9.4.1
** Message: 18:34:48.956: Status changed to connected
** Message: 18:34:48.956: eno1: CARRIER
** Message: 18:34:48.956: eno1: Configured 192.168.1.238/24
** Message: 18:34:48.956: eno1: Configured 
2001:4c4e:1e94:::1580:cf90:77bb/64

** Message: 18:34:48.956: eno1: Configured 2001:4c4e:1e94:::/128
-8<>8---

Looks great for me, which means that I was not able to reproduce the 
issue what martintxo reported.


A couple of differences are there, namely:
- Version: 9.4.1-4 vs. 9.4.1-9
- I am using wpa_supplicant differently on this machine (started from an 
interface specific systemd unit vs. starting from a dhcpcd hook)


Based on that I think that my chroot patch from bug #1029437 does not 
matter in this case :(


In order to get a better picture about this it would be great if 
martintxo could:
- having a strace output from dhcpcd-gtk ('strace -ff -y dhcpcd-gtk' in 
a console, be careful this might produce a huge output!) when the issue 
occures so that we can see the connection attemps from dhcpcd-gtk
- pinpoint the exact systemd hardening which causes this problem, a.k.a. 
adding the lines back one-by-one until the issue occures


Besides that when I chased through the linked issues, I have found an 
upstream commit which was linked to this issue 
(https://bugs.gentoo.org/846515#c5) It just missed 9.4.1 and the 
upstream author used the expression 'might be' which does not mean 100% 
resolution for me... Still it might worth a shot to compile a new 
version with that commit and see whether the issue occures or not.


I will try to have a second round of repro, where I reconfigure my 
machine to get closer to martintxo's setup and see what happens.


Regards,
János Pásztor

Bug#997059: intake 0.6.6-1 apparently okay with ipv6

[Étienne Mollier]

Version: 0.6.6-1

Greetings,

After quite a long hiatus, I finally had a look back at intake
failure to build from source on ipv6 only hosts.  I did not
reproduce the issue after configuring my laptop to only run on
ipv6 addressing.  It seems to me the update to version 0.6.6
could have fixed the issue; or it could have been fixed by an
update in a dependency perhaps.

For reference, the interface linked to the Internet was only
having one public and one network local ipv6 addresses, no ipv4
allowed here, but the loopback was still having ipv4 addressing
during the test, as it seemed to be also the case on the buildd
(although I couldn't check for myself):

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever

I'm closing the issue for now, but feel free to reopen if I
didn't configure my machine correctly and symptoms were to come
back.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#1029775: pyhst2: FTBFS with setuptools 66: Invalid version: '2020ca'

[Andreas Beckmann]

On 28/01/2023 18.09, Didier 'OdyX' Raboud wrote:

So. I have a much shorter (and better) patch, that I'll upload to DELAYED/5 in
few minutes.


Thanks alot.

There is now a new lintian error (not caused by your patch,
but by some changed B-D). Since you were looking into
the python building bits, perhaps you have an idea where this
is originating from? Notice the difference lib vs. lib64

in sid:
E: python3-pyhst2-cuda: custom-library-search-path RUNPATH /usr/lib64 
[usr/lib/python3/dist-packages/PyHST2_2020c/libgputomo.cpython-311-x86_64-linux-gnu.so]
E: python3-pyhst2-cuda: custom-library-search-path RUNPATH /usr/lib64 
[usr/lib/python3/dist-packages/PyHST2_2020c/libprojection.cpython-311-x86_64-linux-gnu.so]

in bookworm:
E: python3-pyhst2-cuda: custom-library-search-path RUNPATH /usr/lib 
[usr/lib/python3/dist-packages/PyHST2_2020c/libgputomo.cpython-311-x86_64-linux-gnu.so]
E: python3-pyhst2-cuda: custom-library-search-path RUNPATH /usr/lib 
[usr/lib/python3/dist-packages/PyHST2_2020c/libprojection.cpython-311-x86_64-linux-gnu.so]

I get this also for rebuilding -6 in bookworm,
while it did not happen in my November upload.

The buildlog has
INFO: x86_64-linux-gnu-gcc -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv 
-O2 -Wl,-z,relro -g -O2 -ffile-prefix-map=/build/pyhst2-2020c=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 
build/temp.linux-x86_64-cpython-311/PyHST/Cspace/c_hst_project_1over.o 
-L/usr/lib64 -L/usr/lib/x86_64-linux-gnu -Wl,--enable-new-dtags,-R/usr/lib64 
-lcudart -lcuda -lcufft -o 
/build/pyhst2-2020c/.pybuild/cpython3_3.11_pyhst2/build/PyHST2_2020c/libprojection.cpython-311-x86_64-linux-gnu.so

Andreas

Bug#1030050: rails: CVE-2023-22796 CVE-2023-22795 CVE-2023-22794 CVE-2023-22792 CVE-2022-44566

[Moritz Mühlenhoff]

Source: rails
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for rails.

CVE-2023-22796[0]:
https://discuss.rubyonrails.org/t/cve-2023-22796-possible-redos-based-dos-vulnerability-in-active-supports-underscore/82116
https://github.com/rails/rails/commit/4b383e6936d7a72b5dc839f526c9a9aeb280acae 
(6-1-stable)

CVE-2023-22795[1]:
https://discuss.rubyonrails.org/t/cve-2023-22795-possible-redos-based-dos-vulnerability-in-action-dispatch/82118
https://github.com/rails/rails/commit/484fc9185db6c6a6a49ab458b11f9366da02bab2 
(6-1-stable)

CVE-2023-22794[2]:
https://discuss.rubyonrails.org/t/cve-2023-22794-sql-injection-vulnerability-via-activerecord-comments/82117
https://github.com/rails/rails/commit/048e9fc05e18c91838a44e60175e475de8b2aad5 
(6-1-stable)

CVE-2023-22792[3]:
https://discuss.rubyonrails.org/t/cve-2023-22792-possible-redos-based-dos-vulnerability-in-action-dispatch/82115
https://github.com/rails/rails/commit/7a7f37f146aa977350cf914eba20a95ce371485f 
(6-1-stable)

CVE-2022-44566[4]:
https://discuss.rubyonrails.org/t/cve-2022-44566-possible-denial-of-service-vulnerability-in-activerecords-postgresql-adapter/82119
https://github.com/rails/rails/commit/414eb337d142a9c61d7723ceb9b7c1ab30dff3ed 
(6-1-stable)


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-22796
https://www.cve.org/CVERecord?id=CVE-2023-22796
[1] https://security-tracker.debian.org/tracker/CVE-2023-22795
https://www.cve.org/CVERecord?id=CVE-2023-22795
[2] https://security-tracker.debian.org/tracker/CVE-2023-22794
https://www.cve.org/CVERecord?id=CVE-2023-22794
[3] https://security-tracker.debian.org/tracker/CVE-2023-22792
https://www.cve.org/CVERecord?id=CVE-2023-22792
[4] https://security-tracker.debian.org/tracker/CVE-2022-44566
https://www.cve.org/CVERecord?id=CVE-2022-44566

Please adjust the affected versions in the BTS as needed.

Bug#1030048: pgpool2: CVE-2023-22332

[Moritz Mühlenhoff]

Source: pgpool2
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for pgpool2.

CVE-2023-22332[0]:
| Information disclosure vulnerability exists in Pgpool-II 4.4.0 to
| 4.4.1 (4.4 series), 4.3.0 to 4.3.4 (4.3 series), 4.2.0 to 4.2.11 (4.2
| series), 4.1.0 to 4.1.14 (4.1 series), 4.0.0 to 4.0.21 (4.0 series),
| All versions of 3.7 series, All versions of 3.6 series, All versions
| of 3.5 series, All versions of 3.4 series, and All versions of 3.3
| series. A specific database user's authentication information may be
| obtained by another database user. As a result, the information stored
| in the database may be altered and/or database may be suspended by a
| remote attacker who successfully logged in the product with the
| obtained credentials.

Quoting from https://www.pgpool.net/mediawiki/index.php/Main_Page#News :

(I have no idea how common that is, feel free to downgrade as necessary)

--
This release contains a security fix.

If following conditions are all met, the password of "wd_lifecheck_user" is 
exposed by "SHOW POOL STATUS" command. The command can be executed by any user 
who can
connect to Pgpool-II. (CVE-2023-22332)

• Version 3.3 or later
• use_watchdog = on
• wd_lifecheck_method = 'query'
• A plain text password is set to wd_lifecheck_password
--

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-22332
https://www.cve.org/CVERecord?id=CVE-2023-22332

Please adjust the affected versions in the BTS as needed.

Bug#1030049: opusfile: CVE-2022-47021

[Moritz Mühlenhoff]

Source: opusfile
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for opusfile.

CVE-2022-47021[0]:
| A null pointer dereference issue was discovered in functions
| op_get_data and op_open1 in opusfile.c in xiph opusfile 0.9 thru 0.12
| allows attackers to cause denial of service or other unspecified
| impacts.

https://github.com/xiph/opusfile/commit/0a4cd796df5b030cb866f3f4a5e41a4b92caddf5
https://github.com/xiph/opusfile/issues/36

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-47021
https://www.cve.org/CVERecord?id=CVE-2022-47021

Please adjust the affected versions in the BTS as needed.