Bug#1066898: tracker-extract: always crash - related to sandboxing making chmod from fontconfig to always fail

[Alban Browaeys]

Package: tracker-extract
Version: 3.7~rc-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   I believe upgrading to Sid from Trixie a few days ago.


mars 15 06:10:37 hermes tracker-miner-fs-3[1633275]: Fontconfig error: Cannot 
load default config file: Unable to open /etc/fonts/fonts.conf
mars 15 06:10:37 hermes tracker-miner-fs-3[1633275]: Disallowed syscall "chmod" 
caught in sandbox
mars 15 06:10:37 hermes systemd[1]: Started 
systemd-coredump@33956-1633288-0.service - Process Core Dump (PID 1633288/UID 
0).
mars 15 06:10:38 hermes systemd[1]: Started 
drkonqi-coredump-processor@33956-1633288-0.service - Pass systemd-coredump 
journal entries to relevant user for potential DrKonqi handling.
mars 15 06:10:38 hermes systemd-coredump[1633289]: Removed old coredump 
core.tracker-extract.1000.4370b7ec7f8d4cf8998826bce50c6f8b.1553954.171047636300.zst.
mars 15 06:10:38 hermes drkonqi-coredump-processor[1633290]: Entry doesn't look 
like a dump. This may have been a vaccum run. Nothing to process.
mars 15 06:10:38 hermes systemd-coredump[1633289]: [] Process 1633275 
(tracker-extract) of user 1000 dumped core.

   Module libsystemd.so.0 from 
deb systemd-255.4-1+b1.amd64
   Module libudev.so.1 from deb 
systemd-255.4-1+b1.amd64
   Module libarchive.so.13 from 
deb libarchive-3.7.2-1.1.amd64
   Module libzstd.so.1 from deb 
libzstd-1.5.5+dfsg2-2.amd64
   Stack trace of thread 
1633287:
   #0  0x7f50633aa207 
__tgkill (libc.so.6 + 0x10a207)
   #1  0x7f50632dc510 
__restore_rt (libc.so.6 + 0x3c510)
   #2  0x7f50633975a7 
__GI___chmod (libc.so.6 + 0xf75a7)
   #3  0x7f5062297d68 
FcDirCacheWrite (libfontconfig.so.1 + 0xbd68)
   #4  0x7f50622a200b 
FcDirCacheScan (libfontconfig.so.1 + 0x1600b)
   #5  0x7f50622a2283 
IA__FcDirCacheRead (libfontconfig.so.1 + 0x16283)
   #6  0x7f506229c7f1 
FcConfigAddDirList (libfontconfig.so.1 + 0x107f1)
   #7  0x7f506229c8c4 
IA__FcConfigBuildFonts (libfontconfig.so.1 + 0x108c4)
   #8  0x7f50622a8d8c 
FcInitLoadOwnConfigAndFonts (libfontconfig.so.1 + 0x1cd8c)
   #9  0x7f5062298f26 
FcConfigEnsure (libfontconfig.so.1 + 0xcf26)
   #10 0x7f5062298f8d 
FcConfigInit (libfontconfig.so.1 + 0xcf8d)
   #11 0x7f50573a3415 
init_in_thread (libpangoft2-1.0.so.0 + 0xc415)
   #12 0x7f50638ffab1 
g_thread_proxy (libglib-2.0.so.0 + 0x87ab1)
   #13 0x7f506332845c 
start_thread (libc.so.6 + 0x8845c)
   #14 0x7f50633a8bbc 
__clone3 (libc.so.6 + 0x108bbc)

   Stack trace of thread 
1633280:
   #0  0x7f50633a1059 
syscall (libc.so.6 + 0x101059)
   #1  0x7f506392dc90 
g_cond_wait_until (libglib-2.0.so.0 + 0xb5c90)
   #2  0x7f506389c143 
g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x24143)
   #3  0x7f50639004ba 
g_thread_pool_wait_for_new_task (libglib-2.0.so.0 + 0x884ba)
   #4  0x7f50638ffab1 
g_thread_proxy (libglib-2.0.so.0 + 0x87ab1)
   #5  0x7f506332845c 
start_thread (libc.so.6 + 0x8845c)
   #6  0x7f50633a8bbc 
__clone3 (libc.so.6 + 0x108bbc)

   Stack trace of thread 
1633275:
   #0  0x7f50639db4a5 
elf_get_dynamic_info (ld-linux-x86-64.so.2 + 0x74a5)
   #1  0x7f50639dc4e5 
_dl_map_object (ld-linux-x86-64.so.2 + 0x84e5)
   #2  0x7f50639d66d1 
openaux (ld-linux-x86-64.so.2 + 0x26d1)
   #3  0x7f50639d5489 
__GI__dl_catch_exception (ld-linux-x86-64.so.2 + 0x1489)
 

Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Otto Kekäläinen]

Hi!

Is anyone perhaps planning to fix cargo?

For example curl isn't building on armel/armhf now and numerous packages
that depend of curl are not building on armel/armhf.

Thanks in advance to the person who steps up.

Bug#1058493: gamescope: Please update to wlroots 0.17

[Safir Secerovic]

Dear Andrej and Guido,

I have prepared preliminary packaging for openvr2 library in my salsa
repository [1].
It builds, but since I have preserved git history from openvr project, I
had to use gbp buildpackage --git-no-pristine-tar to build successfully,
since there were reasonable problems with deltas since I changed the
project name.  That needs some cleanup and the whole repo needs revision
and inspection, since we are talking about a new shared library with a bump
in soname version.
Feel free to clone and suggest things.

In the meantime, I could try to prepare and upload a new gamescope package
with openvr support disabled.

Regards,
sapphire

[1] https://salsa.debian.org/sapphire/openvr2

On Thu, Mar 14, 2024 at 6:16 PM Safir Secerovic 
wrote:

> Hi Andrej,
>
> Are you guys interested in packaging this?
> Packaging new openvr version 2 library (libopenvr-api2 and libopevr2-dev)
> and introducing / sponsoring it into Debian.
>
> We need it for new gamescope releases since two months ago.
>
> Please let us know.
>
> Thanks,
> sapphire
>
> -- Forwarded message -
> From: Safir Secerovic 
> Date: Thu, Mar 14, 2024 at 6:10 PM
> Subject: Re: gamescope: Please update to wlroots 0.17
> To: Debian Bug Tracking System <1058...@bugs.debian.org>
>
>
> Source: gamescope
> Followup-For: Bug #1058493
>
> Dear Developer,
>
> While trying to package the latest version of gamescope,
> there is an obstacle that need to be dealt with.
>
> Namely, a couple of months ago, gamescope upstream has switched its
> dependency
> from libopenvr to libopenvr2 [1].
> Packages libopenvr-api1 and libopenvr-dev cannot be used to build latest
> gamescope.
>
> We need to package libopenvr-api2 and libopevr2-dev I guess.
> I have no problem looking into packaging it myself, but I would need
> sponsorship to introduce the new library into Debian.
>
> Let me know what You think.
>
> Regards,
> sapphire
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.8.0-x64v3-xanmod1 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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
>

Bug#1065779: libcdk5: FTBFS on arm{el,hf}: configure:7804:12: error: implicit declaration of function 'tgoto' [-Werror=implicit-function-declaration]

[Steven Robbins]

Control: tags 1065779 + pending

On Wednesday, March 13, 2024 5:53:11 A.M. CDT Thomas Dickey wrote:

> upgrading really is the simplest solution - not much depends on this,
> and nothing cares about the actual version:

I have uploaded the latest upstream to experimental, which should fix this.  
Unfortunately, the arm builds fail for an unrelated reason -- build-dep 
installability problems.

-Steve


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

Bug#1066897: chrony: NTP server list should be in a file in sources.d

[chkboom]

Package: chrony

The NTP server list should be moved into a file in the sources directory. Doing 
so separates them from the main configuration file.

Also there is no need to restart the daemon if changing anything that is in the 
sources directory.
Changes can be reloaded with: chronyc reload sources

Since /etc/chrony/sources.d is already configured as a directory for chrony 
sources, it seems logical to have all the NTP servers and other sources in that 
directory.

Bug#1066896: chrony: NTP server list should be in a file in sources.d

[chkboom]

Package: chrony
Version: 4.5-1
Severity: wishlist

Dear Maintainer,

The NTP server list should be moved into a file in the sources directory. Doing 
so separates them from the main configuration file.

Also there is no need to restart the daemon if changing anything that is in the 
sources directory.
Changes can be reloaded with: chronyc reload sources

Since /etc/chrony/sources.d is already configured as a directory for chrony 
sources, it seems logical to have all the NTP servers and other sources in that 
directory.

Bug#1066815: ITP: golang-github-woblerr-pgbackrest-exporter -- Prometheus exporter for pgBackRest

[Daniel Swarbrick]

The package name "golang-github-woblerr-pgbackrest-exporter" gives the 
impression that this is a library package.


Please consider naming it as per the more or less adopted convention 
used by the approximately three dozen other Prometheus exporter 
packages, e.g. "prometheus-pgbackrest-exporter".




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064925: RFP: fail2ban-prometheus-exporter - collect and export Prometheus metrics on Fail2Ban)

[Daniel Swarbrick]

Should the package name perhaps instead be 
"prometheus-fail2ban-exporter", so that it aligns with the approximately 
three dozen other exporters already packaged by Debian?


In case you're wondering, there /are/ other examples where the upstream 
name has been munged to conform with the "prometheus-foo-exporter" 
pattern, e.g. prometheus-mqtt-exporter (upstream name mqtt2prometheus).




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063489: ITP: golang-github-rluisr-mysqlrouter-exporter -- Prometheus exporter for MySQL router

[Daniel Swarbrick]

The package name "golang-github-rluisr-mysqlrouter-exporter" gives the 
impression that this is a library package.


Perhaps consider naming it as per the more or less adopted convention 
used by other Prometheus exporter packages, e.g. 
"prometheus-mysqlrouter-exporter".




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066893: missing deps

[Antoine Beaupré]

A bunch of deps are missing from debian at the moment:

2024/03/14 21:19:20 Build-Dependency "github.com/pterm/pterm" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/d5/tengo" is not yet available 
in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/errata-ai/regexp2" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/mholt/archiver" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/adrg/strutil" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/errata-ai/ini" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/jdkato/twine" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control

so that's kind of a big undertaking. some of those are actually pretty
interesting on their own, like pterm looks like a cool lib!

Others are more of a problem, like errata-ai/regexp2 which is a fork of
an existing lib (*also* not in Debian). errata-ai/ini looks like a
rather gratitious fork as well.

-- 
Qui vit sans folie n'est pas si sage qu'il croit.
- François de La Rochefoucauld

Bug#1066895: python-reactivex: duplicate of src:python-rx

[Andreas Beckmann]

Source: python-reactivex
Version: 4.0.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict
Control: affects -1 + src:python-rx

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

python-reactivex seems to be a duplication of python-rx which is already
in the archive.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-reactivex_4.0.4-1_all.deb ...
  Unpacking python3-reactivex (4.0.4-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-reactivex_4.0.4-1_all.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/reactivex/__init__.py', 
which is also in package python3-rx 4.0.4-2
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-reactivex_4.0.4-1_all.deb

List of duplicated files:

usr/lib/python3/dist-packages/reactivex-0.0.0.dist-info/METADATA
usr/lib/python3/dist-packages/reactivex-0.0.0.dist-info/WHEEL
usr/lib/python3/dist-packages/reactivex/__init__.py
usr/lib/python3/dist-packages/reactivex/_version.py
usr/lib/python3/dist-packages/reactivex/abc/__init__.py
usr/lib/python3/dist-packages/reactivex/abc/disposable.py
usr/lib/python3/dist-packages/reactivex/abc/observable.py
usr/lib/python3/dist-packages/reactivex/abc/observer.py
usr/lib/python3/dist-packages/reactivex/abc/periodicscheduler.py
usr/lib/python3/dist-packages/reactivex/abc/scheduler.py
usr/lib/python3/dist-packages/reactivex/abc/startable.py
usr/lib/python3/dist-packages/reactivex/abc/subject.py
usr/lib/python3/dist-packages/reactivex/disposable/__init__.py
usr/lib/python3/dist-packages/reactivex/disposable/booleandisposable.py
usr/lib/python3/dist-packages/reactivex/disposable/compositedisposable.py
usr/lib/python3/dist-packages/reactivex/disposable/disposable.py
usr/lib/python3/dist-packages/reactivex/disposable/multipleassignmentdisposable.py
usr/lib/python3/dist-packages/reactivex/disposable/refcountdisposable.py
usr/lib/python3/dist-packages/reactivex/disposable/scheduleddisposable.py
usr/lib/python3/dist-packages/reactivex/disposable/serialdisposable.py
usr/lib/python3/dist-packages/reactivex/disposable/singleassignmentdisposable.py
usr/lib/python3/dist-packages/reactivex/internal/__init__.py
usr/lib/python3/dist-packages/reactivex/internal/basic.py
usr/lib/python3/dist-packages/reactivex/internal/concurrency.py
usr/lib/python3/dist-packages/reactivex/internal/constants.py
usr/lib/python3/dist-packages/reactivex/internal/exceptions.py
usr/lib/python3/dist-packages/reactivex/internal/priorityqueue.py
usr/lib/python3/dist-packages/reactivex/internal/utils.py
usr/lib/python3/dist-packages/reactivex/notification.py
usr/lib/python3/dist-packages/reactivex/observable/__init__.py
usr/lib/python3/dist-packages/reactivex/observable/amb.py
usr/lib/python3/dist-packages/reactivex/observable/case.py
usr/lib/python3/dist-packages/reactivex/observable/catch.py
usr/lib/python3/dist-packages/reactivex/observable/combinelatest.py
usr/lib/python3/dist-packages/reactivex/observable/concat.py
usr/lib/python3/dist-packages/reactivex/observable/connectableobservable.py
usr/lib/python3/dist-packages/reactivex/observable/defer.py
usr/lib/python3/dist-packages/reactivex/observable/empty.py
usr/lib/python3/dist-packages/reactivex/observable/forkjoin.py
usr/lib/python3/dist-packages/reactivex/observable/fromcallback.py
usr/lib/python3/dist-packages/reactivex/observable/fromfuture.py
usr/lib/python3/dist-packages/reactivex/observable/fromiterable.py
usr/lib/python3/dist-packages/reactivex/observable/generate.py
usr/lib/python3/dist-packages/reactivex/observable/generatewithrelativetime.py
usr/lib/python3/dist-packages/reactivex/observable/groupedobservable.py
usr/lib/python3/dist-packages/reactivex/observable/ifthen.py
usr/lib/python3/dist-packages/reactivex/observable/interval.py
usr/lib/python3/dist-packages/reactivex/observable/marbles.py
usr/lib/python3/dist-packages/reactivex/observable/merge.py
usr/lib/python3/dist-packages/reactivex/observable/never.py
usr/lib/python3/dist-packages/reactivex/observable/observable.py
usr/lib/python3/dist-packages/reactivex/observable/onerrorresumenext.py
usr/lib/python3/dist-packages/reactivex/observable/range.py
usr/lib/python3/dist-packages/reactivex/observable/repeat.py
usr/lib/python3/dist-packages/reactivex/observable/returnvalue.py
usr/lib/python3/dist-packages/reactivex/observable/start.py
usr/lib/python3/dist-packages/reactivex/observable/startasync.py
usr/lib/python3/dist-packages/reactivex/observable/throw.py
usr/lib/python3/dist-packages/reactivex/observable/timer.py
usr/lib/python3/dist-packages/reactivex/observable/toasync.py
usr/lib/python3/dist-packages/reactivex/observable/using.py
usr/lib/python3/dist-packages/reactivex/observable/withlatestfrom.py
usr/lib/python3/dist-packages/reactivex/observable/zip.py
usr/lib/python3/dist-packages/reactivex/observer/__init__.py

Bug#1066894: ITP: dh-puppet -- debhelper add-on to handle Puppet modules

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jérôme Charaoui 
X-Debbugs-Cc: debian-de...@lists.debian.org

   Package name : dh-puppet
   Version  : 1.0
   Upstream author  : Jérôme Charaoui 
   URL  : https://salsa.debian.org/puppet-team/dh-puppet
   License  : GPL-3.0
   Programming Lang : Perl
   Description  : debhelper add-on to handle Puppet modules

dh-puppet provides a debhelper sequence named 'puppet-module' to 
simplify the packaging of Puppet modules: it helps install a module's 
files and documentation, provides common postinst and prerm maintainer 
scripts, and generates control substitution variables for dependencies

Bug#1052138:

[Rowell]

Do you get my last mail

Bug#1066893: RFP: vale -- :pencil: A markup-aware linter for prose built with speed and extensibility in mind.

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: vale
  Version : 3.0.0-1
  Upstream Author : errata.ai
* URL : https://github.com/errata-ai/vale
* License : Expat
  Programming Lang: Go
  Description : A markup-aware linter for prose built with speed and 
extensibility in mind.

Vale is a command-line tool that brings code-like linting to
prose. It's fast, cross-platform (Windows, macOS, and Linux), and
highly customizable.

Key Features

Support for markup: Vale has a rich understanding of many markup formats, 
allowing it to avoid syntax-related false positives and intelligently exclude 
code snippets from prose-related rules.

A highly customizable extension system: Vale is capable of enforcing your 
style—be it a standard editorial style guide or a custom in-house set of rules 
(such as those created by GitLab, Homebrew, Linode, CockroachDB, and Spotify).

Easy-to-install, stand-alone binaries: Unlike other tools, Vale doesn't 
require you to install and configure a particular programming language and its 
related tooling (such as Python/pip or Node.js/npm).



There are a handful of spell-checkers and linters for prose in Debian,
but vale is a little different. It's not *only* a spellchecker and does
*other* things like checking for styles or allow for extensibility.

Similar software include diction(1) and markdownlint, where diction is
*really* old (e.g. doesn't know about markdown) and mdl is not very
customizable (e.g. it's hard, in my experience to add words to a
dictionary).

So I'm considering vale instead.

-- 
We must learn to live together as brothers or perish together as fools.
- Martin Luther King, Jr.

Bug#1066892: inventor: Update to 2.1.6 from GitHub

[Amr Ibrahim]

Package: inventor
Severity: normal

Dear Maintainer,

The current homepage is dead (Invalid URL), and apparently there is an effort
to maintain Open Inventor on GitHub:
https://github.com/aumuell/open-inventor

If you see fit, please update to 2.1.6 from GitHub, and change the homepage and
watch file accordingly.

2.1.6:
* build fixes for modern compilers on Linux and macOS
* bug fixes, most importantly font rendering on 64 bit Linux
* CMake as a modern alternative to the existing Makefile build system


Best,
Amr


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

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

Bug#1066890: rdma-core: don't build docs on minor arches (-DNO_MAN_PAGES=1)

[Drew Parsons]

Source: rdma-core
Version: 50.0-2
Severity: normal

rdma-core does not build on minor architectures, since pandoc is not
available.

pandoc is only needed for documentation (man pages).  It might be
possible to only build docs for arch-indepdent builds, then using
Build-Depends-Indep: pandoc 

In any case the rdma-core docs (man pages actually) are controlled by
NO_MAN_PAGES in CMakeLists.txt. What would be needed is to configure
cmake with -DNO_MAN_PAGES=1 on the minor architectires (if not all
binary-arch builds) to avoid or reduce the footprint of the pandoc
Build-Depends.


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

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

Bug#1065725: adns: FTBFS on arm{el,hf}: FAILED ./case-1stservbroken - WRONG OUTPUT - lines of syscall remaining 0

[Dan Bungert]

Greetings!

I took a look at this bug today.
I found that the regress testsuite make use of some negative offsets, which
seem to perplex the reader on 32 bit systems.

Please see the attached patch, which has allowed this to build for Ubuntu.

-Dan
Author:  Dan Bungert 
Description: Fix reads of signed values into unsigned variables
Bug-Ubuntu:  https://bugs.launchpad.net/bugs/2057735
Bug-Debian:  https://bugs.debian.org/1065725
Forwarded:   yes
Last-Update: 2024-03-14

The regress testsuite makes use of time offsets to mock the passage of time,
and some of the usec values are expressed as negative numbers.  Update the
reader to be able to handle that.
--- a/regress/hplayback.c.m4
+++ b/regress/hplayback.c.m4
@@ -108,7 +108,8 @@
 void Tensuresetup(void) {
   int fd;
   int chars;
-  unsigned long sec, usec;
+  time_t sec;
+  suseconds_t usec;
 
   Tensure_reportfile();
   Tensure_fuzzrawfile();
@@ -124,7 +125,7 @@
   if (!adns__vbuf_ensure(,1000)) Tnomem();
   fgets(vb2.buf,vb2.avail,Tinputfile); Pcheckinput();
   chars= -1;
-  sscanf(vb2.buf," start %lu.%lu%n",,,);
+  sscanf(vb2.buf," start %lld.%ld%n",,,);
   if (chars==-1) Psyntax("start time invalid");
   currenttime.tv_sec= sec;
   currenttime.tv_usec= usec;
@@ -170,12 +171,13 @@
 
 static void P_updatetime(void) {
   int chars;
-  unsigned long sec, usec;
+  time_t sec;
+  suseconds_t usec;
 
   if (!adns__vbuf_ensure(,1000)) Tnomem();
   fgets(vb2.buf,vb2.avail,Tinputfile); Pcheckinput();
   chars= -1;
-  sscanf(vb2.buf," +%lu.%lu%n",,,);
+  sscanf(vb2.buf," +%lld.%ld%n",,,);
   if (chars==-1) Psyntax("update time invalid");
   currenttime.tv_sec+= sec;
   currenttime.tv_usec+= usec;

Bug#1058493: Fwd: gamescope: Please update to wlroots 0.17

[Safir Secerovic]

Hi Andrej,

Are you guys interested in packaging this?
Packaging new openvr version 2 library (libopenvr-api2 and libopevr2-dev)
and introducing / sponsoring it into Debian.

We need it for new gamescope releases since two months ago.

Please let us know.

Thanks,
sapphire

-- Forwarded message -
From: Safir Secerovic 
Date: Thu, Mar 14, 2024 at 6:10 PM
Subject: Re: gamescope: Please update to wlroots 0.17
To: Debian Bug Tracking System <1058...@bugs.debian.org>


Source: gamescope
Followup-For: Bug #1058493

Dear Developer,

While trying to package the latest version of gamescope,
there is an obstacle that need to be dealt with.

Namely, a couple of months ago, gamescope upstream has switched its
dependency
from libopenvr to libopenvr2 [1].
Packages libopenvr-api1 and libopenvr-dev cannot be used to build latest
gamescope.

We need to package libopenvr-api2 and libopevr2-dev I guess.
I have no problem looking into packaging it myself, but I would need
sponsorship to introduce the new library into Debian.

Let me know what You think.

Regards,
sapphire

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

Kernel: Linux 6.8.0-x64v3-xanmod1 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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

Bug#1058493: gamescope: Please update to wlroots 0.17

[Safir Secerovic]

Source: gamescope
Followup-For: Bug #1058493

Dear Developer,

While trying to package the latest version of gamescope, 
there is an obstacle that need to be dealt with.

Namely, a couple of months ago, gamescope upstream has switched its dependency 
from libopenvr to libopenvr2 [1].
Packages libopenvr-api1 and libopenvr-dev cannot be used to build latest 
gamescope.

We need to package libopenvr-api2 and libopevr2-dev I guess.
I have no problem looking into packaging it myself, but I would need 
sponsorship to introduce the new library into Debian.

Let me know what You think.

Regards,
sapphire

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

Kernel: Linux 6.8.0-x64v3-xanmod1 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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

Bug#1066889: netplan.io 1.0 package build requires newer mason than in build deps

[tessa]

Package: netplan.io
Version: 1.0-1
Severity: normal

I discovered this minor packaging issue while attempting to backport the 1.0-1 
package to bookworm.
It appears as if the build deps list meson >= 0.61.0, but in actuality the 
build requires features from
1.3.0, and the build itself calls this out:

WARNING: Project specifies a minimum meson_version '>= 0.61.0' but uses 
features which were added in newer versions:
 * 1.3.0: {'limited_api arg in python.extension_module'}

probably just needs a build-dep update.

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

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

Versions of packages netplan.io depends on:
ii  iproute2   6.1.0-3
ii  libc6  2.36-9+deb12u4
ii  libglib2.0-0   2.74.6-2
ii  libnetplan00.106-2+deb12u1
ii  libsystemd0252.22-1~deb12u1
ii  python33.11.2-1+b1
ii  python3-dbus   1.3.2-4+b1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-rich   13.3.1-1
ii  python3-yaml   6.0-3+b2
ii  systemd252.22-1~deb12u1

netplan.io recommends no packages.

Versions of packages netplan.io suggests:
ii  iw  5.19-1
pn  openvswitch-switch  
ii  wpasupplicant   2:2.10-12

-- no debconf information

Bug#1066843: util-linux: --delete option does not work

[Francesco Potortì]

>
>Control: tags -1 + moreinfo
>
>On Thu, Mar 14, 2024 at 11:11:30AM +0100, Francesco Potortì wrote:
>> The man page for findmnt lists a --delete option which is necessary to me.  
>> Unfortunately, findmnt says it does not have such option, s (I resorted to 
>> using mount for that.
>> 
>> Either --delete should work for findmnt, or the man page should be amended 
>> to remove the --delete option and ideally suggest using mount for those 
>> needing it.
>
>The man page I have says nothing about --delete.
>It however lists --deleted (note the extra d).

Sure, sorry for the typo.  It is --deleted:

# findmnt --deleted 
   
findmnt: unrecognized option '--deleted'
Try 'findmnt --help' for more information.

Bug#1066850: don't hard-code the name of the shared library

[Matthias Klose]

On 14.03.24 21:38, Christoph Biedl wrote:

After getting some help in IRC, I guess the problem boils down to:

1. All architectures provide the t64 variant (libmagic1t64).
2. Some architectures no longer provide the old variant (libmagic1), for
example armhf.
3. Therefore, the install dependency of python3-magic must be the t64 variant.


and derive the name of the shared library package from the
libmagic-dev package.


Now replacing one hardcoded binary library dependency with a different
one is not quite the brightest move as this will introduce work should
the libmagic ABI ever change (hasn't happened in 20 years but still).
So it was nicer to do this dynamically during build. That step however
is optional.

Do you have an idea, an existing solution how to do that?

So far I found two ways, and dislike both:

* Derive from apt-cache:

 override_dh_gencontrol:
 perl -MDebian::Debhelper::Dh_Lib -e \
 'addsubstvar ("python3-magic", "misc:Depends", $$ARGV[0])' \
 "$$(apt-cache show libmagic-dev | awk '($$1=="Depends:"){print $$2}' | 
head -n 1)"
 dh_gencontrol $@

Querying the apt database from inside a package build feels like a layer
violation.

* Abuse dpkg-shlibdeps:

 override_dh_gencontrol:
 dpkg-shlibdeps -e /usr/bin/file -Tdebian/python3-magic.substvars
 dh_gencontrol $@

(Some tweaks to debian/control needed as well.)


dep := $(shell dpkg-query '-f${Depends}' -W libmagic-dev | sed 
's/.*\(libmagic[a-z0-9]*\).*/\1/')

echo "magic:Depends=$(dep)" >> debian/python3-magic.substvars

and add ${magic:Depends} to the control file.


This also introduces an install dependency on libc6, and my gut feeling
tells me this was the point to make python3-magic arch:any.


the approach above doesn't add the libc dependency.



So, is all this worth the efforts? FWIW, I maintain the libmagic
package as well, so being lazy now will just hurt me later.

 Christoph

Bug#793368: Updating /etc/default/locale doesn't update debconf selections during dpkg-reconfigure

[M. Buecher]

This bug still exits in Debian 12 "Bookworm"

File: /var/lib/dpkg/info/locales.config
Line: 371

The logic has to be inverted to work as intended.

Please fix
Matthias Bücher

Bug#1066888: wl-beta: After emacs upgrade, get spammed with warnings

[Peter Chubb]

Package: wl-beta
Version: 2.15.9+0.20230120-1
Severity: normal

Dear Maintainer,

After a routine apt upgrade, I start seeing lots of messages in the
Emacs *Warnings* buffer.  You can ignore them, and get your work done
reading email etc., but they ought to be fixed.  Here are some of them:

 Warning (comp): wl-draft.el:622:7: Warning: ‘string-as-multibyte’ is an 
obsolete function (as of 26.1); use ‘decode-coding-string’.
⛔ Warning (comp): wl-draft.el:752:55: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-draft.el:752:71: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): wl-draft.el:753:25: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-draft.el:753:46: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): wl-draft.el:2006:40: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): wl-draft.el:2126:51: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-draft.el:2126:65: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): wl-draft.el:2127:21: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-draft.el:2127:39: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): wl-action.el:609:18: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-thread.el:990:16: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-thread.el:1016:16: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-thread.el:1018:21: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-thread.el:1018:36: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): wl-fldmgr.el:110:19: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): wl-fldmgr.el:110:38: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.


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

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

Versions of packages wl-beta depends on:
ii  apel10.8+0.20220720-1
ii  emacsen-common  3.0.5
ii  flim1:1.14.9+0.20230205-1
ii  semi1.14.7~0.20230104-1

Versions of packages wl-beta recommends:
ii  ca-certificates20240203
ii  emacs  1:29.2+1-2
ii  emacs-gtk [emacs]  1:29.2+1-2+b1

Versions of packages wl-beta suggests:
pn  bbdb  
pn  bogofilter | bsfilter | spamassassin  
ii  gnupg 2.2.40-2
ii  gnutls-bin3.8.3-1.1
pn  im
pn  maildir-utils 
pn  mhc   
pn  mu-cite   
pn  namazu2   
pn  notmuch   
ii  openssl   3.1.5-1.1
pn  starttls  
pn  w3m-el
pn  x-face-el 

-- no debconf information

Bug#189252: gzip: z* should be in /usr/bin

[cacin]

Package: gzip
Followup-For: Bug #189252

this is now fixed thanks to usrmerge and #1059533

Bug#1066887: locales/locale-gen: Locales Cannot Copy from Locales in /usr/local/share/i18n/locales

[M. Buecher]

Package: locales
Version: 2.36-9+deb12u4
Severity: important
Tags: l10n
X-Debbugs-Cc: maddes+deb...@maddes.net

Dear Maintainer,

referencing a custom locale that resides in /usr/local/share/i18n/loaces/ via 
"copy" doesn't work.

`dpkg-reconfigure locales` gives the following error message:
en_GB.UTF-8@INTL...[error] cannot open locale definition file `en_US@INTL': No 
such file or directory

Both locales will get attached to the bug, so you can be reproduce.

   * What led up to the situation?

Created custom locales in /usr/local/share/i18n/locales/ and wanted
to copy from one those custome locales: en_GB@INTL shall copy LC_TIME from 
en_US@INTL.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Looked around and recognized that locale-gen doesn't pass any I18NPATH to 
localedef. So only the compiled-in single path /usr/share/i18n/locales/ is 
referenced.

   * What was the outcome of this action?

Referencing custom locales without I18NPATH does not work (see error message 
above).

   * What outcome did you expect instead?

Referencing a custom locale should work out of the box.

   * Workarounds?

This worked: `I18NPATH=/usr/local/share/i18n dpkg-reconfigure locales`

   * Possible solutions?

Option #1: Enhance `locale-gen` to set I18NPATH when calling localedef

TESTED and working, allows to set I18NPATH also from the outside.

/usr/sbin/locale-gen:
...
if [ -z "${I18NPATH:-}" ]; then
  if [ -d "${USER_LOCALES}" ]; then
I18NPATH="${USER_LOCALES%/locales}"
  fi
fi

echo "Generating locales (this might take a while)..."
while read -r locale charset; do
  ...
  I18NPATH="${I18NPATH}" localedef ...
  ...
done


Option #2: Enhance `localedef` upstream to allow collon separated list of paths 
via LOCSRCDIR macro

There are no changes since glibc 2.36 in function locfile_read() of 
locale/programs/locfile.c and no debian patches for this function.

Something like this should work (UNTESTED!):

int
locfile_read (struct localedef_t *result, const struct charmap_t *charmap)
{
...
  /* Test in the default directories.  */
  if (ldfile == NULL)
{
  char *locpath = LOCSRCDIR;
  const size_t pathlen = strlen (locpath);
  char locpathbuf[pathlen + 1];
  char path[strlen (filename) + 1 + pathlen];
  char *next;
  locpath = memcpy (locpathbuf, locpath, pathlen + 1);

  while (ldfile == NULL
 && (next = strsep (, ":")) != NULL)
{
  stpcpy (stpcpy (path, next), filename);

  ldfile = lr_open (path, locfile_hash);

  if (ldfile == NULL)
{
  stpcpy (stpcpy (stpcpy (path, next), "/"), filename);

  ldfile = lr_open (path, locfile_hash);
}
}
}
...


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_US.UTF-8@INTL, LC_CTYPE=en_US.UTF-8@INTL (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 locales depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc-bin   2.36-9+deb12u4
ii  libc-l10n  2.36-9+deb12u4

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/locales_to_be_generated: en_DE.UTF-8@INTL UTF-8, en_US.UTF-8 UTF-8, 
en_US.UTF-8@INTL UTF-8
* locales/default_environment_locale: en_US.UTF-8@INTL
comment_char %
escape_char /

% INTL English locale for US
% This is a modified copy of "en_US"
% Modifications done for internationally working people: ISO date, 24h clock, 
comma as decimal separator, A4 paper, metric system, etc.
% Most settings are either directly copied from en_US or from i18n
% Special cases are explicitly mentioned

% "en_US" is part of the GNU C Library and contains locale data.
% The Free Software Foundation does not claim any copyright interest
% in the locale data contained in this file.  The foregoing does not
% affect the license of the GNU C Library as a whole.  It does not
% exempt you from the conditions of the license if your use would
% otherwise be governed by that license.

LC_IDENTIFICATION
title  "INTL English locale for US (based on en_US)"
source "Maddes (based on the work of Free Software Foundation, Inc.)"
address"http:www.github.com//maddes-b//linux-stuff//;
contact""
email  ""
tel""
fax""
language   "American English"
territory  "United States"
revision   "1.0"
date   "2024-03-12"

category "i18n:2012";LC_IDENTIFICATION
category "i18n:2012";LC_CTYPE
category "i18n:2012";LC_COLLATE
category "i18n:2012";LC_TIME
category "i18n:2012";LC_NUMERIC
category "i18n:2012";LC_MONETARY

Bug#1066886: python-certbot-nginx: please remove python3-mock from the build dependencies

[Alexandre Detiste]

Source: python-certbot-nginx
Version: 2.9.0-1
Severity: normal

"mock" was merged a long time ago in the Python standard library
as "unittest.mock"; that's what this software uses.

Please remove the old build-dep from d/control.

Greetings,


debian/control:   python3-mock,

Bug#1063959: pandas and pytest 8

[Rebecca N. Palmer]

Control: reopen -1
Control: tags -1 pending
Control: tags 1066801 pending
Control: tags 1064384 pending

Sorry, that wasn't actually a fix, but what's now in Salsa should be.

Bug#1066885: libopenmpi3t64 hardcodes libpmix2 dependency

[Adrian Bunk]

Package: libopenmpi3t64
Version: 4.1.6-6
Severity: serious

Package: libopenmpi3t64
Version: 4.1.6-6
Depends: ..., libpmix2t64 (>= 5.0.1), ..., libpmix2

This is due to:

Package: libopenmpi3t64
Depends: ${shlibs:Depends}, ${misc:Depends}, libhwloc-plugins, libpmix2


This might have been added due to

openmpi (3.1.1.real-4) unstable; urgency=medium

  * Make libopenmpi3 pull in libpmix2 >= 3.0.0-1

 -- Alastair McKinstry   Wed, 18 Jul 2018 11:20:16 +0100

but now the manual dependency should just be dropped.

Bug#1066843: util-linux: --delete option does not work

[Chris Hofstaedtler]

Control: tags -1 + moreinfo

On Thu, Mar 14, 2024 at 11:11:30AM +0100, Francesco Potortì wrote:
> The man page for findmnt lists a --delete option which is necessary to me.  
> Unfortunately, findmnt says it does not have such option, s (I resorted to 
> using mount for that.
> 
> Either --delete should work for findmnt, or the man page should be amended to 
> remove the --delete option and ideally suggest using mount for those needing 
> it.

The man page I have says nothing about --delete.
It however lists --deleted (note the extra d).

Chris

Bug#1066884: python-fido2: please remove the old python3-mock build dependency

[Alexandre Detiste]

Source: python-fido2
Version: 1.1.2-2
Severity: normal

"mock" was merged as "unittest.mock" 
into the Python standard library years ago.

Please remove the extraneous python3-mock
build-dependency to enable removal of this
old library.

Greetings


tchet@brix /tmp/python-fido2 $ grep mock -r
debian/control:   python3-mock,

Bug#1066249: libmediascan: FTBFS: api_test.c:80:3: error: implicit declaration of function ‘gettimeofday’ [-Werror=implicit-function-declaration]

[gregor herrmann]

On Thu, 14 Mar 2024 21:16:51 +0200, Niko Tyni wrote:

> > Not going to upload as-is, as I hardly speak any C and don't really
> > know what I'm doing and this is more than adding a missing #include
> > or prototype and I don't understand the code.
> I assume you mean the '#define _mkdir mkdir' part? The rest
> seems straightforward.

Right, this _mkdir was the part I was mostly unsure about.
 
> AFAICS the code used to call mkdir(2) without the mode argument.
> A simple test [1] indicates that will just put random garbage there,
> so the resulting directory will have a different mode every time. Surely
> that was always buggy.

That was my assumption as well that this is all a bit, hm, broken.
 
> I'm not convinced that affected functions in test/test_defects.c
> or test/test_background.c ever get executed for us though?

I think they don't get executed but they lead to compile errors.

> In any case, your change
> 
>   +int _mkdir(const char *pathname)
>   +{
>   +mkdir(*pathname, 0775);
>   +}
> 
> is not quite correct: I think it should read something like
> 
>   int _mkdir(const char *pathname)
>   {
>   return mkdir(pathname, 0775)
>   }
> 
> to work properly.

Ha! Thanks, that's what I meant by "I don't really speak C", and
indeed I was wondering how exactly to express this :)
 
> But I think it would be easier to stick with the preprocessor and do
> 
> -#define _mkdir mkdir
> +#include 
> +#define _mkdir(x) mkdir((x), 0755)
> 
> instead.

Great.
 
> Hope this helps :)

It does, thank you!


Patch updated, package uploaded.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1066498: dh-make-perl: autopkgtest regression due to time_t transition

[gregor herrmann]

On Thu, 14 Mar 2024 18:40:27 +0200, Niko Tyni wrote:

> Sure we need to allow for libperl5.XX to stay future-proof. I was just
> thinking of hardcoding libperl5.38t64 as the (temporary) other option
> rather than using a generic libperl5.XXt64 name.
> But no worries :)

There were already for variables for getting the perl API version in
the script :)

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1066883: alg: ecdh-nist-p256: test failed on vector 2, err=-14

[Tj]

Source: linux
Severity: important

Same as: Bug #1061262

I've been seeing this with builds since 6.7 cycle started. It seems to
show up mostly for hosts with bluetooth hardware since the bluetooth
module depends on ecdh. The trace indicates ecdh_generic is still
loading when the test is attempted.

journalctl --grep 'alg: self-tests for ecdh-nist-p256' | 
  grep -- '-- Boot' |
  while read -r a b hash d; do
  journalctl --boot $hash | head -n 1 | 
  grep -oE 'version [^ ]+'
  done |
  sort -u

version 6.7.0-rc5+debian+tj
version 6.7.1+debian+tj
version 6.7.4+debian+tj
version 6.8.0+debian+tj

crypto algo self-tests 'alg: ecdh-nist-p256: test failed on vector 2, err=-14

-14 is "EFAULT 14 / Bad address */

and the log shows

Modules linked in: ecdh_generic(+) ...

where the "(+)" means module loading.

This only seems to occur on hosts with Bluetooth hardware and "bluetooth" 
module (requires ECDH) when those modules are in the initrd.img.

It feels like the self-tests are running before the module is fully loaded - in 
fact the tcrypt module (CONFIG_CRYPTO_TEST) isn't loaded according to "Modules 
linked in:" report and it isn't contained in the initrd.img so these tests seem 
to be occuring without it.

root@t300chi:/tmp/initrd# unmkinitramfs /boot/initrd.img-6.8.0+debian+tj .
root@t300chi:/tmp/initrd# ls
early  main
root@t300chi:/tmp/initrd# ls main/usr/lib/modules/6.8.0+debian+tj/kernel/crypto/
af_alg.ko  algif_skcipher.ko  async_tx  crc32c_generic.ko  crct10dif_common.ko  
crct10dif_generic.ko  ecc.ko  ecdh_generic.ko  xor.ko  xts.ko
root@t300chi:/tmp/initrd# ls 
main/usr/lib/modules/6.8.0+debian+tj/kernel/drivers/bluetooth/
btbcm.ko  btintel.ko  btmtk.ko  btrtl.ko  btusb.ko
root@t300chi:/tmp/initrd# ls 
main/usr/lib/modules/6.8.0+debian+tj/kernel/net/bluetooth/
bluetooth.ko
root@t300chi:/tmp/initrd# find  . /usr/lib/modules/6.8.0+debian+tj/kernel  
-type f -name '*tcrypt*'
/usr/lib/modules/6.8.0+debian+tj/kernel/crypto/tcrypt.ko.xz


Mar 14 06:30:29 t300chi kernel: alg: ecdh-nist-p256: test failed on vector 2, 
err=-14
Mar 14 06:30:29 t300chi kernel: alg: self-tests for ecdh-nist-p256 using 
ecdh-nist-p256-generic failed (rc=-14)
Mar 14 06:30:29 t300chi kernel: [ cut here ]
Mar 14 06:30:29 t300chi kernel: alg: self-tests for ecdh-nist-p256 using 
ecdh-nist-p256-generic failed (rc=-14)
Mar 14 06:30:29 t300chi kernel: WARNING: CPU: 0 PID: 197 at 
crypto/testmgr.c:5888 alg_test+0x42b/0x580
Mar 14 06:30:29 t300chi kernel: Modules linked in: ecdh_generic(+) ecc crc16 
sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_commo>
Mar 14 06:30:29 t300chi kernel: CPU: 0 PID: 197 Comm: cryptomgr_test Not 
tainted 6.8.0+debian+tj #158
Mar 14 06:30:29 t300chi kernel: Hardware name: ASUSTeK COMPUTER INC. 
T300CHI/T300CHI, BIOS T300CHI.209 04/18/2019
Mar 14 06:30:29 t300chi kernel: RIP: 0010:alg_test+0x42b/0x580
Mar 14 06:30:29 t300chi kernel: Code: 89 ea 48 89 ee 4c 89 f7 e8 d2 e8 ff ff 41 
89 c0 e9 36 fd ff ff 44 89 c1 48 89 ea 4c 89 e6 48 c7 c7 58 9c 2b 8a e8 b5 0>
Mar 14 06:30:29 t300chi kernel: RSP: 0018:a53a80627e08 EFLAGS: 00010282
Mar 14 06:30:29 t300chi kernel: RAX:  RBX: 1e00 
RCX: 
Mar 14 06:30:29 t300chi kernel: RDX: 0002 RSI: 0002 
RDI: 
Mar 14 06:30:29 t300chi kernel: RBP: 8e5241213800 R08: 0867 
R09: 000a
Mar 14 06:30:29 t300chi kernel: R10: 0001 R11: 20726f6620737473 
R12: 8e5241213880
Mar 14 06:30:29 t300chi kernel: R13: 0008 R14: 0078 
R15: 
Mar 14 06:30:29 t300chi kernel: FS:  () 
GS:8e535700() knlGS:
Mar 14 06:30:29 t300chi kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Mar 14 06:30:29 t300chi kernel: CR2: 7f389404ee24 CR3: 7761c001 
CR4: 003706f0
Mar 14 06:30:29 t300chi kernel: DR0:  DR1:  
DR2: 
Mar 14 06:30:29 t300chi kernel: DR3:  DR6: fffe0ff0 
DR7: 0400
Mar 14 06:30:29 t300chi kernel: Call Trace:
Mar 14 06:30:29 t300chi kernel:  
Mar 14 06:30:29 t300chi kernel:  ? alg_test+0x42b/0x580
Mar 14 06:30:29 t300chi kernel:  ? __warn+0x7d/0x130
Mar 14 06:30:29 t300chi kernel:  ? alg_test+0x42b/0x580
Mar 14 06:30:29 t300chi kernel:  ? report_bug+0x18d/0x1c0
Mar 14 06:30:29 t300chi kernel:  ? handle_bug+0x3c/0x70
Mar 14 06:30:29 t300chi kernel:  ? exc_invalid_op+0x13/0x60
Mar 14 06:30:29 t300chi kernel:  ? asm_exc_invalid_op+0x16/0x20
Mar 14 06:30:29 t300chi kernel:  ? alg_test+0x42b/0x580
Mar 14 06:30:29 t300chi kernel:  ? alg_test+0x42b/0x580
Mar 14 06:30:29 t300chi kernel:  ? finish_task_switch.isra.0+0x9b/0x2f0
Mar 14 06:30:29 t300chi kernel:  ? __schedule+0x3c7/0xb70
Mar 14 06:30:29 t300chi kernel:  ? _raw_spin_unlock_irqrestore+0x1e/0x40
Mar 14 

Bug#1066139: podman: Cannot create a network with dns_enabled

[Antoine Sirinelli]

On Wed, Mar 13, 2024 at 12:14:28PM +0200, Faidon Liambotis wrote:
> 1) Perhaps you installed podman with apt install --no-install-recommends?

Not the case.

> 2) Alternatively, perhaps you first set up podman without Netavark (e.g.
>before 4.0), and later upgraded to a newer version?

This is likely the case. This system was installed in 2020 and podman has been
installed for a while but I was not able to find the logs before last year...

>I don't think an automatic transition from the old stack to the new
>stack exists. A "podman system reset" should fix it; I'm not sure if
>there is a less intrusive way to do that. Perhaps we'll know more
>about upgrade paths with the 5.0 release, which is imminent.

podman system reset fixed it.

Thank you for your help,

Antoine

Bug#1018336: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy]

[Andreas Tille]

Hi Miriam,

Am Thu, Mar 14, 2024 at 08:33:13PM +0100 schrieb Miriam Ruiz:
> I am totally okay with team maintenance. Lots of thanks!!!

Updated to latest upstream which fixes the bug.

Thanks a lot for your quick response
Andreas.

-- 
http://fam-tille.de

Bug#1066882: bash: :: unrecognized history modifier

[Thorsten Glaser]

Package: bash
Version: 5.2.21-2
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I knew GNU bash had some issues with the exclamation mark,
but it’s even quoted here and still it weirdly fails:

bash$ echo "$BUILDUSERNAME:!:::"
bash: :: unrecognized history modifier

(This is from the pbuilder code to add the build user to
shadow, which I had to run by hand in a cowbuilder --login
chroot because I needed some manual work before the package
build and some packages refuse to be built by root.)


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k

Kernel: Linux 6.6.15-m68k (UP)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages bash depends on:
ii  base-files   13
ii  debianutils  5.17
ii  libc62.37-15.1
ii  libtinfo66.4+20240113-1

Versions of packages bash recommends:
pn  bash-completion  

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#1066110: tracker-extract: regular crash

[intrigeri]

Hi,

I see a similar crash every 2-4 seconds on my sid system since some recent
upgrade.

This looks like
https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/312.

I lack time to do this myself but it could be interesting to check if
the upstream fix resolves this for you:
https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516/diffs
… which I understand will be included in 3.7 stable.

Cheers,
-- 
intrigeri

Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

[Alan M Varghese]

Hello Mo,

May I address you Mo?

I am happy to co-maintain hyprland with you. :)

The ITP for hyprland[0] was created by werdahias@ who had created an
initial skeleton for the packaging a while ago. Under his advise,
I decided to de-vendor all of udis86, tracy and hyprland-protocols.
As far as I understand, the Debian policy recommends de-vendoring
over including files from other sources.

I have been working on this for a while and just uploaded them all
to mentors and created RFS for them. Currently I have completed
packaging hyprland and all its dependencies to the best of my ability.

Regarding the points you shared:
1. I wasn't sure what to do with tracy. I have however de-vendored
it and created an RFS for it[1]. But, I am unable to get the GPU
traces working on my AMD RX 6600 (for a debug build of Hyprland with
tracy enabled). I am not sure if this is because of my device or
something else. I have seen some discussion upstream that tracy's
GPU traces are not always reliable.

   Tracy seems to work fine, otherwise.

2. I have de-vendored udis86 too. The library and the included CLI
seems to run fine. Here is the RFS[2].

3. Again, I have separated hyprland-protocols and the RFS is here[3].

You can find the VCS for all hyprland related stuff I did, under the
NyxTrail namespace in salsa[4].

The packages all seem to run fine so far.

This is my first time packaging for Debian and any feedback is
welcome.

Let me know how you wish to proceed.

Regards,
Alan

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066873
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066870
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066868
[4] https://salsa.debian.org/NyxTrail

On 3/15/24 01:10, Mo Zhou wrote:

Hi Alan,

Thank you for your work!

I did not check the ITP bugs before we make overlapping efforts:
https://salsa.debian.org/debian/hyprlang
https://salsa.debian.org/debian/hyprland

I just rushed the two packages within a short time the last night.
They work properly on Sid with my laptop.

I have uploaded hyprlang to NEW without checking ITP
https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html

The hyprland is still pending as I've not yet finished
the debian/copyright part.

In terms of build depends of hyprland:
1. tracy is optional. USE_TRACY is by default off. We can build
    the package without tracy.
2. the udis86 is embedded in the upstream tarball as well.
    Maybe we can keep it embedded as udis86 is only needed by
    hyprland
3. hyprland-protocols is also embedded. I suppose it is ok
    to keep this specific project, instead of splitting the
    package to increase the required amount of work.

Shall we merge our work and co-maintain this?

On 3/14/24 14:46, Alan M Varghese wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

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

  * Package name : libhyprlang
    Version  : 0.5.0-1
    Upstream contact : vaxerski 
  * URL  : https://github.com/hyprwm/hyprlang
  * License  : LGPL-3+
  * Vcs  : https://salsa.debian.org/NyxTrail/hyprlang
    Section  : x11

The source builds the following binary packages:

   libhyprlang2 - Configuration language for Hyprland (library)
   libhyprlang-dev - Configuration language for Hyprland (development files)

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

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

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

   dget -x 
https://mentors.debian.net/debian/pool/main/libh/libhyprlang/libhyprlang_0.5.0-1.dsc

Changes for the initial release:

  libhyprlang (0.5.0-1) UNRELEASED; urgency=low
  .
    * Initial release. Closes: #1065352

Regards,

Bug#1065791: sleuthkit: FTBFS on arm{el,hf}: /usr/include/zlib.h:1840:5: error: unknown type name ‘off64_t’

[Gianfranco Costamagna]

control: tags -1 patch

from Steve Langasek, removing some ugly hacky defines in the code seems to work


cat fix-armhf-build.patch
Description:
   * Fix armhf builds by removing hack
Author: Steve Langasek 
Bug-Debian: https://bugs.debian.org/1065791
Last-Update: 2024-03-14

--- sleuthkit-4.12.1+dfsg.orig/tsk/base/tsk_base_i.h
+++ sleuthkit-4.12.1+dfsg/tsk/base/tsk_base_i.h
@@ -22,11 +22,12 @@
 
 /* Some Linux systems need LARGEFILE64_SOURCE and autoconf does

  * not define it, so we hack it here */
-#ifdef _LARGEFILE_SOURCE
+/*#ifdef _LARGEFILE_SOURCE
 #ifndef _LARGEFILE64_SOURCE
 #define _LARGEFILE64_SOURCE 1
 #endif
 #endif
+*/
 
 #include "tsk_base.h"

 #include "tsk_unicode.h"


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065806: pam: recent upgrade changes previous default umask

[Professor Jeebs]

Good Day,

I also noticed this change recently, and found it jarring, albeit mostly
cosmetic.  The notes in /etc/login.defs do imply that it is up to
administrators, who we know have differing opinions on all matters of
topics.  For example, I would like to keep the old USERGROUPS_ENAB set
to "yes", *and* to have a default umask of 022 (for reasons; even if
that does not make a lick of sense).  Also, I often do have multiple
users on my systems who belong to a single group (something like
"users").

I remember posting on systemd @ github about how they were choosing to
handle, or not handle values in /etc/login.defs--or, maybe something
else semi-related--at a time in ancient history.  The details, I do not
recall.  But, I do not blame, nor believe, the systemd project has
anything to do with this particular change.  Please correct me, if I am
wrong!  And, maybe I can even be convinced that one handling of umasks
is better than...

Here is how I am handling it now...

In the default .bashrc for *root*, ever since I can remember, I have had
a configuration line commented out, which allows setting the umask value
to 022 for root.  This is how it still behaves by default anyway, as
stated above.  However, I am thinking to go ahead and...

I prefer the way it is handled per user.  There is a related, commented
out, option in /etc/skel/.profile, which lands in new user directories,
which I have never touched the umask part until now.  I uncommented the
line to set the users' default umask settings to 022 and updated users
already on the system.

At your own risk, if you follow along further :)

It was fun to see and reset the permissions on files since the change,
with:

~$ find . -type f -perm 664

and, upon confirming these are (mostly) the new files that I would have
preferred to have different permissions (as before), reset them all
with:

~$ find . -type f -perm 664 -execdir chmod 644 '{}' '+'

(Note: wireplumber keeps some state files in my home folders at 664,
which I guess is just the way they want it.  Some other programs may
prefer different permissions and reset them, also.  We will see!)

So far, I have not inspected, nor determined, whether directory
permissions were affected in a way I might find jarring.

Lastly, I already have .bash_profile and .xsessionrc doing little else
than 'sourcing' .profile and setting a few variables where appropriate.
I don't SSH into the box very often, so I am unsure if the umask holds
in various other situations.

Just my two cents,

Professor Jeebs

Bug#1066850: don't hard-code the name of the shared library

[Christoph Biedl]

After getting some help in IRC, I guess the problem boils down to:

1. All architectures provide the t64 variant (libmagic1t64).
2. Some architectures no longer provide the old variant (libmagic1), for
   example armhf.
3. Therefore, the install dependency of python3-magic must be the t64 variant.

> and derive the name of the shared library package from the
> libmagic-dev package.

Now replacing one hardcoded binary library dependency with a different
one is not quite the brightest move as this will introduce work should
the libmagic ABI ever change (hasn't happened in 20 years but still).
So it was nicer to do this dynamically during build. That step however
is optional.

Do you have an idea, an existing solution how to do that?

So far I found two ways, and dislike both:

* Derive from apt-cache:

override_dh_gencontrol:
perl -MDebian::Debhelper::Dh_Lib -e \
'addsubstvar ("python3-magic", "misc:Depends", $$ARGV[0])' \
"$$(apt-cache show libmagic-dev | awk '($$1=="Depends:"){print 
$$2}' | head -n 1)"
dh_gencontrol $@

Querying the apt database from inside a package build feels like a layer
violation.

* Abuse dpkg-shlibdeps:

override_dh_gencontrol:
dpkg-shlibdeps -e /usr/bin/file -Tdebian/python3-magic.substvars
dh_gencontrol $@

(Some tweaks to debian/control needed as well.)

This also introduces an install dependency on libc6, and my gut feeling
tells me this was the point to make python3-magic arch:any.

So, is all this worth the efforts? FWIW, I maintain the libmagic
package as well, so being lazy now will just hurt me later.

Christoph


signature.asc
Description: PGP signature

Bug#1043465: reportbug: apt install produces errors when run from a non-existing directory

[Wesley Schwengle]

Control: reassign 1.21.22 debconf

On Fri, Aug 11, 2023 at 04:07:11PM +, t3atwv+9rzw960a1ydj0@cs.email wrote:
> Dear Maintainer,
> 
> It doesn't matter which package you try to install, I'm using 'hello' as an 
> example of a very simple package with no dependencies.
> 
> If you try to run an `apt install` command while you are in a directory that 
> has been deleted, you will get error messages.
> 
> Example command:
> $ mkdir /tmp/hello; cd /tmp/hello; rmdir /tmp/hello; sudo apt install hello
> 
> You get an output that includes these lines:
> sh: 0: getcwd() failed: No such file or directory
> sh: 0: getcwd() failed: No such file or directory
> sh: 0: getcwd() failed: No such file or directory
> sh: 0: getcwd() failed: No such file or directory
> sh: 0: getcwd() failed: No such file or directory
> cannot fetch initial working directory: No such file or directory at 
> /usr/sbin/dpkg-preconfigure line 73.
> cannot fetch initial working directory: No such file or directory at 
> /usr/sbin/dpkg-preconfigure line 159.
> 
> The package installs successfully, but the messages are still not something 
> the user should see.

This is actually a debconf bug as the warnings/errors are emitted by
/usr/sbin/dpkg-preconfigure.

I don't fully agree that this is a bug but I'll let the debconf folks decide
over that. I think it is quite useful to have this information in case things
would go wrong because being in a non-existent directory might not be a normal
situation.

The reproduction path can be slightly adjusted to:
mkdir /tmp/hello; cd /tmp/hello; rmdir /tmp/hello; sudo 
/usr/sbin/dpkg-preconfigure hello

I can verify that the behavior is present on bookworm and unstable.

Cheers,
Wesley

Bug#1066249: libmediascan: FTBFS: api_test.c:80:3: error: implicit declaration of function ‘gettimeofday’ [-Werror=implicit-function-declaration]

[Paul Gevers]

Hi Niko, gregor,

On 14-03-2024 8:16 p.m., Niko Tyni wrote:

[Paul: copying you for eyeballs as this seems to have been your pet
  package at some point :)]


I'm receiving the bugs of this package, but thanks. It is (or I fear 
was) a dependency of a package I still have the ambition to package one day.



On Thu, Mar 14, 2024 at 06:21:35PM +0100, gregor herrmann wrote:

Not going to upload as-is, as I hardly speak any C


Neither do I.


Hope this helps :)


I'll have a look next time I have both time and energy (hopefully within 
a week).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066881: RFS: anew/0.2-1 [ITP] -- Tool for adding new lines to files, skipping duplicates (program)

[aka oday]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : anew
   Version  : 0.2-1
   Upstream contact : m...@tomhudson.co.uk
 * URL  : https://github.com/tomnomnom/anew
 * License  : Expat
 * Vcs  : https://salsa.debian.org/marcos.rcarvalho/anew
   Section  : golang

The source builds the following binary packages:

  anew - Tool for adding new lines to files, skipping duplicates (program)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/anew/anew_0.2-1.dsc

Changes for the initial release:

 anew (0.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1063591)

Regards,

-- 
Marcos Rodrigues de Carvalho (aka oday) 

Bug#1036467: virtuoso-opensource: CVE-2023-31607 CVE-2023-31608 CVE-2023-31609 CVE-2023-31610 CVE-2023-31611 CVE-2023-31612 CVE-2023-31613 CVE-2023-31614 CVE-2023-31615 CVE-2023-31616 CVE-2023-31617 C

[Salvatore Bonaccorso]

Hi Andreas,

On Thu, Mar 14, 2024 at 03:22:58PM +0100, Andreas Beckmann wrote:
> Control: severity -1 important
> On Sun, 21 May 2023 20:43:40 +0200 Salvatore Bonaccorso 
> wrote:
> > Source: virtuoso-opensource
> > Version: 7.2.5.1+dfsg1-0.3
> > Severity: grave
> 
> Downgrading the severity since all CVEs are marked as no-dsa (minor issue).

This is actually orthogonal. We might indicate with a RC severity that
we think the next stable release should not ship with these issues
unfixed. And in fact the package was not in testing. 

Lowering the severity makes it actually re-enter testing next (well
actually once it is possible I guess as the migration is yet blocked).

Please reconsider the lowering of the severity with that information
(but I will not setting it back myself but rather open it for
discussion with the above and maybe maintainers will comment as well).

Regards,
Salvatore

Bug#1066880: rpcbind: FTBFS due to immutable chroot contains old libtirpc3

[Zixing Liu]

Package: rpcbind
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

This package won't be able to build when the old libtirpc3 is installed in
the immutable rootfs of the buildd container system.

I have bumped the version requirement of libtirpc-dev to force an upgrade
so that the package will build.

  * d/control: raise libtirpc-dev requirement to 1.3.4+ds-1.1 so that
the package builds can build with the correct libtirpc3t64 library


Thanks for considering the patch.


-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-25-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru rpcbind-1.2.6/debian/control rpcbind-1.2.6/debian/control
--- rpcbind-1.2.6/debian/control2024-02-29 02:33:05.0 -0700
+++ rpcbind-1.2.6/debian/control2024-03-14 09:03:02.0 -0600
@@ -1,10 +1,10 @@
 Source: rpcbind
 Section: net
 Priority: optional
 Maintainer: Josue Ortega 
 Build-Depends: debhelper-compat (= 13),
  pkg-config,
- libtirpc-dev (>= 1.0.2),
+ libtirpc-dev (>= 1.3.4+ds-1.1),
  libwrap0-dev,
  libsystemd-dev [linux-any]
 Standards-Version: 4.6.2

Bug#1036908: expect: Broken use of \c in man page

[Helge Kreutzmann]

Hello Sergei,
Am Wed, Mar 13, 2024 at 04:02:35PM +0300 schrieb Sergei Golovan:
> Sorry for the late reply. It seems to me that you've reported this bug
> to the wrong package. mkpasswd(1) where you've found the bug is from
> the whois package, and not from the expect one. I'm reassigning it.

Yes, you are right.

Thanks for handling.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1036826: Please start handling \c

[Helge Kreutzmann]

Hello Martin,
Am Sun, Mar 10, 2024 at 10:14:20PM +0100 schrieb Martin Quinson:
> Instead, I'd appreciate if you could do a merge request with a test file, 
> along
> with the expected output. It'd save me the time to dig into the discussion of
> this bug. 
> 
> I'm not saying that I won't fix it w/o this test case. I'm just saying that
> providing a test case is a better approach to speedup the fix than severity
> abuse.

I hope explaining the test file in this bug is fine as well, because
I'm not sure what to do exactly merge and how.

The test case is groff(1) as it is in Debian unstable:

$ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim 
--option generated --option 
untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,UNINDENT,UN,a.RE,\|"
 --option unknown_macros=untranslated --master groff.1 -M utf-8 -p test.pot
groff.1:2279: (po4a::man)
  Escape sequence \c encountered. This is not completely
  handled yet.

And there is no output.

If I do a crude preprocessing, it kind of works:

$ cat groff.1 | perl -p -e 's/\\c\n//' > groff.test.1
$ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim 
--option generated --option 
untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,UNINDENT,UN,a.RE,\|"
 --option unknown_macros=untranslated --master groff.test.1 -M utf-8 -p test.pot
$ wc -l test.pot
3157 test.pot

I hope this helps you working on this, together with the discussion in
this bug.

Thanks for your support!

Greetings

  Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1066879: rpyc: CVE-2024-27758

[Salvatore Bonaccorso]

Source: rpyc
Version: 5.3.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/tomerfiliba-org/rpyc/issues/551
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rpyc.

CVE-2024-27758[0]:
| In RPyC before 6.0.0, when a server exposes a method that calls the
| attribute named __array__ for a client-provided netref (e.g.,
| np.array(client_netref)), a remote attacker can craft a class that
| results in remote code execution.


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-2024-27758
https://www.cve.org/CVERecord?id=CVE-2024-27758
[1] https://github.com/tomerfiliba-org/rpyc/issues/551
[2] 
https://github.com/tomerfiliba-org/rpyc/security/advisories/GHSA-h5cg-53g7-gqjw

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1066877: tomcat10: CVE-2024-23672

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for tomcat10.

CVE-2024-23672[0]:
| Denial of Service via incomplete cleanup vulnerability in Apache
| Tomcat. It was possible for WebSocket clients to keep WebSocket
| connections open leading to increased resource consumption.This
| issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from
| 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0
| through 8.5.98.  Users are recommended to upgrade to version
| 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the 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-2024-23672
https://www.cve.org/CVERecord?id=CVE-2024-23672
[1] https://lists.apache.org/thread/cmpswfx6tj4s7x0nxxosvfqs11lvdx2f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1066878: tomcat10: CVE-2024-24549

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for tomcat10.

CVE-2024-24549[0]:
| Denial of Service due to improper input validation vulnerability for
| HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request,
| if the request exceeded any of the configured limits for headers,
| the associated HTTP/2 stream was not reset until after all of the
| headers had been processed.This issue affects Apache Tomcat: from
| 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from
| 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.  Users are
| recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or
| 8.5.99 which fix the 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-2024-24549
https://www.cve.org/CVERecord?id=CVE-2024-24549
[1] https://lists.apache.org/thread/4c50rmomhbbsdgfjsgwlb51xdwfjdcvg

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1061493: consolekit: install PAM module and udev files into /usr

[Mark Hindley]

Control: notfound -1 1.2.6-3

On Wed, Mar 13, 2024 at 10:40:40PM +0100, Andreas Beckmann wrote:
> Followup-For: Bug #1061493
> Control: found -1 1.2.6-3.1~exp1
> Control: severity -1 serious
> Control: tag -1 ftbfs
> 
> This change causes consolekit2 to to FTBFS in experimental:

Indeed. As it was an NMU, I think the etiquette is for the NMUer to fix.

In sid consolekit2 still builds cleanly. Therefore, marking notfound there.

Michael, perhaps you would fix your NMU, or provide a better patch?

Thanks

Mark

Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

[Mo Zhou]

Hi Alan,

Thank you for your work!

I did not check the ITP bugs before we make overlapping efforts:
https://salsa.debian.org/debian/hyprlang
https://salsa.debian.org/debian/hyprland

I just rushed the two packages within a short time the last night.
They work properly on Sid with my laptop.

I have uploaded hyprlang to NEW without checking ITP
https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html

The hyprland is still pending as I've not yet finished
the debian/copyright part.

In terms of build depends of hyprland:
1. tracy is optional. USE_TRACY is by default off. We can build
   the package without tracy.
2. the udis86 is embedded in the upstream tarball as well.
   Maybe we can keep it embedded as udis86 is only needed by
   hyprland
3. hyprland-protocols is also embedded. I suppose it is ok
   to keep this specific project, instead of splitting the
   package to increase the required amount of work.

Shall we merge our work and co-maintain this?

On 3/14/24 14:46, Alan M Varghese wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

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

  * Package name : libhyprlang
Version  : 0.5.0-1
Upstream contact : vaxerski 
  * URL  : https://github.com/hyprwm/hyprlang
  * License  : LGPL-3+
  * Vcs  : https://salsa.debian.org/NyxTrail/hyprlang
Section  : x11

The source builds the following binary packages:

   libhyprlang2 - Configuration language for Hyprland (library)
   libhyprlang-dev - Configuration language for Hyprland (development files)

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

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

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

   dget -x 
https://mentors.debian.net/debian/pool/main/libh/libhyprlang/libhyprlang_0.5.0-1.dsc

Changes for the initial release:

  libhyprlang (0.5.0-1) UNRELEASED; urgency=low
  .
* Initial release. Closes: #1065352

Regards,

Bug#1066876: RFS: hyprland/0.36.0+ds-1 [ITP] -- Dynamic tiling Wayland compositor

[Alan M Varghese]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

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

 * Package name : hyprland
   Version  : 0.36.0+ds-1
   Upstream contact : https://github.com/hyprwm/Hyprland/issues
 * URL  : https://hyprland.org
 * License  : BSD-3-Clause, MIT
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprland
   Section  : x11

The source builds the following binary packages:

  hyprland - Dynamic tiling Wayland compositor
  hyprland-backgrounds - Set of backgrounds packaged with the hyprland Wayland 
compositor
  hyprland-dev - Development files for Hyprland

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hyprland/hyprland_0.36.0+ds-1.dsc

Changes for the initial release:

 hyprland (0.36.0+ds-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1040971
   * The subprojects udis86, tracy and hyprland-protocols have been
 devendored. The source is patched to support this devendoring.
   * The subproject wlroots cannot be devendored. hyprland versions depend on
 a specific commit of the wlroots project and upstream cannot does not
 recommend using any version. So, wlroots is included in this package for
 Debian, with the following changes:
 * The library 'libwlroots.so.13032' that is generated by the project is
   moved to a "private" library directory under usr/lib/hyprland.
 * RPATH is updated so that hyprland links correctly to the library in the
   modified path

Regards,
-- 
  Alan M Varghese

Bug#1018336: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy]

[Miriam Ruiz]

I am totally okay with team maintenance. Lots of thanks!!!

Hugs,
Miry

El jue, 14 mar 2024 a las 19:18, Andreas Tille () escribió:
>
> Hi Miriam,
>
> gentle ping about this.  I remember for cycle and pcalendar you was fine
> with team maintenance.  So I assume in this case you are as well.  If
> we do not hear from you in the next two weeks we will assume agreement.
>
> Kind regards
>Andreas.
>
> - Weitergeleitete Nachricht von Andreas Tille  -
>
> Date: Tue, 27 Feb 2024 14:48:21 +0100
> From: Andreas Tille 
> To: Miriam Ruiz 
> Subject: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting 
> change in DPT policy]
>
> Hi Miriam,
>
> as you can read below I doubt that the situation in several packages is
> the interpretation of "weak" team maintenance if the Maintainer field is
> set to a person.  In the case of your package deap I would guess you
> are OK if I would swap these fields in a potential upload of the new
> upstream version (which might potentially fix
>#1018336 deap: build-depends on python3-nose or uses it for autopkgtest
> )
> Would you mind if I would do so?
>
> Kind regards
> Andreas.
>
> - Weitergeleitete Nachricht von Andreas Tille  -
>
> Date: Tue, 27 Feb 2024 09:05:44 +0100
> From: Andreas Tille 
> To: Debian Python 
> Subject: Suggesting change in DPT policy
>
> Hi,
>
> I became more deeply involved into DPT since 2022 as a consequence of
> the suggestion for transfering several Debian Med/Science packages to
> DPMT[1][2].  I happily followed this suggestion and moved >30 packages
> from the Blends teams to DPT.  I was happy with this move since it makes
> sense.
>
> Recently we received lots of testing removal warnings in those Blends
> teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations.  So
> I did what I usually do in those teams:  I dedicated quite some time in
> team wide bug hunting.  That way I squashed about 50 bugs on packages
> where I was not in Uploaders.  When doing so I usually run
> routine-update on the package which basically streamlines packaging to
> latest standards including calling Janitor tools which are so far
> accepted inside DPT.
>
> I probably should have reviewed the DPT policy on Maintainership[3] more
> carefully. In other teams, it's common for the Maintainer to be set to
> the team, so I assumed it was just an oversight when I made this
> change[4] when touching the package to fix RC bug #1058177.  However, I
> I was pointed immediately about the fact that I was mistaken according
> to the current DPT policy.  I apologize for this.  However, the wording
> of the comment on my commit was discouraging, especially considering I
> was a volunteer who had fixed a critical bug.  Because of this, I
> decided to focus my efforts on fixing other critical bugs for the
> moment.  If the comment had started with a 'Thanks for fixing the
> critical bug, but...' I likely would have corrected my mistake quickly.
> The lack of respect from my teammate simply made me prioritize my time
> on other issues that are more visible to our users.  I wonder whether I
> should propose another change to the policy about maintaining a kind and
> polite language inside the team - but that's a different thing.
>
> While I applied the patch for another RC bug (#1063443) after >2 weeks
> which triggered a RC bug in reportbug I remembered the "keep the
> maintainer" policy.  But I kept on doing Janitor like changes since
> finally the package is maintained in a team where Janitor is accepted.
> When doing so I failed the phrase "please contact the Maintainer for the
> green light."  I apoligize for this again.  The response was another
> volunteer-demotivating private mail (thus no quote) which also was
> lacking the "Thanks for fixing"-phrase and degrading my changes as
> "frivolous".
>
> So far what happened (seen from my possibly biased perspective).
>
> Why do I like to change the policy?
>
> The current wording provides some means to stop volunteer team members
> helping out moving forward to speed up migrations and fix Debian wide
> dependencies.  It hides team maintained packages from a common BTS
> view.  When pointing my browser to
> https://bugs.debian.org/team+pyt...@tracker.debian.org
> I currently see 1339 open bugs (calculated by [UDD1]).  This hides
> another 309 [UDD2] bugs (>18% of team bugs) from our sight.  To work
> around this flaw I used an UDD query to find relevant Python3.12 bugs.
>
> When I think twice about the wording
>Team in Uploaders is a weak statement of collaboration.[3]
> I personally consider it a statement of *no* collaboration (which fits
> the wording of the responses I've got).
>
> How can a team member for instance find another RC bug #1009424?  Just
> from reading the bug report it is pretty easy to fix but does not
> feature any response in BTS.  I came across this while looking into
> Cython 3.0 bugs.  The same source package (basemap) that had the open
> Cython bug 

Bug#1066264: cdrkit: diff for NMU version 9:1.1.11-3.5

[Steve McIntyre]

Thanks! If you think this is a good bugfix, please go ahead and upload
straight to unstable.

On Thu, Mar 14, 2024 at 09:55:13PM +0500, Andrey Rakhmatullin wrote:
>Control: tags 1066264 + patch
>Control: tags 1066264 + pending
>
>Dear maintainer,
>
>I've prepared an NMU for cdrkit (versioned as 9:1.1.11-3.5) and
>uploaded it to DELAYED/4. Please feel free to tell me if I
>should delay it longer.
>
>Regards.
>
>
>-- 
>WBR, wRAR

>diff -Nru cdrkit-1.1.11/debian/changelog cdrkit-1.1.11/debian/changelog
>--- cdrkit-1.1.11/debian/changelog 2022-06-24 19:56:39.0 +0500
>+++ cdrkit-1.1.11/debian/changelog 2024-03-14 21:53:13.0 +0500
>@@ -1,3 +1,10 @@
>+cdrkit (9:1.1.11-3.5) unstable; urgency=medium
>+
>+  * Non-maintainer upload.
>+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066264).
>+
>+ -- Andrey Rakhmatullin   Thu, 14 Mar 2024 21:53:13 +0500
>+
> cdrkit (9:1.1.11-3.4) unstable; urgency=low
> 
>   * Non-maintainer upload.
>diff -Nru cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch 
>cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch
>--- cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch   
>1970-01-01 05:00:00.0 +0500
>+++ cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch   
>2024-03-14 21:50:53.0 +0500
>@@ -0,0 +1,29 @@
>+Description: Add missing header includes.
>+Author: Andrey Rakhmatullin 
>+Bug-Debian: https://bugs.debian.org/1066264
>+Last-Update: 2024-03-14
>+
>+Index: cdrkit-1.1.11/genisoimage/genisoimage.c
>+===
>+--- cdrkit-1.1.11.orig/genisoimage/genisoimage.c
> cdrkit-1.1.11/genisoimage/genisoimage.c
>+@@ -54,6 +54,7 @@
>+ #include 
>+ #include "match.h"
>+ #include "exclude.h"
>++#include "checksum.h"
>+ #include /* For UNICODE translation */
>+ #include 
>+ #ifdef UDF
>+Index: cdrkit-1.1.11/genisoimage/jte.c
>+===
>+--- cdrkit-1.1.11.orig/genisoimage/jte.c
> cdrkit-1.1.11/genisoimage/jte.c
>+@@ -27,6 +27,7 @@
>+ #include "ifo_read.h"
>+ #include "endianconv.h"
>+ #include "checksum.h"
>++#include "md5.h"
>+ #endif
>+ #ifdef APPLE_HYB
>+ #include 
>diff -Nru cdrkit-1.1.11/debian/patches/series 
>cdrkit-1.1.11/debian/patches/series
>--- cdrkit-1.1.11/debian/patches/series2022-05-25 07:57:10.0 
>+0500
>+++ cdrkit-1.1.11/debian/patches/series2024-03-14 21:48:02.0 
>+0500
>@@ -4,3 +4,4 @@
> add-efi-boot.patch
> gcc10.patch
> fix_format-security.patch
>+fix-implicit-function-declaration.patch



-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#1066249: libmediascan: FTBFS: api_test.c:80:3: error: implicit declaration of function ‘gettimeofday’ [-Werror=implicit-function-declaration]

[Niko Tyni]

[Paul: copying you for eyeballs as this seems to have been your pet
 package at some point :)]

On Thu, Mar 14, 2024 at 06:21:35PM +0100, gregor herrmann wrote:
> On Wed, 13 Mar 2024 12:41:10 +0100, Lucas Nussbaum wrote:

> > > test_background.c: In function ‘test_background_api’:
> > > test_background.c:12:16: error: implicit declaration of function ‘mkdir’; 
> > > did you mean ‘_mkdir’? [-Werror=implicit-function-declaration]
> > >12 | #define _mkdir mkdir

> I've pushed a patch to git which make the package compile without
> errors.
> 
> Not going to upload as-is, as I hardly speak any C and don't really
> know what I'm doing and this is more than adding a missing #include
> or prototype and I don't understand the code.

I assume you mean the '#define _mkdir mkdir' part? The rest
seems straightforward.

AFAICS the code used to call mkdir(2) without the mode argument.
A simple test [1] indicates that will just put random garbage there,
so the resulting directory will have a different mode every time. Surely
that was always buggy.

I'm not convinced that affected functions in test/test_defects.c
or test/test_background.c ever get executed for us though? They have
unpatched horrific things like

  const char *test_path = "C:\\Siojej3";

  const char start_dir[] = "C:\\logitest";

In any case, your change

  +int _mkdir(const char *pathname)
  +{
  +mkdir(*pathname, 0775);
  +}

is not quite correct: I think it should read something like

  int _mkdir(const char *pathname)
  {
  return mkdir(pathname, 0775)
  }

to work properly.

But I think it would be easier to stick with the preprocessor and do

-#define _mkdir mkdir
+#include 
+#define _mkdir(x) mkdir((x), 0755)

instead.

Hope this helps :)

[1] echo 'int main(void) { mkdir("ttt"); }' | gcc -xc - && strace -e mkdir 
./a.out
-- 
Niko

Bug#1066875: devscripts: debsign tries to parse gpg version from human-readable output, should use machine-readable output

[Daniel Kahn Gillmor]

Package: devscripts
Version: 2.23.7
Tags: patch

(this is also
https://salsa.debian.org/debian/devscripts/-/merge_requests/394)

debsign currently tries to determine the version of gpg by parsing the
human-readable output of `gpg --version`.

For use in scripts and other code, the GnuPG project prefers the use
of machine-readable output, and has offered `--with-colons
--list-config` for many versions (back at least to 1.3.5 according to
/usr/share/doc/gnupg/DETAILS.gz).  That form of invocation produces a
lot of detail, including the actual version number:

cfg:version:2.2.40

This mode of output is what is used by libgpgme to determine the
version of gpg, so it is likely to remain stable and parseable.

The attached patch converts debsign to use the machine-parseable format,
rather than the human-readable format.

This issue came up when experimenting with sequoia-chameleon-gnupg,
which produces a human-readable string that doesn't match what debsign
was checking for.
(https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/61).
they're fixing that now in the chameleon upstream, but it seems like
debsign should be using the more robust approach anyway.

Thanks for maintaining devscripts!

--dkg

From 6bed35a535962534883a5aa233cbbcbfc7b15624 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Thu, 14 Mar 2024 14:10:59 -0400
Subject: [PATCH] debsign: check gpg version with machine-parseable format

debsign currently tries to determine the version of gpg by parsin the
human-readable output of `gpg --version`.

For use in scripts and other code, the GnuPG project prefers the use
of machine-readable output, and has offered `--with-colons
--list-config` for many versions (back at least to 1.3.5 according to
/usr/share/doc/gnupg/DETAILS.gz).  That form of invocation produces a
lot of detail, including the actual version number:

cfg:version:2.2.40

This mode of output is what is used by libgpgme to determine the
version of gpg, so it is likely to remain stable and parseable.

This change converts debsign to use the machine-parseable format,
rather than the human-readable format.
---
 scripts/debsign.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/debsign.sh b/scripts/debsign.sh
index 15b0dfc2..cc4d31ab 100755
--- a/scripts/debsign.sh
+++ b/scripts/debsign.sh
@@ -170,7 +170,7 @@ signfile() {
 ASCII_SIGNED_FILE="${UNSIGNED_FILE}.asc"
 (cat "$file" ; echo "") > "$UNSIGNED_FILE"
 
-gpgversion=$($signcommand --version | head -n 1 | cut -d' ' -f3)
+gpgversion=$($signcommand --with-colons --list-config | awk -F: '/^cfg:version:/ { print $3; exit }')
 gpgmajorversion=$(echo $gpgversion | cut -d. -f1)
 gpgminorversion=$(echo $gpgversion | cut -d. -f2)
 
-- 
2.43.0



signature.asc
Description: PGP signature

Bug#1066874: miniupnpd-nftables: nft_init.sh clobbers all other FORWARD table rules by changing policy to deny

[Guyang Mao]

Package: miniupnpd-nftables
Version: 2.3.4-1
Severity: important

Dear Maintainer,

I've changed my system to use nftables for firewall rules and found out that 
miniupnpd-nftables
clobbered everything else on FORWARD.

(specifically, docker containers)

Looking at all the rules and nft_init.sh, it seems like creating the forward 
table for miniupnpd
and setting the default policy to deny breaks everything.  Changing the default 
policy to accept
makes everything work again.



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

Kernel: Linux 6.1.0-9-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 miniupnpd-nftables depends on:
ii  libc6   2.37-15.1
ii  libmnl0 1.0.5-2
ii  libnftnl11  1.2.6-2
ii  miniupnpd   2.3.4-1

miniupnpd-nftables recommends no packages.

miniupnpd-nftables suggests no packages.

-- Configuration Files:
/etc/miniupnpd/nft_init.sh changed:
. "$(dirname "$0")/miniupnpd_functions.sh"
$NFT --check list table inet $TABLE > /dev/null 2>&1
if [ $? -eq "0" ]
then
echo "Table $TABLE already exists"
exit 0
fi
echo "Creating nftables structure"
cat > /tmp/miniupnpd.nft <> /tmp/miniupnpd.nft <> /tmp/miniupnpd.nft <

Bug#1066872: mozjs102: Fails to build with Python 3.12

[Jeremy Bícha]

Source: mozjs102
Version: 102.15.1-3
Severity: serious
Tags: ftbfs sid
X-Debbugs-CC: c...@packages.debian.org
Control: affects -1 src:cjs

mozjs102 fails to build with Python 3.12 as default. We fixed similar
issues with mozjs115. Could we please convince cjs to switch to
mozjs115?

https://launchpad.net/ubuntu/+source/mozjs102/102.15.1-3

Thank you,
Jeremy Bícha

Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler

[Alan M Varghese]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

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

 * Package name : tracy
   Version  : 0.10+ds-1
   Upstream contact : Bartosz Taudul 
 * URL  : https://github.com/wolfpld/tracy/
 * License  : Expat, Expat or Unlicense, BSD-2-Clause, BSD-3-clause, 
BSD-3-Clause, Zlib, Unlicense
 * Vcs  : https://salsa.debian.org/NyxTrail/tracy
   Section  : devel

The source builds the following binary packages:

  libtracyclient0.10.0 - Hybrid frame and sampling profiler (library)
  libtracy-dev - Hybrid frame and sampling profiler (development files)
  tracy-profiler - Hybrid frame and sampling profiler (profiler application)
  tracy-capture - Hybrid frame and sampling profiler (capture application)
  tracy-csvexport - Hybrid frame and sampling profiler (csvexport application)
  tracy-doc - Hybrid frame and sampling profiler (documentation)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tracy/tracy_0.10+ds-1.dsc

Changes for the initial release:

 tracy (0.10+ds-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1063442
   * This program includes source files from many other open source
 projects.
   * Of these zstd has been devendored.
   * TODO: devendor imgui, nfd, dtl

Regards,
-- 
  Alan M Varghese

Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

[Alan M Varghese]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

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

 * Package name : libhyprlang
   Version  : 0.5.0-1
   Upstream contact : vaxerski 
 * URL  : https://github.com/hyprwm/hyprlang
 * License  : LGPL-3+
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprlang
   Section  : x11

The source builds the following binary packages:

  libhyprlang2 - Configuration language for Hyprland (library)
  libhyprlang-dev - Configuration language for Hyprland (development files)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libh/libhyprlang/libhyprlang_0.5.0-1.dsc

Changes for the initial release:

 libhyprlang (0.5.0-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1065352

Regards,
-- 
  Alan M Varghese

Bug#1066870: RFS: libudis86/0~20221013-1 [ITP] -- Disassembler for x86 and x86-64 class ISA

[Alan M Varghese]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

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

 * Package name : libudis86
   Version  : 0~20221013-1
   Upstream contact : https://github.com/canihavesomecoffee/udis86/issues
 * URL  : https://github.com/canihavesomecoffee/udis86
 * License  : __AUTO_PERMISSIVE__, BSD-2-Clause, __UNKNOWN__
 * Vcs  : https://salsa.debian.org/NyxTrail/udis86
   Section  : misc

The source builds the following binary packages:

  libudis86-0 - Disassembler for x86 and x86-64 class ISA (library)
  libudis86-dev - Disassembler for x86 and x86-64 class ISA (development files)
  udcli - Disassembler for x86 and x86-64 class ISA (cli)
  libudis86-doc - Disassembler for x86 and x86-64 class ISA (documentation)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libudis86/libudis86_0~20221013-1.dsc

Changes for the initial release:

 libudis86 (0~20221013-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1061940
   * This packaging is based on the fork
 https://github.com/canihavesomecoffee/udis86
 which includes "fixes and additions" from other forks.
   * The latest upstream release is v1.7.2 made on Sep 2, 2013. This build is
 however, based on the latest commit #5336633, made on Oct 13, 2022
   * Created a man page for udcli based on information from '--help' and
 additional information from the project's README.

Regards,
-- 
  Alan M Varghese

Bug#1066869: RFS: hyprpaper/0.6.0-1 [ITP] -- Wallpaper utility for Hyprland

[Alan M Varghese]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

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

 * Package name : hyprpaper
   Version  : 0.6.0-1
   Upstream contact : vaxerski 
 * URL  : https://github.com/hyprwm/hyprpaper
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprpaper
   Section  : x11

The source builds the following binary packages:

  hyprpaper - Wallpaper utility for Hyprland

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hyprpaper/hyprpaper_0.6.0-1.dsc

Changes for the initial release:

 hyprpaper (0.6.0-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1065699
   * Included a simple man page for hyprpaper (uses pandoc for building).

Regards,
-- 
  Alan M Varghese

Bug#1066868: RFS: hyprland-protocols/0.2~20230811-1 [ITP] -- Wayland protocol extensions for Hyprland

[Alan M Varghese]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear Mentors,

I am looking for a sponsor for my package "hyprland-protocols":

 * Package name : hyprland-protocols
   Version  : 0.2~20230811-1
   Upstream contact : vaxerski 
 * URL  : https://github.com/hyprwm/hyprland-protocols
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprland-protocols
   Section  : x11

The source builds the following binary packages:

  hyprland-protocols - Wayland protocol extensions for Hyprland

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

  https://mentors.debian.net/package/hyprland-protocols/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hyprland-protocols/hyprland-protocols_0.2~20230811-1.dsc

Changes for the initial release:

 hyprland-protocols (0.2~20230811-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1051806
   * This build is based on a specific upstream commit of hyprland-protocols.
 hyprland depends on commit #0c2ce70 of hyprland-protocols. The latest
 release of hyprland-protocols is v0.2 which is behind by a few commits.

Regards,
-- 
  Alan M Varghese

Bug#1066867: gnome-tweaks: Starting fails with TypeError

[Danial Behzadi]

Package: gnome-tweaks
Version: 46~beta-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: dani.be...@ubuntu.com

Dear Maintainer,

GNOME Tweaks 46~beta-1 fails to start with error:

```
Traceback (most recent call last):
  File "/usr/bin/gnome-tweaks", line 99, in 
from gtweak.app import GnomeTweaks
  File "/usr/lib/python3/dist-packages/gtweak/app.py", line 13, in 
from gtweak.tweakview import Window
  File "/usr/lib/python3/dist-packages/gtweak/tweakview.py", line 20, in 

from gtweak.tweaks.tweak_group_startup import TWEAK_GROUP as 
StartupApplicationTweaks
  File "/usr/lib/python3/dist-packages/gtweak/tweaks/tweak_group_startup.py", 
line 347, in 
TWEAK_GROUP = AutostartTweakGroup()
  ^
  File "/usr/lib/python3/dist-packages/gtweak/tweaks/tweak_group_startup.py", 
line 243, in __init__
self._setup_startup_app_row()
  File "/usr/lib/python3/dist-packages/gtweak/tweaks/tweak_group_startup.py", 
line 269, in _setup_startup_app_row
app_row = _StartupAppRowTweak(dfile)
  ^^
  File "/usr/lib/python3/dist-packages/gtweak/tweaks/tweak_group_startup.py", 
line 191, in __init__
app_icon = Gtk.Image.new_from_icon_name("image-missing", Gtk.IconSize.LARGE)
   ^
TypeError: Gtk.Image.new_from_icon_name() takes exactly 1 argument (2 given)
```

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fa_IR.UTF-8, LC_CTYPE=fa_IR.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 gnome-tweaks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  gir1.2-adw-1 1.5~beta-1
ii  gir1.2-gdesktopenums-3.0 46~beta-3
ii  gir1.2-glib-2.0  1.78.1-15
ii  gir1.2-gnomedesktop-4.0  44.0-2+b1
ii  gir1.2-gtk-4.0   4.12.5+ds-3
ii  gir1.2-gudev-1.0 238-3
ii  gir1.2-notify-0.70.8.3-1
ii  gir1.2-pango-1.0 1.52.0+ds-1
ii  gnome-settings-daemon46~beta-2
ii  gnome-shell-common   44.9-1
ii  gsettings-desktop-schemas46~beta-3
ii  mutter-common44.8-3
ii  python3  3.11.6-1
ii  python3-gi   3.47.0-3
ii  user-session-migration   0.4.1

gnome-tweaks recommends no packages.

Versions of packages gnome-tweaks suggests:
ii  gnome-shell-extension-prefs  44.9-1

-- no debconf information

Bug#1066827: foot: mouse-click results in sequence 0;45;9M0;45;9m, displayed at the prompt

[Veganester]

Hi,

"after a while" means: when i did use vi.

Meanwhile it is clear  this was the reason. Simply starting vi in a foot
terminal, without a file, and immediately returning to the shell caused
that behaviour.

I could stop it by removing my /etc/vim/vimrc.local file.
Content of that file was
syntax off
set mouse=
set ttymouse=

This file was a relict of working with x-server it is not any more needed
with sway.

Sorry for the inconvenience,

Johann

On Thu, 14 Mar 2024 16:35:07 +0100 Birger Schacht  wrote:
> Hi,
>
>
> can you clarify what "after a while" means? I can not reproduce the
> behavior and I'm using foot all the time...
> Do you have a custom foot configuration?
>
> cheers,
> Birger
>
> On 3/14/24 12:06 AM, Johann Hoermann wrote:
> > Dear Maintainer,
> >
> > when i do a mouse-click in a just opened foot terminal, it
highlights the text under the mouse-pointer which is the expected behaviour.
> >
> > After a while, instead of highlighting, a new mouse-click results
in a sequence 0;45;9M0;45;9m being displayed at the shell prompt.
>
>

Bug#1018336: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy]

[Andreas Tille]

Hi Miriam,

gentle ping about this.  I remember for cycle and pcalendar you was fine
with team maintenance.  So I assume in this case you are as well.  If
we do not hear from you in the next two weeks we will assume agreement.

Kind regards
   Andreas.

- Weitergeleitete Nachricht von Andreas Tille  -

Date: Tue, 27 Feb 2024 14:48:21 +0100
From: Andreas Tille 
To: Miriam Ruiz 
Subject: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting 
change in DPT policy]

Hi Miriam,

as you can read below I doubt that the situation in several packages is
the interpretation of "weak" team maintenance if the Maintainer field is
set to a person.  In the case of your package deap I would guess you
are OK if I would swap these fields in a potential upload of the new
upstream version (which might potentially fix
   #1018336 deap: build-depends on python3-nose or uses it for autopkgtest
)
Would you mind if I would do so?

Kind regards
Andreas.

- Weitergeleitete Nachricht von Andreas Tille  -

Date: Tue, 27 Feb 2024 09:05:44 +0100
From: Andreas Tille 
To: Debian Python 
Subject: Suggesting change in DPT policy

Hi,

I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to
DPMT[1][2].  I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT.  I was happy with this move since it makes
sense.

Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations.  So
I did what I usually do in those teams:  I dedicated quite some time in
team wide bug hunting.  That way I squashed about 50 bugs on packages
where I was not in Uploaders.  When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.

I probably should have reviewed the DPT policy on Maintainership[3] more
carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177.  However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy.  I apologize for this.  However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug.  Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment.  If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users.  I wonder whether I
should propose another change to the policy about maintaining a kind and
polite language inside the team - but that's a different thing.

While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy.  But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the
green light."  I apoligize for this again.  The response was another
volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as
"frivolous".

So far what happened (seen from my possibly biased perspective).

Why do I like to change the policy?

The current wording provides some means to stop volunteer team members
helping out moving forward to speed up migrations and fix Debian wide
dependencies.  It hides team maintained packages from a common BTS
view.  When pointing my browser to
https://bugs.debian.org/team+pyt...@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]).  This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight.  To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.

When I think twice about the wording
   Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).

How can a team member for instance find another RC bug #1009424?  Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS.  I came across this while looking into
Cython 3.0 bugs.  The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug
(#1009424) that stayed unattended for 22 months?  We all know volunteers
have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs.  But what else is the sense of a packaging
team than stepping in situations for long standing 

Bug#1066411: webkit2gtk: FTBFS: SharedContextMutex.cpp:219:41: error: inlining failed in call to ‘always_inline’ ‘egl::SharedContextMutex* egl::SharedContextMutex::doTryLock() [with Mute

[Alberto Garcia]

On Thu, Mar 14, 2024 at 11:00:26AM -0400, Jeremy Bícha wrote:
> > - Several undefined references at link time.
> It is caused by a changed in dpkg in Unstable
> 
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Indeed, we were incorrectly adding that flag to CXXFLAGS. I'm
confirming that this fixes everything and I'll upload the new package
asap.

Thanks!

Berto

Bug#1066850: don't hard-code the name of the shared library

[Matthias Klose]

On 14.03.24 18:52, Christoph Biedl wrote:

Control: tags 1066850 moreinfo

Matthias Klose wrote...


Package: src:python-magic
Version: 2:0.4.27-2
Severity: serious
Tags: sid trixie

the package build-depends on libmagic1, and depends on it. The name was
recently changed to libmagic1t64.


This is not a real problem as libmagic1t64 provides libmagic1, so the
dependency can still be resolved.


this is not true on the 32bit time_t64 archs. Debian doesn't build 
binary-indep packages on these architectures, but this b-d prevents 
doing so (and it does so, because it's impossible to install 
python-magic's b-d's on the porter boxes).



Please don't hard-code it, but try to b-d
on libmagic-dev, (...)


About the build dependency src:python-magic -> libmagic1:

So that is ugly, and using libmagic-dev is a simple fix for it. Will do
in the next uplad.


and derive the name of the shared library package from the
libmagic-dev package.


Are you still talking about the build dependency here? Then it's no
issue as the -dev dependency will take care of that.


No, the idea was to b-d on libmagic-dev, and then get the dependency for 
python3-magic from it.



Question: What is the justifcation for the bug severity? To me, it
is rather "minor".


you can't install the package on the 32bit time_t64 architectures, some 
of them still being release architectures. On these archs, libmagic1t64 
doesn't provide libmagic1.


Matthias

Bug#1066727: satpy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Sebastiaan Couwenberg]

reassign 1066727 src:python-pytest-lazy-fixture
found 1066727 python-pytest-lazy-fixture/0.6.3-2
affects 1066727 src:satpy
thanks

On 3/13/24 4:00 PM, Lucas Nussbaum wrote:

/usr/lib/python3/dist-packages/pytest_lazyfixture.py:105: in normalize_call
 valtype_keys = set(getattr(callspec, valtype).keys()) - used_keys
E   AttributeError: 'CallSpec2' object has no attribute 'funcargs'

Reassigning accordingly.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1066850: don't hard-code the name of the shared library

[Christoph Biedl]

Control: tags 1066850 moreinfo

Matthias Klose wrote...

> Package: src:python-magic
> Version: 2:0.4.27-2
> Severity: serious
> Tags: sid trixie
>
> the package build-depends on libmagic1, and depends on it. The name was
> recently changed to libmagic1t64.

This is not a real problem as libmagic1t64 provides libmagic1, so the
dependency can still be resolved.

> Please don't hard-code it, but try to b-d
> on libmagic-dev, (...)

About the build dependency src:python-magic -> libmagic1:

So that is ugly, and using libmagic-dev is a simple fix for it. Will do
in the next uplad.

> and derive the name of the shared library package from the
> libmagic-dev package.

Are you still talking about the build dependency here? Then it's no
issue as the -dev dependency will take care of that.


Question: What is the justifcation for the bug severity? To me, it
is rather "minor".

Christoph


signature.asc
Description: PGP signature

Bug#1066866: railway-gtk: FTBFS on i386 "type annotations needed"

[Peter Green]

Package: railway-gtk
Version: 2.4.0-1
Severity: serious

railway-gtk FTBFS on i386 (and will probablly FTBFS on other
32-bit architectures but builds on those architectures are
currently blocked by the time64 transition).


error[E0283]: type annotations needed for `std::option::Option`
   --> src/backend/journeys_result.rs:207:17
|
207 | let index = list
| ^
...
215 | if position <= index && index < position + n_items {
| -- type must be known at this point
|
= note: multiple `impl`s satisfying `u32: PartialOrd<_>` found in the 
following crates: `core`, `glib`:
- impl PartialOrd for u32;
- impl PartialOrd for u32;
help: consider giving `index` an explicit type, where the placeholders `_` are 
specified
|
207 | let index: std::option::Option = list
|  


Looking at the code, I'm pretty confident that the intended type was
Option. The attached debdiff adds the annotation. I have tested
that railway-gtk builds succesfully with this patch on both i386
and amd64.diff -Nru railway-gtk-2.4.0/debian/changelog railway-gtk-2.4.0/debian/changelog
--- railway-gtk-2.4.0/debian/changelog  2024-03-04 13:13:51.0 +
+++ railway-gtk-2.4.0/debian/changelog  2024-03-14 16:10:58.0 +
@@ -1,3 +1,10 @@
+railway-gtk (2.4.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with "type annotation needed" error on i386.
+
+ -- Peter Michael Green   Thu, 14 Mar 2024 16:10:58 +
+
 railway-gtk (2.4.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru railway-gtk-2.4.0/debian/patches/add-type-annotation.patch 
railway-gtk-2.4.0/debian/patches/add-type-annotation.patch
--- railway-gtk-2.4.0/debian/patches/add-type-annotation.patch  1970-01-01 
00:00:00.0 +
+++ railway-gtk-2.4.0/debian/patches/add-type-annotation.patch  2024-03-14 
16:10:58.0 +
@@ -0,0 +1,13 @@
+Index: railway-gtk-2.4.0/src/backend/journeys_result.rs
+===
+--- railway-gtk-2.4.0.orig/src/backend/journeys_result.rs
 railway-gtk-2.4.0/src/backend/journeys_result.rs
+@@ -204,7 +204,7 @@ mod imp {
+ let list = self.journeys.borrow();
+ let selection = self.selected.borrow();
+ 
+-let index = list
++let index: Option = list
+ .iter()
+ .position(|j| {
+ j.refresh_token() == selection.as_ref().and_then(|j| 
j.refresh_token())
diff -Nru railway-gtk-2.4.0/debian/patches/series 
railway-gtk-2.4.0/debian/patches/series
--- railway-gtk-2.4.0/debian/patches/series 2024-03-04 13:13:51.0 
+
+++ railway-gtk-2.4.0/debian/patches/series 2024-03-14 16:10:14.0 
+
@@ -1,3 +1,4 @@
 relax-deps.diff
 disable-cargo-home-meson-build.diff
 build-set-project-name-to-railway-gtk.patch
+add-type-annotation.patch

Bug#1066382: xserver-xorg-video-nouveau: FTBFS: ../../src/nv_driver.c:1451:23: error: implicit declaration of function ‘wfbScreenInit’; did you mean ‘fbScreenInit’? [-Werror=implicit-function-declarat

[Sven Joachim]

On 2024-03-13 18:07 +0100, Sven Joachim wrote:

> Control: forwarded -1 
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/569
>
> On 2024-03-13 12:47 +0100, Lucas Nussbaum wrote:
>
>> Source: xserver-xorg-video-nouveau
>> Version: 1:1.0.17-2
>> Severity: serious
>> Justification: FTBFS
>> Tags: trixie sid ftbfs
>> User: lu...@debian.org
>> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef
>>
>> Hi,
>>
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>>
>> This is most likely caused by a change in dpkg 1.22.6, that enabled
>> -Werror=implicit-function-declaration. For more information, see
>> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
>>
>> Relevant part (hopefully):
>>> /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
>>> -I. -I../../src -I..  -Wdate-time -D_FORTIFY_SOURCE=2
>>> -I/usr/include/xorg -fvisibility=hidden -I/usr/include/pixman-1
>>> -I/usr/include/X11/dri -I/usr/include/libdrm -I/usr/include/libdrm
>>> -I/usr/include/libdrm/nouveau -I/usr/include/libdrm -g -O2
>>> -Werror=implicit-function-declaration
>>> -ffile-prefix-map=/<>=. -fstack-protector-strong
>>> -fstack-clash-protection -Wformat -Werror=format-security
>>> -fcf-protection -Wall -minline-all-stringops -I/usr/include/xorg
>>> -fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/X11/dri
>>> -I/usr/include/libdrm -c -o nv04_xv_ovl.lo ../../src/nv04_xv_ovl.c
>>> ../../src/nv_driver.c: In function ‘NVScreenInit’:
>>> ../../src/nv_driver.c:1451:23: error: implicit declaration of
>>> function ‘wfbScreenInit’; did you mean ‘fbScreenInit’?
>>> [-Werror=implicit-function-declaration]
>>>  1451 | ret = wfbScreenInit(pScreen, FBStart, 
>>> pScrn->virtualX,
>>>   |   ^
>>>   |   fbScreenInit
>
> This has already been reported upstream, unfortunately without a
> followup so far.

Got a reply from Alan Coppersmith, and he mentioned a fix to xorg's fb.h
header file which is in the Xserver master branch, but has not yet been
applied to the server-21.1-branch.

> Adding -DFB_ACCESS_WRAPPER to CPPFLAGS lets the build
> succeed, but I have not tested the resulting binary package yet.

Tested it now, and it does not work at all, xinit fails to start:

,
| /usr/lib/xorg/Xorg: symbol lookup error: 
/usr/lib/xorg/modules/drivers/nouveau_drv.so: undefined symbol: wfbPictureInit
`

> See commit d7ba24fb6e4f ("wfb: Fix missing init function decls behind
> FB_ACCESS_WRAPPER") which noticed and fixed the missing function
> declaration, but got reverted in commit ca13913aaf7e.

For a good reason, the commit message mentions the same error which I
got.  So I think we should disable -Werror=implicit-function-declaration
in xserver-xorg-video-nouveau for now until there is a fix in the
xorg-server package.

Cheers,
   Sven

Bug#1066249: libmediascan: FTBFS: api_test.c:80:3: error: implicit declaration of function ‘gettimeofday’ [-Werror=implicit-function-declaration]

[gregor herrmann]

On Wed, 13 Mar 2024 12:41:10 +0100, Lucas Nussbaum wrote:

> > api_test.c: In function ‘check_mimetypes’:
> > api_test.c:80:3: error: implicit declaration of function ‘gettimeofday’ 
> > [-Werror=implicit-function-declaration]
> >80 |   gettimeofday(, NULL);

> > api_test.c: In function ‘main’:
> > api_test.c:198:3: error: implicit declaration of function ‘run_unit_tests’ 
> > [-Werror=implicit-function-declaration]
> >   198 |   run_unit_tests();

> > test_background.c: In function ‘test_background_api’:
> > test_background.c:12:16: error: implicit declaration of function ‘mkdir’; 
> > did you mean ‘_mkdir’? [-Werror=implicit-function-declaration]
> >12 | #define _mkdir mkdir

> > test_background.c: In function ‘test_async_api’:
> > test_background.c:822:3: error: implicit declaration of function 
> > ‘gettimeofday’ [-Werror=implicit-function-declaration]
> >   822 |   gettimeofday(, NULL);

> > test.c: In function ‘TouchFile’:
> > test.c:512:3: error: implicit declaration of function ‘gettimeofday’ 
> > [-Werror=implicit-function-declaration]
> >   512 |   gettimeofday(, NULL);

> > test.c:513:3: error: implicit declaration of function ‘utimes’; did you 
> > mean ‘ctime’? [-Werror=implicit-function-declaration]
> >   513 |   utimes(filename  , );

I've pushed a patch to git which make the package compile without
errors.

Not going to upload as-is, as I hardly speak any C and don't really
know what I'm doing and this is more than adding a missing #include
or prototype and I don't understand the code.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1066865: knot-resolver ftbfs, wrong time_t type on 32bit archs with time_t64

[Matthias Klose]

Package: src:knot-resolver
Version: 5.7.1-1
Severity: serious
Tags: sid trixie ftbfs

seen trying to build knot-resolver on armhf with time_t64:

[...]
Program stderr:


Checking for size of "knot_pkt_t" with dependency libknot: 364
Program luajit found: YES (/usr/bin/luajit)
Running command: /usr/bin/luajit -e '
dofile('"'"'/<>/daemon/lua/kres-gen-32.lua'"'"')
local ffi = require('"'"'ffi'"'"')

  assert(ffi.sizeof(ffi.typeof('"'"'time_t'"'"')) == 8,
'"'"'Lua binding for C type '"'"' .. '"'"'time_t'"'"' .. '"'"' 
has incorrect size: '"'"'

.. ffi.sizeof(ffi.typeof('"'"'time_t'"'"'))
  )

  assert(ffi.sizeof(ffi.typeof('"'"'struct timeval'"'"')) == 16,
'"'"'Lua binding for C type '"'"' .. '"'"'struct timeval'"'"' 
.. '"'"' has incorrect size: '"'"'

.. ffi.sizeof(ffi.typeof('"'"'struct timeval'"'"'))
  )

  assert(ffi.sizeof(ffi.typeof('"'"'zs_scanner_t'"'"')) == 206056,
'"'"'Lua binding for C type '"'"' .. '"'"'zs_scanner_t'"'"' .. 
'"'"' has incorrect size: '"'"'

.. ffi.sizeof(ffi.typeof('"'"'zs_scanner_t'"'"'))
  )

  assert(ffi.sizeof(ffi.typeof('"'"'knot_pkt_t'"'"')) == 364,
'"'"'Lua binding for C type '"'"' .. '"'"'knot_pkt_t'"'"' .. 
'"'"' has incorrect size: '"'"'

.. ffi.sizeof(ffi.typeof('"'"'knot_pkt_t'"'"'))
  )
'
--- stdout ---

--- stderr ---
/usr/bin/luajit: (command line):5: Lua binding for C type time_t has 
incorrect size: 4

stack traceback:
[C]: in function 'assert'
(command line):5: in main chunk
[C]: at 0x00511b7d



../daemon/lua/meson.build:97:4: ERROR: Problem encountered: if you use 
released Knot* versions, please contact us: 
https://www.knot-resolver.cz/contact/
/usr/bin/luajit: (command line):5: Lua binding for C type time_t has 
incorrect size: 4

stack traceback:
[C]: in function 'assert'
(command line):5: in main chunk
[C]: at 0x00511b7d
dh_auto_configure: error: cd obj-arm-linux-gnueabihf && 
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/arm-linux-gnueabihf 
-Dpython.bytecompile=-1 -Dkeyfile_default=/usr/share/dns/root.key 
-Dinstall_root_keys=disabled -Dmanaged_ta=disabled 
-Droot_hints=/usr/share/dns/root.hints -Dinstall_kresd_conf=enabled 
-Dsystemd_files=enabled -Dclient=enabled -Dutils=enabled -Ddoc=enabled 
-Ddnstap=enabled -Dunit_tests=enabled -Dconfig_tests=enabled 
-Dextra_tests=disabled -Dmalloc=jemalloc returned exit code 1

make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 25
make[1]: Leaving directory '/<>'

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

[Tobias Frost]

On Fri, Mar 01, 2024 at 06:50:24PM +0100, Jörg Frings-Fürst wrote:
>  libhx (4.23-1)  experimental; urgency=medium

Note: the dsc file targets unstable, not experimental. The review was
using unstable as target.

-- 
tobi

Bug#1066264: cdrkit: diff for NMU version 9:1.1.11-3.5

[Andrey Rakhmatullin]

Control: tags 1066264 + patch
Control: tags 1066264 + pending

Dear maintainer,

I've prepared an NMU for cdrkit (versioned as 9:1.1.11-3.5) and
uploaded it to DELAYED/4. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
WBR, wRAR
diff -Nru cdrkit-1.1.11/debian/changelog cdrkit-1.1.11/debian/changelog
--- cdrkit-1.1.11/debian/changelog	2022-06-24 19:56:39.0 +0500
+++ cdrkit-1.1.11/debian/changelog	2024-03-14 21:53:13.0 +0500
@@ -1,3 +1,10 @@
+cdrkit (9:1.1.11-3.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066264).
+
+ -- Andrey Rakhmatullin   Thu, 14 Mar 2024 21:53:13 +0500
+
 cdrkit (9:1.1.11-3.4) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch
--- cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch	1970-01-01 05:00:00.0 +0500
+++ cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch	2024-03-14 21:50:53.0 +0500
@@ -0,0 +1,29 @@
+Description: Add missing header includes.
+Author: Andrey Rakhmatullin 
+Bug-Debian: https://bugs.debian.org/1066264
+Last-Update: 2024-03-14
+
+Index: cdrkit-1.1.11/genisoimage/genisoimage.c
+===
+--- cdrkit-1.1.11.orig/genisoimage/genisoimage.c
 cdrkit-1.1.11/genisoimage/genisoimage.c
+@@ -54,6 +54,7 @@
+ #include 
+ #include "match.h"
+ #include "exclude.h"
++#include "checksum.h"
+ #include 	/* For UNICODE translation */
+ #include 
+ #ifdef UDF
+Index: cdrkit-1.1.11/genisoimage/jte.c
+===
+--- cdrkit-1.1.11.orig/genisoimage/jte.c
 cdrkit-1.1.11/genisoimage/jte.c
+@@ -27,6 +27,7 @@
+ #include "ifo_read.h"
+ #include "endianconv.h"
+ #include "checksum.h"
++#include "md5.h"
+ #endif
+ #ifdef APPLE_HYB
+ #include 
diff -Nru cdrkit-1.1.11/debian/patches/series cdrkit-1.1.11/debian/patches/series
--- cdrkit-1.1.11/debian/patches/series	2022-05-25 07:57:10.0 +0500
+++ cdrkit-1.1.11/debian/patches/series	2024-03-14 21:48:02.0 +0500
@@ -4,3 +4,4 @@
 add-efi-boot.patch
 gcc10.patch
 fix_format-security.patch
+fix-implicit-function-declaration.patch


signature.asc
Description: PGP signature

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

[Tobias Frost]

Control: tags -1 moreinfo

Hi Jörg,

d/copyright:
you are changing history:

diff -Naur archive/libhx-4.19/debian/changelog new/libhx-4.23/debian/changelog
(...)
   * debian/rules:
 - Remove build of libhx-dev.symbols.

- -- Jörg Frings-Fürst   Sun, 17 Dec 2023 14:44:39 +0100
+ -- Jörg Frings-Fürst   Tue, 21 Nov 2023 10:41:07 +0100

 libhx (4.14-1) unstable; urgency=medium

- you git repository seems to missing commits. a debcheckout libhx
  gives me 4.17-1 in d/changelog.

- please don't drop the Build-Depends: dpkg-dev (>= 1.22.5), the
  time_t transition requires it, 

--
tobi

On Fri, Mar 01, 2024 at 06:50:24PM +0100, Jörg Frings-Fürst wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libhx":
> 
>    Package name : libhx
>    Version  : 4.23-1
>    Upstream contact : Jan Engelhardt 
>    URL  : https://inai.de/projects/libhx/
>    License  : LGPL-2.1+, WTFPL-2+, GPL-2+
>    Vcs  : https://git.jff.email/cgit/libhx.git
>    Section  : libs
> 
> The source builds the following binary packages:
> 
>   libhx32t64 - C library providing queue, tree, I/O and utility functions
>   libhx-dev - Development files for libhx
>   libhx-doc - Documentation files for libhx
> 
> To access further information about this package, please visit the following
> URL:
> 
>  https://mentors.debian.net/package/libhx/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>  dget -x 
> https://mentors.debian.net/debian/pool/main/libh/libhx/libhx_4.23-1.dsc
> 
> or from 
> 
>  git https://git.jff.email/cgit/libhx.git?h=release%2Fdebian%2F4.23-1
> 
> 
> 
> Changes since the last upload:
> 
>  libhx (4.23-1)  experimental; urgency=medium
>  .
>    * New upstream release (Closes: #1064734).
>    * Add debian/.gitignore
>    * Remove not longer needed debian/libhx-dev.lintian-overrides.
>    * Fix debian/libhx32t64.lintian-overrides.
>    * debian/copyright:
>  - Add 2024 to myself.
> 
> 
> 
> CU
> 
> Jörg
> 
> 
> -- 
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
> 
> 
> Jörg Frings-Fürst
> D-54470 Lieser
> 
> 
> git:  https://git.jff.email/cgit/
> 
> Skype:jff-skype@jff.email
> Jami: joergfringsfuerst
> Telegram: @joergfringsfuerst
> Matrix:   @joergff:matrix.snct-gmbh.de
> 
> My wish list: 
>  - Please send me a picture from the nature at your home.
> 
> 
> 
> 

Bug#1066358: graphviz: diff for NMU version 2.42.2-8.1

[Andrey Rakhmatullin]

Control: tags 1066358 + patch
Control: tags 1066358 + pending

Dear maintainer,

I've prepared an NMU for graphviz (versioned as 2.42.2-8.1) and
uploaded it to DELAYED/4. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
WBR, wRAR
diff -Nru graphviz-2.42.2/debian/changelog graphviz-2.42.2/debian/changelog
--- graphviz-2.42.2/debian/changelog	2024-01-27 01:26:42.0 +0500
+++ graphviz-2.42.2/debian/changelog	2024-03-14 21:33:50.0 +0500
@@ -1,3 +1,10 @@
+graphviz (2.42.2-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066358).
+
+ -- Andrey Rakhmatullin   Thu, 14 Mar 2024 21:33:50 +0500
+
 graphviz (2.42.2-8) unstable; urgency=medium
 
   * Fix CVE-2023-46045: buffer overflow via a crafted config6a file.
diff -Nru graphviz-2.42.2/debian/patches/fix-implicit-function-declaration.patch graphviz-2.42.2/debian/patches/fix-implicit-function-declaration.patch
--- graphviz-2.42.2/debian/patches/fix-implicit-function-declaration.patch	1970-01-01 05:00:00.0 +0500
+++ graphviz-2.42.2/debian/patches/fix-implicit-function-declaration.patch	2024-03-14 21:26:14.0 +0500
@@ -0,0 +1,17 @@
+Description: Add a missing prototype for makeTetrix().
+Author: Andrey Rakhmatullin 
+Bug-Debian: https://bugs.debian.org/1066358
+Origin: backport, https://gitlab.com/graphviz/graphviz/-/commit/be6f649995d00865e7c7d721f9b5bdb13fd715c0
+Forwarded: not-needed
+Last-Update: 2024-03-14
+
+--- graphviz-2.42.2.orig/cmd/tools/graph_generator.h
 graphviz-2.42.2/cmd/tools/graph_generator.h
+@@ -30,6 +30,7 @@ extern void makeRandom(int, int, edgefn)
+ extern void makeSquareGrid(int, int, int, int, edgefn);
+ extern void makeBinaryTree(int, edgefn);
+ extern void makeSierpinski(int, edgefn);
++extern void makeTetrix(int, edgefn);
+ extern void makeHypercube(int, edgefn);
+ extern void makeTree(int, int, edgefn);
+ extern void makeTriMesh(int, edgefn);
diff -Nru graphviz-2.42.2/debian/patches/series graphviz-2.42.2/debian/patches/series
--- graphviz-2.42.2/debian/patches/series	2024-01-27 01:26:42.0 +0500
+++ graphviz-2.42.2/debian/patches/series	2024-03-14 21:24:56.0 +0500
@@ -10,3 +10,4 @@
 update_documentation_link.patch
 fix_out-of-bounds_write_on_invalid_label.patch
 CVE-2023-46045.patch
+fix-implicit-function-declaration.patch


signature.asc
Description: PGP signature

Bug#1066498: dh-make-perl: autopkgtest regression due to time_t transition

[Niko Tyni]

On Thu, Mar 14, 2024 at 05:14:17PM +0100, gregor herrmann wrote:

> After some thinking, I think I makes to (temporarily) allow both
> libperl5.XXt64 and libperl5.XX, otherwise we'll have a mess during
> the 5.40 transition.
> (After that we can get rid of the option with the suffix again.)

Sure we need to allow for libperl5.XX to stay future-proof. I was just
thinking of hardcoding libperl5.38t64 as the (temporary) other option
rather than using a generic libperl5.XXt64 name.

But no worries :)
-- 
Niko

Bug#1065768: libauthen-krb5-perl: FTBFS on arm{el,hf}: Krb5.xs:1040:17: error: implicit declaration of function ‘krb5_free_address’; did you mean ‘krb5_free_addresses’? [-Werror=implicit-function-dec

[gregor herrmann]

On Sat, 09 Mar 2024 21:29:26 +0100, Sebastian Ramacher wrote:

> Source: libauthen-krb5-perl
> Version: 1.9-6
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> https://buildd.debian.org/status/fetch.php?pkg=libauthen-krb5-perl=armhf=1.9-6%2Bb3=1709893977=0
> 
> Krb5.xs:1040:17: error: implicit declaration of function ‘krb5_free_address’; 
> did you mean ‘krb5_free_addresses’? [-Werror=implicit-function-declaration]
>  1040 | krb5_free_address(context,addr);
>   | ^
>   | krb5_free_addresses

Not sure there are many chances to fix this (short of disabling
-Werror=implicit-function-declaration). Cf. also in Fedora:
https://src.fedoraproject.org/rpms/perl-Authen-Krb5/commits/rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=2172836

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1066863: python3-pyqtgraph: SyntaxWarning: invalid escape sequence '\$'

[Taavi Väänänen]

Package: python3-pyqtgraph
Version: 0.13.4-2
Severity: normal

Hello,

The python3-pyqtgraph package printed this warning when it updated from
0.13.3-1 to 0.13.4-2:

Setting up python3-pyqtgraph (0.13.4-2) ...
/usr/lib/python3/dist-packages/pyqtgraph/examples/SpinBox.py:38:
  SyntaxWarning: invalid escape sequence '\$'
  regex='\$?(?P(-?\d+(\.\d+)?)|(-?\.\d+))$')),

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

Kernel: Linux 6.6.15-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 python3-pyqtgraph depends on:
ii  libpyside2-py3-5.15 [libpyside2-py3]  5.15.12-6
ii  pyqt5-dev-tools   5.15.10+dfsg-1
ii  pyqt6-dev-tools   6.6.1-2
ii  python3   3.11.6-1
ii  python3-numpy 1:1.24.2-2
ii  python3-pyqt5 5.15.10+dfsg-1
ii  python3-pyqt6 6.6.1-2
ii  python3-scipy 1.11.4-6
ii  qt6-base-dev-tools6.4.2+dfsg-21
ii  qtbase5-dev-tools 5.15.10+dfsg-7

Versions of packages python3-pyqtgraph recommends:
ii  python3-matplotlib  3.6.3-1+b2
ii  python3-opengl  3.1.7+dfsg-1
ii  python3-pyqt5.qtopengl  5.15.10+dfsg-1

Versions of packages python3-pyqtgraph suggests:
pn  python-pyqtgraph-doc  

-- no debconf information

Bug#1065374: RFS: sane-backends/1.3.0-1 -- API development library for scanners

[Tobias Frost]

Control: tags -1 moreinfo

Hi Jörg,

isfdtype(3) says the header you need to include is 
   #include 
   #include 

Any reason why you don't include the header but use a forward
declaration instead?

--
tobi

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Tobias Frost]

Hi Joachim

&& dpkg --compare-versions $2 le-nl 0.8.3 \
&& dpkg --compare-versions $2 ge 0.8.2; then

- $2 might be empty, you need to quote it: use "$2" otherwise dpkg will
  fail:

$ dpkg --compare-versions $empty le-nl 0.8.3
dpkg: error: --compare-versions takes three arguments:   


Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or 'more' !
 
-- 
tobi

Bug#1066498: dh-make-perl: autopkgtest regression due to time_t transition

[gregor herrmann]

On Wed, 13 Mar 2024 23:12:57 +0200, Niko Tyni wrote:

> > Reviews welcome; I'm not sure it's the most elegant and safe solution,
> > and also if this libperl5.38t64 naming has other effects.
> Thanks for fixing this.

Thanks for checking.
 
> Didn't dig deeply into what the test is actually doing, but I think it'd
> be fine to just hardcode libperl5.38t64 FWIW.

After some thinking, I think I makes to (temporarily) allow both
libperl5.XXt64 and libperl5.XX, otherwise we'll have a mess during
the 5.40 transition.
(After that we can get rid of the option with the suffix again.)
 
> But whatever works is good of course.

:)


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]

[Andrey Rakhmatullin]

On Wed, Mar 13, 2024 at 12:44:18PM +0100, Lucas Nussbaum wrote:
> > error.c:197:43: error: implicit declaration of function ‘strcmp’ 
> > [-Werror=implicit-function-declaration]
> >   197 |   (file_name == old_file_name || !strcmp (old_file_name, 
> > file_name)))
> >   |   ^~
 is included in that file under #if STDC_HEADERS || _LIBC. No
idea what is _LIBC as it's only mentioned in various .c files, but
STDC_HEADERS is set/unset by configure via AC_HEADER_STDC, and in this
case it's unset ("checking for ANSI C header files... no"):

configure:6168: gcc -o conftest -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/build/recode-ConsAw/recode-3.6=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c  1>&5
configure: In function 'main':
configure:6163:67: error: implicit declaration of function 'exit' 
[-Werror=implicit-function-declaration]

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1066849: Re: Bug#1066849: libelf1 Version mismatch (0.190-1+b1 vs 0.191-1)

[Rémi DUCCESCHI]

Hello,

Thanks for the info. So this may be linked to
?

Do you know where I can find information about the time_t64 transition?

Bug#1066827: foot: mouse-click results in sequence 0;45;9M0;45;9m, displayed at the prompt

[Birger Schacht]

Hi,


can you clarify what "after a while" means? I can not reproduce the 
behavior and I'm using foot all the time...

Do you have a custom foot configuration?

cheers,
Birger

On 3/14/24 12:06 AM, Johann Hoermann wrote:

Dear Maintainer,

when i do a mouse-click in a just opened foot terminal, it highlights the 
text under the mouse-pointer which is the expected behaviour.

After a while, instead of highlighting, a new mouse-click results in a 
sequence 0;45;9M0;45;9m being displayed at the shell prompt.

Bug#1066862: openstack-cluster-installer: Enhancement: Manage dnsmasq_dns_servers parameter

[Jim Scadden]

Package: openstack-cluster-installer
Tags: patch
Severity: wishlist

I've raised a Merge Request [1] to manage the dnsmasq_dns_servers option
of /etc/neutron/dhcp_agent.ini in the OCI cluster settings

This enables the user to configure Case 2a from
https://docs.openstack.org/neutron/latest/admin/config-dns-res.html

The MR includes an update to README.md with instructions on the use of
the new cluster option (--neutron-dnsmasq-dns-servers)

--

Regards
Jim Scadden (FloydianJim)

[1] 
https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer/-/merge_requests/48

Bug#1066861: apt-get wants to remove packages instead of upgrading

[Vincent Lefevre]

Package: apt
Version: 2.7.13+b1
Severity: important

When I type "apt-get install libreoffice" to upgrade libreoffice,
apt-get wants to remove wine32:i386, while
"apt-get install libreoffice wine32:i386" shows that the upgrade
is actually possible without removing wine32:i386.

Debug information (attached) shows that in the former case:

Broken libgav1-1:i386 Depends on libabsl20220623:i386 < 20220623.1-3 @ii pmR > 
(>= 0~20220623.0-1)
  Considering libabsl20220623:i386 0 as a solution to libgav1-1:i386 2
  Added libabsl20220623:i386 to the remove list

while it could be upgraded to libabsl20220623t64:i386 instead.

I've attached the output of the following commands:

apt-get install -s -o Debug::pkgProblemResolver=true -o 
Debug::pkgDepCache::AutoInstall=true libreoffice >& out1

apt-get install -s -o Debug::pkgProblemResolver=true -o 
Debug::pkgDepCache::AutoInstall=true libreoffice wine32:i386 >& out2

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Key "";
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Clean-Installed "false";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts 

Bug#1066860: libprelude ftbfs on time_t64 archs

[Matthias Klose]

Package: src:libprelude
Version: 5.2.0-5.3
Severity: serious
Tags: sid trixie ftbfs patch

libprelude ftbfs on time_t64 archs with symbols file mismatches.  I 
don't know why some changes are only limited to arc and x32, but I made 
these all optional.


patch at
http://launchpadlibrarian.net/719321091/libprelude_5.2.0-5.3build2_5.2.0-5.3ubuntu1.diff.gz

Bug#1066829: ITP: assetfinder -- Find domains and subdomains related to a given domain

[Henrique de Moraes Holschuh]

Hello,

On Wed, Mar 13, 2024, at 21:47, aquilamac...@riseup.net wrote:
> * Package name: assetfinder
>   Version : 0.1.1
>   Upstream Contact: Tom Hudson 
> * URL : https://github.com/tomnomnom/assetfinder
> * License : MIT 
>   Programming Lang: Golang
>   Description : Find domains and subdomains related to a given
> domain

Please consider a less generic name, there are many assets in the world one 
might want to search for using software, dns domains and subdomains are not 
even remotely on the top of that list for most people.

May I humbly suggest "dns-assetfinder" ?

It might be a very good idea to talk to upstream first.

-- 
  Henrique de Moraes Holschuh 

Bug#1066411: webkit2gtk: FTBFS: SharedContextMutex.cpp:219:41: error: inlining failed in call to ‘always_inline’ ‘egl::SharedContextMutex* egl::SharedContextMutex::doTryLock() [with Mute

[Jeremy Bícha]

On Thu, Mar 14, 2024 at 10:51 AM Alberto Garcia  wrote:
> - Several undefined references at link time. This is reported upstream
>   as https://bugs.webkit.org/show_bug.cgi?id=270970 and is still not
>   fixed.
>
> I thought these were caused by the new version of gcc in sid but I
> tried downgrading the packages and the problem is still there. In
> trixie everything works fine.

It is caused by a changed in dpkg in Unstable

https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Thank you,
Jeremy Bícha

Bug#1066411: webkit2gtk: FTBFS: SharedContextMutex.cpp:219:41: error: inlining failed in call to ‘always_inline’ ‘egl::SharedContextMutex* egl::SharedContextMutex::doTryLock() [with Mute

[Alberto Garcia]

Control: retitle -1 webkit2gtk: FTBFS due to several undefined references

On Wed, Mar 13, 2024 at 01:05:55PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks, there are two build failures here:

- The one you reported (recursive inlining). This one is also
  affecting wpewebkit (#1066454) but I have a fix for it already.

- Several undefined references at link time. This is reported upstream
  as https://bugs.webkit.org/show_bug.cgi?id=270970 and is still not
  fixed.

I thought these were caused by the new version of gcc in sid but I
tried downgrading the packages and the problem is still there. In
trixie everything works fine.

Since the first problem is already taken care of I'm changing the
title of this bug to that of the second problem.

Berto

Bug#1065327: ITA: python-levenshtein

[Louis-Philippe Véronneau]

retitle 1065327 ITA: python-levenshtein -- extension for computing string 
similarities and edit distances (Python 3)
owner 1065327 Louis-Philippe Véronneau 
thanks

I need this package for sublime-music and since it's being orphaned, I'm 
planning to adopt it.

If someone else wants to maintain this package though, I won't fight you for it 
:)

Cheers (and thanks to morph for the work so far),

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

Bug#1036467: virtuoso-opensource: CVE-2023-31607 CVE-2023-31608 CVE-2023-31609 CVE-2023-31610 CVE-2023-31611 CVE-2023-31612 CVE-2023-31613 CVE-2023-31614 CVE-2023-31615 CVE-2023-31616 CVE-2023-31617 C

[Andreas Beckmann]

Control: severity -1 important
On Sun, 21 May 2023 20:43:40 +0200 Salvatore Bonaccorso 
 wrote:

Source: virtuoso-opensource
Version: 7.2.5.1+dfsg1-0.3
Severity: grave


Downgrading the severity since all CVEs are marked as no-dsa (minor issue).


Andreas

Bug#1066337: tightvnc: FTBFS: vncconnect.c:17:5: error: implicit declaration of function ‘exit’ [-Werror=implicit-function-declaration]

[Sven Geuer]

Hi Lucas,

On Wed, 2024-03-13 at 12:45 +0100, Lucas Nussbaum wrote:
> Source: tightvnc
> Version: 1:1.3.10-7
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

That is hard to correct,
- this software is abandonware
- there are about 250 warnings regarding implicit function declaration,
- there is no generic way to get rid of them.

I had a closer look revealing that there are many different cases to
consider. I am afraid it will take weeks or even months to fix this
bug.

On the other hand I could override dpkg by injecting
-Wno-error=implicit-function-declaration. Would that be acceptable?

Cheers,
Sven
-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1066859: ITP: lomiri-system-settings-online-accounts -- Online Accounts setup for Lomiri

[Mike Gabriel]

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

* Package name: lomiri-system-settings-online-accounts
  Version : 0.10
  Upstream Contact: Alberto Mardegan 
* URL : 
https://gitlab.com/ubports/development/core/lomiri-system-settings-online-accounts/
* License : GPL-3, LGPL-3
  Programming Lang: C++ / QML
  Description : Online Accounts setup for Lomiri

 Lomiri-system-settings is the System Settings application used in Lomiri
 operating environment. it's designed for phones, tablets and convergent
 devices.
 .
 This package will contains the online accounts setup utility for Lomiri
 System Settings as well as the OnlineAccountsClient shared library for
 plumbing OnlineAccounts functionality into client applications.
 .
 This package will be maintained under the umbrella of the Debian UBports
 Packaging Team.