Bug#360884: rwhod: There should be an option to configure the alarm interval

[Gürkan Myczko]

With the new ruptime, see https://bugs.debian.org/1013361
you can easily configure this option.

Bug#489787: rwho -a fails when >1000 users logged in

[Gürkan Myczko]

The new rwho from ruptime, https://bugs.debian.org/1013361
has no such limit.

It is waiting in the new queue to get processed.

Bug#1020628: O: netkit-rwho -- Clients to query the rwho server

[Gürkan Myczko]

Once the ruptime from new queue is processed, I plan to create a 
migration plan for this, but not replacing the

old src:pkgname, nor the binary package names.

Bug#1039284: netkit-rwho: ships sysv-init script without systemd unit

[Gürkan Myczko]

The new implementation of rwho, see #1013361, does come with a systemd 
unit,

it's waiting in the new queue.

Bug#1010291: postgresql-common: Does /var/log/postgresql really need chmod +t?

[Ross Vandegrift]

Package: postgresql-common
Version: 248
Followup-For: Bug #1010291
X-Debbugs-Cc: rvandegr...@debian.org
Control: tags -1 patch

After upgrading to bookworm, I was reminded of this bug when
/var/log/postgresql's sticky bit re-appeared.  So I dug a bit more.

postgresql-common's postinst unconditionally changes owners and modes on
/var/log/postgresql.  The patch below makes it respect dpkg-statoverride.

Thanks,
Ross

diff --git a/debian/postgresql-common.postinst 
b/debian/postgresql-common.postinst
old mode 100644
new mode 100755
index 545146a..638c8b8
--- a/debian/postgresql-common.postinst
+++ b/debian/postgresql-common.postinst
@@ -65,8 +65,10 @@ Please fix this and reinstall this package." >&2

 # nicer log directory permissions
 mkdir -p /var/log/postgresql
-chmod 1775 /var/log/postgresql
-chown root:postgres /var/log/postgresql
+if ! dpkg-statoverride --list /var/log/postgresl > /dev/null; then
+chmod "$LOG_MODE" /var/log/postgresql
+chown root:postgres /var/log/postgresql
+fi

 # create socket directory
 [ -d /var/run/postgresql ] || \

Bug#1038344: bookworm-pu: package request-tracker5/5.0.3+dfsg-2+deb12u1

[Andrew Ruthven]

On Sun, 2023-06-25 at 17:43 +0100, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> I just happened to look at this; otherwise as it was still tagged
> "moreinfo" it would probably have been waiting for attention for quite a
> while.

Oops, I did wonder if I should change the tag.

> As 5.0.3+dfsg-3 in unstable is limited to these changes anyway, you can
> backport it directly and the version history makes things a bit clearer
> for
> some infrastructure. Just add a changelog entry on top of the unstable
> version, "Backport to bookworm" or something, version 5.0.3+dfsg-
> 3~deb12u1,
> target bookworm. Don't remove the changelog for 5.0.3+dfsg-3.
> 
> Example:
> https://release.debian.org/proposed-updates/bookworm_diffs/onionshare_2.6-5~deb12u1.debdiff
> 
> Other than that, please go ahead.

Awesome, thank you. I figured it'd make life easier to upload only these
changes to unstable initially.

Changelog updated as requested, and uploaded to bookworm.

Cheers,
Andrew


-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |

Bug#1039119: darktable: use packaged lua

[David Bremner]

Bastien Roucariès  writes:

> Source: darktable
> Version: Use packaged lua
> Severity: serious
> Justification: embded code copy
>
> Dear Maintainer,
>
> It appear that your package embded and compile lua
>
> Could you:
> - use the packaged lua lib
> - repack in order to avoid accidental reintroduction of compiling lua
>
> rouca

Since upstream already checks for the system lua (unless that changed)
repackaging seems unecessary. Do you have some evidence (build logs ?)
that the build is not using the system lua?

d

Bug#1039168: deluge: ships sysv-init script without systemd unit

[Daniel Baumann]

close 1039168 2.1.1-3
thanks

Hi,

On 6/26/23 00:21, bl...@debian.org wrote:
> deluge has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file.

thanks; this is not the case since deluge 2.1.1-3 from 2023-02-24
already, so closing.

Regards,
Daniel

Bug#1039181: doodle: ships sysv-init script without systemd unit

[Daniel Baumann]

close 1039181 0.7.2-6
thanks

Hi,

On 6/26/23 00:21, bl...@debian.org wrote:
> doodle has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file.

thanks; the daemon just has been removed due to #1038809, so, this
doesn't apply anymore to the current package.

Regards,
Daniel

Bug#1039446: python3-qgis: please remove obsolete dependency on python3-six

[Sebastiaan Couwenberg]

Control: tags -1 pending

The dependency is dropped in git.

Kind Regards,

Bas

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

Bug#1039458: Extension E-MAIL already installed in /usr/share/gnome-shell/extensions/E-MAIL. /usr/share/gnome-shell/extensions/E-MAIL will not be loaded

[AlMa]

Package: gnome-shell
Version: 43.4-1
Control: affects -1 gnome-shell-extension-freon 
gnome-shell-extension-weather gnome-shell-extensions-extra 
gnome-shell-pomodoro gnome-shell-extensions


In my journal, I get a bunch of messages that a Gnome extension is 
already installed and will not be loaded:


Jun 26 03:41:59 AnonymizedMachineName gnome-shell[1131]: Will monitor 
session c1
Jun 26 03:41:59 AnonymizedMachineName dbus-daemon[798]: [system] 
Activating via systemd: service name='org.freedesktop.locale1' 
unit='dbus-org.freedesktop.locale1.service' requested by ':1.37' 
(uid=119 pid=1131 comm="/usr/bin/gnome-shell")
Jun 26 03:41:59 AnonymizedMachineName systemd[1]: Starting 
systemd-localed.service - Locale Service...
Jun 26 03:41:59 AnonymizedMachineName /usr/libexec/gdm-x-session[1076]: 
dbus-daemon[1076]: [session uid=119 pid=1076] Activating service 
name='org.gnome.Shell.Screencast' requested by ':1.5' (uid=119 pid=1131 
comm="/usr/bin/gnome-shell")
Jun 26 03:41:59 AnonymizedMachineName dbus-daemon[798]: [system] 
Successfully activated service 'org.freedesktop.locale1'
Jun 26 03:41:59 AnonymizedMachineName systemd[1]: Started 
systemd-localed.service - Locale Service.
Jun 26 03:41:59 AnonymizedMachineName /usr/libexec/gdm-x-session[1076]: 
dbus-daemon[1076]: [session uid=119 pid=1076] Activating service 
name='org.freedesktop.impl.portal.PermissionStore' requested by ':1.5' 
(uid=119 pid=1131 comm="/usr/bin/gnome-shell")
Jun 26 03:41:59 AnonymizedMachineName /usr/libexec/gdm-x-session[1076]: 
dbus-daemon[1076]: [session uid=119 pid=1076] Successfully activated 
service 'org.freedesktop.impl.portal.PermissionStore'
Jun 26 03:41:59 AnonymizedMachineName kernel: Lockdown: systemd-logind: 
hibernation is restricted; see man kernel_lockdown.7
Jun 26 03:41:59 AnonymizedMachineName dbus-daemon[798]: [system] 
Activating via systemd: service name='org.freedesktop.GeoClue2' 
unit='geoclue.service' requested by ':1.37' (uid=119 pid=1131 
comm="/usr/bin/gnome-shell")
Jun 26 03:41:59 AnonymizedMachineName systemd[1]: Starting 
geoclue.service - Location Lookup Service...
Jun 26 03:41:59 AnonymizedMachineName /usr/libexec/gdm-x-session[1076]: 
dbus-daemon[1076]: [session uid=119 pid=1076] Successfully activated 
service 'org.gnome.Shell.Screencast'
Jun 26 03:41:59 AnonymizedMachineName polkitd[842]: Registered 
Authentication Agent for unix-session:c1 (system bus name :1.37 
[/usr/bin/gnome-shell], object path 
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8)
Jun 26 03:41:59 AnonymizedMachineName dbus-daemon[798]: [system] 
Activating via systemd: service name='org.freedesktop.PackageKit' 
unit='packagekit.service' requested by ':1.37' (uid=119 pid=1131 
comm="/usr/bin/gnome-shell")
Jun 26 03:41:59 AnonymizedMachineName systemd[1]: Starting 
packagekit.service - PackageKit Daemon...

Jun 26 03:41:59 AnonymizedMachineName PackageKit[1193]: daemon start
Jun 26 03:41:59 AnonymizedMachineName systemd[1]: 
systemd-rfkill.service: Deactivated successfully.
Jun 26 03:41:59 AnonymizedMachineName gnome-shell[1131]: 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
Jun 26 03:41:59 AnonymizedMachineName gnome-shell[1131]: 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
Jun 26 03:41:59 AnonymizedMachineName gnome-shell[1131]: 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
Jun 26 03:41:59 AnonymizedMachineName gnome-shell[1131]: 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
Jun 26 03:41:59 AnonymizedMachineName geoclue[1184]: No feature manager 
for feature of type 'GProxyResolver'
Jun 26 03:41:59 AnonymizedMachineName gnome-shell[1131]: 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
Jun 26 03:41:59 AnonymizedMachineName gnome-shell[1131]: Extension 

Bug#1039457: mplayer: reproducible-builds: version differences caused by /bin/sh implementations

[Vagrant Cascadian]

Source: mplayer
Version: 2:1.5+svn38423-2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When build with /bin/sh pointing to dash or bash, a different version.h
is generated, which results in different version strings getting
embedded in various binaries:

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

  /usr/bin/mencoder

  MPlayer·1.5+svn38423-2·(Debian)
  vs.
  MPlayer·1.5+svn38423-2·(Debian)\n

The two shell implementations have some differences in echo
implementations.

The patch to debian/rules fixes this by using a single printf call
instead of two echo calls, and adjusting the escaped strings
accordingly.


According to my local tests, with this patch applied mplayer should
build reproducibly again on tests.reproducible-builds.org when it
migrates to trixie/testing! Unfortunately, there are still outstanding
issues with embedded build paths that are tested in unstable and
experimental.


Thanks for maintaining mplayer!


live well,
  vagrant
From 744d893c714f66cd526a83acc21c3adbb9cf786a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 25 Jun 2023 18:51:36 -0700
Subject: [PATCH] debian/rules: Use printf instead of echo.

The echo implementations may be dependent on the shell implementation.
---
 debian/rules | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/debian/rules b/debian/rules
index 7ed5090..b17fdbc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,7 +12,7 @@ include /usr/share/dpkg/buildtools.mk
 
 D_VERSION = $(shell dpkg-parsechangelog -SVersion | sed -e 's/^[0-9]*://')
 OUR_VERSION = \#define VERSION \"$(D_VERSION) (Debian)\"
-OUR_TITLE = \#define MP_TITLE \"MPlayer $(D_VERSION) (Debian)\\\n\"
+OUR_TITLE = \#define MP_TITLE \"MPlayer $(D_VERSION) (Debian)\"
 
 CFLAGS +=$(CPPFLAGS)
 
@@ -99,8 +99,7 @@ override_dh_auto_build-arch:
 	$(MAKE) install-gui-msg DESTDIR=$(CURDIR)/gui-msg
 	$(MAKE) distclean
 	./configure $(CONFIGURE_FLAGS) --disable-gui
-	echo "$(OUR_VERSION)"  >> version.h
-	echo "$(OUR_TITLE)"  >> version.h
+	printf "$(OUR_VERSION)\n$(OUR_TITLE)\n"  >> version.h
 	dh_auto_build -- mplayer mencoder
 
 override_dh_auto_build-indep:
@@ -112,8 +111,7 @@ override_dh_auto_clean:
 
 override_dh_auto_configure-arch:
 	./configure $(CONFIGURE_FLAGS) --enable-gui --enable-nls
-	echo "$(OUR_VERSION)"  >> version.h
-	echo "$(OUR_TITLE)"  >> version.h
+	printf "$(OUR_VERSION)\n$(OUR_TITLE)\n"  >> version.h
 
 override_dh_auto_configure-indep:
 	[ -f config.mak ] || ./configure $(CONFIGURE_DOC_FLAGS)
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1039456: apt-xapian-index: missing depedency on python3-six

[Alexandre Detiste]

Package: apt-xapian-index
Version: 0.53
Severity: normal

apt-xapian-index uses python3-six in a single place
but forget to declare a depedency on it

apt-xapian-index would better be ported
to properly use the "io" module dirrectly
(one line change)

$ grep ' six' /bin -r 2>/dev/null | grep import
/bin/axi-cache:from six import StringIO
$ dpkg -S axi-cache
apt-xapian-index: /usr/bin/axi-cache

Greetings,


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt-xapian-index depends on:
ii  python3 3.11.2-1+b1
ii  python3-apt 2.6.0
ii  python3-debian  0.1.49
ii  python3-xapian  1.4.22-1

apt-xapian-index recommends no packages.

Versions of packages apt-xapian-index suggests:
ii  python3-xdg  0.28-2

-- no debconf information

Bug#1039455: Acknowledgement (grass-core: please remove obsolete dependency on python3-six)

[Alexandre Detiste]

actualy the depedency belongs on "grass" package

grep ...
> /bin/grass:import six

Bug#1039454: smartmontools: systemd service unit and init scripts should be me in own package

[Witold Baryluk]

Package: smartmontools
Version: 7.3-1+b1
Followup-For: Bug #1039454
X-Debbugs-Cc: witold.bary...@gmail.com


BTW. This would also fix https://bugs.debian.org/204613 and
https://bugs.debian.org/894146

Bug#1039455: grass-core: please remove obsolete dependency on python3-six

[Alexandre Detiste]

Package: grass-core
Version: 8.2.1-1
Severity: normal

Hi,

grass-core hasn't require python3-six for a while,
please remove it from the depedencies.

dpkg -L grass-core | grep '\.py' | xargs grep six
-> false matches

Greetings,

Alexandre Detiste


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

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

Versions of packages grass-core depends on:
ii  grass-doc   8.2.1-1
ii  libatlas3-base [liblapack.so.3] 3.10.3-13
ii  libblas3 [libblas.so.3] 3.11.0-2
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.36-9
ii  libcairo2   1.16.0-7
ii  libfftw3-double33.3.10-1
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgcc-s1   13.1.0-6
ii  libgdal32   3.6.4+dfsg-1
ii  libgeos-c1v53.11.1-1
ii  libgl1  1.6.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libgomp113.1.0-6
ii  liblapack3 [liblapack.so.3] 3.11.0-2
ii  libmariadb3 1:10.11.4-1
ii  libnetcdf19 1:4.9.2-1
ii  libodbc22.3.11-2
ii  libpng16-16 1.6.39-2
ii  libpq5  15.3-0+deb12u1
ii  libproj25   9.2.1-1
ii  libreadline88.2-1.3
ii  libsqlite3-03.40.1-2
ii  libstdc++6  13.1.0-6
ii  libtiff64.5.1~rc3-1
ii  libx11-62:1.8.6-1
ii  libzstd11.5.4+dfsg2-5
ii  python3 3.11.2-1+b1
ii  python3-distutils   3.11.4-1
ii  python3-numpy [python3-numpy-abi9]  1:1.24.2-1
ii  python3-six 1.16.0-4
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages grass-core recommends:
ii  gdal-bin  3.6.4+dfsg-1
ii  proj-bin  9.2.1-1

Versions of packages grass-core suggests:
pn  avce00
pn  e00compr  
ii  gnuplot   5.4.4+dfsg1-2
ii  gnuplot-qt [gnuplot]  5.4.4+dfsg1-2+b2
pn  gpsbabel  
pn  gpstrans  
pn  grass-dev 
pn  grass-gui 
ii  netpbm2:11.01.00-2
pn  python3-rpy2  
pn  python3-termcolor 

-- no debconf information

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Benda Xu]

Hi Luca,

Luca Boccassi  writes:

>> On Sun, 2023-06-25 at 18:51 +0100, Luca Boccassi wrote:
>> > Patch attached and pushed to
>> > https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=hea
>>
>> There is one part I think should not be changed: we currently don't
>> require integration with service management at all. That should
>> probably not be changed.  So please consider reverting
>>
>> +---
>> | Packages that include system services must include ``systemd`` service
>> +---
>>
>> to the original
>>
>> +---
>> | Packages that include system services should include ``systemd`` service
>> +---
>
> How about:
>
> -Packages that include system services should include ``systemd`` service
> -units to start or stop those services.
> +Packages shipping system services should integrate with service management.
> +If they choose to do so, they must include ``systemd`` service units to start
> +or stop those services.

I take care of packages that does not meet the proposed policy. And I
don't have a systemd test environment.  I am curious what is the
recommended way to go forward.

- upload a generator-converted .service without any test;
- set low-NMU to encourage interested party to upload a .service;
- leave the lack-of-systemd-service bug open until some one submit a
  patch or a merge request;
- you name it.

Cheers,
Benda

Bug#1039454: smartmontools: systemd service unit and init scripts should be me in own package

[Witold Baryluk]

Package: smartmontools
Version: 7.3-1+b1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

Lets say I want to have smartctl tool available, to inspect some faulty
or close to faulty drive.

But there is no way to do just that, as installing smartmontool will
automatically start doing automatic things on this disk!

I think it is not desirable to ship systemd service files and init
scripts for smartmontools deamon, in the same package as smartctl itself.

I would suggest moving smartd and its related files to separate package.

Bug#1039453: python3-fasteners: please remove obsolete depedency on python3-six

[Alexandre Detiste]

Package: python3-fasteners
Version: 0.17.3-2
Severity: normal

Please remove obsolete depedency on python3-six,
this package has been completely ported to Python3 for a while.

Greetings,


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

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

Versions of packages python3-fasteners depends on:
ii  python33.11.2-1+b1
ii  python3-monotonic  1.6-2
ii  python3-six1.16.0-4

python3-fasteners recommends no packages.

python3-fasteners suggests no packages.

-- no debconf information

Bug#1039452: python3-cclib: please package new version 1.7.1

[Alexandre Detiste]

Package: python3-cclib
Version: 1.6.2-2
Severity: normal

Please also remove obsolete depedency on python3-six
and add SciPy.

http://cclib.github.io/changelog.html

>Changes in cclib-1.7
> Features
>  Dropping support for Python 2
>  SciPy is now a hard dependency for cclib

Greetings,


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

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

Versions of packages python3-cclib depends on:
ii  python33.11.2-1+b1
ii  python3-numpy  1:1.24.2-1
ii  python3-six1.16.0-4

Versions of packages python3-cclib recommends:
ii  cclib  1.6.2-2

python3-cclib suggests no packages.

-- no debconf information

Bug#1039451: New upstream version 2.8.0

[Xiyue Deng]

Package: elpa-zenburn-theme
Severity: wishlist
Tags: patch

A new upstream version (2.8.0) of zenburn theme is available.  I've created a
pull request at
https://salsa.debian.org/emacsen-team/zenburn-emacs/-/merge_requests/2.  Thanks
for considering!


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

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

Versions of packages elpa-zenburn-theme depends on:
ii  dh-elpa-helper 2.0.16
ii  emacs  1:28.2+1-15
ii  emacs-gtk [emacs]  1:28.2+1-15
ii  emacsen-common 3.0.5

Versions of packages elpa-zenburn-theme recommends:
ii  emacs  1:28.2+1-15
ii  emacs-gtk [emacs]  1:28.2+1-15

elpa-zenburn-theme suggests no packages.

Bug#1039450: ndctl: Split ndctl-monitor (and cxl-monitor?) into own package

[Witold Baryluk]

Package: ndctl
Version: 76.1-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

ndctl and cxl can be used on its own, installation of them should not
imply one wants to run ndctl-monitor (or as I see in version 77 also
cxl-monitor).

Move systemd service units and init scripts to own packages,
ndctl-monitor and cxl-monitor?

Thanks.

Bug#999227: (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path.

[AlMa]

affects 999227 + xterm gdm3
thanks

Any progress?

As of now, Debian stable 12 does NOT contain xfonts-cyrillic, which is 
suggested by xterm 379-1.  Further, gdm-x-session from gdm3 43.0-3 still 
warns us:


Jun 25 20:25:25 AnonymizedMachineName dbus-daemon[973]: [session uid=119 
pid=973] Activating systemd to hand-off: service 
name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' requested by ':1.3' 
(uid=119 pid=961 comm="/usr/libexec/tracker-extract-3")
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(==) No Layout section.  Using the first Screen section.
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(==) No screen section available. Using defaults.
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(**) |-->Screen "Default Screen Section" (0)
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(**) |   |-->Monitor ""
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(==) No monitor specified for screen "Default Screen Section".
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
  Using a default monitor configuration.
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(==) Automatically adding devices
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(==) Automatically enabling devices
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(==) Automatically adding GPU devices
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(==) Automatically binding GPU devices
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(==) Max clients allowed: 256, resource mask: 0x1f
Jun 25 20:25:25 AnonymizedMachineName dbus-daemon[973]: [session uid=119 
pid=973] Successfully activated service 'org.freedesktop.systemd1'
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
Jun 25 20:25:25 AnonymizedMachineName /usr/libexec/gdm-x-session[977]: 
  Entry deleted from font path.

Bug#1039449: fluidsynth: High memory usage even if not used

[Witold Baryluk]

Package: fluidsynth
Version: 2.3.1-2
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

fluidsynth auto-starts on my system when I log in, and that causes it to
read into memory /usr/share/sounds/sf3/default-GM.sf3 (this is a symlink
to /etc/alternatives/default-GM.sf3 which is a symlink to
/usr/share/sounds/sf2/FluidR3_GM.sf2).

About 142 megabytes of it.

-rw-r--r-- 1 root root 142M Feb 24  2008 /usr/share/sounds/sf2/FluidR3_GM.sf2

This causes fluidsynth RSS to use about 165MB of residewnt memory, even
if it is not used for anything.

I do not know why it autostarts, my guess is that pipewire or something
else starts it, even if it is not needed. (it runs as a normal user, not
some system user, and there are no init.d script or systemd units for it
that I can find)

Memory usage, looks to correspond to this memory mapping.

Output of pmap -p $(pidof fluidsynth)

7fdea2389000 144724K rw---   [ anon ]

But there is also many 8M mappings, but they do not contribute to RSS (mapped, 
but not touched).

If I show more info with pmap, I got:

3848:   /usr/bin/fluidsynth -is /usr/share/sounds/sf3/default-GM.sf3
 Address Perm   Offset Device  InodeSizeRssPss Pss_Dirty 
Referenced Anonymous LazyFree ShmemPmdMapped FilePmdMapped Shared_Hugetlb 
Private_Hugetlb Swap SwapPss Locked THPeligible Mapping
...
7fdea2389000 rw-p   00:00  0  144724 144724 144724144724 
1447241447240  0 0  0   
00   0 144724   1 
...


Not only it is fully read, it is mlock-ed (probably to ensure it is not
swapped out, which is important for audio application like this).


It would be desirable in situation like this, to not load whole sf file
by default (just read basic metadata of it), and delay loading, until
there is actually a need for it. Alternatively have them in a format on
disk, that can be mmaped directly. Proper behaviour could be controlled
by some command line flags.

Regards,
Witold

Bug#1039448: python3-uamqp: please package v1.6.4 & rem. dep. on python3-six

[Alexandre Detiste]

Package: python3-uamqp
Version: 1.5.3-1+b4
Severity: normal

Hi,

Please package the new version.

python3-six is not needed anymore as dependency.

a watchfile is welcomed.

Greetings,


https://github.com/Azure/azure-uamqp-python/blob/main/HISTORY.rst

>1.6.4 (2023-02-09)
> Updated OpenSSL dependency to 1.1.1t
> Updated submodules to support OpenSSL 3.0 compilation
> Removed dependency on six  --> XXX
> Fixed a bug that caused the wrong port to selected for websockets when a port 
> was not passed in

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-uamqp depends on:
ii  libc62.36-9
ii  libssl3  3.0.9-1
ii  python3  3.11.2-1+b1
ii  python3-certifi  2022.9.24-1
ii  python3-six  1.16.0-4

python3-uamqp recommends no packages.

python3-uamqp suggests no packages.

-- no debconf information

Bug#1039447: python3-tenacity: please remove obsolete dependency python3-six

[Alexandre Detiste]

Package: python3-tenacity
Version: 8.2.1-1
Severity: normal

All uses of python3-six have been removed quite a while ago:

   https://github.com/jd/tenacity/pull/304

Greetings,

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-tenacity depends on:
ii  python3  3.11.2-1+b1
ii  python3-pbr  5.11.1-2
ii  python3-six  1.16.0-4

python3-tenacity recommends no packages.

Versions of packages python3-tenacity suggests:
pn  python-tenacity-doc  

-- no debconf information

Bug#1039446: python3-qgis: please remove obsolete dependency on python3-six

[Alexandre Detiste]

Package: python3-qgis
Version: 3.28.7+dfsg-1
Severity: normal

QGis has been fully ported to Python3.

Greetings,


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-qgis depends on:
ii  libc62.36-9
ii  libgcc-s113.1.0-6
ii  libpython3.113.11.4-1
ii  libqca-qt5-2 2.3.6-1
ii  libqgis-3d3.28.7 3.28.7+dfsg-1
ii  libqgis-analysis3.28.7   3.28.7+dfsg-1
ii  libqgis-core3.28.7   3.28.7+dfsg-1
ii  libqgis-gui3.28.73.28.7+dfsg-1
ii  libqgis-server3.28.7 3.28.7+dfsg-1
ii  libqgispython3.28.7  3.28.7+dfsg-1
ii  libqscintilla2-qt5-152.13.3+dfsg-3
ii  libqt5core5a 5.15.8+dfsg-12
ii  libqt5gui5   5.15.8+dfsg-12
ii  libqt5network5   5.15.8+dfsg-12
ii  libqt5positioning5   5.15.8+dfsg-3
ii  libqt5svg5   5.15.8-3
ii  libqt5webkit55.212.0~alpha4-30
ii  libqt5widgets5   5.15.8+dfsg-12
ii  libqt5xml5   5.15.8+dfsg-12
ii  libsqlite3-mod-spatialite5.0.1-3
ii  libstdc++6   13.1.0-6
ii  python3  3.11.2-1+b1
ii  python3-dateutil 2.8.2-2
ii  python3-future   0.18.2-6
ii  python3-httplib2 0.20.4-3
ii  python3-jinja2   3.1.2-1
ii  python3-lxml 4.9.2-1+b1
ii  python3-markupsafe   2.1.2-1+b1
ii  python3-owslib   0.29.2-1
ii  python3-plotly   5.4.1+dfsg-1
ii  python3-psycopg2 2.9.5-1+b1
ii  python3-pygments 2.15.1+dfsg-1
ii  python3-pyproj   3.6.0-1
ii  python3-pyqt55.15.9+dfsg-1
ii  python3-pyqt5.qsci   2.13.3+dfsg-3
ii  python3-pyqt5.qtpositioning  5.15.9+dfsg-1
ii  python3-pyqt5.qtsql  5.15.9+dfsg-1
ii  python3-pyqt5.qtsvg  5.15.9+dfsg-1
ii  python3-pyqt5.qtwebkit   5.15.9+dfsg-1
ii  python3-qgis-common  3.28.7+dfsg-1
ii  python3-requests 2.28.1+dfsg-1
ii  python3-six  1.16.0-4
ii  python3-tz   2022.7.1-4
ii  python3-yaml 6.0-3+b2
ii  qgis-providers   3.28.7+dfsg-1

python3-qgis recommends no packages.

python3-qgis suggests no packages.

-- no debconf information

Bug#1039230: ikiwiki-hosting: ships sysv-init script without systemd unit

[Luca Boccassi]

On Mon, 26 Jun 2023 at 00:22, Simon McVittie  wrote:
>
> Version: 0.20220715-1
>
> On Sun, 25 Jun 2023 at 23:23:34 +0100, bl...@debian.org wrote:
> > ikiwiki-hosting has been flagged by Lintian as shipping a sysv-init
> > script without a corresponding systemd unit file.
> ...
> > https://lintian.debian.org/sources/ikiwiki-hosting
>
> Those Lintian checks are very old: it seems we can't assume that
> lintian.debian.org reflects current reality. If you're taking information
> from there for a mass bug filing, please could you at least specify
> the version that was tested in the bug report? (In this case it's
> 0.20180719-2, which is in Debian 11 and was superseded before Debian 12.)

That's unfortunate, I guess lintian.debian.org should not be online if
it's that broken. Who do we ask to take it down? DSA?

> Pages like https://udd.debian.org/lintian/?packages=ikiwiki-hosting appear
> to have more up-to-date Lintian results.

Any idea how to query by tag on that page? The obvious "tag" filter
doesn't seem to work.

Kind regards,
Luca Boccassi

Bug#1039445: python3-plotly: please upload new version an remove python3-plotly dep.

[Alexandre Detiste]

Package: python3-plotly
Version: 5.4.1+dfsg-1
Severity: normal

Hi,

Please package a new version and remove the obsolete python3-six dependency.

Greetings,

>## [5.8.0] - 2022-05-09
>
>### Fixed
>
>  - Resolved various deprecation warning messages
>and compatibility issues with upstream dependencies and Python 3.11,
>plus removed dependency on `six`,...


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-plotly depends on:
ii  python33.11.2-1+b1
ii  python3-decorator  5.1.1-3
ii  python3-nbformat   5.5.0-1
ii  python3-requests   2.28.1+dfsg-1
ii  python3-six1.16.0-4
ii  python3-tenacity   8.2.1-1
ii  python3-tz 2022.7.1-4

python3-plotly recommends no packages.

Versions of packages python3-plotly suggests:
pn  ipython3
ii  python3-ipykernel   6.17.0-1
ii  python3-matplotlib  3.6.3-1+b1
ii  python3-pandas  1.5.3+dfsg-2
ii  python3-scipy   1.10.1-2

-- no debconf information

Bug#1026406: leafnode: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Hi,

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

leafnode (1.12.0-2.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Update po file into Brazilian Portuguese translation. (Closes: 
#1026406)

  * debian/control
- Bump Standards-Version 4.6.2


I attached a debdiff.

Thanks.

Regards,

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450
diff -Nru leafnode-1.12.0/debian/changelog leafnode-1.12.0/debian/changelog
--- leafnode-1.12.0/debian/changelog2023-01-22 08:15:56.0 -0300
+++ leafnode-1.12.0/debian/changelog2023-06-25 20:04:49.0 -0300
@@ -1,3 +1,12 @@
+leafnode (1.12.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update po file into Brazilian Portuguese translation. (Closes: #1026406)
+  * debian/control
+- Bump Standards-Version 4.6.2
+
+ -- Paulo Henrique de Lima Santana (phls)   Sun, 25 Jun 2023 
20:04:49 -0300
+
 leafnode (1.12.0-2) unstable; urgency=medium
 
   * Install a socket-enabled systemd unit:
diff -Nru leafnode-1.12.0/debian/control leafnode-1.12.0/debian/control
--- leafnode-1.12.0/debian/control  2023-01-22 08:15:56.0 -0300
+++ leafnode-1.12.0/debian/control  2023-06-25 20:04:49.0 -0300
@@ -2,7 +2,7 @@
 Section: news
 Priority: optional
 Maintainer: Moritz Muehlenhoff 
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Build-Depends: libpcre2-dev, debhelper-compat (= 13), debhelper
 Homepage: https://www.leafnode.org
 Vcs-Git: https://salsa.debian.org/debian/leafnode.git
diff -Nru leafnode-1.12.0/debian/po/pt_BR.po leafnode-1.12.0/debian/po/pt_BR.po
--- leafnode-1.12.0/debian/po/pt_BR.po  2023-01-22 08:15:56.0 -0300
+++ leafnode-1.12.0/debian/po/pt_BR.po  2023-06-25 20:04:49.0 -0300
@@ -10,28 +10,29 @@
 # or http://www.debian.org/intl/l10n/po-debconf/README-trans
 #
 #Developers do not need to manually edit POT or PO files.
+# Paulo Henrique de Lima Santana (phls) , 2022.
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: leafnode\n"
+"Project-Id-Version: leafnode_1.12.0-1\n"
 "Report-Msgid-Bugs-To: leafn...@packages.debian.org\n"
 "POT-Creation-Date: 2008-02-18 08:13+0100\n"
-"PO-Revision-Date: 2004-08-07 13:32-0300\n"
-"Last-Translator: André Luís Lopes \n"
-"Language-Team: Debian-BR Project \n"
-"Language: \n"
+"PO-Revision-Date: 2022-12-19 13:12-0300\n"
+"Last-Translator: Paulo Henrique de Lima Santana (phls) \n"
+"Language-Team: Brazilian Portuguese \n"
+"Language: pt_BR\n"
 "MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=ISO-8859-1\n"
+"Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=(n > 1)\n"
+"X-Generator: Gtranslator 42.0\n"
 
 #. Type: string
 #. Description
 #: ../templates:2001
-#, fuzzy
-#| msgid "Which news server should Leafnode download news from?"
 msgid "Server to download news from:"
-msgstr ""
-"De qual servidor de notícias o Leafnode deve fazer o download das notícias ?"
+msgstr "Servidor de onde baixar notĂ­cias:"
 
 #. Type: string
 #. Description
@@ -40,6 +41,8 @@
 "The name of the news server should be provided by the organization providing "
 "you with network access, such as your Internet Service Provider."
 msgstr ""
+"O nome do servidor de notícias deve ser fornecido pela organização que "
+"fornece acesso à rede, como seu provedor de serviços de Internet."
 
 #. Type: string
 #. Description
@@ -48,32 +51,26 @@
 "This server is generally called \"news.\" or \"nntp.\" where "
 " is the local domain name."
 msgstr ""
+"Este servidor ĂŠ geralmente chamado de \"news.\" ou \"nntp."
+"\", onde  ĂŠ o nome de domĂ­nio local."
 
 #. Type: boolean
 #. Description
 #: ../templates:3001
 msgid "Enable access controls for Leafnode?"
-msgstr "Habilitar controles de acesso para o Leafnode ?"
+msgstr "Habilitar controles de acesso para o Leafnode?"
 
 #. Type: boolean
 #. Description
 #: ../templates:3001
-#, fuzzy
-#| msgid ""
-#| "If you do not enable some access controls for leafnode, people everywhere "
-#| "will be able to use your news server, for things like posting spam or "
-#| "accessing huge binary newsgroups. People actively scan the net for open "
-#| "news servers."
 msgid ""
 "If you do not enable some access controls for Leafnode, people everywhere "
 "will be able to use the news server which opens opportunities for spamming "
 "or resource abuse."
 msgstr ""
-"Caso vocę năo habilite certos controles de acesso para o Leafnode, pessoas "
-"em qualquer lugar serăo capazes de usar seu servidor de notícias para coisas "
-"ruins como postar spam ou acessar enormes grupos de notícias binários. "
-"Existem pessoas que ativamente procuram através da rede por servidores de "
-"notícias abertos."
+"Se vocĂŞ nĂŁo ativar alguns controles de acesso para o Leafnode, pessoas de "
+"todos os lugares poderĂŁo usar o servidor de notĂ­cias, o que 

Bug#1039444: ITP: node-get-uri -- Returns a `stream.Readable` from a URI string

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-get-uri
  Version : 3.0.0
  Upstream Author : Nathan Rajlich  (http://n8.io/)
* URL : https://github.com/TooTallNate/node-get-uri
* License : Expat
  Programming Lang: JavaScript
  Description : Returns a `stream.Readable` from a URI string

This high-level module accepts a URI string and returns a
Readable stream instance. There is built-in support for a
variety of "protocols", and it's easily extensible with more.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039443: python3-paramiko: please package v3.2.0 an remove python3-six dependency

[Alexandre Detiste]

Package: python3-paramiko
Version: 2.12.0-2
Severity: normal

Hi,

Please uplaod the new version to complete the Py2->3 conversion.

https://bitprophet.org/blog/2021/02/25/byethon2/

You might also close these two Py2 related bugs at the same time:

  #800386  obnam: UnicodeDecodeError python exception during backup
  #947470  paramiko: [Py3] TypeError: a bytes-like object is required,
   not 'str' in pkey.write_private_key()

Greetings,




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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-paramiko depends on:
ii  python3   3.11.2-1+b1
ii  python3-bcrypt3.2.2-1
ii  python3-cryptography  38.0.4-3
ii  python3-nacl  1.5.0-2
ii  python3-six   1.16.0-4

Versions of packages python3-paramiko recommends:
ii  python3-invoke  2.0.0-1

Versions of packages python3-paramiko suggests:
pn  python3-gssapi  

-- no debconf information

Bug#1009290: mariadb-server-10.6: Fails to start on live system

[Witold Baryluk]

Package: mariadb-server
Version: 1:10.11.3-1
Followup-For: Bug #1009290
X-Debbugs-Cc: witold.bary...@gmail.com

Just wwitching to fsync, does not appear to solve the problem either:

root@debian:~# cat  /etc/mysql/mariadb.conf.d/90-live.cnf
[mysqld]
innodb_flush_method = fsync
root@debian:~# 

Jun 25 23:30:03 debian systemd[1]: Starting mariadb.service - MariaDB 10.11.3 
database server...
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] Starting 
MariaDB 10.11.3-MariaDB-1 source revision  as process 1395434
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] InnoDB: 
Compressed tables use zlib 1.2.13
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] InnoDB: 
Number of transaction pools: 1
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] InnoDB: 
Using crc32 + pclmulqdq instructions
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] InnoDB: 
Using liburing
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] InnoDB: 
Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] InnoDB: 
Completed initialization of buffer pool
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [ERROR] InnoDB: 
The Auto-extending data file './ibdata1' is of a different size 0 pages than 
specified by innodb_data_file_path
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [ERROR] InnoDB: 
Plugin initialization aborted with error Generic error
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] InnoDB: 
Starting shutdown...
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [ERROR] Plugin 
'InnoDB' init function returned error.
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [ERROR] Plugin 
'InnoDB' registration as a STORAGE ENGINE failed.
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [Note] Plugin 
'FEEDBACK' is disabled.
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [ERROR] Could 
not open mysql.plugin table: "Table 'mysql.plugin' doesn't exist". Some plugins 
may be not loaded
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [ERROR] 
Unknown/unsupported storage engine: InnoDB
Jun 25 23:30:03 debian mariadbd[1395434]: 2023-06-25 23:30:03 0 [ERROR] Aborting
Jun 25 23:30:03 debian systemd[1]: mariadb.service: Main process exited, 
code=exited, status=1/FAILURE
Jun 25 23:30:03 debian systemd[1]: mariadb.service: Failed with result 
'exit-code'.
Jun 25 23:30:03 debian systemd[1]: Failed to start mariadb.service - MariaDB 
10.11.3 database server.


This is probably, becuase postinst script probably (silently) failed, and
something was not initialized properly during install.

Adding runtime check in that script to detect overlay fs will not be
enough, because it is possible to install mariadb-server in chroot for
live image, which could be on non-overlay fs, but when actually started
it might be on overlay fs.

It would be preferable to do this in startup script instead, but then a
lot of logic would probably need to move from postinst, to startup script.

Bug#1039442: release notes dont mention the security archive

[Richard Lewis]

package: release-notes

I am sure i must be missing something, but i couldnt see anywhere in
the release notes does it explain what the sources.list for security
updates should be.

i was expecting this to be mentioned in one of

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-whats-new.en.html#archive-areas

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-whats-new.en.html#archive-areas
  --- i found this whole subsection pretty cryptic tbh,  "You should
make sure the package database is ready before proceeding with the
upgrade." makes it sound like the user needs to a do something, but
the text doesnt say what. I think this could be much shorter, and
instead of talking about 'databases' just say to open the other
package manager(s) and check there are no pending actions, assuming
that is what it wants me to do

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#upgrade-process

the last one mentions subscribing to the mailing list but doesnt
actually remind anyone to add the security archive area (or remind me
what the syntax is - i assume it's the same as previous releases, but
i remember it changed at least once and was expecting a reminder)

Bug#1039441: python3-pandas: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Package: python3-pandas
Version: 1.5.3+dfsg-2
Severity: normal

python3-six isn't used anywhere anymore for a long time,
please remove it from the dependencies.

Greetings


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pandas depends on:
ii  python33.11.2-1+b1
ii  python3-dateutil   2.8.2-2
ii  python3-numpy  1:1.24.2-1
ii  python3-pandas-lib 1.5.3+dfsg-2
ii  python3-pkg-resources  66.1.1-1
ii  python3-six1.16.0-4
ii  python3-tz 2022.7.1-4

Versions of packages python3-pandas recommends:
pn  python3-bottleneck  
ii  python3-bs4 4.12.2-2
ii  python3-html5lib1.1-3
ii  python3-jinja2  3.1.2-1
ii  python3-lxml4.9.2-1+b1
ii  python3-matplotlib  3.6.3-1+b1
pn  python3-numexpr 
pn  python3-odf 
pn  python3-openpyxl
ii  python3-scipy   1.10.1-2
pn  python3-tables  

Versions of packages python3-pandas suggests:
pn  python-pandas-doc
pn  python3-statsmodels  

-- no debconf information

Bug#1036849: bookworm-pu: package gnome-software/43.5-1~deb12u1

[Simon McVittie]

On Sun, 25 Jun 2023 at 17:13:01 +0100, Jonathan Wiltshire wrote:
> On Wed, Jun 21, 2023 at 11:22:35AM +0100, Simon McVittie wrote:
> > Tested on a bookworm system (browse available packages, upgrade Flatpak
> > apps, install a Flatpak app, install a .deb) and seems fine, and the
> > upstream changes are really minimal, so I uploaded the proposed package.
> 
> It doesn't seem to be in the queue so something has gone wrong with the
> upload. Please check and go ahead.

Sorry, I thought I had uploaded all of the GNOME 43.x bugfix releases that
I prepared so far. Uploaded gnome-software now.

smcv

Bug#1039440: xfwm4: Alt-tab and mouse-down do not shift focus

[bud]

Package: xfwm4
Version: 4.18.0-1
Severity: important
X-Debbugs-Cc: budheal...@gmail.com

Dear Maintainer,

   * What led up to the situation?
I fired jigdo with 2023-06-05 iso DLBDs mounted to scan, to build DVDs. This 
stresses the system, but not seriously. Since the scan step takes 40-45 
minutes, the screen goes to sleep. System Monitor shows there is plenty of RAM 
but 1 or 2 of the CPU threads (of 8) are maxed. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
When awakening the screen, which is more or less instant upon moving the mouse, 
before jigdo-lite finishes (many hours on) a mousedown will not activate other 
windows. Sometimes it will take a few minutes to start recognize mouse clicks, 
although then it is responsive. Using alt-tab will activate a window, but 
clicks are ignored. The mouse wheel will scroll the old focus. For instance, to 
search related bugs I used alt-tab to activate a browser window and used 
keyboard navigation to look through the list.
Similar bugs are #629873 and #640842, but they do not mention trouble with 
alt-tab navigation.
As I am typing, I closed a number of applications and windows. Thunar hung on a 
window for an afp: server; I had disconnected the Ethernet in favor of a 
different network. This might be a part of the recipe but does not seem to be a 
part of the pudding.
   * What was the outcome of this action?
The window manager goes on vacation. Even pressing the Power button had no fast 
response. I had to use tab to select Hibernate. Upon resumption, the error 
status was unaffected. Is the window manager getting lost in its events?
   * What outcome did you expect instead?
XFCE should maintain focus in the active window and shift when activating a 
different one.

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

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

Versions of packages xfwm4 depends on:
ii  libc6 2.36-9
ii  libcairo2 1.16.0-7
ii  libepoxy0 1.5.10-1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-2
ii  libgtk-3-03.24.37-2
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libstartup-notification0  0.12-6+b1
ii  libwnck-3-0   43.0-3
ii  libx11-6  2:1.8.4-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.6-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfce4ui-2-04.18.2-2
ii  libxfce4util7 4.18.1-2
ii  libxfconf-0-3 4.18.0-2
ii  libxfixes31:6.0.0-2
ii  libxinerama1  2:1.1.4-3
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.2-2+b1
ii  libxrender1   1:0.9.10-1.1
ii  libxres1  2:1.2.1-1

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.54.5+dfsg-1

Versions of packages xfwm4 suggests:
ii  xfce4  4.18

-- no debconf information

Bug#1039350: rng-tools-debian: ships sysv-init script without systemd unit

[Thorsten Glaser]

retitle 504044 rng-tools-debian: figure out how to best start this
forcemerge 504044 1039350
thanks

bl...@debian.org dixit:

>rng-tools-debian has been flagged by Lintian as shipping a sysv-init
>script without a corresponding systemd unit file.

It does. However, the situation of how to best start it is still
unclear, unfortunately; see #504044 for the discussion.

I’m totally wary of adding things until that’s solved, so the
situation isn’t complicated even more.

I’m open for suggestions how to deal with the issues listed while
keeping it working for all current use cases (ideally with patches,
I’m very much not in the habit of writing systemd init scripts).

Note that this is the “legacy or special-needs users only” package;
“normal” users, on modernish systems, would use the rng-tools5
package instead, so this is not pressing (I’d even wager a good
percentage of its users start it manually).

Thanks,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#1039439: berusky: FTBFS with libsdl1.2-compat-dev: did you forget to '#include '?

[Simon McVittie]

Source: berusky
Version: 1.7.2-2
Severity: important
Tags: ftbfs trixie sid

I tried recompiling berusky with libsdl1.2-compat-dev instead of
libsdl1.2-dev, in preparation for having src:sdl12-compat take over the
libsdl1.2-dev package name.

It fails to compile with:

> In file included from stack.h:31,
>  from level_game.h:32,
>  from berusky.h:131:
> level_game.cpp: In constructor 
> 'level_generic::level_generic(ITEM_REPOSITORY*)':
> level_game.cpp:107:29: error: expected primary-expression before ',' token
>   107 |   assert(offsetof(LEVEL_DISK, signum) == 0);
>   | ^
> level_game.cpp:107:31: error: 'signum' was not declared in this scope; did 
> you mean 'signed'?
>   107 |   assert(offsetof(LEVEL_DISK, signum) == 0);
>   |   ^~
> level_game.cpp:107:10: error: 'offsetof' was not declared in this scope
>   107 |   assert(offsetof(LEVEL_DISK, signum) == 0);
>   |  ^~~~
> level_game.cpp:35:1: note: 'offsetof' is defined in header ''; did 
> you forget to '#include '?
>34 | #include "berusky.h"
>   +++ |+#include 
>35 | 

Adding #include  according to the compiler's hint fixes the FTBFS.

I'll ask sdl12-compat upstream to add  to the sdl12-compat
headers, but please fix this in berusky anyway, because  is
preferred for C++ code (and SDL is C code).

Thanks,
smcv

Bug#1038419: installation-reports: [arm64] Installation hangs on "Configuring grub-efi-arm64 (arm64)"

[Cyril Brulebois]

Control: reassign -1 src:linux 6.1.27-1
Control: affects -1 debian-installer installation-reports

Hi Joel,

Joel May  (2023-06-25):
> This bug was fixed in kernel version 6.1.33 by commit
> e8631d84c01ece34670af0d300a6f88d86d12f70.  I compiled from source and
> confirm that the problem is indeed fixed in 6.1.33.
> 
> The root of the problem is that the "family" in the SMBIOS is "Lenovo
> ThinkSystem HR330A/HR350A" not "eMAG", so a workaround broken
> SetVirtualAddressMap() is not applied.

Oh wow, thanks for tracking this down.

> I now see that this bug applies to more than installer, that just
> happened to be where I first was blocked by it.  I'm not sure if I
> can/should reclassify this bug report to the kernel package.

Let's reassign so that it can be documented as fixed in a further
upload, to be included into stable via a point release, at which point
the installer will be rebuilt against it… while leaving some pointers
for others to find.


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


signature.asc
Description: PGP signature

Bug#1034847: First commit

[Guilhem Moulin]

Hi,

On Sun, 25 Jun 2023 at 21:19:10 +, Bastien Roucariès wrote:
> I found the commit that remove the stack overlfow check line 688
> https://github.com/lua/lua/commit/287b302acb8d925178e9edb800f0a8d18c7d35f6

That also matching my finding from https://bugs.debian.org/1034847#12 .
Asked for confirmation upstream at 
http://lua-users.org/lists/lua-l/2023-06/msg00059.html
and waiting for a reply.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1039438: enigma: Embded and use lua copy (outdated)

[Bastien Roucariès]

Source: enigma
Severity: serious
Tags: security
Justification: embded
X-Debbugs-Cc: Debian Security Team 

Dear Maintainer,

You ship a outdated and embed lua:
- could you use the system library
- repack in order to avoid compiling accidentally the embded version

Bastien


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

Kernel: Linux 6.1.0-9-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Bug#1039437: emscripten: Status of tests/third_party/

[Bastien Roucariès]

Source: src:emscripten
Severity: important

Dear Maintainer,

A few system library are embdeded in tests/third_party/ and seems to be shipped
as example. It is not really good for a security point of view

Could you:
- try to repack and avoid this
- use embded library if possible

rouca


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

Kernel: Linux 6.1.0-9-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Bug#1039257: reassign

[Bastien Roucariès]

control: reassign -1 src:eja

Bug#1039406: ppx-base FTBFS on bytecode architectures

[Adrian Bunk]

Source: ppx-base
Version: 0.16.0-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ppx-base=0.16.0-1

...
   dh_install -a
dh_install: warning: Cannot find (any matches for) 
"/usr/lib/ocaml/ppx_base/*.a" (tried in ., debian/tmp)

dh_install: warning: libppx-base-ocaml-dev missing files: 
/usr/lib/ocaml/ppx_base/*.a
dh_install: error: missing files, aborting
make: *** [debian/rules:6: binary-arch] Error 25

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 25 Jun 2023 at 19:24, Luca Boccassi  wrote:
>
> On Sun, 25 Jun 2023 at 19:21, Russ Allbery  wrote:
> >
> > Luca Boccassi  writes:
> >
> > > systemd upstream will drop support for the transitional sysv generator
> > > in the near future. The transition is long finished, it's been at least
> > > a decade, and it's time for the tail of packages still shipping only
> > > init scripts but not units to be updated.
> >
> > Has there already been a mass bug filing for packages that ship init
> > scripts but not systemd unit files?
>
> It has not, I'll get that sorted first then, thanks

Done and done:

https://lists.debian.org/debian-devel/2023/06/msg00291.html
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=missing-systemd-service

Kind regards,
Luca Boccassi

Bug#1039257: eja: Please repack in order to avoid lua

[Bastien Roucariès]

Source: src:eja
Severity: important

Dear Maintainer,

Could you repack in order to avoid to ship lua.

It will avoid false positive for shipping lua and avoid to accidentally compile
local lua instead of packaged lua

Thanks

Rouca


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

Kernel: Linux 6.1.0-9-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Bug#1039047: bookworm-pu: package cvs/2:1.12.13+real-28+deb12u1

[Thorsten Glaser]

Jonathan Wiltshire dixit:

>Please go ahead.

Thanks, uploaded.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1029939: shaderc support for mpv

[Shmerl]

Any news on this?

In general, it seems these kind of issues are common for shaderc - glslang
integration.
Some similar bugs were reported elsewhere.

For the reference:

* https://bugs.archlinux.org/task/70990
* https://github.com/mpv-player/mpv/issues/8945
* https://github.com/KhronosGroup/glslang/issues/1484

And etc.

Shmerl.

Bug#1039119: darktable: use packaged lua

[Bastien Roucariès]

Source: darktable
Version: Use packaged lua
Severity: serious
Justification: embded code copy

Dear Maintainer,

It appear that your package embded and compile lua

Could you:
- use the packaged lua lib
- repack in order to avoid accidental reintroduction of compiling lua

rouca


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

Kernel: Linux 6.1.0-9-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Bug#1039118: blobby: Please repack in order to avoid to ship source copy of lua

[Bastien Roucariès]

Source: blobby
Severity: important

Dear Maintainer,

Could you consider to repack in order to avoid to ship a non compiled lua ?

It is alway better to repack in this case, it avoid accidental compilation of
this embded library.

Rouca


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

Kernel: Linux 6.1.0-9-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Bug#1038926: cvs fails with "rsh: No host specified!"

[Thorsten Glaser]

tags 1038926 = bullseye-ignore
thanks

Dixi quod…

>Even if changing the configure argument fixes this, it’ll be hard to
>get this updated in stable post-release. I can try but ⓐ don’t hold

It looks like it ⓐ does fix this and ⓑ will get included in
one of the next point releases for bookworm, maybe even 12.1
already. As bullseye still ships rsh, it doesn’t need fixing.

bye,
//mirabilos
-- 
00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx
21:34⎜ mirabilos: whoa that's sweet
21:52⎜«garrett__:#cvs» much appreciated  «garrett__:#cvs» thanks for your time
23:39⎜ this worked, thank you very much 16:26⎜ ok

Bug#1039117: bam: Please repack in order to avoid lua

[Bastien Roucariès]

Source: bam
Severity: important

Dear Maintainer,

Could you consider to repack in order to avoid third party library like lua.

Even if they are not compiled, it could be accidentally compiled and thus is
not best pratice

Thanks

Rouca


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

Kernel: Linux 6.1.0-9-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Bug#1039116: ardour: Please repack without third party library

[Bastien Roucariès]

Source: ardour
Version: Please repack without third party library
Severity: important

Dear Maintainer,

I was checking if your are affected by a lua security bug. It will be nice if
you could strip (repack with +ds suffix) third party library.

It is a good pratice to not ship third party library when you use system
library:
- in case of security bug it is less work (no need to check build log)
- do not introduce accidental compilation of third party library in case of
upstream modification.

Rouca


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

Kernel: Linux 6.1.0-9-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Bug#1034847: First commit

[Bastien Roucariès]

Hi,

I found the commit that remove the stack overlfow check line 688
https://github.com/lua/lua/commit/287b302acb8d925178e9edb800f0a8d18c7d35f6

Thus first introduced (if no backport) after  5.4.2

Bastien

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

Bug#1039115: ppx-assert FTBFS on bytecode architectures

[Adrian Bunk]

Source: ppx-assert
Version: 0.16.0-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ppx-assert=0.16.0-1

...
   dh_install -a
dh_install: warning: Cannot find (any matches for) 
"/usr/lib/ocaml/ppx_assert/*.a" (tried in ., debian/tmp)

dh_install: warning: libppx-assert-ocaml-dev missing files: 
/usr/lib/ocaml/ppx_assert/*.a
dh_install: warning: Cannot find (any matches for) 
"/usr/lib/ocaml/ppx_assert/runtime-lib/*.a" (tried in ., debian/tmp)

dh_install: warning: libppx-assert-ocaml-dev missing files: 
/usr/lib/ocaml/ppx_assert/runtime-lib/*.a
dh_install: error: missing files, aborting
make: *** [debian/rules:6: binary-arch] Error 25

Bug#1037486: new upstream (3.5)

[Sebastien Badia]

On Tue, Jun 13, 2023 at 01:59:13PM (+0200), Daniel Baumann wrote:
> Hi,
> 
> thank you so much for maintaining rspamd in debian.
> 
> Some time ago, there was a new upstream release with some nice new
> features. It would be nice if you could update the package to the
> current version (3.5).

Hi Daniel,

Thank you for your message,
Indeed with bookworm freeze, I postponed 3.5; but it's now the time!

Regards,


signature.asc
Description: PGP signature

Bug#1039064: binutils-msp430: file conflict with binutils-x86-64-linux-gnu

[Vagrant Cascadian]

On 2023-06-25, Ingo Saitz wrote:
> libdeb.so is both in binutils-x86-64-linux-gnu and binutils-msp430 in
> the same location. This was not the case in ~ti1, where libdeb.so was in
> /usr/lib/bfd-plugins/libdep.so. Thus the upgrade fails:
>
> Preparing to unpack .../binutils-msp430_2.24~ti2_amd64.deb ...
> Unpacking binutils-msp430 (2.24~ti2) over (2.24~ti1) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/binutils-msp430_2.24~ti2_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/bfd-plugins/libdep.so', which 
> is also in package binutils-x86-64-linux-gnu 2.40.50.20230622-1
> Errors were encountered while processing:
>  /var/cache/apt/archives/binutils-msp430_2.24~ti2_amd64.deb

Thanks for the report!

My bad, this points to some even deeper problems with the updates to
this package...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1038813: bullseye-pu: package aide/0.17.3-4+deb11u2

[Adam D. Barratt]

On Sun, 2023-06-25 at 20:15 +0200, Marc Haber wrote:
> On Sun, Jun 25, 2023 at 05:29:12PM +0100, Adam D. Barratt wrote:
> > On Sat, 2023-06-24 at 11:43 +0200, Marc Haber wrote:
> > > On Sat, Jun 24, 2023 at 10:13:58AM +0100, Adam D. Barratt wrote:
> > > > I was about to say "nothing other than a little more patience",
> > > > given
> > > > the request is only a few days old at this point. Looking back,
> > > > however, it appears that there isn't actually a debdiff
> > > > attached,
> > > > as
> > > > was claimed in the original mail.
> > > 
> > > I apologize. Here we go.
> > > 
> > 
> > Thanks. Please go ahead.
> 
> Done.
> 
> One more question that might be a good candidate for more in-depth
> docs:
> With both the bullseye and bookworm versions having been accepted to
> the
> respective proposed-updates repository, there is no longer need to
> hold
> back uploads to unstable, right? I can resume normal work on the
> packages after the acceptance of the package for bullseye?
> 

There's no need to block uploads to unstable on anything happening in
(o)pu, no. The only requirement is that if the issue also affects
unstable then it be fixed there first. Presumably future uploads to
unstable wouldn't revert any fixes.

Regards,

Adam

Bug#1039114: python3-zstd uses a vendored copy of libzstd

[Adrian Bunk]

Package: python3-zstd
Severity: normal
X-Debbugs-Cc: t...@security.debian.org

python3-zstd uses a vendored copy of libzstd, and might
therefore have unfixed CVEs:
https://security-tracker.debian.org/tracker/source-package/libzstd

Linking with the system libzstd (as is supported by the upstream
build system) works for me, please consider doing that so that
python3-zstd will benefit from security fixes to src:libzstd.

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Simon McVittie]

On Sun, 25 Jun 2023 at 18:51:24 +0100, Luca Boccassi wrote:
> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to
> depend on such a backward compat tool, so packages needing this
> hyptothetical package should depend explicitly on it.

I think it's maybe worth mentioning (not in Policy, but in the mass
bug filing about deprecating the generator) that there is an immediate
concrete benefit of moving from the generated unit to a maintainer-written
unit: it lets systemd know whether the service is meant to be a one-time
action like /etc/init.d/sudo (Type=oneshot, RemainAfterExit=yes), or
a long-running daemon like /etc/init.d/ssh (Type=forking or similar,
RemainAfterExit=no).

systemd's generator can't know which one of those each service is meant
to be (because LSB init scripts don't distinguish), so it has to make
pessimistic assumptions that work but are non-ideal in both cases.

smcv

Bug#1039113: discover-pkginstall.8: some remarks and a patch for the manual

[Bjarni Ingi Gislason]

Package: debianutils
Version: 5.7-0.4
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and a fix for the man page.



The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff using

"groff -man -Z" instead of "nroff -man"

#

  Spelling mistakes:

intsall
pkgintsall

#

  Only "skipping paragraph ..." is in the patch.

  Use "sed" to remove trailing space.

  Use "git apply ... --whitespace=fix" to fix extra space issues, or
use global configuration "core.whitespace".

  Report defects to the creator.

27:.\" created by instant / docbook-to-man, Sun 13 Jan 2008, 09:40 


Output from "mandoc -T lint discover-pkginstall.8":

mandoc: discover-pkginstall.8:1:2: WARNING: missing date, using "": TH
mandoc: discover-pkginstall.8:1:31: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:2:12: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:3:83: STYLE: input text line longer than 80 
bytes: discover-pkginstall ...
mandoc: discover-pkginstall.8:3:83: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:4:16: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:5:2: WARNING: skipping paragraph macro: PP after 
SH
mandoc: discover-pkginstall.8:5:4: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:6:47: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:7:19: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:8:2: WARNING: skipping paragraph macro: PP after 
SH
mandoc: discover-pkginstall.8:8:4: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:9:49: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:10:65: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:11:61: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:12:64: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:13:64: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:14:30: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:15:15: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:16:19: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:17:32: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:18:19: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:19:25: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:20:51: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:21:6: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:22:19: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:23:12: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:24:16: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:25:2: WARNING: skipping paragraph macro: PP after 
SH
mandoc: discover-pkginstall.8:25:4: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:26:46: STYLE: whitespace at end of input line
mandoc: discover-pkginstall.8:27:64: STYLE: whitespace at end of input line

###

Reduce space between words.

6:\fBdiscover-pkginstall\fR [\-l]  [\-n]  [\-v]  

#

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

16:.IP "\fB-l\fP" 10 
18:.IP "\fB-n\fP" 10 
22:.IP "\fB-v\fP" 10 

#

The name of a man page is set in bold type and the section in roman (see
man-pages(7)).

26:aptitude(8), discover(1), module-assistant(8) 

#

  Not in the patch.

[ "test-groff" is a developmental version of "groff" ]

Input file is ./discover-pkginstall.8

Output from "test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w-z -rSTYLECHECK=3":

an.tmac::1: style: .TH missing third argument; suggest document
modification date in ISO 8601 format (-MM-DD)

an.tmac::1: style: .TH missing fourth argument; suggest
package/project name and version (e.g., "groff 1.23.0")



--- discover-pkginstall.8   2023-06-25 19:23:06.0 +
+++ discover-pkginstall.8.new   2023-06-25 19:53:03.0 +
@@ -1,11 +1,9 @@
-.TH "discover-pkgintsall" "8" 
+.TH "discover-pkginstall" "8" 
 .SH "NAME" 
-discover-pkginstall \(em intsall packages for available hardware using 
discover(1) 
+discover-pkginstall \(em install packages for available hardware using 
discover(1) 
 .SH "SYNOPSIS" 
-.PP 
-\fBdiscover-pkginstall\fR [\-l]  [\-n]  [\-v]  
+\fBdiscover-pkginstall\fR [\-l] [\-n] [\-v]  
 .SH "Description" 
-.PP 
 \fBdiscover-pkginstall\fR install packages based 
 on detected hardware.  It will use the discover-data database to 
 map for hardware to debian packages, install the packages by 
@@ -13,15 +11,16 @@ default.  Packages using module-assistan
 built and the result installed if module-assistant is installed 
 or pulled in as a dependency. 
 .SH "Options" 
-.IP "\fB-l\fP" 10 
+.IP "\fB\-l\fP" 10 
 Only list the 

Bug#1039112: ITP: r-cran-chk -- GNU R check user-supplied function arguments

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-chk -- GNU R check user-supplied function arguments
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-chk
  Version : 0.9.0
  Upstream Author : Joe Thorley,
* URL : https://cran.r-project.org/package=chk
* License : MIT
  Programming Lang: GNU R
  Description : GNU R check user-supplied function arguments
 For developers to check user-supplied function arguments.  It
 is designed to be simple, fast and customizable.  Error messages
 follow the tidyverse style guide.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-chk

Bug#1039111: ITP: ospray -- Open, Scalable, and Portable Ray Tracing Engine

[Francois Mazen]

Package: wnpp
Severity: wishlist
Owner: Francois Mazen 
X-Debbugs-Cc: debian-de...@lists.debian.org, franc...@mzf.fr

* Package name: ospray
  Version : 2.11.0
* URL : https://www.ospray.org/
* License : Apache 2.0
  Programming Lang: C++
  Description : Open, Scalable, and Portable Ray Tracing Engine

Intel OSPRay is an open source, scalable, and portable ray tracing engine for
high-performance, high-fidelity visualization on Intel Architecture CPUs.
OSPRay is part of the Intel oneAPI Rendering Toolkit and is released under the
permissive Apache 2.0 license.
The purpose of OSPRay is to provide an open, powerful, and easy-to-use
rendering library that allows one to easily build applications that use ray
tracing based rendering for interactive applications (including both surface-
and volume-based visualizations). OSPRay is completely CPU-based, and runs on
anything from laptops, to workstations, to compute nodes in HPC systems.

OSPRay is very popular in scientific visualization community and several
packages in the Debian archive would benefit from it like VTK, ParaView or F3d.

OSPRay package depends on Embree with ISPC enabled build (#956816), rkcommon
(#1039110), and optional dependencies like Open VKL (https://www.openvkl.org/)
or Open Image Denoise (https://www.openimagedenoise.org/). I plan to package
and upload the mandatory dependencies first then package OSPRay and finally
package the optional dependencies.

I already have an experimental package working at
https://salsa.debian.org/mzf/ospray (it requires special build of embree with
ispc) and I plan to maintain this package myself. However, I'm open to co-
maintenance and team maintenance if it someone volunteers.

Bug#1038990: transition: liblc3 1.0.3

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-06-24 09:03:55 +0200, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> Please schedule a transition slot for liblc3 1.0.3.
> 
> The auto-generated ben tracker looks good:
> https://release.debian.org/transitions/html/auto-liblc3.html
> 
> The unique reverse dep (pipewire) builds fine with the
> new liblc3 in experimental.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1037474: marked as done (transition: openmm)

[Sebastian Ramacher]

Control: reopen -1

> From: Sebastian Ramacher 
> To: Andrius Merkys , 1037474-d...@bugs.debian.org
> Subject: Re: Bug#1037474: transition: openmm
> Message-ID: 
> 
> On 2023-06-20 23:50:00 +0200, Sebastian Ramacher wrote:
> > Control: tags -1 confirmed
> > 
> > On 2023-06-13 11:20:02 +0300, Andrius Merkys wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > Hello,
> > > 
> > > I would like to request a transition slot for openmm
> > > (experimental -> unstable) due to soname bump. Current ben tracker [1]
> > > is OK.
> > 
> > Please go ahead
> 
> python-pdbfixer seems to need a sourceful upload due to the
> python3-simtk => python3-openmm rename.

Reopening. Closed by mistake

-- 
Sebastian Ramacher

Bug#1039110: ITP: rkcommon -- Intel oneAPI Rendering Toolkit common C++/CMake infrastructure

[Francois Mazen]

Package: wnpp
Severity: wishlist
Owner: Francois Mazen 
X-Debbugs-Cc: debian-de...@lists.debian.org, franc...@mzf.fr

* Package name: rkcommon
  Version : 1.11.0
* URL : https://github.com/ospray/rkcommon
* License : Apache-2.0
  Programming Lang: C++
  Description : Intel oneAPI Rendering Toolkit common C++/CMake
infrastructure

This project represents a common set of C++ infrastructure and CMake utilities
used by various components of Intel® oneAPI Rendering Toolkit. I plan to
package it because it's a dependency of OSPRay (https://www.ospray.org/) which
I also plan to package.

Although I would maintain this package myself, I'm also open to any
collaborative maintenance (Team or co-maintainers).

I already have a basic package working here:
https://salsa.debian.org/mzf/rkcommon

Bug#1039008: M365-IMAP

[ael]

I completely forgot to mention that I was/am using M365-IMAP with
offlineimap to access the MS servers. However the problem seems to 
have been transient and has not recurred, so I intend to close this bug
in the near future.

Bug#1039109: RFP: findjava -- java application startup script helper

[Loïc Rouchon]

Package: wnpp
Severity: wishlist

* Package name: findjava
  Version : 0.3.2
  Upstream Author : Loïc Rouchon
* URL : https://github.com/loicrouchon/findjava
* License : Apache-2.0
  Programming Lang: Go/Java
  Description : java application startup script helper

findjava is a tool whose goal is to find the best-installed java
to run your java application according to your program's specific
constraints.

Requiring a particular version of java to be installed is a job
for a package manager. However once installed, it is still a difficult
task to locate the proper one when multiple versions are installed.
This makes the java packaging experience extremely complicated
and/or the user experience quite bad if relying on the version in $PATH
as it could fail depending on which version is currently in the $PATH.

The current solution is to rely on the java-wrapper package to find
the appropriate version to use for a java program.

findjava provides an improved alternative to the java-wrappers package
as it:

* supports specifying not only the minimum java version required
but also the maximum version supported.
* is cross-platform meaning it will ease writing start scripts for
java applications as the same mechanism (findjava) can be used for
Debian, fedora, macOS, ...
* can find not only java, but javac, or the path to a java
installation having multiple of those programs

It also allows the system to specify system-level constraints
which can be overridden on a per-program basis giving control to
Debian for specifying the version range for the whole system
while allowing specific packages requiring special configuration
to opt out if needed.

findjava has been started following the discussion "Packaging
applications with JVM version restrictions"
(https://lists.debian.org/debian-java/2023/04/msg3.html and
https://lists.debian.org/debian-java/2023/05/msg4.html)

## Open for feedback

I'm the main developer behind findjava. So far, I did not get
any feedback from Debian developers but I'm more than happy to
improve the findjava to meet the specific needs of Debian
developers/maintainers.

## Technical details:

It is written in Go to minimize the overhead required during
the resolution of the requested java version. It typically
takes 5 to 20ms to find the proper java version on an old
Intel i5-7200U after the initial lookup.

The initial lookup is slightly longer as it requires extracting
the java version and other metadata from the found JREs. findjava
performs this extraction by running a single java class against
the discovered JREs. This takes around 200ms per JRE but is only
computed if a new JRE is discovered or one is updated.

## Packaging

I have no experience when it comes to packaging for Debian, hence
the RFP. I however already made a source package for Ubuntu that
I uploaded to launchpad: findjava - 0.3.1-1~lunar
https://launchpad.net/~loicrouchon/+archive/ubuntu/symly/+packages

I hope this helps

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Otto Kekäläinen]

Hi!

> That MR looks sane; please prepare a backport of 1:10.11.4-1 and send a
> confirmation source debdiff, and it can most likely be waved through.

Thanks for confirmation/guidance.

This is now on my TODO to be done immediately when I return from a
vacation trip in about a week.

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 25 Jun 2023 at 19:26, Ansgar  wrote:
>
> Hi,
>
> On Sun, 2023-06-25 at 18:51 +0100, Luca Boccassi wrote:
> > Patch attached and pushed to
> > https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=hea
>
> I support this as using the compat layer with systemd-sysv-generator
> has some limitations that confuse users (e.g., behavior of "start" as
> the unit stays running due to RemainAfterExit=yes set).  We should
> really aim at providing native systemd units.
>
> There is one part I think should not be changed: we currently don't
> require integration with service management at all. That should
> probably not be changed.  So please consider reverting
>
> +---
> | Packages that include system services must include ``systemd`` service
> +---
>
> to the original
>
> +---
> | Packages that include system services should include ``systemd`` service
> +---

How about:

-Packages that include system services should include ``systemd`` service
-units to start or stop those services.
+Packages shipping system services should integrate with service management.
+If they choose to do so, they must include ``systemd`` service units to start
+or stop those services.

Kind regards,
Luca Boccassi
From 73ff234d23464acdcc08c78312c267d51749c64e Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Sun, 25 Jun 2023 18:42:29 +0100
Subject: [PATCH] system services: make systemd units mandatory

systemd upstream will drop support for the transitional sysv generator
in the near future. The transition is long finished, and it's time for
the tail of packages still shipping only init scripts but not units to
be updated.
---
 policy/ch-opersys.rst | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 207b3c0..af4b159 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -328,15 +328,12 @@ Starting system services
 Introduction
 
 
-Packages that include system services should include ``systemd`` service
-units to start or stop those services.  See :manpage:`systemd.service(5)`
-for details on the syntax of a service unit file.  In the common case that
-a package includes a single system service, the service unit should have
-the same name as the package plus the ``.service`` extension.
-
-If the package does not include a service unit (if, for example, no one
-has yet written one), including an init script, as described below, to
-start the service is encouraged.
+Packages shipping system services should integrate with service management.
+If they choose to do so, they must include ``systemd`` service units to start
+or stop those services.  See :manpage:`systemd.service(5)` for details on the
+syntax of a service unit file.  In the common case that a package includes a
+single system service, the service unit should have the same name as the
+package plus the ``.service`` extension.
 
 Packages including a service unit may optionally include an init script to
 support other init systems.  In this case, the init script should have the
@@ -345,13 +342,13 @@ it and use the service unit instead.  Packages may also support other init
 systems by including configuration in the native format of those init
 systems.
 
-If a service unit is not present, ``systemd`` uses dependency information
-contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide
-which scripts to run and in which order.  The ``sysv-rc`` runlevel system
-for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which
-scripts to run and in which order at boot time and when the init state (or
-"runlevel") is changed.  See the ``README.runlevels`` file shipped with
-``sysv-rc`` for implementation details.  Other alternatives might exist.
+``systemd`` uses dependency and ordering information contained within the
+enabled unit files to decide which services to run and in which order.
+The ``sysv-rc`` runlevel system for ``sysvinit`` uses symlinks in
+``/etc/rcn.d`` to decide which scripts to run and in which order at boot
+time and when the init state (or "runlevel") is changed.  See the
+``README.runlevels`` file shipped with ``sysv-rc`` for implementation details.
+Other alternatives might exist.
 
 The sections below describe how to write those scripts and configure those
 symlinks.
-- 
2.39.2

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Ansgar]

Hi,

On Sun, 2023-06-25 at 18:51 +0100, Luca Boccassi wrote:
> Patch attached and pushed to
> https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=hea

I support this as using the compat layer with systemd-sysv-generator
has some limitations that confuse users (e.g., behavior of "start" as
the unit stays running due to RemainAfterExit=yes set).  We should
really aim at providing native systemd units.

There is one part I think should not be changed: we currently don't
require integration with service management at all. That should
probably not be changed.  So please consider reverting

+---
| Packages that include system services must include ``systemd`` service
+---

to the original

+---
| Packages that include system services should include ``systemd`` service
+---

Ansgar

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 25 Jun 2023 at 19:21, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > systemd upstream will drop support for the transitional sysv generator
> > in the near future. The transition is long finished, it's been at least
> > a decade, and it's time for the tail of packages still shipping only
> > init scripts but not units to be updated.
>
> Has there already been a mass bug filing for packages that ship init
> scripts but not systemd unit files?

It has not, I'll get that sorted first then, thanks

Kind regards,
Luca Boccassi

Bug#1039107: RM: libjodycode [all] -- NBS; binary-all packages no longer built

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

binary-all packages are no longer built (only binary-any),
which requires manual cruft removal of the stale
binary-all packages libjodycode2 and libjodycode2-dev.

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Luca Boccassi  writes:

> systemd upstream will drop support for the transitional sysv generator
> in the near future. The transition is long finished, it's been at least
> a decade, and it's time for the tail of packages still shipping only
> init scripts but not units to be updated.

Has there already been a mass bug filing for packages that ship init
scripts but not systemd unit files?

> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to
> depend on such a backward compat tool, so packages needing this
> hyptothetical package should depend explicitly on it. This is just
> mentioned for completeness, it's been at least a decade and writing a
> unit file is beyond trivial so there shouldn't be any issue adding the
> few remaining ones.

> Once the policy is updated I plan to ask Lintian to bump the severity
> of the existing check:

> https://salsa.debian.org/lintian/lintian/-/merge_requests/407

Assuming the mass bug filing hasn't already happened and I missed it, I
think this is the wrong order.  This sort of large-scale breaking change
should always start with a mass bug filing against all affected packages.
I think the right process is:

* Raise this in debian-devel and propose a mass bug filing requiring all
  packages to add systemd unit files if they currently only have init
  scripts.  This gives people the opportunity to object or take over
  maintenance of the unit file generator and document how to depend on it
  if they wish to do that instead.  (I don't think that's a good idea, but
  we should let the discussion happen.)

* Unless something surprising happens in that discussion, do a mass bug
  filing for this transition and bump the Lintian severity at the same
  time.

* Once that has consensus and is underway, *then* change Policy to reflect
  this project decision.

If the mass bug filing already happened and I just didn't notice, my
apologies.

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

Bug#1039106: transition: tinygltf

[Timo Röhling]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: tinyg...@packages.debian.org
Control: affects -1 + src:tinygltf

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I want to transition tinygltf after a SONAME bump. I confirmed that
Open3D builds with the new release on amd64. The Ben tracker is good:

https://release.debian.org/transitions/html/auto-tinygltf.html

Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSYhTcACgkQ+C8H+466
LVlRrgv/YwCR/B5Z73XK09kHIrI+WrsOmA1Sjegx16OYAqkLhFJsUeJuXmkl6UO7
c/lXZw6OOcpiN0aiJOzmetzAGomdHFylXrDop5X1Z/1T/1PaTMIasxrk/uAmxVy9
vfDfAIgZ9geBfY+ni0pCFsP5ZApuvp8eEMVv8fbZRyt9uBCt2brg8qu0kYuO0KSZ
WDix8208Vq03HwQbvacMoUbamK1EpzjgxAb9MTZKPhojRYyMOfiSYenmILDkU6Lz
Lg0p/uW13w6Q+EQMNTcua4gGeEknmMWKuyNk0N5tadcuMQ+IECL+sLGpR/2a8vAZ
apajqlPdg0DDCNWbICx5+btfAe6xMMTPZuxPHlr0ic/qeHNjfpqX6ccMlBrpdNoj
oIh56y24+Hii2A4KHLYjT4xzpdUONNcuQ6CF3eKI79paWkKuHLpfx6Xd/8lqX05V
yxBPPCZrRxIHtrsTpmKOr5Q1VgCVkJLP8T+J7o59VWg9X7Frg78YhyM9fdqeu3bm
58kRNFB9
=TeRm
-END PGP SIGNATURE-

Bug#1038813: bullseye-pu: package aide/0.17.3-4+deb11u2

[Marc Haber]

On Sun, Jun 25, 2023 at 05:29:12PM +0100, Adam D. Barratt wrote:
> On Sat, 2023-06-24 at 11:43 +0200, Marc Haber wrote:
> > On Sat, Jun 24, 2023 at 10:13:58AM +0100, Adam D. Barratt wrote:
> > > I was about to say "nothing other than a little more patience",
> > > given
> > > the request is only a few days old at this point. Looking back,
> > > however, it appears that there isn't actually a debdiff attached,
> > > as
> > > was claimed in the original mail.
> > 
> > I apologize. Here we go.
> > 
> 
> Thanks. Please go ahead.

Done.

One more question that might be a good candidate for more in-depth docs:
With both the bullseye and bookworm versions having been accepted to the
respective proposed-updates repository, there is no longer need to hold
back uploads to unstable, right? I can resume normal work on the
packages after the acceptance of the package for bullseye?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1035466: bullseye-pu: package postfix/3.5.18-0+deb11u1

[Scott Kitterman]

While this has been pending, another postfix maintenance update has been 
released for 3.5.  Postfix 3.5.20 provides the relevant fixes already provided 
to Bookworm via the 3.7.6 update.  Debdiff attached is oldstable to proposed 
change (not just the additional changes brought by 3.5.20).

Scott Kdiff -Nru postfix-3.5.18/debian/changelog postfix-3.5.20/debian/changelog
--- postfix-3.5.18/debian/changelog	2023-01-21 20:17:03.0 -0500
+++ postfix-3.5.20/debian/changelog	2023-04-30 14:24:06.0 -0400
@@ -1,3 +1,117 @@
+postfix (3.5.20-0+deb11u1) UNRELEASED; urgency=medium
+
+  [Wietse Venema]
+
+  * 3.5.20
+- Bugfix (defect introduced: Postfix 1.0): the command "postconf
+  .. name=v1 .. name=v2 .." (multiple instances of the same
+  parameter name) created multiple name=value entries with
+  the same parameter name. It now logs a warning and skips
+  the earlier update. Found during code maintenance. File:
+  postconf/postconf_edit.c
+
+- Bugfix (defect introduced: Postfix 3.3): the command "postconf
+  -M name1/type1='name2 type2 ...'" died with a segmentation
+  violation when the request matched multiple master.cf
+  entries. The master.cf file was not damaged. Problem reported
+  by SATOH Fumiyasu. File: postconf/postconf_master.c.
+
+- Bugfix (defect introduced: Postfix 2.11): the command
+  "postconf -M name1/type1='name2 type2 ...'" could add a
+  service definition to master.cf that conflicted with an
+  already existing service definition. It now replaces all
+  existing service definitions that match the service pattern
+  'name1/type1' or the service name and type in 'name2 type2
+  ...' with a single service definition 'name2 type2 ...'.
+  Problem reported by SATOH Fumiyasu. File: postconf/postconf_edit.c.
+
+- Bitrot: preliminary support for OpenSSL configuration files,
+  primarily OpenSSL 1.1.1b and later. This introduces new
+  parameters "tls_config_file" and "tls_config_name", which
+  can be used to limit collateral damage from OS distributions
+  that crank up security to 11, increasing the number of
+  plaintext email deliveries. Details are in the postconf(5)
+  manpage under "tls_config_file" and "tls_config_name".
+  Viktor Dukhovni. Files: mantools/postlink, proto/postconf.proto,
+  global/mail_params.h, posttls-finger/posttls-finger.c,
+  smtp/smtp.c, smtp/smtp_proto.c, tls/tls_client.c, tls/tls.h,
+  tls/tls_misc.c, tls/tls_proxy_client_print.c,
+  tls/tls_proxy_client_scan.c, tls/tls_proxy.h, tls/tls_server.c,
+  tlsproxy/tlsproxy.c.
+
+- Cleanup: use TLS_CLIENT_PARAMS to pass the OpensSSL 'init'
+  configurations. This information is independent from the
+  client or server TLS context, and therefore does not belong
+  in tls_*_init() or tls_*_start() calls. The tlsproxy(8)
+  server uses TLS_CLIENT_PARAMS to report differences between
+  its own global TLS settings, and those from its clients.
+  Files: posttls-finger/posttls-finger.c, smtp/smtp.c,
+  smtp/smtp_proto.c, tls/tls.h, tls/tls_proxy_client_misc.c,
+  tls/tls_proxy_client_print.c, tls/tls_proxy_client_scan.c,
+  tls/tls_proxy.h, tlsproxy/tlsproxy.c.
+
+- Cleanup: reverted cosmetic-only changes to minimize the
+  patch footprint for OpenSSL INI file support; updated daemon
+  manpages with the new tls_config_file and tls_config_name
+  configuration parameters. Files: smtp/smtp.c, smtpd/smtpd.c,
+  tls/tls_client.c, tls/tls.h, tls/tls_server.c, tlsproxy/tlsproxy.c,
+
+- Cleanup: made OpenSSL 'default' INI file support error
+  handling consistent with OpenSSL default behavior. Viktor
+  Dukhovni. Files: proto/postconf.proto, tls/tls_misc.c.
+
+- Backwards compatibility for stable releases that originally
+  had no OpenSSL INI support. Skip the new OpenSSL INI support
+  code, unless the Postfix configuration actually specifies
+  non-default tls_config_xxx settings. File: tls/tls_misc.c.
+
+- Cleanup: added a multiple initialization guard in the
+  tls_library_init() function, and made an initialization
+  error sticky. File: tls/tls_misc.c.
+
+- Security: new parameter smtpd_forbid_unauth_pipelining
+  (default: no) to disconnect remote SMTP clients that violate
+  RFC 2920 (or 5321) command pipelining constraints. Files:
+  global/mail_params.h, smtpd/smtpd.c, proto/postconf.proto.
+
+  * 3.5.19
+- Portability: the EVP_get_digestbyname change broke OpenSSL
+  1.0.2 support. File: tls/tls.h.
+
+- Bugfix (introduced: Postfix 3.4): the posttls-finger command
+  failed to detect that a connection was resumed in the case
+  that a server did not return a certificate. Viktor Dukhovni.
+  File: posttls-finger/posttls-finger.c.
+
+- Workaround: OpenSSL 3.x EVP_get_cipherbyname() can return
+  lazily-bound handles. Postfix now checks that 

Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0

[solneman33]

Yes, I was able to upgrade lightdm to 1.32 after I reinstalled xserver-xorg.  I 
don't think it was lightdm causing the issue itself, it was due to xserver-xorg 
and xinit being removed during the a system upgrade.  Once I had those 
re-installed everything is working great again.

Thanks for the follow-up.




Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, June 21st, 2023 at 12:46 AM, Yves-Alexis Perez 
 wrote:


> On Wed, 2023-06-21 at 01:59 +, solneman33 wrote:
> 
> > I downgraded to xkb-data=2.35.1-1 lightdm=1.26.0-8 from testing repo and
> > reinstalled xserver-xorg and xinit. That resolved the issue for me on both
> > machines.
> > 
> > I've never reported a bug before, my apologies if this is incorrect
> > procedure.
> 
> 
> Well, can you check by reinstalling lightdm 1.32 but making sure you have
> xserver-xorg?
> 
> Regards,
> --
> Yves-Alexis

Bug#1039105: Fails to start with Emacs 28

[Dirk Eddelbuettel]

Package: vm
Version: 8.2.0b-8
Severity: normal

Ian,

  After updating my main machine (and the only one running vm along and
exim4, dovecot, spamassassin and whatnot) to Ubuntu 23.04 with its Emacs 28.2
(in an upgrade from 22.10 with Emacs 27.*), I found that vm (which I have
been using all those years, still with some hooks and key-binding you emailed
to in the mid-1990s (!!)) would no longer start.

The error was indicative of elc compilation woes. I found a post by the magit
author suggesting removal and reinstallation (of his package). That worked,
so I was relieved, but it worked only once.

Looking around, I stumbled across the Fedora page for vm. It contains a
reference to a change in this commit

  
https://src.fedoraproject.org/rpms/emacs-vm/c/909b0bc357976252c51502bf17ed1efc6aeb7b97?branch=rawhide

which boils down to

;; Startup settings for VM
  + ;;
  + ;; For some reason, native compilation breaks VM. As a workaround until the
  + ;; problem is understood and fixed, disable native compilation of all VM
  + ;; lisp files.
  + (eval-after-load "comp"
  + '(if (boundp 'native-comp-deferred-compilation-deny-list)
  + (add-to-list 'native-comp-deferred-compilation-deny-list 
"/vm.*\.el")))

I added this in a local -9 build to the top of debian/vm.emacsen-startup
which now has

  ;-*-emacs-lisp-*-
  ; arch-tag: 045640fd-0ff2-45b7-a29f-68e4b8378fbf

  ;; Borrowed with thanks from Fedora at
  ;; 
https://src.fedoraproject.org/rpms/emacs-vm/c/909b0bc357976252c51502bf17ed1efc6aeb7b97?branch=rawhide
  ;;
  ;; For some reason, native compilation breaks VM. As a workaround until the
  ;; problem is understood and fixed, disable native compilation of all VM
  ;; lisp files.
  (eval-after-load "comp"
  '(if (boundp 'native-comp-deferred-compilation-deny-list)
  (add-to-list 'native-comp-deferred-compilation-deny-list 
"/vm.*\.el")))

It would be nice if this could be applied to the package as a hot-fix as
failing to start is a little off-putting. We could probably also skip the
installation on start but there is enough going on in that installer script
that I left things were they were.

Happy to locally refinements or variants if you have any as I obviously have
a test bed for the bug.

Cheers, Dirk

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

Bug#1039104: transition: draco

[Timo Röhling]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: dr...@packages.debian.org
Control: affects -1 + src:draco

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I want to transition draco after a SONAME bump. AFAICT the new version
builds fine with the reverse dependencies. The Ben tracker looks good,
too:

https://release.debian.org/transitions/html/auto-draco.html

Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSYgdoACgkQ+C8H+466
LVkFDwwA0QTML+UwUCCo21sQ9kdO0orbo0CHQR4vL1KmtsOE7BQ7/hQDo36nK6Vk
7CwEYn6GglGiNiBGsikFtQCmcWeHn60pFXgvnDVTizq+vm0g1R9iNPUetnqZ+J6d
jeCh3Mo3HA2vlkhIsudvwNRN6cVtLGUp/6glui9OQ8jJJToSzpNAKoiGVX7urJXF
MJUqagDACOiuX3EJTHcxL8rF3rVB1s+PYvmp5oKnMYqbN2CBYbMHWWbKApkwAtgy
ZBgqHQMZS6/mqEL4R1+v/j94ObsTfmRnX/8LlwsqaQmXnZLTu2IWXABCGbex8OFE
sdmCQKYQdOI/j2Sa28mY93aRgZj2LX1B4GMSMBo9mUjeKXpRW8Wl+wOBTdk5Ofru
yQIEXIYzLXNdjzQ11Gst414OFhkNT80Td63+DRT9hrvFqLO7JW6Di1zdGGe4FhaT
eAAz97k1NAe8cz1bF0lZrsdMoV1cA+wcwlGE8MDmt8jDqo+Ez/xxZ1Zr8Dxda3hK
w3+HwyuO
=J0xZ
-END PGP SIGNATURE-

Bug#1038996: transition: pantomime

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-pantomime.html

On 2023-06-24 11:39:54 +0300, Yavor Doganov wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pantom...@packages.debian.org, 
> pkg-gnustep-maintain...@lists.alioth.debian.org
> Control: affects -1 + src:pantomime
> Control: block -1 with 1032830
> 
> On behalf of the GNUstep team I'd like to request a transition slot
> for pantomime (libpantomime1.3 > 1.4).  Out of the two rdeps
> lusernet.app builds successfully while gnumail will require a
> sourceful upload due to incompatible API changes (#1032830).

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1036300: Fwd: bullseye-pu: package curl/7.74.0-1.3+deb11u8

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, May 19, 2023 at 12:11:17AM +0100, Samuel Henrique wrote:
> [ Reason ]
> * Backport upstream patches to fix 5 CVEs:
>   - CVE-2023-27533: TELNET option IAC injection
>   - CVE-2023-27534: SFTP path ~ resolving discrepancy
>   - CVE-2023-27535: FTP too eager connection reuse
>   - CVE-2023-27536: GSS delegation too eager connection re-use
>   - CVE-2023-27538: SSH connection too eager reuse still
> * d/p/add_Curl_timestrcmp.patch: New patch to backport Curl_timestrcmp(),
>   required for CVE-2023-27535.

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1036046: bullseye-pu: package debian-parl/1.9.27+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, May 14, 2023 at 12:14:48PM +0200, Andreas Beckmann wrote:
> debian-parl needs to be rebuilt against newer boxer-data to drop
> dependencies on packages lo longer built by src:thunderbird, e.g.
> lightning. Currently design-parl* are uninstallable in bullseye.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1036044: bullseye-pu: package debian-design/3.0.22+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, May 14, 2023 at 12:01:16PM +0200, Andreas Beckmann wrote:
> debian-design needs to be rebuilt against newer boxer-data to drop
> dependencies on packages lo longer built by src:thunderbird, e.g.
> lightning. Currently design-desktop* are uninstallable in bullseye.

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1036043: bullseye-pu: package boxer-data/10.8.28+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, May 14, 2023 at 11:44:31AM +0200, Andreas Beckmann wrote:
> This is a data update to remove packages no longer built by
> src:thunderbird, e.g. lightning. This is needed for rebuilding
> src:debian-design and src:debian-parl in order to drop the unavailable
> dependencies and make their binary packages installable again in
> bullseye.

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1039103: mrtg.cfg not moved to new location in /etc/mertg/ when upgrading from bullseye to bookworm

[Konrad Lotter]

Package: mrtg
Version: 2.17.10-5
Severity: important
X-Debbugs-Cc: konradlot...@gmail.com

Dear Maintainer,


   * What led up to the situation? Upgrade Debian from Bullseye to Bookworm 
(package mrtg 2.17.7-2+deb11u1 upgraded to mrtg 2.17.10-5)
   * What exactly did you do (or not do) that was effective (or
 ineffective)? mrtg initially had no output. Manually moved /etc/mrtg.cfg 
from /etc/ to /etc/mrtg/ (not in documentation)
   * What was the outcome of this action? mrtg worked after moving the 
configuration file to the correct location
   * What outcome did you expect instead? That the configuration file should be 
moved automatically when upgrading package



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

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

Versions of packages mrtg depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9
ii  libgd3 2.3.3-9
ii  libsnmp-session-perl   1.14~git20221124T101957-1
ii  perl   5.36.0-7

mrtg recommends no packages.

Versions of packages mrtg suggests:
ii  apache2 [httpd]2.4.57-2
ii  firefox-esr [www-browser]  102.12.0esr-1~deb12u1
ii  lynx [www-browser] 2.9.0dev.12-1
pn  mrtg-contrib   

-- Configuration Files:
/etc/cron.d/mrtg [Errno 2] No such file or directory: '/etc/cron.d/mrtg'
/etc/mrtg.cfg [Errno 13] Permission denied: '/etc/mrtg.cfg'
/etc/mrtg/mrtg.cfg [Errno 13] Permission denied: '/etc/mrtg/mrtg.cfg'

-- debconf information:
  mrtg/create_www: false
* mrtg/fix_permissions: true
* mrtg/remove_cron: true
* mrtg/conf_mods: true

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

Package: debian-policy
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

systemd upstream will drop support for the transitional sysv generator
in the near future. The transition is long finished, it's been at least
a decade, and it's time for the tail of packages still shipping only
init scripts but not units to be updated.

Tentatively this should happen within Trixie's development cycle. Of
course it's free software and generators are not that difficult to
maintain, so if someone wanted to lift the sysv generator out of the
systemd repository and adapt it to be a standalone binary there's
nothing stopping them. But I wouldn't want the systemd package to
depend on such a backward compat tool, so packages needing this
hyptothetical package should depend explicitly on it. This is just
mentioned for completeness, it's been at least a decade and writing a
unit file is beyond trivial so there shouldn't be any issue adding the
few remaining ones.

Once the policy is updated I plan to ask Lintian to bump the severity
of the existing check:

https://salsa.debian.org/lintian/lintian/-/merge_requests/407

Patch attached and pushed to
https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=heads

-- 
Kind regards,
Luca Boccassi
From ea524f52d256e37b4e4747d7e6ac4f316c4805a8 Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Sun, 25 Jun 2023 18:42:29 +0100
Subject: [PATCH] system services: make systemd units mandatory

systemd upstream will drop support for the transitional sysv generator
in the near future. The transition is long finished, and it's time for
the tail of packages still shipping only init scripts but not units to
be updated.
---
 policy/ch-opersys.rst | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 207b3c0..3134783 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -328,16 +328,12 @@ Starting system services
 Introduction
 
 
-Packages that include system services should include ``systemd`` service
+Packages that include system services must include ``systemd`` service
 units to start or stop those services.  See :manpage:`systemd.service(5)`
 for details on the syntax of a service unit file.  In the common case that
 a package includes a single system service, the service unit should have
 the same name as the package plus the ``.service`` extension.
 
-If the package does not include a service unit (if, for example, no one
-has yet written one), including an init script, as described below, to
-start the service is encouraged.
-
 Packages including a service unit may optionally include an init script to
 support other init systems.  In this case, the init script should have the
 same name as the ``systemd`` service unit so that ``systemd`` will ignore
@@ -345,13 +341,13 @@ it and use the service unit instead.  Packages may also support other init
 systems by including configuration in the native format of those init
 systems.
 
-If a service unit is not present, ``systemd`` uses dependency information
-contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide
-which scripts to run and in which order.  The ``sysv-rc`` runlevel system
-for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which
-scripts to run and in which order at boot time and when the init state (or
-"runlevel") is changed.  See the ``README.runlevels`` file shipped with
-``sysv-rc`` for implementation details.  Other alternatives might exist.
+``systemd`` uses dependency and ordering information contained within the
+enabled unit files to decide which services to run and in which order.
+The ``sysv-rc`` runlevel system for ``sysvinit`` uses symlinks in
+``/etc/rcn.d`` to decide which scripts to run and in which order at boot
+time and when the init state (or "runlevel") is changed.  See the
+``README.runlevels`` file shipped with ``sysv-rc`` for implementation details.
+Other alternatives might exist.
 
 The sections below describe how to write those scripts and configure those
 symlinks.
-- 
2.39.2



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

Bug#1039100: linux-image-6.1.0-9-amd64: NVMe SSD drive not detected after rebooting Debian 12

[Lukasz Kusior]

Package: src:linux
Version: 6.1.27-1
Severity: normal
X-Debbugs-Cc: kusior.luk...@gmail.com

Dear Maintainer,

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

   * What led up to the situation? When powering on the laptop everything works 
well, although when rebooting from Debian 12, the UEFI does not detect the NVMe 
drive. Powering laptop off and back on solves the problem.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? While searchinng through the internet I have found it is a 
kernel issue to do with NVMe power saving. There are work-arounds but it must 
be a bug in the kernel as everything works fine with old-stable Debian 11
   * What was the outcome of this action? Don't have skills to fix it, but I 
suppose it could be fixed with next kernel update
   * What outcome did you expect instead?

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


-- Package-specific info:
** Version:
Linux version 6.1.0-9-amd64 (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 
PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=2ae8dcf9-f2e5-4eea-a9a4-2541930d30f2 ro quiet

** Not tainted

** Kernel log:
[4.848950] NET: Registered PF_BLUETOOTH protocol family
[4.848951] Bluetooth: HCI device and connection manager initialized
[4.848957] Bluetooth: HCI socket layer initialized
[4.848960] Bluetooth: L2CAP socket layer initialized
[4.848965] Bluetooth: SCO socket layer initialized
[4.869866] SVM: TSC scaling supported
[4.869871] kvm: Nested Virtualization enabled
[4.869872] SVM: kvm: Nested Paging enabled
[4.869874] SEV supported: 16 ASIDs
[4.869876] SEV-ES supported: 4294967295 ASIDs
[4.869890] SVM: Virtual VMLOAD VMSAVE supported
[4.869891] SVM: Virtual GIF supported
[4.869892] SVM: LBR virtualization supported
[4.886712] MCE: In-kernel MCE decoding enabled.
[4.894585] iwlwifi :04:00.0: base HW address: 08:71:90:c2:6c:2b, OTP 
minor version: 0x4
[4.903249] intel_rapl_common: Found RAPL domain package
[4.903254] intel_rapl_common: Found RAPL domain core
[4.964106] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[4.967502] iwlwifi :04:00.0 wlp4s0: renamed from wlan0
[5.005123] usbcore: registered new interface driver btusb
[5.009854] Bluetooth: hci0: Bootloader revision 0.1 build 42 week 52 2015
[5.013876] Bluetooth: hci0: Device revision is 2
[5.013884] Bluetooth: hci0: Secure boot is enabled
[5.013887] Bluetooth: hci0: OTP lock is enabled
[5.013888] Bluetooth: hci0: API lock is enabled
[5.013890] Bluetooth: hci0: Debug lock is disabled
[5.013892] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[5.015856] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-18-16-1.sfi
[5.015872] Bluetooth: hci0: Found device firmware: intel/ibt-18-16-1.sfi
[5.015926] Bluetooth: hci0: Boot Address: 0x40800
[5.015929] Bluetooth: hci0: Firmware Version: 108-45.22
[5.088122] EXT4-fs (nvme0n1p6): mounted filesystem with ordered data mode. 
Quota mode: none.
[5.216371] audit: type=1400 audit(1687709109.810:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=690 comm="apparmor_parser"
[5.216382] audit: type=1400 audit(1687709109.810:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=689 comm="apparmor_parser"
[5.217189] audit: type=1400 audit(1687709109.810:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=684 
comm="apparmor_parser"
[5.217484] audit: type=1400 audit(1687709109.810:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=685 
comm="apparmor_parser"
[5.217490] audit: type=1400 audit(1687709109.810:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=685 comm="apparmor_parser"
[5.217662] audit: type=1400 audit(1687709109.810:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=688 
comm="apparmor_parser"
[5.217668] audit: type=1400 audit(1687709109.810:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=688 
comm="apparmor_parser"
[5.286656] kauditd_printk_skb: 10 callbacks suppressed
[5.286659] audit: type=1400 audit(1687709109.882:21): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince" pid=687 
comm="apparmor_parser"
[5.286665] audit: type=1400 audit(1687709109.882:22): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince//sanitized_helper" pid=687 comm="apparmor_parser"
[5.286669] audit: type=1400 audit(1687709109.882:23): apparmor="STATUS" 

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Jun 07, 2023 at 07:07:50PM -0700, Otto Kekäläinen wrote:
> Hi!
> 
> Note that upstream released 10.11.4 today. Import preparation in
> progress at 
> https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/50.
> I plan to upload this to experimental tomorrow and eventually into
> bookworm-pu if the release team approves.
> 
> - Otto

That MR looks sane; please prepare a backport of 1:10.11.4-1 and send a
confirmation source debdiff, and it can most likely be waved through.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#932957: no longer build arch-dependent variants of r-n?

[Paul Gevers]

Hi Holger,

On 25-06-2023 14:11, Holger Wansing wrote:

I have reduced the build chain to only build one generic arch-independent
variant of r-n, for all languages. It has all the content, and it's just named
"Release Notes for Debian 12 (bookworm)"
no longer mentioning any arch name in the title, and without any arch-name
reference in the whole document.


Great.


Note: If we decide to go with such approach, the website would need an
overhaul because of this!!!


Sure.


I added some sort of a basic-level draft mode:


To be fair, I'm not very attached to it. During the previous release 
(bullseye) I even had the notes in non-draft mode for (nearly) the whole 
preparation period. I'm not sure anybody took the notes for something 
they were not.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039099: python3-matplotlib: please remove extraneous depedency on python3-six

[Alexandre Detiste]

Package: python3-matplotlib
Version: 3.6.3-1+b1
Severity: normal

MatPlotLib doens't use python3-six anymore, please
remove it from the dependencies.

Greetings



> https://matplotlib.org/stable/devel/MEP/MEP11.html

python3-dateutils still requires it for now,
but it already pull it in itself,
so the depedency doesn't belong here.


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-matplotlib depends on:
ii  libc6   2.36-9
ii  libfreetype62.12.1+dfsg-5
ii  libgcc-s1   13.1.0-6
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libqhull-r8.0   2020.2-5
ii  libstdc++6  13.1.0-6
ii  python-matplotlib-data  3.6.3-1
ii  python3 3.11.2-1+b1
ii  python3-contourpy   1.0.7-1+b1
ii  python3-cycler  0.11.0-1
ii  python3-dateutil2.8.2-2
ii  python3-fonttools   4.38.0-1+b1
ii  python3-kiwisolver  1.4.4-1+b1
ii  python3-numpy [python3-numpy-abi9]  1:1.24.2-1
ii  python3-packaging   23.1-1
ii  python3-pil 9.5.0-1
ii  python3-pil.imagetk 9.5.0-1
ii  python3-pyparsing   3.0.9-1
ii  python3-six 1.16.0-4

Versions of packages python3-matplotlib recommends:
ii  python3-tk  3.11.4-1

Versions of packages python3-matplotlib suggests:
pn  cm-super-minimal 
pn  dvipng   
ii  ffmpeg   7:5.1.3-1
pn  fonts-staypuft   
ii  ghostscript  10.01.2~dfsg-1
ii  gir1.2-gtk-3.0   3.24.37-2
ii  inkscape 1.2.2-2+b1
pn  ipython3 
ii  librsvg2-common  2.54.5+dfsg-1
pn  python3-cairocffi
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1
pn  python3-gobject  
ii  python3-pyqt55.15.9+dfsg-1
ii  python3-scipy1.10.1-2
ii  python3-sip  4.19.25+dfsg-5+b1
ii  python3-tornado  6.2.0-3
pn  texlive-extra-utils  
pn  texlive-latex-extra  

-- no debconf information

Bug#1039098: discover-modprobe.conf.5: some remarks and a patch for the manual

[Bjarni Ingi Gislason]

Package: debianutils
Version: 5.7-0.4
Severity: minor
Tags: patch

Dear Maintainer,

here are notes and fixes for the man page.



The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff using

"groff -man -Z" instead of "nroff -man"

#

  Only "skipping paragraph macro" is fixed.

  Use "sed" to remove trailing spaces.

  Use "git apply ... --whitespace=fix" to fix extra space issues,
or use global configuration "core.whitespace".

  Report this to the creator of the man page.

42:.\" created by instant / docbook-to-man, Thu 31 Aug 2006, 11:05 

Output from "mandoc -T lint discover-modprobe.conf.5":

mandoc: discover-modprobe.conf.5:1:2: WARNING: missing date, using "": TH
mandoc: discover-modprobe.conf.5:1:34: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:2:12: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:3:72: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:4:19: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:5:2: WARNING: skipping paragraph macro: PP 
after SH
mandoc: discover-modprobe.conf.5:5:4: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:6:50: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:7:55: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:8:43: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:9:4: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:10:4: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:11:14: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:12:4: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:13:33: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:14:68: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:15:66: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:16:67: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:17:49: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:18:4: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:19:4: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:20:41: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:21:40: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:22:24: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:23:22: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:24:54: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:25:21: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:26:21: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:27:46: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:28:57: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:29:40: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:30:13: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:31:40: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:32:42: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:33:43: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:34:61: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:35:64: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:36:47: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:37:20: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:39:16: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:40:2: WARNING: skipping paragraph macro: PP 
after SH
mandoc: discover-modprobe.conf.5:40:4: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:41:47: STYLE: whitespace at end of input line
mandoc: discover-modprobe.conf.5:42:64: STYLE: whitespace at end of input line

###

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

14:as such is subject to a string variable assignment syntax. No space 
16:value(s) assigned. If multiple values are to be assigned, the list 
21:\fBtypes\fP and \fBskip\fP. Both can be 
27:These modules 

Bug#1039078: logcheck: Force LANG locale for journalctl to get date in English format

[Ludovic Rousseau]

On Sun, 25 Jun 2023 16:47:59 +0100 Richard Lewis 
 wrote:

On Sun, 25 Jun 2023, 15:09 Ludovic Rousseau,  wrote:

>
> It looks like journalctl now displays the month using the configured
> locale.
>
> Compare:
> # journalctl -t smartd -S "Jun 25 10:00:00"
> juin 25 11:09:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
> Attribu>
> juin 25 13:39:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
> Attribu>
>
> with:
> # LANG=C journalctl -t smartd -S "Jun 25 10:00:00"
> Jun 25 11:09:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
> Attribut>
> Jun 25 13:39:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
> Attribut
>
>

Thanks for the report and patch.

The patch sets LANG to C before running logcheck: i can see this is a
solution that will work in the short-term.

I think it should be C.UTF-8 instead of plain C?

I suspect it would also work to simply write LANG=C into
/etc/logcheck/logcheck.conf (untested)


I tried adding the line:
LANG=C.UTF-8
at the end of /etc/logcheck/logcheck.conf and it works also fine for me.

It is a better solution since I do not have to patch a script for the same 
result.
Thanks for the suggestion.


In the long-term:
- I wonder if locale is something we should allow the user to customize
anyway?
- what if rsyslog starts doing something similar? we cant change its locale
as we work after it has written the log.
- hardcoding locale means you wont be able to manually match things
logcheck reports to what you see when running journalctl by hand, unless
you know to.manually change the locale  i dont see a way round this :(


It was not easy to find the source of the problem because in in /var/log/syslog 
the same log lines are:
2023-06-25T11:09:27.454813+02:00 zotac smartd[548]: Device: /dev/sda [SAT], 
SMART Usage Attribute: 194 Temperature_Celsius changed from 33 to 34
2023-06-25T13:39:27.531540+02:00 zotac smartd[548]: Device: /dev/sda [SAT], 
SMART Usage Attribute: 194 Temperature_Celsius changed from 34 to 35

Here the date does not include the month name (either Jun or juin).


But we should document that locale is fixed for journalctl (but not for
rsyslog!), and make the autopkgtests use a non-english locale as well to
help spot future issues.


My first patch was to change the \w{3} by \w+ in my personal rules. (for example in 
"^(\w{3} [ :0-9]{11}|[0-9T:.+-]{32}) ...")
But since the problem was also present in "official" rules provided by the 
package it was not a good/practical solution.

I have no idea what the correct/best solution should be.

Bye

--
Dr. Ludovic Rousseau

Bug#1039096: python3-invoke: please remove obsolete depedency on python3-six

[Alexandre Detiste]

Package: python3-invoke
Version: 2.0.0-1
Severity: normal

python3-six is not needed anymore since the 2.0.0 release,
please remove it from depedencies.


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-invoke depends on:
ii  python33.11.2-1+b1
ii  python3-pkg-resources  66.1.1-1
ii  python3-six1.16.0-4
ii  python3-yaml   6.0-3+b2

python3-invoke recommends no packages.

Versions of packages python3-invoke suggests:
pn  python-invoke-doc  

-- no debconf information

Bug#1039095: owslib: Homepage: is outdated

[Sebastiaan Couwenberg]

Control: tags -1 pending

This is fixed in git.

Kind Regards,

Bas

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

Bug#1038344: bookworm-pu: package request-tracker5/5.0.3+dfsg-2+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

I just happened to look at this; otherwise as it was still tagged
"moreinfo" it would probably have been waiting for attention for quite a
while.

On Sun, Jun 18, 2023 at 12:50:47AM +1200, Andrew Ruthven wrote:
> [Resent Cc'ing in the bug, Evolution dropped it first time round, sigh]
> 
> On Sat, 2023-06-17 at 13:05 +0100, Adam D. Barratt wrote:
> > You appear to have attached a binary debdiff. Please provide a _source_
> > debdiff for checking.
> 
> My apologies, first time I've done this. I had generated it as well.
> 
> Please find the source debdiff attached.

As 5.0.3+dfsg-3 in unstable is limited to these changes anyway, you can
backport it directly and the version history makes things a bit clearer for
some infrastructure. Just add a changelog entry on top of the unstable
version, "Backport to bookworm" or something, version 5.0.3+dfsg-3~deb12u1,
target bookworm. Don't remove the changelog for 5.0.3+dfsg-3.

Example: 
https://release.debian.org/proposed-updates/bookworm_diffs/onionshare_2.6-5~deb12u1.debdiff

Other than that, please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1037261: Bookworm - OOM-killer called before partition hard drives

[Pascal Hambourg]

On 25/06/2023 at 17:44, Ben Hutchings wrote:

On Fri, 2023-06-09 at 17:16 +0200, Anael Mobilia wrote:

Jun  9 14:50:43 kernel: [0.00] x86/fpu: x87 FPU will use FXSAVE
Jun  9 14:50:43 kernel: [0.00] signal: max sigframe size: 1440
Jun  9 14:50:43 kernel: [0.00] BIOS-provided physical RAM map:
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x-0x0009fbff] usable
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x0009fc00-0x0009] reserved
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x000f-0x000f] reserved
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x0010-0x3ffc9fff] usable
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x3ffca000-0x3fff] reserved
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0xfeffc000-0xfeff] reserved
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0xfffc-0x] reserved


That's 1 GiB RAM, not 32 GiB.  Still, that should be more than enough
for installation.


But:

Jun  9 14:50:43 kernel: [0.123770] Memory: 338616K/1047968K available (14342K kernel code, 2324K rwdata, 8728K rodata, 2772K init, 17436K bss, 171224K reserved, 0K cma-reserved) 


How come available memory is so low ? Or am I misunderstanding ?

Bug#1039095: owslib: Homepage: is outdated

[Adrian Bunk]

Source: owslib
Version: 0.29.2-1
Severity: minor

  debian/control:Homepage: https://geopython.github.com/OWSLib/

This does no longer exist, one of the following could be used instead:
  https://github.com/geopython/OWSLib
  https://owslib.readthedocs.io/en/latest/

Bug#1039039: multipath-tools 0.9.4-3+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1039039 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: multipath-tools
Version: 0.9.4-3+deb12u1

Explanation: hide underlying paths from LVM; prevent initial service failure on 
new installations