Bug#1018009: coinor-cbc FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: coinor-cbc
Version: 2.10.8+ds1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

coinor-cbc fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - is unfortunately not applicable, because ./configure
does not understand --runstatedir. That's probably the reason why it
isn't being used. So the next best thing is passing the flag (together
with --build) explicitly. If you happen to switch to dh_auto_configure
later for a newer configure, you can drop them. The other issue is hard
coding the build architecture strip. Once fixing both, coinor-cbc cross
builds. Please consider applying the attached patch.

Helmut
--- coinor-cbc-2.10.8+ds1/debian/changelog
+++ coinor-cbc-2.10.8+ds1/debian/changelog
@@ -1,3 +1,12 @@
+coinor-cbc (2.10.8+ds1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Pass --host to ./configure.
++ Use the host architecture strip.
+
+ -- Helmut Grohne   Wed, 24 Aug 2022 06:07:02 +0200
+
 coinor-cbc (2.10.8+ds1-1) unstable; urgency=medium
 
   * New upstream release.
--- coinor-cbc-2.10.8+ds1/debian/rules
+++ coinor-cbc-2.10.8+ds1/debian/rules
@@ -2,6 +2,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/pkg-info.mk
 
 %:
@@ -16,12 +17,13 @@
 
 override_dh_auto_configure:
./configure --prefix=/usr --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
+   --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
--enable-static --enable-cbc-parallel --enable-dot 
--enable-dependency-linking
 
 override_dh_strip:
dh_strip
find . -name '*.a' \( \! -name '*_g.a' \) \
--exec strip --strip-debug \
+-exec $(STRIP) --strip-debug \
 --remove-section=.comment \
 --remove-section=.note {} \;
 

Bug#1018008: libvdpau-va-gl FTCBFS: fails running shader-bundle-tool

[Helmut Grohne]

Source: libvdpau-va-gl
Version: 0.4.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libvdpau-va-gl fails to cross build from source, because it fails
running shader-bundle-tool. Other distributions have already recognized
that this build-time tool is not architecture-dependent and should be
built for the build architecture (e.g. voidlinux and oe). Doing so is
close to impossible with CMake (because it doesn't have a notion of
build architecture), so this patch allows providing the tool externally
and makes the Debian package construct it beforehand. The upstream
changes should be upstreamable (and improving the situation at voidlinux
and oe).  Please consider applying the whole patch.

Helmut
diff --minimal -Nru libvdpau-va-gl-0.4.2/debian/changelog 
libvdpau-va-gl-0.4.2/debian/changelog
--- libvdpau-va-gl-0.4.2/debian/changelog   2016-10-07 10:56:46.0 
+0200
+++ libvdpau-va-gl-0.4.2/debian/changelog   2022-08-22 20:37:27.0 
+0200
@@ -1,3 +1,11 @@
+libvdpau-va-gl (0.4.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build shader-bundle-tool with the build architecture
+compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 22 Aug 2022 20:37:27 +0200
+
 libvdpau-va-gl (0.4.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru libvdpau-va-gl-0.4.2/debian/clean 
libvdpau-va-gl-0.4.2/debian/clean
--- libvdpau-va-gl-0.4.2/debian/clean   1970-01-01 01:00:00.0 +0100
+++ libvdpau-va-gl-0.4.2/debian/clean   2022-08-22 20:37:25.0 +0200
@@ -0,0 +1 @@
+debian/shader-bundle-tool
diff --minimal -Nru libvdpau-va-gl-0.4.2/debian/patches/cross.patch 
libvdpau-va-gl-0.4.2/debian/patches/cross.patch
--- libvdpau-va-gl-0.4.2/debian/patches/cross.patch 1970-01-01 
01:00:00.0 +0100
+++ libvdpau-va-gl-0.4.2/debian/patches/cross.patch 2022-08-22 
20:37:27.0 +0200
@@ -0,0 +1,24 @@
+--- libvdpau-va-gl-0.4.2.orig/glsl/CMakeLists.txt
 libvdpau-va-gl-0.4.2/glsl/CMakeLists.txt
+@@ -10,13 +10,19 @@
+   list(APPEND shader_list ${CMAKE_CURRENT_SOURCE_DIR}/${item})
+ endforeach(item)
+ 
++if(SHADER_BUNDLE_TOOL_EXECUTABLE)
++  add_executable(shader-bundle-tool IMPORTED)
++  set_target_properties(shader-bundle-tool PROPERTIES IMPORTED_LOCATION 
"${SHADER_BUNDLE_TOOL_EXECUTABLE}")
++else()
++  add_executable(shader-bundle-tool shader-bundle-tool.cc)
++endif()
++
+ add_custom_command(
+   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/shaders.c 
${CMAKE_CURRENT_BINARY_DIR}/shaders.h
+-  COMMAND ${CMAKE_CURRENT_BINARY_DIR}/shader-bundle-tool 
${CMAKE_CURRENT_BINARY_DIR}/shaders.h ${CMAKE_CURRENT_BINARY_DIR}/shaders.c 
${shader_list}
++  COMMAND shader-bundle-tool ${CMAKE_CURRENT_BINARY_DIR}/shaders.h 
${CMAKE_CURRENT_BINARY_DIR}/shaders.c ${shader_list}
+   DEPENDS ${shader_list} shader-bundle-tool
+ )
+ add_custom_target(shader-bundle-src DEPENDS 
${CMAKE_CURRENT_BINARY_DIR}/shaders.c ${CMAKE_CURRENT_BINARY_DIR}/shaders.h)
+ 
+-add_executable(shader-bundle-tool shader-bundle-tool.cc)
+ add_library(shader-bundle STATIC ${CMAKE_CURRENT_BINARY_DIR}/shaders.c)
+ add_dependencies(shader-bundle shader-bundle-src)
diff --minimal -Nru libvdpau-va-gl-0.4.2/debian/patches/series 
libvdpau-va-gl-0.4.2/debian/patches/series
--- libvdpau-va-gl-0.4.2/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libvdpau-va-gl-0.4.2/debian/patches/series  2022-08-22 20:30:59.0 
+0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru libvdpau-va-gl-0.4.2/debian/rules 
libvdpau-va-gl-0.4.2/debian/rules
--- libvdpau-va-gl-0.4.2/debian/rules   2016-10-07 10:56:46.0 +0200
+++ libvdpau-va-gl-0.4.2/debian/rules   2022-08-22 20:37:27.0 +0200
@@ -1,12 +1,19 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
 export DEB_CPPFLAGS_MAINT_APPEND = -DNDEBUG
 
 %:
dh $@
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+override_dh_auto_configure:
+   $(CXX_FOR_BUILD) glsl/shader-bundle-tool.cc -o debian/shader-bundle-tool
+   dh_auto_configure -- 
-DSHADER_BUNDLE_TOOL_EXECUTABLE=$(CURDIR)/debian/shader-bundle-tool
+endif
+
 override_dh_auto_test:
# Cannot run tests without a X11 server (with VAAPI support)
 

Bug#1017075: #1017075 dask - autopkgtest regression on i386 and armhf

[Diane Trout]

On Mon, 2022-08-22 at 08:37 +0200, Graham Inggs wrote:
> Hi Drew
> 
> On Sun, 21 Aug 2022 at 19:08, Drew Parsons 
> wrote:
> > In regards to bug severity, the dask debci failures are now marked
> > as
> > "Not a regression" so they won't hold up migration of dask.
> 
> Dask's autopkgtests are failing in testing since the removal of
> scikit-learn.  I raised the severity of this bug precisely to prevent
> this accidental migration.
> 
> > Graham, should the bug severity therefore be reduced from Serious
> > back
> > down to Important to enable migration of both dask and scipy?
> 
> Please don't.


Hopefully working around the 32-bit test failures is enough to resolve
the problems for scipy?

Bug#1018007: spamass-milter: X-Spam headers are appended, not prepended

[Osric Wilkinson]

Package: spamass-milter
Version: 0.4.0-2
Severity: normal
Tags: upstream

Dear Maintainer,

spamass-milter should add its headers to the top of the existing
headers, not the bottom.

Upstream know about the problem, 
https://savannah.nongnu.org/bugs/?58234 has a patch attached but I don't
know if it's been tested/merged.

Thanks,
   Osric.

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

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

Versions of packages spamass-milter depends on:
ii  adduser 3.118
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libmilter1.0.1  8.15.2-22
ii  libstdc++6  10.2.1-6
ii  spamc   3.4.6-1

Versions of packages spamass-milter recommends:
ii  postfix   3.5.13-0+deb11u1
ii  spamassassin  3.4.6-1

spamass-milter suggests no packages.

-- Configuration Files:
/etc/default/spamass-milter changed:
OPTIONS="-u spamass-milter -e fluffypeople -I -i 127.0.0.1 -m -u -x"
SOCKET="/var/spool/postfix/spamass/spamass.sock"
SOCKETOWNER="postfix:vmail"
SOCKETMODE="0660"


-- no debconf information

Bug#1017835: elpa-evil: emacs 28.1 upgrade fails with byte compiling elpa-evil

[Nicholas D Steeves]

Dear Gregory and Cédric,

FYI evil-el has been orphaned.  It is currently in the Debian Emacsen
Team's salsa group, but it needs a new human maintainer.  See the orphan
bug at #981120, and here is its git remote (writable for team members):

  g...@salsa.debian.org:emacsen-team/evil-el.git

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1017739: emacs-lucid cannot start after upgrade

[Russ Allbery]

Stefan Monnier  writes:

> Personally I think running something like Emacs as root with $HOME
> pointing to some other user's home directory is a "pilot error", but
> then again I'm one of those who didn't notice the infamous "su" change
> because I never use `su` without `-` (because I simply don't understand
> what is its intended semantics).

To be clear, $HOME was pointing correctly at /root.  Emacs ignored $HOME
and instead created $USER/.emacs.d/eln-cache, which was surprising.  (su
without - still changes $HOME but not $USER.)

Or at least I think that's happened, and the correct thing happened when I
overrode $USER (and $LOGNAME) and then did the same thing again with
otherwise the same environment variables.

-- 
Russ Allbery (r...@debian.org)  

Bug#1017499: Upstream bug report

[Ben Westover]

tags 1017499 + upstream
--

I was about to report the bug upstream, but it looks like Leandro beat me to it.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7117

--
Ben Westover

signature.asc
Description: PGP signature

Bug#1018006: litehtml: qt6-tools does not build/link with this version

[Rob Savoury]

Package: src:litehtml
Version: 0.5-3
Severity: normal
Tags: patch

Dear Maintainer,

This package does not allow src:qt6-tools to successfully build and
link with the system litehtml library. Due no litehtmlConfig.cmake
file in litehtml 0.5 CMake cannot find this system litehtml package
for the qt6-tools builds.

Thanks to litehtml source being included in a 3rdparty directory of
src:qt6-tools that package still builds successfully even without
use of system litehtml. But building/linking with system litehtml
seems to be intended for qt6-tools due a liblitehtml-dev build
dependency included in qt6-tools (6.3.1-2) debian/control file.

Notable changes between litehtml 0.5 source and the version included
in src:qt6-tools make it easier to successfully build qt6-tools with
system litehtml by using the exact same source of litehtml as is
included with src:qt6-tools. The version included is exactly that
of commit 971eadc on 2021-10-28 [1] confirmed by doing a git clone
of litehtml at that commit, with no differences seen between that
version and litehtml source as included with src:qt6-tools.

Also of note is that the litehtml source included in both qt6-tools
versions 6.2.4 and 6.3.1 (both currently in Debian repositories) is
identical. This makes it simple to package the correct version of
src:litehtml for both of the qt6-tools versions that are currently
available to users of either Bullseye or Sid.

Packaging litehtml source from a git clone of exactly the mentioned
commit and updating CMakeLists.patch for new source changes at that
point results in qt6-tools being able to successfully build and link
with system litehtml. This is confirmed by builds of both litehtml
0.5+git20211028 and qt6-tools 6.2.4 available at a Launchpad PPA [2]
recently created to backport the Qt 6.2.x stack for Ubuntu users.

Please see the bug filed against qt6-tools [3] for additional info.
Attached is a proposed patch that applies cleanly to litehtml 0.5-3
which is intended for use against the exact version of src:litehtml
included with src:qt6-tools. This patch updates the following:

- debian/patches/CMakeLists.txt: Major rebase for litehtml > 0.5 due
  significant changes to upstream CMake logic, now also removes a
  CMake find_dependency check for gumbo (which has no CMake config)

- debian/control: Adds libgumbo-dev BD to liblitehtml-dev package to
  work around removal of the impossible to succeed find_dependency

- debian/rules: Updated with new CMake configs for successful build

- debian/liblitehtml0.symbols: Updated with numerous symbols changes
  based on a build with GCC 11.2.0, which makes the attached patch
  somewhat large (these changes are most of the patch contents) but
  is included here for completeness

For this patch to be useful the mentioned version of litehtml source
(0.5+git20211028) is required. With that version of the source and
the included patch a usable litehtml package can be created, which
then allows src:qt6-tools to build with and link against the system
litehtml library.

[1] https://github.com/litehtml/litehtml/commit/971eadc
[2] https://launchpad.net/~savoury1/+archive/ubuntu/qt-6-2
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018004
 debian/changelog  |  12 ++
 debian/control|   2 +-
 debian/liblitehtml0.symbols   |  88 +---
 debian/patches/CMakeLists.patch   | 161 +-
 debian/rules  |   5 +-
 5 files changed, 153 insertions(+), 115 deletions(-)

diff --git litehtml-0.5+git20211028.orig/debian/changelog litehtml-0.5+git20211028/debian/changelog
index d28b852..3586721 100644
--- litehtml-0.5+git20211028.orig/debian/changelog
+++ litehtml-0.5+git20211028/debian/changelog
@@ -1,3 +1,15 @@
+litehtml (0.5+git20211028-1) UNRELEASED; urgency=medium
+
+  * New build from git source to exactly match version included in Qt6 Tools
+  * debian/patches/: Rebase CMakeLists.patch (partially upstreamed, but with
+no multiarch for install so retain that, also fix new litehtmlConfig.cmake
+to not search for gumbo with find_dependency due no gumbo CMake config)
+  * d/control: Add required libgumbo-dev dependency to liblitehtml-dev package
+  * d/rules: Add {EXTERNAL_GUMBO,LITEHTML_UTF8}=ON, BUILD_TESTING=OFF configs
+  * Update symbols from build logs
+
+ -- Rob Savoury   Tue, 23 Aug 2022 15:02:46 -0700
+
 litehtml (0.5-3) unstable; urgency=medium
 
   * Update symbols file
diff --git litehtml-0.5+git20211028.orig/debian/control litehtml-0.5+git20211028/debian/control
index 1ab778c..8c4e894 100644
--- litehtml-0.5+git20211028.orig/debian/control
+++ litehtml-0.5+git20211028/debian/control
@@ -17,7 +17,7 @@ Package: liblitehtml-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: liblitehtml0 (= ${binary:Version}), ${misc:Depends}
+Depends: liblitehtml0 (= ${binary:Version}), libgumbo-dev, ${misc:Depends}
 

Bug#1017496: libgeocoding.so: needs to link with -lphonenumber

[tony mancill]

Hello Paul,

On Wed, Aug 17, 2022 at 09:08:46AM +0800, Paul Wise wrote:
> Package: libgeocoding8
> Version: 8.12.51+ds-1
> Severity: minor
> File: /usr/lib/x86_64-linux-gnu/libgeocoding.so.8.12
> User: debian...@lists.debian.org
> Usertags: undefined-symbol adequate
> 
> libgeocoding.so needs to link with -lphonenumber, see the output of
> adequate, symtree and objdump below. I detected this on amd64 but the
> Debian build log scanner also detected dpkg-buildpackage complaining
> about it on most architectures, see the w3m/getbuildlog output below.
> 
> I filed this bug at severity minor since I'm not sure if there are any
> programs using the libgeocoding.so lib and if they already use the
> libphonenumber.so symbols and link with the -lphonenumber flag or not. 
> 
> This bug report brought to you by adequate:
> 
> https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

Thank you for the bug report and exposition.  I am preparing an upload
for a new upstream version and am in the process of updating the package
from cdbs.  I will address this, if not right away, then in time for
bookworm.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1018005: xfonts-base: missing U+2A7D (⩽) and U+2A7E (⩾) characters in 6x13

[Vincent Lefevre]

Package: xfonts-base
Version: 1:1.0.5
Severity: normal
Tags: patch

I'm using the 6x13 font on some machine, and the following characters
are missing:
  U+2A7D LESS-THAN OR SLANTED EQUAL TO
  U+2A7E GREATER-THAN OR SLANTED EQUAL TO

I could create the glyphs with fontforge, based on U+2264 (≤) and
U+2265 (≥). I've attached a patch.

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

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

Versions of packages xfonts-base depends on:
ii  xfonts-utils  1:7.7+6

xfonts-base recommends no packages.

Versions of packages xfonts-base suggests:
ii  tigervnc-standalone-server [xserver]  1.12.0+dfsg-4
ii  xserver-xorg [xserver]1:7.7+23
ii  xvfb [xserver]2:21.1.4-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -Naurd xfonts-base-1.0.5-a/font-misc-misc/6x13.bdf xfonts-base-1.0.5-b/font-misc-misc/6x13.bdf
--- xfonts-base-1.0.5-a/font-misc-misc/6x13.bdf	2019-02-21 13:48:02.0 +
+++ xfonts-base-1.0.5-b/font-misc-misc/6x13.bdf	2022-08-23 17:29:53.884579715 +
@@ -28,7 +28,7 @@
 X_HEIGHT 6
 _GBDFED_INFO "Edited with gbdfed 1.3."
 ENDPROPERTIES
-CHARS 4121
+CHARS 4123
 STARTCHAR char0
 ENCODING 0
 SWIDTH 480 0
@@ -76509,6 +76509,34 @@
 00
 00
 ENDCHAR
+STARTCHAR uni2A7D
+ENCODING 10877
+SWIDTH 480 0
+DWIDTH 6 0
+BBX 5 7 0 1
+BITMAP
+18
+60
+80
+60
+98
+60
+18
+ENDCHAR
+STARTCHAR uni2A7E
+ENCODING 10878
+SWIDTH 480 0
+DWIDTH 6 0
+BBX 5 7 0 1
+BITMAP
+C0
+30
+08
+30
+C8
+30
+C0
+ENDCHAR
 STARTCHAR uni2E18
 ENCODING 11800
 SWIDTH 480 0

Bug#1017739: emacs-lucid cannot start after upgrade

[Rob Browning]

Stefan Monnier  writes:

>>> emacs -e '(message "%S" comp-native-load-path)'
>
> Sorry, that should have been:
>
> emacs --eval '(message "%S" comp-native-load-path)'
>
> (which you can then try with `-q` and friends if needed).
>
>> I'm a bit mystified as to why everyone else on Debian isn't seeing this.
>> I would have assumed it must be something in my startup files that is
>> incompatible with the latest release of Emacs, except I thought -q
>> --no-site-file should completely disable loading anything from my local
>> configuration.
>
> My crystal ball suggests maybe your ~/.emacs.d is marked as read-only?

I don't know if this helps, but in addition to the recent issue we've
identified where not having emacs-el installed can cause emacs from the
current 28 packages to segfault on startup, people just figured out that
if you try to install emacs via "su apt install emacs" (note the lack of
a "-" argument to su) from a non-root account, emacs can end up failing
for that account because the install ends up creating root-only
directories (for I think the eln files, etc.) in ~.

I'm not sure whether that's something that we'd expect to support
(i.e. apt installs via sudo without -i or su without -), but I wanted to
mention it since it's been reported (I think) more than once, and in
case it indicates something that emacs might want to change (use of USER
vs HOME, etc.).

No personal position there right now either way.

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

Bug#1018004: qt6-tools: does not build and link with system litehtml

[Rob Savoury]

Package: src:qt6-tools
Version: 6.3.1-2
Severity: normal
Tags: patch

Dear Maintainer,

This package does not currently build and link with system litehtml
as apparently desired. A build dependency on liblitehtml-dev seems
to indicate an intention for the package to use the system litehtml
for the Qt Assistant tool, though the currently packaged litehtml
(0.5-3) is not successfully found via CMake due missing the needed
litehtmlConfig.cmake file. So this bug also applies to litehtml.

Failure to build/link with the system litehtml is easily confirmed
by looking at the assistant-qt6 package [1] which shows no depends
on liblitehtml0 as would be expected if system litehtml was used.
For previous versions of qt6-tools (ie. 6.2.4) the usual CMake
status output shows the failure to find system litehtml during the
dh_auto_configure phase which includes the following output [2]:

[...]
-- The following OPTIONAL packages have not been found:

 * Qt6QmlCompilerPlus
 * litehtml
[...]

Builds of Qt 6.3.1 packages including qt6-tools have much reduced
CMake output for some reason, including on Ubuntu Launchpad (not
sure why this is so ?) and so the "not been found" message is not
shown in the build logs (ie. for latest 6.3.1-2 [3] package).

Looking into src:qt6-tools there is a 3rdparty directory [4] which
includes a full copy of litehtml source as at commit 971eadc on
2021-10-28 [5]. This is confirmed by doing a git clone of litehtml
at that exact commit, with no differences seen between that version
of litehtml source and litehtml source included in src:qt6-tools.

Builds of src:qt6-tools that successfully use and link with system
litehtml have been tested by me, through packaging the exact same
version of litehtml (0.5+git20211028) as included in src:qt6-tools.
A patch is then also required due issues with Qt CMake code (trying
to set Qt defs only applicable to source code in the Qt6 Tools
project) and a changed location of litehtml headers (after 0.5).

Builds of src:qt6-tools 6.2.4 against src:litehtml 0.5+git20211028
that demonstrate successful use and linking with the system litehtml
are now available at a recently created Launchpad PPA [6] for Ubuntu
users. So this bug does also affect qt6-tools 6.2.4-2~bpo11+1 as
found in bullseye-backports repository, confirmed by above mentioned
build logs and again by checking depends for assistant-qt6 [7].

Basic testing of the /usr/lib/qt6/bin/assistant binary (installed
via assistant-qt6 binary package) from the Launchpad PPA shows that
it appears to work as intended. Adding precompiled Qt help (.qch)
files via preferences allows browsing of the content successfully.

Attached is a proposed patch which applies cleanly to the qt6-tools
6.3.1-2 package as currently found in Sid. An adaptation of changes
made by this patch was used for 6.2.4 with the mentioned Launchpad
PPA builds, as could be done for the Bullseye qt6-tools backport.
This patch will only be useful once litehtml 0.5+git20211028 is also
packaged, due that version being required for a successful build.

A bug report will subsequently be filed for litehtml detailing the
required version and also other fixes (including updating a patch
to litehtml CMakeLists.txt) for building and linking to work with
qt6-tools successfully. Both packages will have to be updated for
that result to be achieved.

Thank you for your work maintaining the Qt6 packages.

[1] https://packages.debian.org/sid/assistant-qt6
[2]
https://buildd.debian.org/status/fetch.php?pkg=qt6-tools=amd64=6.2.4-3=1657216677=0
[3]
https://buildd.debian.org/status/fetch.php?pkg=qt6-tools=amd64=6.3.1-2=1660602816=0
[4] src:qt6-tools -> src/assistant/qlitehtml/src/3rdparty/litehtml
[5] https://github.com/litehtml/litehtml/commit/971eadc
[6] https://launchpad.net/~savoury1/+archive/ubuntu/qt-6-2
[7] https://packages.debian.org/bullseye-backports/assistant-qt6
 debian/changelog |  9 ++
 debian/control   |  2 +-
 /dev/null => debian/patches/fix-build-with-system-litehtml.patch | 62 
 /dev/null => debian/patches/series   |  1 +
 4 files changed, 73 insertions(+), 1 deletion(-)

diff --git qt6-tools-6.3.1.orig/debian/changelog qt6-tools-6.3.1/debian/changelog
index eacadb8..bfb1f75 100644
--- qt6-tools-6.3.1.orig/debian/changelog
+++ qt6-tools-6.3.1/debian/changelog
@@ -1,3 +1,12 @@
+qt6-tools (6.3.1-3) UNRELEASED; urgency=medium
+
+  * Actually build with system litehtml (not previously working):
+- debian/patches/: Add fix-build-with-system-litehtml.patch to fix FTBFS
+- debian/control: Bump to liblitehtml-dev (>= 0.5+git20211028) BD for the
+  exact version included in src:qt6-tools, required for successful build
+
+ -- Rob Savoury   Tue, 23 Aug 2022 14:06:25 -0700
+
 qt6-tools (6.3.1-2) unstable; urgency=medium
 
   [ Patrick Franz ]
diff --git qt6-tools-6.3.1.orig/debian/control qt6-tools-6.3.1/debian/control

Bug#920139: My friend

[Matthew Ade]

HDF-
Hello
My name is Matthew from Lome Togo. I am an advocate to a late client of
mine who bears the same surname as you and I want you to come and claim his
heritage left behind with the bank. If you don't mind, I would like to have
your WhatsApp number to have a live chat with you for details.
Matthew

Bug#1017960: vmpk stopped producing sound

[Ash Joubert]

Downgrading libdrumstick binaries to 2.6.1-1 restores vmpk 
functionality. I downgraded:


drumstick-data
libdrumstick-alsa2
libdrumstick-rt-backends
libdrumstick-rt2
libdrumstick-widgets2

Kind regards,

--
Ash Joubert (they/them) 
Director
Transient Software Limited 
New Zealand

Bug#1017997: hdf5 ftbfs on s390x

[Gilles Filippini]

Hi Steve,

Steve Langasek a écrit le 23/08/2022 à 22:40 :

Package: hdf5
Version: 1.10.8+repack-1
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Gilles,

hdf5 has been failing to build from source on s390x.  In Ubuntu we have a
patch to fix this build failure.  Please consider including it in Debian as
well.


Thanks for this patch. However I can't reproduce the FTBFS on the s390x 
porterbox zelenka.debian.org.


Would you mind sharing build logs?

Best,
_g.

Bug#1018002: linux: Skipping BTF generation for /my/own/lkm.ko due to unavailability of vmlinux

[Thorsten Glaser]

Package: linux-headers-5.19.0-trunk-amd64
Version: 5.19-1~exp1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

In building an out-of-tree kernel module I wrote on 5.19 (to test
compatibility), I noticed a new error message.

/usr/lib/linux-kbuild-5.19/scripts/Makefile.modfinal emits the
message, and an inserted pwd;ls -l shows that the command looks
for existence of a “vmlinux” file (or symlinked) in its cwd
/usr/src/linux-headers-5.19.0-trunk-amd64 which belongs to the
linux-headers-*-$arch package.

sudo ln -s /boot/vmlinuz-5.19.0-trunk-amd64 
/usr/src/linux-headers-5.19.0-trunk-amd64/vmlinux
brings me further. I now also have to install the pahole package,
which probably needs to be depended on by linux-kbuild-5.19 now,
but then I get:

libbpf: failed to get EHDR from vmlinux
Failed to parse base BTF 'vmlinux': -4001

What am I still missing?

Are these BTF files supposed to be generated for out-of-tree
modules in the first place? If not, I suggest skipping the
  BTF [M] /my/own/lkm.ko
and the error message altogether instead.


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-headers-5.19.0-trunk-amd64 depends on:
ii  linux-compiler-gcc-11-x86  5.18.5-1
ii  linux-headers-5.19.0-trunk-common  5.19-1~exp1
ii  linux-kbuild-5.19  5.19-1~exp1

linux-headers-5.19.0-trunk-amd64 recommends no packages.

linux-headers-5.19.0-trunk-amd64 suggests no packages.

-- no debconf information

Bug#1018000: tuxpaint: SDL2 version of Tux Paint requires SDL2_Pango

[Pere Pujal i Carabantes]

Package: tuxpaint
Version: 1:0.9.28-sdl2-1
Severity: important
Tags: l10n

Dear Maintainer,

Current build (Version: 1:0.9.28-sdl2-1) does not use SDL2_Pango which causes a
problem that the application does not render UI texts properly, this is
specially noticed in Right To Left languages like Arabic thet renders the text
reversed.


   * What led up to the situation?
Using tuxpaint build 1:0.9.28-sdl2-1 in the Arabic language
/usr/bin/tuxpaint --lang arabic

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Compiling and installing SDL2_Pango then compiling Tux Paint makes the text
render properly.

   * What was the outcome of this action?
   * What outcome did you expect instead?

Additional info:

  SDL2_Pango is maintained by Mark K. Kim on the following github repo.

  https://github.com/markuskimius/SDL2_Pango

See also
https://sourceforge.net/p/tuxpaint/mailman/tuxpaint-
maintainers/thread/CADZCvhC2-Gjc6JVnWOj4dHJS50sFx3oVWTe1sg5_CR%2Bvsxe97Q%40mail.gmail.com/#msg37696031



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

Kernel: Linux 5.10.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tuxpaint depends on:
ii  libc62.33-1
ii  libcairo21.16.0-5
ii  libfribidi0  1.0.7-1.1
ii  libimagequant0   2.12.2-1.1
ii  libpaper11.1.28+b1
ii  libpng16-16  1.6.37-1
ii  librsvg2-2   2.50.7+dfsg-2
ii  libsdl2-2.0-02.0.18+dfsg-2
ii  libsdl2-gfx-1.0-01.0.4+dfsg-3.1
ii  libsdl2-image-2.0-0  2.0.5+dfsg1-2
ii  libsdl2-mixer-2.0-0  2.0.4+dfsg1-3
ii  libsdl2-ttf-2.0-02.0.15+dfsg1-2
ii  libvorbis0a  1.3.7-1
ii  libvorbisfile3   1.3.7-1
ii  netpbm   2:10.0-15.3+b2
ii  tuxpaint-data1:0.9.28-sdl2-1
ii  tuxpaint-plugins-default [tuxpaint-plugins]  1:0.9.28-sdl2-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages tuxpaint recommends:
ii  tuxpaint-config  0.0.14-1+b1

tuxpaint suggests no packages.

-- no debconf information

Bug#1018001: dh-nss should handle when multiple binary packages modify NSS

[Sergio Durigan Junior]

Package: dh-nss
Version: 1.5
Severity: medium

Hello,

sssd has recently moved to dh-nss and now its dep8 tests are failing.
The reason is because the migration to dh-nss was done for libsss-nss,
but libsss-sudo also performs modifications to /etc/nsswitch.conf.

dh-nss generates the following snippet inside d/libsss-nss.postinst:

--8<---cut here---start->8---
# Automatically added by dh_installnss/1.5
if [ "$1" = "configure" ] && [ -e "${DPKG_ROOT}/etc/nsswitch.conf" ] ; then
if ! grep -q -E '^[^#:]+:[^#]*\s(sss)(\s|#|$)' 
"${DPKG_ROOT}/etc/nsswitch.conf" ; then
# Installing passwd/sss from libnss-sss in position last
sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e 
'/^passwd:\s[^#]*$/ s/$/ sss/' -e '/^passwd:\s.*#/ s/#/ sss #/'
# Installing group/sss from libnss-sss in position last
sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e 
'/^group:\s[^#]*$/ s/$/ sss/' -e '/^group:\s.*#/ s/#/ sss #/'
# Installing shadow/sss from libnss-sss in position last
sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e 
'/^shadow:\s[^#]*$/ s/$/ sss/' -e '/^shadow:\s.*#/ s/#/ sss #/'
# Installing netgroup/sss from libnss-sss in position last
sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e 
'/^netgroup:\s[^#]*$/ s/$/ sss/' -e '/^netgroup:\s.*#/ s/#/ sss #/'
# Installing services/sss from libnss-sss in position last
sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e 
'/^services:\s[^#]*$/ s/$/ sss/' -e '/^services:\s.*#/ s/#/ sss #/'
# Installing automount/sss from libnss-sss in position last
sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e 
'/^automount:\s[^#]*$/ s/$/ sss/' -e '/^automount:\s.*#/ s/#/ sss #/'
fi
fi
# End automatically added section
--8<---cut here---end--->8---

The problem is that, when libsss-sudo is installed before libsss-nss,
there will already be an entry containing "sss" in /etc/nsswitch.conf.
Because of that, the snippet above doesn't get executed and the
nsswitch.conf file isn't updated.

I read dh_installnss' manpage and source code but I couldn't find an
easy way to workaround this problem.  Ideally, the first grep should be
trying to match the db's specified at the debian/*.nss file, instead of
using a generic match.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1017999: bullseye-pu: package krb5/1.18.3-6+deb11u2

[Sam Hartman]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]

Rhel9 deprecates SHA1 as a CMS digest algorithm.  Without this patch,
a bullseye client cannot perform (anonymous) pkinit to a RHEL9 KDC.
Pkinit is important enough that I'd like to see this fixed, but is not
so common that I'm worried about needing to do a huge cross-version
compatibility test before accepting the change.

That said, it looks like Redhat has fairly thoroughly researched the
compatibility issues.  Accepting this patch into bullseye probably
breaks anonymous pkinit from jessie to a bullseye KDC because jessie is
too old to support SHA256 for all the pkinit uses.  Stretch should be
new enough.

This has been in unstable as part of krb5 1.20 for a while.  Companion
to the just submitted buster update.  The patch is slightly different
because I had to backport one of the changes and because bullseye uses
gbp pq while buster uses git-dpm.



[ Impact ]

Anonymous pkinit breaks against RHEL9 and probably bookworm+1.


[ Tests ]

I ran the automated pkinit tests and confirmed they have adequate coverage to 
test that I properly applied the patch.
I'm trusting Redhat's analysis for the cross-version testing.
Based on knowledge of the people involved and the description of the analysis I 
think that is appropriate.


[ Risks ]

See above.

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

[ Changes ]
(Explain *all* the changes)
diff --git a/debian/changelog b/debian/changelog
index 0be31136f4..d6eaa38262 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+krb5 (1.18.3-6+deb11u2) bullseye; urgency=medium
+
+  * Use SHA256 as Pkinit CMS Digest, Closes: #1017995
+
+
+ -- Sam Hartman   Tue, 23 Aug 2022 14:49:09 -0600
+
 krb5 (1.18.3-6+deb11u1) bullseye; urgency=medium
 
   * Fix KDC null dereference crash on FAST request with no server field,
diff --git 
a/debian/patches/0013-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch 
b/debian/patches/0013-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
new file mode 100644
index 00..720bca3bc7
--- /dev/null
+++ 
b/debian/patches/0013-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
@@ -0,0 +1,119 @@
+From: Julien Rische 
+Date: Fri, 11 Mar 2022 12:04:14 +0100
+Subject: Use SHA-256 instead of SHA-1 for PKINIT CMS digest
+
+[ghud...@mit.edu: edited comments]
+
+ticket: 9055 (new)
+---
+ src/plugins/preauth/pkinit/pkinit_crypto_openssl.c | 40 --
+ 1 file changed, 22 insertions(+), 18 deletions(-)
+
+diff --git a/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 
b/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
+index 8c7fd0c..4452d4e 100644
+--- a/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
 b/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
+@@ -1227,7 +1227,7 @@ cms_signeddata_create(krb5_context context,
+ /* will not fill-out EVP_PKEY because it's on the smartcard */
+ 
+ /* Set digest algs */
+-p7si->digest_alg->algorithm = OBJ_nid2obj(NID_sha1);
++p7si->digest_alg->algorithm = OBJ_nid2obj(NID_sha256);
+ 
+ if (p7si->digest_alg->parameter != NULL)
+ ASN1_TYPE_free(p7si->digest_alg->parameter);
+@@ -1238,17 +1238,18 @@ cms_signeddata_create(krb5_context context,
+ /* Set sig algs */
+ if (p7si->digest_enc_alg->parameter != NULL)
+ ASN1_TYPE_free(p7si->digest_enc_alg->parameter);
+-p7si->digest_enc_alg->algorithm = 
OBJ_nid2obj(NID_sha1WithRSAEncryption);
++p7si->digest_enc_alg->algorithm =
++OBJ_nid2obj(NID_sha256WithRSAEncryption);
+ if (!(p7si->digest_enc_alg->parameter = ASN1_TYPE_new()))
+ goto cleanup;
+ p7si->digest_enc_alg->parameter->type = V_ASN1_NULL;
+ 
+ /* add signed attributes */
+-/* compute sha1 digest over the EncapsulatedContentInfo */
++/* compute sha256 digest over the EncapsulatedContentInfo */
+ ctx = EVP_MD_CTX_new();
+ if (ctx == NULL)
+ goto cleanup;
+-EVP_DigestInit_ex(ctx, EVP_sha1(), NULL);
++EVP_DigestInit_ex(ctx, EVP_sha256(), NULL);
+ EVP_DigestUpdate(ctx, data, data_len);
+ md_tmp = EVP_MD_CTX_md(ctx);
+ EVP_DigestFinal_ex(ctx, md_data, _len);
+@@ -1276,12 +1277,14 @@ cms_signeddata_create(krb5_context context,
+ goto cleanup2;
+ 
+ #ifndef WITHOUT_PKCS11
+-/* Some tokens can only do RSAEncryption without sha1 hash */
+-/* to compute sha1WithRSAEncryption, encode the algorithm ID for the 
hash
+- * function and the hash value into an ASN.1 value of type DigestInfo
+- * DigestInfo::=SEQUENCE {
+- *  digestAlgorithm  AlgorithmIdentifier,
+- *  digest OCTET 

Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

[Simon McVittie]

On Tue, 23 Aug 2022 at 16:44:54 -0400, Jeffrey Walton wrote:
> On Tue, Aug 23, 2022 at 4:40 PM Simon McVittie  wrote:
> > On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote:
> > > The final link fails with multiple definitions of the various atomic
> > > builtins:
> > >
> > > > (.text+0x0): multiple definition of `__sync_fetch_and_add_4'; 
> > > > /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94:
> > > >  first defined here
> 
> Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248#c2 (and
> more generally https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358).

Those are related, but seem like the opposite issue: I'm getting
a build failure because I somehow end up with two copies of
__sync_fetch_and_add_4, whereas those bugs are about having zero copies
of similar compiler-provided functions. We want exactly one copy :-)

Or are you saying that I'm getting these multiple definitions *because*,
unlike gcc-11, gcc-12 is automatically providing symbols like
__sync_fetch_and_add_4 in order to resolve those gcc bug reports?

In any case it seems to be possible to work around this by forcing gcc-11,
which is not great (toolchain maintainers dislike uses of a non-default
gcc) but arguably better than FTBFS.

smcv

Bug#1017998: buster-pu: package krb5/1.17-3+deb10u4

[Sam Hartman]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu


[ Reason ]

Rhel9 deprecates SHA1 as a CMS digest algorithm.  Without this patch,
a buster client cannot perform (anonymous) pkinit to a RHEL9 KDC.
Pkinit is important enough that I'd like to see this fixed, but is not
so common that I'm worried about needing to do a huge cross-version
compatibility test before accepting the change.

That said, it looks like Redhat has fairly thoroughly researched the
compatibility issues.  Accepting this patch into buster probably
breaks anonymous pkinit from jessie to a buster KDC because jessie is
too old to support SHA256 for all the pkinit uses.  Stretch should be
new enough.

This has been in unstable as part of krb5 1.20 for a while.
Expect a bullseye update shortly.

[ Impact ]

Anonymous pkinit breaks against RHEL9 and probably bookworm+1.


[ Tests ]

I ran the automated pkinit tests and confirmed they have adequate coverage to 
test that I properly applied the patch.
I'm trusting Redhat's analysis for the cross-version testing.
Based on knowledge of the people involved and the description of the analysis I 
think that is appropriate.


[ Risks ]

See above.

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

[ Changes ]
(Explain *all* the changes)

diff --git a/debian/.git-dpm b/debian/.git-dpm
index fcd6a7f36e..713ff3581e 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-668523c82a2446609f3eab8688c8837c59b97de2
-668523c82a2446609f3eab8688c8837c59b97de2
+c5354e5b2e0ad5c68fc3f07ecf2c3ab3285d0f08
+c5354e5b2e0ad5c68fc3f07ecf2c3ab3285d0f08
 a75eb54fd955cbf7a8ac44e527fd0e400e87844a
 a75eb54fd955cbf7a8ac44e527fd0e400e87844a
 krb5_1.17.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index 45d55810ea..8167db8a4d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+krb5 (1.17-3+deb10u4) buster; urgency=medium
+
+  * Use SHA256 as Pkinit CMS Digest, Closes: #1017995
+
+ -- Sam Hartman   Tue, 23 Aug 2022 14:28:40 -0600
+
 krb5 (1.17-3+deb10u3) buster; urgency=high
 
   * Fix KDC null dereference crash on FAST request with no server field,
diff --git 
a/debian/patches/0016-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch 
b/debian/patches/0016-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
new file mode 100644
index 00..6bef568521
--- /dev/null
+++ 
b/debian/patches/0016-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
@@ -0,0 +1,128 @@
+From c5354e5b2e0ad5c68fc3f07ecf2c3ab3285d0f08 Mon Sep 17 00:00:00 2001
+From: Julien Rische 
+Date: Fri, 11 Mar 2022 12:04:14 +0100
+Subject: Use SHA-256 instead of SHA-1 for PKINIT CMS digest
+
+[ghud...@mit.edu: edited comments]
+
+ticket: 9055 (new)
+---
+ .../preauth/pkinit/pkinit_crypto_openssl.c| 41 +++
+ 1 file changed, 23 insertions(+), 18 deletions(-)
+
+diff --git a/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 
b/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
+index 5ff81d8cf4..66b09c6f41 100644
+--- a/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
 b/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
+@@ -1237,7 +1237,7 @@ cms_signeddata_create(krb5_context context,
+ /* will not fill-out EVP_PKEY because it's on the smartcard */
+ 
+ /* Set digest algs */
+-p7si->digest_alg->algorithm = OBJ_nid2obj(NID_sha1);
++p7si->digest_alg->algorithm = OBJ_nid2obj(NID_sha256);
+ 
+ if (p7si->digest_alg->parameter != NULL)
+ ASN1_TYPE_free(p7si->digest_alg->parameter);
+@@ -1248,7 +1248,8 @@ cms_signeddata_create(krb5_context context,
+ /* Set sig algs */
+ if (p7si->digest_enc_alg->parameter != NULL)
+ ASN1_TYPE_free(p7si->digest_enc_alg->parameter);
+-p7si->digest_enc_alg->algorithm = 
OBJ_nid2obj(NID_sha1WithRSAEncryption);
++p7si->digest_enc_alg->algorithm =
++OBJ_nid2obj(NID_sha256WithRSAEncryption);
+ if (!(p7si->digest_enc_alg->parameter = ASN1_TYPE_new()))
+ goto cleanup;
+ p7si->digest_enc_alg->parameter->type = V_ASN1_NULL;
+@@ -1259,16 +1260,17 @@ cms_signeddata_create(krb5_context context,
+ alen = data_len;
+ } else {
+ /* add signed attributes */
+-/* compute sha1 digest over the EncapsulatedContentInfo */
++/* compute sha256 digest over the EncapsulatedContentInfo */
+ ctx = EVP_MD_CTX_new();
+ if (ctx == NULL)
+ goto cleanup;
+-EVP_DigestInit_ex(ctx, EVP_sha1(), NULL);
++EVP_DigestInit_ex(ctx, EVP_sha256(), NULL);
+ EVP_DigestUpdate(ctx, data, data_len);
+ md_tmp = EVP_MD_CTX_md(ctx);
+ 

Bug#1005283: Acknowledgement (ITP:php-maximebf-debugbar - debug bar in the browser with information from php)

[Katharina Drexel]

Package can be built and uploaded from here:
https://salsa.debian.org/php-team/pear/php-maximebf-debugbar/

Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

[Jeffrey Walton]

On Tue, Aug 23, 2022 at 4:40 PM Simon McVittie  wrote:
>
> Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786623
> Control: affects -1 + src:mozjs102
>
> On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote:
> > The final link fails with multiple definitions of the various atomic
> > builtins:
> >
> > > (.text+0x0): multiple definition of `__sync_fetch_and_add_4'; 
> > > /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94:
> > >  first defined here
>
> Reported upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1786623

Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248#c2 (and
more generally https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358).

> > (For completeness: 91.10.0-1 and 91.12.0-1 have an additional failure
> > reason involving undefined references to
> > std::type_info::operator==(std::type_info const&) const, but I believe
> > that was fixed in 91.12.0-2 by removing an obsolete patch.)
>
> Correction, it was fixed by a patch removing an obsolete workaround.
> Reported as https://bugzilla.mozilla.org/show_bug.cgi?id=1786621 (but we
> already have a patch for this, so it's an upstream bug but not a Debian bug)

Jeff

Bug#1017961: mozjs102: Fails to build on armel

[Simon McVittie]

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786619

On Tue, 23 Aug 2022 at 13:31:21 +0100, Simon McVittie wrote:
> I tried the attached patch

Sorry, now attached.

> The next thing I'm going to try is using gcc 11 on armel as a workaround
> for #1017979.

That worked, but a lot of tests fail, probably as a result of the attached
patch being wrong. But perhaps it's enough to point someone in the right
direction?

smcv
From: Simon McVittie 
Date: Tue, 23 Aug 2022 09:21:30 +0100
Subject: jit: Only use ARMv7 atomic operations on ARMv7 or higher

Debian's armel (ARM EABI softfloat) port has a lower baseline than the
armhf (ARM EABI hardfloat), currently ARMv5, so we need to fall back
to the "feeling lucky" atomics on this architecture.

Bug-Debian: https://bugs.debian.org/1017961
Signed-off-by: Simon McVittie 
---
 js/src/jit/GenerateAtomicOperations.py | 23 +-
 .../shared/AtomicOperations-feeling-lucky-gcc.h|  5 -
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/js/src/jit/GenerateAtomicOperations.py b/js/src/jit/GenerateAtomicOperations.py
index d8a38a0..1cc1bf6 100644
--- a/js/src/jit/GenerateAtomicOperations.py
+++ b/js/src/jit/GenerateAtomicOperations.py
@@ -12,6 +12,11 @@ is_64bit = "JS_64BIT" in buildconfig.defines
 cpu_arch = buildconfig.substs["CPU_ARCH"]
 is_gcc = buildconfig.substs["CC_TYPE"] == "gcc"
 
+if cpu_arch == "arm":
+armv7 = (int(buildconfig.substs["ARM_ARCH"]) >= 7)
+else:
+armv7 = False
+
 
 def fmt_insn(s):
 return '"' + s + '\\n\\t"\n'
@@ -32,7 +37,7 @@ def gen_seqcst(fun_name):
 }""" % {
 "fun_name": fun_name,
 }
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
 return r"""
 INLINE_ATTR void %(fun_name)s() {
 asm volatile ("dmb sy\n\t" ::: "memory");
@@ -104,7 +109,7 @@ def gen_load(fun_name, cpp_type, size, barrier):
 "fun_name": fun_name,
 "insns": insns,
 }
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
 insns = ""
 if barrier:
 insns += fmt_insn("dmb sy")
@@ -191,7 +196,7 @@ def gen_store(fun_name, cpp_type, size, barrier):
 "fun_name": fun_name,
 "insns": insns,
 }
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
 insns = ""
 if barrier:
 insns += fmt_insn("dmb sy")
@@ -280,7 +285,7 @@ def gen_exchange(fun_name, cpp_type, size):
 "fun_name": fun_name,
 "insns": insns,
 }
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
 insns = ""
 insns += fmt_insn("dmb sy")
 insns += fmt_insn("0:")
@@ -336,7 +341,7 @@ def gen_cmpxchg(fun_name, cpp_type, size):
 "cpp_type": cpp_type,
 "fun_name": fun_name,
 }
-if cpu_arch == "arm" and size == 64:
+if cpu_arch == "arm" and size == 64 and armv7:
 return r"""
 INLINE_ATTR %(cpp_type)s %(fun_name)s(%(cpp_type)s* addr,
  %(cpp_type)s oldval,
@@ -440,7 +445,7 @@ def gen_cmpxchg(fun_name, cpp_type, size):
 "fun_name": fun_name,
 "insns": insns,
 }
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
 insns = ""
 insns += fmt_insn("dmb sy")
 insns += fmt_insn("0:")
@@ -595,7 +600,7 @@ def gen_fetchop(fun_name, cpp_type, size, op):
 "fun_name": fun_name,
 "insns": insns,
 }
-if cpu_arch == "arm":
+if cpu_arch == "arm" and armv7:
 insns = ""
 insns += fmt_insn("dmb sy")
 insns += fmt_insn("0:")
@@ -664,7 +669,7 @@ def gen_copy(fun_name, cpp_type, size, unroll, direction):
 assert size == 8
 insns += fmt_insn("ldr %x[scratch], [%x[src], OFFSET]")
 insns += fmt_insn("str %x[scratch], [%x[dst], OFFSET]")
-elif cpu_arch == "arm":
+elif cpu_arch == "arm" and armv7:
 if size == 1:
 insns += fmt_insn("ldrb %[scratch], [%[src], #OFFSET]")
 insns += fmt_insn("strb %[scratch], [%[dst], #OFFSET]")
@@ -721,7 +726,7 @@ namespace jit {
 
 def generate_atomics_header(c_out):
 contents = ""
-if cpu_arch in ("x86", "x86_64", "arm", "aarch64"):
+if cpu_arch in ("x86", "x86_64", "aarch64") or armv7:
 contents += "#define JS_HAVE_GENERATED_ATOMIC_OPS 1"
 
 # `fence` performs a full memory barrier.
diff --git a/js/src/jit/shared/AtomicOperations-feeling-lucky-gcc.h b/js/src/jit/shared/AtomicOperations-feeling-lucky-gcc.h
index 2e38433..3954202 100644
--- a/js/src/jit/shared/AtomicOperations-feeling-lucky-gcc.h
+++ b/js/src/jit/shared/AtomicOperations-feeling-lucky-gcc.h
@@ -31,7 +31,10 @@
 // Explicitly exclude tier-1 platforms.
 
 #if (defined(__x86_64__) || defined(_M_X64) || defined(__i386__) || \
- 

Bug#1017997: hdf5 ftbfs on s390x

[Steve Langasek]

Package: hdf5
Version: 1.10.8+repack-1
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Gilles,

hdf5 has been failing to build from source on s390x.  In Ubuntu we have a
patch to fix this build failure.  Please consider including it in Debian as
well.

I notice that the newer upstream version of hdf5 that's in experimental does
not fail to build anymore on s390x, so perhaps another solution would be to
upload that version to unstable.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru hdf5-1.10.8+repack/debian/patches/fix-signed_headers_dest.patch 
hdf5-1.10.8+repack/debian/patches/fix-signed_headers_dest.patch
--- hdf5-1.10.8+repack/debian/patches/fix-signed_headers_dest.patch 
1969-12-31 16:00:00.0 -0800
+++ hdf5-1.10.8+repack/debian/patches/fix-signed_headers_dest.patch 
2021-11-07 18:21:41.0 -0800
@@ -0,0 +1,15 @@
+--- a/src/H5FDs3comms.c
 b/src/H5FDs3comms.c
+@@ -1717,8 +1717,10 @@
+ node = node->next;
+ } /* end while node is not NULL */
+ 
+-/* remove trailing ';' from signed headers sequence */
+-signed_headers_dest[HDstrlen(signed_headers_dest) - 1] = '\0';
++if (*signed_headers_dest != '\0') {
++/* remove trailing ';' from signed headers sequence */
++signed_headers_dest[HDstrlen(signed_headers_dest) - 1] = '\0';
++}
+ 
+ /* append signed headers and payload hash
+  * NOTE: at present, no HTTP body is handled, per the nature of
diff -Nru hdf5-1.10.8+repack/debian/patches/series 
hdf5-1.10.8+repack/debian/patches/series
--- hdf5-1.10.8+repack/debian/patches/series2022-04-29 08:47:00.0 
-0700
+++ hdf5-1.10.8+repack/debian/patches/series2022-08-22 20:47:47.0 
-0700
@@ -4,3 +4,4 @@
 relax-version-check.patch
 fix-unaligned-accesses.patch
 reproducibility.patch
+fix-signed_headers_dest.patch

Bug#1017996: dpkg: please provide `--force-really-unsafe-io` (or similar) option

[Ansgar]

Package: dpkg
Version: 1.21.9
Severity: wishlist
Tags: upstream d-i

Hi,

please reconsider to provide a `--force-really-unsafe-io` (or similar)
option that skips the calls to `fsync()` & friends in dpkg.

I tried installing a larger package set (in stable), including
texlive-full, KDE, GCC and other packages. It took:

  Default dpkg: ~4h10m = 250m
  --force-unsafe-io: ~2h20m = 140m
  eatmydata: ~22m

So skipping all fsync() calls provides a speedup of 11 compared to
dpkg's defaults and still 6 compared to --force-unsafe-io. This is a
very noticable change.

The dpkg FAQ[1] asks users to use a different filesystem, non-default
mount options, `--force-unsafe-io` or `eatmydata`.

I don't think asking users to use a different filesystem is a good
option (and the installer doesn't ask in many cases); same for
non-default mount options. Doing so also has other downsides.

Options like `--force-unsafe-io` are okay (and d-i can and does use
it), but are suboptimal in many situations where one really does not
need any calls to `fsync`.  `eatmydata` is a bit of a hack and harder
to use (make sure apt-get calls a wrapper dpkg script or everything
calls apt-get/aptitude/* via some wrapper) or not possible (d-i
doesn't use eatmydata).  I think dpkg supporting to skip fsync on its
own is the better solution (compared to implementing eatmydata support
in d-i and other places).

There are various cases where this is useful:

- Initial installation (d-i or initial setup with ansible/puppet/scripts/*).
- Containers.
- CI systems.
- Anything else using throw-away systems (chroots, containers, VMs, ...).

Even dpkg itself uses eatmydata to avoid `fsync()`s (in .gitlab-ci.yml).

I know this was previously proposed and not implemented, but I think
the numer of cases where this is useful has increased over time and
will probably increase more in the future.

Ansgar

  [1]: 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slow_when_using_new_filesystems_such_as_btrfs_or_ext4.3F

Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

[Simon McVittie]

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786623
Control: affects -1 + src:mozjs102

On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote:
> The final link fails with multiple definitions of the various atomic
> builtins:
> 
> > (.text+0x0): multiple definition of `__sync_fetch_and_add_4'; 
> > /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94:
> >  first defined here

Reported upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1786623

> (For completeness: 91.10.0-1 and 91.12.0-1 have an additional failure
> reason involving undefined references to
> std::type_info::operator==(std::type_info const&) const, but I believe
> that was fixed in 91.12.0-2 by removing an obsolete patch.)

Correction, it was fixed by a patch removing an obsolete workaround.
Reported as https://bugzilla.mozilla.org/show_bug.cgi?id=1786621 (but we
already have a patch for this, so it's an upstream bug but not a Debian bug)

smcv

Bug#1017962: mozjs102: Fails to build on armhf

[Simon McVittie]

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1761665

On Tue, 23 Aug 2022 at 10:27:02 +0100, Simon McVittie wrote:
> Here's the generated file. The build is still going, so I don't know
> whether the FTBFS will be reproducible.

Looks like yes. I think this is the same issue as
https://bugzilla.mozilla.org/show_bug.cgi?id=1761665 upstream,
so I'm trying the workaround suggested there.

smcv

Bug#1015189: [debian-mysql] Bug#1015189: mariadb-server: stopping mariadb.service never finishes

[Paul Gevers]

Hi Faustin,

On 23-08-2022 13:10, Faustin Lammler wrote:

Could you verify if you have still the pb with 10.6.9?


After enabling mariadb-server again, at this moment I can indeed stop it 
nicely. One addition test I did is that I hibernated once with 
mariadb-server running, but also then I could stop it nicely. So, either 
10.6.9 fixed the issue, or the root cause for the symptom went away somehow.


I suggest we close this bug, but I'll reopen it again if the problem 
resurfaces.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017995: Update CMS Digest Algorithm to SHA256

[Sam Hartman]

package: krb5-pkinit
version: 1.17-3+deb10u3
severity: important

Starting with RHEL9, Redhat updated the CMS digest signature to SHA256
instead of SHA1.
This makes sense after all since SHA1 was deprecated in 2011.
The main effect of this is that older clients will not be able to do
anonymous pkinit with a RHEL9 KDC.

MIT Kerberos has supported SHA256 signatures since version 1.15.

Update  the CMS digest algorithm for pkinit to SHA256.

This probably breaks compatibility with jessie and before.

So, assuming this is accepted for buster and bullseye (it's already in
sid and bookworm):

* Stretch will work with buster and jessie

* Buster and forward will work going forward up through sid but will not work
  with jessie or backward

Even if some problem results, anonymous pkinit (and pkinit in general)
is fairly rarely used.


signature.asc
Description: PGP signature

Bug#915379: anacron.service: should probably use KillMode=process

[Melvin Vermeeren]

Hi Lance,

Thanks for your reply!

On Tuesday, 23 August 2022 14:33:11 CEST Lance Lin wrote:
> > 1. Always let jobs finish cleanly: TimeoutStopSec=infinity
> > I strongly prefer this option in all cases (desktop/server/...).
> 
> Sure, I think this is easy enough to do and it does make sense.
> 
> I can push a patch for this.

Sounds great, I also think this is the best way to solve it. I did some local 
testing already with long-running jobs and can confirm TimeoutStopSec=infinity 
in the [Service] section works perfectly. Anacron will finish its current job 
cleanly (cron.daily etc) and only then stop/restart.

> > 2. SIGUSR1 anacron as is the case now, then on timeout SIGTERM to all
> > processes in the group, then on timeout again SIGKILL all processes in the
> > group. I must admit I don't know how to implement this with systemd
> > services.
> This change is more involved. At present, anacron is in "legacy" status. I
> recently picked up the package as part of the cronie transition. cronie is
> expected to replace cron/anacron in the future and is actively developed by
> Fedora. I would suggest we place major changes/improvements in that
> project.

Makes sense, I fully agree with you. Hotfixing anacron by disabling timeout 
should be all that's needed until the cronie transition is complete.

Cheers,

-- 
Melvin Vermeeren
Systems engineer

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

Bug#1002638: ITP

[Gard Spreemann]

Hi,

This seems immensely useful! I've started packaging [1], and will upload
shortly.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017994

 -- Gard


signature.asc
Description: PGP signature

Bug#1017840: debian-security-support: cannot create /var/lib/debian-security-support/security-support.semaphore: Permission

[Christoph Anton Mitterer]

On Tue, 2022-08-23 at 16:23 +, Holger Levsen wrote:
> users must not be cleaned up (=removed) on package removal

Well perhaps not a must as per policy, but I think for debian-security-
support it would still make sense to clean up the user, or do you
expect anyone to create files under that user which would then have no
valid user/group? :-)


Cheers,
Chris.

Bug#1017994: ITP: zigpy -- Python Zigbee stack

[Gard Spreemann]

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

* Package name: zigpy
  Version : 0.50.1
  Upstream Author : Russell Cloran  and contributors
* URL : https://github.com/zigpy/zigpy
* License : GPL-3+
  Programming Lang: Python
  Description : Python Zigbee stack

zigpy is a hardware independent Zigbee protocol stack integration project to 
implement Zigbee standard specifications as a Python 3 library.

Zigbee integration via zigpy allows you to connect one of many off-the-shelf 
Zigbee Coordinator adapters using one of the available Zigbee radio library 
modules compatible with zigpy to control Zigbee based devices. There is 
currently support for controlling Zigbee device types such as binary sensors 
(e.g., motion and door sensors), sensors (e.g., temperature sensors), lights, 
switches, buttons, covers, fans, climate control equipment, locks, and intruder 
alarm system devices.


The package is useful for interacting over the increasingly widespread Zigbee 
home automation and IoT protocol. An RFP was made last year [1].

I intend to maintain the package myself.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002638


signature.asc
Description: PGP signature

Bug#1017993: RM: aircrack-ng [s390x] -- ANAIS; s390x not supported by upstream

[Samuel Henrique]

Package: ftp.debian.org
Severity: normal

There is an FTBFS for s390x, reported upstream:
https://github.com/aircrack-ng/aircrack-ng/issues/2324

But it's unclear whether or not upstream supports it or if the package
even works properly.
I'm not aware of any use case for aircrack-ng on s390x.

The new release (1.7) is blocked on this removal so it can migrate to testing.

Thank you,

-- 
Samuel Henrique 

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

What additional information can I provide for us to move forward with this 
process?

To summarize and include further details, rsync is used to sync applications to 
a file server which behaves like a repository.
We do preserve timestamps from the build server and also use --delete.  We do 
not run the applications from the file server.  All servers use NTP.

The application has a sub-directory that contain files with version numbers.  
These are libraries.
When a new build is complete, a developer pushes their updates via rsync to the 
file server / repository.

I believe that the dentry cache thinks the "old" files exist and generates a No 
such file or directory error showing question marks for that files attributes.
Dropping the dentry cache via echo 2 > /proc/sys/vm/drop_caches resolves the 
issue. 

This behavior is not observed in Debian 10.8 with that distributions associated 
kernel and packages.

> -Original Message-
> From: Jason Breitman
> Sent: Friday, August 19, 2022 9:52 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> > -Original Message-
> > From: Ben Hutchings 
> > Sent: Friday, August 19, 2022 7:27 PM
> > To: Jason Breitman ;
> > 1017...@bugs.debian.org
> > Subject: Re: Bug#1017720: nfs-common: No such file or directory
> >
> > Control: tag -1 moreinfo
> >
> > On Fri, 2022-08-19 at 13:16 +, Jason Breitman wrote:
> > > Package: nfs-common
> > > Version: 1:1.3.4-6
> > > Severity: important
> > >
> > > Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
> > > GNU/Linux
> > >
> > > -- Description
> > > After updating and or creating new files on our file server via
> > > rsync, we see many files report the error message below from NFSv4
> > > clients since upgrading from Debian 10.8 to Debian 11.4.
> > > Clearing the dentry cache resolves the issue right away.
> > > I am not sure that nfs-common is the package to blame, but listed
> > > it based on the bug submission recommendations.
> >
> > The NFS implementation is mostly in the kernel, so probably this issue
> > belongs there.  But the kernel team is responsible for both packages.
> >
> > [...]
> > > -- Error message
> > > ls: cannot access 'filename': No such file or directory
> > > -? ? ???? filename
> > [...]
> >
> > So we know the file's there but can't stat it.  I think this means the
> > client has cached the handle of the old file of that name, which has
> > been deleted.
> >
> > - Are client and server clocks closely synchronised?  If not, that
> > needs to be fixed.
> >
> The clocks are synchronized using NTP.
> 
> > - Are clients likely to read this directory while rsync is running, or
> > shortly before?  If so, it may help to reduce the attribute caching
> > timeout on the client.  See the "Directory entry caching" section in
> > the nfs(5) manual page.
> >
> Clients are not likely to read this directory while rsync is running for the
> observed cases.  That can happen in our environment, but not in this case.
> I am using the lookupcache=pos option.  I tried noac, but the performance
> penalty was too much.  Which option are you referring to and what setting
> do you recommend testing?
> 
> > I don't know why you're only seeing this after an upgrade of the
> > clients, though.  I'm not aware that there has been any big change to
> > attribute caching.
> >
> I appreciate you responding to my report and am happy to answer any
> questions.
> We have multiple monitors and log scrapers to detect "file not found"
> exceptions that would let us know if this was happening before.
> To share more, I have 2 environments mounting from the same file server.
> Each environment has several servers.  The issue is only seen in the
> environment running Debian 11.4.
> I also should have mentioned that the files in question have a version
> number appended.  filename-.  When the file is updated via rsync, it is
> called filename-1112 and the prior file is removed.  The error is about
> filename-.
> I am not sure if this is the proper terminology, but the issue appears to be
> the negative dentry cache.
> 
> > Ben.
> >
> > --
> > Ben Hutchings
> > Beware of bugs in the above code;
> > I have only proved it correct, not tried it. - Donald Knuth
> 
> Jason Breitman
Jason Breitman

Bug#1016625: bart-cuda: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'

[Nilesh Patra]

Control: reassign -1 nvidia-cuda-toolkit/11.4.3-4
Control: retitle -1 Please update nvidia-cuda-toolkit to 11.5.1 or later


On 8/23/22 23:58, Martin Uecker wrote:

Am Dienstag, den 23.08.2022, 23:45 +0530 schrieb Nilesh Patra:

On Tue, Aug 23, 2022 at 07:00:44PM +0200, Martin Uecker wrote:

I think I fixed this. At least it compiles locally in
a sid pbuilder environment, but I needed to build-depend
on gcc-10.


gcc-10 will be removed from the archive some day, so this cannot
be a permanent fix.



It is a workaround for another cuda problem, which
apparently can not deal with newer glibc headers and
which is fixed in 11.5.1 not yet in Debian.


In that case, I am re-assigning this to nvidia-cuda-toolkit.
There is 11.5.2 in exp but it needs to get to unstable.

--
Best,
Nilesh


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016625: bart-cuda: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'

[Martin Uecker]

Am Dienstag, den 23.08.2022, 23:45 +0530 schrieb Nilesh Patra:
> On Tue, Aug 23, 2022 at 07:00:44PM +0200, Martin Uecker wrote:
> > I think I fixed this. At least it compiles locally in
> > a sid pbuilder environment, but I needed to build-depend
> > on gcc-10. 
> 
> gcc-10 will be removed from the archive some day, so this cannot
> be a permanent fix.
> 

It is a workaround for another cuda problem, which 
apparently can not deal with newer glibc headers and
which is fixed in 11.5.1 not yet in Debian.

Bug#1017964: [Pkg-rust-maintainers] Bug#1017964: rust-pleaser FTBFS/autopkgtest failure with nix 0.25

[sub...@bugs.debian.org]

On 2022-08-23 02:12+0100, Peter Green wrote:
> The API of gethostname has changed. Now instead of taking a buffer 
> from the caller it retuns a Result
> 
> Adjusting the code was easy enough, but I notice that the buffer size 
> used by the new version of gethostname is about 4 times larger than 
> the one used previously in pleaser. I have not investigated whether 
> this increase in potential string length has any security implications 
> for pleaser.
> 
> Patch at
> 
> https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/pleaser/debian/patches/nix-0.25.patch

I don't see any issues from it, and thanks for keeping me in the loop.

The patch looks good, thanks again and I'll merge it before the next 
upstream bump.

Ed

Bug#1013959: Upgrade package to latest upstream version

[Markus Koschany]

> Dear maintainer,
> 
> Please upgrade mockito to the latest version, 4.6.1.

Hello,

The latest 4.x series introduces many breaking changes and not all reverse-
dependencies are ready for that. As long as projects continue to use 2.x it
would require some effort from our side to port them to newer mockito versions.
I don't think this is feasible at the moment. We could think about packaging
4.x for experimental in the future or even a new mockito4 source package but
that's not a priority for me.

Regards,

Markus


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

Bug#1016625: bart-cuda: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'

[Nilesh Patra]

On Tue, Aug 23, 2022 at 07:00:44PM +0200, Martin Uecker wrote:
> 
> I think I fixed this. At least it compiles locally in
> a sid pbuilder environment, but I needed to build-depend
> on gcc-10. 

gcc-10 will be removed from the archive some day, so this cannot
be a permanent fix.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#842338: ITP: mint-y-icons -- Mint-Y Icon themes

[Fabio Fantoni]

Control: owner -1 !

Control: retitle -1 ITP: mint-y-icons -- Mint-Y Icon themes

I'll package it under the debian cinnamon team: 
https://salsa.debian.org/cinnamon-team/mint-y-icons




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017990: src:pytango: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: pytango
Version: 9.3.3-1
Severity: serious
Tags: sid bookworm ftbfs
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 60 days as having a Release Critical bug in 
testing [1]. Your package src:pytango has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build on 
s390x while it built there successfully in the past and you have two 
unresolved RC bugs.


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.


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/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=pytango



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017989: src:jellyfish: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: jellyfish
Version: 2.3.0-13
Severity: serious
Control: close -1 2.3.0-14
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1017261

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:jellyfish has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Although your package built on 
all official architectures by now, it's reported to FTBFS in bug 
#1017261 and also reproducible-builds.org shows your package FTBFS in 
both unstable and bookworm.


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 bookworm, 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/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=jellyfish



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017975: [Debian-on-mobile-maintainers] Bug#1017975: ModemManager does not install qmicli needed for unlocking scripts.

[Evangelos Ribeiro Tzaras]

Hi and thanks for your report!

On Tue, 2022-08-23 at 13:56 +0300, Ilja Sidoroff wrote:
> Package: modemmanager
> Version: 1.18.10-1
> Severity: normal
> 
> In reference to bug #1004447.
> 
> The FCC unlocking scripts (in /usr/share/ModemManager/fcc-
> unlock.available.d) 105b and 1199 use `qmicli-binary` to perform the
> unlocking operation. The binary, which is in libqmi-utils -package is
> not installed by default or as a dependency to modemmanager-package.
> If the binary is missing, the symptoms of the bug are as described in
> #1004447. This can probably simply be fixed by adding libqmi-utils as
> a dependency to modemmanager?

I don't think it should be a `Depends`, but a `Recommends:`

> 
> I also noticed that the script `1eac` uses mbimcli-binary, which also
> doesn't seem to installed by default, but I haven't examined that
> further.

same as above



-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#1017083: All sources are included, the bug report is invalid

[Teus Benschop]

Hello,

Thank you for looking into and reporting this issue.

The bug lists a couple of minified Javascript code that is included in the
package, and the bug report asserts that the original source, the
non-minified source, is not included in the source package.

I have checked all of the reported minified sources to find out whether the
source is reported correctly in the bug report, or whether the original
source is already included in the source code of the package.

Here is a list of all the reported files in the bug report, together with
my remarks on them.

[jquery/jquery-3.5.1.min.js]
The source is already included in this file: jquery/jquery-3.5.1.js

[jquery/jquery.touchSwipe.min.js]
The source is already included in this file: jquery/jquery.touchSwipe.js

[nicedit/nicedit.min.js]
The source is already included in this file: nicedit/nicedit.js

[notifit/notifit.min.js]
The source is already included in this file: notifit/notifit.js

[quill/1.1.5/quill.core.js]
The above is full source, not minified.

[quill/1.1.5/quill.js]
The above is full source, not minified.

[quill/1.1.5/quill.min.js]
The source is already included in this file: quill/1.1.5/quill.js

[quill/1.3.6/quill.core.js]
The above is full source, not minified.

[quill/1.3.6/quill.js]
The above is full source, not minified.

[quill/1.3.6/quill.min.js]
The source is already included in this file: quill/1.3.6/quill.js

[quill/quill.core.js]
The above is full source, not minified.

[quill/quill.js]
The above is full source, not minified.

[quill/quill.min.js]
The source is already included in this file: quill/quill.js

[rangy13/rangy-classapplier.min.js]
The source is already included in this file: rangy13/rangy-classapplier.js

[rangy13/rangy-core.min.js]
The source is already included in this file: rangy13/rangy-core.js

[rangy13/rangy-highlighter.min.js]
The source is already included in this file: rangy13/rangy-highlighter.js

[rangy13/rangy-selectionsaverestore.min.js]
The source is already included in this file:
rangy13/rangy-selectionsaverestore.js

[rangy13/rangy-serializer.min.js]
The source is already included in this file: rangy13/rangy-serializer.js

[rangy13/rangy-textrange.min.js]
The source is already included in this file: rangy13/rangy-textrange.js

Therefore my current impression is that all the items reported in this bug
were reported in error, and that the bug report seems to be invalid.

Please correct me if I'm wrong.

If the bug report is invalid, could it be closed?

The bug report, if it remains open, will cause the package to be removed
from the testing distribution. Something I'd like not to happen, in
particular as there seems to be no reason for that.

Met vriendelijke groeten,
With kind regards,

Teus Benschop
https://freesoftwareconsultants.nl
https://bibledit.org

Bug#1017393: buster-pu: package debian-security-support/1:10+2022.08.23

[Holger Levsen]

hi,

I've just uploaded this to buster for the coming point release:

$ debdiff debian-security-support_2020.06.21~deb10u1.dsc 
debian-security-support_10+2022.08.23.dsc|diffstat
 Makefile.PL  |1 +
 debian/changelog |   26 ++
 security-support-ended.deb10 |8 +++-
 security-support-limited |   12 ++--
 4 files changed, 36 insertions(+), 11 deletions(-)

$ debdiff debian-security-support_2020.06.21~deb10u1.dsc 
debian-security-support_10+2022.08.23.dsc
diff -Nru debian-security-support-2020.06.21~deb10u1/debian/changelog 
debian-security-support-10+2022.08.23/debian/changelog
--- debian-security-support-2020.06.21~deb10u1/debian/changelog 2020-07-10 
19:29:25.0 +0200
+++ debian-security-support-10+2022.08.23/debian/changelog  2022-08-23 
18:57:12.0 +0200
@@ -1,3 +1,29 @@
+debian-security-support (1:10+2022.08.23) buster; urgency=medium
+
+  * Introduce release based versioning and add an epoch to achieve that.
+See https://lists.debian.org/20200817100153.ga...@layer-acht.org and
+follow-ups. Closes: #988321
+  * Makefile.PL: strip epoch from internal version just like ~deb10u1 etc are
+also dropped.
+  * Update security-support-ended.deb10 from 1:12+2022.08.12 from unstable,
+thus adding these packages to it:
+- chromium
+- ckeditor3
+- gpac
+- libspring-java
+- slurm-llnl
+- xen
+  * Update security-support-limited from 1:12+2022.08.12 from unstable,
+thus adding:
+- golang
+- khtml
+  * Drop libv8-3.14, mosjz, mosjz24, swftools and webkitgtk from
+security-support-limited as they were only present in stretch and earlier.
+  * Also drop glpi, ltp and wine-gecko-2.(21|24) from security-support-limited
+as they were only present in jessie or earlier.
+
+ -- Holger Levsen   Tue, 23 Aug 2022 18:57:12 +0200
+
 debian-security-support (2020.06.21~deb10u1) buster; urgency=medium
 
   * Rebuild for buster.
diff -Nru debian-security-support-2020.06.21~deb10u1/Makefile.PL 
debian-security-support-10+2022.08.23/Makefile.PL
--- debian-security-support-2020.06.21~deb10u1/Makefile.PL  2018-03-16 
15:39:59.0 +0100
+++ debian-security-support-10+2022.08.23/Makefile.PL   2022-08-19 
16:25:59.0 +0200
@@ -12,6 +12,7 @@
 my $VERSION=$changelog->{Version};
 
 $VERSION =~ s/~deb(.*)//;
+$VERSION =~ s/^[0-9]+://;
 
 WriteMakefile (
 'NAME' =>   'debian-security-support',
diff -Nru 
debian-security-support-2020.06.21~deb10u1/security-support-ended.deb10 
debian-security-support-10+2022.08.23/security-support-ended.deb10
--- debian-security-support-2020.06.21~deb10u1/security-support-ended.deb10 
2020-07-10 19:29:25.0 +0200
+++ debian-security-support-10+2022.08.23/security-support-ended.deb10  
2022-08-23 18:57:08.0 +0200
@@ -11,4 +11,10 @@
 #In the program's output, this is prefixed with "Details:"
 
 # none yet (please remove this line once this is not true anymore)
-libperlspeak-perl2.01-2  2020-04-16  
https://bugs.debian.org/954238 (CVE-2020-10674) and 
https://bugs.debian.org/954297 and 954298
+libperlspeak-perl2.01-2  2020-04-16  
https://bugs.debian.org/954238 (CVE-2020-10674) and 
https://bugs.debian.org/954297 and 954298
+xen  4.11.4+107-gef32c7afa2-12021-08-28  
https://xenbits.xen.org/docs/4.11-testing/SUPPORT.html#release-support
+chromium 90.0.4430.212-1~deb10u1 2022-01-14  
https://lists.debian.org/debian-security-announce/2022/msg00012.html
+slurm-llnl   18.08.5.2-1+deb10u2 2022-08-01  
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/39
+gpac 0.5.2-426-gc5ad4e4+dfsg5-5  2022-08-03  
https://lists.debian.org/debian-lts/2022/05/msg00043.html
+libspring-java   4.3.5-1+deb9u1  2022-08-09  
https://lists.debian.org/debian-lts/2022/08/msg1.html
+ckeditor33.6.6.1+dfsg-1  2022-08-09  
https://lists.debian.org/debian-lts/2022/08/msg1.html
diff -Nru debian-security-support-2020.06.21~deb10u1/security-support-limited 
debian-security-support-10+2022.08.23/security-support-limited
--- debian-security-support-2020.06.21~deb10u1/security-support-limited 
2020-07-10 19:29:25.0 +0200
+++ debian-security-support-10+2022.08.23/security-support-limited  
2022-08-23 18:57:08.0 +0200
@@ -10,13 +10,9 @@
 binutilsOnly suitable for trusted content; see 
https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
 ganglia See README.Debian.security, only supported behind an 
authenticated HTTP zone, #702775
 ganglia-web See README.Debian.security, only supported behind an 
authenticated HTTP zone, #702776
-glpiOnly supported behind an authenticated HTTP zone for trusted 
users
-golang*See 

Bug#1017988: bluez: systemd: ConfigurationDirectory 'bluetooth' already exists but the mode is different

[Kevin Locke]

Package: bluez
Version: 5.65-1
Severity: minor

Dear Maintainer,

With bluez 5.65-1 and systemd 251.3-1, the following message is logged
on boot:

systemd[1234]: ConfigurationDirectory 'bluetooth' already exists but the mode 
is different. (File system: 755 ConfigurationDirectoryMode: 555)

My understanding is that this occurs because bluez creates the
/etc/bluetooth directory with mode 0755, yet
/lib/systemd/system/bluetooth.service contains

[Service]
ConfigurationDirectory=bluetooth
ConfigurationDirectoryMode=0555

Creating /etc/bluetooth with mode 0555 or setting
ConfigurationDirectoryMode to 0755 should resolve the warning.

Thanks,
Kevin


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

Kernel: Linux 6.0.0-rc2 (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 bluez depends on:
ii  dbus [default-dbus-system-bus]  1.14.0-2
ii  init-system-helpers 1.64
ii  kmod30+20220630-3
ii  libasound2  1.2.7.2-1
ii  libc6   2.34-4
ii  libdbus-1-3 1.14.0-2
ii  libdw1  0.187-1
ii  libglib2.0-02.72.3-1+b1
ii  libreadline88.1.2-1.2
ii  libudev1251.3-1
ii  lsb-base11.2
ii  udev251.3-1

bluez recommends no packages.

Versions of packages bluez suggests:
pn  pulseaudio-module-bluetooth  

-- no debconf information

Bug#1016625: bart-cuda: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'

[Martin Uecker]

I think I fixed this. At least it compiles locally in
a sid pbuilder environment, but I needed to build-depend
on gcc-10. 

Martin

Am Sonntag, den 07.08.2022, 13:06 +0530 schrieb Nilesh Patra:
> Hi Martin,
> 
> [CC'ing both your email addresses since I don't know which one you use]
> 
> Since this is your package, could you consider taking a look please?
> 
> On Thu, 04 Aug 2022 04:31:30 +0200 Andreas Beckmann  wrote:
> > Source: bart-cuda
> > Version: 0.7.00-5
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source
> > 
> > Hi,
> > 
> > bart-cuda recently started to FTBFS in sid, while it still succeeds in
> > testing.
> > 
> > /usr//bin/nvcc -DUSE_CUDA -Xcompiler -fPIC -Xcompiler -fopenmp -O3  
> > -I/build/bart-cuda-
> > 0.7.00/src/ -m64 -ccbin gcc -c 
> > /build/bart-cuda-0.7.00/src/wavelet/wl3-cuda.cu -o /build/bart-
> > cuda-0.7.00/src/wavelet/wl3-cuda.o
> > /usr/include/c++/10/type_traits:71:52: error: redefinition of 'constexpr 
> > const _Tp
> > std::integral_constant<_Tp, __v>::value'
> >71 |   template
> >   |^
> >
> > /usr/include/c++/10/type_traits:59:29: note: 'constexpr const _Tp value' 
> > previously declared
> > here
> >59 |   static constexpr _Tp  value = __v;
> >   | ^
> > make[2]: *** [Makefile:332: /build/bart-cuda-0.7.00/src/wavelet/wl3-cuda.o] 
> > Error 1
> > 
> > Andreas

Bug#1017987: bullseye-pu: package debian-security-support/1:11+2022.08.23

[Holger Levsen]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

I've uploaded this now for the next bullseye point release:

$ debdiff debian-security-support_11+2021.03.19.dsc 
debian-security-support_11+2022.08.23.dsc|diffstat
 debian/changelog |   13 +
 security-support-limited |   11 +++
 2 files changed, 16 insertions(+), 8 deletions(-)

$ debdiff debian-security-support_11+2021.03.19.dsc 
debian-security-support_11+2022.08.23.dsc
diff -Nru debian-security-support-11+2021.03.19/debian/changelog 
debian-security-support-11+2022.08.23/debian/changelog
--- debian-security-support-11+2021.03.19/debian/changelog  2021-03-19 
21:58:42.0 +0100
+++ debian-security-support-11+2022.08.23/debian/changelog  2022-08-23 
18:26:34.0 +0200
@@ -1,3 +1,16 @@
+debian-security-support (1:11+2022.08.23) bullseye; urgency=medium
+
+  * Update security-support-limited from 1:12+2022.08.19 from unstable,
+- add khtml. Closes: #1004293.
+- add openjdk-17 and point to the bullseye release notes (as discussed in
+  #975016).
+- for golang, point to the bullseye manual instead the buster one.
+- drop mozjs52 and mozjs60 as they were only present in buster.
+- drop libv8-3.14, mozjs, mozjs24, swftools and webkitgtk as they were
+  only present in stretch and earlier.
+
+ -- Holger Levsen   Tue, 23 Aug 2022 18:26:34 +0200
+
 debian-security-support (1:11+2021.03.19) unstable; urgency=medium
 
   [ Utkarsh Gupta ]
diff -Nru debian-security-support-11+2021.03.19/security-support-limited 
debian-security-support-11+2022.08.23/security-support-limited
--- debian-security-support-11+2021.03.19/security-support-limited  
2021-01-25 13:28:55.0 +0100
+++ debian-security-support-11+2022.08.23/security-support-limited  
2022-08-23 18:24:26.0 +0200
@@ -11,22 +11,17 @@
 cython  Only included for building packages, not running them, #975058
 ganglia See README.Debian.security, only supported behind an 
authenticated HTTP zone, #702775
 ganglia-web See README.Debian.security, only supported behind an 
authenticated HTTP zone, #702776
-golang*See 
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
+golang*See 
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#golang-static-linking
 kde4libskhtml has no security support upstream, only for use on 
trusted content
-libv8-3.14  Not covered by security support, only suitable for trusted 
content
-mozjs   Not covered by security support, only suitable for trusted 
content
-mozjs24 Not covered by security support, only suitable for trusted 
content
-mozjs52 Not covered by security support, only suitable for trusted 
content
-mozjs60 Not covered by security support, only suitable for trusted 
content
+khtml   khtml has no security support upstream, only for use on 
trusted content, see #1004293
 mozjs68 Not covered by security support, only suitable for trusted 
content, see #959804
 mozjs78 Not covered by security support, only suitable for trusted 
content, see #959804
 ocsinventory-server Only supported behind an authenticated HTTP zone
+openjdk-17 See 
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#openjdk-17
 python2.7   Only included for building packages, not running them, #975058
 python-stdlib-extensions Only included for building packages, not running 
them, #975058
 qtwebengine-opensource-src No security support upstream and backports not 
feasible, only for use on trusted content
 qtwebkitNo security support upstream and backports not feasible, only 
for use on trusted content
 qtwebkit-opensource-src No security support upstream and backports not 
feasible, only for use on trusted content
 sql-ledger  Only supported behind an authenticated HTTP zone
-swftoolsNot covered by security support, only suitable for trusted 
content
-webkitgtk   No security support upstream and backports not feasible, only 
for use on trusted content
 zoneminder  See README.Debian.security, only supported behind an 
authenticated HTTP zone, #922724

Thanks for all your SRM work!


-- 
cheers,
Holger

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

The system isn't broken. It was built this way.


signature.asc
Description: PGP signature

Bug#1003798: fluxbox: replace FbRootWindow::depth with maxDepth

[Max Nikulin]

The issue was reported earlier for fluxbox-1.3.5 package as
https://bugs.debian.org/743772

Bug#743772: fluxbox: Cannot move Gnome 3.12 applications

[Max Nikulin]

Tags: patch

The issue was fixed after fluxbox-1.3.7 release and 1.4 has not
completed. I have backported the fix to version 1.3.5 currently
available in Debian.

Notice that the same bug is reported for experimental as
https://bugs.debian.org/1003798

More information is available in
http://git.fluxbox.org/fluxbox.git/commit/?id=dcdde4d32c93d01df205bc06d7dfcbd356be031f
https://sourceforge.net/p/fluxbox/bugs/1102/
https://sourceforge.net/p/fluxbox/bugs/1058/

The problem is quite severe though it is not 100% reproducible.
As a workaround, restart fluxbox.Backport of the following commit:

From dcdde4d32c93d01df205bc06d7dfcbd356be031f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Thomas=20L=C3=BCbking?= 
Date: Sat, 25 Jun 2016 22:25:48 +0200
Subject: replace FbRootWindow::depth with maxDepth

The depth member of FbWindow was abused to store the maximum depth
but that gets overridden with geometry changes of the root window
(screen layout changes) so we store and read the value explicitly while
::depth() maintains the actual depth of the root window

The result of this is that frames for ARGB windows were created with a
wrong depth and failed to reparent the client window.

BUG: 1102
BUG: 1058
---
 src/FbRootWindow.cc | 7 ---
 src/FbRootWindow.hh | 2 ++
 src/FbWinFrame.cc   | 4 ++--
 src/Screen.cc   | 2 +-
 4 files changed, 9 insertions(+), 6 deletions(-)

--- a/src/FbRootWindow.cc
+++ b/src/FbRootWindow.cc
@@ -30,7 +30,8 @@
 m_colormap(0),
 m_decorationDepth(0),
 m_decorationVisual(0),
-m_decorationColormap(0) {
+m_decorationColormap(0),
+m_maxDepth(depth()) {
 
 Display *disp = FbTk::App::instance()->display();
 
@@ -55,9 +56,9 @@
 
 for (int i = 0; i < vinfo_nitems; i++) {
 if ((DefaultDepth(disp, screen_num) < vinfo_return[i].depth)
-&& (depth() < vinfo_return[i].depth)){
+&& (m_maxDepth < vinfo_return[i].depth)){
 m_visual = vinfo_return[i].visual;
-setDepth(vinfo_return[i].depth);
+m_maxDepth = vinfo_return[i].depth;
 }
 
 if((m_decorationDepth < vinfo_return[i].depth)
--- a/src/FbRootWindow.hh
+++ b/src/FbRootWindow.hh
@@ -41,6 +41,7 @@
 int decorationDepth() const { return m_decorationDepth; }
 Visual *decorationVisual() const { return m_decorationVisual; }
 Colormap decorationColormap() const { return m_decorationColormap; }
+int maxDepth() const { return m_maxDepth; }
 
 private:
 Visual *m_visual;
@@ -49,6 +50,7 @@
 int m_decorationDepth;
 Visual *m_decorationVisual;
 Colormap m_decorationColormap;
+int m_maxDepth;
 };
 
 #endif // FBROOTWINDOW_HH
--- a/src/FbWinFrame.cc
+++ b/src/FbWinFrame.cc
@@ -60,8 +60,8 @@
  ButtonMotionMask | EnterWindowMask |
  LeaveWindowMask, true, false,
  client_depth, InputOutput,
- ((client_depth == 32) && (screen.rootWindow().depth() == 32) ? screen.rootWindow().visual() : CopyFromParent),
- ((client_depth == 32) && (screen.rootWindow().depth() == 32) ? screen.rootWindow().colormap() : CopyFromParent)),
+ (client_depth == screen.rootWindow().maxDepth() ? screen.rootWindow().visual() : CopyFromParent),
+ (client_depth == screen.rootWindow().maxDepth() ? screen.rootWindow().colormap() : CopyFromParent)),
 m_layeritem(window(), *screen.layerManager().getLayer(ResourceLayer::NORMAL)),
 m_titlebar(m_window, 0, 0, 100, 16,
ButtonPressMask | ButtonReleaseMask |
--- a/src/Screen.cc
+++ b/src/Screen.cc
@@ -427,7 +427,7 @@
 "using visual 0x%lx, depth %d\n",
 "informational message saying screen number (%d), visual (%lx), and colour depth (%d)").c_str(),
 screenNumber(), XVisualIDFromVisual(rootWindow().visual()),
-rootWindow().depth());
+rootWindow().maxDepth());
 #endif // DEBUG
 
 FbTk::EventManager *evm = FbTk::EventManager::instance();

Bug#1017986: openmrac RFP

[Vojtěch Salajka]

Package: openmrac

Severity: wishlist
Version: 1.0
URL: https://github.com/Franticware/OpenMRac
License: BSD
Programming Lang: C++
Description: 3D split-screen racing game




Game data are CC0 licensed:

https://github.com/Franticware/OpenMRac-data

Bug#1017840: debian-security-support: cannot create /var/lib/debian-security-support/security-support.semaphore: Permission

[Holger Levsen]

On Tue, Aug 23, 2022 at 05:41:22PM +0200, Christoph Anton Mitterer wrote:
> It also seems as if neither that director or its files nor the created
> user is ever cleaned up on purge, but left behind as cruft forever.

users must not be cleaned up (=removed) on package removal, so the
only thing purge should do is remove /var/lib/debian-security-support/


-- 
cheers,
Holger

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

figures don't lie, but liars figure.


signature.asc
Description: PGP signature

Bug#1017356: libpmix2: symbol lookup error: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_ext3x.so: undefined symbol: pmix_value_load

[Drew Parsons]

Source: pmix
Followup-For: Bug #1017356
Control: reopen -1
Control: found 1017356 pmix/4.2.0-2

Adrian's last comments still apply all the same.
The problem is still there.

(tests of version 4.2.0-1 in experimental get run in unstable, see
https://ci.debian.net/packages/m/mpi4py/unstable/amd64/ )

Bug#1017985: roger-router: Fails to build with evolution-data-server 3.45

[Jeremy Bicha]

Source: evolution-data-server
Version: 2.2.1-1
Severity: important
Forwarded: https://gitlab.com/tabos/rogerrouter/-/issues/140
Tags: ftbfs upstream

roger-router fails to build with evolution-data-server 3.45, currently
in Debian Experimental.

Thank you,
Jeremy Bicha

Bug#1017943: schroot: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Hello Christoph,
On Tue, Aug 23, 2022 at 09:12:44AM +0200, Christoph Biedl wrote:
> Control: tags 1017943 pending
> 
> Helge Kreutzmann wrote...
> 
> > Please find the initial German debconf translation for schroot
> > attached.
> 
> Thanks, applied.
> 
> > "Please rename or remove them before installing a newer version of schroot. 
> >  "
> > "For instructions, see /usr/share/doc/schroot/NEWS.gz or  > "org/shelter/reschroot/src/branch/main/NEWS>, starting at \"Major changes 
> > in "
> > "1.6.13\"."
> 
> The text at that URL is in English only. I don't know how you l10n folks
> handle such a situation but I'm open for suggestions. It just seemed
> unwise to put all that information into the debconf dialog.

Translation ressources are always scarse. So my personal suggestion
would be to put enough information (as you did, in my opinion) into
the Debconf dialog and refer to other, typically not localized text
for background.

Technically, it's possible to translate lots of things, like NEWS or
webpages. However, I doubt the former is done much and even the latter
is lacking translators (see my first sentence).

But I'm just one translator. You may want to raise this on
debian-l18n@l.d.o.

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#1017742: po4a: Please provide marker for double strings during po4a-gettextize

[Helge Kreutzmann]

Hello Martin,
On Tue, Aug 23, 2022 at 12:46:03PM +0200, Martin Quinson wrote:
> I get a pot file with a single msgid:
> 
> ```
> #, fuzzy, markdown-text, no-wrap
> msgid "hello"
> msgstr ""
> "#-#-#-#-#  file1:1 (type Title #)  #-#-#-#-#\n"
> "HELLO\n"
> "#-#-#-#-#  file1:3 (type: Title ##)  #-#-#-#-#\n"
> "SUBTITLE\n"
> "#-#-#-#-#  file1:5 (type: Plain text)  #-#-#-#-#\n"
> "SAMPLE PARAGRAPH."
> ```
> 
> I think it's much much better than the previous thing. Thanks again for
> reporting the issue, I'm glad of that new version :)

That is indeed what looks familiar and really a good solution.

Thanks for your hard work.

(And now back to translation the updated documentation ...)

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#1009815: debmutate.watch: Use perl-compatible regular expressions

[Bastian Germann]

On Mon, 18 Apr 2022 15:22:27 + Jelmer Vernooij  wrote:

debmutate.watch currently uses Python's default re module, which supports a
slightly different syntax.

We should ideally switch to the pcre module.


I see that you have packaged and switched to that module. It would have been nicer to package the pcre2 module because 
pcre introduced one more dependency on pcre3 which should be phased out one day. There is already a mass bug filing and 
transition tracker for that.

Bug#1017840: debian-security-support: cannot create /var/lib/debian-security-support/security-support.semaphore: Permission

[Christoph Anton Mitterer]

Hey Holger.


It also seems as if neither that director or its files nor the created
user is ever cleaned up on purge, but left behind as cruft forever.

Or did I oversee something in the posrm?


Thanks,
Chris.

Bug#1017984: RM: libpcre++ -- RoQA; orphaned; unmaintained; no-r-deps; blocks pcre transition

[Bastian Germann]

Package: ftp.debian.org

libpcre++ is not compatible with pcre2 and one of the blocking packages for 
pcre3's removal.
The package does not have any reverse (build)dependencies, so removing should 
be fine.

It is orphaned and not maintained upstream.

Bug#1011196: linux-image-5.17.0-2-amd64: Geek Out USB sound card fails to initialise

[Renato Gallo]

where can I buy one ?
I am curious to test it on 6.0-rc2

On Tue, Aug 23, 2022 at 5:30 PM Lennert Van Alboom 
wrote:

> Quick update, still broken in 5.18 (unstable) and 5.19 (experimental).
>
> Some potentially useful syslog from trying with 5.19.0-trunk-amd64:
>
> Aug 23 17:12:30 Nesbitt kernel: [  188.154086] usb 3-6: new high-speed USB
> device number 5 using xhci_hcd
> Aug 23 17:12:30 Nesbitt kernel: [  188.303314] usb 3-6: New USB device
> found, idVendor=2522, idProduct=0007, bcdDevice=15.02
> Aug 23 17:12:30 Nesbitt kernel: [  188.303323] usb 3-6: New USB device
> strings: Mfr=1, Product=3, SerialNumber=0
> Aug 23 17:12:30 Nesbitt kernel: [  188.303325] usb 3-6: Product: Geek Out
> HD Audio 1V5
> Aug 23 17:12:30 Nesbitt kernel: [  188.303327] usb 3-6: Manufacturer: LH
> Labs
> Aug 23 17:12:30 Nesbitt mtp-probe: checking bus 3, device 5:
> "/sys/devices/pci:00/:00:14.0/usb3/3-6"
> Aug 23 17:12:30 Nesbitt mtp-probe: bus: 3, device: 5 was not an MTP device
> Aug 23 17:12:30 Nesbitt kernel: [  188.389783] usb 3-6: 1:2 : unsupported
> format bits 0x1
> Aug 23 17:12:31 Nesbitt kernel: [  188.460882] usbcore: registered new
> interface driver snd-usb-audio
> Aug 23 17:12:31 Nesbitt mtp-probe: checking bus 3, device 5:
> "/sys/devices/pci:00/:00:14.0/usb3/3-6"
> Aug 23 17:12:31 Nesbitt mtp-probe: bus: 3, device: 5 was not an MTP device
> Aug 23 17:12:31 Nesbitt systemd-udevd[2217]: controlC1: Process
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime
> restore 1' failed with exit code 99.
> Aug 23 17:12:31 Nesbitt systemd[1208]: Reached target Sound Card.
> Aug 23 17:12:36 Nesbitt kernel: [  193.658813] usb 3-6: 1:1:
> usb_set_interface failed (-110)
> Aug 23 17:12:36 Nesbitt kernel: [  193.659333] usb 3-6: 1:0:
> usb_set_interface failed (-71)
> Aug 23 17:12:36 Nesbitt kernel: [  193.660249] usb 3-6: 1:0:
> usb_set_interface failed (-71)
> Aug 23 17:12:36 Nesbitt kernel: [  193.661022] usb 3-6: 1:1:
> usb_set_interface failed (-71)
> Aug 23 17:12:36 Nesbitt kernel: [  193.661169] usb 3-6: 1:0:
> usb_set_interface failed (-71)
>
>
> Relevant thread at Arch about what appears to be the same issue:
> https://bugs.archlinux.org/task/70636
>
> Relevant thread on linux-usb mailinglist:
> https://www.spinics.net/lists/linux-usb/msg228518.html

Bug#1017958: tiff: Don't build with LERC on i386

[Jeremy Bicha]

To be more specific, lerc requires numpy and Ubuntu doesn't want to
build numpy for i386.

So Ubuntu would be required to manually merge tiff packaging updates
if my patch isn't accepted.

Thanks,
Jeremy Bicha

Bug#1011196: linux-image-5.17.0-2-amd64: Geek Out USB sound card fails to initialise

[Lennert Van Alboom]

Quick update, still broken in 5.18 (unstable) and 5.19 (experimental).

Some potentially useful syslog from trying with 5.19.0-trunk-amd64:

Aug 23 17:12:30 Nesbitt kernel: [  188.154086] usb 3-6: new high-speed USB 
device number 5 using xhci_hcd
Aug 23 17:12:30 Nesbitt kernel: [  188.303314] usb 3-6: New USB device found, 
idVendor=2522, idProduct=0007, bcdDevice=15.02
Aug 23 17:12:30 Nesbitt kernel: [  188.303323] usb 3-6: New USB device strings: 
Mfr=1, Product=3, SerialNumber=0
Aug 23 17:12:30 Nesbitt kernel: [  188.303325] usb 3-6: Product: Geek Out HD 
Audio 1V5
Aug 23 17:12:30 Nesbitt kernel: [  188.303327] usb 3-6: Manufacturer: LH Labs
Aug 23 17:12:30 Nesbitt mtp-probe: checking bus 3, device 5: 
"/sys/devices/pci:00/:00:14.0/usb3/3-6"
Aug 23 17:12:30 Nesbitt mtp-probe: bus: 3, device: 5 was not an MTP device
Aug 23 17:12:30 Nesbitt kernel: [  188.389783] usb 3-6: 1:2 : unsupported 
format bits 0x1
Aug 23 17:12:31 Nesbitt kernel: [  188.460882] usbcore: registered new 
interface driver snd-usb-audio
Aug 23 17:12:31 Nesbitt mtp-probe: checking bus 3, device 5: 
"/sys/devices/pci:00/:00:14.0/usb3/3-6"
Aug 23 17:12:31 Nesbitt mtp-probe: bus: 3, device: 5 was not an MTP device
Aug 23 17:12:31 Nesbitt systemd-udevd[2217]: controlC1: Process 
'/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
restore 1' failed with exit code 99.
Aug 23 17:12:31 Nesbitt systemd[1208]: Reached target Sound Card.
Aug 23 17:12:36 Nesbitt kernel: [  193.658813] usb 3-6: 1:1: usb_set_interface 
failed (-110)
Aug 23 17:12:36 Nesbitt kernel: [  193.659333] usb 3-6: 1:0: usb_set_interface 
failed (-71)
Aug 23 17:12:36 Nesbitt kernel: [  193.660249] usb 3-6: 1:0: usb_set_interface 
failed (-71)
Aug 23 17:12:36 Nesbitt kernel: [  193.661022] usb 3-6: 1:1: usb_set_interface 
failed (-71)
Aug 23 17:12:36 Nesbitt kernel: [  193.661169] usb 3-6: 1:0: usb_set_interface 
failed (-71)


Relevant thread at Arch about what appears to be the same issue: 
https://bugs.archlinux.org/task/70636 

Relevant thread on linux-usb mailinglist: 
https://www.spinics.net/lists/linux-usb/msg228518.html

publickey - lennert@vanalboom.org - 0x0320C886.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#1017958: tiff: Don't build with LERC on i386

[Renato Gallo]

hello,

is there really still anyone using i386 out there ?

On Tue, Aug 23, 2022 at 5:09 PM Jeremy Bicha 
wrote:

> Right, it's a tradeoff.
>
> Is having lerc compression support critical enough on i386 to justify
> making extra work for Ubuntu? It already is not critical enough to be
> enabled on some Debian release architectures.
>
> Most people using Debian should be using amd64.
>
> Thank you,
> Jeremy Bicha
>
>

Bug#1017958: tiff: Don't build with LERC on i386

[Jeremy Bicha]

Right, it's a tradeoff.

Is having lerc compression support critical enough on i386 to justify
making extra work for Ubuntu? It already is not critical enough to be
enabled on some Debian release architectures.

Most people using Debian should be using amd64.

Thank you,
Jeremy Bicha

Bug#1017983: reprepro: upgrade from 5.3.0-1.2 to 5.4.1-1 loses data

[Mark Hymers]

Package: reprepro
Version: 5.4.1-1
Severity: important
Tags: upstream

Hello,

I recently tested an upgrade of reprepro from the version in bullseye
(5.3.0-1.2) to the experimental version (5.4.1-1) to allow us to use
the Limit feature.

After the database migration, no packages are found in the database.

This is a fairly large packages database (around about 4.6GiB on disk)
with a lot of suites etc.  After some debugging, I find that during
the upgrade process (in databases.c), this while loop is never actually
entered:

while (cursor_next(legacy_databases, databases_cursor, , )) {

}...

which seems to cause the migration to fail (nothing is done) and new
databases to be created the next time you use a reprepro command
leading to nothing being present in any of the suites.

I've kept a copy of the old packages database but, as mentioned, it's
large so making it available is tricky.

It's been many years since I worked with BDB, so any suggestions as to
how to debug further would be helpful.

Thanks,

Mark


signature.asc
Description: PGP signature

Bug#965514: falselogin: diff for NMU version 0.3-4.1

[Braulio]

Control: tags 965514  + patch pending
Control: tags 999289  + patch pending

Dear maintainer,

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

Regards.

reverted:
--- falselogin-0.3/debian/compat
+++ falselogin-0.3.orig/debian/compat
@@ -1 +0,0 @@
-5
diff -u falselogin-0.3/debian/rules falselogin-0.3/debian/rules
--- falselogin-0.3/debian/rules
+++ falselogin-0.3/debian/rules
@@ -30,7 +30,7 @@
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/falselogin
@@ -56,4 +56,6 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+build-arch: build
+build-indep: build
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install
diff -u falselogin-0.3/debian/changelog falselogin-0.3/debian/changelog
--- falselogin-0.3/debian/changelog
+++ falselogin-0.3/debian/changelog
@@ -1,3 +1,18 @@
+falselogin (0.3-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Using new DH level format. Consequently:
+  - debian/compat: removed.
+  - debian/control: changed from 'debhelper' to 'debhelper-compat' in
+Build-Depends field and bumped level to 13.
+  - debian/rules: using 'dh_prep' instead of 'dh_clean -k' because the
+'-k' option is not supported since compat 12.
+  - Closes: #965514
+  * debian/rules: added missing targets build-arch and build-indep.
+(Closes: #999289)
+
+ -- Braulio Henrique Marques Souto   Tue, 23 Aug 2022 09:00:00 -0300
+
 falselogin (0.3-4) unstable; urgency=low
 
   * New maintainer.
diff -u falselogin-0.3/debian/control falselogin-0.3/debian/control
--- falselogin-0.3/debian/control
+++ falselogin-0.3/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Kevin Zambrano 
 Standards-Version: 3.8.0
-Build-Depends: debhelper (>= 5), publib-dev (>= 0.38-2)
+Build-Depends: debhelper-compat (= 13), publib-dev (>= 0.38-2)
 
 Package: falselogin
 Architecture: any

Bug#1016831: closed by Steven Robbins (Re: libminc: FTBFS on mipsel, mips64el)

[Sebastian Ramacher]

On 2022-08-22 11:21:19 -0500, Steven Robbins wrote:
> On Mon, 22 Aug 2022 09:24:41 +0200 Sebastian Ramacher  
> wrote:
> 
> 
> > > I can't reproduce this.  The main difference between the one that built 
> > > and 
> the 
> > > one that didn't is the new libc, so that's the most likely culprit.
> > 
> > The 4th attempt on the buildds filed again: 
> > https://buildd.debian.org/status/
> fetch.php?pkg=libminc=mips64el=2.4.03-5+b1=1661136219=0
> > 
> > Reopening. Please only close this bug when libminc is able to build on
> > the buildds again.
> 
> I can't debug this!  It builds OK in both the mipsel and mips64el chroots on 
> porterbox eller.  See https://lists.debian.org/debian-devel/2022/08/
> msg00200.html
> 
> Is there something broken on the buildd? 

Maybe the mips porters have a better idea. You could try contacting them
at debian-m...@lists.debian.org. If that also doesn't lead to a solution
for this issue, we will have to get libmimc's binaries for mips64el
removed.

Cheers
-- 
Sebastian Ramacher

Bug#1016864: RFS: librcc/0.2.13+ds-1 [QA] -- RusXMMS Charset Conversion library

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #1016864
Control: tags -1 moreinfo

Hi Hugh,

Thanks for working on librcc!

here's a quick (incomplete) review:

+ Update Vcs-* fields and point to GitHub.

VCS* is for the packaging, not for upstream. The link on Github seems not to
have the (latesdt) packaging

- Adding new packagages

I'd suggest to upload to experimental then, to clear NEW first.
This to avoid breaking reverse depdendenies (moc)

Speaking of, have you checked if moc still works with the new package
(is the new version ABI compatible?)

- Multiarch d/*.install

Instead of using "*" for the multiarch path, you can use
${DEB_HOST_MULTIARCH} with modern debhelper.

- static library

As you are modernizing the package, time to drop the static library?




-- 
tobi

Bug#1017972: (no subject)

[Renato Gallo]

you generally cannot insmod a module compiled from another kernel 

On Tue, Aug 23, 2022 at 3:39 PM Roman Kalugin  wrote:

>
> Unfortunately I can't use patches yet. I can say that I tried to run the
> module from another kernel and I get an error.
>
> sudo insmod
>
> /lib/modules/5.18.0-3-amd64/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko
>
> [sudo] password for alter:
> insmod: ERROR: could not insert module
> /lib/modules/5.18.0-3-amd64/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko:
>
> Invalid module format
>
> I thought you could add it to the default kernel
>
> --
> Best regards, Roman Kalugin
>
> e-mail: kalugi...@gmail.com
>
>

Bug#1017509: needs matrix-common<2.0.0,>=1.2.1, but got matrix-common==1.1.0

[Andrej Shadura]

Control: notfound -1 1.63.0-1~bpo11+1

Hi,

On Tue, 23 Aug 2022, at 16:04, joffrey575 wrote:
> I installed python3-matrix-common package in version 1.2.1-1~bpo11+1 
> bullseye-backports

As you say yourself, you have the necessary package version installed, but 
synapse doesn’t see it:

> août 23 15:56:25 serveur python3[1272851]: ERROR:root:Synapse 1.63.0 needs 
> matrix-common<2.0.0,>=1.2.1, but got matrix-common==1.1.0

This means your system is broken — most probably you installed matrix-common 
using pip or something, and it prevents the one from distribution from being 
used.

-- 
Cheers,
  Andrej

Bug#1017509: needs matrix-common<2.0.0,>=1.2.1, but got matrix-common==1.1.0

[joffrey575]

I installed python3-matrix-common package in version 1.2.1-1~bpo11+1 
bullseye-backports


In the file "/usr/lib/python3/dist-packages/synapse/util/__init__.py", 
at the end,


+SYNAPSE_VERSION = "v1.63.0"
-#SYNAPSE_VERSION = get_distribution_version_string("matrix-synapse", 
__file__)


After start the service, it give me "needs matrix-common<2.0.0,>=1.2.1"

░░ L'unité (unit) matrix-synapse.service a commencé à démarrer.
août 23 15:56:25 serveur python3[1272851]: ERROR:root:Synapse 1.63.0 
needs matrix-common<2.0.0,>=1.2.1, but got matrix-common==1.1.0
août 23 15:56:25 serveur python3[1272851]: Missing Requirements: 
"matrix-common"

août 23 15:56:25 serveur python3[1272851]: To install run:
août 23 15:56:25 serveur python3[1272851]: pip install --upgrade --force 
"matrix-common"
août 23 15:56:25 serveur systemd[1]: matrix-synapse.service: Control 
process exited, code=exited, status=1/FAILURE


A solution ?

Bug#1015218: Splitting bug report

[Martina Ferrari]

clone 1015218 -2
retitle 1015218 consul: CVE-2021-37219 CVE-2021-38698
retitle -2 consul: CVE-2022-29153
thanks

I am splitting this bug in two, as the fixes for these CVEs are in 
different release trees (1.8 vs 1.9)


--
Martina Ferrari (Tina)

Bug#1017981: gnome-shell: client bug: timer event7 debounce: scheduled expiry is in the past

[Tobias Koeck]

Package: gnome-shell
Version: 3.38.6-1~deb11u1
Severity: important

Dear Maintainer,

Aug 23 15:44:38 tron-nb /usr/libexec/gdm-x-session[1670]: (EE) client bug: 
timer event7 debounce: scheduled expiry is in the past (-7ms), your system is 
too slow

and

pushModal: invocation of begin_modal failed

Gnome Shell freezes, it has to be relogin with Ctrl-F1 -> login

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

Kernel: Linux 5.18.0-0.deb11.3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  evolution-data-server3.38.3-1
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-atspi-2.0 2.44.1-1~bpo11+1
ii  gir1.2-freedesktop   1.66.1-1+b1
ii  gir1.2-gcr-3 3.38.1-2
ii  gir1.2-gdesktopenums-3.0 3.38.0-2
ii  gir1.2-gdm-1.0   3.38.2.1-1
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gnomebluetooth-1.03.34.3-2
ii  gir1.2-gnomedesktop-3.0  3.38.5-3
ii  gir1.2-gstreamer-1.0 1.18.4-2.1
ii  gir1.2-gtk-3.0   3.24.24-4+deb11u2
ii  gir1.2-gweather-3.0  3.36.1-3
ii  gir1.2-ibus-1.0  1.5.23-2
ii  gir1.2-mutter-7  3.38.6-2~deb11u2
ii  gir1.2-nm-1.01.38.4-1~bpo11+1
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-polkit-1.00.105-31+deb11u1
ii  gir1.2-rsvg-2.0  2.50.3+dfsg-1
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.66.2-1
ii  gnome-backgrounds3.38.0-1
ii  gnome-settings-daemon3.38.2-1
ii  gnome-shell-common   3.38.6-1~deb11u1
ii  gsettings-desktop-schemas3.38.0-2
ii  gstreamer1.0-pipewire0.3.19-4
ii  libatk-bridge2.0-0   2.38.0-4~bpo11+1
ii  libatk1.0-0  2.38.0-1~bpo11+1
ii  libc62.31-13+deb11u3
ii  libcairo21.16.0-5
ii  libecal-2.0-13.38.3-1
ii  libedataserver-1.2-253.38.3-1
ii  libgcr-base-3-1  3.38.1-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgjs0g 1.66.2-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.8-1
ii  libglib2.0-bin   2.66.8-1
ii  libgnome-autoar-0-0  0.2.4-3
ii  libgnome-desktop-3-193.38.5-3
ii  libgraphene-1.0-01.10.4+dfsg1-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libical3 3.0.9-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libmutter-7-03.38.6-2~deb11u2
ii  libnm0   1.38.4-1~bpo11+1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpolkit-agent-1-0  0.105-31+deb11u1
ii  libpolkit-gobject-1-00.105-31+deb11u1
ii  libpulse-mainloop-glib0  14.2-2
ii  libpulse014.2-2
ii  libsecret-1-00.20.4-2
ii  libsystemd0  251.3-1~bpo11+1
ii  libwayland-server0   1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxfixes3   1:5.0.3-2
ii  python3  3.9.2-3

Versions of packages gnome-shell recommends:
ii  bolt  0.9.1-1
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.38.2.1-1
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.38.4-1
ii  gnome-menus   3.36.0-1
ii  gnome-user-docs   3.38.2-1
ii  

Bug#1015967: RFS: psocksxx/1.1.1-3 -- psocksxx is a C++ wrapper for POSIX sockets

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #1015967

Uploaded.

Bug#1013267: fontforge: BDF font generation: FONT_ASCENT and FONT_DESCENT properties are missing

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/fontforge/fontforge/issues/5089

On 2022-06-20 13:44:55 +0200, Vincent Lefevre wrote:
> FontForge generate invalid BDF files with File → Generate Fonts.
> As a consequence, bdftopcf complains and the font is unusable.
> 
> To reproduce (e.g. without modifying the original font):
> 
>   fontforge /usr/share/fonts/X11/misc/6x13.pcf.gz
> 
> then generate the BDF file (choose 75 as the BDF resolution, as
> in the original font). Then
> 
> $ bdftopcf FixedMedium-13.bdf
> BDF Error on line 29: missing 'FONT_ASCENT' or 'FONT_DESCENT' properties
> bdftopcf: bdf input, FixedMedium-13.bdf, corrupt

I can reproduce the issue with the current upstream master.
So I have reported the bug upstream.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1017952: groupadd: invalid group ID '-1' when adding with --uid

[Samuel Thibault]

Marc Haber, le mar. 23 août 2022 15:02:04 +0200, a ecrit:
> thanks for spotting this. It was both a bug in the code and a big
> omission in our test suite. Both aspects are fixed now.
> 
> On Mon, Aug 22, 2022 at 10:11:24PM +0200, Samuel Thibault wrote:
> > Package: adduser
> > Version: 3.124
> > Severity: serious
> > Justification: Makes creating chroots fail
> 
> Do have the time to check the code from
> https://salsa.debian.org/debian/adduser/-/tree/debian-bug-1017952 ?

I tried it in my test case and it seems to work, thanks!

Samuel

Bug#994750: RFS: mazeofgalious/0.63+dfsg1-1 [ITA] -- The Maze of Galious

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #994750
Control: tags -1 moreinfo

Hi Pablo,

I've just saw that moreinfo has been removed from this RFS, so let's take 
another round
of review:

- There have been an NMU of the package, the changes of the NMU are
  not in your package. Please rebase your package to include this NMU.
  NMU version was: 0.62.dfsg2-4.1. (It could be that you just need to
  merge d/changelog, I did not check that.)

- You should fix as well:
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421648
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455401

- Wording suggestion for the first changelog entry would be:
   * New upstream release (Closes #…, #…, #…)
  (your sentence is fine but nonstandard; no need to fix, but it would be nice)

- d/README.Debian does not contain useful information, it should be deleted.

- d/changelog: There are undocumented changes to the packaging. Please make sure
  to document everything you change …
  e.g - that you are adopting the package (and you need to close the ITA bug)
  - Standard version updated
  - d/compat removed by B-D on debhelper_compat; also changing compat level
with that change.
  - all the changes to the patches are undocumented.
  - and many more undocumented changes.

- d/control
  - Extended description for the data package should also include the 
description
of the game, so that the desciption is descriptive if only looking at the 
data
package's one.
I'd copy the complete extended description of the main package and add -- as
a new paragraph -- the current data package description.
  - (optional) Please consider adding a VCS for the packaging; you can use
salsa.debian.org to host it.
  - (optional) Please consider to put the game under the games-team umbrella.

- if possible, add dep-3 headers to the patches to document them.
  if you are using quilt, quilt --header -e --dep3 will give you a start.

- the file d/dirs and d/mazeofgalious.dirs should not be required.

- lintian stuff that needs fixing:
  - W: mazeofgalious: description-synopsis-starts-with-article

(will be fixed when you fix above mentioned bugs)


  - W: mazeofgalious: package-contains-upstream-installation-documentation 
[usr/share/doc/mazeofgalious/INSTALL]
this file should not be installed

  - I: mazeofgalious source: anticipated-repack-count 0.63+dfsg1-1

it should be just "dfsg" without the "1".


  - I: mazeofgalious: extra-license-file [usr/share/doc/mazeofgalious/LICENSE.gz

the GPL license text should not be installed.

  - I: mazeofgalious: hardening-no-bindnow [usr/games/mog]
  - I: mazeofgalious: hardening-no-fortify-functions [usr/games/mog]

The upstream Makefile hardcodes (overwrites) compiler and linker flags. You
need to patch it so that those set from dpkg-builpackage are appended.

This is a regression, as in the previous package there was a patch 
addressing
this.

- d/copyright should also mention, for debian/* all previous maintainers and
  when they maintained the package.

- (optional) the package-contains-documentation-outside-usr-share-doc lintian
  findings should be overridden, it adds a lot of noise to the lintian report 
and as
  those seems to be level data, linitian is wrong…

- changelog says: "Also modified start.pcx images, as specified in #341501",
  but looking at start.pcx I don't see that #641501 is addressed.

-- 
tobi

Bug#1017862: scipy: FTBFS on 32bit arches fixed

[Sven Mueller]

fixed 1017862 1.8.1-8
thanks

Upload of 1.8.1-8 contained
https://salsa.debian.org/python-team/packages/scipy/-/blob/master/debian/patches/pythran_type_PR16646.patch
- which fixes this both according to the original failure report and
my build of scipy for i386.

Cheers,
Sven

Bug#1017972: (no subject)

[Roman Kalugin]

Unfortunately I can't use patches yet. I can say that I tried to run the 
module from another kernel and I get an error.


sudo insmod 
/lib/modules/5.18.0-3-amd64/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko


[sudo] password for alter:
insmod: ERROR: could not insert module 
/lib/modules/5.18.0-3-amd64/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko: 
Invalid module format


I thought you could add it to the default kernel

--
Best regards, Roman Kalugin

e-mail: kalugi...@gmail.com

Bug#1017973: cups-browsed: Unable to print after resume from suspend

[Brian Potkin]

tags 1017973 upstream
thanks




On Tue 23 Aug 2022 at 19:14:46 +0930, Josh Heidenreich wrote:

> Package: cups-browsed
> Version: 1.28.7-1+deb11u1
> Severity: important
> X-Debbugs-Cc: josh.sickm...@gmail.com

Thank you for your report, Josh

> Dear Maintainer,
>
> When resuming from suspend (such as re-opening the lid of my laptop), printing
> over the network no longer works. I receive the following error:
> 
> No destination host name supplied by cups-browsed for printer "name",
> is cups-browsed running?

This is a message that crops up in other bug reports but not necessarily
involving suspend. See

 https://github.com/OpenPrinting/cups-filters/issues/97

> Restarting the service (i.e. sudo service cups-browsed restart) resolves the
> issue and printing then works. Attempting other fixes does not work; I've
> tried starting and stopping the printer within the CUPS web interface for
> example.
> 
> Note that my device needs to re-connect network after a resume. I of course
> wait for this to finish before attempting printing.
> 
> The printer devices do show up within applications. I don't have any printers
> "installed" as such, only using auto-detection. I regurally switch networks
> between home and office. Device is a Dell XPS 13 model 9370.

Which application? You could try purging (or stopping) cups-browse. The
printers should still show up, even after resuming from suspend.
 
> I've examined the debian changelog an did not see any notable package changes
> between 'stable' and 'unstable' versions of this package.
> 
> I have also examined the upstream changes for each of the versions, and have
> found one possible fix, released in v1.28.9:
> 
> https://github.com/OpenPrinting/cups-filters/pull/360
> "utils/cups-browsed.service: Add network-online.target"
> 
> This change alters the SystemD configuration to depend on the network being
> online.

AFAICT, #360 involves the legacy CUPS protocol, which I doubt very much
you are using.
 
> I've logged this bug report as I consider both printing and suspend/resume
> to be important features. Futhermore, new users would consider printing to
> be "broken" if they had closed the lid of their laptop even a single time
> prior to printing.

TBH, I think your best course of action is to take this upstream.

 https://github.com/OpenPrinting/cups-filters/issues

Regards,

Brian.

Bug#1017130: yakuake FTBFS

[Didier 'OdyX' Raboud]

Control: tags -1 +upstream +patch +fixed-upstream

Hello,

I can confirm this is fixed in 22.08 [0]. Specifically, the commits are as 
follows:
- 
https://invent.kde.org/utilities/yakuake/-/commit/56c0b6f38968902765ffe706e2694eb50b0834f7
 (not all of it)
- 
https://invent.kde.org/utilities/yakuake/-/commit/9e691cfa077bb2e26efc14dd021da0836d70782d

I'd be happy to join the yakuake maintenance team BTW.

Best,

OdyX

[0] https://invent.kde.org/utilities/yakuake/-/commits/release/22.08/

Bug#1017952: groupadd: invalid group ID '-1' when adding with --uid

[Marc Haber]

Hi,

thanks for spotting this. It was both a bug in the code and a big
omission in our test suite. Both aspects are fixed now.

On Mon, Aug 22, 2022 at 10:11:24PM +0200, Samuel Thibault wrote:
> Package: adduser
> Version: 3.124
> Severity: serious
> Justification: Makes creating chroots fail

Do have the time to check the code from
https://salsa.debian.org/debian/adduser/-/tree/debian-bug-1017952 ?

The only file touched to fix the bug is the adduser executable, so you
probably don't even need to build the package.

Greetings
Marc

(MR is https://salsa.debian.org/debian/adduser/-/merge_requests/62 and
still pending team review)

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1017980: zcfan should "Conflicts: thinkfan"

[Lee Garrett]

Package: zcfan
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi Michel,

thank you for packaging zcfan! I think it should have "Conflicts: thinkfan" set
in the package meta-data, as both installed on the same machine likely will
produce unpredictable behaviour.

By the way, it looks like you're using git-buildpackage. Can you push the
pristine-tar and upstream branches? That would make it easier for me to build
and verify the package, and provide a patch.

Greetings,
Lee

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

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 zcfan depends on:
ii  libc6  2.31-13+deb11u3

zcfan recommends no packages.

zcfan suggests no packages.

Bug#1016291: python-inotify: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Bastian Germann]

Control: severity -1 important

I cannot reproduce this. Which kernel version did you use?

Bug#1017961: mozjs102: Fails to build on armel

[Simon McVittie]

On Tue, 23 Aug 2022 at 10:07:47 +0100, Simon McVittie wrote:
> On Mon, 22 Aug 2022 at 20:25:17 -0400, Jeremy Bicha wrote:
> > I did notice this repeatedly in the build log:
> > 
> > {standard input}: Assembler messages:
> > {standard input}: Error: selected processor does not support `dmb sy'
> > in ARM mode
> > {standard input}: Error: selected processor does not support `ldrexb
> > r0,[r1]' in ARM mode
> > {standard input}: Error: selected processor does not support `strexb
> > r3,r2,[r1]' in ARM mode
> 
> I think the answer might be to switch to the fallback atomics
> implementation on armel. I'm testing a patch on amdahl, but it's going
> to take a while to get a result.

I tried the attached patch and the build gets a lot further, but then
the final link fails for the same reason that I described in #1017979
(which is not a regression in mozjs102, mozjs91 has the same failure).

As a result of the final link failing, I don't know whether tests will
pass with this patch.

The next thing I'm going to try is using gcc 11 on armel as a workaround
for #1017979.

smcv

Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

[Simon McVittie]

Source: mozjs91
Version: 91.10.0-1
Severity: serious
Tags: ftbfs help
X-Debbugs-Cc: debian-...@lists.debian.org
Control: block 1017961 by -1

Versions of mozjs91 newer than 91.10.0-1 failed to build on the armel
buildds. I tried building 91.10.0-1 in an armel chroot on amdahl, and
that also fails, which makes me think that the root cause for the build
failure is the upgrade from gcc 11 to 12 as default compiler.

The final link fails with multiple definitions of the various atomic
builtins:

> /usr/bin/arm-linux-gnueabi-g++ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 
> -fstack-protector-strong -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wempty-body 
> -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits 
> -Wunreachable-code -Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond 
> -Wimplicit-fallthrough -Wno-error=maybe-uninitialized 
> -Wno-error=deprecated-declarations -Wno-error=array-bounds 
> -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object 
> -Wno-multistatement-macros -Wno-error=class-memaccess 
> -Wno-error=deprecated-copy -Wno-error=unused-but-set-variable -Wformat 
> -Wformat-overflow=2 -Wno-psabi -fno-sized-deallocation -fno-aligned-new -g 
> -O2 -ffile-prefix-map=/home/smcv/mozjs91-armel=. -fstack-protector-strong 
> -Wformat -Werror=format-security -fPIC -fno-rtti -ffunction-sections 
> -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g 
> -freorder-blocks -O3 -fomit-frame-pointer -funwind-tables  -shared 
> -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libmozjs-91.so -o libmozjs-91.so 
> /home/smcv/mozjs91-armel/debian/build/js/src/build/libmozjs-91_so.list   
> -lpthread -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro 
> -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1 
> -fstack-protector-strong 
> -Wl,-rpath-link,/home/smcv/mozjs91-armel/debian/build/dist/bin 
> -Wl,-rpath-link,/usr/lib  
> /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a
>   -Wl,--version-script,symverscript -Wl,-soname,libmozjs-91.so.0  -lm  
> -latomic -lz -lm -ldl
> /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/12/libgcc.a(linux-atomic.o): in 
> function `__sync_fetch_and_add_4':
> (.text+0x0): multiple definition of `__sync_fetch_and_add_4'; 
> /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94:
>  first defined here
> /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/12/libgcc.a(linux-atomic.o): in 
> function `__sync_fetch_and_sub_4':
> (.text+0x38): multiple definition of `__sync_fetch_and_sub_4'; 
> /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94:
>  first defined here
(etc.)

An example build log:
https://buildd.debian.org/status/fetch.php?pkg=mozjs91=armel=91.13.0-1=1661218081=0

The same failure mode occurred when I tried to build mozjs102 with ARMv7
inline assembler disabled for #1017961.

(For completeness: 91.10.0-1 and 91.12.0-1 have an additional failure
reason involving undefined references to
std::type_info::operator==(std::type_info const&) const, but I believe
that was fixed in 91.12.0-2 by removing an obsolete patch. The latest
mozjs91 and mozjs102 do not have the obsolete patch and do not exhibit
the std::type_info errors.)

Assistance from fans of armel would be much appreciated. If we cannot get
mozjs102 to compile on armel, then gjs and the GNOME stack in general will
probably have to be removed from armel, similar to the way we temporarily
removed them from s390x between mid 2019 and mid 2020.

smcv

Bug#1017976: Confirmation

[Bastian Germann]

I can confirm this on i386.

Bug#1017972: Please add kernel module "nvidia-wmi-ec-backlight.ko"

[Diederik de Haas]

On dinsdag 23 augustus 2022 11:17:39 CEST Roman Kalugin wrote:
> The backlight mode does not work in laptops due to the lack of this module.

https://salsa.debian.org/kernel-team/linux/-/merge_requests/520 is the MR 
implementing the enabling of that module.

> I checked on other versions of kernels such as "5.18.0-17.1-liquorix-amd64"
> and everything works there.

Does that kernel have the patch (set) applied we discussed earlier on the 
debian-kernel ML? IOW: Is that patch (set) needed for things to work or not?

FTR: https://lore.kernel.org/all/20220818184302.10051-18-hdego...@redhat.com/ 
is v3 of that patch (set)

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

Bug#1012013: yaru-theme: Don't use Canonical Ltd. logo in application menu icon on non-Ubuntu distros

[Jeremy Bicha]

Mike, could you report this issue upstream?
https://github.com/ubuntu/yaru/issues

My initial thinking is that upstream could provide an alternative
generic logo and the packaging can use an appropriate instruction in
debian/rules (or something) to install the correct versions based on
the distro it's being built for.

Thank you,
Jeremy Bicha

Bug#1017978: linux-image-5.18.0-4-amd64: Failure creating named object [\ADBG], AE_ALREADY_EXISTS (20211217/dswload2-326)

[marc]

Package: src:linux
Version: 5.18.16-1
Severity: important

Dear Maintainer,

When my computer boot, I have an ACPI error.
Here an extract of dmesg :

[ 0.254183] ACPI BIOS Error (bug): Failure creating named object 
[\ADBG], AE_ALREADY_EXISTS (20211217/dswload2-326)
[ 0.254190] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20211217/psobject-220)


Motherboard : Gigabyte Z690 Gaming X DDR4
Processor : Intel I7-12700KF

root@Midgard:~# uname -a
Linux Midgard 5.18.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 
(2022-08-10) x86_64 GNU/Linux


Regards


-- Package-specific info:
** Version:
Linux version 5.18.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-11 
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.18.0-4-amd64 
root=UUID=adf75a18-c4e0-4908-9b83-7cde3e9db64d ro quiet nvidia-drm.modeset=1


** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded

** Kernel log:
[ 6.041607] snd_hda_intel :01:00.1: enabling device ( -> 0002)
[ 6.041644] snd_hda_intel :01:00.1: Disabling MSI
[ 6.041646] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[ 6.057395] mei_me :00:16.0: enabling device ( -> 0002)
[ 6.059270] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC1220: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[ 6.059273] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[ 6.059274] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)

[ 6.059274] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
[ 6.059275] snd_hda_codec_realtek hdaudioC0D0: dig-out=0x1e/0x0
[ 6.059275] snd_hda_codec_realtek hdaudioC0D0: inputs:
[ 6.059276] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19
[ 6.059276] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18
[ 6.076369] EXT4-fs (sda2): mounted filesystem with ordered data mode. 
Quota mode: none.
[ 6.078279] EXT4-fs (sdb1): mounted filesystem with ordered data mode. 
Quota mode: none.
[ 6.089485] input: HDA Intel PCH Front Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input12
[ 6.089496] input: HDA Intel PCH Rear Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[ 6.089507] input: HDA Intel PCH Line Out as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[ 6.089516] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[ 6.090782] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input5
[ 6.090803] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input6
[ 6.090818] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input7
[ 6.090848] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input8
[ 6.090866] input: HDA NVidia HDMI/DP,pcm=10 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input9
[ 6.090884] input: HDA NVidia HDMI/DP,pcm=11 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10
[ 6.090899] input: HDA NVidia HDMI/DP,pcm=12 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11

[ 6.121611] ee1004 0-0051: 512 byte EE1004-compliant SPD EEPROM, read-only
[ 6.121621] ee1004 0-0053: 512 byte EE1004-compliant SPD EEPROM, read-only
[ 6.124192] iTCO_vendor_support: vendor-support=0
[ 6.125467] iTCO_wdt iTCO_wdt: Found a Intel PCH TCO device (Version=6, 
TCOBASE=0x0400)

[ 6.125516] iTCO_wdt iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 6.128029] usb 1-11.4: New USB device found, idVendor=046d, 
idProduct=0819, bcdDevice= 0.10
[ 6.128032] usb 1-11.4: New USB device strings: Mfr=0, Product=0, 
SerialNumber=2

[ 6.128034] usb 1-11.4: SerialNumber: 08CD0310
[ 6.143345] audit: type=1400 audit(1661252761.000:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=669 comm="apparmor_parser"
[ 6.143467] audit: type=1400 audit(1661252761.000:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" 
pid=674 comm="apparmor_parser"
[ 6.143470] audit: type=1400 audit(1661252761.000:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libreoffice-xpdfimport" pid=671 comm="apparmor_parser"
[ 6.143928] audit: type=1400 audit(1661252761.000:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" 
pid=663 comm="apparmor_parser"
[ 6.143930] audit: type=1400 audit(1661252761.000:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="nvidia_modprobe//kmod" pid=663 comm="apparmor_parser"
[ 6.144012] audit: type=1400 audit(1661252761.000:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libreoffice-oosplash" pid=668 

Bug#1017976: emacsen-common: Segmentation fault when upgrading emacs to 28.1+1-2

[ಚಿರಾಗ್ ನಟರಾಜ್]

Package: emacsen-common
Version: 3.0.4
Severity: important
X-Debbugs-Cc: debb...@chiraag.me

Dear Maintainer,

When upgrading emacs to 28.1+1-2 from 27.1 (previous version) in 
sid/experimental, emacsen-common throws a segmentation fault when configuring:

Fatal error 11: Segmentation fault
Backtrace:
emacs(+0x153373)[0x56339f61e373]
emacs(+0x48827)[0x56339f513827]
emacs(+0x48cf0)[0x56339f513cf0]
emacs(+0x1516d8)[0x56339f61c6d8]
emacs(+0x151759)[0x56339f61c759]
/lib/x86_64-linux-gnu/libc.so.6(+0x3daa0)[0x7f57dd23daa0]
emacs(+0x193eb4)[0x56339f65eeb4]
emacs(+0x199752)[0x56339f664752]
emacs(+0x1b7e5d)[0x56339f682e5d]
emacs(+0x1b7f6f)[0x56339f682f6f]
emacs(+0x1de858)[0x56339f6a9858]
emacs(+0x1df220)[0x56339f6aa220]
emacs(+0x1e29bb)[0x56339f6ad9bb]
emacs(+0x1e35ba)[0x56339f6ae5ba]
emacs(+0x1b7af6)[0x56339f682af6]
emacs(+0x1b7d25)[0x56339f682d25]
emacs(+0x1b7f6f)[0x56339f682f6f]
emacs(+0x1de858)[0x56339f6a9858]
emacs(+0x1df220)[0x56339f6aa220]
emacs(+0x1e29bb)[0x56339f6ad9bb]
emacs(+0x1e35ba)[0x56339f6ae5ba]
emacs(+0x1b7af6)[0x56339f682af6]
emacs(+0x1b7d25)[0x56339f682d25]
emacs(+0x1b7f6f)[0x56339f682f6f]
emacs(+0x1de858)[0x56339f6a9858]
emacs(+0x1df220)[0x56339f6aa220]
emacs(+0x1e29bb)[0x56339f6ad9bb]
emacs(+0x1e35ba)[0x56339f6ae5ba]
emacs(+0x1b7af6)[0x56339f682af6]
emacs(+0x1b7d25)[0x56339f682d25]
emacs(+0x1b7f6f)[0x56339f682f6f]
emacs(+0x1de858)[0x56339f6a9858]
emacs(+0x1df220)[0x56339f6aa220]
emacs(+0x1e29bb)[0x56339f6ad9bb]
emacs(+0x1e35ba)[0x56339f6ae5ba]
emacs(+0x1b7af6)[0x56339f682af6]
emacs(+0x1b7d25)[0x56339f682d25]
emacs(+0x1b7f6f)[0x56339f682f6f]
emacs(+0x1de858)[0x56339f6a9858]
emacs(+0x1df220)[0x56339f6aa220]
emacs(+0x1e29bb)[0x56339f6ad9bb]
...
Segmentation fault

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

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

-- no debconf information

Bug#1017969: texlive-latex-recommended: As configured by texlive-latex-recommended, fontspec using XeLaTeX cannot find system fonts by name.

[Norbert Preining]

> % \setmainfont{TexGyreTermes}
> % \setmathfont{Tex Gyre Termes Math}

If you use the correct
\setmainfont{TeX Gyre Termes}
\setmathfont{TeX Gyre Termes Math}
(note the uppercase X in TeX, the spaces, etc) then it works.

You can check - as documented in the fontspec manual - with
otfinfo -i 
and pick the "Preferred Family", in the Math case
Preferred family:TeX Gyre Termes Math

OSFONTDIR is set to /usr/share/fonts and searched recursively, so the
fonts should be found.

Furthermore, the TeX Gyre fonts should be linked into
/usr/share/texmf/fonts, and also be found via that line.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1015189: [debian-mysql] Bug#1015189: mariadb-server: stopping mariadb.service never finishes

[Faustin Lammler]

Hi Paul!
I am not able to reproduce this with 10.6.9, at least in containers
with:

| podman run --name 1015189 --rm -d fauust/docker-systemd:debian-sid
| podman exec -it 1015189 bash -c "apt-get update \
|   && apt-get -y install mariadb-server \
|   && systemctl start mariadb \
|   && systemctl stop mariadb \
|   && systemctl status mariadb"
| ...
| ○ mariadb.service - MariaDB 10.6.9 database server
|  Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: 
enabled)
|  Active: inactive (dead) since Tue 2022-08-23 11:02:36 UTC; 55ms ago
|Duration: 11ms
|Docs: man:mariadbd(8)
|  https://mariadb.com/kb/en/library/systemd/
| Process: 1124 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d 
/var/run/mysqld (code=exited, status=0/SUCCESS)
| Process: 1125 ExecStartPre=/bin/sh -c systemctl unset-environment 
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
| Process: 1127 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] 
&& VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && 
systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, 
status=0/SUCCESS)
| Process: 1156 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS 
$_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
| Process: 1169 ExecStartPost=/bin/sh -c systemctl unset-environment 
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
| Process: 1171 ExecStartPost=/etc/mysql/debian-start (code=exited, 
status=0/SUCCESS)
|Main PID: 1156 (code=exited, status=0/SUCCESS)
|  Status: "MariaDB server is down"
| CPU: 204ms
| 
| Aug 23 11:02:35 32a0256b22b9 mariadbd[1156]: 2022-08-23 11:02:35 0 [Note] 
/usr/sbin/mariadbd (initiated by: unknown): Normal shutdown
| Aug 23 11:02:35 32a0256b22b9 mariadbd[1156]: 2022-08-23 11:02:35 0 [Note] 
InnoDB: FTS optimize thread exiting.
| Aug 23 11:02:35 32a0256b22b9 mariadbd[1156]: 2022-08-23 11:02:35 0 [Note] 
InnoDB: Starting shutdown...
| Aug 23 11:02:35 32a0256b22b9 mariadbd[1156]: 2022-08-23 11:02:35 0 [Note] 
InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool
| Aug 23 11:02:35 32a0256b22b9 mariadbd[1156]: 2022-08-23 11:02:35 0 [Note] 
InnoDB: Buffer pool(s) dump completed at 220823 11:02:35
| Aug 23 11:02:35 32a0256b22b9 mariadbd[1156]: 2022-08-23 11:02:35 0 [Note] 
InnoDB: Removed temporary tablespace data file: "./ibtmp1"
| Aug 23 11:02:35 32a0256b22b9 mariadbd[1156]: 2022-08-23 11:02:35 0 [Note] 
InnoDB: Shutdown completed; log sequence number 42159; transaction id 15
| Aug 23 11:02:35 32a0256b22b9 mariadbd[1156]: 2022-08-23 11:02:35 0 [Note] 
/usr/sbin/mariadbd: Shutdown complete
| Aug 23 11:02:36 32a0256b22b9 systemd[1]: mariadb.service: Deactivated 
successfully.
| Aug 23 11:02:36 32a0256b22b9 systemd[1]: Stopped MariaDB 10.6.9 database 
server.

Could you verify if you have still the pb with 10.6.9?
Could you also verify if you have the pb with 10.6.9 from MariaDB repo
(https://mariadb.org/downloads)?

Depending on the previous, could you maybe share with me the content of
the DB and the configuration so I could try to reproduce it locally (and
in a VM since podman is probably not the best way to debug systemd
services).

Also, if this is not related to Debian packaging, I suggest you report
this directly upstream at https://jira.mariadb.org, I could not find any
relevant issue there so far.

Cheers!

-- 
Faustin


signature.asc
Description: PGP signature

Bug#1017811: node-wikibase-cli: FTBFS without Internet access

[Andrius Merkys]

control: tags -1 + moreinfo

Hi Steve,

On Sat, 20 Aug 2022 15:05:03 -0700 Steve Langasek
 wrote:
> In Ubuntu, node-wikibase-cli fails to build from source because dh_auto_test
> runs a test suite at build time which requires Internet access, and the
> Ubuntu build environment does not allow access to the Internet.
> 
> Debian packages should not fail to build when they are built offline.

Thanks for reporting this bug. I wonder why Debian buildds do not fail,
but AFAIR there are no guarantees they are off network during package
builds.

> The attached patch fixes the package to run the testsuite but ignore any
> failures.  I've uploaded this patch to Ubuntu to fix the failure there.

While this overcomes the FTBFS, this is not the way I would want the
package to be. It would be much better to find a way to skip tests
requiring network access and keep the remaining ones to catch possible
regressions.

Thanks,
Andrius

Bug#1017975: ModemManager does not install qmicli needed for unlocking scripts.

[Ilja Sidoroff]

Package: modemmanager
Version: 1.18.10-1
Severity: normal

In reference to bug #1004447.

The FCC unlocking scripts (in /usr/share/ModemManager/fcc-unlock.available.d) 
105b and 1199 use `qmicli-binary` to perform the unlocking operation. The 
binary, which is in libqmi-utils -package is not installed by default or as a 
dependency to modemmanager-package. If the binary is missing, the symptoms of 
the bug are as described in #1004447. This can probably simply be fixed by 
adding libqmi-utils as a dependency to modemmanager?

I also noticed that the script `1eac` uses mbimcli-binary, which also doesn't 
seem to installed by default, but I haven't examined that further.

br.

Ilja Sidoroff

Bug#1017742: po4a: Please provide marker for double strings during po4a-gettextize

[Martin Quinson]

Package: po4a
tag 1017742 fixed-upstream
thanks

Hello,

I just fixed the gettextization process, and I think it's now much better. The
version I introduced in last version was indeed really suboptimal.

Now, if I gettextize these two files (presented side by side):

```
# hello   | # HELLO
  |
## hello  | ## SUBTITLE
  |
hello | SAMPLE PARAGRAPH.
```

I get a pot file with a single msgid:

```
#, fuzzy, markdown-text, no-wrap
msgid "hello"
msgstr ""
"#-#-#-#-#  file1:1 (type Title #)  #-#-#-#-#\n"
"HELLO\n"
"#-#-#-#-#  file1:3 (type: Title ##)  #-#-#-#-#\n"
"SUBTITLE\n"
"#-#-#-#-#  file1:5 (type: Plain text)  #-#-#-#-#\n"
"SAMPLE PARAGRAPH."
```

I think it's much much better than the previous thing. Thanks again for
reporting the issue, I'm glad of that new version :)

Bye, Mt.

Le samedi 20 août 2022 à 10:43 +0200, Martin Quinson a écrit :
> 
> 
> - Le 19 Aoû 22, à 21:13, Helge Kreutzmann deb...@helgefjell.de a écrit :
> 
> > Package: po4a
> > Version: 0.67-2
> > Severity: wishlist
> > 
> > Since recently po4a-gettextize adds spaces at the end of strings
> > during gettextisation, if strings occure multiple times in the master
> > file (or translation).
> > 
> > In production, multiple indentical strings in the original file are
> > only stored once in the po file (as they are translated the same).
> > 
> > Therefore, translators need to review those strings carefully and
> > remove those entries from the po file, which have this final space
> > added. In this process they need to choose the most appropriate
> > translation to keep.
> > 
> > Currently, this can be quite difficult, as the string can occur
> > multiple times and the trailing space(s) are difficult to spot in
> > large files. Also these trailing spaces are hard to get a good regular
> > expression for searching.
> > 
> > Therefor I kindly ask you if you could mark those strings in addition
> > (!) with a suitable translator comment (e.g. "Potential duplicate
> > string, review and consolidate"). This would users allow to use msggrep(1)
> > with the option -C to filter them out for review.
> > 
> > Thanks for considering.
> 
> Your bug report makes me realize that the current behavior is perfectly
> broken. I was hopping for the next msgmerge to merge the alternative
> translations of the same msgid, but I realize that they will most probably be
> dropped in the process. 
> 
> Mmm. Let me think about it, I'll try to reimplement this thing so that the
> carful review that you describe becomes automatically done during the
> gettexization.
> 
> Many thanks for reporting,
> Mt

-- 
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.



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

Bug#1017974: autopkgtest: regression on Gitlab-CI with unshare: test stdout not always seen in autopkgtest's stdout

[Simon McVittie]

Package: autopkgtest
Version: 5.24
Severity: important
X-Debbugs-Cc: da...@kalnischkies.de, jspri...@debian.org, jo...@mister-muffin.de

(Cc'd: recent contributors to the unshare backend who might have an
insight into what is going on, or at least might be using this backend
more regularly than the autopkgtest maintainers)

On 2022-08-13 17:53Z, autopkgtest commit 960ae522 was passing tests on
Gitlab-CI, and so were my branches as recently as 2022-08-15 22:44Z.

On 2022-08-21 10:18Z, one of my branches failed CI for a reason that was
apparently unrelated to the change in the branch. I retried the pipeline
for known-good version 960ae522 at 2022-08-21 15:54Z and that also failed.

The failure is that in test-unshare (which tests the unshare backend),
several test-cases run autopkgtest against a mock package in which a
test script "debian/tests/$test_name" emits known strings on its stdout,
and assert that autopkgtest's stdout contains those strings.

For example, test_tree_allow_stderr_nobuild_success runs this test script:

#!/bin/sh
echo I am fine >&2
echo babble

and expects to see "I am fine" in autopkgtest's stderr, and "babble"
in autopkgtest's stdout. In fact "babble" does not always appear, causing
a test failure. This appears to be intermittent: sometimes this test-case
succeeds. stderr seems to be reliable, as far as I can see?

Similarly, test_tree_allow_stderr_nobuild_fail_on_exit and
test_tree_norestrictions_nobuild_fail_on_exit assert that test stdout
appears on autopkgtest's stdout, and these assertions are sometimes failing.

Any ideas?

Thanks,
smcv

Bug#1017356: libpmix2: symbol lookup error: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_ext3x.so: undefined symbol: pmix_value_load

[Drew Parsons]

On 2022-08-23 10:17, Alastair McKinstry wrote:

Hi Drew

Yes, this sounds sensible.

pmix 4.2.0 is just released, i'm uploading to experimental.


Thanks Alistair.  At this point we can send 4.2.0 straight to unstable 
since pmix already got broken here, needs to be fixed.


Would be good to send future major versions to experimental first 
though, i.e. 4.3.0rc1 when its time comes. Upstream seems to reliably 
break things every major release.


Drew