Bug#1017976: Info received (Confirmation)

[Markus Huber]

> Installing "emacs-el" (emacs-common recommends but not depends on it) solved 
> it on my system.

Also the recommended Package "libc6-dev" should be depending (if not, the 
native lisp compilation will fail).

Now we have:
- emacs-common recommends emacs-el
- libgccjit0 depends on libgcc-12-dev, which recommends libc6-dev

Should be:
- emacs-common depends on emacs-el
- libgccjit0 depends on libgcc-12-dev, which depends on libc6-dev

Bug#1018809: davmail: Depends: are too weak

[Dima Kogan]

Package: davmail
Version: 6.0.1.3390-1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. I'm running Debian/sid on amd64. I just did

  apt install davmail

Then this happens:

  $ davmail 

  Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load 
library: /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so
  at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2633)
  

I don't have this file on my system. If this file is required for
davmail to work, then the dependencies should have pulled it in. I see:

  $ apt-file find /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so

  openjdk-11-jre: /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so

So I guess we need

  Depends: openjdk-11-jre

Or something?

Thanks.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf-8), LANGUAGE=en_US.utf-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages davmail depends on:
ii  adduser   3.118
ii  default-jre-headless [java9-runtime-headless] 2:1.11-72
ii  init-system-helpers   1.61
ii  libcommons-codec-java 1.15-1
ii  libcommons-logging-java   1.2-2
ii  libhtmlcleaner-java   2.26-1
ii  libhttpclient-java4.5.13-3
ii  libjackrabbit-java2.20.3-1
ii  libjcifs-java 1.3.19-2
ii  libjettison-java  1.4.1-1
ii  liblog4j1.2-java  1.2.17-10
ii  libmail-java  1.6.5-1
ii  libslf4j-java 1.7.32-1
ii  libstax2-api-java 4.1-1
ii  libwoodstox-java  1:6.2.1-1
ii  logrotate 3.18.1-2
ii  lsb-base  11.1.0
ii  openjdk-11-jre-headless [java9-runtime-headless]  11.0.14+9-1
ii  openjdk-15-jre-headless [java9-runtime-headless]  15.0.2+7-1

davmail recommends no packages.

Versions of packages davmail suggests:
ii  default-jre 2:1.11-72
ii  libopenjfx-java 11.0.11+0-1
pn  libswt-cairo-gtk-4-jni  

-- no debconf information

Bug#1018808: src:haskell-haskell-gi: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: haskell-haskell-gi
Version: 0.24.4-2
Severity: serious
Control: close -1 0.26.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:haskell-haskell-gi has been trying to 
migrate for 78 days [2]. Hence, I am filing this bug. Judging from the 
name of your package I assume your package is part of the unfinished ghc 
transition.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018807: src:haskell-haskell-gi-base: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: haskell-haskell-gi-base
Version: 0.24.2-1
Severity: serious
Control: close -1 0.26.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:haskell-haskell-gi-base has been trying to 
migrate for 78 days [2]. Hence, I am filing this bug. Judging from the 
name of your package I assume your package is part of the unfinished ghc 
transition.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Paul Gevers]

Hi,

On 30-08-2022 22:20, Paul Gevers wrote:
[...]

For avoidance of doubt, I didn't ACK or NACK the transition. I just 
wanted to answer Simon's question about the course of solutions.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#983146: 983146 RFS: bung/3.2.6-5 [ITP] -- backup next generation

[Charles]

Dear Bastian

> During the package build with libreoffice-common as Build-Dependency

Thank you for guidance.  Done.  Uploaded to 
https://mentors.debian.net/package/bung,  The QA information is now


– Package uses debhelper-compat
Debhelper compatibility level 13
– Package is the latest upstream version
local:3.2.6
upstream:3.2.6
url: 
https://github.com/CharlesMAtkinson/bung/releases/download/3.2.6/bung_3.2.6.source_with_htm_and_pdf.tgz

– Package is not native
format:3.0 (quilt)
– "Maintainer" email is the same as the uploader
– Package has lintian informational tags
bung
I extra-license-file
[usr/share/doc/bung/COPYING.gz]
I possible-documentation-but-no-doc-base-registration
I spare-manual-page
[usr/share/man/man8/bung-common.8.gz]
I systemd-service-file-missing-documentation-key
[lib/systemd/system/bung.rm_old_logs.service]
bung source
I out-of-date-standards-version
4.5.1 (released 2020-11-17) (current is 4.6.1.0)
I unused-entry-in-debian-source-include-binaries
usr/share/doc/bung/Backup scripts next generation 3.2.x 
Programmer's Guide.htm [debian/source/include-binaries:1]
usr/share/doc/bung/Backup scripts next generation 3.2.x 
Programmer's Guide.pdf [debian/source/include-binaries:3]
usr/share/doc/bung/Backup scripts next generation 3.2.x 
User Guide.htm [debian/source/include-binaries:4]
usr/share/doc/bung/Backup scripts next generation 3.2.x 
User Guide.pdf [debian/source/include-binaries:6]

P very-long-line-length-in-source-file
1502 > 512 [usr/share/doc/bung/Backup scripts next 
generation 3.2.x Programmer's Guide.odt:115]
1703 > 512 [usr/share/doc/bung/Backup scripts next 
generation 3.2.x User Guide.odt:239]
2165 > 512 [usr/share/doc/bung/Backup scripts next 
generation Publisher's Guide.odt:3]

X debian-watch-does-not-check-gpg-signature
[debian/watch]
X prefer-uscan-symlink
filenamemangle 
s%(?:.*?)?v?(\d[\d.]*)\.source_with_htm_and_pdf\.tgz%@PACKAGE@-$1.tgz% 
[debian/watch:4]

X upstream-metadata-file-is-missing
– Package closes ITP bug
bung:
#985918 (Wishlist, ITP): ITP: bung -- backup next generation
– No VCS field present
– Package is not in Debian
– Upstream-Contact missing from d/copyright
author:None
licenses:GPL-2.0+

Is there anything else you need me to fix?

Best

Charles

Bug#1018806: coreutils: stty: everything after -- ignored?

[наб]

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

-- >8 --
$ stty -a -- -g tabs
speed 19200 baud; rows 54; columns 216; line = 255;
intr = ^C; quit = ^\; erase = ^?; kill = M-^?; eof = ^D; eol = ; eol2 = 
; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^K; werase 
= ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke -flusho -extproc
-- >8 --

Huh? The -g operand isn't a valid tty flag and -a excludes specifying
any operands anyway.

-- >8 --
$ stty -- tabs
speed 19200 baud; line = 255;
kill = M-^?; rprnt = ^K;
-- >8 --

This is in clear and blatant violation of USG.

Best,
наб

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1018805: Enable android-platform-system-extras on ppc64el

[Thomas Fitzsimmons]

Package: android-platform-system-extras
Version: 10.0.0+r36+ds

I'd like to get fastboot and adb installable on ppc64el.  One of their
build prerequisites is android-libext4-utils.

Can you add ppc64el to the Architecture lines in debian/control, for
android-libext4-utils and android-libfec?  I tested on Debian GNU/Linux
bookworm ppc64le, and the build works fine.

Thank you,
Thomas

Bug#1018804: libabsl20220623: [!amd64] cordz statistics may be racy

[Benjamin Barenblat]

I’ve uploaded 0~20220623.0-2, which skips the problematic test, to
unblock the libabsl20210324-to-libabsl20220623 transition (see [1] et
seq.).

[1] https://lists.debian.org/debian-release/2022/08/msg00702.html

(https://lists.debian.org/msgid-search/26fc0675-3232-23de-0149-83b703c4a...@debian.org)

Bug#1018804: libabsl20220623: [!amd64] cordz statistics may be racy

[Benjamin Barenblat]

Package: libabsl20220623
Version: 0~20220623.0-1

Per [1], absl_cordz_info_statistics_test crashes on ppc64el.
Investigation on a porterbox shows the test fails pretty consistently
under asan and tsan. The test passes on amd64. I’ll continue
investigating this; in the meantime, be aware that requesting cordz
statistics may yield incorrect results (or may even invoke undefined
behavior) on non-amd64 platforms.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=abseil=ppc64el=0%7E20220623.0-1=1661859644=0

Bug#1018684: vmpk: program incompletely applied after restart

[Ash Joubert]

On 30/08/2022 08:19, Pedro Lopez-Cabanillas wrote:

There is a setting in VMPK for you: Edit->Preferences->Behavior tab,
checkbox "MIDI channel state consistency". When this setting is enabled
provides consistency between the screen widgets and the synthesizer's
state.


With "MIDI channel state consistency" enabled, instruments sound 
distorted after restart, with what sounds like an echo and balance to 
the left. I am using FluidSynth and PulseAudio.


Kind regards,

--
Ash Joubert (they/them) 
Director
Transient Software Limited 
New Zealand

Bug#1018803: coreutils: stty: drain/-drain doesn't interact with -g/-a/default output?

[наб]

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

It appears drain/-drain is special, in that, unlike all operands,
it does /not/ prevent default output and it does /not/ exclude -a/-g:
-- >8 --
$ stty -drain
speed 38400 baud; line = 0;
-brkint -imaxbel
$ stty -drain -g
500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
$ stty -drain -a
speed 38400 baud; rows 54; columns 172; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase 
= ^W; lnext = ^V;
discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke -flusho -extproc
-- >8 --

This is undocumented, and, indeed, directly against the usage string:
  Usage: stty [-F DEVICE | --file=DEVICE] [SETTING]...
or:  stty [-F DEVICE | --file=DEVICE] [-a|--all]
or:  stty [-F DEVICE | --file=DEVICE] [-g|--save]

I assume this is an oversight.

Best,
наб

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1018802: localechooser: reproducible builds: locale and parallelism trigger reproducibility issues

[Vagrant Cascadian]

Source: localechooser
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The templates file contains randomness and locale-specific translations
dependent on the host system locale.

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/localechooser.html

  Indices-lo.UTF-8:·1,·2,·3,·4,·5,·6,·7,·8,·9,·10,·11, ... ,·50,·51
  vs.
  Indices-lo.UTF-8:·1,·3,·4,·5,·6,·7,·8,·9,·10,·11, ... ·50,·51,·2,·19

  Choices-lo.UTF-8:·Algeria,·Angola,·Benin,·Botswana, ... 
Eswatini,·Ethiopia,·Gabon ...
  vs.
  Choices-lo.UTF-8:·Algeria,·ປະເທດອັງໂກລາ,·Benin,·Botswana, ... 
Eswatini,·ເອທິໂອເປຍ,·Gabon ...

That attached patches fix this by passing --no-parallel to dh (parallism
was probably introduced in the switch from debhelper compat 9 to 13),
and by exporting LC_ALL=C.UTF-8 in debian/rules.


Thanks for maintaining localechooser!


live well,
  vagrant
From 29d0987352263aa2ebedf89c558ff2868dd777d4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 31 Aug 2022 01:04:15 +
Subject: [PATCH 1/2] debian/rules: Disable parallelism for reproducible build.

---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 00100dd0..1eefc5fa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,7 @@
 #! /usr/bin/make -f
 %:
-	dh $@
+	# Avoid parallelism triggering reproducibility issues
+	dh $@ --no-parallel
 
 PACKAGE=localechooser
 
-- 
2.30.2

From 52ec1950fbeb4af707991b38556438b2e1296133 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 31 Aug 2022 01:04:41 +
Subject: [PATCH 2/2] debian/rules: Run the build with the C.UTF-8 locale for
 reproducible build.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 1eefc5fa..62c0230d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,6 +13,9 @@ else # run after network-console for s390
 MENUITEMNUM=2110
 endif
 
+# Avoid locale-specific reproducibility issues
+export LC_ALL=C.UTF-8
+
 override_dh_clean:
 	rm -rf debian/pobuild debian/iso-codes debian/short-tmp
 	rm -rf debian/locales debian/sort-tmp
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1018801: stdx-allocator ftbfs: assertThrown failed: No Exception was thrown.

[Steve Langasek]

Source: stdx-allocator
Version: 3.1.0~beta.2-3
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Matthias,

After fixing up stdx-allocator build-deps so that they're installable,
stdx-allocator fails to build from source due to a test failure:

[...]
 1/1 =
test: stdx-allocator-test
start time:   00:11:36
duration: 0.03s
result:   exit status 1
command:  MALLOC_PERTURB_=202 
'/<>/obj-x86_64-linux-gnu/stdx-allocator-test'
--- stderr ---
core.exception.AssertError@../source/stdx/allocator/package.d(1399): 
assertThrown failed: No Exception was thrown.

/usr/lib/ldc/x86_64-linux-gnu/include/d/std/exception.d:299 [0x55d86e05b4d5]
../source/stdx/allocator/package.d:1399 [0x55d86e065d87]
??:? [0x7fbe61462c85]
??:? [0x7fbe61480d7a]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref 
rt.sections_elf_shared.DSO)) [0x7fbe61481e08]
??:? int rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))) [0x7fbe61480d0b]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) 
[0x7fbe6146e9be]
??:? runModuleUnitTests [0x7fbe61462b34]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int 
function(char[][])*).runAll() [0x7fbe6147738a]
??:? _d_run_main2 [0x7fbe614771d5]
??:? _d_run_main [0x7fbe6147702d]
??:? [0x7fbe6119654f]
??:? __libc_start_main [0x7fbe61196608]
??:? [0x55d86dffd9b4]
1/22 modules FAILED unittests
==
[...]

You can see this in the Ubuntu build logs at
.

-- 
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#1018800: buster-pu: package inetutils/2:1.9.4-7+deb10u2

[Guillem Jover]

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

Hi!

This is the counterpart to #1018744 but for buster.

[ Reason ]

This fixes three pending security issue, that the security team (CCed)
would prefer to see handled as normal oldstable updates.

(This is the same set of changes as the bullseye version, plus a couple
of patches from upstream for CVE-2019-0053, that are missing in that
version.)

[ Impact ]

All changes are security related, mostly buffer overflows, that can at
least cause crashes and DoS.

[ Tests ]

The same tests as the ones for bullseye in #1018744 were used here and
the issues could be reproduced before, and not any more after the
patched version.

[ Risks ]

Same risks as the version for bullseye.

[ Checklist ]

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

[ Changes ]

  * Security fixes for telnet client:
- Validate supplied environment variables.
- Check for buffer overflows when processing telnet protocol messages.
- Add checks for option reply parsing limits causing buffer
  overflow induced crashes due to long option values.
- Fix infinite loop causing a stack exhaustion induced crash due to
  malicious server commands.
Fixes CVE-2019-0053. Closes: #945861
  * Fix inetutils-ftp security bug trusting FTP PASV responses.
Fixes CVE-2021-40491. Closes: #993476
  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
adapted by Erik Auerswald .
Fixes CVE-2022-39028.

[ Other info ]

None.

Thanks,
Guillem
diff -Nru inetutils-1.9.4/debian/changelog inetutils-1.9.4/debian/changelog
--- inetutils-1.9.4/debian/changelog2020-09-18 20:06:42.0 +0200
+++ inetutils-1.9.4/debian/changelog2022-08-31 00:58:35.0 +0200
@@ -1,3 +1,23 @@
+inetutils (2:1.9.4-7+deb10u2) buster; urgency=medium
+
+  * Security fixes for telnet client:
+- Validate supplied environment variables.
+- Check for buffer overflows when processing telnet protocol messages.
+- Add checks for option reply parsing limits causing buffer
+  overflow induced crashes due to long option values.
+- Fix infinite loop causing a stack exhaustion induced crash due to
+  malicious server commands.
+Fixes CVE-2019-0053. Closes: #945861
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+Fixes CVE-2022-39028.
+
+ -- Guillem Jover   Wed, 31 Aug 2022 00:58:35 +0200
+
 inetutils (2:1.9.4-7+deb10u1) buster; urgency=medium
 
   * CVE-2020-10188 (Closes: #956084)
diff -Nru 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
  1970-01-01 01:00:00.0 +0100
+++ 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
  2022-08-31 00:58:35.0 +0200
@@ -0,0 +1,54 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c |   21 +
+ 1 file changed, 21 insertions(+)
+
+--- a/ftp/ftp.c
 b/ftp/ftp.c
+@@ -1357,6 +1357,13 @@ initconn (void)
+ uint32_t *pu32 = (uint32_t *) _addr_sa4->sin_addr.s_addr;
+ pu32[0] = htonl ( (h[0] << 24) | (h[1] << 16) | (h[2] << 8) | 
h[3]);
+   }
++  if (data_addr_sa4->sin_addr.s_addr
++  != ((struct sockaddr_in *) )->sin_addr.s_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv4 */
+ else /* IPv6 */
+   {
+@@ -1387,6 +1394,13 @@ initconn (void)
+ pu32[2] = htonl ( (h[8] << 24) | (h[9] << 16) | (h[10] << 8) 
| h[11]);
+ pu32[3] = htonl ( (h[12] << 24) | (h[13] << 16) | (h[14] << 
8) | h[15]);
+   }
++  if (data_addr_sa6->sin6_addr.s6_addr
++  != ((struct sockaddr_in6 *) 

Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1

[Paul Wise]

On Tue, 2022-08-30 at 22:59 +0200, Thomas Uhle wrote:

> I have prepared a patch for changing the order in which the libraries
> are built and to fix linking.

Thanks for the patch, please consider sending it upstream too,
even though upstream doesn't appear to be very active.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1018799: gcc-12: Workround for fixing -latomic issue on riscv64 after glibc2.34

[Bo YU]

Source: gcc-12
Version: 12.2.0-1
Severity: important
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear gcc Maintainer,

Since glibc 2.34 we need to link libatomic explicitly to fix
huge amount issues that has ftbfs on riscv64.

The detailed explanation is here[0]:

```
... linking with -pthread automatically links with libatomic,
however the recent upload of glibc 2.34 made the -pthread flag 
not fully necessary anymore, and cmake decided to stop using it. 
The workaround is to explicitly link with libatomic
```
We have sent numerous patches to fix this issue[1]. But it is
obvious that, in the past, using the pthread flag in cmake to 
link libatomic, there will be trouble after rebuild like [2].

The workground is *stolen* from Arch linux gcc patch:
https://github.com/felixonmars/archriscv-packages/blob/master/gcc/riscv64.patch#L65

So can we try it? I am not gcc expert and unable to evaluate
the workround how trouble if enabled in Debian. Or there are 
other better solutions? 

Welcome Comments here.

Please feel free to change severity if it is inappropriate.


[0]: https://lists.debian.org/debian-riscv/2022/08/msg00028.html
[1]: 
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-riscv%40lists.debian.org=riscv64
[2]: 
https://buildd.debian.org/status/fetch.php?pkg=opentracing-cpp=riscv64=1.6.0-3=1661892134=0
-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1018798: RM: nautius-sendto -- RoM; unmaintained, feature now part of Nautilus 43

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: nautilus-sen...@packages.debian.org
Affects: src:nautilus-sendto

Please remove nautilus-sendto.

Its last upstream release was 5 years ago. It has been archived which
means bug reports, translation updates, and bug fixes are no longer
being accepted. [1]

Before its final release, all its features were removed except the
ability to attach a file to a draft email in various email clients.
Nautilus 43 overhauled the extension API and added a built in Email
feature. Therefore, this addon is no longer useful.

[1] https://gitlab.gnome.org/GNOME/nautilus-sendto

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#1018797: glib-d FTBFS: conflicting constructors

[Steve Langasek]

Source: glib-d
Version: 2.3.0-2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Matthias,

After patching dh-dlang as in bug #1018795, and rebuilding gir-to-d against
current ldc, I find that glib-d FTBFS because of invalid generated code:

[...]
FAILED: 
libglibd-2.0.so.2.2.0.p/obj-x86_64-linux-gnu_generated_gio_DtlsConnectionIF.d.o 
ldc2 -I=libglibd-2.0.so.2.2.0.p -I=. -I=.. -I=generated -I=../generated 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/libmount -I/usr/include/blkid -enable-color -wi -O -g -release 
-wi -relocation-model=pic 
-makedeps=libglibd-2.0.so.2.2.0.p/obj-x86_64-linux-gnu_generated_gio_DtlsConnectionIF.d.o.deps
 
-of=libglibd-2.0.so.2.2.0.p/obj-x86_64-linux-gnu_generated_gio_DtlsConnectionIF.d.o
 -c ../obj-x86_64-linux-gnu/generated/gio/DtlsConnectionIF.d
generated/gio/TlsCertificate.d(194): Error: constructor 
`gio.TlsCertificate.TlsCertificate.this(string certFile, string keyFile)` 
conflicts with previous declaration at generated/gio/TlsCertificate.d(146)
[...]


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#1018790: coreutils: stty: "ispeed anything" is valid and doesn't seem to do anything

[Pádraig Brady]

On 30/08/2022 21:40, наб wrote:

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

stty ispeed and ospeed don't seem to check that the speed is valid:
-- >8 --
$ LD_PRELOAD=$PWD/dumpispeed.so stty ispeed 420
cfsetispeed(0xPOINTER, 4294967295)=-1

$ LD_PRELOAD=$PWD/dumpispeed.so stty ispeed 57600
cfsetispeed(0xPOINTER, 4097)=0
-- >8 --

Compare bare speeds:
-- >8 --
$ stty 420
stty: invalid argument 420
Try 'stty --help' for more information.

$ stty 57600
-- >8 --


Good catch.
We'll fix this upstream with the attached.

thanks,
Pádraig
From 544cead8456cf788b47ed13cf17b55bc996b5791 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Wed, 31 Aug 2022 00:17:21 +0100
Subject: [PATCH] stty: valid ispeed and ospeed arguments

* src/stty.c (apply_settings): Validate [io]speed arguments
against the internal accepted set.
(set_speed): Check the cfset[io]speed() return value so
that we validate against the system supported set.
* tests/misc/stty-invalid.sh: Add a test case.
* NEWS: Mention the bug fix.
Reported in https://bugs.debian.org/1018790
---
 NEWS   |  5 +
 src/stty.c | 29 +
 tests/misc/stty-invalid.sh |  3 +++
 3 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index ab1a2ef91..db5150824 100644
--- a/NEWS
+++ b/NEWS
@@ -26,6 +26,11 @@ GNU coreutils NEWS-*- outline -*-
   long been documented to be platform-dependent.
   [bug introduced 1999-05-02 and only partly fixed in coreutils-8.14]
 
+  stty ispeed and ospeed options no longer accept and silently ignore
+  invalid speed arguments.  Now they're validated against both the
+  general accepted set, and the system supported set of valid speeds.
+  [This bug was present in "the beginning".]
+
 ** Changes in behavior
 
   'cp --reflink=always A B' no longer leaves behind a newly created
diff --git a/src/stty.c b/src/stty.c
index 3b6a592a9..3d515223e 100644
--- a/src/stty.c
+++ b/src/stty.c
@@ -1159,6 +1159,11 @@ apply_settings (bool checking, char const *device_name,
 {
   check_argument (arg);
   ++k;
+  if (string_to_baud (settings[k]) == (speed_t) -1)
+{
+  error (0, 0, _("invalid ispeed %s"), quote (settings[k]));
+  usage (EXIT_FAILURE);
+}
   if (checking)
 continue;
   set_speed (input_speed, settings[k], mode);
@@ -1169,6 +1174,11 @@ apply_settings (bool checking, char const *device_name,
 {
   check_argument (arg);
   ++k;
+  if (string_to_baud (settings[k]) == (speed_t) -1)
+{
+  error (0, 0, _("invalid ospeed %s"), quote (settings[k]));
+  usage (EXIT_FAILURE);
+}
   if (checking)
 continue;
   set_speed (output_speed, settings[k], mode);
@@ -1696,13 +1706,24 @@ set_control_char (struct control_info const *info, char const *arg,
 static void
 set_speed (enum speed_setting type, char const *arg, struct termios *mode)
 {
-  speed_t baud;
+  /* Note cfset[io]speed(), do not check with the device,
+ and only check whether the system logic supports the specified speed.
+ Therefore we don't report the device name in any errors.  */
+
+  speed_t baud = string_to_baud (arg);
+
+  assert (baud != (speed_t) -1);
 
-  baud = string_to_baud (arg);
   if (type == input_speed || type == both_speeds)
-cfsetispeed (mode, baud);
+{
+  if (cfsetispeed (mode, baud))
+die (EXIT_FAILURE, 0, "unsupported ispeed %s", quotef (arg));
+}
   if (type == output_speed || type == both_speeds)
-cfsetospeed (mode, baud);
+{
+  if (cfsetospeed (mode, baud))
+die (EXIT_FAILURE, 0, "unsupported ospeed %s", quotef (arg));
+}
 }
 
 #ifdef TIOCGWINSZ
diff --git a/tests/misc/stty-invalid.sh b/tests/misc/stty-invalid.sh
index 58e51311d..af49b8d89 100755
--- a/tests/misc/stty-invalid.sh
+++ b/tests/misc/stty-invalid.sh
@@ -50,6 +50,9 @@ if tty -s 

Bug#1018796: mir-core: FTBFS with gdc: unrecognized commandline option -preview=dip1008

[Steve Langasek]

Package: mir-core
Version: 1.1.111-1
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Matthias,

The mir-core package is failing to build on all gdc archs in unstable
because meson.build includes a compiler option, '-preview=dip1008', which is
ldc-specific and not understood by gdc.

Patching this option out lets the package build on all archs, including
those using ldc, so it doesn't appear to be needed.

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
diff -Nru mir-core-1.1.111/debian/patches/drop-non-portable-option.patch 
mir-core-1.1.111/debian/patches/drop-non-portable-option.patch
--- mir-core-1.1.111/debian/patches/drop-non-portable-option.patch  
1969-12-31 16:00:00.0 -0800
+++ mir-core-1.1.111/debian/patches/drop-non-portable-option.patch  
2022-08-30 15:48:27.0 -0700
@@ -0,0 +1,17 @@
+Description: Don't pass -preview= to the compiler
+ This option is understood by ldc and not by gdc, and is not required in order
+ for the package to build.
+Author: Steve Langasek 
+Last-Update: 2022-08-30
+Forwarded: no
+
+--- mir-core-1.1.111.orig/meson.build
 mir-core-1.1.111/meson.build
+@@ -37,7 +37,6 @@ foreach s : sources_list
+ endforeach
+ 
+ add_project_arguments([
+-'-preview=dip1008',
+ '-lowmem',
+ ], language: 'd')
+ 
diff -Nru mir-core-1.1.111/debian/patches/series 
mir-core-1.1.111/debian/patches/series
--- mir-core-1.1.111/debian/patches/series  1969-12-31 16:00:00.0 
-0800
+++ mir-core-1.1.111/debian/patches/series  2022-08-30 15:47:47.0 
-0700
@@ -0,0 +1 @@
+drop-non-portable-option.patch

Bug#1018794: RFP: fx -- terminal JSON viewer

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: fx
  Version : 24.0.0
  Upstream Author : Anton Medvedev 
* URL : https://github.com/antonmedv/fx
* License : MIT
  Programming Lang: Go
  Description : terminal JSON viewer

Function eXecution (fx) is a terminal JSON viewer which includes these
features:

- Mouse support
- Streaming support
- Preserves key order
- Preserves big numbers

Bug#1018795: dh-dlang: support for mapping dpkg-buildflags for ldc but it's not used

[Steve Langasek]

Package: dh-dlang
Version: 0.6.5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Matthias,

I noticed in Ubuntu when trying to rebuild most packages against ldc 1.30.0
that they were now failing to build with current dh-dlang, because including
/usr/share/dh-dlang/dlang-flags.mk caused dpkg-buildflags' LDFLAGS to be
exported and these flags are not understood by ldc (specifically:
-Wl,-Bsymbolic-functions and -Wl,-z,relro on Ubuntu).  This can be seen in
Debian in the failed build of gir-to-d:

[...]
../meson.build:1:0: ERROR: Unable to detect linker for compiler `ldc2 
-L=--version /tmp/tmpsh_a2h39.d -Wl,-z,relro -O -g -release -wi --allinst`
stdout: 
stderr: ldc2: Unknown command line argument '-Wl,-z,relro'.  Try: 'ldc2 --help'
ldc2: Did you mean '--icp-lto'?
[...]

  
(https://buildd.debian.org/status/fetch.php?pkg=gir-to-d=amd64=0.22.0-3%2Bb1=1661202072=0)

Paradoxically, there is support in dh-dlang for mapping these flags for ldc,
but this support is not included automatically in dlang-flags.mk.

I've applied the attached patch in Ubuntu, which fixes the build problem.

Thanks for considering,
-- 
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
diff -Nru dh-dlang-0.6.5build2/dlang-flags.mk 
dh-dlang-0.6.5ubuntu1/dlang-flags.mk
--- dh-dlang-0.6.5build2/dlang-flags.mk 2019-09-29 12:14:32.0 -0700
+++ dh-dlang-0.6.5ubuntu1/dlang-flags.mk2022-08-30 10:09:35.0 
-0700
@@ -34,5 +34,8 @@
 endif
 endif
 endif
+
+include /usr/share/dh-dlang/ldc-transform-ldflags.mk
+
 export DFLAGS
 export DC

Bug#650783:

[Roberta Castellanos]

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Andreas Beckmann]

Followup-For: Bug #1009915
Control: found -1 3.05-1

Hi,

there seems to be one manpage (in bootlogd) missing conflict handling:

/usr/share/man/fr/man8/bootlogd.8.gz


  Preparing to unpack .../bootlogd_3.05-1_amd64.deb ...
  Unpacking bootlogd (3.05-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/bootlogd_3.05-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/fr/man8/bootlogd.8.gz', which is also in 
package manpages-fr 4.15.0-7
  Errors were encountered while processing:
   /var/cache/apt/archives/bootlogd_3.05-1_amd64.deb


Andreas

PS: Please don't consider using Replaces without corresponding Breaks,
the "lost files" after removal are likely spotted by some ci/piuparts
tests resulting in RC bugs.

Bug#1018793: bugs.debian.org: bad bug log for bugs #1017177 to #1017182

[IOhannes m zmoelnig]

Package: bugs.debian.org
Severity: important

Dear Maintainer,

it seems that bugs #1017177 to #1017182 (incl) are unavailable for browsing (and
possibly other things as well).

the error i get when accessing them via the webinterface is something like:
>  An error occurred. Error was: Bad bug log for Bug 1017181. Unable to read 
> records: state kill-init at end at /usr/local/lib/site_perl/Debbugs/Log.pm 
> line 320.

this esp. annoying, as one of my packages has an RC-critical bug in this range,
and I cannot even access the info about what failed.
(I'm also afraid, that i won't be able to close the bug if the database is
corrupted).

Bug#1018788: override: rsyslog:admin/optional

[Cyril Brulebois]

Ansgar  (2022-08-30):
> Yes. Changing the Priority in unstable will automatically propagate to
> testing, but (old)stable will be unaffected.

Perfect, thanks for the confirmation!


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


signature.asc
Description: PGP signature

Bug#1018788: override: rsyslog:admin/optional

[Ansgar]

On Tue, 2022-08-30 at 23:23 +0200, Cyril Brulebois wrote:
> No objections from my side, but I'd like to check something: overrides
> are per suite, and should only change for testing/unstable/experimental,
> not for stable, when acting on such requests, right?

Yes. Changing the Priority in unstable will automatically propagate to
testing, but (old)stable will be unaffected.

Ansgar

Bug#1018792: python3-flox: ships /usr/lib/python3/dist-packages/benchmarks/*.py

[Andreas Beckmann]

Package: python3-flox
Version: 0.5.9-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

python3-flox ships /usr/lib/python3/dist-packages/benchmarks/*.py
causing file conflicts with packages doing the same mistake.

These should probably not be shipped in the package at all or moved to a
package specific subdirectory.


Andreas

Bug#1018788: override: rsyslog:admin/optional

[Cyril Brulebois]

Hi,

Michael Biebl  (2022-08-30):
> as discussed in [1], I'd like to see the priority of rsyslog demoted
> from important to optional.
> We've been shipping with a persistent journal since bullseye and no
> major issues have been reported since then and the feedback has been
> positive so far.
> 
> Copying the rationale from this email:
> 
> The main reason here is, that I want to avoid that log data is stored twice 
> on disk.
> 
> What exactly would this mean going forward:
> 
> - Existing systems will continue to have rsyslog installed (but they can
>   safely uninstall rsyslog)
> 
> - Newly installed systems will no longer have rsyslog installed, unless
>   some other package Depends on either rsyslog | system-log-daemon. But
>   my recommendation is, that individual packages do not have a
>   Depends/Recommends: rsyslog | system-log-daemon unless it is really
>   crucial to their operation. Journald does provide /dev/log and a
>   syslog() api call will make sure the log message ends up on persistent
>   storage.
> 
> - If you prefer rsyslog on a systemd-based system you can easily install
>   rsyslog and it will continue to work as-is.
> 
> 
> There wasn't that much feedback on this RFC, but no objection afaics, so
> I'd like to proceed with this plan.
> 
> Regards,
> Michael
> 
> 
> [1] https://lists.debian.org/debian-devel/2021/11/msg00179.html

No objections from my side, but I'd like to check something: overrides
are per suite, and should only change for testing/unstable/experimental,
not for stable, when acting on such requests, right?

A quick look at coccia's scripts/override/override.* suggests so, but
I'm asking anyway: a bunch of packages in the default set are a no
brainer, but I expect many admins to have some deployment code that
acts on rsyslog, either configuring it in some specific ways, or getting
rid of it… I wouldn't want stable to get a different set of packages
overnight, esp. if it comes via archive metadata updates, rather than
via some package updates.


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


signature.asc
Description: PGP signature

Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Antoine Beaupré]

Control: reassign -1 src:puppet

On 2022-08-25 14:19:42, Antoine Beaupré wrote:

[...]

> For what it's worth, I have tested lavamind's Puppet 7 package from
> experimental, on bookworm, and it works fine:
>
> https://tracker.debian.org/pkg/puppet-agent
>
> ... I am not sure how to express this in the BTS here, because it's a
> different source package, so I can't mark it as fixed there without
> first marking it as affecting that other package, but it never affected
> it.

The correct way seems to be to move this bug report back to src:puppet
where it belongs, which this message should do.

-- 
A man is none the less a slave because he is allowed to choose a new
master once in a term of years.
 - Lysander Spooner

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

[Andreas Beckmann]

Followup-For: Bug #998820

and that:

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

(found in python3-pymodbus (2.1.0+dfsg-2) (bullseye) and
python3-astroalign (2.4.1-2) (sid))


Andreas

Bug#1017794: glib2.0: 2.73 breaks modemmanager

[Jeremy Bicha]

Control: notfound -1 2.72.3-1
Control: tags -1 +bookworm sid

Retitled and more importantly, marking it as not found in Testing so
hopefully britney will notice this issue before migrating glib
tonight.

Thank you,
Jeremy Bicha

Bug#1018791: python3-astroalign: overly generic python module name: /usr/lib/python3/dist-packages/ez_setup.py

[Andreas Beckmann]

Package: python3-astroalign
Version: 2.4.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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


Andreas

Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1

[Thomas Uhle]

Tags: patch

Dear maintainers,

I have prepared a patch for changing the order in which the libraries 
are built and to fix linking.


Best regards,

Thomas UhleDescription: Fix build order and linking of libraries
Author: Thomas Uhle
Bug-Debian: https://bugs.debian.org/889114

--- dbus-c++-0.9.0.orig/src/Makefile.am
+++ dbus-c++-0.9.0/src/Makefile.am
@@ -37,6 +37,7 @@
 	$(ecore_CFLAGS)
 
 SUBDIRS = \
+	. \
 	integration
 
 HEADER_DIR  = $(top_srcdir)/include/dbus-c++
--- dbus-c++-0.9.0.orig/src/integration/ecore/Makefile.am
+++ dbus-c++-0.9.0/src/integration/ecore/Makefile.am
@@ -11,6 +11,7 @@
 	-Wno-unused-parameter
 
 libdbus_c___ecore_1_la_LIBADD = \
+	$(top_builddir)/src/libdbus-c++-1.la \
 	$(dbus_LIBS) \
 	$(ecore_LIBS)
 
--- dbus-c++-0.9.0.orig/src/integration/glib/Makefile.am
+++ dbus-c++-0.9.0/src/integration/glib/Makefile.am
@@ -11,6 +11,7 @@
 	-Wno-unused-parameter
 
 libdbus_c___glib_1_la_LIBADD = \
+	$(top_builddir)/src/libdbus-c++-1.la \
 	$(dbus_LIBS) \
 	$(glib_LIBS)
 

Bug#1018289: perl: FTBFS on hurd-i386: NDBM not getting linked against libgdbm-compat

[Niko Tyni]

Control: tag -1 confirmed upstream

On Sun, Aug 28, 2022 at 01:41:48PM +0200, Samuel Thibault wrote:
> Package: perl
> Version: 5.34.0-5
> Severity: important

> perl currently FTBFS on hurd-i386: 

> # Error:  Can't load '../../lib/auto/NDBM_File/NDBM_File.so' for module 
> NDBM_File: ../../lib/auto/NDBM_File/NDBM_File.so: undefined symbol: 
> dbm_nextkey at ../../lib/XSLoader.pm line 93.
> #   at ../../lib/NDBM_File.pm line 12.

> Notably on hurd there aren't the "harmless" messages about -ldbm ; it's
> supposed to use -lgdbm_compat, as hinted from hints/linux.pl, sourced
> from hints/gnu.pl, but for some reason this isn't working any more?

I think this broke with

  https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/367

but nobody noticed until now.

All the hints files used to get loaded with 'do', which limits scope so
that local variables ("my $var") aren't visible. The $self hash that the
hints usually modify was a local variable ("our $self") to overcome this.

The commit above changed the normal loading to use 'eval', which removed
the visibility problem, and changed the $self variable to a local
variable, presumably to make things cleaner now that it was possible.

Unfortunately hints/gnu.pl is still loading linux.pl with 'do', so $self
isn't visible anymore and the resulting hints have no effect.

A simple 'grep -w do' indicates there's a dozen affected files with the
same pattern (and a couple of false positives removed manually):

  ext/NDBM_File/hints/gnu.pl
  ext/NDBM_File/hints/gnukfreebsd.pl
  ext/NDBM_File/hints/gnuknetbsd.pl
  ext/ODBM_File/hints/gnu.pl
  ext/ODBM_File/hints/gnukfreebsd.pl
  ext/ODBM_File/hints/gnuknetbsd.pl
  ext/POSIX/hints/gnukfreebsd.pl
  ext/POSIX/hints/gnuknetbsd.pl
  ext/DynaLoader/hints/gnukfreebsd.pl
  ext/DynaLoader/hints/gnuknetbsd.pl
  dist/Storable/hints/gnukfreebsd.pl
  dist/Storable/hints/gnuknetbsd.pl

Something like this works but seems rather wordy and
silly to repeat in all of those:

--
  my $hint_file = 'hints/linux.pl';
  open(my $fh, '<', $hint_file)
  or die "Could not open $hint_file for read: $!";
  eval join('', <$fh>);
  die "Failed to load hint file $hint_file: $@" if $@;
--

Guess I'll sleep on this and try to come up with something better.
-- 
Niko

Bug#1017794: glib2.0: Upload 2.73 to Unstable

[Matteo F. Vescovi]

Hi Jeremy!

On 2022-08-30 at 16:44 (-04), Jeremy Bicha wrote:
> I think it's a little better if you opened a new bug so that it would
> have a better title, but not a big deal.

;-) I'm too lazy.

> Does glib2.0 2.73.3-3 uploaded today work better for you?

I tested, but the issue remains.
I 've also set the 'forwarded' field pointing to the upstream issue on
glib2.0 where modemmanager developer explains the problem.

> We did notice that modemmanager's build tests are failing now.
>
> https://launchpad.net/ubuntu/+source/modemmanager/1.19~git20220825-0ubuntu1

ACK, noticed. I could try to rebuild modemmanager disabling tests for
the sake of completeness.

Let me know if I can help you somehow on triaging this.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#1017794: glib2.0: Upload 2.73 to Unstable

[Jeremy Bicha]

On Tue, Aug 30, 2022 at 4:32 PM Matteo F. Vescovi  wrote:
> > We have one blocker bug to fix before we can upload glib 2.73 to Unstable.
>
> [...]
>
> Since the upload of 2.73.x to unstable/sid, modemmanager has started
> crashing with core dump (see [1] for an example).
>
> As a test, I've downgraded to 2.72.3 (former version in unstable/sid)
> and modemmanager has started working fine again.
>
> Thus, I'm raising the severity of this bug report to avoid the migration
> of 2.73.x to testing.

I think it's a little better if you opened a new bug so that it would
have a better title, but not a big deal.

Does glib2.0 2.73.3-3 uploaded today work better for you?

We did notice that modemmanager's build tests are failing now.

https://launchpad.net/ubuntu/+source/modemmanager/1.19~git20220825-0ubuntu1

Thank you,
Jeremy Bicha

Bug#1018790: coreutils: stty: "ispeed anything" is valid and doesn't seem to do anything

[наб]

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

stty ispeed and ospeed don't seem to check that the speed is valid:
-- >8 --
$ LD_PRELOAD=$PWD/dumpispeed.so stty ispeed 420
cfsetispeed(0xPOINTER, 4294967295)=-1

$ LD_PRELOAD=$PWD/dumpispeed.so stty ispeed 57600
cfsetispeed(0xPOINTER, 4097)=0
-- >8 --

Compare bare speeds:
-- >8 --
$ stty 420
stty: invalid argument 420
Try 'stty --help' for more information.

$ stty 57600
-- >8 --

Best,
наб

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1017794: glib2.0: Upload 2.73 to Unstable

[Matteo F. Vescovi]

Control: severity -1 serious
Control: affects -1 modemmanager

On 2022-08-20 at 12:49 (-04), Jeremy Bicha wrote:
> Source: glib2.0
> Version: 2.72.3-1
>
> We have one blocker bug to fix before we can upload glib 2.73 to Unstable.

[...]

Since the upload of 2.73.x to unstable/sid, modemmanager has started
crashing with core dump (see [1] for an example).

As a test, I've downgraded to 2.72.3 (former version in unstable/sid)
and modemmanager has started working fine again.

Thus, I'm raising the severity of this bug report to avoid the migration
of 2.73.x to testing.

Thanks for any support in fixing this.

[1] https://people.debian.org/~mfv/mm+glib2.log

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#1018789: openrazer: autopkgtest regression: openrazer-driver/3.4.0 failed to build for 5.18.0-4-cloud-amd64

[Paul Gevers]

Source: openrazer
Version: 3.4.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
openrazer  from testing3.4.0+dfsg-1
all others from testingfrom testing

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

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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openrazer/25469803/log.gz

I: Removing binary package openrazer-driver-dkms, to get clean state
I: Installing binary package openrazer-driver-dkms
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  udev
The following NEW packages will be installed:
  openrazer-driver-dkms udev
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 1717 kB of archives.
After this operation, 11.0 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian testing/main amd64 udev amd64 251.3-1 
[1656 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 
openrazer-driver-dkms all 3.4.0+dfsg-1 [60.9 kB]

debconf: delaying package configuration, since apt-utils is not installed
Fetched 1717 kB in 0s (32.0 MB/s)
Selecting previously unselected package udev.
(Reading database ... (Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 30129 files and directories currently installed.)
Preparing to unpack .../udev_251.3-1_amd64.deb ...
Unpacking udev (251.3-1) ...
Selecting previously unselected package openrazer-driver-dkms.
Preparing to unpack .../openrazer-driver-dkms_3.4.0+dfsg-1_all.deb ...
Unpacking openrazer-driver-dkms (3.4.0+dfsg-1) ...
Setting up udev (251.3-1) ...
Setting up openrazer-driver-dkms (3.4.0+dfsg-1) ...
autoinstall for dkms modules has been disabled.
I: Checking for missing dkms dependency by trying to deinstall dkms
dpkg: dependency problems prevent removal of dkms:
 openrazer-driver-dkms depends on dkms (>= 2.1.0.0).

dpkg: error processing package dkms (--remove):
 dependency problems - not removing
Errors were encountered while processing:
 dkms
I: No Linux header packages are installed.
I: Installing all available ones from src:linux 5.18.16-1:
I:   install linux-headers-5.18.0-4-amd64
I:   install linux-headers-5.18.0-4-cloud-amd64
I:   install linux-headers-5.18.0-4-rt-amd64
I:   skiplinux-headers-amd64
I:   skiplinux-headers-cloud-amd64
I:   skiplinux-headers-rt-amd64
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  cpp-11 gcc-11 gcc-11-base libasan6 libgcc-11-dev libtsan0
  linux-compiler-gcc-11-x86 linux-headers-5.18.0-4-common
  linux-headers-5.18.0-4-common-rt linux-kbuild-5.18
Suggested packages:
  gcc-11-locales gcc-11-multilib gcc-11-doc
Recommended packages:
  libc6-dev
The following NEW packages will be installed:
  cpp-11 gcc-11 gcc-11-base libasan6 libgcc-11-dev libtsan0
  linux-compiler-gcc-11-x86 linux-headers-5.18.0-4-amd64
  linux-headers-5.18.0-4-cloud-amd64 linux-headers-5.18.0-4-common
  linux-headers-5.18.0-4-common-rt linux-headers-5.18.0-4-rt-amd64
  linux-kbuild-5.18
0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 55.3 MB of archives.
After this operation, 220 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian testing/main amd64 gcc-11-base amd64 
11.3.0-5 [209 kB]
Get:2 http://deb.debian.org/debian testing/main amd64 cpp-11 amd64 
11.3.0-5 [9155 kB]
Get:3 http://deb.debian.org/debian testing/main amd64 libasan6 amd64 
11.3.0-5 [2050 kB]
Get:4 http://deb.debian.org/debian testing/main amd64 libtsan0 amd64 
11.3.0-5 [2017 kB]
Get:5 http://deb.debian.org/debian testing/main amd64 libgcc-11-dev 
amd64 11.3.0-5 [2361 kB]
Get:6 http://deb.debian.org/debian testing/main amd64 gcc-11 amd64 
11.3.0-5 [18.2 MB]
Get:7 http://deb.debian.org/debian testing/main amd64 

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Paul Gevers]

Hi Simon, all,

On 30-08-2022 14:48, Simon McVittie wrote:

If armel is a candidate for being a release architecture, then I think
that leaves two-and-a-half options:


In the last couple of releases, we have been bad at taking decisions on 
this front, so lets assume it is (although this issue is another push in 
the direction of dropping).



1. task-gnome-desktop is uninstallable on this architecture


I have briefly checked with kibi on IRC and we currently think this is 
acceptable.



   1a. or Bastien's suggestion: task-gnome-desktop is installable on this
   architecture, but the preinst fails on baseline CPUs
2. task-gnome-desktop installs something that is not the full GNOME
desktop on this architecture

I would personally prefer 1., but last time I tried this (for s390x),
it was blocked by the release machinery not allowing any task package to
be uninstallable on any release architecture, even if the task doesn't
really make sense there. So I am going to work towards 2., unless the
release team tells me that 1. can be made to work.


So, it'd say, let's try if we can do that (1). Looking at bug #906016 
IIUC it was mostly stalled on some input from our side, not really 
because of machinery being unpersuasive.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

[Rafael Laboissière]

Control: tags -1 moreinfo

* Sylvain Joubert  [2022-03-02 11:17]:


 Package: libmgl-dev
 Version: 8.0.1-1
 Severity: normal

Dear Maintainer,

Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm facing the 
following error:


 CMake Error at 
/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230
 (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS 
OpenMP_CXX_LIB_NAMES)
 Call Stack (most recent call first):
 /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594
 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544
 (find_package_handle_standard_args)
  /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47
 (find_package)
  /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency)
 [...]

It appears the libmgl-dev package is missing a dependency on an OpenMP 
related package. Installing libomp-dev fixes the issue though I'm not 
sure this is the correct package to depend on.


Thank you for the bug report.

Could you please provide an example that trigger the bug? For 
inspiration, look at Bug #1004218 [1] or #1004219 [2].


Best,

Rafael Laboissière

 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004218
 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004219

Bug#1018788: override: rsyslog:admin/optional

[Michael Biebl]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: debian-b...@lists.debian.org


Hi,

as discussed in [1], I'd like to see the priority of rsyslog demoted
from important to optional.
We've been shipping with a persistent journal since bullseye and no
major issues have been reported since then and the feedback has been
positive so far.

Copying the rationale from this email:

The main reason here is, that I want to avoid that log data is stored twice on 
disk.

What exactly would this mean going forward:

- Existing systems will continue to have rsyslog installed (but they can
  safely uninstall rsyslog)

- Newly installed systems will no longer have rsyslog installed, unless
  some other package Depends on either rsyslog | system-log-daemon. But
  my recommendation is, that individual packages do not have a
  Depends/Recommends: rsyslog | system-log-daemon unless it is really
  crucial to their operation. Journald does provide /dev/log and a
  syslog() api call will make sure the log message ends up on persistent
  storage.

- If you prefer rsyslog on a systemd-based system you can easily install
  rsyslog and it will continue to work as-is.


There wasn't that much feedback on this RFC, but no objection afaics, so
I'd like to proceed with this plan.

Regards,
Michael


[1] https://lists.debian.org/debian-devel/2021/11/msg00179.html

Bug#1017541: auditd: Fails to generate/log events after systemd upgrade

[Michael Biebl]

Am 30.08.22 um 19:46 schrieb Michael Biebl:


Am 30.08.22 um 19:31 schrieb Michael Biebl:

On Wed, 17 Aug 2022 19:17:16 +0200 Sven Mueller  wrote:


It's reproducible only with systemd upgrades. We've reproduced it with
different versions of systemd, but always upgrading from 249.7-1 to
the version tested.


I assume this reproducer can be further reduced to

systemctl restart systemd-journald

? (which is part of systemd.postinst)


Could you check if replacing
debian/patches/Don-t-enable-audit-by-default.patch with the attached 
patch helps?


It was pointed out on IRC that we probably need to initialize the value 
with -1 (so it is "unset") instead of simply removing the line.
From: Martin Pitt 
Date: Sun, 28 Dec 2014 12:49:35 +0100
Subject: Don't enable audit by default

It causes flooding of dmesg and syslog, suppressing actually important
messages.

Don't enable it for now, until a better solution is found:
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026591.html

Bug-Debian: https://bugs.debian.org/773528
---
 man/journald.conf.xml | 2 +-
 src/journal/journald-server.c | 2 +-
 src/journal/journald.conf | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index ed7e428..0abed9c 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -426,7 +426,7 @@
 systemd-journald collects generated audit records, it just controls whether it
 tells the kernel to generate them. This means if another tool turns on auditing even if
 systemd-journald left it off, it will still collect the generated
-messages. Defaults to on.
+messages. Defaults to unset.
   
 
   
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 3ed8b80..5d373f4 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -2293,7 +2293,7 @@ int server_init(Server *s, const char *namespace) {
 .compress.threshold_bytes = UINT64_MAX,
 .seal = true,
 
-.set_audit = true,
+.set_audit = -1,
 
 .watchdog_usec = USEC_INFINITY,
 
diff --git a/src/journal/journald.conf b/src/journal/journald.conf
index 64f4d4b..a690681 100644
--- a/src/journal/journald.conf
+++ b/src/journal/journald.conf
@@ -44,4 +44,4 @@
 #MaxLevelWall=emerg
 #LineMax=48K
 #ReadKMsg=yes
-#Audit=yes
+#Audit=


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018787: horizon: autopkgtest failure: horizon.test.unit.test_base.RbacHorizonTests

[Paul Gevers]

Source: horizon
Version: 3:22.1.0-5
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package horizon, great. 
However, it fails on amd64, i386 and armhf. Currently this failure is 
blocking the migration to testing [1]. Can you please investigate the 
situation and fix it?


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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/h/horizon/24859919/log.gz

=== FAILURES 
===
__ RbacHorizonTests.test_rbac_panels 
___

[gw20] linux -- Python 3.10.6 /usr/bin/python3

self = testMethod=test_rbac_panels>


def test_rbac_panels(self):
context = {'request': self.request}
cats = horizon.get_dashboard("cats")
self.assertEqual(cats._registered_with, base.Horizon)

  self.assertQuerysetEqual(cats.get_panels(),

 [''])

horizon/test/unit/test_base.py:547: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/django/test/testcases.py:1072: in 
assertQuerysetEqual

return self.assertEqual(list(items), values, msg=msg)
E   AssertionError: Lists differ: ['', 'tigers>', ''] != ['']

E   E   First differing element 0:
E   ''
E   ''
E   E   First list contains 2 additional elements.
E   First extra element 1:
E   ''
E   E   - ['', '', '']
E   + ['']


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018786: numba: autopkgtest needs update for new version of llvmlite: The module `llvmlite.llvmpy` is deprecated

[Paul Gevers]

Source: numba
Version: 0.55.2+dfsg-1
Severity: serious
X-Debbugs-CC: llvml...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:llvmlite

Dear maintainer(s),

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


   passfail
llvmlite   from testing0.39.0-1
numba  from testing0.55.2+dfsg-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of llvmlite to 
testing [1]. Of course, llvmlite shouldn't just break your autopkgtest 
(or even worse, your package), but it seems to me that the change in 
llvmlite was intended and your package needs to update to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from llvmlite should really 
add a versioned Breaks on the unfixed version of (one of your) 
package(s). Note: the Breaks is nice even if the issue is only in the 
autopkgtest as it helps the migration software to figure out the right 
versions to combine in the tests.


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/n/numba/25502711/log.gz

==
FAIL: test_no_accidental_warnings (numba.tests.test_import.TestNumbaImport)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/numba/tests/test_import.py", 
line 103, in test_no_accidental_warnings

run_in_subprocess(code, flags)
  File "/usr/lib/python3/dist-packages/numba/tests/support.py", line 
1014, in run_in_subprocess

raise AssertionError(msg % (popen.returncode, err.decode()))
AssertionError: process failed with code 1: stderr follows
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/numba/__init__.py", line 38, in 

from numba.core.decorators import (cfunc, generated_jit, jit, njit, 
stencil,
  File "/usr/lib/python3/dist-packages/numba/core/decorators.py", line 
12, in 

from numba.stencils.stencil import stencil
  File "/usr/lib/python3/dist-packages/numba/stencils/stencil.py", line 
11, in 
from numba.core import types, typing, utils, ir, config, ir_utils, 
registry
  File "/usr/lib/python3/dist-packages/numba/core/ir_utils.py", line 
16, in 

from numba.core.extending import _Intrinsic
  File "/usr/lib/python3/dist-packages/numba/core/extending.py", line 
19, in 
from numba.core.pythonapi import box, unbox, reflect, NativeValue 
# noqa: F401
  File "/usr/lib/python3/dist-packages/numba/core/pythonapi.py", line 
8, in 

from llvmlite.llvmpy.core import Type, Constant
  File "/usr/lib/python3/dist-packages/llvmlite/llvmpy/__init__.py", 
line 3, in 

warnings.warn(
UserWarning: The module `llvmlite.llvmpy` is deprecated and will be 
removed in the future.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018785: Problem with python3-dolfinx-real or libfftw3_mpi.so.3

[Torquil Macdonald Sørensen]

Package: python3-dolfinx-real
Version: 1:0.4.1-4+b1

If I try to import the dolfinx package in a python3 session, I get the 
following error:

$ python3
Python 3.10.6 (main, Aug 10 2022, 11:19:32) [GCC 12.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import dolfin

Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'dolfin'

import dolfinx

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/petsc/lib/python3/dist-packages/dolfinx/__init__.py", line 33, in 

from dolfinx import common
  File "/usr/lib/petsc/lib/python3/dist-packages/dolfinx/common.py", line 10, in 

from dolfinx import cpp as _cpp
ImportError: /usr/lib/x86_64-linux-gnu/libfftw3_mpi.so.3: undefined symbol: 
fftw_join_taint




I'm not sure if this is a problem with python3-dolfinx-real or libfftw3-mpi3. 
Please reassign
if necessary. I have libfftw3-mpi3 version 3.3.8-2 installed.

Best regards,
Torquil Sørensen

Bug#1018784: src:haskell-unbounded-delays: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: haskell-unbounded-delays
Version: 0.1.1.0-4
Severity: serious
Control: close -1 0.1.1.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:haskell-unbounded-delays has been trying 
to migrate for 77 days [2]. Hence, I am filing this bug. Judging from 
the name of your package I assume your package is part of the unfinished 
ghc transition.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018783: src:haskell-unliftio: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: haskell-unliftio
Version: 0.2.13-1
Severity: serious
Control: close -1 0.2.22.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:haskell-unliftio has been trying to 
migrate for 77 days [2]. Hence, I am filing this bug. Judging from the 
name of your package I assume your package is part of the unfinished ghc 
transition.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018782: src:haskell-unliftio-core: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: haskell-unliftio-core
Version: 0.1.2.0-3
Severity: serious
Control: close -1 0.2.0.1-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:haskell-unliftio-core has been trying to 
migrate for 77 days [2]. Hence, I am filing this bug. Judging from the 
name of your package I assume your package is part of the unfinished ghc 
transition.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018780: src:haskell-transformers-compat: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: haskell-transformers-compat
Version: 0.6.5-2
Severity: serious
Control: close -1 0.6.6-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:haskell-transformers-compat has been 
trying to migrate for 77 days [2]. Hence, I am filing this bug. Judging 
from the name of your package I assume your package is part of the 
unfinished ghc transition.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018781: src:haskell-transformers-compat: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: haskell-transformers-compat
Version: 0.6.5-2
Severity: serious
Control: close -1 0.6.6-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:haskell-transformers-compat has been 
trying to migrate for 77 days [2]. Hence, I am filing this bug. Judging 
from the name of your package I assume your package is part of the 
unfinished ghc transition.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018777: pari-nflistdata: Unhandled data compression by dh_compress

[Bill Allombert]

On Tue, Aug 30, 2022 at 02:28:57PM -0400, Boyuan Yang wrote:
> Package: pari-nflistdata
> Version: 0.20220729-1
> Severity: important
> X-Debbugs-CC: ballo...@debian.org
> 
> Dear Debian pari-nflistdata package maintainer,
> 
> As seen in https://packages.debian.org/sid/all/pari-nflistdata/filelist ,
> some files are compressed into .gz file (QT --> QT.gz). I believe this is
> due to automatic compression made by dh_compress.

> The unhandled compression may make these data unavailable if the
> uncompressed version were to be used. Please consider adjusting the
> compression handling in debian/rules file.

Dear Boyuan,

I am not sure why you are reporting this bug:

1/ dh_compress do not compress files in /usr/share/pari by itself.

2/ debian/rules says explicitely:

find debian/pari-nflistdata/usr/share/pari/nflistdata  -type f -size 
+4096c \
 -execdir gzip --no-name --best {} \;

3/ The program reading this data (which is no yet in Debian by the way) will 
uncompress
any .gz file it reads transparently.

Compressing those files saves a lot of diskspace, we should not scare 
maintainers away
from compressing files.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1018778: pari-nflistdata: Source-only upload needed

[Bill Allombert]

On Tue, Aug 30, 2022 at 02:31:10PM -0400, Boyuan Yang wrote:
> Source: pari-nflistdata
> Version: 0.20220729-1
> Severity: normal
> X-Debbugs-CC: ballo...@debian.org
> 
> Dear Debian pari-nflistdata package maintainer,
> 
> According to https://tracker.debian.org/pkg/pari-nflistdata , your package
> did not migrate to Debian Testing due to maintainer-built arch:all deb
> package. Please consider making another source-only upload to allow the
> package to migrate to Debian testing.

I know, I did not expext the packqge to clear the NEW queue so quickly :)

But this package is not needed until pari is upgraded to 2.15.0 which is
not released yet. So I will reupload it at the same time as PARI 2.15.0.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1018779: nouveau DRM: Failure to read SCDC_TMDS_CONFIG: -6 error message

[Franco Martelli]

Package: linux-image-amd64
Version: 5.10.136-1



I recently bought a new monitor the cheap HP M24f 2D9K0AA and connected 
via HDMI port to the NVIDIA GeForce GT 630 card.
When I switch twice virtual terminal (CTRL-ALT-F2 - CTRL-ALT-F7) it 
happens that the kernel pollutes the VT screen with this error message:


Debian GNU/Linux 11 itek tty2

itek login: [  307.941844] nouveau :01:00.0: DRM: Failure to read 
SCDC_TMDS_CONFIG: -6





the output of dmesg is:

~# dmesg | grep nouveau
[8.591801] nouveau :01:00.0: vgaarb: deactivate vga console
[8.592698] nouveau :01:00.0: NVIDIA GK208 (108040a1)
[8.658134] nouveau :01:00.0: bios: version 80.28.3e.00.05
[8.658718] nouveau :01:00.0: fb: 2048 MiB DDR3
[9.966104] nouveau :01:00.0: DRM: VRAM: 2048 MiB
[9.966105] nouveau :01:00.0: DRM: GART: 1048576 MiB
[9.966108] nouveau :01:00.0: DRM: TMDS table version 2.0
[9.966109] nouveau :01:00.0: DRM: DCB version 4.0
[9.966111] nouveau :01:00.0: DRM: DCB outp 00: 01000f02 00020030
[9.966112] nouveau :01:00.0: DRM: DCB outp 01: 02011f62 00020010
[9.966114] nouveau :01:00.0: DRM: DCB outp 02: 02022f10 
[9.966115] nouveau :01:00.0: DRM: DCB conn 00: 1031
[9.966116] nouveau :01:00.0: DRM: DCB conn 01: 2161
[9.966117] nouveau :01:00.0: DRM: DCB conn 02: 0200
[9.966497] nouveau :01:00.0: DRM: MM: using COPY for buffer copies
[   10.079553] snd_hda_intel :01:00.1: bound :01:00.0 (ops 
nv50_audio_component_bind_ops [nouveau])
[   10.184971] nouveau :01:00.0: DRM: allocated 1920x1080 fb: 
0x8, bo 9fa1d316

[   10.185029] fbcon: nouveaudrmfb (fb0) is primary device
[   10.186483] nouveau :01:00.0: DRM: Failure to read 
SCDC_TMDS_CONFIG: -6
[   10.225696] nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame 
buffer device
[   10.253987] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 
on minor 0
[   25.624495] nouveau :01:00.0: DRM: Failure to read 
SCDC_TMDS_CONFIG: -6




my hardware details are:

~$ uname -a
Linux itek 5.10.0-17-amd64 #1 SMP Debian 5.10.136-1 (2022-08-13) x86_64 
GNU/Linux


~# lspci -knn
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI] 
RD9x0/RX980 Host Bridge [1002:5a14] (rev 02)
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 
Host Bridge [1002:5a14]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD/ATI] 
RD890S/RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 
I/O Memory Management Unit (IOMMU) [1002:5a23]
00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0) [1002:5a16]

DeviceName:  Onboard IGD
Kernel driver in use: pcieport
00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0) [1002:5a18]

Kernel driver in use: pcieport
00:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 1) [1002:5a19]

Kernel driver in use: pcieport
00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 2) [1002:5a1a]

Kernel driver in use: pcieport
00:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 3) [1002:5a1b]

Kernel driver in use: pcieport
00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40)
Subsystem: ASUSTeK Computer Inc. M5A99X EVO (R1.0) SB950 
[1043:84dd]

Kernel driver in use: ahci
Kernel modules: ahci
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]

Kernel driver in use: ohci-pci
Kernel modules: ohci_pci
00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]

Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]

Kernel driver in use: ohci-pci
Kernel modules: ohci_pci
00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
Subsystem: Advanced 

Bug#1018778: pari-nflistdata: Source-only upload needed

[Boyuan Yang]

Source: pari-nflistdata
Version: 0.20220729-1
Severity: normal
X-Debbugs-CC: ballo...@debian.org

Dear Debian pari-nflistdata package maintainer,

According to https://tracker.debian.org/pkg/pari-nflistdata , your package
did not migrate to Debian Testing due to maintainer-built arch:all deb
package. Please consider making another source-only upload to allow the
package to migrate to Debian testing.

Thanks,
Boyuan Yang


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

Bug#947925: ITP: Bubblemail gnome-shell -- Bubblemail unread mail notification service gnome-shell extension

[Bastian Germann]

Control: block -1 by 955188

Bug#966000: tag

[Antoine Beaupré]

On 2022-08-30 20:20:46, Bastian Germann wrote:
> Control: tags -1 - pending
>
> Am 30.08.22 um 20:12 schrieb Antoine Beaupré:
>> can you expand on how that ITP (forcemerged to #966000, in CC) is
>> pending? is it waiting in NEW or in salsa or something? :)
>
> It was waiting in NEW but was rejected. Francois wants to give it another try.

I figured as much, thanks for the update! :)

François, if you do give it another shot, please do document it here.

Thanks!

a.
-- 
It is not enough to fight for the land; it is even more important to
enjoy it. While you can. While it’s still here.
- Edward Abbey

Bug#1018777: pari-nflistdata: Unhandled data compression by dh_compress

[Boyuan Yang]

Package: pari-nflistdata
Version: 0.20220729-1
Severity: important
X-Debbugs-CC: ballo...@debian.org

Dear Debian pari-nflistdata package maintainer,

As seen in https://packages.debian.org/sid/all/pari-nflistdata/filelist ,
some files are compressed into .gz file (QT --> QT.gz). I believe this is
due to automatic compression made by dh_compress.

The unhandled compression may make these data unavailable if the
uncompressed version were to be used. Please consider adjusting the
compression handling in debian/rules file.

Thanks,
Boyuan Yang


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

Bug#966000: tag

[Bastian Germann]

Control: tags -1 - pending

Am 30.08.22 um 20:12 schrieb Antoine Beaupré:

can you expand on how that ITP (forcemerged to #966000, in CC) is
pending? is it waiting in NEW or in salsa or something? :)


It was waiting in NEW but was rejected. Francois wants to give it another try.

Bug#1018776: linux-image-5.18.0-4-686-pae Kernel panic on Pentium 3 and Athlon XP

[Marco Moock]

Package: src:linux
Version: 5.18.16-1
Severity: important
X-Debbugs-Cc: m...@posteo.de

Dear Maintainer,


   * What led up to the situation?
   Booting Kernel linux-image-5.18.0-4-686-pae on a Pentium 3 600
   (Coppermine) or an Athlon XP (I can find out the exact model
   number if you need). Older kernel versions work. The current
   kernel works on a Pentium 4 3 GHz (I can find out the exact model
   number if you need).
   Error message: https://picr.eu/images/2022/08/29/qUlKO.jpg
   German discussion in a newsgroup: 
https://de.comp.os.unix.linux.misc.narkive.com/JzfZxhgj/kernelpanic-5-18-0-4-686-pae-attempted-to-kill-the-idle-task
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Booting this specific kernel, older kernels work.
   * What was the outcome of this action?
   Kernel panic, can't boot system.
   * What outcome did you expect instead?
   Booting the system the nromal way on the specified hardware.



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host 
bridge [8086:7190] (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: agpgart-intel

00:01.0 PCI bridge [0604]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP 
bridge [8086:7191] (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
Reset- FastB2B+
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

00:10.0 Ethernet controller [0200]: 3Com Corporation 3c905C-TX/TX-M [Tornado] 
[10b7:9200] (rev 78)
Subsystem: 3Com Corporation 3C905CX-TX/TX-M Fast Etherlink for PC 
Management NIC [10b7:1000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: 3c59x
Kernel modules: 3c59x

00:14.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA 
[8086:7110] (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: mgag200
Kernel modules: matroxfb_base, mgag200


** USB devices:
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.18.0-3-686-pae (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-5.18.0-4-686-pae depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20220630-3
ii  linux-base  4.9

Versions of packages linux-image-5.18.0-4-686-pae recommends:
pn  apparmor 
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.18.0-4-686-pae suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-3
pn  linux-doc-5.18  

Versions of packages linux-image-5.18.0-4-686-pae is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#966000: tag

[Antoine Beaupré]

On 2022-07-07 13:32:32, Bastian Germann wrote:
> tags 1004401 pending

can you expand on how that ITP (forcemerged to #966000, in CC) is
pending? is it waiting in NEW or in salsa or something? :)

-- 
Choose a job you love and you will never have to work a day in your life.
 - Confucius

Bug#1017541: auditd: Fails to generate/log events after systemd upgrade

[Michael Biebl]

Am 30.08.22 um 19:31 schrieb Michael Biebl:

On Wed, 17 Aug 2022 19:17:16 +0200 Sven Mueller  wrote:


It's reproducible only with systemd upgrades. We've reproduced it with
different versions of systemd, but always upgrading from 249.7-1 to
the version tested.


I assume this reproducer can be further reduced to

systemctl restart systemd-journald

? (which is part of systemd.postinst)


Could you check if replacing
debian/patches/Don-t-enable-audit-by-default.patch with the attached 
patch helps?



Regards,
Michael
From: Martin Pitt 
Date: Sun, 28 Dec 2014 12:49:35 +0100
Subject: Don't enable audit by default

It causes flooding of dmesg and syslog, suppressing actually important
messages.

Don't enable it for now, until a better solution is found:
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026591.html

Bug-Debian: https://bugs.debian.org/773528
---
 man/journald.conf.xml | 2 +-
 src/journal/journald-server.c | 2 --
 src/journal/journald.conf | 2 +-
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index ed7e428..4de85be 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -426,7 +426,7 @@
 systemd-journald collects generated audit records, it just controls whether it
 tells the kernel to generate them. This means if another tool turns on auditing even if
 systemd-journald left it off, it will still collect the generated
-messages. Defaults to on.
+messages. Defaults to unset.
   
 
   
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 3ed8b80..ae4eeac 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -2293,8 +2293,6 @@ int server_init(Server *s, const char *namespace) {
 .compress.threshold_bytes = UINT64_MAX,
 .seal = true,
 
-.set_audit = true,
-
 .watchdog_usec = USEC_INFINITY,
 
 .sync_interval_usec = DEFAULT_SYNC_INTERVAL_USEC,
diff --git a/src/journal/journald.conf b/src/journal/journald.conf
index 64f4d4b..989a315 100644
--- a/src/journal/journald.conf
+++ b/src/journal/journald.conf
@@ -44,4 +44,4 @@
 #MaxLevelWall=emerg
 #LineMax=48K
 #ReadKMsg=yes
-#Audit=yes
+#Audit=


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017541: auditd: Fails to generate/log events after systemd upgrade

[Michael Biebl]

Am 30.08.22 um 19:46 schrieb Michael Biebl:

Could you check if replacing
debian/patches/Don-t-enable-audit-by-default.patch with the attached 


I meant
debian/patches/debian/Don-t-enable-audit-by-default.patch

Sorry for the confusion.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017541: auditd: Fails to generate/log events after systemd upgrade

[Michael Biebl]

On Wed, 17 Aug 2022 19:17:16 +0200 Sven Mueller  wrote:


It's reproducible only with systemd upgrades. We've reproduced it with
different versions of systemd, but always upgrading from 249.7-1 to
the version tested.


I assume this reproducer can be further reduced to

systemctl restart systemd-journald

? (which is part of systemd.postinst)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018459: Maintainer proposed patch to remove dep

[Moessbauer, Felix]

Hi,

I just got into contact with the upstream maintainer.
He already proposed a patch to remove this dependency and is willing to cut a 
new release after we tested this.
Then I'll bump the version and close the bug (via Stephan).

[1] https://github.com/purcell/airspeed/issues/59
--
Siemens AG, Linux Expert Center
Otto-Hahn-Ring 6, 81739 München, Germany

Bug#1016373: deviceinfo: ftbfs on risc64 arch("error: some symbols or patterns disappeared in the symbols file")

[Manuel A. Fernandez Montecelo]

Hi again,

On Tue, 30 Aug 2022 at 18:24, Manuel A. Fernandez Montecelo
 wrote:
>
> Hi,
>
> On Sat, 30 Jul 2022 at 15:54, Bo YU  wrote:
> >
> > Source: deviceinfo
> > Version: 0.1.0-7
> > Severity: normal
> > Tags: ftbfs, patch
> > User: debian-ri...@lists.debian.org
> > Usertags: riscv64
> > X-Debbugs-Cc: debian-ri...@lists.debian.org
> >
> > Dear deviceinfo Maintainer,
> >
> > The deviceinfo package has a ftbfs issue on riscv64 arch due to missing
> > symbols:
>
>
> Thanks for your report.
>
> I gave back the package to be built again, as it happened around the
> time of the transition from GCC-11 to -12 and other packages like
> khtml had the same problems, but were fine and didn't need
> modifications after being rebuilt.  So let's cross fingers :-)

Failed again with symbols errors, so I guess that the patch is needed
in this case.

https://buildd.debian.org/status/fetch.php?pkg=deviceinfo=riscv64=0.1.0-7=1661877711=0

-- 
Manuel A. Fernandez Montecelo 

Bug#1018750: libreoffice crashes at start if package libreoffice-nlpsolver is missing

[Rene Engelhard]

tag 1018750 - moreinfo

thanks


Hi,

Am 30.08.22 um 18:19 schrieb r087...@yahoo.it:
Yes the problem was that by removing libreoffice-nlpsolver, the 
/usr/lib/libreoffice/share/extensions was a 0-byte file instead of a dir.



OK, thanks for confirming.



by

$ sudo rm -r /usr/lib/libreoffice/share/extensions

$ sudo mkdir /usr/lib/libreoffice/share/extensions

it now works. Solved, thank you :)

And should work again when installing libreoffice-nlpsolver (for magic 
reasons I don't yet understand, as it apparently replaced that 0 byte 
file by a dir again. Removing it then runs into the bug again)



Regards,


Ren

Bug#1005832: more info

[Rene Engelhard]

Hi again.

Am 30.08.22 um 17:43 schrieb Rene Engelhard:

So I guess dpkg removes /usr/lib/libreoffice/share/extensions i(it is
still "owned" by libreoffice-common though. Should it happen?) and
nevertheless libreoffice-common is triggered the touch is fired and you
end up with that 0 byte file :/


Apparently /usr/lib/libreoffice/share/extensions is NOT in 
libreoffice-common anymore in sid, which explains this (no dir anymore, 
touch -> 0 byte file)


Regards,


Rene

Bug#1016373: deviceinfo: ftbfs on risc64 arch("error: some symbols or patterns disappeared in the symbols file")

[Manuel A. Fernandez Montecelo]

Hi,

On Sat, 30 Jul 2022 at 15:54, Bo YU  wrote:
>
> Source: deviceinfo
> Version: 0.1.0-7
> Severity: normal
> Tags: ftbfs, patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> X-Debbugs-Cc: debian-ri...@lists.debian.org
>
> Dear deviceinfo Maintainer,
>
> The deviceinfo package has a ftbfs issue on riscv64 arch due to missing
> symbols:


Thanks for your report.

I gave back the package to be built again, as it happened around the
time of the transition from GCC-11 to -12 and other packages like
khtml had the same problems, but were fine and didn't need
modifications after being rebuilt.  So let's cross fingers :-)

-- 
Manuel A. Fernandez Montecelo 

Bug#1018750: libreoffice crashes at start if package libreoffice-nlpsolver is missing

[Rene Engelhard]

Hi,

Am 30.08.22 um 18:01 schrieb r087...@yahoo.it:


Hi, here's the output:

$ ls -l /usr/lib/libreoffice/share/extensions
totale 4
drwxr-xr-x 6 root root 4096 30 ago 08.50 nlpsolver


That is clear. :)


What is with libreoffice-nlpsolver removed?


Regards,


Rene

Bug#984297: presage: ftbfs with GCC-11

[Simon Chopin]

Package: presage
Followup-For: Bug #984297
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
X-Debbugs-Cc: scho...@ubuntu.com
Control: tags -1 patch



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

  * d/p/c++17.patch: fix the build against GCC-11 by porting the code to C++17
(LP: #1988196)
  * d/p/format-security.patch: fix insecure format strings in the demo code
(FTBFS on Ubuntu due to -Werror=format-security.patch)

I'm not sure that the second one actually applies in Debian, but
attaching the patch in the debdiff just in case.

Thanks for considering the patch.


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports'), (50, 'jammy-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-46-lowlatency (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru presage-0.9.1/debian/patches/c++17.patch 
presage-0.9.1/debian/patches/c++17.patch
--- presage-0.9.1/debian/patches/c++17.patch1970-01-01 01:00:00.0 
+0100
+++ presage-0.9.1/debian/patches/c++17.patch2022-08-30 17:56:09.0 
+0200
@@ -0,0 +1,239 @@
+Description: Port the code to C++17
+Author: Simon Chopin 
+Origin: ubuntu
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984297
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/presage/+bug/1988196
+Last-Update: 2022-08-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/lib/presage.h
 b/src/lib/presage.h
+@@ -112,7 +112,7 @@
+  * 
+  * Presage does not take ownership of the callback object.
+  */
+-Presage(PresageCallback* callback) throw (PresageException);
++Presage(PresageCallback* callback) noexcept(false);
+ 
+ 
+ /** Creates and initializes presage with supplied configuration.
+@@ -122,7 +122,7 @@
+  *
+  * Presage does not take ownership of the callback object.
+  */
+-Presage(PresageCallback* callback, const std::string config) throw 
(PresageException);
++Presage(PresageCallback* callback, const std::string config) 
noexcept(false);
+ 
+ 
+ /** Destroys presage.
+@@ -138,7 +138,7 @@
+  * context.
+  *
+  */
+-std::vector predict() throw (PresageException);
++std::vector predict() noexcept(false);
+ 
+ /** \brief Obtain a prediction that matches the supplied token
+  * filter.
+@@ -153,7 +153,7 @@
+  * of the filter tokens.
+  *
+  */
+-std::multimap predict(std::vector 
filter) throw (PresageException);
++std::multimap predict(std::vector 
filter) noexcept(false);
+ 
+ /** \brief Learn from text offline.
+  *
+@@ -167,7 +167,7 @@
+  * \param text a text string to learn from.
+  *
+  */
+-void learn(const std::string text) const throw (PresageException);
++void learn(const std::string text) const noexcept(false);
+ 
+ /** \brief Callback getter/setter.
+  *
+@@ -176,7 +176,7 @@
+  *
+  * \return pointer to previously used callback
+  */
+-PresageCallback* callback(PresageCallback* callback) throw 
(PresageException);
++PresageCallback* callback(PresageCallback* callback) noexcept(false);
+ 
+ /** \brief Request presage to return the completion string for the given 
predicted token.
+  *
+@@ -190,26 +190,26 @@
+  *
+  * \return completion string
+  */
+-std::string completion(std::string str) throw (PresageException);
++std::string completion(std::string str) noexcept(false);
+ 
+ /** \brief Returns the text entered so far.
+  *
+  * \return context, text entered so far.
+  */
+-std::string context() const throw (PresageException);
++std::string context() const noexcept(false);
+ 
+ /** \brief Returns true if a context change occured.
+  *
+  * \return true if a context change occured after the last update
+  * or predict calls, or false otherwise.
+  */
+-bool context_change() const throw (PresageException);
++bool context_change() const noexcept(false);
+ 
+ /** \brief Returns the current prefix.
+  *
+  * \return prefix
+  */
+-std::string prefix() const throw (PresageException);
++std::string prefix() const noexcept(false);
+ 
+ /** \brief Gets the value of specified configuration variable.
+  *
+@@ -218,7 +218,7 @@
+  *
+  * \return value assigned to configuration variable.
+  */
+-std::string config(const std::string variable) const throw 
(PresageException);
++std::string config(const std::string variable) const noexcept(false);
+ 
+ /** \brief Sets the value 

Bug#1016519: ffmpeg: Still FTBFS on hppa and powerpc

[John David Anglin]

Source: ffmpeg
Followup-For: Bug #1016519

Dear Maintainer,

This is with version 7:5.1-3:
https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=hppa=7%3A5.1-3=1661576231=0

/<>/tests/fate-run.sh fate-filter-overlay_yuv422 "" "" 
"/<>/debian/standard" 'framecrc -auto_conversion_filters -c:v 
pgmyuv -i /<>/debian/standard/tests/vsynth1/%02d.pgm 
-filter_complex_script 
/<>/debian/standard/tests/data/filtergraphs/overlay_yuv422' '' '' 
'' '1' '' '' '' '' '' '' '' '' '' ''
 /<>/debian/standard/ffmpeg -nostdin -nostats 
-noauto_conversion_filters -cpuflags all -auto_conversion_filters -c:v pgmyuv 
-hwaccel none -threads 1 -thread_type frame+slice -i 
/<>/debian/standard/tests/vsynth1/%02d.pgm -filter_complex_script 
/<>/debian/standard/tests/data/filtergraphs/overlay_yuv422 
-bitexact -f framecrc -
--- /<>/tests/ref/fate/filter-overlay_yuv420p102022-07-22 
17:58:40.0 +
+++ tests/data/fate/filter-overlay_yuv420p102022-08-27 04:23:18.426707238 
+
@@ -3,6 +3,6 @@
 #codec_id 0: rawvideo
 #dimensions 0: 352x288
 #sar 0: 0/1
-0,  0,  0,1,   304128, 0x524bcfc6
-0,  1,  1,1,   304128, 0xab3a13af
-0,  2,  2,1,   304128, 0xac08d718
+0,  0,  0,1,   304128, 0xd041d116
+0,  1,  1,1,   304128, 0x293f14ff
+0,  2,  2,1,   304128, 0x2a0dd868
Test filter-overlay_yuv420p10 failed. Look at 
tests/data/fate/filter-overlay_yuv420p10.err for details.
ffmpeg version 5.1-3 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 12 (Debian 12.2.0-1)
  configuration: --prefix=/usr --extra-version=3 --toolchain=hardened 
--libdir=/usr/lib/hppa-linux-gnu --incdir=/usr/include/hppa-linux-gnu 
--arch=hppa --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa 
--enable-libaom --enable-libass --enable-libbluray --enable-libbs2b 
--enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d 
--enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm 
--enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq 
--enable-librist --enable-librubberband --enable-libshine --enable-libsnappy 
--enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh 
--enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable-libvidstab 
--enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 
--enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq 
--enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl 
--enable-opengl --enable-sdl2 --disable-sndio --enable-libdc1394 
--enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r 
--enable-libx264 --enable-libplacebo --enable-shared
  libavutil  57. 28.100 / 57. 28.100
  libavcodec 59. 37.100 / 59. 37.100
  libavformat59. 27.100 / 59. 27.100
  libavdevice59.  7.100 / 59.  7.100
  libavfilter 8. 44.100 /  8. 44.100
  libswscale  6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc56.  6.100 / 56.  6.100
Input #0, image2, from 
'/<>/debian/standard/tests/vsynth1/%02d.pgm':
  Duration: 00:00:02.00, start: 0.00, bitrate: N/A
  Stream #0:0: Video: pgmyuv, yuv420p, 352x288, 25 fps, 25 tbr, 25 tbn
Stream mapping:
  Stream #0:0 (pgmyuv) -> split:default
  overlay:default -> Stream #0:0 (rawvideo)
Output #0, framecrc, to 'pipe:':
  Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le(tv, 
progressive), 352x288, q=2-31, 38016 kb/s, 25 fps, 25 tbn
Metadata:
  encoder : Lavc rawvideo
frame=3 fps=1.2 q=-0.0 Lsize=   0kB time=00:00:00.12 bitrate=  
17.6kbits/s speed=0.0462x
video:891kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: unknown
make[2]: *** [/<>/tests/Makefile:305: 
fate-filter-overlay_yuv420p10] Error 1

Regards,
Dave Anglin

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

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

Bug#1018774: sockjs-client: Deprecated, replaced by node-sockjs

[Yadd]

Source: sockjs-client
Version: 0.3.4+dfsg-2
Severity: serious
Justification: Duplicate

An updated libjs-sockjs is given by node-sockjs. Please remove this
package

Bug#1005832: more info

[Rene Engelhard]

[ Your mail never appeared to me wither in my mailbox nor in  the
mailing list archives. Probably eaten by a spamfilter ]

Hi,

sorry for the late answer.

Am Sat, Jun 25, 2022 at 04:50:40PM -0700 schrieb Mark A. Hershberger:
> Found this bug because this is the only hit I found on search engines for the 
> error I was seeing. I have a Debian system. 

Obviously, since you wouldn't report here ;-)

> The problem is apparently because /usr/lib/libreoffice/share/extensions is 
> (in my case) a 0-byte file and installing an extension resolves the issue. 

Wow the f*? ...

> mah@gabriel:~$ sudo rm /usr/lib/libreoffice/share/extensions 
> mah@gabriel:~$ sudo mkdir /usr/lib/libreoffice/share/extensions 
> mah@gabriel:~$ libreoffice 
> Warning: failed to launch javaldx - java may not function correctly 
> mah@gabriel:~$ dpkg -S /usr/lib/libreoffice/share/extensions 
> dpkg-query: no path found matching pattern 
> /usr/lib/libreoffice/share/extensions 
> mah@gabriel:~$ apt-file search /usr/lib/libreoffice/share/extensions | cut -d 
> : -f 1 | sort -u | xargs dpkg -l 
> Desired=Unknown/Install/Remove/Purge/Hold 
> | 
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend 
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) 
> ||/ Name Version Architecture Description 
> +++-==-=--===
>  
> ii libreoffice-common 1:7.3.4~rc2-1~bpo11+1 all office productivity suite -- 
> arch-independent files 
> un libreoffice-wiki-publisher   (no description available) 
> un libreoffice-writer2latex   (no description available) 
> un libreoffice-writer2xhtml   (no description available) 
> dpkg-query: no packages found matching eyes17 
> dpkg-query: no packages found matching libreoffice-canzeley-client 
> dpkg-query: no packages found matching libreoffice-dmaths 
> dpkg-query: no packages found matching libreoffice-grammalecte 
> dpkg-query: no packages found matching libreoffice-lightproof-en 
> dpkg-query: no packages found matching libreoffice-lightproof-hu 
> dpkg-query: no packages found matching libreoffice-lightproof-pt-br 
> dpkg-query: no packages found matching libreoffice-lightproof-ru-ru 
> dpkg-query: no packages found matching libreoffice-nlpsolver 
> dpkg-query: no packages found matching libreoffice-numbertext 
> dpkg-query: no packages found matching libreoffice-parlatype 
> dpkg-query: no packages found matching libreoffice-texmaths 
> dpkg-query: no packages found matching libreoffice-voikko 

... sigh. I think I see what goes wrong here. How did it appear not in
earlier times (the problematic code is in there since 3.x!).

libreoffice-common has a trigger which is supposed to run
make_lo_sync_extensions to do what it says when a extension is
installed/removed by touching the dir:

$ cat libreoffice-common.postinst
#!/bin/sh

set -e

[...]
validate_extensions() {
  INSTDIR=`mktemp -d`
  if HOME=$INSTDIR /usr/lib/libreoffice/program/unopkg list --bundled 
>/dev/null 2>/dev/null; then
HOME=$INSTDIR /usr/lib/libreoffice/program/unopkg validate -v --bundled
  fi
}

make_lo_sync_extensions() {
touch /usr/lib/libreoffice/share/extensions
}

if [ "$1" = "triggered" ]; then
for triggername in $2; do
case "$triggername" in
# new "bundled" extensions (since 3.3)
"/usr/lib/libreoffice/share/extensions")
  make_lo_sync_extensions
;;
[...]
esac
done
fi

[...]
$

So I guess dpkg removes /usr/lib/libreoffice/share/extensions i(it is
still "owned" by libreoffice-common though. Should it happen?) and
nevertheless libreoffice-common is triggered the touch is fired and you
end up with that 0 byte file :/

Regards,

Rene

Bug#1018773: libgnuradio-funcube3.10.0: Missing Breaks and Replaces headers: trying to overwrite '/usr/lib/x86_64-linux-gnu/libgnuradio-funcube.so.3.10.0.0', which is also in package libgnuradio-funcu

[Axel Beckert]

Package: gr-funcube
Severity: serious
Version: 3.10.0~rc2-3

Hi,

libgnuradio-funcube3.10.0 fails to install as follows due to missing
Breaks and Replaces headers against libgnuradio-funcube1.0.0:

Preparing to unpack .../libgnuradio-funcube3.10.0_3.10.0~rc2-3_amd64.deb ...
Unpacking libgnuradio-funcube3.10.0 (3.10.0~rc2-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/libgnuradio-funcube3.10.0_3.10.0~rc2-3_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/libgnuradio-funcube.so.3.10.0.0', which is also in 
package libgnuradio-funcube1.0.0 3.10.0~rc2-1
Errors were encountered while processing:
 /var/cache/apt/archives/libgnuradio-funcube3.10.0_3.10.0~rc2-3_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- System Information:
Debian Release: bookworm/sid
[Bug report written on a different system than the issue showed up.]

Bug#1018750: libreoffice crashes at start if package libreoffice-nlpsolver is missing

[Rene Engelhard]

tag 1018750 + moreinfo

thanks


Hi,


Am 30.08.22 um 08:48 schrieb r087...@yahoo.it:

Package: libreoffice-nlpsolver
Version: 7.4.1


Erm, no. That version doesn't exist. And thus the BTS is confused

a) The version in sid is 7.4.1 rc1, not 7.4.1

b) the correct Version: would be the *package version*, obviously, thus 
1:7.4.1~rc1-2. If you don't know how to format bugs properly use 
reportbug which helps you with this.


>If the libreoffice-nlpsolver package is not installed, libreoffice 
will crash at start (see below). This package should be set as dependency.


Then obviously it would be a bug in libreoffice itself not 
libreoffice-nlpsolver.


NLPsolver is an *extension* (as the description clearly says) and as 
such is completely optional. LibreOffice starts and works fine without it.



Though I think I saw the problem...

(Just saw https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005832#20 
which never appeared to me wither in my mailbox nor in  the mailing list 
archives. Probably eaten by a spamfilter).


Can you tell me what your ls -l /usr/lib/libreoffice/share/extensions 
is? Before and after installing libreoffice-nlpsolver? Did you remove it 
once? Which other extensions packaged in Debian do you have installed?



Regards,


Rene

Bug#1018762: GNOME Settings has two Screen Blank controls and only one of them works.

[Jeremy Bicha]

On Tue, Aug 30, 2022 at 11:30 AM Kenneth Stailey  wrote:
> Ubuntu 22.10 (karmic) has already triaged it as confirmed, high
> priority and Fix Commited:
> https://bugs.launchpad.net/bugs/1988087
>
> Fedora Pre-Beta 37 bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=2122659

Yes, we'll probably wait for gnome-control-center 42 RC to be released
in a few days.

https://wiki.gnome.org/FortyThree

Thank you,
Jeremy Bicha

Bug#1018762: Issue is in other distros

[Kenneth Stailey]

Ubuntu 22.10 (karmic) has already triaged it as confirmed, high
priority and Fix Commited:
https://bugs.launchpad.net/bugs/1988087

Fedora Pre-Beta 37 bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2122659

Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1

[Thomas Uhle]

Dear maintainers,

as you can see from the build log, both libraries libdbus-c++-ecore-1.so.0 
and libdbus-c++-glib-1.so.0 are built before libdbus-c++-1.so.0 instead of 
after.  That is the main reason why they cannot be linked to it.  I think 
it would be best if the build order could be adapted accordingly upstream, 
so that it would be possible to explicitly link to libdbus-c++-1.so.0.
However, pkg-config does the right thing and appends '-ldbus-c++-1' after 
'-ldbus-c++-ecore-1' as well as after '-ldbus-c++-glib-1'.  And due to 
dbus-c++'s documentation, using pkg-config is the recommended way to get 
compiler and linker flags.


Best regards,

Thomas Uhle

Bug#1018772: libdbus-c++-1-0v5: please put each library into its own package

[Thomas Uhle]

Package: libdbus-c++-1-0v5
Version: 0.9.0-8.2
Severity: wishlist

Dear maintainers,

could you please split libdbus-c++-1-0v5 into three separate packages 
and put the GLib an Ecore related libraries into libdbus-c++-glib-1-0 
and libdbus-c++-ecore-1-0 respectively.


`apt-cache rdepends libdbus-c++-1-0v5` reveals that besides 
libdbus-c++-bin and libdbus-c++-dev, only ffado-dbus-server and 
jami-daemon currently depend on libdbus-c++-1-0v5.  As far as I can see, 
these two packages just depend on libdbus-c++-1.so.0, so there is no need 
to recompile these packages.  That means then only libdbus-c++-dev needs 
to depend on the new packages libdbus-c++-ecore-1-0 and 
libdbus-c++-glib-1-0 next to libdbus-c++-1-0v5.


Thank you in advance!

Thomas Uhle


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-17-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libdbus-c++-1-0v5 depends on:
ii  libc62.31-13+deb11u4
ii  libdbus-1-3  1.12.20-2
ii  libecore11.25.1-1
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libglib2.0-0 2.66.8-1
ii  libstdc++6   10.2.1-6

libdbus-c++-1-0v5 recommends no packages.

libdbus-c++-1-0v5 suggests no packages.

Bug#1018771: libdbus-c++-dev: missing dependency on libdbus-1-dev

[Thomas Uhle]

Package: libdbus-c++-dev
Version: 0.9.0-8.2
Severity: normal

Dear maintainers,

pkg-config reports the following for any of the three dbus-c++ libraries
unless you also install the package libdbus-1-dev:

 Package dbus-1 was not found in the pkg-config search path.
 Perhaps you should add the directory containing `dbus-1.pc'
 to the PKG_CONFIG_PATH environment variable
 Package 'dbus-1', required by 'dbus-c++-1', not found

Please update the dependencies of libdbus-c++-dev.

Thank you in advance!

Thomas Uhle


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-17-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libdbus-c++-dev depends on:
ii  libdbus-c++-1-0v5  0.9.0-8.2
ii  libdbus-c++-bin0.9.0-8.2

libdbus-c++-dev recommends no packages.

libdbus-c++-dev suggests no packages.

Bug#1017629: Uploaded 4.7.2

[Thomas Goirand]

Hi,

FYI, 4.7.2 is uploaded to Experimental, and will go to Unstable when 
OpenStack Zed will be release on the 5th of October.


I would prefer to keep that version if it's not annoying others.
Please let me know.

Let's see how it goes in the pseudo-excuse page anyways...

Cheers,

Thomas Goirand (zigo)

Bug#1018770: llvm-14-dev: misspelling in headers gets compiled into other binaries

[Andreas Beckmann]

Package: llvm-14-dev
Version: 1:14.0.6-2
Severity: normal

Hi,

/usr/include/llvm-14/llvm/Target/TargetMachine.h contains a misspelling
in a string literal: 'overriden' (should be 'overridden') (2 occurrences)
that may get compiled into other applications and make lintian flag the
typo there.
(The same misspelling also appears in comments in multiple headers.)

/usr/include/llvm-14/llvm/Target/TargetMachine.h:442:return 
make_error("buildCodeGenPipeline is not overriden",
/usr/include/llvm-14/llvm/Target/TargetMachine.h:448:
"getPassNameFromLegacyName parseMIRPipeline is not overriden");

(observed while testing to build src:intel-graphics-compiler against
llvm-14)


Andreas

Bug#1018766: python3-progressbar2: file conflicts with python3-progressbar

[Sandro Tosi]

> I don't know how these two packages relate to each other, so I cannot
> give good advice how to handle that conflict.

this was brought to the maintainers attention with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016390#10

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

Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Salvatore Bonaccorso]

Hi Martin,

On Tue, Aug 30, 2022 at 03:18:51PM +0300, Martin-??ric Racine wrote:
> On Tue, Aug 30, 2022 at 3:00 PM Peter Zijlstra  wrote:
> > On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-??ric Racine wrote:
> > > On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra  
> > > wrote:
> > > >
> > > > On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
> > > >
> > > > > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
> > > > > we can't have nested alternatives.  That's unfortunate.
> > > >
> > > > Well, both alternatives end with the LFENCE instruction, so I could pull
> > > > it out and do two consequtive ALTs, but unrolling the loop for i386 is
> > > > a better solution in that the sequence, while larger, removes the need
> > > > for the LFENCE.
> > >
> > > Have we reached a definitive conclusion on to how to fix this?
> >
> > https://git.kernel.org/tip/332924973725e8cdcc783c175f68cf7e162cb9e5
> 
> Thanks.
> 
> Ben: When can we expect an updated kernel to security-updates at Debian?

When the update is ready to go. Likely the update for the next point
release for bullseye will contain the fix for this issue.

Regards,
Salvatore

Bug#1018768: Bonding interface gets the wrong MAC address when configured for the first time

[Christian Schwamborn]

Package: ifenslave
Version: 2.12

This bug has already been filed as #949062 and was archived with the
comment 'Fixed in version ifenslave/2.13'. OK so far, but whats about
bullseye? I just just wasted about 2h of my time finally retracing the
steps someone did over 2 years ago. Is this going to be fixed in stable?
This bug seems insignificant if you run a single machine on a subnet
with a bond interface, but if you are setting up several servers within
the same subnet and all get the same mac address on their bond
interface, it gets a bit annoying.
Where does the mac address, the bond interface gets comes from anyways?
As I got the same address on three different machines.

Bug#1018767: node-sockjs: missing Breaks+Replaces: libjs-sockjs (<< 0.3.24)

[Andreas Beckmann]

Package: node-sockjs
Version: 0.3.24+~0.3.33-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'bullseye'.
It installed fine in 'bullseye', then the upgrade to 'bookworm' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../node-sockjs_0.3.24+~0.3.33-3_all.deb ...
  Unpacking node-sockjs (0.3.24+~0.3.33-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/node-sockjs_0.3.24+~0.3.33-3_all.deb (--unpack):
   trying to overwrite '/usr/share/javascript/sockjs/sockjs.js', which is also 
in package libjs-sockjs 0.3.4+dfsg-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/node-sockjs_0.3.24+~0.3.33-3_all.deb

Can src:sockjs-client (which built the old libjs-sockjs) be removed from
sid?


cheers,

Andreas


libjs-sockjs=0.3.4+dfsg-2_node-sockjs=0.3.24+~0.3.33-3.log.gz
Description: application/gzip

Bug#1018766: python3-progressbar2: file conflicts with python3-progressbar

[Andreas Beckmann]

Package: python3-progressbar2
Version: 4.0.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package python3-progressbar2.
  Preparing to unpack .../python3-progressbar2_4.0.0-2_all.deb ...
  Unpacking python3-progressbar2 (4.0.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-progressbar2_4.0.0-2_all.deb (--unpack):
   trying to overwrite 
'/usr/lib/python3/dist-packages/progressbar/__init__.py', which is also in 
package python3-progressbar 2.5-3
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-progressbar2_4.0.0-2_all.deb

The conflicting files are

usr/lib/python3/dist-packages/progressbar/__init__.py
usr/lib/python3/dist-packages/progressbar/widgets.py

I don't know how these two packages relate to each other, so I cannot
give good advice how to handle that conflict.


cheers,

Andreas


python3-progressbar=2.5-3_python3-progressbar2=4.0.0-2.log.gz
Description: application/gzip

Bug#1018764: src:freeciv: Links /usr/share/doc/ arch:all and arch:all

[Tobias Frost]

Package: freeciv
Version: 3.0.3-1
Severity: normal

Currently we ship symlinks from usr/share/doc/ -> 
usr/share/doc/freeciv-data

 are our binary packages. all of them except freeciv are arch:any.
freeciv-data is arch:all.

If I'm reading that correctly this is a policy violation of §12.3 (+ footnote 
7).

Also dh_installdocs say for --link-doc:

CAVEAT 2: The use of --link-doc should only be done when the packages
have same "architecture" type.  A link from an architecture independent package
to an architecture dependent package (or vice versa) will not work.  Since
compat 10, debhelper will actively reject unsupported combinations.


Changing that is a bit of effort, so I'm just reporting that and will defer
that to an later upload.

--
tobi

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Simon McVittie]

On Thu, 25 Aug 2022 at 13:14:33 -0500, Gunnar Wolf wrote:
> Simon McVittie dijo [Thu, Aug 25, 2022 at 11:19:30AM +0100]:
> > Is armel a realistic candidate for being a Debian 12 release
> > architecture?
> 
> I do not feel armel systems are hard to come by, nor marginal in the
> amount of users they have. Yes, running a GNOME desktop on them might
> be a Very Bad Idea (if at all possible)...  But they are very good
> non-interactive purposes.

Your vote for retaining armel as a release architecture is noted (but
that decision is not up to me - it's up to the release team, with input
from the ARM porters who are responsible for doing the work to keep the
port alive).

If armel is a candidate for being a release architecture, then I think
that leaves two-and-a-half options:

1. task-gnome-desktop is uninstallable on this architecture
  1a. or Bastien's suggestion: task-gnome-desktop is installable on this
  architecture, but the preinst fails on baseline CPUs
2. task-gnome-desktop installs something that is not the full GNOME
   desktop on this architecture

I would personally prefer 1., but last time I tried this (for s390x),
it was blocked by the release machinery not allowing any task package to
be uninstallable on any release architecture, even if the task doesn't
really make sense there. So I am going to work towards 2., unless the
release team tells me that 1. can be made to work.

On Sat, 27 Aug 2022 at 15:41:44 +, Bastien Roucariès wrote:
> adding support to armv6-support will help here

I spoke to an ARM porter (Peter Green) at the weekend, and based on what
he said, it would probably have to be armv7-support: if I'm understanding
correctly, ARMv6 includes *some* atomic instructions, but they are not
the ones that mozjs wants to invoke from inline assembler and its JIT,
and are not really safe to use on ARMv7 CPUs.

Are you suggesting that mozjs102 should add a Build-Depends and
(Pre-?)Depends on armv7-support [armel], and override the compiler
defaults on armel to build with something like -march=armv7?

That doesn't seem very honest, or very efficient: we'd be compiling an
ARMv7 binary as part of what is in theory our ARMv5 port, knowing that
anyone who could successfully run it would be better served by installing
libmozjs-102-0:armhf instead.

For non-baseline i386 extensions (MMX, SSE, SSE2), isa-support has two
justifications for existing:

- there is a reasonably common class of CPU that is not supported by our
  next-higher-baseline port but would benefit from the non-baseline
  extension (CPUs from the Pentium II/III/IV era, which have SSE2 but are
  still only 32-bit, and cannot run amd64 binaries);
- there are commonly-used proprietary binaries which cannot simply be
  recompiled for the next-higher-baseline ABI, and require libraries with
  the older ABI for their dependencies (Linux i386 binary-only games etc.,
  and 32-bit Windows binary-only programs running under Wine)

Neither of those justifications seems to me like it really applies to the
boundary between armel and armhf, unless there is a widespread class of
CPU that has all the mandatory ARMv7 instructions (including the atomic
operations that mozjs wants), but lacks VFP hardfloat support.

smcv

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Luca Falavigna]

Both ways are fine. If you upload -3 right now, NMU will be rejected
because of the newer version, otherwise it'll reach the archive when
time elapses.
A maintainer upload would be better, though :-)

-- 
Cheers,
Luca

Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Martin-Éric Racine]

On Tue, Aug 30, 2022 at 3:00 PM Peter Zijlstra  wrote:
> On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-Éric Racine wrote:
> > On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra  wrote:
> > >
> > > On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
> > >
> > > > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
> > > > we can't have nested alternatives.  That's unfortunate.
> > >
> > > Well, both alternatives end with the LFENCE instruction, so I could pull
> > > it out and do two consequtive ALTs, but unrolling the loop for i386 is
> > > a better solution in that the sequence, while larger, removes the need
> > > for the LFENCE.
> >
> > Have we reached a definitive conclusion on to how to fix this?
>
> https://git.kernel.org/tip/332924973725e8cdcc783c175f68cf7e162cb9e5

Thanks.

Ben: When can we expect an updated kernel to security-updates at Debian?

Martin-Éric

Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Peter Zijlstra]

On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-Éric Racine wrote:
> Greetings,
> 
> On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra  wrote:
> >
> > On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
> >
> > > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
> > > we can't have nested alternatives.  That's unfortunate.
> >
> > Well, both alternatives end with the LFENCE instruction, so I could pull
> > it out and do two consequtive ALTs, but unrolling the loop for i386 is
> > a better solution in that the sequence, while larger, removes the need
> > for the LFENCE.
> 
> Have we reached a definitive conclusion on to how to fix this?

https://git.kernel.org/tip/332924973725e8cdcc783c175f68cf7e162cb9e5

Bug#1018763: old conffiles not removed

[Stefan Bühler]

Package: rspamd
Version: 2.5-1

Hi,

lots of conffiles didn't get removed when upgrading from older
installations.

Candidates that should have been removed can be found with this:

  git log --full-history --diff-filter=DR --summary -- conf/

Those should either make it to debian/rspamd.maintscript as rm_conffile,
or perhaps remove-on-upgrade ... lines could be created in
debian/rspamd.conffiles [1] [2].

A few of those files actually got only renamed, but I think it's too
late now to mark them as moved.

You can use `adequate` to detect those obsolete conffiles on an affected
system:

  adequate --tags obsolete-conffile rspamd

I found this because rspamdadm complained with this message:

  ip_score module is deprecated in honor of reputation module!

cheers,
Stefan

[1] https://manpages.debian.org/testing/dpkg-dev/deb-conffiles.5.en.html
[2] https://manpages.debian.org/testing/debhelper/dh_installdeb.1.en.html

Bug#1018759: ITP: sd - intuitive find and replace CLI

[Blair Noctis]

On 2022/8/30 19:00, Andrey Rahmatullin wrote:

On Tue, Aug 30, 2022 at 06:44:36PM +0800, Blair Noctis wrote:

An RFP is at #1016929 [1].

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


You should have retitled and owned the RFP instead of creating a separate
ITP. You should do that now, as described on
https://www.debian.org/devel/wnpp/#l3 , and merge this bug into that one.



Done. Thanks for pointing out!

--
Regards,
Blair Noctis



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018744: bullseye-pu: package inetutils/2:2.0-1+deb11u1

[Guillem Jover]

Hi!

Sorry, I'm updating the request as I found missing stuff while
preparing the companion update for buster!

On Tue, 2022-08-30 at 00:37:03 +0200, Guillem Jover wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: t...@security.debian.org

> [ Reason ]
> 
> A recent vulnerability (DoS) was reported upstream, for which I
> uploaded a fixed package to sid (will migrate tomorrow). There was a
> (minor) pending security update missing from bullseye. The security
> team (CCed) would prefer to see these handled as normal stable updates.

I'm adding a couple of patches to solve lingering buffer overflow issues
from #945861 and CVE-2019-0053.

> [ Impact ]
> 
> These are both security issues. One against malicious ftp servers
> which can end up controlling the client to connect to other hosts,
> the other a DoS on the telnetd server which makes it crash with
> specific two-byte payloads.

The additional patches are buffer overflows.

> [ Tests ]
> 
> For the ftp client, there's a test recipe at
> .
> 
> For the telnetd server there's a test recipe at
> 
> which amounts to «printf "\xff\xf7" | nc -n -v localhost 23».

The two new patches fix the following reproducers:

  $ DISPLAY=`perl -e 'print Ax"5"'` telnet -l`perl -e 'print "A"x5000'` 
localhost

and

  
https://raw.githubusercontent.com/hackerhouse-opensource/exploits/master/telnet_term_0day.py

> Both test recipes could be reproduced before, and do not work after
> the patched version.

> [ Risks ]
> 
> The fix for the ftp client has been in sid since 2021-09 with no
> reported regressions.
> 
> The fix for telnetd has not yet migrated to testing, but is few lines
> long fixing a couple of NULL pointer dereferences.

Both new fixes have been part of sid/testing for a while now.

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

  * telnet: Add checks for option reply parsing limits causing buffer
overflow induced crashes due to long option values.
Fixes CVE-2019-0053. Closes: #945861
  * Add patch from upstream to fix infinite loop causing a stack exhaustion
induced crash in telnet client due to malicious server commands.
Closes: #945861
>   * Fix inetutils-ftp security bug trusting FTP PASV responses.
> Fixes CVE-2021-40491. Closes: #993476
>   * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
> a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
> or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
> adapted by Erik Auerswald .

> [ Other info ]
> 
> None.

I'm attaching the refreshed debdiff.

Thanks,
Guillem
diff -Nru inetutils-2.0/debian/changelog inetutils-2.0/debian/changelog
--- inetutils-2.0/debian/changelog  2021-02-05 23:14:20.0 +0100
+++ inetutils-2.0/debian/changelog  2022-08-30 13:34:41.0 +0200
@@ -1,3 +1,21 @@
+inetutils (2:2.0-1+deb11u1) bullseye; urgency=medium
+
+  * telnet: Add checks for option reply parsing limits causing buffer
+overflow induced crashes due to long option values.
+Fixes CVE-2019-0053. Closes: #945861
+  * Add patch from upstream to fix infinite loop causing a stack exhaustion
+induced crash in telnet client due to malicious server commands.
+Closes: #945861
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+Fixes CVE-2022-39028.
+
+ -- Guillem Jover   Tue, 30 Aug 2022 13:34:41 +0200
+
 inetutils (2:2.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
2022-08-30 13:33:33.0 +0200
@@ -0,0 +1,59 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c | 21 +
+ 2 files changed, 30 insertions(+)
+
+diff --git 

Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Martin-Éric Racine]

Greetings,

On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra  wrote:
>
> On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
>
> > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
> > we can't have nested alternatives.  That's unfortunate.
>
> Well, both alternatives end with the LFENCE instruction, so I could pull
> it out and do two consequtive ALTs, but unrolling the loop for i386 is
> a better solution in that the sequence, while larger, removes the need
> for the LFENCE.

Have we reached a definitive conclusion on to how to fix this?

Martin-Éric

Bug#1018759: ITP: sd - intuitive find and replace CLI

[Andrey Rahmatullin]

On Tue, Aug 30, 2022 at 06:44:36PM +0800, Blair Noctis wrote:
> An RFP is at #1016929 [1].
> 
> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016929
> 
You should have retitled and owned the RFP instead of creating a separate
ITP. You should do that now, as described on
https://www.debian.org/devel/wnpp/#l3 , and merge this bug into that one.

-- 
WBR, wRAR


signature.asc
Description: PGP signature