Bug#1001815: transition: notcurses

2021-12-31 Thread Paul Gevers

Hi Nick,

On 01-01-2022 05:17, Nick Black (Public gmail account) wrote:

I see that growlight's autopkgtests are disabled in testing
right now due to the timeout. Can we please remove that, so I
can try something?


No, only in unstable [1]. Testing should still work.

Paul

[1] https://ci.debian.net/status/reject_list/


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1002923: python3-matplotlib: Plotting with usetex results in 'Script file /usr/share/matplotlib/mpl-data/kpsewhich.lua not found'

2021-12-31 Thread Kumar Appaiah
Package: python3-matplotlib
Version: 3.5.0-5
Severity: normal

Dear Maintainer,

I tried running this code:

import pylab

pylab.rc('text', usetex=True)
pylab.plot([1, 2, 3], [1, 4, 9])
pylab.show()

This results in the following error:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.9/tkinter/__init__.py", line 1892, in __call__
return self.func(*args)
  File "/usr/lib/python3.9/tkinter/__init__.py", line 814, in callit
func(*args)
  File "/usr/lib/python3/dist-packages/matplotlib/backends/_backend_tk.py", 
line 251, in idle_draw
self.draw()
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_tkagg.py", 
line 9, in draw
super().draw()
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
line 436, in draw
self.figure.draw(self.renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73, in 
draw_wrapper
result = draw(artist, renderer, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in 
draw_wrapper
return draw(artist, renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2803, in draw
mimage._draw_list_compositing_images(
  File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132, in 
_draw_list_compositing_images
a.draw(renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in 
draw_wrapper
return draw(artist, renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082, in 
draw
mimage._draw_list_compositing_images(
  File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132, in 
_draw_list_compositing_images
a.draw(renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in 
draw_wrapper
return draw(artist, renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1159, in draw
ticklabelBoxes, ticklabelBoxes2 = self._get_tick_bboxes(ticks_to_draw,
  File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1085, in 
_get_tick_bboxes
return ([tick.label1.get_window_extent(renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1085, in 

return ([tick.label1.get_window_extent(renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/text.py", line 910, in 
get_window_extent
bbox, info, descent = self._get_layout(self._renderer)
  File "/usr/lib/python3/dist-packages/matplotlib/text.py", line 309, in 
_get_layout
_, lp_h, lp_d = renderer.get_text_width_height_descent(
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
line 259, in get_text_width_height_descent
w, h, d = texmanager.get_text_width_height_descent(
  File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 338, in 
get_text_width_height_descent
page, = dvi
  File "/usr/lib/python3/dist-packages/matplotlib/dviread.py", line 237, in 
__iter__
while self._read():
  File "/usr/lib/python3/dist-packages/matplotlib/dviread.py", line 316, in 
_read
self._dtable[byte](self, byte)
  File "/usr/lib/python3/dist-packages/matplotlib/dviread.py", line 166, in 
wrapper
return method(self, *[f(self, byte-min) for f in get_args])
  File "/usr/lib/python3/dist-packages/matplotlib/dviread.py", line 467, in 
_fnt_def
self._fnt_def_real(k, c, s, d, a, l)
  File "/usr/lib/python3/dist-packages/matplotlib/dviread.py", line 472, in 
_fnt_def_real
tfm = _tfmfile(fontname)
  File "/usr/lib/python3/dist-packages/matplotlib/dviread.py", line 1064, in 
_fontfile
return cls(filename) if filename else None
  File "/usr/lib/python3/dist-packages/matplotlib/dviread.py", line 749, in 
__init__
with open(filename, 'rb') as file:
FileNotFoundError: [Errno 2] No such file or directory: 'Script file 
/usr/share/matplotlib/mpl-data/kpsewhich.lua not found'

Please let me know if I can help further.

Thanks.

Kumar

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

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

Versions of packages python3-matplotlib depends on:
ii  libc6   2.32-4
ii  libfreetype62.10.4+dfsg-1
ii  libgcc-s1   11.2.0-2
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-ui 1.12.1+dfsg-8
ii  libqhull-r8.0   2020.2-4
ii  libstdc++6  11.2.0-2
ii  python-matplotlib-data  3.5.0-5
ii  python3 3.9.2-3
ii  python3-cycler 

Bug#1002922: minetest-mod-worldedit: please update package to the newer upstream version

2021-12-31 Thread Lev Lamberov
Package: minetest-mod-worldedit
Severity: normal
X-Debbugs-Cc: none, Lev Lamberov , Debian Games Team 


Dear Maintainer,

Currently the version of minetest-mod-worldedit in Debian is 0.6. It was
not updated since its initial upload in 2013. Please, consider updating
the package.

Also, it would be nice not to depend on minetest itself, since it make
the package rather problematic to use on headless servers. Please,
depend on minetest | minetest-server.

Cheers!
Lev Lamberov


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

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



Bug#1002921: Log Files

2021-12-31 Thread D.J.J. Ring, Jr.
Further to my bug report.

Installation detects my sound card but no screen reader present. System
inaccessible, only root can run MATE. User can only access CLI.

REGARDS,

David

-- Forwarded message -
From: David J. J. Ring, Jr. 
Date: Thu, Dec 30, 2021, 18:03
Subject: Log Files
To: David JJ Ring Jr 


Log  files
[  1838.994] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[  1838.994] Build Operating System: linux Debian
[  1838.994] Current Operating System: Linux debian 5.10.0-10-amd64 #1 SMP 
Debian 5.10.84-1 (2021-12-08) x86_64
[  1838.994] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-10-amd64 
root=UUID=2bb51d3e-ddb2-4a56-bf34-52e828bf8fe0 ro quiet
[  1838.994] Build Date: 16 December 2021  05:08:23PM
[  1838.994] xorg-server 2:1.20.11-1+deb11u1 (https://www.debian.org/support) 
[  1838.994] Current version of pixman: 0.40.0
[  1838.994]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1838.994] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1838.994] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 30 17:09:15 
2021
[  1838.995] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1838.995] (==) No Layout section.  Using the first Screen section.
[  1838.995] (==) No screen section available. Using defaults.
[  1838.995] (**) |-->Screen "Default Screen Section" (0)
[  1838.995] (**) |   |-->Monitor ""
[  1838.995] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1838.995] (==) Automatically adding devices
[  1838.995] (==) Automatically enabling devices
[  1838.995] (==) Automatically adding GPU devices
[  1838.995] (==) Max clients allowed: 256, resource mask: 0x1f
[  1838.995] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  1838.995]Entry deleted from font path.
[  1838.995] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  1838.995] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1838.995] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  1838.995] (II) Loader magic: 0x561e372abe40
[  1838.995] (II) Module ABI versions:
[  1838.995]X.Org ANSI C Emulation: 0.4
[  1838.995]X.Org Video Driver: 24.1
[  1838.995]X.Org XInput driver : 24.1
[  1838.995]X.Org Server Extension : 10.0
[  1838.996] (++) using VT number 7

[  1838.996] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[  1838.996] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1839.009] (--) PCI:*(0@0:2:0) 8086:1616:8086:2010 rev 9, Mem @ 
0xc000/16777216, 0xa000/536870912, I/O @ 0x4000/64, BIOS @ 
0x/131072
[  1839.009] (II) LoadModule: "glx"
[  1839.009] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  1839.010] (II) Module glx: vendor="X.Org Foundation"
[  1839.010]compiled for 1.20.11, module version = 1.0.0
[  1839.010]ABI class: X.Org Server Extension, version 10.0
[  1839.010] (==) Matched modesetting as autoconfigured driver 0
[  1839.010] (==) Matched fbdev as autoconfigured driver 1
[  1839.010] (==) Matched vesa as autoconfigured driver 2
[  1839.010] (==) Assigned the driver to the xf86ConfigLayout
[  1839.010] (II) LoadModule: "modesetting"
[  1839.010] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[  1839.010] (II) Module modesetting: vendor="X.Org Foundation"
[  1839.010]compiled for 1.20.11, module version = 1.20.11
[  1839.010]Module class: X.Org Video Driver
[  1839.010]ABI class: X.Org Video Driver, version 24.1
[  1839.010] (II) LoadModule: "fbdev"
[  1839.010] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[  1839.010] (II) Module fbdev: vendor="X.Org Foundation"
[  1839.010]compiled for 1.20.0, module version = 0.5.0
[  1839.010]Module class: X.Org Video Driver
[  1839.010]ABI class: X.Org Video Driver, version 24.0
[  1839.010] (II) LoadModule: "vesa"
[  1839.010] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[  1839.010] (II) Module vesa: vendor="X.Org Foundation"
[  1839.010]compiled for 1.20.9, module version = 2.5.0
[  1839.010]Module class: X.Org Video Driver
[  1839.010]ABI class: X.Org Video Driver, version 24.1
[  1839.010] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  1839.010] (II) FBDEV: driver for framebuffer: fbdev
[  1839.010] (II) VESA: driver for VESA chipsets: vesa
[  1839.023] (II) modeset(0): 

Bug#1002921: Xlog

2021-12-31 Thread D.J.J. Ring, Jr.
Further to my bug report

-- Forwarded message -
From: David J. J. Ring, Jr. 
Date: Thu, Dec 30, 2021, 18:13
Subject: Xlog
To: David JJ Ring Jr 
[  5570.481] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[  5570.486] Build Operating System: linux Debian
[  5570.488] Current Operating System: Linux debian 5.10.0-10-amd64 #1 SMP 
Debian 5.10.84-1 (2021-12-08) x86_64
[  5570.488] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-10-amd64 
root=UUID=2bb51d3e-ddb2-4a56-bf34-52e828bf8fe0 ro quiet
[  5570.492] Build Date: 16 December 2021  05:08:23PM
[  5570.493] xorg-server 2:1.20.11-1+deb11u1 (https://www.debian.org/support) 
[  5570.495] Current version of pixman: 0.40.0
[  5570.499]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  5570.499] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  5570.506] (==) Log file: "/home/djringjr/.local/share/xorg/Xorg.1.log", 
Time: Thu Dec 30 18:11:26 2021
[  5570.507] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  5570.508] (==) No Layout section.  Using the first Screen section.
[  5570.508] (==) No screen section available. Using defaults.
[  5570.508] (**) |-->Screen "Default Screen Section" (0)
[  5570.508] (**) |   |-->Monitor ""
[  5570.508] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  5570.508] (==) Automatically adding devices
[  5570.508] (==) Automatically enabling devices
[  5570.508] (==) Automatically adding GPU devices
[  5570.508] (==) Max clients allowed: 256, resource mask: 0x1f
[  5570.508] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  5570.508]Entry deleted from font path.
[  5570.508] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  5570.508] (==) ModulePath set to "/usr/lib/xorg/modules"
[  5570.508] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  5570.508] (II) Loader magic: 0x55ae00bf4e40
[  5570.508] (II) Module ABI versions:
[  5570.508]X.Org ANSI C Emulation: 0.4
[  5570.508]X.Org Video Driver: 24.1
[  5570.508]X.Org XInput driver : 24.1
[  5570.508]X.Org Server Extension : 10.0
[  5570.508] (++) using VT number 2

[  5570.510] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_311
[  5570.511] (II) xfree86: Adding drm device (/dev/dri/card0)
[  5570.511] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 13 paused 0
[  5570.513] (--) PCI:*(0@0:2:0) 8086:1616:8086:2010 rev 9, Mem @ 
0xc000/16777216, 0xa000/536870912, I/O @ 0x4000/64, BIOS @ 
0x/131072
[  5570.513] (II) LoadModule: "glx"
[  5570.513] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  5570.514] (II) Module glx: vendor="X.Org Foundation"
[  5570.514]compiled for 1.20.11, module version = 1.0.0
[  5570.514]ABI class: X.Org Server Extension, version 10.0
[  5570.514] (==) Matched modesetting as autoconfigured driver 0
[  5570.514] (==) Matched fbdev as autoconfigured driver 1
[  5570.514] (==) Matched vesa as autoconfigured driver 2
[  5570.514] (==) Assigned the driver to the xf86ConfigLayout
[  5570.514] (II) LoadModule: "modesetting"
[  5570.514] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[  5570.514] (II) Module modesetting: vendor="X.Org Foundation"
[  5570.514]compiled for 1.20.11, module version = 1.20.11
[  5570.514]Module class: X.Org Video Driver
[  5570.514]ABI class: X.Org Video Driver, version 24.1
[  5570.514] (II) LoadModule: "fbdev"
[  5570.514] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[  5570.514] (II) Module fbdev: vendor="X.Org Foundation"
[  5570.514]compiled for 1.20.0, module version = 0.5.0
[  5570.514]Module class: X.Org Video Driver
[  5570.514]ABI class: X.Org Video Driver, version 24.0
[  5570.514] (II) LoadModule: "vesa"
[  5570.514] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[  5570.515] (II) Module vesa: vendor="X.Org Foundation"
[  5570.515]compiled for 1.20.9, module version = 2.5.0
[  5570.515]Module class: X.Org Video Driver
[  5570.515]ABI class: X.Org Video Driver, version 24.1
[  5570.515] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  5570.515] (II) FBDEV: driver for framebuffer: fbdev
[  5570.515] (II) VESA: driver for VESA chipsets: vesa
[  5570.515] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not 
permitted)
[  5570.515] (II) modeset(0): using drv 

Bug#813771: reportbug: It can't unselect item in 'Do any of the following apply to this report' page.

2021-12-31 Thread Takahide Nojima
Dear Nis Martensen,

Thank you for responding. I don't care about the response delay because
this is not a severe problem, and we can do this at our pace.

 Then you wrote,
> - Is it possible to more clearly highlight the selected row(s)? Some
> of
> the menus can be quite long with a lot of text, and the radiobutton
> or
> checkbox is relatively tiny. It would be nice if the selected
> option(s)
> stand out more.
> 
>  - Also to mark a row it is now necessary to click on the radiobutton
> or
> checkbox. Is it possible to have a click anywhere on a row toggle the
> selection status of that option?
> 
>  - Is it possible, when using checkboxes, to have a way to enforce
> that
> not more than option is selected? The mailer selection menu is an
> example menu where it should be possible to not have any option
> selected, but where being able to select more than one option does
> not
> make sense either.

I understand your expectations. However, I'm not sure that I live up to
your expectation at this moment because I don't come up with a way of
implementation yet to realize what you want. I'm still finding the way,
so that I'm much grateful for any hints if you would have about how to
implement it. 
 
> Instead of sending a patch by email, if you like you can also submit
> a
> merge request on salsa. With that it is easy to discuss specific
> changes
> in the code directly.

Thank you for the suggestion about using salsa. I'm going to register
salsa. If I succeed in the registration of salsa, I'll post the issue
about this bug report.

Regards,


Takahide Nojima



Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

2021-12-31 Thread David J. Ring, Jr.
Package: installation-reports
Severity: important
X-Debbugs-Cc: n...@arrl.net

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: Image version: firmware-11.2.0-amd64-DVD-1.iso 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.2.0+nonfree/amd64/iso-dvd/firmware-11.2.0-amd64-DVD-1.iso
 2021-12-18
Date: 

Machine: Machine: Intense-PC2-BRW (IPC2) (System SKUNumber)
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u2"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host 
Bridge -OPI [8086:1604] (rev 09)
lspci -knn: Subsystem: Intel Corporation Device [8086:2010]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD 
Graphics 5500 [8086:1616] (rev 09)
lspci -knn: Subsystem: Intel Corporation Device [8086:2010]
lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio 
Controller [8086:160c] (rev 09)
lspci -knn: Subsystem: Intel Corporation Device [8086:2010]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Wildcat 
Point-LP MEI Controller #1 [8086:9cba] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet 
Connection I218-LM [8086:155a] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:]
lspci -knn: Kernel modules: e1000e
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP 
High Definition Audio Controller [8086:9ca0] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #3 [8086:9c94] (rev e3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #4 [8086:9c96] (rev e3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #5 [8086:9c98] (rev e3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP 
USB EHCI Controller [8086:9ca6] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Wildcat Point-LP LPC 
Controller [8086:9cc3] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation Wildcat Point-LP 
SATA Controller [AHCI Mode] [8086:9c83] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation Wildcat Point-LP SMBus 
Controller [8086:9ca2] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:1f.6 Signal processing controller [1180]: Intel Corporation 
Wildcat Point-LP Thermal Management Controller [8086:9ca4] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 01:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit 
Network Connection [8086:1539] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:]
lspci -knn: Kernel driver in use: igb
lspci -knn: Kernel modules: igb
lspci -knn: 02:00.0 Network controller [0280]: Intel Corporation Wireless 8260 
[8086:24f3] (rev 3a)
lspci -knn: 

Bug#1001815: transition: notcurses

2021-12-31 Thread Nick Black (Public gmail account)
I see that growlight's autopkgtests are disabled in testing
right now due to the timeout. Can we please remove that, so I
can try something? 

I noticed just now in the growlight testing logs that we have
output of the form e.g.:

xvda14 -> ../../devices/vbd-51712/block/xvda/xvda14
Partition 14 at xvda14
Partition 1 at xvda1
Partition 15 at xvda15
Logical sector size: 512B Physical sector size: 512B

but this isn't "blockdev -v" output; it's just general startup
diagnostics due to calling "growlight-readline -v". we then see
a prompt in the logs:

[growlight](0)> 

that never seems to get any input. i.e. the "echo blockdev -v"
is never hitting it, and that's why it's not shutting down.

success should look like:

^[[64;1H^A^[[0;35m^B[^A^[[0;36m^Bgrowlight^A^[[0;35m^B]^A^[[1;32m^B(0)> 
^A^[[1;37m^B^[[64;1H^[[Kb^[[64;2H^[[64;1H^[[Kbl^[[64;3H^[[64;1H^[[Kblo^[[64;4H^[[64;1H^[[Kbloc^[[64;5H^[[64;1H^[[Kblock^[[64;6H^[[64;1H^[[Kblockd^[[64;7H^[[64;1H^[[Kblockde^[[64;8H^[[64;1H^[[Kblockdev^[[64;9H^[[64;1H^[[Kblockdev
 ^[[64;10H^[[64;1H^[[Kblockdev -^[[64;11H^[[64;1H^[[Kblockdev 
-v^[[64;12H^[[64;1H^[[Kblockdev -v ^[[64;13H
^[[1m^[[38;2;255;255;255mDevice Model Rev   Bytes PSect Flags 
Table WWN  PHY
^[[22m^[[38;2;249;241;165msdjST16000NM000J-2T SN02  16.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . none  5000c500c94d9fd7 SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:31251759104 (14.55Ti)
^[[38;2;249;241;165msdlST12000NM0007-2A SN02  12.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . gpt   5000c500b49867e5 SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:2047 (1Mi)
^[[1m^[[38;2;59;120;255msdl1   53316a63-ce0b-644f-b0de-586da7e95a07  12.00T 
Oth zfs-7f5ed1aa1ce6dbc4
^[[38;2;19;161;14m^[[38;2;59;120;255msdl9   
703b1cea-95bf-a840-8bb8-4336b78ba231   8.39M Oth n/a
^[[38;2;19;161;14m^[[22mUnused sectors 23437768704:23437770752 (1.00Mi)
^[[38;2;249;241;165msdhST12000NM0007-2A SN03  12.00T 4096B M-bM-^XM- 
OWM-bM-^ZM- . gpt   5000c500a5c0e61d SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:2047 (1Mi)
^[[1m^[[38;2;59;120;255msdh1   091bbc74-d66a-3849-af41-42ec40116171  12.00T 
Oth zfs-d60b954b8cc5eae0
^[[38;2;19;161;14m^[[38;2;59;120;255msdh9   
4bcb8333-fb23-d244-8d70-34e9378155d9   8.39M Oth n/a
^[[38;2;19;161;14m^[[22mUnused sectors 23437768704:23437770752 (1.00Mi)
^[[38;2;249;241;165msdkST18000NM000J-2T SN02  18.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . none  5000c500dbd49a2a SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:35156656128 (16.37Ti)
^[[38;2;249;241;165msdiST16000NM000J-2T SN02  16.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . none  5000c500db183d56 SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:31251759104 (14.55Ti)
^[[38;2;249;241;165msdbST12000NM0007-2A SN02  12.00T 4096B 
M-bM-^\M-^TOWM-bM-^ZM- . gpt   5000c500b4104bf5 SAT3
^[[1m^[[38;2;19;161;14m^[[22mUnused sectors 0:2047 (1Mi)

or, with the control sequences stripped:

blockdev -v
Device Model Rev   Bytes PSect Flags Table WWN  PHY
sdjST16000NM000J-2T SN02  16.00T 4096B ✔OW⚠. none  5000c500c94d9fd7 SAT3
Unused sectors 0:31251759104 (14.55Ti)
sdlST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b49867e5 SAT3
Unused sectors 0:2047 (1Mi)
sdl1   53316a63-ce0b-644f-b0de-586da7e95a07  12.00T Oth zfs-7f5ed1aa1ce6dbc4
sdl9   703b1cea-95bf-a840-8bb8-4336b78ba231   8.39M Oth n/a
Unused sectors 23437768704:23437770752 (1.00Mi)
sdhST12000NM0007-2A SN03  12.00T 4096B ☠OW⚠. gpt   5000c500a5c0e61d SAT3
Unused sectors 0:2047 (1Mi)
sdh1   091bbc74-d66a-3849-af41-42ec40116171  12.00T Oth zfs-d60b954b8cc5eae0
sdh9   4bcb8333-fb23-d244-8d70-34e9378155d9   8.39M Oth n/a
Unused sectors 23437768704:23437770752 (1.00Mi)
sdkST18000NM000J-2T SN02  18.00T 4096B ✔OW⚠. none  5000c500dbd49a2a SAT3
Unused sectors 0:35156656128 (16.37Ti)
sdiST16000NM000J-2T SN02  16.00T 4096B ✔OW⚠. none  5000c500db183d56 SAT3
Unused sectors 0:31251759104 (14.55Ti)
sdbST12000NM0007-2A SN02  12.00T 4096B ✔OW⚠. gpt   5000c500b4104bf5 SAT3
Unused sectors 0:2047 (1Mi)

so i've changed up the autopkgtests to try something.


signature.asc
Description: PGP signature


Bug#977494: less: integer overflow on the number in the command buffer

2021-12-31 Thread Vincent Lefevre
Control: forwarded -1 https://github.com/gwsw/less/issues/239

On 2021-12-31 23:47:31 +0100, Vincent Lefevre wrote:
> I'm going to report a bug upstream.

Now done.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#1002919: dblatex missing dependency on fonts-dejavu

2021-12-31 Thread Ian Jackson
Package: dblatex
Version: 0.3.12py3-1

Hi.  I confess that I'm not sure exactly that this bug report is
correct, but I think something is wrong and I thought I ought to
report it.

I recently did some rework on one of my own packages, userv, and I
found that
   dblatex -b xetex
doesn't work unless fonts-dejavu is installed as well as dblatex and
texlive-xetex:

  
https://buildd.debian.org/status/fetch.php?pkg=userv=amd64=1.2.1%7Ebeta3=1640991844=0

I'm not sure where this dependency ought to be, if indeed it ought to
be anywhere at al.  For now I am adding an explicit dependency on
"fonts-dejavu" to my Build-Depends.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1002723: Connection problems to murmur server with older client V 1.3.0

2021-12-31 Thread Chris Knadle

Karsten:

Package: mumble
X-Debbugs-Cc: deb...@decotrain.de
Version: 1.3.4-1
Severity: normal

Hello,

please refer to this bug report at mumble:
https://github.com/mumble-voip/mumble/issues/5382

The connection of the client to the server is always rejected the first time.
Afterwards it connects with a "next server":

|2021-12-27 10:28:31.399 ServerHandler: connection attempt to 
[2001:4dd0:af1b:3a0f:ca0e:14ff:fee6:a090]:64738 failed:
Verbindung verweigert (0); trying next server |


The above connection attempt is to an IPv6 address. Can you please verify that 
the Murmur / mumble-server in question actually has IPv6 connectivity to it?


[IPv6 is more common in Europe, not so much in the United States where I am, so 
when I see this it's "usually an error".]


In the config file in the upstream but report, I see this:

 ; Specific IP or hostname to bind to.
 ; If this is left blank (default), Murmur will bind to all available addresses.
 host=192.168.1.3

That's an IPv4 listening address, not IPv6

I think this is some kid of DNS lookup issue, where the client (for some reason) 
is getting an IPv6 address to connect to, but the server is only listening on 
IPv4. i.e. best I can tell this is an IP networking issue, unrelated to Mumur / 
mumble-server.



With the older server V 1.2.18 this message does not appear.

A connection with the older client V 1.3.0 (within Debian 10) to the current 
server is generally not possible and always
rejected!


But in the upstream bug report, there's a comment stating the opposite;
"The other client that works is on Debian 10 with client V 1.3.0"

https://github.com/mumble-voip/mumble/issues/5382#issuecomment-1000475491

?


Maybe the maintainer can help with this problem?
One of the things I looking for and don't see in the bug report is what the IP 
address was the logs for a /working/ connection. If I was able to see that a 
connection attempt went to the same IPv6 address and worked, that would 
eliminate IPv4 vs IPv6 being the problem.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us



Bug#965685: libropkg-perl: diff for NMU version 0.4-1.4

2021-12-31 Thread gregor herrmann
On Thu, 30 Dec 2021 03:11:49 +0100, Andreas Beckmann wrote:

> On Sun, 26 Dec 2021 18:07:52 +0100 gregor herrmann 
> wrote:
> > I've prepared an NMU for libropkg-perl (versioned as 0.4-1.4) and
> 
> libropkg-perl is orphaned, so you should rather QA it to -2 than NMU it to
> -1.4 ;-)

Oh right, sorry for missing this and thanks for the hint.

Well, next time :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature


Bug#995477: workaround

2021-12-31 Thread Paul Seyfert

Same for me. Trying around it seems this can be addressed on the user side by 
rebuilding in the index:

```

cppman std::unique_ptr

error: no such table: cppreference.com_keywords

cppman --rebuild-index

...

cppman std::unique_ptr

```

if I understand correctly, rebuilding the index fills 
$HOME/.cache/cppman/index.db.
Comparing the /usr/lib/python3/dist-packages/cppman/lib/index.db (from the 
package) with the one in $HOME/.cache,
I see that the table `cppreference.com_keywords` table is present in 
$HOME/.cache and missing in /usr

Could it be the sqlite db in /usr is incorrectly packaged?

I quickly tired (to see if this can be addressed on the packaging side):
 - rm /usr/lib/python3/dist-packages/cppman/lib/index.db
 - cp $HOME/.cache/cppman/index.db 
/usr/lib/python3/dist-packages/cppman/lib/index.db
 - chown root:root /usr/lib/python3/dist-packages/cppman/lib/index.db
 - chmod 644 /usr/lib/python3/dist-packages/cppman/lib/index.db
 - mv $HOME/.cache/cppman $HOME/.cache/cppman.bak

after this (i.e. replacing the shipped index.db with the newly generated one 
and removing my user cache) cppman works
as expected for me.

Hope that helps fixing the issue (be it the maintainers or users).

Cheers,
Paul



Bug#968162: ITP: toybox -- BSD-licensed Linux command line utilities

2021-12-31 Thread Bastian Germann

On Wed, 22 Dec 2021 12:22:20 + Antoni Villalonga  wrote:

3 Lintian errors must be fixed:
  E: toybox source: source-is-missing tests/files/elf/fdstatic
  E: toybox source: source-is-missing tests/files/elf/ndk-elf-note-full
  E: toybox source: source-is-missing tests/files/elf/ndk-elf-note-short

I think dCopyright Files-Excluded should help, but I've messed up in my tests.


Yes, and please exclude tests/files/java.class as well. Make sure that you add a +dfsg suffix to the 
upstream version.


When that is done, I am going to sponsor this.

I have made changes to the copyright and changelog files in branch 
releaseCandidate-0.8.6-1.
Please check them out.

Thanks,
Bastian



Bug#977494: less: integer overflow on the number in the command buffer

2021-12-31 Thread Vincent Lefevre
Control: found -1 590-1

On 2020-12-15 18:48:10 +0100, Vincent Lefevre wrote:
> The code that parses the number in the command buffer does not check
> integer overflow.

This is still the case.

> I'm attaching a patch, which saturates the value to INT_MAX, since
> there are conversions to int in some parts of the code.

Note, however, that this means that one cannot use command P on
values larger than INT_MAX (for files that would be larger than
2 GB). I think that the code needs a better cleanup. I'm going
to report a bug upstream.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#1002595: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"

2021-12-31 Thread Don Armstrong
On Fri, 31 Dec 2021, Mike Frysinger wrote:
> i get that the server is misbehaving now so clients don't have much
> choice but to workaround them, but the server response should be fixed
> nevertheless.

Happy to accept patches to fix the XML serialization in SOAP. The way
that Debbugs is doing it is clearly not correct, but fixing it isn't
high on my priority list. [Really, it's past time for us to support a
REST interface and abandon the SOAP interface.]

-- 
Don Armstrong  https://www.donarmstrong.com

Grimble left his mother in the food store and went to the launderette
and watched the clothes go round. It was a bit like color television
only with less plot.
 -- Clement Freud _Grimble_



Bug#1002914: userv: FBTFS

2021-12-31 Thread Ian Jackson
Aurelien Jarno writes ("Bug#1002914: userv: FBTFS"):
> Source: userv
> Version: 1.2.1~beta2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> userv fails to build from source:
...
> | flex  -t lexer.l > lexer.c
> | /bin/sh: 1: flex: not found

Thanks for the report.  It seems that my usual local build chroot had
flex installed, so I din't spot this before upload.  In earlier
versions we must have been reusing the pre-shipped lexer.c file (which
is many years old).  In ~beta2 I arranged to prevent the reuse of such
files.

I will push a fix shortly.

Thanks,
Ian.



Bug#1002175: docker-compose: FTBFS: AttributeError: 'NoneType' object has no attribute 'split'

2021-12-31 Thread Andrej Shadura

Control: notfound -1 1.27.4-2

Hi,

On Tue, 21 Dec 2021 17:14:52 +0100 Lucas Nussbaum  wrote:

During a rebuild of all packages in sid, your package failed to build
on amd64.


I can’t reproduce this.

--
Cheers,
  Andrej



Bug#1002913: openttd: FBTFS

2021-12-31 Thread Matthijs Kooijman
Hi Aurelien,

Thanks for reporting, I had already seen the failure and am working on
a fix, probably next weekend. The issue is caused by the buildds
building arch and arch-indep separately, which exposes a problem in the
rules file, but I hadn't tested this scenario before upload.

Gr.

Matthijs


signature.asc
Description: PGP signature


Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

2021-12-31 Thread Paul Gevers

Hi Ondřej, PHP PECL Maintainers,

On 31-12-2021 12:50, Ondřej Surý wrote:

Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP version to PHP 
8.1


Thanks.

Will you also upload src:php-imagick, which seems to block some rebuilds 
in the current state.


I want to update the ben transition tracker file to catch these kind of 
packages. Should I add a "Depends on php7.4-common" to the "bad" list?


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#956399: pam-ssh-agent-auth: Segfault when using ECDSA keys

2021-12-31 Thread Bálint Réczey
Hi,

I've uploaded the attached NMU to DELAYED/5.

Cheers,
Balint

Alexander Barton  ezt írta (időpont: 2021. dec. 26., V, 14:30):
>
> Hi!
>
> I’m seeing this as well, any chance to get this patch merged?
> It fixes the issue for me.
>
> Thanks!
> Alex
diff -Nru pam-ssh-agent-auth-0.10.3/debian/changelog pam-ssh-agent-auth-0.10.3/debian/changelog
--- pam-ssh-agent-auth-0.10.3/debian/changelog	2019-01-26 16:58:57.0 +0100
+++ pam-ssh-agent-auth-0.10.3/debian/changelog	2021-12-31 19:08:41.0 +0100
@@ -1,3 +1,13 @@
+pam-ssh-agent-auth (0.10.3-3.1) unstable; urgency=medium
+
+  [Balint Reczey]
+  * Non-maintainer upload.
+
+  [Marc Deslauriers]
+  * Fix segfault when using ECDSA keys (LP: #1869512) (Closes: #956399)
+
+ -- Balint Reczey   Fri, 31 Dec 2021 19:08:41 +0100
+
 pam-ssh-agent-auth (0.10.3-3) unstable; urgency=medium
 
   * Remove myself from uploaders
diff -Nru pam-ssh-agent-auth-0.10.3/debian/patches/0002-fix-segfault-when-using-ECDSA-keys.patch pam-ssh-agent-auth-0.10.3/debian/patches/0002-fix-segfault-when-using-ECDSA-keys.patch
--- pam-ssh-agent-auth-0.10.3/debian/patches/0002-fix-segfault-when-using-ECDSA-keys.patch	1970-01-01 01:00:00.0 +0100
+++ pam-ssh-agent-auth-0.10.3/debian/patches/0002-fix-segfault-when-using-ECDSA-keys.patch	2021-12-31 18:53:19.0 +0100
@@ -0,0 +1,58 @@
+From 1b0d9bcc5f5cd78b0bb1357d6a11da5d616ad26f Mon Sep 17 00:00:00 2001
+From: Wout Mertens 
+Date: Thu, 11 Jun 2020 18:08:13 +0200
+Subject: [PATCH] fix segfault when using ECDSA keys.
+
+Author: Marc Deslauriers 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1869512
+---
+ ssh-ecdsa.c | 15 +++
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+diff --git a/ssh-ecdsa.c b/ssh-ecdsa.c
+index 5b13b30..5bf29cc 100644
+--- a/ssh-ecdsa.c
 b/ssh-ecdsa.c
+@@ -46,7 +46,7 @@ ssh_ecdsa_sign(const Key *key, u_char **sigp, u_int *lenp,
+ u_int len, dlen;
+ Buffer b, bb;
+ #if OPENSSL_VERSION_NUMBER >= 0x1015L
+-	BIGNUM *r, *s;
++	BIGNUM *r = NULL, *s = NULL;
+ #endif
+ 
+ if (key == NULL || key->type != KEY_ECDSA || key->ecdsa == NULL) {
+@@ -137,20 +137,27 @@ ssh_ecdsa_verify(const Key *key, const u_char *signature, u_int signaturelen,
+ 
+ /* parse signature */
+ if ((sig = ECDSA_SIG_new()) == NULL)
+-pamsshagentauth_fatal("ssh_ecdsa_verify: DSA_SIG_new failed");
++pamsshagentauth_fatal("ssh_ecdsa_verify: ECDSA_SIG_new failed");
+ 
+ pamsshagentauth_buffer_init();
+ pamsshagentauth_buffer_append(, sigblob, len);
+ #if OPENSSL_VERSION_NUMBER < 0x1015L
+ if ((pamsshagentauth_buffer_get_bignum2_ret(, sig->r) == -1) ||
+ (pamsshagentauth_buffer_get_bignum2_ret(, sig->s) == -1))
++pamsshagentauth_fatal("ssh_ecdsa_verify:"
++"pamsshagentauth_buffer_get_bignum2_ret failed");
+ #else
+-DSA_SIG_get0(sig, , );
++if ((r = BN_new()) == NULL)
++pamsshagentauth_fatal("ssh_ecdsa_verify: BN_new failed");
++if ((s = BN_new()) == NULL)
++pamsshagentauth_fatal("ssh_ecdsa_verify: BN_new failed");
+ if ((pamsshagentauth_buffer_get_bignum2_ret(, r) == -1) ||
+ (pamsshagentauth_buffer_get_bignum2_ret(, s) == -1))
+-#endif
+ pamsshagentauth_fatal("ssh_ecdsa_verify:"
+ "pamsshagentauth_buffer_get_bignum2_ret failed");
++if (ECDSA_SIG_set0(sig, r, s) != 1)
++pamsshagentauth_fatal("ssh_ecdsa_verify: ECDSA_SIG_set0 failed");
++#endif
+ 
+ /* clean up */
+ memset(sigblob, 0, len);
+-- 
+2.30.2
+
diff -Nru pam-ssh-agent-auth-0.10.3/debian/patches/series pam-ssh-agent-auth-0.10.3/debian/patches/series
--- pam-ssh-agent-auth-0.10.3/debian/patches/series	2019-01-26 16:40:32.0 +0100
+++ pam-ssh-agent-auth-0.10.3/debian/patches/series	2021-12-31 19:08:41.0 +0100
@@ -1,3 +1,4 @@
 0001-authfd.c-check-return-value-of-seteuid-2.patch
 openssl-1.1.1-1.patch
 openssl-1.1.1-2.patch
+0002-fix-segfault-when-using-ECDSA-keys.patch


Bug#996875: aide: 31_aide_spamassassin needs update for SpamAssassin 3.4.6

2021-12-31 Thread Marc Haber
On Mon, Dec 13, 2021 at 08:50:13PM +0100, Marc Haber wrote:
> I have committed the change to git.

I have written a new rule that is a bit sophisticated which calls
dpkg-query to find out which version of spamassassin is installed,
mangles the number into the correct format and uses that as input for
the proper rules. Things will be in the next upload in the new year.

Greetings
Marc


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



Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

2021-12-31 Thread Paul Gevers

Hi Raphaël,

Thanks for reporting.

On 29-12-2021 11:44, Raphaël Hertzog wrote:

Usage of --pin-packages=kali-dev=src:foo results in a file like this
in /etc/apt/preferences.d/autopkgtest-kali-dev

Package:  foo
Pin: release a=kali-dev
Pin-Priority: 995

Unfortunately the "a=kali-dev" only matches on the "Suite" or "Archive"
field in the Release file, and not on the "Codename" field (which in my
caces was the only field available).

I noticed that /etc/apt/preferences.d/autopkgtest-default-release uses
another syntax that seems to cover more cases:

Package: *
Pin: release kali-rolling
Pin-Priority: 990

However that syntax doesn't seem to be documented in apt_preferences.
If it's correct and allows to check on either of the 3 fields, then
we should likely use the same syntax in both files.

Otherwise I would like to suggest to create two entries, one with
"Pin: release a=foo" and one with "Pin: release n=foo" so that
we are sure to match on any of the 3 fields.


I'll have to check and think about this. I remember that I had lots of 
issues with coming up with changes to autopkgtest that also worked for 
Ubuntu, as they use the same Codename for the real Suite and the 
*-proposed Suite (which they call pocket). I don't recall if that was 
with respect to pinning or other aspects of autopkgtest and it's 
requirement to manipulate where packages should be installed from. 
Before committing your proposal I need to understand that I'm not 
breaking existing valid configurations too.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1002709: webext-ublock-origin-firefox: ublock-origin makes firefox-esr 91 consumes 100% of a CPU core

2021-12-31 Thread Markus Koschany
Hi,

thanks for the report. If you install version 1.40.2+dfsg-1 from unstable, does
this resolve your problem? I have noticed similar issues with Firefox on
websites which make heavy use of Javascript but I don't experience them with
Chromium. 

Regards,

Markus


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


Bug#1002309: Further info

2021-12-31 Thread Maxime Chambonnet

> What is the name of this feature in the user interface, so that we can
> search for it in the source code? Is it an extension or is it built-in
> to gnome-shell?

The feature is hot-corner I believe, built-in Gnome.

> Can you reproduce this issue without dash-to-dock being enabled?

I couldn't reproduce within a few days: I'll close this issue and open one
at dash-to-dock.

BR, Maxime



Bug#1001776: yt-dlp: further improve 0002-Disable-upstream-s-autoupdate-mechanism.patch

2021-12-31 Thread Christoph Anton Mitterer
Control: reassign -1 yt-dlp
Control: retitle -1  yt-dlp: further improve 
0002-Disable-upstream-s-autoupdate-mechanism.patch

Hey Uni 193.

First, thanks for maintaining this.

Are you going to do that in https://salsa.debian.org/debian/yt-dlp ?

I'd have written an update to 0002-Disable-upstream-s-autoupdate-
mechanism.patch, which completely removes the run_update and
update_self functions... (better not have it in the code at all, so it
cannot be "accidentally" called by some other place in the code).


Cheers,
Chris.



Bug#1002916: [pkg-php-pear] Bug#1002916: RFS: php-nesbot-carbon/2.55.2-1 [RC] -- simple PHP API extension for DateTime

2021-12-31 Thread David Prévot

Hi Robin,

Le 31/12/2021 à 12:56, Robin Gustafsson a écrit :
[…]

I am looking for a sponsor for my package "php-nesbot-carbon":


I looked at the VCS and all your changes look (more than) fine, thanks 
(I only skimmed at upstream changes, but trust you did due diligence). 
You may also wish to build-depend on dh-sequence-phpcomposer (eventually 
instead of pkg-php-composer) instead of using --with phpcomposer in d/rules.


Anyway, I just granted you DM rights on this package so you can upload 
it yourself (do tell if you want me to upload it directly in the mean time).


When will you find enough time to go through the DM process? ;).

Cheers

David


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption

2021-12-31 Thread Matthias Andree

Am 31.12.21 um 16:32 schrieb Karsten:

Package: fetchmail
Version: 6.4.16-4+deb11u1
Severity: important

I upgraded the server from Debian 9 to 11 and afterwards it seems not possible 
to get fetchmail to work.

I tried every possible option of ssl and sslproto, but fetchmail can't fetch 
the mails.
The log says:

fetchmail: Trying to connect to 185.11.xxx.xxx/993...connected.
fetchmail: Server certificate:
fetchmail: Issuer Organization: mydomain
fetchmail: Issuer CommonName: mydomain.de
fetchmail: Subject CommonName: mydomain.de
fetchmail: mydomain.de key fingerprint: 
7C:CA:43:33:2A:12:B6:8D:83:3C:6E:88:0F:40:4B:6F
fetchmail: Server certificate verification error: self signed certificate
fetchmail: Missing trust anchor certificate:
/C=DE/ST=germany/L=here/O=mydomain/OU=Privacy/CN=mydomain.de/emailAddress=webmas...@mydomain.de
fetchmail: This could mean that the root CA's signing certificate is not in the 
trusted CA certificate location, or that
c_rehash needs to be run on the certificate directory. For details, please see 
the documentation of --sslcertpath and
--sslcertfile in the manual page. See README.SSL for details.
fetchmail: OpenSSL reported: error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed
fetchmail: mydomain.de: SSL connection failed.


It is possible to work with Tunderbird (Debian11) direct with the mailserver 
(Dovecot on Debian 8), but not to download
the emails with fetchmail.

What must be done to get it working again?


Unless you own "mydomain.de" you've now hit innocent bystanders, and in
that case, making up log data with a domain you do not own is not helpful.

If Thunderbird can fetch, either it has a local trust setting, or you've
missed installing the ca-certificates package, or, as László suggested,
the certificate is self-signed and you have not installed the signing
CA's certificate in the trust store.



Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption

2021-12-31 Thread GCS
Hi Karsten,

On Fri, Dec 31, 2021 at 4:36 PM Karsten  wrote:
> I upgraded the server from Debian 9 to 11 and afterwards it seems not 
> possible to get fetchmail to work.
>
> I tried every possible option of ssl and sslproto, but fetchmail can't fetch 
> the mails.
> The log says:
[...]
> fetchmail: Server certificate verification error: self signed certificate
> fetchmail: Missing trust anchor certificate:
> /C=DE/ST=germany/L=here/O=mydomain/OU=Privacy/CN=mydomain.de/emailAddress=webmas...@mydomain.de
> fetchmail: This could mean that the root CA's signing certificate is not in 
> the trusted CA certificate location, or that
> c_rehash needs to be run on the certificate directory. For details, please 
> see the documentation of --sslcertpath and
> --sslcertfile in the manual page. See README.SSL for details.
[...]
> What must be done to get it working again?
 Did you read the verbose information? Your server uses a self-signed
certificate, which doesn't have any trust. You can supply the client
side certificate with --sslcertfile or (by shooting yourself on the
foot) you can disable the certificate validation setting with
--nosslcertck.

Regards,
Laszlo/GCS



Bug#1002544: mpc 0.34 is not compatible with older servers

2021-12-31 Thread kaliko

Hi Nicolas,

Thanks for your report.

On 12/23/21 9:05 PM, Nicolas George wrote:

mpc 0.34 from Debian Bookworm/sid is not compatible with older versions
of the server or protocol. For example:

cigaes@aimlin ~ $ mpc -h 10.0.1.19 version
warning: MPD 0.21 required
mpd version: 0.19.0

> […]

0.19 is quite old, last MPD release in this branch was in 13 Dec 2016 / 
v0.19.26. MPD with protocol <0.20 is available in Debian old-old-stable 
only (aka stretch).



(10.0.1.19 is running mopidy 2.2.2-1 from Buster; upgrading it is
desirable but not an option right now.)


Well the problem here is mopidy actually. modpidy is stuck with 0.19.0 
in master [0], the issue is known though [1].


I understand introducing mpc 0.34 broke with mopidy and it is annoying 
in your setup, but mopidy MPD protocol support is partial when not 
broken. I've myself stumbled upon issues with it and had to work around 
breakage in my own client.


Unfortunately mopidy-mpd plugin need some care.


If mpc 0.34 cannot be made to work with a 0.19 server, then Debian
should offer the possibility to install mpc 0.33 in parallel, since
users may not control the version of the server they want to connect.


MPD project is actually leading the development of the protocol, mopidy 
should follow. As I wrote, protocol 0.19 is not even in old-stable, I 
don't think it's worth shipping mpc 0.33 in parallel (adds confusion for 
users and extra work for maintainers).


Let's hope the issue [1] will be dealt with in time for bookworm.

Cheers,
k

[0] 
https://github.com/mopidy/mopidy-mpd/blob/master/mopidy_mpd/protocol/__init__.py

[1] https://github.com/mopidy/mopidy-mpd/issues/47



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1002142: shasta: FTBFS: PythonModule.cpp:40:29: error: expected primary-expression before ‘(’ token

2021-12-31 Thread Nilesh Patra
forwarded -1 https://github.com/chanzuckerberg/shasta/issues/274

Hopefully upstream fixes it soonish

Regards,
Nilesh


signature.asc
Description: PGP signature


Bug#1002387: pydantic: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

2021-12-31 Thread Sandro Tosi
On Fri, Dec 31, 2021 at 3:00 AM Andreas Tille  wrote:
>
> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/samuelcolvin/pydantic/issues/3604
>
> Hi,
>
> I assumed I can fix the issue with a simple patch[1] but with this patch

setting export PYBUILD_TEST_ARGS=-Wignore is enough here

> the test suite is running into other errors.  Thus I reported the issue
> upstream

this is not an upstream issue, but it's related to mypy being a newer
version in Debian than what upstream expected. If you check the
upstream repo, you can see there are some PRs to support mypy 0.930

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#1002918: RFS: lebiniou-data/3.64.0-1 -- datafiles for Le Biniou

2021-12-31 Thread Olivier Girondel



Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou-data":

  * Package name: lebiniou-data
Version : 3.64.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

 lebiniou-data - datafiles for Le Biniou

The package appears to be lintian-clean.

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

   https://mentors.debian.net/package/lebiniou-data

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.64.0-1.dsc

Changes since the last upload:

  * New upstream release 3.64.0.
  * debian/test/control: Depends: lebiniou (>= 3.64.0).

Regards,

--
Olivier Girondel



Bug#1002917: RFS: lebiniou/3.64.0-1 -- user-friendly, powerful music visualization / VJing tool

2021-12-31 Thread Olivier Girondel



Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: lebiniou
Version : 3.64.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

   lebiniou - user-friendly, powerful music visualization / VJing tool

The package appears to be lintian-clean.

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

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

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.64.0-1.dsc

Changes since the last upload:

  * New upstream release 3.64.0.
  * debian/control: Depends: Removed libjs-jquery, libjs-jquery-ui.
  * debian/control: Depends, Breaks, Replaces: Bump lebiniou-data to 
3.63.0.

  * debian/test/control: Depends: lebiniou-data (>= 3.64.0)
  * debian/test/control: Depends: Removed lebiniou.

Regards,

--
Olivier Girondel



Bug#1002915: ITS: xdelta

2021-12-31 Thread Jelmer Vernooij
On Fri, Dec 31, 2021 at 05:48:46PM +0100, Andrej Shadura wrote:
> This package hasn’t been updated by the current maintainer since 2009, and
> was not in good shape. Multiple NMUs have fixed release-critical bugs and
> improved the state of this package, but it needs somebody to respond to
> bugs and fix them in a more timely fashion.
> 
> As a result, I am filing an ITS (Intent to Salvage) request against package
> xdelta according to section 5.12 in Debian's Developers' Reference.
> 
> I would like to maintain this package in a team with other interested
> parties, if any appear (potential candidates in Cc).
FWIW I'd be interested in co-maintaining.


signature.asc
Description: PGP signature


Bug#1002916: RFS: php-nesbot-carbon/2.55.2-1 [RC] -- simple PHP API extension for DateTime

2021-12-31 Thread Robin Gustafsson
Package: sponsorship-requests
Severity: important
X-Debbugs-Cc: Debian PHP PEAR Maintainers 

Dear mentors and PHP PEAR Team,

I am looking for a sponsor for my package "php-nesbot-carbon":

 * Package name: php-nesbot-carbon
   Version : 2.55.2-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://carbon.nesbot.com/
 * License : Expat
 * Vcs : https://salsa.debian.org/php-team/pear/php-nesbot-carbon
   Section : php

It builds those binary packages:

  php-nesbot-carbon - simple PHP API extension for DateTime

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

  https://mentors.debian.net/package/php-nesbot-carbon/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/php-nesbot-carbon/php-nesbot-carbon_2.55.2-1.dsc

Changes since the last upload:

 php-nesbot-carbon (2.55.2-1) unstable; urgency=medium
 .
   * New upstream version 2.55.2
   * Avoid the Symfony < 5 polyfill used for tests (Closes: #1000654, #1002234)
   * Bump Standards-Version
   * Increase debhelper-compat level
   * Remove Salsa CI config
   * Replace git attributes with uscan's gitexport=all
   * Rename main branch to debian/latest (DEP-14)
   * Mark test dependencies with build profile spec
   * Set field Upstream-Name in debian/copyright
   * Install a pkg-php-tools autoloader file
   * Generate phpab templates at build time


Please also consider granting me DM upload rights for this package.

Regards,
Robin



Bug#1002915: ITS: xdelta

2021-12-31 Thread Andrej Shadura
Package: src:xdelta
Severity: important
X-Debbugs-Cc: Ian Jackson , Jelmer Vernooij 


Hi,

This package hasn’t been updated by the current maintainer since 2009, and
was not in good shape. Multiple NMUs have fixed release-critical bugs and
improved the state of this package, but it needs somebody to respond to
bugs and fix them in a more timely fashion.

As a result, I am filing an ITS (Intent to Salvage) request against package
xdelta according to section 5.12 in Debian's Developers' Reference.

I would like to maintain this package in a team with other interested
parties, if any appear (potential candidates in Cc).

-- 
Cheers,
  Andrej


Bug#1002914: userv: FBTFS

2021-12-31 Thread Aurelien Jarno
Source: userv
Version: 1.2.1~beta2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

userv fails to build from source:
| dh_auto_configure
|   ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking
| checking for gcc... gcc
| checking whether the C compiler works... yes
| checking for C compiler default output file name... a.out
| checking for suffix of executables... 
| checking whether we are cross compiling... no
| checking for suffix of object files... o
| checking whether the compiler supports GNU C... yes
| checking whether gcc accepts -g... yes
| checking for gcc option to enable C11 features... none needed
| checking how to run the C preprocessor... gcc -E
| checking for a BSD-compatible install... /usr/bin/install -c
| checking for md5sum... md5sum
| checking for socket in -lsocket... no
| checking for setenv... yes
| checking for strsignal... yes
| checking for vsnprintf... yes
| checking for grep that handles long lines and -e... /bin/grep
| checking for egrep... /bin/grep -E
| checking for EPROTO... yes
| checking for LOG_AUTHPRIV... yes
| checking for WCOREDUMP... yes
| checking your C compiler... works
| checking __attribute__((,,))... yes
| checking __attribute__((noreturn))... yes
| checking __attribute__((unused))... yes
| checking __attribute__((format...))... yes
| checking GCC warning flag(s) -Wall -Wno-implicit... no
| checking GCC warning flag(s) -Wwrite-strings... ok
| checking GCC warning flag(s) -Wpointer-arith... ok
| checking GCC warning flag(s) -Wimplicit -Wnested-externs... ok
| will build version 1.2.1~beta2
| configure: creating ./config.status
| config.status: creating Makefile
| config.status: creating config.h
| make[1]: Leaving directory '/<>'
|debian/rules override_dh_auto_build
| make[1]: Entering directory '/<>'
| /usr/bin/make OPTIMISE= XCFLAGS="-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" 
XCPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" XLDFLAGS="-Wl,-z,relro" all docs
| make[2]: Entering directory '/<>'
| cat common.h config.h config.status Makefile | md5sum \
|   | sed -e 's/  -$//; s/../0x&,/g; s/,$//;' \
|   >pcsum.h.new
| cmp pcsum.h.new pcsum.h || mv -f pcsum.h.new pcsum.h
| cmp: pcsum.h: No such file or directory
| gcc -g  -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE -Wwrite-strings -Wpointer-arith 
-Wimplicit -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -DVERSION='"1.2.1~beta2"' -DVEREXT='"std"'  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o overlord.o 
overlord.c
| m4  -- tokens.h.m4 >tokens.h.new && mv tokens.h.new tokens.h
| gcc -g  -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE -Wwrite-strings -Wpointer-arith 
-Wimplicit -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -DVERSION='"1.2.1~beta2"' -DVEREXT='"std"'  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o process.o 
process.c
| echo '#define VERSION "1.2.1~beta2"' >version.h.new && mv -f version.h.new 
version.h
| gcc -g  -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE -Wwrite-strings -Wpointer-arith 
-Wimplicit -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -DVERSION='"1.2.1~beta2"' -DVEREXT='"std"'  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o servexec.o 
servexec.c
| m4  -- lexer.l.m4 >lexer.l.new && mv lexer.l.new lexer.l
| flex  -t lexer.l > lexer.c
| /bin/sh: 1: flex: not found
| make[2]: *** [: lexer.c] Error 127
| make[2]: Leaving directory '/<>'
| make[1]: *** [debian/rules:20: override_dh_auto_build] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:12: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

The full build log can be found there:
https://buildd.debian.org/fetch.php?pkg=userv=amd64=1.2.1%7Ebeta2=1640811612=0



Bug#1002913: openttd: FBTFS

2021-12-31 Thread Aurelien Jarno
Source: openttd
Version: 12.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

openttd fails to build from source:
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
|dh_cmake_install -a -O--buildsystem=cmake
| -- Install configuration: "RelWithDebInfo"
| -- Installing: /<>/debian/openttd/usr/games/openttd
| -- Install configuration: "RelWithDebInfo"
| -- Installing: 
/<>/debian/openttd/usr/share/applications/openttd.desktop
| -- Install configuration: "RelWithDebInfo"
| -- Installing: 
/<>/debian/openttd/usr/share/doc/openttd/COPYING.md
| -- Installing: /<>/debian/openttd/usr/share/doc/openttd/README.md
| -- Installing: 
/<>/debian/openttd/usr/share/doc/openttd/changelog.txt
| -- Installing: 
/<>/debian/openttd/usr/share/doc/openttd/multiplayer.md
| -- Installing: 
/<>/debian/openttd/usr/share/doc/openttd/known-bugs.txt
|debian/rules execute_after_dh_install
| make[1]: Entering directory '/<>'
| # Prevent installing duplicate license file
| rm debian/openttd/usr/share/doc/openttd/COPYING.md
| # These are unused
| rm -r debian/openttd-data/usr/share/pixmaps
| rm: cannot remove 'debian/openttd-data/usr/share/pixmaps': No such file or 
directory
| make[1]: *** [debian/rules:46: execute_after_dh_install] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:7: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

The full build log can be found there:
https://buildd.debian.org/fetch.php?pkg=openttd=amd64=12.1-1=1640717943=0



Bug#1002912: buster-pu: package graphicsmagick/1.4+really1.3.35-1~deb10u2

2021-12-31 Thread GCS
Package: release.debian.org
User: release.debian@packages.debian.org
Tags: buster
Severity: normal

Hi RMs,

There's a low priority security issue (CVE-2020-12672: heap-based
buffer overflow in ReadMNGImage in coders/png.c) in GraphicsMagick in
Buster.
Thorsten Alteholz backported the fix for this package version, debdiff
is attached. It would be nice if it can be accepted.

Thanks in advance,
Laszlo/GCS
diff -Nru graphicsmagick-1.4+really1.3.35/debian/changelog graphicsmagick-1.4+really1.3.35/debian/changelog
--- graphicsmagick-1.4+really1.3.35/debian/changelog	2020-04-18 18:30:17.0 +0200
+++ graphicsmagick-1.4+really1.3.35/debian/changelog	2021-12-31 16:41:12.0 +0100
@@ -1,3 +1,11 @@
+graphicsmagick (1.4+really1.3.35-1~deb10u2) buster; urgency=high
+
+  [ Thorsten Alteholz  ]
+  * CVE-2020-12672
+Fix for a heap-based buffer overflow in ReadMNGImage() in coders/png.c.
+
+ -- Laszlo Boszormenyi (GCS)   Fri, 31 Dec 2021 16:41:12 +0100
+
 graphicsmagick (1.4+really1.3.35-1~deb10u1) buster-security; urgency=high
 
   * Security backport for Buster.
diff -Nru graphicsmagick-1.4+really1.3.35/debian/patches/CVE-2020-12672.patch graphicsmagick-1.4+really1.3.35/debian/patches/CVE-2020-12672.patch
--- graphicsmagick-1.4+really1.3.35/debian/patches/CVE-2020-12672.patch	1970-01-01 01:00:00.0 +0100
+++ graphicsmagick-1.4+really1.3.35/debian/patches/CVE-2020-12672.patch	2021-12-31 16:41:08.0 +0100
@@ -0,0 +1,49 @@
+Index: graphicsmagick-1.4+really1.3.35/coders/png.c
+===
+--- graphicsmagick-1.4+really1.3.35.orig/coders/png.c	2021-12-30 00:10:05.139412435 +0100
 graphicsmagick-1.4+really1.3.35/coders/png.c	2021-12-30 00:10:05.131412440 +0100
+@@ -5689,7 +5689,28 @@
+ 
+   if (logging)
+ (void) LogMagickEvent(CoderEvent,GetMagickModule(),
+-  "  Processing MNG MAGN chunk");
++  "  Processing MNG MAGN chunk: MB=%u, ML=%u,"
++  " MR=%u, MT=%u, MX=%u, MY=%u,"
++  " X_method=%u, Y_method=%u",
++  mng_info->magn_mb,mng_info->magn_ml,
++  mng_info->magn_mr,mng_info->magn_mt,
++  mng_info->magn_mx,mng_info->magn_my,
++  mng_info->magn_methx,
++  mng_info->magn_methy);
++
++  /*
++If the image width is 1, then X magnification is done
++by simple pixel replication.
++  */
++  if (image->columns == 1)
++  mng_info->magn_methx = 1;
++
++  /*
++If the image height is 1, then Y magnification is done
++by simple pixel replication.
++  */
++  if (image->rows == 1)
++  mng_info->magn_methy = 1;
+ 
+   if (mng_info->magn_methx == 1)
+ {
+@@ -5734,12 +5755,10 @@
+   Image
+ *large_image;
+ 
+-  int
+-yy;
+-
+   long
+ m,
+-y;
++y,
++yy;
+ 
+   register long
+ x;
diff -Nru graphicsmagick-1.4+really1.3.35/debian/patches/series graphicsmagick-1.4+really1.3.35/debian/patches/series
--- graphicsmagick-1.4+really1.3.35/debian/patches/series	2019-07-25 18:43:39.0 +0200
+++ graphicsmagick-1.4+really1.3.35/debian/patches/series	2021-12-31 16:41:08.0 +0100
@@ -1,2 +1,4 @@
 link-demos.diff
 semaphore_O0_ppc64el.patch
+
+CVE-2020-12672.patch


Bug#1002911: ITP: zlmdb -- Object-relational in-memory database layer based on LMDB

2021-12-31 Thread Bastian Germann

Package: wnpp
Severity: wishlist
Owner: Bastian Germann 
Control: block 822183 by -1

* Package name: zlmdb
  Upstream Author : Crossbar.io Technologies GmbH
* URL : https://github.com/crossbario/zlmdb
* License : Expat
  Programming Lang: Python
  Description : Object-relational in-memory database layer based on LMDB

Object-relational in-memory database layer based on LMDB:

High-performance
Supports multiple serializers (JSON, CBOR, Pickle, Flatbuffers)
Supports export/import from/to Apache Arrow
Support native Numpy arrays and Pandas data frames
Automatic indexes
Free software

This is needed as dependency of crossbar. I plan to maintain it under the 
Python Team umbrella.



Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures

2021-12-31 Thread Luis Guzman
On Fri, 9 Apr 2021 10:35:56 +0200 Andreas Beckmann  wrote:
> Control: reopen -1
>
> On 08/04/2021 19.22, Guillem Jover wrote:
> >> Otherwise, I don't see a bug in dpkg for this here. And I'd be
> >> inclined to close this.
>
> I've managed to solve most of the upgrade paths by propagating some
> Conflicts from libreoffice-common to libreoffice-core, s.t. the packages
> get removed right away and are not deconfigured first (which causes the
> Conflicts encountered later to be ignored).
>

I'm looking at the same issue. Is there a diff you could share on the
conflict changes ?

Is that following another bug report?

Best regards



Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2

2021-12-31 Thread Dirk Eddelbuettel


Ok, we are now at a place where the package is tamed somewhat:

 - a lot of the smaller architectures did not build for 1.7.7-4
 - five larger ones (all 64-bit based AFAICT) did
 - so I hard-wired these explicitly in Architecture:

All green now for the ones attempted:
  https://buildd.debian.org/status/package.php?p=tiledb

That may be a basis for moving to 2.5.3 in a few days.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#1002732: needrestart stalled in background when performing update with KDE Discover

2021-12-31 Thread Thomas Liske
Hi Ryan,

needrestart should not block if it is run non-interactive. On Debian it
uses the debconf frontend which also has graphical frontends. Do you
get debconf dialogs in KDE Discover when installing/updating packages
at all? (Sorry I do not have an KDE environment for testing.)


Regards,
Thomas


On Tue, 2021-12-28 at 08:33 -0500, Ryan Armstrong wrote:
> Package: needrestart
> Version: 3.5-5
> Severity: normal
> 
> Dear Maintainer,
> 
> When I performed an update with KDE Discover, I noticed it stalled at
> 99% complete status and would not finish. When I checked the process
> tree with htop, I noticed the following lines from packagekitd and
> needrestart:
> 
>    2629 root   20   0  492M  124M 79624 S  0.0  0.8  0:29.20 ├─
> /usr/libexec/packagekitd
>    2632 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.00 │ 
> ├─ /usr/libexec/packagekitd
>    2634 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.05 │ 
> ├─ /usr/libexec/packagekitd
>   14075 root   20   0  492M  124M 79624 S  0.0  0.8  0:05.78 │ 
> ├─ /usr/libexec/packagekitd
>   14090 root   20   0  494M 99648 50800 S  0.0  0.6  0:00.24 │ 
> └─ /usr/libexec/packagekitd
>   25864 root   20   0  494M 51924  2336 S  0.0  0.3  0:00.00
> │ └─ /usr/libexec/packagekitd
>   25872 root   20   0  2472   704   616 S  0.0  0.0  0:00.00
> │    └─ sh -c test -x /usr/lib/needrestart/apt-pinvoke &&
> /usr/lib/needrestart/apt-pinvoke || true
>   25873 root   20   0 35864 27816  6140 S  0.0  0.2  0:00.64
> │   └─ /usr/bin/perl /usr/sbin/needrestart
> 
> It appears that packagekit is still running needrestart to ask if I
> want to restart systemd services. However, this prompt is obviously
> not
> visible to me through KDE Discover, so it's stuck waiting forever.
> 
> If I use kill on needrestart, the Discover session completes.
> 
> Since, this is an interaction between Discover, packagekit, apt and
> needrestart (possibly others?), I'm not 100% sure this is the right
> place for it. Feel free to reassign if I got it wrong.
> 
> Ryan
> 
> -- Package-specific info:
> needrestart output:
> Your outdated processes:
> akonadi_archive[3076], akonadi_mailfil[3102], akonadi_sendlat[3116],
> akonadi_unified[3117], blueman-applet[2663], Discord[2921, 2924,
> 2967, 2922, 2958, 2917, 3276, 3044], DiscoverNotifie[2571],
> evolution-addre[2767], evolution-alarm[2660], evolution-calen[2742],
> evolution-sourc[2698], goa-daemon[2704], kmail[2936], kwin_x11[2488],
> nextcloud[2656], plasmashell[2554], QtWebEngineProc[6196, 6215, 6194,
> 6193], tracker-miner-f[2674], xdg-desktop-por[2375], xdg-document-
> po[2392], xdg-permission-[2397]
> 
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en_US
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages needrestart depends on:
> ii  binutils   2.37-7
> ii  dpkg   1.21.1
> ii  gettext-base   0.21-4
> ii  libintl-perl   1.26-3
> ii  libmodule-find-perl    0.15-1
> ii  libmodule-scandeps-perl    1.31-1
> ii  libproc-processtable-perl  0.634-1
> ii  libsort-naturally-perl 1.03-2
> ii  libterm-readkey-perl   2.38-1+b2
> ii  perl   5.32.1-6
> ii  xz-utils   5.2.5-2
> 
> Versions of packages needrestart recommends:
> ii  libpam-systemd  249.7-1
> 
> Versions of packages needrestart suggests:
> ii  iucode-tool    2.3.1-1
> ii  libnotify-bin  0.7.9-3
> 
> -- no debconf information



Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption

2021-12-31 Thread Karsten
Package: fetchmail
Version: 6.4.16-4+deb11u1
Severity: important

I upgraded the server from Debian 9 to 11 and afterwards it seems not possible 
to get fetchmail to work.

I tried every possible option of ssl and sslproto, but fetchmail can't fetch 
the mails.
The log says:

fetchmail: Trying to connect to 185.11.xxx.xxx/993...connected.
fetchmail: Server certificate:
fetchmail: Issuer Organization: mydomain
fetchmail: Issuer CommonName: mydomain.de
fetchmail: Subject CommonName: mydomain.de
fetchmail: mydomain.de key fingerprint: 
7C:CA:43:33:2A:12:B6:8D:83:3C:6E:88:0F:40:4B:6F
fetchmail: Server certificate verification error: self signed certificate
fetchmail: Missing trust anchor certificate:
/C=DE/ST=germany/L=here/O=mydomain/OU=Privacy/CN=mydomain.de/emailAddress=webmas...@mydomain.de
fetchmail: This could mean that the root CA's signing certificate is not in the 
trusted CA certificate location, or that
c_rehash needs to be run on the certificate directory. For details, please see 
the documentation of --sslcertpath and
--sslcertfile in the manual page. See README.SSL for details.
fetchmail: OpenSSL reported: error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed
fetchmail: mydomain.de: SSL connection failed.


It is possible to work with Tunderbird (Debian11) direct with the mailserver 
(Dovecot on Debian 8), but not to download
the emails with fetchmail.

What must be done to get it working again?

Cheers
karsten


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

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



Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer

2021-12-31 Thread Camm Maguire
Greetings!

John Paul Adrian Glaubitz  writes:

> Hello!
>
> On 12/30/21 21:18, Camm Maguire wrote:
>>> I have uploaded patched versions of glibc for m68k and sh4 and blocked the
>>> autobuild for glibc on the buildds.
>> 
>> Greetings!  I think you meant blocked autobuild for gcl
>
> No, I didn't. I meant glibc such that the autobuilders are not building the
> glibc package without the patches I mentioned.
>

OK, thanks!  Assuing the patches are now installed...

>> In any case, after a delay, gcl just attempted autobuild on sh4 and failed 
>> the
>> same way.
>
> Well, on sh4, it failed with linker errors. Seems to be a different problem 
> then
> what I previously assumed. Not sure what the problem is then.
>

... this is the exact same failure.  The code in question compiles .c files
discovered by a call to lisp #'directory which in turn loops over
readdir.  It found no files to compile, hence the undefined symbols.
You can also look at the d_type configure test earlier in the build,
which returns "no".  Suggestions?

Take care,

> Adrian

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



Bug#1002850: Re (2): Bug#1002850: udev fails to create a symlink for a SDHC card; udevadm info reports.

2021-12-31 Thread peter
From:   Michael Biebl 
Date:   Fri, 31 Dec 2021 11:52:50 +0100
> Are you aware, that you already have a symlink
> /dev/disk/by-label/GRNSD

I've used a file system label in /etc/fstab.
LABEL=GRNSD /home/peter/MY ext2 defaults,user,users,exec,noauto 0 0
Don't know whether it refers to /dev/disk/by-label/GRNSD or searches 
through labels more directly.

> What's the point in creating another one named /dev/GRNSD ?

No particular point.  The pattern of name assignment I used came from 
documentation.  Might have been in ArchWiki.  Can try this in fstab.
/dev/disk/by-label/GRNSD /home/peter/MY ext2 defaults,user,users,exec,noauto 0 0
The LABEL=GRNSD line above is shorter.  I don't know which is better.

Years ago udev was promoted to obtain reliable names for devices. 
I don't remember advice favouring filesystem labels over udev names. 
Simply followed the most convincing documentation found.

> Do those users/groups exist?

peter@joule:/home/peter$ grep peter /etc/passwd
peter:x:1000:1000:Peter Easthope,,,:/home/peter:/bin/bash

peter@joule:/home/peter$ grep ^peter /etc/group
peter:x:1000:

> Is the rules file embedded in the initramfs?

Haven't checked.  Will rebuild initramfs.

> Is the device plugged in during boot or attached later?

In the desktop system the name is created when the device is connected 
before powering up and just as well when the device is hot plugged.

I have yet to check the two cases carefully on the laptop.

Will try the various alternatives noted above.

Thanks,   ... P.

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W



Bug#1002909: mypy: FTBFS: test failures

2021-12-31 Thread Jakub Wilk
Source: mypy
Version: 0.930-1
Severity: serious
Justification: fails to build from source

mypy FTBFS on i386, armel, armhf:

| === FAILURES 
===
| ___ testSubclassSpecialize1 

| [gw2] linux -- Python 3.10.1 /usr/bin/python3.10
| data: /build/mypy-NUtJu5/mypy-0.930/mypyc/test-data/run-classes.test:484:
| /build/mypy-NUtJu5/mypy-0.930/mypyc/test/test_run.py:137: in run_case
| self.run_case_inner(testcase)
| /build/mypy-NUtJu5/mypy-0.930/mypyc/test/test_run.py:153: in run_case_inner
| self.run_case_step(testcase, step)
| /build/mypy-NUtJu5/mypy-0.930/mypyc/test/test_run.py:320: in run_case_step
| assert_test_output(testcase, outlines, msg, expected)
| E   AssertionError: Invalid output 
(/build/mypy-NUtJu5/mypy-0.930/mypyc/test-data/run-classes.test, line 484)
| - Captured stdout call 
-
| running build_ext
| building 'native' extension
| creating build/temp.linux-i686-3.10
| creating build/temp.linux-i686-3.10/build
| i686-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security 
-g -fwrapv -O2 -g -O2 -ffile-prefix-map=/build/mypy-NUtJu5/mypy-0.930=. 
-fstack-protector-strong -Wformat -Werror=format-security -g1 -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/build/mypy-NUtJu5/mypy-0.930/mypyc/lib-rt 
-I/usr/include/python3.10 -c build/__native.c -o 
build/temp.linux-i686-3.10/build/__native.o -O0 -g1 -Werror 
-Wno-unused-function -Wno-unused-label -Wno-unreachable-code 
-Wno-unused-variable -Wno-unused-command-line-argument 
-Wno-unknown-warning-option -Wno-unused-but-set-variable
| creating build/lib.linux-i686-3.10
| i686-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g 
-fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 
-ffile-prefix-map=/build/mypy-NUtJu5/mypy-0.930=. -fstack-protector-strong 
-Wformat -Werror=format-security -g1 -Wdate-time -D_FORTIFY_SOURCE=2 
build/temp.linux-i686-3.10/build/__native.o -o 
build/lib.linux-i686-3.10/native.cpython-310-i386-linux-gnu.so
| copying build/lib.linux-i686-3.10/native.cpython-310-i386-linux-gnu.so ->
|
| *** Exit status: 1
| - Captured stderr call 
-
| Expected:
|   A
|   B
|   11(diff)
|   A (diff)
|   B (diff)
|   10(diff)
|   B (diff)
| Actual:
|   A
|   B
|   Traceback (most recent call last):(diff)
| File "driver.py", line 7, in(diff)
|   assert b.foo(o) == id(o)  (diff)
|   AssertionError(diff)
|
| ___ testSubclassSpecialize2 

| [gw2] linux -- Python 3.10.1 /usr/bin/python3.10
| data: /build/mypy-NUtJu5/mypy-0.930/mypyc/test-data/run-classes.test:525:
| /build/mypy-NUtJu5/mypy-0.930/mypyc/test/test_run.py:137: in run_case
| self.run_case_inner(testcase)
| /build/mypy-NUtJu5/mypy-0.930/mypyc/test/test_run.py:153: in run_case_inner
| self.run_case_step(testcase, step)
| /build/mypy-NUtJu5/mypy-0.930/mypyc/test/test_run.py:320: in run_case_step
| assert_test_output(testcase, outlines, msg, expected)
| E   AssertionError: Invalid output 
(/build/mypy-NUtJu5/mypy-0.930/mypyc/test-data/run-classes.test, line 525)
| - Captured stdout call 
-
| running build_ext
| building 'native' extension
| creating build/temp.linux-i686-3.10
| creating build/temp.linux-i686-3.10/build
| i686-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security 
-g -fwrapv -O2 -g -O2 -ffile-prefix-map=/build/mypy-NUtJu5/mypy-0.930=. 
-fstack-protector-strong -Wformat -Werror=format-security -g1 -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/build/mypy-NUtJu5/mypy-0.930/mypyc/lib-rt 
-I/usr/include/python3.10 -c build/__native.c -o 
build/temp.linux-i686-3.10/build/__native.o -O0 -g1 -Werror 
-Wno-unused-function -Wno-unused-label -Wno-unreachable-code 
-Wno-unused-variable -Wno-unused-command-line-argument 
-Wno-unknown-warning-option -Wno-unused-but-set-variable
| creating build/lib.linux-i686-3.10
| i686-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g 
-fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 
-ffile-prefix-map=/build/mypy-NUtJu5/mypy-0.930=. -fstack-protector-strong 
-Wformat -Werror=format-security -g1 -Wdate-time -D_FORTIFY_SOURCE=2 
build/temp.linux-i686-3.10/build/__native.o -o 
build/lib.linux-i686-3.10/native.cpython-310-i386-linux-gnu.so
| copying build/lib.linux-i686-3.10/native.cpython-310-i386-linux-gnu.so ->
|
| *** Exit 

Bug#1002706: nftables stateless NAT in raw table mangles fragmented UDP packets also reproducible in linux-image-5.16.0-rc7-amd64-unsigned

2021-12-31 Thread Salvatore Bonaccorso
Hi Steffen,

On Fri, Dec 31, 2021 at 12:11:10PM +0100, Steffen Weinreich wrote:
> Am 31.12.21 um 11:51 schrieb Salvatore Bonaccorso:
> >
> > Can you report this to upstream and keep this downstream bug into the
> > loop (or updated)?
> 
> Yes I will. Do you have a pointer to the right upstream for me?

Thanks for coming back that quickly. I think I would start with:

./scripts/get_maintainer.pl ./net/netfilter/
Pablo Neira Ayuso  (maintainer:NETFILTER)
Jozsef Kadlecsik  (maintainer:NETFILTER)
Florian Westphal  (maintainer:NETFILTER)
"David S. Miller"  (maintainer:NETWORKING [GENERAL])
Jakub Kicinski  (maintainer:NETWORKING [GENERAL])
netfilter-de...@vger.kernel.org (open list:NETFILTER)
coret...@netfilter.org (open list:NETFILTER)
net...@vger.kernel.org (open list:NETWORKING [GENERAL])
linux-ker...@vger.kernel.org (open list)

asking if anyone else needs to be included. But above covers the
relevant netfilter persons and netdev.

Thank you!

Regards,
Salvatore



Bug#1002863: node-react-audio-player: FTBFS with webpack5: Error: Invalid webpack options

2021-12-31 Thread Nicolas Mora

Hello Ayoyimika,

I've updated the webpack patch for webpack 5. Now the build goes 
further, but it fails anyway:


make[1]: Entering directory '/<>'
webpack -p
internal/modules/cjs/loader.js:818
  throw err;
  ^

Error: Cannot find module 'import-local'
Require stack:
- /usr/share/nodejs/webpack-cli/bin/cli.js
- /usr/share/nodejs/webpack/bin/webpack.js
at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:815:15)

at Function.Module._load (internal/modules/cjs/loader.js:667:27)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/usr/share/nodejs/webpack-cli/bin/cli.js:5:21)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1027:10)

at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/usr/share/nodejs/webpack-cli/bin/cli.js',
'/usr/share/nodejs/webpack/bin/webpack.js'
  ]
}
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


I'll upload a new package to unstable with the new patch, let me know if 
you need further help.


/Nicolas



Bug#1002908: lomiri-thumbnailer: 24/25 Test #24: copyright ....................................***Failed 7.57 sec

2021-12-31 Thread Sebastian Ramacher
Source: lomiri-thumbnailer
Version: 3.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sramac...@debian.org

| 24: Test command: /<>/tests/copyright/check_copyright.sh 
"/<>" "/<>/obj-x86_64-linux-gnu"
| 24: Test timeout computed to be: 1500
| 24: /<>/tests/media/testsong.spx: *No copyright* UNKNOWN
| 24: /<>/tests/media/testvideo-180.mp4: *No copyright* UNKNOWN
| 24: /<>/tests/media/testvideo-270.mp4: *No copyright* UNKNOWN
| 24: /<>/tests/media/testvideo-90.mp4: *No copyright* UNKNOWN
| 24/25 Test #24: copyright ***Failed
7.57 sec
| /<>/tests/media/testsong.spx: *No copyright* UNKNOWN
| /<>/tests/media/testvideo-180.mp4: *No copyright* UNKNOWN
| /<>/tests/media/testvideo-270.mp4: *No copyright* UNKNOWN
| /<>/tests/media/testvideo-90.mp4: *No copyright* UNKNOWN

See
https://buildd.debian.org/status/fetch.php?pkg=lomiri-thumbnailer=amd64=3.0.0-1%2Bb1=1640895058=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#1002907: RM: r-cran-rggobi -- ROM: retired upstream

2021-12-31 Thread Dirk Eddelbuettel


Package: ftp.debian.org
Severity: normal

The `rggobi` package for R was a front-end to the `ggobi` interactive
visualization tool (which we still have).  But `rggobi` development ceased,
and the package has been off CRAN since July of 2020.  We should remove it
too.

There is only one reverse-depends in one of the meta-packages which can be
adjusted easily.

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#1000420: irqtop output is messed up by ruby warning

2021-12-31 Thread Axel Beckert
Control: reassign -1 ruby-curses 1.4.9-1+b7
Control: forcemerge 958973 -1

Hi Yvan,

Yvan Masson wrote:
> When running irqtop interactively (without `--batch` option), output is
> messed up on each refresh by lines of this type:
> 
> /usr/bin/irqtop:xxx: warning: rb_safe_level will be removed in Ruby 3.0

Correct.

> Sorry but I did not take time to try it on testing or unstable.

Still present in unstable. I actually reported this myself against
ruby-curses 1.2.4-1 about 1.5 years ago with no reaction so far:
https://bugs.debian.org/958973 (It's also marked as affecting irqtop
btw.)

So the Debian Ruby Extras Maintainers (Cc'ed) should take this as a
reminder that their ruby-curses package is horribly outdated with
regards to upstream releases.

Note to myself: Do not confuse ruby-curses
(https://github.com/ruby/curses) with ruby-ncurses
(https://github.com/sup-heliotrope/ncursesw-ruby). The former is
outdated in Debian, the latter hasn't seen much recent activity
upstream.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#1002906: reportbug should give a hint on how to check if a bug is still available in a newer release of a package

2021-12-31 Thread Thomas Köhler
Package: reportbug
Version: 7.10.3+deb11u1
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?
When I ran "reportbug ifupdown-extra" because of a wrong systemd service
file it provides that I ran into after upgrading from debian 10 to
debian 11, reportbug told me newer release(s) were already available in
testing and unstable and I should verify whether or not the bug still
exists there. However reportbug didn't tell me how to do this.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I searched for a while to find a way to access the source of
ifupdown-extra.

   * What was the outcome of this action?
I finally found the source of the package after a searching on
packages.debian.org

   * What outcome did you expect instead?
reportbug should point me to the correct place directly, like in this
case for example to
https://packages.debian.org/source/bookworm/ifupdown-extra for the new
release in testing.
A more novice user wouldn't have been able to verify if the bug he is
about to report was already fixed because he would be lost how to find
the source.


-- Package-specific info:
** Environment settings:
EDITOR="/usr/bin/vim"
PAGER="less"
INTERFACE="text"

** /home/thomas/.reportbugrc:
reportbug_version "7.5.3~deb10u1"
mode standard
ui text
email "jean-...@picard.franken.de"

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

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

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3+deb11u1
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf-utils   1.5.77
ii  debsums 3.0.2
ii  dlocate 1.07+nmu1
pn  emacs-bin-common
ii  file1:5.39-3
ii  gnupg   2.2.27-2
ii  postfix [mail-transport-agent]  3.5.6-1+b1
ii  python3-urwid   2.1.2-1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information



Bug#1002905: ITP: schoolkit -- Tools ordinarily available in school kits for geometry

2021-12-31 Thread Georges Khaznadar
Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: schoolkit
  Version : 0.1
  Upstream Author : Georges Khaznadar 
* URL : https://salsa.debian.org/georgesk/schoolkit
* License : GPL-3+
  Programming Lang: Javascript
  Description : Tools ordinarily available in school kits for geometry

 This JavaScript library allows one to insert easily rulers, protractors,
 squares, and so on. All tools are interactive, can be used to do
 on-screen measurements, or to draw simple geometric forms.
 .
 If the package apache2 is installed, a short documentation and a demo
 are available at http://localhost/javascript/schoolkit/index.html

-
So far, I did not find javascript libraries making it easy to
insert geometric tools inside a web page, to help students to inspect
windows' contents. So I wrote on from scratch. The version 0.1 provides
easy-to-insert rulers, protractors and squares; a short explanation is
provided to enable developers to add other tools, with the same features:
draggable to translate or to rotate the tool around its defined center.

This package complies with current standards and it is easily extended,
so I should not have much hassle with its maintenance.



Bug#1002904: ksmbd-tools: Please facilitate the ksmbd-tools use e.g. providing a systemd unit

2021-12-31 Thread Salvatore Bonaccorso
Source: ksmbd-tools
Version: 3.4.3-1
Severity: wishlist
X-Debbugs-Cc: car...@debian.org

Hi

Thanks for packaging ksmbd-tools. Would it be an idea to provide a
systemd unit which facilitates the use of ksmbd? A couple of ideas:

In a ExecStartPre (or better options?) try to load the ksmbd kernel
module which is required to be loaded.

Provide ExecStart, ExecStop directives according to the README to help
starting and reloading the ksmbd service. In such a case does
ksmbd.mountd needs to bestarted with -s / --systemd?

Have a condition (ConditionPathExists?) on /etc/ksmbd/smb.conf
presence for trying to start the service.

Other ideas?

Regards,
Salvatore



Bug#834724:

2021-12-31 Thread Shane Burton



Bug#1002903: python3-openpyxl: no longer depends on jdcal

2021-12-31 Thread Nis Martensen
Package: python3-openpyxl
Version: 3.0.9-1
Severity: minor
X-Debbugs-Cc: nis.marten...@web.de

Since version 3.0.7 openpyxl no longer depends on jdcal, so the
dependency of the python3-openpyxl package on python3-jdcal can be dropped.

Not sure if jdcal has any other reverse dependencies in debian; it may
make sense to remove it from debian if there aren't any.



Bug#997029: pysph: FTBFS in testing and unstable

2021-12-31 Thread Antonio Valentino

Dear Graham,
sorry for the late reply.


On Fri, 22 Oct 2021 18:45:01 +0200 Graham Inggs  wrote:

Source: pysph
Version: 1.0~b0~20191115.gite3d5e10-5
Severity: serious
Tags: ftbfs

Hi Maintainer

As can be seen in reproducible builds [1], pysph sometimes FTBS in
both testing and unstable.  I've copied what I hope is the relevant
part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/pysph.html


=== FAILURES ===
_ MPIReduceArrayTestCase.test_parallel_reduce __

self = 

@mark.parallel
def test_parallel_reduce(self):
args = ['--directory=%s' % self.root]
>   run_parallel_script.run(
filename='simple_reduction.py', args=args, nprocs=nprocs, path=path
)

pysph/parallel/tests/test_parallel.py:101:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

filename = 'simple_reduction.py', args = ['--directory=/tmp/tmpr8h_5ft1']
nprocs = 2, timeout = 30.0
path = 
'/build/1st/pysph-1.0~b0~20191115.gite3d5e10/.pybuild/cpython3_3.9/build/pysph/parallel/tests'

def run(filename, args=None, nprocs=2, timeout=30.0, path=None):
"""Run a python script with MPI or in serial (if nprocs=1).
Kill process
if it takes longer than the specified timeout.

Parameters:
---
filename - filename of python script to run under mpi.
args - List of arguments to pass to script.
nprocs - number of processes to run (1 => serial non-mpi run).
timeout - time in seconds to wait for the script to finish running,
else raise a RuntimeError exception.
path - the path under which the script is located
Defaults to the location of this file (__file__), not curdir.

"""
if args is None:
args = []
file_path = abspath(join(path, filename))
cmd = [sys.executable, file_path] + args
if nprocs > 1:
cmd = ['mpiexec', '-n', str(nprocs)] + cmd



The package seems to build correctly now on all platforms that provide 
the required dependencies.
Also the status in debci [1] seems to be fine (please not that the 
package is currently not buildable on some platform).


In the past there was some issue related to some weird behavior of mpi 
libraries but now the problem seems to be solved.


Do you have an updated pointer to a build failure?
... or can we consider to close or at least reduce the severity of this 
issue?


[1] https://ci.debian.net/packages/p/pysph/


kind regards

--
Antonio Valentino



Bug#958682: node-jsonld: Remove dependency to node-request

2021-12-31 Thread Yadd

Hi,

updating node-jsonld is enough to fix this issue:

  $ pkgjs-depends jsonld

  # jsonld@5.2.0 (node-jsonld)
  DEPENDENCIES:
libjs-json (canonicalize)
node-fetch (node-fetch)
node-lru-cache (lru-cache)
node-rdf-canonize (rdf-canonize)

  MISSING:
  jsonld
   └── @digitalbazaar/http-client (1.2.0)
   └── esm (3.2.25)
   └── ky (0.25.1)
   └── ky-universal (0.8.2)
   └── abort-controller (3.0.0)
   └── event-target-shim (5.0.1)

Else we can simply remove this package from Debian since it seems 
useless (no reverse dependencies).


Cheers,
Yadd



Bug#1002902: yarnpkg: Drop dependency to node-request-capture-har

2021-12-31 Thread Yadd
Package: yarnpkg
Version: 1.22.10+~cs22.25.14-5
Severity: important

node-request-capture-har is a wrapper around deprecated node-request. It
should be removed from Debian bookstrom.

Thus node-yarnpkg should remove this dependency.



Bug#1002901: node-request-capture-har is a wrapper around deprecated node-request

2021-12-31 Thread Yadd
Package: node-request-capture-har
Version: 1.2.2-2
Severity: serious
Tags: upstream security
Justification: security
X-Debbugs-Cc: Debian Security Team 

node-request-capture-har is usable only as a wrapper around deprecated
node-request. Then it should be removed from Debian bookstorm.



Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

2021-12-31 Thread Ondřej Surý
Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP version to PHP 
8.1

Happy New Year everyone!

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 28. 12. 2021, at 11:00, Paul Gevers  wrote:
> 
> Control: tags -1 confirmed
> Control: severity 1000574 serious
> Control: severity 1000593 serious
> Control: severity 977403 serious
> Control: severity 1000642 serious
> Control: severity 1000654 serious
> Control: severity 1000653 serious
> Control: severity 1000619 serious
> Control: severity 978457 serious
> Control: severity 977385 serious
> Control: severity 1000474 serious
> Control: severity 1002020 serious
> Control: severity 1000650 serious
> Control: severity 1002504 serious
> Control: severity 1000596 serious
> Control: severity 1000571 serious
> Control: severity 977373 serious
> 
> Hi Ondřej,
> 
> On 05-12-2021 22:11, Paul Gevers wrote:
>> I propose we can start the php8.1 transition around Christmas 2021. Does 
>> that work for you Ondřej?
> 
> Assuming you were OK with this timing, I propose you go ahead now.
> 
> Paul



signature.asc
Description: Message signed with OpenPGP


Bug#1002164: rust-alacritty-terminal: FTBFS: build-dependency not installable: librust-signal-hook-registry-1.2+default-dev

2021-12-31 Thread Peter Michael Green

reopen 1002164
thanks

On 21/12/2021 20:27, plugwash wrote:


The more immediate fix, which I have just uploaded as rust-signal-hook
0.1.13-3 is to do what upstream did in signal-hook 0.1.17 and use a caret
dependency instead of a tilde dependency on signal-hook-registry.

Signal-hook 0.3 has now been uploaded, but signal-hook-mio is still in NEW,
so alacritty-terminal's build-depedencies are once-again broken.



Bug#1002900: darktable: FTBFS on arm64

2021-12-31 Thread David Bremner
Package: darktable
Version: 3.8.0-1
Severity: serious
Tags: fixed-upstream
Justification: FTBFS, previously did on this architecture

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

See [1] for the full log.

 __DT_CLONE_TARGETS__ is undefined on aarch64. Fixed upstream in the 
darktable-3.8.x branch.

There are quite a few fixes in that branch, so it may be worth waiting
for a point release (or packaging a snapshot) rather than
cherry-picking a fix for this bug.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=darktable=arm64=3.8.0-1=1640868741=0

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

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

Versions of packages darktable depends on:
ii  libc62.33-1
ii  libcairo21.16.0-5
ii  libcolord-gtk1   0.1.26-2+b1
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-7
ii  libcurl3-gnutls  7.79.1-2
ii  libexiv2-27  0.27.3-3.1
ii  libgcc-s111.2.0-13
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.2-1
ii  libgomp1 11.2.0-13
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.37-1
ii  libgtk-3-0   3.24.31-1
ii  libicu67 67.1-7
ii  libilmbase25 2.5.7-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  liblcms2-2   2.12~rc1-2
ii  liblensfun1  0.3.2-6
ii  libopenexr25 2.5.7-1
ii  libopenjp2-7 2.4.0-3
ii  libosmgpsmap-1.0-1   1.2.0-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1
ii  libpng16-16  1.6.37-3
ii  libpugixml1v51.11.4-1
ii  librsvg2-2   2.50.7+dfsg-2
ii  libsecret-1-00.20.4-2
ii  libsoup2.4-1 2.74.2-3
ii  libsqlite3-0 3.36.0-2
ii  libstdc++6   11.2.0-13
ii  libtiff5 4.3.0-2
ii  libwebp6 0.6.1-2.1
ii  libx11-6 2:1.7.2-2+b1
ii  libxml2  2.9.12+dfsg-5+b1
ii  libxrandr2   2:1.5.2-1
ii  zlib1g   1:1.2.11.dfsg-2

darktable recommends no packages.

darktable suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmHO7G8ACgkQA0U5G1Wq
FSHz1g/+Ov/i1IEujrRSFfdblQ676PJEOaonHAkxOAV0Z4lMAYZXf01c8c0AkSC+
GxDagr0hcDfqEZaxavmaps+D30MUwptBAf/7/Cfj13AFNOZ13Xls2q9jpZfkjYRp
WnIBL9Rapyws6BtphU8LGTNkioVGrMYEMOwYCpLao1uWs4TbHJzhyxZnbxFpHJc4
BTLfXf/ZNZVRX5zTuR37f3qFXO10JjapzMt/Po8gIbRH3bnmsz+JppbJtlzj1a/W
keTibD5cxjllpynUhj8Rz5XDTl3a6GlJeOuhOpMm1pLmk+I4GfWueXrbf5loLj5q
gmvz0RgvjnBZpzx5plR+NPnhL4ryhY8g613feU1MeJlMZmVZSRbFVhDmzCTuFiuo
ZvCHZeMV9u3c6xLR9pKG/t02/MvfEF0LuE8RnD0+fbFm4+jAHwvxVvQLZPVkVL5X
H8Z06GzBC3ehRqxZCAyu2alTX8mqHN3qeHaJ9nfa9M6QToeTXJhroGtVUd94PSxe
kcCFMVUqkP4QRtcVX0w3968YW2GMqaGBAstrg95qSymdzJoatGzSqTo25/rq5fYC
NFJBuJYC/LWCKcT+GY2d8+SN6708aKblC15v1MCRW6ZxjOdTC66rV/1ivaQ2Qbuk
urGmmEJOlVVluAFvH3A+ct3LEkDcDzDCaCe6I6RD+UewW58SLMg=
=W6FW
-END PGP SIGNATURE-



Bug#1002899: ITP: node-devtools-protocol -- Chrome DevTools Protocol JSON

2021-12-31 Thread Andrius Merkys
Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 959412 by -1

* Package name: node-devtools-protocol
  Version : 0.0.801017
  Upstream Author : The Chromium Authors
* URL : https://github.com/ChromeDevTools/devtools-protocol
* License : BSD-3-Clause
  Programming Lang: Javascript
  Description : Chrome DevTools Protocol

The Chrome DevTools Protocol allows for tools to instrument, inspect,
debug and profile Chromium, Chrome and other Blink-based browsers. Many
existing projects currently use the protocol. The Chrome DevTools uses
this protocol and the team maintains its API.

Instrumentation is divided into a number of domains (DOM, Debugger,
Network etc.). Each domain defines a number of commands it supports and
events it generates. Both commands and events are serialized JSON
objects of a fixed structure.

node-devtools-protocol is required to package Puppeteer.

Remark: This package is to be maintained with Debian Javascript
Maintainers at
   https://salsa.debian.org/js-team/node-devtools-protocol



Bug#1002706: nftables stateless NAT in raw table mangles fragmented UDP packets also reproducible in linux-image-5.16.0-rc7-amd64-unsigned

2021-12-31 Thread Steffen Weinreich
Am 31.12.21 um 11:51 schrieb Salvatore Bonaccorso:
>
> Can you report this to upstream and keep this downstream bug into the
> loop (or updated)?

Yes I will. Do you have a pointer to the right upstream for me?


cheerio

Steve



Bug#1002795: [Pkg-mailman-hackers] Bug#1002795: mailman3-web: libapache2-mod-proxy-uwsgi is empty

2021-12-31 Thread Geert Stappers
On Wed, Dec 29, 2021 at 11:35:33AM +0100, Pierre-Elliott Bécue wrote:
> Geert Stappers  wrote on 29/12/2021 at 00:18:38+0100:
> >   ...
> > For users of mailman3 with Apache it means that there is NO connection
> > between the webserver and the Django app.
> >
> > Right now I don't know what the new 'recommends: ` should be.
> > I'm only reporting "Apache webserver seems to mis a WSGI module".

The module is available  and needs to be enabled.

> > FWIW: I intent to report back when I have a working combination
> > of mailman3-web and Apache2 webserver.

The module enabled did bring progress,
it bring me not yet to the wanted mile stone.

 
> Thanks, I admit initially I had no plan on supporting apache2 as I don't
> use it. Jonas did that part and therefore I did not follow at all.
> 
> Yet the changelogs you quote are back before buster release and I'm
> quite sure Jonas had a working thing at that point.

Please intake my ignorance on "mailman3" into account  ;-)

 
> I'm Cc-ing him, so that he can give an input.

Hopefully next year.

Enjoy new years eve  ("silvester")


Groeten
Geert Stappers
-- 
Silence is hard to parse



Bug#1002850: Re (2): Bug#1002850: udev fails to create a symlink for a SDHC card; udevadm info reports.

2021-12-31 Thread Michael Biebl

On 31.12.21 01:46, pe...@easthope.ca wrote:

From: Michael Biebl 
Date:   Thu, 30 Dec 2021 23:56:05 +0100

you posted the same info twice. Please drop the -a


Sorry; this should be from "udevadm info /dev/sdb1".

P: 
/devices/pci:00/:00:11.2/usb1/1-2/1-2:1.0/host3/target3:0:0/3:0:0:0/block/sdb/sdb1
N: sdb1
L: 0
S: disk/by-partuuid/000152b8-01
S: disk/by-uuid/d8082dc5-9243-433c-81bc-6388e3564117
S: disk/by-path/pci-:00:11.2-usb-0:2:1.0-scsi-0:0:0:0-part1
S: disk/by-label/GRNSD


Are you aware, that you already have a symlink
/dev/disk/by-label/GRNSD

What's the point in creating another one named
/dev/GRNSD ?



KERNEL=="sd?1", ATTR{size}=="7434240", SYMLINK+="GRNSD", \
 OWNER="peter", GROUP="users"
 
KERNEL=="sd?1", ENV{ID_SERIAL_SHORT}=="0201202010201000", SYMLINK+="GRNSD", \

 OWNER="peter", GROUP="peter"



Do those users/groups exist? Is the rules file embedded in the 
initramfs? Is the device plugged in during boot or attached later?




OpenPGP_signature
Description: OpenPGP digital signature


Bug#1002706: nftables stateless NAT in raw table mangles fragmented UDP packets also reproducible in linux-image-5.16.0-rc7-amd64-unsigned

2021-12-31 Thread Salvatore Bonaccorso
Hi,

On Thu, Dec 30, 2021 at 12:43:56PM +0100, Steffen Weinreich wrote:
> Hi
> 
> The same behavior is reproducible in
> 
> Linux debian 5.16.0-rc7-amd64 #1 SMP PREEMPT Debian 5.16~rc7-1~exp1
> (2021-12-26) x86_64 GNU/Linux

Can you report this to upstream and keep this downstream bug into the
loop (or updated)?

Regards,
Salvatore



Bug#947179: linux-image-5.3.0-3-amd64: Please provide CoreBoot (Google) firmware drivers

2021-12-31 Thread Salvatore Bonaccorso
Hi Tobias,

On Thu, Dec 30, 2021 at 11:50:18PM +0100, Tobias Gruetzmacher wrote:
> Hi,
> 
> On Mon, Dec 13, 2021 at 10:14:22PM +0100, Uwe Kleine-König wrote:
> > > it would be nice if the Debian kernel would provide drivers to interact
> > > with CoreBoot. As far as I can see, those are "hidden" behind
> > > CONFIG_GOOGLE_FIRMWARE ...
> > 
> > The helptext for GOOGLE_FIRMWARE reads:
> > 
> >   These firmware drivers are used by Google's servers.  They are
> >   only useful if you are working directly on one of their
> >   proprietary servers.  If in doubt, say "N".
> 
> Yes, that is a very unfortunate help text...
> 
> > Is this text wrong, or are you working on Google's servers? In case
> > you're not on Google's servers: Did you verify these settings are
> > beneficial on your machine?
> 
> I'm not working on Google servers, but on a "generic" CoreBoot-device. I
> can confirm that when using linux-image-5.16.0-rc7-amd64-unsigned, I can
> load memconsole-coreboot, which in turn gives me access to CoreBoot logs
> in /sys/firmware/log, so the feature is working as intended!
> 
> (As an aside: The file /sys/firmware/log is world-readable after the
> module is loaded, this might leak some information about the hardware to
> users)

Can you report this to upstream?

Regards,
Salvatore



Bug#1002567: ITP: libjson-schema-modern-perl -- Validate JSON data against a schema

2021-12-31 Thread Andrius Merkys
Hi Damyan,

On 2021-12-24 12:15, Damyan Ivanov wrote:
> JSON::Schema::Modern aims to be a fully-compliant JSON Schema evaluator and
> validator, targeting the currently-latest Draft 2020-12
> (https://json-schema.org/specification-links.html#2020-12).

Thanks for an interesting ITP. I find it nontrivial to understand how
JSON::Schema::Modern is different from JSON::Validator which is already
in Debian. Maybe it is worth asking the upstream.

> Currently the tests fail with AUTOMATED_TESTS=1 in the environment (which
> happens during autopkg-testing).

I may look into this if I find some time.

Best,
Andrius



Bug#1002898: ITP: golang-github-cli-shurcool-graphql -- GraphQL client implementation for Go (GitHub CLI fork)

2021-12-31 Thread Anthony Fok
Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-cli-shurcool-graphql
  Version : 0.0.1-1
  Upstream Author : Dmitri Shuralyov
* URL : https://github.com/cli/shurcooL-graphql
* License : Expat
  Programming Lang: Go
  Description : GraphQL client implementation for Go (GitHub CLI fork)

 Package graphql provides a GraphQL client implementation for Go.
 It is forked from https://github.com/shurcooL/graphql for GitHub CLI "gh".

Reason for packaging: Needed by GitHub CLI "gh"



Bug#1002897: RM: echoping -- RoQA; FTBFS with GCC 10, uninstallable, abandoned upstream

2021-12-31 Thread Axel Beckert
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Dario Minnucci , echop...@packages.debian.org, 
m...@qa.debian.org, Logan Rosen 

Hi,

I suggest to remove echoping from the archive i.e. unstable:

It FTBFS with GCC 10—see https://bugs.debian.org/957161 from April
2020, i.e. more than 1.5 years ago. And yes, it FTBFS already with GCC
10 and that bug report is not part of the more recent rounds of GCC 11
FTBFS bug reports.

That bug report also got a patch proposed about a 3/4 year ago and
shows no maintainer reaction at all, neither before nor after the
posting that patch. (X-Debbugs-Cc'ing Logan, the patch proposer as
well in case he has some interest in this package.)

Because a BinNMU has failed due to this issue, the current binary
package is now uninstallable in Unstable after the libidn11 to
libidn12 transition — as Piuparts also reports.

Additionally the linked upstream homepage
(https://github.com/bortzmeyer/echoping/) is not the current one
anymore and points to https://framagit.org/bortzmeyer/echoping.

On both sites you can read the following statement:

> echoping was a small program to test (approximatively) performances
> of a remote host by sending it requests such as HTTP requests.
>
> echoping is no longer maintained.

So it's probably not worth keeping it up under e.g. the QA team's
umbrella or with an NMU even though a patch is available for nearly a
year. (Or in other words: The sole proper way to continue having this
package in Debian is to defacto taking over upstream maintenance as
well.)

And last but not least its maintainer generally looks quite MIA
(X-Debbugs-Cc'ing the MIA team for that) with a lot of NMUs and most
other packages being or going to be removed from testing or not having
seen an upload since before oldstable, i.e. for about three years:
https://qa.debian.org/developer.php?email=midget%40debian.org (Last
upload of echoping was in 2017 btw.)


Bug#1002595: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"

2021-12-31 Thread Mike Frysinger
On Mon, 27 Dec 2021 21:41:04 +0100, Nis Martensen wrote:
> Debbugs already disables some of the possible types around here:
> https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/cgi/soap.cgi#L49
> I suspect it should not disable the auto-detection completely because at
> least some of the remaining types are actually needed. This means there
> will always remain corner cases where it guesses wrong.

it seems like the use of auto-detection was more for quick prototyping
convenience than it should be relied upon long term.  the schema should
be a fixed thing at this point: every response down to the field and its
type should be written in stone.

> Being prepared for this on the client side is a good idea.
> Python-debianbts solves the problem in get_bug_log() by (mostly)
> ignoring the xsi:type for message bodies and always converting them to
> string.

making every client copy & paste the same set of workarounds for bad server
responses sounds like the wrong trade-off.  at that point, why bother sending
type information in the responses if clients can't rely on them ?

i get that the server is misbehaving now so clients don't have much choice but
to workaround them, but the server response should be fixed nevertheless.



Bug#1002879: python3-pot: ships /usr/lib/python3/dist-packages/benchmarks/*.py

2021-12-31 Thread Gard Spreemann

Andreas Beckmann  writes:

> Package: python3-pot
> Version: 0.8.1+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> python3-pot ships python scripts with generic names at a generic
> location, causing file conflicts with packages doing the same mistake:
>
> /usr/lib/python3/dist-packages/benchmarks
> /usr/lib/python3/dist-packages/benchmarks/__init__.py
> /usr/lib/python3/dist-packages/benchmarks/benchmark.py
> /usr/lib/python3/dist-packages/benchmarks/emd.py
> /usr/lib/python3/dist-packages/benchmarks/sinkhorn_knopp.py
>
> Either these should not be shipped at all or they should be moved
> to a package specific subdirectory.

Thank you for noticing and reporting this! They should not have been
shipped at all. I'll get a new version out ASAP, and also notify
upstream.


 Best,
 Gard


signature.asc
Description: PGP signature


Bug#1002893: libguestfs0: uninstallable on amd64 UEFI systems, should probably depend on grub-pc-bin instead of grub-pc

2021-12-31 Thread Simon McVittie
Package: libguestfs0
Version: 1:1.46.2-3
Severity: grave
Justification: renders package unusable on many systems

libguestfs0 depends on grub-pc on amd64 and i386, but grub-pc cannot be
co-installed with grub-efi-amd64: each of those packages represents
setting x86 BIOS grub or x86_64 EFI grub, respectively, as the active
bootloader.

When I try to upgrade libguestfs0 using aptitude, it suggests removing
grub-efi-amd64 and installing grub-pc instead, which is likely to break
previously-working UEFI systems, particularly if using Secure Boot.
Hopefully apt won't suggest that, though.

It would be better if libguestfs0 could use grub-pc-bin for the appliance:
grub-pc-bin contains the actual binaries from grub-pc (x86 BIOS grub)
without needing to set it as the active bootloader for the host system.
The build scripts for the appliance could still set grub-pc-bin as the
active bootloader in its chroot by using the same techniques as the
grub-cloud package.

Alternatively, if guestfs/supermin support it, the appliance could use
systemd-boot (bootctl) or something from the extlinux/syslinux family,
which might be a little easier than grub to insert into the appliance's
rootfs?

smcv



Bug#1002875: fixed via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001933#76

2021-12-31 Thread shirish शिरीष
fixed 1002875
thanks



Bug#1002838: pdfarranger: Error "Can't convert ObjectHelper" when saving

2021-12-31 Thread Jerome Robert
This is fixed in pdfarranger 1.8.2 by 
https://github.com/pdfarranger/pdfarranger/commit/de8acb310e23cacd8409bd895f9cfbd64af9bf23



Bug#969617: src:python-coverage: New upstream version 6.2

2021-12-31 Thread Ben Finney
Control: retitle -1 src:python-coverage: New upstream version 6.2

Version 6.2 is released as of 2021-11-26
https://coverage.readthedocs.io/en/6.2/changes.html#version-6-2-2021-11-26>.

Since version 5.1, some significant changes are in version 6.2:

* Support Python versions 3.6 – 3.11.
* Data collection is thread-safe.
* The HTML report has been redesigned.
* Emit messages describing where Coverage.py is writing its files.
* Settings ‘skip_covered’ and ‘skip_empty’ can be specified
  separately for HTML report.
* The report commands now have options ‘--precision’, ‘--sort’,
  ‘--no-skip-covered’.
* The report skips branches if the source and destination line are
  not executed.
* The report skips third-party packages.
* The ‘combine’ command has new option ‘--keep’.
* New ‘source_pkgs’ setting to specify only package names.
* More consistent (machine-parseable) output for text report.
* Support for Python 3.10 ‘match’/‘case’ syntax.
* Environment variable ‘COVERAGE_RUN’ set when running code with
  Coverage.py.
* Deprecate the ‘annotate’ feature.

-- 
 \  “Ocean, n. A body of water occupying about two-thirds of a |
  `\ world made for man — who has no gills.” —Ambrose Bierce, _The |
_o__)Devil's Dictionary_, 1906 |
Ben Finney 


signature.asc
Description: PGP signature


Bug#1002891: clone(2): Typo in CLONE_VM

2021-12-31 Thread Philipp Marek
Package: manpages-dev
Version: 5.10-1
Severity: minor
File: /usr/share/man/man2/clone.2.gz
X-Debbugs-Cc: phil...@marek.priv.at


"man clone" says

CLONE_VM (since Linux 2.0)
...
If the CLONE_VM flag is specified and the CLONE_VM flag is not specified, 
...

I guess that's a typo and one should be CLONE_VFORK? But which one?


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

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

Versions of packages manpages-dev depends on:
ii  manpages  5.10-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.9.4-2

-- no debconf information



Bug#959412: Puppeteer status?

2021-12-31 Thread Andrius Merkys
Hi Martina,

On 2021-12-31 02:47, Martina Ferrari wrote:
> I was wondering what is the status of this ITP? I need puppeteer for
> $DAYJOB, and I would prefer to use a proper Debian package.
> 
> It seems not much has happened in the last year in the salsa repo, is
> there much left to be done? I would be happy to give it a go if you are
> not currently working on it..

Thanks for your interest. AFAIR, I got stuck in packaging the JS
dependencies needed by puppeteer. Nevertheless I recall the package was
building mostly successfully and passing its upstream-provided test suite.

Please give me a couple of days to dig a bit deeper into this. If I do
not return in a week with more precise status report, please ping.

Best wishes,
Andrius



Bug#1002387: pydantic: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

2021-12-31 Thread Andreas Tille
Control: tags -1 upstream
Control: forwarded -1 https://github.com/samuelcolvin/pydantic/issues/3604

Hi,

I assumed I can fix the issue with a simple patch[1] but with this patch
the test suite is running into other errors.  Thus I reported the issue
upstream

Kind regards

  Andreas.

[1] 
https://salsa.debian.org/python-team/packages/pydantic/-/blob/master/debian/patches/distutils_is_deprecated.patch

-- 
http://fam-tille.de