date:20220520

Hi,

> If multiple Debian users reach out to them, they *might* act after all.

Done with strong words.

Aside from unjustified listing of "ibus" in "Depends:" in ZOOM, Vincent has a 
point.

Need to support user moving from bare XKB setting to ibus's setting.  This side 
of
needs need to be documented since there are many outdated tips for XKB.

Regards,

Osamu

Bug#1011369: transition: gromacs

2022-05-20 Thread Nicholas Breen

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

This is perhaps more of a "recommended best practice" request than a
transition request.

gromacs has an upcoming library transition, staged in experimental, and
its next upload to sid will close one RC bug [1].  However, its only
direct build-dependency in testing is votca-csg, which has a pending RM
request [2].  votca-csg *can* be binNMUed against gromacs 2022.1, but
that's not terribly useful when it's about to be replaced.

Additionally, gromacs upstream dropped support for 32-bit architectures
in the new release, so that will need an additional RM bug for old
binaries, not yet filed.

Should I proceed with an upload to sid when a slot is ready, or wait for
one or both of those removals to clear first?

Thanks.


-- 
Nicholas Breen
nbr...@debian.org


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

Ben file:

title = "gromacs";
is_affected = .depends ~ "libgromacs6" | .depends ~ "libgromacs7";
is_good = .depends ~ "libgromacs7";
is_bad = .depends ~ "libgromacs6";

Bug#1010941: python-argcomplete salvaging and possible team (re)join

2022-05-20 Thread duck


Quack,

On 2022-05-14 04:03, Yaroslav Halchenko wrote:


I have just uploaded to --delayed 5 a workaround fix for #1010941
(FTBFS). The diff is attached


Thanks for the workaround.

I'm going to proceed with the salvaging soon now that the delay has 
passed.

Please give me a few days without NMUs so I can bring it up to shape.


would also be nice to add tags (may be original from Marco?) for prior
upstream/debian releases.


When I made my previous upload I did not realize everything was not in 
the VCS and unfortunately removed past changes. I plan to recreate 
history and add the tags but commits you made will have to be recreated 
on top of them and won't have the same id.


Regards.
\_o<

--
Marc Dequènes

Bug#988540: im-config: breaks the keyboard configuration

2022-05-20 Thread Gunnar Hjalmarsson

The right fix is to make Zoom drop the dependency on ibus. Any feedback 
here on my attempt to do that?


https://devforum.zoom.us/t/annoying-ibus-dependency-in-zoom-deb-files/67293

Was I not clear enough, or not patient enough?

If multiple Debian users reach out to them, they *might* act after all.

--
Gunnar

Bug#988540: im-config: breaks the keyboard configuration

Hi,

> -Original Message-
> From: Vincent Lefevre 
...
> > This happened because ZOOM (this package is external to Debian)
> > provides its DEB package with its "Depends" listing ibus.
> > 
> > It is reasonable for ZOOM to support Chinese and Japanese input and
> > list ibus as dependency. (XKB can't support Chinese nor Japanese
> > input)
> 
> I doubt that support for Chinese and Japanese input is specific to
> Zoom. The dependency should rather be at a higher level in such a
> case (the desktop environment?). But since the issue is in the Zoom
> package, not provided by Debian, nothing can be done here concerning
> this point.

I agree.  There was no need to set "Depends" to "ibus" by ZOOM.  (The best 
option is
"No mention" and the 2nd best option is "Recommends:".)

On default desktop Debian install, GNOME recommends "ibus" via gnome-shell.  So 
there
is no need to force pulling in "ibus".  "ibus" is normally installed.

(I was a bit surprised to see "ibus" instead of an alternative input method 
framework
"fcitx" here.  As I remember, Zoom was started by chinese ex-patriots in USA 
and used
some servers in China to service ZOOM.  This raised security concern during the
initial COVID-19 crisis.  Although the upstream authors of both programs seem 
to have
Chinese name, generally fcitx is more popular with Chinese speaking people.  I 
don't
know if ZOOM has issue with fcitx)

> OK. But note that an important part of the issue was that it took me
> some time to figure out what was going on: I could notice the breakage
> only after logging in again one week later, and I didn't know that this
> was related to ibus and im-config (which I had never heard of before,
> and I probably forgot that they had been installed). The fact that
> I didn't get a warning or an error message in the first place is not
> nice, leaving the user in the dark.

We can't create random monkey patch to warn user.  I am afraid it will be 
complicated
and unmaintainable.

This is somewhat like some European language user sometimes still insists to 
have
Latin1 encoding instead of UTF-8.  (Or sysvinit instead of systemd).  
Transition is
always painful.

Of course, if I get a clean set of code as a patch, I will merge it.  Scanning 
user's
home directory is messy task I am not so keen to pursue.

What I suggest is write up best practice of XKB input transition to ibus in a 
page
wiki.debian.org.  Then create wishlist bug report to ibus asking to add pointer 
to
the wiki page mentioned in README.Debian.  You can be the best person to do 
this ;-)

> > For both ibus and im-config, the desirable user experience can be
> > provided by proper user configuration.
> > 
> > So there is no bug on im-config's parts.
> 
> IMHO, the user's .xsession file shouldn't be run before im-config has
> loaded its configuration.

Without im-config, people used the user's .xsession to set up input method.  im-
config honor such setting by checking some environment variables.  If there is 
such a
marker variable for XKB, we can disable ibus if someone write patch. 

Osamu

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

2022-05-20 Thread Andy Simpkins

On 20 May 2022 15:11:09 BST, Zhang Boyang  wrote:
>Package: debian-cd
>
>Hello,
>
>I suggest debian release a new variant of ISO images, the all-in-one images. 
>These all-in-one image contains ALL debian packages in a single ISO image 
>(possibly all source packages in another all-in-one ISO image). Of course 
>there is no such optical media can hold such a big image, but it is useful for 
>virtual-machines, remotely managed servers, and archival purposes. The 
>theoretical size limit of an ISO9660 filesystem is about 8TB, which is 
>sufficient for including all debian packages.
>
>For the name of this variant, I suggest 'everything', 'allinone', 'world', 
>'virt'.
>
>p.s. This is my personal interest, and I would appreciate if you can kindly 
>consider my suggestion.
>
>
>Best Regards,
>Zhang Boyang
>
>

Sorry to put a dampener on your suggestion but why would you need that?

Why not just mirror the archive to a local disk instead?

Then you have your copy of everything and can just point a netinst at your 
local mirror so you can install from there.

I think that would deliver on every use case that you would be able to use your 
big ISO image and more

Bug#1006391: NMU: libengine-gost-openssl1.1: FTBFS with OpenSSL 3.0


The right thing to do to solve this would be importing the new release.
I NMU this with the already existing Ubuntu patches so it does not block the 
openssl migration.

As the package seems to be abandoned, add already handed-in cross-compile patch 
as well.
The debidff is enclosed.diff -Nru libengine-gost-openssl1.1-1.1.0.3/debian/changelog 
libengine-gost-openssl1.1-1.1.0.3/debian/changelog
--- libengine-gost-openssl1.1-1.1.0.3/debian/changelog  2018-09-16 
17:58:16.0 +0200
+++ libengine-gost-openssl1.1-1.1.0.3/debian/changelog  2022-05-21 
00:33:51.0 +0200
@@ -1,7 +1,23 @@
+libengine-gost-openssl1.1 (1.1.0.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/watch: Scan GitHub tags.
+
+  [ Helmut Grohne ]
+  * Fix openssl engine path for cross compilation (Closes: #966642).
+
+  [ Simon Chopin ]
+  * Stopgap patches for OpenSSL3 before migrating to provider API:
+- d/rules: downgrade deprecation errors to warnings to fix the build
+  against OpenSSL 3 (Closes: #1006391)
+- d/p/OpenSSL3.patch: Fix several const-correctness issues introduced
+  by OpenSSL 3 API changes.
+
+ -- Bastian Germann   Sat, 21 May 2022 00:33:51 +0200
+
 libengine-gost-openssl1.1 (1.1.0.3-1) unstable; urgency=medium
 
   * New upstream version
-
   * Closes: #898823, #906734
 
  -- Wartan Hachaturow   Sun, 16 Sep 2018 18:58:16 +0300
diff -Nru libengine-gost-openssl1.1-1.1.0.3/debian/patches/OpenSSL3.patch 
libengine-gost-openssl1.1-1.1.0.3/debian/patches/OpenSSL3.patch
--- libengine-gost-openssl1.1-1.1.0.3/debian/patches/OpenSSL3.patch 
1970-01-01 01:00:00.0 +0100
+++ libengine-gost-openssl1.1-1.1.0.3/debian/patches/OpenSSL3.patch 
2022-05-21 00:28:56.0 +0200
@@ -0,0 +1,31 @@
+--- a/gost_ameth.c
 b/gost_ameth.c
+@@ -635,7 +635,7 @@
+ }
+ 
+ /* -- Public key functions * --*/
+-static int pub_decode_gost_ec(EVP_PKEY *pk, X509_PUBKEY *pub)
++static int pub_decode_gost_ec(EVP_PKEY *pk, const X509_PUBKEY *pub)
+ {
+ X509_ALGOR *palg = NULL;
+ const unsigned char *pubkey_buf = NULL;
+--- a/gost_pmeth.c
 b/gost_pmeth.c
+@@ -53,7 +53,7 @@
+ }
+ 
+ /* Copies contents of gost_pmeth_data structure */
+-static int pkey_gost_copy(EVP_PKEY_CTX *dst, EVP_PKEY_CTX *src)
++static int pkey_gost_copy(EVP_PKEY_CTX *dst, const EVP_PKEY_CTX *src)
+ {
+ struct gost_pmeth_data *dst_data, *src_data;
+ if (!pkey_gost_init(dst)) {
+@@ -499,7 +499,7 @@
+ OPENSSL_free(data);
+ }
+ 
+-static int pkey_gost_mac_copy(EVP_PKEY_CTX *dst, EVP_PKEY_CTX *src)
++static int pkey_gost_mac_copy(EVP_PKEY_CTX *dst, const EVP_PKEY_CTX *src)
+ {
+ struct gost_mac_pmeth_data *dst_data, *src_data;
+ if (!pkey_gost_mac_init(dst)) {
diff -Nru libengine-gost-openssl1.1-1.1.0.3/debian/patches/series 
libengine-gost-openssl1.1-1.1.0.3/debian/patches/series
--- libengine-gost-openssl1.1-1.1.0.3/debian/patches/series 1970-01-01 
01:00:00.0 +0100
+++ libengine-gost-openssl1.1-1.1.0.3/debian/patches/series 2022-05-21 
00:28:56.0 +0200
@@ -0,0 +1 @@
+OpenSSL3.patch
diff -Nru libengine-gost-openssl1.1-1.1.0.3/debian/rules 
libengine-gost-openssl1.1-1.1.0.3/debian/rules
--- libengine-gost-openssl1.1-1.1.0.3/debian/rules  2018-09-16 
17:58:16.0 +0200
+++ libengine-gost-openssl1.1-1.1.0.3/debian/rules  2022-05-21 
00:33:51.0 +0200
@@ -5,6 +5,9 @@
 
 # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/*
 DPKG_EXPORT_BUILDFLAGS = 1
+
+export DEB_CFLAGS_MAINT_APPEND = -Wno-error=deprecated-declarations
+
 include /usr/share/dpkg/default.mk
 
 # see FEATURE AREAS in dpkg-buildflags(1)
@@ -16,7 +19,7 @@
 # package maintainers to append LDFLAGS
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
-OPENSSL_ENGINE_DIR=$(shell openssl version -e |sed -e 's/^[^.]*"//' -e 
's/".*$$//')
+OPENSSL_ENGINE_DIR=$(shell openssl version -e |sed -e 's/^[^.]*"//' -e 
's/".*$$//' -e 's/$(DEB_BUILD_MULTIARCH)/$(DEB_HOST_MULTIARCH)/')
 # main packaging script based on dh7 syntax
 %:
dh $@ 
diff -Nru libengine-gost-openssl1.1-1.1.0.3/debian/watch 
libengine-gost-openssl1.1-1.1.0.3/debian/watch
--- libengine-gost-openssl1.1-1.1.0.3/debian/watch  1970-01-01 
01:00:00.0 +0100
+++ libengine-gost-openssl1.1-1.1.0.3/debian/watch  2022-05-21 
00:33:51.0 +0200
@@ -0,0 +1,2 @@
+version=4
+https://github.com/gost-engine/engine/tags .*/v?(\d\S+)\.tar\.gz

Bug#1011368: RFS: libkdumpfile/0.4.1-1 [ITP] -- Python bindings for libkdumpfile9

2022-05-20 Thread Michel Alexandre Salim

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkdumpfile":

 * Package name: libkdumpfile
   Version : 0.4.1-1
   Upstream Author : Petr Tesarik 
 * URL : https://github.com/ptesarik/libkdumpfile
 * License : LGPL-3+ or GPL-2+
 * Vcs : https://salsa.debian.org/michel/libkdumpfile
   Section : libs

The source builds the following binary packages:

  libkdumpfile-bin - libkdumpfile9 utilities
  libkdumpfile-dev - libkdumpfile9 development libraries and header
files
  libkdumpfile-doc - Kernel coredump file access (documentation)
  libkdumpfile9 - Kernel coredump file access
  python3-libkdumpfile - Python bindings for libkdumpfile9

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/libk/libkdumpfile/libkdumpfile_0.4.1-1.dsc

Changes for the initial release:

 libkdumpfile (0.4.1-1) unstable; urgency=low
 .
   * Initial release (Closes: #1010829)

Regards,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Bug#1010623: more debug info needed

2022-05-20 Thread Thomas Lange



Can you please provide the output of
# lsinitrd /boot/initrd.img-..

on the old and new system?

PLease also create a new temp initrd on the new system to see the log
of the creation process:

# dracut -v /tmp/tempfile

-- 
regards Thomas

Bug#1011367: warzone2100: ftbfs on riscv64 arch (undefined references to `__atomic_exchange_1')

2022-05-20 Thread Bo YU

Source: warzone2100
Version: 4.2.7
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear Maintainer,

The warzone2100 has a ftbfs issue:

```
FAILED: src/warzone2100 
: && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-fstack-protector-strong -fstack-clash-protection -O2 -g -DNDEBUG -Wl,-z,relro 
-Wl,-z,now-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now 
src/CMakeFiles/warzone2100.dir/3rdparty/physfs_memoryio.cpp.o 
src/CMakeFiles/warzone2100.dir/3rdparty/propertymatcher.cpp.o 
src/CMakeFiles/warzone2100.dir/action.cpp.o 
src/CMakeFiles/warzone2100.dir/activity.cpp.o 
src/CMakeFiles/warzone2100.dir/advvis.cpp.o 
src/CMakeFiles/warzone2100.dir/ai.cpp.o 
src/CMakeFiles/warzone2100.dir/animation.cpp.o 
src/CMakeFiles/warzone2100.dir/astar.cpp.o 
src/CMakeFiles/warzone2100.dir/atmos.cpp.o 
src/CMakeFiles/warzone2100.dir/aud.cpp.o 
src/CMakeFiles/warzone2100.dir/baseobject.cpp.o 
src/CMakeFiles/warzone2100.dir/bucket3d.cpp.o 
src/CMakeFiles/warzone2100.dir/challenge.cpp.o 
src/CMakeFiles/warzone2100.dir/chat.cpp.o 
src/CMakeFiles/warzone2100.dir/cheat.cpp.o 
src/CMakeFiles/warzone2100.dir/clparse.cpp.o 
src/CMakeFiles/warzone2100.dir/cmddroid.cpp.o 
src/CMakeFiles/warzone2100.dir/combat.cpp.o 
src/CMakeFiles/warzone2100.dir/component.cpp.o 
src/CMakeFiles/warzone2100.dir/configuration.cpp.o 
src/CMakeFiles/warzone2100.dir/console.cpp.o 
src/CMakeFiles/warzone2100.dir/data.cpp.o 
src/CMakeFiles/warzone2100.dir/design.cpp.o 
src/CMakeFiles/warzone2100.dir/difficulty.cpp.o 
src/CMakeFiles/warzone2100.dir/display.cpp.o 
src/CMakeFiles/warzone2100.dir/display3d.cpp.o 
src/CMakeFiles/warzone2100.dir/droid.cpp.o 
src/CMakeFiles/warzone2100.dir/edit3d.cpp.o 
src/CMakeFiles/warzone2100.dir/effects.cpp.o 
src/CMakeFiles/warzone2100.dir/faction.cpp.o 
src/CMakeFiles/warzone2100.dir/feature.cpp.o 
src/CMakeFiles/warzone2100.dir/fpath.cpp.o 
src/CMakeFiles/warzone2100.dir/frontend.cpp.o 
src/CMakeFiles/warzone2100.dir/game.cpp.o 
src/CMakeFiles/warzone2100.dir/gateway.cpp.o 
src/CMakeFiles/warzone2100.dir/geometry.cpp.o 
src/CMakeFiles/warzone2100.dir/group.cpp.o 
src/CMakeFiles/warzone2100.dir/hci.cpp.o 
src/CMakeFiles/warzone2100.dir/hci/build.cpp.o 
src/CMakeFiles/warzone2100.dir/hci/commander.cpp.o 
src/CMakeFiles/warzone2100.dir/hci/manufacture.cpp.o 
src/CMakeFiles/warzone2100.dir/hci/objects_stats.cpp.o 
src/CMakeFiles/warzone2100.dir/hci/research.cpp.o 
src/CMakeFiles/warzone2100.dir/ingameop.cpp.o 
src/CMakeFiles/warzone2100.dir/init.cpp.o 
src/CMakeFiles/warzone2100.dir/input/context.cpp.o 
src/CMakeFiles/warzone2100.dir/input/debugmappings.cpp.o 
src/CMakeFiles/warzone2100.dir/input/keyconfig.cpp.o 
src/CMakeFiles/warzone2100.dir/input/manager.cpp.o 
src/CMakeFiles/warzone2100.dir/input/mapping.cpp.o 
src/CMakeFiles/warzone2100.dir/intdisplay.cpp.o 
src/CMakeFiles/warzone2100.dir/intelmap.cpp.o 
src/CMakeFiles/warzone2100.dir/intimage.cpp.o 
src/CMakeFiles/warzone2100.dir/intorder.cpp.o 
src/CMakeFiles/warzone2100.dir/keybind.cpp.o 
src/CMakeFiles/warzone2100.dir/keyedit.cpp.o 
src/CMakeFiles/warzone2100.dir/level_lexer.cpp.o 
src/CMakeFiles/warzone2100.dir/levels.cpp.o 
src/CMakeFiles/warzone2100.dir/lighting.cpp.o 
src/CMakeFiles/warzone2100.dir/loadsave.cpp.o 
src/CMakeFiles/warzone2100.dir/loop.cpp.o 
src/CMakeFiles/warzone2100.dir/main.cpp.o 
src/CMakeFiles/warzone2100.dir/map.cpp.o 
src/CMakeFiles/warzone2100.dir/mapdisplay.cpp.o 
src/CMakeFiles/warzone2100.dir/mapgrid.cpp.o 
src/CMakeFiles/warzone2100.dir/mechanics.cpp.o 
src/CMakeFiles/warzone2100.dir/message.cpp.o 
src/CMakeFiles/warzone2100.dir/miscimd.cpp.o 
src/CMakeFiles/warzone2100.dir/mission.cpp.o 
src/CMakeFiles/warzone2100.dir/modding.cpp.o 
src/CMakeFiles/warzone2100.dir/move.cpp.o 
src/CMakeFiles/warzone2100.dir/multibot.cpp.o 
src/CMakeFiles/warzone2100.dir/multigifts.cpp.o 
src/CMakeFiles/warzone2100.dir/multiint.cpp.o 
src/CMakeFiles/warzone2100.dir/multijoin.cpp.o 
src/CMakeFiles/warzone2100.dir/multilimit.cpp.o 
src/CMakeFiles/warzone2100.dir/multilobbycommands.cpp.o 
src/CMakeFiles/warzone2100.dir/multimenu.cpp.o 
src/CMakeFiles/warzone2100.dir/multiopt.cpp.o 
src/CMakeFiles/warzone2100.dir/multiplay.cpp.o 
src/CMakeFiles/warzone2100.dir/multistat.cpp.o 
src/CMakeFiles/warzone2100.dir/multistruct.cpp.o 
src/CMakeFiles/warzone2100.dir/multisync.cpp.o 
src/CMakeFiles/warzone2100.dir/musicmanager.cpp.o 
src/CMakeFiles/warzone2100.dir/nethelpers.cpp.o 
src/CMakeFiles/warzone2100.dir/notifications.cpp.o 
src/CMakeFiles/warzone2100.dir/objects.cpp.o 
src/CMakeFiles/warzone2100.dir/objmem.cpp.o 
src/CMakeFiles/warzone2100.dir/oprint.cpp.o 
src/CMakeFiles/warzone2100.dir/order.cpp.o 
src/CMakeFiles/warzone2100.dir/pointtree.cpp.o 
src/CMakeFiles/warzone2100.dir/power.cpp.o 
src/CMakeFiles/warzone2100.dir/projectile.cpp.o 
src/CMakeFiles/warzone2100.dir/qtscript.cpp.o 
src/CMakeFiles/warzone2100.dir/quickjs_backend.cpp.o

Bug#1006584: transmission: FTBFS with OpenSSL 3.0


This might be fixed by importing the patches from 
https://github.com/transmission/transmission/pull/1788

Bug#997511: softhsm2: diff for NMU version 2.6.1-2.1

2022-05-20 Thread Ondřej Surý

Hi,

feel free to upload the NMU directly, I think I do have lowNMU threshold set 
(somewhere)

--
Ondřej Surý  (He/Him)

> On 20. 5. 2022, at 23:27, Sebastian Ramacher  wrote:
> 
> Control: tags 997511 + patch
> Control: tags 997511 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for softhsm2 (versioned as 2.6.1-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
> 
> Cheers
> -- 
> Sebastian Ramacher


softhsm2-2.6.1-2.1-nmu.diff
Description: Binary data


signature.asc
Description: Binary data

Bug#1011365: bullseye-pu: package nvidia-cuda-toolkit/11.2.2-3+deb11u2

2022-05-20 Thread Andreas Beckmann

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

Hi,

the nvidia-cuda-toolkit 11.2.2-3+deb11u1 bullseye-pu update
unfortunately updated the bundled openjdk-8 binary snapshot to a version
not runnable on bullseye since it added dependencies on versioned
symbols from a newer glibc.
That was not noticed at build time since dpkg-gensymbols (?) only issued
a warning for the missing symbol version and not an error like for a fully
missing symbol.
We now have a test to ensure the java binary is actually usable ;-)
For amd64 we use a newer binary snapshot built in stretch (lts), for
ppc64el we had to go back to a previously used snapshot and munge the
version a bit.

Another bug was reported for nsight-compute that was looking for some
resources in a different location than where we shipped them.

These bug reports show that there are actually users for these packages
in stable ;-)

The updated package is already uploaded.

Andreas
diff --git a/debian/changelog b/debian/changelog
index 92c791a..f68e95e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+nvidia-cuda-toolkit (11.2.2-3+deb11u2) bullseye; urgency=medium
+
+  * Use a snapshot of openjdk-8-jre (8u332-ga-1~deb9u1) for amd64.
+  * Use a snapshot of openjdk-8-jre (8u302-b08-1) for ppc64el.
+  * Check usability of the java binary.  (Closes: #1008591)
+  * nsight-compute: Move the 'sections' folder to a multiarch location.
+(Closes: #1009719)
+  * Upload to bullseye.
+
+ -- Andreas Beckmann   Fri, 20 May 2022 09:48:41 +0200
+
 nvidia-cuda-toolkit (11.2.2-3+deb11u1) bullseye; urgency=medium
 
   * cuda-gdb: Disable non-functional python support causing segmentation
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 8947feb..438a5c5 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -10,8 +10,9 @@ component = [
'amd64',
'ppc64el',
'arm64',
-   'openjdk-8-source-8u312-b07-1',
-   'openjdk-8-jre-amd64-8u312-b07-1',
-   'openjdk-8-jre-ppc64el-8u312-b07-1',
+   'openjdk-8-source-8u302-b08-1',
+   'openjdk-8-source-8u332-ga-1-d9u1',
+   'openjdk-8-jre-amd64-8u332-ga-1-d9u1',
+   'openjdk-8-jre-ppc64el-8u302-b08-1',
]
 debian-branch = bullseye
diff --git a/debian/nsight-compute.install b/debian/nsight-compute.install
index bb8ddf7..8323707 100755
--- a/debian/nsight-compute.install
+++ b/debian/nsight-compute.install
@@ -3,6 +3,6 @@ nsight_compute/ncu  usr/lib/nsight-compute/
 nsight_compute/ncu-ui  usr/lib/nsight-compute/ [amd64]
 nsight_compute/nv-nsight-cuusr/lib/nsight-compute/ [amd64]
 nsight_compute/nv-nsight-cu-cliusr/lib/nsight-compute/
-nsight_compute/sections/   usr/lib/nsight-compute/
+nsight_compute/sections/   
usr/lib/${DEB_HOST_MULTIARCH}/nsight-compute/
 nsight_compute/extras/ usr/lib/nsight-compute/
 nsight_compute/host/   usr/lib/nsight-compute/ [amd64]
diff --git a/debian/nvidia-openjdk-8-jre.lintian-overrides 
b/debian/nvidia-openjdk-8-jre.lintian-overrides
index 01265ef..b888f3d 100644
--- a/debian/nvidia-openjdk-8-jre.lintian-overrides
+++ b/debian/nvidia-openjdk-8-jre.lintian-overrides
@@ -5,10 +5,9 @@ executable-in-usr-lib
 hardening-no-bindnow
 hardening-no-fortify-functions
 image-file-in-usr-lib
-library-not-linked-against-libc
 package-contains-documentation-outside-usr-share-doc
 package-has-unnecessary-activation-of-ldconfig-trigger
 exit-in-shared-library
 repeated-path-segment
-shared-library-lacks-prerequisites
+[!amd64]: shared-library-lacks-prerequisites
 spelling-error-in-binary
diff --git a/debian/rules b/debian/rules
index 0264dfc..ce9a8b5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -310,6 +310,11 @@ execute_before_dh_auto_build: build-stamp
 override_dh_auto_build-arch:
dh_auto_build --sourcedirectory=cuda-gdb -- V=1
 
+ifneq (,$(jre_pkg))
+execute_before_dh_auto_test-arch:
+   openjdk-8-jre/$(CUDA_JAVA_HOME)/bin/java -version
+endif
+
 execute_before_dh_auto_install:
rm -rf debian/tmp
cp -al build/ debian/tmp
diff --git a/debian/rules.defs b/debian/rules.defs
index 528807a..6c045b4 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -102,7 +102,9 @@ nsight-systems-target.VERSION= 
$(CUDA_VERSION_nsight_systems)
 
 DEFAULT_GCC_VERSION = 10
 
-OPENJDK_VERSION.default = 8u312-b07-1
+OPENJDK_VERSION.default = 8u332-ga-1
+OPENJDK_VERSION.amd64   = 8u332-ga-1~deb9u1
+OPENJDK_VERSION.ppc64el = 8u302-b08-1
 
 NSIGHT_COMPUTE_DESKTOP_DIR.amd64= linux-desktop-glibc_2_11_3-x64
 NSIGHT_COMPUTE_DESKTOP_DIR.i386 = 
linux-desktop-glibc_2_11_3-x86
diff --git a/debian/rules.version_prefix b/debian/rules.version_prefix
index 36c82ed..9194940 100644
---

Bug#1011364: phcpack: FTBFS with gnat-11

Source: phcpack
Version: 2.4.85+dfsg-5
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org


 debian/rules clean
/usr/share/ada/debian_packaging-11.mk:31: *** Please include 
/usr/share/dpkg/default.mk (or the more specific buildflags.mk and 
buildopts.mk) before /usr/share/ada/debian_packaging-11.mk.  Stop.
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2


Cheers
-- 
Sebastian Ramacher

Bug#1011363: transition: dav1d

Control: tags -1 confirmed

On 2022-05-20 23:22:41 +0200, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> Please schedule a transition slot for dav1d.
> 
> The auto-generated ben tracker looks good:
> https://release.debian.org/transitions/html/auto-dav1d.html
> 
> All reverse deps (ffmpeg, libavif, libheif, vlc and xine-lib-1.2)
> build fine with
> the new version in experimental.

Please go ahead

Cheers

> 
> Thanks,
> Dylan
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#997511: softhsm2: diff for NMU version 2.6.1-2.1

Control: tags 997511 + patch
Control: tags 997511 + pending

Dear maintainer,

I've prepared an NMU for softhsm2 (versioned as 2.6.1-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru softhsm2-2.6.1/debian/changelog softhsm2-2.6.1/debian/changelog
--- softhsm2-2.6.1/debian/changelog	2020-05-15 11:41:43.0 +0200
+++ softhsm2-2.6.1/debian/changelog	2022-05-20 23:23:22.0 +0200
@@ -1,3 +1,10 @@
+softhsm2 (2.6.1-2.1) unstable; urgency=medium
+
+  [ William 'jawn-smith' Wilson ]
+  * Disable some tests that are failing with openssl v3 (Closes: #997511)
+
+ -- Sebastian Ramacher   Fri, 20 May 2022 23:23:22 +0200
+
 softhsm2 (2.6.1-2) unstable; urgency=medium
 
   * Explicitly enable ECC and EDDSA curves (Closes: #942419)
diff -Nru softhsm2-2.6.1/debian/patches/0003-fix-ftbfs-with-opensslv3.patch softhsm2-2.6.1/debian/patches/0003-fix-ftbfs-with-opensslv3.patch
--- softhsm2-2.6.1/debian/patches/0003-fix-ftbfs-with-opensslv3.patch	1970-01-01 01:00:00.0 +0100
+++ softhsm2-2.6.1/debian/patches/0003-fix-ftbfs-with-opensslv3.patch	2022-05-20 23:14:03.0 +0200
@@ -0,0 +1,1103 @@
+From 643f061e6fbe04552a2c49bd00528e61a9a77064 Mon Sep 17 00:00:00 2001
+From: Alexander Bokovoy 
+Date: Wed, 26 May 2021 20:03:25 +0300
+Subject: [PATCH 1/4] openssl 3.0: Run DES tests only if OpenSSL allows it
+
+OpenSSL 3.0 moves DES into a legacy provider which has to be loaded
+explicitly. By default, it will not be loaded and DES methods in tests
+will fail. Nest test blocks under successful initialization.
+
+Signed-off-by: Alexander Bokovoy 
+---
+ src/lib/crypto/test/DESTests.cpp | 350 ---
+ 1 file changed, 182 insertions(+), 168 deletions(-)
+
+Index: softhsm2-2.6.1/src/lib/crypto/test/DESTests.cpp
+===
+--- softhsm2-2.6.1.orig/src/lib/crypto/test/DESTests.cpp
 softhsm2-2.6.1/src/lib/crypto/test/DESTests.cpp
+@@ -259,54 +259,58 @@
+ 
+ 			// Now, do the same thing using our DES implementation
+ 			shsmCipherText.wipe();
+-			CPPUNIT_ASSERT(des->encryptInit(, SymMode::CBC, IV));
++			if (des->encryptInit(, SymMode::CBC, IV)) {
+ 
+-			CPPUNIT_ASSERT(des->encryptUpdate(plainText, OB));
+-			shsmCipherText += OB;
++CPPUNIT_ASSERT(des->encryptUpdate(plainText, OB));
++shsmCipherText += OB;
+ 
+-			CPPUNIT_ASSERT(des->encryptFinal(OB));
+-			shsmCipherText += OB;
++CPPUNIT_ASSERT(des->encryptFinal(OB));
++shsmCipherText += OB;
+ 
+-			CPPUNIT_ASSERT(shsmCipherText == cipherText);
++CPPUNIT_ASSERT(shsmCipherText == cipherText);
+ 
+-			// Check that we can get the plain text
+-			shsmPlainText.wipe();
+-			CPPUNIT_ASSERT(des->decryptInit(, SymMode::CBC, IV));
++// Check that we can get the plain text
++shsmPlainText.wipe();
++CPPUNIT_ASSERT(des->decryptInit(, SymMode::CBC, IV));
+ 
+-			CPPUNIT_ASSERT(des->decryptUpdate(shsmCipherText, OB));
+-			shsmPlainText += OB;
++CPPUNIT_ASSERT(des->decryptUpdate(shsmCipherText, OB));
++shsmPlainText += OB;
+ 
+-			CPPUNIT_ASSERT(des->decryptFinal(OB));
+-			shsmPlainText += OB;
++CPPUNIT_ASSERT(des->decryptFinal(OB));
++shsmPlainText += OB;
+ 
+-			CPPUNIT_ASSERT(shsmPlainText == plainText);
++CPPUNIT_ASSERT(shsmPlainText == plainText);
++
++			}
+ 
+ 			// Test 112-bit key
+ 			cipherText = ByteString(testResult[i][j][1]);
+ 
+ 			// Now, do the same thing using our DES implementation
+ 			shsmCipherText.wipe();
+-			CPPUNIT_ASSERT(des->encryptInit(, SymMode::CBC, IV));
++			if (des->encryptInit(, SymMode::CBC, IV)) {
+ 
+-			CPPUNIT_ASSERT(des->encryptUpdate(plainText, OB));
+-			shsmCipherText += OB;
++CPPUNIT_ASSERT(des->encryptUpdate(plainText, OB));
++shsmCipherText += OB;
+ 
+-			CPPUNIT_ASSERT(des->encryptFinal(OB));
+-			shsmCipherText += OB;
++CPPUNIT_ASSERT(des->encryptFinal(OB));
++shsmCipherText += OB;
+ 
+-			CPPUNIT_ASSERT(shsmCipherText == cipherText);
++CPPUNIT_ASSERT(shsmCipherText == cipherText);
+ 
+-			// Check that we can get the plain text
+-			shsmPlainText.wipe();
+-			CPPUNIT_ASSERT(des->decryptInit(, SymMode::CBC, IV));
++// Check that we can get the plain text
++shsmPlainText.wipe();
++CPPUNIT_ASSERT(des->decryptInit(, SymMode::CBC, IV));
+ 
+-			CPPUNIT_ASSERT(des->decryptUpdate(shsmCipherText, OB));
+-			shsmPlainText += OB;
++CPPUNIT_ASSERT(des->decryptUpdate(shsmCipherText, OB));
++shsmPlainText += OB;
+ 
+-			CPPUNIT_ASSERT(des->decryptFinal(OB));
+-			shsmPlainText += OB;
++CPPUNIT_ASSERT(des->decryptFinal(OB));
++shsmPlainText += OB;
++
++CPPUNIT_ASSERT(shsmPlainText == plainText);
++			}
+ 
+-			CPPUNIT_ASSERT(shsmPlainText == plainText);
+ #endif
+ 
+ 			// Test 168-bit key
+@@ -314,27 +318,28 @@
+ 
+ 			// Now, do the same thing using our DES implementation
+ 			shsmCipherText.wipe();
+-			CPPUNIT_ASSERT(des->encryptInit(, SymMode::CBC, IV));
++			if

Bug#1011363: transition: dav1d

2022-05-20 Thread Dylan Aïssi

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

Dear Release Team,

Please schedule a transition slot for dav1d.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-dav1d.html

All reverse deps (ffmpeg, libavif, libheif, vlc and xine-lib-1.2)
build fine with
the new version in experimental.

Thanks,
Dylan

Bug#1011362: network-manager-openconnect: network-manager can't connect to VPNS, GUI says "Error: unable to load VPN connection editor"

2022-05-20 Thread Benjamin Redelings

Package: network-manager-openconnect
Version: 1.2.6-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Using gnome to connect to openconnect VPNS has stopped working.
Also, if you try to edit the VPN through the gnome control panel, you get the 
message

"Error: unabled to load VPN connection editor"

Installing version 1.2.8-2 from experimental seems to fix both problems.

Also see: https://gitlab.gnome.org/GNOME/gtk/-/issues/4740


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

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

Versions of packages network-manager-openconnect depends on:
ii  adduser  3.121
ii  libc62.33-7
ii  libglib2.0-0 2.72.1-1
ii  libnm0   1.38.0-1
ii  libopenconnect5  9.01-1
ii  network-manager  1.38.0-1
ii  openconnect  9.01-1

network-manager-openconnect recommends no packages.

network-manager-openconnect suggests no packages.

-- no debconf information

Bug#866334: About Bug#866334: RFP: lean -- theorem prover from Microsoft Research

2022-05-20 Thread Bill Allombert

On Fri, May 20, 2022 at 07:07:42PM +0100, Julian Gilbey wrote:
> On Fri, May 20, 2022 at 10:59:35PM +0530, Nilesh Patra wrote:
> > On 5/20/22 8:31 PM, Bill Allombert wrote:
> > > On Mon, Sep 16, 2019 at 08:39:56PM +0100, Julian Gilbey wrote:
> > > > I've just started looking at lean.  One of the issues around packaging
> > > > it is that different lean "scripts" (not sure the correct word here)
> > > > require different versions of lean.  There is a script available which
> > > > downloads the required version of lean for any particular script, and
> > > > so keeps a local set of lean versions.
> > > > 
> > > > If we were to package lean for Debian, what exactly would we package?
> > > > The current stable version, or a script such as this?  See
> > > > https://github.com/leanprover-community/mathlib/blob/master/docs/install/debian_details.md
> > > > for a little more on this.
> > > > 
> > > > Thoughts would be appreciated!
> > > 
> > > Lean is now the theorem prover with the largest community, so it would
> > > be nice to have it in Debian. However I do not know how usable it is
> > > outside the visual studio IDE.
> 
> Debian now has the package "elan" which handles installation of Lean;
> this might be sufficient.

Thanks for the tip, I did not know about elan. However installing
software this way really put me off, and it does not seem to install
matlib. Then I found 

(which is  'wget | bash + pip install' variant).

So I feel the RFP to be appropriate, even though probably overwhelming.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#965798: redland: diff for NMU version 1.0.17-1.2

Control: tags 965798 + patch

Dear maintainer,

I've prepared an NMU for redland (versioned as 1.0.17-1.2). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru redland-1.0.17/debian/changelog redland-1.0.17/debian/changelog
--- redland-1.0.17/debian/changelog	2016-12-15 22:47:31.0 +0100
+++ redland-1.0.17/debian/changelog	2022-05-20 22:42:52.0 +0200
@@ -1,3 +1,10 @@
+redland (1.0.17-1.2) unstable; urgency=medium
+
+  [ Sebastien Bacher ]
+  * Update to dh8 to fix the build (Closes: #965798)
+
+ -- Sebastian Ramacher   Fri, 20 May 2022 22:42:52 +0200
+
 redland (1.0.17-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru redland-1.0.17/debian/compat redland-1.0.17/debian/compat
--- redland-1.0.17/debian/compat	2009-12-17 05:17:33.0 +0100
+++ redland-1.0.17/debian/compat	2022-05-20 22:40:45.0 +0200
@@ -1 +1 @@
-5
+8


signature.asc
Description: PGP signature

Bug#1011330: [INTL:sv] Swedish strings for clamsmtp debconf

2022-05-20 Thread Anders Jonsson


Hi Martin,
I made some minor fixes to the po file (mailing list address typo, 
missed space between sentences and another typo).



Regards,
Anders# Translation of clamsmtp debconf template to Swedish
# Copyright (C) 2022 Martin Bagge 
# This file is distributed under the same license as the clamsmtp package.
#
# Daniel Nylander , 2005
# Martin Bagge , 2009, 2022
msgid ""
msgstr ""
"Project-Id-Version: clamsmtp 1.4.1-2\n"
"Report-Msgid-Bugs-To: clams...@packages.debian.org\n"
"POT-Creation-Date: 2018-02-19 18:35+0100\n"
"PO-Revision-Date: 2022-05-20 08:55+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: Swedish\n"
"X-Poedit-Country: Sweden\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Add a clamsmtp system user and group?"
msgstr "Lägg till en systemanvändare och grupp för clamsmtp?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"New installations of clamsmtp install with a system user and group of "
"\"clamsmtp\".  The \"clamav\" user is added to the clamsmtp group to allow "
"the clamav-daemon process to view the quarantine directory.  If this option "
"is set, the installation process will also update the ownership and "
"permissions of the quarantine and run directories."
msgstr ""
"Nya installationer av clamsmtp installeras med systemanvändaren och gruppen "
"\"clamsmtp\".  Användaren \"clamav\" läggs till i gruppen clamsmtp för att "
"tillåta att processen clamav-daemon kan se i karantänmappen.  Om detta "
"alternativ aktiveras kommer installationen även att uppdatera ägarskapet och "
"rättigheterna till karantän- och körmapparna. Om du svarar ja på denna fråga "
"kommer installationen även att uppdatera ägarskap och rättigheter på "
"karantänen och mappen där PID-filen skrivs."

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Fix directory permissions?"
msgstr "Fixa till mapprättigheterna?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"clamsmtpd needs read and write permissions to the virus spool directory, and "
"the run directory in which its PID file is created.  Additionally, the Clam "
"AV daemon must have read access to the spool directory to scan for viruses."
msgstr ""
"clamsmtpd behöver läs- och skrivrättigheter till virus-spoolmappen och kunna "
"köra från den mapp där dess PID-fil är skapad.  ClamAV-daemonen måste också "
"ha läsrättighet till spoolmappen för att skanna efter virus."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"The post-installation script can fix the permissions and ownership of these "
"two directories.  It will consult the /etc/clamsmtpd.conf file for the "
"administratively assigned TempDirectory, PidFile, User, and Group variables, "
"and then update the two directories appropriately."
msgstr ""
"Skriptet som körs efter installationen kan sätta rättigheterna och "
"ägarskapet för dessa två mappar. Skriptet läser filen /etc/clamsmtpd.conf "
"för att hitta värdena för variablerna TempDirectory, PidFile, User, och "
"Group för att sedan uppdatera de två mapparna."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Be sure to check directory permissions after running the init script with "
"the parameters 'start' or 'restart'."
msgstr ""
"Kontrollera rättigheterna för mappen efter att skriptet har körts med "
"parametrarna \"start\" eller \"restart\"."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Purge spool directory on --purge?"
msgstr "Rensa spool-mappen vid --purge ?"

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"The virus spool directory may contain quarantined viruses that can be "
"removed automatically when purging the package."
msgstr ""
"Spool-mappen för virus kan innehålla virus i karantän som kan tas bort "
"automatiskt när paketet tas bort."

Bug#1011187: redis: FTBFS: killed due to inactivity

On 2022-05-18 09:28:56 -0700, Chris Lamb wrote:
> Sebastian Ramacher wrote:
> 
> > E: Build killed with signal TERM after 150 minutes of inactivity
> > [..]
> 
> Hm, I requested a giveback using the automated service and it seems to
> build properly... this time.

The retries on armhf and ppc64el failed again.

Cheers
-- 
Sebastian Ramacher

Bug#1006393: libewf: diff for NMU version 20140807-2.1

Control: tags 1006393 + pending

Dear maintainer,

I've prepared an NMU for libewf (versioned as 20140807-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru libewf-20140807/debian/changelog libewf-20140807/debian/changelog
--- libewf-20140807/debian/changelog	2019-12-03 16:38:28.0 +0100
+++ libewf-20140807/debian/changelog	2022-05-20 22:27:52.0 +0200
@@ -1,3 +1,11 @@
+libewf (20140807-2.1) unstable; urgency=medium
+
+  [ Simon Chopin ]
+  * d/p/OpenSSL3.patch: cherry-picked from upstream to fix the build
+against OpenSSL 3.0 (Closes: #1006393)
+
+ -- Sebastian Ramacher   Fri, 20 May 2022 22:27:52 +0200
+
 libewf (20140807-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru libewf-20140807/debian/patches/OpenSSL3.patch libewf-20140807/debian/patches/OpenSSL3.patch
--- libewf-20140807/debian/patches/OpenSSL3.patch	1970-01-01 01:00:00.0 +0100
+++ libewf-20140807/debian/patches/OpenSSL3.patch	2022-05-20 22:27:02.0 +0200
@@ -0,0 +1,37 @@
+From 033ea5b4e5f8f1248f74a2ec61fc1be183c6c46b Mon Sep 17 00:00:00 2001
+From: Joachim Metz 
+Date: Thu, 18 Nov 2021 06:51:25 +0100
+Subject: [PATCH] Changes for building with OpenSSL 3 #164
+Origin: https://github.com/libyal/libewf/commit/033ea5b4e5f8f1248f74a2ec61fc1be183c6c46b
+
+---
+ ewftools/ewftools_output.c | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/ewftools/ewftools_output.c b/ewftools/ewftools_output.c
+index 07ef5e24..07312055 100644
+--- a/ewftools/ewftools_output.c
 b/ewftools/ewftools_output.c
+@@ -238,11 +238,21 @@ void ewftools_output_version_detailed_fprint(
+ 	 LIBHMAC_VERSION_STRING );
+ 
+ #if defined( HAVE_LIBCRYPTO )
++#if defined( SHLIB_VERSION_NUMBER )
+ 	fprintf(
+ 	 stream,
+ 	 " (libcrypto %s)",
+ 	 SHLIB_VERSION_NUMBER );
+-#endif
++
++#elif defined( OPENSSL_VERSION_MAJOR ) && defined( OPENSSL_VERSION_MINOR )
++	fprintf(
++	 stream,
++	 " (libcrypto %d.%d)",
++	 OPENSSL_VERSION_MAJOR,
++	 OPENSSL_VERSION_MINOR );
++
++#endif /* defined( SHLIB_VERSION_NUMBER ) */
++#endif /* defined( HAVE_LIBCRYPTO ) */
+ #endif
+ 
+ #if defined( HAVE_LIBODRAW ) || defined( HAVE_LOCAL_LIBODRAW )
diff -Nru libewf-20140807/debian/patches/series libewf-20140807/debian/patches/series
--- libewf-20140807/debian/patches/series	2019-12-03 16:38:28.0 +0100
+++ libewf-20140807/debian/patches/series	2022-05-20 22:27:02.0 +0200
@@ -1 +1,2 @@
 Drop-ax_libfguid_pc_libs_private-from-libewf.pc.patch
+OpenSSL3.patch


signature.asc
Description: PGP signature

Bug#1011361: speech-dispatcher: Drop recommends on pulseaudio

2022-05-20 Thread Jeremy Bicha

Source: speech-dispatcher
Version: 0.11.1-1

Please don't have speech-dispatcher recommend pulseaudio. There are
two working sound servers in Debian now: pulseaudio and pipewire. From
a distro management perspective, I think it's better to have the
default dependency set from a higher level metapackage or task than
from individual packages.

I tested that the orca screen reader still works in today's Ubuntu
22.10 ISO when pipewire is installed and running and pulseaudio is
removed.

Thank you,
Jeremy Bicha

Bug#1011360: buster-pu: package python-scrapy/1.5.1-1+deb10u1

2022-05-20 Thread Stefano Rivera

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: mouzan...@gmail.com, w...@debian.org

[ Reason ]
Hi, there were some security issues in python-scrapy, that were deemed
no-DSA

[ Impact ]
Known security issues, with the risk of credential-exposure.

[ Tests ]
They both include unit tests, which pass.

[ Risks ]
There are behavioural changes, that could affect users of this code, if
they are scraping sites that need authentication.
However, this is unavoidable for the issues being fixed.

This matches what was uploaded to stretch-security, although the patch
isn't identical. So, anyone upgrading from stretch-lts would hit a
regression if this wasn't updated. Risks both ways.

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

[ Changes ]
* Security fix for CVE-2021-41125: Don't send authentication data with all
  requests. Provide a http_auth_domain spider attribute to control which
  domains are allowed to receive the configured HTTP authentication
  credentials.
* Security Fix CVE-2022-0577: Don't expose cookies cross-domain when
  redirected. (Closes: #1008234)

[ Other info ]
See also Bug #1011359 for bullseye.
diff -Nru python-scrapy-1.5.1/debian/changelog 
python-scrapy-1.5.1/debian/changelog
--- python-scrapy-1.5.1/debian/changelog2018-09-29 08:51:15.0 
-0400
+++ python-scrapy-1.5.1/debian/changelog2022-05-20 16:14:25.0 
-0400
@@ -1,3 +1,15 @@
+python-scrapy (1.5.1-1+deb10u1) buster; urgency=medium
+
+  * Team upload.
+  * Security fix for CVE-2021-41125: Don't send authentication data with all
+requests. Provide a http_auth_domain spider attribute to control which
+domains are allowed to receive the configured HTTP authentication
+credentials.
+  * Security fix CVE-2022-0577: Don't expose cookies cross-domain when
+redirected. (Closes: #1008234)
+
+ -- Stefano Rivera   Fri, 20 May 2022 16:14:25 -0400
+
 python-scrapy (1.5.1-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru python-scrapy-1.5.1/debian/patches/CVE-2021-41125.patch 
python-scrapy-1.5.1/debian/patches/CVE-2021-41125.patch
--- python-scrapy-1.5.1/debian/patches/CVE-2021-41125.patch 1969-12-31 
20:00:00.0 -0400
+++ python-scrapy-1.5.1/debian/patches/CVE-2021-41125.patch 2022-05-20 
16:14:25.0 -0400
@@ -0,0 +1,206 @@
+From: Andrey Rakhmatullin 
+Date: Fri, 16 Aug 2019 14:53:42 +0500
+Subject: Add http_auth_domain to HttpAuthMiddleware.
+
+Fixes CVE-2021-41125
+Origin: upstream, 
https://github.com/scrapy/scrapy/commit/b01d69a1bf48060daec8f751368622352d8b85a6
+---
+ docs/topics/downloader-middleware.rst   | 18 +-
+ scrapy/downloadermiddlewares/httpauth.py| 21 ++-
+ tests/test_downloadermiddleware_httpauth.py | 85 -
+ 3 files changed, 118 insertions(+), 6 deletions(-)
+
+diff --git a/docs/topics/downloader-middleware.rst 
b/docs/topics/downloader-middleware.rst
+index dfe4c13..73e7e0f 100644
+--- a/docs/topics/downloader-middleware.rst
 b/docs/topics/downloader-middleware.rst
+@@ -309,8 +309,21 @@ HttpAuthMiddleware
+ This middleware authenticates all requests generated from certain spiders
+ using `Basic access authentication`_ (aka. HTTP auth).
+ 
+-To enable HTTP authentication from certain spiders, set the ``http_user``
+-and ``http_pass`` attributes of those spiders.
++To enable HTTP authentication for a spider, set the ``http_user`` and
++``http_pass`` spider attributes to the authentication data and the
++``http_auth_domain`` spider attribute to the domain which requires this
++authentication (its subdomains will be also handled in the same way).
++You can set ``http_auth_domain`` to ``None`` to enable the
++authentication for all requests but usually this is not needed.
++
++.. warning::
++In the previous Scrapy versions HttpAuthMiddleware sent the
++authentication data with all requests, which is a security problem if
++the spider makes requests to several different domains. Currently if
++the ``http_auth_domain`` attribute is not set, the middleware will use
++the domain of the first request, which will work for some spider but
++not for others. In the future the middleware will produce an error
++instead.
+ 
+ Example::
+ 
+@@ -320,6 +333,7 @@ HttpAuthMiddleware
+ 
+ http_user = 'someuser'
+ http_pass = 'somepass'
++http_auth_domain = 'intranet.example.com'
+ name = 'intranet.example.com'
+ 
+ # .. rest of the spider code omitted ...
+diff --git a/scrapy/downloadermiddlewares/httpauth.py 
b/scrapy/downloadermiddlewares/httpauth.py
+index 7aa7a62..b9030f7 100644
+---

Bug#1011359: bullseye-pu: package python-scrapy/2.4.1-2+deb11u1

2022-05-20 Thread Stefano Rivera

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: mouzan...@gmail.com, w...@debian.org

[ Reason ]
Hi, there were some security issues in python-scrapy, that were deemed
no-DSA

[ Impact ]
Known security issues, with the risk of credential-exposure.

[ Tests ]
They both include unit tests, which pass.

[ Risks ]
There are behavioural changes, that could affect users of this code, if
they are scraping sites that need authentication.
However, this is unavoidable for the issues being fixed.

This matches what was uploaded to stretch-security, although the patch
isn't identical. So, anyone upgrading from stretch-lts would hit a
regression if this wasn't updated. Risks both ways.

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

[ Changes ]
* Security fix for CVE-2021-41125: Don't send authentication data with all
 requests. Provide a http_auth_domain spider attribute to control which
 domains are allowed to receive the configured HTTP authentication
 credentials.
* Security Fix CVE-2022-0577: Don't expose cookies cross-domain when
 redirected. (Closes: #1008234)
diff -Nru python-scrapy-2.4.1/debian/changelog 
python-scrapy-2.4.1/debian/changelog
--- python-scrapy-2.4.1/debian/changelog2021-02-28 09:55:45.0 
-0400
+++ python-scrapy-2.4.1/debian/changelog2022-05-20 16:11:00.0 
-0400
@@ -1,3 +1,15 @@
+python-scrapy (2.4.1-2+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Security fix for CVE-2021-41125: Don't send authentication data with all
+requests. Provide a http_auth_domain spider attribute to control which
+domains are allowed to receive the configured HTTP authentication
+credentials.
+  * Security Fix CVE-2022-0577: Don't expose cookies cross-domain when
+redirected. (Closes: #1008234)
+
+ -- Stefano Rivera   Fri, 20 May 2022 16:11:00 -0400
+
 python-scrapy (2.4.1-2) unstable; urgency=medium
 
   * Skip tests that require network access (Closes: #980901).
diff -Nru python-scrapy-2.4.1/debian/patches/CVE-2021-41125.patch 
python-scrapy-2.4.1/debian/patches/CVE-2021-41125.patch
--- python-scrapy-2.4.1/debian/patches/CVE-2021-41125.patch 1969-12-31 
20:00:00.0 -0400
+++ python-scrapy-2.4.1/debian/patches/CVE-2021-41125.patch 2022-05-20 
16:11:00.0 -0400
@@ -0,0 +1,206 @@
+From: Andrey Rakhmatullin 
+Date: Fri, 16 Aug 2019 14:53:42 +0500
+Subject: Add http_auth_domain to HttpAuthMiddleware.
+
+Fixes CVE-2021-41125
+Origin: upstream, 
https://github.com/scrapy/scrapy/commit/b01d69a1bf48060daec8f751368622352d8b85a6
+---
+ docs/topics/downloader-middleware.rst   | 18 +-
+ scrapy/downloadermiddlewares/httpauth.py| 21 ++-
+ tests/test_downloadermiddleware_httpauth.py | 85 -
+ 3 files changed, 118 insertions(+), 6 deletions(-)
+
+diff --git a/docs/topics/downloader-middleware.rst 
b/docs/topics/downloader-middleware.rst
+index 6801adc..e0a3205 100644
+--- a/docs/topics/downloader-middleware.rst
 b/docs/topics/downloader-middleware.rst
+@@ -323,8 +323,21 @@ HttpAuthMiddleware
+ This middleware authenticates all requests generated from certain spiders
+ using `Basic access authentication`_ (aka. HTTP auth).
+ 
+-To enable HTTP authentication from certain spiders, set the ``http_user``
+-and ``http_pass`` attributes of those spiders.
++To enable HTTP authentication for a spider, set the ``http_user`` and
++``http_pass`` spider attributes to the authentication data and the
++``http_auth_domain`` spider attribute to the domain which requires this
++authentication (its subdomains will be also handled in the same way).
++You can set ``http_auth_domain`` to ``None`` to enable the
++authentication for all requests but usually this is not needed.
++
++.. warning::
++In the previous Scrapy versions HttpAuthMiddleware sent the
++authentication data with all requests, which is a security problem if
++the spider makes requests to several different domains. Currently if
++the ``http_auth_domain`` attribute is not set, the middleware will use
++the domain of the first request, which will work for some spider but
++not for others. In the future the middleware will produce an error
++instead.
+ 
+ Example::
+ 
+@@ -334,6 +347,7 @@ HttpAuthMiddleware
+ 
+ http_user = 'someuser'
+ http_pass = 'somepass'
++http_auth_domain = 'intranet.example.com'
+ name = 'intranet.example.com'
+ 
+ # .. rest of the spider code omitted ...
+diff --git a/scrapy/downloadermiddlewares/httpauth.py 
b/scrapy/downloadermiddlewares/httpauth.py
+index 089bf0d..1bee3e2 100644
+---

Bug#1011311: RFS: colordiff/1.0.20-1 -- tool to colorize 'diff' output

2022-05-20 Thread Dave Ewart

Dear mentors,

Rebuild package following suggestions from Bastian Germann.

I am looking for a sponsor for my package "colordiff":

 * Package name: colordiff
   Version : 1.0.20-1
   Upstream Author : Dave Ewart da...@sungate.co.uk
 * URL : http://www.colordiff.org/
 * License : GPL-2+
 * Vcs : https://github.com/daveewart/colordiff
   Section : text

The source builds the following binary packages:

  colordiff - tool to colorize 'diff' output

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/colordiff/colordiff_1.0.20-1.dsc

Changes since the last upload:

 colordiff (1.0.20-1) unstable; urgency=medium
 .
   * New upstream release.
   * debhelper-compat updated to version 13.
   * Updates standards version to 4.6.0, added Rules-Require-Root.

Regards,

-- 
Dave Ewart, da...@sungate.co.uk

Bug#1006365: wireplumber: Please split audio files out of the main package

2022-05-20 Thread Dylan Aïssi

Hello Laurent,

Le jeu. 24 févr. 2022 à 11:33, Laurent Bigonville  a écrit :
>
> This is similar to #1006364 opened against pipewire-media-session and an
> addition to #997862
>
> Currently having wireplumber and pulseaudio installed at the
> same time make both pipewire and pulseadio register A2DP endpoints in
> bluez (and open the alsa devices)
>
> As pulseaudio is still the default (at least when installing GNOME) this
> is causing issues.
>
> Would it be possible to split the configuration and plugins files that
> enable the "audio" part of pipewire to an other package? That way
> pipewire-pulse could depend on that package instead?

Unfortunately, it's not so easy. Moving conf files will just
completely break audio.
If we want to stop wireplumber managing audio, we have to modify conf files and
that makes life harder for users who want to switch to PW/WP for audio.
Some related discussion here:
https://salsa.debian.org/utopia-team/wireplumber/-/merge_requests/7

Arch Linux meets the same issue recently and they had to switch back
to pipewire-media-session:
https://archlinux.org/news/undone-replacement-of-pipewire-media-session-with-wireplumber/

Why a user would install wireplumber without having pipewire managing audio?

Best,
Dylan

Bug#1011358: ITP: tpm2-pytss -- TPM2 TSS Python bindings


Package: wnpp
Severity: wishlist
Control: block 1006586 by -1

* Package name: tpm2-pytss
  Upstream Author : William Roberts (Intel)
* URL : https://github.com/tpm2-software/tpm2-pytss
* License : BSD-2-clause
  Programming Lang: Python
  Description : TPM2 TSS Python bindings

TPM2 TSS Python bindings for Enhanced System API (ESYS), Feature API (FAPI), Marshaling (MU), TCTI 
Loader (TCTILdr) and RC Decoding (rcdecode) libraries. It also contains utility methods for wrapping 
keys to TPM 2.0 data structures for importation into the TPM, unwrapping keys and exporting them 
from the TPM, TPM-less makecredential command and name calculations, TSS2 PEM Key format support, 
importing Keys from PEM, DER and SSH formats, conversion from tpm2-tools based command line strings 
and loading tpm2-tools context files.


This is a dependency of tpm2-pkcs11 1.8.0, which blocks openssl 3 transition.
I am going to hand this in as a Python team-maintained package.

Bug#1011357: /bin/mount links with library in /usr - might be unaccesible in case of /usr failure

2022-05-20 Thread Artur R. Czechowski

Package: mount
Version: 2.38-4
Severity: important
File: /bin/mount

The /bin/mount binary uses libraries being placed in /usr. In case /usr
is a separate filesystem and is not mounted, mount might be unusable.
Here is output of ldd /bin/mount with marked libraries from /usr:

root@tardis:~# ldd /bin/mount
linux-vdso.so.1 (0x7fffa3ede000)
!!! libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1 
(0x7f9394295000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
(0x7f9394269000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f939409)
!!! libblkid.so.1 => /usr/lib/x86_64-linux-gnu/libblkid.so.1 
(0x7f939403c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9394036000)
/lib64/ld-linux-x86-64.so.2 (0x7f9394331000)
!!! libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f9393f9e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f9393f7b000)

libmount and libblkid are parts of the util-linux source package, however
libpcre2-8 is separate source package.

Please note, there is also no package dependency on libpcre2-8-0 in mount
package. However, dependency on libsmartcols1 is listed, but it seems to be
not used by mount.

Best regards
Artur

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 mount depends on:
ii  libblkid1  2.37.3-1+b1
ii  libc6  2.33-7
ii  libmount1  2.38-4
ii  libselinux13.3-1+b1
ii  libsmartcols1  2.37.3-1+b1

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- no debconf information

--

Bug#1011356: src:parlatype: fails to migrate to testing for too long: FTBFS on mips64el, mipsel and s390x

2022-05-20 Thread Paul Gevers


Source: parlatype
Version: 3.0-2
Severity: serious
Control: close -1 3.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1008132

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:parlatype has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package fails to built 
from source on architectures where it built successfully in the past, 
bug #1008132.


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=parlatype



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989085: Description suggestion

2022-05-20 Thread Joseph Carter

Suggest something like…

Description: Micro-compositor for game scaling
 Gamescope wraps your games to give them scaling and fullscreen options. It
 provides a Wayland compositor to your games, but gamescope runs under both
 Wayland and X.org.
 .
 Your game sees a virtual display at the resolution you specified. You see a
 scaled view in a window or fullscreen. This is useful when either the game or
 your system do not permit running the game at native window/screen sizes. You
 can also use integer scaling to keep your pixels sharp and pixelated.

I think this should resolve any confusion as to whether or not a person wants 
to install this.

Joseph

Bug#1011355: deja-dup: Deja Dup's Google support will break in September 2022 for versions < 43.3

2022-05-20 Thread Michael Terry

Package: deja-dup
Version: 42.7-1
Severity: important
X-Debbugs-Cc: m...@mterry.name

Dear Maintainer,

I'm the upstream maintainer of Deja Dup. Google will be removing
a particular oauth workflow that Deja Dup uses in September.

This means that any new authentications for users trying to connect Deja
Dup to their Google account will fail after that date (existing users that
have already authenticated themselves will continue to work).

If possible, updating to 43.3 will fix this. Debian has already updated
the sid version to 43.3. But for older releases like bullseye (which is on
42.7), I recommend a backported patch.

Here's a wiki page for more information about the issue, including
backported patches for older versions like 42.7:
https://wiki.gnome.org/Apps/DejaDup/GoogleAuthChange2022

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

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

Versions of packages deja-dup depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  duplicity0.8.21-1build1
ii  libatk1.0-0  2.36.0-3build1
ii  libc62.35-0ubuntu3
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.1-1
ii  libgpg-error01.43-3
ii  libgtk-3-0   3.24.33-1ubuntu1
ii  libhandy-1-0 1.6.1-1
ii  libjson-glib-1.0-0   1.6.6-1build1
ii  libpackagekit-glib2-18   1.2.5-2ubuntu2
ii  libsecret-1-00.20.5-2
ii  libsoup2.4-1 2.74.2-3

Versions of packages deja-dup recommends:
ii  gvfs-backends  1.48.1-4
ii  packagekit 1.2.5-2ubuntu2
ii  policykit-10.105-33

Versions of packages deja-dup suggests:
pn  python3-pydrive

Bug#1011333: /usr/bin/pdftosrc: CVE-2021-27548 - null-pointer deference in XFAScanner::scanNode used by pdftosrc

2022-05-20 Thread Salvatore Bonaccorso

Hi Hilmar,

On Fri, May 20, 2022 at 03:57:46PM +0200, Hilmar Preuße wrote:
> Am 20.05.2022 um 11:16 teilte Neil Williams mit:
> 
> Hello Neil,
> 
> > texlive-binaries in unstable, experimental and bookworm embeds
> > xpdfreader 4.03 and the code is exposed via the pdftosrc binary.
> > 
> > The PoC file from the CVE triggers a segmentation fault in pdftosrc.
> > pdftosrc from bullseye (correctly) reports a broken PDF without
> > crashing as texlive-binaries in bullseye embeds xpdfreader 4.02.
> > 
> I could simply copy the appropriate commit from upstream [1] and put it into
> our package. The package still builds and it seems to solve the issue (see
> below). I'd do another upload to experimental and upload TL 2022 (containing
> the fix) to unstable in about 2 weeks.
> 
> Would the time frame be OK for you?

FWIW, this sound reasonable and just defer the fix to be fixed with
the new upstream version when landing in unstable.

Regards,
Salvatore

Bug#1011354: Does not include an autopkgtest

2022-05-20 Thread Sebastien Bacher


Package: libqrtr-glib
Version: 1.2.2-1

It would be nicer if the package had autopkgtests testing. The attached 
patch is adding a trivial build test on the model of the ones used for 
most GNOME libraries, it ensure that a simple case builds and that the 
dev isn't missing any depends.


Thanks for considering




diff -Nru libqrtr-glib-1.2.2/debian/changelog libqrtr-glib-1.2.2/debian/changelog
--- libqrtr-glib-1.2.2/debian/changelog	2022-02-19 14:33:19.0 +0100
+++ libqrtr-glib-1.2.2/debian/changelog	2022-05-20 17:10:31.0 +0200
@@ -1,3 +1,9 @@
+libqrtr-glib (1.2.2-2) UNRELEASED; urgency=medium
+
+  * debian/tests: include a basic autopkgtest for the library
+
+ -- Sebastien Bacher   Fri, 20 May 2022 17:10:31 +0200
+
 libqrtr-glib (1.2.2-1) unstable; urgency=medium
 
   * New upstream version 1.2.2
diff -Nru libqrtr-glib-1.2.2/debian/tests/build libqrtr-glib-1.2.2/debian/tests/build
--- libqrtr-glib-1.2.2/debian/tests/build	1970-01-01 01:00:00.0 +0100
+++ libqrtr-glib-1.2.2/debian/tests/build	2022-05-20 17:10:31.0 +0200
@@ -0,0 +1,31 @@
+#!/bin/sh
+# autopkgtest check: Build and run a program against libqrtr-glib, to verify that
+# the headers and pkg-config file are installed correctly
+
+set -e
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cat < libqrtr-glib_test.c
+#include 
+#include 
+
+int main(void)
+{
+  printf("The micro version is %d\n", QRTR_MICRO_VERSION);
+  return 0;
+}
+EOF
+
+# deliberately word-splitting pkg-config output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -o libqrtr-glib_test libqrtr-glib_test.c \
+$("${CROSS_COMPILE}pkg-config" --cflags --libs qrtr-glib)
+echo "build: OK"
+[ -x libqrtr-glib_test ]
+./libqrtr-glib_test
+echo "run: OK"
diff -Nru libqrtr-glib-1.2.2/debian/tests/control libqrtr-glib-1.2.2/debian/tests/control
--- libqrtr-glib-1.2.2/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ libqrtr-glib-1.2.2/debian/tests/control	2022-05-20 17:10:31.0 +0200
@@ -0,0 +1,3 @@
+Tests: build
+Depends: build-essential, pkg-config, libqrtr-glib-dev
+Restrictions: allow-stderr superficial

Bug#1011353: RM: anjuta-extras -- RoM; unmaintained

2022-05-20 Thread Jeremy Bicha

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: anjuta-ext...@packages.debian.org

anjuta-extras is no longer maintained upstream. It has been archived
which means GNOME is no longer accepting any code fixes, translations,
or even bug reports for it any more.

https://gitlab.gnome.org/Archive/anjuta-extras

Its most recent release was in 2017.

It has been unbuildable in Unstable since October:
https://bugs.debian.org/997116

Therefore, please remove anjuta-extras from Debian.

The recommended replacement for Anjuta is GNOME Builder.

On behalf of the Debian GNOME Team,
Jeremy Bicha

Bug#1001741: flatbuffers: please update to new >= 2 version

2022-05-20 Thread Vasyl Gello

Hi Bastian!

Let me try to check it on weekend.
I am not an officual flatbuffers maintainer, but I do use it in Kodi
which I maintain. The delay is likely caused by totally-screwed symbol
mess flatbuffers produce with different compilers. Hope FB authors
fulfilled their promise to make ABI predictable.

Cheers,
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1001741: flatbuffers: please update to new >= 2 version


Please make this at least 2.0.5 because this gets rid of the deprecated imp 
module:
https://github.com/google/flatbuffers/commit/8fd7861b754b0d0574aaeeb10ea4cc485867c56f

Bug#1011352: Does not include an autopkgtest

2022-05-20 Thread Sebastien Bacher


Package: libfreeaptx
Version: 0.1.1-1

It would be nicer if the package had autopkgtests testing. The attached 
patch is adding a trivial build test on the model of the ones used for 
most GNOME libraries, it ensure that a simple case builds and that the 
dev isn't missing any depends, and encode and decode tests copying the 
examples from the upstream github webpage. The tests are using a .wav 
from alsa-utils but it might make sense to include a wav in the package 
instead to avoid relying on external packages which might change in the 
futur.


We are using that change in Ubuntu now as having tests is a requirement 
to promote packages and we plan to preinstall libfreeaptx as part of the 
switch to pipewire.


Thanks for considering



diff -Nru libfreeaptx-0.1.1/debian/changelog libfreeaptx-0.1.1/debian/changelog
--- libfreeaptx-0.1.1/debian/changelog	2021-12-17 12:05:02.0 +0100
+++ libfreeaptx-0.1.1/debian/changelog	2022-05-20 15:23:06.0 +0200
@@ -1,3 +1,10 @@
+libfreeaptx (0.1.1-2) UNRELEASED; urgency=medium
+
+  * debian/tests: 
+- include build, encore and decode autopkgtests
+
+ -- Sebastien Bacher   Fri, 20 May 2022 15:23:06 +0200
+
 libfreeaptx (0.1.1-1) unstable; urgency=medium
 
   * Initial release (Closes: #995607)
diff -Nru libfreeaptx-0.1.1/debian/control libfreeaptx-0.1.1/debian/control
--- libfreeaptx-0.1.1/debian/control	2021-12-17 12:05:02.0 +0100
+++ libfreeaptx-0.1.1/debian/control	2022-05-20 15:23:06.0 +0200
@@ -1,6 +1,7 @@
 Source: libfreeaptx
 Priority: optional
-Maintainer: Kentaro Hayashi 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Kentaro Hayashi 
 Build-Depends: debhelper-compat (= 13)
 Standards-Version: 4.6.0
 Section: libs
diff -Nru libfreeaptx-0.1.1/debian/tests/build libfreeaptx-0.1.1/debian/tests/build
--- libfreeaptx-0.1.1/debian/tests/build	1970-01-01 01:00:00.0 +0100
+++ libfreeaptx-0.1.1/debian/tests/build	2022-05-20 14:56:01.0 +0200
@@ -0,0 +1,31 @@
+#!/bin/sh
+# autopkgtest check: Build and run a program against libfreeaptx, to verify that
+# the headers and pkg-config file are installed correctly
+
+set -e
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cat < libfreeaptx_test.c
+#include "freeaptx.h"
+
+int main(void)
+{
+  struct aptx_context *dec;
+  dec = aptx_init(0);
+  return 0;
+}
+EOF
+
+# deliberately word-splitting pkg-config output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -o libfreeaptx_test libfreeaptx_test.c \
+$("${CROSS_COMPILE}pkg-config" --cflags --libs libfreeaptx)
+echo "build: OK"
+[ -x libfreeaptx_test ]
+./libfreeaptx_test
+echo "run: OK"
diff -Nru libfreeaptx-0.1.1/debian/tests/control libfreeaptx-0.1.1/debian/tests/control
--- libfreeaptx-0.1.1/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ libfreeaptx-0.1.1/debian/tests/control	2022-05-20 15:22:48.0 +0200
@@ -0,0 +1,11 @@
+Tests: build
+Depends: build-essential, pkg-config, libfreeaptx-dev
+Restrictions: allow-stderr superficial
+
+Test-Command: sox /usr/share/sounds/alsa/Noise.wav -t raw -r 44.1k -L -e s -b 24 -c 2 - | freeaptxenc > $AUTOPKGTEST_TMP/sample.aptx; freeaptxdec < $AUTOPKGTEST_TMP/sample.aptx | sox -t raw -r 44.1k -L -e s -b 24 -c 2 - $AUTOPKGTEST_TMP/sample.wav
+Depends: alsa-utils, freeaptx-utils, sox
+Features: test-name=encore_decode
+
+Test-Command: sox /usr/share/sounds/alsa/Noise.wav -t raw -r 44.1k -L -e s -b 24 -c 2 - | freeaptxenc --hd > $AUTOPKGTEST_TMP/sample.aptx; freeaptxdec --hd < $AUTOPKGTEST_TMP/sample.aptx | sox -t raw -r 44.1k -L -e s -b 24 -c 2 - $AUTOPKGTEST_TMP/sample.wav
+Depends: alsa-utils, freeaptx-utils, sox
+Features: test-name=encore_decode_hd

Bug#866334: About Bug#866334: RFP: lean -- theorem prover from Microsoft Research

2022-05-20 Thread Julian Gilbey

On Fri, May 20, 2022 at 10:59:35PM +0530, Nilesh Patra wrote:
> On 5/20/22 8:31 PM, Bill Allombert wrote:
> > On Mon, Sep 16, 2019 at 08:39:56PM +0100, Julian Gilbey wrote:
> > > I've just started looking at lean.  One of the issues around packaging
> > > it is that different lean "scripts" (not sure the correct word here)
> > > require different versions of lean.  There is a script available which
> > > downloads the required version of lean for any particular script, and
> > > so keeps a local set of lean versions.
> > > 
> > > If we were to package lean for Debian, what exactly would we package?
> > > The current stable version, or a script such as this?  See
> > > https://github.com/leanprover-community/mathlib/blob/master/docs/install/debian_details.md
> > > for a little more on this.
> > > 
> > > Thoughts would be appreciated!
> > 
> > Lean is now the theorem prover with the largest community, so it would
> > be nice to have it in Debian. However I do not know how usable it is
> > outside the visual studio IDE.

Debian now has the package "elan" which handles installation of Lean;
this might be sufficient.

Best wishes,

   Julian

Bug#993339: reprotest Salsa CI failure due to different creation times

2022-05-20 Thread Rock Storm

Hi,

I'm having a similar issue. Not sure if it is exactly identical. I can
open a new issue if required.

Basically, reprotest fails during a Salsa CI job on the Printrun
package [1] and I believe this is a false negative.

[1]: https://salsa.debian.org/3dprinting-team/printrun/-/jobs/2790747

An excerpt of the diffoscope output is copied below. Briefly, the
offending files are only different because of the date they were
created. For some reason one of the files creation/modification time is
set as it happened in 1971. Content wise, there's no difference between
them.

One thing that seems suspicious is that the offending files among some
of those modified by quilt patches. Does that ring any bells?

Might also be worth mentioning this package uses upstream and pristine-
tar branches. Could that have any implications?


│ │ ├── data.tar.xz
│ │ │ ├── data.tar
│ │ │ │ ├── file list
│ │ │ │ │ @@ -23,23 +23,23 @@
│ │ │ │ │  -rw-r--r--   0 root (0) root (0)48911 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gl/libtatlin/actors.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0)17289 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gl/panel.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0) 2724 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gl/trackball.py
│ │ │ │ │  drwxr-xr-x   0 root (0) root (0)0 2022-04-30 
17:32:34.00 ./usr/lib/python3/dist-packages/printrun/gui/
│ │ │ │ │  -rw-r--r--   0 root (0) root (0)13721 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/__init__.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0) 3276 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/bufferedcanvas.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0)20859 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/controls.py
│ │ │ │ │ +-rw-r--r--   0 root (0) root (0)21262 1971-06-21 
19:14:00.00 ./usr/lib/python3/dist-packages/printrun/gui/graph.py
│ │ │ │ │ --rw-r--r--   0 root (0) root (0)21262 2022-04-30 
17:32:34.00 ./usr/lib/python3/dist-packages/printrun/gui/graph.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0) 2236 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/log.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0) 4251 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/toolbar.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0) 1466 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/utils.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0) 4990 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/viz.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0)16728 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/widgets.py
│ │ │ │ │ +-rw-r--r--   0 root (0) root (0)19964 1971-06-21 
19:14:00.00 ./usr/lib/python3/dist-packages/printrun/gui/xybuttons.py
│ │ │ │ │ --rw-r--r--   0 root (0) root (0)19964 2022-04-30 
17:32:34.00 ./usr/lib/python3/dist-packages/printrun/gui/xybuttons.py
│ │ │ │ │  -rw-r--r--   0 root (0) root (0) 6048 2021-02-02 
17:37:41.00 ./usr/lib/python3/dist-packages/printrun/gui/zbuttons.py
│ │ │ │ │ +-rw-r--r--   0 root (0) root (0)22401 1971-06-21 
19:14:00.00 ./usr/lib/python3/dist-packages/printrun/gviz.py
│ │ │ │ │ --rw-r--r--   0 root (0) root (0)22401 2022-04-30 
17:32:34.00 ./usr/lib/python3/dist-packages/printrun/gviz.py


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

Christoph, I'm CCing you here both because you created the salsa CI
configuration file back in the day and because you are the latest
sponsor for this package, in case you feel this should be a blocker for
Printrun updates.

Regards,

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

Bug#1011351: RFP: python-vxi11 -- VXI-11 driver for controlling instruments over Ethernet


Package: wnpp
Severity: wishlist

* Package name: python-vxi11
  Upstream Author : Alex Forencich
* URL : https://github.com/python-ivi/python-vxi11
* License : Expat
  Programming Lang: Python
  Description : VXI-11 driver for controlling instruments over Ethernet

This Python package supports the VXI-11 Ethernet instrument control protocol for controlling VXI11 
and LXI compatible instruments. The implementation is pure Python and highly portable.


This should be Python team-maintained.

Bug#1011335: libssl3: using SSL is not possible in Kmail with the update to OpenSSL3

2022-05-20 Thread Bernhard Schmidt

Hi,


> On my computer the system installed is a Debian Sid AMD64 and I use Kmail to
> receive or send messages, for 4 days I could not receive or send messages 
> using
> Kmail.
> When sending a message I had and I have the following error: transport
> interrupted TLS initialization failed.
> When receiving messages from Yahoo or Free mailboxes I have the error:
> unable to connect to server pop. the server immediately terminated the
> connection.
> After research the problem seems to come from SSL and precisely SSL in Debian
> SID is migrating to SSL3.

There is a similar report in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011138 where the
issue went away after uninstalling libssl-dev

Before you do this, could you run

dpkg -l | grep ssl

and append the output to this bugreport?

Bernhard

Bug#866334: About Bug#866334: RFP: lean -- theorem prover from Microsoft Research

2022-05-20 Thread Nilesh Patra


On 5/20/22 8:31 PM, Bill Allombert wrote:

On Mon, Sep 16, 2019 at 08:39:56PM +0100, Julian Gilbey wrote:

I've just started looking at lean.  One of the issues around packaging
it is that different lean "scripts" (not sure the correct word here)
require different versions of lean.  There is a script available which
downloads the required version of lean for any particular script, and
so keeps a local set of lean versions.

If we were to package lean for Debian, what exactly would we package?
The current stable version, or a script such as this?  See
https://github.com/leanprover-community/mathlib/blob/master/docs/install/debian_details.md
for a little more on this.

Thoughts would be appreciated!


Lean is now the theorem prover with the largest community, so it would
be nice to have it in Debian. However I do not know how usable it is
outside the visual studio IDE.


If you want to direct the conversation onto a mailing list, please use 
debian-math@ instead (CC'ed)
as lean is a math based packages

--
Best,
Nilesh





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011138: Workaround for bug #1011138

2022-05-20 Thread Bernhard Schmidt

Control: reassign -1 libssl-dev 3.0.3-4
Control: affects -1 kmail

On 19/05/22 01:35 PM, Hopea Jonne wrote:

> Uninstalling libssl-dev helped, for some reason libssl-dev also ships with a 
> libssl.so binary which may or may not be of same version as other ones.

I don't think this is the reason, libssl-dev does not ship the .so
binary, instead it ships a symlink to the libraries provided by libssl3

$ dpkg-deb -c libssl-dev_3.0.3-4_amd64.deb  | grep .so
lrwxrwxrwx root/root 0 2022-05-16 23:20 
./usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.3
lrwxrwxrwx root/root 0 2022-05-16 23:20 
./usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.3

However, your bugreport might still point to another problem in
libssl-dev, thus reassigning.

Is it possible that you have a partially upgraded system (libssl-dev
from OpenSSL 1.1, but kmail linked to OpenSSL 3.0)?

Bernhard

Bug#1011138: Workaround for bug #1011138

2022-05-20 Thread me

Not entirely sure, libssl-dev was 1.1.x while both libssl3 and libssl1.1 are 
installed. I assume that qt networking (and consequently kmail and other stuff 
like quassel) prefers the libssl.so symlink over libssl.so.3 but expects it to 
be 3.0.

On May 20, 2022 8:16:06 PM GMT+03:00, Bernhard Schmidt  wrote:
>Control: reassign -1 libssl-dev 3.0.3-4
>Control: affects -1 kmail
>
>On 19/05/22 01:35 PM, Hopea Jonne wrote:
>
>> Uninstalling libssl-dev helped, for some reason libssl-dev also ships with a 
>> libssl.so binary which may or may not be of same version as other ones.
>
>I don't think this is the reason, libssl-dev does not ship the .so
>binary, instead it ships a symlink to the libraries provided by libssl3
>
>$ dpkg-deb -c libssl-dev_3.0.3-4_amd64.deb  | grep .so
>lrwxrwxrwx root/root 0 2022-05-16 23:20 
>./usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.3
>lrwxrwxrwx root/root 0 2022-05-16 23:20 
>./usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.3
>
>However, your bugreport might still point to another problem in
>libssl-dev, thus reassigning.
>
>Is it possible that you have a partially upgraded system (libssl-dev
>from OpenSSL 1.1, but kmail linked to OpenSSL 3.0)?
>
>Bernhard

Bug#988540: im-config: breaks the keyboard configuration

2022-05-20 Thread Vincent Lefevre

On 2022-05-21 00:05:09 +0900, Osamu Aoki wrote:
> Classic X environment supports to enter non-ASCII (latin) characters
> via XKB input and some people still want to use this via this old
> setting method.
> 
> Bug was filed by an annoyed user who lost access to functionalities
> offered by his old fashioned XKB input setting.

Well, I didn't know that XKB was old fashioned (I started to use it
in 2011, as a migration from xmodmap). I may consider to move to ibus
if there are no drawbacks (and with some hope that long-standing XKB
related bugs disappear). That said...

> This happened because ZOOM (this package is external to Debian)
> provides its DEB package with its "Depends" listing ibus.
> 
> It is reasonable for ZOOM to support Chinese and Japanese input and
> list ibus as dependency. (XKB can't support Chinese nor Japanese
> input)

I doubt that support for Chinese and Japanese input is specific to
Zoom. The dependency should rather be at a higher level in such a
case (the desktop environment?). But since the issue is in the Zoom
package, not provided by Debian, nothing can be done here concerning
this point.

> ibus merely recommends im-config for easy set-up but this fact pulls
> in im-config as its default behavior.
> 
> im-config is a glue layer code to support keyboard input with focus
> to use modern mothods (such as ibus). im-config's default behavior
> is to use ibus (reasonable default choice).
> 
> ibus can (I think) offer XKB equivalent input functionality if
> configured correctly. I don't use such feature so I can't explain
> with confidence. Here are some references which might help.
> *
> https://superuser.com/questions/1637594/how-to-pass-xkb-options-to-ibus-and-use-them-with-m17n-engines
> (2021)
> * https://vas.neocities.org/custom_keyboard_layout_xkb_ibus.html (2020)
> * 
> https://askubuntu.com/questions/1139936/ubuntu-mate-disable-xkb-and-use-ibus 
> (2019)
> * https://askubuntu.com/questions/1077683/ibus-xkb-engine-layouts-dont-work 
> (2018)
> * https://wiki.archlinux.org/title/IBus#Troubleshooting
> 
> (If I recall correctly, ibus-xkb code has been merged into ibus.
> ibus should offer this XKB input functionality by now.)

Thanks for the information.

> Also for im-config, im-config can be configured not to use ibus by
> running this command:
> 
> im-config -n none
> 
> and reboot.

OK. But note that an important part of the issue was that it took me
some time to figure out what was going on: I could notice the breakage
only after logging in again one week later, and I didn't know that this
was related to ibus and im-config (which I had never heard of before,
and I probably forgot that they had been installed). The fact that
I didn't get a warning or an error message in the first place is not
nice, leaving the user in the dark.

> For both ibus and im-config, the desirable user experience can be
> provided by proper user configuration.
> 
> So there is no bug on im-config's parts.

IMHO, the user's .xsession file shouldn't be run before im-config has
loaded its configuration.

> (Besides, you can remove im-config too since it is only
> recommended.)

But this doesn't solve the problem that one doesn't know what's going
on (see above).

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

Bug#1008829: pysrs-bin: envfrom2srs and srs2envtol fails with ModuleNotFoundError: No module named 'ConfigParser'

2022-05-20 Thread Hefee

Control: forwarded -1 https://github.com/sdgathman/pysrs/issues/12

Hey,

> Why do you insist on keeping broken packages in Debian?

because pysrs is more than these two scripts - the core part is the python 
library supporting handle SRS.

> Sorry.  What's the less offensice way to describe broken and untested?

Just telling it is broken is fine. But saying it is crap and ask directly for 
removal is offensive.

> > It is only the two example scripts, that are not properly ported to Python
> > 3.
> You are installing known broken examples in $PATH? But why!
> 
> Well, whatever.  Thanks for not caring about quality

I try not to ship broken packages on purpose, but I'm just a human make 
mistakes and don't have the time to test everything.

I start asking upstream to create a new version in order to get a fixed package 
in Debian soon.

regards

hefee

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

Bug#1010538: gdu: FTBFS on ppc64el

2022-05-20 Thread Stephen Gelman

 It seems rebuilding the package fixed this…
https://buildd.debian.org/status/logs.php?pkg=gdu=5.13.2-1%2Bb1=ppc64el

On May 3, 2022 at 4:07:00 PM, Sebastian Ramacher 
wrote:

> Source: gdu
> Version: 5.13.2-1
> Severity: serious
> Tags: ftbfs sid bookworm
> Justification: fails to build from source (but built successfully in the
> past)
> X-Debbugs-Cc: sramac...@debian.org
>
>
> https://buildd.debian.org/status/fetch.php?pkg=gdu=ppc64el=5.13.2-1%2Bb1=1651439537=0
>
> === RUN   TestMin
> --- PASS: TestMin (0.00s)
> PASS
> ok   github.com/dundee/gdu/v5/tui 0.229s
> FAIL
> dh_auto_test: error: cd _build && go test -vet=off -v -p 8
> github.com/dundee/gdu/v5/build github.com/dundee/gdu/v5/cmd/gdu
> github.com/dundee/gdu/v5/cmd/gdu/app
> github.com/dundee/gdu/v5/internal/common
> github.com/dundee/gdu/v5/internal/testanalyze
> github.com/dundee/gdu/v5/internal/testapp
> github.com/dundee/gdu/v5/internal/testdev
> github.com/dundee/gdu/v5/internal/testdir
> github.com/dundee/gdu/v5/pkg/analyze github.com/dundee/gdu/v5/pkg/device
> github.com/dundee/gdu/v5/pkg/fs github.com/dundee/gdu/v5/report
> github.com/dundee/gdu/v5/stdout github.com/dundee/gdu/v5/tui returned
> exit code 1
> make: *** [debian/rules:14: binary-arch] Error 25
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
> exit status 2
>
> Cheers
> --
> Sebastian Ramacher
>
>

Bug#1011166: [Debian-on-mobile-maintainers] Bug#1011166: Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0

2022-05-20 Thread Evangelos Ribeiro Tzaras

Hi,
On Thu, 2022-05-19 at 22:23 -0500, Richard Laager wrote:
> On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
> > Thanks for the patch! I'll upload a fixed version soon.
> 
> If you upload a new version, you (or I) can then close the binNMU 
> request, bug #1011201.

just uploaded, and closing #1011201, thanks again!


Cheers,
Evangelos


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

Bug#1011210: RM: android-platform-system-core/1:10.0.0+r36-10 -- ROM; NVIU

2022-05-20 Thread Roger Shimizu

On Fri, May 20, 2022 at 2:26 AM Adam D. Barratt
 wrote:
>
> On Thu, 2022-05-19 at 18:10 +0900, Roger Shimizu wrote:
> > I didn‘t know there's "Testing follows removal automatically" rule,
> > and just saw the wiki [1] says ftpmaster can only remove from sid &
> > experimental.
> >
> > I guess we should choose "testing follows removal automatically".
> >
> > [1]
> > https://wiki.debian.org/ftpmaster_Removals#Removals_from_testing.2C_stable_and_oldstable
> >
>
> For completeness, that section also says:
>
> "
> Note that in most cases it is unnecessary to request removal of your
> package from both testing and unstable. Once the package is removed
> from unstable, it will automatically be removed from testing once there
> are no dependencies keeping it there.
> "

Thanks, Adam!
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#1011350: radare2-cutter: Does not start: libr_core.so.5.0.0: cannot open shared object file

2022-05-20 Thread Göran Weinholt

Package: radare2-cutter
Version: 1.12.0-1
Severity: grave
Justification: renders package unusable

Cutter does not start:

$ Cutter
Cutter: error while loading shared libraries: libr_core.so.5.0.0: cannot open 
shared object file: No such file or directory

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

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

Versions of packages radare2-cutter depends on:
ii  libc6  2.33-7
ii  libcgraph6 2.42.2-6+b3
ii  libgcc-s1  12.1.0-2
ii  libgvc62.42.2-6+b3
ii  libkf5syntaxhighlighting5  5.93.0-1
ii  libpython3.9   3.9.12-1+b1
ii  libqt5core5a   5.15.2+dfsg-16+b2
ii  libqt5gui5 5.15.2+dfsg-16+b2
ii  libqt5network5 5.15.2+dfsg-16+b2
ii  libqt5svg5 5.15.2-4
ii  libqt5widgets5 5.15.2+dfsg-16+b2
ii  libradare2-5.0.0   5.5.0+dfsg-1
ii  libstdc++6 12.1.0-2
ii  python33.10.4-1+b1
ii  python3-ipykernel  6.13.0-1
ii  python3-jupyter-client 7.3.1-1
ii  python3-notebook   6.4.8-2
ii  python3-zmq22.3.0-1+b1

radare2-cutter recommends no packages.

radare2-cutter suggests no packages.

-- no debconf information

Bug#1011349: sway: PATH remains set to ENV_SUPATH in sway environment

2022-05-20 Thread Joshua Honeycutt

Package: sway
Version: 1.7-2
Severity: normal

Dear Maintainer,

On a new install running bookworm my regular user has the wrong PATH 
set. The path used matches ENV_SUPATH from /etc/login.defs.

I think this is because sway inherits the environment from the desktop 
manager (gdm3) which is run as root.

One solution I found in #968910 (message #15) is to modify 
/usr/share/wayland-sessions/sway.desktop to run sway in a login shell.

Another similar bug is #1011088 (zsh) but I installed Gnome and logged 
into a Wayland session and my user got the correct PATH in my bash 
shell (did not test under zsh, but I don't expect a difference).

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

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

Versions of packages sway depends on:
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libevdev21.12.1+dfsg-1
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libgl1-mesa-dri  21.3.8-1
ii  libgles2 1.4.0-1
ii  libglib2.0-0 2.72.1-1
ii  libinput10   1.20.1-1
ii  libjson-c5   0.16-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  libpangocairo-1.0-0  1.50.7+ds-1
ii  libpcre3 2:8.39-14
ii  libpixman-1-00.40.0-1
ii  libsystemd0  250.4-1
ii  libudev1 250.4-1
ii  libwayland-client0   1.20.0-1
ii  libwayland-cursor0   1.20.0-1
ii  libwayland-server0   1.20.0-1
ii  libwlroots10 0.15.1-2
ii  libxcb1  1.14-3
ii  libxkbcommon01.4.0-1
ii  policykit-1  0.105-33
ii  swaybg   1.1.1-2

Versions of packages sway recommends:
ii  foot  1.12.1-1
ii  suckless-tools46-2
ii  sway-backgrounds  1.7-2

Versions of packages sway suggests:
ii  swayidle1.7.1-2
ii  swaylock1.6-2
pn  xdg-desktop-portal-wlr  

-- no debconf information

Bug#1004421: ITS: cadaver

2022-05-20 Thread Sebastian Harl

Thanks for reaching out. Yes, I'm totally okay. I should have orphaned this a 
while ago, so this is much appreciated. Thanks!

On 20 May 2022 05:31:31 UTC, Arnaud Rebillout  wrote:
>CC Sebastian Harl in case it helps
>
>Sebastian are you Ok if I take over this package and maintain it within 
>pkg-security-team?
>
>Cheers
>

Bug#1011311: RFS: colordiff/1.0.20-1 -- tool to colorize 'diff' output


Am 20.05.22 um 18:13 schrieb Dave Ewart:

It would be helpful to me just to clarify a few things, because I'll be
honest: I don't have a huge *understanding* of Debian packaging, merely
a small amount of experience of doing so and many years of general
Linux-ness ;-)  Apologies if my questions seem a bit basic!

I can add extra line to changelog, no problem. Would you say it's OK to
use the same version 1.0.20-1 simply editing the text given that this
version hasn't gone live yet, or should I bump it to 1.0.20-2?


Yes, please just edit the changelog without raising the version.
The changelog follows the versions that are released on Debian archive, not 
mentors.
Please replace the unmeaningful line "Minor packaging tidying."


With regard to "removing debhelper", do you mean change


Build-Depends: debhelper (>> 9.0.0), debhelper-compat (= 13)


to


Build-Depends: debhelper-compat (= 13)


in my debian/control and then rebuild the package?


Exactly.


Finally, "please untag moreinfo on a new upload" -- does this mean I
should create a *new* RFS (i.e. will become a new Bug) once package is
rebuilt?  I'll read docs about how to 'untag moreinfo'.


No, the RFS is kept. The docs are at https://www.debian.org/Bugs/server-control.

Always respond to the bug address also, so any DD can pick up when nobody 
responds.

Bug#1011129: gridengine: FTBFS with OpenJDK 17 due to JDK detection error

2022-05-20 Thread Dave Love

I thought it failed with earlier openjdk than that because of jgdi being
removed, but I think it needs to use

  aimk -no-java ...

I don't know what JDK versions it needs to check for, but it's probably
not worth any effort to get that right.  I'm not sure whether you can
still build jdrmaa, at least.

I look at it immediately, but can probably can in a bit as I need to
resurrect rpm builds anyway.

Bug#1010689: Crashes with "malloc(): invalid next size (unsorted)"

On Sat, 7 May 2022 19:42:42 +0100 Jonathan McDowell  wrote:

On Sat, May 07, 2022 at 11:54:07AM +0100, Jonathan McDowell wrote:
> I've upgraded my system from bullseye to bookworm today and as a result 
> libtpm2-pkcs11-1 has gone from 1.5.0-4 to 1.7.0-1. I'm now unable to use

> the library with SSH:
> 
> | noodles@sevai:~$ ssh the.earth.li 
> | malloc(): invalid next size (unsorted)

> | Aborted

Downgrading to 1.5.0-4 (no other package changes) makes things work
again, fwiw.

J.

Hi Jonathan,

I suspect you did not recreate your database. As far as I can see the package 
misses a migration.
In 1.7.0 changes there is:
"DB Schema Change from 5 to 7.
Backup your DB before upgrading"

This sounds like you hit that.
Can you please try to recreate the DB?

Thanks,
Bastian

Bug#960968: tpm2-pkcs11: FTBFS on hppa - broken configure test for -fstack-protector-all


Control: notfound -1 1.7.0-1

It seems like this is fixed at least in in the testing version 1.7.0-1.
Can you confirm?

Bug#1011348: proot: Segmentation fault and bad address with proot trying to build wayland

2022-05-20 Thread Charles Huber

Package: proot
Version: 5.1.0-1.3
Severity: important
X-Debbugs-Cc: genpfa...@gmail.com

Dear Maintainer,

I'm running into a segmentation fault while fixing locales on a
mmdebstrap'd Bullseye chroot and a 'bad address' failure when trying to
build 'wayland' inside it.

Both operations complete without error when using proot 5.3.1 from:
https://github.com/proot-me/proot/archive/refs/tags/v5.3.1.tar.gz


Segmentation fault repro procedure


# setup
mkdir -p /tmp/test && cd /tmp/test
mmdebstrap --mode=proot --format=directory --arch=i386 --variant=buildd 
bullseye debian-i386 && \
proot -S /tmp/test/debian-i386 apt update && \
proot -S /tmp/test/debian-i386 apt install --yes locales && \
proot -S /tmp/test/debian-i386 sh -c 'echo "en_US.UTF-8 UTF-8" > 
/etc/locale.gen'

# failure
user@box:/tmp/test$ proot -S /tmp/test/debian-i386 /usr/sbin/locale-gen
Generating locales (this might take a while)...
  en_US.UTF-8...Segmentation fault
 done
Generation complete.


Bad address repro procedure


# setup, starting from a successful locale-gen
proot -S /tmp/test/debian-i386 apt install --yes devscripts equivs && \
mkdir -p /tmp/test/wayland && \
cd /tmp/test/wayland && \
apt --only-source source wayland/bullseye && \
cd wayland-*/ && \
PATH=/sbin:/usr/sbin:$PATH \
proot -S /tmp/test/debian-i386 mk-build-deps --install --tool='apt-get -o 
Debug::pkgProblemResolver=yes --no-install-recommends --yes' --remove

# 'bad address' with bullseye's proot 5.1.0
user@box:/tmp/test/wayland/wayland-1.18.0$ proot -R /tmp/test/debian-i386 
dpkg-buildpackage --build=binary --unsigned-source --unsigned-changes
...
Option buildtype is: plain [default: debugoptimized]
Found ninja-1.10.1 at /usr/bin/ninja
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mesonbuild/mesonmain.py", line 140, in 
run
return options.run_func(options)
  File "/usr/lib/python3/dist-packages/mesonbuild/msetup.py", line 253, in run
app.generate()
  File "/usr/lib/python3/dist-packages/mesonbuild/msetup.py", line 161, in 
generate
self._generate(env)
  File "/usr/lib/python3/dist-packages/mesonbuild/msetup.py", line 223, in 
_generate
intr.backend.generate()
  File "/usr/lib/python3/dist-packages/mesonbuild/backend/ninjabackend.py", 
line 519, in generate
self.generate_target(t)
  File "/usr/lib/python3/dist-packages/mesonbuild/backend/ninjabackend.py", 
line 789, in generate_target
o = self.generate_single_compile(target, src, True,
  File "/usr/lib/python3/dist-packages/mesonbuild/backend/ninjabackend.py", 
line 2372, in generate_single_compile
obj_basename = self.object_filename_from_source(target, src)
  File "/usr/lib/python3/dist-packages/mesonbuild/backend/backends.py", line 
581, in object_filename_from_source
source = 'meson-generated_' + os.path.relpath(rel_src, targetdir)
  File "/usr/lib/python3.9/posixpath.py", line 471, in relpath
start_list = [x for x in abspath(start).split(sep) if x]
  File "/usr/lib/python3.9/posixpath.py", line 379, in abspath
cwd = os.getcwd()
OSError: [Errno 14] Bad address
cd build && tail -v -n \+0 meson-logs/meson-log.txt
...


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

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

Versions of packages proot depends on:
ii  libc6   2.31-13+deb11u3
ii  libtalloc2  2.3.1-2+b1

proot recommends no packages.

proot suggests no packages.

-- no debconf information

Bug#1011322: waypipe: ftbfs on riscv64 (Timeout: 2)

2022-05-20 Thread Gard Spreemann


Bo YU  writes:

> On Fri, May 20, 2022 at 02:35:45PM +0200, Gard Spreemann wrote:
>>Hello, and thanks you the bug report and patch.
>>
>>Bo YU  writes:
>>
>>> […]
>>>
>>> The attached patch is simple to disable tests like mips do that.
>>>
>>> If you need me to do more test, please let me know.
>>
>>I believe upstream has made changes that look like they might deal with
>>the test failures on all architectures. From
>>https://gitlab.freedesktop.org/mstoeckl/waypipe/ it looks like commits
>>
>> ffd2d4379e481372ca6240f4b3bcedbd943dec4c
>>
>> 15aab5c344636336f5327d91d3e6a92733503312
>>
>>might do the trick (on all architectures). I was waiting for upstream to
>>make a new release with those changes, but they haven't yet. If you
>>could cherry-pick those two commits and see if they fix the bug on
>>riscv64, then that would be most appreciated. Thanks!
>
> Ok, very happy to do it:)
>
> But there is some trickes for me: how to cherry-pick these commits
> into package that is come from `apt source`?
>
> One way is put the two commits into one patch and apply it into
> d/patches?

I think the way you're suggesting is a good idea. That's anyway how I'd
represent the commits when applying the fix to the Debian
package. Thanks!

PS: This shouldn't be a high priority. At some point, upstream will
surely release a new version with these fixes in place, obsoleting the
patch :-)


 Best,
 Gard
 


signature.asc
Description: PGP signature

Bug#1006277: RFP: easyeffects -- Audio effects for PipeWire applications (formerly - pulseeffects)

2022-05-20 Thread Boyuan Yang

X-Debbugs-Cc: debian-multime...@lists.debian.org lebedev...@gmail.com

Hi,

On Tue, 22 Feb 2022 19:27:22 +0300 Roman Lebedev 
wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-multime...@lists.debian.org, by...@debian.org
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name    : easyeffects
>   Version : 6.2.3
>   Upstream Author : wwmm 
> * URL : https://github.com/wwmm/easyeffects
> * License : GNU GPL v3
>   Programming Lang: C++
>   Description : Audio effects for PipeWire applications (formerly -
pulseeffects)
> 
> The existing Debian package named pulseeffects is dead upstream,
> and the new versions are called easyeffects.
> 
> I'm not sure whether pulseeffects can be used with pipewire,
> or of easyeffects can be used with pulseaudio,
> but i think they can simply be packaged in parallel,
> at least for a bit.
> 
> Lately, i've been using pulseeffects more and more, so i believe
> that packaging easyeffects may make the migration to pipewire
> almost seamless.

Please check out https://github.com/wwmm/easyeffects/issues/1000 and
https://bugs.debian.org/980839 for more information. Any help would be
appreciated.

Thanks,
Boyuan Yang


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

Bug#1011347: RM: coq-float -- ROM; abandoned upstream since years

2022-05-20 Thread Julien Puydt

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: jpu...@debian.org, debian-ocaml-ma...@lists.debian.org

This package has been abandoned upstream for years (last release tagged 2 Dec
2019).

It's in FTBFS since years (bug #970453, filed Wed, 16 Sep 2020 17:19:03 +0200).

I proposed its removal a few months ago (Sat, 19 Feb 2022 11:32:59 +0100),
stating I would wait a few weeks, and forgot about it.

I checked with dak that it's really alone in the world.

Please put the poor thing out of misery,

J.Puydt

Bug#988540: im-config: breaks the keyboard configuration

Control: summary -1 0

im-config can be disabled to avoid breaking the keyboard input using XKB input 
(ZOOM
user)

thanks

Bug#965156: RFP: NoiseTorch -- PulseAudio noise suppressor

2022-05-20 Thread Antoine Beaupré

Just a heads up that there are some "noises" (pun intended) about a
possible compromise of the NoiseTorch source code upstream:

https://www.gamingonlinux.com/2022/05/developer-of-popular-noise-suppression-tool-noisetorch-has-dev-machine-compromised/
https://github.com/lawl/NoiseTorch/commit/014236037eb5ba456c4dae24a0ebaf2caeb1510f

Followup in:

https://github.com/lawl/NoiseTorch/issues/254

It would seem wise to hold off on any packaging until the above is resolved.

-- 
Omnis enim ex infirmitate feritas est.
All cruelty springs from weakness.
 - Lucius Annaeus Seneca (58 AD)

Bug#1004363: Info received (ibus: pops up window with accent mark)

Control: summary -1 0

im-config can be disabled to disable ibus running

thanks

Bug#877125: dtc: build errors with swig for python lib


I have attached a patch to solve this.
This enables the build but does not touch the packaging, which is left for 
#1011282.
So the package build will abort on dh_missing with the new files.From 88fff697d96c8f65c9b40792a066526c8dcac467 Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Fri, 20 May 2022 17:01:09 +0200
Subject: [PATCH] Enable pylibfdt build (Closes: #877125)

Include two post-1.6.1 upstream commits to allow building with Python 3.10
and setuptools. The patch also introduces setuptools_scm, which is why this
needs to be included in the Build-Dependencies.

Fix d/rules' CFLAGS handling. The upstream Makefile overrides the passed
CFLAGS but it contains EXTRA_CFLAGS to add more. The previously contained
CFLAGS amount to the default on Linux.
---
 debian/control|   4 +
 .../02_Move_setup.py_to_the_top_level.patch   | 132 ++
 debian/patches/03_fix_with_Python_3.10.patch  |  55 
 debian/patches/series |   2 +
 debian/rules  |  13 +-
 5 files changed, 198 insertions(+), 8 deletions(-)
 create mode 100644 debian/patches/02_Move_setup.py_to_the_top_level.patch
 create mode 100644 debian/patches/03_fix_with_Python_3.10.patch

diff --git a/debian/control b/debian/control
index d60b092..f82e53c 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,10 @@ Build-Depends: debhelper-compat (= 13),
  bison,
  libyaml-dev,
  pkg-config,
+ python3-dev,
+ python3-setuptools,
+ python3-setuptools-scm,
+ swig,
  texlive ,
  texlive-latex-extra ,
  valgrind [amd64 arm64 armhf i386 mips mips64el mipsel powerpc ppc64 ppc64el s390x],
diff --git a/debian/patches/02_Move_setup.py_to_the_top_level.patch b/debian/patches/02_Move_setup.py_to_the_top_level.patch
new file mode 100644
index 000..372242a
--- /dev/null
+++ b/debian/patches/02_Move_setup.py_to_the_top_level.patch
@@ -0,0 +1,132 @@
+Origin: backport, 23b56cb7e18992650c79a04c9e4e3f2740bc1fbd
+From: Rob Herring 
+Date: Wed, 10 Nov 2021 19:11:35 -0600
+Subject: pylibfdt: Move setup.py to the top level
+
+Using 'pip' and several setup.py sub-commands currently don't work with
+pylibfdt. The primary reason is Python packaging has opinions on the
+directory structure of repositories and one of those appears to be the
+inability to reference source files outside of setup.py's subtree. This
+means a sdist cannot be created with all necessary source components
+(i.e. libfdt headers). Moving setup.py to the top-level solves these
+problems.
+
+With this change. the following commands now work:
+
+Creating packages for pypi.org:
+./setup.py sdist bdist_wheel
+
+Using pip for installs:
+pip install .
+pip install git+http://github.com/robherring/dtc.git@pypi-v2
+
+Signed-off-by: Rob Herring 
+Message-Id: <2021011135.2386773-5-r...@kernel.org>
+Signed-off-by: David Gibson 
+---
+ MANIFEST.in|  9 
+ pylibfdt/Makefile.pylibfdt |  3 +--
+ pylibfdt/meson.build   |  4 ++--
+ setup.py   | 51 ++
+ 6 files changed, 67 insertions(+), 54 deletions(-)
+ create mode 100644 MANIFEST.in
+ create mode 100755 setup.py
+
+diff --git a/MANIFEST.in b/MANIFEST.in
+new file mode 100644
+index 000..9e6c4ac
+--- /dev/null
 b/MANIFEST.in
+@@ -0,0 +1,9 @@
++# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
++
++global-exclude *
++include setup.py
++include pylibfdt/libfdt.i
++include pylibfdt/*.py
++include libfdt/libfdt.h
++include libfdt/fdt.h
++include libfdt/libfdt_env.h
+diff --git a/pylibfdt/Makefile.pylibfdt b/pylibfdt/Makefile.pylibfdt
+index 015a05e..82f565e 100644
+--- a/pylibfdt/Makefile.pylibfdt
 b/pylibfdt/Makefile.pylibfdt
+@@ -9,8 +9,7 @@ PYLIBFDT_CLEANFILES = $(PYLIBFDT_CLEANFILES_L:%=$(PYLIBFDT_dir)/%)
+ PYLIBFDT_CLEANDIRS_L = build __pycache__
+ PYLIBFDT_CLEANDIRS = $(PYLIBFDT_CLEANDIRS_L:%=$(PYLIBFDT_dir)/%)
+ 
+-SETUP = $(PYLIBFDT_dir)/setup.py
+-SETUPFLAGS = --top-builddir .
++SETUP = ./setup.py
+ 
+ ifndef V
+ SETUPFLAGS += --quiet
+diff --git a/pylibfdt/meson.build b/pylibfdt/meson.build
+index fad5aa1..f684cbb 100644
+--- a/pylibfdt/meson.build
 b/pylibfdt/meson.build
+@@ -1,5 +1,5 @@
+-setup_py = find_program('setup.py')
+-setup_py = [setup_py.path(), '--quiet', '--top-builddir', meson.current_build_dir() / '..']
++setup_py = find_program('../setup.py')
++setup_py = [setup_py.path(), '--quiet', '--top-builddir', meson.project_build_root()]
+ 
+ custom_target(
+   'pylibfdt',
+diff --git a/setup.py b/setup.py
+new file mode 100755
+index 000..4b07be9
+--- /dev/null
 b/setup.py
+@@ -0,0 +1,51 @@
++#!/usr/bin/env python3
++# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
++
++# While Python 3 is the default, it's also possible to invoke
++# this setup.py script with Python 2.
++
++"""
++setup.py file for SWIG libfdt
++Copyright (C) 2017 Google, Inc.
++Written by Simon Glass 
++"""
++
++from setuptools import setup,

Bug#1011346: Enabling V4L2 Driver in Chromium Builds

2022-05-20 Thread Andres Salomon

Package: chromium
Severity: wishlist

On Fri, May 20, 2022 at 06:42, Eschenbacher.Stefan
wrote:

Dear Debian Chromium Team,

I am testing Debian Testing/Bookworm ARM64 with a NXP i.MX8MM board
and Kernel 5.17. I try to use the new stateless v4l2 Linux API for
video acceleration. The i.MX8MM has ha Hantro G1 and G2 stateless
VPU. The VPU runs nice with Gstreamer 1.20 from Debian Testing
/Bookworm if I use the following syntax:

gst-launch-1.0 filesrc
location=~/Downloads/mixkit_night_tour_through_the_streets_of_a_big_city_40747_1_c18d1a09b3.mp4
! parsebin ! v4l2slh264dec ! waylandsink

According to this link Chromium supports the new v4l2 request API for
stateless VPUs as well:

Enabling V4L2 Driver in Chromium Builds (google.com)

The following build flag must be set to enable it:

“use_v4l2_codec=true”

I have taken a look into “rules” file of
http://deb.debian.org/debian/pool/main/c/chromium/chromium_101.0.4951.64-1.debian.tar.xz
.
There is no “use_v4l2_codec=true” entry. Is this flag set in
another location? If I run Chromium 101 from Debian Testing with
“--enable-features=VaapiVideoDecoder”chrome://gpu shows “Video
decode=hardware accelerated” but CPU usage is still high. Could you
add this flag in the future?

Mit freundlichen Grüßen / Kind Regards

* *

*Stefan Eschenbacher*–Test Engineer

Scheidt & Bachmann GmbH
Quality Assurance
Breite Straße 132 – 41238 Mönchengladbach – Germany
Phone: +49 2166 266-1199
eschenbacher.ste...@scheidt-bachmann.de

www.scheidt-bachmann.com

*Follow us:*

* *

Court of Record: HRB 2125 Registergericht Mönchengladbach, VAT ID
No: DE 120830018 | SK 4120154764, WEEE No: DE

Chairman of supervisory board: Andreas Schmitz
Managing Directors: Dr.-Ing.Norbert Miller (CEO), Dipl.-Ing. Heinrich
Laumen, Dipl.-Ing. Matthias Augustyniak,
Martin Kammler, Dipl.-Oec. Uwe Brünner,Dipl.-Ing. Jörg M.
Heilingbrunner, Dr.-Ing. Michael Lenders

Please see our data privacy policy:

Important Notice:This E-Mail and any files attached are confidential
and may contain privileged information. If you are not the intended
recipient, do not forward or disclose this E-Mail, open any
attachments, make any copies or save this E-Mail anywhere. Please
delete this E-Mail from your system and notify the sender (as
applicable also by phone +49 2166 266-0). Thank you very much.

Please consider the environment - do you really need to print this
email?

Bug#1004363: ibus: pops up window with accent mark

Control: tags -1 wontfix
Control: severity -1 wishlist
Control: summary -1 0
thanks

Since ibus can be taught to provide XKB functionality with proper 
configuration, loss
of old way of setting input is wishlist bug request.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988540#116

Bug#988540: im-config: breaks the keyboard configuration

Control: tags -1 wontfix
Control: severity -1 wishlist
Control: retitle -1 im-config: breaks the keyboard input using XKB input (ZOOM
user)
Control: summary -1 0
thanks

Classic X environment supports to enter non-ASCII (latin) characters via XKB
input
and some people still want to use this via this old setting method.

Bug was filed by an annoyed user who lost access to functionalities offered by
his
old fashioned XKB input setting. This happened because ZOOM (this package is
external to Debian) provides its DEB package with its "Depends" listing ibus.

It is reasonable for ZOOM to support Chinese and Japanese input and list ibus as
dependency. (XKB can't support Chinese nor Japanese input)

ibus merely recommends im-config for easy set-up but this fact pulls in
im-config as
its default behavior.

im-config is a glue layer code to support keyboard input with focus to use
modern
mothods (such as ibus). im-config's default behavior is to use ibus (reasonable
default choice).

ibus can (I think) offer XKB equivalent input functionality if configured
correctly.
I don't use such feature so I can't explain with confidence. Here are some
references which might help.
*
https://superuser.com/questions/1637594/how-to-pass-xkb-options-to-ibus-and-use-them-with-m17n-engines
(2021)
* https://vas.neocities.org/custom_keyboard_layout_xkb_ibus.html (2020)
* https://askubuntu.com/questions/1139936/ubuntu-mate-disable-xkb-and-use-ibus
(2019)
* https://askubuntu.com/questions/1077683/ibus-xkb-engine-layouts-dont-work
(2018)
* https://wiki.archlinux.org/title/IBus#Troubleshooting

(If I recall correctly, ibus-xkb code has been merged into ibus. ibus should
offer
this XKB input functionality by now.)

Also for im-config, im-config can be configured not to use ibus by running this
command:

im-config -n none

and reboot.

For both ibus and im-config, the desirable user experience can be provided by
proper
user configuration.

So there is no bug on im-config's parts. (Besides, you can remove im-config too
since it is only recommended.)

I consider this bug report as wishlist bug for the default of im-config.

With the above assessment, I mark this as wontfix and leave this here to help
ZOOM
user :-)

(Please note GNOME forces to use ibus even when you disable or remove
im-config.)

Regards,

Osamu

Bug#866334: About Bug#866334: RFP: lean -- theorem prover from Microsoft Research

2022-05-20 Thread Bill Allombert

On Mon, Sep 16, 2019 at 08:39:56PM +0100, Julian Gilbey wrote:
> I've just started looking at lean.  One of the issues around packaging
> it is that different lean "scripts" (not sure the correct word here)
> require different versions of lean.  There is a script available which
> downloads the required version of lean for any particular script, and
> so keeps a local set of lean versions.
> 
> If we were to package lean for Debian, what exactly would we package?
> The current stable version, or a script such as this?  See
> https://github.com/leanprover-community/mathlib/blob/master/docs/install/debian_details.md
> for a little more on this.
> 
> Thoughts would be appreciated!

Lean is now the theorem prover with the largest community, so it would
be nice to have it in Debian. However I do not know how usable it is
outside the visual studio IDE.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#1011322: waypipe: ftbfs on riscv64 (Timeout: 2)

2022-05-20 Thread Bo YU


On Fri, May 20, 2022 at 02:35:45PM +0200, Gard Spreemann wrote:

Hello, and thanks you the bug report and patch.

Bo YU  writes:


[…]

The attached patch is simple to disable tests like mips do that.

If you need me to do more test, please let me know.


I believe upstream has made changes that look like they might deal with
the test failures on all architectures. From
https://gitlab.freedesktop.org/mstoeckl/waypipe/ it looks like commits

ffd2d4379e481372ca6240f4b3bcedbd943dec4c

15aab5c344636336f5327d91d3e6a92733503312

might do the trick (on all architectures). I was waiting for upstream to
make a new release with those changes, but they haven't yet. If you
could cherry-pick those two commits and see if they fix the bug on
riscv64, then that would be most appreciated. Thanks!


Ok, very happy to do it:)

But there is some trickes for me: how to cherry-pick these commits into 
package that is come from `apt source`?


One way is put the two commits into one patch and apply it into
d/patches?

I build package with sbuild normally.

Thank you~

Bo




Best,
Gard

Bug#1011345: transition: rakudo

2022-05-20 Thread M. Zhou

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

Dear release team,

We have uploaded rakudo 2022.04 to experimental, and would like to
start the transition and rebuild packages

Ben file:

title = "rakudo";
is_affected = .depends ~ "raku-api-2022.02" | .depends ~ "raku-api-2022.04";
is_good = .depends ~ "raku-api-2022.04";
is_bad = .depends ~ "raku-api-2022.02";
Thank you for using reportbug

Bug#649146:

2022-05-20 Thread Fitri Adi



Dapatkan Outlook untuk Android

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

2022-05-20 Thread Zhang Boyang


Package: debian-cd

Hello,

I suggest debian release a new variant of ISO images, the all-in-one 
images. These all-in-one image contains ALL debian packages in a single 
ISO image (possibly all source packages in another all-in-one ISO 
image). Of course there is no such optical media can hold such a big 
image, but it is useful for virtual-machines, remotely managed servers, 
and archival purposes. The theoretical size limit of an ISO9660 
filesystem is about 8TB, which is sufficient for including all debian 
packages.


For the name of this variant, I suggest 'everything', 'allinone', 
'world', 'virt'.


p.s. This is my personal interest, and I would appreciate if you can 
kindly consider my suggestion.



Best Regards,
Zhang Boyang

Bug#939170: Setting Discrete TPM made the difference

2022-05-20 Thread Uwe Steinmann

I'm running a T560 for many years, it always had problems coming
back from suspend. It wasn't related to any kernel version starting
from 5.10.x A half way working work around was to send the laptop
into hybrid sleep. It wouldn't come back from sleep when the lid was
opened or the power button was pressed, but hard resetting it, at least
allowed me to hibernate from disc. After that initial procedure it
worked for weeks or even month with at least opening and closing the
lid once a day. But recently (after more than 3 month running without
a reboot) that trick didn't do it anymore. I couldn't figure out why.
I even updated the bios without any success.

Setting 'Discrete TPM' finally made it work again, even without any work
around.

  Uwe


signature.asc
Description: PGP signature

Bug#1011333: /usr/bin/pdftosrc: CVE-2021-27548 - null-pointer deference in XFAScanner::scanNode used by pdftosrc

2022-05-20 Thread Hilmar Preuße


Am 20.05.2022 um 11:16 teilte Neil Williams mit:

Hello Neil,


texlive-binaries in unstable, experimental and bookworm embeds
xpdfreader 4.03 and the code is exposed via the pdftosrc binary.

The PoC file from the CVE triggers a segmentation fault in pdftosrc.
pdftosrc from bullseye (correctly) reports a broken PDF without
crashing as texlive-binaries in bullseye embeds xpdfreader 4.02.

I could simply copy the appropriate commit from upstream [1] and put it 
into our package. The package still builds and it seems to solve the 
issue (see below). I'd do another upload to experimental and upload TL 
2022 (containing the fix) to unstable in about 2 weeks.


Would the time frame be OK for you?

Hilmar

hille@sid-amd64:~/devel/TeXLive$ ./pdftosrc file.pdf
pdftosrc version 4.04

libxpdf: Syntax Error (92917): Command token too long

libxpdf: Syntax Error (93045): Command token too long

libxpdf: Syntax Error (93173): Command token too long

libxpdf: Syntax Error: Couldn't read xref table

libxpdf: Syntax Warning: PDF file is damaged - attempting to reconstruct 
xref table...

No SourceObject found

[1] 
https://github.com/TeX-Live/texlive-source/commit/b20034c3cf23f813a70cb60de8e1761a443f5fbf.patch

--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980542: cockpit : 389ds tab is empty and does not appear in installed applications

2022-05-20 Thread Andreas Bock

I can confirm this bug for Ubuntu Jammy and kinetic. All files are 
missing in '/usr/share/cockpit/389-console'.


Already posted this in Ubuntu Launchpad as 
https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/1974329:


What happend:
After installing the server and afterwards the '389-ds' package 
including all dependencies, Cockpit lacks the plugins entry "389 
Directory Server" in the Web-GUI.


How to reproduce:
I installed Ubuntu server 22.04 multiple times from scratch. Either as 
minimal but althought as default installation does not help. After lots 
of testing and reinstalling the server I found that all files from 
'/usr/share/cockpit/389-console' are missing for the jammy and kinetic 
package 'cockpit-389-ds'. If one compares the package content to focal 
one will see the difference.


What I have done to resolve the issue:
$ wget 
https://github.com/389ds/389-ds-base/archive/389-ds-base-2.0.15.tar.gz

$ tar xzf 389-ds-base-2.0.15.tar.gz
$ cd ~/389-ds-base-2.0.15/src/cockpit/389-console
$ sh ./buildAndRun.sh # Stop the script after downloading and compling 
with ^C
$ sudo cp ~/389-ds-base-2.0.15/src/cockpit/389-console/dist/* 
/usr/share/cockpit/389-console




If you have any further questions feel free to contact me.

Regards, Andreas


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1011322: waypipe: ftbfs on riscv64 (Timeout: 2)

2022-05-20 Thread Gard Spreemann

Hello, and thanks you the bug report and patch.

Bo YU  writes:

> Package: waypipe
> Version: 0.8.2-3
> Severity: normal
> Tags: ftbfs, patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
>
> Dear Maintainer,
>
> The waypipe package has a ftbfs issue on riscv64 arch:
>
> […]
>
> The attached patch is simple to disable tests like mips do that.
>
> If you need me to do more test, please let me know.

I believe upstream has made changes that look like they might deal with
the test failures on all architectures. From
https://gitlab.freedesktop.org/mstoeckl/waypipe/ it looks like commits

 ffd2d4379e481372ca6240f4b3bcedbd943dec4c

 15aab5c344636336f5327d91d3e6a92733503312

might do the trick (on all architectures). I was waiting for upstream to
make a new release with those changes, but they haven't yet. If you
could cherry-pick those two commits and see if they fix the bug on
riscv64, then that would be most appreciated. Thanks!

 Best,
 Gard

signature.asc
Description: PGP signature

Bug#1011342: mini-dinstall: install_permissions does not understand octal

2022-05-20 Thread David Bremner

Package: mini-dinstall
Version: 0.7.0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I suspect (but did not verify) this is related to the port to python3.

The mini-dinstall docs say that the default value for incoming_permissions is 
0755. If you place

incoming_permissions = 0755

in .mini-dinstall it is interpreted as decimal, with fairly bizarre resulting 
permissions.
0o755 yields

Traceback (most recent call last):
  File "/usr/bin/mini-dinstall", line 252, in 
incoming_permissions = configp.getint('DEFAULT', 'incoming_permissions')
  File "/usr/lib/python3.9/configparser.py", line 818, in getint
return self._get_conv(section, option, int, raw=raw, vars=vars,
  File "/usr/lib/python3.9/configparser.py", line 808, in _get_conv
return self._get(section, conv, option, raw=raw, vars=vars,
  File "/usr/lib/python3.9/configparser.py", line 803, in _get
return conv(self.get(section, option, **kwargs))
ValueError: invalid literal for int() with base 10: '0o750'

As a workaround, I was able to enter

incoming_permissions = 488

which works, but is bit cryptic. In this specific case I could also
accept the defaults, I suppose.

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

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

Versions of packages mini-dinstall depends on:
ii  apt-utils2.5.0
ii  python3  3.10.4-1+b1
ii  python3-apt  2.3.0+b1

Versions of packages mini-dinstall recommends:
ii  gpgv  2.2.35-2

Versions of packages mini-dinstall suggests:
ii  debian-keyring  2022.04.26

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmKHiQcACgkQA0U5G1Wq
FSEsBQ//YmSlaWQ1gwVm8ov1lfv5oBf7L0yfI4AfIlsJi29DFe3vt3ZQSE+1A47v
M9rqqaDqtV4FSHdKmbRj2x9INAe9Hf4Rrq8HfBc8M+qbMbCSGst2uNmBpo7q2w0l
xlUPNAPw1+3VUTh4bQTB543oPxvGpnaLCkcd50RsAedvgiUKjd5BpFX5KdqNKXjN
X+3MH/hMlywVzSBV8jRW5LSw0EIgl/Bn5nOZgkrh+2l3ZtXQTv1av3O1DA6lM785
FFvBPWH3xSut4weJZBwCW3Yh+v7MhWZO5Gily4hPGqhAZkxAPkctqHDSEHCsGKks
16GNpXPEiJOiCDRgnUgTdc2nhzsNj3Cbjgb4MTHZvw7JPK/3W/Qp48Ei+gMnQZP+
xpxfuoeyhJ21pLt9jsEI6cCXyKPTB5gqwloLu486Me6wqSfSXYpS8eUeX68WR6Vz
v8ODMDiHU8zCbzyp396yv5++rYAM50EDM5Q0k83a1eoE/dVxv9qBGdRWQcIhs0f6
aUQEunpRuRlRLs1sc+xNqE6qkpdBM2aYniRpXvaU7aRz1zD/ha3zyvf+SRDKVnUv
m3fmOQYfZOHhmhVUfh7lmFaSJHe/UkRi4DuYl8KGORZEJENMt3pXfJIEcqHyy8BJ
Q6jjBblsc9+q0HghXNXHOmJkG/wAvH2/54P0TWR6XaQMOPV9PB0=
=hq/3
-END PGP SIGNATURE-

Bug#967647: mtr: depends on deprecated GTK 2

2022-05-20 Thread Jordi Mallach

Hi Roger,

El dv. 20 de 05 de 2022 a les 12:33 +0200, en/na Rogier Wolff va
escriure:
> 
> For Debian I then need to create a release I think. 
> 
> I'll try to do that soon. Thanks for testing. 

I'm not sure I understand. Debian unstable and Debian testing have MTR
0.95 which has GTK-3 support, so there's no need for a new release as
far as I can tell.

The version in Debian stable can't be upgraded, so it will remain using
GTK-2 until it's superseeded by a new stable version next year.

Jordi

-- 
Jordi Mallach 
Debian Project

Bug#1011341: node-formidable: CVE-2022-29622 - attackers able to execute arbitrary code via file upload

2022-05-20 Thread Neil Williams

Source: node-formidable
Version: 3.2.3+20220426git971e3a7+~cs4.0.8-1
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for node-formidable.

CVE-2022-29622[0]:
| An arbitrary file upload vulnerability in formidable v3.1.4 allows
| attackers to execute arbitrary code via a crafted filename.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-29622
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29622

Please adjust the affected versions in the BTS as needed.

Note: It is unclear whether this CVE has been reported upstream.



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

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

Bug#1011340: Does not include an autopkgtest and missing depends

2022-05-20 Thread Sebastien Bacher


Package: wireplumber
Version: 0.4.10-1

It would be nicer if the package had autopkgtests testing. The attached 
patch is adding a trivial build test on the model of the ones used for 
most GNOME libraries, it ensure that a simple case builds and that the 
dev isn't missing any depends.


We are using that change in Ubuntu now as having tests is a requirement 
to promote packages and we plan to preinstall wireplumber as part of the 
switch to pipewire.
The missing depends have been caught by the test failing on our first 
upload ;-)


Thanks for considering


diff -Nru wireplumber-0.4.10/debian/changelog wireplumber-0.4.10/debian/changelog
--- wireplumber-0.4.10/debian/changelog	2022-05-11 14:01:51.0 +0200
+++ wireplumber-0.4.10/debian/changelog	2022-05-19 15:26:07.0 +0200
@@ -1,3 +1,13 @@
+wireplumber (0.4.10-2) UNRELEASED; urgency=medium
+
+  * debian/tests: 
+- add a basic build autopkgtest for the library
+  * debian/control:
+- libwireplumber-0.4-dev depends on libglib2.0-dev and libglib2.0-dev,
+  those are required by the .pc
+
+ -- Sebastien Bacher   Thu, 19 May 2022 15:26:07 +0200
+
 wireplumber (0.4.10-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru wireplumber-0.4.10/debian/control wireplumber-0.4.10/debian/control
--- wireplumber-0.4.10/debian/control	2022-05-11 14:01:51.0 +0200
+++ wireplumber-0.4.10/debian/control	2022-05-19 15:26:07.0 +0200
@@ -43,6 +43,8 @@
 Architecture: linux-any
 Multi-Arch: same
 Depends: ${misc:Depends},
+ libglib2.0-dev,
+ libpipewire-0.3-dev,
  libwireplumber-0.4-0 (= ${binary:Version}),
  gir1.2-wp-0.4 (= ${binary:Version}),
 Description: Development files for WirePlumber
diff -Nru wireplumber-0.4.10/debian/tests/build wireplumber-0.4.10/debian/tests/build
--- wireplumber-0.4.10/debian/tests/build	1970-01-01 01:00:00.0 +0100
+++ wireplumber-0.4.10/debian/tests/build	2022-05-19 15:26:07.0 +0200
@@ -0,0 +1,30 @@
+#!/bin/sh
+# autopkgtest check: Build and run a program against libwireplumber, to verify that
+# the headers and pkg-config file are installed correctly
+
+set -e
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cat < libwireplumber_test.c
+#include 
+
+int main(void)
+{
+  wp_init (WP_INIT_ALL);
+  return 0;
+}
+EOF
+
+# deliberately word-splitting pkg-config output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -o libwireplumber_test libwireplumber_test.c \
+$("${CROSS_COMPILE}pkg-config" --cflags --libs wireplumber-0.4)
+echo "build: OK"
+[ -x libwireplumber_test ]
+./libwireplumber_test
+echo "run: OK"
diff -Nru wireplumber-0.4.10/debian/tests/control wireplumber-0.4.10/debian/tests/control
--- wireplumber-0.4.10/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ wireplumber-0.4.10/debian/tests/control	2022-05-19 14:05:24.0 +0200
@@ -0,0 +1,3 @@
+Tests: build
+Depends: build-essential, pkg-config, libwireplumber-0.4-dev
+Restrictions: allow-stderr superficial

Bug#975582: mypaint: MyPaint does not start

2022-05-20 Thread Pedro Ângelo

On Fri, 2021-01-15 at 14:36 -0500, Boyuan Yang wrote:
> Control: tags -1 +help
> 
> 在 2021-01-15星期五的 18:58 +0100，Andreas Beckmann写道：
> > Followup-For: Bug #975582
> > Control: reopen -1
> > Control: retitle -1 mypaint: insufficient python dependency
> > 
> > mypaint ships /usr/lib/mypaint/lib/_mypaintlib.cpython-39-x86_64-
> > linux-gnu.so
> > but has only a dependency on python3:any - this may be a bug in
> > dh_python3 or
> > mypaint's usage of dh_python3, but I don't have enough experience
> > with
> > python packages to spot the error.
> > 
> > For example, ycmd ships /usr/lib/ycmd/ycm_core.cpython-39-x86_64-
> > linux-gnu.so
> > and has these python dependencies:
> > libpython3.9 (>= 3.9.0~b4), python3 (<< 3.10), python3 (>= 3.9~),
> > python3:any
> 
> I don't have a solution to it either. Any help would be appreciated.
> 
> Thanks,
> Boyuan Yang

Dear maintainer,

it seems this bug affects the version of mypaint currently in testing. When I
try to start mypaint I get:

INFO: mypaint: Installation layout: conventional POSIX-like structure with
prefix '/usr'
Traceback (most recent call last):
  File "/usr/bin/mypaint", line 293, in 
= get_paths()
  File "/usr/bin/mypaint", line 241, in get_paths
from lib import fileutils
  File "/usr/lib/mypaint/lib/fileutils.py", line 25, in 
import lib.helpers
  File "/usr/lib/mypaint/lib/helpers.py", line 25, in 
from . import mypaintlib
  File "/usr/lib/mypaint/lib/mypaintlib.py", line 13, in 
from . import _mypaintlib
ImportError: cannot import name '_mypaintlib' from 'lib'
(/usr/lib/mypaint/lib/__init__.py)

This seems to happen because the package ships
/usr/lib/mypaint/lib/_mypaintlib.cpython-39-x86_64-linux-gnu.so but the current
system libpython is at version 3.10.

I can confirm that rebuilding the package installs
/usr/lib/mypaint/lib/_mypaintlib.cpython-310-x86_64-linux-gnu.so and that the
program starts properly in this case.

I think this package should depend on whatever python version is currently the
system default for unstable as mentioned above.

Best regards,
P.

Bug#1011338: golang-gopkg-yaml.v3: CVE-2022-28948 - crash when attempting to deserialize invalid input

2022-05-20 Thread Neil Williams

Source: golang-gopkg-yaml.v3
Version: 3.0.0~git20200121.a6ecf24-3
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for golang-gopkg-yaml.v3-dev.

CVE-2022-28948[0]:
| An issue in the Unmarshal function in Go-Yaml v3 causes the program to
| crash when attempting to deserialize invalid input.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-28948
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28948

Please adjust the affected versions in the BTS as needed.


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

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

Bug#1011339: openssl: missing errors strings on mipsel

2022-05-20 Thread Jérémy Lal

Package: openssl
Version: 3.0.3-4
Severity: normal

Hi,

nodejs dynamically links to openssl, and since openssl >= 3,
on mipsel, some of its tests are failing, see
https://buildd.debian.org/status/package.php?p=nodejs

The failures look like openssl was configured with no-err, e.g:
AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

  Comparison {
+   message: 'error:1C8000A5:Provider routines::reason(165)'
-   message: 'error:1C8000A5:Provider routines::illegal or unsupported 
padding mode'
  }
at Object. 
(/root/debian/nodejs-16.14.2+dfsg/test/parallel/test-crypto-sign-verify.js:59:10)

I did not find if nodejs was doing a specific configuration for mipsel.

Note that mips64el and other supported archs have no such test failures.

Could it be that openssl 3 disables error strings on 32-bits platforms ?

Jérémy

Bug#1011337: ITP:php-amphp-http -- Basic HTTP primitives which can be shared by servers and clients

2022-05-20 Thread Katharina Drexel

Package: wnpp

* Package name: php-amphp-http
  Upstream Author : 2018-2022 Niklas Keller 
* License : MIT
  Description : Basic HTTP primitives which can be shared by servers and 
clients.
  .
 Amp is a non-blocking concurrency framework for PHP. It provides an event loop,
 promises and streams as a base for asynchronous programming.

Regards
Katharina

Bug#967647: mtr: depends on deprecated GTK 2

2022-05-20 Thread Rogier Wolff



For Debian I then need to create a release I think. 

I'll try to do that soon. Thanks for testing. 

Roger.

On Fri, May 20, 2022 at 12:20:29PM +0200, Jordi Mallach wrote:
> Package: mtr
> Version: 0.95-1
> Followup-For: Bug #967647
> 
> Hi,
> 
> I just tested a build for this and I can confirm this works just
> swapping libgtk2.0-dev with libgtk-3-dev in the Build-Depends.
> 
> Please upload a package linked against libgtk-3-0.
> 
> Thanks,
> Jordi
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ca_ES:ca
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages mtr depends on:
> ii  libc62.33-7
> ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
> ii  libglib2.0-0 2.72.1-1
> ii  libgtk-3-0   3.24.33-2
> ii  libjansson4  2.14-2
> ii  libncurses6  6.3+20220423-2
> ii  libtinfo66.3+20220423-2
> 
> mtr recommends no packages.
> 
> mtr suggests no packages.
> 
> -- no debconf information
> 

-- 
** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233**
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

Bug#967647: mtr: depends on deprecated GTK 2

2022-05-20 Thread Jordi Mallach

Package: mtr
Version: 0.95-1
Followup-For: Bug #967647

Hi,

I just tested a build for this and I can confirm this works just
swapping libgtk2.0-dev with libgtk-3-dev in the Build-Depends.

Please upload a package linked against libgtk-3-0.

Thanks,
Jordi

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

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

Versions of packages mtr depends on:
ii  libc62.33-7
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.1-1
ii  libgtk-3-0   3.24.33-2
ii  libjansson4  2.14-2
ii  libncurses6  6.3+20220423-2
ii  libtinfo66.3+20220423-2

mtr recommends no packages.

mtr suggests no packages.

-- no debconf information

Bug#1011311: RFS: colordiff/1.0.20-1 -- tool to colorize 'diff' output