Bug#1050212: [ITP]: python3-ajsonrpc -- Python JSON-RPC 2.0 implementation and asynchronous server powered by asyncio

[Peter Zahradnik]

Package: wnpp
Severity: wishlist

* Package name: python3-ajsonrpc
  Version : 1.2.0
  Upstream Author : Kirill Pavlov 
* URL : https://github.com/pavlov99/ajsonrpc
* License : MIT
  Programming Lang: Python
 
 salsa: https://salsa.debian.org/python-team/packages/ajsonrpc

 JSON-RPC 2.0 implementation and asynchronous server powered by asyncio
 ajsonrpc is Lightweight JSON-RPC 2.0 protocol implementation and
 asynchronous server powered by asyncio. This library is a successor of
 json-rpc and written by the same team.
 
 Features:
  - Full JSON-RPC 2.0 implementation
  - Async request manager that handles the protocol
  - Vanilla Python, no dependencies
  - API server setup in 1 min
  - Same development team as json-rpc, largely compatible code
 

Bug#1050211: openvpn-dco-dkms: module fails to build for kernel 6.4.0: fatal error: net/gso.h: No such file or directory

[Carl Suster]

Package: openvpn-dco-dkms
Version: 0.0+git20230816-1
Severity: important

Dear Maintainer,

The module does not build in kernel 6.4.0 due to the file net/gso.h not being
found. I note that this is the same file introduced by the fix for #1043116.
Log follows.

  DKMS make.log for ovpn-dco-0.0+git20230816 for kernel 6.4.0-2-amd64 (x86_64)
  Tue 22 Aug 2023 14:49:19 AEST
  /var/lib/dkms/ovpn-dco/0.0+git20230816/build/gen-compat-autoconf.sh 
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/compat-autoconf.h
  make -C /lib/modules/6.4.0-2-amd64/build 
M=/var/lib/dkms/ovpn-dco/0.0+git20230816/build 
PWD=/var/lib/dkms/ovpn-dco/0.0+git20230816/build REVISION=0.0+git20230816 
CONFIG_OVPN_DCO_V2=m INSTALL_MOD_DIR=updates/   modules
  make[1]: Entering directory '/usr/src/linux-headers-6.4.0-2-amd64'
CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/main.o
CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/bind.o
CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/crypto.o
CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.o
  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.c:25:10: 
fatal error: net/gso.h: No such file or directory
 25 | #include 
|  ^~~
  compilation terminated.
  make[3]: *** 
[/usr/src/linux-headers-6.4.0-2-common/scripts/Makefile.build:257: 
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.o] Error 
1
  make[3]: *** Waiting for unfinished jobs
  make[2]: *** 
[/usr/src/linux-headers-6.4.0-2-common/scripts/Makefile.build:499: 
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco] Error 2
  make[1]: *** [/usr/src/linux-headers-6.4.0-2-common/Makefile:2051: 
/var/lib/dkms/ovpn-dco/0.0+git20230816/build] Error 2
  make[1]: Leaving directory '/usr/src/linux-headers-6.4.0-2-amd64'
  make: *** [Makefile:59: all] Error 2


Carl


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

Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
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: AppArmor: enabled

Versions of packages openvpn-dco-dkms depends on:
ii  dkms  3.0.11-3

openvpn-dco-dkms recommends no packages.

openvpn-dco-dkms suggests no packages.

-- no debconf information

Bug#1050210: libssl3: include the fips provider

[Peter Eisentraut]

Package: libssl3
Version: 3.0.9-1
Severity: wishlist

Please include the fips provider module in this package.

This fips provider has now been certified, so more people are looking to 
use it.


(Conversely, it is confusing that the openssl package currently installs 
the "openssl-fipsinstall" program but not the module that that program 
is supposed to install.  If there is a problem with shipping the module, 
then the documentation that claims you can use it should not be included 
in the package.)

Bug#1049460: Undefined Opcode exception at EFI Shell after launching KeyTool.efi (armhf) binary

[Shivanand.Kunijadar]

Dear Maintainer,

Kindly check the additional information regarding this issue which might be 
helpful for analysis.

I’ve checked below binaries from the efitools:armhf package,

  *   Binaries can run without the exception (not fully tested, just ran the 
binary to check the errors)
 *   HelloWorld.efi
 *   Loader.efi
 *   LockDown.efi
 *   ShimReplace.efi
  *   Binaries fails with the same exception
 *   KeyTool.efi
 *   HashTool.efi
 *   ReadVars.efi
 *   SetNull.efi
 *   UpdateVars.efi

Note: The Undefined OpCode exception never happens with arm64 binaries, so it's 
armhf specific problem
Thanks & Regards
Shivanand K

Bug#1048754: samba: Fails to build source after successful build

[Michael Tokarev]

Version: 2:4.18.6+dfsg-1

13.08.2023 22:21, Lucas Nussbaum wrote:
...

dpkg-source: error: cannot represent change to 
source4/scripting/bin/__pycache__/gen_error_common.cpython-311.pyc: binary file 
contents changed


This is fixed by 4.18.6+dfsg-1 upload by I forgot to add
changelog entry for this:

+  * d/rules: export PYTHONDONTWRITEBYTECODE=1 to stop python from generating
+.pyc caches (Closes: #1048754)

(added now, closing this bugreport).

/mjt

Bug#1050208: libc6: double free detected in tcache 2, then abort

[Paul Szabo]

Package: libc6
Version: 2.36-9+deb12u1
Severity: important

Dear Maintainer,

I noticed an issue with malloc() or free(). I only noticed this
recently, with libc6 version 2.36-9+deb12u1; reverting to previous
2.36-9 did not seem to help.

The issue: sending SIGHUP to the inetd process (from package
openbsd-inetd version 0.20221205-1) should cause it to re-load its
configuration, but instead it elicits

  free(): double free detected in tcache 2

and an abort. This is easiest seen (after "systemctl stop inetd") with

  root# inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs
  [1] 2431
  ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 
server=/usr/sbin/identd
  free(): double free detected in tcache 2
  [1]+  Aborted inetd -d -i
  root# 

I believe that this "double free" is spurious, as there are no errors
(but inetd reloads as expected) when using e.g.

  root# LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=1 inetd -d -i & sleep 1; 
kill -HUP $!; sleep 1; jobs; kill $!; sleep 1; jobs
  [1] 2437
  ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 
server=/usr/sbin/identd
  REDO: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 
server=/usr/sbin/identd
  [1]+  Running LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 
inetd -d -i &
  [1]+  DoneLD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 
inetd -d -i
  root# 

No errors are shown with any value of MALLOC_CHECK_ from 0 to 20, or
even without any MALLOC_CHECK_ but with just LD_PRELOAD so with

  root# LD_PRELOAD=libc_malloc_debug.so inetd -d -i & sleep 1; kill -HUP $!; 
sleep 1; jobs; kill $!; sleep 1; jobs

Instead of LD_PRELOAD, some glibc tunables can also help to avoid the
"double free" error. The settings that I found to help were:

  GLIBC_TUNABLES=glibc.malloc.tcache_count=0
  GLIBC_TUNABLES=glibc.malloc.tcache_count=1

whereas none of the following helped:

  GLIBC_TUNABLES=glibc.malloc.tcache_count=2# or 3, 4, ...
  GLIBC_TUNABLES=glibc.cpu.hwcaps=-avx
  GLIBC_TUNABLES=glibc.cpu.hwcaps=-sse
  GLIBC_TUNABLES=glibc.cpu.hwcap_mask=1099511627775

The issue is present on all of my machines that boot from "disk", with
amd64 or i386 architectures (both using an amd64 kernel, custom-built
from linux-source version 6.1.38-4); some of these are VMs inside
VirtualBox. I hope that the issue can be reproduced elsewhere.
Curiously, the issue does not seem present on same machines when booting
PXE and then NFS-mounted root (similar to LTSP), though the contents of
/usr/lib seem identical whether booting from disk or PXE; the PXE boot
sequence uses sysvinit, not systemd.

Thanks Aurelien for suggesting the glibc tunables (in bug #1041836).
Did not try gdb since I am not proficient with it, would not know what
to look for. Please suggest anything else I should try.

Thanks, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia



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

Kernel: Linux 6.1+pk12.06 (SMP w/12 CPU threads; 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)

Versions of packages libc6 depends on:
ii  libgcc-s1  12.2.0-14

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.3-1+b1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.82
ii  glibc-doc  2.36-9+deb12u1
ii  libc-l10n  2.36-9+deb12u1
ii  libnss-nis 3.1-4
ii  libnss-nisplus 1.3-4
ii  locales2.36-9+deb12u1

-- debconf information:
  glibc/restart-failed:
* glibc/upgrade: true
  glibc/kernel-not-supported:
  glibc/disable-screensaver:
* libraries/restart-without-asking: true
  glibc/kernel-too-old:
  glibc/restart-services:

Bug#1050207: fcitx5-pinyin-gui/experimental: undeclared file conflict with fcitx5-pinyin/unstable

[Helmut Grohne]

Package: fcitx5-pinyin-gui
Version: 5.1.0-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 fcitx5-pinyin

fcitx5-pinyin-gui/experimental and fcitx5-pinyin/unstable both contain
the file /usr/lib/x86_64-linux-gnu/fcitx5/qt5/libpinyindictmanager.so.
As such, dpkg could be unpacking them concurrently and cause an unpack
error. According to debian/changelog, this is a package split. Please
add the necessary Breaks and Replaces declarations.

Helmut

Bug#1050206: rust-test-case: Failed autopkgtest after 3.1.0-3

[Simon Quigley]

Hello,

Since Jonas is in LowNMU, I've uploaded this patch to DELAYED/2 and committed 
it in Git.

Jonas, feel free to cancel the upload (or tell me to) if you have a better 
solution.

Thank you!

--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1040837: rust-log situation update.

[Peter Green]

A bunch of packages just cleared new, and I made a bunch of follow up uploads.
The result is that the situation surrounding the log package has improved
a bit, but it still less than ideal.

The "kv_unstable" and "kv_unstable_sval" features are now enabled, the
"kv_unstable_serde" feature is currently disabled because it requires
the serde feature in the value-bag package, which in turn requires the
serde1 feature in the value-bag-serde1 crate, which in turn requires the
sval_serde crate which is not currently in debian.

I belive the net result of this is that

* kv-log-macro's binary dependencies are  satisfiable but it's 
build-dependencies are not.
* femme's dependencies and build-dependencies are still unsatisfiable.

Looking in the debcargo-conf repository it seems that Fabian Grünbichler
has made a start on packaging sval_serde.

Fabian: is sval-serde ready for sponsorship? if so can you add the RFS
file?

Bug#1025568: gparted: diff for NMU version 1.3.1-1.1

[Hugh McMaster]

On Tue, 22 Aug 2023 at 05:26, Phillip Susi wrote:
>
> I have an upload of 1.5 pending my sorting my gpg key out again.  Could
> you submit any changes as a PR on salsa?  I think I saw someone had done
> that for some minor issues ( was that you? ) but the CI failed.

The only change in the NMU was switching (build-)dependencies from
policykit-1 to pkexec. I can see that you've now committed that change
to the salsa repository, along with some other changes.

I didn't see a need to build-depend on libpolkit-gobject-1-dev, but
I'm not overly familiar with gparted's requirements.

Please let me know if I should submit a PR for the NMU on salsa
(noting you'd have to update the changelog to account for your recent
changes), or whether I should cancel the upload.

Bug#1049457: fuser(1) not working on libraries, possibly because of disagreement over minor device

[Paul Kimoto]

On Wed, Aug 16, 2023 at 11:03:14PM -0400, Paul Kimoto wrote:
> On Wed, Aug 16, 2023 at 05:25:26PM +1000, Craig Small wrote:
>> What does
>> grep -e ' 0:2[57] ' /proc/self/mountinfo
>> show?
> 
> 29 1 0:25 /@rootfs / rw,relatime shared:1 - btrfs /dev/sda3
>   rw,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/@rootfs

FWIW, fuser from psmisc-23.4 configured with
"--enable-mountinfo-list" produces the kind of output I expect.
(Without "--enable-mountinfo-list", it doesn't.)

Bug#1050206: rust-test-case: Failed autopkgtest after 3.1.0-3

[Zixing Liu]

Package: rust-test-case
Version: 3.1.0-3
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
X-Debbugs-Cc: zixing@canonical.com

Dear Maintainer,

After updating rust-test-case to 3.1.0-3, the autopkgtest no longer passes due
to a typo in the Provides field in debian/control.

In Ubuntu, the attached patch was proposed to achieve the following:

  * fix a typo in the Provides field;
this fixes the autopkgtest

Thanks for considering the patch.

Thanks,
Zixing

Bug#1045582: rust-test-case: Failed autopkgtest after 3.1.0-3

[Zixing Liu]

Package: rust-test-case
Followup-For: Bug #1045582
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
X-Debbugs-Cc: zixing@canonical.com
Control: tags -1 patch

Dear Maintainer,

After updating rust-test-case to 3.1.0-3, the autopkgtest no longer passes due
to a typo in the Provides field in debian/control.

In Ubuntu, the attached patch was proposed to achieve the following:

  * fix a typo in the Provides field;
this fixes the autopkgtest

Thanks for considering the patch.

Thanks,
Zixing
diff -Nru rust-test-case-3.1.0/debian/control 
rust-test-case-3.1.0/debian/control
--- rust-test-case-3.1.0/debian/control 2023-08-20 03:24:41.0 -0600
+++ rust-test-case-3.1.0/debian/control 2023-08-21 19:23:25.0 -0600
@@ -45,7 +45,7 @@
  librust-test-case-core-3.1-dev (= ${binary:Version}),
  librust-test-case-core-3.1.0-dev (= ${binary:Version}),
  librust-test-case-macros-3+default-dev (= ${binary:Version}),
- librust-test-case-macros-3+with-regex (= ${binary:Version}),
+ librust-test-case-macros-3+with-regex-dev (= ${binary:Version}),
  librust-test-case-macros-3-dev (= ${binary:Version}),
  librust-test-case-macros-3.1-dev (= ${binary:Version}),
  librust-test-case-macros-3.1.0-dev (= ${binary:Version}),

Bug#1050205: wlsunset: Out of date package

[Mae Miller]

Package: wlsunset
Version: 0.2.0-2
Severity: wishlist

Dear Maintainer,

As per suggestion from the debian-mentors channel, I'm filing a bug
report for this package being out of date. I accidentally made my own local 
version of the updated version and it seems there's no complications with the 
new version that I can see. Please excuse me if this is improper procedure 
though.

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

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

Versions of packages wlsunset depends on:
ii  libc6   2.36-9+deb12u1
ii  libwayland-client0  1.21.0-1

wlsunset recommends no packages.

wlsunset suggests no packages.

-- no debconf information

-- 
Mae Miller (it/she)

Bug#1050204: RFS: streamlink/6.1.0-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.1.0.

  * Package name: streamlink
Version : 6.1.0-1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs  : https://github.com/wxMaxima-developers/wxmaxima
Section : python

It builds those binary packages:

   python3-streamlink - Python module for extracting video streams from 
various websites
   python3-streamlink-doc - CLI for extracting video streams from 
various websites (documentation)
   streamlink - CLI for extracting video streams from various websites 
to a video player


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


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

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

   dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.1.0-1.dsc


Changes since the last upload to unstable:
streamlink (6.1.0-1) unstable; urgency=medium

   * d/clean: remove docs/_build directory (Closes: 1045365)
   * d/source/options: add extend-diff-ignore to fix dpkg-source failure
 due to local changes (python package metadata regeneration)
   * New upstream version 6.1.0
   * d/patches: fix screenshot link for Streamlink Twitch GUI

  -- Alexis Murzeau   Sun, 20 Aug 2023 12:12:58 +0200



Regards,
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F




OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050203: bsd-mailx and selinux not co-operating

[Bhasker C V]

Package: bsd-mailx

Version: 8.1.2-0.20220412cvs-1


In follow-up to https://groups.google.com/g/linux.debian.user/c/vsYHlu728Ig


$ echo hello | mail -s test xx...@yyy.xyz 
2023-08-20 14:39:30 1qXieQ-000Bpa-1P 1qXieQ-000Bpa-1P no recipients 
found in headers

Can't send mail: sendmail process failed with error code 1


however the same works fine when I put selinux in permissive state (no 
warnings shown in audit/dmesg).

This is NOT a configuration issue but looks like selinux compatibility issue

A quick ltrace says

1qXia0-000BPb-0a Failed to create spool file 
/var/spool/exim4//input//1qXia0-000BPb-0a-D: Permission denied



However there are no avc: messages for me to allow this through in my 
selinux module

I even tried a custom policy

allow unconfined_t exim_spool_t:file { open read write create };
allow unconfined_t exim_spool_t:dir { open read write };


since /var/spool/exim4/input has exim_spool_dir set in it
ls -lZd

drwxr-x---. 2 Debian-exim Debian-exim system_u:object_r:exim_spool_t:s0 
4096 Aug 22 00:10 /var/spool/exim4/input


I cant fine any booleans either ..

Many scripts including chkrootkit and tripwire are failing because mail 
cannot send mails(becauses debian uses bsd-mailx as default)


--
Bhasker C V
Secure Mails:http://keys.gnupg.net/pks/lookup?op=get=0x4D05FEEC54E47413
Registered Linux User: #306349

Bug#1050162: debootstrap: fix loong64 usrmerge

[Johannes Schauer Marin Rodrigues]

Hi,

On Mon, 21 Aug 2023 16:09:00 +0800 Han Gao  wrote:
>   Fix loong64 usrmerge recognize.

thank you for your patch but the function you changed is no longer used to
create the merged-/usr symlinks. The new approach creates those symlinks after
unpacking the essential packages and no longer carries an architecture specific
list of directories. With the new approach, things should just work. Can you
try out debootstrap 1.0.130 or later and confirm?

You can find more details about the new merged-/usr approach in this merge
request:

https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1050117: /usr/share/bug/linux-image-6.4.0-0.deb12.2-686-pae-unsigned/include-1cmdline: poweroff (shutdown -h) / reboot (shutdown -r) does not work properly.

[Takashi Yano]

On Sun, 20 Aug 2023 16:08:30 +0900
Takashi Yano wrote:
> I tried various kernel versions and the results are as follows.
> 
> linux-image-5.19.0-0.deb11.2-686-pae 5.19.11-1~bpo11+1  : OK
> linux-image-6.0.0-0.deb11.2-686-pae  6.0.3-1~bpo11+1: OK
> linux-image-6.1.0-0.deb11.5-686-pae  6.1.12-1~bpo11+1   : OK
> linux-image-6.1.0-0.deb11.7-686-pae  6.1.20-2~bpo11+1   : OK
> linux-image-6.1.0-10-686-pae 6.1.38-2   : NG
> linux-image-6.1.0-11-686-pae 6.1.38-4   : NG
> linux-image-6.4.0-0.deb12.2-686-pae-unsigned 6.4.4-3~bpo12+1: NG
> linux-image-6.4.0-2-686-pae  6.4.4-3: NG
> linux-image-6.5.0-0-686-pae-unsigned 6.5~rc6-1~exp1 : NG
> 
> OK: Works without the problem.
> NG: Has the problem.
> 
> It seems that kernels built for bullseye do not have this issue.
> Or maybe the kernel before 6.1.0-0 works.

I have tried another kernel:
linux-image-6.1.0-0.deb11.9-686-pae-unsigned 6.1.27-1~bpo11+1   : NG

The built date are:
linux-image-6.1.0-0.deb11.7-686-pae   2023-05-22 11:37
linux-image-6.1.0-0.deb11.9-686-pae-unsigned  2023-07-18 17:29

It seems that the recent (in a few months) change in the kernel causes
this issue.

-- 
Takashi Yano 

Bug#1050202: ~/.manpath: bleeding-edge man does not use options from "DEFINE nroff -ww ..."

[Bjarni Ingi Gislason]

Package: man-db
Version: 2.11.2-3
Severity: normal

Dear Maintainer,

N.B. VERSION IS 2.12.0-pre2


Example:

In ~/.manpath

DEFINE nroff -b -ww -mandoc

  Inputfile

.TH XX-test 1 2023-08-21
.XX something

  man (man 2.12.0-pre2) is from the repository

man -l 

  Output

IX-test(1)General Commands Manual  
IX-test(1)

2023-08-21 
IX-test(1)

  but /usr/bin/man (man 2.11.2)  shows

troff: backtrace: file '':2
troff::2: warning: macro 'XX' not defined
IX-test(1)General Commands Manual  
IX-test(1)

2023-08-21 
IX-test(1)

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

Kernel: Linux 6.4.4-2 (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)

Versions of packages man-db depends on:
ii  bsdextrautils  2.39.1-4
ii  bsdmainutils   12.1.8
ii  debconf [debconf-2.0]  1.5.82
ii  groff-base 1.23.0-2
ii  libc6  2.37-7
ii  libgdbm6   1.23-3
ii  libpipeline1   1.5.7-1
ii  libseccomp22.5.4-1+b3
ii  zlib1g 1:1.2.13.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor   
ii  elinks [www-browser]   0.16.1.1-4
ii  firefox-esr [www-browser]  115.1.0esr-1
ii  groff  1.23.0-2
ii  less   590-2
ii  lynx [www-browser] 2.9.0dev.12-1
ii  w3m [www-browser]  0.5.3+git20230121-2

-- Configuration Files:
/etc/manpath.config changed [not included]

-- debconf information:
  man-db/auto-update: true
  man-db/install-setuid: false

Bug#1033828: mono-xbuild: Mono packages should provide msbuild instead of xbuild

[Linus Lüssing]

Package: mono-devel
Version: 6.8.0.105+dfsg-3.3
Followup-For: Bug #1033828
X-Debbugs-Cc: linus.luess...@c0d3.blue

Hi,

Just wanted to add that trying to build OpenRA currently fails with the
following error for me:

```
$ make RUNTIME=mono
Compiling in Release mode...
OpenRA requires the 'msbuild -verbosity:m -nologo' tool provided by Mono >= 
6.12.
make: *** [Makefile:94: all] Error 1
make RUNTIME=mono  0.00s user 0.01s system 96% cpu 0.017 total
```

Its INSTALL.md suggests to update and install mono from the mono
project's Debian package repository:

https://github.com/OpenRA/OpenRA/blob/bleed/INSTALL.md#linux

It would be great if mono could be updated to 6.12 and could add
"msbuild" in Debian directly to hopefully fix this issue, without
needing to resort to an alternative package repository.

Regards, Linus


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

Kernel: Linux 6.4.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 mono-devel depends on:
ii  ca-certificates-mono  6.8.0.105+dfsg-3.3
ii  libc6 2.37-6
ii  libmono-2.0-dev   6.8.0.105+dfsg-3.3
ii  libmono-cecil-private-cil 6.8.0.105+dfsg-3.3
ii  libmono-cil-dev   6.8.0.105+dfsg-3.3
ii  libmono-codecontracts4.0-cil  6.8.0.105+dfsg-3.3
ii  libmono-compilerservices-symbolwriter4.0-cil  6.8.0.105+dfsg-3.3
ii  libmono-corlib4.5-cil 6.8.0.105+dfsg-3.3
ii  libmono-peapi4.0a-cil 6.8.0.105+dfsg-3.3
ii  libmono-relaxng4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-security4.0-cil   6.8.0.105+dfsg-3.3
ii  libmono-system-componentmodel-composition4.0-cil  6.8.0.105+dfsg-3.3
ii  libmono-system-componentmodel-dataannotations4.0-cil  6.8.0.105+dfsg-3.3
ii  libmono-system-configuration-install4.0-cil   6.8.0.105+dfsg-3.3
ii  libmono-system-configuration4.0-cil   6.8.0.105+dfsg-3.3
ii  libmono-system-core4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-data-datasetextensions4.0-cil  6.8.0.105+dfsg-3.3
ii  libmono-system-data4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-drawing4.0-cil 6.8.0.105+dfsg-3.3
ii  libmono-system-identitymodel4.0-cil   6.8.0.105+dfsg-3.3
ii  libmono-system-io-compression-filesystem4.0-cil   6.8.0.105+dfsg-3.3
ii  libmono-system-io-compression4.0-cil  6.8.0.105+dfsg-3.3
ii  libmono-system-net-http4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-numerics4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-runtime-serialization4.0-cil   6.8.0.105+dfsg-3.3
ii  libmono-system-runtime4.0-cil 6.8.0.105+dfsg-3.3
ii  libmono-system-security4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-servicemodel4.0a-cil   6.8.0.105+dfsg-3.3
ii  libmono-system-serviceprocess4.0-cil  6.8.0.105+dfsg-3.3
ii  libmono-system-transactions4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-web-services4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-web4.0-cil 6.8.0.105+dfsg-3.3
ii  libmono-system-xml-linq4.0-cil6.8.0.105+dfsg-3.3
ii  libmono-system-xml4.0-cil 6.8.0.105+dfsg-3.3
ii  libmono-system4.0-cil 6.8.0.105+dfsg-3.3
ii  mono-gac  6.8.0.105+dfsg-3.3
ii  mono-mcs  6.8.0.105+dfsg-3.3
ii  mono-runtime  6.8.0.105+dfsg-3.3
ii  mono-xbuild   6.8.0.105+dfsg-3.3
ii  pkg-config1.8.1-1
ii  pkgconf [pkg-config]  1.8.1-1

Versions of packages mono-devel recommends:
ii  mono-csharp-shell  6.8.0.105+dfsg-3.3

mono-devel suggests no packages.

-- no debconf information

Bug#1040864: doxygen: upcoming FTBFS with cairo >= 1.17.6

[Jeremy Bícha]

> many thanks for the timely heads-up and for the research. I think the
> best would be to just upgrade to 1.9.7.

Paolo,

Here's a reminder about packaging doxygen 1.9.7. I am waiting to
upload cairo 1.17 to Unstable until this doxygen issue is fixed first.

Thank you,
Jeremy Bícha

Bug#1050201: seabios: Consider using the standard dh sequence in d/rules

[Gioele Barabucci]

Package: src:seabios
Version: 1.16.2-1
Severity: wishlist
Tags: patch

Dear seabios maintainers,

this package currently uses debhelper with an ad-hoc sequence of steps 
in d/rules. This long list of steps can be shortened and greatly 
simplified by using the standard dh sequence.


You can find a MR that changes `d/rules` to use the standard dh sequence at:

https://salsa.debian.org/qemu-team/seabios/-/merge_requests/4

According to diffoscope, the generated binary package is identical to 
the current one.


--
Gioele Barabucci

Bug#1050200: bridge-utils: Consider using the standard dh sequence in d/rules

[Gioele Barabucci]

Package: src:bridge-utils
Version: 1.7.1-1
Severity: wishlist
Tags: patch

Dear bridge-utils maintainers,

this package currently uses debhelper with an ad-hoc sequence of steps 
in d/rules. This long list of steps can be shortened and greatly 
simplified by using the standard dh sequence.


You can find a MR that changes `d/rules` to use the standard dh sequence at:

https://salsa.debian.org/manty/bridge-utils/-/merge_requests/2

According to diffoscope, the generated binary package is identical to 
the current one.


--
Gioele Barabucci

Bug#1037887: bug#1037887: vtk9: ftbfs with GCC-13

[Aurelien Jarno]

control: tag -1 + pending

Dear maintainer,

On 2023-08-21 14:33, Aurelien Jarno wrote:
> On 2023-06-14 09:32, Matthias Klose wrote:
> > Package: src:vtk9
> > Version: 9.1.0+really9.1.0+dfsg2-5
> > Severity: normal
> > Tags: sid trixie
> > User: debian-...@lists.debian.org
> > Usertags: ftbfs-gcc-13
> > 
> > [This bug is targeted to the upcoming trixie release]
> > 
> > Please keep this issue open in the bug tracker for the package it
> > was filed for.  If a fix in another package is required, please
> > file a bug for the other package (or clone), and add a block in this
> > package. Please keep the issue open until the package can be built in
> > a follow-up test rebuild.
> > 
> > The package fails to build in a test rebuild on at least amd64 with
> > gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
> > severity of this report will be raised before the trixie release.
> 
> The following upstream patch fixes the issue:
> https://gitlab.kitware.com/vtk/vtk/-/commit/1233ceec268d5366c66f5e79786ec784042b591b
> 

I've prepared an NMU for vtk9 (versioned as 9.1.0+really9.1.0+dfsg2-6.1)
to fix this FTBFS, you will find the corresponding diff attached. I have
uploaded it to DELAYED/2. Please feel free to tell me if I should delay
it further or cancel it.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
diff -Nru vtk9-9.1.0+really9.1.0+dfsg2/debian/changelog vtk9-9.1.0+really9.1.0+dfsg2/debian/changelog
--- vtk9-9.1.0+really9.1.0+dfsg2/debian/changelog	2023-06-22 05:14:50.0 +
+++ vtk9-9.1.0+really9.1.0+dfsg2/debian/changelog	2023-08-21 21:27:16.0 +
@@ -1,3 +1,12 @@
+vtk9 (9.1.0+really9.1.0+dfsg2-6.1) unstable; urgency=medium
+
+  [ Aurelien Jarno ]
+  * Non-maintainer upload.
+  * Backport patch from upstream to fix GCC 13 compatibility. (Closes:
+#1037887).
+
+ -- Aurelien Jarno   Mon, 21 Aug 2023 23:27:16 +0200
+
 vtk9 (9.1.0+really9.1.0+dfsg2-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru vtk9-9.1.0+really9.1.0+dfsg2/debian/patches/130_gcc13.patch vtk9-9.1.0+really9.1.0+dfsg2/debian/patches/130_gcc13.patch
--- vtk9-9.1.0+really9.1.0+dfsg2/debian/patches/130_gcc13.patch	1970-01-01 00:00:00.0 +
+++ vtk9-9.1.0+really9.1.0+dfsg2/debian/patches/130_gcc13.patch	2023-08-21 21:12:28.0 +
@@ -0,0 +1,34 @@
+From 1233ceec268d5366c66f5e79786ec784042b591b Mon Sep 17 00:00:00 2001
+From: Laurent Rineau 
+Date: Tue, 17 Jan 2023 16:18:53 +0100
+Subject: [PATCH] Add #include  to compile with gcc13
+
+The `vtkSEPReader` was introduced by MRs !4909 (from my former
+collaborator Maxime) and !4938. Then it was highly modified by
+!7516. The later MR is the one that introduced the uses of
+`std::uint8_t` and `std::uint32_t`.
+
+Those types needs the inclusion of ``.
+---
+ IO/Image/vtkSEPReader.h | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/IO/Image/vtkSEPReader.h b/IO/Image/vtkSEPReader.h
+index a7d8aad1510..37d0c44d18c 100644
+--- a/IO/Image/vtkSEPReader.h
 b/IO/Image/vtkSEPReader.h
+@@ -25,8 +25,9 @@
+ #include "vtkImageAlgorithm.h"
+ #include "vtkNew.h" // for ivars
+ 
+-#include   // for std::array
+-#include  // for std::string
++#include// for std::array
++#include  // for std::uint8_t and std::uint32_t
++#include   // for std::string
+ 
+ namespace details
+ {
+-- 
+GitLab
+
diff -Nru vtk9-9.1.0+really9.1.0+dfsg2/debian/patches/series vtk9-9.1.0+really9.1.0+dfsg2/debian/patches/series
--- vtk9-9.1.0+really9.1.0+dfsg2/debian/patches/series	2023-06-22 05:12:22.0 +
+++ vtk9-9.1.0+really9.1.0+dfsg2/debian/patches/series	2023-08-21 21:25:56.0 +
@@ -12,3 +12,4 @@
 99_fix_ftbfs.patch
 110_vtk9_netcdf.patch
 120_fix_shader_crash.patch
+130_gcc13.patch


signature.asc
Description: PGP signature

Bug#1004112: libunwind-13-dev: Issues when replacing libunwind-dev

[Vadim Zeitlin]

 Sorry but this bug isn't fixed at all: it is possible to keep
libgstreamer1.0-dev installed when installing libc++-dev now, but it's
still impossible to actually use it because libunwind-dev (the not-llvm
version libgstreamer1.0-dev depends on) is still uninstalled and then any
attempt to use libgstreamer via pkg-config result in

Package 'libunwind', required by 'gstreamer-1.0', not found

and it still can't be used.

 I have no idea about it but it remains impossible to use libc++ and
gstreamer on the same system which is a rather bad limitation.

 If anybody has any suggestions for a workaround, they would be very
welcome, TIA!
VZ

Bug#1050199: RM: cbedic -- RoQA; no dictionaries available; orphaned; dead upstream; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:cbedic

Please remove cbedic. Its dictionaries were removed with kbedic, so it 
is not useful anymore. The package is dead upstream, is orphaned, and 
has a very low popcon.

Bug#433326: RFA: cbedic -- Text-mode Bulgarian/English Dictionary

[Bastian Germann]

Control: retitle -1 O: cbedic -- Text-mode Bulgarian/English dictionary

Am 05.12.22 um 22:41 schrieb Bastian Germann:

kbedic was removed from the archive. Should cbedic also be removed?


I am orphaning and am going to file a removal request.

Bug#1050198: xapers complains: DeprecationWarning: pkg_resources is deprecated as an API

[Daniel Kahn Gillmor]

Package: xapers
Version: 0.9.0-1

I see the following warning when i use "xapers add" :

```
Running 
/usr/bin/xapers:6: DeprecationWarning: pkg_resources is deprecated as an API. 
See https://setuptools.pypa.io/en/latest/pkg_resources.html
  from pkg_resources import load_entry_point
```

This probably is just a bitrot/software maintenance issue that needs a
bit of upstream attention.

 --dkg

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

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

Versions of packages xapers depends on:
ii  poppler-utils  22.12.0-2+b1
ii  python33.11.4-5+b1
ii  python3-pkg-resources  68.0.0-2
ii  python3-pybtex 0.24.0-4
ii  python3-xapian 1.4.22-1

Versions of packages xapers recommends:
ii  python3-pycurl  7.45.2-3
ii  python3-urwid   2.1.2-4+b1
ii  xclip   0.13-2
ii  xdg-utils   1.1.3-4.1

xapers suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1050197: bluetoothctl: ctrl-r inescapable

[наб]

Package: bluez
Version: 5.68-2
Severity: normal

Dear Maintainer,

Herein: ^R, ^C ^C ^C ^C ^C, Enter:
-- >8 --
(failed reverse-i-search)`abcder': pairable
(failed reverse-i-search)`abcder':
(failed reverse-i-search)`abcder':
(failed reverse-i-search)`abcder':
(failed reverse-i-search)`abcder':
[bluetooth]# pairable
Missing on/off argument
-- >8 --

-- 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.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bluez depends on:
ii  dbus [default-dbus-system-bus]  1.14.8-2
ii  init-system-helpers 1.65.2
ii  kmod30+20230519-1
ii  libasound2  1.2.9-1
ii  libc6   2.37-7
ii  libdbus-1-3 1.14.8-2
ii  libdw1  0.189-4
ii  libglib2.0-02.77.2-1
ii  libreadline88.2-1.3
ii  libudev1254.1-2
ii  udev254.1-2

bluez recommends no packages.

Versions of packages bluez suggests:
pn  pulseaudio-module-bluetooth  

-- no debconf information


signature.asc
Description: PGP signature

Bug#1041695: chromium: Crash when starting with --incognito option

[Andres Salomon]

Looks like you're missing function names from that backtrace - do you 
have chromium-dbgsym installed?




If you're running debian stable, you'd want to add "deb 
 proposed-updates-debug main" to 
your /etc/apt/sources.list, and then run 'apt install chromium-dbgsym 
chromium-common-dbgsym'


And if you need to temporarily downgrade chromium because the version 
in proposed-updates-debug isn't new enough, you can do something like 
'apt install chromium=115.0.5790.170-1~deb12u1 
chromium-common=115.0.5790.170-1~deb12u1' to downgrade.


Once you have the debugging symbol packages installed, if you grab that 
backtrace again it should be useable.


On Mon, Aug 21 2023 at 08:10:10 PM +00:00:00, Maxime Silvier 
 wrote:
I have taken a closer look at the issue with `chromium -g` command 
— by the way, it is still present in 
chromium=116.0.5845.96-1~deb12u1 but this log was from the 115.0.X 
version.
I hope I did not omit anything useful (the original log file had more 
than 600 lines).


Best regards.

- - -

# Env:
# LD_LIBRARY_PATH=
#
PATH=/home/maxim/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions 
--load-extension=/usr/share/chromium/extensions/keepassxc-browser,/usr/share/chromium/extensions/privacy-badger,/usr/share/chromium/extensions/ublock-origin

/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.5Cvn6Q

Reading symbols from /usr/lib/chromium/chromium...
(No debugging symbols found in /usr/lib/chromium/chromium)
[?2004h(gdb) handle SIG33 pass nostop noprint
handle SIG33 pass nostop noprint
[?2004l
SignalStop  Print   Pass to program Description
SIG33 NoNo  Yes Real-time event 33
[?2004h(gdb) set pagination 0
set pagination 0
[?2004l
[?2004h(gdb) run --icncognito
[?2004l
Starting program: /usr/lib/chromium/chromium --incognito
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

[Detaching after fork from child process 4900]
[New Thread 0x719ff6c0 (LWP 4905)]
[Detaching after fork from child process 4906]
[Detaching after fork from child process 4907]
[Detaching after fork from child process 4908]
[New Thread 0x711fe6c0 (LWP 4911)]
[New Thread 0x701ff6c0 (LWP 4912)]
[New Thread 0x7fffef9fe6c0 (LWP 4913)]
[New Thread 0x7fffef1fd6c0 (LWP 4914)]
[New Thread 0x7fffee9fc6c0 (LWP 4915)]
[New Thread 0x7fffed9fa6c0 (LWP 4916)]
[New Thread 0x7fffee1fb6c0 (LWP 4917)]
[New Thread 0x7fffed1f96c0 (LWP 4918)]
[New Thread 0x7fffec9f86c0 (LWP 4919)]
[New Thread 0x7fffec1f76c0 (LWP 4920)]
[New Thread 0x7fffeafff6c0 (LWP 4921)]
[New Thread 0x7fffea7fe6c0 (LWP 4922)]
Gtk-Message: 11:50:40.232: Failed to load module "appmenu-gtk-module"
[New Thread 0x7fffe9ffd6c0 (LWP 4923)]
[Thread 0x7fffe9ffd6c0 (LWP 4923) exited]
[New Thread 0x7fffe9ffd6c0 (LWP 4924)]
[New Thread 0x7fffe97fc6c0 (LWP 4925)]
[New Thread 0x7fffe87fa6c0 (LWP 4927)]
[New Thread 0x7fffe8ffb6c0 (LWP 4926)]
[New Thread 0x7fffe7ff96c0 (LWP 4928)]
[New Thread 0x7fffe77f86c0 (LWP 4929)]
[New Thread 0x7fffe6fb76c0 (LWP 4930)]
[New Thread 0x7fffe67756c0 (LWP 4934)]
[Detaching after fork from child process 4935]
[4897:4897:0722/115040.316536:ERROR:chrome_browser_cloud_management_controller.cc(162)] 
Cloud management controller initialization aborted as CBCM is not 
enabled.

[New Thread 0x7fffe5e416c0 (LWP 4939)]
[New Thread 0x7fffe56406c0 (LWP 4944)]
[New Thread 0x7fffe4e3f6c0 (LWP 4945)]
[New Thread 0x7fffe45f26c0 (LWP 4960)]
[Detaching after fork from child process 4978]
[New Thread 0x7fffe3cf36c0 (LWP 4997)]

Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x576f956b in ?? ()
[?2004h[?2004l
[?2004h(gdb) bakcktrace
[?2004l
#0  0x576f956b in ?? ()
#1  0x in ?? ()
[?2004h(gdb) thread apply all backtrace
thread apply all backtrace
[?2004l

Bug#562702: python-pam: Debian differences not clearly separated from upstream source

[Bastian Germann]

Control: retitle -1 python-pam: Possible new upstream

The original issue has been resolved over time.
Keep this open to have the new upstream URL at hand.

Bug#1041695: chromium: Crash when starting with --incognito option

[Maxime Silvier]

I have taken a closer look at the issue with `chromium -g` command — by the 
way, it is still present in chromium=116.0.5845.96-1~deb12u1 but this log was 
from the 115.0.X version.
I hope I did not omit anything useful (the original log file had more than 600 
lines).

Best regards.

- - -

# Env:
# LD_LIBRARY_PATH=
#
PATH=/home/maxim/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions 
--load-extension=/usr/share/chromium/extensions/keepassxc-browser,/usr/share/chromium/extensions/privacy-badger,/usr/share/chromium/extensions/ublock-origin
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.5Cvn6Q

Reading symbols from /usr/lib/chromium/chromium...
(No debugging symbols found in /usr/lib/chromium/chromium)
[?2004h(gdb) handle SIG33 pass nostop noprint
handle SIG33 pass nostop noprint
[?2004l
SignalStop  Print   Pass to program Description
SIG33 NoNo  Yes Real-time event 33
[?2004h(gdb) set pagination 0
set pagination 0
[?2004l
[?2004h(gdb) run --icncognito
[?2004l
Starting program: /usr/lib/chromium/chromium --incognito
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 4900]
[New Thread 0x719ff6c0 (LWP 4905)]
[Detaching after fork from child process 4906]
[Detaching after fork from child process 4907]
[Detaching after fork from child process 4908]
[New Thread 0x711fe6c0 (LWP 4911)]
[New Thread 0x701ff6c0 (LWP 4912)]
[New Thread 0x7fffef9fe6c0 (LWP 4913)]
[New Thread 0x7fffef1fd6c0 (LWP 4914)]
[New Thread 0x7fffee9fc6c0 (LWP 4915)]
[New Thread 0x7fffed9fa6c0 (LWP 4916)]
[New Thread 0x7fffee1fb6c0 (LWP 4917)]
[New Thread 0x7fffed1f96c0 (LWP 4918)]
[New Thread 0x7fffec9f86c0 (LWP 4919)]
[New Thread 0x7fffec1f76c0 (LWP 4920)]
[New Thread 0x7fffeafff6c0 (LWP 4921)]
[New Thread 0x7fffea7fe6c0 (LWP 4922)]
Gtk-Message: 11:50:40.232: Failed to load module "appmenu-gtk-module"
[New Thread 0x7fffe9ffd6c0 (LWP 4923)]
[Thread 0x7fffe9ffd6c0 (LWP 4923) exited]
[New Thread 0x7fffe9ffd6c0 (LWP 4924)]
[New Thread 0x7fffe97fc6c0 (LWP 4925)]
[New Thread 0x7fffe87fa6c0 (LWP 4927)]
[New Thread 0x7fffe8ffb6c0 (LWP 4926)]
[New Thread 0x7fffe7ff96c0 (LWP 4928)]
[New Thread 0x7fffe77f86c0 (LWP 4929)]
[New Thread 0x7fffe6fb76c0 (LWP 4930)]
[New Thread 0x7fffe67756c0 (LWP 4934)]
[Detaching after fork from child process 4935]
[4897:4897:0722/115040.316536:ERROR:chrome_browser_cloud_management_controller.cc(162)]
 Cloud management controller initialization aborted as CBCM is not enabled.
[New Thread 0x7fffe5e416c0 (LWP 4939)]
[New Thread 0x7fffe56406c0 (LWP 4944)]
[New Thread 0x7fffe4e3f6c0 (LWP 4945)]
[New Thread 0x7fffe45f26c0 (LWP 4960)]
[Detaching after fork from child process 4978]
[New Thread 0x7fffe3cf36c0 (LWP 4997)]

Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x576f956b in ?? ()
[?2004h[?2004l
[?2004h(gdb) bakcktrace
[?2004l
#0  0x576f956b in ?? ()
#1  0x in ?? ()
[?2004h(gdb) thread apply all backtrace
thread apply all backtrace
[?2004l

Bug#1025568: gparted: diff for NMU version 1.3.1-1.1

[Phillip Susi]

Hugh McMaster  writes:

> Control: tags 1025568 + patch
> Control: tags 1025568 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for gparted (versioned as 1.3.1-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

I have an upload of 1.5 pending my sorting my gpg key out again.  Could
you submit any changes as a PR on salsa?  I think I saw someone had done
that for some minor issues ( was that you? ) but the CI failed.

Bug#1041526: virtiofsd - No copying from Windows possible

[Michael Tokarev]

Might be related:

https://gitlab.com/virtio-fs/virtiofsd/-/issues/120
https://github.com/rust-vmm/vhost/pull/180

/mjt

Bug#1027976: Subject: Re: ITP: libcpucycles -- Microlibrary for counting CPU cycles

[Miguel Landaeta]

libcpucycles is ready to be uploaded.

I just pushed a new git repo for this package.

https://salsa.debian.org/debian/libcpucycles

I'll have to wait a few days to be able to upload the package,
I just updated my PGP key to add new subkeys, because the ones
in the debian keyring expired as I have been inactive for quite
some time.

I attempted an upload 2 days ago and it didn't go through, so the
archive tooling must be failing to validate my upload signature.

Anyway, I'll wait for a few days or nag a DD to do the upload on
my behalf.

Bug#1023565: dleyna adoption

[Barak A. Pearlmutter]

I've done a bit more packaging of dleyna, pushed to
https://salsa.debian.org/debian/dleyna.git branch debian/main, mainly
moving to the latest upstream 0.8.2. My plan is to adopt it by
uploading, which hopefully will result in mopidy-dleyna becoming
usable and then I'll be able to listen to DLNA music on my home
network using Debian boxes, yippee.

Any objections to my just doing an upload? Should I close 1023565 in
the changelog?

(I am, BTW, always thrilled to have co-maintainers, and even happy if
people just do 0-day NMUs or just uploading fixes or whatever.)

Cheers,

--Barak.

Bug#1050196: exim4: EBADF when looking up .forward files

[Erik Hulsmann]

Package: exim4
Version: 4.96-19
Severity: important

Dear Maintainer,

we've got a setup with users' .forward files.
Handling these seems broken to me - strace shows this:


655935 11:50:46.645218 newfstatat(AT_FDCWD, "/home/X/.forward",
{st_mode=S_IFREG|0644, st_size=26, ...}, 0) = 0
Pipe gets opened:
655935 11:50:46.645335 pipe2([12, 13], 0) = 0
655935 11:50:46.645450 rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL,
sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART,
sa_restorer=0x7f7f94347510}, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7f7f94347510}, 8) = 0
Parent closes newly allocated FD 12:
655935 11:50:46.645565 close(12)= 0
655935 11:50:46.645698 close(10)= 0
655935 11:50:46.645810 close(11)= 0
fork:
655935 11:50:46.645922 clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f7f93135c90) = 655936
655936 11:50:46.646714 set_robust_list(0x7f7f93135ca0, 24 
Parent closes FD 13:
655935 11:50:46.646753 close(13 
655936 11:50:46.646783 <... set_robust_list resumed> ) = 0
655935 11:50:46.646815 <... close resumed> ) = 0
655935 11:50:46.646900 read(12,  
655936 11:50:46.646935 close(12 
FD is invalid in parent:
655935 11:50:46.646965 <... read resumed> 0x7ffd9f73b810, 4) = -1 EBADF
(Bad file descriptor)
655936 11:50:46.646997 <... close resumed> ) = -1 EBADF (Bad file
descriptor)
655936 11:50:46.647091 fcntl(13, F_GETFD 
655935 11:50:46.647126 wait4(-1,  
655936 11:50:46.647157 <... fcntl resumed> ) = 0
655936 11:50:46.647217 fcntl(13, F_SETFD, FD_CLOEXEC) = 0
655936 11:50:46.647336 geteuid()= 0
655936 11:50:46.647433 getegid()= 103
655936 11:50:46.647529 setgid(1407) = 0
655936 11:50:46.647629 setuid(1407) = 0
655936 11:50:46.647872 openat(AT_FDCWD, "/home/X/.forward",
O_RDONLY) = 10
655936 11:50:46.648021 newfstatat(10, "", {st_mode=S_IFREG|0644,
st_size=26, ...}, AT_EMPTY_PATH) = 0
655936 11:50:46.648146 newfstatat(10, "", {st_mode=S_IFREG|0644,
st_size=26, ...}, AT_EMPTY_PATH) = 0
655936 11:50:46.648290 read(10, "...\n", 4096) = 26
655936 11:50:46.648409 close(10)= 0
FD is invalid in child as well:
655936 11:50:46.648549 write(13, "\1\0\0\0", 4) = -1 EPIPE (Broken
pipe)
655936 11:50:46.648662 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER,
si_pid=655936, si_uid=1407} ---
655936 11:50:46.648719 close(13)= 0
655936 11:50:46.648835 exit_group(0)= ?
655936 11:50:46.649272 +++ exited with 0 +++
655935 11:50:46.649341 <... wait4 resumed> [{WIFEXITED(s) &&
WEXITSTATUS(s) == 0}], 0, NULL) = 655936
655935 11:50:46.649438 --- SIGCHLD {si_signo=SIGCHLD,
si_code=CLD_EXITED, si_pid=655936, si_uid=1407, si_status=0, si_utime=0,
si_stime=0} ---
655935 11:50:46.649532 gettimeofday({tv_sec=1689940246,
tv_usec=649575}, NULL) = 0
655935 11:50:46.649717 newfstatat(AT_FDCWD, "/etc/localtime",
{st_mode=S_IFREG|0644, st_size=114, ...}, 0) = 0
655935 11:50:46.649889 newfstatat(AT_FDCWD, "/var/log/exim4/mainlog",
{st_mode=S_IFREG|0640, st_size=316972, ...}, 0) = 0
655935 11:50:46.650019 write(4, "2023-07-21 11:50:46 1qM2Sk-00HTHZ-2F
internal problem in userforward router (recipient is
xx...@common-lisp.net): failure to transfer data from subprocess:
status= readerror='Bad file descriptor'\n", 202) = 202
655935 11:50:46.650723 write(2, "2023-07-21 11:50:46 1qM2Sk-00HTHZ-2F
internal problem in userforward router (recipient is
xx...@common-lisp.net): failure to transfer data from subprocess:
status= readerror='Bad file descriptor'\n", 202) = 202

Looks like a definite bug to me.


-- Package-specific info:
Exim version 4.96 #2 built 11-Jun-2023 16:20:21
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007
- 2022
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS
TLS_resume move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event
I18N OCSP PIPECONNECT PRDR PROXY Queue_Ramp SOCKS SPF SRS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm
dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql
sqlite
Authenticators: cram_md5 cyrus_sasl dovecot external plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram
redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /etc/exim4/exim4.conf

-- 

Bug#1049884: birdtray: FTBFS on armhf, armel, mipsel due to thunderbird build-dep

[Emanuele Rocca]

Hi!

On 2023-08-21 07:36, Adam Borowski wrote:
> On Mon, Aug 21, 2023 at 10:38:52AM +0200, Emanuele Rocca wrote:
> > Well FTBFS is a bug isn't it? :-)
> 
> A FTBFS on an architecture that has built before (and hasn't been RMed)
> is a bug, and one that's policied as high severity.

As far as I understand that is the case for birdtray on all 3
architectures? It used to build fine in the past, now it does not:
https://buildd.debian.org/status/fetch.php?pkg=birdtray=mipsel=1.4-2=1547097073=0

> Obviously we'd prefer thunderbird:armhf to be a thing, but unless/until it
> can be fixed, talk about thunderbird addons on armhf is quite moot.

Agreed.

> > Why does birdtray build-depend on thunderbird? It seems to build
> > perfectly fine in a clean armhf chroot without it.

> Build yes, work no. The result would be a pointless package you can't
> use; adding this (otherwise superfluous) build-dependency avoids
> having a non-installable package in the archive.

Given that we know that birdtray does not work on armhf, armel, and
mipsel, the Architecture field should reflect this fact I think. And yes
I understand that in a hypothetical scenario in which thunderbird works
on those arches, birdtray works too. That's not the present reality
though and it seems more accurate to state this fact explicitly instead
of implying it with a superfluous uninstallable build-dep.

>From 
>https://www.debian.org/doc/debian-policy/ch-controlfields.html#architecture:

| Specifying a list of architectures or architecture wildcards indicates
| that the source will build an architecture-dependent package, and will
| only work correctly on the listed or matching architectures.

Cheers,
  Emanuele

Bug#1050195: libwebsockets: Unfortunately the change from #977637 has been lost

[Joachim Zobel]

Source: libwebsockets
Version: Please reenable LWS_WITH_EXTERNAL_POLL support in libwebsockets
Severity: important

Unfortunately the change that sets LWS_WITH_EXTERNAL_POLL to ON has been lost
together with the changelog entry for 4.0.20-2.


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

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

Bug#1049438: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1049438: fixed in r-cran-sp 1:2.0-0+dfsg-2)

[Paul Gevers]

Hi Andreas,

On 19-08-2023 19:39, Debian Bug Tracking System wrote:
Changes: r-cran-sp (1:2.0-0+dfsg-2) unstable; urgency=medium . * Drop 
rgdal from Test-Depends Closes: #1042426, #1049438


I fail to see how this is going to fix the r-cran-rgdal regression. 
Unless you mean to remove r-cran-rgdal from testing without causing 
regression in r-cran-sp. But than I still think that r-cran-sp doesn't 
"close" this particular bug.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041078: mongo-cxx-driver-legacy: diff for NMU version 1.1.3-3.2

[Michael R . Crusoe]

Control: tags 1041078 + patch


Dear maintainer,

I've prepared an NMU for mongo-cxx-driver-legacy (versioned as 1.1.3-3.2). The 
diff
is attached to this message.

Regards.

diff -Nru mongo-cxx-driver-legacy-1.1.3/debian/changelog 
mongo-cxx-driver-legacy-1.1.3/debian/changelog
--- mongo-cxx-driver-legacy-1.1.3/debian/changelog  2021-01-03 
09:48:28.0 +0100
+++ mongo-cxx-driver-legacy-1.1.3/debian/changelog  2023-08-21 
20:39:59.0 +0200
@@ -1,3 +1,11 @@
+mongo-cxx-driver-legacy (1.1.3-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/rules: specify "-std=c++14" to fix FTBFS with googletest 1.13.0.
+Closes: #1041078
+
+ -- Michael R. Crusoe   Mon, 21 Aug 2023 20:39:59 +0200
+
 mongo-cxx-driver-legacy (1.1.3-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mongo-cxx-driver-legacy-1.1.3/debian/rules 
mongo-cxx-driver-legacy-1.1.3/debian/rules
--- mongo-cxx-driver-legacy-1.1.3/debian/rules  2021-01-03 09:48:28.0 
+0100
+++ mongo-cxx-driver-legacy-1.1.3/debian/rules  2023-08-21 16:49:58.0 
+0200
@@ -13,8 +13,7 @@
 --use-sasl-client\
 --sharedclient   \
 --disable-warnings-as-errors \
---c++11=on  \
-CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS)"   \
+CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS) -std=c++14"   \
 CFLAGS="$(CFLAGS) $(CPPFLAGS)"   \
 LINKFLAGS="$(LDFLAGS)"
 

Bug#1049884: birdtray: FTBFS on armhf, armel, mipsel due to thunderbird build-dep

[Adam Borowski]

On Mon, Aug 21, 2023 at 10:38:52AM +0200, Emanuele Rocca wrote:
> Hi Adam,
Hi Em!

> On 2023-08-16 05:14, Adam Borowski wrote:
> > This is not a regression, thus why would it be a bug?
> 
> Well FTBFS is a bug isn't it? :-)

A FTBFS on an architecture that has built before (and hasn't been RMed)
is a bug, and one that's policied as high severity.

A FTBFS that's not a regression is a wishlist, a porting opportunity.
And here it's not even a build failure but a failure to install b-deps.

Obviously we'd prefer thunderbird:armhf to be a thing, but unless/until it
can be fixed, talk about thunderbird addons on armhf is quite moot.
And the way b-deps are written, the moment thunderbird:armhf hits incoming
its addons get enabled in wanna-build, with no human action needed.

> > There's nothing in birdtray itself that would prevent it from being built on
> > these architectures the moment problems in thunderbird are resolved
> 
> Why does birdtray build-depend on thunderbird? It seems to build
> perfectly fine in a clean armhf chroot without it.

Build yes, work no.  The result would be a pointless package you can't use;
adding this (otherwise superfluous) build-dependency avoids having a
non-installable package in the archive.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy.
⠈⠳⣄

Bug#1050194: cloud.debian.org: Custom Script extension is not working in latest Debian 12 Azure image

[Debian]

Package: cloud.debian.org
Severity: important
X-Debbugs-Cc: alex.agra...@audiocodes.com

Hello,

Latest version of Debian 12 image in Azure marketplace (0.20230802.1460)
broke support for Custom Script extension. If one tries to deploy Custom Script
extension - either via ARM template during initial VM creation or for existing
VM via Azure portal - deployment gets stuck forever and never completes.

The following log is produced in /var/log/waagent.log:
2023-08-21T16:55:09.998510Z WARNING ExtHandler ExtHandler No handler status 
found for Microsoft.Azure.Extensions.CustomScript. Not reporting anything for 
it.

In previous Azure marketplace image versions (e.g. 0.20230723.1450) Custom
Script extension works just fine.

Detailed information about Custom Script extension is available here:
https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-linux

Both latest (0.20230802.1460) and previous (0.20230723.1450) images use
the same Azure Linux Agent version - WALinuxAgent-2.7.3.0.

The bug essentially blocks provisioning of new VMs in Azure based on latest 
Debian 12
image that deploys configuration via Custom Script extension.

Thanks,
   Alex

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Thomas Ward]

Bastian:

As I understand the module, for over a year now the latest Lua module 
from OpenResty requires LuaJIT to actually compile.  See 
https://salsa.debian.org/nginx-team/libnginx-mod-http-lua/-/blob/main/debian/control#L8 
where this is in the build deps.


I have not tested removing the PCRE3 build dependency here, but because 
OpenResty has refused to change the Lua library to be any Lua support 
other than 5.1, it requires LuaJIT in order to provide 'continued 
support' for Lua 5.1 bytecode.


It is my understanding that the pcre2/pcre3 dependency may not be 
needed, but I have not deep dived into the Lua packaging recently.  I'm 
running a test build from the tagged data in Salsa locally to see if it 
builds without the pcre2/pcre3 devel libraries in build-deps.



Thomas


On 8/21/23 12:58, Bastian Germann wrote:
Thomas, can you please explain why this package still builds when 
nginx has moved to pcre2? I do not get it.

Bug#1050193: gnome-shell: `/etc/xdg/autostart/gnome-shell-overrides-migration.desktop: not generating unit, error parsing Exec= line: No such file or directory`

[Paul Menzel]

Package: gnome-shell
Version: 44.3-4
Severity: minor


Dear Debian folks,


`journalctl -b` contains the lines below:

Aug 21 16:04:16 ersatz systemd-xdg-autostart-generator[293649]: 
Exec binary '/usr/libexec/gnome-shell-overrides-migration.sh' does not 
exist: No such file or directory
Aug 21 16:04:16 ersatz systemd-xdg-autostart-generator[293649]: 
/etc/xdg/autostart/gnome-shell-overrides-migration.desktop: not 
generating unit, error parsing Exec= line: No such file or directory


Indeed:

$ dpkg -S /etc/xdg/autostart/gnome-shell-overrides-migration.desktop
gnome-shell: /etc/xdg/autostart/gnome-shell-overrides-migration.desktop
$ LANG= ls /usr/libexec/gnome-shell-overrides-migration.sh
ls: cannot access 
'/usr/libexec/gnome-shell-overrides-migration.sh': No such file or directory



Kind regards,

Paul

Bug#1050192: RM: vdk2 -- RoQA; depends on gtk2; unmaintained; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:vdk2

Please remove vdk2. It is unmaintained both upstream and in Debian (last 
maintainer uploard in 2006), and depends on gtk2. The package has a low 
popcon.

Bug#1050191: Stacer doesn't close correctly.

[Rafi Hasan]

Package: Stacer
Version: stable 1.1.0+ds-2

When you try to close the application, you are provided with two options,
one is for quitting the app, and the other lets it run in the system tray.
But on this version, doesn't matter what you chose, it always goes to the
system tray.
This issue isn't present on the previous version(s).

I'm using Debian 12.1 Bookworm on KDE.

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Bastian Germann]

Thomas, can you please explain why this package still builds when nginx 
has moved to pcre2? I do not get it.

Bug#1050190: Flameshot can't copy screenshot to clipboard on Wayland.

[Rafi Hasan]

Package: Flameshot
Version: Flameshot v12.1.0 (Debian 12.1.0-2.1)

If you take any screenshots using the tool, both from GUI or the Terminal,
it simply doesn't get copied to the clipboard on the Wayland session. It
perfectly works on X11. The probable cause is that Flameshot is being
started in X11 mode instead of Wayland mode. Running this script solves the
problem.
https://github.com/flameshot-org/flameshot/issues/2848#issuecomment-1270589109
I'm using Debian 12.1 Bookworm on KDE.

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Thomas Ward]

All:

See the Lua NGINX module issue here in upstream: 
https://github.com/openresty/lua-nginx-module/issues/1984


This has been an open issue since December 2021, and there has *NOT* 
been massive movement yet upstream towards PCRE2 support.


The last info on that bug from July 13th indicates that there are no 
major updates and that a MAJOR update would be needed in Open Resty 
(1.21.4 has been Open Resty's version for eons) in order for PCRE2 
support to really make it, despite nginx core moving to PCRE2.


Given this situation, and the fact this is still not being moved on 
Upstream, this may be a case where we have to decide whether to actually 
*keep* Lua module around at all, especially if we consider PCRE3 
obsolete and a security flaw.  (In which case, this should be also 
tagged as a Security bug).



Thomas



On 8/21/23 11:24, Bastian Germann wrote:

Source: libnginx-mod-http-lua
Severity: serious
Version: 1:0.10.25-1
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

Dear maintainer,

When the pcre3 -> pcre2 mass bug was filed, this package was left out.
I am filing this (edited copy) after the fact:

Your package still depends on the old, obsolete PCRE3 libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, we
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Thanks,
Bastian

___
Pkg-nginx-maintainers mailing list
pkg-nginx-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nginx-maintainers 

Bug#1039902: fenix: Should this package be removed?

[Bastian Germann]

Control: retitle -1 RM: fenix -- ROM (team); 64bit-incompatible
Control: reassign -1 ftp.debian.org
Control: severity -1 normal

On Thu, 29 Jun 2023 11:39:19 +0100 Simon McVittie wrote:

The fenix game development framework does not seem to be in a good state:

- no apparent activity upstream (https://sourceforge.net/projects/fenix/)
  since at least 2013, and no commits in
  https://sourceforge.net/p/fenix/code/HEAD/tree/ since 2008
- an architectural assumption that pointers are <= 32-bit (#456037)
- based on the deprecated SDL 1.2 (#1038340)

Are the two games that depend on it (pixbros and pixfrogger, both most
recently uploaded by a maintainer in 2016) sufficiently important to
justify the amount of QA time that this family of packages takes up?

I think it might be time to remove these packages from Debian.


The games are now gone. Please remove fenix.

Bug#1050189: RM: fenix-plugins -- ROM (team); 64bit-incompatible; leaf package

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:fenix-plugins

Please remove fenix-plugins. It is a leaf package which is not 64 bit 
compatible.

Bug#1041164: dose-distcheck: fails with (W)Dose_common: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe"

[Ralf Treinen]

For the record : this seems to be related to the option "--latest 1"
discarding Essential packages. Here is a minimal Packages file for
reproducing the bug:

Package: aa
Source: aa
Version: 1
Essential: yes
Architecture: all

Package: aa
Source: aa
Version: 2
Architecture: all

-Ralf.

Bug#925358: qemu-user-static: mis-emulates something to do with process/signal handling (m68k, s390x, …)

[Michael Tokarev]

On Fri, 27 Jan 2023 18:14:56 + (UTC) Thorsten Glaser  wrote:

found 925358 1:7.2+dfsg-1+b2
thanks

Ben Hutchings dixit:

>and it certainly has been buggy on some architectures in the past.  It
>seems to be solid now on real hardware.

It probably is. All tests now pass on ARAnyM, even using the mksh
binary built under qemu-user-static (and failing tests there), so
it’s an emulation issue in qemu.

The easiest way to reproduce this locally is (in a sid chroot if
needed, so explicit invocation of qemu, not using binfmt-misc, as
that may use the host’s):

$ wget 
https://deb.debian.org/debian-ports/pool-m68k/main/m/mksh/mksh_59c-21_m68k.deb
$ sha256sum mksh_59c-21_m68k.deb
62df852fc4163b8fbda39bd6e06d146f1da18883789077a68ffa6d4b9562651a  
mksh_59c-21_m68k.deb
$ paxtar xaf mksh_59c-21_m68k.deb
$ paxtar xaf data.tar.xz
$ chmod +x usr/lib/klibc/bin/mksh  # buildd chmod -x’s it if tests fail
$ /usr/bin/qemu-m68k-static usr/lib/klibc/bin/mksh -c 'echo hi'
hi
$ /usr/bin/qemu-m68k-static usr/lib/klibc/bin/mksh -c 'echo hi; /bin/echo hx; 
echo hy'
hi
hx
_

(it just sits there, ignores ^C, uses 100% CPU and needs kill -9)

I was able to re-verify this with the packaged version. In the meantime,
the precisely same binary passes every single test I can throw at it
when running under aranym 1.1.0-2 (kernel 5.16.11-1 but I’ve no doubt
upgrading that won’t change a thing).


I tried this with current qemu 8.0 and 8.1-rc4.  I can reproduce it with
mksh attached to Message#47, it hangs in both cases.  However, the above
with mksh_59c-29_m68k.deb (or s390x.deb) works just fine with both qemu
versions, and works with qemu 7.2 too.  I tried mksh_59c-21_m68k.deb as
well (with the same sha256sum), and it works fine here, no hangs.  On
bookworm system but with different qemu-user-static packages.

Hmm..

/mjt

Bug#1009230: RFP: difftastic -- diff that understands syntax

[James McCoy]

On Mon, Aug 21, 2023 at 07:53:46AM +0100, M Hickford wrote:
> X-Debbugs-CC: debian-r...@lists.debian.org
> 
> > Package: wnpp
> > Severity: wishlist
> >
> > * Package name: difftastic
> >   Version : 0.25.0
> >   Upstream Author : Wilfred Hughes 
> > * URL : https://github.com/Wilfred/difftastic
> > * License : Expat
> >   Programming Lang: Rust
> >   Description : diff that understands syntax
> >
> > Difftastic is an experimental diff tool that compares files based on
> > their syntax.
> 
> 
> Hi. Anyone have the energy to package popular Rust application
> difftastic? It's in other distributions such as Fedora but not yet
> Debian.

Blair Noctis has been looking into it.  That's why they're marked as the
Owner and the bug is now ITP instead of RFP.

However, they're waiting on me getting some of the TreeSitter parsers
packaged.

> I have experience packaging Go applications if anyone would like to
> exchange RFPs

The kitty package is blocked on some new Go packages.  See
https://bugs.debian.org/1037440. :)

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

Bug#1050188: ITP: zpaqfranz -- Swiss army knife for backup and disaster recovery

[Franco Corbelli]

Package: wnpp
Severity: wishlist
Owner: Franco Corbelli 
X-Debbugs-Cc: debian-de...@lists.debian.org, fra...@francocorbelli.com

* Package name: zpaqfranz
  Version : 58.9.c
  Upstream Author : Franco Corbelli 
* URL : https://github.com/fcorbelli/zpaqfranz
* License : MIT
  Programming Lang: C++
  Description : Swiss army knife for backup and disaster recovery

This is a fork of zpaq 7.15 (already in Debian) which was abandoned
by the developer (Matt Mahoney) in 2016.

I have integrated innovative features, in particular the compatibility
with the zfs filesystem, which is increasingly popular also on Debian,
and support for -stdin too (aka: mysql/mariadb dump backups).
These are functions that zpaq cannot do.

I need really a sponsor.

Bug#948658: qemu: Qemu 4.2 hangs/freezes completely due to audio backend changes [regression][bisected]

[Michael Tokarev]

On Tue, 28 Jul 2020 09:39:32 +0300 (EEST) =?ISO-8859-15?Q?Matti_H=E4m=E4l=E4inen?= 
 wrote:
..
Yes, the hang is still reproducible with 5.0-13, but I've been using the 
workaround I described in previous mails, e.g. NOT setting 
'QEMU_ALSA_ADC_DEV="null"', even though that results in numerous warning 
messages .. but works without hanging.


It's been a while again, current version of qemu is 8.0, with 8.1 being at RC4
already.  Is the reported issue still an issue with today version?

It looks like this one is the only bug report about this in the world...

Thanks,

/mjt

Bug#1050187: mvdsv: depends on obsolete pcre3 library

[Bastian Germann]

Source: mvdsv
Severity: serious
Version: 0.35-6
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

Dear maintainer,

When the pcre3 -> pcre2 mass bug was filed, this package was left out.
I am filing this (edited copy) after the fact:

Your package still depends on the old, obsolete PCRE3 libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, we
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Thanks,
Bastian

Bug#964805: Debian Sid HP PA-RISC init (pid 1): Unaligned data reference (code 28) at f8affb6f

[Michael Tokarev]

Control: tag -1 + moreinfo

On Tue, 21 Jul 2020 21:18:19 +0200 Michael Biebl  wrote:

Control: reassign -1 src:qemu
Control: found -1 1:4.2.0-1
Control: notfound -1 1:5.0-6

Am 21.07.20 um 13:31 schrieb Helge Deller:
> On 21.07.20 13:06, Michael Biebl wrote:
>>> Attached is the upstream qemu patch which fixes this issue.
>>> Maybe it makes sense to add it to debian's qemu sources,
>>> or to queue it up in qemu for v4.2.1 ?
> 
> That should read v4.2.2.

> v4.2.1 was released without this patch.
> 
>> Hm, Debian's qemu version is at 5.0.

>> Does this mean this bug report can be closed?
> 
> qemu 5.0 is in debian unstable - and there it's fixed.
> 
>> Maybe Anton needs to raise this with the Fedora guys:

>>  QEMU emulator version 4.2.0 (qemu-4.2.0-7.fc32)
> 
> Yes.


Reassigning the bug report and marking accordingly.


I'm not sure what to do here. Apparently the issue has been
fixed in qemu 5.0 already. Current version is 8.0.  Can
we close this bug report now?

Thanks,

/mjt

Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Bastian Germann]

Source: libnginx-mod-http-lua
Severity: serious
Version: 1:0.10.25-1
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

Dear maintainer,

When the pcre3 -> pcre2 mass bug was filed, this package was left out.
I am filing this (edited copy) after the fact:

Your package still depends on the old, obsolete PCRE3 libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, we
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Thanks,
Bastian

Bug#990659: qemu-system-misc: qemu-riscv64-static sometimes crashes while running gcc in chroot

[Michael Tokarev]

Control: tag -1 + moreinfo

Hi!

Do you have any information about how the situation with current qemu is?
There's 8.0 in testing now (but 8.0 had its own share of linux-user bugs),
and 8.1~rc4 in experimental, - can you try 8.1 one please?

Thanks,

/mjt

Bug#1050185: rust-derive-builder-core - depends on old version of darling.

[Peter Green]

Package: rust-derive-builder-core
Version: 0.12.0-1
Severity: serious

Recently a new version of the darling crates was uploaded,
(Alexander Kajil prepared the uploads, Sylvestre uploaded
darling-core and I uploaded the rest of the darling crates).

Most of the reverse dependencies either already had uploads
prepared, or I was able to prepare uploads. Unfortunately
things were not so fortunate with derive-builder-core.

Bumping darling generally also implies bumping syn,
otherwise one runs into issues. We currently have both
versions 1.x and 2.x of syn in Debian, so this is not
an issue in itself but it means more API changes.

I tried to patch derive-builder-core for the new syn,
but I failed. Looking upstream it seems they are also
currently stuck.

https://github.com/colin-kiegel/rust-derive-builder/issues/292

Bug#1050184: libgetdata: depends on obsolete pcre3 library

[Bastian Germann]

Source: libgetdata
Severity: serious
Version: 0.11.0-6
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

Dear maintainer,

When the pcre3 -> pcre2 mass bug was filed, this package was left out.
I am filing this (edited copy) after the fact:

Your package still depends on the old, obsolete PCRE3 libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, we
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Thanks,
Bastian

Bug#1050179: dgit: unable to clone -security suites (?since bullseye)

[Matthew Vernon]

control: tags 1050179 +patch
quit

On 21/08/2023 15:21, Ian Jackson wrote:

Thanks for the report and the investigation!

Matthew Vernon writes ("Bug#1050179: dgit: unable to clone -security suites (?since 
bullseye)"):

The difficulty is that there is AFAICT no version-knowledge in these
map/rmap entries - one would prefer to apply the map for suites <
bullseye and not for >=bullseye


The usual approach is to list *all* old codenames (at least, any that
still have any existence anywhere) and assume that unknown codenames
are newer.


There is in fact only one suite where this is still germane, since 
pre-buster suites are no longer available on security.debian.org at all. 
Given which, the attached patch works for me (with it I can clone bind9 
for stable,-security oldstable,-security and oldoldstable,-security 
without needing any -c arguments).


HTH,

Matthew
From 2278aa8b77365599b7f48301502777cfae2bfe3a Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Mon, 21 Aug 2023 16:10:11 +0100
Subject: [PATCH] Use the old /updates security map for buster (Closes:
 #1050179)

The suite-map and suite-rmap for debian-security are necessary for the
pre-bullseye layout of the security.debian.org archive.

Since bookworm, the archive layout has changed, and these mappings are
no longer necessary (indeed, they cause dgit clone to fail to work
with bookworm and later security suites).

Buster is the oldest suite still available on security.debian.org, so
this is the only suite we still need the mapping for.

Signed-off-by: Matthew Vernon 
---
 dgit | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dgit b/dgit
index 30d76299..1b02f8de 100755
--- a/dgit
+++ b/dgit
@@ -794,8 +794,8 @@ our %defcfg = ('dgit.default.distro' => 'debian',
 	   'dgit-distro.debian.mirror' => 'http://ftp.debian.org/debian/',
  'dgit-distro.debian-security.archive-query' => 'aptget:',
  'dgit-distro.debian-security.mirror' => 'http://security.debian.org/debian-security/',
- 'dgit-distro.debian-security.aptget-suite-map' => 's#-security$#/updates#',
- 'dgit-distro.debian-security.aptget-suite-rmap' => 's#$#-security#',
+ 'dgit-distro.debian-security.aptget-suite-map' => 's#buster-security$#buster/updates#',
+ 'dgit-distro.debian-security.aptget-suite-rmap' => 's#buster$#buster-security#',
  'dgit-distro.debian-security.nominal-distro' => 'debian',
  'dgit-distro.debian.backports-quirk' => '(squeeze)-backports*',
  'dgit-distro.debian-backports.mirror' => 'http://backports.debian.org/debian-backports/',
-- 
2.39.2

Bug#1050183: httest: depends on obsolete pcre3 library

[Bastian Germann]

Source: httest
Severity: serious
Version: 2.4.23-1.4
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

Dear maintainer,

When the pcre3 -> pcre2 mass bug was filed, this package was left out.
I am filing this (edited copy) after the fact:

Your package still depends on the old, obsolete PCRE3 libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, we
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Thanks,
Bastian

Bug#1043335: dgit-user(7) should note where dgit build is inappropriate (e.g. CI)

[Sean Whitton]

Hello,

On Mon 21 Aug 2023 at 02:08pm +01, Matthew Vernon wrote:

> On 10/08/2023 13:13, Sean Whitton wrote:
>> Hello,
>> On Wed 09 Aug 2023 at 10:29am +01, Matthew Vernon wrote:
>>
>>> And you pointed out that, in fact, I'd be better just using
>>> dpkg-buildpackage -uc -b
>>>
>>> In particular, that avoids the need to produce a source package at
>>> all, which in many cases is desirable (in a gitish workflow, they're
>>> not useful). dgit-user(7) does include runes to produce a
>>> source-package-for-sbuild (under "Using sbuild") alongside a note that
>>> this source package should not otherwise be used (and a reference to
>>> #868527).
>> What I like to tell people is that dgit is pretty much only for when
>> what you want to do will involve .dscs.  No .dscs, no need for dgit.
>
> I think you mean "dgit build" here? clone/pull/etc are all still very useful
> :)

No, I mean in those cases too -- those are cases where you have to deal
with source packages, because those are what the archive mirrors have.

-- 
Sean Whitton

Bug#1006774: bug seems to depend on motherboard/CPU type

[Luc Maisonobe]

The bug is still present in grub 2.06-13.
It however seems to happen only with some motherboard/CPU
configurations.
Here are 3 different configurations I had to test recently:

  - motherboard MSI X570-A PRO, CPU AMD Ryzen 5 3600
 bug occurs: boot freezes as soon as one key is pressed
 on a USB keyboard due to repeated key, only
 way to select menu is to use an old keyboard
  - motherboard ASrock Q87M vPro, CPU Intel core I7 5820K
 no bug: can select boot menu entries from USB keyboard
  - motherboard ASUS H170 pro gaming, CPU Intel core I7-6700
 no bug: cas select boot menu entries from USB keyboard

Every other components in the PC were exactly the same: I just mounted
the motherboard/CPU in the same box at a few days interval

Luc

Bug#1042083: Need more robust handling of fully-qualified hostnames when adding hosts

[Mike Gabriel]

Control: reassign -1 gosa-plugins-systems
Control: found -1 2.8_git20211027.5741b8f-5
Control: found -1 2.8_git20211027.5741b8f-4+deb12u1
Control: severity -1 important

On  Mi 26 Jul 2023 16:12:05 CEST, Guido Berhoerster wrote:


cn=ws008,ou=workstations,ou=systems,dc=skole,dc=skolelinux,dc=no.


This is actually incorrect, it would rather be

cn=ws008.internal,ou=workstations,ou=systems,dc=skole,dc=skolelinux,dc=no

And gosa creates the following entry for DNS:

relativeDomainName=ws008,relativeDomainName=ws008,zoneName=intern,cn=tjener,ou=servers,ou=systems,dc=skole,dc=skolelinux,dc=no

The problem then is that gosa-create-host makes the following LDAP
query:

(&(objectClass=dNSZone)(relativeDomainName=ws008.intern))

assuming that the CN refers to an unqualified hostname.
If gosa should be allowed to create entries with fully qualified hostnames
under ou=workstations,ou=systems,dc=skole,dc=skolelinux,dc=no the script
could also be adapted to skip qualifying the hostname if it contains a ".".


Reassigning this to gosa-plugins-systems and updating the bug's metadata.

Mike


--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpJD460nsC96.pgp
Description: Digitale PGP-Signatur

Bug#1050182: python3-sage: depends on obsolete pcre3 library

[Bastian Germann]

Package: python3-sage
Severity: serious
Version: 9.5-6
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

Dear maintainer,

When the pcre3 -> pcre2 mass bug was filed, python-pcre had not yet been
in the archive. I am filing this (edited copy) after the fact:

Your package still depends on the old, obsolete PCRE3 libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, we
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Thanks,
Bastian

Bug#1050181: rtpengine: depends on obsolete pcre3 library

[Bastian Germann]

Source: rtpengine
Severity: serious
Version: 10.5.5.2-1
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

Dear maintainer,

When the pcre3 -> pcre2 mass bug was filed, python-pcre had not yet been
in the archive. I am filing this (edited copy) after the fact:

Your package still depends on the old, obsolete PCRE3 libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, we
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Thanks,
Bastian

Bug#1039700: Invalid DHCP configuration for systems in LDAP

[Mike Gabriel]

Control: reassign -1 gosa-plugins-systems
Control: found -1 2.8_git20211027.5741b8f-5
Control: found -1 2.8_git20211027.5741b8f-4+deb12u1
Control: severity -1 important

On  Mo 21 Aug 2023 11:55:35 CEST, Guido Berhoerster wrote:

On Wed, 28 Jun 2023 13:36:04 +0200 Guido Berhoerster  
 wrote:

Package: debian-edu-config
Version: 2.12.32

After adding a workstation (hostname: "ws01.intern") as shown in
https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-bullseye-manual-images/gosa_systems_edit_host.png
the following DHCPD error appears, suggesting invalid syntax:

2023-06-28T11:19:42.890913+02:00 tjener dhcpd[1368]: LDAP-HOST line  
2: semicolon expected.

2023-06-28T11:19:42.891073+02:00 tjener dhcpd[1368]: option host-name ws01.
2023-06-28T11:19:42.891107+02:00 tjener dhcpd[1368]:   ^
2023-06-28T11:19:42.891133+02:00 tjener dhcpd[1368]: uid lease  
10.0.16.22 for client 00:16:3e:22:7b:5e is duplicate on intern
2023-06-28T11:19:42.891172+02:00 tjener dhcpd[1368]: DHCPDISCOVER  
from 00:16:3e:22:7b:5e via eth0
2023-06-28T11:19:42.891207+02:00 tjener dhcpd[1368]: DHCPOFFER on  
10.0.0.2 to 00:16:3e:22:7b:5e via eth0
2023-06-28T11:19:42.891859+02:00 tjener dhcpd[1368]: LDAP-HOST line  
2: semicolon expected.

2023-06-28T11:19:42.891915+02:00 tjener dhcpd[1368]: option host-name ws01.
2023-06-28T11:19:42.891947+02:00 tjener dhcpd[1368]:   ^
2023-06-28T11:19:42.891982+02:00 tjener dhcpd[1368]: uid lease  
10.0.16.22 for client 00:16:3e:22:7b:5e is duplicate on intern
2023-06-28T11:19:42.898709+02:00 tjener dhcpd[1368]: DHCPREQUEST  
for 10.0.0.2 (10.0.2.2) from 00:16:3e:22:7b:5e via eth0
2023-06-28T11:19:42.898830+02:00 tjener dhcpd[1368]: DHCPACK on  
10.0.0.2 to 00:16:3e:22:7b:5e via eth0


It turns out that this is another problem caused by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042083

It only happens when the added hostname is fully qualified,
as incorrectly suggested in the above documentation
screenshot. We need to fix this in gosa as it is easy to
get wrong and causes all kinds of weird issues.



Re-assigning this issue to gosa-plugins-systems and updating the bug's  
metadata.


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpvZJA30j0Io.pgp
Description: Digitale PGP-Signatur

Bug#1050179: dgit: unable to clone -security suites (?since bullseye)

[Ian Jackson]

Thanks for the report and the investigation!

Matthew Vernon writes ("Bug#1050179: dgit: unable to clone -security suites 
(?since bullseye)"):
> The difficulty is that there is AFAICT no version-knowledge in these
> map/rmap entries - one would prefer to apply the map for suites <
> bullseye and not for >=bullseye

The usual approach is to list *all* old codenames (at least, any that
still have any existence anywhere) and assume that unknown codenames
are newer.

> IMO, this would be worth a backport to at least stable when fixed -
> it's a bit sad that this functionality is broken since it's quite
> useful for end-users of dgit and helps make sure they get security
> updates.

I agree.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1050180: bookworm-pu: package freeradius/3.2.1+dfsg-4+deb12u1

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: freerad...@packages.debian.org
Control: affects -1 + src:freeradius

[ Reason ]
I would like to fix a regression in the bookworm release of FreeRADIUS where
the TLS-Client-Cert-Common-Name attribute contains the wrong value, breaking
some use-cases (Bug#1043282)

It has been fixed in the new upstream version in sid, the two relevant commits
apply cleanly. The reporter has confirmed that this fixes his problem.

[ Impact ]
Attribute not usable for filtering/policy decisions

[ Tests ]
no additional CI tests covering _this_ specific feature. Reporter has confirmed
the fix.

[ Risks ]
Change is small and has been part of two upstream releases

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

[ Changes ]
See above + d/gbp.conf for the correct stable branch

[ Other info ]
none
diff -Nru freeradius-3.2.1+dfsg/debian/changelog 
freeradius-3.2.1+dfsg/debian/changelog
--- freeradius-3.2.1+dfsg/debian/changelog  2023-05-16 00:04:23.0 
+0200
+++ freeradius-3.2.1+dfsg/debian/changelog  2023-08-19 00:26:34.0 
+0200
@@ -1,3 +1,11 @@
+freeradius (3.2.1+dfsg-4+deb12u1) bookworm; urgency=medium
+
+  * Add d/gbp.conf for bookworm stable branch
+  * Cherry-Pick two upstream commits to fix TLS-Client-Cert-Common-Name
+contains incorrect value (Closes: #1043282)
+
+ -- Bernhard Schmidt   Sat, 19 Aug 2023 00:26:34 +0200
+
 freeradius (3.2.1+dfsg-4) unstable; urgency=medium
 
   * Don't install symlink for cache_eap module no longer shipped
diff -Nru freeradius-3.2.1+dfsg/debian/gbp.conf 
freeradius-3.2.1+dfsg/debian/gbp.conf
--- freeradius-3.2.1+dfsg/debian/gbp.conf   1970-01-01 01:00:00.0 
+0100
+++ freeradius-3.2.1+dfsg/debian/gbp.conf   2023-08-19 00:26:34.0 
+0200
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = debian/bookworm
diff -Nru 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
--- 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
1970-01-01 01:00:00.0 +0100
+++ 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
2023-08-19 00:26:34.0 +0200
@@ -0,0 +1,40 @@
+From d23987cbf55821dc56ab70d5ce6af3305cf83289 Mon Sep 17 00:00:00 2001
+From: "Alan T. DeKok" 
+Date: Tue, 25 Oct 2022 10:51:02 -0400
+Subject: [PATCH] set partial chain always.  Helps with #4785
+
+---
+ src/main/tls.c | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/src/main/tls.c b/src/main/tls.c
+index aa6395d8391f..a33699cbb66e 100644
+--- a/src/main/tls.c
 b/src/main/tls.c
+@@ -3546,6 +3546,11 @@ X509_STORE *fr_init_x509_store(fr_tls_server_conf_t 
*conf)
+   if (conf->check_all_crl)
+   X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK_ALL);
+ #endif
++
++#if defined(X509_V_FLAG_PARTIAL_CHAIN)
++  X509_STORE_set_flags(store, X509_V_FLAG_PARTIAL_CHAIN);
++#endif
++
+   return store;
+ }
+ 
+@@ -4011,11 +4016,11 @@ SSL_CTX *tls_init_ctx(fr_tls_server_conf_t *conf, int 
client, char const *chain_
+   if (conf->ca_file || conf->ca_path) {
+   if ((certstore = fr_init_x509_store(conf)) == NULL ) return 
NULL;
+   SSL_CTX_set_cert_store(ctx, certstore);
+-  }
+-
++  } else {
+ #if defined(X509_V_FLAG_PARTIAL_CHAIN)
+-  X509_STORE_set_flags(SSL_CTX_get_cert_store(ctx), 
X509_V_FLAG_PARTIAL_CHAIN);
++  X509_STORE_set_flags(SSL_CTX_get_cert_store(ctx), 
X509_V_FLAG_PARTIAL_CHAIN);
+ #endif
++  }
+ 
+   if (conf->ca_file && *conf->ca_file) SSL_CTX_set_client_CA_list(ctx, 
SSL_load_client_CA_file(conf->ca_file));
+ 
diff -Nru 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
--- 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
1970-01-01 01:00:00.0 +0100
+++ 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
2023-08-19 00:26:34.0 +0200
@@ -0,0 +1,29 @@
+From 3d08027f30c6d9c1eaccf7d60c68c8f7d78017c3 Mon Sep 17 00:00:00 2001
+From: "Alan T. DeKok" 
+Date: Wed, 26 Oct 2022 07:31:43 -0400
+Subject: [PATCH] fix cert order only for lookup=0.  Fixes #4785
+
+---
+ src/main/tls.c | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/src/main/tls.c b/src/main/tls.c
+index a33699cbb66e..c67148cf12c7 100644
+--- a/src/main/tls.c
 b/src/main/tls.c
+@@ -3015,7 +3015,14 @@ int cbtls_verify(int ok, X509_STORE_CTX *ctx)
+*/
+   if (lookup > 1) {
+   if (!my_ok) lookup = 1;
+-  } 

Bug#1034049: RFS: wxmaxima/23.04.0-1 -- GUI for the computer algebra system Maxima

[Bastian Germann]

Control: tags -1 - moreinfo

The thing was updated.

Bug#1050179: dgit: unable to clone -security suites (?since bullseye)

[Matthew Vernon]

Package: dgit
Version: 10.7
Severity: important

Hi,

It's suggested (in e.g. dgit-user(7)) to clone a combined ,-security
suite. But this does not work (transcript 0 below), with an error about
missing Release file:

E: The repository 'http://security.debian.org/debian-security 
bookworm/updates Release' does not have a Release file.


I think this is because the suit map/rmap for debian-security are
wrong:
dgit: 'dgit-distro.debian-security.aptget-suite-map' => 
's#-security$#/updates#',

dgit: 'dgit-distro.debian-security.aptget-suite-rmap' => 's#$#-security#',

Debian changed its security suite names starting with bullseye from
/updates to -security:
https://lists.debian.org/debian-devel-announce/2019/07/msg4.html

If I disable both mappings I can then clone pcre2 stable,-security
with a warning that pcre2 can't be found in the (security) archive
which I think is correct. That was done thus:

dgit -cdgit-distro.debian-security.aptget-suite-map='' 
-cdgit-distro.debian-security.aptget-suite-rmap='' clone pcre2 
stable,-security


Transcript 1 below contains the full output of that command.

By way of checking that this works where there has been a security
update, I cloned bind9 stable,-security and checked that left me at
1:9.18.16-1~deb12u1 (the security release) - see Transcript 2.

Likewise, dgit merge/pull work with the map & rmap unset.

The difficulty is that there is AFAICT no version-knowledge in these
map/rmap entries - one would prefer to apply the map for suites <
bullseye and not for >=bullseye

IMO, this would be worth a backport to at least stable when fixed -
it's a bit sad that this functionality is broken since it's quite
useful for end-users of dgit and helps make sure they get security
updates.

Thanks,

Matthew

*** BEGIN TRANSCRIPT 0 ***

matthew@aragorn:~/junk$ dgit clone pcre2 stable,-security
fetching stable...
canonical suite name for stable is bookworm
fetching existing git history
last upload to archive: specified git info (debian)
  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
100 2341k  100 2341k0 0  2322k  0  0:00:01  0:00:01 --:--:-- 
2324k

HEAD is now at be53c99 Changelog for 10.42-1
dgit [stable] ok: ready for work in pcre2
fetching bookworm-security...
Ign:1 http://security.debian.org/debian-security bookworm/updates InRelease
Err:2 http://security.debian.org/debian-security bookworm/updates Release
  404  Not Found [IP: 2a04:4e42:82::644 80]
Reading package lists... Done
E: The repository 'http://security.debian.org/debian-security 
bookworm/updates Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is 
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user 
configuration details.
dgit [bookworm-security]: failed command: apt-get -c 
'/home/matthew/.cache/dgit/aptget/apt.conf#debian' update


dgit [bookworm-security]: error: subprocess failed with error exit 
status 100


dgit: error: failed to obtain bookworm-security: failed with error exit 
status 255


*** END TRANSCRIPT 0 ***

*** BEGIN TRANSCRIPT 1 ***

matthew@aragorn:~/junk$ dgit 
-cdgit-distro.debian-security.aptget-suite-map='' 
-cdgit-distro.debian-security.aptget-suite-rmap='' clone pcre2 
stable,-security

fetching stable...
canonical suite name for stable is bookworm
fetching existing git history
last upload to archive: specified git info (debian)
  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
100 2341k  100 2341k0 0  2322k  0  0:00:01  0:00:01 --:--:-- 
2324k

HEAD is now at be53c99 Changelog for 10.42-1
dgit [stable] ok: ready for work in pcre2
fetching bookworm-security...
Hit:1 http://security.debian.org/debian-security bookworm-security InRelease
Reading package lists... Done
canonical suite name is bookworm-security
W: Unable to locate package pcre2
no version available from the archive
dgit [bookworm-security]: source package pcre2 does not exist in suite 
bookworm-security

calculated combined tracking suite bookworm,-security
HEAD is now at be53c99 Changelog for 10.42-1
dgit ok: ready for work in pcre2

*** END TRANSCRIPT 1 ***

*** BEGIN TRANSCRIPT 2 ***

matthew@aragorn:~/junk$ dgit 
-cdgit-distro.debian-security.aptget-suite-map='' 
-cdgit-distro.debian-security.aptget-suite-rmap='' clone bind9 
stable,-security

fetching stable...
canonical suite name for stable is bookworm
starting new git history
last upload to archive: NO git hash
  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
100 5334k  100 5334k0 0  2352k  0  0:00:02  0:00:02 --:--:-- 
2352k
  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
   

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

[Adam D. Barratt]

On Thu, 2023-08-03 at 10:39 -0400, Nicholas D Steeves wrote:
> 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.
> 

I'm not sure what happened to the upload, but there appears to be no
sign of it in either the queued or dak logs.

Regards,

Adam

Bug#1050178: ocaml-extunix FTBFS on hppa

[Helge Deller]

Package: ocaml-extunix
Tags: ftbfs, hppa
Version: 0.4.1-3

This package fails like this:

Failure: tests:7:resource:0:setrlimit:1:RLIMIT_STACK
soft limit
expected: infinity but got: 8388608

see: 
https://buildd.debian.org/status/fetch.php?pkg=ocaml-extunix=hppa=0.4.1-3=1692284259=0

The problem is, that on hppa a "unlimited stack" means "80MB" stack
by default. Reason is, that on hppa the stack grows upwards, so on
hppa there always needs to be a configurable stack (up to a limit).

Can you please apply that patch (at least for hppa) so that the build
succeeds?

Thanks,
Helge

diff -up ./test/test.ml.org ./test/test.ml
--- ./test/test.ml.org  2023-08-21 13:42:33.779667564 +
+++ ./test/test.ml  2023-08-21 14:00:18.226077993 +
@@ -132,7 +132,7 @@ let test_resource =
 RLIMIT_DATA;
 RLIMIT_FSIZE;
 (* RLIMIT_NOFILE; *) (* too fragile to test on CI *)
-RLIMIT_STACK;
+(* RLIMIT_STACK;  *) (* at least on hppa stack unlimited means 80MB *)
 RLIMIT_AS;
   ]
   in

Bug#1050177: nmu: uwsgi-plugin-php_2.0.21+4+0.0.15 uwsgi-plugin-luajit_2.0.21+3+0.0.8 uwsgi-plugin-mongo_2.0.21+3+0.0.9

[Michael R. Crusoe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: uwsgi-plugin-...@packages.debian.org, 
uwsgi-plugin-...@packages.debian.org, cru...@debian.org
Control: affects -1 + src:uwsgi-plugin-php
Control: affects -1 + src:uwsgi-plugin-luajit
Control: affects -1 + src:uwsgi-plugin-mongo

Hello,

uwsgi 2.0.22-1 is in unstable and therefore the separate uwsgi plugin packages 
need
binNMUs. This will hopefully unblock uwsgi's transition[0], along with
preventing testing removals for uwsgi, mailman3, and others.

nmu uwsgi-plugin-php_2.0.21+4+0.0.15 . ANY . unstable . -m "rebuild against new 
upstream release of uwsgi"
nmu uwsgi-plugin-luajit_2.0.21+3+0.0.8  . ANY . unstable . -m "rebuild against 
new upstream release of uwsgi"
nmu uwsgi-plugin-mongo_2.0.21+3+0.0.9 . ANY . unstable . -m "rebuild against 
new upstream release of uwsgi"

[0] https://qa.debian.org/excuses.php?package=uwsgi

Thanks!

Bug#1050176: pytables: FTBFS with 'nocheck' enabled

[Graham Inggs]

Source: pytables
Version: 3.7.0-7
Tags: ftbfs

Hi Maintainer

As can be seen in recent build failures on m68k [1] and sh4 [2],
pytables now FTBFS with 'nocheck' enabled.  I've copied what I hope is
the relevant part of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=pytables=m68k
[2] https://buildd.debian.org/status/logs.php?pkg=pytables=sh4


   dh_missing -a -O--buildsystem=pybuild
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/__init__.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/array.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/atom.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/attributeset.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/carray.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/conditions.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/description.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/earray.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/exceptions.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/expression.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/file.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/filters.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/flavor.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/group.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/idxutils.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/index.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/indexes.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/leaf.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/link.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/node.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/parameters.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/path.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/registry.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/req_versions.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/table.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/undoredo.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/unimplemented.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/utils.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/__pycache__/vlarray.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:
usr/lib/python3.11/dist-packages/tables/misc/__pycache__/__init__.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: warning:

Bug#1042399: I confirm there is a problem

[Debian User]

Hi

I am new to this Debian mailing lists and have started to learn what
and how things are working here because I want to support Debian in
some way in future.


About this issue:

The MariaDB Website say there is even a newer version "MariaDB 10.11.5
Stable (GA)" released. 

https://mariadb.com/kb/en/mariadb-10-11-5-changelog/

I am not sure this issue here is fixed with the newer version.

What would be the right way to report this to the issue?  Should I just
post it to the mailing list or directly to some responsible person?


Sorry for asking you 


best, Carsten.


On Sat, 2023-08-19 at 03:59 +0300, Владимир wrote:
> When is the fix planned to be rolled out. The bug is critical, on
> some 
> systems the file growth reaches about 10GB per day, and at the moment
> it 
> can only be cleaned by recreating the database and files. I tried 
> downloading and uploading the /usr/sbin/mariadbd binary, but it looks
> like it's not just about it, since it doesn't even start, you
> probably 
> need to re-upload all related binaries. This procedure does not
> inspire 
> confidence.
> 

Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates

[Julian Andres Klode]

On Sat, Aug 19, 2023 at 06:14:54PM +0200, Daniel Gröber wrote:
> Hi,
> 
> On Sat, Aug 19, 2023 at 04:53:09PM +0200, Raphael Hertzog wrote:
> > > The problem is that regex is NOT supported at the moment.
> > 
> > Urgh, and you did not complain that the release notes actually encourage
> > users to do that?
> 
> Yeah, that seems less than ideal. Brings me back to thinking we should
> change the security codename to something that's not going to need these
> hacky regexes then.
> 
> Since $release/security is not well liked for unclear ("dak") reasons
> (please someone elaborate if possible), perhaps an approach based on
> Ubuntu's is less controvertial.
> 
> In debian-security/bookworm-security we have this right now
> 
> Origin: Debian
> Label: Debian-Security
> Suite: stable-security
> Version: 12
> Codename: bookworm-security
> 
> and we need the regex becuase $codename/$suite doesn't match "bookworm",
> "bookworm/*" or stable, stable/* resp. Compare this to what Ubuntu uses:
> 
> Origin: Ubuntu
> Label: Ubuntu
> Suite: kinetic-security
> Version: 22.10
> Codename: kinetic
> 
> Here APT::Default-Release "kinetic" would match just fine. Just seems they
> don't support the "stable" alias like we do. Could we use this to cover
> both use-cases:
> 
> Origin: Debian
> Label: Debian-Security
> Suite: stable
> Codename: bookworm
> 
> Now no weird hacks are neceessary APT::DefaultRelease "bookworm" or
> "stable" will match the security repos just fine.
> 
> Users that _really_ want to do weird things to the security repo can still
> use a "label" match in apt/preferences like `Pin: release
> l=Debian-Security`. I think you'd be able to combine this with a codename
> match to be specific about which release too: `Pin: release
> l=Debian-Security n=bookworm` but don't quote me on that until someone
> tests it.
> 
> I don't see any real downsides to this approach other than "ugh more
> change".


I think ultimately APT::Default-Release has been deprecated[1] in
a configuration files many many cycles ago, and the current
behavior is much more meaningful on the command-line, both
in cases of apt install foo -t bookworm and apt install foo/bookworm
to specifically say you want stuff in bookworm and not in updates
or security (that is, you may want to downgrade to the latest
point release or install from it and ignore a buggy security
update).

I have a very strong dislike for the Ubuntu behavior because
it completely breaks user expectations.

In conclusion, I think that while this is a regression for
a very small minority of people, the current status quo is
ultimately an improvement in behavior.

I am amenable to add a warning to apt in case APT::Default-Release
is set in apt.conf such that users get a hint their configuration
is wrong

[1] by way of being not set up anymore, nor recommended in release
notes.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1050175: Missing symbol when importing torch

[M. Zhou]

Sorry for the inconvenience. This is a temporary break due to the
undergoing pytorch 2.0.1 upgrade work.

On Mon, 2023-08-21 at 14:52 +0200, Mattias Ellert wrote:
> Package: python3-torch
> Version: 1.13.1+dfsg-4
> Severity: serious
> 
> Importing torch results in failure due to missing symbols:
> 
> $ python3
> Python 3.11.4 (main, Jun  7 2023, 10:13:09) [GCC 12.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more
> information.
> > > > import torch
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/torch/__init__.py", line 218,
> in
> 
>     from torch._C import *  # noqa: F403
>     ^^
> ImportError: /lib/x86_64-linux-gnu/libtorch_cpu.so.1.13: undefined
> symbol: _ZN4onnx7checker11check_modelERKNS_10ModelProtoE
> > > > 
> 
> pytorch requires rebuild due to updated libonnx1:
> 
> $ c++filt _ZN4onnx7checker11check_modelERKNS_10ModelProtoE
> onnx::checker::check_model(onnx::ModelProto const&)
> 
> $ dpkg-query --show python3-torch libonnx1
> libonnx1:amd641.13.1-1
> python3-torch 1.13.1+dfsg-4
> 
>   Mattias
> 

Bug#1050175: Missing symbol when importing torch

[Mattias Ellert]

Package: python3-torch
Version: 1.13.1+dfsg-4
Severity: serious

Importing torch results in failure due to missing symbols:

$ python3
Python 3.11.4 (main, Jun  7 2023, 10:13:09) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/torch/__init__.py", line 218, in

from torch._C import *  # noqa: F403
^^
ImportError: /lib/x86_64-linux-gnu/libtorch_cpu.so.1.13: undefined
symbol: _ZN4onnx7checker11check_modelERKNS_10ModelProtoE
>>> 

pytorch requires rebuild due to updated libonnx1:

$ c++filt _ZN4onnx7checker11check_modelERKNS_10ModelProtoE
onnx::checker::check_model(onnx::ModelProto const&)

$ dpkg-query --show python3-torch libonnx1
libonnx1:amd64  1.13.1-1
python3-torch   1.13.1+dfsg-4

Mattias



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

Bug#1050174: O: flickcurl -- utilities to call the Flickr API from command line - documentation

[Kumar Appaiah]

Package: wnpp
Severity: normal
X-Debbugs-Cc: flickc...@packages.debian.org, a.ku...@alumni.iitm.ac.in
Control: affects -1 + src:flickcurl

I intend to orphan the flickcurl package.

The package description is:
 Flickcurl is a C library for the Flickr API, handling creating the
 requests, signing, token management, calling the API, marshalling
 request parameters and decoding responses. The library now supports
 100% of the 2008-01-11 version of the API, including the functions
 for photo uploading, browsing, searching, adding and editing
 comments, groups, notes, photosets, categories, activity, blogs,
 favorites, places, tags and photo metadata. It also includes a
 program flickrdf to turn photo metadata, tags and machine tags into
 RDF descriptions of photos and tags.
 .
 Support for the Flickr API in these programs is through the
 libflickcurl library.
 .
 This package contains the HTML documentation for flickcurl and the
 related library.

Bug#1049957: mailman3: does not work with importlib_resources v6

[Michael R. Crusoe]

control: tags -1 patch

Dear Maintainers,

I've submitted a merge request[0] to cherry-pick upstream's fix for 
this. Please consider releasing this fix so the Debian package for 
importlib-resources 6.x can migrate to testing[1] and unblock the 
migration of other packages[2].


Thanks!

[0] https://salsa.debian.org/mailman-team/mailman3/-/merge_requests/3

[1] https://qa.debian.org/excuses.php?package=importlib-resources

[2] https://qa.debian.org/excuses.php?package=python-schema-salad



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041249: cpp-httplib: FTBFS on s390x: ../test/test.cc:5462: Failure

[Andrea Pappacoda]

Hi Emanuele, thank you for the info. I'm aware of that, and even reported the 
issue upstream[1], but the maintainer isn't interested in fixing it.

I would debug and maybe fix the issue myself, but as a DM I don't have easy 
access to porter boxes and honestly the long wait and inability to get access 
to all of them is quite demotivating. I have asked for an s390x porter box a 
couple of days ago and still didn't get access to it, and I'd now have to 
re-ask for and armhf one, and wait again... I'll eventually fix this, but I 
cannot now for factors outside of my control.

If you could please help debug the issue on the architectures you have access 
to I'd be very grateful. If you don't have time, no worries, I fully understand 
it, but please be patient :)

Thanks!

[1]: https://github.com/yhirose/cpp-httplib/issues/1199

Il 21 agosto 2023 10:53:23 CEST, Emanuele Rocca  ha scritto:
>I've bumped into a very similar failure on armhf too, so the problem is
>probably not s390x-specific.
>
>Note that the build succeeded on a second try.

Bug#1037887: vtk9: ftbfs with GCC-13

[Aurelien Jarno]

control: tag -1 + upstream
control: tag -1 + fixed-upstream
control: tag -1 + patch

Hi,

On 2023-06-14 09:32, Matthias Klose wrote:
> Package: src:vtk9
> Version: 9.1.0+really9.1.0+dfsg2-5
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
> 
> [This bug is targeted to the upcoming trixie release]
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
> severity of this report will be raised before the trixie release.

The following upstream patch fixes the issue:
https://gitlab.kitware.com/vtk/vtk/-/commit/1233ceec268d5366c66f5e79786ec784042b591b

Regards
Aurelien

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

Bug#1050166: RM: printrun/2.0.1-1

[Graham Inggs]

Control: tags -1 + moreinfo

Hi Rock Storm

On Mon, 21 Aug 2023 at 09:03, Rock Storm  wrote:
> Dear release team, I would like to request the removal of the printrun
> package (which I maintain) from *testing* due to bug #1050157 [1].

The severity of #1050157 is 'important', so it will just migrate back
into testing after removal.

Please raise the severity of that bug to RC (i.e. serious or above),
then remove the 'moreinfo' tag from this bug.

> IMHO, such a poor user experience
> makes the package not suitable for migrating to Ubuntu and other
> derivatives that rely on Debian testing

Ubuntu imports from Debian unstable, so they already have the new
version of printrun.  Please consider filing a removal bug there too.

Regards
Graham

Bug#1050173: setting a zero password per user during installation

[Nikolay Sabelnikov]

Package: calamaris
Version: 3.2.61-1+b1

during installation, I noticed that it is impossible to set a null password for 
the user.

Bug#1049366: reopen

[Santiago Vila]

reopen 1049366
fixed 1049366 2.2.13-3
thanks

Reopening because the plan is to fix this in stable as well.

Bug#1037914: cloud-initramfs-growroot: missing dependencies in initramfs

[Csillag Tamas]

Package: cloud-initramfs-growroot
Control: severity -1 grave

hi,

I am seeing the same issue on my systems after debian12 upgrade and found that
either declaring the dependency with copy_exec or installing busybox fixes this
issue.
Raising severity.

Regards,
 Tamás

On Wed, Jun 14, 2023 at 09:38:06AM +, ZHANG, Yuntian wrote:
> Package: cloud-initramfs-growroot
> Version: 0.18.debian13
> Severity: important
> X-Debbugs-Cc: y...@radxa.com
> 
> Dear Maintainer,
> 
> cloud-initramfs-growroot was working for our custom Debian 11 system,
> but when we created the Debian 12 system, the following errors were
> observed during booting:
> 
> GROWROOT: /sbin/growpart: 824: /sbin/growpart: grep: not found
> /sbin/growpart: 853: /sbin/growpart: sed: not found
> WARN: unknown label 
> /sbin/growpart: 354: /sbin/growpart: sed: not found
> FAILED: sed failed on dump output
> /sbin/growpart: 83: /sbin/growpart: rm: not found
> 
> Needless to say the root partition was not grown. We had to add
> following lines to get it working again:
> 
> # in /usr/share/initramfs-tools/hooks/growroot:
> copy_exec /usr/bin/grep /bin
> copy_exec /usr/bin/sed /bin
> copy_exec /usr/bin/rm /bin
> copy_exec /usr/bin/awk /bin
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 6.1.33-1-stable (SMP w/6 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_CRAP
> 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)
> 
> Versions of packages cloud-initramfs-growroot depends on:
> ii  cloud-utils  0.33-1
> ii  fdisk2.38.1-5+b1
> ii  initramfs-tools  0.142
> ii  util-linux   2.38.1-5+b1
> 
> cloud-initramfs-growroot recommends no packages.
> 
> cloud-initramfs-growroot suggests no packages.
> 
> -- no debconf information
> 

-- 

Bug#1025568: gparted: diff for NMU version 1.3.1-1.1

[Hugh McMaster]

Control: tags 1025568 + patch
Control: tags 1025568 + pending

Dear maintainer,

I've prepared an NMU for gparted (versioned as 1.3.1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

Hugh
diff -Nru gparted-1.3.1/debian/changelog gparted-1.3.1/debian/changelog
--- gparted-1.3.1/debian/changelog	2022-01-13 03:23:19.0 +1100
+++ gparted-1.3.1/debian/changelog	2023-08-21 21:32:58.0 +1000
@@ -1,3 +1,10 @@
+gparted (1.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Replace policykit-1 with pkexec (Closes: #1025568).
+
+ -- Hugh McMaster   Mon, 21 Aug 2023 21:32:58 +1000
+
 gparted (1.3.1-1) unstable; urgency=medium
 
   * New upstream version 1.3.1
diff -Nru gparted-1.3.1/debian/control gparted-1.3.1/debian/control
--- gparted-1.3.1/debian/control	2022-01-13 02:52:18.0 +1100
+++ gparted-1.3.1/debian/control	2023-08-21 21:31:52.0 +1000
@@ -7,8 +7,8 @@
  libgtkmm-3.0-dev,
  libparted-dev (>= 2.22),
  parted,
+ pkexec,
  pkg-config,
- policykit-1,
  uuid-dev,
  yelp-tools
 Standards-Version: 4.5.0
@@ -19,7 +19,7 @@
 Package: gparted
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends},
- gparted-common (= ${source:Version}), policykit-1
+ gparted-common (= ${source:Version}), pkexec
 Breaks: udisks2 (<< 2.1.5), gparted-common (= 1.0.0-0.1)
 Replaces: gparted-common (= 1.0.0-0.1)
 Suggests:

Bug#1016924: hddemux: FTBFS on ppc64el

[Abhirup Deb]

Package: hddemux
Version: 0.5-1
Severity: normal

Dear Maintainer,

Changes to knot-resolver have been suggested to resolve the FTBFS for 
hddemux on ppc64el,
in reference to the patch suggested by Ubuntu. On subsequent testing 
with our ppc64el machines,
we have been able to conclude that the aforementioned patch resolves the 
issue successfully,

resulting in completion of the build.

The complete build logs have been attached herewith. Also, a copy of the 
aforementioned patch

( as posted by the Ubuntu team ) has been attached for reference.

-- System Information :
   Debian Release: Debian 6.1.27-1 (2023-05-08) ppc64le GNU/Linux
   Kernel Version:   kernel 6.1.0-9-powerpc64le
   libc6 Version: 2.37-7

Happy to provide further information wherever necessary.

- Abhirup



$ dpkg-buildpackage -sa

dpkg-buildpackage: info: source package hddemux
dpkg-buildpackage: info: source version 0.5-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Daniel Kahn Gillmor 

dpkg-buildpackage: info: host architecture ppc64el
 dpkg-source --before-build .
 debian/rules clean
dh clean
   dh_auto_clean
make -j160 clean
make[1]: Entering directory '/build/hddemux-qOnIru/hddemux-0.5'
rm -rf hddemux hddemux.1 \
.refcache/ \
draft-dkg-dprive-demux-dns-http.txt \
draft-dkg-dprive-demux-dns-http.html \
draft-dkg-dprive-demux-dns-http.xml
make[1]: Leaving directory '/build/hddemux-qOnIru/hddemux-0.5'
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: verifying ./hddemux_0.5.orig.tar.gz.asc
gpgv: Signature made Mon Jan 31 20:03:00 2022 UTC
gpgv:using EDDSA key 2DB5491C9DF0DC8F432863CF3E9D717371DE565C
gpgv: Can't check signature: No public key
dpkg-source: warning: cannot verify upstream tarball signature for 
./hddemux_0.5.orig.tar.gz: no acceptable signature found
dpkg-source: info: building hddemux using existing ./hddemux_0.5.orig.tar.gz
dpkg-source: info: building hddemux using existing ./hddemux_0.5.orig.tar.gz.asc
dpkg-source: info: building hddemux in hddemux_0.5-1.debian.tar.xz
dpkg-source: info: building hddemux in hddemux_0.5-1.dsc
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
   dh_auto_build
make -j160 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/build/hddemux-qOnIru/hddemux-0.5'
cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/build/hddemux-qOnIru/hddemux-0.5=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE -g -O3   hddemux.c 
-Wl,--as-needed -Wl,-z,relro -Wl,-z,now -luv -lpthread -ldl -lrt  -lsystemd  
-std=c11 -pedantic -Wall -Werror -o hddemux
pandoc -s -f markdown -t man -o hddemux.1 hddemux.1.md
make[1]: Leaving directory '/build/hddemux-qOnIru/hddemux-0.5'
dh: command-omitted: The call to "dh_auto_test" was omitted due to 
"DEB_BUILD_OPTIONS=nocheck"
   create-stamp debian/debhelper-build-stamp
   dh_prep
   dh_auto_install --destdir=debian/hddemux/
   dh_install
   dh_installdocs
   dh_installchangelogs
   dh_installman
   dh_installinit
   dh_installtmpfiles
   dh_installsystemd
   dh_perl
   dh_link
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_missing
   dh_dwz -a
   dh_strip -a
   dh_makeshlibs -a
   dh_shlibdeps -a
   dh_installdeb
   dh_gencontrol
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'hddemux' in '../hddemux_0.5-1_ppc64el.deb'.
dpkg-deb: building package 'hddemux-dbgsym' in 
'../hddemux-dbgsym_0.5-1_ppc64el.deb'.
 dpkg-genbuildinfo -O../hddemux_0.5-1_ppc64el.buildinfo
 dpkg-genchanges -sa -O../hddemux_0.5-1_ppc64el.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: full upload (original source is included)

diff -Nru hddemux-0.5/debian/control hddemux-0.5/debian/control
--- hddemux-0.5/debian/control  2022-01-31 10:56:12.0 -0700
+++ hddemux-0.5/debian/control  2022-01-31 10:56:12.0 -0700
@@ -7,7 +7,7 @@
  debhelper-compat (= 13),
  gnutls-bin [!arm64] ,
  knot-dnsutils [!arm64] ,
- knot-resolver [!arm64 !s390x] ,
+ knot-resolver [!arm64 !ppc64el !s390x] ,
  libsystemd-dev,
  libuv1-dev,
  nginx-light [!arm64] ,
diff -Nru hddemux-0.5/debian/rules hddemux-0.5/debian/rules
--- hddemux-0.5/debian/rules2022-01-31 10:56:12.0 -0700
+++ hddemux-0.5/debian/rules2022-01-31 10:56:12.0 -0700
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-KRESD_BROKEN_ARCHES := arm64 s390x
+KRESD_BROKEN_ARCHES := arm64 s390x ppc64el
 ifneq (, $(filter $(DEB_HOST_ARCH), $(KRESD_BROKEN_ARCHES)))
   DEB_BUILD_OPTIONS += nocheck
 endif

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Pascal Hambourg]

On 21/08/2023 at 11:56, Arnaud Rebillout wrote:

On 21/08/2023 04:03, Philip Hands wrote:

If you want to do your own tests, the mini.iso can be downloaded via:

https://salsa.debian.org/philh/grub-installer/-/jobs/4582667/artifacts/file/debian/output/debian-202306XX+salsaci+20230820+228-amd64-gtkmini.iso


Hello, I download it and tested it in a QEMU VM. I tested it two times: 
with and without UEFI enabled. I can report that installation succeeded 
in both cases.


Did anyone test with EFI boot and fallback to legacy mode in partman 
("do not force EFI installation") ?

Bug#1048073: mah-jong upgrade to gtk3

[dhd...@icloud.com]

These 3 games are totally different with the original mah-jong game.
Since they are single-player games to collect same cards from the top of the 
stack, the original mah-jong game usually requires 4 players. That's a 
competitive game.
Note: A popular JavaScript-based game 羊了个羊 has a simliar rule to these 3 games, 
and Microsoft bundled a game Mahjong Titans in Windows Vista and Windows 7, 
which is the same as these 3.




From: Bastian Germann 
Sent: Monday, August 21, 2023 3:32:39 PM
To: xiao sheng wen(肖盛文) ; 1048...@bugs.debian.org 
<1048...@bugs.debian.org>
Cc: debian-chinese...@lists.debian.org 
Subject: Re: mah-jong upgrade to gtk3

Am 21.08.23 um 03:50 schrieb xiao sheng wen(肖盛文):
> The homepage of this software is still exist:
> http://mahjong.julianbradfield.org/
>
> The latest version 1.16 is upload on 2020-06-26:
> http://mahjong.julianbradfield.org/Linux/
>
> mah-jong is used very popular in east asia country.

Have you checked out gnome-mahjongg, kmahjongg, or xmahjongg,
which are all more popular in terms of popcon than this one?
I guess there are plenty more mahjong implementations in Debian.

Bug#999936: uwsgi: depends on obsolete pcre3 library

[Mathias Behrle]

Hi all,

friendly ping ;)

> Seems like uwsgi-plugin-{luajit,mongo,php} need a binNMU or an upload
> due to uwsgi ABI change.

Any news on this? Quite a number of packages depending on uwsgi will fall out
of testing shortly, because uwsgi doesn't migrate to testing (which is a major
annoyance).

Thanks for looking into this!

Cheers,
Mathias

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#1043226: +1 (Re: Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text)

[Holger Levsen]

On Tue, Aug 15, 2023 at 10:03:22PM +0100, Samuel Henrique wrote:
> > So, many users, and especially newcomers to Debian, follow the instructions 
> > in the
> > first line and are then surprised when they can't use sudo from their user 
> > from
> > their newly installed system.
> I've seen this issue happening so many times.
> This would be a huge UX improvement for the installation process and I
> really hope the change is made, thank you for filling this, Jonathan!

I very much second this.


-- 
cheers,
Holger

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

"In just 6 decades, roughly the life span of a blue whale, humans took blue 
whale
population down from 360,000 to just 1,000. In one century, whalers killed two
million baleen whales, which together weighed twice as much as all wild mammals
on Earth today."
https://www.theatlantic.com/science/archive/2021/11/whaling-whales-food-krill-iron/620604/


signature.asc
Description: PGP signature

Bug#1050172: ITS: mah-jong

[肖盛文]

Source: mah-jong
Severity: important
X-Debbugs-Cc: b...@debian.org, m...@qa.debian.org, atzli...@sina.com

Hi,

The current maintainer of mah-jong is Nicolas Boullis , he 
is not active now.

The mah-jong has new upstream version.

I want ITS mah-jong.

Thanks!


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

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

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

On 21/08/2023 04:03, Philip Hands wrote:

If you want to do your own tests, the mini.iso can be downloaded via:

https://salsa.debian.org/philh/grub-installer/-/jobs/4582667/artifacts/file/debian/output/debian-202306XX+salsaci+20230820+228-amd64-gtkmini.iso


Hello, I download it and tested it in a QEMU VM. I tested it two times: 
with and without UEFI enabled. I can report that installation succeeded 
in both cases.


Here are logs obtained post-install with 'grep grub-installer: 
/var/log/installer/syslog', in case it's useful


 With UEFI enabled:

Success mounting /target/proc
Success mounting /target/sys
Success mounting /target/sys/firmware/efi/efivars
info: architecture: amd64/efi
info: Identified partition label for /dev/sda2: gpt
dpkg: warning: ignoring request to remove grub which isn't installed
dpkg: warning: ignoring request to remove grub-legacy which isn't installed
dpkg: warning: ignoring request to remove grub-pc-bin which isn't installed
dpkg: warning: ignoring request to remove grub-pc which isn't installed
info: initial os-prober call found the following OSes:
info:
info: Found NO other OSes, triggering question about os-prober, default 
false

info: Additionally installing shim-signed to go with grub-efi-amd64
info: Installing grub on 'dummy'
info: grub-install does not support --no-floppy
info: Running chroot /target grub-install  --force "dummy"
Installing for x86_64-efi platform.
Installation finished. No error reported.
info: grub-install ran successfully

    Without UEFI:

info: architecture: amd64/generic
info: Mounting /proc into /target
info: Identified partition label for /dev/sda1: msdos
dpkg: warning: ignoring request to remove grub which isn't installed
dpkg: warning: ignoring request to remove grub-legacy which isn't installed
dpkg: warning: ignoring request to remove grub-efi which isn't installed
dpkg: warning: ignoring request to remove grub-efi-amd64-bin which isn't 
installed
dpkg: warning: ignoring request to remove grub-efi-amd64-signed which 
isn't installed
dpkg: warning: ignoring request to remove grub-efi-amd64 which isn't 
installed
dpkg: warning: ignoring request to remove grub-efi-ia32-bin which isn't 
installed
dpkg: warning: ignoring request to remove grub-efi-ia32 which isn't 
installed

info: initial os-prober call found the following OSes:
info:
info: Found NO other OSes, triggering question about os-prober, default 
false

info: Installing grub on '/dev/sda'
info: grub-install does not support --no-floppy
info: Running chroot /target grub-install  --force "/dev/sda"
Installing for i386-pc platform.
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda2": No such device
Unknown device "/dev/sda5": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Installation finished. No error reported.
info: grub-install ran successfully

Cheers,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1039700: Invalid DHCP configuration for systems in LDAP

[Guido Berhoerster]

On Wed, 28 Jun 2023 13:36:04 +0200 Guido Berhoerster  
wrote:
> Package: debian-edu-config
> Version: 2.12.32
> 
> After adding a workstation (hostname: "ws01.intern") as shown in
> https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-bullseye-manual-images/gosa_systems_edit_host.png
> the following DHCPD error appears, suggesting invalid syntax:
> 
> 2023-06-28T11:19:42.890913+02:00 tjener dhcpd[1368]: LDAP-HOST line 2: 
> semicolon expected.
> 2023-06-28T11:19:42.891073+02:00 tjener dhcpd[1368]: option host-name ws01.
> 2023-06-28T11:19:42.891107+02:00 tjener dhcpd[1368]:   ^
> 2023-06-28T11:19:42.891133+02:00 tjener dhcpd[1368]: uid lease 10.0.16.22 for 
> client 00:16:3e:22:7b:5e is duplicate on intern
> 2023-06-28T11:19:42.891172+02:00 tjener dhcpd[1368]: DHCPDISCOVER from 
> 00:16:3e:22:7b:5e via eth0
> 2023-06-28T11:19:42.891207+02:00 tjener dhcpd[1368]: DHCPOFFER on 10.0.0.2 to 
> 00:16:3e:22:7b:5e via eth0
> 2023-06-28T11:19:42.891859+02:00 tjener dhcpd[1368]: LDAP-HOST line 2: 
> semicolon expected.
> 2023-06-28T11:19:42.891915+02:00 tjener dhcpd[1368]: option host-name ws01.
> 2023-06-28T11:19:42.891947+02:00 tjener dhcpd[1368]:   ^
> 2023-06-28T11:19:42.891982+02:00 tjener dhcpd[1368]: uid lease 10.0.16.22 for 
> client 00:16:3e:22:7b:5e is duplicate on intern
> 2023-06-28T11:19:42.898709+02:00 tjener dhcpd[1368]: DHCPREQUEST for 10.0.0.2 
> (10.0.2.2) from 00:16:3e:22:7b:5e via eth0
> 2023-06-28T11:19:42.898830+02:00 tjener dhcpd[1368]: DHCPACK on 10.0.0.2 to 
> 00:16:3e:22:7b:5e via eth0

It turns out that this is another problem caused by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042083

It only happens when the added hostname is fully qualified,
as incorrectly suggested in the above documentation
screenshot. We need to fix this in gosa as it is easy to
get wrong and causes all kinds of weird issues.

-- 
Guido Berhoerster