Bug#1021800: pgrouting: reproducible builds: Embeds kernel version of build machine

[Sebastiaan Couwenberg]

Control: tags -1 upstream pending

Thanks for the patch, it's applied in git and forwarded upstream:

 https://github.com/pgRouting/pgrouting/pull/2414

Kind Regards,

Bas

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

Bug#1021799: pgrouting: reproducible builds: Embeds timezone-specific date in libpgrouting-3.4.so

[Sebastiaan Couwenberg]

Control: tags -1 upstream pending

Thanks for the patch, it's applied in git and forwarded upstream:

 https://github.com/pgRouting/pgrouting/pull/2414

Kind Regards,

Bas

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

Bug#1021808: zram-tools: Typo in package description

[Thom]

Package: zram-tools
Version: 0.3.3.1-1
Severity: minor
X-Debbugs-Cc: thom1...@gmail.com

Dear Maintainer,

in the package description the last string says:
"By default it allocates 100MB of RAM"

But in the configuration file /etc/default/zramswap we can see 256MB as default 
value (#SIZE=256 commented out).

After package installation the swap device is 256MB in size
$ sudo swapon
NAME   TYPE  SIZE USED PRIO
/dev/zram0 partition 256M   0B  100

I suggest to correct package description like:
"By default it allocates 256MB of RAM"

Thanks in advance.


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

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

Versions of packages zram-tools depends on:
ii  bc  1.07.1-3+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- no debconf information

Bug#1021807: gimp: Gimp "core-dumps" with an attempt to add a text layer on top of a background color.

[Scott Corcoran]

Package: gimp
Version: 2.10.32-1+b1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Create a 300x200 New Image, fill it with red background color, add a text layer 
on top with (A).
   * What exactly did you do (or not do) that was effective (or ineffective)?
Attempted to repeat the procedure 3-4 times. Same result.
   * What was the outcome of this action?
Crash
   * What outcome did you expect instead?
Ability to add a text layer.



```
GNU Image Manipulation Program version 2.10.32
git-describe: GIMP_2_10_32
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
12.1.0-8' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-12 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Debian 12.1.0-8) 

# Libraries #
using babl version 0.1.96 (compiled against version 0.1.92)
using GEGL version 0.4.38 (compiled against version 0.4.38)
using GLib version 2.74.0 (compiled against version 2.72.3)
using GdkPixbuf version 2.42.9 (compiled against version 2.42.9)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.10 (compiled against version 1.50.9)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 24182 - Thread 24182 #

[New LWP 24183]
[New LWP 24184]
[New LWP 24185]
[New LWP 24186]
[New LWP 24187]
[New LWP 24188]
[New LWP 24243]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___libc_read (nbytes=256, buf=0x7ffe8b5116f0, fd=14) at 
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame 
* 1Thread 0x7fc881e30380 (LWP 24182) "gimp"__GI___libc_read 
(nbytes=256, buf=0x7ffe8b5116f0, fd=14) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7fc881710640 (LWP 24183) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7fc880f0f640 (LWP 24184) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7fc88070e640 (LWP 24185) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7fc87f3a6640 (LWP 24186) "gmain"   0x7fc8826fe1ef in 
__GI___poll (fds=0x55feb8c0e490, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  6Thread 0x7fc87eba5640 (LWP 24187) "gdbus"   0x7fc8826fe1ef in 
__GI___poll (fds=0x55feb8d0dd10, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  7Thread 0x7fc8621ff640 (LWP 24188) "async"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7fc8611fd640 (LWP 24243) "swap writer" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 8 (Thread 0x7fc8611fd640 (LWP 24243) "swap writer"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7fc882aee43f in g_cond_wait () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fc8830857e9 in  () at /lib/x86_64-linux-gnu/libgegl-0.4.so.0
#3  0x7fc882ac4aed in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fc88268784a in start_thread (arg=) at 
./nptl/pthread_create.c:442
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140731235767552, 
6462158967000481282, 140498599663168, 11, 140499158070656, 0, 
-6467466585275941374, 

Bug#1021806: python3-click: Will you please upgrade to the latest version?

[Takahide Nojima]

Package: python3-click
Version: 8.0.3-1
Severity: wishlist

Dear Maintainer,

 This package is based on 8.0.3 of the upstream. That version was
released on 10th Oct 2021 by the upstream.

 However, the upstream has released 8.1.3, and primarily it has
implemented many enhancements since 8.1.0.

 FYI: https://click.palletsprojects.com/en/8.1.x/changes/

 Would you consider upgrading to the latest version of the upstream?

 I'm so grateful to consider that.

Takahide Nojima.


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

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

Versions of packages python3-click depends on:
ii  python3 3.10.6-1
ii  python3-colorama    0.4.5-2
ii  python3-importlib-metadata  4.12.0-1

python3-click recommends no packages.

python3-click suggests no packages.

-- no debconf information

Bug#1021805: python3-multidict: Will you please upgrade to the latest version?

[Takahide Nojima]

Package: python3-multidict
Version: 5.1.0-2+b1
Severity: normal
X-Debbugs-Cc: nozzy123no...@gmail.com

Dear Maintainer,

 This package is based on 5.1.0. That version was released on 3rd Dec
2020  by the upstream.

 However, the upstream has released 6.2, which includes many
enhancements since 5.1.0.

 Would you consider upgrading to the latest version of the upstream?

Takahide Nojima

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

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

Versions of packages python3-multidict depends on:
ii  libc6    2.35-3
ii  python3  3.10.6-1

python3-multidict recommends no packages.

python3-multidict suggests no packages.

-- no debconf information

Bug#1020093: python-dlt: diff for NMU version 2.0-3.1

[Adrian Bunk]

Control: tags 1020093 + patch
Control: tags 1020093 + pending

Dear maintainer,

I've prepared an NMU for python-dlt (versioned as 2.0-3.1) and uploaded 
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru python-dlt-2.0/debian/changelog python-dlt-2.0/debian/changelog
--- python-dlt-2.0/debian/changelog	2021-02-11 00:22:19.0 +0200
+++ python-dlt-2.0/debian/changelog	2022-10-15 06:54:00.0 +0300
@@ -1,3 +1,10 @@
+python-dlt (2.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport E275 codestyle fixes. (Closes: #1020093)
+
+ -- Adrian Bunk   Sat, 15 Oct 2022 06:54:00 +0300
+
 python-dlt (2.0-3) unstable; urgency=medium
 
   * Tighteen the dependency on dlt-daemon version 2.18.6
diff -Nru python-dlt-2.0/debian/patches/e275.patch python-dlt-2.0/debian/patches/e275.patch
--- python-dlt-2.0/debian/patches/e275.patch	1970-01-01 02:00:00.0 +0200
+++ python-dlt-2.0/debian/patches/e275.patch	2022-10-15 06:54:00.0 +0300
@@ -0,0 +1,24 @@
+Description: Backport E275 codestyle fixes
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/1020093
+
+--- python-dlt-2.0.orig/dlt/dlt_broker_handlers.py
 python-dlt-2.0/dlt/dlt_broker_handlers.py
+@@ -62,7 +62,7 @@ class DLTContextHandler(Thread):
+ if filters:
+ with self.lock:
+ try:
+-del(self.context_map[queue_id])
++del self.context_map[queue_id]
+ except KeyError:
+ pass
+ 
+@@ -149,7 +149,7 @@ class DLTMessageHandler(Process):
+ for apid_ctid in filters:
+ self.context_map[apid_ctid].remove(queue_id)
+ if not self.context_map[apid_ctid]:
+-del(self.context_map[apid_ctid])
++del self.context_map[apid_ctid]
+ except (KeyError, ValueError):
+ # - queue_id already removed or not inserted
+ pass
diff -Nru python-dlt-2.0/debian/patches/series python-dlt-2.0/debian/patches/series
--- python-dlt-2.0/debian/patches/series	2021-02-11 00:20:39.0 +0200
+++ python-dlt-2.0/debian/patches/series	2022-10-15 06:54:00.0 +0300
@@ -2,3 +2,4 @@
 ignore_pylint_file.diff
 git-updates.patch
 27.patch
+e275.patch

Bug#1021804: gnome-terminal: Wrong window name "Preferences" showing up in Gnome Dash and the application switcher (Alt-Tab) for running terminals

[Ronny Rentner]

Package: gnome-terminal
Version: 3.46.1-2
Severity: minor
X-Debbugs-Cc: debian-b...@ronny-rentner.de

Dear Maintainer,

when I run Gnome Terminal, it shows up under the name "Preferences" in Gnome
Dash and in the application switcher. This also makes the application grouping
fail in Gnome Dash.

This seems to be caused by having 2 .desktop files:
/usr/share/applications/org.gnome.Terminal.Preferences.desktop
/usr/share/applications/org.gnome.Terminal.desktop

After I have manually deleted the org.gnome.Terminal.Preferences.desktop file,
the problem goes away.

Thanks in adance,

Ronny


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

Kernel: Linux 5.18.0-0.deb11.3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.4-1
ii  dbus-x11 [dbus-session-bus]   1.14.4-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gnome-terminal-data   3.46.1-2
ii  gsettings-desktop-schemas 43.0-1
ii  libatk1.0-0   2.46.0-3
ii  libc6 2.35-3
ii  libgcc-s1 12.2.0-3
ii  libglib2.0-0  2.74.0-3
ii  libgtk-3-03.24.34-3
ii  libpango-1.0-01.50.10+ds-1
ii  libstdc++612.2.0-3
ii  libuuid1  2.38.1-1.1
ii  libvte-2.91-0 0.70.0-1
ii  libx11-6  2:1.8.1-2

Versions of packages gnome-terminal recommends:
ii  gvfs   1.50.2-2
ii  nautilus-extension-gnome-terminal  3.46.1-2
ii  yelp   42.2-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#1020068: ukui-screensaver: diff for NMU version 3.0.3-1.1

[Adrian Bunk]

Control: tags 1020068 + patch
Control: tags 1020068 + pending

Dear maintainer,

I've prepared an NMU for ukui-screensaver (versioned as 3.0.3-1.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru ukui-screensaver-3.0.3/debian/changelog ukui-screensaver-3.0.3/debian/changelog
--- ukui-screensaver-3.0.3/debian/changelog	2022-02-22 08:20:17.0 +0200
+++ ukui-screensaver-3.0.3/debian/changelog	2022-10-15 06:29:20.0 +0300
@@ -1,3 +1,10 @@
+ukui-screensaver (3.0.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with new glib. (Closes: #1020068)
+
+ -- Adrian Bunk   Sat, 15 Oct 2022 06:29:20 +0300
+
 ukui-screensaver (3.0.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru ukui-screensaver-3.0.3/debian/patches/glib.patch ukui-screensaver-3.0.3/debian/patches/glib.patch
--- ukui-screensaver-3.0.3/debian/patches/glib.patch	1970-01-01 02:00:00.0 +0200
+++ ukui-screensaver-3.0.3/debian/patches/glib.patch	2022-10-15 06:29:20.0 +0300
@@ -0,0 +1,15 @@
+Description: Fix FTBFS with new glib
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/1020068
+
+--- ukui-screensaver-3.0.3.orig/BiometricAuth/giodbus.cpp
 ukui-screensaver-3.0.3/BiometricAuth/giodbus.cpp
+@@ -19,7 +19,7 @@
+ 
+ #include "giodbus.h"
+ #include 
+-#include 
++#include 
+ #include 
+ 
+ int get_server_gvariant_stdout (int drvid)
diff -Nru ukui-screensaver-3.0.3/debian/patches/series ukui-screensaver-3.0.3/debian/patches/series
--- ukui-screensaver-3.0.3/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ ukui-screensaver-3.0.3/debian/patches/series	2022-10-15 06:29:20.0 +0300
@@ -0,0 +1 @@
+glib.patch

Bug#1021803: gnuserv FTBFS with emacs 28

[Adrian Bunk]

Source: gnuserv
Version: 3.12.8-8
Severity: serious
Tags: ftbfs
Control: block 1020050 by -1

https://buildd.debian.org/status/logs.php?pkg=gnuserv=3.12.8-8

...
emacs --no-site-file -batch \
--eval "(add-to-list 'load-path \".\")" \
-l gnuserv-compat -f batch-byte-compile gnuserv.el
Package cl is deprecated
Debugger entered--Lisp error: (error "Cannot find suitable directory for output 
in ‘nati...")
  error("Cannot find suitable directory for output in `nati...")
  comp-trampoline-compile(delete-frame)
  comp-subr-trampoline-install(delete-frame)
  ad-add-advice(delete-frame (gnuserv-compat-delete-frame nil t (advice lambda 
nil (run-hook-with-args 'delete-device-hook frame))) before first)
  
byte-code("\300\301!\210\302\303!\204\17\0\304\303\305\"\210\302\306!\204\32\0\304\306\307\"\210\302\310!\204%\0\304\310\311\"\210\312\313!\2045\0\314\315\316!\2063\0..."
 [require cl fboundp define-obsolete-variable-alias defalias 
make-obsolete-variable functionp #f(compiled-function (object) #) add-minor-mode #f(compiled-function (toggle name) 
#) boundp temporary-file-directory (lambda 
(def-tmp-var) (defvar temporary-file-directory def-tmp-var)) getenv "TMPDIR" 
"/tmp" temp-directory #f(compiled-function () #) 
string-match "XEmacs" emacs-version ad-add-advice make-frame 
(gnuserv-compat-make-frame nil t (advice lambda ( parameters device) 
(if (and device (frame-live-p device)) (progn (if parameters 
(modify-frame-parameters device parameters)) (setq ad-return-value device)) 
ad-do-it))) around first ad-activate nil delete-frame 
(gnuserv-compat-delete-frame nil t (advice lambda nil (run-hook-with-args 
'delete-device-hook frame))) before filtered-frame-list 
(gnuserv-compat-filtered-frame-list nil t (advice lambda (predicate  
device) ad-do-it)) devices device-list frame-list selected-device 
selected-frame device-frame-list #f(compiled-function ( device) 
#) frame-iconified-p #f(compiled-function (frame) 
#) deiconify-frame make-frame-visible 
frame-totally-visible-p #f(compiled-function (frame) #) (error) custom featurep custom-declare-variable ...] 5)
  command-line-1(("--eval" "(add-to-list 'load-path \".\")" "-l" 
"gnuserv-compat" "-f" "batch-byte-compile" "gnuserv.el"))
  command-line()
  normal-top-level()

make[1]: *** [Makefile:250: gnuserv.elc] Error 255

Bug#1021802: vmdb2: Grub UEFI installation fails when rootfs is created by debootstrap

[Antonio Terceiro]

Package: vmdb2
Version: 0.26-1
Severity: normal
Tags: patch
X-Debbugs-CC: l...@liw.fi

Dear Maintainer,

I was trying to create an arm64 image with GRUB and UEFI from my amd64
laptop, using the attached definition. It would fail at the GRUB install
phase, and the error message was saying that it was trying to install
grub-efi-amd64 even though I was creating an arm64 image. I then noticed
that the debootstrap plugin was not setting the architecture globally,
what caused the grub plugin to not use the correct architecture.

The attached patch fixes this.

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

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

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32.14.gcdfe14e-4
ii  debootstrap 1.0.127+nmu1
ii  e2fsprogs   1.46.6~rc1-1
ii  kpartx  0.9.0-4
ii  parted  3.5-2
ii  python3 3.10.6-1
ii  python3-jinja2  3.0.3-2
ii  python3-yaml5.4.1-1+b2
ii  qemu-utils  1:7.1+dfsg-2

Versions of packages vmdb2 recommends:
ii  ansible   6.4.0+dfsg-1
ii  dosfstools4.2-1
ii  qemu-user-static  1:7.1+dfsg-2

vmdb2 suggests no packages.

-- no debconf information
# This is a sample VMDB2 input file that specifies a simple system for
# an arm64 machine that boots with UEFI.

steps:
  - mkimg: "{{ output }}"
size: 1G

  - mklabel: gpt
device: "{{ output }}"

  - mkpart: primary
device: "{{ output }}"
start: 0%
end: 20M
tag: efi

  - mkpart: primary
device: "{{ output }}"
start: 20M
end: 100%
tag: /

  - kpartx: "{{ output }}"

  - mkfs: vfat
partition: efi

  - mkfs: ext4
partition: /

  - mount: /

  - unpack-rootfs: /

  - debootstrap: bullseye
variant: minbase
arch: arm64
mirror: http://deb.debian.org/debian
target: /
unless: rootfs_unpacked

  - chroot: /
shell: apt-get clean

  - apt: install
packages:
  - wget
  - iproute2
  - linux-image-arm64
  - systemd-sysv
fs-tag: /
unless: rootfs_unpacked

  - copy-file: /etc/systemd/network/eth0.network
src: eth0.network
unless: rootfs_unpacked

  - chroot: /
shell: systemctl enable systemd-networkd
unless: rootfs_unpacked

  - cache-rootfs: /
unless: rootfs_unpacked

  - chroot: /
shell: |
  sed -i '/^root:[^:]*:/s//root::/' /etc/passwd
  echo arm64-uefi-vmdb2 > /etc/hostname

  - grub: uefi
tag: /
efi: efi
console: serial

# vim: ft=yaml
From 27aeb5717d0a12bb7660ff9ae54f122f22999250 Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Fri, 14 Oct 2022 19:24:45 -0300
Subject: [PATCH] fix(debootstrap plugin): set architecture for later stages

debootstrap takes an architecture argument, but does not propagate that
to later stages of the image build. This causes, for example, the GRUB
plugin to fail to install the correct packages when creating an images
for a foreign archiecture.

The call to dpkg --print-architecture to discover the native
architecture is already done when state is first populated, so there is
no need to do it again in the grub plugin.
---
 vmdb/plugins/debootstrap_plugin.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/vmdb/plugins/debootstrap_plugin.py b/vmdb/plugins/debootstrap_plugin.py
index a28bf94..c96ed01 100644
--- a/vmdb/plugins/debootstrap_plugin.py
+++ b/vmdb/plugins/debootstrap_plugin.py
@@ -51,10 +51,8 @@ class DebootstrapStepRunner(vmdb.StepRunnerInterface):
 install_keyring = values["install_keyring"]
 include = values["include"]
 require_empty = values["require_empty_target"]
-arch = (
-values["arch"]
-or subprocess.check_output(["dpkg", "--print-architecture"]).strip()
-)
+arch = values["arch"] or state.arch
+state.arch = arch
 variant = values["variant"]
 components = values["components"]
 
@@ -113,3 +111,7 @@ class DebootstrapStepRunner(vmdb.StepRunnerInterface):
 ]
 + remove_pkgs,
 )
+
+def run_even_if_skipped(self, values, settings, state):
+if values["arch"]:
+state.arch = values["arch"]
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#1020482: Some languages need upstream fixes

[Soren Stoutner]

Before the Aragonese .bdic can be built the following upstream bug needs to be 
fixed:

https://bugreports.qt.io/browse/QTBUG-107599[1]
https://bugs.chromium.org/p/chromium/issues/detail?id=1374952[2]

Before the Galician .bdic can be built the following upstream bug needs to be 
fixed:

https://bugreports.qt.io/browse/QTBUG-107601[3]
https://bugs.chromium.org/p/chromium/issues/detail?id=1374957[4]

These upstream bugs have been submitted to both Qt and Google.

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


[1] https://bugreports.qt.io/browse/QTBUG-107599
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1374952
[3] https://bugreports.qt.io/browse/QTBUG-107601
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=1374957


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

Bug#1020602: procps: Remove dependency on lsb-base

[Johannes Schauer Marin Rodrigues]

Hi Craig,

Quoting Craig Small (2022-09-27 12:32:01)
> On Sat, 24 Sept 2022 at 15:12, Johannes Schauer Marin Rodrigues <
> jo...@debian.org> wrote:
> 
> > For your convenience, I've submitted a merge request on salsa:
> >
> > https://salsa.debian.org/debian/procps/-/merge_requests/6
> 
> Thanks for that, I've incorporated that merge in now.

thank you for merging the MR I filed!

You manually closed this bug more than two weeks ago but never uploaded a
version of procps that fixes this bug. This makes it look like the RC bug
#1020593 against my package is actually not blocked by any bug anymore. But it
still is because no upload happened.

Do you have an estimate for when you plan to do another procps upload?

If you do not find time I can also NMU procps with what's currently in git.

If you do not want me to NMU and you do not plan to upload any time soon,
please at least re-open this bug because I cannot do any new upload of my
package mmdebstrap before this issue is fixed.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1020481: Pending upstream bug fix

[Soren Stoutner]

Before this dictionary can be build a .bdic the following upstream bug needs to 
be 
fixed (reported both to Qt and to Google):

https://bugreports.qt.io/browse/QTBUG-107600[1]

https://bugs.chromium.org/p/chromium/issues/detail?id=1374955[2]
 
-- 
Soren Stoutner
so...@stoutner.com


[1] https://bugreports.qt.io/browse/QTBUG-107600
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1374955


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

Bug#1020827: logcheck-database: supplied patch file

[Richard Lewis]

control: tags -1 +patch

On Fri, 14 Oct 2022, 08:24 Thomas Dorner,  wrote:

> same here, I've patched it locally and just wanted to supply the patch.
>
> Hmm, I've just noticed, there actually already seems to be one.  I send
> this nonetheless.

Hi Thomas - i provided the previous patch: you found a couple more
instances that i missed (the \/ in ignore.s.server/samba and
ignore.d.workstation/kernel):
I've updated https://salsa.debian.org/debian/logcheck/-/merge_requests/14
to include your work as well -

Jose, as the debian maintainer are you able to review and push a fix
into the repository? (you could also credit Thomas in the changelog,
which isnt updated in the merge request. The merge request applies to
1.3.24 as i wasnt sure if the other commits in the master branch (ie
adding an empty package) were ready for release - but can rebase if
you want?)

This bug is going to be really annoying, so it would be awesome if it
could be fixed

Cheers!

Bug#1021801: RFS: sugarjar/0.0.11-1 [ITP] -- Git/GitHub helper script

[Michel Alexandre Salim]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "sugarjar":

 * Package name : sugarjar
   Version  : 0.0.11-1
   Upstream contact : Phil Dibowitz 
 * URL  : https://github.com/jaymzh/sugarjar
 * License  : Apache-2.0
 * Vcs  : https://salsa.debian.org/michel/sugarjar
   Section  : vcs

The source builds the following binary packages:

  sugarjar - Git/GitHub helper script

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sugarjar/sugarjar_0.0.11-1.dsc

Changes for the initial release:

 sugarjar (0.0.11-1) unstable; urgency=low
 .
   * Initial release (Closes: #1021743)
   * Backport patch to fix sj invoked without a valid command
   * Use installed lib when running rspec
   * Adjust salsa-ci.yml for 'all' architecture

Regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

On Friday, October 14, 2022 11:58:17 AM MST Andres Salomon wrote:
> That would allow chromium and other hunspell users to link against a
> system hunspell when desired, dropping all the bdict versioning stuff
> and the custom paths. I'm pretty sure I could get a patch to link
> against system hunspell into chromium upstream, provided bdic support
> made it into upstream hunspell.

I think that would be the way to go if both the upstreams would support it.

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

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

Bug#994348: python-apt: Removal of the python3-*-dbg packages in sid/bookworm

[Micha Lenk]

Hi there,

Just for the records, I started working on this bug. A first fix attempt 
is available on [1]salsa -- but unfortunately it causes the package to 
fail to build from source. I'll continue tomorrow.


 [1]. 
https://salsa.debian.org/micha/python-apt/-/compare/main...remove-python3-apt-dbg-package


Regards,
Micha

Bug#1020030: ukui-control-center: diff for NMU version 3.0.5-1.1

[Adrian Bunk]

Control: tags 1020030 + patch
Control: tags 1020030 + pending

Dear maintainer,

I've prepared an NMU for ukui-control-center (versioned as 3.0.5-1.1) 
and uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru ukui-control-center-3.0.5/debian/changelog ukui-control-center-3.0.5/debian/changelog
--- ukui-control-center-3.0.5/debian/changelog	2022-02-23 05:41:56.0 +0200
+++ ukui-control-center-3.0.5/debian/changelog	2022-10-14 23:57:13.0 +0300
@@ -1,3 +1,10 @@
+ukui-control-center (3.0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with new glib. (Closes: #1020030)
+
+ -- Adrian Bunk   Fri, 14 Oct 2022 23:57:13 +0300
+
 ukui-control-center (3.0.5-1) unstable; urgency=medium
 
   * New upstream releaes.
diff -Nru ukui-control-center-3.0.5/debian/patches/glib.patch ukui-control-center-3.0.5/debian/patches/glib.patch
--- ukui-control-center-3.0.5/debian/patches/glib.patch	1970-01-01 02:00:00.0 +0200
+++ ukui-control-center-3.0.5/debian/patches/glib.patch	2022-10-14 23:57:13.0 +0300
@@ -0,0 +1,15 @@
+Description: Fix FTBFS with new glib
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/1020030
+
+--- ukui-control-center-3.0.5.orig/plugins/account/userinfo/giodbus.cpp
 ukui-control-center-3.0.5/plugins/account/userinfo/giodbus.cpp
+@@ -18,7 +18,7 @@
+ 
+ #include "giodbus.h"
+ #include 
+-#include 
++#include 
+ #include 
+ 
+ int get_server_gvariant_stdout (int drvid)
diff -Nru ukui-control-center-3.0.5/debian/patches/series ukui-control-center-3.0.5/debian/patches/series
--- ukui-control-center-3.0.5/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ ukui-control-center-3.0.5/debian/patches/series	2022-10-14 23:57:13.0 +0300
@@ -0,0 +1 @@
+glib.patch

Bug#1021800: pgrouting: reproducible builds: Embeds kernel version of build machine

[Vagrant Cascadian]

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

The kernel version of the build environment is embedded in
/usr/lib/postgresql/14/lib/libpgrouting-3.4.so:

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

  Linux-5.18.0-0.deb11.4-amd64
  vs.
  Linux-5.10.0-18-amd64

The attached patch to src/version/version.h.in fixes this by using
CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM.

According to my local tests, with this patch applied, and the patch
submitted in #102179 to fix timestamps, pgrouting should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining pgrouting!

live well,
  vagrant
From bf3f11142a4eb045f692382d202c833679bed491 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 14 Oct 2022 20:19:45 +
Subject: [PATCH 2/2] src/version/version.h.in: Use CMAKE_SYSTEM_NAME to avoid
 embedding running kernel version.

https://tests.reproducible-builds.org/debian/issues/bookworm/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
---
 src/version/version.h.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/version/version.h.in b/src/version/version.h.in
index 52e5018..c023cf0 100644
--- a/src/version/version.h.in
+++ b/src/version/version.h.in
@@ -30,6 +30,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 #define COMPILATION_DATE "@COMPILATION_DATE@";
 #define PROJECT_GIT_HASH "@PROJECT_GIT_HASH@";
 #define PROJECT_LIB_NAME "@PROJECT_NAME_LOWER@-@PROJECT_VERSION@";
-#define CMAKE_SYSTEM_NAME "@CMAKE_SYSTEM@";
+#define CMAKE_SYSTEM_NAME "@CMAKE_SYSTEM_NAME@";
 #define POSTGRES_VERSION "@POSTGRESQL_VERSION_STRING@";
 
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021798: crowdsec: FTBFS: FAIL: TestCreateMachineWithForwardedFor

[Cyril Brulebois]

Hi,

Andreas Beckmann  (2022-10-14):
> Source: crowdsec
> Version: 1.0.9-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> Hi,
> 
> crowdsec in sid (and experimental) recently started to FTBFS:
> 
> === RUN   TestCreateMachineWithForwardedFor
> time="2022-10-14T20:21:20Z" level=info msg="Creating new API server"
>  - [Fri, 14 Oct 2022 20:21:20 UTC] "POST /v1/watchers HTTP/1.1 201 
> 56.31ms "crowdsec-test/" "
> machines_test.go:81:
> Error Trace:
> /build/crowdsec-1.0.9/_build/src/github.com/crowdsecurity/crowdsec/pkg/apiserver/machines_test.go:81
> Error:  Not equal:
> expected: "1.1.1.1"
> actual  : ""
> 
> Diff:
> --- Expected
> +++ Actual
> @@ -1 +1 @@
> -1.1.1.1
> +
> Test:   TestCreateMachineWithForwardedFor
> --- FAIL: TestCreateMachineWithForwardedFor (0.06s)

This should be fixed in the upcoming 1.4.x versions, the test suite
doesn't fail there. There are a bunch of dependencies that need to go in
before that can be uploaded though:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1020002: dnstap-ldns: diff for NMU version 0.2.0-5.1

[Adrian Bunk]

Control: tags 1020002 + patch
Control: tags 1020002 + pending

Dear maintainer,

I've prepared an NMU for dnstap-ldns (versioned as 0.2.0-5.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru dnstap-ldns-0.2.0/debian/changelog dnstap-ldns-0.2.0/debian/changelog
--- dnstap-ldns-0.2.0/debian/changelog	2020-12-13 09:53:45.0 +0200
+++ dnstap-ldns-0.2.0/debian/changelog	2022-10-14 23:17:32.0 +0300
@@ -1,3 +1,10 @@
+dnstap-ldns (0.2.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Adapt to ldns 1.8.3-1 dropping libldns.pc. (Closes: #1020002)
+
+ -- Adrian Bunk   Fri, 14 Oct 2022 23:17:32 +0300
+
 dnstap-ldns (0.2.0-5) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru dnstap-ldns-0.2.0/debian/patches/ldns-pc.patch dnstap-ldns-0.2.0/debian/patches/ldns-pc.patch
--- dnstap-ldns-0.2.0/debian/patches/ldns-pc.patch	1970-01-01 02:00:00.0 +0200
+++ dnstap-ldns-0.2.0/debian/patches/ldns-pc.patch	2022-10-14 23:17:32.0 +0300
@@ -0,0 +1,15 @@
+Description: Adapt to ldns 1.8.3-1 dropping libldns.pc
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/1020002
+
+--- dnstap-ldns-0.2.0.orig/configure.ac
 dnstap-ldns-0.2.0/configure.ac
+@@ -26,7 +26,7 @@ AC_SUBST([my_CFLAGS])
+ AC_CONFIG_HEADERS(config.h)
+ AC_CONFIG_FILES([Makefile])
+ 
+-PKG_CHECK_MODULES([libldns], [libldns])
++PKG_CHECK_MODULES([libldns], [ldns])
+ 
+ PKG_CHECK_MODULES([libfstrm], [libfstrm >= 0.2.0])
+ 
diff -Nru dnstap-ldns-0.2.0/debian/patches/series dnstap-ldns-0.2.0/debian/patches/series
--- dnstap-ldns-0.2.0/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ dnstap-ldns-0.2.0/debian/patches/series	2022-10-14 23:17:32.0 +0300
@@ -0,0 +1 @@
+ldns-pc.patch

Bug#1021799: pgrouting: reproducible builds: Embeds timezone-specific date in libpgrouting-3.4.so

[Vagrant Cascadian]

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

The build time is embedded in
/usr/lib/postgresql/14/lib/libpgrouting-3.4.so:

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

  2022/10/11
  vs.
  2022/10/12

The attached patch to CMakeLists.txt fixes this by passing the UTC
argument to the TIMESTAMP function.

According to my local tests, with this patch applied, and another patch
soon to be submitted for embedded kernel versions, pgrouting should
build reproducibly on tests.reproducible-builds.org!

Thanks for maintaining pgrouting!

live well,
  vagrant
From aacaaba547ed47a674f516e79052c44e5a8bced9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 14 Oct 2022 20:18:06 +
Subject: [PATCH 1/2] CMakeLists.txt: Specify UTC for TIMESTAMP.

https://tests.reproducible-builds.org/debian/issues/bookworm/timestamps_in_cmake_issue.html
---
 CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1f61927..a6ace99 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -29,7 +29,7 @@ include(pgr/Version)
 add_definitions(-DPROJECT_VERSION="${PROJECT_VERSION}${PROJECT_VERSION_DEV}")
 set(PROJECT_LIB_NAME "${PROJECT_NAME_LOWER}-${PROJECT_LIB_VERSION}")
 
-string(TIMESTAMP COMPILATION_DATE "%Y/%m/%d")
+string(TIMESTAMP COMPILATION_DATE "%Y/%m/%d" UTC)
 
 set(MINORS 3.4 3.3 3.2 3.1 3.0 2.6)
 set(OLD_SIGNATURES
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021798: crowdsec: FTBFS: FAIL: TestCreateMachineWithForwardedFor

[Andreas Beckmann]

Source: crowdsec
Version: 1.0.9-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

crowdsec in sid (and experimental) recently started to FTBFS:

=== RUN   TestCreateMachineWithForwardedFor
time="2022-10-14T20:21:20Z" level=info msg="Creating new API server"
 - [Fri, 14 Oct 2022 20:21:20 UTC] "POST /v1/watchers HTTP/1.1 201 56.31ms 
"crowdsec-test/" "
machines_test.go:81:
Error Trace:
/build/crowdsec-1.0.9/_build/src/github.com/crowdsecurity/crowdsec/pkg/apiserver/machines_test.go:81
Error:  Not equal:
expected: "1.1.1.1"
actual  : ""

Diff:
--- Expected
+++ Actual
@@ -1 +1 @@
-1.1.1.1
+
Test:   TestCreateMachineWithForwardedFor
--- FAIL: TestCreateMachineWithForwardedFor (0.06s)

Full log attached.


Andreas


crowdsec.sid.build.gz
Description: application/gzip

Bug#1021797: mvdsv FTBFS on !amd64

[Adrian Bunk]

Source: mvdsv
Version: 0.35-2
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=mvdsv=0.35-2

...
   dh_install -a -O--buildsystem=cmake
dh_install: warning: Cannot find (any matches for) "obj-x86_64-linux-gnu/mvdsv" 
(tried in ., debian/tmp)

dh_install: warning: mvdsv missing files: obj-x86_64-linux-gnu/mvdsv
dh_install: error: missing files, aborting
install -d debian/.debhelper/generated/mvdsv
make: *** [debian/rules:21: binary-arch] Error 25

Bug#1021796: silver-platter: workspace.py: ImportError: cannot import name 'NoColocatedBranchSupport' from 'breezy.errors'

[Andreas Beckmann]

Package: silver-platter
Version: 0.4.5-1
Severity: serious
Control: affects -1 src:janitor

Hi,

src:janitor recently started to FTBFS with some test failures
that seem to originate in silver-platter:

==
ERROR: test_debdiff (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_debdiff
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File "/build/janitor-0.1~git20220702/janitor/tests/test_debdiff.py", line 18, 
in 
from janitor.debian.debdiff import iter_sections, filter_boring
  File "/build/janitor-0.1~git20220702/janitor/debian/__init__.py", line 47, in 

from silver_platter.debian import (
  File "/usr/lib/python3/dist-packages/silver_platter/debian/__init__.py", line 
55, in 
from .. import workspace as _mod_workspace
  File "/usr/lib/python3/dist-packages/silver_platter/workspace.py", line 25, 
in 
from breezy.errors import (
ImportError: cannot import name 'NoColocatedBranchSupport' from 'breezy.errors' 
(/usr/lib/python3/dist-packages/breezy/errors.py)


==
ERROR: test_worker (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_worker
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File "/build/janitor-0.1~git20220702/janitor/tests/test_worker.py", line 18, 
in 
from janitor.worker import bundle_results
  File "/build/janitor-0.1~git20220702/janitor/worker.py", line 55, in 
from silver_platter.workspace import Workspace
  File "/usr/lib/python3/dist-packages/silver_platter/workspace.py", line 25, 
in 
from breezy.errors import (
ImportError: cannot import name 'NoColocatedBranchSupport' from 'breezy.errors' 
(/usr/lib/python3/dist-packages/breezy/errors.py)


Andreas


janitor_0.1~git20220702-1.log.gz
Description: application/gzip

Bug#1021795: groff-base: Please consider removing the extra spaces in Pq (& Po/Pc) and Bq (& Bo/Bc)

[наб]

Package: groff-base
Version: 1.22.4-6
Severity: normal

Dear Maintainer,

The weird spacing on Pqs when compared to ()s has always bugged me,
but now it's bugged me so hard I decided to look.

You may have noticed that, for example,
  (ibid)
is rendered differently from
  .Pq ibid

It's very obvious when you have both styles stacked together,
or even when you compare stacking punctuation at the end of a Sy-style
macro against Pqing it, and it looks pretty ass.

To ensure this isn't just placebo, here's three troff sessions:
-- >8 --
$ troff -mdoc
(ibid)
x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s1
V12000
H72000
md
DFd
t(ibid)
n12000 0
x trailer
V792000
x stop

$ troff -mdoc
.Pq ibid
x T ps
x res 72000 1 1
x init
p1
V12000
H72000
DFd
x font 5 TR
f5
s1
h1666
md
t(
h1666
tibid
h1666
t)
h1666
n12000 0
x trailer
V792000
x stop

$ troff -mdoc
.No ( ibid )
x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s1
V12000
H72000
md
DFd
t(ibid)
n12000 0
x trailer
V792000
x stop
-- >8 --

"(ibid)" and ".No ( ibid )" yield just "(ibid)",
".Pq ibid" adds 'h' (horizontal motion?).
If we insert some spaces, we get:
-- >8 --
$ troff -mdoc
(\|ibid\|)
x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s1
V12000
H72000
md
DFd
t(
h1666
tibid
h1666
t)
n12000 0
x trailer
V792000
x stop
-- >8 --
i.e. ".Pq ibid" is "(\|ibid\|)", so with ⅙m space around the text. Huge.

This doesn't seem to be an inherent limitation of groff/mdoc,
and instead appears to be explicit in
  /usr/share/groff/1.22.4/tmac/mdoc/doc-ditroff
as doc-left-parenthesis (and doc-left-bracket for B[qoc],
and the -right- variants, naturally).

As a test, I've removed these spaces from the strings,
and run off three copies of a monograph:
  * job 3300 is stock groff
  * job 3301 has \|s removed from doc-*-parenthesis
  * job 3302 has \^s removed from doc-*-bracket
which are available for comparison at
  https://lfs.nabijaczleweli.xyz/0012-groff-mdoc-*q-spacing

I especially direct your attention to pp. 4, 6, 7, 9, 10, 12, 14, 15;
this is especially egregious in the big paragraph on page 10, which no
longer consists of 20% blank space.

For Bq, I find the last paragraph of page 68 very illustrative
(and the SYNOPSIS looks markedly better, too).

In groff, these blame back to the original mdoc rewrite in 2001ish,
and are blindly copied from 4.4BSD-Lite2:
-- >8 --
usr/src/share/tmac/doc-nroff:.ds lP \fR\|(\fP
usr/src/share/tmac/doc-nroff:.ds rP \fR\|)\fP
usr/src/share/tmac/doc-nroff:.ds lB \fR\|[\|\fP
usr/src/share/tmac/doc-nroff:.ds rB \fR\|]\fP
usr/src/share/tmac/doc-ditroff:.ds lP \fR\|(\|\fP\s10
usr/src/share/tmac/doc-ditroff:.ds rP \fR\|)\|\fP\s10
usr/src/share/tmac/doc-ditroff:.ds lB \fR\^[\^\fP\s10
usr/src/share/tmac/doc-ditroff:.ds rB \fR\^]\fP\s10
-- >8 --

None of the other encapsulation macros I found in
  /usr/share/groff/1.22.4/tmac/mdoc/doc.tmac
have these spaces, and for comparison Op has them (in groff and 4.4BSD)
but Oo and Oc don't (likewise),
so this reads to me like compensation for like deficient font metrics
on the phototypesetters of yore? or something?

It'd be great if you could consider dropping them :)

Best,
наб

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

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

Versions of packages groff-base depends on:
ii  libc6 2.31-13+deb11u4
ii  libgcc-s1 10.2.1-6
ii  libstdc++610.2.1-6
ii  libuchardet0  0.0.7-1

groff-base recommends no packages.

Versions of packages groff-base suggests:
ii  groff  1.22.4-6

-- no debconf information


signature.asc
Description: PGP signature

Bug#1021794: libipc-run-perl: delay after child exit

[Jakub Wilk]

Package: libipc-run-perl
Version: 20220807.0-1

I've noticed that IPC::Run::run() sometimes takes significantly more 
time than the child process itself. For example:


   $ time -p perl -MIPC::Run=run -e "run('sleep 0.7')"
   real 1.18
   user 0.03
   sys 0.01

This is how it looks under strace:

   $ strace -T -e trace=pselect6 perl -MIPC::Run=run -e "run('sleep 0.7')"
   [ Process PID=8271 runs in 32 bit mode. ]
   pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=10}, NULL) = 0 (Timeout) 
<0.000164>
   pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=10}, NULL) = 0 (Timeout) 
<0.000161>
   pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=10}, NULL) = 0 (Timeout) 
<0.000160>
   ...
   pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=10}, NULL) = 0 (Timeout) 
<0.000248>
   pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=10}, NULL) = 0 (Timeout) 
<0.000212>
   pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=5}, NULL) = ? 
ERESTARTNOHAND (To be restarted if no handler) <0.031700>
   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8272, si_uid=1000, 
si_status=0, si_utime=0, si_stime=0} ---
   pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=468403068}, NULL) = 0 (Timeout) 
<0.469205>
   +++ exited with 0 +++

So there's nearly half a second delay after the child exits.


-- System Information:
Architecture: i386

Versions of packages libipc-run-perl depends on:
ii  perl5.34.0-5
ii  libio-pty-perl  1:1.15-2+b1

--
Jakub Wilk

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Mattia Rizzolo]

On Fri, Oct 14, 2022 at 02:58:17PM -0400, Andres Salomon wrote:
> In my opinion, chromium's (, or QT's, or whoever's) bdic support should be
> merged upstream into hunspell, and hunspell should be shipping bdic files in
> /usr/share/hunspell alongside the .aff and .dic files. I don't know how
> active hunspell upstream is, though, and how amenable they'd be to patches.
> I see at least one person created an hunspell-with-bdic-support fork a
> decade ago: https://github.com/sheremetyev/hunspell
> 
> That would allow chromium and other hunspell users to link against a system
> hunspell when desired, dropping all the bdict versioning stuff and the
> custom paths. I'm pretty sure I could get a patch to link against system
> hunspell into chromium upstream, provided bdic support made it into upstream
> hunspell.
> 
> I wouldn't want to see debian carrying bdic patches in its hunspell package,
> though; nor would I want to see the security team needing to deal with a
> hunspell fork package.

I think you are the first to mention "integrating" bdic into hunspell
itself, and to mention that effectively the parser is based on hunspell
itself…

From what I know, the hunspell project is basically in maintenance mode,
with nobody actively doing anything to it.  Pretty much all changes in
the past years were done by drive-by contributors.

This is to say, I can't deny that somebody proposing MRs upstream might
actually see them merged.

> >   5) something else
> >   (The order mentions my personal preference)
> > - Is there some commandline client for auto-testing the bdic files?
> > - How to reuse the bdic files with chromium?
> > - 3 bugs in qwebengine_convert_dict reported by Soren Stoutner
> 
> 
> I just took a peek at qtwebengine-opensource-src-5.15.10+dfsg, and I see
> that they're using the exact same hunspell fork from chromium.  :(

Not surprising since afaik qtwebengine is basically a fork of chromium
itself...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1021793: vart: reproducible builds: buildid differences triggered by build paths

[Vagrant Cascadian]

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

The buildid for various binaries differs when built from a different
build path:

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

The attached patch to debian/rules fixes this by passing
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to configure.

According to my local tests, with this patch applied, and the patch
submitted in #1021792 to fix timestamp issues, vart should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining vart!

live well,
  vagrant
From 5cd438a9d5fbb958efaabc804584998aa3d14396 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 14 Oct 2022 19:33:34 +
Subject: [PATCH 2/2] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to
 avoid differences when built from different build path.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 1eb4d91..c31a2c1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,7 @@ export DEB_CFLAGS_MAINT_APPEND  = -Wall
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 CONFIGURE_ARGS = -DCMAKE_BUILD_TYPE=Debug \
+	-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 	-DENABLE_DPU_RUNNER=ON \
 	-DENABLE_XRNN_RUNNER=ON
 
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021792: vart: reproducible builds: Embeds build time in in various binaries

[Vagrant Cascadian]

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

The build time is embedded in various binaries:

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

  /usr/lib/x86_64-linux-gnu/libvart-buffer-object.so.2.5.0

  Xilinx·vart-buffer-object·Version:·2.5.0-··2023-11-14-01:55:35·
  vs.
  Xilinx·vart-buffer-object·Version:·2.5.0-··2022-10-12-21:36:55·

The attached patch to the two upstream cmake files fixes this by using
the TIMESTAMP function of cmake rather than calling date directly.

According to my local tests, with this patch applied, vart should build
reproducibly on tests.reproducible-builds.org once it migrates to
bookworm/testing! Differing build paths trigger additional issues, which
are only tested in unstable and experimental.

Thanks for maintaining vart!

live well,
  vagrant
From 1c216f4f812bbbaa6af1b624191fa2c6813c72df Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 14 Oct 2022 19:31:36 +
Subject: [PATCH 1/2] Use cmake TIMESTAMP feature instead of calling "date"
 directly.

The cmake TIMESTAMP function respects SOURCE_DATE_EPOCH, allowing
reproducible timestamps when specified.
---
 cmake/VitisVersion.cmake  | 6 ++
 trace/vaitrace/CMakeLists.txt | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/cmake/VitisVersion.cmake b/cmake/VitisVersion.cmake
index 9801037..4969018 100644
--- a/cmake/VitisVersion.cmake
+++ b/cmake/VitisVersion.cmake
@@ -14,10 +14,8 @@
 # limitations under the License.
 #
 #
-execute_process(
-  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
-  COMMAND date +%F-%T
-  OUTPUT_VARIABLE BUILD_DATE)
+
+string(TIMESTAMP BUILD_DATE "+%F-%T" UTC)
 string(STRIP "${BUILD_DATE}" BUILD_DATE)
 if ("${GIT_VERSION}" STREQUAL "")
   execute_process(
diff --git a/trace/vaitrace/CMakeLists.txt b/trace/vaitrace/CMakeLists.txt
index 57b7482..de930d7 100644
--- a/trace/vaitrace/CMakeLists.txt
+++ b/trace/vaitrace/CMakeLists.txt
@@ -19,7 +19,7 @@ project(vaitrace VERSION 2.5.20221)
 set(VAITRACE_DEST_PATH bin/xlnx/${PROJECT_NAME})
 
 # Generate Version Flags
-execute_process(COMMAND date +%F-%T OUTPUT_VARIABLE VAITRACE_BUILD_DATE)
+string(TIMESTAMP VAITRACE_BUILD_DATE "+%F-%T" UTC)
 string(STRIP "${VAITRACE_BUILD_DATE}" VAITRACE_BUILD_DATE)
 execute_process(
   WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1020011: ukui-biometric-manager: diff for NMU version 1.0.3-1.1

[Adrian Bunk]

Control: tags 1020011 + patch
Control: tags 1020011 + pending

Dear maintainer,

I've prepared an NMU for ukui-biometric-manager (versioned as 1.0.3-1.1) 
and uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru ukui-biometric-manager-1.0.3/debian/changelog ukui-biometric-manager-1.0.3/debian/changelog
--- ukui-biometric-manager-1.0.3/debian/changelog	2022-03-15 14:47:59.0 +0200
+++ ukui-biometric-manager-1.0.3/debian/changelog	2022-10-14 22:35:45.0 +0300
@@ -1,3 +1,10 @@
+ukui-biometric-manager (1.0.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with new glib. (Closes: #1020011)
+
+ -- Adrian Bunk   Fri, 14 Oct 2022 22:35:45 +0300
+
 ukui-biometric-manager (1.0.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru ukui-biometric-manager-1.0.3/debian/patches/glib.patch ukui-biometric-manager-1.0.3/debian/patches/glib.patch
--- ukui-biometric-manager-1.0.3/debian/patches/glib.patch	1970-01-01 02:00:00.0 +0200
+++ ukui-biometric-manager-1.0.3/debian/patches/glib.patch	2022-10-14 22:35:45.0 +0300
@@ -0,0 +1,15 @@
+Description: Fix FTBFS with new glib
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/1020011
+
+--- ukui-biometric-manager-1.0.3.orig/src/giodbus.cpp
 ukui-biometric-manager-1.0.3/src/giodbus.cpp
+@@ -18,7 +18,7 @@
+ 
+ #include "giodbus.h"
+ #include 
+-#include 
++#include 
+ #include 
+ 
+ int get_server_gvariant_stdout (int drvid)
diff -Nru ukui-biometric-manager-1.0.3/debian/patches/series ukui-biometric-manager-1.0.3/debian/patches/series
--- ukui-biometric-manager-1.0.3/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ ukui-biometric-manager-1.0.3/debian/patches/series	2022-10-14 22:35:45.0 +0300
@@ -0,0 +1 @@
+glib.patch

Bug#1021790: src:graphicsmagick: fails to migrate to testing for too long: FTBFS on mips64el

[Paul Gevers]

Hi László,

On 14-10-2022 21:33, László Böszörményi (GCS) wrote:

Your package src:graphicsmagick has been trying to migrate
for 61 days [2].

  It's 'only' 37 days, but that's long enough even.


Hmm, [1] says your package was accepted on 14 August 2022; no sure where 
that weird count in the britney output comes from. Maybe because it took 
so long before the first binaries were built?



Then of course I've already gone on and investigated
this issue with its upstream developer.


It's good to have that documented. Thanks for being pro-active.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021426: bullseye-pu: package glibc/2.31-13+deb11u5

[Aurelien Jarno]

Hi,

On 2022-10-14 11:58, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2022-10-08 at 11:30 +0200, Aurelien Jarno wrote:
> > The glibc/2.31-13+deb11u4 update introduced a regression (bug
> > #1019855) on some early Intel Haswell processors which expose the
> > AVX2 instructions, but lack the BMI2 instructions. On such systems
> > the memchr and strlen related functions fails with SIGILL, rendering
> > them unusable.
> > 
> > The issue is that some of the backported commits to fix the overflow
> > bugs in the AVX2 implementation of wmemchr and wcslen that went in
> > the upstream 2.31 branch, started to use BMI2 instructions in
> > addition to the AVX2 instructions, without checking for the
> > availability of those instructions. This was done in another commit
> > that hasn't been backported.
> > 
> > It happens that a microcode update for the affected CPUs (either
> > through the BIOS/firmware or from a package) fixes this, so it went
> > barely noticed up to now, especially given other distributions
> > usually install firmware updates by default.
> > 
> > [ Impact ]
> > While the number of affected systems is probably small, this bug
> > makes them unusable.
> [...]
> > Given the severity of the bug, it might be a good idea to release it
> > through stable-updates.
> 
> Please go ahead.

Thanks for the review, I have just uploaded it.

Regards
Aurelien

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

Bug#1021791: Testsuite needs updated permissions with PostgreSQL 15

[Christoph Berg]

Re: To Debian Bug Tracking System
> redmine needs updating for this; one workaround for the testsuite
> would be to "grant create on schema public to public;" to revert to
> the old default.

It's not the testsuite failing; it's already the postinst failing to
install redmine.

Christoph

Bug#1021790: src:graphicsmagick: fails to migrate to testing for too long: FTBFS on mips64el

[GCS]

Hi Paul, Marti,

On Fri, Oct 14, 2022 at 9:09 PM Paul Gevers  wrote:
> The Release Team considers packages that are out-of-sync between testing
> and unstable for more than 60 days as having a Release Critical bug in
> testing [1]. Your package src:graphicsmagick has been trying to migrate
> for 61 days [2]. Hence, I am filing this bug. Your package failed to
> build from source on mip64el while it built successfully there in the past.
 It's 'only' 37 days, but that's long enough even.

> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
 I totally agree. Then of course I've already gone on and investigated
this issue with its upstream developer. Turns out it's a regression in
src:lcms2 and already fixed in its Git HEAD. Its upstream developer
(Cc-d) noted there might be a new release soon.
How do you see it now Marti? Do you know which commit might it be so I
can ask the lcms2 maintainer to backport it to the Debian package
instead?

Thanks,
Laszlo/GCS

Bug#1021791: Testsuite needs updated permissions with PostgreSQL 15

[Christoph Berg]

Source: redmine
Version: 5.0.2-2
Severity: serious

PostgreSQL 15 restricts the CREATE privilege on the default "public"
schema in each database to the database owner; previous all users were
allowed to create new objects.

redmine needs updating for this; one workaround for the testsuite
would be to "grant create on schema public to public;" to revert to
the old default.

https://ci.debian.net/data/autopkgtest/testing/arm64/r/redmine/27072176/log.gz

Setting up redmine (5.0.2-2) ...
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
installing your bundle as root will break this application for all non-root
users on this machine.
dbconfig-common: writing config to 
/etc/dbconfig-common/redmine/instances/default.conf
creating postgres user redmine/instances/default:  already exists.
resetting password:  success.
creating database redmine_default: already exists.
dbconfig-common: flushing administrative password
rake aborted!
ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR:  permission 
denied for schema public
LINE 1: CREATE TABLE "schema_migrations" ("version" character varyin...
 ^
/usr/share/rubygems-integration/all/gems/activerecord-6.1.7/lib/active_record/connection_adapters/postgresql/database_statements.rb:49:in
 `exec'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.7/lib/active_record/connection_adapters/postgresql/database_statements.rb:49:in
 `block (2 levels) in execute'
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7/lib/active_support/dependencies/interlock.rb:48:in
 `block in permit_concurrent_loads'
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7/lib/active_support/concurrency/share_lock.rb:187:in
 `yield_shares'

(Possibly this might need fixing in dbconfig-common.)

Christoph

Bug#1016599: mayavi2: diff for NMU version 4.8.0-1.1

[Adrian Bunk]

Control: tags 1016599 + patch
Control: tags 1016599 + pending

Dear maintainer,

I've prepared an NMU for mayavi2 (versioned as 4.8.0-1.1) and uploaded 
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru mayavi2-4.8.0/debian/changelog mayavi2-4.8.0/debian/changelog
--- mayavi2-4.8.0/debian/changelog	2022-07-23 08:27:58.0 +0300
+++ mayavi2-4.8.0/debian/changelog	2022-10-14 22:16:53.0 +0300
@@ -1,3 +1,10 @@
+mayavi2 (4.8.0-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control: python3-vtk7 -> python3-vtk9 (Closes: #1016599)
+
+ -- Adrian Bunk   Fri, 14 Oct 2022 22:16:53 +0300
+
 mayavi2 (4.8.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: #997856)
diff -Nru mayavi2-4.8.0/debian/control mayavi2-4.8.0/debian/control
--- mayavi2-4.8.0/debian/control	2022-07-23 08:27:58.0 +0300
+++ mayavi2-4.8.0/debian/control	2022-10-14 22:16:53.0 +0300
@@ -16,7 +16,7 @@
python3-setuptools,
python3-traits (>= 6.3.2) ,
python3-traitsui (>= 7.2.1) ,
-   python3-vtk7,
+   python3-vtk9,
xauth,
xvfb,
 Standards-Version: 4.6.0
@@ -40,7 +40,7 @@
  python3-pygments,
  python3-traits (>= 6.3.2),
  python3-traitsui (>= 7.2.1),
- python3-vtk7,
+ python3-vtk9,
 Suggests: python3-scipy,
   ipython3
 Description: scientific visualization package for 2-D and 3-D data

Bug#1021790: src:graphicsmagick: fails to migrate to testing for too long: FTBFS on mips64el

[Paul Gevers]

Source: graphicsmagick
Version: 1.4+really1.3.38-1
Severity: serious
Control: close -1 1.4+really1.3.38+hg16739-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:graphicsmagick has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package failed to 
build from source on mip64el while it built successfully there in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=graphicsmagick



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Andres Salomon]

On Fri, Oct 14 2022 at 12:54:53 PM +0200, Roland Rosenfeld 
 wrote:

Hi,

let me try to summarize where we stand and what options and open
questions we have.

I see the following options to package the bdic-Files (seems not all
of them were already mentioned before):

a) Bundle the bdic files in the existing hunspell- files.
   - Pro: no new packages needed
   - Con: Duplicate size of existing ~80 packages
b) Create new packages hunspell-bdic-.
   - Pro: User can install what is needed
   - Con: ~80 new packages necessary
c) Add a mechanism to dictionaries-common, which extends
   update-dictcommon-hunspell to build the bdic file in
   hunspell-.postinst.
   - Pro: No changes in hunspell-
   - Pro: No redundancy in Archive
   - Con: Wastes space on users disk, unless QtWebEngine is used
   - Con: May slow down hunspell- installation
   - Con: Pulls in qtwebengine5-dev-tools for all hunspell- 
packages

d) Add a new package (hunspell-bdic-generator or the like), that
   builds bdic files for all hunspell- packages if it is
   installed.  This requires some dpkg/apt-hook to trigger building
   bdic if a new hunspell- package is installed or upgraded.
   All packages using bdic files have to depend on
   hunspell-bdic-generator.
   - Pro: No changes in hunspell-
   - Pro: No redundancy in Archive
   - Pro: Only used/installed when needed
   - Con: Complex hook mechanism

I'm not sure what option I prefer myself, they all have
disadvantages, but I personally prefer b) over a), while c) and d)
could reduce the effort for hunspell- maintainers (in trade-off
to the efforts in dictionaries-common).



I don't have a strong opinion about a) vs b).





Except this I see the following open points:
- Is bdic really arch:all or do we have some endiane issue?  For 
option

  c) and d) this is irrelevant.


There shouldn't be endian issues, as I mentioned elsewhere.



- Where should the bdic files be placed?
  1) /usr/share/hunspell-bdic
  2) /usr/share/qtwebengine-dict
  3) /usr/share/bdic
  4) /usr/share/hunspell



In my opinion, chromium's (, or QT's, or whoever's) bdic support should 
be merged upstream into hunspell, and hunspell should be shipping bdic 
files in /usr/share/hunspell alongside the .aff and .dic files. I don't 
know how active hunspell upstream is, though, and how amenable they'd 
be to patches. I see at least one person created an 
hunspell-with-bdic-support fork a decade ago: 
https://github.com/sheremetyev/hunspell


That would allow chromium and other hunspell users to link against a 
system hunspell when desired, dropping all the bdict versioning stuff 
and the custom paths. I'm pretty sure I could get a patch to link 
against system hunspell into chromium upstream, provided bdic support 
made it into upstream hunspell.


I wouldn't want to see debian carrying bdic patches in its hunspell 
package, though; nor would I want to see the security team needing to 
deal with a hunspell fork package.




  5) something else
  (The order mentions my personal preference)
- Is there some commandline client for auto-testing the bdic files?
- How to reuse the bdic files with chromium?
- 3 bugs in qwebengine_convert_dict reported by Soren Stoutner



I just took a peek at qtwebengine-opensource-src-5.15.10+dfsg, and I 
see that they're using the exact same hunspell fork from chromium.  :(




- Do we target this this to bookworm or trixie?

Greetings
Roland

Bug#1012871: Reassigning

[Lisandro Damián Nicanor Pérez Meyer]

reassign 1012871 src:qt6-multimedia
forwarded 1012871 https://bugreports.qt.io/browse/QTBUG-104226
thanks

The issue is on the way Qt locates the devices + how it handles gst
classes. The fix ought to be there with 6.4.1.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1021789: dlt-viewer: reproducible-builds: date in PDF files

[Vagrant Cascadian]

Source: dlt-viewer
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The date is embedded in various .pdf files:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/dlt-viewer.html

  /usr/share/doc/dlt-viewer/dlt_viewer_plugins_programming_guide.pdf.gz

  October·12,·2022
  vs.
  November·15,·2023

The attached patch sets FORCE_SOURCE_DATE in debian/rules to ensure that
texlive respects SOURCE_DATE_EPOCH for a reproducible timestamp.

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

Thanks for maintaining dlt-viewer!

live well,
  vagrant
From aa6f2e8c6abce5f87760b52a4d4dbdb92749cd16 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 14 Oct 2022 18:39:17 +
Subject: [PATCH] debian/rules: Ensure reproducible timestamps.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index e27cbb2..497e7de 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,10 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
+# Ensure texlive respects SOURCE_DATE_EPOCH for reproducible
+# timestamps
+export FORCE_SOURCE_DATE=1
+
 doc/dlt_viewer_user_manual.pdf: doc/dlt_viewer_user_manual.tex
 	cd doc && \
 		pdflatex $(^F) && \
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1021788: ITP: savvy -- conversion tool for SAV file format

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: savvy -- conversion tool for SAV file format
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: savvy
  Version : 2.1.0
  Upstream Author : xx-20yy FIXME
* URL : https://github.com/statgen/savvy
* License : MPL-2.0
  Programming Lang: C++
  Description : conversion tool for SAV file format
 Savvy is the official C++ interface for the SAV file format and offers
 seamless support for BCF and VCF files.
 .
 The binary sav can be used to handle SAV filed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/savvy

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Andres Salomon]

FYI:

Chromium includes an embedded copy of the hunspell library, which 
they've forked to ignore dic/aff files and instead use bdic files. The 
patch and google additions can be found here:


https://sources.debian.org/src/chromium/106.0.5249.119-1/third_party/hunspell/google.patch/

https://sources.debian.org/src/chromium/106.0.5249.119-1/third_party/hunspell/google/

You'll note that bdict.h in the google directory mentions right up 
front that offsets in bdict format are little endian, and also 
describes endianness of integer fields themselves. That means putting 
bdic files into arch:all should be fine, as the tools should convert 
them automatically on big-endian platforms (and if they don't, it's a 
bug that chromium devs would accept a fix for).


On Fri, Oct 14 2022 at 08:34:25 PM +0200, Roland Rosenfeld 
 wrote:
 It doesn’t directly address the topic of endianess, but it does 
say

 the following:

 "The .bdic files are always UTF-8 internally, and the convert_dict
 tool converts things appropriately when it runs.”

 I must admit that the topic of endianess goes a bit beyond my
 expertise, but my understanding is that it is primarily an issue for
 executable files. As the .bdic is only a data file, and as the data
 encoded inside it is in UTF-8 as described above, would that mean
 that it is safe to assume that these are arch:all?


I'm also not very familiar with this, so I tried to check out.  I
noted that s390x is big endian (in contrast to nearly all other
supported architectures) and so I logged into a s390x porter box to
build a bdic file and compare it with one build on other
architectures.

When I tried to install qtwebengine5-dev-tools I had to notice, that
this package is not available for s390x.  Checking
https://tracker.debian.org/pkg/qtwebengine-opensource-src I noticed,
that the package is limited to amd64, arm64, armhf, i386, mips64el and
mipsel.  Which means, that it is not available on armel, ppc64el and
s390x (and all other non release relevant architectures).

That's a big drawback, since we want to support the hunspell
dictionaries on all architectures.

I checked, whether the convert_dict tool (mentioned in the chromium
page "Editing the spell checking dictionaries") may be available in
Debian for other architectures, but I only found
qt6-webengine-dev-tools, which supports an even shorter architecture
list (only amd64, arm64, armhf and i386)...

Greetings
Roland

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Roland Rosenfeld]

> It doesn’t directly address the topic of endianess, but it does say
> the following:
> 
> "The .bdic files are always UTF-8 internally, and the convert_dict
> tool converts things appropriately when it runs.”
> 
> I must admit that the topic of endianess goes a bit beyond my
> expertise, but my understanding is that it is primarily an issue for
> executable files. As the .bdic is only a data file, and as the data
> encoded inside it is in UTF-8 as described above, would that mean
> that it is safe to assume that these are arch:all?

I'm also not very familiar with this, so I tried to check out.  I
noted that s390x is big endian (in contrast to nearly all other
supported architectures) and so I logged into a s390x porter box to
build a bdic file and compare it with one build on other
architectures.

When I tried to install qtwebengine5-dev-tools I had to notice, that
this package is not available for s390x.  Checking
https://tracker.debian.org/pkg/qtwebengine-opensource-src I noticed,
that the package is limited to amd64, arm64, armhf, i386, mips64el and
mipsel.  Which means, that it is not available on armel, ppc64el and
s390x (and all other non release relevant architectures).

That's a big drawback, since we want to support the hunspell
dictionaries on all architectures.

I checked, whether the convert_dict tool (mentioned in the chromium
page "Editing the spell checking dictionaries") may be available in
Debian for other architectures, but I only found
qt6-webengine-dev-tools, which supports an even shorter architecture
list (only amd64, arm64, armhf and i386)...

Greetings
Roland

Bug#1017829: elpa-ess: emacs-gtk 28.1 install fails with installed elpa-ess

[Dirk Eddelbuettel]

Salut Seb,

On 14 October 2022 at 20:10, Sébastien Villemot wrote:
| Hi Dirk!
| 
| Le dimanche 21 août 2022 à 09:17 -0500, Dirk Eddelbuettel a écrit :
| > That is a problem, and it is somewhat know.  ESS used to release every six 
or
| > so months, now we are many years behind with no official release.  Your best
| > bet may be to install directly from melpa and removing the package.
| > 
| > I will bring this to the ESS list but last time this was brought up 
everybody
| > more or less agreed but no release tarball was made because "it's 
complicated".
| 
| Would you be willing to consider shipping a snapshot of the git
| repository (as is available on MELPA)? This would be a temporary
| solution until upstream finally makes a formal release. Otherwise it
| looks like ESS will not be part of bookworm…

Correct.

See https://stat.ethz.ch/pipermail/ess-help/2022-September/thread.html
and _many_ earlier threads over the years bemoaning (in more polite words)
the irritating stale mate among that team and the inability to make a release
for four years now. (Mailmain archives are a pain to search but you know how
to condition a search engine to a site etc.)
 
| Shipping a git snapshot is established practice in Debian, especially
| for situations like the present one.
| 
| I am willing to help if needed.

I don't actually speak (e)lisp so I cannot help, and I have no appetite
getting into issues with upstream.

If you want to take over the package, I would welcome that and happily pass
it on to you. I was care taker for a while, but it may be time to pass that
torch on.

Amicalement,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1015860: libxalan2-java: CVE-2022-34169

[Moritz Mühlenhoff]

Am Thu, Oct 13, 2022 at 09:36:09PM +0200 schrieb Markus Koschany:
> Hi,
> 
> I just had a go at this issue and I discovered that libxalan2-java in Debian 
> is
> not affected but rather bcel.
> 
> https://tracker.debian.org/pkg/bcel
> 
> The fixing commit in OpenJDK addresses the same code which is nowhere to be
> found in libxalan2-java but is present in bcel. The bcel upstream commit can 
> be
> found at
> 
> https://github.com/apache/commons-bcel/commit/f3267cbcc900f80851d561bdd16b239d936947f5
> 
> 
> I suggest to reassign the bug to bcel. I agree that libxalan2-java should be
> retired eventually. It is required by quite some reverse-dependencies though
> and it may take some time to achieve that. In theory everything should work
> without the library, because the code is in OpenJDK already?

Nice find!

> I am not sure if we should request to clarify the CVE description or at least
> post on oss-security to make other people aware of it. I assume the official
> xalan2 release ships an internal copy of bcel and that might be the reason for
> the confusion.

Yeah, I think it would be best if you were to post to oss-security about this,
then this can be picked up as a public reference to other distros (and the
URL in the list archives could be used to challenge/update the CVE ID).

Cheers,
Moritz

Bug#1021787: commons-text: CVE-2022-42889

[Moritz Mühlenhoff]

Source: commons-text
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for commons-text.

CVE-2022-42889[0]:
| Apache Commons Text performs variable interpolation, allowing
| properties to be dynamically evaluated and expanded. The standard
| format for interpolation is "${prefix:name}", where "prefix" is used
| to locate an instance of org.apache.commons.text.lookup.StringLookup
| that performs the interpolation. Starting with version 1.5 and
| continuing through 1.9, the set of default Lookup instances included
| interpolators that could result in arbitrary code execution or contact
| with remote servers. These lookups are: - "script" - execute
| expressions using the JVM script execution engine (javax.script) -
| "dns" - resolve dns records - "url" - load values from urls, including
| from remote servers Applications using the interpolation defaults in
| the affected versions may be vulnerable to remote code execution or
| unintentional contact with remote servers if untrusted configuration
| values are used. Users are recommended to upgrade to Apache Commons
| Text 1.10.0, which disables the problematic interpolators by default.

https://www.openwall.com/lists/oss-security/2022/10/13/4

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1021786: nss: CVE-2022-3479

[Moritz Mühlenhoff]

Source: nss
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for nss.

CVE-2022-3479[0]:
| A vulnerability found in nss. By this security vulnerability, nss
| client auth crash without a user certificate in the database and this
| can lead us to a segmentation fault or crash.

https://bugzilla.mozilla.org/show_bug.cgi?id=1774654

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1021785: golang-golang-x-text: CVE-2022-32149

[Moritz Mühlenhoff]

Source: golang-golang-x-text
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for golang-golang-x-text.

CVE-2022-32149[0]:
| An attacker may cause a denial of service by crafting an Accept-
| Language header which ParseAcceptLanguage will take significant time
| to parse.

https://groups.google.com/g/golang-dev/c/qfPIly0X7aU.
https://go.dev/issue/56152
https://github.com/golang/text/commit/434eadcdbc3b0256971992e8c70027278364c72c

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1017829: elpa-ess: emacs-gtk 28.1 install fails with installed elpa-ess

[Sébastien Villemot]

Hi Dirk!

Le dimanche 21 août 2022 à 09:17 -0500, Dirk Eddelbuettel a écrit :
> That is a problem, and it is somewhat know.  ESS used to release every six or
> so months, now we are many years behind with no official release.  Your best
> bet may be to install directly from melpa and removing the package.
> 
> I will bring this to the ESS list but last time this was brought up everybody
> more or less agreed but no release tarball was made because "it's 
> complicated".

Would you be willing to consider shipping a snapshot of the git
repository (as is available on MELPA)? This would be a temporary
solution until upstream finally makes a formal release. Otherwise it
looks like ESS will not be part of bookworm…

Shipping a git snapshot is established practice in Debian, especially
for situations like the present one.

I am willing to help if needed.

Best wishes,

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



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

Bug#1017629: python-jsonschema: Please provide a newer upstream release (>= 4.9.0)

[Samuel Henrique]

Hello Thomas, I hope you're well,

Not meaning to rush you, just a heads up in case it was missed (since
it's automated):

4.7.2-3 migrated to testing, we should be good to get 4.9.1 on sid.
The experimental excuses page is not showing any regressions, which
means it will probably migrate to testing smoothly:
https://qa.debian.org/excuses.php?experimental=1=python-jsonschema

Thank you for your work :)

-- 
Samuel Henrique 

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

[Theodore Ts'o]

On Fri, Oct 14, 2022 at 03:37:29PM +0200, Marco d'Itri wrote:
> On Oct 14, Vincent Lefevre  wrote:
> 
> > > This is obviously convenient on Guillem's part, but we have to optimize 
> > > systems by default for the general case and not just for dpkg -i.
> > This dpkg FAQ says that this is not beneficial for just dpkg,
> > but also "for any application in the system".
> [citation needed]
> 
> I hope that you understand why at this point I cannot trust as is the 
> opinions of the dpkg maintainer.

The dpkg FAQ is just wrong.  It relates to controversy which is over a
dozen years old.  For more information see, see Josef Sipek's blog
post from 2009, "O_PONIES & Other Assorted Wishes"

https://blahg.josefsipek.net/?p=364

The O_PONIES mention references an 2009 April Fool's patch:


https://lore.kernel.org/linux-fsdevel/20090401041843.gn19...@josefsipek.net/

Because buggy applications and clueless application programmers vastly
outnumbers file system maintainers, at the 2009 LSF/MM workshop, a
number of the major file system developers agreed on the following
workaround.  If the application opens a pre-existing file with
O_TRUNC, or renames a newly created file on top of pre-existing file,
we will force the delayed allocation to be automatically resolved when
the file is closed (in the first case) or the rename (in the second
case).  It does *not* force a file system commit.  So if you crash
within 5 seconds of the close(2) or rename(2), you will still suffer
data loss.

HOWEVER, this was always the case for buggy applicatons that refused
to call fsync(2) who were relying on the old ext3 file system
semantics.  It did not guarantee that things would work; it would just
*mostly* work, since *usually* you didn't crash within 5 seconds of
rewriting a file.

So no, we're not going to be making the default change to /etc/fstab.

NACK.

- Ted

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

This is Google’s page describing the .bdic format:

https://sites.google.com/a/chromium.org/dev/developers/how-tos/editing-the-spell-checking-dictionaries[1]

It doesn’t directly address the topic of endianess, but it does say the 
following:

"The .bdic files are always UTF-8 internally, and the convert_dict tool 
converts things 
appropriately when it runs.”

I must admit that the topic of endianess goes a bit beyond my expertise, but my 
understanding is that it is primarily an issue for executable files.  As the 
.bdic is only a data 
file, and as the data encoded inside it is in UTF-8 as described above, would 
that mean that 
it is safe to assume that these are arch:all?

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


[1] 
https://sites.google.com/a/chromium.org/dev/developers/how-tos/editing-the-spell-checking-dictionaries


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

Bug#1013011: opensc: ftbfs with GCC-12

[Reiner Herrmann]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2022-10-de-karlsruhe
thankyou

Hi,

the attached patch imported from the upstream repository fixes the FTBFS.

Kind regards,
  Reiner
From bdca5c7fe4d6f3a23287f62e0be044bef3de1974 Mon Sep 17 00:00:00 2001
From: Reiner Herrmann 
Date: Fri, 14 Oct 2022 19:27:01 +0200
Subject: [PATCH] Import upstream patch to fix pointer usage after realloc

Closes: #1013011
---
 debian/patches/gcc12.patch | 31 +++
 debian/patches/series  |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 debian/patches/gcc12.patch

diff --git a/debian/patches/gcc12.patch b/debian/patches/gcc12.patch
new file mode 100644
index ..029da4af
--- /dev/null
+++ b/debian/patches/gcc12.patch
@@ -0,0 +1,31 @@
+From 0f7082ea46562b15221f428860b993e0519c6cbd Mon Sep 17 00:00:00 2001
+From: Veronika Hanulikova 
+Date: Wed, 16 Feb 2022 11:59:27 +0100
+Bug-Debian: https://bugs.debian.org/1013011
+Subject: [PATCH] Fix usage of pointer after realloc
+
+---
+ src/sm/sm-iso.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/src/sm/sm-iso.c b/src/sm/sm-iso.c
+index 5baded77c6..2c3f6bcabd 100644
+--- a/src/sm/sm-iso.c
 b/src/sm/sm-iso.c
+@@ -181,13 +181,14 @@ static int format_le(size_t le, struct sc_asn1_entry *le_entry,
+ 
+ static int prefix_buf(u8 prefix, u8 *buf, size_t buflen, u8 **cat)
+ {
+-	u8 *p;
++	u8 *p = NULL;
++	int ptr_same = *cat == buf;
+ 
+ 	p = realloc(*cat, buflen + 1);
+ 	if (!p)
+ 		return SC_ERROR_OUT_OF_MEMORY;
+ 
+-	if (*cat == buf) {
++	if (ptr_same) {
+ 		memmove(p + 1, p, buflen);
+ 	} else {
+ 		/* Flawfinder: ignore */
diff --git a/debian/patches/series b/debian/patches/series
index b5adf2fc..a583014f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-Use-sysconfdir-opensc-for-opensc.conf.patch
+gcc12.patch
-- 
2.37.2

Bug#993515: bullseye is not affected

[Timo Röhling]

Control: tags -1 + bookworm sid

As bullseye is not affected as it will never upgrade to glibc
2.34, I'm setting release tags to exclude this bug from stable
and allow the bug to be archived.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

On Friday, October 14, 2022 3:54:53 AM MST Roland Rosenfeld wrote:
> - Where should the bdic files be placed?
>   1) /usr/share/hunspell-bdic

I like this option because it would eliminate the need to wait to find out if 
Chromium can use the files before deciding where to put them.

On a separate note, I am in the process of filing upstream bug reports with 
Google as recommended by Qt.  Once I get those filed I will place links to them 
in the Qt bug reports.  I don’t think we need to wait for these bugs to be 
fixed before adding packages to Debian as they only affect three languages, but 
if the .bdic files are going to be generated automatically we need some 
mechanism to specify that they shouldn’t attempt to be generated for these 
three languages until the bugs are fixed.

Alternatively, we could patch the files so that the errors are avoided.  In the 
case Aragonese with tabs in the .aff, we could change them all to be spaces.  I 
can find no Hunspell file spec that says either tabs or spaces are required, 
and 
I am assuming that Hunspell itself doesn’t have problems with tabs because 
there are no nasty bugs filed against the current Aragonese Debian package, but 
it should also work fine with spaces as that is what all the other Hunspell 
packages appear to use.

The errors in the other two files could be fixed by removing one line from 
ar.aff 
and 31 lines from gl_ES.dic.  That makes them slightly less correct, but most 
people using the .bidc would probably not notice.  If we go this route we need 
to make sure we are only editing temporary files used to generate the .bdic as 
those using the standard Hunspell system should not end up with an inferior 
experience just to accommodate a custom binary format.

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

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

Bug#1021775: Last apt update: -0.0 day(s) ago

[Axel Beckert]

Hi,

Christoph Berg wrote:
> Re: Axel Beckert
> > I wonder if we should generally ignore negative values here (might
> > hide some "wrong time" issues, but then again they should reported by
> > another check) or just accept tiny negative values?
> 
> The check was introduced in 2013 by 8fca9ab199:
> 
> -} elsif ($last_update >= 1.5) {
> +} elsif ($last_update >= 1.5 or $last_update < 0) {
>  $updatecolor = 'yellow';

Ah, I remember. I think there was a false positive (maybe on a SBC
without RTC like a Raspberry Pi) when the time was totally wrong and
hence the last update was in the future, but it hadn't been updated
for quite a while because of that. (HTTPS as well as APT itself is
quite picky about having the proper time these days.)

> The value is coming directly from perl's -M operator, so I don't see
> how the code can/should be fixed

It's definition is:

  -M  Script start time minus file modification time, in days.

So if apt update started running and then e.g. ntpd or so sets the
time back a bit, this time can get negative.

> and we should probably just ignore the issue by using "or
> $last_update < -0.1".

Ack, let's check against < -0.1 for now.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1021652: nomad-driver-podman: missing golang-github-apparentlymart-go-textseg-dev in (Build-|)Depends

[Cyril Brulebois]

Cyril Brulebois  (2022-10-12):
> With the upcoming golang-github-zclconf-go-cty update, its
> golang-github-zclconf-go-cty-dev will stop covering the missing
> (Build-|)Depends, as it will shift from […]-go-textseg-dev to
> […]-go-textseg-v13-dev, making both nomad and nomad-driver-podman FTBFS.

Actually, we're sticking to the existing package, without introducing a
-v13 one (i.e. still using golang-github-apparentlymart-go-textseg-dev),
meaning the golang-github-zclconf-go-cty update doesn't change anything
for this package.

That being said, paths moved from /v12 to /v13, so you'd need to update
that part.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1021650: nomad: missing golang-github-apparentlymart-go-textseg-dev in (Build-|)Depends

[Cyril Brulebois]

Cyril Brulebois  (2022-10-12):
> nomad is shipping an embedded copy of hashicorp/hcl/v2, and doesn't
> list all packages it requires to build. For the time being, this is
> hidden by golang-github-zclconf-go-cty-dev, which in turn pulls the
> required golang-github-apparentlymart-go-textseg-dev package.
> 
> That being said, I'm working on updating golang-github-zclconf-go-cty,
> and golang-github-apparentlymart-go-textseg-v13-dev is likely to be
> used by this updated version, leading to nomad no longer finding
> go-textseg/v12/textseg.

Actually, we're sticking to the existing package, without introducing a
-v13 one (i.e. still using golang-github-apparentlymart-go-textseg-dev),
meaning the golang-github-zclconf-go-cty update doesn't change anything
for this package.

That being said, paths moved from /v12 to /v13, so you'd need to update
that part.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1020108: quilt: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Christoph Biedl]

Control: tags 1020108 patch

Martin Quinson wrote...

> Thanks for any help that could be provided.

Greetings from the Karlsruhe BSP.

As mentioned earlier, the build failure is a result of grep's new
warning messages. Digging closer I realized the current quote_bre()
function can no longer used that way: quilt uses the result both for
grep (now triggering the messages) and sed's search and replace (where
quoting the forward slash is crucial).

The patch attached replaces quote_bre() with two new functions
quote_bre_grep() and quote_bre_sed(), and adjusts all invocations
according to the respective need.

Test suite passes now.

Cheers,
Christoph
--- a/quilt/diff.in
+++ b/quilt/diff.in
@@ -260,7 +260,7 @@
 	# Add all files in the snapshot into the file list (they may all
 	# have changed).
 	files=( $(find $QUILT_PC/$snap_subdir -type f \
-		  | sed -e "s/^$(quote_bre $QUILT_PC/$snap_subdir/)//" \
+		  | sed -e "s/^$(quote_bre_sed $QUILT_PC/$snap_subdir/)//" \
 		  | sort) )
 	printf "%s\n" "${files[@]}" >&4
 	unset files
--- a/quilt/patches.in
+++ b/quilt/patches.in
@@ -71,7 +71,7 @@
 	# Quote each file name only once
 	for file in "${opt_files[@]}"
 	do
-		files_bre[${#files_bre[@]}]=$(quote_bre "$file")
+		files_bre[${#files_bre[@]}]=$(quote_bre_grep "$file")
 	done
 
 	# "Or" all files in a single pattern
--- a/quilt/scripts/patchfns.in
+++ b/quilt/scripts/patchfns.in
@@ -91,7 +91,15 @@
 }
 
 # Quote a string for use in a basic regular expression.
-quote_bre()
+# For use with grep.
+quote_bre_grep()
+{
+	echo "$1" | sed -e 's:\([][^$.*\\]\):\\\1:g'
+}
+
+# Quote a string for use in a basic regular expression.
+# For use with sed's search and replace.
+quote_bre_sed()
 {
 	echo "$1" | sed -e 's:\([][^$/.*\\]\):\\\1:g'
 }
@@ -227,7 +235,7 @@
 
 	if [ -e "$SERIES" ]
 	then
-		grep -q "^$(quote_bre $patch)\([ \t]\|$\)" "$SERIES"
+		grep -q "^$(quote_bre_grep $patch)\([ \t]\|$\)" "$SERIES"
 	else
 		return 1
 	fi
@@ -377,7 +385,7 @@
 {
 	local patch=$1
 	[ -e $DB ] || return 1
-	grep -q "^$(quote_bre $patch)\$" $DB
+	grep -q "^$(quote_bre_grep $patch)\$" $DB
 }
 
 applied_patches()
@@ -477,7 +485,7 @@
 	local tmpfile
 	if tmpfile=$(gen_tempfile)
 	then
-		grep -v "^$(quote_bre $patch)\$" $DB > $tmpfile
+		grep -v "^$(quote_bre_grep $patch)\$" $DB > $tmpfile
 		cat $tmpfile > $DB
 		rm -f $tmpfile
 		[ -s $DB ] || rm -f $DB
@@ -542,7 +550,7 @@
 		fi
 
 		local patch=${1#$SUBDIR_DOWN$QUILT_PATCHES/}
-		local bre=$(quote_bre "$patch")
+		local bre=$(quote_bre_sed "$patch")
 		set -- $(sed -e "/^$bre\(\|\.patch\|\.diff\?\)\(\|\.gz\|\.bz2\|\.xz\|\.lzma\|\.lz\)\([ "$'\t'"]\|$\)/!d" \
 			   -e 's/[ '$'\t''].*//' "$SERIES")
 		if [ $# -eq 1 ]
@@ -653,7 +661,7 @@
 	then
 		find "$path" -type f \
 			   -a ! -path "$(quote_glob "$path")/.timestamp" |
-		sed -e "s/$(quote_bre "$path")\///"
+		sed -e "s/$(quote_bre_sed "$path")\///"
 	fi
 }
 
--- a/quilt/upgrade.in
+++ b/quilt/upgrade.in
@@ -76,7 +76,7 @@
 
 for patch in $(applied_patches)
 do
-	proper_name="$(grep "^$(quote_bre $patch)"'\(\|\.patch\|\.diff?\)\(\|\.gz\|\.bz2\)\([ \t]\|$\)' $SERIES)"
+	proper_name="$(grep "^$(quote_bre_grep $patch)"'\(\|\.patch\|\.diff?\)\(\|\.gz\|\.bz2\)\([ \t]\|$\)' $SERIES)"
 	proper_name=${proper_name#$QUILT_PATCHES/}
 	proper_name=${proper_name%% *}
 	if [ -z "$proper_name" ]
@@ -86,7 +86,7 @@
 	fi
 
 	if [ "$patch" != "$proper_name" -a -d $QUILT_PC/$patch ] \
-	   && grep -q "^$(quote_bre $patch)\$" \
+	   && grep -q "^$(quote_bre_grep $patch)\$" \
 		   $QUILT_PC/applied-patches
 	then
 		mv $QUILT_PC/$patch $QUILT_PC/$proper_name \

Bug#1021784: dcfldd: SHA1 hash is wrong over s390x architecture

[Joao Eriberto Mota Filho]

Package: dcfldd
Version: 1.7-3
Severity: important
Tags: upstream

Control: forwarded -1 
https://github.com/resurrecting-open-source-projects/dcfldd/issues/11

The following command fails on s390x:

dcfldd if=test.txt hash=md5,sha1,sha256,sha384,sha512 2>&1 | grep -C 20 
bc0e4b74695142e0a0bdae87aea310d7078866cb

I attached the file test.txt to this bug. The grep shown above will test the
SHA1 result. The other hashes are right. See below the result of the test over
amd64 WITHOUT the grep:

Total (md5): 92994b0ce292a217e3e3bc31b639e565

Total (sha1): bc0e4b74695142e0a0bdae87aea310d7078866cb

Total (sha256): 02fd428a4671925e4ca61541b9fac648f4ccdccad65602bfd3256ba14e59489c

Total (sha384): 
53b8374607a8258de4173265bfbfa6120093fd42090a92fd589cf2c6c16b4e421b513514976713f7949715720a83

Total (sha512): 
969a39bf47b5f12d81121084f19cb5ae250e0c0ea5b7c6d82cf08131acde8e1955d137612c2f6b255e25b0e28f96f93586f90f06965cb8f719ed7fbdd95cc8d4

Now, over s390x:

Total (md5): 92994b0ce292a217e3e3bc31b639e565

Total (sha1): 68afccc873eb954866097c08d4ad9d9643735f2c

Total (sha256): 02fd428a4671925e4ca61541b9fac648f4ccdccad65602bfd3256ba14e59489c

Total (sha384): 
53b8374607a8258de4173265bfbfa6120093fd42090a92fd589cf2c6c16b4e421b513514976713f7949715720a83

Total (sha512): 
969a39bf47b5f12d81121084f19cb5ae250e0c0ea5b7c6d82cf08131acde8e1955d137612c2f6b255e25b0e28f96f93586f90f06965cb8f719ed7fbdd95cc8d4

Only SHA1 differ between both architectures. Executing the sha1sum command over
the file on s390x will produce the right hash:

(sid_s390x-dchroot)eriberto@zelenka:~$ sha1sum 
dcfldd-1.7.1/debian/tests/test.txt
bc0e4b74695142e0a0bdae87aea310d7078866cb  dcfldd-1.7.1/debian/tests/test.txt

Eriberto


test.txt.gz
Description: application/gzip

Bug#1021771: apache2: Accessing to type-map without .var suffix results 500 and apache2 exits

[Shintaro Sakahara]

OK, here is the detailed version of steps to reproduce:

1. Install apache2, apache2-suexec-pristine and libapache2-mpm-itk packages.
2. Disable mpm_event and enable cgid, mpm_prefork and suexec modules.
3. Configure two sites on Apache2.
3-1. For the first one, enable SuexecUserGroup. (000-default in the example)
3-2. For the second one, enable AssignUserID. (001-userid in the example)
4. Enable type-map and CGI on the first site.
5. Place a type-map file whose filename ends with .cgi.var on the first
site. (board.cgi.var in the example)
6. In the type-map file, specify valid URIs to CGI scripts. Also specify
"Content-Type: application/x-httpd-cgi"
7. Using web browser, access to the path to the type-map file on the
first site, without putting .var suffix.
8. You'll see 500 Internal Server Error. Also, apache2 is terminated in
few seconds.

The problems you can confirm in the above steps are two:
 - The server responds 500 instead of running CGI correctly.
   When you access to the path to the type-map file *with* .var suffix,
   CGI is executed correctly.
 - The apache2 process is terminated.
   This has to be more severe than just returning 500.
   This problem doesn't occur if the second site doesn't exist.

In error.log, you'll see errors like below:
[Thu Sep 29 18:32:42.176871 2022] [cgid:error] [pid 209665] (104)Connection 
reset by peer: AH01248: Error reading request on cgid socket
[Thu Sep 29 18:32:42.177025 2022] [cgid:error] [pid 209704] [client 
xxx.xxx.xxx.xxx:53380] End of script output before headers: board.cgi
[Thu Sep 29 18:32:43.161802 2022] [cgid:error] [pid 209664] AH01239: cgid 
daemon process died, restarting
[Thu Sep 29 18:32:44.170387 2022] [mpm_prefork:emerg] [pid 209706] (22)Invalid 
argument: AH00144: couldn't grab the accept mutex
[Thu Sep 29 18:32:45.170296 2022] [core:alert] [pid 209664] AH00050: Child 
209706 returned a Fatal error... Apache is exiting!

Bug#1021783: postgresql: No prompt or instructions on how to upgrade cluster to 15

[Diederik de Haas]

Package: postgresql
Version: 15+244
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On previous upgrades to postgresql to a new major versions, you'd always
get a prompt and instructions how to upgrade the database cluster to the
new postgresql version. I did not get that with the upgrade to 15 though.

Relevant part of aptitude log:

# aptitude safe-upgrade
...
Preparing to unpack .../027-postgresql-common_244_all.deb ...
Leaving 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by 
postgresql-common'
Unpacking postgresql-common (244) over (243) ...
Preparing to unpack .../028-postgresql-client-common_244_all.deb ...
Unpacking postgresql-client-common (244) over (243) ...
...
Selecting previously unselected package postgresql-client-15.
Preparing to unpack .../105-postgresql-client-15_15.0-1_amd64.deb ...
Unpacking postgresql-client-15 (15.0-1) ...
Selecting previously unselected package postgresql-15.
Preparing to unpack .../106-postgresql-15_15.0-1_amd64.deb ...
Unpacking postgresql-15 (15.0-1) ...
Preparing to unpack .../107-postgresql_15+244_all.deb ...
Unpacking postgresql (15+244) over (14+243) ...
...
Setting up postgresql-client-common (244) ...
...
Setting up postgresql-client-15 (15.0-1) ...
update-alternatives: using /usr/share/postgresql/15/man/man1/psql.1.gz to 
provide /usr/share/man/man1/psql.1.gz (psql.1.gz) in auto mode
...
Setting up postgresql-common (244) ...
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before -
grep: warning: stray \ before /
...
Setting up postgresql-15 (15.0-1) ...
Creating new PostgreSQL cluster 15/main ...
/usr/lib/postgresql/15/bin/initdb -D /var/lib/postgresql/15/main --auth-local 
peer --auth-host scram-sha-256 --no-instructions
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with this locale configuration:
  provider:libc
  LC_COLLATE:  en_US.UTF-8
  LC_CTYPE:en_US.UTF-8
  LC_MESSAGES: en_US.UTF-8
  LC_MONETARY: en_US.UTF-8
  LC_NUMERIC:  en_US.UTF-8
  LC_TIME: nl_NL.UTF-8
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/15/main ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Europe/Amsterdam
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
update-alternatives: using /usr/share/postgresql/15/man/man1/postmaster.1.gz to 
provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode
...
Setting up postgresql (15+244) ...
...


Are the (cluster) upgrade instructions no longer needed? Is it done
automatically and thus no manual action is needed? Are users expected to
know what to do and how to do it? Anything else?

# pg_lsclusters
Ver Cluster Port Status OwnerData directory  Log file
14  main5432 online postgres /var/lib/postgresql/14/main 
/var/log/postgresql/postgresql-14-main.log
15  main5433 online postgres /var/lib/postgresql/15/main 
/var/log/postgresql/postgresql-15-main.log


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

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

Versions of packages postgresql depends on:
ii  postgresql-15  15.0-1

postgresql recommends no packages.

Versions of packages postgresql suggests:
pn  postgresql-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY0mQqQAKCRDXblvOeH7b
bn0iAP9WaPTzPKaTCZn8HDatsPz/DP8hC+DY2+hhWWdY8ls9owD/QiEt4MFZPQb5
hjcE8JnI09aX/M2jPCYI629k/Yy/gQk=
=RuQa
-END PGP SIGNATURE-

Bug#1021745: Fwd: [Pkg-shadow-devel] Bug#1021745: passwd: /etc/passwd was edited with the wrong shell path

[Najib Bakari]

-- Forwarded message -
De: Serge E. Hallyn 
Date: vie, 14 oct 2022 a las 17:56
Subject: Re: [Pkg-shadow-devel] Bug#1021745: passwd: /etc/passwd was edited
with the wrong shell path
To: Najib Bakari 
Cc: Serge E. Hallyn 


On Fri, Oct 14, 2022 at 05:34:09PM +0200, Najib Bakari wrote:
> Dear Serge Hallyn,
> My point was only about the /etc/passwd being edited, even with the check
> and warning.
>
> *> Well no, it clearly checked, and warned you.  You chose to
> ignore the warning.  *
>
> When the warning pops up, it is already too late. Check this please:
>
> #chsh
> Changing the login shell for root
> Enter the new value, or press ENTER for the default
> Login Shell [/bin/zsh]: zsh
> chsh: Warning: zsh does not exist
>
> # chsh
> Password:
> chsh: PAM: Authentication failure
>
> Best regards
>
> Najib

Right, you'd have to reset it after seeing the warning.

This isn't something that has recently changed, it's been like this
for 25 years.

I'm open to a patch that will accept a new /etc/login.defs variable to
affect this - it could, if set, simply refuse on unknown shell, or
ask "are sure".  However, github.com/shadow-maint/shadow woudl be the
place for this.  The debian package would simply make a change to
the debian/login.defs (if it wants) to set the default.  Feel free to
create an issue or, better, submit a PR there :)

thanks,
-serge


-- 
Liebe Güße

Najib El Bakari Zagour

Bug#1021775: Last apt update: -0.0 day(s) ago

[Christoph Berg]

Re: Axel Beckert
> I wonder if we should generally ignore negative values here (might
> hide some "wrong time" issues, but then again they should reported by
> another check) or just accept tiny negative values?

The check was introduced in 2013 by 8fca9ab199:

-} elsif ($last_update >= 1.5) {
+} elsif ($last_update >= 1.5 or $last_update < 0) {
 $updatecolor = 'yellow';

The value is coming directly from perl's -M operator, so I don't see
how the code can/should be fixed and we should probably just ignore
the issue by using "or $last_update < -0.1".

Christoph

Bug#1021576: can't have both LIME and LIME X3DH enabled at the same time

[Dennis Filder]

Control: close -1
X-Debbugs-Cc: ael 

On Thu, Oct 13, 2022 at 07:35:25PM +0100, ael wrote:

> It does seem to leave some error handling attention if it dumps core
> on a simple configuration error. I guess that is for upstream.

It's not actually a coredump, but a fatal error message that is
implemented awkwardly.  There currently does not seem to be any way to
gracefully loop through such error messages from liblinphone to
linphone-desktop.  I'll try to bring it up with the developers, and
also the dearth of documentation.

> PS. I assume you will close the bug report, or should I do so?

I'll close it.

Regards.

Bug#1021782: ITP: r-cran-rcppspdlog -- R package for spdlog C++ logging

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-rcppspdlog
  Version : 0.0.8
  Upstream Author : Dirk Eddelbuettel
* URL or Web page : https://eddelbuettel.github.io/rcppspdlog/
* License : GPL (>= 2)
  Description : R package for spdlog C++ logging

This package may soon be needed by the r-cran-tiledb (src: tile-r) package.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1021446: schroot: [INTL:nl] Dutch translation of debconf messages

[Christoph Biedl]

Control: tags 1021446 pending

Frans Spiesschaert wrote...

> Please add it to your next package revision.

Thanks, now queued up.

Christoph


signature.asc
Description: PGP signature

Bug#1021780: schroot: example of file chroot missing type=file

[Christoph Biedl]

Control: tags 1021780 confirmed

Emanuele Rocca wrote...

> The example does not work as is, it needs "type=file" too.

Oops. It seems this has been around since its introduction back
in 2006 without being noticed.

Christoph


signature.asc
Description: PGP signature

Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> And just for the record: This only happens on some of my hosts. I have
> several hosts (also with a lot of elpa plugins, but probably still not
> as many as on the host where it happens reproducibly) where the
> upgrade from 27.x to 28.x worked fine on the first run.
> 
> It seems that those hosts with this issue are desktops or laptops with
> emacs-gtk installed while others are VMs or Raspberry Pi based servers
> where I only install emacs-lucid or emacs-nox and also no unnecessary
> desktop bloat like dbus, etc.

One counter argument: I have one Thinkpad which has emacs-gtk, dbus
and systemd and there it doesn't happen either.

So maybe that desktop criteria was a red herring.

If I find time, I'll try to figure out if there are elpa package which
are solely installed on those boxes where it happens. Maybe we find
the culprit that way.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1014936: weasyprint: manpage for weasyprint(1) is too much

[Daniel Kahn Gillmor]

Control: forwarded 1014936 https://github.com/Kozea/WeasyPrint/issues/1741

On Wed 2022-10-12 16:57:29 -0400, Scott Kitterman wrote:
> On Thu, 14 Jul 2022 16:19:58 -0400 Daniel Kahn Gillmor 
>   wrote:
>> Hi there!  I'm glad that there's a weasyprint(1) manpage, but the
>> contents of the manual page contain way too much info.
>> 
>> The manpage in section 1 should make it clear how to use the command
>> line utility.
>
> If you have suggestions on how to improve the situation without requiring 
> manual editing every release, I would love to hear them.

Hm, i think you're saying that this is primarily an upstream problem,
which seems plausible.  I've reported it upstream, maybe they'll have a
suggestion.

Thanks for looking into it!  I agree that we want to keep the manpage
up-to-date with upstream documentation.

--dkg


signature.asc
Description: PGP signature

Bug#996539: ITP: sqlitecpp -- a smart and easy to use C++ SQLite3 wrapper

[Bastian Germann]

Control: owner -1 b...@debian.org

There has been no progress for a year.
I have pushed the package to https://salsa.debian.org/debian/sqlitecpp and will 
upload it today.

Bug#1021778: libreoffice-draw: The desktop file for LibreOffice-Draw contains the category 'Graphics' twice.

[Rene Engelhard]

severity 1021778 minor

thanks


Hi.

Am 14.10.22 um 15:30 schrieb Joerg Schiermeier, Bielefeld/Germany:

can't be ;-)


Severity: normal


No, minor.


The desktop file for Linux 
(/usr/share/applications/libreoffice-draw.desktop) inside the Debian 
package 'libreoffice-draw.deb' contains the category 'Graphics twice. 
See here:

--
Categories=Office;Graphics;FlowChart;Graphics;2DGraphics;VectorGraphics;
---///---


Which seems to be due to

    sed -i -e 's/Office;/Office;Graphics;/' 
$(PKGDIR)-draw/usr/share/applications/libreoffice-draw.desktop


in debian/rules which presumably was added when Graphics; wasn't there 
yet...



Regards,


Rene

Bug#1021781: apt: Fix error handling with getline

[Walter Lozano]

Package: apt
Version: 2.4.8
Severity: important

Dear Maintainer,

While working building images using debos[1] with Apertis [2] I noticed strange
behaviors with apt. After debugging the issue, I found what I understand is a
bug and submitted a MR to try to fix it.

https://salsa.debian.org/apt-team/apt/-/merge_requests/265/

As as summary I consider that in some cases the error handling after calling
getline is not correct since it only takes into account errno but not the
return value.

Thanks is advance,

Walter

[1] https://github.com/go-debos/debos
[2] https://www.apertis.org/


-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- /etc/apt/sources.list --

# deb cdrom:[Ubuntu 19.10 _Eoan Ermine_ - Release amd64 (20191017)]/ eoan main 
restricted

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://ar.archive.ubuntu.com/ubuntu/ jammy main restricted
deb-src http://ar.archive.ubuntu.com/ubuntu/ jammy main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://ar.archive.ubuntu.com/ubuntu/ jammy-updates main restricted
# deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://ar.archive.ubuntu.com/ubuntu/ jammy universe
# deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan universe
deb http://ar.archive.ubuntu.com/ubuntu/ jammy-updates universe
# deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu 
## team, and may not be under a free licence. Please satisfy yourself as to 
## your rights to use the software. Also, please note that software in 
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://ar.archive.ubuntu.com/ubuntu/ jammy multiverse
# deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan multiverse
deb http://ar.archive.ubuntu.com/ubuntu/ jammy-updates multiverse
# deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://ar.archive.ubuntu.com/ubuntu/ jammy-backports main restricted 
universe multiverse
# deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan-backports main restricted 
universe multiverse


deb http://security.ubuntu.com/ubuntu jammy-security main restricted
# deb-src http://security.ubuntu.com/ubuntu eoan-security main restricted
deb http://security.ubuntu.com/ubuntu jammy-security universe
# deb-src http://security.ubuntu.com/ubuntu eoan-security universe
deb http://security.ubuntu.com/ubuntu jammy-security multiverse
# deb-src http://security.ubuntu.com/ubuntu eoan-security multiverse

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.

-- (/etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list present, but 
not submitted) --


-- /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list.distUpgrade --

deb 
http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_20.04/
 /

-- (/etc/apt/sources.list.d/google-chrome.list present, but not submitted) --


-- /etc/apt/sources.list.d/google-chrome.list.distUpgrade --

### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main 

-- (/etc/apt/sources.list.d/google-chrome.list.save present, but not submitted) 
--


-- /etc/apt/sources.list.d/katharaframework-ubuntu-kathara-eoan.list --

# deb http://ppa.launchpad.net/katharaframework/kathara/ubuntu focal main # 
disabled on upgrade to focal
# deb-src http://ppa.launchpad.net/katharaframework/kathara/ubuntu eoan main

-- 
(/etc/apt/sources.list.d/katharaframework-ubuntu-kathara-eoan.list.distUpgrade 
present, but not submitted) --


-- /etc/apt/sources.list.d/oem-somerville-three-eyed-raven-meta.list --

deb http://dell.archive.canonical.com/ jammy somerville
# deb-src http://dell.archive.canonical.com/ focal somerville
deb http://dell.archive.canonical.com/ jammy somerville-three-eyed-raven
# deb-src http://dell.archive.canonical.com/ focal somerville-three-eyed-raven

-- 

Bug#1021766: Doesn't call program after timeout

[Thorsten Glaser]

tags 1021766 unreproducible
thanks

Hi madduck,

>Wanting to replace xscreensaver with something better, I took a look
>at xidle. Unfortunately, the simple call
>
>```
>xidle -program /usr/bin/xsecurelock -timeout 5
>```
>
>doesn't cause `xsecurelock` to be spawned after 5 seconds. According

I cannot reproduce this. I just started an xterm and ran:

$ pkill xidle   # because I use this with the -ne corner already
$ xidle -program '/usr/bin/xlock -mode ant' -timeout 5

Then I sat there for a couple of seconds not doing anything, and
xlock (from the xlockmore-gl package in oldold…oldstable) spawned.
Exiting that I ^C’d xidle.

I run X.org with evilwm, although I do use the “exec startx” method
to run X, not a login manager, and that with xserver-xorg-legacy.
Maybe that makes a difference?

I’ll run and look at strace later but…

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#1021780: schroot: example of file chroot missing type=file

[Emanuele Rocca]

Package: schroot
Version: 1.6.13-3
Severity: minor

Hi,

the config file /etc/schroot/schroot.conf ships the following
example of file-based chroot:

#[lenny-file]
#description=Debian lenny (oldstable)
#file=/srv/chroot/lenny.tar.gz
#location=/lenny
#groups=sbuild

The example does not work as is, it needs "type=file" too.

Bug#1021775: Last apt update: -0.0 day(s) ago

[Axel Beckert]

Control: tag -1 + confirmed

Hi Christoph,

Christoph Berg wrote:
> Apparently when apt update and the check are running at the same time,
> the following can happen:
[…]
> yellow Last apt update: -0.0 day(s) ago

Confirmed. I've seen this, too. I suspect that this actually a tiny
negative value (unclear why) which gets rounded to zero.

I wonder if we should generally ignore negative values here (might
hide some "wrong time" issues, but then again they should reported by
another check) or just accept tiny negative values?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1016014: adduser: Broken symlinks in /usr/*/man8 folders. Affects piuparts

[Andreas Beckmann]

Followup-For: Bug #1016014

The translated manpages are no longer installed since
85021c6ae7026f99f3a07d63df2646a88c6cc476, but debian/links still creates
the symlinks to them. You only need to keep the first three lines there.


Andreas

Bug#1021778: libreoffice-draw: The desktop file for LibreOffice-Draw contains the category 'Graphics' twice.

[Joerg Schiermeier, Bielefeld/Germany]

Package: libreoffice-draw
Version: 1:7.4.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Hello!

The desktop file for Linux (/usr/share/applications/libreoffice-draw.desktop) 
inside the Debian package 'libreoffice-draw.deb' contains the category 
'Graphics twice. See here:
- --
Categories=Office;Graphics;FlowChart;Graphics;2DGraphics;VectorGraphics;
- ---///---

One of this category names should be removed in a next version of 
LibreOffice-Draw's package. Please see the documentation about desktop files 
here:


You may what to check also, if the desktop file is valid with the command 
'desktop-file-validate' from the Debian package 'desktop-file-utils'.

- -- 
Yours sincerely
Joerg Schiermeier




- -- Package-specific info:
Configuration filePackage Exists Changed
/etc/libreoffice/registry/draw.xcdlibreoffice-drawYes No
/etc/libreoffice/registry/graphicfilter.xcd   libreoffice-drawYes No

- -- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages libreoffice-draw depends on:
ii  libavahi-client3 0.8-6
ii  libavahi-common3 0.8-6
ii  libc62.35-3
ii  libcdr-0.1-1 0.1.6-2+b1
ii  libdbus-1-3  1.14.4-1devuan1
ii  libfreehand-0.1-10.1.2-3
ii  libgcc-s112.2.0-5
ii  libglib2.0-0 2.74.0-3
ii  libmspub-0.1-1   0.1.4-3+b2
ii  libmwaw-0.3-30.3.21-1
ii  libodfgen-0.1-1  0.1.8-2
ii  libpagemaker-0.0-0   0.0.4-1
ii  libqxp-0.0-0 0.0.2-1+b2
ii  libreoffice-common   1:7.4.2-1
ii  libreoffice-core 1:7.4.2-1
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.7-1
ii  libstdc++6   12.2.0-5
ii  libuno-cppu3 1:7.4.2-1
ii  libuno-cppuhelpergcc3-3  1:7.4.2-1
ii  libuno-sal3  1:7.4.2-1
ii  libuno-salhelpergcc3-3   1:7.4.2-1
ii  libvisio-0.1-1   0.1.7-1+b2
ii  libwpg-0.3-3 0.3.3-1
ii  libxml2  2.9.14+dfsg-1+b1
ii  libzmf-0.0-0 0.0.2-1+b4
ii  ucf  3.0043
ii  uno-libs-private 1:7.4.2-1

libreoffice-draw recommends no packages.

libreoffice-draw suggests no packages.

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.5
ii  fonts-opensymbol2:102.12+LibO7.4.2-1
ii  libabsl20220623 0~20220623.0-2
ii  libboost-locale1.74.0   1.74.0-17
ii  libc6   2.35-3
ii  libcairo2   1.16.0-6
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1.1
ii  libclucene-core1v5  2.3.3.4+dfsg-1.1
ii  libcups22.4.2-1+b1
ii  libcurl3-gnutls 7.85.0-1
ii  libdbus-1-3 1.14.4-1devuan1
ii  libdconf1   0.40.0-3
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.10-1
ii  libexpat1   2.4.9-1
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-4.5
ii  libfreetype62.12.1+dfsg-3
ii  libgcc-s1   12.2.0-5
ii  libglib2.0-02.74.0-3
ii  libgpgmepp6 1.18.0-1
ii  libgraphite2-3  1.3.14-1
ii  libgstreamer-plugins-base1.0-0  1.20.3-2
ii  libgstreamer1.0-0   1.20.3-1
ii  libharfbuzz-icu05.2.0-2
ii  libharfbuzz0b   5.2.0-2
ii  libhunspell-1.7-0   1.7.1-1
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.10-1
ii  libicu7171.1-3
ii  libjpeg62-turbo 1:2.1.2-1+b1
ii  liblcms2-2  2.13.1-1+b1
ii  libldap-2.5-0   2.5.13+dfsg-2
ii  libmythes-1.2-0 2:1.2.5-1
ii  libnspr42:4.35-1
ii  libnss3 2:3.83-1
ii  libnumbertext-1.0-0 1.0.10-1
ii  libopenjp2-72.5.0-1
ii  liborcus-0.17-0 0.17.2-2+b1
ii  liborcus-parser-0.17-0  0.17.2-2+b1
ii  libpng16-16 1.6.38-2
ii  libpoppler123   22.08.0-2.1
ii  libraptor2-02.0.15-4
ii  librdf0 1.0.17-1.2
ii  libreoffice-common  1:7.4.2-1
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  12.2.0-5
ii  

Bug#1021777: bullseye-pu: package libdatetime-timezone-perl/1:2.47-1+2022e

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-p...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.47-1+2022e to bullseye,
with the changes from the Olson DB 2022e as a quilt patch.

Changes (from tzdata upstream):

Jordan and Syria are abandoning the DST regime and are changing to
permanent +03, so they will not fall back from +03 to +02 on
2022-10-28.

Manually stripped down debdiff attached.


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmNJZYdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbaeg/+PKRORnH6t1JUDsGS8vhhRPvqaQdJ8igUXLRNs1NE/1yX8S/E3oVTBO5t
hyFvTgBcTmCpHoxRaBpH+7xrqQqa2k+OpZ3R0sEhQmB3l48wvC8hQyTqip/QIwlb
FnSWDos/drJ9HMA6z35S7fY7hiQU9PTYyIoG42YKylS46tl0ph8GXu7NtkY6MCtI
ryBXbUeVLEbae4Hn2GjG2qHSf5/heFNu423VNhoYxjbemD9PHcUI/s7ODx83Pw1h
nTDszMSjRCw/t272pE3X8q3OQplYQOQMx80m35L+X1/pQbxrj+GsjF/kTvKAyK0G
+GDVZIja2UUvIOcwR2yQQjCNlZi138VFdAt9UMJIrGL6TBke65IRDvWyiPaPXkT7
k+FaKjjnB/x/5b60fUoP7RCs8/gbZPGDDStD62wVhU7l2YLLgYrrn2JwycOmonKW
BvD5AurfclQ/Sugzv0ICgwBauZlPeGy1/WCULzKjVX65zWXmMj6hg3l+DOWaaXYy
zu+vKkKUlsPI8K5eBk13jBWhL1weVzY+RTMuArSSKUkpBHY0kD+Yvrfry4Q1sCqm
UpZwv/yADDLvrIG/ePfmE4ENrDuK6THIfNW7/PkJieD5xTCEl6vm/bt60/fPgo77
JzZ2RIZJxaZD87JaUMfd7UDLlH2grMFZH1awW4gTqELyfZWnFRk=
=xf9h
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.47/debian/changelog 
libdatetime-timezone-perl-2.47/debian/changelog
--- libdatetime-timezone-perl-2.47/debian/changelog 2022-09-27 
17:14:16.0 +0200
+++ libdatetime-timezone-perl-2.47/debian/changelog 2022-10-14 
15:26:55.0 +0200
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.47-1+2022e) bullseye; urgency=medium
+
+  * Update to Olson database version 2022e.
+This update includes contemporary changes for Jordan and Syria.
+
+ -- gregor herrmann   Fri, 14 Oct 2022 15:26:55 +0200
+
 libdatetime-timezone-perl (1:2.47-1+2022d) bullseye; urgency=medium
 
   * Update to Olson database version 2022d.
diff -Nru libdatetime-timezone-perl-2.47/debian/patches/olson-2022e 
libdatetime-timezone-perl-2.47/debian/patches/olson-2022e
--- libdatetime-timezone-perl-2.47/debian/patches/olson-2022e   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/patches/olson-2022e   2022-10-14 
15:26:55.0 +0200
@@ -0,0 +1,7209 @@
+Description: Update to Olson DB 2022e
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2022-10-14
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2022d
++# Generated from debian/tzdata/africa.  Olson data version 2022e
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2022d'}
++sub olson_version {'2022e'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Asia/Damascus.pm
 b/lib/DateTime/TimeZone/Asia/Damascus.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/asia.  Olson data version 2022d
++# Generated from debian/tzdata/asia.  Olson data version 2022e
+ #
+ # Do not edit this file directly.
+ #
+@@ -1114,207 +1114,18 @@
+ ],
+ [
+ 63802587600, #utc_start 2022-10-27 21:00:00 (Thu)
+-63815896800, #  utc_end 2023-03-30 22:00:00 (Thu)
+-63802594800, #  local_start 2022-10-27 23:00:00 (Thu)
+-63815904000, #local_end 2023-03-31 00:00:00 (Fri)
+-7200,
+-0,
+-'EET',
+-],
+-[
+-63815896800, #utc_start 2023-03-30 22:00:00 (Thu)
+-63834037200, #  utc_end 2023-10-26 21:00:00 (Thu)
+-63815907600, #  local_start 2023-03-31 01:00:00 (Fri)
+-63834048000, #local_end 2023-10-27 00:00:00 (Fri)
+-10800,
+-1,
+-'EEST',
+-],
+-[
+-63834037200, #utc_start 2023-10-26 21:00:00 (Thu)
+-63847346400, #  utc_end 2024-03-28 22:00:00 (Thu)
+-63834044400, #  local_start 2023-10-26 23:00:00 (Thu)
+-63847353600, #local_end 2024-03-29 00:00:00 (Fri)
+-7200,
+-0,
+-'EET',
+-],
+-[
+-63847346400, #utc_start 2024-03-28 22:00:00 (Thu)
+-63865486800, #  utc_end 2024-10-24 21:00:00 (Thu)
+-63847357200, #  local_start 2024-03-29 01:00:00 (Fri)
+-63865497600, #local_end 2024-10-25 00:00:00 (Fri)
+-10800,
+-1,
+-'EEST',
+-],
+-[
+-63865486800, #utc_start 2024-10-24 21:00:00 (Thu)
+-63878796000, #  utc_end 2025-03-27 22:00:00 (Thu)
+-63865494000, #  local_start 2024-10-24 23:00:00 (Thu)
+-63878803200, #local_end 2025-03-28 00:00:00 (Fri)
+-7200,
+-0,
+-'EET',
+-],
+-[
+-63878796000, #utc_start 2025-03-27 22:00:00 (Thu)
+-63897541200, #  utc_end 2025-10-30 

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

[Marco d'Itri]

On Oct 14, Vincent Lefevre  wrote:

> > This is obviously convenient on Guillem's part, but we have to optimize 
> > systems by default for the general case and not just for dpkg -i.
> This dpkg FAQ says that this is not beneficial for just dpkg,
> but also "for any application in the system".
[citation needed]

I hope that you understand why at this point I cannot trust as is the 
opinions of the dpkg maintainer.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1021771: apache2: Accessing to type-map without .var suffix results 500 and apache2 exits

[Ondřej Surý]

> On 14. 10. 2022, at 13:13, Shintaro Sakahara  wrote:
> 
> I created a small example using Docker and put on GitHub so that everyone 
> could
> easily reproduce this problem.

Hi,

could you please actually describe the problem into the bugreport?  While having
a reproducer is certainly nice, it's not enough to see what might be the 
problem.
And you can't expect other people do debug the Docker containers.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

Bug#1020489: mgr modules fail to run due to "PY_SSIZE_T_CLEAN macro must be defined for '#' formats"

[Jakob Haufe]

I did a build using the patch from [1] which solved the issue for me.

The modified source and a bookworm/amd64 build can be found using:

-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-
Types: deb
URIs: https://debian.sur5r.net/ceph
Suites: bookworm
Components: main
Signed-By:
 -BEGIN PGP PUBLIC KEY BLOCK-
 .
 mQINBFTD+AwBEAC3o2dFihzkm1diGcq8IElOzBUWTTrfm4ISPmjFDYufSuXBswaZ
 JCHcyDeLvnwxbP/emv3kEx6Z1sluXI3yUwaa6uNpazzyHZLcBjPjuWtZOVXhAIfl
 yJMrKMyLufDgWKkV6h2qKxB+wpj22tacfEsqFrHTWeCM4lYL35gPvbchYjHjylmZ
 QJJuZtwrN7Fv97/Gjxlko+WvbBgIf6vsin7fsgezGD/6aTS3cvlXSdp5vx1KZdBR
 W1TgkD8ykH5K6xK+UBD6Nol70Y7ZrD9uYUNSO/Xa00ieHF3MnBp7wx5+C+o4OD1H
 jT19EFXoiyWTWCG3SSaUTyifhO+caRliRLduFRyJ7sMHkdq2nckokEx71xl69+AY
 MExNM0NEU0CBPRIg18ZjlPeRM2oIjcIxcPRxbrtYVi+yl19kNxMARh5Cp7R5SPfU
 Vcs0JalG4vSaht6EpATsA9RCCsltZFLnPJ6AADHcnDJvJwGEqo4ykFDwdA5/ghwc
 Mb3CQj8j6Z9dooGUqTKMonk8HkAZeCliaiN34Xo4U1+zDdL8ZT+hTFIh66VN0ITR
 Pa/wQFxT7YBPXwfY7TOkPnS06U+fhQw7FGlaIbO0ICjUYMQj9Qr1TeW04IXr+ZE4
 aPgrYzVV0/JHw0K5B7u0/0r2vXY59mMBQJHjGX3aedippRwaApqPxv6VuQARAQAB
 tE5kZWJpYW4uc3VyNXIubmV0IEFyY2hpdmUgQXV0b21hdGljIFNpZ25pbmcgS2V5
 IDIwMTUgKHN1cjVyKSA8ZGViaWFuQHN1cjVyLm5ldD6JAlQEEwEKAD4CGwMFCwkI
 BwMFFQoJCAsFFgIDAQACHgECF4AWIQS/2Q9Nqu+nK2e7r0jjyhqJlBxC5gUCYg5i
 wAUJD1nCtAAKCRDjyhqJlBxC5ng0D/94od9l2apVLr1LIB7/PrNNE16XDhhtD5oz
 G3dZU3BPi5ro2LRFOqG9tq6uzW5TobDpfj/P8JD8/vWZ0gRWsmYZoVPcdbnAXFMm
 dCHAsRIxpipQXaVa+zLBmIk6DbNaNNxeaBKwvUEeBTxYWUfb0t70FbpADvYhgOza
 J1Bvk8I4t6EvvOwllOiaktjR4CnTOQ2eHf32VAe1xxFRTMGN6lOH/G76/DICLOxR
 8252mD2S3opphp/7hxZIOzemwgN3ph2q0YTl4x7fQ7uiCpuTj4GKkUNbebIgt+BO
 38pZKcMLYzviUYqa6EVjtfwio/Ow/7fBXWLBSiqhr1twMzZhi2JQO3q3WnhEsZEj
 NJrmt+eCOzHYzQDtf9ruQ+L97SaJ1bWY6nw6SbPezyYot4PwNHrZQAM3XaDoBt1i
 S168cXV7CqtW/iMA0HsXnbmCmeTUf0uOYjpGRFtf8p5HGL/laO5DKlB+j4CYBm1a
 W95rBX6zAuHdJGcHD/xejhThaTvnlnbBlm7d0BN2LuLt7zKn4GT9+BQBo0F2FoeO
 ZgBQUjX5YHvouWQoldEsXIhbOY2+GnY5idZyyiDFPDF0yCyjMpjHfs8yJIc8c6XQ
 HmK6tIW8dps2naJymvs8ynAeJV1hDG0xALNIyRggH8EQDqcFWKl5djQJavzl3RzS
 v4DMtVZIUg==
 =lUpr
 -END PGP PUBLIC KEY BLOCK-
 
-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-✂-

Cheers,
sur5r

[1] https://github.com/ceph/ceph/pull/44112


-- 
ceterum censeo microsoftem esse delendam.


pgpt0INfpZMre.pgp
Description: OpenPGP digital signature

Bug#1021776: autopkgtest: warn about missing packages in autopkgtest-build-qemu

[Emanuele Rocca]

Package: autopkgtest
Version: 5.26
Severity: minor

The program autopkgtest-build-qemu needs a few packages to be installed in
order to work properly. However, such packages are not listed as dependencies
of autopkgtest given that they are qemu-specific, and qemu is only one of the
backends supported by autopkgtest. Some (but not all) of the needed packages
are listed as Suggests. For vmdb2, autopkgtest-build-qemu detects its absence
and warns about the fact:

 vmdb2 not found. This script requires vmdb2 to be installed

Another required package is zerofree, which is not currently listed in Suggests
though it should be. See https://bugs.debian.org/1021341. Similarly to what it
does for vmdb2, the script should warn if zerofree is missing too.

Depending on the arguments passed to autopkgtest-build-qemu, the combination of
required packages may change. For example, when building an arm64 image on a
amd64 host with --architecture=arm64, the following packages are needed too:

- qemu-user-static
- binfmt-support
- qemu-efi-aarch64
- qemu-system-arm

For other architectures the list of requirements is likely a bit different.

It would be great if autopkgtest-build-qemu could detect this and print a
message about the missing packages instead of crashing.

Bug#1021775: Last apt update: -0.0 day(s) ago

[Christoph Berg]

Package: hobbit-plugins
Version: 20201127
Severity: normal

Apparently when apt update and the check are running at the same time,
the following can happen:

 Fri Oct 14 15:18:01 2022 - apt NOT ok

Debian GNU/Linux 11 (bullseye)

green Pinned/held packages not installed from apt repositories (2):
   ...

green Accepted packages not installed from apt repositories (1):
   ...

yellow Last apt update: -0.0 day(s) ago

Christoph

Bug#1021745: [Pkg-shadow-devel] Bug#1021745: passwd: /etc/passwd was edited with the wrong shell path

[Serge E. Hallyn]

On Fri, Oct 14, 2022 at 12:18:26AM +0200, Najib B wrote:
> Package: passwd
> Version: 1:4.12.3+dfsg1-1
> Severity: important
> X-Debbugs-Cc: najibbak...@gmail.com
> 
> Dear Maintainer,
> 
> I have just noticed this issue on chsh that I would like to report to you,
> including a solution that I would like to mention.
> 
> --
> # chsh
> Changing the login shell for root
> Enter the new value, or press ENTER for the default
> Login Shell [/bin/zsh]: zsh
> chsh: Warning: zsh does not exist
> 
> exit
> $ sudo chsh
> Password:
> chsh: PAM: Authentication failure`
> ---
> The problem here, is that chsh has accepted "zsh" without checking first, if
> that path exists.

Well no, it clearly checked, and warned you.  You chose to
ignore the warning.  If we refuse to set it, we'll get tons
of bug reports about that.  We could add a fail-on-warning
option I suppose...  But if you choose to ignore the warnings
I don't think you'd use that option.

> After exiting "root" it is not possible to login back.
> The solution is to edit /etc/passwd from this:
> root:x:0:0:root:/root:zsh
> to this:
> root:x:0:0:root:/root:/bin/zsh
> 
> Best regards,
> 
> 
> -- System Information:
> Distributor ID:   Kali
> Description:  Kali GNU/Linux Rolling
> Release:  2022.3
> Codename: kali-rolling
> Architecture: x86_64
> 
> Kernel: Linux 5.18.0-kali7-amd64 (SMP w/3 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 passwd depends on:
> ii  libaudit1   1:3.0.7-1.1
> ii  libc6   2.34-4
> ii  libcrypt1   1:4.4.28-2
> ii  libpam-modules  1.5.2-5
> ii  libpam0g1.5.2-5
> ii  libselinux1 3.4-1+b2
> ii  libsemanage23.4-1+b2
> 
> Versions of packages passwd recommends:
> ii  sensible-utils  0.0.17
> 
> passwd suggests no packages.
> 
> -- no debconf information
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1021774: cross-toolchain-base-mipsen: duplicated ld.so.1 in multiple packages

[Andreas Beckmann]

Source: cross-toolchain-base-mipsen
Version: 20
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

several ld.so.1 variants are shipped by two packages that are not
conflicting with each other:

libc6-mips32-mips64-cross=2.35-3cross1
libc6-mips64-cross=2.35-3cross1
usr/mips64-linux-gnuabi64/lib/ld.so.1
libc6-mips32-mips64el-cross=2.35-3cross1
libc6-mips64el-cross=2.35-3cross1
usr/mips64el-linux-gnuabi64/lib/ld.so.1
libc6-mips32-mips64r6-cross=2.35-3cross1
libc6-mips64r6-cross=2.35-3cross1
usr/mipsisa64r6-linux-gnuabi64/lib/ld-linux-mipsn8.so.1
libc6-mips32-mips64r6el-cross=2.35-3cross1
libc6-mips64r6el-cross=2.35-3cross1
usr/mipsisa64r6el-linux-gnuabi64/lib/ld-linux-mipsn8.so.1
libc6-mips32-mipsn32-cross=2.35-3cross1
libc6-mipsn32-cross=2.35-3cross1
usr/mips64-linux-gnuabin32/lib/ld.so.1
libc6-mips32-mipsn32el-cross=2.35-3cross1
libc6-mipsn32el-cross=2.35-3cross1
usr/mips64el-linux-gnuabin32/lib/ld.so.1
libc6-mips32-mipsn32r6-cross=2.35-3cross1
libc6-mipsn32r6-cross=2.35-3cross1
usr/mipsisa64r6-linux-gnuabin32/lib/ld-linux-mipsn8.so.1
libc6-mips32-mipsn32r6el-cross=2.35-3cross1
libc6-mipsn32r6el-cross=2.35-3cross1
usr/mipsisa64r6el-linux-gnuabin32/lib/ld-linux-mipsn8.so.1


Andreas

Bug#1021773: libconfig-model-dpkg-perl: tweak example in docs for fix.(scanned.)copyright does not work

[Andreas Metzler]

Package: libconfig-model-dpkg-perl
Version: 2.164
Severity: normal

The docs for Config::Model::Dpkg::Copyright list dthis example for
tweaking:

! Files:'*' Copyright=~s/\s*".*//

Pasting this example into debian/fix.scanned.copyright makes cme update
dpkg-copyright fail with:

Note: loading debian/fix.scanned.copyright fixes from copyright fix files
Configuration item 'Dpkg::Copyright' has a user error:
Error while applying fix.scanned.copyright file:
Configuration item 'Files:"'*'" Copyright' has a wrong value:
Undefined mandatory value.

cu Andreas

Bug#1021772: libconfig-model-dpkg-perl: docs refer to debian/fix.copyright but fix.scanned.copyright is used

[Andreas Metzler]

Package: libconfig-model-dpkg-perl
Version: 2.164
Severity: normal

Hello,

the docs refer to "debian/fix.copyright" while the filemname used is
fix.scanned.copyright.

cu Andreas

Bug#962650: libcamera now maintaines proper sonames

[Rafael Diniz]

Upstream libcamera now properly sets soname version and bumps it for ABI 
changes.


Relevant commits in upstream:

utils: Provide a release script
https://git.libcamera.org/libcamera/libcamera.git/commit/?id=fc46d091231e22f47e2056fb854ddf4a999d606a

utils: semver: Add version helper
https://git.libcamera.org/libcamera/libcamera.git/commit/?id=1bd14fc8954425ac310d24876c6257f0b80c4880

meson: Shared Object version handling
https://git.libcamera.org/libcamera/libcamera.git/commit/?id=0aac297afd0cf2748c20f919bdd8d5e390b8d9a8

Kind regards,
Rafael Diniz



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021130: bullseye-pu: package tinyexr/1.0.1+dfsg-1+deb11u1

[Timo Röhling]

* Adam D. Barratt  [2022-10-14 13:04]:

Assuming the diff would be similar to that initially proposed, you can
simply prepare and upload 1.0.0+dfsg-1+deb11u1 and we can sort things
out from there.

It is, so I uploaded the correct version now.
Sorry for the screw-up, I should have noticed that before I even
proposed the update.


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1021130: bullseye-pu: package tinyexr/1.0.1+dfsg-1+deb11u1

[Timo Röhling]

* Adam D. Barratt  [2022-10-14 12:53]:

On Fri, 2022-10-14 at 11:53 +0100, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Sun, 2022-10-02 at 19:38 +0200, Timo Röhling wrote:
> The update fixes two vulnerabilities with low priority, i.e.
> the security team has decided not to issue a DSA.
>
> [ Impact ]
> CVE-2022-34300: Heap overflow in DecodePixelData
> CVE-2022-38529: Heap overflow in rleUncompress
>

+  * Fix low-priority vulnerabilities

I'm not sure I'd use that wording in a changelog personally - more
likely just "fix security issues" or "backport fixes" or similar -
but
it's up to you.


Hmmm. The debdiff you've uploaded is rather larger than I was
expecting, or was proposed.

That appears to be (which I should have spotted earlier) because stable
has 1.0.0+dfsg-1 and your upload is based on 1.0.*1*+dfsg-1.

Is there something we can do about this?
Should I prepare a new upload with 1.0.1+really1.0.0, for instance?

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1021130: bullseye-pu: package tinyexr/1.0.1+dfsg-1+deb11u1

[Adam D. Barratt]

On Fri, 2022-10-14 at 13:58 +0200, Timo Röhling wrote:
> * Adam D. Barratt  [2022-10-14 12:53]:
> > On Fri, 2022-10-14 at 11:53 +0100, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On Sun, 2022-10-02 at 19:38 +0200, Timo Röhling wrote:
> > > > The update fixes two vulnerabilities with low priority, i.e.
> > > > the security team has decided not to issue a DSA.
> > > > 
> > > > [ Impact ]
> > > > CVE-2022-34300: Heap overflow in DecodePixelData
> > > > CVE-2022-38529: Heap overflow in rleUncompress
> > > > 
> > > 
> > > +  * Fix low-priority vulnerabilities
> > > 
> > > I'm not sure I'd use that wording in a changelog personally -
> > > more
> > > likely just "fix security issues" or "backport fixes" or similar
> > > -
> > > but
> > > it's up to you.
> > 
> > Hmmm. The debdiff you've uploaded is rather larger than I was
> > expecting, or was proposed.
> > 
> > That appears to be (which I should have spotted earlier) because
> > stable
> > has 1.0.0+dfsg-1 and your upload is based on 1.0.*1*+dfsg-1.
> Is there something we can do about this?
> Should I prepare a new upload with 1.0.1+really1.0.0, for instance?

There's a holding queue in front of proposed-updates, so the upload
isn't in the archive yet.

Assuming the diff would be similar to that initially proposed, you can
simply prepare and upload 1.0.0+dfsg-1+deb11u1 and we can sort things
out from there.

Regards,

Adam

Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el

[Axel Beckert]

Control: found -1 1:28.2+1-1

Hi Sean,

Sean Whitton wrote:
> On Sun 21 Aug 2022 at 02:46PM +02, Axel Beckert wrote:
> > Version: 1:28.1+1-2
[…]
> > upgrading emacs respectively emacs-gtk from 27.1 to 28.1 causes an
> > endless fork loops during package configuration time:
> 
> Are you able to reproduce this with what's in sid at present?

Oh, a new upstream release! Let's try… :-)

Nothing obvious in the output of apt:

Setting up emacs-el (1:28.2+1-1) ...
Setting up emacs-common (1:28.2+1-1) ...
Setting up emacs-bin-common (1:28.2+1-1) ...
Setting up emacs-gtk (1:28.2+1-1) ...
Deep recursion on subroutine 
"main::generate_relevant_tsort_dependencies_internals" at 
/usr/lib/emacsen-common/lib.pl line 127.
Install a2ps for emacs
Install develock-el for emacs
Install ecb for emacs
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install haml-elisp for emacs
Skipping byte-compilation for emacs: Not supported
Install post-el for emacs
Install pylint for emacs
Install quilt-el for emacs
Install ratpoison for emacs
Install rdtool-elisp for emacs
Install sawfish for emacs
Install whizzytex for emacs
Install elpa-gitignore-mode for emacs
install/gitignore-mode-1.4.0: Handling install of emacsen flavor emacs
install/gitignore-mode-1.4.0: byte-compiling for emacs

But unfortunately, it's still reproducible:

11054 root20   0  2724   960   864 S   0.0  0.0  0:00.00 │  │ │  └─ 
/bin/sh /var/lib/dpkg/info/emacs-gtk.postinst configure 1:27.1+1-3.1+b1 

   
11058 root20   0 20372 14448  4916 S   0.0  0.0  0:00.29 │  │ │ 
└─ /usr/bin/perl -w /usr/lib/emacsen-common/emacs-install emacs
11377 root20   0 0 0 0 Z   0.0  0.0  0:00.00 │  │ │ 
   ├─ emacs-install
11438 root20   0  2724   960   864 S   0.0  0.0  0:00.00 │  │ │ 
   └─ /bin/sh /usr/lib/emacsen-common/packages/install/elpa-gitignore-mode emacs
11439 root20   0  2724   956   864 S   0.0  0.0  0:00.00 │  │ │ 
  └─ /bin/sh /usr/lib/dh-elpa/helper/install emacs gitignore-mode 1.4.0
11442 root20   0  2724   112 0 S   0.0  0.0  0:00.00 │  │ │ 
 └─ /bin/sh /usr/lib/dh-elpa/helper/install emacs gitignore-mode 1.4.0
11443 root20   0  168M 58500 36544 S   0.0  0.1  0:00.58 │  │ │ 
└─ emacs --quick --batch -l package --eval (setq package-user-dir 
"/nonexistent") --eval (add-to-list 'package-directory-list 
"/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -f 
batch-byte-compile gitignore-mode-aut
11444 root20   0  170M 61168 36708 S   0.0  0.1  0:02.24 │  │ │ 
   └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-63616c6c2d696e7465726163746976656c79_call_interactively_0-VtJDks.el
11448 root20   0  170M 60524 36284 S   0.0  0.1  0:01.97 │  │ │ 
  └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Wu7AW4.el
11449 root20   0  170M 61244 36792 S   0.0  0.1  0:02.01 │  │ │ 
 └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-XKbTq1.el
11450 root20   0  170M 61200 36744 S   0.0  0.1  0:02.07 │  │ │ 
└─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-2Zc2GB.el
11453 root20   0  170M 61176 36728 S   0.0  0.1  0:02.02 │  │ │ 
   └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Ro5jje.el
11454 root20   0  170M 61308 36852 S   0.0  0.1  0:02.14 │  │ │ 
  └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-2uNzTS.el
11461 root20   0  170M 61192 36736 S   0.0  0.1  0:02.01 │  │ │ 
 └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Ex5VpA.el
11462 root20   0  170M 60696 36456 S   0.0  0.1  0:02.03 │  │ │ 
└─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Q91LV9.el
11463 root20   0  170M 61228 36776 S   0.0  0.1  0:02.01 │  │ │ 
   └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-boXgPR.el
11469 root20   0  170M 61184 36724 S   0.0  0.1  0:02.00 │  │ │ 
  └─ /usr/bin/emacs --batch -l 

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

[Vincent Lefevre]

On 2022-10-14 12:44:25 +0200, Marco d'Itri wrote:
> On Oct 14, Vincent Lefevre  wrote:
> > > This is not "the Debian FAQ" but "the DPKG FAQ", which has been known to 
> > > recommend awful things in the past.
> > But it is still considered in the present times by the dpkg developers.
> > Bug 923423 was closed several hours ago based on this dpkg FAQ:
> This is obviously convenient on Guillem's part, but we have to optimize 
> systems by default for the general case and not just for dpkg -i.

This dpkg FAQ says that this is not beneficial for just dpkg,
but also "for any application in the system".

> > (the issue here is that there is a fsync for *every* file, so that for
> And at this point I am wondering if this is a good design, or if it 
> would be better to use a different strategy.

IMHO, this should time based or perhaps the strategy could depend
on the package being installed (critical packages like libc6 could
use fsync for every file, but all these intermediate fsync's are
useless for packages that can simply be reinstalled in case of
crash or hardware related failure).

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

Bug#1021130: bullseye-pu: package tinyexr/1.0.1+dfsg-1+deb11u1

[Adam D. Barratt]

On Fri, 2022-10-14 at 11:53 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2022-10-02 at 19:38 +0200, Timo Röhling wrote:
> > The update fixes two vulnerabilities with low priority, i.e.
> > the security team has decided not to issue a DSA.
> > 
> > [ Impact ]
> > CVE-2022-34300: Heap overflow in DecodePixelData
> > CVE-2022-38529: Heap overflow in rleUncompress
> > 
> 
> +  * Fix low-priority vulnerabilities
> 
> I'm not sure I'd use that wording in a changelog personally - more
> likely just "fix security issues" or "backport fixes" or similar -
> but
> it's up to you.

Hmmm. The debdiff you've uploaded is rather larger than I was
expecting, or was proposed.

That appears to be (which I should have spotted earlier) because stable
has 1.0.0+dfsg-1 and your upload is based on 1.0.*1*+dfsg-1.

Regards,

Adam

Bug#1021771: apache2: Accessing to type-map without .var suffix results 500 and apache2 exits

[Shintaro Sakahara]

Package: apache2
Version: 2.4.54-1~deb11u1
Severity: important

Dear Maintainer,

I recently upgraded my server from Debian 10 to 11 and encountered a problem
where apache2 responded 500 Internal Server Error and then the process exited
when a URL to a type-map, which referenced CGI script as actual content,
without ".var" suffix was getting accessed.

I created a small example using Docker and put on GitHub so that everyone could
easily reproduce this problem.

https://github.com/skhrshin/apache2-crash-example

* Steps to reproduce *

1. Clone the repo into somewhere
2. Run `docker-compose build`
3. Run `docker-compose up`
4. Access to http://localhost:8081/board.cgi with your web browser

* Expected behavior *

A string "OK" is displayed.

* Actual behavior *

Your web browser gets 500 Internal Server Error.
Also, in a few seconds, the apache2 process is terminated.

I'm not sure if the problem is caused solely by apache2 package or by some
other dependencies like apache2-suexec-pristine or libapache2-mpm-itk, but
I don't know how to find it out. So I asked about this issue to Debian-user ML
if there's something I can do, but I could get no answer, so now I'm reporting
it here. Please tell me if something is insufficient and there's a way to
investigate it more.


-- Package-specific info:

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

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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.54-1~deb11u1
ii  apache2-data 2.4.54-1~deb11u1
ii  apache2-utils2.4.54-1~deb11u1
ii  dpkg 1.20.12
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-4+deb11u2
ii  procps   2:3.3.17-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.0+nmu1

Versions of packages apache2 suggests:
pn  apache2-doc  
ii  apache2-suexec-pristine  2.4.54-1~deb11u1
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-6+deb11u1
ii  libaprutil1  1.6.1-5
ii  libaprutil1-dbd-sqlite3  1.6.1-5
ii  libaprutil1-ldap 1.6.1-5
ii  libbrotli1   1.0.9-2+b2
ii  libc62.31-13+deb11u4
ii  libcrypt11:4.4.18-4
ii  libcurl4 7.74.0-1.3+deb11u3
ii  libjansson4  2.13.1-1.1
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libnghttp2-141.43.0-1
ii  libpcre3 2:8.39-13
ii  libssl1.11.1.1n-0+deb11u3
ii  libxml2  2.9.10+dfsg-6.7+deb11u2
ii  perl 5.32.1-4+deb11u2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages apache2-bin suggests:
pn  apache2-doc  
ii  apache2-suexec-pristine  2.4.54-1~deb11u1
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2 is related to:
ii  apache2  2.4.54-1~deb11u1
ii  apache2-bin  2.4.54-1~deb11u1

-- Configuration Files:
/etc/apache2/conf-available/other-vhosts-access-log.conf changed [not included]
/etc/apache2/ports.conf changed [not included]

-- no debconf information

Bug#1021214: libconfuse 3.3-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1021214 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libconfuse
Version: 3.3-2+deb11u1

Explanation: fix a heap-based buffer over-read in cfg_tilde_expand 
[CVE-2022-40320]

Bug#1021186: debmirror 2.35+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1021186 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: debmirror
Version: 2.35+deb11u1

Explanation: add non-free-firmware to the default section list