Bug#1041516: RM: kalgebra kalgebra-common [mipsel] -- ROM; qtwebengine-opensource-src FTBFS on mipsel

[Pino Toscano]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: kalge...@packages.debian.org
Control: affects -1 + src:kalgebra
Control: block 1041268 by -1

Hi,

please remove the kalgebra & kalgebra-common binary packages on mipsel:
they used to be built because qtwebengine-opensource-src is available on
mipsel. Since qtwebengine-opensource-src FTBFSes on mipsel, and it is
scheduled for removal on architecture, please remove the cruft binaries.

Please note that src:kalgebra still builds a kalgebramobile binary
package on mipsel (like in all the architectures without QtWebEngine).

Thanks,
-- 
Pino

Bug#1041515: RM: kalendar [mipsel] -- ROM; qtwebengine-opensource-src FTBFS on mipsel

[Pino Toscano]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: kalen...@packages.debian.org
Control: affects -1 + src:kalendar
Control: block 1041268 by -1

Hi,

please remove kalendar from mipsel: it uses qtwebengine-opensource-src,
which currently FTBFS on mipsel, and thus kalendar was excluded from
building on mipsel.

Thanks,
-- 
Pino

Bug#1041514: sway 1.7.X fails to build, need adjustment on sway/ipc-json.c.

[ahmadraniri]

Package: sway
Version: 1.7-6
Severity: normal
X-Debbugs-Cc: lidgnuli...@gmail.com

Dear Maintainer,

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

   * What led up to the situation? Sway's source code need to be adjusted 
(sway/ipc-json.c) because by default it won't be able to be built.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I edited the sway/ipc-json.c so sway can be built without 
error.
   * What was the outcome of this action? sway can be built.
   * What outcome did you expect instead? sway can be built.

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


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

Kernel: Linux 6.4.0-rc6 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sway depends on:
ii  libc62.37-6
ii  libcairo21.16.0-7
ii  libevdev21.13.1+dfsg-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgl1-mesa-dri  23.1.3-1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.76.4-2
ii  libinput10   1.23.0-2
ii  libjson-c5   0.16-2
ii  libpango-1.0-0   1.50.14+ds-1
ii  libpangocairo-1.0-0  1.50.14+ds-1
ii  libpcre2-8-0 10.42-2
ii  libpixman-1-00.42.2-1
ii  libsystemd0  254~rc2-3
ii  libudev1 254~rc2-3
ii  libwayland-client0   1.22.0-1
ii  libwayland-cursor0   1.22.0-1
ii  libwayland-server0   1.22.0-1
ii  libwlroots10 0.15.1-6
ii  libxcb1  1.15-1
ii  libxkbcommon01.5.0-1
ii  polkitd  122-4
ii  swaybg   1.2.0-1

Versions of packages sway recommends:
ii  foot  1.15.0-1
ii  suckless-tools47-1
ii  sway-backgrounds  1.8.1-1

Versions of packages sway suggests:
ii  swayidle1.8.0-1
ii  swaylock1.7.2-1
ii  xdg-desktop-portal-wlr  0.7.0-1

-- debconf-show failed

Bug#1041513: linux-image-6.* doesn't shut down properly

[MinimumAttic410]

Source: linux
Severity: important
X-Debbugs-Cc: minimumat...@disroot.org

Dear Maintainer,

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

I have two old ThinkPad T60, one with ATI and other one is with Intel 
chipset (i945). 
Both machines have Debian 12 (bookworm) installed freshly (not 
upgraded).
But with Intel chipset model of T60, system doesnt poweroff properly 
that display turns off but fan keeps spinning.
I don't have this problem with my other T60 with ATI chipset. Just 
Intel model T60 is doing this problem.
I tested several old kernel versions with advice of fellows from 
#debian channel from snapshot.debian, seems all linux-image-6.* versions 
causing this issue.
Latest kernel version which shuts down my Intel model T60 is 
"linux-image-5.19.0-2-amd64-unsigned_5.19.11-1_amd64.deb".
I didn't face this issue with Debian 10 and 11 before. Just having 
issue with Debian 12.
Is it possible to fix this issue for Kernel 6.* and bring for further 
versions?

Thanks in advance.

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


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

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

Bug#1037686: hdrmerge: ftbfs with GCC-13

[Gianfranco Costamagna]

control: tags -1 patch pending

Uploaded the one line patch

diff -Nru hdrmerge-0.5+git20200117/debian/changelog 
hdrmerge-0.5+git20200117/debian/changelog
--- hdrmerge-0.5+git20200117/debian/changelog   2023-07-07 22:22:08.0 
+0200
+++ hdrmerge-0.5+git20200117/debian/changelog   2023-07-16 21:12:40.0 
+0200
@@ -1,3 +1,12 @@
+hdrmerge (0.5+git20200117-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/221.patch:
+- cherry-pick upstream proposed patch to fix gcc-13 build failure (Closes:
+  #1037686)
+
+ -- Gianfranco Costamagna   Sun, 16 Jul 2023 
21:12:40 +0200
+
 hdrmerge (0.5+git20200117-3) unstable; urgency=medium
 
   * Team upload.

diff -Nru hdrmerge-0.5+git20200117/debian/patches/221.patch 
hdrmerge-0.5+git20200117/debian/patches/221.patch
--- hdrmerge-0.5+git20200117/debian/patches/221.patch   1970-01-01 
01:00:00.0 +0100
+++ hdrmerge-0.5+git20200117/debian/patches/221.patch   2023-07-16 
21:12:40.0 +0200
@@ -0,0 +1,21 @@
+From 7a799d5c3adee9865f9956be51ec9d4955a087b7 Mon Sep 17 00:00:00 2001
+From: jdeluyck <5451787+jdelu...@users.noreply.github.com>
+Date: Thu, 29 Jun 2023 13:53:55 +0200
+Subject: [PATCH] fix compilation by including cstdlib
+
+---
+ src/TiffDirectory.hpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/TiffDirectory.hpp b/src/TiffDirectory.hpp
+index de989a4..dd9668d 100644
+--- a/src/TiffDirectory.hpp
 b/src/TiffDirectory.hpp
+@@ -22,6 +22,7 @@
+
+ #include 
+ #include 
++#include 
+
+ #ifndef _TIFFDIRECTORY_HPP_
+ #define _TIFFDIRECTORY_HPP_
diff -Nru hdrmerge-0.5+git20200117/debian/patches/series 
hdrmerge-0.5+git20200117/debian/patches/series
--- hdrmerge-0.5+git20200117/debian/patches/series  2023-07-07 
22:22:08.0 +0200
+++ hdrmerge-0.5+git20200117/debian/patches/series  2023-07-16 
21:12:40.0 +0200
@@ -1 +1,2 @@
 0001-Fix-LibRaw-0.21-API-change.patch
+221.patch


On Wed, 14 Jun 2023 09:25:26 + Matthias Klose  wrote:

Package: src:hdrmerge
Version: 0.5+git20200117-2
Severity: normal
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-13

[This bug is targeted to the upcoming trixie release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
severity of this report will be raised before the trixie release.

The full build log can be found at:
http://qa-logs.debian.net/2023/05/22/logs/hdrmerge_0.5+git20200117-2_unstable_gccexp.log
The last lines of the build log are at the end of this report.

To build with GCC 13, either set CC=gcc-13 CXX=g++-13 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++ 


Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-13/porting_to.html

[...]
   57 | void IFD::write(uint8_t * buffer, size_t & pos, bool hasNext) {
  |  ^
/<>/src/TiffDirectory.cpp:57:44: error: ‘pos’ was not declared in 
this scope
   57 | void IFD::write(uint8_t * buffer, size_t & pos, bool hasNext) {
  |^~~
/<>/src/TiffDirectory.cpp:57:49: error: expected 
primary-expression before ‘bool’
   57 | void IFD::write(uint8_t * buffer, size_t & pos, bool hasNext) {
  | ^~~~
/<>/src/TiffDirectory.cpp: In member function ‘size_t 
hdrmerge::IFD::length() const’:
/<>/src/TiffDirectory.cpp:77:46: error: request for member ‘size’ in 
‘((const hdrmerge::IFD*)this)->hdrmerge::IFD::entryData’, which is of non-class type ‘const 
int’
   77 | return 6 + 12*entries.size() + entryData.size();
  |  ^~~~
/<>/src/TiffDirectory.cpp: At global scope:
/<>/src/TiffDirectory.cpp:81:17: error: ‘hdrmerge::IFD::DirEntry* 
hdrmerge::IFD::getEntry’ is not a static data member of ‘class hdrmerge::IFD’
   81 | IFD::DirEntry * IFD::getEntry(uint16_t tag) {
  | ^~~
/<>/src/TiffDirectory.cpp:81:31: error: ‘uint16_t’ was not 
declared in this scope
   81 | IFD::DirEntry * IFD::getEntry(uint16_t tag) {
  |   ^~~~
/<>/src/TiffDirectory.cpp:81:31: note: ‘uint16_t’ is defined in header 
‘’; did you forget to ‘#include ’?
make[3]: *** [CMakeFiles/hdrmerge.dir/build.make:216: 
CMakeFiles/hdrmerge.dir/src/TiffDirectory.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from 

Bug#1041485: RFS: spades/3.15.5+dfsg-2.1 [NMU] [RC] -- genome assembler for single-cell and isolates data sets

[Bo YU]

X-Debbugs-Cc: debian-...@lists.debian.org

hi!

On Thu, Jul 20, 2023 at 2:27 AM Étienne Mollier  wrote:
>
> X-Debbugs-Cc: debian-...@lists.debian.org
>
> Hi Bo YU,
>
> Bo YU, on 2023-07-19:
> > I am looking for a sponsor for my package "spades":
> […]
> > Changes since the last upload:
> >
> >  spades (3.15.5+dfsg-2.1) unstable; urgency=medium
> >  .
> >* Non-maintainer upload.
>
> If you happen to go by the Salsa login vimerbf-guest, then you
> should have direct access to push directly to the team
> maintained repository.  Don't hesitate to work there, and ping
> the debian-med[1] list once you are happy with your changes and
> they are ready for "Team upload.".  ;)
>
Yeah, it is me. I just got access at yesterday so I am not sure I can
follow the workflow of Debian med team. But now I can try after your
confirmation.:)
> >* Fix ftbfs on gcc-13. (Closes: #1037863)
>
> Thanks for your help fixing that bug, and also for the forward
> upstream.  My only matter for head scratching is the following
> hunk in your patch:
>
> --- a/assembler/ext/src/llvm/Signals.inc
> +++ b/assembler/ext/src/llvm/Signals.inc
> @@ -43,6 +43,7 @@
>  #include "llvm/Support/Program.h"
>  #include "llvm/Support/SaveAndRestore.h"
>  #include "llvm/Support/raw_ostream.h"
> +#include "llvm/Support/Signals.h"
>  #include 
>  #include 
>  #include 
>
> Including cstdint would have probably been less intrusive, and
> solves the build failure as far as I could test.  Was there a
> specific reason to include the whole llvm/Support/Signals.h
> instead of just cstdint?
>
Okay, I rebuild the package again without the change, it works.
I recalled the background, maybe it messed up due to previous
error I ignored. In fact, maybe I overlooked the log:
```
[ 46%] Building CXX object ext/llvm/CMakeFiles/llvm-support.dir/StringMap.cpp.o
In file included from /<>/assembler/ext/src/llvm/Signals.cpp:219:
/<>/assembler/ext/src/llvm/Signals.inc:347:50: error:
'void llvm::sys::CleanupOnSignal(uintptr_t)' should have been declared
inside 'llvm::sys'
  347 | void llvm::sys::CleanupOnSignal(uintptr_t Context) {
```

I will clean up the change for here and upstream.

> Note the file is copied from llvm source code, so I suspect that
> whatever the right change is, it may have a non negligible
> contribution in resolving #1037760 affecting llvm-toolchain-15.
>
> > BTW, the package maybe only need to build target like x64.
>
> I guess you are referring to #976523.  In case a package were to
> drop dependency amd64 specific flags and become architecture
> indepent, then this would be automatically caught by the build
> daemons network.  That being said, in the specific case of
> spades, the package looks to already be exluded by the buildd
> network[2]; if that is the case, reintroducing non-amd64
> architectures will require a couple of manual steps anyway.
>
Oh, thanks you told me the background so today I learned many here.

I think it is okay i push the update to the salsa repo directly as
your suggestion.

Thanks again!

BR,
Bo

> [1]: mailto:debian-...@lists.debian.org
> [2]: https://buildd.debian.org/status/package.php?p=spades
>
> Have a nice day,  :)
> --
>   .''`.  Étienne Mollier 
>  : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
>  `. `'   sent from /dev/pts/1, please excuse my verbosity
>`-on air: The Flower Kings - Garden Of Dreams (Part B Ed…

Bug#1041512: Unable to parse icon type 'ic12' 'ic07' 'ic13' 'ic14'

[肖盛文]

Package: icnsutils
Version: 0.8.1-3.1
Severity: normal
Tags: upstream
X-Debbugs-Cc: atzli...@sina.com

Hi,
There are many icon type Unable to parse.

icns2png -x pyUI/resources/logo.icns -o debian/

Reading icns family from pyUI/resources/logo.icns...
 Extracting icons from /logo.icns...
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic12'
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic07'
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic13'
  Saved 'ic08' element to debian/logo_256x256x32.png.
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic04'
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic14'
  Saved 'ic09' element to debian/logo_512x512x32.png.
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic05'
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic11'
libicns: icns_get_image_info_for_type: Unable to parse icon type 'info'
Extracted 2 images from /logo.icns.

When I use the newest upstream code:
https://git.code.sf.net/p/icns/code

it can parse these icon type, I can get the png files.

Would release a new package in Debian?



-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.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 icnsutils depends on:
ii  libc62.36-9
ii  libicns1 0.8.1-3.1
ii  libpng16-16  1.6.39-2

icnsutils recommends no packages.

icnsutils suggests no packages.

-- no debconf information

Bug#1041511: ntfs-3g: Undocumented dependency on libbrotli-dev

[Theodoric Stier]

Source: ntfs-3g
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: kerd...@gmail.com

Dear Maintainer,

This package build fails during the configure step if libbrotli-dev is not 
installed.
It appears to be missing from BuildDep.

I'm gonna try to use reportbug to attach a build log.

Thanks,
Ted Stier

-- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
 dpkg-buildpackage -us -uc -ui -aamd64 -sa
dpkg-buildpackage: info: source package ntfs-3g
dpkg-buildpackage: info: source version 1:2022.10.3-2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Theodoric Stier 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building ntfs-3g using existing 
./ntfs-3g_2022.10.3.orig.tar.gz
dpkg-source: info: building ntfs-3g in ntfs-3g_2022.10.3-2.debian.tar.xz
dpkg-source: info: building ntfs-3g in ntfs-3g_2022.10.3-2.dsc
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Remember to add 'LT_INIT' to configure.ac.
configure.ac:189: warning: The macro `AC_GNU_SOURCE' is obsolete.
configure.ac:189: You should run autoupdate.
./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from...
configure.ac:189: the top level
configure.ac:475: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:475: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:475: the top level
configure.ac:189: installing './compile'
configure.ac:32: installing './config.guess'
configure.ac:32: installing './config.sub'
configure.ac:36: installing './install-sh'
configure.ac:36: installing './missing'
Makefile.am: installing './INSTALL'
libfuse-lite/Makefile.am: installing './depcomp'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/home/ted/deb/pkg/ntfs-3g/ntfs-3g-2022.10.3'
dh_auto_configure -- --exec-prefix=/ --enable-crypto \
--enable-extras --enable-xattr-mappings \
--enable-quarantined --disable-ldconfig \
--enable-mount-helper --with-fuse=internal \
--enable-posix-acls
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --exec-prefix=/ 
--enable-crypto --enable-extras --enable-xattr-mappings --enable-quarantined 
--disable-ldconfig --enable-mount-helper --with-fuse=internal 
--enable-posix-acls
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for wchar.h... yes
checking for minix/config.h... no
checking for 

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Vagrant Cascadian]

On 2023-07-19, Aurelien Jarno wrote:
> I have just picked /build/reproducible-path which is very unlikely to
> appear in a build log. After a few days of test on zani.d.o, I have
> implemented it globally through puppet with the following commit:
>
> commit aed04290e21c4185bb6a2fb3186bfe4cb862198d
> Author: Aurelien Jarno 
> Date:   Wed Jul 19 23:01:12 2023 +0200
>
> sbuild: use predictible build paths (closes: #1034424)

Very most highly excellent news! Thanks! :)

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1041432: box64: unsatisfiable dependencies

[Adrian Bunk]

On Tue, Jul 18, 2023 at 10:55:53PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
>...
> $ apt-cache show crossbuild-essential-mips64el  | grep Depends:
> Depends: gcc-mips64el-linux-gnuabi64 (>= 4:10.2) | gcc:mips64el, 
> g++-mips64el-linux-gnuabi64 (>= 4:10.2) | g++:mips64el, dpkg-cross
> 
> But other packages use the same thing. Why does it work there?

An alternative dependency might be in non-free or might not exist at all.

Package: box64
Architecture: amd64 arm64 ppc64el riscv64
Depends:
 libgcc-s1:amd64,
 libstdc++6:amd64,

A package must not assume that the user has other architectures enabled.

There is a general issue around such dependencies, and also the more 
specific problem that permitting cross-architecture dependencies would
also require checking that migrating a package for one architecture does
not break dependencies on other architectures.

For box64, using libgcc-s1-amd64-cross and libstdc++6-amd64-cross might 
be an option (untested).

cu
Adrian

Bug#1038981: scaling_cur_freq ≰ scaling_max_freq

[Al Ma]

found 1038981 linux-image-6.1.0-10-amd64/6.1.37-1
found 1038981 linux/6.1.0-10
thanks
The same problem exists after the recent kernel upgrade to 
linux-image-6.1.0-10-amd64 version 6.1.37-1.
$ uname -r
6.1.0-10-amd64
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
40
40
40
40
40
40
40
40
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
400016
399983
400012
48
400015
35
400016
230
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
40
40
40
40
40
40
40
40
As we see, the value 230 is too high! I'd expect around 40. As the fun 
is running, the reported elevated values (here, 2.4 GHz) are probably real.
Gratefully,
AlMa

Bug#1040629: Additional information

[Vladimir Petko]

The original failure could be due to the network issue, as the tests
attempt to access the internet.

Bug#1041509: ITP: gitui -- blazing fast terminal-ui for git

[Johann Felix Soden]

Package: wnpp
Severity: wishlist
Owner: Johann Felix Soden 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name : gitui
  Version : 0.23.0
  Upstream Contact: extrawurst 
* URL : https://github.com/extrawurst/gitui
* License : MIT
  Programming Lang: Rust
  Description : blazing fast terminal-ui for git

gitui is a blazing fast terminal-ui for git with following features:
  - Fast and intuitive keyboard only control
  - Context based help (no need to memorize tons of hot-keys)
  - Inspect, commit, and amend changes
  - Stage, unstage, revert and reset files, hunks and lines
  - Stashing (save, pop, apply, drop, and inspect)
  - Push/Fetch to/from remote
  - Branch List (create, rename, delete, checkout, remotes)
  - Browse commit log, diff committed changes
  - Scalable terminal UI layout
  - Async git API for fluid control
  - Submodule support

Bug#1041497: vmm: fails to run with python3 >= 3.10

[Bernd Zeimetz]

19.07.2023 21:36:39 Bastian Germann :

>> uploading a broken 0.1 version and keeping the maintainer who actually
>> orphaned the package intact is probably not the best way, I would
>> suggest that you either adopt the package or at least set the QA Group
>> as maintainer.
> 
> Can you please reference the orphaning bug report?
> I cannot find one and that is why the upload was a NMU and not a QA upload.

Oh well sorry, seems there was no otphaning bug, I was sure there was one.
Probably because I once said that I might take over the maintenance of the 
package. That's why I actually started to prepare it, but didn't find the time 
to finish it. If necessary I can look through my email archives, but if you 
want to maintain it, nobody will have anything against it.

Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs

[Faidon Liambotis]

On Wed, Jul 19, 2023 at 06:41:54PM +0200, Jonas Smedegaard wrote:
> > > This is a pseudo-ITP: The source package is already maintained for the
> > > subset covering core Cranelift crates, since they are part of same
> > > monorepo. The intent tracked here is extending that source package to
> > > provide binary packages librust-wasmtime* which involves additional
> > > dependencies unneeded for Cranelift.
> > 
> > I'm not sure what you mean by that -- what is already maintained? 
> 
> Whoops, I had it in mind but evidently forgot to mention it: I mean the
> packaging effort tracked as ITP bug#1041434 (and now in NEW queue).

Ah! It makes sense now, thanks :)

> > Also, are you planning to package wasmtime, as in the CLI, itself? I
> > believe this exists on the same upstream/source tree as the language
> > bindings that you're proposing here?
> 
> I mean both the Rust crates and the command-line tool.
> 
> You are right, both are part of same monorepo.

Awesome!

> > > Please shout if there is need for wasmtime, and especially if there is
> > > interest in helping get the needed dependencies packaged.
> > 
> > I don't have the bandwidth to help packaging wasmtime. However, I do
> > maintain another popular WebAssembly runtime, WasmEdge, and last year I
> > contributed a few changes to the Debian LLVM packages
> > (src:llvm-project-14 and friends) with regards to WebAssembly support,
> > and so you could say I'm interested with helping in bringing more parts
> > of the WebAssembly ecosystem in Debian :) I'm also interested in
> > opportunities to help each other, and in the relevant packages working
> > well with each other and/or providing a unified experience. Let me know
> > if you can think of any such ways.
> 
> I don't have a special interest in WebAssembly (yet) - my packaging
> efforts here is targeted packaging of swt (bug#991761).  That work also
> involves packaging (again only a subset of crates initially for) wasmer.

Wasmer too? That's even better :)

Good luck!

Faidon

Bug#1041488: Please review patches for initial upload

[Elias Oltmanns]

Sorry for all those emails, but I have just realised that
debian/README.source needed fixing. The reason is that I started out
with the test suite disabled but have managed to get it running after
all.

So, I have added another patch to the previous two and will append all
three to this message.

Cheers,

Elias


Am 19. Juli 2023 um 23:16 schrieb Elias Oltmanns:
> Package: wnpp
> Followup-For: Bug #1041488
> X-Debbugs-Cc: oltma...@zib.de
> Control: tags -1 patch
> 
> Please have a look at the following patches. They might be suitable as
> an initial seed for a salsa repository for the new package. Please apply
> and simply pull in the upstream sources by means of uscan.
> 
> Thank you in advance for any support you can provide.
> 
> Cheers,
> 
> Elias
> 
> 
> 
>From d7ccbe9e1bdbdb0eb25a61b33953e6d68c7e78cb Mon Sep 17 00:00:00 2001
From: Elias Oltmanns 
Date: Wed, 19 Jul 2023 19:39:57 +0200
Subject: [PATCH 1/3] Initial commit

Closes: #1041488
---
 debian/README.source | 13 +
 debian/control   | 33 +
 debian/copyright | 29 +
 debian/libjwat-java.poms | 35 +++
 debian/maven.ignoreRules | 14 ++
 debian/maven.rules   | 10 ++
 debian/rules |  4 
 debian/source/format |  1 +
 debian/watch |  2 ++
 9 files changed, 141 insertions(+)
 create mode 100644 debian/README.source
 create mode 100644 debian/control
 create mode 100644 debian/copyright
 create mode 100644 debian/libjwat-java.poms
 create mode 100644 debian/maven.ignoreRules
 create mode 100644 debian/maven.rules
 create mode 100755 debian/rules
 create mode 100644 debian/source/format
 create mode 100644 debian/watch

diff --git a/debian/README.source b/debian/README.source
new file mode 100644
index 000..d6f8170
--- /dev/null
+++ b/debian/README.source
@@ -0,0 +1,13 @@
+Information about libjwat-java
+--
+
+This package was debianized using the mh_make command
+from the maven-debian-helper package.
+
+The build system uses Maven but prevents it from downloading
+anything from the Internet, making the build compliant with
+the Debian policy.
+
+Running the test suite at build time has been disabled in
+debian/maven.properties. This is due to dependencies that have not
+been packaged for Debian.
diff --git a/debian/control b/debian/control
new file mode 100644
index 000..50828a5
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,33 @@
+Source: libjwat-java
+Section: java
+Priority: optional
+Maintainer: Debian Java Maintainers 
+Build-Depends:
+ debhelper-compat (= 13),
+ default-jdk,
+ maven-debian-helper (>= 2.1),
+ junit4 (>= 4.13.2),
+Build-Depends-Indep:
+ libbcprov-java (>= 1.65),
+ libdoxia-java (>= 1.7),
+ libmaven-compiler-plugin-java (>= 3.10.1),
+ libmaven-javadoc-plugin-java (>= 3.4.1),
+ libmaven-site-plugin-java (>= 3.12.1),
+ libsurefire-java (>= 2.22.3),
+ libhamcrest-java,
+ libmockito-java,
+ libpowermock-java
+Standards-Version: 4.6.2
+Homepage: https://sbforge.org/display/JWAT/JWAT
+Rules-Requires-Root: no
+
+Package: libjwat-java
+Architecture: all
+Depends: ${misc:Depends}, ${maven:Depends}
+Suggests: ${maven:OptionalDepends}
+Multi-Arch: foreign
+Description: Java Web Archive Toolkit
+ A collection of libraries to use for reading, writing and validating ARC,
+ WARC and GZip files. Also includes various helper classes to help with
+ different types of input streams. Finally there are also classes to help
+ with HTTP, character encoding and other Internet related protocols.
diff --git a/debian/copyright b/debian/copyright
new file mode 100644
index 000..9fa40f9
--- /dev/null
+++ b/debian/copyright
@@ -0,0 +1,29 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: Java Web Archive Toolkit
+Upstream-Contact: https://sbforge.org/display/JWAT/JWAT
+Source: https://github.com/netarchivesuite/jwat
+
+Files: *
+Copyright:
+ 2011-2023, Det Kongelige Bibliotek/Royal Danish Library (https://www.kb.dk/)
+License: Apache-2.0
+
+Files: debian/*
+Copyright: 2023, Zuse Institute Berlin (https://ewig.zib.de/)
+License: Apache-2.0
+
+License: Apache-2.0
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+ .
+ http://www.apache.org/licenses/LICENSE-2.0
+ .
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ .
+ On Debian systems, the full text of the Apache-2.0 license
+ can be found in the file '/usr/share/common-licenses/Apache-2.0'
diff --git a/debian/libjwat-java.poms b/debian/libjwat-java.poms
new file mode 

Bug#1036884: 64-bit time_t: an update

[Steve Langasek]

Hi folks,

Two months ago, I posted with a proposal for how to handle a transition to
64-bit time_t on 32-bit archs in the trixie cycle.

  https://lists.debian.org/debian-devel/2023/05/msg00168.html

We have pretty good consensus on the path forward; however, at the time I
posted I had hoped to have an archive analysis done within a month, so that
this could be staged as the first major transition after trixie opened. 
This timeline proved to be very optimistic.

The problem is that, to understand the impact that a change to the size of
time_t will have on a library's ABI, it must be possible to compile the
headers that expose that API; and we have a significant number of -dev
packages in the archive that for one reason or another don't
straightforwardly compile out of the box.

The Ubuntu Foundations team have been putting in effort over the past two
months, package-by-package, to figure out how to make them compile so that
we know if their ABI is affected.  However, despite a significant investment
of effort, we still have roughly 1500 -dev packages still in need of
analysis, and have sustained a rate of processing only around 50 -dev
packages a week.

The "good" news is that, although there are over 1500 -dev packages yet to
be analyzed, we have prioritized libraries based on the number of
reverse-dependencies and therefore these 1500 -dev packages have among them
less than 300 reverse-build-dependencies that have not already been
identified as part of the transition (800 of these -dev packages have no
reverse-build-dependencies at all).

Therefore, I would like to propose the following.

- Assume the remaining 1500 -dev packages are affected by the ABI breakage.
  This will increase the number of library packages included in the
  transition requiring sourceful uploads from < 500 to 2000[1], but will
  only increase the number of packages requiring rebuilds from 5300 to 5600.

- Agree a target window together with the Release Team for when the
  transition will be uploaded to unstable; and based on this, set a deadline
  beforehand for finalizing the list of library packages whose binary
  package names will be changed.

- We in Ubuntu Foundations will continue on a best effort basis to drive
  down the list of -dev packages which cannot be analyzed, until that
  deadline.

- Any party (maintainer or otherwise) interested in having some of these
  library packages excluded from the transition is welcome to contribute
  fixes up to that deadline that will let us analyze them and show that the
  ABI has not changed.

Your thoughts?

-- 
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

[1] All numbers approximate: the analysis that has been completed so far has
been done against Ubuntu lunar as a stable reference base.  The Debian
transition will of course be done based on a complete analysis of unstable,
which is in progress separately.
libgnome-rr-4-dev
libhfsp-dev
libhx-dev
libibnetdisc-dev
libip6tc-dev
libipmiconsole-dev
libipset-dev
libisns-dev
libisoburn-dev
libixion-dev
libjpeg-turbo8-dev
libklibc-dev
libkrad-dev
libksba-dev
liblasso3-dev
libldacbt-abr-dev
libldb-dev
liblouisutdml-dev
liblrm2-dev
libmaa-dev
libmircommon-dev
libmiroil-dev
libmirplatform-dev
libmirwayland-dev
libmlir-14-dev
libmozjs-102-dev
libmutter-11-dev
libnetplan-dev
libntirpc-dev
libnutscan-dev
liborcus-dev
libotf-dev
libpils2-dev
libportal-dev
libpskc-dev
libptexenc-dev
libpython3.10-dev
libpython3.11-dev
libradosstriper-dev
libreoffice-dev
libsource-highlight-dev
libsss-certmap-dev
libsss-simpleifp-dev
libstdc++-11-dev
libstdc++-12-dev
libstonith1-dev
libsysmetrics-dev
libtotem-dev
libunwind-14-dev
libunwind-15-dev
libusbredirhost-dev
libuwac0-dev
libverto-dev
libvolume-key-dev
libwhoopsie-dev
libwhoopsie-preferences-dev
lua-rrd-dev
python3-ldb-dev
python3-talloc-dev
rhythmbox-dev
ruby3.0-dev
ruby3.1-dev
samba-dev
slapi-dev
libblimps3-dev
libfishcamp-dev
libopenvr-dev
libparmetis-dev
libtestu01-0-dev
libttspico-dev
389-ds-base-dev
android-libandroidfw-dev
android-libselinux-dev
android-libsepol-dev
android-libunwind-dev
angelscript-dev
atfs-dev
cairo-dock-dev
casacore-dev
cauchy-dev
codeblocks-dev
coinor-libbonmin-dev
coinor-libcbc-dev
libfprint-2-tod-dev
dovecot-dev
irssi-dev
isc-dhcp-dev
libaal-dev
libapache2-mod-perl2-dev
bind9-dev
libcanberra-gtk-common-dev
libclc-14-dev
libclc-15-dev
libd3dadapter9-mesa-dev
libdpkg-dev
libfreeradius-dev
libglvnd-core-dev
libmirrenderer-dev
libpinyin-common-dev
libpolly-15-dev
libradospp-dev
libreiser4-dev
libreofficekit-dev
libubi-dev
mir-renderer-gl-dev
ocfs2-tools-dev
php8.1-dev
rados-objclass-dev
remmina-dev
zsh-dev
libamgcl-dev
libjulius-dev
libthrust-dev
notion-dev
ableton-link-dev
android-libbase-dev
android-libcutils-dev

Bug#1041488: Please review patches for initial upload

[Elias Oltmanns]

Package: wnpp
Followup-For: Bug #1041488
X-Debbugs-Cc: oltma...@zib.de
Control: tags -1 patch

Please have a look at the following patches. They might be suitable as
an initial seed for a salsa repository for the new package. Please apply
and simply pull in the upstream sources by means of uscan.

Thank you in advance for any support you can provide.

Cheers,

Elias
>From d7ccbe9e1bdbdb0eb25a61b33953e6d68c7e78cb Mon Sep 17 00:00:00 2001
From: Elias Oltmanns 
Date: Wed, 19 Jul 2023 19:39:57 +0200
Subject: [PATCH 1/2] Initial commit

Closes: #1041488
---
 debian/README.source | 13 +
 debian/control   | 33 +
 debian/copyright | 29 +
 debian/libjwat-java.poms | 35 +++
 debian/maven.ignoreRules | 14 ++
 debian/maven.rules   | 10 ++
 debian/rules |  4 
 debian/source/format |  1 +
 debian/watch |  2 ++
 9 files changed, 141 insertions(+)
 create mode 100644 debian/README.source
 create mode 100644 debian/control
 create mode 100644 debian/copyright
 create mode 100644 debian/libjwat-java.poms
 create mode 100644 debian/maven.ignoreRules
 create mode 100644 debian/maven.rules
 create mode 100755 debian/rules
 create mode 100644 debian/source/format
 create mode 100644 debian/watch

diff --git a/debian/README.source b/debian/README.source
new file mode 100644
index 000..d6f8170
--- /dev/null
+++ b/debian/README.source
@@ -0,0 +1,13 @@
+Information about libjwat-java
+--
+
+This package was debianized using the mh_make command
+from the maven-debian-helper package.
+
+The build system uses Maven but prevents it from downloading
+anything from the Internet, making the build compliant with
+the Debian policy.
+
+Running the test suite at build time has been disabled in
+debian/maven.properties. This is due to dependencies that have not
+been packaged for Debian.
diff --git a/debian/control b/debian/control
new file mode 100644
index 000..50828a5
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,33 @@
+Source: libjwat-java
+Section: java
+Priority: optional
+Maintainer: Debian Java Maintainers 
+Build-Depends:
+ debhelper-compat (= 13),
+ default-jdk,
+ maven-debian-helper (>= 2.1),
+ junit4 (>= 4.13.2),
+Build-Depends-Indep:
+ libbcprov-java (>= 1.65),
+ libdoxia-java (>= 1.7),
+ libmaven-compiler-plugin-java (>= 3.10.1),
+ libmaven-javadoc-plugin-java (>= 3.4.1),
+ libmaven-site-plugin-java (>= 3.12.1),
+ libsurefire-java (>= 2.22.3),
+ libhamcrest-java,
+ libmockito-java,
+ libpowermock-java
+Standards-Version: 4.6.2
+Homepage: https://sbforge.org/display/JWAT/JWAT
+Rules-Requires-Root: no
+
+Package: libjwat-java
+Architecture: all
+Depends: ${misc:Depends}, ${maven:Depends}
+Suggests: ${maven:OptionalDepends}
+Multi-Arch: foreign
+Description: Java Web Archive Toolkit
+ A collection of libraries to use for reading, writing and validating ARC,
+ WARC and GZip files. Also includes various helper classes to help with
+ different types of input streams. Finally there are also classes to help
+ with HTTP, character encoding and other Internet related protocols.
diff --git a/debian/copyright b/debian/copyright
new file mode 100644
index 000..9fa40f9
--- /dev/null
+++ b/debian/copyright
@@ -0,0 +1,29 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: Java Web Archive Toolkit
+Upstream-Contact: https://sbforge.org/display/JWAT/JWAT
+Source: https://github.com/netarchivesuite/jwat
+
+Files: *
+Copyright:
+ 2011-2023, Det Kongelige Bibliotek/Royal Danish Library (https://www.kb.dk/)
+License: Apache-2.0
+
+Files: debian/*
+Copyright: 2023, Zuse Institute Berlin (https://ewig.zib.de/)
+License: Apache-2.0
+
+License: Apache-2.0
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+ .
+ http://www.apache.org/licenses/LICENSE-2.0
+ .
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ .
+ On Debian systems, the full text of the Apache-2.0 license
+ can be found in the file '/usr/share/common-licenses/Apache-2.0'
diff --git a/debian/libjwat-java.poms b/debian/libjwat-java.poms
new file mode 100644
index 000..671e512
--- /dev/null
+++ b/debian/libjwat-java.poms
@@ -0,0 +1,35 @@
+# List of POM files for the package
+# Format of this file is:
+#  [option]*
+# where option can be:
+#   --ignore: ignore this POM and its artifact if any
+#   --ignore-pom: don't install the POM. To use on POM files that are created
+# temporarily for certain artifacts such as Javadoc jars. [mh_install, 

Bug#1041160: linux-image-6.3.0-2-amd64: no pairing with 6.3.0.1 possible

[Dietmar Czekay]

I checked different versions. Here are the results:

beginning right after clicking "add device" until the device manager 
says "not able to pair"


Just Debian 6.1.37-1 works.

#1 SMP PREEMPT_DYNAMIC Debian 6.3.11-1 (2023-07-01)

Jul 19 14:47:09 debian plasmashell[1465]: QString::arg: 2 argument(s) 
missing in org.kde.bluedevilwizard
Jul 19 14:47:09 debian systemd[1257]: Started 
app-org.kde.bluedevilwizard-0310c206d6344b88b616bbf2127308a1.scope - 
Bluetooth-Gerät hinzufügen - Bluetooth-Gerät hinzufügen.
Jul 19 14:47:11 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state

Jul 19 14:47:13 debian wpa_supplicant[855]: wlp3s0: CTRL-EVENT-BEACON-LOSS
Jul 19 14:47:13 debian kernel: rtw_8821ce :03:00.0: failed to send 
h2c command

Jul 19 14:47:14 debian wpa_supplicant[855]: wlp3s0: CTRL-EVENT-BEACON-LOSS
Jul 19 14:47:15 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:17 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:17 debian kernel: rtw_8821ce :03:00.0: failed to send 
h2c command
Jul 19 14:47:19 debian kernel: rtw_8821ce :03:00.0: coex request 
time out
Jul 19 14:47:19 debian systemd[1257]: Reached target bluetooth.target - 
Bluetooth.
Jul 19 14:47:19 debian kernel: Bluetooth: hci0: unexpected event for 
opcode 0xfc19
Jul 19 14:47:19 debian kernel: Bluetooth: hci0: unexpected event for 
opcode 0x2016
Jul 19 14:47:19 debian kernel: rtw_8821ce :03:00.0: failed to send 
h2c command
Jul 19 14:47:19 debian kernel: rtw_8821ce :03:00.0: coex request 
time out
Jul 19 14:47:19 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:20 debian kernel: Bluetooth: hci0: unexpected cc 0x0c7c 
length: 1 < 3
Jul 19 14:47:20 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x06 from d1:cf:2f:cf:76:25
Jul 19 14:47:20 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x07 from d1:cf:2f:cf:76:25
Jul 19 14:47:20 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x08 from d1:cf:2f:cf:76:25
Jul 19 14:47:20 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x09 from d1:cf:2f:cf:76:25
Jul 19 14:47:21 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:23 debian wpa_supplicant[855]: wlp3s0: 
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-90 noise= txrate=19500
Jul 19 14:47:23 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:23 debian bluetoothd[794]: src/service.c:service_accept() 
input-hog profile accept failed for D1:CF:2F:CF:76:25
Jul 19 14:47:32 debian wpa_supplicant[855]: wlp3s0: 
CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-66 noise= txrate=19500
Jul 19 14:47:35 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:39 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:41 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:43 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 19 14:47:43 debian plasmashell[2082]: kf.bluezqt: PendingCall Error: 
"Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy 
blocked the reply, the reply timeout expired, or the network connection 
was broken."
Jul 19 14:47:45 debian bluetoothd[794]: 
src/device.c:set_wake_allowed_complete() Set device flags return status: 
Invalid Parameters



#1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1 (2023-06-12)

Jul 19 14:44:32 debian kernel: Bluetooth: hci0: unexpected event for 
opcode 0xfc19
Jul 19 14:44:32 debian kernel: Bluetooth: hci0: unexpected event for 
opcode 0x2016
Jul 19 14:44:32 debian systemd[1246]: Reached target bluetooth.target - 
Bluetooth.
Jul 19 14:44:33 debian kernel: Bluetooth: hci0: unexpected cc 0x0c7c 
length: 1 < 3
Jul 19 14:44:33 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x06 from d1:cf:2f:cf:76:24
Jul 19 14:44:33 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x07 from d1:cf:2f:cf:76:24
Jul 19 14:44:33 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x08 from d1:cf:2f:cf:76:24
Jul 19 14:44:33 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x09 from d1:cf:2f:cf:76:24

Jul 19 14:44:34 debian systemd[1]: pcscd.service: Deactivated successfully.
Jul 19 14:44:37 debian bluetoothd[798]: src/service.c:service_accept() 
input-hog profile accept failed for D1:CF:2F:CF:76:24
Jul 19 14:44:58 debian plasmashell[2075]: kf.bluezqt: PendingCall Error: 
"Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy 
blocked the reply, the reply timeout expired, or the network connection 
was broken."
Jul 19 14:45:00 debian bluetoothd[798]: 
src/device.c:set_wake_allowed_complete() Set device flags return status: 
Invalid Parameters
Jul 19 14:45:00 debian org_kde_powerdevil[1477]: 

Bug#1039990: [Pkg-javascript-devel] Bug#1039990: nodejs: CVE-2023-30581 CVE-2023-30588 CVE-2023-30589 CVE-2023-30590

[Jérémy Lal]

Le mer. 19 juil. 2023 à 14:18, Moritz Mühlenhoff  a écrit :

> Am Fri, Jun 30, 2023 at 08:12:37PM +0200 schrieb Jérémy Lal:
> > Hi,
> >
> > Le ven. 30 juin 2023 à 19:21, Salvatore Bonaccorso  a
> > écrit :
> >
> > > Source: nodejs
> > > Version: 18.13.0+dfsg1-1
> > > Severity: important
> > > Tags: security upstream
> > > X-Debbugs-Cc: car...@debian.org, Debian Security Team <
> > > t...@security.debian.org>
> > >
> > > Hi,
> > >
> > > The following vulnerabilities were published for nodejs.
> > >
> > > CVE-2023-30581[0], CVE-2023-30588[1], CVE-2023-30589[2] and
> > > CVE-2023-30590[3].
> > >
> > >
> > > If you fix the vulnerabilities please also make sure to include the
> > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> > >
> >
> > It would be interesting to know if we adopt the same plan we had with
> > security team:
> > full upstream updates in the same branch, 18.x here.
>
> Ack, let's do that. Could you prepare bookworm-security updates
> based on 18.17.0 (after it has landed in unstable)?
>

Will do.

Jérémy

Bug#1041454: naev: FTBFS on i386

[Sebastian Ramacher]

Control: reassign -1 meson/1.2.0-1
Control: forcemerge 1041499 -1
Control: affects -1 src:naev

On 2023-07-19 09:32:25 +0200, Sebastian Ramacher wrote:
> Source: naev
> Version: 0.8.2-1
> Severity: serious
> Tags: ftbfs sid trixie
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> https://buildd.debian.org/status/fetch.php?pkg=naev=mips64el=0.8.2-1%2Bb2=1689629171=0
> 
> Configuring config.h using configuration
> Has header "windows.h" : NO 
> Library dl found: YES
> Configuring naev.sh using configuration
> 
> ../test/glcheck/meson.build:4:15: ERROR: Can not run test applications in 
> this cross environment.

That's #1041499 in meson.

Cheers
-- 
Sebastian Ramacher

Bug#1041503: kernel: usb: port power management may be unreliable

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1
During boot the warning “kernel: usb: port power management may be unreliable” 
is printed yellow into the journal (see the attachment). I tried to plug in and 
unplug a mouse into all USB-A ports and an iPhone into all USB-C ports of the 
laptop and the docking station; each time I observed the output in the journal 
and found nothing power-related (see tried_empty_ports.log). A bunch of error 
messages occurred when I unplugged and plugged in the docking station itself. 
The first time I did this, I saw
upowerd[1000]: energy 52,50 bigger than full 52,02
in the journal. However, the second time I did this, the message has not 
reappeared (see tried_unplugging_and_plugging_in_the_docking_station.log).
My wish would be that for the computer at hand (laptop Lenovo ThinkPad T14s 
Gen1, connected to a docking station ThinkPad Thunderbolt 3 Dock Gen 
2/Workstation Dock Gen 2 Type 40 AN (which is powered by a 135 W AC Adapter 
ADL135NCC3A) and to a monitor Philips 275B1 via a HMDI cable), the kernel would 
be able to manage power reliably (and if it happens already now, the warning 
should be considered bogus and should not appear).
Gratefully,
AlMa
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: Run /init as init process
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel:   with arguments:
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: /init
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel:   with environment:
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: HOME=/
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: TERM=linux
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: 
BOOT_IMAGE=/boot/vmlinuz-6.1.0-10-amd64
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: input: Sleep Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input2
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: button: Sleep Button 
[SLPB]
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: input: Lid Switch as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input3
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: button: Lid Switch 
[LID]
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: button: Power Button 
[PWRF]
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: tsc: Refined TSC 
clocksource calibration: 2303.998 MHz
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: clocksource: tsc: mask: 
0x max_cycles: 0x2135f5e6f15, max_idle_ns: 440795231538 ns
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: clocksource: Switched to 
clocksource tsc
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: pps_core: LinuxPPS API 
ver. 1 registered
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: pps_core: Software ver. 
5.3.6 - Copyright 2005-2007 Rodolfo Giometti 
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: battery: Slot [BAT0] 
(battery present)
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: bus type 
drm_connector registered
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: bus type USB 
registered
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: usbcore: registered new 
interface driver usbfs
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: usbcore: registered new 
interface driver hub
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: usbcore: registered new 
device driver usb
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: bus type thunderbolt 
registered
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: thunderbolt :05:00.0: 
enabling device ( -> 0002)
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: i801_smbus :00:1f.4: 
SPD Write Disable is set
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: i801_smbus :00:1f.4: 
SMBus using PCI interrupt
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: i2c i2c-0: 2/2 memory 
slots populated (from DMI)
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: PTP clock support 
registered
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: sdhci: Secure Digital Host 
Controller Interface driver
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: sdhci: Copyright(c) Pierre 
Ossman
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: e1000e: Intel(R) PRO/1000 
Network Driver
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: e1000e: Copyright(c) 1999 
- 2015 Intel Corporation.
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: e1000e :00:1f.6: 
Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: xhci_hcd :00:14.0: 
xHCI Host Controller
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: xhci_hcd :00:14.0: new 
USB bus registered, assigned bus number 1
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: xhci_hcd :00:14.0: hcc 
params 

Bug#1041502: grub-efi-amd64-bin: update-grub removes UEFI-firmware boot option though 30_uefi-firmware is present

[Sebastien Nguyen]

Package: grub-efi-amd64-bin
Version: 2.06-13
Severity: important
X-Debbugs-Cc: snguyens...@gmail.com

Dear Maintainer,

I am not sure if this bug is already fixed by a newer version than 2.06-13 but 
it does not seems to be reported (though a similar one exists) at the moment. 
Plus I am running debian-stable and have no intention to move to testing or 
unstable, so I hope for a backport or security patch.

The problem is the following:

After installing a large amount of apt packages I realized that my menu entry 
for UEFI-firmware disappeared from grub boot menu though 30_uefi-firmware is 
still present.
update-grub will not resolve the problem.
If the entry is added by editing /boot/grub/grub.cfg the next time update-grub 
is executed the menu entry is removed.
30_uefi-firmware seems to be ok and contains:
#! /bin/sh
set -e

# grub-mkconfig helper script.
# Copyright (C) 2020  Free Software Foundation, Inc.
#
# GRUB is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# GRUB is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GRUB.  If not, see .

prefix="/usr"
exec_prefix="/usr"
datarootdir="/usr/share"

export TEXTDOMAIN=grub
export TEXTDOMAINDIR="${datarootdir}/locale"

. "$pkgdatadir/grub-mkconfig_lib"

EFI_VARS_DIR=/sys/firmware/efi/efivars
EFI_GLOBAL_VARIABLE=8be4df61-93ca-11d2-aa0d-00e098032b8c
OS_INDICATIONS="$EFI_VARS_DIR/OsIndicationsSupported-$EFI_GLOBAL_VARIABLE"

if [ -e "$OS_INDICATIONS" ] && \
   [ "$(( $(printf 0x%x \'"$(cat $OS_INDICATIONS | cut -b5)"\') & 1 ))" = 1 ]; 
then
  LABEL="UEFI Firmware Settings"

  gettext_printf "Adding boot menu entry for UEFI Firmware Settings ...\n" >&2

  cat << EOF
menuentry '$LABEL' \$menuentry_id_option 'uefi-firmware' {
fwsetup
}
EOF
fi

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/nvme0n1p2 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/nvme0n1p3 /var ext4 rw,relatime 0 0
/dev/nvme0n1p5 /tmp ext4 rw,relatime 0 0
/dev/nvme0n1p6 /home ext4 rw,relatime 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root ed1f3d9e-2055-465f-90ae-72696f2ea04a
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=fr_FR
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-ed1f3d9e-2055-465f-90ae-72696f2ea04a' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod 

Bug#1041497: Aw: Bug#1041497: vmm: fails to run with python3 >= 3.10

[Bastian Germann]

> uploading a broken 0.1 version and keeping the maintainer who actually
> orphaned the package intact is probably not the best way, I would
> suggest that you either adopt the package or at least set the QA Group
> as maintainer.

Can you please reference the orphaning bug report?
I cannot find one and that is why the upload was a NMU and not a QA upload.

Bug#1041501: cil: Use of uninitialized value in string eq

[Étienne Mollier]

Package: cil
Version: 0.07.00-12
Severity: normal
Tags: upstream patch

Dear Maintainer,

When querying tasks which are under my responsibility, I notice
on filtering with --is-mine that I have one warning per instance
of task which is not mine:

$ cil summary

===
3f8260ce   New  not mine ter
51954acd   New  mine bis
5e3df180   New  mine
72f2511e   New  not mine bis
93f983e6   New  not mine

===

$ cil summary --is-mine
Use of uninitialized value in string eq at 
/usr/share/perl5/CIL/Utils.pm line 464.
Use of uninitialized value in string eq at 
/usr/share/perl5/CIL/Utils.pm line 464.
Use of uninitialized value in string eq at 
/usr/share/perl5/CIL/Utils.pm line 464.

===
51954acd   New  mine bis
5e3df180   New  mine

===

This is not a blocker per se, just a mere annoyance.  I tracked
this warning down an $email_address which may or may not be
defined depending on whether the field has been set.  I tried a
couple of changes based on `if defined $var`, but none of those
approaches led to a working situation.  If I apply the following
patch, in which I ensure the $email_address is always set, even
if this is the empty string, then I can resolve the noise, and I
have not seen any adverse effect so far:

---8<--8<--8<--8<---
--- cil-0.07.00.orig/lib/CIL/Utils.pm
+++ cil-0.07.00/lib/CIL/Utils.pm
@@ -565,7 +565,7 @@
 sub extract_email_address {
 my ($class, $text) = @_;
 
-my $email_address;
+my $email_address = "";
 my $num_found = find_emails(
 $text,
 sub {
---8<--8<--8<--8<---

Same command as before, but this time with the patch applied:

$ cil summary --is-mine

===
51954acd   New  mine bis
5e3df180   New  mine

===

Thanks for considering this change if you deem it useful!  I was
hoping to feed the fix directly upstream, but it seems their
repository[1] is archived for a while.

[1]: https://github.com/chilts/cil

Have a nice day,  :)
Étienne.

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

Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 cil depends on:
ii  dpkg1.21.22
ii  libclass-accessor-perl  0.51-2
ii  libdatetime-perl2:1.59-1
ii  libemail-date-perl  1.104-4
ii  libemail-find-perl  0.10-dfsg-4
ii  libemail-simple-perl2.218-1
ii  libfile-homedir-perl1.006-2
ii  libfile-slurp-perl  .32-2
ii  libfile-touch-perl  0.12-2
ii  perl [libdigest-perl]   5.36.0-7

cil recommends no packages.

cil suggests no packages.

-- no debconf information

-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-on air: Transatlantic - All Of The Above


signature.asc
Description: PGP signature

Bug#1041500: amd64 installation images cannot install a signed 32-bit UEFI boot loader

[Pascal Hambourg]

Package: debian-cd
Version: 20230607

Dear maintainer,

Installation ISO images for amd64 can boot on 32-bit EFI with secure 
boot enabled but only install an unsigned 32-bit EFI boot loader so the 
installed system will be unbootable with secure boot enabled.


Causes:
- grub-efi-ia32-signed:amd64 and shim-helpers-i386-signed:amd64 do not exist
- grub-efi-ia32-bin:amd64 does not recommend grub-efi-ia32-signed
- shim-signed:amd64 and shim-unsigned:amd64 provide only files for 
64-bit EFI

Bug#1041499: meson: glib2.0 FTBFS on mips64el: "native build" but then "Can not run test applications in this cross environment"

[Simon McVittie]

Package: meson
Version: 1.2.0-1
Severity: serious
Tags: ftbfs
Justification: causing FTBFS regression in another package
X-Debbugs-Cc: glib...@packages.debian.org
Control: affects -1 + src:glib2.0

glib2.0's meson.build has several calls to 'cc.run(...)' guarded by
a check for 'cc_can_run = meson.can_run_host_binaries()'.

On mips64el, Meson seems confused about whether this is a native or
cross build. At first, it correctly reports that this is a native build:


> The Meson build system
> Version: 1.2.0
> Source dir: /<>
> Build dir: /<>/debian/build/deb
> Build type: native build
> Project name: glib
> Project version: 2.76.4

but then later, cc.run() fails:

> ../../../meson.build:1127:14: ERROR: Can not run test applications in this 
> cross environment.

(Line 1127 is the first call to cc.run().)

With a minimal reproducer:

project('foo', 'c')
if meson.can_run_host_binaries()
meson.get_compiler('c').run('whatever')
endif

I can run `meson setup _build` successfully on amd64, or on the mips64el
porterbox eller in a trixie_mips64el-dchroot session with meson 1.1.1-2,
but not on eller in a sid_mips64el-dchroot session with meson 1.2.0-1.

I attach meson-log.txt from the minimal reproducer failing in
sid_mips64el-dchroot. It correctly reports

> Is cross compiler: False.

and

> Build machine cpu family: mips64
> Build machine cpu: mips64
> Host machine cpu family: mips64
> Host machine cpu: mips64
> Target machine cpu family: mips64
> Target machine cpu: mips64

as I would expect.

Thanks,
smcv
Build started at 2023-07-19T19:02:54.288530
Main binary: /usr/bin/python3
Build Options: 
Python system: Linux
The Meson build system
Version: 1.2.0
Source dir: /home/smcv
Build dir: /home/smcv/_build
Build type: native build
Project name: foo
Project version: undefined
---
Detecting compiler via: `cc --version` -> 0
stdout:
cc (Debian 13.1.0-7) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
Running command: cc -E -dM -
-
---
Detecting linker via: `cc -Wl,--version` -> 0
stdout:
GNU ld (GNU Binutils for Debian) 2.40.90.20230714
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
---
stderr:
collect2 version 13.1.0
/usr/bin/ld -plugin 
/usr/libexec/gcc/mips64el-linux-gnuabi64/13/liblto_plugin.so 
-plugin-opt=/usr/libexec/gcc/mips64el-linux-gnuabi64/13/lto-wrapper 
-plugin-opt=-fresolution=/tmp/cc9MBOmq.res -plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc 
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id 
--eh-frame-hdr -EL -mips64r2 --as-needed -dynamic-linker /lib64/ld.so.1 
-melf64ltsmip -pie 
/usr/lib/gcc/mips64el-linux-gnuabi64/13/../../../mips64el-linux-gnuabi64/Scrt1.o
 
/usr/lib/gcc/mips64el-linux-gnuabi64/13/../../../mips64el-linux-gnuabi64/crti.o 
/usr/lib/gcc/mips64el-linux-gnuabi64/13/crtbeginS.o 
-L/usr/lib/gcc/mips64el-linux-gnuabi64/13 
-L/usr/lib/gcc/mips64el-linux-gnuabi64/13/../../../mips64el-linux-gnuabi64 
-L/usr/lib/gcc/mips64el-linux-gnuabi64/13/../../../../lib 
-L/lib/mips64el-linux-gnuabi64 -L/lib/../lib -L/usr/lib/mips64el-linux-gnuabi64 
-L/usr/lib/../lib -L/usr/lib/gcc/mips64el-linux-gnuabi64/13/../../.. --version 
-lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state 
--as-needed -lgcc_s --pop-state 
/usr/lib/gcc/mips64el-linux-gnuabi64/13/crtendS.o 
/usr/lib/gcc/mips64el-linux-gnuabi64/13/../../../mips64el-linux-gnuabi64/crtn.o
---
Sanity testing C compiler: ccache cc
Is cross compiler: False.
Sanity check compiler command line: ccache cc sanitycheckc.c -o 
sanitycheckc.exe -D_FILE_OFFSET_BITS=64
Sanity check compile stdout:

-
Sanity check compile stderr:

-
Running test binary command:  /home/smcv/_build/meson-private/sanitycheckc.exe
C compiler for the host machine: ccache cc (gcc 13.1.0 "cc (Debian 13.1.0-7) 
13.1.0")
C linker for the host machine: cc ld.bfd 2.40.90.20230714
---
Detecting linker via: `gcc-ar --version` -> 0
stdout:
GNU ar (GNU Binutils for Debian) 2.40.90.20230714
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
---
---
Detecting compiler via: `cc --version` -> 0
stdout:
cc (Debian 13.1.0-7) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for 

Bug#1041340: RM: libreoffice [mipsel] -- ROM; broken

[Rene Engelhard]

retitle 1041340 RM: libreoffice [mipsel mips64el] -- ROM; broken
thanks

Hi,

Am Mon, Jul 17, 2023 at 07:38:42PM +0200 schrieb Rene Engelhard:
> please remove libreoffice from mipsel.

and mips64el

[ same stuff applies for mips64el ]

> Rationale:
> 
> mipsel is completely broken, long story at [1].
> Upstream who added it (RedHat) confirmed no interest to do anything on
> it.

mips64el is not as broken as mipsel. But extensions are broken. Too bad
we *do* have various extensions in the archive.

See the extension subthread in 
https://lists.debian.org/debian-mips/2023/07/threads.html

As said in https://lists.debian.org/debian-mips/2023/07/msg00020.html I *could* 
disable the
extension mechanism and disable Java and python to get the  needed packages NBS 
but that would
be bad, imho - where would you stop?

Regards,
 
Rene

Bug#1041498: bookworm-pu: package testng7/7.5-2~deb12u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: test...@packages.debian.org, d...@debian.org, 
vladimir.pe...@canonical.com
Control: affects -1 + src:testng7

We need to introduce a backport of testng7 in the version found in trixie
to bookworm (and TBD, also for bullseye).

It's needed for the latest versions of openjdk-17 LTS (as part of the
test suite).

The debdiff below is against the version of testng7 in trixie
(since the package is new in bookworm).

Cheers,
Moritz

diff -Nru testng7-7.5/debian/changelog testng7-7.5/debian/changelog
--- testng7-7.5/debian/changelog2023-06-15 20:21:39.0 +0200
+++ testng7-7.5/debian/changelog2023-07-19 21:03:12.0 +0200
@@ -1,3 +1,9 @@
+testng7 (7.5-2~deb12u1) bookworm; urgency=medium
+
+  * Build for Bookworm, needed by latest OpenJDK 17 LTS releases
+
+ -- Moritz Mühlenhoff   Wed, 19 Jul 2023 21:03:12 +0200
+
 testng7 (7.5-2) unstable; urgency=medium
 
   * Source-only upload.

Bug#1041485: RFS: spades/3.15.5+dfsg-2.1 [NMU] [RC] -- genome assembler for single-cell and isolates data sets

[Étienne Mollier]

X-Debbugs-Cc: debian-...@lists.debian.org

Hi Bo YU,

Bo YU, on 2023-07-19:
> I am looking for a sponsor for my package "spades":
[…]
> Changes since the last upload:
> 
>  spades (3.15.5+dfsg-2.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.

If you happen to go by the Salsa login vimerbf-guest, then you
should have direct access to push directly to the team
maintained repository.  Don't hesitate to work there, and ping
the debian-med[1] list once you are happy with your changes and
they are ready for "Team upload.".  ;)

>* Fix ftbfs on gcc-13. (Closes: #1037863)

Thanks for your help fixing that bug, and also for the forward
upstream.  My only matter for head scratching is the following
hunk in your patch:

--- a/assembler/ext/src/llvm/Signals.inc
+++ b/assembler/ext/src/llvm/Signals.inc
@@ -43,6 +43,7 @@
 #include "llvm/Support/Program.h"
 #include "llvm/Support/SaveAndRestore.h"
 #include "llvm/Support/raw_ostream.h"
+#include "llvm/Support/Signals.h"
 #include 
 #include 
 #include 

Including cstdint would have probably been less intrusive, and
solves the build failure as far as I could test.  Was there a
specific reason to include the whole llvm/Support/Signals.h
instead of just cstdint?

Note the file is copied from llvm source code, so I suspect that
whatever the right change is, it may have a non negligible
contribution in resolving #1037760 affecting llvm-toolchain-15.

> BTW, the package maybe only need to build target like x64.

I guess you are referring to #976523.  In case a package were to
drop dependency amd64 specific flags and become architecture
indepent, then this would be automatically caught by the build
daemons network.  That being said, in the specific case of
spades, the package looks to already be exluded by the buildd
network[2]; if that is the case, reintroducing non-amd64
architectures will require a couple of manual steps anyway.

[1]: mailto:debian-...@lists.debian.org
[2]: https://buildd.debian.org/status/package.php?p=spades

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-on air: The Flower Kings - Garden Of Dreams (Part B Ed…


signature.asc
Description: PGP signature

Bug#1037040: util-linux: Please coordinate upload of 2.39 with manpages-l10n

[Helge Kreutzmann]

Hello Chris,
On Wed, Jul 19, 2023 at 06:20:44PM +0200, Chris Hofstaedtler wrote:
> * Helge Kreutzmann  [230718 18:21]:
> > On Fri, Jun 02, 2023 at 03:33:33PM +0200, Helge Kreutzmann wrote:
> > > once bookworm is released, I assume that you intend to package the latest
> > > version, i.e. 2.39.
> > > 
> > > This version comes with translated man pages, which were (up to
> > > now) shipped by manpages-l10n.
> > > 
> > > To allow a smooth transition, both packages need to declare
> > > appropriate package relations:
> > > https://wiki.debian.org/PackageTransition
> > > 
> > > So please let me know about the upload and the relevant version
> > > (probably 2.39.0-1?).
> > > 
> > > Until I hear something from your side, manpages-l10n will continue
> > > shipping the translated man pages.
> > 
> > The most convenient time for me would be around the end of August,
> > when manpages-l10n releases the next version. Then I could deal with
> > this quite nicely. Do you think this is a sensible date for you as
> > well?
> 
> If you don't plan to upload manpages-l10n until then, I would complete the
> util-linux side relatively soon.

Technically I can upload anytime. Preferably at the weekend. So if you
tell me when you perform the upload, I can follow suite (but maybe
the Saturday/Sunday after you).

The only reason I mentioned end of august was that you did not reply
to my e-mail until now and I saw that you worked on/released another
2.38 version and I usually simply upload each new upstream.

I'll check your list on Friday/Saturday and provide you feedback.

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#1041497: vmm: fails to run with python3 >= 3.10

[Bernd Zeimetz]

Package: vmm
Version: 0.7.0-0.1
Severity: grave
X-Debbugs-Cc: b...@debian.org

Hi Bastian,

uploading a broken 0.1 version and keeping the maintainer who actually
orphaned the package intact is probably not the best way, I would
suggest that you either adopt the package or at least set the QA Group
as maintainer.

# vmm ld
Traceback (most recent call last):
  File "/usr/sbin/vmm", line 18, in 
sys.exit(run(sys.argv))
 ^
  File "/usr/lib/python3/dist-packages/VirtualMailManager/cli/main.py", line 
43, in run
handler = _get_handler()
  ^^
  File "/usr/lib/python3/dist-packages/VirtualMailManager/cli/main.py", line 
27, in _get_handler
handler = CliHandler()
  
  File "/usr/lib/python3/dist-packages/VirtualMailManager/cli/handler.py", line 
44, in __init__
super(CliHandler, self).__init__(skip_some_checks)
  File "/usr/lib/python3/dist-packages/VirtualMailManager/handler.py", line 87, 
in __init__
self._cfg = Cfg(self._cfg_fname)

  File "/usr/lib/python3/dist-packages/VirtualMailManager/config.py", line 292, 
in __init__
LazyConfig.__init__(self)
  File "/usr/lib/python3/dist-packages/VirtualMailManager/config.py", line 73, 
in __init__
'optionname': LazyConfigOption(int, 1, self.getint),
  ^
  File "/usr/lib/python3/dist-packages/VirtualMailManager/config.py", line 251, 
in __init__
if not isinstance(getter, collections.Callable):
  
AttributeError: module 'collections' has no attribute 'Callable'


collections.Callable is collections.abs.Callable since Python 3.10 



Cheers,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1041494: diffpdf: changes in a single digit in zoom don't take immediate effect

[Al Ma]

In my recollection of Debian 11, even changing a single digit in the Zoom field 
led to an immediate redraw, i.e., even before pressing ⏎.  So the current 
situation is double worse.
As of how it _should_ be, I think that whenever a keyboard is attached, only 
hitting [Enter] or moving the cursor (or, perhaps, the focus) elsewhere should 
incur a change in the view. If no real or virtual keyboard is attached (which 
is hard to imagine, but the world is huge), also changing a single digit should 
incur a change in the view.
Gratefully,
AlMa

Bug#1041490: libreoffice-common: AppArmor profile for libreoffice-oosplach needs wayland abstraction

[jleivent]

On Wed, 19 Jul 2023 19:41:52 +0200
Rene Engelhard  wrote:

> tag 1041490 + moreinfo
> 
> thanks
> 
> 
> Hi,
> 
> 
> Am 19.07.23 um 19:05 schrieb Jonathan Leivent:
> > * What led up to the situation?
> >
> > Attempt to run libreoffice in a Wayland compositor desktop without
> > XWayland support  
> 
> What happens then?

I get the error: "Gdk-Message: 19:20:01.316: Error reading events from
display: Invalid argument"

> 
> >
> > * What exactly did you do (or not do) that was effective (or
> >   ineffective)?
> >
> > Disabled the libreoffice AppArmor profiles  
> 
> Which one?

I disabled them all, but I think the only one that needs disabling is
the oosplash one.  That one includes the X abstraction, but no wayland
abstraction.  The others include the gnome abstraction which includes
the wayland abstraction, so they get it indirectly.

> 
> 2 profiles are in complain mode.
>     libreoffice-oosplash
>     libreoffice-soffice

That's an excelent point.  Why then did it fail and was so easily fixed
by using aa-disable?  I just assumed immediately when I saw that the
oosplash profile includes the X abstraction but not the wayland
abstraction (or any other that would pull in the wayland abstraction
indirectly, like gnome) that this caused my failure.

Are there apparmor issues with it causing failures even though in
complain mode?  That would be a much more serious bug.

I can attempt to replicate the situation with some other debug settings
if you know of any I can use.

> 
> Those who would matter during startup (as you imply below) are only
> in complain mode, not enforcing..
> 
> > * What outcome did you expect instead?
> >
> > Yes.  
> 
> That answer doesn't fit the question :)

Sorry - I read the question as "Was the outcome what you expected" for
some reason.  The answer here should be that the outcome was that I
successfully started libreoffice after aa-disabling the libreoffice
apparmor profiles, and that was what I expected.

Bug#1041440: popularity-contest: Non Debian - non Deb packages should be able to be reported - packages missing from Debian

[Karl Schmidt]

On 7/18/23 11:07PM, Petter Reinholdtsen wrote:

[Karl Schmidt]

While popcon seems a good idea - it seems that data from repository
downloads would do much the same job.


Due to the distributed nature of the mirroring setup, there are no such
data, so it can not be used like that.


It Would be possible to fix that. Data just from one server would give a pretty good idea of the popularity. People that 
run popcon likewise are a subset of the real picture.  A scrip could look at the download logs - make a count - you 
could then compare with popcon to see if the numbers match - I think they would.





What would be even more important is gathering statistics on non
Debian and even non Deb package software installed.


This has been discussed for a while.  You might find for example
https://bugs.debian.org/632438 > illuminating.


Interesting. For example - I know there are a lot of people still using 
komposer - nothing really replaces it.

The number of people running appimage packages in place of the older debian 
versions would be interesting to know as well.

The non-debian executable information seems more important than popcon to me.



--

Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street  Ph (785) 841-3089
Lawrence, KS 66049

Modernity is the denial of uncertainty; a false narrative.
-kps

Bug#1037473: ocsinventory-reports: No such file or directory in /usr/share/ocsinventory-reports/require/header.php on line 31

[Krzysztof Jastrzębski]

Simply commented /usr/share/ocsinventory-reports/require/header.php:31 - 
but this is the least of the problems with this package, because whoever 
can install it and change 'display_errors' can also grep error.log

Worse is #1041489 :-(
You're lucky it's a fresh install and not an upgrade of a large install...

--
Pozdrawiam Krzysztof Jastrzębski <><
krzysztof[at]jastrzebscy[dot]pl http://www.jastrzebscy.pl/

Bug#1041496: mailman3-web: Upgrade from Debian 11 to 12 dpkg can't configure mailman3-full and -web

[Richard Rosner]

Package: mailman3-web
Version: 0+20200530-2.1
Severity: important

Dear Maintainer,

I just made the upgrade from bullseye to bookworm. mailman3 was up and running 
before, but the upgrade failed at the point mailman3-full and mailman3-web 
where supposed to be configured by dpkg. dpkg --configure mailman3-web gives 
these mostly hyperkitty-related errors:

mailman3-web (0+20200530-2.1) wird eingerichtet ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
dbconfig-common: flushing administrative password
/usr/lib/python3/dist-packages/django_q/conf.py:139: UserWarning: Retry and 
timeout are misconfigured. Set retry larger than timeout,
failure to do so will cause the tasks to be retriggered before 
completion.
See https://django-q.readthedocs.io/en/latest/configure.html#retry for 
details.
  warn(
System check identified some issues:

WARNINGS:
django_mailman3.MailDomain: (models.W042) Auto-created primary key used when 
not defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
DjangoMailman3Config.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
django_mailman3.Profile: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
DjangoMailman3Config.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Attachment: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Email: (models.W042) Auto-created primary key used when not defining 
a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Favorite: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.LastView: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.MailingList: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Profile: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tag: (models.W042) Auto-created primary key used when not defining a 
primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tagging: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Thread: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.ThreadCategory: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Vote: (models.W042) Auto-created 

Bug#1041495: binutils regression causes edk2 to FTBFS - cannot find entry symbol _ModuleEntryPoint / assertion failures

[dann frazier]

Package: binutils
Version: 2.40.90.20230714-2
Severity: normal
Tags: upstream

edk2 has begun to FTBFS after recent binutils updates. Log follows below[*],
as well as a log using gcc -v[**].

This is reproducible with upstream binutils. I bisected the failure to
upstream commit fb221fba1a5 ("Add --remap-inputs option to the BFD linker").
After applying a reversion of that commit to the Debian package, this failure
goes away.

[*]
dannf@xps13:/tmp/edk2-2023.05$ "gcc" -o 
/tmp/edk2-2023.05/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/DEBUG/StatusCodeHandlerPei.dll
 -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40 
-Wl,--entry,_ModuleEntryPoint -u _ModuleEntryPoint 
-Wl,-Map,/tmp/edk2-2023.05/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/DEBUG/StatusCodeHandlerPei.map,--whole-archive
 -Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie -flto -Os 
-Wl,--start-group,@/tmp/edk2-2023.05/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/OUTPUT/static_library_files.lst,--end-group
 -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
-Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections 
-fdata-sections -fno-stack-protector 
-DSTRING_ARRAY_NAME=StatusCodeHandlerPeiStrings -m64 -march=x86-64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" 
-maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie 
-fno-asynchronous-unwind-tables -Wno-address -fno-omit-frame-pointer -flto 
-DUSING_LTO -Wno-unused-but-set-variable -Wno-unused-const-variable 
-DMDEPKG_NDEBUG -mno-mmx -mno-sse -D DISABLE_NEW_DEPRECATED_INTERFACES -D 
TDX_GUEST_SUPPORTED -D ENABLE_MD5_DEPRECATED_INTERFACES 
-Wl,--defsym=PECOFF_HEADER_SIZE=0x228 
-Wl,--script=/tmp/edk2-2023.05/BaseTools/Scripts/GccBase.lds -Wno-error
/usr/bin/ld: warning: IoFifoSev.obj: missing .note.GNU-stack section implies 
executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future 
version of the linker
/usr/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint; defaulting to 
0240
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail 
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for 

Bug#1041467: sanlock: systemd service uses unsupported option "watchdog-check"

[Håvard F . Aasen]

On Wed, 19 Jul 2023 11:26:44 +0200 =?utf-8?q?Lars_Dr=C3=B6ge?= 
 wrote:
> Package: sanlock
> Severity: important
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> thank you for maintaining the sanlock package. I may have found a version 
> mismatch in the included wdmd.service file and a lib.
> 
>* What led up to the situation?
>  Try to start the wdmd.service, as it was not succesfully pulled in by 
> sanlock.service.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  systemctl start wdmd.service
>* What was the outcome of this action?
>  Error message: Usage: /etc/init.d/wdmd {start|stop|status|restart}
>* What outcome did you expect instead?
>  wdmd.service starts
> 
> The wdmd.service contains this line in the [Service] section:
> 
>   ExecStartPre=/lib/systemd/systemd-wdmd watchdog-check
> 
> But /lib/systemd/systemd-wdmd does not support the argument "watchdog-check", 
> and throws an error instead.
> All related files are part of the sanlock package.
> 

It seems that we use a rather old version of this file, created by the
first maintainer of the package. Upstream has a different file that has
the "watchdog-check" functionality implemented.

> I have found this behavior in
>   - sanlock 3.8.2-2 in Debian Bullseye
>   - sanlock 3.8.5-1+b1 in Debian Bookworm
> 
> Is it safe to remove the ExecStartPre= line and skip the check?
> 

As a temporary solution it most likely is, the check can be run manually
if you want it. The "watchdog-check" only does two things, and is easy
to replicate.
Ensuring that the wdmd.service is stopped, then executing
wdmd --probe
If it is successful, everything is well and nothing more needs to be
done, if it fails, you should try to load the "softdog" kernel module
with
modprobe softdog && udevadm settle
The relevant part, that is missing from the Debian package, can be found
here [1].


For unstable, I will try to use upstream files for both the systemd
service's as well as their init.d scripts and configuration files. For
bookworm the easiest solution might be to just copy in the two missing
functions.


Regards,
Håvard

[1] https://sources.debian.org/src/sanlock/3.8.5-1/init.d/wdmd/#L34-L56

Bug#1041490: libreoffice-common: AppArmor profile for libreoffice-oosplach needs wayland abstraction

[Rene Engelhard]

tag 1041490 + moreinfo

thanks


Hi,


Am 19.07.23 um 19:05 schrieb Jonathan Leivent:

* What led up to the situation?

Attempt to run libreoffice in a Wayland compositor desktop without XWayland 
support


What happens then?



* What exactly did you do (or not do) that was effective (or
  ineffective)?

Disabled the libreoffice AppArmor profiles


Which one?

2 profiles are in complain mode.
   libreoffice-oosplash
   libreoffice-soffice

Those who would matter during startup (as you imply below) are only in 
complain mode, not enforcing..



* What outcome did you expect instead?

Yes.


That answer doesn't fit the question :)


Regards,


Rene

Bug#1041348: RM: https-everywhere/stable -- ROM; obsolete;major browsers offer native support now;

[Adam D. Barratt]

Control: tags -1 - moreinfo

On Wed, 2023-07-19 at 03:28 +0200, Markus Koschany wrote:
> I have uploaded a new revision of boxer-data and debian-parl to
> Bookworm now.
> This update removes the dependency on webext-https-everywhere. Jonas
> agreed to
> this change.
> 
> https://bugs.debian.org/1041350
> 
> AFAIK nothing else should prevent the removal of https-everywhere
> from
> Bookworm.
> 

Thanks. Untagging so this gets back on the radar for 12.2.

Regards,

Adam

Bug#1041491: yuzu: FTBFS: Unmet build dependencies: glslang-tools:native

[Sebastian Ramacher]

Source: yuzu
Version: 0-1335+ds-1
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=yuzu=amd64=0-1335%2Bds-1%2Bb1=1689519069=0

dpkg-buildpackage: info: host architecture amd64
dpkg-checkbuilddeps: error: Unmet build dependencies: glslang-tools:native
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting

Cheers
-- 
Sebastian Ramacher

Bug#1041490: libreoffice-common: AppArmor profile for libreoffice-oosplach needs wayland abstraction

[Jonathan Leivent]

Package: libreoffice-common
Version: 4:7.4.5-3
Severity: important
X-Debbugs-Cc: jleiv...@comcast.net

Dear Maintainer,

   * What led up to the situation?

Attempt to run libreoffice in a Wayland compositor desktop without XWayland 
support

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Disabled the libreoffice AppArmor profiles

   * What was the outcome of this action?

With libreoffice's AppArmor profiles disabled, it starts without issue

   * What outcome did you expect instead?

Yes.


-- Package-specific info:
Configuration filePackage Exists Changed
/etc/libreoffice/registry/Langpack-en-US.xcd  libreoffice-common  Yes No
/etc/libreoffice/registry/lingucomponent.xcd  libreoffice-common  Yes No
/etc/libreoffice/registry/main.xcdlibreoffice-common  Yes No
/etc/libreoffice/registry/pdfimport.xcd   libreoffice-common  Yes No
/etc/libreoffice/registry/res/fcfg_langpack_e libreoffice-common  Yes No
/etc/libreoffice/registry/xsltfilter.xcd  libreoffice-common  Yes No

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

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

Versions of packages libreoffice-common depends on:
ii  libnumbertext-data 1.0.11-1
ii  libreoffice-style-colibre  4:7.4.5-3
ii  ucf3.0043+nmu1
ii  ure4:7.4.5-3

Versions of packages libreoffice-common recommends:
ii  apparmor3.0.8-3
ii  fonts-liberation2   2.1.5-1
ii  libexttextcat-data  3.4.5-1
ii  poppler-data0.4.12-1
ii  python3-uno 4:7.4.5-3
ii  xdg-utils   1.1.3-4.1

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-colibre [libreoffice-style]  4:7.4.5-3

-- no debconf information

Bug#1035576: plasma-settings: OpenDesktop in SystemSettings->OnlineAccounts doesn't work!

[Marco Mattiolo]

Hi,

I think this bug report should not belong to the plasma-settings package.

As you wrote, you are using SystemSettings, which is another app: let's 
think of plasma-settings as the settings app for  a mobile system, while 
systemsettings is the settings app for a desktop system. On a mobile 
system, both are installed due to plasma-mobile's dependencies depending 
on systemsettings, but they are different packages.


As described in [1][2], both systemsettings and plasma-settings are not 
responsible themselves for managing OnlineAccounts: they are just 
exposing the available KCMs. In fact, I do not see the OnlineAccounts 
section inside systemsettings/plasma-settings on my system, unless I 
install the kaccounts-integration package.


Tbh I've no clue where this bug should be re-assigned. Looking at the 
attachment inside [3] bug report, looks like some kind of browser plugin 
is invoked to open the OpenDesktop login interface inside an X window... 
it could be Kaccounts, it could be KCM, it could also be that the login 
window does not support Wayland... have you tried launching 
systemsettings from the console and check if any error message is 
displayed when you try the OpenDesktop login?


Kind regards

Marco

[1] https://invent.kde.org/network/kaccounts-integration#kde-control-module

[2] https://community.kde.org/Online_Accounts

[3] https://bugs.kde.org/show_bug.cgi?id=438424

Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs

[Jonas Smedegaard]

Hi Faidon,

Quoting Faidon Liambotis (2023-07-19 15:01:59)
> On Wed, Jul 19, 2023 at 10:56:32AM +0200, Jonas Smedegaard wrote:
> >  rust-wasmtime is the Rust embedding API for the Wasmtime project:
> >  a cross-platform engine for running WebAssembly programs.
> > 
> > This is a pseudo-ITP: The source package is already maintained for the
> > subset covering core Cranelift crates, since they are part of same
> > monorepo. The intent tracked here is extending that source package to
> > provide binary packages librust-wasmtime* which involves additional
> > dependencies unneeded for Cranelift.
> 
> I'm not sure what you mean by that -- what is already maintained? 

Whoops, I had it in mind but evidently forgot to mention it: I mean the
packaging effort tracked as ITP bug#1041434 (and now in NEW queue).


> Also, are you planning to package wasmtime, as in the CLI, itself? I
> believe this exists on the same upstream/source tree as the language
> bindings that you're proposing here?

I mean both the Rust crates and the command-line tool.

You are right, both are part of same monorepo.


> > Please shout if there is need for wasmtime, and especially if there is
> > interest in helping get the needed dependencies packaged.
> 
> I don't have the bandwidth to help packaging wasmtime. However, I do
> maintain another popular WebAssembly runtime, WasmEdge, and last year I
> contributed a few changes to the Debian LLVM packages
> (src:llvm-project-14 and friends) with regards to WebAssembly support,
> and so you could say I'm interested with helping in bringing more parts
> of the WebAssembly ecosystem in Debian :) I'm also interested in
> opportunities to help each other, and in the relevant packages working
> well with each other and/or providing a unified experience. Let me know
> if you can think of any such ways.

I don't have a special interest in WebAssembly (yet) - my packaging
efforts here is targeted packaging of swt (bug#991761).  That work also
involves packaging (again only a subset of crates initially for) wasmer.

> On that note, you may be interested in (and/or subscribing to) #1033322.

Thanks. I've subscribed to that now :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1041443: [Debian-pan-maintainers] Bug#1041443: pyfai_2023.5.0+dfsg1-3_all-buildd.changes REJECTED

[Aurelien Jarno]

On 2023-07-19 13:38, PICCA Frederic-Emmanuel wrote:
> > I am just the messenger here, if you disagree, please feel free to
> > contact ftpmasters or lintian maintainers.
> 
> This was not a rant about this, I just wanted to understand what is going on 
> :).
> 
> > Your package has been built successfully on (some) buildds, but then the
> > binaries upload got rejected by dak, that's why they are still in
> > "Uploaded" state. Overall it's just like if pyfai hasn't been built or
> > fails to build from source.
> 
> So until a new upstream source is available with other timestamp, it will not 
> be uploadable.

The problem is not in the upstream source tarball (the source got
accepted), but rather in the binary packages produced during the build.
The debian/rules file can somehow change the timestamp after copying the
file into the debian/tmp hierarchy.

> In you opinion, can we discuss about this on debian-devel ?
> 

Yes, I don't see why it couldn't be discussed there.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1033847: closed by Debian FTP Masters (reply to gabr...@debian.org (Gabriel F. T. Gomes)) (Bug#1033847: fixed in bash-completion 1:2.11-7)

[Gabriel F. T. Gomes]

Hi again,

One of the project maintainers said [1] that the plan for a release is
still up. I'll try to help them with whatever spare time I can find.
Not sure if you are interested in doing that as well, but I wanted to
make a point that bash-completion is a very friendly community and
welcomes every contribution. ^^

[1] 
https://github.com/scop/bash-completion/discussions/530#discussioncomment-6490360

Bug#1041489: ocsinventory-reports: version inconsistency between GUI and perl libraries

[Krzysztof Jastrzębski]

Package: ocsinventory-reports
Version: 2.8.1+dfsg1+~2.11.1-1
Severity: important

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
ii  ocsinventory-reports  2.8.1+dfsg1+~2.11.1-1
ii  ocsinventory-server   2.8.1+dfsg1+~2.11.1-1

grep GUI_VER /usr/share/ocsinventory-reports/var.php
define('GUI_VER', '7069');
define('GUI_VER_SHOW', '2.11.1');

But perl libraries left in 2.8.1:
grep "Ocsinventory::VERSION" /usr/share/perl5/Apache/Ocsinventory.pm
$Apache::Ocsinventory::VERSION = '2.8.1';

In upstream sources 
(https://github.com/OCSInventory-NG/OCSInventory-ocsreports/releases/download/2.11.1/OCSNG_UNIX_SERVER-2.11.1.tar.gz) 
this libraries are the same versions as GUI:
grep "Ocsinventory::VERSION" 
/tmp/OCSNG_UNIX_SERVER-2.11.1/Apache/Ocsinventory.pm

$Apache::Ocsinventory::VERSION = '2.11.1';

After upgrade from bullseye to bookworm, ocsinventory-reports upgrades 
database:

Existing database updated
Current version:7039=>Expected version:7069

This causes many errors during updates by agents and during inventory with:
/ocsreports/index.php?function=admin_dico; function=soft_cat; and 
probably more.


For example CATEGORY field was migrated in 7045:
grep -a1 "DROP CATEGORY" 
/usr/share/ocsinventory-reports/files/update/7045.sql

-- DROP CATEGORY column from software_name
ALTER TABLE `software_name` DROP COLUMN `CATEGORY

But old (2.8.1) function uses it:
grep software_name 
/usr/share/perl5/Apache/Ocsinventory/Server/Inventory/Software.pm

  _insert_software_name
sub _insert_software_name {
$sql = "SELECT ID, CATEGORY FROM software_name WHERE NAME = ?";
$sql = "INSERT INTO software_name (NAME) VALUES(?)";
$sql = "INSERT INTO software_name (NAME,CATEGORY) VALUES(?,?)";
$sql = "SELECT ID FROM software_name WHERE NAME = ?";
my $sqlUpdate = "UPDATE software_name SET CATEGORY = ? 
WHERE ID = ?";
$arrayValue{NAME_ID} = _insert_software_name($name, 
$software->{CATEGORY});


Upstream sources are completely rewritten:
grep software_name 
/tmp/OCSNG_UNIX_SERVER-2.11.1/Apache/Ocsinventory/Server/Inventory/Software.pm
$arrayValue{NAME_ID} = _get_info_software($name, 
"software_name", "NAME");


This makes the 2.8.1+dfsg1+~2.11.1-1 package useless and I am not sure 
if after the activity of the agents the database was not disintegrated 
and does not need to be restored from the backup.


--
Pozdrawiam Krzysztof Jastrzębski <><
krzysztof[at]jastrzebscy[dot]pl http://www.jastrzebscy.pl/

Bug#1037040: util-linux: Please coordinate upload of 2.39 with manpages-l10n

[Chris Hofstaedtler]

* Chris Hofstaedtler  [230719 18:24]:
> Attached is a list of the new files that will show up in util-linux-locales.

Attached now :-)

Chris
drwxr-xr-x root/root 0 2023-07-19 17:56 ./usr/share/man/cs/
drwxr-xr-x root/root 0 2023-07-19 17:56 ./usr/share/man/cs/man1/
-rw-r--r-- root/root  4039 2023-07-19 17:56 ./usr/share/man/cs/man1/su.1.gz
-rw-r--r-- root/root  1624 2023-07-19 17:56 
./usr/share/man/cs/man1/write.1.gz
drwxr-xr-x root/root 0 2023-07-19 17:56 ./usr/share/man/cs/man5/
-rw-r--r-- root/root  3643 2023-07-19 17:56 
./usr/share/man/cs/man5/fstab.5.gz
drwxr-xr-x root/root 0 2023-07-19 17:56 ./usr/share/man/de/
drwxr-xr-x root/root 0 2023-07-19 17:56 ./usr/share/man/de/man1/
-rw-r--r-- root/root  1960 2023-07-19 17:56 
./usr/share/man/de/man1/choom.1.gz
-rw-r--r-- root/root  2630 2023-07-19 17:56 
./usr/share/man/de/man1/chrt.1.gz
-rw-r--r-- root/root  1953 2023-07-19 17:56 ./usr/share/man/de/man1/col.1.gz
-rw-r--r-- root/root  1605 2023-07-19 17:56 
./usr/share/man/de/man1/colcrt.1.gz
-rw-r--r-- root/root   971 2023-07-19 17:56 
./usr/share/man/de/man1/colrm.1.gz
-rw-r--r-- root/root  4120 2023-07-19 17:56 
./usr/share/man/de/man1/column.1.gz
-rw-r--r-- root/root  4608 2023-07-19 17:56 
./usr/share/man/de/man1/dmesg.1.gz
-rw-r--r-- root/root  3817 2023-07-19 17:56 
./usr/share/man/de/man1/eject.1.gz
-rw-r--r-- root/root  3069 2023-07-19 17:56 
./usr/share/man/de/man1/fallocate.1.gz
-rw-r--r-- root/root  1627 2023-07-19 17:56 
./usr/share/man/de/man1/fincore.1.gz
-rw-r--r-- root/root  3397 2023-07-19 17:56 
./usr/share/man/de/man1/flock.1.gz
-rw-r--r-- root/root  5551 2023-07-19 17:56 
./usr/share/man/de/man1/getopt.1.gz
-rw-r--r-- root/root  3958 2023-07-19 17:56 
./usr/share/man/de/man1/hardlink.1.gz
-rw-r--r-- root/root  5599 2023-07-19 17:56 
./usr/share/man/de/man1/hexdump.1.gz
-rw-r--r-- root/root  2536 2023-07-19 17:56 
./usr/share/man/de/man1/ionice.1.gz
-rw-r--r-- root/root  1252 2023-07-19 17:56 
./usr/share/man/de/man1/ipcmk.1.gz
-rw-r--r-- root/root  2131 2023-07-19 17:56 
./usr/share/man/de/man1/ipcrm.1.gz
-rw-r--r-- root/root  2170 2023-07-19 17:56 
./usr/share/man/de/man1/ipcs.1.gz
-rw-r--r-- root/root  2857 2023-07-19 17:56 
./usr/share/man/de/man1/last.1.gz
-rw-r--r-- root/root  6015 2023-07-19 17:56 
./usr/share/man/de/man1/logger.1.gz
-rw-r--r-- root/root  1670 2023-07-19 17:56 
./usr/share/man/de/man1/look.1.gz
-rw-r--r-- root/root  3706 2023-07-19 17:56 
./usr/share/man/de/man1/lscpu.1.gz
-rw-r--r-- root/root  7656 2023-07-19 17:56 
./usr/share/man/de/man1/lsfd.1.gz
-rw-r--r-- root/root  2322 2023-07-19 17:56 
./usr/share/man/de/man1/lsipc.1.gz
-rw-r--r-- root/root  1304 2023-07-19 17:56 
./usr/share/man/de/man1/lsirq.1.gz
-rw-r--r-- root/root  3192 2023-07-19 17:56 
./usr/share/man/de/man1/lslogins.1.gz
-rw-r--r-- root/root  2632 2023-07-19 17:56 
./usr/share/man/de/man1/lsmem.1.gz
-rw-r--r-- root/root  1507 2023-07-19 17:56 
./usr/share/man/de/man1/mcookie.1.gz
-rw-r--r-- root/root  1587 2023-07-19 17:56 
./usr/share/man/de/man1/mesg.1.gz
-rw-r--r-- root/root  3154 2023-07-19 17:56 
./usr/share/man/de/man1/more.1.gz
-rw-r--r-- root/root  1378 2023-07-19 17:56 
./usr/share/man/de/man1/mountpoint.1.gz
-rw-r--r-- root/root  1816 2023-07-19 17:56 
./usr/share/man/de/man1/namei.1.gz
-rw-r--r-- root/root  3498 2023-07-19 17:56 
./usr/share/man/de/man1/nsenter.1.gz
-rw-r--r-- root/root  2385 2023-07-19 17:56 
./usr/share/man/de/man1/prlimit.1.gz
-rw-r--r-- root/root  2349 2023-07-19 17:56 
./usr/share/man/de/man1/rename.ul.1.gz
-rw-r--r-- root/root   2023-07-19 17:56 
./usr/share/man/de/man1/renice.1.gz
-rw-r--r-- root/root  1052 2023-07-19 17:56 ./usr/share/man/de/man1/rev.1.gz
-rw-r--r-- root/root  3635 2023-07-19 17:56 
./usr/share/man/de/man1/runuser.1.gz
-rw-r--r-- root/root  4263 2023-07-19 17:56 
./usr/share/man/de/man1/script.1.gz
-rw-r--r-- root/root  1924 2023-07-19 17:56 
./usr/share/man/de/man1/scriptlive.1.gz
-rw-r--r-- root/root  2672 2023-07-19 17:56 
./usr/share/man/de/man1/scriptreplay.1.gz
-rw-r--r-- root/root  3799 2023-07-19 17:56 
./usr/share/man/de/man1/setpriv.1.gz
-rw-r--r-- root/root  1046 2023-07-19 17:56 
./usr/share/man/de/man1/setsid.1.gz
-rw-r--r-- root/root  4162 2023-07-19 17:56 
./usr/share/man/de/man1/setterm.1.gz
-rw-r--r-- root/root  4164 2023-07-19 17:56 ./usr/share/man/de/man1/su.1.gz
-rw-r--r-- root/root  2938 2023-07-19 17:56 
./usr/share/man/de/man1/taskset.1.gz
-rw-r--r-- root/root  2497 2023-07-19 17:56 
./usr/share/man/de/man1/uclampset.1.gz
-rw-r--r-- root/root  1644 2023-07-19 17:56 ./usr/share/man/de/man1/ul.1.gz
-rw-r--r-- root/root  6867 2023-07-19 17:56 
./usr/share/man/de/man1/unshare.1.gz
-rw-r--r-- root/root  1596 2023-07-19 17:56 
./usr/share/man/de/man1/utmpdump.1.gz

Bug#1041488: RFP: libjwat-java -- Java Web Archive Toolkit

[Elias Oltmanns]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: oltma...@zib.de

* Package name: libjwat-java
  Version : 1.2.1
* URL : https://sbforge.org/display/JWAT/JWAT
* License : Apache-2.0
  Programming Lang: Java
  Description : Java Web Archive Toolkit

A collection of libraries to use for reading, writing and validating ARC,
WARC and GZip files. Also includes various helper classes to help with
different types of input streams. Finally there are also classes to help
with HTTP, character encoding and other Internet related protocols.

Additional information:
 - Why is this package useful/relevant?
   The binary Debian package of JHOVE, a java tool for format-specific
   identification, validation, and characterisation of digital objects,
   currently lacks support for EPUB, GZIP, PNG, and WARC files due to a
   missing dependency. Adding libjwat-java to the Debian archive as
   requested in this bug report would make it possible to ship JHOVE
   including those extra modules with Debian too.
   See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037934
 - How do you plan to maintain it?
   At Zuse Intstitute Berlin, we have prepared debian/* packaging files
   for an initial upload. These will be made available in a follow up to
   this bug report. We are looking for a sponsor, however, as there is
   no Debian developer in our team. Specifically, I am hoping for
   support by the Debian Java Maintainers because they are looking after
   the JHOVE package in Debian. As explained above, extending the
   capabilities of JHOVE is the main reason for filing this bug report.

Bug#1037040: util-linux: Please coordinate upload of 2.39 with manpages-l10n

[Chris Hofstaedtler]

Hi,

* Helge Kreutzmann  [230718 18:21]:
> On Fri, Jun 02, 2023 at 03:33:33PM +0200, Helge Kreutzmann wrote:
> > once bookworm is released, I assume that you intend to package the latest
> > version, i.e. 2.39.
> > 
> > This version comes with translated man pages, which were (up to
> > now) shipped by manpages-l10n.
> > 
> > To allow a smooth transition, both packages need to declare
> > appropriate package relations:
> > https://wiki.debian.org/PackageTransition
> > 
> > So please let me know about the upload and the relevant version
> > (probably 2.39.0-1?).
> > 
> > Until I hear something from your side, manpages-l10n will continue
> > shipping the translated man pages.
> 
> The most convenient time for me would be around the end of August,
> when manpages-l10n releases the next version. Then I could deal with
> this quite nicely. Do you think this is a sensible date for you as
> well?

If you don't plan to upload manpages-l10n until then, I would complete the
util-linux side relatively soon.

My plan is the following:

util-linux-locales (!) 2.39.1-3 will ship the translated manpages,
and would gain these package relationships:
  Breaks: manpages-cs (<< 4.19.0-4~),
  manpages-cs-dev (<< 4.19.0-4~),
  manpages-de (<< 4.19.0-4~),
  manpages-de-dev (<< 4.19.0-4~),
  manpages-es (<< 4.19.0-4~),
  manpages-es-dev (<< 4.19.0-4~),
  manpages-fr (<< 4.19.0-4~),
  manpages-fr-dev (<< 4.19.0-4~),
  manpages-pt-br (<< 4.19.0-4~),
  manpages-sr (<< 4.19.0-4~),
  manpages-uk (<< 4.19.0-4~),
  manpages-uk-dev (<< 4.19.0-4~)
  Replaces: manpages-cs (<< 4.19.0-4~),
manpages-cs-dev (<< 4.19.0-4~),
manpages-de (<< 4.19.0-4~),
manpages-de-dev (<< 4.19.0-4~),
manpages-es (<< 4.19.0-4~),
manpages-es-dev (<< 4.19.0-4~),
manpages-fr (<< 4.19.0-4~),
manpages-fr-dev (<< 4.19.0-4~),
manpages-pt-br (<< 4.19.0-4~),
manpages-sr (<< 4.19.0-4~),
manpages-uk (<< 4.19.0-4~),
manpages-uk-dev (<< 4.19.0-4~)

Attached is a list of the new files that will show up in util-linux-locales.

Please check the relationships and the attached file list.


I'm planning to put these changes into 2.39.1-2 in experimental, and then with
-3 into unstable. That should give us the chance to double check things in
experimental.

Chris

Bug#1040838: libblockdev: Please build the "tools" and create a -tools package

[Michael Biebl]

Hi,

On Tue, 11 Jul 2023 13:59:40 +0200 Laurent Bigonville  
wrote:

The libblockdev source package contains two "tools" that are currently
not built.

One for them is "vfat-resize", that looks like an intresting feature to
have?


Tbh, I think this feature should belong into the same package shipping 
mkfs.vfat, i.e. dosfstools.


Andreas, as maintainer of dosfstools, what's your take on this?

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041487: RFS: gnss-sdr/0.0.18-2 [RC] [Team] -- Global navigation satellite systems software defined receiver

[Bo YU]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "gnss-sdr":

 * Package name : gnss-sdr
   Version  : 0.0.18-2
   Upstream contact : Carles Fernandez 
 * URL  : https://gnss-sdr.org
 * License  : Expat, Apache-2.0, Apple-Permissive, BSD-2-clause, 
BSD-3-clause, BSD-3-Clause, LGPL-3+, GPL-3+, Zlib, Permissive
 * Vcs  : https://salsa.debian.org/debian-hamradio-team/gnss-sdr
   Section  : hamradio

The source builds the following binary packages:

  gnss-sdr - Global navigation satellite systems software defined receiver

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

  https://mentors.debian.net/package/gnss-sdr/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnss-sdr/gnss-sdr_0.0.18-2.dsc

Changes since the last upload:

 gnss-sdr (0.0.18-2) unstable; urgency=medium
 .
   * Team upload.
   * Upload to sid to close gcc-13 build issue. (Closes: #1037680)

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1041344: AttributeError: module 'pyflakes.messages' has no attribute 'RedefinedInListComp'

[Ludovic Rousseau]

Hello,

I propose a fix in 
https://salsa.debian.org/python-team/packages/pylama/-/merge_requests/3

Bug#1041486: RFS: openbox/3.6.1-11 -- standards-compliant, fast, light-weight and extensible window manager

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : openbox
   Version  : 3.6.1-11
   Upstream contact : Dana Jansens
 * URL  :http://www.openbox.org
 * License  : GPL-2+, GPL-3+
 * Vcs  :https://github.com/mati75/openbox-debian
   Section  : x11

The source builds the following binary packages:

  openbox - standards-compliant, fast, light-weight and extensible window 
manager
  libobt2v5 - parsing library for openbox
  libobrender32v5 - rendering library for openbox themes
  openbox-dev - development files for the openbox window manager
  gnome-panel-control - command line utility to invoke GNOME panel run 
dialog/menu
  openbox-gnome-session - command line utility to run Openbox as GNOME session
  openbox-kde-session - command line utility to run Openbox as KDE SC session

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/o/openbox/openbox_3.6.1-11.dsc

Changes since the last upload:

 openbox (3.6.1-11) unstable; urgency=medium
 .
   [ Mateusz Łukasik ]
   * debian/obamenu:
 + Use x-terminal-emulator as terminal emulator. (Closes: #1010019)
 + Fix ignoring broken links. (Closes: #886716)
   * d/patches:
 + Add patch for fix openbox invokes imlib_free_image when no image
 is loaded (Closes: #1007147)
 + Add patch from upstream for fix crashes when switching out of
 a fullscreen window with GLib 2.76.0. (LP: #2011751) (Closes: #1033385)
   * d/control: Bump Standards-Version to 4.6.2.
   * d/copyright: Welcome 2023.
   * d/watch: Update to version 4 and change sources repository.
 .
   [ Debian Janitor ]
   * Set upstream metadata fields: Repository-Browse.
   * Remove constraints unnecessary since buster:
 + Build-Depends: Drop versioned constraint on automake and libxml2-dev.
 + gnome-panel-control: Drop versioned constraint on openbox in Replaces.
 + gnome-panel-control: Drop versioned constraint on openbox in Breaks.
 + openbox-gnome-session: Drop versioned constraint on openbox in Replaces.
 + openbox-gnome-session: Drop versioned constraint on openbox in Breaks.
 + openbox-kde-session: Drop versioned constraint on openbox in Replaces.
 + openbox-kde-session: Drop versioned constraint on openbox in Breaks.
   * Remove 1 obsolete maintscript entry.
   * Avoid explicitly specifying -Wl,--as-needed linker flag.
 .
   [ Ingo Brückl ]
   * Update German translation.

Regards,
--
  Mateusz Łukasik

Bug#1041483: nbconvert: autopkgtests broken by recent nbclient

[Simon Chopin]

Source: nbconvert
Followup-For: Bug #1041483
X-Debbugs-Cc: scho...@ubuntu.com

Salsa MR adressing the issue: 
https://salsa.debian.org/python-team/packages/nbconvert/-/merge_requests/4




-- System Information:
Debian Release: bookworm/sid
  APT prefers lunar-updates
  APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'), 
(100, 'lunar-proposed'), (100, 'lunar-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1038811: Kernel 6.3 also has these bugs.

[Niccolò Paganini II]

I would like to add that the problem remains with kernel 6.3...

Best regards,
Niccòlo Paganini

Bug#1041485: RFS: spades/3.15.5+dfsg-2.1 [NMU] [RC] -- genome assembler for single-cell and isolates data sets

[Bo YU]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : spades
   Version  : 3.15.5+dfsg-2.1
   Upstream contact : spades.supp...@bioinf.spbau.ru
 * URL  : http://cab.spbu.ru/software/spades/
 * License  : Expat, Apache-2.0, BSD-3-clause-Akiba, GPL-2+, 
BSD-3-clause, BSD-2-clause, GPL-3+, LGPL-2.1+, BSD-3-clause-Google, Boost-1, 
UoI-NCSA, BSDlike-libbzip2, BSD-3-clause-PacBio
 * Vcs  : https://salsa.debian.org/med-team/spades
   Section  : science

The source builds the following binary packages:

  spades - genome assembler for single-cell and isolates data sets

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/spades/spades_3.15.5+dfsg-2.1.dsc

Changes since the last upload:

 spades (3.15.5+dfsg-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix ftbfs on gcc-13. (Closes: #1037863)

--
BTW, the package maybe only need to build target like x64.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1041484: kernel: hpet_acpi_add: no address or irqs in _CRS

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1
In the journal of a laptop Lenovo ThinkPad T14s Gen1, connected to a docking 
station ThinkPad Thunderbolt 3 Dock Gen 2/Workstation Dock Gen 2 Type 40 AN 
(which is powered by a 135 W AC Adapter ADL135NCC3A) and to a monitor Philips 
275B1 via a HMDI cable, we discovered the following warning (last line is 
yellow) generated at boot:
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: Freeing initrd memory: 
78744K Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: alg: self-tests for 
CTR-KDF (hmac(sha256)) passed Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s 
kernel: Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250) 
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: io scheduler mq-deadline 
registered Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: pcieport 
:00:1c.0: PME: Signaling with IRQ 122 Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: pcieport :00:1c.4: PME: Signaling with 
IRQ 123 Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: pcieport 
:00:1c.4: pciehp: Slot #4 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ 
Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: pcieport :00:1d.0: PME: Signaling with 
IRQ 124 Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: pcieport 
:00:1d.0: pciehp: Slot #0 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ 
Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: pcieport :00:1d.4: PME: Signaling with 
IRQ 125 Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: pcieport 
:04:01.0: pciehp: Slot #1 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ 
Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: shpchp: Standard Hot Plug PCI Controller 
Driver version: 0.4 Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: 
thermal LNXTHERM:00: registered as thermal_zone0 Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: ACPI: thermal: Thermal Zone [THM0] (72 C) 
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: Serial: 8250/16550 driver, 
4 ports, IRQ sharing enabled Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s 
kernel: serial :00:16.3: enabling device ( -> 0003) Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: :00:16.3: ttyS0 at I/O 0x4060 (irq = 
19, base_baud = 115200) is a 16550A Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: hpet_acpi_add: no address or irqs in _CRS
As the laptop has some issues later (e.g., the contents of the external and 
internal screens do not fully match in tty text mode: the output to the 
external monitor is cut below), we'd like to know the extent and consequences 
of the above warning “hpet_acpi_add: no address or irqs in _CRS”. I plain 
English, what does it tell us? What does it warn us about, and which actions 
should we undertake to avoid whichever havoc it might promise?
Here is some more data:
# journalctl -b| grep -i -C1 hpet Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s 
kernel: ACPI: BOOT 0x9CB2F000 28 (v01 LENOVO TP-N2Y   1260 PTEC 
0002) Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: HPET 
0x9CB2A000 38 (v01 LENOVO TP-N2Y   1260 PTEC 0002) Jul 19 
16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: APIC 0x9CB29000 
000164 (v04 LENOVO TP-N2Y   1260 PTEC 0002) -- Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: ACPI: Reserving BOOT table memory at [mem 
0x9cb2f000-0x9cb2f027] Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: 
ACPI: Reserving HPET table memory at [mem 0x9cb2a000-0x9cb2a037] Jul 19 
16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: Reserving APIC table memory 
at [mem 0x9cb29000-0x9cb29163] -- Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s 
kernel: ACPI: Using ACPI (MADT) for SMP configuration information Jul 19 
16:20:34 AnonymizedLenovoThinkPadT14s kernel: ACPI: HPET id: 0x8086a201 base: 
0xfed0 Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: e820: update 
[mem 0x94e5b000-0x9509bfff] usable ==> reserved -- Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: ACPI: Core revision 20220331 Jul 19 
16:20:34 AnonymizedLenovoThinkPadT14s kernel: hpet: HPET dysfunctional in PC10. 
Force disabled. Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: APIC: 
Switch to symmetric I/O mode setup -- Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: DMAR-IR: IOAPIC id 2 under DRHD base  
0xfed91000 IOMMU 1 Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: 
DMAR-IR: HPET id 0 under DRHD base 0xfed91000 Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: DMAR-IR: Queued invalidation will be 
enabled to support x2apic and Intr-remapping. -- Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: :00:16.3: ttyS0 at I/O 0x4060 (irq = 
19, base_baud = 115200) is a 16550A Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: 

Bug#1041483: nbconvert: autopkgtests broken by recent nbclient

[Simon Chopin]

Source: nbconvert
Severity: important
X-Debbugs-Cc: scho...@ubuntu.com

The autopkgtests for nbconvert are broken by a nbclient update that
slightly changes the formatting of an exception string.

This has been fixed upstream in https://github.com/jupyter/nbconvert/pull/1985

Bug#1041482: kernel: pnp 00:0a: disabling [mem …-…] because it overlaps 0000:00:02.0 BAR 6 [mem 0x000c0000-0x000dffff]

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1
In the journal of a laptop Lenovo ThinkPad T14s Gen1, connected to a docking 
station ThinkPad Thunderbolt 3 Dock Gen 2/Workstation Dock Gen 2 Type 40 AN 
(which is powered by a 135 W AC Adapter ADL135NCC3A) and to a monitor Philips 
275B1 via a HMDI cable, we discovered the following four warnings (last four 
lines are yellow) generated at boot:
Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: pnp: PnP ACPI init Jul 19 
16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 00:00: [io  0x1800-0x18fe] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:00: [mem 0xfd00-0xfd69] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:00: [mem 0xfd6b-0xfd6c] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:00: [mem 0xfd6f-0xfdff] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:00: [mem 0xfe00-0xfe01] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:00: [mem 0xfe20-0xfe7f] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:00: [mem 0xff00-0x] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:01: [io  0x2000-0x20fe] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:02: [io  0x0680-0x069f] has been 
reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 00:02: [io 
 0x164e-0x164f] has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s 
kernel: system 00:04: [io  0x1854-0x1857] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:07: [io  0x1800-0x189f] could 
not be reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:07: [io  0x0800-0x087f] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:07: [io  0x0880-0x08ff] has been 
reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 00:07: [io 
 0x0900-0x097f] has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s 
kernel: system 00:07: [io  0x0980-0x09ff] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:07: [io  0x0a00-0x0a7f] has been 
reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 00:07: [io 
 0x0a80-0x0aff] has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s 
kernel: system 00:07: [io  0x0b00-0x0b7f] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:07: [io  0x0b80-0x0bff] has been 
reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 00:07: [io 
 0x15e0-0x15ef] has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s 
kernel: system 00:07: [io  0x1600-0x167f] could not be reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:07: [io  0x1640-0x165f] could 
not be reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:07: [mem 0xf000-0xf7ff] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:07: [mem 0xfed1-0xfed13fff] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:07: [mem 0xfed18000-0xfed18fff] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:07: [mem 0xfed19000-0xfed19fff] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:07: [mem 0xfeb0-0xfebf] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:07: [mem 0xfed2-0xfed3] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:07: [mem 0xfed9-0xfed93fff] could not be reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:08: [mem 0xfed1-0xfed17fff] 
could not be reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: 
system 00:08: [mem 0xfed18000-0xfed18fff] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:08: [mem 0xfed19000-0xfed19fff] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:08: [mem 0xf000-0xf7ff] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:08: [mem 0xfed2-0xfed3] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: system 
00:08: [mem 0xfed9-0xfed93fff] could not be reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:08: [mem 0xfed45000-0xfed8] 
could not be reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: 
system 00:08: [mem 0xfee0-0xfeef] has been reserved Jul 19 16:20:34 
AnonymizedLenovoThinkPadT14s kernel: system 00:09: [mem 0xfe038000-0xfe038fff] 
has been reserved Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: pnp 
00:0a: disabling [mem 0x000c-0x000c3fff] because it overlaps :00:02.0 
BAR 6 [mem 

Bug#1041481: hexchat process terminates after choosing an irc room to join.

[Alexander Stecker]

Package: hexchat
Version: 2.16.1-1+b3
Severity: important
X-Debbugs-Cc: debian2...@yvbn.de

Dear Maintainer,

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

   * What led up to the situation?
 trying to join an irc room
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 click on the name of the, then click ok.
   * What was the outcome of this action?
 hexchat terminated
   * What outcome did you expect instead?
 open the room

output of hexchat on command line: https://paste.debian.net/1286336/

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


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

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

Versions of packages hexchat depends on:
ii  hexchat-common   2.16.1-1
ii  libc62.36-9
ii  libcanberra0 0.30-10
ii  libdbus-glib-1-2 0.112-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libssl3  3.0.9-1
ii  libx11-6 2:1.8.4-2+deb12u1

Versions of packages hexchat recommends:
ii  ca-certificates  20230311
ii  hexchat-lua  2.16.1-1+b3
ii  hexchat-perl 2.16.1-1+b3
ii  hexchat-plugins  2.16.1-1+b3
ii  hexchat-python3  2.16.1-1+b3
ii  libglib2.0-bin   2.74.6-2

Versions of packages hexchat suggests:
pn  hexchat-otr  
pn  unifont  

-- no debconf information

Bug#1037577: antpm: 1.21-1 to fix ftbfs with GCC-13

[Ralovich Kristóf]

Version 1.21-1 is supposed to fix the gcc 13 build failure. Could someone 
please upload it from master/HEAD of https://salsa.debian.org/debian/antpm ?

Thank you,
Kristof

Bug#1041480: python3-h5py: I can't use the debian provided python3-h5py as a dependency in my package because it is called h5py.-debian-h5py-serial

[Tim Molteno]

Package: python3-h5py
Version: 3.7.0-8
Severity: important
X-Debbugs-Cc: t...@molteno.net

Dear Maintainer,

I am developing a package that depends on h5py. It is predominantly used on 
raspberry pi, and other single board computers. When I specify 'h5py' 
as a dependency, it does not pick up the system installed version. I think this 
is because it is named 'h5py.-debian-h5py-serial'. This causes
huge problems because the attempt to build takes more than an hour and then 
fails on an rPi3.

How should packages that wish to the debian python3-h5py as a dependency 
specify this.

-- System Information:
Debian Release: 12.0
  APT prefers stable
  APT policy: (990, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-h5py depends on:
ii  python3-h5py-serial  3.7.0-8

python3-h5py recommends no packages.

Versions of packages python3-h5py suggests:
pn  python-h5py-doc  

-- no debconf information

Bug#1041196: marco: Window title disappears when the first character is Chinese

[Wenbin Lv]

Control: tags -1 + patch

A fix is merged upstream, although no new release has been made yet.

https://github.com/mate-desktop/marco/pull/758/commits/4afac8d567bbedead598f213900c805ae406be04

Bug#1041479: httpcore: Please update to 0.17.3 (or current version)

[Scott Kitterman]

Source: httpcore
Version: 0.16.3-1
Severity: wishlist

The DNS Over HTTP (DOH) tests for dnspython use httpcore as of the
latest upstream release (which I'm preparing for upload), but need a
newer version that is currently in unstable.

Please update so we can run the complete test suite.

Thanks,

Scott K

Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs

[Faidon Liambotis]

On Wed, Jul 19, 2023 at 10:56:32AM +0200, Jonas Smedegaard wrote:
>  rust-wasmtime is the Rust embedding API for the Wasmtime project:
>  a cross-platform engine for running WebAssembly programs.
> 
> This is a pseudo-ITP: The source package is already maintained for the
> subset covering core Cranelift crates, since they are part of same
> monorepo. The intent tracked here is extending that source package to
> provide binary packages librust-wasmtime* which involves additional
> dependencies unneeded for Cranelift.

I'm not sure what you mean by that -- what is already maintained? 

Also, are you planning to package wasmtime, as in the CLI, itself? I
believe this exists on the same upstream/source tree as the language
bindings that you're proposing here?

> Please shout if there is need for wasmtime, and especially if there is
> interest in helping get the needed dependencies packaged.

I don't have the bandwidth to help packaging wasmtime. However, I do
maintain another popular WebAssembly runtime, WasmEdge, and last year I
contributed a few changes to the Debian LLVM packages
(src:llvm-project-14 and friends) with regards to WebAssembly support,
and so you could say I'm interested with helping in bringing more parts
of the WebAssembly ecosystem in Debian :) I'm also interested in
opportunities to help each other, and in the relevant packages working
well with each other and/or providing a unified experience. Let me know
if you can think of any such ways.

On that note, you may be interested in (and/or subscribing to) #1033322.

Regards,
Faidon

Bug#1041470: Acknowledgement (RFP: gnome-crosswords -- crossword player and editor)

[Trent W. Buck]

I have a bare-minimum packaging working (below).
The libipuz stuff is a total mess, but enough to at least run the app.
If I do any more work on it (unlikely) it'll end up at
https://github.com/cyberitsolutions/bootstrap2020/tree/twb/debian-12-PrisonPC.packages


bash5$ grep -rnH ^ libipuz crosswords
libipuz/debian/source/format:1:3.0 (quilt)
libipuz/debian/rules:1:#!/usr/bin/make -f
libipuz/debian/rules:2:export DEB_BUILD_MAINT_OPTIONS = hardening=+all
libipuz/debian/rules:3:%:
libipuz/debian/rules:4: dh $@
libipuz/debian/control:1:Source: libipuz
libipuz/debian/control:2:Section: games
libipuz/debian/control:3:Priority: optional
libipuz/debian/control:4:Homepage: https://gitlab.gnome.org/jrb/libipuz/
libipuz/debian/control:5:Standards-Version: 4.5.1
libipuz/debian/control:6:Maintainer: Trent W. Buck 
libipuz/debian/control:7:Rules-Requires-Root: no
libipuz/debian/control:8:Build-Depends: debhelper-compat (= 13),
libipuz/debian/control:9: meson (>= 0.59.0),
libipuz/debian/control:10: pkg-config,
libipuz/debian/control:11: python3,
libipuz/debian/control:12: libglib2.0-dev,
libipuz/debian/control:13: libjson-glib-dev,
libipuz/debian/control:14: cmake,
libipuz/debian/control:15:
libipuz/debian/control:16:Package: libipuz-1
libipuz/debian/control:17:Depends:
libipuz/debian/control:18: ${misc:Depends},
libipuz/debian/control:19: ${shlibs:Depends},
libipuz/debian/control:20:Architecture: any
libipuz/debian/control:21:Description: FIXME
libipuz/debian/control:22: FIXME
libipuz/debian/changelog:1:libipuz (0.4.2-1) bookworm; urgency=medium
libipuz/debian/changelog:2:
libipuz/debian/changelog:3:  * Initial Debianization.
libipuz/debian/changelog:4:
libipuz/debian/changelog:5: -- Trent W. Buck   Thu, 25 
Aug 2022 20:19:14 +1000
libipuz/debian/watch:1:# Stolen from 
https://sources.debian.org/src/gucharmap/1:14.0.3-1/debian/watch/
libipuz/debian/watch:2:version=4
libipuz/debian/watch:3:https://gitlab.gnome.org/jrb/@PACKAGE@/tags \
libipuz/debian/watch:4:  .*/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
libipuz/debian/copyright:1:Files: *
libipuz/debian/copyright:2:Copyright: 2021 Trent W. Buck
libipuz/debian/copyright:3:License: expat
libipuz/debian/copyright:4:
libipuz/debian/copyright:5:License: expat
libipuz/debian/copyright:6: Permission is hereby granted, free of charge, 
to any person obtaining
libipuz/debian/copyright:7: a copy of this software and associated 
documentation files (the
libipuz/debian/copyright:8: "Software"), to deal in the Software without 
restriction, including
libipuz/debian/copyright:9: without limitation the rights to use, copy, 
modify, merge, publish,
libipuz/debian/copyright:10: distribute, sublicense, and/or sell copies of 
the Software, and to
libipuz/debian/copyright:11: permit persons to whom the Software is 
furnished to do so, subject to
libipuz/debian/copyright:12: the following conditions:
libipuz/debian/copyright:13: .
libipuz/debian/copyright:14: The above copyright notice and this permission 
notice shall be included
libipuz/debian/copyright:15: in all copies or substantial portions of the 
Software.
libipuz/debian/copyright:16: .
libipuz/debian/copyright:17: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT 
WARRANTY OF ANY KIND,
libipuz/debian/copyright:18: EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 
TO THE WARRANTIES OF
libipuz/debian/copyright:19: MERCHANTABILITY, FITNESS FOR A PARTICULAR 
PURPOSE AND NONINFRINGEMENT.
libipuz/debian/copyright:20: IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT 
HOLDERS BE LIABLE FOR ANY
libipuz/debian/copyright:21: CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN 
AN ACTION OF CONTRACT,
libipuz/debian/copyright:22: TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
CONNECTION WITH THE
libipuz/debian/copyright:23: SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
crosswords/debian/copyright:1:Files: *
crosswords/debian/copyright:2:Copyright: 2021 Trent W. Buck
crosswords/debian/copyright:3:License: expat
crosswords/debian/copyright:4:
crosswords/debian/copyright:5:License: expat
crosswords/debian/copyright:6: Permission is hereby granted, free of 
charge, to any person obtaining
crosswords/debian/copyright:7: a copy of this software and associated 
documentation files (the
crosswords/debian/copyright:8: "Software"), to deal in the Software without 
restriction, including
crosswords/debian/copyright:9: without limitation the rights to use, copy, 
modify, merge, publish,
crosswords/debian/copyright:10: distribute, sublicense, and/or sell copies 
of the Software, and to
crosswords/debian/copyright:11: permit persons to whom the Software is 
furnished to do so, subject to
crosswords/debian/copyright:12: the following conditions:
crosswords/debian/copyright:13: .

Bug#1039990: [Pkg-javascript-devel] Bug#1039990: nodejs: CVE-2023-30581 CVE-2023-30588 CVE-2023-30589 CVE-2023-30590

[Moritz Mühlenhoff]

Am Fri, Jun 30, 2023 at 08:12:37PM +0200 schrieb Jérémy Lal:
> Hi,
> 
> Le ven. 30 juin 2023 à 19:21, Salvatore Bonaccorso  a
> écrit :
> 
> > Source: nodejs
> > Version: 18.13.0+dfsg1-1
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team <
> > t...@security.debian.org>
> >
> > Hi,
> >
> > The following vulnerabilities were published for nodejs.
> >
> > CVE-2023-30581[0], CVE-2023-30588[1], CVE-2023-30589[2] and
> > CVE-2023-30590[3].
> >
> >
> > If you fix the vulnerabilities please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> >
> 
> It would be interesting to know if we adopt the same plan we had with
> security team:
> full upstream updates in the same branch, 18.x here.

Ack, let's do that. Could you prepare bookworm-security updates
based on 18.17.0 (after it has landed in unstable)?

Cheers,
Moritz

Bug#1041260: wike: BD-Uninstallable: libadwaita-1-dev:amd64 (>= 1.3)

[Jeremy Bícha]

On Sun, Jul 16, 2023 at 1:33 PM Sebastian Ramacher  wrote:
 Yes, sure. But all this sounds like nobody actually tested the uploaded
> wike version. The uploads should have gone to experimental …

I believe it was tested on a system that had libadwaita from
Experimental installed. Anyway, we're uploading libadwaita-1 to
Unstable now.

Thank you,
Jeremy Bícha

Bug#1041478: pymca: depends on python2

[Andreas Beckmann]

Package: pymca
Version: 5.8.7+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   pymca : Depends: python2:any but it is not installable


Cheers,

Andreas

Bug#1041227: transition: suitesparse

[Sebastian Ramacher]

On 2023-07-19 13:37:44 +0200, Sébastien Villemot wrote:
> Le dimanche 16 juillet 2023 à 18:50 +0200, Sebastian Ramacher a écrit :
> > On 2023-07-15 23:25:28 +0200, Sébastien Villemot wrote:
> > > Please schedule a transition for suitesparse 7, which currently sits in
> > > experimental.
> > 
> > Please go ahead.
> 
> Thanks for driving this transition so far.
> 
> I have noticed the build failures of octave on 32-bit architectures
> (that you reported in #1041460).
> 
> Actually, it turns out that suitesparse 7 is partly broken on 32-bit
> architectures. Contrarily to what I said previously, there is an ABI
> change on 32-bit architectures. And due to the way that this ABI change
> was performed, it had the unintended consequence of breaking libspqr3
> (provided by src:suitesparse) on 32-bit architectures. Upstream
> realized this too late (and did not make much publicity around it, so I
> was not aware of the issue before starting the transition).
> 
> Upstream seems to be working on a fix, but at this point there is none
> available. The only affected package seems to be octave, for which
> there is a workaround (disabling libspqr use on 32-bit archs, which
> implies that some functionalities won’t be available there). I hope
> this situation is only temporary.

Let's try this workaround until upstream has the fix ready.

Cheers
-- 
Sebastian Ramacher

Bug#1041443: [Debian-pan-maintainers] Bug#1041443: pyfai_2023.5.0+dfsg1-3_all-buildd.changes REJECTED

[PICCA Frederic-Emmanuel]

> I am just the messenger here, if you disagree, please feel free to
> contact ftpmasters or lintian maintainers.

This was not a rant about this, I just wanted to understand what is going on :).

> Your package has been built successfully on (some) buildds, but then the
> binaries upload got rejected by dak, that's why they are still in
> "Uploaded" state. Overall it's just like if pyfai hasn't been built or
> fails to build from source.

So until a new upstream source is available with other timestamp, it will not 
be uploadable.

In you opinion, can we discuss about this on debian-devel ?


Cheers

Fred

Bug#1041227: transition: suitesparse

[Sébastien Villemot]

Le dimanche 16 juillet 2023 à 18:50 +0200, Sebastian Ramacher a écrit :
> On 2023-07-15 23:25:28 +0200, Sébastien Villemot wrote:
> > Please schedule a transition for suitesparse 7, which currently sits in
> > experimental.
> 
> Please go ahead.

Thanks for driving this transition so far.

I have noticed the build failures of octave on 32-bit architectures
(that you reported in #1041460).

Actually, it turns out that suitesparse 7 is partly broken on 32-bit
architectures. Contrarily to what I said previously, there is an ABI
change on 32-bit architectures. And due to the way that this ABI change
was performed, it had the unintended consequence of breaking libspqr3
(provided by src:suitesparse) on 32-bit architectures. Upstream
realized this too late (and did not make much publicity around it, so I
was not aware of the issue before starting the transition).

Upstream seems to be working on a fix, but at this point there is none
available. The only affected package seems to be octave, for which
there is a workaround (disabling libspqr use on 32-bit archs, which
implies that some functionalities won’t be available there). I hope
this situation is only temporary.

There are two other reverse dependencies of libspqr (petsc and apbs)
but so far they don’t seem to be affected (they probably are to some
extent, but at least no FTBFS or autopkgtest failure in sight).

Ideally I should have waited longer before starting this transition but
it’s now too late (unless you think that the transition should be
rolled back, though that seems a bit extreme given the limited extent
of the breakage; in particular, 32-bit archs are probably not used that
much for number crunching these days).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1041477: php-net-ftp: PHP Fatal error with Bookworm PHP 8.2

[Benjamin Renard]

Package: php-net-ftp
Version: 1:1.4.0-2.1
Severity: important

Dear Maintainer,

This package seem not compatible with the PHP 8.2 version included in
Debian Bookworn. I have the following PHP Fatal error when including the
/usr/share/php/Net/FTP.php file:

PHP Fatal error:  Array and string offset access syntax with curly braces
is no longer supported in /usr/share/php/Net/FTP.php on line 1181

This problem could be quickly fixed:

https://github.com/pear/Net_FTP/pull/9/commits/b8d35f51815619460daa67bbed67dda3f96ed1b5

Furthermore, we have PHP warnings about the $case_insensitive parameter
of define function:

PHP Warning:  define(): Argument #3 ($case_insensitive) is ignored since 
declaration of case-insensitive constants is no longer supported in 
/usr/share/php/Net/FTP.php on line 34
PHP Warning:  define(): Argument #3 ($case_insensitive) is ignored since 
declaration of case-insensitive constants is no longer supported in 
/usr/share/php/Net/FTP.php on line 43
PHP Warning:  define(): Argument #3 ($case_insensitive) is ignored since 
declaration of case-insensitive constants is no longer supported in 
/usr/share/php/Net/FTP.php on line 52
PHP Warning:  define(): Argument #3 ($case_insensitive) is ignored since 
declaration of case-insensitive constants is no longer supported in 
/usr/share/php/Net/FTP.php on line 61
PHP Warning:  define(): Argument #3 ($case_insensitive) is ignored since 
declaration of case-insensitive constants is no longer supported in 
/usr/share/php/Net/FTP.php on line 71
PHP Warning:  define(): Argument #3 ($case_insensitive) is ignored since 
declaration of case-insensitive constants is no longer supported in 
/usr/share/php/Net/FTP.php on line 83

This could be also quickly fixed:

https://github.com/pear/Net_FTP/pull/9/commits/d5a2bda1e3418c4c0a397f25afffb072d7f964d5

Regards,

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages php-net-ftp depends on:
ii  php-common  2:93

php-net-ftp recommends no packages.

php-net-ftp suggests no packages.

-- no debconf information

Bug#1041476: systemd: keep 254-rcX out of testing

[Luca Boccassi]

Source: systemd
Version: 254~rc2-3
Severity: grave

Let's avoid having release candidates reach testing, even after
autopkgtest is happy. Apparently setting the urgency in the changelog
entry does not work anymore...

-- 
Kind regards,
Luca Boccassi


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

Bug#1041471: src:isa-support: fails to migrate to testing for too long: new autopkgtest fails on armel

[roucaries bastien]

Hi Paul,

It is a regression on qemu. I will disable the test but I will prefer
qemu fixed.

I could not reproduce on porter box, I get another qemu bug...

Who is the specialist of qemu ?

Bastien

Le mer. 19 juil. 2023 à 10:45, Paul Gevers  a écrit :
>
> Source: isa-support
> Version: 15.1
> Severity: serious
> Control: close -1 19
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
> Dear maintainer(s),
>
> The Release Team considers packages that are out-of-sync between testing
> and unstable for more than 30 days as having a Release Critical bug in
> testing [1]. Your package src:isa-support has been trying to migrate for
> 31 days [2]. Hence, I am filing this bug. The version in unstable added
> an autopkgtest that segfaults on armel. (Just for your info in case it's
> relevant, the ci.debian.net armel VM's run on arm64 hardware.)
>
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that
> hamper the migration of their package in a timely manner.
>
> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.
>
> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and trixie, so
> it doesn't affect (old-)stable.
>
> If you believe your package is unable to migrate to testing due to
> issues beyond your control, don't hesitate to contact the Release Team.
>
> Paul
>
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
> [2] https://qa.debian.org/excuses.php?package=isa-support

Bug#1041475: bullseye-pu: package hnswlib/0.4.0-3+deb11u1

[Étienne Mollier]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hnsw...@packages.debian.org
Control: affects -1 + src:hnswlib

Hi,

[ Reason ]
hnswlib is affected by CVE-2023-37365 marked no-dsa, documented
through the important bug #1041426.  Quoting the CVE for short:
hnswlib has a double free in init_index when the M argument is a
large integer.

[ Impact ]
Users of hnswlib may encounter double-free crashes when
specifying randomly the M parameters to the software.

[ Tests ]
I verified the package built in a clean bullseye chroot, then
verified there were no autopkgtest regressions in bullseye, then
verified manualy that the reproducer did trigger the crash with
the current version in bullseye, and finally that the patched
version did not trigger the crash anymore, but instead raised
the warning message appropriately.

[ Risks ]
There is little risk as the change is relatively straightforward
but users who might like to set off-specifications values of the
M parameter may run into the self imposed limitation.  M is
documented to have values that make sense in a range from 2 to
100, and the patch sets a hard limit at 1 per upstream
recommendation.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in oldstable
  [*] the issue is verified as fixed in unstable

[ Changes ]
Changes mostly consists in applying a version of the patch
discussed with upstream[1] ported to hnswlib 0.4.0-3 in
bullseye.  Instead of forwarding the value of the argument M
as-is, the code now checks for the value to be lesser than 1
before applying.  If the value is larger, then it is capped and
the library issues a warning.

[1]: https://github.com/nmslib/hnswlib/pull/484

[ Other info ]
It might have made sense to also set a check for M == 1, as it
will result in a crash, probably not as serious as the double
free though:

Traceback (most recent call last):
  File "", line 1, in 
RuntimeError: Not enough memory: addPoint failed to allocate linklist

M == 0 looks to behave, or has a special meaning.  In doubt, I
prefer leaving as-is.

I didn't notice lintian errors about the bullseye distribution,
contrary to the bookworm side.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/4, please excuse my verbosity
   `-on air: Mile Marker Zero - Reaping Tide
diff -Nru hnswlib-0.4.0/debian/changelog hnswlib-0.4.0/debian/changelog
--- hnswlib-0.4.0/debian/changelog  2020-11-10 23:06:36.0 +0100
+++ hnswlib-0.4.0/debian/changelog  2023-07-19 11:07:28.0 +0200
@@ -1,3 +1,12 @@
+hnswlib (0.4.0-3+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * cve-2023-37365.patch: new: fix CVE-2023-37365.
+This is done by capping M to 1 per discussion with upstream.
+(Closes: #1041426)
+
+ -- Étienne Mollier   Wed, 19 Jul 2023 11:07:28 +0200
+
 hnswlib (0.4.0-3) unstable; urgency=medium
 
   * Team Upload.
diff -Nru hnswlib-0.4.0/debian/patches/cve-2023-37365.patch 
hnswlib-0.4.0/debian/patches/cve-2023-37365.patch
--- hnswlib-0.4.0/debian/patches/cve-2023-37365.patch   1970-01-01 
01:00:00.0 +0100
+++ hnswlib-0.4.0/debian/patches/cve-2023-37365.patch   2023-07-19 
11:04:35.0 +0200
@@ -0,0 +1,40 @@
+Description: hnswalg.h: cap M to 1 (CVE-2023-37365)
+ This patch works around issue nmslib#467, also referenced as CVE-2023-37365,
+ by implementing Yury Malkov's suggestion about capping the M value,
+ coding the maximum number of outgoing connections in the graph, to a
+ reasonable enough value of the order of 1.  For the record, the
+ documentation indicates reasonable values for M range from 2 to 100,
+ which are well within the cap; see ALGO_PARAMS.md.
+ .
+ The reproducer shown in issue nmslib#467 doesn't trigger the double free
+ condition anymore after this change is applied, but completes
+ successfully, although with the below warning popping up on purpose:
+ .
+  warning: M parameter exceeds 1 which may lead to adverse effects.
+   Cap to 1 will be applied for the rest of the processing.
+
+Author: Étienne Mollier 
+Bug: https://github.com/nmslib/hnswlib/issues/467
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041426
+Forwarded: https://github.com/nmslib/hnswlib/pull/484
+Reviewed-by: Yury Malkov 
+Last-Update: 2023-07-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- hnswlib.orig/hnswlib/hnswalg.h
 hnswlib/hnswlib/hnswalg.h
+@@ -34,7 +34,13 @@
+ data_size_ = s->get_data_size();
+ fstdistfunc_ = s->get_dist_func();
+ dist_func_param_ = s->get_dist_func_param();
+-M_ = M;
++if ( M <= 1 ) {
++M_ = M;
++} else {
++

Bug#1041443: [Debian-pan-maintainers] Bug#1041443: pyfai_2023.5.0+dfsg1-3_all-buildd.changes REJECTED

[Aurelien Jarno]

Hi,

On 2023-07-19 11:24, PICCA Frederic-Emmanuel wrote:
> ok, it seems that I generated an orig.tag.gz with this (Thu Jan  1 00:00:00 
> 1970).
> 
> I can not remember which tool I used to generate this file.
> 
> gbp import-orig --uscan
> 
> or
> 
> deb-new-upstream

I am just the messenger here, if you disagree, please feel free to
contact ftpmasters or lintian maintainers.

> Nevertheless, why is it a serious bug ?

Your package has been built successfully on (some) buildds, but then the
binaries upload got rejected by dak, that's why they are still in
"Uploaded" state. Overall it's just like if pyfai hasn't been built or
fails to build from source.

Regards
Aurelien

[1] https://buildd.debian.org/status/package.php?p=pyfai

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1041474: intel-gmmlib: FTBFS on i386: error: ambiguating new declaration of ‘GMM_STATUS GmmLib::GmmMultiAdapterContext::LockMAContextSyncMutex()’

[Andreas Beckmann]

Source: intel-gmmlib
Version: 22.3.7+ds1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=intel-gmmlib=i386=22.3.7%2Bds1-1=1688230619=0

[ 53%] Building CXX object 
Source/GmmLib/CMakeFiles/igfx_gmmumd_dll.dir/GlobalInfo/GmmInfo.cpp.o
cd /<>/obj-i686-linux-gnu/Source/GmmLib && /usr/bin/c++ 
-DGMM_LIB_DLL -DGMM_LIB_DLL_EXPORTS -DGMM_UNIFIED_LIB -DGMM_UNIFY_DAF_API 
-DISTDLIB_UMD -DSMALL_POOL_ALLOC -DUNUSED_ISTDLIB_MT -D_ATL_NO_WIN_SUPPORT 
-D__GFX_MACRO_C__ -D__GMM -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS 
-D__UMD -Digfx_gmmumd_dll_EXPORTS -I/<>/Source/GmmLib 
-I/<>/Source/GmmLib/Utility/GmmLog 
-I/<>/Source/GmmLib/inc -I/<>/Source/GmmLib/Utility 
-I/<>/Source/GmmLib/GlobalInfo 
-I/<>/Source/GmmLib/Texture 
-I/<>/Source/GmmLib/Resource 
-I/<>/Source/GmmLib/Platform -I/<>/Source/util 
-I/<>/Source/inc -I/<>/Source/inc/common 
-I/<>/Source/inc/umKmInc -I/<>/Source/install -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-reorder 
-Wsign-promo -Wnon-virtual-dtor -Wno-invalid-offsetof 
-fvisibility-inlines-hidden -fno-use-cxa-atexit -fno-rtti -fexceptions 
-fcheck-new -std=c++11 -pthread -Werror=non-virtual-dtor -O3 -DNDEBUG -fPIC 
-Wall -Winit-self -Winvalid-pch -Wpointer-arith -Wno-unused 
-Wno-unknown-pragmas -Wno-comments -Wno-narrowing -Wno-overflow 
-Wno-parentheses -Wno-missing-braces -Wno-sign-compare -Wno-enum-compare 
-Werror=address -Werror=format-security -Werror=return-type -march=corei7 
-mpopcnt -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -mfpmath=sse 
-finline-functions -fno-short-enums -Wa,--noexecstack -fno-strict-aliasing 
-DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -fstack-protector 
-fdata-sections -ffunction-sections -fmessage-length=0 -fvisibility=hidden 
-fPIC -g -m32 -funswitch-loops -Wl,--no-undefined -Wl,--no-as-needed 
-Wl,--gc-sections -O2 -fno-omit-frame-pointer -finline-limit=100 -MD -MT 
Source/GmmLib/CMakeFiles/igfx_gmmumd_dll.dir/GlobalInfo/GmmInfo.cpp.o -MF 
CMakeFiles/igfx_gmmumd_dll.dir/GlobalInfo/GmmInfo.cpp.o.d -o 
CMakeFiles/igfx_gmmumd_dll.dir/GlobalInfo/GmmInfo.cpp.o -c 
/<>/Source/GmmLib/GlobalInfo/GmmInfo.cpp
/<>/Source/GmmLib/GlobalInfo/GmmInfo.cpp:628:24: error: 
ambiguating new declaration of ‘GMM_STATUS 
GmmLib::GmmMultiAdapterContext::LockMAContextSyncMutex()’
  628 | GMM_STATUS GMM_STDCALL 
GmmLib::GmmMultiAdapterContext::LockMAContextSyncMutex()
  |^~
In file included from 
/<>/Source/GmmLib/inc/External/Common/GmmInfoExt.h:25,
 from 
/<>/Source/GmmLib/inc/../Texture/GmmTexture.h:27,
 from 
/<>/Source/GmmLib/inc/Internal/Common/GmmLibInc.h:52,
 from /<>/Source/GmmLib/GlobalInfo/GmmInfo.cpp:23:
/<>/Source/GmmLib/inc/External/Common/GmmInfo.h:630:41: note: old 
declaration ‘GMM_STATUS 
GmmLib::GmmMultiAdapterContext::LockMAContextSyncMutex()’
  630 | GMM_STATUS  LockMAContextSyncMutex();
  | ^~
/<>/Source/GmmLib/GlobalInfo/GmmInfo.cpp:639:24: error: 
ambiguating new declaration of ‘GMM_STATUS 
GmmLib::GmmMultiAdapterContext::UnLockMAContextSyncMutex()’
  639 | GMM_STATUS GMM_STDCALL 
GmmLib::GmmMultiAdapterContext::UnLockMAContextSyncMutex()
  |^~
/<>/Source/GmmLib/inc/External/Common/GmmInfo.h:631:41: note: old 
declaration ‘GMM_STATUS 
GmmLib::GmmMultiAdapterContext::UnLockMAContextSyncMutex()’
  631 | GMM_STATUS  UnLockMAContextSyncMutex();
  | ^~~~
make[3]: *** [Source/GmmLib/CMakeFiles/igfx_gmmumd_dll.dir/build.make:527: 
Source/GmmLib/CMakeFiles/igfx_gmmumd_dll.dir/GlobalInfo/GmmInfo.cpp.o] Error 1


Andreas

Bug#1041473: O: autofdo -- AutoFDO Profile Toolchain

[Matthias Klose]

Package: wnpp

see https://tracker.debian.org/pkg/autofdo

no new upstream releases for some years

Bug#1037546: Uploaded to unstable

[Christian Ehrhardt]

Hi,
just as FYI I've not got any response from Bernd on IRC, bug, salsa so
I went ahead and uploaded this.

Bryce will soon merge this in Ubuntu and go through some deeper
testing together with vmware - so we should soon know if any issue
hides and needs to be fixed.

-- 
Christian Ehrhardt
Senior Staff Engineer and acting Director, Ubuntu Server
Canonical Ltd

Bug#1041472: src:lmfit-py: fails to migrate to testing for too long: autopkgtest regression on i386

[Paul Gevers]

Source: lmfit-py
Version: 1.1.0-1
Severity: serious
Control: close -1 1.2.1-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:lmfit-py has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The autopkgtest of the version in 
unstable fails on i386, where it passed in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=lmfit-py



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041471: src:isa-support: fails to migrate to testing for too long: new autopkgtest fails on armel

[Paul Gevers]

Source: isa-support
Version: 15.1
Severity: serious
Control: close -1 19
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:isa-support has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable added 
an autopkgtest that segfaults on armel. (Just for your info in case it's 
relevant, the ci.debian.net armel VM's run on arm64 hardware.)


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=isa-support


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

Hi Leo,

I hope you are well. Now that all dependencies to build this package are
in place, I've taken the liberty of uploading the package to
debian/experimental and pushed my sources to
https://salsa.debian.org/go-team/packages/golang-github-sigstore-sigstore

I really don't want this to be seen as an ITP takeover, since we've been
talking on this ITP for a while, I hope that's okay. Please take a look at
this repo and at
https://ftp-master.debian.org/new/golang-github-sigstore-sigstore_1.4.0-1.html
and let me know what you think.

Best,
-rt

-- 
regards,
Reinhard

Bug#1041470: RFP: gnome-crosswords -- crossword player and editor

[Trent W. Buck]

Package: wnpp
Severity: wishlist

* Package name: gnome-crosswords
  Version : 0.3.4
  Upstream Contact: Jonathan Blandford?
* URL : https://gitlab.gnome.org/jrb/crosswords
* License : GPL3
  Programming Lang: C
  Description : crossword player and editor

Features:

 • Uses .ipuz files internally and supports a significant chunk of the open 
.ipuz spec for crosswords
 • Supports cryptic, barred, arrowword, filippine, and rebus-style puzzles
 • Loads .ipuz, .puz, and .jpz files from disk
 • Supports standalone puzzle collections of crosswords with multiple ways of 
playing them
 • External puzzle set downloaders can be used to download puzzles
 • Extensive styling support for crosswords. Square, black and white crosswords 
are traditional, but this game can also take advantage of color and shapes
 • Reveal button to find mistakes in the puzzle
 • Hint button to suggest possible answers using Peter Broda's Wordlist
 • Puzzle checksums for puzzles that don't include an answer
 • Respects the Desktop-wide dark-mode preference
 • Language-specific quirks
 • Adaptive sizing to let it work on tablets or mobile form-factors

While Debian has crossword puzzle apps, they're all very dated.
They are mostly using Xlib or Xaw so they look unpleasant.

This depends on libipuz-dev from the same author, so
that would have to be packaged at the same time.
https://gitlab.gnome.org/jrb/libipuz

I suppose technically that should also have an RFP, but
I don't think it has any use beyond "so I can have gnome-crosswords".

Bug#1041469: cloudcompare: Please enable CGAL support

[Tobias Ellinghaus]

Package: cloudcompare
Version: 2.13~git20230616+ds-1
Severity: wishlist
X-Debbugs-Cc: t_ellingh...@gmx.de

Dear Maintainer,

please enable support for CGAL (passing `-DCCCORELIB_USE_CGAL=On` to cmake
might be enough) so that meshing of point clouds works.

Thanks in advance,
Tobias


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

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

Versions of packages cloudcompare depends on:
ii  libc62.37-5
ii  libgcc-s113.1.0-8
ii  libgl1   1.6.0-1
ii  libglu1-mesa [libglu1]   9.0.2-1.1
ii  libgomp1 13.1.0-8
ii  liblz4-1 1.9.4-1
ii  libpcl-common1.131.13.0+dfsg-3
ii  libpcl-features1.13  1.13.0+dfsg-3
ii  libpcl-filters1.13   1.13.0+dfsg-3
ii  libpcl-io1.131.13.0+dfsg-3
ii  libpcl-registration1.13  1.13.0+dfsg-3
ii  libpcl-search1.131.13.0+dfsg-3
ii  libpcl-segmentation1.13  1.13.0+dfsg-3
ii  libpcl-surface1.13   1.13.0+dfsg-3
ii  libqt5concurrent55.15.10+dfsg-2
ii  libqt5core5a 5.15.10+dfsg-2
ii  libqt5gui5   5.15.10+dfsg-2
ii  libqt5opengl55.15.10+dfsg-2
ii  libqt5printsupport5  5.15.10+dfsg-2
ii  libqt5widgets5   5.15.10+dfsg-2
ii  libstdc++6   13.1.0-8
ii  zlib1g   1:1.2.13.dfsg-1

cloudcompare recommends no packages.

cloudcompare suggests no packages.

-- no debconf information

Bug#1041468: bookworm-pu: package hnswlib/0.6.2-2+deb12u1

[Étienne Mollier]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hnsw...@packages.debian.org
Control: affects -1 + src:hnswlib

Hi Stable Release Managers,

[ Reason ]
hnswlib is affected by CVE-2023-37365 marked no-dsa, documented
through the important bug #1041426.  Quoting the CVE for short:
hnswlib has a double free in init_index when the M argument is a
large integer.

[ Impact ]
Users of hnswlib may encounter double-free crashes when
specifying randomly the M parameters to the software.

[ Tests ]
I verified the package built in a clean bookworm chroot, then
verified there were no autopkgtest regressions in bookworm, then
verified manualy that the reproducer did trigger the crash with
the current version in bookworm, and finally that the patched
version did not trigger the crash anymore, but instead raised
the warning message appropriately.

[ Risks ]
There is little risk as the change is relatively straightforward
but users who might like to set off-specifications values of the
M parameter may run into the self imposed limitation.  M is
documented to have values that make sense in a range from 2 to
100, and the patch sets a hard limit at 1 per upstream
recommendation.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in stable
  [*] the issue is verified as fixed in unstable

[ Changes ]
Changes mostly consists in applying a version of the patch
discussed with upstream[1] ported to hnswlib 0.6.2-2 in
bookworm.  Instead of forwarding the value of the argument M
as-is, the code now checks for the value to be lesser than 1
before applying.  If the value is larger, then it is capped and
the library issues a warning.

[1]: https://github.com/nmslib/hnswlib/pull/484

[ Other info ]
It might have made sense to also set a check for M == 1, as it
will result in a crash, probably not as serious as the double
free though:

Traceback (most recent call last):
  File "", line 1, in 
RuntimeError: Not enough memory: addPoint failed to allocate linklist

M == 0 looks to behave, or has a special meaning.  In doubt, I
prefer leaving as-is.

Last info, lintian loudly complained at the distribution field,
but looking at the Developer Reference, the field seemed good,
so if there is anything I need to change, don't hesitate to
tell:

E: hnswlib changes: bad-distribution-in-changes-file bookworm

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/4, please excuse my verbosity
   `-on air: Chroma Key - Human Love
diff -Nru hnswlib-0.6.2/debian/changelog hnswlib-0.6.2/debian/changelog
--- hnswlib-0.6.2/debian/changelog  2022-10-12 16:11:36.0 +0200
+++ hnswlib-0.6.2/debian/changelog  2023-07-19 10:27:07.0 +0200
@@ -1,3 +1,12 @@
+hnswlib (0.6.2-2+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * cve-2023-37365.patch: new: fix CVE-2023-37365.
+This is done by capping M to 1 per discussion with upstream.
+(Closes: #1041426)
+
+ -- Étienne Mollier   Wed, 19 Jul 2023 10:27:07 +0200
+
 hnswlib (0.6.2-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru hnswlib-0.6.2/debian/patches/cve-2023-37365.patch 
hnswlib-0.6.2/debian/patches/cve-2023-37365.patch
--- hnswlib-0.6.2/debian/patches/cve-2023-37365.patch   1970-01-01 
01:00:00.0 +0100
+++ hnswlib-0.6.2/debian/patches/cve-2023-37365.patch   2023-07-19 
10:24:55.0 +0200
@@ -0,0 +1,40 @@
+Description: hnswalg.h: cap M to 1 (CVE-2023-37365)
+ This patch works around issue nmslib#467, also referenced as CVE-2023-37365,
+ by implementing Yury Malkov's suggestion about capping the M value,
+ coding the maximum number of outgoing connections in the graph, to a
+ reasonable enough value of the order of 1.  For the record, the
+ documentation indicates reasonable values for M range from 2 to 100,
+ which are well within the cap; see ALGO_PARAMS.md.
+ .
+ The reproducer shown in issue nmslib#467 doesn't trigger the double free
+ condition anymore after this change is applied, but completes
+ successfully, although with the below warning popping up on purpose:
+ .
+  warning: M parameter exceeds 1 which may lead to adverse effects.
+   Cap to 1 will be applied for the rest of the processing.
+
+Author: Étienne Mollier 
+Bug: https://github.com/nmslib/hnswlib/issues/467
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041426
+Forwarded: https://github.com/nmslib/hnswlib/pull/484
+Reviewed-by: Yury Malkov 
+Last-Update: 2023-07-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- hnswlib.orig/hnswlib/hnswalg.h
 hnswlib/hnswlib/hnswalg.h
+@@ -33,7 +33,13 @@
+ data_size_ = s->get_data_size();
+ fstdistfunc_ = s->get_dist_func();
+  

Bug#1041467: sanlock: systemd service uses unsupported option "watchdog-check"

[Lars Dröge]

Package: sanlock
Severity: important
Justification: renders package unusable

Dear Maintainer,

thank you for maintaining the sanlock package. I may have found a version 
mismatch in the included wdmd.service file and a lib.

   * What led up to the situation?
 Try to start the wdmd.service, as it was not succesfully pulled in by 
sanlock.service.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 systemctl start wdmd.service
   * What was the outcome of this action?
 Error message: Usage: /etc/init.d/wdmd {start|stop|status|restart}
   * What outcome did you expect instead?
 wdmd.service starts

The wdmd.service contains this line in the [Service] section:

  ExecStartPre=/lib/systemd/systemd-wdmd watchdog-check

But /lib/systemd/systemd-wdmd does not support the argument "watchdog-check", 
and throws an error instead.
All related files are part of the sanlock package.

I have found this behavior in
  - sanlock 3.8.2-2 in Debian Bullseye
  - sanlock 3.8.5-1+b1 in Debian Bookworm

Is it safe to remove the ExecStartPre= line and skip the check?

Best regards,
Lars


-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages sanlock depends on:
ii  adduser  3.134
ii  init-system-helpers  1.65.2
ii  libaio1  0.3.113-4
ii  libblkid12.38.1-5+b1
ii  libc62.36-9
pn  libsanlock1  
ii  libuuid1 2.38.1-5+b1

sanlock recommends no packages.

Versions of packages sanlock suggests:
pn  python3-sanlock  
pn  sanlk-reset  

Bug#1040767: facter: inconsistent detection of Xen dom0

[Sergio Gelato]

systemd has a similar issue, tracked in #1038901. (Maybe one should ask the 
virt-what maintainers whether they agree with 
https://github.com/systemd/systemd/issues/28113#issuecomment-1621986461, in 
which case this bug can be reassigned to virt-what.)

Bug#1041464: debian-policy: make Uploaders field optional for team-maintained packages

[Sean Whitton]

Hello,

On Wed 19 Jul 2023 at 10:48am +01, Luca Boccassi wrote:

> Thanks, I skimmed through that long discussion and it seems to me it
> went nowhere. I don't think there's any benefit in attempting to just
> restart it. What about escalating to the CTTE and ask them to make a
> decision? That way the matter can be closed one way or the other.

That would be a premature escalation -- if you want to drive this,
please approach the MIA team.

-- 
Sean Whitton

Bug#1041466: printer-driver-gutenprint: Canon MG3500: CMYK mode is not working anymore

[Georges Gouriten]

Package: printer-driver-gutenprint
Version: 5.3.4.20220624T01008808d602-1
Severity: important
X-Debbugs-Cc: georges.gouriten.pub...@gmail.com

Dear Maintainer,

I recently updated my packages and the Gutenprint driver for my Canon MG3500 is
not working anymore.

I checked the configuration through Cups, the default options are fine, and
especially General > Color Model > CMYK.

However, it does not work properly anymore. If I want to print a document from
okular, for instance, if I go to Properties > Avanced > Color Model, it is set
on Grayscale, not CMYK, same thing for Libreoffice.

And, even if I manually change the model to CMYK, it still prints black and
white.

The RGB model works, but the colors are not good.

I tried reinstalling the package and rebooting/rebooting the printer, but it
does not change a thing.

I have reverted to the old "IJ Printer Driver Ver. 4.00" at the moment, but this
is not great.

Any way to fix this?

Best

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages printer-driver-gutenprint depends on:
ii  cups 2.4.2-3
ii  cups-client  2.4.2-3
ii  cups-filters [ghostscript-cups]  1.28.17-3
ii  libc62.36-9
ii  libcups2 2.4.2-3
ii  libgutenprint9   5.3.4.20220624T01008808d602-1
ii  libusb-1.0-0 2:1.0.26-1
ii  zlib1g   1:1.2.13.dfsg-1

printer-driver-gutenprint recommends no packages.

Versions of packages printer-driver-gutenprint suggests:
pn  gutenprint-doc  
pn  gutenprint-locales  

-- no debconf information

Bug#1041464: debian-policy: make Uploaders field optional for team-maintained packages

[Luca Boccassi]

On Wed, 19 Jul 2023 at 10:26, Sean Whitton  wrote:
>
> control: forcemerge 798476 1041464
>
> Hello,
>
> On Wed 19 Jul 2023 at 10:18am +01, Luca Boccassi wrote:
>
> > Assigning ownership to individuals deters group and team maintenance,
> > as other team members will feel like they are overstepping when working
> > on a package for which other people are marked as Uploaders.
> >
> > In order to remove all barriers to team contributions and maintenance,
> > make the 'Uploaders' field optional instead of mandatory when the
> > 'Maintainer' is a team alias. This allows packages where we do not want
> > to assign ownership to any individual, but leave them be purely team
> > maintained, to do so.
>
> I wanted to do this some years ago, but the MIA team objected.  So you'd
> need to speak to them first.

Thanks, I skimmed through that long discussion and it seems to me it
went nowhere. I don't think there's any benefit in attempting to just
restart it. What about escalating to the CTTE and ask them to make a
decision? That way the matter can be closed one way or the other.

Kind regards,
Luca Boccassi

Bug#1041443: [Debian-pan-maintainers] Bug#1041443: Bug#1041443: pyfai_2023.5.0+dfsg1-3_all-buildd.changes REJECTED

[PICCA Frederic-Emmanuel]

I just check this date is in the upstream tar file

https://files.pythonhosted.org/packages/54/84/ea12e176489b35c4610625ce56aa2a1d91ab235b0caa71846317bfd1192f/pyfai-2023.5.0.tar.gz

Bug#1041443: [Debian-pan-maintainers] Bug#1041443: pyfai_2023.5.0+dfsg1-3_all-buildd.changes REJECTED

[PICCA Frederic-Emmanuel]

ok, it seems that I generated an orig.tag.gz with this (Thu Jan  1 00:00:00 
1970).

I can not remember which tool I used to generate this file.

gbp import-orig --uscan

or

deb-new-upstream

Nevertheless, why is it a serious bug ?

thanks

Frederic

Bug#1041464: debian-policy: make Uploaders field optional for team-maintained packages

[Sean Whitton]

control: forcemerge 798476 1041464

Hello,

On Wed 19 Jul 2023 at 10:18am +01, Luca Boccassi wrote:

> Assigning ownership to individuals deters group and team maintenance,
> as other team members will feel like they are overstepping when working
> on a package for which other people are marked as Uploaders.
>
> In order to remove all barriers to team contributions and maintenance,
> make the 'Uploaders' field optional instead of mandatory when the
> 'Maintainer' is a team alias. This allows packages where we do not want
> to assign ownership to any individual, but leave them be purely team
> maintained, to do so.

I wanted to do this some years ago, but the MIA team objected.  So you'd
need to speak to them first.

-- 
Sean Whitton

Bug#1041464: debian-policy: make Uploaders field optional for team-maintained packages

[Luca Boccassi]

Package: debian-policy

Assigning ownership to individuals deters group and team maintenance,
as other team members will feel like they are overstepping when working
on a package for which other people are marked as Uploaders.

In order to remove all barriers to team contributions and maintenance,
make the 'Uploaders' field optional instead of mandatory when the
'Maintainer' is a team alias. This allows packages where we do not want
to assign ownership to any individual, but leave them be purely team
maintained, to do so.

-- 
Kind regards,
Luca Boccassi
From  Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Wed, 19 Jul 2023 10:14:54 +0100
Subject: [PATCH] Make 'Uploaders' field optional for team maintenance

Naming people in Uploaders assigns ownership and deters team maintenance,
make the field optional
---
 policy/ch-binary.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index a03a3b8..e314168 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -164,8 +164,8 @@ The format of the ``Maintainer`` control field is described in
 :ref:`s-f-Maintainer`.
 
 If the maintainer of the package is a team of people with a shared email
-address, the ``Uploaders`` control field must be present and must
-contain at least one human with their personal email address. See
+address, the ``Uploaders`` control field can be present, in which case it
+must contain at least one human with their personal email address. See
 :ref:`s-f-Uploaders` for the syntax of that field.
 
 An orphaned package is one with no current maintainer. Orphaned packages


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

Bug#1041465: pristine-tar: pristine-xz failed to reproduce build of ../libxml2-2.11.4.tar.xz

[Aron Xu]

Package: pristine-tar
Version: 1.50
Severity: important

While importing libxml2-2.11.4.tar.xz through gbp:

$ gbp import-orig --pristine-tar ../libxml2-2.11.4.tar.xz
What is the upstream version? [2.11.4]
gbp:info: Importing '../libxml2-2.11.4.tar.xz' to branch 'upstream'...
gbp:info: Source package is libxml2
gbp:info: Upstream version is 2.11.4
gbp:error: Import of ../libxml2_2.11.4.orig.tar.xz failed: Couldn't
commit to 'pristine-tar' with upstream '96ab8ed14cb3
6463c3531d5f6f3c8c897d187d57': pristine-xz failed to reproduce build
of ../libxml2_2.11.4.orig.tar.xz
(Please file a bug report.)
pristine-tar: failed to generate delta
gbp:error: Error detected, Will roll back changes.
gbp:info: Rolling back branch upstream by resetting it to
7188a3bc963343a2dfc60c7510807e6c3c14aeda
gbp:info: Rolling back branch pristine-tar by resetting it to
96b561e8b4f167e53a88f8b68703c79d1735d6c2
gbp:error: Rolled back changes after import error.

The tarball is at
https://download.gnome.org/sources/libxml2/2.11/libxml2-2.11.4.tar.xz
And the git repository to import to:
https://salsa.debian.org/xml-sgml-team/libxml2/

Thanks,
Aron

Bug#1041367: src:emacs: Detect default GCC version instead of hard-coding.

[Sean Whitton]

Hello Manphiz,

I don't think the benefit is significant to be interested in reviewing
and applying this, though perhaps Rob will take a look.  Sorry to dissapoint.

-- 
Sean Whitton

Bug#1006551: bullseye-pu: package tiff/4.2.0-1+deb11u1

[Aron Xu]

Hi SRMs,

I think this can be closed since tiff already has the deb11u4 version
in bullseye through a previous security update.

Regards,
Aron