Bug#1017076: qtbase6-dev: qt6-base-dev not being cached with apt-get server for bookworm

[Carl]

Package: qtbase6-dev
Version: qt6-base-dev
Severity: normal
X-Debbugs-Cc: carlniko...@gmail.com

Dear Maintainer,

apt-get install qt6-base-dev did not work


could not install version 6 from terminal. only version 5 came up in results
for bookworm main on sources.list despite it supposedly being listed for
bookworm on the server..

apt nor apt-get did not download files and dependencies correctly as it could
not 'Locate them'


expected to not have to download files manually from the debian file server for
version qt6-base-dev...


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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1017075: dask - autopkgtest regression on i386 and armhf

[Peter Green]

Package: dask
version: 2022.02.0+dfsg-1

dask's autopkgtest is showing regessions on armhf and i386 (amd64, arm64 and 
ppc64el pass, armel and s390x are not a regression).

https://ci.debian.net/data/autopkgtest/testing/armhf/d/dask/24684717/log.gz
https://ci.debian.net/data/autopkgtest/testing/i386/d/dask/24649779/log.gz


=== FAILURES ===
_ test_query_with_meta _

db = 'sqlite:tmp/tmpmr8qr16b.'

def test_query_with_meta(db):
from sqlalchemy import sql
data = {
"name": pd.Series([], name="name", dtype="str"),
"age": pd.Series([], name="age", dtype="int"),
}
index = pd.Index([], name="number", dtype="int")
meta = pd.DataFrame(data, index=index)
s1 = sql.select(
[sql.column("number"), sql.column("name"), sql.column("age")]
).select_from(sql.table("test"))
out = read_sql_query(s1, db, npartitions=2, index_col="number", meta=meta)
# Don't check dtype for windows https://github.com/dask/dask/issues/8620

assert_eq(out, df[["name", "age"]], check_dtype=sys.platform != "win32")


/usr/lib/python3/dist-packages/dask/dataframe/io/tests/test_sql.py:443: _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
a = name age
number 0 Alice 33
1 Bob 40
2 Chris 22
3 Dora 16
4 Edith 53
5 Francis 30
6 Garreth 20
b = name age
number 0 Alice 33
1 Bob 40
2 Chris 22
3 Dora 16
4 Edith 53
5 Francis 30
6 Garreth 20
check_names = True, check_dtype = True, check_divisions = True
check_index = True, scheduler = 'sync', kwargs = {}

def assert_eq(
a,
b,
check_names=True,
check_dtype=True,
check_divisions=True,
check_index=True,
scheduler="sync",
**kwargs,
):
if check_divisions:
assert_divisions(a, scheduler=scheduler)
assert_divisions(b, scheduler=scheduler)
if hasattr(a, "divisions") and hasattr(b, "divisions"):
at = type(np.asarray(a.divisions).tolist()[0]) # numpy to python
bt = type(np.asarray(b.divisions).tolist()[0]) # scalar conversion
assert at == bt, (at, bt)
assert_sane_keynames(a)
assert_sane_keynames(b)
a = _check_dask(
a, check_names=check_names, check_dtypes=check_dtype, scheduler=scheduler
)
b = _check_dask(
b, check_names=check_names, check_dtypes=check_dtype, scheduler=scheduler
)
if hasattr(a, "to_pandas"):
a = a.to_pandas()
if hasattr(b, "to_pandas"):
b = b.to_pandas()
if isinstance(a, (pd.DataFrame, pd.Series)):
a = _maybe_sort(a, check_index)
b = _maybe_sort(b, check_index)
if not check_index:
a = a.reset_index(drop=True)
b = b.reset_index(drop=True)
if isinstance(a, pd.DataFrame):

tm.assert_frame_equal(

a, b, check_names=check_names, check_dtype=check_dtype, **kwargs
E AssertionError: Attributes of DataFrame.iloc[:, 1] (column name="age") are 
different
E E Attribute "dtype" are different
E [left]: int32
E [right]: int64

/usr/lib/python3/dist-packages/dask/dataframe/utils.py:562: AssertionError
_ test_categorize_info _

@pytest.mark.skipif(not PANDAS_GT_120, reason="need newer version of Pandas")
def test_categorize_info():
# assert that we can call info after categorize
# workaround for: https://github.com/pydata/pandas/issues/14368
from io import StringIO
pandas_format._put_lines = put_lines
df = pd.DataFrame(
{"x": [1, 2, 3, 4], "y": pd.Series(list("aabc")), "z": pd.Series(list("aabc"))},
index=[0, 1, 2, 3],
)
ddf = dd.from_pandas(df, npartitions=4).categorize(["y"])
# Verbose=False
buf = StringIO()
ddf.info(buf=buf, verbose=True)
expected = (
"\n"
"Int64Index: 4 entries, 0 to 3\n"
"Data columns (total 3 columns):\n"
" # Column Non-Null Count Dtype\n"
"--- -- -- -\n"
" 0 x 4 non-null int64\n"
" 1 y 4 non-null category\n"
" 2 z 4 non-null object\n"
"dtypes: category(1), object(1), int64(1)\n"
"memory usage: 496.0 bytes\n"
)

assert buf.getvalue() == expected

E assert "
E Int64Index: 4 entries, 0 to 3
E Data columns (total 3 columns):
E # Column Non-Null Count Dtype
E --- -- -- -
E 0 x 4 non-null int64
E 1 y 4 non-null category...
E E ...Full output truncated (7 lines hidden), use '-vv' to show

/usr/lib/python3/dist-packages/dask/dataframe/tests/test_dataframe.py:3629: 
AssertionError
=== warnings summary ===


This is preventing the fix for bug 1013080 from migrating to testing.

Bug#1016974: sofia-sip: CVE-2022-31001 CVE-2022-31002 CVE-2022-31003

[Evangelos Ribeiro Tzaras]

control -1 tags pending

Hi again,

On Thu, 2022-08-11 at 23:52 +0200, Moritz Muehlenhoff wrote:
> On Thu, Aug 11, 2022 at 11:08:49PM +0200, Evangelos Ribeiro Tzaras wrote:
> > 
> > > If you fix the vulnerabilities please also make sure to include the
> > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> > 
> > ACK.
> > Is there a specific format needed when referencing the CVE?
> 
> Not really, just mention them in debian/changelog :-)

alright, so the patches apply cleanly and
d/changelog mentions the CVEs (and closes this bug).

> In addition we'll keep security-tracker.debian.org updated when the upload
> reaches unstable.
> 
> Once the fix is in unstable (and if there are issues reported after a few
> days) we can sort out an update for bullseye-security.

Sounds good to me! I think bullseye-security would be great, 
because I'm certain it is also vulnerable 
(oldstable potentially too - haven't checked)


-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#1017074: ITP: libpysal -- "Core components of PySAL A library of spatial analysis functions".

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: libpysal
  Version : 4.6.2
  Upstream Author : Name PySAL Developers
* URL : https://github.com/pysal/libpysal/
* License : BSD 3-Clause
  Programming Lang: Python
  Description : "Componentes principais do PySAL Uma biblioteca de funções 
de análise espacial.

libpysal offers four modules that form the building blocks in many upstream 
packages in the PySAL family:
   *  Spatial Weights: libpysal.weights
   *  Input-and output: libpysal.io
   *  Computational geometry: libpysal.cg
   *  Built-in example datasets libpysal.examples
Note:
package depends in https://github.com/pysal/pysal

Bug#1017073: python-suntime: reproducible builds: Timestamps recorded for all packaged files

[Vagrant Cascadian]

Source: python-suntime
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps locales
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

All the timestamps in python-suntime vary based on the build time:

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

  1 
-rw-r--r--···0004·2023-08-24·15:33:27.00·debian-binary
  1   
-rw-r--r--···0004·2022-07-22·09:11:52.00·debian-binary
  2 
-rw-r--r--···000·1212·2023-08-24·15:33:27.00·control.tar.xz
 2   
-rw-r--r--···000·1212·2022-07-22·09:11:52.00·control.tar.xz
  3 
-rw-r--r--···000·4196·2023-08-24·15:33:27.00·data.tar.xz
3   
-rw-r--r--···000·4200·2022-07-22·09:11:52.00·data.tar.xz

This *should* be handled by dpkg, but for some reason it does not. At
first, I thought it might be the incorrectly formatted line in
debian/changelog:

-  Sandro Tosi   Mon, 20 Jun 2022 23:02:36 -0400
+ -- Sandro Tosi   Mon, 20 Jun 2022 23:02:36 -0400

But that doesn't seem to be the case; SOURCE_DATE_EPOCH is set at all
stages during the build, and fixing this doesn't change the results.

I'm not sure why... but forcing a consistant locale appears to
fix/workaround the issue. Patch attached which sets LC_ALL and LANG to
C.UTF-8 in debian/rules, does not trigger the issue.


With this patch applied, python-suntime should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining python-suntime!


live well,
  vagrant
From 4adc1ba9ea7c004d819029c8273287091c50978f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 13 Aug 2022 02:33:12 +
Subject: [PATCH] debian/rules: Set LC_ALL and LANG to ensure reproducible
 build.

The timestamps of all files seem to vary otherwise.
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index fd7232c..b123c57 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME=suntime
+export LC_ALL=C.UTF-8
+export LANG=C.UTF-8
 
 %:
 	dh $@ --with python3 --buildsystem=pybuild
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1017072: [Pkg-rust-maintainers] Bug#1017072: rust-grcov: Please update package to 0.8.x

[Peter Green]

Severity 1017072 serious
Thanks

I'm bumping this up to serious, because the version of rust-grcov currently in 
Debian
has many broken build-dependencies, I could open a seperate bug for that but I
don't think it's worthwhile.

There is work in progress packaging for an update of rust-grcov in the 
debcargo-conf
repository, unfortunately the latest upstream version has a dependencies on a 
few
crates that are not in debian. Specifically symbolic-common, symbolic-demangle 
and
tera.

Sylvestre prepared a patch that removed the dependencies on symbolic-common and
symbolic-demangle, but the patch broke the build so I removed it from the
patch series for now. Looking at the upstream git history it looks to me
like eliminating those dependencies would be non-trivial.

So it looks like before grcov can be updated those crates need to be packaged
by someone (won't be me, I generally only package new stuff if I personally
use it).

Bug#1017072: rust-grcov: Please update package to 0.8.x

[Guillem Jover]

Source: rust-grcov
Source-Version: 0.5.15-2
Severity: wishlist

Hi!

This package is at 0.8.11 upstream, which happens to include support
for cobertura reporting. It would be nice to have the latest upstream
version packaged.

Thanks,
Guillemm

Bug#1017068: [Debian-on-mobile-maintainers] Bug#1017068: gnome-calls: sip test fails when builds are running on machines without network

[Evangelos Ribeiro Tzaras]

Hi Shannon,

thanks for your report!

On Fri, 2022-08-12 at 16:30 -0400, Shannon Brady via Debian-on-mobile-
maintainers wrote:
> Package: gnome-calls
> X-Debbugs-Cc: shannonbr...@google.com
> Version: 43~alpha.2-1
> Severity: important
> 
> Dear Maintainer,
> When building this version of gnome-call on a system that is not connected to
> the network, builds will always fail the SIP test with the following error



> (/<>/_build/tests/sip:50791): CallsSipMediaPipeline-WARNING **:
> 12:24:34.431: Error on the message bus: Could not get/set settings from/on
> resource. (../gst/udp/gstmultiudpsink.c(1228):
> gst_multiudpsink_configure_client (): /GstPipeline:media-
> pipeline/GstUDPSink:rtcp-udp-sink:
> Invalid address family (got 10))
> --
> 
> Note that address_family 10 corresponds to AF_INT6, which is odd because the
> addresses that are assigned in the test are IPv4 addresses
> (https://gitlab.gnome.org/GNOME/calls/-/blob/master/tests/test-sip.c#L274) .
> Specifically 127.0.0 which is IPv4 localhost 

This is very interesting, thanks for investigating so thoroughly!

> However, this test will succeed on a build network that does have network and
> DNS.Is this expected behaviour? I would have assumed that builds should be
> able to succeed without internet connection.

Yeah it **should**.
I'll have to reproduce this on my end and see what can be done about it
upstream.

-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#1017071: RFS: psi-notify/1.3.1-1 -- Alert when your machine is becoming oversaturated

[Michel Alexandre Salim]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "psi-notify":

 * Package name: psi-notify
   Version : 1.3.1-1
   Upstream Author : Chris Down 
 * URL : https://github.com/cdown/psi-notify
 * License : Expat
 * Vcs : https://salsa.debian.org/michel/psi-notify
   Section : utils

The source builds the following binary packages:

  psi-notify - Alert when your machine is becoming oversaturated

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

  https://mentors.debian.net/package/psi-notify/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/psi-notify/psi-notify_1.3.1-1.dsc

Changes since the last upload:

 psi-notify (1.3.1-1) unstable; urgency=low
 .
   * Update to 1.3.1
   * Patches now upstreamed
   * Allows running tests on systems with PSI disabled
   * manpage now included

Regards,

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


signature.asc
Description: PGP signature

Bug#1017070: python-etelemetry: server offline, DEP8 tests fail

[Andreas Hasenack]

Package: python-etelemetry
Version: 0.3.0-2
Severity: normal

Dear Maintainer,

the rig.mit.edu server that seems to be used by default by
python-etelemetry is offline:

$ python3
Python 3.10.6 (main, Aug 10 2022, 11:19:32) [GCC 12.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import etelemetry
>>> etelemetry.get_project("nipy/nipype")
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line
174, in _new_conn
conn = connection.create_connection(
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py",
line 96, in create_connection
raise err
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py",
line 86, in create_connection
sock.connect(sa)
TimeoutError: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py",
line 704, in urlopen
httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py",
line 387, in _make_request
self._validate_conn(conn)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py",
line 1043, in _validate_conn
conn.connect()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line
358, in connect
self.sock = conn = self._new_conn()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line
179, in _new_conn
raise ConnectTimeoutError(
urllib3.exceptions.ConnectTimeoutError:
(,
'Connection to rig.mit.edu timed out. (connect timeout=5)')
(...)

This was noted in an upstream bug report[1] from August 2021, and is
failing debci[2] and ubuntu[3] dep8 tests:

E   urllib3.exceptions.ConnectTimeoutError:
(,
'Connection to rig.mit.edu timed out. (connect timeout=5)')

I'm unsure how to proceed here, as it looks like that that server is
essential for this package to operate. Maybe skip those tests, but
still, the package itself won't be in a working state (see backtrace
above, with commands taken straight out from upstream README file
showing how to use the module).

Maybe the PR at [4] can help, as it allows for custom endpoints.


1. https://github.com/sensein/etelemetry-client/issues/35
2. 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-etelemetry/24654839/log.gz
3. 
https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/p/python-etelemetry/20220812_192355_57dbb@/log.gz
4. https://github.com/sensein/etelemetry-client/pull/39

Bug#1016710: zlib: diff for NMU version 1:1.2.11.dfsg-4.1

[Salvatore Bonaccorso]

Control: tags 1016710 + patch
Control: tags 1016710 + pending


Dear maintainer,

I've prepared an NMU for zlib (versioned as 1:1.2.11.dfsg-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru zlib-1.2.11.dfsg/debian/changelog zlib-1.2.11.dfsg/debian/changelog
--- zlib-1.2.11.dfsg/debian/changelog	2022-03-26 00:32:05.0 +0100
+++ zlib-1.2.11.dfsg/debian/changelog	2022-08-12 22:15:03.0 +0200
@@ -1,3 +1,12 @@
+zlib (1:1.2.11.dfsg-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix a bug when getting a gzip header extra field with inflate()
+(CVE-2022-37434) (Closes: #1016710)
+  * Fix extra field processing bug that dereferences NULL state->head
+
+ -- Salvatore Bonaccorso   Fri, 12 Aug 2022 22:15:03 +0200
+
 zlib (1:1.2.11.dfsg-4) unstable; urgency=medium
 
   * Pick upstream patch for CVE-2018-25032 (closes: #1008265).
diff -Nru zlib-1.2.11.dfsg/debian/patches/Fix-a-bug-when-getting-a-gzip-header-extra-field-wit.patch zlib-1.2.11.dfsg/debian/patches/Fix-a-bug-when-getting-a-gzip-header-extra-field-wit.patch
--- zlib-1.2.11.dfsg/debian/patches/Fix-a-bug-when-getting-a-gzip-header-extra-field-wit.patch	1970-01-01 01:00:00.0 +0100
+++ zlib-1.2.11.dfsg/debian/patches/Fix-a-bug-when-getting-a-gzip-header-extra-field-wit.patch	2022-08-12 22:15:03.0 +0200
@@ -0,0 +1,36 @@
+From: Mark Adler 
+Date: Sat, 30 Jul 2022 15:51:11 -0700
+Subject: Fix a bug when getting a gzip header extra field with inflate().
+Origin: https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1
+Bug-Debian: https://bugs.debian.org/1016710
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-37434
+
+If the extra field was larger than the space the user provided with
+inflateGetHeader(), and if multiple calls of inflate() delivered
+the extra header data, then there could be a buffer overflow of the
+provided space. This commit assures that provided space is not
+exceeded.
+---
+ inflate.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/inflate.c b/inflate.c
+index 7be8c63662a7..7a728974923a 100644
+--- a/inflate.c
 b/inflate.c
+@@ -763,9 +763,10 @@ int flush;
+ copy = state->length;
+ if (copy > have) copy = have;
+ if (copy) {
++len = state->head->extra_len - state->length;
+ if (state->head != Z_NULL &&
+-state->head->extra != Z_NULL) {
+-len = state->head->extra_len - state->length;
++state->head->extra != Z_NULL &&
++len < state->head->extra_max) {
+ zmemcpy(state->head->extra + len, next,
+ len + copy > state->head->extra_max ?
+ state->head->extra_max - len : copy);
+-- 
+2.36.1
+
diff -Nru zlib-1.2.11.dfsg/debian/patches/Fix-extra-field-processing-bug-that-dereferences-NUL.patch zlib-1.2.11.dfsg/debian/patches/Fix-extra-field-processing-bug-that-dereferences-NUL.patch
--- zlib-1.2.11.dfsg/debian/patches/Fix-extra-field-processing-bug-that-dereferences-NUL.patch	1970-01-01 01:00:00.0 +0100
+++ zlib-1.2.11.dfsg/debian/patches/Fix-extra-field-processing-bug-that-dereferences-NUL.patch	2022-08-12 22:15:03.0 +0200
@@ -0,0 +1,31 @@
+From: Mark Adler 
+Date: Mon, 8 Aug 2022 10:50:09 -0700
+Subject: Fix extra field processing bug that dereferences NULL state->head.
+Origin: https://github.com/madler/zlib/commit/1eb7682f845ac9e9bf9ae35bbfb3bad5dacbd91d
+
+The recent commit to fix a gzip header extra field processing bug
+introduced the new bug fixed here.
+---
+ inflate.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/inflate.c b/inflate.c
+index 7a728974923a..2a3c4fe98464 100644
+--- a/inflate.c
 b/inflate.c
+@@ -763,10 +763,10 @@ int flush;
+ copy = state->length;
+ if (copy > have) copy = have;
+ if (copy) {
+-len = state->head->extra_len - state->length;
+ if (state->head != Z_NULL &&
+ state->head->extra != Z_NULL &&
+-len < state->head->extra_max) {
++(len = state->head->extra_len - state->length) <
++state->head->extra_max) {
+ zmemcpy(state->head->extra + len, next,
+ len + copy > state->head->extra_max ?
+ state->head->extra_max - len : copy);
+-- 
+2.36.1
+
diff -Nru zlib-1.2.11.dfsg/debian/patches/series zlib-1.2.11.dfsg/debian/patches/series
--- zlib-1.2.11.dfsg/debian/patches/series	2022-03-26 00:32:05.0 +0100
+++ zlib-1.2.11.dfsg/debian/patches/series	2022-08-12 22:15:03.0 +0200
@@ -2,3 +2,5 @@
 use-dso
 use-dso-really
 CVE-2018-25032

Bug#1017069: qsstv: desktop file and icon missing from .deb

[Daniele Forsi]

Package: qsstv
Version: 9.5.8-2+b1
Severity: normal
Owner: dfo...@gmail.com
X-Debbugs-Cc: dfo...@gmail.com

Dear Team members,

qsstv isn't visible in the applications menu because the .desktop file and the 
icon aren't included in version 9.5.8-2+b1.
Looking at p.d.o., the .desktop file was included in 9.4.4-3 (but not the icon) 
and both were included in 9.2.6+repack-1.

File list in 9.5.8-2:
/usr/bin/qsstv
/usr/share/doc/qsstv/README.Debian
/usr/share/doc/qsstv/changelog.Debian.amd64.gz
/usr/share/doc/qsstv/changelog.Debian.gz
/usr/share/doc/qsstv/copyright
/usr/share/doc/qsstv/examples/CQ_1.templ
/usr/share/doc/qsstv/examples/CQ_2.templ
/usr/share/doc/qsstv/examples/comment.templ
/usr/share/doc/qsstv/examples/im_reply.templ
/usr/share/doc/qsstv/examples/simple_replay.templ
/usr/share/man/man1/qsstv.1.gz

File list in 9.2.6+repack-1:
/usr/bin/qsstv
/usr/share/applications/qsstv.desktop
/usr/share/doc/qsstv/README.Debian
/usr/share/doc/qsstv/changelog.Debian.gz
/usr/share/doc/qsstv/changelog.gz
/usr/share/doc/qsstv/copyright
/usr/share/doc/qsstv/examples/CQ_1.templ
/usr/share/doc/qsstv/examples/CQ_2.templ
/usr/share/doc/qsstv/examples/comment.templ
/usr/share/doc/qsstv/examples/im_reply.templ
/usr/share/doc/qsstv/examples/simple_replay.templ
/usr/share/man/man1/qsstv.1.gz
/usr/share/qsstv/qsstv.png

Thanks,
Daniele

Bug#1016321: boost1.74: FTBFS: runtime error: file /<>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.

[Giovanni Mascellani]

Hi,

Il 29/07/22 20:32, Lucas Nussbaum ha scritto:

During a rebuild of all packages in sid, your package failed to build
on amd64.


Thanks for filing the bug. It seems that Boost builds fine with xsltproc 
and libxslt1version 1.1.34 (instead of 1.1.35 currently in sid). I am 
not an XSLT master and it seems that nobody upstream has noticed yet, 
maybe because 1.1.35 is still relatively recent. I'll file a bug 
upstream to see if they can work out a solution.


Giovanni.

Bug#646174: coreutils: date prints wrong time zone for UTC+/-x and GMT+/-x

[Jakub Wilk]

* W. Martin Borgert , 2011-10-21, 23:20:
Maybe this is only my misunderstanding or a documentation omission. But 
I'm under the impression, that date prints the timezone incorrect in 
some cases:


$ for tz in UTC UTC+2 UTC-2 ; do TZ=$tz date ; done
Fri Oct 21 20:55:45 UTC 2011
Fri Oct 21 18:55:45 UTC 2011
Fri Oct 21 22:55:45 UTC 2011


This is unfortunate, but it works as required by POSIX; see the tzset(3) 
man page.


You may want something like this:

$ TZ=Etc/GMT+2 date
Fri Aug 12 17:29:03 -02 2022

(Note the different sign conventions.)

--
Jakub Wilk

Bug#1016526: [Pkg-openssl-devel] Bug#1016526: Bug#1016526: openssl: Regression on mips64el throws error:1E08010C:DECODER

[Jérémy Lal]

Le ven. 12 août 2022 à 21:10, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> a écrit :

> On 2022-08-02 20:18:32 [+0200], Jérémy Lal wrote:
> > Indeed, something has changed somewhere else.
>
> I've been looking at this because I assumed that something may be
> different in the init path on mips vs everywhere else leading to a
> similar kind of an error like the last time where the error strings were
> missing. That said, I haven't seen much difference between mips64el and
> amd64 here. Therefore I just wiped my home on eller.
> Let me know if you want me to look at this again.
>

Thanks a lot. I assumed the same, that's why I notified it here.

The actual issue is somewhere else between gcc11 and gcc12.

Jérémy

Bug#1016526: [Pkg-openssl-devel] Bug#1016526: Bug#1016526: openssl: Regression on mips64el throws error:1E08010C:DECODER

[Sebastian Andrzej Siewior]

On 2022-08-02 20:18:32 [+0200], Jérémy Lal wrote:
> Indeed, something has changed somewhere else.

I've been looking at this because I assumed that something may be
different in the init path on mips vs everywhere else leading to a
similar kind of an error like the last time where the error strings were
missing. That said, I haven't seen much difference between mips64el and
amd64 here. Therefore I just wiped my home on eller.
Let me know if you want me to look at this again.

> Jérémy

Sebastian

Bug#1017067: python3-lxml: missing dependency in bullseye

[michel]

Package: python3-lxml
Version: 4.6.3+dfsg-0.1+deb11u1
Severity: normal
Tags: patch
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,


i'm getting this error

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/lxml/cssselect.py", line 13, in 
import cssselect as external_cssselect
ModuleNotFoundError: No module named 'cssselect'


by installing python3-cssselect it goes away as expected.

Bug#915379: anacron.service: should probably use KillMode=process

[Melvin Vermeeren]

Hi,

I ran into this problem today. Automated upgrades with unattended-upgrades 
upgraded debianutils. Then needrestart decided that anacron.service needed to 
be restart.

However, backup cron jobs were running at the time, which take longer than a 
minute or two. After the brief timeout every single process in the chain got 
killed abruptly, without any of the actual cron job tasks even receiving a 
SIGTERM to clean up nicely. Worst of all this means the process does not even 
get a chance to report error/failure, so not mail ends up in the mailbox.

The result (with borgbackup at least) means a lot of manual work to cleanup 
stale repository locks acquired, checking some caches and manually unmount and 
removing the snapshots made for backup purposes.

I strongly feel like stopping/restarting anacron.service should never, ever 
timeout at all. A very long-running (possibly stuck) cron job should result in 
a blocking (or failing) stop action which can then be investigated properly by 
the administrator. Such as event would be a bug in another package and not a 
problem with anacron daemon.

Forcefully killing long-running cron jobs can have severe consequences. In 
today's case it was recoverable but similar cron jobs could also perform 
automated cleanup/pruning tasks in databases, registries, etc, where killing 
is very, very much undesired and effectively as bad as system crash for data 
integrity purposes.

I can think of two ways to improve this.

1. Always let jobs finish cleanly: TimeoutStopSec=infinity
I strongly prefer this option in all cases (desktop/server/...).

2. SIGUSR1 anacron as is the case now, then on timeout SIGTERM to all 
processes in the group, then on timeout again SIGKILL all processes in the 
group. I must admit I don't know how to implement this with systemd services.

Could you share thoughts regarding this issue?

Thanks,

-- 
Melvin Vermeeren
Systems engineer

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

Bug#1017063: gnome-weather: fails to start up;

[Evangelos Ribeiro Tzaras]

On Fri, 2022-08-12 at 11:47 -0400, Jeremy Bicha wrote:
> On Fri, Aug 12, 2022 at 11:18 AM Evangelos Ribeiro Tzaras
>  wrote:
> > gnome-weather errors out with a critical on my testing/sid system when
> > trying to launch it:



> Please check if downgrading your libmozjs-91-0 to the version from Testing
> fixes your issue.

You're on point: It does!

Let's see if I do this right...

control: reassign -1 libmozjs-91-0
control: affects -1 gnome-weather
control: tags -1 + sid

-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#853915:

[Gina]

Bug#853915:

[Gina]

Bug#1016779: golang-github-lucas-clemente-quic-go: Minimal change to resolve FTBFS

[William 'jawn-smith' Wilson]

Package: golang-github-lucas-clemente-quic-go
Followup-For: Bug #1016779
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

As noted in this bug, golang-github-lucas-clemente-quic-go FTBFS with
Go 1.19. This patch cherry picks the minimum change from upstream to
resolve this issue. Note that it won't build until there is a new
version of golang-github-marten-seemann-qtls-go1-19 packaged in Debian.
I have filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017034
towards this end.

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


  * Update from upstream to build qtls with Go 1.19.


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-27-generic (SMP w/32 CPU threads)
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
diff -Nru golang-github-lucas-clemente-quic-go-0.26.0/debian/control 
golang-github-lucas-clemente-quic-go-0.26.0/debian/control
--- golang-github-lucas-clemente-quic-go-0.26.0/debian/control  2022-04-01 
15:00:32.0 -0500
+++ golang-github-lucas-clemente-quic-go-0.26.0/debian/control  2022-08-11 
13:18:49.0 -0500
@@ -15,7 +15,7 @@
  golang-github-francoispqt-gojay-dev,
  golang-github-golang-mock-dev,
  golang-github-marten-seemann-qpack-dev,
- golang-github-marten-seemann-qtls-go1-18-dev,
+ golang-github-marten-seemann-qtls-go1-19-dev,
  golang-github-onsi-ginkgo-dev (>= 1.14.2),
  golang-go.opencensus-dev,
  golang-golang-x-crypto-dev,
@@ -38,7 +38,7 @@
  golang-github-cheekybits-genny-dev,
  golang-github-francoispqt-gojay-dev,
  golang-github-marten-seemann-qpack-dev,
- golang-github-marten-seemann-qtls-go1-18-dev,
+ golang-github-marten-seemann-qtls-go1-19-dev,
  golang-go.opencensus-dev,
  golang-golang-x-crypto-dev,
  golang-golang-x-net-dev,
diff -Nru 
golang-github-lucas-clemente-quic-go-0.26.0/debian/patches/0005-qtls-go-119.patch
 
golang-github-lucas-clemente-quic-go-0.26.0/debian/patches/0005-qtls-go-119.patch
--- 
golang-github-lucas-clemente-quic-go-0.26.0/debian/patches/0005-qtls-go-119.patch
   1969-12-31 18:00:00.0 -0600
+++ 
golang-github-lucas-clemente-quic-go-0.26.0/debian/patches/0005-qtls-go-119.patch
   2022-08-11 13:18:49.0 -0500
@@ -0,0 +1,152 @@
+Description: Update to build with qtls-go1-19
+ This package has a dependency that is packaged separately per
+ Go version: golang-github-marten-seemann-qtls-go1-x. This patch
+ is the minimal change from upstream to allow this package to be
+ built against Go 1.19. This patch should be dropped when a new
+ upstream version of this repository is packaged.
+Origin: upstream, 
https://github.com/lucas-clemente/quic-go/commit/ea9de26ed5499336234b8a7dfc56e9516898a3db
+Last-Update: 2022-08-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: golang-github-lucas-clemente-quic-go-0.26.0/internal/qtls/go119.go
+===
+--- golang-github-lucas-clemente-quic-go-0.26.0.orig/internal/qtls/go119.go
 golang-github-lucas-clemente-quic-go-0.26.0/internal/qtls/go119.go
+@@ -1,6 +1,99 @@
+ //go:build go1.19
+-// +build go1.19
+ 
+ package qtls
+ 
+-var _ int = "quic-go doesn't build on Go 1.19 yet."
++import (
++  "crypto"
++  "crypto/cipher"
++  "crypto/tls"
++  "net"
++  "unsafe"
++
++  "github.com/marten-seemann/qtls-go1-19"
++)
++
++type (
++  // Alert is a TLS alert
++  Alert = qtls.Alert
++  // A Certificate is qtls.Certificate.
++  Certificate = qtls.Certificate
++  // CertificateRequestInfo contains information about a certificate 
request.
++  CertificateRequestInfo = qtls.CertificateRequestInfo
++  // A CipherSuiteTLS13 is a cipher suite for TLS 1.3
++  CipherSuiteTLS13 = qtls.CipherSuiteTLS13
++  // ClientHelloInfo contains information about a ClientHello.
++  ClientHelloInfo = qtls.ClientHelloInfo
++  // ClientSessionCache is a cache used for session resumption.
++  ClientSessionCache = qtls.ClientSessionCache
++  // ClientSessionState is a state needed for session resumption.
++  ClientSessionState = qtls.ClientSessionState
++  // A Config is a qtls.Config.
++  Config = qtls.Config
++  // A Conn is a qtls.Conn.
++  Conn = qtls.Conn
++  // ConnectionState contains information about the state of the 
connection.
++  ConnectionState = qtls.ConnectionStateWith0RTT
++  // EncryptionLevel is the encryption level of a message.
++  EncryptionLevel = qtls.EncryptionLevel
++  // Extension is a TLS extension
++  Extension 

Bug#1017066: trn4: intermittent false-positive reports of new mail ("(Mail)")

[Jacob Nevins]

Package: trn4
Version: 4.0-test77-13
Severity: minor

trn4 has a feature where it can tell you if there's new mail in your
local mailbox (/var/mail/$USER or whatever), by putting "(Mail)" in the
status line, e.g.
  (Mail) -- Select a newsgroup (natural order)
(See MAILCALL and MAILFILE in the man page for a mention of this
behaviour, although I have neither of these environment variables set.)

I'm finding that this sometimes fires spuriously -- I have no unread
mail, and yet the "(Mail)" indicator appears in trn4, and persists until
something changes in my mailbox -- I can make it go away by making and
committing a trivial change to my mailbox file.

I noticed this occasionally on jessie (trn4 4.0-test77-11), but it seems
much more frequent for me (annoyingly so) on bullseye (4.0-test77-13).


I have half a theory about what's going on:

Here's the logic that trn4 uses to check for new mail (in general, code
about it is protected by "#ifdef MAILCALL"):


if (stat(mailfile,) < 0 || !filestat.st_size
|| filestat.st_atime > filestat.st_mtime)
/* don't flag new mail */
else
/* flag new mail */

So, that can flag new mail if the mailbox atime == mtime (to a whole
number of seconds), which seems like a thing that could happen if the
MUA is very on the ball about checking the mailbox file.

My MUA is mutt (run on the same machine as trn4). Between jessie
(1.5.23-3+deb8u6) and bullseye (2.0.5-4.1), mutt started using inotify
to watch mailboxes (1.11.0, "inotify is used for local mailbox
monitoring on Linux"). So it seems plausible that the condition above
could happen more often these days; if the mutt process is active, it
could plausibly access the mailbox in the same second that new mail
arrives.

In at least one instance where I've reproduced this trn4 behaviour by
sending myself mail, the timestamps seemed to support my theory:

$ stat /var/spool/mail/jacobn
...
Access: 2022-08-12 17:25:57.799257318 +0100
Modify: 2022-08-12 17:25:57.0 +0100
Change: 2022-08-12 17:25:57.799257318 +0100
 Birth: 1970-01-01 01:00:00.0 +0100

I haven't thought too hard about how this theory interacts with me, the
human, actually reading the mail in my MUA, updating the status flags,
and committing them to the mailbox file.


I haven't thought hard about what the correct fix would be, either.
Obviously it's tempting to change > to >=, but I don't know if that's
completely safe.
Comparing to bash's mailcheck.c as another implementation of this sort
of feature (which doesn't cause me trouble), I find that it's much more
stateful (remembering previous mtimes etc), but at its heart is a
similar-looking check, which treats atime==mtime as *not* a cause for
new mail:
https://git.savannah.gnu.org/cgit/bash.git/tree/mailcheck.c#n463
(I think bash is only looking at second-granularity timestamps, same as
trn4.)


(I'm raising this as much to record my investigations as in the hope it
will be fixed. I haven't reported it upstream. If it annoys me too much
I'll probably just turn off the feature.)

Bug#1017065: libwacom-bin: Missing package relation with python3-libevdev for libwacom-show-stylus: "Error: No module named 'libevdev'"

[Axel Beckert]

Package: libwacom-bin
Version: 2.4.0-1
Severity: serious

Hi,

using one of the programs in libwacom-bin fails as follows:

$ libwacom-show-stylus
Error: No module named 'libevdev'
One or more python modules are missing. Please install those modules and re-run 
this tool.

After installing python3-libevdev, the tool works again:

$ libwacom-show-stylus
Using "Wacom Bamboo 16FG 4x5 Pen": /dev/input/event25
Using stylus file(s): /usr/share/libwacom/libwacom.stylus
Insufficient permissions, please run me as root

So the package is missing a package relation with python3-libevdev,
probably a Recommends, maybe also a Suggests or Depends. (I'll leave
that choice to the package maintainer.)

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

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

Versions of packages libwacom-bin depends on:
ii  libc6   2.34-3
ii  libglib2.0-02.72.3-1+b1
ii  libgudev-1.0-0  237-2
ii  libwacom9   2.4.0-1
ii  python3 3.10.6-1

libwacom-bin recommends no packages.

libwacom-bin suggests no packages.

-- no debconf information

Bug#1017063: gnome-weather: fails to start up;

[Jeremy Bicha]

On Fri, Aug 12, 2022 at 11:18 AM Evangelos Ribeiro Tzaras
 wrote:
> gnome-weather errors out with a critical on my testing/sid system when trying 
> to launch it:
>
> (org.gnome.Weather:2558104): Gjs-Console-CRITICAL **: 17:07:12.604: Error: 
> Expected type object for argument 'boxed_type' but got type undefined
> _init/GObject.ParamSpec.jsobject@resource:///org/gnome/gjs/modules/core/overrides/GObject.js:404:24
> @resource:///org/gnome/Weather/js/app/thermometer.js:49:36

Please check if downgrading your libmozjs-91-0 to the version from Testing
fixes your issue.

Thank you,
Jeremy Bicha

Bug#819341: [unison] Please build unison-fsmonitor

[Sylvain Leroy]

On Fri, 24 Jul 2020 07:49:22 +0200 =?UTF-8?Q?St=c3=a9phane_Glondu?= 
 wrote:

Le 23/07/2020 à 17:35, Vincent Lefevre a écrit :
>> I am planning to change the packaging structure of Unison in Debian.
>>
>> My current roadmap is:
>> - create a new source package unison-2.48
>> - make meta-unison provide unison and unison-gtk with symlinks to the
>>   binaries provided by unison-2.48
>> - let the "unison" source package disappear
>> - create a new source package unison-2.51 (or whatever is the latest
>>   version at the time)
>> - ...
>> - build unison-fsmonitor in unison-2.51
>>
>> and be done with alternatives. This new packaging scheme makes more
>> sense IMHO and will ease co-installability of multiple versions of unison.
> 
> What would be important would be to include the OCaml version number

> in the unison package name, since it has an effect on the behavior.

Right. I've already uploaded unison-2.48 to NEW, let's settle on that
first. I will add the OCaml version number in the next OCaml transition.


Any news on the unison-fsmonitor helper to be compiled and bundled with 
the unison package ?


--
Sylvain Leroy
Président Eternilab
https://www.eternilab.com

Bug#1017063: gnome-weather: fails to start up;

[Evangelos Ribeiro Tzaras]

Package: gnome-weather
Version: 43~beta-1
Severity: important

Dear Maintainer,


gnome-weather errors out with a critical on my testing/sid system when trying 
to launch it:

(org.gnome.Weather:2558104): Gjs-Console-CRITICAL **: 17:07:12.604: Error: 
Expected type object for argument 'boxed_type' but got type undefined
_init/GObject.ParamSpec.jsobject@resource:///org/gnome/gjs/modules/core/overrides/GObject.js:404:24
@resource:///org/gnome/Weather/js/app/thermometer.js:49:36

I'm not quite sure if this warrants a higher severity or not,
I read the BTS docs as suggesting this might be `grave` indeed ;)


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

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

Versions of packages gnome-weather depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  geoclue-2.0  2.6.0-1
ii  gir1.2-adw-1 1.2~beta-1
ii  gir1.2-geoclue-2.0   2.6.0-1
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gtk-4.0   4.6.6+ds-2
ii  gir1.2-gweather-4.0  4.0.0-2
ii  gjs  1.73.1-1
ii  libglib2.0-bin   2.72.3-1+b1

gnome-weather recommends no packages.

gnome-weather suggests no packages.

-- no debconf information

Bug#1017062: Should kross be removed?

[Moritz Muehlenhoff]

Source: kross
Version: 5.96.0-1
Severity: serious

See #1017061, kross isn't useful without interpreters.

Cheers,
Moritz

Bug#1017061: Should kross-interpreters be removed?

[Moritz Muehlenhoff]

Source: kross-interpreters
Version: 4:21.12.3-1
Severity: serious

Your package came up as a candidate for removal from Debian. On
IRC Sune mentioned that libkross is most probably unused these
days and on the KF6 removal list. And the Python bindings still
depend on Python 2 (without porting activity) which is being
removed from bookworm.

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in two weeks.

Cheers,
Moritz

Bug#1017049: profanity: No acknowledgement when running “/omemo start” in a chat room; also no docs on this

[Stefan Kropp]

On Fr, 12.08.2022 12:58:51, debbug.profan...@sideload.33mail.com wrote:
> Package: profanity
> Version: 0.10.0-1
> Severity: normal
> Tags: upstream
> 
> To send encrypted messages to a chat room, the following steps are
> necessary:
> 
>   1) OMEMO must be switched on for that room (enter “/omemo start” within 
> that room)
>   2) the fingerprint of every person in that room must be trusted
>   «OR»
>   2) enable blind trust (“/help omemo trustmode” in some versions)
> 
> When step 1 is performed, there is no response from the app in that
> window. There is also no response in window 1. No error message
> either. So it appears to the user that their command was ignored. 

When OMEMO has been enabled, there should be "[OMEMO]" in the
titlebar. Just beside of the room title. It also should disappear
with /omemo end.

In case of error, you will see some error message like:

  ! You have not generated or loaded a cryptographic materials,
use '/omemo gen'

> In my case, the command had proper effect (so egress messages
> thereafter were encrypted). But the user should be told
> something like:
>
>   “OMEMO enabled for outbound messages to this channel.
>To reverse this action, run `\omemo end`”
> 
> It would perhaps also be useful when entering a chat room that has
> OMEMO disabled to automatically print a banner saying:
> 
>   “Warning: messages sent to this room will be unencrypted.
>To enable e2ee run `\omemo start` in this window.”

Some people prefer E2EE, some not. If profanity will print this
warning all the time, it will be a little bit annoying. One
example is public non-anonymous group chats. There are also
clients which doesn't used OMEMO at all.

> Also, “/help omemo” does not cover this use case. The page gives the
> proper BNF syntax (“/omemo start []”), but it fails to
> mention that “” cannot be a /room/, and that the only way to
> start a session for a room is to do “/omemo start” in that room.

Maybe this is an issue. Thanks for the report.

> So there are three bugs here:
>   1) lack of command acknowledgement
>   2) lack of warning banner in unencrypted rooms
>   3) lack of help docs

Keep in mind there where some issues with OMEMO in 0.10.0. Some
issues has been fixed in 0.11.0 / 0.12.0.

-- 
Stefan
Diese E-Mail wurde von einem Debian GNU/Linux System gesendet

Bug#1016973: kopanocore: CVE-2022-26562

[Andreas Rönnquist]

On Thu, 11 Aug 2022 20:57:57 +0200 Salvatore Bonaccorso  
wrote:
> Hi Andreas,
> 
> Can you get in contact with upstream about it?
> 

Done (by mail) - I'll get back here when I get I reply.

-- Andreas Rönnquist
gus...@debian.org

Bug#1013156: gdcm: vtk[6,7] removal

[David Gobbi]

I've created a GDCM pull request where the necessary changes can be
discussed.  Lots of work remains to be done.

https://github.com/malaterre/GDCM/pull/145

Bug#1012219: Please adjust StanHeaders to new version of (one)tbb

[Andreas Tille]

Ping?  Is there any place where I can open an issue about this?
I've found
   https://github.com/cran/StanHeaders
but this is readonly and has no option to report issues.

Kind regards
 Andreas.

Am Mon, Jul 18, 2022 at 10:45:14AM +0200 schrieb Andreas Tille:
> Control: tags -1 upstream
> Control: forwarded -1 Ben Goodrich 
> 
> Hi Ben,
> 
> Debian is migrating from old tbb to onetbb (currently version 2021.5.0).  When
> trying to build rstan version 2.21.5 which includes StanHeaders we get the 
> error
> you can find here in our CI:
> 
>https://salsa.debian.org/r-pkg-team/r-cran-rstan/-/jobs/3011219
> 
> In file included from 
> /usr/lib/R/site-library/StanHeaders/include/stan/math/prim/core.hpp:4,
>  from 
> /usr/lib/R/site-library/StanHeaders/include/stan/math/prim/mat.hpp:6,
>  from 
> /usr/lib/R/site-library/StanHeaders/include/stan/math/rev/mat.hpp:12,
>  from ./stan/model/log_prob_grad.hpp:4,
>  from ./stan/model/test_gradients.hpp:7,
>  from ./stan/services/diagnose/diagnose.hpp:10,
>  from stan_fit.cpp:33:
> /usr/lib/R/site-library/StanHeaders/include/stan/math/prim/core/init_threadpool_tbb.hpp:9:10:
>  fatal error: tbb/task_scheduler_init.h: No such file or directory
> 9 | #include 
>   |  ^~~
> compilation terminated.
> 
> It seems StanHeaders need to be adapted to onetbb.
> 
> There is a tbb -> onetbb transition guide:
> https://oneapi-src.github.io/oneTBB/main/tbb_userguide/Migration_Guide.html
> 
> Hope this helps
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#1017049: [Pkg-xmpp-devel] Bug#1017049: profanity: No acknowledgement when running “/omemo start” in a chat room; also no docs on this

[Martin]

On 2022-08-12 12:58, debbug.profan...@sideload.33mail.com wrote:
> Package: profanity
> Version: 0.10.0-1

Could you please check, if version 0.12.1-1~bpo11+1 solves the issue?

To install it on Debian 11, perform the following steps:

$ echo "deb https://deb.debian.org/debian bullseye-backports main" \
| sudo tee /etc/apt/sources.list.d/backports.list
$ sudo apt update
$ sudo apt install -t bullseye-backports profanity

Thank you!

Bug#977441: linux: Pls. consider CONFIG_DRM_V3D

[Diederik de Haas]

On Friday, 3 June 2022 13:21:17 CEST Diederik de Haas wrote:
> The major missing piece AFAICT was enablement in DeviceTree. Recently a
> patch set was submitted that seems to contain the missing pieces ...
> 
> https://lore.kernel.org/all/20220601110249.569540-1-pbrobin...@gmail.com/ is
> the upstream thread where I got the patches from.

This patch series is now part of Linus' tree, so will be part of 5.20/6.0.

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

Bug#1016996: libnl-3-200-udeb: uninstallable, depends on non-udeb sgml-base

[Matthieu Baerts]

Hi Cyril,

On 12/08/2022 01:33, Cyril Brulebois wrote:
> Hi Matthieu,
> 
> Matthieu Baerts  (2022-08-11):
>> Thank you for having CCed me, provided a fix so quickly and for the
>> detailed explanations! Sorry, I didn't notice the regression when
>> testing on my side.
> 
> Absolutely no problems; it's easy to spot things when some daily build
> breaks, much easier than spotting all the changes in a set of 18 binary
> packages which tend to hardcode a strict dependency toward sibling
> packages…

Thank you! :-)

>> Do we need to revert your workaround when #1015263 will be fixed? If
>> yes, are you tracking this issue and planning to do the revert or do
>> you prefer if someone else looks at that?
> 
> At the moment, I didn't think that far ahead… First things first: I hope
> this issue doesn't become more widespread, so I'm hoping debhelper gets
> a fix sooner than later. If more hotfixes like this are needed, I'll
> probably plan on tracking individual changes to coordinate reverts. In
> the meanwhile, if you could take care of cancelling that change in that
> particular package when the time comes, that'd be awesome! Otherwise, I
> do have sticky notes and a large desk, I can deal with it. :)

OK, yes, no issue for me, I just subscribed to the debhelper bug
(#1015263) and I will revert the modification in debian/rules when needed.

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Bug#705566: date does not read the timezone from the environment variable TZ, and there is no other way to view from the CLI times in other timezones.

[Michael Stone]

On Fri, Aug 12, 2022 at 12:18:20PM +0200, Uwe Kleine-König wrote:

uwe@taurus:/usr/share/zoneinfo$ TZ=Europe/London date
Fri Aug 12 11:13:34 AM BST 2022
uwe@taurus:/usr/share/zoneinfo$ TZ=BST date
Fri Aug 12 10:13:38 AM BST 2022

The first one is the right one, but there is no way to determine the
latter to be wrong. Apart from the offset the output is identical and if
you're not aware that TZ=BST is wrong you have no chance to notice that.

If it at least said "Fri Aug 12 11:13:38 AM UTC 2022" or (better yet)
dies with an error code that would be highly convenient.


It would also be non-compliant with the standard. I'll pile on with what 
everyone else said, and repeat that the only practical solution is to 
not do what you're doing because the functionality is fundamentally 
unreliable. The ideal solution would be to drop support for three letter 
timezone codes entirely, but that's untenable from a compatibility 
standpoint.

Bug#1016806: closed by Debian FTP Masters (reply to gregor herrmann ) (Bug#1016806: fixed in libcpanel-json-xs-perl 4.31-1)

[gregor herrmann]

On Thu, 11 Aug 2022 21:21:47 +0300, Niko Tyni wrote:

> > #1016806: request-tracker5: FTBFS with Perl 5.36: Subroutine 
> > JSON::PP::Boolean::(0+ redefined
> > 
> > It has been closed by Debian FTP Masters  
> > (reply to gregor herrmann ).
> 
> >* Import upstream version 4.31.
> >  Fixes "FTBFS with Perl 5.36: Subroutine JSON::PP::Boolean::(0+ 
> > redefined"
> >  (Closes: #1016806)
> 
> Unfortunately this did not fix the issue.

Ack, it fixes the test failure of cpanel-json-xs itself, but as I
have suspected and in the meantime confirmed, it doesn't help rt5.
 
> I've now filed https://github.com/rurban/Cpanel-JSON-XS/issues/200 about this.

Thanks!


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1016937: atop: autopkgtest regression on arm64 and armhf and times out on s390x

[Paul Gevers]

Hi,

[tl;dr: atop seems to hang on s390x]

On 12-08-2022 12:23, Marc Haber wrote:

On Thu, Aug 11, 2022 at 10:51:32PM +0200, Paul Gevers wrote:

On 10-08-2022 12:03, Marc Haber wrote:

Unfortunately, this bug report suffers from multiple cut or
template error. The ci link points to the mercurial page for amd64, the
text alternates between s390s, armhf, arm64 and amd64.


There was only one that I'm aware of, the link to mercurial. But I
understand it if the text was a bit confusing.


You said autopkgtest fails on amd64, which was never the case. Maybe
amd64 and arm64 got confused.


What I *wanted* to convey is that arm64 and amd64 *failures* are in our 
RC policy and all other *regressions* are RC too. I did mix that up.



I tried the (dead simple)d autopkgtest on the s390s and arm64 porterboxes
and it succeeded in a second's time. I have sharpened the expression
that counts the CPUs in lscpu's output and hope this will fix the issue.


ooo, CPU count. Yes, some of those archs run on hosts with lots of CPU's.
armhf has 160, s390x has 10.


I am testing locally on amd64 with a machine with 12 CPUs. The armhf
tests succeed (see
https://ci.debian.net/data/autopkgtest/testing/armhf/a/atop/24578667/log.gz).


Great, same on arm64. s390x still times out though.


The complete test is:
#!/bin/bash

# atop reports number of CPU and two extra lines
ATOPSOPINION="$(atop -P cpu 5 1 | grep -vE '^(RESET|SEP)' | wc -l)"


When I run `atop` manually (on stable), it doesn't do anything...
root@ci-worker-s390x-01:~# atop
^C

I started up a clean unstable lxc container and installing atop takes 
quite some time between:
Created symlink 
/etc/systemd/system/timers.target.wants/atop-rotate.timer -> 
/lib/systemd/system/atop-rotate.timer.
Created symlink /etc/systemd/system/multi-user.target.wants/atop.service 
-> /lib/systemd/system/atop.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/atopacct.service -> 
/lib/systemd/system/atopacct.service.

and
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 145.

running atop from unstable also hangs:
root@elbrus:~# atop
^C


There is no loop, and nothing that could fail on a big number. In my
understanding, this could run on a box with 2000 cores and still work.


Except, it doesn't. Seems like atop is seriously broken on s390x on the 
hosts that we have.



Also, the test does not time out on zelenka when manually invoked in an
schroot (setting PATH to point to an executable atop is necessary, as it
does not seem to be possible to install an abitrary package that is not
in the archive. Also, the test is successful if invoked after installing
atop 2.7.1-2 from the archive.


Maybe we need to involve the s390x porters? I put them in CC to already 
draw their attention.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017059: RM: dicompyler -- ROM; Orphaned upstream, not compatible with recent matplotlib

[Andreas Tille]

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

Hi,

bug #985891 was forwarded upstream[1] but there is no sensible solution
to get it working with recent matplotlib.  It does not sound sensible to
package a Python module that brings back legacy stuff just to rescue
dicompyler which is not maintained actively any more (the repository is
archived by the owner).

Thus its time to remove this package from Debian,

Kind regards and thanks for working as ftpmaster

  Andreas.

[1] https://github.com/bastula/dicompyler/issues/122

Bug#1015049: thrift: FTBFS: dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

[Graham Inggs]

Control: severity -1 serious
Control: tags -1 - unreproducible

I retried on the amd64 buildd and got a similar failure [1].


[1] 
https://buildd.debian.org/status/fetch.php?pkg=thrift=amd64=0.16.0-5%2Bb1=1660308329=0

Bug#1017058: evdi-dkms: failt to compile drm/drm_irq.h is missing - kernel 5.18.0-3-amd64

[Thomas Drillich]

Package: evdi-dkms
Version: 1.9.0+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: t...@drillich.com

Dear Maintainer,
building the kernel-module on amd64 failed, cause there are no more
drm/drm_irq.h in the current kernel-source (and future Kernel, I've checked
19.1).

Is there a fix around?


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

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

Versions of packages evdi-dkms depends on:
ii  dkms  3.0.3-4

Versions of packages evdi-dkms recommends:
ii  libevdi0  1.9.0+dfsg-1

evdi-dkms suggests no packages.

-- no debconf information
DKMS make.log for evdi-1.9.0+dfsg for kernel 5.18.0-3-amd64 (x86_64)
Fr 12. Aug 14:38:14 CEST 2022
make: Verzeichnis „/usr/src/linux-headers-5.18.0-3-amd64“ wird betreten
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_platform_drv.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_platform_dev.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_sysfs.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_modeset.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_connector.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_encoder.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_fb.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_gem.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_painter.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_params.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_cursor.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_debug.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_i2c.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_ioc32.o
In file included from /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:23:
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.h:23:10: fatal error: 
drm/drm_irq.h: Datei oder Verzeichnis nicht gefunden
   23 | #include 
  |  ^~~
compilation terminated.
make[1]: *** 
[/usr/src/linux-headers-5.18.0-3-common/scripts/Makefile.build:294: 
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.o] Fehler 1
make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet
In file included from /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_gem.c:16:
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.h:23:10: fatal error: 
drm/drm_irq.h: Datei oder Verzeichnis nicht gefunden
   23 | #include 
  |  ^~~
compilation terminated.
make[1]: *** 
[/usr/src/linux-headers-5.18.0-3-common/scripts/Makefile.build:294: 
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_gem.o] Fehler 1
In file included from /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_ioc32.c:32:
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.h:23:10: fatal error: 
drm/drm_irq.h: Datei oder Verzeichnis nicht gefunden
   23 | #include 
  |  ^~~
compilation terminated.
make[1]: *** 
[/usr/src/linux-headers-5.18.0-3-common/scripts/Makefile.build:294: 
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_ioc32.o] Fehler 1
In file included from 
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_platform_dev.c:30:
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.h:23:10: fatal error: 
drm/drm_irq.h: Datei oder Verzeichnis nicht gefunden
   23 | #include 
  |  ^~~
compilation terminated.
make[1]: *** 
[/usr/src/linux-headers-5.18.0-3-common/scripts/Makefile.build:294: 
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_platform_dev.o] Fehler 1
In file included from /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_painter.c:19:
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.h:23:10: fatal error: 
drm/drm_irq.h: Datei oder Verzeichnis nicht gefunden
   23 | #include 
  |  ^~~
compilation terminated.
make[1]: *** 
[/usr/src/linux-headers-5.18.0-3-common/scripts/Makefile.build:294: 
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_painter.o] Fehler 1
In file included from /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_i2c.c:12:
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.h:23:10: fatal error: 
drm/drm_irq.h: Datei oder Verzeichnis nicht gefunden
   23 | #include 
  |  ^~~
compilation terminated.
make[1]: *** 
[/usr/src/linux-headers-5.18.0-3-common/scripts/Makefile.build:294: 
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_i2c.o] Fehler 1
In file included from /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_connector.c:19:
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.h:23:10: fatal error: 
drm/drm_irq.h: Datei oder Verzeichnis nicht gefunden
   23 | #include 
  |  ^~~
compilation terminated.
In file included from 

Bug#1017056: setuptools: cannot get metadata from pyproject.toml

[Ole Streicher]

Package: python3-setuptools
Version: 59.6.0-1.2
Severity: wishlist
Control: affects -1 src:asdf-standard

Dear maintainer,

I have a package (asdf-standard) that has no setup.py but a
pyproject.toml that contains (almost) all metadata. According to the
compilation hint, I added pybuild-plugin-pyproject to the build
dependencies. However it
still does not build properly. The build fails with the following
output:

8<
* Building wheel...
Successfully built UNKNOWN-1.0.3-py3-none-any.whl
I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.10
with "installer" module
E: pybuild pybuild:369: build: plugin pyproject failed with: UNKNOWN
wheel found: UNKNOWN-1.0.3-py3-none-any.whl. Does pyproject.toml specify
a build-backend?
dh_auto_build: error: pybuild --build -i python{version} -p 3.10
returned exit code 13
make: *** [debian/rules:5: binary] Error 25
8<

The build backend specified in pyproject.toml is

build-backend = "setuptools.build_meta"

In a discussion on the debian-python mailing list Scott Talberg gave the
hint:

> I *think* the issue might be that our setuptools is too old to
> understand how to get project metadata from pyproject.toml (PEP 621).
> This seems to indicate that it was added in setuptools 61.0.0:
> 
> https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

Therefore, I would ask if setuptools could be upgraded to at least
version 61?

Best regards

Ole

pyproject.toml
Description: application/toml

Bug#705566: date does not read the timezone from the environment variable TZ, and there is no other way to view from the CLI times in other timezones.

[Pádraig Brady]

On 12/08/2022 11:18, Uwe Kleine-König wrote:

On Sun, May 05, 2013 at 05:43:38PM -0600, Bob Proulx wrote:

severity 705566 normal
thanks

Laurence Maddox wrote:

I get this output:
Current default time zone: 'America/Chicago'
Local time is now:  Tue Apr 16 14:45:29 CDT 2013.
Universal Time is now:  Tue Apr 16 19:45:29 UTC 2013.


Looks okay.  What output did you expect?


I need to view on the CLI the time in various timezones.
...
I have searched for the "right" way to complete my task, and found a link here:
http://www.linuxquestions.org/questions/programming-9/display-different-timezones-in-command-line-927660/

That link recommends that I complete my task using a command like this one:
TZ=UTC date && TZ=CDT date && TZ=IST date


The concept is reasonable but you must pick a correct timezone for
what you want to accomplish.  UTC is okay.  But CDT and IST are
meaningless to libc.  The GNU libc has no concept of invalid
timezones.  If a timezone doesn't match anything else then the default
is that it is a name for UTC.  So basically you have asked for UTC
three times in a row.


I stumbled about a similar thing just now and would consider this
behaviour at least inconsistent:

uwe@taurus:/usr/share/zoneinfo$ TZ=Europe/London date
Fri Aug 12 11:13:34 AM BST 2022
uwe@taurus:/usr/share/zoneinfo$ TZ=BST date
Fri Aug 12 10:13:38 AM BST 2022

The first one is the right one, but there is no way to determine the
latter to be wrong. Apart from the offset the output is identical and if
you're not aware that TZ=BST is wrong you have no chance to notice that.

If it at least said "Fri Aug 12 11:13:38 AM UTC 2022" or (better yet)
dies with an error code that would be highly convenient.

And given that the timezone specifier in the output is "BST" (in both
cases!) noticing that TZ=BST is wrong isn't as trivial as it should be.

Note that using -R doesn't help here either because then I have to
notice that "+" is wrong, but to find the offset from me to BST was
the actual task to solve here ...


In my experience using POSIX timezone specifications
leads to ambiguity and they're not really usable.
Instead it's best to use the longer form location based zones where possible.
I've expanded on this here:
https://www.pixelbeat.org/docs/linux_timezones/

thanks,
Pádraig

Bug#1017054: bullseye-pu: package libdatetime-timezone-perl/1:2.47-1+2022b

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.47-1+2022b to bullseye,
updating the data to the new tzdata 2022b release via a quilt patch.

Changes (from tzdata package):
- Chile's 2022 DST start is delayed from September 4 to September 11.
- Iran plans to stop observing DST permanently, after it falls back
  on 2022-09-21.


Manually stripped down debdiff attached.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmL2S0dfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbd2w//Wngrc3zLX4xsvg771bO/8RDhLbS29NwaWQ6G05y5HHp9ykfnywCL+XD+
DTliAJL1rADNM8T5mRaIvutgiphR6njzvA+Bnlc28X2nq0UgF7uGb7Xawba/jEVO
50w3MmaSSHHhKe0vkyOb5g+LP5lAQVz2UjlXzPaEbZikqBFUwyxMV45a33dDzytZ
vezEaMRVgii+OzF9eTLXusdms6IFA5GlnI+8k9UIMxEGVs7m1ZSdHUG/8X5oP1yZ
m0yc2XUy3Wff7qaMSiGD4kG0JbNTpy2wgKaMMy6zqR5bdwIH8wZ0tTLC0i/mKwOK
WZlPdGUZo9QJWd4cN/YHUcwmTBBV/F/oXmMSakSPLXEUguivqbpJRp+VZqR1bZm8
wGK096z9AdCztuTpIOV7u/PG+3wSpxU7yClcv5IFsnUe5I8gUqbIiWl5v1CWjcD2
feJLoVLA8h1Ms3LAuXy+JljmkzB+O7VdJeVSpPsPU5k6yZI2waVyMwOLj88NH9Uv
jORnht/qLh3AxbAXpj9TnTK6uLjA+4rK79XFTlBFmzSox3z51pLpDlDtFL5n+Wv0
sDLFVZq+syLt5Q/aWfqMLOynoALWkg/udXjA42OAEgAglQQn8TnL1vdB0bcS0x3R
bk+4lB4qbyW14XQUIQdesCcMiHpz8gCvT6Yf5Ph78zVPw7GHEFw=
=6jjm
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.47/debian/changelog 
libdatetime-timezone-perl-2.47/debian/changelog
--- libdatetime-timezone-perl-2.47/debian/changelog 2022-03-19 
15:48:18.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/changelog 2022-08-12 
14:35:14.0 +0200
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.47-1+2022b) bullseye; urgency=medium
+
+  * Update to Olson database version 2022b.
+This update includes contemporary changes for Chile and Iran.
+
+ -- gregor herrmann   Fri, 12 Aug 2022 14:35:14 +0200
+
 libdatetime-timezone-perl (1:2.47-1+2022a) bullseye; urgency=medium
 
   * Update to Olson database version 2022a.
diff -Nru libdatetime-timezone-perl-2.47/debian/patches/olson-2022b 
libdatetime-timezone-perl-2.47/debian/patches/olson-2022b
--- libdatetime-timezone-perl-2.47/debian/patches/olson-2022b   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/patches/olson-2022b   2022-08-12 
14:35:14.0 +0200
@@ -0,0 +1,21549 @@
+Description: Update to Olson DB 2022b
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2022-08-12
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2022a
++# Generated from debian/tzdata/africa.  Olson data version 2022b
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2022a'}
++sub olson_version {'2022b'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/America/Santiago.pm
 b/lib/DateTime/TimeZone/America/Santiago.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/southamerica.  Olson data version 2022a
++# Generated from debian/tzdata/southamerica.  Olson data version 2022b
+ #
+ # Do not edit this file directly.
+ #
+@@ -196,20 +196,20 @@
+ ],
+ [
+ 61395163200, #utc_start 1946-07-15 04:00:00 (Mon)
+-61399306800, #  utc_end 1946-09-01 03:00:00 (Sun)
++61399047600, #  utc_end 1946-08-29 03:00:00 (Thu)
+ 61395152400, #  local_start 1946-07-15 01:00:00 (Mon)
+-61399296000, #local_end 1946-09-01 00:00:00 (Sun)
++61399036800, #local_end 1946-08-29 00:00:00 (Thu)
+ -10800,
+ 1,
+ '-03',
+ ],
+ [
+-61399306800, #utc_start 1946-09-01 03:00:00 (Sun)
++61399047600, #utc_start 1946-08-29 03:00:00 (Thu)
+ 61417627200, #  utc_end 1947-04-01 04:00:00 (Tue)
+-61399292400, #  local_start 1946-08-31 23:00:00 (Sat)
++61399033200, #  local_start 1946-08-28 23:00:00 (Wed)
+ 61417612800, #local_end 1947-04-01 00:00:00 (Tue)
+ -14400,
+-0,
++1,
+ '-04',
+ ],
+ [
+@@ -1177,17 +1177,17 @@
+ ],
+ [
+ 63784638000, #utc_start 2022-04-03 03:00:00 (Sun)
+-63797947200, #  utc_end 2022-09-04 04:00:00 (Sun)
++63798552000, #  utc_end 2022-09-11 04:00:00 (Sun)
+ 63784623600, #  local_start 2022-04-02 23:00:00 (Sat)
+-63797932800, #local_end 2022-09-04 00:00:00 (Sun)
++63798537600, #local_end 2022-09-11 00:00:00 (Sun)
+ -14400,
+ 0,
+ '-04',
+ ],
+ [
+-63797947200, #utc_start 2022-09-04 04:00:00 (Sun)
++63798552000, #utc_start 2022-09-11 04:00:00 (Sun)
+ 63816087600, #  utc_end 2023-04-02 03:00:00 (Sun)
+-63797936400, #  local_start 2022-09-04 01:00:00 (Sun)
++63798541200, #  local_start 

Bug#1017053: fenics-dolfinx: FTBFS on mips64el

[Graham Inggs]

Source: fenics-dolfinx
Version: 1:0.4.1-4
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

Hi Maintainer

Your package FTBFS on mips64el during the recent rebuilds for Python
3.10 [1].  I've copied what I hope is the relevant part of the log
below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=fenics-dolfinx


Traceback (most recent call last):
  File "/<>/python/setup.py", line 67, in 
setup(name='fenics-dolfinx',
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
153, in setup
return distutils.core.setup(**attrs)
  File "/usr/lib/python3.10/distutils/core.py", line 148, in setup
dist.run_commands()
  File "/usr/lib/python3.10/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3.10/distutils/dist.py", line 985, in run_command
cmd_obj.run()
  File "/usr/lib/python3.10/distutils/command/build.py", line 135, in run
self.run_command(cmd_name)
  File "/usr/lib/python3.10/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
  File "/usr/lib/python3.10/distutils/dist.py", line 985, in run_command
cmd_obj.run()
  File "/<>/python/setup.py", line 41, in run
self.build_extension(ext)
  File "/<>/python/setup.py", line 64, in build_extension
subprocess.check_call(['cmake', '--build', '.'] + build_args,
cwd=self.build_temp, env=env)
  File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.',
'--config', 'Release', '--', '-j3']' returned non-zero exit status 2.
chrpath -d 
/<>/debian/tmp*/usr/lib/python*/dist-packages/dolfinx/*.so
open: No such file or directory
elf_open: Invalid argument

Bug#1017051: tinyarray: FTBFS on i386

[Graham Inggs]

Source: tinyarray
Version: 1.2.3-4
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

Hi Maintainer

Your package FTBFS on i386 during the recent rebuilds for Python 3.10
[1].  I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=tinyarray


=== FAILURES ===
 test_binary_operators _

def test_binary_operators():
ops = operator
operations = [ops.add, ops.sub, ops.mul, ops.mod,
ops.floordiv, ops.truediv]
if sys.version_info.major < 3:
operations.append(ops.div)

with warnings.catch_warnings():
warnings.filterwarnings("ignore", category=RuntimeWarning)

for op in operations:
for dtype in dtypes:
for shape in [(), 1, 3, (3, 2)]:
if dtype is complex and op in [ops.mod, ops.floordiv]:
continue
a = make(shape, dtype)
b = make(shape, dtype)
>   assert_equal(op(ta.array(a.tolist()), 
> ta.array(b.tolist())),
 op(a, b))
E   AssertionError:
E   Arrays are not equal
E
E   Mismatched elements: 2 / 3 (66.7%)
E   Max absolute difference: 1.11022302e-16
E   Max relative difference: 1.11022302e-16
Ex: array([nan+nanj,  1. +0.j,  1. +0.j])
Ey: array([nan+nanj,  1. +0.j,  1. +0.j])

../../../test_tinyarray.py:375: AssertionError
__ test_binary_ufuncs __

def test_binary_ufuncs():
with warnings.catch_warnings():
warnings.filterwarnings("ignore", category=RuntimeWarning)

for name in ["add", "subtract", "multiply", "divide",
 "remainder", "floor_divide"]:
np_func = np.__dict__[name]
ta_func = ta.__dict__[name]
for dtype in dtypes:
for shape in [(), 1, 3, (3, 2)]:
if dtype is complex and \
name in ["remainder", "floor_divide"]:
continue
a = make(shape, dtype)
b = make(shape, dtype)
>   assert_equal(ta_func(a.tolist(), b.tolist()),
 np_func(a, b))
E   AssertionError:
E   Arrays are not equal
E
E   Mismatched elements: 2 / 3 (66.7%)
E   Max absolute difference: 1.11022302e-16
E   Max relative difference: 1.11022302e-16
Ex: array([nan+nanj,  1. +0.j,  1. +0.j])
Ey: array([nan+nanj,  1. +0.j,  1. +0.j])

../../../test_tinyarray.py:396: AssertionError

Bug#1017050: gyoto: FTBFS in unstable on arm64, mipsel and s390x

[Graham Inggs]

Source: gyoto
Version: 1.4.4-7
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

Hi Maintainer

Your package FTBFS on arm64, mipsel and s390x during the recent
rebuilds for Python 3.10 [1].  I've copied what I hope is the relevant
part of the logs below.  It seems to be the same test failing, but
with different incorrect values.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=gyoto


==
FAIL: test___str__ (tests.core.TestUnit)
--
Traceback (most recent call last):
  File "/<>/python/tests/core.py", line 108, in test___str__
self.assertEqual(str(gyoto.core.Unit("km")), "km")
AssertionError: '@\udcd9' != 'km'
- @\udcd9
+ km


==
FAIL: test___str__ (tests.core.TestUnit)
--
Traceback (most recent call last):
  File "/<>/python/tests/core.py", line 108, in test___str__
self.assertEqual(str(gyoto.core.Unit("km")), "km")
AssertionError: '\udcf0p' != 'km'
- \udcf0p
+ km


==
FAIL: test___str__ (tests.core.TestUnit)
--
Traceback (most recent call last):
  File "/<>/python/tests/core.py", line 108, in test___str__
self.assertEqual(str(gyoto.core.Unit("km")), "km")
AssertionError: '\x00\x00' != 'km'
-
+ km

Bug#1017049: profanity: No acknowledgement when running “/omemo start” in a chat room; also no docs on this

[debbug . profanity]

Package: profanity
Version: 0.10.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.profan...@sideload.33mail.com

To send encrypted messages to a chat room, the following steps are
necessary:

  1) OMEMO must be switched on for that room (enter “/omemo start” within that 
room)
  2) the fingerprint of every person in that room must be trusted
  «OR»
  2) enable blind trust (“/help omemo trustmode” in some versions)

When step 1 is performed, there is no response from the app in that
window. There is also no response in window 1. No error message
either. So it appears to the user that their command was ignored. In
my case, the command had proper effect (so egress messages thereafter
were encrypted). But the user should be told something like:

  “OMEMO enabled for outbound messages to this channel.
   To reverse this action, run `\omemo end`”

It would perhaps also be useful when entering a chat room that has
OMEMO disabled to automatically print a banner saying:

  “Warning: messages sent to this room will be unencrypted.
   To enable e2ee run `\omemo start` in this window.”

Also, “/help omemo” does not cover this use case. The page gives the
proper BNF syntax (“/omemo start []”), but it fails to
mention that “” cannot be a /room/, and that the only way to
start a session for a room is to do “/omemo start” in that room.

So there are three bugs here:
  1) lack of command acknowledgement
  2) lack of warning banner in unencrypted rooms
  3) lack of help docs

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages profanity depends on:
ii  libc6  2.31-13+deb11u3
ii  libcurl3-gnutls7.74.0-1.3+deb11u1
ii  libgcrypt201.8.7-6
ii  libglib2.0-0   2.66.8-1
ii  libgpgme11 1.14.0-1+b2
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libncursesw6   6.2+20201114-2
ii  libnotify4 0.7.9-3
ii  libotr54.1.1-4
ii  libpython3.9   3.9.2-1
ii  libreadline8   8.1-1
ii  libsignal-protocol-c2.3.2  2.3.3-1
ii  libsqlite3-0   3.34.1-3
ii  libstrophe00.10.1-1
ii  libtinfo6  6.2+20201114-2
ii  libx11-6   2:1.7.2-1
ii  libxss11:1.2.3-1

profanity recommends no packages.

profanity suggests no packages.

-- no debconf information

Bug#1017048: python-autobahn: dependency on python3.9

[Graham Inggs]

Source: python-autobahn
Version: 22.1.1+dfsg1-2
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.10

Hi Maintainer

Your package has a (generated) dependency on python3.9 which is being
removed.  Your package is arch:all and so cannot be binNMU'd.  Please
do a source-only upload, and please investigate if it is possible to
drop this dependency to make future python3 migrations easier.

Regards
Graham

Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_alloc

[Lucas Nussbaum]

On 08/08/22 at 22:45 +0200, Richard B. Kreckel wrote:
> I am unable to reproduce the above compile-time error.

Hi,

I can still reproduce it.

Lucas

Bug#1017046: dh-virtualenv: dependency on python3.9-venv

[Graham Inggs]

Source: dh-virtualenv
Version: 1.2.2-1.1
Severity: serious
Tags: bookworm sid
User: debian-pyt...@lists.debian.org
Usertags: python3.10

Hi Maintainer

Your package has a (generated) dependency on python3.9-venv and
python3.9 is being removed.  Your package is arch:all and so cannot be
binNMU'd.  Please do a source-only upload, and please investigate if
it is possible to drop this dependency to help future python3
migrations.

Regards
Graham

Bug#1013060: veyon: ftbfs with GCC-12

[Dmitry Shachnev]

On Thu, Jun 16, 2022 at 12:14:44PM +, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-12/g++-12, but succeeds to build with gcc-11/g++-11. The
> severity of this report will be raised before the bookworm release.
>
> [...]
>
> /<>/core/src/VncView.cpp: In member function ‘virtual void 
> VncView::mouseEventHandler(QMouseEvent*)’:
> /<>/core/src/VncView.cpp:580:59: error: variable ‘constexpr 
> const std::array 3> buttonTranslationMap’ has initializer but incomplete type
>   580 | static constexpr std::array 
> buttonTranslationMap{ {
>   |   
> ^~~~

I have just NMUed veyon. Diff can be seen here:

https://salsa.debian.org/debian-edu-pkg-team/veyon/-/merge_requests/2

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1017045: RFP: nitropy -- A command line interface for the Nitrokey FIDO2, Nitrokey Start, Nitrokey 3 and NetHSM

[Martin Kropfinger]

Package: wnpp
Severity: wishlist

For managing the security-devices of Nitrokey there is a python-tool
available. It would be nice having it in the official repository.

The sources can be found at: https://github.com/Nitrokey/pynitrokey

As license is used MIT and Apache v2.0.

Bug#705566: date does not read the timezone from the environment variable TZ, and there is no other way to view from the CLI times in other timezones.

[Uwe Kleine-König]

On Sun, May 05, 2013 at 05:43:38PM -0600, Bob Proulx wrote:
> severity 705566 normal
> thanks
> 
> Laurence Maddox wrote:
> > I get this output:
> > Current default time zone: 'America/Chicago'
> > Local time is now:  Tue Apr 16 14:45:29 CDT 2013.
> > Universal Time is now:  Tue Apr 16 19:45:29 UTC 2013.
> 
> Looks okay.  What output did you expect?
> 
> > I need to view on the CLI the time in various timezones.
> > ...
> > I have searched for the "right" way to complete my task, and found a link 
> > here:
> > http://www.linuxquestions.org/questions/programming-9/display-different-timezones-in-command-line-927660/
> > 
> > That link recommends that I complete my task using a command like this one:
> > TZ=UTC date && TZ=CDT date && TZ=IST date
> 
> The concept is reasonable but you must pick a correct timezone for
> what you want to accomplish.  UTC is okay.  But CDT and IST are
> meaningless to libc.  The GNU libc has no concept of invalid
> timezones.  If a timezone doesn't match anything else then the default
> is that it is a name for UTC.  So basically you have asked for UTC
> three times in a row.

I stumbled about a similar thing just now and would consider this
behaviour at least inconsistent:

uwe@taurus:/usr/share/zoneinfo$ TZ=Europe/London date
Fri Aug 12 11:13:34 AM BST 2022
uwe@taurus:/usr/share/zoneinfo$ TZ=BST date
Fri Aug 12 10:13:38 AM BST 2022

The first one is the right one, but there is no way to determine the
latter to be wrong. Apart from the offset the output is identical and if
you're not aware that TZ=BST is wrong you have no chance to notice that.

If it at least said "Fri Aug 12 11:13:38 AM UTC 2022" or (better yet)
dies with an error code that would be highly convenient.

And given that the timezone specifier in the output is "BST" (in both
cases!) noticing that TZ=BST is wrong isn't as trivial as it should be.

Note that using -R doesn't help here either because then I have to
notice that "+" is wrong, but to find the offset from me to BST was
the actual task to solve here ...

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#1016937: atop: autopkgtest regression on arm64 and armhf and times out on s390x

[Marc Haber]

On Thu, Aug 11, 2022 at 10:51:32PM +0200, Paul Gevers wrote:
> On 10-08-2022 12:03, Marc Haber wrote:
> > Unfortunately, this bug report suffers from multiple cut or
> > template error. The ci link points to the mercurial page for amd64, the
> > text alternates between s390s, armhf, arm64 and amd64.
> 
> There was only one that I'm aware of, the link to mercurial. But I
> understand it if the text was a bit confusing.

You said autopkgtest fails on amd64, which was never the case. Maybe
amd64 and arm64 got confused.

> > I tried the (dead simple)d autopkgtest on the s390s and arm64 porterboxes
> > and it succeeded in a second's time. I have sharpened the expression
> > that counts the CPUs in lscpu's output and hope this will fix the issue.
> 
> ooo, CPU count. Yes, some of those archs run on hosts with lots of CPU's.
> armhf has 160, s390x has 10.

I am testing locally on amd64 with a machine with 12 CPUs. The armhf
tests succeed (see
https://ci.debian.net/data/autopkgtest/testing/armhf/a/atop/24578667/log.gz).

The complete test is:
#!/bin/bash

# atop reports number of CPU and two extra lines
ATOPSOPINION="$(atop -P cpu 5 1 | grep -vE '^(RESET|SEP)' | wc -l)"
TRUTH="$(lscpu -p | grep -vE '^#' | wc -l)"

if [ "${TRUTH}" -ne "${ATOPSOPINION}" ]; then
  printf >&2 "autopkgtest 01-numcpus failed"
  printf >&2 "atop thinks %s CPUs, truth is %s CPUs\n" "${ATOPSOPINION}" 
"${TRUTH}"
  atop -P cpu 5 1 >&2
  lscpu -p >&2
  exit 1
else
  exit 0
fi

There is no loop, and nothing that could fail on a big number. In my
understanding, this could run on a box with 2000 cores and still work.

Also, the test does not time out on zelenka when manually invoked in an
schroot (setting PATH to point to an executable atop is necessary, as it
does not seem to be possible to install an abitrary package that is not
in the archive. Also, the test is successful if invoked after installing
atop 2.7.1-2 from the archive.

> > Can you find out in which line the autopkgtest stalls?
> 
> Unfortunately; you have access to the same log as I have.

So we have an unreproducible and unexplained timeout.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1014456: unbound: Please enable cachedb and redis support

[Michael Tokarev]

On Wed, 06 Jul 2022 15:16:31 +0200 Michiel Hazelhof  wrote:

Package: unbound
Version: 1.16.0-2
Severity: wishlist

Dear Maintainer,

When using unbound on a server it would be helpfull if redis was available as a 
caching server.
From what I can tell using the following parameters should do the trick: 
--enable-cachedb --with-libhiredis


Hi!

What does cachedb/redis bring us, how these can be used?
Should apparmor profile be updated for it to work?

Thanks,

/mjt

Bug#840975: ifupdown: When running /etc/network/interfaces.d/, editor backups aren't ignored

[Jérémie Courrèges-Anglas]

On Wed, 19 Oct 2016 20:38:54 +0200 Guus Sliepen 
wrote:
> On Sun, Oct 16, 2016 at 09:14:31AM -0500, Dan Greene wrote:
> 
> > I edited /etc/networking/interfaces.d/wlan0 on my system using jo
> > to change the configuration. When saving, many editors, including
> > joe, leave backups that end with a tilde '~'. When I run
> > $ ifup wlan0
> > or when the system tries to bring up the interface at boot, the
> > system loads the backup created by the editor in addition to the
> > current version, and as a result, gets confused. (I believe it
tries
> > to set the route twice.)
> > 
> > This, of course, results in the network not working, and the reason
is
> > not obvious, leading to wasted time trying to fix it.
> 
> I suspect something else is happening here, because ifup only reads
> those files that consists only of a-z, A-Z, 0-9, _ and -. So files
with
> a tilde, whereever they appear in the filename, are ignored.

That's partly true, it depends on whether the configuration uses
"source /some/dir/*" or "source-dir /some/dir/". The former doesn't use
scandir(3) or the directory_filter() function, only the latter does
filter file names like you describe.  Sadly the postinst script puts

  source /etc/network/interfaces.d/*

in /etc/network/interfaces by default.

> In order to find out what the real problem is, could you send me a
copy
> of your /etc/network/interfaces, /etc/network/interfaces.d/wlan0?
Also,
> do ifdown wlan0, and then run this command:
> 
> ifup -v wlan0 2>&1 >ifup.log
> 
> And send me a copy of ifup.log. You can of course also look at it
> yourself, it should tell you exactly what ifup is trying to do and
what
> commands it is executing.

See the attached config.txt and ifup-v... files.

-- 
Jeremie Courreges-Anglas
Administrateur Systeme et Reseau
celeste.fr - oceanet-technology.com


ifup: parsing file /etc/network/interfaces.d/tralala~
if test -d /sys/class/net/eno2 && ! ip link show eno2.1400 >/dev/null 
2>&1; then if test `cat /sys/class/net/eno2/type` -eq 32; then  
   echo 0x1400 > /sys/class/net/eno2/create_child; else 
ip link set up dev eno2; ip link add link eno2 name eno2.1400 type 
vlan id 1400;fi; fi

ifup: configuring interface eno2.1400=eno2.1400 (inet)
run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/hostapd
run-parts: executing /etc/network/if-pre-up.d/ifenslave
+ [ inet = meta ]
+ IF_BOND_SLAVES=
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ exit 0
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
ip addr add 192.0.2.64/255.255.255.0 broadcast 192.0.2.255dev eno2.1400 
label eno2.1400
ip link set dev eno2.1400   up

run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/clamav-freshclam-ifupdown
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/ifenslave
+ [ inet = meta ]
+ [  ]
run-parts: executing /etc/network/if-up.d/ntpsec-ntpdate
run-parts: executing /etc/network/if-up.d/openvpn
run-parts: executing /etc/network/if-up.d/wpasupplicant
ca@OT-PORT-023:~/src/ifupdown-0.8.37$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*
#source-dir /etc/network/interfaces.d/

# The loopback network interface
auto lo
iface lo inet loopback
jca@OT-PORT-023:~/src/ifupdown-0.8.37$ ls /etc/network/interfaces.d/
tralala~
jca@OT-PORT-023:~/src/ifupdown-0.8.37$ cat /etc/network/interfaces.d/tralala~ 
auto eno2.1400
iface eno2.1400 inet static
address 192.0.2.64/24

Bug#1015260: Problem solved!

[Sietse Achterop]

  Hello Nicolas,

sorry for the late reaction.
I somehow did not receive your last mail, and also was on vacation.


Are you sure you have set up nqc to connect using USB?



Either:



nqc -Susb -firmware firm0332.lgo



Or:



export RCX_PORT=usb
nqc -firmware firm0332.lgo


I did use

   RCX_PORT=/dev/usb/legousbtower0

but with RCX_PORT=usb it did work!
  (I think I did try this at some point, but alas)

Thanks for the help!
We have 6 units and can now start using them again in a few student projects.

   Regards,
 Sietse

Bug#1017044: graphviz: please remove the Debian menu file

[Pino Toscano]

Package: graphviz
Version: 2.42.2-7
Severity: minor
Tags: patch

Hi,

graphviz currently provides a Debian menu file with two entries, for
the dotty and lefty applications; however:
- the Debian menu is deprecated for some years already [1]
- none of the items in the menu file have icons
- the applications are very niche
- there are no desktop counterparts, nor requests for them either in
  Debian nor upstream

Hence, rather than converting them to desktop files, I think it is a
better idea to simply drop the old Debian menu file for now. In case
there is a demand for those two applications, I think it would be better
to ask upstream to provide proper desktop files for them.

Attached there is a patch to simply drop the Debian menu file.

[1] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html

Thanks,
-- 
Pino
diff -Nru graphviz-2.42.2/debian/changelog graphviz-2.42.2/debian/changelog
--- graphviz-2.42.2/debian/changelog2022-06-15 19:55:30.0 +0200
+++ graphviz-2.42.2/debian/changelog2022-08-12 11:28:29.0 +0200
@@ -1,3 +1,15 @@
+graphviz (2.42.2-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop the Debian menu file:
+- the Debian menu is deprecated for some years already
+- none of the items in the menu file have icons
+- the applications are very niche
+- there are no desktop counterparts, nor requests for them either in Debian
+  nor upstream
+
+ -- Pino Toscano   Fri, 12 Aug 2022 11:28:29 +0200
+
 graphviz (2.42.2-7) unstable; urgency=medium
 
   * Recommend fonts-liberation2 (closes: #1003006).
diff -Nru graphviz-2.42.2/debian/graphviz.menu 
graphviz-2.42.2/debian/graphviz.menu
--- graphviz-2.42.2/debian/graphviz.menu2014-12-10 16:25:41.0 
+0100
+++ graphviz-2.42.2/debian/graphviz.menu1970-01-01 01:00:00.0 
+0100
@@ -1,4 +0,0 @@
-?package(graphviz):needs="X11" section="Applications/Graphics" \
-  title="dotty" command="/usr/bin/dotty"
-?package(graphviz):needs="X11" section="Applications/Graphics" \
-  title="lefty" command="/usr/bin/lefty"

Bug#1017043: transition: openexr

[Mathieu Malaterre]

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

I'd like to request a transition slot for openexr 3.x transition.
Basically this is an API change as well as a merge of ilmbase into
openexr (previously two packages).

openexr 3.1.5 is available in experimental:

https://buildd.debian.org/status/package.php?p=openexr=experimental

I've build all reverse dependencies without major issues. Package
openexr-viewers will need to be RM since abandonned upstream.

openvdb current status may interfere a bit in the process.

Thanks

Ben file:

title = "openexr";
is_affected = .depends ~ /\b(libopenexr25|openexr\-doc)\b/ | .depends ~ 
/\b(libopenexr\-3\-1\-30|libopenexr\-doc)\b/;
is_good = .depends ~ /\b(libopenexr\-3\-1\-30|libopenexr\-doc)\b/;
is_bad = .depends ~ /\b(libopenexr25|openexr\-doc)\b/;

Bug#989218: openvpn: the lack of down update-resolv-conf script

[Bernhard Schmidt]

On 29/05/21 04:14 AM, sergio wrote:

> resolv.conf left configured after tunnel down due to lack of down script

No, the Debian supplied script is supposed to be used for both

---
$ head /etc/openvpn/update-resolv-conf
#!/bin/bash
# 
# Parses DHCP options from openvpn to update resolv.conf
# To use set as 'up' and 'down' script in your openvpn *.conf:
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
---

and handles down just fine.

> If you will be updating the current debian update-resolv-conf with
> client.up / client.down from openwrt, please pay attention, that
> client.up calls resolvconf with '-p' so it fails on debian.

I won't be updating the resolvconf scripts myself, but I would accept
tested patches for it. 

The scripts in
https://github.com/OpenVPN/openvpn/tree/master/contrib/pull-resolv-conf
are not acceptable (they fiddle with /etc/resolv.conf directly if
resolvconf is not available).

Bernhard

Bug#1017002: Please update mozillavpn to 2.9.0, and switch to Qt6

[Sylvestre Ledru]

Hello

Le 11/08/2022 à 10:20, Amr Ibrahim a écrit :

Package: mozillavpn

Hello,

Please update mozillavpn to 2.9.0, and switch to Qt6 when possible.

https://github.com/mozilla-mobile/mozilla-vpn-client/releases/latest

Best,
Amr


I have been trying but I have a build failure.

Would you like to give it a try ?

Cheers

Sylvestre

Bug#1017042: Does not deggragate addresses anymore

[Klaus Ethgen]

Package: ipcalc
Version: 0.42-2
Severity: normal

Deaggregate addresses doesn't work anymore and result in endless
recursions.

   ~> ipcalc 121.224.0.0 - 121.239.255.255
   deaggregate 121.224.0.0 - 121.239.255.255
   Deep recursion on subroutine "Math::BigInt::bior" at 
/usr/share/perl5/Math/BigFloat.pm line 3883.
   Deep recursion on subroutine "Math::BigFloat::bior" at 
/usr/share/perl5/Math/BigInt.pm line 3513.

The command does not return anymore.

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

Kernel: Linux 5.16.17 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ipcalc depends on:
ii  perl  5.34.0-5

ipcalc recommends no packages.

ipcalc suggests no packages.

-- no debconf information

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#976070: openvpn fails with iproute option

[Bernhard Schmidt]

On 29/11/20 11:05 AM, Glennie Vignarajah wrote:

> In order to use openvpn with non root priviliges, iproute is need as
> state in openvpn's howto document [1]. By default, iproute is disabled
> on compile time and needs to enabled with ``--enable-iproute2``.

Upstream has now added the option for openvpn to retain the
CAP_NET_ADMIN capability while dropping priviledges. OpenVPN now works
correctly with --user something.

Bernhard

Bug#908559: openvpn: Openvpn cannot run /sbin/ip if started from systemd

[Bernhard Schmidt]

Version: 2.5.0-1

> The openvpn systemd unit cannot start because it cannot call the /sbin/ip
> script. If I run the same script by hand it starts, so the problem should be
> in the system unit file. I have been using the same config file for a while
> (~8-10 years) and changed nothing, it happened when I upgraded my host at
> the end of August after a long summber break.

Starting with 2.5.0, openvpn is not using direct calls to /sbin/ip
anymore, but netlink messages. Closing this bug.

Bernhard

Bug#1016723: git: Bump version to 2.37.1

[Sedat Dilek]

Hi,

git version 2.37.2 was released.

Just wanna let you know.

Best regards,
-Sedat-

[1] https://git.kernel.org/pub/scm/git/git.git/tag/?h=v2.37.2

Bug#1017029: displaycal: fails to start, stall at spalsh screen after numerous error messages

[Christian Marillat]

On 12 août 2022 08:58, "Jean-Luc Coulon (f5ibh)"  
wrote:

> Hello Christian !
>
> Yes! Good shot!
>
> It works once libsdl2-mixer-2.0-0 installed.

I'm not sure if this is the right fix, but I'll add libsdl2-mixer-2.0-0
in Depends.

Christian

Bug#1017029: displaycal: fails to start, stall at spalsh screen after numerous error messages

[Jean-Luc Coulon (f5ibh)]

Le 12/08/2022 à 08:06, Christian Marillat a écrit :

On 11 août 2022 20:46, "Jean-Luc Coulon (f5ibh)"  
wrote:


Package: displaycal
Version: 3.9.7-1
Severity: important
Tags: upstream

Hi,

When I launch displaycal from a console, I get a lot of error messages
(the same group of messages repeated many times).
Then it stalls with the splash screen displayed.

I'm not sure if installing libsdl2-mixer-2.0-0.

Do you have a github account ?

Yes, I've


Christian

Bug#1016340: openssh: FTBFS: Failed to copy 'etc/ssh/sshd_config': No such file or directory at /usr/share/dh-exec/dh-exec-install-rename line 68, <> line 7.

[Craig Small]

Hi Colin,
  Thanks for the report. I first copied dh-exec-install-rename from dh-exec
0.23.4 and compiled OpenSSL fine. The odd thing is that 0.23.4 was out but
0.24 was on Salsa but never released. 0.25 was just an update of the Salsa
version and 0.26 was the re-introduction of the patches for 0.23.4.
Anyway, 0.26 is on Salsa and is the current version.

A diff between these files showed only a few lines to a) cater for
dh-exec-install-move and fix Bug #831786

I thought it had to do with the move side of things but it turns out it was
the fix that was the issue!
I commented out the following in /usr/share/dh-exec/dh-exec-install-rename

if (defined ($ENV{"DH_INTERNAL_OPTIONS"}) &&
$ENV{"DH_INTERNAL_OPTIONS"} =~ /-[ai]/) {
$noop = 0;
}

I'm not really sure why this causes the problem, but it definitely sets
something off.

 - Craig



On Fri, 12 Aug 2022 at 00:56, Colin Watson  wrote:

> Control: clone -1 -2
> Control: reassign -2 dh-exec
> Control: retitle -2 dh-exec-install-rename sometimes moves rather than
> copies
>
> On Fri, Jul 29, 2022 at 08:40:48PM +0200, Lucas Nussbaum wrote:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> >
> >
> > Relevant part (hopefully):
> > > make[1]: Entering directory '/<>'
> > > # Remove version control tags to avoid unnecessary conffile
> > > # resolution steps for administrators.
> > > sed -i '/\$OpenBSD:/d' \
> > > debian/tmp/etc/ssh/moduli \
> > > debian/tmp/etc/ssh/ssh_config \
> > > debian/tmp/etc/ssh/sshd_config
> > > dh_install -Nopenssh-client-udeb -Nopenssh-server-udeb
> > > dh_install -popenssh-client-udeb -popenssh-server-udeb \
> > > --sourcedir=debian/build-udeb
> > > Failed to copy 'etc/ssh/sshd_config': No such file or directory at
> /usr/share/dh-exec/dh-exec-install-rename line 68, <> line 7.
> > > dh_install: error: debian/openssh-server.install (executable config)
> returned exit code 127
> > > make[1]: *** [debian/rules:163: override_dh_install-arch] Error 25
>
> This seems to be a dh-exec regression, and when I fixed that I ran into
> additional regressions behind it.  I'm a bit confused at this point.
> You should be able to reproduce all these problems by building openssh
> 1:9.0p1-1.  All this used to work with dh-exec 0.23.4 - see e.g.:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=openssh=amd64=1%3A9.0p1-1%2Bb1=1652555012=0
>
> https://launchpadlibrarian.net/598976391/buildlog_ubuntu-kinetic-amd64.openssh_1%3A9.0p1-1_BUILDING.txt.gz
>
> The first problem here is that dh_install is run multiple times, and the
> first one moves a file out of debian/tmp/ when it's only supposed to
> copy.  This looks like a simple typo in dh-exec-install-rename; it tries
> to copy from a couple of different paths, but for the second one it
> calls "move" rather than "cp", which is surely just a mistake.  Patch
> for that follows:
>
> diff --git a/lib/dh-exec-install-rename b/lib/dh-exec-install-rename
> index 06fe885..2c269e8 100755
> --- a/lib/dh-exec-install-rename
> +++ b/lib/dh-exec-install-rename
> @@ -66,9 +66,9 @@ if (/([^\s]*)\s+=>\s+([^\s]*)/ || /^=>\s+([^\s]*)/) {
>  die "Failed to move '$src': $!";
>  } else {
>  cp ($src, File::Spec->catfile ($debpath, $dstfile)) or
> -move (File::Spec->catfile ("debian/tmp", $src),
> -  File::Spec->catfile ($debpath, $dstfile)) or
> -  die "Failed to copy '$src': $!";
> +cp (File::Spec->catfile ("debian/tmp", $src),
> +File::Spec->catfile ($debpath, $dstfile)) or
> +die "Failed to copy '$src': $!";
>  }
>  }
>
>
> The second dh_install command does the same copies even though it isn't
> supposed to be processing those packages, which is when we hit the
> failure.  Horrible, but maybe that's just how debhelper handles
> executable config files and dh-exec doesn't get much choice?  Not sure.
> (Relatedly, though it doesn't affect openssh, how can
> dh-exec-install-move possibly work properly if every dh_install run will
> end up moving files regardless of whether it's operating on the package
> in question?)
>
> After applying the above fix, the build gets further, and I get to:
>
>dh_missing
> dh_missing: warning:
> dh-exec.aqR1q_B1/etc/ufw/applications.d/openssh-server exists in debian/tmp
> but is not installed to anywhere (related file:
> "debian/tmp/dh-exec._KAY3sIj/etc/ufw/applications.d/openssh-server")
> dh_missing: warning:
> dh-exec.aqR1q_B1/usr/share/apport/package-hooks/openssh-server.py exists in
> debian/tmp but is not installed to anywhere (related file:
> "debian/tmp/dh-exec._KAY3sIj/usr/share/apport/package-hooks/openssh-server.py")
> dh_missing: warning: dh-exec.aqR1q_B1/usr/share/openssh/sshd_config exists
> in debian/tmp but is not installed to anywhere (related file:
> "debian/tmp/dh-exec._KAY3sIj/usr/share/openssh/sshd_config")
> dh_missing: warning: 

Bug#1017029: displaycal: fails to start, stall at spalsh screen after numerous error messages

[Jean-Luc Coulon (f5ibh)]

Hello Christian !

Yes! Good shot!

It works once libsdl2-mixer-2.0-0 installed.

Regards

Jean-Luc

Le 11/08/2022 à 23:59, Christian Marillat a écrit :

On 11 août 2022 20:46, "Jean-Luc Coulon (f5ibh)"  
wrote:


Package: displaycal
Version: 3.9.7-1
Severity: important
Tags: upstream

Hi,

Hi,


When I launch displaycal from a console, I get a lot of error messages
(the same group of messages repeated many times).
Then it stalls with the splash screen displayed.

Could you try to install the libsdl2-mixer-2.0-0 package and see if this
bug is gone ?

Christian

Bug#1017041: golang-github-bmatsuo-lmdb-go: flaky autopkgtest on s390x: segfaults

[Paul Gevers]

Source: golang-github-bmatsuo-lmdb-go
Version: 1.8.0+git20170215.a14b5a3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it was 
showing up as a regression for the upload of glibc [0]. I noticed that 
it regularly fails on s390x in what I quickly spotted as always the same 
place. It segfaults.


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

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

Paul

[0] 
https://ci.debian.net/data/autopkgtest/testing/s390x/g/golang-github-bmatsuo-lmdb-go/24525427/log.gz


=== RUN   TestTxn_Drop
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x3ff8af8 
pc=0x3ffb7e98052]


runtime stack:
runtime.throw({0x11b7cba, 0x2a})
/usr/lib/go-1.18/src/runtime/panic.go:992 +0x70
runtime.sigpanic()
/usr/lib/go-1.18/src/runtime/signal_unix.go:802 +0x2a4

goroutine 88 [syscall, locked to thread]:
runtime.cgocall(0x1169570, 0xc5dd50)
	/usr/lib/go-1.18/src/runtime/cgocall.go:157 +0x72 fp=0xc5dd20 
sp=0xc5dcf0 pc=0x1008472
github.com/bmatsuo/lmdb-go/lmdb._Cfunc_mdb_txn_begin(0x3ff74263140, 0x0, 
0x0, 0xcfe018)

_cgo_gotypes.go:885 +0x3a fp=0xc5dd48 sp=0xc5dd20 pc=0x115ab0a
github.com/bmatsuo/lmdb-go/lmdb.beginTxn.func1(0xc000194060, 0x0, 0x0, 
0xcfe000)


/tmp/autopkgtest-lxc.9o42tkd3/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/txn.go:99
 +0x108 fp=0xc5dd88 sp=0xc5dd48 pc=0x1162518
github.com/bmatsuo/lmdb-go/lmdb.beginTxn(0xc000194060, 0x0, 0x0)

/tmp/autopkgtest-lxc.9o42tkd3/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/txn.go:99
 +0x24e fp=0xc5ddd0 sp=0xc5dd88 pc=0x116228e
github.com/bmatsuo/lmdb-go/lmdb.(*Env).run(0xc000194060, 0x1, 0x0, 
0xc5de58)


/tmp/autopkgtest-lxc.9o42tkd3/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/env.go:507
 +0x74 fp=0xc5de18 sp=0xc5ddd0 pc=0x1161544
github.com/bmatsuo/lmdb-go/lmdb.(*Env).Update(...)

/tmp/autopkgtest-lxc.9o42tkd3/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/env.go:478
github.com/bmatsuo/lmdb-go/lmdb.openDBI(0xc000194060, {0x11ad4e4, 0x2}, 
0x4)


/tmp/autopkgtest-lxc.9o42tkd3/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/txn_test.go:1391
 +0x72 fp=0xc5de80 sp=0xc5de18 pc=0x1157a62
github.com/bmatsuo/lmdb-go/lmdb.TestTxn_Drop(0xc000102340)

/tmp/autopkgtest-lxc.9o42tkd3/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/txn_test.go:152
 +0xb6 fp=0xc5df68 sp=0xc5de80 pc=0x1149e16
testing.tRunner(0xc000102340, 0x11bac28)
	/usr/lib/go-1.18/src/testing/testing.go:1439 +0x122 fp=0xc5dfc0 
sp=0xc5df68 pc=0x10dfa52

testing.(*T).Run.func1()
	/usr/lib/go-1.18/src/testing/testing.go:1486 +0x5e fp=0xc5dfd8 
sp=0xc5dfc0 pc=0x10e0bee

runtime.goexit()
	/usr/lib/go-1.18/src/runtime/asm_s390x.s:742 +0x2 fp=0xc5dfd8 
sp=0xc5dfd8 pc=0x1079482

created by testing.(*T).Run
/usr/lib/go-1.18/src/testing/testing.go:1486 +0x442

goroutine 1 [chan receive]:
testing.(*T).Run(0xca0820, {0x11af3ba, 0xc}, 0x11bac28)
/usr/lib/go-1.18/src/testing/testing.go:1487 +0x466
testing.runTests.func1(0xca0820)
/usr/lib/go-1.18/src/testing/testing.go:1839 +0x8a
testing.tRunner(0xca0820, 0xc95cf8)
/usr/lib/go-1.18/src/testing/testing.go:1439 +0x122
testing.runTests(0xc0e060, {0x12a8c00, 0x49, 0x49}, 
{0xc0b48ae619a94ce3, 0x8bb2cc3cd7, 0x12c0e80})

/usr/lib/go-1.18/src/testing/testing.go:1837 +0x4d6
testing.(*M).Run(0xca6140)
/usr/lib/go-1.18/src/testing/testing.go:1719 +0x5fc
main.main()
_testmain.go:305 +0x1f8
FAILgithub.com/bmatsuo/lmdb-go/lmdb 1.656s


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017029: displaycal: fails to start, stall at spalsh screen after numerous error messages

[Christian Marillat]

On 11 août 2022 20:46, "Jean-Luc Coulon (f5ibh)"  
wrote:

> Package: displaycal
> Version: 3.9.7-1
> Severity: important
> Tags: upstream
>
> Hi,
>
> When I launch displaycal from a console, I get a lot of error messages
> (the same group of messages repeated many times).
> Then it stalls with the splash screen displayed.

I'm not sure if installing libsdl2-mixer-2.0-0.

Do you have a github account ?

Christian