Bug#1033747: Can’t Create Merge Request

[Soren Stoutner]

https://salsa.debian.org/sorenstoutner/chromium/-/commit/
4e771687e558a3c0b3c8dc052664e249d0db3c56[1] fixes this issue, but for 
some reason I can’t create a merge request.

-- 
Soren Stoutner
so...@stoutner.com


[1] https://salsa.debian.org/sorenstoutner/chromium/-/commit/
4e771687e558a3c0b3c8dc052664e249d0db3c56


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

Bug#1033771: libopenjfx-java: javafx.scene.media does not support available libav versions

[Owen]

Package: libopenjfx-java
Version: 11.0.11+1-3
Severity: normal
X-Debbugs-Cc: owen.riddy+deb...@fastmail.com

Dear Maintainer,

This problem was found trying to play an mp3 using Clojure (the JVM hosted 
language). Constructing a javafx.scene.media.MediaPlayer failed with an 
exception:

com.sun.media.jfxmedia.MediaException
   Could not create player!

I have investigated the issue and believe that the problem is due to the 
version of libavcodec in Debian. At the moment Debian has 2 options:

$ aptitude search "libavcodec[0-9]*$" -F %p
libavcodec58


libavcodec59


libavcodec59:i386 

However, OpenJFX only added support for 58 in v13 
(https://bugs.openjdk.org/browse/JDK-8215894) and 59 in v20 
(https://bugs.openjdk.org/browse/JDK-8294400). Neither option allows mp3 
playback.

I changed my project dependencies to use javafx-media version 20 and it worked 
as expected.

;; deps.edn
org.openjfx/javafx-media {:mvn/version "20"}

;; Code
(import [javafx.scene.media Media MediaPlayer])
(import [javafx.application Platform])

(Platform/startup identity)

(def media (-> "audio/screen-saver.mp3" io/resource .toExternalForm Media.))
(def player (MediaPlayer. media))

(.play player)

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

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

Versions of packages libopenjfx-java depends on:
ii  libopenjfx-jni  11.0.11+1-3

libopenjfx-java recommends no packages.

Versions of packages libopenjfx-java suggests:
ii  openjfx  11.0.11+1-3

-- no debconf information

Bug#1033770: bullseye-pu: package apache2/2.4.56-1~deb11u2

[Yadd]

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

[ Reason ]
apache2 silently reenable apache2-doc.conf despite having been disabled
(#1018718)

[ Impact ]
This behavior  overwrites local changes on upgrade, which is a
release-critical bug as it’s a Policy violation

[ Tests ]
No change

[ Risks ]
No risk here

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

[ Changes ]
Drop apache2-doc.postinst

[ Other ]
Fixed in testing/Bookworm in version 2.4.54-3.

Cheers,
Yadd
diff --git a/debian/NEWS b/debian/NEWS
new file mode 100644
index ..c048ae45
--- /dev/null
+++ b/debian/NEWS
@@ -0,0 +1,9 @@
+apache2 (2.4.56-1~deb11u2) bullseye; urgency=medium
+
+  This version does not automatically enable the apache2 config snippet for
+  /manual anymore. If you want to have it enabled you will need to do this
+  yourself, e.g. with
+
+/usr/sbin/a2enconf apache2-doc
+
+ -- Yadd   Sat, 01 Apr 2023 08:17:08 +0400
diff --git a/debian/apache2-doc.postinst b/debian/apache2-doc.postinst
deleted file mode 100644
index e7e1e5a7..
--- a/debian/apache2-doc.postinst
+++ /dev/null
@@ -1,17 +0,0 @@
-#! /bin/sh
-
-set -e
-
-# conffiles must be moved before invoking rc.d
-#DEBHELPER#
-
-# This code should use dh_apache2 once it is available as build dependency
-
-if [ "$1" = "configure" ] ; then
-   if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
-   . /usr/share/apache2/apache2-maintscript-helper
-   apache2_invoke enconf apache2-doc || true
-   fi
-fi
-
-exit
diff --git a/debian/changelog b/debian/changelog
index 41c3a7cc..1c0d3659 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+apache2 (2.4.56-1~deb11u2) bullseye; urgency=medium
+
+  [ Hendrik Jäger ]
+  * Don't automatically enable apache2-doc.conf (Closes: #1018718)
+
+ -- Yadd   Sat, 01 Apr 2023 08:24:10 +0400
+
 apache2 (2.4.56-1~deb11u1) bullseye-security; urgency=medium
 
   * New upstream version (Closes: #1032476, CVE-2023-27522, CVE-2023-25690)

Bug#1004507: RFP: tagainijisho -- Japanese dictionary and learning assistant

[Bryan Gardiner]

Hello,

Tagaini Jisho is a fantastic program and is my go-to for any kind of
Japanese translation, so I am interested in getting it back into Debian.
Its Qt 5 port was released as stable in version 1.2.0 last year, and the
latest upstream version is now 1.2.2.

I have updated the old 1.0.2-2 packaging for the latest release, and
uploaded a source package to mentors.debian.net.  I haven't found in the
docs whether I should file an ITP separate from this RFP, or can just
use this bug, but I'll assume for the sake of tidiness that a separate
bug isn't wanted.

Thanks,
Bryan

Bug#1033769: buildd.debian.org: winetricks not open

[acpi, sgx, x509, bios uefi, hardware lenovo ideapad 330-15IGM 81FN]

Package: buildd.debian.org
Severity: important
X-Debbugs-Cc: genteboapesso...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Bug#1033768: buildd.debian.org: Choose lxqt and install kde, low performance, ptbr utf8 abnt2, lenovo ideapad 330-15IGM 81FN

[acpi, sgx, x509, bios uefi, hardware lenovo ideapad 330-15IGM 81FN]

Package: buildd.debian.org
Severity: important
X-Debbugs-Cc: genteboapesso...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Bug#1033767: buildd.debian.org: error bug acpi sgx x509, pc 81fn lenovo

[acpi, sgx, x509, bios uefi, hardware lenovo ideapad 330-15IGM 81FN]

Package: buildd.debian.org
Severity: important
X-Debbugs-Cc: genteboapesso...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Bug#1033766: bullseye-pu: package cyrus-imapd/3.6.1-4

[Yadd]

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

[ Reason ]
debian/copyright was incomplete

[ Impact ]
Incomplete copyright

[ Tests ]
No change, test passed. Note that autopkgtest works but has been
disabled on Debian machines (too long).

[ Risks ]
No risk here, no code change.

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

[ Changes ]
Update of debian/copyright

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 9d1408cb..a6d3c31a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+cyrus-imapd (3.6.1-4) unstable; urgency=medium
+
+  * Update copyright
+  * Declare compliance with policy 4.6.2
+
+ -- Yadd   Fri, 31 Mar 2023 11:12:57 +0400
+
 cyrus-imapd (3.6.1-2) unstable; urgency=medium
 
   [ Remus-Gabriel Chelu ]
diff --git a/debian/control b/debian/control
index ad383b18..d20e0f52 100644
--- a/debian/control
+++ b/debian/control
@@ -51,7 +51,7 @@ Build-Depends: bison,
unicode-data,
xxd,
xutils-dev
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/debian/cyrus-imapd
 Vcs-Git: https://salsa.debian.org/debian/cyrus-imapd.git
 Homepage: https://www.cyrusimap.org/
diff --git a/debian/copyright b/debian/copyright
index b6d376e4..1049ba5c 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -7,6 +7,43 @@ Files: *
 Copyright: 1994-2020, Carnegie Mellon University
 License: CMU
 
+Files: cassandane/*
+Copyright: 2011 Opera Software Australia Pty. Ltd.
+License: OSAP
+
+Files: cassandane/Cassandane/*
+ cassandane/utils/crash.c
+Copyright: 2011-2022 Fastmail Pty Ltd
+License: FPL
+
+Files: cmulocal/ax_cxx_compile_stdcxx_11.m4
+Copyright: 2008 Benjamin Kosnik 
+ 2012 Zack Weinberg 
+ 2013 Roy Stogner 
+ 2014, 2015 Google Inc., contributed by Alexey Sokolov 
+ 2015 Paul Norman 
+License: FSFAPL
+
+Files: cmulocal/ax_prog_perl_modules.m4
+Copyright: 2009 Dean Povey 
+License: FSFAPL
+
+Files: cmulocal/*.m4
+ compile
+ config.*
+ ylwrap
+Copyright: 1992-2022 Free Software Foundation, Inc.
+License: GPL-2+
+
+Files: cmulocal/ax_python_module.m4
+Copyright: 2008 Andrew Collier
+License: FSFAPL
+
+Files: com_err/et/*
+Copyright: 1987, 1988 by the Student Information Processing Board of the
+ Massachusetts Institute of Technology
+License: MIT
+
 Files: debian/*
 Copyright: 1997, Joey Hess
  2001-2010, Henrique de Moraes Holschuh
@@ -18,6 +55,11 @@ Copyright: 1997, Joey Hess
  2019-2022, Yadd 
 License: GPL-2+
 
+Files: doc/*
+Copyright: 1993–2023 The Cyrus Team
+License: CMU
+Comment: Built with Sphinx, license BSD-2-Clause
+
 Files: imap/objectstore_caringo.c
 Copyright: 2015 OpenIO, as a part of Cyrus
 License: CMU
@@ -128,6 +170,41 @@ License: CMU
  AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
  OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 
+License: FPL
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ .
+ 1. Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+ .
+ 2. Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+ .
+ 3. The name "Fastmail Pty Ltd" must not be used to
+endorse or promote products derived from this software without
+prior written permission. For permission or any legal
+details, please contact
+ FastMail Pty Ltd
+ PO Box 234
+ Collins St West 8007
+ Victoria
+ Australia
+ .
+ 4. Redistributions of any form whatsoever must retain the following
+acknowledgment:
+"This product includes software developed by Fastmail Pty. Ltd."
+ .
+ FASTMAIL PTY LTD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY  AND FITNESS, IN NO
+ EVENT SHALL OPERA SOFTWARE AUSTRALIA BE LIABLE FOR ANY SPECIAL, INDIRECT
+ OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
+ USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ OF THIS SOFTWARE.
+
 License: Expat
  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files (the "Software"), to
@@ -146,6 +223,12 @@ License: Expat
  AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
  TION WITH THE SOFTWARE OR THE USE OR 

Bug#1032916: ca-certificates: expired certificate: E-Tugra_Certification_Authority.crt

[Antoine Beaupré]

On 2023-03-14 07:54:07, Paul Wise wrote:
> I noticed that there is one expired certificate in ca-certificates:

On 2023-03-18 15:55:28, Philipp Hahn wrote:
> FYI: ca-certificates conatins many more CA certificates, which are
> expired by now:

It seems to me this would be a prime candidate for a nice autopkgtest,
so that this would be detected by our CI system... :)

a.
-- 
On ne peut s'empêcher de vieillir, mais on peut s'empêcher de devenir
vieux.
- Henri Matisse

Bug#951465: new source package for Meson documentation?

[John Scott]

It doesn't make sense to use a patch to add the Meson documentation to
this source package. I wonder if a new source package providing Meson
documentation (because it is maintained separately) would be welcome? I
would be willing to prepare this, but as I am not a Debian Developer, I
will need a sponsor.


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

Bug#1033745: sequeler: Unlisted dependency on libgda-5.0-mysql

[Yangfl]

Brian Vaughan  于2023年4月1日周六 01:33写道：
>
> Package: sequeler
> Version: 0.8.0-1+b2
> Severity: normal
> X-Debbugs-Cc: bgvaug...@gmail.com
>
> Without libgda-5.0-mysql installed, Sequeler will fail to connect to a MariaDB
> database, with the error message, "No provider 'MySQL' installed".
>
> sequeler 0.8.0-1+b2 lists libgda-5.0-4 as a dependency. libgda-5.0-4 suggests
> libgda-5.0-bin, libgda-5.0-mysql, and libgda-5.0-postgres.
>
> According to this upstream bug, sequeler should list as dependencies
> libgda-5.0-mysql and libgda-5.0-postgres.
> https://github.com/Alecaddd/sequeler/issues/26
>
>
> -- System Information:
> Debian Release: 12.0
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages sequeler depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
> ii  libc62.36-8
> ii  libcairo21.16.0-7
> ii  libgda-5.0-4 5.2.10-3
> ii  libgee-0.8-2 0.20.6-1
> ii  libglib2.0-0 2.74.6-1
> ii  libgranite6  6.2.0-3
> ii  libgtk-3-0   3.24.37-2
> ii  libgtksourceview-3.0-1   3.24.11-2+b1
> ii  libsecret-1-00.20.5-3
> ii  libssh2-11.10.0-3+b1
>
> sequeler recommends no packages.
>
> sequeler suggests no packages.
>
> -- no debconf information

This does not stop user using sqlite connection, so they are not
qualified as hard dependencies.

Bug#1033765: mirror submission for debian.vranetworks.com

[Ernesto Valdes Curiel]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.vranetworks.com
Type: leaf
Archive-architecture: amd64 arm64 armhf
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Ernesto Valdes Curiel 
Country: MX Mexico




Trace Url: http://debian.vranetworks.com/debian/project/trace/
Trace Url: 
http://debian.vranetworks.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.vranetworks.com/debian/project/trace/debian.vranetworks.com

Bug#1033764: [INTL:ro] Romanian debconf templates translation of vsftpd

[Remus-Gabriel Chelu]

Package: vsftpd
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «vsftpd» file.

Thanks,
Remus-Gabriel

vsftpd_debconf_ro.po
Description: Binary data

Bug#1033607: sogo: /usr/bin/sogo linked against wrong version of libgnustep-base

[Phil Gruber]

Thanks for getting back to me.

Here's what this looks like for me:


$ /usr/sbin/sogod
/usr/sbin/sogod: error while loading shared libraries: libgnustep-base.so.1.24: 
cannot open shared object file: No such file or directory
$ ldd -r /usr/sbin/sogod | grep gnustep
libgnustep-base.so.1.27 => /usr/lib/libgnustep-base.so.1.27 
(0x7f6c6428f000)
libgnustep-base.so.1.24 => not found
libgnustep-base.so.1.24 => not found
libgnustep-base.so.1.24 => not found
libgnustep-base.so.1.24 => not found
libgnustep-base.so.1.24 => not found
libgnustep-base.so.1.24 => not found
libgnustep-base.so.1.24 => not found
libgnustep-base.so.1.24 => not found
libgnustep-base.so.1.24 => not found


I just removed and re-installed the sogo package, but it didn't make a 
difference.


On 01/04/2023 03.27, Sebastian Ramacher wrote:

Control: tags -1 moreinfo

On 2023-03-28 14:45:24 +0200, Philipp Gruber wrote:

Package: sogo
Version: 5.0.1-4+deb11u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The binary of /usr/sbin/sogod contained in bullseye is linked to
libgnustep-base.so.1.24.


Are you sure?

$ ldd -r /usr/sbin/sogod | grep gnustep-base
 libgnustep-base.so.1.27 => /usr/lib/libgnustep-base.so.1.27 
(0x7f3b59898000)

Cheers


However, the package depends on libgnustep-base.so.1.27,
which is the current version of bullseye.

Downgrading is not possible due to dependencies. I assume re-building
the binary with correct dependencies will fix this.

Kind regards,
Phil


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

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

Versions of packages sogo depends on:
ii  adduser   3.118
ii  gnustep-base-runtime  1.27.0-3
ii  init-system-helpers   1.60
ii  libc6 2.31-13+deb11u5
ii  libcrypt1 1:4.4.18-4
ii  libcurl4  7.74.0-1.3+deb11u3
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  libgnustep-base1.27   1.27.0-3
ii  liblasso3 2.6.1-3
ii  libmemcached111.0.18-4.2
ii  liboath0  2.6.6-3
ii  libobjc4  10.2.1-6
ii  libsbjson2.3  2.3.2-4+b2
ii  libsodium23   1.0.18-1
ii  libsope1  5.0.1-2
ii  libssl1.1 1.1.1n-0+deb11u3
ii  libzip4   1.7.3-1
ii  lsb-base  11.1.0
ii  memcached 1.6.9+dfsg-1
ii  sogo-common   5.0.1-4+deb11u1
ii  systemd   247.3-7+deb11u1
ii  zip   3.0-12

sogo recommends no packages.

Versions of packages sogo suggests:
ii  default-mysql-server1.0.7
ii  mariadb-server-10.5 [virtual-mysql-server]  1:10.5.18-0+deb11u1

-- Configuration Files:
/etc/sogo/sogo.conf [Errno 13] Permission denied: '/etc/sogo/sogo.conf'

-- no debconf information

Bug#1033763: unblock: fpc/3.2.2+dfsg-20

[Abou Al Montacir]

Hi,

On Sat, 2023-04-01 at 02:20 +0200, Abou Al Montacir wrote:
> ...
>   [x] attach debdiff against the package in testing
> ...
Attaching debdiff
-- 
Cheers,
Abou Al Montacir
diff -Nru fpc-3.2.2+dfsg/debian/changelog fpc-3.2.2+dfsg/debian/changelog
--- fpc-3.2.2+dfsg/debian/changelog	2023-03-17 13:45:28.0 +0100
+++ fpc-3.2.2+dfsg/debian/changelog	2023-03-30 21:31:30.0 +0200
@@ -1,3 +1,10 @@
+fpc (3.2.2+dfsg-20) unstable; urgency=medium
+
+  * Fixed compiler internal error 2003042401 on mipsel.
+This error occurs when compiling Lazarus  on mipsel architecture.
+
+ -- Abou Al Montacir   Thu, 30 Mar 2023 21:31:30 +0200
+
 fpc (3.2.2+dfsg-19) unstable; urgency=medium
 
   * Fixed missing crtbeginS.o on mipsel architecture.
diff -Nru fpc-3.2.2+dfsg/debian/patches/5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch fpc-3.2.2+dfsg/debian/patches/5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch
--- fpc-3.2.2+dfsg/debian/patches/5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch	1970-01-01 01:00:00.0 +0100
+++ fpc-3.2.2+dfsg/debian/patches/5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch	2023-03-29 13:43:22.0 +0200
@@ -0,0 +1,24 @@
+From 85c7368759f5fb53aa23e03c8cc27c2deb424b62 Mon Sep 17 00:00:00 2001
+From: florian 
+Date: Wed, 24 Aug 2022 21:15:18 +0200
+Subject: [PATCH]   * handle also simulated flags in
+ tmipselnotnode.second_boolean, resolves #39877
+
+---
+ compiler/mips/ncpumat.pas | 31 ---
+ tests/webtbs/tw39877.pp   | 15 +++
+ 2 files changed, 31 insertions(+), 15 deletions(-)
+ create mode 100644 tests/webtbs/tw39877.pp
+
+diff --git a/fpcsrc/compiler/mips/ncpumat.pas b/fpcsrc/compiler/mips/ncpumat.pas
+index 9db7c052..5b33a866 100644
+--- a/fpcsrc/compiler/mips/ncpumat.pas
 b/fpcsrc/compiler/mips/ncpumat.pas
+@@ -245,6 +245,7 @@ begin
+   begin
+ secondpass(left);
+ case left.location.loc of
++  LOC_FLAGS,
+   LOC_REGISTER, LOC_CREGISTER, LOC_REFERENCE, LOC_CREFERENCE,
+   LOC_SUBSETREG,LOC_CSUBSETREG,LOC_SUBSETREF,LOC_CSUBSETREF:
+   begin
diff -Nru fpc-3.2.2+dfsg/debian/patches/series fpc-3.2.2+dfsg/debian/patches/series
--- fpc-3.2.2+dfsg/debian/patches/series	2023-03-15 14:20:00.0 +0100
+++ fpc-3.2.2+dfsg/debian/patches/series	2023-03-29 13:09:50.0 +0200
@@ -34,3 +34,4 @@
 pas2jni-cthreads.patch
 change_fpmake_to_install_missing_package_examples.patch
 Fix-missing-crtbeginS.o-on-mipsel.patch
+5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch
diff -Nru fpc-3.2.2+dfsg/debian/source/timestamps fpc-3.2.2+dfsg/debian/source/timestamps
--- fpc-3.2.2+dfsg/debian/source/timestamps	2023-03-15 14:20:00.0 +0100
+++ fpc-3.2.2+dfsg/debian/source/timestamps	2023-03-29 13:45:08.0 +0200
@@ -5,6 +5,7 @@
 fpcsrc/compiler/globals.pas 2020-05-14T13:54+00:00
 fpcsrc/compiler/hlcgobj.pas 2020-05-14T13:54+00:00
 fpcsrc/compiler/m68k/cpubase.pas 2022-05-26T16:24+00:00
+fpcsrc/compiler/mips/ncpumat.pas 2023-03-29T11:45+00:00
 fpcsrc/compiler/ncgvmt.pas 2022-11-19T17:36+00:00
 fpcsrc/compiler/powerpc64/cgcpu.pas 2022-11-19T17:36+00:00
 fpcsrc/compiler/powerpc64/cpupara.pas 2022-05-26T16:24+00:00


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

Bug#1033763: unblock: fpc/3.2.2+dfsg-20

[Abou Al Montacir]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package fpc

Fixed compiler crash by applying a patch from upstream.

[ Reason ]
When compiling some packages on mipsel, FPC craches with internal error
2003042401. This issue was solved by upstream.

[ Impact ]
The fix is in a file specific to the mipsel code generator, so can not impact
any other architecutre. It adds code generation for a special combination of
opcode and operands. The same code exists already for similar architectures
like SPARC.

[ Tests ]
The code file producing the internal error is now compiled correctly.
There is a test produced by upstream to test this fix, but we decided not to
include it in order not to increase the size of the patch.

[ Risks ]
No risks are foreseen.

[ 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

[ Other info ]
This patch was produced by FPC upstream mipsel maintainer and was included for
long time in their daily snapshots.

Bug#1033762: [INTL:ro] Romanian debconf templates translation of vdr

[Remus-Gabriel Chelu]

Package: vdr
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «vdr» file.

Thanks,
Remus-Gabriel

vdr_debconf_ro.po
Description: Binary data

Bug#1033637: linux: amdgpu - External displays connected through Thinkpad Ultra Dock not turn on after suspend

[Diederik de Haas]

On Friday, 31 March 2023 12:57:44 CEST Stefan K wrote:
> when I searching my error message I got a lot of hits..
> In arch it's solved:
> https://bugs.archlinux.org/task/76934
> 
> the patch:
> https://gitlab.freedesktop.org/superm1/linux/-/commit/2145b4de3fea9908cda6be
> f0693a797cc7f4ddfc.patch

Oh boy, that brought back some memories ...

That patch would likely indeed have solved your problem, but I'm going to take 
a guess and assume that you didn't actually try to apply that patch and 
verified that it then worked. (because it would be very difficult to apply)
That patch was HUGE and therefor unacceptable to be backported to 6.1 and this 
issue is AFAIUI one of the reasons that it took longer then normal to declare 
6.1 a LTS release.

The memories refer to https://bugs.debian.org/1028451 and that got solved by a 
different set of patches which were accepted (and the result of *further* 
discussions around that issue).
https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1721571 which is the 
"Forwarded" of that bug, also refers to "6.1.5.arch2-1". Further discussion on 
that issue resulted in the aforementioned patches which were accepted.

But I believe there were some corner cases expected that would not be solved 
and I'm guessing your issue is one of those.

On Wednesday, 29 March 2023 09:59:22 CEST Stefan K wrote:
> and syslog said:
> [drm:dc_link_allocate_mst_payload [amdgpu]] *ERROR* Failure: pbn_per_slot==0
> not allowed. Cannot continue, returning DC_UNSUPPORTED_VALUE.

That's from your initial bug report and that may be key to finding out if/why 
your case is indeed such a corner case and from there find.

https://bugs.debian.org/1033050 may be the same or a similar issue.
@Bernhard: Do you think it's the same issue?

If so, that may be useful as your report contains a kernel crash with a stack 
trace. I don't know what to do with that, but others can. Certainly the 
upstream devs which this issue likely needs to be reported to.

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

Bug#1033761: nautilus-scripts-manager: nautilus-script-manager throws exception under bookworm

[H . -Dirk Schmitt]

Package: nautilus-scripts-manager
Version: 2.0-1.1
Severity: grave
X-Debbugs-Cc: none, H.-Dirk Schmitt 

The package seems to be outdated for bookworm.

/bin/nautilus-scripts-manager:21: PyGIWarning: Pango was imported without 
specifying a version first. Use gi.require_version('Pango', '1.0') before 
import to ensure that the right version gets loaded.
  from gi.repository import Pango, Gtk, GLib
libEGL warning: DRI3: failed to query the version
libEGL warning: DRI2: failed to authenticate
/bin/nautilus-scripts-manager:21: PyGIWarning: Gtk was imported without 
specifying a version first. Use gi.require_version('Gtk', '4.0') before import 
to ensure that the right version gets loaded.
  from gi.repository import Pango, Gtk, GLib
Traceback (most recent call last):
  File "/bin/nautilus-scripts-manager", line 97, in 
s = Gdk.Screen.get_default()
^^
  File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 32, in 
__getattr__
return getattr(self._introspection_module, name)
   ^
  File "/usr/lib/python3/dist-packages/gi/module.py", line 123, in __getattr__
raise AttributeError("%r object has no attribute %r" % (
AttributeError: 'gi.repository.Gdk' object has no attribute 'Screen'


Same result on 2 different machines.

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

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

Versions of packages nautilus-scripts-manager depends on:
ii  nautilus43.2-1
ii  python3 3.11.2-1
ii  python3-gi  3.42.2-3+b1

nautilus-scripts-manager recommends no packages.

nautilus-scripts-manager suggests no packages.

-- no debconf information


-- 

---

H.-Dirk_Schmitt
Dipl.Math.
eMail:dirk.schm...@computer42.org
pgp: http://www.computer42.org/~dirk/OpenPGP-fingerprint.html

Bug#1033682: unblock tomboy-ng: 0.36a

[David Bannon]

On 1/4/23 04:34, Sebastian Ramacher wrote:

Control: tags -1 moreinfo

On 2023-03-30 13:31:28 +1100, David Bannon wrote:

Package: release.debian.org
Severity: normal
User:release.debian@packages.debian.org
Usertags: unblock


Please unblock package tomboy-ng v0.36a

[ Reason ]
Poor testing on my part lead to the use of bad colors for dark
themes with version 0.36 currently in Bookworm. This relates to
tomboy-ng's recent move to using Qt5 instead of gtk2 and,
perhaps, my own person preference to not use dark themes.
V0.36a is now uploaded and my sponsor requested I apply for an
unblock.

..
Why are you removing the old changelog entry?

Cheers


Good question Sebastian.  Sadly, I don't have a good answer. Seems in my 
haste to get the important fixes into the app in time, I messed up use 
of my packaging scripts. (Noting I release tomboy-ng in several other 
Linux packages, Windows and MacOS.)


The changelog 'should' look like this (just updated) -

https://github.com/tomboy-notes/tomboy-ng/blob/master/debian/changelog

But the one you have is missing transition from 0.35 to 0.36. Future 
releases will have the missing information.


// --- changelog ---

1c1
< tomboy-ng (0.36-1) unstable; urgency=medium
---
> tomboy-ng (0.36a-1) unstable; urgency=medium
3,14c3,7
<   *  Release of new version
<   * From 0.35 to 0.36 -
<   * New Feature export as PDF.
<   * New Feature insert a symbol or accented character.
<   * Bug fix in column mode of calculator.
<   * Warn user about setting non mono font.
<   * All Tomdroid functionality removed.
<   * A fix for SWYT not finding some text in a brand new note.
<   * Can set colour of a link, more suitable default.
<   * Use of TextHint to better indicate EditSearch role.
<   * Revised note button colors for better dark theme use.
<   * Please see github for further change details
---
>   *  Release of new version.
>   * More uniform colors when used with qt5ct.
>   * Man page added info re colors.
>   * Indicator that custom colors being used.
>   * Please see github for further change details.
16c9
<  -- David Bannon   Wed, 22 Feb 2023 20:45:26 
+1100

---
>  -- David Bannon   Sun, 19 Mar 2023 10:08:23 
+1100


// --

Bug#1033277: coreutils: new upstream version

[Christoph Anton Mitterer]

On Fri, 2023-03-31 at 22:53 +0200, Sven Joachim wrote:
> Or complain on upstream
> bug #62572[1] and ask for a revert of the '-n' exit failure if the
> destination exists.

Well -n isn't POSIX. But in strictly speaking their change seems even
POSIX compliant to me as that says for both tools:

>The following exit values shall be returned:
> 0
>All input files were [copied/moved] successfully.
>>0
>An error occurred.

and one could argue that this ain't the case with -n if the destination
already exists.
It's however open to debate whether --no-clobber would have fallen into
that spirit.


OTOH, e.g. GNU coreutil cp's info page says in at least 9.1:
>An exit status of zero indicates success, and a nonzero value
>indicates failure.

So with that in mind they seem to break their own "promise" with that
change.


Anyway,... I have no strong opinions on that matter.
In any case, I don't think Debian should do anything else than
upstream/other-distros in that particular point.


Cheers,
Chris.

Bug#1026265: profile-sync-daemon: Please package new upstream release (6.48+)

[ng]

Is this package orphaned?

Bug#1028250: debian-installer: broken cryptsetup support

[Guilhem Moulin]

Hi kibi,

On Sat, 01 Apr 2023 at 00:36:35 +0200, Cyril Brulebois wrote:
> Cyril Brulebois  (2023-03-26):
>> I'm happy to have the patches included, and I can definitely live with
>> possible temporary regressions (should that happen) that might arise
>> from having them.
>
> Pre-upload testing shows that the situation seems unchanged with
> 2:2.6.1-3~deb12u1: encrypted LVM still OOMK's with otherwise default
> options in the installer, when the VM is started with `kvm -m 1G`;
> that's fine with `kvm -m 1.2G` so at least it didn't seem to regress
> from the previous d-i release, and I've decided to continue d-i preps
> accordingly.

Ah right, reopened the upstream issue but forgot to follow-up here :-(
https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1328592911

As I wrote in the upstream BTS the patch appears to be incomplete,
AFAICT it helps in the PBKDF benchmark but just like you I also noticed
it still sometimes fails while running the keyslot key derivation.
Unfortunately I only found that out *after* uploading ~deb12u1…  It was
premature to think one could remove the errata from the bookworm d-i,
but at least I'm quite confident that does not make the OOMK issue
worse: it solves it at early stage but but it sometimes still trigger
later.

From a user perspective, I guess it's best to stick to the errata for
now (at least for the graphical installer; in text mode 1G RAM appear to
be enough according to my tests).  Depending on what upstream comes up
with we might suggest to fix that via s-p-u later.

Thanks to you, elbrus, an other Release Team members for everything!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1033760: [INTL:ro] Romanian debconf templates translation of unattended-upgrades

[Remus-Gabriel Chelu]

Package: unattended-upgrades
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «unattended-upgrades» file.

Thanks,
Remus-Gabriel

unattended-upgrades_debconf_ro.po
Description: Binary data

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

[Pascal Hambourg]

Hello,

Le 01/04/2023 at 00:41, Dima Kogan wrote:


I got it running by using a friend's usb installer. HIS usb disk was a
valid UEFI boot disk, so I could boot in UEFI mode, and do the normal
install, which completed successfully.


How was this "usb installer" created ?


cp debian-bookworm-DI-alpha2-amd64-netinst.iso /dev/sde


This worked, but apparently this was not a valid UEFI thing.


It is bootable in EFI mode on all UEFI PCs I tested.


Next. Steve McIntyre suggested installing in "expert mode", and then
explicitly creating a GPT partition table. This worked, but I didn't
read his suggestion closely enough, and didn't add an ESP partition.


Anyway the installer partitioner (partman) would not allow to create an 
EFI system partition when booted in BIOS/legacy mode, and the boot 
loader installer (grub-installer) would not allow to install GRUB for 
EFI boot (even though some UEFI firmware accept to boot from a regular 
FAT partition, or you may create an EFI partition with fdisk-udeb or 
parted-udeb in an installer shell, and you may install grub-efi-amd64 
with apt-install in an installer shell).

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

[Dima Kogan]

Hi all. Thanks for the replies. I was just able to get it installed. And
here are some notes about what happened, and about how we can do better.

I got it running by using a friend's usb installer. HIS usb disk was a
valid UEFI boot disk, so I could boot in UEFI mode, and do the normal
install, which completed successfully.

As stated earlier, I made my USB install disk like this:

>  I downloaded this:
>
>debian-bookworm-DI-alpha2-amd64-netinst.iso
>
>  from here:
>
>https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/
>
>  and I wrote that .iso to /dev/sde
>
>cp debian-bookworm-DI-alpha2-amd64-netinst.iso /dev/sde

This worked, but apparently this was not a valid UEFI thing. Which I
didn't know. Maybe some clearer instructions on the website would help.
I was here:

  https://www.debian.org/devel/debian-installer/

Clicking on "amd64" under "other images (netboot, USB stick, etc.)"
gives me listings of files that I don't know what to do with. I ended up
getting the "CD" image, which gave me an .iso file that I did know what
to do with. The iso-cd page:

  https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/

has some quick instructions which maybe would be helpful for those that
don't know what to do with an .iso. It does mention UEFI, but only when
describing the "mac" image. So better UEFI notes on the iso-cd page. And
any kind of notes on the USB page would be good.


Next. Steve McIntyre suggested installing in "expert mode", and then
explicitly creating a GPT partition table. This worked, but I didn't
read his suggestion closely enough, and didn't add an ESP partition.
Because I didn't know anything about it. The installer allowed me to do
that, and once again, created an unbootable installation. Should the
installer have yelled at me? Just because I was in "expert mode" doesn't
mean I know what I'm doing :)

I guess that's it. In the default path where the installer just picks
the partition kind (MBR, GPT, ) I don't think it ever said anything
about that being a choice at all. If it at least had text somewhere
about creating an "MBR", or something, that would probably be good.

Thanks.

Bug#1028250: debian-installer: broken cryptsetup support

[Cyril Brulebois]

Hi again,

Cyril Brulebois  (2023-03-26):
> I'm happy to have the patches included, and I can definitely live with
> possible temporary regressions (should that happen) that might arise
> from having them.

Pre-upload testing shows that the situation seems unchanged with
2:2.6.1-3~deb12u1: encrypted LVM still OOMK's with otherwise default
options in the installer, when the VM is started with `kvm -m 1G`;
that's fine with `kvm -m 1.2G` so at least it didn't seem to regress
from the previous d-i release, and I've decided to continue d-i preps
accordingly.


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


signature.asc
Description: PGP signature

Bug#1033759: bullseye-pu: duktape/2.5.0-2+deb11u1

[Thorsten Alteholz]

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


The attached debdiff for duktape fixes CVE-2021-46322 in Bullseye. This 
CVE has been marked as no-dsa by thesecurity team.


The same fixes have been already uploaded to Unstable.

  Thorsten
diff -Nru duktape-2.5.0/debian/changelog duktape-2.5.0/debian/changelog
--- duktape-2.5.0/debian/changelog  2020-03-14 16:44:16.0 +0100
+++ duktape-2.5.0/debian/changelog  2023-03-26 14:03:02.0 +0200
@@ -1,3 +1,11 @@
+duktape (2.5.0-2+deb11u1) bullseye; urgency=medium
+
+  * upload by the LTS Team.
+  * CVE-2021-46322
+a SEGV issue was discovered when some stack limits are reached
+
+ -- Thorsten Alteholz   Sun, 26 Mar 2023 14:03:02 +0200
+
 duktape (2.5.0-2) unstable; urgency=medium
 
   * debian/copyright: update file (Closes: #951903)
diff -Nru duktape-2.5.0/debian/patches/CVE-2021-46322.patch 
duktape-2.5.0/debian/patches/CVE-2021-46322.patch
--- duktape-2.5.0/debian/patches/CVE-2021-46322.patch   1970-01-01 
01:00:00.0 +0100
+++ duktape-2.5.0/debian/patches/CVE-2021-46322.patch   2023-03-26 
14:03:02.0 +0200
@@ -0,0 +1,80 @@
+commit a851d8a5687356b1d6ad0f8f39d6226947f17b27
+Author: Sami Vaarala 
+Date:   Tue Jan 11 01:34:02 2022 +0200
+
+Fix segfault in call setup when valstack limit hit
+
+Index: duktape-2.5.0/src-input/duk_js_call.c
+===
+--- duktape-2.5.0.orig/src-input/duk_js_call.c 2023-03-27 19:32:09.275869100 
+0200
 duktape-2.5.0/src-input/duk_js_call.c  2023-03-27 19:32:09.275869100 
+0200
+@@ -2151,6 +2151,15 @@
+   /* [ ... func this arg1 ... argN ] */
+ 
+   /*
++   *  Grow value stack to required size before env setup.  This
++   *  must happen before env setup to handle some corner cases
++   *  correctly, e.g. test-bug-scope-segv-gh2448.js.
++   */
++
++  duk_valstack_grow_check_throw(thr, vs_min_bytes);
++  act->reserve_byteoff = (duk_size_t) ((duk_uint8_t *) thr->valstack_end 
- (duk_uint8_t *) thr->valstack);
++
++  /*
+*  Environment record creation and 'arguments' object creation.
+*  Named function expression name binding is handled by the
+*  compiler; the compiled function's parent env will contain
+@@ -2171,13 +2180,8 @@
+*  Setup value stack: clamp to 'nargs', fill up to 'nregs',
+*  ensure value stack size matches target requirements, and
+*  switch value stack bottom.  Valstack top is kept.
+-   *
+-   *  Value stack can only grow here.
+*/
+ 
+-  duk_valstack_grow_check_throw(thr, vs_min_bytes);
+-  act->reserve_byteoff = (duk_size_t) ((duk_uint8_t *) thr->valstack_end 
- (duk_uint8_t *) thr->valstack);
+-
+   if (use_tailcall) {
+   DUK_ASSERT(nregs >= 0);
+   DUK_ASSERT(nregs >= nargs);
+Index: duktape-2.5.0/tests/ecmascript/test-bug-scope-segv-gh2448.js
+===
+--- /dev/null  1970-01-01 00:00:00.0 +
 duktape-2.5.0/tests/ecmascript/test-bug-scope-segv-gh2448.js   
2023-03-27 19:32:09.275869100 +0200
+@@ -0,0 +1,35 @@
++// https://github.com/svaarala/duktape/issues/2448
++
++/*===
++RangeError
++===*/
++
++function JSEtest() {
++var src = [];
++var i;
++
++src.push('(function test() {');
++for (i = 0; i < 1e4; i++) {
++src.push('var x' + i + ' = ' + i + ';');
++}
++src.push('var arguments = test(); return "dummy"; })');
++src = src.join('');
++//print(src);
++
++var f = eval(src)(src);
++
++try {
++f();
++} catch (e) {
++print(e.name + ': ' + e.message);
++}
++
++print('still here');
++}
++
++try {
++JSEtest();
++} catch (e) {
++//print(e.stack || e);
++print(e.name);
++}
diff -Nru duktape-2.5.0/debian/patches/series 
duktape-2.5.0/debian/patches/series
--- duktape-2.5.0/debian/patches/series 2020-03-13 21:44:00.0 +0100
+++ duktape-2.5.0/debian/patches/series 2023-03-26 14:03:02.0 +0200
@@ -1,3 +1,5 @@
 #XXX hardening.patch
 hardening.patch
 debug-symbols.patch
+
+CVE-2021-46322.patch

Bug#1033758: [INTL:ro] Romanian debconf templates translation of ufw

[Remus-Gabriel Chelu]

Package: ufw
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «ufw» file.

Thanks,
Remus-Gabriel

ufw_debconf_ro.po
Description: Binary data

Bug#1033200: Reply to email -- notes on Debian -- Exposition re Xubuntu

[WILLIAM ORVILLE RICHMOND]

    You had noted:

 You can change the apt sources.list to use 'https' instead of 
'http' to potentially avoid some problems with external interference 
(although, some interference is considered good interference, so this 
isn't a default in Debian for now). A VPN would indeed eliminate far 
more of potential external interference, but for now that seems like 
overkill.


==

     I got a Debian installation together ( archived ssd ) and edited 
the "/etc/apt/services.list" file.  I then did "sudo apt update" which 
listed 187 items.  I followed this with "sudo apt upgrade" which 
miraculously downloaded and installed all 187 items.  After rebooting 
this machine with "shutdown -r now" {amazing after the amount of time I 
had put in these last 2-3 months} it worked properly.  I then did a 
"sudo apt install a2ps", a " sudo apt install gv" and a "sudo apt 
install aptitude".  I followed this with "sudo aptitude" and selected 
"openssh server" with the shift/+ followed by g and g.  After this 
completed installation and I had exited from aptitude and rebooted I 
tested this by doing "ssh orville@andy".  After logging in to andy I did 
"ssh orville@elmer" and was able to log in to elmer.


 While this is not an extensive test it seems that all on Debian 
was now working.


==

 Unless I understand why this happened I will continue to consider 
a VPN.


==

The current “/etc/apt/sources.list” file on elmer --- the current Debian 
makchine.


orville@elmer:/etc/apt$ cat sources.list
# See https://wiki.debian.org/SourcesList for more information.
deb https://deb.debian.org/debian bullseye main
deb-src https://deb.debian.org/debian bullseye main

deb https://deb.debian.org/debian bullseye-updates main
deb-src https://deb.debian.org/debian bullseye-updates main

deb https://security.debian.org/debian-security/ bullseye-security main
deb-src https://security.debian.org/debian-security/ bullseye-security main


==

Xubuntu with unmodified “/etc/apt/sources.list and unmodified 
“/etc/apt/sources.list.distUpgrade”


root@andy:/etc/apt# apt update
Err:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
  Temporary failure resolving 'security.ubuntu.com'
Err:2 http://us.archive.ubuntu.com/ubuntu jammy InRelease
  Connection failed [IP: 91.189.91.39 80]
Err:3 http://us.archive.ubuntu.com/ubuntu jammy-updates InRelease
  Connection failed [IP: 91.189.91.38 80]
Err:4 http://us.archive.ubuntu.com/ubuntu jammy-backports InRelease
  Connection failed [IP: 91.189.91.39 80]
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Failed to fetch 
http://us.archive.ubuntu.com/ubuntu/dists/jammy/InRelease Connection 
failed [IP: 91.189.91.39 80]
W: Failed to fetch 
http://us.archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease 
Connection failed [IP: 91.189.91.38 80]
W: Failed to fetch 
http://us.archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease 
Connection failed [IP: 91.189.91.39 80]
W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease 
Temporary failure resolving 'security.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old 
ones used instead.



Xubuntu with all “http://” replaced with “https://”

root@andy:/etc/apt# apt update
Err:1 https://security.ubuntu.com/ubuntu jammy-security InRelease
  Temporary failure resolving 'security.ubuntu.com'
Err:2 https://us.archive.ubuntu.com/ubuntu jammy InRelease
  Temporary failure resolving 'us.archive.ubuntu.com'
Err:3 https://us.archive.ubuntu.com/ubuntu jammy-updates InRelease
  Could not connect to us.archive.ubuntu.com:443 (91.189.91.39). - 
connect (111: Connection refused) Cannot initiate the connection to 
us.archive.ubuntu.com:443 (2001:67c:1562::15). - connect (101: Network 
is unreachable) Could not connect to us.archive.ubuntu.com:443 
(91.189.91.38). - connect (111: Connection refused) Cannot initiate the 
connection to us.archive.ubuntu.com:443 (2001:67c:1562::18). - connect 
(101: Network is unreachable)

Err:4 https://us.archive.ubuntu.com/ubuntu jammy-backports InRelease
  Cannot initiate the connection to us.archive.ubuntu.com:443 
(2001:67c:1562::15). - connect (101: Network is unreachable) Cannot 
initiate the connection to us.archive.ubuntu.com:443 
(2001:67c:1562::18). - connect (101: Network is unreachable)

Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Failed to fetch 
https://us.archive.ubuntu.com/ubuntu/dists/jammy/InRelease Temporary 
failure resolving 'us.archive.ubuntu.com'
W: Failed to fetch 
https://us.archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease Could 
not connect to us.archive.ubuntu.com:443 (91.189.91.39). - connect (111: 
Connection refused) Cannot initiate the connection to 
us.archive.ubuntu.com:443 (2001:67c:1562::15). - connect (101: Network 
is unreachable) Could not 

Bug#1033277: coreutils: new upstream version

[Sven Joachim]

On 2023-03-21 02:46 +0100, Christoph Anton Mitterer wrote:

> Package: coreutils
> Version: 9.1-1
> Severity: wishlist
>
> Hey.
>
> 9.2 is out :-)

This version has an important incompatible change:

,
|   'cp -n' and 'mv -n' now exit with nonzero status if they skip their
|   action because the destination exists, and likewise for 'cp -i',
|   'ln -i', and 'mv -i' when the user declines.  (POSIX specifies this
|   for 'cp -i' and 'mv -i'.)
`

If you have time on your hands, please look on codesearch.debian.net for
'cp -n', 'mv -n' and '--no-clobber' and file bugs against packages whose
scripts are going to fail due to this change.  Or complain on upstream
bug #62572[1] and ask for a revert of the '-n' exit failure if the
destination exists.

Cheers,
   Sven


1. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62572

Bug#1033672: otf2: FTBFS on riscv64 because it needs libatomic

[Samuel Thibault]

Hello,

Steve Langasek, le mer. 29 mars 2023 22:18:16 -0700, a ecrit:
> So I'm touching m4 after all.  Here's a minimal patch which I've
> build-tested locally and is expected to work on riscv64 autobuilds too.  You
> can see build results at:
> 
>   https://launchpad.net/ubuntu/+source/otf2/3.0.2-1ubuntu3

Thanks for your patch! Upstream integrated it a bit differently, I'll
upload a fixed package.

Samuel

Bug#1033757: ghostscript: CVE-2023-28879

[Salvatore Bonaccorso]

Source: ghostscript
Version: 10.0.0~dfsg-9
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=706494
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ghostscript.

CVE-2023-28879[0]:
| In Artifex Ghostscript through 10.01.0, there is a buffer overflow
| leading to potential corruption of data internal to the PostScript
| interpreter, in base/sbcp.c. This affects BCPEncode, BCPDecode,
| TBCPEncode, and TBCPDecode. If the write buffer is filled to one byte
| less than full, and one then tries to write an escaped character, two
| bytes are written.

I'm preparing an update for this issue.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-28879
https://www.cve.org/CVERecord?id=CVE-2023-28879
[1] https://bugs.ghostscript.com/show_bug.cgi?id=706494 (not public)

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033756: wireshark: CVE-2023-1161

[Salvatore Bonaccorso]

Source: wireshark
Version: 4.0.3-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/wireshark/wireshark/-/issues/18839
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wireshark.

CVE-2023-1161[0]:
| ISO 15765 and ISO 10681 dissector crash in Wireshark 4.0.0 to 4.0.3
| and 3.6.0 to 3.6.11 allows denial of service via packet injection or
| crafted capture file


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-1161
https://www.cve.org/CVERecord?id=CVE-2023-1161
[1] https://www.wireshark.org/security/wnpa-sec-2023-08.html
[2] https://gitlab.com/wireshark/wireshark/-/issues/18839

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

[Sebastian Ramacher]

Control: severity -1 important

On 2023-03-29 22:13:54 -0400, Antoine Beaupré wrote:
> On 2023-03-28 00:13:46, Francesco Poli wrote:
> > On Mon, 27 Mar 2023 00:03:20 -0400 (EDT) Unit 193 wrote:
> [...]
> >> And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
> >> is a workaround for the aforementioned throttling, to revert would mean to 
> >> make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
> >> utilize yt-dlp with the default quality option.
> >> 
> >> If we weren't so close to the freeze I'd say the right option would be to 
> >> simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
> >> an option anymore either.
> >
> > Why not?
> >
> > The [freeze policy] states that, even in full freeze, fixes for
> > important bugs are appropriate, as long as they can be done via unstable
> > (as it is currently the case for mpv).
> >
> > [freeze policy]: 
> >
> > I have just filed bug [#1033595], in order to request that the patches
> > you cited are applied to mpv.
> >
> > [#1033595]: 
> >
> > I hope this can be the way to go.
> 
> Considering that a bug was filed against mpv, shouldn't this one be
> downgraded? I don't quite see why yt-dlp should be kicked out of
> bookworm because mpv didn't catchup...

grave seems to be an exaggeration for this issue. Both packages still
work.

Cheers
-- 
Sebastian Ramacher

Bug#1033755: heimdal: CVE-2022-3116

[Salvatore Bonaccorso]

Source: heimdal
Version: 7.8.git20221117.28daf24+dfsg-1.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 7.7.0+dfsg-2+deb11u3
Control: found -1 7.7.0+dfsg-2

Hi,

The following vulnerability was published for heimdal.

CVE-2022-3116[0]:
| The Heimdal Software Kerberos 5 implementation is vulnerable to a null
| pointer dereferance. An attacker with network access to an application
| that depends on the vulnerable code path can cause the application to
| crash.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-3116
https://www.cve.org/CVERecord?id=CVE-2022-3116
[1] 
https://github.com/heimdal/heimdal/commit/7a19658c1f4fc4adf85bb7bea96caae5ba57b33e
 

Regards,
Salvatore

Bug#1020473: Ready to Implement

[Soren Stoutner]

The dependencies are finally in place so this can be implemented.

To make things simpler for dictionary packagers, we are using a virtual package 
and an 
unversioned path for the conversion tool so that dictionary packagers don’t 
have to make 
modifications to their packages when the versions of Qt change in Debian.

All you should need to do is the following:

1.  Build-depend on `convert-bdic`.
2.  Use /usr/bin/convert-bdic to do the dictionary conversion.
3.  Place the .bdic files in /usr/share/hunspell-bdic.

More detailed information can be found in the dictionary packager documentation 
at:

file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic

Thanks,

Soren

-- 
Soren Stoutner
so...@stoutner.com


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

Bug#1033754: python-redis: CVE-2023-28858

[Salvatore Bonaccorso]

Source: python-redis
Version: 4.3.4-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-redis.

CVE-2023-28858[0]:
| redis-py before 4.5.3 leaves a connection open after canceling an
| async Redis command at an inopportune time, and can send response data
| to the client of an unrelated request in an off-by-one manner. NOTE:
| this CVE Record was initially created in response to reports about
| ChatGPT, and 4.3.6, 4.4.3, and 4.5.3 were released (changing the
| behavior for pipeline operations); however, please see CVE-2023-28859
| about addressing data leakage across AsyncIO connections in general.

Ss mentioned in the description, please make sure to apply the
complete set of fixes to not open CVE-2023-28859. Currently we can
consider python-redis as not-affected by the CVE-2023-28859, as this
results by an incomplete fix for CVE-2023-28858. So when fixing
CVE-2023-28858 apply as well the followup needed fixes. Details in the
security-tracker reference.


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

For further information see:

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

Regards,
Salvatore

Bug#1033753: golang-github-crewjam-saml: CVE-2023-28119

[Salvatore Bonaccorso]

Source: golang-github-crewjam-saml
Version: 0.4.12-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-crewjam-saml.
Strictly speaking might be disputed if it is RC level, but would be
good to have it fixed in bookworm before the release.

CVE-2023-28119[0]:
| The crewjam/saml go library contains a partial implementation of the
| SAML standard in golang. Prior to version 0.4.13, the package's use of
| `flate.NewReader` does not limit the size of the input. The user can
| pass more than 1 MB of data in the HTTP request to the processing
| functions, which will be decompressed server-side using the Deflate
| algorithm. Therefore, after repeating the same request multiple times,
| it is possible to achieve a reliable crash since the operating system
| kills the process. This issue is patched in version 0.4.13.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-28119
https://www.cve.org/CVERecord?id=CVE-2023-28119
[1] 
https://github.com/crewjam/saml/commit/8e9236867d176ad6338c870a84e2039aef8a5021
[2] https://github.com/crewjam/saml/security/advisories/GHSA-5mqj-xc49-246p

Regards,
Salvatore

Bug#1033752: sniproxy: CVE-2023-25076

[Salvatore Bonaccorso]

Source: sniproxy
Version: 0.6.0-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sniproxy.

CVE-2023-25076[0]:
| A buffer overflow vulnerability exists in the handling of wildcard
| backend hosts of SNIProxy 0.6.0-2 and the master branch (commit:
| 822bb80df9b7b345cc9eba55df74a07b498819ba). A specially crafted HTTP,
| TLS or DTLS packet can lead to arbitrary code execution. An attacker
| could send a malicious packet to trigger this vulnerability.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-25076
https://www.cve.org/CVERecord?id=CVE-2023-25076
[1] https://talosintelligence.com/vulnerability_reports/TALOS-2023-1731
[2] 
https://github.com/dlundquist/sniproxy/commit/f8d9a433fe22ab2fa15c00179048ab02ae23d583

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033751: [INTL:ro] Romanian debconf templates translation of ucf

[Remus-Gabriel Chelu]

Package: ucf
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «ucf» file.

Thanks,
Remus-Gabriel

ucf_debconf_ro.po
Description: Binary data

Bug#1033750: glib-networking libproxy fails

[Casey C]

Package: glib-networking
Version: 2.74.0-4

An issue with glib-networking causes GStreamer to abort streams.
The "environment-libproxy" test from glib-networking-tests fails:
"$ /usr/libexec/installed-tests/glib-networking/environment-libproxy
# random seed: R02Scaabc7588fed22ec43e9b4138b1e372f
1..3
# Start of proxy tests
# Start of environment tests
ok 1 /proxy/environment/uri
ok 2 /proxy/environment/socks
# child process (/proxy/environment/ignore [2843]) exit status: 1 (error)
# child process (/proxy/environment/ignore [2843]) stdout: ""
# child process (/proxy/environment/ignore [2843]) stderr:
"**\nGLib-Net:ERROR:../proxy/tests/common.c:192:test_proxy_ignore_common:
assertion failed (proxies[0] == ignore_tests[i].proxy): (\"
http://localhost:8080\; == \"direct://\")\n"
**
GLib-Net:ERROR:../proxy/tests/environment.c:72:test_proxy_ignore: child
process (/proxy/environment/ignore [2843]) failed unexpectedly
Bail out! GLib-Net:ERROR:../proxy/tests/environment.c:72:test_proxy_ignore:
child process (/proxy/environment/ignore [2843]) failed unexpectedly
Aborted"

Other tests complete without error.

Debian GStreamer Bug Report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029618
GStreamer Bug Report:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1008

Architecture is powerpc. Running 32-bit userland on 64-bit kernel
(6.0.0-6-powerpc64). Please let me know if I can provide any additional
information.

Bug#1033749: libqt6webenginecore6: WebEngine currently builds with an embedded copy of libtiff

[Soren Stoutner]

Package: libqt6webenginecore6
Version: 6.4.2-final+dfsg-1
Severity: normal
Tags: upstream

WebEngine currently builds with an embedded copy of libtiff.

https://udd.debian.org/lintian/?packages=qt6-webengine

As described in the upstream Qt bug report, this appears to be a problem with
the embedded pdfium, even though the standalong libQt6Pdf.so does not have
an embedded copy, which has to do with different options being used during the
separate build processes.

https://bugreports.qt.io/browse/QTBUG-111626

An upstream Chromium bug has also been filed.

https://bugs.chromium.org/p/chromium/issues/detail?id=1429647

The purpose of this bug report is to track the upstream progress of this fix.
Once it is fixed upstream, it might or might not require a small modification
in the packaging to enable building against the system libtiff.



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

Kernel: Linux 6.1.0-6-amd64 (SMP w/12 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 libqt6webenginecore6 depends on:
ii  libc6   2.36-8
ii  libdbus-1-3 1.14.6-1
ii  libevent-2.1-7  2.1.12-stable-8
ii  libexpat1   2.5.0-1
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-4
ii  libgcc-s1   12.2.0-14
ii  libharfbuzz-subset0 6.0.0+dfsg-3
ii  libharfbuzz0b   6.0.0+dfsg-3
ii  libicu7272.1-3
ii  libjpeg62-turbo 1:2.1.5-2
ii  liblcms2-2  2.14-2
ii  libminizip1 1.1-8+b1
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libopenjp2-72.5.0-1+b1
ii  libopus01.3.1-3
ii  libpng16-16 1.6.39-2
ii  libqt6core6 [qt6-base-abi]  6.4.2+dfsg-7
ii  libqt6gui6  6.4.2+dfsg-7
ii  libqt6network6  6.4.2+dfsg-7
ii  libqt6positioning6  6.4.2-1
ii  libqt6qml6  6.4.2+dfsg-1
ii  libqt6quick66.4.2+dfsg-1
ii  libqt6webchannel6   6.4.2-1
ii  libqt6webengine6-data   6.4.2-final+dfsg-1
ii  libre2-920220601+dfsg-1+b1
ii  libsnappy1v51.1.9-3
ii  libstdc++6  12.2.0-14
ii  libvpx7 1.12.0-1
ii  libwebp71.2.4-0.1
ii  libwebpdemux2   1.2.4-0.1
ii  libwebpmux3 1.2.4-0.1
ii  libx11-62:1.8.4-2
ii  libxcb1 1.15-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.6-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxkbcommon0   1.5.0-1
ii  libxkbfile1 1:1.1.0-1
ii  libxml2 2.9.14+dfsg-1.1+b3
ii  libxrandr2  2:1.5.2-2+b1
ii  libxslt1.1  1.1.35-1
ii  libxtst62:1.2.3-1.1
ii  sse3-support15
ii  zlib1g  1:1.2.13.dfsg-1

libqt6webenginecore6 recommends no packages.

libqt6webenginecore6 suggests no packages.

-- no debconf information

Bug#1033748: source: build should not need extra option for user root

[henrynmail-deb...@yahoo.com]

Package: tar
Version: 1.34+dfsg-1
Severity: minor
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

thy typically steps tu build a pacage ist to run these steps as user "root":

   # apt source tar
   # cd tar-1.34+dfsg
   # apt build-dep tar
   # dpkg-buildpackage -B "-Pnocheck noinsttest noudeb" -uc -us

This stops with an error

    configure: error: you should not run configure as root (set 
FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)

For automate tools such stop is not nice.

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: unable to detect

Versions of packages tar depends on:
ii  libacl1  2.3.1-3
ii  libc6    2.36-8
ii  libselinux1  3.4-1+b5

tar recommends no packages.

Versions of packages tar suggests:
ii  bzip2    1.0.8-5+b1
pn  ncompress    
pn  tar-doc  
pn  tar-scripts  
ii  xz-utils 5.4.1-0.2

-- no debconf information

Bug#1033747: chromium: Build Chromium without the embedded libtiff

[Soren Stoutner]

Package: chromium
Version: 111.0.5563.110-1
Severity: normal
Tags: upstream

Chromium currently builds with an embedded copy of libtiff.  This is likely
pulled in by the embedded pdfium, althouth it might also be used in other
places.  Chromium usually detects the presence of system libraries at build
time and uses them if they are present, but in the case of libtiff the
necessary plumbing has never been added to do so.

Upstream bug report:

https://bugs.chromium.org/p/chromium/issues/detail?id=1429647


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

Kernel: Linux 6.1.0-6-amd64 (SMP w/12 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 chromium depends on:
ii  chromium-common  111.0.5563.110-1
ii  libasound2   1.2.8-1+b1
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libatomic1   12.2.0-14
ii  libatspi2.0-02.46.0-5
ii  libbrotli1   1.0.9-2+b6
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcups2 2.4.2-2
ii  libdbus-1-3  1.14.6-1
ii  libdouble-conversion33.2.1-1
ii  libdrm2  2.4.114-1+b1
ii  libevent-2.1-7   2.1.12-stable-8
ii  libexpat12.5.0-1
ii  libflac121.4.2+ds-2
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgbm1  22.3.6-1+deb12u1
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.6-1
ii  libgtk-3-0   3.24.37-2
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjsoncpp25 1.9.5-4
ii  liblcms2-2   2.14-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libopenjp2-7 2.5.0-1+b1
ii  libopus0 1.3.1-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libpulse016.1+dfsg1-2+b1
ii  libre2-9 20220601+dfsg-1+b1
ii  libsnappy1v5 1.1.9-3
ii  libstdc++6   12.2.0-14
ii  libwebp7 1.2.4-0.1
ii  libwebpdemux21.2.4-0.1
ii  libwebpmux3  1.2.4-0.1
ii  libwoff1 1.0.2-2
ii  libx11-6 2:1.8.4-2
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxkbcommon01.5.0-1
ii  libxml2  2.9.14+dfsg-1.1+b3
ii  libxnvctrl0  525.85.05-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxslt1.1   1.1.35-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  111.0.5563.110-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6  2.36-8
ii  libdouble-conversion3  3.2.1-1
ii  libjsoncpp25   1.9.5-4
ii  libstdc++6 12.2.0-14
ii  libx11-6   2:1.8.4-2
ii  libxnvctrl0525.85.05-1
ii  x11-utils  

Bug#1029618: GStreamer & glib-networking

[Casey C]

I submitted a bug report to GStreamer about this issue. See
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1008. The
GStreamer dev that helped out with my bug report found that the fault
originates with libproxy in glib-networking. I ran the
"environment-libproxy" test from glib-networking-tests and the result was:
"$ /usr/libexec/installed-tests/glib-networking/environment-libproxy
# random seed: R02S5b1dc0abfabd6b943121bee035468cde
1..3
# Start of proxy tests
# Start of environment tests
ok 1 /proxy/environment/uri
ok 2 /proxy/environment/socks
# child process (/proxy/environment/ignore [2067]) exit status: 1 (error)
# child process (/proxy/environment/ignore [2067]) stdout: ""
# child process (/proxy/environment/ignore [2067]) stderr:
"**\nGLib-Net:ERROR:../proxy/tests/common.c:192:test_proxy_ignore_common:
assertion failed (proxies[0] == ignore_tests[i].proxy): (\"
http://localhost:8080\; == \"direct://\")\n"
**
GLib-Net:ERROR:../proxy/tests/environment.c:72:test_proxy_ignore: child
process (/proxy/environment/ignore [2067]) failed unexpectedly
Bail out! GLib-Net:ERROR:../proxy/tests/environment.c:72:test_proxy_ignore:
child process (/proxy/environment/ignore [2067]) failed unexpectedly
Aborted"

The rest of the glib-networking tests complete without errors. I will
submit a bug report for glib-networking.

Bug#865975: docker.io: How to reproduce on Virtual Box / Windows host

[Mickaël Vera]

Package: docker.io
Version: 20.10.23+dfsg1-1+b3
Followup-For: Bug #865975
X-Debbugs-Cc: vera.mick...@free.fr

Dear Maintainer,

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

   * What led up to the situation?
 Installation of debian testing in Virtual Box (windows 10 Host) and basic 
use of docker.io
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Creation of a VM in Virtual Box, no customization at all
 Installation of debian testing in this VM, no customization at all
 Installation of docker.io
 Open a terminal and execute command "ping google.fr"
 => ping is OK for hours
 In another terminal execute "docker run -dit -p 8080:80 -v 
"$PWD":/usr/local/apache2/htdocs/ httpd:2.4
 After a few seconds (10 - 40s) the ping command displays "Destination Host 
Unreachable"
 docket stop  resolves the problem and ping command immediatly 
reaches destination
 applying iptables commands mentionned above doesn't solve the problem
 configuring docker like this
 /etc/docker/daemon.json:
 {
"iptables": false
 }
 prevents docker from modifying iptables config but doesn't solve the 
problem

   * What was the outcome of this action?
 Systematically, VM access to internet is broken
   * What outcome did you expect instead?
 Same behaviour as in Debian stable, no network broken access
 This nominal usage of docker works in ubuntu 22.10 installed today for 
this test

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


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

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

Versions of packages docker.io depends on:
ii  adduser3.131
ii  containerd 1.6.18~ds1-1+b2
ii  init-system-helpers1.65.2
ii  iptables   1.8.9-2
ii  libc6  2.36-8
ii  libdevmapper1.02.1 2:1.02.185-2
ii  libsystemd0252.6-1
ii  runc   1.1.4+ds1-1+b3
ii  sysvinit-utils [lsb-base]  3.06-2
ii  tini   0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 3.0.8-3
ii  ca-certificates  20230311
ii  cgroupfs-mount   1.4
ii  git  1:2.39.2-1.1
ii  needrestart  3.6-3
ii  xz-utils 5.4.1-0.2

Versions of packages docker.io suggests:
pn  aufs-tools 
pn  btrfs-progs
pn  debootstrap
pn  docker-doc 
ii  e2fsprogs  1.46.6-1
pn  rinse  
pn  rootlesskit
pn  xfsprogs   
pn  zfs-fuse | zfsutils-linux  

-- no debconf information

Bug#1033746: [INTL:ro] Romanian debconf templates translation of ubuntu-keyring

[Remus-Gabriel Chelu]

Package: ubuntu-keyring
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «ubuntu-keyring» file.

Thanks,
Remus-Gabriel

ubuntu-keyring_debconf_ro.po
Description: Binary data

Bug#1033734: munin-plugins-core: nginx_*: example configuration does not work with ipv6 localhost

[Holger Levsen]

control: tags -1 + +upstream
thanks

On Fri, Mar 31, 2023 at 07:43:56AM +0200, Helmut Grohne wrote:
> I noticed that the example configuration included in the nginx_* plugins
> does not work. Nowadays, localhost tends to resolve to ::1 and with the
> example configuration, this yields an error. Thus, it would be good to
> also listen on the ipv6 loopback to make it work. I'm attaching a patch.

thanks for the bug report with patch, Helmut!


-- 
cheers,
Holger

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

Climate Justice is that moment when we can start looking each other in the
eyes again. (Luisa Neubauer)


signature.asc
Description: PGP signature

Bug#1033682: unblock tomboy-ng: 0.36a

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-03-30 13:31:28 +1100, David Bannon wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> 
> Please unblock package tomboy-ng v0.36a
> 
> [ Reason ]
> Poor testing on my part lead to the use of bad colors for dark
> themes with version 0.36 currently in Bookworm. This relates to
> tomboy-ng's recent move to using Qt5 instead of gtk2 and,
> perhaps, my own person preference to not use dark themes.
> V0.36a is now uploaded and my sponsor requested I apply for an
> unblock.
> 
> [ Impact ]
> As several users of the version currently in Testing have advised
> me, with some dark themes, the existing version might display
> some text with the same color as the background. Not good.
> 
> [ Tests ]
> I have personally tested the proposed new version, 0.36a extensively.
> Similarly, some testing by end users has also taken place.
> 
> [ Risks ]
> All changes relate to text colors. No other application logic
> has changed.
> As no package depends on tomboy-ng, effects beyond tomboy-ng approach
> zero. In every case identified, the 0.36a delivers the same or better
> user experience.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I initiated and reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ]
> Attached is a debdiff between 0.36 and 0.36a, quite a lot of its
> content relates to the Lazarus IDE's making inconsequential of
> changes to po and form files. Of significance is changes to
> man pages (better description of how to manage it's Qt5 colors)
> and editbox.pas where the means of determining appropriate
> colors has been changed. Changes to settings.pas to inform user
> of non-standard colors and save preferences.
> Some related minor change to loadnote.pas and mainform.pas
> 
> Thanks for your consideration, David Bannon
> 
> unblock tomboy-ng 0.36a
> 
> 

> diff -Nru tomboy-ng-0.36/debian/changelog tomboy-ng-0.36a/debian/changelog
> --- tomboy-ng-0.36/debian/changelog   2023-02-22 20:45:26.0 +1100
> +++ tomboy-ng-0.36a/debian/changelog  2023-03-19 10:08:23.0 +1100
> @@ -1,19 +1,12 @@
> -tomboy-ng (0.36-1) unstable; urgency=medium
> +tomboy-ng (0.36a-1) unstable; urgency=medium
>  
> -  *  Release of new version
> -  * From 0.35 to 0.36 -
> -  * New Feature export as PDF.
> -  * New Feature insert a symbol or accented character.
> -  * Bug fix in column mode of calculator.
> -  * Warn user about setting non mono font.
> -  * All Tomdroid functionality removed.
> -  * A fix for SWYT not finding some text in a brand new note.
> -  * Can set colour of a link, more suitable default.
> -  * Use of TextHint to better indicate EditSearch role.
> -  * Revised note button colors for better dark theme use.
> -  * Please see github for further change details
> +  *  Release of new version.
> +  * More uniform colors when used with qt5ct.
> +  * Man page added info re colors.
> +  * Indicator that custom colors being used.
> +  * Please see github for further change details.
>  
> - -- David Bannon   Wed, 22 Feb 2023 20:45:26 +1100
> + -- David Bannon   Sun, 19 Mar 2023 10:08:23 +1100

Why are you removing the old changelog entry?

Cheers

>  
>  tomboy-ng (0.35-2) unstable; urgency=medium
>  
> diff -Nru tomboy-ng-0.36/doc/tomboy-ng.1 tomboy-ng-0.36a/doc/tomboy-ng.1
> --- tomboy-ng-0.36/doc/tomboy-ng.12023-02-22 20:42:59.0 +1100
> +++ tomboy-ng-0.36a/doc/tomboy-ng.1   2023-03-19 10:01:36.0 +1100
> @@ -11,7 +11,7 @@
>  tomboy\-ng \- manage a collection of notes using a simple GUI markup
>  
>  .SH SYNOPSIS
> -tomboy\-ng  [\-h \-\-help] [\-\-debug\-sync]  [\-\-debug\-index] 
> [\-\-debug\-log=LOGFILE] [\-l \-\-lang=CC] [\-\-config\-dir=PATH_to_DIR] [\-o 
> PATH_to_NOTE] [\-\-open\-note=PATH_to_NOTE] [PATH_to_NOTE] [\-t 
> \-\-import\-txt=PATH_to_FILE] [\-m \-\-import\-md=PATH_to_FILE] [\-n 
> \-\-import\-note=PATH_to_NOTE] [\-\-title\-fname]
> +tomboy\-ng  [\-h \-\-help] [\-\-dark\-theme] [\-\-debug\-sync]  
> [\-\-debug\-index] [\-\-debug\-log=LOGFILE] [\-l \-\-lang=CC] 
> [\-\-config\-dir=PATH_to_DIR] [\-o PATH_to_NOTE] 
> [\-\-open\-note=PATH_to_NOTE] [PATH_to_NOTE] [\-t 
> \-\-import\-txt=PATH_to_FILE] [\-m \-\-import\-md=PATH_to_FILE] [\-n 
> \-\-import\-note=PATH_to_NOTE] [\-\-title\-fname]
>  
>  .SH DESCRIPTION
>  tomboy\-ng is a rewrite of the much loved Tomboy Notes. It runs on Linux, 
> Windows and MacOS.  It  is  file  compatible  with  Tomdroid  and  GNote 
> (>=v0.30).  Tomboy\-ng notes support Bold, Italic, Strikethrough, Highlight 
> and Underline in four sizes. It will sync notes with other systems using 
> Tomboy's File Sync model and to remote servers using sshfs. It will Sync with 
> a Github account, either all your notes or just ones in the SyncGithub 
> notebook. You can edit notes, from almost any device with a browser in 
> markdown format.
> @@ -24,6 +24,20 

Bug#1033745: sequeler: Unlisted dependency on libgda-5.0-mysql

[Brian Vaughan]

Package: sequeler
Version: 0.8.0-1+b2
Severity: normal
X-Debbugs-Cc: bgvaug...@gmail.com

Without libgda-5.0-mysql installed, Sequeler will fail to connect to a MariaDB
database, with the error message, "No provider 'MySQL' installed".

sequeler 0.8.0-1+b2 lists libgda-5.0-4 as a dependency. libgda-5.0-4 suggests
libgda-5.0-bin, libgda-5.0-mysql, and libgda-5.0-postgres.

According to this upstream bug, sequeler should list as dependencies
libgda-5.0-mysql and libgda-5.0-postgres.
https://github.com/Alecaddd/sequeler/issues/26


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

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

Versions of packages sequeler depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libgda-5.0-4 5.2.10-3
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.74.6-1
ii  libgranite6  6.2.0-3
ii  libgtk-3-0   3.24.37-2
ii  libgtksourceview-3.0-1   3.24.11-2+b1
ii  libsecret-1-00.20.5-3
ii  libssh2-11.10.0-3+b1

sequeler recommends no packages.

sequeler suggests no packages.

-- no debconf information

Bug#1033744: reportbug: iperf [ 1.815355] pci 0000:00:1c.0: bridge window [mem 0x90500000-0x906fffff 64bit pref]

[js1]

Package: iperf
Version: 2.0.14a+dfsg1-1
Severity: normal
X-Debbugs-Cc: sujiannm...@gmail.com

Dear Maintainer,

   * What led up to the situation?
iperf -c x.x.x.x -d does not work
   * What exactly did you do (or not do) that was effective (orineffective)?
as the client (-c), bidirectional testing does not work.
as the server (-s) and using 2.1.x as client, bidirectional testing 
works as expected.
   * What was the outcome of this action?
only a single unidirectional test is run
   * What outcome did you expect instead?
-d should run two unidirectional test



-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages iperf depends on:
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6

iperf recommends no packages.

iperf suggests no packages.

-- no debconf information

Bug#1033743: [INTL:ro] Romanian debconf templates translation of tiger

[Remus-Gabriel Chelu]

Package: tiger
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «tiger» file.

Thanks,
Remus-Gabriel

tiger_debconf_ro.po
Description: Binary data

Bug#1033742: [PATCH] backport fix to keylisting operations to Debian Stable

[John Scott]

Source: gpgme1.0
Version: 1.14.0-1
Severity: normal
Tags: patch upstream bullseye
X-Debbugs-Cc: gni...@fsij.org

Hi,

Please consider uploading this to bullseye-proposed-updates. This is a
fix that allows the keylisting operations as documented. The regression
risk is extremely small and I wrote an autopkgtest that fails with the
old version and passes with the new.

I am CC'ing Gniibe since he authored the upstream change and he just so
happens to be a Debian Developer too; I'd be delighted if he would
sponsor this.

A patch is attached or you can pull in the OpenPGP-signed commit from
the debian-stable-fix branch of
https://salsa.debian.org/jscott/gpgme.git

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
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

From 611fab84c0b6b0156d4e5d0a72da2c420c5bdddc Mon Sep 17 00:00:00 2001
From: John Scott 
Date: Fri, 31 Mar 2023 12:19:03 -0400
Subject: [PATCH] Backport a fix to the keylisting operations and prepare for
 release to Bullseye

---
 debian/changelog  |  9 ++
 debian/copyright  |  4 +
 ...GPGME-keylist-from-data-ignores-sigs.patch | 88 +
 debian/patches/series |  1 +
 debian/tests/control  |  4 +
 debian/tests/find-signature-from-data.c   | 99 +++
 6 files changed, 205 insertions(+)
 create mode 100644 debian/patches/GPGME-keylist-from-data-ignores-sigs.patch
 create mode 100644 debian/tests/find-signature-from-data.c

diff --git a/debian/changelog b/debian/changelog
index c7bedbb9..9ab80b04 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+gpgme1.0 (1.14.0-1+deb11u1) bullseye; urgency=medium
+
+  [ John Scott ]
+  * Backport an upstream fix so that the functions for listing keys from data
+can return signature information if the application so requests.
+  * Add DEP-8 test ensuring that the fix works.
+
+ -- Debian GnuPG Maintainers   Fri, 31 Mar 2023 11:35:22 -0400
+
 gpgme1.0 (1.14.0-1) unstable; urgency=medium
 
   * new upstream release
diff --git a/debian/copyright b/debian/copyright
index d5b34af4..f2bdfdd4 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -10,6 +10,10 @@ Copyright:
   Werner Koch
 License: LGPL-2.1+
 
+Files: debian/tests/find-signature-from-data.c
+Copyright: 2023 John Scott 
+License: GPL-3+
+
 Files: src/argparse.*
 Copyright:
  1998-2001, 2006-2008, 2012 Free Software Foundation, Inc.,
diff --git a/debian/patches/GPGME-keylist-from-data-ignores-sigs.patch b/debian/patches/GPGME-keylist-from-data-ignores-sigs.patch
new file mode 100644
index ..f94b2035
--- /dev/null
+++ b/debian/patches/GPGME-keylist-from-data-ignores-sigs.patch
@@ -0,0 +1,88 @@
+Description: fix GPGME's keylisting from data functions ignoring request for signatures
+ When requesting signature information, the functions to iterate over keys in specified
+ data does not return it. This is an oversight corrected in this change. Note that
+ the majority of applications don't request signature information (the default); this
+ change only serves to benefit those that do request it and hadn't been getting it.
+Origin: upstream, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=patch;h=b2a2158384a9f048ff61ee0cebef8346055f0454
+Author: NIIBE Yutaka 
+Bug: https://dev.gnupg.org/T5438
+Applied-Upstream: 1.18.0, commit:b2a2158384a9f048ff61ee0cebef8346055f0454
+Reviewed-By: John Scott 
+Last-Update: 2023-03-31
+---
+
+--- gpgme1.0-1.14.0.orig/src/engine-backend.h
 gpgme1.0-1.14.0/src/engine-backend.h
+@@ -103,7 +103,8 @@ struct engine_ops
+ int secret_only, int reserved,
+ gpgme_keylist_mode_t mode,
+ int engine_flags);
+-  gpgme_error_t (*keylist_data) (void *engine, gpgme_data_t data);
++  gpgme_error_t (*keylist_data) (void *engine, gpgme_keylist_mode_t mode,
++ gpgme_data_t data);
+   gpgme_error_t (*keysign) (void *engine,
+ gpgme_key_t key, const char *userid,
+ unsigned long expires, unsigned int flags,
+--- gpgme1.0-1.14.0.orig/src/engine-gpg.c
 gpgme1.0-1.14.0/src/engine-gpg.c
+@@ -3115,7 +3115,7 @@ gpg_keylist_ext (void *engine, const cha
+
+
+ static gpgme_error_t
+-gpg_keylist_data (void *engine, gpgme_data_t data)
++gpg_keylist_data (void *engine, gpgme_keylist_mode_t mode, gpgme_data_t data)
+ {
+   engine_gpg_t gpg = engine;
+   gpgme_error_t err;
+@@ -3134,6 +3134,9 @@ gpg_keylist_data (void *engine, gpgme_da
+ err = add_arg 

Bug#1033607: sogo: /usr/bin/sogo linked against wrong version of libgnustep-base

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-03-28 14:45:24 +0200, Philipp Gruber wrote:
> Package: sogo
> Version: 5.0.1-4+deb11u1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> The binary of /usr/sbin/sogod contained in bullseye is linked to
> libgnustep-base.so.1.24.

Are you sure?

$ ldd -r /usr/sbin/sogod | grep gnustep-base
libgnustep-base.so.1.27 => /usr/lib/libgnustep-base.so.1.27 
(0x7f3b59898000)

Cheers

> However, the package depends on libgnustep-base.so.1.27,
> which is the current version of bullseye.
> 
> Downgrading is not possible due to dependencies. I assume re-building
> the binary with correct dependencies will fix this.
> 
> Kind regards,
> Phil
> 
> 
> -- System Information:
> Debian Release: 11.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB.UTF-8
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages sogo depends on:
> ii  adduser   3.118
> ii  gnustep-base-runtime  1.27.0-3
> ii  init-system-helpers   1.60
> ii  libc6 2.31-13+deb11u5
> ii  libcrypt1 1:4.4.18-4
> ii  libcurl4  7.74.0-1.3+deb11u3
> ii  libgcc-s1 10.2.1-6
> ii  libglib2.0-0  2.66.8-1
> ii  libgnustep-base1.27   1.27.0-3
> ii  liblasso3 2.6.1-3
> ii  libmemcached111.0.18-4.2
> ii  liboath0  2.6.6-3
> ii  libobjc4  10.2.1-6
> ii  libsbjson2.3  2.3.2-4+b2
> ii  libsodium23   1.0.18-1
> ii  libsope1  5.0.1-2
> ii  libssl1.1 1.1.1n-0+deb11u3
> ii  libzip4   1.7.3-1
> ii  lsb-base  11.1.0
> ii  memcached 1.6.9+dfsg-1
> ii  sogo-common   5.0.1-4+deb11u1
> ii  systemd   247.3-7+deb11u1
> ii  zip   3.0-12
> 
> sogo recommends no packages.
> 
> Versions of packages sogo suggests:
> ii  default-mysql-server1.0.7
> ii  mariadb-server-10.5 [virtual-mysql-server]  1:10.5.18-0+deb11u1
> 
> -- Configuration Files:
> /etc/sogo/sogo.conf [Errno 13] Permission denied: '/etc/sogo/sogo.conf'
> 
> -- no debconf information

-- 
Sebastian Ramacher

Bug#867523: ITP: golang-github-pkg-browser -- Package browser provides helpers to open files, readers, and urls in a browser window.

[Reinhard Tartler]

Hi Patrick,

I overlooked that you worked on this package in 2017. It appears that it
was never uploaded to Debian. Do you remember why? Was it rejected from
ftp-master for some reason or something?

I took the liberty of pushing my packaging attempt to salsa. Let me know if
you are still interested in this package and let me know what you think.

Best,
-rt

On Thu, Jul 6, 2017 at 9:42 PM root  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Patrick O'Doherty 
>
> * Package name: golang-github-pkg-browser
>   Version : 0.0~git20170505.0.c90ca0c-1
>   Upstream Author :
> * URL : https://github.com/pkg/browser
> * License : BSD-2-clause
>   Programming Lang: Go
>   Description : provides helpers to open files, readers, and urls in a
> browser window.
>
>  Package browser provides helpers to open files, readers, and URLs in a
> browser window.
>
>

-- 
regards,
Reinhard

Bug#1033741: libelfin: CVE-2023-24180

[Salvatore Bonaccorso]

Source: libelfin
Version: 0.3-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/aclements/libelfin/issues/75
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libelfin.

CVE-2023-24180[0]:
| Libelfin v0.3 was discovered to contain an integer overflow in the
| load function at elf/mmap_loader.cc. This vulnerability allows
| attackers to cause a Denial of Service (DoS) via a crafted elf file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-24180
https://www.cve.org/CVERecord?id=CVE-2023-24180
[1] https://github.com/aclements/libelfin/issues/75

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033641: libseccomp failing to build from source on bookworm with python 3.11

[Felix Geyer]

On 29.03.23 10:28, Mayer, Dirk wrote:

make[3]: Nothing to be done for 'install-data-am'.

/usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip 
and other standards-based tools.

   warnings.warn(

/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:146: 
EasyInstallDeprecationWarning: easy_install command is deprecated. Use build 
and pip and other standards-based tools.

   warnings.warn(

TEST FAILED: 
/work/tmp/libseccomp_2.5.4-1/libseccomp-2.5.4/debian/tmp//usr/lib/python3.11/site-packages/
 does NOT support .pth files


This seems to happen because you have python3-setuptools installed but 
libseccomp doesn't
build-depend on it.
You should always build Debian packages in a minimal chroot.

libseccomp uses distutils but the setuptools packages replaces the distutils 
module which
results in this error.
If you uninstall python3-setuptools the build should run fine.


Once libseccomp switches to setuptools we need to fix the underlying problem 
though so I leave
this bug open.

Best regards,
Felix

Bug#1033515: NMU: wit: autopkgtest regression: [[: not found

[Aloïs Micard]

Hello Bastian,

While I'm not active in Debian lately I keep monitoring my packages.
I dunno why this bug slip under my radar but I'm grateful you fixed it.

Have a nice one.

Cheers,

On 29/03/2023 22:41, Bastian Germann wrote:

I have just uploaded a NMU to fix this. debdiff is attached.


--
⢀⣴⠾⠻⢶⣦⠀  Aloïs Micard
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://creekorful.org
⠈⠳⣄  DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#1033740: linphone crashed when receiving a phone call

[Marco d'Itri]

Package: linphone-desktop
Version: 4.4.10-2+b2
Severity: normal

(gdb) where
#0  0x7f39af58281c in pulse_card_create_writer (card=)
at ./src/audiofilters/pulseaudio.c:859
#1  0x7f39af57c22c in ring_start_with_cb
(factory=0x558b0cac2330, file=0x558b0ca762e0 
"/usr/share/sounds/linphone/rings/oldphone-mono.wav", interval=, 
sndcard=0x558b0caa8780, func=0x7f39ae9eed30 , user_data=0x558b0c9fa7e0) at 
./src/voip/ringstream.c:80
#2  0x7f39ae9eee06 in linphone_ringtoneplayer_start_with_cb(MSFactory*, 
LinphoneRingtonePlayer*, MSSndCard*, char const*, int, 
LinphoneRingtonePlayerFunc, void*)
(factory=0x558b0cac2330, rp=0x558b0c9fa7e0, card=0x558b0caa8780, 
ringtone=0x558b0ca762e0 "/usr/share/sounds/linphone/rings/oldphone-mono.wav", 
loop_pause_ms=2000, end_of_ringtone=end_of_ringtone@entry=0x0, user_data=0x0)
at ./coreapi/ringtoneplayer.c:103
#3  0x7f39ae9eee8e in linphone_ringtoneplayer_start(MSFactory*, 
LinphoneRingtonePlayer*, MSSndCard*, char const*, int)
(factory=, rp=, card=, 
ringtone=, loop_pause_ms=)
at ./coreapi/ringtoneplayer.c:28
#4  0x7f39ae7ae2a5 in 
LinphonePrivate::ToneManager::notifyIncomingCall(std::shared_ptr
 const&)
(this=this@entry=0x558b0ca6a830, 
session=std::shared_ptr (use count 5, weak count 
1) = {...})
at ./src/conference/session/tone-manager.cpp:537
--Type  for more, q to quit, c to continue without paging--c
#5  0x7f39ae7af574 in 
LinphonePrivate::ToneManager::notifyState(std::shared_ptr
 const&, LinphonePrivate::CallSession::State)
(this=this@entry=0x558b0ca6a830, 
callSession=std::shared_ptr (use count 5, weak 
count 1) = {...}, 
state=state@entry=LinphonePrivate::CallSession::State::IncomingReceived)
at ./src/conference/session/tone-manager.cpp:666
#6  0x7f39ae7974c9 in 
LinphonePrivate::MediaSessionPrivate::setState(LinphonePrivate::CallSession::State,
 std::__cxx11::basic_string, std::allocator 
> const&)
(this=this@entry=0x558b0c27de00, 
newState=newState@entry=LinphonePrivate::CallSession::State::IncomingReceived, 
message="Incoming call received")
at ./src/conference/session/media-session.cpp:811
#7  0x7f39ae78bb75 in 
LinphonePrivate::CallSessionPrivate::startIncomingNotification() 
(this=0x558b0c27de00)
at ./src/conference/session/call-session.cpp:210
#8  0x7f39ae70d25f in LinphonePrivate::Call::startIncomingNotification()
(this=) at ./src/call/call.cpp:181
#9  0x7f39ae84fbee in 
LinphonePrivate::SalCallOp::processRequestEventCb(void*, 
belle_sip_request_event const*)
(userCtx=0x558b105e8160, event=)
at ./src/sal/call-op.cpp:952
#10 0x7f39ae861f4e in LinphonePrivate::Sal::processRequestEventCb(void*, 
belle_sip_request_event const*) (userCtx=, event=0x7ffd454d2ee0)
at ./src/sal/sal.cpp:267
#11 0x7f39ad2efd7e in belle_sip_provider_dispatch_request
(req=0x558b10e34250, prov=) at ./src/provider.c:183
#12 belle_sip_provider_dispatch_message
(prov=, msg=0x558b10e34250) at ./src/provider.c:297
#13 0x7f39ad2ce4b5 in notify_incoming_messages (obj=0x558b11c66650)
at ./src/channel.c:534
#14 belle_sip_channel_process_stream
(obj=obj@entry=0x558b11c66650, eos=eos@entry=0) at ./src/channel.c:640
#15 0x7f39ad2d07ab in belle_sip_channel_process_read_data
(obj=0x558b11c66650) at ./src/channel.c:678
#16 belle_sip_channel_process_data
(obj=obj@entry=0x558b11c66650, revents=revents@entry=1)
at ./src/channel.c:703
#17 0x7f39ad2f8592 in on_udp_data (lp=0x558b0ccfedd0, events=1)
at ./src/transports/udp_listeningpoint.c:207
#18 0x7f39ad2c1af8 in belle_sip_main_loop_iterate (ml=0x558b0ca969b0)
at ./src/belle_sip_loop.c:697
#19 belle_sip_main_loop_run (ml=0x558b0ca969b0) at ./src/belle_sip_loop.c:753
#20 0x7f39ad2c1fec in belle_sip_main_loop_sleep
(ml=0x558b0ca969b0, milliseconds=)
at ./src/belle_sip_loop.c:766
#21 0x7f39ae9d1d0f in LinphonePrivate::Sal::iterate()
(this=) at ./src/sal/sal.h:137
#22 linphone_core_iterate(LinphoneCore*) (lc=0x558b0ca69cb0)
at ./coreapi/linphonecore.c:4121
#23 0x558b0b0eef06 in CoreManager::iterate() (this=0x558b0c5dd130)
at ./linphone-app/src/components/core/CoreManager.cpp:426
#24 0x7f39ae0e8f4f in QtPrivate::QSlotObjectBase::call(QObject*, void**)
(a=0x7ffd454d42a0, r=0x558b0c5dd130, this=0x558b0cc95050)
at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#25 doActivate(QObject*, int, void**)
(sender=0x558b0ccfef00, signal_index=3, argv=0x7ffd454d42a0)
at kernel/qobject.cpp:3923
#26 0x7f39ae0e21ef in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**)
(sender=, m=m@entry=0x7f39ae34c2e0 
, local_signal_index=local_signal_index@entry=0, 
argv=argv@entry=0x7ffd454d42a0) at kernel/qobject.cpp:3983
#27 0x7f39ae0ecd6a in QTimer::timeout(QTimer::QPrivateSignal)
(this=, _t1=...) at .moc/moc_qtimer.cpp:205
#28 0x7f39ae0dd50d in QObject::event(QEvent*)
(this=0x558b0ccfef00, e=0x7ffd454d43f0) at 

Bug#1033739: unblock: libmath-bigint-perl/1.999838-1

[Roland Rosenfeld]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libmath-bigint-perl

In #1012704 and #1017042 (both "serious") there is a problem
mentioned, that ipcalc fails with libmath-bigint-perl 1.999835-1 and
1.999837-1.

This issue was forwarded upstream:
https://rt.cpan.org/Public/Bug/Display.html?id=146411

Upstream just debugged and fixed this issue with a new release
1.999838 with the following upstream changelog:

1.999838 2023-03-30

 * Fix CPAN RT #146411 regarding infinite recursion in bitwise operations. This
   happened when arguments were upgraded and downgraded and upgraded again ad
   infinitum. Add tests to verify the fix.

Upstream also added some test cases (that's why the patch is a little
bit bigger).

[ Reason ]
I solves RC bugs #1012704 and #1017042.

[ Impact ]
ipcalc and other programs may fail with old 1.999837-1.
libconvert-asn1-perl build-depends-indep libmath-bigint-perl, that's
why it is tagged key package.

[ Tests ]
The (updated) testsuite passes with the new package.
The ipcalc failures from the above RC bugs now pass.

[ Risks ]
According to https://udd.debian.org/cgi-bin/key_packages.yaml.cgi it
is a key package.

[ 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

[ Other info ]
I uploaded in behalf of the perl team.


unblock libmath-bigint-perl/1.999838-1

diff --git a/CHANGES b/CHANGES
index 4090295..42b8906 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,9 @@
+1.999838 2023-03-30
+
+ * Fix CPAN RT #146411 regarding infinite recursion in bitwise operations. This
+   happened when arguments were upgraded and downgraded and upgraded again ad
+   infinitum. Add tests to verify the fix.
+
 1.999837 2022-07-02
 
  * Improve the interoperability between objects of different classes for the
diff --git a/META.json b/META.json
index 553efcb..e7516ef 100644
--- a/META.json
+++ b/META.json
@@ -4,7 +4,7 @@
   "Peter John Acklam "
],
"dynamic_config" : 1,
-   "generated_by" : "ExtUtils::MakeMaker version 7.64, CPAN::Meta::Converter version 2.150010",
+   "generated_by" : "ExtUtils::MakeMaker version 7.70, CPAN::Meta::Converter version 2.150010",
"license" : [
   "perl_5"
],
@@ -50,6 +50,6 @@
  "web" : "https://github.com/pjacklam/p5-Math-BigInt;
   }
},
-   "version" : "1.999837",
-   "x_serialization_backend" : "JSON::PP version 4.09"
+   "version" : "1.999838",
+   "x_serialization_backend" : "JSON::PP version 4.16"
 }
diff --git a/META.yml b/META.yml
index 8f73b8b..c6f3b5e 100644
--- a/META.yml
+++ b/META.yml
@@ -7,7 +7,7 @@ build_requires:
 configure_requires:
   ExtUtils::MakeMaker: '6.58'
 dynamic_config: 1
-generated_by: 'ExtUtils::MakeMaker version 7.64, CPAN::Meta::Converter version 2.150010'
+generated_by: 'ExtUtils::MakeMaker version 7.70, CPAN::Meta::Converter version 2.150010'
 license: perl
 meta-spec:
   url: http://module-build.sourceforge.net/META-spec-v1.4.html
@@ -24,5 +24,5 @@ requires:
   perl: '5.006001'
 resources:
   repository: https://github.com/pjacklam/p5-Math-BigInt.git
-version: '1.999837'
+version: '1.999838'
 x_serialization_backend: 'CPAN::Meta::YAML version 0.018'
diff --git a/SIGNATURE b/SIGNATURE
index 1dd2231..8cda454 100644
--- a/SIGNATURE
+++ b/SIGNATURE
@@ -15,15 +15,15 @@ not run its Makefile.PL or Build.PL.
 Hash: RIPEMD160
 
 SHA256 961f8c23b6fc94cb9766265257dd548b190087df0c71dfd7d994bc649af5f002 BUGS
-SHA256 ff6e661bb85121620f7afce30a73f12cc1816ab0341b88647a446bafd9c58b38 CHANGES
+SHA256 9b432465325ff89dc74a6149b45f99c76a4184d4cf8220ca67a0eb8205c7d711 CHANGES
 SHA256 7d84c6e69ee6c3ab6301314d2fa4bc233f24bd36a4a546b2cfd05a078bda98b7 CREDITS
 SHA256 fd8f78318c23adef95971cc01ee0e79d68f52f60b761ba28129c8509fff46954 GOALS
 SHA256 28e80ee628ff111dd34a2a26af921693c9c823caadab30c848e4c4f4fc00830f HISTORY
 SHA256 b857edab549ac6893e2df5e1ec768ee46b62bcf1607a55e876f4d23f079eacce LICENSE
 SHA256 eff8d9db8aa0fe02bc74643e8fdea5aaf423cd885e67d1d046526b903d4397b8 MANIFEST
 SHA256 6cbc650165422bed661f292abb91ffaefa416830203a2aa8c790114ce6535cde MANIFEST.SKIP
-SHA256 304e19de0dded923fe216259e271491b1692d2c657266d66d7cced67f515ae30 META.json
-SHA256 f6ce709213efe573904d1586ea91302b4eabd970ef6bb673948bb46db4295571 META.yml
+SHA256 a1dc6acf784a5a6bb73f6b8ac1dfc6fcd83fbb55c9f8f5e0f035b82511d4f42c META.json
+SHA256 035d8a88fbc630bb729ecb63df5c6ca99d9fc3db8ee7b70627070e73e04b690f META.yml
 SHA256 053b2511fa5ac8e6141b5596d6777220ef257a5ddfda3f3ff7325907757660a7 Makefile.PL
 SHA256 99f7f7df45a00c9f19ad38edec8c5dad5f5977c2b1a14ac3bb491ac193db1f7d NEW
 SHA256 2aadb8383836311d8b47a34b7eb1c68043ccd5b90bfc2d9c57016b33579d2385 README
@@ -32,10 +32,10 @@ SHA256 546b67064f9314ed19382b6677bcbe699e774f5edcc31e6dc9567a2e54998eff TODO
 SHA256 77a80748e329a042faaa91eb0b44a493dfdfd726fec854a1a376c8404324b485 examples/1000.txt
 SHA256 

Bug#994442: (no subject)

[Tiago Bortoletto Vaz]

Hi, I tried to reproduce this issue without success. Please note that 1.0.5 has
been released.

Can you give me exact steps to reproduce it in 1.0.5 using the current version
of chainsaw?

Thanks.

--
Tiago Bortoletto Vaz

Bug#1033738: [INTL:ro] Romanian debconf templates translation of texlive-base

[Remus-Gabriel Chelu]

Package: texlive-base
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «texlive-base» file.

Thanks,
Remus-Gabriel

texlive-base_debconf_ro.po
Description: Binary data

Bug#1033284: apache2 2.4.56-1 redirects not normal working appeared %3f

[Robert Willert]

This Bug with $3f added is fixed in apache trunk r1908813.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66547

Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

[Isaac True]

Alternatively, this could be an environment variable to allow flash-kernel to 
run non-interactively on an EFI system (such as when installing/updating with 
apt, or after updating the initrd).

---

diff -Nru flash-kernel-3.106/debian/changelog 
flash-kernel-3.106+nmu1/debian/changelog
--- flash-kernel-3.106/debian/changelog 2022-04-22 23:55:41.0 +
+++ flash-kernel-3.106+nmu1/debian/changelog2023-03-31 14:28:23.0 
+
@@ -1,3 +1,10 @@
+flash-kernel (3.106+nmu1) UNRELEASED; urgency=medium
+
+  * Skip EFI detection mechanism when the FK_FORCE_EFI environment
+variable is set to "yes".
+
+ -- Isaac True   Fri, 31 Mar 2023 14:28:23 +
+
 flash-kernel (3.106) unstable; urgency=medium

   * db/all.db: Move MNT Reform 2 boards later to fix sort order.
diff -Nru flash-kernel-3.106/flash-kernel.8 
flash-kernel-3.106+nmu1/flash-kernel.8
--- flash-kernel-3.106/flash-kernel.8   2022-03-23 14:22:28.0 +
+++ flash-kernel-3.106+nmu1/flash-kernel.8  2023-03-31 14:28:11.0 
+
@@ -40,6 +40,10 @@
 .B choice of machine may cause host filesystem partitions to be mounted and
 .B modified.

+.IP FK_FORCE_EFI
+Skip EFI detection when this variable is set to `yes'. Normally, flash-kernel
+will abort if it detects that the system is running in EFI mode.
+
 .SH FILES
 .TP
 .B /usr/share/flash-kernel/db/all.db
diff -Nru flash-kernel-3.106/functions flash-kernel-3.106+nmu1/functions
--- flash-kernel-3.106/functions2022-04-12 19:43:15.0 +
+++ flash-kernel-3.106+nmu1/functions   2023-03-31 14:28:23.0 +
@@ -789,7 +789,7 @@
kfile=$(readlink -e "$kfile")
 fi

-if [ -d /sys/firmware/efi ]; then
+if [ -d /sys/firmware/efi ] && [ "x$FK_FORCE_EFI" != "xyes" ]; then
# skipping when detect EFI
echo "System running in EFI mode, skipping."
exit 0

Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

[Isaac True]

Package: flash-kernel
Version: 3.106
Severity: normal
File: flash-kernel
X-Debbugs-Cc: isaac@is.having.coffee

Dear Maintainer,

As part of our CI/CD system, we are building images for target devices.
The images are set up in virtual machines which boot using EFI, but
flash-kernel installation always fails as it detects that the system is
running in EFI by checking for the existence of /sys/firmware/efi. 

Being able to setup the image on these VMs is an important part of our
testing and validation workflow, so it would be very helpful to have an
option to skip this check and proceed regardless of whether the system
is currently running in EFI mode or not. 

I've added a debdiff for a proposal for a new parameter --force-efi
which can be set to skip this check.

---

diff -Nru flash-kernel-3.106/debian/changelog 
flash-kernel-3.106+nmu1/debian/changelog
--- flash-kernel-3.106/debian/changelog 2022-04-22 23:55:41.0 +
+++ flash-kernel-3.106+nmu1/debian/changelog2023-03-31 13:04:23.0 
+
@@ -1,3 +1,10 @@
+flash-kernel (3.106+nmu1) UNRELEASED; urgency=medium
+
+  * Skip EFI detection mechanism when the --force-efi option
+has been set.
+
+ -- Isaac True   Fri, 31 Mar 2023 13:04:23 +
+
 flash-kernel (3.106) unstable; urgency=medium

   * db/all.db: Move MNT Reform 2 boards later to fix sort order.
diff -Nru flash-kernel-3.106/flash-kernel.8 
flash-kernel-3.106+nmu1/flash-kernel.8
--- flash-kernel-3.106/flash-kernel.8   2022-03-23 14:22:28.0 +
+++ flash-kernel-3.106+nmu1/flash-kernel.8  2023-03-31 13:04:23.0 
+
@@ -3,7 +3,7 @@
 .SH NAME
 flash-kernel \- put kernel and initramfs in boot location
 .SH SYNOPSIS
-.B flash-kernel [--supported] [--force] [kvers]
+.B flash-kernel [--supported] [--force] [--force-efi] [kvers]
 .SH DESCRIPTION
 flash-kernel is a script which will put the kernel and initramfs in
 the boot location of embedded devices that don't load the kernel and
@@ -25,6 +25,11 @@
 match. Valid filenames for images to flash are suffixed with the
 subarchitecture.
 .P
+Normally, flash\-\-kernel will abort the installation if it detects that
+it is running in an EFI-based environment. If the \-\-force\-efi option
+is used, flash\-kernel will skip this check and continue with the
+installation.
+.P
 If the \-\-supported option is used, flash\-kernel will test to see if
 the hardware is supported, and return a true or false value.
 .SH ENVIRONMENT VARIABLES
diff -Nru flash-kernel-3.106/functions flash-kernel-3.106+nmu1/functions
--- flash-kernel-3.106/functions2022-04-12 19:43:15.0 +
+++ flash-kernel-3.106+nmu1/functions   2023-03-31 13:04:23.0 +
@@ -679,6 +679,11 @@
force="yes"
shift
 fi
+force_efi="no"
+if [ "x$1" = "x--force-efi" ]; then
+   force_efi="yes"
+   shift
+fi
 if [ "x$1" = "x--machine" ]; then
machine="$2"
shift 2
@@ -789,9 +794,10 @@
kfile=$(readlink -e "$kfile")
 fi

-if [ -d /sys/firmware/efi ]; then
+if [ -d /sys/firmware/efi ] && [ "x$force_efi" != "xyes" ]; then
# skipping when detect EFI
echo "System running in EFI mode, skipping."
+   echo "Use --force-efi if you want to skip this check."
exit 0
 fi

Bug#1029218: dkms should perform reproducible build of modules

[Andreas Beckmann]

Control: tag -1 moreinfo

On Thu, 19 Jan 2023 15:51:25 -0500 "Daniel Richard G." 
 wrote:

If I install the same DKMS package on two identically-configured Debian
sid systems, the resulting kernel modules are not bit-for-bit identical.


Do you have an example how the kernel modules differ? diffoscope might 
help ...

Does this happen with all or only with certain dkms modules?

Is the build reproducible on the same host, e.g. does the sequence
dkms build
dkms unbuild
dkms build
produce binary identical modules?


Andreas

Bug#1033731: sbcl: support bootstrap on riscv64

[Bo YU]

Hi!

On Fri, Mar 31, 2023 at 6:00 PM John Paul Adrian Glaubitz
 wrote:
>
> Hello!
>
> On Fri, 2023-03-31 at 17:16 +0800, Bo YU wrote:
> > Sorry, the folder is wrong. The right folder is here:
> > https://drive.google.com/drive/folders/1c6AFD_EgGwXTbAiC_-1al6Gb_wBpfMpr
> What about 2.2.9? Has the bug not been fixed since 2.2.3?
Oh. It seems the 2.2.9 can be built with the sbcl(2.2.2-1) riscv64 package.
But, very odd:
```
...
SBCL has been installed:
 binary /<>/stage1/bin/sbcl
 core and contribs in /<>/stage1/lib/sbcl/

Documentation:
 man /<>/stage1/share/man/man1/sbcl.1
chmod 100 stage1 # Make stage 1 unreadable (only executable), to avoid
messing with the stage 2
./clean.sh
make[2]: Entering directory '/<>/tools-for-build'
make[2]: Leaving directory '/<>/tools-for-build'
make[2]: Entering directory '/<>/doc/manual'
rm -f *~ *.bak *.orig \#*\# .\#* texput.log *.fasl
rm -rf sbcl asdf "docstrings/"
rm -f  sbcl.html asdf.html
rm -f contrib-docs.texi-temp
rm -f package-locks.texi-temp
rm -f variables.texinfo
rm -f sbcl.ps asdf.ps sbcl.pdf asdf.pdf html-stamp tempfiles-stamp
rm -f asdf.aux asdf.cp asdf.cps asdf.fn asdf.fns asdf.ky asdf.log
asdf.pg asdf.toc asdf.tp asdf.tps asdf.vr asdf.vrs sbcl.aux sbcl.cp
sbcl.cps sbcl.fn sbcl.fns sbcl.ky sbcl.log sbcl.pg sbcl.toc sbcl.tp
sbcl.tps sbcl.vr sbcl.vrs
rm -f sbcl.info sbcl.info-* asdf.info
make[2]: Leaving directory '/<>/doc/manual'
make[2]: Entering directory '/<>/doc/internals'
rm -rf *.include *.info *.pdf *~ *.cp *.fn *.ky *.log *.pg *.toc \
*.tp *.vr *.aux *.eps *.png *.dvi *.ps *.txt *.fns \
html-stamp sbcl-internals/
make[2]: Leaving directory '/<>/doc/internals'
# Create stage 2
./make.sh --xc-host="/<>/stage1/bin/sbcl
--disable-debugger --no-sysinit --no-userinit" --prefix=/usr --fancy
make-config.sh: 237: /<>/stage1/bin/sbcl: not found
No working host Common Lisp implementation.
See ./INSTALL, the "SOURCE DISTRIBUTION" section
make[1]: *** [debian/rules:58: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:45: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Build finished at 2023-03-31T12:36:02Z

Finished



+--+
| Cleanup  |
+--+

Purging /<>
Not cleaning session: cloned chroot in use
E: Build failure (dpkg-buildpackage died)

+--+
| Summary  |
+--+

Build Architecture: riscv64
Build Type: binary
Build-Space: 45904
Build-Time: 2247
Distribution: UNRELEASED
Fail-Stage: build
Host Architecture: riscv64
Install-Time: 559
Job: /home/rv/build/sbcl/2.2.9/sbcl_2.2.9-1.1.dsc
Machine Architecture: riscv64
Package: sbcl
Package-Time: 2908
Source-Version: 2:2.2.9-1.1
Space: 45904
Status: attempted
Version: 2:2.2.9-1.1

```
Nothing change other than B-D and ifeq.

BR,
Bo

Bug#1033617: libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev

[Andreas Metzler]

Control: tags -1 confirmed patch

On 2023-03-28 Felix Stupp  wrote:
> Package: libopenexr-dev
> Version: 3.1.5-4
> Severity: serious
> Justification: Policy 7.4
> X-Debbugs-Cc: me+debian-b...@banananet.work

> Dear Maintainer,

> I cannot upgrade this package from version 2.5.7-1 to version 3.1.5-4
> due to a file conflict with the package libilmbase-dev on version
[...]

Thank you Felix! dist-upgrading from libopenexr{25,-dev} 2.5.7-1 and
libilmbase{25,-dev} 2.5.7-2+b1 fails with

Preparing to unpack .../libopenexr-dev_3.1.5-4_amd64.deb ...
Unpacking libopenexr-dev (3.1.5-4) over (2.5.7-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libopenexr-dev_3.1.5-4_amd64.deb (--unpack):
 trying to overwrite '/usr/include/OpenEXR/Iex.h', which is also in package 
libilmbase-dev:amd64 2.5.7-2+b1

due to the versioning of the Breaks:/Replaces which was not binNMU-safe:
ametzler@argenau:/tmp$ dpkg --info 
/var/cache/apt/archives/libopenexr-dev_3.1.5-4_amd64.deb  | grep 'Breaks\|Repl'
 Breaks: libilmbase-dev (<= 2.5.7-2)
 Replaces: libilmbase-dev (<= 2.5.7-2)

I think 2.5.7-2 was the last sourceful < 3 upload, so (<< 2.5.7-3)
should work.

---
diff --git a/debian/changelog b/debian/changelog
index 9c5fae4..fa9c263 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+openexr (3.1.5-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Make versioning of libilmbase-dev Breaks/Replaces binNMU-safe.
+Closes: #1033617
+
+ -- Andreas Metzler   Fri, 31 Mar 2023 15:02:17 +0200
+
 openexr (3.1.5-4) unstable; urgency=medium

   * d/control: Add missing zlib1g-dev dependency. Closes: #1017516
diff --git a/debian/control b/debian/control
index 5fecc23..3d783c2 100644
--- a/debian/control
+++ b/debian/control
@@ -49,8 +49,8 @@ Package: libopenexr-dev
 Section: libdevel
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
-Replaces: libilmbase-dev (<= 2.5.7-2)
-Breaks: libilmbase-dev (<= 2.5.7-2)
+Replaces: libilmbase-dev (<< 2.5.7-3)
+Breaks: libilmbase-dev (<< 2.5.7-3)
 Depends: libimath-dev (>= 3.1.2),
  libopenexr-3-1-30 (= ${binary:Version}),
  zlib1g-dev,
--

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1030200: linux-image-6.1.0-3-amd64: .platform keyring (EFI DB variable) no longer trusted to sign modules, regression against 6.0

[наб]

https://salsa.debian.org/kernel-team/linux/-/merge_requests/691

наб


signature.asc
Description: PGP signature

Bug#1033704: unblock: ikiwiki-hosting/0.20220716-2

[Emilio Pozuelo Monfort]

Hi Simon,

On 30/03/2023 19:15, Simon McVittie wrote:

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

Please unblock package ikiwiki-hosting


The package is not blocked at this stage in the freeze as it's not a key package 
and has autopkgtests. However I have added an unblock hint anyway and aged it a bit.


Cheers,
Emilio

Bug#1033671: MD5File() goes into an unconditional infinite loop on bullseye

[Guillem Jover]

Control: fixed -1 0.11.4-1
Control: severity -1 serious

On Wed, 2023-03-29 at 20:51:07 +0200, Guillaume Morin wrote:
> Package: libbsd0
> Version: 0.11.3-1
> Tags: patch,upstream,fixed-upstream,bullseye

> MD5File in bullseye is essentially an infinite loop. It just calls
> itself.
> 
> The simplest fix is
> 
> --- a/src/md5.c
> +++ b/src/md5.c
> @@ -105,7 +105,7 @@
>  MD5File(const char *filename, char *buf)
>  {
> libmd_wrapper(MD5File);
> -   return MD5File(filename, buf);
> +   return libmd_MD5File(filename, buf);
>  }
>  
>  char *
> 
> This was fixed upstream by 
> https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888

Ah, nice catch! I think I missed that during the switch. I'll be
preparing a stable update later today to propose to the release team.

Thanks,
Guillem

Bug#1033736: ITP: golang-github-pkg-browser -- Package browser provides helpers to open files, readers, and urls in a browser window.

[No reply]

Здравствуйте!

Сообщения, пришедшие на адрес no-re...@decast.com не обрабатываются.
Пожалуйста, уточните получателя и повторно отправьте ему Ваше сообщение.

С уважением,
Decast group

-
Hello!

Messages that delivered to the address no-re...@decast.com not processed.

Please check the recipient's address and send them your message again.

Sincerely,
Decast group

Bug#1033735: ITP: golang-github-jellydator-ttlcache -- An in-memory cache with item expiration and generics

[No reply]

Здравствуйте!

Сообщения, пришедшие на адрес no-re...@decast.com не обрабатываются.
Пожалуйста, уточните получателя и повторно отправьте ему Ваше сообщение.

С уважением,
Decast group

-
Hello!

Messages that delivered to the address no-re...@decast.com not processed.

Please check the recipient's address and send them your message again.

Sincerely,
Decast group

Bug#1033736: ITP: golang-github-pkg-browser -- Package browser provides helpers to open files, readers, and urls in a browser window.

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-pkg-browser
  Version : 0.0~git20210911.681adbf-1
  Upstream Author : 
* URL : https://github.com/pkg/browser
* License : BSD-2-clause
  Programming Lang: Go
  Description : Package browser provides helpers to open files, readers, 
and urls in a browser window.

This golang helper library provides helpers to open files, readers, and
urls in a browser window. It is a build dependency of
golang-github-sigstore-sigstore, cf. #1029170

Bug#1025069: pavucontrol

[Lucas]

Here's a correction:  I shutdown and started it again, and the
pavucontrol setup was retained.  So, I continued testing by running
ardour, knowing it's set to use JACK through ALSA.  It played fine,
but when I quit it, I wasn't able to hear pulseaudio, nor select the
same pavucontrol profile.  Luckily, there's a "Pro Audio"
Configuration in pavucontrol that works too.  I retested ardour with
it and later standard pulseaudio playback, and it continues to work!
I wouldn't say this is fixed, but I consider it much improved, by
these findings, and almost tolerable.

Bug#1033735: ITP: golang-github-jellydator-ttlcache -- An in-memory cache with item expiration and generics

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-jellydator-ttlcache
  Version : 3.0.1-1
  Upstream Author : Jellydator
* URL : https://github.com/jellydator/ttlcache
* License : Expat
  Programming Lang: Go
  Description : An in-memory cache with item expiration and generics

This is a build dependency of golang-github-sigstore-sigstore, cf. #1029170

Bug#1033637: Aw: Re: Bug#1033637: linux: amdgpu - External displays connected through Thinkpad Ultra Dock not turn on after suspend

[Stefan K]

Hi,

when I searching my error message I got a lot of hits..
In arch it's solved:
https://bugs.archlinux.org/task/76934

the patch:
https://gitlab.freedesktop.org/superm1/linux/-/commit/2145b4de3fea9908cda6bef0693a797cc7f4ddfc.patch


> Gesendet: Donnerstag, 30. März 2023 um 15:37 Uhr
> Von: "Diederik de Haas" 
> An: "Stefan K" , 1033...@bugs.debian.org
> Betreff: Re: Bug#1033637: linux: amdgpu - External displays connected through 
> Thinkpad Ultra Dock not turn on after suspend
>
> Control: found -1 6.1.20-1
> 
> > > Unstable has version 6.1.20-1, can you test whether the issue is present
> > > there too?
> > Yes, it still happens with 6.1.20-1..
> 
> Updating metadata accordingly
> 
> On Thursday, 30 March 2023 14:46:51 CEST Stefan K wrote:
> > With Kernel 6.0.0-0.deb11.6-amd64 it works fine
> 
> Shouldn't that be 6.1.0-0.deb11.6-amd64?
> Which would be the bullseye-backports kernel for version 6.1.15-1.
> 
> On https://snapshot.debian.org/binary/linux-image-amd64/ you can find 
> compiled 
> debs of various kernel kernel versions. The goal is to figure out what the 
> last 
> kernel was that worked properly and the first one that does not.
> 
> As a first test, I would like you to try 6.1~rc3-1~exp1.
> If that version also has the issue, then it's useful to test 6.0-1~exp1.
> If 6.0-1~exp1 does NOT have the issue, but 6.1~rc3~exp1 then we know that the 
> issue was introduced in the 6.1 'merge window'.

Bug#1033733: vkd3d: new upstream release 1.7

[Simon McVittie]

Control: tags -1 + patch

On Fri, 31 Mar 2023 at 10:58:46 +0100, Simon McVittie wrote:
> vkd3d has a new upstream release available, v1.7. It would be great
> to have that version in experimental, or in unstable after bookworm
> is released.
> 
> I need .deb packages of this version for a work project, so I've been
> looking at updating the packaging used for Debian as a starting point
> for that, and I'll send a merge request when I have it working.

Please consider merging this:

  https://salsa.debian.org/smcv-guest/vkd3d wip/1.7

I used `uscan --download` to get the orig.tar.* I used for test-builds.

Errata: I'm getting test failures when I run the build-time tests on my
development laptop (Debian unstable, Intel UHD Graphics 620, Mesa 22.3.6),
although those failing tests are skipped when I do the build in a chroot
or a podman container. I wonder whether it would be more honest to disable
the build-time tests completely, since they're clearly not providing much
coverage in practice: the majority of them are skipped when using Debian's
production infrastruction (sbuild).

For the moment, I've left the build-time tests enabled in my branch,
and continued with the maintainers' approach of disabling tests in
situations where they're clearly not going to work.

Thanks,
smcv

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[James Addison]

Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: fierel...@gmail.com

Hi Fierelier - thanks for your previous comment, here's my reply, slightly
later than I'd hoped:

On Wed, 29 Mar 2023 00:10:52 +0200, Fierelier wrote:
> - issue 1: i386, i486, i586, i686 are considered as Pentium 4 in LLVM,
> which might be relevant if Rust is compiled with it:
> https://github.com/llvm/llvm-project/issues/61347

Yep, this is relevant.

Debian does currently use LLVM for rustc builds, yep.  Along the way I found
the rustc build README.Debian[1] that's a very useful explanatory guide.

To be slightly more specific, currently LLVM 14 is in use, and some of the
build options for it (including that version number[2]) are placed into a
config.toml[3] file that's used by the rustc build process (x.py).

Included in Debian's patches for the LLVM 14 toolchain is a patch to adjust
the Pentium 4 target you mention down to i686:

https://sources.debian.org/src/llvm-toolchain-14/1%3A14.0.6-12/debian/patches/clang-baseline-fix-i386.patch

> - issue 2: Rust considers i686 as Pentium 4, and i586 as Pentium:
> https://github.com/rust-lang/rust/issues/82435

Also relevant, yep.  Some of the comments, and the current title that I read
for that thread ("i686 target spec disagrees with downstream definitions")
discuss the core of the problem here.

There are reasons for some people to want the definition of i686 to shift
forward, perhaps towards the bulk of the processors within that family that
are in everyday use.

And there are reasons to want to keep the definition to its original, most
compatible specification (although as found on my NOPL learnings, even in the
early days of the P6 there was some divergence there).

I don't like neither wasted CPU time, nor wasted electricity, nor wasted human
time spent reading and understanding these issues, but it's difficult (for me,
at least) to see a remedy that is optimal for all of those.  Even writing an
additional paragraph about this introduces overhead for future readers.

> - When building the Rust toolchain itself, if Debian uses LLVM for it,
> it might be a good idea to set the CPU target explicitly to pentiumpro
> in LLVM's flags (fix issue 1) (It could also be a good idea to set
> this for LLVM in general if possible, if not already done so). -- Also
> compile the i586 Rust toolchain, not the i686 one (fix issue 2).

It looks like that CPU target adjustment suggestion was accepted in #908561 in
September Y2018.

For my investigation regarding the presence of NOPL -- an instruction that is
unavailable[4] on a limited number of i686 CPUs -- reducing that target further
to from "pentiumpro" to "i686" appears to resolve the issue.

That, I expect, also has the side-effect of omitting MMX instructions from the
set of valid instructions that the Debian i386 Rust toolchain may output.  So
there is at least one downside there.

My personal preference, that may or may not be aligned with Debian, is that
switching to build from the Rust i586 toolchain, while it would be a valid fix,
could cause confusion; it'd be a form of ecosystem fragmentation, and puzzling
for humans in particular to reason about.

Arguably that could be worthwhile puzzlement -- "why do Debian's Rust packages
and libraries refer to i586?", followed by learning about the situation and
knowledge spreading.  Is that better than referring to i686 as with other
toolchains within Debian, yet having some divergence from what upstream's i686
means?

In honesty, I don't know.  But I would like people who install Debian i386 on
all systems within Debian's i386 baseline to be able to use those computers and
the Debian-packaged software as intended, as completely as possible, and to me
it feels like changing the policy baseline or changing to i586 are beyond my
skills (certainly in time for bookworm), so I'm offering the best option that I
can.

Thanks again,
James

[1] - 
https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/README.Debian/#L28-L32

[2] - https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/rules/#L31

[3] - 
https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/config.toml.in/#L30-L43

[4] - https://bugzilla.redhat.com/show_bug.cgi?id=579838#c32

Bug#1025069: Roland STUDIO-CAPTURE Multichannel

[Lucas]

I had been happily using my Roland STUDIO-CAPTURE on recent kernels
with only minor changes to /etc/pulse/daemon.conf:
default-sameple-format = S24LE
default-sample-rate = 96000

After upgrading to bookworm and away from pure pulseaudio to
pipewire-pulse (on wireplumber) I only have "Dummy Output" selectable
in Gnome's Settings.
I have modified what I could from 48000 rates to 96000 in
/usr/share/pipewire, but that didn't solve it (and I can't seem to
find a global setting for sample format).  Prior to that, I'd tried
setting the STUDIO-CAPTURE's own rate to 48000 Hz, without change to
Gnome Settings' "Dummy Output" option only.

What does seem to have worked (for now) is running pavucontrol and
setting the Configuration tab's STUDIO-CAPTURE Profile to MultiChannel
Output (or selecting it as the default device for the Input and Output
tabs).  I haven't rebooted yet, though, and I think I'll be needing to
set it again after every boot, as after setting it, it changes Gnome
Settings' "Output Device" to nothing and is greyed out.  The "Input
Device" there may be changed to "Analog Input - STUDIO-CAPTURE", but
that reverts to the "Dummy Output" and no audio.

I think it may have to do with the STUDIO-CAPTURE's many outputs, but
I'm not sure where to set that, aside from possibly creating a device
definition, which pulseaudio alone didn't require.

Here's my pactl list sinks output after pavucontrol sets it up
working, if it helps:
Sink #470
State: RUNNING
Name: 
alsa_output.usb-Roland_STUDIO-CAPTURE_STCP80008c08d018c010005040a0d0c4-01.multichannel-output
Description: STUDIO-CAPTURE Multichannel
Driver: PipeWire
Sample Specification: s32le 10ch 96000Hz
Channel Map: aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9
Owner Module: 4294967295
Mute: no
Volume: aux0: 65536 / 100% / 0.00 dB,   aux1: 65536 / 100% / 0.00
dB,   aux2: 65536 / 100% / 0.00 dB,   aux3: 65536 / 100% / 0.00 dB,
aux4: 65536 / 100% / 0.00 dB,   aux5: 65536 / 100% / 0.00 dB,   aux6:
65536 / 100% / 0.00 dB,   aux7: 65536 / 100% / 0.00 dB,   aux8: 65536
/ 100% / 0.00 dB,   aux9: 65536 / 100% / 0.00 dB
balance 0.00
Base Volume: 65536 / 100% / 0.00 dB
Monitor Source:
alsa_output.usb-Roland_STUDIO-CAPTURE_STCP80008c08d018c010005040a0d0c4-01.multichannel-output.monitor
Latency: 0 usec, configured 0 usec
Flags: HARDWARE DECIBEL_VOLUME LATENCY
Properties:
alsa.card = "3"
alsa.card_name = "STUDIO-CAPTURE"
alsa.class = "generic"
alsa.device = "0"
alsa.driver_name = "snd_usb_audio"
alsa.id = "USB Audio"
alsa.long_card_name = "Roland STUDIO-CAPTURE at
usb-:05:00.0-4, high speed"
alsa.name = "USB Audio"
alsa.resolution_bits = "32"
alsa.subclass = "generic-mix"
alsa.subdevice = "0"
alsa.subdevice_name = "subdevice #0"
api.alsa.card.longname = "Roland STUDIO-CAPTURE at
usb-:05:00.0-4, high speed"
api.alsa.card.name = "STUDIO-CAPTURE"
api.alsa.path = "hw:3"
api.alsa.pcm.card = "3"
api.alsa.pcm.stream = "playback"
audio.channels = "10"
audio.position = "AUX0,AUX1,AUX2,AUX3,AUX4,AUX5,AUX6,AUX7,AUX8,AUX9"
card.profile.device = "3"
device.api = "alsa"
device.class = "sound"
device.id = "43"
device.profile.description = "Multichannel"
device.profile.name = "multichannel-output"
device.routes = "0"
factory.name = "api.alsa.pcm.sink"
media.class = "Audio/Sink"
device.description = "STUDIO-CAPTURE"
node.name =
"alsa_output.usb-Roland_STUDIO-CAPTURE_STCP80008c08d018c010005040a0d0c4-01.multichannel-output"
node.nick = "STUDIO-CAPTURE"
node.pause-on-idle = "false"
object.path = "alsa:pcm:3:hw:3:playback"
priority.driver = "1000"
priority.session = "1000"
factory.id = "18"
clock.quantum-limit = "8192"
client.id = "53"
node.driver = "true"
factory.mode = "merge"
audio.adapt.follower = ""
library.name = "audioconvert/libspa-audioconvert"
object.id = "42"
object.serial = "470"
node.max-latency = "16384/96000"
api.alsa.period-size = "512"
api.alsa.period-num = "64"
api.alsa.headroom = "512"
api.acp.auto-port = "false"
api.acp.auto-profile = "false"
api.alsa.card = "3"
api.alsa.use-acp = "true"
api.dbus.ReserveDevice1 = "Audio3"
device.bus = "usb"
device.bus-id =
"usb-Roland_STUDIO-CAPTURE_STCP80008c08d018c010005040a0d0c4-01"
device.bus_path = "pci-:05:00.0-usb-0:4:1.1"
device.enum.api = "udev"
device.icon_name = "audio-card-analog-usb"
device.name =
"alsa_card.usb-Roland_STUDIO-CAPTURE_STCP80008c08d018c010005040a0d0c4-01"
device.nick = "STUDIO-CAPTURE"
device.plugged.usec = "19929357"
device.product.id = 

Bug#1032270: regression in --req-cn option

[Dennis Camera]

Dear Bastian,

I noticed that you applied the patch I suggested for #995156.

Is there any chance you could also apply the patch I posted in my last
message to address this bug?

Since I use the --req-cn option in our production PKI, it not working
would block us from upgrading to bookworm once it is released.

Thank you very much for your efforts in advance.
Kind regards,
Dennis

Bug#1033734: munin-plugins-core: nginx_*: example configuration does not work with ipv6 localhost

[Helmut Grohne]

Package: munin-plugins-core
Version: 2.0.67-3
Tags: patch

Hi,

I noticed that the example configuration included in the nginx_* plugins
does not work. Nowadays, localhost tends to resolve to ::1 and with the
example configuration, this yields an error. Thus, it would be good to
also listen on the ipv6 loopback to make it work. I'm attaching a patch.

Helmut
--- munin-2.999.16.orig/plugins/node.d/nginx_request
+++ munin-2.999.16/plugins/node.d/nginx_request
@@ -22,11 +22,13 @@ compiled, and secondly it must be config
 
   server {
 listen 127.0.0.1;
+listen [::1];
 server_name localhost;
 location /nginx_status {
 stub_status on;
 access_log   off;
 allow 127.0.0.1;
+allow ::1;
 deny all;
 }
   }
--- munin-2.999.16.orig/plugins/node.d/nginx_status
+++ munin-2.999.16/plugins/node.d/nginx_status
@@ -21,11 +21,13 @@ compiled, and secondly it must be config
 
   server {
 listen 127.0.0.1;
+listen [::1];
 server_name localhost;
 location /nginx_status {
 stub_status on;
 access_log   off;
 allow 127.0.0.1;
+allow ::1;
 deny all;
 }
   }

Bug#1033731: sbcl: support bootstrap on riscv64

[John Paul Adrian Glaubitz]

Hello!

On Fri, 2023-03-31 at 17:16 +0800, Bo YU wrote:
> Sorry, the folder is wrong. The right folder is here:
> https://drive.google.com/drive/folders/1c6AFD_EgGwXTbAiC_-1al6Gb_wBpfMpr

Thanks.

> > 
> > Did you build in a clean environment, i.e. using sbuild?
> Yeah, I used sbuild(with --extra-package options) to build it.
> I will gradually upgrade to 2.2.3(revert the commit) to see if this
> problem still exists.

What about 2.2.9? Has the bug not been fixed since 2.2.3?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1033733: vkd3d: new upstream release 1.7

[Simon McVittie]

Source: vkd3d
Version: 1.2-15
Severity: wishlist

vkd3d has a new upstream release available, v1.7. It would be great
to have that version in experimental, or in unstable after bookworm
is released.

I need .deb packages of this version for a work project, so I've been
looking at updating the packaging used for Debian as a starting point
for that, and I'll send a merge request when I have it working.

One thing to watch out for is that there is an ABI regression:
https://bugs.winehq.org/show_bug.cgi?id=54761
so packaging a new version will require the patch from that bug.

Thanks,
smcv

Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message

[Guy Durrieu]

Package: src:linux
Version: 6.1.20-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Up to now I worked with Linux 6.1.0-7-amd64, without any trouble. I just
installed Linux 6.1.0-7-amd64 and I get a kernel panic when launching it.

Here is a transcription of what appears on the screen (OCR on a screen 
picture,

I hope there are no remaining errors).


[ 0.117782] Kernel panic — not syncing: timer doesn’t work through 
Interrupt-

remapped I0-APIC
[ 0.117848] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-7-and64 #1 
Debian

6.1.20-1
[ 0.117913] Hardware name: Gigabyte Technology Co., Ltd. ABS50M-Gaming
3/AB350M-Gaming 3-CF, BIOS F50d 07/02/2020
[ 0.117982] Call Trace:
[ 0.118634] 
[ 0.118685] dump_stack_lvl+0x44/0x5c
[ 0.118143] panic+0x118/0x2ed
[ 0.118198] panic_if_irq_remap.cold+0x5/0x5
[ 0.118256] setup_I0_APIC+0x3db/0x64b
[ 0.118313] ? _raw_spin_unlock_irqrestore+0x23/0x40
[ 0.118372] ? clear_IO_APIC_pin+0x169/0x240
[ 0.118429] apic_intr_node_init+0x101/0x106
[ 0.118485] x86_late_time_init+0x20/0x34
[ 0.118542] start_kerne1+0x667/0x727
[ 0.118598] secondary_startup_64_no_verify+0xe5/0xeb
[ 0.118658] 
[ 0.118711] ---[ end Kernel panic - not syncing: timer doesn’t work through
Interrupt-remapped IO-APIC J---


Hope it helps.
Thanks in advance for your help.
Best regards.

-- Guy Durrieu


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: AB350M-Gaming 3
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F50d
board_vendor: Gigabyte Technology Co., Ltd.
board_name: AB350M-Gaming 3-CF
board_version: x.x


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

Kernel: Linux 6.1.0-6-amd64 (SMP w/4 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 linux-image-6.1.0-7-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod    30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-7-amd64 recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-7-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.06-8
pn  linux-doc-6.1   

Versions of packages linux-image-6.1.0-7-amd64 is related to:
ii  firmware-amd-graphics 20230210-4
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x    
pn  firmware-brcm80211    
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree    20230210-4
ii  firmware-misc-nonfree 20230210-4
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20230210-4
pn  firmware-samsung  
pn  firmware-siano    
pn  firmware-ti-connectivity  
pn  xen-hypervisor    

-- no debconf information

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

[Steve McIntyre]

On Thu, Mar 30, 2023 at 09:12:05AM -0700, Dima Kogan wrote:
>Pascal Hambourg  writes:
>
>> On 30/03/2023 at 01:21, Dima Kogan wrote:
>>> I had to turn off
>>> secure-boot and UEFI in the BIOS.
>>
>> Why ? What happens if UEFI boot is enabled ?
>
>If UEFI was enabled, the USB device isn't seen by the machine in its
>list of valid boot devices

Ugh, that sounds like a *particularly* crappy firmware bug then :-(
What boot options does the firmware list in that case?

Hmm, checking: 

https://www.dell.com/support/manuals/en-uk/latitude-14-5420-laptop/lati_5420_om/uefi-bios?guid=guid-892bb204-aa23-43e3-aa1f-0c2b66c0ddc3=en-us

the "Important Information" section looks like it might be relevant?

>> How did you prepare the USB drive ? What installation image did you
>> use (full file name and URL please) ?
>
>>From yesterday's email:
>
>  I downloaded this:
>
>debian-bookworm-DI-alpha2-amd64-netinst.iso
>
>  from here:
>
>https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/
>
>  and I wrote that .iso to /dev/sde
>
>I did "cp debian-bookworm-DI-alpha2-amd64-netinst.iso /dev/sde"

OK, that all sounds fine.

>>> I'm not 100% sure of the exact cause. But I suspect strongly is that
>>> booting the install media without UEFI broke installing to an UEFI-only
>>> disk.
>>
>> If the installer was booted in BIOS/legacy mode, it installed GRUB for
>> legacy boot.
>
>Was this a choice the installer made, or was it the only option? I don't
>actually have a workaround yet. And if the installer had a check box to
>ask for a GPT even though the install media was booted without UEFI,
>then I could at least get this working after some fiddling.

This *might* help you:

 * partman:

   If the system is booted in EFI mode, partman defaults to GPT for
   disk partitioning. If not, it will default to MSDOS.

   In partman, hitting  on the raw disk will allow you to
   create a new blank partition table; this will take thd default type
   normally, and you won't be asked.

   *If* you switch to expert mode from the main menu (i.e. drop
   question priority), then go back into partman, you can choose to
   use a different partition type. By all means try GPT here, and
   create an EFI system partition (ESP) too.

 * grub-installer:

   This depends on the system being booted in EFI mode to do the right
   thing. If you're not, you *might* be able to make things work by
   editing the script /usr/bin/grub-installer and replace the line
   ARCH="$(archdetect)" with ARCH="amd64/efi". I've not tested this,
   but you *might* be able to progress here.

The installer is *very* much designed to only set up EFI-relevant
stuff if you're booted in EFI mode.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   https://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#1033731: sbcl: support bootstrap on riscv64

[Bo YU]

Hi,

On Fri, Mar 31, 2023 at 5:01 PM John Paul Adrian Glaubitz
 wrote:
>
> Hello Bo!
>
> On Fri, 2023-03-31 at 16:53 +0800, Bo YU wrote:
> > The sbcl can be bootstraped on Debian riscv64 now.
> > A riscv64 sbcl package is available here:
> > https://drive.google.com/drive/folders/1wCCV6Ke0YMCrgGwKF4rjTTlEz8wr4Piq?usp=share_link
>
> The folder is empty.
Sorry, the folder is wrong. The right folder is here:
https://drive.google.com/drive/folders/1c6AFD_EgGwXTbAiC_-1al6Gb_wBpfMpr

>
> > Please note it is 2.2.2 from upstream to be bootstrapped. At first
> > I hope it can reduce bootstrap pain on Debian r iscv64. And
> > I will also keep an eye on upstream changes and update here.
> > BTW, I have to modify the d/rules file to fix the issue that reported
> > cannot find `stage1/bin/sbcl` issue. It seems the file was cleared by
> > `./clean.sh` even with `chmod 100 stage 1`
>
> Did you build in a clean environment, i.e. using sbuild?
Yeah, I used sbuild(with --extra-package options) to build it.
I will gradually upgrade to 2.2.3(revert the commit) to see if this
problem still exists.

BR,
Bo

Bug#1033602: nvidia-graphics-drivers: dh_missing finds missing files and I think it is my fault

[Renato Gallo]

Hello,

I just would like to thank you for the fast response, kindness, support and
effort

Kind Regards
Renato Gallo

On Tue, Mar 28, 2023 at 5:26 PM Renato Gallo  wrote:

> Now I am following your lead and what you wrote.
> Tried with the untouched source version and it worked.
> I have noticed that the dch foo edits the changelog so I tried to update
> it to the actual version.
> Now it fails at the checksums . since your method seems to differ from
> the kernel deb compilation I was asking myself how does he updates the
> checksums ?
>
> On Tue, 2023-03-28 at 17:16 +0200, Andreas Beckmann wrote:
>
> On 28/03/2023 16.11, Renato Gallo wrote:
>
> First things first Thanks again I will try
> I based my experiment onto the master main git
> what should I clone to be reasonably safe and follow your lead ?
>
>
> 525 or better 530. master is ancient and stale (and is no longer
> refreenced in metadata, so should really go away.
>
>
> Andreas
>
>

Bug#1033731: sbcl: support bootstrap on riscv64

[John Paul Adrian Glaubitz]

Hello Bo!

On Fri, 2023-03-31 at 16:53 +0800, Bo YU wrote:
> The sbcl can be bootstraped on Debian riscv64 now.
> A riscv64 sbcl package is available here:
> https://drive.google.com/drive/folders/1wCCV6Ke0YMCrgGwKF4rjTTlEz8wr4Piq?usp=share_link

The folder is empty.

> Please note it is 2.2.2 from upstream to be bootstrapped. At first
> used 2.3.2, but due to one commit[0] was introduced after 2.2.3:
> was failed to bootstrap it after many attempts
> There are many issues 0n Debian using ecl to bootstrap it also.
> > So with help of Christoph[1], I first built sbcl in a cross build
> way then patched the binary file into sbcl package which can be
> bootstrapped itself at last.

Well, Debian is using clisp for bootstrapping sbcl but that still doesn't
work for sbcl, see:

> https://buildd.debian.org/status/logs.php?pkg=sbcl=riscv64

> I hope it can reduce bootstrap pain on Debian r iscv64. And
> I will also keep an eye on upstream changes and update here.
> BTW, I have to modify the d/rules file to fix the issue that reported
> cannot find `stage1/bin/sbcl` issue. It seems the file was cleared by
> `./clean.sh` even with `chmod 100 stage 1`

Did you build in a clean environment, i.e. using sbuild?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1033731: sbcl: support bootstrap on riscv64

[Bo YU]

Source: sbcl
Version: 2:2.2.9- 1
Severity: minor
Tags: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer ，

The sbcl can be bootstraped on Debian riscv64 now.
A riscv64 sbcl package is available here:
https://drive.google.com/drive/folders/1wCCV6Ke0YMCrgGwKF4rjTTlEz8wr4Piq?usp=share_link

Please note it is 2.2.2 from upstream to be bootstrapped. At first
used 2.3.2, but due to one commit[0] was introduced after 2.2.3:
was failed to bootstrap it after many attempts
There are many issues 0n Debian using ecl to bootstrap it also.
| So with help of Christoph[1], I first built sbcl in a cross build
way then patched the binary file into sbcl package which can be
bootstrapped itself at last.

I hope it can reduce bootstrap pain on Debian r iscv64. And
I will also keep an eye on upstream changes and update here.
BTW, I have to modify the d/rules file to fix the issue that reported
cannot find `stage1/bin/sbcl` issue. It seems the file was cleared by
`./clean.sh` even with `chmod 100 stage 1`

[0]: https://bugs.launchpad.net/sbcl/+bug/2002930
[1]: https://lists.debian.org/debian-common-lisp/2023/03/msg5.html

BR,
Bo

Bug#1033729: google-android-cmdline-tools-7.0-installer: apkanalyzer fails to run if google-android-build-tools-*-installer is not installed

[Marco Gontijo]

Package: google-android-cmdline-tools-7.0-installer
Severity: important
X-Debbugs-Cc: marcotmar...@gmail.com

Dear Maintainer,

I installed this package and tried to run apkanalyzer. I got this error message:

Exception in thread "main" java.lang.IllegalStateException: Cannot locate 
latest build tools

After I installed google-android-build-tools-33.0.0-installer, the command
worked. This should be a package dependency.


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Bug#1033730: adduser changes in bookworm

[Marc Haber]

Package: release-notes
Severity: normal

Hi,

adduser has changed quite a bit during the bookworm cycle. We have
deprecated a few command line and configuration options and have renamed
others to be less confusing and a bit more consistent to themselves.
There have also been behavioral changes regarding the
--disabled-password and --disabled-login options of adduser that might
affect package maintainer scripts. User might also be affected by
changes in the handling of primary and supplementary groups and the
permissions set by the home directories of newly created accounts.
Newly created system users also have their home directory set to
/nonexistent unless the --home option is given as well.

Whatever incomplete LDAP support that was present in Adduser was
removed.

Users of adduser are advised to check /usr/share/doc/adduser/NEWS.Debian
and /usr/shade/doc/adduser/README.Debian and the manual pages that come
with the package to find out which changes are planned for Debian's
release after bookworm, enabling them to do necessary changes to their
packages and code during the bookworm cycle to get ready for bookworm+1.

As adduser is a very widely installed package, this may warrant
mentioning in the release notes.

Greetings
Marc

Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-03-31 08:59:01)
> Hi. Thanks for all the explanations. I just re-read this whole sequence
> of emails, and I'm mostly clear on this now.
> 
> First off, I think the last email confused things a little bit. I run
> sbuild on modified source, as you expect. The sequence in the previous
> email was just a simple example of something that surprisingly to me
> doesn't work in sbuild.
> 
> All packages I ever work on live in git. So the "clean" state is defined
> as the result of "git clean -fdx && git reset --hard". I know that
> sbuild can't assume git
> 
> So my workflow is usually something like
> 
> - git clean -fdx && git reset --hard
> - sbuild
> 
> If I forgot the clean step above, dpkg usually yells at me. That feels
> like enough, without needing a "dh clean" also.

if you are not using gbp which has the --git-cleaner option, how about adding a
setting you can put into your ~/.sbuildrc, which, instead of running
"debian/rules clean" will run an arbitrary command of your choosing like "git
clean -fdx && git reset --hard"?

> If there's no way to make this always work in all cases, can we make the
> error message better somehow? How about
> 
>   "dh clean" failed. Note: this runs outside the chroot, so the required
>   Build-Depends may not be installed
> 
> Or something like that. This bit of info would have saved me some time:
> I spent time looking around before filing this report. Is that reasonable?
> Can we do even better?

Yes, we can absolutely improve the error message.

Note though, that in the sbuild.conf man page it already says:

> When  running  sbuild from within an unpacked source tree, run the 'clean'
> target before generating the source package. This might require some of the
> build dependencies necessary for running the  'clean' target to be installed
> on the host machine. Only disable if you start from a clean check‐ out and
> you know what you are doing.

Does that paragraph say everything you would've liked to know or is there
anything you'd add there?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1033728: sudo-ldap might be removed post-bookworm or post-trixie

[Marc Haber]

Package: sudo-ldap
Severity: important

The sudo-ldap package is difficult to maintain. It is, however, still
more popular than the more modern and more flexible libnss-sudo, see
https://qa.debian.org/popcon.php?package=sudo

I'd like to ask the users of the sudo-ldap package why they are not
using libnss-sudo. I am especially interested in things that sudo-ldap
does better than libsss-sudo.

Most current deployments of LDAP with Linux clients for console and ssh
login are likely to be using sssd the uid and password management
anyway, so it seems just natural to use sss for sudo management as well.

Please add your reasons to this bug, so that the sudo maintainers can
properly consider the reasons in their decision.

Greetings
Marc

Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

[Dima Kogan]

Hi. Thanks for all the explanations. I just re-read this whole sequence
of emails, and I'm mostly clear on this now.

First off, I think the last email confused things a little bit. I run
sbuild on modified source, as you expect. The sequence in the previous
email was just a simple example of something that surprisingly to me
doesn't work in sbuild.

All packages I ever work on live in git. So the "clean" state is defined
as the result of "git clean -fdx && git reset --hard". I know that
sbuild can't assume git

So my workflow is usually something like

- git clean -fdx && git reset --hard
- sbuild

If I forgot the clean step above, dpkg usually yells at me. That feels
like enough, without needing a "dh clean" also.

If there's no way to make this always work in all cases, can we make the
error message better somehow? How about

  "dh clean" failed. Note: this runs outside the chroot, so the required
  Build-Depends may not be installed

Or something like that. This bit of info would have saved me some time:
I spent time looking around before filing this report. Is that
reasonable? Can we do even better?

Thanks much

Bug#1033725: systemd-boot: Sign systemd-boot with Debian Secure Boot CA

[Michael Biebl]

Am 31.03.23 um 07:58 schrieb Gihun Nam:

Package: systemd-boot
Severity: wishlist
X-Debbugs-Cc: gihun...@proton.me

Dear Maintainer,

Please, sign /usr/lib/systemd/boot/efi/systemd-bootx64.efi with Debian Secure 
Boot CA
(or maybe create systemd-bootx64.efi.signed) so that systemd-boot can be used 
with
UEFI Secure Boot and shim out of the box.

Debian provides systemd-boot but does not sign it with a Debian key.
To use systemd-boot with shim, one needs to enroll its hash with MokManager.
Although systemd-boot is not an official bootloader of Debian,
signing it would be handy to people using systemd-boot and Secure Boot with 
Debian.



We would love too, but this is not in the hands of the systemd(-boot) 
maintainers.


Please see
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033569: systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section

[Michael Biebl]

Control: tags -1 + fixed-upstream

Am 28.03.23 um 20:46 schrieb Emanuele Rocca:

Hi,

On Mon, Mar 27, 2023 at 06:23:57PM +0200, Michael Biebl wrote:

Please consider raising this issue upstream


There's no need, the bug is fixed in main (currently at 3a051522).


Ah nice, good to know.
Marking accordingly


It is however reproducible checking out tag v253, so presumably upstream
version v254 will be the first release fixing this.

I see that there's been quite some work in the area, eg. commit 2afeaf16.


Yeah, the way systemd-boot is built has been reworked completely.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033727: gcompris-qt: Some images not shown (qt plugin missing)

[Stefan Kropp]

Package: gcompris-qt
Version: 3.1-2
Severity: normal
X-Debbugs-Cc: stefan.kr...@posteo.de

Dear Maintainer,

some images not shown (e.g. click the fishes).

This problem could be solved by installing

  qt5-image-formats-plugins

Please add this package as dependency.

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

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

Versions of packages gcompris-qt depends on:
ii  gcompris-qt-data   3.1-2
ii  libc6  2.36-8
ii  libgcc-s1  12.2.0-14
ii  libqt5core5a   5.15.8+dfsg-3
ii  libqt5gui5 5.15.8+dfsg-3
ii  libqt5multimedia5  5.15.8-2
ii  libqt5multimedia5-plugins  5.15.8-2
ii  libqt5network5 5.15.8+dfsg-3
ii  libqt5qml5 5.15.8+dfsg-3
ii  libqt5quick5   5.15.8+dfsg-3
ii  libqt5sensors5 5.15.8-2
ii  libqt5widgets5 5.15.8+dfsg-3
ii  libstdc++6 12.2.0-14
ii  qml-module-qtgraphicaleffects  5.15.8-2
ii  qml-module-qtmultimedia5.15.8-2
ii  qml-module-qtquick-controls5.15.8-2
ii  qml-module-qtquick-controls2   5.15.8+dfsg-2
ii  qml-module-qtquick-particles2  5.15.8+dfsg-3

gcompris-qt recommends no packages.

gcompris-qt suggests no packages.

-- no debconf information
Thank you for using reportbug

Bug#1033726: krb5: Unable to set DEFCCNAME, krb5.conf dosen't respect default_ccache_name - cached login impossible?

[tuharsky]

Package: krb5-config
Version: 2.6+nmu1
Severity: normal
File: krb5.conf

Dear Maintainer,

I'm setting up an AD authenticated machine. I have problem with credentials 
cache. KRB5 insists the cache file to be /tmp/krb5cc_{%euid}
Thus, the file is deleted after reboot. However, I want to enable cached 
(offline) login, so I set in /etc/krb5.conf in [libdefaults] section:
default_ccache_name = /var/cache/krb5/krb5cc_{%euid}

The KRB5 seems to ignore the setting, klist shows cache file still to be in the 
default location



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

Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
Locale: LANG=sk_SK.UTF-8, LC_CTYPE=sk_SK.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 krb5-config depends on:
ii  bind9-host 1:9.16.37-1~deb11u1
ii  debconf [debconf-2.0]  1.5.77

krb5-config recommends no packages.

krb5-config suggests no packages.

-- debconf information excluded