Bug#1018909: Forwarded upstream

[Aurélien COUDERC]

control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=458069

Bug#1022025: Can't enable amdgpu driver in linux-image-5.10.0-19-amd64

[muumatch]

Package: linux-image
Version: 5.10.0-19

Hi,
I'm using bulleseye, and upgrate to "linux-image-5.10.0-19" today.
Then rebooted, my PC couldn't boot.
I pressed a phyisical power button, and force rebooted a PC.
I pressed "e" on grub menu, into edit mode for boot options.
I edited,

GRUB_CMDLINE_LINUX_DEFAULT="quiet radeon.cik_support=0 amdgpu.cik_support=1"

to

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

Then press "F10", a PC could boot.
Deleted part "radeon.cik_support=0 amdgpu.cik_support=1" is for enabled 
"amdgpu" driver instead of "radeon".
Of cause, can't enable amdgpu driver after rebooted, and vulkan disabled also.
I seems, has problems amdgpu support in a linux-image-5.10.0-19 ?

My GPU: 
$ lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Kaveri [Radeon R7 Graphics]

Bug#1021710: "r"eplacing high nibble doesn't take effect

[Peter Pentchev]

control: tag -1 + confirmed upstream

On Thu, Oct 13, 2022 at 01:41:36PM +0200, Philipp Marek wrote:
> Package: hexer
> Version: 1.0.6-1
> Severity: normal
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> Replacing a nibble (only) has no effect; but the display indicates 
> otherwise.

Thanks for your interest in hexer! This is related to another bug
I noticed recently; I will try to fix it in the next couple of days.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1022024: python-gitlab FTBFS: test failures

[Adrian Bunk]

Source: python-gitlab
Version: 1:3.10.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=python-gitlab=all=1%3A3.10.0-1=1666104723=0

...
=== FAILURES ===
 test_from_helper_subprocess_error_raises_error 

m_open = 
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7f57355c8b50>

@mock.patch("builtins.open")
@pytest.mark.skipif(sys.platform.startswith("win"), reason="Not supported 
on Windows")
def test_from_helper_subprocess_error_raises_error(m_open, monkeypatch):
# using /usr/bin/false here to force a non-zero return code
fd = io.StringIO(
dedent(
"""\
[global]
default = helper

[helper]
url = https://helper.url
oauth_token = helper: /usr/bin/false
"""
)
)

fd.close = mock.Mock(return_value=None)
m_open.return_value = fd
with monkeypatch.context() as m:
m.setattr(Path, "resolve", _mock_existent_file)
with pytest.raises(config.GitlabConfigHelperError) as e:
>   config.GitlabConfigParser(gitlab_id="helper")

tests/unit/test_config.py:327: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
gitlab/config.py:114: in __init__
self._parse_config()
gitlab/config.py:198: in _parse_config
self._get_values_from_helper()
gitlab/config.py:266: in _get_values_from_helper
subprocess.check_output(commmand, stderr=subprocess.PIPE)
/usr/lib/python3.10/subprocess.py:420: in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
/usr/lib/python3.10/subprocess.py:501: in run
with Popen(*popenargs, **kwargs) as process:
/usr/lib/python3.10/subprocess.py:969: in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
args = ['/usr/bin/false'], executable = b'/usr/bin/false', preexec_fn = None
close_fds = True, pass_fds = (), cwd = None, env = None, startupinfo = None
creationflags = 0, shell = False, p2cread = -1, p2cwrite = -1, c2pread = 11
c2pwrite = 12, errread = 13, errwrite = 14, restore_signals = True, gid = None
gids = None, uid = None, umask = -1, start_new_session = False

def _execute_child(self, args, executable, preexec_fn, close_fds,
   pass_fds, cwd, env,
   startupinfo, creationflags, shell,
   p2cread, p2cwrite,
   c2pread, c2pwrite,
   errread, errwrite,
   restore_signals,
   gid, gids, uid, umask,
   start_new_session):
"""Execute program (POSIX version)"""

if isinstance(args, (str, bytes)):
args = [args]
elif isinstance(args, os.PathLike):
if shell:
raise TypeError('path-like args is not allowed when '
'shell is true')
args = [args]
else:
args = list(args)

if shell:
# On Android the default shell is at '/system/bin/sh'.
unix_shell = ('/system/bin/sh' if
  hasattr(sys, 'getandroidapilevel') else '/bin/sh')
args = [unix_shell, "-c"] + args
if executable:
args[0] = executable

if executable is None:
executable = args[0]

sys.audit("subprocess.Popen", executable, args, cwd, env)

if (_USE_POSIX_SPAWN
and os.path.dirname(executable)
and preexec_fn is None
and not close_fds
and not pass_fds
and cwd is None
and (p2cread == -1 or p2cread > 2)
and (c2pwrite == -1 or c2pwrite > 2)
and (errwrite == -1 or errwrite > 2)
and not start_new_session
and gid is None
and gids is None
and uid is None
and umask < 0):
self._posix_spawn(args, executable, env, restore_signals,
  p2cread, p2cwrite,
  c2pread, c2pwrite,
  errread, errwrite)
return

orig_executable = executable

# For transferring possible exec failure from child to parent.
# Data format: "exception name:hex errno:description"
# Pickle is not used; it is complex and involves memory allocation.
errpipe_read, errpipe_write = os.pipe()
# errpipe_write must not be in the standard io 0, 1, or 2 fd range.
low_fds_to_close = []
while errpipe_write < 3:
low_fds_to_close.append(errpipe_write)
  

Bug#1010807: isc-dhcp: ftbfs on riscv64 arch

[Paul Wise]

On Tue, 2022-10-18 at 10:17 +0800, Bo YU wrote:

> Certainly. I have updated the patch with help of Paul Wise.
> But I am not sure I understand it correctly. Yeah, The bind.tar.gz keeps
> itself config.{guess/sub}, so I simply copy these files from system in
> Makefile.

While that is a minimal workaround for the riscv64 FTBFS, I think a
better option would be to unpack bind/bind.tar.gz manually before
dh_update_autotools_config runs and also ensure that dh_autoreconf
rebuilds things in the unpacked bind dir too, something like this:

debian/rules

   # Ensure that the bind config.guess/config.sub are unpacked first,
   # otherwise they won't be updated and isc-dhcp will FTBFS on new arches
   execute_before_dh_update_autotools_config:
cd bind && tar xf bind.tar.gz
   
   # Ensure that the bind build system gets rebuilt too
   override_dh_autoreconf:
dh_autoreconf debian/autogen.sh

debian/autogen.sh

   #!/bin/sh
   set -x
   autoreconf -f -i
   cd bind/bind-*/
   autoreconf -f -i

That is still only a workaround; the correct solution to this issue
is that isc-dhcp should link against the bind9 libraries instead of
adding a copy of bind9 to isc-dhcp. This would be more complicated
though and would have to be done upstream not in Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1020155: caffeine: diff for NMU version 2.9.12-0.1

[Boyuan Yang]

Control: tags 1020155 + patch
Control: tags 1020155 + pending

Dear maintainer,

I've prepared an NMU for caffeine (versioned as 2.9.12-0.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru caffeine-2.9.10/caffeinate caffeine-2.9.12/caffeinate
--- caffeine-2.9.10/caffeinate  2017-01-16 07:59:02.0 -0500
+++ caffeine-2.9.12/caffeinate  2022-04-11 03:42:09.0 -0400
@@ -25,7 +25,7 @@
 
 sys.tracebacklimit = None
 PROGRAM_NAME = "caffeinate"
-VERSION = pkg_resources.require("caffeine")[0].version
+VERSION = pkg_resources.require("cups-of-caffeine")[0].version
 
 def die(err):
 sys.exit(PROGRAM_NAME + ': ' + err)
diff -Nru caffeine-2.9.10/caffeine caffeine-2.9.12/caffeine
--- caffeine-2.9.10/caffeine2020-07-06 17:21:36.0 -0400
+++ caffeine-2.9.12/caffeine2022-04-11 03:42:49.0 -0400
@@ -32,7 +32,7 @@
 
 # Handle command-line arguments
 parser = argparse.ArgumentParser(prog=PROGRAM_NAME, description='Prevent
desktop idleness in full-screen mode')
-parser.add_argument('-V', '--version', action='version',
version=PROGRAM_NAME + ' ' + pkg_resources.require(PROGRAM_NAME)[0].version)
+parser.add_argument('-V', '--version', action='version',
version=PROGRAM_NAME + ' ' + pkg_resources.require("cups-of-
caffeine")[0].version)
 parser.parse_args()
 
 ewmh = EWMH()
diff -Nru caffeine-2.9.10/caffeine-indicator caffeine-2.9.12/caffeine-
indicator
--- caffeine-2.9.10/caffeine-indicator  2020-08-31 11:54:38.0 -0400
+++ caffeine-2.9.12/caffeine-indicator  2022-04-11 03:42:25.0 -0400
@@ -34,7 +34,7 @@
 from Xlib import display
 
 PROGRAM_NAME = "caffeine-indicator"
-VERSION = pkg_resources.require("caffeine")[0].version
+VERSION = pkg_resources.require("cups-of-caffeine")[0].version
 
 # Register the gettext function for the whole interpreter as "_"
 builtins._ = gettext.gettext
diff -Nru caffeine-2.9.10/cups_of_caffeine.egg-info/PKG-INFO caffeine-
2.9.12/cups_of_caffeine.egg-info/PKG-INFO
--- caffeine-2.9.10/cups_of_caffeine.egg-info/PKG-INFO  2022-03-29
13:41:08.0 -0400
+++ caffeine-2.9.12/cups_of_caffeine.egg-info/PKG-INFO  2022-07-14
16:55:06.0 -0400
@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: cups-of-caffeine
-Version: 2.9.10
+Version: 2.9.12
 Summary: Keep your computer awake.
 Home-page: https://launchpad.net/caffeine
 Author: Reuben Thomas
diff -Nru caffeine-2.9.10/debian/changelog caffeine-2.9.12/debian/changelog
--- caffeine-2.9.10/debian/changelog2022-04-11 03:24:50.0 -0400
+++ caffeine-2.9.12/debian/changelog2022-10-18 23:15:26.0 -0400
@@ -1,3 +1,10 @@
+caffeine (2.9.12-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
++ Fix build with setuptools (>= 61.0). (Closes: #1020155)
+
+ -- Boyuan Yang   Tue, 18 Oct 2022 23:15:26 -0400
+
 caffeine (2.9.10-2) unstable; urgency=medium
 
   * Hard-code the version directly into executables to workaround
diff -Nru caffeine-2.9.10/PKG-INFO caffeine-2.9.12/PKG-INFO
--- caffeine-2.9.10/PKG-INFO2022-03-29 13:41:08.237084000 -0400
+++ caffeine-2.9.12/PKG-INFO2022-07-14 16:55:06.973254200 -0400
@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: cups-of-caffeine
-Version: 2.9.10
+Version: 2.9.12
 Summary: Keep your computer awake.
 Home-page: https://launchpad.net/caffeine
 Author: Reuben Thomas
diff -Nru caffeine-2.9.10/setup.py caffeine-2.9.12/setup.py
--- caffeine-2.9.10/setup.py2022-03-29 13:35:27.0 -0400
+++ caffeine-2.9.12/setup.py2022-07-14 16:54:26.0 -0400
@@ -57,7 +57,7 @@
 data_files.append(tuple(("/" + autostart_dir, [join(autostart_dir,
desktop_name)])))
 
 setup(name="cups-of-caffeine",
-version="2.9.10",
+version="2.9.12",
 description="Keep your computer awake.",
 license="GPLv3",
 author="Reuben Thomas",
@@ -68,4 +68,5 @@
 data_files=data_files,
 
 scripts=["caffeine", "caffeinate", "caffeine-indicator"],
+py_modules=[], # Workaround for setuptools >= 61.0; see
https://bugs.launchpad.net/caffeine/+bug/1981419
 )
diff -Nru caffeine-2.9.10/translations/ar.po caffeine-
2.9.12/translations/ar.po
--- caffeine-2.9.10/translations/ar.po  2022-03-28 10:04:23.0 -0400
+++ caffeine-2.9.12/translations/ar.po  2022-07-14 16:50:31.0 -0400
@@ -14,8 +14,8 @@
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"X-Launchpad-Export-Date: 2021-07-12 06:04+\n"
-"X-Generator: Launchpad (build 1b66c075b8638845e61f40eb9036fabeaa01f591)\n"
+"X-Launchpad-Export-Date: 2022-04-19 06:24+\n"
+"X-Generator: Launchpad (build 5cc3bd61c85a328825183f316ddd801c0f7d7ef2)\n"
 
 #. file 'caffeine/core.py', line 123
 msgid "Caffeine is dormant"
diff -Nru caffeine-2.9.10/translations/be.po caffeine-
2.9.12/translations/be.po
--- caffeine-2.9.10/translations/be.po  2022-03-28 10:04:23.0 -0400
+++ caffeine-2.9.12/translations/be.po  2022-07-14 16:50:31.0 -0400
@@ -14,8 +14,8 @@
 

Bug#1021961: groff(7) mangled .ft documentation

[G. Branden Robinson]

package groff
tag 1021961 + upstream
thanks

It seems I can never learn how to get the magic "-1" bug number to work
for me.  I suspect it is a curse Anthony Towns laid on me lo these many
years ago...


signature.asc
Description: PGP signature

Bug#1021918: debian-installer: Kernel module blacklisting inconsistent

[Pascal Hambourg]

On 17/10/2022 at 13:13, Olaf Meeuwissen wrote:


I recently tried this version with hardware that triggers loading of the
mt7921e kernel module.  Loading the module fails due to a firmware file
load error but the installer starts okay.  However, the installer later
crashes when probing for network hardware (when it tries to rmmod the
kernel module).


How does the installer crash exactly ? Kernel panic ? Freeze ? Error ?


The first issue I ran into was that the documented[1] way to blacklist
kernel modules is no longer correct

  [1]: 
https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist

Instead of

   mt7921e.blacklist=yes

I had to use

   modprobe.blacklist=mt7921e


/lib/debian-installer-startup.d/S02module-params has the following comment:

# Before udev is started, parse kernel command word for module params of
# the form module.param=value and register them so they will be used when
# modules are loaded. Also check for modules to be blacklisted.

But udev is actually started earlier, so the first method does not work 
with modules included in initrd.gz (e.g. storage drivers).


However it should work with network driver modules which are installed 
much later.



However, upon booting I saw a pile of ATA bus and I/O errors that made
me suspicious.  The disk is brand new and a smartmontools extended test
reports no errors.

I found a /etc/modprobe.d/blacklist.local.conf file with

   blacklist modprobe


This is a minor bug in /lib/debian-installer-startup.d/S02module-params 
which can be easily fixed. However, it should not have any actual impact 
as "modprobe" does not match any kernel module name or alias.



For completeness' sake, the /etc/default/grub file included

   GRUB_CMDLINE_LINUX="modprobe.blacklist=mt7921e"


As expected.


Seeing that the kernel boot argument is added correctly to the GRUB
configuration, there is no need to create a file in /etc/modprobe.d/.
In addition, the installation manual needs to be updated to use the
correct syntax.


If I understand correctly, this is how things work:

The kernel runs /init.
/init runs /lib/debian-installer/start-udev which starts udevd.
udevd gets hotplug events and calls modprobe to load matching modules 
included in initrd.gz.

Then /init exec's /bin/busybox init.

busybox init reads /etc/inittab and runs /sbin/debian-installer-startup.
debian-installer-startup runs 
/lib/debian-installer-startup.d/S02module-params.
/lib/debian-installer-startup.d/S02module-params calls 
/bin/register-module for each module parameter or blacklist in the 
kernel command line.
register-module writes module blacklists in 
/etc/modprobe.d/blacklist.local.conf and module parameters in 
/etc/modprobe.d/local.conf.


Later, network driver modules are installed and loaded.

Later, /usr/bin/grub-installer calls /bin/user-params which retrieves 
kernel parameters after "--" or "---" in the command line and writes 
them to grub2/linux_cmdline in debconf and GRUB_CMDLINE_LINUX in 
/etc/default/grub.


So indeed kernel module parameters and blacklists may be duplicated in 
/etc/modprobe.d and GRUB_CMDLINE_LINUX. To avoid duplication they should 
be inserted before "---" in the installer command line.

Bug#1021737: lava: CVE-2022-42902

[Antonio Terceiro]

On Tue, Oct 18, 2022 at 06:09:45PM -0300, Antonio Terceiro wrote:
> Hi,
> 
> On Thu, Oct 13, 2022 at 09:13:18PM +0200, Moritz Mühlenhoff wrote:
> > Source: lava
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: grave
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerability was published for lava.
> > 
> > CVE-2022-42902[0]:
> > | In Linaro Automated Validation Architecture (LAVA) before 2022.10,
> > | there is dynamic code execution in lava_server/lavatable.py. Due to
> > | improper input sanitization, an anonymous user can force the lava-
> > | server-gunicorn service to execute user-provided code on the server.
> > 
> > https://git.lavasoftware.org/lava/lava/-/merge_requests/1834
> > https://git.lavasoftware.org/lava/lava/-/commit/e66b74cd6c175ff8826b8f3431740963be228b52?merge_request_iid=1834
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2022-42902
> > https://www.cve.org/CVERecord?id=CVE-2022-42902
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> I have uploaded a fix version to unstable (latest upstream), and I would
> like to upload the attached debdiff to -security. That package builds
> cleanly and passes its autopkgtest on bullseye. Let me know.

Correction: it fails the autopkgtest, but it fails in the exact same way
as the package already in bullseye fails.


signature.asc
Description: PGP signature

Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0

[Bill Allombert]

On Mon, Oct 17, 2022 at 08:44:52AM +, Tobias Hansen wrote:
> Control: block -1 by 1020436 1020456
> 
> Before sagemath can be fixed, cypari2 and giac have to be built against pari 
> 2.15.

OK, is there someone taking care of giac ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1022022: New btusb hardware IDs (MT7922, MT7921, others)

[Chris Hofstaedtler]

* Diederik de Haas  [221019 00:07]:
> On dinsdag 18 oktober 2022 23:44:17 CEST Chris Hofstaedtler wrote:
> > it appears quite some new btusb hardware was released recently.
> > linux-next has a lot of simple "Add xyz ID" patches for btusb.c:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/driv
> > ers/bluetooth/btusb.c
> > 
> > Please consider applying 57117d7234dadfba2a83615b2a9369f6f2f9914f
> > and/or the other patches adding new hwids to btusb.c for the
> > bookworm kernel.
> 
> It's already part of Linux 6.1-rc1 and it is expected that 6.1 will be the
> next LTS release and I'd guess thus also the Bookworm kernel.
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/bluetooth?h=v6.1-rc1

Right, that'd be good. I've manually applied
57117d7234dadfba2a83615b2a9369f6f2f9914f against 5.9.11-1, and that
works for me; but only after making available
BT_RAM_CODE_MT7922_1_1_hdr.bin from linux-firmware.git.

Chris

Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client

[Soren Stoutner]

For some reason, the plain text version of my previous email cut of the end 
(although it was 
included in the HTML version).  I am sending just that part again in hopes it 
goes through in 
both plain text and HTML.

> On Tuesday, October 18, 2022 1:41:51 PM MST Bastian Germann wrote:
> The debian/copyright needs some more
> changes. Search the upstream import commit for newly added copyright lines
> and new license texts.

I very carefully looked though all the files in the source and the output of 
licensecheck to 
create the copyright file.  If you compare it to the copyright file from 
4.0.9-1 you will see 
that it is much improved and fixes many inaccuracies that existed in the 
4.0.9-1 Debian 
package.  I am fairly sure that the current copyright file is comprehensively 
correct, but feel 
free to point out anything I have missed.


On a different topic, I see that you replaced the included distutils with the 
Debian system 
one.  Thank you for doing that.  (I created an MR that updates debian/copyright 
to include 
your copyright on that patch.)

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


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

Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client

[Soren Stoutner]

On Tuesday, October 18, 2022 1:41:51 PM MST Bastian Germann wrote:
> Okay, those tests can fail. Still there is some stuff to do on the package:
> Please fix the reprotest at
> https://salsa.debian.org/cryptocoin-team/electrum/-/jobs/3398402, which
> used to passed

Do you know why this is failing?  The applicable line appears to be:

Binary files 
/builds/cryptocoin-team/electrum/debian/output/reprotest/control/source-root/
python3-electrum_4.3.2+ds1-1+salsaci_all.deb and 
/builds/cryptocoin-team/electrum/
debian/output/reprotest/experiment-1/source-root/python3-
electrum_4.3.2+ds1-1+salsaci_all.deb differ

However, I can’t see any indication *why* they differ.  I assume that is is 
building it in two 
ways and comparing the output, but I don’t understand what the difference 
between those 
two build environments are or why they are producing different output.

> , and the lintian errors at
> https://salsa.debian.org/cryptocoin-team/electrum/-/jobs/3398403:
> 
> E: electrum source: source-is-missing [electrum/www/jquery-3.4.1.min.js]
> E: electrum source: source-is-missing [electrum/www/jquery-ui.min.js]
> E: electrum source: source-is-missing [electrum/www/qrcode.js]
>
> If the sources of these minified js files are included in the source tree,
> add a lintian override with a comment where it is. Else, please add the
> source to debian/missing-sources/. Extra points for replacing the files
> with the versions from Debian packages (if possible).

These same Lintian errors exist in the current 4.0.9-1 package.

https://udd.debian.org/lintian/?packages=electrum[1]

In preparing the 4.3.2 update I fixed all the Lintian errors that were directly 
related to the 
update as well as any of the low-hanging Lintian errors that did not require 
invasive 
changes to the package.  My goal was to make contact with, Tristan Seligmann, 
the 
package maintainer and also coordinate with upstream about the best way to 
remove 
these files, instead using the jQuery that is included with Debian.

If I am not able to contact Tristan Seligmann I plan on creating a future 
upload that does 
this work anyway, perhaps becoming the package maintainer myself.  I also, at 
the same 
time, plan to make other more invasive package changes, like replacing the 
embedded 
version of Kivy with the Debian-packaged one and replacing the fonts that ship 
within the 
python3-electrum package with those in their respective Debian packages.

Because this Lintian error existed in the previous packages and because it does 
not relate 
the RC bug that this upload is attempting to fix I was planning to wait for a 
future release to 
fix it.  Do you think it would be best to deal with it now without input from 
Tristan 
Seligmann?
 
> I reviewed your changes. Please do not introduce a compat file on packages
> that already use debhelper-compat. 

Thanks for catching that.  I went to fix it in the Git repository, but I see 
you have already 
done so.

> The debian/copyright needs some more
> changes. Search the upstream import commit for newly added copyright lines
> and new license texts.


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

Bug#1022023: xrdp: FTBFS on hppa - test timeout

[John David Anglin]

Source: xrdp
Version: 0.9.19-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

See:
https://buildd.debian.org/status/fetch.php?pkg=xrdp=hppa=0.9.19-1%2Bb2=1665886290=0
https://buildd.debian.org/status/fetch.php?pkg=xrdp=hppa=0.9.19-1%2Bb2=1665932047=0
https://buildd.debian.org/status/fetch.php?pkg=xrdp=hppa=0.9.19-1%2Bb2=1666130404=0

Seems similar to the issue reported for armhf.

Probably can be fixed by increasing the timeout value.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.16+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1021922: console-setup: FTBFS make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA16.psf] Error 2

[Michael Biebl]

Am 18.10.22 um 17:23 schrieb Samuel Thibault:

Control: severity -1 important

Hello,

Michael Biebl, le lun. 17 oct. 2022 13:53:44 +0200, a ecrit:

Source: console-setup
Version: 1.210
Tags: ftbfs


1.210 does actually build, it's +binnmu1 that doesn't, because + in the
build path gets confused with file assembly on the command line:


umask 022; /<>/Fonts/bdf2psf --log /<>/Fonts/Arabic-Fixed15.log  
/<>/Fonts/bdf/9x15-IL2.bdf+/<>/Fonts/bdf/9x15.bdf+/<>/Fonts/bdf/9x15c.bdf  
/<>/Fonts/standard.equivalents \


Ah, interesting.


I have now uploaded 1.211, which will thus fulfill your NMU need, and be
able to propagate. Leaving this bug as important open since +something
uploads are an important thing to support.


nod

Thanks for the upload, Samuel!


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021999: ftp.debian.org: update lintian to backports version

[Sean Whitton]

Hello,

On Tue 18 Oct 2022 at 07:23PM +02, Andreas Beckmann wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Hi,
>
> please update lintian on ftp-master to the version from backports. The
> currently used version from stable does not understand the current
> overrides format (especially file names are now often encloded in []),
> causing overrides for autoreject tags to be ignored and uploads to NEW
> getting autorejected, e.g.

I believe this is a DSA matter.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1022022: New btusb hardware IDs (MT7922, MT7921, others)

[Diederik de Haas]

On dinsdag 18 oktober 2022 23:44:17 CEST Chris Hofstaedtler wrote:
> it appears quite some new btusb hardware was released recently.
> linux-next has a lot of simple "Add xyz ID" patches for btusb.c:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/driv
> ers/bluetooth/btusb.c
> 
> Please consider applying 57117d7234dadfba2a83615b2a9369f6f2f9914f
> and/or the other patches adding new hwids to btusb.c for the
> bookworm kernel.

It's already part of Linux 6.1-rc1 and it is expected that 6.1 will be the
next LTS release and I'd guess thus also the Bookworm kernel.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/bluetooth?h=v6.1-rc1

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

Bug#1021839: info -w is slow for man pages

[Hilmar Preuße]

Control: tags -1 + fixed-upstream

Am 15.10.2022 um 19:14 teilte Jakub Wilk mit:

Package: info
Version: 6.8-6

I noticed that "info -w" is puzzlingly slow when the argument is a man 
page:



This has been solved/implemented in two git commits:

commit ef2eb3589883dc6ced661e424f0e11bee05cc83b
Author: Gavin Smith 
Date:   Tue Oct 18 11:31:53 2022 +0100

* info/man.c (check_manpage_node):
Call get_manpage_node if exit status from man -w PAGE was 2.


commit 8520d2b4d80eebe49ed44f11c47901f87d35c29f
Author: Gavin Smith 
Date:   Sun Oct 16 14:21:32 2022 +0100

Check for man page with 'man -w'

* info/man.c (check_manpage_node): New function, to check if
man page exists with 'man -w'.  This is much faster for large
man pages.
(find_man_formatter): Cache return value.
* info/info.c (get_initial_file): Use check_manpage_node instead
of get_manpage_node.

'info -w ffmpeg-all' was reported to be slow by Hilmar Preusse.
'ffmpeg-all' is an especially long man page, so takes a longer time
for nroff to format.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021823: info: memory exhausted for python3.10.info

[Hilmar Preuße]

Control: tags -1 + fixed-upstream

Am 15.10.2022 um 15:32 teilte Jakub Wilk mit:


info runs out of memory when trying to dump python3.10 docs on stdout:

    $ dpkg-query -W python3.10-doc
    python3.10-doc    3.10.7-2

    $ info python3.10 > /dev/null
    info: memory exhausted


commit f7e8f926d74c9dda4c4bf350a407f4d9448c4d98
Author: Gavin Smith 
Date:   Tue Oct 18 12:42:16 2022 +0100

More efficient subnode dumping

* info/session.c (dump_node_to_stream): Take a FILE_BUFFER *
argument rather than a filename.  Only get nodes from this file
buffer, using info_get_node_of_file_buffer.  This avoids looking
for the file for every node when dumping subnodes.
(dump_nodes_to_file): Call info_find_file before calling
dump_node_to_stream.

Hilmar Preusse reported that "info python3.8 >/dev/null" had
extremely high memory usage.  python3.8.info.gz was over 4MB
in size, and had more than 4500 nodes.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022022: New btusb hardware IDs (MT7922, MT7921, others)

[Chris Hofstaedtler]

Source: linux
Version: 5.19.11-1

Hi,

it appears quite some new btusb hardware was released recently.
linux-next has a lot of simple "Add xyz ID" patches for btusb.c:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/bluetooth/btusb.c

Personally I have an Asus PN52 mini PC, with an MT7922 wifi/bt card.
It sports this hwid:
Bus 005 Device 003: ID 0489:e0e2 Foxconn / Hon Hai Wireless_Device
  idVendor   0x0489 Foxconn / Hon Hai
  idProduct  0xe0e2
  bcdDevice1.00
  iManufacturer   5 MediaTek Inc.
  iProduct6 Wireless_Device

I'll try applying 57117d7234dadfba2a83615b2a9369f6f2f9914f on top of
5.19.11-1 and report if that works, but I would expect it to.

Please consider applying 57117d7234dadfba2a83615b2a9369f6f2f9914f
and/or the other patches adding new hwids to btusb.c for the
bookworm kernel.

Thanks,
Chris

Bug#1022021: lirc: Uses deprecated yaml.load in python-pkg

[Gordon Ball]

Source: lirc
Version: 0.10.1-7
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


It appears to be used in python-pkg/lirc/database.py and
tools/check_config.py. The former gets installed in the `lirc` binary
package.


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

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

Bug#1022020: lecm: Uses deprecated yaml.load

[Gordon Ball]

Source: lecm
Version: 0.0.9-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


yaml.load is used to load config in
https://sources.debian.org/src/lecm/0.0.9-1/lecm/configuration.py/?hl=71#L71


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

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

Bug#1021879: rust-kamadak-exif: please upgrade to v0.5.4

[Peter Green]

Please upgrade to newer major upstream release v0.5.4, needed by
packages I am preparing.


The new version of rust-kamadak-exif depends on the mutate_once
crate which is not currently in Debian. Nor can I find any evidence
that anyone is currently working on packaging it for Debian.

Bug#1022019: labgrid: Uses deprecated yaml.load

[Gordon Ball]

Source: labgrid
Version: 0.4.1-4
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


Most call sites in labgrid appear to be fixed, but there appears to be
one remaining use of yaml.load in remote/coordinator, assuming that is
still live code:
https://sources.debian.org/src/labgrid/0.4.1-4/labgrid/remote/coordinator.py/?hl=309#L309


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

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

Bug#1021737: lava: CVE-2022-42902

[Antonio Terceiro]

Hi,

On Thu, Oct 13, 2022 at 09:13:18PM +0200, Moritz Mühlenhoff wrote:
> Source: lava
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for lava.
> 
> CVE-2022-42902[0]:
> | In Linaro Automated Validation Architecture (LAVA) before 2022.10,
> | there is dynamic code execution in lava_server/lavatable.py. Due to
> | improper input sanitization, an anonymous user can force the lava-
> | server-gunicorn service to execute user-provided code on the server.
> 
> https://git.lavasoftware.org/lava/lava/-/merge_requests/1834
> https://git.lavasoftware.org/lava/lava/-/commit/e66b74cd6c175ff8826b8f3431740963be228b52?merge_request_iid=1834
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2022-42902
> https://www.cve.org/CVERecord?id=CVE-2022-42902
> 
> Please adjust the affected versions in the BTS as needed.

I have uploaded a fix version to unstable (latest upstream), and I would
like to upload the attached debdiff to -security. That package builds
cleanly and passes its autopkgtest on bullseye. Let me know.

I'm also attaching the 2 patches included directly, since they are
easier to read than the diff-in-diff. The main patch for the security
issue is exactly the one that was applied upstream.
From e66b74cd6c175ff8826b8f3431740963be228b52 Mon Sep 17 00:00:00 2001
From: Igor Ponomarev 
Date: Mon, 26 Sep 2022 18:51:47 +0300
Subject: [PATCH] Replace dynamic code execution in lava_server/lavatable.py

`exec` was used to create query parameters for the tables searches.
`exec` is extremely dangerous and can lead to remote code execution.
It is also very slow.
The new implementation is equivalent in function but uses
dictionaries and unpacking to create arguments.
---
 lava_server/lavatable.py | 76 ++--
 1 file changed, 26 insertions(+), 50 deletions(-)

--- a/lava_server/lavatable.py
+++ b/lava_server/lavatable.py
@@ -41,8 +41,6 @@ class LavaView(tables.SingleTableView):
 """
 bespoke time-based field handling
 """
-local_namespace = locals()
-local_namespace["q"] = query
 time_queries = {}
 if hasattr(self.table_class.Meta, "times"):
 # filter the possible list by the request
@@ -50,26 +48,20 @@ class LavaView(tables.SingleTableView):
 # check if the request includes the current time filter & get the value
 match = self.request.GET.get(key)
 if match and match != "":
-self.terms[key] = "%s within %s %s" % (
-key,
-match,
-value,
-)  # the label for this query in the search list
+self.terms[key] = f"{key} within {match} {value}"
+# the label for this query in the search list
 time_queries[key] = value
 for key, value in time_queries.items():
 match = escape(self.request.GET.get(key))
 # escape converts None into u'None'
 if not match or match == "" or match == "None":
 continue
-args = "q = q.__and__(Q({0}__gte=timezone.now()-timedelta({1}={2})))".format(
-key, value, match
+
+query &= Q(
+**{f"{key}__gte": timezone.now() - timedelta(**{value: int(match)})}
 )
-try:
-exec(args, globals(), local_namespace)  # sets the value of q
-except SyntaxError:
-# should log the exception somewhere...
-continue  # just skip this term - results in a query matching All.
-return local_namespace["q"]
+
+return query
 
 def get_table_data(self, prefix=None):
 """
@@ -145,60 +137,44 @@ class LavaView(tables.SingleTableView):
 if not self.request:
 return data
 
-local_namespace = locals()
-local_namespace["q"] = Q()
+q = Q()
 self.terms = {}
 # discrete searches
 for key, val in distinct.items():
 if key in self.table_class.Meta.searches:
-args = 'q = q.__and__(Q({0}__contains="{1}"))'.format(key, val)
-try:
-exec(args, globals(), local_namespace)  # sets the value of q
-except SyntaxError:
-# should log exception somewhere...
-continue  # just skip this term - results in a query matching All.
+q &= Q(**{f"{key}__contains": val})
+
 if (
 hasattr(self.table_class.Meta, "queries")
 and key in self.table_class.Meta.queries.keys()
 

Bug#1022018: ganeti: Uses deprecated yaml.load

[Gordon Ball]

Source: ganeti
Version: 3.0.2-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


This is used in the tests: test/py/ganeti.cli_unittest.py; this causes
autopkgtest failure against the version of pyyaml in experimental. I
don't think it breaks anything outside the test suite however.

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

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

Bug#1022016: etm: Uses deprecated yaml.load

[Gordon Ball]

Package: etm
Version: 3.2.30-4
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.

Found in `etmTk/data.py` in several places.

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

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

Versions of packages etm depends on:
ii  python33.10.6-1
ii  python3-dateutil   2.8.2-1
pn  python3-icalendar  
ii  python3-tk 3.10.7-1
ii  python3-tz 2022.4-1
ii  python3-yaml   5.4.1-1+b2

Versions of packages etm recommends:
pn  mercurial  

etm suggests no packages.

Bug#1021977: Fwd: Tzdata timezone files corruption after clean debian 11 installation

[Satish Binda]

Thank you for the clarification.

On Tue, Oct 18, 2022, 22:24 Aurelien Jarno  wrote:

> Dear Satish,
>
> On 2022-10-18 22:17, Satish Binda wrote:
> > because normally it is just one line ascii or ansi or utf-8, perhaps
> utf-16
> > but not an easy to digest binary file, at length, that no one knows about
>
> That is not correct. The file format is described by RFC8536 [1] and is
> a binary format.
>
> Regards
> Aurelien
>
> [1] https://datatracker.ietf.org/doc/html/rfc8536
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>

Bug#1022015: elasticsearch-curator: Uses deprecated yaml.load

[Gordon Ball]

Source: elasticsearch-curator
Version: 5.8.1-4
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


Found at least in curator/utils.py
(https://sources.debian.org/src/elasticsearch-curator/5.8.1-4/curator/utils.py/?hl=53#L53)
 


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

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

Bug#933574: chicken: FTBFS on hppa - stack exhausted running csi

[John David Anglin]

Dear Maintainer,

The stack overflows because the stack is incorrectly configured to
grow downward when in fact the stack on hppa grows upward.  When this
is fixed, build is successful:
https://buildd.debian.org/status/fetch.php?pkg=chicken=hppa=5.3.0-1=1666123017=0

Please push fix upstream and install patch if needed.

Thanks,
Dave Anglin

Index: chicken-5.3.0/Makefile.linux
===
--- chicken-5.3.0.orig/Makefile.linux
+++ chicken-5.3.0/Makefile.linux
@@ -94,7 +94,11 @@ chicken-config.h: chicken-defaults.h
 	echo "#define HAVE_ALLOCA_H 1" >>$@
 	echo "#define HAVE_ERRNO_H 1" >>$@
 	echo "#define HAVE_SYSEXITS_H 1" >>$@
+ifeq ($(ARCH),hppa)
+	echo "#define C_STACK_GROWS_DOWNWARD 0" >>$@
+else
 	echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@
+endif
 ifdef GCHOOKS
 	echo "#define C_GC_HOOKS" >>$@
 endif
Index: chicken-5.3.0/config-arch.sh
===
--- chicken-5.3.0.orig/config-arch.sh
+++ chicken-5.3.0/config-arch.sh
@@ -34,6 +34,7 @@ case "`uname -m`" in
 	*) echo "ppc.sysv";;
 	esac;;
 amd64|x86_64) echo "x86-64";;
+parisc*) echo "hppa";;
 riscv*) echo "riscv";;
 *) ;;
 esac


signature.asc
Description: PGP signature

Bug#1018255: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts

[Ben Westover]

Bonjour Jérémy,

On 10/18/22 4:24 PM, Jérémy Lal wrote:
>   > It seems that Lenny McLennigton, the main person behind upstream
>   went rouge in a way that is difficult
>   > to be aligned with Debian values (and CoC), as shown by their
>   response on [twitter].
>
> Where in Debian is it stated that an open source project has to have a
> Code of Conduct to be part of Debian ?

I think he was saying the project doesn't align very well with the
*Debian* Code of Conduct (https://debian.org/code_of_conduct).

> I don't understand why the drama happening between upstream
> project maintainers should concern Debian directly.

To me the main issue is the fact that a known hostile entity has sole
control over the meta severs that PolyMC interfaces with to download and
execute arbitrary code, also potentially leaking personal information. I
don't feel comfortable having that on my system, and I think most Debian
users would agree. I don't at the moment want to support this current
upstream by uploading their potentially hazardous package into Debian.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1012950: [Debian-med-packaging] Bug#1012950: insighttoolkit4: ftbfs with GCC-12

[Étienne Mollier]

Hi Simon,

Simon Chopin, on 2022-10-17:
> For information, we've tried using the following patch on Ubuntu:
> 
> https://github.com/InsightSoftwareConsortium/ITK/commit/b6d3d5066d939b90fff7d642adf46f5ab4136876

Thanks for the follow-up, there is a commit[1a,1b] in the
itk-4.y branch which works around the same issues with a
different mean.

[1a]: 
https://salsa.debian.org/med-team/insighttoolkit/-/commit/b228aa8992f6cc0c40c3b5266b54fb488f5fa03c
[1b]: 
https://salsa.debian.org/med-team/insighttoolkit/-/commit/9c720b1eab3fa22399aee9a9dba0bebca4c804a5

but:
> This did fix the compilation, but then the tests started to fail. I
> actually ended up forcing the compilation with gcc-11 to get the
> package building again.

Same here, that's why there hasn't been an upload yet.  Given
that itk4 is out of maintenance upstream, maybe sticking to
older compiler level is a lesser evil if it helps keeping
reverse dependencies that have still not migrated to itk5.
gcc-11 is still in bookworm as far as I could witness, but I
believe it ought to be phased out before the release.  I'm
unsure it is a good idea to forcefully pull it.

Any ways, thanks for the heads up,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.
On air: Curved Air - Over And Above


signature.asc
Description: PGP signature

Bug#1022014: ceph: Uses deprecated yaml.load

[Gordon Ball]

Source: ceph
Version: 16.2.10+ds-3
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


The only place I found this in the ceph source is in a test:

https://sources.debian.org/src/ceph/16.2.10+ds-3/src/test/crimson/cbt/t2c.py/?hl=46#L46

This doesn't look like it's installed in any of the binaries, but
perhaps it can be hit during build?


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

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

Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client

[Bastian Germann]

Okay, those tests can fail. Still there is some stuff to do on the package:
Please fix the reprotest at 
https://salsa.debian.org/cryptocoin-team/electrum/-/jobs/3398402, which used to 
passed,
and the lintian errors at 
https://salsa.debian.org/cryptocoin-team/electrum/-/jobs/3398403:

E: electrum source: source-is-missing [electrum/www/jquery-3.4.1.min.js]
E: electrum source: source-is-missing [electrum/www/jquery-ui.min.js]
E: electrum source: source-is-missing [electrum/www/qrcode.js]

If the sources of these minified js files are included in the source tree, add a lintian override with a comment where 
it is. Else, please add the source to debian/missing-sources/. Extra points for replacing the files with the versions 
from Debian packages (if possible).


I reviewed your changes. Please do not introduce a compat file on packages that 
already use debhelper-compat.
The debian/copyright needs some more changes. Search the upstream import commit for newly added copyright lines and new 
license texts.

Bug#1022013: ansible: Uses deprecated yaml.load (in community plugin only)

[Gordon Ball]

Source: ansible
Version: 6.4.0+dfsg-1
Severity: minor
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.

I could only find this usage in the community VDO plugin, not the core,
hence `minor`:
https://sources.debian.org/src/ansible/6.4.0+dfsg-1/ansible_collections/community/general/plugins/modules/system/vdo.py/?hl=551#L551


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

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

Bug#1021668: [Pkg-xen-devel] Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746

[Moritz Muehlenhoff]

On Tue, Oct 18, 2022 at 02:17:32PM +0200, Hans van Kranenburg wrote:
> Does explicitly opening a BTS bug mean that, like we use to call it,
> "these CVEs warrant a DSA",

No, in general we aim to file bugs for any open CVEs regardless of
the DSA state. This allows people to see that an issue is known
(and some maintainers might also not have noticed in time).

> and that it is a request for an ASAP package
> update and preparing a security update for stable, or, is this a new
> thing where BTS bugs are opened for packages, just in case the
> maintainer did not already track security issues themselves actively?

For the latest set of Xen issues my estimate is that we can postpone
them until the next batch, they seem all of moderate/limited impact.
But let me know if you think otherwise.

Cheers,
Moritz

Bug#883126: darkice cannot connect to IPv6 icecast server

[Kevin Otte]

This PR has been merged. Unknown when a new release might be made.

On Fri, 29 Jan 2021 12:07:24 -0500 Kevin Otte  wrote:

I finally had a chance to chase this down and filed the issue upstream:
https://github.com/rafael2k/darkice/issues/166

I have also submitted a PR to try and fix the issue:
https://github.com/rafael2k/darkice/pull/167

Bug#1021977: Fwd: Tzdata timezone files corruption after clean debian 11 installation

[Aurelien Jarno]

Dear Satish,

On 2022-10-18 22:17, Satish Binda wrote:
> because normally it is just one line ascii or ansi or utf-8, perhaps utf-16
> but not an easy to digest binary file, at length, that no one knows about

That is not correct. The file format is described by RFC8536 [1] and is
a binary format.

Regards
Aurelien

[1] https://datatracker.ietf.org/doc/html/rfc8536

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

Bug#1021840: mention borg compact in NEWS.Debian

[Gianfranco Costamagna]

Hello, patch please?

G.






Il sabato 15 ottobre 2022 20:51:18 CEST, Joey Hess  ha 
scritto: 





Package: borgbackup
Version: 1.2.2-2
Severity: wishlist

borg compact is needed to actually free up pruned space, which was not
the case with the version in stable. I noticed this only after my backup
disk overflowed, and I think that having a mention of it in NEWS.Debian
might have made me aware of it earlier.

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 borgbackup depends on:
ii  libacl1                2.3.1-1
ii  libc6                  2.35-3
ii  liblz4-1              1.9.4-1
ii  libssl3                3.0.5-4
ii  libxxhash0            0.8.1-1
ii  libzstd1              1.5.2+dfsg-1
ii  python3                3.10.6-1
ii  python3-msgpack        1.0.3-1+b1
ii  python3-packaging      21.3-1.1
ii  python3-pkg-resources  65.3.0-1.1

Versions of packages borgbackup recommends:
ii  fuse3 [fuse]    3.11.0-1
ii  python3-llfuse  1.4.1+dfsg-2+b1
ii  python3-pyfuse3  3.2.1-1+b1

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1018255: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts

[Jérémy Lal]

Le mar. 18 oct. 2022 à 21:57, Ben Westover  a écrit :

> Hello,
>
> On Tue, 18 Oct 2022 11:03:09 +0200 Tobias Frost  wrote:
> > There is currently some drama envoling with upstream, possibly this
> RFS/ITP should be put on hold
> > until it is resolved (or maybe switched to one the forks that are
> currently materializing [fork])
> >
> > It seems that Lenny McLennigton, the main person behind upstream went
> rouge in a way that is difficult
> > to be aligned with Debian values (and CoC), as shown by their response
> on [twitter].
>

Where in Debian is it stated that an open source project has to have a Code
of Conduct to be part of Debian ?
I don't understand why the drama happening between upstream
project maintainers should concern Debian directly.

Jérémy

Bug#1021987: evolution segfault

[Andy Mann]

Package: evolution
Version: 3.46.0-2
Severity: important

UPDATE:
There is also this warning in .xsession-errors:

(evolution:40745): Gtk-WARNING **: 20:50:22.852: Calling
org.xfce.Session.Manager.Inhibit failed:
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method “Inhibit”

Launch GNOME service on startup is enabled in xfce settings.

Bug#861615: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts

[Ben Westover]

Hello,

On Tue, 18 Oct 2022 11:03:09 +0200 Tobias Frost  wrote:
> There is currently some drama envoling with upstream, possibly this RFS/ITP 
> should be put on hold
> until it is resolved (or maybe switched to one the forks that are currently 
> materializing [fork])
>
> It seems that Lenny McLennigton, the main person behind upstream went rouge 
> in a way that is difficult
> to be aligned with Debian values (and CoC), as shown by their response on 
> [twitter].

Disgusting. The moment I think I've found the perfect MultiMC fork with
a thriving community and friendly upstream, the guy who set it up (and
actually doesn't contribute all that much) turns out to be one of
*those* people tarnishing our community, and ruins this work. I was
suspicious of him right off the bat with the "sneed.church" email (some
sort of 4chan cult, see [sneedacity] nightmare).

For now I will remove my package from Mentors but keep the RFS/ITP open
in hope that this issue is resolved in the near future.

--
Ben Westover

[sneedacity] https://github.com/tenacityteam/tenacity/issues/99


OpenPGP_signature
Description: PGP signature

Bug#1018255: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts

[Ben Westover]

Hello,

On Tue, 18 Oct 2022 11:03:09 +0200 Tobias Frost  wrote:
> There is currently some drama envoling with upstream, possibly this RFS/ITP 
> should be put on hold
> until it is resolved (or maybe switched to one the forks that are currently 
> materializing [fork])
>
> It seems that Lenny McLennigton, the main person behind upstream went rouge 
> in a way that is difficult
> to be aligned with Debian values (and CoC), as shown by their response on 
> [twitter].

Disgusting. The moment I think I've found the perfect MultiMC fork with
a thriving community and friendly upstream, the guy who set it up (and
actually doesn't contribute all that much) turns out to be one of
*those* people tarnishing our community, and ruins this work. I was
suspicious of him right off the bat with the "sneed.church" email (some
sort of 4chan cult, see [sneedacity] nightmare).

For now I will remove my package from Mentors but keep the RFS/ITP open
in hope that this issue is resolved in the near future.

--
Ben Westover

[sneedacity] https://github.com/tenacityteam/tenacity/issues/99


OpenPGP_signature
Description: PGP signature

Bug#1022012: O: magit-annex -- git-annex subcommands for magit

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:magit-annex

I intend to orphan the magit-annex package.

This package is no longer in my ~/.emacs.d/init.el and it would be
better if someone who actually uses the package maintains it.  This is a
team-maintained package, so the adoptor should either replace me in
Uploaders:, or alternatively take the package out of the team's hands.

The package description is:
 This package adds some git-annex subcommands to magit's interface,
 under the '@' prefix key.  See the descriptions of the git-annex and
 elpa-magit packages.
 .
 Some examples of operations supported by this package:
 .
   * adding untracked files with `git annex add`
   * displaying information about unused files listed by `git annex unused`
   * locking and unlocking files.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1022011: dleyna-server: transition to gssdp/gupnp 1.6.0

[Andreas Henriksson]

Package: dleyna-server
Version: 0.7.2-1
Severity: normal
Tags: fixed-upstream

Dear (non-existant) Maintainer,

New upstream releases of gssdp and gupnp 1.6.0 has broken the ABI
and thus bumped the SONAME. A transition is needed.
The new versions are currently stuck in binary-NEW but should hopefully
soon be available in experimental (you can `gbp clone vcsgit:gssdp`,
`gbp clone vcsgit:gupnp` and build them yourself for now if you wish).

Please consider uploading a version of dleyna-server to experimental
that is compatible with the new SONAMEs.
The relevant upstream commit is:
https://github.com/phako/dleyna-server/commit/e7f64192643f5783e19482a11697d

The relevant bug report for coordinating the transition is #1022003

Regards,
Andreas Henriksson

Bug#1022010: dleyna-renderer: transition to gssdp/gupnp 1.6.0

[Andreas Henriksson]

Package: dleyna-renderer
Version: 0.7.2-1
Severity: normal
Tags: fixed-upstream

Dear (non-existant) Maintainer,

New upstream releases of gssdp and gupnp 1.6.0 has broken the ABI
and thus bumped the SONAME. A transition is needed.
The new versions are currently stuck in binary-NEW but should hopefully
soon be available in experimental (you can `gbp clone vcsgit:gssdp`,
`gbp clone vcsgit:gupnp` and build them yourself for now if you wish).

Please consider uploading a version of dleyna-renderer to experimental
that is compatible with the new SONAMEs.
The relevant upstream commit is:
https://github.com/phako/dleyna-renderer/commit/b3a06c8bc4b91803d7bde312f49a6

The relevant bug report for coordinating the transition is #1022003

Regards,
Andreas Henriksson

Bug#1022009: dleyna-core: transition to gssdp/gupnp 1.6.0

[Andreas Henriksson]

Source: dleyna-core
Version: 0.7.0-1
Severity: normal
Tags: fixed-upstream

Dear (non-existant) Maintainer,

New upstream releases of gssdp and gupnp 1.6.0 has broken the ABI
and thus bumped the SONAME. A transition is needed.
The new versions are currently stuck in binary-NEW but should hopefully
soon be available in experimental (you can `gbp clone vcsgit:gssdp`,
`gbp clone vcsgit:gupnp` and build them yourself for now if you wish).

Please consider uploading a version of dleyna-core to experimental
that is compatible with the new SONAMEs.
The relevant upstream commit is:
https://github.com/phako/dleyna-core/commit/b88f231affc697be813d7c77c17e3130df8

The relevant bug report for coordinating the transition is #1022003

Regards,
Andreas Henriksson

Bug#1022008: librm: transition to gssdp/gupnp 1.6

[Andreas Henriksson]

Source: librm
Version: 2.2.3-1
Severity: normal
Tags: fixed-upstream

Dear Maintainer,

New upstream releases of gssdp and gupnp 1.6.0 has broken the ABI
and thus bumped the SONAME. A transition is needed.
The new versions are currently stuck in binary-NEW but should hopefully
soon be available in experimental (you can `gbp clone vcsgit:gssdp`,
`gbp clone vcsgit:gupnp` and build them yourself for now if you wish).

Please consider uploading a version of librm to experimental that is
compatible with the new SONAMEs.
The relevant upstream commits to cherry-pick are:
https://gitlab.com/tabos/librm/-/commit/c9aae663ff40c1ab171476652eba68c174d96
https://gitlab.com/tabos/librm/-/commit/a849d9a6a6624d5f3c6a70dd63590d1a2b79d

The relevant bug report for coordinating the transition is #1022003

Unless I've heard from you before the release-team gives the go-ahead
I'll assume you prefer me NMU as needed.

Regards,
Andreas Henriksson

Bug#1022007: caja-extensions: transition to gssdp/gupnp 1.6

[Andreas Henriksson]

Source: caja-extensions
Version: 1.26.1-1
Severity: normal
Tags: fixed-upstream

Dear Maintainer,

New upstream releases of gssdp and gupnp 1.6.0 has broken the ABI
and thus bumped the SONAME. A transition is needed.
The new versions are currently stuck in binary-NEW but should hopefully
soon be available in experimental (you can `gbp clone vcsgit:gssdp`,
`gbp clone vcsgit:gupnp` and build them yourself for now if you wish).

Please consider uploading a version of caja-extensions to experimental
that is compatible with the new SONAMEs.
This upstream issue includes a suggested solution:
https://github.com/mate-desktop/caja-extensions/issues/110#issuecomment-1115036764

The relevant bug report for coordinating the transition is #1022003

Unless I've heard from you before the release-team gives the go-ahead
I'll assume you prefer me NMU as needed.

Regards,
Andreas Henriksson

Bug#1022004: pyasn1 please drop pypy-pyasn1 to support python2.7 removal

[Paul Gevers]

Control: tags -1 pending patch

Hi,

On 18-10-2022 21:25, Paul Gevers wrote:
When 
done with preparation, I'll upload to DELAYED/5 and update this bug 
report with the debdiff.


See attachment. I checked the content of the two remaining packages with 
diffoscope against the versions in the archive and didn't see surprises 
(yes changes because of the newer version of sphinx).


Paul
diff -Nru pyasn1-0.4.8/debian/changelog pyasn1-0.4.8/debian/changelog
--- pyasn1-0.4.8/debian/changelog   2022-06-03 02:57:14.0 +0200
+++ pyasn1-0.4.8/debian/changelog   2022-10-18 21:27:43.0 +0200
@@ -1,3 +1,18 @@
+pyasn1 (0.4.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Debian Janitor ]
+  * Remove constraints unnecessary since buster:
++ python3-pyasn1: Drop versioned constraint on python3-pysnmp4 in Breaks.
++ python-pyasn1-doc: Drop versioned constraint on python-pyasn1 in 
Replaces.
++ python-pyasn1-doc: Drop versioned constraint on python-pyasn1 in Breaks.
+
+  [ Paul Gevers ]
+  * Stop building pypy-pyasn1 (Closes: 1022004)
+
+ -- Paul Gevers   Tue, 18 Oct 2022 21:27:43 +0200
+
 pyasn1 (0.4.8-2) unstable; urgency=low
 
   [ Debian Janitor ]
diff -Nru pyasn1-0.4.8/debian/control pyasn1-0.4.8/debian/control
--- pyasn1-0.4.8/debian/control 2022-06-03 02:57:14.0 +0200
+++ pyasn1-0.4.8/debian/control 2022-10-18 21:27:43.0 +0200
@@ -11,10 +11,9 @@
 Build-Depends:
  debhelper-compat (= 13),
  dh-python,
- pypy,
  python3-all,
  python3-sphinx,
-Build-Depends-Indep: pypy-setuptools, python3-setuptools
+Build-Depends-Indep: python3-setuptools
 Rules-Requires-Root: no
 Homepage: http://snmplabs.com/pyasn1/index.html
 Vcs-Git: https://salsa.debian.org/python-team/packages/pyasn1.git
@@ -24,7 +23,6 @@
 Package: python3-pyasn1
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
-Breaks: python3-pysnmp4 (<< 4.3.4)
 Description: ASN.1 library for Python (Python 3 module)
  This  is  an implementation  of  ASN.1  types  and codecs  in  Python
  programming language. It has been first written to support particular
@@ -33,24 +31,11 @@
  .
  This package contains the Python 3 module.
 
-Package: pypy-pyasn1
-Architecture: all
-Depends: ${misc:Depends}, ${pypy:Depends}
-Description: ASN.1 library for Python (PyPy module)
- This  is  an implementation  of  ASN.1  types  and codecs  in  Python
- programming language. It has been first written to support particular
- protocol (SNMP) but then generalized  to be suitable for a wide range
- of protocols based on ASN.1 specification.
- .
- This package contains the PyPy module.
-
 Package: python-pyasn1-doc
 Section: doc
 Architecture: all
 Depends: ${misc:Depends}, ${sphinxdoc:Depends}
-Replaces: python-pyasn1 (<< 0.4.2-1)
 Built-Using: ${sphinxdoc:Built-Using}
-Breaks: python-pyasn1 (<< 0.4.2-1)
 Suggests: doc-base
 Multi-Arch: foreign
 Description: ASN.1 library for Python (documentation)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022006: New version fixes a warning

[Bjarni Ingi Gislason]

Package: twm
Version: 1:1.0.10-1
Severity: normal

Dear Maintainer,

  a new version of "twm" (1.0.12) fixes following:

(II) [KMS] Kernel modesetting enabled.
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully
(0). Closing log file.
[ cut here ]
WARNING: CPU: 1 PID: 1877 at drivers/gpu/drm/ttm/ttm_bo.c:356
ttm_bo_release+0x30c/0x330 [ttm]
Modules linked in: nft_reject_ipv4 nf_reject_ipv4 nft_reject nft_ct
nf_log_syslog nft_log radeon drm_ttm_helper ttm drm_display_helper
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
CPU: 1 PID: 1877 Comm: Xorg Not tainted 6.0.2-1 #1
Hardware name: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./E350N WIN8, BIOS F3 01/18/2013
RIP: 0010:ttm_bo_release+0x30c/0x330 [ttm]
Code: 00 e8 88 96 39 e1 48 8b 43 e8 eb a7 be 03 00 00 00 e8 18 b1 23 e1
e9 f7 fd ff ff e8 0e 74 39 e1 e9 ed fd ff ff 4c 89 e0 eb 89 <0f> 0b 48
83 7b 20 00 0f 84 27 fd ff ff 0f 0b e9 20 fd ff ff 0f 0b
RSP: 0018:c95abd98 EFLAGS: 00010202
RAX:  RBX: 888100f655c8 RCX: 
RDX: 0002 RSI: 81da8c49 RDI: 888100f655c8
RBP: 888100f65478 R08: 0064 R09: 88810078e960
R10: c95abe68 R11: 0001 R12: 888100f5c6f0
R13: 88810006c7a0 R14: 8881007c6f00 R15: 888104a306d8
FS:  7f9f64a09a80() GS:88813c30()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f9f64a77008 CR3: 0200c000 CR4: 06e0
Call Trace:
 
 ? fsnotify_grab_connector+0x3e/0x70
 radeon_bo_unref+0x15/0x30 [radeon]
 radeon_gem_object_free+0x2b/0x50 [radeon]
 drm_gem_dmabuf_release+0x31/0x50
 dma_buf_release+0x35/0x90
 __dentry_kill+0xf0/0x160
 __fput+0xd3/0x240
 task_work_run+0x57/0x90
 do_exit+0x274/0x8d0
 do_group_exit+0x28/0x90
 __x64_sys_exit_group+0xf/0x10
 do_syscall_64+0x3a/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f9f644d6459
Code: Unable to access opcode bytes at RIP 0x7f9f644d642f.
RSP: 002b:7ffcdcc26a98 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX: 7f9f645f09e0 RCX: 7f9f644d6459
RDX: 003c RSI: 00e7 RDI: 
RBP:  R08: fc78 R09: 7f9f645fbb00
R10: 27c3fa55cc3ade70 R11: 0246 R12: 7f9f645f09e0
R13:  R14: 7f9f645f5ec8 R15: 7f9f645f5ee0
 
---[ end trace  ]---


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

Kernel: Linux 6.0.2-1 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages twm depends on:
ii  libc6 2.35-3
ii  libice6   2:1.0.10-1
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.8.1-2
ii  libxext6  2:1.3.4-1+b1
ii  libxmu6   2:1.1.3-3
ii  libxt61:1.2.1-1
ii  menu  2.1.49

twm recommends no packages.

twm suggests no packages.

-- no debconf information
-- 

Bug#1022005: RFS: swirc/3.3.6 [ITP] -- Curses ICB and IRC client

[Markus Uhlin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : swirc
   Version  : 3.3.6
   Upstream contact : Markus Uhlin 
 * URL  : https://www.nifty-networks.net/swirc/
 * License  : public-domain, MIT, ISC, BSD-3, OpenSSL
 * Vcs  : https://github.com/uhlin/swirc
   Section  : net

The source builds the following binary packages:

  swirc - Curses ICB and IRC client

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/s/swirc/swirc_3.3.6.dsc

Changes for the initial release:

 swirc (3.3.6) unstable; urgency=medium
 .
   * Initial import. (Closes: #1021993)

Regards,

Markus

Bug#1022003: transition: gssdp/gupnp 1.2->1.6 (+ rygel 0.42.0)

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2022-10-18 21:24:03 +0200, Andreas Henriksson wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello release team,
> 
> I'd like to transition gssdp/gupnp to 1.6 version as part of current
> GNOME release.
> 
> I've just uploaded the new versions of gssdp and gupnp 1.6.0 to
> binary-NEW/experimental.

Please remove the moreinfo tag once they cleared NEW.

Cheers

> 
> I will team-upload new releases of the following reverse dependencies as
> part of gnome-team:
> 
> * rygel (0.42.0-1 just uploaded to binary-NEW/experimental) 
>   - FYI internal soname bump for broken plugin ABI, but there are no
> external plugins (all built from src:rygel).
> * gupnp-tools (0.12.0-1 just uploaded to experimental)
> * gupnp-igd (needs cherry-pick 
> https://gitlab.gnome.org/GNOME/gupnp-igd/-/commit/79a1e4cf8c256132978a1d8ab718c8ad132386de
>  )
> 
> I've just done QA uploads to unstable for latest version of
> dleyna-{core,renderer,server} to make it easier to cherry-pick upstream
> changes for gssdp/gupnp 1.6 (not yet in a released version).
> I can do qa uploads of dleyna-* but would prefer if these packages where
> simply removed from testing as they've been orphaned for many years
> (since their initial upload to debian).
> Will file a bug for each package and point out the upstream commits
> respectively:
> * 
> https://github.com/phako/dleyna-core/commit/b88f231affc697be813d7c77c17e3130df81cb9a
> * 
> https://github.com/phako/dleyna-renderer/commit/b3a06c8bc4b91803d7bde312f49a68109b8ad8d4
> * 
> https://github.com/phako/dleyna-server/commit/e7f64192643f5783e19482a11697de9ec3eea033
> 
> I will file bugs for remaining (and offer to NMU if no response),
> fixed-upstream (not yet in a released version):
> 
> * caja-extensions -- 
> https://github.com/mate-desktop/caja-extensions/issues/110
> * librm -- 
> https://gitlab.com/tabos/librm/-/commit/c9aae663ff40c1ab171476652eba68c174d96ba2
>  + 
> https://gitlab.com/tabos/librm/-/commit/a849d9a6a6624d5f3c6a70dd63590d1a2b79d1af
> 
> 
> Regards,
> Andreas Henriksson
> 
> 
> PS. Once I've filed all bug reports I'll set them as blockers for this bug
> report.
> 
> 
> Ben file:
> 
> title = "gupnp";
> is_affected = .depends ~ "libgupnp-1.2-1" | .depends ~ "libgssdp-1.2-0" | 
> .depends ~ "libgupnp-1.6-0" | .depends ~ "libgssdp-1.6-0";
> is_good = .depends ~ "libgupnp-1.6-0" | .depends ~ "libgssdp-1.6-0";
> is_bad = .depends ~ "libgupnp-1.2-1" | .depends ~ "libgssdp-1.2-0";
> 

-- 
Sebastian Ramacher

Bug#1022004: pyasn1 please drop pypy-pyasn1 to support python2.7 removal

[Paul Gevers]

Source: pyasn1
Version: 0.4.8-2
Severity: serious
Justification: rt

Dear maintainers,

If I didn't make a mistake, pyasn1 is keeping pypy in the key
package set because it (Build-)Depends on it. Again, if I didn't make a
mistake, there are no reverse Build-Depends or Depends anymore of
pypy-pyasn1, so I think the package can just be dropped. That would be 
another step in the python2.7 removal transition.


I'll be preparing an NMU that does this after I submit this bug. When 
done with preparation, I'll upload to DELAYED/5 and update this bug 
report with the debdiff. Please let me know if you prefer to handle this 
by yourself and/or if I should cancel or delay the upload.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022003: transition: gssdp/gupnp 1.2->1.6 (+ rygel 0.42.0)

[Andreas Henriksson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello release team,

I'd like to transition gssdp/gupnp to 1.6 version as part of current
GNOME release.

I've just uploaded the new versions of gssdp and gupnp 1.6.0 to
binary-NEW/experimental.

I will team-upload new releases of the following reverse dependencies as
part of gnome-team:

* rygel (0.42.0-1 just uploaded to binary-NEW/experimental) 
  - FYI internal soname bump for broken plugin ABI, but there are no
external plugins (all built from src:rygel).
* gupnp-tools (0.12.0-1 just uploaded to experimental)
* gupnp-igd (needs cherry-pick 
https://gitlab.gnome.org/GNOME/gupnp-igd/-/commit/79a1e4cf8c256132978a1d8ab718c8ad132386de
 )

I've just done QA uploads to unstable for latest version of
dleyna-{core,renderer,server} to make it easier to cherry-pick upstream
changes for gssdp/gupnp 1.6 (not yet in a released version).
I can do qa uploads of dleyna-* but would prefer if these packages where
simply removed from testing as they've been orphaned for many years
(since their initial upload to debian).
Will file a bug for each package and point out the upstream commits
respectively:
* 
https://github.com/phako/dleyna-core/commit/b88f231affc697be813d7c77c17e3130df81cb9a
* 
https://github.com/phako/dleyna-renderer/commit/b3a06c8bc4b91803d7bde312f49a68109b8ad8d4
* 
https://github.com/phako/dleyna-server/commit/e7f64192643f5783e19482a11697de9ec3eea033

I will file bugs for remaining (and offer to NMU if no response),
fixed-upstream (not yet in a released version):

* caja-extensions -- https://github.com/mate-desktop/caja-extensions/issues/110
* librm -- 
https://gitlab.com/tabos/librm/-/commit/c9aae663ff40c1ab171476652eba68c174d96ba2
 + 
https://gitlab.com/tabos/librm/-/commit/a849d9a6a6624d5f3c6a70dd63590d1a2b79d1af


Regards,
Andreas Henriksson


PS. Once I've filed all bug reports I'll set them as blockers for this bug
report.


Ben file:

title = "gupnp";
is_affected = .depends ~ "libgupnp-1.2-1" | .depends ~ "libgssdp-1.2-0" | 
.depends ~ "libgupnp-1.6-0" | .depends ~ "libgssdp-1.6-0";
is_good = .depends ~ "libgupnp-1.6-0" | .depends ~ "libgssdp-1.6-0";
is_bad = .depends ~ "libgupnp-1.2-1" | .depends ~ "libgssdp-1.2-0";

Bug#1022002: src:rust-vergen: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: rust-vergen
Version: 3.0.4-2
Severity: serious
Control: close -1 6.0.2-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:rust-vergen has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package doesn't pass its 
own autopkgtests.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022001: libwebp: Please package new upstream release 1.2.4

[Boyuan Yang]

Source: libwebp
Version: 1.2.2-2
Severity: normal
Tags: sid
X-Debbugs-CC: j...@debian.org

Dear Debian libwebp package maintainer,

A new upstream release for libwebp is available at
https://storage.googleapis.com/downloads.webmproject.org/releases/webp/index.html
. Please consider packaging it.

Also, the package libavif I maintain has libsharpyuv as a new build-
dependency, which is provided by src:libwebp in the new release. Please also
consider providing the libsharpyuv library. Thanks!

Best,
Boyuan Yang


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

Bug#1021977: Fwd: Tzdata timezone files corruption after clean debian 11 installation

[Aurelien Jarno]

Dear Satish,

Thanks for the attachement. It indeed matches the file provided in the
tzdata package in version 2021a-1+deb11u7. Can you please tell me why
do you believe it is corrupted or affected by a malware?

Regards
Aurelien

On 2022-10-18 20:44, Satish Binda wrote:
> Dear Aurel,
> 
> I included the attachment this time.
> 
> Yours truly,
> 
> Satish
> -- Forwarded message -
> From: Satish Binda 
> Date: Tue, Oct 18, 2022 at 10:04 AM
> Subject: Tzdata timezone files corruption after clean debian 11 installation
> To: 
> Cc: 
> 
> 
> Package: tzdata
> Version: 2021a-1+deb11u7
> 
> Dear Debian,
> 
> I wanted to change my timezone from europe/amsterdam to utc.
> when i viewed the europe/amsterdam timezone file. I got corruption or
> malware
> as I included in this email.
> 
> All zone files as I can see contain either corruption or malware.
> 
> This is on a fresh install of debian 11.
> 
> I am going to reinstall the tzdata package if possible; but it is quite a
> breach.
> 
> Yours truly,
> 
> Satish Binda
> The Netherlands
> (ultra violence / agent 1 / kick some dust)



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

Bug#1022000: ITP: clipper -- Cross-platform clipboard access in Go

[rajudev]

Package: wnpp
Severity: wishlist
Owner: Raju Devidas 

* Package name    : clipper
  Version : 0.1.0-1
  Upstream Author : Zachary Yedidia
* URL : https://github.com/zyedidia/clipper
* License : Expat
  Programming Lang: Go
  Description : Cross-platform clipboard access in Go

 Clipper: cross-platform clipboard library
 .
 Cross-platform clipboard access in Go
 Go Reference (https://pkg.go.dev/github.com/zyedidia/clipper)
 MIT License (https://github.com/zyedidia/clipper/blob/master/LICENSE)

 clipper needs to be packaged as a dependency for micro.

Bug#1021977: Tzdata timezone files corruption after clean debian 11 installation

[Aurelien Jarno]

Hi,

On 2022-10-18 10:04, Satish Binda wrote:
> Package: tzdata
> Version: 2021a-1+deb11u7
> 
> Dear Debian,
> 
> I wanted to change my timezone from europe/amsterdam to utc.
> when i viewed the europe/amsterdam timezone file. I got corruption or

Can you please give some details about what you tried to do, for
instance which command did you try to "view" the timezone file?

> malware
> as I included in this email.

I do not find anything included in the email, can you please give some
more details?

Regards
Aurelien

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

Bug#1021695: ITP: rocprim -- parallel primitives for GPU-accelerated code

[Cordell Bloor]

Package: wnpp
Severity: wishlist
Owner: Cordell Bloor 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name    : rocprim
  Version : 5.3.0
  Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/ROCmSoftwarePlatform/rocPRIM
* License : Expat (MIT/X)
  Programming Lang: HIP
  Description : parallel primitives for GPU-accelerated code

rocPRIM is a header-only library providing HIP parallel primitives for
developing performant GPU-accelerated code on the AMD ROCm platform.

This package is a dependency of several libraries for scientific
computing on AMD GPUs, including rocthrust, rocsparse, rocalution,
hipcub, pytorch and tensorflow. It fulfills a similar role in the
AMD ROCm platform as CUB does in NVIDIA's CUDA platform.

This package is part of AMD's ROCm stack and will be maintained
under the Debian AI team umbrella.

Bug#1017982: Consul pending upload

[Martina Ferrari]

Hi all,

So I spent a considerable amount of time trying to update consul to fix 
the pending RC bugs.


I have updated the package to 1.9.17, refreshing patches and improving 
the repository structure, but it requires updating a number of 
dependencies (which might break other things like docker.io), and it 
also seems to require an *older* version of grpc. I really don't have 
time to continue pursuing this, so I have dropped Consul support from 
Prometheus instead.


I have pushed my changes to the git repository, in case anybody wants to 
continue the work.


On 12/09/2022 17:41, Martina Ferrari wrote:



On 10/09/2022 16:13, Nilesh Patra wrote:
src:nomad still B-D on consul, although you are right that it is out 
of testing, but
IIRC it was in a good shape a while ago(but not now), even made it to 
last stable.

So keeping consul _maybe_ useful (dunno for sure)

Also, src:patroni package (still in testing) has a "test-dep" in 
d/tests/control on

consul, so that'd need to be dropped if you plan to remove it.


Honestly, I don't have much time or motivation to work on consul. Unless 
somebody with an interest on it steps up and works on closing the RC 
bugs, it will end being removed from testing very soon..





--
Martina Ferrari (Tina)

Bug#1019353: transition: perl 5.36

[Niko Tyni]

On Tue, Oct 18, 2022 at 03:05:59PM +0200, Emilio Pozuelo Monfort wrote:
> > On Wed, Sep 07, 2022 at 09:47:39PM +0300, Niko Tyni wrote:

> > > We'd like to get Perl 5.36 in bookworm. Filing this to get it on the
> > > radar properly, but I'd like to do a few more checks first. So tagging
> > > 'moreinfo' for now. I'll remove that when I'm done with the checks,
> > > hopefully in a couple of weeks at the latest.

> That looks good. Please go ahead.

Thanks! perl_5.36.0-4 uploaded to unstable.
-- 
Niko

Bug#1021999: ftp.debian.org: update lintian to backports version

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please update lintian on ftp-master to the version from backports. The
currently used version from stable does not understand the current
overrides format (especially file names are now often encloded in []),
causing overrides for autoreject tags to be ignored and uploads to NEW
getting autorejected, e.g.

nvidia-graphics-drivers_510.85.02-6_amd64.changes REJECTED

libnvidia-ptxjitcompiler1: lintian output: 'embedded-library 
usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-ptxjitcompiler.so.510.85.02: 
zlib', automatically rejected package.
libnvidia-ptxjitcompiler1: If you have a good reason, you may override this 
lintian tag.
nvidia-driver-bin: lintian output: 'embedded-library 
usr/lib/nvidia/current/nvidia-debugdump: zlib', automatically rejected package.
nvidia-driver-bin: If you have a good reason, you may override this lintian tag.
nvidia-smi: lintian output: 'embedded-library 
usr/lib/nvidia/current/nvidia-smi: zlib', automatically rejected package.
nvidia-smi: If you have a good reason, you may override this lintian tag.
firmware-nvidia-gsp: lintian output: 'statically-linked-binary 
lib/firmware/nvidia/510.85.02/gsp.bin', automatically rejected package.
firmware-nvidia-gsp: If you have a good reason, you may override this lintian 
tag.

while these (generated) overrides exist:

debian/libnvidia-ptxjitcompiler1.lintian-overrides:embedded-library zlib 
[usr/lib*/libnvidia-ptxjitcompiler.so.510.85.02]
debian/nvidia-driver-bin.lintian-overrides:embedded-library zlib 
[usr/lib/nvidia/current/nvidia-debugdump]
debian/nvidia-smi.lintian-overrides:embedded-library zlib 
[usr/lib/nvidia/current/nvidia-smi]
debian/firmware-nvidia-gsp.lintian-overrides:statically-linked-binary 
[lib/firmware/nvidia/510.85.02/gsp.bin]


Andreas

Bug#1021955: pod2man: runaway italics inside C<>

[Jakub Wilk]

* Russ Allbery , 2022-10-17 16:50:

I'm moderately surprised that this went uncaught for this long


Me too.

(and I think it may be a bug in groff, which if recently introduced may 
explain that).


I don't think it's recent. I could reproduce this even in lenny.

--
Jakub Wilk

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Sat, 18 Dec 2021 10:55:37 +0100 Francesco Poli wrote:

> On Mon, 13 Sep 2021 23:00:28 +0200 Francesco Poli wrote:
> 
> > On Sat, 24 Jul 2021 16:08:27 +0200 Francesco Poli wrote:
> > 
> > > I have performed more tests on :
> > > no difference, after allowing the use of the mic, the mic signal does
> > > not seem to reach the browser (as if the mic were broken).
> > > 
> > > packagemicrophone
> > > =
> > > firefox-esr/78.12.0esr-1   fails
> > > firefox-esr/78.12.0esr-1~deb10u1   fails
> > > firefox/88.0.1-1   fails
> > 
> > And:
> > 
> > firefox-esr/78.13.0esr-1fails
> 
> And:
> 
> firefox-esr/91.4.0esr-1 fails

And:

firefox-esr/102.3.0esr-1 fails


> 
> > 
> > > 
> > > 
> > > But the mic still works perfectly with chromium and with
> > > firefox-esr/68.7.0esr-1 ...
> > > 
> > > 
> > > 
> > > This bug report has turned into a monologue.
> > > Could anyone among the maintainers of Mozilla-related packages reply,
> > > please?
> > > 
> > > Does anybody actually care about this issue?
> > > 
> > > This regression has been present in Debian testing since May 2020 and,
> > > after some initial investigation (May and June 2020) there seems to
> > > have been no further progress.
> > > 
> > > Can you reproduce the issue with a microphone?
> > > 
> > > It has been suggested in the past that the issue could be caused by one
> > > of the Debian-specific patches, since upstream Firefox does not seem to
> > > be affected.
> > > Has anyone tried to pinpoint the patch causing the regression?
> > > 
> > > Or, in case the issue is reproducible with upstream Firefox as well,
> > > has the bug report been forwarded upstream?
> > > 
> > > 
> > > Thank you for your time and patience.
> > 
> > Really, is there anybody (who cares) out there?
> 
> Ping? ping? ping? ping? ping? ...


... ?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpk9ewrkNbos.pgp
Description: PGP signature

Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org

[Akbarkhon Variskhanov]

Hi.

I just wanted to mention that there is already a command-line utility
appropriately called `salsa` from the devscripts package. Perhaps it
is worth mentioning it in gbp-create-remote-repo(1)? Or you may even
drop it completely, although I don't think you would like to do that.

Cheers,
Akbar.

Bug#1021997: cargo: New upstream version

[Kurt Roeckx]

Source: cargo
Version: 0.57.0-7
Severity: wishlist

Hi,

Would it be possible to upload a newer version of cargo? The current
version is preventing me from building things. I think the 0.62 version
matches the 1.61 version of rustc that's currently in testing/unstable.


Kurt

Bug#1021922: console-setup: FTBFS make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA16.psf] Error 2

[Samuel Thibault]

Control: severity -1 important

Hello,

Michael Biebl, le lun. 17 oct. 2022 13:53:44 +0200, a ecrit:
> Source: console-setup
> Version: 1.210
> Tags: ftbfs

1.210 does actually build, it's +binnmu1 that doesn't, because + in the
build path gets confused with file assembly on the command line:

> umask 022; /<>/Fonts/bdf2psf --log 
> /<>/Fonts/Arabic-Fixed15.log  
> /<>/Fonts/bdf/9x15-IL2.bdf+/<>/Fonts/bdf/9x15.bdf+/<>/Fonts/bdf/9x15c.bdf
>   /<>/Fonts/standard.equivalents \

I have now uploaded 1.211, which will thus fulfill your NMU need, and be
able to propagate. Leaving this bug as important open since +something
uploads are an important thing to support.

Samuel

Bug#1009735: mutt: CVE-2022-1328

[Bastian Germann]

Control: fixed -1 20220429+dfsg1-1

On Fri, 15 Apr 2022 21:27:54 +0200 Salvatore Bonaccorso  
wrote:

CVE-2022-1328[0]:
| Buffer Overflow in uudecoder in Mutt affecting all versions starting
| from 0.94.13 before 2.2.3 allows read past end of input line


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


The upstream changelog in version 20220415 claims this to be fixed.

Bug#1021996: libqtermwidget5-1: Please rebuild with python bindings enabled

[Marcel Partap]

Package: libqtermwidget5-1
Version: 1.1.0-1
Severity: normal
X-Debbugs-Cc: mpar...@gmx.net

Dear LXQt-team, can you please also build the python bindings so this can be
used with PyQt5 

`QTERMWIDGET_BUILD_PYTHON_BINDING=ON` ftw thx in advance ; )


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (510, 'unstable'), (509, 'experimental'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libqtermwidget5-1 depends on:
ii  libc6  2.35-1
ii  libqt5core5a   5.15.6+dfsg-2
ii  libqt5gui5 5.15.6+dfsg-2
ii  libqt5widgets5 5.15.6+dfsg-2
ii  libstdc++6 12.2.0-2
ii  libutf8proc2   2.7.0-3
ii  qtermwidget5-data  1.1.0-1

Versions of packages libqtermwidget5-1 recommends:
ii  fonts-hack  3.003-3

libqtermwidget5-1 suggests no packages.

-- no debconf information

Bug#1021978: spamassassin: non-standard version numbers break spamassassin's AIDE script

[Noah Meyerhans]

On Tue, Oct 18, 2022 at 10:08:32AM +0200, Thomas Dorner wrote:
> The problem is that the current version number 4.0.0~rc3-3.1 does not
> match the expected schema of N.N.N-N.  As only the first 3 numbers are
> used anyway, I've created a patch (attached) making the regular
> expression less rigid by ignoring everything after those 3 numbers.
> This works for me.

Isn't this an AIDE issue that should be fixed in that package?  The
spamassassin version complies with Debian's package version numbering
expectations.

noah

Bug#1021995: fastqtl: autopkgtest regression

[Adrian Bunk]

Source: fastqtl
Version: 2.184+v7+dfsg-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/f/fastqtl/27230464/log.gz

...
autopkgtest [23:13:45]: test run-sample-analysis: [---
covariates.txt.gz
genotypes.vcf.gz
genotypes.vcf.gz.tbi
interaction.txt
phenotypes.bed.gz
phenotypes.bed.gz.tbi

Fast QTL
  * Authors : Olivier DELANEAU, Halit ONGEN, Alfonso BUIL & Manolis DERMITZAKIS
  * Contact : olivier.delan...@gmail.com
  * Webpage : http://fastqtl.sourceforge.net/
  * Version : v2.184_gtex

Perform permutation based interaction analysis (used to calculate corrected 
p-values for MPs)
  * Perform 100 permutations
  * Test interaction with term from [interaction.txt]
  * Random number generator is seeded with 1
  * Considering variants within 1e+06 bp of the MPs
  * Using minor allele frequency threshold = 0.
  * Using minor allele sample threshold = 0
  * Using INFO field AF threshold = 0.
  * Chunk processed 1 / 100

Scanning phenotype data in [phenotypes.bed.gz]
  * 364 phenotypes

Reading phenotype data in [phenotypes.bed.gz]
  * region = 22:17517460-17646177
  * 373 samples included
  * 4 phenotypes included

Reading genotype data in [genotypes.vcf.gz] in VCF format
  * region = 22:16517460-18646177
  * 373 samples included
  * 8580 sites included

Reading covariates in [covariates.txt.gz]
  * 373 samples included
  * 4 covariate(s) included

Reading interaction term in [interaction.txt]
  * 373 samples included

Imputing missing genotypes

Imputing missing phenotypes

Initialize covariate 

Processing gene [ENSG0237438.1]
  * Number of variants in cis = 7966
  * Beta distribution parameters = 1.0382 2287.7101
  * Progress = 25.0%

Processing gene [ENSG0177663.8]
  * Number of variants in cis = 8165
  * Beta distribution parameters = 0.7994 2826.0721
  * Progress = 50.0%

Processing gene [ENSG0183307.3]
  * Number of variants in cis = 8279
  * Beta distribution parameters = 0.9595 9906.5566
  * Progress = 75.0%

Processing gene [ENSG0069998.8]
  * Number of variants in cis = 8466
  * Beta distribution parameters = 0.9606 4564.2130
  * Progress = 100.0%

Running time: 37 seconds
5d4
< ENSG0093072.10 8531 1.06453 1772.43 334.203 snp_22_17738177 -948 
0.000356058 0.683168 0.649116
autopkgtest [23:14:22]: test run-sample-analysis: ---]
autopkgtest [23:14:22]: test run-sample-analysis:  - - - - - - - - - - results 
- - - - - - - - - -
run-sample-analysis  FAIL non-zero exit status 1



Likely the files under debian/tests/output_tests/ must be regenerated.

Bug#1021994: fastqtl: binary-all FTBFS

[Adrian Bunk]

Source: fastqtl
Version: 2.184+v7+dfsg-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=fastqtl=all=2.184%2Bv7%2Bdfsg-2=1665929072=0

...
dh_fixperms
chmod -x debian/*/usr/share/fastqtl/*.R
chmod: cannot access 'debian/*/usr/share/fastqtl/*.R': No such file or directory
make[1]: *** [debian/rules:21: override_dh_fixperms] Error 1

Bug#1021993: ITP: swirc -- Curses ICB and IRC client

[Markus Uhlin]

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

* Package name: swirc
  Version : 3.3.6-1
  Upstream Author : Markus Uhlin 
* URL : https://www.nifty-networks.net/swirc/
* License : BSD-3, ISC and MIT.
  Programming Lang: C and C++
  Description : Curses ICB and IRC client

Swirc is a BSD licensed, console based and lightweight ICB and IRC
client written in C/C++, whose goals are to be portable and secure.

Features:
 - TLS/SSL
 - Multiple IRCv3 features such as SASL auth mechanism
 - Themes
 - And more...

The package is useful/relevant because the Debian project provides
support via IRC. IRC (Internet Relay Chat) is also a well proven
social media that lets the users to be anonymous.

ICB (Internet Citizen's Band) is a less common chat protocol similar
to IRC. It's used by the OpenBSD project. Swirc can act both as an ICB
and IRC client.

I plan to maintain Swirc using my best efforts to keep it safe and
sensible. I'm not looking for co-maintainers, but feedback is always
good.

I'm however looking for a SPONSOR!

Bug#1021668: [Pkg-xen-devel] Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746

[Salvatore Bonaccorso]

Hi Hans,

On Tue, Oct 18, 2022 at 02:17:32PM +0200, Hans van Kranenburg wrote:
> Hi!
> 
> On 10/12/22 19:38, Moritz Mühlenhoff wrote:
> > Source: xen
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: important
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerabilities were published for xen.
> > 
> > CVE-[...]
> Thanks for the overview. The XAPI one indeed does not apply to src:xen.
> 
> I have a question, since the 'bug' report does not contain a question,
> or explicit call for action, and I have not seen it in this way before.
> 
> Does explicitly opening a BTS bug mean that, like we use to call it,
> "these CVEs warrant a DSA", and that it is a request for an ASAP package
> update and preparing a security update for stable, or, is this a new
> thing where BTS bugs are opened for packages, just in case the
> maintainer did not already track security issues themselves actively?

Filling a bug or even it's severity may be completely orthogonal to
the question if something warrants a DSA. In fact you will notice
in the security-tracker issues triaged as no-dsa, not warranting a DSA
but which could be fixed in a point release or piggy-backed as well in
a later update filled as bug for tracking as well in the BTS with
severity grave, indicating though that the issue should be assumed RC
and be fixed in testing so that the next stable version will include a
fix.

Filling a bug make sure maintaines are aware of the issues.

Hope this helps,

Regards,
Salvatore

Bug#1005092: [EXTERNAL] Re: pytest-mpl: Please update to version 0.13

[Singer, Leo P. (GSFC-6610)]

Hi Daichi,

Yes, I can do that next week. (I am traveling and do not have my Debian key on 
me.)

Leo

From: Daichi Fukui 
Date: Tuesday, October 18, 2022 at 09:36
To: "1005...@bugs.debian.org" <1005...@bugs.debian.org>
Cc: "leo.sin...@ligo.org" 
Subject: [EXTERNAL] Re: pytest-mpl: Please update to version 0.13

Dear maintainer
CC: Leo Singer

> Dear maintainer,
>
> I am currently packaging cmyt [1], which is a new dependency of the "yt"
> package. For testing, cmyt requires at least version 0.13 of pytest-mpl.
> Could I ask to update the version in Debian to this latest version?
>
> Thank you very much!
>
> Ole
If you don't mind, can I work on updating this package to version 0.13?
I'd be happy if I could contribute to this one and the Astro team.

FYI, I've CC'd this email to Leo because it seems Leo is the top contributor 
according to d/changelog.

Best,
Fukui

Bug#1005092: pytest-mpl: Please update to version 0.13

[Daichi Fukui]

Dear maintainer
CC: Leo Singer

> Dear maintainer,
>
> I am currently packaging cmyt [1], which is a new dependency of the "yt"
> package. For testing, cmyt requires at least version 0.13 of pytest-mpl.
> Could I ask to update the version in Debian to this latest version?
>
> Thank you very much!
>
> Ole

If you don't mind, can I work on updating this package to version 0.13?
I'd be happy if I could contribute to this one and the Astro team.

FYI, I've CC'd this email to Leo because it seems Leo is the top
contributor according to d/changelog.

Best,
Fukui

Bug#1019353: transition: perl 5.36

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

Hi Niko,

On 05/10/2022 21:50, Niko Tyni wrote:

Control: tag -1 - moreinfo
Control: block -1 with 1021324

On Wed, Sep 07, 2022 at 09:47:39PM +0300, Niko Tyni wrote:

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Tags: moreinfo
X-Debbugs-Cc: p...@packages.debian.org
Control: block -1 with 1016761

We'd like to get Perl 5.36 in bookworm. Filing this to get it on the
radar properly, but I'd like to do a few more checks first. So tagging
'moreinfo' for now. I'll remove that when I'm done with the checks,
hopefully in a couple of weeks at the latest.


That was a bit optimistic (no real problems, I just couldn't find the
time), but I think we're ready now.

I've just test rebuilt the packages needing a binNMU one more time, and
the only one failing in testing is redland-bindings (#1021324, should be
trivial to fix.)  I'm marking that as a blocker, but I haven't checked
if it could be removed easily if necessary.

#1019757 is still open but I've worked around the one autopkgtest
regression that it triggered. I don't think it should be a blocker for
the transition.  I'm not aware of any other autopkgtest regressions
(but I've only tested on amd64.)

Hope this addresses any concerns you might have. Please let us know
when there is a free transition window.  An advance notice of a few days
would be appreciated.

Thanks for your work as always,


That looks good. Please go ahead.

Cheers,
Emilio

Bug#1021992: geary: FTBFS on mipsel, riscv64 (test timeout)

[Eric Long]

Source: geary
Version: 43.0-1
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: i...@hack3r.moe, debian-ri...@lists.debian.org

Dear maintainers,

geary failed to build on mipsel and riscv64 due to js-tests timeout. armhf also
timed out along with another test failure, which may be solved separately.

I've attached a patch that extends the timeout to 100s so that the test will
pass. If more help is needed, please let me know.

Cheers,
Eric
Description: Extend js-tests timeout to fix FTBFS on many platforms
Author: Eric Long 
Last-Update: 2022-10-18

--- a/test/meson.build
+++ b/test/meson.build
@@ -212,5 +212,6 @@
 test(
   'js-tests',
   test_js_bin,
-  depends: [ client_lib, web_process ]
+  depends: [ client_lib, web_process ],
+  timeout: 100
 )

Bug#940419: RFA: golang-github-segmentio-kafka-go

[Cyril Brulebois]

Alexandre Viau  (2019-09-15):
> Feel free to upload a new version of the package and remove me from
> the uploaders in debian/control.

I might work on this package, but that's not clear-cut yet (crowdsec has
a kafka acquisition module which I'm disabling for the time being; it
might be temporary, it might be long-term, not sure yet).

For information, as of v0.4.35, the following modules are needed, and
don't seem to be available in the archive:

github.com/aws/aws-sdk-go-v2/aws
github.com/mongodb/mongo-go-driver/mongo
github.com/pierrec/lz4/v4
github.com/xdg/scram


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


signature.asc
Description: PGP signature

Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4

[karogyoker999]

I've opened a new MR:
https://salsa.debian.org/pkg-llvm-team/z3/-/merge_requests/8

This MR won't add SSE2 as a requirement. Instead, it will make
the compiler not to emit SSE2 instructions when building for x86_32.
I've tested it on my Athlon XP and it works fine.
objdump -d doesn't show up any SSE2 instructions anymore.
If I compile the original source of z3, SSE2 will be emitted,
even when I'm building on an Athlon XP.

As a next step, I'll try the SIMDEverywhere approach.

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

[Daichi Fukui]

Hi all,

> As mentioned in a different bugreport [0], c4core depends on
biojppm/cmake,
> debugbreak, and fast_float.
> To meet the dependency, we're now preparing for uploading debugbreak and
> fast_float [1][2].
>
> As for biojppm/cmake, it looks like this software is used for the author's
> project only.
> This makes me wonder if it is really reasonable to package biojppm/cmake.
> It is technically possible to package it but it could end up with no other
> packages depending on the packaged biojppm/cmake than c4core.
> To make a clear decision, I would like to ask for your opinion on this
> issue.

With the help of Debian developers, debugbreak and fast_float were uploaded
to the archive.
Thus it is a good time to work on c4core.

If you don't mind, can you share your thoughts on the issue relating
to biojppm/cmake as discussed above?

Best,
Fukui

Bug#1021874: python-greenlet: FTBFS with Python 3.11 as a supported version

[Thomas Goirand]

FYI, this is fixed if upgrading to upstream release 1.1.3.

Cheers,

Thomas Goirand (zigo)

Bug#1021668: [Pkg-xen-devel] Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746

[Hans van Kranenburg]

Hi!

On 10/12/22 19:38, Moritz Mühlenhoff wrote:
> Source: xen
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for xen.
> 
> CVE-[...]
Thanks for the overview. The XAPI one indeed does not apply to src:xen.

I have a question, since the 'bug' report does not contain a question,
or explicit call for action, and I have not seen it in this way before.

Does explicitly opening a BTS bug mean that, like we use to call it,
"these CVEs warrant a DSA", and that it is a request for an ASAP package
update and preparing a security update for stable, or, is this a new
thing where BTS bugs are opened for packages, just in case the
maintainer did not already track security issues themselves actively?

I'm just wondering...

Thanks,
Hans

Bug#1021991: mumax3: does not use nvcc during build

[Andreas Beckmann]

Source: mumax3
Version: 3.10-4
Severity: serious

Hi,

mumax3 has a build dependency on nvidia-cuda-toolkit, but does not call
nvcc during build to compile the .cu files. I don't think that is intended.

Please make the following additional packaging changes w.r.t. cuda:
* Use Build-Depends: nvidia-cuda-toolkit-gcc instead of nvidia-cuda-toolkit
  That results in a deterministic nvcc+gcc combination using the default
  cuda compatible GCC version as defined in src:nvidia-cuda-toolkit.
  It also provides the /usr/bin/cuda-{gcc,g++} symlinks.
* In case you need to set a host compiler for 'nvcc -ccbin  ...'
  (because e.g. your package build system picks an cuda-incompatible gcc
  version by default (i.e. /usr/bin/gcc aka gcc-12)), please use
  cuda-g++ (or cuda-gcc) and do not hardcode any version.

Andreas

Bug#1021990: /usr/sbin/sssd: Bullseye error message "Could not start TLS encryption. (unknown error code)" when libldap-common is not installed

[Alexander Merkle]

Package: sssd-common
Version: 2.4.1-2
Severity: normal
File: /usr/sbin/sssd
X-Debbugs-Cc: support-alexander.mer...@lauterbach.com

Dear Maintainer,

I noticed after a fresh installation of bullseye (using debootstrap) the 
package 'libldap-common' is not installed.
Thus sssd / libldap.so  does not find the certificate storage which is defined 
in /etc/ldap/ldap.conf.

Thus without libldap-common installed sssd reports
  Could not start TLS encryption. (unknown error code)
. I found the following ticket in the sssd issue tracking 
  https://github.com/SSSD/sssd/issues/5444
which sounds like the same problem.

Workarounds:
1) install libdap-common manually
2) configure ldap_tls_cacert = .pem manually in sssd.conf

May be libldap-common should be added to the dependency list of sssd in 
bullseye.
By the way the problem does not exist when I debootstrap a debian 
stretch/buster/bookworm.

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

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

Versions of packages sssd-common depends on:
ii  adduser3.118
ii  libc-ares2 1.17.1-1+deb11u1
ii  libc6  2.31-13+deb11u4
ii  libdbus-1-31.12.24-0+deb11u1
ii  libdhash1  0.6.1-2
ii  libglib2.0-0   2.66.8-1
ii  libgssapi-krb5-2   1.18.3-6+deb11u2
ii  libini-config5 0.6.1-2
ii  libkeyutils1   1.6.1-2
ii  libkrb5-3  1.18.3-6+deb11u2
ii  libldap-2.4-2  2.4.57+dfsg-3+deb11u1
ii  libldb22:2.2.3-2~deb11u2
ii  libnfsidmap2   0.25-6
ii  libnl-3-2003.4.0-1+b1
ii  libnl-route-3-200  3.4.0-1+b1
ii  libp11-kit00.23.22-1
ii  libpam0g   1.4.0-9+deb11u1
ii  libpcre3   2:8.39-13
ii  libpopt0   1.18-2
ii  libref-array1  0.6.1-2
ii  libselinux13.1-3
ii  libsemanage1   3.1-1+b2
ii  libssl1.1  1.1.1n-0+deb11u3
ii  libsss-certmap02.4.1-2
ii  libsss-idmap0  2.4.1-2
ii  libsss-nss-idmap0  2.4.1-2
ii  libsystemd0247.3-7+deb11u1
ii  libtalloc2 2.3.1-2+b1
ii  libtdb11.4.3-1+b1
ii  libtevent0 0.10.2-1
ii  python33.9.2-3
ii  python3-sss2.4.1-2

Versions of packages sssd-common recommends:
ii  bind9-host  1:9.16.33-1~deb11u1
ii  libnss-sss  2.4.1-2
ii  libpam-sss  2.4.1-2

Versions of packages sssd-common suggests:
ii  apparmor 2.13.6-10
pn  libsss-sudo  
ii  sssd-tools   2.4.1-2

-- no debconf information

Bug#1021985: sddm login screen changed to white and does not display the breeze theme any more

[Chris Nospam]

Control: reassign sddm-theme-breeze 4:5.25.5-1

Bug#1021985: Re. sddm login screen changed to white and does not display the breeze theme any more

[Chris Nospam]

I think I have identified the bug now. The breeze package (was upgraded, see 
above) changed the wallpaper file types from jpg to png. Now the default config 
of sddm/sddm-theme-breeze does not find it, as it wants a jpg in the file 
theme.conf .
Please fix theme.conf in package sddm-theme-breeze from

background=/usr/share/wallpapers/Next/contents/images/5120x2880.jpg

to

background=/usr/share/wallpapers/Next/contents/images/5120x2880.png

The controls, e.g., shutdown et al. are not visible as they are drawn white on 
default background white (this is a sperarate bug, if you are asking me). Maybe 
this could be more smart and detect such a border case.

Bug#1021989: i8c: overly generic python module name: /usr/lib/python3/dist-packages/setup.py

[Andreas Beckmann]

Package: i8c
Version: 0.0.6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package uses a very generic
python module name that now clashes with other packages:

/usr/lib/python3/dist-packages/setup.py


Andreas

Bug#1021988: mate-tweak: overly generic python module name: /usr/lib/python3/dist-packages/setup.py

[Andreas Beckmann]

Package: mate-tweak
Version: 22.10.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package uses a very generic
python module name that now clashes with other packages:

/usr/lib/python3/dist-packages/setup.py


Andreas

Bug#998820: lintian: overly generic python modules /usr/lib/python3/dist-packages/benchmarks/*.py

[Andreas Beckmann]

Followup-For: Bug #998820

Another one:

/usr/lib/python3/dist-packages/setup.py

found in i8c 0.0.6-1 and mate-tweak 22.10.0-1


Andreas

Bug#1021984: (some kind of) transition: add python3.11 as a supported python3 version

[Graham Inggs]

Control: forwarded -1 https://deb.li/3Kf4j

Hi Matthias

On Tue, 18 Oct 2022 at 12:18, Matthias Klose  wrote:
> Please setup a tracker to add python3.11 as a supported python3 version. This 
> is
> non-blocking, as packages can migrate on their own once built. I'm not yet
> starting this, just want to have an overview of affected packages.
>
> Please re-use the final version of the python3.9 tracker (#996584).

The tracker is up:
https://release.debian.org/transitions/html/python3.11-add.html

> The upstream release in on time again, so we should be prepared to start this
> addition after the upstream release end of October.

\o/

Regards
Graham

Bug#1021698: libical3: Version 3.0.15-2 cannot parse ics files anymore

[Nicolas Mora]

According to this issue [1], the bug has been fixed in 3.0.16.

I'll upload the new version in unstable today so hopefully you'll be 
able to upgrade soon.


/Nicolas

[1] https://github.com/libical/libical/issues/610

Bug#1021987: evolution segfault - randomly crashes and closes.

[Andy Mann]

Package: evolution
Version: 3.46.0-2
Severity: important
Tags: upstream

(ALSO FORWARDING THIS UPSTREAM)
Evolution gui, having run as normal for a few minutes, randomly crashes and
closes.
The crashes do not appear to be linked to any particular action or menu
selection, apart from mouse movement.
Evolution restarts OK from the XFCE menu.

I regularly apt upgrade, and upgraded evolution to 3.46.0-2 a few days ago, when
the crashes started occuring.

dmesg shows:
[ 1315.117379] evolution[4317]: segfault at 8 ip 7f337ba7d467 sp
7ffcbcb36628 error 6 in libglib-2.0.so.0.7400.0[7f337b9f2000+8c000]
[ 1315.117432] Code: e9 9e b0 fc ff 66 0f 1f 44 00 00 48 8b 7f 30 e8 cf 53 f7 ff
eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 31 c0 ba 01 00 00 00  0f b1 17
75 01 c3 e9 1d f5 ff ff 66 66 2e 0f 1f 84 00 00 00 00

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

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

Versions of packages evolution depends on:
ii  dbus [default-dbus-system-bus]  1.14.4-1
ii  evolution-common3.46.0-2
ii  evolution-data-server   3.46.0-1
ii  libc6   2.35-3
ii  libcamel-1.2-64 3.46.0-1
ii  libecal-2.0-2   3.46.0-1
ii  libedataserver-1.2-27   3.46.0-1
ii  libevolution3.46.0-2
ii  libglib2.0-02.74.0-3
ii  libgtk-3-0  3.24.34-3
ii  libical33.0.15-2
ii  libnotify4  0.8.1-1
ii  libxml2 2.9.14+dfsg-1+b1
ii  psmisc  23.5-3

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.46.0-2
ii  evolution-plugin-pstimport   3.46.0-2
ii  evolution-plugins3.46.0-2
ii  yelp 42.2-1

Versions of packages evolution suggests:
ii  evolution-ews   3.46.0-2
ii  evolution-plugins-experimental  3.46.0-2
ii  gnupg   2.2.39-1
ii  network-manager 1.40.0-1+b1

-- no debconf information

Neofetch:
OS: Debian GNU/Linux bookworm/sid x86_64 
Host: 10AAS0F201 ThinkCentre M93p 
Kernel: 5.19.0-2-amd64 
Shell: bash 5.2.0 
DE: Xfce 4.16
WM: Xfwm4 
WM Theme: Adwaita-dark-2 
Theme: Adwaita-dark-2 [GTK2/3] 
Icons: Tango [GTK2], Adwaita [GTK3] 
CPU: Intel i5-4570T (4) @ 3.600GHz 
GPU: Intel HD Graphics 
Memory: 1550MiB / 7372MiB

Regards,
Andy, Birmingham, UK

Bug#1021985: sddm login screen changed to white and does not display the breeze theme any more

[Chris Nospam]

Here some entries from an sddm start in /var/log/syslog, filtered by grep sddm:

Oct 18 08:46:21 betty sddm[925]: Initializing...
Oct 18 08:46:21 betty sddm[925]: Starting...
Oct 18 08:46:21 betty sddm[925]: Logind interface found
Oct 18 08:46:21 betty sddm[925]: Adding new display on vt 7 ...
Oct 18 08:46:21 betty sddm[925]: Loading theme configuration from ""
Oct 18 08:46:21 betty sddm[925]: Display server starting...
Oct 18 08:46:21 betty sddm[925]: Adding cookie to 
"/var/run/sddm/{aa4bb32b-dbfe-438e-8bde-4348c400857f}"
Oct 18 08:46:21 betty sddm[925]: Running: /usr/bin/X -dpi 0 -auth 
/var/run/sddm/{aa4bb32b-dbfe-438e-8bde-4348c400857f} -background none -noreset 
-displayfd 17 -seat seat0 vt7
Oct 18 08:46:22 betty sddm[925]: Setting default cursor
Oct 18 08:46:22 betty sddm[925]: Running display setup script  
"/usr/share/sddm/scripts/Xsetup"
Oct 18 08:46:22 betty sddm[925]: Display server started.
Oct 18 08:46:22 betty sddm[925]: Socket server starting...
Oct 18 08:46:22 betty sddm[925]: Socket server started.
Oct 18 08:46:22 betty sddm[925]: Loading theme configuration from 
"/usr/share/sddm/themes/breeze/theme.conf"
Oct 18 08:46:22 betty sddm[925]: Greeter starting...
Oct 18 08:46:22 betty sddm-helper[1386]: [PAM] Starting...
Oct 18 08:46:22 betty sddm-helper[1386]: [PAM] Authenticating...
Oct 18 08:46:22 betty sddm-helper[1386]: [PAM] returning.
Oct 18 08:46:23 betty systemd[1388]: Cleanup lingering KCrash metadata was 
skipped because of a failed condition check 
(ConditionPathExistsGlob=/var/lib/sddm/.cache/kcrash-metadata/*.ini).
Oct 18 08:46:23 betty systemd[1388]: Cleanup lingering KCrash metadata was 
skipped because of a failed condition check 
(ConditionPathExistsGlob=/var/lib/sddm/.cache/kcrash-metadata/*.ini).
Oct 18 08:46:23 betty systemd[1]: Started Session 1 of User sddm.
Oct 18 08:46:23 betty sddm[925]: Greeter session started successfully
Oct 18 08:46:23 betty sddm-greeter[1408]: High-DPI autoscaling not Enabled
Oct 18 08:46:23 betty sddm-greeter[1408]: Reading from 
"/usr/share/xsessions/plasma.desktop"
Oct 18 08:46:23 betty sddm-greeter[1408]: Loading theme configuration from 
"/usr/share/sddm/themes/breeze/theme.conf"
Oct 18 08:46:23 betty sddm-greeter[1408]: Connected to the daemon.
Oct 18 08:46:23 betty sddm[925]: Message received from greeter: Connect
Oct 18 08:46:23 betty sddm-greeter[1408]: QFont::fromString: Invalid 
description '(empty)'
Oct 18 08:46:23 betty sddm-greeter[1408]: Loading 
file:///usr/share/sddm/themes/breeze/Main.qml...
Oct 18 08:46:23 betty sddm-greeter[1408]: QObject: Cannot create children for a 
parent that is in a different thread.#012(Parent is 
QGuiApplication(0x7fffced42270), parent's thread is QThread(0x55c623077060), 
current thread is QThread(0x55c62319ad10)
Oct 18 08:46:23 betty sddm-greeter[1408]: QObject: Cannot create children for a 
parent that is in a different thread.#012(Parent is 
QGuiApplication(0x7fffced42270), parent's thread is QThread(0x55c623077060), 
current thread is QThread(0x55c62319ad10)
Oct 18 08:46:23 betty sddm-greeter[1408]: QObject: Cannot create children for a 
parent that is in a different thread.#012(Parent is 
QGuiApplication(0x7fffced42270), parent's thread is QThread(0x55c623077060), 
current thread is QThread(0x55c62319ad10)
Oct 18 08:46:23 betty sddm-greeter[1408]: QObject::installEventFilter(): Cannot 
filter events for objects in a different thread.
Oct 18 08:46:23 betty dbus-daemon[674]: [system] Activating via systemd: 
service name='org.freedesktop.UPower' unit='upower.service' requested by 
':1.34' (uid=115 pid=1408 comm="/usr/bin/sddm-greeter --socket 
/tmp/sddm-:0-PRpPZo")
Oct 18 08:46:23 betty sddm-greeter[1408]: Failed to find a Kirigami platform 
plugin
Oct 18 08:46:23 betty sddm-greeter[1408]: 
file:///usr/share/sddm/themes/breeze/components/VirtualKeyboard.qml:12:1: Type 
InputPanel unavailable
Oct 18 08:46:23 betty sddm-greeter[1408]: 
qrc:/QtQuick/VirtualKeyboard/content/InputPanel.qml:127:5: Type Keyboard 
unavailable
Oct 18 08:46:23 betty sddm-greeter[1408]: 
qrc:/QtQuick/VirtualKeyboard/content/components/Keyboard.qml:38:1: module 
"QtQuick.VirtualKeyboard.Plugins" is not installed
Oct 18 08:46:23 betty sddm-greeter[1408]: 
file:///usr/share/sddm/themes/breeze/Background.qml:21:5: QML Image: Cannot 
open: file:///usr/share/wallpapers/Next/contents/images/5120x2880.jpg
Oct 18 08:46:23 betty sddm-greeter[1408]: Adding view for "HDMI-1" QRect(0,0 
1600x1200)
Oct 18 08:46:23 betty sddm-greeter[1408]: Qt Quick Layouts: Polish loop 
detected. Aborting after two iterations.
Oct 18 08:46:24 betty sddm-greeter[1408]: Message received from daemon: 
Capabilities
Oct 18 08:46:24 betty sddm-greeter[1408]: Message received from daemon: HostName

Bug#1021896: close the reportbug

[Bo YU]

close 1021896
close -1
thanks

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1004285: [DAViCal-devel] Bug#1004285: fixed in davical 1.1.11-1

[Florian Schlichting]

Hi Benno,

On Mon, Oct 10, 2022 at 12:46:57PM +0200, Benno Overeinder wrote:
> Unfortunately the problem persists after updating to davical 1.1.11-1. I see
> the same messages in the Apache2 error.log as previously reported.

looking at your error log from February, I think the crucial part is

Fri Feb 18 21:14:58.430957 2022] [php:notice] [pid 49689] [client 
192.168.1.1:64517] davical: BUG: :DAViCal Fatal Error: [0A000] 
SQLSTATE[0A000]: Feature not supported: 7 ERROR:  set-returning 
functions are not allowed in CASE...

This sounds like https://gitlab.com/davical-project/davical/-/issues/171

The important bit is to make sure that update-davical-database is run
from the new package, and that it has replaced the expand_memberships
function to not contain a CASE statement any more.

Florian

Bug#1021985: sddm login screen changed to white and does not display the breeze theme any more

[Chris Nospam]

Package: sddm
Version: 0.19.0-4
Severity: normal
X-Debbugs-Cc: chris...@gmx.de

Dear Maintainer,

immediately after upgrading my bookworm/testing installation on Monday October 
17th morning the sddm login screen shows a white background instead the breeze 
wallpaper. Further no controls different to the login prompt, i.e., shutdown, 
dropdown to choose desktop environment, etc., are displayed. The same happend 
to my bookwork kvm instance.
As far I can see there were von packages upgraded with sddm in its name, 
despite of kdm-config-sddm, see below snippet of apt's history.log.
I use the sddm-theme-breeze, which is the only one installed. It used to show 
the colored rocket the last months.
Please note, I did not change any configuration in KDE's SDDM settings app. The 
breeze theme shows up twice, but this is for many years the case (another 
bug?). Choosing the other one does not change anything.

> dpkg -l | grep sddm
ii  kde-config-sddm   4:5.26.0-1
  amd64KCM module for SDDM
ii  sddm  0.19.0-4  
  amd64modern display manager for X11
ii  sddm-theme-breeze 4:5.25.5-1
  amd64Breeze SDDM theme
> update-alternatives --display sddm-debian-theme
sddm-debian-theme - auto mode
  link best version is /usr/share/sddm/themes/breeze
  link currently points to /usr/share/sddm/themes/breeze
  link sddm-debian-theme is /usr/share/sddm/themes/debian-theme
/usr/share/sddm/themes/breeze - priority 30
> cd /usr/share/sddm/themes/
> ls -a
total 12
drwxr-xr-x 3 root root 4096 Nov 12  2020 .
drwxr-xr-x 7 root root 4096 Oct  9  2015 ..
drwxr-xr-x 4 root root 4096 Oct 17 18:49 breeze
lrwxrwxrwx 1 root root   35 Jun 25 11:59 debian-theme -> 
/etc/alternatives/sddm-debian-theme
> cd breeze/
> ls -la
total 780
drwxr-xr-x 4 root root   4096 Oct 17 18:49 .
drwxr-xr-x 3 root root   4096 Nov 12  2020 ..
-rw-r--r-- 1 root root   1391 Sep  6 14:35 Background.qml
-rw-r--r-- 1 root root   1627 Sep  6 14:35 KeyboardButton.qml
-rw-r--r-- 1 root root   5085 Sep  6 14:35 Login.qml
-rw-r--r-- 1 root root  23199 Sep  6 14:35 Main.qml
-rw-r--r-- 1 root root   1467 Sep  6 14:35 SessionButton.qml
drwxr-xr-x 4 root root   4096 Sep 25 14:36 components
-rw-r--r-- 1 root root   5681 Sep  6 14:35 default-logo.svg
drwxr-xr-x 2 root root   4096 Sep 25 14:36 faces
-rw-r--r-- 1 root root   2516 Sep  6 14:35 metadata.desktop
-rw-r--r-- 1 root root 717013 Sep  6 14:35 preview.png
-rw-r--r-- 1 root root208 Sep  9 23:22 theme.conf
> cat theme.conf
[General]
showlogo=hidden
logo=/usr/share/sddm/themes/breeze/default-logo.svg
type=image
color=#1d99f3
fontSize=10
background=/usr/share/wallpapers/Next/contents/images/5120x2880.jpg
needsFullUserModel=false
> cd usr/share/wallpapers/Next/contents/images/
> ls -la
total 31512
drwxr-xr-x 2 root root4096 Oct 17 08:36 .
drwxr-xr-x 4 root root4096 Oct 17 08:36 ..
-rw-r--r-- 1 root root  656342 Oct  6 14:07 1024x768.png
-rw-r--r-- 1 root root 1073831 Oct  6 14:07 1080x1920.png
-rw-r--r-- 1 root root  947830 Oct  6 14:07 1280x1024.png
-rw-r--r-- 1 root root  844607 Oct  6 14:07 1280x800.png
-rw-r--r-- 1 root root  876586 Oct  6 14:07 1366x768.png
-rw-r--r-- 1 root root 1011086 Oct  6 14:07 1440x900.png
-rw-r--r-- 1 root root 1270494 Oct  6 14:07 1600x1200.png
-rw-r--r-- 1 root root 1265636 Oct  6 14:07 1680x1050.png
-rw-r--r-- 1 root root 1463093 Oct  6 14:07 1920x1080.png
-rw-r--r-- 1 root root 1534398 Oct  6 14:07 1920x1200.png
-rw-r--r-- 1 root root 2245178 Oct  6 14:07 2560x1440.png
-rw-r--r-- 1 root root 2362192 Oct  6 14:07 2560x1600.png
-rw-r--r-- 1 root root 3125482 Oct  6 14:07 3200x1800.png
-rw-r--r-- 1 root root 3238221 Oct  6 14:07 3200x2000.png
-rw-r--r-- 1 root root  223019 Oct  6 14:07 360x720.png
-rw-r--r-- 1 root root 4097873 Oct  6 14:07 3840x2160.png
-rw-r--r-- 1 root root  135430 Oct  6 14:07 440x247.png
-rw-r--r-- 1 root root 5200588 Oct  6 14:07 5120x2880.png
-rw-r--r-- 1 root root  639660 Oct  6 14:07 720x1440.png
> cat /var/log/apt/history.log (shortened to that day)
root@betty:/temp# cat history.log
Start-Date: 2022-10-17  08:34:20
Commandline: apt-get dist-upgrade
Install: node-acorn:amd64 (8.8.0+ds+~cs25.17.7-1, automatic), 
polkitd-pkla:amd64 (121+compat0.1-6, automatic), node-cjs-module-lexer:amd64 
(1.2.2+dfsg-4, automatic), systemd-coredump:amd64 (251.5-2, automatic), 
node-xtend:amd64 (4.0.2-3, automatic), libduktape207:amd64 (2.7.0-1+b1, 
automatic), node-undici:amd64 (5.10.0+dfsg1+~cs18.9.18.10-2, automatic)
Upgrade: dpkg:amd64 (1.21.9, 1.21.9+b1), libkdecorations2-5v5:amd64 
(4:5.25.5-1, 4:5.26.0-1), breeze:amd64 (4:5.25.5-1, 4:5.26.0-1), 
libtext-unidecode-perl:amd64 (1.30-2, 1.30-3), librados2:amd64 
(16.2.10+ds-2+b2, 16.2.10+ds-2+b3), libnode108:amd64 (18.7.0+dfsg-5, 
18.10.0+dfsg-6), libcups2:amd64 (2.4.2-1+b1, 2.4.2-1+b2), libmailutils9:amd64 
(1:3.15-3, 1:3.15-3+b1), 

Bug#1021973: iconv: undefined symbol after upgrade

[Helmut Grohne]

Control: tags -1 + confirmed

On Tue, Oct 18, 2022 at 09:13:05AM +0200, Guillaume Lefranc wrote:
> after upgrading libc-bin from 2.28-10+deb10u1 to 2.28-10+deb10u2, the 
> following error appeared after running iconv the following way:
> 
> iconv -cs -f 'UTF-8' -t 'UTF-8' /tmp/510754/import/import.1
> 
> iconv: relocation error: iconv: symbol __gconv_create_spec version 
> GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

I'm sorry for having missed this. The fix for this issue is quite
obvious. libc-bin needs a tighter version constraint on libc6. Also
libc6 needs to break old libc-bin.

I don't think this is worth an update on its own though, because partial
upgrades are an unusual thing to do. Indeed apt in unstable will make
this even more difficult to perform.

If there happens to be a regression update for other reasons, this
should be fixed as well.

Helmut