Bug#1069988: onboard: Onboard/Appearance.py: SyntaxWarning: invalid escape sequence '\w'

[Paul Wise]

Package: onboard
Version: 1.4.1-6
Severity: normal
File: /usr/lib/python3/dist-packages/Onboard/Appearance.py
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

The recent upgrade of onboard triggers Python 3.12 syntax warnings,
the correct fix is to use Python's "raw" strings feature with regexes.

https://docs.python.org/3/library/re.html#raw-string-notation

   Unpacking onboard (1.4.1-6) over (1.4.1-5+b7) ...
   Preparing to unpack .../7-onboard-common_1.4.1-6_all.deb ...
   Unpacking onboard-common (1.4.1-6) over (1.4.1-5) ...
   Setting up onboard-common (1.4.1-6) ...
   Setting up onboard (1.4.1-6) ...
   /usr/lib/python3/dist-packages/Onboard/Appearance.py:924: SyntaxWarning: 
invalid escape sequence '\w'
 _key_ids_pattern = re.compile('[\w-]+(?:[.][\w-]+)?', re.UNICODE)
   /usr/lib/python3/dist-packages/Onboard/Appearance.py:1066: SyntaxWarning: 
invalid escape sequence '\w'
 key_ids = [x for x in re.findall('\w+(?:[.][\w-]+)?', text) if x]
   Setting up onboard-data (1.4.1-6) ...
   Setting up onboard-dbgsym (1.4.1-6) ...

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'stable-updates'), (500, 'stable-security-debug'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages onboard depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3+b3
ii  gir1.2-glib-2.0  1.78.1-15
ii  gir1.2-gtk-3.0   3.24.41-4
ii  gir1.2-pango-1.0 1.52.1+ds-1
ii  iso-codes4.16.0-1
ii  libc62.37-18
ii  libcairo21.18.0-1+b1
ii  libcanberra0 [libcanberra0t64]   0.30-15
ii  libdconf10.40.0-4+b2
ii  libgcc-s114-20240330-1
ii  libglib2.0-0t64  2.78.4-7
ii  libgtk-3-0t643.24.41-4
ii  libhunspell-1.7-01.7.2+really1.7.2-10+b2
ii  librsvg2-common  2.58.0+dfsg-1
ii  libstdc++6   14-20240330-1
hi  libudev1 254.5-1
ii  libx11-6 2:1.8.7-1
ii  libxi6   2:1.8.1-1
ii  libxkbfile1  1:1.1.0-1
ii  libxtst6 2:1.2.3-1.1
ii  onboard-common   1.4.1-6
ii  python3  3.11.6-1
ii  python3-cairo1.26.0-1
ii  python3-dbus 1.3.2-5+b1
ii  python3-gi-cairo 3.47.0-3

Versions of packages onboard recommends:
ii  gir1.2-atspi-2.0 2.52.0-1
pn  gir1.2-ayatanaappindicator3-0.1  
ii  onboard-data 1.4.1-6
ii  xdg-utils1.1.3-4.1

Versions of packages onboard suggests:
ii  mousetweaks  3.32.0-4

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1069987: mpv: Man page should note that --ontop functionality doesn't work on Wayland

[Russell Coker]

Package: mpv
Version: 0.37.0-1+b2
Severity: normal

Currently forcing a window to be on top on a Wayland environment is not a
problem that has a good solution.  The man page for mpv should note that on
Linux the --ontop option only works with X11 not with Wayland.  Currently
people are misled to believe that it will work which leads to wasting time.

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages mpv depends on:
ii  libarchive13t64   3.7.2-2
ii  libasound2t64 1.2.11-1+b1
ii  libass9   1:0.17.1-2
ii  libavcodec60  7:6.1.1-4
ii  libavdevice60 7:6.1.1-4
ii  libavfilter9  7:6.1.1-4
ii  libavformat60 7:6.1.1-4
ii  libavutil58   7:6.1.1-4
ii  libbluray21:1.3.4-1
ii  libc6 2.37-18
ii  libcaca0  0.99.beta20-4+b1
ii  libcdio-cdda2t64  10.2+2.0.1-1.1+b1
ii  libcdio-paranoia2t64  10.2+2.0.1-1.1+b1
ii  libcdio19t64  2.1.0-4.2
ii  libdrm2   2.4.120-2
ii  libdvdnav46.1.1-3
ii  libegl1   1.7.0-1
ii  libgbm1   24.0.6-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3+b3
ii  libjpeg62-turbo   1:2.1.5-3
ii  liblcms2-22.14-2+b1
ii  liblua5.2-0   5.2.4-3+b2
ii  libmujs3  1.3.3-3+b2
ii  libpipewire-0.3-0t64  1.0.5-1+b1
ii  libplacebo338 6.338.2-2
ii  libpulse0 16.1+dfsg1-5
ii  librubberband23.3.0+dfsg-2+b1
ii  libsdl2-2.0-0 2.30.2+dfsg-1
ii  libsixel1 1.10.3-3
ii  libswresample47:6.1.1-4
ii  libswscale7   7:6.1.1-4
ii  libuchardet0  0.0.8-1+b1
ii  libva-drm22.20.0-2
ii  libva-wayland22.20.0-2
ii  libva-x11-2   2.20.0-2
ii  libva22.20.0-2
ii  libvdpau1 1.5-2
ii  libvulkan11.3.280.0-1
ii  libwayland-client01.22.0-2.1+b1
ii  libwayland-cursor01.22.0-2.1+b1
ii  libwayland-egl1   1.22.0-2.1+b1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxkbcommon0 1.6.0-1
ii  libxpresent1  1.0.1-1
ii  libxrandr22:1.5.4-1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1.1
ii  libzimg2  3.0.5+ds1-1+b1
ii  zlib1g1:1.3.dfsg-3.1

Versions of packages mpv recommends:
ii  xdg-utils  1.1.3-4.1
ii  yt-dlp 2024.04.09-1

Versions of packages mpv suggests:
pn  libcuda1  

-- debconf-show failed

Bug#1069986: dublin-traceroute: Manual build-depends on NBS package libtins4.0

[Scott Kitterman]

Source: dublin-traceroute
Version: 0.4.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The package has a manual build-depends on libtins4.0, which is NBS.  It
has been renamed libtins4.5.  Once it is decrufted, this package will
FTBFS.

Scott K

Bug#1069985: python-cobra: Manual build-depends on NBS package libsbml5

[Scott Kitterman]

Source: python-cobra
Version: 0.26.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The package build-depends on the NBS package libsbml5.  It has been
renamed libsbml5t64.  Once the package is decrufted, this one will
FTBFS.

Please update your build-depends.

Scott K

Bug#1069984: alire: Build-depends on NBS package libgnatcoll21-dev

[Scott Kitterman]

Source: alire
Version: 1.2.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The package libgnatcoll21-dev has been renamed to libgnatcoll-dev.  Once
libgnatcoll21-dev is decfufted, it will FTBFS.  Please update your build
depends.

Scott K

Bug#1069983: dwarf-fortress: Manual build-depends on NBS package libgtk2.0-0

[Scott Kitterman]

Source: dwarf-fortress
Version: 0.47.04+dfsg1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

The package has a manual build-depends on libgtk2.0-0, which has been
replaced by libgtk2.0-0t64.  Once it has been decrufted, the package
will no longer build.

Scott K

Bug#1069982: theli: Manual build-depends on NBS package libcurl4

[Scott Kitterman]

Source: theli
Version: 3.1.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Once libcurl4 is decrufted, the package will no longer build.  The
libcurl4 package has been replaced by libcurl4t64.

Scott K

Bug#1069952: upgrade from 2.78.4-1 to 2.78.4-7 breaks over 200 packages in testing distribution

[Shmerl]

On Sat, 27 Apr 2024 10:08:34 -0400 =?UTF-8?Q?Jeremy_B=C3=ADcha?= <
jeremy.bi...@canonical.com> wrote:
> On Sat, Apr 27, 2024 at 9:33 AM js  wrote:
> >Wanted to see the effect of upgrading libglib2.0-dev by a minor
> >version number, 2.78.4-1 to 2.78.4-7 and that would have caused over
> >200 packages to break in the **testing** distribution.
>
> Try
> sudo apt dist-upgrade
>
> It is not a "minor" update. It is part of the t64 transition which is
> a huge change.
>
> Thank you,
> Jeremy Bícha
>

That doesn't help. New libglib2.0 is breaking a bunch of things in testing.
For example libglib2.0-bin is not co-nisntallable with a bunch of things in
KDE Plasma
and almost broke a whole installation for me. I managed to somewhat recover
it, but
for instance *packagekit* and *plasma-discover *got removed. Can you please
take a look.

sudo apt install libglib2.0-bin
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Unsatisfied dependencies:
plasma-workspace : Depends: gdb-minimal but it is not going to be installed
or
gdb
Error: Error, pkgProblemResolver::Resolve generated breaks, this may be
caused by held packages.

Regards,
Shmerl.

Bug#1066743: backblaze-b2: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.12 3.11" returned exit code 13

[Alexandre Detiste]

update is blocked by this

https://github.com/TvoroG/pytest-lazy-fixture/issues/65

many duplicates:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes=python-pytest-lazy-fixture

Bug#1069981: python-gitlab: please remove obsolete python3-mock dependency

[Alexandre Detiste]

Source: python-gitlab
Version: 1:4.3.0-1
Severity: normal

Dear Maintainer,

python3-mock is an obsolete library that is slowly being removed from Debian.
This project has switched to the newer unittest.mock from
the standard library and does not requires it anymore.

Greetings,


tchet@quieter:/tmp/python-pygitlab$ grep mock -r | grep -e import -e debian
debian/control: python3-httmock,
tests/unit/mixins/test_mixin_methods.py:from unittest.mock import mock_open, 
patch
tests/unit/objects/test_projects.py:from unittest.mock import mock_open, patch
tests/unit/test_cli.py:from unittest import mock
tests/unit/test_config.py:from unittest import mock
tchet@quieter:/tmp/python-pygitlab$

Bug#1069980: haskell-futhark FTBFS: Missing build dependency on alex

[Adrian Bunk]

Source: haskell-futhark
Version: 0.25.15-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-futhark=0.25.15-1

...
CallStack (from HasCallStack):
  withMetadata, called at 
libraries/Cabal/Cabal/src/Distribution/Simple/Utils.hs:370:14 in 
Cabal-3.8.1.0:Distribution.Simple.Utils
Error: hlibrary.setup: The program 'alex' is required but it could not be
...

Bug#1069979: pbuilder: please make APTGETOPT available to hook scripts

[Georgios Zarkadas]

Package: pbuilder
Version: 0.231
Severity: wishlist
Control: tags patch

Dear Maintainer,

There are eight hookscripts in the examples/ directory
that use ${APTGETOPT[@]} in their code. APTGETOPT is a
bash array and while it works fine inside pbuilder code
where all library modules are sourced, it is not get
exported to hookscripts, because they are executed as
a separate process and the array is not exported to
their environment.

I have tested this using explicit export APTGETOPT clause
in my pbuilderrc and hookscripts that print the environment
and, unless my configuration is fundamentally broken, it
is not get exported.

I file this as a bug, because including a large number
of scripts using this feature in the examples/ directory
implies the expectation that it actually works.

The attached patch exports the APTGETOPT array as a plain
environment variable in a way that scripts that use the
${APTGETOPT[@]} form in their code will run successfully
without modification. The second patch (...manpages) updates
the relevant hookscripts section of the pbuilder manpage.

Cheers,
Georgios

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 6 (excalibur/ceres)
Release:6
Codename:   excalibur ceres
Architecture: x86_64

Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.86
ii  debootstrap1.0.134devuan2
ii  dpkg-dev   1.22.6

Versions of packages pbuilder recommends:
ii  devscripts  2.23.7
ii  eatmydata   131-1
ii  fakeroot1.34-1
ii  iproute26.8.0-1
ii  net-tools   2.10-0.1devuan1
ii  sudo1.9.15p5-3+b1

Versions of packages pbuilder suggests:
pn  cowdancer   
ii  gdebi-core  0.9.5.7+nmu7

-- debconf information:
  pbuilder/mirrorsite: http://deb.devuan.org/merged
  pbuilder/rewrite: false
  pbuilder/nomirror:

-- debsums errors found:
debsums: changed file /usr/lib/pbuilder/pbuilder-modules (from pbuilder
package)

NOTE: I have patched pbuilder-modules with both the
patch I have proposed in bug #789401 and the patch
in this bug report, hence the failed debsums test.
diff --git a/pbuilder-modules b/pbuilder-modules
index 5695d0f2..d4df7ae6 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -1159,6 +1159,7 @@ function executehooks () {
DISTRIBUTION="$DISTRIBUTION" \
BUILD_ARCH="$ARCHITECTURE" \
HOST_ARCH="$HOST_ARCH" \
+   APTGETOPT="$(echo ${APTGETOPT[@]})" \
$CHROOTEXEC "/$hooks/$(basename "$fn")"
log.i "user script $fn finished"
else
diff --git a/pbuilder.8 b/pbuilder.8
index e59e207e..69fa56e8 100644
--- a/pbuilder.8
+++ b/pbuilder.8
@@ -432,6 +432,11 @@ contains the build architecture, the architecture the package is building on.
 .I HOST_ARCH
 contains the host architecture, the architecture the package is building for.
 .RE
+.RS 8
+.I APTGETOPT
+contains additional options to pass to apt-get. Since \fBAPTGETOPT()\fR is a
+bash array, the variable contains all its values concatenated with spaces.
+.RE
 \" End of hookdir description
 
 .TP

Bug#1069978: bash: incorrect value of $BASH for login shells

[Gioele Barabucci]

Package: bash
Version: 5.2.21-2
X-Debbugs-CC: bug-b...@gnu.org

Hi,

bash 5.0 and 5.2 do not set $BASH to the right value when bash is used 
as the login shell:


$ apt install bash-static
$ getent passwd $USER | cut -d: -f 7
/bin/bash

$ su $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

/usr/bin/bash-static
/usr/bin/bash-static

$ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

/bin/bash
/usr/bin/bash-static

(bash-static is not a link to bash)

Bash also uses the value in /etc/passwd when in login mode, although the 
documentation says


> BASH   Expands to the full filename used to invoke this instance of bash.

"full filename" could be interpreted both as "an absolute filename" as 
well as "the canonical absolute path".


$ su $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true'
/usr/bin/bash
/usr/bin/bash

$ su -l $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true'
/bin/bash
/usr/bin/bash

Regards,

--
Gioele Barabucci

Bug#1069977: python-xvfbwrapper: plase drop the extraneous dependency on python3-mock

[Alexandre Detiste]

Source: python-xvfbwrapper
Version: 0.2.9-5
Severity: normal

Dear Maintainer,

This project will prefer unittest.mock
from the standard library when available.

Greetings



tchet@quieter:/tmp/python-xvfbwrapper$ grep mock -r -C 2
debian/control: python3-mock,
--
setup.py-try:
setup.py:from unittest import mock  # noqa
setup.py-except ImportError:
setup.py:tests_require.append('mock')
--
test_xvfb.py-import unittest
test_xvfb.py-try:
test_xvfb.py:from unittest.mock import patch
test_xvfb.py-except ImportError:
test_xvfb.py:from mock import patch
--
tox.ini-deps=
tox.ini:py27,pypy: mock
tchet@quieter:/tmp/python-xvfbwrapper$

Bug#1069976: networking-sfc: please drop the python3-mock dependency

[Alexandre Detiste]

Source: networking-sfc
Version: 18.0.0-1
Severity: normal

Dear Maintainer,

This project had already switched to unittest.mock from the standard library.

tchet@quieter:/tmp/networking-sfc$ grep mock -r | grep -e debian -e import
grep: .git/objects/pack/pack-84f0168960e071e8c16a1da42cf5aa27efafc571.pack : 
fichiers binaires correspondent
debian/control: python3-mock,
debian/control: python3-requests-mock,
networking_sfc/tests/base.py:from unittest import mock
networking_sfc/tests/unit/db/test_flowclassifier_db.py:from unittest import mock
networking_sfc/tests/unit/db/test_sfc_db.py:from unittest import mo.

Bug#1069975: networking-baremetal: please drop the dependency on python3-mock

[Alexandre Detiste]

Source: networking-baremetal
Version: 6.3.0-2
Severity: normal

Dear Maintainer,

This project has switched to unittest.mock.

Greetings


tchet@quieter:/tmp/networking-baremetal$ grep mock -r | grep -e debian -e import
debian/control: python3-mock,
networking_baremetal/tests/unit/drivers/netconf/test_openconfig.py:from 
unittest import mock
networking_baremetal/tests/unit/ironic_agent/test_hashring_member_manager.py:from
 unittest import mock
networking_baremetal/tests/unit/ironic_agent/test_ironic_agent.py:from unittest 
import mock
networking_baremetal/tests/unit/openconfig/test_interfaces.py:from unittest 
import mock
networking_baremetal/tests/unit/openconfig/test_lacp.py:from unittest import 
mock
networking_baremetal/tests/unit/openconfig/test_network_instance.py:from 
unittest import mock
networking_baremetal/tests/unit/openconfig/test_vlan.py:from unittest import 
mock
networking_baremetal/tests/unit/plugins/ml2/test_baremetal_mech.py:from 
unittest import mock
tchet@quieter:/tmp/networking-baremetal$

Bug#1069974: squeak-vm: displays empty "several squeak images" list instead of starting

[Tom Goulet]

Package: squeak-vm
Version: 1:4.10.2.2614+20120917~dfsg-1+b1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I was testing out Debian Junior programming applications.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I started squeak from terminal.

   * What was the outcome of this action?
I saw a small window with the title "There are seve... queak images"
which had the instructions "Select items from the list below." and
"Choose one:".  But there were no items in the list to choose.  I
have taken a screenshot which I hope works for you:
https://imgur.com/a/vUgBoqI

   * What outcome did you expect instead?
I expected the Squeak VM to show up with graphics.

I noticed on the terminal, after starting squeak, it said:
printf too old, using shell-quote (CPAN String::ShellQuote) instead
found gettext in /bin
xargs: shell-quote: No such file or directory

So I installed libstring-shellquote-perl and retried the squeak command.
It worked fine, with the graphics of the text and the clouds and the
little red car showing up.  Maybe you should have that as a dependency?

I wasn't able to test the latest version, but I was thinking that if the
Debian stable version doesn't work, it should be fixed.

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

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages squeak-vm depends on:
ii  gettext-base  0.21-12
ii  libc6 2.36-9+deb12u6
ii  libfreetype6  2.12.1+dfsg-5
ii  libjpeg62-turbo   1:2.1.5-2
ii  libpcre3  2:8.39-15
ii  lxterminal [x-terminal-emulator]  0.4.0-2
ii  qterminal [x-terminal-emulator]   1.2.0-2
ii  whiptail  0.52.23-1+b1
ii  xterm [x-terminal-emulator]   379-1

Versions of packages squeak-vm recommends:
ii  etoys5.0.2408-1
ii  scratch  1.4.0.6~dfsg1-6.1
ii  zenity   3.44.0-1

squeak-vm suggests no packages.

-- no debconf information

Bug#1069973: mailman-hyperkitty: please drop extraneous python3-mock dependency

[Alexandre Detiste]

Source: mailman-hyperkitty
Version: 1.2.1-2
Severity: normal

Dear Maintainer,

This package relies on the newer unittest.mock
from the standard library instead.

Greeting

tchet@quieter:/tmp/mailman-hyperkitty$ grep mock -r
debian/control:   python3-mock,
debian/tests/control: python3-mock,
mailman_hyperkitty/tests/test_archiver.py:from unittest.mock import Mock, patch
tchet@quieter:/tmp/mailman-hyperkitty$

Bug#935905: bash: ":?xxx" filename broken on autocomplete

[Andreas Schwab]

On Apr 27 2024, Kerin Millar wrote:

> In the course of trying this in bash-5.3-alpha, I noticed something else. If 
> ':?aa' is not the only entry in the current working directory, readline 
> behaves as if : is an ambiguous completion. That is:
>
> # mkdir ':?aa'
> # touch 'something-else'
> # rmdir :
>
> ... produces nothing until pressing the tab key a second time, after which 
> both entries are listed while the content of readline's input buffer remains 
> unchanged.

':' is in $COMP_WORDBREAKS.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Bug#1060772: python3-jupyterlab: Using node-corepack downloads yarnpkg from Internet

[Aurelien Jarno]

control: severity -1 serious

On 2024-01-14 08:20, Yadd wrote:
> Package: python3-jupyterlab
> Version: 4.0.9+ds1-1
> Severity: important
> X-Debbugs-Cc: y...@debian.org
> 
> Hi,
> 
> the patch 0003-Use-system-provided-yarn.js.patch replaces missing
> yarn.js by node-corepack. Please keep in mind that
> node-corepack/../yarn.js is a wrapper that downloads yarnpkg from
> Internet instead of using Debian's one.

As network access is forbidden by Debian Policy section 4.9, this is
actually a serious bug. Changing the severity accordingly.

Regards
Aurelien

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

Bug#1036369: ruby-rest-client: network-dependent tests fail

[Aurelien Jarno]

control: severity -1 serious

On 2023-05-20 10:46, Vignesh Raman wrote:
> Package: ruby-rest-client
> Version: 2.1.0-3
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: vignesh.ra...@collabora.com
> 
> Dear Maintainer,
> 
> ruby-rest-client is failing to build because its test suite
> depends on access to the internet,

As network access is forbidden by Debian Policy section 4.9, this is
actually a serious bug. Changing the severity accordingly.

Regards
Aurelien

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

Bug#987017: release-notes: Giving many ways to do something *is* useful

[Manny]

Package: release-notes
Followup-For: Bug #987017
X-Debbugs-Cc: debbug.release-no...@sideload.33mail.com

@ Antoine Beaupre

> Is there any reason why we have all that diversity?
> …
> I'm not arguing for deprecating aptitude altogether, but it would seem
> to me that using less tools in the release notes would be better.

As an aptitude user, I was bothered by the lack of aptitude ways of
doing things in the upgrade guide. I had to research and use guesswork
to work out what is the aptitude-equivalent command, which complicated
my effort. For the minimal system upgrade, users were directed to run
“apt upgrade --without-new-pkgs”. I thought why is the aptitude
approach missing?  Is aptitude incapable of this?  I then went to the
man page and found “aptitude safe-upgrade”. I am still not sure if
that is the equivalent command. And if so, is it exacly the same or
are there differences?

Whether someone wants to know a bit of many tools or be a master of
few tools is a matter of preference, but the docs would ideally
accommodate both kinds of users (though not necessarily in the same
doc… that’s another matter - but if the different methods are
side-by-side in the same doc it helps users learn about the
equivalences and makes it easier for them to settle on a preferred
method). But certainly it’s sensible to drop methods that have no
advantage of any kind.

The advice I was given early in my Debian years was that apt-get was a
more primitive command and aptitude was more complete/comprehensive,
that it logs or tracks more things and generally the better tool
according to folks giving IRC support. I think aptitude calls apt
IIRC, which makes it a higher level tool.

> I am not sure we should tell people to "remove any non-Debian package"
> before the upgrade. They might have legitimate reasons to have
> third-party package repositories...?

Concur. I’m not sure what the past release notes said, but the
Bookworm release notes simply bluntly direct users to “Remove
non-Debian packages”. This was frustrating for me. **Why?** I want to
know why I am doing something. The list of non-Debian packages
contained pkgs *I need*. Users need to know why they are directed to
destroy something they need.

Is there a real likeliness that a non-Debian pkg will make a mess or
disaster of the upgrade?  Or is this step a generic “we only
officially support our officially distributed software” scenario?

I decided to go against the guidance. There was one non-Debian pkg
that I no longer used, so removal was a trivial choice for that
one. But I left the other non-Debian pkgs alone. Some of them broke
and some survived.

The guide should probably suggest removing any non-Debian pkgs that
are not needed to mitigate dependency complications, but simply warn
that non-Debian pkgs allowed to persist might not run correctly and
should be also treated with low priority if conflicts arise.

@ Justin B Rye

>> aptitude search '~o'
>
> This is nice and simple, but frankly as an aptitude user I wouldn't
> bother.  Instead I'd do what the text just above mentions - launch
> aptitude, notice that there was a category for "Obsolete and Locally
> Created Packages"

If the guide is intended to help train the user and advance their
Debian skills, then the CLI advice is probably favorable because it’s
more likely to improve the user’s knowledge than a UI that needs no
manual.

If the guide is intended to just execute steps to do a job (git’r
done), then the CLI is still the winner because it’s just one line for
a user to copy-paste and get instant results with minimal text and
minimal reading.

Briefly mentioning the UI option probably doesn’t hurt though in
addition to the CLI.

>> apt-forktracer | sort
> 
> I've never quite been able to understand how it is that anybody
> could get themselves into the situation of *needing* this specialised
> package installed to work around the weirdness of their setup, but
> still need to be told what it is that's unusual about their system.
> …
>> In my personal documentation, I've settled on `apt-forktracer`,
>
> I'd be interested to know what you find it useful for.

For me, apt-forktracer gives 1 pkg additional output:

$ apt-forktracer | sort
linux-image-5.10.0-16-amd64 (5.10.127-2)
linux-image-5.10.0-19-amd64 (5.10.149-2)
linux-image-5.10.0-6-amd64 (5.10.28-1)
linux-image-5.10.0-7-amd64 (5.10.40-1)
linux-image-5.10.0-8-amd64 (5.10.46-5)
mastodon-archive (1.4.4-izzy1)
openjdk-11-jre (11.0.23+9-1~deb11u1) [Debian: 11.0.22+7-1~deb11u1]
openjdk-11-jre-headless (11.0.23+9-1~deb11u1) [Debian: 11.0.22+7-1~deb11u1]
ungoogled-chromium (90.0.4430.212-1.sid1)
ungoogled-chromium-common (90.0.4430.212-1.sid1)
ungoogled-chromium-sandbox (90.0.4430.212-1.sid1)
ungoogled-chromium-shell (90.0.4430.212-1.sid1)
wire-desktop (3.35.3348-3348)
xdiskusage (1.60-4~bpo12+1) [Debian Backports: 1.60-4~bpo12+1] [Debian: 
1.48-10.1+b1]

The “apt list '?narrow(?installed, ?not(?origin(Debian)))'” command
excludes the last line 

Bug#935905: bash: ":?xxx" filename broken on autocomplete

[Kerin Millar]

On Sat, 27 Apr 2024 23:28:49 +0200
Gioele Barabucci  wrote:

> Control: found -1 5.2.21-2
> 
> On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek  
> wrote:
> > the autocompletion is broken on filenames or directories with ":?" at the 
> > beginning.
> > 
> > # mkdir ':?aa'
> > # rmdir :
> > 
> > gives me
> > 
> > # rmdir :\:\?
> > 
> > which doesn't match the filename; I can finish completion by entering "aa", 
> > but then "rm" rejects this name.
> 
> In bash 5.2.21(1) the filename is now fully completed, but the stray ":" 
> at the beginning is still produced:
> 
>  $ mkdir ':?aa'
>  $ rmdir :
>  $ rmdir :\:\?aa/

In the course of trying this in bash-5.3-alpha, I noticed something else. If 
':?aa' is not the only entry in the current working directory, readline behaves 
as if : is an ambiguous completion. That is:

# mkdir ':?aa'
# touch 'something-else'
# rmdir :

... produces nothing until pressing the tab key a second time, after which both 
entries are listed while the content of readline's input buffer remains 
unchanged.

-- 
Kerin Millar

Bug#690608: logcheck-database: consider to add ignore.d.server/rrdcached

[Richard Lewis]

On Tue, 16 Oct 2012 03:14:20 +0200 Sebastian Steinhuber
 wrote:

> Dear Maintainer,
> to drop (slightly boring) messages from the package rrdcached of the
> form:
> Oct 15 22:59:29 dds rrdcached[12045]: flushing old values
>
> I added a file named ignore.d.server/rrdcached, containing the line:
>
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rrdcached\[[0-9]+\]: flushing
> old values$

Hi Sebastian,
over a decade ago you reported the above bug against
logcheck-database: im sorry no-one replied before today!

Is this rule still valid?  im thinking things may have moved on, and
wondering if the bug is still valid.

Bug#588935: bash-static: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8)

[Gioele Barabucci]

Version: 5.0-6

On Tue, 13 Jul 2010 17:10:39 +0200 "Raoul Bhatia [IPAX]" 
 wrote:

using bash-static as a login shell on debian squeeze. i want to "scp" a
file cleanup.sh from this very machine to another one:

> # scp cle

resulting in:

> # scp cle-bash-static: warning: setlocale: LC_CTYPE: cannot change locale 
(en_US.UTF-8)
> -bash-static: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8)
> anup.sh 


auto complete works thou as you can see by the third line where
bash-static adds "anup.sh"

this does not happen if:

1. i use /bin/bash as a login shell, or
2. i start "bash-static" after login as a regular program.


Hi,

this issue does not seem to affect version 5.0-6 and later of bash.

Please reopen this bug if you can still reproduce this issue.

Regards,

--
Gioele Barabucci

Bug#935905: bash: ":?xxx" filename broken on autocomplete

[Gioele Barabucci]

Control: found -1 5.2.21-2

On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek  
wrote:
the autocompletion is broken on filenames or directories with ":?" at the 
beginning.


# mkdir ':?aa'
# rmdir :

gives me

# rmdir :\:\?

which doesn't match the filename; I can finish completion by entering "aa", 
but then "rm" rejects this name.


In bash 5.2.21(1) the filename is now fully completed, but the stray ":" 
at the beginning is still produced:


$ mkdir ':?aa'
$ rmdir :
$ rmdir :\:\?aa/

Regards,

--
Gioele Barabucci

Bug#442244: [Logcheck-devel] Bug#442244: logcheck-database: should include the filters from cyrus-imapd-2.2

[Richard Lewis]

On Fri, 14 Sep 2007 14:06:58 +0200 martin f krafft  wrote:
> also sprach Alex Prinsier  [2007.09.14.1344 
> +0200]:
> > Please copy over the filters from cyrus-imapd-2.2. I'm running
> > logcheck on a loghost, which doesn't run cyrus itself. There might
> > be a better alternative to copying the file, but anyhow it should
> > be in logcheck-database.

> logcheck is not designed to be run on a loghost, really. I know it
> would be nice, but it's not the general use case. You'll fare best
> if you copy the file over, or simply install the cyrus-imapd-2.2
> package on the loghost and disable all services.
>

I am tempted to  close this bug from 2007:
- No-one has objected to the above two paragraphs since 2007, over a decade ago
- The design of logcheck is that rules can be installed by packages
and logcheck-database should not duplicate that, and it would risk
file conflicts and out of date files.
- People who want to run logcheck on a "loghost" can copy the rules -
for example from sources.debian.org or salsa.debian.org

HOWEVER:  maybe this bug has value as it suggests that the logcheck
ignore.d.serve/cyrus rules should actually be deleted:

apt-file search cyrus | grep logcheck
cyrus-common: /etc/logcheck/ignore.d.server/cyrus-imapd
cyrus-common: /etc/logcheck/violations.ignore.d/cyrus-common
cyrus-common: /etc/logcheck/violations.ignore.d/cyrus-imapd
logcheck-database: /etc/logcheck/ignore.d.server/cyrus

Bug#1069972: Backport cmake 3.29 compatibility fix

[textshell]

Package: extra-cmake-modules
Tags: patch, fixed-upstream
Severity: important
X-Debbugs-CC: c...@istoph.de

Please backport

https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/431

Since cmake 3.29 entered sid, the files created by ECMAddQch.cmake and
shipped in -dev packages cause warnings or errors (with CMP0160 set
to NEW).

Furthermore when libraries that use ECMAddQch are consumed in packages
build using meson, the builds fails as the meson cmake compat code
always sets cmake_minimum_required to the current cmake version and
thus CMP0160 is alway set to NEW which makes the code generated
before the fix an hard error.

For example the package chr now no longer builds in sid because of
this (in combination with ksyntax-highlighting).

-- Configuring incomplete, errors occurred!
ERR:
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/KF5SyntaxHighlighting/KF5SyntaxHighlightingQchTargets.cmake:6
 (set_target_properties):
  IMPORTED property is read-only for target("KF5SyntaxHighlighting_QCH")
Call Stack (most recent call first):
  
/usr/lib/x86_64-linux-gnu/cmake/KF5SyntaxHighlighting/KF5SyntaxHighlightingConfig.cmake:42
 (include)
  CMakeLists.txt:20 (find_package)

(for a full log see https://salsa.debian.org/chr/chr/-/jobs/5651154 )

Regards,
 - Martin

Bug#1069971: git-buildpackage: import-dsc/import-dscs fail with TypeError: Parser must be a string or character stream, not NoneType

[Petter Reinholdtsen]

Package: git-buildpackage
Version: 0.9.30

When trying to bootstrap a git repository with the snapshotted uploads
of nitpick using 'gbp import-dscs', this fail with the following error:

File Imakefile is read-only; trying to patch anyway
File XPICsim is read-only; trying to patch anyway
File pu_defs.h is read-only; trying to patch anyway
File pu_lib.c is read-only; trying to patch anyway
Traceback (most recent call last):
  File "/usr/bin/gbp", line 149, in 
sys.exit(supercommand())
 ^^
  File "/usr/bin/gbp", line 145, in supercommand
return module.main(args)
   ^
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dscs.py", line 180, 
in main
if importer.importdsc(dscs[0]):
   ^^^
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dscs.py", line 72, in 
importdsc
return import_dsc.main(['import-dsc'] + self.args + [dsc.dscfile])
   ^^^
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py", line 531, in 
main
apply_debian_patch(repo, sources[0], dsc, commit, options)
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py", line 175, in 
apply_debian_patch
author = get_author_from_changelog(source.unpacked)
 ^^
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py", line 116, in 
get_author_from_changelog
date = rfc822_date_to_git(dch.date, fuzzy=True)
   
  File "/usr/lib/python3/dist-packages/gbp/git/__init__.py", line 44, in 
rfc822_date_to_git
d = dateutil.parser.parse(rfc822_date, fuzzy=fuzzy)
^^^
  File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py", line 1368, 
in parse
return DEFAULTPARSER.parse(timestr, **kwargs)
   ^^
  File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py", line 640, 
in parse
res, skipped_tokens = self._parse(timestr, **kwargs)
  ^^
  File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py", line 719, 
in _parse
l = _timelex.split(timestr) # Splits the timestr into tokens
^^^
  File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py", line 201, 
in split
return list(cls(s))
^^
  File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py", line 69, in 
__init__
raise TypeError('Parser must be a string or character stream, not '
TypeError: Parser must be a string or character stream, not NoneType


A simple way to reproduce it is to download the nitpic_0.1-1.dsc source
package and try to import it into a fresh 'git init' directory like
this:

  gbp import-dsc --pristine-tar ../nitpic_0.1-1.dsc

I suspect the problem is the d/changelog entry:

nitpic (0.1-1) unstable; urgency=low

  * Initial release.

 --   Fri, 7 Feb 1997 00:02:50 -0500

Perhaps it is unable to handle no name in front of the mail address?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1066875: devscripts: debsign tries to parse gpg version from human-readable output, should use machine-readable output

[Guillem Jover]

Hi!

On Thu, 2024-03-14 at 14:55:36 -0400, Daniel Kahn Gillmor wrote:
> Package: devscripts
> Version: 2.23.7
> Tags: patch

> debsign currently tries to determine the version of gpg by parsing the
> human-readable output of `gpg --version`.

[…]

> The attached patch converts debsign to use the machine-parseable format,
> rather than the human-readable format.

I was just modifying this code for another report I'm about to file,
and instead wondered why have it at all! I'm proposing simply removing
the backwards compat code given that even in oldstable gnugp1 is
already at verison 1.4.23. See attached patch.

Thanks,
Guillem
From a9601103ca8deb4aeaaca04b8f42272ced6fde27 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 27 Apr 2024 23:06:39 +0200
Subject: [PATCH] debsign: Remove compatibility code for ancient GnuPG

The code is trying to handle GnuPG versions older than 1.4, where
the oldest GnuPG version available in Debian via the gnupg1 package
is 1.4.23 since oldstable. So there is no much point in trying to
support even older versions.

Remove the code to simplify things.
---
 scripts/debsign.sh | 37 ++---
 1 file changed, 10 insertions(+), 27 deletions(-)

diff --git a/scripts/debsign.sh b/scripts/debsign.sh
index 15b0dfc2..2ddb8b11 100755
--- a/scripts/debsign.sh
+++ b/scripts/debsign.sh
@@ -170,33 +170,16 @@ signfile() {
 ASCII_SIGNED_FILE="${UNSIGNED_FILE}.asc"
 (cat "$file" ; echo "") > "$UNSIGNED_FILE"
 
-gpgversion=$($signcommand --version | head -n 1 | cut -d' ' -f3)
-gpgmajorversion=$(echo $gpgversion | cut -d. -f1)
-gpgminorversion=$(echo $gpgversion | cut -d. -f2)
-
-if [ $gpgmajorversion -gt 1 -o $gpgminorversion -ge 4 ]
-then
-	$signcommand --no-auto-check-trustdb \
-		--local-user "$signas" --clearsign \
-		--list-options no-show-policy-urls \
-		--armor --textmode --output "$ASCII_SIGNED_FILE"\
-		"$UNSIGNED_FILE" || \
-	{ SAVESTAT=$?
-	  echo "$PROGNAME: $signcommand error occurred!  Aborting" >&2
-	  stty $savestty 2>/dev/null || true
-	  exit $SAVESTAT
-	}
-else
-	$signcommand --local-user "$signas" --clearsign \
-		--no-show-policy-url \
-		--armor --textmode --output "$ASCII_SIGNED_FILE" \
-		"$UNSIGNED_FILE" || \
-	{ SAVESTAT=$?
-	  echo "$PROGNAME: $signcommand error occurred!  Aborting" >&2
-	  stty $savestty 2>/dev/null || true
-	  exit $SAVESTAT
-	}
-fi
+$signcommand --no-auto-check-trustdb \
+	--local-user "$signas" --clearsign \
+	--list-options no-show-policy-urls \
+	--armor --textmode --output "$ASCII_SIGNED_FILE"\
+	"$UNSIGNED_FILE" || \
+{ SAVESTAT=$?
+  echo "$PROGNAME: $signcommand error occurred!  Aborting" >&2
+  stty $savestty 2>/dev/null || true
+  exit $SAVESTAT
+}
 stty $savestty 2>/dev/null || true
 echo
 PRECIOUS_FILES=$(($PRECIOUS_FILES + 1))
-- 
2.43.0

Bug#789401: Proposed patch to solve the issue.

[Georgios Zarkadas]

Hi Thorsten,

Limiting access to the expanded chroot is something that can be done.

I currently use a `build' group and have {mode 750, ug root:build}  the
build directory,
were the base tgzs are unpacked as subdirectories, and {mode 2775, ug
root:build}
the result directory, so that pdebuild-internal can copy back resulting
debs.

`build' group members are the developers that can use pbuilder. This is a
separate group
than the one that has sudo rights to run pbuilder (though both have the
same members);
its sole role is to allow write access to the result directory and read
access to the build
directory.

I made this setup recently and maybe it needs some tuning (probably mode 775
for the result directory is enough), but so far packages build successfully
with it.

However, this solution requires the creation of a system group during
pbuilder's installation
and setting permissions to the associated directories. Also whoever uses a
custom directory
setup should afterwards set the above permissions accordingly.

/tmp/buildd is already preserved by the compatibility symlink code inside
pbuilder, in the sense
that it is there after the base tgz unpacking. Even if the compatibility
code is removed, one can
set BUILDDIR=/tmp/buildd in pbuilderrc and have it there, as long as
BUILDDIR is always created
during unpacking. That's why I have shipped the patch with the modified
comments at that point.

Even if a choice is made for pbuilder to support limiting access to the
expanded chroot,
I believe that chroot's temporary directories should be cleaned before
creating the base tgz.
Other things also go there (hookdir, pbuildersatisfydepends package, etc.)
and, since by design
these directories are for temporary stuff, persistence should not be
anticipated.

Cheers,
Georgios

Στις Σάβ 27 Απρ 2024 στις 5:10 μ.μ., ο/η Thorsten Glaser 
έγραψε:

> Hi Georgios,
>
> why not just ensure the parent directory of the chroot is not
> traversable for just any normal user?
>
> That would allow preserving /tmp/buildd as build place as well
> as retaining stuff under /run which packages create and which
> is, in practice, often needed for chroots where initscripts are
> not run.
>
> In addition, I often do use the access to the /tmp in the chroot
> for debugging and bootstrapping, so maybe create a new system
> group, chown 0:_pbuilder /var/cache/pbuilder/build; chmod 0750
> that directory, and good is? (Untested.)
>
> Then, I could add my user to that group and continue doing so.
>
> bye,
> //mirabilos
> --
> „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
> mksh auf jedem System zu installieren.“
> -- XTaran auf der OpenRheinRuhr, ganz begeistert
> (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
>

Bug#588312: [Logcheck-devel] Bug#588312: logcheck-database: updated rules for many packages

[Richard Lewis]

Closing this bug from 2010 (14 years ago!) -- the then-maintainer
found that most of the suggestions were either already present or
should not actually be added, for various reasons.

A requested was made to resubmit as more independent bugs - if that
was done, we dont need this bug, and if not that suggests there is no
interest in proceeding.

Either way, the best thing seems to be to close this bug. Please
reopen with updated rules, if needd


On Thu, 08 Jul 2010 13:58:47 +0200 Hannes von Haugwitz
 wrote:
> Hi,
>
> Like Gerfried said, please file different bug reports for different
> packages the next time.
>
> Some comments about your rule suggestions:
>
> Radosław Antoniuk wrote:
> >> #dkimproxy
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: connect from 
> >> .*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: DKIM signing - 
> >> signed; .*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dkimproxy.out\[[0-9]+\]: DKIM signing - 
> >> skipped; .*$
> >
> > No rules at all.
> >
> >
> > Jul  7 12:39:21 hosting dkimproxy.out[1508]: DKIM signing - skipped;
> > message-id=,
> > from=
> > Jul  7 12:39:21 hosting dkimproxy.out[1508]: DKIM signing - signed;
> > message-id=,
> > from=
> > Jul  7 12:39:21 hosting dkimproxy.out[1508]: connect from 127.0.0.1
> >
>
> I don't see the need of wildchar .* here.
>
> >
> >> #ssh
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd\[[0-9]+\]: error writing 
> >> /proc/self/oom_adj: Operation not permitted$
> >
> > Not there.
> >
>
> Looks like an error for me, maybe #555625?
>
> >> #ntp
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ ntpd\[[0-9]+\]: kernel time sync status 
> >> change 4001
> >
> > No config at all
> >
>
> This message shouldn't occur anymore (see #498992).
>
> >
> >> #syslog-ng
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslog-ng\[[0-9]+\]: Log statistics;.*$
> >> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslog-ng\[[0-9]+\]: Configuration 
> >> reload request received, reloading configuration;$
> >
> >
> > syslog-ng[31823]: Log statistics; processed='destination(d_error)=3',
> > processed='destination(d_messages)=298',
> > processed='src.internal(s_src#1)=90',
> > stamp='src.internal(s_src#1)=1278499023',
> > processed='destination(d_syslog)=90', processed='center(received)=0',
> > processed='destination(d_xconsole)=3',
> > processed='destination(d_newscrit)=0',
> > processed='destination(d_auth)=1452',
> > processed='destination(d_daemon)=1',
> > processed='global(payload_reallocs)=0',

Bug#511483: logcheck-database: please add rules for rkhunter

[Richard Lewis]

package: logcheck-database

# think it's reasonable to add rkhunter rules - although the ones in
this bug need updates
severity 511483 normal
tags 511481 - wontfix

Bug#1069964: debian-installer: Debian LXQt ISO loads all unnecessary proprietary firmware even with firmware=never parameter

[Cyril Brulebois]

Hi,

Thanks for the report but wow, that's way too many topics.

baptx  (2024-04-27):
> The following issue is based on the discussion I created on
> https://forums.debian.net/viewtopic.php?t=159027 where you can find
> attached the content of /var/log/installer/syslog which was generated
> on a virtual machine with virt-manager when installing
> debian-live-12.5.0-amd64-lxqt.iso with the firmware=never parameter
> (the problem was also present on my real computer when I tested with a
> previous version debian-live-12.0.0-amd64-lxqt.iso). I also attached
> the result of the vrms command after using firmware=never parameter.

vrms is irrelevant.

> To compare, you can also find attached another installer syslog
> without using firmware=never parameter, which also contains the line
> "hw-detect: skipping check-missing-firmware as requested by the
> caller" and looks like a bug.

No, it's not. See check on CHECK_MISSING_FIRMWARE in hw-detect.

> The firmware=never parameter did not work at all when using the LXQt
> ISO file (maybe the problem also happens on ISO files with other
> desktop environments), the non-free firmware packages were installed.

That would be a bug in debian-live then, not in debian-installer. Cc-ing
accordingly.

> And with the LXQt ISO file, the graphical expert install as well as
> the text expert install did not ask me if I want the non-free firmware
> packages, they were installed automatically.

> I noticed the firmware=never parameter only worked with the netinst
> ISO file.

Well, that's been added for use by debian-installer. What debian-live
does or doesn't do with it is outside our control.

> For the automatic detection of needed non-free firmware packages, it
> only worked with the netinst ISO file as well (the LXQt ISO file
> installed all non-free firmware packages). But even with netinst ISO
> file, it seems it is only guessing the non-free firmware packages
> needed since several were not needed to make my laptop work correctly
> (firmware-realtek, firmware-sof-signed) when installed on my real
> computer instead of a virtual machine.

The lookup is based on what devices are seen during the installation
process. If the relevant kernel modules list firmware files, we try to
match them to firmware packages, and queue their installation. Unless
firmware=never was used of course. That doesn't mean they are absolutely
required for those devices to work. There is just no way to know for
sure.

> It would also be useful to have the firmware=never parameter added in
> a menu in the normal graphical installation (for people who don't want
> the complexity of the expert installation), since it is more
> convenient to have it in a menu and also avoids mistakes when typing
> firmware=never (I accidentally typed firmzare due to my AZERTY
> keyboard and the QWERTY input).

Menu maintenance (esp. across architectures, BIOS vs. UEFI, etc.) is a
huge mess already, it might happen but I'm not holding my breath here.

> It would be a good idea to warn the user if the entered parameter /
> value does not exist, to avoid unwanted results like installing
> non-free firmware.

There's no absolute list to check against, so that cannot be done.


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


signature.asc
Description: PGP signature

Bug#1059417: ed: diff for NMU version 1.20.1-1.1

[Chris Hofstaedtler]

Lev,

* Sven Joachim  [240427 19:48]:
> On 2024-04-17 14:26 +0200, Chris Hofstaedtler wrote:
> > I've prepared an NMU for ed (versioned as 1.20.1-1.1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
> 
> Seems your NMU was ignored and reverted in the latest upload. :-(

I'm guessing you didn't see the bug-mail / NMU so far? Are you going
to upload the patch yourself?

Chris

Bug#1069970: ITP: libeddsa-java -- implementation of EdDSA in Java

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-Java team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org

* Package name: libeddsa-java
  Version : 0.3.0
  Upstream Contact: str4d
* URL : https://github.com/str4d/ed25519-java
* License : CC0-1.0
  Programming Lang: Java
  Description : implementation of EdDSA in Java

This package is needed as a dependency of libmina-sshd-java and of new upstream
versions of jgit. I plan to maintain it in the Debian-Java team and to be its
first uploader.


This implementation of EdDSA is based on the ref10 implementation in SUPERCOP.

There are two internal implementations:
- A port of the radix-2^51 operations in ref10 - fast and constant-time, but
  only useful for Ed25519;
- A generic version using BigIntegers for calculation - a bit slower and not
  constant-time, but compatible with any EdDSA parameter specification.

Bug#1069968: ruby3.2: CVE-2024-27282

[Salvatore Bonaccorso]

Source: ruby3.2
Version: 3.2.3-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src;ruby3.1 3.1.2-8
Control: retitle -2 ruby3.1: CVE-2024-27282
Control: found -2 3.1.2-7

Hi,

The following vulnerability was published for ruby.

CVE-2024-27282[0]:
| Arbitrary memory address read vulnerability with Regex search


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-27282
https://www.cve.org/CVERecord?id=CVE-2024-27282
[1] 
https://www.ruby-lang.org/en/news/2024/04/23/arbitrary-memory-address-read-regexp-cve-2024-27282/
[2] https://github.com/ruby/ruby/commit/989a2355808a63fc45367785c82ffd46d18c900a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1069966: ruby3.1: CVE-2024-27280: Buffer overread vulnerability in StringIO

[Salvatore Bonaccorso]

Source: ruby3.1
Version: 3.1.2-8
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.1.2-7

Hi,

The following vulnerability was published for ruby3.1.

CVE-2024-27280[0]:
| Buffer overread vulnerability in StringIO


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-27280
https://www.cve.org/CVERecord?id=CVE-2024-27280
[1] https://www.ruby-lang.org/en/news/2024/03/21/buffer-overread-cve-2024-27280/

Regards,
Salvatore

Bug#1069967: fai-client: install_packages E: Unable to locate package ...

[Markus Rexhepi-Lindberg]

Package: fai-client
Severity: wishlist

Dear Maintainer,

When a non-existing package is in the list of packages passed to
install_packages apt-get responds with the following error message.

E: Unable to locate package ...

This in turn fails the installation of all the packages in the list.

I know this is the default behavior of apt-get but I would like to
request an option for install_packages to ignore non-existing packages
and retry the installation again with the same list but without the
non-existing package(s).

If such an option won't be implemented then an option to isolate a list
of packages to be installed could also work. Then a user could define a
list of packages that they would be ok with not being installed due to
reasons such as them being non-existing.

--
Markus

Bug#592365: logcheck: ignore rules for transmission-daemon

[Richard Lewis]

On Tue, 10 Aug 2010 10:28:54 +1000 Nemo  wrote:

> > ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ 
> > transmission-daemon\[[[:digit:]]+\]: Saved 
> > "/var/lib/transmission-daemon/info/.*" \(bencode.c:1651\)$
> > ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ transmission-daemon\[[0-9]+\]: .* DHT 
> > announce .*\(tr-dht.c:(669|637)\)$

Hi Nemo, in 14 years ago you reported a bug against logcheck-database
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592365 -

I believe you suggested that the above be added to logcheck.

It;s a shame no-one ever replied to you - let me at least try now:

Are these rules still needed for transmission-daemon? I imagine there
may have been several changes to message formats since then.

Bug#1069965: planner: When managing calendars, it isn't really possible to delete one. Hopeless to set Sunday as workday.

[Tommy Bollman]

Package: planner
Version: 0.14.91-2
Severity: normal
X-Debbugs-Cc: tommy.boll...@gmail.com

Dear Maintainer, planner: When managing calendars, it isn't really possible to
delete a calendar from the list box. It is also hopeless to set Sunday as
workday, when in the "calendar view" I am bummed, I used a version of planner
for a project around New years eve 2023, and I didn't find any faults with it.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I tried to delete a calendar under managing calendars, but it just wouldn't
go away. The parent I could delete, but then the child ended up in the list
view.
   It also came with three! default calendars in the calendar view.

   I tried multiple times to set Sunday as workday, but to no avail.
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 6.6.17-01102-gd3cec3c11146 (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)

Versions of packages planner depends on:
ii  gir1.2-gtk-2.0   2.24.33-2
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u6
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libgail-3-0  3.24.38-2~deb12u1
ii  libgda-5.0-4 5.2.10-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  libxslt1.1   1.1.35-1
pn  planner-data 
ii  python3-gi   3.42.2-3+b1
ii  shared-mime-info 2.2-1

Versions of packages planner recommends:
pn  planner-doc  

planner suggests no packages.

Bug#1069964: debian-installer: Debian LXQt ISO loads all unnecessary proprietary firmware even with firmware=never parameter

[baptx]

Package: debian-installer
Severity: important
X-Debbugs-Cc: baptx...@gmail.com

The following issue is based on the discussion I created on 
https://forums.debian.net/viewtopic.php?t=159027 where you can find attached 
the content of /var/log/installer/syslog which was generated on a virtual 
machine with virt-manager when installing debian-live-12.5.0-amd64-lxqt.iso 
with the firmware=never parameter (the problem was also present on my real 
computer when I tested with a previous version 
debian-live-12.0.0-amd64-lxqt.iso). I also attached the result of the vrms 
command after using firmware=never parameter. To compare, you can also find 
attached another installer syslog without using firmware=never parameter, which 
also contains the line "hw-detect: skipping check-missing-firmware as requested 
by the caller" and looks like a bug.

The firmware=never parameter did not work at all when using the LXQt ISO file 
(maybe the problem also happens on ISO files with other desktop environments), 
the non-free firmware packages were installed. And with the LXQt ISO file, the 
graphical expert install as well as the text expert install did not ask me if I 
want the non-free firmware packages, they were installed automatically.
I noticed the firmware=never parameter only worked with the netinst ISO file.
For the automatic detection of needed non-free firmware packages, it only 
worked with the netinst ISO file as well (the LXQt ISO file installed all 
non-free firmware packages). But even with netinst ISO file, it seems it is 
only guessing the non-free firmware packages needed since several were not 
needed to make my laptop work correctly (firmware-realtek, firmware-sof-signed) 
when installed on my real computer instead of a virtual machine.
Can these issues be fixed?

It would also be useful to have the firmware=never parameter added in a menu in 
the normal graphical installation (for people who don't want the complexity of 
the expert installation), since it is more convenient to have it in a menu and 
also avoids mistakes when typing firmware=never (I accidentally typed firmzare 
due to my AZERTY keyboard and the QWERTY input). It would be a good idea to 
warn the user if the entered parameter / value does not exist, to avoid 
unwanted results like installing non-free firmware.

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

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

Bug#1034993: software-properties-qt: missing Conflicts+Replaces for software-properties-kde when upgrading from bullseye

[Andreas Beckmann]

Followup-For: Bug #1034993
Control: tag -1 patch pending

I'v just uploaded a NMU with the attached changes to DELAYED/14. My
intention is to rebuild this for bookworm-pu to get this fixed in a
point release.
Please let me know if I should delay it longer.


Andreas
diff --git a/debian/changelog b/debian/changelog
index 8c9ea885..92415036 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+software-properties (0.99.30-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * software-properties-qt: Add Conflicts+Replaces: software-properties-kde
+for smoother upgrades from bullseye.  (Closes: #1034993)
+
+ -- Andreas Beckmann   Sat, 27 Apr 2024 21:08:49 +0200
+
 software-properties (0.99.30-4) unstable; urgency=medium
 
   * py3-software-properties: Depend on lazr.restfulclient (Closes: #1029047)
diff --git a/debian/control b/debian/control
index 94d20bd7..790eaae4 100644
--- a/debian/control
+++ b/debian/control
@@ -109,6 +109,8 @@ Depends: debconf-kde-helper,
  ${misc:Depends},
  ${python3:Depends}
 Suggests: plasma-discover
+Conflicts: software-properties-kde
+Replaces: software-properties-kde
 Description: manage the repositories that you install software from (Qt)
  This software provides an abstraction of the used apt repositories.
  It allows you to easily manage your distribution and independent software

Bug#1069405: x11-apps: FTBFS on arm64: configure: error: Package requirements (x11-xcb xcb-present >= 1.9 xcb-xfixes xcb-damage) were not met

[Andreas Beckmann]

Followup-For: Bug #1069405
Control: retitle -1 x11-apps: FTBFS with libxcb 1.17: Package requirements 
(x11-xcb xcb-present >= 1.9 xcb-xfixes xcb-damage) were not met
Control: block -1 with 1069408

This happens on all architectures and is probably caused by the missing
libxcb-dri3-dev dependency in libxcb-present-dev. (#1069408)

Andreas

Bug#1069963: python-nbxmpp: Build-depends on NBS package libglib2.0-0

[Scott Kitterman]

Source: python-nbxmpp
Version: 4.5.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

This package has a hard coded build-depends on libglib2.0-0, which is
NBS and the package will FTBFS once it is decrufted.  It was renamed
libglib2.0-0t64 as part of the 64 bit time transition.

Please update your build-depends.

Scott K

Bug#1069962: renpy: Missing dependency on python3-ecdsa

[Antoine Le Gonidec]

Package: renpy
Version: 8.1.3+dfsg-1
Severity: normal

`import ecdsa` is called from /usr/share/games/renpy/renpy/savetoken.py,
but the renpy package has no dependency on python3-ecdsa.

This leads to a crash when this file is loaded:

Traceback (most recent call last):
  File "/usr/games/renpy", line 252, in 
main()
  File "/usr/games/renpy", line 248, in main
renpy.bootstrap.bootstrap(renpy_base)
  File "/usr/share/games/renpy/renpy/bootstrap.py", line 250, in bootstrap
renpy.import_all()
  File "/usr/share/games/renpy/renpy/__init__.py", line 428, in import_all
import renpy.savetoken
  File "/usr/share/games/renpy/renpy/savetoken.py", line 26, in 
import ecdsa
ModuleNotFoundError: No module named 'ecdsa'

Installing the python3-ecdsa package is enough to avoid this error, but
it should probably be added to the direct dependencies of the renpy
package.

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

Kernel: Linux 6.7.9-amd64 (SMP w/8 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

Versions of packages renpy depends on:
ii  fonts-dejavu-core 2.37-8
ii  fonts-motoya-l-cedar  1.01-5
ii  fonts-nanum   20200506-1
ii  fonts-roboto-hinted   2:0~20170802-3
ii  python3   3.11.8-1
ii  python3-pefile2023.2.7-3
ii  python3-pygame-sdl2   8.2.1-1
ii  python3-renpy 8.1.3+dfsg-1+b1
ii  python3-six   1.16.0-6

Versions of packages renpy recommends:
pn  python3-tk  
pn  zenity  

renpy suggests no packages.

-- no debconf information

Bug#1069961: ImportError: cannot import name 'RWops_from_file' from 'pygame_sdl2.rwobject'

[Antoine Le Gonidec]

Package: renpy
Version: 8.1.3+dfsg-1
Severity: important

When trying to run commercial games with Debian-provided renpy (I tried
Slay the Princess and Roadwarden), a crash is triggered before the game
window would be shown:

Traceback (most recent call last):
  File "/usr/games/renpy", line 252, in 
main()
  File "/usr/games/renpy", line 248, in main
renpy.bootstrap.bootstrap(renpy_base)
  File "/usr/share/games/renpy/renpy/bootstrap.py", line 250, in bootstrap
renpy.import_all()
  File "/usr/share/games/renpy/renpy/__init__.py", line 409, in import_all
import renpy.loader
  File "/usr/share/games/renpy/renpy/loader.py", line 37, in 
from pygame_sdl2.rwobject import RWops_from_file, RWops_create_subfile
ImportError: cannot import name 'RWops_from_file' from 'pygame_sdl2.rwobject' 
(/usr/lib/python3/dist-packages/pygame_sdl2/rwobject.cpython-311-x86_64-linux-gnu.so)

The import line triggering this error is no longer part of the upstream
codebase, it has been replaced with the following commit:
https://github.com/renpy/renpy/commit/13cfd68491a38ca1d864c6b668b8c527e58923e2

Applying this patch on top of the cuurent sid build does indeed avoid
this crash, and allow to run the games I tested.

I suggest either backporting this patch, or, better, packaging the
current upstream release (8.2.1).

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

Kernel: Linux 6.7.9-amd64 (SMP w/8 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

Versions of packages renpy depends on:
ii  fonts-dejavu-core 2.37-8
ii  fonts-motoya-l-cedar  1.01-5
ii  fonts-nanum   20200506-1
ii  fonts-roboto-hinted   2:0~20170802-3
ii  python3   3.11.8-1
ii  python3-pefile2023.2.7-3
ii  python3-pygame-sdl2   8.2.1-1
ii  python3-renpy 8.1.3+dfsg-1+b1
ii  python3-six   1.16.0-6

Versions of packages renpy recommends:
pn  python3-tk  
pn  zenity  

renpy suggests no packages.

-- no debconf information

Bug#1015201: logcheck: Update patterns, here: rsyslogd

[Richard Lewis]

On Sun, 17 Jul 2022 17:28:11 +0100 Richard Lewis
 wrote:
> > The pattern for rsyslogd can be improved. Please add the following
> > line:
> >
> > imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' \(fd 3\) from 
> > systemd.  \[v8.2206.0\]
> >
> > You might want to generalize the fd (on my system it is always fd 3,
> > but I don't know if this is general) and possibly the version number;
> > ideally this would remain in sync to whatever is in testing.
>
> I have the following rules in etc/logcheck/ignore.d.server/local-rsyslog
>
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ systemd\[1\]: rsyslog\.service:
> Sent signal SIGHUP to main process [0-9]+ \(rsyslogd\) on client
> request\.$
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd\[[0-9]+\]: \[origin
> software="rsyslogd" swVersion="[0-9.]+" x-pid="[0-9]+"
> x-info="https://www.rsyslog.com"\] rsyslogd was HUPed$
>
> so you might like to add those too. (i believe these are caused by
> logrotate via /usr/lib/rsyslog/rsyslog-rotate , the latter being part
> of rsyslog). they are relevant to bullseye systems

Hi Helge. Apologies no-one has replied to this bug report for 2 years
and that this response isnt going to be what you want!

The rules for rsyslog are actually provided by rsyslog not
logcheck-database so this bug should be against rsyslog --
however, im not sure rsyslog produces those messages about HUP any
more so maybe it should be closed rather than reassigned?

I do see the one about the unix socket but
a) i wonder if that's a bug rather that should be hidden?
b) I also think i only see it  "startup" (ie only produced when the
system boots / service starts):
debian usually doesnt add rules to filter startup messages as it tends
to add a lot of rules

(apologies if i am wrong on this - i dont usually have rsyslog
installed, but ve been running it in a container for testing some
upcoming changes to logcheck and
i don't see either of the messages above despite running for several days).

Bug#1069883: most: copyright - mark the ftp:// address not available (N/A)

[Benj. Mako Hill]

Thanks for catching that. I'll update the URL with the next upload.

Regards,
Mako




> Package: most
> Version: 5.2.0-1+b1
> Severity: minor
> 
> https://metadata.ftp-master.debian.org/changelogs//main/m/most/most_5.2.0-1_copyright
> 
> Suggest to add a note[1], that the sources are no longer available
> at the location:
> 
> This package was put together by Chris Fearnley ,
> from the GNU sources, which I obtained from
>   ftp://space.mit.edu/pub/davis/most/
> 
> => 
> 
> This package was put together by Chris Fearnley ,
> from the GNU sources, which I obtained from
>   ftp://space.mit.edu/pub/davis/most/
> As of 2024-04-26 the sources are no longer avilable
> 
> [1]
> lftp ftp://space.mit.edu/pub/davis/most/
> cd: Access failed: 550 No such directory. (/pub/davis/most)
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages most depends on:
> ii  libc6  2.37-15
> ii  libslang2  2.3.3-3+b1
> 
> most recommends no packages.
> 
> most suggests no packages.
> 
> -- no debconf information
> 

-- 
Benjamin Mako Hill
https://mako.cc/


signature.asc
Description: PGP signature

Bug#532719: [Logcheck-devel] Bug#532719: additional sample

[Richard Lewis]

On Tue, 16 Jun 2009 11:27:57 -0700 Russ Allbery  wrote:
> chrysn  writes:

> touch /etc/default/locale will also make these go away with no behavior
> changes.  In my experience, it happens on systems upgraded from older
> versions of Debian but not with new installs.  I think this is more a
> bug or misconfiguration than something that logcheck really should be
> filtering out.

For the reason given above in 2009 im closing this bug asking to
filter a message about a missing locale:
debian installs a locale by defuault and not having one is unusual: if
the file disappeared most people
would want to know about it, so logcheck should be reporting it.

people who want to have a system without a locale set (assuming that
is even still possible - and why not just set it to C?)
can of course add a local rule to filter the message, but i see no
case for hiding this message by default.

Therefore, closing this bug.

If there's some case im missing, it can be reopened of couse

Bug#510472: logcheck-database: pam_unix messages could be ignored.

[Richard Lewis]

On Tue, 18 Aug 2009 20:24:31 -0400
=?iso-8859-1?B?RnLpZOlyaWMgQnJp6HJl?=  wrote:
> On Fri, Jan 02, 2009 at 10:21:51AM +0100, Jan Evert van Grootheest wrote:
> > Package: logcheck-database
> > Version: 1.2.68
> >
> > It has now started to spam the logs with lots of
> > Jan  2 09:22:57 sisko sshd[28511]: pam_unix(sshd:auth): authentication 
> > failure; logname= uid=0 euid=0 tty=ssh ruser= 
> > rhost=host92-22-static.38-79-b.business.telecomitalia.it  user=root
>
> This is a duplicate of #70, which was fixed a while ago.  (The fix
> was actually part of 1.2.64, so I'm assuming you filed this report from
> a different machine.)
>
> > And on another system the same is happening for imapd.
>
> Are we talking about cyrus-imapd-2.2?  Could you provide an example?

This bug is from 2009, and has been tagged moreinfo for much of that
time: i fear the world has moved on:
- logcheck-database filters messages from pam for successful login
- most people would want to know about authentication failures,
especially since root is not allowed to ssh in by default these days
- those that get too many authentication failures can and should add
their local rule, but i dont see a case to filter such methods by
default
- there isnt really anything actionable in this report anyway

Therefore: closing it - anyone is feel free to reopen!

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Chris Hofstaedtler]

On Fri, Apr 26, 2024 at 08:06:15PM +0100, RL wrote:
> the chkrootkit package provides several utilities for examining some of
> these files: chkutmp chkwtmp and check_wtmpx and chklastlog [a] -- it does
> not use pam but reads the files in /var/log
> 
> How would I test these against the new files - i assume the new versions
> are compatable but might need bigger variables in those utilities?

As briefly mentioned on the wiki page, TTBOMK the new files are
sqlite3 databases.

> https://salsa.debian.org/pkg-security-team/chkrootkit

I took a quick look, but I'm not sure which of the checks would be
applicable. For checks that do not rely on the implications of the
old file structure, you can probably use libwtmpdb or use
libsqlite3-0 directly.

Chris

Bug#590684: [logcheck-database] rules for rsyslog

[Richard Lewis]

On Mon, 02 Aug 2010 10:29:03 +0200 Hannes von Haugwitz
 wrote:

> > ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ rsyslogd: \[origin
> > software="rsyslogd" swVersion="3.18.6" x-pid="[[:digit:]]+"
> > x-info="http://www.rsyslog.com"\] restart$
>
> Daemon restart messages are willingly not included in logcheck-database.
>
> So I tag this bug as wontfix.

I think we can actually close this bug 14-year old bug: rsyslog
provides its own rules for logcheck and those rules do cover the
startup message (which has changed since the report).

Bug#1066721: netcat: FTBFS: netcat.c:1557:9: error: implicit declaration of function ‘helpme’ [-Werror=implicit-function-declaration]

[Andreas Beckmann]

Followup-For: Bug #1066721
Control: tag -1 patch

I've committed a fix to the git repository. Will followup with a NMU in a
few days. I've also enabled the salsa-ci pipeline for the package.

Andreas

Bug#1059417: ed: diff for NMU version 1.20.1-1.1

[Sven Joachim]

Control: found -1 1.20.2-1

On 2024-04-17 14:26 +0200, Chris Hofstaedtler wrote:

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

Seems your NMU was ignored and reverted in the latest upload. :-(

Cheers,
   Sven

> diff -Nru ed-1.20.1/debian/changelog ed-1.20.1/debian/changelog
> --- ed-1.20.1/debian/changelog2024-02-17 12:12:41.0 +0100
> +++ ed-1.20.1/debian/changelog2024-04-17 14:22:21.0 +0200
> @@ -1,3 +1,12 @@
> +ed (1.20.1-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Install ed, red into /usr/bin. (Closes: #1059417)
> +Keep update-alternatives calls unchanged, to preserve existing
> +user configuration.
> +
> + -- Chris Hofstaedtler   Wed, 17 Apr 2024 14:22:21 +0200
> +
>  ed (1.20.1-1) unstable; urgency=medium
>
>* New upstream version 1.20.1
> diff -Nru ed-1.20.1/debian/rules ed-1.20.1/debian/rules
> --- ed-1.20.1/debian/rules2024-02-17 12:12:41.0 +0100
> +++ ed-1.20.1/debian/rules2024-04-17 14:21:33.0 +0200
> @@ -12,7 +12,7 @@
>   dh $@
>
>  override_dh_auto_configure:
> - dh_auto_configure -- --bindir=/bin $(CROSS) \
> + dh_auto_configure -- $(CROSS) \
> $(foreach v,CPPFLAGS CFLAGS LDFLAGS,'$(v)=$($(v))')
>
>  override_dh_auto_test:

Bug#1066842: Updating extrepo-offline-data in Debian Stable (debdiff)

[Jonathan Wiltshire]

On Tue, Apr 23, 2024 at 09:10:54AM +0200, Thomas Goirand wrote:
> diff -Nru extrepo-data-1.0.3/debian/changelog 
> extrepo-data-1.0.3+deb12u1+1/debian/changelog
> --- extrepo-data-1.0.3/debian/changelog   2022-10-13 16:27:28.0 
> +0200
> +++ extrepo-data-1.0.3+deb12u1+1/debian/changelog 2024-04-23 
> 09:03:00.0 +0200
> @@ -1,3 +1,10 @@
> +extrepo-data (1.0.3+deb12u1+1) bookworm; urgency=medium
> +
> +  * Update the repo data from the Debian unstable branch.
> +  * Fix d/copyright mime syntax.
> +
> + -- Thomas Goirand   Tue, 23 Apr 2024 09:03:00 +0200

There's a stray "+1" in the version, should be 1.0.3+deb12u1.

Is this actually a backport of current unstable though? In which case it
should include the changelog from 1.0.4 and be 1.0.4~deb12u1.

With one fix or the other, 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#1068422: possibly caused by python 3.12.3 Re: Bug#1068422: can't import dask.dataframe - TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 'property' object

[Antonio Valentino]

On Sun, 21 Apr 2024 13:07:41 +0100 "Rebecca N. Palmer" 
 wrote:
This bug is not *obviously* known to dask upstream, but their CI is 
failing and I haven't checked why.


It happens only in Python 3.12, not 3.11:
https://ci.debian.net/packages/d/dask/unstable/amd64/45013666/
and still doesn't happen in testing, but does happen in mostly-testing 
with 
src:python3-defaults,src:db5.3,src:keras,src:nodejs,src:openssl,src:python3-stdlib-extensions,src:python3.11,src:python3.12,src:readline,src:udisks2,src:viagee 
from unstable:

https://ci.debian.net/packages/d/dask/testing/amd64/45564690/

This suggests that the trigger may be the upgrade of Python itself 
(3.12.2-1 in testing -> 3.12.3-1 in unstable).


*Possibly* related items from the upstream Python changelog:
https://github.com/python/cpython/issues/101293
https://github.com/python/cpython/issues/117110


Apparently this issue seems to be related to:
https://github.com/dask/dask/pull/11035

regards
--
Antonio Valentino

Bug#1052772: isoquery: diff for NMU version 3.3.3-1.1

[Dr. Tobias Quathamer]

Am 27.04.24 um 14:08 schrieb Sebastian Ramacher:

Control: tags 1052772 + patch


Dear maintainer,

I've prepared an NMU for isoquery (versioned as 3.3.3-1.1). The diff
is attached to this message.

Regards.


Hi Sebastian,

thanks a lot for your NMU. Unfortunately, the fix from Steve is not 
correct, because the expected output of the test actually *is* French, 
so the failing test was indeed right.


The test did work previously, so something in the locale handling must 
have changed. I've now fixed this upstream and will prepare a new upload 
with the expected test output changed back to French. The package build 
now succeeds again with all tests passing.


Regards,
Tobias



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069960: passwordsafe: (regression) pwsafe crashes after supplying master password

[Manny]

Package: passwordsafe
Version: 1.16.0+dfsg-4
Severity: important
Tags: upstream
X-Debbugs-Cc: debbug.passwords...@sideload.33mail.com

After upgrading from Bullseye to Bookworm, pwsafe crashes after
supplying the master password. Terminal output shows:

===8<
pwsafe: ./src/core/PWSfileV1V2.cpp:391: size_t PWSfileV1V2::ReadCBC(unsigned 
char&, StringX&): Assertion `wcLen != 0' failed.
===8<

I was previously able to access my passwords with version
1.12.0+dfsg-1. So this is a regression.

It’s worth noting that my DB file was originally created by Bruce
Schneier’s “pwsafe” CLI tool. That package died for some reason and as
a refugee I was forced to adopt this GUI “passwordsafe”, which was
originally claimed to be compatible with Schneier’s CLI tool. However,
it was only compatible in terms of *reading* the DB. Edits result in
corruption (yikes!). So I was crippled with version 1.12.0+dfsg-1 but
at least I could /read/ my DB. Of course this crash in version
1.16.0+dfsg-4 is a total show stopper.


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

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

Versions of packages passwordsafe depends on:
ii  libc6 2.36-9+deb12u6
ii  libgcc-s1 12.2.0-14
ii  libmagic1 1:5.44-3
ii  libqrencode4  4.1.1-1
ii  libstdc++612.2.0-14
ii  libuuid1  2.38.1-5+deb12u1
ii  libwxbase3.0-0v5  3.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v5  3.0.5.1+dfsg-2
ii  libx11-6  2:1.8.4-2+deb12u2
ii  libxerces-c3.23.2.4+debian-1
ii  libxtst6  2:1.2.3-1.1
ii  libykpers-1-1 1.20.0-3
ii  passwordsafe-common   1.16.0+dfsg-4

Versions of packages passwordsafe recommends:
ii  xvkbd  4.1-2

passwordsafe suggests no packages.

-- no debconf information

Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding

[Helge Deller]

Source: libcbor
Version: 0.10.2-1.2
Tags: ftbfs
X-Debbugs-Cc: del...@debian.org

libcbor fails to build from source on the hppa and mips architectures.
Reason is, that a testcases which checks the binary representation
of NaN fails on those architectures, because they use a different binary
encoding of the bytes.
See the "encoding" section at https://en.wikipedia.org/wiki/NaN for details.

Failure except:
20: [ RUN  ] test_float
20: [  ERROR   ] --- difference at offset 2 0xffbf 0xffc0
20: difference at offset 3 0x 0x00
20: difference at offset 4 0x 0x00
20: 3 bytes of 0x1739c and 0xfa001b57 differ
20: [   LINE   ] --- ./test/float_ctrl_encoders_test.c:150: error: Failure!
20: [  FAILED  ] test_float
20: [ RUN  ] test_double
20: [  ERROR   ] --- difference at offset 2 0xfff7 0xfff8
20: difference at offset 3 0x 0x00
20: difference at offset 4 0x 0x00
20: difference at offset 5 0x 0x00
20: difference at offset 6 0x 0x00
20: difference at offset 7 0x 0x00
20: difference at offset 8 0x 0x00
20: 7 bytes of 0x1739c and 0xfa001b63 differ
20: [   LINE   ] --- ./test/float_ctrl_encoders_test.c:177: error: Failure!

The attached patch avoids this test on hppa and thus building libcbor succeeds.
I did not test the patch on mips yet.

Helge--- test/float_ctrl_encoders_test.c.org	2024-04-27 14:49:38.175261711 +
+++ test/float_ctrl_encoders_test.c	2024-04-27 14:59:12.825184338 +
@@ -9,6 +9,16 @@
 #include "assertions.h"
 #include "cbor.h"
 
+/* In NaNs generated by the PA-RISC and old MIPS processors, the
+ * signaling/quiet bit is zero if the NaN is quiet, and non-zero if the NaN is
+ * signaling. Thus the binary representation is different to other
+ * architectures. See encoding section at https://en.wikipedia.org/wiki/NaN */
+#if defined(__hppa__) || defined(__mips__)
+#define ARCH_WITH_STD_IEEE_754_NAN	0
+#else
+#define ARCH_WITH_STD_IEEE_754_NAN	1
+#endif
+
 unsigned char buffer[512];
 
 static void test_bools(void **_CBOR_UNUSED(_state)) {
@@ -147,13 +157,15 @@
   5);
 
   assert_size_equal(5, cbor_encode_single(NAN, buffer, 512));
-  assert_memory_equal(buffer, ((unsigned char[]){0xFA, 0x7F, 0xC0, 0x00, 0x00}),
+  if (ARCH_WITH_STD_IEEE_754_NAN)
+	  assert_memory_equal(buffer, ((unsigned char[]){0xFA, 0x7F, 0xC0, 0x00, 0x00}),
   5);
 
 #ifndef _WIN32
   // TODO: https://github.com/PJK/libcbor/issues/271
   assert_size_equal(5, cbor_encode_single(nanf("3"), buffer, 512));
-  assert_memory_equal(buffer, ((unsigned char[]){0xFA, 0x7F, 0xC0, 0x00, 0x03}),
+  if (ARCH_WITH_STD_IEEE_754_NAN)
+  	assert_memory_equal(buffer, ((unsigned char[]){0xFA, 0x7F, 0xC0, 0x00, 0x03}),
   5);
 #endif
 
@@ -174,7 +186,8 @@
   9);
 
   assert_size_equal(9, cbor_encode_double(nan(""), buffer, 512));
-  assert_memory_equal(
+  if (ARCH_WITH_STD_IEEE_754_NAN)
+assert_memory_equal(
   buffer,
   ((unsigned char[]){0xFB, 0x7F, 0xF8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}),
   9);
@@ -182,7 +195,8 @@
 #ifndef _WIN32
   // TODO: https://github.com/PJK/libcbor/issues/271
   assert_size_equal(9, cbor_encode_double(nan("3"), buffer, 512));
-  assert_memory_equal(
+  if (ARCH_WITH_STD_IEEE_754_NAN)
+assert_memory_equal(
   buffer,
   ((unsigned char[]){0xFB, 0x7F, 0xF8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03}),
   9);

Bug#1042865: planner: Help user guide is missing from Debian package

[Tommy Bollman]

Package: planner-doc
Version: 0.14.91-2
Followup-For: Bug #1042865
X-Debbugs-Cc: tommy.boll...@gmail.com

Dear Maintainer, Not only are the files missing, but the doc viewer that runs
internally in Gnome Planner
arent able to read the Docbook format of the planner.xml that was present from
Gnome Planners Homepage (planner-0.14.06.tar.xz
).

The problem is, that no images is loaded into the file, even when I have
download and installed with the correct rights into
/usr/share/gnome/help/planner/C and likewise/eu directories.

I have compared the file planner.xml with synaptic.xml, and I see that  images
are tried to be loaded with a "graph" tag in planner.xml, whereas images are
loaded with an "ImageObject" tag in Synaptic iirc.

My personal fix, has been to cd into the directory with planner.xml and execute
"yelp planner.xml", that works.


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

   * What led up to the situation?
I think what has led up to this situation was the ditching of autotools.
I think that there is a newer version of the docbook reader now, and that this
will lead to a rewrite of planner.xml.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 See above.
   * What was the outcome of this action?
   Success.
   * What outcome did you expect instead?
   That I had to do more to make it work.


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

Kernel: Linux 6.6.17-01102-gd3cec3c11146 (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)

planner-doc depends on no packages.

planner-doc recommends no packages.

Versions of packages planner-doc suggests:
ii  planner  0.14.91-2

-- no debconf information

Bug#1069958: 503 Server reports unexpected range

[Masked Witch]

Package: auto-apt-proxy
Version: 14.1

I've been using apt-cacher-ng on a central system on my network along
with auto-apt-proxy on all the other systems to help stay under my
internet service provider's data cap. It works great with all the
repositories I use it with except one. The central system updates with
https://apt.syncthing.net just fine, but when the other systems try to
update with http://apt.syncthing.net they get this error:

> 503  Server reports unexpected range [IP: 192.168.x.x 3142]

I thought maybe apt.syncthing.net implemented something to curb
potential person in the middle attacks, but they have no idea either:

https://github.com/syncthing/apt-web/issues/33

Bug#1069957: postfix: false syslog_name (misinfo) in the logs

[Manny]

Package: postfix
Version: 3.7.10-0+deb12u1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.post...@sideload.33mail.com

When an smtp command failed to send an outbound message, Postfix
neglected to correctly log the syslog_name as specified by this
option:

  -o syslog_name=postfix/smtptor

The logs are shown in bug report 1069949¹. This severely crippled
troubleshooting efforts because it misleads testers about what
actually executed. Notice in the logs of that bug report that a
well-behaved smtp program correctly yielded the “postfix/smtptor”
string.

In the failure scenario, the string “postfix/smtp” was logged, falsely
implying that the wrapper script was never called, yet it actually
logged output from the wrapper script. This resulting deception led
the bug chase down the wrong path.

I suspect whatever code applies the custom syslog_name is running
sequentially late and an initialised default value of “postfix/smtp”
is used as a placeholder.

A low-effort fix would be to change that initialisation to something
that’s at least non-misleading, such as:

* “postfix/TBD”
* “postfix/smtpAppTBD”
* “postfix/UNKNOWN”
* “postfix/UNSET”
* “postfix/UNSETsmtp”
* “postfix/DEADBEEF”
* “postfix/ifYouSeeThis,TellWietse”
* “postfix/thisWillNeverHappen”
* “postfix/youFoundAbug”

Any of those as an initialisation default would at least avoid
misinformation.

Going the extra mile would be fixing whatever caused the logger to act
before the custom syslog_name took effect.

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

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

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

Versions of packages postfix depends on:
ii  adduser3.134
ii  cpio   2.13+dfsg-7.1
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.22
ii  e2fsprogs  1.47.0-2
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u6
ii  libdb5.3   5.3.28+dfsg2-1
ii  libicu72   72.1-3
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.28+dfsg-10
ii  libssl33.0.11-1~deb12u2
ii  netbase6.4
ii  ssl-cert   1.1.2

Versions of packages postfix recommends:
ii  ca-certificates  20230311
ii  python3  3.11.2-1+b1

Versions of packages postfix suggests:
ii  emacs-gtk [mail-reader]1:28.2+1-15
ii  libsasl2-modules   2.1.28+dfsg-10
ii  mailutils [mail-reader]1:3.15-4
ii  neomutt [mail-reader]  20220429+dfsg1-4.1
pn  postfix-cdb
ii  postfix-doc3.7.10-0+deb12u1
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mta-sts-resolver   
pn  postfix-mysql  
ii  postfix-pcre   3.7.10-0+deb12u1
pn  postfix-pgsql  
pn  postfix-sqlite 
ii  procmail   3.22-27
ii  systemd-resolved [resolvconf]  252.22-1~deb12u1
ii  ufw0.36.2-1

-- Configuration Files:
/etc/postfix/post-install changed [not included]
/etc/postfix/postfix-files changed [not included]
/etc/postfix/postfix-script [Errno 2] No such file or directory: 
'/etc/postfix/postfix-script'

-- debconf information excluded

Bug#1069135: org-bullets: please consider switching to a more up-to-date upstream

[Aymeric Agon-Rambosson]

Hi Lev, Hi Nicholas,

If you are looking for replacements for org-bullets, there is also 
org-modern (https://github.com/minad/org-modern), from Daniel 
Mendler.


I've been using it happily for quite some time now.

Generally, Daniel Mendler's projects are very well implemented and 
maintained. I maintain 4 or 5 of his projects in Debian and I have 
very little work.


Best,

Aymeric

Le mercredi 17 avril 2024 à 13:02, Léon Lamberov 
 a écrit :



Hi Nicholas,

Вт 16 апр 2024 @ 18:13 Nicholas D Steeves :


Source: org-bullets
Version: 0.2.4-3
Severity: normal


I noticed some deprecation warnings in org-bullets' 
native-compilation log, so searched for an upstream fix.  What 
I found was that our current upstream source is a decade old:


  https://github.com/sabof/org-bullets

and that MELPA provides their users with a package from this 
fork, which has activity from four years ago:


  https://github.com/integral-dw/org-bullets

It looks like integral-dw's fork might now the defacto 
upstream, because sabof's project looks dead.  Maybe a PR/MR 
for some of those compilation warnings could be a useful way to 
test for a living and responsive upstream?


Thanks for your investigation!

As I can see, org-super-star-mode (also from integral-dw) has 
more
features than org-bullets and better support (last commit was in 
Jan
2023). So, I guess, we could update org-bullets to integral-dw's 
version
and also package org-super-star-mode, and then, probably, 
deprecate
org-bullets in favor of org-super-star-mode. What do you think 
of the

proposal?

[super-star] https://github.com/integral-dw/org-superstar-mode

Cheers!
Lev

Bug#1068598: spice-gtk: diff for NMU version 0.42-2.1

[Sebastian Ramacher]

Control: tags 1068598 + patch


Dear maintainer,

I've prepared an NMU for spice-gtk (versioned as 0.42-2.1). The diff
is attached to this message.

Regards.


-- 
Sebastian Ramacher
diff -Nru spice-gtk-0.42/debian/changelog spice-gtk-0.42/debian/changelog
--- spice-gtk-0.42/debian/changelog	2023-05-20 13:06:47.0 +0200
+++ spice-gtk-0.42/debian/changelog	2024-04-27 16:22:29.0 +0200
@@ -1,3 +1,11 @@
+spice-gtk (0.42-2.1) unstable; urgency=medium
+
+  * debian/control: Remove hard-coded dependencies on libusbredirhost1 and
+libusbredirparser1 from spice-client-gtk. libspice-client-glib-2.0-8
+properly links and depends on the correct libraries. (Closes: #1068598)
+
+ -- Sebastian Ramacher   Sat, 27 Apr 2024 16:22:29 +0200
+
 spice-gtk (0.42-2) unstable; urgency=medium
 
   * debian/control.in: Include version with remmina-plugin-spice Breaks.
diff -Nru spice-gtk-0.42/debian/control spice-gtk-0.42/debian/control
--- spice-gtk-0.42/debian/control	2023-05-20 13:06:47.0 +0200
+++ spice-gtk-0.42/debian/control	2024-04-27 16:20:22.0 +0200
@@ -54,8 +54,6 @@
 Architecture: any
 Depends: libspice-client-glib-2.0-8 (= ${binary:Version}),
  libspice-client-gtk-3.0-5 (= ${binary:Version}),
- libusbredirhost1 (>= 0.7.1),
- libusbredirparser1 (>= 0.7.1),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: Simple clients for interacting with SPICE servers
diff -Nru spice-gtk-0.42/debian/control.in spice-gtk-0.42/debian/control.in
--- spice-gtk-0.42/debian/control.in	2023-05-20 13:06:47.0 +0200
+++ spice-gtk-0.42/debian/control.in	2024-04-27 16:22:29.0 +0200
@@ -50,8 +50,6 @@
 Architecture: any
 Depends: libspice-client-glib-2.0-8 (= ${binary:Version}),
  libspice-client-gtk-3.0-5 (= ${binary:Version}),
- libusbredirhost1 (>= 0.7.1),
- libusbredirparser1 (>= 0.7.1),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: Simple clients for interacting with SPICE servers

Bug#1061435: lintian-brush ftbfs with updated pyo3 version

[Peter Green]

relaxing that in Cargo.toml to >= 0.19 lets the build succeed (and build 
with python3-defaults from experimental).


I was doing a test build of lintian brush to test I could build it
with the version of rust-distro-info I was preparing (now uploaded)
and ran into a couple of other issues.

Firstly there was a missing build-dependency on librust-pyo3-file-dev,
I added it.

Secondly in version 0.1.81, rust-breezyshim added an extra variant
"NoWhoami" to the "CommitError" enum, causing serveral match
statements to fail to build. I made a quick extension of the code
to accomodate this, but it could probablly do with some more
thinking about by someone with a better understanding of the code.

Finally I got test failures.


==
FAIL: fixer test: multiple-references for upstream-metadata-invalid
--
Traceback (most recent call last):
  File "/lintian-brush-0.152+nmu1/lintian_brush/tests/fixers.py", line 129, in 
runTest
raise AssertionError("unexpected output: %s" % diff.decode())
AssertionError: unexpected output: diff --no-dereference -x '*~' -ur 
/lintian-brush-0.152+nmu1/lintian_brush/tests/../../tests/upstream-metadata-invalid/multiple-references/out/debian/upstream/metadata
 /tmp/tmpbyzt2qq8/testdir/debian/upstre  am/metadata
--- 
/lintian-brush-0.152+nmu1/lintian_brush/tests/../../tests/upstream-metadata-invalid/multiple-references/out/debian/upstream/metadata
2023-10-28 00:41:32.0 +
+++ /tmp/tmpbyzt2qq8/testdir/debian/upstream/metadata   2024-04-27 
13:33:40.537269350 +
@@ -10,13 +10,15 @@
   Journal: LinuxUser
   Year: 2003
   Volume: 12
-  URL: 
https://www.linux-community.de/ausgaben/linuxuser/2003/12/woerterbuecher-und-textdateien-durchsuchen-mit-grafischem-frontend/
+  URL:
+
https://www.linux-community.de/ausgaben/linuxuser/2003/12/woerterbuecher-und-textdateien-durchsuchen-mit-grafischem-frontend/
 - Author: Michael Vogelbacher
   Title: Service und Informationen aus dem Netz
   Journal: LinuxUser
   Year: 2001
   Volume: 01
-  URL: 
https://www.linux-community.de/ausgaben/linuxuser/2001/01/service-und-informationen-aus-dem-netz/
+  URL: 
+https://www.linux-community.de/ausgaben/linuxuser/2001/01/service-und-informationen-aus-dem-netz/

 - Author: Redaktion pcmagazin
   Title: Ding - das Linuxlexikon
   Journal: PC Magazin



==
FAIL: fixer test: from-upstream-metadata for copyright-missing-upstream-info
--
Traceback (most recent call last):
  File "/lintian-brush-0.152+nmu1/lintian_brush/tests/fixers.py", line 108, in 
runTest
self.assertEqual(p.returncode, 0)
AssertionError: 1 != 0

==
FAIL: fixer test: meta.yml for upstream-metadata-file
--
Traceback (most recent call last):
  File "/lintian-brush-0.152+nmu1/lintian_brush/tests/fixers.py", line 108, in 
runTest
self.assertEqual(p.returncode, 0)
AssertionError: 1 != 0

==
FAIL: fixer test: cran for debian-watch-file-is-missing
--
Traceback (most recent call last):
  File "/lintian-brush-0.152+nmu1/lintian_brush/tests/fixers.py", line 108, in 
runTest
self.assertEqual(p.returncode, 0)
AssertionError: 1 != 0

--
Ran 796 tests in 80.565s

FAILED (failures=4, expected failures=1)


A debdiff is attached, which fixes the compile errors but not the test failures.
diff -Nru lintian-brush-0.152/Cargo.toml lintian-brush-0.152+nmu1/Cargo.toml
--- lintian-brush-0.152/Cargo.toml  2023-10-28 00:41:32.0 +
+++ lintian-brush-0.152+nmu1/Cargo.toml 2024-04-27 11:28:42.0 +
@@ -40,7 +40,7 @@
 
 [workspace.dependencies]
 breezyshim = "0.1.34"
-pyo3 = "0.19"
+pyo3 = ">=0.19"
 debversion = ">=0.1.8"
 serde_yaml = ">=0.8"
 reqwest = "0.11"
diff -Nru lintian-brush-0.152/debian/changelog 
lintian-brush-0.152+nmu1/debian/changelog
--- lintian-brush-0.152/debian/changelog2023-10-28 00:41:32.0 
+
+++ lintian-brush-0.152+nmu1/debian/changelog   2024-04-27 11:28:42.0 
+
@@ -1,3 +1,12 @@
+lintian-brush (0.152+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on pyo3 crate (Closes: #106435)
+  * Add missing build-dependency on librust-pyo3-file-dev
+  * Fix build with newer versions of rust-breezyshim.
+
+ -- Peter Michael Green   Sat, 27 Apr 2024 11:28:42 +
+
 lintian-brush (0.152) unstable; urgency=medium
 
   * Fix compatibility with newer rust crates. Closes: #1054839
diff -Nru 

Bug#1069956: postfix: logs flooded as Postfix rapidly reattempts smtp too frequently (240 times per second)

[Manny]

Package: postfix
Version: 3.7.10-0+deb12u1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.post...@sideload.33mail.com

When an outbound smtp command fails, Postfix retries the command
*hundreds* of times per second. This was discovered in the course of
troubleshooting bug 1069949:

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

An smtp wrapper script was created which was impacted by a
Postfix-unrelated defect. The defect caused an instant failure of the
smtp call. The wrapper script logged its own actions in a separate
file. Each line of the wrapper script log began with a timestamp like
this:

  2024-04-27T13:10:30

That exact same timestamp appeared on ~1200 lines in the log file
before advancing to the next second. Each execution yields five lines,
so the smpt program was apparently called ~240 times per second on
very old hardware. A modern machine would have run many times more;
probably thousands of times per second.

Strangely, /var/log/mail.log only showed output that was timestamped
once per second. That is still excessive, but it also raises the
question: why is there just 1 line in /var/log/mail.log for every 240
smtp executions?  Is result output being lost, or is the logger doing
something extra smart and saying “the hundreds of reattempts in the
past second all have the same error output, thus we only need to print
it once per second”?

Either way, this could use improvement. Retrying outbound smtp 240
times per second is crazy. Some tuning parameters are provided¹ but
they seem to miss this egress smtp scenario. Ideally the frequency of
attempts should be non-linear. A sensible schedule would be something
like this:

1st second: 2 attempts
2nd second: 1 attempt
3rd second: 1 attempt
4th second: 0 attempts
5th second: 1 attempt
10th second: 1 attempt

Then try once again 20 seconds later, etc, until perhaps going linear
on a once per 10 min basis.

Assuming the Postfix logger is cleverly consolidating repetitious
error messages, that’s great!  But it should not conceal the count
from the user. This line:

  2024-04-25T13:10:28.533021+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented

would be written better as:

  2024-04-25T13:10:28.533021+02:00 MannysHost postfix/smtp[*] (240 identical 
output instances) → fatal: socket: Function not implemented

There is also some confusion by the way the docs are written. The
section title “Slowing down SMTP clients that make many errors” is
ambiguous and implies the case above (the need to control egress SMTP
client transmissions). But it’s actually talking about a control on
the smtpd server to limit *ingress* traffic from external SMTP
clients.

¹ file:///usr/share/doc/postfix/html/TUNING_README.html#slowdown


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

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

Versions of packages postfix depends on:
ii  adduser3.134
ii  cpio   2.13+dfsg-7.1
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.22
ii  e2fsprogs  1.47.0-2
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u6
ii  libdb5.3   5.3.28+dfsg2-1
ii  libicu72   72.1-3
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.28+dfsg-10
ii  libssl33.0.11-1~deb12u2
ii  netbase6.4
ii  ssl-cert   1.1.2

Versions of packages postfix recommends:
ii  ca-certificates  20230311
ii  python3  3.11.2-1+b1

Versions of packages postfix suggests:
ii  emacs-gtk [mail-reader]1:28.2+1-15
ii  libsasl2-modules   2.1.28+dfsg-10
ii  mailutils [mail-reader]1:3.15-4
ii  neomutt [mail-reader]  20220429+dfsg1-4.1
pn  postfix-cdb
ii  postfix-doc3.7.10-0+deb12u1
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mta-sts-resolver   
pn  postfix-mysql  
ii  postfix-pcre   3.7.10-0+deb12u1
pn  postfix-pgsql  
pn  postfix-sqlite 
ii  procmail   3.22-27
ii  systemd-resolved [resolvconf]  252.22-1~deb12u1
ii  ufw0.36.2-1

-- Configuration Files:
/etc/postfix/post-install changed [not included]
/etc/postfix/postfix-files changed [not included]
/etc/postfix/postfix-script [Errno 2] No such file or directory: 
'/etc/postfix/postfix-script'

-- debconf information:
  postfix/mydomain_warning:
  postfix/recipient_delim: +
  

Bug#1069952: upgrade from 2.78.4-1 to 2.78.4-7 breaks over 200 packages in testing distribution

[Jeremy Bícha]

On Sat, Apr 27, 2024 at 9:33 AM js  wrote:
>Wanted to see the effect of upgrading libglib2.0-dev by a minor
>version number, 2.78.4-1 to 2.78.4-7 and that would have caused over
>200 packages to break in the **testing** distribution.

Try
sudo apt dist-upgrade

It is not a "minor" update. It is part of the t64 transition which is
a huge change.

Thank you,
Jeremy Bícha

Bug#789401: Proposed patch to solve the issue.

[Thorsten Glaser]

Hi Georgios,

why not just ensure the parent directory of the chroot is not
traversable for just any normal user?

That would allow preserving /tmp/buildd as build place as well
as retaining stuff under /run which packages create and which
is, in practice, often needed for chroots where initscripts are
not run.

In addition, I often do use the access to the /tmp in the chroot
for debugging and bootstrapping, so maybe create a new system
group, chown 0:_pbuilder /var/cache/pbuilder/build; chmod 0750
that directory, and good is? (Untested.)

Then, I could add my user to that group and continue doing so.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1069955: nautilus: Incomplete Italian translation

[Andrea Bolognani]

Package: nautilus
Version: 43.2-1
Severity: minor

Hi,

some fairly prominent actions (e.g. New Folder, Open With) show up in
English when running with an Italian locale.

I would like to see that addressed in a future bookworm update.

Actually translating the labels will be fairly quick, but I'm not
sure what the process around getting updated translation into the
Debian package looks like. Maybe the translations have already been
added upstream, and it's just a matter of backporting the relevant
changes? Or they have to be contributed there first. If you could
provide some pointers, I'll look into it.

Thanks in advance.


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

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
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 nautilus depends on:
ii  bubblewrap  0.8.0-2
ii  desktop-file-utils  0.26-1
ii  gsettings-desktop-schemas   43.0-1
ii  gvfs1.50.3-1
ii  libadwaita-1-0  1.2.2-1
ii  libc6   2.36-9+deb12u6
ii  libcairo2   1.16.0-7
ii  libcloudproviders0  0.3.1-2
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libgexiv2-2 0.14.0-1+b1
ii  libglib2.0-02.74.6-2
ii  libglib2.0-data 2.74.6-2
ii  libgnome-autoar-0-0 0.4.3-1
ii  libgnome-desktop-4-243.2-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3+deb12u1
ii  libgstreamer1.0-0   1.22.0-2
ii  libgtk-4-1  4.8.3+ds-2+deb12u1
ii  libnautilus-extension4  43.2-1
ii  libpango-1.0-0  1.50.12+ds-1
ii  libportal-gtk4-10.6-4
ii  libportal1  0.6-4
ii  libselinux1 3.4-1+b6
ii  libtracker-sparql-3.0-0 3.4.2-1
ii  nautilus-data   43.2-1
ii  shared-mime-info2.2-1
ii  tracker 3.4.2-1
ii  tracker-extract 3.4.3-1
ii  tracker-miner-fs3.4.3-1

Versions of packages nautilus recommends:
ii  gnome-sushi   43.0-2
ii  gvfs-backends 1.50.3-1
ii  libgdk-pixbuf2.0-bin  2.42.10+dfsg-1+b1
ii  librsvg2-common   2.54.7+dfsg-1~deb12u1

Versions of packages nautilus suggests:
ii  eog 43.2-1
ii  evince [pdf-viewer] 43.1-2+b1
pn  nautilus-extension-brasero  
pn  nautilus-sendto 
ii  totem   43.0-2
ii  xdg-user-dirs   0.18-1

-- no debconf information

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1069954: python-requests-mock: please package version 1.12.1 & remove python3-six dependency

[Alexandre Detiste]

Source: python-requests-mock
Version: 1.11.0-1
Severity: normal

Dear Maintainer,

python3-six usage has been removed in last release

https://github.com/jamielennox/requests-mock/compare/1.11.0...1.12.1

Greetings

Bug#864522: bmusb: please add Vcs-* headers to debian/control

[Petter Reinholdtsen]

[Holger Levsen 2017-06-09]
> please add the following headers to the source stanza in debian/control:

I agree, it would be great with a pointer to the current git repository.

Steinar, something you can have a look at?
-- 
Happy hacking
Petter Reinholdtsen

Bug#1069953: libgstreamer-plugins-bad1.0-dev: not installable on i386

[Sebastian Ramacher]

Package: libgstreamer-plugins-bad1.0-dev
Version: 1.24.2-3
Severity: grave
X-Debbugs-Cc: sramac...@debian.org

$ apt install --no-install-recommends libgstreamer-plugins-bad1.0-dev
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Unsatisfied dependencies:
 libgstreamer-plugins-bad1.0-dev : Depends: libgstreamer-opencv1.0-0 (= 
1.24.2-3) but it is not going to be installed


This issues makes at least cheese BD-Uninstallable on i386

Cheers
-- 
Sebastian Ramacher

Bug#1069952: upgrade from 2.78.4-1 to 2.78.4-7 breaks over 200 packages in testing distribution

[js]

Package: libglib2.0-dev
Version: 2.78.4-1
Severity: important

Dear Maintainer,

==

   * What led up to the situation?
   Wanted to see the effect of upgrading libglib2.0-dev by a minor
   version number, 2.78.4-1 to 2.78.4-7 and that would have caused over
   200 packages to break in the **testing** distribution.

   My understanding is:
   1. minor version changes like -1 to -7 reflect only minor packaging
   changes, not something as disruptive as breaking so many packages
   2. testing distribution is not supposed have broken packages;
   packages should transition from unstable to testing only after
   dependencies are in place.

   It seems adding this minor version change into testing made this
   version of the library not usable because of all the other packages
   that have to be removed because of it. The change would have been
   better left in unstable until new versions of these packages were
   available so they could all move to testing in a non-disruptive way.

 The following packages will be REMOVED:
  anjuta atril balsa baresip-gstreamer bijiben blender brasero brasero-cdrkit 
cheese claws-mail-extra-plugins claws-mail-fancy-plugin cysignals-tools devhelp 
dleyna-renderer
  dleyna-server elisa empathy ephoto evince evolution evolution-data-server 
evolution-plugin-pstimport evolution-plugin-spamassassin evolution-plugins 
font-manager gdb
  gir1.2-clutter-gst-3.0 gir1.2-evince-3.0 gir1.2-gst-plugins-bad-1.0 
gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gir1.2-rb-3.0 gir1.2-totem-1.0 
gir1.2-webkit2-4.0
  gir1.2-webkit2-4.1 glade gnome-contacts gnome-flashback 
gnome-getting-started-docs gnome-music gnome-online-miners gnome-packagekit 
gnome-photos gnome-session-flashback
  gnome-shell gnome-software gnome-software-plugin-flatpak gnome-sound-recorder 
gnome-sushi gnome-user-docs gnome-user-guide gnome-video-effects gnucash 
goldendict
  google-earth-pro-stable grilo-plugins-0.3 gst123 gstreamer1.0-alsa 
gstreamer1.0-clutter-3.0 gstreamer1.0-gl gstreamer1.0-gtk3 gstreamer1.0-libav 
gstreamer1.0-nice
  gstreamer1.0-packagekit gstreamer1.0-pipewire gstreamer1.0-plugins-bad 
gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly 
gstreamer1.0-pulseaudio
  gstreamer1.0-tools gstreamer1.0-x gthumb handbrake jupyter jupyter-console 
jupyter-notebook jupyter-qtconsole kdenlive kdevelop kdevelop-python 
kdevelop510-libs kdevelop512-libs
  kdevelop54-libs kdevelop55-libs kdevelop56-libs kmymoney knowthelist 
libatrilview3 libbrasero-media3-1 libcheese-gtk25 libcheese8 
libclutter-gst-3.0-0 libdebuginfod1
  libdevhelp-3-6 libdmapsharing-3.0-2 libdmapsharing-4.0-3 libdw-dev libdw1 
libedataserverui-1.2-4 libelementary1 libelf1 libemotion1 libevas-loaders 
libevolution libevview3-3
  libfarstream-0.2-5 libfolks-eds26 libgladeui-2-13 libglib2.0-0 
libgstreamer-gl1.0-0 libgstreamer-plugins-bad1.0-0 
libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev
  libgstreamer1.0-0 libgstreamer1.0-dev libgupnp-dlna-2.0-4 libkf5webkit5 
libopencv-videoio4.5d libopencv-videoio406 libopenimageio2.4 libpurple-bin 
libpurple0
  libqt5multimedia5-plugins libqt5multimediagsttools5 libqt5webkit5 
libqt6multimedia6 libreoffice libreoffice-base libreoffice-calc 
libreoffice-core libreoffice-draw
  libreoffice-evolution libreoffice-gnome libreoffice-gtk3 libreoffice-impress 
libreoffice-librelogo libreoffice-lightproof-en libreoffice-math 
libreoffice-nlpsolver
  libreoffice-report-builder libreoffice-report-builder-bin 
libreoffice-texmaths libreoffice-wiki-publisher libreoffice-writer 
libreoffice-writer2latex librhythmbox-core10
  librpmbuild8 librygel-renderer-gst-2.6-2 libtelepathy-farstream3 
libtorch-test libtorch2.0 libtotem0 libwebkit2gtk-4.0-37 libwebkit2gtk-4.1-0 
libwxgtk-media3.0-gtk3-0v5
  libwxgtk-media3.2-1 libwxgtk-webview3.0-gtk3-0v5 libyelp0 liferea midori 
mkvtoolnix-gui nautilus packagekit packagekit-tools parole 
phonon4qt5-backend-gstreamer pidgin
  pidgin-plugin-pack pulseaudio python3-apptools python3-debugpy 
python3-envisage python3-guidata python3-ipykernel python3-jupyter-console 
python3-notebook python3-pweave
  python3-pydevd python3-pyface python3-pyqt5.qtwebkit python3-qdarkstyle 
python3-qtawesome python3-qtconsole python3-qtpy python3-qwt python3-spyder 
python3-spyder-kernels
  python3-spyder-unittest python3-torch python3-traitsui python3-wxgtk-media4.0 
qml-module-qtwebkit qt5-assistant qtmultimedia5-dev qttools5-dev-tools 
quodlibet rednotebook
  rhythmbox rhythmbox-plugin-cdrecorder rhythmbox-plugins rkward rust-gdb 
shotwell software-properties-common software-properties-gtk sound-juicer spyder 
telepathy-haze totem
  totem-plugins tracker-extract tracker-miner-fs tumbler vitables webcamoid 
webcamoid-plugins wireshark wkhtmltopdf xfburn xfce4-goodies yelp

Bug#1069951: ITP: tcl-ooxml -- Read and Write Office Open XML "XLSX" since Excel 2007

[Massimo Manghi]

Package: wnpp
Severity: wishlist
Owner: Massimo Manghi 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: tcl-ooxml
  Version : 1.8
  Upstream Contact: Alexander Schöpe 
* URL : https://fossil.sowaswie.de/ooxml/
* License : BSD-3
  Programming Lang: Tcl
  Description : Read and Write Office Open XML "XLSX" since Excel 2007

This package contains several commands to edit Excel files. The three most 
important are the following three:
  * Importing Excel files into a Tcl array with ::ooxml::xl_read, 
  * Exporting Tcl data to an Excel file with ::ooxml::xl_write 
  * Exporting Tcl tablelist to an Excel file with ::ooxml::tablelist_to_xl.

The relevance of this tool is self-evident, being documents produced with
the Office Open XML format one of the more important ways of data interchange 
with
the non-free and widely used applications such as MS-Excel 

Bug#595696: Bug#594817: console-setup should configure the width of the console

[Samuel Thibault]

Samuel Thibault, le mar. 01 sept. 2015 19:40:30 +0200, a ecrit:
> Anton Zinoviev, le Tue 01 Sep 2015 20:31:33 +0300, a écrit :
> > On Tue, Aug 25, 2015 at 10:20:46PM +0200, Samuel Thibault wrote:
> > > Samuel Thibault, le Sun 29 Aug 2010 21:08:05 +0200, a écrit :
> > > >   We could even imagine to
> > > >   rasterize a vector font on the fly for very big sizes.
> > > 
> > > otf2bdf and bdf2psf could be used for that, for instance if the user
> > > specifies the width (which will be the most probable use, people usually
> > 
> > I am afraid of such automatic conversion.  There are too many 
> > combinations which can easily lead to many undiscovered bugs... I'd 
> > prefer if we use otf2bdf and bdf2psf manually in order to add a few new 
> > fonts in the source package of console-setup.
> 
> Right, that can be enough, indeed. We can add more as screen get more
> dpi (and make it simple to change in the package build for users to
> build them easily if they need)

I just did that :)

Up to 64b width, the maximum width that will be allowed by linux 6.9.

Samuel

Bug#1058433: kexec-tools: diff for NMU version 1:2.0.27-1.1

[Sebastian Ramacher]

Control: tags 1058433 + patch


Dear maintainer,

I've prepared an NMU for kexec-tools (versioned as 1:2.0.27-1.1). The diff
is attached to this message.

Regards.


-- 
Sebastian Ramacher
diff -Nru kexec-tools-2.0.27/debian/changelog kexec-tools-2.0.27/debian/changelog
--- kexec-tools-2.0.27/debian/changelog	2023-10-05 00:17:28.0 +0200
+++ kexec-tools-2.0.27/debian/changelog	2024-04-27 14:49:56.0 +0200
@@ -1,3 +1,10 @@
+kexec-tools (1:2.0.27-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch to fix build with binutils 2.41 (Closes: #1058433)
+
+ -- Sebastian Ramacher   Sat, 27 Apr 2024 14:49:56 +0200
+
 kexec-tools (1:2.0.27-1) unstable; urgency=medium
 
   * New upstream release (Closes: #1051962)
diff -Nru kexec-tools-2.0.27/debian/patches/328de8e00e298f00d7ba6b25dc3950147e9642e6.patch kexec-tools-2.0.27/debian/patches/328de8e00e298f00d7ba6b25dc3950147e9642e6.patch
--- kexec-tools-2.0.27/debian/patches/328de8e00e298f00d7ba6b25dc3950147e9642e6.patch	1970-01-01 01:00:00.0 +0100
+++ kexec-tools-2.0.27/debian/patches/328de8e00e298f00d7ba6b25dc3950147e9642e6.patch	2024-04-27 14:48:49.0 +0200
@@ -0,0 +1,92 @@
+From 328de8e00e298f00d7ba6b25dc3950147e9642e6 Mon Sep 17 00:00:00 2001
+From: Michel Lind 
+Date: Tue, 30 Jan 2024 04:14:31 -0600
+Subject: Fix building on x86_64 with binutils 2.41
+
+Newer versions of the GNU assembler (observed with binutils 2.41) will
+complain about the ".arch i386" in files assembled with "as --64",
+with the message "Error: 64bit mode not supported on 'i386'".
+
+Fix by moving ".arch i386" below the relevant ".code32" directive, so
+that the assembler is no longer expecting 64-bit instructions to be used
+by the time that the ".arch i386" directive is encountered.
+
+Based on similar iPXE fix:
+https://github.com/ipxe/ipxe/commit/6ca597eee
+
+Signed-off-by: Michel Lind 
+Signed-off-by: Simon Horman 
+---
+ purgatory/arch/i386/entry32-16-debug.S | 2 +-
+ purgatory/arch/i386/entry32-16.S   | 2 +-
+ purgatory/arch/i386/entry32.S  | 2 +-
+ purgatory/arch/i386/setup-x86.S| 2 +-
+ 4 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/purgatory/arch/i386/entry32-16-debug.S b/purgatory/arch/i386/entry32-16-debug.S
+index 5167944d..12e11649 100644
+--- a/purgatory/arch/i386/entry32-16-debug.S
 b/purgatory/arch/i386/entry32-16-debug.S
+@@ -25,10 +25,10 @@
+ 	.globl entry16_debug_pre32
+ 	.globl entry16_debug_first32
+ 	.globl entry16_debug_old_first32
+-	.arch i386
+ 	.balign 16
+ entry16_debug:
+ 	.code32
++	.arch i386
+ 	/* Compute where I am running at (assumes esp valid) */
+ 	call	1f
+ 1:	popl	%ebx
+diff --git a/purgatory/arch/i386/entry32-16.S b/purgatory/arch/i386/entry32-16.S
+index c051aab0..eace0958 100644
+--- a/purgatory/arch/i386/entry32-16.S
 b/purgatory/arch/i386/entry32-16.S
+@@ -20,10 +20,10 @@
+ #undef i386	
+ 	.text
+ 	.globl entry16, entry16_regs
+-	.arch i386
+ 	.balign 16
+ entry16:
+ 	.code32
++	.arch i386
+ 	/* Compute where I am running at (assumes esp valid) */
+ 	call	1f
+ 1:	popl	%ebx
+diff --git a/purgatory/arch/i386/entry32.S b/purgatory/arch/i386/entry32.S
+index f7a494f1..8ce9e316 100644
+--- a/purgatory/arch/i386/entry32.S
 b/purgatory/arch/i386/entry32.S
+@@ -20,10 +20,10 @@
+ #undef i386
+ 
+ 	.text
+-	.arch	i386
+ 	.globl entry32, entry32_regs
+ entry32:
+ 	.code32
++	.arch	i386
+ 
+ 	/* Setup a gdt that should that is generally usefully */
+ 	lgdt	%cs:gdt
+diff --git a/purgatory/arch/i386/setup-x86.S b/purgatory/arch/i386/setup-x86.S
+index 201bb2cb..a212eed4 100644
+--- a/purgatory/arch/i386/setup-x86.S
 b/purgatory/arch/i386/setup-x86.S
+@@ -21,10 +21,10 @@
+ #undef i386
+ 
+ 	.text
+-	.arch	i386
+ 	.globl purgatory_start
+ purgatory_start:
+ 	.code32
++	.arch	i386
+ 
+ 	/* Load a gdt so I know what the segment registers are */
+ 	lgdt	%cs:gdt
+-- 
+cgit 1.2.3-korg
+
diff -Nru kexec-tools-2.0.27/debian/patches/series kexec-tools-2.0.27/debian/patches/series
--- kexec-tools-2.0.27/debian/patches/series	2023-09-17 19:14:33.0 +0200
+++ kexec-tools-2.0.27/debian/patches/series	2024-04-27 14:49:01.0 +0200
@@ -7,3 +7,4 @@
 powerpcspe_support.patch
 vmcore-dmesg_man_page_fix.patch
 systemd-support.patch
+328de8e00e298f00d7ba6b25dc3950147e9642e6.patch

Bug#1069950: python-pymemcache: please remove extraneous python3-mock build dependency

[Alexandre Detiste]

Source: python-pymemcache
Version: 4.0.0-6
Severity: normal

Dear Maintainer,

Since the times of #795565, upstream has now switched
to the newer unittest.mock.

Greetings

tchet@quieter:/tmp/python-pymemcache$ grep mock -r | grep -e debian -e import
debian/changelog:  * Added missing python{3,}-mock depends (Closes: #795565).
debian/control: python3-mock,
pymemcache/test/test_client.py:from unittest import mock
pymemcache/test/test_client_hash.py:from unittest import mock
pymemcache/test/test_client_retry.py:from unittest import mock
tchet@quieter:/tmp/python-pymemcache$

Bug#1069949: (regression) fatal: socket: Function not implemented

[Manny]

Package: torsocks
Version: 2.4.0-1
Severity: important
Tags: upstream
X-Debbugs-Cc: debbug.torso...@sideload.33mail.com

After upgrading from Bullseye to Bookworm, this is what happens in the
logs when sending a Tor-routed message:

(/var/log/mail.log)
===8<
2024-04-25T13:10:25.165542+02:00 MannysHost postfix/smtpd[*]: connect from 
localhost[127.0.0.1]
2024-04-25T13:10:25.186729+02:00 MannysHost postfix/smtpd[*]: 2D6EFE313A: 
client=localhost[127.0.0.1]
2024-04-25T13:10:25.232021+02:00 MannysHost postfix/cleanup[*]: 2D6EFE313A: 
message-id=
2024-04-25T13:10:25.236765+02:00 MannysHost postfix/qmgr[*]: 2D6EFE313A: 
from=, size=1181, nrcpt=1 (queue active)
2024-04-25T13:10:25.236875+02:00 MannysHost postfix/smtpd[*]: disconnect from 
localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
2024-04-25T13:10:25.298945+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:26.357045+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:27.444922+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:28.533021+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:29.636915+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:30.694143+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:31.808365+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:32.921259+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:34.026594+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:35.140735+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:36.234895+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:37.352079+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:38.440755+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
2024-04-25T13:10:39.549476+02:00 MannysHost postfix/smtp[*]: fatal: socket: 
Function not implemented
…
===8<

This is what the log looked like in Bullseye just before the upgrade,
when sending over Tor still worked correctly:

(/var/log/mail.log)
===8<
Apr 24 09:37:17 MannysHost postfix/postfix-script[2130]: refreshing the Postfix 
mail system
Apr 24 09:37:17 MannysHost postfix/master[1026]: reload -- version 3.5.24, 
configuration /etc/postfix
Apr 24 09:37:17 MannysHost postfix/postfix-script[2168]: refreshing the Postfix 
mail system
Apr 24 09:37:17 MannysHost postfix/master[1026]: reload -- version 3.5.24, 
configuration /etc/postfix
Apr 24 12:32:42 MannysHost postfix/submission/smtpd[27946]: connect from 
localhost[127.0.0.1]
Apr 24 12:32:42 MannysHost postfix/submission/smtpd[27946]: 3C344E3262: 
client=localhost[127.0.0.1]
Apr 24 12:32:42 MannysHost postfix/submission/cleanup/cleanup[27949]: 
3C344E3262: message-id=
Apr 24 12:32:42 MannysHost postfix/submission/smtpd[27946]: disconnect from 
localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
Apr 24 12:32:42 MannysHost postfix/qmgr[2173]: 3C344E3262: 
from=, size=1126, nrcpt=1 (queue active)
Apr 24 12:32:50 MannysHost postfix/smtptor/smtp[27956]: 3C344E3262: 
to=, relay=recipient.mx.server[1.2.3.4]:587, delay=8.1, 
delays=0.07/0.13/5.8/2.1, dsn=2.0.0, status=sent (250 OK id=yadayada)
===8<

Sending over clearnet has no issues in any version. It’s only when a
message must go over the Tor network that there is a problem.

The configuration consists of the following:

(/etc/postfix/master.cf)
===8<
# The syslog_name option is not needed. It can be set to
# anything. It’s just to add distinction in mail.log between clearnet
# and Tor mail (otherwise both kinds of transmission are prefixed as
# “postfix/smtp”).
#
smtptor  unix  -   -   n   -   -   smtp_tor
  -o smtp_address_preference=ipv4
  -o smtp_dns_support_level=disabled
  -o smtp_tls_security_level=none
  -o debug_peer_level=2
  -o syslog_name=postfix/smtptor
===8<

(/usr/lib/postfix/sbin/smtp_tor)
===8<
!/bin/bash

typeset -r dir_cmd=$(/usr/sbin/postconf -h command_directory)
typeset -r exec_smtp=$("$dir_cmd"/postconf -h daemon_directory)/smtp

setx_output()
{
if [[ $1 ]]; then
exec 4>>"$1"
BASH_XTRACEFD=4
PS4='\D{+%F}T\t $LINENO: '
set -x
else
set +x
#BASH_XTRACEFD=2
exec 4>&-
fi
}
setx_output /var/log/mail_${0##*/}.log

torsocks "$exec_smtp" "$@"

setx_output
===8<

To setup 

Bug#1069948: python3-pydevd: cannot be installed on Debian testing, unsatisfied dependency on gdb

[Amr Ibrahim]

Package: python3-pydevd
Version: 2.10.0+ds-10
Severity: grave
Justification: renders package unusable

Dear Maintainer,

On an up-to-date Debian testing, python3-pydevd cannot be installed because of
an unsatisfied dependency on gdb.

Best,
Amr


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

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

Versions of packages python3-pydevd depends on:
pn  gdb   
ii  libc6 2.37-18
ii  libgcc-s1 14-20240330-1
ii  libstdc++614-20240330-1
ii  python3   3.11.6-1
pn  python3-bytecode  
pn  python3-coverage  

python3-pydevd recommends no packages.

Versions of packages python3-pydevd suggests:
pn  pydevd  

Bug#1032615: please consider pcp over dool as replacement

[equinox]

Hi

On Mon, 24 Apr 2023 03:01:03 +0200 Marc Lehmann  wrote:

Please do NOT consider dool as replacement for dstat, but pcp instead.


Sorry but calling pcp a better drop-in replacement for dstat is a bit of
a stretch. On a fresh minimal installation of debian/testing pcp starts
several daemons which have several open TCP ports.

Just compare this:

without pcp:


# pstree
systemd-+-agetty
|-cron
|-dbus-daemon
|-haveged
|-sshd---sshd---zsh---pstree
|-systemd---(sd-pam)
|-systemd-journal
|-systemd-logind
`-systemd-udevd


with pcp (installed via `apt-get install dstat`):


# pstree
systemd-+-agetty
|-cron
|-dbus-daemon
|-haveged
|-pmcd---pmdaroot-+-pmdakvm
| |-pmdalinux
| |-pmdaproc
| `-pmdaxfs
|-pmlogger
|-pmpause
|-sshd---sshd---zsh---pstree
|-systemd---(sd-pam)
|-systemd-journal
|-systemd-logind
`-systemd-udevd


This is already quite some stuff that is running that most of the time i don't
need. Even more problemantic ist this:

without pcp:


# ss -tulnp
Netid  State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
tcpLISTEN  0   128   0.0.0.0:22 0.0.0.0:*  
users:(("sshd",pid=672,fd=3))
tcpLISTEN  0   128  [::]:22[::]:*  
users:(("sshd",pid=672,fd=4))



with pcp:


# ss -tulnp
Netid  State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
tcpLISTEN  0   5 0.0.0.0:43300.0.0.0:*  
users:(("pmlogger",pid=2315,fd=7))
tcpLISTEN  0   128   0.0.0.0:22  0.0.0.0:*  
users:(("sshd",pid=672,fd=3))
tcpLISTEN  0   5 0.0.0.0:44321   0.0.0.0:*  
users:(("pmcd",pid=1976,fd=0))
tcpLISTEN  0   5[::]:4330   [::]:*  
users:(("pmlogger",pid=2315,fd=8))
tcpLISTEN  0   128  [::]:22 [::]:*  
users:(("sshd",pid=672,fd=4))
tcpLISTEN  0   5[::]:44321  [::]:*  
users:(("pmcd",pid=1976,fd=3))


Why are all this ports open all the time? This is NOT what i would expect when
i install something that always has been a simple command-line python script.

Don't get me wrong there might be a good reason why pcp works this way - most
likely because it has a wider scope with different use-cases. But calling this
a drop-in replacement for a tool that only does stuff when i really need it and
is otherweise just taking up a little bit of disk-space is imho dangerous 
because
it dramatically increases the remote attack-surface - at least in the default
install.


The reasons are not only that pcp seems to be much more actively maintained,
it is also vastly more compatible to dstat than dool. For example, dool uses
an unreadable color palette (e.g. black text on black background) by
default, and uses a very different default output format.


I haven't really used dool or pcp-dstat too much but at the momemt i have
a hard time understanding why i should worry about sligtly different output
coloring and ignore the potential security issues that come with long-running
daemons that, at least in the default install, are reachable from everywhere.

Again, there might be a good use-case for running pcp on your system. This is
not what i argue against. But at the moment, if i install the package `datat`
on debian testing, i get something i would never expect.

regards
 christian

Bug#1069947: RM: wesnoth-1.16 -- ROM; superseded by wesnoth-1.18

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org, rho...@debian.org,
p...@pehjota.net
Control: affects -1 + src:wesnoth-1.16

Please remove wesnoth-1.16 now that wesnoth-1.18 has landed in sid. Thanks!

Regards,
Vincent

Bug#1052772: isoquery: diff for NMU version 3.3.3-1.1

[Sebastian Ramacher]

Control: tags 1052772 + patch


Dear maintainer,

I've prepared an NMU for isoquery (versioned as 3.3.3-1.1). The diff
is attached to this message.

Regards.


-- 
Sebastian Ramacher
diff -Nru isoquery-3.3.3/debian/changelog isoquery-3.3.3/debian/changelog
--- isoquery-3.3.3/debian/changelog	2023-02-28 12:15:46.0 +0100
+++ isoquery-3.3.3/debian/changelog	2024-04-27 14:02:12.0 +0200
@@ -1,3 +1,11 @@
+isoquery (3.3.3-1.1) unstable; urgency=medium
+
+  [ Steve Langasek ]
+  * debian/patches/test-locale-is-C: Don't expect non-English output
+under LANG=C.UTF-8.  Closes: #1052772.
+
+ -- Sebastian Ramacher   Sat, 27 Apr 2024 14:02:12 +0200
+
 isoquery (3.3.3-1) unstable; urgency=medium
 
   * New upstream version 3.3.3
diff -Nru isoquery-3.3.3/debian/patches/series isoquery-3.3.3/debian/patches/series
--- isoquery-3.3.3/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ isoquery-3.3.3/debian/patches/series	2024-04-27 14:00:59.0 +0200
@@ -0,0 +1 @@
+test-locale-is-C
diff -Nru isoquery-3.3.3/debian/patches/test-locale-is-C isoquery-3.3.3/debian/patches/test-locale-is-C
--- isoquery-3.3.3/debian/patches/test-locale-is-C	1970-01-01 01:00:00.0 +0100
+++ isoquery-3.3.3/debian/patches/test-locale-is-C	2024-04-27 14:00:59.0 +0200
@@ -0,0 +1,423 @@
+Description: Don't expect non-English output under LANG=C.UTF-8
+ For some reason upstream has a test case that uses French output to compare
+ against, but sets LANG=C.UTF-8 in the test environment.  We shouldn't expect
+ French output in this environment.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1052772.
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: isoquery-3.3.3/tests/expected/iso_639-2/all_localized_test_stdout.txt
+===
+--- isoquery-3.3.3.orig/tests/expected/iso_639-2/all_localized_test_stdout.txt
 isoquery-3.3.3/tests/expected/iso_639-2/all_localized_test_stdout.txt
+@@ -1,4 +1,4 @@
+-aar		aa	afar
+-alg			algonquines, langues
+-bod	tib	bo	tibétain
+-heb		he	hébreu
++aar		aa	Afar
++alg			Algonquian languages
++bod	tib	bo	Tibetan
++heb		he	Hebrew
+Index: isoquery-3.3.3/tests/expected/iso_639-3/all_localized_test_stdout.txt
+===
+--- isoquery-3.3.3.orig/tests/expected/iso_639-3/all_localized_test_stdout.txt
 isoquery-3.3.3/tests/expected/iso_639-3/all_localized_test_stdout.txt
+@@ -1,3 +1,3 @@
+-aae	I	L			albanais d'Arbëreshë
+-deu	I	L	de	ger	allemand
+-nbs	I	L			langue des signes namibienne
++aae	I	L			Arbëreshë Albanian
++deu	I	L	de	ger	German
++nbs	I	L			Namibian Sign Language
+Index: isoquery-3.3.3/tests/expected/iso_639-5/all_localized_test_stdout.txt
+===
+--- isoquery-3.3.3.orig/tests/expected/iso_639-5/all_localized_test_stdout.txt
 isoquery-3.3.3/tests/expected/iso_639-5/all_localized_test_stdout.txt
+@@ -1,3 +1,3 @@
+-aus	australiennes, langues
+-nai	indiennes d’Amérique du Nord, langues
+-tut	altaïques, langues
++aus	Australian languages
++nai	North American Indian languages
++tut	Altaic languages
+Index: isoquery-3.3.3/tests/expected/iso_3166-1/all_localized_test_stdout.txt
+===
+--- isoquery-3.3.3.orig/tests/expected/iso_3166-1/all_localized_test_stdout.txt
 isoquery-3.3.3/tests/expected/iso_3166-1/all_localized_test_stdout.txt
+@@ -1,7 +1,7 @@
+-DE	DEU	276	Allemagne
+-ES	ESP	724	Espagne
++DE	DEU	276	Germany
++ES	ESP	724	Spain
+ FR	FRA	250	France
+-RU	RUS	643	Russie, Fédération de
++RU	RUS	643	Russian Federation
+ TV	TUV	798	Tuvalu
+-TW	TWN	158	Taïwan, province de Chine
++TW	TWN	158	Taiwan, Province of China
+ UA	UKR	804	Ukraine
+Index: isoquery-3.3.3/tests/expected/iso_3166-1/invalid_codes_localized_test_stdout.txt
+===
+--- isoquery-3.3.3.orig/tests/expected/iso_3166-1/invalid_codes_localized_test_stdout.txt
 isoquery-3.3.3/tests/expected/iso_3166-1/invalid_codes_localized_test_stdout.txt
+@@ -1,3 +1,3 @@
+ UA	UKR	804	Ukraine
+-FR	FRA	250	Frankreich
+-TW	TWN	158	Taiwan, Chinesische Provinz
++FR	FRA	250	France
++TW	TWN	158	Taiwan, Province of China
+Index: isoquery-3.3.3/tests/expected/iso_3166-1/multiple_codes_localized_test_stdout.txt
+===
+--- isoquery-3.3.3.orig/tests/expected/iso_3166-1/multiple_codes_localized_test_stdout.txt
 isoquery-3.3.3/tests/expected/iso_3166-1/multiple_codes_localized_test_stdout.txt
+@@ -1,3 +1,3 @@
+ UA	UKR	804	Ukraine
+-FR	FRA	250	Frankreich
+-TW	TWN	158	Taiwan, Chinesische Provinz
++FR	FRA	250	France
++TW	TWN	158	Taiwan, Province of China
+Index: isoquery-3.3.3/tests/expected/iso_3166-2/all_localized_test_stdout.txt
+===
+--- 

Bug#1069946: rust-webpki-roots: hardcoded root certs are unfit for stable Debian

[Jonas Smedegaard]

Source: rust-webpki-roots
Version: 0.26.1-1
Severity: grave
Tags: upstream
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The purpose of WebPKI-Roots is to hardcode a static set of PKI
certificates into compiled code.
This functionality is unfit for a Debian stable release, where the
ability to update certificates is crucial for the long lifespan of the
release.

Hence flagging this as a severe bug, to avoid this package to trickle
into testing and from there into stable.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYs6eAACgkQLHwxRsGg
ASE72w/+MedwMxfVZceByG1b0b0NgXBqVKDy1vYa4evK7dtK8Tw/jhEIgGeOlwji
cjoPM974u+DCwhMKvaKjIOjQnokr6NL47g0uGj1aUKvNL/Gv6hHNBVXLyyN14wqS
jpl7QpLNkpSISy8TPEwR8dVtQYaRoxWneIRdYMM+SAh5h+MMWlesXQ964G37ZQPH
iOC1RmQs/WGLgPf3pR+rFOz0IgKBMyX5DIUj/KLffLpI3Va4F5BsJib54E3JbQKc
4SLu5iTEJPROp+DTR5YZg3nyF0//qdzWCejRVOu0RxNxXy4GtN0g/aXQzR4zJpY9
5LrExmr7gEb/Gwi5K21P1RMVUSUISg19z5rhcOTciJ4FBI2DY/72F6/lWwaXIrDe
eui0KsOkUmqiexgj2qT8g6hD+LWkfl7mc2i8a/x0epkgXwMu9/2BclsQpVqhkGVt
+X/fzsBOzd6So0V7GZctfZRSbUGBY8aHx/fZ9TXFv52wDEV+yt+ZdsCct0fuXOJK
KThXXZZrlLjms7DjlniInTrlfkkKFoqtlXT7NDakeAD6iNMmGseJ05D0li7mqvLZ
VXODwdevwol5+dlQxFAp6+MGhCw2/veyuySJ8Ti4V9Lcxpa8AdlebV+FIHaqMu6v
E84BT2g5qnueVmmxC0QWgijm36pv2xJm/iIcCEHVpte6pT2ri30=
=X1MJ
-END PGP SIGNATURE-

Bug#1069878: dm-writeboost-dkms: kernel module fails to build for Linux 6.7.12: error: too few arguments to function ‘dm_io’

[Andreas Beckmann]

Followup-For: Bug #1069878
Control: tag -1 + bookworm

DKMS make.log for dm-writeboost-2.2.16 for kernel 6.1.0-20-cloud-amd64 (x86_64)
Sat Apr 27 11:45:49 UTC 2024
make -C /lib/modules/6.1.0-20-cloud-amd64/build 
M=/var/lib/dkms/dm-writeboost/2.2.16/build modules
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-20-cloud-amd64'
make -f /usr/src/linux-headers-6.1.0-20-common/scripts/Makefile.build 
obj=/var/lib/dkms/dm-writeboost/2.2.16/build need-builtin=1 need-modorder=1 
  printf '%s
'   dm-writeboost-target.o dm-writeboost-metadata.o dm-writeboost-daemon.o | 
awk '!x[$0]++ { print("/var/lib/dkms/dm-writeboost/2.2.16/build/"$0) }' > 
/var/lib/dkms/dm-writeboost/2.2.16/build/dm-writeboost.mod
   gcc-12 
-Wp,-MMD,/var/lib/dkms/dm-writeboost/2.2.16/build/.dm-writeboost-target.o.d 
-nostdinc -I/usr/src/linux-headers-6.1.0-20-common/arch/x86/include 
-I./arch/x86/include/generated -I/usr/src/linux-headers-6.1.0-20-common/include 
-I./include -I/usr/src/l
inux-headers-6.1.0-20-common/arch/x86/include/uapi 
-I./arch/x86/include/generated/uapi 
-I/usr/src/linux-headers-6.1.0-20-common/include/uapi 
-I./include/generated/uapi -include 
/usr/src/linux-headers-6.1.0-20-common/include/linux/compiler-version.h 
-include 
/usr/src/linux-headers-6.1.0-20-common/include/linux/kconfig.h -include 
/usr/src/linux-headers-6.1.0-20-common/include/linux/compiler_types.h 
-D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-6.1.0-20-common/= -Wall 
-Wundef -Werror=strict-prototypes -Wn
o-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE 
-Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type 
-Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx 
-fcf-protection=none -m64 -fali
gn-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone 
-mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables 
-mindirect-branch=thunk-extern -mindirect-branch-register -m
indirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables 
-mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address 
-Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 
-fno-allow-store-data-races -Wframe-la
rger-than=2048 -fstack-protector-strong -Wno-main -Wno-unused-but-set-variable 
-Wno-unused-const-variable -Wno-dangling-pointer -ftrivial-auto-var-init=zero 
-fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY 
-Wvla -Wno-pointer-sign -W
cast-function-type -Wno-stringop-truncation -Wno-stringop-overflow 
-Wno-restrict -Wno-maybe-uninitialized -Wno-array-bounds 
-Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -fno-strict-overflow 
-fno-stack-check -fconserve-stack -Werror=date-time -Werror=
incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -g  
-DMODULE  -DKBUILD_BASENAME='"dm_writeboost_target"' 
-DKBUILD_MODNAME='"dm_writeboost"' -D__KBUILD_MODNAME=kmod_dm_writeboost -c -o 
/var/lib/dkms/dm-writeboost/2.2.16/build/dm-wri
teboost-target.o 
/var/lib/dkms/dm-writeboost/2.2.16/build/dm-writeboost-target.c   ; 
./tools/objtool/objtool --hacks=jump_label --hacks=noinstr --orc --retpoline 
--rethunk --sls --static-call --uaccess   --module 
/var/lib/dkms/dm-writeboost/2.2.16/build/dm-w
riteboost-target.o
   gcc-12 
-Wp,-MMD,/var/lib/dkms/dm-writeboost/2.2.16/build/.dm-writeboost-metadata.o.d 
-nostdinc -I/usr/src/linux-headers-6.1.0-20-common/arch/x86/include 
-I./arch/x86/include/generated -I/usr/src/linux-headers-6.1.0-20-common/include 
-I./include -I/usr/src
/linux-headers-6.1.0-20-common/arch/x86/include/uapi 
-I./arch/x86/include/generated/uapi 
-I/usr/src/linux-headers-6.1.0-20-common/include/uapi 
-I./include/generated/uapi -include 
/usr/src/linux-headers-6.1.0-20-common/include/linux/compiler-version.h -includ
e /usr/src/linux-headers-6.1.0-20-common/include/linux/kconfig.h -include 
/usr/src/linux-headers-6.1.0-20-common/include/linux/compiler_types.h 
-D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-6.1.0-20-common/= -Wall 
-Wundef -Werror=strict-prototypes -
Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE 
-Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type 
-Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx 
-fcf-protection=none -m64 -fa
lign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone 
-mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables 
-mindirect-branch=thunk-extern -mindirect-branch-register 
-mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables 
-mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address 
-Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 
-fno-allow-store-data-races -Wframe-
larger-than=2048 -fstack-protector-strong -Wno-main 

Bug#1069945: rapiddisk-dkms: module fails to build for Linux 6.7.12, 6.1.85: rapiddisk-cache.c:198:16: error: too few arguments to function 'dm_io'

[Andreas Beckmann]

Package: rapiddisk-dkms
Version: 9.1.0-2
Severity: serious
Control: found -1 9.0.0-1

DKMS make.log for rapiddisk-dkms-9.1.0 for kernel 6.7.12-amd64 (x86_64)
Fri Apr 26 21:35:41 UTC 2024
make: Entering directory '/usr/src/linux-headers-6.7.12-amd64'
  CC [M]  /var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk.o
  CC [M]  /var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.o
/var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.c: In function 
'dm_io_async_bvec':
/var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.c:198:16: error: too 
few arguments to function 'dm_io'
  198 | return dm_io(, num_regions, where, NULL);
  |^
In file included from 
/var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.c:46:
/usr/src/linux-headers-6.7.12-common/include/linux/dm-io.h:82:5: note: declared 
here
   82 | int dm_io(struct dm_io_request *io_req, unsigned int num_regions,
  | ^
/var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.c:199:1: error: 
control reaches end of non-void function [-Werror=return-type]
  199 | }
  | ^
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.7.12-common/scripts/Makefile.build:248: 
/var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [/usr/src/linux-headers-6.7.12-common/Makefile:1936: 
/var/lib/dkms/rapiddisk-dkms/9.1.0/build] Error 2
make: *** [/usr/src/linux-headers-6.7.12-common/Makefile:246: __sub-make] Error 
2
make: Leaving directory '/usr/src/linux-headers-6.7.12-amd64'

The corresponding change "dm io: Support IO priority" has been
introduced in 
  v6.9-rc1 (6e5f0f6383b4896c7e9b943d84b136149d0f45e9)
and has been backported to
  v6.8.2   (3d02f57794b56f8a04a21fdfb04f20a1c9f712a7)
  v6.7.11  (4156ddd66b15ca409cd52dc7040c28c25143ce5a)
  v6.6.23  (5cfcea64883486d79c695afdc502e32eb1b71587)
  v6.1.83  (92b3c2437df8fe55a5c7816d9521b1fb7d0718b0)
This module build failure will happen on bookworm, too, which already has
6.1.0-20-* (aka 6.1.85) in bookworm-pu.

The solution is probably to conditionally append ', IOPRIO_DEFAULT'
as last parameter to the dm_io calls.

Please support both variants s.t. on upgrades where both old and new
kernels are installed the dkms module can be built for both variants.


Andreas

Bug#1069400: dqlite: FTBFS on arm64: dh_auto_test: error: make -j4 check "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2

[Mathias Gibbens]

Control: tags -1 + help unreproducible
Control: severity -1 important

  Lowering bug severity to important since I can't reproduce this issue
on any of my systems. Additionally, looking at the various reproducible
builds shows the most recent arm64 build passed, while the amd64 one
failed.

Mathias


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

Bug#1069941: colorcet: please drop extraneous obsolete python3-mock dependency

[Alexandre Detiste]

Source: colorcet
Version: 3.0.1-1
Severity: normal

Dear Maintainer,

Please drop extraneous obsolete python3-mock dependency,
it is not used at all and we are trying to slowly
remove this old library from Debian.

Greetings

tchet@quieter:/tmp/colorcet$ grep mock -r
debian/control: python3-mock,
tchet@quieter:/tmp/colorcet$

Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices

[Михаил Медведев]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : imsprog
   Version  : 1.3.7-1
   Upstream contact : Mikhail medvedeve-ink-rea...@yandex.ru
 * URL  :https://github.com/bigbigmdm/IMSProg
 * License  : GPL-2+, GPL-3+, LGPL-2.1
 * Vcs  :https://github.com/bigbigmdm/IMSProg/
   Section  : devel

The source builds the following binary packages:

  imsprog - Linux chip programmer for CH341a devices

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/i/imsprog/imsprog_1.3.7-1.dsc

Changes since the last upload:

 imsprog (1.3.7-1) unstable; urgency=medium
 .
   * New upstream release

Regards,
--
  Mikhail Medvedev

Bug#1069940: python-blazarclient: please drop the python3-mock dependency

[Alexandre Detiste]

Source: python-blazarclient
Version: 4.0.1-2
Severity: normal

Dear Maintainer,

upstream does not use python3-mock anymore

Greetings


tchet@quieter:/tmp/python-blazarclient$ grep mock -r | grep -e debian -e import

blazarclient/tests/test_base.py:from unittest import mock
blazarclient/tests/test_command.py:from unittest import mock
blazarclient/tests/test_plugin.py:from unittest import mock
blazarclient/tests/test_shell.py:#import mock
blazarclient/tests/v1/shell_commands/test_floatingips.py:from unittest import 
mock
blazarclient/tests/v1/shell_commands/test_hosts.py:from unittest import mock
blazarclient/tests/v1/shell_commands/test_leases.py:from unittest import mock

debian/control: python3-mock ,

Bug#1069934: 4.9.2. The dak ls utility should mention rmadison

[Holger Levsen]

control: severity -1 wishlist
thanks

Hi Bill,

On Sat, Apr 27, 2024 at 12:11:21PM +0200, Bill Allombert wrote:
> 4.9.2. The dak ls utility
> could mention rmadison from devscripts
> that does not require to log to ftp-master.debian.org.
 
yes. patches, commits & pushes welcome.


-- 
cheers,
Holger

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

20230709: Today was the warmest day on earth in 125,000 years. Today was also
the day with the most planes in the air at one time ever in history. By the time
you read this both of these records have probably been broken.


signature.asc
Description: PGP signature

Bug#1069939: networkd-dispatcher: please remove dependency on python3-mock

[Alexandre Detiste]

Source: networkd-dispatcher
Version: 2.2.4-1
Severity: normal

Dear Maintainer,

python3-mock is not usefull in a Python3-only world.

Here's a patch to remove it.

I see you are also active in the upstream repository;
so it should be trivial.

Greetings


diff --git a/debian/control b/debian/control
index 777e335..05ed46b 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,6 @@ Build-Depends: asciidoc,
iw | wireless-tools,
python3-dbus,
python3-gi,
-   python3-mock,
python3-pytest,
python3:any,
xsltproc
diff --git a/tests/test_networkd-dispatcher.py 
b/tests/test_networkd-dispatcher.py
index 7b270d2..4c1cd7a 100644
--- a/tests/test_networkd-dispatcher.py
+++ b/tests/test_networkd-dispatcher.py
@@ -3,13 +3,13 @@ from collections import namedtuple
 import dbus
 import errno
 import logging
-import mock
+from unittest import mock
 import os
 import socket
 import subprocess
 import sys
 import pytest
-from mock import patch
+from unittest.mock import patch
 myPath = os.path.dirname(os.path.abspath(__file__))
 sys.path.insert(0, myPath + '/../')
 import networkd_dispatcher
diff --git a/tox.ini b/tox.ini
index 02cc761..b4fd7a3 100644
--- a/tox.ini
+++ b/tox.ini
@@ -14,7 +14,6 @@ deps =
 pytest
 PyGObject
 pytest-cov
-mock
 commands =
 python3 -V
 python3 -m pytest --cov=networkd_dispatcher --cov-report term-missing -q 
tests

Bug#789401: Proposed patch to solve the issue.

[Georgios Zarkadas]

The attached patch removes, during the recreation of base tgz,
all files from /tmp and /var/tmp (which is also world-writable).

It is made for the git version at salsa.debian.org but can also be applied
to the current (0.231) version as-is.

I have also modified a comment during the creation of BUILDDIR to alert for
the possibility of a user who keeps (still) in his/her configuration
/tmp/buildd
as the build directory.

It is not essential to the issue (only the tar command is), but I thought
it would be nice to have also. I can send a modified version of the patch,
if deemed necessary.

Cheers,
Georgios
diff --git a/pbuilder-modules b/pbuilder-modules
index aca876de..8d8a0c59 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -730,8 +730,9 @@ function extractbuildplace () {
 fi
 
 mountproc
-# FIXME maybe add more checks here? - actually it's not even really needed,
-# since it's created at chroot creation time too.
+# FIXME maybe add more checks here? - Always create it, since it may be set
+# in the configuration to be inside one of the excluded (at 'create_basetgz')
+# directories of the chroot (for example: '/tmp/buildd').
 mkdir -p "${BUILDPLACE}${BUILDDIR}"
 # XXX added in 0.216, to be deprecated in the future
 # Add a compatibility symlink from the old BUILDDIR (/tmp/buildd) to the new
@@ -834,7 +835,7 @@ function create_basetgz() {
 if [ -h "$BUILDPLACE/tmp/buildd" ] && [ "$(readlink -f "$BUILDPLACE/tmp/buildd")" = "${BUILDPLACE}$BUILDDIR" ]; then
 rm "$BUILDPLACE/tmp/buildd"
 fi
-if ! tar -c --use-compress-program "$COMPRESSPROG" -f "${BASETGZ}.tmp" --exclude ./sys/* --exclude ./proc/* ./* ; then
+if ! tar -c --use-compress-program "$COMPRESSPROG" -f "${BASETGZ}.tmp" --exclude "./sys/*" --exclude "./proc/*" --exclude "./tmp/*" --exclude "./tmp/.*" --exclude "./var/tmp/*" --exclude "./var/tmp/.*" ./* ; then
 log.e "failed building base tarball"
 rm -f "${BASETGZ}.tmp"
 exit 1;

Bug#1069938: RM: backup2swift

[Alexandre Detiste]

Source: backup2swift
Version: 0.8-1.1
Severity: normal

Dear Maintainer,

I see you are both upstream & maintainer for backup2swift.

Maybe it would be better to remove such utility from Debian
than let them bitrot unattended.

Greetings


https://tracker.debian.org/pkg/backup2swift
https://github.com/mkouhei/backup2swift

Bug#955260: libkqueue: fails to build on most my boxes

[marillat]

On Sat, 27 Apr 2024 12:32:58 +0200 Andreas Beckmann  wrote:

[...]

> This is now happening on the buildds as well and I can also reproduce it
> locally on amd64.

You must try with the latest source 2.6.1

https://github.com/mheily/libkqueue/releases

Christian

Bug#1069937: flent: please drop old extraneous python3-mock build dependency

[Alexandre Detiste]

Source: flent
Version: 2.1.1-2
Severity: normal

Dear Maintainer,

python3-mock is an old library that was merged in
the Python standard library since Python 3.3.

We are slowly removing it from Debian.

Please remove the one ref in d/control.

Greetings


tchet@quieter:/tmp/flent$ grep mock -r
CHANGES.md:  'mock' Python library).
debian/control:   python3-mock,
tchet@quieter:/tmp/flent$

Bug#1069936: svtplay-dl: please update package to allow for python3-mock removal

[Alexandre Detiste]

Source: svtplay-dl
Version: 3.0-2
Severity: normal

Dear Maintainer,

I propose to help you geting this back in shape & uploaded;
and I'll sponsor the upload too.

Greetings

Bug#955260: libkqueue: fails to build on most my boxes

[Andreas Beckmann]

Followup-For: Bug #955260
Control: severity -1 serious
Control: found -1 2.3.1-1
Control: retitle -1 libkqueue: FTBFS: tests fail with ERROR: Program received 
signal 6

This is now happening on the buildds as well and I can also reproduce it
locally on amd64.


Andreas

Bug#1069935: lyskom-elisp-client: missing Build-Depends: emacs

[Andreas Beckmann]

Source: lyskom-elisp-client
Version: 0.48+git.20231226.364902c3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

lyskom-elisp-client fails to build for arch:all due to missing emacs:

https://buildd.debian.org/status/fetch.php?pkg=lyskom-elisp-client=all=0.48%2Bgit.20231226.364902c3-1=1714210327=0

dh binary-indep
   dh_testroot -i
   dh_prep -i
   dh_installdirs -i
   dh_auto_install --destdir=debian/lyskom-elisp-client/ -i
make -j6 install 
DESTDIR=/<>/lyskom-elisp-client-0.48\+git.20231226.364902c3/debian/lyskom-elisp-client
 AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/<>'
emacs -batch -l lpath.el -l help-compile.el -f batch-byte-compile 
lyskom-0.48+git.20231226.364902c3.el
make[1]: emacs: No such file or directory
make[1]: *** [Makefile:62: lyskom-0.48+git.20231226.364902c3.elc] Error 127
make[1]: Leaving directory '/<>'
dh_auto_install: error: make -j6 install 
DESTDIR=/<>/lyskom-elisp-client-0.48\+git.20231226.364902c3/debian/lyskom-elisp-client
 AM_UPDATE_INFO_DIR=no returned exit code 2
make: *** [debian/rules:10: binary-indep] Error 25


Andreas

Bug#1069934: 4.9.2. The dak ls utility should mention rmadison

[Bill Allombert]

Package: developers-reference
Version: 13.6
Severity: normal

Hello Holger,

4.9.2. The dak ls utility

could mention rmadison from devscripts
that does not require to log to ftp-master.debian.org.

There is also a be interface:

% curl 'https://api.ftp-master.debian.org/madison?package=evince'
evince | 3.30.2-3+deb10u1 | oldoldstable   | source, amd64, arm64, 
armhf, i386
evince | 3.30.2-3+deb10u1 | oldoldstable-debug | source
evince | 3.38.2-1 | oldstable  | source, amd64, arm64, 
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince | 43.1-2   | stable | source
evince | 43.1-2+b1| stable | amd64, arm64, armel, 
armhf, i386, mips64el, mipsel, ppc64el, s390x
evince | 45.0-1   | testing| source
evince | 45.0-1+b1| testing| amd64, arm64, armel, 
armhf, i386, mips64el, ppc64el, s390x
evince | 46.0-1   | unstable   | source
evince | 46.0-1   | unstable-debug | source
evince | 46.0-1+b1| unstable   | amd64, arm64, armel, 
armhf, i386, mips64el, ppc64el, riscv64, s390x

Cheers,
-- 
Bill. 

Imagine a large red swirl here.