Bug#1052607: pxdvi can not use haranoaji fonts

[Youhei SASAKI]

tags 1052607 moreinfo

On Mon, 25 Sep 2023 17:13:47 +0900,
Takeshi Soejima  wrote:
> 
> Package: xdvik-ja
> Version: 22.87.05+j1.42-2
> 
> Dear Maintainer,
> 
> If kanjix.map is generated to use haranoaji fonts (default) by
> kanji-config-updmap, dvipdfmx works fine, but pxdvi can not display
> japanese characters.

I can't reproduce this bugs.
Please send sample TeX file.

Best Wishes,
Youhei

--
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07

Bug#1053488: ITP: django-jsonfield -- Reusable JSONField for Django Models

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: django-jsonfield
  Version : 3.1.0
  Upstream Author : Brad Jasper 
* URL : https://github.com/rpkilby/jsonfield
* License : MIT
  Programming Lang: Python
  Description : Reusable JSONField for Django Models

  jsonfield is a reusable model field that allows you to store validated JSON,
  automatically handling serialization to and from the database. It is
  particularly useful when your app needs to be database-agnostic or when the
  built-in JSONField's extended querying is not being leveraged.

This library is a dependancy of the django-bulk-update module.

I plan to maintain this package as part of the Python team.

Bug#1053487: mariadb: FTBFS on hppa: Post-build test suite fails on multiple tests showing unexpected optimizer debug info

[Otto Kekäläinen]

Source: mariadb
Version: 1:10.11.1-1
Tags: upstream, confirmed, help, ftbfs
X-Debbugs-CC: debian-h...@lists.debian.org
User: debian-h...@lists.debian.org
Usertags: hppa

While reviewing the build logs from MariaDB 1:10.11.5-1 I saw multiple
tests fail with this pattern:

main.analyze_engine_stats 'innodb,slow_query_log_off' w1 [ fail ]
Test ended at 2023-10-05 02:34:21
CURRENT_TEST: main.analyze_engine_stats
--- /<>/mysql-test/main/analyze_engine_stats.result
2023-08-11 06:35:40.0 +
+++ /<>/mysql-test/main/analyze_engine_stats.reject
2023-10-05 02:34:19.664680297 +
@@ -16,9 +16,6 @@
 select '$out' as X;
 X
 {
-  "query_optimization": {
-"r_total_time_ms": "REPLACED"
-  },
   "query_block": {
 "select_id": 1,
 "r_loops": 1,
@@ -55,9 +52,6 @@
 select '$out' as X;
 X
 {
-  "query_optimization": {
-"r_total_time_ms": "REPLACED"
-  },
   "query_block": {
 "select_id": 1,
 "r_total_time_ms": "REPLACED",
@@ -88,9 +82,6 @@
 select '$out' as X;
 X
 {
-  "query_optimization": {
-"r_total_time_ms": "REPLACED"
-  },
   "query_block": {
 "select_id": 1,
 "r_total_time_ms": "REPLACED",
@@ -129,13 +120,9 @@
 ANALYZE FORMAT=JSON SELECT * FROM t1 WHERE a IN (SELECT s FROM t2);
 ANALYZE
 {
-  "query_optimization": {
-"r_total_time_ms": "REPLACED"
-  },
   "query_block": {
 "select_id": 1,
 "r_loops": 1,
-"r_total_time_ms": "REPLACED",
 "const_condition": "1",
 "nested_loop": [
   {
mysqltest: Result length mismatch

Failures were in tests: main.analyze_engine_stats,
main.derived_split_innodb, main.cte_recursive,
main.rowid_filter_innodb, main.analyze_stmt_orderby,
main.explain_json_format_partitions etc

There was also other tests failing on result mismatches to the degree
that the test suite stopped running.

Full log.
* 
https://buildd.debian.org/status/fetch.php?pkg=mariadb=hppa=1%3A10.11.5-1=1696473748=0


This is not a regression in the latest MariaDB version, as there is a
similar pattern of test failues also in e.g. a log from 10.11.1:
https://buildd.debian.org/status/fetch.php?pkg=mariadb=hppa=1%3A10.11.1-1=1674740552=0

However in the 10.11.1 build some tests passed that now failed.
Somebody with better understanding on how the optimizer debug output
works should be able to figure out what is HPPA specific here and why
it behaves differently and thus test suite ends up failing.

Bug#1053486: mariadb: FTBFS on ppc64: Post-build test suite fails on main.mysql_upgrade

[Otto Kekäläinen]

Source: mariadb
Version: 1:10.11.5-1
Tags: upstream, confirmed, help, ftbfs
X-Debbugs-CC: debian-powe...@lists.debian.org
User: debian-powe...@lists.debian.org
Usertags: ppc64

Builds on ppc64 repeatedly failed on test main.mysql_upgrade with error message:

main.mysql_upgrade 'innodb'  w8 [ fail ]
Test ended at 2023-10-04 05:48:24
CURRENT_TEST: main.mysql_upgrade
mariadb-dump: Couldn't execute 'show create table
`transaction_registry`': Unknown storage engine 'InnoDB' (1286)
mysqltest: In included file "./include/load_dump_and_upgrade.inc":
included from /<>/mysql-test/main/mysql_upgrade.test at line 507:
At line 15: exec of '/<>/builddir/client//mariadb-dump
--defaults-file=/<>/builddir/mysql-test/var/8/my.cnf
--defaults-group-suffix=.1 mysql >
/<>/builddir/mysql-test/var/tmp/8/mysql_database_backup'
failed, error: 512, status: 2, errno: 11
Output from before failure:
call mtr.add_suppression("Column count of mysql.proc is wrong.
Expected 21, found 20.");
The result from queries just before the failure was:
< snip >
Phase 8/8: Running 'FLUSH PRIVILEGES'
OK
SHOW CREATE USER mariadb_102;
CREATE USER for mariadb_102@%
CREATE USER `mariadb_102`@`%`
connect con1,localhost,mariadb_102;
select current_user();
current_user()
mariadb_102@%
disconnect con1;
connection default;
drop table mysql.global_priv;
rename table mysql.global_priv_bak to mysql.global_priv;
# End of 10.4 tests
#
# Check that mysql_upgrade can be run on mysqldump
# of mysql schema from previous versions
#
call mtr.add_suppression("innodb_(table|index)_stats has length
mismatch in the column name table_name");
call mtr.add_suppression("Column count of mysql.proc is wrong.
Expected 21, found 20.");

This seems to hint at some bug that the mariadb-upgrade perhaps didn't
run properly on this platform.

Full logs:
* 
https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64=1%3A10.11.5-1=1696398960=0
* 
https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64=1%3A10.11.5-1=1696469091=0

These logs also show failures in tests main.xa_prepared_binlog_off,
main.statistics_upgrade_not_done, main.greedy_optimizer with errors
hinting too disk issue / file corruption, but those failures were
sporadic.

The test main.mysql_upgrade was passing in the 10.11.4-1 builds on
Debian unstable, so this is clearly a regression in 10.11.5.

Bug#1053485: mariadb: FTBFS on sparc64: Post-build test suite fails on main.ctype_binary main.ctype_latin1

[Otto Kekäläinen]

Source: mariadb
Version: 1:10.11.5-1
Tags: upstream, confirmed, help, ftbfs
X-Debbugs-CC: debian-sp...@lists.debian.org
User: debian-sp...@lists.debian.org
Usertags: sparc64

Builds on sparc64 repeatedly failed on tests main.ctype_binary
main.ctype_latin1 with error message:

main.ctype_binaryw13 [ fail ]
Test ended at 2023-10-04 07:23:33
CURRENT_TEST: main.ctype_binary
mysqltest: At line 209: query 'SELECT COUNT(*) FROM t WHERE
EXTRACTVALUE(c,'a')='a'' failed:  (2013): Lost connection to
server during query
..
Thread 1 (Thread 0x8001022f68c0 (LWP 508035)):
#0  0x8001026918f8 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x01a18920 in handle_fatal_signal (sig=10) at
./sql/signal_handler.cc:360
curr_time = 1696404205
tm = {tm_sec = 25, tm_min = 23, tm_hour = 7, tm_mday = 4,
tm_mon = 9, tm_year = 123, tm_wday = 3, tm_yday = 276, tm_isdst = 0,
tm_gmtoff = 0, tm_zone = 0x100022e69e0 "UTC"}
thd = 0x80011c000c68
print_invalid_query_pointer = false
Backtrace stopped: Cannot access memory at address 0xf0

This indicates that the code path in these two tests are able to crash
the server.

Full logs with full stack trace at:
* 
https://buildd.debian.org/status/fetch.php?pkg=mariadb=sparc64=1%3A10.11.5-1=1696405551=0
* 
https://buildd.debian.org/status/fetch.php?pkg=mariadb=sparc64=1%3A10.11.5-1=1696474965=0

These two tests were passing in the 10.11.4-1 builds in Debian
unstable, so this is clearly a regression in 10.11.5.

Bug#1053470: ld.so: ignore tunables in secure mode

[Aurelien Jarno]

Hi,

On 2023-10-05 09:33, Michael Hudson-Doyle wrote:
> I think that is the sort of conclusion upstream is coming to in
> https://inbox.sourceware.org/libc-alpha/20231003201151.1406279-1-siddh...@sourceware.org/T/#e9123bc53d892ab6552e05109ce939d531d741092
> too. In any case, the upstream bug tracker / mailing list is probably the
> place to start with this.

I fully agree with that. Let's try to not have a different behavior for
each distribution by getting this done upstream. If it doesn't work we
could look at doing that at the distribution level.

Regards
Aurelien

> On Thu, 5 Oct 2023 at 07:00, Christian Göttsche 
> wrote:
> 
> > Package: glibc
> > Version: 2.37-12
> >
> > In the light of the recent privilege escalation vulnerability I'd like
> > to suggest disabling the support for tunables in secure mode (most
> > notably for setuid-binaries).
> > This would mitigate future regressions in the handling of the
> > environment variable and possible vulnerabilities caused by the
> > interaction of particular options with security relevant applications.
> >
> > The support could either be disabled at compile time[1] or at runtime
> > via a file existence check (either by reusing `/etc/suid-debug` or a
> > new one like `/etc/suid-tunables`).
> >
> >
> > [1]:
> > https://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=commitdiff;h=5d1686416ab766f3dd0780ab730650c4c0f76ca9
> >
> >

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1053481: libdpkg-perl: dpkg-source fails to generate (complete) Testsuite-Triggers if test deps have :native qualifier

[Guillem Jover]

Hi!

On Wed, 2023-10-04 at 20:17:58 -0400, James McCoy wrote:
> Package: libdpkg-perl
> Version: 1.18.8
> Severity: normal
> Control: affects -1 src:zsh src:poppler src:libjodycode src:doxygen 
> src:jemalloc src:jdupes src:libsdl2 src:iproute2

> Any test stanza in a debian/tests/control file which contains a
> foo:native Depends will not have its dependencies translated into
> Testsuite-Triggers.
> 
> This is due to an explicit check in Dpkg::Deps::Simple->parse_string()
> which only allows native qualified dependencies for build dependencies.
> 
> As an example, running “dpkg-source -b .” for jdupes shows

[…]

> Three warnings, one for each of the tests.  Since it does have a test
> without a native qualified dependency, Testsuite-Triggers is generated.
> 
> % grep Depends debian/tests/control
> Depends: @, tree:native
> Depends: @, tree:native
> Depends: @, tree:native
> Depends: @, forensics-samples-files
> % grep Testsuite ../jdupes_1.27.3-2.dsc
> Testsuite: autopkgtest
> Testsuite-Triggers: forensics-samples-files
> 
> As far as I can tell, this has been a problem since dpkg-source gained
> support for generating Testsuite-Triggers.

Right, nice catch! Given that these fields are based on what might
appear on build dependencies, I think it does make sense to consider
them an overlay on top of those. So I'll make them allow anything that
is allowed for build dependencies.

Thanks,
Guillem

Bug#1053484: tclodbc: Off-by-one error in SQLDescribeParam() call

[Christian Werner]

Package: tclodbc
Version: any
Severity: important
X-Debbugs-Cc: christian.wer...@t-online.de

Dear Maintainer,

according to its description, the SQLDescribeParam() ODBC API counts
the parameter numbers starting with 1. However, in the statemnt.cxx
a loop over the parameters of a query is run starting with 0 as
parameter number. In consequence, data type mapping of the client
parameters to the query might become wrong heavily depending on the
actual query itself. Problem can be easily resolved by changing

 SQLDescribeParam(..., i, ...);

to

 SQLDescribeParam(..., i+1, ...);

BR,
Christian

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

Kernel: Linux 5.10.0-25-amd64 (SMP w/4 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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tclodbc depends on:
ii  libc62.31-13+deb11u6
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libgcc1  1:8.3.0-6
ii  libodbc1 2.3.6-0.1+b1
ii  libstdc++6   10.2.1-6
ii  odbcinst1debian2 2.3.6-0.1+b1
ii  tcl  8.6.11+1

tclodbc recommends no packages.

Bug#1053476: [debian-mysql] Bug#1053476: galera-3: CVE-2023-5157

[Otto Kekäläinen]

Thanks for reporting this Salvatore!

Are you aware of what plans upstream has?

The Jira MDEV-25068 was fixed in Galera 26.4.12
(https://releases.galeracluster.com/galera-4.12/release-notes-galera-26.4.12.txt)
in 2022. i don't see any commits on
https://github.com/codership/galera/commits/3.x since 2022. i will
keep an eye for new upstream releases.

I can also review/merge for all Debian and Ubuntu releases still in
maintenance a patch if somebody wants to submit a Debian-specific fix
at https://salsa.debian.org/mariadb-team/galera-3/-/merge_requests. On
a quick look I did not find the 26.4.12 fix
(https://github.com/search?q=repo%3Acodership%2Fgalera+MDEV-25068=commits)
so I am not aware of any specific commit nor if it can be backported
to 25.3.37

Bug#1052812: python-pytest-timeout: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Scott Talbert]

On Tue, 26 Sep 2023, Lucas Nussbaum wrote:


Relevant part (hopefully):

 debian/rules binary
dh binary --buildsystem=pybuild --with python3
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:291: python3.11 setup.py config
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:291: /usr/bin/python3 setup.py build
running build
running build_py
copying pytest_timeout.py -> 
/<>/.pybuild/cpython3_3.11_python-pytest-timeout/build
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:291: cd 
/<>/.pybuild/cpython3_3.11_python-pytest-timeout/build; python3.11 
-m pytest


I think this is happening because of the change to dh-python to remove the 
*.egg-info files as part of 'clean'.  The egg is needed for running tests 
so the plugin can be found.  (The egg is built as part of the build 
process, but not until the 'install' phase.)  We could try to work around 
this, but I think a better solution is to switch to pyproject.toml, which 
I think shouldn't be affected by this problem.  I sent a pull request 
upstream.


Scott

Bug#1053483: Acknowledgement (tlsa can produce invalid records)

[Antoine Beaupré]

Control: forwarded -1 https://github.com/letoams/hash-slinger/issues/45
Control: tags -1 +patch

I submitted this patch upstream to fix this issue:

https://github.com/letoams/hash-slinger/pull/46

Attached as well.

-- 
Antoine Beaupré
torproject.org system administration
>From e3bec6e2a6b1bda7c52b4c585474fd7cc23ab643 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Charaoui?= 
Date: Wed, 4 Oct 2023 22:05:26 -0400
Subject: [PATCH] fix generic TLSA record generation

It seems like the calculation for the TLSA record never really worked,
as we're doing float division here on the `len()` field. In our case,
that field returned `35.0` which is not valid in our environment.

Doing an integer division gives the correct result in most cases, I
believe.

Closes: #45
---
 tlsa | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tlsa b/tlsa
index cea7230..ec97150 100755
--- a/tlsa
+++ b/tlsa
@@ -513,7 +513,7 @@ class TLSARecord:
 	def getRecord(self, generic=False):
 		"""Returns the RR string of this TLSARecord, either in rfc (default) or generic format"""
 		if generic:
-			return '%s IN TYPE52 \# %s %s%s%s%s' % (self.name, (len(self.cert)/2)+3 , self._toHex(self.usage), self._toHex(self.selector), self._toHex(self.mtype), self.cert)
+			return '%s IN TYPE52 \# %s %s%s%s%s' % (self.name, (len(self.cert)//2)+3 , self._toHex(self.usage), self._toHex(self.selector), self._toHex(self.mtype), self.cert)
 		return '%s IN TLSA %s %s %s %s' % (self.name, self.usage, self.selector, self.mtype, self.cert)
 
 	def _toHex(self, val):
-- 
2.39.2

Bug#1053483: tlsa can produce invalid records

[Antoine Beaupré]

Package: hash-slinger
X-Debbugs-Cc: lavam...@torproject.org
Version: 3.1-1.1~bpo11+1
Severity: grave

On Debian bullseye, running the following command here generates an
invalid DNS record:

pauli# ./tlsa --create --usage=3 --selector=1 --mtype=1 --certificate 
/srv/puppet.torproject.org/from-letsencrypt/cdn-fastly-backend.torproject.org.crt
 --port 443 cdn-fastly-backend.torproject.org --output=generic
Got a certificate for cdn-fastly-backend.torproject.org. with Subject:
/CN=cdn-fastly-backend.torproject.org
_443._tcp.cdn-fastly-backend.torproject.org. IN TYPE52 \# 35.0 
030101e86cb4aa5bec41b44c5e78c0b3b05992ab276d540376aca18eb494d8e229cd4c

Notice the float (35.0) there? That, of course, crashes bind with:

Notice: /Stage[main]/Dnsextras::Entries/Exec[rebuild torproject.org
zone]/returns: dns_rdata_fromtext:
/srv/dns.torproject.org/puppet-extra/include-torproject.org:945: near
'35.0': not a valid number

I suspect this wasn't caught by other users because it happens when the
len() of the cert string is an odd number, which, oddly, I guess it is
here.

I believe this is a release critical bug that should be fixed in
bookworm because it keeps the server from functioning at all. 

For a little background, we used hash-slinger as a replacement for
"swede" here (not packaged) that wasn't ported to Python 3. It *almost*
worked but crashed on some records with the above error, taking down our
main DNS server...

This was also reported in:

https://github.com/letoams/hash-slinger/issues/45

And is being tracked on our side at:

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

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

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

Versions of packages hash-slinger depends on:
ii  ca-certificates20210119
ii  dns-root-data  2021011101
ii  openssh-client 1:8.4p1-5+deb11u1
ii  python33.9.2-3
ii  python3-dnspython  2.0.0-1
ii  python3-gnupg  0.4.6-1
ii  python3-m2crypto   0.37.1-2
ii  python3-unbound1.13.1-1+deb11u1

hash-slinger recommends no packages.

hash-slinger suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/tlsa (from hash-slinger package)

-- 
Antoine Beaupré
torproject.org system administration

Bug#1053482: systemd-resolved: resolved can intermittingly fail AF_UNSPEC queries to CNAMEd domains

[benjamin]

Package: systemd-resolved
Version: 252.12-1~deb12u1
Severity: important

Dear Maintainer,

When systemd-resolved simultaneously does A and  queries, it fails if one 
of the queries returns a CNAME with a zero ttl and the other query returns a 
CNAME with a nonzero ttl. This happens in practice with several DNS providers. 
A fix for the problem was recently merged upstream at 
https://github.com/systemd/systemd/commit/8ec951e8d5cdd3ad632b1cbd8bcbe21d68b17512.
 See that commit for further details about the issue.

Please consider backporting this fix to bookworm.


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

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

Versions of packages systemd-resolved depends on:
ii  dbus [default-dbus-system-bus]  1.14.8-2~deb12u1
ii  libc6   2.36-9+deb12u3
ii  libssl3 3.0.9-1
ii  libsystemd-shared   252.12-1~deb12u1
ii  systemd 252.12-1~deb12u1

Versions of packages systemd-resolved recommends:
pn  libnss-myhostname  
ii  libnss-resolve 252.12-1~deb12u1

Versions of packages systemd-resolved suggests:
ii  polkitd  122-3

-- no debconf information

Bug#1053481: libdpkg-perl: dpkg-source fails to generate (complete) Testsuite-Triggers if test deps have :native qualifier

[James McCoy]

Package: libdpkg-perl
Version: 1.18.8
Severity: normal
Control: affects -1 src:zsh src:poppler src:libjodycode src:doxygen 
src:jemalloc src:jdupes src:libsdl2 src:iproute2

Any test stanza in a debian/tests/control file which contains a
foo:native Depends will not have its dependencies translated into
Testsuite-Triggers.

This is due to an explicit check in Dpkg::Deps::Simple->parse_string()
which only allows native qualified dependencies for build dependencies.

As an example, running “dpkg-source -b .” for jdupes shows

% dpkg-source -b .
dpkg-source: warning: can't parse dependency tree:native
dpkg-source: warning: can't parse dependency tree:native
dpkg-source: warning: can't parse dependency tree:native
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building jdupes using existing ./jdupes_1.27.3.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building jdupes in jdupes_1.27.3-2.debian.tar.xz
dpkg-source: info: building jdupes in jdupes_1.27.3-2.dsc

Three warnings, one for each of the tests.  Since it does have a test
without a native qualified dependency, Testsuite-Triggers is generated.

% grep Depends debian/tests/control
Depends: @, tree:native
Depends: @, tree:native
Depends: @, tree:native
Depends: @, forensics-samples-files
% grep Testsuite ../jdupes_1.27.3-2.dsc
Testsuite: autopkgtest
Testsuite-Triggers: forensics-samples-files

As far as I can tell, this has been a problem since dpkg-source gained
support for generating Testsuite-Triggers.

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

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

Versions of packages libdpkg-perl depends on:
ii  dpkg  1.22.0
ii  perl  5.36.0-9

Versions of packages libdpkg-perl recommends:
ii  bzip2   1.0.8-5+b1
ii  libfile-fcntllock-perl  0.22-4+b1
ii  liblocale-gettext-perl  1.07-6
ii  xz-utils5.4.4-0.1

Versions of packages libdpkg-perl suggests:
ii  binutils   2.41-5
ii  brz [bzr]  3.3.4-1
ii  clang-14 [c-compiler]  1:14.0.6-16
ii  clang-16 [c-compiler]  1:16.0.6-15
ii  debian-keyring 2023.09.24
ii  gcc [c-compiler]   4:13.2.0-1
ii  gcc-13 [c-compiler]13.2.0-4
ii  git1:2.42.0-1
ii  gnupg  2.2.40-1.1
ii  gpgv   2.2.40-1.1
ii  patch  2.7.6-7
ii  sensible-utils 0.0.20

-- no debconf information

Bug#1052676: linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK)

[Ben Hutchings]

Control: severity -1 important

On Tue, 2023-09-26 at 22:45 +0200, Diederik de Haas wrote:
[...]
> I don't know *IF* it's possible to still add hardware support to the 6.1 
> kernel which is used in Stable/Bookworm. Assuming the platforms were properly 
> supported in the upstream 6.1 kernel, then there still has been zero testing 
> with it on a Debian system, which does not sound ideal for Stable.
> One of the Debian kernel maintainers would have to answer whether it is 
> possible at all for 6.1/Stable/Bookworm.
[...]

I'm not sure if it's documented anywhere, but release team policy has
been that hardware enablement is allowed in stable updates.  (If that
involves changes to a driver we already enabled, the benefit has to be
weighed against the risk of regressions for previously supported
devices.  But I don't that's being proposed here.)

Even though there won't have been broad testing of the Debian kernel
configuration on the Mediatek SoCs, this can't possibly be a regression
for them.

Ben.


-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth



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

Bug#1053122: linux-image-6.5.0-1-amd64: using smp_processor_id() in preemptible

[Ben Hutchings]

Control: retitle -1 linux-image-6.5.0-1-amd64: Kernel page fault in
process exit due to bit flip
Control: tag -1 moreinfo

On Wed, 2023-09-27 at 20:45 +0200, Gabriel Francisco wrote:
> Package: src:linux
> Version: 6.5.3-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: frc.gabr...@gmail.com
> 
> Dear Maintainer,
> 
> First of all thanks for your hard work!
> 
> I noticed my computer started freezing for few seconds when entering/exiting
> full screen videos in youtube using firefox and while trying to check if the
> issue also afected chromium I saw the following message in dmesg:
> 
> [12569.564300] BUG: unable to handle page fault for address: 991989e936b8
> [12569.564304] #PF: supervisor write access in kernel mode
> [12569.564306] #PF: error_code(0x0002) - not-present page

The first BUG message should be more meaningful that what comes after.
This shows the kernel tried to access non-existent memory.

> [12569.564308] PGD 0 P4D 0 
> [12569.564311] Oops: 0002 [#1] PREEMPT SMP NOPTI
> [12569.564314] CPU: 10 PID: 328649 Comm: Chroot Helper Not tainted 
> 6.5.0-1-amd64 #1  Debian 6.5.3-1
> [12569.564317] Hardware name: ASUS System Product Name/ROG STRIX B550-F 
> GAMING WIFI II, BIOS 3205 08/14/2023
> [12569.564318] RIP: 0010:down_write+0x23/0x70
> [12569.564324] Code: 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 
> fb e8 2e bc ff ff bf 01 00 00 00 e8 74 3a 53 ff 31 c0 ba 01 00 00 00  48 
> 0f b1 13 75 33 65 48 8b 04 25 80 29 03 00 48 89 43 08 bf 01
> [12569.564326] RSP: 0018:a189d736fc70 EFLAGS: 00010246
> [12569.564328] RAX:  RBX: 991989e936b8 RCX: 
> 891797aaef00
> [12569.564330] RDX: 0001 RSI: 891989e645c0 RDI: 
> 8e7c95dc
> [12569.564331] RBP:  R08: 0060 R09: 
> 80400014
> [12569.564333] R10: 8918cbfeb7f8 R11: 0006 R12: 
> 7f7e5fd0
> [12569.564334] R13: 0001 R14: 891989e645c0 R15: 
> 891989e64958

The CPU registers contain several addresses starting 89, except for
rbx which starts 99 (and is the faulting address).  That looks like
a single bit got flipped.

This could be due to a kernel bug, but is more likely a hardware
problem.  Please test the RAM with memtest86+.  Also if you've enabled
any overclocking options, turn those off.

[...]
> After that the computer can't shutdown and systemd keeps waiting on process 
> PID 328649 (Chroot Helper).

This (and the other BUG messages) are because that process crashed in
kernel mode and couldn't properly exit.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth



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

Bug#1053480: ITP: qnetload -- Display graphically network speed and usage

[Carles Pina i Estany]

Package: wnpp
Severity: wishlist
Owner: Carles Pina i Estany 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: qnetload
  Version : 1.3.2
  Upstream Contact: Carles Pina i Estany 
* URL : https://github.com/cpina/qnetload
* License : GPL-3.0
  Programming Lang: C++
  Description : Display graphically network speed and usage

 Similar look and feel to xnetload with some extra features (keeping the
 retro UI).
 .
 Change the monitored interface, on startup it uses previous interface,
 and right click on the interface name to see the IP.
 .
 Show the current speed and total downloaded/uploaded from the start
 of qnetload to now. Click on graph to calculate the MB/hour projected.
 Click on the Started / Elapsed to rotate between them.

I used to use xnetload which is not part of Debian anymore (since before
2017 I think). xnetload is available in
https://github.com/rsmith-nl/xnetload but no updates, when I checked
(this might be fixed) had problems if an interface transmited more than
2^32 (4 GB).

qnetload is a more modern (Qt) but similar UI alternative.

I've found {x,q}netload very useful on situations such as:
- metered connections (e.g. mobile 4G+, etc.) to see that data is not
  being over-used. Also to get an estimate (with a click of the mouse)
  on how much data this video-call or radio station is going to use over
  one hour
- very flaky connections (e.g. on a ship, airplane, train, etc.)
- useful for debugging the connection (application got stuck or all the
  network stopped transmitting for some seconds?)

In 2017, when I started implementing qnetload, I could not find any
alternative to it.

I plan to maintain it myself.

I need a sponsor.

I have a working package that I will upload to
https://mentors.debian.net/ in about 2 or 3 days.

Bug#1024695: Comp warnings fix pending

[Manphiz]

Control: tags 1024695 pending
Control: tags 1034734 pending
Control: tags 1037179 pending
Control: tags 1051478 pending
thanks

Hi,

I have a merge request[1] pending that should fix most of the comp
warnings which should be included in the next release.  Stay tuned.


[1] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/12


signature.asc
Description: PGP signature

Bug#1053251: [Emc-developers] Bug#1053251: How to fix this bug

[Rod Webster]

Andy,

I think this describes the process.

https://www.debian.org/doc/manuals/developers-reference/pkgs.html

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Thu, 5 Oct 2023 at 07:45, andy pugh  wrote:

> Are there any guidelines on the process of how to fix this bug in the
> released version?
> Being in Debian is all new to us, we have been releasing via our own
> repository for the last 15 years or more.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> emc-develop...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Bug#1053251: How to fix this bug

[andy pugh]

Are there any guidelines on the process of how to fix this bug in the
released version?
Being in Debian is all new to us, we have been releasing via our own
repository for the last 15 years or more.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)

[John Paul Adrian Glaubitz]

Hi Ilias!

On Wed, 2023-10-04 at 12:26 +0200, John Paul Adrian Glaubitz wrote:
> Looking at the ghc package in openSUSE, I found this patch [1] which disables 
> unboxed arrays
> in order to fix the build on big-endian systems. And, indeed, disabling 
> unboxed arrays in
> libraries/containers/containers/include/containers.h allows me to fully build 
> ghc from git
> on 32-bit PowerPC. See also [2].

I managed to track this down to this commit [1]:

ba089952f034d91718c71f5ef297fe54818559df is the first bad commit
commit ba089952f034d91718c71f5ef297fe54818559df
Author: Sylvain Henry 
Date:   Fri Jan 15 12:33:40 2021 +0100

Bignum: add Natural constant folding rules (#15821)

* Implement constant folding rules for Natural (similar to Integer ones)

* Add mkCoreUbxSum helper in GHC.Core.Make

* Remove naturalTo/FromInt

  We now only provide `naturalTo/FromWord` as
  the semantics is clear (truncate/zero-extend). For Int we have to deal
  with negative numbers (throw an exception? convert to Word
  beforehand?) so we leave the decision about what to do to the caller.

  Moreover, now that we have sized types (Int8#, Int16#, ..., Word8#,
  etc.) there is no reason to bless `Int#` more than `Int8#` or `Word8#`
  (for example).

* Replaced a few `()` with `void#`

 compiler/GHC/Builtin/Names.hs  | 310 +++---
 compiler/GHC/Core/Make.hs  |  14 +-
 compiler/GHC/Core/Opt/ConstantFold.hs  | 670 +++--
 compiler/GHC/HsToCore/Expr.hs  |   6 +-
 compiler/GHC/Types/Id/Make.hs-boot |   1 +
 libraries/base/GHC/Enum.hs |   4 +-
 libraries/base/GHC/Float.hs|   6 +-
 libraries/base/GHC/Int.hs  |  16 +-
 libraries/base/GHC/Natural.hs  |  20 +-
 libraries/base/GHC/Num.hs  |  12 +-
 libraries/base/GHC/Real.hs |   2 +-
 libraries/ghc-bignum/src/GHC/Num/BigNat.hs |  64 +-
 libraries/ghc-bignum/src/GHC/Num/Integer.hs|  14 +-
 libraries/ghc-bignum/src/GHC/Num/Natural.hs| 162 +++--
 libraries/ghc-bignum/src/GHC/Num/Primitives.hs |   4 +-
 libraries/ghc-bignum/src/GHC/Num/WordArray.hs  |   4 +-
 .../integer-gmp/src/GHC/Integer/GMP/Internals.hs   |   8 +-
 testsuite/tests/lib/integer/Makefile   |  50 +-
 testsuite/tests/lib/integer/all.T  |   1 +
 .../tests/lib/integer/naturalConstantFolding.hs| 172 ++
 .../lib/integer/naturalConstantFolding.stdout  |  38 ++
 testsuite/tests/perf/compiler/T16473.stdout|   2 +-
 .../tests/simplCore/should_compile/T15445.stderr   |   2 +-
 23 files changed, 1057 insertions(+), 525 deletions(-)
 create mode 100644 testsuite/tests/lib/integer/naturalConstantFolding.hs
 create mode 100644 testsuite/tests/lib/integer/naturalConstantFolding.stdout

And I have verified that this commit actually introduced the segfault on 32-bit 
PowerPC.

Adrian

> [1] 
> https://gitlab.haskell.org/ghc/ghc/-/commit/ba089952f034d91718c71f5ef297fe54818559df

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

Bug#1052551: gnome-calculator: Does not start from GUI (gnome), incurs error: "Calculator is not responding force quit wait"

[Mauro Meloni]

Same here.
Starting gnome-calculator on a terminal shields the following error messages:
** (gnome-calculator:54274): WARNING **: 18:11:44.979: 
currency-provider.vala:161: Couldn't download IMF currency rate file: HTTP/2 
Error: INTERNAL_ERROR
(gnome-calculator:54274): libsoup-WARNING **: 18:11:44.979: 
(../libsoup/soup-session.c:334):soup_session_dispose: runtime check failed: 
(soup_connection_manager_get_num_conns (priv->conn_manager) == 0)
(gnome-calculator:54274): libsoup-WARNING **: 18:11:44.979: 
(../libsoup/soup-connection-manager.c:78):soup_host_free: runtime check failed: 
(host->conns == NULL)

Bug#1052338: kea: /etc/init.d/kea-dhcp-ddns-server

[Paride Legovini]

Control: severity -1 wishlist  

Hi Alessandro,

Alessandro Vesely wrote on 20/09/2023:
> I installed kea on Devuan, but bugreport said kea is unforked.
> 
> The server won't start, because DAEMON doesn't exist:
> 
> 799-north:init.d# diff -u /tmp/kea-dhcp-ddns-server kea-dhcp-ddns-server
> --- /tmp/kea-dhcp-ddns-server 2023-09-20 19:39:20.0 +0200
> +++ kea-dhcp-ddns-server  2023-09-20 19:39:23.0 +0200
> @@ -17,7 +17,7 @@
>  PATH=/sbin:/usr/sbin:/bin:/usr/bin
>  DESC=kea-dhcp-ddns
>  NAME=kea-dhcp-ddns
> -DAEMON=kea-dhcp-ddns
> +DAEMON=/usr/sbin/kea-dhcp-ddns
>  DAEMON_ARGS="-c /etc/kea/kea-dhcp-ddns.conf"
>  PIDFILE=/run/$NAME.pid
>  SCRIPTNAME=/etc/init.d/$NAME

In principle I'd like this to be tested on a Debian system,
but the fix seems really straightforward.

Would you be able to submit it as an MP against the Kea
packaging repository [1]? Thanks!

Paride

[1] https://salsa.debian.org/debian/isc-kea/

Bug#1053479: RFS: streamlink/6.2.1-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.2.1.

  * Package name: streamlink
Version : 6.2.1-1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs  : https://github.com/wxMaxima-developers/wxmaxima
Section : python

It builds those binary packages:

   python3-streamlink - Python module for extracting video streams from
various websites
   python3-streamlink-doc - CLI for extracting video streams from
various websites (documentation)
   streamlink - CLI for extracting video streams from various websites
to a video player

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

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

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

   dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.2.1-1.dsc

Changes since the last upload to unstable:
streamlink (6.2.1-1) unstable; urgency=medium

  * New upstream version 6.2.1
  * d/patches: update patches

 -- Alexis Murzeau   Thu, 21 Sep 2023 19:54:32 +0200



Regards,
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F




OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053301: udev.postinst removes valid /etc/rc*.d/ symlinks

[Mark Hindley]

Control: tags -1 patch
Control: affects -1 initscripts
Control: severity -1 serious
Justification: Breaks unrelated packages, breaks non-systemd boot

Michael,

Please find a patch below that addresses this issue in my test setup. I can
offer to NMU if you would like?

I have provided an easy means to reproduce the bug and a clear justfication for
why I think this is an RC bug. If you disagree, please explain why, rather than
just changing the severity. Thanks.

Best wishes

Mark

diff --git a/debian/changelog b/debian/changelog
index fe1f4bc..ec8a75a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+systemd (254.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * d/udev.postinst: Correct version number test for dropping
+/etc/init.d/udev and only remove /etc/rc?.d/symlinks if
+/etc/init.d/udev doesn't exist.  (Closes: #1053301)
+
+ -- Mark Hindley   Wed, 04 Oct 2023 18:30:36 +0100
+
 systemd (254.5-1) unstable; urgency=medium
 
   * New upstream version 254.5
diff --git a/debian/udev.postinst b/debian/udev.postinst
index 84ff782..04bafa2 100644
--- a/debian/udev.postinst
+++ b/debian/udev.postinst
@@ -11,7 +11,8 @@ case "$1" in
 # update/create hwdb before we (re)start udev
 update_hwdb
 
-if dpkg --compare-versions "$2" lt-nl "254.1-4~"; then
+if dpkg --compare-versions "$2" lt-nl "254.3-1~" &&
+[ ! -f /etc/init.d/udev ] ; then
 update-rc.d udev remove || true
 fi
 ;;

Bug#1053478: RFS: angband/4.2.5+dfsg-1 -- roguelike game

[Chris Carr]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : angband
   Version  : 4.2.5+dfsg-1
   Upstream contact : Nick McConnell (nckmccn...@gmail.com)
 * URL  : https://github.com/angband/angband
 * License  : GPL-2 (and others, all DFSG-free)
 * Vcs  : https://salsa.debian.org/games-team/angband
   Section  : games

The source builds the following binary packages:

  angband - roguelike game

  angband-data - architecture-independent game data



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

  https://salsa.debian.org/games-team/angband

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

  dget -x https://bass.fugue.org/angband/4.2.5/angband_4.2.5+dfsg-1.dsc



Changes since the last upload:

angband (1:4.2.5+dfsg-1) UNRELEASED; urgency=low

  [ Chris Carr ]
  * new 4.x upstream release (Closes: #799358, #778811, #781747, #782437) (LP: 
#1827167)
  * fix the d/auto_clean step
  * refresh the patches for latest release:
* remove usage of __DATE__ to make the package reproducible
* remove-nonfree.patch: redo it smarter
* point to the locally-installed manual from the help screen
* make the console port behave the same as others
  * remove old NEWS entry from 2015
  * fix FTBFS after successful build (Closes: #1043963)

  [ Alexandre Detiste ]
  * repack archive to drop Windows .dll & non-free .mp3
  * modernize build-deps:
* SDL1 -> SDL2 (Closes: #1038023, #781751)
  * also libsdl-ttf2.0-0 -> libsdl2-ttf-2.0-0
(Closes: #732253) (LP: #1309711)
* tex/pdf toolchain -> HTML Sphinx
* libncursesw5-dev | libncursesw-dev | ncursesw-dev
   -> libncurses-dev (Closes: #851238)
  * fix FTCBFS using patch provided (Closes: #894114)
  * set Multi-Arch: foreign
  * compatibility with DebHelper 14 & 15
  * remove old conffiles for good (Closes: #781561)

  [ Debian Janitor ]
  * Update lintian override info format in d/angband.lintian-overrides
  * Use secure copyright file specification URI.
  * Drop use of autotools-dev debhelper.
  * Use secure URI in debian/watch.
  * Use secure URI in Homepage field.
  * Bump debhelper from deprecated 8 to 13.
  * Set debhelper-compat version in Build-Depends.
  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse.
  * Fix day-of-week for changelog entries 1:3.3.2-2, 1:3.1.2v2-1.


Regards,

Chris Carr

Bug#1006292: bullseye-pu: package plasma-discover/5.20.5-3

[Patrick Franz]

Hej,

Am Mittwoch, 4. Oktober 2023, 15:02:11 CEST schrieb Adam D. Barratt:
[...]
> Thanks, but it's too late to get the updated package accepted for the
> 11.8 point release now in any case.
> 
> The question that remains from Jonathan's mail is - is it OK to
> include the plasma-desktop and knewstuff updates without
> plasma-discover, or should those be held back until plasma-discover
> is ready, and all three released at the same time?

I don't know to be honest. I guess the safe way is to release all three 
together.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1053470: ld.so: ignore tunables in secure mode

[Michael Hudson-Doyle]

I think that is the sort of conclusion upstream is coming to in
https://inbox.sourceware.org/libc-alpha/20231003201151.1406279-1-siddh...@sourceware.org/T/#e9123bc53d892ab6552e05109ce939d531d741092
too. In any case, the upstream bug tracker / mailing list is probably the
place to start with this.

On Thu, 5 Oct 2023 at 07:00, Christian Göttsche 
wrote:

> Package: glibc
> Version: 2.37-12
>
> In the light of the recent privilege escalation vulnerability I'd like
> to suggest disabling the support for tunables in secure mode (most
> notably for setuid-binaries).
> This would mitigate future regressions in the handling of the
> environment variable and possible vulnerabilities caused by the
> interaction of particular options with security relevant applications.
>
> The support could either be disabled at compile time[1] or at runtime
> via a file existence check (either by reusing `/etc/suid-debug` or a
> new one like `/etc/suid-tunables`).
>
>
> [1]:
> https://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=commitdiff;h=5d1686416ab766f3dd0780ab730650c4c0f76ca9
>
>

Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory

[Mark Hindley]

Control: tags -1 moreinfo

Ian

On Wed, Sep 27, 2023 at 10:33:32PM +0100, Ian Jackson wrote:
> Mark Hindley writes ("Bug#1052942: insserv: FTBFS: insserv: Could not read 
> script nolsbheader: No such file or directory"):
> > Thanks for this. However, I am currently unable to repoduce this
> > failure in my customary pbuilder setup. And it doesn't appear at
> > reproducible builds either[1]
> 
> I just tried this myself with my usual sbuild setup and it succeeded
> there too[1].


Thanks for your confirmation.

> Lucas, I think something from your rebuild environment
> (a chroot of some kind I presume) must be triggering this failure.  Is
> there some way we can reproduce it more precisely (eg, a buildinfo
> file?)

Yes, I agree a buildinfo file might give a hint.

> I looked at the build log
>  http://qa-logs.debian.net/2023/09/25/insserv_1.24.0-1_unstable.log
> and compared it to the one from my sbuild, using diff.  There are a
> lot of changes to the "furniture" but also there are noise changes to
> the output of the insserv test suite, including ordring changes of
> passing tests.  This seemed surprising to me.
> 
> Mark, is the insserv test suite supposed to produce deterministic
> output ?

I have never had the need to look at the testsuite since I started looking after
the package. A quick look now doesn't immediately reveal something that would
obviously change the order of the tests.

I tried again locally with make -j8 and still could not reproduce any failure.

Mark

Bug#1053477: RFP: pass-secret-service -- dbus-service to serve secret-service api with pass backend

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: pass-secret-service
  Version : no release published
  Upstream Contact: Matthias Dellweg 
* URL : https://github.com/mdellweg/pass_secret_service/
* License : GPL-3
  Programming Lang: Python
  Description : dbus-service to serve secret-service api with pass backend

Expose the libsecret dbus api with pass as backend.



I am not aware of any other wrapper around pass that provides a
standard interface for other applications to store their secrets into
it, is anyone else?

Requirements mention a few problematic deps:

git+https://github.com/mdellweg/python-dbus-next@master
secretstorage (python library not packaged in Debian)

It also depends on pypass, but that's already packaged in Debian
(interesting!).

Bug#1053476: galera-3: CVE-2023-5157

[Salvatore Bonaccorso]

Source: galera-3
Version: 25.3.37-1
Severity: important
Tags: security upstream
Forwarded: https://jira.mariadb.org/browse/MDEV-25068
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for galera-3.

CVE-2023-5157[0]:
| A vulnerability was found in MariaDB. An OpenVAS port scan on ports
| 3306 and 4567 allows a malicious remote client to cause a denial of
| service.

Can you please investigate this further, it looks fixes are in galera
itself.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5157
https://www.cve.org/CVERecord?id=CVE-2023-5157
[1] https://jira.mariadb.org/browse/MDEV-25068

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1053475: python-django: CVE-2023-43665: Denial-of-service possibility in django.utils.text.Truncator

[Salvatore Bonaccorso]

Source: python-django
Version: 3:4.2.5-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3:3.2.21-1
Control: found -1 3:3.2.19-1

Hi,

The following vulnerability was published for python-django.

CVE-2023-43665[0]:
| Denial-of-service possibility in django.utils.text.Truncator


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-43665
https://www.cve.org/CVERecord?id=CVE-2023-43665
[1] https://www.djangoproject.com/weblog/2023/oct/04/security-releases/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1053474: snappy-java: CVE-2023-43642

[Salvatore Bonaccorso]

Source: snappy-java
Version: 1.1.8.3-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for snappy-java.

CVE-2023-43642[0]:
| snappy-java is a Java port of the snappy, a fast C++
| compresser/decompresser developed by Google. The SnappyInputStream
| was found to be vulnerable to Denial of Service (DoS) attacks when
| decompressing data with a too large chunk size. Due to missing upper
| bound check on chunk length, an unrecoverable fatal error can occur.
| All versions of snappy-java including the latest released version
| 1.1.10.3 are vulnerable to this issue. A fix has been introduced in
| commit `9f8c3cf74` which will be included in the 1.1.10.4 release.
| Users are advised to upgrade. Users unable to upgrade should only
| accept compressed data from trusted sources.

Please double check as mainly filling the issue to make you aware of
the upstream issue.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-43642
https://www.cve.org/CVERecord?id=CVE-2023-43642
[1] 
https://github.com/xerial/snappy-java/commit/9f8c3cf74223ed0a8a834134be9c917b9f10ceb5
[2] 
https://github.com/xerial/snappy-java/security/advisories/GHSA-55g7-9cwv-5qfv

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1028489: transition: boost1.81

[David James]

Hi Anton,

Is there anything I can do to help this transition along? I wish to
package software that does not build on 1.74, but does on 1.81 and 1.82.
If there's anyway I can assist with bumping boost-defaults to 1.81 or 1.82
I would be happy to help.

Regards,

David James

Bug#1004256: UPDATE

[Renee Brutcher]

Yes hello I am trying to update, however, it is appearing in my end that  the " 
to" / " from" roles are reversed

Thank You,
ReneeB
Sent via the Samsung Galaxy Note9, an AT 5G Evolution capable smartphone

Bug#1053443: automount should not act if filesystem is already mounted

[Marc Haber]

On Wed, Oct 04, 2023 at 08:41:10PM +0200, Michael Biebl wrote:
> Do you both /efi *and* /boot/efi
> 
> The automount unit is for efi.automount

No, just /boot/efi, but the aide run triggers the automount, which
affects for some strange reason /boot/efi and makes the inode numbers
change.

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#1053473: xfce4-terminal version 1.0.4 has a bug and does not have the tab 'Shortcuts' in Terminal Preferences

[Antonio Meirelles]

Package: xfce4-terminal
Version: 1.1.0-2
Severity: normal
X-Debbugs-Cc: apmeirel...@gmail.com

Dear Maintainer,

xfce4-terminal version 1.0.4 has a bug and does not have the tab 'Shortcuts' in 
Terminal Preferences. If I install manually xfce4-terminal version 1.1.0 it 
shows the 'Shortcuts' tab correctly.

This is how it was tested:

Step 1: Manual download of the package:
wget 
http://ftp.us.debian.org/debian/pool/main/x/xfce4-terminal/xfce4-terminal_1.1.0-2_amd64.deb

Step 2: Installation of the package:
sudo apt install ./xfce4-terminal_1.1.0-2_amd64.deb

Step 3: Go to 'Terminal Preferences' and check for the presence of 'Shortcuts' 
tabs next to 'Advanced' tab


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

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

Versions of packages xfce4-terminal depends on:
ii  exo-utils4.18.0-1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpcre2-8-0 10.42-1
ii  libutempter0 1.2.1-3
ii  libvte-2.91-00.70.6-1~deb12u1
ii  libx11-6 2:1.8.4-2+deb12u1
ii  libxfce4ui-2-0   4.18.2-2
ii  libxfce4util74.18.1-2
ii  libxfconf-0-34.18.0-2
ii  perl 5.36.0-7

Versions of packages xfce4-terminal recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.8-2~deb12u1

xfce4-terminal suggests no packages.

-- no debconf information

Bug#1053469: libx11 FTBFS: dh_quilt_unpatch: error: quilt --quiltrc /dev/null pop -a || test $? = 1 returned exit code 1

[Sven Joachim]

Control: reassign -1 quilt
Control: forcemerge 1053444 -1

On 2023-10-04 20:50 +0300, Adrian Bunk wrote:

> Source: libx11
> Version: 2:1.8.7-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/logs.php?pkg=libx11=2%3A1.8.7-1
>
> ...
>  fakeroot debian/rules clean
> dh clean --with quilt --builddirectory=build/
>dh_auto_clean -O--builddirectory=build/
>dh_autoreconf_clean -O--builddirectory=build/
>dh_quilt_unpatch -O--builddirectory=build/
> No patch removed
> dh_quilt_unpatch: error: quilt --quiltrc /dev/null pop -a || test $? = 1 
> returned exit code 1
> make: *** [debian/rules:4: clean] Error 25

This is a bug in dh_quilt_unpatch which makes many packages FTBFS.

Cheers,
   Sven

Bug#1053443: automount should not act if filesystem is already mounted

[Michael Biebl]

Do you both /efi *and* /boot/efi

The automount unit is for efi.automount


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053472: starts w/o writing pid file, leading systemd to kill it

[Joey Hess]

Package: sasl2-bin
Version: 2.1.28+dfsg1-3
Severity: normal

saslauthd was not running after an upgrade. 
Investigation showed this happening after systemctl start:

Oct 04 14:21:21 kite systemd[1]: Failed to start saslauthd.service - SASL 
Authentication Daemon.
Oct 04 14:21:21 kite systemd[1]: saslauthd.service: Failed with result 
'timeout'.
Oct 04 14:21:21 kite systemd[1]: saslauthd.service: start operation timed out. 
Terminating.
Oct 04 14:20:21 kite saslauthd[752305]: : auth failure: 
[user=linda] [service=smtp] [realm=kitenet.net] [mech=sasldb] [reason=Unknown]
Oct 04 14:19:51 kite systemd[1]: saslauthd.service: Can't open PID file 
/run/saslauthd/saslauthd.pid (yet?) after start: No such file or directory
Oct 04 14:19:51 kite saslauthd[752305]: : listening on socket: 
/var/spool/postfix/var/run/saslauthd/mux
Oct 04 14:19:51 kite saslauthd[752305]: : master pid is: 752305
Oct 04 14:19:51 kite systemd[1]: Starting saslauthd.service - SASL 
Authentication Daemon...

/run/saslauthd/saslauthd.pid did not exist. Apparently the daemon did start
though since it was handling auth attempts.

systemctl start saslauthd actually hung while this was going on, until systemd
timed out and killed the daemon.

I have worked around this by editing /usr/lib/systemd/system/saslauthd.service
and commenting out PIDFile=/var/run/saslauthd/saslauthd.pid

Aha: I notice that the pid file is being created, but in
/var/spool/postfix/var/run/saslauthd. Apparently because I use -m to make it
put the mix file there. It seems it might be new behavior for it to write the
pid file there too? Or systemd has changed its behavior when it doesn't find a
pid file. Anyway, I think -m should not affect where it puts the pid file.

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

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

Versions of packages sasl2-bin depends on:
ii  db-util5.3.2
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.37-12
ii  libcrypt1  1:4.4.36-2
ii  libdb5.3   5.3.28+dfsg2-2
ii  libkrb5-3  1.20.1-4
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  libpam0g   1.5.2-7
ii  libsasl2-2 2.1.28+dfsg1-3
ii  libssl33.0.11-1
ii  perl   5.36.0-9

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

-- Configuration Files:
/etc/default/saslauthd changed:
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="pam"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
MECHANISMS=sasldb


-- debconf information:
  cyrus-sasl2/purge-sasldb2: false
  cyrus-sasl2/upgrade-sasldb2-failed:
  cyrus-sasl2/upgrade-sasldb2-backup-failed:
  cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak

-- 
see shy jo

Bug#1053471: libpython3.11-testsuite: Installation fails with SyntaxError

[Ara Keary]

Package: libpython3.11-testsuite
Version: 3.11.6-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: ara.ke...@gmail.com

Installation fails with a message


Setting up libpython3.11-testsuite (3.11.6-1) ...
  File "/usr/lib/python3.11/test/test_future_stmt/badsyntax_future10.py", line 3
from __future__ import print_function
^
SyntaxError: from __future__ imports must occur at the beginning of the file
dpkg: error processing package libpython3.11-testsuite (--configure):
 installed libpython3.11-testsuite package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of python3.11-full:
 python3.11-full depends on libpython3.11-testsuite; however:
  Package libpython3.11-testsuite is not configured yet.

dpkg: error processing package python3.11-full (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libpython3.11-testsuite
 python3.11-full
Error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not 
activate remote peer: activation request failed: unit is masked.
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up libpython3.11-testsuite (3.11.6-1) ...
  File "/usr/lib/python3.11/test/test_future_stmt/badsyntax_future10.py", line 3
from __future__ import print_function
^
SyntaxError: from __future__ imports must occur at the beginning of the file
dpkg: error processing package libpython3.11-testsuite (--configure):
 installed libpython3.11-testsuite package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of python3.11-full:
 python3.11-full depends on libpython3.11-testsuite; however:
  Package libpython3.11-testsuite is not configured yet.

dpkg: error processing package python3.11-full (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libpython3.11-testsuite
 python3.11-full
 


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

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

Versions of packages libpython3.11-testsuite depends on:
ii  net-tools   2.10-0.1
ii  python3.11  3.11.6-1

libpython3.11-testsuite recommends no packages.

Versions of packages libpython3.11-testsuite suggests:
ii  python3-gdbm  3.11.5-1
ii  python3-tk3.11.5-1

-- no debconf information

Bug#1004256: FW: Your MetaMask account will soon be suspended!

[Renee Brutcher]

Sent via the Samsung Galaxy Note9, an AT 5G Evolution capable smartphone



 Original message 
From: MetaMask 
Date: 10/4/23 04:31 (GMT-06:00)
To: Recipients 
Subject: Your MetaMask account will soon be suspended!

c

What consequences will result from my failure to complete the update?

If the update is not completed by October 06, the use of your assets will be 
suspended.

Wallets that have not completed the update will be unable to use our service 
once it has been implemented.

[https://storage.googleapis.com/topolio41172/plugin-assets/6320/41172/Buy_crypto_hero.jpg]
Complete the Update 

Thank you for choosing us as your preferred cryptocurrency wallet. If you have 
any questions or concerns,

our support team is available 24/7 to assist you.

Bug#1052937: False-positive for wofi-pass

[Martin Dosch]

Dear Lucas,

wofi-pass is marked for autoremoval due to this bug report but I suspect 
it to be a false-positive as wofi-pass does not depend on any emacs 
stuff and it also builds successful (see attached buildlog).


Best regards,
Martin
Format: 1.0
Source: wofi-pass
Binary: wofi-pass
Architecture: all
Version: 0.0~git20230512.4468bbe-1
Checksums-Md5:
 8904dc51b2b857a6bc704954ef781e16 4636 
wofi-pass_0.0~git20230512.4468bbe-1_all.deb
Checksums-Sha1:
 dde74911b027afb6c20a118e0b7a9d5a172f2c19 4636 
wofi-pass_0.0~git20230512.4468bbe-1_all.deb
Checksums-Sha256:
 6208618d857ede797ffc4e529f94969662c0190271055a3929f3ad9825f7c3da 4636 
wofi-pass_0.0~git20230512.4468bbe-1_all.deb
Build-Origin: Debian
Build-Architecture: amd64
Build-Date: Wed, 04 Oct 2023 17:46:14 +
Build-Path: /build/wofi-pass-OcDOGy/wofi-pass-0.0~git20230512.4468bbe
Installed-Build-Depends:
 autoconf (= 2.71-3),
 automake (= 1:1.16.5-1.3),
 autopoint (= 0.21-13),
 autotools-dev (= 20220109.1),
 base-files (= 13),
 base-passwd (= 3.6.1),
 bash (= 5.2.15-2+b5),
 binutils (= 2.41-5),
 binutils-common (= 2.41-5),
 binutils-x86-64-linux-gnu (= 2.41-5),
 bsdextrautils (= 2.39.2-2),
 bsdutils (= 1:2.39.2-2),
 build-essential (= 12.10),
 bzip2 (= 1.0.8-5+b1),
 coreutils (= 9.1-1),
 cpp (= 4:13.2.0-1),
 cpp-12 (= 12.3.0-9),
 cpp-13 (= 13.2.0-4),
 dash (= 0.5.12-6),
 debconf (= 1.5.82),
 debhelper (= 13.11.6),
 debianutils (= 5.13),
 dh-autoreconf (= 20),
 dh-strip-nondeterminism (= 1.13.1-1),
 diffutils (= 1:3.8-4),
 dpkg (= 1.22.0),
 dpkg-dev (= 1.22.0),
 dwz (= 0.15-1),
 file (= 1:5.45-2),
 findutils (= 4.9.0-5),
 g++ (= 4:13.2.0-1),
 g++-13 (= 13.2.0-4),
 gcc (= 4:13.2.0-1),
 gcc-12 (= 12.3.0-9),
 gcc-12-base (= 12.3.0-9),
 gcc-13 (= 13.2.0-4),
 gcc-13-base (= 13.2.0-4),
 gettext (= 0.21-13+b1),
 gettext-base (= 0.21-13+b1),
 grep (= 3.11-3),
 groff-base (= 1.23.0-2),
 gzip (= 1.12-1),
 hostname (= 3.23+nmu1),
 init-system-helpers (= 1.65.2),
 intltool-debian (= 0.35.0+20060710.6),
 libacl1 (= 2.3.1-3),
 libarchive-zip-perl (= 1.68-1),
 libasan8 (= 13.2.0-4),
 libatomic1 (= 13.2.0-4),
 libattr1 (= 1:2.5.1-4),
 libaudit-common (= 1:3.1.1-1),
 libaudit1 (= 1:3.1.1-1),
 libbinutils (= 2.41-5),
 libblkid1 (= 2.39.2-2),
 libbz2-1.0 (= 1.0.8-5+b1),
 libc-bin (= 2.37-12),
 libc-dev-bin (= 2.37-12),
 libc6 (= 2.37-12),
 libc6-dev (= 2.37-12),
 libcap-ng0 (= 0.8.3-1+b3),
 libcap2 (= 1:2.66-4),
 libcc1-0 (= 13.2.0-4),
 libcom-err2 (= 1.47.0-2+b1),
 libcrypt-dev (= 1:4.4.36-2),
 libcrypt1 (= 1:4.4.36-2),
 libctf-nobfd0 (= 2.41-5),
 libctf0 (= 2.41-5),
 libdb5.3 (= 5.3.28+dfsg2-2),
 libdebconfclient0 (= 0.271),
 libdebhelper-perl (= 13.11.6),
 libdpkg-perl (= 1.22.0),
 libelf1 (= 0.189-4),
 libfile-stripnondeterminism-perl (= 1.13.1-1),
 libgcc-12-dev (= 12.3.0-9),
 libgcc-13-dev (= 13.2.0-4),
 libgcc-s1 (= 13.2.0-4),
 libgcrypt20 (= 1.10.2-3),
 libgdbm-compat4 (= 1.23-3),
 libgdbm6 (= 1.23-3),
 libgmp10 (= 2:6.3.0+dfsg-2),
 libgomp1 (= 13.2.0-4),
 libgpg-error0 (= 1.47-2),
 libgprofng0 (= 2.41-5),
 libgssapi-krb5-2 (= 1.20.1-4),
 libhwasan0 (= 13.2.0-4),
 libicu72 (= 72.1-3),
 libisl23 (= 0.26-3),
 libitm1 (= 13.2.0-4),
 libjansson4 (= 2.14-2),
 libk5crypto3 (= 1.20.1-4),
 libkeyutils1 (= 1.6.3-2),
 libkrb5-3 (= 1.20.1-4),
 libkrb5support0 (= 1.20.1-4),
 liblsan0 (= 13.2.0-4),
 liblz4-1 (= 1.9.4-1),
 liblzma5 (= 5.4.4-0.1),
 libmagic-mgc (= 1:5.45-2),
 libmagic1 (= 1:5.45-2),
 libmd0 (= 1.1.0-1),
 libmount1 (= 2.39.2-2),
 libmpc3 (= 1.3.1-1),
 libmpfr6 (= 4.2.1-1),
 libnsl-dev (= 1.3.0-2),
 libnsl2 (= 1.3.0-2),
 libpam-modules (= 1.5.2-7),
 libpam-modules-bin (= 1.5.2-7),
 libpam-runtime (= 1.5.2-7),
 libpam0g (= 1.5.2-7),
 libpcre2-8-0 (= 10.42-4),
 libperl5.36 (= 5.36.0-9),
 libpipeline1 (= 1.5.7-1),
 libquadmath0 (= 13.2.0-4),
 libseccomp2 (= 2.5.4-1+b3),
 libselinux1 (= 3.5-1),
 libsframe1 (= 2.41-5),
 libsmartcols1 (= 2.39.2-2),
 libssl3 (= 3.0.11-1),
 libstdc++-13-dev (= 13.2.0-4),
 libstdc++6 (= 13.2.0-4),
 libsub-override-perl (= 0.09-4),
 libsystemd0 (= 254.5-1),
 libtinfo6 (= 6.4+20230625-2),
 libtirpc-common (= 1.3.3+ds-1),
 libtirpc-dev (= 1.3.3+ds-1),
 libtirpc3 (= 1.3.3+ds-1),
 libtool (= 2.4.7-7),
 libtsan2 (= 13.2.0-4),
 libubsan1 (= 13.2.0-4),
 libuchardet0 (= 0.0.7-1),
 libudev1 (= 254.5-1),
 libunistring5 (= 1.1-2),
 libuuid1 (= 2.39.2-2),
 libxml2 (= 2.9.14+dfsg-1.3),
 libzstd1 (= 1.5.5+dfsg2-2),
 linux-libc-dev (= 6.5.3-1),
 login (= 1:4.13+dfsg1-2),
 m4 (= 1.4.19-4),
 make (= 4.3-4.1),
 man-db (= 2.12.0-1),
 mawk (= 1.3.4.20230808-1),
 ncurses-base (= 6.4+20230625-2),
 ncurses-bin (= 6.4+20230625-2),
 patch (= 2.7.6-7),
 perl (= 5.36.0-9),
 perl-base (= 5.36.0-9),
 perl-modules-5.36 (= 5.36.0-9),
 po-debconf (= 1.0.21+nmu1),
 rpcsvc-proto (= 1.4.3-1),
 sed (= 4.9-1),
 sensible-utils (= 0.0.20),
 sysvinit-utils (= 3.08-1),
 tar (= 1.34+dfsg-1.2),
 usr-is-merged (= 37),
 util-linux (= 2.39.2-2),
 xz-utils (= 5.4.4-0.1),
 zlib1g (= 1:1.2.13.dfsg-3)
Environment:
 DEB_BUILD_OPTIONS="parallel=8"
 LANG="de_DE.UTF-8"
 LC_ALL="C.UTF-8"
 

Bug#1053470: ld.so: ignore tunables in secure mode

[Christian Göttsche]

Package: glibc
Version: 2.37-12

In the light of the recent privilege escalation vulnerability I'd like
to suggest disabling the support for tunables in secure mode (most
notably for setuid-binaries).
This would mitigate future regressions in the handling of the
environment variable and possible vulnerabilities caused by the
interaction of particular options with security relevant applications.

The support could either be disabled at compile time[1] or at runtime
via a file existence check (either by reusing `/etc/suid-debug` or a
new one like `/etc/suid-tunables`).


[1]: 
https://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=commitdiff;h=5d1686416ab766f3dd0780ab730650c4c0f76ca9

Bug#1041451: [Sender Not Verified] Re: Bug#1041451: gmap: FTBFS on all !amd64 archs

[Thomas Wu]

Hi Andreas,

I have restored the non-SIMD binaries in the latest version 2023-10-01 of
GMAP, which includes various other improvements and bug fixes.  This
version can be downloaded from our Web server at
http://research-pub.gene.com/gmap.  Please let me know if you find any
problems with this release.

Thanks,

Tom


On Tue, Sep 19, 2023 at 11:50 AM Thomas Wu  wrote:

>
> Hi Andreas,
>
> I have decided to restore the non-SIMD binaries.  I have just written code
> to do that, and will release a new version once some large-scale test runs
> complete successfully.
>
> Thanks,
>
> Thomas Wu
>
>
>
> On Tue, Sep 19, 2023 at 8:48 AM Thomas Wu  wrote:
>
>>
>> Hi Andreas,
>>
>> The GMAP package should compile on both Intel and Apple architectures.  I
>> think we are now requiring SIMD or its equivalent Neon, though, which is
>> why we are no longer building the *.nosimd binaries.  I don't think that's
>> a problem since every modern computer supports SIMD or Neon.  Does Debian
>> require a non-SIMD target machine?  I will try to look at your bug report
>> to understand what is going on.
>>
>> Thanks,
>>
>> Thomas Wu
>>
>>
>> On Tue, Sep 19, 2023 at 7:44 AM Andreas Tille  wrote:
>>
>>> **Warning** The sender address (Andreas Tille ) can not be verified,
>>> sender email address could be spoofed. Please take care to proceed.
>>> Control: tags -1 upstream
>>> Control: forwarded -1 Thomas Wu , Colin K. Watanabe <
>>> c...@gene.com>
>>>
>>>
>>> Hi Thomas and Colin,
>>>
>>> the Debian packaged gmap fails to build since version 2023-06-01 for all
>>> release architectures besides amd64.  You can read about this bug on our
>>> bug tracker[1].  I think the analysis from Étienne below is a sensible
>>> explanation for the issue.
>>>
>>> It would be really helpful if you could clarify why you disabled SIMD?
>>> Does this mean you suggest we should provide gmap for amd64 only?
>>>
>>> Kind regards
>>> Andreas.
>>>
>>>
>>> [1] https://bugs.debian.org/1041451
>>>
>>> Am Tue, Aug 15, 2023 at 12:42:09PM +0200 schrieb Étienne Mollier:
>>> > Hi,
>>> >
>>> > The relevant part of the error message shows that the generic
>>> > fully scalar gmap.nosimd executable is never built for any cpu
>>> > architecture:
>>> >
>>> >   Note: /<>/build/src/gmap.avx2 does not exist.  For
>>> faster speed, may want to compile package on an AVX2 machine
>>> >   Note: /<>/build/src/gmap.sse42 does not exist.  For
>>> faster speed, may want to compile package on an SSE4.2 machine
>>> >   Note: /<>/build/src/gmap.sse41 does not exist.  For
>>> faster speed, may want to compile package on an SSE4.1 machine
>>> >   Note: /<>/build/src/gmap.ssse3 does not exist.  For
>>> faster speed, may want to compile package on an SSSE3 machine
>>> >   Note: /<>/build/src/gmap.sse2 does not exist.  For
>>> faster speed, may want to compile package on an SSE2 machine
>>> >   Note: /<>/build/src/gmap.nosimd does not exist.
>>> For faster speed, may want to compile package on an non-SIMD machine
>>> >   Error: appropriate GMAP version not found
>>> >
>>> > Looking into src/Makefile.am, indeed they seem disabled upstream
>>> > for the current gmap versions:
>>> >
>>> >   # intersect-uint2.c requires SIMD
>>> >   #bin_PROGRAMS += gmap.nosimd
>>> >   #bin_PROGRAMS += gmapl.nosimd
>>> >   #bin_PROGRAMS += gsnap.nosimd
>>> >   #bin_PROGRAMS += gsnapl.nosimd
>>> >
>>> > My quick attempts to bring the necessary support in the
>>> > aforementioned intersect-uint2.c file were not very fruitful so
>>> > far.  Something in there looks to prevent use of simde.
>>> >
>>> > Anyways, in hope this helps further investigations,
>>> > --
>>> >   .''`.  Étienne Mollier 
>>> >  : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
>>> >  `. `'   sent from /dev/pts/4, please excuse my verbosity
>>> >`-
>>>
>>>
>>>
>>> > ___
>>> > Debian-med-packaging mailing list
>>> > debian-med-packag...@alioth-lists.debian.net
>>> >
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>>>
>>>
>>> --
>>> http://fam-tille.de
>>>
>>>

Bug#1053469: libx11 FTBFS: dh_quilt_unpatch: error: quilt --quiltrc /dev/null pop -a || test $? = 1 returned exit code 1

[Adrian Bunk]

Source: libx11
Version: 2:1.8.7-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=libx11=2%3A1.8.7-1

...
 fakeroot debian/rules clean
dh clean --with quilt --builddirectory=build/
   dh_auto_clean -O--builddirectory=build/
   dh_autoreconf_clean -O--builddirectory=build/
   dh_quilt_unpatch -O--builddirectory=build/
No patch removed
dh_quilt_unpatch: error: quilt --quiltrc /dev/null pop -a || test $? = 1 
returned exit code 1
make: *** [debian/rules:4: clean] Error 25

Bug#1026277: RFS: quadrilateralcowboy/1~20230127-1 [ITP] -- first-person cyberpunk adventure game

[James Addison]

Package: sponsorship-requests
Followup-For: Bug #1026277
X-Debbugs-Cc: package-sponsorship-reque...@lists.debian.org

Hi folks,

I'm looking for sponsors for my package 'quadrilateralcowboy' - the source
package is available on Salsa[1] and for inspection on mentors.debian.net[2].

The package is a first-person game that involves elements of programming, and
the game data for it is available using Debian's game-data-packager system.

(there was an RFS[3] open for this, but it's been archived and I can't seem to
unarchive that.  I thought reporting against the ITP might be preferable to a
duplicate RFS)

Thank you,
James

[1] - https://salsa.debian.org/jayaddison/quadrilateralcowboy/

[2] - https://mentors.debian.net/package/quadrilateralcowboy/

[3] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029409

Bug#1053468: mrpt FTBFS with suitesparse 7.2.0

[Adrian Bunk]

Source: mrpt
Version: 1:2.10.1+ds-2
Severity: serious
Tags: ftbfs patch
Forwarded: 
https://github.com/MRPT/mrpt/commit/afda967b07745c16d8c4a2a649a2709b0f8183e4

https://buildd.debian.org/status/logs.php?pkg=mrpt=1%3A2.10.1%2Bds-3

...
In file included from /usr/include/c++/13/bits/ios_base.h:41,
 from /usr/include/c++/13/ios:44,
 from /usr/include/c++/13/istream:40,
 from /usr/include/c++/13/sstream:40,
 from /usr/include/c++/13/complex:45,
 from /usr/include/suitesparse/cs.h:31,
 from 
/<>/libs/math/include/mrpt/math/CSparseMatrix.h:29,
 from /<>/libs/math/src/CSparseMatrix.cpp:12:
/usr/include/c++/13/bits/locale_classes.h:77:5: error: template with C linkage
   77 | template
  | ^~~~
/<>/libs/math/include/mrpt/math/CSparseMatrix.h:22:1: note: 
‘extern "C"’ linkage started here
   22 | extern "C"
  | ^~
...

Bug#1051910: mirror submission for ossmirror.mycloud.services

[Adam D. Barratt]

Hi,

I believe you should now have had a response.

Regards,

Adam


On Wed, 2023-10-04 at 08:29 +0800, OSSMirror@OnboardCloud wrote:
> Hi Adam,
>  
> Thanks for sharing. It seems that we have crossed the 50 mark and our
> mirror is listed!
>  
> Do you know roughly how long does it usually take for the mirrors@
> folks to check/reply amidst their busy schedule?
>  
> Cheers,
>  
> -Original Message-
> From: Adam D. Barratt 
> Date: Friday, 29 September 2023 at 12:11 AM
> To: OSSMirror@OnboardCloud , 
> 1051...@bugs.debian.org <1051...@bugs.debian.org>
> Subject: Re: Bug#1051910: mirror submission for
> ossmirror.mycloud.services
> 
> Hi,
>  
> mirrors@ is the correct address. I suspect people are simply busy.
> (Well, I know people are.)
>  
> Regards,
>  
> Adam
>  
> On Thu, 2023-09-28 at 13:10 +0800, OSSMirror@OnboardCloud wrote:
> > Hi Adam,
> >  
> > Thanks for sharing. Looks like we are almost near the ½ way mark to
> > reaching 50 points today.
> >  
> > Separately, we have written in to mirr...@debian.org on 14/9 to ask
> > about hosting official “.country.” mirrors but did not receive any
> > reply till date. Do you know if we have written to the correct
> > address or are you able to refer us to the correct party to
> > discuss/review this?
> >  
> > Best regards,
> >  
> > -Original Message-
> > From: Adam D. Barratt 
> > Date: Tuesday, 26 September 2023 at 1:54 AM
> > To: OSSMirror@OnboardCloud 
> > Cc: 1051...@bugs.debian.org <1051...@bugs.debian.org>
> > Subject: Re: Bug#1051910: mirror submission for
> > ossmirror.mycloud.services
> >
> > Hi,
> >  
> > The published list is generated by an automated process that checks
> > on
> > the status of the mirror in recent days. You can see the current
> > status
> > of your mirror at
> > 
> https://mirror-master.debian.org/status/mirror-info/ossmirror.mycloud.services.html
> >  
> > The score needs to reach at least 50 currently before the
> automation
> > will consider including it.
> >  
> > Regards,
> >  
> > Adam
> >  
> > On Mon, 2023-09-25 at 09:52 +0800, OSSMirror@OnboardCloud wrote:
> > > Hi Adam,
> > >  
> > > We were looking at the mirror listing and our mirror does not
> seem
> > to
> > > have been listed yet.
> > >  
> > > https://www.debian.org/mirror/list-full#SG
> > >  
> > >  
> > > May I enquire do you know roughly how long does it take for the
> > > mirror to be listed?
> > >  
> > > Best regards,
> > >  
> > > -Original Message-
> > > From: OSSMirror@OnboardCloud 
> > > Date: Sunday, 24 September 2023 at 3:31 AM
> > > To: Adam D. Barratt 
> > > Cc: 1051...@bugs.debian.org <1051...@bugs.debian.org>
> > > Subject: Re: Bug#1051910: mirror submission for
> > > ossmirror.mycloud.services
> > >
> > > Thanks Adam for the clarification and kind assistance!
> > >  
> > > On 24 Sep 2023, at 2:56 AM, Adam D. Barratt <
> > a...@adam-barratt.org.uk
> > > > wrote:
> > >  
> > > On Sun, 2023-09-24 at 01:57 +0800, OSSMirror@OnboardCloud wrote:
> > > > Hi Adam,
> > > >
> > > > Thanks for the reply. Could you elaborate further what do you
> > mean
> > > as
> > > > the /debian/ works:
> > > >
> > > > http://ossmirror.mycloud.services/debian/
> > > >
> > >  
> > > Ah, right - I was mislead by the index of
> > > http://ossmirror.mycloud.services implying that only /os/
> existed,
> > > and
> > > didn't check for an alias.
> > >  
> > > Regards,
> > >  
> > > Adam
> > >  
> > >  
> > >  
> >  
> >  
> >  
> >  
>  
>  
>  
>  

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Holger Wansing]

Hi,

Am 4. Oktober 2023 17:05:16 MESZ schrieb Laura Arjona Reina 
:
>Hello all
>Sorry for jumping into the thread withour having reading all of it, but the 
>changes to the website cron jobs to build the trixie release notes (MR 13) 
>have been integrated in the codebase (see 
>https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes
> ) and we're getting an error in the build process (hence the recent "ddp 
>build failed" message in the debian-doc list).
>
>I think there are two issues:

Thanks for the quick merge.

That being done now, I need to push the 
'Migrate r-n to restructuredText' changings to master.

Please be patient.

Holger


>A)
>
>7release-notes script now calls for trixie 
>(https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes#L208
> ):
>
>make install DESTDIR=$crondir/tmp >> $notesdir/build.log 2>&1
>
>while for the other releases the call is 
>(https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes#L242
> )
>
>
>make -C $notesdir/release-notes publish \
>PUBLISHTARBALL=yes PUBLISHDIR=$webtopdir/www/releases/$release >> 
> $notesdir/build.log 2>&1
>
>I believe that the Makefile of release-notes understands "publish" instead of 
>"install" but I'm not sure about how should we update L208 of the 
>7release-notes script.
>
>B)
>On the other hand, if I look at the master branch of the release-notes repo, I 
>see that it's still written in docbook, not restructuredtext.
>I guess the files in the new format are still in 
>https://salsa.debian.org/holgerw/release-notes and should be merged into the 
>original release-notes repo first so we actually build them and not the old 
>docbook ones, but not 100% sure about this point because I couldn't follow all 
>the related threads with all the attention they needed (apologies!).
>
>
>Kind regards,
>
>El 4/10/23 a las 12:23, Holger Wansing escribió:
>> Hi,
>> 
>> Thomas Lange  wrote (Wed, 4 Oct 2023 10:29:35 +0200):
>>> Hi Holger,
>>> 
>>> I really like the idea no to produce release notes for each
>>> architecture but only one. Moving to sphinx is also nice.
>>> 
>>> Sorry, if I broke your MR, by adding code that checks if something
>>> changed in the git repo. I think I can easily add this to your code
>>> later. So maybe we copy your version of 7release-notes and after that
>>> I add my code.
>> 
>> That would be really great!
>> 
>>> Do you know how long the build process takes using sphinx? I've added
>>> the code, because the build took around 90 minutes using docbook.
>> 
>> I expect the build time to be reduced dramatically (rughly ~ 1/9, due to
>> building only one arch instead of nine), but I have no definite values,
>> expecially not for the run on www-master.
>> 
>>> Any other things I should keep an eye on?
>> 
>> None at the moment.
>> 
>> Thanks for considering this MR.
>> It would give us the possibility to move r-n to sphinx, which would be a
>> great deal!
>> 
>> 
>> Holger
>> 
>> 
>

-- 
Sent from /e/ OS on Fairphone3

Bug#1053467: network-manager-openconnect-gnome: No option to specify UserAgent header in GUI

[Florian Echtler]

Package: network-manager-openconnect-gnome
Version: 1.2.6-4
Severity: wishlist
Tags: patch
X-Debbugs-Cc: f...@butterbrot.org

Dear Maintainer,

our Cisco VPN apparently got upgraded a few days ago and now requires a
specific UserAgent
header to still allow clients to connect, e.g. using the string "AnyConnect
Windows 4.10.04071".

There is an upstream patch that fixes this issue, adding a UI field for the
user agent string:

https://gitlab.gnome.org/GNOME/NetworkManager-
openconnect/-/commit/b5e154c06fd9013a925f85c2aa38d88e4ee53db0

I've verified that this patch works on 1.2.6; I'd suggest to add this into at
least buster-backports
and bullseye-backports, and perhaps also into 1.2.8 on bookworm, if applicable
(AFAICT this patch has
not yet been merged upstream).

Thanks and best, Florian


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

Kernel: Linux 5.15.0-67-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager-openconnect-gnome depends on:
ii  libc62.35-0ubuntu3.4
ii  libgcr-base-3-1  3.40.0-4
ii  libgcr-ui-3-13.40.0-4
ii  libglib2.0-0 2.72.4-0ubuntu2.2
ii  libgtk-3-0   3.24.33-1ubuntu2
ii  libnm0   1.36.6-0ubuntu2
ii  libopenconnect5  8.20-1
ii  libsecret-1-00.20.5-2
ii  libsoup2.4-1 2.74.2-3
ii  libwebkit2gtk-4.0-37 2.40.5-0ubuntu0.22.04.1
ii  libxml2  2.9.13+dfsg-1ubuntu0.3
ii  network-manager-openconnect  1.2.6-4

network-manager-openconnect-gnome recommends no packages.

network-manager-openconnect-gnome suggests no packages.

-- no debconf information

Bug#1040433: Interest in maintaining anki for Debian

[Christian Vargas]

Hello,

I was browsing for opportunities to help contribute to Debian and saw 
that this package requires a new maintainer. While I have never solely 
been responsible for maintaining a project, I saw that anki was one of 
them and happened to have made extensive use of this software during my 
time as an undergraduate student. I would be very interested in 
maintaining this package and would love to do my best effort in doing 
so. I mostly work with Python professionally for my current job, but 
have recently taken it upon myself to learn and begin projects in rust 
as well. Please don't hesitate to reach out to me and I would love to 
discuss further.

Regards,

Christian

Bug#980041: paps: please update to 0.7.1

[Michael Prokop]

* Stephen Kitt [Wed Jan 13, 2021 at 11:50:23AM +0100]:

> paps is now maintained on https://github.com/dov/paps, and there have
> been releases since 0.6.8. In particular, current versions produce PS
> files with the original text content, instead of only rendered
> glyphs.

Friendly maintainer ping, paps feels like being unmaintained within Debian?

| % rmadison paps
| paps   | 0.6.8-7.1 | oldoldstable   | source, amd64, arm64, armel, 
armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
| paps   | 0.6.8-7.1 | oldstable  | source
| paps   | 0.6.8-7.1 | stable | source
| paps   | 0.6.8-7.1 | testing| source
| paps   | 0.6.8-7.1 | unstable   | source, riscv64
| paps   | 0.6.8-7.1 | unstable-debug | source
| paps   | 0.6.8-7.1+b1  | oldstable  | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x
| paps   | 0.6.8-7.1+b1  | stable | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x
| paps   | 0.6.8-7.1+b1  | testing| amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, s390x
| paps   | 0.6.8-7.1+b1  | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, s390x

regards
-mika-


signature.asc
Description: PGP signature

Bug#1053466: unicorn: Fails to build binary package again after successful build

[Gioele Barabucci]

Package: src:unicorn
Version: 6.1.0-2
Severity: minor
Tags: ftbfs patch
User: debian...@lists.debian.org
Usertags: qa-doublebuild

Dear maintainers,

due to files modified in d/rules, the `unicorn` package fails to build a 
binary-only package after a successful build.


```
dpkg-source: info: local changes detected, the modified files are:
 source_dir/GIT-VERSION-FILE
 source_dir/ext/unicorn_http/unicorn_http.c
 source_dir/lib/unicorn/version.rb
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/unicorn_6.1.0-2+salsaci+20231004+2.diff.Ltit1F

```

A patch to fix this issue is included in the following MR:
https://salsa.debian.org/ruby-team/unicorn/-/merge_requests/2

--
Gioele Barabucci

Bug#1053465: unicorn: Unnecessary Build-Depends on quilt

[Gioele Barabucci]

Package: src:unicorn
Version: 6.1.0-2
Tags: patch

Dear maintainers,

the `unicorn` package does not need to Build-Depends on `quilt`. 
`dpkg-source` built-in support for quilt patches (already integrated in 
the standard `dh` pipeline) is enough.


A patch to fix this issue is included in the following MR:
https://salsa.debian.org/ruby-team/unicorn/-/merge_requests/2

--
Gioele Barabucci

Bug#1053464: Dak: make-changelog always change timestamp for directories

[Christian Marillat]

Package: ftp.debian.org
Severity: normal
Usertags: dak

dak make-changelog -e -a localhost

$ ls -l /srv/dak/changelogs/main/y/ 
total 12
drwxr-sr-x 2 dak ftpmaster 4096 Oct  4 17:14 youtube-dl-dmo
drwxr-sr-x 2 dak ftpmaster 4096 Oct  4 17:14 yt-dlp-dmo
drwxr-sr-x 2 dak ftpmaster 4096 Oct  4 17:14 ytdl-gui-dmo

Christian

Bug#1053463: quilt: quilt functions corrupt patches if awk is not gawk

[Sven Joachim]

Package: quilt
Version: 0.67+really0.67-1
Severity: important
Tags: fixed-upstream patch

The /usr/share/quilt/scripts/patchfns script contains a gawkism and does
not work correctly with either mawk or original-awk.  In both cases
"quilt refresh" corrupts existing patches, but the symptoms are quite
different:

- With awk=original-awk the refreshed patch is appended after the
  original one instead of replacing it, and applying the refreshed patch
  later fails.

- With awk=mawk there is a complaint from mawk:

  ,
  | awk: line 21: regular expression compile failed (syntax error ^* or ^+)
  | ^+++[ \t][^ \t]
  `

  This time there is no duplication of the patch, but the complete patch
  header is removed, causing information loss. :-(

Fortunately the problem had already been reported upstream and fixed in
commit ce9c68abb7c ("patchfns: Compatibility fix for BSD awk"), I have
attached the patch for your convenience and already tested it
successfully with both mawk and original-awk. :-)


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

From ce9c68abb7cee0b4fb0d5a7ff7048d0ab3b726f8 Mon Sep 17 00:00:00 2001
From: Jean Delvare 
Date: Thu, 23 Jun 2022 14:36:58 +0200
Subject: [PATCH 1/1] patchfns: Compatibility fix for BSD awk

"+" needs to be quoted to be considered as a literal "+" by BSD awk.

Without this fix, patch_header() fails to find the beginning of the
changes and treats the whole patch as a header, subsequently causing
"quilt refresh" to append the refreshed patch after the original one
instead of replacing it.

Bug reported and fix suggested by Dominic Evans.

Signed-off-by: Jean Delvare 
Fixes: 1d94980dbdd4 ("Tighten the patch format parsing")
---
 quilt/scripts/patchfns.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/quilt/scripts/patchfns.in b/quilt/scripts/patchfns.in
index 75cee52..c2d5f9d 100644
--- a/quilt/scripts/patchfns.in
+++ b/quilt/scripts/patchfns.in
@@ -848,7 +848,7 @@ patch_header()
 		MAYBE_CONTEXT=0
 	}
 	MAYBE_UNIFIED {
-		if (/^+++[ \t][^ \t]/)
+		if (/^\+\+\+[ \t][^ \t]/)
 			exit
 		print eaten
 		MAYBE_UNIFIED=0
@@ -881,7 +881,7 @@ patch_body()
 		MAYBE_CONTEXT=0
 	}
 	MAYBE_UNIFIED {
-		if (/^+++[ \t][^ \t]/) {
+		if (/^\+\+\+[ \t][^ \t]/) {
 			print eaten
 			body=1
 		}
--
2.42.0

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Laura Arjona Reina]

Hello all
Sorry for jumping into the thread withour having reading all of it, but 
the changes to the website cron jobs to build the trixie release notes 
(MR 13) have been integrated in the codebase (see 
https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes 
) and we're getting an error in the build process (hence the recent "ddp 
build failed" message in the debian-doc list).


I think there are two issues:

A)

7release-notes script now calls for trixie 
(https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes#L208 
):


make install DESTDIR=$crondir/tmp >> $notesdir/build.log 2>&1

while for the other releases the call is 
(https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7release-notes#L242 
)



make -C $notesdir/release-notes publish \
PUBLISHTARBALL=yes PUBLISHDIR=$webtopdir/www/releases/$release 
>> $notesdir/build.log 2>&1


I believe that the Makefile of release-notes understands "publish" 
instead of "install" but I'm not sure about how should we update L208 of 
the 7release-notes script.


B)
On the other hand, if I look at the master branch of the release-notes 
repo, I see that it's still written in docbook, not restructuredtext.
I guess the files in the new format are still in 
https://salsa.debian.org/holgerw/release-notes and should be merged into 
the original release-notes repo first so we actually build them and not 
the old docbook ones, but not 100% sure about this point because I 
couldn't follow all the related threads with all the attention they 
needed (apologies!).



Kind regards,

El 4/10/23 a las 12:23, Holger Wansing escribió:

Hi,

Thomas Lange  wrote (Wed, 4 Oct 2023 10:29:35 +0200):

Hi Holger,

I really like the idea no to produce release notes for each
architecture but only one. Moving to sphinx is also nice.

Sorry, if I broke your MR, by adding code that checks if something
changed in the git repo. I think I can easily add this to your code
later. So maybe we copy your version of 7release-notes and after that
I add my code.


That would be really great!


Do you know how long the build process takes using sphinx? I've added
the code, because the build took around 90 minutes using docbook.


I expect the build time to be reduced dramatically (rughly ~ 1/9, due to
building only one arch instead of nine), but I have no definite values,
expecially not for the run on www-master.


Any other things I should keep an eye on?


None at the moment.

Thanks for considering this MR.
It would give us the possibility to move r-n to sphinx, which would be a
great deal!


Holger




--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#1052614: RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins

[Drew Parsons]

Control: affects 1052614 - src:fenics-basix

On 2023-09-26 01:45, Drew Parsons wrote:

On 2023-09-26 01:10, Emmanuel Arias wrote:

Control: retitle -1 ITP: python-skbuild-core -- next generation Python
CMake adaptor and Python API for plugins

Control: owner -1 Emmanuel Arias 


I've seen it before. I will work on it and maintain it under the DPT
umbrella.


Note that basix (0.7) now has alternative build methods.  Toplevel 
pyproject.toml uses the new python-skbuild-core. But the alternative 
method builds the cpp and python subdirs separately, which is the method 
previously used by the package.  This old method still works, so in that 
sense basix is not blocked now by python-skbuild-core.


In other words, there's no urgency in this ITP, it's not holding up 
basix upgrades the way I first thought.


Drew

Bug#1053444: Quilt and exit codes

[Sune Stolborg Vuorela]

So.

It looks like in version .66, it was the situation
Done something succesfully 0
Most errors returned 1
Nothing to do returned 2

In version .67 it is kind of the same, except "lack of series file" is now put 
in "error" category, not "nothing to do".

The debhelper quilt addon was wrongfully changed to to succeed with error code 
0 or 1 in 
https://salsa.debian.org/debian/quilt/-/commit/
765d2587ee912cb909d275af62d019b2e7fb0dfc

That change should be reverted.


Instead, quilt patch/unpatch should only be run if series file exists.

Alternatively, the upstream 
http://git.savannah.nongnu.org/cgit/quilt.git/commit/?
id=8b39a960afcf45cd4f5804ae62b6b0656bdb191d
sholud be reverted

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#1053462: debian-security-support: merge .ended and .limited files together

[Santiago Ruano Rincón]

Source: debian-security-support
Severity: normal

El 27/09/23 a las 09:25, Raphael Hertzog escribió:
> Hi,
> 
> On Tue, 26 Sep 2023, Santiago Ruano Rincón wrote:
> > > > Agreed, a split makes sense, it causes marginal additional overhead and 
> > > > makes
> > > > the whole setup more explicit.
> > > 
> > > cloning this bug once more so we don't forget about this.
> > 
> > (I think the moreinfo tag comes from the original bug)
> > 
> > I hope this MR correctly splits the limited support file:
> > https://salsa.debian.org/debian/debian-security-support/-/merge_requests/17
> 
> As I commented on the MR, I think it would be a good move to merge "ended"
> and "limited" files together. This will require more code changes but
> gives a clearer overview of the restrictions affecting a given release.
> 
> We could have a single file per release with 3 fields:
> 
> * package (or package regexp)
> * supported (true/false), trues implies limited support, false means not 
> supported
> * comment (should explain the limitation if supported == true)
> 
> We could keep an unversioned file (for unstable?) that would serve as
> template when we have to create a new release.

Since #975301 has been closed now, I think this should be discussed in a
new bug report.

I like the above suggestion. Just wondering why don't keep the "latest
version with support" and "Date when support ended or will end" fields
currently found in "ended" files.


signature.asc
Description: PGP signature

Bug#1052041: RM: rust-sequoia-sq [mips64el ppc64el s390x] -- RoM; build-depends on rust-sequoia-net which is NBS on those arches

[Jeremy Bícha]

Control: tags +moreinfo

I'm adding the moreinfo tag for the same reason as

https://bugs.debian.org/1053135

Thank you,
Jeremy Bícha

Bug#1052857: hackrf: FTBFS: unsatisfiable build-dependencies: libstdc++-arm-none-eabi-dev (= 15:12.2.rel1-1+23), gcc-arm-none-eabi (= 15:12.2.rel1-1)

[Bastian Germann]

Looks like #1050327 is causing this.

Bug#1020217: S3-backed snapshot implementation on AWS?

[Noah Meyerhans]

On Sun, Sep 24, 2023 at 04:09:31PM -0700, Noah Meyerhans wrote:
> > > Could we use the Debian AWS account to host that service?
> > 
> > I would assume that a service like snapshot would be within the scope
> > for our AWS usage.  Noah?
> 
> It makes sense and I will look into it.  Let's not start anything until
> we hear definitive confirmation.

OK, let's do it.

noah

Bug#1053461: bookworm-pu: package openrefine/3.6.2-2+deb12u1

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org

[ Reason ]

Fixing CVE-2023-41886 and CVE-2023-41887.

OpenRefine is a powerful free, open source tool for working with messy
data. Prior to this version, a remote code execution vulnerability
allows any unauthenticated user to execute code on the server.

[ Tests ]

I have verified that the new test case works as expected.

[ Risks ]

Low, leaf package, all tests work as expected.

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

[ Other info ]

Please note that I have previously uploaded another bookworm-pu,
#1051429, to fix CVE-2023-37476. This update addresses the new CVE
mentioned in this bug report. CVE-2023-37476 has been fixed with
3.6.2-2+deb12u1 already.
diff --git a/debian/changelog b/debian/changelog
index 16033d8..37acbbf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+openrefine (3.6.2-2+deb12u2) bookworm; urgency=medium
+
+  * Fix CVE-2023-41887 and CVE-2023-41886:
+OpenRefine is a powerful free, open source tool for working with messy
+data. Prior to this version, a remote code execution vulnerability allows
+any unauthenticated user to execute code on the server.
+
+ -- Markus Koschany   Wed, 04 Oct 2023 15:02:45 +0200
+
 openrefine (3.6.2-2+deb12u1) bookworm; urgency=medium
 
   * Fix CVE-2023-37476:
diff --git a/debian/patches/CVE-2023-41887-and-CVE-2023-41886.patch 
b/debian/patches/CVE-2023-41887-and-CVE-2023-41886.patch
new file mode 100644
index 000..274b758
--- /dev/null
+++ b/debian/patches/CVE-2023-41887-and-CVE-2023-41886.patch
@@ -0,0 +1,183 @@
+From: Markus Koschany 
+Date: Wed, 4 Oct 2023 14:39:55 +0200
+Subject: CVE-2023-41887 and CVE-2023-41886
+
+Origin: 
https://github.com/OpenRefine/OpenRefine/commit/693fde606d4b5b78b16391c29d110389eb605511
+---
+ .../extension/database/DatabaseConfiguration.java   | 16 
+ .../database/mariadb/MariaDBConnectionManager.java  | 12 +---
+ .../database/mysql/MySQLConnectionManager.java  | 11 +--
+ .../database/pgsql/PgSQLConnectionManager.java  | 11 +--
+ .../database/sqlite/SQLiteConnectionManager.java|  9 -
+ .../database/DatabaseConfigurationTest.java | 21 +
+ 6 files changed, 48 insertions(+), 32 deletions(-)
+ create mode 100644 
extensions/database/tests/src/com/google/refine/extension/database/DatabaseConfigurationTest.java
+
+diff --git 
a/extensions/database/src/com/google/refine/extension/database/DatabaseConfiguration.java
 
b/extensions/database/src/com/google/refine/extension/database/DatabaseConfiguration.java
+index 47dad7f..3f0dd57 100644
+--- 
a/extensions/database/src/com/google/refine/extension/database/DatabaseConfiguration.java
 
b/extensions/database/src/com/google/refine/extension/database/DatabaseConfiguration.java
+@@ -29,6 +29,9 @@
+ package com.google.refine.extension.database;
+ 
+ 
++import java.net.URI;
++import java.net.URISyntaxException;
++
+ public class DatabaseConfiguration {
+ 
+ private String connectionName;
+@@ -128,4 +131,17 @@ public class DatabaseConfiguration {
+ 
+ 
+ 
++public URI toURI() {
++try {
++return new URI(
++"jdbc:" + databaseType.toLowerCase(),
++databaseHost + ((databasePort == 0) ? "" : (":" + 
databasePort)),
++"/" + databaseName,
++useSSL ? "useSSL=true" : null,
++null
++);
++} catch (URISyntaxException e) {
++throw new IllegalArgumentException(e);
++}
++}
+ }
+diff --git 
a/extensions/database/src/com/google/refine/extension/database/mariadb/MariaDBConnectionManager.java
 
b/extensions/database/src/com/google/refine/extension/database/mariadb/MariaDBConnectionManager.java
+index 4af014a..04c7dc8 100644
+--- 
a/extensions/database/src/com/google/refine/extension/database/mariadb/MariaDBConnectionManager.java
 
b/extensions/database/src/com/google/refine/extension/database/mariadb/MariaDBConnectionManager.java
+@@ -139,7 +139,7 @@ public class MariaDBConnectionManager {
+ 
+ Class.forName(type.getClassPath());
+ DriverManager.setLoginTimeout(10);
+-String dbURL = getDatabaseUrl(databaseConfiguration);
++String dbURL = databaseConfiguration.toURI().toString();
+ connection = DriverManager.getConnection(dbURL, 
databaseConfiguration.getDatabaseUser(),
+ databaseConfiguration.getDatabasePassword());
+ 
+@@ -173,14 +173,4 @@ public class MariaDBConnectionManager {
+ }
+  
+ }
+-
+-
+-   
+-private static String getDatabaseUrl(DatabaseConfiguration dbConfig) {

Bug#1053444: severity of 1053444 is grave

[Julien Cristau]

severity 1053444 grave
thanks

See e.g. 
https://buildd.debian.org/status/fetch.php?pkg=libx11=all=2%3A1.8.7-1=1696420352=0

quilt pop exits 2 if it has nothing to do
(https://sources.debian.org/src/quilt/0.67%2Breally0.67-1/quilt/pop.in/#L246),
so that should be expected and not an error for dh_quilt_unpatch.

Bug#1053460: pssh: parallel-ssh randomly crashes

[Florian Wiessner]

Package: pssh
Version: 2.3.1-4
Severity: important
Tags: newcomer

Dear Maintainer,

there is a bug in parallel-ssh which makes the program crash at random:

Traceback (most recent call last):
  File "/usr/bin/parallel-ssh", line 121, in 
do_pssh(hosts, cmdline, opts)
  File "/usr/bin/parallel-ssh", line 92, in do_pssh
statuses = manager.run()
  File "/usr/lib/python3/dist-packages/psshlib/manager.py", line 76, in run
self.update_tasks(writer)
  File "/usr/lib/python3/dist-packages/psshlib/manager.py", line 133, in 
update_tasks
self.clear_sigchld_handler()
  File "/usr/lib/python3/dist-packages/psshlib/manager.py", line 96, in 
clear_sigchld_handler
signal.signal(signal.SIGCHLD, signal.SIG_DFL)
  File "/usr/lib/python3.9/signal.py", line 47, in signal
handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
TypeError: 'int' object is not callable

The bug may cause other programs not beeing executed which is fatal in clustered
environments and can lead to all kinds of problems.

The bug seems to be fixed in testing (2.3.5). 

Please backport the patch to bullseye or upgrade the bullseye package to the
newer version.


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

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

Versions of packages pssh depends on:
ii  openssh-client   1:8.4p1-5+deb11u1
ii  python3  3.9.2-3

pssh recommends no packages.

pssh suggests no packages.

Bug#1053458: openstreetmap-carto-common: Configure step failed with FATAL: role "root" does not exist

[Nicolas Peugnet]

Package: openstreetmap-carto-common
Version: 5.7.0-1
Severity: important

Dear Maintainer,

When installing openstreetmap-carto-common package (as a dependency of
openstreetmap-carto), the configure step failed after having answered
yes to all the questions (as I remember: "do you want to download the
additionnal resources?" and "What is the name of the database? gis").

Here is the error message from apt install:

Setting up openstreetmap-carto-common (5.7.0-1) ...
INFO:root:Starting load of external data into database
Traceback (most recent call last):
  File "/usr/share/openstreetmap-carto-common/./get-external-data.py", line 
405, in 
main()
  File "/usr/share/openstreetmap-carto-common/./get-external-data.py", line 
305, in main
conn = psycopg2.connect(database=database,
   ^^^
  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 122, in 
connect
conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
   ^^^
psycopg2.OperationalError: connection to server on socket 
"/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "root" does not exist

dpkg: error processing package openstreetmap-carto-common (--configure):
 installed openstreetmap-carto-common package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of openstreetmap-carto:
 openstreetmap-carto depends on openstreetmap-carto-common; however:
  Package openstreetmap-carto-common is not configured yet.

dpkg: error processing package openstreetmap-carto (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 openstreetmap-carto-common
 openstreetmap-carto
E: Sub-process /usr/bin/dpkg returned an error code (1)


It seems indeed that by default the root user does not have access to
PostgreSQL databases, and only postgres user has superuser privileges.
So maybe this script should be run as postgres user.

I'd like to mention that I tried to install this package on an almost
completely fresh install of Debian 12. I followed this tutorial until
the end [1] before noticing that the openstreetmap-carto package was
part of Debian. But I donc think that it was the source of the issue.

[1] 
https://switch2osm.org/serving-tiles/manually-building-a-tile-server-debian-12/

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

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

Versions of packages openstreetmap-carto-common depends on:
ii  curl   7.88.1-10+deb12u1
ii  debconf [debconf-2.0]  1.5.82
ii  fonts-dejavu-core  2.37-6
pn  fonts-noto-cjk 
pn  fonts-noto-hinted  
pn  fonts-noto-unhinted
pn  fonts-unifont  
ii  gdal-bin   3.6.2+dfsg-1+b2
ii  mapnik-utils   3.1.0+ds-3+b1
ii  python33.11.2-1+b1
ii  unzip  6.0-28

openstreetmap-carto-common recommends no packages.

openstreetmap-carto-common suggests no packages.

Bug#1053459: elasticsearch-curator: curator_cli does not work against system installed python3-click

[J]

Package: elasticsearch-curator
Version: elasticsearch-curator
Severity: normal

Dear Maintainer,

curator_cli, which is provided by the elasticsearch-curator package,
seems to depend on a different version of the python "click" module than
is installed by the python3-click package. This renders curator_cli
unusable without pip installing an appropriate click version.

I expected elasticsearch-curator to provide a curator_cli which matches
the click provided by python3-click.

To reproduce on a fresh bookworm install:

# apt install elasticsearch-curator

and attempt to run curator_cli without any arguments. You should see
this traceback:

$ curator_cli
Traceback (most recent call last):
  File "/usr/bin/curator_cli", line 33, in 
sys.exit(load_entry_point('elasticsearch-curator==5.8.1', 
'console_scripts', 'curator_cli')())
 
^^
  File "/usr/bin/curator_cli", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/curator/curator_cli.py", line 2, in 

from curator.singletons import cli
  File "/usr/lib/python3/dist-packages/curator/singletons.py", line 7, in 

from curator.cli_singletons.alias import alias
  File "/usr/lib/python3/dist-packages/curator/cli_singletons/alias.py", line 
5, in 
@click.command(context_settings=get_width())
^^^
  File "/usr/lib/python3/dist-packages/curator/cli_singletons/utils.py", line 
34, in get_width
return dict(max_content_width=click.get_terminal_size()[0])
  ^^^
AttributeError: module 'click' has no attribute 'get_terminal_size'


Let me know if you need any more information, although I think this is
pretty straightforward to reproduce.

Thanks!

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

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

Versions of packages elasticsearch-curator depends on:
ii  python33.11.2-1+b1
pn  python3-elasticsearch-curator  
ii  python3-pkg-resources  66.1.1-1

elasticsearch-curator recommends no packages.

elasticsearch-curator suggests no packages.

Bug#1053457: live-build: Building live image fails when unmounting /sys: 'target is busy'

[Emanuele Rocca]

Package: live-build
Version: 1:20230502
Severity: normal

Dear Maintainer,

Building a live image with `lb build` fails towards the end with the
following error:

 P: Begin unmounting /sys...
 umount: /tmp/sid-image/chroot/sys: target is busy.
 E: An unexpected failure occurred, exiting...

The issue can be reproduced as follows:

 lb config --distribution sid --updates false --archive-areas 'main 
non-free-firmware' --bootloaders grub-efi
 echo live-task-lxde > config/package-lists/desktop.list.chroot
 lb build --debug

Bug#1006292: bullseye-pu: package plasma-discover/5.20.5-3

[Adam D. Barratt]

Hi,

On Mon, 2023-10-02 at 19:05 +0200, Patrick Franz wrote:
> Hej,
> 
> Am Montag, 2. Oktober 2023, 19:04:00 CEST schrieb Jonathan Wiltshire:
> > Ping on this? It's urgent given the point release is planned for
> > the
> > coming weekend, and we're currently unsure if the related fix is
> > safe
> > to release without this one. If there's no answer we'll have to
> > play
> > safe and hold plasma-desktop back until the next cycle as well.
> 
> Thanks for the ping. I'll try to get it done tomorrow or the day
> after.

Thanks, but it's too late to get the updated package accepted for the
11.8 point release now in any case.

The question that remains from Jonathan's mail is - is it OK to include
the plasma-desktop and knewstuff updates without plasma-discover, or
should those be held back until plasma-discover is ready, and all three
released at the same time?

Regards,

Adam

Bug#1040395: gnome-remote-desktop: Built-in RDP server fails incoming connections with "...(MIC) verification failed!"

[Timo Lindfors]

Hi,


g-r-d's built in RDP server does not work


I got the same error message when I used the wrong password by accident. 
When I started using the correct password I was able to use RDP again. 
This is with vanilla Debian 12 and gnome.


I would try with an alphanumeric password and verify that it matches the 
output of


secret-tool lookup xdg:schema org.gnome.RemoteDesktop.RdpCredentials


-Timo

Bug#1052533: llvm-17-dev: cmake config unusable due to missing files

[Gianfranco Costamagna]

control: fixed -1 1:17.0.2-1~exp1
control: close -1

On Fri, 29 Sep 2023 11:56:19 +0200 Andreas Beckmann  wrote:

Followup-For: Bug #1052533
Control: found -1 1:17.0.1-1~exp2

The omp problem is not completely fixed, yet:

-- The CXX compiler identification is GNU 13.2.0
-- The C compiler identification is GNU 13.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Performing Test HAVE_FFI_CALL
-- Performing Test HAVE_FFI_CALL - Success
-- Found FFI: /usr/lib/x86_64-linux-gnu/libffi.so
-- Could NOT find LibEdit (missing: LibEdit_INCLUDE_DIRS LibEdit_LIBRARIES)
-- Performing Test Terminfo_LINKABLE
-- Performing Test Terminfo_LINKABLE - Success
-- Found Terminfo: /usr/lib/x86_64-linux-gnu/libtinfo.so
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
-- Could NOT find zstd (missing: zstd_LIBRARY zstd_INCLUDE_DIR)
-- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.14")
-- Could NOT find CURL (missing: CURL_LIBRARY CURL_INCLUDE_DIR)
CMake Error at /usr/lib/llvm-17/lib/cmake/llvm/LLVMExports.cmake:1857 (message):
  The imported target "omp" references the file

 "/usr/lib/llvm-17/lib/libomp.so.5"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-17/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/llvm-17/cmake/LLVMConfig.cmake:369 (include)
  CMakeLists.txt:3 (find_package)


-- Configuring incomplete, errors occurred!


Andreas




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053456: O: yatex -- Yet Another TeX mode for Emacs

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: ya...@packages.debian.org
Control: affects -1 + src:yatex

Satoru KURASHIKI  intends to orphan package,
but he does not have his time.  So I do it for him acked by him.

Description: Yet Another TeX mode for Emacs
 YaTeX is an intelligent, acquisitive and integrated package which reduces
 your efforts of composing LaTeX source on Emacs.
 .
 YaTeX automates typesetting and previewing of LaTeX and enables
 completing input of LaTeX mark-up command such as `\begin{}'..`\end{}'.
 .
 This package also includes yahtml mode, the honest and bright YaTeX-compatible
 major-mode for writing HTML. If you have noticed the power of YaTeX, you can
 drive yahtml over the HTML files quickly and steadily. And vice versa, of
 course.
 .
 YaTeX also supports Demacs which runs on MS-DOS(386), Mule
 (Multi Language Enhancement to GNU Emacs), and LaTeX on DOS.
 .
 For more information, please refer to http://www.yatex.org/
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#1053455: O: emacs-window-layout -- window layout manager for emacs

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: emacs-window-lay...@packages.debian.org
Control: affects -1 + src:emacs-window-layout

Satoru KURASHIKI  intends to orphan package,
but he does not have his time.  So I do it for him acked by him.

Description: window layout manager for emacs
 This elisp library provides functions to split a frame or window
 into some windows according to a layout recipe.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#1053454: anki: Trace under Gnome3/wayland if press settings

[George Shuklin]

Package: anki
Version: 2.1.15+dfsg-3
Severity: normal
X-Debbugs-Cc: george.shuk...@gmail.com

Configuration: Gnome3/wayland (Intel GPU).

When run anki and press tools->settings, following trace is captured, and no
settings are displayed.


Anki 2.1.15 (442df9d6) Python 3.11.5 Qt 5.15.10 PyQt 5.15.9
Platform: Linux
Flags: frz=False ao=False sv=2

Caught exception:
  File "/usr/share/anki/aqt/main.py", line 882, in onPrefs
aqt.dialogs.open("Preferences", self)
  File "/usr/share/anki/aqt/__init__.py", line 82, in open
instance = creator(*args)
   ^^
  File "/usr/share/anki/aqt/preferences.py", line 25, in __init__
self.setupCollection()
  File "/usr/share/anki/aqt/preferences.py", line 80, in setupCollection
f.lrnCutoff.setValue(qc['collapseTime']/60.0)
: setValue(self, val: int): argument 1 has unexpected type
'float'


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/20 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 anki depends on:
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-flot   4.2.1+dfsg-6
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libjs-mathjax   2.7.9+dfsg-1
ii  libqt5core5a5.15.10+dfsg-3
ii  python3 3.11.4-5+b1
ii  python3-bs4 4.12.2-2
ii  python3-decorator   5.1.1-5
ii  python3-distro  1.8.0-1
ii  python3-distutils   3.11.5-1
ii  python3-jsonschema  4.10.3-2
ii  python3-markdown3.4.4-1
ii  python3-pyaudio 0.2.13-1+b1
ii  python3-pyqt5   5.15.9+dfsg-2
ii  python3-pyqt5.qtwebchannel  5.15.9+dfsg-2
ii  python3-pyqt5.qtwebengine   5.15.6-1
ii  python3-requests2.31.0+dfsg-1
ii  python3-send2trash  1.8.2-1

Versions of packages anki recommends:
ii  python3-matplotlib  3.6.3-1+b1

Versions of packages anki suggests:
pn  dvipng  
pn  lame
ii  mpv 0.36.0-1

-- no debconf information

Bug#1053453: O: emacs-calfw -- calendar framework for Emacs

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: emacs-ca...@packages.debian.org
Control: affects -1 + src:emacs-calfw

Satoru KURASHIKI  intends to orphan package,
but he does not have his time.  So I do it for him acked by him.

Description: calendar framework for Emacs
 This program displays a calendar view in the Emacs buffer,
 which also work with org-agenda, google calendar, and ical.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#1053452: The packaged plugin "keyboard_shortcuts" does not work with roundcube v1.6.1

[Dmitry Katsubo]

Package: roundcube-plugins-extra
Version: 1.4.10+1-4

The plugin "keyboard_shortcuts" should be either fixed or replaced with another 
plugin.

Error log:

=== cut ===
[03-Oct-2023 17:23:13 UTC] PHP Warning:  Undefined property: rcmail::$imap in 
/usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php on line 
104
[03-Oct-2023 17:23:13 UTC] PHP Fatal error:  Uncaught Error: Call to undefined 
method rcmail::imap_connect() in 
/usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php:105
Stack trace:
#0 /usr/share/roundcube/program/lib/Roundcube/rcube_plugin_api.php(518): 
keyboard_shortcuts->html_output()
#1 /usr/share/roundcube/program/include/rcmail_output_html.php(1456): 
rcube_plugin_api->exec_hook()
#2 [internal function]: rcmail_output_html->xml_command()
#3 /usr/share/roundcube/program/include/rcmail_output_html.php(1322): 
preg_replace_callback()
#4 /usr/share/roundcube/program/include/rcmail_output_html.php(825): 
rcmail_output_html->parse_xml()
#5 /usr/share/roundcube/program/include/rcmail_output_html.php(654): 
rcmail_output_html->parse()
#6 /usr/share/roundcube/program/include/rcmail.php(296): 
rcmail_output_html->send()
#7 /usr/share/roundcube/index.php(278): rcmail->action_handler()
#8 {main}
  thrown in 
/usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php on line 
105

[04-Oct-2023 10:19:41 UTC] PHP Warning:  Undefined property: rcmail::$imap in 
/usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php on line 
104
[04-Oct-2023 10:19:41 UTC] PHP Warning:  Undefined property: rcmail::$imap in 
/usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php on line 
107

[04-Oct-2023 10:19:41 UTC] PHP Fatal error:  Uncaught Error: Call to a member 
function get_capability() on null in 
/usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php:107
Stack trace:
#0 /usr/share/roundcube/program/lib/Roundcube/rcube_plugin_api.php(518): 
keyboard_shortcuts->html_output()
#1 /usr/share/roundcube/program/include/rcmail_output_html.php(1456): 
rcube_plugin_api->exec_hook()
#2 [internal function]: rcmail_output_html->xml_command()
#3 /usr/share/roundcube/program/include/rcmail_output_html.php(1322): 
preg_replace_callback()
#4 /usr/share/roundcube/program/include/rcmail_output_html.php(825): 
rcmail_output_html->parse_xml()
#5 /usr/share/roundcube/program/include/rcmail_output_html.php(654): 
rcmail_output_html->parse()
#6 /usr/share/roundcube/program/include/rcmail.php(296): 
rcmail_output_html->send()
#7 /usr/share/roundcube/index.php(278): rcmail->action_handler()
#8 {main}
  thrown in 
/usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php on line 
107
=== cut ===

The following patch solves the critical issues:

=== cut ===
--- /usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php.orig 
   2023-10-04 12:19:19.182581433 +0200
+++ /usr/share/roundcube/plugins/keyboard_shortcuts/keyboard_shortcuts.php 
2023-10-04 12:31:59.561591110 +0200
@@ -101,12 +101,12 @@
 $c .= "  ";
 $c .= "";

-if(!is_object($rcmail->imap)){
-  $rcmail->imap_connect();
+if(!is_object($rcmail->storage)){
+  $rcmail->storage_connect();
 }
-$threading_supported = 
$rcmail->imap->get_capability('thread=references')
-  || $rcmail->imap->get_capability('thread=orderedsubject')
-  || $rcmail->imap->get_capability('thread=refs');
+$threading_supported = 
$rcmail->storage->get_capability('thread=references')
+  || $rcmail->storage->get_capability('thread=orderedsubject')
+  || $rcmail->storage->get_capability('thread=refs');

 if ($threading_supported) {
   $c .= "".$this->gettext("threads")."";
=== cut ===


-- 
With best regards,
Dmitry

Bug#1053451: O: e2wm -- simple window manager for emacs

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: e...@packages.debian.org
Control: affects -1 + src:e2wm

Satoru KURASHIKI  intends to orphan package,
but he does not have his time.  So I do it for him acked by him.

Description: simple window manager for emacs
 This is an implementation of introducing window management to Emacs.
  * Management of list of editable buffers
  * Assignment of windows for pop-up buffers
  * Switching window layout like the perspective in eclipse
  * Plug-in extension
 .
 The current implementation has following perspectives:
  * code : main coding layout
  * two : side by side layout
  * doc : reading documentation layout
  * dashboard : showing plug-ins like dashboard in Mac OSX
  * array : selecting buffers like expose in Mac OSX
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#1051150: RFS: blender-doc/3.6-1 [ITP] -- Blender Manual by the Blender Foundation

[Hugh McMaster]

Hi Jonathan,

Thanks for your work on this package. Just two more things to do.

On Tue, 3 Oct 2023 at 05:53, Jonathan Rubenstein wrote:
>
> Hey, I've implemented the requested changes, again with some
> questions/exceptions.
>
> > * Not all files in tools*/* are explicitly marked Apache-2.0, but
> > given most are, I think it's okay to assume that. In any case, the
> > attributable copyright is the same as for the main package.
>
> Not sure if this is asking for any particular action or just a comment
> on the situation.

That was just a comment.

1. Add a debian/README.source file and add a comment that says package
builders must install the package git-lfs before cloning upstream's
git repository.
2. Run `dch -r` to update the timestamp in d/changelog.

Once both of those items are done, please upload the final version to
Debian Mentors, and we should be good to go.

Hugh

Bug#1041196: marco: Window title disappears when the first character is Chinese

[Colomban Wendling]

Package: marco
Version: 1.26.1-3+deb12u1
Followup-For: Bug #1041196

> A fix is merged upstream, although no new release has been made yet.

Indeed, however the version in Bookworm manually imports the patch
creating the issue, because it's not in 1.26.1 (it's in 1.26.2 though).

So IMO this need to be patched in Bookworm, and even in unstable
waiting for a release, as it's quite problematic when having such
title-less windows.

Bug#1053450: wlgreet: Non-existing background image

[Matthias Urlichs]

Package: wlgreet
Version: 0.4.1-2
Severity: normal
X-Debbugs-Cc: sm...@smurf.noris.de

The /etc/greetd/sway-config file shipped with wlgreet contains the line

output * bg /etc/greetd/background fill

but no such file exists, causing the default config to display an ugly
red error bar.

Please replace this line with

output * bg #00 solid_color

(or maybe some dark grey like #33).

Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)

[John Paul Adrian Glaubitz]

Hi!

On Wed, 2023-10-04 at 11:59 +0200, John Paul Adrian Glaubitz wrote:
> FWIW, I have not been able to build GHC from git on 32-bit PowerPC even for 
> 8.10.7. I assume,
> I will need to add some of Debian's patches on top of vanilla GHC in order to 
> get the build
> to succeed.
> 
> Trying to build GHC 9.0.2 fails for example with:
> 
> > http://paste.debian.net/hidden/31954e9a/

Looking at the ghc package in openSUSE, I found this patch [1] which disables 
unboxed arrays
in order to fix the build on big-endian systems. And, indeed, disabling unboxed 
arrays in
libraries/containers/containers/include/containers.h allows me to fully build 
ghc from git
on 32-bit PowerPC. See also [2].

I have now a working reproducer and can now start bisecting between 8.10.7 and 
9.0.2.

Adrian

> [1] 
> https://build.opensuse.org/package/view_file/devel:languages:haskell/ghc/Disable-unboxed-arrays.patch?expand=1
> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/16998

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

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Holger Wansing]

Hi,

Thomas Lange  wrote (Wed, 4 Oct 2023 10:29:35 +0200):
> Hi Holger,
> 
> I really like the idea no to produce release notes for each
> architecture but only one. Moving to sphinx is also nice.
> 
> Sorry, if I broke your MR, by adding code that checks if something
> changed in the git repo. I think I can easily add this to your code
> later. So maybe we copy your version of 7release-notes and after that
> I add my code.

That would be really great!

> Do you know how long the build process takes using sphinx? I've added
> the code, because the build took around 90 minutes using docbook.

I expect the build time to be reduced dramatically (rughly ~ 1/9, due to 
building only one arch instead of nine), but I have no definite values, 
expecially not for the run on www-master.

> Any other things I should keep an eye on?

None at the moment.

Thanks for considering this MR.
It would give us the possibility to move r-n to sphinx, which would be a
great deal!


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1053449: VisiData requires python3-pkg-resources

[Daniel Carpenter]

Package: visidata
Version: 2.11-1

When I install visidata in a fresh debian:sid docker container, it crashes
when I try to start it:

  File "/usr/bin/vd", line 3, in 
import visidata.main
  File "/usr/lib/python3/dist-packages/visidata/__init__.py", line 102, in

import visidata.main
  File "/usr/lib/python3/dist-packages/visidata/main.py", line 19, in

from pkg_resources import resource_filename
ModuleNotFoundError: No module named 'pkg_resources'

If I also install python3-pkg-resources, it does start. Is it a dependency?

I see that bullseye is not affected, but bookworm and trixie are.

Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)

[John Paul Adrian Glaubitz]

Hi Ilias!

On Wed, 2023-09-20 at 14:54 +0300, Ilias Tsitsimpis wrote:
> Thanks for working on this, comments inline.

Thanks for the useful hints!

> On Wed, Sep 20, 2023 at 12:15PM, John Paul Adrian Glaubitz wrote:
> > I have been bisecting this issue but in order to be successful, I need a 
> > simple
> > reproducer which isn't trivial since I cannot just reuse the build 
> > directory of
> > an unsuccessful build due to the changing Haskell libraries for different 
> > GHC
> > versions.
> > 
> > Ideally, we should have a single command line with GHC which will trigger 
> > the
> > segmentation fault.
> 
> Are you bisecting the segfault issue? If yes, then a simple reproducer
> would be to try and compile haskell-random.
> 
> Since you already have cabal-install on your system, you can do
> something like:
> 
>   $ cabal install --with-ghc=/usr/bin/ghc --with-ghc-pkg=/usr/bin/ghc-pkg 
> random-1.2.1.1
> 
> (replace ghc and ghc-pkg with the ones you have built).

Thanks, this is the exact reproducer I need. I can reproduce the crash using 
this
command line inside a 32-bit PowerPC chroot on perotto with ghc 9.0.2.

> > To bisect, I have done the following:
> > 
> > # git bisect start
> > # git bisect good ghc-8.10.7-release
> > # git bisect bad ghc-9.2.7-release
> 
> Since this issue is also present in ghc-9.0.2, maybe we can start from
> there.

Yes, that's what I am trying now as well.

> > # git submodule update --init
> > # ./boot ; python3 boot
> > # echo "SRC_HC_OPTS += -lffi -latomic -optl-pthread" >> mk/build.mk && \
> >   echo "Stage1Only := YES" >> mk/build.mk && \
> >   echo 'utils/genprimopcode_CONFIGURE_OPTS += "-f-build-tool-depends"' \
> >   >> mk/build.mk && echo 'compiler_CONFIGURE_OPTS += 
> > "-f-build-tool-depends"' \
> >   >> mk/build.mk && echo 'utils/hpc_CONFIGURE_OPTS += 
> > "-f-build-tool-depends"' \
> >   >> mk/build.mk && echo "HADDOCK_DOCS := NO" >> mk/build.mk \
> >   && echo "BUILD_SPHINX_HTML := NO" >> mk/build.mk && echo 
> > "BUILD_SPHINX_PDF := NO" \
> >   >> mk/build.mk
> > # ./configure && make -j32
> > 
> > For newer versions, the build has to be performed with Hadrian, so the last 
> > step
> > would be:
> > 
> > # ./hadrian/build -j
> 
> Keep in mind that hadrian doesn't take into account 'mk/build.mk'. You
> will have to configure hadrian in the same way, see also
> https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html.

Thanks, good to know!

> Let me summarize the current state to make sure we are not missing
> anything:
> 
> 1. GHC 9.0.2 with the native code generator is currently broken on
> powerpc and segfaults while building (at least) haskell-random and
> GHC-9.4.6. Strangely enough, we can compile GHC 9.0.2 itself.
> 
> 2. An unregisterised GHC 9.0.2 is *also* broken on powerpc, producing 
> code that overflows integers. We are also seeing unregisterised GHC
> 9.4.6 on i386 being broken, since the tests for haskell-quickcheck fail
> (see 
> https://buildd.debian.org/status/package.php?p=haskell-quickcheck=sid).
> The plan for i386 is to registerise GHC and use the LLVM backend by
> default (to avoid the baseline violation).

I see.

> 3. We cannot cross-compile GHC 9.4 and newer any more (we are discussing
> this here as well https://gitlab.haskell.org/ghc/ghc/-/issues/23975).

This can be trivially fixed with the help of this patch:

> https://gitlab.haskell.org/ghc/ghc/-/commit/9cb385098f2dfd647c13ca509d71786c56277cff

> Given the above, I can think of the following:
> 
> 1. Fix the native code generator in GHC 9.0.2
> 2. Fix unregisterised GHCs on 32-bit architectures

FWIW, I am seeing the overflow on 32-bit PowerPC only. I don't see it on m68k, 
for example.

> 3. Try and use the LLVM backend in GHC 9.0.2 on powerpc, and see if this
> produces valid code and allows us to compile GHC 9.4.6.

Ah, that's actually a possible approach to take.

FWIW, I have not been able to build GHC from git on 32-bit PowerPC even for 
8.10.7. I assume,
I will need to add some of Debian's patches on top of vanilla GHC in order to 
get the build
to succeed.

Trying to build GHC 9.0.2 fails for example with:

> http://paste.debian.net/hidden/31954e9a/

> For the record, I have started working on migrating GHC in Debian to use
> the new Hadrian build system, you can find the latest code here
> https://salsa.debian.org/haskell-team/DHG_packages/-/tree/hadrian. I am
> at a really good state right now where I can build GHC, and doing a lot
> of tests to verify I haven't missed anything. If you are working on GHC
> right now as well, I would appreciate if you can take a look, and/or
> start using this branch for all your tests, so we catch any errors
> early.

I want to get the build issue on 32-bit PowerPC sorted out first.

Adrian

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

Bug#1053446: xdg-email portal unavailable after default install

[Simon McVittie]

On Wed, 04 Oct 2023 at 10:57:18 +0200, Alec Leamas wrote:
> After a default install + installing flatpak the xdg-email portal does not
> work.

A default install of what exactly? What steps can be followed to reproduce
this problem?

The reason I ask is that Flatpak apps can't run the /usr/bin/xdg-email
from the host system, so if your steps to reproduce involve something
happening inside a Flatpak app that will run xdg-email from the PATH,
a dependency on xdg-utils on the host is not going to have the effect
that you're hoping for.

Inside a Flatpak app, none of the programs installed from .deb packages in
the host's /usr/bin are available. Instead, /usr comes from the Flatpak
runtime. If the app wants to be able to run xdg-email, then either the
app or its runtime needs to include the same code that is available
in Debian's flatpak-xdg-utils package (but, again, installed inside
the Flatpak app or runtime, not on the host system, so a dependency on
flatpak-xdg-utils on the host would not be helpful).

For example, the reference runtime org.freedesktop.Platform contains
a /usr/bin/xdg-email executable compiled from the same codebase as
Debian's flatpak-xdg-utils package (at least, version 22.08 does,
I haven't checked older or newer branches). This means that derived
runtimes like org.gnome.Platform//44 also contain that executable.

> Since the xdg-email portal requires xdg-utils

It does not. It requires any email client on the host system, either
installed from a .deb or a Flatpak app (or a Snap app or anything else
that participates in the freedesktop.org ecosystem), that registers
itself in a .desktop file as a freedesktop.org MIME-type handler for the
pseudo-MIME-type "x-scheme-handler/mailto". For example, thunderbird or
mutt would be suitable.

This is the same thing that xdg-utils requires in order to have the
xdg-email executable work, in any desktop environment that doesn't have
its own special code path in xdg-utils.

Steps to demonstrate this, starting from a virtual machine image produced
by autopkgtest-build-qemu, which has no graphical environment installed
and should be approximately equivalent to an installation from
debian-installer with no tasks enabled:

# apt install openbox xdm xorg flatpak mutt xterm
# apt purge xdg-utils
Package 'xdg-utils' is not installed, so not removed
# reboot
(GUI: log in to xdm, right-click on background, open a terminal)
$ flatpak remote-add --user --if-not-exists flathub flathub 
https://dl.flathub.org/repo/flathub.flatpakrepo
$ flatpak install --user flathub org.freedesktop.Platform//22.08
$ flatpak run org.freedesktop.Platform//22.08
[inside Flatpak app's shell]$ xdg-email nob...@example.com
(GUI: a new xterm opens, running mutt)

or for a more GUI reproducer, replace the last few steps with:

$ flatpak remote-add --user --if-not-exists flathub flathub 
https://dl.flathub.org/repo/flathub.flatpakrepo
$ flatpak install --user flathub com.belmoussaoui.ashpd.demo
$ flatpak run com.belmoussaoui.ashpd.demo
(GUI: go to Email tab, fill in Addresses: nob...@example.com, click Request)
(GUI: a new xterm opens, running mutt)

smcv

Bug#1053448: libzmq5: libzmq5: issues with fork detection

[Support Centreon]

Package: libzmq5
Version: 4.3.4-1
Severity: normal
File: libzmq5

Dear Maintainer,

There is a bug on the latest version of libzmq5 which has been fixed by
the community but there is no new version for almost 3 years.
We meet this bug when libzmq is compiled with GCC 7 or newer. We get this 
message:
Assertion failed: ok (src/mailbox.cpp:99)

Here is the issue description:
https://github.com/zeromq/libzmq/issues/3313

Here is the fix:
https://github.com/zeromq/libzmq/pull/4309

Is it possible to compile a new version with the fix and put it on your
repositories?
I would really appreciate it.

Best regards

Stéphane

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

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

Versions of packages libzmq5:amd64 depends on:
ii  libbsd0   0.11.3-1
ii  libc6 2.31-13+deb11u7
ii  libgcc-s1 10.2.1-6
ii  libgssapi-krb5-2  1.18.3-6+deb11u3
ii  libnorm1  1.5.9+dfsg-2
ii  libpgm-5.3-0  5.3.128~dfsg-2
ii  libsodium23   1.0.18-1
ii  libstdc++610.2.1-6

libzmq5:amd64 recommends no packages.

libzmq5:amd64 suggests no packages.

-- no debconf information

Bug#1053443: automount should not act if filesystem is already mounted

[Michael Biebl]

Am 04.10.23 um 08:38 schrieb Marc Haber:

Package: systemd
Version: 254.5-1
Severity: minor
File: /usr/share/man/man8/systemd-gpt-auto-generator.8.gz

Hi,

on my systems, /boot/efi is mounted via /etc/fstab. I am not sure
whether this is wrong, but I'd like it to be mounted all the time and
stay mounted. When aide runs, a generated efi.automount is invoked and
mounts /boot/efi again over the already mounted filesystem.

Since the EFI partition is a vfat filesystem which doesn't have inodes,
the inode values are synthesized differently for every aide run, which
triggers a security mechanism in aide since aide now thinks that
somebody is trying to move a different file in place between file
enumeration and checksum building.

Could the generated automounter please grow a condition to not act if
the filesystem in question is already mounted?


hm, that sounds like a bug. Reading man systemd-gpt-auto-generator
'''

   The ESP is mounted to /boot/ if that directory exists and is not 
used for XBOOTLDR, and otherwise to /efi/. Same as for /boot/, an 
automount unit is used. The mount point will be created if necessary.


   No configuration is created for mount points that are configured 
in fstab(5) or when the target directory contains files.


'''

You can disable systemd-gpt-auto-generator via the systemd.gpt_auto=0 
kernel command line parameter until this is addressed.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1022034: policyd-rate-limit: Uses deprecated yaml.load

[Fabio]

Package: policyd-rate-limit
Version: 1.0.1.1-2.1
Followup-For: Bug #1022034

Dear Maintainer,

seems that utils.py use an old syntax, I've applied this patch:

88c88
< self._config = yaml.load(f)
---
> self._config = yaml.load(f, 
> Loader=yaml.SafeLoader)

to the file:

usr/lib/python3/dist-packages/policyd_rate_limit/utils.py

Still testing but seems resolved.

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

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 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 policyd-rate-limit depends on:
ii  adduser  3.134
ii  init-system-helpers  1.65.2
ii  python3  3.11.2-1+b1
ii  python3-yaml 6.0-3+b2

policyd-rate-limit recommends no packages.

Versions of packages policyd-rate-limit suggests:
pn  python3-mysqldb   
ii  python3-psycopg2  2.9.5-1+b1

-- no debconf information

Bug#1052613: Keepalived occasionally fails SSL_CHECK

[Vincent Bernat]

Hello Pavel,

I'll be more comfortable if you submitted this patch upstream first.

On 2023-09-25 12:48, Pavel Matěja wrote:

Package: keepalived
Version: 1:2.2.7-1

I'm upgrading our servers from Bullseye to Bookworm. Some of them act as load 
balancers using keepalived.
Right now I have one Bullseye and one Bookworm with the same configuration 
checking the same services.
Several of our services are running on HTTPS therefore I'm using SSL_CHECK.
I can see that the Bookworm one occasionally fails SSL_CHECK for several 
seconds on one service while the
Bullseye does not report any problem at all.
It's quite rare - not even once per hour with 2s loop delay.

I was looking for possible reason and I've found
https://github.com/openssl/openssl/issues/20365
https://github.com/pjsip/pjproject/issues/3632
https://stackoverflow.com/questions/18179128/how-to-manage-the-error-queue-in-openssl-ssl-get-error-and-err-get-error

They are all basically saying that you can have multiple SSL errors left in 
error queue and you are supposed to
run|ERR_get_error() before calling |SSL_* functions.

I've tried to patch keepalived sources (see attachment) and the problem seems 
to disappear.

I have no idea why is Bullseye package unaffected. It might be related to 
different OpenSSL version.

What do you think about this?

--
Pavel Matěja

Bug#1052845: python-django-tagging: FTBFS: raise FullResultSet

[Alexandre Rossi]

Hi,

Seems like this is fixed in:
https://salsa.debian.org/python-team/packages/python-django-tagging/-/merge_requests/2

Thanks,

Alex

Bug#1052019: RFS: golang-github-gookit-color/1.5.4-1

[Afeedh Shaji]

Dear Go team,

I am looking for a sponsor for the package "golang-github-gookit-color".
This package is a prerequisite for upcoming package "lazygit" (#908894).

I pushed to our team's Salsa:

  https://salsa.debian.org/go-team/packages/golang-github-gookit-color

Could you please reviewing/sponsoring this?
Any kind of reviews and suggestions are appreciated.


Thanks,
Afeedh



signature.asc
Description: PGP signature

Bug#1053446: xdg-email portal unavailable after default install

[Alec Leamas]

Package: flatpak
Version:  1.14.3-1

After a default install + installing flatpak the xdg-email portal does 
not work. The reason is that the native xdg-email application is not 
available, it is part of the xdg-utils package which not is pulled in by 
the flatpak package.


According to the descripion, the flatpak package "contains the services 
and executables needed to install and launch sandboxed applications, and 
the portal services needed to provide limited access to resources 
outside the sandbox."


Since the xdg-email portal requires xdg-utils, the flatpak package IMHO 
thus should add a "Depends: xdg-utils" or possibly "Recommends",  either 
directly in the flatpak package or indirectly in for example 
xdg-desktop-portal.

Bug#1053195: Please remove librados-dev build-depends on all 32 bits arch

[Thomas Goirand]

On 10/2/23 16:52, Christoph Martin wrote:

Hi Thomas,

I would limit the dependencies to the following architectures:
[amd64 arm64 ia64 mips64el ppc64 ppc64el riscv64 s390x sparc64],

Is this the correct list?

And what about the dependency on librgw-dev?

Regards
Christoph


Hi Christoph,

The above list of arch seem technically correct to me, however, Ceph 
wont build on many of them (sparc64, ppc64, ia64), so you may want to 
remove the build-dep for them too. See this:

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

So really, your list of arch should be:
[amd64 arm64 mips64el ppc64el riscv64 s390x]

as I don't trust it will be easy to re-add compat for anything else. So 
it may be easier for you, and more productive for these non-official 
ports, to let them build without Ceph support.


Note that I'm currently trying to fix the mips64el, which should be fine 
on my next upload.


As for librgw-dev, same thing, as all things Ceph will be removed from 
Debian for 32 bits arch...


Thanks for your care,
Cheers,

Thomas Goirand (zigo)

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Thomas Lange]

Hi Holger,

I really like the idea no to produce release notes for each
architecture but only one. Moving to sphinx is also nice.

Sorry, if I broke your MR, by adding code that checks if something
changed in the git repo. I think I can easily add this to your code
later. So maybe we copy your version of 7release-notes and after that
I add my code.

Do you know how long the build process takes using sphinx? I've added
the code, because the build took around 90 minutes using docbook.

Any other things I should keep an eye on?
-- 
regards Thomas

Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)

[Manphiz]

Hi Amin,

Amin Bandali  writes:

> Hiya,
>
> Manphiz writes:
>
>> Manphiz  writes:
>>
>>> Another finding is that in 28.x, if the term buffer have any further
>>> questions to ask, debian-bug seems to consider the process stuck and
>>> would just ignore everything and proceed.  In 29.x however, the term
>>> buffer seems to be able to accept user input and can process the output
>>> accordingly - even if the script requires sudo and prompt for password,
>>> and debian-bug can properly include the output in the generated email
>>> for bug report.  So with the merge request[4] it would instead skip all
>>> potential additional information unfortunately.
>>>
>>
>> Actually 28.x also works for user inputs if running term-exec without my
>> problematic hooks so yeah!
>>
>>> As we do want to handle process termination better, while trying to keep
>>> process from failing, I think temporarily disable term-exec-hook when
>>> processing the output and restore after the report is generated should
>>> probably work in most cases.  Just wondering whether this is acceptable
>>> in the process of debian-bug?
>>>
>>
>> Forgot to mention that this is implemented as the 2nd commit in the
>> MR[4] and tested on bookworm and trixie to be working.
>>
>>> [4] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/11
>
> Thank you for the patch. :-)  This seems like a reasonable fix to me,
> and if David has no comments or objections I'd be happy to merge it
> in the coming days.
>
> Quick request: would you please amend your patch/MR to add a
> debian/changelog entry for the change(s)?  It would be good to
> do a new upload soon, and it'd be nice to have debian/changelog
> in tiptop shape for that.
>
> Thanks,
> -a

Thanks for the review!  I've pushed another commit adding the changelog
entries, and changed some of the commit message to be consistent, so
please force pull if you want to test again.  Would definitely look
forward to hearing from David as well.

P.S. I'm also testing some patches to fix the comp warnings and
hopefully can be included in the next upload.  Will send another merge
request when ready.

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Created a new bug to track the MR
https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13

That is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053445


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

[Holger Wansing]

Hi,

Holger Wansing  wrote (Wed, 4 Oct 2023 09:27:34 +0200):
> > I have just requested webmaster to switch the bookworm build from the 
> > master branch to the bookworm branch [1]. After that request gets merged 
> > and deployed, I'd like you to publish your work in the master branch 
> > such that we can work from there (and see the results too [2]). Because 
> > in your worked we stopped making notes per architecture, we probably 
> > need to make further changes to the webmaster archive, but let's first 
> > build something.
> 
> Hey webmaster team,
> 
> please consider MR13 in webmaster's cron repo:
> 
> https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13

I filed this MR ~ 6 weeks ago, but no reaction so far.
And yesterday other commits made this MR broken, unable to merge it now.
Needs to be overworked now.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1052487: aide-common: please recommend canonical "cron | cron-daemon"

[Marc Haber]

On Tue, Oct 03, 2023 at 11:26:51PM +0200, Alexandre Detiste wrote:
> BTW: to make systemd-cron life easier, the .service/.timer
> name has to exactly match the cron job name.

Is that a recommendation to rename /etc/cron.daily/aide to
/etc/cron.daily/dailyaidecheck because timer and service are
dailyaidechck as well?

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