Bug#1034455: bullseye-pu: package mariadb-10.5 10.5.19-0+deb11u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-04-20 at 22:10 -0700, Otto Kekäläinen wrote:
> Control: tags -1 -moreinfo
> 
> Updated message to be specific about the change in proposed-updates
> only, i.e. 1:10.5.19-0+deb11u1 -> 1:10.5.19-0+deb11u2
> 
> Changelog:
> 
> mariadb-10.5 (1:10.5.19-0+deb11u2) bullseye; urgency=medium
> 
>   * Add patch to revert upstream libmariadb API change (Closes:
> #1033654)
> 

Thanks.

Please go ahead, bearing in mind that the window for 11.7 closes during
this weekend.

Regards,

Adam

Bug#1034586: always reports inactive/expired certificate on armhf

[Marco d'Itri]

On Apr 21, gs-debian@gluelogic.com wrote:

> Please confirm you are running an arm64 kernel, as you posted above.
Confirmed.

> What lighttpd package (from which architecture) do you have installed?
> $ file /usr/sbin/lighttpd 

root@omitted:~# /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf -tt
2023-04-21 07:37:51: (mod_openssl.c.1335) SSL: inactive/expired X509 
certificate '/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem'
root@omitted:~# file /usr/sbin/lighttpd
/usr/sbin/lighttpd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux-armhf.so.3, 
BuildID[sha1]=414352134318885ffaf3dbf10c3b87590cdcddaf, for GNU/Linux 3.2.0, 
stripped
root@omitted:~# ldd /usr/sbin/lighttpd
linux-vdso.so.1 (0xf7ee6000)
libpcre2-8.so.0 => /lib/arm-linux-gnueabihf/libpcre2-8.so.0 (0xf7e1)
libnettle.so.8 => /lib/arm-linux-gnueabihf/libnettle.so.8 (0xf7db)
libxxhash.so.0 => /lib/arm-linux-gnueabihf/libxxhash.so.0 (0xf7d9)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf7c79000)
/lib/ld-linux-armhf.so.3 (0xf7ee7000)
root@omitted:~# ldd /usr/lib/lighttpd/mod_openssl.so 
linux-vdso.so.1 (0xf7b38000)
libssl.so.3 => /lib/arm-linux-gnueabihf/libssl.so.3 (0xf7abc000)
libcrypto.so.3 => /lib/arm-linux-gnueabihf/libcrypto.so.3 (0xf780)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf76e9000)
/lib/ld-linux-armhf.so.3 (0xf7b39000)
root@omitted:~#

-- 
ciao,
Marco

Bug#804400: elinks: fails to parae git:// URLs

[أحمد المحمودي]

Is this link still valid ? I am trying to see if this issue still 
persists.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1034586: always reports inactive/expired certificate on armhf

[gs-debian . org]

On Wed, Apr 19, 2023 at 01:39:02AM +0200, Marco d'Itri wrote:
> Package: lighttpd
> Version: 1.4.69-1
> Severity: normal
> 
> I am using the latest openssl and lighttpd packages on an armhf (with an 
> arm64 kernel) and an amd64 system, and only on the armhf system I always 
> get this warning at startup even just after having created a Let's 
> Encrypt certificate.
> 
> Apr 19 01:23:31 omitted.mi.bofh.it lighttpd[8876]: 2023-04-19 01:23:30: 
> (mod_openssl.c.1335) SSL: inactive/expired X509 certificate 
> '/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem'
> 
> # openssl x509 -noout -text -in 
> /var/lib/dehydrated/certs/bokassa.mi.bofh.it/fullchain.pem | grep -A2 Validity
> Validity
> Not Before: Apr 18 22:13:45 2023 GMT
> Not After : Jul 17 22:13:44 2023 GMT
> 
> After looking at 
> https://github.com/lighttpd/lighttpd1.4/blob/fdb7ffed88b9dfe09a51e7fb58e5ddfe938c1ec9/src/mod_openssl.c#L1284
>  
> I wonder if this is common on all 32 bit systems instead.

No, this is not common on all 32-bit systems, though I am curious as to
why you are seeing that warning with a valid certificate.

To try to reproduce this, I took some LE certs and put them on a 32-bit
ARM system I have (which is running openwrt, not Debian)
$ uname -m
armv7l
$ cat /proc/cpuinfo | egrep "model|Features"
model name  : ARMv7 Processor rev 1 (v7l)
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
$ file /usr/sbin/lighttpd 
/usr/sbin/lighttpd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-musl-armhf.so.1, no section header

The vfpv3 and /lib/ld-musl-armhf.so.1 confirms to me this is an armhf.
See also: https://www.baeldung.com/linux/arm64-armel-armhf-overview

My cert:
$ openssl x509 -noout -text -in /tmp/x.com/fullchain.pem | grep -A2 Validity
Validity
Not Before: Apr 10 22:15:43 2023 GMT
Not After : Jul  9 22:15:42 2023 GMT

==> I did not get any warning trace on that system with:

$ lighttpd -f test.conf -tt
using my LE certificates, though that test system has only
lighttpd 1.4.67 at the moment.

My test system is running a 32-bit kernel.

Please confirm you are running an arm64 kernel, as you posted above.

What lighttpd package (from which architecture) do you have installed?
$ file /usr/sbin/lighttpd 
might be useful.  Please ensure that you have installed the proper
package for your architecture.

Is your system openssl-based or libressl-based?

The only changes between lighttpd 1.4.67 and lighttpd 1.4.69 in
lighttpd mod_openssl that seemed to be related to this issue is that
lighttpd mod_openssl started using libressl ASN1_TIME_cmp_time_t() when
  LIBRESSL_VERSION_NUMBER >= 0x306fL
and this also requires that lighttpd mod_openssl was built with
libressl.  The standard Debian package for lighttpd mod_openssl is built
with openssl.

Bug#784216: Not a bug

[أحمد المحمودي]

Since this intentional,also Google Search works fine without setting 
document.browse.refresh to 0. Hence closing this bug.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1034455: bullseye-pu: package mariadb-10.5 10.5.19-0+deb11u2

[Otto Kekäläinen]

Control: tags -1 -moreinfo

Updated message to be specific about the change in proposed-updates
only, i.e. 1:10.5.19-0+deb11u1 -> 1:10.5.19-0+deb11u2

Changelog:

mariadb-10.5 (1:10.5.19-0+deb11u2) bullseye; urgency=medium

  * Add patch to revert upstream libmariadb API change (Closes: #1033654)

 -- Otto Kekäläinen   Sat, 15 Apr 2023 12:50:35 -0700


± git diff --stat debian/1%10.5.19-0+deb11u1..bullseye
 debian/changelog   |  6 ++
 debian/patches/mariadb-client-version-id.patch | 53
+
 debian/patches/series  |  1 +
 debian/salsa-ci-enable-sec-and-update-repos.sh | 23 +++
 debian/salsa-ci.yml|  6 ++

Output of git diff debian/1%10.5.19-0+deb11u1..bullseye | xz >
debian-1%10.5.19-0+deb11u2.debdiff.xz attached.

Package is maintained via gbp. All changes, along with full git commit
messages are viewable at
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bullseye.
Viewing on Salsa is recommended, but debdiff provided for release
managers that prefer to read it instead (note it has zero git commit
messages).


debian-1%10.5.19-0+deb11u2.debdiff.xz
Description: application/xz

Bug#342243: elinks: fails to create ipc socket on openafs

[أحمد المحمودي]

Could you test if this problem still persists in elinks 0.13.1 ?

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#324246: does not handle nbsp in forms corrrectly

[أحمد المحمودي]

I just tested that for, using Elinks 0.16.0 (packaging is still in 
progress), and elinks as a result says that it loads: about:blank?q=%20
is that correct ?

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1034659: freeipa-client: IPA client Kerberos configuration incompatible with java

[Mathieu Baudier]

Package: freeipa-client
Version: 4.9.11-1
Severity: normal

Dear Maintainer,


on a host enrolled as an IPA client, Kerberos is not usable in Java.

The error message is:
  KrbException: krb5.conf loading failed

(please find simple steps to reproduce below)

After debugging step by step, I found out that this is due to the fact
that the following Kerberos configuration directory
/var/lib/sss/pubconf/krb5.include.d/
ends up being included twice and that Java rejects multiple includes of the 
same directory.

This directory is included:

- in the configuration file /etc/krb5.conf.d/enable_sssd_conf_dir
which is deployed by the installation of the *package* freeipa-client
(probably indirectly by one of the sssd packages?)

- in the configuration file /etc/krb5.conf
which is generated by the ipa-client-install procedure

As a workaround, commenting out the includedir line in 
/etc/krb5.conf.d/enable_sssd_conf_dir
(or completely removing this file, since it contains only this line)
solves the problem.

Please note that:
- the issue occurs with Java 17, 11 and 21 (and most likely other available 
Java versions)
- the issue does NOT occur on bullseye with freeipa-client from backports
(which we have been using in production for a while)

In order to reproduce (on a host enrolled as an IPA client), using the standard 
Java JAAS Kerberos example:
https://docs.oracle.com/en/java/javase/17/security/jaas-authentication.html
(just copy JaasAcn.java and jaas.conf in the same directory; no need to compile)

$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java 
-Djava.security.auth.login.config=jaas.conf JaasAcn.java
Kerberos username [mbaudier]: 
Authentication failed:
  KrbException: krb5.conf loading failed

And the workaround:

$ sudo mv /etc/krb5.conf.d/enable_sssd_conf_dir /tmp

$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java 
-Djava.security.auth.login.config=jaas.conf JaasAcn.java
Kerberos username [mbaudier]: 
Kerberos password for mbaudier: 
Authentication succeeded!


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

Kernel: Linux 5.14.0-162.23.1.el9_1.x86_64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freeipa-client depends on:
ii  bind9-dnsutils [dnsutils]1:9.18.13-1
ii  bind9-utils  1:9.18.13-1
ii  certmonger   0.79.17-2
ii  curl 7.88.1-9
ii  dnsutils 1:9.18.13-1
ii  freeipa-common   4.9.11-1
ii  krb5-user1.20.1-1+b1
ii  libc62.36-9
ii  libcom-err2  1.47.0-2
ii  libcurl4 7.88.1-9
ii  libini-config5   0.6.2-1
ii  libjansson4  2.14-2
ii  libk5crypto3 1.20.1-1+b1
ii  libkrb5-31.20.1-1+b1
ii  libldap-2.5-02.5.13+dfsg-5
ii  libnss-sss   2.8.2-4
ii  libnss3-tools2:3.89-2
ii  libpam-sss   2.8.2-4
ii  libpopt0 1.19+dfsg-1
ii  libsasl2-modules-gssapi-mit  2.1.28+dfsg-11
ii  libssl3  3.0.8-1
ii  libsss-sudo  2.8.2-4
ii  oddjob-mkhomedir 0.34.7-1+b2
ii  python3  3.11.2-1+b1
ii  python3-dnspython2.3.0-1
ii  python3-gssapi   1.8.2-1+b1
ii  python3-ipaclient4.9.11-1
ii  python3-ldap 3.4.3-2+b2
ii  python3-sss  2.8.2-4
ii  sssd 2.8.2-4

Versions of packages freeipa-client recommends:
ii  chrony  4.3-2

Versions of packages freeipa-client suggests:
pn  libpam-krb5  

-- no debconf information

Bug#1034658: /etc/bash.bashrc: does not protect against unset PS1 => breaks when run with -u

[наб]

Package: bash
Version: 5.2.15-2+b1
Severity: normal
Tags: patch

Dear Maintainer,

When running the man-pages linters with 2>&1 | less, I got a wall of
  /etc/bash.bashrc: line 7: PS1: unbound variable

It uses
  SHELL := /usr/bin/env bash -Eeuo pipefail
and, /etc/bash.bashrc says, ll. 7,8:
  # If not running interactively, don't do anything
  [ -z "$PS1" ] && return

I've fixed this by making that expansion ${PS1-} instead;
this is what debian_chroot does below, for presumably the same reason.

I've preventatively done the same thing to the rest of the variables,
but just the PS1 thing was enough to run the tests.

I'm attaching a diff of the unpacked source
(incl. a $(cat => $(<; this a free optimisation in bash-specific code);
this would be much easier if the VCS pointed at anything (#1024158).

Best,
наб


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

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

Versions of packages bash depends on:
ii  base-files   12.4
ii  debianutils  5.7-0.4
ii  libc62.36-9
ii  libtinfo66.4-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-6

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information
diff -ur bash-5.2.15.orig/debian/etc.bash.bashrc bash-5.2.15/debian/etc.bash.bashrc
--- bash-5.2.15.orig/debian/etc.bash.bashrc	2023-04-21 04:27:38.741253125 +0200
+++ bash-5.2.15/debian/etc.bash.bashrc	2023-04-21 04:30:57.006972972 +0200
@@ -4,7 +4,7 @@
 # this file has to be sourced in /etc/profile.
 
 # If not running interactively, don't do anything
-[ -z "$PS1" ] && return
+[ -z "${PS1-}" ] && return
 
 # check the window size after each command and, if necessary,
 # update the values of LINES and COLUMNS.
@@ -12,12 +12,12 @@
 
 # set variable identifying the chroot you work in (used in the prompt below)
 if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
-debian_chroot=$(cat /etc/debian_chroot)
+debian_chroot=$(< /etc/debian_chroot)
 fi
 
 # set a fancy prompt (non-color, overwrite the one in /etc/profile)
 # but only if not SUDOing and have SUDO_PS1 set; then assume smart user.
-if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
+if ! [ -n "${SUDO_USER-}" -a -n "${SUDO_PS1-}" ]; then
   PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
 fi
 


signature.asc
Description: PGP signature

Bug#1034657: RFP: cafe-desktop -- This desktop environment is MATE desktop fork, and works with CTK (GTK3 fork).

[Fjords]

Package: cafe-desktop
Severity: wishlist

There is a MATE fork called CAFE, which uses the CTK toolkit (forked 
from GTK3). Seems there has been quite a bit of work in progress over 
the past year, and there are DEB files provided upstream. I have tested 
this on a VM with the forked packages, and it's running decently stable. 
I think this would be a good addition to Debian's repositories for 
anyone who likes MATE but isn't optimistic about GTK's future. Please 
take a look and consider its inclusion. Thank you.


Upstream: https://github.com/cafe-desktop

Bug#1034656: ITP: geneagrapher-core -- request and build graphs of records from the Math Genealogy Project

[Torrance, Douglas]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Doug Torrance 
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: wishlist

* Package name: geneagrapher-core
 Version : 0.1.0
 Upstream Author : David Alber 
* URL : https://github.com/davidalber/geneagrapher-core
* License : MIT
 Programming Lang: Python
 Description : request and build graphs of records from the Math Genealogy 
Project

Geneagrapher is a tool for extracting information from the
Mathematics Genealogy Project to form a math family tree, where
connections are between advisors and their students.

This package contains the core data-grabbing and manipulation
functions needed to build a math family tree. The functionality here
is low level and intended to support the development of other
tools. If you just want to build a geneagraph, take a look at
Geneagrapher. If you want to get mathematician records and use them in
code, then this project may be useful to you.

Note that this is a dependency of geneagrapher, which is already in Debian,
as of the latest release.  I intend to maintain this package under the
umbrella of the Debian Python Team.


signature.asc
Description: PGP signature

Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box

[James Addison]

Source: inkscape
Followup-For: Bug #1034289
X-Debbugs-Cc: giuseppe.bilo...@gmail.com, debian-gtk-gn...@lists.debian.org
Control: forwarded -1 https://gitlab.com/inkscape/inkscape/-/issues/3664

Dear Maintainer (and cc'ing the GTK-GNOME list),

Following on from Giuseppe's upstream link:

> Additional information: the issue I'm seeing seems to match upstream
> issue #3664
> https://gitlab.com/inkscape/inkscape/-/issues/3664

... to a further-upstream bug[1] in the GTK issue tracker, there's a reference
to GDK window repainting as the possible cause[2] (with a suggested fix).

The (untested) patch I've attached here applies the suggested change to
src:gtk+3.0 (and was created from version gtk+3.0-3.24.37 of it).

I don't yet have an environment prepared to build and test it, but will try to
create one soon.

Thanks,
James

[1] - https://gitlab.gnome.org/GNOME/gtk/-/issues/2560

[2] - https://gitlab.gnome.org/GNOME/gtk/-/issues/2560#note_757809
Description: gdkwindow: allow frame paint events to occur for non-toplevel 
windows
 .
 Partially-reverts upstream commit fc569f1ac6ff108afc17f7f439480273826af3a6.
Author: James Addison 
Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/2560
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034289
Last-Update: 2023-04-21

--- gtk+3.0-3.24.37.orig/gdk/gdkwindow.c
+++ gtk+3.0-3.24.37/gdk/gdkwindow.c
@@ -3253,7 +3253,7 @@ gdk_window_begin_draw_frame (GdkWindow
   return NULL;
 }
 
-  if (gdk_window_has_native (window) && gdk_window_is_toplevel (window))
+  if (gdk_window_has_native (window))
 gdk_window_begin_paint_internal (window, region);
 
   impl_class = GDK_WINDOW_IMPL_GET_CLASS (window->impl);
@@ -3307,7 +3307,7 @@ gdk_window_end_draw_frame (GdkWindow
   return;
 }
 
-  if (gdk_window_has_native (window) && gdk_window_is_toplevel (window))
+  if (gdk_window_has_native (window))
 gdk_window_end_paint_internal (window);
 
   impl_class = GDK_WINDOW_IMPL_GET_CLASS (window->impl);

Bug#1034347: spamd timeout after reboot: dns: bad dns reply: bgread: recv() failed

[Martin Michlmayr]

* Noah Meyerhans  [2023-04-20 09:31]:
> > Can you please add this fix as an update to bookworm.
> 
> Requested an unblock for bookworm at 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034639

Thank you, that's an excellent summary.  Thanks for taking the time
to fix and write this!

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1034655: lightdm: Login dialog after resuming from standby should match xflock4

[Stefan Tauner]

Package: lightdm
Version: 1.26.0-8
Severity: normal
X-Debbugs-Cc: stefan.tau...@gmx.at

Dear Maintainer,

since I am using autologin (because I am using FDE and have to unlock the OS
before boot anyway)
there are usually only two ways to interact with the lightdm: after locking the
session with xflock4
and after resuming from standby. While the UI behaves as I which after locking
manually it does not
when resuming: I'd like to simply enter my password to unlock the session after
resume but the UI is
blank in that case instead of having the username predefined and the focus on
the password field.
Objectively, this is a minor thing but for me it's about 50% of my interactions
:)

It's also a regression IMhO - at least in Debian 10 this worked perfectly (I
kinda skipped 11).
I presume the behavior is due to lightdm itself but maybe it is because of how
the session gets
locked when entering suspend (which is via systemctl suspend)?
The only changes I made to lightdm.conf are setting autologin-user to my
username and
autologin-user-timeout=0. This is a pretty fresh install of Bookworm.

KR


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

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

Versions of packages lightdm depends on:
ii  adduser3.132
ii  dbus   1.14.6-1
ii  debconf [debconf-2.0]  1.5.82
ii  libaudit1  1:3.0.9-1
ii  libc6  2.36-9
ii  libgcrypt201.10.1-3
ii  libglib2.0-0   2.74.6-2
ii  libpam-systemd [logind]252.6-1
ii  libpam0g   1.5.2-6
ii  libxcb11.15-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.8-2+b1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+23

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.20-2
pn  xserver-xephyr   

-- Configuration Files:
/etc/lightdm/lightdm.conf changed [not included]

-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm

Bug#1034431: FTBFS creating vof.bin when /bin/sh -> bash

[Vagrant Cascadian]

Control: found 1034431 1:7.2+dfsg-5

Also appears in the older version... and we fixed these tests on
tests.reproducible-builds.org, so it will likely start to FTBFS there...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1031152: system-config-printer: unlock button in system-config-printer provides no elevated permissions dialog

[Kevin Otte]

On my Debian 11 XFCE machine this works correctly. Make sure "PolicyKit 
Authentication Agent" is checked under "Session and Startup" -> 
"Application Autostart".


In Debian 12 under Sway the GNOME Authentication Agent segfaults, but I 
will take this up under separate cover. I was able to work around the 
issue for the moment by using lxpolkit for the authentication agent instead.

Bug#1034610: grub-common no longer supports labels

[Dario Andres Susman]

I'm afraid not. This is very old, perhaps, because I've been using 
"testing" on this box for a long time.
I should have saved the patch I did for myself. That's why referenced 
Bug 568084, because I did apply a change using that patch in 
/etc/grub.d/10_linux years ago. I should have kept a copy of the file. 
It wasn't overritten for ages until recently.


Another thing is that even if labels are not used, and UUID are 
disabled, the kernel (or something else?) switches what device is set 
for sda or sdb. Hence the problem booting up. I had no choice but to go 
back UUIDs for now. :\
Rather odd, because if I boot back with linux-6.1.0-6-amd64, it books 
perfectly (without enabling UUIDs).


I must admit, I'm rather confused by and with issue. It may be related 
with the kernel and not grub, perhaps? :S


Thank you!

Best regards,
Dario Susman


On 20/04/2023 14:57, Steve McIntyre wrote:

Control: severity -1 important

Hi!

On Wed, Apr 19, 2023 at 02:52:31PM -0300, Dario Susman wrote:

Package: grub-common
Version: 2.06-8
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

After upgrading to latest version of grub-common and kernel, the system
wouldn't boot up with the latest kernel. The device paths changed, sda1
to sdb1. I noticed that the grub config changed to use UUIDs, however
/etc/default/grub is set to use LABELS. Which is something I prefer to
do.

It seems that grub-mkinfo no longer supports the GRUB_ENABLE_LINUX_LABEL
parameters and has to be re-written for it to work.

Looking in the history, I can't see where we've ever supported
this. Can you tell me which version(s) ever had this working for you
please?





OpenPGP_signature
Description: OpenPGP digital signature

Bug#275623: sync root's .bashrc and .profile with bash's skeletons

[Santiago Vila]

El 20/4/23 a las 14:15, Askar Safin escribió:

Yes, current situation breaks bash-completion. Moreover, it breaks
bash-completion in standard debian images for docker. Because in this
images you enter the container as root via non-login shell. So,
bash-completion in docker simply doesn't work.


I want to keep dotfiles for root as simple as possible.
If you need to change them, you can always change them
in your system, and the changes will be preserved.

The feature which you are asking to be enabled by default is an
optional feature which in no way it's necessary to be present.

Therefore, this is really a wontfix, but for now I prefer to keep it as 
wishlist.

Thanks.

Bug#1034654: unblock: src:libsignal-protocol-c/2.3.3-3

[Martin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@security.debian.org

Dear release team, dear security team,

I added a patch to libsignal-protocol-c and uploaded to unstable.
It fixes https://security-tracker.debian.org/tracker/CVE-2022-48468
in an embedded code copy. Please let it go into bookworm. Thanks!

Cheers
diff -Nru libsignal-protocol-c-2.3.3/debian/changelog libsignal-protocol-c-2.3.3/debian/changelog
--- libsignal-protocol-c-2.3.3/debian/changelog	2023-01-13 00:49:29.0 +
+++ libsignal-protocol-c-2.3.3/debian/changelog	2023-04-20 21:52:41.0 +
@@ -1,3 +1,10 @@
+libsignal-protocol-c (2.3.3-3) unstable; urgency=medium
+
+  * Add patch to fix unsigned integer overflow in protobuf code
+CVE: https://security-tracker.debian.org/tracker/CVE-2022-48468
+
+ -- Martin   Thu, 20 Apr 2023 21:52:41 +
+
 libsignal-protocol-c (2.3.3-2) unstable; urgency=medium
 
   * Bump debhelper compat
diff -Nru libsignal-protocol-c-2.3.3/debian/patches/fix-unsigned-integer-overflow.patch libsignal-protocol-c-2.3.3/debian/patches/fix-unsigned-integer-overflow.patch
--- libsignal-protocol-c-2.3.3/debian/patches/fix-unsigned-integer-overflow.patch	1970-01-01 00:00:00.0 +
+++ libsignal-protocol-c-2.3.3/debian/patches/fix-unsigned-integer-overflow.patch	2023-04-20 21:49:54.0 +
@@ -0,0 +1,30 @@
+Description: Fix unsigned integer overflow
+ and fix regression caused by that fix
+ related CVE:
+ https://security-tracker.debian.org/tracker/CVE-2022-48468
+Author: 10054172 , Todd C. Miller 
+Origin: other
+Bug: https://github.com/protobuf-c/protobuf-c/issues/499
+Last-Update: 2023-04-20
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/protobuf-c/protobuf-c.c
 b/src/protobuf-c/protobuf-c.c
+@@ -2456,10 +2456,13 @@
+ 			return FALSE;
+ 
+ 		def_mess = scanned_member->field->default_value;
+-		subm = protobuf_c_message_unpack(scanned_member->field->descriptor,
+-		 allocator,
+-		 len - pref_len,
+-		 data + pref_len);
++		if (len >= pref_len)
++			subm = protobuf_c_message_unpack(scanned_member->field->descriptor,
++			 allocator,
++			 len - pref_len,
++			 data + pref_len);
++		else
++			subm = NULL;
+ 
+ 		if (maybe_clear &&
+ 		*pmessage != NULL &&
diff -Nru libsignal-protocol-c-2.3.3/debian/patches/series libsignal-protocol-c-2.3.3/debian/patches/series
--- libsignal-protocol-c-2.3.3/debian/patches/series	2023-01-13 00:49:29.0 +
+++ libsignal-protocol-c-2.3.3/debian/patches/series	2023-04-20 21:45:25.0 +
@@ -1 +1,2 @@
 full-library-version-soname.patch
+fix-unsigned-integer-overflow.patch

Bug#1034653: unblock: x264/2:0.164.3095+gitbaee400-3

[Sebastian Ramacher]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: x...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:x264

Please unblock package x264.

[ Reason ]
gpac has a long list of open security issues (see #1033116). As gpac is
a key package (via x264), it's not a removal candidate. With this
change, the x264 binary drops mp4box support and no longer links
libgpac11 which also removes gpac from the key packages set.

[ Impact ]
We will end up with an unfixed gpac in the archive. In bullseye we
currently have 156 open security issues in gpac. There "only" 48 issues
in bookworm.

[ Tests ]
x264 has autopkgtests.

[ Risks ]
Some users may rely on the mp4box support x264. They are required to
migrate to ffmpeg or other encoders. There are however none in the
archive.

[ 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 x264/2:0.164.3095+gitbaee400-2+b1

-- 
Sebastian Ramacher
diff -Nru x264-0.164.3095+gitbaee400/debian/changelog 
x264-0.164.3095+gitbaee400/debian/changelog
--- x264-0.164.3095+gitbaee400/debian/changelog 2022-06-16 19:31:55.0 
+0200
+++ x264-0.164.3095+gitbaee400/debian/changelog 2023-04-12 23:37:05.0 
+0200
@@ -1,3 +1,12 @@
+x264 (2:0.164.3095+gitbaee400-3) unstable; urgency=medium
+
+  * Team upload
+  * debian/: Disable gpac support
+gpac is a constant source of security issues. gpac support is disabled so
+it can be removed from bookworm.
+
+ -- Sebastian Ramacher   Wed, 12 Apr 2023 23:37:05 +0200
+
 x264 (2:0.164.3095+gitbaee400-2) unstable; urgency=medium
 
   * Team upload
diff -Nru x264-0.164.3095+gitbaee400/debian/confflags 
x264-0.164.3095+gitbaee400/debian/confflags
--- x264-0.164.3095+gitbaee400/debian/confflags 2018-08-28 23:13:27.0 
+0200
+++ x264-0.164.3095+gitbaee400/debian/confflags 2023-04-12 23:36:40.0 
+0200
@@ -11,14 +11,14 @@
MAKEFLAGS += -j$(NUMJOBS)
 endif
 
-common_confflags += --prefix=/usr --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
+common_confflags += --prefix=/usr --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) 
--disable-gpac
 
 ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
 common_confflags += --host=$(DEB_HOST_GNU_TYPE) 
--cross-prefix=$(DEB_HOST_GNU_TYPE)-
 endif
 
 ifneq (,$(filter stage1,$(DEB_BUILD_PROFILES)))
-common_confflags += --disable-avs --disable-ffms --disable-gpac
+common_confflags += --disable-avs --disable-ffms
 endif
 
 # XXX why isn't --enable-visualize used in the static build?
diff -Nru x264-0.164.3095+gitbaee400/debian/control 
x264-0.164.3095+gitbaee400/debian/control
--- x264-0.164.3095+gitbaee400/debian/control   2022-06-16 19:31:55.0 
+0200
+++ x264-0.164.3095+gitbaee400/debian/control   2023-04-12 23:37:05.0 
+0200
@@ -9,7 +9,6 @@
  debhelper-compat (= 13),
  libavformat-dev (>= 6:9) ,
  libffms2-dev ,
- libgpac-dev (>= 0.5.0+svn4288~) ,
  nasm (>= 2.13) [any-i386 any-amd64],
  pkg-config
 Standards-Version: 4.6.1
diff -Nru x264-0.164.3095+gitbaee400/debian/control.in 
x264-0.164.3095+gitbaee400/debian/control.in
--- x264-0.164.3095+gitbaee400/debian/control.in2022-06-11 
17:15:48.0 +0200
+++ x264-0.164.3095+gitbaee400/debian/control.in2023-04-12 
23:36:15.0 +0200
@@ -9,7 +9,6 @@
  debhelper-compat (= 13),
  libavformat-dev (>= 6:9) ,
  libffms2-dev ,
- libgpac-dev (>= 0.5.0+svn4288~) ,
  nasm (>= 2.13) [any-i386 any-amd64],
  pkg-config
 Standards-Version: 4.6.1

Bug#1034652: unblock: reportbug/12.0.0

[Nis Martensen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: report...@packages.debian.org, nis.marten...@web.de
Control: affects -1 + src:reportbug

Please pre-approve package reportbug (pre-upload)

[ Reason ]
Paul Gevers asked if we can have a version of reportbug that prevents
bug 992332 from happening again in bookworm. I'd like to use the
opportunity to include a few other small fixes as well if possible.

[ Impact ]
- Developers will be able to file bookworm-pu requests (#1034260)
- Developers will be able to file unblock requests for udeb-only
packages (#1034143)
- Reportbug won't get package names wrong in unblock requests if the
requested package name contains regex characters (#1031924)
- A developer preparing a reportbug release will be prevented from
uploading a package version that is not PEP440 compliant.
- Kernel info compiled by reportbug will consider an updated linux
kernel taint list.

[ Tests ]
There are no automated tests for the changes. All except the taint list
change have been tested manually.

[ Risks ]
Risks should be low. I'm filing this unblock request using the new
reportbug version that I'm planning to upload.

[ 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

Are the proposed changes okay to be uploaded?diff -Nru reportbug-11.6.0/debian/changelog reportbug-12.0.0/debian/changelog
--- reportbug-11.6.0/debian/changelog   2022-12-04 19:28:36.0 +0100
+++ reportbug-12.0.0/debian/changelog   2023-04-17 13:20:18.0 +0200
@@ -1,3 +1,27 @@
+reportbug (12.0.0) unstable; urgency=medium
+
+  [ Benjamin Drung ]
+  * Make Python version PEP440 compliant
+
+  [ Paul Wise ]
+  * Update Linux kernel taint list and location
+
+  [ Nis Martensen ]
+  * debian/control: update standards-version (no changes needed)
+  * reportbug.utils.get_package_status: force literal package name match when
+calling apt-cache show. Thanks to David Kalnischkies for comprehensive
+explanations on apt's command line argument features.
+(Closes: #1031924)
+
+  [ Roland Clobus ]
+  * reportbug.debbugs.check_package_info: fix crash with udeb-only pkg
+(Closes: #1034143)
+
+  [ Nis Martensen ]
+  * reportbug/utils.py: update CODENAME2SUITE for bookworm (Closes: #1034260)
+
+ -- Nis Martensen   Mon, 17 Apr 2023 13:20:18 +0200
+
 reportbug (11.6.0) unstable; urgency=medium
 
   [ Paul Wise ]
diff -Nru reportbug-11.6.0/debian/control reportbug-12.0.0/debian/control
--- reportbug-11.6.0/debian/control 2022-08-17 20:48:30.0 +0200
+++ reportbug-12.0.0/debian/control 2023-04-17 13:00:18.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Reportbug Maintainers 
 Uploaders: Sandro Tosi ,
Nis Martensen ,
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Build-Depends: debhelper-compat (= 12),
dh-python,
python3,
diff -Nru reportbug-11.6.0/debian/make_pep440_compliant 
reportbug-12.0.0/debian/make_pep440_compliant
--- reportbug-11.6.0/debian/make_pep440_compliant   1970-01-01 
01:00:00.0 +0100
+++ reportbug-12.0.0/debian/make_pep440_compliant   2023-04-17 
13:00:18.0 +0200
@@ -0,0 +1,24 @@
+#!/usr/bin/python3
+
+import re
+import sys
+
+
+def make_pep440_compliant(version: str) -> str:
+"""Convert the version into a PEP440 compliant version."""
+public_version_re = re.compile(
+r"^([0-9][0-9.]*(?:(?:a|b|rc|.post|.dev)[0-9]+)*)\+?"
+)
+_, public, local = public_version_re.split(version, maxsplit=1)
+if not local:
+return version
+sanitized_local = re.sub("[+~]+", ".", local).strip(".")
+pep440_version = f"{public}+{sanitized_local}"
+assert re.match(
+"^[a-zA-Z0-9.]+$", sanitized_local
+), f"'{pep440_version}' not PEP440 compliant"
+return pep440_version
+
+
+if __name__ == "__main__":
+print(make_pep440_compliant(sys.argv[1]))
diff -Nru reportbug-11.6.0/debian/rules reportbug-12.0.0/debian/rules
--- reportbug-11.6.0/debian/rules   2022-04-18 18:33:14.0 +0200
+++ reportbug-12.0.0/debian/rules   2023-04-17 13:00:18.0 +0200
@@ -3,15 +3,16 @@
 include /usr/share/dpkg/pkg-info.mk
 
 REPORTBUG_VERSION := $(shell python3 -c "import reportbug; 
print(reportbug.VERSION_NUMBER)")
+PEP440_DEB_VERSION := $(shell debian/make_pep440_compliant "$(DEB_VERSION)")
 
 %:
dh $@ --with=python3
 
 override_dh_auto_build:
# Test if versions are synchronized (only if releasing); this will bomb 
if not synced
-   if [ "$(DEB_DISTRIBUTION)" != "UNRELEASED" -a "$(REPORTBUG_VERSION)" != 
"$(DEB_VERSION)" ] ; \
+   if [ "$(DEB_DISTRIBUTION)" != "UNRELEASED" -a "$(REPORTBUG_VERSION)" != 
"$(PEP440_DEB_VERSION)" ] ; \
then \
-   echo 'Please update VERSION_NUMBER variable in 
reportbug/__init__.py'; exit 1 ; \
+   echo 'Please 

Bug#1034651: installation-reports: Somewhat successful installation on Radxa ROCK 4C+ (RK3399-T)

[Manfred Stock]

Package: installation-reports
Severity: normal
Tags: d-i

Boot method: microSD card with netboot SD-card-image built from 
firmware.rock-pi-4-rk3399.img.gz and partition.img.gz
Image version: 
https://deb.debian.org/debian/dists/testing/main/installer-arm64/current/images/netboot/SD-card-images/firmware.rock-pi-4-rk3399.img.gz
 and 
https://deb.debian.org/debian/dists/testing/main/installer-arm64/current/images/netboot/SD-card-images/partition.img.gz,
 dated from 2023-03-31T21:11:00
Date: ~2023-04-20T20:00:00

Machine: OKdo ROCK 4C+ powered by Radxa, a single board ARM64 computer based on 
RK3399-T
Partitions:
  # fdisk -l /dev/mmcblk0
  Disk /dev/mmcblk0: 29.72 GiB, 31914983424 bytes, 62333952 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: gpt
  Disk identifier: 12808202-944C-4D0B-A0BE-15B1F343F7C8

  DeviceStart  End  Sectors  Size Type
  /dev/mmcblk0p1 2048   999423   997376  487M Linux filesystem
  /dev/mmcblk0p2   999424 60332031 59332608 28.3G Linux filesystem
  /dev/mmcblk0p3 60332032 62332927  2000896  977M Linux swap


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

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

Comments/Problems:

Installation was done over the serial console - iirc, using a USB keyboard and
screen plugged into the HDMI output didn't work, I think I only saw some output
from u-boot and maybe the kernel, but nothing from the installer. I think I
also saw that the board was detected as "Radxa ROCK Pi 4B" (and thus the
corresponding DTB got used which got also installed and linked in /boot).

The installation process was smooth, I don't remember any error messages or
warnings. I used the automatic partitioning with the whole disk. However, when
rebooting, I just got the following:

  U-Boot TPL 2023.01+dfsg-2 (Jan 18 2023 - 01:57:16)
  lpddr4_set_rate: change freq to 400MHz 0, 1
  Channel 0: LPDDR4, 400MHz
  BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
  Channel 1: LPDDR4, 400MHz
  BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
  256B stride
  lpddr4_set_rate: change freq to 800MHz 1, 0
  Trying to boot from BOOTROM
  Returning to boot ROM...

  U-Boot SPL 2023.01+dfsg-2 (Jan 18 2023 - 01:57:16 +)
  Trying to boot from MMC1
  mmc_load_image_raw_sector: mmc block read error
  Trying to boot from MMC2
  Card did not respond to voltage select! : -110
  spl: mmc init failed with error: -95
  Trying to boot from MMC1
  mmc_load_image_raw_sector: mmc block read error
  SPL: failed to boot from all boot devices
  ### ERROR ### Please RESET the board ###

I'm not sure what went wrong here, but unplugging and plugging it in again
didn't change anything. After putting the microSD card in another machine,
bind-mounting /dev, mounting the root file system, installing the (not yet
installed) u-boot-rockchip package after chrooting into the root file system
and running 

  TARGET=/usr/lib/u-boot/rock-pi-4-rk3399 u-boot-install-rockchip /dev/mmcblk0

it successfully booted. So I guess that when using the whole disk, u-boot
doesn't get installed correctly or fully - or at all.

Before I arrived at the above solution, I made several other installation
attempts. In a (rare ;)) successful attempt, I didn't use the whole disk and
chose to manually partition it instead. I also reused the original but enlarged
partition where the installer resided as /boot and added new partitions for the
root file system and swap. That way, the system successfully booted immediately
after the installation. In that case, I assume it was just using the u-boot
that came with the installer image since the partition table wasn't recreated
during the installation - but I'm just guessing here.

Now that it booted, I still didn't get a lot of output on the attached screen,
iirc, it was only output from u-boot. Similarly on the serial console - there, I
only got output from u-boot and various error or warning messages from the
kernel, but no login prompt. I think the reason for this is that the wrong DTB
gets used. I don't remember all the details how I worked around that, but at
least part of the solution was adding

  Machine: Radxa ROCK 4C+
  Kernel-Flavors: arm64
  DTB-Id: rockchip/rk3399-rock-4c-plus.dtb
  Boot-Script-Path: /boot/boot.scr
  U-Boot-Script-Name: bootscr.uboot-generic
  Required-Packages: u-boot-tools

to /etc/flash-kernel/db,

  setenv fdtfile rockchip/rk3399-rock-4c-plus.dtb

to e.g. /etc/flash-kernel/ubootenv.d/rock4cplus and maybe

  Radxa ROCK 4C+

to 

Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion

[Cyril Brulebois]

Hi Askar,

and thanks for the report.

Askar Safin  (2023-04-20):
> I don't know what should really be done. I can list possible solutions:
> 
> - Fix d-i. Remove /usr/lib/finish-install.d/60cleanup or replace it with
>   something else

d-i is merely exposing a bug in bash-completion, so I don't think we
should change anything there.

> - Fix "apt-get clean". Make it not remove /var/cache/apt/*.bin
> - Fix "bash-completion". Make it work even if /var/cache/apt/*.bin are
>   not present (for example, by recreating them on-the-fly)

Clearly one of these. While I'm no apt maintainer and can't speak for
the semantics behind “apt-get clean”, it seems to me bash-completion's
relying on files that might not be there is the crux of the problem.


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


signature.asc
Description: PGP signature

Bug#1034420: grub-efi-amd64: Package update fails with error: installation script subprocess returned error exit status 128

[Steve McIntyre]

Hi!

On Fri, Apr 14, 2023 at 09:23:03PM +0200, Andrea Palazzi wrote:
>Package: grub-efi-amd64
>Version: 2.06-8
>Severity: important
>X-Debbugs-Cc: palazziand...@yahoo.it
>
>Dear Maintainer,
>   * What led up to the situation?
>updating the system with apt update && apt upgrade
>
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>apt-update && apt-upgrade
>
>   * What was the outcome of this action?
>Setting up grub-efi-amd64 (2.06-8) ...
>dpkg: error processing package grub-efi-amd64 (--configure):
> installed grub-efi-amd64 package post-installation script subprocess returned 
> error exit status 128
>dpkg: dependency problems prevent configuration of grub-efi:
> grub-efi depends on grub-efi-amd64 (= 2.06-8); however:
>  Package grub-efi-amd64 is not configured yet.
>
>dpkg: error processing package grub-efi (--configure):
> dependency problems - leaving unconfigured
>Errors were encountered while processing:
> grub-efi-amd64
> grub-efi
>E: Sub-process /usr/bin/dpkg returned an error code (1)

There's not a lot to see here so far. What happens if you run:

  "sudo grub-install -v"

by hand please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#1034638: wmaker: comments in appearance.menu not allowed

[Torrance, Douglas]

Control: forwarded -1 https://github.com/window-maker/wmaker/issues/28

On Thu 20 Apr 2023 11:31:51 AM -04, Helge Kreutzmann  
wrote:

[[PGP Signed Part:Undecided]]
Package: wmaker
Version: 0.95.9-3+b2
Severity: minor

Yesterday I got the following error messaage:
2023-04-19T20:00:02.520024+02:00 twentytwo
/usr/libexec/WindowMaker/wmaker[2864]: (getPropList(proplist.c:885)):
warnung: Syntaxfehler in file /usr/share/WindowMaker/appearance.menu,
Zeile 1: Zeichenkette, Binärdaten, Array oder Dictionary
erwartet. Zeichenketten ggf. mit " einklammern.
2023-04-19T20:00:02.521878+02:00 twentytwo 
/usr/libexec/WindowMaker/wmaker[2864]: (getPropList(proplist.c:888)): warnung: 
Kommentare sind in Domänendaten von WindowMaker nicht erlaubt.

In english:
Warning: Syntaxerror in  file /usr/share/WindowMaker/appearance.menu line 1: String, 
binary data, array or dictionary expected. Escape strings possibly by "
Warning: Comments are not allowed within domain names from window maker.


# head /usr/share/WindowMaker/appearance.menu
#include "wmmacros"

Appearance MENU
  "Background" OPEN_MENU background.menu


Thanks for the reported!  Forwarding upstream.


signature.asc
Description: PGP signature

Bug#1034646: [pre-approval] unblock: fuse3/3.14.0-4

[Cyril Brulebois]

Hi László,

László Böszörményi  (2023-04-20):
> [ Risks ]
> Minimal, the fixes are small and very targeted. Should not affect the
> installer creation (as it uses the fuse3 udeb), but kibi is also
> pinged for an extra check.

Thanks, appreciated.

No objections from the d-i side.


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


signature.asc
Description: PGP signature

Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion

[Askar Safin]

Package: debian-installer
Severity: normal
Tags: d-i

Steps to reproduce:
- Install debian using recently published debian-bookworm-DI-
rc1-amd64-netinst.iso
- At first boot as a very first thing to do type "apt-get install a" (as
root, in normal root login shell)
- You will see that bash-completion doesn't work
- If you type "apt-get install apt", and try "apt-get install a"
again, you will see that bash-completion works

This situation is very bad. Imagine you installed Debian. Of course, the first
thing you may try to do is install some package to it. So it is quite possible
you will type "apt-get install ..." as a first thing. And you will see that
bash-completion doesn't work!

(Don't confuse "apt-get install a" with "apt-get insta")

I think I know why this happens. d-i has file /usr/lib/finish-
install.d/60cleanup. This file calls "apt-get clean". "apt-get clean" removes
"/var/cache/apt/*.bin". And "/var/cache/apt/*.bin" are needed for bash-
completion to work with apt.

If I remove /usr/lib/finish-install.d/60cleanup, then this bug disappears.

So, if you want to quickly fix this bug, simply delete /usr/lib/finish-
install.d/60cleanup.

I don't know what should really be done. I can list possible solutions:

- Fix d-i. Remove /usr/lib/finish-install.d/60cleanup or replace it with
something else
- Fix "apt-get clean". Make it not remove /var/cache/apt/*.bin
- Fix "bash-completion". Make it work even if /var/cache/apt/*.bin are not
present (for example, by recreating them on-the-fly)

(Disregard "System information" below)



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

Kernel: Linux 5.10.0-0.deb9.21-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1034649: 7kaa: Unplugging USB headset hangs 7kaa

[Nils Dagsson Moskopp]

Package: 7kaa
Version: 2.15.4p1+dfsg-1
Severity: normal
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

whenever I unplug the USB headset while 7kaa is running, it hangs.
7kaa prints a single line of output to the terminal, quoted below:

> AL lib: (EE) ALCpulsePlayback_streamStateCallback: Received stream failure!

“lsusb” outputs the following information about the USB headset:

> Bus 003 Device 017: ID 0b0e:0308 GN Netcom Jabra EVOLVE LINK

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

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

Versions of packages 7kaa depends on:
ii  7kaa-data2.15.4p1+dfsg-1
ii  libc62.31-13+deb11u5
ii  libcurl3-gnutls  7.74.0-1.3+deb11u7
ii  libenet7 1.3.13+ds-1
ii  libgcc-s110.2.1-6
ii  libopenal1   1:1.19.1-2
ii  libsdl2-2.0-02.0.14+dfsg2-3+deb11u1
ii  libstdc++6   10.2.1-6
ii  libuuid1 2.36.1-8+deb11u1

7kaa recommends no packages.

Versions of packages 7kaa suggests:
pn  7kaa-music  

-- no debconf information

Bug#1034648: postinst runs linux-update-symlinks before initrd exists

[Joey Hess]

Source: linux
Version: 6.1.20-2
Severity: normal

I was upgrading a slow arm board and noticed this:

Setting up linux-image-6.1.0-7-armmp-lpae (6.1.20-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.18.0-4-armmp-lpae
I: /initrd.img.old is now a symlink to boot/initrd.img-5.18.0-4-armmp-lpae
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-7-armmp-lpae
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-7-armmp-lpae
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-7-armmp-lpae

It probably took 5 minutes to generate the initrd, and until then
/initrd.img was a dangling symlink. A power failure in this wide window would
not be fun.

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

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

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1034647: unblock: gammu/1.42.0-8

[Boian Bonev]

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

Please unblock package gammu

This upload fixes RC bug #1034237
All changes are kept as minimal as possible

[ Reason ]
Closes RC bug

[ Impact ]
gammu will be dropped out of bookworm and all its users will be unhappy

[ Tests ]
Manually verified that upgrade and downgrade go smooth on usrmerged sid

[ Risks ]
The main risk is moving a file from /usr/lib to /lib
The move does not involve different packages and should be safe

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

Thanks to Santiago Vila for the review and advice

unblock gammu/1.42.0-8
diff -Nru gammu-1.42.0/debian/changelog gammu-1.42.0/debian/changelog
--- gammu-1.42.0/debian/changelog   2023-01-31 17:39:21.0 +
+++ gammu-1.42.0/debian/changelog   2023-04-11 15:27:43.0 +
@@ -1,3 +1,9 @@
+gammu (1.42.0-8) unstable; urgency=medium
+
+  * Install systemd files in /lib (Closes: #1034237)
+
+ -- Boian Bonev   Tue, 11 Apr 2023 15:27:43 +
+
 gammu (1.42.0-7) unstable; urgency=medium
 
   * Move dep on tzdata (Closes: #1029417)
diff -Nru gammu-1.42.0/debian/control gammu-1.42.0/debian/control
--- gammu-1.42.0/debian/control 2023-01-31 17:39:21.0 +
+++ gammu-1.42.0/debian/control 2023-04-11 15:27:43.0 +
@@ -15,6 +15,7 @@
  libglib2.0-dev,
  libgudev-1.0-dev [linux-any],
  libpq-dev,
+ libsystemd-dev,
  libusb-1.0-0-dev [linux-any],
  pkg-config,
  sqlite3,
diff -Nru gammu-1.42.0/debian/gammu-smsd.install 
gammu-1.42.0/debian/gammu-smsd.install
--- gammu-1.42.0/debian/gammu-smsd.install  2023-01-31 10:28:05.0 
+
+++ gammu-1.42.0/debian/gammu-smsd.install  2023-04-11 15:27:43.0 
+
@@ -1,8 +1,8 @@
 debian/gammu-smsdrc /etc/
+lib/systemd/system/gammu-smsd.service
 usr/bin/gammu-smsd
 usr/bin/gammu-smsd-inject
 usr/bin/gammu-smsd-monitor
-usr/lib/systemd/system/gammu-smsd.service
 usr/share/man/man1/gammu-smsd*
 usr/share/man/man5/gammu-smsd*
 usr/share/man/man7/gammu-smsd*
diff -Nru gammu-1.42.0/debian/rules gammu-1.42.0/debian/rules
--- gammu-1.42.0/debian/rules   2023-01-29 21:07:57.0 +
+++ gammu-1.42.0/debian/rules   2023-04-11 15:27:43.0 +
@@ -29,7 +29,7 @@
 override_dh_auto_configure:
dh_auto_configure -- \
-DINSTALL_LIBDATA_DIR=/usr/lib/${DEB_HOST_MULTIARCH} \
-   -DSYSTEMD_SERVICES_INSTALL_DIR=/usr/lib/systemd/system \
+   -DSYSTEMD_SERVICES_INSTALL_DIR=/lib/systemd/system \
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
-DINSTALL_LSB_INIT=ON \
-DSYSTEMD_FOUND=ON \

Bug#1031370:

[Robin Gustafsson]

Hi,

I've submitted a merge request on Salsa to fix this.
https://salsa.debian.org/python-team/packages/python-werkzeug/-/merge_requests/3

Regards,
Robin

Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore

[Thomas Viehweger]

Hi,

I can confirm that DVB playback  is now working again for me with 
mpv_0.35.1-4_amd64.deb.

Thanks!

Bug#1034646: [pre-approval] unblock: fuse3/3.14.0-4

[GCS]

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

Hi RMs,

Two issues in src:fuse3 I would like to have fixed for Bookworm.

[ Reason ]
There's a memory leak in the high level API [1] and the fuse CLI
doesn't propagate the allowed maximum threads to use [2].

[ Impact ]
In special cases like fuse3 would get a signal during its start it
would leak some memory. Users can't set usage constraints in terms of
threads (CPU) usage. These are not common situations but would be
better to handle these.

[ Tests ]
Upstream test suite. Tested and built correctly in experimental.
Waiting for your permission to upload to Sid.

[ Risks ]
Minimal, the fixes are small and very targeted. Should not affect the
installer creation (as it uses the fuse3 udeb), but kibi is also
pinged for an extra check.

[ 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 fuse3/3.14.0-4

Thanks for considering,
Laszlo/GCS
[1] https://github.com/libfuse/libfuse/pull/781
[2] https://github.com/libfuse/libfuse/pull/742
diff -Nru fuse3-3.14.0/debian/changelog fuse3-3.14.0/debian/changelog
--- fuse3-3.14.0/debian/changelog	2023-03-17 20:51:05.0 +0100
+++ fuse3-3.14.0/debian/changelog	2023-04-18 23:07:15.0 +0200
@@ -1,3 +1,11 @@
+fuse3 (3.14.0-4) unstable; urgency=medium
+
+  * Backport upstream fixes:
+- fix max_threads command line parameter propagation,
+- fix memory leak in high level API.
+
+ -- Laszlo Boszormenyi (GCS)   Tue, 18 Apr 2023 23:07:15 +0200
+
 fuse3 (3.14.0-3) unstable; urgency=medium
 
   [ Helge Deller  ]
diff -Nru fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch
--- fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch	1970-01-01 01:00:00.0 +0100
+++ fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch	2023-04-17 21:34:29.0 +0200
@@ -0,0 +1,24 @@
+From ab5ca07af03b7dbb33193666c13b938534bde0e4 Mon Sep 17 00:00:00 2001
+From: Sarath Lakshman 
+Date: Sat, 11 Mar 2023 16:58:31 +0530
+Subject: [PATCH] Fix max_threads command line parameter propagation
+
+The fuse_main_real() method doesn't apply the max_threads parameter
+parsed through the commandline arguments. This commit fixes the wiring
+of max_threads argument.
+---
+ lib/helper.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/helper.c b/lib/helper.c
+index 35c6a98c..14a0df33 100644
+--- a/lib/helper.c
 b/lib/helper.c
+@@ -377,6 +377,7 @@ int fuse_main_real(int argc, char *argv[], const struct fuse_operations *op,
+ 		fuse_loop_cfg_set_clone_fd(loop_config, opts.clone_fd);
+ 
+ 		fuse_loop_cfg_set_idle_threads(loop_config, opts.max_idle_threads);
++		fuse_loop_cfg_set_max_threads(loop_config, opts.max_threads);
+ 		res = fuse_loop_mt(fuse, loop_config);
+ 	}
+ 	if (res)
diff -Nru fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch
--- fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch	1970-01-01 01:00:00.0 +0100
+++ fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch	2023-04-17 21:34:29.0 +0200
@@ -0,0 +1,66 @@
+From fcd293f675fc7bfa0522186c5d68ef932eec6945 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Matthias=20G=C3=B6rgens?= 
+Date: Fri, 14 Apr 2023 19:19:03 +0800
+Subject: [PATCH] Fix memory leak in high level API (#781)
+
+Previously, in the high level API if we received a signal between
+setting up signal handlers and processing INIT, we would leak
+
+```
+$ ./example/hello -s -d -f mountpoint/
+[9/9] Linking target example/hello_ll
+FUSE library version: 3.14.1
+nullpath_ok: 0
+
+=
+==178330==ERROR: LeakSanitizer: detected memory leaks
+
+Direct leak of 352 byte(s) in 1 object(s) allocated from:
+#0 0x7fbb19abf411 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
+#1 0x7fbb1a0efd3b in fuse_fs_new ../lib/fuse.c:4814
+#2 0x7fbb1a0f02b5 in fuse_new_31 ../lib/fuse.c:4913
+#3 0x7fbb1a10ec5e in fuse_main_real ../lib/helper.c:345
+#4 0x5625db8ab418 in main ../example/hello.c:176
+#5 0x7fbb1983c78f  (/usr/lib/libc.so.6+0x2378f)
+
+SUMMARY: AddressSanitizer: 352 byte(s) leaked in 1 allocation(s).
+```
+
+That's because `fuse_lowlevel.c`s `fuse_session_destroy` would only call
+the user supplied `op.destroy`, if INIT had been processed, but the high
+level API relied on `op.destroy` to free `f->fs`.
+
+This patch moves the freeing into `fuse_destroy` that will always be
+called by our high-level API.
+---
+ lib/fuse.c | 3 +--
+ 1 file changed, 1 

Bug#1034645: unblock: graphicsmagick/1.4+really1.3.40-4

[GCS]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:graphicsmagick

Hi RMs,

Two security fixes were added to graphicsmagick and I would like to
get those to Bookworm.

[ Reason ]
It was found that the MIFF reader was somehow able to provide
attribute data in a way which resulted in a heap overflow. There is
also a memory leak fix.

[ Impact ]
The heap overflow was detected by ASAN, meaning it might be
exploitable. The memory leak is in the handling of the
EXIF:Orientation key, common in images.

[ Tests ]
Upstream test suite.

[ Risks ]
Minimal but if there would be any issue upstream is quick to address them.

[ 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 graphicsmagick/1.4+really1.3.40-4

Thanks for considering,
Laszlo/GCS
diff -Nru graphicsmagick-1.4+really1.3.40/debian/changelog graphicsmagick-1.4+really1.3.40/debian/changelog
--- graphicsmagick-1.4+really1.3.40/debian/changelog	2023-01-19 19:44:45.0 +0100
+++ graphicsmagick-1.4+really1.3.40/debian/changelog	2023-04-17 19:17:10.0 +0200
@@ -1,3 +1,19 @@
+graphicsmagick (1.4+really1.3.40-4) unstable; urgency=medium
+
+  * Remove development ifdef from memory leak fix.
+
+ -- Laszlo Boszormenyi (GCS)   Mon, 17 Apr 2023 19:17:10 +0200
+
+graphicsmagick (1.4+really1.3.40-3) unstable; urgency=high
+
+  * Backport security fixes:
+- MIFF reader able to provide attribute data in way which results in
+  a heap overflow,
+- SetImageAttribute(): eliminate memory leak when handling attribute
+  with key "EXIF:Orientation".
+
+ -- Laszlo Boszormenyi (GCS)   Sun, 16 Apr 2023 14:21:32 +0200
+
 graphicsmagick (1.4+really1.3.40-2) unstable; urgency=medium
 
   * Don't force tiff dependency, let shlibs handle it (closes: #1029212).
diff -Nru graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch
--- graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch	1970-01-01 01:00:00.0 +0100
+++ graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch	2023-04-17 19:17:10.0 +0200
@@ -0,0 +1,115 @@
+
+# HG changeset patch
+# User Bob Friesenhahn 
+# Date 1681598921 18000
+# Node ID 3ce01217413bb5b476460bbc8ab11020205eeda0
+# Parent  8bec800dbaef2d72da0e7e997ad45bece0e95893
+SetImageAttribute(): Eliminate memory leak when handling attribute with key "EXIF:Orientation"
+
+diff -r 8bec800dbaef -r 3ce01217413b ChangeLog
+--- a/ChangeLog	Sat Apr 08 18:31:31 2023 -0500
 b/ChangeLog	Sat Apr 15 17:48:41 2023 -0500
+@@ -1,3 +1,9 @@
++2023-04-15  Bob Friesenhahn  
++
++	* magick/attribute.c (SetImageAttribute): Eliminate memory leak
++	when handling attribute with key "EXIF:Orientation".  (SourceForge
++	issue #707 "memory leaks in gm").
++
+ 2023-04-08  Bob Friesenhahn  
+ 
+ 	* coders/mpc.c (ReadMPCImage): If an attribute appears multiple
+diff -r 8bec800dbaef -r 3ce01217413b coders/miff.c
+--- a/coders/miff.c	Sat Apr 08 18:31:31 2023 -0500
 b/coders/miff.c	Sat Apr 15 17:48:41 2023 -0500
+@@ -761,6 +761,8 @@ SetNewImageAttribute(Image *image,const
+   MagickPassFail
+ status;
+ 
++  status = SetImageAttribute(image,key,value);
++
+   if (GetImageAttribute(image,key) == (const ImageAttribute *) NULL)
+ status = SetImageAttribute(image,key,value);
+   else
+diff -r 8bec800dbaef -r 3ce01217413b magick/attribute.c
+--- a/magick/attribute.c	Sat Apr 08 18:31:31 2023 -0500
 b/magick/attribute.c	Sat Apr 15 17:48:41 2023 -0500
+@@ -3178,9 +3178,6 @@
+   register ImageAttribute
+ *p;
+ 
+-  int
+-orientation;
+-
+   /*
+ Initialize new attribute.
+   */
+@@ -3271,6 +3268,9 @@
+ 
+   if (LocaleCompare(attribute->key,"EXIF:Orientation") == 0)
+ {
++  int
++orientation = 0;
++
+   /*
+ Special handling for EXIF orientation tag.
+ If new value differs from existing value,
+@@ -3278,17 +3278,19 @@
+ is valid. Don't append new value to existing value,
+ replace it instead.
+   */
+-  orientation = MagickAtoI(value);
+-  if (orientation > 0 || orientation <= (int)LeftBottomOrientation)
+-SetEXIFOrientation(image, orientation);
+-
+-  /* Replace current attribute with new one */
+-  attribute->next = p->next;
+-  if (p->previous == (ImageAttribute *) NULL)
+-image->attributes=attribute;
+-  else
+-p->previous->next = attribute;
+-  DestroyImageAttribute(p);
++  if ((MagickAtoIChk(value, ) == 

Bug#1034644: fbterm: FTBFS if ncurses is configured with "--disable-root-env"

[Sven Joachim]

Control: tags -1 + patch

On 2023-04-20 20:10 +0200, Sven Joachim wrote:

> Source: fbterm
> Version: 1.7-5
> Tags: ftbfs
>
> If ncurses is configured with "--disable-root-env", fbterm FTBFS.  The
> reason is that with that option ncurses programs ignore the TERMINFO
> variable when run as root, or even under fakeroot.  From my build log:
>
> ,
> | TERMINFO=/tmp/fbterm-1.7/debian/fbterm/usr/share/terminfo tic fbterm
> | "fbterm", line 2, terminal 'fbterm': /etc/terminfo/f: permission denied
> | make[3]: *** [Makefile:424: install-data-local] Error 1
> | make[3]: Leaving directory '/tmp/fbterm-1.7/terminfo'
> | make[2]: *** [Makefile:317: install-am] Error 2
> | make[2]: Leaving directory '/tmp/fbterm-1.7/terminfo'
> | make[1]: *** [Makefile:378: install-recursive] Error 1
> | make[1]: Leaving directory '/tmp/fbterm-1.7'
> | dh_auto_install: error: make -j2 install 
> DESTDIR=/tmp/fbterm-1.7/debian/fbterm AM_UPDATE_INFO_DIR=no returned exit 
> code 2
> | make: *** [debian/rules:4: binary] Error 25
> `

The attached patch takes care of that by using tic's -o option instead
of the TERMINFO variable.  I find it rather strange that you are
patching both Makefile.am and Makefile.in, as the latter should be
regenerated from the former, but whatever.

BTW, my suggestion to let ncurses-term take over the fbterm terminfo
entry (see #897959) still holds.

Cheers,
   Sven

From 055ae93fac996d66e0be3891eb134847f5e4241f Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Thu, 20 Apr 2023 20:23:14 +0200
Subject: [PATCH] Use tic's -o option to install the fbterm terminfo file

Rather than relying on the TERMINFO variable, which does not work
under fakeroot if ncurses is configured with "--disable-root-env".

Closes: #1034644
---
 debian/patches/01_add_terminfo_path | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/patches/01_add_terminfo_path b/debian/patches/01_add_terminfo_path
index 8f186f8..65f31bf 100644
--- a/debian/patches/01_add_terminfo_path
+++ b/debian/patches/01_add_terminfo_path
@@ -1,6 +1,6 @@
 Description: Add TERMINFO path to terminfo/Makefile.*
 Author: Nobuhiro Iwamatsu 
-Last-Update: 2020-04-20
+Last-Update: 2023-04-20

 diff --git a/terminfo/Makefile.am b/terminfo/Makefile.am
 index b023297..2c5ba34 100644
@@ -11,7 +11,7 @@ index b023297..2c5ba34 100644

  install-data-local:
 -	tic fbterm
-+	TERMINFO=$(DESTDIR)/usr/share/terminfo tic fbterm
++	tic -o $(DESTDIR)/usr/share/terminfo fbterm
 diff --git a/terminfo/Makefile.in b/terminfo/Makefile.in
 index 92cfbd9..ae09eb7 100644
 --- a/terminfo/Makefile.in
@@ -21,7 +21,7 @@ index 92cfbd9..ae09eb7 100644

  install-data-local:
 -	tic fbterm
-+	TERMINFO=$(DESTDIR)/usr/share/terminfo tic fbterm
++	tic -o $(DESTDIR)/usr/share/terminfo fbterm

  # Tell versions [3.59,3.63) of GNU make to not export all variables.
  # Otherwise a system limit (for SysV at least) may be exceeded.
--
2.40.0

Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

[Steven Robbins]

Just a note to say that I have used a Debian "testing" chroot environment and 
can reproduce the reported crash.  I will be investigating more in the coming 
days.

-Steve


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

Bug#1034644: fbterm: FTBFS if ncurses is configured with "--disable-root-env"

[Sven Joachim]

Source: fbterm
Version: 1.7-5
Tags: ftbfs

If ncurses is configured with "--disable-root-env", fbterm FTBFS.  The
reason is that with that option ncurses programs ignore the TERMINFO
variable when run as root, or even under fakeroot.  From my build log:

,
| TERMINFO=/tmp/fbterm-1.7/debian/fbterm/usr/share/terminfo tic fbterm
| "fbterm", line 2, terminal 'fbterm': /etc/terminfo/f: permission denied
| make[3]: *** [Makefile:424: install-data-local] Error 1
| make[3]: Leaving directory '/tmp/fbterm-1.7/terminfo'
| make[2]: *** [Makefile:317: install-am] Error 2
| make[2]: Leaving directory '/tmp/fbterm-1.7/terminfo'
| make[1]: *** [Makefile:378: install-recursive] Error 1
| make[1]: Leaving directory '/tmp/fbterm-1.7'
| dh_auto_install: error: make -j2 install 
DESTDIR=/tmp/fbterm-1.7/debian/fbterm AM_UPDATE_INFO_DIR=no returned exit code 2
| make: *** [debian/rules:4: binary] Error 25
`

For the reasons why I am considering the "--disable-root-env" option in
ncurses, see #1034372.


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

Bug#1034643: unblock: avahi/0.8-10

[Michael Biebl]

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

Please unblock package avahi


[ Reason ]
The main issue is the fix for CVE-2023-1981, a local denial of service
that can be executed by unprivileged users.

The removal of the bind9-host dependency is a change that had already
been committed to git and I didn't want to revert it.

Updating debian/watch doesn't affect the binary package itself.

[ Impact ]
If the package is not updated, users are vulnerable to CVE-2023-1981.

[ Tests ]
No automated tests for the affected code is available.

[ Risks ]
I consider the risk rather low as it's a targetted fix which has been
approved/applied upstream.


[ 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 ]
(Anything else the release team should know.)

unblock avahi/0.8-10
diff --git a/debian/changelog b/debian/changelog
index 81e976a7..8efca465 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+avahi (0.8-10) unstable; urgency=medium
+
+  [ Felix Geyer ]
+  * Remove dependency on bind9-host.
+Originally added in #433030, no longer needed as the
+avahi-daemon-check-dns.sh script is no longer shipped.
+
+  [ Michael Biebl ]
+  * Emit error if requested service is not found.
+Fixes a potential local DoS where the avahi daemon could be crashed by
+an unprivileged user via a D-Bus call.
+(CVE-2023-1981, Closes: #1034594)
+  * Update watch file to get tarballs directly from avahi.org again.
+The recent changes in GitHub broke the current watch file.
+As new releases are again uploaded to avahi.org, get the release
+tarballs from there.
+
+ -- Michael Biebl   Wed, 19 Apr 2023 13:51:49 +0200
+
 avahi (0.8-9) unstable; urgency=medium
 
   [ Gioele Barabucci ]
diff --git a/debian/control b/debian/control
index 6210237d..2ee1cdc1 100644
--- a/debian/control
+++ b/debian/control
@@ -38,7 +38,6 @@ Depends: ${shlibs:Depends},
  ${misc:Depends},
  adduser,
  default-dbus-system-bus | dbus-system-bus,
- bind9-host | host
 Recommends: libnss-mdns,
 Suggests: avahi-autoipd
 Multi-Arch: foreign
diff --git a/debian/patches/Emit-error-if-requested-service-is-not-found.patch 
b/debian/patches/Emit-error-if-requested-service-is-not-found.patch
new file mode 100644
index ..19eb2b96
--- /dev/null
+++ b/debian/patches/Emit-error-if-requested-service-is-not-found.patch
@@ -0,0 +1,54 @@
+From: =?utf-8?b?UGV0ciBNZW7FocOtaw==?= 
+Date: Thu, 17 Nov 2022 01:51:53 +0100
+Subject: Emit error if requested service is not found
+
+It currently just crashes instead of replying with error. Check return
+value and emit error instead of passing NULL pointer to reply.
+
+Fixes #375
+
+(cherry picked from commit a2696da2f2c50ac43b6c4903f72290d5c3fa9f6f)
+---
+ avahi-daemon/dbus-protocol.c | 20 ++--
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+diff --git a/avahi-daemon/dbus-protocol.c b/avahi-daemon/dbus-protocol.c
+index 70d7687..406d0b4 100644
+--- a/avahi-daemon/dbus-protocol.c
 b/avahi-daemon/dbus-protocol.c
+@@ -375,10 +375,14 @@ static DBusHandlerResult 
dbus_get_alternative_host_name(DBusConnection *c, DBusM
+ }
+ 
+ t = avahi_alternative_host_name(n);
+-avahi_dbus_respond_string(c, m, t);
+-avahi_free(t);
++if (t) {
++avahi_dbus_respond_string(c, m, t);
++avahi_free(t);
+ 
+-return DBUS_HANDLER_RESULT_HANDLED;
++return DBUS_HANDLER_RESULT_HANDLED;
++} else {
++return avahi_dbus_respond_error(c, m, AVAHI_ERR_NOT_FOUND, "Hostname 
not found");
++}
+ }
+ 
+ static DBusHandlerResult dbus_get_alternative_service_name(DBusConnection *c, 
DBusMessage *m, DBusError *error) {
+@@ -389,10 +393,14 @@ static DBusHandlerResult 
dbus_get_alternative_service_name(DBusConnection *c, DB
+ }
+ 
+ t = avahi_alternative_service_name(n);
+-avahi_dbus_respond_string(c, m, t);
+-avahi_free(t);
++if (t) {
++avahi_dbus_respond_string(c, m, t);
++avahi_free(t);
+ 
+-return DBUS_HANDLER_RESULT_HANDLED;
++return DBUS_HANDLER_RESULT_HANDLED;
++} else {
++return avahi_dbus_respond_error(c, m, AVAHI_ERR_NOT_FOUND, "Service 
not found");
++}
+ }
+ 
+ static DBusHandlerResult dbus_create_new_entry_group(DBusConnection *c, 
DBusMessage *m, DBusError *error) {
diff --git a/debian/patches/dbus-Use-non-deprecated-installation-path.patch 
b/debian/patches/dbus-Use-non-deprecated-installation-path.patch
index 796c97dc..cb348788 100644
--- a/debian/patches/dbus-Use-non-deprecated-installation-path.patch
+++ b/debian/patches/dbus-Use-non-deprecated-installation-path.patch
@@ -1,6 +1,7 @@
 From: Jan Tojnar 
 Date: Sat, 21 May 2022 19:02:11 +0200
 Subject: dbus: Use non-deprecated 

Bug#1028250: debian-installer: broken cryptsetup support

[Cyril Brulebois]

Hi,

(Letting Paul and the bug report know about our little chat.)

Guilhem Moulin  (2023-04-20):
> AFAICT the issue is now fully fixed upstream: on systems without swap
> the memory cost won't exceed half the amount of free memory during
> PBKDF benchmarking.

As a reminder: the “no swap” case happens in d-i when using guided
partitioning, as the swap will only be added/activated after formatting
the disk.

>  * Don't do anything: ship 2:2.6.1-3~deb12u1 in bookworm and leave the
>DI errata in place.  The downside is that the PBKDF needs roughly
>half of the physical memory, so the OOM killer might trigger if the
>rest of the system uses close to the other half.  Moreover this not
>future proof, as memory requirement increases along releases.  (That
>said the issue has been present since 2 releases and there is nothing
>we can do about existing volumes.  Concretely, that means low-memory
>Bookworm rescue systems will likely OOM when trying to luksOpen an
>existing LUKS2 volume in graphical mode.)

I'd rather avoid that one for the reasons you mention.

>  * Wait for upstream to release 2.6.2 with fixes for #-1 as well as
>other bugfixes and upload it, either via t-p-u during the hard freeze
>or later via s-p-u.  In upstream's own words “[the minor release]
>will take few week because of translation loop etc.”  The downside
>being of course more review work for the release team, as the diff is
>already rather large:
>
> https://gitlab.com/cryptsetup/cryptsetup/-/compare/v2.6.1...main?from_project_id=195655=false

Waiting is definitely not needed from my point of view.

>  * Backport upstream MR !498, let it mature in sid for a few
>weeks then upload 2:2.6.1-4~deb12u1 via t-p-u.  There are only 2
>upstream commits to cherry-pick and neither is large nor intrusive;
>moreover like the commits previously cherry-picked they are no-op on
>“normal” systems (only systems without swap are affected).  For
>convenience I attach a debdiff for 2:2.6.1-3~deb12u2 and you'll also
>find binary packages for amd64 at
>https://people.debian.org/~guilhem/tmp/cryptsetup_2.6.1-3~deb12u2/
>Tested: autopkgtests (incl. full upstream test suite), d-i in both
>graphical and text install on VMs with 1024M RAM (now memory cost
>won't exceed ~250M resp. ~300M thus leaving plenty of headroom for
>the rest).

Since you're happy with that approach, let's go for an upload to
unstable for the time being, I'll conduct some tests shortly, and once
it's indeed confirmed to work fine, go via t-p-u (because of the same
fun as before with some library) so that it can be used for rc3 (if it's
ready by then — we haven't really defined when it's going to happen
besides “somewhen before end of April”).


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


signature.asc
Description: PGP signature

Bug#1001084: ITP: meli -- terminal mail client

[Jonas Smedegaard]

0.7.2+20230410 draft 1 needs embedding 8 crates (6 missing, 1 unwanted, 1 
ahead);
runs and seems to work from a brief test use.

Main tasks are still to keep package up-to-date with upstream releases, and
to package more of the crates currently embedded.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary packages I built - then I will share those.

As developer (but no need to be official member of Debian!), you can
join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/meli/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#992119: virt-install --cloud-init doesn't work with Debian genericcloud images

[Reto Schneider]

On Wed, 11 Aug 2021 20:13:29 -0400 David Mandelberg 
 wrote:
Would it make sense to change virt-install to use virtio for the ISO 
file? (Or some other way of providing the ISO that genericcloud has 
drivers for?)
A possible workaround is passing "--machine pc" to virt-install. This 
causes the old(er) i440FX instead of Q35 (current default) to be used.


The following would provide a solution, but seems to be out of scope for 
the cloud kernel: 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/699

Bug#1034610: grub-common no longer supports labels

[Steve McIntyre]

Control: severity -1 important

Hi!

On Wed, Apr 19, 2023 at 02:52:31PM -0300, Dario Susman wrote:
>Package: grub-common
>Version: 2.06-8
>Severity: critical
>Justification: breaks the whole system
>
>Dear Maintainer,
>
>After upgrading to latest version of grub-common and kernel, the system
>wouldn't boot up with the latest kernel. The device paths changed, sda1
>to sdb1. I noticed that the grub config changed to use UUIDs, however
>/etc/default/grub is set to use LABELS. Which is something I prefer to
>do.
>
>It seems that grub-mkinfo no longer supports the GRUB_ENABLE_LINUX_LABEL
>parameters and has to be re-written for it to work.

Looking in the history, I can't see where we've ever supported
this. Can you tell me which version(s) ever had this working for you
please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#1034631: lintian: Warn for 32bit time_t / Y2038 problems

[Russ Allbery]

Uwe Kleine-König  writes:

> to help making package maintainers aware of the Y2038 problem I
> implemented a lintian check that triggers if a symbol from glibc is used
> that uses a 32bit time_t type.

> The code is available in a MR on the lintian packaging repository at
> https://salsa.debian.org/lintian/lintian/-/merge_requests/463

I have no objections to adding this as an experimental tag.  The detection
component to determine the size of the problem is certainly useful.

However, more generally, do we know yet how Debian intends to handle this
transition?  Changing to 64-bit time_t will change the ABI of shared
libraries and thus is not a safe change to make without an SONAME
transition unless we're going to do something architecture-wide, such as
introducing a new version of the i386 architecture where everything is
built with 64-bit time_t.

I know there's a caution in there already about this, but I'm concerned
about maintainers acting on this tag by blindly adding the Autoconf flags
or macros to switch to 64-bit time_t and thus creating numerous
uncoordinated shared library transitions, possibly without knowing they
need to change the SONAME.  And it's not clear to me that we want to do
the migration by changing the SONAME of every shared library in Debian
that uses time_t has part of its public API (which is a lot of them).

I know of at least one package (and I am certain that there will be more)
where this change will also change on-disk data formats in a way that is
not backward-compatible, which is even less safe.

The current caution should probably be stronger: it's only safe to do this
transition for leaf packages that do not call any shared library functions
with time_t parameters and that do not use time_t in any binary data
structures stored on disk (possibly including caches, depending on the
situation).  In other situations, this is something that's going to
require some distribution-wide coordination that I don't think we've
started yet.

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

Bug#1034642: naev: Crash after landing on a planet in the Qex system

[Nils Dagsson Moskopp]

Package: naev
Version: 0.8.0-1
Severity: important
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

when doing the tutorial the player has to visit the Qex system,
but upon landing on a planet and taking off, the game crashes …

The output of naev in a terminal is reproduced below this line:

 Naev v0.8.0+dev (linux-x86_64)
Found ndata: /usr/share/naev/dat
 Sea of Darkness
Reached main menu
Warning: [font_makeChar] Unicode character '0xfff7eefc' not found in font! 
Using missing glyph.
Entity: line 491: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xBB 0x9C 0x62 0x75
  Kapilän Z. ��bung, der Melendez-Mitarbeiter, d
 ^
Entity: line 491: parser error : PCDATA invalid Char value 24
ab dir eine Anleitung, wie man es steuert, und behauptete anschli]��end, dass du
   ^
error : xmlTextWriterWriteDocCallback : XML error 9 !
I/O error : flush error
ERROR ../src/save.c:134 [save_all]: xmlw: unable to end document
abort

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

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

Versions of packages naev depends on:
ii  libc62.31-13+deb11u5
ii  libcxsparse3 1:5.8.1+dfsg-2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenal1   1:1.19.1-2
ii  libpng16-16  1.6.37-3
ii  libsdl2-2.0-02.0.14+dfsg2-3+deb11u1
ii  libsdl2-mixer-2.0-0  2.0.4+dfsg1-3
ii  libvorbis0a  1.3.7-1
ii  libvorbisfile3   1.3.7-1
ii  libxml2  2.9.10+dfsg-6.7+deb11u3
ii  naev-data0.8.0-1

naev recommends no packages.

naev suggests no packages.

-- no debconf information

Bug#1034196: unblock: openrefine/3.6.2-2

[Markus Koschany]

Hi Paul,

Am Donnerstag, dem 20.04.2023 um 18:07 +0200 schrieb Paul Gevers:
> [...]
> > Since I already followed the Debian Policy and included the missing sources
> > in
> > debian/missing-sources, I felt that shipping the 3rdparty directory in
> > debian/missing-sources/3rdparty would be a good intermediate solution.
> 
> But you added a more files than you have in testing (including jquery.js).

Yes, because 3.6.1 was the first version after 3.5.2 that removed those
3rdparty Javascript files. I noticed it after I had uploaded the package. I
corrected this problem in 3.6.2-1.

> > If you
> > insist I can repack the tarball, add the 3rdparty directory and remove it
> > from
> > debian/missing-sources but in the end it would not make any difference.
> 
> Huh? I wasn't asking you to do that. I was asking you to use packaged 
> binaries as a dependency.
> 
> > Openrefine is a desktop application which only runs on your own computer.
> 
> You know, now I know. Does the security team also know? Should they really?

I am a member of the security team. It is on my radar.

> 
> > If
> > you insist I can depend on libjs-jquery and replace the local copy with a
> > symlink but I feel this would be an example of over-engineering without any
> > real value to our users in this specific case.
> 
> That argument holds for a lot of things we do. What I try to say is that 
> there's a price we pay in our community too by not doing it. In this 
> case: tracking embedded versions. Because of the popularity of things 
> like jquery they are embedded a lot and we're trying to track them *and* 
> remove them. Just to clear, I wasn't *only* talking about jquery.js, but 
> also about the others that are covered by binaries in our archive. Even 
> if upstream added stuff back, I would still recommend you to link (and 
> depend on) the files shipped in e.g. libjs-jquery. I know what I talking 
> about, my upstream cacti ships a lot of embedded libraries too; I do my 
> best to remove things that we already ship in Debian. My upstream 
> complained once in a while that my versions are wrong; I still believe 
> it's the right thing to do in a distribution like Debian. I think they 
> are starting to see the value of our side too.
> 
> Lintian is telling you that too:
> https://udd.debian.org/lintian/?packages=openrefine

As I had explained in my previous reply, there is no security impact. Cacti is
a network application and can be accessed remotely by different parties.
Instead openrefine is a privacy focused standalone application. Keeping your
data on your own computer is a feature here. The security team would triage any
Javascript CVE for openrefine as either unimportant or minor because openrefine
is intended to be used for local and single person usage.

Code deduplication is also not a problem, JS files are often small. On the
other hand there is a huge downside for all those Javascript system libraries.
Even minor changes may break existing applications, APIs are not stable,
upstream is unable to help you if you diverge from their version. And then
there is another point which is often neglected in Debian discussions:
developer time. We waste too much time for over-optimizations and often neglect
user experience and maintainability aspects. 

It seems we treat every computer language and every package as it was C only
and try to use always the same hammer because everything looks like a nail. I
believe it is important to differentiate from time to time. 

Regards,

Markus



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

Bug#1034641: exiv2: Pick upstream patch for regression on Olympus Maker notes

[Fab Stz]

Package: exiv2
Version: 0.27.6-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

Would you please pick a patch from upstream that fixes a regression in 0.27.6?
This regression leads to loss of corruption of Olympus Makernotes.

You can find all the details in the issue at
https://github.com/Exiv2/exiv2/issues/2542

Upstream's patch is linked from
https://github.com/Exiv2/exiv2/issues/2542#issuecomment-1493926009


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991,
'stable'), (95, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages exiv2 depends on:
ii  libc62.31-13+deb11u5
ii  libexiv2-27  0.27.3-3+deb11u1
ii  libgcc-s110.2.1-6
ii  libstdc++6   10.2.1-6

exiv2 recommends no packages.

exiv2 suggests no packages.

Bug#1034640: unblock: spirv-llvm-translator-15/15.0.0-2

[Andreas Beckmann]

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

Looks like I forgot to merge the -fvisibility=hidden changes from
src:spirv-llvm-translator-14 (and the corresponding removal of 4500+
useless C++ symbols from the .symbols file) into
src:spirv-llvm-translator-15. Just noticed while preparing -16 for
experimental.

unblock spirv-llvm-translator-15/15.0.0-2

Andreas


spirv-llvm-translator-15_15.0.0-2.diff.xz
Description: application/xz

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

[Andreas Metzler]

On 2023-04-20 Paul Gevers  wrote:
> Hi Andreas,

> On Fri, 31 Mar 2023 15:06:14 +0200 Andreas Metzler  wrote:
> > I think 2.5.7-2 was the last sourceful < 3 upload, so (<< 2.5.7-3)
> > should work.

> And to be backports and other local packages, I think that could/should be
> (<< 2.5.7-3~).

> Can a/this fix be uploaded soon please? We're trying to pick a bookworm
> release date and a fix should be in.

Hello Paul,

I will not have time for a NMU before next week, I can probably fit it
in then.

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

Bug#1034429: coreutils: install: -s runs ["strip", $f] instead of ["strip", "--", $f]; should use strip from $STRIP

[Pádraig Brady]

On 15/04/2023 15:47, наб wrote:

On Sat, Apr 15, 2023 at 02:04:18PM +0100, Pádraig Brady wrote:

But perhaps the strip program doesn't handle the convention
that -- indicates end of option processing?

Inasmuch as "perhaps strip doesn't use getopt(3)" /and/
 "perhaps strip doesn't conform to the XCU"
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/strip.html;
  note no changes since Issue 2, which means this has been a requirement
  realistically since 1989
  (it's in my copy of XSI Issue 3, saying it's equivalent to Issue 2,
   but it's only Volume 1, and it's unclear to me if the XBD USG
   was fully developed; Issue 2 hasn't been archived),
  and definitely since SUSv1, whose Guideline 10 and Utility Description
  Defaults, OPTIONS, Default Behaviour are both as present-day)
can both hold at the same time, I guess?
You can probably tell I'm quite sceptical any such strip exists.


I was thinking of the more general case where the strip program
may be a shell wrapper or something that doesn't handle -- appropriately.
The main point is that we should fix this issue in any case.


It would also be nice for $STRIP to provide a default if -S isn't set;
the usefulness of install -s is doubtful if
install -s binary $DESTDIR/bin
only works if binary happens to match the host arch.

Yes it's a fair point that calling strip without options is quite restrictive.
Though I suppose --strip-program can point to a script that calls strip 
appropriately.

My target usecase is for third-party programs running install -s,
which, without modification, cannot be made to work if strip is binutils
strip and the binary is non-native.


Well one could adjust the $PATH so an appropriate strip wrapper is found.

cheers,
Pádraig

Bug#996464: ITP: atomic-data-rust -- graph database server to share Atomic Data on the web

[Jonas Smedegaard]

0.34.2 draft 2 needs embedding 66 crates (64 missing, 1 outdated, 1 ahead); 
runs but needs to point to external web assets until those are packaged

Main tasks are still packaging companion npm project Atomic Data Browser,
and continue packaging remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary that I've built - then I will share that.

As developer (but no need to be official member of Debian!), you can
join the Debian Rust team and help package these missing crates: 
https://salsa.debian.org/debian/atomic-data-rust/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1034347: spamd timeout after reboot: dns: bad dns reply: bgread: recv() failed

[Noah Meyerhans]

On Wed, Apr 19, 2023 at 07:50:32AM +0800, Martin Michlmayr wrote:
> * Martin Michlmayr  [2023-04-13 18:23]:
> > A Google search has led to:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1985587
> > The proposed patch seems relevant to Debian's spamd service file too:
> > https://src.fedoraproject.org/rpms/spamassassin/pull-request/12#request_diff
> 
> I've now tested this change to the systemd file and it makes it work
> as expected.
> 
> Can you please add this fix as an update to bookworm.

Requested an unblock for bookworm at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034639

Bug#1008656: linux-image-5.10.0-13-cloud-amd64: Consider AHCI SATA support in cloud kernels

[Bastian Blank]

Control: tags -1 wontfix

On Wed, Mar 30, 2022 at 08:17:51AM +, Thomas Wouters wrote:
> So I tried to reproduce it with `virt-install` to figure out what's 
> going on and could replicate similar behavior: the cloud-init user-data 
> is, by default (for x86), provided to the guest as a SATA connected 
> CDROM drive and the kernel is unable to detect it because it's missing 
> AHCI support.

No, it is not.  The default is to use cdrom via virtio-blk or
virtio-scsi.

> I think it would make sense to include AHCI support in the kernel cloud 
> image since it should fix cloud-init support in the "genericcloud" 
> images built by the cloud team.

No, this is out of scope as defined in the description of the package.

Bastian

-- 
Well, Jim, I'm not much of an actor either.

Bug#1034639: unblock: spamassassin/4.0.0-5

[Noah Meyerhans]

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

Please unblock package spamassassin

This is a targeted change that addresses #1034347, in which spamd can
sometimes be started with incorrect DNS server configuration.  This happens
because spamd startup happened too early in the boot process, and services
responsible for populating resolv.conf had not necessarily run yet.  The
solution was to order spamd.service After=network-online.target, as shown in
the attached debdiff.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034347

[ Reason ]
Spamd needs a valid DNS configuration for complete operation.

[ Impact ]
Without working DNS, spamd is unable to make use of many of its core mail
validation services, which diminishes its usefulness.

[ Tests ]
Manual validation by myself and the bug submitter.

[ Risks ]
It's a trivial change to the boot order and should not impact anything that
depends on spamd.

[ 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 spamassassin/4.0.0-5
diff -Nru spamassassin-4.0.0/debian/changelog 
spamassassin-4.0.0/debian/changelog
--- spamassassin-4.0.0/debian/changelog 2023-01-06 13:05:09.0 -0800
+++ spamassassin-4.0.0/debian/changelog 2023-04-16 13:28:05.0 -0700
@@ -1,3 +1,9 @@
+spamassassin (4.0.0-5) unstable; urgency=medium
+
+  * Update spamd.service to order after network-online.target (Closes: 
#1034347)
+
+ -- Noah Meyerhans   Sun, 16 Apr 2023 13:28:05 -0700
+
 spamassassin (4.0.0-4) unstable; urgency=medium
 
   * Revert "drop unused params from Makefile.PL"
diff -Nru spamassassin-4.0.0/debian/spamd.service 
spamassassin-4.0.0/debian/spamd.service
--- spamassassin-4.0.0/debian/spamd.service 2023-01-06 12:32:43.0 
-0800
+++ spamassassin-4.0.0/debian/spamd.service 2023-04-16 13:04:49.0 
-0700
@@ -1,6 +1,6 @@
 [Unit]
 Description=Perl-based spam filter using text analysis
-After=network.target
+After=syslog.target network-online.target
 
 [Service]
 Type=simple

Bug#1034196: unblock: openrefine/3.6.2-2

[Paul Gevers]

Hi Markus,

On 20-04-2023 15:21, Markus Koschany wrote:

In version 3.5.x upstream included all Javascript files in the original source
tarball but also shipped some minified files without the unminified sources.


[...]

This was a missing piece. At least it explains how you got where you are 
now.



Since I already followed the Debian Policy and included the missing sources in
debian/missing-sources, I felt that shipping the 3rdparty directory in
debian/missing-sources/3rdparty would be a good intermediate solution.


But you added a more files than you have in testing (including jquery.js).


If you
insist I can repack the tarball, add the 3rdparty directory and remove it from
debian/missing-sources but in the end it would not make any difference.


Huh? I wasn't asking you to do that. I was asking you to use packaged 
binaries as a dependency.



Openrefine is a desktop application which only runs on your own computer.


You know, now I know. Does the security team also know? Should they really?


If
you insist I can depend on libjs-jquery and replace the local copy with a
symlink but I feel this would be an example of over-engineering without any
real value to our users in this specific case.


That argument holds for a lot of things we do. What I try to say is that 
there's a price we pay in our community too by not doing it. In this 
case: tracking embedded versions. Because of the popularity of things 
like jquery they are embedded a lot and we're trying to track them *and* 
remove them. Just to clear, I wasn't *only* talking about jquery.js, but 
also about the others that are covered by binaries in our archive. Even 
if upstream added stuff back, I would still recommend you to link (and 
depend on) the files shipped in e.g. libjs-jquery. I know what I talking 
about, my upstream cacti ships a lot of embedded libraries too; I do my 
best to remove things that we already ship in Debian. My upstream 
complained once in a while that my versions are wrong; I still believe 
it's the right thing to do in a distribution like Debian. I think they 
are starting to see the value of our side too.


Lintian is telling you that too:
https://udd.debian.org/lintian/?packages=openrefine

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033591: Tested opendmarc 1.4.2 from bullseye-updates with success

[Florian Sager]

I saw about 10 restarts per hour of opendmarc, 
1.4.0~beta1+dfsg-6+deb11u1 with log messages like


>>>
systemd[1]: opendmarc.service: Main process exited, code=killed, 
status=6/ABRT

systemd[1]: opendmarc.service: Failed with result 'signal'.
systemd[1]: opendmarc.service: Scheduled restart job, restart counter is 
at 9488.

systemd[1]: Stopped OpenDMARC Milter.
systemd[1]: Starting OpenDMARC Milter...
systemd[1]: opendmarc.service: Can't open PID file 
/run/opendmarc/opendmarc.pid (yet?) after start: Operation not permitted

opendmarc[3752463]: OpenDMARC Filter v1.4.0 starting ()
opendmarc[3752463]: additional trusted authentication services: (none)
systemd[1]: Started OpenDMARC Milter.
<<<

and today I could relate some of these crashes to repeated attempts of 
an external mailserver to send a message that contained the following 
ARC headers:


>>>
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 
b=KlmBz61o8BGN/yiWJrnTFF9lMYpIOQDW8JYggaml8CKULIleMnaBp8B+wEn0zmbCQJIqgo63vf6bJMzQLx0NYdGgs7bsTMiZyrIqs+MLIcOCiJiPRWYGndZ67bf33RT1R21Sdb4xFjHiBKfCI07d8Igq48c2E9CL/dIBs7zEvDb23XWF0PTkcEwVTP0QpyzVq+TWYLgbiM8mgG2irndVfRLG0OjtWHG9cvNYUMGryLpTnJYRkKvV2pl/SpiRqsqr8ngZSxISTIMiIodwTy1+YJEF4L6JeYMfUMaHldk1RHXDVJBIFLrTwMEsCTgAjwFJNqTWQPRQqQRPNdhcOe0Smg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 
d=microsoft.com;

 s=arcselector9901;
 
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4CZNmpHP3LoqXtV4ng6ME/2WWZ/8yvNenpaB+SW3eP4=;
 
b=hsFxbdEh+1sjXjaxdsA3yC8S0SeMHp4z5wYPLUXu2PmNl7AsGe0ZsZb7MJi+22KIJf9M57PmciUnw8qoJdJZ+NERsivTM+F98Yr6yhMXPzOI8LshGWFvZpJYqwrlJiT8752FAZ4JNWAd9JEdxaDLbLE7U0hG5Ln++eS8QPDftJBW2cQi1FgK5Qu4x6HIK4Z1yWKYiBSEJnymdbRFKoT3TUcnGvWvEmAYfOtJKTe7XmuST43Dmc3uZgG3AMjaxdHADKl55tXUrKIjw1QIOoPTpdbK5A/VCs+oxfFBlvThkdyNC6SAiCRO+jhYvKmpCUssdOAb6xYCt2E5eXotY/9kSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 116.202.101.96) smtp.rcpttodomain=gedk.de smtp.mailfrom=out.agitos.de;
 dmarc=none action=none header.from=gedk.de; dkim=none (message not 
signed);

 arc=none (0)
<<<


I cloned 
https://salsa.debian.org/kitterman/opendmarc/-/tree/glts/bullseye-updates?ref_type=heads 
and compiled the patched opendmarc 1.4.2 to test if the crashes can be 
reduced on Debian bullseye:


Just in case someone else likes to do the same in the directory with 
cloned source code:


>>>
apt install make dh-autoreconf quilt libmilter-dev
export QUILT_PATCHES=debian/patches
quilt push -a
autoreconf -v -i
./Autobuild.sh
make install
<<<

As the installed result links to libopendmarc.so.2
>>>
# ldd /usr/local/sbin/opendmarc
    linux-vdso.so.1 (0x7ffc25be9000)
    libopendmarc.so.2 => /usr/lib/x86_64-linux-gnu/libopendmarc.so.2 
(0x7f25cc931000)

<<<
... I adapted the library link accordingly:
>>>
/usr/lib/x86_64-linux-gnu# ls -la lib*dmarc*
lrwxrwxrwx 1 root root 21  20. Apr 16:40  libopendmarc.so.2 -> 
libopendmarc.so.2.0.3

-rw-r--r-- 1 root root  55424  3. Nov 2021  libopendmarc.so.2.0.2
-rwxr-xr-x 1 root root 278992 20. Apr 16:40 libopendmarc.so.2.0.3
<<<

While the old opendmarc process found the config file 
/etc/opendmarc.conf without a cmdline option I needed to change in the 
systemd unit file:

>>>
# v1.4.0: ExecStart=/usr/sbin/opendmarc, needed to be changed for v1.4.2:
ExecStart=/usr/local/sbin/opendmarc -c /etc/opendmarc.conf
<<<

With this patched process the email with the ARC headers (see above) 
could be received.
Furthermore I don't see any opendmarc crashes so far in the logfiles 
(checked for 30 minutes).


Best regards
Florian Sager

Bug#1034638: wmaker: comments in appearance.menu not allowed

[Helge Kreutzmann]

Package: wmaker
Version: 0.95.9-3+b2
Severity: minor

Yesterday I got the following error messaage:
2023-04-19T20:00:02.520024+02:00 twentytwo 
/usr/libexec/WindowMaker/wmaker[2864]: (getPropList(proplist.c:885)): warnung: 
Syntaxfehler in file /usr/share/WindowMaker/appearance.menu, Zeile 1: 
Zeichenkette, Binärdaten, Array oder Dictionary erwartet. Zeichenketten ggf. 
mit " einklammern.
2023-04-19T20:00:02.521878+02:00 twentytwo 
/usr/libexec/WindowMaker/wmaker[2864]: (getPropList(proplist.c:888)): warnung: 
Kommentare sind in Domänendaten von WindowMaker nicht erlaubt.

In english:
Warning: Syntaxerror in  file /usr/share/WindowMaker/appearance.menu line 1: 
String, binary data, array or dictionary expected. Escape strings possibly by "
Warning: Comments are not allowed within domain names from window maker.


# head /usr/share/WindowMaker/appearance.menu
#include "wmmacros"

Appearance MENU
  "Background" OPEN_MENU background.menu
  …



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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wmaker depends on:
ii  libc6   2.36-9
ii  libexif12   0.6.24-1+b1
ii  libfontconfig1  2.14.1-4
ii  libwings3   0.95.9-3+b2
ii  libwraster6 0.95.9-3+b2
ii  libwutil5   0.95.9-3+b2
ii  libx11-62:1.8.4-2
ii  libxext62:1.3.4-1+b1
ii  libxinerama12:1.1.4-3
ii  libxpm4 1:3.5.12-1.1
ii  wmaker-common   0.95.9-3

wmaker recommends no packages.

Versions of packages wmaker suggests:
ii  desktop-base   12.0.5
ii  konsole [x-terminal-emulator]  4:22.12.3-1
pn  wmaker-data
pn  wmaker-utils   
ii  x11-apps   7.7+9
ii  xterm [x-terminal-emulator]379-1

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#931520: harden-doc: before-compromise section references testing/updates instead of testing-security

[Javier Fernandez-Sanguino]

Hi Vincent,

I can try to get this updated this weekend. If anyone wants to go ahead
with a fix you have my blessing.

Best regards,

Javier

El jue, 20 abr 2023, 12:15, Vincent Lefevre  escribió:

> On 2019-07-07 11:12:11 +0800, Paul Wise wrote:
> > The harden-doc before-compromise section references testing/updates but
> > with bullseye that suite has been renamed to testing-security. Please
> > update the harden-doc before-compromise section.
>
> Could this eventually be updated for bookworm?
> It is bad to give wrong information to users.
>
> BTW, the old testing/updates lines are still visible here:
>
> https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#security-support-testing
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>

Bug#1033811: closed by Graham Inggs (Re: Bug#1033811: unblock: mariadb/1:10.11.2-2)

[Otto Kekäläinen]

Hi!

Can you please list the commits you do not accept so I can revert them and
upload a 10.11.2-3 which you are then willing to approve?

I think it would be a huge miss if none of a month worth of bugfix work
would make into the release.

Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting

[karogyoker999]

Control: severity -1 minor

Bug#1008656: linux-image-5.10.0-13-cloud-amd64: Consider AHCI SATA support in cloud kernels

[Uwe Kleine-König]

Control: tags -1 + patch

There is a MR for this bug on https://deb.li/Xe0A

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#1034574: uscan: support OpenPGP signature verification without requiring a saved upstream signing key

[Uwe Kleine-König]

Hello,

On Tue, Apr 18, 2023 at 05:25:58PM +, John Scott wrote:
> I know if you're looking at the subject line alone you'll think I'm proposing 
> introducing a security vulnerability, but let me explain.
> 
> There are some problems with storing an upstream signing key inside the 
> package. It might get stale, not incorporating additional subkeys necessary 
> for signature verification or revocations. Also, it requires manual work on 
> the part of the maintainer and can't be done automatically.
> 
> Folks outside the OpenPGP ecosystem might not know this, but the Web of Trust 
> is now not the only way of doing things. There are ways, like Web Key 
> Directory, DANE, and LDAP, to not only discover an OpenPGP key, but also 
> verify that it really belongs to the person in the user ID.
> 
> First, we save in some metadata file somewhere (debian/upstream/metadata?) 
> the user IDs (aka names and email addresses) of upstream, or perhaps mappings 
> of key IDs to email addresses. When uscan goes to verify the signature, it 
> will know the key ID of the signer but might not know their user ID, so it 
> will look in the mapping table.
> 
> Then it will fetch the key using an authenticated method and use it to verify 
> the signature.
> 
> I hope that makes sense. Unfortunately I only know C, so I don't think I'll 
> be able to contribute this.

My personal objective opinion to that is: I prefer manual key handling
over such automatisms. To get the key belonging to a certain email
address the mentioned mechanisms like WKD and DANE are reasonably good.
But I want to authenticate a certain person, not someone in control of a
certain email address (which can change).

So if such a mechanism existed, I wouldn't opt-in to it and prefer to
continue occasionally updating the upstream key after manual
verification.

My 0.02€,
Uwe



-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting

[karogyoker999]

Control: tags -1 + unreproducible

The issue was due to faulty RAM. No further action required.

Bug#1034637: atril: cannot parse a pdf files which gv parses right

[Francesco Potortì]

Package: atril
Version: 1.26.0-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

Atril, Evince and Xpdf cannot parse the attached file: they show the page 
header and no text (the page is otherwise blank). However, gv displays it well, 
as does Overleaf.

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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 atril depends on:
ii  atril-common 1.26.0-2
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libatk1.0-0  2.46.0-4
ii  libatrildocument31.26.0-2
ii  libatrilview31.26.0-2
ii  libc62.36-6
ii  libcaja-extension1   1.26.1-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.2-1
ii  libgtk-3-0   3.24.35-3
ii  libice6  2:1.0.10-1
ii  libsecret-1-00.20.5-3
ii  libsm6   2:1.2.3-1
ii  libxml2  2.9.14+dfsg-1.1+b2
ii  shared-mime-info 2.2-1

Versions of packages atril recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.4-1
ii  dbus-x11 [dbus-session-bus]   1.14.4-1
ii  gvfs  1.50.2-2

Versions of packages atril suggests:
ii  caja  1.26.1-1
ii  poppler-data  0.4.11-1
ii  unrar 1:6.2.3-2

-- no debconf information


test.pdf
Description: Adobe PDF document

Bug#1034190: More security bugs in game loading

[Ben Hutchings]

On Thu, 2023-04-20 at 10:01 +0200, Paul Gevers wrote:
> Hi Ben,
> 
> On Mon, 10 Apr 2023 22:01:04 +0200 Ben Hutchings  
> wrote:
> > Package: sgt-puzzles
> > Severity: serious
> 
> The fix for this bug will not automatically migrate to testing because 
> the package doesn't have autopkgtests and we're in the freeze. The 
> changes are massive,

They're actually not that massive, but split into a lot of small
patches.

> so I'd like to confirm in an unblock bug that all 
> changes are indeed targeted fixes before unblocking. Can you file such 
> an unblock request if you don't want the package to be autoremoved (or 
> add a non-superficial autopkgtest if that makes sense)?

Yes, I will file an unblock request.

Ben.

-- 
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding
stump of a severed limb. - me, 29 June 1999


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

Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3

[Dmitry Baryshkov]

On Thu, 20 Apr 2023 at 11:28, Roger Shimizu  wrote:
>
> On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov
>  wrote:
> >
> > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu  wrote:
> > >
> > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov
> > >  wrote:
> > > >
> > > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu  wrote:
> > > > >
> > > > > > Hello Roger, FTP masters,
> > > > > > Short story: the uploaded 
> > > > > > linux-board-support-package-dragonboard845c package (currently in 
> > > > > > NEW) contains a file with unclear license background and as such it 
> > > > > > should not be allowed into the archive.
> > > > > > The orig.tar.gz file needs to be repackaged before uploading.
> > > > >
> > > > > I tried to repack the orig, and re-upload, but got REJECTED by:
> > > > >
> > > > > linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc:
> > > > > Does not match file already existing in the pool.
> > > >
> > > > Usually one would use suffix like -dfsg to mark the repacked package.
> > > > The -dfsg doesn't make sense in the case of a non-free package, so you
> > > > can probably use -repack.
> > >
> > > Yes, but upstream uses .zip archive anyhow.
> > > So we have to repack to .orig.tar.*
> >
> > To notify possible users that it's not just a repack of zip, but also
> >
> > >
> > > > More importantly I'm not sure that this package should be a part of
> > > > Debian at all.
> > >
> > > Why?
> > > Without bootloader part, we cannot support installer in Debian.
> >
> > This bootloader is already installed by the manufacturer. Please
> > consider these partitions as a firmware. One does not modify the
> > device firmware during Debian installation.
> >
> > Maybe I misunderstand something about the usecase you are facing.
> > Could you please describe it?
>
> RB3 is an open platform.
> You do not know what system user previously installed.

Yes, that's the point. It could have been customized by the user.

 I always hated some W operating system rewriting the MBR
unconditionally and really liked the way Debian asks user if this is a
desired theing.

> And even Linaro provided two different system, with different
> partition layouts, aosp and linux:
> - https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/

And usually they differ only in the partitioning scheme, in GPT data.
So. Repartitioning the UFS sounds correct to me. Reflashing the
bootloader doesn't sound good.

> I'm not sure why you suppose the bootloader has to be original.

I suppose that it's not a task of the DI to update the bootloader.

>
> Linaro's rescue image also rewrite those partitions.
> I think Debian should do the same.
>
> > My current understanding:
> > - The device comes from the factory with the bootloaders flashed
> > - DI repartitions one of UFS LUNs to replace vendor+system+userdata
> > with the rootfs/home/etc
> > - DI installs all the packages to the target rootfs, including the
> > package with custom kernel hooks
> > - the kernel hooks write the generated android boot img to the boot 
> > partition
> >
> > Is there anything else?
>
> Anyway, this is not for this ITP ticket. We can discuss when porting
> to installer.

Sure. Please ping either me directly or the linux-arm-msm mailing list
when you'd like to discuss it. Getting DI to work on these boards
would be a very welcomed and appreciated both by our group and by the
overall community.

>
> > > > I doubt that DI should touch these partitions. Firstly, because of the
> > > > reasons I expressed in my previous email (risk of bricking the board,
> > > > custom bootloaders being used on these devboards, etc).
> > > > Secondly, I'd like to point out that RB3/RB5 (and other dragonboards)
> > > > are in a pretty unique position. Other development boards (QRD, HDK,
> > > > Open-Q, etc.) do not have public redistributable bootloader archives.
> > >
> > > No worries about the brick issue.
> >
> > Actually, no. Bricking the device during installer is a very bad thing.
>
> I said no worries, because we need to fix those issue when porting to 
> installer.
> This is ITP ticket, and we need to be focus on packaging firmware first.

I checked other bootloaders (lilo, syslinux, grub, etc). All of them
push data to /usr/lib/something. I think this approach should be
adopted by your packages.

>
> Cheers,
> Roger
>
> > > We should consider this before releasing it to installer.
> > > Currently, we just take the 1st step to get everything necessary to
> > > hit the debian archive.
> >
> > Ok, it's up to you, once the archive is free of the Renesas firmware,
> > but I'd not consider it 'necessary'.  The user has to perfectly know
> > what he is flushing and why. I'd strongly advice to point to the
> > rescue packages or to the Thundercomm SDK manager instead of packaging
> > everything into the installer.
> >
> > --
> > With best wishes
> > Dmitry



-- 
With best wishes
Dmitry

Bug#1033291: autopkgtest-virt-qemu: support booting images created using debvm-create

[Jochen Sprickerhof]

Hi Helmut,

thanks for implementing this!

* Helmut Grohne  [2023-03-21 19:58]:

We include python3 here, because autopkgtest-virt-qemu says so. We also
include a generic kernel image, because debvm prefers a cloud image,
which lacks support for the 9p filesystem used by autopkgtest-virt-qemu
(see #1027174). Then we must enable the additional serial gettys. While
systemd has a getty generator, this generator cannot enable the consoles
that autopkgtest-virt-qemu needs. autopkgtest-virt-qemu really wants
boot messages one ttyS0 (or hvc0), so this is what we must pass as
console= boot parameter.

[..]

@@ -435,6 +488,18 @@
argv.append(
'if=pflash,format=raw,unit=1,file=%s/efivars.fd' % workdir
)
+elif boot == 'vmlinux':
+ext2_extract_boot_components(
+self.images[0].file, workdir + "/kernel", workdir + "/initrd"
+)
+label = subprocess.check_output(
+["/sbin/e2label", self.images[0].file], encoding="utf-8"
+).strip()
+argv.extend([
+"-kernel", workdir + "/kernel",
+"-initrd", workdir + "/initrd",
+"-append", "root=LABEL=%s rw console=ttyS0" % label,
+])
else:
adtlog.debug(
'Assuming nothing special needs to be done to set up '


Adding console=ttyS0 unconditionally seems to break arm64:

autopkgtest-virt-qemu --show-boot --qemu-architecture aarch64 
autopkgtest_arm64.ext4

In debvm-run we add it for amd64|i386 only:

https://sources.debian.org/src/debvm/0.2.10/bin/debvm-run/#L356

Attached is a patch to do the same here.

Cheers Jochen
diff --git a/lib/autopkgtest_qemu.py b/lib/autopkgtest_qemu.py
index cdb34ec..201313b 100644
--- a/lib/autopkgtest_qemu.py
+++ b/lib/autopkgtest_qemu.py
@@ -495,10 +495,13 @@ class Qemu:
 label = subprocess.check_output(
 ["/sbin/e2label", self.images[0].file], encoding="utf-8"
 ).strip()
+console = ""
+if self.qemu_architecture in ('i386', 'x86_64'):
+console = " console=ttyS0"
 argv.extend([
 "-kernel", workdir + "/kernel",
 "-initrd", workdir + "/initrd",
-"-append", "root=LABEL=%s rw console=ttyS0" % label,
+"-append", "root=LABEL=%s rw%s" % (label, console),
 ])
 else:
 adtlog.debug(


signature.asc
Description: PGP signature

Bug#1034196: unblock: openrefine/3.6.2-2

[Markus Koschany]

Hello,

Am Donnerstag, dem 20.04.2023 um 11:57 +0200 schrieb Paul Gevers:
> Control: tags -1 moreinfo
> 
> Hi,
> 
> On Mon, 10 Apr 2023 23:55:44 +0200 Markus Koschany  wrote:
> > This unblock is related to #1034127 and the unblock of rhino.
> 
> rhino is now unblocked.

Thank you.

> 
> > The main reason for
> > upgrading from 3.6.1 to 3.6.2 was to include missing Javascript files
> > which are needed to run the web / desktop application of openrefine.
> 
> I *think* you are abusing missing-sources. Quoting policy [1]:
> """
> Sometimes upstream does not include the source code for some files in 
> the upstream tarball. In order to satisfy the DFSG for packages in main 
> or contrib, you should either:
> 
>  repack the upstream tarball to include those sources; or
> 
>  include a copy of the sources in the debian/missing-sources directory.
> """
> But you are *installing* those missing sources.

In version 3.5.x upstream included all Javascript files in the original source
tarball but also shipped some minified files without the unminified sources. I
kindly asked them to change that. They then decided to remove third party
Javascript files completely and download them separately with npm while
building their own version of openrefine. I didn't have the chance to discuss
this change with them yet and how they want to distribute those third party
Javascript files in the future.

Since I already followed the Debian Policy and included the missing sources in
debian/missing-sources, I felt that shipping the 3rdparty directory in
debian/missing-sources/3rdparty would be a good intermediate solution. If you
insist I can repack the tarball, add the 3rdparty directory and remove it from
debian/missing-sources but in the end it would not make any difference. The
debdiff and the functionality would be the same. I feel such a change could be
postponed for the next release cycle when I know upstream's thoughts. 


>  On top of that, you are 
> shipping yet another copy of e.g. jquery.js [2]. Please, if remotely 
> possible, use bin:libjs-jquery (and similar for the other dependencies) 
> instead.

Openrefine is a desktop application which only runs on your own computer.
Openrefine is not affected by any possible security vulnerabilities in jquery
or any other Javascript library hence why it is more beneficial to use a local
copy that is closely integrated and tested with Openrefine. The risk of
breaking the application whenever the system library changes is much higher. If
you insist I can depend on libjs-jquery and replace the local copy with a
symlink but I feel this would be an example of over-engineering without any
real value to our users in this specific case. 

Regards,

Markus


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

Bug#1026060: mpv: dvb playback does not work anymore

[James Addison]

Source: mpv
Followup-For: Bug #1026060
X-Debbugs-Cc: s...@debian.org

Thanks, Nicholas!

Although I don't have a DVB device to test with locally, the fix makes sense
to me, and I'm glad to read from Alf's report that it is working.

Regards,
James

Bug#1028250: debian-installer: broken cryptsetup support

[Guilhem Moulin]

Hi kibi,

On Sat, 01 Apr 2023 at 01:34:54 +0200, Guilhem Moulin wrote:
> Ah right, reopened the upstream issue but forgot to follow-up here :-(
> https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1328592911

AFAICT the issue is now fully fixed upstream: on systems without swap
the memory cost won't exceed half the amount of free memory during PBKDF
benchmarking.  I can think of the following next steps (list probably
not exhaustive):

 * Don't do anything: ship 2:2.6.1-3~deb12u1 in bookworm and leave the
   DI errata in place.  The downside is that the PBKDF needs roughly
   half of the physical memory, so the OOM killer might trigger if the
   rest of the system uses close to the other half.  Moreover this not
   future proof, as memory requirement increases along releases.  (That
   said the issue has been present since 2 releases and there is nothing
   we can do about existing volumes.  Concretely, that means low-memory
   Bookworm rescue systems will likely OOM when trying to luksOpen an
   existing LUKS2 volume in graphical mode.)

 * Wait for upstream to release 2.6.2 with fixes for #-1 as well as
   other bugfixes and upload it, either via t-p-u during the hard freeze
   or later via s-p-u.  In upstream's own words “[the minor release]
   will take few week because of translation loop etc.”  The downside
   being of course more review work for the release team, as the diff is
   already rather large:
   
https://gitlab.com/cryptsetup/cryptsetup/-/compare/v2.6.1...main?from_project_id=195655=false

 * Backport upstream MR !498, let it mature in sid for a few
   weeks then upload 2:2.6.1-4~deb12u1 via t-p-u.  There are only 2
   upstream commits to cherry-pick and neither is large nor intrusive;
   moreover like the commits previously cherry-picked they are no-op on
   “normal” systems (only systems without swap are affected).  For
   convenience I attach a debdiff for 2:2.6.1-3~deb12u2 and you'll also
   find binary packages for amd64 at
   https://people.debian.org/~guilhem/tmp/cryptsetup_2.6.1-3~deb12u2/
   Tested: autopkgtests (incl. full upstream test suite), d-i in both
   graphical and text install on VMs with 1024M RAM (now memory cost
   won't exceed ~250M resp. ~300M thus leaving plenty of headroom for
   the rest).

Your call :-)
-- 
Guilhem.
diffstat for cryptsetup-2.6.1 cryptsetup-2.6.1

 changelog   |8 
+
 patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch |   74 
++
 patches/Use-only-half-of-detected-free-memory-on-systems-without-.patch |   43 
+
 patches/series  |2 
 4 files changed, 127 insertions(+)

diff -Nru cryptsetup-2.6.1/debian/changelog cryptsetup-2.6.1/debian/changelog
--- cryptsetup-2.6.1/debian/changelog   2023-03-26 19:18:59.0 +0200
+++ cryptsetup-2.6.1/debian/changelog   2023-04-20 13:19:06.0 +0200
@@ -1,3 +1,11 @@
+cryptsetup (2:2.6.1-3~deb12u2) UNRELEASED; urgency=medium
+
+  * Backport upstream MR !498, see #1028250:
++ 7893c33d: Check for physical memory available also in PBKDF benchmark.
++ 6721d3a8: Use only half of detected free memory on systems without swap.
+
+ -- Guilhem Moulin   Thu, 20 Apr 2023 13:19:06 +0200
+
 cryptsetup (2:2.6.1-3~deb12u1) bookworm; urgency=medium
 
   * Rebuild for Bookworm.
diff -Nru 
cryptsetup-2.6.1/debian/patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch
 
cryptsetup-2.6.1/debian/patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch
--- 
cryptsetup-2.6.1/debian/patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch
 1970-01-01 01:00:00.0 +0100
+++ 
cryptsetup-2.6.1/debian/patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch
 2023-04-20 13:19:06.0 +0200
@@ -0,0 +1,74 @@
+From: Milan Broz 
+Date: Mon, 3 Apr 2023 13:31:16 +0200
+Subject: Check for physical memory available also in PBKDF benchmark.
+
+Origin: 
https://gitlab.com/cryptsetup/cryptsetup/-/commit/7893c33d71cde09e240234c484c6c468f22c2fe7
+Bug: https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1328592911
+Bug-Debian: https://bugs.debian.org/1028250
+---
+ lib/internal.h| 1 +
+ lib/utils_benchmark.c | 9 +
+ lib/utils_pbkdf.c | 4 ++--
+ 3 files changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/lib/internal.h b/lib/internal.h
+index 98095fa..f261cae 100644
+--- a/lib/internal.h
 b/lib/internal.h
+@@ -89,6 +89,7 @@ int crypt_benchmark_pbkdf_internal(struct crypt_device *cd,
+  struct crypt_pbkdf_type *pbkdf,
+  size_t volume_key_size);
+ const char *crypt_get_cipher_spec(struct crypt_device *cd);
++uint32_t pbkdf_adjusted_phys_memory_kb(void);
+ 
+ /* Device backend */
+ struct device;
+diff --git a/lib/utils_benchmark.c b/lib/utils_benchmark.c
+index 728e4df..a0326ce 100644
+--- 

Bug#1032875: Small setback

[Christian Ehrhardt]

Hi,
I'm not entirely convinced on how up to date and frequently maintained
the new repository is.
I've found that it breaks on just checkout + make.

This wasn't unknown, but PRs to fix it were open for quite some time
without action
- https://github.com/scottchiefbaker/dool/pull/28
- https://github.com/scottchiefbaker/dool/pull/30
It IMHO also need:
- https://github.com/scottchiefbaker/dool/pull/37
on top.

But the point is, if PRs and issues are not handled we will only get a
singular update and not an active replacement for dstat.

I'll be waiting to see if there is a response to the open PRs.

-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#1031215: gradience

[matthias . geiger1024]

19. Apr. 2023, 23:39 von lorenzobertin...@gmail.com:

>
>   IRC well :)). I wanted to ask you what is the preferred way to get in
>  contact with the gnome packaging group?
>
>
>  Sorry, I meant the IRC channel dedicated to debian gnome packaging.

np :) you  can join #debian-gnome on the OFTC IRC network or send an email to 
debian-gtk-gn...@lists.debian.org. I can recommend reading 
https://wiki.debian.org/Gnome/Git and familiarizing myself with the teams' 
workflow.

I checked and I looks like these two python libraries would need packaging from 
scratch beforehand:

Anyascii:

https://github.com/anyascii/anyascii#python
material-color-theme:

https://github.com/avanisubbiah/material-color-utilities-pythonor 
https://pypi.org/project/material-color-utilities-python/

So you can file an ITP or an RFP for both. If you have any questions feel free 
to reply here (or send me a mail privately).

Hope this helps,

---
Matthias Geiger (werdahias)

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#275623: sync root's .bashrc and .profile with bash's skeletons

[Askar Safin]

Yes, current situation breaks bash-completion. Moreover, it breaks
bash-completion in standard debian images for docker. Because in this
images you enter the container as root via non-login shell. So,
bash-completion in docker simply doesn't work.

So, please, copy /etc/skel/.bashrc to /root/.bashrc . I can write a
patch, if you want.

-- 
Askar Safin

Bug#1034562: installation-reports: "Works", graphical corruption & flashing once in Gnome

[Adam Baxter]

On Wed, 19 Apr 2023, at 05:58, Roland Clobus wrote:
> Hello Adam,
>
> I've seen some issues on openQA which run on AMD hardware, but I 
> personally only have Intel processors, so I cannot reproduce such 
> issues. [1]
>
> Can you confirm that the microcode is active?
> sudo journalctl --boot | grep microcode
>

It was, but I forgot to capture this output.

> Could you try uninstalling the package 'amd-microcode'?
> sudo apt-get remove amd-microcode
> sudo update-initramfs -u
>
> Does that fix your graphical issues?

No, but installing the non-free nvidia-driver did. It's a pity, as I don't need 
anything nouveau couldn't theoretically provide.

Thanks anyway.

--Adam

Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)

[Askar Safin]

/var/lib/dpkg/info/base-files.postinst installs /root/.bashrc from
/usr/share/base-files/dot.bashrc .
So /root/.bashrc is owned by base-files .
I found this is already reported to base-files:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275623 .
And moreover there is a message on bash-completion there, which CC
you: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275623#58 .

-- 
Askar Safin

Bug#1034634: unblock: freetype/2.12.1+dfsg-5

[Hugh McMaster]

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

Please unblock package freetype.

[ Reason ]
An integer overflow vulnerability was discovered in FreeType (specifically, the
tt_hvadvance_adjust() function). This is CVE-2023-2004.

[ Impact ]
FreeType 2 can crash when getting TrueType font metrics due to the overflow.

[ Tests ]
Chromium's OSS-Fuzz project regularly fuzzes the FreeType source. After the
upstream fix was applied, the vulnerability was fixed.

[ Risks ]
The patch is non-invasive and very small.

[ 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 freetype/2.12.1+dfsg-5
diff -Nru freetype-2.12.1+dfsg/debian/changelog 
freetype-2.12.1+dfsg/debian/changelog
--- freetype-2.12.1+dfsg/debian/changelog   2023-01-12 23:05:22.0 
+1100
+++ freetype-2.12.1+dfsg/debian/changelog   2023-04-20 21:08:03.0 
+1000
@@ -1,3 +1,10 @@
+freetype (2.12.1+dfsg-5) unstable; urgency=medium
+
+  * debian/patches: Add a patch to fix CVE-2023-2004 (Closes: #1034612).
+- Integer overflow in tt_hvadvance_adjust().
+
+ -- Hugh McMaster   Thu, 20 Apr 2023 21:08:03 +1000
+
 freetype (2.12.1+dfsg-4) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru freetype-2.12.1+dfsg/debian/patches/CVE-2023-2004.patch 
freetype-2.12.1+dfsg/debian/patches/CVE-2023-2004.patch
--- freetype-2.12.1+dfsg/debian/patches/CVE-2023-2004.patch 1970-01-01 
10:00:00.0 +1000
+++ freetype-2.12.1+dfsg/debian/patches/CVE-2023-2004.patch 2023-04-20 
21:03:11.0 +1000
@@ -0,0 +1,42 @@
+Description: Prevent integer overflow in tt_hvadvance_adjust().
+ Fixes CVE-2023-2004.
+Author: Werner Lemberg 
+Origin: 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/e6fda039ad638866b7a6a5d046f03278ba1b7611
+Bug-Debian: https://bugs.debian.org/1034612
+Last-Update: 2023-04-30
+
+--- a/src/truetype/ttgxvar.c
 b/src/truetype/ttgxvar.c
+@@ -42,6 +42,7 @@
+ #include 
+ #include 
+ #include FT_CONFIG_CONFIG_H
++#include 
+ #include 
+ #include 
+ #include 
+@@ -1133,14 +1134,17 @@
+outerIndex,
+innerIndex );
+ 
+-FT_TRACE5(( "%s value %d adjusted by %d unit%s (%s)\n",
+-vertical ? "vertical height" : "horizontal width",
+-*avalue,
+-delta,
+-delta == 1 ? "" : "s",
+-vertical ? "VVAR" : "HVAR" ));
++if ( delta )
++{
++  FT_TRACE5(( "%s value %d adjusted by %d unit%s (%s)\n",
++  vertical ? "vertical height" : "horizontal width",
++  *avalue,
++  delta,
++  delta == 1 ? "" : "s",
++  vertical ? "VVAR" : "HVAR" ));
+ 
+-*avalue += delta;
++  *avalue = ADD_INT( *avalue, delta );
++}
+ 
+   Exit:
+ return error;
diff -Nru freetype-2.12.1+dfsg/debian/patches/series 
freetype-2.12.1+dfsg/debian/patches/series
--- freetype-2.12.1+dfsg/debian/patches/series  2023-01-12 23:05:22.0 
+1100
+++ freetype-2.12.1+dfsg/debian/patches/series  2023-04-20 21:02:52.0 
+1000
@@ -5,3 +5,4 @@
 CVE-2022-31782.patch
 fix-wild-free-svg.patch
 hardening.patch
+CVE-2023-2004.patch

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

[Reinhard Tartler]

On Thu, Apr 13, 2023 at 6:46 AM Reinhard Tartler  wrote:

>
> -- unfortunately, I made a mistake: I packaged version 3 of
> jellydator-ttlcache, which has a significantly different API than version2,
> which sigstore currently uses.
>
> I'm considering either downgrading the package, or making sigstore use v3.
> I guess the latter is better in the long term. Mh.
>
>
https://github.com/sigstore/sigstore/pull/1099 to make up for that mistake

-- 
regards,
Reinhard

Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore

[Alf]

Found detailled information on my hardware as I noted on first installation in 
Debian-Stretch:


$ /opt/bin/mediaclient -e
 List of Media Hardware Devices 
device 0: [Sundtek MediaTV Pro (USB 2.0)]  
DVB-C, DVB-T,
  ANALOG-TV, FM-RADIO, 
REMOTE-CONTROL, OSS-AUDIO, RDS
  [INFO]:
 STATUS: STANDBY
  [BUS]:
 ID: 3-1.4
  [SERIAL]:
 ID: U120820070038
  [DVB-C,DVB-T]:
 FRONTEND: /dev/dvb/adapter0/frontend0
 DVR: /dev/dvb/adapter0/dvr0
 DMX: /dev/dvb/adapter0/demux0
  [ANALOG-TV]:
 VIDEO0: /dev/video1
 VBI0: /dev/vbi0
  [FM-RADIO]:
 RADIO0: /dev/radio0
 RDS: /dev/rds0
  [REMOTECONTROL]:
 INPUT0: /dev/mediainput0
  [OSS]:
 OSS0: /dev/dsp0

Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore

[Alf]

Am 19.04.23 um 23:02 schrieb Nicholas D Steeves:

Dear Alf and James,

I agree that DVB support is important, and I just uploaded mpv_0.35.1-4
(to sid/unstable).  That release will close this bug, but please test
this it ASAP and confirm that it works with your DVB hardware.
Yes, I know it might take a day to become available...sorry about that.


I just updated mpv to version 0.35.1-4 from Sid - and can confirm that the
issue has been fixed. All works as some time ago with v34.*.

...
 (+) Video --vid=1 (h264 1280x720 50.000fps)
 (+) Audio --aid=1 (mp2 2ch 48000Hz)
File tags:
 Title: arte HD(Unitymedia)
[ffmpeg/video] h264: co located POCs unavailable
Using hardware decoding (vaapi).
AO: [pipewire] 48000Hz stereo 2ch s16p
VO: [gpu] 1280x720 vaapi[nv12]
AV: 00:11:15 / 00:11:19 (99%) A-V:  0.000 Cache: 4.1s/5MB

Hardware here is a quite old "Sundtek TV-Stick" from 2017 with their driver.
I am watching DVB-C television with it and the channels.conf is unchanged.

THANKS for your fast response and the fix!

What now does not work: "smplayer". It only plays sound but no video.
SMplayer-Protocol continously spits huge amounts of these messagen:
[12:23:52:227] MPVProcess::parseLine: "[vo/vaapi] vaPutSurface() failed (invalid 
parameter)"

But that's not an issue as long as "mpv" does the job.

Alf

Bug#982017: harden-doc: Wrong homepage

[Vincent Lefevre]

On 2021-02-05 19:00:36 +0100, Davide Prina wrote:
> I have see that the project homepage do not respond anymore:
> https://www.debian.org/doc/manuals/securing-debian-howto/

I get a "Page not found" error.

> I think that the homepage is now:
> https://www.debian.org/doc/user-manuals#securing

As it says that this is available via the harden-doc package,
this seems to be the case.

Could this eventually be updated for bookworm?

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

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

[Paul Gevers]

Hi Andreas,

On Fri, 31 Mar 2023 15:06:14 +0200 Andreas Metzler  wrote:

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


And to be backports and other local packages, I think that could/should 
be (<< 2.5.7-3~).


Can a/this fix be uploaded soon please? We're trying to pick a bookworm 
release date and a fix should be in.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#931520: harden-doc: before-compromise section references testing/updates instead of testing-security

[Vincent Lefevre]

On 2019-07-07 11:12:11 +0800, Paul Wise wrote:
> The harden-doc before-compromise section references testing/updates but
> with bullseye that suite has been renamed to testing-security. Please
> update the harden-doc before-compromise section.

Could this eventually be updated for bookworm?
It is bad to give wrong information to users.

BTW, the old testing/updates lines are still visible here:
  
https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#security-support-testing

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

Bug#1034196: unblock: openrefine/3.6.2-2

[Paul Gevers]

Control: tags -1 moreinfo

Hi,

On Mon, 10 Apr 2023 23:55:44 +0200 Markus Koschany  wrote:

This unblock is related to #1034127 and the unblock of rhino.


rhino is now unblocked.


The main reason for
upgrading from 3.6.1 to 3.6.2 was to include missing Javascript files
which are needed to run the web / desktop application of openrefine.


I *think* you are abusing missing-sources. Quoting policy [1]:
"""
Sometimes upstream does not include the source code for some files in 
the upstream tarball. In order to satisfy the DFSG for packages in main 
or contrib, you should either:


repack the upstream tarball to include those sources; or

include a copy of the sources in the debian/missing-sources directory.
"""
But you are *installing* those missing sources. On top of that, you are 
shipping yet another copy of e.g. jquery.js [2]. Please, if remotely 
possible, use bin:libjs-jquery (and similar for the other dependencies) 
instead.


Paul

[1] 
https://www.debian.org/doc/debian-policy/ch-source.html#missing-sources-debian-missing-sources
[2] 
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034632: rust-zram-generator: FTBFS - Couldn't find DIE at [59fe9]

[Lukas Märdian]

Package: rust-zram-generator
Version: 1.1.2-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Dear Maintainer,

rust-zram-generator FTBFS on LLVM-15 when LTO is enabled in Cargo.toml due to
https://github.com/rust-lang/rust/issues/66118

This does not currently affect Debian, but can be reproduced on Ubuntu, where
llvm-15 is already the default. It will affect Debian in the future.

   dh_fixperms -a -O--buildsystem=cargo
   dh_missing -a -O--buildsystem=cargo
   dh_dwz -a -O--buildsystem=cargo
dwz: 
debian/systemd-zram-generator/lib/systemd/system-generators/zram-generator: 
Couldn't find DIE at [55d39] referenced by DW_AT_abstract_origin from DIE at 
[25457]
dh_dwz: error: dwz -- 
debian/systemd-zram-generator/lib/systemd/system-generators/zram-generator 
returned exit code 1

In Ubuntu, the attached patch was applied to achieve the following:
  * d/rules: Disable dwz to fix FTBFS with LTO

Thanks for considering the patch.

-- Lukas


-- 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.19.0-38-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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
diff -Nru rust-zram-generator-1.1.2/debian/rules 
rust-zram-generator-1.1.2/debian/rules
--- rust-zram-generator-1.1.2/debian/rules  2022-12-28 18:03:27.0 
+0100
+++ rust-zram-generator-1.1.2/debian/rules  2023-04-20 10:58:07.0 
+0200
@@ -14,3 +14,7 @@
mv debian/systemd-zram-generator/usr/bin/zram-generator \
debian/systemd-zram-generator/lib/systemd/system-generators
rm -rf debian/systemd-zram-generator/usr/bin
+
+override_dh_dwz:
+   # Don't do anything. Fails because of LTO:
+   # https://github.com/rust-lang/rust/issues/66118

Bug#1034060: unblock: aide/0.18.2-1

[Paul Gevers]

Control: tags -1 confirmed moreinfo

On 07-04-2023 19:34, Marc Haber wrote:

This is a pre-upload request for guidance regarding aide 0.18.2.
upstream released a new version that fixes a number of locking issues,
each of which possible a release-critical bug.


It seems you are overly cautious in this case.


The aide package has autopkgtests.


As aide is not a key package, this means we don't need to be involved if 
we're not going into full freeze already.



A debdiff of the actual package will be delivered for approval before
upload once you have indicated that you would consider approval. Thanks
in advance.


A debdiff normally contains all changes including the debian/changelog. 
I'm fine for now.


Please remove the moreinfo tag once the package is uploaded and might 
miss bookworm due to an announcement of the full freeze (I'd expect if 
you upload soon, we don't need to be further involved).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033935: unblock: ausweisapp2/1.26.3-1

[John Paul Adrian Glaubitz]

Hello Paul!

On Thu, 2023-04-20 at 10:40 +0200, Paul Gevers wrote:
> On 04-04-2023 12:01, John Paul Adrian Glaubitz wrote:
> > I would like to ask for the package ausweisapp2 to be unblocked for
> > testing. While the debdiff is rather large (about 1.8 MB),
> 
> Could you prepare a debdiff stripping tests (assuming those are not 
> influencing the build itself), stripping the copyright line changes and 
> dropping the changed png files? It seems this might be reviewable when 
> that's done.

Thanks, this is a very good idea to make the debdiff more reviewable!

I will look into this.

> > the package
> > itself is just a leaf package and used for a very specific purpose only
> > which is providing the official ID card authentication app of the German
> > government, so I think the risk conveyed by this update is rather low.
> 
> Well, in the hard freeze we're looking for *targeted* fixes [1].
> 
> Paul
> PS: you could consider if an (non-superficial) autopkgtest is 
> possible/reasonable

I have no experience with autopkgtest yet, but this is definitely on my TODO 
list.

Thanks,
Adrian

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

Bug#1034314: Bug fixed upstream

[David Härdeman]

Note: this patch has been accepted upstream and is included in GSD 44.1

Bug#1033935: unblock: ausweisapp2/1.26.3-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Adrian,

On 04-04-2023 12:01, John Paul Adrian Glaubitz wrote:

I would like to ask for the package ausweisapp2 to be unblocked for
testing. While the debdiff is rather large (about 1.8 MB),


Could you prepare a debdiff stripping tests (assuming those are not 
influencing the build itself), stripping the copyright line changes and 
dropping the changed png files? It seems this might be reviewable when 
that's done.



the package
itself is just a leaf package and used for a very specific purpose only
which is providing the official ID card authentication app of the German
government, so I think the risk conveyed by this update is rather low.


Well, in the hard freeze we're looking for *targeted* fixes [1].

Paul
PS: you could consider if an (non-superficial) autopkgtest is 
possible/reasonable


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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3

[Roger Shimizu]

On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov
 wrote:
>
> On Wed, 19 Apr 2023 at 10:06, Roger Shimizu  wrote:
> >
> > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov
> >  wrote:
> > >
> > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu  wrote:
> > > >
> > > > > Hello Roger, FTP masters,
> > > > > Short story: the uploaded linux-board-support-package-dragonboard845c 
> > > > > package (currently in NEW) contains a file with unclear license 
> > > > > background and as such it should not be allowed into the archive.
> > > > > The orig.tar.gz file needs to be repackaged before uploading.
> > > >
> > > > I tried to repack the orig, and re-upload, but got REJECTED by:
> > > >
> > > > linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc:
> > > > Does not match file already existing in the pool.
> > >
> > > Usually one would use suffix like -dfsg to mark the repacked package.
> > > The -dfsg doesn't make sense in the case of a non-free package, so you
> > > can probably use -repack.
> >
> > Yes, but upstream uses .zip archive anyhow.
> > So we have to repack to .orig.tar.*
>
> To notify possible users that it's not just a repack of zip, but also
>
> >
> > > More importantly I'm not sure that this package should be a part of
> > > Debian at all.
> >
> > Why?
> > Without bootloader part, we cannot support installer in Debian.
>
> This bootloader is already installed by the manufacturer. Please
> consider these partitions as a firmware. One does not modify the
> device firmware during Debian installation.
>
> Maybe I misunderstand something about the usecase you are facing.
> Could you please describe it?

RB3 is an open platform.
You do not know what system user previously installed.
And even Linaro provided two different system, with different
partition layouts, aosp and linux:
- https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/
I'm not sure why you suppose the bootloader has to be original.

Linaro's rescue image also rewrite those partitions.
I think Debian should do the same.

> My current understanding:
> - The device comes from the factory with the bootloaders flashed
> - DI repartitions one of UFS LUNs to replace vendor+system+userdata
> with the rootfs/home/etc
> - DI installs all the packages to the target rootfs, including the
> package with custom kernel hooks
> - the kernel hooks write the generated android boot img to the boot partition
>
> Is there anything else?

Anyway, this is not for this ITP ticket. We can discuss when porting
to installer.

> > > I doubt that DI should touch these partitions. Firstly, because of the
> > > reasons I expressed in my previous email (risk of bricking the board,
> > > custom bootloaders being used on these devboards, etc).
> > > Secondly, I'd like to point out that RB3/RB5 (and other dragonboards)
> > > are in a pretty unique position. Other development boards (QRD, HDK,
> > > Open-Q, etc.) do not have public redistributable bootloader archives.
> >
> > No worries about the brick issue.
>
> Actually, no. Bricking the device during installer is a very bad thing.

I said no worries, because we need to fix those issue when porting to installer.
This is ITP ticket, and we need to be focus on packaging firmware first.

Cheers,
Roger

> > We should consider this before releasing it to installer.
> > Currently, we just take the 1st step to get everything necessary to
> > hit the debian archive.
>
> Ok, it's up to you, once the archive is free of the Renesas firmware,
> but I'd not consider it 'necessary'.  The user has to perfectly know
> what he is flushing and why. I'd strongly advice to point to the
> rescue packages or to the Thundercomm SDK manager instead of packaging
> everything into the installer.
>
> --
> With best wishes
> Dmitry

Bug#1034617: unblock: libxml2/2.9.14+dfsg-1.2

[Paul Gevers]

Hi,

On 19-04-2023 22:03, Salvatore Bonaccorso wrote:

unblock libxml2/2.9.14+dfsg-1.2


Unblocked, thanks.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034631: lintian: Warn for 32bit time_t / Y2038 problems

[Uwe Kleine-König]

Package: lintian
Version: 2.116.3
Severity: normal
Tags: patch
X-Debbugs-Cc: uklei...@debian.org

Hello,

to help making package maintainers aware of the Y2038 problem I
implemented a lintian check that triggers if a symbol from glibc is used
that uses a 32bit time_t type.

The code is available in a MR on the lintian packaging repository at
https://salsa.debian.org/lintian/lintian/-/merge_requests/463

Thanks for considering
Uwe

Bug#1034630: ITP: serious-engine -- game engine developed for the classic Serious Sam games

[Sébastien Noel]

Package: wnpp
Severity: wishlist
Owner: Sébastien Noel 
X-Debbugs-Cc: debian-de...@lists.debian.org, sebast...@twolife.be

* Package name: serious-engine
  Version : 0~git20230405
* URL : https://github.com/ptitSeb/Serious-Engine/
* License : GPLv2
  Programming Lang: C++
  Description : first-person shooter game engine

The serious-engine serve as the base for two games developed
by Croteam and originally published in 2001 & 2002 :

The series follows the adventures of protagonist Sam "Serious" Stone
and his fight against the forces of the notorious extraterrestrial
overlord Mental, who seeks to destroy humanity.

This package alone isn't of any use; it only contains the game engine,
you will need a copy of the original game for this package to be
useful. This can be purchased from GOG.

Bug#1026886: watch file for packages on github

[Kentaro Hayashi]

Hi,

> It is possible to write watch files dealing with pre-releases without using
> fakeupstream.cgi. Here are some variants:
> 
...
> 
> The 'failure scenario' describes just one of many mistakes upstream can make,
> and fakeupstream.cgi isn't meant to correct such upstream human mistakes. It 
> is
> rather meant to make it possible to track upstream versions where it otherwise
> would not be.

In 'failure scenario', I admire that it maybe a rare case, the problem is that
tag itself doesn't have information whether pre-release or official release.
(need to contains the identifier to distingish)

Thus, suggested watch rule works in most cases if upstream tagged as 
pre-release to
 v0.1.97pre or something,
but it will not work as expectedlly if v0.1.97 tag is given to pre-release.
(it is bad practice, though)

In GitHub, pre-release requires tag, so it may happen re-creating same tag for 
release
from a sysytem point of view.


Anyway, it may be a trivial exceptional case, so I'll close it.

Regards,




 

Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.

[Patryk Obara]

On 1.04.2023 16:57, Zuhair al-Mrayyed wrote:


Why do we need both rather than upgrading dosbox? Is this package
supposed to take over the existing binary package eventually?

Kind regards
Philipp Kern


some games are buggy in dosbox but run fine in dosbox-staging,
CyberMage: Darklight Awakening, for Example, has joystick calibration
issues in dosbox but not in staging.

regards,

Zuhair al-Mrayyed


This thread started more than two years ago. Since that time
"vanilla" DOSBox still has the same issues and had no releases, while
DOSBox Staging is now sitting at 0.80.1, and we're working towards
version 0.81.0. Debian users are forced to rely on non-native packages
such as Flatpak or Snap to get software that is working properly.

Is naming such a big deal that it prevents our emulator from hitting 
Debian repositories? We are packaged by several other distributions

already: https://repology.org/project/dosbox-staging/versions

Please talk to us, how we can help in making DOSBox Staging packaged
on Debian?

Cheers,

Patryk Obara

Bug#1034190: More security bugs in game loading

[Paul Gevers]

Hi Ben,

On Mon, 10 Apr 2023 22:01:04 +0200 Ben Hutchings  
wrote:

Package: sgt-puzzles
Severity: serious


The fix for this bug will not automatically migrate to testing because 
the package doesn't have autopkgtests and we're in the freeze. The 
changes are massive, so I'd like to confirm in an unblock bug that all 
changes are indeed targeted fixes before unblocking. Can you file such 
an unblock request if you don't want the package to be autoremoved (or 
add a non-superficial autopkgtest if that makes sense)?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031152: system-config-printer: unlock button in system-config-printer provides no elevated permissions dialog

[Laurent Bigonville]

On Sun, 12 Feb 2023 09:06:02 -0500 Alexis  wrote:
[...]
>
>
> * What was the outcome of this action?
>
> The following error was thrown:
>

> Gtk-WARNING **: 08:47:30.475: Error acquiring permission: Failed to 
acquire permission for action-id 
org.opensuse.cupspkhelper.mechanism.all-edit


Do you have the cups-pk-helper package installed?

system-config-printer-common already recommends that package.

The definition of Recommends is: "This declares a strong, but not 
absolute, dependency. The Recommends field should list packages that 
would be found together with this one in all but unusual 
installations.", so you should probably also install recommended packages.


Kind regards,

Laurent Bigonville

Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error

[Robert Jäschke]

Package: pdf-presenter-console
Version: 4.6.0-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: jaesc...@l3s.de

Dear Maintainer,

When starting pdfpc it immediately dies with the following error
message:

> pdfpc slides.pdf
pdfpc: symbol lookup error: /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: 
undefined symbol: gst_transcoder_get_sync_signal_adapter


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

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

Versions of packages pdf-presenter-console depends on:
ii  libc6   2.36-9
ii  libcairo2   1.16.0-7
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libgee-0.8-20.20.6-1
ii  libglib2.0-02.74.6-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3
ii  libgstreamer1.0-0   1.22.0-2
ii  libgtk-3-0  3.24.37-2
ii  libjson-glib-1.0-0  1.6.6-1
ii  libmarkdown22.2.7-2
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpangocairo-1.0-0 1.50.12+ds-1
ii  libpoppler-glib822.12.0-2+b1
ii  libqrencode44.1.1-1
ii  libsoup2.4-12.74.3-1
ii  libwebkit2gtk-4.0-372.40.0-3
ii  libx11-62:1.8.4-2

Versions of packages pdf-presenter-console recommends:
ii  gstreamer1.0-gtk3  1.22.0-5

pdf-presenter-console suggests no packages.

-- no debconf information

Bug#1034392: Acknowledgement (tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater)

[Per Lundberg]

On 2023-04-20 00:03, Vladimir Petko wrote:


Oh, thank you for providing a patch for a quite annoying bug


The pleasure is ours. :-) (I didn't write the patch myself but I helped
out a bit with the initial debugging)


Would it be possible to add a header to the patch, so that it is
possible to see where it came from and why, e.g.


Great suggestions - I have added the header as suggested to the patch.

As mentioned, we haven't tested this on JDK 11. If someone has the JDK
11 sources & build environment readily available, it would be great to
get it verified if it works there as well. (This does not hinder the
patch from being applied to JDK 17 already, from my POV.)
--
Best regards,
PerDescription: attach in linux hangs due to permission denied accessing /proc/pid/root
  The attach API uses /proc/pid/root in order to support containers.
  Dereferencing this symlink is governed by ptrace access mode PTRACE_MODE_READ_FSCREDS
  which may not succeed when running as the user running the JRE.
  This breaks running jcmd and jmap as the same user the JVM is running as.
  Use tmpdir when pid matches ns_pid.
Author: Sebastian Lövdahl 
Bug: https://bugs.openjdk.org/browse/JDK-8226919
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034601
Last-Update: 2023-04-18

From 36b554e2de46d77898be4d0feae0ee2171b445bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sebastian=20L=C3=B6vdahl?= 
Date: Tue, 18 Apr 2023 12:50:32 +0300
Subject: [PATCH] 8226919: Fix dynamic attach in Linux for non-container
 environments

---
 .../sun/tools/attach/VirtualMachineImpl.java  | 37 ---
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
index 324e52235cb..605adc20157 100644
--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
@@ -209,11 +209,8 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
 }

 // Return the socket file for the given process.
-private File findSocketFile(int pid, int ns_pid) {
-// A process may not exist in the same mount namespace as the caller.
-// Instead, attach relative to the target root filesystem as exposed by
-// procfs regardless of namespaces.
-String root = "/proc/" + pid + "/root/" + tmpdir;
+private File findSocketFile(int pid, int ns_pid) throws IOException {
+String root = findTargetProcessTmpDirectory(pid, ns_pid);
 return new File(root, ".java_pid" + ns_pid);
 }

@@ -229,21 +226,33 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
 // Do not canonicalize the file path, or we will fail to attach to a VM in a container.
 f.createNewFile();
 } catch (IOException x) {
-String root;
-if (pid != ns_pid) {
-// A process may not exist in the same mount namespace as the caller.
-// Instead, attach relative to the target root filesystem as exposed by
-// procfs regardless of namespaces.
-root = "/proc/" + pid + "/root/" + tmpdir;
-} else {
-root = tmpdir;
-}
+String root = findTargetProcessTmpDirectory(pid, ns_pid);
 f = new File(root, fn);
 f.createNewFile();
 }
 return f;
 }

+private String findTargetProcessTmpDirectory(int pid, int ns_pid) throws IOException {
+String root;
+if (pid != ns_pid) {
+// A process may not exist in the same mount namespace as the caller.
+// Instead, attach relative to the target root filesystem as exposed by
+// procfs regardless of namespaces.
+String procRootDirectory = "/proc/" + pid + "/root";
+if (!Files.isReadable(Path.of(procRootDirectory))) {
+throw new IOException(
+String.format("Unable to access root directory %s " +
+  "of target process %d", procRootDirectory, pid));
+}
+
+root = procRootDirectory + "/" + tmpdir;
+} else {
+root = tmpdir;
+}
+return root;
+}
+
 /*
  * Write/sends the given to the target VM. String is transmitted in
  * UTF-8 encoding.
--
2.40.0

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

[Paul Gevers]

Hi,

Sorry for taking so long to respond (the moreinfo tag was still attached 
to the bug, so it didn't show up in my regular bts view, so please 
remove it when you reply).


On 16-03-2023 11:40, Christian Kastner wrote:

Overall, the diff is a bit long (and has some irrelevant stuff), so
I'm hesitant to offer t-p-u now (to avoid waiting for
llvm-toolchain-15).


Understood. Yeah, the diff is long, unfortunately, as the packaging
fixes accumulated over time.


That's why (especially around the freeze) we expect maintainers to keep 
track of migration and ensure they happen. You got stuck behind 
llvm-toolchain-15, but that's very unlikely to be fixed before the release.



Is this something that you could consider at a later point in time, if I
also break down the diff into more reviewable fragments (dependencies,
build, metadata, ...)? Because I do think that most changes are just
fixes of one sort or another - no features added.


I checked the diff again and I was about to propose to upload it to tpu, 
but I saw the following:


diff -Nru rocm-hipamd-5.2.3/debian/rules rocm-hipamd-5.2.3/debian/rules
--- rocm-hipamd-5.2.3/debian/rules  2022-10-20 19:20:33.0 +
+++ rocm-hipamd-5.2.3/debian/rules  2023-03-10 22:38:51.0 +

[...]
+   -DHIP_PLATFORM=amd

Is that correct for the arm64 builds?

Paul


OpenPGP_signature
Description: OpenPGP digital signature