Bug#1019524: RFP: golang-freecumextremist-themusicgod1-xhandler-dev

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist

* Package name: golang-freecumextremist-themusicgod1-xhandler-dev
  Version : 0.0
  Upstream Author : Olivier Poitrey 
* URL : https://git.freecumextremist.com/themusicgod1/xhandler/
* License : MIT
  Programming Lang: Go
  Description : XHandler is a bridge between net/context and
http.Handler.

( It has been evacuated from NSA/Microsoft Github )
It lets you enforce net/context in your handlers without sacrificing
compatibility with existing http.Handlers nor imposing a specific router.
Thanks to net/context deadline management, xhandler is able to enforce a
per request deadline and will cancel the context when the client closes the
connection unexpectedly.
You may create your own net/context aware handler pretty much the same way
as you would do with http.Handler.

It is currently a prerequisite for geth ( #890541 )

Bug#1019523: ITP: cosmosocks -- Cosmosocks is a socks4/5 server implementation written in cosmopolitan libc.

[Mike]

Package: wnpp
Severity: wishlist
Owner: Michael Bann 

* Package name: cosmosocks
  Version : 0.4
  Upstream Author : Michael Bann 
* URL : https://github.com/bannsec/cosmosocks
* License : GPL-3.0
  Programming Lang: C
  Description : Cosmosocks is a socks4/5 server implementation written
in cosmopolitan libc.

The purpose of this project is to be a fully portable socks server that
can be run with the same user experience and indeed the same binary
across any major posix compliant system. Due to it's reliance on
cosmopolitan libc, it contains no external dependencies for any platform
it is deployed to.

This project is expected to have minimal changes, so I intend to manage
pushing any needed updates myself. However, since I have not managed a
package before on debian, I believe I will require a sponsor to help me
get this off the ground.

Bug#1019414: prometheus-xmpp-alerts: Datetime format is not the same as what prometheus-alertmanager uses

[Jelmer Vernooij]

Hi Craig,

Thanks for the bug report.

On Fri, Sep 09, 2022 at 08:58:55AM +1000, Craig Small wrote:
> prometheus-xmpp-alerts is expecting its datetime to be in UTC, but that
> is not what the prometheus alertmanager uses.
> 
> This means basically prometheus-xmpp-alerts does not work with
> prometheus-alermanager which is its main use-case.
> 
> I suspect that one or both of the programming teams assumes the servers
> run UTC which is a pretty bad assuption, not sure if it is xmpp-alerts
> fault for hard-coding the timezone or alermanagers fault for not setting
> it. In reality its both.
> 
> In my opinion, the xmpp-alerts should accept both a UTC timezone and a
> different timezone.
> 
> The file in question is 
> /usr/lib/python3/dist-packages/prometheus_xmpp/__init__.py
> with the function parse_timestring
> 
> ts = re.sub('\\.([0-9]{6})([0-9]{0,3})Z$', r'.\1Z', ts)
> return datetime.strptime(ts, '%Y-%m-%dT%H:%M:%S.%fZ')
> 
> The error message is:
> Sep 08 21:26:39 constantine prometheus-xmpp-alerts[2111702]: ValueError: time 
> data '2022-09-08T21:26:09.706263468+10:00' does not match format 
> '%Y-%m-%dT%H:%M:%S.%fZ'
> 
> which is true, "+10:00" doesn't match "Z", but it does match "%z". Also
> %z understands "Z" too. Oddly enough it doesn't understand any other
> sort of timezone, e.g. K is UTC+10h but that's strptime for you.
> 
> You'll also notice that the nanoseconds have not been stripped, again
> because of the assumption of the timezone for the regex.
> 
> So the answer is, do timezones properly.
> 1) Make the regex understand both sorts of timezones
> 2) Use %z because that's what its for.
> 
> The regex is we either get "Z" or +/-hh:mm so the solution on a single
> line is:
> 
> >>> datetime.strptime(re.sub('\\.([0-9]{6})([0-9]{0,3})(Z|[-+][0-9]{1,2}:[0-9]{2})$',
> >>>  r'.\1\3',"2022-09-08T21:26:09.706263468+10:00"), 
> >>> '%Y-%m-%dT%H:%M:%S.%f%z')
> datetime.datetime(2022, 9, 8, 21, 26, 9, 706263, 
> tzinfo=datetime.timezone(datetime.timedelta(seconds=36000)))
> >>> datetime.strptime(re.sub('\\.([0-9]{6})([0-9]{0,3})(Z|[-+][0-9]{1,2}:[0-9]{2})$',
> >>>  r'.\1\3',"2022-09-08T21:26:09.706263468Z"), '%Y-%m-%dT%H:%M:%S.%f%z')
> datetime.datetime(2022, 9, 8, 21, 26, 9, 706263, tzinfo=datetime.timezone.utc)
> >>> datetime.strptime(re.sub('\\.([0-9]{6})([0-9]{0,3})(Z|[-+][0-9]{1,2}:[0-9]{2})$',
> >>>  r'.\1\3',"2022-09-08T21:26:09.706263468-10:00"), 
> >>> '%Y-%m-%dT%H:%M:%S.%f%z')
> datetime.datetime(2022, 9, 8, 21, 26, 9, 706263, 
> tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=50400)))
> 
> I can provide a patch if required.

I believe this is already fixed upstream. See 
https://github.com/jelmer/prometheus-xmpp-alerts/blob/master/prometheus_xmpp/__init__.py#L23

Jelmer

Bug#1019522: gnome-shell-extension-shortcuts: Please update max gnome-shell version

[Jeremy Bicha]

Source: gnome-shell-extension-shortcuts
Version: 1.3.3-1

Please update your maximum gnome-shell dependency to
gnome-shell (<< 44~)

Note the trailing ~

GNOME Shell pre-releases are packaged as for instance 44~beta .
Setting the max to only "44" would allow it to be installed with GNOME
Shell 44~beta but the extension won't work because the extensions's
metadata.json says it's not compatible with 44.

Sorry we weren't more specific with https://bugs.debian.org/1008555

Thank you,
Jeremy Bicha

Bug#1019460: chkrootkit: warning: egrep is obsolescent

[Richard Lewis]

On Fri, 9 Sep 2022 07:24:34 -0500 "Marc F. Clemente"  wrote:
> I upgraded grep from version 3.7-1 to 3.8-1. Something in the readme
> says that "Upstream has made egrep and fgrep obsolecent."
>
> Now chkrootkit spews a bunch of relatively harmless warnings:
>
> egrep: warning: egrep is obsolescent; using grep -E

There is discussion of the egrep messages at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019335 and it looks
like a new grep will be uploaded next week that will stop these
messages appearing, so these will go away. You can also use the
various mechanisms to filter the output to remove the messages. (See
README.Debian and the various links therein)

In the longer term chkrootkit should probably be patched to replace
calls to egrep with 'grep -E' - however, this is slightly more
involved than you might guess given the calls to egrep are indirect
(using $egrep variable, which is itself set from TROJAN variable -
there may be some other issues with how this is done); and ideally
$egrep would continue to honour the '-p' setting after any change.

(Also chkrootkit is considering egrep as potentially a binary that
should be scanned for issues - if TROJAN is changed then there also
needs to be a change to ensure the chk_egrep test is still attempted.
But it also looks a little strange that  chk_grep is looking for a
different thing  to chk_egrep. suggest they should be combined)

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Gunnar Hjalmarsson]

On 2022-08-28 07:21, Yukiharu YABUKI wrote:

I have realized that this issue happended in GDM3 environment.
In LightDM environment, this issue does not happend.


Hmm.. So you have GDM3 installed, which depends on the core GNOME 
packages including gnome-session-common. Maybe that GNOME user service 
systemd file has something to do with it, after all.


Can we do an experiment?

1. Change your ~/.xinput file to "none" using this command:

   im-config -n none

2. Change your default display manager to GDM3.

3. Reboot and log in.

4. Find out if ibus-daemon is still running:

   ps aux | grep ibus

--
Gunnar

Bug#1014290: libgrokj2k: FTBFS with Perl 5.36: macro "utf8_to_utf16" requires 4 arguments, but only 1 given

[gregor herrmann]

On Sat, 10 Sep 2022 13:50:47 +, Aaron Boxer wrote:

> This bug has been fixed in current unstable version of the library.
> Can it be closed ?

Sorry to say but version 10.0.0-1 still fails to build in my perl
5.36 chroot (and builds in unstable with perl 5.34).


make  -f src/lib/codec/CMakeFiles/grokj2kcodec.dir/build.make 
src/lib/codec/CMakeFiles/grokj2kcodec.dir/depend
make[3]: Entering directory '/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu'
cd /build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu && /usr/bin/cmake -E 
cmake_depends "Unix Makefiles" /build/libgrokj2k-10.0.0 
/build/libgrokj2k-10.0.0/src/lib/codec 
/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu 
/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/codec 
/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/codec/CMakeFiles/grokj2kcodec.dir/DependInfo.cmake
 --color=
make[3]: Leaving directory '/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu'
make  -f src/lib/codec/CMakeFiles/grokj2kcodec.dir/build.make 
src/lib/codec/CMakeFiles/grokj2kcodec.dir/build
make[3]: Entering directory '/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu'
[ 85%] Building CXX object 
src/lib/codec/CMakeFiles/grokj2kcodec.dir/grok_codec.cpp.o
[ 85%] Building CXX object 
src/lib/codec/CMakeFiles/grokj2kcodec.dir/image_format/Serializer.cpp.o
[ 85%] Building CXX object 
src/lib/codec/CMakeFiles/grokj2kcodec.dir/image_format/MemManager.cpp.o
[ 85%] Building CXX object 
src/lib/codec/CMakeFiles/grokj2kcodec.dir/common/convert.cpp.o
cd /build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/codec && 
/usr/lib/ccache/c++ -DSPDLOG_COMPILED_LIB -Dgrokj2kcodec_EXPORTS 
-I/build/libgrokj2k-10.0.0/thirdparty/liblcms2/include 
-I/build/libgrokj2k-10.0.0/thirdparty/libtiff 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/thirdparty/libtiff 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/bin 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/core 
-I/build/libgrokj2k-10.0.0/src/lib/core -I/build/libgrokj2k-10.0.0/src/include 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/codec 
-I/build/libgrokj2k-10.0.0/src/lib/codec/image_format 
-I/build/libgrokj2k-10.0.0/src/lib/codec/common 
-I/build/libgrokj2k-10.0.0/src/lib/codec/jp2 
-I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -g -O2 
-ffile-prefix-map=/build/libgrokj2k-10.0.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 
-fvisibility=hidden -fPIC -Wall -Wextra -Wconversion -Wsign-conversion 
-Wunused-parameter -std=gnu++20 -MD -MT 
src/lib/codec/CMakeFiles/grokj2kcodec.dir/common/convert.cpp.o -MF 
CMakeFiles/grokj2kcodec.dir/common/convert.cpp.o.d -o 
CMakeFiles/grokj2kcodec.dir/common/convert.cpp.o -c 
/build/libgrokj2k-10.0.0/src/lib/codec/common/convert.cpp
cd /build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/codec && 
/usr/lib/ccache/c++ -DSPDLOG_COMPILED_LIB -Dgrokj2kcodec_EXPORTS 
-I/build/libgrokj2k-10.0.0/thirdparty/liblcms2/include 
-I/build/libgrokj2k-10.0.0/thirdparty/libtiff 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/thirdparty/libtiff 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/bin 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/core 
-I/build/libgrokj2k-10.0.0/src/lib/core -I/build/libgrokj2k-10.0.0/src/include 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/codec 
-I/build/libgrokj2k-10.0.0/src/lib/codec/image_format 
-I/build/libgrokj2k-10.0.0/src/lib/codec/common 
-I/build/libgrokj2k-10.0.0/src/lib/codec/jp2 
-I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -g -O2 
-ffile-prefix-map=/build/libgrokj2k-10.0.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 
-fvisibility=hidden -fPIC -Wall -Wextra -Wconversion -Wsign-conversion 
-Wunused-parameter -std=gnu++20 -MD -MT 
src/lib/codec/CMakeFiles/grokj2kcodec.dir/image_format/Serializer.cpp.o -MF 
CMakeFiles/grokj2kcodec.dir/image_format/Serializer.cpp.o.d -o 
CMakeFiles/grokj2kcodec.dir/image_format/Serializer.cpp.o -c 
/build/libgrokj2k-10.0.0/src/lib/codec/image_format/Serializer.cpp
cd /build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/codec && 
/usr/lib/ccache/c++ -DSPDLOG_COMPILED_LIB -Dgrokj2kcodec_EXPORTS 
-I/build/libgrokj2k-10.0.0/thirdparty/liblcms2/include 
-I/build/libgrokj2k-10.0.0/thirdparty/libtiff 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/thirdparty/libtiff 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/bin 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/core 
-I/build/libgrokj2k-10.0.0/src/lib/core -I/build/libgrokj2k-10.0.0/src/include 
-I/build/libgrokj2k-10.0.0/obj-x86_64-linux-gnu/src/lib/codec 
-I/build/libgrokj2k-10.0.0/src/lib/codec/image_format 
-I/build/libgrokj2k-10.0.0/src/lib/codec/common 
-I/build/libgrokj2k-10.0.0/src/lib/codec/jp2 
-I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -g -O2 
-ffile-prefix-map=/build/libgrokj2k-10.0.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 

Bug#1019519: opencv: downloads blobs from Github during build

[Victor Westerhuis]

Source: opencv
Version: 4.6.0+dfsg-6
Severity: serious
Tags: patch
Justification: Policy 4.9

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

During the build process, OpenCV module wechat_qrcode downloads four blobs from 
Github:
- -- wechat_qrcode: Downloading detect.caffemodel from 
https://raw.githubusercontent.com/WeChatCV/opencv_3rdparty/a8b69ccc738421293254aec5ddb38bd523503252/detect.caffemodel
- -- wechat_qrcode: Downloading detect.prototxt from 
https://raw.githubusercontent.com/WeChatCV/opencv_3rdparty/a8b69ccc738421293254aec5ddb38bd523503252/detect.prototxt
- -- wechat_qrcode: Downloading sr.caffemodel from 
https://raw.githubusercontent.com/WeChatCV/opencv_3rdparty/a8b69ccc738421293254aec5ddb38bd523503252/sr.caffemodel
- -- wechat_qrcode: Downloading sr.prototxt from 
https://raw.githubusercontent.com/WeChatCV/opencv_3rdparty/a8b69ccc738421293254aec5ddb38bd523503252/sr.prototxt

"For packages in the main archive, required targets must not attempt network 
access [...]", according to Debian Policy 4.9.

I have prepared a patch in a fork of the Salsa repository and have started a 
merge request.

Regards,


Victor Westerhuis


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US:en:nl_NL:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmMdENITHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+8tJD/9opFU7fVCyUbMDSqmdWzN8zqaOGw/3
8FzeLW07m8/UrjIIvULXkNqSUCgPfyKNQ0ZFp8dEaVrUCLAZSPdTq27I+r+7I9BT
QFF5B3kV0WzJmxw6u96DoYtNZQGEHLjL5ugJd+jYOTuEOwkfApTvS5CvMSI5Uuol
hdw+KP0z0fNBPKB8J5lgkh1Dth1iqYQTveHuUxhf4nv6ANdTnJCmRwgyWisQpdhf
d11NxpNqm4GM9TrVMG5cT/wBhriZ9PIRgswmVpq2adGCE+Pe1Qgit7VnXl2g1hU8
Nm2B4Yefq80IhSbNBpgg9LSXr+NaNY0YppUqlLZFPv7AJAyGpnJvmLmjOC9AFuTr
PirsyOyO3nE+caMfJp8zZGPNjRwvGEXnuL+YOjjdoz2+rCas0Jb5c/bujHeN6hYT
mt/3w7keXJikKxrmMJibXIz7gRy6Oyu1ZoGXXOkMgZezUi1s1/AUJwM7QOalpO+H
5s+btTZ8tZu7I8O748plYkekFd6UFRBnrV0xXNADpEX6jgsqcLCM+XN88z4jgidF
jnIJePmz6ffJE9kjQs5illj/FtkRdSWsRabn1+0nU+RVrj9gUYgmT8dC0Cfanyrp
eOQNyKK1qBcn2x3Vvfzocr0dUW1KDM+bcOCBMc/JCPlFxYeeMR/X8KCYvNzLFVGI
lIc2JzYOkoIAEA==
=fzKE
-END PGP SIGNATURE-

Bug#1019518: ITP: gitsign -- keyless git signing using sigstore

[Leo Antunes]

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

* Package name: gitsign
  Version : 0.3.0
  Upstream Author : The Sigstore Authors 
* URL : https://sigstore.dev
* License : Apache 2.0
  Programming Lang: go
  Description : keyless git signing using sigstore

Tool for keyless signing of git commits based on sigstore.

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Steve Langasek (2022-09-10 22:16:55)
> > > > For the record I do not consider this an override requiring a
> > > > supermajority and would abide by a majority TC decision.
> 
> > > Thank you for your input.  The TC can just issue advice after reviewing
> > > the proposed changes, in this case.  An alternative would be to word the
> > > resolution such that it counts as advice if we have a simple majority
> > > and an override if we have a supermajority.  I'd prefer the former, but
> > > it would be good to hear from Helmut about it.
> 
> > AIUI, Steve's objection is substantially that this is quite an invasive
> > change to make across our toolchain, and should be discussed on debian-devel
> > before just being implemented package-by-package (rather than any particular
> > objection to the approach). Is that correct?
> 
> I think that's a fair characterization, yes.
> 
> I support the goal of making it easier to bootstrap ports.  I also don't
> even see a cleaner way to accomplish this than what's proposed.  But I think
> there's a duty, when making distro-level changes, to have a project-level
> discussion about what's being proposed and why, and to get consensus on it,
> not just file a bunch of bug reports on individual packages.

I think there's a duty, when maintaining a package, to at least send a short
reply to bugs against your package and even more so, if pinged multiple times
and your co-maintainer explicitly waiting for you and thus this non-action
resulting in blocking other people's work. We invoked the TC not because we did
not want to discuss on d-devel but because you have kept silent since February
2021 when we filed our initial bug #983427 against pam.  In hindsight, we
should've written to d-devel, yes.  Helmut and myself are working on a mail to
send to d-devel to get this done now in the sense of "better late than never".
We didn't think that such a mail was necessary because there are only 10 source
packages (including pam) that require the DPKG_ROOT variable in their
maintainer script for this mechanism to work (that's why I wouldn't classify
this as "distro-level change") and because the required changes to maintainer
scripts result in zero behaviour changes on anything that is not
early-bootstrap.

>From my side, I'd be fine with the TC pausing any action on this issue and
waiting for our mail to d-devel first. This is assuming that if there is no
opposition to the DPKG_ROOT idea, that Steve then also has no objection against
merging our patch.

Helmut, what do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1019516: xscreensaver: New version available upstream

[Jamie Zawinski]

Please make sure you grab xscreensaver-6.05.1.tar.gz if you already grabbed the 
other one; there was a last minute fix.

Bug#1019510: systemd-sysv: annoying beep during shutdown or reboot

[Michael Biebl]

Control: tags -1 + moreinfo

Am 10.09.2022 um 21:57 schrieb Christian Danneberg:

on every reboot or shutdown my Laptop beeps very loud (Dell E6230). This
behaviour came up after the installation of Bookworm.
I tried all stuff I found. Blacklisting of pcspkr kernel module, on my system I
can't find a module like pcspkr or similar. Tried to find the   hex code 0x07
in the binary of /sbin/shutdown. As suggested in forum.debian.de.

All that had no effect.


Do you get a beep if you run
systemctl reboot --no-wall ?

It's possibly related to 
https://github.com/systemd/systemd/commit/cdf370626f08ed509a5dde9d5618eed29d625032


In that case, wall messages do trigger a beep on your system.
If you don't want that, you can blacklist pcspkr.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019392: toybox: autopkgtest regression on ppc64el: exited with signal (or returned 255)

[Paul Gevers]

Hi,

On 10-09-2022 04:23, Antoni Villalonga wrote:

Hi Paul,

Thanks for reporting the issue.

I've tested the package on a virtual ppc64el Debian/Sid fresh installation.

Testing the coreutils seq takes around 0.8 seconds:
  $ echo -ne '' | timeout 10 seq 1000 > /dev/null

Testing the toybox seq takes around 1.4 seconds:
  $ echo -ne '' | timeout 10 toybox seq 1000 > /dev/null

In that case, Coreutils seems to perform twice faster than Toybox. In any case
both have taken lot less than 10 seconds specified for the test.


And in an unstable container on one of our ppc64el host:
root@elbrus:/# time echo -ne '' | timeout 10 seq 1000 > /dev/null

real0m0.183s
user0m0.177s
sys 0m0.007s
root@elbrus:/# time echo -ne '' | timeout 10 toybox seq 1000 > /dev/null

real0m0.426s
user0m0.411s
sys 0m0.012s

Are you sure it's this commmand that times out in the test?


After looking at your qa profile I've noticed you are the autopkgtest
maintainer. May be you can give me some hints on how to reproduce the issue or
how long it takes on "autopkgtest boxes" to adapt the "timeout" :)


As noted above, I can not reproduce the issue with the stand alone 
command you provided, while in the autopkgtest context, you test failed 
already 18 times, so it's not a coincidence.



If it's not possible, I'll try to contact with ppc64el debian team for help.


I think we first need to be able to reproduce.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019515: gemmi: autopkgtest regression on arm64 i386 s390x and ppc64el: numerical deltas

[Paul Gevers]

Source: gemmi
Version: 0.5.6+ds-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
gemmi  from testing0.5.6+ds-2
all others from testingfrom testing

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

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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/arm64/g/gemmi/25899714/log.gz

=== FAILURES 
===
__ TestProg.test_sfcalc_1pfe 
___


self = 

@unittest.skipIf(sys.platform == 'win32', 'with MSVC it differs 
slightly')

def test_sfcalc_1pfe(self):

  self.do('''\
$ gemmi sfcalc --dmin=9 --rate=4 --blur=60 --rcut=1e-7 --test -v 
tests/1pfe.cif.gz

[...]
RMSE=0.0010414  0.0001639%  max|dF|=0.003530  R=0.000% 
=8.067e-06

''')  # noqa: E501

tests/test_prog.py:89: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tests/test_prog.py:36: in do

self.assertEqual(expected_lines, output_lines)
E   AssertionError: Lists differ: ['RMSE=0.0010414  0.0001639% 
max|dF|=0.003530  R=0.000%  =8.067e-06'] != ['RMSE=0.0010127 
0.0001594%  max|dF|=0.003041  R=0.000%  =7.880e-06']

E   E   First differing element 0:
E   'RMSE=0.0010414  0.0001639%  max|dF|=0.003530  R=0.000% 
=8.067e-06'
E   'RMSE=0.0010127  0.0001594%  max|dF|=0.003041  R=0.000% 
=7.880e-06'
E   E   - ['RMSE=0.0010414  0.0001639%  max|dF|=0.003530  R=0.000% 
=8.067e-06']

E   ?  - ^^^ -- ^ --
E   E   + ['RMSE=0.0010127  0.0001594%  max|dF|=0.003041  R=0.000% 
=7.880e-06']

E   ?   ^^^ + ++   ++ ^
__ TestProg.test_sfcalc_5wkd 
___


self = 

@unittest.skipIf(sys.platform == 'win32', 'with MSVC it differs 
slightly')

def test_sfcalc_5wkd(self):

  self.do('''\
$ gemmi sfcalc --blur=12 --dmin=2.5 --rate=2.5 --rcut=1e-7 --test 
-v tests/5wkd.pdb

[...]
RMSE=3.3342e-05  4.703e-05%  max|dF|=0.0001706  R=0.000% 
=4.718e-06

''')  # noqa: E501

tests/test_prog.py:81: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tests/test_prog.py:36: in do

self.assertEqual(expected_lines, output_lines)
E   AssertionError: Lists differ: ['RMSE=3.3342e-05  4.703e-05% 
max|dF|=0.0001706  R=0.000%  =4.718e-06'] != ['RMSE=3.2830e-05 
4.630e-05%  max|dF|=0.0001628  R=0.000%  =4.665e-06']

E   E   First differing element 0:
E   'RMSE=3.3342e-05  4.703e-05%  max|dF|=0.0001706  R=0.000% 
=4.718e-06'
E   'RMSE=3.2830e-05  4.630e-05%  max|dF|=0.0001628  R=0.000% 
=4.665e-06'
E   E   - ['RMSE=3.3342e-05  4.703e-05%  max|dF|=0.0001706  R=0.000% 
=4.718e-06']
E   ?   ^^^^ - -- 
  ^^^
E   E   + ['RMSE=3.2830e-05  4.630e-05%  max|dF|=0.0001628  R=0.000% 
=4.665e-06']
E   ?  ++ ^^^   ++ 
  ^^^
=== short test summary info 

FAILED tests/test_prog.py::TestProg::test_sfcalc_1pfe - AssertionError: 
Lists...
FAILED tests/test_prog.py::TestProg::test_sfcalc_5wkd - AssertionError: 
Lists...
 2 failed, 169 passed in 1.42s 
=

autopkgtest [17:13:32]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019514: node-jquery breaks r-cran-plumber autopkgtest: compared text different

[Paul Gevers]

Source: node-jquery, r-cran-plumber
Control: found -1 node-jquery/3.6.1+dfsg+~3.5.14-1
Control: found -1 r-cran-plumber/1.2.0+ds-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of node-jquery the autopkgtest of r-cran-plumber 
fails in testing when that autopkgtest is run with the binary packages 
of node-jquery from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
node-jqueryfrom testing3.6.1+dfsg+~3.5.14-1
r-cran-plumber from testing1.2.0+ds-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of node-jquery to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-plumber/25895524/log.gz

dpkg-architecture: warning: cannot determine CC system type, falling 
back to default (native compilation)

BEGIN TEST spelling.R

R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


if(requireNamespace('spelling', quietly = TRUE))

+   spelling::spell_check_test(vignettes = TRUE, error = FALSE,
+  skip_on_cran = TRUE)
NULL



BEGIN TEST testthat.R

R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


library(testthat)
library(plumber)

test_check("plumber")
/usr/lib/R/site-library/jquerylib/lib/3.6.1>

[ FAIL 1 | WARN 0 | SKIP 23 | PASS 1895 ]

== Skipped tests 
===

* On CRAN (15)
* arrow cannot be loaded (5)
* geojsonsf cannot be loaded (3)

== Failed tests 

-- Error (test--include.R:25:5): Includes work 
-
Error in `expect_match(val$body, "R 
Output.*\\s*$")`: is.character(act$val) is not TRUE

Backtrace:
x
 1. \-testthat::expect_match(val$body, "R 
Output.*\\s*$") at test--include.R:25:4

 2.   \-base::stopifnot(is.character(act$val))

[ FAIL 1 | WARN 0 | SKIP 23 | PASS 1895 ]
Error: Test failures
Execution halted
autopkgtest [04:14:56]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019513: node-jquery breaks r-cran-pkgdown autopkgtest: replacement has 11 rows, data has 10

[Paul Gevers]

Source: node-jquery, r-cran-pkgdown
Control: found -1 node-jquery/3.6.1+dfsg+~3.5.14-1
Control: found -1 r-cran-pkgdown/2.0.6-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of node-jquery the autopkgtest of r-cran-pkgdown 
fails in testing when that autopkgtest is run with the binary packages 
of node-jquery from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
node-jqueryfrom testing3.6.1+dfsg+~3.5.14-1
r-cran-pkgdown from testing2.0.6-2
all others from testingfrom testing

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

Currently this regression is blocking the migration of node-jquery to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-pkgdown/25895523/log.gz

BEGIN TEST testthat.R

R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


library(testthat)
library(pkgdown)

test_check("pkgdown")

[ FAIL 8 | WARN 0 | SKIP 86 | PASS 514 ]

══ Skipped tests 
═══

• dir_exists(path)[[1]] is not TRUE (1)
• dir_exists(test_path("assets/site-dot-github/.github")) is not TRUE (2)
• empty test (1)
• On CRAN (78)
• rmarkdown::pandoc_available(version) is not TRUE (4)

══ Failed tests 

Error in `$<-.data.frame`(`*tmp*`, "call_text", value = 
c("pkgdown::build_articles(pkg)",  :   replacement has 11 rows, data has 10

Calls: test_check ... trace_format -> trace_as_tree -> $<- -> $<-.data.frame
Execution halted
autopkgtest [04:15:09]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019497: O: watchman -- file watching service

[Eriberto Mota]

Hello again,

After taking a look over the current source code in GitHub, I noticed
that it is a nightmare (for me).

1. The most complicated for me: there are 5 embedded libraries (in
watchman/thirdparty/). This is a very bad thing because these
libraries are old and vulnerable.

2. The program has source code based in 5 different languages (C++,
Python, Rust, Java and Thrift).

3. There are several relevant issues opened (including a question
about FTBFS in Ubuntu 22.04).

I lost interest in adopting this package. Thanks for your previous work.

Cheers,

Eriberto

Bug#1019512: r-cran-jquerylib: autopkgtest needs update for new version of node-jquery: Mismatch between compiled version 3.6.0 and current version 3.6.1

[Paul Gevers]

Source: r-cran-jquerylib
Version: 0.1.4+dfsg-3
Severity: serious
X-Debbugs-CC: node-jqu...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:node-jquery

Dear maintainer(s),

With a recent upload of node-jquery the autopkgtest of r-cran-jquerylib 
fails in testing when that autopkgtest is run with the binary packages 
of node-jquery from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
node-jqueryfrom testing3.6.1+dfsg+~3.5.14-1
r-cran-jquerylib   from testing0.1.4+dfsg-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. The text 
suggest you actually want something smarter than just testing that the 
version remains the same. If your package *needs* that, you should 
document that in the package Depends, such that tools can pick it up, 
but somehow I feel the test is way too strict.


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


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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-jquerylib/25892083/log.gz

Mismatch between compiled version 3.6.0 and current version 3.6.1
autopkgtest [03:15:29]: test check-compiled-versions



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019511: scipy breaks scikit-learn autopkgtest on ppc64el: precision delta's

[Paul Gevers]

Source: scipy, scikit-learn
Control: found -1 scipy/1.8.1-14
Control: found -1 scikit-learn/1.1.2+dfsg-5
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
scipy  from testing1.8.1-14
scikit-learn   from testing1.1.2+dfsg-5
all others from testingfrom testing

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

Currently this regression is blocking the migration of scipy to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/scikit-learn/25863055/log.gz

=== FAILURES 
===
__ test_mlp_regressor_dtypes_casting 
___


def test_mlp_regressor_dtypes_casting():
mlp_64 = MLPRegressor(
alpha=1e-5, hidden_layer_sizes=(5, 3), random_state=1, 
max_iter=50

)
mlp_64.fit(X_digits[:300], y_digits[:300])
pred_64 = mlp_64.predict(X_digits[300:])
mlp_32 = MLPRegressor(
alpha=1e-5, hidden_layer_sizes=(5, 3), random_state=1, 
max_iter=50

)
mlp_32.fit(X_digits[:300].astype(np.float32), y_digits[:300])
pred_32 = mlp_32.predict(X_digits[300:].astype(np.float32))
>   assert_allclose(pred_64, pred_32, rtol=1e-04)
E   AssertionError: E   Not equal to tolerance rtol=0.0001, atol=0
E   E   Mismatched elements: 1 / 60 (1.67%)
E   Max absolute difference: 1.77346709e-06
E   Max relative difference: 0.0001
Ex: array([-1.624248e-02,  2.327707e+00,  6.674963e-01, 
4.904700e-01,

E   6.739288e-01,  3.166697e+00,  4.548126e-01,  6.674963e-01,
E  -3.220949e-02, -6.899952e-01,  6.674963e-01, 
-6.329127e-01,...
Ey: array([-1.624250e-02,  2.327706e+00,  6.674960e-01, 
4.904711e-01,

E   6.739284e-01,  3.166698e+00,  4.548138e-01,  6.674960e-01,
E  -3.220773e-02, -6.899955e-01,  6.674960e-01, 
-6.329128e-01,...


/usr/lib/python3/dist-packages/sklearn/neural_network/tests/test_mlp.py:872: 
AssertionError


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Steve Langasek]

On Sat, Sep 10, 2022 at 05:36:13PM +0100, Matthew Vernon wrote:
> On 09/09/2022 19:45, Sean Whitton wrote:
> > Hello,

> > On Thu 08 Sep 2022 at 10:09PM -07, Steve Langasek wrote:

> > > For the record I do not consider this an override requiring a
> > > supermajority and would abide by a majority TC decision.

> > Thank you for your input.  The TC can just issue advice after reviewing
> > the proposed changes, in this case.  An alternative would be to word the
> > resolution such that it counts as advice if we have a simple majority
> > and an override if we have a supermajority.  I'd prefer the former, but
> > it would be good to hear from Helmut about it.

> AIUI, Steve's objection is substantially that this is quite an invasive
> change to make across our toolchain, and should be discussed on debian-devel
> before just being implemented package-by-package (rather than any particular
> objection to the approach). Is that correct?

I think that's a fair characterization, yes.

I support the goal of making it easier to bootstrap ports.  I also don't
even see a cleaner way to accomplish this than what's proposed.  But I think
there's a duty, when making distro-level changes, to have a project-level
discussion about what's being proposed and why, and to get consensus on it,
not just file a bunch of bug reports on individual packages.

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


signature.asc
Description: PGP signature

Bug#1019510: systemd-sysv: annoying beep during shutdown or reboot

[Christian Danneberg]

Package: systemd-sysv
Version: 251.4-3
Severity: normal

Dear Maintainer,

on every reboot or shutdown my Laptop beeps very loud (Dell E6230). This
behaviour came up after the installation of Bookworm.
I tried all stuff I found. Blacklisting of pcspkr kernel module, on my system I
can't find a module like pcspkr or similar. Tried to find the   hex code 0x07
in the binary of /sbin/shutdown. As suggested in forum.debian.de.

All that had no effect.

Kind regards and thank for your effort working on Debian.




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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 systemd-sysv depends on:
ii  systemd  251.4-3

Versions of packages systemd-sysv recommends:
ii  libnss-systemd  251.4-3
ii  libpam-systemd  251.4-3

systemd-sysv suggests no packages.

-- no debconf information

Bug#1019506: usrmerge: usr-is-merged claims system is not usr-merged but usrmerge is installed

[Philip RInn]

Hi

I guess, I spotted the problem: it seems /lib32 is not merged.

lrwxrwxrwx   1 root root7 20. Nov 2020  bin -> usr/bin
lrwxrwxrwx   1 root root7 20. Nov 2020  lib -> usr/lib
drwxr-xr-x   2 root root 4,0K  3. Sep 10:33 lib32
lrwxrwxrwx   1 root root9 20. Nov 2020  lib64 -> usr/lib64
lrwxrwxrwx   1 root root8 20. Nov 2020  sbin -> usr/sbin


Not sure if it's of relevance, but that's what is in /lib32, /usr/lib32

philip@debian:~$ ls -la /lib32
drwxr-xr-x  2 root root  4,0K  3. Sep 10:33 .
drwxr-xr-x 19 root root  4,0K  9. Sep 14:56 ..
-rwxr-xr-x  1 root root  200K 27. Aug 13:38 ld-linux.so.2
-rw-r--r--  1 root root   14K 27. Aug 13:38 libanl.so.1
-rw-r--r--  1 root root   14K 27. Aug 13:38 libBrokenLocale.so.1
-rw-r--r--  1 root root   43K 27. Aug 13:38 libc_malloc_debug.so.0
-rwxr-xr-x  1 root root  2,2M 27. Aug 13:38 libc.so.6
-rw-r--r--  1 root root   14K 27. Aug 13:38 libdl.so.2
-rw-r--r--  1 root root   18K 27. Aug 13:38 libmemusage.so
-rw-r--r--  1 root root 1014K 27. Aug 13:38 libm.so.6
-rw-r--r--  1 root root   94K 27. Aug 13:38 libnsl.so.1
-rw-r--r--  1 root root   38K 27. Aug 13:38 libnss_compat.so.2
-rw-r--r--  1 root root   14K 27. Aug 13:38 libnss_dns.so.2
-rw-r--r--  1 root root   14K 27. Aug 13:38 libnss_files.so.2
-rw-r--r--  1 root root   26K 27. Aug 13:38 libnss_hesiod.so.2
-rw-r--r--  1 root root   14K 27. Aug 13:38 libpcprofile.so
-rw-r--r--  1 root root   14K 27. Aug 13:38 libpthread.so.0
-rw-r--r--  1 root root   62K 27. Aug 13:38 libresolv.so.2
-rw-r--r--  1 root root   14K 27. Aug 13:38 librt.so.1
-rw-r--r--  1 root root   22K 27. Aug 13:38 libSegFault.so
-rw-r--r--  1 root root   38K 27. Aug 13:38 libthread_db.so.1
-rw-r--r--  1 root root   14K 27. Aug 13:38 libutil.so.1

philip@debian:~$ ls -la /usr/lib32
drwxr-xr-x  3 root root 4,0K 10. Sep 12:21 .
drwxr-xr-x 15 root root 4,0K 15. Apr 12:54 ..
drwxr-xr-x  3 root root  36K  3. Sep 10:33 gconv
-rw-r--r--  1 root root 150K  8. Sep 15:52 libgcc_s.so.1
lrwxrwxrwx  1 root root   19  8. Sep 15:52 libstdc++.so.6 -> libstdc++.so.6.0.30
-rw-r--r--  1 root root 2,2M  8. Sep 15:52 libstdc++.so.6.0.30



Not sure how I got into that situation ... and not sure why installing usrmerge 
again didn't fix it ...


Best,
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019509: src:loggerhead: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: loggerhead
Version: 1.19~bzr511-1
Severity: serious
Control: close -1 2.0.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:loggerhead has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package has autopkgtests 
which regressed.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019508: src:uftrace: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: uftrace
Version: 0.11-6
Severity: serious
Control: close -1 0.12-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1015032

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:uftrace has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build from 
source as reported in bug 1015032.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017348: autopkgtest regression on ppc64el

[Alexis Bienvenüe]

Control: reassign -1 libopencv-imgproc406 
Control: severity -1 normal
Control: retitle -1 libopencv-imgproc406: cv::boundingRect fails on ppc64el

Hi.

I'm afraid I could not find why cv::boundingRect behaves like that.
Anyway I reassign this bug to opencv.

Regards,
Alexis Bienvenüe.

Bug#1019506: usrmerge: usr-is-merged claims system is not usr-merged but usrmerge is installed

[Philip Rinn]

Package: usrmerge
Version: 29
Severity: normal
X-Debbugs-Cc: ri...@debian.org

Hi,

I'm pretty sure I migrated my system to usr-merged long time ago (uninstalled
ursmerge again iirc). I now wanted to install usr-is-merged to avoid getting
usrmerge installed again - and usr-is-merge claimed my system was not usr-
merged. I installed usrmerge again but usr-is-merged still thinks it's not
merged:

philip@debian:~$ LANG=C sudo apt install usrmerge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
usrmerge is already the newest version (29).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

philip@debian:~$ LANG=C sudo apt install usr-is-merged
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  usr-is-merged
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/4332 B of archives.
After this operation, 12.3 kB of additional disk space will be used.
(Reading database ... 415597 files and directories currently installed.)
Preparing to unpack .../usr-is-merged_29_all.deb ...


**
*
* The usr-is-merged package cannot be installed because this system does
* not have a merged /usr.
*
* Please install the usrmerge package to convert this system to merged-/usr.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
**


dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_29_all.deb
(--unpack):
 new usr-is-merged package pre-installation script subprocess returned error
exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/usr-is-merged_29_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


Am I missing something here?

Best
Philip


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

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

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-2
ii  perl5.34.0-5

usrmerge recommends no packages.

usrmerge suggests no packages.

-- no debconf information

Bug#1019505: ltrace: no Homepage field

[Jakub Wilk]

Source: ltrace
Version: 0.7.3-6.3
Severity: wishlist

Please add

Homepage: https://www.ltrace.org/

to debian/control.

--
Jakub Wilk

Bug#1019454: dgit push-built --quilt=unapplied should auto-create separate dgit view like push-source does

[Ian Jackson]

Simon McVittie writes ("Bug#1019454: dgit push-built --quilt=unapplied should 
auto-create separate dgit view like push-source does"):
> On Fri, 09 Sep 2022 at 18:53:27 +0100, Ian Jackson wrote:
> > Hmmm.  I think dgit is expecting you to have built the source package
> > along with the binaries, with some variant on `dgit build`.
> 
> That seems plausible. I did build the source package along with the
> binaries, just not with `dgit build`: I already have a build environment
> I'm happy with, and I don't want to pass its options through too many
> layers of "interpret some options and then pass the rest on". (Perhaps
> I should start using `dgit build` for its convenient -v handling, but
> that's not part of my workflow right now.)

Right, fair enough.

> > Note that there are situations where you must use dgit to make the
> > source package (or specify funny options to your builder program),
> > notably if you have changes to (or additions of) .gitignore in the
> > upstream part of the tree.
> 
> If I got this wrong, the failure mode would be that dgit complains that
> my .dsc doesn't match my git state and refuses to upload it, correct?

Yes.

> If so, I don't see that as a problem: I'm fine with limiting myself
> to the category of changes that makes my git tree simple to deal with
> (that goes with the patches-unapplied territory).

Quite so.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1019479: ITP: rust-async-std -- async version of the Rust standard library

[Jonas Smedegaard]

Quoting Reinhard Tartler (2022-09-10 19:42:34)
> On Sat, Sep 10, 2022 at 1:02 PM Jonas Smedegaard  wrote:
> 
> > Quoting Reinhard Tartler (2022-09-10 17:22:06)
> > > Thanks Jonas for working on this.
> > >
> > > Btw, I've looked at packaging it independently and may have good news for
> > > you:
> > >
> > > a) I've had some limited success with relaxing dependencies, please see
> > my
> > > patch attached to this email
> > > b) I've packaged and uploaded two dependencies to NEW:
> > > - https://ftp-master.debian.org/new/rust-sval_1.0.0~alpha.5-1.html
> > > - https://ftp-master.debian.org/new/rust-value-bag_1.0.0~alpha.9-1.html
> >
> > Nice! Especially that those packages you've done.
> >
> > I don't understand how you could get rid of kv-log-macro without
> > patching any Rust code - which is the part blocking me now.  But seems I
> > should simply wait for your work to get approved, and then bug the Rust
> > team about log crate breakage, and then try again...
> >
> 
> Awesome, it seems you've also packaged kv-log-macro, so once that's in
> unstable, another blocker is resolved.

s/packaged/am packaging/ - I cannot finalize that yet: Depends on
feature "kv_unstable" of crate log, which in turn depends on crate
value_bag that you've packaged just now.  Reported as bug#1019504.

Speaking of which: Please file ITP bugreports - they help track
dependencies and help communicate reasons other bugs are not yet
solved.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1019504: librust-log-dev: provided virtual package librust-log+kv-unstable-dev is unusable

[Jonas Smedegaard]

Package: librust-log-dev
Version: 0.4.17-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Virtual package librust-log+kv-unstable-dev is broken: It needs Rust
crate value_bag which is not yet in Debian.

The needed crate is in NEW however:
https://ftp-master.debian.org/new/rust-value-bag_1.0.0~alpha.9-1.html

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMc08sACgkQLHwxRsGg
ASHh7Q/+LX6gN4sF7Ml8dk95zUchJ/qR+YH+m2dwVJLAf4kp1+K7l4Tj0HgoQ3NL
JOiJehAfUHANK5vBrDuKiI+lFgtg6Q6oLS04GpBrdVRxpmiGWEvh62QBi08Bq9lo
7zmsoWaDgnBG0GF5ATZYg+vK9aIWpTiZ5CLruhCbT0tvk92PwOHAq2Y52TNSQ0jv
ts4rdbauVYsE5i6/sDEFQa+sTjXvR+5Q+Ohr4hfOvuoiD5Z9VF3viU+J4gYCL7lG
6l4ZMENL8Pu9wsrkotXSxOvrZvfsndZliwVFgtEPq9Po+i1cSKxabH5il+yX3aDJ
8NN89xo03x+if+DfJtukAmh6AU6MJ9nuvH22sPVx/GySjxPEwuX7WDjvu6SaMTMF
ffeZqeQVCcy5brJeEew4HrMSaNJ56fbwJAvjEfZxQRRBXZ5SLoJifN5V47mBL8sP
scrLF+9SRXC0aIngloXXHq/Q/Hf/SA3LMo+PG47xU7ZTOIYyTCzeULoEIWuqPH20
OHqJR1kjiYI0et+eON6Eb2Nw1ruFEyUAaDvDefsaOJ+UvunyiRgdZTxu7/o8tkYn
3luzcUrcH//cmD9nKbDN31hJDs9rWfhllFnMEcDJA/D2ceelUkUqw9AJHxaIo/BJ
ulf4h+oaiDcyhozypvEhKEMCjNiZUI3WS7hndSsxgK+aXVXpVm0=
=XOCs
-END PGP SIGNATURE-

Bug#1017766: podman: Failed to activate DNS. Missing dependency on golang-github-containernetworking-plugin-dnsname

[Reinhard Tartler]

Hi Michael,

On Sat, Aug 20, 2022 at 5:47 PM Michael Musenbrock <
michael.musenbr...@gmx.at> wrote:

>
>
> Now a dns-server is active in the network, but the other pods attached to
> the network
> still can't be resolved. But this may be just some config issue. I will
> check.
>
>
just checking in, did you had a chance to check whether this is a config
issue?

In any case, any chance you could describe your test setup? I'm still
looking
for a minimal test case that would be able to demonstrate the issue, and
thought
you might be able to help?

Best,
-rt


-- 
regards,
Reinhard

Bug#1019479: ITP: rust-async-std -- async version of the Rust standard library

[Reinhard Tartler]

On Sat, Sep 10, 2022 at 1:02 PM Jonas Smedegaard  wrote:

> Quoting Reinhard Tartler (2022-09-10 17:22:06)
> > Thanks Jonas for working on this.
> >
> > Btw, I've looked at packaging it independently and may have good news for
> > you:
> >
> > a) I've had some limited success with relaxing dependencies, please see
> my
> > patch attached to this email
> > b) I've packaged and uploaded two dependencies to NEW:
> > - https://ftp-master.debian.org/new/rust-sval_1.0.0~alpha.5-1.html
> > - https://ftp-master.debian.org/new/rust-value-bag_1.0.0~alpha.9-1.html
>
> Nice! Especially that those packages you've done.
>
> I don't understand how you could get rid of kv-log-macro without
> patching any Rust code - which is the part blocking me now.  But seems I
> should simply wait for your work to get approved, and then bug the Rust
> team about log crate breakage, and then try again...
>

Awesome, it seems you've also packaged kv-log-macro, so once that's in
unstable, another blocker is resolved.

Best,
rt
-- 
regards,
Reinhard

Bug#1019497: O: watchman -- file watching service

[Eriberto]

Em sáb., 10 de set. de 2022 às 13:57, Anuradha Weeraman
 escreveu:
>
> On Sat, Sep 10, 2022 at 01:14:51PM -0300, Eriberto Mota wrote:
> > Hi Anuradha,
> >
> > > The current version is dated and there a few issues with the python
> > > module that would need to be fixed if it's to make Bookworm. It also
> > > depends on an obsolete pcre3 library and the best course of action is to
> > > upgrade to the latest version upstream.
> >
> > Do you know if the python issues were fixed in the latest version upstream?
>
> Yes, it is. I've just uploaded a version (4.9.0-7) with the fix.

I will check this package soon. I am interested in adopting it, but I
need to take a look over the source before.

Thanks for your work.

Cheers,

Eriberto

Bug#1019503: postgresql-13: memory leak with JIT compilation

[Antoine Beaupre]

Package: postgresql-13
Version: 13.7-0+deb11u1
Severity: important

We have found severe regressions when upgrading from bookworm to
bullseye on two of our PostgreSQL servers.

It seems like, in busy workloads, the JIT actually leaks memory. Like
a lot. In this screenshot of a yearly Grafana dashboard, you can see
memory usage is fairly regular until the upgrade (early May) at which
point the server starts regularly swapping and eventually OOM'ing:

https://gitlab.torproject.org/tpo/tpa/team/uploads/41f8850ecc4b4170f56901b4018a9870/image.png

The internal ticket we filed about this has all the gory details,
which are probably too much for this bug report:

https://gitlab.torproject.org/tpo/tpa/team/-/issues/40815

We also had issues on other servers, more examples:

https://gitlab.torproject.org/tpo/tpa/team/-/issues/40814

While this may seem like a one-off thing that affects only certain
workloads — we certainly have other PostgreSQL that do not suffer from
this problem — when it *does* affect the workload, it's pretty
catastrophic. Hence the "important" severity ("major effect on the
usability of a package, without rendering it completely unusable to
everyone").

Also, it took us a long time to track down this problem... it's
basically only because of the release notes of an unrelated project
(PuppetDB) happened to feature a similar bug report that we were
hinted this could be a problem:

https://tickets.puppetlabs.com/browse/PDB-5452

... which makes me think this problem might be more widespread than a
few workloads. It seems like DSA also had problems with the upgrade on
the sources.debian.org server which, granted, is a huge server as
well, but I don't see why that should necessarily be a problem with
PostgreSQL...

Past PostgreSQL upgrades have been basically without flaw for us: the
procedure is a little disruptive (e.g. dump/restore, basically) but
apart from that, we have never seen such a huge regression in
performance. So I figured it was worth at least a bug report.

I'm not sure what should come out of this; I can't help but think this
is a bug in the JIT, but it's far beyond my capacity to even start
debugging this specifically. So maybe this could be forwarded
upstream? But in the meantime, maybe this could be fixed "simply" by
adding a note to the Debian bullseye release notes.

One should also see if this behavior also occurs in newer releases: we
briefly considered upgrading to 14 to see if this was still happening,
before finding the JIT trick, but have not done so (yet?).

Thank you for your attention,

a.

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

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

Versions of packages postgresql-13 depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u3
ii  libgcc-s1  10.2.1-6
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  libicu67   67.1-7
ii  libldap-2.4-2  2.4.57+dfsg-3+deb11u1
ii  libllvm11  1:11.0.1-2
ii  libpam0g   1.4.0-9+deb11u1
ii  libpq5 13.7-0+deb11u1
ii  libselinux13.1-3
ii  libssl1.1  1.1.1n-0+deb11u3
ii  libstdc++6 10.2.1-6
ii  libsystemd0247.3-7
ii  libuuid1   2.36.1-8+deb11u1
ii  libxml22.9.10+dfsg-6.7+deb11u2
ii  libxslt1.1 1.1.34-4+deb11u1
ii  locales2.31-13+deb11u3
ii  locales-all2.31-13+deb11u3
ii  postgresql-client-13   13.7-0+deb11u1
ii  postgresql-common  225
ii  ssl-cert   1.1.0+nmu1
ii  tzdata 2021a-1+deb11u5
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages postgresql-13 recommends:
pn  sysstat  

postgresql-13 suggests no packages.

-- debconf information:
  postgresql-13/postrm_purge_data: true

Bug#1012333: u-boot-menu: add support for using config fragments

[Vagrant Cascadian]

On 2022-06-04, Jonas Smedegaard wrote:
> Quoting Arnaud Ferraris (2022-06-04 16:39:03)
>> Currently u-boot-menu makes use of a single configuration file
>> one has to edit in order to change the default options. It could
>> be useful to use config fragments containing only one (or more)
>> variables, so that different packages could change different
>> config options (for example, one fragment could modify the
>> default cmdline, while another one could change the DTB folder).
>
> Thanks, that sounds like a useful feature indeed.
>
> Seems more sensible for me, however, to implement this using debconf.
>
> Otherwise, installation and removal of a package would need to trigger
> u-boot-menu, and u-boot-menu would need to specially examine such
> cofigfile snippets to skip snippets belonging to removed but not purged
> packages.

Well, you could implement configuration files snippets directory outside
of /etc (e.g. /usr/share/u-boot-menu/snippet.d or something like that),
which would avoid this problem. u-boot-menu could have a dpkg trigger
that for when files in this directory change.

That seems a lot simpler than introducing the complexity of debconf
generated configuration files...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1019502: xfce4-session: sometimes fails to start from gdm3: /usr/bin/startxfce4: X server already running on display :0

[Simon McVittie]

Package: xfce4-session
Version: 4.16.0-1
Severity: normal

While testing installation media for #debian-cd, I tried the test-case
that involved installing all the available desktop environments (GNOME,
XFCE, etc.). I chose gdm3 as the display manager when prompted (it was the
default), finished the installation, and rebooted to the installed system.

Most of the desktop environments that I tried worked fine, but XFCE failed
to log in (bounced back to the gdm3 prompt after a brief blank screen).
This log message in the systemd journal might be relevant:

Sep 10 17:41:04 espresso /usr/libexec/gdm-x-session[10361]: 
/usr/bin/startxfce4: X server already running on display :0

I'm surprised if startxfce4 is starting its own X11 server, since the
traditional situation for X11 display managers is that the display manager
is responsible for starting Xorg.

It worked OK when I used dpkg-reconfigure to swap from gdm3 to lightdm
(which is a better choice anyway on systems where you'd want to use XFCE).

This doesn't seem to be 100% reproducible: after a couple of cycles of
switching the display manager and rebooting, XFCE started up fine even
from gdm3. I'm not sure what was going on there.

As a hint for any XFCE maintainers who might look into this while not
being familiar with gdm3, the interface for choosing a desktop environment
in gdm3 is:

- choose your user
- don't enter your password immediately
- click on the gear wheel icon in the lower right corner
- choose the desired desktop environment
- *now* enter your password

smcv

-- 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-18-amd64 (SMP w/4 CPU threads)
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 xfce4-session depends on:
ii  libatk1.0-02.36.0-2
ii  libc6  2.31-13+deb11u4
ii  libcairo2  1.16.0-5
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libice62:1.0.10-1
ii  libpango-1.0-0 1.46.2-3
ii  libpolkit-gobject-1-0  0.105-31+deb11u1
ii  libsm6 2:1.2.3-1
ii  libwnck-3-03.36.0-1
ii  libx11-6   2:1.7.2-1
ii  libxfce4ui-2-0 4.16.0-1
ii  libxfce4util7  4.16.0-1
ii  libxfconf-0-3  4.16.0-2
ii  x11-xserver-utils  7.7+8
ii  xfce4-settings 4.16.0-1
ii  xfconf 4.16.0-2

Versions of packages xfce4-session recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  libpam-systemd [logind]   247.3-7+deb11u1
ii  light-locker  1.8.0-3
ii  systemd-sysv  247.3-7+deb11u1
ii  upower0.99.11-2
ii  xfdesktop44.16.0-1
ii  xfwm4 4.16.1-1

Versions of packages xfce4-session suggests:
pn  fortunes-mod  
ii  sudo  1.9.5p2-3

-- no debconf information

Bug#1019465: [Aptitude-devel] Bug#1019465: Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason

[Axel Beckert]

Control: tag -1 - moreinfo

Hi Vincent,

Vincent Lefevre wrote:
> > > Linux Standard Base init script functionality
> > > lsb-base (remove, 11.2) will be automatically removed because of 
> > > dependency▒
> > > errors:   
> > >  ▒
> > 
> > Where did this show up? I didn't get this. Or at least can't remember
> > it. Was this a pop-up message?
> 
> After typing 'g' (to "perform all pending installations, removals,
> and upgrades") and putting the cursor over the
> 
> id  lsb-base -50.2 kB  11.2 11.2
> 
> line (in order to learn why this package is removed). This is what
> the bottom part of the window shows.

Ah, I didn't see that because I have the description window hidden by
default. Thanks for the explanation.

> > > but no errors shown!!!
> > 
> > Because they were resolved.
> 
> OK, so the real reason should be given.

Ack.

> > > It seems to be triggered by the upgrade of sysvinit packages from
> > > 3.04-1 to 3.05-2. In the sysvinit 3.05-1 log message:
> > > 
> > >   * Take over library scripts from lsb-base.
> > 
> > Yes, but because of this:
> > 
> > Conflicts: lsb-base
> 
> Normally conflicts produce an error on packages that must not be
> removed. Here, I suppose that this is OK because of
> 
> Provides: lsb-base (= 11.1.0)
> 
> (by default, this is not shown by aptitude in the package description).

Hmmm, yeah, that probably should be fixed, too.

> > So from my point of view aptitude did everything correctly and I don't
> > see a bug here.
> 
> Well, the "because of dependency errors" in the above message is
> incorrect and very confusing. Since there are no dependency errors,
> this cannot be because of dependency errors.

Indeed. Thanks for the additional information!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1019479: ITP: rust-async-std -- async version of the Rust standard library

[Jonas Smedegaard]

Quoting Reinhard Tartler (2022-09-10 17:22:06)
> Thanks Jonas for working on this.
> 
> Btw, I've looked at packaging it independently and may have good news for
> you:
> 
> a) I've had some limited success with relaxing dependencies, please see my
> patch attached to this email
> b) I've packaged and uploaded two dependencies to NEW:
> - https://ftp-master.debian.org/new/rust-sval_1.0.0~alpha.5-1.html
> - https://ftp-master.debian.org/new/rust-value-bag_1.0.0~alpha.9-1.html

Nice! Especially that those packages you've done.

I don't understand how you could get rid of kv-log-macro without
patching any Rust code - which is the part blocking me now.  But seems I
should simply wait for your work to get approved, and then bug the Rust
team about log crate breakage, and then try again...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Matthew Vernon]

On 09/09/2022 19:45, Sean Whitton wrote:

Hello,

On Thu 08 Sep 2022 at 10:09PM -07, Steve Langasek wrote:


For the record I do not consider this an override requiring a
supermajority and would abide by a majority TC decision.


Thank you for your input.  The TC can just issue advice after reviewing
the proposed changes, in this case.  An alternative would be to word the
resolution such that it counts as advice if we have a simple majority
and an override if we have a supermajority.  I'd prefer the former, but
it would be good to hear from Helmut about it.


AIUI, Steve's objection is substantially that this is quite an invasive 
change to make across our toolchain, and should be discussed on 
debian-devel before just being implemented package-by-package (rather 
than any particular objection to the approach). Is that correct?


But that Sam is unsold on the technical approach and wanted input from 
Steve before agreeing?


Regards,

Matthew

Bug#1019497: O: watchman -- file watching service

[Anuradha Weeraman]

On Sat, Sep 10, 2022 at 01:14:51PM -0300, Eriberto Mota wrote:
> Hi Anuradha,
> 
> > The current version is dated and there a few issues with the python
> > module that would need to be fixed if it's to make Bookworm. It also
> > depends on an obsolete pcre3 library and the best course of action is to
> > upgrade to the latest version upstream.
> 
> Do you know if the python issues were fixed in the latest version upstream?

Yes, it is. I've just uploaded a version (4.9.0-7) with the fix.

-- 
Anuradha

Bug#1018064: Subject: RFS: cmd2/2.4.1+ds-1 [ITA] [RC] -- Improved Python cmd2 module from (cammon documentation)

[Nilson Silva]

Control: tags -1 - moreinfo,

Hi tobias!
> I suggest tracking the RFS bug. Remove a tag more info and maybe
> summarize what has been changed
> someone catch it sooner than I can, and I also prefer
> to do the real sponsorship "in the open"
> (I unintentionally dropped the CC bug at some point…

I decided to keep it in the debian namespace instead of the python team. 
I made the appropriate changes to the control and changelog.

And now, I'm just waiting for your decision, regarding sponsorship

good weekend!
Nilson F. Silva


De: Tobias Frost 
Enviado: segunda-feira, 29 de agosto de 2022 04:26
Para: Nilson Silva 
Assunto: Re: Bug#1018064: Subject: RFS: cmd2/2.4.1+ds-1 [ITA] [RC] -- Improved 
Python cmd2 module from (cammon documentation) 
 
Hi Nilson,

On Sat, Aug 27, 2022 at 05:11:20PM +, Nilson Silva wrote:
> Control: tags -1 - moreinfo
> 
> Hello Tobias!
> finished!
> As I still don't have cmd2 permission on debian, I created a Fork and renamed 
> the branch from master to debian/master which is the team's default.
> 
> As also the current repository shows that the package is not from the python 
> team.

I don't know about python team policies, but the debian/ namespace is a special
namespace for collabarative maintainance of packages. If it is in this
namespace, it says: everyone is invited to help maintaining.
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

I like this concept very much, so I would find it a pity if it is moved to the 
python
team namespace. But as said, I dont know their policies about this aspect.

FWWIW, I've granted you access rights to the repository in the debian namespace.

Note, if you decide to move it into the python team namespace, ask the salsa 
admins
to move it, instead of creating another repository.


> follow the new .dsc and mine
> https://mentors.debian.net/package/cmd2/
> 
> and personal repository where the fork is:
> 
> https://salsa.debian.org/nilsonfsilva/python-cmd2
(I think we should first settle the location of the repo before uploading,
as currently it points to 
https://salsa.debian.org/python-team/packages/python-cmd2
which is ENOENT.)
 
> Assunto: Bug#1018064: Subject: RFS: cmd2/2.4.1+ds-1 [ITA] [RC] -- Improved 
> Python cmd2 module from (cammon documentation) 
> (...)
> You write:
> >    * New maintainer. (Closes: #1012662, #1002341)
> 
> however, #1002341 is fixing a FTBFS, so it does not "match" the entry. I guess
> this bug deserves its own changelog entry…

(this has not been fixed.)

> Cheers,
> --
> tobi

Bug#1019465: [Aptitude-devel] Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason

[Vincent Lefevre]

Hi Axel,

On 2022-09-10 15:34:50 +0200, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > After marking some packages for upgrade, I get:
> > 
> > --\ Packages being deleted due to unsatisfied dependencies (1)
> > id  lsb-base -50.2 kB  11.2 11.2
> 
> which is correct, yes.
> 
> > Linux Standard Base init script functionality
> > lsb-base (remove, 11.2) will be automatically removed because of dependency 
> >▒
> > errors: 
> >▒
> 
> Where did this show up? I didn't get this. Or at least can't remember
> it. Was this a pop-up message?

After typing 'g' (to "perform all pending installations, removals,
and upgrades") and putting the cursor over the

id  lsb-base -50.2 kB  11.2 11.2

line (in order to learn why this package is removed). This is what
the bottom part of the window shows.

> > but no errors shown!!!
> 
> Because they were resolved.

OK, so the real reason should be given.

> > It seems to be triggered by the upgrade of sysvinit packages from
> > 3.04-1 to 3.05-2. In the sysvinit 3.05-1 log message:
> > 
> >   * Take over library scripts from lsb-base.
> 
> Yes, but because of this:
> 
> Conflicts: lsb-base

Normally conflicts produce an error on packages that must not be
removed. Here, I suppose that this is OK because of

Provides: lsb-base (= 11.1.0)

(by default, this is not shown by aptitude in the package description).

> So from my point of view aptitude did everything correctly and I don't
> see a bug here.

Well, the "because of dependency errors" in the above message is
incorrect and very confusing. Since there are no dependency errors,
this cannot be because of dependency errors.

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

Bug#1019497: O: watchman -- file watching service

[Eriberto Mota]

Hi Anuradha,

> The current version is dated and there a few issues with the python
> module that would need to be fixed if it's to make Bookworm. It also
> depends on an obsolete pcre3 library and the best course of action is to
> upgrade to the latest version upstream.

Do you know if the python issues were fixed in the latest version upstream?

Cheers,

Eriberto

Bug#1019483: [INTL:es] Spanish translation of the debconf template

[Christoph Biedl]

Control: tags 1019483 pending

Camaleón wrote...

> You can find enclosed the Spanish translation template to be uploaded
> with the latest package build.

Thanks, queued up.

Christoph


signature.asc
Description: PGP signature

Bug#1018725: rlottie: FTBFS on riscv64

[Nicholas Guriev]

Control: tag -1 pending

Hello!

I rewrote the Atomic-render.patch with std::atomic_flag that does not demand
linking against libatomic on riscv64. At least cross-compiling works.

https://salsa.debian.org/debian/rlottie/-/commit/d45c764f0c3c3857ab8eb137f6444f3edd924020


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

Bug#697088: Hi/hola?

[Thas Yeol]

Bug#1019501: ansible-mitogen should probably depend on ansible and not on ansible-core

[Florian Küpper]

Package: ansible-mitogen
Version: 0.3.3-2

Dear python packaging Team,
in docs/ansible_detailed.rst#noteworthy-differences it is layed out
that for newer ansible versions,
which split ansible-core and ansible , ansible 5 is satisfying
mitogens (ansible) depedencies.
Next upstream iteration ansible 6 will be supported.

Your control file however has a nearly explicit dependency on debians
current ansible-core.
For bookworm that amounts to a "de-facto inverse dependency" of
ansible-core on ansible-mitogen.

I beleive I saw autopkg-tests and I wonder if You could relax Your
control file to reflect that and instead fail only if tests fail.

Many Thanks in advance!
Florian

Bug#1018727: bash: after upgrade, aliases with embedded $() subcommands don't work

[Jon DeVree]

This is fixed in bash 5.2-rc4
-- 
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).

Bug#1019500: apt-cacher-ng should depend on xz-utils

[Tim Woodall]

Package: apt-cacher-ng
Version: 3.7.4-1
Severity: minor

Dear Maintainer,

The /etc/cron.daily/apt-cacher-ng installed by apt-cacher-ng uses
/usr/bin/xz from xz-utils but apt-cacher-ng does not depend on that
package.

Please consider adding this dependency otherwise you can get emails from
cron like the following:

/etc/cron.daily/apt-cacher-ng:
xargs: xz: No such file or directory

Thanks.

Bug#763199: RFP: libpdl-fftw3-perl -- PDL interface to the Fastest Fourier Transform in the West v3

[Thomas Uhle]

Control: retitle -1 RFP: libpdl-fftw3-perl -- PDL interface to the Fastest 
Fourier Transform in the West v3

* Package name: libpdl-fftw3-perl
  Version : 0.18
  Upstream Author : Ed J , Dima Kogan , Craig DeForest 
, Chris Marshall 
* URL or Web page : https://metacpan.org/dist/PDL-FFTW3/
* License : GPL-3
  Description : PDL interface to the Fastest Fourier Transform in the West 
v3

This is a PDL interface to version 3 of the FFTW library. It is similar 
to the standard FFT routine but usually much faster and it supports 
complex <-> complex and real <-> complex FFTs.


PDL::FFTW used to be part of the standard PDL distribution but the days 
of FFTW v2.x are long gone, also in Debian's repositories. As PDL::FFTW3 
interfaces the successor which is verion 3 of the FFTW library, it would 
be possible and really great to have FFTW back for use with PDL.

Bug#1019479: ITP: rust-async-std -- async version of the Rust standard library

[Reinhard Tartler]

Thanks Jonas for working on this.

Btw, I've looked at packaging it independently and may have good news for
you:

a) I've had some limited success with relaxing dependencies, please see my
patch attached to this email
b) I've packaged and uploaded two dependencies to NEW:
- https://ftp-master.debian.org/new/rust-sval_1.0.0~alpha.5-1.html
- https://ftp-master.debian.org/new/rust-value-bag_1.0.0~alpha.9-1.html

Hope that helps!
-rt

On Sat, Sep 10, 2022 at 5:21 AM Jonas Smedegaard  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> * Package name: rust-async-std
>   Version : 1.12.0
>   Upstream Author : Stjepan Glavina  and more
> * URL : https://async.rs/
> * License : Apache-2.0 or Expat
>   Programming Lang: Rust
>   Description : async version of the Rust standard library
>
>  async-std is a library
>  that looks and feels like the Rust standard library,
>  except everything in it is made to work with async/await
>  exactly as you would expect it to.
>
> This package is needed by rust-criterion.
> It will be maintained in the Debian section of Salsa, at
> https://salsa.debian.org/debian/rust-async-std
>
>  - Jonas
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMcVpYACgkQLHwxRsGg
> ASFWmg/+NwUatUny1Hv+VuYmWqH0kNQaSJMZo7jrD0/5oSjcAFEFNsDQhnpairAR
> We52Qqds0m9a90A/w9FSjJnHrBfexmOJ9w0Nho4V9KcEat7Ia18GqS0G/REvr4QF
> xJj2pV2WRHz0cuegc711tT1W8qbOPKvz7D6MhzlrrGHB7z3Jj2mCp2Am9UBW7Nov
> TD/6cw31aDbZpnxmBJUys/UmEdkycg4fa0SBg5jQGtvWO2Vj1ifPnPlF+YV2Djh9
> 2JnBkydYDeE0eU9C81b9h0BFvC0fR9VWe6XKFLwHC3NePhC+CIka9NU6ANjvOAzb
> PPHFMNiS7dgr5+Ke7Jd4j1g3BEOloS1m1Mr2MYFY46g3SybSMk/dNcxMVe7L1TQN
> XMAzr6hjC/dqpjapiXvK4eW66rfgBKN9M0PEnGWXVF3skbvmWKRyIP/6tu8DtAVz
> DDOOjuR/256gM5fEEqHWNRxaufg+m0rQEKFgvegv8K4aiTu5qL9JfzQxBph/6AsM
> qEnmg0vhNK9RP77eNE06uXmlbXIDJx06Bu2MdrkzhjK4lelJ50OtwCuSdSlt99Px
> 1X42PlmOP4JLRSQa/JjzBUpz4nUaUNK0Or7EPVFt8oOpRw3wLq4PsVhQbiPqX5Um
> YI0UHlmTO9nb91Fs74suS5J/USgatRvEGY8Tukd9oLEPx11CIt0=
> =XQhF
> -END PGP SIGNATURE-
>
>

-- 
regards,
Reinhard
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -80,10 +80,6 @@
 version = "0.3.4"
 optional = true
 
-[dependencies.kv-log-macro]
-version = "1.0.6"
-optional = true
-
 [dependencies.log]
 version = "0.4.8"
 features = ["kv_unstable"]
@@ -139,10 +135,8 @@
 "async-global-executor",
 "async-io",
 "futures-lite",
-"kv-log-macro",
 "log",
 "pin-project-lite",
-"gloo-timers",
 ]
 docs = [
 "attributes",
@@ -158,7 +152,6 @@
 "once_cell",
 "pin-utils",
 "slab",
-"wasm-bindgen-futures",
 "futures-channel",
 "async-channel",
 "async-lock",
@@ -193,15 +186,6 @@
 version = "0.3.4"
 optional = true
 
-[target."cfg(target_arch = \"wasm32\")".dependencies.gloo-timers]
-version = "0.2.1"
-features = ["futures"]
-optional = true
-
-[target."cfg(target_arch = \"wasm32\")".dependencies.wasm-bindgen-futures]
-version = "0.4.10"
-optional = true
-
 [target."cfg(target_arch = \"wasm32\")".dev-dependencies.getrandom]
 version = "0.2.0"
 features = ["js"]

Bug#1018065: On disappeared reactions and animated stickers

[Nicholas Guriev]

clone 1018065 -2
reassign -2 librlottie0-1 0.1+dfsg-3
retitle -2 rlottie: invisible animation with separated layers
retitle 1018065 telegram-desktop: dangling decoding threads due to video 
stickers
thanks

Hi, everyone interested!

I am splitting this bug report into two as Alexander Kernozhitsky suggested.
Because the problems need to be fixed in different packages.

For disappeared reactions and invisible animated stickers, I already have a
fix. It was due to wrong check in my No-cyclic-structures.patch. As for
incorrect FFmpeeg usage, it will be fixed in the upcoming Telegram release.


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

Bug#965242: procmon: changing from ITP to RFP

[Anuradha Weeraman]

retitle 965242 RFP: procmon -- utility to trace the syscall activity on the 
system
noowner 965242
thanks

I'm unable to spend time on packaging and maintaining this, and since
this has been in my queue for a while, I'd like to give this up to
someone who'd be willing to take this up.

-- 
Anuradha

Bug#1019498: gm2-12 linker failure

[Tilmann Hentze]

Package: gm2-12
Version: 12.2.0-2
Severity: normal

Dear Maintainer,

gm2-12 fails to link this simple program:
$ cat helloworld.mod 
MODULE helloWorld;
FROM StrIO IMPORT WriteString, WriteLn;

BEGIN
WriteString("Hello World");
WriteLn;
END helloWorld.

$ gm2-12 helloworld.mod 
/usr/bin/ld: /tmp/ccEDyn3K.a(a-helloworld_m2.o): in function `init(int, 
char**)':
a-helloworld_m2.cpp:(.text+0x154): undefined reference to `_M2_helloWorld_init'
/usr/bin/ld: /tmp/ccEDyn3K.a(a-helloworld_m2.o): in function `finish()':
a-helloworld_m2.cpp:(.text+0x196): undefined reference to 
`_M2_helloWorld_finish'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/m2/m2pim/libm2pim.so: undefined 
reference to `RTco_select'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/m2/m2pim/libm2pim.so: undefined 
reference to `RTco_initSemaphore'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/m2/m2pim/libm2pim.so: undefined 
reference to `RTco_wait'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/m2/m2pim/libm2pim.so: undefined 
reference to `RTco_signal'
collect2: error: ld returned 1 exit status

Please note: gm2-10 (10.4.0-5) show the same error message.
Compiling and linking above program works with gm2-9 (9.5.0-2) though.
Best regards,
Tilmann.

-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages gm2-12 depends on:
ii  g++-12 12.2.0-2
ii  gcc-12-base12.2.0-2
ii  libc6  2.34-7
ii  libgcc-s1  12.2.0-2
ii  libgm2-12-dev  12.2.0-2
ii  libgmp10   2:6.2.1+dfsg1-1
ii  libisl23   0.25-1
ii  libmpc31.2.1-2
ii  libmpfr6   4.1.0-3
ii  libstdc++6 12.2.0-2
ii  libzstd1   1.5.2+dfsg-1
ii  zlib1g 1:1.2.11.dfsg-4.1

gm2-12 recommends no packages.

gm2-12 suggests no packages.

-- no debconf information

Bug#1019497: O: watchman -- file watching service

[Anuradha Weeraman]

Package: wnpp
Severity: normal
Control: affects -1 src:watchman

I haven't been using this package in a while, and the latest version
upstream requires some work to get into Debian, which I cannot afford
right now.

The current version is dated and there a few issues with the python
module that would need to be fixed if it's to make Bookworm. It also
depends on an obsolete pcre3 library and the best course of action is to
upgrade to the latest version upstream.

If you use this package and would like to maintain it, please adopt it.
It's a good and useful package and deserves someone who can spend some
quality time on it.

-- 
Anuradha

Bug#1019496: linux-signed-amd64: Please add CONFIG_SENSORS_AQUACOMPUTER_D5NEXT as module.

[Patrick]

Source: linux-signed-amd64
Version: 5.19.6+1
Severity: normal

Hello,

would it be possible to add CONFIG_SENSORS_AQUACOMPUTER_D5NEXT as a
module in order to enable the drivers for the aquacomputer devices?

Thanks in advance!

Best regards
Patrick Clara

Bug#1019495: Cross-origin requests for torrent files

[Soni "They/Them" L.]

Package: cdimage.debian.org
Severity: wishlist

Please add

    Access-Control-Allow-Origin: *

to the HTTP headers for .torrent files. We're working on an in-browser
webtorrent-powered distro downloader at https://distrorrent.github.io/
and being able to fetch up-to-date torrents directly would be nice to have.

Thanks.

Bug#1019494: localepurge: uses egrep and fgrep: fgrep/egrep: warning: egrep is obsolescent; using grep -F/-E

[Axel Beckert]

Package: localepurge
Version: 0.7.3.10
Severity: normal

localepurge's hook under /etc/apt/apt.conf.d/99-localepurge uses egrep:

  Post-Invoke {"if [ -x /usr/sbin/localepurge ] && [ $(ps w -p $PPID | egrep -c 
'(remove|purge)') != 1 ]; then /usr/sbin/localepurge; else exit 0; fi";};

Which since grep 3.8 unfortunately emits this annoying warning:

  egrep: warning: egrep is obsolescent; using grep -E

Additionally it uses fgrep in /usr/sbin/localepurge itself:

  /usr/sbin/localepurge:   if [ -f $NOPURGECONF ] && fgrep --quiet 
--line-regexp USE_DPKG $NOPURGECONF ; then
  /usr/sbin/localepurge:  if fgrep --quiet --line-regexp USE_DPKG $NOPURGECONF
  /usr/sbin/localepurge:  elif fgrep --quiet --line-regexp NEEDSCONFIGFIRST 
$NOPURGECONF
  /usr/sbin/localepurge:if fgrep --quiet --line-regexp DONTBOTHERNEWLOCALE 
$NOPURGECONF; then
  /usr/sbin/localepurge:if fgrep --quiet --line-regexp SHOWFREEDSPACE 
$NOPURGECONF; then
  /usr/sbin/localepurge:if fgrep --quiet --line-regexp MANDELETE $NOPURGECONF; 
then
  /usr/sbin/localepurge:if fgrep --quiet --line-regexp VERBOSE $NOPURGECONF \
  /usr/sbin/localepurge:if fgrep --quiet --line-regexp QUICKNDIRTYCALC 
$NOPURGECONF; then

See /usr/share/doc/grep/NEWS.Debian.gz for details.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  locales2.34-7
ii  perl   5.34.0-5
ii  procps 2:3.3.17-7+b1
ii  ucf3.0043

localepurge recommends no packages.

Versions of packages localepurge suggests:
ii  bleachbit  4.4.2-1
pn  debfoster  
ii  deborphan  1.7.35

-- debconf information:
* localepurge/nopurge: de, de_CH.UTF-8, de_DE.UTF-8, en, en_DK.UTF-8, 
en_GB.UTF-8, en_US.UTF-8
  localepurge/verbose: false
  localepurge/remove_no:
  localepurge/quickndirtycalc: true
  localepurge/showfreedspace: true
  localepurge/dontbothernew: false
* localepurge/mandelete: true
  localepurge/none_selected: false
* localepurge/use-dpkg-feature: true

Bug#1019465: [Aptitude-devel] Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason

[Axel Beckert]

Control: tag -1 + moreinfo

Hi Vincent,

Vincent Lefevre wrote:
> After marking some packages for upgrade, I get:
> 
> --\ Packages being deleted due to unsatisfied dependencies (1)
> id  lsb-base -50.2 kB  11.2 11.2

which is correct, yes.

> Linux Standard Base init script functionality
> lsb-base (remove, 11.2) will be automatically removed because of dependency   
>  ▒
> errors:   
>  ▒

Where did this show up? I didn't get this. Or at least can't remember
it. Was this a pop-up message?

> but no errors shown!!!

Because they were resolved.

> It seems to be triggered by the upgrade of sysvinit packages from
> 3.04-1 to 3.05-2. In the sysvinit 3.05-1 log message:
> 
>   * Take over library scripts from lsb-base.

Yes, but because of this:

Conflicts: lsb-base

So from my point of view aptitude did everything correctly and I don't
see a bug here.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1019476: Re

[pascalr0410]

Ther problem have been corected with the 11.5 release

Could be close.

Bug#1019492: RFP: python-aiosignald -- Python bindings for signald

[Martin]

Package: wnpp
Severity: wishlist

* Package name: python-aiosignald
  Version : v0.3.1
  Upstream Author : Nicolas Cedilnik 
* URL or Web page : https://git.sr.ht/~nicoco/aiosignald
* License : AGPL-3+
  Description : Python bindings for signald
  
> Interact with the signal messaging network in python with sweet, sweet
> autocompletion. Most of the code is generated by the generate.py
> script that uses the schema available at
> https://signald.org/protocol.json. No 3rd party dep, just the python
> standard lib.

Bug#1019486: gdm3: Gdm3 crashes (oh no something has gone wrong)

[Jeremy Bicha]

Control: severity -1 important

My best guess is that this issue is caused by your mixing and matching
pieces from Unstable and Testing.

The automatically included dependency list doesn't have enough details
for me to tell exactly where the problem is.

We are doing a large and complicated transition this week affecting
several different libraries and services that all need to be upgraded
together to ensure that things like gdm (which uses gnome-shell)
continue to work. I did try adding many Breaks and dependency bumps,
but I'm sure I did not add enough to cover every possible attempted
incomplete upgrade. I think the transition will migrate to Testing
tonight or tomorrow night which will make it simpler to be sure you
have all the right packages.

https://bugs.debian.org/1016706

Thank you,
Jeremy Bicha

Bug#1019491: cargo FTCBFS: missing Build-Depends: zlib1g-dev:native

[Helmut Grohne]

Source: cargo
Version: 0.57.0-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cargo fails to cross build from source, because it happens to also build
a native cargo and thus needs a native zlib (-lz) library. This is
presently missing in Build-Depends. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru cargo-0.57.0/debian/changelog cargo-0.57.0/debian/changelog
--- cargo-0.57.0/debian/changelog   2022-05-02 22:57:46.0 +0200
+++ cargo-0.57.0/debian/changelog   2022-09-10 11:07:48.0 +0200
@@ -1,3 +1,10 @@
+cargo (0.57.0-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: zlib1g-dev:native. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 10 Sep 2022 11:07:48 +0200
+
 cargo (0.57.0-7) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru cargo-0.57.0/debian/control cargo-0.57.0/debian/control
--- cargo-0.57.0/debian/control 2022-05-02 22:57:07.0 +0200
+++ cargo-0.57.0/debian/control 2022-09-10 11:07:48.0 +0200
@@ -23,6 +23,7 @@
  libhttp-parser-dev,
  libssl-dev,
  zlib1g-dev,
+ zlib1g-dev:native,
  git 
 Homepage: https://crates.io/
 Standards-Version: 4.2.1

Bug#1019490: ndctl FTCBFS: multiple reasons

[Helmut Grohne]

Source: ndctl
Version: 73-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ndctl regressed cross building. It added a meson check using cc.runs to
test for typeof. Such tests make cross builds fail. However, the test
can be easily rewritten as a compile check. Beyond that, debian/rules
confuses the terms "build" and "host". Please refer to man
dpkg-architecture for their definitions. I'm attaching a patch that
fixes both for your convenience.

Helmut
diff --minimal -Nru ndctl-74/debian/changelog ndctl-74/debian/changelog
--- ndctl-74/debian/changelog   2022-08-24 12:53:47.0 +0200
+++ ndctl-74/debian/changelog   2022-09-10 06:31:41.0 +0200
@@ -1,3 +1,12 @@
+ndctl (74-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Avoid an unnecessary compiler run test.
++ Fix confusion of build and host.
+
+ -- Helmut Grohne   Sat, 10 Sep 2022 06:31:41 +0200
+
 ndctl (74-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru ndctl-74/debian/patches/cross.patch 
ndctl-74/debian/patches/cross.patch
--- ndctl-74/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100
+++ ndctl-74/debian/patches/cross.patch 2022-09-10 06:31:39.0 +0200
@@ -0,0 +1,26 @@
+--- ndctl-74.orig/meson.build
 ndctl-74/meson.build
+@@ -231,19 +231,18 @@
+ conf.set('ENABLE_LOGGING', get_option('logging').enabled())
+ conf.set('ENABLE_DEBUG', get_option('dbg').enabled())
+ 
+-typeof = cc.run('''
+-  int main() {
++typeof_code = '''
++  void func() {
+ struct {
+   char a[16];
+ } x;
+ typeof(x) y;
+ 
+-return sizeof(x) == sizeof(y);
++char static_assert[2 * (sizeof(x) == sizeof(y)) - 1];
+   }
+   '''
+-)
+ 
+-if typeof.compiled() and typeof.returncode() == 1
++if cc.compiles(typeof_code)
+   conf.set('HAVE_TYPEOF', 1)
+   conf.set('HAVE_STATEMENT_EXPR', 1)
+ endif
diff --minimal -Nru ndctl-74/debian/patches/series 
ndctl-74/debian/patches/series
--- ndctl-74/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ ndctl-74/debian/patches/series  2022-09-10 06:25:33.0 +0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru ndctl-74/debian/rules ndctl-74/debian/rules
--- ndctl-74/debian/rules   2022-08-24 12:21:41.0 +0200
+++ ndctl-74/debian/rules   2022-09-10 06:31:41.0 +0200
@@ -27,7 +27,7 @@
dh_installinit -p ndctl --init-script=ndctl-monitor
 
 override_dh_install:
-   mv debian/tmp/usr/$(DEB_BUILD_MULTIARCH)/* 
debian/tmp/usr/lib/$(DEB_BUILD_MULTIARCH)/
+   mv debian/tmp/usr/$(DEB_HOST_MULTIARCH)/* 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
dh_install
 
 override_dh_makeshlibs:

Bug#1019489: mark python3-dateutil Multi-Arch: foreign

[Helmut Grohne]

Package: python3-dateutil
Version: 2.8.1-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:389-ds-base src:abinit src:amp src:ariba src:arpys 
src:astropy src:astropy-healpix src:astropy-regions src:astroscrappy 
src:basemap src:beancount src:bioxtasraw src:borgbackup src:bornagain src:brian 
src:cadabra2 src:calibre src:casa-formats-io src:cctbx src:cfgrib src:cnvkit 
src:cpl-plugin-amber src:cpl-plugin-fors src:cpl-plugin-giraf 
src:cpl-plugin-hawki src:cpl-plugin-muse src:cpl-plugin-naco 
src:cpl-plugin-uves src:cpl-plugin-vimos src:cpl-plugin-visir 
src:cpl-plugin-xshoo src:deap src:dioptas src:dipy src:direnv src:epigrass 
src:facet-analyser src:fast-histogram src:fence-agents src:fiona src:freeart 
src:freecad src:freesas src:galpy src:gammapy src:gensim src:genx src:gpaw 
src:gpsd src:gr-radar src:graph-tool src:gudhi src:guiqwt src:healpy src:hinge 
src:hkl src:htseq src:hyperspy src:imexam src:iminuit src:intake src:kallisto 
src:libcxx-serial src:lmod src:matplotlib src:mdanalysis src:mdtraj src:meep 
src:mlpack src:mrpt src:mypaint src:nipy src:numpy src:opendrop 
src:openstructure src:pandas src:paraview src:photutils src:picard src:pikepdf 
src:promod3 src:psd-tools src:psi4 src:pybdsf src:pycorrfit src:pydevd 
src:pyerfa src:pyfai src:pygac src:pykwalify src:pymatgen src:pymca src:pyraf 
src:pyregion src:pyresample src:pyrle src:pyrsistent src:pyscanfcs src:pysolid 
src:pysynphot src:python-argon2 src:python-biom-format src:python-biopython 
src:python-cartopy src:python-cdo src:python-clevercsv 
src:python-clickhouse-driver src:python-cobra src:python-cogent src:python-cpl 
src:python-cryptography src:python-csa src:python-cython-blis src:python-datrie 
src:python-dicompylercore src:python-drizzle src:python-escript 
src:python-fabio src:python-feather-format src:python-geotiepoints 
src:python-ltfatpy src:python-memprof src:python-nacl src:python-pomegranate 
src:python-pyani src:python-pybedtools src:python-pygraphviz src:python-pyproj 
src:python-questplus src:python-shapely src:python-skbio src:python-sqt 
src:python-thinc src:python-wordcloud src:python-xmlsec src:python-zstandard 
src:pywavelets src:pyxrd src:q2-cutadapt src:q2-dada2 src:q2-metadata src:qgis 
src:qiskit-terra src:qutip src:rasterio src:rdkit src:reproject src:rocketcea 
src:ros-actionlib src:ros-bond-core src:ros-class-loader src:ros-collada-urdf 
src:ros-common-msgs src:ros-diagnostics src:ros-dynamic-reconfigure 
src:ros-geometric-shapes src:ros-geometry src:ros-geometry2 
src:ros-image-common src:ros-image-pipeline src:ros-interactive-markers 
src:ros-kdl-parser src:ros-laser-geometry src:ros-message-runtime 
src:ros-navigation-msgs src:ros-nodelet-core src:ros-opencv-apps 
src:ros-pcl-msgs src:ros-perception-pcl src:ros-random-numbers 
src:ros-resource-retriever src:ros-robot-state-publisher src:ros-ros 
src:ros-ros-comm src:ros-ros-comm-msgs src:ros-rosconsole 
src:ros-rosconsole-bridge src:ros-roscpp-core src:ros-rospack src:ros-rviz 
src:ros-std-msgs src:ros-urdf src:ros-vision-opencv src:ros2-ament-cmake 
src:ros2-ament-index src:ros2-osrf-testing-tools-cpp 
src:ros2-performance-test-fixture src:ros2-rcpputils src:ros2-rcutils 
src:ros2-rosidl src:rpy2 src:sagemath src:sasmodels src:sasview src:scamp 
src:scikit-learn src:sep src:sfepy src:silx src:skimage src:sncosmo 
src:specutils src:statsmodels src:sunpy src:synphot src:tiledb-py 
src:tnseq-transit src:tycho2 src:unifrac src:veusz src:vtk7 src:vtk9 
src:weechat-matrix src:xrayutilities src:yade src:yt

The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on python3-dateutil is not satisfiable. In
general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign or annotated :native. In
this case, I think that the foreign marking is a reasonable compromise.
dateutil is a pure Python module that does not depend on any Python
extensions. Its interpreter dependency is already annotated :any and its
only module dependency (six) is already marked Multi-Arch: foreign.
Technically, the byte compiled objects are architecture-dependent, but a
foreign interpreter can import modules that lack them. Therefore, one
can argue that interfacing with python3-dateutil is entirely
architecture-independent and the foreign marking is warranted. I'm
attaching a patch for your convenience.

Helmut
diff --minimal -Nru python-dateutil-2.8.1/debian/changelog 
python-dateutil-2.8.1/debian/changelog
--- python-dateutil-2.8.1/debian/changelog  2021-07-16 10:51:20.0 
+0200
+++ python-dateutil-2.8.1/debian/changelog  2022-09-10 13:06:04.0 
+0200
@@ -1,3 +1,10 @@
+python-dateutil (2.8.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark python3-dateutils Multi-Arch: foreign (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 10 Sep 2022 13:06:04 +0200
+
 python-dateutil (2.8.1-6) unstable; urgency=medium
 
   [ 

Bug#1019488: bouncycastle: incomplete information in the manifest files

[Sudip Mukherjee]

Source: bouncycastle
Version: 1.71-1
Severity: important
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

The META-INF/MANIFEST.MF file of libbcpg-java contains only the following:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.10.12
Application-Library-Allowable-Codebase: *
Application-Name: Bouncy Castle OpenPGP API
Automatic-Module-Name: org.bouncycastle.pg
Caller-Allowable-Codebase: *
Class-Path: bcprov.jar
Codebase: *
Created-By: 11.0.15+10-post-Debian-1 (Debian)
Extension-Name: org.bouncycastle.bcpg
Implementation-Vendor: BouncyCastle.org
Implementation-Vendor-Id: org.bouncycastle
Implementation-Version: 1.71.00.0
Permissions: all-permissions
Specification-Vendor: BouncyCastle.org
Specification-Version: 1.1
Trusted-Library: true

Which is incomplete and does not contain all the other required information
like Bundle-Version, Bundle-Name, Export-Package etc. And this lack of 
information
makes the package unusable when using a SimpleConfigurator based bundles.info 
file.

But if I see the jar file in the maven repository I can see the manifest file 
in that
contains all the required information. The jar can be found at:
https://repo1.maven.org/maven2/org/bouncycastle/bcpg-jdk18on/1.71/bcpg-jdk18on-1.71.jar


-- 
Regards
Sudip

Bug#1019239: transition: coq (41 packages involved)

[Julien Puydt]

Hi

Le sam. 10 sept. 2022 à 14:00, Sebastian Ramacher  a
écrit :

>
> coq-stdpp can be installed with any coq version. That will need fixing.
>

The coq version is a non-issue: the libcoq-stdlib dep should already cover
that. I'll look into why it doesn't.

Cheers

J.Puydt

>

Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system

[Erik Ogenvik]

As the main developer of Worldforge I'm perfectly fine with it being
provided as Snap instead of being part of the Debian base packages.
The way development happens makes it not well suited for Debians focus on
stability. We often need to make changes to the protocol that has changes
to the client and server happening in sync.
The Snap allows us to move more quickly, which suits this specific project.

sincerely Erik Ogenvik

Den lör 10 sep. 2022 kl 02:39 skrev Olek Wojnar :

> Control: tag -1 = confirmed
>
> Thanks for reminding me about this bug, tobi! I guess a lot has been
> happening since February of 2020
>
>
> On 8/27/22 08:11, Tobias Frost wrote:
> > User: tobi-rm-proposals@d.o
> > Usertags: rm-proposal
> >
> > (FTR, I also don't think that snap/flatpak/appimage should be pulled by
> an Debian package)
>
> So I did think about what Manuel said although life and world events
> distracted me from replying. I am now of the opinion that although I had
> the best of intentions and (at the time) logical reasons for doing so,
> packaging a Snap is an inherently bad and problematic concept. So, I
> agree with you. :)
>
> > I agree with Olek, Ember (and friends) were always hard to keep floating
> in Debian, so I can
> > understand Oleks' sentiment about maybe using snap… However this can be
> done by the
> > users themselves, there is no need to have a debian package doing so.
>
> Yes... But I got S much great packaging experience from that! ;) In
> all seriousness: yes, I agree, a user can install a Snap and it's a
> waste of time for package maintainers to do so.
>
> > So, maybe, it is time to let ember go and remove it from Debian?
>
> I'd really hate to see that happen but if the code isn't in a stable
> state soon then I'm not sure there will be much of a choice. I've
> reached out to upstream to inquire about the timeline. Depending on that
> response, I'll decide how to move forward. The Ember client hasn't seen
> a release since November 2019 and the Cyphesis server hasn't been
> released since October 2013. A lot has changed since then and neither of
> those releases is maintainable at this point.
>
> Either way, I've marked this bug confirmed because I now fundamentally
> agree with the issue.
>
> > It has no reverse dependencies, so it is save to do so.
> >
> > I'll reassign this bug to ftp.debian.org in 3 months, if there is no
> veto
> > in this bug.
>
> Let's try to figure this out sooner. :)
>
> -Olek
>

Bug#1019239: transition: coq (41 packages involved)

[Sebastian Ramacher]

On 2022-09-10 13:24:56 +0200, Sebastian Ramacher wrote:
> On 2022-09-10 12:59:12 +0200, Julien Puydt wrote:
> > Hi
> > 
> > Le sam. 10 sept. 2022 à 12:12, Sebastian Ramacher  a
> > écrit :
> > 
> > >
> > > The rebuild are now done, but there are some autopkgtest regressions.
> > > They all look like
> > >
> > > https://ci.debian.net/data/autopkgtest/testing/amd64/c/coq-iris/25883605/log.gz
> > > .
> > > Are there some packages that lack the proper dependencies?
> > >
> > 
> > 
> > The fact that the coq-iris package isn't a version 4.0.0-1+b1 isn't normal
> > - I guess my wanna-build script was buggy and didn't give every needed nmu
> > line. (I rewrote it since... the new one should be better...)
> > 
> > I'll need to check the failing packages - probably monday.
> 
> coq-iris also currently FTBFS:
> 
> 
> COQC iris/prelude/options.v
> COQC iris/prelude/prelude.v
> File "./iris/prelude/prelude.v", line 2, characters 0-34:
> Error: File /usr/lib/ocaml/coq/user-contrib/stdpp/prelude.vo has bad version
> number 81500 (expected 81600). It is corrupted or was compiled with another
> version of Coq.
> 
> make[4]: *** [Makefile.coq:793: iris/prelude/prelude.vo] Error 1
> make[3]: *** [Makefile.coq:409: all] Error 2
> 
> I guess there are more packages coq-* that are currently installable
> although that shouldn't be. Otherwise they would turn up red on the
> transition tracker.

coq-stdpp can be installed with any coq version. That will need fixing.

Cheers
-- 
Sebastian Ramacher

Bug#1019486: gdm3: Gdm3 crashes (oh no something has gone wrong)

[Christophe TROESTLER]

Package: gdm3
Version: 42.0-1
Severity: grave
X-Debbugs-Cc: none, Christophe Troestler 

Dear Maintainer,

After the latest update, gdm3 (42.0) starts with the message “oh no something 
has gone wrong”.  =/var/log/syslog= contains the stack trace below.  Note sure 
how to fix this.

Best regards,
Christophe

-

Sep 10 13:31:33 poincare gnome-shell[184978]: libsoup3 symbols detected. Using 
libsoup2 and libsoup3 in the same process is not supported.
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: == Stack trace for 
context 0x55d5b8bbf190 ==
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #0   55d5b8ca6920 i   
resource:///org/gnome/shell/ui/dateMenu.js:377 (14a0de263b00 @ 73)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #1   55d5b8ca6850 i   
resource:///org/gnome/shell/ui/dateMenu.js:352 (14a0de263a10 @ 486)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #2   55d5b8ca67b8 i   
resource:///org/gnome/shell/ui/dateMenu.js:316 (14a0de263d30 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #3   55d5b8ca66c0 i   
resource:///org/gnome/shell/ui/dateMenu.js:944 (14a0de26a790 @ 1329)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #4   55d5b8ca6628 i   
resource:///org/gnome/shell/ui/panelMenu.js:11 (24683107e830 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #5   55d5b8ca6590 i   
resource:///org/gnome/shell/ui/panelMenu.js:97 (24683107eb00 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #6   55d5b8ca64f8 i   
resource:///org/gnome/shell/ui/dateMenu.js:853 (14a0de26a9c0 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #7   55d5b8ca6450 i   
resource:///org/gnome/shell/ui/panel.js:698 (14a0de262970 @ 101)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #8   55d5b8ca6388 i   
resource:///org/gnome/shell/ui/panel.js:709 (14a0de2629c0 @ 109)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #9   55d5b8ca62e8 i   
resource:///org/gnome/shell/ui/panel.js:662 (14a0de2628d0 @ 109)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #10   55d5b8ca6240 i  
 resource:///org/gnome/shell/ui/panel.js:486 (14a0de2623d0 @ 705)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #11   55d5b8ca61a8 i  
 resource:///org/gnome/shell/ui/panel.js:447 (14a0de262c40 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #12   55d5b8ca60f8 i  
 resource:///org/gnome/shell/ui/main.js:228 (36c0410e54c0 @ 663)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #13   55d5b8ca6050 i  
 resource:///org/gnome/shell/ui/main.js:166 (36c0410e5380 @ 324)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #14   55d5b8ca5fc8 i  
 resource:///org/gnome/shell/ui/init.js:6 (36c0410c9290 @ 63)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #15   7ffd87d517d0 b  
 self-hosted:2408 (36c0410a7880 @ 753)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #16   55d5b8ca5ee8 i  
 self-hosted:2355 (36c0410a7830 @ 375)
Sep 10 13:31:33 poincare gnome-session[184930]: gnome-session-binary[184930]: 
WARNING: Application 'org.gnome.Shell.desktop' killed by signal 5
Sep 10 13:31:33 poincare gnome-session[184930]: gnome-session-binary[184930]: 
WARNING: App 'org.gnome.Shell.desktop' respawning too quickly



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (400, 'unstable'), (300, 'stable'), (100, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gdm3 depends on:
ii  accountsservice   22.08.8-1
ii  adduser   3.128
ii  cinnamon [x-window-manager]   5.4.11-1
ii  cinnamon-session [x-session-manager]  5.4.0-1
ii  dbus [default-dbus-system-bus]1.14.0-2
ii  dbus-bin  1.14.0-2
ii  dbus-daemon   1.14.0-2
ii  dconf-cli 0.40.0-3
ii  dconf-gsettings-backend   0.40.0-3
ii  debconf [debconf-2.0] 1.5.79
ii  gir1.2-gdm-1.042.0-1
ii  gnome-session [x-session-manager] 42.0-1
ii  gnome-session-bin 42.0-1+b1
ii  gnome-session-common  42.0-1
ii  gnome-settings-daemon 43~beta-1+b1
ii  gnome-shell   42.4-2
ii  gnome-terminal [x-terminal-emulator]  3.44.1-1
ii  gsettings-desktop-schemas 43~alpha-1
ii  konsole [x-terminal-emulator] 4:22.04.1-1
ii  kwin-x11 [x-window-manager]   4:5.25.4-2
ii  libaccountsservice0   22.08.8-1
ii  libaudit1   

Bug#1019487: libembree-dev should depend on libtbb-dev

[Stephan Lachnit]

Package: libembree-dev
Version: 3.13.4+dfsg-1
Severity: important
Tags: patch
X-Debbugs-Cc: stephanlach...@debian.org

During a rebuild of VecGeom, I noticed that it fails from Embree:

```
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/embree-3.13.4/embree-
config.cmake:53 (FIND_PACKAGE):
  By not providing "FindTBB.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "TBB", but
  CMake did not find one.

  Could not find a package configuration file provided by "TBB" with any of
  the following names:

TBBConfig.cmake
tbb-config.cmake

  Add the installation prefix of "TBB" to CMAKE_PREFIX_PATH or set "TBB_DIR"
  to a directory containing one of the above files.  If "TBB" provides a
  separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  CMakeLists.txt:388 (find_package)


-- Configuring incomplete, errors occurred!
```

This can be simply fixed by adding libtbb-dev to the build dependencies.

However, this dependency should be added to libembree-dev.

Cheers,
Stephan


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 libembree-dev depends on:
ii  libembree3-3  3.13.4+dfsg-1

libembree-dev recommends no packages.

Versions of packages libembree-dev suggests:
pn  embree-tools  

-- no debconf information

Bug#1019485: libvirglrenderer-dev should depend on libva-dev

[Michael Tokarev]

Package: libvirglrenderer-dev
Version: 0.10.1-1
Severity: important

When a package uses libvirglrenderer-dev, it expects the package to be
self-contained, so the build-dependency is specified against only the
package which is actually used, not about its inter-dependencies.
However, the installed libvirglrenderer-dev isn't useable as it is:

meson.build:717:2: ERROR: Could not generate cargs for virglrenderer:
Package libva was not found in the pkg-config search path.
Perhaps you should add the directory containing `libva.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libva', required by 'virglrenderer', not found

This is because virglrenderer.pc refers to libva.pc which is not pulled
in by the dependencies of libvirglrenderer-dev package.

libva-dev should be added to the Depends: field of libvirglrenderer-dev.
Or maybe debian should have a mechanism to track deps of pkgconfig
files somehow, in a way similar to shared libraries.

Severity is important because this causes other packages to FTBFS.
Maybe it shuold be serious instead.

Thanks,

/mjt

Bug#1019335: Reconsider the egrep and fgrep deprecation

[Paul Gevers]

Hi,

On 09-09-2022 23:05, Christoph Berg wrote:

Re: Santiago Ruano Rincón

Changes are ready. I'll upload on Monday.


Thanks!


Indeed. Thanks.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019484: ITP: rust-femme -- pretty-printer and ndjson logger for log crate

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-femme
  Version : 2.2.1
  Upstream Author : Irina Shestak 
* URL : https://github.com/lrlna/femme
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : pretty-printer and ndjson logger for log crate

 Not just a pretty (inter)face.
 .
 femme is a pretty-printer and ndjson logger for the log crate.

This package is needed by rust-kv-log-macro.
It will be maintained in the Debian section of Salsa, at
https://salsa.debian.org/debian/rust-femme

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMcdKwACgkQLHwxRsGg
ASE0dg//W0sEZZIIxNQjY6cT61RET/Tm78RHy407b1ILebPsdrgC3brkzsad7ZF6
541K/J0q20t7+xTw6Dief6LDsVLUZiJDXPVSI3r/TAzlb3Fbgn6aPRy+KFc7u1Q+
2kImsx/6GI3eEHlDWviX29/d8mvOgh8F/x6xHLJAo5+UwH1f70qjPF4arJ8lkVL4
10MEVtG/Jw1KumcmSQKmpSD7MPEuCPafuwK//cLCf74gXNqLLdT4uj6jDpX6CG3M
6GDrHA0PiBG/9fI7H05XArzpPfTMaxTOkQGJiDyVacB3I0zWtQo1Sk/AG8GnUd/p
+IsrLrV627rSCIYL0crPNIU1hgAnbx4KITIORoJQOrPXpQE0ReLiynZhXKZ9XQDU
KSiuXti2O+853w8Tt9iozjUE52ENVO5w7UWgF2CjQJN5gTwDpalSfKm+bLOvI5b5
pwgCOtn9U7UdAn2+EeqZDFKkXBECZ3VyxhfPdkU2XiN7k+UTaPLYd9gv0NHKqjdl
3kMGgcyRjduHecbkH7M96JzLEwnwsfa9yhryD9qBwPxReSQ9IL1hD8o8OufhjCkv
7cY6AF+ng+mZ3MYx3h68tAsjsGAqPrYmEXvY5+mYLZlAASOuxM6CGDhD7UQL1zzW
ZNnRFlhJ5imP90U2raSMjtJ84BjrK2zh6QI2+c2vjac83bQlUjw=
=Gm+3
-END PGP SIGNATURE-

Bug#1019239: transition: coq (41 packages involved)

[Sebastian Ramacher]

On 2022-09-10 12:59:12 +0200, Julien Puydt wrote:
> Hi
> 
> Le sam. 10 sept. 2022 à 12:12, Sebastian Ramacher  a
> écrit :
> 
> >
> > The rebuild are now done, but there are some autopkgtest regressions.
> > They all look like
> >
> > https://ci.debian.net/data/autopkgtest/testing/amd64/c/coq-iris/25883605/log.gz
> > .
> > Are there some packages that lack the proper dependencies?
> >
> 
> 
> The fact that the coq-iris package isn't a version 4.0.0-1+b1 isn't normal
> - I guess my wanna-build script was buggy and didn't give every needed nmu
> line. (I rewrote it since... the new one should be better...)
> 
> I'll need to check the failing packages - probably monday.

coq-iris also currently FTBFS:


COQC iris/prelude/options.v
COQC iris/prelude/prelude.v
File "./iris/prelude/prelude.v", line 2, characters 0-34:
Error: File /usr/lib/ocaml/coq/user-contrib/stdpp/prelude.vo has bad version
number 81500 (expected 81600). It is corrupted or was compiled with another
version of Coq.

make[4]: *** [Makefile.coq:793: iris/prelude/prelude.vo] Error 1
make[3]: *** [Makefile.coq:409: all] Error 2

I guess there are more packages coq-* that are currently installable
although that shouldn't be. Otherwise they would turn up red on the
transition tracker.

Cheers
-- 
Sebastian Ramacher

Bug#1019239: transition: coq (41 packages involved)

[Julien Puydt]

Hi

Le sam. 10 sept. 2022 à 12:12, Sebastian Ramacher  a
écrit :

>
> The rebuild are now done, but there are some autopkgtest regressions.
> They all look like
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/coq-iris/25883605/log.gz
> .
> Are there some packages that lack the proper dependencies?
>


The fact that the coq-iris package isn't a version 4.0.0-1+b1 isn't normal
- I guess my wanna-build script was buggy and didn't give every needed nmu
line. (I rewrote it since... the new one should be better...)

I'll need to check the failing packages - probably monday.

Cheers,

J.Puydt

Bug#1016296: flint: FTBFS: dh_auto_test: error: make -j8 check

[Jerome BENOIT]

ping
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018948: chromium: Main context menu opens in left upper corner of the window

[Krassy Boykinov]

Hey, thank you for the fast response :).

> Am 10.09.2022 um 07:16 schrieb Andres Salomon :
> Thanks for the screenshot. It looks like other people are seeing this with 
> the official chrome package, so that's nice that my wayland build fix wasn't 
> the cause of this bug. :)
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1361832=wayland%20menu=2
> 
> Upstream is updating their wayland libs and doing some other fixes, so 
> hopefully this one will get fixed in the process.
> 
> 
>> On 9/6/22 10:22, Krassy Boykinov wrote:
>> Hello Andreas,
>> 
>> i use gnome-shell (wayland mode). I have attached a screenshot of the 
>> problem.
>> 
>> Best regards

Bug#1019239: transition: coq (41 packages involved)

[Julien Puydt]

Hi

Le sam. 10 sept. 2022 à 12:12, Sebastian Ramacher  a
écrit :

> On 2022-09-06 10:56:14 +0200, julien.pu...@gmail.com wrote:
> > Le mardi 06 septembre 2022 à 09:41 +0200, Sebastian Ramacher a écrit :
> > > Control: tags -1 confirmed
> > >
> > > Please go ahead and let me know once you're done with all the
> > > uploads.
> >
> > "dput *_source.changes" in the directory where I prepared the new
> > uploads just finished.
>
> The rebuild are now done, but there are some autopkgtest regressions.
> They all look like
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/coq-iris/25883605/log.gz
> .
> Are there some packages that lack the proper dependencies?
>

H... It shouldn't even be possible to co-install packages not compiled
with the same coq, so I'll need to dig a bit to understand why the failure
happened this late in the test.

Cheers,

J.Puydt

>

Bug#1019453: ibus: IBus doesn't work correctly in apps that don't support surrounding text

[Gunnar Hjalmarsson]

Control: owner -1 gunna...@debian.org

Thanks for your report, Eberhard.

On 2022-09-09 18:19, Eberhard Beilharz wrote:

A fix a while ago changed the IBUS_CAP_SURROUNDING_TEXT capability to
basically be a compile-time flag. This makes it impossible for ibus
engines to detect whether or not a client supports surrounding text.
This affects for example ibus-engine-keyman with the "IPA (SIL)"
keyboard, which doesn't work correctly in Chromium (which doesn't
support surrounding text).

Upstream bug: https://github.com/ibus/ibus/issues/2354
Upstream fix: https://github.com/ibus/ibus/pull/2436


It would be good with some more input about the approach in your 
upstream PR. Best if it gets merged upstream, of course. So I'm going to 
wait a week or two before adding it as a patch in Debian.


It will be fixed in Debian sid/bookworm and Ubuntu 22.10 (i.e. ibus 
1.5.27) to start with. If it's considered important enough for updating 
stable releases, more paperwork will be needed.


--
Gunnar

Bug#1019239: transition: coq (41 packages involved)

[Sebastian Ramacher]

On 2022-09-06 10:56:14 +0200, julien.pu...@gmail.com wrote:
> Le mardi 06 septembre 2022 à 09:41 +0200, Sebastian Ramacher a écrit :
> > Control: tags -1 confirmed
> > 
> > Please go ahead and let me know once you're done with all the
> > uploads.
> 
> "dput *_source.changes" in the directory where I prepared the new
> uploads just finished.

The rebuild are now done, but there are some autopkgtest regressions.
They all look like
https://ci.debian.net/data/autopkgtest/testing/amd64/c/coq-iris/25883605/log.gz.
Are there some packages that lack the proper dependencies?

Cheers
-- 
Sebastian Ramacher

Bug#1019483: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: schroot
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# Translation of schroot debconf templates to Spanish.
# Copyright (C) 2022 Christoph Biedl
# This file is distributed under the same license as the schroot package.
# 2022 Christoph Biedl , 2022.
#
msgid ""
msgstr ""
"Project-Id-Version: schroot\n"
"Report-Msgid-Bugs-To: schr...@packages.debian.org\n"
"POT-Creation-Date: 2022-08-15 20:51+0200\n"
"PO-Revision-Date: 2022-08-27 14:56+0200\n"
"Language-Team: Debian L10n Spanish \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"
"Last-Translator: Camaleón \n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"Language: es\n"

#. Type: note
#. Description
#: ../schroot.templates:1001
msgid "Stricter rule on chroot names"
msgstr "Reglas más restrictivas para los nombres en entornos chroot"

#. Type: note
#. Description
#: ../schroot.templates:1001
msgid ""
"Due to stricter rules on the name, the chroots listed below are no longer "
"supported."
msgstr ""
"Debido a reglas más estrictas en los nombres, los siguientes chroot ya no "
"se admiten."

#. Type: note
#. Description
#: ../schroot.templates:1001
msgid " ${LIST}"
msgstr " ${LIST}"

#. Type: note
#. Description
#: ../schroot.templates:1001
msgid ""
"Chroot names must begin with an letter or digit, the remaining characters "
"may additionally be dash ('-'), dot ('.'), or underscore ('_')."
msgstr ""
"Los nombres chroot deben comenzar con una letra o un número, para el resto "
"de caracteres también puede usar guión («-»), punto («.») o guión bajo "
"(«_»)."

#. Type: note
#. Description
#: ../schroot.templates:1001
msgid ""
"Please rename or remove them before installing a newer version of schroot.  "
"For instructions, see /usr/share/doc/schroot/NEWS.gz or , starting at \"Major changes in "
"1.6.13\"."
msgstr ""
"Cambiéles el nombre o elimínelos antes de instalar una nueva versión de "
"schroot. Para más información, consulte «/usr/share/doc/schroot/NEWS.gz» o "
"«https://codeberg.org/shelter/reschroot/src/branch/main/NEWS», empezando "
"por «Cambios importantes en la versión 1.6.13»."

Bug#1019482: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: osk-sdl
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# Translation of osk-sdl debconf templates to Spanish.
# Copyright (C) 2022 Osk-sdl packaging team 
# This file is distributed under the same license as the osk-sdl package.
# Camaleón , 2022.
#
msgid ""
msgstr ""
"Project-Id-Version: osk-sdl\n"
"Report-Msgid-Bugs-To: osk-...@packages.debian.org\n"
"POT-Creation-Date: 2022-08-08 09:21+\n"
"PO-Revision-Date: 2022-08-27 13:21+0200\n"
"Language-Team: Debian L10n Spanish \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"
"Last-Translator: Camaleón \n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"Language: es\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Automatically clean crypttab?"
msgstr "¿Limpiar automáticamente crypttab?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Selecting this will result in instances of 'osk-sdl-keyscript'  being "
"removed from /etc/crypttab on package removal."
msgstr ""
"Si elige esta opción, las instancias de «osk-sdl-keyscript» se "
"borrarán de «/etc/crypttab» cuando elimine el paquete."

Bug#1019481: ITP: rust-kv-log-macro -- kv-log-macro is a log macro for log's kv-unstable backend.

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-kv-log-macro
  Version : 1.0.7
  Upstream Author : Yoshua Wuyts 
* URL : https://github.com/yoshuawuyts/kv-log-macro
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : log macro for log's kv-unstable backend

 kv-log-macro is a log macro for log's kv-unstable backend.

This package is needed by rust-async-std.
It will be maintained in the Debian section of Salsa, at
https://salsa.debian.org/debian/rust-kv-log-macro

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMcXm0ACgkQLHwxRsGg
ASGjwg//equwkN+PM/zrNorlZe8Ij9bEeCMG1K7uA1JCrBr35MFkRRd7uo4Q5Rbx
MqGYuskZzo2SbMIfFTFnCB7yWF89p+oyN07kZcHxFs5ekRDW6lz3iPtphv9MDHQ4
f1yt65PfR8pjOGegf/DspLeRJN166YhjkkvrOaVi+7irzpXDRFc3sOaVhZld3sY+
CTSbzMzgdU5e8Vysaa7ltbXNAdvSDsVVXoNTN0tVnKQjKlYBJddpvP/8X5XZhRjj
9kWnZXhtqzmWgEl0zxMTk8t0merngSuZthy/gGdH4UAHINZoSMF2oN9XQ3SbVsmR
9XIdlY7LMgjxPYKZZ7Q6p5sD9lmD9ExdLM1MeZufZCQ9/bLj2CPTU1vvltYE+ruz
f1GtLQyB20rIhz7aeA864YeKFGwbH/TAvPmrpkyx6zQboRefBmkWyjZE7FoOSzEl
ij/TuA9eKZRgtsUgrdrzym0rGg/eo3Goy/cDaDHB6fEcc14w7HLE9B1xTiN0OS7k
C51xMFApt7yR58bIdyaZs3zq69MHoS9NPmKObTsUe3LnFiQ3gKcCU9cP8+OOte1G
ltWihC8qLCipxC7iQnZ1XtawznFrdYIwnNHjxYCMmiHIWHl305iBqLeDmpHbOiLA
94DnNZxvw7zjFbmlcZAb+3UbjXqNJfoObxB1Qtrzae+LPnqg9Bo=
=4Gx8
-END PGP SIGNATURE-

Bug#1019480: initscripts: wrong filename test (/etc/rc.local.shutdown) in init.d/rc.local

[Mark Hindley]

Patrice,

Thanks for spotting this typo.

I will upload a fixed version later today.

Mark

Bug#1019064: Transition KDE PIM 22.08

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/kdepim-22.08.html

On 2022-09-03 16:32:29 +0200, Patrick Franz wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: delta...@debian.org, debian-qt-...@lists.debian.org
> 
> Hi Release team,
> 
> we would like to request a transition for KDE PIM 22.08.
> 
> We have uploaded KDE PIM 22.08 to experimental, but since KDE PIM
> does not provide ABI stability and some packages outside of
> KDE PIM depend on it, we need a transition.
> 
> The packages depending on KDE PIM are:
> 
> * digikam
> * kgpg
> * kio-gdrive
> * kjots
> * kmymoney
> * kraft
> * zanshin
> 
> I've uploaded a fix for kjots to build against KDE PIM 22.08, but all
> other packages should just need a rebuild.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1019480: initscripts: wrong filename test (/etc/rc.local.shutdown) in init.d/rc.local

[Patrice DUROUX]

Package: initscripts
Version: 3.05-2
Severity: normal

Dear Maintainer,

The corresponding file provided by the package is currently: /etc/rc.shutdown
Isn't it?

Regards,
Patrice

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

Kernel: Linux 5.17.0-2-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 initscripts depends on:
ii  lsb-base  11.2
ii  sysv-rc   3.05-2

Versions of packages initscripts recommends:
ii  e2fsprogs  1.46.5-2
ii  psmisc 23.5-3

initscripts suggests no packages.

-- no debconf information

Bug#1019479: ITP: rust-async-std -- async version of the Rust standard library

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-async-std
  Version : 1.12.0
  Upstream Author : Stjepan Glavina  and more
* URL : https://async.rs/
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : async version of the Rust standard library

 async-std is a library
 that looks and feels like the Rust standard library,
 except everything in it is made to work with async/await
 exactly as you would expect it to.

This package is needed by rust-criterion.
It will be maintained in the Debian section of Salsa, at
https://salsa.debian.org/debian/rust-async-std

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMcVpYACgkQLHwxRsGg
ASFWmg/+NwUatUny1Hv+VuYmWqH0kNQaSJMZo7jrD0/5oSjcAFEFNsDQhnpairAR
We52Qqds0m9a90A/w9FSjJnHrBfexmOJ9w0Nho4V9KcEat7Ia18GqS0G/REvr4QF
xJj2pV2WRHz0cuegc711tT1W8qbOPKvz7D6MhzlrrGHB7z3Jj2mCp2Am9UBW7Nov
TD/6cw31aDbZpnxmBJUys/UmEdkycg4fa0SBg5jQGtvWO2Vj1ifPnPlF+YV2Djh9
2JnBkydYDeE0eU9C81b9h0BFvC0fR9VWe6XKFLwHC3NePhC+CIka9NU6ANjvOAzb
PPHFMNiS7dgr5+Ke7Jd4j1g3BEOloS1m1Mr2MYFY46g3SybSMk/dNcxMVe7L1TQN
XMAzr6hjC/dqpjapiXvK4eW66rfgBKN9M0PEnGWXVF3skbvmWKRyIP/6tu8DtAVz
DDOOjuR/256gM5fEEqHWNRxaufg+m0rQEKFgvegv8K4aiTu5qL9JfzQxBph/6AsM
qEnmg0vhNK9RP77eNE06uXmlbXIDJx06Bu2MdrkzhjK4lelJ50OtwCuSdSlt99Px
1X42PlmOP4JLRSQa/JjzBUpz4nUaUNK0Or7EPVFt8oOpRw3wLq4PsVhQbiPqX5Um
YI0UHlmTO9nb91Fs74suS5J/USgatRvEGY8Tukd9oLEPx11CIt0=
=XQhF
-END PGP SIGNATURE-

Bug#1019478: libflame: failing numpy tests (avx512) in testing transition tests

[Drew Parsons]

Source: libflame
Version: 5.2.0-3
Severity: normal

libflame 5.2.0-3 in testing is failing numpy tests on amd64 against
scipy 1.8.1-14 fom unstable, affecting the scipy 1.8 upgrade.

The pattern of the failure is strange.  Tests passed with scipy
1.8.1-13 only days before.  Tests in unstable are passing. The failure
is in libflame's numpy test not it's scipy test. But numpy hasn't been
updated. Why has it just now started failing? Maybe it's related to
gcc-12 (which also triggers test failure)?

The error seems to come from numpy's use of avx512 in
TestSharedMemory.test_hidden[CLONGDOUBLE]:

E  compile options: '-I/usr/include/python3.10 
-c'
E  extra options: '-mavx512er -mavx512pf'
E  CCompilerOpt.feature_test[1466] : testing 
feature 'AVX512_KNL' with flags (-msse -msse2 -msse3 -mssse3 -msse4.1 -mpopcnt 
-msse4.2 -mavx -mf16c -mfma -mavx2 -mavx512f -mavx512cd -mavx512er -mavx512pf)
E  C compiler: x86_64-linux-gnu-gcc 
-Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC
E  
E  compile options: '-I/usr/include/python3.10 
-c'
E  extra options: '-msse -msse2 -msse3 -mssse3 
-msse4.1 -mpopcnt -msse4.2 -mavx -mf16c -mfma -mavx2 -mavx512f -mavx512cd 
-mavx512er -mavx512pf -Werror'
E  CCompilerOpt.dist_test[581] : 
CCompilerOpt._dist_test_spawn[716] : Command (x86_64-linux-gnu-gcc 
-Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.10 -c 
/usr/lib/python3/dist-packages/numpy/distutils/checks/cpu_avx512_knl.c -o 
/tmp/tmpukjc8skw/usr/lib/python3/dist-packages/numpy/distutils/checks/cpu_avx512_knl.o
 -MMD -MF 
/tmp/tmpukjc8skw/usr/lib/python3/dist-packages/numpy/distutils/checks/cpu_avx512_knl.o.d
 -msse -msse2 -msse3 -mssse3 -msse4.1 -mpopcnt -msse4.2 -mavx -mf16c -mfma 
-mavx2 -mavx512f -mavx512cd -mavx512er -mavx512pf -Werror) failed with exit 
status 1 output -> 
E  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/12/include/immintrin.h:51,
E   from 
/usr/lib/python3/dist-packages/numpy/distutils/checks/cpu_avx512_knl.c:14:
E  In function �_mm512_exp2a23_round_pd�,
E  inlined from �main� at 
/usr/lib/python3/dist-packages/numpy/distutils/checks/cpu_avx512_knl.c:21:17:
E  
/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h:55:20: error: 
�__W� is used uninitialized [-Werror=uninitialized]
E 55 |   return (__m512d) 
__builtin_ia32_exp2pd_mask ((__v8df) __A,
E|
^
E 56 |  
  (__v8df) __W,
E|  
  ~
E 57 |  
  (__mmask8) -1, __R);
E|  
  ~~~
E  
/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h: In function 
�main�:
E  
/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h:54:11: note: 
�__W� was declared here
E 54 |   __m512d __W;
E|   ^~~



Also there is the error:

E  compile options: 
'-I/usr/lib/python3/dist-packages/numpy/core/include 
-Ibuild/src.linux-x86_64-3.10/numpy/distutils/include -I/usr/include/python3.10 
-c'
E  extra options: '-msse -msse2 -msse3'
E  x86_64-linux-gnu-gcc: wrapmodule.c
E  x86_64-linux-gnu-gcc: fortranobject.c
E  wrapmodule.c:12:10: fatal error: Python.h: 
No such file or directory
E 12 | #include "Python.h"
E|  ^~
E  compilation terminated.

Bug#1019423: programs

[Rene Engelhard]

Hi,

Am 09.09.22 um 08:56 schrieb Dietmar Czekay:


it's not limited to impress, but also writer, calc

Of course, since window opening is not application-specific but someting 
which belongs into core


Regards,


Rene

Bug#1019423: libreoffice-impress: starting by double click from dolphin results in 1 pixel wide window

[Rene Engelhard]

reassign 1019423 libreoffice-core

found 1019423 1:7.4.1~rc1-3

thanks


Am 09.09.22 um 07:08 schrieb Dietmar:

opening a file (text or spreadsheet) by double click results in a 1 pixel wide
program window. Hovering, the mouse action to resize is accessible and I can
resize the window. But I have to detect the small line, what the window seems
to be.


Tried in a clean sid VM with Plasma (which only had tests done in  GNOME 
so far): Hmm, indeed.



And it seems after that LO remembers the "window size" and gets a 
problem (startcenter only shows the buttons and then when doing writer 
you get the whole window as the size of the button bar)


And lowriter from the terminal and from the menu doesn't work either 
unless you rm -rf the user profile (.config/libreoffice).


Now it becomes weird:

After I did that I removed libreoffice-kf5 (and -qt5) to check whether 
that has any effect it does work. After that  I installed it again and 
it still does work. Even from dolphin...



So I believe something in the user config was wrong to start with and 
rewriting it fixed it...



Regards,


Rene

Bug#1019475: Connecting a HDMI to an external display ends the KDE session and can cause plasmashell to crash and a new "Dynamic user" to get added

[Aurélien COUDERC]

control: -1 tags + wontfix

Le 10 septembre 2022 10:04:14 GMT+02:00, mYnDstrEAm  
a écrit :
>Package: plasma-workspace
>Version: 5.20.5-6
>
>Running Debian11 with KDE with Wayland.
>
>This happens when connecting a second HDMI to the display no matter if that 
>monitor is switched on or off when doing so.

Dear mYnDstrEAm,

thanks for taking the time to report this bug.

Plasma on Wayland is really only provided as a technology preview on Debian 11 
and has many known bugs including stability issues, so I'm marking this bug as 
« wontfix ».

If you really need Wayland you should upgrade to Debian testing, and if you 
really need Debian stable you should stick to the Plasma X11 session.


Happy hacking !
--
Aurélien

Bug#1019477: diet-ng: FTBFS on riscv64 and s390x (unrecognized command line option ‘-main’)

[Eric Long]

Source: diet-ng
Version: 1.8.1-3
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer(s),

We are currently porting packages to riscv64 platform. diet-ng fails to build
on riscv64, s390x and x32 due to unknown option -Wmain in D compiler.

This is the same problems as #944626 [1]. Full buildd log can be found [2].

Attached is a patch that disables testing on riscv64 and s390x as well; I don't
have an x32 environment so I cannot fix it. Please let me know if I missed
anything. 

Cheers,
Eric

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944626
[2]: 
https://buildd.debian.org/status/fetch.php?pkg=diet-ng=riscv64=1.8.1-3=1662361652=0
--- a/meson.build
+++ b/meson.build
@@ -52,10 +52,13 @@
 # Check if machine is arm but not arm64/aarch64
 is_arm = (host_machine.cpu_family().startswith('arm') and host_machine.cpu() 
!= 'arm64')
 
+is_riscv64 = host_machine.cpu() == 'riscv64'
+is_s390x = host_machine.cpu() == 's390x'
+
 #
 # Tests
 #
-if not is_arm
+if not is_arm and not is_riscv64 and not is_s390x
 diet_test_exe = executable('test_diet',
 [diet_src],
 include_directories: [src_dir],

Bug#1019476: libsdl2-2.0-0: Error 404 when trying to install libsdl2-2.0-0 via APT on arch i386

[pascalr0410]

Package: libsdl2-2.0-0
Version: 2.0.14+dfsg2-3
Severity: normal

WHen trying to install wine I have the folowing error :

root@legion:~# apt-get install wine
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
  fonts-wine glib-networking:i386 gstreamer1.0-plugins-base:i386
gstreamer1.0-plugins-good:i386 gstreamer1.0-x:i386 libaa1:i386 libavahi-
client3:i386 libavahi-common-data:i386
  libavahi-common3:i386 libavc1394-0:i386 libbz2-1.0:i386 libcaca0:i386
libcap2:i386 libcapi20-3 libcapi20-3:i386 libcdparanoia0:i386
libcups2:i386
libcurl3-gnutls:i386 libcurl4:i386
  libdb5.3:i386 libdv4:i386 libdw1:i386 libexif12:i386 libfaudio0
libfaudio0:i386 libgd3:i386 libgdbm-compat4:i386 libgdbm6:i386
libglu1-mesa:i386 libgmp10:i386 libgnutls30:i386
  libgphoto2-6:i386 libgphoto2-port12:i386 libgpm2:i386 libgstreamer-
plugins-
base1.0-0:i386 libgstreamer1.0-0:i386 libgudev-1.0-0:i386
libhogweed6:i386
libiec61883-0:i386
  libieee1284-3:i386 liblcms2-2:i386 libldap-2.4-2:i386 libltdl7:i386
libmpg123-0:i386 libncurses6:i386 libncursesw6:i386 libnettle8:i386
libnghttp2-14:i386 libnspr4:i386 libnss3:i386
  libodbc1:i386 libopenal1:i386 liborc-0.4-0:i386 libosmesa6
libosmesa6:i386
libp11-kit0:i386 libpcap0.8:i386 libpci3:i386 libperl5.32:i386
libpoppler-
glib8:i386 libpoppler102:i386
  libproxy1v5:i386 libpsl5:i386 libraw1394-11:i386 librtmp1:i386
libsane1:i386
libsasl2-2:i386 libsasl2-modules:i386 libsasl2-modules-db:i386
libsdl2-2.0-0:i386 libshout3:i386
  libslang2:i386 libsndio7.0:i386 libsnmp40:i386 libsoup2.4-1:i386
libsqlite3-0:i386 libssh2-1:i386 libstb0 libstb0:i386 libtag1v5:i386
libtag1v5-vanilla:i386 libtasn1-6:i386
  libunwind8:i386 libusb-1.0-0:i386 libv4l-0:i386 libv4lconvert0:i386
libvisual-0.4-0:i386 libvkd3d1 libvkd3d1:i386 libwayland-cursor0:i386
libwayland-egl1:i386 libwine libwine:i386
  libxcomposite1:i386 libxcursor1:i386 libxi6:i386 libxkbcommon0:i386
libxpm4:i386 libxrandr2:i386 libxslt1.1:i386 libxv1:i386 wine32:i386
wine64
Paquets suggérés :
  gvfs:i386 libdv-bin:i386 oss-compat:i386 libgd-tools:i386 gdbm-
l10n:i386
gnutls-bin:i386 gphoto2:i386 gpm:i386 libvisual-0.4-plugins:i386
gstreamer1.0-tools:i386 libmyodbc:i386
  odbc-postgresql:i386 tdsodbc:i386 unixodbc-bin:i386
libportaudio2:i386
libraw1394-doc:i386 hplip:i386 libsasl2-modules-gssapi-mit:i386 |
libsasl2-modules-gssapi-heimdal:i386
  libsasl2-modules-ldap:i386 libsasl2-modules-otp:i386 libsasl2-modules-
sql:i386 sndiod:i386 ttf-mscorefonts-installer gstreamer1.0-libav:i386
gstreamer1.0-plugins-bad:i386
  gstreamer1.0-plugins-ugly:i386 ttf-mscorefonts-installer:i386 q4wine
winbind
winetricks playonlinux wine-binfmt exe-thumbnailer | kio-extras
wine32-preloader:i386 wine64-preloader
Les NOUVEAUX paquets suivants seront installés :
  fonts-wine glib-networking:i386 gstreamer1.0-plugins-base:i386
gstreamer1.0-plugins-good:i386 gstreamer1.0-x:i386 libaa1:i386 libavahi-
client3:i386 libavahi-common-data:i386
  libavahi-common3:i386 libavc1394-0:i386 libbz2-1.0:i386 libcaca0:i386
libcap2:i386 libcapi20-3 libcapi20-3:i386 libcdparanoia0:i386
libcups2:i386
libcurl3-gnutls:i386 libcurl4:i386
  libdb5.3:i386 libdv4:i386 libdw1:i386 libexif12:i386 libfaudio0
libfaudio0:i386 libgd3:i386 libgdbm-compat4:i386 libgdbm6:i386
libglu1-mesa:i386 libgmp10:i386 libgnutls30:i386
  libgphoto2-6:i386 libgphoto2-port12:i386 libgpm2:i386 libgstreamer-
plugins-
base1.0-0:i386 libgstreamer1.0-0:i386 libgudev-1.0-0:i386
libhogweed6:i386
libiec61883-0:i386
  libieee1284-3:i386 liblcms2-2:i386 libldap-2.4-2:i386 libltdl7:i386
libmpg123-0:i386 libncurses6:i386 libncursesw6:i386 libnettle8:i386
libnghttp2-14:i386 libnspr4:i386 libnss3:i386
  libodbc1:i386 libopenal1:i386 liborc-0.4-0:i386 libosmesa6
libosmesa6:i386
libp11-kit0:i386 libpcap0.8:i386 libpci3:i386 libperl5.32:i386
libpoppler-
glib8:i386 libpoppler102:i386
  libproxy1v5:i386 libpsl5:i386 libraw1394-11:i386 librtmp1:i386
libsane1:i386
libsasl2-2:i386 libsasl2-modules:i386 libsasl2-modules-db:i386
libsdl2-2.0-0:i386 libshout3:i386
  libslang2:i386 libsndio7.0:i386 libsnmp40:i386 libsoup2.4-1:i386
libsqlite3-0:i386 libssh2-1:i386 libstb0 libstb0:i386 libtag1v5:i386
libtag1v5-vanilla:i386 libtasn1-6:i386
  libunwind8:i386 libusb-1.0-0:i386 libv4l-0:i386 libv4lconvert0:i386
libvisual-0.4-0:i386 libvkd3d1 libvkd3d1:i386 libwayland-cursor0:i386
libwayland-egl1:i386 libwine libwine:i386
  libxcomposite1:i386 libxcursor1:i386 libxi6:i386 libxkbcommon0:i386
libxpm4:i386 libxrandr2:i386 libxslt1.1:i386 libxv1:i386 wine
wine32:i386
wine64
0 mis à jour, 104 nouvellement installés, 0 à enlever et 0 non mis à
jour.
Il est nécessaire de prendre 517 ko/94,8 Mo dans les archives.
Après cette opération, 605 Mo d'espace disque supplémentaires seront
utilisés.
Souhaitez-vous continuer ? [O/n]
Err :1 http://deb.debian.org/debian bullseye/main i386 libsdl2-2.0-0
i386
2.0.14+dfsg2-3
  404  Not Found [IP : 

Bug#1019473: iproute2-doc: Examples from source should be included

[herbert]

Package: iproute2-doc
Version: 5.10.0-4
Severity: normal

The examples from the iproute2 source package should be included
in iproute2-doc.

Thanks,

-- System Information
Debian Release: 11.2
Kernel Version: Linux gwarestrin 5.16.0 #1 SMP PREEMPT Mon Jan 17 13:04:35 AEDT 
2022 x86_64 GNU/Linux

Bug#1019472: RM: mknfonts.tool -- ROM; obsolete

[Yavor Doganov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org

This package is obsolete and now completely unnecessary following the
removal of the GNUstep art backend.  Please remove; thanks.

Bug#1019471: yoshimi: FTBFS on riscv64 (undefined reference to `__atomic_compare_exchange_1')

[Eric Long]

Source: yoshimi
Version: 2.2.2-1
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer(s),

We are currently porting packages to riscv46 platform. yoshimi failed to build
on riscv64 due to not linking to libatomic:

```
[100%] Linking CXX executable yoshimi
/usr/bin/cmake -E cmake_link_script CMakeFiles/yoshimi.dir/link.txt --verbose=1
/usr/bin/c++ -ffast-math -fomit-frame-pointer -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -Wl,-z,relro 
-Wl,-z,now -rdynamic CMakeFiles/yoshimi.dir/Interface/InterChange.cpp.o 
CMakeFiles/yoshimi.dir/Interface/Data2Text.cpp.o 
CMakeFiles/yoshimi.dir/Interface/Text2Data.cpp.o 
CMakeFiles/yoshimi.dir/Interface/MidiLearn.cpp.o 
CMakeFiles/yoshimi.dir/Interface/MidiDecode.cpp.o 
CMakeFiles/yoshimi.dir/CLI/CmdInterface.cpp.o 
CMakeFiles/yoshimi.dir/CLI/CmdInterpreter.cpp.o 
CMakeFiles/yoshimi.dir/Misc/CmdOptions.cpp.o 
CMakeFiles/yoshimi.dir/Misc/Config.cpp.o 
CMakeFiles/yoshimi.dir/Misc/SynthEngine.cpp.o 
CMakeFiles/yoshimi.dir/Misc/Bank.cpp.o 
CMakeFiles/yoshimi.dir/Misc/BuildScheduler.cpp.o 
CMakeFiles/yoshimi.dir/Misc/Microtonal.cpp.o 
CMakeFiles/yoshimi.dir/Misc/Part.cpp.o CMakeFiles/yoshimi.dir/Misc/Splash.cpp.o 
CMakeFiles/yoshimi.dir/Misc/WavFile.cpp.o 
CMakeFiles/yoshimi.dir/Misc/XMLwrapper.cpp.o 
CMakeFiles/yoshimi.dir/Params/ADnoteParameters.cpp.o 
CMakeFiles/yoshimi.dir/Params/EnvelopeParams.cpp.o 
CMakeFiles/yoshimi.dir/Params/FilterParams.cpp.o 
CMakeFiles/yoshimi.dir/Params/LFOParams.cpp.o 
CMakeFiles/yoshimi.dir/Params/SUBnoteParameters.cpp.o 
CMakeFiles/yoshimi.dir/Params/PADnoteParameters.cpp.o 
CMakeFiles/yoshimi.dir/Params/Controller.cpp.o 
CMakeFiles/yoshimi.dir/Params/Presets.cpp.o 
CMakeFiles/yoshimi.dir/Params/PresetsStore.cpp.o 
CMakeFiles/yoshimi.dir/Params/UnifiedPresets.cpp.o 
CMakeFiles/yoshimi.dir/Params/OscilParameters.cpp.o 
CMakeFiles/yoshimi.dir/Synth/ADnote.cpp.o 
CMakeFiles/yoshimi.dir/Synth/Envelope.cpp.o 
CMakeFiles/yoshimi.dir/Synth/LFO.cpp.o 
CMakeFiles/yoshimi.dir/Synth/OscilGen.cpp.o 
CMakeFiles/yoshimi.dir/Synth/SUBnote.cpp.o 
CMakeFiles/yoshimi.dir/Synth/Resonance.cpp.o 
CMakeFiles/yoshimi.dir/Synth/PADnote.cpp.o 
CMakeFiles/yoshimi.dir/DSP/AnalogFilter.cpp.o 
CMakeFiles/yoshimi.dir/DSP/Filter.cpp.o 
CMakeFiles/yoshimi.dir/DSP/FormantFilter.cpp.o 
CMakeFiles/yoshimi.dir/DSP/SVFilter.cpp.o 
CMakeFiles/yoshimi.dir/DSP/Unison.cpp.o 
CMakeFiles/yoshimi.dir/Effects/Alienwah.cpp.o 
CMakeFiles/yoshimi.dir/Effects/Chorus.cpp.o 
CMakeFiles/yoshimi.dir/Effects/Echo.cpp.o 
CMakeFiles/yoshimi.dir/Effects/EffectLFO.cpp.o 
CMakeFiles/yoshimi.dir/Effects/EffectMgr.cpp.o 
CMakeFiles/yoshimi.dir/Effects/Effect.cpp.o 
CMakeFiles/yoshimi.dir/Effects/Phaser.cpp.o 
CMakeFiles/yoshimi.dir/Effects/Reverb.cpp.o 
CMakeFiles/yoshimi.dir/Effects/EQ.cpp.o 
CMakeFiles/yoshimi.dir/Effects/Distorsion.cpp.o 
CMakeFiles/yoshimi.dir/Effects/DynamicFilter.cpp.o 
CMakeFiles/yoshimi.dir/MusicIO/MusicClient.cpp.o 
CMakeFiles/yoshimi.dir/MusicIO/MusicIO.cpp.o 
CMakeFiles/yoshimi.dir/MusicIO/JackEngine.cpp.o 
CMakeFiles/yoshimi.dir/MusicIO/AlsaEngine.cpp.o 
CMakeFiles/yoshimi.dir/PresetsUI.cpp.o CMakeFiles/yoshimi.dir/EnvelopeUI.cpp.o 
CMakeFiles/yoshimi.dir/LFOUI.cpp.o CMakeFiles/yoshimi.dir/FilterUI.cpp.o 
CMakeFiles/yoshimi.dir/VirKeyboardUI.cpp.o 
CMakeFiles/yoshimi.dir/ConfigUI.cpp.o CMakeFiles/yoshimi.dir/SUBnoteUI.cpp.o 
CMakeFiles/yoshimi.dir/ResonanceUI.cpp.o 
CMakeFiles/yoshimi.dir/OscilGenUI.cpp.o CMakeFiles/yoshimi.dir/ADnoteUI.cpp.o 
CMakeFiles/yoshimi.dir/PADnoteUI.cpp.o CMakeFiles/yoshimi.dir/EffUI.cpp.o 
CMakeFiles/yoshimi.dir/BankUI.cpp.o CMakeFiles/yoshimi.dir/PartUI.cpp.o 
CMakeFiles/yoshimi.dir/MicrotonalUI.cpp.o CMakeFiles/yoshimi.dir/MasterUI.cpp.o 
CMakeFiles/yoshimi.dir/MasterMiscUI.cpp.o 
CMakeFiles/yoshimi.dir/ParametersUI.cpp.o 
CMakeFiles/yoshimi.dir/ConsoleUI.cpp.o CMakeFiles/yoshimi.dir/VectorUI.cpp.o 
CMakeFiles/yoshimi.dir/MidiLearnUI.cpp.o 
CMakeFiles/yoshimi.dir/UI/DynamicTooltip.cpp.o 
CMakeFiles/yoshimi.dir/UI/WidgetPDial.cpp.o 
CMakeFiles/yoshimi.dir/UI/WidgetCheckButton.cpp.o 
CMakeFiles/yoshimi.dir/UI/WidgetSpinner.cpp.o 
CMakeFiles/yoshimi.dir/UI/WidgetMWSlider.cpp.o 
CMakeFiles/yoshimi.dir/UI/YoshiWin.cpp.o 
CMakeFiles/yoshimi.dir/UI/MiscGui.cpp.o CMakeFiles/yoshimi.dir/main.cpp.o -o 
yoshimi  -lfontconfig -lfreetype -lfltk_images -lfltk_forms -lfltk_gl -lfltk 
-lSM -lICE -lX11 -lXext -lm -lmxml -lasound -ljack -lfftw3f -lcairo -lncurses 
-lform -lreadline -lz -Wl,-Bstatic -ldl -Wl,-Bdynamic 
/usr/bin/ld: CMakeFiles/yoshimi.dir/Params/PADnoteParameters.cpp.o: in function 
`std::__atomic_base::compare_exchange_strong(bool&, bool, 
std::memory_order, std::memory_order)':
/usr/include/c++/12/bits/new_allocator.h:158: undefined reference to 
`__atomic_compare_exchange_1'
/usr/bin/ld: CMakeFiles/yoshimi.dir/Params/PADnoteParameters.cpp.o: in function 

Bug#1019470: git: Bump version to 2.37.3

[Sedat Dilek]

Package: git
Version: 1:2.37.2-1
Severity: normal
X-Debbugs-Cc: sedat.di...@gmail.com

Dear Maintainer,

please update git to version 2.37.3.
It's a maintenance release containing several bug-fixes.

Thanks.

Best regards,
-Sedat-

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

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

Versions of packages git depends on:
ii  git-man  1:2.37.2-1
ii  libc62.34-7
ii  libcurl3-gnutls  7.85.0-1
ii  liberror-perl0.17029-1
ii  libexpat12.4.8-1
ii  libpcre2-8-0 10.40-1
ii  perl 5.34.0-5
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages git recommends:
ii  ca-certificates  20211016
ii  less 590-1
ii  openssh-client [ssh-client]  1:9.0p1-1+b1
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-9
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
ii  git-email 1:2.37.2-1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information