Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t

[Sylvestre Ledru]

Le 08/03/2023 à 02:30, Faidon Liambotis a écrit :

On Fri, Mar 03, 2023 at 05:31:41PM +, Simon McVittie wrote:

# clang++-15 -c --target=wasi-wasm32 -ostddef-cpp.o stddef.cpp
# apt-get install --no-install-recommends libc++-15-dev
# clang++-15 -c --target=wasi-wasm32 -ostddef-cpp.o stddef.cpp

Expected result: both clang++-15 calls succeed (stddef.h declares size_t)

Actual result: the second clang++-15 call fails:

(Super helpful bug report, thanks!)

As I mentioned in #1029010 just now, this is a regression from 14->15.
Retracing the same steps with clang-14 & libc++-14-dev-wasm32, there are
no errors and everything works as intended.

Looking at the differences of the include paths between the two by
passing -v to clang, one can see:
   /usr/include/wasm32-wasi/c++/v1
- /usr/lib/llvm-14/lib/clang/14.0.6/include
+ /usr/include/c++/v1
+ /usr/lib/llvm-15/lib/clang/15.0.7/include
   /usr/local/include
   /usr/include/wasm32-wasi
   /usr/include
i.e. /usr/include/c++/v1 (i.e. libc++-15-dev) is included in the include
path only with clang-15. It shouldn't be.

Looking at the interdiff of d/patches/wasm/wasm-sysroot-usr.diff[1]
patch between llvm-toolchain 1:14.0.6-12 and 1:15.0.7-1, it looks line
there are a few hunks that are missing.

Specifically, it looks like the entire patching of the method
WebAssembly::AddClangCXXStdlibIncludeArgs isn't happening anymore. One
of these differences was exactly about this -- the comment says:
   // don't include the host architecture's headers in the search path

Sylvestre, I think you did the 14->15 porting, right? Do you
know/remember what happened there?


Maybe i did a mistake in the merge?!
Sorry if I did
S

Bug#1031794: socklog: fails to extract source package: dpkg-source: error: pathname 'socklog-2.1.0+repack/debian/service/socklog-unix/log/supervise' points outside source root (to '/run/runit/supervis

[Mathieu Mirmont]

Hi,

Sorry for the noise on this ticket, it looks like every git push
triggered an email here. I have fixed this silly bug and prepared a
new package to upload, it is on mentors [1]. I would really appreciate
if someone could upload it before socklog is removed from testing.

[1] https://mentors.debian.net/package/socklog/

Cheers,

Mathieu.


On Wed, Feb 22, 2023 at 09:45:29PM +0100, Lucas Nussbaum wrote:
> Source: socklog
> Version: 2.1.0+repack-4
> Severity: serious
> 
> Hi,
> 
> # dget 
> https://deb.debian.org/debian/pool/main/s/socklog/socklog_2.1.0+repack-4.dsc
> dget: retrieving 
> https://deb.debian.org/debian/pool/main/s/socklog/socklog_2.1.0+repack-4.dsc
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 100  1980  100  19800 0   8615  0 --:--:-- --:--:-- --:--:--  8646
> dget: retrieving 
> https://deb.debian.org/debian/pool/main/s/socklog/socklog_2.1.0+repack.orig.tar.gz
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 100 59796  100 597960 0   162k  0 --:--:-- --:--:-- --:--:--  163k
> dget: retrieving 
> https://deb.debian.org/debian/pool/main/s/socklog/socklog_2.1.0+repack-4.debian.tar.xz
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 100 11080  100 110800 0  46909  0 --:--:-- --:--:-- --:--:-- 46751
> socklog_2.1.0+repack-4.dsc:
>   Good signature found
>validating socklog_2.1.0+repack.orig.tar.gz
>validating socklog_2.1.0+repack-4.debian.tar.xz
> All files validated successfully.
> dpkg-source: info: extracting socklog in socklog-2.1.0+repack
> dpkg-source: info: unpacking socklog_2.1.0+repack.orig.tar.gz
> dpkg-source: info: unpacking socklog_2.1.0+repack-4.debian.tar.xz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying 0001-socklog-conf-update-service.patch
> dpkg-source: info: applying 0002-tryto-c.patch
> dpkg-source: info: applying 0003-patches-fix-build-warnings.patch
> dpkg-source: error: pathname 
> 'socklog-2.1.0+repack/debian/service/socklog-unix/log/supervise' points 
> outside source root (to '/run/runit/supervise/socklog-unix.log')
> 
> That's on a system with a mix of testing and unstable. I'm not sure of
> which package introduced that additional check. Let me know if you
> cannot reproduce.
> 
> Lucas
> 

-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

Bug#1032497: gnome-shell: JS ERROR: Error: Invalid overview shown transition from HIDDEN to SHOWN

[di dit]

Package: gnome-shell
Version: 43.3-2
Severity: important

Dear Maintainer,

After login from gdm3, gnome-shell/wayland will sometimes start and
after leaving the overview mode I can't start any application. The mouse
cursor can be moved but mouse clicks and keyboard keys are ignored. This
has happened to me about every 2-3 logins on 2 different unstable/amd64
machines during the last week. Each time this happens, the following
entry is present in journalctl :
  gnome-shell[73239]: JS ERROR: Error: Invalid overview shown transition
from HIDDEN to SHOWN
   _changeShownState
@resource:///org/gnome/shell/ui/overview.js:295:19

 runStartupAnimation/<@resource:///org/gnome/shell/ui/overview.js:693:18
   onComplete
@resource:///org/gnome/shell/ui/overviewControls.js:856:31

 _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:152:13

 _easeActor/<@resource:///org/gnome/shell/ui/environment.js:239:64
This also happens if I disable extensions.
This bug has already been reported here:

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514#note_1683525
and it is reported to be fixed there:
  https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2667

Best regards and thank you for your very good work!

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.36-4
ii  gir1.2-gtk-4.0   4.8.3+ds-2
ii  gir1.2-gweather-4.0  4.2.0-2
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.3-5
ii  gir1.2-nm-1.01.42.2-2
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-2
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.38.5-1
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.3-2
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-1
ii  libedataserver-1.2-273.46.4-1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.6-1
ii  libglib2.0-bin   2.74.6-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043.2-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.36-4
ii  libgtk-4-1   4.8.3+ds-2
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.3-5
ii  libnm0   1.42.2-2
ii  libpango-1.0-0   

Bug#1032498: stymulator FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: stymulator
Version: 0.21a~dfsg-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

stymulator fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes stymulator cross buildable. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru stymulator-0.21a~dfsg/debian/changelog 
stymulator-0.21a~dfsg/debian/changelog
--- stymulator-0.21a~dfsg/debian/changelog  2022-11-04 00:37:59.0 
+0100
+++ stymulator-0.21a~dfsg/debian/changelog  2023-03-07 20:17:06.0 
+0100
@@ -1,3 +1,9 @@
+stymulator (0.21a~dfsg-4) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 07 Mar 2023 20:17:06 +0100
+
 stymulator (0.21a~dfsg-3) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru stymulator-0.21a~dfsg/debian/rules 
stymulator-0.21a~dfsg/debian/rules
--- stymulator-0.21a~dfsg/debian/rules  2022-11-04 00:37:59.0 +0100
+++ stymulator-0.21a~dfsg/debian/rules  2023-03-07 20:17:04.0 +0100
@@ -14,7 +14,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
-   $(MAKE) CXXFLAGS="$(CXXFLAGS)" CXX="g++" -C src/
+   dh_auto_build -D src -- CXXFLAGS="$(CXXFLAGS)"
touch $@
 
 clean:

Bug#1032499: ukui-interface FTCBFS: hard codes the build architecture qmake

[Helmut Grohne]

Source: ukui-interface
Version: 1.0.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ukui-interface fails to cross build from source, because debian/rules
hard codes the build architecture qmake. There are two easy ways to get
the host architecture one. Using dh_auto_configure (and yeah you can
call this multiple times with different build systems) would be the
simplest. Using dpkg's buildtools.mk is the least invasive. I'm
attaching a patch of the latter approach for your convenience.

Helmut
diff --minimal -Nru ukui-interface-1.0.1/debian/changelog 
ukui-interface-1.0.1/debian/changelog
--- ukui-interface-1.0.1/debian/changelog   2021-11-02 07:53:40.0 
+0100
+++ ukui-interface-1.0.1/debian/changelog   2023-03-08 07:13:31.0 
+0100
@@ -1,3 +1,10 @@
+ukui-interface (1.0.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the host architecture qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 08 Mar 2023 07:13:31 +0100
+
 ukui-interface (1.0.1-2) unstable; urgency=medium
 
   * Source only upload for migration to testing.
diff --minimal -Nru ukui-interface-1.0.1/debian/rules 
ukui-interface-1.0.1/debian/rules
--- ukui-interface-1.0.1/debian/rules   2021-07-29 09:09:37.0 +0200
+++ ukui-interface-1.0.1/debian/rules   2023-03-08 07:13:29.0 +0100
@@ -3,6 +3,7 @@
 #export DH_VERBOSE = 1
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk
+include /usr/share/dpkg/buildtools.mk
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 #export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
@@ -30,7 +31,7 @@
 override_dh_auto_build:
dh_auto_build
mkdir -p $(LOG4QT_BUILD_DIR)
-   cd $(LOG4QT_BUILD_DIR) && qmake -makefile "QMAKE_CFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=$(LOG4QT_BUILD_DIR)=. \
+   cd $(LOG4QT_BUILD_DIR) && $(QMAKE) -makefile "QMAKE_CFLAGS_RELEASE=-g 
-O2 -fdebug-prefix-map=$(LOG4QT_BUILD_DIR)=. \
-fstack-protector-strong -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2" \
"QMAKE_CFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=$(LOG4QT_BUILD_DIR)=. -fstack-protector-strong \
-Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" \

Bug#1032501: gnu-efi FTCBFS: unsatisfiable binutils dependency

[Helmut Grohne]

Source: gnu-efi
Version: 3.0.15-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

gnu-efi cannot be cross built from source due to its binutils
dependency. For native builds, it is implied by build-essential. For
cross builds it is unsatisfiable. Please drop it. Doing so fixes cross
builds for arm*, but not for x86. I'm attaching a patch for your
convenience. If you ever need a veryioned dependency on binutils, please
use binutils-for-host or binutils-for-build depending on how you use it.

Helmut
diff --minimal -Nru gnu-efi-3.0.15/debian/changelog 
gnu-efi-3.0.15/debian/changelog
--- gnu-efi-3.0.15/debian/changelog 2023-01-27 21:24:25.0 +0100
+++ gnu-efi-3.0.15/debian/changelog 2023-03-08 09:12:15.0 +0100
@@ -1,3 +1,10 @@
+gnu-efi (3.0.15-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS for arm*: Drop unnecessary binutils dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 08 Mar 2023 09:12:15 +0100
+
 gnu-efi (3.0.15-1) unstable; urgency=medium
 
   * New upstream version 3.0.15
diff --minimal -Nru gnu-efi-3.0.15/debian/control gnu-efi-3.0.15/debian/control
--- gnu-efi-3.0.15/debian/control   2023-01-27 21:24:25.0 +0100
+++ gnu-efi-3.0.15/debian/control   2023-03-08 09:12:13.0 +0100
@@ -5,7 +5,6 @@
 Uploaders: Julian Andres Klode 
 Build-Depends:
  debhelper-compat (= 12),
- binutils,
  gcc-multilib [any-amd64 i386],
 Standards-Version: 4.1.1
 Vcs-Git: https://salsa.debian.org/efi-team/gnu-efi.git

Bug#1032500: synfig FTCBFS: unsatisfiable binutils dependency

[Helmut Grohne]

Source: synfig
Version: 1.5.1+dfsg-3
Severity: minor
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

synfig cannot be cross built from source, because its build dependency
on binutils cannot be satisfied. During native builds, it is implied in
build-essential, so it should be dropped with no replacement. I'm
attaching a patch for your convenience. Note that this doesn't make
synfig cross buildable as it pulls gfortran via openmpi and we haven't
made that work yet.

Helmut
diff --minimal -Nru synfig-1.5.1+dfsg/debian/changelog 
synfig-1.5.1+dfsg/debian/changelog
--- synfig-1.5.1+dfsg/debian/changelog  2022-07-05 07:06:27.0 +0200
+++ synfig-1.5.1+dfsg/debian/changelog  2023-03-08 09:34:02.0 +0100
@@ -1,3 +1,10 @@
+synfig (1.5.1+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unnecessary binutils dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 08 Mar 2023 09:34:02 +0100
+
 synfig (1.5.1+dfsg-3) unstable; urgency=medium
 
   * New upstream patch to fix FTBFS with ffmpeg-5.0 (Closes: #1013460).
diff --minimal -Nru synfig-1.5.1+dfsg/debian/control 
synfig-1.5.1+dfsg/debian/control
--- synfig-1.5.1+dfsg/debian/control2022-04-10 05:50:20.0 +0200
+++ synfig-1.5.1+dfsg/debian/control2023-03-08 09:34:01.0 +0100
@@ -5,7 +5,6 @@
 Maintainer: Debian Multimedia Maintainers 
 Uploaders: Dmitry Smirnov 
 Build-Depends: debhelper-compat (= 12), autopoint, intltool
-,binutils
 ,etl-dev (>= 1.5.1~)
 ,libavcodec-dev
 ,libavformat-dev

Bug#1032502: sslh FTCBFS: unsatisfiable cross Build-Depends

[Helmut Grohne]

Source: sslh
Version: 1.20-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

sslh has unsatisfiable cross Build-Depends. The binutils dependency is
natively implied in build-essential. It can be dropped with no
replacement. The other two issues are libio-socket-inet6-perl and lcov,
both of which are only used for testing and thus can be annotated
, which renders them irrelevant to cross building. I'm
attaching a patch for your convenience.

Helmut
diff --minimal -Nru sslh-1.20/debian/changelog sslh-1.20/debian/changelog
--- sslh-1.20/debian/changelog  2019-09-05 19:04:54.0 +0200
+++ sslh-1.20/debian/changelog  2023-03-08 09:29:12.0 +0100
@@ -1,3 +1,13 @@
+sslh (1.20-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Drop unnecessary binutils dependency.
++ Annotate test dependencies libio-socket-inet6-perl and lcov with
+  .
+
+ -- Helmut Grohne   Wed, 08 Mar 2023 09:29:12 +0100
+
 sslh (1.20-1) unstable; urgency=medium
 
   [ Guillaume Delacour ]
diff --minimal -Nru sslh-1.20/debian/control sslh-1.20/debian/control
--- sslh-1.20/debian/control2019-09-05 19:04:54.0 +0200
+++ sslh-1.20/debian/control2023-03-08 09:29:10.0 +0100
@@ -2,9 +2,9 @@
 Section: net
 Priority: optional
 Maintainer: Don Armstrong 
-Build-Depends: debhelper-compat (= 12), libwrap0-dev, binutils, po-debconf,
-   libio-socket-inet6-perl, libconfig-dev, libcap-dev [linux-any],
-   psmisc, lcov, libpcre3-dev,
+Build-Depends: debhelper-compat (= 12), libwrap0-dev, po-debconf,
+   libio-socket-inet6-perl , libconfig-dev, libcap-dev 
[linux-any],
+   psmisc, lcov , libpcre3-dev,
init-system-helpers (>= 1.51)
 Standards-Version: 4.4.0
 Homepage: http://www.rutschle.net/tech/sslh/README.html

Bug#1032503: camlidl FTCBFS: unsatisfiable binutils and cpp dependencies

[Helmut Grohne]

Source: camlidl
Version: 1.11-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

camlidl cannot be cross built from source for a number of dependency
issues. Two of them are binutils and cpp, both of which are natively
implied by build-essential and cross-unsatisfiable. Please drop them.
I'll leave the issues around dh-ocaml for later and attach a patch for
your convenience.

Helmut
diff --minimal -Nru camlidl-1.11/debian/changelog camlidl-1.11/debian/changelog
--- camlidl-1.11/debian/changelog   2023-01-20 12:35:37.0 +0100
+++ camlidl-1.11/debian/changelog   2023-03-08 09:08:28.0 +0100
@@ -1,3 +1,11 @@
+camlidl (1.11-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unnecessary and cross-unsatisfiable dependencies on binutils and cpp.
+(Closes: #-1)
+
+ -- Helmut Grohne   Wed, 08 Mar 2023 09:08:28 +0100
+
 camlidl (1.11-1) unstable; urgency=medium
 
   [ Stéphane Glondu ]
diff --minimal -Nru camlidl-1.11/debian/control camlidl-1.11/debian/control
--- camlidl-1.11/debian/control 2023-01-20 12:35:37.0 +0100
+++ camlidl-1.11/debian/control 2023-03-08 09:08:25.0 +0100
@@ -7,8 +7,6 @@
 Build-Depends:
  ocaml-nox,
  debhelper-compat (= 13),
- cpp,
- binutils,
  dh-ocaml
 Standards-Version: 4.6.1
 Rules-Requires-Root: no

Bug#1032504: libguestfs: minor cross build improvements

[Helmut Grohne]

Source: libguestfs
Version: 1:1.48.6-2
Severity: minor
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

libguestfs Build-Depends on binutils. This dependency is implied by
build-essential for native builds and unsatisfiable during cross builds.
Please drop it. I've also noticed that libguestfs builds a perl
extension. In this case, it should depend on perl-xs-dev. While it has
tons of more cross satisfiability issues, these are fairly obvious
incremental fixes. I'm attaching a patch for your convenience. Please
close this bug when applying the patch.

Helmut
diff --minimal -Nru libguestfs-1.48.6/debian/changelog 
libguestfs-1.48.6/debian/changelog
--- libguestfs-1.48.6/debian/changelog  2023-03-06 15:29:41.0 +0100
+++ libguestfs-1.48.6/debian/changelog  2023-03-08 09:22:43.0 +0100
@@ -1,3 +1,12 @@
+libguestfs (1:1.48.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve Build-Depends for cross builds: (Closes: #-1)
++ Drop binutils dependency implied in build-essential.
++ Add perl-xs-dev for building a perl extension.
+
+ -- Helmut Grohne   Wed, 08 Mar 2023 09:22:43 +0100
+
 libguestfs (1:1.48.6-2) unstable; urgency=medium
 
   * Add Brazilian Portuguese debconf translation, thanks to
diff --minimal -Nru libguestfs-1.48.6/debian/control 
libguestfs-1.48.6/debian/control
--- libguestfs-1.48.6/debian/control2023-03-06 15:29:01.0 +0100
+++ libguestfs-1.48.6/debian/control2023-03-08 09:22:34.0 +0100
@@ -36,6 +36,7 @@
   dh-python,
   default-jdk,
   gem2deb, rake, libjs-jquery,
+  perl-xs-dev,
   libmodule-build-perl,
   libtest-pod-coverage-perl, libextutils-command-perl, libintl-perl, 
libtest-pod-perl,
   libstring-shellquote-perl,
@@ -60,7 +61,6 @@
 #-# appliance start
   acl,
   attr,
-  binutils,
   bsdextrautils | bsdmainutils,
   btrfs-progs,
   bzip2,

Bug#1032505: braillefont FTCBFS: unsatisfiable binutils dependency

[Helmut Grohne]

Source: braillefont
Version: 1.0-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

braillefont cannot be cross built from source, because its dependency on
binutils is not satisfiable. Build-Depends should be switched to
binutils-for-build or binutils-for-host depending on the way binutils is
being used. In this case, the unversioned dependency already is implied
by build-essential and can be dropped without replacement. Another issue
is the libgd-perl dependency, which is a perl extension module. As such,
a user needs to select the required architecture and sind the module is
to be run during build, it needs to be annotated :native. I'm attaching
a patch for your convenience.

Helmut
diff --minimal -Nru braillefont-1.0/debian/changelog 
braillefont-1.0/debian/changelog
--- braillefont-1.0/debian/changelog2022-10-15 12:09:42.0 +0200
+++ braillefont-1.0/debian/changelog2023-03-08 09:01:02.0 +0100
@@ -1,3 +1,12 @@
+braillefont (1.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix cross building: (Closes: #-1)
++ Drop unnecessary and unsatisfiable binutils dependency.
++ Annotate libgd-perl dependency with :native.
+
+ -- Helmut Grohne   Wed, 08 Mar 2023 09:01:02 +0100
+
 braillefont (1.0-5) unstable; urgency=low
 
   * rules: Turning off trimming of changelogs.
diff --minimal -Nru braillefont-1.0/debian/control 
braillefont-1.0/debian/control
--- braillefont-1.0/debian/control  2022-10-15 12:04:11.0 +0200
+++ braillefont-1.0/debian/control  2023-03-08 09:01:02.0 +0100
@@ -2,7 +2,7 @@
 Maintainer: Judit Foglszinger 
 Section: text
 Priority: optional
-Build-Depends: libgd-perl, binutils, debhelper (>= 13~), debhelper-compat (= 
13)
+Build-Depends: libgd-perl:native, debhelper (>= 13~), debhelper-compat (= 13)
 Standards-Version: 4.6.1
 Homepage: https://github.com/kilobyte/braillefont
 Rules-Requires-Root: no

Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

[Dennis van Dok]

On 08-03-2023 07:03, Cyril Brulebois wrote:

Hi Dennis,

Dennis van Dok  (2023-03-07):

Can confirm that works; the alpha2 installer
https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/debian-bookworm-DI-alpha2-amd64-netinst.iso

Did see the wireless card and was able to get on my home wireless
network.


Thanks for confirming!


It's currently sitting in /etc/modules, I could remove it to see if it
is still needed. I think it is, I'm running the latest kernel:


Testing a boot without it in /etc/modules would be awesome, yes.


I just tested it and what do you know: the module is loaded 
automatically. So the tweak to /etc/modules is no longer required.


I am running a fairly new kernel:

Linux bobo 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 
(2023-02-15) x86_64 GNU/Linux


HTH,

Dennis

Bug#1032470: Acknowledgement (effect plugins tab missing in kdenlive 22.12.2-1)

[Robin]

Update:
Issue was solved for me by additionally installing the package
  qml-module-org-kde-kcm

Suggestion:
Please add the following packages to the dependecies of kdenlive:
   qml-module-org-kde-newstuff  
   qml-module-org-kde-kcm

Reference:
I found this solution here, the issue seems to be known already at kdenlive:
  https://bugs.kde.org/show_bug.cgi?id=463203

Bug#1032486: goverlay: Please add libglu1-mesa as a runtime dependency.

[Stephan Lachnit]

Hi Safir,

can you provide more details why libglu1-mesa is required by GOverlay?
I don't see any hints for it upstream.

Regards,
Stephan

Bug#1032506: plantuml: crashes on startup

[Victor Westerhuis]

Package: plantuml
Version: 1:1.2020.2+ds-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: vic...@westerhu.is

Hi maintainer,

Plantuml immediately crashes on startup with the following stacktrace:

Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libawt_xawt.so
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2393)
at java.base/java.lang.Runtime.load0(Runtime.java:755)
at java.base/java.lang.System.load(System.java:1953)
at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
at 
java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
at 
java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
at 
java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
at 
java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:315)
at 
java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:285)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2398)
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:818)
at java.base/java.lang.System.loadLibrary(System.java:1989)
at java.desktop/java.awt.image.ColorModel$1.run(ColorModel.java:210)
at java.desktop/java.awt.image.ColorModel$1.run(ColorModel.java:208)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at 
java.desktop/java.awt.image.ColorModel.loadLibraries(ColorModel.java:207)
at java.desktop/java.awt.image.ColorModel.(ColorModel.java:220)
at 
java.desktop/java.awt.image.BufferedImage.(BufferedImage.java:286)
at net.sourceforge.plantuml.FileFormat.(FileFormat.java:90)
at net.sourceforge.plantuml.Option.(Option.java:94)
at net.sourceforge.plantuml.Run.main(Run.java:88)

The requested library, /usr/lib/jvm/java-17-openjdk-amd64/lib/libawt_xawt.so,
is found in openjdk-17-jre, which is not a dependency of default-jre-headless.
It is, however, a dependency of default-jre. Manually installing default-jre
does indeed solve the error.

--
Groet, Regards,

Victor Westerhuis

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

Kernel: Linux 6.1.14+ (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 plantuml depends on:
ii  default-jre-headless  2:1.17-74
ii  libavalon-framework-java  4.2.0-10
ii  libbatik-java 1.16+dfsg-1
ii  libcommons-io-java2.11.0-2
ii  libcommons-logging-java   1.2-3
ii  libfop-java   1:2.8-2
ii  libjlatexmath-java1.0.7-3
ii  libxml-commons-external-java  1.4.01-5
ii  libxmlgraphics-commons-java   2.8-2

Versions of packages plantuml recommends:
ii  graphviz  2.42.2-7+b3

plantuml suggests no packages.

-- no debconf information

Bug#1031905: riseup-vpn: fails to connect, when pressing cancel some the ui elements will dissapear.

[Giorgos]

I did exaclty what you asked. 
Output :
d10:~$ pkexec /usr/sbin/bitmask-root firewall stop 
Traceback (most recent call last): 
  File "/usr/sbin/bitmask-root", line 120, in  
    IPTABLES = swhich("iptables") 
   ^^ 
  File "/usr/sbin/bitmask-root", line 117, in swhich 
    raise Exception("Can't find %s" % (binary,)) 
Exception: Can't find iptables 
d10:~$ echo $? 
1 
d10:~$ pkexec /usr/sbin/bitmask-root firewall start 195.154.106.118 
51.159.55.86 163.172.90.118 
Traceback (most recent call last): 
  File "/usr/sbin/bitmask-root", line 120, in  
    IPTABLES = swhich("iptables") 
   ^^ 
  File "/usr/sbin/bitmask-root", line 117, in swhich 
    raise Exception("Can't find %s" % (binary,)) 
Exception: Can't find iptables 
d10:~$ echo $? 
1


i have still the same problem.
 
6 Μαρ 2023, 06:33 Από nil...@debian.org:

> Hi Giorgos,
>
> On 3/6/23 00:13, Giorgos wrote:
>
>> [...]
>>
>
> Thanks for providing me the answers to my questions.
>
>> $ riseup-vpn
>> [...]
>> 2023/03/05 20:42:21 Error while running bitmask-root:
>> 2023/03/05 20:42:21 args:  [/usr/sbin/bitmask-root firewall stop]
>>
>
> Looks like bitmask-root has some problems starting up. Could you please
> provide me the output of these commands?
>
> $ pkexec /usr/sbin/bitmask-root firewall stop
> $ echo $?
> $ pkexec /usr/sbin/bitmask-root firewall start 195.154.106.118 51.159.55.86 
> 163.172.90.118
> $ echo $?
>
> Please consider to get back to me soonish, as we (debian) are currently in 
> freeze and it'd get
> more difficult to do further changes going ahead.
>
> Thank you!
>
> Nilesh
>

Bug#1032507: RFS: kylin-process-manager/3.0.0-1 [ITP] -- System resources watching and cgroups management

[KevinDuan]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: duankai...@ubuntukylin.com


Dear mentors,

I am looking for a sponsor for my package "kylin-process-manager":

 * Package name : kylin-process-manager
   Version  : 3.0.0-1
   Upstream contact : guopengfei 
 * URL  : https://gitee.com/openkylin/kylin-app-cgroupd
 * License  : GPL-3+, Expat
 * Vcs  : https://gitee.com/openkylin/kylin-app-cgroupd
   Section  : admin

The source builds the following binary packages:

  kylin-process-manager - System resources watching and cgroups management

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

  https://mentors.debian.net/package/kylin-process-manager/

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

  dget -x https://mentors.debian.net/debian/pool/main/k/kylin-process-
manager/kylin-process-manager_3.0.0-1.dsc

Changes for the initial release:

 kylin-process-manager (3.0.0-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1032455)

Regards,
--

KevinDuan

Bug#1029010: llvm-toolchain-15: autopkgtest regression

[Simon McVittie]

On Wed, 08 Mar 2023 at 03:11:57 +0200, Faidon Liambotis wrote:
> On Fri, Mar 03, 2023 at 05:46:15PM +, Simon McVittie wrote:
> > I don't think this is *really* a regression, because in the version in
> > bookworm, the autopkgtest didn't exercise compilation of C++ into
> > WebAssembly at all.
> 
> This statement strictly speaking is true, but applies only if you look
> at LLVM 15 in isolation. It *is* a regression, in the sense that this
> works with llvm-toolchain-14, where the WebAssembly work was first
> pushed, today, in both bookworm and sid. For example, retracing your
> steps in #1032317 with s/15/14/ does not result into a failure.

Sorry, I was confused by the binary package reorganization in the
llvm-toolchain-15 toolchain since it forked from -14, and I hadn't
realised that -14 had undergone equivalent restructuring to enable
WASM support. Yes, this is a regression since -14, even if it isn't
a regression since the -15 in bookworm.

> there is a metapackage, libc++-dev-wasm32, which Depends on the
> default implementation, which is libc++-14-dev-wasm32 right now. That
> metapackage has at least one notable reverse B-D, firefox, using it to
> build certain security/sandboxing features (RLBox[1], AIUI). That is to
> say, this feature works (w/ 14) and does very useful things today. it
> (seemingly) broke when it was ported to llvm-toolchain-15, which
> src:firefox does not depend on directly.

If I understand correctly, that doesn't *necessarily* have to be RC for
bookworm, because llvm-toolchain-15 is not (yet!) the default version
of LLVM provided by the metapackage, and is only used by Mesa? But it
would be a blocker for either moving the default forward from 14 to 15
(as has already been done in experimental), or making Firefox use the
non-default 15 toolchain like Mesa does, presumably to get some new
feature or optimization that isn't in 14?

smcv

Bug#1032508: RFS: ukui-globaltheme/0.2.1-1 [ITP] -- Heyin Global Theme for UKUI

[KevinDuan]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: duankai...@ubuntukylin.com

Dear mentors,

I am looking for a sponsor for my package "ukui-globaltheme":

 * Package name : ukui-globaltheme
   Version  : 0.2.1-1
   Upstream contact : Yue Lan 
 * URL  : https://gitee.com/openkylin/ukui-globaltheme
 * License  : GPL-3.0+
 * Vcs  : https://gitee.com/openkylin/ukui-globaltheme
   Section  : metapackages

The source builds the following binary packages:

  ukui-globaltheme-common - Common data and settings for UKUI Global Theme
  ukui-globaltheme-light-seeking - Light-Seeking Global Theme for UKUI
  ukui-globaltheme-heyin - Heyin Global Theme for UKUI

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

  https://mentors.debian.net/package/ukui-globaltheme/

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

  dget -x https://mentors.debian.net/debian/pool/main/u/ukui-globaltheme/ukui-
globaltheme_0.2.1-1.dsc

Changes for the initial release:

 ukui-globaltheme (0.2.1-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1032454)

Regards,
--
  KevinDuan

Bug#1032509: davmail: O365Interactive mode does not open web logon window - libraries not found on java path

[Phil Turner]

Package: davmail
Version: 6.0.1.3390-5
Severity: normal

Dear Maintainer,

When davmail tries to open a window to display the 365 logon screen it
fails because it can't find appropriate prism_*.so files.

I had to change the -Djava.library.path=/usr/lib/jni argument in the
launch script to
-Djava.library.path=/usr/lb/jni:/usr/x86_64-linux-gnu/jni
to get it to work. (Obviously this is architecture dependent.)

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

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

Versions of packages davmail depends on:
ii  davmail-server  6.0.1.3390-5
ii  default-jre 2:1.17-74
ii  libopenjfx-java 11.0.11+1-3
ii  libswt-cairo-gtk-4-jni  4.26.0-1

davmail recommends no packages.

davmail suggests no packages.

-- Configuration Files:
/etc/davmail/davmail.properties changed [not included]

-- no debconf information

Bug#1032506: plantuml: crashes on startup

[Andrej Shadura]

Hi,

On Wed, 8 Mar 2023, at 10:36, Victor Westerhuis wrote:
> Package: plantuml
> Version: 1:1.2020.2+ds-2
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: vic...@westerhu.is
>
> Hi maintainer,
>
> Plantuml immediately crashes on startup with the following stacktrace:

> The requested library, /usr/lib/jvm/java-17-openjdk-amd64/lib/libawt_xawt.so,
> is found in openjdk-17-jre, which is not a dependency of default-jre-headless.
> It is, however, a dependency of default-jre. Manually installing default-jre
> does indeed solve the error.

Thanks for the bug report. Does this happen always, or with some specific 
command-line options? I was told before that plantuml is known to work headless 
as well, although I hadn’t tested it myself.

-- 
Cheers,
  Andrej

Bug#1032510: packagekit: pkcon what-provides application/x-keepass2 makes PK crash

[Laurent Bigonville]

Package: packagekit
Version: 1.2.6-3
Severity: serious

Hello,

pkcon what-provides application/x-keepass2 makes PK crash:

$ pkcon what-provides application/x-keepass2
Getting provides[=]
Loading cache   [=]
Querying[=] e 
daemon crashed mid-transaction!
Finished[ ] (0%)

   Stack trace of thread 10447:
#0  0x7faf3ef75ccc __pthread_kill_implementation (libc.so.6 
+ 0x8accc)
#1  0x7faf3ef26ef2 __GI_raise (libc.so.6 + 0x3bef2)
#2  0x7faf3ef11472 __GI_abort (libc.so.6 + 0x26472)
#3  0x7faf3c89d919 
_ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x9d919)
#4  0x7faf3c8a8e1a _ZN10__cxxabiv111__terminateEPFvvE 
(libstdc++.so.6 + 0xa8e1a)
#5  0x7faf3c8a8e85 _ZSt9terminatev (libstdc++.so.6 + 
0xa8e85)
#6  0x7faf3c8a90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8)
#7  0x7faf3c8a00e4 _ZSt19__throw_logic_errorPKc 
(libstdc++.so.6 + 0xa00e4)
#8  0x7faf3e96cb3a 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC4IS3_EEPKcRKS3_ 
(libpk_backend_apt.so + 0x2cb3a)
#9  0x7faf3e95d122 backend_what_provides_thread 
(libpk_backend_apt.so + 0x1d122)
#10 0x5644cb0c7aca pk_backend_job_thread_setup (packagekitd 
+ 0x23aca)
#11 0x7faf3f5dbcfd g_thread_proxy (libglib-2.0.so.0 + 
0x7ecfd)
#12 0x7faf3ef73fd4 start_thread (libc.so.6 + 0x88fd4)
#13 0x7faf3eff466c __clone3 (libc.so.6 + 0x10966c)


This breaks GNOME ability to suggest which application to install when
opening files.

Feel free to downgrade the severity if you want.

Kind regards,
Laurent Bigonville


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

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

Versions of packages packagekit depends on:
ii  init-system-helpers 1.65.2
ii  libappstream4   0.16.1-1
ii  libapt-pkg6.0   2.6.0
ii  libc6   2.36-8
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-1
ii  libglib2.0-bin  2.74.6-1
ii  libgstreamer1.0-0   1.22.0-2
ii  libpackagekit-glib2-18  1.2.6-3
ii  libpolkit-gobject-1-0   122-3
ii  libsqlite3-03.40.1-1
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.6-1
ii  polkitd 122-3

Versions of packages packagekit recommends:
ii  packagekit-tools  1.2.6-3
ii  systemd   252.6-1

Versions of packages packagekit suggests:
ii  appstream  0.16.1-1

-- no debconf information

Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

[Cyril Brulebois]

Dennis van Dok  (2023-03-08):
> I just tested it and what do you know: the module is loaded automatically.
> So the tweak to /etc/modules is no longer required.
> 
> I am running a fairly new kernel:
> 
> Linux bobo 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15)
> x86_64 GNU/Linux

The output of `lsmod` in your installed system would be nice, to check
my lpss hypothesis (and possibly get new ideas if it doesn't check out).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1031905: riseup-vpn: fails to connect, when pressing cancel some the ui elements will dissapear.

[Nilesh Patra]

Hi Giorgos,

On 3/8/23 15:06, Giorgos wrote:

I did exaclty what you asked.
Output :
*d10*:*~*$ pkexec /usr/sbin/bitmask-root firewall stop
Traceback (most recent call last):
  File "/usr/sbin/bitmask-root", line 120, in 
    IPTABLES = swhich("iptables")
[...]

i have still the same problem.


Understood. I think this is a missing dependency, I will add it and upload.
Could you please meanwhile install "iptables"?

$ sudo apt install iptables

After you do so, try to run riseup-vpn again. It might/should work.
Could you please check this and get back to me?

Thanks,
Nilesh

Bug#1029206: [pre-approval] unblock: webkit2gtk 2.40.0-2

[Alberto Garcia]

On Mon, Mar 06, 2023 at 12:29:05PM +, Alberto Garcia wrote:
> > It's been a while. Any progress? It's getting late in the freeze
> > already.
> upstream confirmed that there are some last minutes changes to
> the API so the final soname will happen with the official 2.40.0
> release, which is planned on the weekend of the 18th of March:

Update: 2.39.91 has just been published, and upstream told me that no
more API changes are expected before 2.40.0, so I'll enable the gtk4
packages and upload them to experimental now.

Berto

Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

[Dennis van Dok]

On 08-03-2023 10:48, Cyril Brulebois wrote:

Dennis van Dok  (2023-03-08):

I just tested it and what do you know: the module is loaded automatically.
So the tweak to /etc/modules is no longer required.

I am running a fairly new kernel:

Linux bobo 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15)
x86_64 GNU/Linux


The output of `lsmod` in your installed system would be nice, to check
my lpss hypothesis (and possibly get new ideas if it doesn't check out).


Here goes:

Module  Size  Used by
tun61440  2
uinput 20480  1
vboxnetadp 28672  0
vboxnetflt 32768  0
vboxdrv   602112  2 vboxnetadp,vboxnetflt
ctr16384  3
ccm20480  9
rfcomm 94208  7
cmac   16384  3
algif_hash 16384  1
algif_skcipher 16384  1
af_alg 36864  6 algif_hash,algif_skcipher
snd_seq_dummy  16384  0
snd_hrtimer16384  1
snd_seq90112  7 snd_seq_dummy
snd_seq_device 16384  1 snd_seq
qrtr   49152  4
ipmi_devintf   20480  0
ipmi_msghandler77824  1 ipmi_devintf
bnep   28672  2
binfmt_misc24576  1
nls_ascii  16384  1
nls_cp437  20480  1
vfat   24576  1
fat90112  1 vfat
snd_ctl_led24576  0
snd_soc_skl_hda_dsp24576  4
snd_soc_intel_hda_dsp_common20480  1 snd_soc_skl_hda_dsp
snd_soc_hdac_hdmi  45056  1 snd_soc_skl_hda_dsp
snd_sof_probes 24576  0
snd_hda_codec_hdmi 81920  1
snd_hda_codec_realtek   172032  1
snd_hda_codec_generic98304  1 snd_hda_codec_realtek
ledtrig_audio  16384  2 snd_ctl_led,snd_hda_codec_generic
snd_soc_dmic   16384  1
snd_sof_pci_intel_tgl16384  0
snd_sof_intel_hda_common   188416  1 snd_sof_pci_intel_tgl
soundwire_intel49152  1 snd_sof_intel_hda_common
iwlmvm385024  0
soundwire_generic_allocation16384  1 soundwire_intel
soundwire_cadence  40960  1 soundwire_intel
snd_sof_intel_hda  20480  1 snd_sof_intel_hda_common
snd_sof_pci24576  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_sof_xtensa_dsp 16384  1 snd_sof_intel_hda_common
snd_sof   274432  3 
snd_sof_pci,snd_sof_intel_hda_common,snd_sof_probes
mac80211 1175552  1 iwlmvm
snd_sof_utils  20480  1 snd_sof
snd_soc_hdac_hda   24576  1 snd_sof_intel_hda_common
snd_hda_ext_core   40960  3 
snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda
snd_soc_acpi_intel_match73728  2 
snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
x86_pkg_temp_thermal20480  0
snd_soc_acpi   16384  2 
snd_soc_acpi_intel_match,snd_sof_intel_hda_common
intel_powerclamp   20480  0
snd_soc_core  348160  8 
soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_sof_probes,snd_soc_dmic,snd_soc_skl_hda_dsp
btusb  65536  0
btrtl  28672  1 btusb
coretemp   20480  0
btbcm  24576  1 btusb
btintel45056  1 btusb
snd_compress   28672  2 snd_soc_core,snd_sof_probes
btmtk  16384  1 btusb
kvm_intel 380928  0
bluetooth 950272  44 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm
soundwire_bus 102400  3 
soundwire_intel,soundwire_generic_allocation,soundwire_cadence
libarc416384  1 mac80211
kvm  1138688  1 kvm_intel
snd_hda_intel  57344  0
snd_intel_dspcfg   36864  3 snd_hda_intel,snd_sof,snd_sof_intel_hda_common
snd_intel_sdw_acpi 20480  2 snd_sof_intel_hda_common,snd_intel_dspcfg
irqbypass  16384  1 kvm
iwlwifi   360448  1 iwlmvm
snd_hda_codec 184320  8 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_intel_hda_dsp_common,snd_soc_hdac_hda,snd_sof_intel_hda,snd_soc_skl_hda_dsp
snd_hda_core  122880  11 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_soc_intel_hda_dsp_common,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_sof_intel_hda
jitterentropy_rng  16384  1
uvcvideo  131072  0
rapl   20480  0
processor_thermal_device_pci16384  0
processor_thermal_device20480  1 processor_thermal_device_pci
snd_hwdep  16384  1 snd_hda_codec
videobuf2_vmalloc  20480  1 uvcvideo
iTCO_wdt   16384  0
processor_thermal_rfim16384  1 processor_thermal_device
pmt_telemetry  16384  0
videobuf2_memops   20480  1 videobuf2_vmalloc
intel_pmc_bxt  16384  1 iTCO_wdt
videobuf2_v4l2 36864  1 uvcvideo
processor_thermal_mbox16384  2 
processor_thermal_rfim,processor_thermal_device
mei_hdcp   24576  0
snd_pcm   159744 

Bug#1032506: plantuml: crashes on startup

[Victor Westerhuis]

Hi (again) Andrej,

Victor Westerhuis schreef op 08.03.2023 10:56:

Control: severity -1 important

Hi Andrej,

Thanks for the quick response.

Andrej Shadura schreef op 08.03.2023 10:44:

Hi,

On Wed, 8 Mar 2023, at 10:36, Victor Westerhuis wrote:

Package: plantuml
Version: 1:1.2020.2+ds-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: vic...@westerhu.is

Hi maintainer,

Plantuml immediately crashes on startup with the following 
stacktrace:


The requested library, 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libawt_xawt.so,
is found in openjdk-17-jre, which is not a dependency of 
default-jre-headless.
It is, however, a dependency of default-jre. Manually installing 
default-jre

does indeed solve the error.


Thanks for the bug report. Does this happen always, or with some
specific command-line options? I was told before that plantuml is
known to work headless as well, although I hadn’t tested it myself.


The issue is in
https://salsa.debian.org/debian/plantuml/-/blob/master/debian/plantuml.sh#L29-32:
if the DISPLAY environment variable is unset the headless AWT backend
is requested, which is correct. However, the opposite is not
necessarily true: if DISPLAY is set, default-jre is not necessarily
installed.
I have opened a MR on Salsa with a fix at 
https://salsa.debian.org/debian/plantuml/-/merge_requests/3.


I have downgraded the severity, because explicitly unsetting DISPLAY
before calling /usr/bin/plantuml fixes the crash.

--
Groet, Regards,

Victor Westerhuis

--
Groet, Regards,

Victor Westerhuis

Bug#1032511: Unneeded versioned dependency to libx11-xcb1

[Klaus Ethgen]

Package: firefox
Version: 110.0.1-1
Severity: important

The package has an versioned dependency to libxcb-xkb1, which currently
prevent the workaround about a critical bug in that library by using the
version bevore the current one.
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1032512: Unneeded versioned dependency to libx11-xcb1

[Klaus Ethgen]

Package: libqt6opengl6
Version: 6.4.2+dfsg-7
Severity: important

The package has an versioned dependency to libxcb-xkb1, which currently
prevent the workaround about a critical bug in that library by using the
version bevore the current one.
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1032513: Unneeded versioned dependency to libx11-xcb1

[Klaus Ethgen]

Package: libqt6gui6
Version: 6.4.2+dfsg-7
Severity: important

The package has an versioned dependency to libxcb-xkb1, which currently
prevent the workaround about a critical bug in that library by using the
version bevore the current one.
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1032290:

[Mason Xiaohan Liu]

Did you get my mail

Bug#1032379: bug#746: Killed when starting modale dialog like pinentry

[Klaus Ethgen]

Am Mi den  8. Mär 2023 um 11:18 schrieb Mark Hindley:
> Thanks for this. I am glad you found it.
> 
> On Wed, Mar 08, 2023 at 11:00:45AM +0100, Klaus Ethgen wrote:
> > Am Mi den  8. Mär 2023 um 10:37 schrieb Klaus Ethgen:
> > > I think, the bug can be reassignet to fvwm2.
> > > 
> > > I seen the following line in .xsession-errors. I did not see it bevore
> > > as this file is removed with every login..
> > >fvwm2: ../../src/xcb_io.c:626: _XAllocID: Zusicherung »ret != inval_id«
> > > nicht erfüllt.
> 
> A quick look shows quite a few recent similar reports in various unrelated
> packages. So it may be caused by src:libx11 which produces libx11-xcb1.
> 
> > Well, maybe not in fvwm2 as that file is not part of fvwm.
> 
> Maybe you can add this information to #1032379 and reassign?

I can prove it. If I revert the last update of libx11-6, libx11-data and
libx11-xcb1, everything works correct again.

Gruß
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1032379: bug#746: Killed when starting modale dialog like pinentry

[Mark Hindley]

On Wed, Mar 08, 2023 at 11:26:37AM +0100, Klaus Ethgen wrote:
> > Maybe you can add this information to #1032379 and reassign?
> 
> I can prove it. If I revert the last update of libx11-6, libx11-data and
> libx11-xcb1, everything works correct again.

Good work! Thanks.

Mark

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Bálint Réczey]

Hi Alejandro,

Alejandro Colomar  ezt írta (időpont: 2023.
márc. 5., V, 20:44):
>
> Package: passwd
> Source: shadow
> Tags: patch
> X-Debbugs-CC: Bálint Réczey 
> X-Debbugs-CC: Iker Pedrosa 
> X-Debbugs-CC: Serge Hallyn 
>
> These dependencies were added upstream recently.
>
> Signed-off-by: Alejandro Colomar 
> Cc: Iker Pedrosa 
> Cc: Serge Hallyn 
> ---
>  debian/control | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/debian/control b/debian/control
> index 3cc66f8d..75015c35 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -11,11 +11,13 @@ Build-Depends: bison,
> gettext,
> itstool,
> libaudit-dev [linux-any],
> +   libbsd-dev,

I checked out recent changes in shadow's master and I'm very happy
about many of the fixes for memory allocation problems,
but wearing my maintainer hat I believe linking to a new library for a
few functions which are not very different from their glibc
counterpart is not worth it.
There are reasons for strlcpy() not being provided by glibc [1]:

"Reactions among core glibc contributors on the topic of including
strlcpy() and strlcat() have been varied over the years. Christoph
Hellwig's early patch was rejected in the then-primary maintainer's
inimitable style (1 and 2). But reactions from other glibc developers
have been more nuanced, indicating, for example, some willingness to
accept the functions. Perhaps most insightfully, Paul Eggert notes
that even when these functions are provided (as an add-on packaged
with the application), projects such as OpenSSH, where security is of
paramount concern, still manage to either misuse the functions
(silently truncating data) or use them unnecessarily (i.e., the
traditional strcpy() and strcat() could equally have been used without
harm); such a state of affairs does not constitute a strong argument
for including the functions in glibc. "

I agree with their position and the 6 cases where strlcpy() is used in
shadow's current master could be implemented with strncpy() as safely
as with strlcpy().

Freezero() also provides little extra benefit over memset() and free()
and is used only 4 times in the code.

Could you please return to using functions provided by glibc instead
of pulling in libbsd in the next upstream release?
That way there would be no need for pkg-config or pkgconf either.

Cheers,
Balint

[1] https://lwn.net/Articles/507319/

Bug#983600: Is there a workaround for this?

[Kevin P. Fleming]

This package is a transitive *unused* dependency of something I'm trying to 
cross-build (using pbuilder), and the fact that I can't install it stops the 
entire process. If there's any way I can force this package to be installed 
despite the broken dependency chain I could likely make progress.

Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

[Cyril Brulebois]

Dennis van Dok  (2023-03-08):
> intel_lpss_pci 28672  0
> intel_lpss 16384  1 intel_lpss_pci

Thanks, that's indeed what I had in mind. I need to finish chasing
regressions/fixes on Raspberry Pi, I've noted that down for later.

I should be able to share a small(-ish) ISO for you to test, so that
you can check whether touchpad support becomes available. Same story
as before: that'd be just about booting the installer, reaching the
language selection screen, and letting us know whether the touchpad's
working.

If that works, I'll need to coordinate with the kernel team to see
which component should be used to ship those modules (which would
then be picked up by further installer builds).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1032419: (no subject)

[Daniel Swarbrick]

jq is already a Recommends.

Due to the potentially very diverse nature of this package, making 
everything that is referenced by any / all scripts in the package a 
Depends is going to pollute systems. For example, the ipmi textfile 
collector requires ipmitool, but it's also only a Recommends.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031192: toil: FTBFS (The job JobClass is requesting 2.0 cores)

[Santiago Vila]

Here is a build log.

Thanks.

toil.build.log.gz
Description: application/gzip

Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start

[Andreas Hasenack]

Hi,

On Wed, Mar 8, 2023 at 1:33 AM Benedikt Spranger  wrote:

> After adopting /etc/apparmor.d/usr.sbin.kea-dhcp4 by adding
> "owner /run/kea/logger_lockfile rwk,":
>
>
This rule exists in the apparmor profile already:
https://salsa.debian.org/debian/isc-kea/-/blob/debian/unstable/debian/usr.sbin.kea-dhcp4#L36


DHCP4_INIT_FAIL failed to initialize Kea server: configuration error
> using file '/etc/kea/kea-dhcp4.conf': Unable to open database: unable to
> open '/var/lib/kea/kea-leases4.csv'
>
>
There is a rule for that too:

https://salsa.debian.org/debian/isc-kea/-/blob/debian/unstable/debian/usr.sbin.kea-dhcp4#L45

Maybe you have some other apparmor profile installed, and when you upgraded
the package, it wasn't replaced?

What are the contents of your /etc/apparmor.d/usr.sbin.kea-dhcp4 file?

Do you have some dpkg backup file perhaps? Check
/etc/apparmor.d/usr.sbin.kea-dhcp4*

Bug#1032514: unblock: quakespasm/0.95.1+dfsg-2

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: quakesp...@packages.debian.org
Control: affects -1 + src:quakespasm

Please unblock package quakespasm

[ Reason ]
Fix #1032276

[ Impact ]
If not fixed, when the quake-server package is installed and quakespasm is
the selected alternative for quake-engine-server, the quake-server systemd
service spams the system log with rapid "Console input too long" messages.

[ Tests ]
Manual test: can configure /etc/alternatives/quake-engine-server =
/usr/games/quakespasm, systemctl restart quake-server.service, and connect
a client with `quake --engine=quakespasm '+connect 127.0.0.1'`. With the
version in bookworm, "Console input too long" messages appear until the
server is stopped. With the proposed version, those messages do not appear.

[ Risks ]
Low risk: almost a leaf package (one of multiple options for contrib
packages quake and quake-server), the patch is simple, and its small user
base is indicated by the fact that it has taken this long for anyone to
notice that the bug existed.

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

unblock quakespasm/0.95.1+dfsg-2
diffstat for quakespasm-0.95.1+dfsg quakespasm-0.95.1+dfsg

 Quake/sys_sdl_unix.c  |   14 ++
 debian/.gitignore |5 
 debian/changelog  |9 +
 debian/control|2 
 debian/patches/series |1 
 debian/patches/sys_sdl_unix-Stop-reading-from-stdin-when-EOF-is-reached.patch |   58 ++
 6 files changed, 87 insertions(+), 2 deletions(-)

diff -Nru quakespasm-0.95.1+dfsg/debian/changelog quakespasm-0.95.1+dfsg/debian/changelog
--- quakespasm-0.95.1+dfsg/debian/changelog	2022-11-08 07:57:52.0 +
+++ quakespasm-0.95.1+dfsg/debian/changelog	2023-03-07 11:56:29.0 +
@@ -1,3 +1,12 @@
+quakespasm (0.95.1+dfsg-2) unstable; urgency=medium
+
+  * Add patch to fix running the server with /dev/null as stdin.
+In particular, this makes it suitable for the systemd service in the
+quake package. (Closes: #1032276)
+  * Standards-Version: 4.6.2 (no changes required)
+
+ -- Simon McVittie   Tue, 07 Mar 2023 11:56:29 +
+
 quakespasm (0.95.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru quakespasm-0.95.1+dfsg/debian/control quakespasm-0.95.1+dfsg/debian/control
--- quakespasm-0.95.1+dfsg/debian/control	2022-09-16 10:48:48.0 +0100
+++ quakespasm-0.95.1+dfsg/debian/control	2023-03-07 11:56:29.0 +
@@ -13,7 +13,7 @@
libsdl2-dev,
libvorbis-dev
 Rules-Requires-Root: no
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/games-team/quakespasm
 Vcs-Git: https://salsa.debian.org/games-team/quakespasm.git
 Homepage: http://quakespasm.sourceforge.net/
diff -Nru quakespasm-0.95.1+dfsg/debian/.gitignore quakespasm-0.95.1+dfsg/debian/.gitignore
--- quakespasm-0.95.1+dfsg/debian/.gitignore	1970-01-01 01:00:00.0 +0100
+++ quakespasm-0.95.1+dfsg/debian/.gitignore	2023-03-07 11:56:29.0 +
@@ -0,0 +1,5 @@
+/*.debhelper.log
+/*.substvars
+/files
+/quakespasm/
+/quakespasm-dbg/
diff -Nru quakespasm-0.95.1+dfsg/debian/patches/series quakespasm-0.95.1+dfsg/debian/patches/series
--- quakespasm-0.95.1+dfsg/debian/patches/series	2022-09-16 10:48:48.0 +0100
+++ quakespasm-0.95.1+dfsg/debian/patches/series	2023-03-07 11:56:29.0 +
@@ -4,3 +4,4 @@
 mkpak-bashism.patch
 reproducible-build.patch
 rotfish-double-count.patch
+sys_sdl_unix-Stop-reading-from-stdin-when-EOF-is-reached.patch
diff -Nru quakespasm-0.95.1+dfsg/debian/patches/sys_sdl_unix-Stop-reading-from-stdin-when-EOF-is-reached.patch quakespasm-0.95.1+dfsg/debian/patches/sys_sdl_unix-Stop-reading-from-stdin-when-EOF-is-reached.patch
--- quakespasm-0.95.1+dfsg/debian/patches/sys_sdl_unix-Stop-reading-from-stdin-when-EOF-is-reached.patch	1970-01-01 01:00:00.0 +0100
+++ quakespasm-0.95.1+dfsg/debian/patches/sys_sdl_unix-Stop-reading-from-stdin-when-EOF-is-reached.patch	2023-03-07 11:56:29.0 +
@@ -0,0 +1,58 @@
+From: Simon McVittie 
+Date: Tue, 7 Mar 2023 11:46:00 +
+Subject: sys_sdl_unix: Stop reading from stdin when EOF is reached
+
+If the quakespasm server is run noninteractively with stdin redirected
+from /dev/null (for example as a systemd service), this loop would
+previously ignore EOF (read() returns 0) and append the uninitialized
+contents of `c` to the buffer once per iteration, until the buffer is
+full, at which point it would log "Console input too long!" and repeat.
+
+For complet

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Bálint Réczey]

Hi Serge,

Serge E. Hallyn  ezt írta (időpont: 2023. márc. 6., H, 21:30):
>
> On Mon, Mar 06, 2023 at 08:41:15PM +0100, Bálint Réczey wrote:
> > Hi Alejandro,
> >
> >
> > Alejandro Colomar  ezt írta (időpont: 2023.
> > márc. 5., V, 20:38):
> > >
> > > Package: passwd
> > > Source: shadow
> > > Tags: patch
> > > X-Debbugs-CC: Bálint Réczey 
> > > X-Debbugs-CC: Iker Pedrosa 
> > > X-Debbugs-CC: Serge Hallyn 
> > > To: sub...@bugs.debian.org
> > >
> > > Hi Balint,
> > >
> > > This is my first patch set sent to Debbugs.  Let's see if I do it
> > > correctly :).
> > >
> > > I can't open a MR in Salsa, since my account is still to be approved
> > > (I opened it yesterday).  BTW, if you have any contacts there, please
> > > have a look at it; the identifier is 'alx' and the associated email is
> > > .  I sent a mail to the Salsa admin a week ago but
> > > received no response (but I guess they might be busy).
> > >
> > > Cheers,
> > >
> > > Alex
> > >
> > > ---
> > >
> > > Alejandro Colomar (2):
> > >   debian/control: Sort alphabetically package lists
> > >   debian/control: Add libbsd-dev and pkg-config
> > >
> > >  debian/control | 26 ++
> > >  1 file changed, 14 insertions(+), 12 deletions(-)
> > >
> > > Range-diff against v1:
> > > -:   > 1:  3d079bd9 debian/control: Sort alphabetically package 
> > > lists
> > > 1:  48ac3d10 ! 2:  9e323b50 debian/control: Add libbsd-dev and pkg-config
> > > @@ debian/control: Build-Depends: bison,
> > >  libselinux1-dev [linux-any],
> > >  libsemanage-dev [linux-any],
> > >  libxml2-utils,
> > > -+   pkg-config,
> > > ++   pkgconf,
> >
> > Thank you for the good intention, but this change won't be needed
> > because pkgconf will provide pkg-config according to the plan:
> >
> > https://lists.debian.org/debian-devel/2022/07/msg00252.html
> >
> > Cheers,
> > Balint
>
> Hi Balint,
>
> right now shadow is not depending on either one.  Alex is adding
> the pkgconf one.  This diff is between Alex's two diffs, showing
> that his first diff had added pkg-config, while v2 is instead doing
> pkgconf.

Yes, and I'd still depend on the more mature pkg-config variant if one
variant is added until the archive-wide transition to pkgconf is
completed.

Cheers,
Balint

Bug#1032515: libsoup-3.0-0: Can't download from https://www.bing.com - connection reset by peer

[Sam Morris]

Package: libsoup-3.0-0
Version: 3.2.2-2
Severity: normal
X-Debbugs-Cc: s...@robots.org.uk

With the following python script I get:

$ python3 bing.py 
Traceback (most recent call last):
  File "/tmp/bing.py", line 7, in 
ses.send_and_read(mes)
gi.repository.GLib.GError: g-io-error-quark: Error receiving data: 
Connection reset by peer (44)

Here's the script:

import gi

gi.require_version("Soup", "3.0")

from gi.repository import Soup

mes = Soup.Message.new_from_encoded_form(
"GET",
"https://www.bing.com/HPImageArchive.aspx";,
Soup.form_encode_hash(
{"format": "js", "idx": "0", "n": "1", "mbl": "1", "mkt": "auto"}
),
)
ses = Soup.Session()
ses.send_and_read(mes)

Soup 2.4 is able to access the same URL just fine, there's a gjs script
to demonstrate at
.

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libsoup-3.0-0 depends on:
ii  glib-networking 2.66.0-2
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-8
ii  libglib2.0-02.74.5-1
ii  libgssapi-krb5-21.20.1-1
ii  libnghttp2-14   1.52.0-1
ii  libpsl5 0.21.0-1.2
ii  libsoup-3.0-common  3.2.2-2
ii  libsqlite3-03.40.1-1
ii  zlib1g  1:1.2.11.dfsg-2+deb11u2

libsoup-3.0-0 recommends no packages.

libsoup-3.0-0 suggests no packages.

-- no debconf information

Bug#1032450: unblock (pre-approval): gtk+3.0/3.24.37-2

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-03-07 01:12:58 +, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: gtk+...@packages.debian.org
> Control: affects -1 + src:gtk+3.0
> 
> gtk+3.0_3.24.37 is in experimental at the moment, and we'd like to
> include it in bookworm if possible.
> 
> [ Reason ]
> Resync with upstream release. What we have in bookworm at the moment
> is GTK 3.24.36 and something like half of 3.24.37; rebasing on 3.24.37
> seems a better basis for a stable release.

Agreed. Please go ahead.

Are there any other stable releases planned for the 3.24.x series during
the freeze?

Cheers

> 
> We could apply selected changes from 3.24.37 as patches, but at some
> point we're just reconstructing 3.24.37 with extra steps.
> 
> [ Impact ]
> Updating to the version in experimental will give us:
> - support for transparent drag-and-drop of files between sandboxed
>   Flatpak GTK 3/GTK 4 apps (hopefully also Qt in future), and
>   non-sandboxed GTK 3 apps from Debian
> - the upstream fix for an annoying regression where spurious startup
>   notifications appear in the GNOME top bar and newly-launched GTK 3 apps
>   don't reliably appear in Alt+Tab, replacing our previous
>   upstream-rejected workaround which didn't completely solve this
> - various smaller bug fixes, some of which resolve potential crashes
> 
> Also, the patches added in 3.24.36-3 and 3.24.36-4 are now part of the
> upstream source, giving users a better picture of what version we're
> actually providing.
> 
> [ Tests ]
> Installed in a GNOME desktop for manual testing with
> no obvious regressions, and I can no longer reproduce
> https://gitlab.gnome.org/GNOME/gtk/-/issues/5386.
> 
> I was also able to drag-and-drop a file from Nautilus onto the
> org.gtk.Demo4 Flatpak app from 
> (specifically the Clipboard window), where it appears as an
> xdg-document-portal filename when dropped on the bottom half of the demo.
> 
> autopkgtest reports one apparent regression for gnome-photos, but I think
> it might be spurious (the test getting stuck). I'll try to investigate it
> if it turns out to be reproducible.
> 
> [ Risks ]
> I wouldn't normally be adding the file transfer portal (drag-and-drop
> to/from sandboxes) at this stage in the release cycle, but it's a good
> feature to have if we want users to be able to run more sandboxed apps
> over the next 2 years, and surprisingly little code. It does have one
> potential interop issue (using a non-standard MIME type) which I've
> reported upstream. I hope fixing that should be a simple change
> (< 10 lines).
> 
> Similarly I wouldn't normally be adding the changes in gdk/broadway/ at
> this stage in the release cycle, but hardly anyone uses the GTK broadway
> backend (it's a mechanism for displaying apps via a web browser) and
> patching them out seems like it would be more disruptive than helpful.
> 
> [ 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 testing
> 
> The attached diff is between the patched trees, excluding the actual
> patches and some Windows- and macOS-specific changes to avoid noise.
> I normally upload using dgit, so the contents of git and the debdiff
> will match exactly.

> diff --git a/NEWS b/NEWS
> index fdd44e6e77..c4191123a9 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,3 +1,25 @@
> +Overview of Changes in GTK+ 3.24.37, 02-03-2023
> +===
> +
> +* Support the file transfer portal for copy-paste and DND
> +
> +* Treat XKB_MODE_NAME_LODO as super key
> +
> +* Refactor startup notification handling to be in sync with GTK 4
> +
> +* GL: Synchronie when calling MakeCurrent
> +
> +* CSS: Fix a problem with stopping animations
> +
> +* Wayland: Drop the legacy text input module
> +
> +* Windows: Set the default file extension in the native file chooser
> +
> +* Translation updates:
> + Abkhazian
> + Turkish
> +
> +
>  Overview of Changes in GTK+ 3.24.36, 12-22-2022
>  ===
>  
> diff --git a/debian/changelog b/debian/changelog
> index c7c69ef1c0..d115481e26 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,43 @@
> +gtk+3.0 (3.24.37-2) UNRELEASED; urgency=medium
> +
> +  * d/copyright: Remove gtk-text-input.xml.
> +This file is no longer present in the source package.
> +  * Remove Lintian overrides for lintian/lintian!452, no longer necessary
> +
> + -- Simon McVittie   Tue, 07 Mar 2023 00:07:09 +
> +
> +gtk+3.0 (3.24.37-1) experimental; urgency=medium
> +
> +  * New upstream release
> +- Add support for xdg-desktop-portal file transfer API, allowing
> +  copy/paste and drag-and-drop of files where one of the apps involved
> +  is sandboxed by Flatpak, Snap or similar (GNOME/gtk!5554)
> +- Fix a 

Bug#1031765: pgrep: signal handler matching breaks argument parsing

[Heinrich Schuchardt]

Upstream has merged https://github.com/ganeti/ganeti/pull/1692, commit 
9cd67e6a81c6 ("uidpool_unittest: avoid using negative UIDs") to solve 
the issue.


Additionally the following patch is needed to fix a separate problem 
with testing:

a40748ab26fc ("py-tests: make tests compatible with roman 3.2+")

Best regards

Heinrich

Bug#1032516: mysql-8.0: [INTL:tr] turkish debconf translation update

[Atila KOÇ]

Package: mysql-8.0
Version: N/A
Severity: wishlist
Tags: l10n patch

Hello,

Find attached the updated Turkish translation of the mysql-8.0 debconf 
template.

It has been submitted for review to the debian-l10n-turkish mailing list.
Please include it in your next upload.

Regards,
Atila KOÇ

--- YASAL UYARI ---

# Turkish debconf translation of mysql-8.0 package
# This file is distributed under the same license as the mysql-8.0 package.
# Atila KOÇ , 2012, 2015, 2018, 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: mysql-8.0\n"
"Report-Msgid-Bugs-To: mysql-...@packages.debian.org\n"
"POT-Creation-Date: 2018-12-07 09:36+0100\n"
"PO-Revision-Date: 2023-02-20 09:51+0300\n"
"Last-Translator: Atila KOÇ \n"
"Language-Team: Debian L10n Turkish \n"
"Language: tr\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: note
#. Description
#: ../mysql-server-8.0.templates:2001
msgid "Automatic maintenance of MySQL server daemon disabled"
msgstr "MySQL sunucusu hizmetinin otomatik bakımı etkisizleştirildi"

#. Type: note
#. Description
#: ../mysql-server-8.0.templates:2001
msgid ""
"Packaging maintainer scripts detected a case that it does not know how to "
"handle and cannot continue configuring MySQL. Automatic management of your "
"MySQL installation has been disabled to allow other packaging tasks to "
"complete. For more details, see /etc/mysql/FROZEN."
msgstr ""
"Paket yönetimi betikleri nasıl çözeceklerini bilemedikleri bir sorunla "
"karşılaştılar ve bu nedenle MySQL yapılandırmasını sürdüremeyecekler. MySQL "
"kurulumunuzun otomatik yönetimi, diğer paket yönetimi işlerinin "
"tamamlanmasına izin vermek için etkisizleştirildi. Daha fazla bilgi için /"
"etc/mysql/FROZEN dosyasını inceleyin."

#. Type: note
#. Description
#: ../mysql-server-8.0.templates:3001
msgid "Important note for NIS/YP users"
msgstr "NIS/YP kullanıcıları için önemli not"

#. Type: note
#. Description
#: ../mysql-server-8.0.templates:3001
msgid ""
"Using MySQL under NIS/YP requires a mysql user account to be added on the "
"local system with:"
msgstr ""
"MySQL'in NIS/YP ile kullanılması, yerel sisteme aşağıdaki ile bir mysql "
"kullanıcı hesabının eklenmesini gerektirir:\""

#. Type: note
#. Description
#: ../mysql-server-8.0.templates:3001
msgid ""
"You should also check the permissions and ownership of the /var/lib/mysql "
"directory:"
msgstr ""
"Buna ek olarak /var/lib/mysql dizininin sahiplik ve izin ayarlarını da "
"gözden geçirmelisiniz:"

#. Type: boolean
#. Description
#: ../mysql-server-8.0.templates:4001
msgid "Remove all MySQL databases?"
msgstr "Tüm MySQL veritabanları kaldırılsın mı?"

#. Type: boolean
#. Description
#: ../mysql-server-8.0.templates:4001
msgid ""
"The /var/lib/mysql directory which contains the MySQL databases is about to "
"be removed."
msgstr ""
"MySQL veritabanlarını barındıran /var/lib/mysql dizini kaldırılmak üzere."

#. Type: boolean
#. Description
#: ../mysql-server-8.0.templates:4001
msgid ""
"This will also erase all data in /var/lib/mysql-files as well as /var/lib/"
"mysql-keyring."
msgstr ""
"Bu işlem /var/lib/mysql-files ve /var/lib/mysql-keyring dizinlerindeki "
"verileri de silecektir."

#. Type: boolean
#. Description
#: ../mysql-server-8.0.templates:4001
msgid ""
"If you're removing the MySQL package in order to later install a more recent "
"version or if a different mysql-server package is already using it, the data "
"should be kept."
msgstr ""
"Eğer MySQL paketini daha sonra güncel bir sürümünü kurmak üzere "
"kaldırıyorsanız ya da veritabanlarınızı başka bir mysql-server sürümü ile "
"kullanıyorsanız, verinizi saklamalısınız\""

#. Type: boolean
#. Description
#: ../mysql-server-8.0.templates:5001
msgid "Start the MySQL server on boot?"
msgstr "MySQL sunucusu açılış sırasında başlatılsın mı?"

#. Type: boolean
#. Description
#: ../mysql-server-8.0.templates:5001
msgid ""
"The MySQL server can be launched automatically at boot time or manually with "
"the '/etc/init.d/mysql start' command."
msgstr ""
"MySQL sunucusu açılış sırasında otomatikman ya da sonradan '/etc/init.d/"
"mysql start' komutu çalıştırılarak elle başlatılabilir."

#. Type: password
#. Description
#: ../mysql-server-8.0.templates:6001
msgid "New password for the MySQL \"root\" user:"
msgstr "MySQL \"root\" kullanıcısı için yeni parola:"

#. Type: password
#. Description
#: ../mysql-server-8.0.templates:6001
msgid ""
"While not mandatory, it is highly recommended that you set a password for "
"the MySQL administrative \"root\" user."
msgstr ""
"Zorunlu olmasa da, MySQL yönetici hesabı \"root\" kullanıcısı için bir "
"parola oluşturulması kuvvetle önerilir."

#. Type: password
#. Description
#: ../mysql-server-8.0.templates:6001
msgid "If this field is left blank, the password will not be changed."
msgstr "Bu alan boş bırakılırsa, parola değiştirilmeyecektir."

#. Type: password
#. Descriptio

Bug#994189: RFP

[matthias . geiger1024]

Note that there is jellyfin-server and jellyfin-media player. Both provide 
debian packages, they look good enough to be used as base.  The media player 
uses some extrenal libs that would need packaging first: 
https://github.com/jellyfin/jellyfin-media-player/tree/master/external

Regards,
---
Matthias Geiger (werdahias)

Bug#1032517: nginx settings deleted on upgrade

[Ralf Jung]

Package: nginx
Version: 1.22.1-7
Severity: grave
Justification: causes non-serious data loss

Dear Maintainer,

last weekend I did an "apt upgrade" of my system as usual, asking apt to prune 
configuration files for packages that are being uninstalled.
Now I realize that my nginx stopped working, and it turns out its configuration 
files are just completely gone.
Look like the recent package reorganization went wrong and actually deletes 
configuration under certain conditions -- that's pretty bad.
Package updates shouldn't cause a loss of configuration files, even when 
pruning packages that are not present any more.

Kind regards,
Ralf

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

Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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 nginx depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  iproute2   6.1.0-1
ii  libc6  2.36-8
ii  libcrypt1  1:4.4.33-2
ii  libpcre2-8-0   10.42-1
ii  libssl33.0.8-1
ii  zlib1g 1:1.2.13.dfsg-1

nginx recommends no packages.

Versions of packages nginx suggests:
ii  fcgiwrap   1.1.0-14
pn  nginx-doc  
ii  ssl-cert   1.1.2

-- Configuration Files:
/etc/nginx/fastcgi.conf [Errno 2] No such file or directory: 
'/etc/nginx/fastcgi.conf'
/etc/nginx/fastcgi_params [Errno 2] No such file or directory: 
'/etc/nginx/fastcgi_params'
/etc/nginx/koi-utf [Errno 2] No such file or directory: '/etc/nginx/koi-utf'
/etc/nginx/koi-win [Errno 2] No such file or directory: '/etc/nginx/koi-win'
/etc/nginx/mime.types [Errno 2] No such file or directory: 
'/etc/nginx/mime.types'
/etc/nginx/nginx.conf [Errno 2] No such file or directory: 
'/etc/nginx/nginx.conf'
/etc/nginx/proxy_params [Errno 2] No such file or directory: 
'/etc/nginx/proxy_params'
/etc/nginx/scgi_params [Errno 2] No such file or directory: 
'/etc/nginx/scgi_params'
/etc/nginx/sites-available/default [Errno 2] No such file or directory: 
'/etc/nginx/sites-available/default'
/etc/nginx/snippets/fastcgi-php.conf [Errno 2] No such file or directory: 
'/etc/nginx/snippets/fastcgi-php.conf'
/etc/nginx/snippets/snakeoil.conf [Errno 2] No such file or directory: 
'/etc/nginx/snippets/snakeoil.conf'
/etc/nginx/uwsgi_params [Errno 2] No such file or directory: 
'/etc/nginx/uwsgi_params'
/etc/nginx/win-utf [Errno 2] No such file or directory: '/etc/nginx/win-utf'

-- debconf information:
  nginx/log-symlinks:

Bug#1032221: [pkg-cryptsetup-devel] Bug#1032221: Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Christoph Anton Mitterer]

Control: reopen -1

On Wed, 2023-03-08 at 08:16 +0100, Milan Broz wrote:
> Just upstream is no longer responding here...

Seems upstream is dead... I also have some minor PRs open against
argon2, but no response. Tried to get directly in contact with some of
them, but the same.

@Guilhem, I'm reopening this for now.


Cheers,
Chris.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Bálint,

[I reordered some quotes for my reply]
[CC Paul, since he's been mentioned, and I'm curious to know
if he has any comments]

On 3/8/23 11:59, Bálint Réczey wrote:
> Hi Alejandro,
> 
> Alejandro Colomar  ezt írta (időpont: 2023.
> márc. 5., V, 20:44):
>>
>> Package: passwd
>> Source: shadow
>> Tags: patch
>> X-Debbugs-CC: Bálint Réczey 
>> X-Debbugs-CC: Iker Pedrosa 
>> X-Debbugs-CC: Serge Hallyn 
>>
>> These dependencies were added upstream recently.
>>
>> Signed-off-by: Alejandro Colomar 
>> Cc: Iker Pedrosa 
>> Cc: Serge Hallyn 
>> ---
>>  debian/control | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/debian/control b/debian/control
>> index 3cc66f8d..75015c35 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -11,11 +11,13 @@ Build-Depends: bison,
>> gettext,
>> itstool,
>> libaudit-dev [linux-any],
>> +   libbsd-dev,
> 
> I checked out recent changes in shadow's master and I'm very happy
> about many of the fixes for memory allocation problems,

Thanks! :-)

> but wearing my maintainer hat I believe linking to a new library for a
> few functions which are not very different from their glibc
> counterpart is not worth it.

We added it with strlcpy(3) in mind, but I agree with you that
it's not a critical reason, and we could live without it; in fact
I introduced a similar (and IMO superior) function, stpecpy(),
which could replace strlcpy(3) in all 6 calls.

But we didn't really add it for it; we already had the libbsd-dev
dependency before adding strlcpy(3).  libbsd-dev was added for
readpassphrase(3bsd), which has nothing similar in glibc, and I don't
want to be rewriting it in terms of glibc stuff, since it's not
trivial.

It was added in this patch set:

* 2a5b8810 - Mon, 21 Nov 2022 14:00:13 +0100 (4 months ago)
|   agetpass: Hook into build-system - Guillem Jover
* ab91ec10 - Wed, 28 Sep 2022 23:09:19 +0200 (5 months ago)
|   Hide [[gnu::malloc(deallocator)]] in a macro - Alejandro Colomar
* 554f86ba - Tue, 27 Sep 2022 21:21:35 +0200 (5 months ago)
|   Replace the deprecated getpass(3) by our agetpass() - Alejandro 
Colomar
* 155c9421 - Mon, 26 Sep 2022 22:22:24 +0200 (5 months ago)
|   libmisc: agetpass(), erase_pass(): Add functions for getting 
passwords safely - Alex Colomar
* 8cce4557 - Wed, 28 Sep 2022 00:03:46 +0200 (5 months ago)
|   Don't 'else' after a 'noreturn' call - Alex Colomar
* 99ce21a3 - Tue, 22 Nov 2022 14:35:06 +0100 (4 months ago)
|   CI: add libbsd and pkg-config dependencies - Iker Pedrosa


> 
> Freezero() also provides little extra benefit over memset() and free()
> and is used only 4 times in the code.

Use of freezero(3bsd) was added later to erase_pass() for one reason:
that API pair --agetpass(), erase_pass()-- already strongly depends on a
libbsd-dev function --readpassphrase(3bsd)--, so depending on two of them
doesn't add any issues.  Anyway, freezero(3) is easy to implement if we
had a need.



> There are reasons for strlcpy() not being provided by glibc [1]:
> 
> "Reactions among core glibc contributors on the topic of including
> strlcpy() and strlcat() have been varied over the years. Christoph
> Hellwig's early patch was rejected in the then-primary maintainer's
> inimitable style (1 and 2). But reactions from other glibc developers
> have been more nuanced, indicating, for example, some willingness to
> accept the functions. Perhaps most insightfully, Paul Eggert notes
> that even when these functions are provided (as an add-on packaged
> with the application), projects such as OpenSSH, where security is of
> paramount concern, still manage to either misuse the functions
> (silently truncating data) or use them unnecessarily (i.e., the
> traditional strcpy() and strcat() could equally have been used without
> harm); such a state of affairs does not constitute a strong argument
> for including the functions in glibc. "
> 
> I agree with their position and the 6 cases where strlcpy() is used in
> shadow's current master could be implemented with strncpy() as safely
> as with strlcpy().

I would strongly advise against that.  strncpy(3) doesn't produce
strings.

See the following manual pages:




My main concerns with strncpy(3) are:

-  It zeroes the rest of the buffer, which isn't bad per se, but
   then when reading code it's hard to tell if that was necessary
   or if it was just some inessential side effect of calling
   strncpy(3).  Which was exactly what happened when I did the
   migration from strncpy(3) to strlcpy(3): I had a hard time
   telling for sure at every call site if I could do it, or if
   I was doing something wrong by removing that zeroing.

-  It doesn't terminate the string, so you still need to manually
   

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Alejandro Colomar]

Hi Bálint,

On 3/8/23 13:11, Bálint Réczey wrote:
> Hi Serge,
> 
> Serge E. Hallyn  ezt írta (időpont: 2023. márc. 6., H, 
> 21:30):

[...]

>>
>> Hi Balint,
>>
>> right now shadow is not depending on either one.  Alex is adding
>> the pkgconf one.  This diff is between Alex's two diffs, showing
>> that his first diff had added pkg-config, while v2 is instead doing
>> pkgconf.
> 
> Yes, and I'd still depend on the more mature pkg-config variant if one
> variant is added until the archive-wide transition to pkgconf is
> completed.

Didn't the transition already happen?  I thought it had.  This is what
I see:


$ apt-cache show pkg-config
Package: pkg-config
Source: pkgconf
[...]
Depends: pkgconf (>= 1.8.0-7~)
Description-en: manage compile and link flags for libraries (transitional 
package)
 pkgconf is an implementation of the pkg-config system, which helps to configure
 compiler and linker flags for development frameworks.
 .
 pkgconf is a replacement for pkg-config, providing additional functionality
 while also maintaining compatibility.
 .
 This package only provides a dependency link to the pkgconf package to help
 with package upgrades. It can be safely removed.
[...]
Homepage: http://pkgconf.org/
[...]
Filename: pool/main/p/pkgconf/pkg-config_1.8.1-1_amd64.deb
[...]


(Some fields removed with [...] to keep it short and to the point.)


> 
> Cheers,
> Balint

Cheers,

Alex


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Alejandro Colomar]

On 3/8/23 13:59, Alejandro Colomar wrote:
> Hi Bálint,
> 
> On 3/8/23 13:11, Bálint Réczey wrote:
>> Hi Serge,
>>
>> Serge E. Hallyn  ezt írta (időpont: 2023. márc. 6., H, 
>> 21:30):
> 
> [...]
> 
>>>
>>> Hi Balint,
>>>
>>> right now shadow is not depending on either one.  Alex is adding
>>> the pkgconf one.  This diff is between Alex's two diffs, showing
>>> that his first diff had added pkg-config, while v2 is instead doing
>>> pkgconf.
>>
>> Yes, and I'd still depend on the more mature pkg-config variant if one
>> variant is added until the archive-wide transition to pkgconf is
>> completed.
> 
> Didn't the transition already happen?  I thought it had.  This is what
> I see:
> 
> 
> $ apt-cache show pkg-config
> Package: pkg-config
> Source: pkgconf
> [...]
> Depends: pkgconf (>= 1.8.0-7~)
> Description-en: manage compile and link flags for libraries (transitional 
> package)
>  pkgconf is an implementation of the pkg-config system, which helps to 
> configure
>  compiler and linker flags for development frameworks.
>  .
>  pkgconf is a replacement for pkg-config, providing additional functionality
>  while also maintaining compatibility.
>  .
>  This package only provides a dependency link to the pkgconf package to help
>  with package upgrades. It can be safely removed.
> [...]
> Homepage: http://pkgconf.org/
> [...]
> Filename: pool/main/p/pkgconf/pkg-config_1.8.1-1_amd64.deb
> [...]

In fact, pkg-config doesn't seem to provide anything useful by itself:

$ apt-file show pkg-config
pkg-config: /usr/share/doc/pkg-config/changelog.Debian.gz
pkg-config: /usr/share/doc/pkg-config/changelog.gz
pkg-config: /usr/share/doc/pkg-config/copyright
pkg-config: /usr/share/lintian/overrides/pkg-config

Everything it provides is through the dependency on pkgconf, it seems.

Cheers,

Alex

> 
> 
> (Some fields removed with [...] to keep it short and to the point.)
> 
> 
>>
>> Cheers,
>> Balint
> 
> Cheers,
> 
> Alex
> 
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Guilhem Moulin]

Control: clone -1 -2
Control: severity -2 important
Control: done -1 2:2.6.1-2

On Wed, 08 Mar 2023 at 13:42:53 +0100, Christoph Anton Mitterer wrote:
> @Guilhem, I'm reopening this for now.

No please don't, #-1 is RC so that would block transitioning into
Bookworm which only supports merged-usr…  Will fix that later during the
freeze, but ATM the priority is to get -2 into Bookworm ASAP, not
further delay the transition.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Christoph Anton Mitterer]

On Wed, 2023-03-08 at 14:04 +0100, Guilhem Moulin wrote:
> No please don't, #-1 is RC so that would block transitioning into
> Bookworm which only supports merged-usr…  Will fix that later during
> the
> freeze, but ATM the priority is to get -2 into Bookworm ASAP, not
> further delay the transition.

Well but at least right now people without merged /usr will still end
up in a broken system?

And there is no guarantee that /usr has already been merged at that
point... I mean it should, when the upgrade to bookwork completes...
but can it happen that it's interrupted? Or that people do it in
several steps? Then they could upgrade argon2, reboot and have the
missing libgcc.

Anyway... thanks for taking care :-)


Cheers,
Chris.

Bug#1032519: appstream: noisy warnings when running apt update with glib 2.75

[Jeremy Bícha]

Source: appstream
Version: 0.16.1-1
Control: affects -1 src:glib2.0

Test Case
-
Install glib2.0 2.75.4-1 from experimental
Then run sudo apt update

What Happens
---
The output has these warnings repeated several times:

(appstreamcli): GLib-GIO-CRITICAL **: GFileInfo created without
standard::is-hidden

(appstreamcli): GLib-GIO-CRITICAL **: file ../../../gio/gfileinfo.c:
line 1587 (g_file_info_get_is_hidden): should not be reached

Other Info
-
Debian's glib includes cherry-picks of the post-2.75.4 fixes through March 7
https://gitlab.gnome.org/GNOME/glib/-/commits/main

This test case also works on Ubuntu 23.04 (which is where I noticed
the issue first). It doesn't happen with glib 2.75.3.

Because my test case is Debian-specific, I am filing here but I assume
this is an upstream issue; don't know whether it's appstream or glib
that needs to be fixed.

Thank you,
Jeremy Bícha

Bug#1032520: ITP: libthreadar -- C++ classes for manipulating threads

[John Goerzen]

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

* Package name: libthreadar
  Version : 2.4.0
  Upstream Author : Denis Corbin
* URL : https://sourceforge.net/projects/libthreadar/
* License : LGPL v3+
  Programming Lang: C++
  Description : C++ classes for manipulating threads


 Libthreadar is a C++ library providing an abstracted set of C++ *classes* to
 manipulate threads in a very simple and efficient way from your C++ code.
 .
 It also handles exceptions thrown from a thread and propagated to another one,
 when the later is calling the thread::join() method. This let one manage
 exceptions as simply as it is in C++ single threaded context.
 .
 Additionally, all the related objects around multi-threading (mutex, semaphore,
 ...) are provided, under easy to use and independent C++ classes.  Other more
 advanced classes ease the information exchange between threads like scattering
 and gathering a collection of objects between many threads, or asynchonous
 buffered information exchanges between two threads.
 .
 libthreadar allows the dar package to provide multithreaded encryption,
 compression, and remote repository access.

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Guilhem Moulin]

On Wed, 08 Mar 2023 at 14:11:05 +0100, Christoph Anton Mitterer wrote:
> On Wed, 2023-03-08 at 14:04 +0100, Guilhem Moulin wrote:
>> No please don't, #-1 is RC so that would block transitioning into
>> Bookworm which only supports merged-usr…  Will fix that later during
>> the
>> freeze, but ATM the priority is to get -2 into Bookworm ASAP, not
>> further delay the transition.
>
> Well but at least right now people without merged /usr will still end
> up in a broken system?

Yes.  Been the case for a week (since the argon2=0~20190702-0.1 upload).
However the TC has ruled that these systems are no longer supported, so
the issue isn't RC.  Not saying we should shove it under the carpet,
only that it shouldn't delay transition.

> And there is no guarantee that /usr has already been merged at that
> point... I mean it should, when the upgrade to bookwork completes...
> but can it happen that it's interrupted? Or that people do it in
> several steps? Then they could upgrade argon2, reboot and have the
> missing libgcc.

Correct, but AFAICT that's would be a FrankenDebian so not something
supported either.  Either way that's not something src:cryptsetup can
fix.  One could upload src:argon2 again adding “Break: cryptsetup-initramfs
(<< 2:2.6.1-2)” to libargon2-1, though I'm not sure it's worth doing
given the freeze and the fact that covered that supported systems are
covered.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#592834: Bookworm - vgs invocation

[Rostás Attila]

Dear Maintainer,

I encountered the following message while did the latest patching of the
Debian 12 installation:

Setting up libndctl6:amd64 (76.1-1) ...
Setting up libxendevicemodel1:amd64 (4.17.0+46-gaaf74a532c-1) ...
Setting up mdadm (4.2-5) ...
update-initramfs: deferring update (trigger activated)
Generating grub configuration file ...
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093640: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093640: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093667: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093667: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093694: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093694: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093721: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093721: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093824: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2093824: /usr/sbin/grub-probe
Found linux image: /boot/vmlinuz-6.1.0-5-amd64
Found initrd image: /boot/initrd.img-6.1.0-5-amd64
Found linux image: /boot/vmlinuz-6.1.0-3-amd64
Found initrd image: /boot/initrd.img-6.1.0-3-amd64
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2094286: /usr/sbin/grub-probe
File descriptor 3 (pipe:[16075760]) leaked on vgs invocation. Parent PID
2094286: /usr/sbin/grub-probe
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults
Setting up libxenhypfs1:amd64 (4.17.0+46-gaaf74a532c-1) ...
Setting up python3-apt (2.5.3) ...
Setting up libxenmisc4.17:amd64 (4.17.0+46-gaaf74a532c-1) ...
Processing triggers for initramfs-tools (0.142) ...

/boot is not on lvm but on raid1 - ext4. The other parts of the filesystem
is lvm indeed.

The softwares:
~# dpkg -l grub*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---=
un  grub(no description
available)
un  grub-cloud-amd64(no description
available)
ii  grub-common   2.06-8   amd64GRand Unified
Bootloader (common files)
un  grub-coreboot   (no description
available)
un  grub-doc(no description
available)
un  grub-efi(no description
available)
ii  grub-efi-amd642.06-8   amd64GRand Unified
Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin2.06-8   amd64GRand Unified
Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed 1+2.06+8 amd64GRand Unified
Bootloader, version 2 (amd64 UEFI signed by Debian)
un  grub-efi-arm(no description
available)
un  grub-efi-arm64  (no description
available)
un  grub-efi-ia32   (no description
available)
un  grub-efi-ia64   (no description
available)
un  grub-emu(no description
available)
un  grub-ieee1275   (no description
available)
un  grub-legacy (no description
available)
un  grub-legacy-doc (no description
available)
un  grub-linuxbios  (no description
available)
un  grub-pc (no description
available)
un  grub-uboot  (no description
available)
un  grub-xen(no description
available)
un  grub-yeeloong   (no description
available)
un  grub2   (no description
available)
ii  grub2-common  2.06-8   amd64GRand Unified
Bootloader (common files for version 2)

:~# dpkg -l lvm*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  lvm2   2.03.16-2amd64

Bug#918075: Some patches for dar

[John Goerzen]

Hi László,

I had thought that I'd be able to get by without the delta-diff
features, but due to some changes over here, they would save me multiple
GBs per day.  So I am happy to dive in to work on dar.

I have submitted an ITP for libthreadar, which will allow multithreaded
compression/encryption as well as enable remote repository support.  I
have also uploaded a backport of librsync to bullseye-backports to
enable a future dar backport to bullseye with binary delta support.

The attached patch adds binary delta support, as well as cleaning up
some other things (documentation images and capability support depending
on what was installed in the build environment, for instance).  I was
also able to backport the result to bullseye.

Would you like me to take over maintaining dar?  Or would you like to
apply the patch (with appropriate changelog updates) and upload it?  Or
I could upload it and leave the maintainers line alone?

Thanks!

- John

diff --git a/debian/changelog b/debian/changelog
index f037041..2cb2738 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+dar (2.7.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support delta changes via librsync.
+  * Update dep on e2fslibs-dev to new name libext2fs-dev
+  * Add dep on libcap-dev to eneable proper capability handling.
+  * Add build-dependency on dot to ensure figures for docs are always
+built.
+
+ -- John Goerzen   Mon, 06 Mar 2023 18:19:22 -0600
+
 dar (2.7.8-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index 5698278..43bcb2c 100644
--- a/debian/control
+++ b/debian/control
@@ -3,9 +3,11 @@ Section: utils
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
 Build-Depends: debhelper-compat (= 13), pkg-config, zlib1g-dev, libbz2-dev,
- libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, e2fslibs-dev,
- libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev, doxygen, groff
-Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev, librsync-dev
+ libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, libext2fs-dev,
+ libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev,
+ librsync-dev, libcap-dev,
+ doxygen, groff, graphviz
+Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: http://dar.linux.free.fr/
diff --git a/debian/rules b/debian/rules
index de23882..0e60393 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@ DEB_CONFIGURE_EXTRA_FLAGS := --disable-upx --disable-python-binding \
 			 --enable-mode=64
 DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 
-BUILT_USING_PACKAGES = libc-dev-bin libattr1-dev libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev
+BUILT_USING_PACKAGES = libc-dev-bin libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev librsync-dev libext2fs-dev libcap-dev
 
 BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W $(BUILT_USING_PACKAGES))
 

Bug#1032521: myrepos: "unknown repository type" error registering git bare with packed refs

[Jacob Greenleaf]

Package: myrepos
Version: 1.20180726
Severity: normal

Dear Maintainer,

An error is returned when running "mr register" on a bare git
repository that has no refs/tags or refs/heads directory. 

$ git clone --bare --quiet https://github.com/beancount/beancount-mode.git
$ cd beancount-mode.git
$ rmdir refs/tags
$ mr register
mr register: unknown repository type

In my case my repositories are stored that way on disk, perhaps
because I'm using GitLab which seems to aggressively prefer
packed-refs [1] instead for example.

I checked the git reference documentation (gitrepository-layout [2],
etc.)  and was unable to find anything defining the directories under
refs/ as required instead of optional, but git seems to work fine with
an empty refs directory, lazily creating things under refs/ if they
are missing. However having a missing refs/ directory entirely is not
OK:

$ rm -rf refs
$ git log --oneline -1
fatal: not a git repository (or any of the parent directories): .git

A patch is attached that loosens the git_bare test (and vcsh) to not
require heads nor tags under refs, but instead simply require a refs
folder in addition to the other heuristics used for detecting a git
repository. 

This appears to have been added in
c20b454a225407e5c6b918cbb6e739b888b252ab when handling of git bare
repositories was separated out.

[1] https://git-scm.com/docs/git-pack-refs
[2] https://git-scm.com/docs/gitrepository-layout


*** 0001-Fix-detection-of-git-bare-repositories-with-no-tags-.patch
From: Jacob Greenleaf 
Origin: other
Date: Tue, 7 Mar 2023 19:35:41 -0800
Subject: [PATCH] Fix detection of git bare repositories with no tags or heads
 refs dirs

---
 mr | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mr b/mr
index 056e749..26d9300 100755
--- a/mr
+++ b/mr
@@ -2501,11 +2501,11 @@ hg_test  = perl: -d "$ENV{MR_REPO}/.hg"
 darcs_test = perl: -d "$ENV{MR_REPO}/_darcs"
 fossil_test = perl: -f "$ENV{MR_REPO}/_FOSSIL_" || -f "$ENV{MR_REPO}/.fslckout"
 git_bare_test = perl:
-   -d "$ENV{MR_REPO}/refs/heads" && -d "$ENV{MR_REPO}/refs/tags" &&
+   -d "$ENV{MR_REPO}/refs" &&
-d "$ENV{MR_REPO}/objects" && -f "$ENV{MR_REPO}/config" &&
`GIT_CONFIG="$ENV{MR_REPO}"/config git config --get core.bare` =~ /true/
 vcsh_test = perl:
-   -d "$ENV{MR_REPO}/refs/heads" && -d "$ENV{MR_REPO}/refs/tags" &&
+   -d "$ENV{MR_REPO}/refs" &&
-d "$ENV{MR_REPO}/objects" && -f "$ENV{MR_REPO}/config" &&
`GIT_CONFIG="$ENV{MR_REPO}"/config git config --get vcsh.vcsh` =~ /true/
 veracity_test  = perl: -d "$ENV{MR_REPO}/.sgdrawer"
-- 
2.30.2


-- System Information:
Debian Release: 11.6
  APT prefers bullseye
  APT policy: (500, 'bullseye')
Architecture: amd64 (x86_64)

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

Versions of packages myrepos depends on:
ii  perl  5.32.1-4+deb11u2

Versions of packages myrepos recommends:
ii  libfile-homedir-perl  1.006-1
ii  libhtml-parser-perl   3.75-1+b1
ii  libio-pty-easy-perl   0.10-1.1
ii  libwww-perl   6.52-1

Versions of packages myrepos suggests:
pn  ack | ack-grep
pn  bzr   
ii  curl  7.74.0-1.3+deb11u7
pn  cvs   
pn  darcs 
pn  dgit  
pn  fossil
ii  git [git-core]1:2.30.2-1+deb11u2
pn  git-annex 
pn  git-big-picture   
pn  git-svn   
pn  gitk | tig
pn  kdesdk-scripts
ii  liburi-perl   5.08-1
pn  mercurial 
pn  perl-doc  
pn  stow  
pn  subversion
pn  subversion-tools  
pn  unison
pn  vcsh  
ii  xdg-utils 1.1.3-4.1

-- no debconf information

Bug#1032450: unblock (pre-approval): gtk+3.0/3.24.37-2

[Simon McVittie]

On Wed, 08 Mar 2023 at 13:13:08 +0100, Sebastian Ramacher wrote:
> On 2023-03-07 01:12:58 +, Simon McVittie wrote:
> > gtk+3.0_3.24.37 is in experimental at the moment, and we'd like to
> > include it in bookworm if possible.
> 
> Are there any other stable releases planned for the 3.24.x series during
> the freeze?

We won't know until/unless they happen. GTK 3 is in maintenance mode and
has no fixed schedule: releases happen whenever upstream gets round to
making them.

As a result of regressions like the startup-notification thing that's
fixed in 3.24.37, the primary maintainer upstream has said that he's going
to be increasingly strict about what backports he'll allow into 3.x in
future, although it remains to be seen how that policy will turn out.

(I'd personally prefer it if new features like the file transfer portal
were done as a 3.25.x prerelease followed by a 3.26.x stable release,
the same way GTK 3 historically worked and GTK 4 still does, but upstream
has historically considered that to be too much release-management work
for the major versions that are in maintenance mode, so I think we're
unlikely to get that.)

smcv

Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.

[Cyril Brulebois]

Control: tag -1 fixed-upstream
Control: found -1 6.1.15-1

Hi Bjørn and Hank,

Bjørn Mork  (2022-09-13):
> Hank Barta  writes:
> 
> > ** Kernel log:
> > [  723.735217] mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
> > [  723.741743] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
> > [  723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
> > [  723.754797] mmc0: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
> > [  723.761324] mmc0: sdhci: Cmd:   0x0502 | Max curr: 0x00080008
> > [  723.767851] mmc0: sdhci: Resp[0]:   0x01aa | Resp[1]:  0x
> > [  723.774379] mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
> > [  723.780905] mmc0: sdhci: Host ctl2: 0x
> > [  723.785404] mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
> > [  723.791930] mmc0: sdhci: 
> > [  733.923993] mmc0: Timeout waiting for hardware cmd interrupt.
> 
> These repeated messages are normal on the RPi4 if you boot it without an
> SD card.

This is definitely a blocking issue for booting on both Pi 4 (SD card)
and CM4 (SD card or internal eMMC). That's also seen with v6.1.15
(annotating accordingly) and v6.2 (not annotating as we have no such
package in the archive at the moment). Thankfully that's gone in
v6.3-rc1.

You can find my analysis in:
  
https://lore.kernel.org/linux-arm-kernel/20230308144105.di552lbogqv2s...@mraw.org/

Hopefully we'll get that fixed via stable/6.1.y soon. I might propose a
patch series against the Debian package right away though, Raspberry Pi
users have suffered long enough from that regression…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf

[Emanuele Rocca]

Control: tags -1 + patch

On Fri, Mar 03, 2023 at 03:13:15PM +0100, Emanuele Rocca wrote:
> Firefox seems to erroneously enable NEON in places where it shouldn't. Trying
> to figure out exactly where and what's the best way to address this.

Patch attached.

According to the large disclaimer in moz.build one should not touch that file
but instead modify generate_mozbuild.py. It seems to me however that changes to
the python script are not automatically applied to moz.build?

In any case with the attached patch firefox-esr builds properly for armhf and
works fine here emulating a cortex-r5f CPU.

Thanks,
  ema
Index: firefox-esr-102.8.0esr/gfx/skia/moz.build
===
--- firefox-esr-102.8.0esr.orig/gfx/skia/moz.build
+++ firefox-esr-102.8.0esr/gfx/skia/moz.build
@@ -455,8 +455,6 @@ if CONFIG['INTEL_ARCHITECTURE']:
 SOURCES['skia/src/opts/SkOpts_sse42.cpp'].flags += ['-msse4.2']
 SOURCES['skia/src/opts/SkOpts_avx.cpp'].flags += ['-mavx']
 SOURCES['skia/src/opts/SkOpts_hsw.cpp'].flags += ['-mavx2', '-mf16c', '-mfma']
-elif CONFIG['CPU_ARCH'] == 'arm' and CONFIG['CC_TYPE'] in ('clang', 'gcc'):
-CXXFLAGS += CONFIG['NEON_FLAGS']
 elif CONFIG['CPU_ARCH'] == 'aarch64' and CONFIG['CC_TYPE'] in ('clang', 'gcc'):
 SOURCES['skia/src/opts/SkOpts_crc32.cpp'].flags += ['-march=armv8-a+crc']
 

Bug#1032168: meson: autopkgtest fills disk completely

[Jussi Pakkanen]

On Wed, 1 Mar 2023 at 21:09, Paul Gevers  wrote:

> No, but e.g. on s390x it never ever came close to filling the disk, so
> the peaks of before today here are really new:
> https://ci.debian.net/munin/ci-worker-s390x-01/ci-worker-s390x-01/df.html
> (but apparently another package is also suddenly misbehaving, so maybe
> it's indeed something *below* meson. I'll try to figure out tonight or
> tomorrow morning.

Did you manage to discover whether that is the same issue or something
different?

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Bálint Réczey]

Hi Alejandro,

Alejandro Colomar  ezt írta (időpont: 2023.
márc. 8., Sze, 13:59):
>
> Hi Bálint,
>
> On 3/8/23 13:11, Bálint Réczey wrote:
> > Hi Serge,
> >
> > Serge E. Hallyn  ezt írta (időpont: 2023. márc. 6., H, 
> > 21:30):
>
> [...]
>
> >>
> >> Hi Balint,
> >>
> >> right now shadow is not depending on either one.  Alex is adding
> >> the pkgconf one.  This diff is between Alex's two diffs, showing
> >> that his first diff had added pkg-config, while v2 is instead doing
> >> pkgconf.
> >
> > Yes, and I'd still depend on the more mature pkg-config variant if one
> > variant is added until the archive-wide transition to pkgconf is
> > completed.
>
> Didn't the transition already happen?  I thought it had.  This is what
> I see:
>
>
> $ apt-cache show pkg-config
> Package: pkg-config
> Source: pkgconf
> [...]
> Depends: pkgconf (>= 1.8.0-7~)
> Description-en: manage compile and link flags for libraries (transitional 
> package)
>  pkgconf is an implementation of the pkg-config system, which helps to 
> configure
>  compiler and linker flags for development frameworks.
>  .
>  pkgconf is a replacement for pkg-config, providing additional functionality
>  while also maintaining compatibility.
>  .
>  This package only provides a dependency link to the pkgconf package to help
>  with package upgrades. It can be safely removed.
> [...]
> Homepage: http://pkgconf.org/
> [...]
> Filename: pool/main/p/pkgconf/pkg-config_1.8.1-1_amd64.deb
> [...]

Oh, it already happened. I mistakenly checked that in my system's
changelog, not in unstable's.
Then I'd prefer the pkgconfig build dependency, too.

Thanks,
Balint

Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start

[Paride Legovini]

Benedikt Spranger wrote on 08/03/2023:
> Package: kea-dhcp4-server
> Version: 2.2.0-5
> Severity: important
> X-Debbugs-Cc: none, Benedikt Spranger 
> 
> Dear maintainer,
> 
> after an update kea-dhcp4 refuses to start due to an apparmor
> missconfiguration. To track down the problem I started the server
> manualy. No luck. Same error(s) - Therefore further step backs.
> Here to reproduce the problem:
> 
> 1) Install kea-dhcp4-server
> 2) Start the server manualy:
> 
> # kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
> Unable to use interprocess sync lockfile (Permission denied): 
> /var/run/kea/logger_lockfile

This is expected: in Debian the lockfile path is defined in the systemd
service files, like this:

Environment="KEA_LOCKFILE_DIR=/run/lock/kea"

which is different from the default /var/run/kea/, which got used in
your manual attempt.

The issue you're seeing is likely not with the lockfile. Running:

# KEA_LOCKFILE_DIR=/run/lock/kea kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

may show the actual issue, but I suggest using e.g.

journalctl -u kea-dhcp4-server.service

Please do follow up to this bug if you figure out something more about
this issue: if there's a bug in the apparmor profile we want to fix is
sooner than later.

Thanks!

Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.

[Diederik de Haas]

On Wednesday, 8 March 2023 15:49:03 CET Cyril Brulebois wrote:
> This is definitely a blocking issue for booting on both Pi 4 (SD card)
> and CM4 (SD card or internal eMMC). That's also seen with v6.1.15
> (annotating accordingly) and v6.2 (not annotating as we have no such
> package in the archive at the moment). Thankfully that's gone in
> v6.3-rc1.
> 
> You can find my analysis in:
>  
> https://lore.kernel.org/linux-arm-kernel/20230308144105.di552lbogqv2s7fk@mr
> aw.org/
> 
> Hopefully we'll get that fixed via stable/6.1.y soon. I might propose a
> patch series against the Debian package right away though, Raspberry Pi
> users have suffered long enough from that regression…

The relevant patches are queued up for 6.1.16:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/
commit/queue-6.1?id=a5ed16fdb1a2a3a9b50c3da79abcfe9366b2c47a

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

Bug#1032517: nginx settings deleted on upgrade

[Piotr Jurkiewicz]

I can confirm this bug. Happened to me twice yesterday. The problem 
occurs also when pruning is being done after system upgrade, in a 
separate step.

Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t

[Faidon Liambotis]

On Wed, Mar 08, 2023 at 09:08:13AM +0100, Sylvestre Ledru wrote:
> > Specifically, it looks like the entire patching of the method
> > WebAssembly::AddClangCXXStdlibIncludeArgs isn't happening anymore. One
> > of these differences was exactly about this -- the comment says:
> >// don't include the host architecture's headers in the search path
> > 
> > Sylvestre, I think you did the 14->15 porting, right? Do you
> > know/remember what happened there?
> 
> Maybe i did a mistake in the merge?!

Upstream commit b5787a0 ("Support -stdlib=libstdc++ for WebAssembly")
reorganized the code a bit, which resulted in a merge conflict. It also
included half of what my patch did, namely the getDriver().SysRoot to
computeSysRoot() conversion, which probably resulted in you thinking
that this hunk isn't necessary anymore!

I'm attaching a diff that restores the second half of the diff, and I
believe should fix this bug. (LLVM is a pain to build and test, so I
haven't tested this at all yet; hoping that it's easier for Sylvestre to
test!). I'm also attaching the interdiff in case it helps anyone to
review.

I'm not submitting an MR because I noticed that "15" branch has
progressed further compared to 1-15.0.7-1, and I'm not sure how you'd
like to handle it; basically whether these changes are suitable for
bookworm at this point, or whether you'd like to to fork a branch for
bookworm.

Side-note unrelated to this bug, but confused me during its
investigation:
  # this is a badly named duplicate of debian/1%15.0.7-1
  git tag -d debian/1%15.0.71; git push origin :debian/1%15.0.71
  # cruft left behind from the move to debian/patches/wasm/
  git checkout 15; git rm debian/patches/wasm-*; git commit -m "Remove cruft"
  git checkout snapshot; git rm debian/patches/wasm-*; git commit -m "Remove 
cruft"

HTH!
Faidon
--- a/debian/patches/wasm/wasm-sysroot-usr.diff
+++ b/debian/patches/wasm/wasm-sysroot-usr.diff
@@ -57,6 +59,33 @@
  void WebAssembly::addLibCxxIncludePaths(
  const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const {
+@@ -499,7 +519,9 @@ void WebAssembly::addLibCxxIncludePaths(
+   }
+ 
+   // Second add the generic one.
+-  addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
++  // don't include the host architecture's headers in the search path
++  if (!getDriver().SysRoot.empty())
++addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
+ }
+ 
+ void WebAssembly::addLibStdCXXIncludePaths(
+@@ -546,8 +568,11 @@ void WebAssembly::addLibStdCXXIncludePat
+ addSystemInclude(DriverArgs, CC1Args, TargetDir);
+   }
+ 
+-  // Second add the generic one.
+-  addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
+-  // Third the backward one.
+-  addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version + "/backward");
++  // don't include the host architecture's headers in the search path
++  if (!getDriver().SysRoot.empty()) {
++// Second add the generic one.
++addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
++// Third the backward one.
++addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version + "/backward");
++  }
+ }
 --- a/clang/lib/Driver/ToolChains/WebAssembly.h
 +++ b/clang/lib/Driver/ToolChains/WebAssembly.h
 @@ -89,6 +89,8 @@ private:
diff -u b/clang/lib/Driver/ToolChains/WebAssembly.cpp b/clang/lib/Driver/ToolChains/WebAssembly.cpp
--- b/clang/lib/Driver/ToolChains/WebAssembly.cpp
+++ b/clang/lib/Driver/ToolChains/WebAssembly.cpp
@@ -519,7 +519,9 @@
   }
 
   // Second add the generic one.
-  addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
+  // don't include the host architecture's headers in the search path
+  if (!getDriver().SysRoot.empty())
+addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
 }
 
 void WebAssembly::addLibStdCXXIncludePaths(
@@ -568,6 +570,9 @@
 
-  // Second add the generic one.
-  addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
-  // Third the backward one.
-  addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version + "/backward");
+  // don't include the host architecture's headers in the search path
+  if (!getDriver().SysRoot.empty()) {
+// Second add the generic one.
+addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
+// Third the backward one.
+addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version + "/backward");
+  }
 }

Bug#1029010: llvm-toolchain-15: autopkgtest regression

[Faidon Liambotis]

On Wed, Mar 08, 2023 at 09:41:21AM +, Simon McVittie wrote:
> > there is a metapackage, libc++-dev-wasm32, which Depends on the
> > default implementation, which is libc++-14-dev-wasm32 right now. That
> > metapackage has at least one notable reverse B-D, firefox, using it to
> > build certain security/sandboxing features (RLBox[1], AIUI). That is to
> > say, this feature works (w/ 14) and does very useful things today. it
> > (seemingly) broke when it was ported to llvm-toolchain-15, which
> > src:firefox does not depend on directly.
> 
> If I understand correctly, that doesn't *necessarily* have to be RC for
> bookworm, because llvm-toolchain-15 is not (yet!) the default version
> of LLVM provided by the metapackage, and is only used by Mesa? But it
> would be a blocker for either moving the default forward from 14 to 15
> (as has already been done in experimental), or making Firefox use the
> non-default 15 toolchain like Mesa does, presumably to get some new
> feature or optimization that isn't in 14?

At least as I also understand it, that's right. 

I think it'd be a pity to revert this for 15 and we should aim for
feature parity between the two branches, but disabling it is, and can
remain an option as a plan B given where we are in the bookworm release
cycle. That's IMHO, with a biased view, as the wasm patches author, but
ultimately up to the maintainer (which is definitely not me ;).

I'm hopeful we can address the underlying issue quickly though, and I
propose to put a hold to this conversation for the time being and see
where we get with a proper resolution first. I just posted a patch in
the other bug report. Fingers crossed.

Faidon

Bug#986821: freecad: Garbled menu makes freecad unusable

[Werner Mayer]

Hi everybody,

I have tested it on my XFCE system to decrease the DPI value to e.g. 80
and then I can confirm that FreeCAD's menus and toolbars are unusable.
Looking through the code I found this line

QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);

After commenting it out the problem is gone.

The line once has been added with
https://github.com/FreeCAD/FreeCAD/pull/4605 and is supposed to fix a
scaling problem on Windows.

As a proper fix I suggest to enable this line for Windows only:

#if QT_VERSION >= QT_VERSION_CHECK(5,14,0) && defined(Q_OS_WIN)
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);
#endif



Btw, FreeCAD built with Qt6 doesn't seem to suffer from this problem.

I hope this helps.

BR,
Werner

Bug#1023566: libharfbuzz0b: undefined symbol: FT_Get_Transform - impossible to install matlab

[Drew Parsons]

Package: libharfbuzz0b
Version: 6.0.0+dfsg-3
Followup-For: Bug #1023566

Running their binary executable directly:

$ ./bin/glnxa64/MATLABWindow 
./bin/glnxa64/MATLABWindow: symbol lookup error: 
/usr/lib/x86_64-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Get_Transform

libharfbuzz.so.0 declares it needs libfreetype.so.6

The problem is that Matlab provides its own copy of libfreetype.so.6
(libfreetype.so.6.16.0).  Removing that allows the matlab installer to
proceed.

But also that just brings Matlab closer to its next problem.  Now it's
not accepting keyboard input to type in the email address to start the
install process.

This whole fiasco provides just a little more affirmation that I'm
doing the right thing teaching students python + numpy/scipy
instead of Matlab.

Bug#1032522: emacs-gtk: Pausing at an open quote causes emacs to freeze when editing Python

[Hans-Christoph Steiner]

Package: emacs-gtk
Version: 1:28.2+1-10
Severity: important

Dear Maintainer,

   * What led up to the situation?

I've been editing Python in emacs for over a decade.  I'm working on
fdroidserver right now, an old Python code base.

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

While editing Python code, if I pause after typing an open quote, like
' or """, then emacs will totally freeze and has to be killed.  The
window won't draw updates if I resize it.  Specifically, this has to
be typed in a class function, for example, typing at this point:
https://gitlab.com/fdroid/fdroidserver/-/blob/ae2b33dab38f7e76fc6ca5245c8e3fa44224802f/tests/index.TestCase#L68

And adding:

foo = '

will cause it to crash every time.

   * What was the outcome of this action?

emacs is frozen, and it is pegging the one CPU.

   * What outcome did you expect instead?

It should just let me type code!


It seems to be related to:
https://www.reddit.com/r/emacs/comments/z0oye9/emacs_freezes_when_opening_a_python_file/


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

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 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 emacs depends on:
ii  emacs-gtk  1:28.2+1-10

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1023566: libharfbuzz0b: undefined symbol: FT_Get_Transform - impossible to install matlab

[Drew Parsons]

Package: libharfbuzz0b
Version: 6.0.0+dfsg-3
Followup-For: Bug #1023566

For the record, it started accepting keyboard input after I left the
directly and reentered to try again ;/  I now have a working version
of Matlab on my debian system (after removing their libfreetype.so.6)

I meant to add, all this means that libharfbuzz0b is not responsible
for the matlab problems.  This is not a libharfbuzz0b bug
(can be helpful nevertheless to keep this bug here to help others
who are experiencing the same problem, and direct them to use
numpy/scipy instead)

Bug#1032379: bug#746: Killed when starting modale dialog like pinentry

[Timo Aaltonen]

Mark Hindley kirjoitti 8.3.2023 klo 12.33:

On Wed, Mar 08, 2023 at 11:26:37AM +0100, Klaus Ethgen wrote:

Maybe you can add this information to #1032379 and reassign?


I can prove it. If I revert the last update of libx11-6, libx11-data and
libx11-xcb1, everything works correct again.


Good work! Thanks.

Mark



please file this upstream and mention that it's a regression in 1.8.4

https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues

--
t

Bug#1022126: New mainline kernel is out fixes for example 1022126 bug

[Salvatore Bonaccorso]

Hi Marc,

On Sat, Mar 04, 2023 at 12:09:15PM +0100, Marc-Robin Wendt wrote:
> Its actually not my game, but if it speeds things up, I will help
> testing (if anyone tells me, what to do).

Thank you. Can you try with the following series of 4 patches.

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2

will describe how to pass a series of patches to apply for testing.

Thanks already in advance,

Regards,
Salvatore
>From 37904556ea6f04f48c3ca9419edf8155aa1e1899 Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Wed, 8 Mar 2023 17:14:56 +0100
Subject: [PATCH 1/4] Revert "scsi: mpt3sas: Fix return value check of
 dma_get_required_mask()"

This reverts commit e0e0747de0ea3dd87cdbb0393311e17471a9baf1.

As noted in 1a2dcbdde82e ("scsi: mpt3sas: re-do lost mpt3sas DMA mask
fix") in mainline there was a mis-merge in commit 62e6e5940c0c ("Merge
tag 'scsi-misc' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi"). causing that
the fix needed to be redone later on again. To make series of patches
apply cleanly to the stable series where e0e0747de0ea ("scsi: mpt3sas:
Fix return value check of dma_get_required_mask()") was backported,
revert the afferomentioned commit.

No upstream commit exists for this commit.

Link: https://lore.kernel.org/regressions/yq1sfehmjnb@ca-mkp.ca.oracle.com/
Signed-off-by: Salvatore Bonaccorso 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c
index c1b76cda60db..18f85c963944 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2825,7 +2825,7 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev)
 
 	if (ioc->is_mcpu_endpoint ||
 	sizeof(dma_addr_t) == 4 || ioc->use_32bit_dma ||
-	dma_get_required_mask(&pdev->dev) <= DMA_BIT_MASK(32))
+	dma_get_required_mask(&pdev->dev) <= 32)
 		ioc->dma_mask = 32;
 	/* Set 63 bit DMA mask for all SAS3 and SAS35 controllers */
 	else if (ioc->hba_mpi_version_belonged > MPI2_VERSION)
-- 
2.39.2

>From 8ad037f24e7a9c46105065e81503968b7bdc14b1 Mon Sep 17 00:00:00 2001
From: Sreekanth Reddy 
Date: Thu, 25 Aug 2022 13:24:54 +0530
Subject: [PATCH 2/4] scsi: mpt3sas: Don't change DMA mask while reallocating
 pools

commit 9df650963bf6d6c2c3fcd325d8c44ca2b99554fe upstream.

When a pool crosses the 4GB boundary region then before reallocating pools
change the coherent DMA mask to 32 bits and keep the normal DMA mask set to
63/64 bits.

Link: https://lore.kernel.org/r/20220825075457.16422-2-sreekanth.re...@broadcom.com
Signed-off-by: Sreekanth Reddy 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Salvatore Bonaccorso 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 18f85c963944..faea8001adf5 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2822,19 +2822,26 @@ static int
 _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev)
 {
 	struct sysinfo s;
+	u64 coherent_dma_mask, dma_mask;
 
-	if (ioc->is_mcpu_endpoint ||
-	sizeof(dma_addr_t) == 4 || ioc->use_32bit_dma ||
-	dma_get_required_mask(&pdev->dev) <= 32)
+	if (ioc->is_mcpu_endpoint || sizeof(dma_addr_t) == 4 ||
+	dma_get_required_mask(&pdev->dev) <= 32) {
 		ioc->dma_mask = 32;
+		coherent_dma_mask = dma_mask = DMA_BIT_MASK(32);
 	/* Set 63 bit DMA mask for all SAS3 and SAS35 controllers */
-	else if (ioc->hba_mpi_version_belonged > MPI2_VERSION)
+	} else if (ioc->hba_mpi_version_belonged > MPI2_VERSION) {
 		ioc->dma_mask = 63;
-	else
+		coherent_dma_mask = dma_mask = DMA_BIT_MASK(63);
+	} else {
 		ioc->dma_mask = 64;
+		coherent_dma_mask = dma_mask = DMA_BIT_MASK(64);
+	}
+
+	if (ioc->use_32bit_dma)
+		coherent_dma_mask = DMA_BIT_MASK(32);
 
-	if (dma_set_mask(&pdev->dev, DMA_BIT_MASK(ioc->dma_mask)) ||
-	dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(ioc->dma_mask)))
+	if (dma_set_mask(&pdev->dev, dma_mask) ||
+	dma_set_coherent_mask(&pdev->dev, coherent_dma_mask))
 		return -ENODEV;
 
 	if (ioc->dma_mask > 32) {
-- 
2.39.2

>From ecd75f575db8537651bd6ee4edaaf0f508951a8c Mon Sep 17 00:00:00 2001
From: Sreekanth Reddy 
Date: Tue, 13 Sep 2022 17:35:38 +0530
Subject: [PATCH 3/4] scsi: mpt3sas: re-do lost mpt3sas DMA mask fix

commit 1a2dcbdde82e3a5f1db9b2f4c48aa1aeba534fb2 upstream.

This is a re-do of commit e0e0747de0ea ("scsi: mpt3sas: Fix return value
check of dma_get_required_mask()"), which I ended up undoing in a
mis-merge in commit 62e6e5940c0c ("Merge tag 'scsi-misc' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi").

The original commit message was

  scsi: mpt3sas: Fix return value check of dma_get_required_mask()

  Fix the incorrect return value check of dma_get_required_mas

Bug#1032379: bug#746: Killed when starting modale dialog like pinentry

[Klaus Ethgen]

Am Mi den  8. Mär 2023 um 17:37 schrieb Timo Aaltonen:
> Mark Hindley kirjoitti 8.3.2023 klo 12.33:
> > On Wed, Mar 08, 2023 at 11:26:37AM +0100, Klaus Ethgen wrote:
> > > > Maybe you can add this information to #1032379 and reassign?
> > > 
> > > I can prove it. If I revert the last update of libx11-6, libx11-data and
> > > libx11-xcb1, everything works correct again.
> > 
> > Good work! Thanks.
> > 
> > Mark
> > 
> 
> please file this upstream and mention that it's a regression in 1.8.4
> 
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues

I would like too but I have no account there and without it seems that I
cannot see any issue.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1028713: Forwarded upstream (Was: salmon call causing pigx-rnaseq to infinitely loop)

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/COMBINE-lab/salmon/issues/835

Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t

[Simon McVittie]

On Wed, 08 Mar 2023 at 17:46:11 +0200, Faidon Liambotis wrote:
> I'm not submitting an MR because I noticed that "15" branch has
> progressed further compared to 1-15.0.7-1, and I'm not sure how you'd
> like to handle it; basically whether these changes are suitable for
> bookworm at this point, or whether you'd like to to fork a branch for
> bookworm.

See also #1032316 which is exactly about whether 1%15.0.7-1 is intended
for bookworm or not: the reason I started looking at this is that
1%15.0.7-1 not migrating is holding back fixes in src:mesa, at least
one of which is RC.

smcv

Bug#1032523: fdutils: setfdprm parameters not retained with -p

[Larry Kraemer]

Package: fdutils
Version: 5.6-2
Severity: normal
X-Debbugs-Cc: ldkrae...@gmail.com

Dear Maintainer,
In Debian 8 I have a SS DD 180K Floppy attached ad /dev/fd0.  I execute the 
following commands to format a TRS180 floppy, and it formats correctly.

larry@Debian811:~$ lsmod | grep floppy
floppy 56090  0

larry@Debian811:~$ ls -alt /dev/fd0
brw-rw 1 root disk 2, 0 Mar  8 00:20 /dev/fd0

larry@Debian811:~$ groups larry
larry : larry cdrom floppy sudo audio dip video plugdev netdev bluetooth 
lpadmin scanner

larry@Debian811:~$ sudo ls -alt /media
total 16
drwxr-xr-x   4 root root   4096 Mar  6 14:50 .
drwxrw   2 root floppy 4096 Mar  6 14:50 floppy
drwxr-xr-x  18 root root   4096 Mar  6 14:46 ..
drwxr-x---+  2 root root   4096 Mar  6 14:45 larry

larry@Debian811:~$ sudo gedit /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
#  
UUID=5cc7486c-e24e-4327-aba3-50560ee92b58 /  ext4
defaults,noatime 0 1
UUID=99e769fc-7dea-4ae5-a063-1d400d134319 swap   swap
defaults,noatime 0 0

/dev/fd0/media/floppy   auto rw,user,noauto 0   0

larry@Debian811:~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0  2:014K  0 disk 
sda  8:00 37.3G  0 disk 
\u251c\u2500sda1   8:102G  0 part 
\u251c\u2500sda2   8:20 29.4G  0 part /
\u2514\u2500sda3   8:30  5.9G  0 part [SWAP]
sdb  8:16   1 28.7G  0 disk 
\u2514\u2500sdb1   8:17   1 28.7G  0 part 
sr0 11:01 1024M  0 rom  

larry@Debian811:~$ sudo setfdprm -p /dev/fd0 TRS180

larry@Debian811:~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0  2:01  180K  0 disk 
sda  8:00 37.3G  0 disk 
\u251c\u2500sda1   8:102G  0 part 
\u251c\u2500sda2   8:20 29.4G  0 part /
\u2514\u2500sda3   8:30  5.9G  0 part [SWAP]
sdb  8:16   1 28.7G  0 disk 
\u2514\u2500sdb1   8:17   1 28.7G  0 part 
sr0 11:01 1024M  0 rom  

larry@Debian811:~$ sudo getfdprm /dev/fd0
SS DD sect=18 ssize=256 

larry@Debian811:~$ sudo superformat /dev/fd0 TRS180
 Verifying cylinder 39, head 0 
mformat -s9 -t40 -h1 -S1 -M512  a:

When I change to a TEAC 360K DS/DD Floppy Drive, Debian says it is not a valid 
Block Device.


But, in Debian 11 nothing works with the same hardware and the same commands.
I just change my Hard Drive to the latest version of Bullseye (Ver 11).


larry@Debian11:~$ lsmod | grep floppy
floppy 90112  0

larry@Debian11:~$ ls -alt /dev/fd0
brw-rw 1 root disk 2, 0 Mar  8 00:20 /dev/fd0

larry@Debian11:~$ groups larry
larry : larry cdrom floppy sudo audio dip video plugdev netdev bluetooth 
lpadmin scanner

larry@Debian11:~$ sudo ls -alt /media
total 16
drwxr-xr-x   4 root root 4096 Mar  6 14:50 .
drwxrwx---   2 root root 4096 Mar  6 14:50 floppy
drwxr-xr-x  18 root root 4096 Mar  6 14:46 ..
drwxr-x---+  2 root root 4096 Mar  6 14:45 larry

larry@Debian11:~$ sudo gedit /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
#  
UUID=5cc7486c-e24e-4327-aba3-50560ee92b58 /  ext4
defaults,noatime 0 1
UUID=99e769fc-7dea-4ae5-a063-1d400d134319 swap   swap
defaults,noatime 0 0

/dev/fd0/media/floppy   auto rw,user,noauto 0   0

larry@Debian11:~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0  2:014K  0 disk 
sda  8:00 37.3G  0 disk 
\u251c\u2500sda1   8:102G  0 part 
\u251c\u2500sda2   8:20 29.4G  0 part /
\u2514\u2500sda3   8:30  5.9G  0 part [SWAP]
sdb  8:16   1 28.7G  0 disk 
\u2514\u2500sdb1   8:17   1 28.7G  0 part 
sr0 11:01 1024M  0 rom  

larry@Debian11:~$ sudo setfdprm -p /dev/fd0 TRS180

larry@Debian11:~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0  2:01  180K  0 disk 
sda  8:00 37.3G  0 disk 
\u251c\u2500sda1   8:102G  0 part 
\u251c\u2500sda2   8:20 29.4G  0 part /
\u2514\u2500sda3   8:30  5.9G  0 part [SWAP]
sdb  8:16   1 28.7G  0 disk 
\u2514\u2500sdb1   8:17   1 28.7G  0 part 
sr0 11:01 1024M  0 rom  

larry@Debian11:~$ sudo getfdprm /dev/fd0
SS DD sect=18 ssize=256 


larry@Debian11:~$ sudo superformat /dev/fd0 TRS180
Measuring drive 0's raw capacity
format: Operation not supported

larry@Debian11:~$ sudo getfdprm /dev/fd0
SS DD sect=18 ssize=256 

larry@Debian11:~$ ls -alt /dev/fd0
brw-rw 1 root disk 2, 0 Mar  8 00:20 /dev/fd0

If I install a TEAC DS/DD 360K Floppy Drive, I get an error message stating 
"Not a valid Block Device.  I do have an ICON on my desktop, but i can not 
mount the DS/DD 360K Floppy Drive, 

Bug#1032316: llvm-toolchain-15: is this version intended for Debian 12 'bookworm'?

[Simon McVittie]

On Mon, 06 Mar 2023 at 21:35:41 +0100, Étienne Mollier wrote:
> Simon McVittie, on 2023-03-03:
> > llvm-toolchain-15/1:15.0.7-1 was uploaded several weeks ago, shortly
> > after the transition freeze, but has not migrated to testing due to an
> > autopkgtest regression (#1029010).
> 
> I subscribe the debian-ai mailing list.  The ROCm compiler is
> currently built on top of llvm-toolchain-15, and moving back to
> the llvm-toolchain-14 may require some non-trivial effort if the
> latter were to not target Debian 12 bookworm.

There is *a* version of llvm-toolchain-15 in bookworm, version 1:15.0.6-4,
which is used by the rocm-hipamd_5.2.3-1 and mesa_22.3.3-1 in bookworm.
I'm not suggesting that 1:15.0.6-4 should be *removed*. What I'm asking
here is whether it's intended to be upgraded to 1:15.0.7-1 (or presumably
a later version where #1029010 has been fixed), or kept at 1:15.0.6-4.

It looks as though rocm-hipamd and mesa are in a very similar situation,
actually: each one has a newer version in unstable which fixes a RC bug
currently present in bookworm (#1021643 in rocm-hipamd, #1029731 in mesa)
but cannot migrate because it's blocked by llvm-toolchain-15_1:15.0.7-1
not migrating.

smcv

Bug#1032524: ITP: golang-github-gitleaks-go-gitdiff -- Go library for parsing and applying patches created by Git

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-gitleaks-go-gitdiff
  Version : 0.8.0-1
  Upstream Author : Gitleaks
* URL : https://github.com/gitleaks/go-gitdiff
* License : Expat
  Programming Lang: Go
  Description : Go library for parsing and applying patches created by Git

 go-gitdiff is a Go library for parsing and applying patches generated by
 git diff, git show, and git format-patch.  It can also parse and apply
 unified diffs generated by the standard diff tool.
 .
 It supports standard line-oriented text patches and Git binary patches,
 and aims to parse anything accepted by the git apply command.

Reason for packaging: A dependency of gitleaks

Bug#1032523: fdutils: mydebian8

[Larry Kraemer]

Package: fdutils
Version: 5.5-20060227-7
Followup-For: Bug #1032523

Dear Maintainer,

Here is the information on my Debian 8 system:

Floppy Drive is now a TEAC DS/DD 360K floppy:

larry@Debian8-386:~$ sudo setfdprm -p /dev/fd0 360/360
[sudo] password for larry:
 
larry@Debian8-386:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
fd0  2:01   360K  0 disk 
sda  8:00 465.8G  0 disk 
\u251c\u2500sda1   8:10 117.2G  0 part /
\u251c\u2500sda2   8:20  24.4G  0 part 
\u251c\u2500sda3   8:30 321.7G  0 part 
\u2514\u2500sda4   8:40   2.5G  0 part [SWAP]
sdb  8:16   1  28.7G  0 disk 
\u2514\u2500sdb1   8:17   1  28.7G  0 part 
sr0 11:01  1024M  0 rom  

larry@Debian8-386:~$ sudo getfdprm /dev/fd0
get geometry parameters: No such device


Floppy Drive is now a TEAC DS/DD 360K floppy:

larry@Debian8-386:~$ sudo setfdprm -p /dev/fd0 TRS180
larry@Debian8-386:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
fd0  2:01   180K  0 disk 
sda  8:00 465.8G  0 disk 
\u251c\u2500sda1   8:10 117.2G  0 part /
\u251c\u2500sda2   8:20  24.4G  0 part 
\u251c\u2500sda3   8:30 321.7G  0 part 
\u2514\u2500sda4   8:40   2.5G  0 part [SWAP]
sdb  8:16   1  28.7G  0 disk 
\u2514\u2500sdb1   8:17   1  28.7G  0 part 
sr0 11:01  1024M  0 rom  
larry@Debian8-386:~$ sudo getfdprm /dev/fd0
get geometry parameters: No such device


larry@Debian8-386:~$ sudo setfdprm -p /dev/fd0 360/360

larry@Debian8-386:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
fd0  2:01   360K  0 disk 
sda  8:00 465.8G  0 disk 
\u251c\u2500sda1   8:10 117.2G  0 part /
\u251c\u2500sda2   8:20  24.4G  0 part 
\u251c\u2500sda3   8:30 321.7G  0 part 
\u2514\u2500sda4   8:40   2.5G  0 part [SWAP]
sdb  8:16   1  28.7G  0 disk 
\u2514\u2500sdb1   8:17   1  28.7G  0 part 
sr0 11:01  1024M  0 rom  

larry@Debian8-386:~$ sudo mount -t msdos /dev/fd0 /media/floppy/
mount: /dev/fd0 is not a valid block device

larry@Debian8-386:~$ ls -alt /dev/fd0
brw-rw 1 root disk 2, 0 Mar  8 03:26 /dev/fd0

larry@Debian8-386:~$ ls -alt /media
total 20
drwxr-x---+  2 root root   4096 Mar  8 01:22 larry
drwxr-xr-x  22 root root   4096 Oct 31  2020 ..
drwxr-xr-x   5 root root   4096 Dec 24  2018 .
drwxrw   2 root floppy 4096 Dec 20  2018 floppy
drwxr-xr-x   2 root root   4096 Dec  9  2016 cdrom0
lrwxrwxrwx   1 root root  6 Dec  9  2016 cdrom -> cdrom0

This Computer (Desktop) also has a Floppy on the Desktop, but nothing
will mount it.  Not by clicking on the Icon or trying to mount the 
floppy via a terminal.


I've searched the Internet and found lot of postings on "Not a Valid
Block Device", but nothing that gives a hint of a FIX.



-- System Information:
Debian Release: 8.11
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-11-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fdutils depends on:
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  debianutils4.4+b1
ii  dpkg   1.17.27
ii  install-info   5.2.0.dfsg.1-6
ii  libc6  2.19-18+deb8u10

Versions of packages fdutils recommends:
ii  mtools  4.0.18-2

fdutils suggests no packages.

-- Configuration Files:
/etc/mediaprm changed:
"360/360":
 DS DD sect=9
"1200/1200":
 DS HD sect=15
"360/720":
 SS DD sect=9
"720/720":
 DS DD sect=9
"360/1200":
 DS DD sect=9
"720/1200":
 DS QD sect=9
"1440/1440":
 DS HD sect=18
"2880/2880":
 DS ED sect=36
"2880/2880":
 DS ED sect=36
"2880/2880":
 DS ED sect=36
"1440/1200":
 DS HD sect=18
"1680/1440":
 DS HD sect=21
"410/1200":
 DS DD sect=10 cyl=41
"820/1440":
 DS DD sect=10 cyl=82
"1476/1200":
 DS HD sect=18 cyl=82
"1722/1440":
 DS HD sect=21 cyl=82
"420/1200":
 DS DD sect=10 cyl=42
"830/1440":
 DS DD sect=10 cyl=83
"1494/1200":
 DS HD sect=18 cyl=83
"1743/1440":
 DS HD sect=21 cyl=83
"1743/1440":
 DS HD sect=21 cyl=83
"880/1200":
 DS QD tracksize=11b ssize=1KB
"1040/720":
 DS QD sect=13
"1120/720":
 DS QD tracksize=7KB mss
"1600/1200":
 DS HD tracksize=10KB mss
"1760/1440":
 DS HD sect=11 ssize=1KB
"1920/1440":
 DS HD tracksize=12KB mss
"3200/2880":
 DS ED sect=5 ssize=4KB
"3520/2880":
 DS ED tracksize=22KB ssize=4KB
"3840/2880":
 DS ED sect=3 ssize=8KB
"3840/2880":
 DS ED sect=3 ssize=8KB
"1840/1440":
 DS HD tracksize=23b ssize=2KB
"800/720":
 DS DD sect=10
"1600/1440":
 DS HD sect=20
"KAY16":
 DS DD sect=9 cyl=40 tpi=48 ssize=512
"GEN250":
 SS DD sect=24 dtr=0 fm=1 cyl=77 ssize=128
"ABC160":
 SS DD sect=16 ssize=256
"ACT180":
 SS DD sect=9
"ADL160":
 SS DD sect=16 ssize=256
"ADV160":
 SS DD sect=4 ssize=1KB
"ADV640":
 DS QD sect=4 ssize=1KB
"ALT720":
 DS QD sect=9
"AMI200":
 SS DD sect=10
"AMP200":
 SS DD sect=10
"AMP400":
 SS QD sect=5 ssize=1KB
"AMS720":
 DS QD sect=9
"ARC400":

Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t

[Sylvestre Ledru]

Le 08/03/2023 à 18:13, Simon McVittie a écrit :

On Wed, 08 Mar 2023 at 17:46:11 +0200, Faidon Liambotis wrote:

I'm not submitting an MR because I noticed that "15" branch has
progressed further compared to 1-15.0.7-1, and I'm not sure how you'd
like to handle it; basically whether these changes are suitable for
bookworm at this point, or whether you'd like to to fork a branch for
bookworm.

See also #1032316 which is exactly about whether 1%15.0.7-1 is intended
for bookworm or not: the reason I started looking at this is that
1%15.0.7-1 not migrating is holding back fixes in src:mesa, at least
one of which is RC.


yeah, it is intended for bookworm

sorry if i didn't state it clearly earlier.

Faidon, would you like to push your fixes directly in the repo?

Thanks again

S

Bug#1032525: packer: crashes on a very simple template

[Santiago Vila]

Package: packer
Version: 1.6.6+ds1-7
Severity: grave

Hello.

I'm using packer and ansible to create images for GCP.

After upgrading to Debian bookworm, packer crashes on
the most simple template:

$ packer build sample.pkr.hcl
panic: ConfigSpec failed: gob: type cty.Type has no exported fields [recovered]
panic: ConfigSpec failed: gob: type cty.Type has no exported fields

goroutine 1 [running]:
log.Panic({0xc00083e8e8?, 0x0?, 0x0?})
log/log.go:388 +0x65
github.com/hashicorp/packer/packer/plugin.(*cmdBuilder).checkExit(0xc0005e0490?,
 {0x314b860, 0xc0005e04c0}, 0x0)
github.com/hashicorp/packer/packer/plugin/builder.go:47 +0x7f
github.com/hashicorp/packer/packer/plugin.(*cmdBuilder).ConfigSpec.func1()
github.com/hashicorp/packer/packer/plugin/builder.go:19 +0x39
panic({0x314b860, 0xc0005e04c0})
runtime/panic.go:884 +0x212
github.com/hashicorp/packer/packer-plugin-sdk/rpc.(*commonClient).ConfigSpec(0xc00068e9e0)
github.com/hashicorp/packer/packer-plugin-sdk/rpc/common.go:44 +0x297
github.com/hashicorp/packer/packer/plugin.(*cmdBuilder).ConfigSpec(0xc00047f0d0?)
github.com/hashicorp/packer/packer/plugin/builder.go:22 +0x65
github.com/hashicorp/packer/hcl2template.decodeHCL2Spec({0x4447708, 
0xc000483650}, 0xd?, {0x7fc2746a1680?, 0xc0004728a0?})
github.com/hashicorp/packer/hcl2template/decode.go:17 +0x39
github.com/hashicorp/packer/hcl2template.(*PackerConfig).startBuilder(0x3379060?,
 {{0xc000792540, 0xd}, {0xc000792570, 0xa}, 0xc0004cd1e0, {0x0, 0x0}, {0x0, 
0x0}}, ...)
github.com/hashicorp/packer/hcl2template/types.source.go:110 +0x16a
github.com/hashicorp/packer/hcl2template.(*PackerConfig).GetBuilds(0xc00077f320,
 {{0x0, 0x0, 0x0}, {0x0, 0x0, 0x0}, 0x0, 0x0, {0x0, ...}})
github.com/hashicorp/packer/hcl2template/types.packer_config.go:396 
+0xb48
github.com/hashicorp/packer/command.(*BuildCommand).RunContext(0xc53920, 
{0x4447120?, 0xcaa540}, 0xc000782120)
github.com/hashicorp/packer/command/build.go:156 +0x1b5
github.com/hashicorp/packer/command.(*BuildCommand).Run(0xc53920, 
{0xc000112170, 0x1, 0x1})
github.com/hashicorp/packer/command/build.go:40 +0xc5
github.com/mitchellh/cli.(*CLI).Run(0xc000748640)
github.com/mitchellh/cli/cli.go:261 +0x5f8
main.wrappedMain()
github.com/hashicorp/packer/main.go:249 +0xb11
main.realMain()
github.com/hashicorp/packer/main.go:50 +0xf5
main.main()
github.com/hashicorp/packer/main.go:36 +0x19



!!! PACKER CRASH 

Packer crashed! This is always indicative of a bug within Packer.
A crash log has been placed at "crash.log" relative to your current
working directory. It would be immensely helpful if you could please
report the crash with Packer[1] so that we can fix this.

[1]: https://github.com/hashicorp/packer/issues

!!! PACKER CRASH 

This is the template I'm using:

-
locals { timestamp = regex_replace(timestamp(), "[- TZ:]", "") }

source "googlecompute" "buildd-gce" {
  account_file= "my-account-file.json"
  image_family= "debian-12-buildd"
  image_name  = "debian-12-buildd-amd64-${local.timestamp}"
  machine_type= "n1-standard-1"
  disk_size   = 10
  project_id  = "my-project-id"
  source_image_family = "debian-11"
  ssh_username= "packer"
  tags= ["ssh"]
  zone= "us-central1-f"
}

build {
  sources = ["source.googlecompute.buildd-gce"]

  provisioner "ansible" {
extra_arguments = ["--become"]
groups  = ["buildd"]
playbook_file   = "playbooks/buildd-gce.yml"
  }

}
-

I'm also attaching the crash.log file.


For completeness: Version 1.8.6 from github does not crash, but it has
two subtle incompatibilities with openssh-client in bookworm:

https://github.com/hashicorp/packer-plugin-ansible/issues/140
https://github.com/hashicorp/packer/issues/11783

I was going to report those issues here for documentation purposes,
as both of them have workarounds. but then I found the Debian
version seems not to work at all.

Thanks.2023/03/08 18:30:02 [INFO] Packer version: 1.6.6 [go1.19.6 linux amd64]
2023/03/08 18:30:02 Checking 'PACKER_CONFIG' for a config file path
2023/03/08 18:30:02 'PACKER_CONFIG' not set; checking the default config file path
2023/03/08 18:30:02 Attempting to open config file: /home/bluser/.packerconfig
2023/03/08 18:30:02 [WARN] Config file doesn't exist: /home/bluser/.packerconfig
2023/03/08 18:30:02 Setting cache directory: /home/bluser/packer_cache
2023/03/08 18:30:02 [TRACE] validateValue: not active for timestamp, so skipping
2023/03/08 18:30:02 [TRACE] validateValue: not active for timestamp, so skipping
2023/03/08 18:30:02 [TRACE] validateValue: not active for timestamp, so

Bug#1032517:

[Jan Mojzis]

Hello,
can You please send me the steps how i can reproduce it
- packages list/versions before the upgrade
- exact apt/apt-get command
- packages list/versions after the upgrade

Jan

Bug#1031489: temporary fix

[Alexander Procenko]

qt software uses
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0×7f0e27e0)
pastebin.com/raw/qNyjpFsv
but load
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libGL.so.1
and gives Segmentation Fault
if add this
export QT_XCB_GL_INTEGRATION=none
export QT_OPENGL=software
and starting trough
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so qbittorrent
software starting without error

Bug#1032526: [pre-approval] unblock: dar/2.7.8-2

[GCS]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: jgoer...@complete.org
Control: affects -1 + src:dar

Hi RMs,

Please pre-approve a feature enabled version of dar.

[ Reason ]
John Goerzen updated build dependencies to reflect the libext2fs-dev
rename, added delta changes support with rsync (previously I've not
enabled it as it didn't have the static library to use with
dar-static) and use Linux capabilities support.

[ Impact ]
Users will get a more feature rich version of dar.

[ Tests ]
The delta changes testing done by John, I did only build and basic testing.

[ Risks ]
I don't know any. No code change, only enable features that are
present in the source code already.

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

Thanks for consideration,
Laszlo/GCS
diff -Nru dar-2.7.8/debian/changelog dar-2.7.8/debian/changelog
--- dar-2.7.8/debian/changelog	2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/changelog	2023-03-08 18:14:41.0 +0100
@@ -1,3 +1,17 @@
+dar (2.7.8-2) unstable; urgency=medium
+
+  [ John Goerzen ]
+  * Support delta changes via librsync.
+  * Update dep on e2fslibs-dev to new name libext2fs-dev
+  * Add dep on libcap-dev to eneable proper capability handling.
+  * Add build-dependency on dot to ensure figures for docs are always
+built.
+
+  [ Laszlo Boszormenyi (GCS) ]
+  * Build depend on libcap-dev only on Linux architectures.
+
+ -- Laszlo Boszormenyi (GCS)   Wed, 08 Mar 2023 18:14:41 +0100
+
 dar (2.7.8-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru dar-2.7.8/debian/control dar-2.7.8/debian/control
--- dar-2.7.8/debian/control	2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/control	2023-03-08 18:14:41.0 +0100
@@ -3,9 +3,11 @@
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
 Build-Depends: debhelper-compat (= 13), pkg-config, zlib1g-dev, libbz2-dev,
- libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, e2fslibs-dev,
- libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev, doxygen, groff
-Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev, librsync-dev
+ libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, libext2fs-dev,
+ libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev,
+ librsync-dev, libcap-dev [linux-any],
+ doxygen, groff, graphviz
+Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: http://dar.linux.free.fr/
diff -Nru dar-2.7.8/debian/rules dar-2.7.8/debian/rules
--- dar-2.7.8/debian/rules	2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/rules	2023-03-08 18:14:41.0 +0100
@@ -4,13 +4,18 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 DEB_CONFIGURE_EXTRA_FLAGS := --disable-upx --disable-python-binding \
 			 --enable-mode=64
 DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 
-BUILT_USING_PACKAGES = libc-dev-bin libattr1-dev libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev
+BUILT_USING_PACKAGES = libc-dev-bin libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev librsync-dev libext2fs-dev
+ifeq ($(DEB_HOST_ARCH_OS), linux)
+BUILT_USING_PACKAGES += libcap-dev
+endif
 
 BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W $(BUILT_USING_PACKAGES))
 

Bug#918075: Some patches for dar

[GCS]

Hi John,

On Wed, Mar 8, 2023 at 2:47 PM John Goerzen  wrote:
> I had thought that I'd be able to get by without the delta-diff
> features, but due to some changes over here, they would save me multiple
> GBs per day.  So I am happy to dive in to work on dar.
 Sounds good.

> I have submitted an ITP for libthreadar, which will allow multithreaded
> compression/encryption as well as enable remote repository support.  I
> have also uploaded a backport of librsync to bullseye-backports to
> enable a future dar backport to bullseye with binary delta support.
 Where can I check the libthreadar packaging?

> Would you like me to take over maintaining dar?  Or would you like to
> apply the patch (with appropriate changelog updates) and upload it?  Or
> I could upload it and leave the maintainers line alone?
 It's a release freeze for Bookworm. I'm asking for approval and will
do it once it is allowed.
I am open to giving the package to you during the Trixie release cycle.

Regards,
Laszlo/GCS

Bug#1031964: libtrilinos-{globi,opti}pack-{13.2,dev} are empty

[Graham Inggs]

Hi

Sorry for missing this.  I noticed the empty packages (or at least,
Lintian did!) while sponsoring the upload of 13.4.1-1 to experimental
and fixed it there, but didn't think it important enough to fix for
bookworm.

If someone is willing to do a (team) upload, I'll be happy to unblock it.

Please consider this a release team unblock pre-approval.

Regards
Graham

Bug#1032527: ITP: golang-github-bep-lazycache -- Thread-safe in-memory LRU cache with non-blocking cache priming on cache misses (Go library)

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-bep-lazycache
  Version : 0.2.0-1
  Upstream Author : Bjørn Erik Pedersen
* URL : https://github.com/bep/lazycache
* License : Expat
  Programming Lang: Go
  Description : Thread-safe in-memory LRU cache with non-blocking cache 
priming on cache misses (Go library)

 Lazycache is a simple thread safe in-memory LRU cache.  Under the hood
 it leverages the great simpleru package in golang-lru, with its exellent
 performance.  One big difference between golang-lru and this library is
 the GetOrCreate method, which provides:
 .
  * Non-blocking cache priming on cache misses.
  * A guarantee that the prime function is only called once for a given key.
  * The cache's RWMutex is not locked during the execution of the prime
function, which should make it easier to reason about potential deadlocks.
 .
 Other notable features:
 .
  * The API is generic
  * The cache can be resized while running.
  * When the number of entries overflows the defined cache size, the
least recently used item gets discarded (LRU).


Reason for packaging: Needed by hugo (>= 0.111.0)

Bug#1030669: Only include in Bookworm with commitment to stable updates

[Moritz Muehlenhoff]

On Wed, Mar 08, 2023 at 02:20:25PM +0100, Marco d'Itri wrote:
0;115;0c> On Feb 14, Moritz Muehlenhoff  wrote:
> 
> > > > Varnish should only be included in Bookworm with a reliable commitment
> > > > by the maintainers to backport/test security fixes across the typical
> > > > three year life cycle (two years of stable-security and one year of
> > > > oldstable-security).
> > > I do not think that this will be helpful for Varnish users.
> > Then someone needs to step up, it's as easy as that.
> Fine: "I hereby commit to backport/test security fixes for varnish 
> across the lifetime of bookworm".

Noted, thanks.

Cheers,
Moritz

Bug#1032476: apache2: CVE-2023-25690 CVE-2023-27522

[Moritz Muehlenhoff]

On Wed, Mar 08, 2023 at 07:09:20AM +0400, Yadd wrote:
> On 3/7/23 23:46, Salvatore Bonaccorso wrote:
> > Source: apache2
> > Version: 2.4.55-1
> > Severity: grave
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerabilities were published for apache2.
> > 
> > CVE-2023-25690[0]:
> > 
> > CVE-2023-27522[1]:
> 
> Hi,
> 
> here is the debdiff for Bullseye

I'm fine with a DSA, but we've seen a fair amount of regressions in 2.4.x 
releases,
so let's wait a few days for regressions reported in sid (and Ondreys PHP repo).

You can already upload the new version, though (we can reject/reupload if 
needed).

Cheers,
Moritz

Bug#1032486: goverlay: Please add libglu1-mesa as a runtime dependency.

[Safir Secerovic]

Dear Stephan,

Thank You so much for your prompt response.
Without libglu1-mesa installed, I get following error message upon launch:

sapphire@perun:~$ DRI_PRIME=1 QT_QPA_PLATFORM=xcb mangohud --dlsym goverlay
[2023-03-08 12:41:38.583] [MANGOHUD] [info] [config.cpp:118] skipping
config: '/usr/libexec/MangoHud.conf' [ not found ]
[2023-03-08 12:41:38.583] [MANGOHUD] [info] [config.cpp:118] skipping
config: '/home/sapphire/.config/MangoHud/goverlay.conf' [ not found ]
[2023-03-08 12:41:38.583] [MANGOHUD] [info] [config.cpp:123] parsing
config: '/home/sapphire/.config/MangoHud/MangoHud.conf'
[2023-03-08 12:41:38.661] [MANGOHUD] [info] [overlay.cpp:768] Uploading is
disabled (permit_upload = 0)
[2023-03-08 12:41:38.672] [MANGOHUD] [info] [gl_renderer.cpp:414] GL
version: 4.6
[FORMS.PP] ExceptionOccurred
  Sender=Exception
  Exception=Could not load library: libGLU.so.1
  Stack trace:
  $005F720B
Exception at 005F720B: Exception:
Could not load library: libGLU.so.1.


On Wed, Mar 8, 2023 at 3:17 AM Stephan Lachnit 
wrote:

> Hi Safir,
>
> can you provide more details why libglu1-mesa is required by GOverlay?
> I don't see any hints for it upstream.
>
> Regards,
> Stephan
>

Bug#1032528: installation-reports: Raspberry Pi 3 Model B Plus in EFI mode - debian-bookworm-DI-alpha2-arm64-netinst.iso

[Emanuele Rocca]

Package: installation-reports

Boot method: USB stick
Image version: 
https://cdimage.debian.org/cdimage/bookworm_di_alpha2/arm64/iso-cd/debian-bookworm-DI-alpha2-arm64-netinst.iso
Date: 2023-03-08

Machine: Raspberry Pi 3 Model B Plus Rev 1.3
Processor: ARM Cortex-A53
Memory: 1G
Partitions:
  Filesystem Type 1K-blocksUsed Available Use% Mounted on
  udev   devtmpfs395476   0395476   0% /dev
  tmpfs  tmpfs91436 500 90936   1% /run
  /dev/mmcblk0p5 ext4  30196596 1749452  26887900   7% /
  tmpfs  tmpfs   457172   0457172   0% /dev/shm
  tmpfs  tmpfs 5120   0  5120   0% /run/lock
  /dev/mmcblk0p1 vfat307016   21048285968   7% /boot/efi
  tmpfs  tmpfs91432   0 91432   0% /run/user/1000

Output of lspci -knn (or lspci -nn):
  n/a

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O*]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[]

Comments/Problems:

I have tested the Bookworm Alpha 2 installer on a RPi 3B+ in EFI mode. To do
so, I first had to add the UEFI Firmware for Raspberry Pi 3 to the SD card onto
which I planned to install Debian. The firmware images are available here:
https://github.com/pftf/RPi3/releases

On another Linux system I created a msdos (not GPT) partition table on the SD
card with fdisk:

$ sudo fdisk /dev/sdf

Created a new partition with 'n', specified it should be primary with 'p',
assigned it number '1', First sector '2048', Last sector '+300m'. Changed the
partition type with 't', specified hex code 'e' for "W95 FAT16 (LBA)", made it
bootable with 'a', saved with 'w'.

Then I created a FAT16 filesystem on the partition with:

$ sudo mkfs.vfat -F 16 /dev/sdf1

Mounted /dev/sdf1, unzipped RPi3_UEFI_Firmware_v1.38.zip onto it.

At this point, the RPi3 was able to boot regular vanilla d-i images from a USB
stick. I used debian-bookworm-DI-alpha2-arm64-netinst.iso.

- Both wifi and wired ethernet were found, though for some reason the wired
  interface did not always manage to get configured via DHCP. I tried a few
  times, and when wired ethernet did not work, the wifi interface did. It seemed
  hit-or-miss.
  
  The installer also detected that some non-free firmware was required by the
  brcm module, but I don't think this is the reason for the issue, which I
  suspect would have otherwise been always reproducible?

- The raspi-firmware package did not get installed, and I think it should
  probably have?

- To ensure that Guided partitioning would not automatically change the
  partition table to GPT, but leave it as msdos, I have manually created a root
  partition. I haven't tested whether this was actually necessary though.

- Rebooting into the freshly installed system unfortunately did not work. This
  is because bootaa64.efi (and indeed the whole /boot/efi/EFI/boot directory)
  was missing. I could fix this by booting the installer again in Rescue Mode 
and
  choosing "Force GRUB installation to the EFI removable media path", which
  added /boot/efi/EFI/BOOT with:

ema@raspi:~$ sudo ls -l /boot/efi/EFI/BOOT
total 5160
-rwx-- 1 root root  856064 Mar  8  2023 BOOTAA64.EFI
-rwx-- 1 root root   91520 Mar  8  2023 fbaa64.efi
-rwx-- 1 root root 4322752 Mar  8  2023 grubaa64.efi

- depthcharge-tools-installer was very keen in letting me know that I do not
  have a ChromeOS board. The message "depthcharge-tools-installer: Not
  installing to non-ChromeOS board." was repeated a total of 21 times.

ema@raspi:~$ sudo grep -c "non-ChromeOS board" /var/log/installer/syslog
21

  Mentioning that once, if at all, would probably be enough. :-)

So all in all the only truly serious problem was the fact that grub had to be
installed to the EFI removable media path. I briefly discussed this with Sledge
on irc and he mentioned that it would be good to have a list of platforms
requiring such workaround, so that we can apply it when needed.

Please find the contents of /var/log/installer/ attached.


installer.tar.gz
Description: application/gzip

Bug#1032168: meson: autopkgtest fills disk completely

[Paul Gevers]

Hi Jussi,

On 08-03-2023 16:13, Jussi Pakkanen wrote:

On Wed, 1 Mar 2023 at 21:09, Paul Gevers  wrote:


No, but e.g. on s390x it never ever came close to filling the disk, so
the peaks of before today here are really new:
https://ci.debian.net/munin/ci-worker-s390x-01/ci-worker-s390x-01/df.html
(but apparently another package is also suddenly misbehaving, so maybe
it's indeed something *below* meson. I'll try to figure out tonight or
tomorrow morning.


Did you manage to discover whether that is the same issue or something
different?


Yes, sorry for not following up. meson was still getting scheduled on 
s390x because the worker prefetched tests from the queue before I 
disallowed meson. So it was meson all the time.


Having said that, let me open the discussion on what I expect from this 
bug. I *don't* expect all tests on our infrastructure to be totally 
resilient to all restrictions we have. Although several tens of GB is a 
lot, I also realize that it isn't *that* much, so if you understand why 
meson suddenly needs considerably more disk space and that's to be 
expected, then I'm fine with closing this bug and have meson on the 
rejectlist for architecture where we don't have enough (or you implement 
restrictions in your test of course). What this bug tries to prevent is 
*accidental* increased requirements that point out a flaw somewhere.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032388: closed by Debian FTP Masters (reply to Simon McVittie ) (Bug#1032388: fixed in mutter 43.3-5)

[Todor Tsankov]

On 07/03/2023 12:21, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:mutter package:
> 
> #1032388: gnome-shell: fails to switch keyboard layout from topbar menu
> 

The bug is still present for me with mutter 43.3-5 from unstable.

--Todor

Bug#1032529: RM: rust-crossbeam-utils-0.7 -- RoQA; Obsolete, open security issue

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-crossbeam-utils-...@packages.debian.org
Control: affects -1 + src:rust-crossbeam-utils-0.7

Please remove rust-crossbeam-utils-0.7. It's an older version of
src: rust-crossbeam-utils, affected by CVE-2022-23639 and there are
no remaining reverse dependencies.

Cheers,
Moritz

Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start

[bene]

> Please do follow up to this bug if you figure out something more about
> this issue: if there's a bug in the apparmor profile we want to fix is
> sooner than later.

OK. Do it again:

1)  Purge kea-dhcp4-server from the system to ensure a clean install
# apt-get purge kea-dhcp4-server

2) Ensure ther is no apparmor profile left:
# ls -l /etc/apparmor.d/
insgesamt 88
drwxr-xr-x 2 root root   95 15. Feb 08:03 abi
drwxr-xr-x 4 root root 4096 27. Feb 07:51 abstractions
drwxr-xr-x 2 root root6 18. Mär 2018  force-complain
drwxr-xr-x 2 root root 4096 27. Feb 07:51 libvirt
drwxr-xr-x 3 root root 4096  8. Mär 19:40 local
-rw-r--r-- 1 root root 1379 14. Feb 12:49 lsb_release
-rw-r--r-- 1 root root 1189  3. Sep 2021  nvidia_modprobe
drwxr-xr-x 2 root root6 26. Feb 2019  samba
-rw-r--r-- 1 root root 3461  9. Jan 09:25 sbin.dhclient
drwxr-xr-x 5 root root  266 15. Feb 08:03 tunables
-rw-r--r-- 1 root root 3448  5. Jul 2020  usr.bin.man
-rw-r--r-- 1 root root 2255 11. Nov 2020  usr.lib.ipsec.charon
-rw-r--r-- 1 root root  872 11. Nov 2020  usr.lib.ipsec.stroke
-rw-r--r-- 1 root root 1871 19. Aug 2021  usr.lib.libvirt.virt-aa-helper
-rw-r--r-- 1 root root 2628  1. Feb 2022  usr.sbin.chronyd
-rw-r--r-- 1 root root  761  5. Feb 00:25 usr.sbin.cups-browsed
-rw-r--r-- 1 root root 6027  6. Sep 2021  usr.sbin.cupsd
-rw-r--r-- 1 root root  621 25. Nov 2020  usr.sbin.haveged
-rw-r--r-- 1 root root  744 17. Feb 19:20 usr.sbin.kea-dhcp-ddns
-rw-r--r-- 1 root root  855 17. Feb 19:20 usr.sbin.kea-lfc
-rw-r--r-- 1 root root 4732 28. Jan 17:03 usr.sbin.libvirtd
-rw-r--r-- 1 root root  730 15. Okt 2020  usr.sbin.mariadbd
-rw-r--r-- 1 root root 2654 26. Jan 21:13 usr.sbin.named
-rw-r--r-- 1 root root 1196 11. Nov 2020  usr.sbin.swanctl

# aa-status
apparmor module is loaded.
25 profiles are loaded.
25 profiles are in enforce mode.
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/ipsec/charon
   /usr/lib/ipsec/stroke
   /usr/sbin/chronyd
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/haveged
   /usr/sbin/swanctl
   /{,usr/}sbin/dhclient
   kea-dhcp-ddns
   kea-lfc
   libvirtd
   libvirtd//qemu_bridge_helper
   lsb_release
   man_filter
   man_groff
   named
   nvidia_modprobe
   nvidia_modprobe//kmod
   virt-aa-helper
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
7 processes have profiles defined.
2 processes are in enforce mode.
   /usr/sbin/cupsd (6782)
   /usr/lib/cups/notifier/dbus (6785) /usr/sbin/cupsd
0 processes are in complain mode.
5 processes are unconfined but have a profile defined.
   /usr/lib/ipsec/charon (1820)
   /usr/sbin/chronyd (2268)
   /usr/sbin/chronyd (2317)
   /usr/sbin/cups-browsed (2199)
   /usr/sbin/haveged (1858)
0 processes are in mixed mode.
0 processes are in kill mode.

3) install kea-dhcp4-server
# apt-get install kea-dhcp4-server

4) Start manually:
# KEA_LOCKFILE_DIR=/run/lock/kea kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
2023-03-08 19:43:47.887 INFO  [kea-dhcp4.dhcp4/7774.139648314530240] 
DHCP4_STARTING Kea DHCPv4 server version 2.2.0 (stable) starting
2023-03-08 19:43:47.888 WARN  [kea-dhcp4.dhcp4/7774.139648314530240] 
DHCP4_CONFIG_SYNTAX_WARNING configuration syntax warning: 
/etc/kea/kea-dhcp4.conf:436.39: Extraneous comma. A piece of configuration may 
have been omitted.
INFO  HOSTS_BACKENDS_REGISTERED the following host backend types are available: 
mysql postgresql
INFO  DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , 
using default socket type raw
INFO  DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 
192.0.2.0/24 with params: t1=900, t2=1800, valid-lifetime=3600
INFO  COMMAND_ACCEPTOR_START Starting to accept connections via unix domain 
socket bound to /run/kea/kea4-ctrl-socket
INFO  DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: added 
IPv4 subnets: 1; DDNS: disabled
INFO  DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600 
type=memfile universe=4
INFO  DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file 
/var/lib/kea/kea-leases4.csv
2023-03-08 19:43:47.891 ERROR [kea-dhcp4.dhcp4/7774.139648314530240] 
DHCP4_CONFIG_LOAD_FAIL configuration error using file: /etc/kea/kea-dhcp4.conf, 
reason: Unable to open database: unable to open '/var/lib/kea/kea-leases4.csv'
2023-03-08 19:43:47.891 ERROR [kea-dhcp4.dhcp4/7774.139648314530240] 
DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file 
'/etc/kea/kea-dhcp4.conf': Unable to open database: unable to open 
'/var/lib/kea/kea-leases4.csv'

QED: Same apparmor error I could not fix...

# ls /etc/apparmor.d/usr.sbin.kea-dhcp4*
/etc/apparmor.d/usr.sbin.kea-dhcp4

The content of /etc/apparmor.d/usr.sbin.kea-dhcp4:
--- 8< ---
abi ,

include 

profile kea-dhcp4 /usr/sbin/kea-dhcp4 {
  include 

  

Bug#1032530: debootstrap: Unable to debootstrap Ubuntu 22.04 (jammy)

[Ian Chilton]

Package: debootstrap
Version: 1.0.114+deb10u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Attempting to debootstrap ubuntu 22.04 (jammy).

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

Running:
debootstrap --arch amd64 jammy /tmp/jammy http://archive.ubuntu.com/ubuntu

   * What was the outcome of this action?

I: Validating zlib1g 1:1.2.11.dfsg-2ubuntu9
I: Chosen extractor for .deb packages: dpkg-deb
I: Extracting base-files...
E: Tried to extract package, but file already exists. Exit...

   * What outcome did you expect instead?

It should have succeeded.

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


-- System Information:
Debian Release: 10.13
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-22-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii  wget  1.20.1-1.1

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2019.1+deb10u1
ii  gnupg   2.2.12-1+deb10u2

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#1032450: unblock: gtk+3.0/3.24.37-2

[Simon McVittie]

Control: retitle -1 unblock: gtk+3.0/3.24.37-2

On Wed, 08 Mar 2023 at 13:13:08 +0100, Sebastian Ramacher wrote:
> On 2023-03-07 01:12:58 +, Simon McVittie wrote:
> > Resync with upstream release. What we have in bookworm at the moment
> > is GTK 3.24.36 and something like half of 3.24.37; rebasing on 3.24.37
> > seems a better basis for a stable release.
> 
> Agreed. Please go ahead.

Uploaded. There is a slight difference wrt the diff you saw: I added
two translation updates from upstream, and one bug fix for interop with
non-GTK users of the file transfer portal.

gtk+3.0_3.24.37-2-since-prerelease-no-l10n.diff is the diff since the
version you approved, filtered to exclude debian/patches/*.patch and
po/*.po (so you only see the actual code change).

gtk+3.0_3.24.37-2-since-prerelease.diff.gz is the diff since the
version you approved, filtered to exclude debian/patches/*.patch only.

gtk+3.0_3.24.37-2.diff.gz is the full diff since testing.

> > [The file transfer portal code] does have one
> > potential interop issue (using a non-standard MIME type) which I've
> > reported upstream. I hope fixing that should be a simple change
> > (< 10 lines).

I included the upstream fix for this in 3.24.37-2, putting it in the same
situation as gtk4: for maximum compatibility, both the correct MIME type
and the typo'd MIME type are accepted and treated as equivalent.
Successfully tested by dragging a file from evince (GTK 3, on host system)
to gtk4-demo (Flatpak).

> > autopkgtest reports one apparent regression for gnome-photos, but I think
> > it might be spurious (the test getting stuck). I'll try to investigate it
> > if it turns out to be reproducible.

It was not reproducible when retried (2/2 successes since the failure)
so I'm going to ignore this unless the problem recurs.

smcv
diff --git a/debian/changelog b/debian/changelog
index d115481e26..d40e38239b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,10 +1,15 @@
-gtk+3.0 (3.24.37-2) UNRELEASED; urgency=medium
+gtk+3.0 (3.24.37-2) unstable; urgency=medium
 
+  * d/p/selection-Use-the-right-mime-type.patch:
+Add patch to fix incorrect MIME type for file transfer portal.
+Regression in 3.24.37, affecting interoperability with other
+implementations like the one requested in QTBUG-91357.
+  * d/patches: Update translations from upstream git: gl, he
   * d/copyright: Remove gtk-text-input.xml.
 This file is no longer present in the source package.
   * Remove Lintian overrides for lintian/lintian!452, no longer necessary
 
- -- Simon McVittie   Tue, 07 Mar 2023 00:07:09 +
+ -- Simon McVittie   Wed, 08 Mar 2023 14:52:40 +
 
 gtk+3.0 (3.24.37-1) experimental; urgency=medium
 
diff --git a/debian/patches/Update-Galician-translation.patch b/debian/patches/Update-Galician-translation.patch
new file mode 100644
index 00..2e729bfcd5
diff --git a/debian/patches/Update-Hebrew-translation.patch b/debian/patches/Update-Hebrew-translation.patch
new file mode 100644
index 00..dd90613d9b
diff --git a/debian/patches/selection-Use-the-right-mime-type.patch b/debian/patches/selection-Use-the-right-mime-type.patch
new file mode 100644
index 00..1c6e8705dc
diff --git a/debian/patches/series b/debian/patches/series
index 75e2a23964..52b52c99b8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,6 @@
+selection-Use-the-right-mime-type.patch
+Update-Hebrew-translation.patch
+Update-Galician-translation.patch
 016_no_offscreen_widgets_grabbing.patch
 017_no_offscreen_device_grabbing.patch
 060_ignore-random-icons.patch
diff --git a/gtk/gtkselection.c b/gtk/gtkselection.c
index 048b4ad496..82755e9a66 100644
--- a/gtk/gtkselection.c
+++ b/gtk/gtkselection.c
@@ -343,6 +343,7 @@ static GdkAtom text_plain_utf8_atom;
 static GdkAtom text_plain_locale_atom;
 static GdkAtom text_uri_list_atom;
 static GdkAtom portal_files_atom;
+static GdkAtom portal_filetransfer_atom;
 
 static void 
 init_atoms (void)
@@ -364,6 +365,7 @@ init_atoms (void)
 
   text_uri_list_atom = gdk_atom_intern_static_string ("text/uri-list");
   portal_files_atom = gdk_atom_intern_static_string ("application/vnd.portal.files");
+  portal_filetransfer_atom = gdk_atom_intern_static_string ("application/vnd.portal.filetransfer");
 }
 }
 
@@ -526,7 +528,10 @@ gtk_target_list_add_uri_targets (GtkTargetList *list,
 
 #ifndef G_OS_WIN32
   if (file_transfer_portal_supported ())
-gtk_target_list_add (list, portal_files_atom, 0, info);
+{
+  gtk_target_list_add (list, portal_filetransfer_atom, 0, info);
+  gtk_target_list_add (list, portal_files_atom, 0, info);
+}
 #endif
 }
 
@@ -1899,7 +1904,8 @@ gtk_selection_data_set_uris (GtkSelectionData  *selection_data,
 	}
 }
 #ifndef G_OS_WIN32
-  else if (selection_data->target == portal_files_atom &&
+  else if ((selection_data->target == portal_filetransfer_atom ||
+selection_data->target == portal_files_atom) &&
file_transfer_por