Bug#1000372: ITP: ocaml-magic-mime -- OCaml library to map filenames to common MIME types

[Stéphane Glondu]

Le 25/11/2021 à 20:19, Thaddeus H. Black a écrit :
>> * Package name: ocaml-magic-mime
>>   Version : 1.2.0
>>   Upstream Author : Anil Madhavapeddy
>> * URL : https://github.com/mirage/ocaml-magic-mime
>> * License : ISC
>>   Programming Lang: OCaml
>>   Description : OCaml library to map filenames to common MIME types
>>
>>  This library contains a database of MIME types that maps filename
>>  extensions into MIME types suitable for use in many Internet
>>  protocols such as HTTP or e-mail. It is generated from the mime.types
>>  file found in Unix systems, but has no dependency on a filesystem
>>  since it includes the contents of the database as an ML
>>  datastructure.
>>
>> This is a new transitive dependency of ocsigenserver.
> 
> A typical Debian system already has two such
> databases: /etc/mime.types /usr/share/mime/globs
> 
> I do not mean to challenge you, nor to discourage you,
> but am merely curious:  why a third database?

As said in the description: "It is generated from the mime.types file
found in Unix systems, but has no dependency on a filesystem since it
includes the contents of the database as an ML datastructure.". Whether
you consider this worthwhile or not is a personal opinion, I guess.


Cheers,

-- 
Stéphane

Bug#1000631: misreports mismatched-override update-debian-copyright

[Marc Haber]

Package: lintian
Version: 2.113.0
Severity: minor

Hi,

in a yet unpublished branch of the aide package
(https://salsa.debian.org/debian/aide), I get the following pedantic
warning:

W: aide source: mismatched-override update-debian-copyright 2005 vs 2021 
[debian/copyright:103]
W: aide source: mismatched-override update-debian-copyright 2006 vs 2021 
[debian/copyright:58]

debian/source/lintian-overrides says:
aide source: update-debian-copyright 2006 vs 2021 [debian/copyright:58]
aide source: update-debian-copyright 2005 vs 2021 [debian/copyright:103]

The stanza beginning line 58 is:
Files: debian/po/fr.po
Copyright: 2005 Christian Perrier 
2006 Gregory Colpart 
License: GPL-2+
Comment: File is not explicitly licensed

The stanza beginning line 103 is:
Files: debian/po/zh_TW.po
Copyright: 2005 Asho Yeh 
License: GPL-2+
Comment: File is not explicitly licensed

- How am I supposed to override a warning for two lines of copyright
  with differnet years?
- How am I supposed to correctly override the second stanza?

Greetings
Marc


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

Kernel: Linux 5.15.5-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils2.37-10
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012004-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1000630: ITP: libbibtex-parser-perl -- pure Perl BibTeX parser

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 999599

* Package name: libbibtex-parser-perl
  Version : 1.03
  Upstream Author : Gerhard Gossen and Boris Veytsman
* URL : https://metacpan.org/release/BibTeX-Parser
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : pure Perl BibTeX parser

BibTeX::Parser is a pure-Perl BibTeX format parser.

BibTeX::Parser is used by some of unpackaged tools I work with.

Remark: This package is to be maintained with Debian Perl Group at
   https://salsa.debian.org/perl-team/modules/packages/libbibtex-parser-perl

Bug#1000629: update-debian-copyright should probably exclude debian/po

[Marc Haber]

Package: lintian
Version: 2.113.0
Severity: minor

Hi,

the update-debian-copyright check is also applied to the debian/po
subdirectory. Debconf translations ARE actually seldomly touched, so an
older package might actually HAVE translations that have a copyright
that differs from the rest of debian/* AND are probably years old.

Also, the file name of the file with the outdated copyright is not gicen
in the tag context, it is thus not possible to exclude
update-debian-copyright for files in debian/po from the package.

Greetings
Marc


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

Kernel: Linux 5.15.5-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils2.37-10
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012004-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1000622: ser2net: Fails to start on boot since the serial port is not ready

[Marc Haber]

severity #1000622 minor
thanks

On Fri, Nov 26, 2021 at 12:25:24AM +0100, Mario V wrote:
> Distributor ID:   Raspbian
> Description:  Raspbian GNU/Linux 11 (bullseye)

Please try to reproduce the issue on Debian proper.

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#1000628: transition: libotf

[Harshula]

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


Hi Release Team,

Upstream incremented libotf's SONAME from 0 to 1. The latest upstream 
version is packaged and available in experimental. I want to upload it 
to unstable.


Auto-generated tracker:
https://release.debian.org/transitions/html/auto-libotf.html

The following source packages need binNMUs:
m17n-lib
emacs

Ben file:
title = "libotf";
is_affected = .depends ~ "libotf1" | .depends ~ "libotf0";
is_good = .depends ~ "libotf1";
is_bad = .depends ~ "libotf0";

The reverse dependencies were successfully built locally by pbuilder:

$ ldd /usr/lib/x86_64-linux-gnu/libm17n-gui.so | grep otf
libotf.so.1 => /lib/x86_64-linux-gnu/libotf.so.1 (0x7fa9943b8000)

$ ldd /usr/bin/m17n-edit | grep otf
libotf.so.1 => /lib/x86_64-linux-gnu/libotf.so.1 (0x7f6472821000)

$ ldd /usr/bin/emacs-gtk | grep otf
libotf.so.1 => /lib/x86_64-linux-gnu/libotf.so.1 (0x7f7d9456e000)

$ ldd /usr/bin/emacs-lucid | grep otf
libotf.so.1 => /lib/x86_64-linux-gnu/libotf.so.1 (0x7f6686afd000)

Thanks,
Harshula

Bug#1000627: apache2: missing dependency setting

[Yadd]

Le 26/11/2021 à 03:03, westlake a écrit :
> Package: apache2
> Version: 2.4.48-3.1+deb11u1
> Severity: important
> 
> apache2 can fail to start if the user defines a specific interface.
> 
> the workaround meanwhile is to add "network-online.target" to the
> systemd unit.
> 
> The issue noticeably occurs when the user decides to use
> "systemd-networkd" for the configuration rather than
> /etc/network/interfaces.
> 
> A bugreport was initially provided to systemd explaining the problem in
> greater detail, however a lead maintainer replied that the bug is to be
> forwarded to the server package in question.
>  -- a copy of this original bugreport to systemd/systemd-networkd is
> here for further referencing:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000510
> 
> A server should not fail to "start" just because it is using a specific
> interface.
> 
> I attempted to provide the suggestion for systemd/systemd-networkd
> maintainers to give a policy of having "network-online.target" for
> server programs but I was told that the issue is the specific
> server-package in question. (only two server packages that I use often
> have this problem, openssh-server and apache2)
> 
> journalctl -xe -u [package]  -- shows nothing revealing than ".. failed
> to bind to address x.x.x.x". "networkctl" -- all shows green
> highlighting --- the .network definitions are all correct.
> 
> the problem seems to me the systemd policy of having
> network-online.target as a practice for server unit files is not
> enforced enough..
> 
> though the traditional ifup-networking scripts doesn't have this issue
> afaict.
> 
> .. it happens more often when the user opts not to be using the default
> networking.service and instead go with the newer systemd-networkd method
> for bringing up interfaces during the bootup.
> 
> the user here is not at fault, and should be allowed to set specific
> interfaces for the apache2 and ssh service.
> 
> (fwiw, -- prior setting up the workaround, both ssh and apache2 servers
> will both exhibit the same binding-interface error, as shown in journalctl.
> 
> However when starting these services manually: such as,
> systemctl start apache2.service, and
> systemctl start ssh.service
> 
> there is no problem at all starting these up
> 
> The interfaces are set at the system-level.  There is no
> dbus-triggered/Desktop-login interface settings.
> 
> The problem is systemd++network-online.target not set in the unit files.
> 
> Systemd and Server package maintainers should enforce a better policy so
> that simple changes do not affect the ability to start the service.
> )
> (this bugreport is getting cc'd to the ssh package -- as the problem
> also exists with that package)
> thanks

Hi,

I've no talent in systemd, how can I do that? With:

  Wants=network-online.target
  After=network-online.target

in debian/apache*.service?

Bug#996780: gnome-boxes: Systematic system freeze few seconds after launching a Windows WM

[Mathieu R.]

Gunnar question made me question X server, and apparently it's related to
Wayland, cause opening a session with Xorg, i can't reproduce it

Le mar. 23 nov. 2021, 15 h 52, Mathieu R.  a
écrit :

> i'm not, i'm using intel drivers
>
> Le sam. 20 nov. 2021, 18 h 43, Gunnar Hjalmarsson  a
> écrit :
>
>> Are you possibly using a NVIDIA driver? Asking because of this:
>>
>> https://github.com/NVIDIA/egl-wayland/issues/27#issuecomment-951725683
>>
>> --
>> Cheers,
>> Gunnar Hjalmarsson
>>
>

Bug#1000627: apache2: missing dependency setting

[westlake]

Package: apache2
Version: 2.4.48-3.1+deb11u1
Severity: important

apache2 can fail to start if the user defines a specific interface.

the workaround meanwhile is to add "network-online.target" to the 
systemd unit.


The issue noticeably occurs when the user decides to use 
"systemd-networkd" for the configuration rather than 
/etc/network/interfaces.


A bugreport was initially provided to systemd explaining the problem in 
greater detail, however a lead maintainer replied that the bug is to be 
forwarded to the server package in question.
 -- a copy of this original bugreport to systemd/systemd-networkd is 
here for further referencing: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000510


A server should not fail to "start" just because it is using a specific 
interface.


I attempted to provide the suggestion for systemd/systemd-networkd 
maintainers to give a policy of having "network-online.target" for 
server programs but I was told that the issue is the specific 
server-package in question. (only two server packages that I use often 
have this problem, openssh-server and apache2)


journalctl -xe -u [package]  -- shows nothing revealing than ".. failed 
to bind to address x.x.x.x". "networkctl" -- all shows green 
highlighting --- the .network definitions are all correct.


the problem seems to me the systemd policy of having 
network-online.target as a practice for server unit files is not 
enforced enough..


though the traditional ifup-networking scripts doesn't have this issue 
afaict.


.. it happens more often when the user opts not to be using the default 
networking.service and instead go with the newer systemd-networkd method 
for bringing up interfaces during the bootup.


the user here is not at fault, and should be allowed to set specific 
interfaces for the apache2 and ssh service.


(fwiw, -- prior setting up the workaround, both ssh and apache2 servers 
will both exhibit the same binding-interface error, as shown in 
journalctl.


However when starting these services manually: such as,
systemctl start apache2.service, and
systemctl start ssh.service

there is no problem at all starting these up

The interfaces are set at the system-level.  There is no 
dbus-triggered/Desktop-login interface settings.


The problem is systemd++network-online.target not set in the unit files.

Systemd and Server package maintainers should enforce a better policy so 
that simple changes do not affect the ability to start the service.

)
(this bugreport is getting cc'd to the ssh package -- as the problem 
also exists with that package)

thanks

Bug#1000626: openssh-server: missing dependency setting

[westlake]

Package: openssh-server
Version: 1:8.4p1-5
Severity: important

openssh-server can fail to start if the user defines a specific interface.

the workaround meanwhile is to add "network-online.target" to the 
systemd unit.


The issue noticeably occurs when the user decides to use 
"systemd-networkd" for the configuration rather than 
/etc/network/interfaces.


A bugreport was initially provided to systemd explaining the problem in 
greater detail, however a lead maintainer replied that the bug is to be 
forwarded to the server package in question.
 -- a copy of this original bugreport to systemd/systemd-networkd is 
here for further referencing: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000510


A server should not fail to "start" just because it is using a specific 
interface.


I attempted to provide the suggestion for systemd/systemd-networkd 
maintainers to give a policy of having "network-online.target" for 
server programs but I was told that the issue is the specific 
server-package in question. (only two server packages that I use often 
have this problem, openssh-server and apache2)


journalctl -xe -u [package]  -- shows nothing revealing than ".. failed 
to bind to address x.x.x.x". "networkctl" -- all shows green 
highlighting --- the .network definitions are all correct.


the problem seems to me the systemd policy of having 
network-online.target as a practice for server unit files is not 
enforced enough..


though the traditional ifup-networking scripts doesn't have this issue 
afaict.


.. it happens more often when the user opts not to be using the default 
networking.service and instead go with the newer systemd-networkd method 
for bringing up interfaces during the bootup.


the user here is not at fault, and should be allowed to set specific 
interfaces for the apache2 and ssh service.


(fwiw, -- prior setting up the workaround, both ssh and apache2 servers 
will both exhibit the same binding-interface error, as shown in 
journalctl.


However when starting these services manually: such as,
systemctl start apache2.service, and
systemctl start ssh.service

there is no problem at all starting these up

The interfaces are set at the system-level.  There is no 
dbus-triggered/Desktop-login interface settings.


The problem is systemd++network-online.target not set in the unit files.

Systemd and Server package maintainers should enforce a better policy so 
that simple changes do not affect the ability to start the service.

)
(this bugreport is getting cc'd to the apache2 package -- as the problem 
also exists with that package)

thanks

Bug#996350: Problem can be tracked down to ruby-rr

[Daniel Leidert]

I was examining the problem. The problem seems to be ruby-rr 3.x. rabl actually
requires rr 1.x, and with this version it works. I verified this by building
against ruby-rr from Stable. But with ruby-rr 3.x in Testing/Unstable it fails.

I don't have a fix for that.
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1000625: libopencv-dev: Broken pkg-config file

[Adrian Bunk]

Package: libopencv-dev
Version: 4.5.4+dfsg-6
Severity: serious

https://buildd.debian.org/status/logs.php?pkg=mrgingham=1.20-3%2Bb1

...
g++ -Wl,-z,relro -Wl,-z,now -shared -Wl,--default-symver -fPIC 
-Wl,-soname,libmrgingham.so.2 find_grid.o find_blobs.o 
find_chessboard_corners.o mrgingham.o ChESS.o  -llibopencv_stitching.so.4.5.4d 
-llibopencv_alphamat.so.4.5.4d -llibopencv_aruco.so.4.5.4d 
-llibopencv_barcode.so.4.5.4d -llibopencv_bgsegm.so.4.5.4d 
-llibopencv_bioinspired.so.4.5.4d -llibopencv_ccalib.so.4.5.4d 
-llibopencv_dnn_objdetect.so.4.5.4d -llibopencv_dnn_superres.so.4.5.4d 
-llibopencv_dpm.so.4.5.4d -llibopencv_face.so.4.5.4d 
-llibopencv_freetype.so.4.5.4d -llibopencv_fuzzy.so.4.5.4d 
-llibopencv_hdf.so.4.5.4d -llibopencv_hfs.so.4.5.4d 
-llibopencv_img_hash.so.4.5.4d -llibopencv_intensity_transform.so.4.5.4d 
-llibopencv_line_descriptor.so.4.5.4d -llibopencv_mcc.so.4.5.4d 
-llibopencv_quality.so.4.5.4d -llibopencv_rapid.so.4.5.4d 
-llibopencv_reg.so.4.5.4d -llibopencv_rgbd.so.4.5.4d 
-llibopencv_saliency.so.4.5.4d -llibopencv_shape.so.4.5.4d 
-llibopencv_stereo.so.4.5.4d -llibopencv_structured_light.so.4.5.4d 
-llibopencv_phase_unwrapping.so.4.5.4d -llibopencv_superres.so.4.5.4d 
-llibopencv_optflow.so.4.5.4d -llibopencv_surface_matching.so.4.5.4d 
-llibopencv_tracking.so.4.5.4d -llibopencv_highgui.so.4.5.4d 
-llibopencv_datasets.so.4.5.4d -llibopencv_text.so.4.5.4d 
-llibopencv_plot.so.4.5.4d -llibopencv_ml.so.4.5.4d 
-llibopencv_videostab.so.4.5.4d -llibopencv_videoio.so.4.5.4d 
-llibopencv_viz.so.4.5.4d -llibopencv_wechat_qrcode.so.4.5.4d 
-llibopencv_ximgproc.so.4.5.4d -llibopencv_video.so.4.5.4d 
-llibopencv_xobjdetect.so.4.5.4d -llibopencv_objdetect.so.4.5.4d 
-llibopencv_calib3d.so.4.5.4d -llibopencv_imgcodecs.so.4.5.4d 
-llibopencv_features2d.so.4.5.4d -llibopencv_dnn.so.4.5.4d 
-llibopencv_flann.so.4.5.4d -llibopencv_xphoto.so.4.5.4d 
-llibopencv_photo.so.4.5.4d -llibopencv_imgproc.so.4.5.4d 
-llibopencv_core.so.4.5.4d -lpthread -o libmrgingham.so.2.1
/usr/bin/ld: cannot find -llibopencv_stitching.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_alphamat.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_aruco.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_barcode.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_bgsegm.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_bioinspired.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_ccalib.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_dnn_objdetect.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_dnn_superres.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_dpm.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_face.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_freetype.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_fuzzy.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_hdf.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_hfs.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_img_hash.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_intensity_transform.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_line_descriptor.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_mcc.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_quality.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_rapid.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_reg.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_rgbd.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_saliency.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_shape.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_stereo.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_structured_light.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_phase_unwrapping.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_superres.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_optflow.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_surface_matching.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_tracking.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_highgui.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_datasets.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_text.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_plot.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_ml.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_videostab.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_videoio.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_viz.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_wechat_qrcode.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_ximgproc.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_video.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_xobjdetect.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_objdetect.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_calib3d.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_imgcodecs.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_features2d.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_dnn.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_flann.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_xphoto.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_photo.so.4.5.4d
/usr/bin/ld: cannot find -llibopencv_imgproc.so.4.5.4d
/usr/bin/ld: cannot find 

Bug#1000624: dh-raku: Please provide dh-sequence-raku

[gregor herrmann]

Package: dh-raku
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In my understanding, the contemporary way to use debhelper addons is
via dh-sequence-FOO.

I guess for the dh-raku package this means:
- - add "Provides: dh-sequence-raku" in d/control
- - adapt documentation (README.org, maybe more) to promote
  "Build-Depends: dh-sequence-raku" in debian/control
  instead of
  "--with raku" in debian/rules

Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmGgMSdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZHzQ//Ygc8lOusJxNJwv7h5VW6VJ0US6BaCWDrDT1k/E59GXIaqVGEneIG9+ZI
Y9Rg8d9Kfc3PdYzhEYK1Z3bxkDAH1mNfMknaIP14F1LKCyvlkXPWppBUDgoWDYmL
hKhrz3nKVHBzNox7XBBe8nY4XXs0Y6MqkcKDTLFxrLZTCHnIAKgBHoQjJJBiDtc2
QnsfOlTqUNxWemTPzQR66QteQtwF5U7ZUEW8/jyPioGWsk9n7EpQ+Z8QtV4mCYpO
n/T41CO+HqfYiOTJFFJqonWL9gYz56bKeKnPObMWMWDujY0ofQEKY8BIzjr7wHdi
kyExu/q5JJRO7LhK/V44/VXvpl2840av2CFQz8vuUEckNOmfeS3LyU3OAQSrA8sG
xEDe9pqY98NE9YeZ9rV4i3jrnMkwfy/Y1tkSutUkMrt09rZoHz3yK4q/HOIfoKjx
SOGTcXw4jv0pFVdJr7yWkkCP3R2rQiPpZKMD4cNLC1IMBxFKiIsmqasracfOYmN/
rWUdOuHLd/rCVjyVTz4X5yS1nizhqZp+Phqos6cYOKCvt09rCLkugvXiJiuyPeL+
72IT4syzeMjbqxB66IivNlseLBL+1gbLVyaZLjeU7wDpMcUSI/+dIIVgINN+dc3H
1KWMk9tfgCmjd8zlBAd0420EoXse+e2pbEdxBosPxOdQL9EWQuU=
=i+Ht
-END PGP SIGNATURE-

Bug#1000623: The tests hide a programming bug: NameError: uninitialized constant I18n::Inflector::Rails::BadInflectionKind

[Daniel Leidert]

Source: ruby-i18n-inflector-rails
Version: 1.0.7-4.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

While fixing the package for the Ruby 3.0 and Rails 6.1 transition, I
discovered that the tests actually hide a bug in the code. Several tests
throw:

  NameError: uninitialized constant I18n::Inflector::Rails::BadInflectionKind

and indeed, this class is called twice via

  I18n::Inflector::Rails::BadInflectionKind.new()

but I cannot find any definiton. The i18n-inflector gem contains a
I18n::BadInflectionKind class, but it requires to pass the locale as well,
which is not available in the no_inflection_method_for() method.

This looks like a genuine bug and the upstream project hasn't seen any
development since 2013. The only package using this gem is diaspora.

Regards, Daniel


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

Kernel: Linux 5.14.0-4-amd64 (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmGgL9MACgkQS80FZ8KW
0F15bw//f8p2/V2FElGchMN7QUt1JsswDs4NYDOXjGf9OIAA62VQCzP3a5izgYgb
9XFoSyh8DzU1CVXH908+kwHkhbQfVfaQSdj0IopdztCiRztlHgbsYQXLf6meQqpT
9OHBTL4HeUFaObI915IR1F9YmHfL7c9Pu0zwxTjkGwEBmX/5iAtR7NE6YELL2fBT
uvOdqKAcnbc+kf8hbWbVBC/efcx+I7ajdax77q7QYrTnLjjQsdwys878ZxrkYg0p
Tbrm2YE01P3t20PLSIDrsIVNrdA96tru6IyFaqnZZARI/WIi1b8MKryYrPA1/qjd
SczUOFZbgslaWN3nc7RS7ybA5bbAEhF6H3ZORtlEvcGvKLnCa7LKPOqwt3JEh5G+
97XJD/vLOzn26rco2LhuPU35B8Ls1WWT3TPQPr/AdLRdE4jzHepAioy9V2d1EXI3
FmT6KxD4QoJ8e0OcVXr50Abz+Ftmoi4VjEZNJyHV5Nr+icIUFwpoFWPuMJ4FTxyQ
VMGYBYct5Z6C/HiKPn554+BlmhGp9FD7LJIqmHv+kcHmJLdFGHxfTS1cdeZ7uNFc
B9S3aZLG3QBZPL1T2BKsk+D7YOOxGF8ng4AWKqEzxW56KfoGbvF/TllJwXq0VxOm
c/x/1nVsMOrWRaDveDWm03UpJF5o0930G63lOLXHmWEUBYlNNLM=
=a9YU
-END PGP SIGNATURE-

Bug#589682:

[Richard Lewis]

The issue described in this report isnt a bug: $egrep and ${egrep} are
the same. The variable is set indirectly by the code that supports the
'-p' option (which sets a variable for everything in cmdlist)

(However, it seems to me that not every cmd in cmdlist is always
invoked as ${cmd} - something to investigate)

Bug#1000599: Don't require xdg-desktop-portal on Ubuntu i386

[Alberto Garcia]

Control: tags -1 pending

On Thu, Nov 25, 2021 at 07:11:28PM +0100, Sebastien Bacher wrote:
> The Ubuntu i386 archive is a partial one aimed at multiarch purpose
> and doesn't include desktop services as the xdg portal. The
> attached patch which is stacked on top of the recently submitted
> one to disable lto removes the recommends on the portal on that
> distribution and architecture

Thanks, applied.

https://salsa.debian.org/webkit-team/webkit/-/commit/87f7e1bd2d3bd55d123b0b46100a8ac45b9e1b8e

Berto

Bug#1000598: Fail to build with lto

[Alberto Garcia]

Control: tags -1 pending

On Thu, Nov 25, 2021 at 07:00:15PM +0100, Sebastien Bacher wrote:

> Webkitgtk fails to build with lto, that's not a problem for Debian
> at the moment but we carry a delta in Ubuntu where LTO is enabled by
> default. The option shouldn't be an issue for Debian and allows us
> to lower the delta and might be useful for Debian as well at some
> point.

Thanks, applied

https://salsa.debian.org/webkit-team/webkit/-/commit/68941ac2c5f22d2f9a2994c1c73a16bf00bdc5dc

Berto

Bug#999418: chkrootkit: chkproc bogus OooPS, not expected 210672 value

[R Lewis]

On Wed, 10 Nov 2021 18:53:38 + "Dr. David Alan Gilbert" <
li...@treblig.org> wrote:
> Package: chkrootkit
> Version: 0.55-1+b1
> Severity: important
>
> Dear Maintainer,
>   Since upgrade to bullseye I'm seeing chkrootkit warnings of the
> form:
>
> OooPS, not expected 210672 value
>
> I think the problem here is the new larger PIDs on newer kernels.
>
> I think the problem here is something involving the MAX_PROCESSES calc in
chkproc.c

This is a duplicate of bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982998 and is fixed in
0.55-2

(0.55-2 can be rebuilt with no changes on bullseye)

Bug#1000622: ser2net: Fails to start on boot since the serial port is not ready

[Mario V]

Package: ser2net
Version: 4.3.3-1
Severity: important
X-Debbugs-Cc: mario@volterra.cloud

Dear Maintainer,

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

   * What led up to the situation?
Installed, before upgrade to Debian Bullseye it worked fine on buster 
(raspberry Pi0 W)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
sudo apt install ser2net , edit /etc/ser2net/ser2net.conf, sudo systemctl 
enable ser2net && sudo systemctl start ser2net
   * What was the outcome of this action?
the service started
   * What outcome did you expect instead?
When rebooting the Pi0 on sudo systemctl status ser2net I get
```
 ser2net[625]: Invalid port name/number: Invalid data to parameter on line 30 
column 0
```

and it's not working until I run again `sudo systemctl restart ser2net` , in 
buster it was working just fine.


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv6l

Kernel: Linux 5.10.63+
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ser2net depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+rpt2+rpi1
ii  libgensio0   2.2.4-1
ii  libyaml-0-2  0.2.2-1
ii  lsb-base 11.1.0+rpi1

ser2net recommends no packages.

Versions of packages ser2net suggests:
pn  telnet  

-- Configuration Files:
/etc/ser2net.yaml changed:
%YAML 1.1
---
define:  \r\nser2net port \p device \d [\B] (Debian GNU/Linux)\r\n\r\n
connection: 
  accepter: tcp,20108
  connector: serialdev,/dev/ttyAMA0,115200n81,local
  options:
kickolduser: true


-- no debconf information

Bug#1000230: screenruler fails to start

[Peter Mueller]

Dear George,
On one of the two Debian-stable machines I manage libcanberra-gtk3-module is 
installed:
$ LANG=en_US.utf8 sudo aptitude show libcanberra-gtk3-module | egrep 
"(State)|(Version)" Version: 0.30-7 State: installed
On this machine, screenruler works. I'll check the other machine in several 
days and let you know.

Bug#1000621: /etc/ssh/sshd_config options: ClientAliveInterval and ClientAliveCountMax not working

[Martin Jungmann]

Package: openssh-server
Version: 1:8.4p1-5
OS: Debian 11 (Bullseye)

Hello,

configuration ClientAliveInterval and ClientAliveCountMax do not disconnect
idle ssh sessions.
The Previous openssh-server package (1:7.9p1-10+deb10u2) used in Debian 10
worked fine.
For example configuration in /etc/ssh/sshd _config
*ClientAliveInterval 15*
*ClientAliveCountMax 0*
It disconnected the idle ssh session after 15 second, unfortunately this
configuration is not working on Bullseye with the stable (1:8.4p1-5) or
testing version (1:8.7p1-2).

Kind regards
Martin Jungmann

Bug#974217: RFS: python-radexreader/1.0.0-5 [ITP] -- Reader for the RADEX RD1212 Geiger counter

[Bastian Germann]

Control: tags -1 - moreinfo

On 25.11.21 18:21, Fabrice Creuzot wrote:

I'm not sure what error you have encountered.
When I trying the following commands, it works (for me).
But perhaps it's not the good way.


dget -x 
https://mentors.debian.net/debian/pool/main/p/python-radexreader/python-radexreader_1.2.1-1.dsc


This is not building via git but gives the correct URL for your RFS. You previously wrote 
https://mentors.debian.net/package/python3-radexreader/ which is non-existing. Therefore I tried to 
build from the URL in Vcs-Git, which errors.



tar xzf python-radexreader_1.2.1.orig.tar.gz

tar xf python-radexreader_1.2.1-1.debian.tar.xz

cp -a debian/ python-radexreader-1.2.1/


You should use dpkg-source -x instead of those...


cd python-radexreader-1.2.1/

debuild -b -uc -us

ls ../*deb
  ../python3-radexreader_1.2.1-1_all.deb
  ../radexreader_1.2.1-1_all.deb


Le 27/10/2021 à 22:28, Bastian Germann a écrit :

Control: tags -1 moreinfo

On Sun, 29 Nov 2020 13:08:01 +0100 Fabrice Creuzot  wrote:

I uploaded a new package release (1.0.0-5).
I fixed lintian errors and I updated debian directory in source repository.


Building from git is broken. Please reupload a source package and remove this bug's moreinfo tag 
after that.

Bug#1000620: Pre-built binaries in qtwebengine source package

[Legimet]

Package: src:qtwebengine-opensource-src
Version: 5.15.7+dfsg-1

I found that there are some pre-built binaries in the source package. I
have listed them below:

tests/auto/widgets/resources/test.swf
src/3rdparty/chromium/third_party/devtools-frontend/src/node_modules/rollup/node_modules/fsevents/fsevents.node
src/3rdparty/chromium/third_party/breakpad/breakpad/src/client/mac/testapp/crashduringload
src/3rdparty/chromium/third_party/breakpad/breakpad/src/client/mac/testapp/crashInMain
src/3rdparty/chromium/third_party/breakpad/breakpad/src/client/mac/gcov/libgcov.a
src/3rdparty/chromium/third_party/skia/platform_tools/android/bin/mac/perfhost
src/3rdparty/chromium/third_party/openh264/src/autotest/performanceTest/ios/fruitstrap
src/3rdparty/chromium/third_party/openh264/src/autotest/performanceTest/ios/iFileTransfer
src/3rdparty/chromium/third_party/devtools-frontend/src/scripts/jsdoc_validator/jsdoc_validator.jar
src/3rdparty/chromium/third_party/devtools-frontend/src/scripts/closure/compiler.jar
src/3rdparty/chromium/third_party/devtools-frontend/src/scripts/closure/closure_runner/closure_runner.jar
src/3rdparty/chromium/third_party/closure_compiler/compiler/compiler.jar
src/3rdparty/chromium/build/android/CheckInstallApk-debug.apk
src/3rdparty/chromium/third_party/jetifier_standalone/lib/jetifier-standalone.jar
src/3rdparty/chromium/third_party/gradle_wrapper/gradle/wrapper/gradle-wrapper.jar
src/3rdparty/chromium/third_party/flatbuffers/src/android/gradle/wrapper/gradle-wrapper.jar
src/3rdparty/chromium/third_party/flatbuffers/src/samples/android/gradle/wrapper/gradle-wrapper.jar
src/3rdparty/chromium/third_party/skia/platform_tools/android/apps/gradle/wrapper/gradle-wrapper.jar
src/3rdparty/chromium/build/android/stacktrace/java_deobfuscate.jar
src/3rdparty/chromium/third_party/blink/manual_tests/resources/ArrayParameterTestApplet.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/StringTypeTest.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/DrawMessage.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/TestApplet.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/CheckerApplet.class
src/3rdparty/chromium/third_party/blink/manual_tests/accessibility/resources/AppletTest.class
src/3rdparty/chromium/third_party/win_build_output
src/3rdparty/chromium/third_party/angle/third_party/vulkan-tools/src/external/x86/lib/vulkan-1.lib
src/3rdparty/chromium/third_party/angle/third_party/vulkan-tools/src/external/x64/lib/vulkan-1.lib
src/3rdparty/chromium/third_party/angle/third_party/vulkan-loader/src/loader/loader.aps
src/3rdparty/chromium/third_party/devtools-frontend/src/front_end/sdk/wasm_source_map/pkg/wasm_source_map_bg.wasm
src/3rdparty/chromium/v8/third_party/wasm-api/example/*.wasm
src/3rdparty/chromium/third_party/vulkan_memory_allocator/bin/*.spv

Bug#1000619: tcpdf: Failing testsuite with PHP 8.1

[David Prévot]

Package: php-tcpdf
Version: 6.4.2+dfsg1-1
Severity: normal
Control: block 976811 by -1

Hi,

Now that PHP 8.1 is default in experimental (soon in unstable), we
noticed the testsuite is currently failing due to deprecation notices.

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults
https://ci.debian.net/data/autopkgtest/unstable/amd64/t/tcpdf/16973890/log.gz
[…]
Deprecated: Implicit conversion from float 16.912810673130803 to int loses 
precision in /usr/share/php/tcpdf/tcpdf.php on line 7360

Deprecated: Implicit conversion from float 5.388921932205105 to int loses 
precision in /usr/share/php/tcpdf/tcpdf.php on line 7360

Deprecated: Implicit conversion from float 0.20696933481202212 to int loses 
precision in /usr/share/php/tcpdf/tcpdf.php on line 7360

Deprecated: Implicit conversion from float 0.006000286595066149 to int loses 
precision in /usr/share/php/tcpdf/tcpdf.php on line 7360

Warning: Cannot modify header information - headers already sent by (output 
started at /usr/share/php/tcpdf/tcpdf.php:7360) in 
/usr/share/php/tcpdf/tcpdf.php on line 7709
TCPDF ERROR: Some data has already been output to browser, 
can't send PDF file
---
[…]

A quick look upstream makes me think a patch is already available.

PHP 8.1: Fix implicit conversion from float to int #387 
https://github.com/tecnickcom/TCPDF/pull/387

Thanks in advance for fixing this issue.

Regards

David


signature.asc
Description: PGP signature

Bug#911735: pdfwalker unusable due to ruby-gtk2 module issue

[Daniel Leidert]

There is currently a problem with origami caused by ruby-gtk2 (#990443), a gem
which has been deprecated and is likely to vanish due to the Gtk2 removal in
Debian.

This problem (#990443), for which we do not have a solution at the moment,
prevents pdfwalker from starting, even after fixing the other bugs.

The project itself seems unmaintained for some years now. If it is not ported
to Gtk3 soon, it has no future in Debian.
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1000616: Kernel list_del corruption. next->prev should be ...

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Kai,

On Thu, Nov 25, 2021 at 10:32:08PM +0100, Kai Lüke wrote:
> Package: linux-image-5.15.0-1-amd64
> Version: 5.15.3-1
> 
> I often hit this bug here, often shortly before others are hit which render
> the system unusable.
> Here the dmesg log section from pstore:
> 
> 
> <3>[  257.036085] list_del corruption. next->prev should be
> dfd4c8b732c8, but was 98adb59f5830
> <4>[  257.036115] [ cut here ]
> <2>[  257.036117] kernel BUG at lib/list_debug.c:54!
> <4>[  257.036129] invalid opcode:  [#1] SMP NOPTI
> <4>[  257.036137] CPU: 1 PID: 3955 Comm: xdg-document-po Tainted: G 
> I   5.15.0-1-amd64 #1  Debian 5.15.3-1
> <4>[  257.036146] Hardware name: LENOVO 20CLS2LJ00/20CLS2LJ00, BIOS N10ET38W
> (1.17 ) 08/20/2015
> <4>[  257.036150] RIP: 0010:__list_del_entry_valid.cold+0x1d/0x47
> <4>[  257.036164] Code: c7 c7 d8 c5 d5 aa e8 32 f7 fe ff 0f 0b 48 89 fe 48
> c7 c7 68 c6 d5 aa e8 21 f7 fe ff 0f 0b 48 c7 c7 18 c7 d5 aa e8 13 f7 fe ff
> <0f> 0b 48 89 f2 48 89 fe 48 c7 c7 d8 c6 d5 aa e8 ff f6 fe ff 0f 0b
> <4>[  257.036170] RSP: 0018:a6ba0182b958 EFLAGS: 00010046
> <4>[  257.036178] RAX: 0054 RBX: a6ba0182bab0 RCX:
> 
> dmesg-efi-163787479303001:
> Oops#1 Part3
> <4>[  257.036183] RDX:  RSI: 98afc5c60880 RDI:
> 98afc5c60880
> <4>[  257.036188] RBP: dfd4c8b732c0 R08:  R09:
> a6ba0182b788
> <4>[  257.036192] R10: a6ba0182b780 R11: ab2d21c8 R12:
> 0002
> <4>[  257.036197] R13: a6ba0182bae0 R14: a6ba0182b998 R15:
> dfd4c8b73248
> <4>[  257.036202] FS:  7f3313ed5380() GS:98afc5c4()
> knlGS:
> <4>[  257.036208] CS:  0010 DS:  ES:  CR0: 80050033
> <4>[  257.036213] CR2: 7f5434002078 CR3: 35acc005 CR4:
> 003706e0
> <4>[  257.036219] Call Trace:
> <4>[  257.036224]  
> <4>[  257.036228]  release_pages+0x2eb/0x510
> <4>[  257.036244]  __pagevec_release+0x1c/0x50
> <4>[  257.036254]  truncate_inode_pages_range+0x157/0x520
> <4>[  257.036264]  ? schedule+0x44/0xa0
> <4>[  257.036271]  ? schedule_hrtimeout_range_clock+0x9d/0x120
> <4>[  257.036281]  ? __inode_wait_for_writeback+0x7e/0xf0
> <4>[  257.036294]  fuse_evict_inode+0x16/0xd0 [fuse]
> <4>[  257.036320]  evict+0xce/0x180
> <4>[  257.036330]  __dentry_kill+0xe1/0x180
> <4>[  257.036337]  shrink_dentry_list+0x4e/0xc0
> <4>[  257.036344]  shrink_dcache_parent+0xd1/0x120
> <4>[  257.036352]  d_invalidate+0x66/0xe0
> <4>[  257.036359]  ? dput+0x32/0x300
> <4>[  257.036366]  fuse_reverse_inval_entry+0xbd/0x1e0 [fuse]
> <4>[  257.036385]  fuse_dev_do_write+0x54b/0xee0 [fuse]
> <4>[  257.036404]  ? __pollwait+0xd0/0xd0
> <4>[  257.036416]  fuse_dev_write+0x4f/0x80 [fuse]
> <4>[  257.036449]  do_iter_readv_writev+0x14f/0x1b0
> <4>[  257.036462]  do_iter_write+0x7c/0x1c0
> <4>[  257.036473]  vfs_writev+0xaa/0x140
> <4>[  257.036485]  ? ktime_get_ts64+0x49/0xf0
> <4>[  257.036494]  do_writev+0x6b/0x110
> <4>[  257.036505]  do_syscall_64+0x38/0xc0
> <4>[  257.036512]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> dmesg-efi-163787479302001:
> Oops#1 Part2
> <4>[  257.036523] RIP: 0033:0x7f3314351a6d
> <4>[  257.036529] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 6a f9
> f8 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 14 00 00 00 0f 05
> <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 be f9 f8 ff 48
> <4>[  257.036535] RSP: 002b:7ffde2997830 EFLAGS: 0293 ORIG_RAX:
> 0014
> <4>[  257.036543] RAX: ffda RBX: 0003 RCX:
> 7f3314351a6d
> <4>[  257.036547] RDX: 0003 RSI: 7ffde29978a0 RDI:
> 0007
> <4>[  257.036552] RBP: 7ffde29978a0 R08:  R09:
> 7f33145b82c0
> <4>[  257.036556] R10: 7f3333a0 R11: 0293 R12:
> 563a24a49690
> <4>[  257.036560] R13: 0003 R14: 7f333440 R15:
> 563a24a1f8c0
> <4>[  257.036567]  
> <4>[  257.036570] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer
> snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device
> xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp
> nft_compat iscsi_target_mod target_core_mod nft_masq nft_counter
> nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bridge stp
> llc nf_tables nfnetlink ctr bnep overlay ccm algif_aead des_generic libdes
> ecb algif_skcipher cpufreq_userspace cpufreq_powersave cmac cpufreq_ondemand
> cpufreq_conservative md4 algif_hash lz4 af_alg lz4_compress zram zsmalloc
> btusb btrtl btbcm btintel bluetooth jitterentropy_rng uvcvideo
> videobuf2_vmalloc videobuf2_memops sha512_ssse3 videobuf2_v4l2
> videobuf2_common sha512_generic videodev mc drbg ansi_cprng ecdh_generic ecc
> crc16 binfmt_misc nls_ascii nls_cp437 vfat fat joydev intel_rapl_msr
> intel_rapl_common mei_wdt x86_pkg_temp_thermal intel_powerclamp iwlmvm
> snd_ctl_led 

Bug#1000588: evince,mailcap: "evince --new-window $file" opens the file chooser dialog instead of the requested file

[Charles Plessy]

Le Thu, Nov 25, 2021 at 03:15:27PM +, Simon McVittie a écrit :
> Control: reassign -1 mailcap 3.70
> 
> On Thu, 25 Nov 2021 at 15:13:01 +0100, Julien Cristau wrote:
> 
> Yes, update-mime should only be parsing the fields from the
> [Desktop Entry] group, something like this (untested):

Thanks Julien and Simon,

I agree that the problem and the solution are in mailcap.

I am about to go for a business trip, so the fix may take a couple of
weeks.  If you consider an NMU please go straight for a team upload
and push the change in Salsa; as DDs you should have commit rights.

https://salsa.debian.org/debian/mailcap

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1000617: python3-nbclient_0.5.6-1: trying to overwrite '/usr/bin/jupyter-run', which is also in package jupyter-client 7.0.6-2

[Roman Lebedev]

Package: python3-nbclient
Version: 0.5.5-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer, it looks like python3-nbclient / jupyter-client don't
play well together:

Unpacking python3-nbclient (0.5.6-1) over (0.5.5-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-dawlPe/41-python3-nbclient_0.5.6-1_all.deb (--unpack):
 trying to overwrite '/usr/bin/jupyter-run', which is also in package 
jupyter-client 7.0.6-2

Roman

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

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

Versions of packages python3-nbclient depends on:
ii  python3 3.9.8-1
ii  python3-jupyter-client  7.0.6-2
ii  python3-nbformat5.1.3-1
ii  python3-nest-asyncio1.5.1-1
ii  python3-traitlets   5.1.1-1

python3-nbclient recommends no packages.

python3-nbclient suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAmGgAWAACgkQCDw+u0oW
ieBqgg/8DM/IiyThgtywLCfOU8oGu3WGFCFDQcT7q7X+TkNSB+q3aeZ/rH5+5V19
fwlS2LnNKG/yqvDz2BSUq5+NZZJXp1wEqlpDhpgb3eSMjimBN/AjudtQbATqFtXW
EhWIRCH3qlig3Bs/q170DbdAT7D6ql4iDdM3hFVN7W4UpjcxmJL1y1k9lQpYG54G
5F25gUI5yrBJTVmt+24ApZChNEj6L1ZKnF7g5155V6PhMnyjygigzift2RfbUGfB
fJerTPjEhPYdwIYq/fLIrVC9cmfVT4EYzxqUIFEK0wlUZNTBYbhb6HO+J9EXtbrB
BrN8/6wptBlyP4R4dmCCplqt2UzduLRkVvgSjMNyzTcZIhco5vs8bQzplKOjA9ui
vuKCmtjgcuNyCvvCi6p2LTaimne74gUNdPic99THb2XqplfvwPMN/+cvoONCh4r9
AUiv//q/OCJP3bC9bZg0cmwm69td5SUI4FtnkDF344hJLETio8nXhfaIIgi59io5
2hCQQhxIxOMxIQ1/iOpGGq+VrZlIHi8TaqiwItB6vxPrMEMy6P59zk18lamxpIsd
9d/QE6K36+3yYxNscPucpLAMPEQxtIQ68IFQM7M7betVNHPVErDVgn/9CNFR8rNc
gwgBvsEyG+0LLjtWD8yLA8L4H8OLgxW27ldGo1OHQOwOMw7oyoI=
=BbOc
-END PGP SIGNATURE-

Bug#996806: [Pkg-mailman-hackers] Bug#996806: mailmain3: Expected test results for arc_validate tests need updating

[Pierre-Elliott Bécue]

Jordi Mallach  wrote on 24/11/2021 at 23:39:00+0100:

> Source: mailman3
> Version: 3.3.3-1
> Followup-For: Bug #996806
>
> Apparently this is fixed in upstream commit
> f311b135fe13e3ec07ef2eedadba9c09b25e57ff
>
> See
>
> https://gitlab.com/mailman/mailman/-/commit/f311b135fe13e3ec07ef2eedadba9c09b25e57ff
>
> for more details.
>
> I might try to work on a fix in the following days, most probably
> including an update to the latest version, which includes other fixes I
> need.

I'm waiting for some stuck dependencies issues to solve to batch a full
update of mailman3.

Cheers!
-- 
PEB


signature.asc
Description: PGP signature

Bug#990443: [DRE-maint] Bug#990443: Issue seems to be ruby-gtk2

[Daniel Leidert]

Am Donnerstag, dem 25.11.2021 um 22:15 +0100 schrieb Daniel Leidert:
> I did some debugging with this issue and it actually seems to be caused by
> ruby-gtk2. It is easy to reproduce. In irb:
> 
> require 'gtk2'
> include Gtk
> require 'openssl'
> 
> => crash (happens when openssl loads openssl.so):

Correkt traceback:

14: from test.rb:3:in `'
13: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
12: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
11: from /usr/lib/ruby/2.7.0/openssl.rb:20:in `'
10: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 9: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 8: from /usr/lib/ruby/2.7.0/openssl/ssl.rb:15:in `'
 7: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 6: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 5: from /usr/lib/ruby/2.7.0/ipaddr.rb:19:in `'
 4: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 3: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 2: from /usr/lib/ruby/2.7.0/socket.rb:4:in `'
 1: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require': 
superclass mismatch for class Socket (TypeError)


-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1000615: fsverity-utils FTCBFS: rebuilds with the build architecture compiler during make install

[Helmut Grohne]

Source: fsverity-utils
Version: 1.4-1~exp1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fsverity-utils fails to cross build from source, because make install
detects a changed compiler and proceeds to rebuild it using the build
architecture compiler. Exporting the host architecture CC for all
targets fixes this. Please consider applying the attached patch.

Helmut
diff --minimal -Nru fsverity-utils-1.4/debian/changelog 
fsverity-utils-1.4/debian/changelog
--- fsverity-utils-1.4/debian/changelog 2021-06-24 14:16:03.0 +0200
+++ fsverity-utils-1.4/debian/changelog 2021-11-25 22:27:54.0 +0100
@@ -1,3 +1,11 @@
+fsverity-utils (1.4-1~exp1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Avoid rebuild during make install by exporting CC.
+(Closes: #-1)
+
+ -- Helmut Grohne   Thu, 25 Nov 2021 22:27:54 +0100
+
 fsverity-utils (1.4-1~exp1) experimental; urgency=medium
 
   * New upstream version 1.4.
diff --minimal -Nru fsverity-utils-1.4/debian/rules 
fsverity-utils-1.4/debian/rules
--- fsverity-utils-1.4/debian/rules 2021-06-24 10:16:10.0 +0200
+++ fsverity-utils-1.4/debian/rules 2021-11-25 22:27:52.0 +0100
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 
 include /usr/share/dpkg/default.mk
+-include /usr/share/dpkg/buildtools.mk
+export CC
 
 MAKEFLAGS=PREFIX=/usr V=1 USE_SHARED_LIB=1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all

Bug#1000616: Kernel list_del corruption. next->prev should be ...

[Kai Lüke]

Package: linux-image-5.15.0-1-amd64
Version: 5.15.3-1

I often hit this bug here, often shortly before others are hit which 
render the system unusable.

Here the dmesg log section from pstore:


<3>[  257.036085] list_del corruption. next->prev should be 
dfd4c8b732c8, but was 98adb59f5830

<4>[  257.036115] [ cut here ]
<2>[  257.036117] kernel BUG at lib/list_debug.c:54!
<4>[  257.036129] invalid opcode:  [#1] SMP NOPTI
<4>[  257.036137] CPU: 1 PID: 3955 Comm: xdg-document-po Tainted: 
G  I   5.15.0-1-amd64 #1  Debian 5.15.3-1
<4>[  257.036146] Hardware name: LENOVO 20CLS2LJ00/20CLS2LJ00, BIOS 
N10ET38W (1.17 ) 08/20/2015

<4>[  257.036150] RIP: 0010:__list_del_entry_valid.cold+0x1d/0x47
<4>[  257.036164] Code: c7 c7 d8 c5 d5 aa e8 32 f7 fe ff 0f 0b 48 89 fe 
48 c7 c7 68 c6 d5 aa e8 21 f7 fe ff 0f 0b 48 c7 c7 18 c7 d5 aa e8 13 f7 
fe ff <0f> 0b 48 89 f2 48 89 fe 48 c7 c7 d8 c6 d5 aa e8 ff f6 fe ff 0f 0b

<4>[  257.036170] RSP: 0018:a6ba0182b958 EFLAGS: 00010046
<4>[  257.036178] RAX: 0054 RBX: a6ba0182bab0 RCX: 


dmesg-efi-163787479303001:
Oops#1 Part3
<4>[  257.036183] RDX:  RSI: 98afc5c60880 RDI: 
98afc5c60880
<4>[  257.036188] RBP: dfd4c8b732c0 R08:  R09: 
a6ba0182b788
<4>[  257.036192] R10: a6ba0182b780 R11: ab2d21c8 R12: 
0002
<4>[  257.036197] R13: a6ba0182bae0 R14: a6ba0182b998 R15: 
dfd4c8b73248
<4>[  257.036202] FS:  7f3313ed5380() GS:98afc5c4() 
knlGS:

<4>[  257.036208] CS:  0010 DS:  ES:  CR0: 80050033
<4>[  257.036213] CR2: 7f5434002078 CR3: 35acc005 CR4: 
003706e0

<4>[  257.036219] Call Trace:
<4>[  257.036224]  
<4>[  257.036228]  release_pages+0x2eb/0x510
<4>[  257.036244]  __pagevec_release+0x1c/0x50
<4>[  257.036254]  truncate_inode_pages_range+0x157/0x520
<4>[  257.036264]  ? schedule+0x44/0xa0
<4>[  257.036271]  ? schedule_hrtimeout_range_clock+0x9d/0x120
<4>[  257.036281]  ? __inode_wait_for_writeback+0x7e/0xf0
<4>[  257.036294]  fuse_evict_inode+0x16/0xd0 [fuse]
<4>[  257.036320]  evict+0xce/0x180
<4>[  257.036330]  __dentry_kill+0xe1/0x180
<4>[  257.036337]  shrink_dentry_list+0x4e/0xc0
<4>[  257.036344]  shrink_dcache_parent+0xd1/0x120
<4>[  257.036352]  d_invalidate+0x66/0xe0
<4>[  257.036359]  ? dput+0x32/0x300
<4>[  257.036366]  fuse_reverse_inval_entry+0xbd/0x1e0 [fuse]
<4>[  257.036385]  fuse_dev_do_write+0x54b/0xee0 [fuse]
<4>[  257.036404]  ? __pollwait+0xd0/0xd0
<4>[  257.036416]  fuse_dev_write+0x4f/0x80 [fuse]
<4>[  257.036449]  do_iter_readv_writev+0x14f/0x1b0
<4>[  257.036462]  do_iter_write+0x7c/0x1c0
<4>[  257.036473]  vfs_writev+0xaa/0x140
<4>[  257.036485]  ? ktime_get_ts64+0x49/0xf0
<4>[  257.036494]  do_writev+0x6b/0x110
<4>[  257.036505]  do_syscall_64+0x38/0xc0
<4>[  257.036512]  entry_SYSCALL_64_after_hwframe+0x44/0xae
dmesg-efi-163787479302001:
Oops#1 Part2
<4>[  257.036523] RIP: 0033:0x7f3314351a6d
<4>[  257.036529] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 6a 
f9 f8 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 14 00 00 00 
0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 be f9 f8 ff 48
<4>[  257.036535] RSP: 002b:7ffde2997830 EFLAGS: 0293 ORIG_RAX: 
0014
<4>[  257.036543] RAX: ffda RBX: 0003 RCX: 
7f3314351a6d
<4>[  257.036547] RDX: 0003 RSI: 7ffde29978a0 RDI: 
0007
<4>[  257.036552] RBP: 7ffde29978a0 R08:  R09: 
7f33145b82c0
<4>[  257.036556] R10: 7f3333a0 R11: 0293 R12: 
563a24a49690
<4>[  257.036560] R13: 0003 R14: 7f333440 R15: 
563a24a1f8c0

<4>[  257.036567]  
<4>[  257.036570] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer 
snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device 
xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 
xt_tcpudp nft_compat iscsi_target_mod target_core_mod nft_masq 
nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 bridge stp llc nf_tables nfnetlink ctr bnep overlay ccm 
algif_aead des_generic libdes ecb algif_skcipher cpufreq_userspace 
cpufreq_powersave cmac cpufreq_ondemand cpufreq_conservative md4 
algif_hash lz4 af_alg lz4_compress zram zsmalloc btusb btrtl btbcm 
btintel bluetooth jitterentropy_rng uvcvideo videobuf2_vmalloc 
videobuf2_memops sha512_ssse3 videobuf2_v4l2 videobuf2_common 
sha512_generic videodev mc drbg ansi_cprng ecdh_generic ecc crc16 
binfmt_misc nls_ascii nls_cp437 vfat fat joydev intel_rapl_msr 
intel_rapl_common mei_wdt x86_pkg_temp_thermal intel_powerclamp iwlmvm 
snd_ctl_led watchdog snd_hda_codec_realtek snd_hda_codec_generic 
snd_hda_codec_hdmi

dmesg-efi-163787479301001:
Oops#1 Part1
<4>[  257.036705]  kvm_intel snd_hda_intel mei_hdcp mac80211 kvm 
snd_intel_dspcfg snd_intel_sdw_acpi irqbypass libarc4 snd_hda_codec rapl 

Bug#1000613: gammapy FTBFS on !amd64: test failures

[Adrian Bunk]

Source: gammapy
Version: 0.19-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=gammapy=0.19-1

...
=== FAILURES ===
__ test_binary_erode ___

def test_binary_erode():
geom = WcsGeom.create(binsz=0.02, width=2 * u.deg)
mask = geom.region_mask("icrs;circle(0, 0, 1)")

mask = mask.binary_erode(width=0.2 * u.deg, kernel="disk", 
use_fft=False)
assert_allclose(mask.data.sum(), 4832)

mask = mask.binary_erode(width=0.2 * u.deg, kernel="box", use_fft=True)
>   assert_allclose(mask.data.sum(), 3372)
E   AssertionError: 
E   Not equal to tolerance rtol=1e-07, atol=0
E   
E   Mismatched elements: 1 / 1 (100%)
E   Max absolute difference: 15
E   Max relative difference: 0.0044484
Ex: array(3387)
Ey: array(3372)

gammapy/maps/wcs/tests/test_ndmap.py:836: AssertionError
__ test_binary_dilate __

def test_binary_dilate():
geom = WcsGeom.create(binsz=0.02, width=2 * u.deg)
mask = geom.region_mask("icrs;circle(0, 0, 0.8)")

mask = mask.binary_dilate(width=0.2 * u.deg, kernel="disk", 
use_fft=False)
assert_allclose(mask.data.sum(), 8048)

mask = mask.binary_dilate(width=(10, 10), kernel="box")
>   assert_allclose(mask.data.sum(), 9203)
E   AssertionError: 
E   Not equal to tolerance rtol=1e-07, atol=0
E   
E   Mismatched elements: 1 / 1 (100%)
E   Max absolute difference: 11
E   Max relative difference: 0.00119526
Ex: array(9214)
Ey: array(9203)

gammapy/maps/wcs/tests/test_ndmap.py:847: AssertionError
=== short test summary info 
FAILED gammapy/maps/wcs/tests/test_ndmap.py::test_binary_erode - AssertionErr...
FAILED gammapy/maps/wcs/tests/test_ndmap.py::test_binary_dilate - AssertionEr...
= 2 failed, 1030 passed, 562 skipped, 10 xfailed in 150.08s (0:02:30) ==
...

Bug#1000600: libudev.a static library missing.

[Michael Biebl]

Control: tags -1 + wontfix
Control: severity -1 wishlist


upstream is strictly against static linking, thus there is no static 
library anymore and we won't patch downstream to add one.

Those marking as wontfix.

On 25.11.21 19:39, Bram Stolk wrote:

Package: libudev-dev
Version: 247.3-6

The libudev-dev package only comes with a shared library, not with a 
static library.
https://packages.debian.org/bullseye/amd64/libudev-dev/filelist 



NOTE: THIS WAS NOT ALWAYS THE CASE.


We haven't shipped a libudev.a since jessie, i.e. for over 4 release, 
roughly 8 years.



Somewhere along the line, the libudev.a file disappeared.
(It could have happened with the inclusion into systemd sources?)

This means that statically linking against libudev will fail:

/usr/bin/ld: cannot find -ludev
collect2: error: ld returned 1 exit status

I see no reason why libudev should not be available as a static library 
as well.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#990443: Issue seems to be ruby-gtk2

[Daniel Leidert]

I did some debugging with this issue and it actually seems to be caused by
ruby-gtk2. It is easy to reproduce. In irb:

require 'gtk2'
include Gtk
require 'openssl'

=> crash (happens when openssl loads openssl.so):

Traceback (most recent call last):
28: from /usr/bin/pdfwalker:25:in `'
27: from /usr/bin/pdfwalker:25:in `load'
26: from 
/usr/share/rubygems-integration/all/gems/origami-2.0.4/bin/pdfwalker:4:in `'
25: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
24: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
23: from /usr/share/origami/gui/walker.rb:31:in `'
22: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
21: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
20: from 
/usr/share/rubygems-integration/all/gems/origami-2.0.4/lib/origami.rb:41:in 
`'
19: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
18: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
17: from 
/usr/share/rubygems-integration/all/gems/origami-2.0.4/lib/origami/pdf.rb:49:in 
`'
16: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
15: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
14: from 
/usr/share/rubygems-integration/all/gems/origami-2.0.4/lib/origami/encryption.rb:21:in
 `'
13: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
12: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
11: from /usr/lib/ruby/2.7.0/openssl.rb:20:in `'
10: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 9: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 8: from /usr/lib/ruby/2.7.0/openssl/ssl.rb:15:in `'
 7: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 6: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 5: from /usr/lib/ruby/2.7.0/ipaddr.rb:19:in `'
 4: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 3: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
 2: from /usr/lib/ruby/2.7.0/socket.rb:4:in `'
 1: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require': 
superclass mismatch for class Socket (TypeError)

That's not a bug in origami.

I'll have a look at ruby-gtk2. However, I guess as soon as Gtk2 vanishes from
Debian, pdfwalker will become dysfunctional.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1000374: transition: opencv

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2021-11-25 21:37:30, Timo Röhling wrote:
> Hi,
> 
> * Sebastian Ramacher  [2021-11-22 20:34]:
> > Why does the name of the -java package get changed? For the Java ABI
> > nothing changes in this case. If you compare the produced class files,
> > the only difference is that libopencv_java454d.so is loaded instead of
> > libopencv_java454.so.
> I gave it some more thought (and discussed it with Jochen), and I
> ended up reverting that rename, back to libopencv4.5-java, for
> 4.5.4+dfsg-5 in experimental.

Alright, please go ahead

Cheers

> 
> Cheers
> Timo
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀   ╭╮
> ⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
> ⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
> ⠈⠳⣄   ╰╯



-- 
Sebastian Ramacher

Bug#999524: python-language-server: FTBFS with numpy 1.21 (in experimental): dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Drew Parsons]

Source: python-language-server
Followup-For: Bug #999524

Upstream lost write access to the python-language-server repo
https://github.com/palantir/python-language-server/issues/935
so have forked the project to python-lsp-server at
https://github.com/python-lsp/python-lsp-server

As part of the move they renamed the module from pyls to pylsp.

The new version is packaged and available (python3-pylsp,
src:python-lsp-server).

python-language-server can be removed once spyder is updated for pylsp.

Bug#1000612: python-cassandra-driver: flaky test

[Adrian Bunk]

Source: python-cassandra-driver
Version: 3.24.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=python-cassandra-driver=3.24.0-1%2Bb1

...
==
FAIL: Verify that timer timeouts are honored appropriately
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.9_dbg_cassandra/build/tests/unit/io/utils.py",
 line 171, in test_multi_timer_validation
submit_and_wait_for_completion(self, self.create_timer, 0, 100, 1, 100)
  File 
"/<>/.pybuild/cpython3_3.9_dbg_cassandra/build/tests/unit/io/utils.py",
 line 138, in submit_and_wait_for_completion
unit_test.assertAlmostEqual(callback.expected_wait, 
callback.get_wait_time(), delta=.15)
AssertionError: 0.0 != 0.1567823886871338 within 0.15 delta (0.1567823886871338 
difference)
 >> begin captured logging << 
cassandra.connection: DEBUG: Sending initial options message for new connection 
(281473218221072) to 127.0.0.1:9042
cassandra.io.libevreactor: DEBUG: Starting libev event loop
cassandra.io.libevreactor: DEBUG: Closing connection (281473218221072) to 
127.0.0.1:9042
cassandra.io.libevreactor: DEBUG: Closed socket to 127.0.0.1:9042
- >> end captured logging << -

--
Ran 594 tests in 121.258s

FAILED (SKIP=18, failures=1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.9_dbg_cassandra/build; python3.9-dbg -m 
nose -v  --ignore-files="test_eventletreactor\.py"
dh_auto_test: error: pybuild --test -i python{version}-dbg -p "3.10 3.9" 
returned exit code 13
make[1]: *** [debian/rules:41: override_dh_auto_test] Error 25

Bug#1000611: libvtk9{,-qt}: soname change without library transition

[Anton Gladky]

Hi Adrian,

thanks for the bug report. It was really an accidental upload into
unstable instead of experimental. Yes, I will rename the package
and upload it ASAP.

Regards

Anton

Am Do., 25. Nov. 2021 um 22:03 Uhr schrieb Adrian Bunk :
>
> Package: libvtk9
> Version: 9.1.0+dfsg2-2
> Severity: serious
> Control: affects -1 libvtk9-qt src:vtk9
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/f/freecad/16980590/log.gz
>
> ...
> ERROR: TestFemApp (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: TestFemApp
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/unittest/loader.py", line 154, in loadTestsFromName
> module = __import__(module_name)
>   File "/usr/share/freecad/Mod/Fem/TestFemApp.py", line 33, in 
> from femtest.app.test_mesh import TestMeshCommon as FemTest07
>   File "/usr/share/freecad/Mod/Fem/femtest/app/test_mesh.py", line 33, in 
> 
> import Fem
> ImportError: libvtkFiltersExtraction-9.0.so.1: cannot open shared object 
> file: No such file or directory
> ...
>
>
> The soname of the vtk9 libraries is not 9, it is 9.0 for VTK 9.0
> and 9.1 for VTK 9.1:
>
> $  objdump -p /usr/lib/x86_64-linux-gnu/libvtkChartsCore-9.1.so.1 | grep 
> SONAME
>   SONAME   libvtkChartsCore-9.1.so.1
> $
>
> In bullseye libvtk9 and libvtk9-qt should have been named
> libvtk9.0 and libvtk9.0-qt, but this alone is harmless.
>
> Not harmless is that the libraries must transition to the new
> soname in 9.1, renaming the packages to libvtk9.1 and libvtk9.1-qt.
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1000611: libvtk9{,-qt}: soname change without library transition

[Adrian Bunk]

Package: libvtk9
Version: 9.1.0+dfsg2-2
Severity: serious
Control: affects -1 libvtk9-qt src:vtk9

https://ci.debian.net/data/autopkgtest/testing/amd64/f/freecad/16980590/log.gz

...
ERROR: TestFemApp (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: TestFemApp
Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File "/usr/share/freecad/Mod/Fem/TestFemApp.py", line 33, in 
from femtest.app.test_mesh import TestMeshCommon as FemTest07
  File "/usr/share/freecad/Mod/Fem/femtest/app/test_mesh.py", line 33, in 

import Fem
ImportError: libvtkFiltersExtraction-9.0.so.1: cannot open shared object file: 
No such file or directory
...


The soname of the vtk9 libraries is not 9, it is 9.0 for VTK 9.0
and 9.1 for VTK 9.1:

$  objdump -p /usr/lib/x86_64-linux-gnu/libvtkChartsCore-9.1.so.1 | grep SONAME
  SONAME   libvtkChartsCore-9.1.so.1
$

In bullseye libvtk9 and libvtk9-qt should have been named
libvtk9.0 and libvtk9.0-qt, but this alone is harmless.

Not harmless is that the libraries must transition to the new
soname in 9.1, renaming the packages to libvtk9.1 and libvtk9.1-qt.

Bug#1000610: lintian: FP for missing-build-dependency-for-dh-addon with Build-Depends: debhelper (>= 11)

[Ian Wienand]

Package: lintian
Version: 2.111.0
Severity: normal
X-Debbugs-Cc: i...@debian.org

Dear Maintainer,

With the following Build-Depends in libgc

---
Build-Depends: debhelper (>= 11),
 libatomic-ops-dev (>= 7.6~),
 pkg-config,
 pkg-kde-tools
---

I am getting the lintian error missing-build-dependency-for-dh-addon

---
$ lintian libgc_8.0.6-1.1_amd64.changes
E: libgc source: missing-build-dependency-for-dh-addon autoreconf => dh-
autoreconf | debhelper (>= 9.20160403~) | debhelper-compat
---

The >=11 would seem to satisfy the >= 9.20160403~ ?

-i


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

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

Versions of packages lintian depends on:
ii  binutils2.37-7
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012004-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1000374: transition: opencv

[Timo Röhling]

Hi,

* Sebastian Ramacher  [2021-11-22 20:34]:

Why does the name of the -java package get changed? For the Java ABI
nothing changes in this case. If you compare the produced class files,
the only difference is that libopencv_java454d.so is loaded instead of
libopencv_java454.so.

I gave it some more thought (and discussed it with Jochen), and I
ended up reverting that rename, back to libopencv4.5-java, for
4.5.4+dfsg-5 in experimental.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1000609: flatpak - should recommend xdg-user-dirs

[Bastian Blank]

Package: flatpak
Version: 1.12.2-1
Severity: normal

Hi

flatpak supports specifying filesystem permissions relative to XDG user
dirs, e.g. --filesystem=xdg-download.  To make this support actually
work, it seems to need a properly setup XDG user dir setup including the
existence of ~/.config/user-dirs.dirs.  This file is created by
xdg-user-dirs-update if the xdg-user-dir package is installed.

The Arch wiki actually describes how this works:
https://wiki.archlinux.org/title/XDG_user_directories.

Please recommand the xdg-user-dir package, which is required to make
this function work.

Bastian

-- Package-specific info:
Permissions of /usr/bin/bwrap:
-rwxr-xr-x 1 root root 67904 Aug 20 17:19 /usr/bin/bwrap
/etc/sysctl.d/*-bubblewrap.conf:
cat: '/etc/sysctl.d/*-bubblewrap.conf': No such file or directory
/usr/lib/sysctl.d/50-bubblewrap.conf:
# Enable unprivileged creation of new user namespaces in older Debian
# kernels.
#
# If this is not desired, copy this file to
# /etc/sysctl.d/50-bubblewrap.conf and change the value of this parameter
# to 0, then use dpkg-statoverride to make /usr/bin/bwrap setuid root.
#
# For more details see https://deb.li/bubblewrap or
# /usr/share/doc/bubblewrap/README.Debian
kernel.unprivileged_userns_clone=1
/proc/sys/kernel/unprivileged_userns_clone:
1
/proc/sys/user/max_cgroup_namespaces:
63118
/proc/sys/user/max_ipc_namespaces:
63118
/proc/sys/user/max_mnt_namespaces:
63118
/proc/sys/user/max_net_namespaces:
63118
/proc/sys/user/max_pid_namespaces:
63118
/proc/sys/user/max_time_namespaces:
63118
/proc/sys/user/max_user_namespaces:
63118
/proc/sys/user/max_uts_namespaces:
63118

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

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

Versions of packages flatpak depends on:
ii  adduser3.118
ii  bubblewrap 0.5.0-1
ii  dbus   1.12.20-3
ii  libappstream-glib8 0.7.18-2
ii  libarchive13   3.4.3-2+b1
ii  libc6  2.32-4
ii  libdconf1  0.40.0-2
ii  libfuse2   2.9.9-5
ii  libgdk-pixbuf-2.0-02.42.6+dfsg-2
ii  libglib2.0-0   2.70.1-1
ii  libgpgme11 1.16.0-1.1+b1
ii  libjson-glib-1.0-0 1.6.6-1
ii  libmalcontent-0-0  0.10.3-1
ii  libostree-1-1  2021.5-1
ii  libpolkit-agent-1-00.105-31
ii  libpolkit-gobject-1-0  0.105-31
ii  libseccomp22.5.2-2
ii  libsoup2.4-1   2.74.1-1
ii  libsystemd0249.7-1
ii  libxau61:1.0.9-1
ii  libxml22.9.12+dfsg-5+b1
ii  libzstd1   1.4.8+dfsg-3
ii  xdg-dbus-proxy 0.1.2-2

Versions of packages flatpak recommends:
ii  ca-certificates  20210119
ii  desktop-file-utils   0.26-1
ii  gtk-update-icon-cache3.24.30-3
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   249.7-1
ii  p11-kit  0.24.0-5
ii  policykit-1  0.105-31
ii  shared-mime-info 2.0-1
ii  xdg-desktop-portal   1.10.1-4
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.10.0-3

Versions of packages flatpak suggests:
ii  avahi-daemon0.8-5
pn  malcontent-gui  

Versions of packages bubblewrap depends on:
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libselinux1  3.3-1+b1

Versions of packages bubblewrap recommends:
ii  procps  2:3.3.17-5

-- no debconf information

Bug#1000608: buster-pu: package ros-ros-comm/1.14.3+ds1-5+deb10u2

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jspri...@debian.org

[ Reason ]
CVE-2021-37146 was published with a denial of service against
ros-ros-comm.

[ Impact ]
The impact is rather low as the ROS middleware has no authentication nor
security features implemented and should only be used behind a firewall.
Still would be good to get it fixed in old-stable.

[ Tests ]
The patch adds a unit test and I ran manual tests using the relay
command from the topic-tools package.

[ Risks ]
Except for one new method (nextTagData) I see the code as rather simple,
and the risk as low.
For nextTagData the difference is that it is more strict in parsing only
the next xml tag which should be fine in the defined domain. Also this
is part of the upstream releases and also in unstable since some time.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
The patches add three things:
- Null pointer checks in XmlRpc.
- Add and update unit tests for the new changes.
- A new nextTagData method. This is an improved version of the old
  parseTag version. Both methods extract the data inside of a given xml
  tag in a string. The old parseTag used find to search for the
  requested tag. The new nextTagData only allows space characters in
  front of the expected xml tag.

[ Other info ]
I kept the individual patches as upstream merged them, hope that is
fine.
>From 1e0c5a384e036b2b4ee513c3f8514de3a8f77c9f Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Wed, 20 Oct 2021 21:44:38 +0200
Subject: [PATCH] 1.14.3+ds1-5+deb10u3 (CVE-2021-37146)

---
 debian/changelog  |   6 +
 .../0015-Fix-oversize-string-test.patch   |  25 +
 ...fensive-checks-for-offset-being-NULL.patch |  45 ++
 ...-tests-for-XML-tag-utility-functions.patch | 653 ++
 ...18-Add-implementation-of-nextTagData.patch | 167 +
 ...h-structFromXml-to-using-nextTagData.patch |  22 +
 debian/patches/series |   5 +
 7 files changed, 923 insertions(+)
 create mode 100644 debian/patches/0015-Fix-oversize-string-test.patch
 create mode 100644 
debian/patches/0016-Add-defensive-checks-for-offset-being-NULL.patch
 create mode 100644 
debian/patches/0017-Add-unit-tests-for-XML-tag-utility-functions.patch
 create mode 100644 debian/patches/0018-Add-implementation-of-nextTagData.patch
 create mode 100644 
debian/patches/0019-Switch-structFromXml-to-using-nextTagData.patch

diff --git a/debian/changelog b/debian/changelog
index 420c997..c3cc30a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ros-ros-comm (1.14.3+ds1-5+deb10u3) buster; urgency=medium
+
+  * Add https://github.com/ros/ros_comm/pull/2186 (Fix CVE-2021-37146)
+
+ -- Jochen Sprickerhof   Wed, 20 Oct 2021 21:43:47 +0200
+
 ros-ros-comm (1.14.3+ds1-5+deb10u2) buster; urgency=high
 
   * Add https://github.com/ros/ros_comm/pull/2065 (Fix CVE-2020-16124)
diff --git a/debian/patches/0015-Fix-oversize-string-test.patch 
b/debian/patches/0015-Fix-oversize-string-test.patch
new file mode 100644
index 000..489b651
--- /dev/null
+++ b/debian/patches/0015-Fix-oversize-string-test.patch
@@ -0,0 +1,25 @@
+From: Chris Lalancette 
+Date: Wed, 7 Jul 2021 14:34:14 +
+Subject: Fix oversize string test.
+
+It claims to be "well-formed", but the closing tag was wrong.
+Fix that here.
+
+Signed-off-by: Chris Lalancette 
+---
+ utilities/xmlrpcpp/test/TestValues.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utilities/xmlrpcpp/test/TestValues.cpp 
b/utilities/xmlrpcpp/test/TestValues.cpp
+index acd79c2..48730fd 100644
+--- a/utilities/xmlrpcpp/test/TestValues.cpp
 b/utilities/xmlrpcpp/test/TestValues.cpp
+@@ -180,7 +180,7 @@ TEST(XmlRpc, testOversizeString) {
+   try {
+ std::string xml = "";
+ xml += std::string(__INT_MAX__, 'a');
+-xml += "a";
++xml += "a";
+ int offset;
+ 
+ offset = 0;
diff --git 
a/debian/patches/0016-Add-defensive-checks-for-offset-being-NULL.patch 
b/debian/patches/0016-Add-defensive-checks-for-offset-being-NULL.patch
new file mode 100644
index 000..b0e024b
--- /dev/null
+++ b/debian/patches/0016-Add-defensive-checks-for-offset-being-NULL.patch
@@ -0,0 +1,45 @@
+From: Chris Lalancette 
+Date: Wed, 7 Jul 2021 17:23:39 +
+Subject: Add defensive checks for offset being NULL.
+
+Signed-off-by: Chris Lalancette 
+---
+ utilities/xmlrpcpp/src/XmlRpcUtil.cpp | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/utilities/xmlrpcpp/src/XmlRpcUtil.cpp 
b/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
+index ab0991d..a964b94 100644
+--- a/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
 b/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
+@@ -108,6 +108,7 @@ void XmlRpcUtil::error(const char* fmt, ...)
+ std::string 

Bug#1000607: bullseye-pu: package ros-ros-comm/1.15.9-ds1-7

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jspri...@debian.org

[ Reason ]
CVE-2021-37146 was published with a denial of service against
ros-ros-comm.

[ Impact ]
The impact is rather low as the ROS middleware has no authentication nor
security features implemented and should only be used behind a firewall.
Still would be good to get it fixed in stable.

[ Tests ]
The patch adds a unit test and I ran manual tests using the relay
command from the topic-tools package.

[ Risks ]
Except for one new method (nextTagData) I see the code as rather simple,
and the risk as low.
For nextTagData the difference is that it is more strict in parsing only
the next xml tag which should be fine in the defined domain. Also this
is part of the upstream releases and also in unstable since some time.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
The patches add three things:
- Null pointer checks in XmlRpc.
- Add and update unit tests for the new changes.
- A new nextTagData method. This is an improved version of the old
  parseTag version. Both methods extract the data inside of a given xml
  tag in a string. The old parseTag used find to search for the
  requested tag. The new nextTagData only allows space characters in
  front of the expected xml tag.

[ Other info ]
I kept the individual patches as upstream merged them, hope that is
fine.
>From 5f40cf6d70e063b1684651794cfb75aaca68bee3 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Wed, 20 Oct 2021 21:27:15 +0200
Subject: [PATCH] 1.15.9+ds1-7+deb11u1 (CVE-2021-37146)

---
 debian/changelog  |   6 +
 .../0010-Fix-oversize-string-test.patch   |  25 +
 ...fensive-checks-for-offset-being-NULL.patch |  45 ++
 ...-tests-for-XML-tag-utility-functions.patch | 653 ++
 ...13-Add-implementation-of-nextTagData.patch | 167 +
 ...h-structFromXml-to-using-nextTagData.patch |  31 +
 debian/patches/series |   5 +
 7 files changed, 932 insertions(+)
 create mode 100644 debian/patches/0010-Fix-oversize-string-test.patch
 create mode 100644 
debian/patches/0011-Add-defensive-checks-for-offset-being-NULL.patch
 create mode 100644 
debian/patches/0012-Add-unit-tests-for-XML-tag-utility-functions.patch
 create mode 100644 debian/patches/0013-Add-implementation-of-nextTagData.patch
 create mode 100644 
debian/patches/0014-Switch-structFromXml-to-using-nextTagData.patch

diff --git a/debian/changelog b/debian/changelog
index 057deda..a4d8cf2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ros-ros-comm (1.15.9+ds1-7+deb11u1) bullseye; urgency=medium
+
+  * Add https://github.com/ros/ros_comm/pull/2185 (Fix CVE-2021-37146)
+
+ -- Jochen Sprickerhof   Wed, 20 Oct 2021 21:28:10 +0200
+
 ros-ros-comm (1.15.9+ds1-7) unstable; urgency=medium
 
   * Fix Breaks+Replace
diff --git a/debian/patches/0010-Fix-oversize-string-test.patch 
b/debian/patches/0010-Fix-oversize-string-test.patch
new file mode 100644
index 000..2c4d781
--- /dev/null
+++ b/debian/patches/0010-Fix-oversize-string-test.patch
@@ -0,0 +1,25 @@
+From: Chris Lalancette 
+Date: Wed, 7 Jul 2021 14:34:14 +
+Subject: Fix oversize string test.
+
+It claims to be "well-formed", but the closing tag was wrong.
+Fix that here.
+
+Signed-off-by: Chris Lalancette 
+---
+ utilities/xmlrpcpp/test/TestValues.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utilities/xmlrpcpp/test/TestValues.cpp 
b/utilities/xmlrpcpp/test/TestValues.cpp
+index ce51bce..3cd0ade 100644
+--- a/utilities/xmlrpcpp/test/TestValues.cpp
 b/utilities/xmlrpcpp/test/TestValues.cpp
+@@ -214,7 +214,7 @@ TEST(XmlRpc, testOversizeString) {
+   try {
+ std::string xml = "";
+ xml += std::string(__INT_MAX__, 'a');
+-xml += "a";
++xml += "a";
+ int offset;
+ 
+ offset = 0;
diff --git 
a/debian/patches/0011-Add-defensive-checks-for-offset-being-NULL.patch 
b/debian/patches/0011-Add-defensive-checks-for-offset-being-NULL.patch
new file mode 100644
index 000..6426089
--- /dev/null
+++ b/debian/patches/0011-Add-defensive-checks-for-offset-being-NULL.patch
@@ -0,0 +1,45 @@
+From: Chris Lalancette 
+Date: Wed, 7 Jul 2021 17:23:39 +
+Subject: Add defensive checks for offset being NULL.
+
+Signed-off-by: Chris Lalancette 
+---
+ utilities/xmlrpcpp/src/XmlRpcUtil.cpp | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/utilities/xmlrpcpp/src/XmlRpcUtil.cpp 
b/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
+index 111737a..c203a91 100644
+--- a/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
 b/utilities/xmlrpcpp/src/XmlRpcUtil.cpp
+@@ -108,6 +108,7 @@ void XmlRpcUtil::error(const char* fmt, ...)
+ std::string 
+ XmlRpcUtil::parseTag(const char* tag, std::string 

Bug#997959: RM: git-annex [armel armhf] -- ROM; enduring issues building on 32-bit ARM architectures

[Sean Whitton]

reassign -1 ftp.debian.org
retitle -1 RM: git-annex [armel armhf] -- ROM; enduring issues building on 
32-bit ARM architectures
severity -1 normal
thanks

Recent releases of git-annex fail to build on 32-bit ARM architectures
and no-one has been able to figure out why, including upstream.  As this
situation has persisted for some weeks, I'd like to request removal on
those architectures for now.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1000372: ITP: ocaml-magic-mime -- OCaml library to map filenames to common MIME types

[Thaddeus H. Black]

On Mon, Nov 22, 2021 at 09:55:52AM +0100, Stéphane Glondu wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stéphane Glondu 
> X-Debbugs-Cc: debian-de...@lists.debian.org, 
> debian-ocaml-ma...@lists.debian.org
> 
> * Package name: ocaml-magic-mime
>   Version : 1.2.0
>   Upstream Author : Anil Madhavapeddy
> * URL : https://github.com/mirage/ocaml-magic-mime
> * License : ISC
>   Programming Lang: OCaml
>   Description : OCaml library to map filenames to common MIME types
> 
>  This library contains a database of MIME types that maps filename
>  extensions into MIME types suitable for use in many Internet
>  protocols such as HTTP or e-mail. It is generated from the mime.types
>  file found in Unix systems, but has no dependency on a filesystem
>  since it includes the contents of the database as an ML
>  datastructure.
> 
> This is a new transitive dependency of ocsigenserver.

A typical Debian system already has two such
databases: /etc/mime.types /usr/share/mime/globs

I do not mean to challenge you, nor to discourage you,
but am merely curious:  why a third database?


signature.asc
Description: PGP signature

Bug#984434: id3ren: Wrong homepage

[Eriberto Mota]

> I think that the homepage is now:
> https://github.com/sebcode/id3ren

This seems like a fork for a specific change only, not a new homepage.

Regards,

Eriberto

Bug#1000605: libreoffice: changelog contains git editing noise

[Rene Engelhard]

notfound 1000605 1:7.2.2-1

found 1000605 1:7.2.3-1

Hi,

Am 25.11.21 um 20:15 schrieb Jonas Smedegaard:
> Source: libreoffice
> Version: 1:7.2.2-1

Don't believe so. ITYM 1:7.2.3-1

> Severity: minor

>
> changelog contains the following git editing noise:
>
>  efaacb77 (actually only set TEST_TIMEOUT if we ignore the
> test results anyway...)
>
Not only that, it contains 7.3 changelog entries, too :/


How on earth did this happen and how did I not notice?


Thanks for pointing that out.


Regards,


Rene

Bug#1000605: libreoffice: changelog contains git editing noise

[Jonas Smedegaard]

Source: libreoffice
Version: 1:7.2.2-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

changelog contains the following git editing noise:

> >>> efaacb77 (actually only set TEST_TIMEOUT if we ignore the test 
> >>> results anyway...)

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGf4O8ACgkQLHwxRsGg
ASHK8A/+J6xjpzgFm8yTwvi+mt6jyHXbQgqBFufuCdjEifBCrmhsE8S+UfX+XSO0
nEto8zfirCE0dDLXlpScASB676UmcwqNrB28MOHgcnGn5xLDPk33gxBrkp47/0gc
j9t4xVAZm3nQexVI7FHynekifSVpn3OXz3QEwSYk3AK0MukFlqq7T+XPsEw9Zi5u
QTHl9SCHWELjuumXbLk8KvMP5IW5RtKArTCtXNSH4BPgE2V84xfZjE9Ps+AisYr8
69L2BnzY2pSsINQMflPk/RGQmChZboPBAtbmVEgbm/xkp70ZCDWorF1zSIv3V1k/
SLbdGhD2C3hRuaaeuEnirJl9URneXL6Rc0wAD0wV1uA/IPV06QpfA6khsCHgGYXf
Ep7DRq+shFIFajyO9cRbnapACKtxsQjriuCG85uRrVPmcqaOmBoUZFbdwLwfIGRE
Y7VXrLtzd+jHllZXo8FXVjgjqwFEIDNw6HuPESmAYzsub9bDjBbDCvbMGn3jEeQr
/bowTuo5nnZhlNJ32DKMuJN35GPadPg6nJnOmljnnXfJlzP/XRq59mhJmGOzzFfv
0YzgdCRDnCUdIPdSph3fYZ4YCC8HjANm9QpU3/q3bZk/FxmfTDPROyMRuuKB2wBc
o4BcBTlPXIx8ZadvV6gw9372t2x0KK4xwEgf4vch8JlHILUTw1Q=
=F9qh
-END PGP SIGNATURE-

Bug#1000604: ITP: golang-github-digitalocean-go-libvirt -- Pure Go interface for interacting with libvirt

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-digitalocean-go-libvirt
  Version : 0.0~git20210615.eaff166-1
  Upstream Author : DigitalOcean
* URL : https://github.com/digitalocean/go-libvirt
* License : Apache-2.0
  Programming Lang: Go
  Description : Pure Go interface for interacting with libvirt

 Provides a pure Go interface for interacting with libvirt. Rather than
 using libvirt's C bindings, this package makes use of libvirt's RPC
 interface. Connections to the libvirt server may be local, or remote.
 RPC packets are encoded using the XDR standard as defined by RFC 4506.

This package is a dependency for updating golang-github-digitalocean-
go-qemu, which is in turn a dependency of packaging LXD (ITP #768073)
and will be team-maintained within the Debian Go Packaging Team.

I am initially packaging the most recient version of golang-github-
digitalocean-go-libvirt that works nicely with golang-github-
digitalocean-go-qemu; there are a couple newer commits, but they change
the API and golang-github-digitalocean-go-qemu has not yet been updated
for those changes.


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

Bug#1000603: specutils FTBFS with Python 3.10

[Adrian Bunk]

Source: specutils
Version: 1.4.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=specutils=1.4.1-1%2Bb1

...
=== FAILURES ===
__ test_continuum_calculation __

def test_continuum_calculation():
"""
This test fits the first simulated spectrum from the fixture.  The
initial guesses are manually set here with bounds that essentially make
sense as the functionality of the test is to make sure the fit works and
we get a reasonable answer out **given** good initial guesses.
"""

x_single_continuum, y_single_continuum = single_peak_continuum()
spectrum = Spectrum1D(flux=y_single_continuum*u.Jy, 
spectral_axis=x_single_continuum*u.um)
g1_fit = fit_generic_continuum(spectrum)

>   spectrum_normalized = spectrum / g1_fit(spectrum.spectral_axis)

specutils/tests/test_continuum.py:60: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
specutils/spectra/spectrum1d.py:568: in __truediv__
return self.divide(other)
/usr/lib/python3/dist-packages/astropy/nddata/mixins/ndarithmetic.py:536: in 
divide
return self._prepare_then_do_arithmetic(np.true_divide, operand,
/usr/lib/python3/dist-packages/astropy/nddata/mixins/ndarithmetic.py:610: in 
_prepare_then_do_arithmetic
operand2 = cls(operand2)
specutils/spectra/spectrum1d.py:288: in __init__
spec_axis = self.wcs.pixel_to_world(np.arange(self.flux.shape[-1]))
specutils/utils/wcs_utils.py:217: in pixel_to_world
return super().pixel_to_world(*args, **kwargs).to(
/usr/lib/python3/dist-packages/gwcs/api.py:299: in pixel_to_world
return self(*pixels, with_units=True)
/usr/lib/python3/dist-packages/gwcs/wcs.py:379: in __call__
result = self.output_frame.coordinates(result)
/usr/lib/python3/dist-packages/gwcs/coordinate_frames.py:463: in coordinates
return coord.SpectralCoord(*args).to(self.unit[0])
/usr/lib/python3/dist-packages/astropy/units/decorators.py:304: in wrapper
return_ = wrapped_function(*func_args, **func_kwargs)
/usr/lib/python3/dist-packages/astropy/coordinates/spectral_coordinate.py:193: 
in __new__
obj = super().__new__(cls, value, unit=unit, **kwargs)
/usr/lib/python3/dist-packages/astropy/coordinates/spectral_quantity.py:57: in 
__new__
obj = super().__new__(cls, value, unit=unit, **kwargs)
/usr/lib/python3/dist-packages/astropy/units/quantity.py:425: in __new__
value = value.view(cls)
/usr/lib/python3/dist-packages/astropy/coordinates/spectral_coordinate.py:242: 
in __array_finalize__
super().__array_finalize__(obj)
/usr/lib/python3/dist-packages/astropy/coordinates/spectral_quantity.py:72: in 
__array_finalize__
super().__array_finalize__(obj)
/usr/lib/python3/dist-packages/astropy/units/quantity.py:550: in 
__array_finalize__
self._set_unit(unit)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <[AttributeError("SpectralCoord instance has no attribute 
'radial_velocity'") raised in repr()] SpectralCoord object at 0x7f389f6d3d10>
unit = Unit(dimensionless)

def _set_unit(self, unit):
if unit is None or not unit.is_equivalent(self._equivalent_unit):
>   raise UnitTypeError(
"{} instances require units equivalent to '{}'"
.format(type(self).__name__, self._equivalent_unit) +
(", but no unit was given." if unit is None else
 f", so cannot set it to '{unit}'."))
E   astropy.units.core.UnitTypeError: SpectralCoord instances require 
units equivalent to '(Unit("Hz"), Unit("m"), Unit("J"), Unit("1 / m"), Unit("km 
/ s"))', so cannot set it to ''.

/usr/lib/python3/dist-packages/astropy/units/quantity.py:1933: UnitTypeError
__ test_continuum_full_window __

def test_continuum_full_window():
"""
This test fits the first simulated spectrum from the fixture, but
with the fit_continuum function instead of fit_generic_continuum. Uses
a window to select the entire spectrum and checks that it recovers the
original, non-windowed fit.
"""

x_single_continuum, y_single_continuum = single_peak_continuum()
spectrum = Spectrum1D(flux=y_single_continuum*u.Jy, 
spectral_axis=x_single_continuum*u.um)

# Smooth in the same way fit_generic_continuum does.
spectrum_smoothed = median_smooth(spectrum, 3)

# Check that a full width window recovers the original, non-windowed 
fit.
g1_fit = fit_continuum(spectrum_smoothed, window=(0.*u.um, 10.*u.um))
g1_fit_orig = fit_continuum(spectrum_smoothed)

>   sp_normalized = spectrum / g1_fit(spectrum.spectral_axis)

specutils/tests/test_continuum.py:88: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Bug#998232: cargo segv when updating crates.io index

[Drew Vogel]

Daniel Berrange's workaround of setting 
`CARGO_NET_GIT_FETCH_WITH_CLI=true` works for me. I found it necessary 
to use this with the official debian:10-slim docker image. Thanks!



On Sun, 14 Nov 2021 08:29:20 +0100 Georg Brandl  wrote:

> On Mon, 01 Nov 2021 12:38:41 + "Daniel P. Berrange"
>  wrote:
> > Since about Oct 12th, we have been seeing cargo on Debian 10
> > crash with a segv when attempting to update crates.io index
> > in CI jobs.
> >
> > This was initially seen inside docker container running CI
> > pipelines in GitLab, but has been reproduced in regular
> > VM installs too and by multiple people
>
> This seems to be caused by cargo's libgit2. A workaround is to
> add "git" as a build dep and set CARGO_NET_GIT_FETCH_WITH_CLI=true
> in cargo's environment or set the corresponding option in
> .cargo/config.toml.
>
>

Bug#1000601: python3-casa-formats-io need to depend on a versioned python3-numpy

[Adrian Bunk]

Package: python3-casa-formats-io
Version: 0.1-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/arm64/c/casa-formats-io/16993092/log.gz

...
___ ERROR collecting tests/test_casa_dask.py ___
ImportError while importing test module 
'/usr/lib/python3/dist-packages/casa_formats_io/tests/test_casa_dask.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/usr/lib/python3/dist-packages/casa_formats_io/__init__.py:1: in 
from .casa_dask import *  # noqa
/usr/lib/python3/dist-packages/casa_formats_io/casa_dask.py:13: in 
from ._casa_chunking import _combine_chunks
E   ImportError: numpy.core.multiarray failed to import
--- Captured stderr 
RuntimeError: module compiled against API version 0xe but this version of numpy 
is 0xd
...


python3-casa-formats-io needs a generated dependency on python3-numpy-api*

Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1

[Felix Geyer]

On Sun, 10 Oct 2021 14:34:30 +0200 Felix Geyer  wrote:

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
libseccomp 2.5.1 only knows about syscall up to Linux 5.8.
The proposed changes add the syscalls up to Linux 5.14.

[ Impact ]
Syscalls for Linux 5.9 and 5.10 can't be allowed.

Software built with support for newer kernels (often the case in containers)
expect newer syscalls to work or return ENOSYS.
If that syscall is not supported by libseccomp and a default filter action of
returning EPERM is used, such software will break.
Therefore you often need to be able to allow a syscall even when the running
kernel doesn't support it.

[ Tests ]
* autopkgtest passes on amd64
* Verified adding a filter for the close_range() syscall works (new in 5.9)
* Verified that systemd and Docker run

[ Risks ]
The changes only extend the syscall csv table and add new syscall defines.

[ Checklist ]
   [x] *all* changes are documented in the d/changelog
   [x] I reviewed all changes and I approve them
   [x] attach debdiff against the package in (old)stable
   [x] the issue is verified as fixed in unstable

[ Changes ]
Cherry-pick upstream commits to support syscalls up to Linux 5.14.


I've updated the debdiff to include two more cherry-picked patches that add
a new syscalls from Linux 5.15 and missing syscall defines.

Felixdiff -Nru libseccomp-2.5.1/debian/changelog libseccomp-2.5.1/debian/changelog
--- libseccomp-2.5.1/debian/changelog   2020-12-21 10:50:30.0 +0100
+++ libseccomp-2.5.1/debian/changelog   2021-11-25 19:18:20.0 +0100
@@ -1,3 +1,9 @@
+libseccomp (2.5.1-1+deb11u1) bullseye; urgency=medium
+
+  * Add support for syscalls up to Linux 5.15.
+
+ -- Felix Geyer   Thu, 25 Nov 2021 19:18:20 +0100
+
 libseccomp (2.5.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch 
libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch
--- libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch 
1970-01-01 01:00:00.0 +0100
+++ libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch 
2021-11-24 19:09:09.0 +0100
@@ -0,0 +1,104 @@
+From 8379ee877612f027f75592c8de5bf7969aa7fb51 Mon Sep 17 00:00:00 2001
+From: Paul Moore 
+Date: Wed, 27 Oct 2021 15:39:17 -0400
+Subject: [PATCH] api: update seccomp-syscalls.h
+
+It appears that the seccomp-syscalls.h header file had gotten out of
+sync with the syscalls.csv syscall table, this patch fixes this
+disconnect.
+
+The only edit that is somewhat interesting is that the oldwait4(2)
+syscall probably never should have been included in the header file
+as it appears to no longer exist (?).
+
+Reported-by: Mike Frysinger 
+Acked-by: Tom Hromatka 
+Signed-off-by: Paul Moore 
+
+(imported from commit 3f47bba7c5c8cc18be80e625eedb2c1823233708)
+---
+ include/seccomp-syscalls.h | 22 --
+ 1 file changed, 16 insertions(+), 6 deletions(-)
+
+diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h
+index 7075f3f6..4baa307a 100644
+--- a/include/seccomp-syscalls.h
 b/include/seccomp-syscalls.h
+@@ -537,6 +537,8 @@
+ 
+ #define __SNR_epoll_pwait __NR_epoll_pwait
+ 
++#define __SNR_epoll_pwait2__NR_epoll_pwait2
++
+ #ifdef __NR_epoll_wait
+ #define __SNR_epoll_wait  __NR_epoll_wait
+ #else
+@@ -1007,6 +1009,10 @@
+ 
+ #define __SNR_kill__NR_kill
+ 
++#define __SNR_landlock_add_rule   __NR_landlock_add_rule
++#define __SNR_landlock_create_ruleset __NR_landlock_create_ruleset
++#define __SNR_landlock_restrict_self  __NR_landlock_restrict_self
++
+ #ifdef __NR_lchown
+ #define __SNR_lchown  __NR_lchown
+ #else
+@@ -1141,6 +1147,8 @@
+ 
+ #define __SNR_mount   __NR_mount
+ 
++#define __SNR_mount_setattr   __NR_mount_setattr
++
+ #ifdef __NR_move_mount
+ #define __SNR_move_mount  __NR_move_mount
+ #else
+@@ -1277,12 +1285,6 @@
+ #define __SNR_olduname__PNR_olduname
+ #endif
+ 
+-#ifdef __NR_oldwait4
+-#define __SNR_oldwait4__NR_oldwait4
+-#else
+-#define __SNR_oldwait4__PNR_oldwait4
+-#endif
+-
+ #ifdef __NR_open
+ #define __SNR_open__NR_open
+ #else
+@@ -1299,6 +1301,8 @@
+ 
+ #define __SNR_openat  __NR_openat
+ 
++#define __SNR_openat2 __NR_openat2
++
+ #ifdef __NR_pause
+ #define __SNR_pause   __NR_pause
+ #else
+@@ -1327,6 +1331,8 @@
+ 
+ #define __SNR_personality __NR_personality
+ 
++#define __SNR_pidfd_getfd __NR_pidfd_getfd
++
+ #ifdef __NR_pidfd_open
+ #define __SNR_pidfd_open  __NR_pidfd_open
+ #else
+@@ -1395,6 +1401,8 @@
+ 
+ #define __SNR_prlimit64   __NR_prlimit64
+ 
++#define __SNR_process_madvise 

Bug#1000600: libudev.a static library missing.

[Bram Stolk]

Package: libudev-dev
Version: 247.3-6

The libudev-dev package only comes with a shared library, not with a static
library.
https://packages.debian.org/bullseye/amd64/libudev-dev/filelist

NOTE: THIS WAS NOT ALWAYS THE CASE.

Somewhere along the line, the libudev.a file disappeared.
(It could have happened with the inclusion into systemd sources?)

This means that statically linking against libudev will fail:

/usr/bin/ld: cannot find -ludev
collect2: error: ld returned 1 exit status

I see no reason why libudev should not be available as a static library as
well.

Please include libudev.a in the libudev-dev package, so that statically
linking against libudev is possible again.


-- 
Owner/Director of Game Studio Abraham Stolk Inc.
Vancouver BC, Canada
b.st...@gmail.com

Bug#1000599: Don't require xdg-desktop-portal on Ubuntu i386

[Sebastien Bacher]

Package: webkit2gtk
Version: 2.34.2-1
Severity: minor

Dear maintainers,

The Ubuntu i386 archive is a partial one aimed at multiarch purpose and 
doesn't include desktop services as the xdg portal. The attached patch 
which is stacked on top of the recently submitted one to disable lto 
removes the recommends on the portal on that distribution and architecture


Thanks for considering!

Sebastien Bacher


diff -Nru webkit2gtk-2.34.2/debian/changelog webkit2gtk-2.34.2/debian/changelog
--- webkit2gtk-2.34.2/debian/changelog	2021-11-25 18:51:31.0 +0100
+++ webkit2gtk-2.34.2/debian/changelog	2021-11-25 18:51:31.0 +0100
@@ -3,6 +3,8 @@
   * debian/rules:
 - explicitly disable lto since when it's on the build is failing,
   that doesn't impact Debian by default but is an issue on Ubuntu 
+   - don't Recommends xdg-desktop-portal-gtk on Ubuntu i386, it's a partial
+ architecture and the binary doesn't exist
 
  -- Sebastien Bacher   Thu, 25 Nov 2021 18:51:31 +0100
 
diff -Nru webkit2gtk-2.34.2/debian/rules webkit2gtk-2.34.2/debian/rules
--- webkit2gtk-2.34.2/debian/rules	2021-11-25 18:51:31.0 +0100
+++ webkit2gtk-2.34.2/debian/rules	2021-11-25 18:51:31.0 +0100
@@ -66,8 +66,13 @@
 	CPPFLAGS += -DNDEBUG -DG_DISABLE_CAST_CHECKS
 endif
 
+# Don't Recommends xdg portals on Ubuntu i386 where it doesn't exist
+ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386)
+	EXTRA_CMAKE_ARGUMENTS += -DENABLE_BUBBLEWRAP_SANDBOX=ON
+	DH_GENCONTROL_ARGS += -Vbwrap:Depends="bubblewrap (>= 0.3.1), \
+	xdg-dbus-proxy"
 # Disable the bubblewrap sandbox if libseccomp-dev is not available
-ifeq ($(shell pkg-config --exists libseccomp && echo yes),yes)
+else ifeq ($(shell pkg-config --exists libseccomp && echo yes),yes)
 	EXTRA_CMAKE_ARGUMENTS += -DENABLE_BUBBLEWRAP_SANDBOX=ON
 	DH_GENCONTROL_ARGS += -Vbwrap:Depends="bubblewrap (>= 0.3.1), \
 	xdg-dbus-proxy"

Bug#1000598: Fail to build with lto

[Sebastien Bacher]

Package: webkit2gtk
Version: 2.34.2-1
Severity: minor

Dear maintainers,

Webkitgtk fails to build with lto, that's not a problem for Debian at 
the moment but we carry a delta in Ubuntu where LTO is enabled by 
default. The option shouldn't be an issue for Debian and allows us to 
lower the delta and might be useful for Debian as well at some point.


Thanks for considering the attached patch,

Sebastien Bacher


diff -Nru webkit2gtk-2.34.2/debian/changelog webkit2gtk-2.34.2/debian/changelog
--- webkit2gtk-2.34.2/debian/changelog	2021-11-24 15:56:26.0 +0100
+++ webkit2gtk-2.34.2/debian/changelog	2021-11-25 18:51:31.0 +0100
@@ -1,3 +1,11 @@
+webkit2gtk (2.34.2-2) UNRELEASED; urgency=medium
+
+  * debian/rules:
+- explicitly disable lto since when it's on the build is failing,
+  that doesn't impact Debian by default but is an issue on Ubuntu 
+
+ -- Sebastien Bacher   Thu, 25 Nov 2021 18:51:31 +0100
+
 webkit2gtk (2.34.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru webkit2gtk-2.34.2/debian/rules webkit2gtk-2.34.2/debian/rules
--- webkit2gtk-2.34.2/debian/rules	2021-11-24 15:56:26.0 +0100
+++ webkit2gtk-2.34.2/debian/rules	2021-11-25 18:51:31.0 +0100
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=-lto
 
 include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/buildflags.mk

Bug#964607: Massive update necessary

[Daniel Leidert]

This gem is out-of-date. Upstream is at 3.2.2, which requires packaging for
google-cloud-translate-v2 and google-cloud-translate-v3 and updating google-
cloud-core to >= 1.6. The tests require packageing google-style.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1000597: dnsproxy only works with DNS servers at localhost

[Marcos Talau]

Package: dnsproxy
Version: 1.17-2
Severity: serious
X-Debbugs-Cc: mar...@talau.info

Hi there,

The dnsproxy (1.17-2) only works with DNS servers at localhost. This is
a problem, as you cannot use DNS servers from other hosts. The problem was
introduced by patch 03_fix_listen_udp_port.patch. But without this patch,
the bug #1000159 comes back, and this can generate a possible security breach.

The discussion with upstream about this can be found here [1].

[1] https://github.com/awaw/dnsproxy/issues/6


Regards,
mt


signature.asc
Description: PGP signature

Bug#974217: RFS: python-radexreader/1.0.0-5 [ITP] -- Reader for the RADEX RD1212 Geiger counter

[Fabrice Creuzot]

I'm not sure what error you have encountered.
When I trying the following commands, it works (for me).
But perhaps it's not the good way.


dget -x 
https://mentors.debian.net/debian/pool/main/p/python-radexreader/python-radexreader_1.2.1-1.dsc


tar xzf python-radexreader_1.2.1.orig.tar.gz

tar xf python-radexreader_1.2.1-1.debian.tar.xz

cp -a debian/ python-radexreader-1.2.1/

cd python-radexreader-1.2.1/

debuild -b -uc -us

ls ../*deb
 ../python3-radexreader_1.2.1-1_all.deb
 ../radexreader_1.2.1-1_all.deb


Le 27/10/2021 à 22:28, Bastian Germann a écrit :

Control: tags -1 moreinfo

On Sun, 29 Nov 2020 13:08:01 +0100 Fabrice Creuzot  
wrote:

I uploaded a new package release (1.0.0-5).
I fixed lintian errors and I updated debian directory in source 
repository.


Building from git is broken. Please reupload a source package and remove 
this bug's moreinfo tag after that.

Bug#1000596: Not compatible with PHP 8

[David Prévot]

Package: php-db
Version: 1.10.0-1
Severity: normal
Control: block 976811 by -1

Hi,

PHP 8.1 being the default in experimental, we noticed some failing tests
in autopkgtest infrastructure:

FAIL DB::DB_Error[DB-1.10.0/tests/db_error.phpt]
FAIL DB::Error 2[DB-1.10.0/tests/db_error2.phpt]
FAIL DB::factory[DB-1.10.0/tests/db_factory.phpt]

There is a new upstream version (and maybe a few commits after that)
about PHP 8, so the package may just need to be updated to the latest
version.

Regards

David


signature.asc
Description: PGP signature

Bug#1000595: eom: does only save the last rotated image

[Philipp Pilhofer]

Package: eom
Version: 1.24.1-1
Severity: normal

Dear Maintainer,

* What led up to the situation?

Several images in a folder, and I want to rotate some of them by 90°

(I'm using MATE in German, so my translations of the actions might not be 100%
what is shown there in English.)

* What exactly did you do (or not do) that was effective (or
ineffective)?

Opening the first image, clicking on Rotate 90° left/right; moving on to the
next one etc; then closing the window, eom asks: "Do you want to save changes"
(with the possibility to tick/untick every changed image) — yes (for all).

* What was the outcome of this action?

It looks like all changed images are saved, as they are reloading thumbnails.
But only the last image is actually rotated, all others keep as they were. This
was working in debian buster (so probably eom 1.20.2)

* What outcome did you expect instead?

It should save all changed images, not only the last one.


-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (100, 'bullseye-fasttrack')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-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

Versions of packages eom depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2
ii eom-common 1.24.1-1
ii gir1.2-eom-1.0 1.24.1-1
ii libatk1.0-0 2.36.0-2
ii libc6 2.31-13+deb11u2
ii libcairo2 1.16.0-5
ii libexempi8 2.5.2-1
ii libexif12 0.6.22-3
ii libgdk-pixbuf2.0-0 2.40.2-2
ii libgirepository-1.0-1 1.66.1-1+b1
ii libgl1 1.3.2-1
ii libgl1-mesa-glx 20.3.5-1
ii libglib2.0-0 2.66.8-1
ii libgtk-3-0 3.24.24-4
ii libjpeg62-turbo 1:2.0.6-4
ii liblcms2-2 2.12~rc1-2
ii libmate-desktop-2-17 1.24.1-2
ii libpeas-1.0-0 1.28.0-2+b1
ii librsvg2-2 2.50.3+dfsg-1
ii librsvg2-common 2.50.3+dfsg-1
ii libx11-6 2:1.7.2-1
ii libxml2 2.9.10+dfsg-6.7
ii mate-desktop-common 1.24.1-2
ii shared-mime-info 2.0-1
ii zlib1g 1:1.2.11.dfsg-2

eom recommends no packages.

Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1

[Paul Gevers]

Hi Otto,

On 25-11-2021 17:15, Otto Kekäläinen wrote:

It would be much easier to target a stable update if the date (or at
least the month) was published on https://release.debian.org/


https://lists.debian.org/debian-devel-announce/2019/08/msg0.html

"""
Following the release of 10.1, we will continue to aim for stable point
releases on an approximately two-month basis, and oldstable every three
to four months.
"""

This is still valid.

Also:
https://lists.debian.org/debian-release/2021/11/msg00311.html
"""
tl;dr, suggested dates:

December 4th [least preferable for me]
December 11th
December 18th
"""

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1

[Otto Kekäläinen]

> > Before I submit the final debdiff and changelog I will wait for the
> > release date to show up at https://release.debian.org/
>
> Why? The longer you wait, the fewer changes you have to actually get the 
> update
> into the next point release. It'd be better to send those debdiffs early and
> give more time for ACKs or comments.

Last time I waited from July to September and what ended up in the
next stable update was eventually a different MariaDB release:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991221

If I send now 10.5.13+bugfixes for review but eventually we end up
uploading 10.5.14+bugfixes, then the intermediate work would be
inefficient use of time. In open source it is also important to keep
the window for contributions open and not immediately close it, in
particular if it then just remains closed for months in vain.
Therefore I will close the chapter on this release and make the final
changelog/debdiff at a time when I know that it actually is time to do
so.

It would be much easier to target a stable update if the date (or at
least the month) was published on https://release.debian.org/

Bug#1000292: Why was libpython3.10-dev not available in the test build?

[Andreas Beckmann]

On 25/11/2021 07.52, Graham Inggs wrote:

I think you can simply change the build-depends on python3-dev to
python3-all-dev.


That fixes the build for me.


Andreas

Bug#1000594: ITP: sfeed -- Collection of command-line tools for processing RSS and Atom feeds

[Sebastian Crane]

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

* Package name: sfeed
  Version : 1.0
  Upstream Author : Hiltjo Posthuma 
* URL : https://codemadness.org/sfeed-simple-feed-parser.html
* License : ISC
  Programming Lang: C
  Description : Collection of command-line tools for processing RSS and
Atom feeds

sfeed is a collection of command-line tools for converting RSS and Atom
feeds to and from other formats and for fetching, merging, filtering and
sorting feed items.

I use sfeed for processing RSS and Atom feeds in scripts (videos of my
sfeed-powered Telex-style ticker tape available upon request!) The
conversion to email (mbox) format to read in an email client can be very
useful, as email clients have features that are not typically found in
feedreaders, such as being able to forward items on to others.

sfeed has already been packaged for a number of other distributions
(notably Alpine Linux, FreeBSD, NetBSD and OpenBSD).

I'd like to maintain this package - it's pretty small, so I think I
would be able to maintain it alone. However, I am not a Debian
Maintainer, so I'll be requesting sponsorship in due course!

Bug#1000230: screenruler fails to start

[Georges Khaznadar]

Dear Peter,

please can you check whether installing the package
libcanberra-gtk3-module solves your issue?

If so, this package is probably missing as a dependency for screenruler,
and I can easily fix this bug.

Best regards,   Georges.

Peter Mueller a écrit :
> Package: screenruler
> Version: 0.960+bzr41+deb10-4
> I use Gnome on Wayland. Reproduce:
> 1) Open uxterm, bash being my shell.
> 2) Type in
> screenruler
> and press [Enter].
> 3) Observe:
> $ screenruler Loading libraries... Gtk-Message: 00:03:09.619: Failed to load 
> module "canberra-gtk-module" /usr/bin/screenruler:61:in `block in ': 
> 'Gdk::Pixbuf' has been deprecated. Use 'GdkPixbuf::Pixbuf'. 
> /usr/lib/ruby/vendor_ruby/gdk_pixbuf2/deprecated.rb:48:in `new': 
> GdkPixbuf::Pixbuf.new(path) is deprecated. Use GdkPixbuf::Pixbuf.new(:file => 
> path) instead. /usr/lib/ruby/vendor_ruby/gdk_pixbuf2/deprecated.rb:48:in 
> `new': GdkPixbuf::Pixbuf.new(path) is deprecated. Use 
> GdkPixbuf::Pixbuf.new(:file => path) instead. 
> /usr/lib/ruby/vendor_ruby/gdk_pixbuf2/deprecated.rb:48:in `new': 
> GdkPixbuf::Pixbuf.new(path) is deprecated. Use GdkPixbuf::Pixbuf.new(:file => 
> path) instead. Creating windows... Gtk-WARNING **: Unknown property: 
> GtkWindow.has-resize-grip from 
> /usr/share/screenruler/utils/glade_window.rb:29:in `initialize' from 
> /usr/share/screenruler/ruler_window.rb:51:in `initialize' from 
> /usr/bin/screenruler:76:in `new' from /usr/bin/screenruler:76:in `' 
> Reading settings... Presenting ruler... Shutting down...
> $ sudo aptitude show gnome|grep Version Version: 1:3.38+3
> I would be happy if I could kindly ask that my bug report finds attention.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#975911: [debian-mysql] Bug#975911: ctrl-w handling

[Otto Kekäläinen]

> Could we please change the default keybindings in Debian libedit2 itself,
> instead of having to do same as having to create following ~/.editrc
> for all users on all systems in order for seamless transition?

Modifying .editrc seems like a change that could have a lot of side
effects. Maybe "backwards compatibility" or migration from readline to
libedit should be handled by libedit in some more generic way so we
don't have to adapt in MariaDB packaging?

Or should we maybe go back to readline if it is better?

Bug#999740: Please upload libgc 8.0.6 to unstable

[Matthias Klose]

Control: tags -1 + moreinfo

> Note that the existing patches in the debian package are no longer needed:
> *  enable-threads-on-hurd.diff - see the explanation below

there was no explanation.

> *  issue329.diff - already in the upstream
> Required changes in libgc1.symbols (since 8.0.4):
> *  GC_next_used_block is removed
> *  GC_next_block is added

Also GC_unmap_end is removed.  Are the removed symbols referenced in any of the
reverse dependencies?  If yes then we have to change the library name, because
it's a transition.

Matthias

Bug#1000593: Failing testsuite with PHP 8.1

[David Prévot]

Package: php-console-commandline
Version: 1.2.1-1
Severity: normal
Control: block 976811 by -1

Hi,

The testsuite is currently failing with PHP 8:

FAIL [ 2/53] Test for Console_CommandLine::addArgument() 
method.[Console_CommandLine-1.2.1/tests/console_commandline_addargument.phpt]
[…]
FAIL [ 6/53] Test for Console_CommandLine::addCommand() 
method.[Console_CommandLine-1.2.1/tests/console_commandline_addcommand_3.phpt]
FAIL [ 7/53] Test for Console_CommandLine::addOption() 
method.[Console_CommandLine-1.2.1/tests/console_commandline_addoption.phpt]

There is a new upstream version (1.2.4), but I quickly checked that two
failures (first and last) still happen. (It’s also not a PEAR package
anymore, so need some work to convert the packaging to its Composer
source).


signature.asc
Description: PGP signature

Bug#1000588: evince,mailcap: "evince --new-window $file" opens the file chooser dialog instead of the requested file

[Simon McVittie]

Control: reassign -1 mailcap 3.70

On Thu, 25 Nov 2021 at 15:13:01 +0100, Julien Cristau wrote:
> since upgrading from bullseye to bookworm, opening a pdf from mutt
> doesn't work.  The /etc/mailcap entry says:
> 
> > application/pdf; evince --new-window %s; test=test -n "$DISPLAY"
> 
> and indeed "evince --new-window foo.pdf" doesn't actually open foo.pdf.
> 
> Maybe this is intended though, and the problem is how update-mime parses
> evince's desktop file?  Looks like it's using the Exec line from
> [Desktop Action new-window] (which didn't exist in bullseye) instead of
> from the main [Desktop Entry] section.

Yes, update-mime should only be parsing the fields from the
[Desktop Entry] group, something like this (untested):

my $in_desktop_group = 0;
while () {
chomp;
next if m/^\s*$|^\s*\#/);
if (m/^\[Desktop Entry\]$/) {
$in_desktop_group = 1;
next;
}
if (m/^\[.*\]$/) {
$in_desktop_group = 0;
next;
}
next unless $in_desktop_group;
if (m/^Terminal=(\w+)/i) {
... the rest of the current implementation ...
}

The [Desktop Action x] groups are not relevant when using an application
as a handler for opening files listed in MimeType.

See the specification[1] for full syntax.

smcv

[1] 
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

Bug#1000592: plasma: Touchpad Tap-to-click setting breaks

[Emmanuel Revah]

Package: systemsettings
Version: 4:5.20.5-2
Severity: normal
File: plasma

Dear Maintainer,

   * What led up to the situation?

At some random moment Tap-to-click stops working.

If I go to systemsettings -> Input Devices -> Touchpad and then uncheck and 
recheck "Tap-to-click", and then press "Apply", it goes works again.

I can re-confirm that the setting "Tap-to-click" was checked before the issue 
and during the issue, it just seems like it needs to be re-applied.


I hope this report is helpful.


Have a nice day,



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

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

Versions of packages systemsettings depends on:
ii  kio 5.78.0-5
ii  kpackagetool5   5.78.0-3
ii  libc6   2.31-13+deb11u2
ii  libkf5activities5   5.78.0-2
ii  libkf5activitiesstats1  5.78.0-2
ii  libkf5auth5 5.78.0-2
ii  libkf5authcore5 5.78.0-2
ii  libkf5completion5   5.78.0-3
ii  libkf5configcore5   5.78.0-4
ii  libkf5configgui55.78.0-4
ii  libkf5configwidgets55.78.0-2
ii  libkf5coreaddons5   5.78.0-4
ii  libkf5crash55.78.0-3
ii  libkf5dbusaddons5   5.78.0-2
ii  libkf5declarative5  5.78.0-2
ii  libkf5i18n5 5.78.0-2
ii  libkf5iconthemes5   5.78.0-2
ii  libkf5itemmodels5   5.78.0-2
ii  libkf5itemviews55.78.0-2
ii  libkf5kcmutils5 5.78.0-3
ii  libkf5kiogui5   5.78.0-5
ii  libkf5kiowidgets5   5.78.0-5
ii  libkf5package5  5.78.0-3
ii  libkf5quickaddons5  5.78.0-2
ii  libkf5service-bin   5.78.0-2
ii  libkf5service5  5.78.0-2
ii  libkf5widgetsaddons55.78.0-2
ii  libkf5windowsystem5 5.78.0-2
ii  libkf5xmlgui5   5.78.0-2
ii  libkworkspace5-54:5.20.5-6
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5qml5  5.15.2+dfsg-6
ii  libqt5quick55.15.2+dfsg-6
ii  libqt5quickwidgets5 5.15.2+dfsg-6
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6
ii  qml-module-org-kde-kcm  5.78.0-2
ii  qml-module-org-kde-kirigami25.78.0-3
ii  qml-module-org-kde-kitemmodels  5.78.0-2
ii  qml-module-qtquick-controls 5.15.2-2
ii  qml-module-qtquick-layouts  5.15.2+dfsg-6
ii  qml-module-qtquick2 5.15.2+dfsg-6

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information

Bug#998108: firefox freezes shortly after start

[dirdi]

After the upgrade to 94.0-2, I still experienced some crashes, but 
disabling hardware acceleration (about:preferences > General > 
Performance > uncheck both checkboxes and set processing limit to 8) 
fixed it for me.

Bug#975911: ctrl-w handling

[Matija Nalis]

I support idea that ctrl-w should retain behaviour that it had all
those years in libreadline5, until it was removed in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980504
and libedit2 made an drop-in replacement.

Could we please change the default keybindings in Debian libedit2 itself, 
instead of having to do same as having to create following ~/.editrc
for all users on all systems in order for seamless transition?

bind "^W" ed-delete-prev-word
bind "^_" vi-undo

Those two would at least (mostly) restore behaviour of two most
missing/changed features.

-- 
Opinions above are GNU-copylefted.

Bug#1000590: RM: postgresql-13 -- ROM; Superseded by postgresql-14

[Christoph Berg]

Package: ftp.debian.org
Severity: normal

Hi,

please remove postgresql-13 from unstable.

Current reverse deps:

Checking reverse dependencies...
# Broken Depends:
mimeo: postgresql-13-mimeo
pg-track-settings: postgresql-13-pg-track-settings
pgaudit: postgresql-13-pgaudit
pgq: postgresql-13-pgq3
pgq-node: postgresql-13-pgq-node
pgtap: postgresql-13-pgtap
postgresql-multicorn: postgresql-13-python3-multicorn
repmgr: postgresql-13-repmgr

# Broken Build-Depends:
postgresql-multicorn: postgresql-server-dev-13


multicorn is currently unfixable and can be left broken while we wait
to see if upstream has a fix, or if we should remove the package
(#1000589).

The others are cruft that should be removed as part of #1000402.

Christoph

Bug#1000589: Incompatible with PostgreSQL 14

[Christoph Berg]

Source: postgresql-multicorn
Version: 1.4.0-4
Severity: serious

Multicorn is incompatible with PostgreSQL 14 and needs non-trivial
porting while upstream work has stalled for the past two years.

https://github.com/Segfault-Inc/Multicorn/issues/271

In the meantime, it should be removed from testing.

Christoph

Bug#1000588: evince,mailcap: "evince --new-window $file" opens the file chooser dialog instead of the requested file

[Julien Cristau]

Package: evince, mailcap
Version: evince/41.2-1, mailcap/3.70

Hi,

since upgrading from bullseye to bookworm, opening a pdf from mutt
doesn't work.  The /etc/mailcap entry says:

> application/pdf; evince --new-window %s; test=test -n "$DISPLAY"

and indeed "evince --new-window foo.pdf" doesn't actually open foo.pdf.

Maybe this is intended though, and the problem is how update-mime parses
evince's desktop file?  Looks like it's using the Exec line from
[Desktop Action new-window] (which didn't exist in bullseye) instead of
from the main [Desktop Entry] section.

Cheers,
Julien

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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  evince-common41.2-1
ii  gsettings-desktop-schemas41.0-2
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libevdocument3-4 41.2-1
ii  libevview3-3 41.2-1
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.1-1
ii  libgnome-desktop-3-1941.1-1
ii  libgtk-3-0   3.24.30-3
ii  libhandy-1-0 1.4.0-1
ii  libnautilus-extension1a  41.1-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1
ii  libsecret-1-00.20.4-2
ii  shared-mime-info 2.0-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-3
ii  dbus-x11 [dbus-session-bus]   1.12.20-3

Versions of packages evince suggests:
ii  gvfs 1.48.1-2
ii  nautilus-sendto  3.8.6-3.1
ii  poppler-data 0.4.11-1
pn  unrar

-- no debconf information

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Sebastian Ramacher]

Hi

On 2021-11-25 13:22:12, Guillem Jover wrote:
> On Thu, 2021-11-25 at 12:26:29 +0100, [EXT] Vincent Lefevre wrote:
> > [Cc Sebastian Ramacher]
> > 
> > On 2021-11-25 21:42:48 +1100, Hugh McMaster wrote:
> > > On Thu, 25 Nov 2021 at 03:39, Vincent Lefevre wrote:
> > > >
> > > > On 2021-11-24 16:31:08 +0100, Guillem Jover wrote:
> > > > > The symlinks must be kept for backwards compat. Please see #998169 for
> > > > > the context of this packaging cleanup.
> > > >
> > > > OK, thanks. #998169 gives the explanation.
> > > >
> > > > Note that I was also wondering whether these symblinks are still
> > > > actually used. For instance, libgdal29 3.3.3+dfsg-2 depends on
> > > > libodbc1 (>= 2.3.1), but
> > > >
> > > > $ ldd /usr/lib/libgdal.so.29 | grep libodbc
> > > > libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 
> > > > (0x7fb732d54000)
> > > > libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 
> > > > (0x7fb732d3c000)
> > > >
> > > > So the .so.2 names are already used, and the symlinks are not needed
> > > > for libgdal29. Now, what about the other packages? Since these .so.2
> > > > sonames were added in 2013 (8 years ago!), I suppose that the old
> > > > .so.1 sonames are no longer used at all, so that no backward compat
> > > > symlinks are needed.
> > > 
> > > I've inspected a quarter of unixodbc's reverse dependencies so far and
> > > found all were using soversion 2.
> > > 
> > > As indicated in #998169, I had removed the symlinks but was advised to
> > > reinstate them.
> > 
> > If you mean Sebastian Ramacher's message
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998169#39
> > 
> > saying "libodbc1 and odbcinst1debian2 could then be transitional
> > packages with the compat symlinks that stay around at least for
> > bookworm." I suppose that Sebastian did not know that the .so.2
> > sonames were already used for some time (I recall that the change
> > in unixodbc was done in 2013). Was anything particular said on
> > #debian-release?
> > 
> > So I assume that only a transitional dummy package (without the
> > symlinks) is needed.
> 
> If we have to ship a transitional package anyway, I'm not sure why
> is there this pushback about shipping a couple of symlinks with it?
> The package will soon enough fade away.
> 
> (I mean if that implied we can solve this with just versioned
> Provides, I could understand but…)
> 
> > > I highly doubt that any package is linking via hard-coding to the
> > > old soname version.
> > 
> > Well, I think that the only potential issue is for old packages that
> > were built before the soname change in 2013 and were removed from
> > Debian at that time (thus are no longer rebuilt). But in practice,
> > compat symlinks are not kept that long, are they?
> 
> Or old locally built packages, or old third-party packages.
> 
> > Note that given the fact that libodbc1 depends on libltdl7 (>= 2.4.6),
> > which appeared in 2016, such packages from 2013 or earlier should
> > already be broken.
> 
> This would still break the "contract" of the package that potential
> reverse dependencies expect. I think there's a difference between say
> program symlinks and library symlinks, as the latter are the entire
> raison d'être of these package anyway. More so, when as per above, we
> need to ship the package in any case. :)

Indeed. These symlinks need to stay for satisfy the "contract"
of libodbc1. In bullseye, this currently is:

* libodbc.so.2
* libodbccr.so.2
* libodbc.so.1
* libodbccr.so.1

After upgrading to the bookworm version of libodbc1, the same SONAMEs
need to be provided. If the plan is to go ahead with the package clean
up, this means that libodbc1 needs to have a dependency on libodbc2 and
libodcbccr2 and it also needs provides the compat symlinks for
libodbc.so.1 and libodbccr.so.1. The same is also true for all the other
library packages that are being clean up.

What we can do after that was implemented, is to rebuild all packages in
bookworm to gain dependencies on libodbc2 and libodbccr2. Once this was
done and bookworm was released, one can think of dropping libodbc1 for
trixie.

Long story short: due to the non-transition in 2013, libodcb1 needs to
satisfy its promise to provide both the .1 and .2 versions.

Cheers
-- 
Sebastian Ramacher

Bug#1000450: Please package latest versions of modemmanager 1.18.2 (also libmbim, libqmi)

[Christoph Biedl]

Arnaud Ferraris wrote...

> modemmanager and its dependencies are now maintained by the
> DebianOnMobile team[1]. We have libqmi and libmbim ready to be uploaded
> (should happen anytime soon now), and modemmanager will follow once
> those reach unstable.

Okay, just a hint then: The package description could take an update,
the list of supported mobile devices has been extended to "5G" upstream.

Noticed that while updating my local fork.

Christoph


signature.asc
Description: PGP signature

Bug#997178: Build tested and ready as PR

[Christian Ehrhardt]

Hi,
I have opened PR [1] which fixes this (without the full bump to the new ABI)

[1]: https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/merge_requests/11

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#852757: apt calls malloc inside SIGWINCH handler, leading to deadlock

[David Kalnischkies]

Hi,

On Thu, Nov 25, 2021 at 07:30:45PM +0800, Zhang Boyang wrote:
> It seems my last email was marked spam. It's strange that the bug tracker
> has received my reply but the mailing list didn't. Please correct me if I
> misunderstand the situation.

Indeed, looks like your mail was dropped at some point. If you supply
sufficient details listmasters might be able to tell you what exactly
went wrong.

(The BTS seems to assign your mails ~ -10 points which is very good, but
 at the same time the list mail which passed through got 0, which is not
 bad, but also not particular good citing e.g. "MIME_BASE64_TEXT_BOGUS(1)
 R_DKIM_REJECT(1)". With patches you might be better of in salsa btw.)


> The patch is attached again for convenience. This patch implemented Anders's
> idea. The signal handler will only set a flag. After signal handler
> completed, the pselect() in pkgDPkgPM::Go() will return immediately with
> errno set to EINTR. Then, progress->Pluse() is called by pkgDPkgPM::Go(),
> and PackageManagerFancy::Pluse() will redraw the status bar.

Not having looked at the issue itself I just gave the patch a casual
glance: PackageManagerFancy is a public – hence exported – interface,
so you can't change member variables or add virtual methods as that
breaks the ABI.

At some point we will have one I am sure, but if at all possible it
could be better to investigate if that can be solved some other way.
(Not exactly sure why that is public at all, given there seems to also
 be a factory function to be able to hide it?)

Can we perhaps make it (still) easier to reproduce? apt can be told to
use a different dpkg via Dir::Bin::dpkg – can we have that be a script
which just spits out 'offending' lines (= is it the fd messages or the
messages on stdout for example – or both) ?


(Sorry for not being very specific at the moment as I am a bit starved
 for Debian time; will try to give that some proper thought/review
 ~next week)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#996696: google-http-client-java: please upgrade to version 1.40.1

[Markus Koschany]

On Tue, 26 Oct 2021 21:05:57 -0400 Olek Wojnar  wrote:
> Markus,
> 
> Sorry for the slow reply, it has been an extraordinarily crazy time over
> here recently. I'm barely keeping up on emails but I'm hoping that things
> quiet down a little in the coming weeks and allow me to catch up. This is
> near the top of my list!

I have dropped the add_depend.patch now because it is not very useful. Let me
know if there are any issues with bazel-bootstrap then I can take a look and we
find a better way.

Regards,

Markus



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

Bug#1000152: Upgrading libsasl2-modules to 2.1.27+dfsg-2.2 or up broke freeipa-client

[Timo Aaltonen]

On 25.11.2021 13.55, Bastian Germann wrote:

Control: found -1 2.1.27+dfsg-2.2

On Thu, 25 Nov 2021 08:37:40 +0200 Timo Aaltonen  
wrote:

As the topic says, -2.2. Downgrading to -2.1 makes things work again.


Ah, yes, I am sorry about that. Can you please recompile and install 
-2.1 on a sid system and
check whether you get the same result? As you said, the changes to -2.2 
can't be causing this.




-2.1 doesn't build in sid due to needing at least the sphinx fixes from 
-2.2 :)



--
t

Bug#1000587: python-fakeredis: (autopkgtest) needs update for python3.10: ModuleNotFoundError: No module named 'lupa._lupa'

[Paul Gevers]

Source: python-fakeredis
Version: 1.6.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python2.10 to the supported Python 
versions [0]. With a recent upload of python3-defaults the autopkgtest 
of python-fakeredis fails in testing when that autopkgtest is run with 
the binary packages of python3-defaults from unstable. It passes when 
run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.9.8-1
python-fakeredis   from testing1.6.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.10.html lists 
what's new in Python2.10, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-fakeredis/16956477/log.gz


 ERRORS 

_ ERROR at teardown of test_failed_script_error[fake] 
__


request = >

@pytest.fixture(
params=[
pytest.param('fake', marks=pytest.mark.fake),
pytest.param('real', marks=pytest.mark.real)
]
)
async def r(request):
if request.param == 'fake':
ret = await fakeredis.aioredis.create_redis_pool()
else:
if not request.getfixturevalue('is_redis_running'):
pytest.skip('Redis is not running')
ret = await aioredis.create_redis_pool('redis://localhost')
await ret.flushall()
yield ret
>   await ret.flushall()

test/test_aioredis1.py:34: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = >
async_op = False

def flushall(self, async_op=False):
"""
Remove all keys from all databases.
:param async_op: lets the entire dataset to be freed 
asynchronously. \

Defaults to False
"""
if async_op:
fut = self.execute(b'FLUSHALL', b'ASYNC')
else:

  fut = self.execute(b'FLUSHALL')


/usr/lib/python3/dist-packages/aioredis/commands/server.py:141: _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = >
command = b'FLUSHALL', args = (), kwargs = {}

def execute(self, command, *args, **kwargs):

  return self._pool_or_conn.execute(command, *args, **kwargs)


/usr/lib/python3/dist-packages/aioredis/commands/__init__.py:51: _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , command = 
b'FLUSHALL'

args = (), kw = {}, conn = , address = 'fakeredis'

def execute(self, command, *args, **kw):
"""Executes redis command in a free connection and returns
future waiting for result.
Picks connection from free pool and send command through
that connection.
If no connection is found, returns coroutine waiting for
free connection to execute command.
"""
conn, address = self.get_connection(command, args)
if conn is not None:

  fut = conn.execute(command, *args, **kw)


/usr/lib/python3/dist-packages/aioredis/pool.py:196: _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = , command = b'FLUSHALL', encoding = None
args = (), is_pubsub = False

def execute(self, command, *args, encoding=_NOTSET):
"""Executes redis command and returns Future waiting for the 
answer.

Raises:
* TypeError if any of args can not be encoded as bytes.
* ReplyError on redis '-ERR' responses.
* ProtocolError when response can not be decoded meaning connection
  is broken.
* ConnectionClosedError when either client or server has closed the
  connection.
"""
if self._reader is None or self._reader.at_eof():
msg = self._close_msg or "Connection closed or corrupted"
raise ConnectionClosedError(msg)
if command is None:
raise TypeError("command must not be None")
if None in args:
raise TypeError("args must not contain None")
command = command.upper().strip()
is_pubsub = command in _PUBSUB_COMMANDS
is_ping = command in ('PING', b'PING')
if self._in_pubsub and not (is_pubsub or is_ping):
raise RedisError("Connection in SUBSCRIBE mode")
elif is_pubsub:

Bug#1000586: dcmstack: (autopkgtest) needs update for python3.10: No module named 'numpy.core._multiarray_umath'

[Paul Gevers]

Source: dcmstack
Version: 0.8-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

With a recent upload of python3-defaults the autopkgtest of dcmstack 
fails in testing when that autopkgtest is run with the binary packages 
of python3-defaults from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
python3-defaults   from testing3.9.8-1
dcmstack   from testing0.8-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.10.html lists 
what's new in Python2.10, it may help to identify what needs to be 
updated. Additionally I was told that you may be missing a call to 
dh_numpy3 somewhere.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/arm64/d/dcmstack/16984530/log.gz

Testing with python3.10 in 
/tmp/autopkgtest-lxc.n5nw69fn/downtmp/autopkgtest_tmp:
= test session starts 
==
platform linux -- Python 3.10.0+, pytest-6.2.5, py-1.10.0, pluggy-0.13.0 
-- /usr/bin/python3.10

cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.n5nw69fn/downtmp/autopkgtest_tmp
collecting ... collected 0 items / 4 errors

 ERRORS 

__ ERROR collecting test/test_cli.py 
___
ImportError while importing test module 
'/tmp/autopkgtest-lxc.n5nw69fn/downtmp/autopkgtest_tmp/test/test_cli.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/numpy/core/__init__.py:22: in 
from . import multiarray
/usr/lib/python3/dist-packages/numpy/core/multiarray.py:12: in 
from . import overrides
/usr/lib/python3/dist-packages/numpy/core/overrides.py:7: in 
from numpy.core._multiarray_umath import (
E   ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'

During handling of the above exception, another exception occurred:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
test/test_cli.py:6: in 
import numpy as np
/usr/lib/python3/dist-packages/numpy/__init__.py:140: in 
from . import core
/usr/lib/python3/dist-packages/numpy/core/__init__.py:48: in 
raise ImportError(msg)
E   ImportError: E   E   IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW 
TO SOLVE THIS ISSUE!

E   E   Importing the numpy C-extensions failed. This error can happen for
E   many reasons, often due to issues with your setup or how NumPy was
E   installed.
E   E   We have compiled some common reasons and troubleshooting tips at:
E   E   https://numpy.org/devdocs/user/troubleshooting-importerror.html
E   E   Please note and check the following:
E   E * The Python version is: Python3.10 from "/usr/bin/python3.10"
E * The NumPy version is: "1.19.5"
E   E   and make sure that they are the versions you expect.
E   Please carefully study the documentation linked above for further help.
E   E   Original error was: No module named 'numpy.core._multiarray_umath'
 ERROR collecting test/test_dcmmeta.py 
_
ImportError while importing test module 
'/tmp/autopkgtest-lxc.n5nw69fn/downtmp/autopkgtest_tmp/test/test_dcmmeta.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/numpy/core/__init__.py:22: in 
from . import multiarray
/usr/lib/python3/dist-packages/numpy/core/multiarray.py:12: in 
from . import overrides
/usr/lib/python3/dist-packages/numpy/core/overrides.py:7: in 
from numpy.core._multiarray_umath import (
E   ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'

During handling of the above exception, another exception occurred:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
test/test_dcmmeta.py:9: in 
import numpy as np
/usr/lib/python3/dist-packages/numpy/__init__.py:140: in 
from . import core
/usr/lib/python3/dist-packages/numpy/core/__init__.py:48: in 
raise ImportError(msg)
E   ImportError: E   E   IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW 
TO SOLVE THIS ISSUE!

E   E   Importing the numpy C-extensions failed. This error can happen for
E   many reasons, often due to issues with your setup or how NumPy was
E   installed.
E   E   We have compiled some common reasons 

Bug#890822: Test #435: RunCMake.CPack_RPM Failed

[Timo Röhling]

Control: tag 890822 + unreproducible

Closing this bug due to inactivity; besides, it is probably not
relevant any more.

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1000585: Failed tests on PHP 8.1: expected output order change

[David Prévot]

Package: php-doctrine-common
Version: 3.2.0-1
Severity: normal
Tags: patch
Control: block 976811 by -1

The tests fail on PHP 8.1 because the output is displayed in a different
order. The simple attached patch fixes the issue, but needs to be
applied in sync when PHP 8.1 becomes the default in Debian.

Regards

David
From 38efa9220b7290aeddbfdfa6ab4e7a4f7423b5d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?David=20Pr=C3=A9vot?= 
Date: Thu, 25 Nov 2021 08:17:18 -0400
Subject: [PATCH] Reorder expected result for PHP 8.1

---
 tests/Doctrine/Tests/Common/Util/DebugTest.php | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/Doctrine/Tests/Common/Util/DebugTest.php b/tests/Doctrine/Tests/Common/Util/DebugTest.php
index 306810c9..191e8120 100644
--- a/tests/Doctrine/Tests/Common/Util/DebugTest.php
+++ b/tests/Doctrine/Tests/Common/Util/DebugTest.php
@@ -148,12 +148,12 @@ class DebugTest extends DoctrineTestCase
 'different-attributes' => [
 new TestAsset\ChildClass(),
 [
-'childPublicAttribute' => 4,
-'childProtectedAttribute:protected' => 5,
-'childPrivateAttribute:Doctrine\Tests\Common\Util\TestAsset\ChildClass:private' => 6,
 'parentPublicAttribute' => 1,
 'parentProtectedAttribute:protected' => 2,
 'parentPrivateAttribute:Doctrine\Tests\Common\Util\TestAsset\ParentClass:private' => 3,
+'childPublicAttribute' => 4,
+'childProtectedAttribute:protected' => 5,
+'childPrivateAttribute:Doctrine\Tests\Common\Util\TestAsset\ChildClass:private' => 6,
 ],
 ],
 'same-attributes' => [
@@ -161,8 +161,8 @@ class DebugTest extends DoctrineTestCase
 [
 'parentPublicAttribute' => 4,
 'parentProtectedAttribute:protected' => 5,
-'parentPrivateAttribute:Doctrine\Tests\Common\Util\TestAsset\ChildWithSameAttributesClass:private' => 6,
 'parentPrivateAttribute:Doctrine\Tests\Common\Util\TestAsset\ParentClass:private' => 3,
+'parentPrivateAttribute:Doctrine\Tests\Common\Util\TestAsset\ChildWithSameAttributesClass:private' => 6,
 ],
 ],
 ];
-- 
2.34.0



signature.asc
Description: PGP signature

Bug#1000554: RFS: libfm-qt/0.16.0-3.1 [NMU] [RC] -- Language package for libfm-qt

[Adam Borowski]

On Wed, Nov 24, 2021 at 04:14:29PM -0500, S. 7 wrote:
> I am looking for a sponsor for my package "libfm-qt":
> 
> * Package name : libfm-qt
> Version : 0.16.0-3.1

> libfm-qt (0.16.0-3.1) unstable; urgency=high
+  * Non-maintainer upload
+  * Update symbols to fix FTBFS. (Closes: #984102)
+
+ -- S. 7   Sat, 30 Oct 2021 18:19:55 +0200

The new symbols work on amd64 arm64, but are not enough on i386.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Ceterum censeo systemdinem esse delendam.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄
y

Bug#1000584: inkscape: confused by set-group-ID on directory

[Francesco Potortì]

Package: inkscape
Version: 1.1.1-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

I have a directory X with permissions drwxrwsr-x and umask 0002

I start Inkscape from a dirrente directory, read a pdf file from X and
export a bitmap conversion to directory X.

The file permissions are -rw--- (they should be -rw-rw-r--)

I remove the file and export again.  This time the file permissions are
-rw-r--r-- (they should be -rw-rw-r--).

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

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

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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 inkscape depends on:
ii  libatkmm-1.6-1v5   2.28.2-1
ii  libboost-filesystem1.74.0  1.74.0-13
ii  libc6  2.32-4
ii  libcairo2  1.16.0-5
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.6-2
ii  libdbus-glib-1-2   0.112-2
ii  libdouble-conversion3  3.1.5-7
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.11.0+dfsg-1
ii  libgc1 1:8.0.4-3
ii  libgcc-s1  11.2.0-10
ii  libgdk-pixbuf-2.0-02.42.6+dfsg-2
ii  libglib2.0-0   2.70.1-1
ii  libglibmm-2.4-1v5  2.66.2-1
ii  libgomp1   11.2.0-10
ii  libgsl25   2.6+dfsg-2
ii  libgspell-1-2  1.9.1-2
ii  libgtk-3-0 3.24.30-3
ii  libgtkmm-3.0-1v5   3.24.5-1
ii  libharfbuzz0b  2.7.4-1
ii  libjpeg62-turbo1:2.0.6-4
ii  liblcms2-2 2.12~rc1-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3
ii  libpango-1.0-0 1.48.10+ds1-1
ii  libpangocairo-1.0-01.48.10+ds1-1
ii  libpangoft2-1.0-0  1.48.10+ds1-1
ii  libpangomm-1.4-1v5 2.46.1-1
ii  libpng16-161.6.37-3
ii  libpoppler-glib8   20.09.0-3.1
ii  libpoppler102  20.09.0-3.1
ii  libpotrace01.16-2
ii  libreadline8   8.1-2
ii  librevenge-0.0-0   0.0.4-6+b1
ii  librsvg2-common2.50.7+dfsg-2
ii  libsigc++-2.0-0v5  2.10.4-2
ii  libsoup2.4-1   2.74.1-1
ii  libstdc++6 11.2.0-10
ii  libvisio-0.1-1 0.1.7-1+b1
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.7.2-2+b1
ii  libxml22.9.12+dfsg-5+b1
ii  libxslt1.1 1.1.34-4
ii  python33.9.7-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages inkscape recommends:
ii  aspell   0.60.8-4
ii  fig2dev  1:3.2.8b-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.3
ii  libwmf-bin   0.2.8.4-17+b1
ii  python3-lxml 4.6.4-1
ii  python3-numpy1:1.19.5-1
ii  python3-scour0.38.2-1

Versions of packages inkscape suggests:
ii  dia   0.97.3+git20160930-9+b1
pn  inkscape-tutorials
ii  libsvg-perl   2.86-1
ii  pstoedit  3.77-1
pn  python3-uniconvertor  
ii  ruby  1:2.7.6

-- no debconf information

Bug#999448: [External] Re: Bug#999448: atop: Two fixes for debian/rules: activate atopacctd before activating atop, load atop.default into pkg

[李菲]

On Thu, Nov 25, 2021 at 6:49 PM Marc Haber 
wrote:

> On Thu, Nov 25, 2021 at 03:34:15PM +0800, 李菲 wrote:
> > On Thu, Nov 25, 2021 at 3:32 AM Marc Haber <
> mh+debian-packa...@zugschlus.de>
> > wrote:
> > > On Thu, Nov 11, 2021 at 06:56:33PM +0800, 李菲 wrote:
> > > > wrote:
> > > > I guess the below 'Reproduce' can tell this :) That is, if atop
> starts
> > > > before
> > > > atopacctd, it will read from /var/cache/atop.d/atop.acct. Instead, if
> > > > atopacctd
> > > > starts earlier, atop will read from
> /run/pacct_shadow.d/00.paf
> > > > which is generated by atopacctd.
> > >
> > > Is this a race condition that only occurs once in a while? I tried it
> > > three times now on a test system and all three times it ended up with
> > > atop reading from the .paf file right after reboot.
> > >
> > You mean reboot the machine? I am wondering why rebooting
> > is needed after installing atop.
>
> It is not. I just tried to reproduce your issue.
>
> > I did the following check just
> > after installing atop without rebooting the machine. :)
> > As for the reboot, I am inclined to the problem is corrected
> > after rebooting, mainly due to the "Before=atop.service"
> > in atopacct.service file.
>
> So I need to de- and reinstall atop to reproduce this?
>
In short, build => install => check (no restart) should work.

Have a nice day, thanks
Fei

>
> 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#1000152: Upgrading libsasl2-modules to 2.1.27+dfsg-2.2 or up broke freeipa-client

[Bastian Germann]

Control: found -1 2.1.27+dfsg-2.2

On Thu, 25 Nov 2021 08:37:40 +0200 Timo Aaltonen  wrote:

As the topic says, -2.2. Downgrading to -2.1 makes things work again.


Ah, yes, I am sorry about that. Can you please recompile and install -2.1 on a 
sid system and
check whether you get the same result? As you said, the changes to -2.2 can't 
be causing this.

Bug#1000583: RFS: foomatic-filters/4.0.17-13 [RC] -- OpenPrinting printer support - filters

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "foomatic-filters":

   Package name: foomatic-filters
   Version : 4.0.17-13
   Upstream Author : Mailinglist 
   URL : https://wiki.linuxfoundation.org/openprinting/start
   License : GPL-2.0+, MIT
   Vcs : https://jff.email/cgit/foomatic-filters.git
   Section : text

It builds those binary packages:

  foomatic-filters - OpenPrinting printer support - filters
  foomatic-filters-beh - Openprinting Backend error handler

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

  https://mentors.debian.net/package/foomatic-filters/

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

 dget -x 
https://mentors.debian.net/debian/pool/main/f/foomatic-filters/foomatic-filters_4.0.17-13.dsc

or from 

 git https://jff.email/cgit/foomatic-filters.git/?h=release%2Fdebian%2F4.0.17-13



Changes since the last upload:

 foomatic-filters (4.0.17-13) unstable; urgency=medium
 .
   * Fix error processing package (Closes: #997318):
 - debian/foomatic-filters.postins: Switch to mktemp.
   * Declare compliance with Debian Policy 4.6.0.1 (No changes needed).
   * debian/copyright:
 - Add year 2021 to myself.

CU
Jörg

--
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


Jörg Frings-Fürst
D-54470 Lieser

git:  https://jff.email/cgit/


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#852757: apt calls malloc inside SIGWINCH handler, leading to deadlock

[Zhang Boyang]

Hello,

It seems my last email was marked spam. It's strange that the bug 
tracker has received my reply but the mailing list didn't. Please 
correct me if I misunderstand the situation.


My previous reply can be viewed at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852757


The patch is attached again for convenience. This patch implemented 
Anders's idea. The signal handler will only set a flag. After signal 
handler completed, the pselect() in pkgDPkgPM::Go() will return 
immediately with errno set to EINTR. Then, progress->Pluse() is called 
by pkgDPkgPM::Go(), and PackageManagerFancy::Pluse() will redraw the 
status bar.


I looked around for similar bugs. I found #947279 might be the same bug, 
but I don't have much evidence.


Best regards,
Zhang BoyangFrom 6cdd7fe9476a8149bc5bf18f70f9a8a30ba92d3a Mon Sep 17 00:00:00 2001
From: Zhang Boyang 
Date: Wed, 24 Nov 2021 23:34:04 +0800
Subject: [PATCH] Fix incorrect SIGWINCH handling

Previously, status line is redrawn in signal handler. However, the
drawing code make heavy use of std::string and other syscalls, which may
not be async-signal-safe. This will cause deadlock, overwritten errno,
even silent memory corruption.

With this patch, the signal handler will only set a flag, which is
async-signal-safe, and actual redrawing will be deferred to Pulse().

Closes: #852757
---
 apt-pkg/install-progress.cc | 31 +--
 apt-pkg/install-progress.h  |  8 +---
 2 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/apt-pkg/install-progress.cc b/apt-pkg/install-progress.cc
index aadd28e51..99f16bffa 100644
--- a/apt-pkg/install-progress.cc
+++ b/apt-pkg/install-progress.cc
@@ -222,22 +222,22 @@ PackageManagerFancy::PackageManagerFancy()
: d(NULL), child_pty(-1)
 {
// setup terminal size
-   old_SIGWINCH = signal(SIGWINCH, PackageManagerFancy::staticSIGWINCH);
-   instances.push_back(this);
+   if (instances++ == 0)
+  old_SIGWINCH = signal(SIGWINCH, PackageManagerFancy::staticSIGWINCH);
 }
-std::vector PackageManagerFancy::instances;
+int PackageManagerFancy::instances = 0;
+sighandler_t PackageManagerFancy::old_SIGWINCH;
+volatile sig_atomic_t PackageManagerFancy::SIGWINCH_flag = 0;
 
 PackageManagerFancy::~PackageManagerFancy()
 {
-   instances.erase(find(instances.begin(), instances.end(), this));
-   signal(SIGWINCH, old_SIGWINCH);
+   if (--instances == 0)
+  signal(SIGWINCH, old_SIGWINCH);
 }
 
-void PackageManagerFancy::staticSIGWINCH(int signum)
+void PackageManagerFancy::staticSIGWINCH(int)
 {
-   std::vector::const_iterator I;
-   for(I = instances.begin(); I != instances.end(); ++I)
-  (*I)->HandleSIGWINCH(signum);
+   SIGWINCH_flag = 1;
 }
 
 PackageManagerFancy::TermSize
@@ -294,13 +294,24 @@ void PackageManagerFancy::SetupTerminalScrollArea(int nr_rows)
  }
 }
 
-void PackageManagerFancy::HandleSIGWINCH(int)
+void PackageManagerFancy::HandleSIGWINCH()
 {
int const nr_terminal_rows = GetTerminalSize().rows;
SetupTerminalScrollArea(nr_terminal_rows);
DrawStatusLine();
 }
 
+void PackageManagerFancy::Pulse()
+{
+   if (SIGWINCH_flag)
+   {
+  SIGWINCH_flag = 0;
+  int errsv = errno;
+  HandleSIGWINCH();
+  errno = errsv;
+   }
+}
+
 void PackageManagerFancy::Start(int a_child_pty)
 {
child_pty = a_child_pty;
diff --git a/apt-pkg/install-progress.h b/apt-pkg/install-progress.h
index 94b66ed9b..d1dd3eb8a 100644
--- a/apt-pkg/install-progress.h
+++ b/apt-pkg/install-progress.h
@@ -125,12 +125,14 @@ namespace Progress {
 void * const d;
  private:
 APT_HIDDEN static void staticSIGWINCH(int);
-static std::vector instances;
+static int instances;
+static sighandler_t old_SIGWINCH;
+static volatile sig_atomic_t SIGWINCH_flag;
 APT_HIDDEN bool DrawStatusLine();
 
  protected:
 void SetupTerminalScrollArea(int nr_rows);
-void HandleSIGWINCH(int);
+void HandleSIGWINCH();
 
 typedef struct {
int rows;
@@ -138,12 +140,12 @@ namespace Progress {
 } TermSize;
 TermSize GetTerminalSize();
 
-sighandler_t old_SIGWINCH;
 int child_pty;
 
  public:
 PackageManagerFancy();
 virtual ~PackageManagerFancy();
+virtual void Pulse() APT_OVERRIDE;
 virtual void Start(int child_pty=-1) APT_OVERRIDE;
 virtual void Stop() APT_OVERRIDE;
 virtual bool StatusChanged(std::string PackageName,
-- 
2.30.2

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Vincent Lefevre]

[Cc Sebastian Ramacher]

On 2021-11-25 21:42:48 +1100, Hugh McMaster wrote:
> On Thu, 25 Nov 2021 at 03:39, Vincent Lefevre wrote:
> >
> > On 2021-11-24 16:31:08 +0100, Guillem Jover wrote:
> > > The symlinks must be kept for backwards compat. Please see #998169 for
> > > the context of this packaging cleanup.
> >
> > OK, thanks. #998169 gives the explanation.
> >
> > Note that I was also wondering whether these symblinks are still
> > actually used. For instance, libgdal29 3.3.3+dfsg-2 depends on
> > libodbc1 (>= 2.3.1), but
> >
> > $ ldd /usr/lib/libgdal.so.29 | grep libodbc
> > libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 
> > (0x7fb732d54000)
> > libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 
> > (0x7fb732d3c000)
> >
> > So the .so.2 names are already used, and the symlinks are not needed
> > for libgdal29. Now, what about the other packages? Since these .so.2
> > sonames were added in 2013 (8 years ago!), I suppose that the old
> > .so.1 sonames are no longer used at all, so that no backward compat
> > symlinks are needed.
> 
> I've inspected a quarter of unixodbc's reverse dependencies so far and
> found all were using soversion 2.
> 
> As indicated in #998169, I had removed the symlinks but was advised to
> reinstate them.

If you mean Sebastian Ramacher's message

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998169#39

saying "libodbc1 and odbcinst1debian2 could then be transitional
packages with the compat symlinks that stay around at least for
bookworm." I suppose that Sebastian did not know that the .so.2
sonames were already used for some time (I recall that the change
in unixodbc was done in 2013). Was anything particular said on
#debian-release?

So I assume that only a transitional dummy package (without the
symlinks) is needed.

> I highly doubt that any package is linking via hard-coding to the
> old soname version.

Well, I think that the only potential issue is for old packages that
were built before the soname change in 2013 and were removed from
Debian at that time (thus are no longer rebuilt). But in practice,
compat symlinks are not kept that long, are they?

Note that given the fact that libodbc1 depends on libltdl7 (>= 2.4.6),
which appeared in 2016, such packages from 2013 or earlier should
already be broken.

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

Bug#997178: FYI - Patch is upstream

[Christian Ehrhardt]

Hi,
I just wanted to say that the patch for this is upstream [1] so we
could either pick it as-is (as I know there were often enough problems
with the ABI making it hard to move) or even go for the new version.

$ git tag --contains 283fc17de8
release-3.23.1

[1]: 
https://gitlab.com/gpsd/gpsd/-/commit/283fc17de89f666d16b8cef45e7b8ecd602927cf

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#1000576: xserver-xorg-input-all: Please include other input drivers in dependencies

[Salvo Tomaselli]

To add more details, the kde touchpad config for libinput doesn't allow me
to use 2 and 3 fingers touch for middle and right click.

And the speed and acceleration of trackpoint can't be set as the same.

Best

Il gio 25 nov 2021, 11:06 Salvo "LtWorf" Tomaselli  ha
scritto:

> Package: xserver-xorg-input-all
> Version: 1:7.7+23
> Severity: critical
> Justification: breaks unrelated software
> X-Debbugs-Cc: tipos...@tiscali.it
>
> Dear Maintainer,
>
> because of libinput not behaving properly with my trackpoint, and the
> maintainer
> refusing to add the necessary configuration options to make it behave like
> I
> think it should behave, I never use the libinput driver and just remove it
> in
> favour of synaptics.
>
> However since xserver-xorg-input-all depends only on the libinput driver,
> what
> happens is that the entire desktop task gets uninstalled when doing this
> operation,
> which means that a lot of stuff that is completely unrelated and that I
> need
> gets removed as well.
>
> Please consider adding "| xserver-xorg-input-synaptics" in the dependency
> field,
> so that my desktop environment doesn't get removed when I try to use the
> input
> driver that works better for me.
>
> Best
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages xserver-xorg-input-all depends on:
> ii  xserver-xorg-input-libinput  1.2.0-1
>
> Versions of packages xserver-xorg-input-all recommends:
> ii  xserver-xorg-input-wacom  0.34.99.1-1+b1
>
> xserver-xorg-input-all suggests no packages.
>
> -- no debconf information
>

Bug#999448: [External] Re: Bug#999448: atop: Two fixes for debian/rules: activate atopacctd before activating atop, load atop.default into pkg

[Marc Haber]

On Thu, Nov 25, 2021 at 03:34:15PM +0800, 李菲 wrote:
> On Thu, Nov 25, 2021 at 3:32 AM Marc Haber 
> wrote:
> > On Thu, Nov 11, 2021 at 06:56:33PM +0800, 李菲 wrote:
> > > wrote:
> > > I guess the below 'Reproduce' can tell this :) That is, if atop starts
> > > before
> > > atopacctd, it will read from /var/cache/atop.d/atop.acct. Instead, if
> > > atopacctd
> > > starts earlier, atop will read from /run/pacct_shadow.d/00.paf
> > > which is generated by atopacctd.
> >
> > Is this a race condition that only occurs once in a while? I tried it
> > three times now on a test system and all three times it ended up with
> > atop reading from the .paf file right after reboot.
> >
> You mean reboot the machine? I am wondering why rebooting
> is needed after installing atop.

It is not. I just tried to reproduce your issue.

> I did the following check just
> after installing atop without rebooting the machine. :)
> As for the reboot, I am inclined to the problem is corrected
> after rebooting, mainly due to the "Before=atop.service"
> in atopacct.service file.

So I need to de- and reinstall atop to reproduce this?

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#991511: fontmanager.app: Font size change has no effect

[Gürkan Myczko]

Hi Matthias,

Could you provide a screenshot? I can use the slider and the font size 
pulldown menu items to change the font size in

above view.

Maybe also tell what window manager/desktop environment, and using which 
fonts this happens.


Thanks,

Bug#1000579: rdkit: autopkgtest regression

[Paul Gevers]

Source: rdkit
Version: 202103.5-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of rdkit the autopkgtest of rdkit fails in testing 
when that autopkgtest is run with the binary packages of rdkit from 
unstable. It passes when run with only packages from testing. In tabular 
form:


   passfail
rdkit  from testing202103.5-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rdkit

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rdkit/16957749/log.gz

### PostgreSQL 14 installcheck ###
Creating new PostgreSQL cluster 14/regress ...
make: Entering directory 
'/tmp/autopkgtest-lxc.d5zz2gpa/downtmp/build.YIU/src/Code/PgSQL/rdkit'
/usr/lib/postgresql/14/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress 
--inputdir=/tmp/autopkgtest-lxc.d5zz2gpa/downtmp/build.YIU/src 
--bindir='/usr/lib/postgresql/14/bin'--dbname=contrib_regression 
rdkit-91 props btree molgist bfpgist-91 bfpgin sfpgist slfpgist fps 
reaction  (using postmaster on localhost, port 5433)

== dropping database "contrib_regression" ==
NOTICE:  database "contrib_regression" does not exist, skipping
DROP DATABASE
== creating database "contrib_regression" ==
CREATE DATABASE
ALTER DATABASE
== running regression test queries==
test rdkit-91 ... ok 2975 ms
test props... ok   69 ms
test btree... ok  536 ms
test molgist  ... ok 1352 ms
test bfpgist-91   ... ok   97 ms
test bfpgin   ... ok  221 ms
test sfpgist  ... ok   80 ms
test slfpgist ... ok   96 ms
test fps  ... ok   88 ms
test reaction ... FAILED 3389 ms

===
 1 of 10 tests failed. ===

The differences that caused some tests to fail can be viewed in the
file 
"/tmp/autopkgtest-lxc.d5zz2gpa/downtmp/build.YIU/src/Code/PgSQL/rdkit/regression.diffs". 
 A copy of the test summary that you see
above is saved in the file 
"/tmp/autopkgtest-lxc.d5zz2gpa/downtmp/build.YIU/src/Code/PgSQL/rdkit/regression.out".


make: *** [/usr/lib/postgresql/14/lib/pgxs/src/makefiles/pgxs.mk:433: 
installcheck] Error 1
make: Leaving directory 
'/tmp/autopkgtest-lxc.d5zz2gpa/downtmp/build.YIU/src/Code/PgSQL/rdkit'
*** /tmp/pg_virtualenv.TNKdYW/log/postgresql-14-regress.log (last 100 
lines) ***
2021-11-24 12:12:29.980 UTC [4556] LOG:  starting PostgreSQL 14.1 
(Debian 14.1-1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 
11.2.0-10) 11.2.0, 64-bit
2021-11-24 12:12:29.980 UTC [4556] LOG:  listening on IPv6 address 
"::1", port 5433
2021-11-24 12:12:29.980 UTC [4556] LOG:  listening on IPv4 address 
"127.0.0.1", port 5433
2021-11-24 12:12:29.980 UTC [4556] LOG:  listening on Unix socket 
"/tmp/.s.PGSQL.5433"
2021-11-24 12:12:29.982 UTC [4557] LOG:  database system was shut down 
at 2021-11-24 12:12:29 UTC
2021-11-24 12:12:29.985 UTC [4556] LOG:  database system is ready to 
accept connections
2021-11-24 12:12:32.321 UTC [4621] debci@contrib_regression WARNING: 
could not create molecule from SMILES 'c1c'
2021-11-24 12:12:32.321 UTC [4621] debci@contrib_regression WARNING: 
could not create molecule from SMILES 'cc'
2021-11-24 12:12:32.323 UTC [4621] debci@contrib_regression WARNING: 
could not create molecule from SMILES 'c1ccc'
2021-11-24 12:12:35.211 UTC [4621] debci@contrib_regression ERROR: 
Unknown flag value: 'BOGUS'. Flags ignored.
2021-11-24 12:12:35.211 UTC [4621] debci@contrib_regression STATEMENT: 
select 'C1C(C)C1'::mol @> 
mol_adjust_query_properties('C1CC1CC'::mol,'{"adjustDegreeFlags":"bogus"}');
2021-11-24 12:12:35.214 UTC [4621] debci@contrib_regression WARNING: 
could not create molecule from CTAB 'a'
2021-11-24 12:12:35.214 UTC [4621] debci@contrib_regression WARNING: 
could not create molecule from SMILES 'a'
2021-11-24 12:12:35.214 UTC [4621] debci@contrib_regression WARNING: 
could not create molecule from SMILES 'C1C'
2021-11-24 12:12:35.285 UTC [4625] debci@contrib_regression WARNING: 
computeNMMolHash: hash BogusValue not recognized, using AnonymousGraph

Dropping cluster 14/regress ...
 
/tmp/autopkgtest-lxc.d5zz2gpa/downtmp/build.YIU/src/Code/PgSQL/rdkit/regression.diffs 

diff -U3