Bug#1033034: unblock: libmemcached/1.1.4-1

[Ondřej Surý]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please unblock package libmemcached 1.1.4-1, it contains fix for #1032479
(CVE-2023-27478).  Removing libmemcached from testing would pull a hell lot of
packages with it.  The upstream changes between 1.1.3 and 1.1.4 are minimal and
the code changes are limited to fixing the CVE; It also fixes the underlinking
problem that we had to patch.

Thanks,
Ondrej

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libmemcached/1.1.4-1


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmQSouNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcK6XxAAp5XHOJE5RV6adouX85kXtGR9Yj7L9LcRH/n77IReorLZa/JpxtKceha9
JufAm0CK8fWuvJ5HqYcqo2BClpIiyjLSz8WtuwJw8lQMoblOikpC36P2Cw362UO7
/9guIyuyEaMOY25f6N0P7+w3Xpd6eJXksCvpAYUnSCitBz9Ce0MLiRvQaXtBFT0r
WBQnKd63kF6t/ZG75Et8pJJgUoIxarlrBPe7EwwIepvoQO5RcNt3TqUFzy9uOF2C
74GOMOn8RLLYFlQyhUfVds18m53i5pxXa2B+leYfvVvZhkTrZuJCrDPUUlAxtkfP
WDfUPCKzegYcUfwSiIPDqjihPiMD+OasuUPfDKPG39e2iQts9wUeCMkRnBOVHUVw
Pp/zt5KGPXwvgz9xeKBIVRbquVt+l3lmGI/qUU3vCezVi4nhOlnrwXoPyC5QoWG3
ZGe1DY0nzcSLq1yviUWmUTVQwHfp9dxoJPIvsAi7sh5saTnnquxEC/xUjTWn1wQ3
uKHUw3uFnZ5q8VYqdsAFjTbCogz8MZsyZlsYcxspDCEkW8JoKpdSl9zZiZ9ouoap
Gy4IqQBmQCU9u2oBiwf9CWLywxkzmmHYuCdNGwzspOZbqfOB4iY4tsq9n5uM/KsR
zlT3OO/DQdiEOztBZJQIhWuZ6VFMDpqMrVdDQIXjecvpknAr+MU=
=JrGZ
-END PGP SIGNATURE-
diff -Nru libmemcached-1.1.3/.builds/freebsd.yml 
libmemcached-1.1.4/.builds/freebsd.yml
--- libmemcached-1.1.3/.builds/freebsd.yml  2023-02-03 11:59:40.0 
+0100
+++ libmemcached-1.1.4/.builds/freebsd.yml  2023-03-06 19:36:56.0 
+0100
@@ -45,11 +45,5 @@
   maybe cmake --build debug -j2 --target test
   - install: |
   maybe cmake --install debug --prefix /tmp
-  - package: |
-  maybe cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_DOCS_MANGZ=ON -S 
libmemcached -B release
-  maybe cmake --build release -j2 --target package -- VERBOSE=
-  maybe cmake -DCPACK_COMPONENT_INSTALL=ON release
-  maybe cmake --build release -j2 --target package -- VERBOSE=
-  maybe cmake --build release -j2 --target push-artifacts -- VERBOSE=
   - success: |
   notify-gitter success
diff -Nru libmemcached-1.1.3/.builds/openbsd.yml 
libmemcached-1.1.4/.builds/openbsd.yml
--- libmemcached-1.1.3/.builds/openbsd.yml  2023-02-03 11:59:40.0 
+0100
+++ libmemcached-1.1.4/.builds/openbsd.yml  2023-03-06 19:36:56.0 
+0100
@@ -33,11 +33,5 @@
   maybe cmake --build debug -j2 --target test
   - install: |
   maybe cmake --install debug --prefix /tmp
-  - package: |
-  maybe cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_DOCS_MANGZ=ON -S 
libmemcached -B release
-  maybe cmake --build release -j2 --target package -- VERBOSE=
-  maybe cmake -DCPACK_COMPONENT_INSTALL=ON release
-  maybe cmake --build release -j2 --target package -- VERBOSE=
-  maybe cmake --build release -j2 --target push-artifacts -- VERBOSE=
   - success:
   notify-gitter success
diff -Nru libmemcached-1.1.3/.builds/scripts/notify-gitter 
libmemcached-1.1.4/.builds/scripts/notify-gitter
--- libmemcached-1.1.3/.builds/scripts/notify-gitter2023-02-03 
11:59:40.0 +0100
+++ libmemcached-1.1.4/.builds/scripts/notify-gitter2023-03-06 
19:36:56.0 +0100
@@ -1,6 +1,8 @@
 #!/usr/bin/env bash
 set -eu
 
+test -f ~/.gitter || exit 0
+
 GITTER=$(cat ~/.gitter)
 STATUS=$1
 
diff -Nru libmemcached-1.1.3/ChangeLog libmemcached-1.1.4/ChangeLog
--- libmemcached-1.1.3/ChangeLog2023-02-03 11:59:40.0 +0100
+++ libmemcached-1.1.4/ChangeLog2023-03-06 19:36:56.0 +0100
@@ -1,5 +1,22 @@
 # ChangeLog v1.1
 
+## v 1.1.4
+
+> released 2022-03-06
+
+* Fix [gh #107](https://github.com/awesomized/libmemcached/issues/107):
+  macOS: deprecated sasl API (improve detection of `libsasl2`).
+* Fix [gh #131](https://github.com/awesomized/libmemcached/issues/131):
+  Consider renaming tools (add `CLIENT_PREFIX` build option; default: `mem`)
+* Fix [gh #132](https://github.com/awesomized/libmemcached/issues/132):
+  Add build of static library (add `BUILD_SHARED_LIBS` build option; default: 
`ON`).
+* Fix [gh #134](https://github.com/awesomized/libmemcached/issues/134):
+  Update client option documentation.
+* Fix [gh #136](https://github.com/awesomized/libmemcached/issues/136):
+  `libmemcachedutil` is underlinked (link against libmemcached).
+* Fix [gh 
php-memcached#531](https://github.com/php-memcached-dev/php-memcached/issues/531):
+  `get` returns random values when lower than default `OPT_POLL_TIMEOUT` is 
set.
+
 ## v 1.1.3
 
 > released 2022-11-09
diff -Nru libmemcached-1.1.3/ChangeLog-1.1.md 

Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)

[Hideki Yamane]

control: tags -1 +pending


On Wed, 15 Mar 2023 18:39:47 + Jose M Calhariz  wrote:
> Thank you, your problem is known and will be fixed on the next upload.

-- 
Hideki Yamane 

Bug#1027429: mmdebstrap: unshare backend not working

[Johannes Schauer Marin Rodrigues]

Hi Andrea,

Quoting Andrea Pappacoda (2022-12-31 12:54:35)
> Hi, for some reason I'm unable to get the unshare backend working on one of my
> machines.
> 
> When I try to create an unstable-amd64 tarball to use with sbuild I get this
> strange error:
> 
> mmdebstrap --variant=apt --include=build-essential unstable unstable-
> amd64.tar
> I: automatically chosen mode: unshare
> I: chroot architecture amd64 is equal to the host's architecture
> I: automatically chosen format: tar
> I: using /tmp/mmdebstrap.panqVhWsFm as tempdir
> W: /etc/subuid is empty
> E: invalid idmap

I found another actionable in your bug report. mmdebstrap should not
automatically choose unshare mode if that cannot work on your system. To that
end I wrote:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/055e1719b95960496a0cda88535fd00e9a395516

If you like, please try that out on your system with --mode=unshare as well as
with --mode=auto. The messages and logic should be much better now.

If you cannot apply that patch, since mmdebstrap is a single script, you can
also just download the perl script and run it:

https://gitlab.mister-muffin.de/josch/mmdebstrap/raw/branch/main/mmdebstrap

Tell me what you think!

This is similar to #1032489, so I'm putting Dima in CC who can try this as
well. :)

Thanks!

cheers, josch

Bug#987008: grub2: diff for NMU version 2.06-8.1

[Hideki Yamane]

Control: tags -1 +pending

Hi from RC bugs digger,

 It's better to show this issue is going to be solved, add "pending"
 is good to avoid duplicate efforts :)


-- 
Hideki Yamane 

Bug#1033033: unblock: mozjs78/78.15.0-7

[Jeremy Bícha]

Package: release.debian.org
Control: affects -1 + src:mozjs78
X-Debbugs-Cc: mozj...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mozjs78

[ Reason ]
This update adds 2 patches to fix 2 FTBFS issues (python3.11 & gcc12)

[ Impact ]
mozjs78 can be built from source

[ Tests ]
mozjs78 in Unstable has built on all release architectures.
mozjs78 does not have autopkgtests itself yet, but all the cjs
autopkgtests triggered by this update have passed.

[ Risks ]

[ 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 ]
mozjs78 is the SpiderMonkey JavaScript engine from the obsolete
Firefox ESR 78 branch. It is only used by cjs (a fork of gjs), a
critical element of the Cinnamon desktop. The Cinnamon developers will
eventually switch to newer versions of mozjs but this won't happen for
Bookworm.

https://wiki.mozilla.org/Release_Management/Calendar

unblock mozjs78/78.15.0-7

Thank you,
Jeremy Bicha


mozjs78_78.15.0-7.debdiff
Description: Binary data

Bug#1033032: buddy: reproducible-builds: Embedded build path and usrmerge paths in example Makefile

[Vagrant Cascadian]

Source: buddy
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path and various binary paths are embedded in
/usr/share/doc/libbdd-dev/examples/solitare/Makefile:

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

  ACLOCAL·=·${SHELL}·'/build/1st/buddy-2.4+dfsg/tools/missing'·aclocal-1.16
  vs.
  ACLOCAL·=·${SHELL}·'/build/2/buddy-2.4+dfsg/2nd/tools/missing'·aclocal-1.16

  EGREP·=·/bin/grep·-E
  vs.
  EGREP·=·/usr/bin/grep·-E

The attached patch fixes this by removing the example Makefile, which
would have to be regenerated anyways to match the running system.

If removing the example Makefile is not viable, it might be possible to
sanitize the build paths, and add relevent arguments to configure
(e.g. EGREP='/bin/grep -e') to use the specified paths.

According to my local tests, with this patch applied buddy should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining buddy!

live well,
  vagrant
From 157d368d3bba2def3069861780acb0ff26fa66c5 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 15 Mar 2023 19:00:17 -0700
Subject: [PATCH] debian/rules: Remove example Makefile containing build paths
 and various binary paths.

As the Makefile would need to be regenerated from Makefile.am or
Makefile.in in order to match the running system, remove it.

https://reproducible-builds.org/docs/build-path/
https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index b0f63f0..1fe0f65 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,7 +22,7 @@ override_dh_installexamples:
 	rm -f debian/libbdd-dev/usr/share/doc/libbdd-dev/examples/bddcalc/Makefile* ; \
 	sed -i "2a g++ -O2 -o bddcalc hashtbl.cxx lexer.cxx parser.cxx -lbdd -lm" debian/libbdd-dev/usr/share/doc/libbdd-dev/examples/bddcalc/runtest ; \
   	rm -f debian/libbdd-dev/usr/share/doc/libbdd-dev/examples/Makefile
-  	# No idea what to do in examples/solitare
+	rm -f debian/libbdd-dev/usr/share/doc/libbdd-dev/examples/solitare/Makefile
 
 override_dh_installchangelogs:
 	dh_installchangelogs $(CURDIR)/ChangeLog
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1033030: nodeenv: uses plain HTTP to download NodeJS binaries

[Ryan LaPointe]

Package: nodeenv
Version: 0.13.4-1.1
Severity: normal
X-Debbugs-Cc: r...@ryanlapointe.org

The latest version of nodeenv available in the Debian repositories
uses plain HTTP to connect to nodejs.org to download the NodeJS
executables when the --prebuilt option is used. This version was
released in 2015 and 19 new versions of nodeenv have been released
since then (https://github.com/ekalinin/nodeenv/tags). Newer versions
of nodeenv use HTTPS to download NodeJS. Although nodejs.org responds
with a 301 redirecting to HTTPS, the initial connection over HTTP
still creates a vulnerability to a man-in-the-middle attack.
It's 2023, and executing binaries that were downloaded using plain
HTTP with no verification is a bad practice.
(https://security.googleblog.com/2020/02/protecting-users-from-insecure_6.html)
Please update this package to a newer upstream version to fix this bad
practice.

I tried emailing the package maintainer before opening this bug, but
the maintainer's mailserver rejected my message because the
maintainer's mailbox "is over quota".

Bug#1032290:

[MouseZhang]

Hi, I’m sorry for replying your mail so late, because system put this ITP mail 
into the Trash Mail.
I’ve checked all my mail box, there is no mail from you.
I'm worried that something is wrong with my email. Can you send it to my other 
email address?
The gmail address is mousezha...@gmail.com , 
thank you!

> On Mar 8, 2023, at 18:32, Mason Xiaohan Liu  
> wrote:
> 
> Did you get my mail

Bug#1033029: libsqlite3-0: please declare a Breaks against old crowdsec versions

[Cyril Brulebois]

Package: libsqlite3-0
Version: 3.34.1-3
Severity: important
Tags: patch
X-Debbugs-Cc: debian...@lists.debian.org

Hi,

With my crowdsec maintainer hat on: while preparing the final crowdsec
upload(s) for bookworm, I've spotted that the crowdsec package from
bullseye doesn't start on a bookworm system:

time="16-03-2023 00:19:45" level=fatal msg="api server init: unable to run 
local API: unable to init database client: failed creating schema resources: 
sql/schema: invalid type \"INTEGER\" for column \"events_count\""

While crowdsec is a Go package, relying on the Ent package to deal with
SQLite, the latter leverages golang-github-mattn-go-sqlite3-dev, which
ends up building against the system SQLite library.

That's how crowdsec 1.0.9-2(+b4) in bullseye ends up depending on
libsqlite3-0 (>= 3.7.15).

The service starts fine with all libsqlite3-0 versions between 3.34.1-3
and 3.36.0-2, and no longer starts with 3.37.0-1 and later. While I was
contemplating the documented changes for 3.37.0 (and finding nothing
relevant), my very kind upstream found this Ent issue:
  https://github.com/ent/ent/issues/2209

In short, Ent's expectations are no longer fulfilled, and crowdsec no
longer starts with newer versions.

To support partial upgrades from bullseye to bookworm, it would be best
if libsqlite3-0 would break old crowdsec versions, so that we don't run
into this issue (either because admins are performing partial upgrades
on purpose, or because apt broke down the upgrade into smaller chunks
with a combination of crowdsec/libsqlite3-0 packages that cannot work).

Patch attached, thanks for considering!


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff -Nru sqlite3-3.40.1/debian/changelog sqlite3-3.40.1/debian/changelog
--- sqlite3-3.40.1/debian/changelog 2022-12-31 09:41:40.0 +0100
+++ sqlite3-3.40.1/debian/changelog 2023-03-16 00:51:04.0 +0100
@@ -1,3 +1,10 @@
+sqlite3 (3.40.1-2) UNRELEASED; urgency=medium
+
+  * Add Breaks against crowdsec as found in bullseye, as it relies on a
+particular table_info format, which changes between 3.36.0 and 3.37.0.
+
+ -- Cyril Brulebois   Wed, 15 Mar 2023 23:51:04 +
+
 sqlite3 (3.40.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru sqlite3-3.40.1/debian/control sqlite3-3.40.1/debian/control
--- sqlite3-3.40.1/debian/control   2022-12-31 09:41:40.0 +0100
+++ sqlite3-3.40.1/debian/control   2023-03-16 00:50:52.0 +0100
@@ -52,7 +52,7 @@
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Breaks: python-migrate (<< 0.11.0-4~), python3-migrate (<< 0.11.0-4~)
+Breaks: python-migrate (<< 0.11.0-4~), python3-migrate (<< 0.11.0-4~), 
crowdsec (<< 1.4)
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Description: SQLite 3 shared library

Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Christian Kastner]

On 2023-03-13 18:28, Christian Kastner wrote:
> [ Impact ]
> The new versions are in far better shape: they've catched missing
> dependencies, added patches, improved the build process, etc.

Apologies, I was only thinking of the more recent releases.

Revision -2 fixed an RC bug in January, but never got the chance to
migrate because of an RC bug in a dependency. Revision -6 fixed another
RC bug.

All releases after -2 were incremental improvements that basically never
got the chance to migrate because of a dependency not migrating.

Bug#1031441: Potential RM candidate ?

[Daniel Leidert]

Am Mittwoch, dem 15.03.2023 um 21:19 +0530 schrieb Pirate Praveen:
> On Mon, 13 Mar 2023 23:17:02 +0530 Mohd Bilal  
> wrote:
>  > Hello,
>  >
>  > The upstream[1] for ruby-github-api has been inactive for over 2 years
>  > now and this is affecting other packages like ruby-oauth2[2] and
>  > ruby-faraday[3] from migrating.
>  >
>  > $ reverse-depends -b ruby-github-api
>  > Reverse-Build-Depends
>  > * ruby-jeweler
>  >
>  > $ reverse-depends -b ruby-jeweler
>  > No reverse dependencies found
>  >
>  > So should we remove these 2 packages ? or as a workaround we could relax
>  > the versions in Gemfile to actually fix this bug since the Debian source
>  > doesn't ship the upstream test suite.
> 
> I think we can remove these two packages.

I agree. Without migrating github-api to oauth2, IMHO/AFAIR it is also
dysfunctional right now.

JFTR: The upstream author is still very much active on github, just not
working on that gem, it seems.

Regards, Daniel

Bug#1032984:

[Stefan Schippers]

Package: libx11-6
Version: 2:1.8.4-2
Bug: #1032984

The issue has been filed upstream.
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/186

Stefan

On 3/15/23 09:27, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1032984: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032984.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian X Strike Force 

If you wish to submit further information on this problem, please
send it to 1032...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#1032379: bug#751: Update: crash due to fvwm window manager crash

[Stefan Schippers]

Thank you.
I have filed the issue upstream.
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/186
Stefan

On 3/15/23 09:56, Klaus Ethgen wrote:

Hi,

I made a libx11 build with the version 2:1.8.4-3~really1.8.3~3 which is
really version 1.8.3-3, so reverting ALL in the new package.

That will solve the dependency stuff and will be overwritten when debian
comes out with a fixed package.

It is available in my repo:
deb ftp://ftp.ethgen.ch/pub/debian ceres unofficial

Regards
Klaus

Bug#1033028: pydata-sphinx-theme: please update to at least v0.9.0rc1

[Gianfranco Costamagna]

Source: pydata-sphinx-theme
Version: 0.7.2-3

Hello, I see there is version 0.13.1, I would like to have it packaged, because 
newer python-pyqtgraph is requesting
   "navbar_end": ["theme-switcher", "navbar-icon-links"],

and AFAICS that theme-switcher appeared on 0.9.0 or similar version.

"Add dark theme and theme switcher by @12rambau in #540"

I know updating needs another library "sphinx_theme_builder", but you seem 
already having an ITP for it :)

thanks for your work!

Gianfranco


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992172: exim4: CVE-2021-38371

[Heiko Schlittermann]

[not encrypted, I'm not able to find the key of Moritz]
Hi,

Salvatore Bonaccorso  (Mi 15 Mär 2023 20:49:01 CET):
> Looks the planned advisory at
> https://www.exim.org/static/doc/security/CVE-2021-38371.txt is not
> online.

I found the message from last year on the list, and the today's messages
too. It seems that there was some discussion about the content of the
advisory.

I'll try to clarify it and then return.

-- 
Heiko


signature.asc
Description: PGP signature

Bug#1032029: mosquitto ignores ip address for websocket listeners

[Roger Light]

Unfortunately this was marked as spam, so I didn't see it.

The attached patch will deny the use of listener bind addresses for
websockets listeners. I also note that using a more recent version of
libwebsockets does not display the same problem.

Regards,

Roger

On Sun, 26 Feb 2023 at 19:39, Helmut Grohne  wrote:

> Package: mosquitto
> Version: 2.0.11-1
> Severity: serious
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
>
> If you configure a websocket listener for mosquitto with an IP address
> to bind to, mosquitto will instead bind the wildcard address. This
> renders a secure configuration insecure.
>
> A simple configuration producing this behaviour is a default
> installation together with one config update:
>
> $ cat /etc/mosquitto/conf.d/listen.conf
> bind_address localhost
> listener 9001 127.0.0.1
> protocol websockets
> $
>
> If you (re)start mosquitto, you can see the insecure bind:
>
> $ ss -tlp
> ...
> LISTEN0 4096 *:9001   *:*
>   users:(("mosquitto",pid=269,fd=7))
> ...
> $
>
> The mosquitto.conf manual page in section 5 says that for websockets,
> you can only give an IP address as bind address, which kinda implies
> that you can given an IP address there. I think it is a reasonable
> expectation that binding to 127.0.0.1 should be secure.
>
> I am filing this as severity serious, because normally a security
> vulnerability would be grave, but this vulnerability only surfaces in a
> (possibly common) non-default configuration. Hence lowering to serious.
>
> I note (mostly for myself) that the following invocation reproduces the
> problem:
>
> debvm-create -- --include iproute2,mosquitto --customize-hook='printf
> "bind_address localhost\\nlistener 9001 127.0.0.1\\nprotocol websockets\\n"
> > "$1/etc/mosquitto/conf.d/listen.conf"'
>
> Helmut
>
diff --git a/src/conf.c b/src/conf.c
index 592ea9796..046ccefb5 100644
--- a/src/conf.c
+++ b/src/conf.c
@@ -1837,6 +1837,10 @@ static int config__read_file_core(struct mosquitto__config *config, bool reload,
 		*/
 		}else if(!strcmp(token, "websockets")){
 #ifdef WITH_WEBSOCKETS
+			if(cur_listener->host){
+log__printf(NULL, MOSQ_LOG_ERR, "Error: Websockets does not allow a listener bind address.");
+return MOSQ_ERR_INVAL;
+			}
 			cur_listener->protocol = mp_websockets;
 #else
 			log__printf(NULL, MOSQ_LOG_ERR, "Error: Websockets support not available.");

Bug#1033027: blhc: misinterprets nvcc compilation as linking

[Andreas Beckmann]

Package: blhc
Version: 0.13-4
Severity: normal

Hi,

blhc seems to misparse nvcc compilation as linking, reporting missing
LDFLAGS:

https://salsa.debian.org/nvidia-team/nvidia-nccl/-/jobs/4055703

2294:LDFLAGS missing (-Wl,-z,relro): /usr/bin/nvcc -DNCCL_OP=0 -DNCCL_TYPE=0 
-ccbin cuda-g++ -gencode=arch=compute_50,code=sm_50 
-gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_61,code=sm_61 
-gencode=arch=compute_35,code=sm_35 -gencode=arch=compute_70,code=sm_70 
-gencode=arch=compute_80,code=sm_80 -gencode=arch=compute_90,code=sm_90 
-gencode=arch=compute_90,code=compute_90 -std=c++11 --expt-extended-lambda 
-Xptxas -maxrregcount=96 -Xfatbin -compress-all -O3 -Xptxas -v -Xcompiler 
-Wall,-Wextra,-Wno-unused-parameter -I. -I.. 
-I/builds/nvidia-team/nvidia-nccl/debian/output/source_dir/build/include 
-I../../include --compiler-options "-fPIC -fvisibility=hidden" -dc 
/builds/nvidia-team/nvidia-nccl/debian/output/source_dir/build/obj/collectives/device/sendrecv_sum_i8.cu
 -o 
/builds/nvidia-team/nvidia-nccl/debian/output/source_dir/build/obj/collectives/device/sendrecv_sum_i8.o


Andreas

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Guilhem Moulin]

Hi,

On Wed, 15 Mar 2023 at 22:43:31 +0100, Bastian Germann wrote:
> Am 15.03.23 um 22:39 schrieb Paul Gevers:
>> Do I understand correctly that:
>> 1) argon2 in testing isn't affected
>> 2) this bug isn't solved yet, despite the closure?
>> 3) the issue for cryptsetup is worked around in cryptsetup
>>
>> libargon2-1 is linked by more packages. Are they all OK without this
>> unintentional change unfixed? Why is the unintentional change not
>> reverted or fixed?
>
> There is no unintentional change.

Yes there is, namely the fact that libargon2-1 no longer links against
libpthread, which in turn caused a major regression in
cryptsetup-initramfs (mitigated in src:cryptsetup 2:2.6.1-2).  Unlike
what I initially claimed in #1014110's msg#20 that change can't be
reverted or fixed in src:argon2 since it's caused by building with a
newer libc; a binNMU would therefore have caused the same regression, it
was just unfortunate timing to dust up the package and upload just
before the hard freeze.

> If packages are waiting for argon2 then I would prefer an unblock of
> both argon2 and cryptsetup at the same time.

More importantly, argon2 >>0~20190702-0.1 should not be allowed in
bookworm before cryptsetup >=2:2.6.1-2, as doing so would make systems
using cryptsetup-initramfs (such an those using “encrypted LVM” layout
from d-i) unbootable.

cryptsetup can transition before argon2 though, and I do intend to file
an unblock request for it given -3 mitigates #1028250.  Bastien, since
argon2 and cryptsetup likely won't enter testing at the same time (which
is was I hoped to do with that bug clone dance, but that failed for the
reasons you described) you might want to upload a new version with
‘Breaks: cryptsetup-initramfs (<<2:2.6.1-2)’.  If you want something
newer than 0~20171227-0.3 in bookworm, that is.  (As far as cryptsetup
is concerned it's fine to ship bookworm with argon2=0~20171227-0.3 and
cryptsetup=2:2.6.1-3.)

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1033026: wordnet: Update wordnet database files to version 3.1

[Amr Ibrahim]

Source: wordnet
Severity: normal

Hello,

Please update the wordnet database files to version 3.1.

Wordnet 3.1 is not a full package as version 3.0. However, the files in the
database directory of version 3.0 can be replaced with those files of version
3.1 and the WordNet interface will run, returning entries from the 3.1
database.

Please see the section on version 3.1 upstream:
https://wordnet.princeton.edu/download/current-version

Best,
Amr


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

Kernel: Linux 6.1.0-6-amd64 (SMP w/8 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

Bug#1033025: unblock: socklog/2.1.0+repack-5

[Mathieu Mirmont]

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

Please unblock package socklog

[ Reason ]
Fix RC bug #1031794.

[ Impact ]
No change of behaviour.

[ Tests ]
After a manual package install and update the services socklog-klog
and socklog-unix run fine. Also dpkg-source -x does not complain
anymore.

[ Risks ]
Low, the changes are trivial.

[ 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 was hoping to get this pushed before the hard freeze but I wasn't
lucky finding an uploader on time. The changes are therefore a bit
more than what I would want at this point but they are all trivial.

unblock socklog/2.1.0+repack-5

-- 
Mathieu Mirmont 
diff -Nru socklog-2.1.0+repack/debian/changelog 
socklog-2.1.0+repack/debian/changelog
--- socklog-2.1.0+repack/debian/changelog   2020-12-22 22:40:42.0 
+0100
+++ socklog-2.1.0+repack/debian/changelog   2023-03-06 22:01:18.0 
+0100
@@ -1,3 +1,15 @@
+socklog (2.1.0+repack-5) unstable; urgency=medium
+
+  * Various uninteresting changes
+  * watch, repack.sh: append +repack to tarball filename
+  * Refresh lintian overrides
+  * service/socklog-unix: remove supervise symlink (Closes: #1031794)
+  * control: bump debian policy to 4.6.2, no change required
+  * gitlab-ci.yml: disable unnecessary jobs
+  * gbp.conf: add configuration file
+
+ -- Mathieu Mirmont   Mon, 06 Mar 2023 22:01:18 +0100
+
 socklog (2.1.0+repack-4) unstable; urgency=medium
 
   * copyright: bump the year
diff -Nru socklog-2.1.0+repack/debian/control 
socklog-2.1.0+repack/debian/control
--- socklog-2.1.0+repack/debian/control 2020-12-22 22:40:42.0 +0100
+++ socklog-2.1.0+repack/debian/control 2023-03-06 21:52:36.0 +0100
@@ -5,7 +5,7 @@
 Uploaders: Gerrit Pape 
 Vcs-Browser: https://salsa.debian.org/debian/socklog
 Vcs-Git: https://salsa.debian.org/debian/socklog.git
-Standards-Version: 4.5.1
+Standards-Version: 4.6.2
 Homepage: http://smarden.org/socklog
 Build-Depends: debhelper-compat (= 13),
dh-runit,
@@ -37,9 +37,8 @@
  ${misc:Depends}, ${shlibs:Depends}
 Recommends: ipsvd, mailx
 Provides: system-log-daemon, linux-kernel-log-daemon
-Conflicts: system-log-daemon, linux-kernel-log-daemon, ${runit:Conflicts}
-Breaks: socklog (<= 2.1.0+repack-3), ${runit:Breaks}
-Replaces: socklog (<= 2.1.0+repack-3)
+Conflicts: system-log-daemon, linux-kernel-log-daemon
+Breaks: ${runit:Breaks}
 Description: system and kernel logging services - runit services
  socklog cooperates with the runit package to create a small and
  secure replacement for rsyslog. socklog supports system logging
diff -Nru socklog-2.1.0+repack/debian/copyright 
socklog-2.1.0+repack/debian/copyright
--- socklog-2.1.0+repack/debian/copyright   2020-11-23 16:13:31.0 
+0100
+++ socklog-2.1.0+repack/debian/copyright   2023-03-06 21:52:36.0 
+0100
@@ -9,7 +9,7 @@
 
 Files: debian/*
 Copyright: Copyright 2001-2008, Gerrit Pape 
- 2019-2020, Mathieu Mirmont 
+ 2019-2023, Mathieu Mirmont 
 License: BSD-3-clause
 
 License: BSD-3-clause
diff -Nru socklog-2.1.0+repack/debian/gbp.conf 
socklog-2.1.0+repack/debian/gbp.conf
--- socklog-2.1.0+repack/debian/gbp.conf1970-01-01 01:00:00.0 
+0100
+++ socklog-2.1.0+repack/debian/gbp.conf2023-03-06 22:01:10.0 
+0100
@@ -0,0 +1,3 @@
+[DEFAULT]
+pristine-tar = True
+sign-tags = True
diff -Nru socklog-2.1.0+repack/debian/gitlab-ci.yml 
socklog-2.1.0+repack/debian/gitlab-ci.yml
--- socklog-2.1.0+repack/debian/gitlab-ci.yml   2020-11-02 03:12:15.0 
+0100
+++ socklog-2.1.0+repack/debian/gitlab-ci.yml   2023-03-06 21:52:36.0 
+0100
@@ -1,3 +1,7 @@
 include:
   - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
   - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  SALSA_CI_DISABLE_BUILD_PACKAGE_ALL: 1
+  SALSA_CI_DISABLE_AUTOPKGTEST: 1
diff -Nru socklog-2.1.0+repack/debian/repack.sh 
socklog-2.1.0+repack/debian/repack.sh
--- socklog-2.1.0+repack/debian/repack.sh   2020-11-02 01:53:45.0 
+0100
+++ socklog-2.1.0+repack/debian/repack.sh   2023-03-06 21:52:36.0 
+0100
@@ -1,12 +1,13 @@
 #!/bin/sh
+set -eu
 
 # Command line check.
-if [ $# -ne 3 ] || [ "$1" != "--upstream-version" ]; then
+if [ $# -lt 2 ] || [ $# -gt 3 ]|| [ "$1" != "--upstream-version" ]; then
 echo "$0: This script must be called via uscan." >&2
 exit 1
 fi
 version="$2"
-tarball="$3"
+tarball="../socklog_$version.orig.tar.gz"
 
 # Create a temporary directory and delete it on exit.
 temp="$(mktemp -d)"
@@ -15,6 +16,11 @@
 # Unpack the original tarball, stripping the first directory component.
 tar -C "$temp" -xf 

Bug#1031652: bullseye-pu: package c-ares/1.17.1-1+deb11u1 CVE-2022-4904

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, Feb 19, 2023 at 09:05:37PM +0100, Gregor Jasny wrote:
> I'd like to upload a new version of c-ares which fixes
> CVE-2022-4904 (#1031525). According to the assessment of the 
> Security Team the bug is not severe enough to warrant an upload
> to bullseye-seurity but the patch should go into -proposed instead.

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1031279: bullseye-pu: package flask-security/4.0.0-1+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Feb 14, 2023 at 02:26:58PM +, Carsten Schoenert wrote:
> [ Reason ]
> The version of flask-security in bullseye is affected by CVE-2021-23385.
> https://security-tracker.debian.org/tracker/CVE-2021-23385
> 
> [ Impact ]
> Without that fix users of Flask based application which using
> get_post_logout_redirect and get_post_login_redirect functions might get
> an bypassed URL validation and redirect a user to an arbitrary URL.

Please go ahead.

> +Subject: A (hopeful) fix for possible open-redirect.

Nothing like confidence :D


Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1025789: bullseye-pu: wolfssl/4.6.0+p1-0+deb11u1_4.6.0+p1-0+deb11u2.debdiff

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Thu, Dec 08, 2022 at 08:07:09PM -0800, Felix Lechner wrote:
> diff -Nru wolfssl-4.6.0+p1/debian/changelog.dch 
> wolfssl-4.6.0+p1/debian/changelog.dch
> --- wolfssl-4.6.0+p1/debian/changelog.dch 1970-01-01 00:00:00.0 
> +
> +++ wolfssl-4.6.0+p1/debian/changelog.dch 2022-12-06 08:25:30.0 
> +
[...]

Stray file?

> diff -Nru 
> wolfssl-4.6.0+p1/debian/patches/add-WOLFSSL_CHECK_SIG_FAULTS-macro.patch 
> wolfssl-4.6.0+p1/debian/patches/add-WOLFSSL_CHECK_SIG_FAULTS-macro.patch
> --- wolfssl-4.6.0+p1/debian/patches/add-WOLFSSL_CHECK_SIG_FAULTS-macro.patch  
> 1970-01-01 00:00:00.0 +
> +++ wolfssl-4.6.0+p1/debian/patches/add-WOLFSSL_CHECK_SIG_FAULTS-macro.patch  
> 2022-12-06 08:25:30.0 +
> @@ -0,0 +1,154 @@
> +Description: PR 5498: CVE-2022-42961
> +Author: Jacob Barthelmeh 
> +Origin: backport

Origin would typically be a URL, and a description of what the patch fixes
(not just a bare CVE number) would be nice.




-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1032985: unblock: gourmand/1.1.0+really1.1.0~rc3-3

[Christian Marillat]

On 15 mars 2023 20:35, Jonathan Wiltshire  wrote:

> Control: tag -1 moreinfo
>
> Hi,
>
> On Wed, Mar 15, 2023 at 09:29:54AM +0100, Christian Marillat wrote:
>> [ Checklist ]
>>   [x] all changes are documented in the d/changelog
>>   [x] I reviewed all changes and I approve them
>>   [ ] attach debdiff against the package in testing
>
> Can we get the debdiff please?

Yes :

,
| diff -Nru gourmand-1.1.0+really1.1.0~rc3/debian/changelog 
gourmand-1.1.0+really1.1.0~rc3/debian/changelog
| --- gourmand-1.1.0+really1.1.0~rc3/debian/changelog   2023-02-05 
17:26:09.0 +0100
| +++ gourmand-1.1.0+really1.1.0~rc3/debian/changelog   2023-03-10 
17:29:44.0 +0100
| @@ -1,3 +1,10 @@
| +gourmand (1.1.0+really1.1.0~rc3-3) unstable; urgency=medium
| +
| +  * Add upstream patch to fix "unable to add an ingredient"
| +(Closes: #1030027)
| +
| + -- Christian Marillat   Fri, 10 Mar 2023 17:29:44 +0100
| +
|  gourmand (1.1.0+really1.1.0~rc3-2) unstable; urgency=medium
|  
|* Replaces python3-scrape-schema-recipe by python3-recipe-scrapers.
| diff -Nru 
gourmand-1.1.0+really1.1.0~rc3/debian/patches/02_fix-unable-to-add-an-ingredient.patch
 
gourmand-1.1.0+really1.1.0~rc3/debian/patches/02_fix-unable-to-add-an-ingredient.patch
| --- 
gourmand-1.1.0+really1.1.0~rc3/debian/patches/02_fix-unable-to-add-an-ingredient.patch
1970-01-01 01:00:00.0 +0100
| +++ 
gourmand-1.1.0+really1.1.0~rc3/debian/patches/02_fix-unable-to-add-an-ingredient.patch
2023-03-10 17:29:44.0 +0100
| @@ -0,0 +1,21 @@
| +From 19a544882b1aabb75d83494e3797e515909300bb Mon Sep 17 00:00:00 2001
| +From: Cyril Danilevski 
| +Date: Fri, 27 Jan 2023 19:02:40 +0100
| +Subject: [PATCH] Do not query ingredient key when parsing ingredients from
| + line (#142)
| +
| +---
| + src/gourmand/reccard.py | 2 +-
| + 1 file changed, 1 insertion(+), 1 deletion(-)
| +
| +--- a/src/gourmand/reccard.py
|  b/src/gourmand/reccard.py
| +@@ -1174,7 +1174,7 @@ class IngredientEditorModule (RecEditorM
| + selected item, so that the new ingredient can be added right below 
it in
| + the tree.
| + """
| +-d = self.rg.rd.parse_ingredient(line, conv=self.rg.conv)
| ++d = self.rg.rd.parse_ingredient(line, conv=self.rg.conv, 
get_key=False)
| + if d:
| + if 'rangeamount' in d:
| + d['amount'] = self.rg.rd.format_amount_string_from_amount(
| diff -Nru gourmand-1.1.0+really1.1.0~rc3/debian/patches/series 
gourmand-1.1.0+really1.1.0~rc3/debian/patches/series
| --- gourmand-1.1.0+really1.1.0~rc3/debian/patches/series  2022-12-10 
09:50:43.0 +0100
| +++ gourmand-1.1.0+really1.1.0~rc3/debian/patches/series  2023-03-10 
17:29:44.0 +0100
| @@ -1 +1,2 @@
|  01_Fix-FTBFS-with-python.patch
| +02_fix-unable-to-add-an-ingredient.patch
`

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Bastian Germann]

Am 15.03.23 um 22:39 schrieb Paul Gevers:

Hi,

[Release Team here]

On Thu, 2 Mar 2023 18:42:56 +0100 Bastian Germann  wrote:

On Thu, 2 Mar 2023 05:10:41 +0100 Guilhem Moulin  wrote:
> Ah no my bad, the changelog entry is probably incorrect and the
> cryptsetup-initramfs breakage is caused by the recent libargon2 upload
> indeed, but AFAICT not by anything particular in the upload.

I am sorry for having caused that issue, Daniel. Thanks for investigating, 
Guilhem.

The changelog entry is correct because it fixes a formerly made change.
0~20171227-0.1 intended to compile only udeb without threads:
"Build udeb without a dependency on pthreads"
But it unintentionally compiled the .deb executable with the .a compiled 
without threads.
The additional "make clean" fixes accidentally picking up the wrong .a.


Do I understand correctly that:
1) argon2 in testing isn't affected
2) this bug isn't solved yet, despite the closure?
3) the issue for cryptsetup is worked around in cryptsetup

libargon2-1 is linked by more packages. Are they all OK without this unintentional change unfixed? Why is the 
unintentional change not reverted or fixed?


There is no unintentional change. If packages are waiting for argon2 then I would prefer an unblock of both argon2 and 
cryptsetup at the same time. The version change seems major but the diff shows mostly build files changed.


I scheduled the build in time for the hard freeze but as the excuses system did not catch the bug severity/fixed changes 
it was not considered for migration.

Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Paul Gevers]

Hi,

[Release Team here]

On Thu, 2 Mar 2023 18:42:56 +0100 Bastian Germann  wrote:

On Thu, 2 Mar 2023 05:10:41 +0100 Guilhem Moulin  wrote:
> Ah no my bad, the changelog entry is probably incorrect and the
> cryptsetup-initramfs breakage is caused by the recent libargon2 upload
> indeed, but AFAICT not by anything particular in the upload.

I am sorry for having caused that issue, Daniel. Thanks for investigating, 
Guilhem.

The changelog entry is correct because it fixes a formerly made change.
0~20171227-0.1 intended to compile only udeb without threads:
"Build udeb without a dependency on pthreads"
But it unintentionally compiled the .deb executable with the .a compiled 
without threads.
The additional "make clean" fixes accidentally picking up the wrong .a.


Do I understand correctly that:
1) argon2 in testing isn't affected
2) this bug isn't solved yet, despite the closure?
3) the issue for cryptsetup is worked around in cryptsetup

libargon2-1 is linked by more packages. Are they all OK without this 
unintentional change unfixed? Why is the unintentional change not 
reverted or fixed?


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033008: texlive-extra-utils: make4ht - Error in odt conversion: Format error in the file, in the styles.xml

[Preuße]

On 15.03.2023 17:36, Andrey Spitsyn wrote:

Hi Andrey,


Please update TeX Live to up-to date version, because this bug fixed in
upsteam, see https://github.com/michal-h21/make4ht/issues/107
I'm building new packages now and would hand them over to you for testing.


Hilmar
--
sigfault

Bug#1026078: bullseye-pu: package ceph/14.2.21-1 CVE-2022-3650

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Dec 14, 2022 at 11:52:16AM +0100, Thomas Goirand wrote:
> I have prepared an update for Ceph in Bullseye to address
> CVE-2022-3650 (ie: ceph to root privilege escalation).
> The security team already told me that there will be no DSA.

Please go ahead with the distribution label fixed.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2

[Luca Boccassi]

On Wed, 15 Mar 2023 at 21:07, Jonathan Wiltshire  wrote:
>
> Control: tag -1 moreinfo
>
> Hi,
>
> On Wed, Dec 07, 2022 at 08:11:11PM +, Luca Boccassi wrote:
> > An improvement to reduce the number of dependencies pulled down by the
> > usr-merged debootstrapped image has been available in unstable,
> > bookworm and bullseye-backports for a while. I'd like to make this
> > improvement available in bullseye as well, as it saves ~50MB on a
> > minbase image. See:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025657
>
> This sounds like a behaviour change in stable, which would be very unusual
> unless it fixes significant issues. Can it really be justified?
>
> Thanks,

We already changed debootstrap's behaviour via p-u to add support for
merged-usr, these are further fixups to improve those changes, so I
think it is justified.

Kind regards,
Luca Boccassi

Bug#1026945: bullseye-pu: package guix/1.2.0-4

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Dec 24, 2022 at 07:33:38AM -0800, Vagrant Cascadian wrote:
> This fixes a FTBFS of due several test suites using expired OpenPGP
> keys. At the time the current packages in Debian were built, the keys
> had not yet expired, but was later fixed upstream:

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Wed, Dec 07, 2022 at 08:11:11PM +, Luca Boccassi wrote:
> An improvement to reduce the number of dependencies pulled down by the
> usr-merged debootstrapped image has been available in unstable,
> bookworm and bullseye-backports for a while. I'd like to make this
> improvement available in bullseye as well, as it saves ~50MB on a
> minbase image. See:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025657

This sounds like a behaviour change in stable, which would be very unusual
unless it fixes significant issues. Can it really be justified?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1033024: lios hangs when opening Preferences

[Gunnar Hjalmarsson]

Package: lios
Version: 2.7.2-4

Hi again Samuel!

My apologies for a somewhat vague bug report, but here we go:

There seems to be more issues with lios besides not specifying Gtk version.

The reason why I involved myself is that an Ubuntu user asked about the 
lios status on a mailing list. That made me add the patch to specify 
versions of imported libs, but the user keeps complaining. :/ This time 
about a freeze when opening Preferences. And I could reproduce that too.


I see that there are quite a few fixes upstream, and at the same time 
it's apparent that upstream does not care much about conventional 
releases. So I decided to create a new upstream tarball from the git 
repo and see if that improves things. I uploaded it to an Ubuntu PPA for 
now:


https://launchpad.net/~gunnarhj/+archive/ubuntu/lios

And yes, even if I don't really use the application, it no longer 
complains if I open the Preferences menu.


I'll check with the user and hear if they consider that version to be an 
improvement. If they do, I would like to get it into Ubuntu 23.04 at 
least. (Ubuntu is in the equivalent of "soft freeze" ATM.)


The question to you is if you would like me to add it to the repo and 
upload to experimental. Or do you possibly think that the release team 
would approve also this for Debian 12?


Let me know. I won't touch the Debian repo again until I know what you 
think.


--
Cheers,
Gunnar

Bug#1032985: unblock: gourmand/1.1.0+really1.1.0~rc3-3

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Wed, Mar 15, 2023 at 09:29:54AM +0100, Christian Marillat wrote:
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [ ] attach debdiff against the package in testing

Can we get the debdiff please?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1031410: bullseye-pu: package postgis/3.1.1+dfsg-1+deb11u1

[Sebastiaan Couwenberg]

Can we get this into the upcoming 11.7 point release?

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1033023: RFS: ipmiutil/3.1.9-1 -- IPMI management utilities

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ipmiutil" for upload into
experimental:

   Package name : ipmiutil
   Version  : 3.1.9-1
   URL  : https://sourceforge.net/projects/ipmiutil/
   License  : BSD-2-clause, BSD-3-clause, Zlib, Artistic-2.0, 
  GPL-2+ with OpenSSL exception, GPL-2+
   Vcs  : https://jff.email/cgit/ipmiutil.git
   Section  : utils

The source builds the following binary packages:

  ipmiutil - IPMI management utilities

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/i/ipmiutil/ipmiutil_3.1.9-1.dsc

or from 

 git https://jff.email/cgit/ipmiutil.git/?h=release%2Fdebian%2F3.1.9-1


Changes since the last upload:

 ipmiutil (3.1.9-1) unstable; urgency=medium
 .
   * New upstream release.
 - Refresh patches:
   + debian/patches/0700-init.patch
   + debian/patches/0705-crontab.patch
   + debian/patches/0105-typo.patch
   * Remove old patches:
 - debian/patches/0100-out-of-bounds.patch
 - debian/patches/0710-systemd.patch

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  HU6U7Z6H
Wire: @joergfringsfuerst
Skype:jff-skype@jff.email
Ring: jff
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1032847: unblock: intel-microcode/3.20230214.1

[Tobias Frost]

Control: tag -1 -moreinfo
> 
> On Sun, Mar 12, 2023 at 06:56:21PM +0100, Tobias Frost wrote:
> > I've uploaded intel-microcode to DELAYED/5, ETA will be Mar 17 ~18:00 CET
> > Please unblock package intel-microcode once it hits unstable.
> 
> Please remove the moreinfo tag from this bug when it's ready to review.

It's now in unstable.

-- 
tobi

Bug#1033022: firefox-esr: does not display web pages

[Vagrant Cascadian]

On 2023-03-15, Vagrant Cascadian wrote:
> After upgrading to the latest firefox-esr, all web pages fail to display
> anything...
...
> Are there any unversioned or missing dependencies on something that
> should also come from sid?

Apparently, it needs libnss3 2:3.89-1 from sid to work properly...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1033022: firefox-esr: does not display web pages

[Vagrant Cascadian]

Package: firefox-esr
Version: 102.9.0esr-1
Severity: grave
X-Debbugs-Cc: vagr...@debian.org

After upgrading to the latest firefox-esr, all web pages fail to display
anything... except those in my pinned tabs, although those also fail to do
anything other than display presumably cached content? Closing and
restarting the browser did not help. Rebooting did not help.

Downgrading to the version from bookworm(102.8.0esr-1), and everything
works again!

FWIW, I am running with MOZ_ENABLE_WAYLAND=1 under sway.

Are there any unversioned or missing dependencies on something that
should also come from sid? I typically run bookworm, but occasionally
pull in specific packages from sid as desired. This usually has worked
fine over many years, so it is a bit surprising!

live well,
  vagrant


-- Package-specific info:


-- Addons package information


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

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.6-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libgtk-3-0   3.24.37-2
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.4-2
ii  libx11-xcb1  2:1.8.4-2
ii  libxcb-shm0  1.15-1
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  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.2-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec59  7:5.1.2-3

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
ii  libgssapi-krb5-2   1.20.1-1
pn  pulseaudio 

-- no debconf information


signature.asc
Description: PGP signature

Bug#1033021: flash-kernel: support for qnap TS-412

[Graeme Vetterlein]

Package: flash-kernel
Version: 3.79
Severity: minor

Dear Maintainer,


NB the System Information below is incorrect. I'm actually running an old 
stretch build
here (buster would not install) but since it's working in stretch, I guess it's 
still be working
in later releases.


The file /usr/share/doc/flash-kernel/README.gz says:


If you would like to see support for another device, please file a bug


However I believe the QNAP TS-412 is already supported, so the README is simply
out of date ?  (I could be wrong, time may tell)



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

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

Bug#1033020: a2ps: v4.15+ shall switch to upstream-provided a2ps-lpr-wrapper

[Boyuan Yang]

Package: a2ps
Severity: normal
Version: 1:4.15.1-1~exp1

Upstream of a2ps is now providing a sane a2ps-lpr-wrapper, see
https://lists.gnu.org/archive/html/bug-a2ps/2023-03/msg3.html .
The new packaging shall use this wrapper instead of the one provided in
debian/ directory.

Thanks,
Boyuan Yang


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

Bug#1032994: unblock: node-webpack/5.76.1+dfsg1+~cs17.16.16-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Yadd,

On 15-03-2023 13:38, Yadd wrote:

[ Reason ]
node-webpack is vulnerable to cross-realm object access
(#1032904, CVE-2023-28154).


This doesn't look like a targeted fix, but rather seems to include much 
more.


How about reverting and providing a fix only for that CVE please?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032657: runit-services: connmand runscript

[Dimitris]

Hey Lorenzo,

Στις 15/3/23 18:29, ο/η Lorenzo έγραψε:

Do you have preference for the license? this package is under
BSD-3-clause but there are scripts under different license like CC0 or
GPL-3+ ..


just added a repo license : 
https://git.devuan.org/xinomilo/runscript-collection/src/branch/master/LICENSE 
, so tbh, don't really have any license preference.
connmand runscript in repo is just compiled parts from connmand sysv 
initscript and a random runit-services script (licensed cc0-1.0 iirc).

so, any license you think fits best, is ok by me.


thanks for all your runit/debian work :)
d.


OpenPGP_0xF634004775696B86_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992172: exim4: CVE-2021-38371

[Salvatore Bonaccorso]

Hello Andreas and Moritz,

On Wed, Mar 15, 2023 at 05:18:15PM +0100, Moritz Mühlenhoff wrote:
> Am Sun, Aug 15, 2021 at 07:21:40AM +0200 schrieb Andreas Metzler:
> > On 2021-08-14 Salvatore Bonaccorso  wrote:
> > > Source: exim4
> > > Version: 4.94.2-7
> > > Severity: important
> > > Tags: security upstream
> > > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > > 
> > 
> > > Hi,
> > 
> > > The following vulnerability was published for exim4, this is to start
> > > tracking the issue downstream for us. Note that at time of writing [2]
> > > gives still a 404.
> > 
> > > CVE-2021-38371[0]:
> > > | The STARTTLS feature in Exim through 4.94.2 allows response injection
> > > | (buffering) during MTA SMTP sending.
> > [...]
> > 
> > IIRC that is mitigated in experimental (4.95 rc) by ALPN and unkown
> > command related changes, I will not be able to check in detail for a
> > week or so, though.
> 
> Do you know if this is fixed in 4.96/bookworm?

Looks the planned advisory at
https://www.exim.org/static/doc/security/CVE-2021-38371.txt is not
online.

Looping in as well Heiko Schlittermann. Heiko, can you share details
on fixes?

Regards,
Salvatore

Bug#1032999: unblock: mesa/22.3.6-1

[Paul Gevers]

Hi Timo,

On 15-03-2023 19:15, Timo Aaltonen wrote:
There's actually 22.3.7 out, which I was thinking of uploading to sid, 


Is that following the freeze policy [1]? I.e. targeted fixes? (It might 
be, I don't know the release policy of mesa).


since it's the last release of the 22.3.x series. Maybe that should be 
requested to be unblocked instead once it's available?


Well, it's blocked by something else, having *this* version tested in 
unstable is worth quite a bit for us. So, please only upload that 
version if it meets the freeze policy.


Paul

[1] https://release.debian.org/testing/freeze_policy.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033019: unblock: mozjs102/102.9.0-1

[Jeremy Bícha]

Package: release.debian.org
Control: affects -1 + src:mozjs102
X-Debbugs-Cc: mozjs...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mozjs102

[ Reason ]
The new mozjs102 stable point release includes a security fix, CVE-2023-25751

[ Impact ]
mozjs102 is only used by gjs which in turn is used by GNOME Shell and
several GNOME apps written in JavaScript.

[ Tests ]
The build tests have passed successfully and the gjs autopkgtests
triggered by this upload have passed too. (mozjs102 itself
does not have autopkgtests yet).

I also completed the manual test cases from
https://wiki.ubuntu.com/DesktopTeam/TestPlans/gjs
on Debian Testing.

[ Risks ]

[ 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 ]
mozjs102 is the SpiderMonkey JavaScript engine from the current
Firefox ESR stable branch. There are monthly releases until August.

https://wiki.mozilla.org/Release_Management/Calendar

I am unaware of anyone using Firefox vulnerabilities to attack GNOME
Shell, but I think it's good to be prudent and apply available
security updates. I don't think the Debian Security Team has done
security uploads for mozjs*, in part because Mozilla's lifecycle is so
short that it's difficult for an upstream supported mozjs to be in a
Debian stable release.

For more info about the commits, see the Github mirror:
https://github.com/mozilla/gecko-dev/commits/esr102/js

unblock mozjs102/102.9.0-1

Thank you,
Jeremy Bicha
diff -Nru mozjs102-102.8.0/config/milestone.txt mozjs102-102.9.0/config/milestone.txt
--- mozjs102-102.8.0/config/milestone.txt	2023-02-15 10:26:31.0 +
+++ mozjs102-102.9.0/config/milestone.txt	2023-03-13 14:54:55.0 +
@@ -10,4 +10,4 @@
 # hardcoded milestones in the tree from these two files.
 #
 
-102.8.0
+102.9.0
diff -Nru mozjs102-102.8.0/debian/changelog mozjs102-102.9.0/debian/changelog
--- mozjs102-102.8.0/debian/changelog	2023-02-15 13:57:21.0 +
+++ mozjs102-102.9.0/debian/changelog	2023-03-13 15:03:53.0 +
@@ -1,3 +1,15 @@
+mozjs102 (102.9.0-1) unstable; urgency=high
+
+  [ Jeremy Bicha ]
+  * New upstream release
+- CVE-2023-25751: Incorrect code generation during JIT compilation
+
+  [ John Paul Adrian Glaubitz ]
+  * Disable large-arraybuffers/base.js on all big-endian targets
+(Closes: #1020700)
+
+ -- Jeremy Bicha   Mon, 13 Mar 2023 11:03:53 -0400
+
 mozjs102 (102.8.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru mozjs102-102.8.0/debian/rules mozjs102-102.9.0/debian/rules
--- mozjs102-102.8.0/debian/rules	2023-02-15 13:57:21.0 +
+++ mozjs102-102.9.0/debian/rules	2023-03-13 15:03:53.0 +
@@ -75,7 +75,7 @@
 endif
 
 # See: https://bugzilla.mozilla.org/show_bug.cgi?id=1755540
-ifneq (,$(findstring $(DEB_BUILD_ARCH),s390x))
+ifneq (,$(findstring $(DEB_BUILD_ARCH),powerpc ppc64 sparc64 s390x))
 	EXCLUDED_TESTS += large-arraybuffers/basic.js
 endif
 
diff -Nru mozjs102-102.8.0/js/src/devtools/automation/autospider.py mozjs102-102.9.0/js/src/devtools/automation/autospider.py
--- mozjs102-102.8.0/js/src/devtools/automation/autospider.py	2023-02-15 10:26:31.0 +
+++ mozjs102-102.9.0/js/src/devtools/automation/autospider.py	2023-03-13 14:54:55.0 +
@@ -8,15 +8,12 @@
 import json
 import logging
 import multiprocessing
-import re
 import os
 import platform
-import posixpath
 import shlex
 import shutil
 import subprocess
 import sys
-
 from collections import Counter, namedtuple
 from logging import info
 from os import environ as env
@@ -52,9 +49,6 @@
 # paths. So for direct subprocess.* invocation, use normal paths from
 # DIR, but when running under the shell, use POSIX style paths.
 DIR = directories(os.path, os.getcwd())
-PDIR = directories(
-posixpath, os.environ["PWD"], fixup=lambda s: re.sub(r"^(\w):", r"/\1", s)
-)
 
 AUTOMATION = env.get("AUTOMATION", False)
 
@@ -95,8 +89,8 @@
 "--objdir",
 type=str,
 metavar="DIR",
-# The real default must be set later so that OBJDIR and POBJDIR can be
-# platform-dependent strings.
+# The real default must be set later so that OBJDIR can be
+# relative to the srcdir.
 default=env.get("OBJDIR"),
 help="object directory",
 )
@@ -185,8 +179,6 @@
 OBJDIR = args.objdir or os.path.join(DIR.source, "obj-spider")
 OBJDIR = os.path.abspath(OBJDIR)
 OUTDIR = os.path.join(OBJDIR, "out")
-POBJDIR = args.objdir or posixpath.join(PDIR.source, "obj-spider")
-POBJDIR = posixpath.abspath(POBJDIR)
 MAKE = env.get("MAKE", "make")
 PYTHON = sys.executable
 
@@ -466,7 +458,7 @@
 
 env["MOZCONFIG"] = mozconfig
 
-mach = posixpath.join(PDIR.source, "mach")
+mach = os.path.join(DIR.source, "mach")
 
 if not args.nobuild:
 # Do the build
diff -Nru mozjs102-102.8.0/js/src/jit/CacheIR.cpp 

Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy

[Soren Stoutner]

I’m not sure I understand what point you are trying to make.

On Wednesday, March 15, 2023 12:35:07 PM MST Mezgani Ali wrote:
> Look Storen,
> 
> Qt WebEgine used 15 years ago for developing a Safari from scratch.
> Debian/GNU Linux is more GTK side than Qt.
> 
> 
> Kind regards,
> 
> Mezgani Ali
> +212 6 44 17 94 51
> ali.mezg...@nativelabs.ma
> https://wiki.debian.org/mezgani
> 
> ⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel.
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀
> ⠈⠳⣄⠀
> 
> > On 15/03/2023, at 19:52, Soren Stoutner  wrote:
> > 
> > Paul,
> > 
> > The point is that these security updates are added upstream, they are
> > regularly packaged in Debian, and it wouldn’t be any harder to support
> > them in Debian stable than security updates for any other browser.  Your
> > original email indicated that none of these three things were true.
> > 
> > Beyond that, you might find the following an interesting read (fairly
> > long, but the point is that, as per the Chromium maintainer, Qt WebEngine
> > has better coverage in Debian stable than Chromium does):
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255
> >  Privacy
> > Browser is not going to ship in Bookworm, but it will ship in Bookworm+1.
> >  Part of the reason why I have become one of the Qt maintainers is so
> > that it receives proper security support in stable (and oldstable as much
> > as possible, although there probably isn’t any web browser that currently
> > has good security coverage in oldstable).
> > 
> > Soren
> > 
> > On Wednesday, March 15, 2023 11:34:58 AM MST Dmitry Shachnev wrote:
> > > Hi all!
> > > 
> > > On Tue, Mar 14, 2023 at 06:41:55PM -0700, Soren Stoutner wrote:
> > > > Paul,
> > > > 
> > > > I /am/ one of the Debian Qt WebEngine maintainers, and I also submit
> > > > code
> > > > to the upstream Qt project.
> > > > 
> > > > The Salsa link you included appears to be a bit misinformed about
> > > > security
> > > > support for Qt WebEngine in Debian.  For more accurate information, I
> > > > would
> > > > point you to this link:
> > > > 
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794
> > > 
> > > Please note that this request is for a not-yet-released Debian version.
> > > 
> > > I am not sure the Release team will agree to have such updates in
> > > stable.
> > > Although, I would be happy to discuss this with them.
> > > 
> > > --
> > > Dmitry Shachnev
> > 
> > --
> > Soren Stoutner
> > so...@stoutner.com


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

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

Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy

[Mezgani Ali]

Look Storen,

Qt WebEgine used 15 years ago for developing a Safari from scratch. Debian/GNU 
Linux is more GTK side than Qt.


Kind regards,

Mezgani Ali
+212 6 44 17 94 51
ali.mezg...@nativelabs.ma
https://wiki.debian.org/mezgani

⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel.
⣾⠁⢠⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄⠀





> On 15/03/2023, at 19:52, Soren Stoutner  wrote:
> 
> Paul,
> 
> The point is that these security updates are added upstream, they are 
> regularly packaged in Debian, and it wouldn’t be any harder to support them 
> in Debian stable than security updates for any other browser.  Your original 
> email indicated that none of these three things were true.
> 
> Beyond that, you might find the following an interesting read (fairly long, 
> but the point is that, as per the Chromium maintainer, Qt WebEngine has 
> better coverage in Debian stable than Chromium does):
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255 
> 
> Privacy Browser is not going to ship in Bookworm, but it will ship in 
> Bookworm+1.  Part of the reason why I have become one of the Qt maintainers 
> is so that it receives proper security support in stable (and oldstable as 
> much as possible, although there probably isn’t any web browser that 
> currently has good security coverage in oldstable).
> 
> Soren
> 
> On Wednesday, March 15, 2023 11:34:58 AM MST Dmitry Shachnev wrote:
> > Hi all!
> >
> > On Tue, Mar 14, 2023 at 06:41:55PM -0700, Soren Stoutner wrote:
> > > Paul,
> > >
> > > I /am/ one of the Debian Qt WebEngine maintainers, and I also submit code
> > > to the upstream Qt project.
> > >
> > > The Salsa link you included appears to be a bit misinformed about security
> > > support for Qt WebEngine in Debian.  For more accurate information, I
> > > would
> > > point you to this link:
> > >
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794
> >
> > Please note that this request is for a not-yet-released Debian version.
> >
> > I am not sure the Release team will agree to have such updates in stable.
> > Although, I would be happy to discuss this with them.
> >
> > --
> > Dmitry Shachnev
> 
> 
> --
> Soren Stoutner
> so...@stoutner.com

Bug#1033017: RFS: dmidecode/3.5-1 -- SMBIOS/DMI table decoder

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dmidecode" for upload into
experimental:

   Package name : dmidecode
   Version  : 3.5-1
   Upstream contact : dmidecode-de...@nongnu.org
   URL  : https://nongnu.org/dmidecode/
   License  : GPL-2+
   Vcs  : https://jff.email/cgit/dmidecode.git/
   Section  : utils

The source builds the following binary packages:

  dmidecode - SMBIOS/DMI table decoder
  dmidecode-udeb - SMBIOS/DMI table decoder (udeb)

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/d/dmidecode/dmidecode_3.5-1.dsc

or from 

 git https://jff.email/cgit/dmidecode.git/?h=release%2Fdebian%2F3.5-1


Changes since the last upload:

 dmidecode (3.5-1) unstable; urgency=medium
 .
   * New upstream release (Closes: #1032980).
   * Declare compliance with Debian Policy 4.6.2.0 (No changes needed).
   * debian/copyright:
 - Add year 2023 to myself.

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  HU6U7Z6H
Wire: @joergfringsfuerst
Skype:jff-skype@jff.email
Ring: jff
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1030704: extra-package doesn't work with autopkgtest-virt-server=docker

[Christian Kastner]

Hi,

On 2023-02-06 17:33, Shengjing Zhu wrote:
> +--+
> | Update chroot   
>  |
> +--+
> 
> Get:1 
> file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive
>  ./ InRelease
> Ign:1 
> file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive
>  ./ InRelease
> Get:2 
> file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive
>  ./ Release [603 B]
> Get:2 
> file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive
>  ./ Release [603 B]
> Get:3 
> file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive
>  ./ Release.gpg
> Ign:3 
> file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive
>  ./ Release.gpg
> Get:4 
> file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive
>  ./ Packages [999 B]
> Err:4 
> file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive
>  ./ Packages
>   Could not open file 
> /var/lib/apt/lists/partial/_build_golang-github-coredhcp-coredhcp-xIXI4Z_resolver-dcoFh4_apt%5farchive_._Packages
>  - open (13: Permission denied)
> ...
> Fetched 440 kB in 2s (289 kB/s)
> Reading package lists...
> E: Failed to fetch 
> store:/var/lib/apt/lists/partial/_build_golang-github-coredhcp-coredhcp-xIXI4Z_resolver-dcoFh4_apt%5farchive_._Packages
>   Could not open file 
> /var/lib/apt/lists/partial/_build_golang-github-coredhcp-coredhcp-xIXI4Z_resolver-dcoFh4_apt%5farchive_._Packages
>  - open (13: Permission denied)
> E: Some index files failed to download. They have been ignored, or old ones 
> used instead.

Is it possible that you are running with umask 0027? If you, can you try
with umask 0022?

I ran into a similar issue in autopkgtest, and I think they could be
related. See [1].

Best,
Christian

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

Bug#1033016: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: debian-edu-router
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# debian-edu-router po-debconf translation to Spanish
# Copyright (C) 2023 debian-edu-router
# This file is distributed under the same license as the debian-edu-router 
package.
# Camaleón , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: debian-edu-router\n"
"Report-Msgid-Bugs-To: debian-edu-rou...@packages.debian.org\n"
"POT-Creation-Date: 2023-01-29 21:22+0100\n"
"PO-Revision-Date: 2023-03-05 13:13+0100\n"
"Language-Team: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"
"Last-Translator: Camaleón \n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"Language: es\n"

#. Type: title
#. Description
#: ../debian-edu-router-config.templates:1001
msgid "Debian Edu Router Configuration"
msgstr "Configuración de Debian Edu Router"

#. Type: boolean
#. Description
#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:3001
#: ../debian-edu-router-config.templates:4001
msgid "Do you want to skip Debian Edu Router networking configuration?"
msgstr "¿Desea omitir la configuración de red de Debian Edu Router?"

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:3001
msgid ""
"ERROR: Not enough usable network interfaces available for setting up the "
"router!"
msgstr ""
"ERROR: No hay suficientes interfaces de red disponibles que se puedan "
"utilizar para configurar el enrutador."

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:4001
msgid ""
"ERROR: Not enough unconfigured network interfaces available for setting up "
"the router!"
msgstr ""
"ERROR: No hay suficientes interfaces de red sin configurar que se encuentren "
"disponibles para configurar el enrutador."

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:4001
msgid ""
"The following interfaces were found already configured in files not managed "
"by Debian Edu Router:"
msgstr ""
"Se han encontrado las siguientes interfaces de red ya configuradas en "
"archivos no gestionados por Debian Edu Router:"

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:4001
msgid "${non_d_e_r_ifaces}"
msgstr "${non_d_e_r_ifaces}"

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:4001
msgid "Please consider unconfiguring these interfaces and re-try again."
msgstr "Considere desconfigurar estas interfaces de red y vuelva a intentarlo."

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:5001
msgid "Please disconnect all network cables from this host now and proceed."
msgstr "Desconecte todos los cables red de este equipo ahora y proceda."

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:5001
msgid ""
"NOTE: For the requested step-by-step setup, please start with all network "
"cables disconnected."
msgstr ""
"NOTA: Para proceder con la configuración paso a paso, inicie con todos los "
"cables de red desconectados."

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:5001
msgid ""
"You have ${num_tries} try left to unplug all network cables until the step-"
"by-step setup will be aborted."
msgstr ""
"Dispone de ${num_tries} intentos más para desconectar todos los cables de "
"red antes de que se aborte la configuración paso a paso."

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:6001
msgid "The networking cables were not unplugged. Sending you back to the"
msgstr "No se han desconectado los cables de red. Volviendo a la"

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:6001
msgid "first question."
msgstr "primera pregunta."

#. Type: select
#. Choices
#: ../debian-edu-router-config.templates:7001
msgid "Yes"
msgstr "Sí"

#. Type: select
#. Choices
#: ../debian-edu-router-config.templates:7001
msgid "Abort"
msgstr "Abortar"

#. Type: select
#. Description
#: ../debian-edu-router-config.templates:7002
msgid "Do you want to enable IP packet forwarding?"
msgstr "¿Desea activar el reenvío de paquetes IP?"

#. Type: select
#. Description
#: ../debian-edu-router-config.templates:7002
msgid ""
"The routing part of 'Debian Edu Router' requires IP packets to be forwarded "
"back and forth between network interfaces by the kernel. This is mandatory "
"and without it the router simply won't work. If you select 'Abort' this "
"package will be left unconfigured. To undo its half-installed state, remove/"
"purge it again."
msgstr ""
"La configuración del enrutado de «Debian Edu Router» requiere que el núcleo "
"reenvíe los paquetes IP de un lado a otro entre las interfaces de red. Esto "
"es obligatorio y sin ello el enrutador simplemente no funcionará. Si elige "
"«Abortar» este paquete quedará sin configurar. Para deshacer el estado de "
"semi-instalado del paquete, 

Bug#1022256: upgrade-reports: gnustep-base-common blocks upgrade from bullseye to bookworm because of version dependencies

[Yavor Doganov]

Control: tags -1 moreinfo unreproducible

Please accept my apologies that it took me so long to react.

On Sun, 23 Oct 2022 09:55:58 +0300,
Paul Gevers wrote:
> On 22-10-2022 22:06, Daniel Savi wrote:
> > My previous release is: bullseye
> > I am upgrading to: bookworm
> > Archive date: unknown
> > Upgrade date: 10-22-22
> > 
> > - Did any packages fail to upgrade?
> > gnustep-base-common could not be upgraded due to a versioning
> > conflict. Happened on two independent systems. The upgrade to
> > bookworm failed for that reason.  Removing gnustep-base-common
> > prior to the upgrade helped.

Unfortunately I could not reproduce this on an i386 machine.  I made a
fresh standard install of bullseye and then installed the "gnustep"
package.  Afterwards I upgraded to bookworm with the usual procedure
(apt upgrade; apt full-upgrade) -- everything went smoothly.

Daniel, could you please provide logs and/or more information, perhaps
some unusual setup or specific combination of installed packages that
triggers the problem?

Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)

[Jose M Calhariz]

On 3/13/23 13:16, Kamil Jońca wrote:

"Debian Bug Tracking System"  writes:


Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1032884: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032884.


dpkg -l "amanda*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==
un  amanda   (no description available)
ii  amanda-client  1:3.5.1-9+b1 amd64Advanced Maryland Automatic 
Network Disk Archiver (Client)
ii  amanda-common  1:3.5.1-9+b1 amd64Advanced Maryland Automatic 
Network Disk Archiver (Libs)
ii  amanda-server  1:3.5.1-10   amd64Advanced Maryland Automatic 
Network Disk Archiver (Server)


Work properly, so this is kind a regression.

KJ



Hi


What dumptypes do you use in amanda?


I am preparing one update to fix a regression and I would like to know 
your situation is covered by my fix.



Kind regards

Jose M Calhariz

Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy

[Soren Stoutner]

Paul,

The point is that these security updates /are/ added upstream, they /are 
/regularly 
packaged in Debian, and it wouldn’t be any harder to support them in Debian 
stable than 
security updates for any other browser.  Your original email indicated that 
none of these 
three things were true.

Beyond that, you might find the following an interesting read (fairly long, but 
the point is 
that, as per the Chromium maintainer, Qt WebEngine has better coverage in 
Debian stable 
than Chromium does):

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

Privacy Browser is not going to ship in Bookworm, but it will ship in 
Bookworm+1.  Part of 
the reason why I have become one of the Qt maintainers is so that it receives 
proper 
security support in stable (and oldstable as much as possible, although there 
probably isn’t 
any web browser that currently has good security coverage in oldstable).

Soren

On Wednesday, March 15, 2023 11:34:58 AM MST Dmitry Shachnev wrote:
> Hi all!
> 
> On Tue, Mar 14, 2023 at 06:41:55PM -0700, Soren Stoutner wrote:
> > Paul,
> > 
> > I /am/ one of the Debian Qt WebEngine maintainers, and I also submit code
> > to the upstream Qt project.
> > 
> > The Salsa link you included appears to be a bit misinformed about security
> > support for Qt WebEngine in Debian.  For more accurate information, I
> > would
> > point you to this link:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794
> 
> Please note that this request is for a not-yet-released Debian version.
> 
> I am not sure the Release team will agree to have such updates in stable.
> Although, I would be happy to discuss this with them.
> 
> --
> Dmitry Shachnev


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


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


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

Bug#1033015: Minor issues in debian/rules [patch]

[Daniel Richard G.]

Package: chromium
Version: 111.0.5563.64-1
Severity: minor

I've been experimenting with building the latest Debian chromium package
on Ubuntu 22.04, and in the course of that have found a couple of minor
issues in the debian/rules file:

* The flags added by optimize=+lto in DEB_BUILD_MAINT_OPTIONS will
  cause every compile invocation to print "optimization flag
  '-ffat-lto-objects' is not supported" warnings (as the dpkg LTO flags
  are meant for GCC, not Clang), and balloon the RAM required for the
  final link from ~2.5 GB to ~30 GB. The link will also require much
  more time to complete; on my fairly beefy test system, it went from
  under a minute to four hours.

  Disabling this explicitly before Debian enables LTO system-wide would
  be a good move, in my view. On Ubuntu, LTO is already the default, and
  without adding this bit, the package is difficult to build in their
  infrastructure due to the resource requirements.

* LDFLAGS is set without obtaining an initial value from
  dpkg-buildflags(1).

The attached patch addresses both issues.

Side note: You may want to consider enabling ThinLTO, by setting
use_thin_lto=true and unsetting concurrent_links. The final link
requires only ~10.5 GB RAM, and completes within minutes.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.--- chromium-111.0.5563.64/debian/rules.orig	2023-03-02 01:24:58.0 +
+++ chromium-111.0.5563.64/debian/rules	2023-03-15 08:15:54.485885154 +
@@ -6,6 +6,9 @@
 # enable all build hardening flags
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+# disable lto flags, as they are for gcc, not clang
+export DEB_BUILD_MAINT_OPTIONS+=optimize=-lto
+
 # indicate that binary targets do not require root
 export DEB_RULES_REQUIRES_ROOT=no
 
@@ -15,12 +18,13 @@
 export CC=clang
 export CXX=clang++
 
-# more verbose linker output
-export LDFLAGS+=-Wl,--stats
-
 # initial flags from dpkg-buildflags
 export DEB_CXXFLAGS_MAINT_STRIP=-g
 export CXXFLAGS=$(shell dpkg-buildflags --get CXXFLAGS)
+export LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
+
+# more verbose linker output
+export LDFLAGS+=-Wl,--stats
 
 # extra flags to reduce warnings that aren't very useful
 export CXXFLAGS+=-Wno-conversion \

Bug#1032387: aide: Cron job does not send mail with new _aide user

[Guillem Jover]

On Wed, 2023-03-15 at 14:39:35 +0100, Guillem Jover wrote:
> On Wed, 2023-03-15 at 04:39:14 +0100, Guillem Jover wrote:
> > On Tue, 2023-03-14 at 21:36:01 +0100, Marc Haber wrote:
> > > Where is it hardcoded? I have only seen code that honors what's read in
> > > from defaults.
> > > 
> > > That variable was renamed to AIDEUSER just in case there is a conflict
> > > with the pre-set USER variable.
> > > 
> > > > Ideally USER would get automatically
> > > > set instead of hardcoding it to root though, as that makes a check fail,
> > > > say with USER=$(id -u -n) or similar. Will prepare another patch with
> > > > that too.

Ah, checking now the actual change to use AIDEUSER instead that you
mentioned above, then all my previous checks are not relevant here, as
there is definitely nothing else setting that envvar, so my original
comment is more relevant now than before, as AIDEUSER not being set will
always end up using the default "root", which will definitely be wrong
when being called as user _aide. So I think the above proposal to initialize
it from id(1) would be the better default, say:

,---
AIDEUSER="${AIDEUSER:-$(id -u -n)}"
`---

or even:

,---
: "${AIDEUSER:=$(id -u -n)}"
`---

If the user has set it explicitly in the default file, it gets
honored, otherwise whatever the current user is, then that gets used
to check the permissions on disk, which is what I said we want?

Thanks,
Guillem

Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)

[Jose M Calhariz]

On 3/15/23 18:29, Kamil Jońca wrote:

Jose M Calhariz  writes:


On 3/13/23 13:16, Kamil Jońca wrote:

"Debian Bug Tracking System"  writes:


Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1032884: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032884.


dpkg -l "amanda*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==
un  amanda   (no description available)
ii  amanda-client  1:3.5.1-9+b1 amd64Advanced Maryland Automatic 
Network Disk Archiver (Client)
ii  amanda-common  1:3.5.1-9+b1 amd64Advanced Maryland Automatic 
Network Disk Archiver (Libs)
ii  amanda-server  1:3.5.1-10   amd64Advanced Maryland Automatic 
Network Disk Archiver (Server)


Work properly, so this is kind a regression.

KJ



Hi


What dumptypes do you use in amanda?



--8<---cut here---start->8---
define dumptype gnutar-base {
 compress client custom
 client-custom-compress "/usr/local/lib/amanda/xz9"
 encrypt client
 client-encrypt "/usr/local/lib/amanda/encgpg"
 index yes
 program "GNUTAR"
 maxpromoteday 30
}
define dumptype gnutar-local {
 gnutar-base
 auth "local"
}

define dumptype gnutar-bsdtcp {
 gnutar-base
 auth "bsdtcp"
}
define dumptype gnutar-bsdtcp-nocomp {
 gnutar-bsdtcp
 compress none
}

define dumptype gnutar-local-nocomp {
 gnutar-local
 compress none
}
--8<---cut here---end--->8---

"/usr/local/lib/amanda/xz9"   = exec /usr/bin/xz "$@"

"/usr/local/lib/amanda/encgpg" = exec gpg -e  (in case of dumping)
  


Thank you, your problem is known and will be fixed on the next upload.


Kind regards

Jose M Calhariz

Bug#1033014: debcargo: debian/debcargo.toml should permit including extra features for dh_auto_test

[Daniel Kahn Gillmor]

Package: debcargo
Version: 2.6.0-2+b1
Control: affects -1 + src:rust-sequoia-net dh-cargo

debcargo's dh_auto_test fails by default for rust-sequoia-net version
0.26.0 unless i override it in debian/rules.  I think i ought to be able
to specify the particular additional thing i need in
debian/debcargo.toml and not have to port any sort of automated
difference from debcargo-generated debian/rules.

rust-sequoia-net 0.26.0 is in debian experimental at the moment.  It is
a library crate.  debcargo and dh-cargo together make it so that
dh_auto_test runs "cargo build" during build-time testing.

rust-sequoia-net depends on rust-sequoia-openpgp, and
rust-sequoia-openpgp requires that one of its "crypto-*" features be
enabled in order to work.

Currently, this works because i've made it use the following debian/rules:

```
#!/usr/bin/make -f
%:
dh $@ --buildsystem cargo

# see https://gitlab.com/sequoia-pgp/sequoia/-/issues/990
override_dh_auto_test:
dh_auto_test -- --features sequoia-openpgp/crypto-nettle
```

I see a couple different ways that this could be fixed:

 - instead of doing "cargo build" during dh_auto_test for library
   crates, it could do "cargo test", without -Zavoid-dev-deps -- i don't
   fully understand how much this would risk breaking other packages
   that use the same framework, though.

 - alternately, maybe i could declaratively specify in debcargo
   any additional features to append to `dh_auto_test`.

This might belong to dh-cargo, and not debcargo -- or maybe it's
something that needs to be addressed in both places.

  --dkg


signature.asc
Description: PGP signature

Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy

[Dmitry Shachnev]

Hi all!

On Tue, Mar 14, 2023 at 06:41:55PM -0700, Soren Stoutner wrote:
> Paul,
>
> I /am/ one of the Debian Qt WebEngine maintainers, and I also submit code
> to the upstream Qt project.
>
> The Salsa link you included appears to be a bit misinformed about security
> support for Qt WebEngine in Debian.  For more accurate information, I would
> point you to this link:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794

Please note that this request is for a not-yet-released Debian version.

I am not sure the Release team will agree to have such updates in stable.
Although, I would be happy to discuss this with them.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)

[Kamil Jońca]

Jose M Calhariz  writes:

> On 3/13/23 13:16, Kamil Jońca wrote:
>> "Debian Bug Tracking System"  writes:
>>
>>> Thank you for filing a new Bug report with Debian.
>>>
>>> You can follow progress on this Bug here: 1032884: 
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032884.
>>>
>> dpkg -l "amanda*"
>> Desired=Unknown/Install/Remove/Purge/Hold
>> | 
>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>> ||/ Name   Version  Architecture Description
>> +++-==---==
>> un  amanda   (no description available)
>> ii  amanda-client  1:3.5.1-9+b1 amd64Advanced Maryland Automatic 
>> Network Disk Archiver (Client)
>> ii  amanda-common  1:3.5.1-9+b1 amd64Advanced Maryland Automatic 
>> Network Disk Archiver (Libs)
>> ii  amanda-server  1:3.5.1-10   amd64Advanced Maryland Automatic 
>> Network Disk Archiver (Server)
>>
>>
>> Work properly, so this is kind a regression.
>>
>> KJ
>>
>>
> Hi
>
>
> What dumptypes do you use in amanda?
>
>
--8<---cut here---start->8---
define dumptype gnutar-base {
compress client custom
client-custom-compress "/usr/local/lib/amanda/xz9"
encrypt client
client-encrypt "/usr/local/lib/amanda/encgpg"
index yes
program "GNUTAR"
maxpromoteday 30
}
define dumptype gnutar-local {
gnutar-base
auth "local"
}

define dumptype gnutar-bsdtcp {
gnutar-base
auth "bsdtcp"
}
define dumptype gnutar-bsdtcp-nocomp {
gnutar-bsdtcp
compress none
}

define dumptype gnutar-local-nocomp {
gnutar-local
compress none
}
--8<---cut here---end--->8---

"/usr/local/lib/amanda/xz9"   = exec /usr/bin/xz "$@"

"/usr/local/lib/amanda/encgpg" = exec gpg -e  (in case of dumping)
 
-- 
http://wolnelektury.pl/wesprzyj/teraz/

Bug#1032999: unblock: mesa/22.3.6-1

[Timo Aaltonen]

Simon McVittie kirjoitti 15.3.2023 klo 16.40:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: m...@packages.debian.org
Control: affects -1 + src:mesa
Control: block -1 by 1032887

Please consider unblocking package mesa.

[ Reason ]
New upstream bugfix release, fixing #1029731 (RC) and many more.

[ Impact ]
If not accepted, bookworm will ship with various avoidable crashes and
hangs in the graphics driver stack.

[ Tests ]
Has been in unstable for 17 days, currently no RC bugs.

[ Risks ]
I'll leave this for the Mesa maintainers to answer...

[ Checklist ]
   [x] all changes are documented in the d/changelog
   [ ] I reviewed all changes and I approve them
   [x] attach debdiff against the package in testing

[ Other info ]
I am not a maintainer of this package, just an interested user.

This can't migrate until llvm-toolchain-15 does (see #1032887, which I
believe is only waiting for a maintainer re-upload with build artifacts
excluded).

unblock mesa/22.3.6-1



Hi,

There's actually 22.3.7 out, which I was thinking of uploading to sid, 
since it's the last release of the 22.3.x series. Maybe that should be 
requested to be unblocked instead once it's available?


--
t

Bug#1032972: handbrake: debian version of handbrake does NOT handle subtitles correctly

[js jb]

I've installed the snapshot version of handbrake from handbrake.fr directly 
(via flatpak)and verified that on the same DVDs, it generates the subtitles 
perfectly.
I also built the debian version of handbrake from source and that one still has 
the same problems.One can also see the subtitles overlaying each other so that 
in rapid dialog multiple subtitles appearone on top of each other, making them 
all illegible.  This does not happen in the handbrake snaphshot.
thanks,--jack

Bug#1032999: unblock: mesa/22.3.6-1

[Simon McVittie]

On Wed, 15 Mar 2023 at 14:40:27 +, Simon McVittie wrote:
>   [x] attach debdiff against the package in testing

Sorry, here's the debdiff, filtered to exclude .pick_status.json (which is
used upstream to track which changes should/should not be backported).

smcv


mesa_22.3.6-1-debdiff.diff.gz
Description: application/gzip

Bug#755494: libmpd: diff for NMU version 11.8.90+git20130319-0.1

[Boyuan Yang]

X-Debbugs-CC: m...@emillon.org

Hi Etienne,

On Tue, 31 Jan 2023 15:04:29 -0500 Boyuan Yang  wrote:
> X-Debbugs-CC: m...@emillon.org
> 
> Hi Etienne,
> 
> On Mon, 21 Jul 2014 13:16:23 +0200 Etienne Millon  wrote:
> > Package: libmpd
> > Version: 0.20.0-1.1
> > Severity: normal
> > Tags: patch pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for libmpd (versioned as
> > 11.8.90+git20130319-0.1). As you are in the low threshold NMU list,
> > I'm looking to upload it without delay. Sorry for the large diff, this
> > is a new upstream version (reason is explained in #749055).
> > 
> > A source package can be found here while I am contacting sponsors:
> > 
> >
>
http://mentors.debian.net/debian/pool/main/libm/libmpd/libmpd_11.8.90+git20130319-0.1.dsc
> > 
> > It also seems that you are MIA; if that is confirmed I can adopt the
> > package and freshen the packaging: hardening, watch file, S-V, remove
> > quilt, etc.
> 
> I checked upstream homepage and could not find any link to the git
> development repo. Instead, I could only find a released tarball of
v11.8.17,
> but it seems still earlier than the v11.8.90 you provided. Do you have any
> idea about where I could find the upstream git repo that matches the
> snapshot you provided?

Just to let you know, Debian now has libmpd 11.8.17 packaged. You may find
its details at https://tracker.debian.org/pkg/libmpd . If any newer version
is needed, please let me know.

Best,
Boyuan Yang


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

Bug#1009303: imv: Upstream homepage has moved, and incorrect watch file

[Paride Legovini]

On Mon, 11 Apr 2022 11:05:48 +0200 Gard Spreemann  wrote:
> Package: imv
> Version: 4.3.0-1
> Severity: minor
> X-Debbugs-Cc: g...@nonempty.org
> 
> Dear Maintainer,
> 
> The package currently has
> 
>  Homepage: https://github.com/eXeC64/imv
> 
> while upstream has moved to
> 
>  https://sr.ht/~exec64/imv/
> 
> This also causes d/watch to monitor stale sources for new releases.

Thank you, unfortunately I missed version 4.4.0 because of this.
Now Debian is frozen, I'll fix the upstream location and package
the latest upstream version once the new development cycle opens.

Paride

Bug#1018061: pads: segfault at 3a ip

[Tim McConnell]

Hi Benhard, 
Okay patch installed, the output is in the attached file.
I was already on 1.2-14 so we'll see if the patch helped or if it was
needed by me. 

-- 
Tim McConnell 


On Wed, 2023-03-15 at 12:10 +0100, Bernhard Übelacker wrote:
> Am 26.02.23 um 16:47 schrieb Tim McConnell:
> 
> > Hi Bernhard,
> > The delay is fine, I'm sure it takes a minute to figure it out ;-)
> > and
> > no I didn't have anything other than defaults for GDB set. I'm not
> > a
> > programmer so I don't know all the tricks to GDB or when is best  
> > to
> > use them. With that said, how would I go about installing /testing
> > the
> > patch you provide? I'm happy to test it out for you, I just need
> > the
> > knowledge of how to.
> > Thanks!
> > 
> 
> 
> Hello Tim,
> if you are fine with installing a bunch of build dependencies
> you could use following steps to rebuild the package with the patch.
> 
> As root:
> # apt build-dep pads
> 
> As user:
> $ mkdir -p source/pads
> 
> Put attached patch to the new directory and continue as user:
> $ cd   source/pads
> $ apt source pads
> $ cd pads-1.2/
> $ patch -p1 < ../pads_print_arp_asset_initialize.patch
> $ dpkg-buildpackage -b
> 
> As root (with the directory adjusted to your user):
> # dpkg -i /home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-
> dbgsym_1.2-14_amd64.deb}
> 
> 
> And then see if it still works as expected and see
> if the crash happens again.
> 
> Kind regards,
> Bernhard
  |  ^~~~
identification.c:325:26: note: in expansion of macro ‘bdata’
  325 | strlcat(app, bdata(sig->title.misc), MAX_MISC);
  |  ^
util.h:56:39: note: expected ‘const char *’ but argument is of type ‘unsigned 
char *’
   56 | size_t strlcat(char *dst, const char *src, size_t len);
  |   ^~~
identification.c: In function ‘parse_raw_signature’:
identification.c:130:14: warning: ‘title’ may be used uninitialized 
[-Wmaybe-uninitialized]
  130 | if (title->qty < 3)
  | ~^
identification.c:94:22: note: ‘title’ was declared here
   94 | struct bstrList *title;
  |  ^
identification.c:170:8: warning: ‘pcre_string’ may be used uninitialized 
[-Wmaybe-uninitialized]
  170 | if (pcre_string != NULL)
  |^
identification.c:96:13: note: ‘pcre_string’ was declared here
   96 | bstring pcre_string;
  | ^~~
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib  -Wdate-time -D_FORTIFY_SOURCE=2   
-g -O2 -ffile-prefix-map=/home/tmick/source/pads/pads-1.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -g -std=gnu89 
-c -o packet.o packet.c
In file included from /usr/include/netinet/in.h:21,
 from global.h:69,
 from packet.h:44,
 from packet.c:28:
/usr/include/features.h:194:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE 
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
  194 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use 
_DEFAULT_SOURCE"
  |   ^~~
packet.c: In function ‘process_arp’:
packet.c:160:46: warning: pointer targets in passing argument 2 of 
‘check_arp_asset’ differ in signedness [-Wpointer-sign]
  160 | if (check_arp_asset(ip_addr, arph->arp_sha) == 1) {
  |  ^
  |  |
  |  uint8_t * {aka unsigned 
char *}
In file included from packet.h:45:
storage.h:58:51: note: expected ‘char *’ but argument is of type ‘uint8_t *’ 
{aka ‘unsigned char *’}
   58 | int check_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN]);
  |  ~^
packet.c:161:44: warning: pointer targets in passing argument 2 of 
‘add_arp_asset’ differ in signedness [-Wpointer-sign]
  161 | add_arp_asset(ip_addr, arph->arp_sha, 0);
  |^
  ||
  |uint8_t * {aka unsigned char 
*}
storage.h:60:50: note: expected ‘char *’ but argument is of type ‘uint8_t *’ 
{aka ‘unsigned char *’}
   60 | void add_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN], 
time_t discovered);
  | ~^
packet.c:162:47: warning: pointer targets in passing argument 2 of 
‘print_arp_asset’ differ in signedness [-Wpointer-sign]
  162 | print_arp_asset (ip_addr, arph->arp_sha);
  |   ^
  |   |
  |   uint8_t * {aka unsigned 
char *}
In file included from pads.h:52,
 from util.h:42,
 from mac-resolution.h:40,
 

Bug#1033013: execsnoop truncates arguments output

[Antoine Beaupre]

Package: libbpf-tools
Version: 0.26.0+ds-1
Severity: normal
File: /usr/sbin/execsnoop

execsnoop is super useful, but fails rather ungracefully if the
commandline argument is longer than 128 characters.

i have tried to improve that with a patch, but couldn't figure out
why.

execsnoop.bt in the bpftrace package doesn't suffer from this
limitation, so it's not a problem in the kernel itself.

See also: https://github.com/iovisor/bcc/issues/740


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

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

Versions of packages libbpf-tools depends on:
ii  libc62.36-8
ii  libelf1  0.188-2.1
ii  zlib1g   1:1.2.13.dfsg-1

libbpf-tools recommends no packages.

libbpf-tools suggests no packages.

-- no debconf information

Bug#1033012: /usr/libexec/miniupnpd-startstop-helper.sh: 12: Cannot fork

[Michael Deegan]

Package: miniupnpd
Version: 2.3.1-1
Severity: normal

Dear Maintainer,

Not sure what changed, but miniupnp no longer knows how to create and update
its iptables chains, rendering the service useless.

   Mar 16 00:26:11 yipyap systemd[1]: Starting UPnP Internet Gateway Device 
Daemon...
   Mar 16 00:26:11 yipyap miniupnpd-startstop-helper.sh[16295]: 
/usr/libexec/miniupnpd-startstop-helper.sh: 12: Cannot fork
   Mar 16 00:26:11 yipyap miniupnpd-startstop-helper.sh[16294]: Warning: no 
interface defined
   Mar 16 00:26:11 yipyap systemd[1]: miniupnpd.service: Can't open PID file 
/run/miniupnpd.pid (yet?) after start: Operation not permitted
   Mar 16 00:26:11 yipyap miniupnpd[16298]: HTTP listening on port 38765
   Mar 16 00:26:11 yipyap systemd[1]: Started UPnP Internet Gateway Device 
Daemon.
   Mar 16 00:26:11 yipyap miniupnpd[16298]: no HTTP IPv6 address, disabling IPv6

Perusing miniupnpd-startstop-helper.sh makes it clear that its absence is a 
problem! :)

It also looks like systemd is complaining that miniupnpd is forking before
it has finished writing its pidfile.

I also noticed in kernel log:

   Mar 16 00:26:11 yipyap kernel: [ 4637.252634] cgroup: fork rejected by pids 
controller in /system.slice/miniupnpd.service

So I did `systemctl edit miniupnpd.service`, and bumped TasksMax to some
unreasonable number. This only helps a little:

   Mar 16 00:30:48 yipyap systemd[1]: Starting UPnP Internet Gateway Device 
Daemon...
   Mar 16 00:30:48 yipyap miniupnpd-startstop-helper.sh[19317]: Warning: no 
interface defined
   Mar 16 00:30:48 yipyap systemd[1]: miniupnpd.service: Can't open PID file 
/run/miniupnpd.pid (yet?) after start: Operation not permitted
   Mar 16 00:30:48 yipyap miniupnpd[19380]: HTTP listening on port 38655
   Mar 16 00:30:48 yipyap systemd[1]: Started UPnP Internet Gateway Device 
Daemon.
   Mar 16 00:30:49 yipyap miniupnpd[19380]: no HTTP IPv6 address, disabling IPv6

Next problem!  /usr/libexec/miniupnpd-startstop-helper.sh seems to assume
$CONFFILE is defined at some point.  The only point I can see it being set
is within the init.d script, which is unused because we're running systemd
here.  So as a workaround I add `CONFFILE=/etc/miniupnpd/miniupnpd.conf` to
/etc/default/miniupnpd. This only helps a little:

   Mar 16 00:34:25 yipyap systemd[1]: Starting UPnP Internet Gateway Device 
Daemon...
   Mar 16 00:34:25 yipyap miniupnpd-startstop-helper.sh[20600]: 
/usr/libexec/miniupnpd-startstop-helper.sh: 24: read_config: not found
   Mar 16 00:34:25 yipyap miniupnpd-startstop-helper.sh[20601]: 
/usr/libexec/miniupnpd-startstop-helper.sh: 25: read_config: not found
   Mar 16 00:34:25 yipyap miniupnpd-startstop-helper.sh[20595]: Warning: no 
interface defined
   Mar 16 00:34:25 yipyap systemd[1]: miniupnpd.service: Can't open PID file 
/run/miniupnpd.pid (yet?) after start: Operation not permitted
   Mar 16 00:34:25 yipyap systemd[1]: Started UPnP Internet Gateway Device 
Daemon.
   Mar 16 00:34:25 yipyap miniupnpd[20603]: HTTP listening on port 32959
   Mar 16 00:34:25 yipyap miniupnpd[20603]: no HTTP IPv6 address, disabling IPv6

read_config() appears to be defined only in the init.d script, which again
doesn't help because we're running systemd. I am going to give up here. Am
I missing something, or is this a case of "running natively under systemd
has never worked"?

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-debug'), (500, 'stable'), (500, 
'oldstable'), (490, 'testing'), (460, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 6.1.0-5-686-pae (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages miniupnpd depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  miniupnpd-iptables 2.3.1-1
ii  uuid-runtime   2.36.1-8+deb11u1

miniupnpd recommends no packages.

miniupnpd suggests no packages.

-- debconf information:
* miniupnpd/force_igd_desc_v1: false
* miniupnpd/start_daemon: true
* miniupnpd/iface: eth0
* miniupnpd/listen: br0
* miniupnpd/ip6script: true

Bug#1033011: octave-dev: missing Breaks+Replaces against older liboctave-dev

[Sébastien Villemot]

Le mercredi 15 mars 2023 à 17:51 +0100, Sébastien Villemot a écrit :
> As a consequence, upgrades from Buster to Bookworm with liboctave-dev
> installed can fail
I meant from Bullseye to Bookworm.

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



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

Bug#983576: CVE-2020-8020 CVE-2020-8021 CVE-2020-8031

[Andrej Shadura]

Hi,

On Wed, 15 Mar 2023, at 17:33, Moritz Mühlenhoff wrote:
> Could we get these fixed for bookworm? (Plus #911797)

The OBS packages in bookworm don’t ship any Ruby (frontend) code anymore.

-- 
Cheers,
  Andrej

Bug#1033011: octave-dev: missing Breaks+Replaces against older liboctave-dev

[Sébastien Villemot]

Package: octave-dev
Version: 6.3.0-1
Severity: serious

liboctave-dev has been renamed octave-dev, but the latter misses a
Breaks+Replaces against the former.

As a consequence, upgrades from Buster to Bookworm with liboctave-dev
installed can fail, because the new octave-dev wants to overwrite files which
are provided by the old liboctave-dev.

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

Bug#1033010: improve performance on 9p by raising msize

[Antoine Beaupre]

Package: autopkgtest
Version: 5.28
Severity: normal

I get this warning when building packages with the autopkgtest
sbuild-qemu backend:

qemu-system-x86_64: warning: 9p: degraded performance: a reasonable high 
msize sho.

It looks like this is an upstream issue, but I wonder if we might not
be able to do some better tweaking for this. This is discussed here
upstream:

https://wiki.qemu.org/Documentation/9psetup#Performance_Considerations_(msize)

where they suggest changing from the default 128KiB to tens of
*megabytes*. The example uses:

msize=104857600

which is 100 megs, if i'm not mistaken.

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.5.6
ii  libdpkg-perl1.21.20
ii  procps  2:4.0.2-3
ii  python3 3.11.2-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.29-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  lxc  
pn  lxd  
ii  ovmf 2022.11-2
pn  ovmf-ia32
ii  podman   4.3.1+ds1-5+b2
ii  python3-distro-info  1.5
ii  qemu-efi-aarch64 2022.11-2
ii  qemu-efi-arm 2022.11-2
pn  qemu-system  
ii  qemu-utils   1:7.2+dfsg-4
ii  schroot  1.6.13-3+b1
ii  util-linux   2.38.1-5
ii  vmdb20.26-2
ii  zerofree 1.1.1-1

-- no debconf information

Bug#1029167: mozjs78: Fails to build on armhf and armel

[Emanuele Rocca]

Hi Jeremy and Simon!

On 2023-03-15 11:50, Emanuele Rocca wrote:
> Motivated by this, I've tried to build mozjs78 with GCC 11 instead of
> 12, and it *did* build successfully. My proposal is thus to build
> mozjs78 with GCC 11 on armhf and armel, see attached patch.

I've now discovered that this very bug was reported upstream [0] and it
has been already fixed in the debian/102/master branch [1].
 
To confirm, I've just built mozjs78 successfully on armhf with the patch
applied (Remove-workaround-for-old-libstdc-problem-which-now-cause.patch)

The right way to fix the problem in mozjs78 seems to be just
cherry-picking 3230b3af to debian/78/master as well.

Thanks,
  Emanuele

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1786621
[1] 
https://salsa.debian.org/gnome-team/mozjs/-/commit/3230b3af440e67260139572a12064cea10134779

Bug#1033009: unblock: calamares-settings-debian/12.0.5-1

[Jonathan Carter]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: calamares-settings-deb...@packages.debian.org, Please alloq 
calamares-settings-debian (12.0.5-1) to migrate to testing, it contains the 
correct artwork for bookworm
Control: affects -1 + src:calamares-settings-debian

Please unblock package calamares-settings-debian

It contains the correct artwork for bookworm.

unblock calamares-settings-debian/12.0.5-1

Bug#1019594: closed by Daniel Baumann (bts)

[Moritz Mühlenhoff]

Am Sun, Feb 19, 2023 at 06:03:09PM + schrieb Debian Bug Tracking System:
> This is an automatic notification regarding your Bug report
> which was filed against the src:deluge package:
> 
> #1019594: deluge: CVE-2021-3427
> 
> It has been closed by Daniel Baumann .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Daniel Baumann 
>  by
> replying to this email.

Hi Daniel,
What about 2.0.3, do you please to also address this for bookworm?

Cheers,
Moritz

Bug#1033008: texlive-extra-utils: make4ht - Error in odt conversion: Format error in the file, in the styles.xml

[Andrey Spitsyn]

Package: texlive-extra-utils
Version: 2022.20230122-2
Severity: important
X-Debbugs-Cc: andrey.spit...@gmail.com

Dear Maintainer,

Please update TeX Live to up-to date version, because this bug fixed in
upsteam, see https://github.com/michal-h21/make4ht/issues/107


Best Regards,
Andrey


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 einhander staff 860 Aug  4  2017 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 2155 Mar  5 17:41 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 13 00:25 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Feb 15 16:35 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Feb 15 16:35 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Oct 26 11:17 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 15 16:35 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb 15 16:35 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3126 Mar  5 17:38 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jun 26  2011 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 26 11:17 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-extra-utils depends on:
ii  libunicode-linebreak-perl  0.0.20190101-1+b5
ii  python33.11.2-1
ii  tex-common 6.18
ii  texlive-base   2022.20230122-2
ii  texlive-binaries   2022.20220321.62855-5
ii  texlive-latex-base 2022.20230122-2
ii  texlive-luatex 2022.20230122-2
ii  texlive-plain-generic  2022.20230122-2

Versions of packages texlive-extra-utils recommends:
ii  ghostscript10.0.0~dfsg-9+b1
ii  libfile-homedir-perl   1.006-2
ii  liblog-log4perl-perl   1.57-1
ii  libyaml-tiny-perl  1.73-1
ii  ruby   1:3.1
ii  texlive-latex-recommended  2022.20230122-2

Versions of packages texlive-extra-utils suggests:
ii  chktex1.7.8-1
ii  default-jre-headless  2:1.17-74
pn  dvidvi
ii  dvipng1.15-1.1+b1
pn  fragmaster
ii  lacheck   1.26-17
ii  latexdiff 1.3.2-1
ii  latexmk   1:4.79-1
pn  purifyeps 
pn  xindy 

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.4

Versions of packages texlive-extra-utils is related to:
ii  

Bug#983576: CVE-2020-8020 CVE-2020-8021 CVE-2020-8031

[Moritz Mühlenhoff]

Am Fri, Feb 26, 2021 at 05:29:07PM +0100 schrieb Moritz Muehlenhoff:
> Source: open-build-service
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> CVE-2020-8020:
> https://bugzilla.suse.com/show_bug.cgi?id=1171439
> https://github.com/openSUSE/open-build-service/commit/7cc32c8e2ff7290698e101d9a80a9dc29a5500fb
> 
> CVE-2020-8021:
> https://bugzilla.suse.com/show_bug.cgi?id=1171649
> https://github.com/openSUSE/open-build-service/commit/7323c904f86ba9e04065c23422d06c03647589fb
> 
> CVE-2020-8031:
> https://bugzilla.suse.com/show_bug.cgi?id=1178880

Could we get these fixed for bookworm? (Plus #911797)

Cheers,
Moritz

Bug#1023693: libstb: CVE-2021-37789

[Moritz Mühlenhoff]

Am Tue, Nov 08, 2022 at 08:42:05PM +0100 schrieb Moritz Mühlenhoff:
> Source: libstb
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for libstb.
> 
> CVE-2021-37789[0]:
> | stb_image.h 2.27 has a heap-based buffer over in stbi__jpeg_load,
> | leading to Information Disclosure or Denial of Service.
> 
> https://github.com/nothings/stb/issues/1178

This is fixed in 
https://github.com/nothings/stb/commit/5ba0baaa269b3fd681828e0e3b3ac0f1472eaf40

Could we get that fixed for bookworm?

Cheers,
Moritz

Bug#992172: exim4: CVE-2021-38371

[Moritz Mühlenhoff]

Am Sun, Aug 15, 2021 at 07:21:40AM +0200 schrieb Andreas Metzler:
> On 2021-08-14 Salvatore Bonaccorso  wrote:
> > Source: exim4
> > Version: 4.94.2-7
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> 
> > Hi,
> 
> > The following vulnerability was published for exim4, this is to start
> > tracking the issue downstream for us. Note that at time of writing [2]
> > gives still a 404.
> 
> > CVE-2021-38371[0]:
> > | The STARTTLS feature in Exim through 4.94.2 allows response injection
> > | (buffering) during MTA SMTP sending.
> [...]
> 
> IIRC that is mitigated in experimental (4.95 rc) by ALPN and unkown
> command related changes, I will not be able to check in detail for a
> week or so, though.

Do you know if this is fixed in 4.96/bookworm?

Cheers,
Moritz

Bug#1032468: file-roller: does not work - no error messages except on stderr (org.freedesktop.DBus.Error.ServiceUnknown)

[Vincent Lefevre]

Control: retitle -1 file-roller: in some sandbox, fails with no error messages 
except on stderr (org.freedesktop.DBus.Error.ServiceUnknown)

On 2023-03-15 04:01:48 +0100, Vincent Lefevre wrote:
> Well, for the remote test, I now remember the following bug:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018880
> 
> ("under ssh X11 forwarding, apps like nautilus that use
> xdg-desktop-portal start with 25s delay"). It is probably the
> same issue.

For the timeout issue, there is this bug (I've just added
an "affects" for file-roller).

Locally and without a sandbox, file-roller appears to work,
without a timeout (the only issue I could find is that it wanted
to open a window higher than the screen).

> > Is there anything unusual about the way you installed Firefox or
> > file-roller? (For instance if they are installed as Flatpak, Snap or
> > AppImage apps, or running in some sort of sandbox, or running remotely?)
> 
> Well, Firefox is running in a sandbox (firejail), though that's
> quite usual for me, since I've been doing that for more than
> 5 years, without issues with external applications except that
> I needed to unblacklist /usr/libexec (according to upstream, this
> directory must not be used by applications, thus disagreeing with
> Debian) and whitelist some application-specific paths.
> 
> This may be the issue with the firefox profile, but there is no
> documentation and the error message is not helpful. So, if there
> is something to add to the firefox profile, one doesn't know.

So I've clarified the bug title. There are 2 issues:

1. The fact that it does not work in this case. This might be either
an issue in file-roller itself (couldn't it just ignore the error
and assume that it is the only instance?) or in the firejail firefox
profile (but one still needs to make sure that data doesn't escape
the sandbox), but there is a lack of documentation.

The fact that file-roller is based on dbus to work and has the
single-instance design is not just a detail of implementation.
BTW, this will not work either in Mutt when viewing an attachment,
because the file is unlinked as soon as the application quits,
which will happen if file-roller has already been started. This
could also be an issue with web browsers, even without a sandbox.

2. The absence of graphical error report in case of failure, at least
in this case, so that there is absolutely no feedback about the error
in Firefox: it could just mean that the file is still being downloaded
or that the application takes time to start. To quote Paolo Amadini at

  https://bugzilla.mozilla.org/show_bug.cgi?id=1318331#c1

"In fact, the target application should be a GUI application, and
normally it's the application's responsibility to show a message box
if there is an issue when opening the file, regardless of the return
code, that may still indicate success."

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

Bug#1014714: nim: CVE-2021-41259

[Moritz Mühlenhoff]

Am Sun, Jul 10, 2022 at 07:31:30PM +0200 schrieb Moritz Mühlenhoff:
> Source: nim
> X-Debbugs-CC: t...@security.debian.org
> Severity: normal
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for nim.
> 
> CVE-2021-41259[0]:
> | Nim is a systems programming language with a focus on efficiency,
> | expressiveness, and elegance. In affected versions the uri.parseUri
> | function which may be used to validate URIs accepts null bytes in the
> | input URI. This behavior could be used to bypass URI validation. For
> | example: parseUri("http://localhost\0hello;).hostname is set to
> | "localhost\0hello". Additionally, httpclient.getContent accepts null
> | bytes in the input URL and ignores any data after the first null byte.
> | Example: getContent("http://localhost\0hello;) makes a request to
> | localhost:80. An attacker can use a null bytes to bypass the check and
> | mount a SSRF attack.
> 
> https://github.com/nim-lang/security/security/advisories/GHSA-3gg2-rw3q-qwgc

Could we get this fixed for bookworm?

Cheers,
Moritz

Bug#1033007: Now gcc-13: [Fwd: [PATCH] gcc-12: Re-enable split-stack support for GNU/Hurd.]

[Svante Signell]

Package: gcc-snapshot
Version: 1:20230315-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-snapshot
X-Debbugs-CC: debian-h...@lists.debian.org

Hello, seems like the patch gcc_config_gnu.h.diff, in debian gcc-12 named:
pr104290-followup.diff was lost (again).

How can this patch ever become upstreamed??

It seems like sending to gcc-patches is not enough. Create a regression bug?  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 is already reported as a
regression, it has to be updated to cover upstream releases of gcc-13 now.

For gcc-12 Debian has been carrying it as:
pr104290-followup.diff

Submitting this problem as new bug to Debian/gcc-13/gcc-snapshot!

Thanks!
--- Begin Message ---
Hello,

In line of porting the latest build of libgo/go with gcc-12 to GNU/Hurd, support
of split-stack was found to be removed.
 
After patching the files in libgo the build of gotools fails:
go1: error: '-fsplit-stack' currently only supported on GNU/Linux
go1: error: '-fsplit-stack' is not supported by this compiler configuration

The attached patch defines OPTION_GLIBC_P(opts) and OPTION_GLIBC that was lost
in config/gnu.h, needed to enable split-stack support for GNU/Hurd. 

This problem happened with the latest commit as discussed in the mail thread
starting with https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588973.html
.

The file first doing this check is: (first error: ..)
src/gcc/common/config/i386/i386-common.cc
in function:
static bool ix86_supports_split_stack (bool report,
struct gcc_options *opts ATTRIBUTE_UNUSED)

and secondly in:src/gcc/opts.cc: (second error: ...)
in function:
void
finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
location_t loc)

The checking logic is in function ix86_supports_split_stack():
#if defined(TARGET_THREAD_SPLIT_STACK_OFFSET) && defined(OPTION_GLIBC_P)
  if (!OPTION_GLIBC_P (opts))
#endif
{
  if (report)
error ("%<-fsplit-stack%> currently only supported on GNU/Linux");
  return false;
}

  bool ret = true;

In case of GNU/Hurd TARGET_THREAD_SPLIT_STACK_OFFSET is defined as well as
OPTION_GLIBC_P but OPTION_GLIBC_P(opts) is needed to. The attached patch to
src/gcc/config/gnu.h creates that definition. For GNU/Hurd, gnu.h is included in
the configure stage:
Configuring stage 1 in ./gcc
...
Using the following target machine macro files:
...
../../src/gcc/config/gnu.h

For a longer history about this bug see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

Additionally, I would propose the text in gcc/common/config/i386/i386-common.cc
to change from:
error ("%<-fsplit-stack%> currently only supported on GNU/Linux");
to:
error ("%<-fsplit-stack%> currently only supported on GLIBC-based systems");

Thanks!

--- a/src/gcc/config/gnu.h	2022-02-06 11:59:41.0 +0100
+++ b/src/gcc/config/gnu.h	2022-02-06 12:00:19.0 +0100
@@ -19,6 +19,9 @@
 along with GCC.  If not, see <http://www.gnu.org/licenses/>.
 */
 
+#define OPTION_GLIBC_P(opts)	(DEFAULT_LIBC == LIBC_GLIBC)
+#define OPTION_GLIBC		OPTION_GLIBC_P (_options)
+
 #undef GNU_USER_TARGET_OS_CPP_BUILTINS
 #define GNU_USER_TARGET_OS_CPP_BUILTINS()		\
 do {	\
--- End Message ---

Bug#1033006: unblock: openvpn/2.6.1-1 (preapproval)

[Bernhard Schmidt]

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

Please give permission to upload OpenVPN 2.6.1-1 to unstable and let
it migrate to testing (currently in experimental as 2.6.1-1~exp1

[ Reason ]
Upstream has released the first minor release in the 2.6.x series. 
It is primarily a bugfix release but has one new security feature.

https://github.com/OpenVPN/openvpn/blob/v2.6.1/Changes.rst

| Dynamic TLS Crypt When both peers are OpenVPN 2.6.1+, OpenVPN will dynamically
| create a tls-crypt key that is used for renegotiation. This ensure that only
| the previously authenticated peer can do trigger renegotiation and complete
| renegotiations.

I am afraid that this might be CVE material down the road and would
be more invasive to backport during a stable release than adding it now.

There is another release slated for next week that will overhaul the
kernel interface to the optional DCO (data channel offload) kernel
module. I have asked upstream to make 2.6.2 as small as possible
compared to 2.6.1, so we can review 2.6.2 and the new DCO module 
in time.

There have been no changes in the debian/ packaging

[ Impact ]
Missing out on this release would make us miss all the small bugfixes and
make reviewing the DCO change a lot harder.

[ Tests ]
Upstream has a very thorough patch review process and CI pipeline
2.6.1-1~exp1 (but compiled on bullseye) has been running on my employers
eduVPN server serving thousands of university students.

[ Risks ]
The code change is not trivial but managable

https://github.com/OpenVPN/openvpn/compare/v2.6.0...v2.6.1

about half of the changes affect only Windows or FreeBSD

I'm not smart enough to understand anything about the one
new feature, but it has been extensively documented and
tested by upstream

https://github.com/OpenVPN/openvpn/commit/202a934fc32673ef865b5cbcb23ad6057ceb2e0b

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

I've omitted the debdiff because there have not been any changes
apart from the new upstream version, which is a lot more readable
as a list of commits on github than with a plain debdiff

If you want me to attach a debdiff feel free to tell me.

[ Other info ]
The upcoming DCO change will involve a new version of src:openvpn and a new 
version
of src:openvpn-dco-dkms. The list of changes on the kernel side is already 
visible
on https://github.com/OpenVPN/ovpn-dco/commits/master .

In the past we managed to break DCO on above mentioned really heavily loaded
OpenVPN server within a few hours. The new version is a major overhaul and more
in-line with code upstreamable in Linux, and did survive torture tests.

I know this is kind of late, but I think it would be better to include it as 
well
as soon as it is released because

- we cannot support the old deprecated module
- openvpn uses DCO (of the right version) automatically and will transparently
  fall-back to non-DCO mode if the module is not found (or the wrong version)
- it has not been in Bullseye previously, so if we see that DCO is too unstable
  with the new version we can just drop it before the release

unblock openvpn/2.6.1-1

Bug#1031441: Potential RM candidate ?

[Pirate Praveen]

On Mon, 13 Mar 2023 23:17:02 +0530 Mohd Bilal  
wrote:

> Hello,
>
> The upstream[1] for ruby-github-api has been inactive for over 2 
years

> now and this is affecting other packages like ruby-oauth2[2] and
> ruby-faraday[3] from migrating.
>
> $ reverse-depends -b ruby-github-api
> Reverse-Build-Depends
> * ruby-jeweler
>
> $ reverse-depends -b ruby-jeweler
> No reverse dependencies found
>
> So should we remove these 2 packages ? or as a workaround we could 
relax
> the versions in Gemfile to actually fix this bug since the Debian 
source

> doesn't ship the upstream test suite.

I think we can remove these two packages.

Bug#1032587: UDD's upstream_metadata table may contain stale data?

[Andreas Tille]

Am Tue, Mar 14, 2023 at 10:05:33PM +0100 schrieb Andreas Tille:
> Am Tue, Mar 14, 2023 at 10:42:30PM +0200 schrieb Faidon Liambotis:
> > Thanks Andreas! Is the code and/or logs for this cronjob somewhere I can
> > access myself? Perhaps I could have a look myself and help you out?
> 
> Its
> 
>
> https://salsa.debian.org/blends-team/website/-/blob/master/misc/machine_readable/fetch-machine-readable_salsa.py
> 
> but I think this short term issue is not worth that you are looking into
> it.  It should run on blends.debian.net since there are most of the
> watched projects cached.  For some reason the job seems to fail for
> 
>https://salsa.debian.org/python-team/packages/kazam
> 
> but I need to sort out whether this suspicion is true

Suspicion is wrong and I'm now convinced that we are trapped by some
means by Salsa to prevent DOS attacks.  That's why I increased the time
span between fetching data from Salsa (we have time, just need to be
ready in less than one day) and added more exceptions[1] to hopefully
fetch things like these:

> raise RemoteDisconnected("Remote end closed connection without"
> http.client.RemoteDisconnected: Remote end closed connection without response
> ...
> raise RemoteDisconnected("Remote end closed connection without"
> urllib3.exceptions.ProtocolError: ('Connection aborted.', 
> RemoteDisconnected('Remote end closed connection without response'))
> ...
> raise ConnectionError(err, request=request)
> requests.exceptions.ConnectionError: ('Connection aborted.', 
> RemoteDisconnected('Remote end closed connection without response'))

It seems I should also make sure cron will sent me some mail on
failure of this job since it was not working for quite some time.

BTW, it might be that I could need help by convincing Salsa admins that
it makes sense to parse these machine readable files right on Salsa.  I
started in times of Alioth with a job that was reading repositories
directly which was way less network consuming.  Since Salsa this is
not possible any more.  I tried really hard to cache the results and
reduce the network traffic as low as possible (just downloading single
files only).  However, as we see this is not reliable any more (which
it was for a couple of years).

Kind regards
   Andreas.

[1] 
https://salsa.debian.org/blends-team/website/-/commit/a51cf1cfeadc4693aaacfb5e74113805a286ebe1

-- 
http://fam-tille.de

Bug#995156: easy-rsa: vars Autodetection

[Dennis Camera]

On Wed, 1 Mar 2023 19:05:13 +0200, Adrian Bunk wrote:
> Has anyone discussed this with upstream?
> 
> This seems to be an area with frequent changes upstream, adding a
>patch 
> that is not a backport from upstream might be a bad idea.

From what I can tell upstream has addressed this issue in release 3.1.1.

I propose to backport upstream commit 525a116 (fix-make-cadir.patch
attached) to restore the correct behaviour.
I wrote a small test script (test.sh) which initialises a new cadir,
sets EASYRSA_KEY_SIZE and generates a CA + certificate to verify that
the configured key size is applied.

Regards,
Dennis

PS: Please note that the subject of the certificate generated by
test.sh is incorrect (#1032270).
diff --git a/easyrsa3/easyrsa b/easyrsa3/easyrsa
index 46de7dd..525a116 100755
--- a/easyrsa3/easyrsa
+++ b/easyrsa3/easyrsa
@@ -977,7 +977,7 @@ and initialize a fresh PKI here."
 Your newly created PKI dir is:
 * $EASYRSA_PKI"
 
-	if [ "$user_vars_true" ]; then
+	if [ "$user_vars_true" ] || [ "$old_vars_true" ]; then
 		: # ok - No message required
 	else
 		message "\
@@ -1079,12 +1079,18 @@ install_data_to_pki () {
 	fi
 
 	# Create PKI/vars from PKI/example
+	unset -v old_vars_true
 	case "$context" in
 	init-pki)
-		if [ -e "${EASYRSA_PKI}/${vars_file_example}" ]; then
-			[ -e "${EASYRSA_PKI}/${vars_file}" ] || \
-cp "${EASYRSA_PKI}/${vars_file_example}" \
-	"${EASYRSA_PKI}/${vars_file}" || :
+		if [ -e ./vars ]; then
+			# If the old vars exists then do nothing
+			old_vars_true=1
+		else
+			if [ -e "${EASYRSA_PKI}/${vars_file_example}" ]; then
+[ -e "${EASYRSA_PKI}/${vars_file}" ] || \
+	cp "${EASYRSA_PKI}/${vars_file_example}" \
+		"${EASYRSA_PKI}/${vars_file}" || :
+			fi
 		fi
 	;;
 	vars-setup)


test.sh
Description: application/shellscript

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

[Dennis Camera]

On Thu, 2 Mar 2023 16:23:01 +0100 
Dennis Camera  wrote:
> The correct behaviour of the --req-cn option was restored in upstream
> version 3.1.1.

I attached a patch based on upstream commit
fe3cced16c62de5dd33f3a230ee03e904306a55b which fixes the behaviour of
--req-cn.
--- a/easyrsa3/easyrsa	2023-03-02 16:44:48.526049371 +0100
+++ b/easyrsa3/easyrsa	2023-03-02 16:49:00.478040360 +0100
@@ -1130,18 +1130,29 @@
 	[ -n "$1" ] || die "\
 Error: gen-req must have a file base as the first argument.
 Run easyrsa without commands for usage and commands."
+
+	# Initialisation
+	unset -v text nopass ssl_batch
+
+	# Set ssl batch mode and Default commonName, as required
+	if [ "$EASYRSA_BATCH" ]; then
+		ssl_batch=1
+		[ "$EASYRSA_REQ_CN" = ChangeMe ] && export EASYRSA_REQ_CN="$1"
+	else
+		# --req-cn must be used with --batch, otherwise use default
+		export EASYRSA_REQ_CN="$1"
+	fi
+
+	# Output files
 	key_out="$EASYRSA_PKI/private/$1.key"
 	req_out="$EASYRSA_PKI/reqs/$1.req"
 
-	# Set the request commonName
-	EASYRSA_REQ_CN="$1"
-	shift
+	shift # scrape off file-name
 
 	# Require SSL Lib version for 'nopass' -> $no_password
 	verify_pki_init
 
 	# function opts support
-	unset -v text nopass ssl_batch
 	while [ -n "$1" ]; do
 		case "$1" in
 			text) text=1 ;;
@@ -1365,7 +1376,7 @@
 	rm -f "$ext_tmp"
 
 	[ "$EASYRSA_SILENT" ] || print # Separate Notice below
-	unset -v EASYRSA_BATCH # This is why batch mode should not silence output
+	#unset -v EASYRSA_BATCH # This is why batch mode should not silence output
 	notice "\
 Certificate created at: $crt_out"
 
@@ -1406,12 +1417,16 @@
 	[ -f "$key_out" ] && die "Key $err_exists $key_out"
 	[ -f "$crt_out" ] && die "Certificate $err_exists $crt_out"
 
-	# create request
+	# Set commonName
+	[ "$EASYRSA_REQ_CN" = ChangeMe ] || die "\
+Option conflict: '$cmd' does not support setting an external commonName"
 	EASYRSA_REQ_CN="$name"
+
+	# create request
 	gen_req "$name" batch ${nopass+ nopass}
 
 	# Sign it
-	( sign_req "$crt_type" "$name" batch ) || {
+	( sign_req "$crt_type" "$name" ) || {
 		rm -f "$req_out" "$key_out"
 		die "Failed to sign '$name' - See error messages above for details."
 	}

Bug#1033005: puppetdb: "fresh" installion results in "permission denied for table schema_migrations"

[CSights]

Package: puppetdb
Version: 7.12.1-3
Severity: grave
Justification: renders package unusable


Greetings,

Setting up puppetdb with a empty database seems to not succeed.  puppetdb fails 
to start and issues
the message:

"Execution error (PSQLException) at 
org.postgresql.core.v3.QueryExecutorImpl/receiveErrorResponse 
(QueryExecutorImpl.java:2676).\nERROR: permission denied for table 
schema_migrations\n",

The reason why I put "fresh" in quotes is that actually what I'm doing is 
purging puppetdb,
installing puppetdb, then running 'dpkg-reconfigure puppetdb'.  During the 
purge of puppetdb
dbconfig prompts whether to remove the old DB and I choose "yes".  I keep the 
default answers
when running 'dpkg-reconfigure puppetdb'.

I haven't attempted to look at the DB permissions for the table 
schema_migrations, but it seems
likely the puppetdb user doesn't have access.

Thanks for your time!
C.



-- 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-5-amd64 (SMP w/2 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 puppetdb depends on:
ii  adduser3.131
ii  dbconfig-pgsql 2.0.24
ii  debconf [debconf-2.0]  1.5.82
ii  default-jre-headless   2:1.17-74
ii  init-system-helpers1.65.2
ii  libasm-java9.4-1
ii  libat-at-clojure   1.2.0-1.1
ii  libbidi-clojure2.1.6-2
ii  libcheshire-clojure5.11.0-2
ii  libclj-digest-clojure  1.4.9+dfsg-1
ii  libclj-http-clojure2.3.0-1.1
ii  libclj-stacktrace-clojure  0.2.7-1
ii  libclj-time-clojure0.15.2-2
ii  libclojure-java1.11.1-2
ii  libcommons-io-java 2.11.0-2
ii  libcommons-lang3-java  3.12.0-2
ii  libcommons-logging-java1.2-3
ii  libcompojure-clojure   1.6.0-1.1
ii  libcore-async-clojure  1.5.648-1
ii  libcore-match-clojure  1.0.0-1
ii  libcore-memoize-clojure1.0.257-1
ii  libdata-priority-map-clojure   1.1.0-3
ii  libdujour-version-check-clojure0.2.3-1
ii  libdynapath-clojure1.0.0-3
ii  libfast-zip-visit-clojure  1.0.2-3
ii  libgeronimo-j2ee-management-1.1-spec-java  1.0.1-1.1
ii  libgeronimo-jms-1.1-spec-java  1.1.1-1
ii  libhikaricp-java   2.7.9-1
ii  libhoneysql-clojure2.4.962+really2.3.911-1
ii  libinstaparse-clojure  1.4.7-1.1
ii  libjava-jdbc-clojure   0.7.10-1
ii  libjava-jmx-clojure0.3.4-1.1
ii  libkitchensink-clojure 3.2.1-1
ii  libmath-combinatorics-clojure  0.1.4-1.1
ii  libmetrics-clojure 2.9.0-2.1
ii  libmurphy-clojure  0.5.2-2
ii  libpostgresql-jdbc-java42.5.4-1
ii  libpuppetlabs-i18n-clojure 0.9.2-2
ii  libraynes-fs-clojure   1.5.2-1
ii  libring-core-clojure   1.8.2-2
ii  librobert-hooke-clojure1.3.0-4
ii  libslf4j-java  1.7.32-1
ii  libspecter-clojure 1.0.2-2.1
ii  libstockpile-clojure   0.0.4-1.1
ii  libstructured-logging-clojure  0.2.0-4
ii  libtools-logging-clojure   1.2.4-2
ii  libtools-macro-clojure 0.1.5-2
ii  libtools-namespace-clojure 0.2.11-1.1
ii  libtrapperkeeper-authorization-clojure 1.0.0-4
ii  libtrapperkeeper-clojure   3.2.0-4
ii  libtrapperkeeper-metrics-clojure   1.5.0-5
ii  libtrapperkeeper-scheduler-clojure 1.1.3-7
ii  libtrapperkeeper-status-clojure1.1.1-4
ii  libtrapperkeeper-webserver-jetty9-clojure  4.4.1-5
ii  libversioneer-clojure  0.2.0-1
ii  ucf3.0043+nmu1

puppetdb recommends no packages.

Versions of packages puppetdb suggests:
pn  libnippy-clojure
ii  postgresql  15+247
pn  postgresql-contrib  

-- debconf information:
  puppetdb/app-password-confirm: (password omitted)
  puppetdb/password-confirm: (password omitted)
  puppetdb/pgsql/app-pass: (password omitted)
  puppetdb/pgsql/admin-pass: (password omitted)
  puppetdb/dbconfig-upgrade: true
* 

Bug#1019731: gitlab: failed to fetch comments in merge requests (500 Internal Server Error)

[Antoine Le Gonidec]

The attached patch works around the failure to display comments on diffs.

It has been submitted and included upstream already, see:
- https://gitlab.com/gitlab-org/gitlab/-/issues/374174#note_1238695337
- https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108902
diff --git a/config/application.rb b/config/application.rb
index a3fe4935fdf..88fd66f0baf 100644
--- a/config/application.rb
+++ b/config/application.rb
@@ -595,6 +595,15 @@ class Application < Rails::Application
 Gitlab::Color, # https://gitlab.com/gitlab-org/gitlab/-/issues/368844,
 Hashie::Array # https://gitlab.com/gitlab-org/gitlab/-/issues/378089
   ]
+  # 
+  # it seems that setting config.active_record.yaml_column_permitted_classes in an after_initialize does not update
+  # the value in ActiveRecord::Base.yaml_column_permitted_classes. We can not move the setting of
+  # config.active_record.yaml_column_permitted_classes out of the after_initialize because then the gitlab classes
+  # are not loaded yet.
+  #
+  # Manually set ActiveRecord::Base.yaml_column_permitted_classes
+  #
+  ActiveRecord::Base.yaml_column_permitted_classes = config.active_record.yaml_column_permitted_classes
 
   # on_master_start yields immediately in unclustered environments and runs
   # when the primary process is done initializing otherwise.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032075: Play Queue and display of current title don't change when actually played song changes

[Sven Bartscher]

Hi,

On Mon, 27 Feb 2023 15:19:17 +0100 Sven Bartscher 
 wrote:
when listening to music in sublime music, the song metadata indicated in 
the lower left corner and the play queue reachable in the lower right 
corner do not update when they should. This includes situations such as


* the next song starts when the previous has ended
* the “Go to next song” button is used
* another song is selected for playback somewhere else in the interface
* a song is set to “play next“

Instead they just stay stuck in in the state they have when starting up, 
i.e. showing the song that was first played after starting and the play 
queue at that time. Note that while the mentioned interface elements 
don't reflect the change, the actual playback and the time slider in the 
lower middle reflect the changes made, e.g. the time resets to the start 
when a new song is started and “play next” selections are correctly 
respected when switching to the next song.


I just noticed that the behavior described above actually depends on the 
active tab being viewed. While viewing the “Playlists” tab, the behavior 
is as described above. However, as soon as yous switch to another tab 
(“Albums”, “Artists” or “Browse”) the metadata indicator in the lower 
left corner updates to the correct values.


The behavior of the play queue depends on how music was queued there. If 
music has been queued from tabs other then “Playlists” the play queue 
behaves similarly to the metadata indicator, i.e. it is frozen while on 
the “Playlists” tab, but resumes updating correctly once you switch to 
another tab. If you fill the play queue by clicking the “Play All” or 
“Shuffle All” buttons in the “Playlists” tab or double clicking a 
specific song from a playlist, it goes into a permanently frozen state 
that keeps displaying the play queue in the state before the playlist 
was queued. This frozen state can be broken by going into another tab 
and playing another song to replace the play queue.


If you don't queue a whole playlist, but only a single song from the 
playlist tab, by right-clicking and selecting “Play next” or “Add to 
queue“ the play queue updates accordingly (as soon as you switch away 
from the playlists tab) and doesn't go into the permanently frozen state.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033004: unblock: libevent/2.1.12-stable-8

[Nicolas Mora]

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

Please unblock package libevent

[ Reason ]
libevent in testing has a ftbfs bug with glibc 2.36: #1023284

[ Impact ]
The package libevent 2.1.12-stable-5 recompiled with glibc 2.36 breaks the ABI
by removing the symbol evutil_secure_rng_add_bytes.

[ Tests ]
Tests and autopkgtest passed

[ Risks ]
Low risks, the issue has been discussed upstream
(https://github.com/libevent/libevent/issues/1393) and the patrch, which is
already implemented in other distribs, has been accepted upstream
(https://github.com/libevent/libevent/pull/1427). The patch noops the function
evutil_secure_rng_add_bytes when arc4random is already provided by the system.

[ 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 ]
The package should have been update sooner (before freeze), the first attempt
was to change the package name to libevent-2.1-7a, as in Ubuntu, the new
package went in NEW queue and was rejected (2.1.12-stable-7), then then
question was asked upstream to find a better solution.

Thanks in advance!

/Nicolas

unblock libevent/2.1.12-stable-8
diff -Nru libevent-2.1.12-stable/debian/changelog 
libevent-2.1.12-stable/debian/changelog
--- libevent-2.1.12-stable/debian/changelog 2022-04-15 11:26:52.0 
-0400
+++ libevent-2.1.12-stable/debian/changelog 2023-01-04 15:28:26.0 
-0500
@@ -1,3 +1,30 @@
+libevent (2.1.12-stable-8) unstable; urgency=medium
+
+  * Upload to unstable
+  * Restore last unstable version
+  * d/patches: Add patch evutil_secure_rng_add_bytes_noop.patch
+to make evutil_secure_rng_add_bytes noop with glibc's
+implemtation of arc4random, thanks z...@debian.org!
+(Closes: #1023284)
+  * d/control: upgrade Standards-Version to 4.6.2
+  * d/copyright: update year to 2023
+
+ -- Nicolas Mora   Wed, 04 Jan 2023 15:28:26 -0500
+
+libevent (2.1.12-stable-7) experimental; urgency=medium
+
+  * d/control: change package name to libevent-2.1-7a to update rdeps
+   (Closes: #1023284)
+
+ -- Nicolas Mora   Mon, 07 Nov 2022 07:14:20 -0500
+
+libevent (2.1.12-stable-6) experimental; urgency=medium
+
+  * d/symbols: remove symbol evutil_secure_rng_add_bytes
+  * d/control: upgrade Standards-Version to 4.6.1
+
+ -- Nicolas Mora   Wed, 02 Nov 2022 13:07:03 -0400
+
 libevent (2.1.12-stable-5) unstable; urgency=medium
 
   * d/control: Update maintainer
diff -Nru libevent-2.1.12-stable/debian/control 
libevent-2.1.12-stable/debian/control
--- libevent-2.1.12-stable/debian/control   2022-04-15 11:26:42.0 
-0400
+++ libevent-2.1.12-stable/debian/control   2023-01-04 15:28:26.0 
-0500
@@ -4,7 +4,7 @@
 Priority: optional
 Build-Depends: debhelper-compat (= 13),
libssl-dev
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Vcs-Git: https://salsa.debian.org/debian/libevent.git -b master
 Vcs-Browser: https://salsa.debian.org/debian/libevent
 Homepage: https://libevent.org/
diff -Nru libevent-2.1.12-stable/debian/copyright 
libevent-2.1.12-stable/debian/copyright
--- libevent-2.1.12-stable/debian/copyright 2022-04-15 09:45:11.0 
-0400
+++ libevent-2.1.12-stable/debian/copyright 2023-01-04 15:28:26.0 
-0500
@@ -13,7 +13,7 @@
2007-2015  Anibal Monsalve Salazar 
2017-2020 Balint Reczey 
2022 Balint Reczey 
-   2022 Nicolas Mora 
+   2022-2023 Nicolas Mora 
 License: BSD-3-clause
 
 Files: WIN32-Code/getopt.c
diff -Nru 
libevent-2.1.12-stable/debian/patches/evutil_secure_rng_add_bytes_noop.patch 
libevent-2.1.12-stable/debian/patches/evutil_secure_rng_add_bytes_noop.patch
--- 
libevent-2.1.12-stable/debian/patches/evutil_secure_rng_add_bytes_noop.patch
1969-12-31 19:00:00.0 -0500
+++ 
libevent-2.1.12-stable/debian/patches/evutil_secure_rng_add_bytes_noop.patch
2023-01-04 15:28:26.0 -0500
@@ -0,0 +1,40 @@
+Description: Make evutil_secure_rng_add_bytes noop with glibc's implemtation 
of arc4random
+Author: Shengjing Zhu 
+Forwarded: not-needed
+--- a/evutil_rand.c
 b/evutil_rand.c
+@@ -190,14 +190,14 @@
+   ev_arc4random_buf(buf, n);
+ }
+ 
+-#if !defined(EVENT__HAVE_ARC4RANDOM) || 
defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
+ void
+ evutil_secure_rng_add_bytes(const char *buf, size_t n)
+ {
++#if defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
+   arc4random_addrandom((unsigned char*)buf,
+   n>(size_t)INT_MAX ? INT_MAX : (int)n);
+-}
+ #endif
++}
+ 
+ void
+ evutil_free_secure_rng_globals_(void)
+--- a/include/event2/util.h
 b/include/event2/util.h
+@@ -862,7 +862,6 @@
+ EVENT2_EXPORT_SYMBOL
+ int evutil_secure_rng_set_urandom_device_file(char *fname);
+ 
+-#if !defined(EVENT__HAVE_ARC4RANDOM) || 
defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
+ /** Seed the random number generator with extra 

Bug#986357: Please improve package description

[Enrico Zini]

On Sat, Feb 25, 2023 at 03:58:34AM +, peter green wrote:

> It looks like the description we have today was written when sq was
> first packaged, but wasn't actually incorporated into the package
> until later because of 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993633
> 
> Version 0.25.0-1 simply had
> 
> >  Description: Command-line frontends for Sequoia
> >   This package contains the following binaries built from the Rust crate
> >   "sequoia-sq":
> >- sq

That's correct. I think now the description makes sense, and I like the
improvements you propose.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Bug#1033003: cyrus-imapd FTBFS (and will fail at runtime) with glibc 2.37 on some archs

[Steve Langasek]

Package: cyrus-imapd
Version: 3.6.1-2
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Forwarded: https://github.com/cyrusimap/cyrus-imapd/pull/4433

Dear maintainers,

In Ubuntu, we discovered by way of a build-time test suite failure that
cyrus-imapd makes some calls to snprintf() with incorrect arguments that
lead to incorrect runtime behavior against glibc 2.37.

Specifically, an indirect caller passes INT_MAX as the size of a buffer of
unknown length, causing glibc's snprintf() implementation to wig out and not
copy the final byte of the source string.

This is not a serious bug for Debian right now because Debian is currently
shipping glibc 2.36, but will eventually become RC.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru cyrus-imapd-3.6.1/debian/patches/no-INT_MAX-snprintf.patch 
cyrus-imapd-3.6.1/debian/patches/no-INT_MAX-snprintf.patch
--- cyrus-imapd-3.6.1/debian/patches/no-INT_MAX-snprintf.patch  1969-12-31 
16:00:00.0 -0800
+++ cyrus-imapd-3.6.1/debian/patches/no-INT_MAX-snprintf.patch  2023-03-15 
08:11:32.0 -0700
@@ -0,0 +1,46 @@
+Description: don't let callers pass INT_MAX as a length to snprintf()
+ There's a lot of code history here that leads to callers passing 
+ buffers two levels down through the code to snprintf() without knowing 
+ their size and therefore passing (approximately) INT_MAX as a length 
+ argument to snprintf().
+ .
+ This is clearly incorrect but has worked up until now since the data 
+ written falls well within the actual size of the buffer so there are no 
+ buffer overflows.  But changes in how boundary checking is implemented 
+ in glibc 2.37 mean this is now failing on (at least) armhf.
+ .
+ Instead of telling snprintf() we have unlimited space in which to write our
+ two characters, set an upper bound so snprintf() knows we need NO MORE THAN
+ two bytes.
+ .
+ This is a workaround for the incorrect length argument still being passed in
+ from up the stack.  A correct solution would fix the API to not let callers
+ pass buffers of undeclared length down into string manipulation functions
+ and use the overflow protection features of the language instead of relying
+ on out-of-band promises in code comments that buffers are "big enough".
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2011326
+Author: Steve Langasek 
+Last-Update: 2023-03-15
+Forwarded: https://github.com/cyrusimap/cyrus-imapd/pull/4433
+
+Index: cyrus-imapd-3.6.1/lib/times.c
+===
+--- cyrus-imapd-3.6.1.orig/lib/times.c
 cyrus-imapd-3.6.1/lib/times.c
+@@ -45,6 +45,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "assert.h"
+ #include "times.h"
+@@ -562,7 +563,7 @@
+ 
+ /* UTC can be written "Z" or "+00:00" */
+ if (gmtoff == 0)
+-rlen += snprintf(buf+rlen, len-rlen, "Z");
++rlen += snprintf(buf+rlen, MIN(len-rlen, 2), "Z");
+ else
+ rlen += snprintf(buf+rlen, len-rlen, "%c%.2lu:%.2lu",
+  gmtnegative ? '-' : '+', gmtoff/60, gmtoff%60);
diff -Nru cyrus-imapd-3.6.1/debian/patches/series 
cyrus-imapd-3.6.1/debian/patches/series
--- cyrus-imapd-3.6.1/debian/patches/series 2023-02-12 18:50:58.0 
-0800
+++ cyrus-imapd-3.6.1/debian/patches/series 2023-03-15 07:49:36.0 
-0700
@@ -8,3 +8,4 @@
 0018-increase-test-timeout.patch
 #0019-propagate-XXFLAGS.patch
 0020_fix-cyr_cd-shebang.patch
+no-INT_MAX-snprintf.patch

Bug#1033002: kodi: switch B-D from libcec-dev to libv4l-dev for CEC support?

[Diederik de Haas]

Source: kodi
Version: 2:20.1+dfsg-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

User '6by9' said the following in:
https://github.com/lategoodbye/rpi-zero/issues/43#issuecomment-1464044950
===
200~CEC is handled through the vc4 driver in mainline - no need for
VCHIQ.

cec-client doesn't handle multiple Linux kernel CEC API interfaces - it
has hard defines like that at
https://github.com/Pulse-Eight/libcec/blob/master/include/cectypes.h#L287

Use cec-ctl (part of v4l-utils) instead of libcec - libcec is largely
abandonware.
===

The part about abandonware and not capable of handling the Linux kernel
CEC API interfaces sound rather problematic.

So maybe it's a good idea to switch in the Trixie dev cycle?

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZBHhVwAKCRDXblvOeH7b
bmj4AP4oYzvd5FCzQ3mA4ME4VRJB9ZDkHrTHlotUBmwl8enQYgEA11FdHjOQnjYI
cyk9tBPvQjBOfCW05O3qWu3eRfgNuA0=
=BkX9
-END PGP SIGNATURE-

Bug#1033001: darktable: Missing application icon after launching

[Guy Rutenberg]

Package: darktable
Version: 4.2.1-3
Severity: normal
X-Debbugs-Cc: guyrutenb...@gmail.com

Dear Maintainer,

Under GNOME (43.3), the Darktable icon is visible when searching for the app,
but once the window is spawned, it is associated with a generic missing icon
(for example in Alt+Tab or the Activities overview).

The associated wmclass is "darktable", which seems fine. Not sure why the icon
disappears.

Thanks,
Guy


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

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

Versions of packages darktable depends on:
ii  libavif150.11.1-1
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcolord-gtk1   0.3.0-3
ii  libcolord2   1.4.6-2.2
ii  libcups2 2.4.2-2
ii  libcurl3-gnutls  7.88.1-6
ii  libexiv2-27  0.27.6-1
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libgomp1 12.2.0-14
ii  libgphoto2-6 2.5.30-1
ii  libgphoto2-port122.5.30-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.40-2
ii  libgtk-3-0   3.24.37-2
ii  libheif1 1.15.1-1
ii  libicu72 72.1-3
ii  libimath-3-1-29  3.1.6-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libjxl0.70.7.0-10
ii  liblcms2-2   2.14-2
ii  liblensfun1  0.3.3-1
ii  liblua5.4-0  5.4.4-3
ii  libopenexr-3-1-303.1.5-4
ii  libopenjp2-7 2.5.0-1+b1
ii  libosmgpsmap-1.0-1   1.2.0-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libportmidi0 1:217-6.1
ii  libpugixml1v51.13-0.2
ii  librsvg2-2   2.54.5+dfsg-1
ii  libsdl2-2.0-02.26.4+dfsg-1
ii  libsecret-1-00.20.5-3
ii  libsoup2.4-1 2.74.3-1
ii  libsqlite3-0 3.40.1-1
ii  libstdc++6   12.2.0-14
ii  libtiff6 4.5.0-5
ii  libwebp7 1.2.4-0.1
ii  libwebpmux3  1.2.4-0.1
ii  libx11-6 2:1.8.4-2
ii  libxml2  2.9.14+dfsg-1.1+b3
ii  libxrandr2   2:1.5.2-2+b1
ii  zlib1g   1:1.2.13.dfsg-1

darktable recommends no packages.

darktable suggests no packages.

-- no debconf information

Bug#1033000: ITP: ufo-tofu -- Helper scripts for tomographic reconstruction using the ufo-core framework

[Roland Mas]

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

* Package name: ufo-tofu
  Version : 0.12.0
  Upstream Author : Matthias Vogelgesang 
* URL : https://github.com/ufo-kit/tofu
* License : LGPL v3.0
  Programming Lang: Python
  Description : Helper scripts for tomographic reconstruction using the 
ufo-core framework

Python data processing scripts to be used with the UFO framework. At
the moment they are targeted at high-performance reconstruction of
tomographic data sets.

This package will be maintained under the Science Team umbrella, in
particular the Photons And Neutrons Team.

Bug#1032999: unblock: mesa/22.3.6-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: m...@packages.debian.org
Control: affects -1 + src:mesa
Control: block -1 by 1032887

Please consider unblocking package mesa.

[ Reason ]
New upstream bugfix release, fixing #1029731 (RC) and many more.

[ Impact ]
If not accepted, bookworm will ship with various avoidable crashes and
hangs in the graphics driver stack.

[ Tests ]
Has been in unstable for 17 days, currently no RC bugs.

[ Risks ]
I'll leave this for the Mesa maintainers to answer...

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I am not a maintainer of this package, just an interested user.

This can't migrate until llvm-toolchain-15 does (see #1032887, which I
believe is only waiting for a maintainer re-upload with build artifacts
excluded).

unblock mesa/22.3.6-1

Bug#1032998: imagemagick: font issue since 8:6.9.10.23+dfsg-2.1+deb10u2

[Maxime Besson]

Package: imagemagick
Version: 8:6.9.10.23+dfsg-2.1+deb10u2
Severity: normal

Dear Maintainer,

After updating to 8:6.9.10.23+dfsg-2.1+deb10u2, libgd-securityimage-perl
does not work anymore because of the CVE-2022-44267 and CVE-2022-44268
mitigation:



Removing this line from /etc/ImageMagick-6/policy.xml restores correct
hebavior.

Here is a test script that tries to generate a Captcha

use GD::SecurityImage use_magick => 1;

my $image = GD::SecurityImage->new(
width=> 200,
height   => 100,
lines=> 4,
gd_font  => 'Giant',
scramble => 1,
rndmax   => 10,
);
$image->random;
$image->create( 'normal', 'default', "#403030", "#FF644B");
print $image->out( force => 'png' );

The update breaks usage of fonts, and causes warnings to be printed, and
the image to be missing any text (which is bad for a Captcha)
, likely due to the fact that font configuration files for ImageMagick
are in /etc

-- Package-specific info:
ImageMagick program version
---

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

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/6 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- Configuration Files:
/etc/ImageMagick-6/policy.xml changed [not included]

-- no debconf information

Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

[Johannes Schauer Marin Rodrigues]

Quoting Johannes Schauer Marin Rodrigues (2023-03-15 10:29:01)
> I have a patch for you that should fix this problem in the sense that
> mmdebstrap should not choose the unshare mode anymore. If you like, apply the
> following to mmdebstrap from unstable:
> 
> https://mister-muffin.de/p/ZwXV.diff

even better: https://mister-muffin.de/p/lkd1.diff

Bug#1032997: ITP: pylsl -- Python bindings for liblsl

[Enrico Zini]

Package: wnpp
Severity: wishlist
Owner: Enrico Zini 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: pylsl
  Version : 1.16.1
  Upstream Contact: Christian A. Kothe
* URL : https://github.com/labstreaminglayer/pylsl
* License : MIT
  Programming Lang: Python
  Description : Python bindings for liblsl

This is the Python interface to the Lab Streaming Layer (LSL). LSL is an
overlay network for real-time exchange of time series between
applications, most often used in research environments. LSL has clients
for many other languages and platforms that are compatible with each
other.

 - - -

LSL seems to be a standard for taking data from devices like EEG sensors
and making them availale to software that analyses them.

I've packaged this for a personal project, and it would be
straightforward to upload it to Debian. I can't take responsibility for
supporting people with more professional needs besides trying to deal
with FTBFS kind of issues, but after asking in the Debian Science Team
mailing list, it can be maintained under the Science Team umbrella.

Bug#1032996: ITP: liblsl -- lsl library for multi-modal time-synched data transmission over the local network

[Enrico Zini]

Package: wnpp
Severity: wishlist
Owner: Enrico Zini 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: liblsl
  Version : 4.6.0
  Upstream Contact: Christian A. Kothe
* URL : https://github.com/sccn/liblsl
* License : MIT
  Programming Lang: C++
  Description : lsl library for multi-modal time-synched data transmission 
over the local network

The lab streaming layer is a simple all-in-one approach to streaming
experiment data between applications in a lab, e.g. instrument time
series, event markers, audio, and so on


LSL seems to be a standard for taking data from devices like EEG sensors
and making them availale to software that analyses them.

I've packaged this for a personal project, and it would be
straightforward to upload it to Debian. I can't take responsibility for
supporting people with more professional needs besides trying to deal
with FTBFS kind of issues, but after asking in the Debian Science Team
mailing list, it can be maintained under the Science Team umbrella.