Bug#1025296: clementine: Core dump at startup, libprotobuf version mismatch

[smarios]

Package: clementine
Version: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: smar...@jaist.ac.jp

Dear Maintainer,

Clementine core dumps on startup, complaining about mismatched versions
of libprotobuf.

   * What led up to the situation?
Updating packages (and possibly libprotobuf).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried starting clementine from the command line.

Also tried to LD_PRELOAD libprotobuf.so.23 but this has no
effect, as clementine explicitly depends on libprotobuf.so.32

   * What was the outcome of this action?
Clementine crashes on startup, producing a core dump.

   * What outcome did you expect instead?
Clementine to startup normally and allow playback of music.

Furthermore, this also affects strawberry.

I'm attaching raw output from clementine crashing, below:

redacted@redacted:~$ clementine
[libprotobuf FATAL google/protobuf/stubs/common.cc:83] This program was 
compiled against version 3.12.4 of the Protocol Buffer runtime library, which 
is not compatible with the installed version (3.21.9).  Contact the program 
author for an update.  If you compiled the program yourself, make sure that 
your headers are from the same version of Protocol Buffers as your link-time 
library.  (Version verification failed in "gen/proto_out/ipc/ipc.pb.cc".)
terminate called after throwing an instance of 
'google::protobuf::FatalException'
  what():  This program was compiled against version 3.12.4 of the Protocol 
Buffer runtime library, which is not compatible with the installed version 
(3.21.9).  Contact the program author for an update.  If you compiled the 
program yourself, make sure that your headers are from the same version of 
Protocol Buffers as your link-time library.  (Version verification failed in 
"gen/proto_out/ipc/ipc.pb.cc".)
Aborted (core dumped)



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

Kernel: Linux 6.0.0-4-amd64 (SMP w/12 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 clementine depends on:
ii  gstreamer1.0-plugins-base   1.20.4-1
ii  gstreamer1.0-plugins-good   1.20.3-1+b1
ii  gstreamer1.0-plugins-ugly   1.20.3-1
ii  libasound2  1.2.8-1
ii  libc6   2.36-5
ii  libcdio19   2.1.0-4
ii  libchromaprint1 1.5.1-2+b1
ii  libcrypto++88.7.0+git220824-1
ii  libfftw3-double33.3.8-2
ii  libgcc-s1   12.2.0-9
ii  libglib2.0-02.74.1-2
ii  libgpod40.8.3-17
ii  libgstreamer-plugins-base1.0-0  1.20.4-1
ii  libgstreamer1.0-0   1.20.4-1
ii  liblastfm5-11.1.0-5
ii  libmtp9 1.1.20-1
ii  libmygpo-qt5-1  1.1.0-4
ii  libprotobuf32   3.21.9-5
ii  libpulse0   16.1+dfsg1-2+b1
ii  libqt5concurrent5   5.15.6+dfsg-4
ii  libqt5core5a5.15.6+dfsg-4
ii  libqt5dbus5 5.15.6+dfsg-4
ii  libqt5gui5  5.15.6+dfsg-4
ii  libqt5network5  5.15.6+dfsg-4
ii  libqt5sql5  5.15.6+dfsg-4
ii  libqt5sql5-sqlite   5.15.6+dfsg-4
ii  libqt5widgets5  5.15.6+dfsg-4
ii  libqt5x11extras55.15.6-2
ii  libsqlite3-03.40.0-1
ii  libstdc++6  12.2.0-9
ii  libtag1v5   1.13-1
ii  libx11-62:1.8.1-2
ii  zlib1g  1:1.2.11.dfsg-4.1

Versions of packages clementine recommends:
ii  gstreamer1.0-alsa1.20.4-1
ii  gstreamer1.0-pulseaudio  1.20.3-1+b1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.20.3-2+b1

-- no debconf information

Regards,

Bug#702914: libnet-server-perl: CVE-2013-1841: Improper reverse DNS matching check for the given hostname

[Salvatore Bonaccorso]

This issue has been fixed upstream in the 2.011 version.

Regards,
Salvatore

Bug#1014274: reverse dependencies

[Scott Ashcroft]

Hi,

I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32

Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack is returned to calling function.
Because the Debian build uses various hardening flags to protect
accesses to the stack that makes a segfault.

The quick fix appears to be to add:

-DFST_DO_MISALIGNED_OPS

to CPPFLAGS. (i386 and amd64 already have this hardwired in the code.)

I've tested this best I could by cross-compiling and running the binary
under qemu. It passed all the tests in tests/sat.

The real fix would be to either assume that all architectures can run
with FST_DO_MISALIGNED_OPS and remove the broken code or fix
fstGetUint32 so it returns memory allocated correctly, but either of
those is a job for upstream.

Cheers,
Scott

Bug#1025295: firefox-esr: Firefox stops rendering/refreshing the window content

[Christian Henz]

Package: firefox-esr
Version: 102.5.0esr-1~deb11u1
Severity: normal

Dear Maintainer,

Since the recent upgrade to version 102.5 a couple of weeks ago, Firefox
sometimes stops rendering/refreshing the window contents.

What I am seeing is consistent with upstream bug report
https://bugzilla.mozilla.org/show_bug.cgi?id=1781167

According to that report, the issue is due to be fixed in 102.6.


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 5.10.0-19-rt-amd64 (SMP w/2 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libasound2   1.2.4-1.1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u5
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.24-0+deb11u1
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  libxtst6 2:1.2.3-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.2.14-1~deb9u1
ii  libavcodec58  7:4.3.5-0+deb11u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6.1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-6+deb11u3
pn  pulseaudio 

-- no debconf information

Bug#1025234: prometheus: flaky autopkgtest (on 32 bit archs?)

[Daniel Swarbrick]

Hi Paul,

I have also noticed the fairly frequent failures of the memory-intensive 
tests on 32-bit, and I am doing my best to keep on top of them with 
t.Skip() patches where appropriate. Several of the tests result in the 4 
GiB memory footprint threshold being exceeded.


Prometheus itself is still usable on 32-bit, but obviously only up to a 
certain size. The upstream developers don't seem to consider 32-bit when 
writing unit tests, thus the regular addition of new tests which fail.


Daniel.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025294: RM: cov-core -- ROM; Dead Upstream; Unused; Merged Into Other Projects

[Boyuan Yang]

Package: ftp.debian.org
X-Debbugs-Cc: by...@debian.org
Severity: normal

Dear Debian FTP Masters,

Please remove src:cov-core [1] from Debian Sid archive. It used to be a
dependency for python3-pytest*, but its development has stopped back in 2014
and its functionality has merged into python3-pytest-cov many years ago.

[1] https://tracker.debian.org/pkg/cov-core

With recent package updates, src:cov-core now has no reverse dependencies and
reverse build-dependencies. (We may need to wait till src:python-stetl
2.1~dev0~20211124-009e39f-1 to migrate to Testing.)

Thanks,
Boyuan Yang


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

Bug#1025155: git: with "cherry-pick -x", the "cherry picked from commit" line should be preceded by a blank line

[Vincent Lefevre]

Control: retitle -1 git cherry-pick -x: the "cherry picked from commit" line is 
not preceded by a blank line when the last line starts with "note:"

On 2022-11-30 13:22:02 +0100, Vincent Lefevre wrote:
> When "git cherry-pick -x" is used, a "cherry picked from commit" line
> is added to the commit message. A blank line is usually added, but not
> always. A blank line should *always* be added.
[...]

After various tests, it seems that the blank line is forgotten
when the last line of the commit message starts with "note:"
(case insensitively).

For instance:

New commit

foo

nOtE:
(cherry picked from commit 3ba643e2eec4bdc1cd46b478ab36ee0707d241c2)

and

New commit

Note: foo.
(cherry picked from commit d0e85cdd32e30f78eeb968f275fc3a98899d791e)

but

New commit

note:
foo

(cherry picked from commit a0ffae22fd3c94210170a3addcf802804f6ee5f7)



New commit

A Note:

(cherry picked from commit 0a89e0e7f8be3063803b0ad4381cd848ec52dd39)



New commit

Note

(cherry picked from commit f217bd5069c9d66a8ca54c869919ff484a18d20c)

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

Bug#1025293: nmu: tpm2-tools_5.3-1

[Ying-Chun Liu (PaulLiu)]

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

nmu tpm2-tools_5.3-1 . ANY . unstable . -m "rebuild against latest tpm2-tss"

Dear release managers,

Please rebuild tpm2-tools. We have missing pkg-config dependencies
in tpm2-tss. So some of the command-line tool of tpm2-tools is not build
and install due to that.
Just rebuild tpm2-tools with tpm2-tss and those command-line tools
will be back.

Yours,
Paul



OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025292: open-vm-tools 12.1.5 has been released

[John Wolfe]

Package: open-vm-tools
Version: 12.1.5


open-vm-tools 12.1.5 was released on Nov. 29, 2022.

This release contains several fixes including:
  - The deployPkg plugin may prematurely reboot the guest VM before cloud-init
has completed user data setup
  - A SIGSEGV may be encountered when a non-quiescing snapshot times out.
  - A number of Coverity reported issues have been addressed.

For complete details, see: 
https://github.com/vmware/open-vm-tools/releases/tag/stable-12.1.5

Release Notes are available at: 
https://github.com/vmware/open-vm-tools/blob/stable-12.1.5/ReleaseNotes.md

The granular changes that have gone into the 12.1.5 release are in the 
ChangeLog at: 
https://github.com/vmware/open-vm-tools/blob/stable-12.1.5/open-vm-tools/ChangeLog

Bug#1025214: was: regression: dkms/3.0.8-2 renders zfs-dkms FTBFS

[M. Zhou]

Control: merge 1025214 1025171

The "MAKEFLAGS="--environment-overrides" also caused zfs-dkms FTBFS.
The two bugs above are the same issue, hence the merge.

Bug#1025291: ITP: libnginx-mod-http-set-misc -- Extended rewrite directives module for Nginx

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Nginx Maintainers 


* Package name: libnginx-mod-http-set-misc
  Version : 0.33
  Upstream Author : Yichun "agentzh" Zhang (章亦春) agen...@gmail.com
* URL : https://github.com/openresty/set-misc-nginx-module
* License : BSD-2-clause
  Programming Lang: C
  Description : Extended rewrite directives module for Nginx

 This module provides more directives that can be used in
 the Nginx rewrite phase, like the 'set' directive.
 - URI escaping and unescaping
 - JSON quoting
 - digests encoding and decoding
 - random number generator

This is another module that is part of a cache stack for Nginx,
along with srcache, and memc.
It is put in nginx-team, and I will upload it and take care of it.

Bug#1025290: xdx fails to open due to seg fault

[Ed Lawson]

Package: xdx
Version: 2.91-1
Severity: important
X-Debbugs-Cc: elaw...@grizzy.com

Dear Maintainer,

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

   * What led up to the situation?  XDX would not open after recent system
upgrade
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Nothing as package will not open/run.
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages xdx depends on:
ii  hamradio-files   20221125
ii  libc62.36-6
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.2-1
ii  libgtk-3-0   3.24.35-1
ii  libpango-1.0-0   1.50.10+ds-1

xdx recommends no packages.

Versions of packages xdx suggests:
ii  libhamlib-utils  4.5-2+b1

-- no debconf information

Bug#930247: grep: inconsistent behaviour with anchored regex containing back-references

[Thorsten Glaser]

Package: grep
Version: 3.6-1
Followup-For: Bug #930247
X-Debbugs-Cc: t...@mirbsd.de
Control: found 930247 3.8-3
Control: severity 930247 serious
Control: retitle 930247 grep: does not handle backreferences correctly, 
violating POSIX

I’m running into this, in stable and unstable both:

(sid-amd64)tglase@tglase:/tmp $ cat x
Total failed: 0
Total failed: 1 (1 ignored)
Total failed: 2 (1 ignored)
Total failed: 1 (2 ignored)
Total failed: 1
Total failed: 111
(sid-amd64)tglase@tglase:/tmp $ grep -e '^Total failed: 0$' -e '^Total failed: 
\([0-9]*\) (\1 ignored)$' x
Total failed: 0
Total failed: 1 (1 ignored)
Total failed: 2 (1 ignored)
Total failed: 1 (2 ignored)

By contrast, BSD handles it correctly:

tg@tglase-bsd:/tmp $ grep -e '^Total failed: 0$' -e '^Total failed: \([0-9]*\) 
(\1 ignored)$' x
Total failed: 0
Total failed: 1 (1 ignored)

POSIX:

3. The back-reference expression '\n' shall match the same (possibly
   empty) string of characters as was matched by a subexpression
   enclosed between "\(" and "\)" preceding the '\n'. The character

via 
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03
from https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html

Please fix this clear standards violation; it makes grep
virtually unusable.



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

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages grep depends on:
ii  dpkg  1.20.12
ii  install-info  6.7.0.dfsg.2-6
ii  libc6 2.31-13+deb11u5
ii  libpcre3  2:8.39-13

grep recommends no packages.

Versions of packages grep suggests:
ii  libpcre3  2:8.39-13

-- no debconf information

Bug#1025289: ITP: libnginx-mod-http-memc -- Extended memcached commands module for Nginx

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Nginx Maintainers 


* Package name: libnginx-mod-http-memc
  Version : 0.19
  Upstream Author : Yichun "agentzh" Zhang (章亦春) agen...@gmail.com
* URL : https://github.com/openresty/memc-nginx-module
* License : BSD-2-clause
  Programming Lang: C
  Description : Extended memcached commands module for Nginx

 This module supports almost the whole memcached ascii protocol,
 and provides many more commands than the embedded memcached
 module in Nginx.
 The libnginx-mod-http-srcache-filter module can be configured to
 use that module to cache responses.

This is nginx-team maintained and I will upload and take care of it.

Bug#961747: libstatgrab: Fix reproducibility issues in example Makefile

[Vagrant Cascadian]

Control: tags 961747 pending

On 2021-01-03, Vagrant Cascadian wrote:
> On 2020-05-28, Vagrant Cascadian wrote:
>> The example Makefile shipped in libstatgrab-dev changes depending on the
>> build path and if the system was build with a merged /usr
>> (a.k.a. usrmerge) filesystem layout.
>>
>> The attached patches fix these issues, though it might be worth
>> considering dropping the example Makefile from the package entirely; the
>> end-user would have to regenerate it themselves in order for it to be
>> functional.
>
> On further consideration, I think the better option is to ship
> Makefile.in and Makefile.am instead of the generated Makefile, allowing
> someone wishing to use the example to regenerate the Makefile to match
> thier system. Patch attached.

I have uploaded an NMU to DELAYED/10 fixing this issue:

diff -Nru libstatgrab-0.92.1/debian/changelog 
libstatgrab-0.92.1/debian/changelog
--- libstatgrab-0.92.1/debian/changelog 2021-12-27 22:53:19.0 -0800
+++ libstatgrab-0.92.1/debian/changelog 2022-12-01 15:36:31.0 -0800
@@ -1,3 +1,11 @@
+libstatgrab (0.92.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libstatgrab-dev.examples: Install Makefile.am and Makefile.in instead
+of Makefile. (Closes: #961747)
+
+ -- Vagrant Cascadian   Thu, 01 Dec 2022 
15:36:31 -0800
+
 libstatgrab (0.92.1-1) unstable; urgency=medium
 
   * The Akamai Technologies paid volunteer days release.
diff -Nru libstatgrab-0.92.1/debian/libstatgrab-dev.examples 
libstatgrab-0.92.1/debian/libstatgrab-dev.examples
--- libstatgrab-0.92.1/debian/libstatgrab-dev.examples  2005-10-09 
09:57:47.0 -0700
+++ libstatgrab-0.92.1/debian/libstatgrab-dev.examples  2022-12-01 
15:36:31.0 -0800
@@ -1,2 +1,2 @@
 examples/*.c
-examples/Makefile
+examples/Makefile.*


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1025288: ITP: libnginx-mod-http-srcache -- Transparent caching layer for Nginx

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Nginx Maintainers 


* Package name: libnginx-mod-http-srcache
  Version : 0.32
  Upstream Author : Yichun "agentzh" Zhang (章亦春) agen...@gmail.com
* URL : https://github.com/openresty/srcache-nginx-module
* License : BSD-2-clause
  Programming Lang: C
  Description : Transparent caching layer for Nginx

 This module provides a transparent caching layer for arbitrary nginx
 locations. The caching behavior is mostly compatible with RFC 2616.
 It allows full configuration through its nginx directives.

 - this package is awesome and I've been using it for many years.
   The ability to build it outside nginx source triggered the
   possibility to package it properly.
 - this will be maintained inside nginx team. I plan to be
   the uploader. Jan Mojžíš helped packaging it.

Bug#1025271: libgtk-3-0: Testing printer is available per default -> intentional?

[Simon McVittie]

On Thu, 01 Dec 2022 at 20:16:37 +0100, Roland Clobus wrote:
> with the new version there are now 100 test printers available per default.
> Is that change intentional?

No, that isn't intentional. I was trying to match the configuration we had
previously used with Autotools, which included --enable-test-print-backend...
but it looks like that option doesn't actually do anything, whereas the
corresponding Meson option works.

> Another change: the lpr backend is also made available per default.

It seems that wasn't previously enabled, so it's probably better to
go back to what was practically used with Autotools, meaning file and
cups. In the Autotools build, lpr was enabled if and only if cups isn't.

The reason I switched GTK from Autotools to Meson now is that upstream
have started talking about removing the ability to build with Autotools.

smcv

Bug#1025278: sra-toolkit: binary sratools installed on PATH

[Carl Suster]

Package: sra-toolkit
Version: 3.0.0+dfsg-1
Severity: wishlist

Dear Maintainer,

sra-toolkit installs a binary /usr/bin/sratools, which is intended to be used
via the symlinks installed by the package (since its behaviour is influenced by
the name of the executable):

lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/fasterq-dump -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/fastq-dump -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/prefetch -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/sam-dump -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/sra-pileup -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/srapath -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/vdb-dump -> sratools

Invoking the executable by its original name does nothing useful:

$  /usr/bin/sratools
An error occured: unrecognized tool sratools
If this continues to happen, please contact the SRA Toolkit at 
https://trace.ncbi.nlm.nih.gov/Traces/sra/

Perhaps sratools should be installed in a private directory like
/usr/lib/sra-toolkit, leaving only the symlinks in /usr/bin.

Given the absence of man pages for the tools, and not being familiar with them,
this caused me some confusion because it appeared something was broken.

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 sra-toolkit depends on:
ii  libbz2-1.0 1.0.8-5+b1
ii  libc6  2.36-6
ii  libhdf5-103-1  1.10.8+repack-4
ii  libmagic1  1:5.41-4
ii  libncbi-vdb3   3.0.0+dfsg2-4
ii  libncbi-wvdb2  2.11.2+dfsg-6
ii  libncbi-wvdb3  3.0.0+dfsg2-4
ii  libre2-9   20220601+dfsg-1
ii  libxml22.9.14+dfsg-1.1+b2
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages sra-toolkit recommends:
ii  med-config  3.7.3

sra-toolkit suggests no packages.

-- no debconf information

Bug#1025279: nvidia-graphics-drivers: CVE-2022-34670, CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34679, CVE-2022-34680, CVE-2022-34682, CVE-2022-34684, CVE-2022-42254, CVE-2022-42255, CV

[Andreas Beckmann]

Source: nvidia-graphics-drivers
Severity: serious
Tags: security upstream
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9
Control: reassign -2 src:nvidia-graphics-drivers-legacy-340xx 340.76-6
Control: retitle -2 nvidia-graphics-drivers-legacy-340xx: CVE-2022-34670, 
CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34680, CVE-2022-42257, 
CVE-2022-42258, CVE-2022-42259
Control: tag -2 + wontfix
Control: reassign -3 src:nvidia-graphics-drivers-legacy-390xx 390.48-4
Control: retitle -3 nvidia-graphics-drivers-legacy-390xx: CVE-2022-34670, 
CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34680, CVE-2022-42257, 
CVE-2022-42258, CVE-2022-42259
Control: reassign -4 src:nvidia-graphics-drivers-tesla-418 418.87.01-1
Control: retitle -4 nvidia-graphics-drivers-tesla-418: CVE-2022-34670, 
CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34679, CVE-2022-34680, 
CVE-2022-34682, CVE-2022-42254, CVE-2022-42256, CVE-2022-42257, CVE-2022-42258, 
CVE-2022-42259, CVE-2022-42260, CVE-2022-42261, CVE-2022-42262, CVE-2022-42263, 
CVE-2022-42264
Control: tag -4 + wontfix
Control: reassign -5 src:nvidia-graphics-drivers-tesla-450 450.51.05-1
Control: retitle -5 nvidia-graphics-drivers-tesla-450: CVE-2022-34670, 
CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34679, CVE-2022-34680, 
CVE-2022-34682, CVE-2022-42254, CVE-2022-42256, CVE-2022-42257, CVE-2022-42258, 
CVE-2022-42259, CVE-2022-42260, CVE-2022-42261, CVE-2022-42262, CVE-2022-42263, 
CVE-2022-42264
Control: reassign -6 src:nvidia-graphics-drivers-tesla-460 460.32.03-1
Control: retitle -6 nvidia-graphics-drivers-tesla-460: CVE-2022-34670, 
CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34679, CVE-2022-34680, 
CVE-2022-34682, CVE-2022-42254, CVE-2022-42255, CVE-2022-42256, CVE-2022-42257, 
CVE-2022-42258, CVE-2022-42259, CVE-2022-42260, CVE-2022-42261, CVE-2022-42262, 
CVE-2022-42263, CVE-2022-42264
Control: tag -6 + wontfix
Control: close -6 460.106.00-3
Control: reassign -7 src:nvidia-graphics-drivers-tesla-470 470.57.02-1
Control: retitle -7 nvidia-graphics-drivers-tesla-470: CVE-2022-34670, 
CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34679, CVE-2022-34680, 
CVE-2022-34682, CVE-2022-42254, CVE-2022-42255, CVE-2022-42256, CVE-2022-42257, 
CVE-2022-42258, CVE-2022-42259, CVE-2022-42260, CVE-2022-42261, CVE-2022-42262, 
CVE-2022-42263, CVE-2022-42264
Control: reassign -8 src:nvidia-graphics-drivers-tesla-510 510.47.03-1
Control: retitle -8 nvidia-graphics-drivers-tesla-510: CVE-2022-34670, 
CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34679, CVE-2022-34680, 
CVE-2022-34682, CVE-2022-34684, CVE-2022-42254, CVE-2022-42255, CVE-2022-42256, 
CVE-2022-42257, CVE-2022-42258, CVE-2022-42259, CVE-2022-42260, CVE-2022-42261, 
CVE-2022-42262, CVE-2022-42263, CVE-2022-42264
Control: reassign -9 src:nvidia-graphics-drivers-tesla 510.85.02-1
Control: retitle -9 nvidia-graphics-drivers-tesla: CVE-2022-34670, 
CVE-2022-34674, CVE-2022-34675, CVE-2022-34677, CVE-2022-34679, CVE-2022-34680, 
CVE-2022-34682, CVE-2022-34684, CVE-2022-42254, CVE-2022-42255, CVE-2022-42256, 
CVE-2022-42257, CVE-2022-42258, CVE-2022-42259, CVE-2022-42260, CVE-2022-42261, 
CVE-2022-42262, CVE-2022-42263, CVE-2022-42264
Control: found -1 340.24-1
Control: found -1 343.22-1
Control: found -1 396.18-1
Control: found -1 430.14-1
Control: found -1 455.23.04-1
Control: found -1 465.24.02-1
Control: found -1 495.44-1
Control: found -1 515.48.07-1

https://nvidia.custhelp.com/app/answers/detail/a_id/5415

CVE-2022-34670  NVIDIA GPU Display Driver for Linux contains a
vulnerability in the kernel mode layer handler, where an unprivileged
regular user can cause truncation errors when casting a primitive to a
primitive of smaller size causes data to be lost in the conversion,
which may lead to denial of service or information disclosure.

CVE-2022-42263  NVIDIA GPU Display Driver for Linux contains a
vulnerability in the kernel mode layer handler, where an Integer
overflow may lead to denial of service or information disclosure.

CVE-2022-34676  NVIDIA GPU Display Driver for Linux contains a
vulnerability in the kernel mode layer handler, where an out-of-bounds
read may lead to denial of service, information disclosure, or data
tampering.

CVE-2022-42264  NVIDIA GPU Display Driver for Linux contains a
vulnerability in the kernel mode layer, where an unprivileged regular
user can cause the use of an out-of-range pointer offset, which may lead
to data tampering, data loss, information disclosure, or denial of
service.

CVE-2022-34674  NVIDIA GPU Display Driver for Linux contains a
vulnerability in the kernel mode layer handler, where a helper function
maps more physical pages than were requested, which may lead to
undefined behavior or an information leak.

CVE-2022-34678  NVIDIA GPU Display Driver for Windows and Linux contains
a vulnerability in the kernel mode layer, where an unprivileged user can
cause a null-pointer dereference, which may lead to denial of 

Bug#952493: xavs2: please make the build reproducible

[Vagrant Cascadian]

On 2020-02-24, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> xavs2 could not be built reproducibly.
>
> Patch attached, although that xavs2 will still vary due to the
> embedding the path in calls to assert(...).

> --- a/debian/patches/1003_reproducible_build.patch1969-12-31 
> 16:00:00.0 -0800
> --- b/debian/patches/1003_reproducible_build.patch2020-02-24 
> 15:38:11.940987381 -0800
> @@ -0,0 +1,17 @@
> +Description: Make the build reproducible
> +Author: Chris Lamb 
> +Last-Update: 2020-02-24
> +
> +--- xavs2-1.3.orig/version.sh
>  xavs2-1.3/version.sh
> +@@ -24,7 +24,9 @@ VER_MAJOR=`echo $(($api / 10))`
> + VER_MINOR=`echo $(($api % 10))`
> + 
> + # date and time information
> +-BUILD_TIME=`date "+%Y-%m-%d %H:%M:%S"`
> ++DATE_FMT="+%Y-%m-%d %H:%M:%S"
> ++SOURCE_DATE_EPOCH="${SOURCE_DATE_EPOCH:-$(date +%s)}"
> ++BUILD_TIME=$(date -u -d "@$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || 
> date -u -r "$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date -u 
> "$DATE_FMT")
> + 
> + # generate the file version.h
> + echo "// 
> ==="  
> > version.h

I can confirm that this patch still works, though the build path issues
still remain.

Though fixing just the timestamp issues should build reproducibly when
the package migrates to testing, as tests.reproducible-builds.org does
not test build path variations, and would make it easier to debug the
remaining issues.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#955783: netgen-lvs: please make the build reproducible

[Vagrant Cascadian]

Control: tags 955783 pending

On 2020-04-04, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> netgen-lvs could not be built reproducibly.
>
> This is because it embeds by the build date into the binary.

Uploaded an NMU to DELAYED/10 fixing this issue:

diff -Nru netgen-lvs-1.5.133/debian/changelog 
netgen-lvs-1.5.133/debian/changelog
--- netgen-lvs-1.5.133/debian/changelog 2021-11-07 10:50:30.0 -0800
+++ netgen-lvs-1.5.133/debian/changelog 2022-12-01 14:32:11.0 -0800
@@ -1,3 +1,12 @@
+netgen-lvs (1.5.133-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * Do not embed build timestamp (Closes: #955783)
+
+ -- Vagrant Cascadian   Thu, 01 Dec 2022 
14:32:11 -0800
+
 netgen-lvs (1.5.133-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
netgen-lvs-1.5.133/debian/patches/do-not-embed-build-timestamp-closes-9557.patch
 
netgen-lvs-1.5.133/debian/patches/do-not-embed-build-timestamp-closes-9557.patch
--- 
netgen-lvs-1.5.133/debian/patches/do-not-embed-build-timestamp-closes-9557.patch
1969-12-31 16:00:00.0 -0800
+++ 
netgen-lvs-1.5.133/debian/patches/do-not-embed-build-timestamp-closes-9557.patch
2022-12-01 14:32:11.0 -0800
@@ -0,0 +1,57 @@
+From: Chris Lamb 
+Date: Sat, 4 Apr 2020 22:36:48 +0100
+X-Dgit-Generated: 1.5.133-1.2 d0def6605122fc8c1aeae62bd675d10394577f65
+Subject: Do not embed build timestamp (Closes: #955783)
+
+Adjusted-by: Vagrant Cascadian 
+
+---
+
+diff --git a/base/Makefile b/base/Makefile
+index dbc0bb1..8c87439 100644
+--- a/base/Makefile
 b/base/Makefile
+@@ -10,7 +10,11 @@ include ${NETGENDIR}/defs.mak
+ 
+ SRCS   += ${GR_SRCS}
+ DFLAGS += ${GR_DFLAGS}
++ifdef SOURCE_DATE_EPOCH
++DFLAGS += -DNETGEN_DATE="\"`LC_ALL=C date -u -d "@$(SOURCE_DATE_EPOCH)" 
2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" 2>/dev/null || date -u`\""
++else
+ DFLAGS += -DNETGEN_DATE="\"`date`\""
++endif
+ CFLAGS += ${GR_CFLAGS}
+ 
+ include ${NETGENDIR}/rules.mak
+diff --git a/netgen/Makefile b/netgen/Makefile
+index 52beff7..9541edd 100644
+--- a/netgen/Makefile
 b/netgen/Makefile
+@@ -8,7 +8,11 @@ EXTRA_LIBS = ${NETGENDIR}/base/libbase.o \
+${MAIN_EXTRA_LIBS}
+ 
+ DFLAGS += ${GR_DFLAGS}
++ifdef SOURCE_DATE_EPOCH
++DFLAGS += -DNETGEN_DATE="\"`LC_ALL=C date -u -d "@$(SOURCE_DATE_EPOCH)" 
2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" 2>/dev/null || date -u`\""
++else
+ DFLAGS += -DNETGEN_DATE="\"`date`\""
++endif
+ 
+ LIBS += ${GR_LIBS} -lm
+ CFLAGS += ${GR_CFLAGS} -I${NETGENDIR}/base
+diff --git a/tcltk/Makefile b/tcltk/Makefile
+index 861e185..5105765 100644
+--- a/tcltk/Makefile
 b/tcltk/Makefile
+@@ -6,7 +6,11 @@ include ${NETGENDIR}/defs.mak
+ 
+ EXTRA_LIBS = ${MAIN_EXTRA_LIBS}
+ 
++ifdef SOURCE_DATE_EPOCH
++DFLAGS += -DNETGEN_DATE="\"`LC_ALL=C date -u -d "@$(SOURCE_DATE_EPOCH)" 
2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" 2>/dev/null || date -u`\""
++else
+ DFLAGS += -DNETGEN_DATE="\"`date`\""
++endif
+ LIBS += -lm
+ CLEANS += netgen.sh netgen.tcl netgenexec${EXEEXT}
+ CFLAGS += -I${NETGENDIR}/base
diff -Nru netgen-lvs-1.5.133/debian/patches/series 
netgen-lvs-1.5.133/debian/patches/series
--- netgen-lvs-1.5.133/debian/patches/series2021-11-07 10:50:30.0 
-0800
+++ netgen-lvs-1.5.133/debian/patches/series2022-12-01 14:32:11.0 
-0800
@@ -1,3 +1,4 @@
 0002-Make-sure-hardening-flags-are-passed-down.patch
 0002-Fix-some-sprintf-calls.patch
 autoconf2.71.patch
+do-not-embed-build-timestamp-closes-9557.patch


signature.asc
Description: PGP signature

Bug#1025277: ITP: ksanecore -- library providing logic to interface scanners

[Aurélien COUDERC]

Package: wnpp
Severity: wishlist
Owner: Aurélien COUDERC 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Qt/KDE Maintainers 


* Package name: ksanecore
  Version : 22.11.90
  Upstream Author : Kåre Särs 
* URL : https://invent.kde.org/libraries/ksanecore
* License : LGPL
  Programming Lang: C++
  Description : library providing logic to interface scanners

KSaneCore is a library that provides a Qt interface for the SANE library
for scanner hardware.

This package will be maintained under the Debian Qt/KDE Maintainers
Team’s umbrella.

Bug#1025215: transition: qtermwidget

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-12-01 08:42:21 +0800, ChangZhuo Chen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: LXQt Packaging Team , 
> Tom Jampen 
> 
> 
> This transition is for qtermwidget soversion changing from 0 to 1. The
> following are reverse dependencies affected by this transition:
> 
> * qterminal: new version has been uploaded to experimental
> * texstudio: binNMU

Please go ahead

Cheers

> 
> 
> Ben file:
> 
> title = "qtermwidget";
> is_affected = .depends ~ "libqtermwidget5-0" | .depends ~ "libqtermwidget5-1";
> is_good = .depends ~ "libqtermwidget5-1";
> is_bad = .depends ~ "libqtermwidget5-0";
> 
> -- 
> ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
> http://czchen.info/
> Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B



-- 
Sebastian Ramacher

Bug#1025212: transition: libfm-qt

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-12-01 08:02:56 +0800, ChangZhuo Chen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> This transition is for libfm-qt soversion changing from 11 to 12.  All
> affected packages listed in [0] have been uploaded to experimental.
> Except mips64el, mipsel, ppc64el, all other architectures can be built
> successful.

Please go ahead

Cheers

> 
> 
> [0] https://release.debian.org/transitions/html/auto-libfm-qt.html
> 
> 
> Ben file:
> 
> title = "libfm-qt";
> is_affected = .depends ~ "libfm-qt11" | .depends ~ "libfm-qt12";
> is_good = .depends ~ "libfm-qt12";
> is_bad = .depends ~ "libfm-qt11";
> 
> -- 
> ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
> http://czchen.info/
> Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B



-- 
Sebastian Ramacher

Bug#922584: [Help] Re: FTBFS against opencv 4.0.1 (exp)

[Adrian Bunk]

On Mon, Nov 23, 2020 at 05:49:42PM +0100, Andreas Tille wrote:
> Control: tags -1 help
> 
> Hi,
> 
> the configure step checks for the existence of opencv and only if
> available builds the executable limereg.  I found a (hackish) solution
> in Git[1] to convince configure that opencv is available.  However, the
> code tries to include cv.h which is not available any more.  I have no
> knowledge about opencv and thus I have no idea to proceed.  My only idea
> is to drop the limereg binary package and just keep the liblimereg
> packages alive.
> 
> Any help is welcome

[1] contains a patch from a Debian porter, but considering the facts 
that limereg already missed the current Debian stable bullseye and the 
comment from upstream (who is also the original Debian packager) in [2], 
removal from Debian might be a better option?

I do not know how limereg compares to other tools like for example
elastix (based on ITK) or registrationx (part of CMTK) or other tools,
but neither the upstream bug tracker nor the Debian BTS indicate that
there would be an active userbase who report bugs or complained that
limereg is not in bullseye.

>Andreas.
>...

cu
Adrian

[1] https://github.com/RoelofBerg/limereg/issues/3
[2] https://github.com/RoelofBerg/limereg/issues/3#issuecomment-1296863979

Bug#945105: intel-gpu-tools: please make the build reproducible

[Vagrant Cascadian]

On 2019-11-19, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> intel-gpu-tools could not be built reproducibly.
>
> This is because it embedded the path to the test directory in the
> binary. As we don't even build the tests (according to a comments,
> they FTBFS...) my attached patch is almost-certainly harmless.
>
> Patch attached.

That patch no longer applies due to changes in upstream, but I've
attached a new patch that passes a relative source directory from
debian/rules, leveraging the upstream changes.

Would the maintainers be amendable to an NMU for this fix? I would love
to see this land in time for the bookworm freeze...

It looks like there is or will be a transition for:

  https://release.debian.org/transitions/html/auto-procps.html

Which might necessitate a bit of delay...

live well,
  vagrant
From 9300b7973cec79f4d33d48f676b7e491ea6d2a8b Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 1 Dec 2022 21:20:56 +
Subject: [PATCH] debian/rules: Pass relative source directory for reproducible
 builds. (Closes: #945105)

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

diff --git a/debian/rules b/debian/rules
index ef422d80..a0dfcccd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,7 +17,7 @@ override_dh_clean:
 # FIXME: building debugger causes FTBFS
 override_dh_auto_configure:
 	dh_auto_configure -- \
-		-Dtests=disabled
+		-Dtests=disabled -Dsrcdir=.
 
 # Disable test suite:
 override_dh_auto_test:
-- 
2.38.1



signature.asc
Description: PGP signature

Bug#1025276: xlog: segfaults during startup

[tony mancill]

Package: xlog
Version: 2.0.24-2
Severity: important

Something has bitrotted with xlog and now it fails to start.

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

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

Versions of packages xlog depends on:
ii  dpkg 1.21.10
ii  libc62.36-6
ii  libcairo21.16.0-6
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.2-1
ii  libgtk2.0-0  2.24.33-2
ii  libhamlib4   4.5-2+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  xlog-data2.0.24-2

Versions of packages xlog recommends:
ii  shared-mime-info  2.2-1
ii  xdg-utils 1.1.3-4.1

Versions of packages xlog suggests:
pn  cwdaemon 
pn  extra-xdg-menus  
pn  glabels  

-- no debconf information

Bug#1025069: more info

[Hans-Christoph Steiner]

You can ping me on IRC (_hc) or matrix (@eighthave:matrix.org) if you want to 
try it interactively.  pulseaudio was not running as far as I could tell.


root@delbin:~# service pulseaudio-enable-autospawn status
○ pulseaudio-enable-autospawn.service
 Loaded: masked (Reason: Unit pulseaudio-enable-autospawn.service is 
masked.)
 Active: inactive (dead)
hans@delbin:~$ ps auxww|grep pulse
hans   68885  0.0  0.1  35168 10600 ?S/usr/bin/pipewire-pulse

hans   80426  0.0  0.0   9568  2204 pts/1S+   21:04   0:00 grep pulse
hans@delbin:~$ systemctl --user --now enable wireplumber.service
hans@delbin:~$ journalctl --user -u pipewire --user -u wireplumber --user -u 
pipewire-pulse  -f

Nov 26 22:54:26 delbin pipewire-pulse[2233]: 536870912
Nov 26 22:54:26 delbin wireplumber[2182]: Failed to set scheduler settings: 
Operation not permitted
Nov 26 22:54:26 delbin wireplumber[2182]: SPA handle 
'api.libcamera.enum.manager' could not be loaded; is it installed?
Nov 26 22:54:26 delbin wireplumber[2182]: PipeWire's libcamera SPA missing or 
broken. libcamera not supported.
Nov 26 22:54:27 delbin wireplumber[2182]: Trying to use legacy bluez5 API for LE 
Audio - only A2DP will be supported. Please upgrade bluez5.

Dec 01 20:50:55 delbin systemd[2147]: Stopping PipeWire PulseAudio...
Dec 01 20:50:55 delbin systemd[2147]: Stopped PipeWire PulseAudio.
Dec 01 20:50:55 delbin systemd[2147]: pipewire-pulse.service: Consumed 17.350s 
CPU time.

Dec 01 20:50:55 delbin systemd[2147]: Started PipeWire PulseAudio.
Dec 01 20:50:55 delbin pipewire-pulse[68890]: 536870912
hans@delbin:~$ systemctl status|grep -e pipe -e wire -e pulse
 │ │   └─80108 grep -e pipe -e wire -e pulse
   ├─pipewire-pulse.service
   │ └─68885 /usr/bin/pipewire-pulse
   ├─pipewire.service
   │ └─2180 /usr/bin/pipewire
   ├─wireplumber.service
   │ └─2182 /usr/bin/wireplumber

Bug#1024395: grub-efi-amd64-signed: update

[Garrett McLean]

Package: grub-efi-amd64-bin
Version: 1+2.06+3~deb11u4
Followup-For: Bug #1024395
X-Debbugs-Cc: t...@security.debian.org

Wanted to update and say that even with sb enabled, mok doesn't show up
with mokutil --list-enrolled. In my case this may be because mokutil
doesn't work with my mobo (ASUS X99-Deluxe/U3.1) and I had to manually
add my mok in BIOS settings.

Hopefully this info is useful. It seems superfluous but I'm including it
just in case.

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

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

Versions of packages grub-efi-amd64-signed depends on:
ii  grub-common  2.06-3~deb11u4

Versions of packages grub-efi-amd64-signed recommends:
ii  shim-signed  1.38+15.4-7

grub-efi-amd64-signed suggests no packages.

Versions of packages grub-efi-amd64-bin depends on:
ii  grub-common  2.06-3~deb11u4

Versions of packages grub-efi-amd64-bin recommends:
ii  efibootmgr  17-1

-- no debconf information

Bug#1024953: jsonpickle: (autopkgtest) needs update for python3.11: 'NoneType' object has no attribute 'keys'

[Louis-Philippe Véronneau]

fixed 1024953 3.0.0
tags 1024953 fixed-upstream
thanks

Hi!

Note that this bug has been fixed upstream, but haven't been released in 
a git tag yet.


I think the changes are too substantial (major version) to patch the 
issue in Debian via quilt.


I asked the upstream maintainer to make a release here: 
https://github.com/jsonpickle/jsonpickle/issues/416


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024907: deepdiff: (autopkgtest) needs update for python3.11: AssertionError

[Louis-Philippe Véronneau]

found 1024907 6.2.1
thanks

Note that I've updated this package to the latest upstream version 
(6.2.1) on Salsa and the problem is still there.


--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024427: reproducible segfault in bullseye mutt

[Salvatore Bonaccorso]

Hi Antonio,

On Wed, Nov 30, 2022 at 09:38:39AM -0800, Kevin J. McCarthy wrote:
> Note this was fixed in Mutt 2.2.8.  See
> https://gitlab.com/muttmua/mutt/-/issues/428 for the Mutt bug report.
> 
> This important fix is at: 
> https://gitlab.com/muttmua/mutt/-/commit/48b6ea32e21db8b580cd3ca8c346c3e2c22756f6.patch
> 
> There are two related commits, that may be of interest in backporting too,
> but aren't the cause of this segfault:
> https://gitlab.com/muttmua/mutt/-/commit/f0eb3586480c301b66657c7326b6546ef086c7f4.patch
> https://gitlab.com/muttmua/mutt/-/commit/b254f2fb44f994c48e2491adaf03d97d3c628283.patch

There is an upcoming point release for bullseye on 17th of december,
can you pick those fixes for a stable update?

Thanks for your work on mutt!

Regards,
Salvatore

Bug#1025275: libfcft-dev: Missing dependencies

[Adrian Bunk]

Package: libfcft-dev
Version: 2.3.1-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:fuzzel src:foot src:yambar

$ pkg-config --cflags fcft
Package fontconfig was not found in the pkg-config search path.
Perhaps you should add the directory containing `fontconfig.pc'
to the PKG_CONFIG_PATH environment variable
Package 'fontconfig', required by 'fcft', not found
Package 'freetype2', required by 'fcft', not found
Package 'harfbuzz', required by 'fcft', not found
Package 'libutf8proc', required by 'fcft', not found
Package 'pixman-1', required by 'fcft', not found
Package 'tllist', required by 'fcft', not found

$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/fcft.pc
...
Requires.private: fontconfig, freetype2, harfbuzz, libutf8proc, pixman-1, 
tllist >= 1.0.1
...
$



These dependencies are an implementation detail of libfcft-dev
that must be expressed in the package dependencies, not something
every user has to copy and update all the time (like when libutf8proc
usage was enabled in fcft).

As of 3.1.5-2 the missing dependencies are:
 libpixman-1-dev, libfreetype6-dev, libfontconfig-dev,
 libtllist-dev, libharfbuzz-dev, libutf8proc-dev

Adding the dependencies to libfcft-dev fixes this bug.


Only pixman.h is used in the headers in libfcft-dev,
an alternative fix would be to add only a dependency
on libpixman-1-dev and reduce Requires.private in fcft.pc to:
  Requires.private: pixman-1

Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player

[Helmar Gerloni]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "tuxguitar".

The package builds and runs on amd64. I was not able to build it on i386 
because of missing libswt-gtk-4-java. I don't know if it builds on other 
architectures; probably not out-of-the-box.

Would be great if someone could tell me if there is a chance to get the package 
into Debian. Any comments are welcome, I'll try to improve the package as good 
as I can.

 * Package name : tuxguitar
   Version  : 1.5.6+dfsg1-1
   Upstream contact : Julian Casadesus 
 * URL  : http://www.tuxguitar.com.ar
 * License  : UNCLEAR (MagicSFver2.sf2?), LGPL-2.1+ (the rest)
 * Vcs  : https://salsa.debian.org/java-team/tuxguitar
   Section  : sound

The source builds the following binary packages:

  tuxguitar - Multitrack guitar tablature editor and player
  tuxguitar-jsa - tuxguitar plugin for sound playback using Java Sound API
  tuxguitar-alsa - tuxguitar plugin for sound playback using ALSA
  tuxguitar-oss - tuxguitar plugin for sound playback using OSS
  tuxguitar-fluidsynth - tuxguitar plugin for sound playback using fluidsynth
  tuxguitar-jack - tuxguitar plugin for sound playback using JACKD
  tuxguitar-synth-lv2 - tuxguitar LV2 audio plugin
  tuxguitar-soundfont - tuxguitar Magic Sound Font v2.0
  tuxguitar-gervill - tuxguitar gervill audio plugin

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tuxguitar/tuxguitar_1.5.6+dfsg1-1.dsc

Regards,   Helmar.

Bug#941627: Packaging grub-btrfs

[Nicholas D Steeves]

Control: retitle -1 RFP: grub-btrfs -- provides grub entries for btrfs 
snapshots (boot environments/restore points)
Control: noowner

Hi Pascal!

Pascal Jäger  writes:

> am one of the devs of grub-btrfs and I am the one responsible for the last 
> few updates to it.
>

Thank you for your work on grub-btrfs, it looks like it's matured a lot
since I filed this ITP years ago :)  I've converted this ITP to an RFP,
because I suspect everyone feels like I'm taking too long haha.

> Recently the idea arose to make a Debian package for it. [1]
> While researching how to do that I found this ITP.
> Now this kind of is on ice, the last reply was more than a year ago, and I 
> wonder why. And how we should proceed on this.
> I already filed another ITP which should be closed, I guess.

Bart took care of that ;)

> We have a package already from the dev of Kaisen Linux which that dev wanted 
> to contribute to Debian after getting a sponsor.
> So if you are still interested into packaging grub-btrfs I would suggest the 
> guy from kaisen linux prepares his Debian package and you sponsor it maybe?
>

What is Kaisen Linux?  I read issue #236 that you linked to, and it
seems like geckolinux (author of Spiral Linux or Gecko Linux?) should
possibly be part of this conversation.  Kali Linux also has its own
packaging.

To get grub-btrfs into the unstable->testing->stable stream of Debian
(which is what an Intent to Package is about, long-term), there are a
couple of TODOs:

1. The Debian package needs a committed, motivated, *long-term*
maintainer with free time.  I've been short on free time and extra
energy for a while, which is a shame, because btrfs integration was once
my #1 priority in Debian.

2. Whether manually, or with CI, there needs to be one or more regularly
tested configurations.  For example, a Snapper-based snapshot layout,
Timeshift, or some_other_tool-based snapshot layout.  I hope geckolinux
can help with this.  This one is important to critical.  If a normal
user loses data while doing something completely reasonable, then we've
failed to consider the problem with due diligence.  I'm also aware that
Neptune OS and Linux Mint are using Timeshift.

3. Does Timeshift's (already in Debian) GRUB menu entry support (is this
enabled yet?) conflict with grub-btrfs?  Are there any other conflicts?
For example, ZFS stuff?  Any other pitfalls that may cause data lose?
This one is important to critical.

4. I think everyone will agree that users who install this will have a
reasonable expectation of automatic boot environments/system restore
points.  This requires an apt trigger in whatever tool is used to make
the snapshots.  This one is normal.

5. A decision needs to be made about what layouts will be supported, and
what layouts will be "if it breaks, you're on your own".  It's possible
(but unlikely, as far as I can tell) that additional Debian Installer
work will be necessary.  This is arguably just another aspect of #1.
As far as I can tell, the following are the cases this package will
encounter, in order of most common to least common:
  a) Our default @rootfs, no other subvolumes.
  b) @roots, and @home -- Ahem!  This seems like it will be required, to
  not lose user data!  Yes, this is why I stalled for so long.  Debian
  Installer is not fun to work on.
  c) Either support old installations directly on subvolid=5, or loudly
  declare that they're not supported somewhere in the description and
  documentation.  Seems like user data will be lost similarly to "b"
  d) How to protect /var/www as well as databases?
  e) Snapper/SUSE style, which is a superset of Ubuntu-style, as far as
  I can tell, or maybe Ubuntu-style is a subset of SUSE?  Does anyone
  know?
  f) Ubuntu-style @ and @home

6.  And what happens when a user has both Debian stable and unstable/sid
(or Ubuntu) installed to the same drive, and both have grub-btrfs
installed?  What is "The Right Thing" in this case, and will grub-btrfs
Do The Right Thing?  This question prompted the discussion that led to
rootfs on "@rootfs" rather than "@" like Ubuntu/SUSE or "rootfs" like
Fedora.

I can't commit to reviewing anyone's work in time for the freeze due to
poor availability of free time in the coming months.  That said, I will
be happy to help with coordination and staging in the experimental suite
during the freeze, and the features can be introduced via
bookworm-backports so users of Debian stable can still benefit.

Other than all this, I suspect that the following is probably what users
expect will happen:

  1. Boot from read only subvolume (how to check for bootable
  subvolumes?) with an overlayfs and prominent warning that any changes
  will not be written to disk.  The tool that handles the GRUB config
  would need to do this.  If it can't be done with kernel command line,
  then an initramfs (with hooks) could be used.
  * Alternatively, I guess a pure btrfs solution could make a
writeable snapshot of the known-good 

Bug#1025267: Nimbus Roman: wrong glyph for ₤ (U+20A4 LIRA SIGN)

[Fabian Greffrath]

Hi Jakub,

Am Donnerstag, dem 01.12.2022 um 19:21 +0100 schrieb Jakub Wilk:
> In the Nimbus Roman font, the character ₤ (U+20A4 LIRA SIGN) looks
> like 
> "zł". It should look similar to £ (U+00A3 POUND SIGN) instead.

well, I doubt that we'll be able to fix this in the scope of the Debian
package. Would you please do me a favor and forward this issue to the
upstream git tracker? Thank you!

 - Fabian



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

Bug#876771: NMU fixing reproducible and cross-build issues

[Vagrant Cascadian]

I am uploading an NMU fixing reproducible builds and cross-building
issues:

diff -Nru squeak-plugins-scratch-1.4.0.2~svn.r83/debian/changelog 
squeak-plugins-scratch-1.4.0.2~svn.r83/debian/changelog
--- squeak-plugins-scratch-1.4.0.2~svn.r83/debian/changelog 2018-11-09 
03:16:26.0 -0800
+++ squeak-plugins-scratch-1.4.0.2~svn.r83/debian/changelog 2022-12-01 
12:18:32.0 -0800
@@ -1,3 +1,15 @@
+squeak-plugins-scratch (1.4.0.2~svn.r83-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * Make the build reproducible. (Closes: #942006)
+
+  [ Helmut Grohne ]
+  * Fix cross-building (Closes: #876771)
+
+ -- Vagrant Cascadian   Thu, 01 Dec 2022 
12:18:32 -0800
+
 squeak-plugins-scratch (1.4.0.2~svn.r83-3) unstable; urgency=medium
 
   * Cleaned up many lintian warnings
diff -Nru squeak-plugins-scratch-1.4.0.2~svn.r83/debian/rules 
squeak-plugins-scratch-1.4.0.2~svn.r83/debian/rules
--- squeak-plugins-scratch-1.4.0.2~svn.r83/debian/rules 2018-11-09 
03:16:26.0 -0800
+++ squeak-plugins-scratch-1.4.0.2~svn.r83/debian/rules 2022-12-01 
12:18:32.0 -0800
@@ -1,9 +1,15 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 export DH_ALWAYS_EXCLUDE=.svn
 
+ifeq ($(origin CC),default)
+CC = $(DEB_HOST_GNU_TYPE)-gcc
+endif
+PKG_CONFIG ?= $(DEB_HOST_GNU_TYPE)-pkg-config
 LDFLAGS=-Wl,-z,defs -Wl,--as-needed -Wl,--no-undefined
-CFLAGS=-std=gnu89
+CFLAGS=-std=gnu89 $(shell dpkg-buildflags --get CFLAGS)
 
 config: config-stamp
 config-stamp: 
@@ -17,21 +23,21 @@
 build-stamp: config
dh_testdir
cd camera/ && \
-   gcc $(CFLAGS) -g -fPIC -c *.c
+   $(CC) $(CFLAGS) -g -fPIC -c *.c
cd camera/ && \
-   gcc $(LDFLAGS) -g -shared *.o -lv4l2 -ldl -o so.CameraPlugin
+   $(CC) $(LDFLAGS) -g -shared *.o -lv4l2 -ldl -o so.CameraPlugin
cd scratch/ && \
-   gcc $(CFLAGS) -g -fPIC -c *.c
+   $(CC) $(CFLAGS) -g -fPIC -c *.c
cd scratch/ && \
-   gcc $(LDFLAGS) -g -shared *.o -lm -o so.ScratchPlugin
+   $(CC) $(LDFLAGS) -g -shared *.o -lm -o so.ScratchPlugin
cd unicode/ && \
-   gcc $(CFLAGS) -g -fPIC -c `pkg-config --cflags pangocairo` *.c
+   $(CC) $(CFLAGS) -g -fPIC -c `$(PKG_CONFIG) --cflags pangocairo` 
*.c
cd unicode/ && \
-   gcc $(LDFLAGS) -g -shared *.o `pkg-config --libs pangocairo` 
-lc -o so.UnicodePlugin
+   $(CC) $(LDFLAGS) -g -shared *.o `$(PKG_CONFIG) --libs 
pangocairo` -lc -o so.UnicodePlugin
cd wedo/ && \
-   gcc $(CFLAGS) -g -fPIC -c *.c
+   $(CC) $(CFLAGS) -g -fPIC -c *.c
cd wedo/ && \
-   gcc $(LDFLAGS) -g -shared *.o -o so.WeDoPlugin
+   $(CC) $(LDFLAGS) -g -shared *.o -o so.WeDoPlugin
touch $@
 
 clean: 


signature.asc
Description: PGP signature

Bug#942009: stgit: please make the build reproducible

[Vagrant Cascadian]

On 2019-10-08, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed
> that stgit could not be built reproducibly.
>
> This is because the contents of the dynamically-compiled Bash
> completion script was not being generated in a deterministic manner,
> as well as the cmdlist.py module.
>
> Patch attached.

Uploaded an NMU fixing this:

diff -Nru stgit-0.19/debian/changelog stgit-0.19/debian/changelog
--- stgit-0.19/debian/changelog 2019-10-03 05:38:18.0 -0700
+++ stgit-0.19/debian/changelog 2022-12-01 11:53:31.0 -0800
@@ -1,3 +1,12 @@
+stgit (0.19-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * Make the build reproducible. (Closes: #942009)
+
+ -- Vagrant Cascadian   Thu, 01 Dec 2022 
11:53:31 -0800
+
 stgit (0.19-1) unstable; urgency=medium
 
   [ Maximiliano Curia ]
diff -Nru stgit-0.19/debian/patches/reproducible_build 
stgit-0.19/debian/patches/reproducible_build
--- stgit-0.19/debian/patches/reproducible_build1969-12-31 
16:00:00.0 -0800
+++ stgit-0.19/debian/patches/reproducible_build2022-12-01 
11:53:00.0 -0800
@@ -0,0 +1,33 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-10-08
+
+--- stgit-0.19.orig/stgit/argparse.py
 stgit-0.19/stgit/argparse.py
+@@ -260,7 +260,7 @@ class CompgenBase(object):
+ cmd += ['-A', act]
+ words = self.words(var)
+ if words:
+-cmd += ['-W', '"%s"' % ' '.join(words)]
++cmd += ['-W', '"%s"' % ' '.join(sorted(words))]
+ cmd += ['--', '"%s"' % var]
+ return ' '.join(cmd)
+ 
+@@ -310,4 +310,4 @@ class patch_range(CompgenBase):
+ for e in self.__endpoints:
+ assert not e.actions(var)
+ words |= e.words(var)
+-return set(['$(_patch_range "%s" "%s")' % (' '.join(words), var)])
++return set(['$(_patch_range "%s" "%s")' % (' '.join(sorted(words)), 
var)])
+
+--- stgit-0.19.orig/stgit/commands/__init__.py
 stgit-0.19/stgit/commands/__init__.py
+@@ -63,7 +63,7 @@
+ def py_commands(commands, f):
+ f.write('from __future__ import unicode_literals\n\n')
+ f.write('command_list = {\n')
+-for name, (mod, kind, help) in commands.items():
++for name, (mod, kind, help) in sorted(commands.items()):
+ f.write('%r: (\n' % name)
+ f.write('%r,\n' % mod)
+ f.write('%r,\n' % kind)
diff -Nru stgit-0.19/debian/patches/series stgit-0.19/debian/patches/series
--- stgit-0.19/debian/patches/series2019-10-03 05:38:18.0 -0700
+++ stgit-0.19/debian/patches/series2022-12-01 11:53:00.0 -0800
@@ -2,3 +2,4 @@
 stg-gitk_bashism
 disable_interactive_test
 Avoid-the-git-error-messages-when-running-stg-outside-of-.patch
+reproducible_build


signature.asc
Description: PGP signature

Bug#1025021: python-bayespy: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'

[Paul Gevers]

Control: reassign -1 python3-nose
Control: tags -1 ftbfs patch pending upstream
Control: tags -1 - bookworm sid
Control: merge 1024235 -1
Control: affects -1 src:python-bayespy

Hi Håvard,

On 01-12-2022 19:16, Håvard F. Aasen wrote:

File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run
  inspect.getargspec(func)
  ^^
AttributeError: module 'inspect' has no attribute 'getargspec'



This looks to be an error with nose, not python-bayespy. See bug #1024235 [1]


Indeed, reassigning (and merging hopefully).

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000653: Fix php-mail build

[Athos Ribeiro]

On Wed, Nov 30, 2022 at 05:11:15PM +0100, Christoph Martin wrote:

Hi

I have uploaded a fixed package as NMU to the deferred queue.

Am 17.11.22 um 13:55 schrieb Christoph Martin:


do you plan to release a new version with the proposed fix anytime soon?
I build it locally with the fix and it builds fine.
I could upload the package if this is ok for you.



Christoph


Thanks, Christoph.

FYI, I had forwarded the fix upstream at
https://github.com/pear/Mail/pull/21. They requested the change to be
backwards compatible. I did so by supporting backwards compatibility
when on PHP < 8.

--
Athos Ribeiro

Bug#1025273: dpkg-genbuildinfo: fails when no cross compiler is available

[Helmut Grohne]

Package: dpkg-dev
Version: 1.21.10
Severity: important
File: /usr/bin/dpkg-genbuildinfo
User: helm...@debian.org
Usertags: rebootstrap

Hi Guillem,

thanks for implementing the taint flag for cross compilation.
Unfortunately, this breaks architecture bootstrap.

We need to cross build linux kernel headers rather early before we have
a libc or a cross compiler. Despite being build-essential, we've
carefully set up linux stage1 to not need it.

Can we make the failure non-fatal? In the absence of a cross compiler,
we could simply skip emitting the taint flag. Would that be ok?

Helmut

Bug#1025272: RM: python-descartes -- ROM; Dead upstream

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
Control: block -1 by 1025044

Please remove python-decartes from the archive, it's dead upstream.

Kind Regards,

Bas

Bug#890312: desmume: please make the build reproducible

[Vagrant Cascadian]

On 2018-02-13, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that desmume could not be built reproducibly.
>
> The absolute build path ends up in the binary.

Uploaded an NMU to DELAYED/10 fixing this issue:

diff -Nru desmume-0.9.11/debian/changelog desmume-0.9.11/debian/changelog
--- desmume-0.9.11/debian/changelog 2022-11-23 14:40:49.0 -0800
+++ desmume-0.9.11/debian/changelog 2022-12-01 10:44:49.0 -0800
@@ -1,3 +1,12 @@
+desmume (0.9.11-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * make the build reproducible (Closes: #890312)
+
+ -- Vagrant Cascadian   Thu, 01 Dec 2022 
10:44:49 -0800
+
 desmume (0.9.11-4) unstable; urgency=medium
 
   * Team upload
diff -Nru 
desmume-0.9.11/debian/patches/make-the-build-reproducible-closes-89031.patch 
desmume-0.9.11/debian/patches/make-the-build-reproducible-closes-89031.patch
--- 
desmume-0.9.11/debian/patches/make-the-build-reproducible-closes-89031.patch
1969-12-31 16:00:00.0 -0800
+++ 
desmume-0.9.11/debian/patches/make-the-build-reproducible-closes-89031.patch
2022-12-01 10:44:49.0 -0800
@@ -0,0 +1,21 @@
+From: Chris Lamb 
+Date: Tue, 13 Feb 2018 10:39:28 +
+X-Dgit-Generated: 0.9.11-4.1 e7e2190f11cca0402ae7cdbe6d5086a34d82d75e
+Subject: make the build reproducible (Closes: #890312)
+
+
+---
+
+diff --git a/configure.ac b/configure.ac
+index 0595900..5f23469 100755
+--- a/configure.ac
 b/configure.ac
+@@ -169,7 +169,7 @@ if test "x$glade" = "xyes" ; then
+ AC_SUBST(LIBGLADE_LIBS)
+ 
+ dnl uninstalled glade ui dir
+-
AC_DEFINE_UNQUOTED(GLADEUI_UNINSTALLED_DIR,"`pwd`/src/gtk-glade/glade/",[path 
to glade ui dir])
++AC_DEFINE_UNQUOTED(GLADEUI_UNINSTALLED_DIR,"src/gtk-glade/glade/",[path 
to glade ui dir])
+ AC_SUBST(GLADEUI_UNINSTALLED_DIR)
+ 
+ PKG_CHECK_MODULES(GTKGLEXT,
diff -Nru desmume-0.9.11/debian/patches/series 
desmume-0.9.11/debian/patches/series
--- desmume-0.9.11/debian/patches/series2022-11-23 14:39:26.0 
-0800
+++ desmume-0.9.11/debian/patches/series2022-12-01 10:44:49.0 
-0800
@@ -3,3 +3,4 @@
 osmesa_printf.patch
 gcc6_fixes.patch
 gcc7_fixes.patch
+make-the-build-reproducible-closes-89031.patch


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1022404: raqm: diff for NMU version 0.7.0-4.1

[Adrian Bunk]

On Fri, Nov 25, 2022 at 05:16:03AM -0600, Jeremy Bicha wrote:
> Adrian,
> 
> Do you think it would be useful to include Ubuntu's change in your NMU
> to add an autopkgtest so that these build failures are detected sooner
> next time? It would have blocked the new harfbuzz from migrating to
> Testing.

Sounds reasonable to me, but let's give the maintainer a chance to
agree or disagree to that.

> https://patches.ubuntu.com/r/raqm/raqm_0.7.0-4ubuntu1.patch

  Depends: @, @builddeps@
would be better than the duplication in Ubuntu's change.

> Thank you,
> Jeremy Bicha

cu
Adrian

Bug#1025271: libgtk-3-0: Testing printer is available per default -> intentional?

[Roland Clobus]

Package: libgtk-3-0
Version: 3.24.35-1
Severity: normal

Hello maintainers of libgtk-3-0,

with the new version there are now 100 test printers available per default.
Is that change intentional?

Another change: the lpr backend is also made available per default.

Detected by openQA:
https://openqa.debian.net/tests/100696#step/desktop_printing/18

The print backends that are currently present:
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-file.so
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-lpr.so
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-test.so

I would assume that at least libprintbackend-test.so does not need to be
shipped for the regular users.

With kind regards,
Roland Clobus


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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 libgtk-3-0 depends on:
ii  adwaita-icon-theme   43-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.46.0-4
ii  libatk1.0-0  2.46.0-4
ii  libc62.36-5
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libcolord2   1.4.6-1
ii  libcups2 2.4.2-1+b2
ii  libepoxy01.5.10-1
ii  libfontconfig1   2.13.1-4.5
ii  libfribidi0  1.0.8-2.1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.1-2
ii  libgtk-3-common  3.24.35-1
ii  libharfbuzz0b5.2.0-2+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpangoft2-1.0-01.50.10+ds-1
ii  libwayland-client0   1.21.0-1
ii  libwayland-egl1  1.21.0-1
ii  libx11-6 2:1.8.1-2
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.1-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxkbcommon01.4.1-1
ii  libxrandr2   2:1.5.2-2+b1
ii  shared-mime-info 2.2-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin 3.24.35-1
ii  librsvg2-common  2.54.5+dfsg-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs  1.50.2-2

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
ii  gtk-vector-screenshot 0.3.3-2
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
ii  ibus-gtk3 1.5.27-4
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-10
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#1025270: sabnzbdplus: security bug CVE-2021-29488 in package

[Chris]

Package: sabnzbdplus
Version: 3.1.1+dfsg-2+deb11u1
Severity: important

Dear Maintainer,

according to their github homepage their is a security flaw, enabling a 
dependency to write outside of the configuration of the package. 

regards
chris


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

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
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 sabnzbdplus depends on:
ii  init-system-helpers   1.60
ii  libjs-bootstrap   3.4.1+dfsg-2
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-ui   1.12.1+dfsg-8+deb11u1
ii  libjs-moment  2.29.1+ds-2+deb11u2
ii  lsb-base  11.1.0
ii  par2  0.8.1-1
ii  python3   3.9.2-3
ii  python3-chardet   4.0.0-1
ii  python3-cheetah   3.2.6-1+b1
ii  python3-cherrypy3 8.9.1-8
ii  python3-configobj 5.0.6-4
ii  python3-cryptography  3.3.2-1
ii  python3-feedparser5.2.1-3
ii  python3-portend   2.6-1
ii  python3-sabyenc   4.0.2-1+b2
ii  python3-six   1.16.0-2
ii  unrar 1:6.0.3-1+deb11u1

Versions of packages sabnzbdplus recommends:
ii  libavahi-compat-libdnssd1  0.8-5+deb11u1
ii  p7zip-full 16.02+dfsg-8
ii  python3-dbus   1.2.16-5
ii  python3-notify20.3-4
ii  unzip  6.0-26+deb11u1

sabnzbdplus suggests no packages.

-- no debconf information

Bug#1025269: ITP dotnet in debian archive

[Ben Harris]

Package: dotnet-sdk-6.0
Version: 6.0.403-1
Severity: normal

ITP for dotnet in debian


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

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

Versions of packages dotnet-sdk-6.0 depends on:
ii  aspnetcore-runtime-6.0  6.0.11-1
ii  aspnetcore-targeting-pack-6.0   6.0.11-1
ii  dotnet-apphost-pack-6.0 6.0.11-1
ii  dotnet-runtime-6.0  6.0.11-1
ii  dotnet-targeting-pack-6.0   6.0.11-1
ii  netstandard-targeting-pack-2.1  2.1.0-1

dotnet-sdk-6.0 recommends no packages.

dotnet-sdk-6.0 suggests no packages.

-- no debconf information

Bug#796257: Reproducible source pkg

[Marek Marczykowski-Górecki]

This bug has also interesting interaction with reproducing _source_
package. If you take source package and do:

dpkg-source -x pkg.dsc
dpkg-source -b dir

then, depending on umask, you may end up with a different source
package, even though you haven't changed anything. This happens at least
to files in debian/ (debian.tar.xz) for quilt package format.

This affects cases like feeding source package to pbuilder - the output
source package (and its hash in changes file) will be different than the
original source pkg - if original pkg was built with different umask.

IMHO _if_ dpkg-source really must mess with file permissions (of which I
do not agree), it should also normalize them in archives it create.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature

Bug#1020710: RFP: flycheck-grammalecte -- Adds support for Grammalecte (a french grammar checker) to flycheck.

[Antoine Beaupré]

On 2022-12-01 13:35:50, Nicholas D Steeves wrote:
> Antoine Beaupré  writes:
>
>> On 2022-09-26 19:03:41, Nicholas D. Steeves wrote:
>>> Please ping me about this in a month, and hopefully I'll have time and
>>> motivation then :)
>>
>> Ping! :)
>>
>
> Thanks!  I took a look, and due to flycheck_grammalecte.py and
> conjugueur.py this is not a simple elpa package, so I won't have time to
> package it until 2023.
>
> Also, sorry, I'm not willing to package this one without a
> comaintainer who is motivated to keep those Python bits working.

No problems, I can take a look at some other time. :) I'd be happy to
collaborate, of course!

-- 
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin, 1755

Bug#1025268: Should mozjs102 in bookworm use the system icu?

[Adrian Bunk]

Source: mozjs102
Severity: normal

The system icu 72 is no longer older than the icu 71 vendored
in mozjs102, should mozjs102 in bookworm use the system icu?

Bug#1020710: RFP: flycheck-grammalecte -- Adds support for Grammalecte (a french grammar checker) to flycheck.

[Nicholas D Steeves]

Antoine Beaupré  writes:

> On 2022-09-26 19:03:41, Nicholas D. Steeves wrote:
>> Please ping me about this in a month, and hopefully I'll have time and
>> motivation then :)
>
> Ping! :)
>

Thanks!  I took a look, and due to flycheck_grammalecte.py and
conjugueur.py this is not a simple elpa package, so I won't have time to
package it until 2023.

Also, sorry, I'm not willing to package this one without a
comaintainer who is motivated to keep those Python bits working.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1025091: toot: Posting toots with media attachment fails

[gregor herrmann]

On Thu, 01 Dec 2022 08:48:29 +0100, Ivan Habunek wrote:

> On Tue, 29 Nov 2022, at 19:27, gregor herrmann wrote:
> > As far as I can guess from the debug output, toot expects something
> > in text_url the but reply from the server contains "text_url":null
> The text_url field was deprecated and seems to be removed in Mastodon 4. 
> This bug is fixed in toot 0.30.1. 

Thanks Ivan and highvoltage, nice to see this fixed in unstable.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1025021: python-bayespy: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'

[Håvard F . Aasen]

> 
> ==
> ERROR: test suite for  '/usr/lib/python3/dist-packages/bayespy/tests/__init__.py'>
> --
> Traceback (most recent call last):
>File "/usr/lib/python3/dist-packages/nose/suite.py", line 209, in run
>  self.setUp()
>File "/usr/lib/python3/dist-packages/nose/suite.py", line 292, in setUp
>  self.setupContext(ancestor)
>File "/usr/lib/python3/dist-packages/nose/suite.py", line 315, in 
> setupContext
>  try_run(context, names)
>File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run
>  inspect.getargspec(func)
>  ^^
> AttributeError: module 'inspect' has no attribute 'getargspec'
> 
> --
> Ran 127 tests in 26.429s
> 
> FAILED (errors=1)


This looks to be an error with nose, not python-bayespy. See bug #1024235 [1]


Håvard

[1] https://bugs.debian.org/1024235

Bug#1025267: Nimbus Roman: wrong glyph for ₤ (U+20A4 LIRA SIGN)

[Jakub Wilk]

Package: fonts-urw-base35
Version: 20200910-6

In the Nimbus Roman font, the character ₤ (U+20A4 LIRA SIGN) looks like 
"zł". It should look similar to £ (U+00A3 POUND SIGN) instead.


--
Jakub Wilk

Bug#1025259: libzfp-dev: cmake files misplaced

[Gürkan Myczko]

if you’re in a hurry please go ahead with team upload.

thank you

Gürkan



> On 1 Dec 2022, at 18:37, Helmut Grohne  wrote:
> 
> Control: tags -1 + patch
> 
>> On Thu, Dec 01, 2022 at 04:56:35PM +0100, Helmut Grohne wrote:
>> The cmake files shipped by libzfp-dev are misplaced. The upstream code
>> expects them to be in a multiarch location while the installation
>> procedure strips that multiarch directory (via debian/libzfp-dev.install
>> line 3). When cmake computes the installation prefix (by removing
>> trailing path components), it tries to remove the multiarch directory,
>> but ends up removing /usr thus looking for includes in /include, which
>> doesn't exist. What you see is this:
> 
> I'm attaching a patch for your convenience. Would you mind uploading it
> soonish or allowing Enrico or me to upload it as NMU or team upload?
> 
> Thanks in advance
> 
> Helmut
> 

Bug#1025266: RFS: zope.exceptions/4.6-1 [QA] [RC] -- Zope exceptions for Python 3

[Håvard F . Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "zope.exceptions":

 * Package name : zope.exceptions
   Version  : 4.6-1
   Upstream contact : Zope Foundation and Contributors 
 * URL  : https://github.com/zopefoundation/zope.exceptions
 * License  : Zope-2.1
 * Vcs  :
   Section  : zope

The source builds the following binary packages:

  python3-zope.exceptions - Zope exceptions for Python 3

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

  https://mentors.debian.net/package/zope.exceptions/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zope.exceptions/zope.exceptions_4.6-1.dsc

Changes since the last upload:

 zope.exceptions (4.6-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream release
 - Supports Python 3.11. Closes: #1025197

Regards,
Håvard

Bug#999926: Looking for an advice on PCRE2 and GLib regex

[Akbarkhon Variskhanov]

Hi.

Cc'ing pkg-gnome-maintainers because I'd like their advice and insight as well.

I'm working on porting xfce4-verve-plugin[1] to PCRE2. By chance, I
have come across GLib's regex API, which seems like a higher-level
wrapper around PCRE2. Perhaps you are familiar with it. If so, what
could you say about it? Is it stable or mature enough? Does it change
often or have bugs? Would you recommend using it?

It seems to me that it's a bit more straightforward but does it bring
any particular advantages over PCRE2? To be honest, xfce4-verve-plugin
uses regex only to test whether a given string is a URL or an email
within two simple functions, so it's nothing really major and I'm
almost done porting anyway. I'm just curious and interested to know
your thoughts.

[1] https://gitlab.xfce.org/panel-plugins/xfce4-verve-plugin/-/merge_requests/8

Bug#1023550: transition: qcustomplot

[Sudip Mukherjee]

Hi Filippo,

On Thu, Nov 24, 2022 at 09:59:49PM +0100, Filippo Rusconi wrote:
> Greetings Sebastian,
> 
> On Thu, Nov 24, 2022 at 09:05:07PM +0100, Sebastian Ramacher wrote:
> > Hi Filippo
> 
> [...]
> 
> > > > Thanks! Please go ahead with the transition.
> > > 
> > > I just uploaded the package to unstable. I have not closed the bug yet, 
> > > waiting
> > > to check that everything goes fine.
> > 
> > qcustomplot's autopkgtests are failing. Could you please take a look at
> > them? Thanks
> 
> It is weeks that I monitor the salsa stuff, but I do not understand what these
> tests mean. One example (bear with me):

The failures are because cmake could not find the library and so the
variable 'QCustomPlot_LIBRARIES' was empty and so while linking it did not
ask 'ld' to link with libqcustomplot. Please dont ask why.
Try the attached patch which will explicitely ask cmake to find the library
and save it to the variable. It worked in my schroot.


-- 
Regards
Sudip
diff -Nru qcustomplot-2.1.0+dfsg1/debian/changelog qcustomplot-2.1.0+dfsg1/debian/changelog
--- qcustomplot-2.1.0+dfsg1/debian/changelog	2022-11-25 10:01:09.0 +
+++ qcustomplot-2.1.0+dfsg1/debian/changelog	2022-12-01 17:36:10.0 +
@@ -1,3 +1,10 @@
+qcustomplot (2.1.0+dfsg1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix autopkgtest.
+
+ -- Sudip Mukherjee   Thu, 01 Dec 2022 17:36:10 +
+
 qcustomplot (2.1.0+dfsg1-3) unstable; urgency=low
 
   * Fix the autopkgtest by fixing the dependencies of libqcustomplot-dev: when
diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-axis qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-axis
--- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-axis	2022-11-25 10:01:09.0 +
+++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-axis	2022-12-01 16:27:01.0 +
@@ -19,6 +19,7 @@
 
 FIND_PACKAGE(QCustomPlot REQUIRED)
 FIND_PACKAGE(Qt5PrintSupport REQUIRED)
+find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
 set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
 
 set(CMAKE_AUTOMOC ON)
diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-inter qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-inter
--- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-inter	2022-11-25 10:01:09.0 +
+++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-inter	2022-12-01 17:26:26.0 +
@@ -19,6 +19,7 @@
 
 FIND_PACKAGE(QCustomPlot REQUIRED)
 FIND_PACKAGE(Qt5PrintSupport REQUIRED)
+find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
 set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
 
 set(CMAKE_AUTOMOC ON)
diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-plot qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-plot
--- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-plot	2022-11-25 10:01:09.0 +
+++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-plot	2022-12-01 17:26:40.0 +
@@ -19,6 +19,7 @@
 
 FIND_PACKAGE(QCustomPlot REQUIRED)
 FIND_PACKAGE(Qt5PrintSupport REQUIRED)
+find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
 set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
 
 set(CMAKE_AUTOMOC ON)
diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-scroll qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-scroll
--- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-scroll	2022-11-25 10:01:09.0 +
+++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-scroll	2022-12-01 17:26:50.0 +
@@ -19,6 +19,7 @@
 
 FIND_PACKAGE(QCustomPlot REQUIRED)
 FIND_PACKAGE(Qt5PrintSupport REQUIRED)
+find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
 set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
 
 set(CMAKE_AUTOMOC ON)
diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-text qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-text
--- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-text	2022-11-25 10:01:09.0 +
+++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-text	2022-12-01 17:27:05.0 +
@@ -19,6 +19,7 @@
 
 FIND_PACKAGE(QCustomPlot REQUIRED)
 FIND_PACKAGE(Qt5PrintSupport REQUIRED)
+find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
 set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
 
 set(CMAKE_AUTOMOC ON)
diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/control qcustomplot-2.1.0+dfsg1/debian/tests/control
--- qcustomplot-2.1.0+dfsg1/debian/tests/control	2022-11-25 10:01:09.0 +
+++ qcustomplot-2.1.0+dfsg1/debian/tests/control	2022-12-01 17:35:46.0 +
@@ -1,2 +1,3 @@
 Tests: buildtest-axis buildtest-inter buildtest-plot buildtest-scroll buildtest-text
 Depends: libqcustomplot-dev, build-essential, cmake
+Restrictions: allow-stderr

Bug#927255: powerpc-utils is uninstallable

[John Paul Adrian Glaubitz]

Hi Lance!

On 12/1/22 17:54, Lance Albertson wrote:

Unfortunately this is a major issue when trying to get a system installed using 
the
debian-installer. I am trying to support ppc64 (Big Endian) for our users, and 
Debian
is the only platform that still provides a modern ppc64 environment.


Thanks for the praise ;-). It is possible partially through the support of 
OSUOSL ;-).


I've created my own netboot install images using the latest sid environment, 
and I am
unable to work around this and get a system installed. While the solution above 
works
for debootstrap itself, it makes it impossible to get a system installed.

Could you change pmac-utils to Suggests instead of Depends? That way it should 
get things
working again. AFAIK this isn't a hard requirement anymore on ppc64 at least.


Yes, I will demote the package to Suggests or even remove it. I don't think 
it's necessary
anymore.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1025218: python3-urllib3: please drop dependance on python3-six

[Daniele Tricoli]

found 1025218 2.0.0-1
thanks

Hello Alexandre,
thanks for your report.

On 01/12/2022 03:27, Alexandre Detiste wrote:

Package: python3-urllib3
Version: 1.26.12-1
Severity: normal

Hi,

Please drop dependance on Python3-six.


The embedded copy has been removed from the upcoming release.

https://sources.debian.org/src/python-urllib3/1.26.12-1/src/urllib3/packages/six.py/
urllib3 from version 2.0.0 will not use six, yes, but for now we have to 
keep the dependency: version 2.0.0 is still alpha and since Debian will 
freeze soon, I don't plan to package 2.0.0 for unstable.

I will package it for experimental, but not right now.

Cheers,

--
Daniele Tricoli
https://mornie.org

Bug#1023020: cmark-gfm: FTBFS on s390x

[Keith Packard]

Scott Talbert  writes:

> On Wed, 30 Nov 2022, Keith Packard wrote:
>
>> Scott Talbert  writes:
>>
>>> @Keith, do you have time to upload this patch?  Unfortunately, this is
>>> blocking a large number of packages from migrating to testing.
>>> Alternatively, any objections to an NMU?
>>
>> Thanks for the NMU! Did you happen to create a git repo with this
>> change? I just noticed that the salsa repo is in my private space.
>>
>>g...@salsa.debian.org:keithp/cmark-gfm.git
>
> No, I didn't, since I wasn't aware you were using a Vcs for packaging (no 
> Vcs listed in d/control).
>
> I can send you a merge request with the changes, if you'd like?

That would be great. I'll see about moving this out of my personal salsa
area and do a new upload with control pointing at the vcs.

-- 
-keith


signature.asc
Description: PGP signature

Bug#1025259: libzfp-dev: cmake files misplaced

[Helmut Grohne]

Control: tags -1 + patch

On Thu, Dec 01, 2022 at 04:56:35PM +0100, Helmut Grohne wrote:
> The cmake files shipped by libzfp-dev are misplaced. The upstream code
> expects them to be in a multiarch location while the installation
> procedure strips that multiarch directory (via debian/libzfp-dev.install
> line 3). When cmake computes the installation prefix (by removing
> trailing path components), it tries to remove the multiarch directory,
> but ends up removing /usr thus looking for includes in /include, which
> doesn't exist. What you see is this:

I'm attaching a patch for your convenience. Would you mind uploading it
soonish or allowing Enrico or me to upload it as NMU or team upload?

Thanks in advance

Helmut

Bug#1025265: lua-cjson: diff for NMU version 2.1.0+dfsg-2.2

[Boyuan Yang]

Package: lua-cjson
Version: 2.1.0+dfsg-2.1
Severity: normal
Tags: patch  pending
X-Debbugs-CC: by...@debian.org mmyan...@gmail.com un...@debian.org

Dear maintainer,

I've prepared an NMU for lua-cjson (versioned as 2.1.0+dfsg-2.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

The NMU mainly adds support for lua5.3 and lua5.4. The purpose of this
NMU is to avoiding bundling another copy of lua-cjson source code when
packaging src:xmake ( https://bugs.debian.org/986736 ). For the git
packaging repo, having someone to create lua-team/lua-cjson.git on
Salsa would also be great. I am including this change in Vcs-* fields
in advance to avoid the necessity of yet another upload.

Please feel free to let me know if you have any doubts or questions.
Thanks!

Regards,
Boyuan Yang

diff -Nru lua-cjson-2.1.0+dfsg/debian/changelog lua-cjson-
2.1.0+dfsg/debian/changelog
--- lua-cjson-2.1.0+dfsg/debian/changelog   2018-01-20
15:15:36.0 -0500
+++ lua-cjson-2.1.0+dfsg/debian/changelog   2022-11-30
11:26:18.0 -0500
@@ -1,3 +1,19 @@
+lua-cjson (2.1.0+dfsg-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add lua version 5.3 (Closes: #872599, #942569).
+  * Add lua version 5.4.
+  * Add Rules-Requires-Root: no.
+  * Add hardening options.
+  * Bump debhelper compat to 13.
+  * Bump Standards-Version to 4.6.1.
+
+  [ Boyuan Yang ]
+  * debian/control: Migrate Vcs-* fields to Salsa lua-team.
+  * debian/copyright: Use latest machine-readable copyright format.
+
+ -- Yangfl   Thu, 01 Dec 2022 00:26:18 +0800
+
 lua-cjson (2.1.0+dfsg-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lua-cjson-2.1.0+dfsg/debian/compat lua-cjson-
2.1.0+dfsg/debian/compat
--- lua-cjson-2.1.0+dfsg/debian/compat  2012-08-24 09:21:32.0 -0400
+++ lua-cjson-2.1.0+dfsg/debian/compat  1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-7
-
diff -Nru lua-cjson-2.1.0+dfsg/debian/control lua-cjson-
2.1.0+dfsg/debian/control
--- lua-cjson-2.1.0+dfsg/debian/control 2018-01-20 15:15:36.0 -0500
+++ lua-cjson-2.1.0+dfsg/debian/control 2022-11-30 11:26:18.0 -0500
@@ -1,13 +1,14 @@
 Source: lua-cjson
 Maintainer: The Debian Lua Team 
 Uploaders: Dmitry E. Oboukhov 
-Build-Depends: debhelper (>= 9), dh-lua
-Standards-Version: 3.9.3
+Build-Depends: debhelper-compat (= 13), dh-lua
+Standards-Version: 4.6.1
 Section: interpreters
 Priority: optional
+Rules-Requires-Root: no
 Homepage: http://www.kyne.com.au/~mark/software/lua-cjson.php
-VCS-Git: git://anonscm.debian.org/collab-maint/liblua-cjson.git
-VCS-Browser:
http://anonscm.debian.org/gitweb/?p=collab-maint/liblua-cjson.git;a=summary
+Vcs-Git: https://salsa.debian.org/lua-team/lua-cjson.git
+Vcs-Browser: https://salsa.debian.org/lua-team/lua-cjson
 
 Package: lua-cjson
 Architecture: any
@@ -30,7 +31,7 @@
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, ${shlibs:Depends}, lua-cjson (=
${binary:Version})
+Depends: ${misc:Depends}, lua-cjson (= ${binary:Version})
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}
 Description: JSON parser/encoder for Lua, development files
diff -Nru lua-cjson-2.1.0+dfsg/debian/copyright lua-cjson-
2.1.0+dfsg/debian/copyright
--- lua-cjson-2.1.0+dfsg/debian/copyright   2012-08-24
09:21:32.0 -0400
+++ lua-cjson-2.1.0+dfsg/debian/copyright   2022-11-30
11:26:18.0 -0500
@@ -1,11 +1,21 @@
-Format-Specification:
http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?view=markup=135
-Maintainer: Mark Pulford 
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Source: http://www.kyne.com.au/~mark/software/lua-cjson.php
-Name: CJSON
+
+Files: *
+Copyright: 2010-2012, Mark Pulford 
+Comment: In the Lua community this license is better known as "MIT".
+  Unfortunately other variants of this license are also known as "MIT".
+  To obtain a machine intepretable copyright file Debian prefers to name
this
+  version of the MIT license using the non ambiguous term "Expat".
+License: Expat
+
+Files: debian/*
+Copyright: 2012, Dmitry E. Oboukhov 
+License: Expat
 
 Files: g_fmt.c, dtoa.c
 Copyright: 1991-2001, Lucent Technologies.
-License:
+License: Permissive
  Permission to use, copy, modify, and distribute this software for any
  purpose without fee is hereby granted, provided that this entire notice
  is included in all copies of any software which is or includes a copy
@@ -17,16 +27,6 @@
  REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
  OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
 
-Files: debian/*
-Copyright: 2012, Dmitry E. Oboukhov 
-License: Expat
-
-Files: *
-Copyright: 2010-2012, Mark Pulford 
-Comment: In the Lua community this license is better known as "MIT".
-  Unfortunately other variants of this license are also known as "MIT".
-  To obtain a machine intepretable copyright file Debian prefers to name
this
-  

Bug#1025264: mmsd-tng: Can't send MMS message because of missing Content Type

[Daniel Dehennin]

Package: mmsd-tng
Version: 2.0~beta-1+b1
Severity: important

Dear Maintainer,

Since I updated my mobian phone with the beta package now in testing, I
can't send MMS any more:

nov. 30 12:05:53 mobian mmsdtng[2720]: ../src/service.c:process_request() 
Sending 
nov. 30 12:05:53 mobian mmsdtng[2720]: GSocketClient: Starting new address 
enumeration
nov. 30 12:05:53 mobian mmsdtng[2720]: GSocketClient: Address enumeration 
succeeded
nov. 30 12:05:53 mobian mmsdtng[2720]: GSocketClient: Starting TCP connection 
attempt
nov. 30 12:05:53 mobian mmsdtng[2720]: 
../src/service.c:soupmessage_network_event_cb() Socket 12 Binding to wwan0 
length 5
nov. 30 12:05:53 mobian mmsdtng[2720]: 
../src/service.c:soupmessage_network_event_cb() Socket is bound to wwan0
nov. 30 12:05:53 mobian mmsdtng[2720]: GSocketClient: TCP connection successful
nov. 30 12:05:53 mobian mmsdtng[2720]: GSocketClient: Starting application 
layer connection
nov. 30 12:05:53 mobian mmsdtng[2720]: GSocketClient: Connection successful!
nov. 30 12:05:53 mobian mmsdtng[2720]: > POST / HTTP/1.1
nov. 30 12:05:53 mobian mmsdtng[2720]: > Soup-Debug-Timestamp: 1669799969
nov. 30 12:05:53 mobian mmsdtng[2720]: > Soup-Debug: SoupSession 1 
(0x558c1cb8c0), SoupMessage 1 (0x558c24b470), GSocket 1 (0x7f8c009520)
nov. 30 12:05:53 mobian mmsdtng[2720]: > Host: mms.free.fr
nov. 30 12:05:53 mobian mmsdtng[2720]: > Content-Length: 115859
nov. 30 12:05:53 mobian mmsdtng[2720]: > Accept-Encoding: gzip, deflate
nov. 30 12:05:53 mobian mmsdtng[2720]: > Connection: Keep-Alive
nov. 30 12:05:53 mobian mmsdtng[2720]: >
nov. 30 12:05:53 mobian mmsdtng[2720]: [45B blob data]
nov. 30 12:05:53 mobian mmsdtng[2720]:   
nov. 30 12:05:53 mobian mmsdtng[2720]: < HTTP/1.1 400 Bad Request
nov. 30 12:05:53 mobian mmsdtng[2720]: < Soup-Debug-Timestamp: 1669799970
nov. 30 12:05:53 mobian mmsdtng[2720]: < Soup-Debug: SoupMessage 1 
(0x558c24b470)
nov. 30 12:05:53 mobian mmsdtng[2720]: < Date: Wed, 30 Nov 2022 09:19:29 GMT
nov. 30 12:05:53 mobian mmsdtng[2720]: < Server: Apache/2.4.41 (Ubuntu)
nov. 30 12:05:53 mobian mmsdtng[2720]: < Content-Length: 0
nov. 30 12:05:53 mobian mmsdtng[2720]: < Connection: close
nov. 30 12:05:53 mobian mmsdtng[2720]: < Content-Type: text/html; charset=UTF-8

This bug is solved upstream[1] in the 2.0.0 release[2].

Could you integrate this new release?

Thanks.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.15-sunxi64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_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)

Versions of packages mmsd-tng depends on:
ii  init-system-helpers   1.65.2
ii  libc-ares21.18.1-1+b2
ii  libc6 2.36-5
ii  libgcc-s1 12.2.0-9
ii  libglib2.0-0  2.74.1-2
ii  libmm-glib0   1.20.0-1
ii  libphonenumber8 [libphonenumber8-protobuf32]  8.12.57+ds-3
ii  libsoup-3.0-0 3.2.1-2
ii  libstdc++612.2.0-9

Versions of packages mmsd-tng recommends:
ii  modemmanager  1.20.0-1

mmsd-tng suggests no packages.

-- no debconf information


Footnotes:
[1]  
https://gitlab.com/kop316/mmsd/-/commit/53e01a6d4f6dd09642c34392d0e4666488584d6b

[2]  https://gitlab.com/kop316/mmsd/-/tags/2.0.0

-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF


signature.asc
Description: PGP signature

Bug#1025263: evolution: The red line indicator for time and date is not on the correct day

[skill]

Package: evolution
Version: 3.46.1-1
Severity: important

Dear Maintainer,

After updating my system, the red line displayed on the calander is displayed
on Friday dec 2 instead of the current date.

I played around with the date settings in the Gnome control panel, and tried
rebooting. I also checked through evolution settings but of course there was
nothing for setting the current time indicator to a future date/time.

I discoverd the problem due to appointment confusion between today's and
tomorrow's appointments. I almost missed one. Now that I know the problem is
less serious for me. However it could cause similar problems for unaware users.

Since the problem involves being off by exactly 1 day, I'm thinking there is an
n+1 array error somewhere in this version.

If you need any additional information, let me know. I'm happy to help.

regards,
will


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 evolution depends on:
ii  dbus [default-dbus-system-bus]  1.14.4-1
ii  evolution-common3.46.1-1
ii  evolution-data-server   3.46.1-1+b2
ii  libc6   2.36-5
ii  libcamel-1.2-64 3.46.1-1+b2
ii  libecal-2.0-2   3.46.1-1+b2
ii  libedataserver-1.2-27   3.46.1-1+b2
ii  libevolution3.46.1-1
ii  libglib2.0-02.74.1-2
ii  libgtk-3-0  3.24.35-1
ii  libical33.0.16-1+b1
ii  libnotify4  0.8.1-1
ii  libwebkit2gtk-4.1-0 2.38.2-1+b1
ii  libxml2 2.9.14+dfsg-1.1+b2
ii  psmisc  23.5-3

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.46.1-1
ii  evolution-plugin-pstimport   3.46.1-1
ii  evolution-plugins3.46.1-1
ii  yelp 42.2-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.40-1
ii  network-manager 1.40.4-1

-- debconf-show failed

Bug#1025262: mir FTBFS, symbols files issues.

[Peter Green]

Source: mir
Version: 1.8.2+dfsg-3
Severity: serious
Tags: ftbfs

mir FTBFS on all architectures with symbols files issues
(there was previously a bug report for hppa, but since it now fails on release
architectures I feel a seperate bug report is deserved).

https://buildd.debian.org/status/fetch.php?pkg=mir=amd64=1.8.2%2Bdfsg-4%2Bb1=1669159921=0

--- debian/libmirprotobuf3.symbols (libmirprotobuf3_1.8.2+dfsg-4+b1_amd64)
+++ dpkg-gensymbolskixGS3   2022-11-22 23:31:49.399075926 +
@@ -8,75 +8,85 @@
  MIR_PROTOBUF_PROTOBUF_3.6.0@MIR_PROTOBUF_PROTOBUF_3.6.0 1.7
  MIR_PROTOBUF_UBSAN@MIR_PROTOBUF_UBSAN 1.7
  _ZN3mir8protobuf10Connection12InternalSwapEPS1_@MIR_PROTOBUF_FEDORA 1.7
- _ZN3mir8protobuf10Connection16default_instanceEv@MIR_PROTOBUF_3 1.7
+#MISSING: 1.8.2+dfsg-4+b1# 
_ZN3mir8protobuf10Connection16default_instanceEv@MIR_PROTOBUF_3 1.7
  
_ZN3mir8protobuf10Connection21CheckTypeAndMergeFromERKN6google8protobuf11MessageLiteE@MIR_PROTOBUF_3
 1.7
  _ZN3mir8protobuf10Connection5ClearEv@MIR_PROTOBUF_3 1.7
  _ZN3mir8protobuf10Connection8CopyFromERKS1_@MIR_PROTOBUF_3 1.7
  _ZN3mir8protobuf10Connection9MergeFromERKS1_@MIR_PROTOBUF_3 1.7
- (arch=alpha amd64 arm64 armel armhf i386 m68k mips64el mipsel powerpc ppc64 
ppc64el riscv64 s390x sh4 sparc64 
x32)_ZN3mir8protobuf10ConnectionC1EPN6google8protobuf5ArenaE@MIR_PROTOBUF_3 
1.8.0+dfsg1
+#MISSING: 1.8.2+dfsg-4+b1# (arch=alpha amd64 arm64 armel armhf i386 m68k 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 
x32)_ZN3mir8protobuf10ConnectionC1EPN6google8protobuf5ArenaE@MIR_PROTOBUF_3 
1.8.0+dfsg1
+ _ZN3mir8protobuf10ConnectionC1EPN6google8protobuf5ArenaEb@MIR_PROTOBUF_3 
1.8.2+dfsg-4+b1
  _ZN3mir8protobuf10ConnectionC1ERKS1_@MIR_PROTOBUF_3 1.7
  (arch=hppa)_ZN3mir8protobuf10ConnectionC1Ev@MIR_PROTOBUF_3 1.8.0+dfsg1
- (arch=alpha amd64 arm64 armel armhf i386 m68k mips64el mipsel powerpc ppc64 
ppc64el riscv64 s390x sh4 sparc64 
x32)_ZN3mir8protobuf10ConnectionC2EPN6google8protobuf5ArenaE@MIR_PROTOBUF_3 
1.8.0+dfsg1
+#MISSING: 1.8.2+dfsg-4+b1# (arch=alpha amd64 arm64 armel armhf i386 m68k 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 
x32)_ZN3mir8protobuf10ConnectionC2EPN6google8protobuf5ArenaE@MIR_PROTOBUF_3 
1.8.0+dfsg1
+ _ZN3mir8protobuf10ConnectionC2EPN6google8protobuf5ArenaEb@MIR_PROTOBUF_3 
1.8.2+dfsg-4+b1
  _ZN3mir8protobuf10ConnectionC2ERKS1_@MIR_PROTOBUF_3 1.8.0+dfsg1
  (arch=hppa)_ZN3mir8protobuf10ConnectionC2Ev@MIR_PROTOBUF_3 1.8.0+dfsg1

and so on.

I presume this is related to the new version of protobuf.

Bug#1025261: vagrant: Broken with ruby3.1

[Guillem Jover]

Package: vagrant
Version: 2.2.19+dfsg-1
Severity: serious

Hi!

After the upgrade of ruby to the 3.1 version vagrant has stopped
working completely, I'm getting the following errors repeated multiple
times:

,---
/usr/lib/ruby/vendor_ruby/rubygems/resolver/conflict.rb:47:in 
`conflicting_dependencies': undefined method `request' for nil:NilClass 
(NoMethodError)

[@failed_dep.dependency, @activated.request.dependency]
   
from /usr/lib/ruby/vendor_ruby/rubygems/exceptions.rb:61:in 
`conflicting_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/exceptions.rb:55:in `initialize'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `exception'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `raise'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `rescue in 
resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:191:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:411:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:423:in 
`resolve_current'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:230:in `finish_resolve'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:287:in `block in 
activate_bin_path'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `activate_bin_path'
from /usr/bin/vagrant:25:in `'
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:317:in
 `raise_error_unless_state': Unable to satisfy the following requirements: 
(Gem::Resolver::Molinillo::VersionConflict)

- `vagrant (= 2.2.19)` required by `user-specified dependency`
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:299:in
 `block in unwind_for_conflict'
from :90:in `tap'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:297:in
 `unwind_for_conflict'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:682:in
 `attempt_to_activate'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:254:in
 `process_topmost_state'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:182:in
 `resolve'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolver.rb:43:in
 `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:190:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:411:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:423:in 
`resolve_current'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:230:in `finish_resolve'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:287:in `block in 
activate_bin_path'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `activate_bin_path'
from /usr/bin/vagrant:25:in `'
`---

Installing ruby3.0 and forcing the «/usr/bin/ruby» symlink back to
ruby3.0 make vagrant work again.

Thanks,
Guillem

Bug#1024802: here is a hw probe of my system

[Timothy L. Mieszkowski]

https://linux-hardware.org/?probe=51cf6d10e7

To reiterate this system is mostly working but headless.
The only monitor I can get to work is a smart TV, dumb DP displays show no
output neither does dumb tv.

The screen goes blank shortly into booting

Thanks,
Tim

Bug#941627: Packaging grub-btrfs

[Pascal Jäger]

am one of the devs of grub-btrfs and I am the one responsible for the last few 
updates to it.

Recently the idea arose to make a Debian package for it. [1]
While researching how to do that I found this ITP.
Now this kind of is on ice, the last reply was more than a year ago, and I 
wonder why. And how we should proceed on this.
I already filed another ITP which should be closed, I guess.
We have a package already from the dev of Kaisen Linux which that dev wanted to 
contribute to Debian after getting a sponsor.
So if you are still interested into packaging grub-btrfs I would suggest the 
guy from kaisen linux prepares his Debian package and you sponsor it maybe?

Best,
Pascal

[1] https://github.com/Antynea/grub-btrfs/discussions/236 
(https://github.com/Antynea/grub-btrfs/discussions/236#discussioncomment-4237797)

Bug#927255: powerpc-utils is uninstallable

[Lance Albertson]

On Mon, 6 Sep 2021 18:39:57 +0200 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hello!
>
> On 9/6/21 18:36, Pierre Neyron wrote:
> > Yes, the following command running on a buster system complains about
> > pmac-utils in the second stage:
> >
> > debootstrap --foreign --arch=ppc64 --no-check-gpg '--include=locales
> > openssh-server linux-image-powerpc64' sid /rootfs
> > https://deb.debian.org/debian-ports
>
> pmac-utils is part of the unreleased repository, so you need to install
> it afterwards. I don't recommend running debootstrap with the kernel
> included which probably pulls in powerpc-utils.
>
> Once you have created the chroot, use the following sources.list [1] which
> should allow you to install powerpc-utils.
>
> Adrian
>
> > [1] https://people.debian.org/~glaubitz/sources.list

Unfortunately this is a major issue when trying to get a system installed
using the debian-installer. I am trying to support ppc64 (Big Endian) for
our users, and Debian is the only platform that still provides a modern
ppc64 environment.

I've created my own netboot install images using the latest sid
environment, and I am unable to work around this and get a system
installed. While the solution above works for debootstrap itself, it makes
it impossible to get a system installed.

Could you change pmac-utils to Suggests instead of Depends? That way it
should get things working again. AFAIK this isn't a hard requirement
anymore on ppc64 at least.

Thanks!

-- 
Lance Albertson
Director
Oregon State University | Open Source Lab

Bug#1025260: RM: wtdbg2 [arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha hppa hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k powerpc ppc64 riscv64 sh4 sparc64 x32] -- ROM; Several archite

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 1025...@bugs.debian.org

Hi ftpmasters,

according to bug #1025249 this package shows flaky autopkgtests for
several architectures on other the tests do not run at all.  Thus it
seems to be the best solution to restrict the architectures to amd64
only since this is the architecture tested by upstream.

Kind regards and thanks for your work as ftpmaster

  Andreas.

Bug#1025171: [Pkg-zfsonlinux-devel] Bug#1025171: zfs-dkms FTBFS against 6.0.0-5-amd64

[M. Zhou]

Control: reassign -1 dkms 3.0.8-2
Control: retitle -1 regression: dkms/3.0.8-2 renders zfs-dkms FTBFS
Control: severity -1 serious

Hi,

Thank you for the information! I can confirm that this is the same issue
that you have encountered. By commenting out the --environment-overrides,
the current zfs-dkms package can be built against 6.0.0-5-amd64 successfully.

According to the build log when I filed the bug report, the problem is indeed
that the compiler cannot find the header files. I believed it was some -I ...
flags missing due to some reason.

So it is a regression bug in dkms/3.0.8-2, as -I flags needed for zfs-dkms
are accidentally removed.

On Wed, 2022-11-30 at 22:56 +, Heikki Kallasjoki wrote:
> There isn't enough detail to be sure, but this might be the same issue I
> hit on sid yesterday, so adding it here. It might also count as a dkms
> bug for all I know.
> 
> In my case, zfs-dkms fails to build against either of my currently
> installed kernels (5.19.0-1-amd64, 6.0.0-5-amd64), but only after
> updating the package dkms to version 3.0.8-2 (from 3.0.8-1).
> 
> This appears to be the result of the changes to the export-CC.patch:
> https://sources.debian.org/patches/dkms/3.0.8-2/export-CC.patch/
> 
> The 3.0.8-2 version adds the following commands to the prepare_build()
> function:
> 
> export CC=$CC
> export MAKEFLAGS="--environment-overrides"
> 
> I've verified that zfs-dkms builds fine for me if I temporarily comment
> out the second line from /usr/sbin/dkms.
> 
> A build log for a failed attempt (with the flag present) is at:
> https://0x0.st/o0fu.txt
> 
> The log also includes a dump of the environment variables at the start
> of the build, from a command I added to the dkms script.
> 
> Digging a little deeper, it appears that when `--environment-overrides`
> is set, a number of required command-line options (in particular, an -I
> option to add /var/lib/dkms/zfs/2.1.6/build/include in the include
> search path) fail to be set. I didn't manage to trace why exactly that
> is, but you can see both a failing and a working example (for one object
> file) at:
> https://0x0.st/o0EC.txt
> 
> FWIW, it seems like the build environment dkms uses inherits whatever
> was present in the environment when apt was called. If this is the case,
> then it feels to me including the `--environment-overrides` flag has
> potential to make things brittle. The effect of the flag is to: "Give
> variables taken from the environment precedence over variables from
> makefiles." Any arbitrary environment variables the user may have set
> for their own purposes might be unexpectedly overriding important
> variables from the Makefile(s).
> 
> ___
> Pkg-zfsonlinux-devel mailing list
> pkg-zfsonlinux-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel

Bug#1025249: wtdbg2: flaky autopkgtest: Segmentation fault

[Andreas Tille]

Hi Paul,

Am Thu, Dec 01, 2022 at 01:54:09PM +0100 schrieb Paul Gevers:
> https://ci.debian.net/data/autopkgtest/stable/ppc64el/w/wtdbg2/28644876/log.gz
> 
> [Sat Nov 26 06:40:02 2022] masked 154 repeat-like nodes by local subgraph
> analysis
> [Sat Nov 26 06:40:02 2022] generating edges
> /tmp/autopkgtest-lxc.t8xpx53w/downtmp/build.dY0/src/debian/tests/run-unit-test:
> line 23:  1447 Segmentation fault  wtdbg2 -x rs -g 4.6m -i
> pacbio_filtered.fastq -t 16 -fo dbg
> 
> 
> https://ci.debian.net/data/autopkgtest/testing/ppc64el/w/wtdbg2/27771576/log.gz
> 
> [Thu Nov  3 00:50:18 2022] sorting regs ...  Done
> [Thu Nov  3 00:50:19 2022] generating intervals ... 
> /tmp/autopkgtest-lxc.wcfl1vkh/downtmp/build.kT7/src/debian/tests/run-unit-test:
> line 23:  1310 Segmentation fault  wtdbg2 -x rs -g 4.6m -i
> pacbio_filtered.fastq -t 16 -fo dbg

OK, I excluded ppc64el.
 
> https://ci.debian.net/data/autopkgtest/testing/arm64/w/wtdbg2/26361496/log.gz
> 
> [Fri Sep 23 22:33:59 2022] masked 154 repeat-like nodes by local subgraph
> analysis
> [Fri Sep 23 22:33:59 2022] generating edges
> /tmp/autopkgtest-lxc.7iunliwg/downtmp/build.Yi1/src/debian/tests/run-unit-test:
> line 23:  2686 Segmentation fault  wtdbg2 -x rs -g 4.6m -i
> pacbio_filtered.fastq -t 16 -fo dbg

I decided to restrict the package to amd64 only since this is the
architecture which is most probably used and tested by upstream.

BTW, the autopkgtest for riscv64 does not have "Segmentation fault"
but

  
https://ci.debian.net/data/autopkgtest/unstable/riscv64/w/wtdbg2/27987776/log.gz

has:

1 contigs 2500 edges 0 basesautopkgtest [14:18:48]: ERROR: timed out on command 
"su -s /bin/bash debci -c set -e; export USER=`id -nu`; . /etc/profile 
>/dev/null 2>&1 || true;  . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.a93se6k6/downtmp/build.2Wn/src"; mkdir -p -m 
1777 -- "/tmp/autopkgtest-lxc.a93se6k6/downtmp/run-unit-test-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.a93se6k6/downtmp/run-unit-test-artifacts";
 export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.a93se6k6/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.a93se6k6/downtmp/autopkgtest_tmp"; export 
ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export 
LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE LC_CTYPE 
LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME 
LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;cd 
"$buildtree"; chmod +x 
/tmp/autopkgtest-lxc.a93se6k6/downtmp/build.2Wn/src/debian/tests/run-unit-test; 
exec /tmp/autopkgtest-lxc.a93se6k6/downtmp/wrapper.sh 
--script-pid-file=/tmp/autopkgtest_script_pid 
--stderr=/tmp/autopkgtest-lxc.a93se6k6/downtmp/run-unit-test-stderr 
--stdout=/tmp/autopkgtest-lxc.a93se6k6/downtmp/run-unit-test-stdout -- 
/tmp/autopkgtest-lxc.a93se6k6/downtmp/build.2Wn/src/debian/tests/run-unit-test 
;" (kind: test)


This does not make the testing itself better, but I wanted to mention
this in case the debci setup needs to adjust some timeouts.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1025246: libunibreak1: Not multi-arch co-installable

[Sebastian Ramacher]

On 2022-12-01 12:29:06 +, Simon McVittie wrote:
> Package: libunibreak1
> Version: 1.1-2.1
> Severity: normal
> Control: affects -1 + src:libass
> X-Debbugs-Cc: lib...@packages.debian.org
> 
> libunibreak1 and libunibreak-dev are not multi-arch co-installable. With
> the recent upload of libass 1:0.17.0-1, which gained a dependency on
> libunibreak1, this prevents co-installation of this dependency chain
> for both amd64 and i386 at the same time:
> 
> gstreamer1.0-libav -> libavfilter8 -> libass9 -> libunibreak1
> 
> libwine Suggests gstreamer1.0-libav, in order to support all possible
> audio and video codecs. This means we can't have full audio and video
> support in both 32-bit Wine and 64-bit Wine at the same time until
> libunibreak1 becomes Multi-Arch: same.
> 
> This looks like relatively simple shared library packaging, so I'll try
> to provide a patch.
> 
> If unibreak support in libass is optional, then the maintainers of libass
> could work around this bug by disabling it, or by disabling it on i386.

If have reverted the change in libass. Once this issue is fixed, I'll
renable libunibreak.

Cheers

> 
> smcv
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
> 'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
> 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (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 libunibreak1 depends on:
> ii  libc6  2.36-6
> 
> libunibreak1 recommends no packages.
> 
> libunibreak1 suggests no packages.
> 
> -- no debconf information
> 

-- 
Sebastian Ramacher

Bug#1025259: libzfp-dev: cmake files misplaced

[Helmut Grohne]

Package: libzfp-dev
Version: 1.0.0-3
Severity: important
X-Debbugs-Cc: enr...@debian.org

The cmake files shipped by libzfp-dev are misplaced. The upstream code
expects them to be in a multiarch location while the installation
procedure strips that multiarch directory (via debian/libzfp-dev.install
line 3). When cmake computes the installation prefix (by removing
trailing path components), it tries to remove the multiarch directory,
but ends up removing /usr thus looking for includes in /include, which
doesn't exist. What you see is this:

| Make Error in src/CMakeLists.txt:
|   Imported target "zfp::zfp" includes non-existent path
| 
| "/include"
| 
|   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
| 
|   * The path was deleted, renamed, or moved to another location.
| 
|   * An install or uninstall procedure did not complete successfully.
| 
|   * The installation package was faulty and references files it does not
|   provide.

Helmut

Bug#1025258: python3-bleak: excessive Depends

[Helmut Grohne]

Package: python3-bleak
Version: 0.19.4-1

Compared to 0.16.0-1, python3-bleak gained quite some dependencies, some
of which are fairly unexpected:

python3-sphinx-rtd-theme: Given that there is python-bleak-doc, I would
not have expected any sphinx-related dependencies on python3-bleak.

python3-flake8, python3-pytest-asyncio, python3-pytest-cov: These seem
all seem like they'd only be required for testing bleak.

The accumulated dependencies increase the cumulative installation size
of python3-bleak by more than 10MB.

Helmut

Bug#1024395: grub-efi-amd64-signed: related to #1024447?

[Garrett McLean]

Package: grub-efi-amd64-bin
Version: 1+2.06+3~deb11u4
Followup-For: Bug #1024395

Dear Maintainer,

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

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

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

Hello,

Chiming in to say that I too am not seeing my mok in
mokutil --list-enrolled, which is strange because the drivers are
definitely signed, loaded and working just swell with sb enabled.

Also: when I select my stable installation on the grub menu, the screen turns
mostly black and I see something about about an efi stub and secure boot
being enabled. After a few seconds of this, kernel messages appear as normal.

GRUB_GFXMODE and GRUB_GFXPAYLOAD_LINUX both seem to be ignored, or at
least, don't display the requested resolution.

videoinfo and videotest are "prohibited due to sb policy" (I paraphrase,
but that's the gist).

And, as in #1024447, I see ?s instead of lines bordering the grub menu.

Disabling sb fixes all these errors.

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

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

Versions of packages grub-efi-amd64-signed depends on:
ii  grub-common  2.06-3~deb11u4

Versions of packages grub-efi-amd64-signed recommends:
ii  shim-signed  1.38+15.4-7

grub-efi-amd64-signed suggests no packages.

Versions of packages grub-efi-amd64-bin depends on:
ii  grub-common  2.06-3~deb11u4

Versions of packages grub-efi-amd64-bin recommends:
ii  efibootmgr  17-1

-- no debconf information

Bug#1020926: added rsync support

[Teresa Cancino]

Hi Folks!


We have added rsync support to the mirror:


Protocols: HTTP, HTTPS and RSYNC

rsync access: rsync://mirror.hnd.cl/debian

Regards

Bug#1025257: chkrootkit: Add possibility to skip large directory scans in find

[Peter Gervai]

Package: chkrootkit
Version: 0.55-4+b2
Severity: wishlist
Tags: patch upstream

Would be nice to skip extremely large directories which the admin choose to 
skip in the scan.
Typical examples are /var/lib/backuppc or similar backup dirs, or various large 
mounts.
The following patch contains only a few changes in the find calls where it uses 
a complete root dir scan.
I hope I was successful doing it POSIX safe, but please check.

(Sidenote: I see you commented out '-o' at the end of the $findargs, is it 
correct this way?)


--- chkrootkit.orig 2022-08-17 15:47:55.0 +0200
+++ chkrootkit  2022-12-01 15:38:30.214332133 +0100
@@ -417,7 +417,7 @@
 [ -d ${ROOTDIR}/usr/lib/lib.so1.so ] && expertmode_output ${find} 
${ROOTDIR}/usr/lib/lib.so1.so
 ### sniffer's logs
 expertmode_output "${find} ${ROOTDIR}dev ${ROOTDIR}usr ${ROOTDIR}tmp \
-   ${ROOTDIR}lib ${ROOTDIR}etc ${ROOTDIR}var ${findargs} -name tcp.log -o 
-name \
+   ${ROOTDIR}lib ${ROOTDIR}etc ${ROOTDIR}var ${findargs} 
${FIND_EXCLUDE_ARGS} -name tcp.log -o -name \
 .linux-sniff -o -name sniff-l0g -o -name core_ -o -wholename 
${ROOTDIR}usr/lib/in.httpd -o \
 -wholename ${ROOTDIR}usr/lib/in.pop3d"
 
@@ -707,7 +707,7 @@
if [ "${QUIET}" != "t" ]; then \
   printn "Searching for sniffer's logs, it may take a while... "; fi
files=`${find} ${ROOTDIR}dev ${ROOTDIR}tmp ${ROOTDIR}lib ${ROOTDIR}etc 
${ROOTDIR}var \
-   ${findargs} \( -name "tcp.log" -o -name ".linux-sniff" -o -name "sniff-l0g" 
-o -name "core_" \) \
+   ${findargs} ${FIND_EXCLUDE_ARGS} \( -name "tcp.log" -o -name ".linux-sniff" 
-o -name "sniff-l0g" -o -name "core_" \) \
2>/dev/null`
if [ "${files}" = "" ]
then
@@ -2943,6 +2943,9 @@
 
 -e) shift
 EXCLUDES="$1 $EXCLUDES";;
+
+-E) shift
+EXCLUDE_DIRS="$1 $EXCLUDE_DIRS";;
 
 -s) shift
 EXCLUDES_SNIF="$1";;
@@ -2969,6 +2972,7 @@
 -xexpert mode
 -e 'FILE1 FILE2'  exclude files/dirs from results. Must be followed by 
a space-separated list of files/dirs.
   Read 
/usr/share/doc/chkrootkit/README.FALSE-POSITIVES first.
+-E 'DIR1 DIR2'exclude dirs (actually 'find' path patterns) from 
scanning.
 -s REGEXP filter results of sniffer test through 'grep -Ev 
REGEXP' to exclude expected
   PACKET_SNIFFERs. Read 
/usr/share/doc/chkrootkit/README.FALSE-POSITIVES first.
 -r DIRuse DIR as the root directory
@@ -3002,6 +3006,14 @@
 pth=`echo $PATH | sed -e "s/:/ /g"`
 pth="$pth /sbin /usr/sbin /lib /usr/lib /usr/libexec ."
 
+### Excluded paths from find (split the string, POSIX style)
+set -f
+FIND_EXCLUDE_ARGS=""
+for p in $EXCLUDE_DIRS; do
+   FIND_EXCLUDE_ARGS="${FIND_EXCLUDE_ARGS} -path ${p} -prune -o "
+done
+set +f
+
 ### external command's PATH
 if [ "${CHKRKPATH}" = "" ]; then
   chkrkpth=${pth}



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

Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages chkrootkit depends on:
ii  libc6  2.36-4

Versions of packages chkrootkit recommends:
ii  binutils   2.39-8
ii  iproute2   6.0.0-1+b1
ii  net-tools  1.60+git20181103.0eebece-1
ii  procps 2:3.3.17-7+b1

chkrootkit suggests no packages.

-- Configuration Files:
/etc/cron.daily/chkrootkit changed [not included]

Bug#1025176: libicu71 missing on SH4 port

[Jeffrey Walton]

On Thu, Dec 1, 2022 at 9:53 AM Jeffrey Walton  wrote:
>
> On Wed, Nov 30, 2022 at 8:26 PM Jeffrey Walton  wrote:
> >
> > On Wed, Nov 30, 2022 at 5:14 PM László Böszörményi (GCS)  
> > wrote:
> > > ...
> > >  You may locally hack the build of boost1.74 not to require Python
> > > (and drop its related binary packages). Of course, best would be to
> > > port python-greenlet to sh4 or just fix its build - can you give a
> > > helping hand to its upstream?
> > > At least this is what I see without access to any sh4 machine. As we
> > > know each other, I may check it for you if I can access that machine.
> > > But I think you are much more skilled in these things.
> >
> > Yes, sure. Let me take a look at python-greenlet on SH4.
>
> Ok, so I had a look at this last night. I don't think I am going to be
> able to help with improving Greenlet. For Greenlet, I think the best
> course of action is to ping the Greenlet developers and ask them for
> help with SH4.
>
> The #error is triggered because there's no switch_sh4_linux.h in [1].
> The file provides a function called slp_switch(), and it is inline
> ASM. Based on other arch files, it looks like the function does some
> sort of manual switching on app-managed lightweight threads. So the
> function uses inline ASM to save/restore registers and move the stack
> pointer around (if I am parsing things correctly).
>
> Unfortunately, I think that's a bit outside my comfort zone. I don't
> know Greenlet, and I don't know SH4 ASM. For completeness, here is the
> SH4 software manual: [2].
>
> If the Greenlet developers decline to port to SH4, then I think the
> next step is to remove the Greenlet dependency on SH4. Maybe there's a
> configure option in GDB, Boost or Python that can ultimately sidestep
> the dependency on SH4. I think the first team to engage is the GDB
> team. They may have a suggestion to shed the Boost dependency.
>
> [1] 
> https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform
> [2] https://www.renesas.com/us/en/document/mas/sh-4-software-manual

Ok, so it looks like the Greenlet developers have an open bug report
at [1]. It was opened Apr 19, 2020. I'm guessing the Greenlet
developers are not going to provide the support given they've had over
2 years to do so.

I think that leaves contacting the GDB folks to see if there's a way
to sidestep Boost dependency.

[1] https://github.com/python-greenlet/greenlet/issues/166

Bug#1025213: gnome-shell: Flickering and mangled screens on wayland if dri driver not available

[Gert van de Kraats]

Hello Simon,

Unfortunately my 32-bit Dell-laptop does not crash and I think the 
software-boys should not stop delivery of


software for older hardware, forcing to waste good working hardware.

Therefore I will use Debian testing as long as it supports 32-bit, so at 
least some one is testing something at 32-bit.


My previous upgrade was 2022-11-06, the next failing upgrade was 2022-11-27.

It contains 921 packages; also upgrade libgl1-mesa-dri:i386 22.2.0-1 
22.2.4-1 .


I am not sure problem is at gnome-shell itself.

I am almost sure it is not at mesa/swrast. I ran lsof for gnome-shell to 
check the open files.


If the i915 driver is present at X and wayland the i915 shared library 
is shown.


If the driver is not present at X the swrast library is shown, but not 
at wayland.


Perhaps gtk/pango is used for software-rendering at wayland.

I will try to downgrade gnome-shell and dependent packages.

Bug#1025176: libicu71 missing on SH4 port

[Jeffrey Walton]

On Wed, Nov 30, 2022 at 8:26 PM Jeffrey Walton  wrote:
>
> On Wed, Nov 30, 2022 at 5:14 PM László Böszörményi (GCS)  
> wrote:
> > ...
> >  You may locally hack the build of boost1.74 not to require Python
> > (and drop its related binary packages). Of course, best would be to
> > port python-greenlet to sh4 or just fix its build - can you give a
> > helping hand to its upstream?
> > At least this is what I see without access to any sh4 machine. As we
> > know each other, I may check it for you if I can access that machine.
> > But I think you are much more skilled in these things.
>
> Yes, sure. Let me take a look at python-greenlet on SH4.

Ok, so I had a look at this last night. I don't think I am going to be
able to help with improving Greenlet. For Greenlet, I think the best
course of action is to ping the Greenlet developers and ask them for
help with SH4.

The #error is triggered because there's no switch_sh4_linux.h in [1].
The file provides a function called slp_switch(), and it is inline
ASM. Based on other arch files, it looks like the function does some
sort of manual switching on app-managed lightweight threads. So the
function uses inline ASM to save/restore registers and move the stack
pointer around (if I am parsing things correctly).

Unfortunately, I think that's a bit outside my comfort zone. I don't
know Greenlet, and I don't know SH4 ASM. For completeness, here is the
SH4 software manual: [2].

If the Greenlet developers decline to port to SH4, then I think the
next step is to remove the Greenlet dependency on SH4. Maybe there's a
configure option in GDB, Boost or Python that can ultimately sidestep
the dependency on SH4. I think the first team to engage is the GDB
team. They may have a suggestion to shed the Boost dependency.

[1] 
https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform
[2] https://www.renesas.com/us/en/document/mas/sh-4-software-manual

Bug#992981: autoconf: AC_CHECK_LIB no longer works with g++

[Vincent Lefevre]

Control: tags -1 fixed-upstream

On 2021-08-26 01:53:06 +0200, Vincent Lefevre wrote:
> Control: forwarded -1 https://savannah.gnu.org/support/index.php?110532
> 
> On 2021-08-26 00:54:02 +0200, Vincent Lefevre wrote:
> > Patch attached. I tested it and solves the failure with GNU MPFR.
> 
> I've reported the bug upstream and submitted the patch, as the issue
> is reproducible from the git repository.

And this was fixed upstream on 2021-08-31.

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

Bug#1025256: ITP: crowdsec-firewall-bouncer -- CrowdSec bouncer for firewalls

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: crowdsec-firewall-bouncer
  Version : 0.0.25~rc2-1
  Upstream Author : crowdsec
* URL : https://github.com/crowdsecurity/cs-firewall-bouncer
* License : Expat
  Programming Lang: Go
  Description : CrowdSec bouncer for firewalls

 This package uses the CrowdSec API to implement decisions at the firewall
 level via blocklists. It supports both nftables and iptables+ipset (IPv4
 and IPv6).


Cheers,   
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1025131: apt-cacher-cleanup does not work

[Mark Hindley]

Control: tags -1 pending

Robert,

Many thanks for correcting my typo and testing.

Uploading later today.

Mark

Bug#1025255: ITP: crowdsec-custom-bouncer -- CrowdSec bouncer for custom scripts

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: crowdsec-custom-bouncer
  Version : 0.0.13-1
  Upstream Author : crowdsec
* URL : https://github.com/crowdsecurity/cs-custom-bouncer
* License : Expat
  Programming Lang: Go
  Description : CrowdSec bouncer for custom scripts

 This package uses the CrowdSec API to fetch the latest decisions
 periodically, and passes them as arguments to a custom user script.


Cheers,   
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1025254: ITP: golang-github-google-nftables -- Go library to interact with Linux nftables

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-google-nftables
  Version : 0.0~git20221107.130caa4-1
  Upstream Author : Google
* URL : https://github.com/google/nftables
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library to interact with Linux nftables

 This package is a third-party Go package to interact with nftables
 programmatically. It is implemented in pure Go, meaning it does not
 wrap the libnftnl library.
 .
 It is neither an official netfilter project nor an official Google
 product.

This is a dependency for the upcoming crowdsec-firewall-bouncer
package. I've asked upstream to publish a release to avoid the
ugly snapshot-based version number.


Cheers,   
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1025253: ITP: golang-github-crowdsecurity-go-cs-bouncer -- Go library to create CrowdSec bouncers

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-crowdsecurity-go-cs-bouncer
  Version : 0.0.1-1
  Upstream Author : crowdsec
* URL : https://github.com/crowdsecurity/go-cs-bouncer
* License : Expat
  Programming Lang: Go
  Description : Go library to create CrowdSec bouncers

 CrowdSec is a lightweight security engine, able to detect and remedy
 aggressive network behavior. This package makes it possible to build
 bouncers, which are the components responsible for acting upon a
 decision taken by the engine.

This is a dependency of the upcoming crowdsec-firewall-bouncer and
crowdsec-custom-bouncer packages.


Cheers,   
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#925591: Workaround

[Yvan Masson]

Hi,

It is probably not the best solution, but the UEFI page of the Debian 
wiki [1] proposes a workaround: a grub hook to duplicate the ESP mounted 
on /boot/efi to ESP(s) on other drives. Note that I have not tested it.


1. https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition

Regards,
Yvan


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021150: cryptsetup: please upload to bullseye-backports

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Fri, 7 Oct 2022 at 15:31, Luca Boccassi  wrote:
>
> On Fri, 7 Oct 2022 at 13:47, Guilhem Moulin  wrote:
> >
> > Hi,
> >
> > On Sun, 02 Oct 2022 at 20:40:36 +0100, Luca Boccassi wrote:
> > > Could you please consider an upload of the latest cryptsetup to
> > > bullseye-backports?
> >
> > Bookworm/sid's cryptsetup-initramfs conflicts with Bullseye's lvm2.
> > Could you please upload lvm2 to bullseye-backports, or ask the maintainer
> > to do it?  I don't have the bandwidth for this, but will take care of
> > the cryptsetup upload afterwards.
>
> Thanks for checking, I'll add it to the to-do list and come back once
> it's sorted.

The lvm2 maintainer does not wish to maintain a backport, so this
cannot happen. Closing.

Kind regards,
Luca Boccassi

Bug#1025229: mksh: flaky autopkgtest on several architectures

[Thorsten Glaser]

Hi Paul,

> I looked at the results of the autopkgtest of your package. I noticed that it
> regularly fails. Also the failures on arm64 seem consistent now in testing 
> (but
> it has a pass in unstable).

thanks for bringing this to my attention. This is a bug in the
autopkgtest script in that it doesn’t take those tests whose
failure should be ignored into account, combined with these
tests failing much more than they used to on build infrastructure
(for which I *still* have not been able to find the underlying
reason).

I’ll fix the scripts (and the repro-builds issue) and upload RSN,
to ignore the allowed failures.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1006129: weresync: Needs additional dependency to run

[Ileana Dumitrescu]

Misread the patch initially as a build-depends, I'll go ahead and incorporate 
to make sure distutils exists at run time. Thank you!

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

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

Bug#1006129: weresync: Needs additional dependency to run

[Ileana Dumitrescu]

Hi,

I am currently unable to reproduce this bug. weresync build-depends on 
python3-sphinx (which build-depends on python3-distutils), so it is no longer 
necessary to add this build-dependency to weresync. I confirmed that python3-
distutils is installed when building weresync 1.0.9-2 in pbuilder. So I am 
closing this bug, but please reach out if it remains an issue.

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

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

Bug#1006996: Bug #1006996: mate-polkit: On arm64 architecture mate-polkit tries to open an amd64 file and fails

[Simon McVittie]

Forwarding this from -devel since I'm not sure whether you saw it there.

- Forwarded message from Simon McVittie  -

Date: Sat, 19 Nov 2022 11:44:34 +
From: Simon McVittie 
To: debian-de...@lists.debian.org
Subject: Re: Bug #1006996: mate-polkit: On arm64 architecture mate-polkit tries 
to open an amd64 file and fails
Message-ID: 

On Fri, 18 Nov 2022 at 22:23:05 +, Mike Gabriel wrote:
> The flaw in mate-polkit is that the
> /etc/xdg/autostart/.desktop file so far has been shipped in
> mate-polkit-common (which usually got built on amd64 builders) and that that
> .desktop file contains a multi-arch path in the Exec= key.

Probably a silly question, but could you build mate-polkit with
--libdir=/usr/libexec instead of /usr/lib/x86_64-linux-gnu/polkit-mate,
so that the polkit auth agent is at a location that does not vary between
architectures?

mate-polkit is currently Multi-Arch: same, but that seems wrong to me:
on a dual-architecture amd64/i386 system (or arm64/armhf or any other
combination), there is no point in running more than one architecture's
copy of the MATE polkit authentication agent. They'll all have the same
UI and the same behaviour, so any single architecture is enough. This
seems like a textbook case of a Multi-Arch: foreign package.

(On amd64 it would maybe be nice to leave behind a symlink
/usr/lib/x86_64-linux-gnu/polkit-mate/polkit-mate-authentication-agent-1 ->
/usr/libexec/polkit-mate-authentication-agent-1 so that if a sysadmin has
edited the conffile and therefore doesn't receive the new version, then
the agent will still start. But that's an optional quality-of-implementation
thing.)

Another possible solution to this would be to not install an XDG
autostart file into /etc at all, and instead do one or more of these:

1. teach MATE to read additional autostart files from a location below
   /usr as a lower priority than XDG_CONFIG_DIRS, for instance if it
   is currently reading
   [g_get_user_config_dir() + "/autostart",
x + "/autostart" for x in g_get_system_config_dirs().split(":")]
   then that could be changed to
   [g_get_user_config_dir() + "/autostart",
x + "/autostart" for x in g_get_system_config_dirs().split(":"),
"/usr/share/mate/autostart"]
2. launch this polkit agent programmatically in MATE code (perhaps via
   D-Bus activation) instead of relying on XDG autostart as a way to
   discover it
3. integrate it into the desktop shell so it doesn't need to be launched
   separately at all

People who have been thinking about image-based OSs are already trying to
move the community towards a model where the "factory-installed" state
of /etc is empty, and every file in /etc represents a local divergence
from that original state (sysadmin configuration). I think that's a
good goal in general: /etc has traditionally been a mixture of sysadmin
configuration (/etc/fstab, /etc/hostname) and system-integration glue
(/etc/ld.so.conf.d, /etc/xdg/autostart), and if we separated those two,
it would become a lot more obvious what is sysadmin configuration and
what is part of the OS.

Solving the problem of "the design of /etc/xdg/autostart conflicts with
wanting a factory install to have an empty /etc" *in general* is hard
because it's an interoperability point between multiple desktop environments
(e.g. people don't want to break /etc/xdg/aa-notify.desktop), so changing
it in an interoperable/consistent way requires changing the spec and every
implementation. For instance some people are advocating changing the
autostart spec so that implementations will read
/usr/etc/xdg/autostart/*.desktop or /usr/etc/autostart/*.desktop or
/usr/share/xdg/autostart/*.desktop or some standardized path like that.
AIUI there's currently no real consensus on specific paths.

However, solving it for a component that has OnlyShowIn=MATE is easy,
because by design only MATE is going to launch that component anyway -
so it's entirely reasonable for it to rely on implementation-specific
MATE behaviours. For instance, if MATE developers decided that they are
going to read /usr/share/mate/autostart as an additional search path
component of lower priority than $XDG_CONFIG_DIRS/autostart, then that
wouldn't harm interoperability with other desktops and is something
that MATE can do unilaterally.

Alternatively, integrating the polkit agent into the desktop shell is
what GNOME does: GNOME's polkit agent is part of GNOME Shell, which
has some other advantages, such as the compositor (which is also Shell)
being able to give it special handling around input-grabbing to protect
the secure input path.

If you evaluate those options and decide that you still need
conffile handling for /etc/xdg/autostart/*.desktop here:

> To simplify life (and yes, this is debatable): Do situations exist, where an
> enforced conffile update (overwriting it) is allowed / justifiable?

The Policy requirement is not "don't overwrite conffiles", the Policy
requirement is "don't revert sysadmin changes". 

Bug#912485: childsplay: Please migrate to python3-pygame

[Markus Koschany]

Am Donnerstag, dem 01.12.2022 um 14:31 +0100 schrieb Bastian Germann:
> On Tue, 20 Oct 2020 21:19:16 +0200 Markus Koschany  wrote:
> > I have started to port childsplay to python3. There are no estimates
> > when it's done but I hope I can finish the work before we freeze.
> 
> Will you make it to the bookworm freeze? If not, please consider removing the
> package.

Probably not because there are other issue I have to attend to first. I don't
intend to remove the game, just to introduce it later again.


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

Bug#912485: childsplay: Please migrate to python3-pygame

[Bastian Germann]

On Tue, 20 Oct 2020 21:19:16 +0200 Markus Koschany  wrote:

I have started to port childsplay to python3. There are no estimates
when it's done but I hope I can finish the work before we freeze.


Will you make it to the bookworm freeze? If not, please consider removing the 
package.

Bug#1025251: libunibreak: uses deprecated debhelper compat level 7

[Simon McVittie]

Source: libunibreak
Version: 1.1-2
Severity: wishlist

This package uses deprecated debhelper compat level 7. The recommended
compat level as of 2022 is 13, and compat levels less than 10 are
deprecated. Please see debhelper-compat-upgrade-checklist(7) for details.
debhelper periodically ends support for old compat levels, so this bug is
likely to become release-critical after Debian 12 is released.

If backports are desired, packages using compat level 13 are
straightforward to backport to Debian 11 or even Debian 10, so there is
usually no reason to use a compat level older than the recommended one.

I have not attempted to raise the debhelper compat level while resolving
#1025246 because it is normally a more appropriate change to be made by
the maintainer, similar to #1007428.

smcv

Bug#1025250: xyz: Fix FTBFS without mercantile

[Bas Couwenberg]

Source: xyzservices
Version: 2022.9.0-1
Severity: important
Tags: ftbfs patch
Control: block 1025244 by -1

Dear Maintainer,

The mercantile package is unmaintained and is going to be removed (#1025244).

You package needs the attached patch to not FTBFS without mercantile.

Please apply the patch before the bookworm freeze (or adopt the mercantile 
package).

Kind Regards,

Bas
diff -Nru xyzservices-2022.9.0/debian/changelog 
xyzservices-2022.9.0/debian/changelog
--- xyzservices-2022.9.0/debian/changelog   2022-10-25 17:04:47.0 
+0200
+++ xyzservices-2022.9.0/debian/changelog   2022-12-01 13:50:57.0 
+0100
@@ -1,3 +1,10 @@
+xyzservices (2022.9.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to skip tests when mercantile is not available.
+
+ -- Bas Couwenberg   Thu, 01 Dec 2022 13:50:57 +0100
+
 xyzservices (2022.9.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru xyzservices-2022.9.0/debian/control 
xyzservices-2022.9.0/debian/control
--- xyzservices-2022.9.0/debian/control 2022-07-26 09:07:29.0 +0200
+++ xyzservices-2022.9.0/debian/control 2022-12-01 13:42:48.0 +0100
@@ -6,7 +6,6 @@
 Build-Depends: debhelper-compat (= 13),
dh-sequence-python3,
python3-all,
-   python3-mercantile,
python3-pytest ,
python3-requests,
python3-setuptools
diff -Nru xyzservices-2022.9.0/debian/patches/mercantile.patch 
xyzservices-2022.9.0/debian/patches/mercantile.patch
--- xyzservices-2022.9.0/debian/patches/mercantile.patch1970-01-01 
01:00:00.0 +0100
+++ xyzservices-2022.9.0/debian/patches/mercantile.patch2022-12-01 
13:50:47.0 +0100
@@ -0,0 +1,15 @@
+Description: Skip tests when mercantile is not available.
+Author: Bas Couwenberg 
+Forwarded: not-needed
+
+--- a/xyzservices/tests/test_providers.py
 b/xyzservices/tests/test_providers.py
+@@ -3,7 +3,7 @@ import os
+ import pytest
+ import xyzservices.providers as xyz
+ import requests
+-import mercantile
++pytest.importorskip("mercantile")
+ 
+ flat_free = xyz.filter(requires_token=False).flatten()
+ 
diff -Nru xyzservices-2022.9.0/debian/patches/series 
xyzservices-2022.9.0/debian/patches/series
--- xyzservices-2022.9.0/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ xyzservices-2022.9.0/debian/patches/series  2022-12-01 13:44:32.0 
+0100
@@ -0,0 +1 @@
+mercantile.patch
diff -Nru xyzservices-2022.9.0/debian/tests/control 
xyzservices-2022.9.0/debian/tests/control
--- xyzservices-2022.9.0/debian/tests/control   2022-06-28 19:34:40.0 
+0200
+++ xyzservices-2022.9.0/debian/tests/control   2022-12-01 13:43:05.0 
+0100
@@ -1,2 +1,2 @@
 Tests: run-tests
-Depends: python3-all, python3-mercantile, python3-pytest, python3-requests, @
+Depends: python3-all, python3-pytest, python3-requests, @

Bug#1025249: wtdbg2: flaky autopkgtest: Segmentation fault

[Paul Gevers]

Source: wtdbg2
Version: 2.5-7
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package because it 
was blocking glibc. I noticed that it regularly fails (particularly on 
ppc64el, but not exclusively there).


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/data/autopkgtest/stable/ppc64el/w/wtdbg2/28644876/log.gz

[Sat Nov 26 06:40:02 2022] masked 154 repeat-like nodes by local 
subgraph analysis

[Sat Nov 26 06:40:02 2022] generating edges
/tmp/autopkgtest-lxc.t8xpx53w/downtmp/build.dY0/src/debian/tests/run-unit-test: 
line 23:  1447 Segmentation fault  wtdbg2 -x rs -g 4.6m -i 
pacbio_filtered.fastq -t 16 -fo dbg



https://ci.debian.net/data/autopkgtest/testing/ppc64el/w/wtdbg2/27771576/log.gz

[Thu Nov  3 00:50:18 2022] sorting regs ...  Done
[Thu Nov  3 00:50:19 2022] generating intervals ... 
/tmp/autopkgtest-lxc.wcfl1vkh/downtmp/build.kT7/src/debian/tests/run-unit-test: 
line 23:  1310 Segmentation fault  wtdbg2 -x rs -g 4.6m -i 
pacbio_filtered.fastq -t 16 -fo dbg



https://ci.debian.net/data/autopkgtest/testing/arm64/w/wtdbg2/26361496/log.gz

[Fri Sep 23 22:33:59 2022] masked 154 repeat-like nodes by local 
subgraph analysis

[Fri Sep 23 22:33:59 2022] generating edges
/tmp/autopkgtest-lxc.7iunliwg/downtmp/build.Yi1/src/debian/tests/run-unit-test: 
line 23:  2686 Segmentation fault  wtdbg2 -x rs -g 4.6m -i 
pacbio_filtered.fastq -t 16 -fo dbg


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024155: Fixed in Git [Re: libngs-c++-dev: missing Breaks+Replaces: libncbi-vdb-dev (<< 3), libngs-sdk-dev (<< 3)]

[Aaron M. Ucko]

Andreas Tille  writes:

> I have fixed this issue in Git.

Thanks!

> I'm wondering about the status of the
> ncbi-vdb transition[1].  Isn't it time to upload the packages to
> unstable now?  Just let me know if you need any help.

I first want to get a better picture of where sra-sdk 3.x stands in
terms of architecture support, which may be clearer with upgrades to
3.0.1 in place.  I've been working on them, but a power outage last
weekend delayed me; I'll try to wrap them up this weekend.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu