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

[fabian]

Hi Witold,

Am 2023-06-26 02:32, schrieb Witold Baryluk:

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)


well, it does come with a systemd unit:

/usr/lib/systemd/user/fluidsynth.service

If this service is enabled, fluidsynth acts as a MIDI daemon, i.e. as a 
virtual MIDI device.


You may either want to disable this service, or switch to a different 
default soundfont with a smaller memory footprint, e.g. the one in the 
`timgm6mb-soundfont` package, either by uninstalling all soundfont 
packages but this one or by using Debian's `update-alternatives` 
mechanism.


Hope that helps!

 - Fabian

Bug#1038883: dolfin: autopkgtest failure due to bytes as docstring

[Gregor Riepl]

your package fails the autopkgtest with the new pytest 7.3 because
python/test/unit/function/test_function_space.py uses a bytes object
(b""" literal) as module docstring, and pytest crashes while looking for
the "PYTEST_DONT_REWRITE" marker.


This does sound like a serious bug in pytest, though. If it can't 
process the docstring, it should ignore it, not crash.


But I don't quite get why it would choke on a byte string, if it's just 
looking for a token?



As far as I understand, using a bytes() object as docstring violates
PEP-257, which is why I am filing this as a dolfin bug and not a pytest
regression. I have Cc'd the debian-python mailing list for a second
opinion, but I believe this bug should be resolved by getting rid of the
erroneous "b" prefix.


PEP-257 says:


If you violate these conventions, the worst you’ll get is some dirty
looks. But some software (such as the Docutils docstring processing
system PEP 256, PEP 258) will be aware of the conventions, so
following them will get you the best results.


FWIW, I think this should be fixed in both pytest and the affected 
package. Unless there is a specific reason for the byte string, it 
should be replaced with a regular string.

Bug#1037478: ca-certificates-java: Same for 20230620

[bert]

Package: ca-certificates-java
Version: 20230620
Followup-For: Bug #1037478
X-Debbugs-Cc: b...@dismail.de

Dear Maintainer,

I saw this error in today's testing update to version 20230620.


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

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

Versions of packages ca-certificates-java depends on:
ii  ca-certificates   20230311
ii  openjdk-17-jre-headless [java8-runtime-headless]  17.0.7+7-1

ca-certificates-java recommends no packages.

ca-certificates-java suggests no packages.

-- Configuration Files:
/etc/default/cacerts [Errno 13] Permission denied: '/etc/default/cacerts'

-- no debconf information

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Johannes Schauer Marin Rodrigues]

Hi Simon,

if you are short on time, you might skip right to the end of this mail and
ignore my other comments as they are not of any high priority since at least
for me, this issue is solved with somehow integrating debvm or adding an
interface that allows using debvm output with autopkgtest.

Quoting Simon McVittie (2022-06-08 11:57:58)
> On Sun, 05 Jun 2022 at 17:04:02 +0200, Johannes Schauer Marin Rodrigues wrote:
> > I am offering to either rewrite autopkgtest-build-qemu with a --method 
> > option
> > defaulting either to "guestfish" if a native image is requested, 
> > "initramfs" if
> > a foreign architecture is requested and "kernel" if the image is neither 
> > i386,
> > amd64, armhf, arm64 or ppc64el. If the user requires a system as close to a
> > real system as possible, they can manually use --method=debian-installer.
> 
> This is extremely comprehensive, but I'm concerned that if we have this
> many code paths for building a qemu VM, at least one of them will be
> broken at any given time. We already have more virtualization backends
> than maintainer bandwidth or routine testing (see my recent efforts to
> get all our tests passing, and I haven't even got as far as qemu yet).
> 
> I appreciate your offer to add more code, but if we add all these code
> paths and document them as something that should work, I'm concerned that
> we'll end up in a situation where we can't remove any of them because
> someone might be relying on them, but we don't actually know that they
> *work* either, and nobody among the autopkgtest maintainers has the time
> or knowledge to fix them when they don't. (This could be mitigated by
> outsourcing as much as possible to some other system builder, like we
> already do to some extent with vmdb2.)

those are very valid concerns. This makes sense.

> As I believe I've already said in an earlier message to this bug report,
> one way to get autopkgtest out of the business of being yet another
> system-building tool is to start from a "cloud" VM image produced by
> someone else (ideally, "have a qemu-runnable cloud image" would be one
> of the jobs for the porting team for each architecture). One approach to
> this is to take a generic cloud image, boot it with qemu and modify it
> to provide the serial ports that autopkgtest-virt-qemu currently needs,
> as autopkgtest-buildvm-ubuntu-cloud does.

My concern with using downloadable cloud images is that what I download from
some server is not verified by the archive GPG keys. I much rather run one of
the existing system-building tools which only downloads data verified by
debian-archive-keyring. But in another threat you already said that you'd like
the input to autopkgutils just being a tarball created by some other tool and
I'd be completely happy with that idea.

> However, the serial-port-based command execution is really quite
> fragile: there are arbitrary timeouts that cause testbed startup to
> fail randomly while under load (which is a large part of why I haven't
> been able to get it systematically passing tests), and it's vulnerable
> to architectures having different conventions for how the virtualized
> "hardware" is represented in the guest user-space. I've tried to reduce
> that problem by using the virtio hypervisor serial consoles /dev/hvc*, but
> as you can see from the ppc64le special case in lib/autopkgtest_qemu.py,
> even that is not completely predictable, because on ppc64le the virtio
> serial consoles start from hvc1.
> 
> I think a less fragile approach than the serial ports would be to use
> ssh, which in practice needs to work anyway, because it's how porters
> typically interact with their test hardware. My goal in refactoring
> part of autopkgtest-virt-qemu into lib/autopkgtest_qemu.py was to get an
> autopkgtest-virt-ssh setup script that runs and manages a qemu VM, using
> cloud-init to provision a trusted public key. Unfortunately, getting that
> tested and working has been delayed by trying to clear enough technical
> debt to make the tests pass on the backends we already have...

Is the argument here, that you are not happy with how autopkgtest-virt-qemu
operates in general and that's an additional reason (probably in connection
with the maintenance burden) why you don't want to add new features to it?

> I think the proliferation of system-building tools that you have noted in
> the past is partly because until recently they have always needed root,
> partly because none of the existing ones is particularly comprehensive,
> and partly because of the number of fiddly details involved in getting
> the correct bootloader for each architecture and poking it into place.
> If we had something analogous to grub-cloud (install on and boot from the
> first disk, no attempt to support dual-booting or special configurations,
> hard-code a serial console, etc.) as part of the minimal requirements
> for supporting an architecture, ideally with a metapackage available on
> all architectures that pulls

Bug#1024997: what kind of bug was it?

[Junichi Uekawa]

Hi,

From my guess it's some kind of buffer management issue; what was the bug and 
is there a minimal fix ?

Bug#1038000: bookworm-pu: package texlive-bin/2022.20220321.62855-5.1+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Jun 15, 2023 at 12:09:55PM +0200, Hilmar Preusse wrote:
> * Stop building *jit* binaries on i386 based arches to make TL installable
>   on computers not supporting sse2 (Closes: #1035461).
> * Add patch for CVE-2023-32668: disable socket in luatex by default
>   (Closes: #1036470).

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



signature.asc
Description: PGP signature

Bug#1037444: bookworm-pu: package kanboard/1.2.26+ds-4

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Jun 15, 2023 at 11:32:06PM -0400, Joe Nahmias wrote:
> Attached is a revised debdiff between -2 and -2+deb12u1.
> --Joe

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#1039047: cvs 1.12.13+real-28+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1039047 = 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: cvs
Version: 1.12.13+real-28+deb12u1

Explanation: configure full path to ssh

Bug#1037990: bookworm-pu: package nvidia-support/20220217+3~deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Jun 15, 2023 at 10:50:06AM +0200, Andreas Beckmann wrote:
> [ Reason ]
> Upgrades from bullseye to bookworm may fail while building kernel
> modules with dkms if some obsolete nvidia-*-dkms packages (that have no
> successor in bookworm) are still installed.
> (The dkms hook in bookworm no longer returns success if building a
> module has failed.)
> Let's add some Breaks against them (to nvidia-installer-cleanup which
> has the highest score from apt in these scenarios), to ensure the
> obsolete packages (and anything depending on them) gets removed during
> the upgrade to bookworm.

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#1036849: gnome-software 43.5-1~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1036849 = 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: gnome-software
Version: 43.5-1~deb12u1

Explanation: new upstream release; memory leak fixes

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

[Jonathan Wiltshire]

On Mon, Jun 26, 2023 at 04:42:27PM +1200, Andrew Ruthven wrote:
> 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.

You need a tilde in the version, not a plus ("lower than"). I'll reject the
upload, you can upload a fixed version whenever you like.

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#1039119: darktable: use packaged lua

[roucaries bastien]

Le lun. 26 juin 2023 à 06:45, David Bremner  a écrit :

> 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
>


Yes in your case i cheched by grepping thé build log. Lua ils compiléd what
why i set rc severity.


Bastien

> d
>

Bug#1039270: Here's my monit.service

[Trent W. Buck]

FYI, attached are my monit systemd units.
They are definitely "too hardened" for some users.
You can PROBABLY just take everything before the hardening part, and use that 
as-is.

In particular, I deliberately prevent monit running as root
(I want systemd to restart units; I just want monit to check the availability 
of remote hosts).
This required some kludges because (IIRC) monit wants to have write access to 
its own config (like cupsd, or a crappy PHP webapp).

The NRPE replacement's "server" side should be here:
https://github.com/cyberitsolutions/die-nrpe-die
but I never got around to git filter-repo'ing the publishable parts out, so
I've attached a minified version of that as well.
[Unit]
Description=Pro-active monitoring utility for unix systems
After=network-online.target
Documentation=man:monit(1) https://mmonit.com/wiki/Monit/HowTo


# NOTE: "monit --interactive" means Run_Foreground and skips daemonize() 
(Type=simple).
#   This prevents systemd distinguishing "starting" from "started" 
(Type=forking).  Meh?
#   This DOES NOT prevent monit doing a weird "if monit is already running, 
just kill -USR1 it, and exit(0)"!
#   
https://bitbucket.org/tildeslash/monit/src/release-5-32-0/src/monit.c#lines-195:205
#   
https://bitbucket.org/tildeslash/monit/src/release-5-32-0/src/monit.c#lines-563:584
#   Overall, I think Type=forking gives systemd slightly better information.
#   Type=forking is required if you want to e.g. Before=nginx.service.
#
# NOTE: "monit reload" is basically "kill -HUP $MAINPID", but
#   it doesn't require "apt install procps".
[Service]
Type=forking
ExecStartPre=monit --test
ExecStart=monit
ExecReload=monit reload


# FIXME: sometimes on "systemctl start monit" or "systemctl restart monit",
#monit simply exits immediately.
#This can happen after unattended-upgrades + needrestart restart monit
#due to a library getting a security patch!
#
#
# /join irc://irc.cyber.com.au/#cyber
# 11:11  Why is monit down
# 11:12  Something stopped it at 6:25 which is when cron.daily runs
# 11:16  2022-11-20T06:25:01.984164+11:00 heavy systemd[1]: 
cron-daily.service: Succeeded.
# 11:16  2022-11-20T06:25:05.905322+11:00 heavy systemd[1]: Stopping 
Apt-Cacher NG software download proxy...
# 11:16  2022-11-20T06:25:05.906880+11:00 heavy systemd[1]: Stopping 
Statistics collection and monitoring daemon...
# 11:16  2022-11-20T06:25:05.910253+11:00 heavy systemd[1]: Stopping 
Pro-active monitoring utility for unix systems...
# 11:16  ...why?
# 11:17  Maybe needrestart did it in response to a package upgrade
# 11:17  2022-11-20T06:25:08.540726+11:00 heavy systemd[1]: Starting 
Statistics collection and monitoring daemon...
# 11:17  ...but then
# 11:17  it doesn't actually start properly
# 11:17  So I think there's two things here:
# 11:18  1) something in morning cron restarted a bunch of services
# 11:18  2) sometimes monit doesn't restart properly, and instead simply 
exits
# 11:18  I had seen (2) before not after I stopped messing with it
# 11:18  Same thing again when I run it by hand just now
# 11:20  monit is doing something like exit(0) for no reason
# 11:20  but not deterministically
# 11:20  An ugly workaround might be to set 'restart=always' instead of 
just on-error
# 12:06  mike: I've gotten nowhere debugging this
# 12:07  mike: I'm going to do what you suggest
#
# /join ircs://irc.libera.chat/#monit
# 11:21  So I have this problem where SOMETIMES monit when told to start 
as a daemon, will instead just exit immediately
# 11:21  http://ix.io/4gHg
#
#   twb@heavy:~$ sudo systemctl start monit
#   [sudo] password for twb:
#   twb@heavy:~$ sudo systemctl status monit
#   ● monit.service - Pro-active monitoring utility for unix systems
#Loaded: loaded (/etc/systemd/system/monit.service; 
enabled; vendor preset: enabled)
#Active: inactive (dead) since Thu 2022-11-24 11:18:40 
AEDT; 3s ago
#  Docs: man:monit(1)
#https://mmonit.com/wiki/Monit/HowTo
#   Process: 2059508 ExecStartPre=chown -h monit: 
/etc/monit/monitrc (code=exited, status=0/SUCCESS)
#   Process: 2059509 ExecStartPre=chmod 0600 /etc/monit/monitrc 
(code=exited, status=0/SUCCESS)
#   Process: 2059510 ExecStart=monit (code=exited, 
status=0/SUCCESS)
#  Main PID: 2059512 (code=exited, status=0/SUCCESS)
#   CPU: 272ms
#
#   Nov 24 11:18:40 heavy systemd[1]: Starting Pro-active 
monitoring utility for unix systems...
#   Nov 24 11:18:40 heavy monit[2059510]: Starting Monit 5.27.2 
daemon with http interface at [*]:2812
#   Nov 24 11:18:40 heavy monit[2059510]: Starting Monit 5.27.2 
daemon with http interface at [*]:2812
#   Nov 24 11:18:40 heavy systemd[1]: Started Pro-active monitoring 
utility for unix systems.
#

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 
places-m...@gn

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 abre

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&ver=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&ver=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 de

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