Bug#995085: dlt-viewer: missing installed headers in -dev packages

[Gianfranco Costamagna]

control: forcemerge -1 993562
control: close -1
control: fixed -1 2.21.2+dfsg-3
control: fixed -1 2.21.2+dfsg-2+deb11u1
On Sat, 25 Sep 2021 22:23:45 +0200 Gianfranco Costamagna 
 wrote:
> Source: dlt-viewer
> Version: 2.21.2+dfsg-2
> Severity: serious
> tags: patch
> Fixed: 2.21.2+dfsg-3
> 
> Hello, the package doesn't install lots of header files, see 
> https://bugs.debian.org/993564 for more information.
> 
> G.
> 
> 

Bug#995495: Working versions

[debian]

 The following prebuilt versions exhibit this bug:

linux-image-5.13.0-trunk-amd64-unsigned_5.13.9-1~exp2_amd64.deb

linux-image-5.13.0-trunk-amd64-unsigned_5.13.12-1~exp1_amd64.deb

And this one works fine:

linux-image-5.10.0-9-amd64-unsigned_5.10.70-1_amd64.deb

Bug#993260: the apng2gif git repo had updated

[肖盛文]

Hi,

    After I know the apng2gif (1.8-3) uploaded, I add the tag 
debian/1.8-3 and pushed all to the git repo.


vcswatch is OK now:

https://qa.debian.org/cgi-bin/vcswatch?package=apng2gif

Thanks for your remind.

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#995495: linux-image-5.14.0-1-amd64: amdgpu fails to initialize (ring gfx test failed, hw_init of IP block failed)

[Stefan Muenzel]

Package: src:linux
Version: 5.14.6-3
Severity: important
X-Debbugs-Cc: deb...@s.muenzel.net

amdgpu fails to initialize at boot with linux-image-5.14.0.1-amd64, the
same system boots using 5.10.0-1-amd64.

Graphics card is a Radeon PRO WX 3200, CPU is a AMD Ryzen 9 3900X,
motherboard is ASRock X570 Taichi using latest BIOS.

-- Package-specific info:
** Version:
Linux version 5.14.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.3.0-11) 10.3.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian 
5.14.6-3 (2021-09-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.14.0-1-amd64 root=/dev/mapper/smallssd-sid--root ro 
quiet

** Tainted: D (128)
 * kernel died recently, i.e. there was an OOPS or BUG

** Kernel log:
[0.00] Linux version 5.14.0-1-amd64 (debian-ker...@lists.debian.org) 
(gcc-10 (Debian 10.3.0-11) 10.3.0, GNU ld (GNU Binutils for Debian) 2.37) #1 
SMP Debian 5.14.6-3 (2021-09-28)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.0-1-amd64 
root=/dev/mapper/smallssd-sid--root ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'compacted' format.
[0.00] signal: max sigframe size: 1776
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x09afefff] usable
[0.00] BIOS-e820: [mem 0x09aff000-0x09ff] reserved
[0.00] BIOS-e820: [mem 0x0a00-0x0a1f] usable
[0.00] BIOS-e820: [mem 0x0a20-0x0a213fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x0a214000-0xbb6c] usable
[0.00] BIOS-e820: [mem 0xbb6d-0xbcd18fff] reserved
[0.00] BIOS-e820: [mem 0xbcd19000-0xbcd4afff] ACPI data
[0.00] BIOS-e820: [mem 0xbcd4b000-0xbd436fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbd437000-0xbdf77fff] reserved
[0.00] BIOS-e820: [mem 0xbdf78000-0xbdffefff] type 20
[0.00] BIOS-e820: [mem 0xbdfff000-0xbeff] usable
[0.00] BIOS-e820: [mem 0xbf00-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfd20-0xfd2f] reserved
[0.00] BIOS-e820: [mem 0xfd40-0xfd5f] reserved
[0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved
[0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] reserved
[0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00183f2f] usable
[0.00] BIOS-e820: [mem 0x00183f30-0x00183fff] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.70 by American Megatrends
[0.00] efi: ACPI=0xbd41e000 ACPI 2.0=0xbd41e014 TPMFinalLog=0xbd3e8000 
SMBIOS=0xbde24000 SMBIOS 3.0=0xbde23000 MEMATTR=0xb8074298 ESRT=0xb5871598 
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 3.2.0 present.
[0.00] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./X570 Taichi, 
BIOS P4.60 08/03/2021
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3800.090 MHz processor
[0.10] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.11] e820: remove [mem 0x000a-0x000f] usable
[0.17] last_pfn = 0x183f300 max_arch_pfn = 0x4
[0.000639] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.000861] e820: update [mem 0xbceb-0xbceb] usable ==> reserved
[0.000866] e820: update [mem 0xc000-0x] usable ==> reserved
[0.000870] last_pfn = 0xbf000 max_arch_pfn = 0x4
[0.007121] esrt: Reserving ESRT space from 0xb5871598 to 
0xb58715d0.
[0.007131] e820: update [mem 0xb5871000-0xb5871fff] usable ==> reserved
[0.007168] 

Bug#995494: bullseye-pu: package vim/2:8.2.2434-3+deb11u1

[James McCoy]

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

[ Reason ]
* Vim has some recent "no DSA" CVEs which, although unlikely to hit,
  would be good to fix (#994497, #994498, #994076)

* In the buster -> bullseye upgrade, vim-gtk becomes a transitional
  package, switching to vim-gtk3.  The vim-gtk alternatives weren't
  cleaned up, so there's a lot of noise during the upgrade about
  dangling links for alternatives and a window where the symlinks may
  not exist (#993766).

[ Impact ]
* Off chance that Vim crashes or twiddles some bits in memory it
  shouldn't be.

[ Tests ]
* The CVE fixes all come with tests from upstream.

* I've manually tested the upgrade scenario described in #993766.  The
  scary warnings about dangling links are fixed, but the scenario
  encountered (conffile editing needed with no alternative link in
  place) isn't something I see an obvious way to fix.

  I've also tested upgrading from current bullseye to the proposed
  changes.

  The most likely reason to encounter the bug is if /etc/vim/vimrc,
  which is a conffile, is modified, since it will cause dpkg's conffile
  prompt to happen.  At this point, buster vim-gtk's files have been
  removed but vim-common is being configured before vim-gtk3, so the new
  alternatives haven't been established.

  The binaries are already in place, so the user can run vim.gtk3, but
  it's not what their fingers (or possibly $VISUAL/$EDITOR) expects to
  use.

[ Risks ]
Low risk.  CVE fixes are pretty small and covered by new tests.  The
alternatives issue is targeted

[ 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
  * Aside from the vim-gtk -> vim-gtk3 change, which is buster ->
bullseye specific.

[ Changes ]
attached

[ Other info ]
n/a


vim_8.2.2434-3+deb11u1.diff
Description: Binary data

Bug#995467: ITS: mlton

[Henry Cejtin]

That would be fantastic.
Although I live on Debian systems, I don't really know anything about
making Debian packages.
I was looking at what it took and it was more than I could do.

The best thing would be some kind of script to go from the Git
repository to the package.
I looked at the difference between the Git log comments and the changelog.

On Fri, Oct 1, 2021 at 10:33 AM Ryan Kavanagh  wrote:
>
> Package: mlton
> Version: 20130715-3
> Severity: important
>
> Hi,
>
> I intend to salvage [0] the mlton package. It has been uninstallable for
> years now [1], and has had other RC bugs since 2018 [2, 3]. I attempted
> to contact the current maintainer a month ago (with MIA CC'd) to
> determine if they were still interested in maintaining the package, but
> I have received no response.
>
> Best,
> Ryan
>
> [0] 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992097
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904475
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917644
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 mlton depends on:
> ii  mlton-compiler  20130715-3
> ii  mlton-doc   20130715-3
> ii  mlton-tools 20130715-3
>
> mlton recommends no packages.
>
> mlton suggests no packages.
>
> -- no debconf information
>
> --
> |)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
> |\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A

Bug#995493: ITP: python-elgato-streamdeck -- Python 3 library to control an Elgato Stream Deck

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-elgato-streamdeck
  Version : 0.8.5
  Upstream Author : Dean Camera 
* URL : https://github.com/abcminiuser/python-elgato-streamdeck
* License : MIT
  Programming Lang: Python
  Description : Python 3 library to control an Elgato Stream Deck

 This is an open source Python 3 library to control an Elgato Stream Deck
 directly, without the official software. This can allow to create custom
 front-ends, such as a custom control front-end for home automation software.

Bug#995492: lintian: Broken --fails-on=none as default never got reverted

[Guillem Jover]

Package: lintian
Version: 2.77.0
Severity: serious

Sigh,

So the problematic --fail-on default change never got actually reverted
as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e
omitted the relevant part that would make it work. :(

None of the previous arguments against the default change brought up
in #962158 have stopped being relevant (also contrary to the commit
message…). Worse, this sneaked in what has shipped now in a stable
Debian release. :( So any errors found in CI systems and through other
tooling has been silently ignored since then. :/

Only noticed now due to #994414, a great excuse to now keep the broken
behavior I guess. (Where the --help output still does not match…)

Unamused,
Guillem

Bug#990417: openjdk-11-jre-headless: running java in qemu s390 gives a SIGILL at C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8

[John Neffenger]

On Mon, 28 Jun 2021 19:28:21 +0200 Arne Plöse  wrote:

#  SIGILL (0x4) at pc=0x03ff88c7e6f4, pid=587, tid=588
#
# Problematic frame:
# C  [linux-vdso64.so.1+0x6f8]  __kernel_getcpu+0x8


I get the same error on Ubuntu 20.04 LTS and the latest QEMU 6.1, so I 
created bug reports for the Ubuntu QEMU package:


Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8'
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1945540

and also for the upstream QEMU project:

Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8'
https://gitlab.com/qemu-project/qemu/-/issues/655

John

Bug#995491: ath11k regression for Dell XPS 13 9310 breaks WiFi

[Paul Tagliamonte]

Package: linux
Version: 5.14.6-3
Tags: fixed-upstream
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=214455
thanks

After updating my kernel, my Dell XPS 13's WiFi stopped working. This
is related to an upstream changeset introduced in 5.14.5 and 5.13.18;
and is fixed in 5.14.7.

The patch is present in
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/net/qrtr?id=d2cabd2dc8da78faf9b690ea521d03776686c9fe

I suspect we don't want to carry this patch, I'm opening this bug to
make this a bit more discoverable to other Dell XPS ath11k users, and
to have any related discussion in one place. I suspect we'll all have
to wait until 5.14.7+ is sent up to sid; which should be fine.

Thanks for your work maintaining Linux,
  Paul


-- 
:wq

Bug#995490: lintian: false positive python3-script-but-no-python3-dep with Depends: python3, seems to want python3:any instead

[Simon McVittie]

Package: lintian
Version: 2.107.0
Severity: normal

xdg-desktop-portal-tests has a python3 script. It also has
"Depends: python3".

This is now diagnosed as "python3-script-but-no-python3-dep"; looking at
recent commits, Lintian seems to want it to depend on python3:any instead.
I think that's incorrect: a dependency on either python3 or python3:any
guarantees that some sort of /usr/bin/python3 will be available, so
either one should be considered to be acceptable, and the tag should
only be emitted if neither of those dependencies is present.

For *many* use-cases, a dependency on python3:any is *preferred*: it'ss
a less specific dependency than python3, as I'll explain further below,
so it constrains the dependency solution less (and in particular it's
helpful to people who want to cross-compile or install packages from a
secondary architecture). However, for *some* use-cases, a dependency on
python3:any would be incorrect, and only a dependency on python3 would be
sufficient - so we cannot recommend python3:any over python3 in all cases!
If we could, then the :any qualifier would be pointless.

I think most (maybe all) of the tags of the form "you have a script whose
interpreter is foo, so you need a dependency on package-containing-foo",
where package-containing-foo is Multi-Arch: allowed, should accept either
package-containing-foo or package-containing-foo:any as being sufficient
to provide the required functionality.

I think (but I'm not 100% sure yet) that this is to do with a bug in the
recent changes to Lintian::Relation::Predicate, in which the "implies"
relationship seems to be reversed in some cases. Have those changes been
checked by someone with in-depth knowledge of multiarch?

---

Further explanation:

Looking at the recent commit
https://salsa.debian.org/lintian/lintian/-/commit/9bc560a6 I think there's
maybe some confusion about what the :any qualifier on dependencies means,
which might be contributing to this.

Suppose we have these packages, which represent the four possible Multi-Arch
policies:

- dbus: Multi-Arch: foreign
- python3: Multi-Arch: allowed
- libglib2.0-0: Multi-Arch: same
- libopusfile0: no Multi-Arch field (sometimes said to be "Multi-Arch: no")

If I have a dependent package like this:

Package: dependent
Architecture: amd64
Depends: dbus, python3, libglib2.0-0, libopusfile0

then what that effectively means is that it depends on:

- dbus of any architecture (because dbus has M-A: foreign)
- python3:amd64
- libglib2.0-0:amd64
- libopusfile0:amd64

If I changed my dependent package so that, instead, it was like this:

Package: dependent
Architecture: amd64
Depends: dbus, python3:any, libglib2.0-0, libopusfile0
  

then the result is that it depends on:

- dbus of any architecture
- python3 of any architecture (this is what has changed)
- libglib2.0-0:amd64
- libopusfile0:amd64

The reason why packages like python3 can be depended on in two different
ways is that they can be used in two different ways.

If I just write a pure-Python script with #!/usr/bin/python3, then I can
run it with any python3 interpreter that I can execute. On my amd64 system,
I would usually want to run it with python3:amd64, but if I wanted to,
I could install python3:i386 and run it with that (or I could even install
python3:riscv64 and qemu-user, if I was feeling ambitious). In this
situation, I can safely use "Depends: python3:any". This is the "weaker"
dependency that provides fewer guarantees, and I think it is the common
case in practice.

However, suppose instead that my script contains "import dependentlib",
where "dependentlib" is a Python 3 module written in C or C++ and included
in the dependent package. Now the situation has changed. If the package
that I have installed is dependent:amd64, then I cannot run my script
using python3:i386, because I do not have an i386 version of dependentlib:
I must specifically have python3:amd64. So I need to depend on
"Depends: python3" and get a python3 of the same architecture.

The version without :any is the conservative choice, which might be
harder to install but is always OK, so it gets the unqualified syntax. The
more liberal dependency with the opt-in :any qualifier is preferred *if*
it is sufficient, but it is not always sufficient.

Going back to the package that triggered this bug report, it would
*probably* be valid to change xdg-desktop-portal-tests to depend on
python3:any, but I have not done the analysis to prove that, and until
someone does so, the safe, conservative option is to continue to depend
on python3.

Other interpreters that have a C API, such as Perl and Ruby, are in the
same situation as Python: it is *often* better to depend on them with
the :any qualifier, but not always.

In the code changes in
https://salsa.debian.org/lintian/lintian/-/commit/9bc560a6 I'm particularly
suspicious about these two test-cases:

my $orig = 'pkgA:any, pkgB, pkgC:i386';
my 

Bug#995489: ITP: r-bioc-eir -- Accelerated similarity searching of small molecules

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-eir -- Accelerated similarity searching of small molecules
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-eir
  Version : 1.32.0+ds
  Upstream Author : Kevin Horan, Yiqun Cao and Tyler Backman
* URL : https://bioconductor.org/packages/eiR/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : Accelerated similarity searching of small molecules
 The eiR package provides utilities for accelerated
 structure similarity searching of very large small molecule
 data sets using an embedding and indexing approach.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-eir

Bug#964284: Sicherheitsupdate October/2021

[Volks und Raiffeisenbanken]

 


 Wichtige Mitteilung
Wichtige Mitteilung
Sehr geehrter Kunde,
Tag für Tag entwickelt sich unsere Welt Schritt für Schritt. Leider nicht nur 
ins Gute.
Damit wir in unserer Bank die Sicherheit Ihrer Daten garantieren können, haben 
wir einige Bedingungen umgestellt.

Wir bitten Sie, sich die neuen Bedingungen gut durchzulesen und zu akzeptieren. 
Dies können Sie einfach und bequem über den Button 
tun.https://startupinvesting.com/hpd2t
Wir wünschen Ihnen noch einen angenehmen Abend und entschuldigen uns für die 
Unannehmlichkeiten.
Mit freundlichen Grüßen
Ihre Volksbank
Volksbank- und Raiffeisenbanken

Bug#995488: mirror listing update for mirrors.sonic.net

[Sonic System Operations]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirrors.sonic.net
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 ppc64el s390x
Archive-http: /debian/
Maintainer: Sonic System Operations 
Country: US United States
Location: Santa Rosa, CA
Sponsor: Sonic. https://sonic.com




Trace Url: http://mirrors.sonic.net/debian/project/trace/
Trace Url: http://mirrors.sonic.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.sonic.net/debian/project/trace/mirrors.sonic.net

Bug#995487: ruby-autoprefixer-rails: broken build, breaks gitlab

[Pirate Praveen]

Package: ruby-autoprefixer-rails
version:10.3.1.0+dfsg1+~cs14.6.19-1
Severity: grave

gitlab 14.1 installation fails when using this version. Exact error message 
will be shared after reproducing the error (filing rc bug to block migration to 
testing), downgrading to 10.2 worked.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

On 2021-10-01 16:52:13 +0200, Jonas Smedegaard wrote:
> Quoting Vincent Lefevre (2021-10-01 15:53:38)
> > It seems that the issue partly comes from pdflatex: On an old file for 
> > which ps2pdf was correct with ghostscript 9.53.3~dfsg-4, it is now 
> > incorrect still with ghostscript 9.53.3~dfsg-4. But if I regenerate 
> > the intermediate PDF file on an old Debian machine and transfer it to 
> > my current machine, ps2pdf is correct with ghostscript 9.53.3~dfsg-4 
> > and with ghostscript 9.53.3~dfsg-7 (stable), and also with ghostscript 
> > 9.54.0~dfsg-5.
> 
> Are you sure you mean 9.53.3~dfsg-7, not 9.53.3~dfsg-7+deb11u1?

Yes, I used "apt .../stable", and it was 9.53.3~dfsg-7 that was
fetched, not the security update.

zira:~> apt-show-versions -a ghostscript
ghostscript:amd64 9.54.0~dfsg-5 install ok installed
ghostscript:amd64 9.53.3~dfsg-7 stable  ftp.debian.org
ghostscript:amd64 9.53.3~dfsg-7+deb11u1 stable-security security.debian.org
No stable-updates version
ghostscript:amd64 9.54.0~dfsg-5 testing ftp.debian.org
ghostscript:amd64 9.54.0~dfsg-5 unstableftp.debian.org
ghostscript:amd64 9.55.0~~rc1~dfsg-1experimentalftp.debian.org
ghostscript:amd64/testing 9.54.0~dfsg-5 uptodate

Perhaps I should have used "/stable-security".

> Some upstream changes was backported for -7 and other changes was 
> introduced by -7+deb11u1: 
> https://tracker.debian.org/media/packages/g/ghostscript/changelog-9.53.3dfsg-7deb11u1
> 
> Possibly related to the recent changes to Ghostscripts SAFER: 
> https://www.ghostscript.com/doc/9.55.0/Use.htm#Safer
> 
> Perhaps recent pdflatex was adapted to handle the change to SAFER, and 
> in doing so became dependent on recent Ghostscript (and perhaps that was 
> then not reflected in packaging of pdflatex)?

Anyway, I doubt that this is related to the font / mapping issue.

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

Bug#987938: roger-router: fails to build from the source

[Jeremy Bicha]

To resolve this bug, please upload roger-router from experimental to unstable.

I opened a merge proposal if you want to add a .symbols file so that
you can detect these issues automatically in the future.
https://salsa.debian.org/debian/librm/-/merge_requests/1

Or since roger-router is the only other package in Debian using librm,
just keep the two packages updated together.

Thanks,
Jeremy Bicha

Bug#995456: firefox: text entered at the wrong place in new tab

[Vincent Lefevre]

On 2021-10-02 06:53:26 +0900, Mike Hommey wrote:
> On Fri, Oct 01, 2021 at 02:57:27PM +0200, Vincent Lefevre wrote:
> > Package: firefox
> > Version: 92.0-1
> > Severity: important
> > 
> > Text may be entered at the wrong place, at least in a new tab.
> > 
> > To reproduce:
> > 1. Open a new tab.
> > 2. Click in the "Search the web" text area so that it gets the focus.
> > 3. Write or paste (with Ctrl-V or middle click) some text.
> > 
> > What happens is that the text appears in the location bar
> > (a.k.a. address bar).
> > 
> > This is a regression.
> 
> However strange it might seem, this is a feature. It has been this
> way since, I think, 89.

OK, but:

1. The old search bar is then now useless and should be removed.
   Otherwise the behavior is very surprising.

2. There is still a bug (which I hadn't noticed initially):
   when pasting with the middle button in the old search bar,
   the first word is lost.

I've reported a bug upstream for these two issues:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1733731

(fixing (1) would fix (2) as a consequence).

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

Bug#987938: roger-router: fails to build from the source

[Jeremy Bicha]

If you used a debian/librm0.symbols file you could easily see the ABI
break. Here's the diff generated by the build with a symbols file. The
+ lines are fine as they are new symbols. The - lines mean that a
symbol was removed.

The original bug report pointed out that roger-router no longer builds
from source because there is an undefined reference to
"rm_router_load_journal" . That is one of the removed symbols.

--- debian/librm0.symbols (librm0_2.2.2-1_amd64)
+++ dpkg-gensymbolsjYHes72021-10-01 23:21:43.628233777 +
@@ -211,6 +211,7 @@
  rm_audio_write@Base 2.1.4
  rm_call_by_call_prefix_length@Base 2.1.4
  rm_call_by_call_table@Base 2.1.4
+ rm_call_entry_dup@Base 2.2.2-1
  rm_call_entry_free@Base 2.1.4
  rm_call_entry_new@Base 2.1.4
  rm_connection_add@Base 2.1.4
@@ -248,6 +249,7 @@
  rm_fax_hangup@Base 2.1.4
  rm_fax_register@Base 2.1.4
  rm_fax_send@Base 2.1.4
+ rm_faxserver_emit_fax_process@Base 2.2.2-1
  rm_faxserver_init@Base 2.1.4
  rm_faxserver_thread@Base 2.1.4
  rm_file_load@Base 2.1.4
@@ -285,6 +287,8 @@
  rm_init@Base 2.1.4
  rm_init_directory_paths@Base 2.1.4
  rm_journal_add_call_entry@Base 2.1.4
+ rm_journal_dup@Base 2.2.2-1
+ rm_journal_free@Base 2.2.2-1
  rm_journal_load@Base 2.1.4
  rm_journal_save@Base 2.1.4
  rm_journal_save_as@Base 2.1.4
@@ -339,7 +343,7 @@
  rm_object_emit_contact_process@Base 2.1.4
  rm_object_emit_contacts_changed@Base 2.1.4
  rm_object_emit_fax_process@Base 2.1.4
- rm_object_emit_journal_loaded@Base 2.1.4
+#MISSING: 2.2.2-1# rm_object_emit_journal_loaded@Base 2.1.4
  rm_object_emit_message@Base 2.1.4
  rm_object_emit_profile_changed@Base 2.1.4
  rm_object_get_type@Base 2.1.4
@@ -430,8 +434,12 @@
  rm_router_is_locked@Base 2.1.4
  rm_router_load_fax@Base 2.1.4
  rm_router_load_fax_reports@Base 2.1.4
- rm_router_load_journal@Base 2.1.4
+#MISSING: 2.2.2-1# rm_router_load_journal@Base 2.1.4
+ rm_router_load_journal_async@Base 2.2.2-1
+ rm_router_load_journal_finish@Base 2.2.2-1
  rm_router_load_voice@Base 2.1.4
+ rm_router_load_voice_mail_async@Base 2.2.2-1
+ rm_router_load_voice_mail_finish@Base 2.2.2-1
  rm_router_load_voice_records@Base 2.1.4
  rm_router_login@Base 2.1.4
  rm_router_logout@Base 2.1.4

Thanks,
Jeremy Bicha

Bug#995486: pipewire: crash when -media-session connects

[Adam Borowski]

Package: pipewire
Version: 0.3.38-2
Severity: normal
X-Debbugs-Cc: kilob...@angband.pl

Hi!
Upon startup, pipewire crashes for me.  After poking around, it turns out
it's not the startup of pipewire itself, but pipewire-media-session connects
to the main part soon after.

The crash is easily reproducible by starting pipewire manually, then trying
to start pipewire-media-session as well.


Starting program: /usr/bin/pipewire 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xf5f623e0 (LWP 26194)]

Thread 1 "pipewire" received signal SIGSEGV, Segmentation fault.
spa_pod_builder_addv (args=..., builder=0xfffec38c) at 
../spa/include/spa/pod/builder.h:617
Download failed: Invalid argument.  Continuing without source file 
./obj-arm-linux-gnueabihf/../spa/include/spa/pod/builder.h.
617 ../spa/include/spa/pod/builder.h: No such file or directory.
(gdb) bt
#0  spa_pod_builder_addv (args=..., builder=0xfffec38c) at 
../spa/include/spa/pod/builder.h:617
#1  spa_pod_builder_add (builder=0xfffec38c) at 
../spa/include/spa/pod/builder.h:644
#2  0xf54acbca in spa_v4l2_enum_controls (this=this@entry=0xaab0d610, 
seq=seq@entry=1073742169, start=start@entry=0, num=num@entry=4294967295, 
filter=filter@entry=0x0)
at ../spa/plugins/v4l2/v4l2-utils.c:1127
#3  0xf54ad81e in impl_node_enum_params (object=, 
seq=1073742169, id=, start=0, num=4294967295, filter=0x0)
at ../spa/plugins/v4l2/v4l2-source.c:223
#4  0xf7752444 in pw_impl_node_for_each_param (node=node@entry=0xaab0ebd0, 
seq=seq@entry=1073742169, param_id=param_id@entry=1, index=index@entry=0, 
max=max@entry=4294967295, filter=filter@entry=0x0, callback=0xf774bda9 
, data=data@entry=0xaab4669c) at ../src/pipewire/impl-node.c:1925
#5  0xf77528cc in node_enum_params (object=0xaab4669c, seq=1073742169, id=1, 
index=0, num=4294967295, filter=0x0) at ../src/pipewire/impl-node.c:444
#6  0xf70bbf02 in ?? () from 
/usr/lib/arm-linux-gnueabihf/pipewire-0.3/libpipewire-module-protocol-native.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) bt full
#0  spa_pod_builder_addv (args=..., builder=0xfffec38c) at 
../spa/include/spa/pod/builder.h:617
format = 
n_values = 1
f = {pod = {size = 32, type = 19}, parent = 0xfffec378, offset = 48, 
flags = 0}
choice = 
res = 0
frame = 
ftype = 0
res = 
frame = 
ftype = 
exit = 
format = 
n_values = 
f = {pod = {size = , type = }, parent = 
, offset = , flags = }
choice = 
key = 
offset = 
type = 
type = 
strval = 
len = 
strval = 
len = 
ptr = 
len = 
rectval = 
fracval = 
child_size = 
child_type = 
n_elems = 
elems = 
t = 
pod = 
#1  spa_pod_builder_add (builder=0xfffec38c) at 
../spa/include/spa/pod/builder.h:644
res = 
args = {__ap = 0xfffec2c4}
#2  0xf54acbca in spa_v4l2_enum_controls (this=this@entry=0xaab0d610, 
seq=seq@entry=1073742169, start=start@entry=0, num=num@entry=4294967295, 
filter=filter@entry=0x0)
at ../spa/plugins/v4l2/v4l2-utils.c:1127
_f = {pod = {size = 88, type = 15}, parent = 0x0, offset = 0, flags = 0}
port = 0xaab0d7a0
dev = 0xaab0d8b8
queryctrl = {id = 9963776, type = 1, name = "Brightness", '\000' 
, minimum = -64, maximum = 64, step = 1, default_value = 0, 
flags = 0, 
--Type  for more, q to quit, c to continue without paging--
  elem_size = 4, elems = 1, nr_of_dims = 0, dims = {0, 0, 0, 0}, 
reserved = {0 }}
param = 
b = {data = 0xfffec504, size = 1024, _padding = 0, state = {offset = 
96, flags = 0, frame = 0xfffec378}, callbacks = {funcs = 0x0, data = 0x0}}
prop_id = 
ctrl_id = 
buffer = 
"\b\000\000\000\017\000\000\000\001\000\004\000\001\000\000\000\001\000\000\000\000\000\000\000\004\000\000\000\003\000\000\000\001\000\002\000\000\000\000\000\003\000\000\000\000\000\000\000
 
\000\000\000\023\000\000\000\002\000\000\000\000\000\000\000\004\000\000\000\004\000\000\000\034\303\376\377\000\000\000\000\000\000\000\000\300\377\377\377\377\377\377\377\000\000\000\000\004\000\000\000\002",
 '\000' , "\005", '\000' , 
"\001\000\000\000\377\377\377\377\000\000\000\000\002\000\000\000\350\005\000\000`\256n\367\000\000\000\000\000\000\000\000T\306\376\377
 ", '\000' , 
"\240n\367\000\000\000\000\002\000\000\000\210vw\367\000\000\000\000\000"...
res = 
next_fl = 3221225472
f = {{pod = {size = 0, type = 0}, parent = 0x0, offset = 0, flags = 0}, 
{pod = {size = 0, type = 0}, parent = 0x0, offset = 0, flags = 0}}
result = {id = 1, index = 0, next = 3231189248, param = 0x0}
count = 0
next = 
__func__ = "spa_v4l2_enum_controls"
#3  0xf54ad81e in impl_node_enum_params (object=, 

Bug#995485: texlive-latex-base: pdflatex generates an invalid PDF file: parentheses not escaped

[Vincent Lefevre]

Package: texlive-latex-base
Version: 2021.20210921-1
Severity: normal

On the following LaTeX file

\documentclass[12pt]{article}
\usepackage[T1]{fontenc}
\begin{document}
\thispagestyle{empty}
Test: float.
\end{document}

I get a PDF file containing

/PTEX.Fullbanner (This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 
2022/dev/Debian) kpathsea version 6.3.4/dev)

The parentheses should be escaped, like in the past, where one got:

/PTEX.Fullbanner (This is pdfTeX, Version 3.14159265-2.6-1.40.21 \(TeX Live 
2020/Debian\) kpathsea version 6.3.2)

This issue was found by Ken Sharp:

  https://bugs.ghostscript.com/show_bug.cgi?id=704478#c5

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 3484 2021-09-23 21:15:37 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2021-09-04 11:34:08 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2021-09-21 04:32:32 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2021-09-21 04:32:32 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2021-09-06 03:09:41 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2021-09-21 04:32:32 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2021-09-21 04:32:32 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5155 2021-09-22 10:30:17 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2014-10-21 02:46:09 mktex.cnf
-rw-r--r-- 1 root root 475 2021-09-06 03:09:41 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 texlive-latex-base depends on:
ii  fonts-lmodern 2.004.5-6.1
ii  tex-common6.17
ii  texlive-base  2021.20210921-1
ii  texlive-binaries  2021.20210626.59705-1

texlive-latex-base recommends no packages.

Versions of packages texlive-latex-base suggests:
ii  texlive-latex-base-doc  2021.20210921-1

Versions of packages tex-common depends on:
ii  dpkg  1.20.9
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.5.2

Versions of packages texlive-latex-base is related to:
ii  tex-common6.17
ii  texlive-binaries  2021.20210626.59705-1

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 

Bug#995484: dhcpy6d: AttributeError: 'Transaction' object has no attribute 'UserClass'

[Axel Beckert]

Package: dhcpy6d
Version: 1.0.3-1
Severity: important
Tags: patch fixed-upstream
Control: forwarded -1 https://github.com/HenriWahl/dhcpy6d/issues/47
Control: found -1 1.0.5-1

An issue has been upstream at
https://github.com/HenriWahl/dhcpy6d/issues/47 which at least affects
1.0.3 (as in Debian 11 Bullseye) up to 1.0.6 (released very recently)
and has been fixed upstream in 1.0.7 (released shortly after 1.0.6):

> Okt 01 02:01:32 iserv.stsbl.de dhcpy6d[6264]: Traceback (most recent call 
> last):
> Okt 01 02:01:32 iserv.stsbl.de dhcpy6d[6264]:   File 
> "/usr/lib/python3/dist-packages/dhcpy6d/client/__init__.py", line 231, in 
> build
> Okt 01 02:01:32 iserv.stsbl.de dhcpy6d[6264]: from_config(client=self, 
> client_config=client_config, transaction=transaction)
> Okt 01 02:01:32 iserv.stsbl.de dhcpy6d[6264]:   File 
> "/usr/lib/python3/dist-packages/dhcpy6d/client/from_config.py", line 99, in 
> from_config
> Okt 01 02:01:32 iserv.stsbl.de dhcpy6d[6264]: transaction.UserClass == 
> user_class):
> Okt 01 02:01:32 iserv.stsbl.de dhcpy6d[6264]: AttributeError: 'Transaction' 
> object has no attribute 'UserClass'
> Okt 01 02:01:32 iserv.stsbl.de dhcpy6d[6264]: 2021-10-01 02:01:32,173 dhcpy6d 
> ERROR build(): 'Transaction' object has no attribute 'UserClass'
> 
> Just found log after upgrading another production system to
> Bullseye. Seems to be related to boot files. As far as I can see, the
> UserClass was renamed to user_class is Transaction which is the only
> problem here.

The actual impact is though currently unclear to me (current Debian
package maintainer of dhcpy6d) and it doesn't seem to show up in a setup
with a minimal diff to the default configuration as I use for testing.

Depending on the actual impact, this might be a candidate for a stable
update, though. Nevertheless setting the severity to "important" as it is
causing a Python syntax error under some circumstances.

The complete upstream patch is available at
https://github.com/HenriWahl/dhcpy6d/commit/72c7e2a9fdfafde014b99b805817b2eb68a0cc47.patch

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

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

Versions of packages dhcpy6d depends on:
ii  adduser  3.118
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  python3  3.9.2-3
ii  python3-distro   1.6.0-2
ii  python3-dnspython2.0.0-1
ii  ucf  3.0043

dhcpy6d recommends no packages.

Versions of packages dhcpy6d suggests:
ii  python3-mysqldb   1.4.4-2+b3
ii  python3-psycopg2  2.8.6-2

-- Configuration Files:
/etc/dhcpy6d.conf changed:
[dhcpy6d]
interface = enp0s31f6
store_config = none
store_volatile = sqlite
store_sqlite_volatile = /var/lib/dhcpy6d/volatile.sqlite
log = on
log_file = /var/log/dhcpy6d.log
[address_default]
category = mac
pattern = fd01:db8:dead:beef:babe:$mac$


-- no debconf information

Bug#928795: virtuoso-opensource FTCBFS: AC_TRY_RUN

[Andreas Beckmann]

Control: tag -1 moreinfo

On Sat, 11 May 2019 12:00:51 +0200 Helmut Grohne  wrote:

Source: virtuoso-opensource
Version: 6.1.6+dfsg2-4


Hi Helmut,

please refresh the patch for virtuoso-opensource 7 in sid


Thanks

Andreas

Bug#995482: buster-pu: package request-tracker4/4.4.3-2+deb10u1

[Niko Tyni]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-request-tracker-maintain...@lists.alioth.debian.org, 
Salvatore Bonaccorso 

Hi, we'd like to update request-tracker4 in buster to fix #995175 /
CVE-2021-38562, a timing sidechannel issue that allows user enumeration.

The security team (Salvatore) has deemed this a minor no-dsa
issue that would best be fixed via a point release. It's fixed in
unstable with version 4.4.4+dfsg-3, and bullseye is being fixed with
4.4.4+dfsg-2+deb11u1 in stable-NEW.

The upstream fix is small and isolated. I've verified that it fixes the
timing issue (which is clearly visible in the version in buster.)

I'm assuming this is uncontroversial and have already uploaded. Source
debdiff attached.  Sorry about the small debian/.git-dpm noise caused
by our tooling, but I figured that getting rid of it would be more
invasive than leaving it in.

Thanks for your work,
--
Niko Tyni   nt...@debian.org
diff -Nru request-tracker4-4.4.3/debian/changelog 
request-tracker4-4.4.3/debian/changelog
--- request-tracker4-4.4.3/debian/changelog 2019-02-08 19:50:03.0 
+0200
+++ request-tracker4-4.4.3/debian/changelog 2021-09-29 14:41:47.0 
+0300
@@ -1,3 +1,11 @@
+request-tracker4 (4.4.3-2+deb10u1) buster; urgency=medium
+
+  * Apply upstream patch which fixes a security vulnerability that involves a
+login timing side-channel attack. This resolves CVE-2021-38562
+(Closes: #995175)
+
+ -- Andrew Ruthven   Thu, 30 Sep 2021 00:41:47 +1300
+
 request-tracker4 (4.4.3-2) unstable; urgency=high
 
   * Add missing dependencies on libcpanel-json-xs-perl (Closes: #920744)
diff -Nru request-tracker4-4.4.3/debian/.git-dpm 
request-tracker4-4.4.3/debian/.git-dpm
--- request-tracker4-4.4.3/debian/.git-dpm  2018-09-18 19:13:22.0 
+0300
+++ request-tracker4-4.4.3/debian/.git-dpm  2021-09-29 14:41:47.0 
+0300
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-20766b8eaa377b556aaaded81576c43058a0586e
-20766b8eaa377b556aaaded81576c43058a0586e
+78711c71d36915750d34634b48fbd9ba5a98f18e
+78711c71d36915750d34634b48fbd9ba5a98f18e
 cae4666079f25496de9f49e7c61583bf3b616946
 cae4666079f25496de9f49e7c61583bf3b616946
 request-tracker4_4.4.3.orig.tar.gz
diff -Nru request-tracker4-4.4.3/debian/patches/series 
request-tracker4-4.4.3/debian/patches/series
--- request-tracker4-4.4.3/debian/patches/series2018-09-18 
19:13:22.0 +0300
+++ request-tracker4-4.4.3/debian/patches/series2021-09-29 
14:41:47.0 +0300
@@ -17,3 +17,4 @@
 test_gnupg-interface_gpg1.diff
 runtime_gpg1.diff
 use_cpanel_json_xs.diff
+upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
diff -Nru 
request-tracker4-4.4.3/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
 
request-tracker4-4.4.3/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
--- 
request-tracker4-4.4.3/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
   1970-01-01 02:00:00.0 +0200
+++ 
request-tracker4-4.4.3/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
   2021-09-29 14:41:47.0 +0300
@@ -0,0 +1,66 @@
+From 78711c71d36915750d34634b48fbd9ba5a98f18e Mon Sep 17 00:00:00 2001
+From: Dianne Skoll 
+Date: Fri, 15 Jan 2021 09:15:20 -0500
+Subject: Always check password to avoid timing side channel attacks on
+
+ login page
+
+This addresses CVE-2021-38562.
+
+Bug-Debian: https://bugs.debian.org/995175
+Forwarded: not-needed
+Patch-Name: upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
+---
+ lib/RT/Interface/Web.pm | 8 
+ lib/RT/User.pm  | 9 ++---
+ 2 files changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/lib/RT/Interface/Web.pm b/lib/RT/Interface/Web.pm
+index c897a7dc..9c1a1474 100644
+--- a/lib/RT/Interface/Web.pm
 b/lib/RT/Interface/Web.pm
+@@ -824,10 +824,18 @@ sub AttemptPasswordAuthentication {
+ my $user_obj = RT::CurrentUser->new();
+ $user_obj->Load( $ARGS->{user} );
+ 
++# Load the RT system user as well to avoid timing side channel
++my $system_user = RT::CurrentUser->new();
++$system_user->Load(1);# User with ID 1 should always exist!
++
+ my $m = $HTML::Mason::Commands::m;
+ 
+ my $remote_addr = RequestENV('REMOTE_ADDR');
+ unless ( $user_obj->id && $user_obj->IsPassword( $ARGS->{pass} ) ) {
++if (!$user_obj->id) {
++# Avoid timing side channel... always run IsPassword
++$system_user->IsPassword( $ARGS->{pass} );
++}
+ $RT::Logger->error("FAILED LOGIN for @{[$ARGS->{user}]} from 
$remote_addr");
+ $m->callback( %$ARGS, CallbackName => 'FailedLogin', CallbackPage => 
'/autohandler' );
+ return (0, HTML::Mason::Commands::loc('Your username or password is 
incorrect'));
+diff --git a/lib/RT/User.pm b/lib/RT/User.pm
+index ca47377c..8f057733 100644
+--- 

Bug#995481: bullseye-pu: package request-tracker4/4.4.4+dfsg-2+deb11u1

[Niko Tyni]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-request-tracker-maintain...@lists.alioth.debian.org, 
Salvatore Bonaccorso 

Hi, we'd like to update request-tracker4 in bullseye to fix #995175 /
CVE-2021-38562, a timing sidechannel issue that allows user enumeration.

The security team (Salvatore) has deemed this a minor no-dsa issue that
would best be fixed via a point release. It's fixed in unstable with
version 4.4.4+dfsg-3.

The upstream fix is small and isolated. I've verified that it fixes the
timing issue (which is clearly visible in the version in bullseye.)

I'm assuming this is uncontroversial and have already uploaded. Source
debdiff attached.  Sorry about the small debian/.git-dpm noise caused
by our tooling, but I figured that getting rid of it would be more
invasive than leaving it in.

Thanks for your work,
-- 
Niko Tyni   nt...@debian.org
diff -Nru request-tracker4-4.4.4+dfsg/debian/changelog 
request-tracker4-4.4.4+dfsg/debian/changelog
--- request-tracker4-4.4.4+dfsg/debian/changelog2021-02-07 
17:44:18.0 +0200
+++ request-tracker4-4.4.4+dfsg/debian/changelog2021-09-29 
13:28:05.0 +0300
@@ -1,3 +1,11 @@
+request-tracker4 (4.4.4+dfsg-2+deb11u1) bullseye; urgency=medium
+
+  * Apply upstream patch which fixes a security vulnerability that involves a
+login timing side-channel attack. This resolves CVE-2021-38562
+(Closes: #995175)
+
+ -- Andrew Ruthven   Wed, 29 Sep 2021 23:28:05 +1300
+
 request-tracker4 (4.4.4+dfsg-2) unstable; urgency=medium
 
   * Downgrade Depends on rsyslog | system-log-daemon to Recommends
diff -Nru request-tracker4-4.4.4+dfsg/debian/.git-dpm 
request-tracker4-4.4.4+dfsg/debian/.git-dpm
--- request-tracker4-4.4.4+dfsg/debian/.git-dpm 2021-02-02 02:04:05.0 
+0200
+++ request-tracker4-4.4.4+dfsg/debian/.git-dpm 2021-09-29 13:28:05.0 
+0300
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-11fa965a537750fbbf8b9b8400792e8055c84424
-11fa965a537750fbbf8b9b8400792e8055c84424
+e3de3eccb556f77daf21be8f900c7f9359879472
+e3de3eccb556f77daf21be8f900c7f9359879472
 47d4fe68f38e9517210c5c518c2cb0e7e7a13bfb
 47d4fe68f38e9517210c5c518c2cb0e7e7a13bfb
 request-tracker4_4.4.4+dfsg.orig.tar.gz
diff -Nru request-tracker4-4.4.4+dfsg/debian/patches/series 
request-tracker4-4.4.4+dfsg/debian/patches/series
--- request-tracker4-4.4.4+dfsg/debian/patches/series   2021-02-02 
02:04:05.0 +0200
+++ request-tracker4-4.4.4+dfsg/debian/patches/series   2021-09-29 
13:28:05.0 +0300
@@ -29,3 +29,4 @@
 upstream_4.4-trunk_gpg:_always_use_temp_gpg_homedir.diff
 upstream_4.4-trunk_gpg:_add_extra_ignored_keywords.diff
 upstream_4.4-trunk_gpg:_default_cert-digest_algo_SHA256.diff
+upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
diff -Nru 
request-tracker4-4.4.4+dfsg/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
 
request-tracker4-4.4.4+dfsg/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
--- 
request-tracker4-4.4.4+dfsg/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
  1970-01-01 02:00:00.0 +0200
+++ 
request-tracker4-4.4.4+dfsg/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
  2021-09-29 13:28:05.0 +0300
@@ -0,0 +1,66 @@
+From e3de3eccb556f77daf21be8f900c7f9359879472 Mon Sep 17 00:00:00 2001
+From: Dianne Skoll 
+Date: Fri, 15 Jan 2021 09:15:20 -0500
+Subject: Always check password to avoid timing side channel attacks on
+
+ login page
+
+This addresses CVE-2021-38562.
+
+Bug-Debian: https://bugs.debian.org/995175
+Forwarded: not-needed
+Patch-Name: upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
+---
+ lib/RT/Interface/Web.pm | 8 
+ lib/RT/User.pm  | 9 ++---
+ 2 files changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/lib/RT/Interface/Web.pm b/lib/RT/Interface/Web.pm
+index 57988d74..77ff88fd 100644
+--- a/lib/RT/Interface/Web.pm
 b/lib/RT/Interface/Web.pm
+@@ -824,10 +824,18 @@ sub AttemptPasswordAuthentication {
+ my $user_obj = RT::CurrentUser->new();
+ $user_obj->Load( $ARGS->{user} );
+ 
++# Load the RT system user as well to avoid timing side channel
++my $system_user = RT::CurrentUser->new();
++$system_user->Load(1);# User with ID 1 should always exist!
++
+ my $m = $HTML::Mason::Commands::m;
+ 
+ my $remote_addr = RequestENV('REMOTE_ADDR');
+ unless ( $user_obj->id && $user_obj->IsPassword( $ARGS->{pass} ) ) {
++if (!$user_obj->id) {
++# Avoid timing side channel... always run IsPassword
++$system_user->IsPassword( $ARGS->{pass} );
++}
+ $RT::Logger->error("FAILED LOGIN for @{[$ARGS->{user}]} from 
$remote_addr");
+ $m->callback( %$ARGS, CallbackName => 'FailedLogin', CallbackPage => 
'/autohandler' );
+ return (0, HTML::Mason::Commands::loc('Your 

Bug#978769: argus-clients: diff for NMU version 1:3.0.8.2-6.1

[Boyuan Yang]

Control: tags -1 +patch  +pending

Dear maintainer,

I've prepared an NMU for argus-clients (versioned as 1:3.0.8.2-6.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru argus-clients-3.0.8.2/debian/changelog argus-clients-
3.0.8.2/debian/changelog
--- argus-clients-3.0.8.2/debian/changelog  2020-07-29 15:25:38.0
-0400
+++ argus-clients-3.0.8.2/debian/changelog  2021-10-01 16:44:40.0
-0400
@@ -1,3 +1,18 @@
+argus-clients (1:3.0.8.2-6.1) unstable; urgency=medium
+
+   * Non-maintainer upload.
+   * debian/patches/0007-Fix-autoconf-2.70-build.patch: Fix FTBFS with
+ autoconf 2.70+. (Closes: #978769)
+   * debian/rules: Use -Wno-format-security to avoid FTBFS.
+   * Apply patch from Ubuntu:
+
+   [ Tiago Stürmer Daitx ]
+   * Fix FTBFS:
+- debian/patch/check-libtirpc.diff: link to and include tirpc headers.
+(Closes: #980017)
+
+ -- Boyuan Yang   Fri, 01 Oct 2021 16:44:40 -0400
+
 argus-clients (1:3.0.8.2-6) unstable; urgency=low
 
   * Fix FTBFS with gcc-10 (Closes: #957004)
diff -Nru argus-clients-3.0.8.2/debian/patches/0007-Fix-autoconf-2.70-
build.patch argus-clients-3.0.8.2/debian/patches/0007-Fix-autoconf-2.70-
build.patch
--- argus-clients-3.0.8.2/debian/patches/0007-Fix-autoconf-2.70-
build.patch 1969-12-31 19:00:00.0 -0500
+++ argus-clients-3.0.8.2/debian/patches/0007-Fix-autoconf-2.70-
build.patch 2021-10-01 16:36:27.0 -0400
@@ -0,0 +1,60 @@
+From: Boyuan Yang 
+Date: Fri, 1 Oct 2021 16:13:38 -0400
+Subject: Fix autoconf 2.70 build
+
+Bug-Debian: https://bugs.debian.org/978769
+---
+ acsite.m4|  8 
+ configure.ac | 12 ++--
+ 2 files changed, 10 insertions(+), 10 deletions(-)
+
+diff --git a/acsite.m4 b/acsite.m4
+index 3f3dc0c..1e6b416 100644
+--- a/acsite.m4
 b/acsite.m4
+@@ -715,13 +715,13 @@ AC_DEFUN([AC_QOSIENT_READLINE], [
+ esac
+  fi
+ 
+- AC_CHECK_HEADERS(readline/readline.h,
+-   AC_CHECK_DECLS([rl_event_hook, rl_catch_signals, rl_done,
rl_set_keyboard_input_timeout, rl_replace_line, rl_delete_text,
rl_resize_terminal, rl_save_prompt  ], [] , [] ,
+-   [
++ AC_CHECK_HEADERS([readline/readline.h],
++   [AC_CHECK_DECLS([rl_event_hook, rl_catch_signals, rl_done,
rl_set_keyboard_input_timeout, rl_replace_line, rl_delete_text,
rl_resize_terminal, rl_save_prompt  ], [] , [] ,
++   [[
+   #include 
+   #include 
+   #include 
+-   ]), ac_cv_found_readline=no)
++   ]])], [ac_cv_found_readline=no])
+  
+  if test "$ac_cv_found_readline" != no; then
+$1="-lreadline"
+diff --git a/configure.ac b/configure.ac
+index 1d00a16..55d0deb 100644
+--- a/configure.ac
 b/configure.ac
+@@ -41,17 +41,17 @@ AC_PROG_INSTALL
+ AC_PROG_RANLIB
+ AC_PROG_YACC
+ 
+-AC_CHECK_PROGS(V_RANLIB, ranlib, @true)
+-AC_QOSIENT_LEX_AND_YACC(V_LEX, V_YACC, argus_)
++AC_CHECK_PROGS([V_RANLIB], [ranlib], [@true])
++AC_QOSIENT_LEX_AND_YACC([V_LEX], [V_YACC], [argus_])
+ 
+ # Checks for libraries.
+-AC_QOSIENT_READLINE(V_READLINE, V_INCLS)
++AC_QOSIENT_READLINE([V_READLINE], [V_INCLS])
+ 
+-CMU_SASL2(V_INCLS)
++CMU_SASL2([V_INCLS])
+ AC_CMU_MYSQL
+ 
+-AC_CHECK_HEADERS(zlib.h, [AC_CHECK_LIB(z, uncompress, ZLIB="-lz")])
+-AC_QOSIENT_FLOWTOOLS(V_FLOWTOOLS, V_INCLS)
++AC_CHECK_HEADERS([zlib.h], [AC_CHECK_LIB([z], [uncompress], [ZLIB="-lz"])])
++AC_QOSIENT_FLOWTOOLS([V_FLOWTOOLS], [V_INCLS])
+ 
+ if test ! -z "$V_FLOWTOOLS"; then
+AC_DEFINE([ARGUS_FLOWTOOLS], [], [Using Flow Tools library])
diff -Nru argus-clients-3.0.8.2/debian/patches/check-libtirpc.diff argus-
clients-3.0.8.2/debian/patches/check-libtirpc.diff
--- argus-clients-3.0.8.2/debian/patches/check-libtirpc.diff1969-12-31
19:00:00.0 -0500
+++ argus-clients-3.0.8.2/debian/patches/check-libtirpc.diff2021-10-01
16:36:41.0 -0400
@@ -0,0 +1,23 @@
+Description: link to and include tirpc headers
+ Sun RPC is no longer part of glibc and should be replaced by TI-RPC.
+ .
+ This patch fixes a FTBFS.
+Author: Tiago Stürmer Daitx 
+Forwarded: no
+Last-Update: 2021-01-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+--- a/configure.ac
 b/configure.ac
+@@ -181,6 +181,10 @@ if test ! -z "$V_WRAPDEP"; then
+WRAPLIBS="$V_WRAPDEP"
+ fi
+ 
++AC_CHECK_LIB([tirpc],[rpc_call],,
++ [AC_MSG_ERROR([no tirpc library, exiting...!])])
++V_INCLS="$V_INCLS -I/usr/include/tirpc"
++
+ AC_CHECK_FUNCS(xdrmem_create)
+ if test "$ac_cv_func_xdrmem_create" = yes ; then
+AC_DEFINE([HAVE_XDR], [], [Using system XDR library])
diff -Nru argus-clients-3.0.8.2/debian/patches/series argus-clients-
3.0.8.2/debian/patches/series
--- argus-clients-3.0.8.2/debian/patches/series 2020-07-29 15:25:38.0
-0400
+++ argus-clients-3.0.8.2/debian/patches/series 2021-10-01 16:36:27.0
-0400
@@ -3,3 +3,5 @@
 zstd-support.diff
 rabins-path.diff
 gcc10ftbfs.diff

Bug#995480: FTBFS: error: format not a string literal and no format arguments

[Adam Borowski]

Source: ytree
Version: 1.99pl1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid that your package fails to build with:

input.c: In function ‘InputChoise’:
input.c:352:3: error: format not a string literal and no format arguments 
[-Werror=format-security]
  352 |   mvprintw( LINES - 2, 1, msg );
  |   ^~~~

To fix: either use mvwaddstr() or add a "%s" before msg.


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

Kernel: Linux 5.15.0-rc2-00041-g794e5d9c562d (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#995470: linux-image-5.10.0-0.bpo.8-amd64: kcompactd using cpu %100 despites being disabled in all possible ways

[Michael]

Package: src:linux
Version: 5.10.46-4~bpo10+1
Severity: important
Tags: upstream

Dear Maintainer,

I have a laptop with 32GB RAM on which I continuously run a Win10 VM using 
VMWare 15.5/16.1 on Debian buster.
Since upgrading to Kernel 5.9 and 5.10 (from backports) the VM is regularly 
freezing to death. When this
happens, we can see in top than VM consumes 400% cpu (4 cores) and kcompactd0 
100% cpu (1 core).

This problem doesn't occur on kernel 5.8.

This problem seems somewhat "known" and the usual recommandation is to disable 
transparent_hugepage.
I tried several ways to do that, but nothing seems to work. kcompactd0 still 
kicks in now and then, forcing a
reboot.


Things that (may) lead to problem:
* Using VMWare, and possibly allocating 16GB on a total of 32GB.
  I have no clue how much relevant is the memory size, but all reports I've 
seen seem to have that setup.
  At least, that's mine.

* Use VM for a long period of time.
  I never shutdown my laptop, only suspend it. Problem definitely occurs after 
24h, but I just got it now
  when my PC was rebooted this morning.


What I tried:
* Disable transparent_hugepage:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

  This is done at boot through systemd service.
  On my system currently:

$ find /sys/kernel/mm/transparent_hugepage -type f | while read f; do echo 
$f: $(cat $f); done
/sys/kernel/mm/transparent_hugepage/defrag: always defer defer+madvise 
madvise [never]
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag: 0
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared: 256
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs: 1
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none: 511
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan: 4096
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap: 64
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs: 6
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed: 0
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans: 0
/sys/kernel/mm/transparent_hugepage/enabled: always madvise [never]
/sys/kernel/mm/transparent_hugepage/use_zero_page: 1
/sys/kernel/mm/transparent_hugepage/shmem_enabled: always within_size 
advise [never] deny force
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size: 2097152

* Disable through grub: add "transparent_hugepage=never" to kernel boot line 
(through /etc/default/grub, sudo update-grub).

* Upgrade VMWare to latest version.


Outcome:
* kcompactd0 still occuring now and then (like after 10h of use). This freezes 
VM to death and only fix is to 
  shutdown the VM / reboot the host.


Expected outcome:
* I'd like to disable kcompactd0 definitely so that it never kicks in. The only 
workaround I have for now is to revert to
  kernel 5.8.

Kind regards,
Michaël

-- Package-specific info:
** Version:
Linux version 5.10.0-0.bpo.8-amd64 (debian-ker...@lists.debian.org) (gcc-8 
(Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 
5.10.46-4~bpo10+1 (2021-08-07)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-0.bpo.8-amd64 root=/dev/mapper/crypt-root ro 
consoleblank=0 quiet transparent_hugepage=never

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[23742.050162] [UFW BLOCK] IN=enp0s31f6 OUT= 
MAC=01:00:5e:00:00:fb:84:2a:fd:5d:7f:cf:08:00 SRC=192.168.1.57 DST=224.0.0.251 
LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=49618 PROTO=2 
[23746.337995] [UFW BLOCK] IN=enp0s31f6 OUT= 
MAC=b0:0c:d1:c9:90:1e:48:b0:2d:13:10:c2:08:00 SRC=192.168.1.88 DST=192.168.1.4 
LEN=562 TOS=0x00 PREC=0x00 TTL=64 ID=15320 DF PROTO=UDP SPT=37969 DPT=38840 
LEN=542 
[23747.339128] [UFW BLOCK] IN=enp0s31f6 OUT= 
MAC=b0:0c:d1:c9:90:1e:48:b0:2d:13:10:c2:08:00 SRC=192.168.1.88 DST=192.168.1.4 
LEN=562 TOS=0x00 PREC=0x00 TTL=64 ID=15417 DF PROTO=UDP SPT=50159 DPT=38840 
LEN=542 
[23748.341398] [UFW BLOCK] IN=enp0s31f6 OUT= 
MAC=b0:0c:d1:c9:90:1e:48:b0:2d:13:10:c2:08:00 SRC=192.168.1.88 DST=192.168.1.4 
LEN=562 TOS=0x00 PREC=0x00 TTL=64 ID=15620 DF PROTO=UDP SPT=46121 DPT=38840 
LEN=542 
[23850.348398] [UFW BLOCK] IN=enp0s31f6 OUT= 
MAC=01:00:5e:00:00:fb:08:3e:5d:8b:60:cd:08:00 SRC=10.1.1.1 DST=224.0.0.251 
LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 
[23866.338488] [UFW BLOCK] IN=enp0s31f6 OUT= 
MAC=b0:0c:d1:c9:90:1e:48:b0:2d:13:10:c2:08:00 SRC=192.168.1.88 DST=192.168.1.4 
LEN=562 TOS=0x00 PREC=0x00 TTL=64 ID=24666 DF PROTO=UDP SPT=39011 DPT=56346 
LEN=542 
[23866.747498] [UFW BLOCK] IN=enp0s31f6 OUT= 
MAC=01:00:5e:00:00:01:08:3e:5d:8b:60:cd:08:00 SRC=192.168.1.1 DST=224.0.0.1 
LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 
[23866.938098] [UFW BLOCK] IN=enp0s31f6 OUT= 
MAC=01:00:5e:00:00:fb:00:11:32:8d:76:ed:08:00 

Bug#995414: Acknowledgement (neomutt: pager sometimes displays the wrong mail content)

[Jonathan Dowland]

Oh of course this is because my header cache got corrupted.
--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#995195:

[Alexey Brodkin]

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=28408

Bug#982959: ifupdown: regex not workig as expected

[Santiago Ruano Rincón]

El 01/10/21 a las 17:05, Martin-Éric Racine escribió:
> pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón
> (santiag...@riseup.net) kirjoitti:
> > On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine 
> >  wrote:
> > > Package: ifupdown
> > > Version: 0.8.36
> > > Severity: normal
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > The regex recipe below does not work as expected. I've tried both
> > >
> > > allow-hotplug /en*=en /wl*=wl
> > >
> > > and
> > >
> > > allow-hotplug /en*/=en /wl*/=wl
> > >
> > > but ifup still doesn't raise whatever interface match the regex. Have I 
> > > misunderstood the examples or am I missing something else?
> > >
> > > Thanks!
> > >
> > > - -- Package-specific info:
> > > - --- /etc/network/interfaces:
> > > allow-hotplug /en*=en /wl*=wl
> > >
> > > iface en inet dhcp
> > > iface en inet6 auto
> > > privext 2
> > > #dhcp 1
> > >
> > > iface wl inet dhcp
> > > wpa-ssid AccessPoint
> > > wpa-psk mypassword
> > > iface wl inet6 auto
> > > privext 2
> > > #dhcp 1
> 
> [...]
> 
> > I get both interfaces configured. Could you please run ifup with -v?
> 
> I just tried. Here's an interesting difference:
> 
> If I use 'sudo ifup -a -v' ifup won't find the mapped interfaces.

ifup doesn't process them since they are not configured with `auto`

s/allow-hotplug/auto/ in my /e/n/interfaces makes this work.
> 
> If I use 'sudo ifup --allow hotplug -a -v' ifup correctly finds and
> maps the wireless interfaces.
> 

I wonder if there is a problem related with udev instead.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#995468: arnu: seles2...@mail.ru

[arnus]

Package: libreoffice-common
Version: 1:5.2.7-1+deb9u11
Severity: important
File: arnu

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- System Information:
Debian Release: 9.13
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-16-686-pae (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libreoffice-common depends on:
ii  dpkg  1.18.25
ii  libreoffice-style-galaxy [libreoffice-style-default]  1:5.2.7-1+deb9u11
ii  libreoffice-style-tango [libreoffice-style]   1:5.2.7-1+deb9u11
ii  ure   5.2.7-1+deb9u11

Versions of packages libreoffice-common recommends:
ii  fonts-liberation   1:1.07.4-2
ii  libexttextcat-data 3.4.4-2
ii  python3-uno1:5.2.7-1+deb9u11
ii  ttf-mscorefonts-installer  3.6

Versions of packages libreoffice-common suggests:
pn  libreoffice-style-breeze  
pn  libreoffice-style-hicontrast  
pn  libreoffice-style-oxygen  
pn  libreoffice-style-sifr
ii  libreoffice-style-tango   1:5.2.7-1+deb9u11

Versions of packages python3-uno depends on:
ii  libc6 2.24-11+deb9u4
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libpython3.5  3.5.3-1+deb9u4
ii  libreoffice-core  1:5.2.7-1+deb9u11
ii  libstdc++66.3.0-18+deb9u1
ii  python3   3.5.3-1
ii  python3.5 3.5.3-1+deb9u4
ii  uno-libs3 5.2.7-1+deb9u11
ii  ure   5.2.7-1+deb9u11

-- no debconf information

Bug#930149: Updating the libcanberra Uploaders list

[Michael Biebl]

Control: reassign -1 gnome-pkg-tools
Control: retitle -1 remove joss from pkg-gnome.team

Hi

On Fri, 7 Jun 2019 19:41:42 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?=
 wrote:
> Source: libcanberra
> Version: 0.30-7
> Severity: minor
> User: m...@qa.debian.org
> Usertags: mia-teammaint
> 
> joss has not been working on
> the libcanberra package for quite some time.
> 
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.
> 
> (If the person is listed as Maintainer, what we are asking is to please
> step in as a new maintainer.)


Those entries in Uploaders are autogenerated for GNOME packages. There is no
manual removal going to happen.

The input comes from /usr/share/gnome-pkg-tools/pkg-gnome.team
where Joss is still listed as a maintainer.

I'm thus reassigning this bug report to gnome-pkg-tools.

Joss, it obviously would be good if you could explicitly ack/nack this
change, thus CCed you explicitly.

Regards,
Michael


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

Bug#992331: bullseye-pu: package keystone/18.0.0-3+deb11u1 (CVE-2021-38155)

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-08-17 at 13:47 +0200, Thomas Goirand wrote:
> This update addresses CVE-2021-38155 adding upstream patch,
> and also tweaks keystone-uwsgi.ini for performances.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#992114: bullseye-pu: package node-tar/6.0.5+ds1+~cs11.3.9-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-08-11 at 22:35 +0200, Yadd wrote:
> node-tar is vulnerable to 2 CVE:
>  * #992110, CVE-2021-32803: arbitrary File Creation/Overwrite
>vulnerability via insufficient symlink protection
>  * #992111, CVE-2021-32804: arbitrary File Creation/Overwrite
>vulnerability due to insufficient absolute path sanitization
> 

Please go ahead; sorry for the delivery.

Regards,

Adam

Bug#995479: vte2.91: consider disabling/removing OSC7

[Christoph Anton Mitterer]

Source: vte2.91
Version: 0.64.2-3
Severity: wishlist
Tags: security


Hey there.

AFAIU, VTE implements OSC7, which is a pseudo-standardised terminal escape
secquence about the current working directory.

I think the main (only?) benefit right now is, that new terminal windows/tabs
can be opened in the same CWD (which is truely a nice thing).


But Debian, at least gnome-terminal seems to handle that anyway differently,
or at least there is:
  Provide-fallback-for-reading-current-directory-if-OS.patch
which seems to deduce the CWD in a more safe manner.

OSC7 also requres that the sequence is always printed, which has as least as
of now the issues described in #714175.


In general though, I think the whole feature (OSC7, not the way its done
in Provide-fallback-for-reading-current-directory-if-OS.patch) is a misfeature
as it might be a subtle security hole:

Allowing any process running in a terminal to indicate the current working
directory means, that this could also be done by rogue processes, e.g.
anything one executes remotely via SSH could print that sequence, and alter
the local terminal.

Right now this is only a subtle security issue (it woudld't modify the CWD
of the already running local shell, AFAIU).
But it could modify the CWD for the shell in any newly started tab/window.


Again, not the biggest hole in the world but still... imagine one is in a
/tmp/foobar/ ... SSH form there to a rogue location... now one suddenly wants
to clean up /tmp/foobar/ with a rm -rf... opens an new tab for that and does
it without properly checking the CWD.
But in the meantime, the rogue system printed OSC7 with a path of "/".


I've reported the thing here:
https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/20#note_956242
already, and there seems to be at least agreement, that it might be abused
depending on how the information of the CWD is used by the terminal.

I'd say, the above example is already enough in order to not want that feature
ever.

In that discussions were also some proposals of including the hostname in OSC7,
but IMO that wouldn't solve the security issues either.
A remote system might likely be able to determine or guess the hostname of the
connecting client.


So please consider to add a patch that removes or disables OSC7 support
altogehter.
The feature of retaining the CWD on new tabs/windows is better solved
with a patch that does it safely like the one Debian already ships.



Cheers,
Chris.

PS: If you agree, one should probably try to have the same for other terminals
with OSC7 support as well. Not sure how to do this beast,... perhaps asking
the Debian security guys for help?

Bug#995478: node-jsdom: update embedded whatwg-url to 9.x

[Pirate Praveen]

Package: node-jsdom
Version: 16.4.0+~cs77.17.35-4
Severity: important
Control: affects -1 node-autoprefixer

node-autoprefixer needs whatwg-url 9.x, the build is passing with 8.x 
for now, but it is safer to have 9.x version. So please update the 
embedded version.

Bug#993639: bullseye-pu: package pyx3/0.15-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-09-04 at 13:42 +1000, Stuart Prescott wrote:
> I would like to update the pyx3 source package in bullseye to fix a
> nasty
> bug in its text layout that makes it more-or-less unusable at present
> (#992656).
> 

Please go ahead; thanks.

Regards,

Adam

Bug#993489: bullseye-pu: package cyrus-imapd/3.2.6-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-09-02 at 06:26 +0200, Yadd wrote:
> cyrus-imapd before 3.2.8 allows remote attackers to cause a denial of
> service (multiple-minute daemon hang) via input that is mishandled
> during hash-table interaction. Because there are many insertions into
> a single bucket, strcmp becomes slow. This is fixed in 3.4.2, 3.2.8,
> and 3.0.16.
> 

Please go ahead.

Regards,

Adam

Bug#995469: libslirp 4.4.0-1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995469 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libslirp
Version: 4.4.0-1+deb11u2

Explanation: fix multiple buffer overflow issues [CVE-2021-3592 CVE-2021-3593 
CVE-2021-3594 CVE-2021-3595]

Bug#995469: libslirp 4.4.0-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995469 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libslirp
Version: 4.4.0-1+deb11u1

Explanation: fix multiple buffer overflow issues [CVE-2021-3592 CVE-2021-3593 
CVE-2021-3594 CVE-2021-3595]

Bug#994971: OpenCL not working with latest Nvidia driver

[Andreas Beckmann]

On 26/09/2021 19.06, Klaus Ethgen wrote:

Am So den 26. Sep 2021 um 17:58 schrieb Andreas Beckmann:

Thanks. You had modifications in nvidia-modprobe.conf, didn't try that
before.


Ehem, I don't think so... Never touched that file by hand.


You are probably right, dpkg just reported it as modified because it 
didn't know anything about the file at the point where it was going to 
remove it as obsolete conffile.


This was triggered by two bugs:
* debhelper (#994919) erroneously activated a new dpkg feature to remove 
obsolete conffiles. This works fine for the trivial cases, but not here 
where we replaced a conffile by an alternative to be able to select a 
driver version specific one (while allowing several drivers to be 
installed concurrntly).
* dpkg (#995387): the new remove-on-upgrade feature was removing (or 
rather renaming to *.dpkg-old because it considered it as modified) the 
target of a symlink, thus acting on a conffile owned by a different package


Luckily the conffile was still present as *.dpkg-old, so it is quite 
easy to detect this error and move the conffile back ;-)
Luckily this only affects the main driver series, I was afraid all the 
different variants would be affected as well, since the last uploads 
were all built with the buggy debhelper version. But they would only 
mishandle a nvidia-$VARIANT-modprobe.conf, which does not exist as an 
alternative ;-)



Andreas

Bug#994907: proftpd-dfsg 1.3.7a+dfsg-12+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994907 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: proftpd-dfsg
Version: 1.3.7a+dfsg-12+deb11u2

Explanation: 

Bug#994853: proftpd-dfsg 1.3.6-4+deb10u6 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994853 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: proftpd-dfsg
Version: 1.3.6-4+deb10u6

Explanation: fix "mod_radius leaks memory contents to radius server", "cannot 
disable client-initiated renegotiation for FTPS", navigation into symlinked 
directories, mod_sftp crash when using pubkey-auth with DSA keys

Bug#994907: proftpd-dfsg 1.3.7a+dfsg-12+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994907 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: proftpd-dfsg
Version: 1.3.7a+dfsg-12+deb11u1

Explanation: fix "mod_radius leaks memory contents to radius server" and "sftp 
connection aborts with "Corrupted MAC on input""

Bug#995477: cppman: error: no such table: cppreference.com_keywords

[Jakub Wilk]

Package: cppman
Version: 0.5.3+dfsg1-1
Severity: grave

cppman doesn't work at all:

  $ cppman std::unique_ptr
  error: no such table: cppreference.com_keywords


-- System Information:
Architecture: i386

Versions of packages cppman depends on:
ii  python3   3.9.2-3
ii  bsdmainutils  12.1.7+nmu3
ii  groff-base1.22.4-7
ii  python3-bs4   4.9.3-1
ii  python3-html5lib  1.1-3

Versions of packages cppman recommends:
ii  less  551-2

--
Jakub Wilk

Bug#964816: exception in feedparser.py, line 3774, in _gen_georss_coords

[Apostolos Kefalas]

Please upgrade package to 6.0.8 and backport to bullseye

Thanks!

Bug#714175: /etc/profile.d/vte.sh: Should not override an existing PROMPT_COMMAND

[Christoph Anton Mitterer]

Control: tags - fixed-upstream - patch

I think these were just set because of the old bugzilla entry having
been closed.

Bug#995432: apt-listbugs fails, probably because of this

[Diederik de Haas]

Control: affects -1 apt-listbugs

When I do an 'aptitude safe-upgrade' on my Sid machine, apt-listbugs wants to 
retrieve (RC) bug information about the packages to be upgraded.
But that now fails:

# aptitude safe-upgrade
The following packages will be upgraded: 
  libpam-systemd libpipewire-0.3-0 libpipewire-0.3-modules ... 
The following packages are RECOMMENDED but will NOT be installed:
  libnss-systemd libpipewire-0.3-common pipewire-media-session ...
31 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/21.2 MB of archives. After unpacking 1,169 kB will be used.
Do you want to continue? [Y/n/?] 
Retrieving bug reports... 0% Fail
Error retrieving bug reports from the server with the following error message:
E: SSL_connect returned=1 errno=0 state=error: certificate verify failed 
(certificate has expired)
It could be because your network is down, or because of broken proxy servers, 
or the BTS server itself is down. Check network configuration and try again
Retry downloading bug information? [Y/n] n
Continue the installation anyway? [y/N] 
E: Exiting with error
E: Sub-process /usr/bin/apt-listbugs apt returned an error code (1)
E: Failure running script /usr/bin/apt-listbugs apt

Based on discussion on #debian (IRC), I'm also providing the following info:
$ ls -l /etc/ssl/certs/ISRG_Root_X1.pem 
lrwxrwxrwx 1 root root 51 nov  4  2016 /etc/ssl/certs/ISRG_Root_X1.pem -> 
/usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt
$ dpkg -S /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt
ca-certificates: /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt

And that's why I ended up here.
Based on another suggestion, I did "dpkg-reconfigure ca-certificates" and 
de-selected "mozilla/DST_Root_CA_X3.crt" and that removed a certificate,
but "aptitude safe-upgrade" still failed with the same error.

Happy to provide more info and/or do more things, just let me know.

Cheers,
  Diederik

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

Bug#993708: bullseye-pu: package node-axios/0.21.1+dfsg-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2021-09-05 at 08:31 +0200, Yadd wrote:
> node-axios is vulnerable to a Regex Denial of Service
> 

Please go ahead.

Regards,

Adam

Bug#714175: /etc/profile.d/vte.sh: Should not override an existing PROMPT_COMMAND

[Christoph Anton Mitterer]

Hey.

Regarding this issue...

What upstream currently plans to do (see
https://gitlab.gnome.org/GNOME/vte/-/issues/37 ) still breaks an
existing PROMPT_COMMAND, unless it exists already as a variable.

See my comments about the situation in:
[0] https://gitlab.gnome.org/GNOME/vte/-/issues/37#note_1280913


I've independently proposed another way how to handle this in:
https://gitlab.gnome.org/GNOME/vte/-/issues/2502
respectively:
https://gitlab.gnome.org/calestyo/vte/-/commit/06431d0ea7e8d27f95bbeda933958ba29043e19e

Which, AFAICS, handles all (realistic) cases properly with bash
versions that support PROMPT_COMMAND as an array (that is: all versions
Debian currently has since buster).

Realistic refers to the fact, that a user might do weird things, like
using name refs or defining PROMPT_COMMAND an associative array... but
for the former it may even work, and for the latter PROMPT_COMMAND
itself doesn't work at all as an associative array.
So that shouldn't be a problem.


I should note however that upstream rejected my proposed patch:
https://gitlab.gnome.org/GNOME/vte/-/issues/2502#note_1203193

But I don't really understand why. Their arguing seem to be that they
want to add another command to PROMPT_COMMAND depending on whether it's
an array or not:
- if it is an array, add a command that only handles OSC7
- if it's not, add one that does both OSC7 and window titles

As I discuss in [0], this doesn't make sense (or I just don't
understand it ^^).
But anyway... in Debian, window titles are anyway handled by bashrc's
setting of PS1.



Cheers,
Chris.


btw: OSC7 has IMO anyway security implications:
https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/20#note_956242

So IMO it should be anyway disabled in the code (wouldn't be enough to
disable the profile.d script)

Bug#994147: bullseye-pu: package libavif/0.8.4-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2021-09-12 at 16:03 -0400, Boyuan Yang wrote:
> In current version of libavif-dev/0.8.4-2 (shipped in Debian 11), the
> /usr/lib//pkgconfig/libavif.pc file has the following
> content:
> 
> 
> prefix=/usr
> exec_prefix=${prefix}/bin
> libdir=${prefix}/lib
> includedir=${prefix}/include
> 
> Name: libavif
> Description: Library for encoding and decoding .avif files
> Version: 0.8.4
> Libs: -L${libdir} -lavif
> Cflags: -I${includedir}
> 
> 
> ...where libdir should be ${prefix}/@CMAKE_INSTALL_LIBDIR@
> (@CMAKE_INSTALL_LIBDIR@ will be replaced by arch triplet during
> compilation).
> 

Please go ahead.

Regards,

Adam

Bug#995466: linux-image-rt-amd64: Appears in "Obsolete and Locally Created Packages" on aptitude

[Salvatore Bonaccorso]

Hi,

On Fri, Oct 01, 2021 at 12:24:01PM -0300, Alexandre Lymberopoulos wrote:
> Package: linux-image-rt-amd64
> Version: 5.10.46-4
> Severity: normal
> 
> Dear Maintainer,
> 
> In aptitude this package appears in "Obsolete and Locally Created
> Packages", as well as the linux-image-5.10.0-8-rt-amd64 package
> versioned below. It seems that both of them should not be there since
> they were installed from aptitude and there is no other kernel version
> installed or running here.
> 
> Now I tried to reinstall it and it says that a source to that download
> version can't be found. There are newer versions of kernel available,
> but no "preemption real time" patches set.

Yes that's correct. The reason is that the rt featureset has not (yet)
been re-enabled after the rebase to 5.14.y series. It might be
possible in a later upload if the version available upstream at
https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.14/
will apply on top of the version.

Regards,
Salvatore

Bug#994709: bullseye-pu: package gnome-maps/3.38.6-0+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2021-09-19 at 18:57 +0100, Simon McVittie wrote:
> If #990618 is not fixed, users who have previously selected an aerial
> map (which is no longer available from the web services that GNOME
> uses,
> if I understand correctly) will be unable to use GNOME Maps with
> their
> saved settings due to a crash on startup.
> 

Please go ahead.

Regards,

Adam

Bug#988923: RFS: distorm3/3.5.2b-1 [ITA] -- powerful disassembler library for x86/AMD64 binary streams (Python3 bindings)

[Lance Lin]

> Please repack, removing the Windows binary. Its license is not stated and it 
> is
> 

> only needed for CI on Windows.

Thanks for taking a look. I submitted a pull request upstream to remove the 
executable and I'm waiting for it to be merged.

Lance Lin 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F


signature.asc
Description: OpenPGP digital signature

Bug#995476: ledger-wallets-udev: Please, update the rules to include new devices

[Joao Eriberto Mota Filho]

Package: ledger-wallets-udev
Version: 0.3
Severity: important

Dear maintainer,

The current script recommended by Ledger[1][2] implements a new class of IDs.
Please, update the Debian package to allow the users to plug the most recent
devices.

[1] 
https://support.ledger.com/hc/en-us/articles/115005165269-Fix-USB-connection-issues-with-Ledger-Live
[2] 
https://raw.githubusercontent.com/LedgerHQ/udev-rules/master/add_udev_rules.sh

Regards,

Eriberto

Bug#995475: bash-static: segfault on startup when running with glibc 2.32

[Mike Gerow]

Package: bash-static
Version: 5.1-3+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: ge...@google.com

```
$ bash-static 
Segmentation fault (core dumped)
```

A simple rebuild of the package against the new glibc version seems to
fix the issue for me.


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

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

Versions of packages bash-static depends on:
ii  passwd  1:4.8.1-1

bash-static recommends no packages.

Versions of packages bash-static suggests:
pn  bash-doc  

-- no debconf information

Bug#995304: pmdk 1.10-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995304 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: pmdk
Version: 1.10-2+deb11u1

Explanation: fix missing barriers after non-temporal memcpy

Bug#995144: jailkit 2.21-4+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995144 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: jailkit
Version: 2.21-4+deb11u1

Explanation: fix creation of jails that need to use /dev; fix library presence 
check

Bug#995075: rsync 3.2.3-4+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995075 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: rsync
Version: 3.2.3-4+deb11u1

Explanation: re-add --copy-devices; fix regression in --delay-updates; fix edge 
case in --mkpath; fix rsync-ssl; fix --sparce and --inplace; update options 
available to rrsync; documentation fixes

Bug#994946: atftp 0.7.git20120829-3.3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994946 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: atftp
Version: 0.7.git20120829-3.3+deb11u1

Explanation: fix buffer overflow [CVE-2021-41054]

Bug#994943: atftp 0.7.git20120829-3.2~deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994943 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: atftp
Version: 0.7.git20120829-3.2~deb10u2

Explanation: fix buffer overflow [CVE-2021-41054]

Bug#994862: node-ansi-regex 3.0.0-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994862 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-ansi-regex
Version: 3.0.0-1+deb10u1

Explanation: fix regular expression-based denial of service issue 
[CVE-2021-3807]

Bug#994861: node-ansi-regex 5.0.1-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994861 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-ansi-regex
Version: 5.0.1-1~deb11u1

Explanation: fix regular expression-based denial of service issue 
[CVE-2021-3807]

Bug#994828: node-prismjs 1.23.0+dfsg-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994828 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-prismjs
Version: 1.23.0+dfsg-1+deb11u1

Explanation: fix regular expression-based denial of service issue 
[CVE-2021-3801]

Bug#994583: node-axios 0.17.1+dfsg-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994583 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-axios
Version: 0.17.1+dfsg-2+deb10u1

Explanation: fix regular expression-based denial of service issue 
[CVE-2021-3749]

Bug#994555: node-object-path 0.11.5-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994555 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-object-path
Version: 0.11.5-3+deb11u1

Explanation: fix prototype pollution issues [CVE-2021-23434 CVE-2021-3805]

Bug#994513: debconf 1.5.71+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994513 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: debconf
Version: 1.5.71+deb10u1

Explanation: check that whiptail or dialog is actually usable

Bug#994490: node-set-value 3.0.1-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994490 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-set-value
Version: 3.0.1-2+deb11u1

Explanation: fix prototype pollution [CVE-2021-23440]

Bug#994107: mtr 0.94-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994107 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: mtr
Version: 0.94-1+deb11u1

Explanation: fix regression in JSON output

Bug#992117: node-tar 4.4.6+ds1-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 992117 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-tar
Version: 4.4.6+ds1-3+deb10u1

Explanation: remove non-directory paths from the directory cache 
[CVE-2021-32803]; strip absolute paths more comprehensively [CVE-2021-32804]

Bug#991632: node-jszip 3.1.4+dfsg-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 991632 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-jszip
Version: 3.1.4+dfsg-1+deb10u1

Explanation: use a null prototype object for this.files [CVE-2021-23413]

Bug#987372: distro-info-data 0.41+deb10u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 987372 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: distro-info-data
Version: 0.41+deb10u4

Explanation: update included data for several releases

Bug#995474: ettercap FTBFS: error: format not a string literal and no format arguments

[Helmut Grohne]

Source: ettercap
Version: 1:0.8.3.1-3
Severity: serious
Tags: ftbfs

ettercap fails to build from source in unstable on amd64, because
ncurses added format string annotations. A build now ends as follows:

| [  4%] Building C object 
src/interfaces/CMakeFiles/ec_interfaces.dir/curses/widgets/wdg_compound.c.o
| cd /<>/obj-text-only/src/interfaces && /usr/bin/cc 
-Dec_interfaces_EXPORTS -I/<>/obj-text-only/include 
-I/<>/include -I/usr/include/ncurses 
-I/<>/src/interfaces/text -I/<>/src/interfaces/daemon 
-I/<>/src/interfaces/curses 
-I/<>/src/interfaces/curses/widgets -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -fPIC 
-MD -MT 
src/interfaces/CMakeFiles/ec_interfaces.dir/curses/widgets/wdg_compound.c.o -MF 
CMakeFiles/ec_interfaces.dir/curses/widgets/wdg_compound.c.o.d -o 
CMakeFiles/ec_interfaces.dir/curses/widgets/wdg_compound.c.o -c 
/<>/src/interfaces/curses/widgets/wdg_compound.c
| /<>/src/interfaces/curses/widgets/wdg_compound.c: In function 
‘wdg_compound_border’:
| /<>/src/interfaces/curses/widgets/wdg_compound.c:381:7: error: 
format not a string literal and no format arguments [-Werror=format-security]
|   381 |   wprintw(ww->win, wo->title);
|   |   ^~~
| cc1: some warnings being treated as errors
| make[4]: *** [src/interfaces/CMakeFiles/ec_interfaces.dir/build.make:205: 
src/interfaces/CMakeFiles/ec_interfaces.dir/curses/widgets/wdg_compound.c.o] 
Error 1
| make[4]: Leaving directory '/<>/obj-text-only'
| make[3]: *** [CMakeFiles/Makefile2:651: 
src/interfaces/CMakeFiles/ec_interfaces.dir/all] Error 2
| make[3]: Leaving directory '/<>/obj-text-only'
| make[2]: *** [Makefile:149: all] Error 2
| make[2]: Leaving directory '/<>/obj-text-only'
| dh_auto_build: error: cd obj-text-only && make -j1 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
| make[1]: *** [debian/rules:43: override_dh_auto_build-text-only] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:4: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut

Bug#995448: apt-listbugs: fails to connect to the BTS - certificate expired

[Antonio Terceiro]

On Fri, Oct 01, 2021 at 07:43:35PM +0200, Michael Biebl wrote:
> Am 01.10.21 um 19:27 schrieb Antonio Terceiro:
> > I tracked this down to an issue between apt-listbugs (or ruby-soap4r, or
> > something else below that) and apt-cacher-ng. If I disable
> > apt-cacher-ng, apt-listbugs works fine. However trying to make other
> > clients go for bugs.debian.org through apt-cacher-ng work fine (e.g.
> > curl), so maybe this is not even caused by apt-cacher-ng itself.
> 
> I'm seeing the same issue and I'm also running apt-cacher-ng

FWIW for now I'm working around this issue like this:

───┬───
   │ File: /etc/apt/apt.conf.d/apt-listbugs-noproxy.conf
───┼───
   1   │ # FIXME
   2   │ Acquire::http::Proxy::bugs.debian.org DIRECT;
───┴───


signature.asc
Description: PGP signature

Bug#995370: pidgin: segmentation fault on malloc/free

[Richard Laager]

On 10/1/21 7:11 AM, Václav Ovsík wrote:

This is the changeset causing segfaults.


Thanks! That's excellent that you bisected it all the way to a commit 
(not just a release). I've copied this to the upstream bug report.


--
Richard

Bug#995460: ITP: workflow -- Parallel computing and asynchronous web server engine

[Lance Lin]

Package: wnpp
Severity: wishlist

* Package name    : workflow

  Version : 0.9.8

  Upstream Author : Li Yingxin 

* URL : https://github.com/sogou/workflow/

* License : Apache-2.0

  Programming Lang: (C++)

  Description : Parallel computing and asynchronous web server engine

Workflow can be used as a scalable web server to handle a variety of server

workflows. It can be used to orchestrate complex relationships between

computing and networking. Workflow currently supports protocols for HTTP,

Redis, MySQL, and Kafka.

I plan to maintain workflow myself since I didn't see a team that seemed 
appropriate. I'm open to suggestions though.

signature.asc
Description: OpenPGP digital signature

Bug#995448: apt-listbugs: fails to connect to the BTS - certificate expired

[Antonio Terceiro]

On Fri, Oct 01, 2021 at 05:42:32PM +0200, Francesco Poli wrote:
> > Versions of packages apt-listbugs depends on:
> > ii  apt 2.3.9
> > ii  ruby1:2.7+2
> > pn  ruby-debian 
> > pn  ruby-gettext
> > ii  ruby-soap4r 2.0.5-5
> > pn  ruby-unicode
> > pn  ruby-xmlparser  
> [...]
> 
> By the way, is this information accurate?
> Do you really miss some of the dependencies of apt-listbugs on your
> system (which would be a broken system)? Or is it just that you purged
> apt-listbugs, before filing the bug report?

BTW, no, this must be a bug in reporbug. I have:

$ dpkg-query --show apt ruby ruby-debian ruby-gettext ruby-soap4r ruby-unicode 
ruby-xmlparser
apt 2.3.9
ruby1:2.7+2
ruby-debian 0.3.10+b4
ruby-gettext3.3.3-2
ruby-soap4r 2.0.5-5
ruby-unicode0.4.4.4-1+b1
ruby-xmlparser:amd640.7.3-4


signature.asc
Description: PGP signature

Bug#995448: apt-listbugs: fails to connect to the BTS - certificate expired

[Michael Biebl]

Am 01.10.21 um 19:27 schrieb Antonio Terceiro:

I tracked this down to an issue between apt-listbugs (or ruby-soap4r, or
something else below that) and apt-cacher-ng. If I disable
apt-cacher-ng, apt-listbugs works fine. However trying to make other
clients go for bugs.debian.org through apt-cacher-ng work fine (e.g.
curl), so maybe this is not even caused by apt-cacher-ng itself.


I'm seeing the same issue and I'm also running apt-cacher-ng





OpenPGP_signature
Description: OpenPGP digital signature

Bug#995448: apt-listbugs: fails to connect to the BTS - certificate expired

[Antonio Terceiro]

Control: affects -1 apt-listbugs

On Fri, Oct 01, 2021 at 05:42:32PM +0200, Francesco Poli wrote:
> Control: severity -1 important
> Control: tags -1 + unreproducible
> Control: reassign -1 ruby-soap4r 2.0.5-5
> 
> On Fri, 1 Oct 2021 09:23:10 -0300 Antonio Terceiro wrote:
> 
> > Package: apt-listbugs
> > Version: 0.1.35
> > Severity: grave
> > Justification: renders package unusable
> > 
> > Dear Maintainer,
> 
> Hello Antonio!
> Thanks for your bug report.
> 
> > 
> > The old Let's Encrypt root certificate expired recently. Let's Encrypt
> > has moved on from that certificate a long time ago, and in principle
> > only old devices who don't get their CA store updated should be
> > affected.
> > 
> > https://techcrunch.com/2021/09/21/lets-encrypt-root-expiry/
> > 
> > However, apt-listbugs fails due to a expired certificate, while curl and
> > my web browser can access the BTS just fine:
> > 
> > 8<8<8<-
> > ~$ apt-listbugs list apt-listbugs
> > Retrieving bug reports... 0% Fail
> > Error retrieving bug reports from the server with the following error 
> > message:
> > E: SSL_connect returned=1 errno=0 state=error: certificate verify failed 
> > (certificate has expired)
> > It could be because your network is down, or because of broken proxy 
> > servers, or the BTS server itself is down. Check network configuration and 
> > try again
> > Retry downloading bug information? [Y/n] n
> > Continue the installation anyway? [y/N] n
> > E: Exiting with error
> [...]
> > 8<8<8<-
> > 
> > I can also reproduce this on a clean unstable system.
> 
> I cannot reproduce this issue on my testing systems:
> 
>   $ apt-listbugs list apt-listbugs
>   Retrieving bug reports... Done
>   Parsing Found/Fixed information... Done
>   grave bugs of apt-listbugs (→ ) 
>b1 - #995448 - apt-listbugs: fails to connect to the BTS - certificate 
> expired
>   Summary:
>apt-listbugs(1 bug)
> 
> I have just tried on my unstable chroot, as well.
> It works there, too...
> 
> 
> Some points worth noticing:
> 
>  * apt-listbugs does _not_ handle the HTTP connection directly, it uses
>the ruby-soap4r library (which, in its turn, uses some underlying
>library to handle the HTTP connection): I am reassigning this bug
>report down the chain
> 
>  * apt-listbugs does _not_ explicitly force the use of SSL (I am waiting
>for openssl 3.0.0 to be in unstable for that: see [#792639] for the
>long story): it just passes an http:// URL to the SOAP library;
>there must be something else (on your system, or on the network path
>between your system and the Debian BTS) that switches the connection
>to HTTPS, otherwise I really do not know what's going on!

I tracked this down to an issue between apt-listbugs (or ruby-soap4r, or
something else below that) and apt-cacher-ng. If I disable
apt-cacher-ng, apt-listbugs works fine. However trying to make other
clients go for bugs.debian.org through apt-cacher-ng work fine (e.g.
curl), so maybe this is not even caused by apt-cacher-ng itself.


signature.asc
Description: PGP signature

Bug#983521: Caja active loop causes high cpu loads randomly

[Rock Storm]

Package: caja
Version: 1.24.0-1+b1
Followup-For: Bug #983521
X-Debbugs-Cc: rockst...@gmx.com

Dear Maintainer,

Hi,

I believe I'm experiencing the same issue. If not, the symptoms are
similar. I run Debian 11 with MATE as desktop environment. Every time I
log into my user the process below is the highest CPU consumming
process and the average load of the PC sits at around 30%, no other
programs initiated.

/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -
nolisten tcp vt7 -novtswitch

The following step make htop to be the most demanding process with the
average load of the PC sitting at around 0.5%. Which is the situation I
would expect when no other program is running.

Below are the caja processes I see when I first log in. Killing that
process PID 1455 listed below solves the issue. I've reproduced this
several times. Killing the one with "--no-default-window" one made the
trick every time.

```
$ ps -ef | grep caja
rock14551195  2 18:09 ?00:00:01 /usr/bin/caja --no-
default-window
rock91951224  0 18:10 ?00:00:00 /usr/bin/caja
rock91977059  0 18:10 pts/100:00:00 grep --color=auto
caja
```

Hope this helps someone narrow down the issue.

Please let me know if there's anything else I could do to debug this
further.


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 caja depends on:
ii  caja-common   1.24.0-1
ii  desktop-file-utils    0.26-1
ii  gvfs  1.48.1-2
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.32-4
ii  libcairo-gobject2 1.16.0-5
ii  libcairo2 1.16.0-5
ii  libcaja-extension1    1.24.0-1+b1
ii  libexempi8    2.5.2-1
ii  libexif12 0.6.23-1
ii  libgail-3-0   3.24.30-3
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.70.0-1+b1
ii  libglib2.0-bin    2.70.0-1+b1
ii  libglib2.0-data   2.70.0-1
ii  libgtk-3-0    3.24.30-3
ii  libice6   2:1.0.10-1
ii  libmate-desktop-2-17  1.24.1-2
ii  libnotify4    0.7.9-3
ii  libpango-1.0-0    1.48.10+ds1-1
ii  libpangocairo-1.0-0   1.48.10+ds1-1
ii  libselinux1   3.1-3
ii  libsm6    2:1.2.3-1
ii  libx11-6  2:1.7.2-2+b1
ii  libxml2   2.9.12+dfsg-5
ii  mate-desktop  1.24.1-2
ii  shared-mime-info  2.0-1

Versions of packages caja recommends:
ii  gvfs-backends  1.48.1-2

Versions of packages caja suggests:
ii  engrampa    1.24.1-1+b1
pn  gstreamer1.0-tools  
ii  meld    3.20.4-1

-- no debconf information

--
Rock Storm
Open PGP: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Eugene Berdnikov]

  Hi Samuel.
  
On Tue, Sep 28, 2021 at 08:51:59PM +0100, Samuel Henrique wrote:
> >  To build version dependency automatically script should have access
> >  to the whole history of all versions of libc6, with list of symbols
> >  and markers when each symbol become usable.
> 
> We have that, you can read about it here[0][1][2], if you're interested.

 Thank you for those references, I've got much helpful info from them.

> >  Yes, this issue may occure when libc6 vesion is outdated in normal
> >  upgrade process.
> 
> I would disagree on the definition of a normal upgrade process, one
> would never end up with a combination of incompatible rsync + libc,
> that can only happen if somebody installs a package that is not
> supported by Debian (not from the official repos) and that package
> holds libc back (thus running an unsupported version)[4].

 I had several (at least 2 distinct) live systems with this post-upgrade
 problem. They have backups, but now it too late: now those backups are
 replaced by new ones.

 However, it requires some clarification what is "normal upgrade" process.
 I do not run full-upgrade ("aptitude safe-upgrade" in my taste) if some
 new package it to be installed. I simply check dependences to be sure
 that new package does not bring risk to break functionality of important
 services on production system. The full-upgrade is performed on a schedule,
 once a week or two, and requires additional monitoring of the system's
 behaviour. For example, I have an LXC containter with libc-2.31-17,
 which was not updated at least a month (file libc.so.6 dated 23-Aug).
 Running "apt-get update ; aptitude -R install rsync" I got rsync-3.2.3-8
 without libc6 update. I consider this as a normal situation, because
 I have no obligation to do full-upgrade when I install some package.
 However, this combination (rsync-3.2.3-8 + libc6-2.31-17) is not
 functional: rsync replies "failed to set permissions [...] Function
 not implemented (38)".

> I did try to reproduce the issue on Jessie, with libc 2.28, but I was
> able to run "rsync -va /etc/ld.so.cache /tmp" with no issues.

 Did you try the last rsync binary with libc6-2.28?
 I tried and got an error (see below).

> It might be possible that the issue you're seeing only affects libc
> between 2.28 and 2.31, if that's the case, it will be very tricky for
> me to reproduce since Debian only supports 2.28, 2.31 and 2.32.

 Many versions are saved here: http://snapshot.debian.org/binary/libc6/.

 Using the previously mentioned LXC container and binary packages from
 snapshot.debian.org, I tried rsync-3.2.3-8 with libc 2.31-17, 2.30-4,
 2.29-10, 2.28-10, 2.28-1, 2.27-1, in all cases rsync fails with the same
 "not implemented" error. I did not go below 2.27-1 because it requires
 downgrading of base system packages...

> If you have an affected system at hand, I would kindly ask you to try
> to implement upstream's workaround[5] and see if it makes your issue
> go away.

 I could take me too much time to set up building environment and compile
 from sources... However, I can test binary on my setup, if you provide it
 (for arch:amd64, please). I can provide access to my LXC environment:
 just send me your ssh public key, and I'll create an entry for you.

> Just a small correction, I see you mentioned lchown, but the issue is
> related to lchmod.

 Yes, it should be read "lchown" (lchmod was mentioned by mistake).
-- 
 Eugene Berdnikov

Bug#995162: cannot install together with i386

[Andreas Metzler]

Hello Mattia,

thank you for providing more background on this.

On 2021-09-30 Mattia Rizzolo  wrote:
[...]
> Realistically, package-wise, I think they would good by not placing PNGs
> in arch:any packages, that would side-step this issue.  And it's the
> proper thing to do anyway so why not.

If I thought it was the proper thing I would have done it ages ago. ;-)
Splitting off tiny arch:any packages is not without cost (inflated
number of packages is very expensive) and it was not worth it.
Given this specific problem I will probably ignore this cost and do the
split-offs since I cannot do a persistant fix on my side in a different
way..

cu Andreas

Bug#995473: picolibc: aarch64 autopkgtest fails in Ubuntu

[Steve Langasek]

Package: picolibc-aarch64-linux-gnu
Version: 1.7.2-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish

Hi Keith,

Recent versions of picolibc are failing to migrate into the Ubuntu release
because the new(ish) aarch64 autopkgtest fails on Ubuntu:

[...]
autopkgtest [19:05:54]: test command3: [---
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: 
/usr/lib/picolibc/aarch64-linux-gnu/lib/../lib/libc.a(stack_protector.c.o): in 
function `__stack_chk_fail_weak':
./aarch64-linux-gnu/../../../newlib/libc/ssp/stack_protector.c:54: undefined 
reference to `_exit'
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: 
/usr/lib/picolibc/aarch64-linux-gnu/lib/../lib/libc.a(puts.c.o): in function 
`puts':
./aarch64-linux-gnu/../../../newlib/libc/tinystdio/puts.c:41: undefined 
reference to `__iob'
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: 
./aarch64-linux-gnu/../../../newlib/libc/tinystdio/puts.c:41: undefined 
reference to `__iob'
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: 
/usr/lib/picolibc/aarch64-linux-gnu/lib/../lib/libc.a(signal.c.o): in function 
`raise':
./aarch64-linux-gnu/../../../newlib/libc/signal/signal.c:131: undefined 
reference to `getpid'
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: 
./aarch64-linux-gnu/../../../newlib/libc/signal/signal.c:131: undefined 
reference to `kill'
collect2: error: ld returned 1 exit status
[...]

  (https://autopkgtest.ubuntu.com/packages/p/picolibc/impish/amd64)

I believe the issue is that, unlike other architectures, the aarch64 support
is using gcc-aarch64-linux-gnu instead of a compiler that uses a libc-less
target by default, and makes an incorrect assumption that in its default
configuration it will not generate references to glibc.  This happens to
work for the autopkgtest test case on Debian, but fails on Ubuntu (from the
output, probably related at least in part to the additional security
hardening features that are turned on in Ubuntu gcc by default).

The following compile command succeeds:

aarch64-linux-gnu-gcc -ffreestanding --specs=picolibc.specs -o 
/tmp/touch-aarch64 debian/tests/touch.c -lm

So perhaps picolibc.specs just needs to include the equivalent of
-ffreestanding in order to be portable.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#995427: RFA: mrtg -- multi router traffic grapher

[Eriberto Mota]

Hi Sandro,

I use MRTG regularly and I have interest in adopting it. However, I
don't know the source code very well and I need to check this before.
I think that I really will adopt MRTG in one week. I will send you a
final decision soon (I think in this weekend).

Thanks for your work.

Regards,

Eriberto

Bug#995472: a2jmidid fails to build on RISC-V

[Heinrich Schuchardt]

Package: a2jmidid
Version: 9-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

building on RISC-V fails.

In Ubuntu, the attached patch was applied to achieve the following:

  * Enable building on RISC-V (LP: #1945803) 


Thanks for considering the patch.


-- System Information:
Debian Release: 11.0
  APT prefers impish
  APT policy: (500, 'impish')
Architecture: riscv64

Kernel: Linux 5.13.0-1003-generic (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru a2jmidid-9/debian/patches/0001-sigsegv-enable-RISC-V-build.patch 
a2jmidid-9/debian/patches/0001-sigsegv-enable-RISC-V-build.patch
--- a2jmidid-9/debian/patches/0001-sigsegv-enable-RISC-V-build.patch
1970-01-01 01:00:00.0 +0100
+++ a2jmidid-9/debian/patches/0001-sigsegv-enable-RISC-V-build.patch
2021-10-01 16:18:06.0 +0200
@@ -0,0 +1,47 @@
+From 2c3fbef6854743416d95d85b1565dde51668488c Mon Sep 17 00:00:00 2001
+From: Heinrich Schuchardt 
+Date: Fri, 1 Oct 2021 16:15:29 +0200
+Subject: [PATCH 1/1] sigsegv: enable RISC-V build
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Avoid build error
+
+../sigsegv.c:104:39: error: ‘mcontext_t’ has no member named ‘gregs’;
+did you mean ‘__gregs’?
+  104 | ucontext->uc_mcontext.gregs[i]
+  |   ^
+
+Signed-off-by: Heinrich Schuchardt 
+---
+ sigsegv.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/sigsegv.c b/sigsegv.c
+index fb4456e..6930185 100644
+--- a/sigsegv.c
 b/sigsegv.c
+@@ -91,7 +91,9 @@ static void signal_segv(int signum, siginfo_t* info, 
void*ptr) {
+ a2j_error("info.si_errno = %d", info->si_errno);
+ a2j_error("info.si_code  = %d (%s)", info->si_code, 
si_codes[info->si_code]);
+ a2j_error("info.si_addr  = %p", info->si_addr);
+-#if !defined(__alpha__) && !defined(__ia64__) && !defined(__FreeBSD_kernel__) 
&& !defined(__arm__) && !defined(__hppa__) && !defined(__sh__) && 
!defined(__aarch64__)
++#if !defined(__alpha__) && !defined(__ia64__) && \
++!defined(__FreeBSD_kernel__) && !defined(__arm__) && !defined(__hppa__) 
&& \
++!defined(__sh__) && !defined(__aarch64__) && !defined(__riscv)
+ for(i = 0; i < NGREG; i++)
+ a2j_error("reg[%02d]   = 0x" REGFORMAT, i,
+ #if defined(__powerpc__) && !defined(__powerpc64__)
+@@ -108,7 +110,7 @@ static void signal_segv(int signum, siginfo_t* info, 
void*ptr) {
+ ucontext->uc_mcontext.gregs[i]
+ #endif
+ );
+-#endif /* alpha, ia64, kFreeBSD, arm, hppa, aarch64 */
++#endif /* alpha, ia64, kFreeBSD, arm, hppa, aarch64, riscv */
+ 
+ #if defined(SIGSEGV_STACK_X86) || defined(SIGSEGV_STACK_IA64)
+ # if defined(SIGSEGV_STACK_IA64)
+-- 
+2.32.0
+
diff -Nru a2jmidid-9/debian/patches/series a2jmidid-9/debian/patches/series
--- a2jmidid-9/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ a2jmidid-9/debian/patches/series2021-10-01 16:18:52.0 +0200
@@ -0,0 +1 @@
+0001-sigsegv-enable-RISC-V-build.patch

Bug#995471: Backport virt-top to bullseye

[Jörn Heissler]

Package: virt-top
Version: 1.0.9-1.1

Hello,

virt-top didn't make it into bullseye:
https://tracker.debian.org/news/1196264/virt-top-removed-from-testing/
Later, a fixed version was uploaded into unstable (#973188).

That one compiles without modifications on bullseye. Could it please be
uploaded into bullseye-backports?

Cheers
Jörn Heissler


signature.asc
Description: PGP signature

Bug#995341: release.debian.org: Xen dom0 does not power off on bullseye (stable)

[Chuck Zmudzinski]

On 9/29/2021 7:26 PM, Chuck Zmudzinski wrote:



Special instructions for applying the debdiff:


Please note that an updated debdiff has been provided
to target the correct distribution and use the correct
version number for the updated package at the following
link:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995341#30

Also, a clarification:

The special instructions below (the quilt pop -a and
quilt push -a commands) are only required to test the debdiff
on a local build. No special processing should be required
on automated test builds.

Chuck




1. Download the attached debdiff, bug#994899.diff, into a working 
directory


Then in the working directory with the attached bug#994899.diff and the
archived/compressed source file archives for xen_4.14.3-1~deb11u1 in it:

2. dpkg-source -x xen_4.14.3-1~deb11u1.dsc
3. cd xen-4.14.3
4. quilt pop -a
5. patch -p1 < ../bug#994899.diff
6. quilt push -a

After these 6 steps, the tree is ready
to build the source/binary packages.

Bug#995448: apt-listbugs: fails to connect to the BTS - certificate expired

[Francesco Poli]

Control: affects -1 + apt-listbugs

I forgot...


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


pgpko8ZXPtEF7.pgp
Description: PGP signature

Bug#988923: Try again...

[Bastian Germann]

Control: forwarded -1 https://github.com/gdabah/distorm/pull/177

Bug#946788: (kein Betreff)

[Apostolos Kefalas]

I am also affected by this bug

On Thu, 09 Sep 2021 07:11:35 + c.bu...@posteo.jp wrote:
> The problem still exists in Debian 11 because the packages was not 
> updated.
> I do not understand why this was n marked as a release stopping bug for 
> Debian 11.
> 
> 

Bug#939200:

[Tony Scelfo]

I had a possibly related symptom described in
https://forums.debian.net/viewtopic.php?p=743616#p743616 with my fix
described in https://forums.debian.net/viewtopic.php?p=743676#p743676.

In short, a USB device seems to have caused issues with the kernel that led
to the increased network latency. For me, removing the USB device
completely fixed my network latency problems.

Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh

[Michael Schindler]

Package: libpam-ssh
Version: 2.3+ds-2
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

I configured and used the ssh-key forwarding of openssh. The mere installation
of libpam-ssh on the client machine breaks the functionality of
agent-forwarding in openssh: The reason for this is that libpam-ssh launches
its own ssh-agent instead of respecting the forward.

I have a server with an ssh-agent running and charged with the keys. Server and
clients are configured to forward the agent ("ForwardAgent yes" in the config
files). This is done by setting the environment variable SSH_AUTH_SOCK
appropriately. I can then log from one client to the next, and the key requests
are forwarded to the server. On the client machine with libpam-ssh installed,
however, this functionality is broken: Instead of forwarding the agent from the
server, it sets the environment variables SSH_AUTH_PID and SSH_AUTH_SOCK then
point to the freshly started ssh-agent on the client, which has no keys
charged. Thus, the login to the next client fails.


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

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

Versions of packages libpam-ssh depends on:
ii  libc6   2.31-13
ii  libpam-runtime  1.4.0-9
ii  libpam0g1.4.0-9
ii  libssl1.1   1.1.1k-1+deb11u1

Versions of packages libpam-ssh recommends:
ii  libpam-tmpdir0.09+b2
ii  openssh-client [ssh-client]  1:8.4p1-5

libpam-ssh suggests no packages.

-- no debconf information

Bug#995469: bullseye-pu: package libslirp/4.4.0-1+deb11u2

[Michael Tokarev]

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

There are a few security bugs found in libslirp, a user-level
networking library used in qemu and other places, in version
in bullseye.  These bugs has already been fixed in -testing
by a new upstream version of the library, but these CVEs are
still listed for it in bullseye.

The impact of these bugs are relatively low, - this is why
the security team decided to not release a DSA for them.
However they're security issues still, and I'd be really
glad to clear the list of security issues for this package.
I asked the security team about pushing this to bullseye-security
and the answer was to go the bullseye-proposed-updates route.

The way how libslirp is used in qemu makes every bug in libslirp
to be basically non-essential, since user-level networking is
only good for some quick testing, it is not supposed to be used
in production.  However I don't know how this library is used
in other places.

[ Tests ]
There's no automated tests tried for this library. Neither do
I have reproducers for all the issues involved. However I tested
the user-mode networking of qemu with this proposed version of
libslirp and gave it as much stress testing as I can, especially
trying to hit the areas changed. Run a bunch of various stress
testing and manually did stuff including various UDP protocols,
tftp transfers, and BOOTP debugging. So far everything seems to
work correctly.

After submitting the previous release I found another issue
which was the most simple and which for some reason I weren't
tested, and fixed it by another, later change from upstream, -
which fixed a regression if one of the fix. This is actually
the most typical usage scenario, and now I'm certain the most
common case is working too.  No other changes upstream are
relevant.

The same changes were made upstream (these *are* changes taken
from upstream, with very minor editing of context so eg function
declarations will find their way in the header file which, in
a later version, contained more declarations than in the version
in bullseye), - and these upstream changes has been tested by
numerous people including debian testing. I hadn't need to backport
the changes, the code is the same (if not counting the context
in header file).

[ Risks ]
Again, due to the nature of this package which is mostly aimed
for testing and not real production, the risk of breaking it is
rather small. It can affect quite some people ofcourse. Having
in mind this is the same set of changes already used by many
people in a more recent version, I don't expect a big issue there.

[ 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 ]
Here are the changelog entry for the new release:

libslirp (4.4.0-1+deb11u2) bullseye; urgency=medium



  * fix-DHCP-broken-in-libslirp-v4.6.0.patch from upstream

this fixes previous change in this area

(bootp-limit-vendor-area-to-input-packet-CVE-2021-3592.patch).

https://gitlab.freedesktop.org/slirp/libslirp/-/issues/48



 -- Michael Tokarev   Fri, 01 Oct 2021 19:10:39 +0300



libslirp (4.4.0-1+deb11u1) bullseye; urgency=medium

  * import a few patches from upstream to fix 4 security issues:
   - add-mtod_check.patch (preparational)
   - bootp-limit-vendor-area-to-input-packet-CVE-2021-3592.patch,
 bootp-check-bootp_input-buffer-size-CVE-2021-3592.patch
 Closes: #989993, CVE-2021-3592: invalid pointer init in bootp_init()
   - tftp-check-tftp_input-buffer-size-CVE-2021-3595.patch,
 tftp-introduce-a-header-structure-CVE-2021-3595.patch
 Closes: #989996, CVE-2021-3595: invalid pointer init in tftp_input()
   - udp-check-upd_input-buffer-size-CVE-2021-3594.patch
 Closes: #989995, CVE-2021-3594: invalid pointer init in udp_input()
   - upd6-check-udp6_input-buffer-size-CVE-2021-3593.patch
 Closes: #989994, CVE-2021-3593: invalid pointer init in udp6_input()

 -- Michael Tokarev   Thu, 30 Sep 2021 21:08:51 +0300

[ Other info ]
And here's the debdiff.

Thanks!

/mjt

diff -Nru libslirp-4.4.0/debian/changelog libslirp-4.4.0/debian/changelog

--- libslirp-4.4.0/debian/changelog 2020-12-19 18:36:33.0 +0300

+++ libslirp-4.4.0/debian/changelog 2021-10-01 19:10:39.0 +0300

@@ -1,3 +1,29 @@

+libslirp (4.4.0-1+deb11u2) bullseye; urgency=medium

+

+  * fix-DHCP-broken-in-libslirp-v4.6.0.patch from upstream

+this fixes previous change in this area

+(bootp-limit-vendor-area-to-input-packet-CVE-2021-3592.patch).

+https://gitlab.freedesktop.org/slirp/libslirp/-/issues/48

+

+ -- Michael Tokarev   Fri, 01 Oct 2021 19:10:39 +0300

+

+libslirp (4.4.0-1+deb11u1) bullseye; urgency=medium

+

+  * import a few patches from upstream to fix 4 security issues:

+   - 

Bug#994294: python3-numba: armel tests fail: Symbol not found: __sync_fetch_and_add_4 [armel]

[Drew Parsons]

Source: numba
Followup-For: Bug #994294
Control: forwarded 994294 https://github.com/numba/numba/issues/7452

We've got numba 0.52, while 0.54 was released last week. Is it possible 
to package up numba 0.54 for further testing?

Bug#958362: pdfrw: fails with python 3.7+ -- abandoned upstream

[Bastian Germann]

On Mon, 20 Apr 2020 23:30:00 +0200 Johannes 'josch' Schauer  
wrote:

In this state, pdfrw should not be included in the next Debian stable
release.


https://github.com/sarnold/pdfrw has a fork that is actively maintained.
Gentoo already uses this as upstream.

Bug#995448: apt-listbugs: fails to connect to the BTS - certificate expired

[Francesco Poli]

Control: severity -1 important
Control: tags -1 + unreproducible
Control: reassign -1 ruby-soap4r 2.0.5-5

On Fri, 1 Oct 2021 09:23:10 -0300 Antonio Terceiro wrote:

> Package: apt-listbugs
> Version: 0.1.35
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,

Hello Antonio!
Thanks for your bug report.

> 
> The old Let's Encrypt root certificate expired recently. Let's Encrypt
> has moved on from that certificate a long time ago, and in principle
> only old devices who don't get their CA store updated should be
> affected.
> 
> https://techcrunch.com/2021/09/21/lets-encrypt-root-expiry/
> 
> However, apt-listbugs fails due to a expired certificate, while curl and
> my web browser can access the BTS just fine:
> 
> 8<8<8<-
> ~$ apt-listbugs list apt-listbugs
> Retrieving bug reports... 0% Fail
> Error retrieving bug reports from the server with the following error message:
> E: SSL_connect returned=1 errno=0 state=error: certificate verify failed 
> (certificate has expired)
> It could be because your network is down, or because of broken proxy servers, 
> or the BTS server itself is down. Check network configuration and try again
> Retry downloading bug information? [Y/n] n
> Continue the installation anyway? [y/N] n
> E: Exiting with error
[...]
> 8<8<8<-
> 
> I can also reproduce this on a clean unstable system.

I cannot reproduce this issue on my testing systems:

  $ apt-listbugs list apt-listbugs
  Retrieving bug reports... Done
  Parsing Found/Fixed information... Done
  grave bugs of apt-listbugs (→ ) 
   b1 - #995448 - apt-listbugs: fails to connect to the BTS - certificate 
expired
  Summary:
   apt-listbugs(1 bug)

I have just tried on my unstable chroot, as well.
It works there, too...


Some points worth noticing:

 * apt-listbugs does _not_ handle the HTTP connection directly, it uses
   the ruby-soap4r library (which, in its turn, uses some underlying
   library to handle the HTTP connection): I am reassigning this bug
   report down the chain

 * apt-listbugs does _not_ explicitly force the use of SSL (I am waiting
   for openssl 3.0.0 to be in unstable for that: see [#792639] for the
   long story): it just passes an http:// URL to the SOAP library;
   there must be something else (on your system, or on the network path
   between your system and the Debian BTS) that switches the connection
   to HTTPS, otherwise I really do not know what's going on!

[#792639]: 

[...]
> Versions of packages apt-listbugs depends on:
> ii  apt 2.3.9
> ii  ruby1:2.7+2
> pn  ruby-debian 
> pn  ruby-gettext
> ii  ruby-soap4r 2.0.5-5
> pn  ruby-unicode
> pn  ruby-xmlparser  
[...]

By the way, is this information accurate?
Do you really miss some of the dependencies of apt-listbugs on your
system (which would be a broken system)? Or is it just that you purged
apt-listbugs, before filing the bug report?


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


pgpKZVu0csUUG.pgp
Description: PGP signature

Bug#995214: Wide apostrophe ending up on single width pages

[積丹尼 Dan Jacobson]

> "YW(" == Yao Wei (魏銘廷)  writes:

YW(> You can try preferring Latin fonts to CJK fonts.

How? 怎麼設定？

Bug#995467: ITS: mlton

[Ryan Kavanagh]

Package: mlton
Version: 20130715-3
Severity: important

Hi,

I intend to salvage [0] the mlton package. It has been uninstallable for
years now [1], and has had other RC bugs since 2018 [2, 3]. I attempted
to contact the current maintainer a month ago (with MIA CC'd) to
determine if they were still interested in maintaining the package, but
I have received no response.

Best,
Ryan

[0] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992097
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904475
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917644

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 mlton depends on:
ii  mlton-compiler  20130715-3
ii  mlton-doc   20130715-3
ii  mlton-tools 20130715-3

mlton recommends no packages.

mlton suggests no packages.

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#994294: python3-numba: armel tests fail: Symbol not found: __sync_fetch_and_add_4 [armel]

[Drew Parsons]

Source: numba
Followup-For: Bug #994294

numba test options give a better more detail

experimental_armel-dchroot$ python3 -m numba.runtests --log
DEBUG:numba.core.byteflow:bytecode dump:
>  0NOP(arg=None, lineno=38)
   2LOAD_FAST(arg=0, lineno=38)
   4LOAD_FAST(arg=1, lineno=38)
   6BINARY_ADD(arg=None, lineno=38)
   8RETURN_VALUE(arg=None, lineno=38)
DEBUG:numba.core.byteflow:pending: deque([State(pc_initial=0 nstack_initial=0)])
DEBUG:numba.core.byteflow:stack: []
DEBUG:numba.core.byteflow:dispatch pc=0, inst=NOP(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack []
DEBUG:numba.core.byteflow:dispatch pc=2, inst=LOAD_FAST(arg=0, lineno=38)
DEBUG:numba.core.byteflow:stack []
DEBUG:numba.core.byteflow:dispatch pc=4, inst=LOAD_FAST(arg=1, lineno=38)
DEBUG:numba.core.byteflow:stack ['$a2.0']
DEBUG:numba.core.byteflow:dispatch pc=6, inst=BINARY_ADD(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack ['$a2.0', '$b4.1']
DEBUG:numba.core.byteflow:dispatch pc=8, inst=RETURN_VALUE(arg=None, lineno=38)
DEBUG:numba.core.byteflow:stack ['$6binary_add.2']
DEBUG:numba.core.byteflow:end state. edges=[]
DEBUG:numba.core.byteflow:-Prune 
PHIs-
DEBUG:numba.core.byteflow:Used_phis: defaultdict(, 
{State(pc_initial=0 nstack_initial=0): set()})
DEBUG:numba.core.byteflow:defmap: {}
DEBUG:numba.core.byteflow:phismap: defaultdict(, {})
DEBUG:numba.core.byteflow:changing phismap: defaultdict(, {})
DEBUG:numba.core.byteflow:keep phismap: {}
DEBUG:numba.core.byteflow:new_out: defaultdict(, {})
DEBUG:numba.core.byteflow:--DONE Prune 
PHIs---
DEBUG:numba.core.byteflow:block_infos State(pc_initial=0 nstack_initial=0):
AdaptBlockInfo(insts=((0, {}), (2, {'res': '$a2.0'}), (4, {'res': '$b4.1'}), 
(6, {'lhs': '$a2.0', 'rhs': '$b4.1', 'res': '$6binary_add.2'}), (8, {'retval': 
'$6binary_add.2', 'castval': '$8return_value.3'})), outgoing_phis={}, 
blockstack=(), active_try_block=None, outgoing_edgepushed={})
DEBUG:numba.core.interpreter:label 0:
a = arg(0, name=a)   ['a']
b = arg(1, name=b)   ['b']
$6binary_add.2 = a + b   ['$6binary_add.2', 'a', 'b']
$8return_value.3 = cast(value=$6binary_add.2) ['$6binary_add.2', 
'$8return_value.3']
return $8return_value.3  ['$8return_value.3']

DEBUG:numba.core.ssa: SSA block analysis pass on 0
DEBUG:numba.core.ssa:Running 
DEBUG:numba.core.ssa:on stmt: a = arg(0, name=a)
DEBUG:numba.core.ssa:on stmt: b = arg(1, name=b)
DEBUG:numba.core.ssa:on stmt: $6binary_add.2 = a + b
DEBUG:numba.core.ssa:on stmt: $8return_value.3 = cast(value=$6binary_add.2)
DEBUG:numba.core.ssa:on stmt: return $8return_value.3
DEBUG:numba.core.ssa:defs defaultdict(,
{'$6binary_add.2': [],
 '$8return_value.3': [],
 'a': [],
 'b': []})
DEBUG:numba.core.ssa:SSA violators set()
LLVM ERROR: Symbol not found: __sync_fetch_and_add_4


So, the error is coming from numba.core.ssa