Bug#1043005: plasma-dialer: org.kde.telephony used in multiple dbus files

[Russell Coker]

Package: plasma-dialer
Version: 23.01.0-1
Severity: normal
X-Debbugs-Cc: russ...@coker.com.au

mobian@mobian:~$ grep -R org.kde.telephon /usr/share/dbus-1/services
/usr/share/dbus-1/services/org.kde.modemdaemon.service:Name=org.kde.telephony
/usr/share/dbus-1/services/org.kde.telephony.service:Name=org.kde.telephony

Above is the output of grep, both those files are in this package.

gnoring duplicate name 'org.kde.telephony' in service file '/usr/share//
dbus-1/services/org.kde.telephony.service'

The above error is from dbus-launcher.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1-rockchip (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not 
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages plasma-dialer depends on:
ii  callaudiod0.1.9-1
ii  libc6 2.37-6
ii  libcallaudio-0-1  0.1.9-1
ii  libkf5configcore5 5.107.0-1
ii  libkf5configgui5  5.107.0-1
ii  libkf5contacts5   5:5.107.0-1
ii  libkf5coreaddons5 5.107.0-1
ii  libkf5dbusaddons5 5.107.0-1
ii  libkf5i18n5   5.107.0-1+b1
ii  libkf5kiogui5 5.107.0-1
ii  libkf5modemmanagerqt6 5.107.0-1
ii  libkf5notifications5  5.107.0-1
ii  libkf5people5 5.107.0-1
ii  libkf5peoplebackend5  5.107.0-1
ii  libkf5service-bin 5.107.0-1
ii  libkf5service55.107.0-1
ii  libkf5windowsystem5   5.107.0-1
ii  libphonenumber8 [libphonenumber8-protobuf32]  8.12.57+ds-4
ii  libqt5core5a  5.15.10+dfsg-3
ii  libqt5dbus5   5.15.10+dfsg-3
ii  libqt5feedback5   5.0~git20180903.a14bd0b-5
ii  libqt5gui55.15.10+dfsg-3
ii  libqt5qml55.15.10+dfsg-2
ii  libqt5quickcontrols2-55.15.10+dfsg-2
ii  libqt5sql55.15.10+dfsg-3
ii  libqt5waylandclient5  5.15.10-2
ii  libstdc++613.2.0-1
ii  libwayland-client01.22.0-2

plasma-dialer recommends no packages.

plasma-dialer suggests no packages.

-- debconf-show failed

Bug#1043004: mozillavpn: CVE-2023-4104

[Salvatore Bonaccorso]

Source: mozillavpn
Version: 2.9.0-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for mozillavpn.

CVE-2023-4104[0]:
| Privileged vpndaemon on Linux wrongly and incompletely implements
| Polkit authentication


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-4104
https://www.cve.org/CVERecord?id=CVE-2023-4104
[1] https://www.openwall.com/lists/oss-security/2023/08/03/1

Regards,
Salvatore

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[YunQiang Su]

Simon McVittie  于2023年8月4日周五 00:33写道：
>
> Source: gnome-shell
> Version: 44.3-1
> Severity: serious
> Tags: ftbfs experimental help
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: debian-m...@lists.debian.org
> User: debian-m...@lists.debian.org
> Usertags: mips64el mipsel
>
> gnome-shell 44 builds successfully on all release architectures except
> mips*el, but fails to build on mips*el. The three perf-* unit tests fail
> with exit status 1 and no obvious error messages:
> 
> 
>
> At the moment this is only in experimental, but we want to upload it to
> unstable soon, as part of the libmutter-12-0 transition
> .
>

I will try to debug it.

> Is gnome-shell practically useful on mips-based hardware, or does it
> have hardware requirements that the mips family do not meet in practice?
> If nobody really uses it on mips*el, it might be better to do
> architecture-specific removals rather than attempting to debug and fix it.
>
> Or, if the mips porting team can confirm that GNOME 43 works in practice
> as a desktop environment on mips*el hardware, then it would be useful

Yes. There are some MIPS desktop cases.

> to try GNOME 44 from experimental on the same hardware (after building
> gnome-shell locally with DEB_BUILD_OPTIONS=nocheck) to check whether
> this is a practical problem.
>
> Thanks,
> smcv
>


-- 
YunQiang Su

Bug#1042994: libreoffice-draw experimental: LibreOffice Draw (and LO Impress) do not start

[Rene Engelhard]

tag 1042994 + unreproducible

tag 1042994 + moreinfo

thanks


Hi,

Am 04.08.23 um 01:22 schrieb Thomas Florek:
Launching LO Draw (and also LO Impress) did not work, either from the 
plasma desktop or from the console.


Works fine here. (Clean sid VM with experimentals LO)


Even tried extra in KDE (X11 and wayland).


I see you have non-Debian packages installed. try with a clean Debian?


Regards,


Rene

Bug#1041457: python-escript: FTBFS on i386

[Sebastiaan Couwenberg]

Control: severity -1 important

python-escript was removed from i386 (#1042939).

Reducing the severity accordingly.

Kind Regards,

Bas

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

Bug#1043003: RFP: node-socket-cli -- CLI tool for Socket.dev

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: node-socket-cli
  Version : 0.7.1
  Upstream Contact: Socket (https://github.com/SocketDev/)
* URL : https://github.com/SocketDev/socket-cli-js
* License : MIT
  Programming Lang: JavaScript
  Description : CLI tool for Socket.dev

This tool can be used to pull useful security information out of the
socket.dev (proprietary) service, but more interestingly, it can also be
used as a safety wrapper around the npm:

  https://socket.dev/blog/introducing-safe-npm

Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Scott Kitterman]

Source: pdm
Version: 2.2.1+ds1-1
Severity: important

The python3-pep517 package has been replaced by python3-pyproject-hooks.
Please update your package depends and build-depends (this may required
a new upstream release - I did check and the current upstream release
supports using pyproject-hooks).

Once I request removal, I'll raise the severity of this to serious.  I
expect that by next week we'll be down to only two or three packages
left that use pep517, so I'll probably request it then.  If you need
more time to update this package, I can wait, please let me know.

Scott K

Bug#1043001: ITP: ukui-system-appwidget -- The ukui time app widget

[xibowen]

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

* Package name: ukui-system-appwidget
  Version : 4.0.0.1-1
  Upstream Contact: wangyan 
* URL : https://gitee.com/openkylin/ukui-system-appwidget/
* License : GPL
  Programming Lang: C++
  Description : The ukui time app widget


ukui-system-appwidget is an application of ukui-app-widget, which is
used to display the time on the desktop. It contains modules of
month, day, hour, minute and AM/PM.
It is a widget application. We need a sponsor.

Bug#1043000: libgtk-3-0: segfault if wayland compositor does not support xdg_activation_v1

[James Ye]

Package: libgtk-3-0
Version: 3.24.37-2
Severity: important
Tags: upstream
X-Debbugs-Cc: jye...@gmail.com

Dear Maintainer,

On bookworm, when using a Wayland compositor that does not support
xdg_activation_v1, GTK3 applications launched through desktop entries will
immediately segfault.

One such compositor included in Debian is the enlightenment desktop. This issue
is also encountered in other environments, such as when using the "Linux apps"
feature of Chromebooks.

This bug was reported upstream at
https://gitlab.gnome.org/GNOME/gtk/-/issues/5701, and the fix is included in GTK
3.24.38.


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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   43-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u1
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libcolord2   1.4.6-2.2
ii  libcups2 2.4.2-3+deb12u1
ii  libepoxy01.5.10-1
ii  libfontconfig1   2.14.1-4
ii  libfribidi0  1.0.8-2.1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-common  3.24.37-2
ii  libharfbuzz0b6.0.0+dfsg-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpangoft2-1.0-01.50.12+ds-1
ii  libwayland-client0   1.21.0-1
ii  libwayland-cursor0   1.21.0-1
ii  libwayland-egl1  1.21.0-1
ii  libx11-6 2:1.8.4-2+deb12u1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.1-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxkbcommon01.5.0-1
ii  libxrandr2   2:1.5.2-2+b1
ii  shared-mime-info 2.2-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin 3.24.37-2
ii  librsvg2-common  2.54.5+dfsg-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs  1.50.3-1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
ii  ibus-gtk3 1.5.27-5
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-10
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#1042999: flatpak: remote-add'ing flathub fails with error: SSL peer certificate or SSH remote key was not OK

[Steve Mcqueen]

Package: flatpak
Version: 1.14.4-1
Severity: important
X-Debbugs-Cc: stevemcqu...@mailinator.com

Dear Maintainer,

>From a new install of Debian bookworm, i'm attempting to install flatpak
and flathub for the first time. I run the remote-add command and get
back an ssl error. example:

$ flatpak remote-add --if-not-exists flathub 
https://flathub.org/repo/flathub.flatpakrepo
error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: While 
fetching https://flathub.org/repo/flathub.flatpakrepo: [60] SSL peer 
certificate or SSH remote key was not OK

That flathub URL is a 301 redirect to: 
https://dl.flathub.org/repo/flathub.flatpakrepo

As far as I can tell there's nothing wrong with the certs on flathub's
end. I tried a few random online SSL validators and they gave no
complaints. The cert isn't expired, and is properly chained. directly 
using curl doesn't seem to complain. Firefox doesn't complain. 
Interestingly, wget DOES complain about the url, saying the certificate
is not trusted. 

Manually downloading the .flatpakrepo file and installing that way gets
a little further, but complains again the same way when trying to
download another metadata file.

So this may not be flatpak related, but maybe something to do with 
ca-certificates or curl or something like that? Expired root CA or
something? This is the edge of my knowledge.

The end result of this is that I cannot use flatpak in Debian bookworm
because I cannot add the main remote repository from flathub.

-- Package-specific info:
Permissions of /usr/bin/bwrap:
-rwxr-xr-x 1 root root 72080 Feb 28 02:38 /usr/bin/bwrap
/etc/sysctl.d/*-bubblewrap.conf:
cat: '/etc/sysctl.d/*-bubblewrap.conf': No such file or directory
/usr/lib/sysctl.d/50-bubblewrap.conf:
# Enable unprivileged creation of new user namespaces in older Debian
# kernels.
#
# If this is not desired, copy this file to
# /etc/sysctl.d/50-bubblewrap.conf and change the value of this parameter
# to 0, then use dpkg-statoverride to make /usr/bin/bwrap setuid root.
#
# For more details see https://deb.li/bubblewrap or
# /usr/share/doc/bubblewrap/README.Debian
kernel.unprivileged_userns_clone=1
/proc/sys/kernel/unprivileged_userns_clone:
1
/proc/sys/user/max_cgroup_namespaces:
126235
/proc/sys/user/max_ipc_namespaces:
126235
/proc/sys/user/max_mnt_namespaces:
126235
/proc/sys/user/max_net_namespaces:
126235
/proc/sys/user/max_pid_namespaces:
126235
/proc/sys/user/max_time_namespaces:
126235
/proc/sys/user/max_user_namespaces:
126235
/proc/sys/user/max_uts_namespaces:
126235

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

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

Versions of packages flatpak depends on:
ii  adduser 3.134
ii  bubblewrap  0.8.0-2
ii  dbus [default-dbus-system-bus]  1.14.8-2~deb12u1
ii  fuse3   3.14.0-4
ii  libappstream4   0.16.1-2
ii  libarchive133.6.2-1
ii  libc6   2.36-9+deb12u1
ii  libcurl3-gnutls 7.88.1-10+deb12u1
ii  libdconf1   0.40.0-4
ii  libfuse3-3  3.14.0-4
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libglib2.0-02.74.6-2
ii  libgpgme11  1.18.0-3+b1
ii  libjson-glib-1.0-0  1.6.6-1
ii  libmalcontent-0-0   0.11.0-4
ii  libostree-1-1   2022.7-2
ii  libpolkit-agent-1-0 122-3
ii  libpolkit-gobject-1-0   122-3
ii  libseccomp2 2.5.4-1+b3
ii  libsystemd0 252.12-1~deb12u1
ii  libxau6 1:1.0.9-1
ii  libxml2 2.9.14+dfsg-1.3~deb12u1
ii  libzstd11.5.4+dfsg2-5
ii  xdg-dbus-proxy  0.1.4-3

Versions of packages flatpak recommends:
ii  ca-certificates  20230311
ii  desktop-file-utils   0.26-1
ii  gtk-update-icon-cache3.24.37-2
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   252.12-1~deb12u1
ii  p11-kit  0.24.1-2
ii  polkitd  122-3
ii  shared-mime-info 2.2-1
ii  xdg-desktop-portal   1.16.0-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]  5.27.5-2
ii  xdg-user-dirs0.18-1

Versions of 

Bug#1042044: Additional information

[Vladimir Petko]

Dear Maintainers,

I have tried to fix gtk warnings but due to changes in the FileDialog
API there are significant changes that are best fixed upstream[1].
I have attached debdiff patch to disable those warnings for now.

Best regards,
 Vladimir.

[1] https://github.com/strongswan/strongswan/issues/1829


disable-gtk-warnings.debdiff
Description: Binary data

Bug#1042065: ltrace: [p]{read,write}[v]() handling, common *64() functions in modern glibc, [fl]seek[o]()/ftell[o](); requisite [u]llong; 20x speed optimisation in default config; format %b+bin() lens

[наб]

Control: retitle -1 ltrace: [p]{read,write}[v]() handling, common *64() 
functions in modern glibc, [fl]seek[o]()/ftell[o](); requisite [u]llong; 20x 
speed optimisation in default config; format %b+bin() lens and %w[f]32x; 
splice/c_f_r/sendfile[64] formatting; useful __errno_location; %config lines 
not limited to 1kB; pipe[2]() with fds; sysconf(); %m[un]map[64](); operator 
new/delete; ; another ~10%

I'm attaching everything, since I fixed some documentation fucky-wuckies
from the earlier ones. 0018-0021 are new, and turn
  $ grep pipe ll
  pipe2(0x7ffcd6d7baf0, 0x8, 0x7ffcd6d7bb70, 0x7ffcd6d7bb70)
   = 0
  $ grep -e mmap -e sysconf ll
  sysconf(30, 0, 1, 0x393c) 
   = 4096
  mmap64(0, 0x3d3c, 1, 2)   
   = 0x7fe67b29c000
into
  $ grep pipe ll
  pipe2([3, 4], 0x8)
   = 0
  $ grep -e mmap -e sysconf ll
  sysconf(_SC_PAGE_SIZE)
   = 4096
  mmap64(0, 15676, 0b1, 0x2, 0, 4096)   
   = 0x7fa1b27ff000

regex.h suite looks like:
  regcomp(0x7fff5ee83120, ";", 0b100)   
   = REG_OK
  
  regexec(0x7fff5ee83040, "\nint   SYS_access(string,octal);"..., 1, [{0, 31}], 
0b111) = REG_NOMATCH
  regexec(0x7fff5ee83040, ";\nint   SYS_access(string,octal)"..., 1, [{0, 32}], 
0b111) = REG_OK
  
  regcomp(0x7ffece59ee70, "\\(", 0b100) 
   = REG_EPAREN
  regerror(REG_EPAREN, 0x7ffece59ee70, nil, 0)  
   = 18
  malloc(18)
   = 0x5604c35c2140
  regerror(REG_EPAREN, 0x7ffece59ee70, "Unmatched ( or \\(", 18)
   = 18

And function lookups are sped up approximately ten-fold
(3μs -> 300ns on a hit (depending on the access pattern, of course) and
 12μs -> 600ns on a miss)
which translates to an approximately 10% (roughly, maybe, it's difficult
to measure) speed-up depending on the program:
  $ hyperfine '/bin/ltrace -o/dev/null -F /etc/ltrace.conf ls' \
 './ltrace -o/dev/null -F /etc/ltrace.conf ls'
  Benchmark 1: /bin/ltrace -o/dev/null -F /etc/ltrace.conf ls
Time (mean ± σ): 545.6 ms ±  75.8 ms[User: 153.6 ms, System: 350.1 
ms]
Range (min … max):   473.1 ms … 722.5 ms10 runs
  
  Benchmark 2: ./ltrace -o/dev/null -F /etc/ltrace.conf ls
Time (mean ± σ): 447.1 ms ±  36.7 ms[User: 94.6 ms, System: 329.8 
ms]
Range (min … max):   412.8 ms … 516.4 ms10 runs
  
  Summary
'./ltrace -o/dev/null -F /etc/ltrace.conf ls' ran
  1.22 ± 0.20 times faster than '/bin/ltrace -o/dev/null -F 
/etc/ltrace.conf ls'
vs
  $ hyperfine '/bin/ltrace -F /etc/ltrace.conf -o/dev/null  
~/code/voreutils/out/cmd/tac -rs \; < etc/ltrace.conf' \
 './ltrace -F /etc/ltrace.conf -o/dev/null  
~/code/voreutils/out/cmd/tac -rs \; < etc/ltrace.conf'
  Benchmark 1: /bin/ltrace -F /etc/ltrace.conf -o/dev/null  
~/code/voreutils/out/cmd/tac -rs \; < etc/ltrace.conf
Time (mean ± σ):  3.631 s ±  0.117 s[User: 1.087 s, System: 2.334 s]
Range (min … max):3.516 s …  3.886 s10 runs
  
  Benchmark 2: ./ltrace -F /etc/ltrace.conf -o/dev/null  
~/code/voreutils/out/cmd/tac -rs \; < etc/ltrace.conf
Time (mean ± σ):  3.113 s ±  0.169 s[User: 0.659 s, System: 2.274 s]
Range (min … max):2.934 s …  3.496 s10 runs
  
  Summary
'./ltrace -F /etc/ltrace.conf -o/dev/null  ~/code/voreutils/out/cmd/tac -rs 
\; < etc/ltrace.conf' ran
  1.17 ± 0.07 times faster than '/bin/ltrace -F /etc/ltrace.conf 
-o/dev/null  ~/code/voreutils/out/cmd/tac -rs \; < etc/ltrace.conf'
From: =?utf-8?b?0L3QsNCx?= 
Date: Tue, 25 Jul 2023 21:20:32 +0200
Subject: Add llong/ullong. Tested on i686/amd64

---
 expr.c |  6 +++---
 expr.h |  4 ++--
 lens_default.c | 14 ++
 printf.c   | 10 +-
 read_config_file.c |  4 
 sysdeps/linux-gnu/ia64/fetch.c |  4 
 sysdeps/linux-gnu/m68k/fetch.c |  2 ++
 sysdeps/linux-gnu/ppc/fetch.c  |  2 ++
 sysdeps/linux-gnu/ppc/trace.c  |  6 ++
 sysdeps/linux-gnu/s390/fetch.c |  2 ++
 sysdeps/linux-gnu/s390/trace.c |  6 ++
 sysdeps/linux-gnu/x86/fetch.c  | 15 ---
 sysdeps/linux-gnu/x86/trace.c  |  6 ++
 type.c | 25 ++---
 type.h |  2 ++
 value.c| 16 
 value.h|  4 ++--
 zero.c |  2 +-
 18 files changed, 99 insertions(+), 31 deletions(-)

diff --git a/expr.c b/expr.c
index 32860fd..01ce4c6 100644
--- a/expr.c
+++ b/expr.c
@@ -246,7 +246,7 @@ 

Bug#1006927: /usr/bin/dh_fixperms: please don't make all files executable in subdirectories of /usr/libexec

[Matthias Klose]

also seen in gcc-13, dh_fixperms "fixes" the permissions for liblto_plugin.so, 
and then lintian complains about that.

Bug#1042979: subversion-tools: psvn.el does not work with emacs 29.1

[James McCoy]

On Fri, Aug 04, 2023 at 01:18:15AM +0900, OHURA Makoto wrote:
> After upgrading emacs 29.1, psvn.el does not work fine.  Emacs 29.1
> doesn't support the function, toggle-read-only.  Use read-only-mode.
> I attach a patch to this e-mail.

Thanks for the patch!

> --- psvn.el.old   2023-08-04 01:00:23.460477204 +0900
> +++ psvn.el   2023-08-04 00:28:50.764059785 +0900
> @@ -2248,7 +2248,7 @@
>(setq mode-line-process 'svn-status-mode-line-process)
>(run-hooks 'svn-status-mode-hook)
>(let ((view-read-only nil))
> -(toggle-read-only 1)))
> +(read-only-mode 1)))

If we make this change, then it won't work with older emacs versions.
I'd like to send the fix upstream, but would need this resolved first.

Is it possible to make these changes compatible with both old and new
emacs?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1026965: Error messages still there despite a full system upgrade in Windows

[Al Ma]

After having run
System Update (which upgraded IME Software) made by Lenovo and Windows Update 
(which upgraded Windows 11 including its drivers) made by Microsoft, I still 
see the error messages in the Debian journal. (Some ACPI-related stuff also 
appears on the screen during boot, but it's a bit hard to see because this 
vanishes quickly.)

Bug#1042998: kresd aborting (SIGABRT) at mdb.c:2433: Assertion 'mp->mp_pgno != pgno' failed in mdb_page_touch

[Daniel Kahn Gillmor]

Package: knot-resolver
Version: 5.3.1-1+deb11u1

An armhf bullseye machine received several rapid and unexpected power
outages, automatically rebooting each time, with kresd opening
immediately on boot.

after the third boot, I see these mdb errors and warnings, resulting in
a permanent failure of the service to start:

Aug 03 12:55:38 host systemd[1]: Started Knot Resolver daemon.
Aug 03 12:55:39 host kresd[441]: [ta_update] refreshing TA for .
Aug 03 12:55:49 host kresd[441]: [ta_update] active refresh failed for . with 
rcode: 2
Aug 03 12:55:49 host kresd[441]: [ta_update] next refresh for . in 2.4 hours
Aug 03 12:56:18 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:18 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:18 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:19 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:19 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:19 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:20 host kresd[441]: [tls] Using ephemeral TLS credentials
Aug 03 12:56:20 host kresd[441]: [tls] RFC 7858 OOB key-pin (0): pin-sha256=""
Aug 03 12:56:21 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:21 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:21 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:25 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:25 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:25 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: [cache] LMDB error: MDB_CURSOR_FULL: Internal 
error - cursor stack limit reached
Aug 03 12:56:32 host kresd[441]: mdb.c:2433: Assertion 'mp->mp_pgno != pgno' 
failed in mdb_page_touch()
Aug 03 12:56:32 host systemd[1]: kresd@1.service: Main process exited, 
code=killed, status=6/ABRT
Aug 03 12:56:32 host systemd[1]: kresd@1.service: Failed with result 'signal'.
Aug 03 12:56:32 host systemd[1]: kresd@1.service: Scheduled restart job, 
restart counter is at 1.
Aug 03 12:56:32 host systemd[1]: Stopped Knot Resolver daemon.
Aug 03 12:56:32 host systemd[1]: Starting Knot Resolver daemon...
Aug 03 12:56:32 host kresd[496]: mdb.c:2433: Assertion 'mp->mp_pgno != pgno' 
failed in mdb_page_touch()
Aug 03 12:56:32 host systemd[1]: kresd@1.service: Main process exited, 
code=killed, status=6/ABRT
Aug 03 12:56:32 host systemd[1]: kresd@1.service: Failed with result 'signal'.
Aug 03 12:56:32 host systemd[1]: Failed to start Knot Resolver daemon.
Aug 03 12:56:33 host systemd[1]: 

Bug#1041745: smartd[…]: Device: /dev/nvme0, number of Error Log entries increased from … to …

[Al Ma]

Thanks for looking into this. The solid-state–memory device in question is 
Samsung SSD 970 EVO 1TB, S/N:…, FW:2B2QEXE7, 1.00 TB. It's no longer sold on 
samsung.com but still sold as new on amazon (ASIN B07CGJNLBB; the Web site says 
it has been sold there since April 24, 2018). So yes, given the dates in 
https://en.wikipedia.org/wiki/NVM_Express#Specifications 
https://en.wikipedia.org/wiki/NVM_Express#Specifications, the drive might be 
aware of the NVMe 1.2 or 1.3 specification but, again hypothetically, not 1.4 
or even 2.0. I wouldn't know how to check this, and firmware upgrades seem 
unavailable ( https://semiconductor.samsung.com/consumer-storage/support/tools/ 
http://semiconductor.samsung.com/consumer-storage/support/tools/ mentions the 
same version 2B2QEXE7). Just in case this helps, the motherboard is Asus WS 
C422 PRO/SE.
Here is some debugging data:
$ sudo nvme error-log -e 2 /dev/nvme0
Error Log Entries for device:nvme0 entries:2
.
Entry[ 0]
.
error_count     : 1885
sqid            : 0
cmdid           : 0x14
status_field    : 0x2002(Invalid Field in Command: A reserved coded value or an 
unsupported value in a defined field)
phase_tag       : 0
parm_err_loc    : 0x
lba             : 0
nsid            : 0
vs              : 0
trtype          : The transport type is not indicated or the error is not 
transport related.
cs              : 0
trtype_spec_info: 0
.
Entry[ 1]
.
error_count     : 0
sqid            : 0
cmdid           : 0
status_field    : 0(Successful Completion: The command completed without error)
phase_tag       : 0
parm_err_loc    : 0
lba             : 0
nsid            : 0
vs              : 0
trtype          : The transport type is not indicated or the error is not 
transport related.
cs              : 0
trtype_spec_info: 0
.
$ sudo nvme list
Node                  Generic               SN                   Model          
                          Namespace Usage                      Format           
FW Rev
- -  
 - -- 
 
/dev/nvme0n1          /dev/ng0n1            Anonymized S.N.      Samsung SSD 
970 EVO 1TB                  1         135,04  GB /   1,00  TB    512   B +  0 
B   2B2QEXE7
$ sudo nvme error-log -e 2 /dev/nvme0
Error Log Entries for device:nvme0 entries:2
.
Entry[ 0]
.
error_count     : 1885
sqid            : 0
cmdid           : 0x14
status_field    : 0x2002(Invalid Field in Command: A reserved coded value or an 
unsupported value in a defined field)
phase_tag       : 0
parm_err_loc    : 0x
lba             : 0
nsid            : 0
vs              : 0
trtype          : The transport type is not indicated or the error is not 
transport related.
cs              : 0
trtype_spec_info: 0
.
Entry[ 1]
.
error_count     : 0
sqid            : 0
cmdid           : 0
status_field    : 0(Successful Completion: The command completed without error)
phase_tag       : 0
parm_err_loc    : 0
lba             : 0
nsid            : 0
vs              : 0
trtype          : The transport type is not indicated or the error is not 
transport related.
cs              : 0
trtype_spec_info: 0
.
As you see, the output is slightly different from that in 
https://github.com/linux-nvme/libnvme/issues/550 
https://github.com/linux-nvme/libnvme/issues/550, and `nvme list` does not 
increase error_count (or at least not directly). If there's anything else I can 
help with, please let me know.
Gratefully,
AlMa

Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

[Vincent Lefevre]

On 2023-08-03 16:52:07 +0200, Sven Joachim wrote:
> On 2023-08-02 15:51 +0200, Vincent Lefevre wrote:
> > Package: aptitude
> > Version: 0.8.13-5
> > Severity: normal
> >
> > When I use "C" (View a package's changelog) on clang-15 from the
> > aptitude TUI, I get a warning that is immediately erased, so that
> > it is impossible to read it.
> >
> > I suppose that aptitude should redirect stderr from
> > aptitude-changelog-parser so that it can display its contents
> > (when non empty) in a clear way.
> 
> It should prevent these errors from showing up in the first place.

If aptitude knows what to do (or may ignore the issue), yes.

> See #967911, which has been tagged "pending" almost three years ago. :-(

I forgot about this one.

> Yes, the clang-15 changelog entry for version 1:15.0.7-2 is not properly
> terminated.

OK, I've just reported a bug for this:

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

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

Bug#1042997: llvm-toolchain-15: Debian's changelog entry for 1:15.0.7-2 is not properly terminated

[Vincent Lefevre]

Source: llvm-toolchain-15
Severity: minor

Debian's changelog contains:


llvm-toolchain-15 (1:15.0.7-2) unstable; urgency=medium

  [ Sylvestre Ledru ]
  * Yeah, we would like to have this version in bookworm
(Closes: #1032316)
  * Adjust some lintian overrides
  * Disable flang on s390x. Seems that it is breaking

  [ Gianfranco Costamagna ]
  * Update print lldb python patch, following what was done
in automake for newer python

  [ Samuel Thibault ]
  * Fix disabling amdgpu on non-Linux.

llvm-toolchain-14 (1:14.0.6-13) unstable; urgency=medium


The 1:15.0.7-2 part is not properly terminated. This causes a warning
message with aptitude:

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

It seems that aptitude needs to parse the changelog (and other tools
might as well). There is a risk to misinterpret the data.

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

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

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

Bug#1042996: kodi: Kodi autoinstalls 77 unremovable language addons

[Steve Mcqueen]

Package: kodi
Version: 2:20.1+dfsg-1
Severity: normal
Tags: l10n
X-Debbugs-Cc: stevemcqu...@mailinator.com

Dear Maintainer,

Kodi will auto-install 77 (assumedly all) language addons automatically.
I am unable to remove them in the kodi addons interface, only disable
them. Uninstall is grayed out. If I try to delete them from ~/.kodi,
they just auto-install themselves again. I'm only interested in one
language addon, en_us and the rest really clutter the addons menu. 
I can't find a setting anywhere to choose or stop this.

Steps to reproduce:
1. Use Debian bookworm
2. apt install kodi (or use gnome/kde installer)
3. open kodi, go to addons, watch it auto-download 77 languages addons.
4. Choose any of them, see that uninstall is greyed out.
5. quit kodi
6. rm -rf ~/.kodi/addons/resource.language.XXX (pick one as an example)
7. start kodi again, watch it re-download the deleted language addon.

Expected behavior: Kodi either only installs my default language (en_us
for me), or at least allows me to remove the other ones. I believe this
is how it behaves in other distros.

Thank you!

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

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

Versions of packages kodi depends on:
ii  kodi-bin   2:20.1+dfsg-1
ii  kodi-data  2:20.1+dfsg-1

Versions of packages kodi recommends:
ii  kodi-repository-kodi [kodi-repository]  2:20.1+dfsg-1
ii  kodi-visualization-spectrum 20.2.0+ds1-1

kodi suggests no packages.

-- no debconf information

Bug#1042995: Provide functional graphical systemd session

[Bas Wijnen]

Package: autopkgtest
Version: 5.28
Severity: wishlist
X-Debbugs-Cc: wij...@debian.org

Hi,

I've written package tests for openmsx-catapult. That's a graphical program,
which I'm testing using dogtail. Dogtail needs an X11 environment with
accessibility enabled. To enable accessibility, the systemd session must be set
up correctly. Simply running xvfb-run is not good enough.

While I can't say exactly what is needed, because I haven't managed to make it
work so far, I do know that it doesn't seem to be something that should be
implemented in every package that provides a graphical interface. Instead, I
think it would make sense to have a Restriction in autopkgtest, similar to
needs-root, which ensures that the testbed has a functional graphical
environment, usable for programs such as dogtail.

Thanks,
Bas

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.6.1
ii  libdpkg-perl1.21.22
ii  procps  2:4.0.2-3
ii  python3 3.11.2-1+b1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.31-1.2

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  lxc  
pn  lxd  
ii  ovmf 2022.11-6
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.5
ii  qemu-efi-aarch64 2022.11-6
ii  qemu-efi-arm 2022.11-6
pn  qemu-system  
ii  qemu-utils   1:7.2+dfsg-7+deb12u1
ii  schroot  1.6.13-3+b2
ii  util-linux   2.38.1-5+b1
ii  vmdb20.27+really.0.26-1
pn  zerofree 

-- no debconf information

Bug#1042994: libreoffice-draw experimental: LibreOffice Draw (and LO Impress) do not start

[Thomas Florek]

Package: libreoffice-draw
Version: 4:7.6.0~rc2-2
Severity: important
X-Debbugs-Cc: thflo...@gmail.com

Dear Maintainer,

Launching LO Draw (and also LO Impress) did not work, either from the 
plasma desktop or from the console.

No windows appeared on the desktop and no messages appeared on the console.


Versions of packages libreoffice-draw depends on:
ii  libavahi-client3  0.8-10
ii  libavahi-common3  0.8-10
ii  libc6 2.37-6
ii  libcdr-0.1-1  0.1.7-1
ii  libdbus-1-3   1.14.8-2
ii  libfreehand-0.1-1 0.1.2-3
ii  libgcc-s1 13.2.0-1
ii  libglib2.0-0  2.76.4-4
ii  libmspub-0.1-10.1.4-3+b3
ii  libmwaw-0.3-3 0.3.22-1
ii  libodfgen-0.1-1   0.1.8-2
ii  libpagemaker-0.0-00.0.4-1
ii  libqxp-0.0-0  0.0.2-1+b3
ii  libreoffice-common4:7.6.0~rc2-2
ii  libreoffice-core  4:7.6.0~rc2-2
ii  libreoffice-uiconfig-draw 4:7.6.0~rc2-2
ii  libreoffice-uiconfig-impress  4:7.6.0~rc2-2
ii  librevenge-0.0-0  0.0.5-3
ii  libstaroffice-0.0-0   0.0.7-1
ii  libstdc++613.2.0-1
ii  libuno-cppu3  4:7.6.0~rc2-2
ii  libuno-cppuhelpergcc3-3   4:7.6.0~rc2-2
ii  libuno-sal3   4:7.6.0~rc2-2
ii  libuno-salhelpergcc3-34:7.6.0~rc2-2
ii  libvisio-0.1-10.1.7-1+b3
ii  libwpg-0.3-3  0.3.4-3
ii  libxml2   2.9.14+dfsg-1.3
ii  libzmf-0.0-0  0.0.2-1+b5
ii  ucf   3.0043+nmu1
ii  uno-libs-private  4:7.6.0~rc2-2

libreoffice-draw recommends no packages.

libreoffice-draw suggests no packages.

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.14.1-4
ii  fonts-opensymbol4:102.12+LibO7.6.0~rc2-2
ii  libabsl20220623 20220623.1-1
ii  libboost-locale1.74.0   1.74.0+ds1-22
ii  libc6   2.37-6
ii  libcairo2   1.16.0-7
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1.1
ii  libclucene-core1v5  2.3.3.4+dfsg-1.1
ii  libcups22.4.2-5
ii  libcurl3-gnutls 7.88.1-11
ii  libdbus-1-3 1.14.8-2
ii  libdconf1   0.40.0-4
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.10-1
ii  libexpat1   2.5.0-2
ii  libexttextcat-2.0-0 3.4.6-1
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.13.0+dfsg-1
ii  libgcc-s1   13.2.0-1
ii  libglib2.0-02.76.4-4
ii  libgpgmepp6 1.18.0-3+b1
ii  libgraphite2-3  1.3.14-1
ii  libgstreamer-plugins-base1.0-0  1.22.5-dmo1
ii  libgstreamer1.0-0   1.22.4-1
ii  libharfbuzz-icu08.0.1-1
ii  libharfbuzz0b   8.0.1-1
ii  libhunspell-1.7-0   1.7.2+really1.7.2-10
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.10-1
ii  libicu7272.1-3
ii  libjpeg62-turbo 1:2.1.5-2
ii  liblcms2-2  2.14-2
ii  libldap-2.5-0   2.5.13+dfsg-5
ii  libmythes-1.2-0 2:1.2.5-1
ii  libnspr42:4.35-1.1
ii  libnss3 2:3.91-1
ii  libnumbertext-1.0-0 1.0.11-1
ii  libopenjp2-72.5.0-2
ii  liborcus-0.18-0 0.18.1-2
ii  liborcus-parser-0.18-0  0.18.1-2
ii  libpng16-16 1.6.40-1
ii  libpoppler126   22.12.0-2+b1
ii  libraptor2-02.0.16-3
ii  librdf0 1.0.17-3
ii  libreoffice-common  4:7.6.0~rc2-2
ii  librevenge-0.0-00.0.5-3
ii  libsm6  2:1.2.3-1
ii  libstdc++6  13.2.0-1
ii  libtiff64.5.1+git230720-1
ii  libuno-cppu34:7.6.0~rc2-2
ii  libuno-cppuhelpergcc3-3 4:7.6.0~rc2-2
ii  libuno-sal3 4:7.6.0~rc2-2
ii  libuno-salhelpergcc3-3  4:7.6.0~rc2-2
ii  libwebp71.2.4-0.2
ii  libx11-62:1.8.6-1
ii  libx11-xcb1 2:1.8.6-1
ii  libxext62:1.3.4-1+b1
ii  libxinerama12:1.1.4-3
ii  libxml2 2.9.14+dfsg-1.3
ii  libxmlsec1  1.2.37-2
ii  libxmlsec1-nss  1.2.37-2
ii  libxrandr2  2:1.5.2-2+b1
ii  libxrender1 1:0.9.10-1.1
ii  libxslt1.1  1.1.35-1
ii  libzxing2   1.4.0-3+b1
ii  uno-libs-private4:7.6.0~rc2-2
ii  ure 4:7.6.0~rc2-2
ii  zlib1g  

Bug#1042993: dkms: DKMS fails to build amd64 kernel module in i386 userland

[Stefan Monnier]

Package: dkms
Version: 3.0.11-3
Severity: normal

Dear Maintainer,

My machine is running Debian testing i386 but with an amd64 kernel
(to make better use of my 8GB of RAM).  I also have `dkms` and `tp-smapi-dkms`
installed.

Until recently this worked fine and built the `tp-smapi` kernel module
for my `amd64` kernel.  But now installation of the
`linux-image-6.4.0-1-amd64:amd64` kernel encounters problems when dkms
tries to build the dkms package.

More specifically I get the following error:

dkms: running auto installation service for kernel 6.4.0-1-amd64.
Sign command: /lib/modules/6.4.0-1-amd64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j2 KERNELRELEASE=6.4.0-1-amd64 -C /lib/modules/6.4.0-1-amd64/build
M=/var/lib/dkms/tp_smapi/0.43/build HDAPS=1...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.4.0-1-amd64 (x86_64)
Consult /var/lib/dkms/tp_smapi/0.43/build/make.log for more information.
dkms autoinstall on 6.4.0-1-amd64/x86_64 failed for tp_smapi(10)
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.

and `/var/lib/dkms/tp_smapi/0.43/build/make.log` says:

DKMS make.log for tp_smapi-0.43 for kernel 6.4.0-1-amd64 (x86_64)
jeu 03 aoû 2023 18:35:09 EDT
make : on entre dans le répertoire « /usr/src/linux-headers-6.4.0-1-amd64 »
  CC [M]  /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o
/bin/bash: ligne 1: x86_64-linux-gnu-gcc-13 : commande introuvable
make[1]: *** [/usr/src/linux-
headers-6.4.0-1-common/scripts/Makefile.build:257 :
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o] Erreur 127
make[1]: *** Attente des tâches non terminées
  CC [M]  /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o
/bin/bash: ligne 1: x86_64-linux-gnu-gcc-13 : commande introuvable
make[1]: *** [/usr/src/linux-
headers-6.4.0-1-common/scripts/Makefile.build:257 :
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o] Erreur 127
make: *** [/usr/src/linux-headers-6.4.0-1-common/Makefile:2051 :
/var/lib/dkms/tp_smapi/0.43/build] Erreur 2
make : on quitte le répertoire « /usr/src/linux-headers-6.4.0-1-amd64 »


-- Stefan


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 dkms depends on:
ii  build-essential  12.10
ii  dpkg-dev 1.21.22
ii  gcc [c-compiler] 4:13.1.0-4
ii  gcc-10 [c-compiler]  10.4.0-7
ii  gcc-11 [c-compiler]  11.4.0-2
ii  gcc-12 [c-compiler]  12.3.0-6
ii  gcc-13 [c-compiler]  13.1.0-9
ii  gcc-9 [c-compiler]   9.3.0-22
ii  kmod 30+20230519-1
ii  lsb-release  12.0-2
ii  make 4.3-4.1
ii  patch2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot 1.32.1-1
iu  linux-headers-amd64 [linux-headers-generic]  6.4.4-1
ii  sudo 1.9.14p2-1

Versions of packages dkms suggests:
ii  e2fsprogs  1.47.0-2
ii  menu   2.1.50

-- Configuration Files:
/etc/modprobe.d/dkms.conf changed:


-- no debconf information

Bug#996905: pms: diff for NMU version 0.42-1.1

[gregor herrmann]

Control: tags 996905 + patch
Control: tags 996905 + pending


Dear maintainer,

Daniel Gröber has prepared an NMU for pms (versioned as 0.42-1.1) and
I've uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru pms-0.42/debian/changelog pms-0.42/debian/changelog
--- pms-0.42/debian/changelog	2013-08-11 22:46:48.0 +0200
+++ pms-0.42/debian/changelog	2023-07-05 23:17:35.0 +0200
@@ -1,3 +1,14 @@
+pms (0.42-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS: error: format not a string literal and no format arguments
+[-Werror=format-security]" by selectively demoting -Wformat-security to
+warning (Closes: #996905)
+  * Fix time() undeclared error when building with gcc-12
+  * Upgrade debhelper compat to 11 and fix related lintian warnings
+
+ -- Daniel Gröber   Wed, 05 Jul 2023 23:17:35 +0200
+
 pms (0.42-1) unstable; urgency=low
 
   * New upstream release (Closes: #612192).
diff -Nru pms-0.42/debian/compat pms-0.42/debian/compat
--- pms-0.42/debian/compat	2013-08-11 21:14:52.0 +0200
+++ pms-0.42/debian/compat	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru pms-0.42/debian/control pms-0.42/debian/control
--- pms-0.42/debian/control	2013-08-11 22:40:45.0 +0200
+++ pms-0.42/debian/control	2023-07-05 23:17:35.0 +0200
@@ -1,9 +1,10 @@
 Source: pms
 Section: sound
-Priority: extra
+Priority: optional
 Maintainer: Alejandro Garrido Mota 
-Build-Depends: debhelper (>= 9), gettext, gettext-base, libgettextpo0, libncurses5-dev,
-   libmpd-dev, libncursesw5-dev, libglib2.0-dev, gnulib, libboost-regex-dev
+Build-Depends: debhelper-compat (= 11),
+   gettext, gettext-base, libgettextpo0, libncurses-dev,
+   libmpd-dev, libglib2.0-dev, gnulib, libboost-regex-dev
 Standards-Version: 3.9.4
 Homepage: http://pms.sourceforge.net
 
diff -Nru pms-0.42/debian/patches/Fix-autotools-errors.patch pms-0.42/debian/patches/Fix-autotools-errors.patch
--- pms-0.42/debian/patches/Fix-autotools-errors.patch	1970-01-01 01:00:00.0 +0100
+++ pms-0.42/debian/patches/Fix-autotools-errors.patch	2023-07-05 23:17:35.0 +0200
@@ -0,0 +1,24 @@
+Description: Fix autotools errors
+Author: Daniel Gröber 
+--- a/configure.ac
 b/configure.ac
+@@ -13,7 +13,7 @@ AC_ARG_ENABLE([regex],
+esac])
+ 
+ AC_PREFIX_PROGRAM(man)
+-AM_INIT_AUTOMAKE([-Wall -Werror foreign])
++AM_INIT_AUTOMAKE([-Wall -Werror subdir-objects foreign])
+ AC_PROG_CXX
+ AC_CONFIG_HEADERS([config.h])
+ AC_CONFIG_FILES([Makefile po/Makefile.in])
+--- a/Makefile.am
 b/Makefile.am
+@@ -3,7 +3,7 @@ man_MANS = pms.1
+ EXTRA_pms_SOURCES = src/action.h src/color.h src/command.h src/config.h src/conn.h src/display.h src/input.h src/list.h src/song.h src/types.h src/libmpdclient.h src/i18n.h src/topbar.h src/pms.h src/settings.h src/field.h src/mycurses.h src/mediator.h src/message.h src/filter.h
+ EXTRA_DIST = config.rpath m4/ChangeLog  pms.1 po
+ pms_SOURCES = src/action.cpp src/color.cpp src/command.cpp src/config.cpp src/conn.cpp src/display.cpp src/input.cpp src/list.cpp src/pms.cpp src/song.cpp src/libmpdclient.c src/field.cpp src/settings.cpp src/mediator.cpp src/message.cpp
+-CXXFLAGS += \
++AM_CXXFLAGS = \
+ 	@GLIB_CFLAGS@ \
+ 	-DLOCALE_DIR=\""$(datadir)/locale"\"
+ 
diff -Nru pms-0.42/debian/patches/Fix-missing-ctime-include.patch pms-0.42/debian/patches/Fix-missing-ctime-include.patch
--- pms-0.42/debian/patches/Fix-missing-ctime-include.patch	1970-01-01 01:00:00.0 +0100
+++ pms-0.42/debian/patches/Fix-missing-ctime-include.patch	2023-07-05 23:17:35.0 +0200
@@ -0,0 +1,13 @@
+Description: Fix missing  include
+ Newer gcc version must have moved stuff around
+Author: Daniel Gröber 
+--- a/src/message.cpp
 b/src/message.cpp
+@@ -23,6 +23,7 @@
+ 
+ 
+ #include 
++#include 
+ #include 
+ #include "message.h"
+ 
diff -Nru pms-0.42/debian/patches/Ignore-format-security-FP.patch pms-0.42/debian/patches/Ignore-format-security-FP.patch
--- pms-0.42/debian/patches/Ignore-format-security-FP.patch	1970-01-01 01:00:00.0 +0100
+++ pms-0.42/debian/patches/Ignore-format-security-FP.patch	2023-07-05 23:17:35.0 +0200
@@ -0,0 +1,47 @@
+Description: Ignore -Wformat-security false positive
+ I don't see a reasonable way to rewrite this code without triggering this
+ warning since the dynamic format string being used here is controlled by the
+ user in the rc file.
+Author: Daniel Gröber 
+--- a/src/display.cpp
 b/src/display.cpp
+@@ -1700,6 +1700,7 @@ void colprint(pms_window * w, int y, int
+ 			{
+ fmt += 2;
+ output = "%%";
++#pragma GCC diagnostic warning "-Wformat-security"
+ wprintw(w->h(), 

Bug#1042218: ruby-moneta: FTBFS: ERROR: Test "ruby3.1" failed: cannot load such file -- ox/ox

[Leandro Cunha]

Control: reassign -1 src:ruby-ox

The package in question causing the problem is ruby-ox (on an upgrade
to 2.14.16-1 and solved with 2.14.17-1). The 'ox/ox' does not exist in
Debian's ruby-ox (but assumes it is in stalled as a gem and hence
loads 'ox/ox'), but there is only 'ox.so' and the solution was to
remove the require for 'ox/ox'. Require relative, according to the
documentation[1], when it returns false for a directory not found, it
returns a load error with a file not found message and does not search
for the file in the entire directory tree, unlike require that found
the archive 'ox.so'.

[1] https://ruby-doc.org/3.2.2/Kernel.html#method-i-require_relative

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1042992: micropython FTBFS with gcc 13

[Adrian Bunk]

Source: micropython
Version: 1.19.1+ds-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=micropython=riscv64=1.19.1%2Bds-1=1691093977=0

...
../py/stackctrl.c: In function ‘mp_stack_ctrl_init’:
../py/stackctrl.c:32:32: error: storing the address of local variable 
‘stack_dummy’ in ‘mp_state_ctx.thread.stack_top’ [-Werror=dangling-pointer=]
   32 | MP_STATE_THREAD(stack_top) = (char *)_dummy;
../py/stackctrl.c:31:18: note: ‘stack_dummy’ declared here
   31 | volatile int stack_dummy;
  |  ^~~
In file included from ../py/runtime.h:29,
 from ../py/stackctrl.c:27:
../py/mpstate.h:323:23: note: ‘mp_state_ctx’ declared here
  323 | extern mp_state_ctx_t mp_state_ctx;
  |   ^~~~
cc1: all warnings being treated as errors
make[2]: *** [../py/mkrules.mk:80: build/py/stackctrl.o] Error 1


micropython builds with the following two fixes:
https://github.com/micropython/micropython/commit/f1c6cb7725960487195daa5c5c196fd8d3563811
https://github.com/micropython/micropython/commit/32572439984e5640c6af46fbe7c27400c30112ce

Bug#1041562: dracut-core: dracut 059 produces broken unified kernel images with systemd 254

[Harlan Lieberman-Berg]

On Thu, 20 Jul 2023 23:16:43 +0200 Pawel Jasiak  wrote:
> Fixes are already in dracut master branch:
> - f32e95bcadbc5158843530407adc1e7b700561b1
> - 33a66ed04bdc30eccb172a0cd6dcc36d9d74f825

I confirm that these two patches fix the problem.  I've pushed up a
branch to Salsa (fix-uki) with the patch fuzzed and included, plus an
entry for d/changelog.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures

[M. Zhou]

Control: fixed -1 2021.9.0-2

I agree.

On Thu, 2023-08-03 at 00:32 +0200, Petter Reinholdtsen wrote:
> [M. Zhou]
> > The issue still exists with armel:
> > https://buildd.debian.org/status/package.php?p=onetbb
> 
> If so, this is a duplicate of 
> https://bugs.debian.org/1042009 >, which is about the armel
> issue,
> and should be closed.
> 

Bug#1042990: util-linux: FTBFS on hppa - #error Unknown target architecture

[John David Anglin]

Patch.

Regards,
Dave Anglin

--- ./include/audit-arch.h.save 2023-08-03 20:42:00.937401304 +
+++ ./include/audit-arch.h  2023-08-03 20:53:40.755627981 +
@@ -57,6 +57,12 @@
 #else
 #   define SECCOMP_ARCH_NATIVE AUDIT_ARCH_LOONGARCH64
 #endif
+#elif __hppa__
+#if __SIZEOF_POINTER__ == 4
+#   define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PARISC
+#else
+#   define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PARISC64
+#endif
 #else
 #error Unknown target architecture
 #endif


signature.asc
Description: PGP signature

Bug#1033156: gtg bug #1033156 investigation

[François Mazen]

Control: forwarded -1 https://github.com/getting-things-gnome/gtg/issues/950
Tags: patch


Thanks for the bug report, the problem have been identified upstream [1] and the
steps to reproduce are:
 - type "pay my taxes every:year" in the quick entry, then enter
 - close gtg
 - open gtg
 - open the task "pay my taxes"

Upstream proposes a patch [2] which adds a strftime method to the Date object.
It should be checked if it actually fixes the reported issue.

Best Regards,
François

[1] https://github.com/getting-things-gnome/gtg/issues/950
[2] https://github.com/getting-things-gnome/gtg/pull/943/files




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

Bug#1041612: Enhancing upstream version git awareness in Debian packages [was Re: Bug#1041612: RFS: dh-git/1.0 [ITP]]

[Nicholas D Steeves]

Hi Aidan,

Aidan  writes:

> OK, thank you for your quick feedback.
> If the implementation is fundamentally flawed then I think I'll just leave
> it.

I liked the user-facing UI of your proposed solution, I agree that it
can be hard to learn how to work with git in Debian packaging, and it
can be hard to understand Debian upstream version numbers.

  https://wiki.debian.org/Packaging/SourcePackage
  https://www.debian.org/doc/debian-policy/ch-source.html

Please note that many Debian packages are not child branches of upstream
git history.  Instead they import tarballs of git snapshots, but that's
not to say that the metadata is lost!

Might you be interested in writing a decoder of Debian upstream versions
that already embed upstream git metadata?  Some examples of existing
versions are:

  1.1+14.gb364e08
  tagged_release + commits_since_that_release . letter_for_VCS_used hash
  
  0.0~git20220110.1ce338b
  a_release_has_not_been_tagged ~ VCS_used date . hash

  1.2.1+git20190611.dadb6258
  tagged_release + VCS_used date . hash

  https://manpages.debian.org/bookworm/dpkg-dev/deb-version.7.en.html

Between that, and the remote defined at
debian/upstream/metadata:Repository for many packages, you can also
write a simple program that searches upstream history for a confirmed
match.

  https://wiki.debian.org/UpstreamMetadata

Upstreams possess their git history, so they can just run the decoder on
the Debian version.  ie:

  $ git-upstream-decoder 1.1+14.gb364e08-2
  b364e08009fe0062cf0927d8a0582fad5a12b8e7

The second third of this project could be the encoder, which

  1. Generates a Debian Policy-compliant upstream version with embedded
  committish info (see the three examples included in this email).  Some
  examples of how to do this can be found in dh-make-golang.
  2. For workflows where upstream git history is merged, the encoder
  could also make it easier to tag an upstream committish for Debian
  use, which is just an extension of solution at #1.
  3. Generates a watch file that uses mode=git, and that encodes the
  upstream committish into the Debian upstream version.  If I remember
  correctly uscan already has built-in support for a format compatible
  with git-describe.

The final third letting people know about your tool, encouraging
upstreams to use it, etc.  One problem I noticed with dh-git is that it
would require upstreams to have access to a Debian system.  Not all do,
and not all want to.

Please let me know if you're interested, please consider CCing your
reply (in-line style, not top-posting) to debian-de...@debian.org, and
please keep me in CC.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1042991: RM: adapta-gtk-theme -- RoQA; RC-Buggy; Unmaintained; Dead Upstream

[Boyuan Yang]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: by...@debian.org prof.franciscar...@gmail.com
Severity: normal


Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/1041364 , package adapta-gtk-theme has a
dead upstream, missed last Debian Stable release, is currently RC-buggy. The 
listed
package maintainer (in CC list) did not respond to the previous emails as well
in the last 2 years.

As a result, I believe this package should be removed from Debian archive.
Please let me know if you have any questions.

Thanks,
Boyuan Yang




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

Bug#1040731: wslay: autopkgtest failure due to new CMake deprecation warning

[Anton Gladky]

Hi Timo,

thanks a lot for this upload! I have just prepared a
"normal" update, including your changes and some
others. If you want, you can cancel NMU or it will be
automatically rejected by the system.

Best regards


Anton


Am Di., 1. Aug. 2023 um 11:21 Uhr schrieb Timo Röhling :

> Hi Anton,
>
> On Fri, 21 Jul 2023 21:13:56 +0200 Anton Gladky  wrote:
> > Thanks a lot for the MR and update.
> > I will prepare an update and upload it in one week. If it's ok for you.
> > Otherwise, please NMU.
> I have just uploaded an NMU to DELAYED/5 and pushed the corresponding
> commits to the branch nmu-bug-1040731. Chris' solution is probably
> cleaner (I just hot-patched the CMakeLists.txt in autopkgtest), so
> if you have time this week, feel free to upload your own release,
> and I will cancel my upload.
>
>
> Cheers
> Timo
>
> --
> ⢀⣴⠾⠻⢶⣦⠀   ╭╮
> ⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
> ⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
> ⠈⠳⣄   ╰╯
>

Bug#1042990: util-linux: FTBFS on hppa - #error Unknown target architecture

[John David Anglin]

Source: util-linux
Version: 2.39.1-3
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails here:
gcc -DHAVE_CONFIG_H -I.  -include config.h -I./include 
-DLOCALEDIR=\"/usr/share/locale\" -D_PATH_RUNSTATEDIR=\"/run\" 
-D_PATH_SYSCONFSTATICDIR=\"/usr/lib\"   -Wdate-time -D_FORTIFY_SOURCE=2 
-fsigned-char -fno-common -Wall -Wextra -Waddress-of-packed-member 
-Wdiscarded-qualifiers -Wimplicit-function-declaration -Wmissing-declarations 
-Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs 
-Wno-missing-field-initializers -Wold-style-definition -Wpointer-arith 
-Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wtype-limits 
-Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable 
-Wunused-parameter -Wunused-result -Wunused-variable -Werror=sequence-point -g 
-O2 -ffile-prefix-map=/<>=. -Wformat -Werror=format-security -c -o 
tests/helpers/test_enosys.o tests/helpers/test_enosys.c
In file included from tests/helpers/test_enosys.c:30:
./include/audit-arch.h:61:6: error: #error Unknown target architecture
   61 | #error Unknown target architecture
  |  ^
make[5]: *** [Makefile:10077: tests/helpers/test_enosys.o] Error 1

See:
https://buildd.debian.org/status/fetch.php?pkg=util-linux=hppa=2.39.1-3=1690505350=0

The audit architecture defines for hppa are defined in 
/usr/include/linux/audit.h:

#define AUDIT_ARCH_PARISC   (EM_PARISC)
#define AUDIT_ARCH_PARISC64 (EM_PARISC|__AUDIT_ARCH_64BIT)

Please add the architecture defines for hppa to include/audit-arch.h.

Thanks,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.43+ (SMP w/4 CPU threads)
Locale: LANG=C, 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)

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:

Bug#1042968: emacs: Gnus unusable after upgrading to Emacs 29

[Florent Rougon]

Hi David,

David Bremner  wrote:

> Please try to duplicate the problem with "emacs -q". I suspect there is
> either some obsolete/broken third party package or just some personal
> configuration causing this problem.

You're right, the problem was in my .gnus.el which had a
(gnus-add-configuration …) call where the passed-in value came in part
from an old default value of `gnus-buffer-configuration' (that is where
the `gnus-carpal' stuff came from). I did that setting once long ago and
didn't remember the details. Sorry I had grepped my ~/.emacs.d and
~/lisp but completely forgot to do it on ~/.gnus.el!

[ BTW, I misunderstood part of the *Backtrace* buffer when I wrote that
  “clicking on the gnus-configure-frame “button” in the backtrace shows
  (defun gnus-configure-frame ...) in
  /usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz with *different code*”.
  The line of that buffer where I used RET was:

  gnus-configure-frame((cond (gnus-use-trees '(vertical 1.0 (article 1.0) 
(summary 0.25 point) (tree 0.25))) (t '(vertical 1.0 (article 1.0) (summary 
0.25 point) (if gnus-carpal '(summary-carpal 4))

  and I now understand that the big (cond (gnus-use-trees …)) is the
  `split' argument — a callable here — that was passed to
  `gnus-configure-frame'. ]

So, the problem is solved and was actually a PEBKAC case. Many thanks
for your help and sorry for the noise!

Regards

-- 
Florent

Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty

[Steve McIntyre]

On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote:
>Hi Michael,
>
>Cyril Brulebois  (2023-06-28):
>> Control: reassign -1 busybox-udeb 1:1.36.1-3
>
>[…]
>
>> With a local build, confirmed -3 is buggy, and that reverting only
>> busybox-udeb to -1 is sufficient to restore syslog support in the
>> installer.
>> 
>> Reassigning there; the GRUB thing can be filed separately once we have
>> actual information via syslog.
>
>A fix would be appreciated, we've got reports piling up about things we
>have no logs for.

After weeks with this breakage, I've just uploaded a minimal NMU to
fix it, reverting the syslog changes since -1. I've buit and tested
successfully locally.

Here's the NMU diff.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
diff -Nru busybox-1.36.1/debian/changelog busybox-1.36.1/debian/changelog
--- busybox-1.36.1/debian/changelog 2023-06-14 22:01:54.0 +0100
+++ busybox-1.36.1/debian/changelog 2023-08-03 21:22:44.0 +0100
@@ -1,3 +1,11 @@
+busybox (1:1.36.1-3.1) unstable; urgency=medium
+
+  * NMU
+  * Revert recent changes that have broken syslogd in d-i.
+Closes: #1039710
+
+ -- Steve McIntyre <93...@debian.org>  Thu, 03 Aug 2023 21:22:44 +0100
+
 busybox (1:1.36.1-3) unstable; urgency=medium
 
   * syslogd-avoid-nulling-devlog.patch - fix overriding dev/log
diff -Nru busybox-1.36.1/debian/patches/series 
busybox-1.36.1/debian/patches/series
--- busybox-1.36.1/debian/patches/series2023-06-14 21:55:08.0 
+0100
+++ busybox-1.36.1/debian/patches/series2023-08-03 21:22:44.0 
+0100
@@ -14,6 +14,7 @@
 platform-linux.diff
 fix-non-linux-build.patch
 #
-syslogd-decrease-stack-usage-50-bytes.patch
-syslogd-daemonize-after-init-make-errs-visible.patch
-syslogd-avoid-nulling-devlog.patch
+syslogd-fork-after-init-not-before.patch
+#syslogd-decrease-stack-usage-50-bytes.patch
+#syslogd-daemonize-after-init-make-errs-visible.patch
+#syslogd-avoid-nulling-devlog.patch
diff -Nru 
busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch 
busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
--- busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch  
1970-01-01 01:00:00.0 +0100
+++ busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch  
2023-08-03 21:22:44.0 +0100
@@ -0,0 +1,58 @@
+From: Michael Tokarev 
+Date: Tue, 6 Jun 2023 17:08:18 +0300
+Subject: [PATCH] syslogd: fork after init on a regular system, not before
+
+Current syslogd performs all init after daemonizing, meanwhile
+main process exits successfully. This means any errors during init
+will not be even shown up because at this time the process has its
+stderr redirected to /dev/null already.
+
+On a MMU system, delay daemonizing to after init.
+On non-MMU system, keep current code.
+
+Signed-off-by: Michael Tokarev 
+---
+ sysklogd/syslogd.c | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/sysklogd/syslogd.c b/sysklogd/syslogd.c
+index 6ddfd771a..2f9a727cd 100644
+--- a/sysklogd/syslogd.c
 b/sysklogd/syslogd.c
+@@ -1025,7 +1025,6 @@ static void do_syslogd(void)
+   signal(SIGALRM, do_mark);
+   alarm(G.markInterval);
+ #endif
+-  xmove_fd(create_socket(), STDIN_FILENO);
+ 
+   if (option_mask32 & OPT_circularlog)
+   ipcsyslog_init();
+@@ -1033,6 +1032,16 @@ static void do_syslogd(void)
+   if (option_mask32 & OPT_kmsg)
+   kmsg_init();
+ 
++  {
++  int fd = create_socket();
++#if BB_MMU
++  if (!(option_mask32 & OPT_nofork)) {
++  bb_daemonize(DAEMON_CHDIR_ROOT);
++  }
++#endif
++  xmove_fd(fd, STDIN_FILENO);
++  }
++
+   timestamp_and_log_internal("syslogd started: BusyBox v" BB_VER);
+   write_pidfile_std_path_and_ext("syslogd");
+ 
+@@ -1179,9 +1188,11 @@ int syslogd_main(int argc UNUSED_PARAM, char **argv)
+   G.hostname = safe_gethostname();
+   *strchrnul(G.hostname, '.') = '\0';
+ 
++#if !BB_MMU
+   if (!(opts & OPT_nofork)) {
+   bb_daemonize_or_rexec(DAEMON_CHDIR_ROOT, argv);
+   }
++#endif
+ 
+   do_syslogd();
+   /* return EXIT_SUCCESS; */

Bug#1042989: Consider switching packaging to Incus

[Mathias Gibbens]

Package: lxd
Severity: important

  Recently a fork of LXD has been announced:
https://github.com/cyphar/incus/. Depending on how that develops Debian
might want to consider switching LXD's packaging to follow the fork.


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

Bug#1042988: ruby-eye: Please package ruby-eye 0.10.0

[Vladimir Petko]

Source: ruby-eye
Version: 0.7-5.1
Severity: wishlist
X-Debbugs-Cc: vladimir.pe...@canonical.com

Dear Maintainer,

In Ubuntu ruby-celluliod is unable to migrate from proposed due to:
migrating ruby-celluloid/0.18.0-2/amd64 to testing makes ruby-celluloid-
io/0.16.2-5/amd64 uninstallable
migrating ruby-celluloid/0.18.0-2/amd64 to testing makes ruby-eye/0.7-5.1/amd64
uninstallable

This happens due to the Breaks constraint in ruby-celluloid 0.18.0-2 that
required at least version 0.10 of ruby-eye.

Would it be possible to consider providing a new version of the package?


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

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

Bug#1042987: ruby-celluliod-io: Please package ruby-celluloid-io 0.17.3

[Vladimir Petko]

Package: ruby-celluliod-io
Severity: wishlist
X-Debbugs-Cc: vladimir.pe...@canonical.com

Dear Maintainer,

In Ubuntu ruby-celluliod is unable to migrate from proposed due to:
migrating ruby-celluloid/0.18.0-2/amd64 to testing makes ruby-celluloid-
io/0.16.2-5/amd64 uninstallable
migrating ruby-celluloid/0.18.0-2/amd64 to testing makes ruby-eye/0.7-5.1/amd64
uninstallable

This happens due to the Breaks constraint in ruby-celluloid 0.18.0-2 that
required at least version 0.17.3 of ruby-celluliod-io.

Would it be possible to consider releasing a new verion of ruby-celluliod-io
package?


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

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

Bug#1042931: dpkg-dev: dpkg-buildpackage -P option does not work

[Thorsten Glaser]

Hi Guillem,

>I think there's another report about "suboptimal option parsing"
>behavior, which I'll check later whether it makes sense to merge.

oh.

>Otherwise you should use -Pprofile or --build-profiles=profile.

Ah, hmm. I gathered the latter, but the former was somewhat
unexpected, considering I mostly encounter utilities that
use getopt(3) or ksh getopts which honour the POSIX utility
syntax guidelines.

Thanks,
//mirabilos
-- 
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against
 ╳  HTML eMail! Also,
╱ ╲ header encryption!

Bug#963887: UDD: 'duck' importer broken since 2020-05-25

[Baptiste Beauplat]

Hi Lucas,

On Thu, 2023-08-03 at 10:38 +0200, Lucas Nussbaum wrote:
> I submitted #1042947 to discuss re-creating a UDD duck importer,
> using the same model as the lintian importer.
> 
> @Baptiste: could you take a look? There would be a few changes on the
> duck side that would make it much easier.

Sure, I'll have a look before next week.

Best,
-- 
Baptiste Beauplat



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

Bug#1042978: Tests invalid package upgrades

[Paul Gevers]

Control: reassign -1 release.debian.org

Hi Ben,

On 03-08-2023 18:01, Ben Hutchings wrote:

ci.debian.net must therefore also test updating the binaries from all
these source packages together, not just those built from linux.


But ci.debian.net just does what it's been asked to do by the client, in 
this case britney. So, if anything it's britney2 that needs to be 
changed to support this. But, britney2 tries to deduce what needs to be 
tested together from the package relations. Normally, what you're seeing 
here is the result of a test where the signed packages haven't been 
build yet. britney retries tests after 24 hours and normally it retries 
with linux-signed-* in the list of pinned packages as you can see in the 
dkms history. The question that now arises is why it doesn't do that now.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042827: [Pkg-sssd-devel] priv-wrapper?

[Simon Josefsson]

Timo Aaltonen  writes:

> Simon Josefsson kirjoitti 1.8.2023 klo 18.46:
>> Hi
>> I have finished packaging cwrap's priv-wrapper:
>> https://salsa.debian.org/jas/priv-wrapper/
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042827
>> Would you be interested in co-maintaining priv-wrapper in the SSSD
>> group?  I noticed that SSSD maintains some of the other cwrap projects:
>> https://tracker.debian.org/pkg/nss-wrapper
>> https://tracker.debian.org/pkg/pam-wrapper
>> https://tracker.debian.org/pkg/uid-wrapper
>> I'm happy to maintain priv-wrapper in the sssd-group, and help
>> improve
>> packaging of other SSSD packages (e.g, upload new releases), if you
>> grant me access to the Salsa gitlab group.
>> /Simon
>
> Hi,
>
> That sounds fine.

Great -- I'll move priv-wrapper once ftp-master has approved it, and
then make a new upload using its new home.

I'll review nss/pam/uid-wrapper next, I don't expect much changes, I'll
upload to DELAYED to allow for review.

> I had a brief look at priv-wrapper packaging, and noticed it only
> keeps the debian/ dir in git? The sssd-team packages have the full
> upstream git as the base, with packaging added to the packaging
> branch. I prefer those will remain like that :)

I usually also do the full git repo with upstream branch for most of the
packages I maintain, but for this new package I wanted to see if keeping
only debian/ in git worked, as I've had success with that in another
package.  What is really the upside of having upstream code in Debian's
git?  One downside is that it wastes space, although I don't think that
matters a lot these days.  Another downside is that it confuses what is
really the "upstream" in case the Debian git-repo's view of what
"upstream" is differs from the real upstream.

Just to clarify, did you mean that you would want priv-wrapper to use
the same style as the other packages, or merely that I shouldn't change
the other sssd-packages to use this debian/-only approach?  I wouldn't
do the latter.  Generally if you feel there is any subjective style
matter you don't agree with, I'm happy to follow what you prefer.  I
prefer to keep priv-wrapper as debian/-only if you think that is okay,
unless I learn some disadvantage with it that I am not aware of yet.

/Simon

PS. Changing to your ubuntu.com email address since sending to your
debian.org address results in bounces when debian.org forwards it to
ubuntu.com because debian.org is not authorized to send emails on behalf
of si...@josefsson.org due to (probably) my SPF 'mx -all' preference.  I
think it is a problem with the debian.org forwarder..


signature.asc
Description: PGP signature

Bug#833680: lists.debian.org: mhonarc encodes bad attachments with spanish accents

[Anders Jonsson]

I see this behavior also with some attachments containing åäö getting 
those characters mangled in Swedish and German.


For example:
Swedish: https://lists.debian.org/debian-l10n-swedish/2023/08/msg1.html
German: https://lists.debian.org/debian-l10n-german/2023/07/msg00041.html

Bug#1025489: Accepted rxvt-unicode 9.31-1 (source) into unstable

[Salvatore Bonaccorso]

Source: rxvt-unicode
Source-Version: 9.31-1

On Thu, Aug 03, 2023 at 02:42:53PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Thu, 03 Aug 2023 10:05:54 -0400
> Source: rxvt-unicode
> Architecture: source
> Version: 9.31-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Ryan Kavanagh 
> Changed-By: Ryan Kavanagh 
> Changes:
>  rxvt-unicode (9.31-1) unstable; urgency=medium
>  .
>* New upstream version 9.31 (Closes: CVE-2022-4170)

Closing manually #1025489.

Regards,
Salvatore

Bug#1042983: squeekboard - rust gtk stack update.

[Arnaud Ferraris]

Hi Peter,

Le 03/08/2023 à 19:27, Peter Green a écrit :

Package: squeekboard
Version: 1.22.0-3
Severity: serious

The rust gtk stack is currently being updated in Debian,
squeekboard needs a small patch

Please test that squeekboard works with this patch and
if-so apply it.


Thanks for the patch, it works as expected but tests seem to fail on 
i386. I'll check what is going wrong there and upload as soon as this 
issue is fixed.


Cheers,
Arnaud



___
Debian-on-mobile-maintainers mailing list
debian-on-mobile-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1037567: abseil: ftbfs with GCC-13

[Aurelien Jarno]

Hi,

On 2023-08-02 14:27, Benjamin Barenblat wrote:
> I’ve been procrastinating on starting the transition because of some
> lingering MIPS issues. I think they’ve all been sorted out, and I just
> uploaded my latest work to experimental. If that passes the buildds,
> I’ll request a transition slot and do the transition as quickly as
> possible.
> 
> If waiting on the transition is going to unacceptably delay the riscv64
> bootstrap, please let me know. I think I know which patches I would have
> to backport to 20220623 to get it to build with GCC 13, so I may be able
> to fix this in unstable before the transition completes.

It was not clear when we're going to need abseil when sending the
initial mail, but it's not clear that we'll need to really soon for
building llvm-toolchain-XX through both libgrpc++-dev and
libctypes-ocaml.

Therefore it would be great if you can fix that in unstable before the
transition. From what I understand it should be this patch:
https://github.com/abseil/abseil-cpp/commit/4eef16170014f75f4291ae335a271900f89eaedf

Alternatively it could also be changing the compiler to gcc-12.

Thanks
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1042986: guvcview: stop hardcoding path to icon

[sx97gz+5r6clohbtj4b0]

Package: guvcview
Version: 2.0.8-2
Severity: normal
X-Debbugs-Cc: sx97gz+5r6clohbtj4b0@cs.email

Dear Maintainer,

the file /usr/share/applications/guvcview.desktop hardcodes the path to the 
icon file:

Icon=/usr/share/pixmaps/guvcview/guvcview.png

This means that themes like papirus-icon-theme cannot override the displayed 
icon for guvcview.

Please stop hardcoding the path to the icon.

A naive change to:

Icon=guvcview

makes it work if the user has papirus-icon-theme or other icon themes 
installed. However, it breaks the icon if there is no icon theme installed, 
because the vendor icon file is in /usr/share/pixmaps/guvcview/guvcview.png 
instead of /usr/share/pixmaps/guvcview.png

A workaround is to create a symlink:

# ln -s /usr/share/pixmaps/guvcview/guvcview.png /usr/share/pixmaps/guvcview.png

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/1 CPU thread; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages guvcview depends on:
ii  libc6  2.36-9+deb12u1
ii  libglib2.0-0   2.74.6-2
ii  libgtk-3-0 3.24.37-2
ii  libguvcview-2.1-2  2.0.8-2

Versions of packages guvcview recommends:
ii  uvcdynctrl  0.2.5-2

guvcview suggests no packages.

-- no debconf information

Bug#1042050: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4:(.text.startup+0x3): undefined reference to `hidden_function'

[Shmerl]

On Tue, 1 Aug 2023 22:55:02 +0300 Jussi Pakkanen  wrote:
> On Wed, 26 Jul 2023 at 00:16, Lucas Nussbaum  wrote:
>
> This is actually a bug in gobject-introspection. It has already been
> fixed upstream. Dunno what the schedule is for getting that into a
> release and on to Debian.
>

Can this be applied for now as a patch until upstream makes a new tag
(which can be a while)?

https://gitlab.gnome.org/GNOME/gobject-introspection/-/commit/bf96a92ef263820d40e233814a46932cae00db41

Stuck Meson is blocking a bunch of packages from being updated in testing.

Regards,

Shmerl.

Bug#1041885: rust-multihash: please upgrade to v0.19

[Jonas Smedegaard]

Quoting Peter Green (2023-08-03 20:49:57)
> > Please upgrade or separately provide newer upstream branch v0.19,
> > needed by rust-multiaddr (bug#1041880).
> 
> The new version of rust-multihash depends on the core2 crate which is
> not currently in debian. Nor does anyone appear to be working on
> packaging it

Sometimes maintaining a package involves packaging new dependencies.

Do the Rust team have an interest in maintaining rust-multihash?
Otherwise please say so, and I will consider adopting it.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#1042985: libgnupg-interface-perl: FTBFS with Perl 5.38: Insecure directory in $ENV{PATH} while running with -T switch

[Niko Tyni]

Source: libgnupg-interface-perl
Version: 1.02-3
Severity: important
Tags: ftbfs trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
X-Debbugs-Cc: Andrew Ruthven 

This package fails to build from source with Perl 5.38 (currently in
experimental.)

  
http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libgnupg-interface-perl_1.02-3/libgnupg-interface-perl_1.02-3_amd64-2023-07-06T13:45:16Z.build

   Insecure directory in $ENV{PATH} while running with -T switch at 
/<>/blib/lib/GnuPG/Interface.pm line 355.
   Use of uninitialized value $line in pattern match (m//) at 
/<>/blib/lib/GnuPG/Interface.pm line 828.
   Use of uninitialized value $a in split at 
/<>/blib/lib/GnuPG/Interface.pm line 842.
   Use of uninitialized value $a in split at 
/<>/blib/lib/GnuPG/Interface.pm line 842.
   GnuPG Version 1.4 or 2.2+ required at (eval 208) line 83.
   t/taint.t .. 
   1..2
   Dubious, test returned 255 (wstat 65280, 0xff00)
   Failed 2/2 subtests 
 
This is a Debian specific test file (debian/patches/detect-taint-mode)
but it seems to flag a real upstream issue.

lib/GnuPG/Interface.pm has this:

local $ENV{PATH} if tainted $ENV{PATH};
exec @command or die "exec() error: $ERRNO";

which broke with
  https://github.com/Perl/perl5/commit/5ede4453c4877110eb5214ff400c173210b101b1
for a good reason: an empty $ENV{PATH} is equivalent to '.' (cwd).

Andrew, I'm copying you as you were involved in this stuff a few years
back so you might still be interested :)

Hm, possibly perl should add a Breaks for earlier versions once this is fixed.
-- 
Niko Tyni   nt...@debian.org

Bug#1042984: golang-1.19 should not be in trixie

[Adrian Bunk]

Source: golang-1.19
Severity: serious
Tags: trixie sid

With 1.20 already being the default, the obsolete golang-1.19
should be removed from trixie.

This bug will trigger the autoremoval.

Bug#1040387: libb-perlreq-perl: FTBFS with Perl 5.38: t/01-B-PerlReq.t failure

[Niko Tyni]

Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=148982
Control: tag -1 patch

On Wed, Jul 05, 2023 at 01:26:54PM +0300, Niko Tyni wrote:
> Source: libb-perlreq-perl
> Version: 0.82-7
> Severity: important
> Tags: ftbfs trixie sid
> User: debian-p...@lists.debian.org
> Usertags: perl-5.38-transition
> 
> This package fails to build from source with Perl 5.38 (currently in
> experimental):

There's a patch by Petr Písař in [rt.cpan.org #148982].
-- 
Niko

Bug#1042005: transition: mumps hypre2.28.0 superlu combblas

[Adrian Bunk]

On Wed, Aug 02, 2023 at 10:58:17AM +0200, Drew Parsons wrote:
> On 2023-07-31 21:30, Sebastian Ramacher wrote:
> > > 
> > > combblas:  1.16.0 → 2.0.0
> > > superlu:5 → 6
> > > hypre: 2.26.0 → 2.28.0
> > > mumps:5.5 → 5.6
> > 
> > Please go ahead.
> 
> combblas and superlu are loaded.
> 
> Probably best to run the rebuild of superlu-dist against combblas
>...

That didn't build:

https://buildd.debian.org/status/logs.php?pkg=superlu-dist=8.1.2%2Bdfsg1-1%2Bb2

...
/usr/bin/ld: 
CMakeFiles/superlu_dist.dir/z_c2cpp_GetHWPM.cpp.o:/usr/include/CombBLAS/BipartiteMatchings/BPMaximalMatching.h:17:
 multiple definition of `GlobalMT'; 
CMakeFiles/superlu_dist.dir/d_c2cpp_GetHWPM.cpp.o:/usr/include/CombBLAS/BipartiteMatchings/BPMaximalMatching.h:17:
 first defined here
/usr/bin/ld: CMakeFiles/superlu_dist.dir/z_c2cpp_GetHWPM.cpp.o: in function 
`combblas::ThreadBuffLenForBinning(int, int)':
/usr/include/CombBLAS/BipartiteMatchings/ApproxWeightPerfectMatching.h:401: 
multiple definition of `combblas::ThreadBuffLenForBinning(int, int)'; 
CMakeFiles/superlu_dist.dir/d_c2cpp_GetHWPM.cpp.o:/usr/include/CombBLAS/BipartiteMatchings/ApproxWeightPerfectMatching.h:401:
 first defined here
...


At first sight this looks like a bug in the combblas headers to me.


> Drew

cu
Adrian

BTW: dolfin/fenics-basix/fenics-dolfinx need source-only uploads
 for testing migration.

Bug#1024695: also debian-ispell

[Dan Jacobson]

Hi 1034744 team: please see #1024695 as a bug that could get fixed at
the same time...

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

[Ryan Tandy]

Control: tag -1 moreinfo

Hello, I'm sorry for the long delay in following up on this.

I'm looking at this issue and I don't see where any dynlist crash was 
reported or fixed upstream for 2.5.14.


Can you please explain how to trigger the crash, or point to the 
upstream issue where it was fixed? In order to fix the issue in 
bookworm, I will have to be able to reproduce and verify it myself.


Thank you,
Ryan

Bug#1042983: squeekboard - rust gtk stack update.

[Peter Green]

Package: squeekboard
Version: 1.22.0-3
Severity: serious

The rust gtk stack is currently being updated in Debian,
squeekboard needs a small patch

Please test that squeekboard works with this patch and
if-so apply it.diff -Nru squeekboard-1.22.0/debian/changelog 
squeekboard-1.22.0/debian/changelog
--- squeekboard-1.22.0/debian/changelog 2023-07-01 15:14:45.0 +
+++ squeekboard-1.22.0/debian/changelog 2023-08-03 16:41:53.0 +
@@ -1,3 +1,10 @@
+squeekboard (1.22.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update for gtk-rs 0.17.
+
+ -- Peter Michael Green   Thu, 03 Aug 2023 16:41:53 +
+
 squeekboard (1.22.0-3) unstable; urgency=medium
 
   * debian: update build dependencies.
diff -Nru squeekboard-1.22.0/debian/control squeekboard-1.22.0/debian/control
--- squeekboard-1.22.0/debian/control   2023-07-01 15:14:45.0 +
+++ squeekboard-1.22.0/debian/control   2023-08-03 16:39:01.0 +
@@ -17,11 +17,11 @@
  librust-aho-corasick-dev,
  librust-bitflags-1-dev (>= 1.0),
  librust-clap-4+std-dev (>= 4.0),
- librust-gio+v2-58-dev (>= 0.16),
- librust-glib+v2-58-dev (>= 0.16),
- librust-glib-sys-dev (>= 0.16),
- librust-gtk+v3-24-dev (>= 0.16),
- librust-gtk-sys-dev (>= 0.16),
+ librust-gio+v2-58-dev (>= 0.17),
+ librust-glib+v2-58-dev (>= 0.17),
+ librust-glib-sys-dev (>= 0.17),
+ librust-gtk+v3-24-dev (>= 0.17),
+ librust-gtk-sys-dev (>= 0.17),
  librust-maplit-1-dev (>= 1.0),
  librust-serde-derive-1-dev (>= 1.0),
  librust-serde-yaml-0.8-dev (>= 0.8),
diff -Nru squeekboard-1.22.0/debian/patches/0005-gtk-rs-0.17.patch 
squeekboard-1.22.0/debian/patches/0005-gtk-rs-0.17.patch
--- squeekboard-1.22.0/debian/patches/0005-gtk-rs-0.17.patch1970-01-01 
00:00:00.0 +
+++ squeekboard-1.22.0/debian/patches/0005-gtk-rs-0.17.patch2023-08-03 
16:41:53.0 +
@@ -0,0 +1,56 @@
+Index: squeekboard-1.22.0/Cargo.deps.newer
+===
+--- squeekboard-1.22.0.orig/Cargo.deps.newer
 squeekboard-1.22.0/Cargo.deps.newer
+@@ -10,30 +10,30 @@ zvariant_derive = "2.10.*"
+ xkbcommon = { version = "0.5.*", features = ["wayland"] }
+ 
+ [dependencies.cairo-rs]
+-version = "0.16.*"
++version = "0.17.*"
+ 
+ [dependencies.cairo-sys-rs]
+-version = "0.16.*"
++version = "0.17.*"
+ 
+ [dependencies.gdk]
+-version = "0.16.*"
++version = "0.17.*"
+ 
+ [dependencies.gio]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v2_58"]
+ 
+ [dependencies.glib]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v2_58"]
+ 
+ [dependencies.glib-sys]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v2_58"]
+ 
+ [dependencies.gtk]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v3_24"]
+ 
+ [dependencies.gtk-sys]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v3_24"]
+Index: squeekboard-1.22.0/src/popover.rs
+===
+--- squeekboard-1.22.0.orig/src/popover.rs
 squeekboard-1.22.0/src/popover.rs
+@@ -326,7 +326,7 @@ pub fn show(
+ let layout_action = gio::SimpleAction::new_stateful(
+ "layout",
+ Some(current_layout_name.to_variant().type_()),
+-_layout_name.to_variant()
++current_layout_name.to_variant()
+ );
+ 
+ let menu_inner = menu.clone();
diff -Nru squeekboard-1.22.0/debian/patches/series 
squeekboard-1.22.0/debian/patches/series
--- squeekboard-1.22.0/debian/patches/series2023-07-01 15:14:45.0 
+
+++ squeekboard-1.22.0/debian/patches/series2023-08-03 16:40:41.0 
+
@@ -2,3 +2,4 @@
 0002-src-popover-fix-build-with-newer-gtk-rs.patch
 0003-src-style-fix-build-with-newer-gtk-rs.patch
 0004-Cargo.-use-xkbcommon-v0.5.patch
+0005-gtk-rs-0.17.patch

Bug#1042982: yaru-theme-gnome-shell: Broken with gnome-shell 43

[Jeremy Bícha]

Package: yaru-theme-gnome-shell
Version: 23.04.4-1
Severity: serious

Yaru 23.04 was designed for GNOME Shell 44 but Debian still only has
GNOME Shell 43. This makes the theme broken for users of Debian
Testing and Unstable currently.

How can we coordinate this better in the future?

It's potentially especially challenging every 2 years when Debian
freezes and the GNOME team delays switching to the new GNOME until the
Debian Stable .1 release.

Even the non-GNOME Shell parts might have been broken too but the new
gtk4 and libadwaita landed in Testing last week so it's at least not
broken any more.

Thank you,
Jeremy Bícha

Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Bertram Felgenhauer]

Package: polkitd
Version: 123-1
Severity: normal
File: /usr/lib/polkit-1/polkitd

Dear Maintainer,

for reasons lost in time I had polkitd:i386 installed on an x86_64 host.

After the update to 123-1, polkitd stopped working with errors like

  [ 2080.436059] audit: type=1326 audit(1691077090.861:74): auid=4294967295 
uid=0 gid=0 ses=4294967295 subj=unconfined pid=4252 comm="polkitd" 
exe="/usr/lib/polkit-1/polkitd" sig=31 arch=4003 syscall=45 compat=1 
ip=0xf7f51887 code=0x0

This is due to the addition of system call filtering in the polkit
systemd unit:

  SystemCallArchitectures=native  # (which is not i386)
  SystemCallFilter=@system-service

The solution is to install polkitd in its native version.

Can this be fixed by strengthening dependencies?
(Say, tie the architecture to that of systemd...)

Cheers,

Bertram

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

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

Versions of packages polkitd depends on:
ii  adduser 3.137
ii  dbus [default-dbus-system-bus]  1.14.8-1
ii  libc6   2.36-9
ii  libduktape207   2.7.0-2
ii  libexpat1   2.5.0-2
ii  libglib2.0-02.76.4-4
ii  libpam-systemd [logind] 254-1
ii  libpam0g1.5.2-6
ii  libpolkit-agent-1-0 123-1
ii  libpolkit-gobject-1-0   123-1
ii  libsystemd0 254-1
ii  systemd [systemd-sysusers]  254-1
ii  xml-core0.18+nmu1

polkitd recommends no packages.

Versions of packages polkitd suggests:
pn  polkitd-pkla  

Versions of packages polkitd is related to:
pn  elogind 
pn  libpam-elogind  
ii  libpam-systemd  254-1
ii  systemd 254-1

-- no debconf information

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[Simon McVittie]

Source: gnome-shell
Version: 44.3-1
Severity: serious
Tags: ftbfs experimental help
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el mipsel

gnome-shell 44 builds successfully on all release architectures except
mips*el, but fails to build on mips*el. The three perf-* unit tests fail
with exit status 1 and no obvious error messages:



At the moment this is only in experimental, but we want to upload it to
unstable soon, as part of the libmutter-12-0 transition
.

Is gnome-shell practically useful on mips-based hardware, or does it
have hardware requirements that the mips family do not meet in practice?
If nobody really uses it on mips*el, it might be better to do
architecture-specific removals rather than attempting to debug and fix it.

Or, if the mips porting team can confirm that GNOME 43 works in practice
as a desktop environment on mips*el hardware, then it would be useful
to try GNOME 44 from experimental on the same hardware (after building
gnome-shell locally with DEB_BUILD_OPTIONS=nocheck) to check whether
this is a practical problem.

Thanks,
smcv

Bug#1042979: subversion-tools: psvn.el does not work with emacs 29.1

[OHURA Makoto]

Package: subversion-tools
Version: 1.14.2-4+b2
Severity: normal
Tags: patch
X-Debbugs-Cc: none, OHURA Makoto 

Dear Maintainer,

After upgrading emacs 29.1, psvn.el does not work fine.  Emacs 29.1 doesn't 
support the function, toggle-read-only.  Use read-only-mode.  I attach a patch 
to this e-mail.

Thanks.

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

Kernel: Linux 6.4.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 subversion-tools depends on:
ii  libapr1 1.7.2-3
ii  libc6   2.37-6
ii  libsvn1 1.14.2-4+b2
ii  subversion  1.14.2-4+b2

Versions of packages subversion-tools recommends:
ii  libconfig-inifiles-perl 3.03-2
ii  libsvn-perl 1.14.2-4+b2
ii  liburi-perl 5.19-2
ii  postfix [mail-transport-agent]  3.8.1-2
ii  rsync   3.2.7-1
ii  svn2cl  0.14-3

Versions of packages subversion-tools suggests:
pn  ruby-svn  

-- no debconf information


  OHURA Makoto: oh...@debian.org(Debian Project)
oh...@netfort.gr.jp(LILO/Netfort)
  GnuPG public key: http://www.netfort.gr.jp/~ohura/gpg.asc.txt
fingerprint: 54F6 D1B1 2EE1 81CD 65E3  A1D3 EEA2 EFA2 77DC E083
  http://www.netfort.gr.jp/~ohura/

--- psvn.el.old 2023-08-04 01:00:23.460477204 +0900
+++ psvn.el 2023-08-04 00:28:50.764059785 +0900
@@ -2248,7 +2248,7 @@
   (setq mode-line-process 'svn-status-mode-line-process)
   (run-hooks 'svn-status-mode-hook)
   (let ((view-read-only nil))
-(toggle-read-only 1)))
+(read-only-mode 1)))

 (defun svn-status-update-mode-line ()
   (setq svn-status-mode-line-process
@@ -5729,7 +5729,7 @@
   (use-local-map svn-info-mode-map)
   (setq major-mode 'svn-info-mode)
   (setq mode-name "svn-info")
-  (toggle-read-only 1))
+  (read-only-mode 1))

 (defun svn-info-show-context ()
   "Show the context for a line in the info buffer.
@@ -5814,7 +5814,7 @@
   (if svn-blame-mode
   (progn
 (easy-menu-add svn-blame-mode-menu)
-(toggle-read-only 1))
+(read-only-mode 1))
 (easy-menu-remove svn-blame-mode-menu))
   (force-mode-line-update))




pgp_1OkSICrk6.pgp
Description: OpenPGP Digital Signature

Bug#1037349: Problem resolved

[Eric Chassande-Mottin]

Hi!

I've resolved this issue by following the instructions given here:

https://github.com/QubesOS/qubes-issues/issues/8193

that is: remove/reinstall all pipewire, pulseaudio and pavucontrol packages

Cheers,
Eric

Bug#1042928: Please include example handler for mailto: URIs

[Nicholas D Steeves]

David Bremner  writes:

> Nicholas D Steeves  writes:
>
>> 1. Set Notmuch as the default application for email (or URI handler)
>> 2. Navigate to the BTS in a web browser like Firefox
>> 3. Find a bug, and click on one of the reply links
>> 4. Emacs opens in message-mode rather than notmuch-message-mode
>
> OK, this seems like a completely different bug report :).

:) Maybe!  I also wonder if I simply assigned it to the wrong package.

> Unfortunately also not really one I know much about, as I don't use
> Gnome (I assume step 1 above means set default in gnome?).

It's not GNOME specific (I use KDE), but given that a desktop file is
used, I wonder if the nature of this bug is more of an XDG thing.  For
the purposes of this bug I'll attempt to reproduce using my laptop
rather than desktop.

> I guess my first question is if you can duplicate the problem from the
> command line. I tried
>
> % notmuch-emacs-mua --hello mailto:brem...@debian.org
>
> It seems to do the right thing. 

Hmm,

% xdg-open mailto:brem...@debian.org

also seems to do the right thing.

> Maybe your mailto URLs are more complicated? Anyway, if you can
> duplicate the problem without requiring gnome or firefox, that would be
> helpful.

Good hypothesis!  The following mailto link is copied from the BTS via
eww-view-source, it points to your most recent email, which is the the
one that this email--my reply--is replying to:

xdg-open 
"mailto:1042...@bugs.debian.org?References=%3C169101992716.3310278.2992723615742697826.reportbug%40bras-base-mtrlpq0313w-grc-19-69-156-163-190.dsl.bell.ca%3E%0A%20%3C87fs517z32.fsf%40tethera.net%3E%20%3C87tttguclr.fsf%40digitalMercury.freeddns.org%3E%0A%20%3C87bkfo8mpa.fsf%40tethera.net%3Ebody=On%20Thu%2C%2003%20Aug%202023%2007%3A06%3A09%20-0300%20David%20Bremner%20%3Cdavid%40tethera.net%3E%20wrote%3A%0A%3E%20Nicholas%20D%20Steeves%20%3Csten%40debian.org%3E%20writes%3A%0A%3E%20%0A%3E%20%3E%201.%20Set%20Notmuch%20as%20the%20default%20application%20for%20email%20%28or%20URI%20handler%29%0A%3E%20%3E%202.%20Navigate%20to%20the%20BTS%20in%20a%20web%20browser%20like%20Firefox%0A%3E%20%3E%203.%20Find%20a%20bug%2C%20and%20click%20on%20one%20of%20the%20reply%20links%0A%3E%20%3E%204.%20Emacs%20opens%20in%20message-mode%20rather%20than%20notmuch-message-mode%0A%3E%20%0A%3E%20OK%2C%20this%20seems%20like%20a%20completely%20different%20bug%20report%20%3A%29.%0A%3E%20%0A%3E%20Unfortunately%20also%20not%20really%20one%20I%20know%20much%20about%2C%20as%20I%20don%27t%20use%0A%3E%20Gnome%20%28I%20assume%20step%201%20above%20means%20set%20default%20in%20gnome%3F%29.%0A%3E%20%0A%3E%20I%20guess%20my%20first%20question%20is%20if%20you%20can%20duplicate%20the%20problem%20from%20the%0A%3E%20command%20line.%20I%20tried%0A%3E%20%0A%3E%20%25%20notmuch-emacs-mua%20--hello%20mailto%3Abremner%40debian.org%0A%3E%20%0A%3E%20It%20seems%20to%20do%20the%20right%20thing.%20%0A%3E%20%0A%3E%20Maybe%20your%20mailto%20URLs%20are%20more%20complicated%3F%20Anyway%2C%20if%20you%20can%0A%3E%20duplicate%20the%20problem%20without%20requiring%20gnome%20or%20firefox%2C%20that%20would%20be%0A%3E%20helpful.%0A%3E%20%0A%3E%20%0A%3E%20d%0A%3E%20%0A%3E%20%0Asubject=Re%3A%20Bug%231042928%3A%20Please%20include%20example%20handler%20for%20mailto%3A%20URIsIn-Reply-To=%3C87bkfo8mpa.fsf%40tethera.net%3E;

...and that succeeds.

Finally, it works properly in Firefox on my laptop...oh no, this is
starting to look like a Heisenbug.  I'm baffled why notmuch-message-mode
opens correctly on my laptop, while my desktop opens message-mode.

So what are the differences between the systems?  My desktop had the
dummy transitional package "notmuch-emacs" installed.  Of course, that
shouldn't make a difference one way or another, but I've removed it
anyway.

How can I trace Emacs, to see what data it receives as a startup
argument, and to see what it does with it?  I'd like to see if I can
eliminate the "the desktop environment is sending a bad URI" hypothesis.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#1042978: Acknowledgement (Tests invalid package upgrades)

[Ben Hutchings]

The test log for reference:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dkms/36392756/log.gz

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi,

I've uploaded a fixed package that addresses these issues.

Colin

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

  * Package name : libtypec
Version  : 0.3-1
  * URL  : https://github.com/Rajaram-Regupathy/libtypec



   libtypec1 - generic interface for efficient USB-C port management
   libtypec-dev - Development files for an interface for USB-C port management



  libtypec (0.3-1) unstable; urgency=low
  .
* Initial release (Closes: #1023477)
* Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#1042978: Tests invalid package upgrades

[Ben Hutchings]

Package: debci
Severity: serious
X-Debbugs-Cc: debian-ker...@lists.debian.org

ci.debian.net is running dkms's autopkgtest with packages from testing
except for linux's binaries updated from unstable.  The test fails
because linux-headers-amd64 is uninstallable in this scenario:

* The available version of linux-headers-amd64 will be the latest,
  6.4.4-2.  It depends on (currently) linux-headers-6.4.0-1-amd64
  at the same version.
* The available version of linux-headers-6.4.0-1-amd64 (built from
  src:linux-signed-amd64) will be 6.4.4-1.

This cross-source-package version lock is unusual but has been
implemented deliberately to ensure that linux and linux-signed-*
always migrate from unstable to testing together.

ci.debian.net must therefore also test updating the binaries from all
these source packages together, not just those built from linux.  If
it's not possible to do this in a general way then we need a specific
workaround that can be used in dkms and any other affected packages
to prevent this invalid test scenario.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages debci depends on:
ii  adduser 3.137
pn  amqp-tools  
ii  bsdmainutils12.1.8
ii  curl7.88.1-10
ii  dctrl-tools 2.24-3+b1
ii  debian-archive-keyring  2023.3
ii  debootstrap 1.0.128+nmu5
ii  devscripts  2.23.5
ii  distro-info 1.5
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  jq  1.6-2.1
pn  libjs-bootstrap 
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
pn  libjs-jquery-flot   
ii  moreutils   0.67-1
ii  netcat-openbsd  1.225-1
ii  netcat-traditional  1.10-47
pn  parallel
ii  patchutils  0.4.2-1
pn  retry   
ii  rsync   3.2.7-1
ii  ruby1:3.1
pn  ruby-activerecord   
pn  ruby-bunny  
pn  ruby-erubi  
pn  ruby-kaminari-activerecord  
pn  ruby-minitar
pn  ruby-omniauth-gitlab
pn  ruby-sinatra
pn  ruby-sinatra-contrib
pn  ruby-sqlite3 | ruby-pg  
pn  ruby-thor   
ii  sudo1.9.14p2-1

Versions of packages debci recommends:
ii  systemd-timesyncd [time-daemon]  254~rc3-3

Versions of packages debci suggests:
pn  apt-cacher-ng   
pn  auto-apt-proxy  

Bug#1042977: crossfire-server does not work with Python 3.11

[Dr. Oliver Muth]

Package: crossfire-server
Version: 1.75.0-5+b2
Severity: important

Dear Maintainer,

It seems crossfire-server was compiled using the 
PyUnicode_EncodeRawUnicodeEscape workaround for Python 3.3 - 3.9 which is 
deprecated in Python 3.11.

On each start crossfire-server logs the following error message in 
/var/log/crossfire/logfile:
23/08/03 16:56:50 [II] plugins: loading cfanim.so
23/08/03 16:56:50 [II] plugins: loading cfcitybell.so
23/08/03 16:56:50 [II] plugins: loading cfpython.so
23/08/03 16:56:50 [EE] Error trying to load 
/usr/lib/x86_64-linux-gnu/crossfire/plugins/cfpython.so: 
/usr/lib/x86_64-linux-gnu/crossfire/plugins/cfpython.so: undefined symbol: 
PyUnicode_EncodeRawUnicodeEscape

Subsequently game functions that require a python script do not work. Instead 
errors are logged like:
[EE] The requested plugin doesn't exist: Python at 11/23 in map Old City
[EE] The requested plugin doesn't exist: Python at 5/34 in map world_105_115
[EE] The requested plugin doesn't exist: Python at 11/7 in map Starting House
[EE] The requested plugin doesn't exist: Python at 1/3 in map apartments

However, nm -gD cfpython.so | grep PyUnicode finds the symbol in 
/usr/lib/crossfire/plugins/cfpython.so:
 U PyUnicode_AsUnicode
 U PyUnicode_AsUTF8
 U PyUnicode_AsUTF8String
 U PyUnicode_DecodeUnicodeEscape
 U PyUnicode_EncodeRawUnicodeEscape
 U PyUnicode_FromString

but it is missing from libpython3.11.so (in Debian bookworm). It was still 
available in libpython3.9 in Debian buster.

I found this in the upstream source in plugins/cfpython/cjson.c :
if (PyUnicode_Check(string)) {
// PyUnicode_EncodeRawUnicodeEscape() is deprecated as of Python 3.3, 
scheduled for removal in Python 3.11
#ifndef IS_PY3K3
/* HACK: Workaround for crash bug in Python3's 
PyUnicode_AsRawUnicodeEscapeString... */
str = PyUnicode_EncodeRawUnicodeEscape(PyUnicode_AS_UNICODE(string),
   PyUnicode_GET_SIZE(string));
#else
// The Python docs recommend using PyUnicode_AsRawUnicodeEscapeString() 
or PyUnicode_AsEncodedString() over PyUnicode_EncodeRawUnicodeEscape().
str = PyUnicode_AsRawUnicodeEscapeString(string);
#endif

So it seems IS_PY3K3 was #defined at compile time, even though it should not be 
for Python 3.11?

Kind regards

Oliver


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

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

Versions of packages crossfire-server depends on:
ii  bzip21.0.8-5+b1
ii  crossfire-common 1.75.0-5
ii  crossfire-maps   1.75.0+dfsg1-1
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u1
ii  libcrypt11:4.4.33-2
ii  libcurl3-gnutls  7.88.1-10+deb12u1
ii  libpython3.113.11.2-6
ii  python3  3.11.2-1+b1
ii  python3-bsddb3   6.2.9-2+b4

crossfire-server recommends no packages.

crossfire-server suggests no packages.

-- Configuration Files:
/etc/crossfire/dm_file changed [not included]

-- no debconf information

Bug#1042961: reported upstream

[Francesco Potortì]

I have reported it.  Thanks

Bug#1042976: needrestart false positive: Warning about not being able to check for processor microcode upgrades on arm64 platform

[Christian Britz]

Package: needrestart
Version: 3.6-4
Severity: normal
Tags: upstream
X-Debbugs-Cc: cbr...@t-online.de

Dear Maintainer,

when I run needrestart on my Raspberry Pi (Debian Bookworm) it prints out the
following:

root@raspberrypi:~# LANG=C needrestart
Scanning processes...
Scanning processor microcode...
[...]
Failed to check for processor microcode upgrades.
[...]

There is no package equivalent to amd64-microcode or intel-microcode for the
arm64 architecture, so this check should probably be removed.


-- Package-specific info:
needrestart output:



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

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_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

Versions of packages needrestart depends on:
ii  binutils   2.40-2
ii  dpkg   1.21.22
ii  gettext-base   0.21-12
ii  libintl-perl   1.33-1
ii  libmodule-find-perl0.16-2
ii  libmodule-scandeps-perl1.31-2
ii  libproc-processtable-perl  0.634-1+b2
ii  libsort-naturally-perl 1.03-4
ii  libterm-readkey-perl   2.38-2+b1
ii  perl   5.36.0-7
ii  xz-utils   5.4.1-0.2

Versions of packages needrestart recommends:
ii  libpam-systemd  252.12-1~deb12u1
ii  systemd 252.12-1~deb12u1

Versions of packages needrestart suggests:
ii  iucode-tool2.3.1-3
ii  libnotify-bin  0.8.1-1

-- no debconf information

Bug#1042975: libnspr4-dev multi arch co-install

[Jan Smets]

Package: nspr
Version: 2:4.35-1.1

Hi!
Different arch flavors of libnspr4-dev can not be co-installed.
Please add the Multi-Arch: same  hints to the debian/control file
Also, nspr-config - which is a shell script - contains the library path -
making it different.

if test -z "$libdir"; then
libdir=/usr/lib/x86_64-linux-gnu
fi

This can be dynamically queried from dpkg-architecture -qDEB_HOST_MULTIARCH

Much appreciated.
Thank you

-- 
Smets Jan
j...@smets.cx

Bug#1042560: xtensor autopkg test fails with LLVM-16

[Drew Parsons]

Source: xtensor
Followup-For: Bug #1042560
Control: forwarded 1042560 
https://github.com/xtensor-stack/xtensor/issues/2718#issuecomment-1664157116

Something weird going on here.  This is a string comparison not a
floating point comparison.  The string is supposed to be the type of
the values, so why is LLVM-16 returning "le" instead of "double" ?
Is it a bug in LLVM-16?

Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.

[Nicholas D Steeves]

Control: tag -1 + upstream wontfix
Control: forwarded -1 https://list.orgmode.org/20160222085952.GA32746@garlic/

Hello Max,

Max Nikulin  writes:

> On Sun, 21 Feb 2016 11:37:01 +0100 Sébastien Delafond wrote:
>> 
>> thanks for your report. As this seems to be a pure upstream problem,
>> could you please follow up on it using the org-mode mailing list[0] ?
>> Once that's done, feel free to add a link to your post in the Debian
>> BTS.
>
> I think, this issue can be closed as not a bug:
>
> Nicolas Goaziou to emacs-orgmode. Re: * [[shell:cat ~/tmp | grep "asdf 
> :: "]] does not work. Wed, 24 Feb 2016 18:38:09 +0100
> https://list.orgmode.org/878u2a57r2@nicolasgoaziou.fr/T/#u
>
>> This is not a bug. -  :: *is* description list syntax, no matter how
>> you look at it. You can easily work around this, e.g., by starting the
>> link on the next line.

I read the thread upstream, and see what you mean, and upstream's
perspective makes sense.  How do you feel about keeping this bug open,
because this "gotcha" should be documented somewhere.  I'm not sure if
org-mode's documentation would be the best place, because it's non-free.

For future readers of this bug, Brian G Powell wrote some nice style
suggestions for avoiding this pitfall, so here is the link:

  
https://list.orgmode.org/CAFm0skF=3JNXQQPFYutEvM8y+FRZJziE+QngVX=gocx3rkq...@mail.gmail.com/#t

> And a related issue: try to export text where /italics breaks the link 
> [[https://lists.debian.org/msgid-search/?m=zitsdg4dp0wxd...@powdarrmonkey.net][Bits
>  
> from the Release Team: a trixie customer]] due to adjacent slash and 
> question mark./

Thank you for documenting this one too.

> It is a price for lightweight markup and it is how org-element parser works.

Indeed!  Please go ahead and give this bug a more useful title.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1042555: glib2.0: Release 2.77.x to unstable

[Simon McVittie]

On Thu, 03 Aug 2023 at 10:35:17 -0400, Jeremy Bícha wrote:
> We need special handling for mipsel/mips64el for gnome-shell

I see the whole stack works, except for gnome-shell itself which fails
build-time tests. We should open a bug for that and X-Debbugs-Cc the
mips team, so that they can't claim they had no opportunity to fix it.

I think this will require a reduced-scope version of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018076#86, removing
gnome-shell-dependent binary packages from gdm3 and meta-gnome3 on
mips{,64}el.

> Add gnome-shell-extension-gsconnect to your transition list; the 44
> compatible version in Experimental isn't compatible with 43.

Sure. When someone (maybe me) gets round to uploading a 44-compatible
gnome-shell-extension-bluetooth-quick-connect, it will be in the same
situation.

> I think we would be ok with keeping the new xdg-desktop-portal-gnome
> in Experimental because of how it interacts badly with other installed
> desktops (still not actually resolved upstream)

I'm hoping that's resolvable before trixie. ebassi is working on it
upstream, but it seems xdg-desktop-portal needs to be involved too.
One day in my copious free time I should build a snapshot for
experimental - co-maintainers very welcome of course!

smcv

Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

[Sven Joachim]

On 2023-08-02 15:51 +0200, Vincent Lefevre wrote:

> Package: aptitude
> Version: 0.8.13-5
> Severity: normal
>
> When I use "C" (View a package's changelog) on clang-15 from the
> aptitude TUI, I get a warning that is immediately erased, so that
> it is impossible to read it.
>
> I suppose that aptitude should redirect stderr from
> aptitude-changelog-parser so that it can display its contents
> (when non empty) in a clear way.

It should prevent these errors from showing up in the first place.
See #967911, which has been tagged "pending" almost three years ago. :-(

> Enabling the terminal's logs allows me to get the text of this
> warning:
>
> aptitude-changelog-parser: warning: 
> /tmp/aptitude-root.7707:EXkCUB/aptitude-download-4-bORTciGPJi,..uo2EeQnZD7WBcD+L6_aptitude-download-cbF3RCIRNjR7d%D7+V.DiRimX__YaCHL(l105):
>  found start of entry where expected more change data or trailer
>
> This text seems to come from /usr/share/perl5/Dpkg/Changelog/Debian.pm:
>
> unless ($expect eq FIRST_HEADING || $expect eq NEXT_OR_EOF) {
> $self->parse_error($file, $.,
> sprintf(g_('found start of entry where expected %s'),
> $expect), "$_");
> }
>
> About this unexpected warning, there may be some other bug.

Yes, the clang-15 changelog entry for version 1:15.0.7-2 is not properly
terminated.

Cheers,
   Sven

Bug#1040981: closed by Debian FTP Masters (reply to Michael Tokarev ) (Bug#1040981: fixed in qemu 1:8.0.3+dfsg-2)

[Venkata.Pyla]

>-Original Message-
>From: Michael Tokarev 
>Sent: Thursday, August 3, 2023 11:28 AM
>To: pyla venkata(ＴＳＩＰ TMIEC ODG Porting) tsip.com>; 1040...@bugs.debian.org
>Subject: Re: Bug#1040981 closed by Debian FTP Masters master.debian.org> (reply to Michael Tokarev ) (Bug#1040981:
>fixed in qemu 1:8.0.3+dfsg-2)
>
>03.08.2023 08:52, venkata.p...@toshiba-tsip.com пишет:
>> Hi Michael Tokarev,
>>
>> Thanks for providing the patches, I am trying to check if the changes
>> are fixed the problem, unfortunately I am still getting the crash dumps, 
>> maybe I
>am not correctly using the fixed version of qemu?
>>
>> I followed the below steps to check the issue, does chroot is using fixed 
>> version
>of qemu (1:8.0.3+dfsg-5) while executing armhf binaries in chroot.
>
>https://bugs.debian.org/1040981
>https://tracker.debian.org/news/1449891/accepted-qemu-1803dfsg-5-source-
>into-unstable/

Thanks for the information I will check more details

>
>/mjt

Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1

[Nicholas D Steeves]

Jonathan Wiltshire  writes:

> Control: tag -1 confirmed
>
> On Mon, Jun 12, 2023 at 07:44:52PM -0400, Nicholas D Steeves wrote:
>> Updated debdiff attached.
>
> Please go ahead (you should probably add a non-maintainer upload line, or
> add yourself to uploaders, as well).

Thanks for the ACK, and for the reminder!  I had forgotten to run dch
with "--team", so I fixed that, and uploaded.

Kind regards,
Nicholas

Bug#1042555: glib2.0: Release 2.77.x to unstable

[Jeremy Bícha]

On Thu, Aug 3, 2023 at 9:41 AM Simon McVittie  wrote:
> https://release.debian.org/britney/pseudo-excuses-experimental.html#glib2.0
> says that if the experimental version landed in unstable now, it would be
> unable to migrate.

I triggered retries for those now. I believe those are just flaky
results and that the autopkgtests will pass.

> Are you aware of anything else blocking those, or should I be opening a
> transition-tracker bug?

44 Blocker
--
We need special handling for mipsel/mips64el for gnome-shell. At least
this should be simpler than the gjs/s390x case years ago since at
least our team-managed GNOME Shell extensions are arch:all so it
reduces the number of architecture-specific removals we need.

Soft blocker: My opinion is that we should upload Dash to Dock at the
same time. I'll ping Jonathan again to upload the update since he
started on it. Otherwise, I am comfortable with kicking the other
extensions out of Testing given that we set the hard gnome-shell
version dependencies for the 43 cycle so it's relatively clear to
users what is happening.

44 Notes

Add gnome-shell-extension-gsconnect to your transition list; the 44
compatible version in Experimental isn't compatible with 43.

I think we would be ok with keeping the new xdg-desktop-portal-gnome
in Experimental because of how it interacts badly with other installed
desktops (still not actually resolved upstream).

I do not foresee issues if we push GNOME 45 stuff to Unstable before
GNOME Shell. There are a few low level packages that we would need to
verify compatibility: gnome-control-center, gnome-settings-daemon,
gsettings-desktop-schemas, gtk4, libadwaita. We need to do that
anyway, but there's a greater chance of issues skipping a version.

So yes, go ahead and open the transition bug.

45
--
GNOME Shell 45 Beta will be released in a few days. Unfortunately,
every GNOME Shell extension will be broken by this update and will
need to adapt to changes in the new version.

The GNOME Shell developers in general request that distros like Debian
Unstable provide GNOME Shell Beta to early users so that bugs can be
identified in time for the .0 release instead of the bugs getting
reported after .0 or .1, which then forces GNOME Shell maintainers to
work on fixing major bugs for .1 or .2 and it delays when they can
start development for the next GNOME release, which then encourages
them to land big changes after Beta.

However, I imagine our users will be rather upset if all their
extensions no longer work and there aren't even upstream fixes
available yet. So I want to be more conservative for GNOME Shell this
time and wait until at least RC to release to Unstable.

Mutter 45 Beta has one new dependency, libei, so I plan to work with
the Debian X team to package that in a few days.

We need a new mozjs series. Fortunately gjs seems more stable and I've
been assured that we should be able to keep using the old gjs with new
GNOME Shell or the other way around right now.

Thank you,
Jeremy Bícha

Bug#1042974: RM: python3-pymatgen [armel armhf i386 riscv64 mips64el mipsel] -- NBS; depends on python3-monty and it stop build for some architectures

[Emmanuel Arias]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pymat...@packages.debian.org, eam...@debian.org
Control: affects -1 + src:pymatgen

Dear team,

monty started to depend in python3-torch for that reason
python3-monty stop build for armel, armhf, i386, riscv64,
mips64el, mipsel.

Please remove python3-pymatgen from those Architectures.

Thanks!
Kind Regards,
Emmanuel

Bug#1042973: RM: python3-emmet-core [armel armhf i386 riscv64 mips64el mipsel] -- NBS; depends on python3-monty and it stop build for some architectures

[Emmanuel Arias]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-emmet-c...@packages.debian.org, eam...@debian.org
Control: affects -1 + src:python-emmet-core


Dear team,

monty started to depend in python3-torch for that reason
python3-monty stop build for armel, armhf, i386, riscv64,
mips64el, mipsel.

Please remove python3-emmet-core from those Architectures.

Thanks!
Kind Regards,
Emmanuel

Bug#1042972: RM: python3-mp-api [armel armhf i386 riscv64 mips64el mipsel] -- NBS; depends on python3-monty and it stop build for some architectures

[Emmanuel Arias]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-mp-...@packages.debian.org, eam...@debian.org
Control: affects -1 + src:python-mp-api

Dear team,

python3-monty start to depends in python3-torch for that reason
python3-monty stop build for armel, armhf, i386, riscv64,
mips64el, mipsel.

Please remove python3-mp-api from those Architectures.

Thanks!
Kind Regards,

Emmanuel

Bug#1025779: onetbb: Please add patch to add support for ia64

[John Paul Adrian Glaubitz]

Hello Petter!

On Thu, 2023-08-03 at 15:56 +0200, Petter Reinholdtsen wrote:
> [John Paul Adrian Glaubitz]
> > If you feel fixing this, you can use yttrium.debian.net.
> > 
> > I don't have much time for ia64 at the moment.
> 
> Thanks.  I just wanted to check the status and hopefully reduce the
> amount of open bugs.  I do not plan to increase the number of
> architectures provided at this time, in case it will make it harder for
> the package to propagate into testing.

Ports architectures do not affect the propagation of packages to testing.

So, feel free to ignore the tests on ia64.

FWIW, I have also a patch that I sent upstream that fixes powerpc, but I
need to clean it up again before upstream accepts it.

Adrian

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

Bug#1042968: emacs: Gnus unusable after upgrading to Emacs 29

[David Bremner]

Florent Rougon  writes:

> Package: emacs
> Version: 1:29.1+1-2
> Severity: normal
>
> Dear maintainer,
>
> This morning, I performed the following upgrade:
>
> [UPGRADE] emacs:amd64 1:28.2+1-16 -> 1:29.1+1-2
> [UPGRADE] emacs-bin-common:amd64 1:28.2+1-16 -> 1:29.1+1-2
> [UPGRADE] emacs-common:amd64 1:28.2+1-16 -> 1:29.1+1-2
> [UPGRADE] emacs-common-non-dfsg:amd64 1:28.2+1-2 -> 1:29.1+1-1
> [UPGRADE] emacs-el:amd64 1:28.2+1-16 -> 1:29.1+1-2
> [UPGRADE] emacs-gtk:amd64 1:28.2+1-16 -> 1:29.1+1-2
>
> and rebooted because the kernel was also upgraded at the same time.
> Since then, Gnus (the version shipped with Emacs) has become unusable
> for me because every time I hit RET in the *Summary* buffer in order to
> read a message, I get the following error:
>
> gnus-configure-frame: Symbol’s value as variable is void: gnus-carpal

Please try to duplicate the problem with "emacs -q". I suspect there is
either some obsolete/broken third party package or just some personal
configuration causing this problem.

I could not find gnus-carpal anywhere in current debian sources aside
from xemacs21-packages. So I guess checking if some xemacs21 things are
also installed would be worthwhile.

Thanks!

David

Bug#1041489: ocsinventory-reports: version inconsistency between GUI and perl libraries

[Meik Hellmund]

I can confirm bugs #1037473 and #1041489

The following worked for me:

- install the ocsinventory 2.12.0 deb packages provided by the ocsinventory 
team as described here:

http://wiki.ocsinventory-ng.org/03.Basic-documentation/Setting-up-a-OCS-Inventory-Server-with-rpm/#install-ocs-inventory-server-with-apt
- cp /etc/ocsinventory/dbconfig.inc.php /etc/ocsinventory-reports/
- chown www-data:www-data /var/lib/ocsinventory-reports
- edit ocsinventory files in /etc/apache2/sites-enabled/z-* and correct user/pw 
for mariadb access
- go to your  ocsreports webpage and let it upgrade the db structure



-- 
Meik Hellmund
Mathematisches Institut, Uni Leipzig

Bug#1042971: autopkgtest: do we still need to support systems without dpkg-query, or with read-only rootfs?

[Simon McVittie]

Package: autopkgtest
Version: 5.30
Severity: normal
X-Debbugs-Cc: par...@debian.org

As discussed briefly in
,
autopkgtest has some level of (possibly vestigial) support for:

- systems where the root filesystem is mounted read-only
  (as identified by `test -w /var/lib/dpkg/status`, which might itself
  be considered a bug as explained by the uses-dpkg-database-directly
  Lintian tag); also, elsewhere in autopkgtest, we're careful to assume
  that /sbin and even /var/cache might be read-only

- systems where the Essential interface `dpkg-query` is missing
  (see https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1469647,
  which has a regression test that has caused us extra work recently by
  intentionally removing an Essential interface during testing)

It is not clear to me how snapd, "snappy images", Ubuntu Touch,
Ubuntu Core and similar Canonical products fit together, which ones are
end-of-life or no longer relevant for autopkgtest's purposes, and which
ones are still current and still expected to have autopkgtests run on
them. Please could the operators of Ubuntu's autopkgtest infrastructure
clarify this?

Ideally, I would like autopkgtest to be able to assume that it is running
on a Debian system (or a derivative), with all Essential interfaces
present; and if we have uid 0, then the root filesystem should be rw.

Or, if a significant derivative like Ubuntu wants autopkgtest to
be able to support deviations from that "normal" interface, then
I would like those and the reasons behind them to be documented in
debian/README.source, similar to what I did in
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/247
for our distro-version policies.

Thanks,
smcv

Bug#1042938: Additional information

[John Goerzen]

I can add to this:

1) Adding the "ftp" user lets the anonymous and ftp accounts work as
expected.

2) The long delay appears to be due to attempting a reverse lookup with
avahi.  I could find no way to disable reverse lookups in iksd.  Most
services these days don't do reverse lookups because of the expense of
them, and waiting so long for a response seems to be breaking the
incoming processes.

Probably the postinst script should adduser the ftp account, or, given
that iksd is less-used than kermit as a whole, README.Debian should
mention it.

I am still unable to get the syslog feature to work.

- John

Bug#1042970: zoneminder: Embded cakephp

[Bastien Roucariès]

Source: zoneminder
Severity: serious
Justification: embded code copy

Dear Maintainer,

Your package include a copy of cake php. Could you use the packaged one ?

Thanks



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

Bug#1025779: onetbb: Please add patch to add support for ia64

[Petter Reinholdtsen]

[John Paul Adrian Glaubitz]
> If you feel fixing this, you can use yttrium.debian.net.
>
> I don't have much time for ia64 at the moment.

Thanks.  I just wanted to check the status and hopefully reduce the
amount of open bugs.  I do not plan to increase the number of
architectures provided at this time, in case it will make it harder for
the package to propagate into testing.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1042969: vsftpd: Deletes the ftp user on remove, breaking other packages

[John Goerzen]

Package: vsftpd
Version: 3.0.3-13+b2
Severity: critical
Justification: breaks unrelated software

On removing this package, it indiscriminately removes the ftp user.
Unfortunately, that user was required for iksd in package ckermit to work, so
this broke the unrelated ckermit package.

It is likely that there are other packages and users that would also
use the ftp user.  It should not be removed on package removal.

-- Package-specific info:

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

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

Versions of packages vsftpd depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u1
ii  libcap21:2.66-4
ii  libpam-modules 1.5.2-6
ii  libpam0g   1.5.2-6
ii  libssl33.0.9-1
ii  libwrap0   7.6.q-32
ii  lsb-base   11.6
ii  netbase6.4
ii  procps 2:4.0.2-3
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages vsftpd recommends:
ii  logrotate  3.21.0-1
ii  ssl-cert   1.1.2

vsftpd suggests no packages.

-- debconf information:
  vsftpd/directory: /srv/ftp
  vsftpd/username: ftp
# Example config file /etc/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
#
# Run standalone?  vsftpd can run either from an inetd or as a standalone
# daemon started from an initscript.
listen=NO
#
# This directive enables listening on IPv6 sockets. By default, listening
# on the IPv6 "any" address (::) will accept connections from both IPv6
# and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6
# sockets. If you want that (perhaps because you want to listen on specific
# addresses) then you must run two copies of vsftpd with two configuration
# files.
listen_ipv6=YES
#
# Allow anonymous FTP? (Disabled by default).
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
#write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
#local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# If enabled, vsftpd will display directory listings with the time
# in  your  local  time  zone.  The default is to display GMT. The
# times returned by the MDTM FTP command are also affected by this
# option.
use_localtime=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
#xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will 

Bug#1042555: glib2.0: Release 2.77.x to unstable

[Simon McVittie]

On Thu, 03 Aug 2023 at 07:24:17 -0400, Jeremy Bícha wrote:
> glib 2.77.1 appears to be the GNOME 45 Beta release. It has
> successfully migrated out of mantic-proposed in Ubuntu. I am unaware
> of any remaining blockers to landing it in Testing.

GLib is usually solid enough that I'm OK with uploading betas to unstable
in general (more so than GNOME Shell, for example). But,
https://release.debian.org/britney/pseudo-excuses-experimental.html#glib2.0
says that if the experimental version landed in unstable now, it would be
unable to migrate.

Maybe some of those failures can be addressed by a new upstream of the
dependent packages, and maybe some of them are flaky tests that just
need enough retries and will eventually succeed - I haven't tried to
analyze them yet. I think the blocker for GLib 2.77.x in unstable is
looking into those.

What I don't want is GLib 2.77.x sitting in unstable indefinitely,
unable to reach trixie, because there are regressions but nobody is
looking at them.

> Would you be comfortable if we uploaded it to Unstable now? Last
> cycle, the upstream maintainers were annoyed that distros didn't get
> more user testing sooner. I think they were talking more about Ubuntu
> and Fedora but maybe Debian can help there.

I think there are two big things on the GNOME team's to-do list:

* finishing GNOME 44 with the GNOME Shell 44 transition;
* starting GNOME 45 beta stuff, for which GLib is the first step

I don't think they necessarily have to block each other, but the release
team are going to be upset if one of them gets entangled in the other and
takes us a long time to sort out.

The GNOME Shell transition seems to be basically ready, consisting of:

* budgie-desktop
* gnome-remote-desktop
* gnome-shell
* gnome-shell-extensions
* mutter
* and then when the rest is ready to migrate, kicking out any remaining
  packages listed in
  
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gnome-shell-44
  from testing

Are you aware of anything else blocking those, or should I be opening a
transition-tracker bug?

smcv

Bug#1042913: freecad: TechDraw workbench: still persist in v. 0.20.2+dfsg1-7

[Luca]

Package: freecad
Version: 0.20.2+dfsg1-4
Followup-For: Bug #1042913
X-Debbugs-Cc: macgyv...@gmail.com

I had some time to setup a testing server to try the version from testing (did
not want to experiment with my production PC) and the problem is still there.


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.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 freecad depends on:
ii  freecad-python3  0.20.2+dfsg1-4

Versions of packages freecad recommends:
ii  calculix-ccx  2.20-1
ii  graphviz  2.42.2-7+b3

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#1041591: iris: Retry DRM_IOCTL_I915_GEM_EXECBUFFER2 on ENOMEM

[SuperCat]

I have backported this patch and applied it to my system. Tested for more
than 2 weeks and no crashes anymore.

diff --git a/src/gallium/drivers/iris/iris_batch.c
b/src/gallium/drivers/iris/iris_batch.c
index c7a08a0e1f5f0..deab85ce4aaf3 100644
--- a/src/gallium/drivers/iris/iris_batch.c
+++ b/src/gallium/drivers/iris/iris_batch.c
@@ -981,9 +981,14 @@ submit_batch(struct iris_batch *batch)
}

int ret = 0;
-   if (!batch->screen->devinfo.no_hw &&
-   intel_ioctl(batch->screen->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
))
-  ret = -errno;
+   if (!batch->screen->devinfo.no_hw) {
+  do {
+ ret = intel_ioctl(batch->screen->fd,
DRM_IOCTL_I915_GEM_EXECBUFFER2, );
+  } while (ret && errno == ENOMEM);
+
+  if (ret)
+ ret = -errno;
+   }

simple_mtx_unlock(bo_deps_lock);

Bug#1017819: iris: Retry DRM_IOCTL_I915_GEM_EXECBUFFER2 on ENOMEM

[SuperCat]

I have backported this patch and applied it to my system. Tested for more
than 2 weeks and no crashes anymore.

diff --git a/src/gallium/drivers/iris/iris_batch.c
b/src/gallium/drivers/iris/iris_batch.c
index c7a08a0e1f5f0..deab85ce4aaf3 100644
--- a/src/gallium/drivers/iris/iris_batch.c
+++ b/src/gallium/drivers/iris/iris_batch.c
@@ -981,9 +981,14 @@ submit_batch(struct iris_batch *batch)
}

int ret = 0;
-   if (!batch->screen->devinfo.no_hw &&
-   intel_ioctl(batch->screen->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
))
-  ret = -errno;
+   if (!batch->screen->devinfo.no_hw) {
+  do {
+ ret = intel_ioctl(batch->screen->fd,
DRM_IOCTL_I915_GEM_EXECBUFFER2, );
+  } while (ret && errno == ENOMEM);
+
+  if (ret)
+ ret = -errno;
+   }

simple_mtx_unlock(bo_deps_lock);

Bug#1042968: emacs: Gnus unusable after upgrading to Emacs 29

[Florent Rougon]

Package: emacs
Version: 1:29.1+1-2
Severity: normal

Dear maintainer,

This morning, I performed the following upgrade:

[UPGRADE] emacs:amd64 1:28.2+1-16 -> 1:29.1+1-2
[UPGRADE] emacs-bin-common:amd64 1:28.2+1-16 -> 1:29.1+1-2
[UPGRADE] emacs-common:amd64 1:28.2+1-16 -> 1:29.1+1-2
[UPGRADE] emacs-common-non-dfsg:amd64 1:28.2+1-2 -> 1:29.1+1-1
[UPGRADE] emacs-el:amd64 1:28.2+1-16 -> 1:29.1+1-2
[UPGRADE] emacs-gtk:amd64 1:28.2+1-16 -> 1:29.1+1-2

and rebooted because the kernel was also upgraded at the same time.
Since then, Gnus (the version shipped with Emacs) has become unusable
for me because every time I hit RET in the *Summary* buffer in order to
read a message, I get the following error:

gnus-configure-frame: Symbol’s value as variable is void: gnus-carpal

Redoing RET after `toggle-debug-on-error' yields the following
backtrace:

Debugger entered--Lisp error: (void-variable gnus-carpal)
  (if gnus-carpal '(summary-carpal 4))
  gnus-configure-frame((cond (gnus-use-trees '(vertical 1.0 (article 1.0) 
(summary 0.25 point) (tree 0.25))) (t '(vertical 1.0 (article 1.0) (summary 
0.25 point) (if gnus-carpal '(summary-carpal 4))
  gnus-configure-windows(article)
  gnus-summary-scroll-up(1)
  funcall-interactively(gnus-summary-scroll-up 1)
  command-execute(gnus-summary-scroll-up)

Surprisingly, clicking on the gnus-configure-frame “button” in the
backtrace shows (defun gnus-configure-frame ...) in
/usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz with *different code*:
there are a few (cond ...) forms but none that starts as
(cond (gnus-use-trees...).

$ ls -l /usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz 
/usr/share/emacs/29.1/lisp/gnus/gnus-win.elc
-rw-r--r-- 1 root root 11128 Aug  1 20:24 
/usr/share/emacs/29.1/lisp/gnus/gnus-win.elc
-rw-r--r-- 1 root root  5006 Jul 30 17:32 
/usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz
$ sha512sum /usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz
2fd828896c493913dd63586d39d559df679cda673c154ec5bbf421ff5ddc465815d830495c4aefaad5d306d0b4792bbd1b23754830a8cee83591006fe1ea6ceb
  /usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz

According to `C-h N', the `gnus-carpal' variable has been obsolete since
Emacs 24 and was removed in Emacs 29.1. If I evaluate
(setq gnus-carpal nil) in the *scratch* buffer, the problem doesn't
happen anymore — until Emacs is restarted, of course.

I tried 'aptitude reinstall emacs-el emacs-common' but this didn't
change anything to the problem.

Thanks for your work and help!

Regards

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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:29.1+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1042967: nheko crashes on first launch in arm64 (librem 5)

[Pirate Praveen]

Package: nheko
Version: 0.11.3-2+b1
severity: grave
justification: makes the app unusable

I initially noticed this on mobian bookworm (then I switched to 
chatty). Now I can reliable reproduce it on trixie as well.


Crash log attached.

To reproduce rm -rf .local/share/nheko .config/nheko .cache/nheko
and run nheko from terminal

First noticed when I reinstalled, flatpack also fails same way so looks 
like an upstream issue.


Second time, nheko starts but initial sync never completes. Both chatty 
and gomuks works with same matrix id.


[2023-08-03 17:42:55.678] [ui] [info] Restoring window size 0x0
[2023-08-03 17:42:55.759] [ui] [info] WebRTC: initialised GStreamer 1.22.4
[2023-08-03 17:42:55.883] [ui] [info] jdenticon plugin not found.
[2023-08-03 17:42:57.976] [ui] [info] starting nheko 0.11.3
[2023-08-03 17:42:57.986] [ui] [info] Unity service available: false
Error: signal 11:
nheko(_Z17stacktraceHandleri+0x40)[0xd55ee940]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
nheko(+0x973940)[0xd5433940]
nheko(+0x977090)[0xd5437090]
nheko(+0x9783bc)[0xd54383bc]
/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0(+0x55270)[0x9da25270]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x148)[0x9d83a6c8]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(+0x5aaa0)[0x9d83aaa0]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x34)[0x9d83ab44]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x54)[0x9deef6d8]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x13c)[0x9de89d2c]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x98)[0x9de933f8]
nheko(main+0xd14)[0xd526b684]
/lib/aarch64-linux-gnu/libc.so.6(+0x26dc0)[0x9d2a6dc0]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0x9d2a6e98]
nheko(_start+0x30)[0xd526c770]
Error: signal 6:
nheko(_Z17stacktraceHandleri+0x40)[0xd55ee940]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
/lib/aarch64-linux-gnu/libc.so.6(+0x7fd30)[0x9d2ffd30]
/lib/aarch64-linux-gnu/libc.so.6(gsignal+0x1c)[0x9d2b9e2c]
nheko(_Z17stacktraceHandleri+0xd8)[0xd55ee9d8]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
nheko(+0x973940)[0xd5433940]
nheko(+0x977090)[0xd5437090]
nheko(+0x9783bc)[0xd54383bc]
/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0(+0x55270)[0x9da25270]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x148)[0x9d83a6c8]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(+0x5aaa0)[0x9d83aaa0]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x34)[0x9d83ab44]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x54)[0x9deef6d8]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x13c)[0x9de89d2c]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x98)[0x9de933f8]
nheko(main+0xd14)[0xd526b684]
/lib/aarch64-linux-gnu/libc.so.6(+0x26dc0)[0x9d2a6dc0]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0x9d2a6e98]
nheko(_start+0x30)[0xd526c770]

Bug#1042965: py7zr: Remove unneeded build-depends on deprecate pep517

[Scott Kitterman]

Source: py7zr
Version: 0.11.3+dfsg-5
Severity: important
Tags: patch

The pep517 package has been superceded by python-pyproject-hooks.  It
looks like this package added a build-depends on python3-pep517
relatively early in our fielding of the ability to build Debian packages
based on pyproject.toml.  This build dependency is no longer needed and
can be simply removed.

I did test that the package built without it.  See the attached patch.
I am happy to address this as a team upload if you would prefer.  I will
soon be requesting removal of the pep517 package and I intend to bump
the severity of this when I do if it's not resolved by then.

Scott K
diff -Nru py7zr-0.11.3+dfsg/debian/changelog py7zr-0.11.3+dfsg/debian/changelog
--- py7zr-0.11.3+dfsg/debian/changelog  2023-03-25 18:50:07.0 -0400
+++ py7zr-0.11.3+dfsg/debian/changelog  2023-08-02 10:11:34.0 -0400
@@ -1,3 +1,10 @@
+py7zr (0.11.3+dfsg-6) unstable; urgency=medium
+
+  * Team upload.
+  * Drop build-depends on python3-pep517, deprecated, no longer needed
+
+ -- Scott Kitterman   Wed, 02 Aug 2023 10:11:34 -0400
+
 py7zr (0.11.3+dfsg-5) unstable; urgency=medium
 
   [ YOKOTA Hiroshi ]
diff -Nru py7zr-0.11.3+dfsg/debian/control py7zr-0.11.3+dfsg/debian/control
--- py7zr-0.11.3+dfsg/debian/control2023-03-25 18:50:07.0 -0400
+++ py7zr-0.11.3+dfsg/debian/control2023-08-02 10:06:35.0 -0400
@@ -6,7 +6,6 @@
 Build-Depends: debhelper-compat (= 13),
pybuild-plugin-pyproject,
python3-all-dev,
-   python3-pep517,
python3-pyannotate ,
python3-pycryptodome ,
python3-pytest ,

Bug#1042966: man pages: lint: bad-whatis-entry

[Bjarni Ingi Gislason]

Package: binutils-common
Version: 2.40.90.20230720-1
Severity: minor

Dear Maintainer,

  the whatis entry in the man page database is defective,

"man -k html" shows for example:

gp-display-html (1)  - (unknown subject)

-.-.

Example from gp-display-html.1.gz:

.TH GP-DISPLAY-HTML.1 1 "2023-07-20" "binutils-2.40.90" "User Commands"

  and

.SH "NAME"
gprofng display html \- Generate an HTML based directory structure to browse 
the profiles

-.-.

The name in "NAME" ('gprofng display html') should be the same as in .TH
(gp-display-html) and should be _ONE_ word.

  The same is the case with other man pages in this package.

  See lexgrog(1).

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

Kernel: Linux 6.4.4-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#1024695: also debian-ispell

[David Bremner]

Dan Jacobson  writes:

> ⛔ Warning (comp): debian-el.el:90:26: Warning: reference to free variable 
> ‘dired-mode-map’
> ⛔ Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of 
> unescaped single quotes (use \= or different quoting)
> ⛔ Warning (comp): debian-ispell.el:420:16: Warning: reference to free 
> variable ‘ispell-program-name’
> ⛔ Warning (comp): debian-ispell.el:427:16: Warning: reference to free 
> variable ‘ispell-dictionary’
> ⛔ Warning (comp): debian-ispell.el:429:11: Warning: assignment to free 
> variable ‘ispell-base-dicts-override-alist’
> ⛔ Warning (comp): debian-ispell.el:437:24: Warning: reference to free 
> variable ‘ispell-base-dicts-override-alist’
> ⛔ Warning (comp): debian-ispell.el:475:9: Warning: reference to free variable 
> ‘ispell-dictionary’
> ⛔ Warning (comp): debian-ispell.el:489:18: Warning: reference to free 
> variable ‘ispell-program-name’

As I'm sure you know, that's a different package, maintained by a
different person.

Bug#1042921: glib log feature

[Jonas Smedegaard]

Quoting Matthias Geiger (2023-08-03 12:18:32)
> Sorry, I patched out the log dependency (and subsequent features) 
> absentminded.
> 
> A fixed version is uploaded and should hit the buildds / archive soon.

Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#1036051: working riscv64 patch

[Ritesh Raj Sarraf]

On Wed, 2023-08-02 at 06:45 +0200, Matthias Klose wrote:
> here is a working patch:
> https://patches.ubuntu.com/b/bpfcc/bpfcc_0.26.0+ds-1ubuntu2.patch
> 
> need to exclude the tools dir as done for other architectures, both
> in 
> debian/rules and debian/control

Thank you. I'll prepare something for Debian Experimental to start
with.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#1042555: glib2.0: Release 2.77.x to unstable

[Jeremy Bícha]

Simon,

glib 2.77.1 appears to be the GNOME 45 Beta release. It has
successfully migrated out of mantic-proposed in Ubuntu. I am unaware
of any remaining blockers to landing it in Testing.

Would you be comfortable if we uploaded it to Unstable now? Last
cycle, the upstream maintainers were annoyed that distros didn't get
more user testing sooner. I think they were talking more about Ubuntu
and Fedora but maybe Debian can help there.

Thank you,
Jeremy Bícha