Bug#1043395: roundcube-core: Cron job triggers gc.sh 60 times

[Antti Kultanen]

Package: roundcube
Version: 1.6.2+dfsg-1
Severity: minor

Hi all,

in the crontab file /etc/cron.d/roundcube-core file the garbage collector 
is set run 60 times, or every minute from 5:00 to 5:59.
-8<-
# Purge expired sessions, caches and tempfiles
* 5 * * * www-data test -d /run/systemd/system || /usr/share/roundcube/bin/gc.sh
-8<-
Is there a reason for this or is it just a typo? I'd imagine running it once 
would suffice.


(Noticed this when #1043250 caused PHP warnings about invalid timezone)


Thanks,
Antti

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

Kernel: Linux 6.4.0-0-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages roundcube-core depends on:
ii  dbconfig-common   2.0.24
ii  debconf [debconf-2.0] 1.5.82
ii  dpkg  1.21.22
ii  libapache2-mod-php8.2 [php-json]  8.2.7-1
ii  libjs-bootstrap4  4.6.1+dfsg1-4
ii  libjs-codemirror  5.65.0+~cs5.83.9-2
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-minicolors   2.3.5+dfsg-4
ii  libjs-jquery-ui   1.13.2+dfsg-1
ii  libjs-jstimezonedetect1.0.7+~1.0.3-1
ii  libmagic1 1:5.44-3
ii  php   2:8.2+93
ii  php-auth-sasl 1.1.0-1
ii  php-cli   2:8.2+93
ii  php-common2:93
ii  php-guzzlehttp-guzzle 7.4.5-1
ii  php-intl  2:8.2+93
ii  php-json  2:8.2+93
ii  php-mail-mime 1.10.11-1
ii  php-masterminds-html5 2.8.1+dfsg-1
ii  php-mbstring  2:8.2+93
ii  php-net-sieve 1.4.6-1
ii  php-net-smtp  1.10.1-1
ii  php-pear  1:1.10.13+submodules+notgz+2022032202-2
ii  php8.2 [php]  8.2.7-1
ii  php8.2-cli [php-json] 8.2.7-1
ii  php8.2-intl [php-intl]8.2.7-1
ii  php8.2-mbstring [php-mbstring]8.2.7-1
ii  roundcube-mysql   1.6.2+dfsg-1
ii  ucf   3.0043+nmu1

Versions of packages roundcube-core recommends:
ii  apache2 [httpd-cgi]   2.4.57-2
ii  php-enchant   2:8.2+93
ii  php-gd2:8.2+93
ii  php8.2-enchant [php-enchant]  8.2.7-1
ii  php8.2-gd [php-gd]8.2.7-1
ii  roundcube-skin-classic1.6.0+ds-2
ii  roundcube-skin-larry  1.6.1+ds-1

Versions of packages roundcube-core suggests:
pn  php-bacon-qr-code   
pn  php-bjeavons-zxcvbn-php 
pn  php-crypt-gpg   
pn  php-net-ldap3   
pn  php-roundcube-rtf-html-php  
pn  roundcube-plugins   

Versions of packages roundcube depends on:
ii  dpkg  1.21.22

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

-- debconf information excluded

Bug#1042902: system-packages-el and #1042902

[Lev Lamberov]

Hi,

As reported in #1042902 system-packages-el in some configurations sets
its system-packages-package-manager variable to a wrong value. The
upstream documentation says that

  The package attempts to guess which package manager you use. If it
  guesses wrong (or you'd like to set it manually), you may modify the
  variable =system-packages-package-manager=.

Typically one uses apt/apt-get in Debian, so I think it is justified to
set the variable to apt by default. I can imagine someone who uses other
package managers in Debian, but guess these users are not our primary
target audience so to say.

What the team thinks about the issue? Should the variable be set to apt
by default in Debian? If yes, where would you suggest to set it?

Regards,
Lev

Bug#907490: gnome-session-binary[…]: Unrecoverable failure in required component org.gnome.Shell.desktop

[Alma Madeleine]

tags 907490 - unreproducible - moreinfo
affects 907490 gnome-session-bin gnome-settings-daemon gjs

thanks



In my journal, the error “Unrecoverable failure in required component 
org.gnome.Shell.desktop” occurs in red during boot.  Shortly before this 
error message, lots of other warnings, failures, and errors get printed 
(all not in red but in yellow or bold white or usual white-gray):


…
Aug 10 04:17:04 MyAnonymizedPC systemd[1008]: Reached target 
default.target - Main User Target.

Aug 10 04:17:04 MyAnonymizedPC systemd[1008]: Startup finished in 1.402s.
Aug 10 04:17:04 MyAnonymizedPC dbus-daemon[873]: [system] Activating via 
systemd: service name='org.freedesktop.PackageKit' 
unit='packagekit.service' requested by ':1.33' (uid=119 pid=1065 
comm="/usr/bin/gnome-shell")
Aug 10 04:17:04 MyAnonymizedPC systemd[1]: Starting packagekit.service - 
PackageKit Daemon...

Aug 10 04:17:04 MyAnonymizedPC PackageKit[1248]: daemon start
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
apps-m...@gnome-shell-extensions.gcampax.github.com already installed in 
/usr/share/gnome-shell/extensions/apps-m...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/apps-m...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
auto-move-wind...@gnome-shell-extensions.gcampax.github.com already 
installed in 
/usr/share/gnome-shell/extensions/auto-move-wind...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/auto-move-wind...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
drive-m...@gnome-shell-extensions.gcampax.github.com already installed 
in 
/usr/share/gnome-shell/extensions/drive-m...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/drive-m...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
launch-new-insta...@gnome-shell-extensions.gcampax.github.com already 
installed in 
/usr/share/gnome-shell/extensions/launch-new-insta...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/launch-new-insta...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
native-window-placem...@gnome-shell-extensions.gcampax.github.com 
already installed in 
/usr/share/gnome-shell/extensions/native-window-placem...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/native-window-placem...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
places-m...@gnome-shell-extensions.gcampax.github.com already installed 
in 
/usr/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
screenshot-window-si...@gnome-shell-extensions.gcampax.github.com 
already installed in 
/usr/share/gnome-shell/extensions/screenshot-window-si...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/screenshot-window-si...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
user-th...@gnome-shell-extensions.gcampax.github.com already installed 
in 
/usr/share/gnome-shell/extensions/user-th...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/user-th...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
window-l...@gnome-shell-extensions.gcampax.github.com already installed 
in 
/usr/share/gnome-shell/extensions/window-l...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/window-l...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
windowsnaviga...@gnome-shell-extensions.gcampax.github.com already 
installed in 
/usr/share/gnome-shell/extensions/windowsnaviga...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/windowsnaviga...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
workspace-indica...@gnome-shell-extensions.gcampax.github.com already 
installed in 
/usr/share/gnome-shell/extensions/workspace-indica...@gnome-shell-extensions.gcampax.github.com. 
/usr/share/gnome-shell/extensions/workspace-indica...@gnome-shell-extensions.gcampax.github.com 
will not be loaded
Aug 10 04:17:04 MyAnonymizedPC gnome-shell[1065]: Extension 
freon@UshakovVasilii_Github.yahoo.com already installed in 
/usr/share/gnome-shell/extensions/freon@UshakovVasilii_Github.yahoo.com. 

Bug#1041332: mrtg: modifies conffiles (policy 10.7.3): /etc/mrtg/mrtg.cfg

[Eriberto Mota]

> during a test with piuparts I noticed your package modifies conffiles.
> This is forbidden by the policy, see
> https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files

Hi Andreas,

Thanks for your time and help.

I decided to change the current action from the debconf by a warning for
the final user. I will make it soon.

Regards,

Eriberto

Bug#1043394: perl: Please add cross config.sh files for hurd-amd64

[Samuel Thibault]

Package: perl
Version: 5.36.0-7
Severity: important
Tags: patch

Hello,

We are bootstrapping hurd-amd64 :)

I could run config.debian natively on the arch, here is the result,
could you add them to debian/cross/hurd-amd64/, so that we can easily
cross-build the package?

Thanks,
Samuel

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

Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 perl depends on:
ii  dpkg   1.21.22
ii  libperl5.365.36.0-7
ii  perl-base  5.36.0-7
ii  perl-modules-5.36  5.36.0-7

Versions of packages perl recommends:
ii  netbase  6.4

Versions of packages perl suggests:
pn  libtap-harness-archive-perl  
ii  libterm-readline-gnu-perl1.46-1
ii  make 4.3-4.1
ii  perl-doc 5.36.0-7

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
#!/bin/sh
#
# This file was produced by running the Configure script. It holds all the
# definitions figured out by Configure. Should you modify one of these values,
# do not forget to propagate your changes by running "Configure -der". You may
# instead choose to run each of the .SH files by yourself, or "Configure -S".
#

# Package name  : perl5
# Source directory  : /dummy/build/dir
# Configuration time: Tue Oct 18 16:44:58 UTC 2022
# Configured by : Debian
# Target system : gnu localhost 0.9 gnu-mach x86_64-at386 gnu 

: Configure command line arguments.
config_arg0='../Configure'
config_args='-Dmksymlinks -Dusethreads -Duselargefiles -Dcc=x86_64-gnu-gcc 
-Dcpp=x86_64-gnu-cpp -Dld=x86_64-gnu-gcc -Dccflags=-DDEBIAN 
-DAPPLLIB_EXP="/usr/lib/x86_64-gnu/perl-base" -Wdate-time -D_FORTIFY_SOURCE=2 
-g -O2 -ffile-prefix-map=/dummy/build/dir=. -fstack-protector-strong -Wformat 
-Werror=format-security -Dldflags= -Wl,-z,relro -Dlddlflags=-shared 
-Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=x86_64-gnu -Dprefix=/usr 
-Dprivlib=/usr/share/perl/5.36 -Darchlib=/usr/lib/x86_64-gnu/perl/5.36 
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 
-Dvendorarch=/usr/lib/x86_64-gnu/perl5/5.36 -Dsiteprefix=/usr/local 
-Dsitelib=/usr/local/share/perl/5.36.0 
-Dsitearch=/usr/local/lib/x86_64-gnu/perl/5.36.0 -Dman1dir=/usr/share/man/man1 
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 
-Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl 
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm 
-Ui_libutil -Ui_xlocale -Uversiononly -DDEBUGGING=-g -Doptimize=-O2 -dEs 
-Uuseshrplib'
config_argc=40
config_arg1='-Dmksymlinks'
config_arg2='-Dusethreads'
config_arg3='-Duselargefiles'
config_arg4='-Dcc=x86_64-gnu-gcc'
config_arg5='-Dcpp=x86_64-gnu-cpp'
config_arg6='-Dld=x86_64-gnu-gcc'
config_arg7='-Dccflags=-DDEBIAN -DAPPLLIB_EXP="/usr/lib/x86_64-gnu/perl-base" 
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/dummy/build/dir=. 
-fstack-protector-strong -Wformat -Werror=format-security'
config_arg8='-Dldflags= -Wl,-z,relro'
config_arg9='-Dlddlflags=-shared -Wl,-z,relro'
config_arg10='-Dcccdlflags=-fPIC'
config_arg11='-Darchname=x86_64-gnu'
config_arg12='-Dprefix=/usr'
config_arg13='-Dprivlib=/usr/share/perl/5.36'
config_arg14='-Darchlib=/usr/lib/x86_64-gnu/perl/5.36'
config_arg15='-Dvendorprefix=/usr'
config_arg16='-Dvendorlib=/usr/share/perl5'
config_arg17='-Dvendorarch=/usr/lib/x86_64-gnu/perl5/5.36'
config_arg18='-Dsiteprefix=/usr/local'
config_arg19='-Dsitelib=/usr/local/share/perl/5.36.0'
config_arg20='-Dsitearch=/usr/local/lib/x86_64-gnu/perl/5.36.0'
config_arg21='-Dman1dir=/usr/share/man/man1'
config_arg22='-Dman3dir=/usr/share/man/man3'
config_arg23='-Dsiteman1dir=/usr/local/man/man1'
config_arg24='-Dsiteman3dir=/usr/local/man/man3'
config_arg25='-Duse64bitint'
config_arg26='-Dman1ext=1'
config_arg27='-Dman3ext=3perl'
config_arg28='-Dpager=/usr/bin/sensible-pager'
config_arg29='-Uafs'
config_arg30='-Ud_csh'
config_arg31='-Ud_ualarm'
config_arg32='-Uusesfio'
config_arg33='-Uusenm'
config_arg34='-Ui_libutil'
config_arg35='-Ui_xlocale'
config_arg36='-Uversiononly'
config_arg37='-DDEBUGGING=-g'
config_arg38='-Doptimize=-O2'
config_arg39='-dEs'

Bug#1043393: strace: enable testsuite non fatal on riscv64

[Bo YU]

Package: strace
Version: 6.1-0.1
Severity: normal
Tags: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The strace package has FTBFS issue due to test failed from known kernel
issue:

https://github.com/strace/strace/issues/242
http://lists.infradead.org/pipermail/linux-riscv/2023-August/038202.html

Since it affects riscv64's official rebootstrap, we will be temporarily
make testsuite non fatal on riscv64 in uploading 6.4. The reportbug is
opened in order to track the bug on Debian side. Once the issue to be
fixed it should be closed.

Thanks.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1041836: root unable to write un-owned

[Paul Szabo]

Bummer. This last "echo x > /tmp/x" issue is probably the result of
protected_regular being set in kernel configs, see
https://docs.kernel.org/admin-guide/sysctl/fs.html#id12

Sorry about the noise. (Hangs head in shame.)

Cheers, Paul

Bug#1041836: root unable to write un-owned

[Paul Szabo]

Another oddity that should never happen: root cannot write file
that he does not own. Demonstration (root running bash):

  root# touch /tmp/x
  root# ls -l /tmp/x
  -rw-r--r-- 1 root root 0 Aug 10 09:39 /tmp/x
  root# echo a > /tmp/x
  root# chown 2:2 /tmp/x
  root# ls -l /tmp/x
  -rw-r--r-- 1 bin bin 2 Aug 10 09:39 /tmp/x
  root# echo b > /tmp/x
  -bash: /tmp/x: Permission denied
  root# chown 0:0 /tmp/x
  root# ls -l /tmp/x
  -rw-r--r-- 1 root root 2 Aug 10 09:39 /tmp/x
  root# echo c > /tmp/x

This issue seems to reproduce on all machines where I tried.
Quite possibly unrelated (so I may cop some flak) ... or maybe
these "impossible" happenings have a common cause?

Cheers, Paul

Bug#1043392: fanwor: Depends on SDL 1.2

[Simon McVittie]

Source: fanwor
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2
Control: block 1038037 by -1

This package seems to be new to the archive, but using the legacy SDL
1.2 API/ABI, which since trixie is provided by a compatibility layer
implemented in terms of SDL 2.

As a result, it also uses libsdl-mixer1.2, which is completely
unmaintained upstream (there will be no new releases).

If possible, please port this package to use SDL 2 directly. There is
a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

The direct SDL 2 replacement for libsdl-mixer1.2-dev is libsdl2-mixer-dev,
which has a very similar API and is maintained.

Thanks,
smcv

Bug#1043201: slirp: immediate exit at startup

[Ferenc Wágner]

Roberto Lumbreras  writes:

> timeout is defined as "struct timeval":
>
>struct timeval {
>time_t   tv_sec;   /* Seconds */
>suseconds_t  tv_usec;  /* Microseconds */
>};
>
> timeout.tv_used is suseconds_t == time_t == int, so I can't understand
> why it's unsigned in your case.

Hi Roberto,

I probably missed the starting 's', suseconds_t is indeed documented as
signed, and is actually a long int here.  So my patch shouldn't work.
What's sure:

# gdb slirp
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from slirp...
Reading symbols from 
/usr/lib/debug/.build-id/e1/1ce5371d887d06c3b97a0c6a68463ba1cc8bcf.debug...
(gdb) b main.c:960
Breakpoint 1 at 0x1408b: file ./main.c, line 960.
(gdb) r
Starting program: /usr/bin/slirp 
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Slirp v1.0.17 (BETA)

Copyright (c) 1995,1996 Danny Gasparovski and others.
All rights reserved.
This program is copyrighted, free software.
Please read the file COPYRIGHT that came with the Slirp
package for the terms and conditions of the copyright.

IP address of Slirp host: 172.17.0.2
IP address of your DNS(s): 10.12.1.5, 10.10.1.10
Your address is 10.0.2.15
(or anything else you want)

Type five zeroes (0) to exit.

[autodetect SLIP/CSLIP, MTU 1500, MRU 1500, 115200 baud]

SLiRP Ready ...

Breakpoint 1, main_loop () at ./main.c:960
warning: Source file is more recent than executable.
960 ret = select(nfds+1, , , , );
(gdb) p timeout
$1 = {tv_sec = 0, tv_usec = 4294967295}
(gdb) p/x timeout.tv_usec
$2 = 0x
(gdb) p nfds
$3 = 0
(gdb) n
962 if (ret < 0) {
(gdb) p ret
$4 = -1
(gdb) p errno
$5 = 22
(gdb) n
963 if (errno == EINTR)
(gdb) 
965 slirp_exit(1);
(gdb) 
[Inferior 1 (process 4349) exited with code 01]

> If you dig in src/main.c there are more lines with timeout.tv_used
> being compared with negative numbers, your patch may work but I think
> it has to be something else.

Yes, I've got another theory now: timeout.tv_usec is a long int of
8 bytes size, but at main.c:935 it gets assigned a 4-byte unsigned:

if ((timeout.tv_usec < 0) || (tmp_time >= 0 && tmp_time < timeout.tv_usec))
timeout.tv_usec = (u_int)tmp_time;

This results in the value of 4294967295 above instead of the expected
-1, so timeout does not get reset to {5, 0} and select() gets the
invalid timeout value, immediately breaking the loop.

> Have you tried just compiling the slirp package? Maybe it's a problem
> with libc6 linking, https://tracker.debian.org/pkg/slirp warns that
> slirp "Fails to build during reproducibility testing". I'm looking
> into this.

Reproducibility probably does not factor into this, but I'll do some
more checks as I get to it.
-- 
Regards,
Feri.

Bug#1041836: libc6 2.36-9+deb12u1 double free abort

[Paul Szabo]

Dear Aurelien,

I used LD_PRELOAD=libc_malloc_debug.so for MALLOC_CHECK_. With those
extra checks (tried all values of MALLOC_CHECK_ from 0 to 20), glibc
did not show any errors, suggesting that the bug is not in inetd.

The original poster said his issue shows on some hardware only.
I observed my issue on a wider range of CPUs: present on Xeon4309Y,
Xeon6326 and i7-8700, but not on i7-4790, i5-4570, i5-3470, N5105 or
x5-Z8350. Maybe the difference is in the RAM of the machine? Those
with my issue have 16GB or more, those without have 8GB or less. 

Cheers, Paul

Bug#1043391: debianize crash

[Jelmer Vernooij]

Package: lintian-brush

On Sun, Jun 25, 2023 at 05:42:11PM +0200, Alexandre Detiste wrote:
> I know it's experimental :-)
> 
>   url = g...@github.com:dcarp/cmake-d.git
> 
> 
> 
>  debianize
> debianize is experimental and often generates packaging that is incomplete
> or does not build as-is. If you encounter issues, please consider filing a
> bug.
> No upstream repository specified, using upstream source in
> /home/tchet/git/cmake-d/
> Switching to packaging branch debian/main.
> No upstream releases found, falling back to snapshot.
> No upstream releases found, falling back to snapshot.
> found 457 deltas to reuse
> 
> 
> found 457 deltas to reuse
> No support in debianize for build system cmake, falling back to default.
> Creating core packaging using process_default
> Kickstarting from dist tarball. Using upstream version
> 0+git20210905.1.34095f2
> Looking for upstream 0+git20210905.1.34095f2 in upstream branch
> file:///home/tchet/git/cmake-d/,branch=debian%2Fmain.
> Looking for upstream 0+git20210905.1.34095f2 in upstream branch
> file:///home/tchet/git/cmake-d/,branch=debian%2Fmain.
> Traceback (most recent call last):
> 
> 
>   File "/usr/bin/debianize", line 8, in 
> sys.exit(main())
>  ^^
>   File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line
> 1660, in main
> debianize_result = debianize(
>^^
>   File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line
> 1098, in debianize
> control = process(
>   
>   File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line
> 688, in process_default
> kickstart_from_dist(wt, subpath)
>   File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line
> 1016, in kickstart_from_dist
> result.tag_names) = import_upstream_dist(
> ^
>   File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line
> 822, in import_upstream_dist
> upstream_branch_name) = import_upstream_version_from_dist(
> ^^
>   File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line
> 336, in import_upstream_version_from_dist
> locations = upstream_source.fetch_tarballs(
> ^^^
>   File
> "/usr/lib/python3/dist-packages/breezy/plugins/debian/upstream/branch.py",
> line 614, in fetch_tarballs
> fn = self.create_dist(
>  ^
>   File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line
> 290, in default_create_dist
> return ogni_create_dist(
>^
>   File "/usr/lib/python3/dist-packages/ognibuild/dist.py", line 162, in
> create_dist
> return dist(session, os.path.join(export_directory, subpath),
>^^
>   File "/usr/lib/python3/dist-packages/ognibuild/dist.py", line 81, in dist
> from .fixers import (
>   File "/usr/lib/python3/dist-packages/ognibuild/fixers.py", line 22, in
> 
> from buildlog_consultant.common import (
> ImportError: cannot import name 'MissingGoSumEntry' from
> 'buildlog_consultant.common'
> (/usr/lib/python3/dist-packages/buildlog_consultant/common.py)

Bug#1042830: Issue in Breezy

[Jelmer Vernooij]

This is an issue in breezy; see #968111

Bug#1041118: ska FTBFS with googletest 1.13.0

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is attached.diff -Nru ska-1.0+dfsg/debian/changelog ska-1.0+dfsg/debian/changelog
--- ska-1.0+dfsg/debian/changelog   2022-10-03 07:39:45.0 +0200
+++ ska-1.0+dfsg/debian/changelog   2023-08-10 00:11:51.0 +0200
@@ -1,3 +1,11 @@
+ska (1.0+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Override CXXFLAGS to get rid of -std=c++0x (Closes: #1041118)
+  * Clean googletest link
+
+ -- Bastian Germann   Thu, 10 Aug 2023 00:11:51 +0200
+
 ska (1.0+dfsg-2) unstable; urgency=medium
 
   * Packaging update
diff -Nru ska-1.0+dfsg/debian/clean ska-1.0+dfsg/debian/clean
--- ska-1.0+dfsg/debian/clean   1970-01-01 01:00:00.0 +0100
+++ ska-1.0+dfsg/debian/clean   2023-08-10 00:11:51.0 +0200
@@ -0,0 +1 @@
+tests/googletest
diff -Nru ska-1.0+dfsg/debian/rules ska-1.0+dfsg/debian/rules
--- ska-1.0+dfsg/debian/rules   2022-10-03 07:39:45.0 +0200
+++ ska-1.0+dfsg/debian/rules   2023-08-10 00:11:51.0 +0200
@@ -1,16 +1,23 @@
 #!/usr/bin/make -f
 
 # DH_VERBOSE := 1
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
 export LC_ALL=C.UTF-8
 
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build -- CXXFLAGS+=-std=c++17
+
 override_dh_auto_install:
# do not use broken Makefile which forces /usr/local/bin
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-   cd tests && ln -s /usr/src/googletest/googletest && make && \
+   cd tests && ln -s /usr/src/googletest/googletest && \
+   $(MAKE) CXXFLAGS+=-std=c++17 && \
./general_unittest && ./kmers_unittest && ./DNA_unittest
 endif

Bug#1042530: [request-tracker-maintainers] Bug#1042530

[Ángel]

Control: tags -1 +upstream
Control: severity -1 normal

Resetting severity to normal, as it was a result of the FTBFS. There's
an old ckeditor version bundled by upstream. It's not confirmed if the
CVE can be exploited in RT.
Should be fixed, but not a release-critical issue.

> 

Bug#1042527: [request-tracker-maintainers] Bug#1042527: request-tracker5: Include ckeditor minimified

[Ángel]

Control: tags +upstream
Control: severity normal

Resetting severity to normal, as it was a result of the FTBFS. There's
an old ckeditor version bundled by upstream. It's not confirmed if the
CVE can be exploited in RT.
Should be fixed, but not a release-critical issue.

Bug#1024693:

[kevinibmer]

I am also facing the same problem on Firefox ESR. I tried all the
about:config suggestions you find online and nothing seem to work.
Please issue some fixes.

Bug#1041836: libc6 2.36-9+deb12u1 double free abort

[Aurelien Jarno]

Hi,

What you reported seems unrelated to the original issue. It's better to
open a new bug if you believe there is in issue in glibc.

On 2023-08-09 10:46, Paul Szabo wrote:
> Maybe related: seems that the default for "mcheck" or MALLOC_CHECK_ has
> changed.
> 
> I observe an oddity. I only noticed this recently, with libc6 version
> 2.36-9+deb12u1; reverting to previous 2.36-9 did not seem to help.
> 
> The issue. Sending SIGHUP to the inetd(8) process should cause it to
> re-load its configuration, but instead it elicits
> 
>   free(): double free detected in tcache 2
> 
> and an abort. This is easiest seen (after "systemctl stop inetd") with
> 
>   root# inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs
>   [1] 2431
>   ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 
> server=/usr/sbin/identd
>   free(): double free detected in tcache 2
>   [1]+  Aborted inetd -d -i
>   root# 

This is very likely a bug in inetd. There is no default value in
MALLOC_CHECK_, by default a fast memory allocator which is not tolerant
against simple errors is used, and thus just aborts in that case.

> Sanity(?) is restored by using MALLOC_CHECK_=0 (needs LD_PRELOAD):
> 
>   root# LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i & sleep 
> 1; kill -HUP $!; sleep 1; jobs; kill $!; sleep 1; jobs
>   [1] 2437
>   ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 
> server=/usr/sbin/identd
>   REDO: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) 
> builtin=0 server=/usr/sbin/identd
>   [1]+  Running LD_PRELOAD=libc_malloc_debug.so 
> MALLOC_CHECK_=0 inetd -d -i &
>   [1]+  DoneLD_PRELOAD=libc_malloc_debug.so 
> MALLOC_CHECK_=0 inetd -d -i
>   root# 
> 
> To compound the oddity, the value of MALLOC_CHECK_ or even its presence
> seems ignored, just the LD_PRELOAD=libc_malloc_debug.so "fixes" the
> issue.

Since glibc 2.34, the debugging features in malloc such as the
MALLOC_CHECK_ environment variable are not built-in anymore and require
to preload the libc_malloc_debug.so library. This allows one to change
the level of checks through the MALLOC_CHECK_ environment variable.

Regards
Aurelien

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

Bug#1043390: yapra: please consider upgrading to 3.0 source format

[Bastian Germann]

Source: yapra
Version: 0.1.2-7.2
Severity: wishlist

This package is among the few that still use source format 1.0.
Please upgrade it to source format 3.0:
https://wiki.debian.org/Projects/DebSrc3.0

Bug#1043389: O: sjeng -- chess program that plays many variants

[Bastian Germann]

Package: wnpp

sjeng is obviously not maintained anymore. Please only consider adopting 
it if you have the time and skills to maintain it.


Description: chess program that plays many variants
 Sjeng is a chess program that plays normal chess and many variants
 like crazyhouse, bughouse, suicide (aka giveaway or anti-chess) and
 losers. It can also play variants which have the same rules as
 normal chess, but a different starting position. It uses the
 XBoard/WinBoard interface by Tim Mann, so it can be used with
 xboard or eboard. It is also capable of playing on internet chess
 servers.

Bug#1043388: RM: pixfrogger -- ROM (team); low popcon; dead upstream; not available for 64 bit

[Bastian Germann]

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

In light of #1039902 and #456037, please remove pixfrogger.
The package has a low popcon. It is dead upstream.

Bug#1043387: RM: pixbros -- ROM (team); low popcon; dead upstream; not available for 64 bit

[Bastian Germann]

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

In light of #1039902 and #456037, please remove pixbros.
The package has a low popcon. It is dead upstream.

Bug#1043386: src:rust-log: fails to migrate to testing for too long: unresolved RC issue

[Paul Gevers]

Source: rust-log
Version: 0.4.17-3
Severity: serious
Control: close -1 0.4.19-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1040835

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:rust-log has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The package is blocked by bug 
1040835 and the associated (I guess) autopkgtest regressions and 
uninstallability it causes.


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 trixie, 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/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=rust-log



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043281: Aborts with "illegal hardware instruction" on i586 AMD Geode

[martin f krafft]

Regarding the following, written by "Marc Haber" on 2023-08-08 at 14:57 Uhr 
+0200:

Is this probably a duplicate of #1004894?

If so, this probably boils down on a GCC bug, see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713


Thanks and sorry for the duplicate. Not sure it is. I did a search, 
but "opcode" only appeared on my radar later…


--
 .''`.   martin f. krafft 
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"auch der mutigste von uns hat nur selten den mut zu dem,

 was er eigentlich weiß."
 - friedrich nietzsche

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hello Nicholas,
>Remember my Wed, 21 Jun 2023 email (as well as the one with the
>diagram)? 
I remembered this also:
>"...then if httpd 1.15 is older then mini-httpd 1.30, you must choose
>1.15.  Meanwhile, Robert McCool's copyright still exists in 1.15 even
>if he hasn't made a contribution since 1.3."

>I compared a couple of versions and found the same diff.
>Hint: Read the commit message for 1.5.1.

I've redone some diffs, too. Also, my previous statement of 1.4.2 httpd
makes no sense, because, at a quick glance, I could observe the
introduction of virtual hosting in httpd 1.5*, which mini-httpd had
from the beginning. You're right to advise to look at 1.5* again.

>I started a review and noted what looks like one typo.
Where can I view the typo/review info ? I've looked in my original
merge details and I couldn't find it. Am I affected by temporary
blindness ? :)

Have a great day/night,
Alexandru



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

Bug#1043385: haskell-gi-vte: FTBFS in sid

[Andreas Hasenack]

Package: haskell-gi-vte
Version: 2.91.30-1
Severity: important

Dear Maintainer,

haskell-gi-vte is failing to build from source in debian sid:
Preprocessing library for gi-vte-2.91.30..
Building library for gi-vte-2.91.30..
[ 1 of 19] Compiling GI.Vte.Config( GI/Vte/Config.hs,
dist-ghc/build/GI/Vte/Config.o, dist-ghc/build/GI/Vte/Config.dyn_o )
[ 2 of 19] Compiling GI.Vte.Constants ( GI/Vte/Constants.hs,
dist-ghc/build/GI/Vte/Constants.o,
dist-ghc/build/GI/Vte/Constants.dyn_o )
[ 3 of 19] Compiling GI.Vte.Enums[boot] ( GI/Vte/Enums.hs-boot,
dist-ghc/build/GI/Vte/Enums.o-boot, dist-ghc/build/GI/Vte/Enums.dyn_o
)
[ 4 of 19] Compiling GI.Vte.Enums ( GI/Vte/Enums.hs,
dist-ghc/build/GI/Vte/Enums.o, dist-ghc/build/GI/Vte/Enums.dyn_o )
[ 5 of 19] Compiling GI.Vte.Flags[boot] ( GI/Vte/Flags.hs-boot,
dist-ghc/build/GI/Vte/Flags.o-boot, dist-ghc/build/GI/Vte/Flags.dyn_o
)
[ 6 of 19] Compiling GI.Vte.Flags ( GI/Vte/Flags.hs,
dist-ghc/build/GI/Vte/Flags.o, dist-ghc/build/GI/Vte/Flags.dyn_o )
[ 7 of 19] Compiling GI.Vte.Functions ( GI/Vte/Functions.hs,
dist-ghc/build/GI/Vte/Functions.o,
dist-ghc/build/GI/Vte/Functions.dyn_o )
[ 8 of 19] Compiling GI.Vte.Objects.Pty[boot] (
GI/Vte/Objects/Pty.hs-boot, dist-ghc/build/GI/Vte/Objects/Pty.o-boot,
dist-ghc/build/GI/Vte/Objects/Pty.dyn_o )
[ 9 of 19] Compiling GI.Vte.Objects.Pty ( GI/Vte/Objects/Pty.hs,
dist-ghc/build/GI/Vte/Objects/Pty.o,
dist-ghc/build/GI/Vte/Objects/Pty.dyn_o )
[10 of 19] Compiling GI.Vte.Objects.Terminal[boot] (
GI/Vte/Objects/Terminal.hs-boot,
dist-ghc/build/GI/Vte/Objects/Terminal.o-boot,
dist-ghc/build/GI/Vte/Objects/Terminal.dyn_o )
[11 of 19] Compiling GI.Vte.Callbacks ( GI/Vte/Callbacks.hs,
dist-ghc/build/GI/Vte/Callbacks.o,
dist-ghc/build/GI/Vte/Callbacks.dyn_o )
[12 of 19] Compiling GI.Vte.Structs.CharAttributes[boot] (
GI/Vte/Structs/CharAttributes.hs-boot,
dist-ghc/build/GI/Vte/Structs/CharAttributes.o-boot,
dist-ghc/build/GI/Vte/Structs/CharAttributes.dyn_o )
[13 of 19] Compiling GI.Vte.Structs.CharAttributes (
GI/Vte/Structs/CharAttributes.hs,
dist-ghc/build/GI/Vte/Structs/CharAttributes.o,
dist-ghc/build/GI/Vte/Structs/CharAttributes.dyn_o )
[14 of 19] Compiling GI.Vte.Structs.Regex[boot] (
GI/Vte/Structs/Regex.hs-boot,
dist-ghc/build/GI/Vte/Structs/Regex.o-boot,
dist-ghc/build/GI/Vte/Structs/Regex.dyn_o )
[15 of 19] Compiling GI.Vte.Structs.Regex ( GI/Vte/Structs/Regex.hs,
dist-ghc/build/GI/Vte/Structs/Regex.o,
dist-ghc/build/GI/Vte/Structs/Regex.dyn_o )
[16 of 19] Compiling GI.Vte.Structs   ( GI/Vte/Structs.hs,
dist-ghc/build/GI/Vte/Structs.o, dist-ghc/build/GI/Vte/Structs.dyn_o )
[17 of 19] Compiling GI.Vte.Objects.Terminal (
GI/Vte/Objects/Terminal.hs, dist-ghc/build/GI/Vte/Objects/Terminal.o,
dist-ghc/build/GI/Vte/Objects/Terminal.dyn_o )

GI/Vte/Objects/Terminal.hs:1910:1: error:
Could not load module ‘GI.Cairo.Structs.FontOptions’
It is a member of the hidden package ‘gi-cairo-1.0.27’.
Perhaps you need to add ‘gi-cairo’ to the build-depends in your .cabal file.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
 |
1910 | import qualified GI.Cairo.Structs.FontOptions as Cairo.FontOptions
 | ^^
-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 880.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build
--builddir=dist-ghc returned exit"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 610
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup
build --builddir=dist-ghc") called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 473
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup",
"build", "--builddir=dist-ghc") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line
650
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe()
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Bug#1043384: O: pal -- command-line calendar program that can keep track of events

[Bastian Germann]

Package: wnpp

The last maintainer upload was in 2011, so I am orphaning libranlip now.
Please only consider adopting the package if you have the time and 
skills to maintain it.


Description: command-line calendar program that can keep track of events
pal is a command-line calendar program for Unix/Linux systems that can 
keep track of events. It has similarities with the Unix cal command, the 
more complex GNU gcal program, and the calendar program distributed with 
the BSDs.

Bug#1043383: python-pcre: depends on obsolete pcre3 library

[Bastian Germann]

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

Dear maintainer,

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


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

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

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

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

A possible replacement for your package is at
https://github.com/grtetrault/pcre2.py

Thanks,
Bastian

Bug#1043382: RM: doscan -- RoQA; low popcon; unmaintained; RC-buggy (depends on pcre3)

[Bastian Germann]

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

Please remove doscan. The package has a low popcon. It is unmaintained 
upstream and the last maintainer upload was in 2014. The RC bug is not 
expected to be solved, so the package should be removed.

Bug#1041488: Please review patches for initial upload

[tony mancill]

Hello Elias,

On Mon, Jul 24, 2023 at 10:41:02PM +0200, Elias Oltmanns wrote:
> Am 21. Juli 2023 um 08:08 schrieb tony mancill:
> [...]
> 
> Contacting archive.org and asking for license clarification might be an
> option. I am not sure whether I would hold my breath, but it seems to me
> that removing the files in question might turn out to be the only
> alternative. Then again, we could disable the test suite, after all, so
> the build would not depend on the presence of those files.

I intend to remove files for which we don't have clear licenses from the
DFSG repacked tarball and disable the tests that depend upon them.
Apologies for the delay here - it will be a few days yet before I will
have the package for an upload.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1041966: conky-all: unkown variable '$journal'

[Vincent Cheng]

Control: tag -1 + confirmed help

On Tue, Jul 25, 2023 at 4:18 AM Marco Herrn  wrote:
>
> Package: conky-all
> Version: 1.18.3-1
> Severity: normal
>
> According to the package description this package provides support for
> systemd journal:
>
> “
>  This is a full conky with most compile options enabled:
>  .
>  Wayland, X11, XDamage, XDBE, Xft, MPD, MOC, math, hddtemp, portmon, RSS,
>  Weather, wireless, IBM, nvidia, eve-online, Imlib2,
>  apcupsd, I/O stats, argb, Lua and the cairo and imlib2 Lua bindings,
>  Audacious, PulseAudio, iCal, iconv, IRC, and systemd journal.
> ”
>
> Also the manpage lists “journal” as a known variable:
>
> “
>journal lines (type)
>   Displays  last N lines of the systemd journal.  The optional 
> type can be `user' or `system' which will show only the user or system 
> journal respectively.  By
>   default, all journal lines visible to the user are shown.  A 
> maximum of 200 lines can be displayed, or until the text buffer is filled.
> ”
>
> However, using this variable in the config file leads to the message
>
> “conky: unknown variable '$journal'”
>
> and conky itself displays the text
>
> “${journal}”

For anyone following along with this bug report, I could use some help
figuring out where the problem lies (a patch would be even better!).
Both conky-{std,all} are built with -DBUILD_JOURNAL=ON (can be
confirmed from the build log) and src:conky has a build-dep on
libsystemd-dev (which does have the necessary pkg-config files).
However cmake doesn't seem to actually be able to find libsystemd. I'm
not sure what's going on here.

Regards,
Vincent

Bug#1034853: ares: Fullscreen not working with XFCE

[jsupertoot]

Dear Maintainer,

This seems to be resolved with the upgrade to 132-1.

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

[Alexis Murzeau]

Hi,

On 09/08/2023 09:24, Jeroen Ploemen wrote:

Hi Alexis,

thanks for updating the pkg to the latest release. Only one minor
issue came up during review:

* copyright: info for src/streamlink/webbrowser/cdp/connection.py is
   missing; see the notice starting at line 109 of that file.


Thanks for your review.

I've fixed it by adding the missing copyright to d/copyright and updated 
the package on mentors.


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



OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1042025: thrift: FTBFS: dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

[GCS]

Control: forwarded -1 https://issues.apache.org/jira/browse/THRIFT-5680

Hi Christoph,

On Wed, Aug 9, 2023 at 8:27 PM Christoph Berg  wrote:
> > > (./testapplicationexception:892843): GLib-CRITICAL **: 07:16:59.134: Did 
> > > not see expected message GLib-GObject-WARNING **: value*out of range*type*
> > > not ok /testapplicationexception/Properties/test - 
> > > GLib-GObject-FATAL-CRITICAL: value "-1" of type 'gint' is invalid or out 
> > > of range for property 'type' of type 'gint'
> > > Bail out!
[...]
> Fwiw, there is a new 0.18.1 upstream version. Perhaps that works
> better.
 It is already packaged for experimental and has the same build
problem. Upstream knows this bug [1], assigned major priority to it
but has not touched the issue since february.

Regards,
Laszlo/GCS
[1] https://issues.apache.org/jira/browse/THRIFT-5680

Bug#1041439: zchunk: backport to bookworm

[Bastian Germann]

Hi Peter,

On Tue, 18 Jul 2023 23:34:28 +0200 Bastian Germann  wrote:

Am 18.07.23 um 23:24 schrieb Peter Pentchev:
> However, would you be terribly upset if I did the backport myself?

I would actually prefer that. Thanks!


Any chance of backporting soon?

Thanks,
Bastian

Bug#1043381: amd64-microcode: Followups for 4th Gen AMD EPYC processors for CVE-2023-20569 / AMD Inception

[Salvatore Bonaccorso]

Source: amd64-microcode
Version: 3.20230719.1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20230414.1
Control: found -1 3.20230719.1~deb12u1  
Control: found -1 3.20191218.1
Control: found -1 3.20230719.1~deb11u1

Hi Henrique,

From
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html
we did fortunately covered the 3rd Gen AMD EPYC processors microcode
updates for CVE-2023-20569 already with the previous done update:

amd64-microcode (3.20230719.1) unstable; urgency=high

  * Update package data from linux-firmware 20230625-39-g59fbffa9:
* Fixes for CVE-2023-20593 "Zenbleed" on AMD Zen2 processors
  (closes: #1041863)
* New Microcode patches:
  + Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a8
* Updated Microcode patches:
  + Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a
  + Family=0x19 Model=0x01 Stepping=0x00: Patch=0x0a001079
  + Family=0x19 Model=0x01 Stepping=0x01: Patch=0x0a0011d1
  + Family=0x19 Model=0x01 Stepping=0x02: Patch=0x0a001234
  * README: update for new release

 -- Henrique de Moraes Holschuh   Mon, 24 Jul 2023 13:07:34 
-0300

(and so in {bookworm,bullseye,buster}-security as well).

There was a microcode followup today as
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f2eb058afc57348cde66852272d6bf11da1eef8f
which followups for the 4th Gen AMD EPYC processors, Genoa
(Family=0x19 Model=0x11) and Bergamo (Family=0x19 Model=0xa0).

Regards,
Salvatore

Bug#1043380: RM: f-irc -- RoQA; RC-buggy; dead upstream; unmaintained; low popcon

[Bastian Germann]

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

Please remove f-irc. It is trivially RC-buggy for a long time and thus 
did not make it to bookworm. It is dead upstream and I cannot even find 
mirrors other than Debian/Ubuntu that provide the package.


The last maintainer upload was in 2014 and the package has a low popcon.

Bug#1042025: thrift: FTBFS: dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

[Christoph Berg]

Re: Lucas Nussbaum
> Version: 0.17.0-2

> > (./testapplicationexception:892843): GLib-CRITICAL **: 07:16:59.134: Did 
> > not see expected message GLib-GObject-WARNING **: value*out of range*type*
> > not ok /testapplicationexception/Properties/test - 
> > GLib-GObject-FATAL-CRITICAL: value "-1" of type 'gint' is invalid or out of 
> > range for property 'type' of type 'gint'
> > Bail out!
> > /bin/bash: line 6: 892843 Trace/breakpoint trap   ${dir}$tst
> > FAIL: testapplicationexception
> > TAP version 13
> > # random seed: R02Sdadbad636988fc61fb41629b59ecfdd6

Fwiw, there is a new 0.18.1 upstream version. Perhaps that works
better.

Christoph

Bug#1043378: bookworm-pu: package icingaweb2/2.11.4-2+deb12u1

[Bas Couwenberg]

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

[ Reason ]
The php8.2.patch in icingaweb2 (2.11.4-2) does not cover all the code paths.

The web setup, icingacli, and MySQL/MariaDB support are some examples users ran 
into.

Especially the many Deprecated notices in the web setup cause significant 
hindrance.

[ Impact ]
Deprecated notices that hinder usability.

[ Tests ]
The patch was manually tested with icingacli.

[ Risks ]
Suppressing the Deprecated notices in the error_reporting() calls should be 
very low risk in a stable release where PHP 8.3 won't be introduced in the 
future like unstable.

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

[ Changes ]
The branch needs to be updated to keep git-buildpackage and debcheckout working.

The patch is required to suppress the remaining Deprecated notices that were 
not fixed by php8.2.patch.

[ Other info ]
N/A

Kind Regards,

Bas
diff -Nru icingaweb2-2.11.4/debian/changelog icingaweb2-2.11.4/debian/changelog
--- icingaweb2-2.11.4/debian/changelog  2023-01-28 07:18:34.0 +0100
+++ icingaweb2-2.11.4/debian/changelog  2023-08-09 19:45:18.0 +0200
@@ -1,3 +1,12 @@
+icingaweb2 (2.11.4-2+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * Update branch in gbp.conf & Vcs-Git URL.
+  * Add patch to suppress Deprecated notices.
+(closes: #1037925)
+
+ -- Bas Couwenberg   Wed, 09 Aug 2023 19:45:18 +0200
+
 icingaweb2 (2.11.4-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru icingaweb2-2.11.4/debian/control icingaweb2-2.11.4/debian/control
--- icingaweb2-2.11.4/debian/control2023-01-18 17:28:15.0 +0100
+++ icingaweb2-2.11.4/debian/control2023-08-09 19:45:18.0 +0200
@@ -8,7 +8,7 @@
php-cli
 Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/nagios-team/icingaweb2
-Vcs-Git: https://salsa.debian.org/nagios-team/icingaweb2.git
+Vcs-Git: https://salsa.debian.org/nagios-team/icingaweb2.git -b bookworm
 Homepage: https://icinga.com
 Rules-Requires-Root: no
 
diff -Nru icingaweb2-2.11.4/debian/gbp.conf icingaweb2-2.11.4/debian/gbp.conf
--- icingaweb2-2.11.4/debian/gbp.conf   2022-07-01 20:21:56.0 +0200
+++ icingaweb2-2.11.4/debian/gbp.conf   2023-08-09 19:45:18.0 +0200
@@ -6,7 +6,7 @@
 
 # The default name for the Debian branch is "master".
 # Change it if the name is different (for instance, "debian/unstable").
-debian-branch = master
+debian-branch = bookworm
 
 # git-import-orig uses the following names for the upstream tags.
 # Change the value if you are not using git-import-orig
diff -Nru icingaweb2-2.11.4/debian/patches/error_reporting.patch 
icingaweb2-2.11.4/debian/patches/error_reporting.patch
--- icingaweb2-2.11.4/debian/patches/error_reporting.patch  1970-01-01 
01:00:00.0 +0100
+++ icingaweb2-2.11.4/debian/patches/error_reporting.patch  2023-08-09 
19:45:18.0 +0200
@@ -0,0 +1,27 @@
+Description: Suppress Deprecated notices, upstream doesn't support PHP 8.2 yet.
+Author: Bas Couwenberg 
+Bug: https://github.com/Icinga/icingaweb2/issues/4918
+Bug-Debian: https://bugs.debian.org/1037925
+
+--- a/library/Icinga/Application/ApplicationBootstrap.php
 b/library/Icinga/Application/ApplicationBootstrap.php
+@@ -591,7 +591,7 @@ abstract class ApplicationBootstrap
+  */
+ protected function setupErrorHandling()
+ {
+-error_reporting(E_ALL | E_STRICT);
++error_reporting(E_ALL & ~E_DEPRECATED | E_STRICT);
+ ini_set('display_startup_errors', 1);
+ ini_set('display_errors', 1);
+ set_error_handler(function ($errno, $errstr, $errfile, $errline) {
+--- a/library/Icinga/Application/webrouter.php
 b/library/Icinga/Application/webrouter.php
+@@ -8,7 +8,7 @@ use Icinga\Web\Controller\StaticControll
+ use Icinga\Web\JavaScript;
+ use Icinga\Web\StyleSheet;
+ 
+-error_reporting(E_ALL | E_STRICT);
++error_reporting(E_ALL & ~E_DEPRECATED | E_STRICT);
+ 
+ if (isset($_SERVER['REQUEST_URI'])) {
+ $ruri = $_SERVER['REQUEST_URI'];
diff -Nru icingaweb2-2.11.4/debian/patches/series 
icingaweb2-2.11.4/debian/patches/series
--- icingaweb2-2.11.4/debian/patches/series 2022-12-05 09:30:57.0 
+0100
+++ icingaweb2-2.11.4/debian/patches/series 2023-08-09 19:45:18.0 
+0200
@@ -1 +1,2 @@
 php8.2.patch
+error_reporting.patch

Bug#1043379: O: libranlip -- generates random variates with multivariate Lipschitz density

[Bastian Germann]

Package: wnpp

The last maintainer upload was in 2006, so I am orphaning libranlip now.
Please only consider adopting the package if you have the time and 
skills to maintain it.


RanLip generates random variates with an arbitrary multivariate 
Lipschitz density.

Bug#1037925: [Pkg-nagios-devel] Bug#1037925: deprication warnings

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 8/9/23 19:15, Olaf Stenzel wrote:
the reported deprecation warnings are enabled by the application 
bootstrap and overrides the php.ini defaults.


The attached patch solves this problem.


While I'm not in favor of suppressing the Deprecated notices, I also 
cannot find the motivation to further patch icingaweb2 to fix code paths 
I don't use like setup & mysql, let's do it anyway to get this issue 
resolved in bookworm. It's going to byte us in the future, but we'll 
cross that bridge when we get there.


Kind Regards,

Bas

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

Bug#1043377: sopt: FTBFS during tests on mips64el -- communicator (SEGFAULT)

[Bastian Germann]

Source: sopt
Version: 3.0.1+dfsg-2
Severity: serious

On mips64el, a test fails due to a segfault:

test 19
  Start 19: communicator

19: Test command: /usr/bin/mpiexec "-n" "1" 
"/<>/obj-mips64el-linux-gnuabi64/cpp/tests/test_communicator"
19: Working Directory: 
/<>/obj-mips64el-linux-gnuabi64/cpp/tests

19: Test timeout computed to be: 1000
17: [2023-08-09 15:28:13.169] [sopt] [debug] Starting bisection method 
over x ∈ [-1.5, 0], to estimate f(x) = 1
17: [2023-08-09 15:28:13.170] [sopt] [debug] Starting bisection method 
over x ∈ [0, 1.5], to estimate f(x) = 1
17: [2023-08-09 15:28:13.258] [sopt] [debug] Starting calculation of 
credible interval: 8 x 8 grid.
17: [2023-08-09 15:28:13.258] [sopt] [debug] Grid pixel (0, 0): [0, 16) 
x [0, 16)
17: [2023-08-09 15:28:13.266] [sopt] [debug] Starting bisection method 
over x ∈ [-16384, 0], to estimate f(x) = 1

19: [mipsel-osuosl-03:2434331] *** Process received signal ***
19: [mipsel-osuosl-03:2434331] Signal: Segmentation fault (11)
19: [mipsel-osuosl-03:2434331] Signal code: Address not mapped (1)
19: [mipsel-osuosl-03:2434331] Failing at address: (nil)
19: [mipsel-osuosl-03:2434331] *** End of error message ***
16/22 Test #19: communicator .***Exception: SegFault 
 0.23 sec

[mipsel-osuosl-03:2434331] *** Process received signal ***
[mipsel-osuosl-03:2434331] Signal: Segmentation fault (11)
[mipsel-osuosl-03:2434331] Signal code: Address not mapped (1)
[mipsel-osuosl-03:2434331] Failing at address: (nil)
[mipsel-osuosl-03:2434331] *** End of error message ***

Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry

[Victor Westerhuis]

"Jakub Ružička"  schreef op 9 augustus 2023 17:11:15 CEST:
>On 23-08-09 15:08, Colin Watson wrote:
>> How will this sort of thing work when a git tree isn't necessarily
>> available at binary package build time, since buildds build binary
>> packages from a source package rather than directly from git and the
>> source package doesn't usually include a git tree?  Is it just a matter
>> of causing the plugin to exist so that pybuild doesn't fail, but in
>> practice the version is still going to be set by something that's
>> actually in the source package?
>
>A primary objective is to provide the plugin so that
>
>python3 -m build
>
>works in general, not limited to package builds.
>
>Supporting pybuild correctly out of the box for projects using the plugin is
>a next step.
>
>I'm not sure how it will behave when no VCS is available as in source package.
>
>IIRC it replaces version in pyproject.toml during build. So possibly
>a mechanism that does the same during package build but from d/changelog
>version might solve this... Hmmm, sounds non-trivial.
>
>This will certainly require some testing.
>

There are already some workarounds for other similar tools in pybuild.pm, so 
that would be the place to add this workaround as well, if necessary. 

See the current examples at 
https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dh/pybuild.pm#L125-151
-- 
Groet, Regards,

Victor Westerhuis
-- 
Groet, Regards,

Victor Westerhuis

Bug#1043376: O: libjama -- C++ Linear Algebra Package

[Bastian Germann]

Package: wnpp

Am 09.08.23 um 18:44 schrieb Vagrant Cascadian:
Given the last maintainer upload was in 2006 ... seems like this package 
should maybe be orphaned?


I am orphaning libjama as suggested by Vagrant.
Please only adopt the package if you can afford the time and have the 
skills to maintain it.


Description: C++ Linear Algebra Package
 JAMA/C++ was adapted for The Template Numerical Toolkit (TNT) from
 JAMA, a Java Matrix Library, developed jointly by the Mathworks and
 NIST. See http://math.nist.gov/javanumerics/jama for more information.

 TNT is a collection of interfaces and reference implementations of
 numerical objects useful for scientific computing in C++. The toolkit
 defines interfaces for basic data structures, such as multidimensional
 arrays and sparse matrices, commonly used in numerical applications.
 The goal of this package is to provide reusable software components
 that address many of the portability and maintenance problems with C++
 codes.

 TNT provides a distinction between interfaces and implementations of
 TNT components. For example, there is a TNT interface for
 two-dimensional arrays which describes how individual elements are
 accessed and how certain information, such as the array dimensions, can
 be used in algorithms; however, there can be several implementations of
 such an interface: one that uses expression templates, or one that uses
 BLAS kernels, or another that is instrumented to provide debugging
 information. By specifying only the interface, applications codes may
 utilize such algorithms, while giving library developers the greatest
 flexibility in employing optimization or portability strategies.

Bug#1043375: Subject: ITP: shards -- dependency manager for the Crystal language

[David Suarez]

Package: wnpp
Owner: David Suárez 
Severity: wishlist

* Package name: shards
  Version : 0.17.3
  Upstream Author : Julien Portalier
* URL : http://crystal-lang.org/
* License : Apache-2.0
  Programming Lang: Crystal
  Description : dependency manager for the Crystal language


 Shards is the dependency manager for the Crystal programming language.
 .
 It manages dependencies for Crystal projects and libraries with reproducible
 installs across computers and systems.

The project's sources are hosted on GitHub [0].

Why?

We love Ruby's efficiency for writing code.
We love C's efficiency for running code.
We want the best of both worlds.
We want the compiler to understand what we mean without having to
specify types everywhere.
We want full OOP.
Oh, and we don't want to write C code to make the code run faster.


Links:
  [0] https://github.com/crystal-lang/shards

Bug#1037925: deprication warnings

[Olaf Stenzel]

Hello,

the reported deprecation warnings are enabled by the application 
bootstrap and overrides the php.ini defaults.


The attached patch solves this problem.

cheers
Olaf--- /usr/share/php/Icinga/Application/ApplicationBootstrap.php.orig	2023-01-26 12:54:15.0 +0100
+++ /usr/share/php/Icinga/Application/ApplicationBootstrap.php	2023-08-09 19:03:20.750101741 +0200
@@ -591,7 +591,7 @@
  */
 protected function setupErrorHandling()
 {
-error_reporting(E_ALL | E_STRICT);
+error_reporting(E_ALL & ~E_DEPRECATED | E_STRICT);
 ini_set('display_startup_errors', 1);
 ini_set('display_errors', 1);
 set_error_handler(function ($errno, $errstr, $errfile, $errline) {

Bug#1043374: rust-bindgen: Please update to avoid future LLVM-16 bug

[Andreas Hasenack]

Package: rust-bindgen
Version: 0.60.1-2
Severity: normal

Dear maintainer,

in Ubuntu we are using LLVM-16 already, and I came across an FTBFS[0]
in src:rust-nettle-sys[1] that, after some troubleshooting, showed it
was only failing to build when built with rust-bindgen 0.60.x.

[nettle-sys 2.2.0] thread 'main' panicked at
'"aes_ctx_union_(unnamed_at_/usr/include/nettle/aes_h_150_3)" is not a
valid Ident', 
/<>/debian/cargo_registry/proc-macro2-1.0.65/src/fallback.rs:791:9

If I remove the src:rust-nettle-sys patch[2] that changes the bindgen
dependency, the build then uses a newer rust-bindgen from upstream
(0.63.0) and works.

Going over upstream's rust-bindgen repository[3] I found a bug[4] that
started manifesting itself with llvm-16, and that's what I'm seeing
when building src:rust-nettle-sys with rust-bindgen 0.60.1. Applying
the patch from the PR[5] linked in that bug report to src:rust-bindgen
and installing the resulting packages fixes the build of
src:rust-nettle-sys.

I would kindly ask to apply that patch in debian's src:rust-bindgen
package, or perhaps updated to rust-bindgen 0.62.0 or higher (latest
version is currently 0.66.1), to avoid problems when Debian moves to
LLVM-16 as default. In Ubuntu, I'll probably apply the patch, to avoid
becoming too different from debian for the time being.

Thanks!


0. https://bugs.launchpad.net/ubuntu/+source/rust-nettle-sys/+bug/2030886
1. https://bugs.launchpad.net/ubuntu/+source/rust-nettle-sys/+bug/2030886
2. 
https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/nettle-sys/debian/patches/0002-Relax-dependency-on-bindgen.patch
3. https://github.com/rust-lang/rust-bindgen
4. https://github.com/rust-lang/rust-bindgen/issues/2312
5. https://github.com/rust-lang/rust-bindgen/pull/2316

Bug#1043373: RM: rust-vhost-user-backend [armel armhf i386 mipsel powerpc sh4 m68k] -- ANAIS; upstream does not support 32bit architectures

[Michael Tokarev]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-vhost-user-back...@packages.debian.org, 
pkg-qemu-de...@lists.alioth.debian.org
Control: affects -1 + src:rust-vhost-user-backend

Upstream does not want to support 32bit architectures, making
use of either wrong code which works on 64bit arches only, or
using features available on 64bit arches oly, in every next
release.  Currently it explicitly uses arrays of AtomicU64
which either does not exist at all (armel) or are too slow.
This is after patching other problem places using d/patches,
which got rejected by the upstream due to lack of interest
in (writing correct code) supporting 32 bits.

Thanks,

/mjt

Bug#1043372: RM: rust-virtiofsd [armel armhf i386 mipsel powerpc sh4 m68k] -- ANAIS; upstream does not support 32bit architectures

[Michael Tokarev]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-virtio...@packages.debian.org, 
pkg-qemu-de...@lists.alioth.debian.org
Control: affects -1 + src:rust-virtiofsd


Upstream does not support 32bit architectures, since
other rust crates this package uses does not, see
https://gitlab.com/virtio-fs/virtiofsd/-/issues/114

I'm filing ANAIS requests for other packages as well.
(virtiofsd is a package without reverse dependencies).

Thanks,

/mjt

Bug#1043200: libjama: please consider upgrading to 3.0 source format

[Vagrant Cascadian]

On 2023-08-07, Bastian Germann wrote:
> Source: libjama
> Version: 1.2.4-2.3
> Severity: wishlist
>
> This package is among the few that still use source format 1.0.
> Please upgrade it to source format 3.0:
> https://wiki.debian.org/Projects/DebSrc3.0

Given the last maintainer upload was in 2006 ... seems like this package
should maybe be orphaned?

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1035314: cron:i386 : PreDepends: cron-daemon-common:i386 but it is not installable

[Alexandre Detiste]

Hi,

Maybe should package "cron-daemon-common"
also be marked "Multi-Arch: foreign" ?

Greetings

Bug#1036004:

[Nathan Schulte]

Control: fixed 6.5~rc4-1~exp1

Bug#1043371: RM: golang-github-elisescu-pty -- RoQA; unnecessary fork, changes have been merged back

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-github-elisescu-...@packages.debian.org, z...@debian.org
Control: affects -1 + src:golang-github-elisescu-pty


No reverse dependency. Changes have been merged in golang-github-creack-pty-dev.

Bug#1043370: RFS: odr-dabmod/2.6.0-2 -- DAB modulator compliant to ETSI EN 300 401

[Robin Alexander]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "odr-dabmod" (dab/dab+
modulator) which belongs to the Opendigitalradio DAB/DAB+ broadcasting
chain:

 * Package name : odr-dabmod
   Version  : 2.6.0-2
   Upstream contact : Matthias P. Braendli 
 * URL  : https://www.opendigitalradio.org/mmbtools
 * License  : FSFAP, LGPL-3, GPL-3.0+, Expat, Apache-2.0, BSD-
3-Clause, GPL-2.0+, GPL-3.0+ with autoconf exception, GPL-2+ with
Autoconf-data exception, EXPAT
 * Vcs  : https://salsa.debian.org/ralex/odr-dabmod
   Section  : hamradio

The source builds the following binary packages:

  odr-dabmod - DAB modulator compliant to ETSI EN 300 401

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

  https://mentors.debian.net/package/odr-dabmod/

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/odr-dabmod/odr-dabmod_2.6.0-2.dsc

Changes for the initial release:

 odr-dabmod (2.6.0-2) unstable; urgency=low
 .
   * Do not report specific packages in the Depends section

Thank you very much in advance for your support,



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

Bug#1043233: exim4-base: On-connect auto-generated self-signed certificates have expired end date

[Andreas Metzler]

Control: tags -1 confirmed
Control: found -1  4.95~RC0-1
Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=3014
Control: tags -1 patch

On 2023-08-07 Björn Wiberg  wrote:
> Package: exim4-base
> Version: 4.96-15+deb12u1
> Severity: normal

> Hello,

> When using built-in on-connect auto-generated self-signed certificates
> (i.e., not installing "real" SSL/TLS certificates), the ones that are
> auto-generated appear to have a date in the past (1970-01-01 02:00:00
> UTC) as their end date:
 [...]
>  - subject `CN=glimmer.localdomain,O=Exim Developers,C=UK', issuer 
> `CN=glimmer.localdomain,O=Exim Developers,C=UK', serial 0x0100, 
> RSA key 3072 bits, signed using RSA-SHA256, activated `2023-08-07 17:40:16 
> UTC', expires `1970-01-01 02:00:00 UTC', 
> pin-sha256="40P5jkI8FD97/oh+CYdi4BJH1nfhpfk0BFH/25j3yK4="

Thank you, that broke during 4.95 development.

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

Bug#1043314: libnftnl: please disable documentation build when not building -doc package

[Jeremy Sowden]

Control: tags -1 + pending

On 2023-08-09, at 14:00:40 +0100, Jeremy Sowden wrote:
> On 2023-08-09, at 00:12:00 +0100, Simon McVittie wrote:
> > Source: libnftnl
> > Version: 1.2.6-1
> > Severity: wishlist
> > Tags: patch
> > 
> > Similar to libnetfilter-conntrack, libnftnl only needs graphviz (and
> > doxygen) for its API documentation, so an easy way to reduce
> > dependency chains would be for libnetfilter-conntrack to only build
> > its API documentation when "Architecture: all" packages are being
> > built.
> > 
> > Please consider the attached patch, with the "Closes" line amended
> > to mention this bug report's bug number. I used diffoscope to
> > confirm that this change does not alter the contents of either the
> > _amd64 or _all binary packages.
> 
> No problem.  I'm working through the nf libs that I help maintain.
> I'll do this one next.

This is ready for upload when you have a minute, Arturo.

J.


signature.asc
Description: PGP signature

Bug#1043299: xterm: build with ReGIS support

[Sven Joachim]

On 2023-08-08 14:33 -0400, Benjamin Barenblat wrote:

> Package: xterm
> Version: 384-1
> Severity: wishlist
>
> Xterm supports ReGIS (DEC vector graphics) emulation, but it’s not
> compiled in by default. Would you be willing to add
> `--enable-regis-graphics` to the `configure` invocation in debian/rules?

Not yet.  As Thomas said, ReGIS graphics support is experimental, and I
count some 150 reasons for this assessment.

$ grep -c FIXME graphics_regis.c
149

Cheers,
   Sven

Bug#1043368: kokkos FTBFS with gcc 13

[Adrian Bunk]

Source: kokkos
Version: 3.7.01-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=kokkos=riscv64=3.7.01-2=1691576293=0
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/kokkos.html

...
/<>/core/src/impl/Kokkos_MemoryPool.cpp:116:48: error: ‘uint32_t’ 
has not been declared
  116 | void _print_memory_pool_state(std::ostream& s, uint32_t const* 
sb_state_ptr,
  |^~~~
/<>/core/src/impl/Kokkos_MemoryPool.cpp:117:49: error: ‘uint32_t’ 
has not been declared
  117 |   int32_t sb_count, uint32_t sb_size_lg2,
  | ^~~~
/<>/core/src/impl/Kokkos_MemoryPool.cpp:118:31: error: ‘uint32_t’ 
has not been declared
  118 |   uint32_t sb_state_size, uint32_t 
state_shift,
  |   ^~~~
/<>/core/src/impl/Kokkos_MemoryPool.cpp:118:55: error: ‘uint32_t’ 
has not been declared
  118 |   uint32_t sb_state_size, uint32_t 
state_shift,
  |   ^~~~
/<>/core/src/impl/Kokkos_MemoryPool.cpp:119:31: error: ‘uint32_t’ 
has not been declared
  119 |   uint32_t state_used_mask) {
  |   ^~~~
...

Bug#1043367: thunderbird 115.1 is unresponsive

[Debian/GNU]

Package: thunderbird
Version: 1:115.1.0-1
Severity: important

Dear Maintainer,

after upgrading thunderbird to 1:115.1.0-1, it has become unusable.

starting works nicely and i get the password prompt, after which the
main screen is shown.

however, the window is totally unresponsive, and thunderbird works
happily at 100% for hours.

my system is not super-new, but not that old either:
```
$ lscpu
Architecture:x86_64
  CPU op-mode(s):32-bit, 64-bit
  Address sizes: 39 bits physical, 48 bits virtual
  Byte Order:Little Endian
CPU(s):  8
  On-line CPU(s) list:   0-7
Vendor ID:   GenuineIntel
  Model name:Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
CPU family:  6
Model:   158
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):   1
Stepping:9
CPU(s) scaling MHz:  50%
CPU max MHz: 4200.
CPU min MHz: 800.
BogoMIPS:7200.00
[...]

$ cat /proc/meminfo
MemTotal:   32783544 kB
[...]

$ lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1080] 
(rev a1)
[...]

$ df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  202G  183G  9.2G  96% /
[...]

$
```

As you can see i'm slightly tight on disk space (and my ~/.thunderbird/
folder takes about 5.2GB), but i *think* this should be a usable setup.

of course, thunderbird_115 upgraded my profile, so i can no longer
downgrade to the thunderbird from bookworm :-(

dfmasr
IOhannes



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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.8-1
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.9-1
ii  libatk1.0-0  2.49.90-2
ii  libc62.37-7
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.8-2
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.13.0+dfsg-1
ii  libgcc-s113.2.0-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.77.1-2
ii  libgtk-3-0   3.24.38-2
ii  libicu72 72.1-3
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.91-1
ii  libotr5  4.1.1-5
ii  libpango-1.0-0   1.50.14+ds-1
ii  librnp0  0.16.3-1
ii  libstdc++6   13.2.0-1
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zenity   3.44.0-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2

Versions of packages thunderbird suggests:
ii  apparmor  3.0.8-3
ii  fonts-lyx 2.3.7-1
ii  libgssapi-krb5-2  1.20.1-2

-- no debconf information

Bug#981323: override: usbutils:utils/standard

[t18tt3+eywx8zyq2qrw4]

Package: ftp.debian.org
Followup-For: Bug #981323

I don't know the history of this, but I can provide a reproducer.

If you install debian bookworm using the netinstall cd on a qemu virtual 
machine that does not have the -usb option, then usbutils is not installed.

If you install debian bookworm using the netinstall cd on a qemu virtual 
machine that has the -usb option, then usbutils is installed.

The bugreport might therefore be more suited for d-i then.

Bug#1043366: O: libgcr410 -- PC/SC driver for GemPlus GCR410 serial SmartCard interface

[Bastian Germann]

Package: wnpp

libgcr410 is obviously not maintained anymore. I am hereby orphaning the 
package.
I doubt that it is still of use today but if you have any use for it, please 
consider adopting.

Description: PC/SC driver for GemPlus GCR410 serial SmartCard interface
 The libgcr410 package contains a PC/SC driver for the GemPlus GCR410 serial
 SmartCard interface. Note that this is a different driver then libgempc.
 If you have a GemPC 410 reader, this driver is not for you.

Bug#1043365: sendxmpp: Add support for modern SASL authentication (add libauthen-sasl-scram-perl dependency)

[Erik Hulsmann]

Package: sendxmpp
Severity: normal

Dear Maintainer,

Hardly any XMPP server is configured to allow the SASL mechanisms that
Authen::SASL comes with out-of-the-box. Servers typically enable SCRAM-SHA-1
and SCRAM-SHA-256.

To support these mechanisms, Authen::SASL::SCRAM was developed and recently
accepted into Debian. To make sendxmpp usable this day and age, please
libauthen-sasl-scram-perl a required (or at least a recommended) dependency.

Thank you.


Erik.


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

Kernel: Linux 6.2.0-10018-tuxedo (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 sendxmpp depends on:
pn  libnet-xmpp-perl  
ii  perl  5.34.0-3ubuntu1.2

sendxmpp recommends no packages.

sendxmpp suggests no packages.

Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry

[Jakub Ružička]

On 23-08-09 15:08, Colin Watson wrote:
> How will this sort of thing work when a git tree isn't necessarily
> available at binary package build time, since buildds build binary
> packages from a source package rather than directly from git and the
> source package doesn't usually include a git tree?  Is it just a matter
> of causing the plugin to exist so that pybuild doesn't fail, but in
> practice the version is still going to be set by something that's
> actually in the source package?

A primary objective is to provide the plugin so that

python3 -m build

works in general, not limited to package builds.

Supporting pybuild correctly out of the box for projects using the plugin is
a next step.

I'm not sure how it will behave when no VCS is available as in source package.

IIRC it replaces version in pyproject.toml during build. So possibly
a mechanism that does the same during package build but from d/changelog
version might solve this... Hmmm, sounds non-trivial.

This will certainly require some testing.

Bug#1041443: issue at meson-python

[Jerome Kieffer]

Hi,

Apparently this bug comes from the tool used to build the source package: 
"meson-python" ... it does not set properly timestamps in the source archive.
https://github.com/mesonbuild/meson-python/issues/450

Cheers,

Jerome

Bug#1043291: mate-tweak: can't change MATE panel layout by mate-tweak because of missed mate-volume-control-applet executable

[Norbert]

Thanks, Mike!

The problem here is caused by `mate-volume-control-applet` file location.
It came from `mate-media`, you are right about this package
Problem persists even with the installed `mate-media` package.
In Debian 10 (buster) it was located in PATH -
`/usr/bin/mate-volume-control-applet` (see
https://packages.debian.org/search?suite=buster=any=path=contents=mate-volume-control-applet
).
But in Debian 11 and newer it is located in non-PATH place -
`/usr/libexec/mate-volume-control-applet` (see
https://packages.debian.org/search?suite=bullseye=any=path=contents=mate-volume-control-applet).
So it can't be found by `mate-tweak` (see
https://sources.debian.org/src/mate-tweak/22.10.0-2/mate-tweak/?hl=78#L571
).

My local quick and dirty hack is the following:
```
sudo ln -sf /usr/libexec/mate-volume-control-applet
/usr/local/bin/mate-volume-control-applet
```

But I would suggest fixing this problem in the `mate-tweak` script - for
example you can call this applet by full path -
`/usr/libexec/mate-volume-control-applet`.
It is still applicable for default Debian installation without Ayatana
indicators.

Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry

[Colin Watson]

On Wed, Aug 09, 2023 at 04:16:29PM +0200, Jakub Ružička wrote:
> * Package name: python-poetry-dynamic-versioning
>   Version : 0.25.0
>   Upstream Contact: Matthew T. Kennerly 
> * URL : https://github.com/mtkennerly/poetry-dynamic-versioning
> * License : Expat
>   Programming Lang: Python
>   Description : dynamic versioning plugin for Poetry
> 
> This is a Python plugin for Poetry and Poetry Core to enable dynamic
> versioning based on tags in your version control system, powered by Dunamai.
> Many different version control systems are supported, including Git and
> Mercurial.
> 
> 
> Poetry is very popular in the Python world and this plugin makes it easy to
> use dynamic versioning in Poetry-managed projects.
> 
> Having this in Debian is a prerequisite for packaging of any projects using
> poetry-dynamic-versioning. Some of existing packages require this in order to
> update to latest upstream version which started using the plugin.

How will this sort of thing work when a git tree isn't necessarily
available at binary package build time, since buildds build binary
packages from a source package rather than directly from git and the
source package doesn't usually include a git tree?  Is it just a matter
of causing the plugin to exist so that pybuild doesn't fail, but in
practice the version is still going to be set by something that's
actually in the source package?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1043364: mutt-wizard: missing dependency on procps for /usr/bin/pgrep

[Jonathan Dowland]

Package: mutt-wizard
Version: 3.3.1-2
Severity: important
Tags: patch

/usr/bin/mw-mailsync: 15: pgrep: not found

pgrep is provided by procps which is not an essential package, so
mutt-wizard must depend upon it.

Patch at
.

I was fully expecting Salsa to arrange to Fork the repository and create
a Merge Request for that patch, but it did not, instead it committed it
directly to master.


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

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

Versions of packages mutt-wizard depends on:
ii  curl   7.88.1-10
ii  isync  1.4.4-5
ii  msmtp  1.8.23-1
ii  neomutt20220429+dfsg1-4.1
ii  pass   1.7.4-6
ii  xdg-utils  1.1.3-4.1

Versions of packages mutt-wizard recommends:
ii  abook0.6.1-2+b1
ii  cron 3.0pl1-162
ii  lynx 2.9.0dev.12-1
ii  notmuch  0.37-1+b1
ii  urlview  0.9-23.1

Versions of packages mutt-wizard suggests:
pn  links2   
pn  mpop 
ii  mpv  0.35.1-4
ii  w3m  0.5.3+git20230121-2
pn  zathura  

-- no debconf information

-- 
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#1043363: ganglia-webfrontend: not compatible with PHP 8

[Rike-Benjamin Schuppner]

Package: ganglia-webfrontend
Version: 3.7.5+debian-4
Severity: important
Tags: upstream

Dear Maintainer,

as mentioned in upstream bug reports [1], the ganglia-webfrontend
package is currently incompatible with PHP 8.

When run on bookworm, Apache logs the error:

PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to
function ganglia_api_error_handler(), 4 passed in
/usr/share/ganglia-webfrontend/graph.php on line 1615 and exactly 5
expected in
/usr/share/ganglia-webfrontend/lib/common_api.php:18\nStack
trace:\n#0 /usr/share/ganglia-webfrontend/graph.php(1615):
ganglia_api_error_handler()\n#1 {main}\n  thrown in
/usr/share/ganglia-webfrontend/lib/common_api.php on line 18

While it may still work with an older version of PHP, it is out of the
box unusable on Debian bookworm.

Best
/rike-benjamin schuppner

[1]: https://github.com/ganglia/ganglia-web/issues/361


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

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

Versions of packages ganglia-webfrontend depends on:
ii  apache2 [httpd-cgi] 2.4.57-2
ii  libapache2-mod-php  2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  libapache2-mod-php8.1 [libapac  8.1.21-1+0~20230716.45+debian12~1.gbpbeb527
he2-mod-php]
ii  libapache2-mod-php8.2 [libapac  8.2.7-1~deb12u1
he2-mod-php]
ii  libjs-chosen1.8.7+dfsg-2
ii  libjs-d33.5.17-4
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-cookie 12-4
ii  libjs-jquery-flot   4.2.1+dfsg-6
ii  libjs-jquery-jstree 3.3.12+dfsg1-2
ii  libjs-jquery-mobile 1.4.5+dfsg-2
ii  libjs-jquery-scrollto   2.1.3+dfsg-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libjs-jstimezonedetect  1.0.7+~1.0.3-1
ii  libjs-moment2.29.4+ds-1
ii  libjs-moment-timezone   0.5.40+dfsg-1+2023c
ii  libjs-rickshaw  1.5.1.dfsg-5
ii  libjs-select2.js4.0.13+dfsg1-6
ii  php-xml 2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php8.1-xml [php-xml]8.1.21-1+0~20230716.45+debian12~1.gbpbeb527
ii  php8.2-xml [php-xml]8.2.7-1~deb12u1
ii  rrdtool 1.7.2-4+b8

Versions of packages ganglia-webfrontend recommends:
ii  gmetad  3.7.2-6+b2
ii  php-gd  2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php8.1-gd [php-gd]  8.1.21-1+0~20230716.45+debian12~1.gbpbeb527
ii  php8.2-gd [php-gd]  8.2.7-1~deb12u1

ganglia-webfrontend suggests no packages.

-- debconf information:
* ganglia-webfrontend/restart: true
  ganglia-webfrontend/webserver: false

Bug#1043362: mw-mailsync: guard to check for logged in user is flawed

[Jonathan Dowland]

Package: mutt-wizard
Version: 3.3.1-2
Severity: important

The following guard is used towards the top of mw-mailsync:

  pgrep -u "${USER:=$LOGNAME}" >/dev/null || { echo "$USER not logged in; sync will 
not run."; exit ;}

This is inadequate, because USER and LOGNAME might not be defined in the
running environment even if the user is logged in. For example, in a
container context:

  conf=/some/path/to/stick/muttwizard/conf/in
  podman run --rm -ti \
  --mount type=bind,ro=false,chown=true,src=$conf,dst=$HOME \
  mutt-wizard \
  neomutt

(where 'mutt-wizard' is the name of a debian:bookworm container
with mutt-wizard and its dependencies installed.)

Furthermore, the behaviour when this fails - ${USER:=$LOGNAME}
expands to the empty string, so the script invokes
"pgrep -u >/dev/null", which is at least benign and just dumps
the pgrep invocation output on the user's terminal.

(Why run mutt-wizard in a container? To mitigate against it not
isolating its own configuration from any pre-existing configuration
belonging to the user. See:
)





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

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

Versions of packages mutt-wizard depends on:
ii  curl   7.88.1-10
ii  isync  1.4.4-5
ii  msmtp  1.8.23-1
ii  neomutt20220429+dfsg1-4.1
ii  pass   1.7.4-6
ii  xdg-utils  1.1.3-4.1

Versions of packages mutt-wizard recommends:
ii  abook0.6.1-2+b1
ii  cron 3.0pl1-162
ii  lynx 2.9.0dev.12-1
ii  notmuch  0.37-1+b1
ii  urlview  0.9-23.1

Versions of packages mutt-wizard suggests:
pn  links2   
pn  mpop 
ii  mpv  0.35.1-4
ii  w3m  0.5.3+git20230121-2
pn  zathura  

-- no debconf information

--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#1043361: ITP: cronie -- Process Scheduling Daemon

[Lin Qigang]

Package: wnpp
Severity: wishlist

* Package name: cronie
  Version : 1.6.1
  Upstream Author : Marcela Mašláňová 
* URL : https://github.com/cronie-crond/cronie
* License : ISC, BSD-2-clause, BSD-3-clause, GPL-2+, GPL-3+
  Programming Lang: (C)
  Description : Process Scheduling Daemon

cronie is a daemon that runs specified programs at scheduled times and
optionally mails generated output to the user. It is a fork of the 
original ISC cron and contains many improvements, such as:

  * inotify support (Linux only)
  * clustering support
  * full PAM support

cronie is fully compatible with ISC cron (Debian's standard job 
scheduler), and can be used as a drop-in replacement for it.


cronie is already in experimental [1]. I plan to maintain cronie with 
the help of Georges Khaznadar for uploading.


[1] https://tracker.debian.org/pkg/cronie

Lance Lin
GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7


OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043320: bash: Background loop with sudo and wait cause terminal problems

[Bruce Momjian]

FYI, this problem does not happen with sh/dash.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry

[Jakub Ružička]

Package: wnpp
Severity: wishlist
Owner: Jakub Ružička 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-poetry-dynamic-versioning
  Version : 0.25.0
  Upstream Contact: Matthew T. Kennerly 
* URL : https://github.com/mtkennerly/poetry-dynamic-versioning
* License : Expat
  Programming Lang: Python
  Description : dynamic versioning plugin for Poetry

This is a Python plugin for Poetry and Poetry Core to enable dynamic
versioning based on tags in your version control system, powered by Dunamai.
Many different version control systems are supported, including Git and
Mercurial.


Poetry is very popular in the Python world and this plugin makes it easy to
use dynamic versioning in Poetry-managed projects.

Having this in Debian is a prerequisite for packaging of any projects using
poetry-dynamic-versioning. Some of existing packages require this in order to
update to latest upstream version which started using the plugin.

I plan to maintain the package as a part of the PythonTeam alongside
its requirement python-dunamai by the same upstream author.

I don't expect this package to be maintenance heavy.


signature.asc
Description: PGP signature

Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast

[Ben Hutchings]

On Wed, 2023-08-09 at 13:35 +0200, kolafl...@kolahilft.de wrote:
> I was able to resolve the issue with my ASRock J4105-ITX board (Celeron 
> J4105) on Debian-12. I just had to
>apt install intel-microcode
> and reboot. After 4 weeks of running the system 23/7 I had no further 
> crashes.
> 
> Without that intel-microcode package
>/sys/devices/system/cpu/cpu*/microcode/version
> is 0x26 (38 decimal).
> And with intel-microcode-3.20230512.1 the version is 0x3e (decimal 62).
> 
> 
> I'm not sure why intel-microcode was not installed by default. All my 
> other Debian computers have that package installed automatically.
[...]

We didn't use to install intel-microcode by default because it's non-
free.  Starting with Debian 12, non-free firmware and microcode are
installed on systems where they are useful, but upgrades from older
versions won't change this.

But I'm fairly sure what you've found is a different issue from what
Olivier originally reported.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949



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

Bug#1041775: iio-sensor-proxy: D-Bus policy is installed in /etc instead of /usr

[Gioele Barabucci]

Dear iio-sensor-proxy maintainers,

this patch has been accepted upstream and is included in the recently 
released version 3.5.


https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/commit/29c79c9e

Regards,

--
Gioele Barabucci

Bug#1031413: Slow backward search in long lines

[Rene Kita]

[Resending my mail from 2023-04-11 as it does not appear in the Debian
BTS. With help from #debian-admin I learned the my local part (mail@) in
my From: was the problem. My mails went to /dev/null or somewhere. :-(
Apologies for any inconveniences.]



Hi Robert,

Thanks for the detailed bug report!

On Thu, Feb 16, 2023 at 09:41:56PM +0100, Robert Alm Nilsson wrote:
> When I search backward in w3m by using the '?' command, the program
> freezes with high CPU usage for a bit of time if the found text is near
> the end of a very long line.

[Snip repro steps]

> The reason that this happens when searching backward but not forward is
> that in the function `backwardSearch` in search.c there is this loop:
> 
> while (regexMatch(...) == 1)
> 
> but in `forwardSearch` it's just an if statement:
> 
> if (regexMatch(...) == 1)
> 
> That means that when searching backward, we do one regexMatch for each
> character on the line and since the regexMatch itself already searches
> through the characters, that's pretty wasteful and that's what gives us
> the squared times.
> 
> It should be possible to change this so that an if statement is used in
> `backwardSearch` just like in `forwardSearch`.

This does not work as we are searching backwards and need the last
match, not the first.

> Maybe there could be two versions of `regexMatch` where one of them
> searches backwards or just returns the last match instead of the first
> one so that we don't have to call it in a loop.

This would be the ideal solution, of course - but also not a trivial
one. As a workaround we can change the function to not proceed char by
char, but to skip past the end of the last match. This will of course
not help if nearly the whole line matches.

See my patch below (I also refactored backwardSearch to remove a lot of
duplicated code).


---
Author: Rene Kita 
Subject: Fix slow backward search in long lines

We need to search the whole line up to the position we are at to find
the first match from the end. If we have a match we know its end and can
skip past it. This makes searching very long strings way more efficient.

While there, refactor the whole function.
---
 search.c |  104 ++-
 1 file changed, 44 insertions(+), 60 deletions(-)

--- a/search.c
+++ b/search.c
@@ -220,7 +220,7 @@ backwardSearch(Buffer *buf, char *str)
while (l->bpos && l->prev)
l = l->prev;
 }
-begin = l;
+
 if (pos > 0) {
pos--;
 #ifdef USE_M17N
@@ -228,80 +228,64 @@ backwardSearch(Buffer *buf, char *str)
pos--;
 #endif
p = >lineBuf[pos];
-   found = NULL;
-   found_last = NULL;
+}
+else {
+   if (!(l = l->prev)) {
+   if (!WrapSearch)
+   return SR_NOTFOUND;
+   l = buf->lastLine;
+   }
+   p = >lineBuf[l->size];
+}
+
+begin = l;
+found = NULL;
+found_last = NULL;
+
+while (1) {
q = l->lineBuf;
+   /*
+* Search as long as we have matches on the current line.
+* We are searching the line from begin to end. As we are searching
+* backwards we want the last match on the line.
+*/
while (regexMatch(q, >lineBuf[l->size] - q, q == l->lineBuf) == 1) {
matchedPosition(, );
if (first <= p) {
found = first;
found_last = last;
}
-   if (q - l->lineBuf >= l->size)
-   break;
-   q++;
+   q = last;
 #ifdef USE_M17N
while (q - l->lineBuf < l->size
   && l->propBuf[q - l->lineBuf] & PC_WCHAR2)
q++;
 #endif
-   if (q > p)
+   if (q >= p)
break;
}
-   if (found) {
-   pos = found - l->lineBuf;
-   while (pos >= l->len && l->next && l->next->bpos) {
-   pos -= l->len;
-   l = l->next;
-   }
-   buf->pos = pos;
-   if (l != buf->currentLine)
-   gotoLine(buf, l->linenumber);
-   arrangeCursor(buf);
-   set_mark(l, pos, pos + found_last - found);
-   return SR_FOUND;
+
+   if (found)
+   break;
+
+   if (!(l = l->prev)) {
+   if (!WrapSearch)
+   return SR_NOTFOUND;
+   l = buf->lastLine;
}
+   if (l == begin) /* no match */
+   return SR_NOTFOUND;;
 }
-for (l = l->prev;; l = l->prev) {
-   if (l == NULL) {
-   if (WrapSearch) {
-   l = buf->lastLine;
-   wrapped = TRUE;
-   }
-   else {
-   break;
-   }
-   }
-   found = NULL;
-   found_last = NULL;
-   q = l->lineBuf;
-   while (regexMatch(q, >lineBuf[l->size] - q, q == l->lineBuf) == 1) {
-   matchedPosition(, );
-   found = first;
-   found_last = last;
-   if (q - l->lineBuf >= l->size)
-  

Bug#1043359: RM: rinutils -- RoQA; RC-buggy since inception

[Bastian Germann]

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

Please remove rinutils. It is RC-buggy since it got into the archive 
(shame on me for sponsoring it) and was never in a Debian release.
The maintainer has never responded to my requests to fix the RC bug, so 
I am filing this RM request.

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail  writes:

> MR filed:
> https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2

Thanks.  We can rebase and squash at the end, but for now please don't
force push.

>>Oh man, yeah, hello early days of the internet!  All you need now is
>>some MIDI files and GIFs.
>  Haha, your paragraph makes me want to reinstall DOOM/Starcraft for the
> nth time now :)

:)

>>3. Please note which version of NCSA httpd matches mini-httpd.
> After much diff'ing and vim'ing and staring at #ifdefs and trying to
> separate Jef's unversioned changes to htpasswd.c from actual NCSA
> updates: 
> It's 99.999% 1.4.2. I noted that in debian/copyright.

Remember my Wed, 21 Jun 2023 email (as well as the one with the
diagram)?  1.4.2 still has the "no commercial endeavour" clause.

Here is what I found with
https://github.com/TooDumbForAName/ncsa-httpd/

$ git checkout 1.5.1
$ git diff 1.4.2 -- support/htpasswd.c

diff --git a/support/htpasswd.c b/support/htpasswd.c
index a9263ec..fb3415a 100644
--- a/support/htpasswd.c
+++ b/support/htpasswd.c
@@ -4,12 +4,18 @@
  * Rob McCool
  */

+#include "config.h"
+#include "portability.h"
+
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#ifdef NEED_CRYPT_H
+#include 
+#endif /* NEED_CRYPT_H */

 #define LF 10
 #define CR 13
@@ -79,10 +85,13 @@ to64(s, v, n)
 }
 }

+#ifdef HEAD_CRYPT
 char *crypt(char *pw, char *salt); /* why aren't these prototyped in include */
+#endif /* HEAD_CRYPT */
+
 #ifdef HEAD_GETPASS
 char *getpass(char *prompt);
-#endif
+#endif /* HEAD_GETPASS */

 void add_password(char *user, FILE *f) {
 char *pw, *cpw, salt[3];

=

I compared a couple of versions and found the same diff.

Hint: Read the commit message for 1.5.1.  Having read that, what is your
explanation for this diff, and what is your explanation for the changes
between any version of httpd in this range and mini-httpd?  There's
another hint in the tarball name that you're comparing with, but that
Jef Poskanzer may not have used.

> I hope everything is in order with my MR.

Yes, your MR looks good.  I started a review and noted what looks like
one typo.

> Have a great day and may the Debian swirl girate eternally !

Haha, you too!
Nicholas


signature.asc
Description: PGP signature

Bug#1043358: RM: gkeyfile-sharp -- RoQA; unmaintained upstream

[Bastian Germann]

Source: gkeyfile-sharp
Severity: wishlist

gkeyfile-sharp does not have any reverse dependency anymore. Upstream 
has not produced a release for a long time. Please consider removing the 
package.

Bug#765068: w3m: Misleading Option String for Cookies

[Rene Kita]

On Fri, 17 Oct 2014 21:49:27 +0200 Markus Hiereth  
wrote:
[...]

I had a look at the code with a debugger.

The w3m option field 'Domains to avoid [wrong number of dots]' expects a
list of domain names, separated by comma or space.

The code in question is the following from cookie.c:
322  if (version == 0) {
323  /* [NETSCAPE] rule */
324  unsigned int n = total_dot_number(domain->ptr,
325   domain->ptr + domain->length,
326   3);
327  if (n < 2) {
328  if (! check_avoid_wrong_number_of_dots_domain(domain)) {
329  COOKIE_ERROR(COO_ESPECIAL);
330  }
331  }

If n < 2 the actual matching happens in file.c:domain_match().

Note that comments in the code talk about RFC 2109 and DRAFT 12 (RFC
2965?). I don't think the code was ever updated to adjust to newer RFCs.
Also note that I'm not really familiar with RFCs related to cookies.

> please note the discussion thread within the mailing list of the
> English translation team:
> 
> https://lists.debian.org/debian-l10n-english/2014/10/msg00018.html
> 
> The results are
> 
> - It is necessary to find out what domain information is subject to
>   w3m's checking: The domain of the server that sends a SET-COOKIE
>   request and / or the domain name specified in the cookie itself.

The matching happens against the domain attribute that was given
in the SET-COOKIE header (Domain=).

> - It is necessary to have precisely described what matching is
>   performed with the domain attribute of a cookie. E.g. only the
>   number of dots in this string or all the conditions mentioned in the
>   RFC.

As can be seen from the code snippet above this depends on the version
of the cookie. The version depends of the header name, Set-Cookie: vs
Set-Cookie2: (according to Wikipedia Set-Cookie2 is deprecated and not
used anymore).

The check will only be performed when the number of dots in the domain
name is less then 2. AFAIK RFC 6265 made the leading dot in the domain
attribute optional. This means, a nowadays valid domain attribute, e.g.
github.com, will be checked.

Whitelisting `.github.com' will a match `domain=github.com' while
whitelisting `aol.com' will not match `domain=.aol.com' (.aol.com will
not be checked in the first place because it has two dots. I changed the
code to debug it).

Note, a domain like `https://aol.co.uk' will never be checked as is
always contains at least two dots.

Bug#1043357: golang-github-gotk3-gotk3: Unnecessary build dependency libgio-cil

[Bastian Germann]

Please also note the -dev package's dependency on libgio-cil.
This is probably unnecessary as well.

Bug#1043314: libnftnl: please disable documentation build when not building -doc package

[Jeremy Sowden]

On 2023-08-09, at 00:12:00 +0100, Simon McVittie wrote:
> Source: libnftnl
> Version: 1.2.6-1
> Severity: wishlist
> Tags: patch
> 
> Similar to libnetfilter-conntrack, libnftnl only needs graphviz
> (and doxygen) for its API documentation, so an easy way to reduce
> dependency chains would be for libnetfilter-conntrack to only build its
> API documentation when "Architecture: all" packages are being built.
> 
> Please consider the attached patch, with the "Closes" line amended to
> mention this bug report's bug number. I used diffoscope to confirm that
> this change does not alter the contents of either the _amd64 or _all
> binary packages.

No problem.  I'm working through the nf libs that I help maintain.  I'll
do this one next.

J.


signature.asc
Description: PGP signature

Bug#1043357: golang-github-gotk3-gotk3: Unnecessary build dependency libgio-cil

[Bastian Germann]

Source: golang-github-gotk3-gotk3
Version: 0.6.2-1
Severity: important

golang-github-gotk3-gotk3 build-depends on libgio-cil (C#) which does 
not make any sense. I have built the package successfully without that 
build dependency, so please drop it.

Bug#1043356: aegisub: fails to start on aarch64 with "terminate called without an active exception"

[Luis Fors]

Package: aegisub
Version: 3.2.2+dfsg-7+b3
Severity: normal
X-Debbugs-Cc: luis.a.f...@gmail.com

Dear Maintainer,

Aegisub fails to start:
```
$ aegisub-3.2
terminate called without an active exception
Aborted
```

I am using an MNT Reform, which is something of a DIY/hobbyist device, so I am 
unsure of whether this bug occurs for all aarch64 users or only Reform users.

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

Kernel: Linux 6.4.0-1-reform2-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aegisub depends on:
ii  libasound2 1.2.9-1
ii  libass91:0.17.1-1
ii  libboost-chrono1.74.0  1.74.0+ds1-22
ii  libboost-filesystem1.74.0  1.74.0+ds1-22
ii  libboost-locale1.74.0  1.74.0+ds1-22
ii  libboost-regex1.74.0 [libboost-regex1.74.  1.74.0+ds1-22
0-icu72]
ii  libboost-thread1.74.0  1.74.0+ds1-22
ii  libc6  2.37-7
ii  libffms2-5 2.40+git20211209-2+b2
ii  libfftw3-double3   3.3.10-1
ii  libfontconfig1 2.14.1-4
ii  libgcc-s1  13.2.0-1
ii  libgl1 1.6.0-1
ii  libhunspell-1.7-0  1.7.2+really1.7.2-10
ii  libicu72   72.1-3
ii  libluajit-5.1-22.1.0~beta3+git20220320+dfsg-4.1
ii  libpulse0  16.1+dfsg1-2+b1
ii  libstdc++6 13.2.0-1
ii  libwxbase3.2-1 3.2.2+dfsg-3
ii  libwxgtk-gl3.2-1   3.2.2+dfsg-3
ii  libwxgtk3.2-1  3.2.2+dfsg-3
ii  zlib1g 1:1.2.13.dfsg-1

aegisub recommends no packages.

Versions of packages aegisub suggests:
pn  aegisub-l10n  

-- no debconf information

Bug#1043330: tox: please make the build reproducible

[Faidon Liambotis]

Control: tags -1 pending

Hi Chris,

On Wed, Aug 09, 2023 at 09:16:05AM +0100, Chris Lamb wrote:
> This is because:
> 
> a) The documentation embeded the current build date via the copyright
> year and a "last updated" timestamp. The attached patch changes this
> to use SOURCE_DATE_EPOCH if available.

I fixed this upstream a while ago:
https://github.com/tox-dev/tox/pull/2941

> b) The default value for the --hashset argument (a random integer) was
> encoded into the documentation. As this value was nondeterminstic, a
> fresh value is inserted into the documentation on each build. This in
> turn makes the package unreproducible. The attached patch changes this
> to use the Pythonic "default=None … if default is None" pattern (NB.
> this is distinct from the "notset" value, which, incidentally, is
> typod in the --help text.)

I've been working for this for a while, and we actually resolved it with
upstream just this week! See:
https://github.com/tox-dev/tox/issues/2942
https://github.com/tox-dev/tox/pull/3076

The history/current status is: I uploaded 4.4.6-1 to experimental before
the freeze, as it's a major release breaking reverse dependencies. I
noticed the FTBR and tried to fix them upstream in the meantime.

4.4.6 is quite a bit outdated by now. Stefano Rivera is kindly helping
with bringing tox 4 to sid/trixie (see #1035635 for the thread with the
release team) and while doing so (understandably) opted into not
updating to a new upstream version.

I have a new upstream release staged locally, building reproducibly, but
not interfering with the tox 4 transition (as led by Stefano). Once the
transition is over, I'll upload 4.7.0 (or later) to unstable, which
should resolve this reproducibility issues -- and hopefully not
introduce new ones :)

Thanks!
Faidon

Bug#1043355: linux: Select MICROCODE_LATE_LOADING

[Paul Menzel]

Package: src:linux
Version: 6.5~rc4-1~exp1
Severity: Normal


Dear Debian folks,


Currently, Debian’s Linux kernel does not allow late loading microcode 
updates. Although discouraged, there are environments where that is 
preferred to rebooting/kexec’ing the system. It’d be great, if you could 
enable this.


The option was introduced in Linux 5.19, and backported to Linux 
5.15.99. Before the feature was working, but as the config defaults to 
no, it no longer does.


$ grep LATE_L /boot/config-6.*
/boot/config-6.4.0-1-amd64:# CONFIG_MICROCODE_LATE_LOADING is not set
/boot/config-6.5.0-0-amd64:# CONFIG_MICROCODE_LATE_LOADING is not set

The reason is, that the commit adding the new option 
`CONFIG_MICROCODE_LATE_LOADING`, introduced in Linux with commit 
a77a94f86273 (x86/microcode: Default-disable late loading) [1] was 
backported to stable release v5.15.99 in commit 6d2b3a31 [2], and the 
Linux configuration was not updated.



Kind regards,

Paul


[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a77a94f86273ce42a39cb479217dd8d68acfe0ff
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6d2b3a319144f3f5148d8a2b19549ea3bb118c2e

Bug#1043354: linux-image-6.1.0-10-armmp: please enable analog devices ethernet phy driver "adin"

[Josua Mayer]

Package: src:linux
Version: 6.1.38-2+sr1
Severity: normal
Tags: patch
X-Debbugs-Cc: josua.maye...@gmail.com

Dear Maintainer,

Please enable the "adin" driver for analog devices ADIN1300 ethernet phy.

SolidRun i.MX6 SoMs revision 1.9 and later replaced the original Atheros 
ethernet PHY with
ADIN1300. This combination is fully supported in Linux 6.1.
Therefore please enable the kernel module for armhf target.

Sincerely
Josua Mayer

-- Package-specific info:
** Version:
Linux version 6.1.0-10-armmp (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 
6.1.38-2+sr1 (2023-08-03)

** Command line:
  console=ttymxc0,115200 deferred_probe_timeout=10 ahci_imx.hotplug=1 cma=128M 
log_level=7 net.ifnames=0

** Tainted: C (1024)
 * staging driver was loaded

** Kernel log:
[   18.664358] Registered IR keymap rc-empty
[   18.716304] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[   18.759979] imx-ipuv3 240.ipu: IPUv3H probed
[   18.774524] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, 
raw IR receiver, no transmitter
[   18.800230] imx-ipuv3 280.ipu: IPUv3H probed
[   18.815890] input: gpio_ir_recv as 
/devices/platform/ir-receiver/rc/rc0/input0
[   18.848755] mc: Linux media interface: v0.10
[   18.947000] etnaviv etnaviv: bound 13.gpu (ops gpu_ops [etnaviv])
[   18.953152] videodev: Linux video capture interface: v2.00
[   19.011893] dwhdmi-imx 12.hdmi: Detected HDMI TX controller v1.30a with 
HDCP (DWC HDMI 3D TX PHY)
[   19.040476] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops [etnaviv])
[   19.078395] imx_media_common: module is from the staging directory, the 
quality is unknown, you have been warned.
[   19.096468] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops [etnaviv])
[   19.103221] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108
[   19.136549] imx6_media: module is from the staging directory, the quality is 
unknown, you have been warned.
[   19.167734] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[   19.211360] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[   19.217588] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[   19.242861] CAN device driver interface
[   19.311072] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0
[   19.330363] coda 204.vpu: firmware: failed to load vpu_fw_imx6q.bin (-2)
[   19.337504] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   19.352112] coda 204.vpu: firmware: failed to load vpu_fw_imx6q.bin (-2)
[   19.359277] coda 204.vpu: Direct firmware load for vpu_fw_imx6q.bin 
failed with error -2
[   19.382870] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW
[   19.419980] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops 
imx_drm_exit [imxdrm])
[   19.429343] coda 204.vpu: firmware: direct-loading firmware 
vpu/vpu_fw_imx6q.bin
[   19.454390] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops 
imx_drm_exit [imxdrm])
[   19.461379] coda 204.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin
[   19.511767] coda 204.vpu: Firmware code revision: 46076
[   19.517435] coda 204.vpu: Initialized CODA960.
[   19.522318] coda 204.vpu: Firmware version: 3.1.1
[   19.538475] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops 
imx_drm_exit [imxdrm])
[   19.582536] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops 
imx_drm_exit [imxdrm])
[   19.614946] coda 204.vpu: coda-jpeg-encoder registered as video0
[   19.626811] imx-drm display-subsystem: bound 12.hdmi (ops 
dw_hdmi_imx_ops [dw_hdmi_imx])
[   19.678814] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem 
on minor 1
[   19.688579] coda 204.vpu: coda-jpeg-decoder registered as video1
[   19.705350] imx_thermal 20c8000.anatop:tempmon: Extended Commercial CPU 
temperature grade - max:105C critical:100C passive:95C
[   19.726904] coda 204.vpu: coda-video-encoder registered as video2
[   19.746329] imx-drm display-subsystem: [drm] Cannot find any crtc or sizes
[   19.768188] coda 204.vpu: coda-video-decoder registered as video3
[   19.823963] imx-drm display-subsystem: [drm] Cannot find any crtc or sizes
[   19.888081] caam 210.crypto: Entropy delay = 3200
[   19.953984] caam 210.crypto: Instantiated RNG4 SH0
[   20.014746] caam 210.crypto: Instantiated RNG4 SH1
[   20.051209] caam 210.crypto: device ID = 0x0a160100 (Era 4)
[   20.057950] caam 210.crypto: job rings = 2, qi = 0
[   20.258432] sgtl5000 0-000a: sgtl5000 revision 0x11
[   20.320280] sgtl5000 0-000a: Using internal LDO instead of VDDD: check ER1 
erratum
[   20.553197] debugfs: File 'Headphone Jack' in directory 'dapm' already 
present!
[   20.687846] imx6_media_csi: module is from the staging directory, the 
quality is unknown, you have been warned.
[   20.694504] imx6_media_csi: module is from the staging directory, the 
quality is unknown, 

Bug#1043278: libshumate-dev: file conflict in Multi-Arch package

[Matthias Geiger]

On 09.08.23 13:05, Simon McVittie wrote:

On Wed, 09 Aug 2023 at 11:45:11 +0200, Matthias Geiger wrote:

Ok. diff included
-getter="get_cache_dir">
+getter="get_cache_dir"
+default-value="NULL">
-getter="get_size_limit">
+getter="get_size_limit"
+default-value="1">

(etc.)

I suspect that the difference might simply be that libshumate-dev:mips64el
was uploaded at an unlucky time, and was compiled with a different
version of gobject-introspection.

Looking at the logs, it was indeed built with a different version:

amd64:

Preparing to unpack .../143-gobject-introspection_1.76.1-2_amd64.deb ...

mips64el:

Preparing to unpack .../143-gobject-introspection_1.74.0-3_mips64el.deb ...

If that's the reason for this, then any sourceful upload should resolve
the issue. You could add a Build-Depends: gobject-introspection (>= 1.76.1)
if you want to be sure.



Thanks for looking into this. I'll upload a revision with the version 
constraint added.


werdahias



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043353: daemons running by default differ between sysvinit and systemd

[Guido Berhoerster]

Package: cfengine3
Version: 3.21.0-2

The default behavior differs depending on whether systemd is installed or not.

In case the cfengine sysvinit script is run, none of the daemons are started by
default because /etc/default/cfengine3 contains:

…
# To start these three daemons you need /var/lib/cfengine3/inputs/promises.cf
RUN_CFMONITORD=0
RUN_CFSERVERD=0
RUN_CFEXECD=0
…

On the other hand the systemd services for all three daemons are enabled by 
default as long as /var/lib/cfengine3/inputs/promises.cf exists.

The behavior should be the same for both cases.

-- 
Guido Berhoerster

Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast

[kolafl...@kolahilft.de]

I was able to resolve the issue with my ASRock J4105-ITX board (Celeron 
J4105) on Debian-12. I just had to

  apt install intel-microcode
and reboot. After 4 weeks of running the system 23/7 I had no further 
crashes.


Without that intel-microcode package
  /sys/devices/system/cpu/cpu*/microcode/version
is 0x26 (38 decimal).
And with intel-microcode-3.20230512.1 the version is 0x3e (decimal 62).


I'm not sure why intel-microcode was not installed by default. All my 
other Debian computers have that package installed automatically. I had 
some very rare crashes with Debian-11. So Debian-12 maybe just worsened 
the issue and it already existed before updating to Debian-12.


In theory a BIOS update might also do the job. I run BIOS 1.40 and there 
is a 1.60 version from 2021. But 1.60 does not list a microcode update.

https://www.asrock.com/mb/Intel/J4105-ITX/#BIOS
(haven't updated to BIOS 1.60 yet)


Kind regards,
kolAflash


OpenPGP_0xEA831012D83C3408.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043352: node-eventemitter3: drop debian/todo as tests are run

[Andrius Merkys]

Source: node-eventemitter3
Severity: wishlist
Version: 4.0.7-3

Hello,

node-eventemitter3 contains a debian/todo file with the following content:

  Tests depend on node-assume, which is not yet packaged (#962635):

  mocha spec --timeout 1 test/test.js

node-assume is now packaged and it seems that mocha tests are now used 
both the build and autopkgtest stage. Thus debian/todo is outdated and 
should be removed.


Andrius

Bug#1043351: ebtables: unescaped hyphens in manpage

[Linus Lüssing]

Package: ebtables
Version: 2.0.11-5
Severity: normal
X-Debbugs-Cc: linus.luess...@c0d3.blue

Dear Maintainer,

I tried running the following ebtables command, but got an error:

```
$ sudo ebtables -I INPUT -i veth1 -j mark ‐‐mark-set 0x42
ebtables v1.8.9 (nf_tables): Bad argument : '‐‐mark-set'
```

On #netfilter IRC people with eagle-eyes and apparently a different font
than me pointed out that I was trying to use Unicode instead of ASCII
hyphens. Changing the command to use "--mark-set", with ASCII hyphens,
instead helped.

It seems I copied the Unicode version from the ebtables manpage. I believe
it's a similar issue to this one:

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

That is un-escaped hyphens in the manpage source code are rendered to
Unicode hyphens.

To fix this the hyphens should be escaped in the manpage source code.

Regards, Linus

(Kudos to @aiyion@infosec.exchange on Mastodon who pointed me to the
curl Debian bug report and by that to the origin of my issue.)


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages ebtables depends on:
ii  libc62.37-6
ii  netbase  6.4

Versions of packages ebtables recommends:
ii  iptables  1.8.9-2
ii  kmod  30+20230519-1

ebtables suggests no packages.

-- no debconf information

Bug#1043350: cairo-dock-dbus-plug-in-interface-mono: Please drop this unused package

[Bastian Germann]

Package: cairo-dock-dbus-plug-in-interface-mono
Version: 3.4.1+git20201022.a0d3415c-1
Severity: minor

cairo-dock-dbus-plug-in-interface-mono is hindering package removal in 
the GtkSharp ecosystem. It does not have any reverse dependencies and a 
low popcon. Please consider removing it.

Bug#1041323: CFEngine agent connection errors

[Guido Berhoerster]

On Thu, 20 Jul 2023 11:25:09 +0200 Guido Berhoerster  
wrote:
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  TRUST 
> FAILED, server presented untrusted key: MD5=42d62c2c4be843a78dafffb40dd40277
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  No 
> suitable server found for '/var/lib/cfengine3/inputs'
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Promise 
> belongs to bundle 'failsafe_cfe_internal_update' in file 
> '/var/lib/cfengine3/inputs/failsafe.cf' near line 121
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Errors 
> encountered when actuating files promise '/var/lib/cfengine3/inputs'
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]:error: ::1>
>  SSL_write: underlying network error (Broken pipe)
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>
>  SSL_write: underlying network error (Broken pipe)
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]:   notice: ::1>
>  Connection was hung up!
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>
>  Connection was hung up!
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  TRUST 
> FAILED, server presented untrusted key: MD5=42d62c2c4be843a78dafffb40dd40277
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  No 
> suitable server found for '/var/lib/cfengine3/modules'
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Promise 
> belongs to bundle 'failsafe_cfe_internal_update' in file 
> '/var/lib/cfengine3/inputs/failsafe.cf' near line 130
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Errors 
> encountered when actuating files promise '/var/lib/cfengine3/modules'
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]:error: ::1>
>  SSL_write: underlying network error (Broken pipe)
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>
>  SSL_write: underlying network error (Broken pipe)
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]:   notice: ::1>
>  Connection was hung up!
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>
>  Connection was hung up!
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  TRUST 
> FAILED, server presented untrusted key: MD5=42d62c2c4be843a78dafffb40dd40277
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]:error: ::1>
>  Connection was hung up while receiving line:
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>
>  Connection was hung up while receiving line:
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]:   notice: ::1>
>  Client closed connection early! He probably does not trust our key...
> Jul 20 10:35:34 tjener.intern cf-serverd[1168]: CFEngine(server)  ::1>
>  Client closed connection early! He probably does not trust our key...
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  No 
> suitable server found for '/var/lib/cfengine3/inputs'
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Promise 
> belongs to bundle 'failsafe_cfe_internal_update' in file 
> '/var/lib/cfengine3/inputs/failsafe.cf' near line 144
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Comment is 
> 'If we failed to fetch policy we try again using
>   the 
> legacy default in case we are fetching policy
>   from a 
> hub that is not serving mastefiles via a
>   
> shortcut.'
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Errors 
> encountered when actuating files promise '/var/lib/cfengine3/inputs'
> Jul 20 10:35:34 tjener.intern cf-agent[4722]: CFEngine(agent)  Method 
> 'failsafe_cfe_internal_update' failed in some repairs
> Jul 20 10:35:34 tjener.intern cf-agent[4734]: CFEngine(agent)  TRUST 
> FAILED, server presented untrusted key: MD5=42d62c2c4be843a78dafffb40dd40277
> Jul 20 10:35:34 tjener.intern cf-agent[4734]: CFEngine(agent)  No 
> suitable server found for '/var/lib/cfengine3/inputs/cf_promises_validated'
> Jul 20 10:35:34 tjener.intern cf-agent[4734]: CFEngine(agent)  Promise 
> belongs to bundle 'cfe_internal_update_policy_cpv' in file 
> '/var/lib/cfengine3/inputs/cfe_internal/update/update_policy.cf' near line 229
> Jul 20 10:35:34 tjener.intern cf-agent[4734]: CFEngine(agent)  Comment is 
> 'Check whether a validation stamp is available for a new policy update to 
> reduce the distributed load'


The untrusted server key issue can be fixed by following the procedure on 
manually establishing trust described in

Bug#1043349: RFA: node-assume -- Expect-like assertions that work in node and the browser

[Andrius Merkys]

Package: wnpp

Hello,

I would like to pass the maintenance of node-assume to someone more
motivated. The package is in good shape. I sponsored its initial upload, 
but in the end I did not use it. Now it seems to be used by a bunch of 
node-* packages.


Package description from debian/control:

 Assume is an expect inspired assertion library who's sole purpose is 
to create
 a working and human readable assert library for browsers and node. The 
library

 is designed to work with different assertion styles.
 .
 Assume is written with client and server-side Javascript in mind and uses
 commonjs module system to export itself.
 .
 This package is used as a build dependency for other Debian packages.
 Specifically it is used in the testing phase of the build process.

Andrius

Bug#743553: information: rsyslog: build omudpspoof module

[Jens Hektor]

This is a longstanding wish (2014!), it would be nice
to have this module installable without rebuilding
this package on my own.

It is the basic connectivity module and as we have all
the "advanced" module (eg. elasticsearch) this is
the module to build a nice farm of syslog servers
running all rsyslogd.

So it would be very nice to have this soon.

Or I have to roll back into the Redhat World.

Best regards, Jens Hektor

--
Dipl.-Phys. Jens Hektor, Security Operations
RWTH Aachen University, IT Center RWTH Aachen University
Room 2.04, Wendlingweg 10, 52074 Aachen (Germany)
Phone: +49 241 80 29206 - Fax: +49 241 80 22100
http://www.itc.rwth-aachen.de - hek...@itc.rwth-aachen.de


smime.p7s
Description: Kryptografische S/MIME-Signatur

Bug#1043348: rrsync: Directory check too strict

[Johannes Schmidt]

Package: rsync
Version: 3.2.7-1
Severity: normal
X-Debbugs-Cc: jsmith6...@gmx.net

Dear Maintainer,

I found a regression in rrsync, which came with the change from Perl (Bullseye)
to Python (Bookworm), and would like to propose a bug fix.


   * What led up to the situation?

I am using backupninja to create local backups from a remote server. With
Bullseye, I had to use the following line in the configuration file to make it
work with rrsync:
include = .

backupninja converts this to the command
rsync  user@remoteserver:/./ /localbackupdir/
to read the complete subdirectory defined by rrsync (see below) and store it in
the local backup directory.


authorized_keys on the remote server:
command="/usr/bin/rrsync -ro /path/to/restricted/source/",restrict ssh-rsa
...


Starting with Bookworm, rrsync breaks the backup process with the error "unsafe
arg":
(Output of die('unsafe arg:', orig_arg, [arg, real_arg]) )
unsafe arg: /./, [/path/to/restricted/source/., /path/to/restricted/source]

Note that arg is not equal to real_arg, since the trailing "/./" of the
original argument (orig_arg) is not completely stripped from arg.


   * What exactly did you do (or not do) that was effective (or ineffective)?

I found that in rrsync, there is a directory argument check that is too
restrictive to work with above (valid) string:

rrsync 3.2.7 (as in Bookworm):
https://salsa.debian.org/debian/rsync/-/blob/debian/3.2.7-1/support/rrsync?ref_type=tags#L309

ret = [ ]
for arg in got:
if args.dir != '/' and arg != '.' and (typ == 3 or (typ == 2 and not
am_sender)):
arg_has_trailing_slash = arg.endswith('/')
if arg_has_trailing_slash:
arg = arg[:-1]
else:
arg_has_trailing_slash_dot = arg.endswith('/.')
if arg_has_trailing_slash_dot:
arg = arg[:-2]
real_arg = os.path.realpath(arg)
if arg != real_arg and not real_arg.startswith(args.dir_slash):
die('unsafe arg:', orig_arg, [arg, real_arg])
if arg_has_trailing_slash:
arg += '/'
elif arg_has_trailing_slash_dot:
arg += '/.'
if opt == 'arg' and arg.startswith(args.dir_slash):
arg = arg[args.dir_slash_len:]
if arg == '':
arg = '.'
ret.append(arg)

After a small patch, the code seems still valid for me, but allowing a trailing
"/" after a trailing "/.", therefore allowing a trailing "/./".

My proposed patch:

ret = [ ]
for arg in got:
if args.dir != '/' and arg != '.' and (typ == 3 or (typ == 2 and not
am_sender)):
1.  arg_has_trailing_slash = arg.endswith('/')
if arg_has_trailing_slash:
arg = arg[:-1]
2.  arg_has_trailing_slash_dot = arg.endswith('/.')
if arg_has_trailing_slash_dot:
arg = arg[:-2]
3.  real_arg = os.path.realpath(arg)
if arg != real_arg and not real_arg.startswith(args.dir_slash):
die('unsafe arg:', orig_arg, [arg, real_arg])
4.  if arg_has_trailing_slash_dot:
arg += '/.'
5.  if arg_has_trailing_slash:
arg += '/'
if opt == 'arg' and arg.startswith(args.dir_slash):
arg = arg[args.dir_slash_len:]
if arg == '':
arg = '.'
ret.append(arg)

1. Trailing "/" is removed.
2. Trailing "/." is removed.
3. Directory is checked.
4. Trailing "/." is appended again.
5. Trailing "/" is appended again.

Please check carefully, I am not familiar with the Python language.


   * What was the outcome of this action?

The check in line 320 (
https://salsa.debian.org/debian/rsync/-/blob/debian/3.2.7-1/support/rrsync?ref_type=tags#L320
) does not fail, which is the intended result.


Thank you in advance.


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

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

Versions of packages rsync depends on:
ii  init-system-helpers1.65.2
ii  libacl12.3.1-3
ii  libc6  2.36-9+deb12u1
ii  liblz4-1   1.9.4-1
ii  libpopt0   1.19+dfsg-1
ii  libssl33.0.9-1
ii  libxxhash0 0.8.1-1
ii  libzstd1   1.5.4+dfsg2-5
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

rsync recommends no packages.

Versions of 

Bug#1043278: libshumate-dev: file conflict in Multi-Arch package

[Simon McVittie]

On Wed, 09 Aug 2023 at 11:45:11 +0200, Matthias Geiger wrote:
> Ok. diff included

> -getter="get_cache_dir">
> +getter="get_cache_dir"
> +default-value="NULL">

> -getter="get_size_limit">
> +getter="get_size_limit"
> +default-value="1">

(etc.)

I suspect that the difference might simply be that libshumate-dev:mips64el
was uploaded at an unlucky time, and was compiled with a different
version of gobject-introspection.

Looking at the logs, it was indeed built with a different version:

amd64:
> Preparing to unpack .../143-gobject-introspection_1.76.1-2_amd64.deb ...

mips64el:
> Preparing to unpack .../143-gobject-introspection_1.74.0-3_mips64el.deb ...

If that's the reason for this, then any sourceful upload should resolve
the issue. You could add a Build-Depends: gobject-introspection (>= 1.76.1)
if you want to be sure.

smcv

Bug#1043347: RM: zeitgeist-sharp -- RoQA; unmaintained; low popcon

[Bastian Germann]

Source: zeitgeist-sharp
Severity: wishlist

zeitgeist-sharp does not have any reverse dependency anymore. Upstream 
has not produced a release for a long time. Please consider removing the 
package.

Bug#1043242: highlight: new upstream version

[David Bremner]

Unit 193  writes:
>
> Actually at the time of this writing, 4.7 is the current release.  I had 
> gone ahead and jumped to the latest version a while ago, mainly to unify 
> my system on one Lua version, and I've attached the debdiff (debian/ only) 
> to this message.
>

Hi all;

I've orphaned the package [1] and created a gbp style repo in the debian
group on salsa. If some team or group decides to maintain highlight I
may rejoin in the future, but for now I decided to get out of the way.

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

Bug#1043346: RM: notify-sharp-3.0 -- RoQA; unmaintained; low popcon

[Bastian Germann]

Source: notify-sharp-3.0
Severity: wishlist

I have just filed RM bug #901994 for the removal of sparkleshare, the 
only reverse dependency of notify-sharp-3.0. Upstream has not produced a 
release for a long time. Please consider removing the package as well.