Bug#1041506: python-av: diff for NMU version 10.0.0-1.1

[Sebastian Ramacher]

Control: tags 1041506 + patch
Control: tags 1043015 + patch

Dear maintainer,

I've prepared an NMU for python-av (versioned as 10.0.0-1.1). The diff
is attached to this message. The changes are pushed to the packaging
repository.

Cheers
-- 
Sebastian Ramacher
diff -Nru python-av-10.0.0/debian/changelog python-av-10.0.0/debian/changelog
--- python-av-10.0.0/debian/changelog	2022-11-27 16:54:06.0 +0100
+++ python-av-10.0.0/debian/changelog	2023-08-05 14:05:17.0 +0200
@@ -1,3 +1,10 @@
+python-av (10.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Build with ffmpeg 6.0 (Closes: #1041506, #1043015)
+
+ -- Sebastian Ramacher   Sat, 05 Aug 2023 14:05:17 +0200
+
 python-av (10.0.0-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru python-av-10.0.0/debian/patches/series python-av-10.0.0/debian/patches/series
--- python-av-10.0.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ python-av-10.0.0/debian/patches/series	2023-08-05 14:04:34.0 +0200
@@ -0,0 +1 @@
+Update-to-ffmpeg-6.0.patch
diff -Nru python-av-10.0.0/debian/patches/Update-to-ffmpeg-6.0.patch python-av-10.0.0/debian/patches/Update-to-ffmpeg-6.0.patch
--- python-av-10.0.0/debian/patches/Update-to-ffmpeg-6.0.patch	1970-01-01 01:00:00.0 +0100
+++ python-av-10.0.0/debian/patches/Update-to-ffmpeg-6.0.patch	2023-08-05 14:04:18.0 +0200
@@ -0,0 +1,250 @@
+From 8871e13848cbf78615ba7b429d301adc071841ea Mon Sep 17 00:00:00 2001
+From: Mattias Wadman 
+Date: Tue, 21 Mar 2023 17:01:22 +0100
+Subject: [PATCH] Update to ffmpeg 6.0
+
+Removed and renamed constants with entry from API changes
+https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/doc/APIchanges
+
+Remove use of AVCodecContext.sub_text_format
+  2021-09-20 - 176b8d785bf - lavc 59.9.100 - avcodec.h
+Deprecate AVCodecContext.sub_text_format and the corresponding
+AVOptions. It is unused since the last major bump.
+
+AV_CODEC_CAP_TRUNCATED removed:
+  2021-09-20 - dd846bc4a91 - lavc 59.8.100 - avcodec.h codec.h
+Deprecate AV_CODEC_FLAG_TRUNCATED and AV_CODEC_CAP_TRUNCATED,
+as they are redundant with parsers.
+
+AV_CODEC_CAP_AUTO_THREADS renamed to AV_CODEC_CAP_AUTO_THREADS
+  2021-03-16 - 7d09579190 - lavc 58.132.100 - codec.h
+Add AV_CODEC_CAP_OTHER_THREADS as a new name for
+AV_CODEC_CAP_AUTO_THREADS. AV_CODEC_CAP_AUTO_THREADS
+is now deprecated.
+
+AV_CODEC_CAP_INTRA_ONLY removed (use AV_CODEC_PROP_INTRA_ONLY instead):
+AV_CODEC_CAP_LOSSLESS removed (use AV_CODEC_PROP_LOESSNES instead):
+  2020-05-21 - 13b1bbff0b - lavc 58.86.101 - avcodec.h
+Deprecated AV_CODEC_CAP_INTRA_ONLY and AV_CODEC_CAP_LOSSLESS.
+
+AV_CODEC_FLAG_TRUNCATED removed:
+AV_CODEC_CAP_TRUNCATED removed:
+  2021-09-20 - dd846bc4a91 - lavc 59.8.100 - avcodec.h codec.h
+Deprecate AV_CODEC_FLAG_TRUNCATED and AV_CODEC_CAP_TRUNCATED,
+as they are redundant with parsers.
+
+AV_CODEC_FLAG2_DROP_FRAME_TIMECODE removed:
+  Not API changelog but was removed in f843460eb790d37e444e5946628f228421916537:
+  avcodec/avcodec: Remove AV_CODEC_FLAG2_DROP_FRAME_TIMECODE
+
+  It has been deprecated in 94d68a4
+  and can't be set via AVOptions. The only codecs that use it
+  (the MPEG-1/2 encoders) have private options for this.
+  So remove it.
+
+AVFMT_FLAG_PRIV_OPT removed:
+  2021-03-03 - 2ff40b98ec - lavf 58.70.100 - avformat.h
+Deprecate AVFMT_FLAG_PRIV_OPT. It will do nothing
+as soon as av_demuxer_open() is removed.
+
+Related to #1106
+---
+ av/codec/codec.pyx   | 12 
+ av/codec/context.pyx | 11 ---
+ av/container/core.pyx|  3 ---
+ include/libavcodec/avcodec.pxd   | 10 +-
+ include/libavformat/avformat.pxd |  1 -
+ scripts/activate.sh  |  2 +-
+ 6 files changed, 6 insertions(+), 33 deletions(-)
+
+diff --git a/av/codec/codec.pyx b/av/codec/codec.pyx
+index ad3198fd..978d4277 100644
+--- a/av/codec/codec.pyx
 b/av/codec/codec.pyx
+@@ -52,7 +52,6 @@ Capabilities = define_enum('Capabilities', 'av.codec', (
+ """Codec uses get_buffer() for allocating buffers and supports custom allocators.
+ If not set, it might not use get_buffer() at all or use operations that
+ assume the buffer was allocated by avcodec_default_get_buffer."""),
+-('TRUNCATED', lib.AV_CODEC_CAP_TRUNCATED),
+ ('HWACCEL', 1 << 4),
+ ('DELAY', lib.AV_CODEC_CAP_DELAY,
+ """Encoder or decoder requires flushing with NULL input at the end in order to
+@@ -102,8 +101,10 @@ Capabilities = define_enum('Capabilities', 'av.codec', (
+ """Codec supports slice-based (or partition-based) multithreading."""),
+ ('PARAM_CHANGE', lib.AV_CODEC_CAP_PARAM_CHANGE,
+ """Codec supports changed parameters at any point."""),
+-('AUTO_THREADS', lib.AV_CODEC_CAP_AUTO_THREADS,
+-"""Codec supports avctx->thread_count == 0 (auto)."""),
++('AUTO_THREADS', lib.AV_CODEC_CAP_OTHER_THREADS,
++"""Codec supports 

Bug#1043059: abseil/experimental FTBFS on mipsel

[Adrian Bunk]

Source: abseil
Version: 20230125.3-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=abseil=mipsel=20230125.3-2=1691047974=0

...
virtual memory exhausted: Cannot allocate memory
make[4]: *** [absl/container/CMakeFiles/absl_btree_test.dir/build.make:79: 
absl/container/CMakeFiles/absl_btree_test.dir/btree_test.cc.o] Error 1


The patch below works around the address space issue, but later there is a test 
failure:

...
86: ./absl/log/scoped_mock_log.cc:39: Failure
86: Mock function called more times than expected - returning directly.
86: Function call: Log(INFO, @0x7f9b9b2c "./absl/log/log_format_test.cc", 
@0x7f9b9b14 "nan")
86:  Expected: to be never called
86:Actual: called once - over-saturated and active
86: ./absl/log/log_format_test.cc:611: Failure
86: Actual function call count doesn't match EXPECT_CALL(test_sink, Send(AllOf( 
TextMessage(MatchesOstream(comparison_stream)), TextMessage(AnyOf(Eq("-nan"), 
Eq("nan"), Eq("NaN"), Eq("-nan(ind)"))), ::testing::_)))...
86:  Expected: to be called once
86:Actual: never called - unsatisfied and active
86: [  FAILED  ] FloatingPointLogFormatTest/0.NegativeNaN, where TypeParam = 
float (0 ms)
...
99% tests passed, 1 tests failed out of 208

Total Test time (real) = 235.11 sec

The following tests FAILED:
 86 - absl_log_format_test (Failed)
Errors while running CTest
make[2]: *** [Makefile:74: test] Error 8


Full log is in eller:~bunk/build/LOG.abseil


The test failure is obviously triggered by my enabling of the unit tests,
keeping them disabled would of course "fix" the problem (this might also
be an option for some ports architectures).



--- debian/rules.old2023-08-04 22:56:54.349545220 +
+++ debian/rules2023-08-05 09:40:50.315873020 +
@@ -17,12 +17,8 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow reproducible=+fixfilepath
 
-# Unit tests require more than 2 GB of RAM, so disable them on mipsel.
-#
-# Disable unit tests unconditionally if nocheck is set.
-ifeq ($(DEB_HOST_ARCH),mipsel)
-ABSL_RUN_TESTS=OFF
-else ifneq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
+# Disable unit tests if nocheck is set.
+ifneq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
 ABSL_RUN_TESTS=OFF
 else
 ABSL_RUN_TESTS=ON
@@ -34,6 +30,12 @@
 ABSL_TEST_EXTRA_ARGS=--no-parallel
 endif
 
+# Reduce debug info on architectures with only 2 GB address space
+ifneq (,$(filter $(DEB_HOST_ARCH), mipsel sh4))
+export DEB_CXXFLAGS_MAINT_APPEND += -g1
+endif
+
+
 %:
dh $@
 

Bug#1043048: openblas: gives wrong results on mips64el, ignores test failures

[Rebecca N. Palmer]

Control: tags -1 upstream

Upstream CI's mips64 qemu test has what look like the same FATAL ERRORs, 
in MIPS64_GENERIC but not SICORTEX, but is still listed as passing.


Which suggests that they also have both parts of this bug (wrong answers 
on mips64el, and errors not actually failing the build), and that 
switching back to SICORTEX will probably work.

Bug#1043058: libesmtp6: missing Breaks: libesmtp5

[Andreas Beckmann]

Package: libesmtp6
Version: 1.1.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

This leaves a crippled libesmtp5 package installed on certain upgrade
paths.

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The libesmtp6 package has the following relationships with libesmtp5:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  libesmtp5

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

3m29.5s ERROR: FAIL: debsums reports modifications inside the chroot:
  debsums: missing file /usr/lib/esmtp/sasl-cram-md5.so (from libesmtp5 package)
  debsums: missing file /usr/lib/esmtp/sasl-login.so (from libesmtp5 package)
  debsums: missing file /usr/lib/esmtp/sasl-plain.so (from libesmtp5 package)

This wasn't noticed as long as libesmtp6 still provided the files, but
that no longer seems to be the case.


cheers,

Andreas


libesmtp-dev_1.1.0-3+b1.log.gz
Description: application/gzip

Bug#1043057: thunderbird: `[GFX1-]: FireTestProcess failed: Abspalten des Kindprozesses »/usr/lib/thunderbird/glxtest« gescheitert (Datei oder Verzeichnis nicht gefunden)`

[Paul Menzel]

Package: thunderbird
Version: 1:115.1.0-1
Severity: normal


Dear Debian folks,


Upgrading *thunderbird* from 1:102.13.1-1 to 115.1.0-1 the messages 
below are printed to the terminal:


[GFX1-]: FireTestProcess failed: Abspalten des Kindprozesses 
»/usr/lib/thunderbird/glxtest« gescheitert (Datei oder Verzeichnis nicht 
gefunden)


[GFX1-]: glxtest: ManageChildProcess failed

[GFX1-]: No GPUs detected via PCI

Copying the executable from *firefox* fixes the issue.

sudo cp -a /usr/lib/firefox/glxtest /usr/lib/thunderbird/glxtest

After that, the message below is shown:

[GFX1-]: FireTestProcess failed: Abspalten des Kindprozesses 
»/usr/lib/thunderbird/vaapitest« gescheitert (Datei oder Verzeichnis 
nicht gefunden)



Kind regards,

Paul

Bug#1043056: gnome-shell crashes with sigseg

[Jörg Sommer]

Package: gnome-shell
Version: 43.6-1
Severity: normal

Hi,

my gnome-shell crashed and I've a coredump of it. I hope this is useful for
you to find and fix the bad point, because a crash of gnome-shell kills the
whole desktop.

```
% coredumpctl --debugger ~/bin/gdb-bt-full debug /usr/bin/gnome-shell
   PID: 1067 (gnome-shell)
   UID: 1000 (joerg)
   GID: 1000 (joerg)
Signal: 11 (SEGV)
 Timestamp: Sat 2023-08-05 12:16:47 CEST (1h 32min ago)
  Command Line: /usr/bin/gnome-shell
Executable: /usr/bin/gnome-shell
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service
  Unit: user@1000.service
 User Unit: org.gnome.Shell@wayland.service
 Slice: user-1000.slice
 Owner UID: 1000 (joerg)
   Boot ID: b407b68900ed4b4695d770c2cb30b696
Machine ID: 523cb54753234ed08c13ec497d0d3b64
  Hostname: zenbook
   Storage: 
/var/lib/systemd/coredump/core.gnome-shell.1000.b407b68900ed4b4695d770c2cb30b696.1067.169123060700.zst
 (present)
  Size on Disk: 48.5M
   Message: Process 1067 (gnome-shell) of user 1000 dumped core.

Module libudev.so.1 from deb systemd-254-1.amd64
Module libsystemd.so.0 from deb systemd-254-1.amd64
Stack trace of thread 1067:
#0  0x7fb10935dde8 n/a (libmutter-11.so.0 + 0x15dde8)
#1  0x7fb10a70a3d8 g_closure_invoke (libgobject-2.0.so.0 + 
0x163d8)
#2  0x7fb10a71cede n/a (libgobject-2.0.so.0 + 0x28ede)
#3  0x7fb10a723c97 g_signal_emit_valist 
(libgobject-2.0.so.0 + 0x2fc97)
#4  0x7fb10a7241bf g_signal_emit (libgobject-2.0.so.0 + 
0x301bf)
#5  0x7fb109629cec n/a (libmutter-clutter-11.so.0 + 0x9fcec)
#6  0x7fb1095f9e57 n/a (libmutter-clutter-11.so.0 + 0x6fe57)
#7  0x7fb10a1325e5 g_main_context_dispatch 
(libglib-2.0.so.0 + 0x595e5)
#8  0x7fb10a1328e8 n/a (libglib-2.0.so.0 + 0x598e8)
#9  0x7fb10a132b9f g_main_loop_run (libglib-2.0.so.0 + 
0x59b9f)
#10 0x7fb1092d6fc5 meta_context_run_main_loop 
(libmutter-11.so.0 + 0xd6fc5)
#11 0x556d8776f924 n/a (gnome-shell + 0x2924)
#12 0x7fb1090456ca __libc_start_call_main (libc.so.6 + 
0x276ca)
#13 0x7fb109045785 __libc_start_main_impl (libc.so.6 + 
0x27785)
#14 0x556d8776fbc1 n/a (gnome-shell + 0x2bc1)

Stack trace of thread 1078:
#0  0x7fb10911eeb9 syscall (libc.so.6 + 0x100eb9)
#1  0x7fb10a18c260 g_cond_wait (libglib-2.0.so.0 + 0xb3260)
#2  0x7fb10a0fcefb n/a (libglib-2.0.so.0 + 0x23efb)
#3  0x7fb10a15f4e2 n/a (libglib-2.0.so.0 + 0x864e2)
#4  0x7fb10a15ee9d n/a (libglib-2.0.so.0 + 0x85e9d)
#5  0x7fb1090a63ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fb109126a1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 1081:
#0  0x7fb1091199ef __GI___poll (libc.so.6 + 0xfb9ef)
#1  0x7fb10a13285e n/a (libglib-2.0.so.0 + 0x5985e)
#2  0x7fb10a132b9f g_main_loop_run (libglib-2.0.so.0 + 
0x59b9f)
#3  0x7fb10a338536 n/a (libgio-2.0.so.0 + 0x11c536)
#4  0x7fb10a15ee9d n/a (libglib-2.0.so.0 + 0x85e9d)
#5  0x7fb1090a63ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fb109126a1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 1079:
#0  0x7fb1091199ef __GI___poll (libc.so.6 + 0xfb9ef)
#1  0x7fb10a13285e n/a (libglib-2.0.so.0 + 0x5985e)
#2  0x7fb10a13297c g_main_context_iteration 
(libglib-2.0.so.0 + 0x5997c)
#3  0x7fb10a1329c1 n/a (libglib-2.0.so.0 + 0x599c1)
#4  0x7fb10a15ee9d n/a (libglib-2.0.so.0 + 0x85e9d)
#5  0x7fb1090a63ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fb109126a1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 1101:
#0  0x7fb1091199ef __GI___poll (libc.so.6 + 0xfb9ef)
#1  0x7fb10a13285e n/a (libglib-2.0.so.0 + 0x5985e)
#2  0x7fb10a13297c g_main_context_iteration 
(libglib-2.0.so.0 + 0x5997c)
#3  0x7fb1004374bd n/a (libdconfsettings.so + 0xb4bd)
#4  0x7fb10a15ee9d n/a (libglib-2.0.so.0 + 0x85e9d)
#5  0x7fb1090a63ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fb109126a1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 1099:
#0  

Bug#1043055: libbellesip2: missing Breaks+Replaces: libbellesip1 (<< 5.2)

[Andreas Beckmann]

Package: libbellesip2
Version: 5.2.0+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'bookworm'.
It installed fine in 'bookworm', then the upgrade to 'trixie' 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...):

  Selecting previously unselected package libbellesip2:amd64.
  Preparing to unpack .../25-libbellesip2_5.2.0+dfsg-2_amd64.deb ...
  Unpacking libbellesip2:amd64 (5.2.0+dfsg-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-FWGR51/25-libbellesip2_5.2.0+dfsg-2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/belr/grammars/sdp_grammar', which is also in 
package libbellesip1:amd64 5.1.64+dfsg-2


cheers,

andreas

Bug#1043048: openblas: gives wrong results on mips64el, ignores test failures

[Rebecca N. Palmer]

The most obviously relevant
change between those is that the installed BLAS changed from atlas to
openblas.


It looks like this wasn't a change of default, but that experimental 
uses libatlas and unstable uses libopenblas.


(I don't know why, as the obvious dependency chain is src:statsmodels -> 
python3-scipy -> python3-pythran -> libopenblas-dev | libatlas-base-dev 
on both, and libopenblas is installable in experimental.)



It looks like version 0.3.21+ds-4 is not affected by this issue and
passes its testsuite. Can you possibly check whether statsmodels builds
against that version?


It did (successfully) in statsmodels version 0.13.5+dfsg-7.  The 
openblas build logs also show the issue starting between .21 and .22.

Bug#1043054: rust-rcgen: Please patch to support CRLs

[Jonas Smedegaard]

Source: rust-rcgen
Version: 0.11.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please apply upstream-accepted but not yet released patches to support
CRLs.

Raising severity since this affects the testsuite of rust-rustls-webpki,
and as the affected tests are security-sensitive I would prefer to not
ignore them.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTONDsACgkQLHwxRsGg
ASGuFQ//RmzIHFX0dbuTC0vKewHs3u2kq5B8nZdI2at1kenqSwE3llqzwum0gaYm
yEGlk8UpG4MmDPkWpmFkltyZSYHFbN/bqu+/T+XhBtOVwpTLm2qohJlAgmWMVn1I
yalyNDiTUNSPFDsGkvT6nB66D1gaKtD4k4EK/w8Cmo8hCzl8GrTny/zZIUhx9Dfz
P6GRQ7fa1l13elfEnhPmFEEztf8afoozPcYiALMZxvV6coIviGSjsv7WNClWGtII
HnT8z4QlWjAGOfRg0XOP5MYZbCWUjqMJDVkXztXG92rlMI4kZZaIXbtYD3aL8dwX
9usPpMwk0o55qHHCAmuclv+DA3NBNwofIDXJHhf7OO4VE9yKRj79wiIhHQoe4TwP
ZCEjXCcNUyG68tW+fJLEWfYL5FbfFL/jkAJMnjVArtd6FdXI7ojsL0QiAfEW8VYB
FB/IGyKW89eo2kJnm08REL969CBpTs1Q7VZzvKu0uaTpFx5mvVDIo6P46JuQQAuq
ftWGHu5L7LbA1glXAJViztzvlyrvxsF/349PoQdGg5a/7KzyKP8jtfITGaCFOiZQ
JGvDjuviQF0FusDcpWZgpu/1crjya0rRdCqjOAWXfLmqCYNiM33JanRkiFdNhsGx
waHRP0+PmHExl88FOcT91C+dD8yTPv6kobKEIjSaGwj2TrgURlA=
=DjE8
-END PGP SIGNATURE-

Bug#1041649: [Pkg-utopia-maintainers] Bug#1041649: Bug#1041649: Bug still present in 2.10.0-4?!

[Michael Biebl]

Am 05.08.23 um 10:56 schrieb Farblos:

On 2023-08-04  22:54, Michael Biebl wrote:

Since I myself can't reproduce the issue anymore with 2.10.0-4, I'm 
going to close this bug report again and you ask you to report this 
upstream as a separate issue.


Just one more round-trip with you, please:

It seems that you cherry-picked commit 
521265ae0e71426a608cdc6bff5f828c7b788dc0 only, but in 
https://github.com/storaged-project/udisks/pull/1148 tbzatek mentions:


 > Needs storaged-project/libblockdev#941

Could this be the reason?  Or have you included that as well without me 
noticing it?


The libblockdev 3.0.2-1 release includes this commit.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#986971: sendxmpp: Sendxmpp doesn't work with current XMPP servers

[Erik Huelsmann]

Much of this seems to be caused by the fact that there was no support for
SCRAM-SHA-1 authentication in Perl. I've started work to add exactly that:
https://metacpan.org/release/EHUELS/Authen-SASL-SCRAM-0.01-TRIAL

Just installing this library on my server allowed me to authenticate
against my own ejabberd server using SCRAM-SHA-512. Before, I could only
authenticate against my server when the PLAIN authentication was also
enabled. I'll be filing an RFP bug when the package publishes on CPAN and a
wishlist bug against sendxmpp to add this library as a dependency.

Bug#1043053: toot: Please provide a backport

[Martin Dosch]

Package: toot
Version: 0.34.1-1
Severity: wishlist

Dear Maintainer,

I would appreciate if you'd be willing to provide backports for toot, so 
that people using stable would be able to benefit from upstream 
improvements.

Best regards,
Martin

-- System Information:
Debian Release: 12.1
  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 6.1.0-10-amd64 (SMP w/4 CPU threads; 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)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.11.2-1+b1
ii  python3-bs4   4.11.2-2
ii  python3-requests  2.28.1+dfsg-1
ii  python3-urwid 2.1.2-4+b1
ii  python3-wcwidth   0.2.5+dfsg1-1.1

toot recommends no packages.

toot suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

[Sven Joachim]

On 2023-08-05 11:46 +0200, Vincent Lefevre wrote:

> On 2023-08-04 18:06:24 +0200, Sven Joachim wrote:
>> On 2023-08-04 01:57 +0200, Vincent Lefevre wrote:
>>
>> > On 2023-08-03 16:52:07 +0200, Sven Joachim wrote:
> [...]
>> >> It should prevent these errors from showing up in the first place.
>> >
>> > If aptitude knows what to do (or may ignore the issue), yes.
>>
>> I was a bit imprecise, actually I meant that aptitude-changelog-parser
>> should not emit these warnings to stderr, which is what #967911 is about.
>>
>> >> See #967911, which has been tagged "pending" almost three years ago. :-(
>> >
>> > I forgot about this one.
>>
>> Since the screen flashes created by aptitude-changelog-parser's warnings
>> have been annoying me for so long, I have now created a merge request to
>> cherry-pick the fix for unstable:
>>
>> https://salsa.debian.org/apt-team/aptitude/-/merge_requests/20
>
> First, I don't understand
>
>   But we cannot currently change that verbose default when using
>   changelog_parse() from Dpkg::Changelog::Parse.
>
> in the patch. The following works as expected:
>
> --- a/aptitude-changelog-parser   2022-08-06 05:45:53.0 +0200
> +++ b/aptitude-changelog-parser   2023-08-05 10:55:39.291911672 +0200
> @@ -15,6 +15,7 @@
>  # Usage: aptitude-changelog-parser [ []]
>
>  my %opts;
> +$opts{verbose} = 0;
>  if (scalar @ARGV >= 1) {
>  $opts{file} = shift @ARGV;
>  }

Ah yes, Guillem implemented the "verbose" option three years ago in
reaction to #967911.  And it could not be used back then because the
dpkg version offering it was only uploaded several months later, but now
it certainly can be used. :-)

Would you like to submit a merge request on salsa for the master branch?

Cheers,
   Sven

Bug#1043014: (no subject)

[Nicola Ferralis]

Patches for Ubuntu Mantic have been discussed and approved:

https://bugs.launchpad.net/ubuntu/+source/blender/+bug/2029503

Patch available:

https://git.launchpad.net/~ahasenack/ubuntu/+source/blender/tree/debian/patches/0004-fix-support-ffmpeg6.patch?h=mantic-blender-ftbfs-ffmpeg6

Bug#1042753: nouveau bug in linux/6.1.38-2

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/dri-devel/20be6650-5db3-b72a-a7a8-5e817113c...@kravcenko.com/
 https://lore.kernel.org/dri-devel/20230805101813.2603989-1-kher...@redhat.com/
Control: tag -1 - moreinfo

On Saturday, 5 August 2023 11:44:22 CEST Olaf Skibbe wrote:
> On Sat, 5 Aug 2023 at 01:09, Karol Herbst wrote:
> > Mind checking if instead of reverting the entire commit that this is
> > enough to fix it as well?
> > 
> > https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/f99ae069876f7f
> > feb6368da0381485e8c3adda43.patch
> This patch does fix the problem as well: Screen works.

And this caused a patch proposal fixing the issue \o/
https://lore.kernel.org/dri-devel/20230805101813.2603989-1-kher...@redhat.com/

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

Bug#1042818: firmware-amd-graphics: Random display freezes on certain AMD GPUs

[Diederik de Haas]

Hi,

Thanks for looking into this, but I have some questions.

On Tuesday, 1 August 2023 12:55:55 CEST Gregor Riepl wrote:
> Forwarded: https://gitlab.freedesktop.org/drm/amd/-/issues/1887

On Saturday, 5 August 2023 10:55:10 CEST Gregor Riepl wrote:
> Version: 20230515-3
> Tags: fixed-upstream, upstream
> 
> linux-firmware 20230804 has been released and contains the mentioned reverts
> for amdgpu firmware.

Upstream commit d3f66064cf43bd7338a79174bd0ff60c4ecbdf6d titled:
Partially revert "amdgpu: DMCUB updates for DCN 3.1.4 and 3.1.5"

That does indeed seem relevant to the error msgs you posted in this bug.
That commit links to https://gitlab.freedesktop.org/drm/amd/-/issues/2666 
which is rather different from the 'Forwarded' URL/issue.
Was the initial Forwarded incorrect or am I missing something?

"This partially reverts commit ade163aaaeae0c1ad20cb3dd8ce878bf61c91b3a" is 
also part of that commit msg, but that commit was NOT part of version 
20230515, but 20230625 which has not (yet?) been uploaded to Debian.

Which leads me to conclude that you shouldn't have been affected as Debian's 
firmware package (version) does not include the commit which caused the issue.
Can you shed some light on this discrepancy?

> This should also fix #1040185, but for that issue, a backport to bookworm
> may be required.

Similar as above as it shouldn't have the commit _causing_ the issue.

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

Bug#1043052: wine: d3d9 doesn't work on WS_CHILD windows

[Alfred Agrell]

Package: wine
Version: 8.0~repack-4
Severity: normal
X-Debbugs-Cc: blub...@gmail.com

Dear Maintainer,

please compile and run the following program (x86_64-w64-mingw32-gcc test.c 
-ld3d9 && wine a.exe):



#include 
#include 
#include 
#include 

HWND wnd_parent;
HWND wnd;
int f;

LRESULT myWindowProcA(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
printf("%d %u %d\n", hWnd==wnd, Msg, f++);
if (Msg == WM_CLOSE)
exit(0);
return DefWindowProcA(hWnd, Msg, wParam, lParam);
}

int main()
{
WNDCLASSEXA wcex = { sizeof(WNDCLASSEX), CS_DBLCLKS, myWindowProcA, 0L, 
0L, NULL, NULL, NULL, NULL, NULL, "windowclass", NULL };
RegisterClassEx();

WNDCLASSEXA wcex2 = { sizeof(WNDCLASSEX), 0, myWindowProcA, 0L, 0L, 
NULL, NULL, NULL, NULL, NULL, "windowclass_child", NULL };
RegisterClassEx();

uint32_t wstyle = 
WS_CAPTION|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE|WS_SYSMENU|WS_MINIMIZEBOX;
uint32_t wstyleex = 
WS_EX_ACCEPTFILES|WS_EX_WINDOWEDGE|WS_EX_CONTROLPARENT;
wnd_parent = CreateWindowExA(wstyleex, "windowclass", "parent", wstyle, 
0, 0, 640, 480, NULL, NULL, NULL, NULL );
ShowWindow(wnd_parent, SW_SHOWDEFAULT);
UpdateWindow(wnd_parent);

wnd = CreateWindowExA(0, "windowclass_child", "child", WS_CHILD, 0, 0, 
320, 240, wnd_parent, NULL, NULL, NULL );
ShowWindow(wnd, SW_SHOWDEFAULT);
UpdateWindow(wnd);

IDirect3D9* d3d = Direct3DCreate9(D3D_SDK_VERSION);
DWORD   BehaviorFlags = D3DCREATE_SOFTWARE_VERTEXPROCESSING | 
D3DCREATE_MULTITHREADED;

D3DPRESENT_PARAMETERS d3dpp = {};
D3DDISPLAYMODE  dm;
IDirect3D9_GetAdapterDisplayMode(d3d, D3DADAPTER_DEFAULT, );
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_COPY;
d3dpp.BackBufferFormat = dm.Format;
d3dpp.BackBufferHeight = 640;
d3dpp.BackBufferWidth = 480;
d3dpp.hDeviceWindow = wnd_parent;

IDirect3DDevice9* d3ddev;
IDirect3D9_CreateDevice(d3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, 
BehaviorFlags, , );

IDirect3D9* d3d2 = Direct3DCreate9(D3D_SDK_VERSION);
d3dpp.hDeviceWindow = wnd;
IDirect3DDevice9* d3ddev2;
IDirect3D9_CreateDevice(d3d2, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, 
BehaviorFlags, , );

for (int frame=0;frame<600;frame++)
{
IDirect3DDevice9_Clear(d3ddev, 
0,NULL,D3DCLEAR_TARGET,D3DCOLOR_RGBA(255,0,frame*4,0),1.0f,0);
IDirect3DDevice9_Present(d3ddev, NULL, NULL, NULL, NULL );

IDirect3DDevice9_Clear(d3ddev2, 
0,NULL,D3DCLEAR_TARGET,D3DCOLOR_RGBA(0,255,frame*4,0),1.0f,0);
IDirect3DDevice9_Present(d3ddev2, NULL, NULL, NULL, NULL );

MSG msg;
while( (PeekMessage( , NULL, 0, 0, PM_REMOVE )) != 0)
{ 
TranslateMessage(); 
DispatchMessage(); 
} 
}
}



Expected behavior:

Should show an animated green-teal rectangle, and an animated red-magenta L 
shape.


Actual behavior:

Shows a black rectangle, and the expected red-magenta L shape. Dragging another 
window over the black rectangle leaves the pixels unchanged, duplicating the 
window border a bunch of times.


I have verified that the expected result shows up
- if I build Wine 8.0 from source
- if I build latest Wine git from source (somewhere around version 8.13)
- on Ubuntu 22.04's Wine package (6.0.3~repack-1)
- on Arch's Wine package (8.13-1)
- on Windows 7
- on Windows 10
therefore I believe that this bug is Debian-specific somehow.


-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

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

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

Versions of packages wine depends on:
ii  wine32  8.0~repack-4
ii  wine64  8.0~repack-4

wine recommends no packages.

Versions of packages wine suggests:
ii  dosbox0.74-3-4+b1
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
pn  winetricks

Versions of packages libwine depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9+deb12u1
ii  libcapi20-3  1:3.27-3+b1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libglib2.0-0   

Bug#1043048: openblas: gives wrong results on mips64el, ignores test failures

[Sébastien Villemot]

Dear Rebecca,

Thanks for your report.

Le samedi 05 août 2023 à 09:25 +0100, Rebecca N. Palmer a écrit :
> Package: libopenblas0-pthread
> Version: 0.3.23+ds-2
> Control: affects -1 src:statsmodels
> Severity: serious
> Justification: the default BLAS should NOT silently give wrong answers
> (i.e. if there's no easy way to actually fix this, please switch the 
> default on mips64el back to atlas, and consider removing this package 
> from mips64el)
> 
> statsmodels recently (between 0.14.0+dfsg-1 and -2) started to FTBFS on 
> mips64el with multiple wrong test results.  The most obviously relevant 
> change between those is that the installed BLAS changed from atlas to 
> openblas.
> 
> openblas' own tests on mips64el ( 
> https://buildd.debian.org/status/fetch.php?pkg=openblas=mips64el=0.3.23%2Bds-2=1686760279=0
>  
> ) have 64 instances of "FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF 
> ACCURATE".  (I don't know why this isn't failing the build, which is 
> possibly a bug in itself.)
> 
> openblas upstream are not _obviously_ aware of this.  Given the 
> existence of .github/workflows/mips64.yml, this suggests it _may_ be 
> nontrivial to reproduce in qemu.

It looks like version 0.3.21+ds-4 is not affected by this issue and
passes its testsuite. Can you possibly check whether statsmodels builds
against that version?

My guess is that this bug is caused by the switch to the MIPS64_GENERIC
kernel that I made in version 0.3.22+ds-1. If this is indeed the cause,
then an easy short term fix is to roll back this change and go back to
the SICORTEX kernel. For a longer term fix, I would need to work with
upstream to determine why the MIPS64_GENERIC kernel is broken.

Also note that in any case, using ATLAS is not a good solution because
we are considering its removal, see the thread on debian-science@.¹
BLIS is a better alternative to OpenBLAS.

I also agree that the fact that the OpenBLAS testsuite fails without
triggering an FTBFS is abnormal. I’m surprised by this, and this should
be investigated.

Cheers,


¹
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org




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

Bug#1043051: rust-rustls-webpki: Fails to build without internet access

[Jeremy Bícha]

Source: rust-rustls-webpki
Version: 0.101.2-1
Severity: serious
Tags: ftbfs

rust-rustls-webpki fails to build without internet access

Full build log
==
https://launchpad.net/ubuntu/+source/rust-rustls-webpki/0.101.2-1/+latestbuild/amd64

Build log excerpt
=
   dh_auto_test -O--buildsystem=cargo
/<>/debian/dh-cargo/bin/cargo test
debian cargo wrapper: options, profiles, parallel: ['parallel=8'] [] ['-j8']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
x86_64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1',
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose',
'--verbose', '-j8', '--target', 'x86_64-unknown-linux-gnu',
'--release'],) {}
Updating git repository `https://github.com/est31/rcgen.git`
warning: spurious network error (2 tries remaining): failed to resolve
address for github.com: Temporary failure in name resolution;
class=Net (12)
warning: spurious network error (1 tries remaining): failed to resolve
address for github.com: Temporary failure in name resolution;
class=Net (12)
error: failed to load source for dependency `rcgen`

Caused by:
  Unable to update https://github.com/est31/rcgen.git

Caused by:
  failed to clone into:
/<>/debian/cargo_home/git/db/rcgen-8bc4158ba396894b

Caused by:
  network failure seems to have happened
  if a proxy or similar is necessary `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  failed to resolve address for github.com: Temporary failure in name
resolution; class=Net (12)
dh_auto_test: error: /<>/debian/dh-cargo/bin/cargo test
returned exit code 101

Thank you,
Jeremy Bícha

Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

[Vincent Lefevre]

On 2023-08-04 18:06:24 +0200, Sven Joachim wrote:
> On 2023-08-04 01:57 +0200, Vincent Lefevre wrote:
> 
> > On 2023-08-03 16:52:07 +0200, Sven Joachim wrote:
[...]
> >> It should prevent these errors from showing up in the first place.
> >
> > If aptitude knows what to do (or may ignore the issue), yes.
> 
> I was a bit imprecise, actually I meant that aptitude-changelog-parser
> should not emit these warnings to stderr, which is what #967911 is about.
> 
> >> See #967911, which has been tagged "pending" almost three years ago. :-(
> >
> > I forgot about this one.
> 
> Since the screen flashes created by aptitude-changelog-parser's warnings
> have been annoying me for so long, I have now created a merge request to
> cherry-pick the fix for unstable:
> 
> https://salsa.debian.org/apt-team/aptitude/-/merge_requests/20

First, I don't understand

  But we cannot currently change that verbose default when using
  changelog_parse() from Dpkg::Changelog::Parse.

in the patch. The following works as expected:

--- a/aptitude-changelog-parser 2022-08-06 05:45:53.0 +0200
+++ b/aptitude-changelog-parser 2023-08-05 10:55:39.291911672 +0200
@@ -15,6 +15,7 @@
 # Usage: aptitude-changelog-parser [ []]
 
 my %opts;
+$opts{verbose} = 0;
 if (scalar @ARGV >= 1) {
 $opts{file} = shift @ARGV;
 }

This silences warnings from

sub parse_error {
my ($self, $file, $line_nr, $error, $line) = @_;

push @{$self->{parse_errors}}, [ $file, $line_nr, $error, $line ];

if ($self->{verbose}) {
if ($line) {
warning("%20s(l$line_nr): $error\nLINE: $line", $file);
} else {
warning("%20s(l$line_nr): $error", $file);
}
}
}

in /usr/share/perl5/Dpkg/Changelog.pm.

Now, silenting such warnings for changelog_parse() will fix issues
like this one, but it will not fix the general problem with warnings
and errors.

For instance, aptitude-changelog-parser has

eval {
require Dpkg::Changelog::Parse;
Dpkg::Changelog::Parse->import();
1;
} or do {
warn "warning: Dpkg::Changelog::Parse not present, install libdpkg-perl\n";
exit 0;
};

at the beginning, and this warning, which is important and must still
be output, will still quickly disappear. BTW, the "exit 0;" is also
incorrect, but that's another issue (bug 1043050, which I've just
reported).

And concerning errors, /usr/share/perl5/Dpkg/Changelog/Parse.pm has

error(g_('changelog format %s is unknown: %s'), $format, $@) if $@;
error(g_('changelog format %s is not a Dpkg::Changelog class'), $format)
unless $changes->isa('Dpkg::Changelog');

and

error(g_('unknown output format %s'), $options{format});

In /usr/share/perl5/Dpkg/ErrorHandling.pm, this corresponds to

sub error($;@)
{
die report(REPORT_ERROR, @_);
}

This will not be silenced by "$SIG{__WARN__} = sub {};" like in your
patch. I don't think these fatal errors should be silenced at all,
but currently, they will also quickly disappear.

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

Bug#1042753: nouveau bug in linux/6.1.38-2

[Olaf Skibbe]

On Sat, 5 Aug 2023 at 01:09, Karol Herbst wrote:


Mind checking if instead of reverting the entire commit that this is
enough to fix it as well?

https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/f99ae069876f7ffeb6368da0381485e8c3adda43.patch


This patch does fix the problem as well: Screen works.

Cheers,
Olaf

Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.

[Bastien]

Hi Max and Josef,

Max Nikulin  writes:

> I do not see any value in having this bug in the open state, but I am
> leaving decision up to you. 

I tested with the latest Org version and the bug is still there.

May I suggest to the OP (Josef?) to share the bug upstream on the
Org-mode list, if not already done?

Even if it's a minor gotcha, it deserves to be fixed.

Bugs are reported on the mailing list and tracked on
https://updates.orgmode.org.

> Despite some conflict of licenses, I do not think it is possible to
> avoid reading of the Org mode manual. It may benefit from a note on
> ambiguous syntax. Currently it has some references to zero width space
> hack only
> https://orgmode.org/manual/Escape-Character.html
> that has some drawbacks and not applicable to links.
> https://orgmode.org/manual/Link-Format.html
> Discusses escaping of brackets only disregarding possible interference
> with other markup structures.
> https://orgmode.org/manual/Plain-Lists.html
> does not mention possible issues as well.

I'd rather have the Org manual document the standard syntax and some
edge cases, when frequently reported.  But such "hacks" rather belong
to this page on Worg: https://orgmode.org/worg/org-hacks.html

HTH,

-- 
 Bastien

Bug#1000113: kodi: depends on obsolete pcre3 library

[Adrian Bunk]

On Thu, Jul 06, 2023 at 08:47:59AM +0100, Matthew Vernon wrote:
> Hi,
> 
> On 06/07/2023 06:33, Vasyl Gello wrote:
> 
> > Yes I definitely see the bug. However, Kodi extensively uses pcrecpp and
> > the only replacement I see for pcre2 is jpcre2 [1]
> > There is an ITP bug about it since 2017 but no package.
> > 
> > Matthew, from your experience, is jpcre2 the only C++ wrapper for pcre2
> > or there is something more recommended / maintainable?
> > I did the search but found only jpcre2.
> 
> I should say that I'm not C++ expert; jpcre2 is the only wrapper I find by
> web-searching. I think, though, that it should be possible to use the pcre2
> libraries from C++ in the usual way that you can call C libraries from C++
> (and the headers have the usual extern "C" magic)...

Another option would be to use the vendored copy of PCRE until upstream 
supports PCRE2.

Using a vendored copy of a library is usually not an RC bug.

We do have a package that added and builds a copy of Python 2.7 before 
building itself after to the Python2 removal, so that would be a rather
minor vendoring in comparison.

> Regards,
> 
> Matthew

cu
Adrian

Bug#1037668: closed by Debian FTP Masters (reply to Stephan Lachnit ) (Bug#1037668: fixed in gamescope 3.11.51-1)

[Adrian Bunk]

On Fri, Jul 21, 2023 at 12:54:04AM +, Debian Bug Tracking System wrote:
>...
>  gamescope (3.11.51-1) experimental; urgency=medium
>...
>* Upload to experimental due to wlroots 0.16.0
>* Fix compilation with GCC-13 (Closes: #1037668)
>...

Could you upload to unstable now that wlroots 0.16.2 is there?

Thanks
Adrian

Bug#1041707: qemu-system-ppc: ppc QEMU serial appears to have a maximum ratio of output to input, hides output and only writes it on subsequent input(?!)

[Michael Tokarev]

22.07.2023 16:41, наб пишет:

Package: qemu-system-ppc
Version: 1:7.2+dfsg-7
Severity: normal

Dear Maintainer,

Sorry for the psycho subject. Please see video:
I paste in a file in pieces, and only get a few dozen bytes of echo
on each paste. Then, when I'm done pasting, I keep getting chunks of the
file when mashing the keyboard.


I dunno what to od with this bug report.  Please submit this report to the
upstream bug tracking system, https://gitlab.com/qemu-project/qemu/-/issues

Also please try at least qemu 8.0, or better yet - 8.1-rc2 from experimental.
The chance it works better is not high, but not zero either.

Thanks,

/mjt

Bug#1043050: aptitude: incorrect exit value in aptitude-changelog-parser

[Vincent Lefevre]

Package: aptitude
Version: 0.8.13-5
Severity: normal
Tags: patch

/usr/bin/aptitude-changelog-parser has:

eval {
require Dpkg::Changelog::Parse;
Dpkg::Changelog::Parse->import();
1;
} or do {
warn "warning: Dpkg::Changelog::Parse not present, install libdpkg-perl\n";
exit 0;
};

But in case the second part is executed, aptitude displays nothing,
and the user has the impression that it is still waiting for data.
Changing the exit value to 1 makes aptitude display the old (cached?)
logs. See attached patch.

Note: there's still the issue that the warning disappears immediately
(this is similar to bug 1042897).

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20230625
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffc1f9ed000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7fc184ae6000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fc18420)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fc184aad000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fc184a78000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fc184a6f000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fc18450e000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fc184099000)
libboost_iostreams.so.1.74.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7fc184a55000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fc183e0)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fc184a5)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fc183a0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc18442f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fc184a2a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc18381e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc184a25000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fc18407a000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fc18441c000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fc18404b000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fc183dda000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7fc183d1a000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 
(0x7fc183ce8000)
libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fc18373f000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fc1835f9000)
libxxhash.so.0 => /usr/lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7fc184036000)
/lib64/ld-linux-x86-64.so.2 (0x7fc184b17000)
libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 
(0x7fc183cde000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7fc183cd2000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fc183caa000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.7.3
ii  libboost-iostreams1.74.0  1.74.0+ds1-22
ii  libc6 2.37-6
ii  libcwidget4   0.5.18-6
ii  libgcc-s1 13.2.0-1
ii  libncursesw6  6.4+20230625-2
ii  libsigc++-2.0-0v5 2.12.0-1
ii  libsqlite3-0  3.42.0-1
ii  libstdc++613.2.0-1
ii  libtinfo6 6.4+20230625-2
ii  libxapian30   1.4.22-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.21.22
ii  sensible-utils  0.0.20

Versions of packages aptitude suggests:
ii  apt-xapian-index0.53
ii  aptitude-doc-en [aptitude-doc]  0.8.13-5
pn  debtags 
ii  tasksel 3.73

-- no debconf information

-- 
Vincent 

Bug#1043049: aptitude: please consider adding progress bar like apt when upgrading

[waxhead]

Package: aptitude
Version: 0.8.13-5
Severity: wishlist
X-Debbugs-Cc: waxh...@dirtcellar.net

Dear Maintainer,

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

   * What led up to the situation?

When upgrading packages with aptitude there is no indicator showing progress 
unlike apt.
Please consider add an apt-like progress bar. Thanks.

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

N/A

   * What was the outcome of this action?

N/A

   * What outcome did you expect instead?

N/A

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


-- Package-specific info:
Terminal: tmux-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20230625
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd598b8000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fe2263e4000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fe2263ab000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fe226376000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fe226a24000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fe226284000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fe22611d000)
libboost_iostreams.so.1.74.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7fe226105000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fe225e0)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fe226a1d000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fe225a0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe225d21000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fe2260e1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe22581e000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fe2260c2000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fe2260af000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fe22608)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7fe22605a000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fe225c61000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fe2257ec000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fe22570d000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fe2255c7000)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7fe226045000)
/lib64/ld-linux-x86-64.so.2 (0x7fe226a2f000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fe226039000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7fe2255bb000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fe225593000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.6.1
ii  libboost-iostreams1.74.0  1.74.0+ds1-22
ii  libc6 2.37-6
ii  libcwidget4   0.5.18-6
ii  libgcc-s1 13.2.0-1
ii  libncursesw6  6.4+20230625-2
ii  libsigc++-2.0-0v5 2.12.0-1
ii  libsqlite3-0  3.42.0-1
ii  libstdc++613.2.0-1
ii  libtinfo6 6.4+20230625-2
ii  libxapian30   1.4.22-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.21.22
ii  sensible-utils  0.0.20

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 3.73

-- no debconf information

Bug#1041649: [Pkg-utopia-maintainers] Bug#1041649: Bug still present in 2.10.0-4?!

[Farblos]

On 2023-08-04  22:54, Michael Biebl wrote:

Since I myself can't reproduce the issue anymore with 2.10.0-4, I'm 
going to close this bug report again and you ask you to report this 
upstream as a separate issue.


Just one more round-trip with you, please:

It seems that you cherry-picked commit 
521265ae0e71426a608cdc6bff5f828c7b788dc0 only, but in 
https://github.com/storaged-project/udisks/pull/1148 tbzatek mentions:


> Needs storaged-project/libblockdev#941

Could this be the reason?  Or have you included that as well without me 
noticing it?


Thanks

Bug#1042818: firmware-amd-graphics: Random display freezes on certain AMD GPUs

[Gregor Riepl]

Package: firmware-amd-graphics
Version: 20230515-3
Tags: fixed-upstream, upstream
Followup-For: Bug #1042818
X-Debbugs-Cc: onit...@gmail.com

linux-firmware 20230804 has been released and contains the mentioned reverts
for amdgpu firmware.
This is not a permanent fix of the underlying problem, but it will at least
allow systems to function normally again.

Please update as soon as possible.
This should also fix #1040185, but for that issue, a backport to bookworm may
be required.

Thanks.


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

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1043034: pipewire-pulse: Missing dependencie(s) or incomplete

[Dylan Aïssi]

Hi,

Le ven. 4 août 2023 à 23:21, Jiff  a écrit :
>
> Ze error :
> ==
> Uninstall *pulse* except those required by other packages.
>
> Ze cure :
> =
> apt install pavucontrol paprefs
>

I don't understand what is your issue, can you elaborate?
pavucontrol and paprefs are not dependencies of pipewire.

Best regards,
Dylan

Bug#1043024: amdgpu: When updating I get a "Possible missing firmware /lib/firmware/amdgpu/modules" (Sapphire Nitro R9 390)

[Gregor Riepl]

Package: firmware-amd-graphics
Version: 20230515-3
Followup-For: Bug #1043024
X-Debbugs-Cc: onit...@gmail.com

Can you post which firmware files are missing exactly?

dmesg should give you all the needed information.


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

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1026965: ACPI Error: Needed [Integer/String/Buffer], found [Package]

[Albert Nash]

noowner 1026965
thanks
I don't have the laptop at my disposal any longer. Please someone else take 
ownership of the bug.
Albert.

Bug#1043048: openblas: gives wrong results on mips64el, ignores test failures

[Rebecca N. Palmer]

Package: libopenblas0-pthread
Version: 0.3.23+ds-2
Control: affects -1 src:statsmodels
Severity: serious
Justification: the default BLAS should NOT silently give wrong answers
(i.e. if there's no easy way to actually fix this, please switch the 
default on mips64el back to atlas, and consider removing this package 
from mips64el)


statsmodels recently (between 0.14.0+dfsg-1 and -2) started to FTBFS on 
mips64el with multiple wrong test results.  The most obviously relevant 
change between those is that the installed BLAS changed from atlas to 
openblas.


openblas' own tests on mips64el ( 
https://buildd.debian.org/status/fetch.php?pkg=openblas=mips64el=0.3.23%2Bds-2=1686760279=0 
) have 64 instances of "FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF 
ACCURATE".  (I don't know why this isn't failing the build, which is 
possibly a bug in itself.)


openblas upstream are not _obviously_ aware of this.  Given the 
existence of .github/workflows/mips64.yml, this suggests it _may_ be 
nontrivial to reproduce in qemu.

Bug#888900: closed by Carsten Schoenert (Re: reassign 888900 to src:thunderbird)

[Carsten Schoenert]

My previous statement about IA64 isn't a supported architecture any more
isn't true, IA64 is still within the ports section.

But I won't reopen this report as I'm not able and willing to keep also
track of an non RC architecture for Thunderbird. Keep Thunderbird in a
buildable state for the current RC architectures (execpt the already
removes architectures here) is taken mostly all the avaiable time and
energy.

If some non RC architecture want to be more supported by someone please
work on usptreaming first the needed patches.

Regards
Carsten

Bug#1043047: spirv-llvm-translator-16, some more symbols updated

[Gianfranco Costamagna]

Source: spirv-llvm-translator-16
Version: 16.0.0-3
tags: patch

Hello, some more symbols are now optional :)

diff -Nru spirv-llvm-translator-16-16.0.0/debian/libllvmspirvlib16.symbols 
spirv-llvm-translator-16-16.0.0/debian/libllvmspirvlib16.symbols
--- spirv-llvm-translator-16-16.0.0/debian/libllvmspirvlib16.symbols
2023-08-04 12:09:10.0 +0200
+++ spirv-llvm-translator-16-16.0.0/debian/libllvmspirvlib16.symbols
2023-08-05 09:41:01.0 +0200
@@ -42,7 +42,7 @@
  _ZN4llvm39initializeSPIRVLowerConstExprLegacyPassERNS_12PassRegistryE@Base 13
  _ZN4llvm39initializeSPIRVLowerOCLBlocksLegacyPassERNS_12PassRegistryE@Base 13
  _ZN4llvm39initializeSPIRVRegularizeLLVMLegacyPassERNS_12PassRegistryE@Base 13
- _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE@Base 16
+ (optional=lto)_ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE@Base 16
 #MISSING: 16# 
_ZN4llvm44initializeSPIRVLowerSaddIntrinsicsLegacyPassERNS_12PassRegistryE@Base 
15
  
_ZN4llvm46createSPIRVLowerBitCastToNonStandardTypeLegacyERKN5SPIRV14TranslatorOptsE@Base
 14
  
_ZN4llvm46initializeSPIRVLowerSaddWithOverflowLegacyPassERNS_12PassRegistryE@Base
 16
@@ -425,8 +425,8 @@
  
(optional=templinst|subst)_ZSt17__rotate_adaptiveIN9__gnu_cxx17__normal_iteratorIPSt4pairIjjESt6vectorIS3_SaIS3_S4_{ssize_t}ET_S9_S9_S9_T1_SA_T0_SA_@Base
 13
 #MISSING: 16.0.0-3~gcc13# _ZSt19piecewise_construct@Base 16
 #MISSING: 14.0.0-7~gcc13# (optional=templinst|arch=amd64 arm64 
x32)_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_@Base
 0
- _ZTIN4llvm3Any11StorageBaseE@Base 16
- _ZTIN4llvm3Any11StorageImplIPKNS_6ModuleEEE@Base 16
+ (optional=lto)_ZTIN4llvm3Any11StorageBaseE@Base 16
+ (optional=lto)_ZTIN4llvm3Any11StorageImplIPKNS_6ModuleEEE@Base 16
  (arch=armel riscv64)_ZTIN9__gnu_cxx7__mutexE@Base 13
  
_ZTINSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb0ELb0EEE@Base 
13
  
_ZTINSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb0ELb1EEE@Base 
13
@@ -451,8 +451,8 @@
  (arch=armel armhf)_ZTISt19_Sp_make_shared_tag@Base 13
  (optional=templinst|arch=armel 
riscv64)_ZTISt23_Sp_counted_ptr_inplaceINSt8__detail4_NFAINSt7__cxx1112regex_traitsIcSaIvELN9__gnu_cxx12_Lock_policyE1EE@Base
 13
  (optional=templinst|arch=!armel 
!riscv64)_ZTISt23_Sp_counted_ptr_inplaceINSt8__detail4_NFAINSt7__cxx1112regex_traitsIcSaIvELN9__gnu_cxx12_Lock_policyE2EE@Base
 13
- _ZTSN4llvm3Any11StorageBaseE@Base 16
- _ZTSN4llvm3Any11StorageImplIPKNS_6ModuleEEE@Base 16
+ (optional=lto)_ZTSN4llvm3Any11StorageBaseE@Base 16
+ (optional=lto)_ZTSN4llvm3Any11StorageImplIPKNS_6ModuleEEE@Base 16
  (arch=armel riscv64)_ZTSN9__gnu_cxx7__mutexE@Base 13
  
_ZTSNSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb0ELb0EEE@Base 
13
  
_ZTSNSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb0ELb1EEE@Base 
13
@@ -477,7 +477,7 @@
  _ZTSSt19_Sp_make_shared_tag@Base 13
  (optional=templinst|arch=armel 
riscv64)_ZTSSt23_Sp_counted_ptr_inplaceINSt8__detail4_NFAINSt7__cxx1112regex_traitsIcSaIvELN9__gnu_cxx12_Lock_policyE1EE@Base
 13
  (optional=templinst|arch=!armel 
!riscv64)_ZTSSt23_Sp_counted_ptr_inplaceINSt8__detail4_NFAINSt7__cxx1112regex_traitsIcSaIvELN9__gnu_cxx12_Lock_policyE2EE@Base
 13
- _ZTVN4llvm3Any11StorageImplIPKNS_6ModuleEEE@Base 16
+ (optional=lto)_ZTVN4llvm3Any11StorageImplIPKNS_6ModuleEEE@Base 16
  (optional=templinst|arch=armel 
riscv64)_ZTVSt23_Sp_counted_ptr_inplaceINSt8__detail4_NFAINSt7__cxx1112regex_traitsIcSaIvELN9__gnu_cxx12_Lock_policyE1EE@Base
 0
  (optional=templinst|arch=!armel 
!riscv64)_ZTVSt23_Sp_counted_ptr_inplaceINSt8__detail4_NFAINSt7__cxx1112regex_traitsIcSaIvELN9__gnu_cxx12_Lock_policyE2EE@Base
 0
  
(optional=templinst)_ZZNKSt7__cxx1112regex_traitsIcE16lookup_classnameIPKcEENS1_10_RegexMaskET_S6_bE12__classnames@Base
 0


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043046: Backups on workstations start only if the workstation is running at the planned time

[Armin Fuerst]

Package: backintime-common
Version: 1.3.3-4

I am using backintime on all my workstations for backups. It is 
scheduled with "every day". As they are workstations, there is no time, 
they are running reliably every day.
Before my update to bookworm, the backup was started shortly after the 
workstation was resumed or started if there is no existing backup for 
the current day. Since my update to bookworm, this is not working 
anymore, the backup is only started if the workstation is running at the 
specified time.

I have following cron-packages installed:
anacron
cron
cron-daemon-common

Bug#1043035: systemd has invalid dependency in sid for riscv64

[Michael Biebl]

Am 05.08.23 um 00:11 schrieb Michał B.:

Package: systemd

The systemd has invalid dependency in comparison to other packages. I am 
unable to debootstrap for riscv64 platform.


The build dependency is not invalid.
If you look at
https://buildd.debian.org/status/package.php?p=systemd
you will see that the package is in BD-Uninstallable state.
Following the chain, you end up with
https://buildd.debian.org/status/package.php?p=abseil=sid

Once that package abseil is fixed on riscv64, the issue should be gone.
In any case, not a bug in systemd.

Regards,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#967462: growl-for-linux: depends on deprecated GTK 2

[Kentaro HAYASHI]

Thank you for contribution.

It seems that the fix is reasonable.

On Mon, 24 Jul 2023 14:04:03 +0200 Bastian Germann
 wrote:
> Control: unblock 967462 by -1
> 
> I am uploading a NMU to DELAYED/10 to get rid of the build dependency
> libayatana-appindicator, which is not needed. The debdiff is attached
> and also available in git.

Bug#1042697: (no subject)

[Kentaro HAYASHI]

NOTE for sphinx 7 when it is landed into sid:

* doc/files.am should be patched to eliminate jquery.js and
  underscore.js dependency or use  python3-sphinxcontrib.jquery and so
  on.
* debian/control
  * add missing libjs-sphixdoc dependency.
* debian/groonga-doc.links should be updated.
  * drop jquery and underscore 
  * add other searchtools language_data sphihx_highlight doctools

Bug#1043022: udisks2: After 2.10 update problem with usb vfat external disk

[luca pedrielli]

Maybe solved with this commit:
https://github.com/storaged-project/udisks/commit/60179ee1a364fc8a4b32a45668abd9f75ebf0117

--
Saluti, Luca Pedrielli

Bug#1043045: transition: spatialite

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: spatial...@packages.debian.org
Control: affects -1 + src:spatialite
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-spatialite.html

SpatiaLite 5.1.0 bumped its SONAME requiring a transition.

All rdeps built successfully as summarized below.


Transition: spatialite

 libspatialite7 (5.0.1-3) -> libspatialite8 (5.1.0-1~exp1)

The status of the most recent rebuilds is as follows.

 gdal (3.7.1+dfsg-1)  OK
 librasterlite2   (1.1.0~beta1-3) OK
 spatialite-tools (5.0.1-2)   OK

 merkaartor   (0.19.0+ds-4)   OK
 osmcoastline (2.4.0-2)   OK
 qgis (3.28.9+dfsg-1) OK
 spatialite-gui   (2.1.0~beta1-2) OK


Kind Regards,

Bas

Bug#1008159: [PATCH] More MIME file types and URI scheme handlers in thunderbird.desktop

[Carsten Schoenert]

Hi Max,

this patch and also this bug report wasn't on my radar, it simply slipped
through.

I'm happy to add this to the Debian package build, but a small request
for modification I have.

Could you please cut all these additions into own peaces/patches?
By this it's more visible what the addition of adding a specific handler
is made of. And using git blame will make it easier to find what content
was added by which commit.

Regards
Carsten

Am Sat, Apr 01, 2023 at 05:50:53PM +0700 schrieb Max Nikulin:
> Control: tags -1 +patch
> 
> I have noticed that besides mid: (Message-ID) protocol more URI schemes
> supported by thunderbird are missed in the .desktop file. It can open e.g.
> .ics files from https://, but I do not think it should be added.
> 
> For symmetry I have added x-/non-x- counterparts to text/calendar and
> text/vcard types.
> 
> See the attachment for a patch.

> More MIME file types and URI scheme handlers in thunderbird.desktop
> 
>   * Thunderbird is capable to handle more URI schemes:
> -  USENET news links,
> - mid: RFC 2392 - Content-ID and Message-ID Uniform Resource Locators,
> - webcal: and webcals: calendars in iCalendar format,
> - add alternatives for .ics and .vcf files.
> (Closes: #1008159)
> 
> --- thunderbird_102.9.1-1/debian/thunderbird.desktop  2023-03-18 
> 12:09:36.0 +
> +++ thunderbird/debian/thunderbird.desktop2023-04-01 10:17:39.553667864 
> +
> @@ -9,7 +9,7 @@
>  Version=1.0
>  Icon=thunderbird
>  Categories=Network;Email;News;GTK;
> -MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/x-vcard;
> +MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/news;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/x-calendar;text/vcard;text/x-vcard;
>  StartupWMClass=thunderbird-default
>  StartupNotify=true
>  Name[ast]=Veceru de corréu Thunderbird