Bug#1067529: libonvif: Please package new upstream version

[Petter Reinholdtsen]

Package: onvif-tools
Version: 1.4.4-1
Severity: wishlist

According to https://github.com/sr99622/libonvif/tags >, the
latest upstream version of libonvif is 2.0.1, while the latest Debian
package is 1.4.4.

Please update to the latest upstream version in Debian to make recording
and multistream support available.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1041832: #1041832: libsequoia-octopus-librnp: undeclared file conflict with thunderbird

[Helmut Grohne]

Hi Holger,

On Fri, Mar 22, 2024 at 07:36:37PM +, Holger Levsen wrote:
> < h01ger> helmut: re:  #1041832: i just could not reproduce this bug, see
>   https://paste.debian.net/1311659/ - though we "didnt change
>   anything" in sequoia-octopus, so what am i missing? :)
> 
> that paste had basically this content:
> 
> ± dpkg -L libsequoia-octopus-librnp |grep librnp.so
> /usr/lib/sequoia/libsequoia_octopus_librnp.so
> /usr/lib/thunderbird/librnp.so
> ± dpkg -L thunderbird|grep librnp.so
> 1 ±

You're faced with a relatively early dumat-generated report and I see
how the lack of detail makes diagnosing this difficult. Later reports
have been improved to include the missing detail.

Let me paste the machine-readable report and explain it.

libsequoia-octopus-librnp:
  1.4.1-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
thunderbird:
  1:115.7.0-1~deb11u1: bullseye
  1:115.7.0-1~deb12u1: bookworm
  1:115.8.0-1~deb12u1: bookworm-proposed-updates
  1:115.9.0-1~deb11u1: bullseye-security
  1:115.9.0-1~deb12u1: bookworm-security
  1:122.0~b2-1: experimental
  what: undeclared file conflict
source: rust-sequoia-octopus-librnp
suites: experimental
  1.8.1-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
thunderbird:
  1:115.7.0-1~deb11u1: bullseye
  1:115.7.0-1~deb12u1: bookworm
  1:115.8.0-1~deb12u1: bookworm-proposed-updates
  1:115.9.0-1~deb11u1: bullseye-security
  1:115.9.0-1~deb12u1: bookworm-security
  1:122.0~b2-1: experimental
  what: undeclared file conflict
source: rust-sequoia-octopus-librnp
suites: unstable
thunderbird:
  1:122.0~b2-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
libsequoia-octopus-librnp:
  1.4.1-1: experimental
  1.8.1-1: unstable
  what: undeclared file conflict
suites: experimental

Specifically, you need a version of libsequoia-octopus-librnp from
unstable or experimental and combine it with a thunderbird version from
bullseye, bookworm or experimental. If we disregard experimental and
assume that libsequoia-octopus-librnp to trixe, apt could choose to
first install libsequoia-octopus-librnp in a bookworm to trixie upgrade
before upgrading thunderbird to drop the file.

So to reproduce this, I recommend using a bookworm system, install
thunderbird, add unstable to apt sources, install
libsequoia-octopus-librnp.

Helmut

Bug#1064178: RFS: xwayland-run/0.0.2-1 [ITP] -- Set of utilities to run headless X/Wayland clients

[Bo YU]

Hi,
On Sun, Feb 18, 2024 at 11:31:07AM +0800, Bo YU wrote:

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "xwayland-run":

* Package name : xwayland-run
  Version  : 0.0.2-1
  Upstream contact : Olivier Fourdan 
* URL  : https://gitlab.freedesktop.org/ofourdan/xwayland-run
* License  : GPL-2.0+
* Vcs  : https://salsa.debian.org/vimerbf-guest/xwayland-run
  Section  : x11

The source builds the following binary packages:

 xwayland-run - Set of utilities to run headless X/Wayland clients

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

 https://mentors.debian.net/package/xwayland-run/

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

 dget -x 
https://mentors.debian.net/debian/pool/main/x/xwayland-run/xwayland-run_0.0.2-1.dsc

Changes for the initial release:

xwayland-run (0.0.2-1) UNRELEASED; urgency=low
.
  * Initial release. (Closes: #1061513)


Could anyone to review this package at your free time? I would like to
put this package under Xorg team namespace also.

TUA.


--
Regards,
--
 Bo YU





--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1067528: mirror submission for mirrors.bupt.edu.cn

[fdt]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.bupt.edu.cn
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: fdt 
Country: CN China
Location: Beijing CERNET
Sponsor: NIC, Beijing University of Posts and Telecommunications 
https://nic.bupt.edu.cn




Trace Url: http://mirrors.bupt.edu.cn/debian/project/trace/
Trace Url: http://mirrors.bupt.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.bupt.edu.cn/debian/project/trace/mirrors.bupt.edu.cn

Bug#1067155: debian-policy: prerm scripts cannot actually rely on dependencies

[Sean Whitton]

Hello,

On Tue 19 Mar 2024 at 01:02pm +01, Julian Andres Klode wrote:

> Package: debian-policy
> Severity: wishlist
> X-Debbugs-Cc: de...@lists.debian.org, debian-d...@lists.debian.org
>
> APT's installation planner does not consider dependencies of packages
> being scheduled for removal, so a prerm must fail equally gracefully
> as a postrm does in absence of its dependencies.
>
> This does break dpkg's assumptions which it happily tells you about,
> but this is the reality we live in.
>
> So e.g. one thing you see is that apt removes libapt-pkg6.0, then
> unpacks libapt-pkg6.0t64, then removes libapt-pkg6.0 reverse
> dependencies.
>
> Clearly APT should be considering dependencies when removing packages
> but even in that case, removals may sometimes need to be forced in the
> wrong order because any order leads to broken dependencies, so still,
> prerms should not rely on dependencies, but only on essential packages.

I'm not sure that Policy is the place to discuss a change proposal like
this, and we can't render a swathe of packages RC buggy by making such a
change here.  The archive would need to change first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067527: nyx: curses.py:118: SyntaxWarning: invalid escape sequence '\['

[Paul Wise]

Package: nyx
Version: 2.1.0-3
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

During the recent upgrade I got a Python syntax warning,
probably it was caused by the Python 3.12 transition.

   Preparing to unpack .../archives/nyx_2.1.0-3_all.deb ...
   Unpacking nyx (2.1.0-3) over (2.1.0-2.3) ...
   Setting up nyx (2.1.0-3) ...
   /usr/lib/python3/dist-packages/nyx/curses.py:118: SyntaxWarning: invalid 
escape sequence '\['
 ANSI_RE = re.compile('\x1B\[([0-9;]+)m')

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nyx depends on:
ii  python33.11.6-1
ii  python3-pkg-resources  68.1.2-2
ii  python3-stem   1.8.2-1

nyx recommends no packages.

Versions of packages nyx suggests:
ii  tor  0.4.8.10-1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Sean Whitton]

Hello,

On Mon 18 Mar 2024 at 04:06am -07, Josh Triplett wrote:

> On Mon, Mar 18, 2024 at 05:38:15PM +0800, Sean Whitton wrote:
>> Was there some recent packaging situation that prompted you to think
>> about this?  I'm cautious about adding it in the absence of that.
>
> Mostly, recent discussions in various places regarding whether packages
> are required to use *cron* to run periodic jobs. Policy says what
> packages must do if they install a cronjob, but that itself does not
> mandate the use of cron specifically. It seemed worth explicitly stating
> the understood-but-unwritten interpretation that having Policy about XYZ
> does not mandate that packages use XYZ.
>
> I've also seen a few arguments over the decades that amount to "Policy
> talks about A, and doesn't talk about B" being used as some amount of
> weight towards A or against B.
>
> And finally, I have occasionally seen someone try to build a Debian
> package by sitting down with the Policy manual, and start down the route
> of trying to supply everything Policy talks about that seems like it
> makes sense for the package. The mention of "Policy talking about where
> to install info documentation, but that doesn't mean you have to have
> info documentation" was not a hypothetical; I've seen that and similar
> reasoning a non-zero number of times.
>
> I figured that something like this text would help address all of those.

Thanks.  For the time being, I myself am not convinced.  Policy is not a
stick to beat maintainers with, as we say, but I'm not sure that idea is
one that ought to be in Policy itself.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067526: RFS: company-mode/0.10.2-1 [Team] -- Modular in-buffer completion framework for Emacs

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "company-mode":

 * Package name : company-mode
   Version  : 0.10.2-1
   Upstream contact : Dmitry Gutov 
 * URL  : https://company-mode.github.io/
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/company-mode
   Section  : lisp

The source builds the following binary packages:

  elpa-company - Modular in-buffer completion framework for Emacs

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

  https://mentors.debian.net/package/company-mode/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/company-mode/company-mode_0.10.2-1.dsc

Changes since the last upload:

 company-mode (0.10.2-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version
   * Migrate from debhelper >= 11 to debhelper-compat version 13
   * Update Standards-Version to 4.6.2 (no change needed)
   * Set Rules-Requires-Root as no in d/control
   * Check DEB_BUILD_OPTIONS against nocheck in override_dh_auto_test
   * Modernize d/watch to version 4 with substitute strings to be robust
   * Add Upstream-Contact in d/copyright

Regards,
-- 
Xiyue Deng

Bug#1066246: lcm: FTBFS: emit_cpp.c:306:19: error: implicit declaration of function ‘_exit’ [-Werror=implicit-function-declaration]

[Bo YU]

Tags: patch

Hi,
On Wed, Mar 13, 2024 at 12:40:02PM +0100, Lucas Nussbaum wrote:

Source: lcm
Version: 1.3.1+repack1-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

Relevant part (hopefully):

gcc -DPACKAGE_NAME=\"lcm\" -DPACKAGE_TARNAME=\"lcm\" -DPACKAGE_VERSION=\"1.3.1\" -DPACKAGE_STRING=\"lcm\ 1.3.1\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"lcm\" -DVERSION=\"1.3.1\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\".libs/\" -I.  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread  -Wdate-time -D_FORTIFY_SOURCE=2 -g -std=gnu99 -Wall 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_REENTRANT -Wno-unused-parameter -Wno-format-zero-length -Wshadow -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c -o emit_csharp.o emit_csharp.c
emit_cpp.c: In function ‘emit_header_start’:
emit_cpp.c:306:19: error: implicit declaration of function ‘_exit’ 
[-Werror=implicit-function-declaration]
  306 |   _exit(1);
  |   ^
emit_cpp.c:306:19: warning: incompatible implicit declaration of built-in 
function ‘_exit’ [-Wbuiltin-declaration-mismatch]
In function ‘ensure_token_capacity’,
inlined from ‘tokenize_next_internal’ at tokenize.c:325:14:
tokenize.c:127:28: warning: argument 2 range [18446744071562067968, 
18446744073709551615] exceeds maximum object size 9223372036854775807 
[-Walloc-size-larger-than=]
  127 | t->token = (char*) realloc(t->token, t->token_capacity);
  |^~~~
In file included from tokenize.c:1:
/usr/include/stdlib.h: In function ‘tokenize_next_internal’:
/usr/include/stdlib.h:564:14: note: in a call to allocation function ‘realloc’ 
declared here
  564 | extern void *realloc (void *__ptr, size_t __size)
  |  ^~~
gcc -DPACKAGE_NAME=\"lcm\" -DPACKAGE_TARNAME=\"lcm\" -DPACKAGE_VERSION=\"1.3.1\" -DPACKAGE_STRING=\"lcm\ 1.3.1\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"lcm\" -DVERSION=\"1.3.1\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\".libs/\" -I.  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread  -Wdate-time -D_FORTIFY_SOURCE=2 -g -std=gnu99 -Wall 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_REENTRANT -Wno-unused-parameter -Wno-format-zero-length -Wshadow -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c -o emit_python.o emit_python.c
gcc -DPACKAGE_NAME=\"lcm\" -DPACKAGE_TARNAME=\"lcm\" -DPACKAGE_VERSION=\"1.3.1\" -DPACKAGE_STRING=\"lcm\ 1.3.1\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"lcm\" -DVERSION=\"1.3.1\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\".libs/\" -I.  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread  -Wdate-time -D_FORTIFY_SOURCE=2 -g -std=gnu99 -Wall 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_REENTRANT -Wno-unused-parameter -Wno-format-zero-length -Wshadow -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c -o emit_lua.o emit_lua.c
emit_python.c: In function ‘emit_package’:
emit_python.c:702:33: warning: ‘__builtin___sprintf_chk’ may write a 
terminating nul past the end of the destination [-Wformat-overflow=]
  702 | sprintf(package_dir, "%s%s%s", package_dir_prefix, pdname,
  | ^
In file included from /usr/include/stdio.h:906,
 from emit_python.c:1:
In function ‘sprintf’,
inlined from ‘emit_package’ at emit_python.c:702:5:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:30:10: note: 
‘__builtin___sprintf_chk’ output 2 or more bytes (assuming 4097) into a 
destination of size 4096
   30 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  |  

Bug#1067525: RFS: runit/2.1.2-59 -- system-wide service supervision

[Lorenzo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : runit
   Version  : 2.1.2-59
   Upstream contact : Gerrit Pape 
 * URL  : http://smarden.org/runit/
 * License  : CC0-1.0, BSD-3-clause, GPL-3+
 * Vcs  : https://salsa.debian.org/debian/runit
   Section  : admin

The source builds the following binary packages:

  runit - system-wide service supervision
  runit-run - service supervision (systemd and sysv integration)
  getty-run - runscripts to supervise getty processes
  runit-init - system-wide service supervision (as init system)

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

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

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

  dget -x
  https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-59.dsc

Git repo:

  https://salsa.debian.org/debian/runit/-/tree/next?ref_type=heads

Changes since the last upload:

 runit (2.1.2-59) unstable; urgency=medium
 .
   * upload to unstable
   * d/copyright: update years
   * d/watch: use https instead of http
   * lintian: update overrides for runit
   * Revert "d/rules: undo changelog trimming for runit"
   * update-service: add bash-completion
   * cpsv: update manpage


About the getty-run.NEWS in a previous RFS(#1057098):

On Tue, 13 Feb 2024 15:06:46 +0100 Tobias Frost  wrote:

> You've misunderstood me with NEWS file (but this is not a stopper for
> the upload.)
> 
> What I meant is that the NEWS file is that old that it should be
> removed. (Debhelper just pointed me to the file, even if it did
> not correctly disagnose the issue)
> This is even more correct if debhelper decided to strip out that
> version from d/changelog anyways, users will not get this NEWS
> files displayed, and the information in it shouldn't be relveant
> anymore. 
> So my suggestion would be to just rm it.

I prefer not to remove this for now, the info inside the file are
relevant for me (as maintainer) since I would like to remove the
links in getty-run.links in the future (they are kind of a policy
violation) but I face the same issue as Dmitry..

Regards,
Lorenzo

Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'

[Thorsten Glaser]

Andrey Rakhmatullin dixit:

>OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64

Yes.

>, and I suspect not all of its uses also are.

That’s what I get from this, yes.

>And I assume this arch doesn't have 64-bit atomics.

No native ones, yes.

I *think* either libatomic or libatomic_ops(?) make them
available, but very slowly, using a syscall to guarantee
atomicity (those systems are normally uniprocessor) on
m68k.

If possible, avoiding them would be preferrable. (For
example, in some cases, like reading a 64-bit timestamp,
if the writing direction is known and stable, reading
twice then comparing is a possible alternative at least
for some architectures (e.g. I know BSD code for sparc
does it that way).

I guess you’ll have to ask the porters of 32-bit arches
with no native 64-bit atomics for details.

Though I had thought GCC’s builtin atomics use the
aforementioned kernel-based workaround from that library
these days?

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k

[Thorsten Glaser]

Colin Watson dixit:

>Could you try the somewhat further reduced patch in

The package made from that branch built fine in my cowbuilder,
and I have all reason to assume it’ll do so in sbuild/buildd.

Thanks,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#1067426: [Pkg-electronics-devel] Bug#1067426: Package sponsorship request Qucs-S

[Felix Salfelder]

On Fri, Mar 22, 2024 at 03:47:12PM +0100, Tobias Frost via 
Pkg-electronics-devel wrote:
> I've had a brief view at the debian/ directory on your repository,
> and there will be a bit work required to make your package suitable
> for inclusion into Debian, for example you'll need a debian/copyright
> file. I didn't look into further details, but I suggest to upload your
> package to mentors.debian.net, as this has already some QA built in and
> will help you to identify problems with your package, for example from
> the linitian tool.

Hi there.

Ruben has done significant work on a Qucs package in 2019, which might
serve as a starting point [0].

I picked it up after the upstream repo split [1,2]. The former has been
released since (version 0.0.20). The latter isn't suitable for Debian
due to the Qt3 dependency. Needless to say, none of this has been
uploaded. But there's little need to start from scratch.

Best wishes
felix

[0] https://salsa.debian.org/science-team/qucs
[1] https://salsa.debian.org/felixs-guest/qucsator
[2] https://salsa.debian.org/felixs-guest/qucs

Bug#1067524: ITP: precis -- Java implementation of the PRECIS Framework

[Matthew Fennell]

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

* Package name: precis
  Version : 1.1.0
  Upstream Contact: Christian Schudt
* URL : https://github.com/sco0ter/precis
* License : Expat
  Programming Lang: Java
  Description : Java implementation of the PRECIS Framework

This Java library validates and prepares Unicode strings, so that they can
safely be used in application protocols, e.g. when dealing with usernames and
passwords.

It supports RFCs 8264, 8265, 8266 and 5893, and is designed to replace software
like Libidn's Stringprep class by handling internationalised strings in a more
coherent way.

It is a dependency of of Babbler, a Java library for interacting with XMPP
servers, which is in turn used by several transports, as well as caas, an
automated compliance tester with an open RFP (#959816).

I hope to maintain this package within the Debian Java Maintainers team. I am
not a Debian Developer, so will need to look for sponsorship once the package
is ready.

Bug#1067523: firefox: CVE-2024-29943 / CVE-2024-29944 critical bugs, fixed in FF 124.0.1

[Vincent Lefevre]

Package: firefox
Version: 124.0-1
Severity: grave
Tags: security upstream fixed-upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Firefox 124.0.1 is available upstream, which fixes 2 critical bugs:
  https://www.mozilla.org/en-US/security/advisories/mfsa2024-15/

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils  5.17
ii  fontconfig   2.15.0-1.1
ii  libasound2t641.2.11-1+b1
ii  libatk1.0-0t64   2.51.90-4
ii  libc62.37-15.1
ii  libcairo-gobject21.18.0-1+local1
ii  libcairo21.18.0-1+local1
ii  libdbus-1-3  1.14.10-4+b1
ii  libevent-2.1-7t642.1.12-stable-8.1+b1
ii  libffi8  3.4.6-1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b2
ii  libgcc-s114-20240315-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b2
ii  libglib2.0-0t64  2.78.4-5
ii  libgtk-3-0t643.24.41-3
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libpango-1.0-0   1.51.0+ds-4
ii  libstdc++6   14-20240315-1
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.4-1
ii  procps   2:4.0.4-4
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages firefox recommends:
ii  libavcodec60  7:6.1.1-3

Versions of packages firefox suggests:
ii  fonts-lmodern   2.005-1
ii  fonts-stix [otf-stix]   1.1.1-5
ii  libcanberra0t64 [libcanberra0]  0.30-12.2
ii  libgssapi-krb5-21.20.1-6
ii  pulseaudio  16.1+dfsg1-3+b1

-- no debconf information

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

Bug#1063085: uhd: NMU diff for 64-bit time_t transition

[Steve Langasek]

Control: reopen -1

Reopening, closed by an upload of an unrelated package.

On Fri, Mar 22, 2024 at 12:20:06PM +0100, Andreas Beckmann wrote:
> Control: reopen -1
> Control: severity -1 serious

> I'm reopening this due to the regression (file conflict) #1063324

> Both libuhd4.6.0 and libuhd4.6.0-dpdk provide
>   /usr/lib/x86_64-linux-gnu/libuhd.so.4.6.0
> and are conflicting with each other.

> So I'm a bit confused that only libuhd4.6.0 got renamed to libuhd4.6.0t64
> ...

> Even if libuhd4.6.0-dpdk would not need to be renamed, I'd suggest to rename
> it anyway to not make the logic too complicated.

> Anyway libuhd4.6.0-dpdk (or libuhd4.6.0t64-dpdk) needs
>   Conflicts: libuhd4.6.0, libuhd4.6.0t64
> to solve #1063324.

Ah libuhd4.6.0-dpdk would not have been renamed because it is not built on
any 32-bit architectures.

So I think the Conflicts: just needs updating but the package does not need
renamed.

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


signature.asc
Description: PGP signature

Bug#1067522: pipewire-pulse: Computer totally unresponsive while playing video on Firefox - OOM error

[Alex Beer]

Package: pipewire-pulse
Version: 1.0.3-1
Severity: normal

Dear Maintainer,
while playing youtube video on Firefox audio start lagging and quite,
except some random spikes, and often computer is completely frozen
(can't switch to console but seems shortcut has effects as seen from
logs).

Below dmesg extract.

--dmesg--
[18746.845975] Timer invoked oom-killer: 
gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=167
[18746.845984] CPU: 1 PID: 20806 Comm: Timer Not tainted 6.6.15-amd64 #1  
Debian 6.6.15-2
[18746.845987] Hardware name: LENOVO 20AWS1CK07/20AWS1CK07, BIOS GLETA2WW (2.56 
) 07/16/2021
[18746.845989] Call Trace:
[18746.845991]  
[18746.845994]  dump_stack_lvl+0x47/0x60
[18746.846001]  dump_header+0x4a/0x240
[18746.846004]  oom_kill_process+0xf9/0x190
[18746.846007]  out_of_memory+0x256/0x540
[18746.846010]  __alloc_pages_slowpath.constprop.0+0xaad/0xd60
[18746.846014]  __alloc_pages+0x30b/0x330
[18746.846017]  folio_alloc+0x1b/0x50
[18746.846021]  __filemap_get_folio+0x128/0x2c0
[18746.846025]  filemap_fault+0x153/0xb60
[18746.846028]  __do_fault+0x33/0x130
[18746.846032]  do_fault+0x2b0/0x4f0
[18746.846035]  __handle_mm_fault+0x796/0xd90
[18746.846040]  handle_mm_fault+0x17f/0x360
[18746.846043]  do_user_addr_fault+0x1ed/0x660
[18746.846049]  exc_page_fault+0x7f/0x180
[18746.846052]  asm_exc_page_fault+0x26/0x30
[18746.846056] RIP: 0033:0x7f1e5817c580
[18746.846062] Code: Unable to access opcode bytes at 0x7f1e5817c556.
[18746.846064] RSP: 002b:7f1e4c6fe428 EFLAGS: 00010246
[18746.846067] RAX: 7f1e5b087d10 RBX: 7f1e4b9616e8 RCX: 7f1e60dc4443
[18746.846069] RDX:  RSI: 7f1e4b9616e0 RDI: 7f1e45b17d80
[18746.846070] RBP: 7f1e60bcecb8 R08: 0001 R09: 1d72
[18746.846072] R10:  R11: 0246 R12: 7f1e4b9616e0
[18746.846074] R13: 7f1e45b17d80 R14: 7f1e60bcec90 R15: 7f1e45c62e50
[18746.846077]  
[18746.846079] Mem-Info:
[18746.846081] active_anon:1127237 inactive_anon:2632650 isolated_anon:0
active_file:637 inactive_file:338 isolated_file:0
unevictable:112926 dirty:752 writeback:0
slab_reclaimable:47512 slab_unreclaimable:47392
mapped:257060 shmem:1753420 pagetables:32119
sec_pagetables:0 bounce:0
kernel_misc_reclaimable:0
free:33061 free_pcp:218 free_cma:0
[18746.846086] Node 0 active_anon:4508948kB inactive_anon:10530600kB 
active_file:2548kB inactive_file:1352kB unevictable:451704kB isolated(anon):0kB 
isolated(file):0kB mapped:1028240kB dirty:3008kB writeback:0kB shmem:7013680kB 
shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:487424kB writeback_tmp:0kB 
kernel_stack:43296kB pagetables:128476kB sec_pagetables:0kB all_unreclaimable? 
no
[18746.846092] Node 0 DMA free:13312kB boost:0kB min:64kB low:80kB high:96kB 
reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB 
inactive_file:0kB unevictable:0kB writepending:0kB present:15980kB 
managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[18746.846098] lowmem_reserve[]: 0 3321 15770 15770 15770
[18746.846103] Node 0 DMA32 free:66008kB boost:0kB min:14220kB low:17772kB 
high:21324kB reserved_highatomic:0KB active_anon:1271756kB 
inactive_anon:2016448kB active_file:632kB inactive_file:0kB unevictable:83588kB 
writepending:208kB present:3556508kB managed:3490560kB mlocked:0kB bounce:0kB 
free_pcp:864kB local_pcp:116kB free_cma:0kB
[18746.846110] lowmem_reserve[]: 0 0 12449 12449 12449
[18746.846114] Node 0 Normal free:52924kB boost:0kB min:53296kB low:66620kB 
high:79944kB reserved_highatomic:0KB active_anon:3236252kB 
inactive_anon:8515092kB active_file:2700kB inactive_file:456kB 
unevictable:368116kB writepending:2800kB present:13080576kB managed:12755512kB 
mlocked:7904kB bounce:0kB free_pcp:8kB local_pcp:4kB free_cma:0kB
[18746.846120] lowmem_reserve[]: 0 0 0 0 0
[18746.846124] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 
0*512kB 1*1024kB (U) 2*2048kB (UM) 2*4096kB (M) = 13312kB
[18746.846138] Node 0 DMA32: 327*4kB (UME) 346*8kB (UME) 242*16kB (UE) 130*32kB 
(UME) 87*64kB (UME) 143*128kB (UME) 67*256kB (UME) 24*512kB (UME) 0*1024kB 
0*2048kB 0*4096kB = 65420kB
[18746.846156] Node 0 Normal: 320*4kB (UME) 144*8kB (UME) 103*16kB (UME) 
139*32kB (UME) 313*64kB (UME) 60*128kB (UME) 49*256kB (ME) 9*512kB (ME) 
0*1024kB 0*2048kB 0*4096kB = 53392kB
[18746.846173] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=1048576kB
[18746.846175] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=2048kB
[18746.846177] 1760641 total pagecache pages
[18746.846178] 4984 pages in swap cache
[18746.846179] Free swap  = 0kB
[18746.846180] Total swap = 8388604kB
[18746.846181] 4163266 pages RAM
[18746.846182] 0 pages HighMem/MovableOnly
[18746.846183] 97908 pages reserved
[18746.846184] 0 pages hwpoisoned
[18746.846185] Tasks state 

Bug#1067521: fonts-noto-hinted: remove package from debian repository

[ton62j+drqwja2pu5a1w]

Package: fonts-noto-hinted
Severity: normal

Dear Maintainer,

the package fonts-noto-hinted has no reverse dependencies and is
obsolete itself. Please remove it from debian repositories.

Thank you.

Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library

[matthew]

bret curtis  wrote:
> > One thing I noticed is that upstream integrated their own fork [1] of
> > glslang directly into the build [2] as of 1.0.3 [3].
> 
> Indeed, I created an issue to track this and Robert is aware of the
> situation. AnyOldName3 and myself are working together with upstream
> glslang that would make it findable and work correctly via cmake so that
> cmake itself would not have to carry its own vulkan and glslang files. [1]

Apologies, I somehow missed your Github issue. Looks like you're about 10 steps
ahead of where I was when I wrote the email! :)

> > I see a few options:
> >
> > 1) We work with upstream to unvendor the dependency
> >
> 
> We are already doing this. :) The trickle down should be happening now.  [2]
> 
> 
> > 2) We disable the shader compiler part of vsg
> >
> 
> Please no; while this would get the package into Debian faster it would be
> useless for OpenMW, or specifically the Vulkan work we are doing there
> which makes use of VSG's glslang.
> 
> 
> > 3) We patch the build to depend on Debian's glslang package
> >
> 
> If we can't wait for 1 to trickle down into Debian's repo; this is a way
> forward. I have a branch I've been working on that would resolve that.  [3]

Agreed - 1 makes most sense to me as well.

I have a few machines with different configurations, so feel free to mail me if
it would help for me to test against your branch (or anything else for that
matter).

Thanks,
Matthew

Bug#443685: bash: Quote removal happening too early

[ton62j+drqwja2pu5a1w]

Package: bash
Followup-For: Bug #443685

this isn't actually a bug in bash.

$ bash -o posix -c 'a=\\; echo $a\/*'
/bin /boot /cdrom /dev /emul /etc /export /home /initrd /lib /lib64 /lost+found 
/media /mnt /opt /proc /root /sbin /srv /sys /tmp /usr /var

is correct behavior.

bash 5.2.15 in debian behaves correctly.

Arguably it is a bug in dash instead.

Discussion here https://austingroupbugs.net/view.php?id=1234

Bug#1067034: dhcpcd-gtk: fails to see wireless networks and to let me enter passphrases

[Leandro Cunha]

Hi,

Control: tags -1 + newcomer
Control: severity -1 normal

This package, when tested, worked normally with WiFi networks without
needing to do any configuration, just install and use. As you ask for
help to use it, I will insert the newcomer tag, understanding that you
have just arrived and want to report a problem you have encountered. I
will investigate what is happening with the package and check for any
problems in the future.

Please keep any new information up to date on this bug and thanks!

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1064659: (no subject)

[Mario Limonciello]

Thanks! But we can go a step farther.  We haven't needed it since 
switching to meson.  Will drop in the next upload.


https://salsa.debian.org/efi-team/fwupd/-/commit/e57b1114f8c0299eb6e2b68e2a14ef3e2ff0f0d3

Bug#1064748: guix: FTBFS: In procedure canonicalize-path: No such file or directory

[Vagrant Cascadian]

Control: fixed 1064748 1.4.0-6

Marking this as fixed in 1.4.0-6, although strictly speaking, this is
only worked around by disabling the tests, so the bug should remain
open.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027486: (no subject)

[Mario Limonciello]

Can you still reproduce this with fwupd 1.9.15-2?  I believe it should 
be fixed now.

Bug#1062820: (no subject)

[Mario Limonciello]

This will be fixed in the next upload by this change.

https://salsa.debian.org/efi-team/fwupd/-/commit/08001e21ccbb71902429dc3096086b35114c822f

Bug#1067520: virtnbdbackup: Backup fails due to missing binary `qemu-img`

[Anatol Ulrich]

Package: virtnbdbackup
Version: 1.9.15-1
Severity: important
X-Debbugs-Cc: e+report...@mail.taugt.net

Dear Maintainer,

executing virtnbdbackup fails at the end because it tries to spawn `qemu-img`. 
An error log is attached below.
A quick investigation revealed this binary is included in `qemu-utils`; 
installing this package resolved the error, 
so `qemu-utils` should be added as a dependency of `virtnbdbackup`.

Invocation and error log:

# virtnbdbackup -d hass -l auto -o /mnt/files_old/hass
[2024-03-22 21:37:31] INFO lib common - printVersion [MainThread]: Version: 
1.9.15 Arguments: /usr/bin/virtnbdbackup -d hass -l auto -o /mnt/files_old/hass
[2024-03-22 21:37:31] INFO root virtnbdbackup - main [MainThread]: Backup 
level: [auto]
[2024-03-22 21:37:31] INFO root virtnbdbackup - main [MainThread]: Backup mode 
auto, target folder is empty: executing full backup.
(...)
[2024-03-22 21:38:51] INFO root virtnbdbackup - main [MainThread]: Backup jobs 
finished, stopping backup task.
[2024-03-22 21:38:51] INFO root virtnbdbackup - backupConfig [MainThread]: 
Saving VM config to: [/mnt/files_old/hass/vmconfig.virtnbdbackup.0.xml]
[2024-03-22 21:38:51] INFO root virtnbdbackup - backupBootConfig [MainThread]: 
Save additional boot config [loader] to: 
[/mnt/files_old/hass/OVMF_CODE_4M.fd.virtnbdbackup.0]
[2024-03-22 21:38:51] INFO root virtnbdbackup - backupBootConfig [MainThread]: 
Save additional boot config [nvram] to: 
[/mnt/files_old/hass/hass_VARS.fd.virtnbdbackup.0]
Traceback (most recent call last):
  File "/usr/bin/virtnbdbackup", line 1115, in 
main()
  File "/usr/bin/virtnbdbackup", line 675, in main
saveFiles(args, vmConfig, disks, fileStream, logFile)
  File "/usr/bin/virtnbdbackup", line 711, in saveFiles
backupDiskInfo(args, disk)
  File "/usr/bin/virtnbdbackup", line 799, in backupDiskInfo
info = qemu.util("").info(disk.path, args.sshClient)
   ^
  File "/usr/lib/python3/dist-packages/libvirtnbdbackup/qemu/util.py", line 91, 
in info
return self.runcmd(cmd, toPipe=True)
   ^
  File "/usr/lib/python3/dist-packages/libvirtnbdbackup/qemu/util.py", line 
289, in runcmd
with subprocess.Popen(
 ^
  File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'qemu-img'



-- 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-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.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 virtnbdbackup depends on:
ii  libnbd-bin 1.14.2-1
ii  nbdkit 1.32.5-1
ii  nbdkit-plugin-python   1.32.5-1
ii  python33.11.2-1+b1
ii  python3-libnbd 1.14.2-1
ii  python3-libvirt9.0.0-1
ii  python3-lxml   4.9.2-1+b1
ii  python3-lz44.0.2+dfsg-1+b2
ii  python3-paramiko   2.12.0-2
ii  python3-tqdm   4.64.1-1
ii  python3-typing-extensions  4.4.0-1
ii  python3.11 3.11.2-6

virtnbdbackup recommends no packages.

virtnbdbackup suggests no packages.

-- no debconf information

Bug#1067519: O: tkrzw-python -- set of implementations of DBM - python binding

[Boyuan Yang]

Package: wnpp
Control: affects -1 + src:tkrzw-python
X-Debbugs-Cc: tkrzw-pyt...@packages.debian.org
Severity: normal

I intend to orphan the tkrzw-python package.
Future maintainers should also handle the underlying C++ library,
src:tkrzw.

The package description is:
 Tkrzw is a C++ library implementing DBM (Database Manager) with
 various algorithms. It features high degrees of performance,
 concurrency, scalability and durability.
 .
 This package contains the Python 3 binding of the library.

Thanks,
Boyuan Yang


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

Bug#1067518: O: tkrzw -- set of implementations of DBM

[Boyuan Yang]

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

I intend to orphan the tkrzw package since I no longer use it.
Future maintainer should also handle its python binding,
src:tkrzw-python.

The package description is:
 Tkrzw is a C++ library implementing DBM (Database Manager) with
 various algorithms. It features high degrees of performance,
 concurrency, scalability and durability.

Thanks,
Boyuan Yang


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

Bug#1067517: fai: Regression from 6.05 to 6.2.2, fai_disk_info gives empty list of hard drives

[Florian Goth]

Source: fai
Version: 6.0.3+deb12u1
Severity: normal
X-Debbugs-Cc: florian.g...@uni-wuerzburg.de

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

I tried to install debian bookworm via PXE(UEFI)to a Fujits-Siemens Box, a P720 
with a single magnetic drive.
It used to work for its last installation in december 2023, where the 
fai-release shipped in debian was 6.0.5.
Now Debian ships 6.2.2 and the installation fails with the error message that 
no hard drive is present in the system.
A change that occured during this time was a bigger rewrite in fai-disk-info, 
where a larger
grep expression was changed into:

all_disks_and_size | checkdisk $FAI_BOOTSTICK | once_only

the variable FAI_BOOTSTICK expands to an empty string in this setting.

Changing this line to
all_disks_and_size
# | checkdisk $FAI_BOOTSTICK | once_only

made the installation on this particular system work for me again.



-- System Information:
Debian Release: 12.5

Bug#1059325: bash: printf does not recognise numeric constants with explicit base 10

[Gioele Barabucci]

Control: tags -1 moreinfo

On Fri, 22 Dec 2023 15:12:12 +0100 Francesco =?utf-8?Q?Potort=C3=AC?= 
 wrote:

Package: bash
Version: 5.2.21-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

$ bash --version
GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ echo $((10#08))
8

pot@pot:~$ printf %d\\n 10#08
bash: printf: 10#08: invalid number
10

This is clearly a bug: printf should print no error, and just print 8 followed 
by newline.


The rules that apply to printf arguments are not the same rules that 
apply to $(( )). Here "10#08" is a plain string that is not interpreted 
at all by bash nor printf. Only inside $(( )) and a few other cases, 
"10#08" will be interpreted as the representation of a number in base 10 
(this is a bashism, other shells do not do that).


From ARITHMETIC EVALUATION in bash(1):

The  shell allows arithmetic expressions to be evaluated, under 
certain circumstances (see the let and declare builtin commands, the 
(( compound command, and Arithmetic  Expansion).>


[...]

Integer constants follow the C language definition, without suffixes>
or  character  constants.   Constants with a leading 0 are 
interpreted as octal numbers.  A leading 0x or 0X denotes 
hexadecimal.  Otherwise, numbers take the form [base#]n, where the 
optional  base is  a  decimal number between 2 and 64 representing 
the arithmetic base, and n is a number in that base.  If base# is 
omitted, then base 10 is used.



However, this only happens on one of my two boxes with Debian
testing.  The other one does not exhibit the bug, and printf just
prints 8 followed by newline.

That's interesting. What version of bash is installed in the other boxes?

Regards,

--
Gioele Barabucci

Bug#1067516: util-linux: sulogin should not render system inaccessable in single-user/emergency mode

[Philip Hands]

Package: util-linux
Severity: normal

The D-I team are just about to reword the root password prompt in a way that
will likely lead to more people taking the chance to lock root and rely upon
sudo from the initial user. This is something that's already possible, so this
wording change is at most going to increase the popularity of this option.

At present, this results in sulogin becoming useless (unless one reconfigures
it), because it prompts the user for a password that does not exist.

This situation prompted this MR against user-setup (in D-I):

  https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6

however it occurs to me that even if we adopt this, it does nothing to address
existing installs.

BTW That MR offers to configure things so that a locked root account will cause
sulogin to fail open, dropping the user into a root shell without asking for a
password.

While thinking about this, it occurs to me that one might be able to add an
option to sudo (-g perhaps) that would allow one to specify a group that should
be treated as a proxy for root when root's password is locked. Then, if that
option were specified, the users in the specified group ('sudo' on Debian) could
be allowed to specify their password instead, and if the password were correct,
be only then given root on the system. I guess one could either just check
against all group members for a match, or add a prompt for the username too.

This bug is therefore in two parts:

   1) ask users how they want this configured, if they have a locked root
  account, and have not been asked about it yet.

   2) implement the mentioned -g option, or come up with some other way of
  enabling the user to login during a single/emergency boot, without simply
  dropping the user straight into a root shell.

Cheers, Phil.

Bug#1067515: ITP: waymore -- Tool to discover extensive data from online archives

[aquilamacedo]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Aquila Macedo Costa 
Severity: wishlist

* Package name: waymore
  Version : 3.7
  Upstream Contact: @xnl-h4ck3r
* URL : https://github.com/xnl-h4ck3r/waymore
* License : Expat
  Programming Lang: Python3
  Description : Tool to discover extensive data from online archives

waymore is a versatile tool designed to extract comprehensive
information
from various sources including the Wayback Machine, Common Crawl, Alien
Vault
OTX, URLScan, and VirusTotal. Whether you're searching for historical
web data
or analyzing security threats, waymore provides a seamless experience
with its
intuitive interface and extensive features.

I'm writing to submit an Intention to Package (ITP) for waymore
under the pkg-security team's umbrella.

Bug#1067514: commons-configuration2: CVE-2024-29133

[Salvatore Bonaccorso]

Source: commons-configuration2
Version: 2.8.0-2
Severity: important
Tags: security upstream
Forwarded: https://issues.apache.org/jira/browse/CONFIGURATION-841
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for commons-configuration2.

CVE-2024-29133[0]:
| Out-of-bounds Write vulnerability in Apache Commons
| Configuration.This issue affects Apache Commons Configuration: from
| 2.0 before 2.10.1.  Users are recommended to upgrade to version
| 2.10.1, which fixes 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-29133
https://www.cve.org/CVERecord?id=CVE-2024-29133
[1] https://issues.apache.org/jira/browse/CONFIGURATION-841

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1029954: Problems with Bash

[Gioele Barabucci]

Control: tags -1 moreinfo

On Sun, 29 Jan 2023 14:23:01 + Mcgiwer  wrote:

Package: Bash
Version: any
Affect's following OS: Debian / Ubuntu / AntiX

Description:


I wanted to report unintended bad behaviour of Bash that cause problems with 
usage of it.


-   no possibility to neither unset, nor remove the readonly bit from the read 
only variables
-   changes of value on some variables aren't beeing set or are sillently 
dropped
-   there seem be a issue with output redirection (it isn't always working). 
Example: I run a command that should output into a file, but instead of thay, 
it output's to stdout.


Hi, you already filed bug 1010103 for the third issue.

Could you please provide runnable commands that show the other two 
issues, including what results you expect?


Regards,

--
Gioele Barabucci

Bug#1043037: Reasonable fork of MLMMJ available now

[Michael Jeanson]

On Sat, 23 Dec 2023 18:10:34 -0500 Chris Knadle  
wrote:

retitle 1043037 Switch upstream source to fork after release of MLMMJ 1.4
summary 1043037 MLMMJ upstream is dead since 2017, but users of MLMMJ 
have created a usable fork with new features; it's time to switch to it

thanks

New location for ongoing fork MLMMJ releases (current release is 1.4.3):
    https://codeberg.org/mlmmj/mlmmj/releases


Hi,

I've prepared an updated mlmmj 1.4.4 package in a personal repo [1], I've also 
been working with upstream to fix some issues I've encountered while updating 
the packaging code.


Please have a look and feel free to take only the pieces you like, I don't run 
an mlmmj server yet so other than running the test suite it's quite untested. 
There are some test failures on Salsa-CI which I'm unable to reproduce locally 
at the moment.


I would like to eventually migrate an existing mailman2 system to mlmmj after 
trixie is release, hence this effort.


Cheers,

Michael

[1] https://salsa.debian.org/mjeanson/mlmmj

Bug#1010103: [Bug report] Bash: issues with redirecting output

[Gioele Barabucci]

Control: rename -1 bash: output redirection is ineffective
Control: tags -1 moreinfo

On Sun, 24 Apr 2022 14:12:34 + Mcgiwer  wrote:

Package: bash
Serverity: serious

OS: Debian 11

Description:

I had found a strange issue in Bash: there is a problem with redirecting the 
output of some commands when executing them in the console.

I had attempted all variants (wroten as a template):

\`\`\`
\* command > file.txt
\* command >> file.txt
\* command 1> file.txt
\* command 2> file.txt
\* command 3> file.txt
\* command &> file.tx
\* command \| tee file.txt
\`\`\`

In every case the output was shown in the console and the file remained empty.

Could anyone check what's wrong?

I had tested it on:

\`\`\`
apt update \| grep "NO\_PUBKEY"
\`\`\`


Dear Mcgiwer,

is the command you tried to run

$ apt update | grep "NO_PUBKEY" > file.txt

?

In this case, the redirection mechanism was working like expected: what 
you are redirecting is the output of the last command, not of the whole 
pipeline. So the warnings printed on stderr by apt will never be 
redirected and will appear in your console.


If you want to redirect the collective output of all commands in a 
pipeline you can use


$ { cmd1 | cmd2 ; } > file.txt

Regards,

--
Gioele Barabucci

Bug#1067513: commons-configuration2: CVE-2024-29131

[Salvatore Bonaccorso]

Source: commons-configuration2
Version: 2.8.0-2
Severity: important
Tags: security upstream
Forwarded: https://issues.apache.org/jira/browse/CONFIGURATION-840
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for commons-configuration2.

CVE-2024-29131[0]:
| Out-of-bounds Write vulnerability in Apache Commons
| Configuration.This issue affects Apache Commons Configuration: from
| 2.0 before 2.10.1.  Users are recommended to upgrade to version
| 2.10.1, which fixes 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-29131
https://www.cve.org/CVERecord?id=CVE-2024-29131
[1] https://issues.apache.org/jira/browse/CONFIGURATION-840
[2] https://www.openwall.com/lists/oss-security/2024/03/20/4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded

[Amin Bandali]

Hi Carsten, all,

On Fri Mar 22, 2024 at 11:22 AM EDT, Carsten Schoenert wrote:
[...]
> > Thanks a lot for the follow up. Carsten can you confirm with TB if this 
> > works as
> > expected?
>
> I need to check this again and in detail, because I had recently some 
> issues as the expected hash ids were different while working with gbp 
> import and later gbp buildpackage on some package from the kicad 
> universe. But I think these problems are currently related to the t64 
> transition.
[...]

I'd run into a similar issue with gbp and I, too, initially suspected
t64, but I believe it was actually an issue with pristine-tar, that
Sebastian has sinced fixed, per https://bugs.debian.org/1065751.
I haven't had the chance to specifically try reproducing it with
pristine-tar 1.50+nmu2, but per Sebastian and my colleague Jeremy
it should now be fixed with that version of pristine-tar.  Otherwise
if you can still reproduce it please open a bug against pristine-tar
and let Sebastian know.

Thanks,
-a

Bug#1041832: #1041832: libsequoia-octopus-librnp: undeclared file conflict with thunderbird

[Holger Levsen]

hi,

< h01ger> helmut: re:  #1041832: i just could not reproduce this bug, see
https://paste.debian.net/1311659/ - though we "didnt change
anything" in sequoia-octopus, so what am i missing? :)

that paste had basically this content:

± dpkg -L libsequoia-octopus-librnp |grep librnp.so
/usr/lib/sequoia/libsequoia_octopus_librnp.so
/usr/lib/thunderbird/librnp.so
± dpkg -L thunderbird|grep librnp.so
1 ±

<   jochensp> | h01ger: 
https://packages.debian.org/search?searchon=contents=librnp.so=path=unstable=any
 says on ppc64
<   jochensp> | h01ger: also 
https://packages.debian.org/search?suite=bookworm=any=path=contents=librnp.so
< h01ger> jochensp: what? (re: ppc64 only)
<   jochensp> | h01ger: also thunderbird (1:115.0.1-1) has:
 [f78b777] d/mozconfig.default: Use internal shipped
 librnp version and 1:115.1.1-1 reverts that
< jochensp> (and ppc64 is out of date in unstable)
< h01ger> jochensp: ah! [f78b777] - thank you!
< h01ger> jochensp: can i quote you in that bug?
<   jochensp> | h01ger: sure
< h01ger> :) thanks!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Just because other people are also responsible, does not mean you are not
responsible.


signature.asc
Description: PGP signature

Bug#1067512: libglfw3-wayland is practically not installable

[Michel Le Bihan]

Package: libglfw3-wayland
Version: 3.3.10-1

Hello,

I noticed that libglfw3-wayland conflicts with libglfw3. That makes perfect 
sense since both packages provide the same .so files. However, most packages in 
Debian depend only on libglfw3. Take pink-pony as an example. It's not possible 
to have both pink-pony and libglfw3-wayland installed on the same system. I 
think that either libglfw3 should be a virtual package that depends on 
libglfw3-wayland or libglfw3-x11 or that libglfw3
 should have both backends enabled.

Michel Le Bihan

Bug#1064213: incus-agent: Incus Agent never starts due to ConditionPathExists

[Mathias Gibbens]

Control: tags -1 + help pending

On Sun, 2024-02-18 at 19:48 +, stefa...@debian.org wrote:
> It does that if incus-agent-setup is in the image. This was an image
> without incus-agent-setup, just your incus-agent package.

  The incus-agent package does include incus-agent-setup, which is
called from the service file's ExecStartPre stanza.

  I have synced up the packaged service file and setup script from the
current Incus release. It looks like some refactoring was done to move
from a systemd-triggered service to a udev rule-triggered start.
Hopefully that will resolve the issue you've been seeing.

> If the intention isn't to use the incus-agent package inside VMs, this
> should be declared more clearly.

  It was my intention that the incus-agent package should be usable
inside VMs. I appreciate the report that it wasn't.

> Use a bare image without incus-agent-setup to reproduce the bug.

  I have been unable to reproduce this myself. I've tried to do so a
variety of ways, but I'm guessing with my hardware/setup I'm just not
triggering the race condition in the same way.

  I've pushed commit a15849186e1c1945985f5bfd872ba4ce98eb3461 with the
incus-agent changes. It will be included with the Incus 0.7 upload,
hopefully sometime Monday. When the new version is available, I'd
appreciate if you could test to see if the changes in packaging for 0.7
resolve your issue.

Mathias


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

Bug#1042976: #1042976 seems to be solved

[Christian Britz]

The problem seems to be solved for arm64 with current version in
bookworm 3.6-4+deb12u1

Bug#1067511: libgpod: FTBFS with experimental libplist

[Gianfranco Costamagna]

Package: libgpod
Version: 0.8.3-19.1
Severity: normal
Tags: patch

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

  * Add two patches from arch linux
to fix FTBFS with newer libplist


Thanks for considering the patch.

*** /tmp/tmp5qufybct/libgpod_0.8.3-19.1ubuntu2.debdiff
diff -Nru libgpod-0.8.3/debian/patches/fix-new-libplist.patch 
libgpod-0.8.3/debian/patches/fix-new-libplist.patch
--- libgpod-0.8.3/debian/patches/fix-new-libplist.patch 1970-01-01 
01:00:00.0 +0100
+++ libgpod-0.8.3/debian/patches/fix-new-libplist.patch 2024-03-22 
14:54:42.0 +0100
@@ -0,0 +1,34 @@
+Description: Arch linux cherry-picked patch
+Origin: 
https://gitlab.archlinux.org/archlinux/packaging/packages/libgpod/-/commit/37664b35631261bf707e88132d5920757bcf0958
+Last-Update: 2024-03-22
+
+--- libgpod-0.8.3.orig/tools/ipod-lockdown.c
 libgpod-0.8.3/tools/ipod-lockdown.c
+@@ -100,7 +100,7 @@ read_sysinfo_extended_by_uuid (const cha
+   plist_get_string_val(ptr, );
+   if (str != NULL) {
+   ptr = plist_new_string(str);
+-  plist_dict_insert_item(value, "SerialNumber", ptr);
++  plist_dict_set_item(value, "SerialNumber", ptr);
+   free(str);
+   }
+
+@@ -112,15 +112,15 @@ read_sysinfo_extended_by_uuid (const cha
+   plist_get_string_val(ptr, );
+   if (str != NULL) {
+   ptr = plist_new_string(str);
+-  plist_dict_insert_item(value, "VisibleBuildID", ptr);
++  plist_dict_set_item(value, "VisibleBuildID", ptr);
+   free(str);
+   }
+
+   ptr = plist_new_string(uuid);
+-  plist_dict_insert_item(value, "FireWireGUID", ptr);
++  plist_dict_set_item(value, "FireWireGUID", ptr);
+
+   ptr = plist_new_string(uuid);
+-  plist_dict_insert_item(value, "UniqueDeviceID", ptr);
++  plist_dict_set_item(value, "UniqueDeviceID", ptr);
+
+   plist_to_xml(value, , _length);
+
diff -Nru libgpod-0.8.3/debian/patches/newer-plist.patch 
libgpod-0.8.3/debian/patches/newer-plist.patch
--- libgpod-0.8.3/debian/patches/newer-plist.patch  1970-01-01 
01:00:00.0 +0100
+++ libgpod-0.8.3/debian/patches/newer-plist.patch  2024-03-22 
14:54:42.0 +0100
@@ -0,0 +1,14 @@
+Description: Patch for newer libplist pkgconfig file
+Origin: 
https://gitlab.archlinux.org/archlinux/packaging/packages/libgpod/-/commit/c8b8b172f84270323a227a1df565af1713c0bafb
+
+--- libgpod-0.8.3.orig/configure.ac
 libgpod-0.8.3/configure.ac
+@@ -42,7 +42,7 @@ AC_CHECK_FUNCS([localtime_r])
+ AC_CHECK_MEMBERS([struct tm.tm_gmtoff],,,[#include ])
+ dnl sqlite3 is needed for newer ipod models (nano5g), and libplist is needed
+ dnl by libgpod sqlite code
+-PKG_CHECK_MODULES(LIBGPOD, glib-2.0 >= 2.16.0 gobject-2.0 sqlite3 libplist >= 
1.0 gmodule-2.0)
++PKG_CHECK_MODULES(LIBGPOD, glib-2.0 >= 2.16.0 gobject-2.0 sqlite3 libplist-2.0 
>= 1.0 gmodule-2.0)
+
+ dnl ***
+ dnl The following functions are only available starting
diff -Nru libgpod-0.8.3/debian/patches/series 
libgpod-0.8.3/debian/patches/series
--- libgpod-0.8.3/debian/patches/series 2023-12-09 14:05:31.0 +0100
+++ libgpod-0.8.3/debian/patches/series 2024-03-22 14:54:42.0 +0100
@@ -3,3 +3,5 @@
 Upstream-change-to-speed-up-itdb_resolve_path-calls.patch
 Fix-System-GLib.DateTime-ambiguity.patch
 Fix-wrong-char-for-comments-in-gpod.i.patch
+newer-plist.patch
+fix-new-libplist.patch

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]

Control: severity -1 serious

Hi Andreas,

On Thu, Mar 14, 2024 at 09:08:50PM +0100, Salvatore Bonaccorso wrote:
> 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).

I'm reconsidering the above statement of myself.

As this in meanwhile has been fixed in experimental, and in my point
of view, it is to be considered a batch of issues which we want to see
fixed in trixie I'm going to raise the severity again to RC, to make
clear the intention.

Andreas, I hope this is still fine with you, and making clear we
should have the version in experimental to go to trixie. Again this is
orthogonal to a no-dsa marking perspective.

Regards,
Salvatore

Bug#996202: EFI Secure Boot for systemd-boot

[Luca Boccassi]

On Mon, 4 Mar 2024 at 23:58, Luca Boccassi  wrote:
>
> On Mon, 4 Mar 2024 at 23:28, Steve McIntyre  wrote:
>
> > Modulo those questions, let's talk infrastructure. Off the top of my
> > head, in no particular order...
> >
> >   * We'll need to create a new intermediate signing cert for
> > systemd-boot (and another for UKI, I guess). Given recent
> > discussions about changing the way we build and sign kernels, we
> > should also generate a new signer cert for those too. And if we're
> > going that far, we may as well generate a complete new set of 2024
> > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA about
> > doing this piece.
>
> That makes sense to me, I guess DSA owns the machinery to do this?
>
> >   * We'll probably need to add things to the signing setup for
> > ftp-master. Nothing earth-shattering, just some config to
> > recognise the new set of packages IIRC. I'm sure Bastian can
> > manage this. :-)
> >
> >   * Are people from the team ready to deal with long-term security
> > support for the systemd-boot chain?
>
> Speaking for myself, yes, I am already part of the team who is
> responsible for that upstream, and I plan to be very strict about not
> carrying downstream patches for the signed components outside of
> security fixes (and even then, prefer upstream stable point releases
> that I am also responsible for anyway).
>
> > That's all I can think of for now, but I wouldn't be surprised if more
> > comes to mind tomorrow... :-)
>
> Thanks for the feedback!

Gentle ping on this - what are the next steps in order to make this happen?

Bug#1067309: xerces-c: FTBFS: Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file: No

[Matthias Klose]

On 22.03.24 18:08, Andrey Rakhmatullin wrote:

On Wed, Mar 20, 2024 at 09:54:25PM +0100, Lucas Nussbaum wrote:

Exception in thread "main" java.lang.UnsatisfiedLinkError: 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open 
shared object file: No such file or directory

/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so links against
libharfbuzz.so.0 (ant other libraries) but openjdk-17-jre-headless since
17.0.10+7-3 only Recommends libharfbuzz0b (and other library packages).
As the change in openjdk-17-jre-headless is intentional, I guess B-D in
xerces-c need to be expanded?



yes, just remove the -headless alternative.

Bug#1063915: mirror submission for debian.mirrors.ovh.net

[Louis Sautier]

On 3/22/24 17:42, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

On Wed, 2024-02-14 at 20:03 +, OVHcloud wrote:

Site: debian.mirrors.ovh.net
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Maintainer: OVHcloud
Country: FR France
Location: Anycast (Gravelines, Roubaix and Strasbourg)


Hi Adam,

First, let me just explain in a bit more detail how requests are 
handled. Our DNS A record for debian.mirrors.ovh.net only points to one 
anycast IP address with 4 locations. Once it receives a request, the 
following happens:


Load balancer (anycast IP) in Beauharnois (Canada)→ Caches in 
Beauharnois → Backend in Canada if cache miss


Load balancer (anycast IP) in Gravelines (France)→ Caches in Gravelines 
→ Backend in France if cache miss


Load balancer (anycast IP) in Roubaix(France)→Caches in Roubaix→ Backend 
in France if cache miss


Load balancer (anycast IP) in Strasbourg(France)→Caches in Strasbourg→ 
Backend in France if cache miss



I know there was some discussion on IRC, so apologies if I'm rehashing
here, but:

- are the individual backends exposed in any way?
Not publicly, but if you were to give me me a source IP address, I could 
provide you with an rsync account that has access to both our backends. 
We already do this for other distributions.

- how do you ensure that the backends are in sync with each other?


We take ZFS snapshots after each sync and we send these to the backends. 
Once the latest snapshot has been sent to both backends, they start 
pointing to it. This last operation is performed simultaneously on both.


After this, we compile a list of changed URLs and issue a series of HTTP 
PURGE requests to every cache server, simultaneously too.


We also have monitoring in place to detect discrepancies between the 
backends for all our mirrors.



- what are the chances of users seeing inconsistent state if they hit
different backends which aren't at the same stage of updating?


I think the chances are pretty low as we try to run all phases of the 
sync simultaneously. The most sensitive part would be the cache 
invalidation process which might purge some URLs at slightly different 
times.


All I can say is that, despite the high number of servers already 
relying on our Debian mirror, we have never heard of errors caused by this.



Regards,

Adam


I hope this answers all your questions.


Have a nice day,


Louis

Bug#1054102: Auto-Réponse / Auto-Reply: Bug#1054102 closed by "Adam D. Barratt" (Re: Bug#1054102: mirror submission for debian.savoirfairelinux.net)

[File par défaut via RT]

Bonjour,

Votre message a bien été enregistré par notre système de suivi. Votre numéro de 
ticket est le 429756.

Si vous souhaitez envoyer d'autres courriels concernant cette demande, merci 
d'inclure dans le sujet le code [Ticket #429756]), ou bien répondez directement 
à ce courriel. 

Cordialement,
Centre de support Savoir-Faire Linux
supp...@savoirfairelinux.com

--

Greetings,

Your support request has been recorded in our ticket management system, and 
your ticket number is 429756.

If you wish to send additional e-mails concerning your support request, please 
include your ticket number ( [Ticket #429756] ) in the subject line, or reply 
to this e-mail.

Regards,
Savoir-Faire Linux support center
supp...@savoirfairelinux.com
-

This is an automatic notification regarding your Bug report
which was filed against the mirrors package:

#1054102: mirror submission for debian.savoirfairelinux.net

It has been closed by "Adam D. Barratt" .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact "Adam D. Barratt" 
 by
replying to this email.


-- 
1054102: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054102
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1053191: mirror submission for mirror.kpfu.ru

[Adam D. Barratt]

Control: tags -1 + moreinfo

Hi,

Apologies for the delay in getting back to you.

On Fri, 2023-09-29 at 06:50 +, kpfu.ru wrote:
> Site: mirror.kpfu.ru
> Archive-architecture: amd64 i386

Our automated checks noticed an issue with your mirror:

o The trace file at
  http://mirror.kpfu.ru/debian/project/trace/mirror.kpfu.ru
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your trace file is missing one or both of them.


As an additional note, is there a reason that you only mirror amd64
packages? In general users will expect mirrors to carry all
architectures.

Regards,

Adam

Bug#921750: security-warning hook not found, fails open

[Santiago Ruano Rincón]

On Fri, 08 Feb 2019 15:18:55 -0500 Antoine Beaupre  wrote:
> Package: dput-ng
> Version: 1.22
> Severity: important
> 
> Hi!
> 
> I tried switching to dput-ng again, and here's what happened:
> 
> anarcat@curie:dist$ dput security-master 
> libreoffice_4.3.3-2+deb8u12_amd64.changes
> Uploading libreoffice using ftp to security-master (host: 
> ftp.security.upload.debian.org; directory: /pub/SecurityUploadQueue)
> running allowed-distribution: check whether a local profile permits uploads 
> to the target distribution
> running protected-distribution: warn before uploading to distributions where 
> a special policy applies
> running checksum: verify checksums before uploading
> running suite-mismatch: check the target distribution for common errors
> running gpg: check GnuPG signatures before the upload
> Could not execute /usr/share/dput/helper/security-warning: [Errno 2] No such 
> file or directory: '/usr/share/dput/helper/security-warning': 
> '/usr/share/dput/helper/security-warning'
> Error: You've set a hook (pre_upload_command) to run 
> (`/usr/share/dput/helper/security-warning`), but it can't be found (and 
> doesn't appear to exist). Please verify the path and correct it.
> Uploading libreoffice_4.3.3-2+deb8u12.dsc
> Uploading libreoffice_4.3.3-2+deb8u12.debian.tar.xz
> Uploading libreoffice_4.3.3-2+deb8u12_amd64.deb
> [...]
> 
> ie. it didn't find the `security-warning` file it's supposed to show
> and prompt the user but worse, it then just went on uploading the
> package normally.
> 
> The warning should be shown, and failing that, the upload should fail
> if the hook is missing.
> 
> Thanks for the nice work! :)

I've also been hit by this. And the problem seems to be the old-style
/etc/dput.cf, that overrides the dput-ng profiles. I've purged dput,
hoping this would help the next time.

FWIW, dput-ng comes with a protected-distribution hook, that has the
same goal of security-warning.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1058071: mirror submission for mirrors.cat.pdx.edu

[Adam D. Barratt]

Control: tags -1 + moreinfo

Hi,

Apologies for the delay in getting back to you.

On Mon, 2023-12-11 at 23:52 +, Sage Imel wrote:
> Site: mirrors.cat.pdx.edu
> Archive-architecture: amd64 arm64 armhf hurd-amd64 i386 riscv64

Our automated checks noticed an issue with your mirror:

o The trace file at
  http://mirrors.cat.pdx.edu/debian/project/trace/mirrors.cat.pdx.edu
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your trace file is missing one or both of them.

As an additional note, is there a reason that you only mirror a subset
of Debian's official architectures?

Architectures-Configuration: EXCLUDE alpha arm armel hppa hurd-i386 ia64 
kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc s390 s390x sh sparc 

armel, mipsel and s390x are all currently supported architectures and
would be expected to appear on all Debian mirrors.

Regards,

Adam

Bug#1067510: O: cjson -- Ultralightweight JSON parser in ANSI C

[Boyuan Yang]

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

I intend to orphan the cjson package. Future maintainer should be aware that
there are now several non-DSA open CVEs in Debian Bookworm that should be
fixed.

The package description is:
 cJSON is a ultralightweight json parse.
 .
 It aims to be the dumbest possible parser that you can get your job done with.
 .
 It's a single file of C, and a single header file.

Thanks,
Boyuan Yang


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

Bug#1067309: xerces-c: FTBFS: Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file: No

[Andrey Rakhmatullin]

On Wed, Mar 20, 2024 at 09:54:25PM +0100, Lucas Nussbaum wrote:
> > Exception in thread "main" java.lang.UnsatisfiedLinkError: 
> > /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: 
> > cannot open shared object file: No such file or directory
/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so links against
libharfbuzz.so.0 (ant other libraries) but openjdk-17-jre-headless since
17.0.10+7-3 only Recommends libharfbuzz0b (and other library packages).
As the change in openjdk-17-jre-headless is intentional, I guess B-D in
xerces-c need to be expanded?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1067504: python3-numba: Can not be installed.

[Diane Trout]

On Fri, 2024-03-22 at 15:58 +, Elizabeth Loss-Cutler-Hull wrote:
> Package: python3-numba
> Version: 0.59.0+dfsg-1
> Severity: serious
> 
> In Debian sid, python3-numba currently depends on python3-numpy (<
> 1:1.25) and python3-numpy (>= 1:1.22.0).
> 
> However the currently available version of python3-numpy is
> 1:1.26.4+ds-6, rendering python3-numba uninstallable.
> 

Ah that's what I did wrong.

Thank you for pointing the out of date version. I should have an fix
uploaded soon.

Diane

Bug#1067075: openvas-scanner: FTBFS on arm{el,hf}: /<>/src/attack.c:1617:16: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘__time64_t’ {aka ‘long long

[Simon Chopin]

Package: openvas-scanner
Followup-For: Bug #1067075
X-Debbugs-Cc: scho...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch ftbfs

Hi,

The attached patch should fix this (shipped in Ubuntu).

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

Kernel: Linux 6.8.0-11-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
openvas-scanner-22.7.9/debian/patches/Fix-printf-specifiers-for-time_t-related-types.patch
 
openvas-scanner-22.7.9/debian/patches/Fix-printf-specifiers-for-time_t-related-types.patch
--- 
openvas-scanner-22.7.9/debian/patches/Fix-printf-specifiers-for-time_t-related-types.patch
  1970-01-01 01:00:00.0 +0100
+++ 
openvas-scanner-22.7.9/debian/patches/Fix-printf-specifiers-for-time_t-related-types.patch
  2024-03-22 17:51:47.0 +0100
@@ -0,0 +1,75 @@
+From b75d19ecd90498e6d005c62b8fd4d31f3909a5cb Mon Sep 17 00:00:00 2001
+From: Simon Chopin 
+Date: Fri, 22 Mar 2024 17:43:22 +0100
+Subject: [PATCH] Fix printf specifiers for time_t-related types
+
+Best to only use fixed-width types and explicit casting.
+---
+ src/attack.c   | 8 +---
+ src/pluginlaunch.c | 8 +---
+ 2 files changed, 10 insertions(+), 6 deletions(-)
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067075
+diff --git a/src/attack.c b/src/attack.c
+index 120a3cd..3c76b31 100644
+--- a/src/attack.c
 b/src/attack.c
+@@ -44,9 +44,11 @@
+ #include  /* for nvticache_t */
+ #include 
+ #include 
++#include 
+ #include/* for strlen() */
+ #include  /* for waitpid() */
+ #include/* for close() */
++#include 
+ 
+ #define ERR_HOST_DEAD -1
+ 
+@@ -987,9 +989,9 @@ attack_start (struct ipc_context *ipcc, struct 
attack_start_args *args)
+   now.tv_usec += 100;
+ }
+   g_message (
+-"Vulnerability scan %s finished for host %s in %ld.%.2ld seconds",
+-globals->scan_id, ip_str, (long) (now.tv_sec - then.tv_sec),
+-(long) ((now.tv_usec - then.tv_usec) / 1));
++"Vulnerability scan %s finished for host %s in %"PRIu64".%.2"PRIu32" 
seconds",
++globals->scan_id, ip_str, (uint64_t) (now.tv_sec - then.tv_sec),
++(uint32_t) ((now.tv_usec - then.tv_usec) / 1));
+ }
+ }
+ 
+diff --git a/src/pluginlaunch.c b/src/pluginlaunch.c
+index d9d1dee..66ac683 100644
+--- a/src/pluginlaunch.c
 b/src/pluginlaunch.c
+@@ -24,8 +24,10 @@
+ #include "utils.h"
+ 
+ #include   /* for errno() */
++#include 
+ #include  /* for prefs_get_bool() */
+ #include 
++#include 
+ #include   /* for perror() */
+ #include  /* for atoi() */
+ #include 
+@@ -187,10 +189,10 @@ update_running_processes (kb_t main_kb, kb_t kb)
+ {
+   char *name = nvticache_get_filename (oid);
+   g_message (
+-"%s (%s) [%d] finished its job in %ld.%.3ld seconds",
++"%s (%s) [%d] finished its job in 
%"PRIu64".%.3"PRIu32" seconds",
+ name, oid, processes[i].pid,
+-(long) (now.tv_sec - processes[i].start.tv_sec),
+-(long) ((now.tv_usec - processes[i].start.tv_usec)
++(uint64_t) (now.tv_sec - processes[i].start.tv_sec),
++(uint32_t) ((now.tv_usec - processes[i].start.tv_usec)
+ / 1000));
+   g_free (name);
+ }
+
+base-commit: d6f2b322940b50ce5f2a6e121c6b41c57d9bbd26
+-- 
+2.43.0
+
diff -Nru openvas-scanner-22.7.9/debian/patches/series 
openvas-scanner-22.7.9/debian/patches/series
--- openvas-scanner-22.7.9/debian/patches/series2023-12-19 
14:10:26.0 +0100
+++ openvas-scanner-22.7.9/debian/patches/series2024-03-22 
17:51:47.0 +0100
@@ -1,3 +1,4 @@
 Fix-test-failure.patch
 Use-pkg_check_modules-when-required.patch
 Adapt-the-redis-config-file-for-Kali.patch
+Fix-printf-specifiers-for-time_t-related-types.patch

Bug#1067509: debhelper: Can't locate Debian/Debhelper/Dh_Lib.pm in @INC

[Andreas Beckmann]

Package: debhelper
Version: 13.15
Severity: grave
Justification: makes everything FTBFS

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

Can't locate Debian/Debhelper/Dh_Lib.pm in @INC (you may need to install the 
Debian::Debhelper::Dh_Lib module) (@INC entries checked: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.38.2 /usr/local/share/perl/5.38.2 
/usr/lib/x86_64-linux-gnu/perl5/5.38 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.38 
/usr/share/perl/5.38 /usr/local/lib/site_perl) at /usr/bin/dh line 15.
BEGIN failed--compilation aborted at /usr/bin/dh line 15.

Once a fixed version is in the archive, please give-back everything
failed because of this debhelper bug.


Andreas

Bug#1067508: debhelper: lost most of its dependencies in 13.15

[Simon McVittie]

Package: debhelper
Version: 13.15
Severity: grave
Justification: renders package unusable
Control: block 1036884 by -1

debhelper 13.14.1 has:

Depends: autotools-dev, dh-autoreconf (>= 17~), dh-strip-nondeterminism (>= 
0.028~), dpkg (>= 1.18.0~), dpkg-dev (>= 1.18.2~), dwz (>= 0.12.20190711), file 
(>= 3.23), libdebhelper-perl (= 13.14.1), libdpkg-perl (>= 1.17.14), man-db, 
po-debconf, perl:any

According to its buildd log (I haven't upgraded to the new version locally
yet), debhelper 13.15 only has:

Depends: perl:any

This leads to multiple packages failing to build from source because
one of the dh_ tools cannot load Dh_Lib, for example in
.

I suspect this might have regressed in
?

smcv

Bug#1067507: lomiri-ui-toolkit ftbfs with Python 3.12

[Matthias Klose]

Package: src:lomiri-ui-toolkit
Version: 1.3.5012+dfsg-5
Severity: important
Tags: sid trixie patch
User: debian-pyt...@lists.debian.org
Usertags: python3.12

lomiri-ui-toolkit ftbfs with Python 3.12, patch at
http://launchpadlibrarian.net/720653257/lomiri-ui-toolkit_1.3.5012+dfsg-5_1.3.5012+dfsg-5ubuntu1.diff.gz

I didn't check if the quoting is correct.

Bug#1063915: mirror submission for debian.mirrors.ovh.net

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2024-02-14 at 20:03 +, OVHcloud wrote:
> Site: debian.mirrors.ovh.net
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/
> Maintainer: OVHcloud 
> Country: FR France
> Location: Anycast (Gravelines, Roubaix and Strasbourg)

I know there was some discussion on IRC, so apologies if I'm rehashing
here, but:

- are the individual backends exposed in any way?
- how do you ensure that the backends are in sync with each other?
- what are the chances of users seeing inconsistent state if they hit
different backends which aren't at the same stage of updating?

Regards,

Adam

Bug#1067506: Please provide new upstream version

[Matthias Geiger]

Package: python3-pykeepass
Severity: wishlist
X-Debbugs-Cc: tc...@debian.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainers,

please provide the latest upstream release (4.0.7), as this is needed
for the new version of src:secrets.

best,

werdahias

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 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: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages python3-pykeepass depends on:
ii  python3   3.11.8-1
pn  python3-argon2
ii  python3-construct 2.10.68+dfsg1-2
ii  python3-dateutil  2.8.2-3
ii  python3-lxml  5.1.0-1
ii  python3-pycryptodome  3.20.0+dfsg-1

python3-pykeepass recommends no packages.

python3-pykeepass suggests no packages.

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmX9susVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1NIAP/RVfRWiGZp7W5ygjIEUBMnPQg9RG
HRmr+HxjXPM8glDDyoogZUyFagw5hu6nA3wJMMZcwPaASYil7ft9V1qjUkgPZgaL
RmZ8WRYKgpqdTcqkADYfopssvOzxlPaTFSfFD98P/wNU2fk+BA7tFYBHZLZOkA6a
qf4WCvf1vkAPYwZiTfcKv8Ih7ZfiNEXMUS3DcWq6jArHuUML8P9M4hP4qz3V4RXC
o6ARYY7lcpoEkW+pehcyfvegX85oUgZKDJQcStACR5piMSSlm2+Pw3GBMo0CWQth
QTLCwEwlXucA9Kf8MAmGcpeTieWGUd5t9qah2LbBgX3bkg836wdGUyT33PXOtCKy
MAlfP8XZO5XLyM7UixEVr/C1q+RuMfOkePxqJCfYL+axoSqI/kIXExLkKguC5bBm
6z828bQI2D+Ns5MSEUOlSKWsGitumVGDOkOG1+1BVPdIktwSX0Uzl/Vb6g8nxaR1
D2IEh8cHKlyMFtgKkRk/3QXBYhBs47zDtXYuYlkc7ZqEzvTSARAfVf29bqdh5J6x
hz5kqwj9PpdWLfZQ52G9N34pj2tjIjaJ6iUgLCND4mk4zmbGPYEGdj8drqxat6J5
H3Ck5D58g6u3o6vfIXHAewusUwQ058UkfFJ67mz6pEootU/m3TAYIuheyOSTDDLK
Htx/cV0HQQPkI2Dg
=9xze
-END PGP SIGNATURE-

Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'

[Andrey Rakhmatullin]

On Sun, Mar 17, 2024 at 06:30:27PM +, Thorsten Glaser wrote:
> In file included from ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:14:
> ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c: In function 
> 'mca_btl_ofi_get':
> ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.h:33:13: error: implicit 
> declaration of function 'OPAL_THREAD_ADD_FETCH64'; did you mean 
> 'OPAL_THREAD_ADD_FETCH32'? [-Werror=implicit-function-declaration]
>33 | OPAL_THREAD_ADD_FETCH64(&(module)->outstanding_rdma, 1);  
>   \
>   | ^~~
> ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:70:5: note: in expansion of 
> macro 'MCA_BTL_OFI_NUM_RDMA_INC'
>70 | MCA_BTL_OFI_NUM_RDMA_INC(ofi_btl);
OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64, and
I suspect not all of its uses also are. And I assume this arch doesn't
have 64-bit atomics.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1066115: mpg123: FTBFS: error: implicit declaration of function ‘mpg321_alsa_get_volume’ [-Werror=implicit-function-declaration]

[Joachim Reichel]

tag 1066115 + patch
thanks

Hi,

attached is the debdiff for the NMU, uploaded to delayed/10. Similar to the 
previous NMU it adds -Wno-error=implicit-function-declaration to downgrade these 
errors back into warnings again.


Best regards,
  Joachimdiff -Nru mpg321-0.3.2/debian/changelog mpg321-0.3.2/debian/changelog
--- mpg321-0.3.2/debian/changelog   2020-07-23 17:22:42.0 +0200
+++ mpg321-0.3.2/debian/changelog   2024-03-21 21:39:07.0 +0100
@@ -1,3 +1,11 @@
+mpg321 (0.3.2-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add -Wno-error=implicit-function-declaration to CFLAGS to disable
+new defaults from dpkg-buildflags (Closes: #1066115).
+
+ -- Joachim Reichel   Thu, 21 Mar 2024 20:39:07 +
+
 mpg321 (0.3.2-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mpg321-0.3.2/debian/rules mpg321-0.3.2/debian/rules
--- mpg321-0.3.2/debian/rules   2020-07-23 17:22:42.0 +0200
+++ mpg321-0.3.2/debian/rules   2024-03-21 21:37:50.0 +0100
@@ -4,7 +4,7 @@
 #export DH_VERBOSE=1
 
 
-export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused 
-Wno-error=format-security -Wno-error=implicit-function-declaration -fcommon 
+export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused 
-Wno-error=format-security -Wno-error=implicit-function-declaration -fcommon
 
 MPG321_ARCH = $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
 

Bug#1067488: mirror listing update for mirror.lon.macarne.com

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Fri, 2024-03-22 at 10:36 +, Arne wrote:
> Submission-Type: update
> Site: mirror.lon.macarne.com
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Arne 

The only change here from #1067086 seems to be that the original
request has:

Maintainer: Macarne LLC 

Do you want it changing to the individual address instead?

Regards,

Adam

Bug#1064431: mirror submission for mirror.fra.macarne.com

[Adam D. Barratt]

Control: forcemerge 1067082 -1

Hi,

This has been handled in the duplicate #1067082.

Regards,

Adam

On Fri, 2024-02-23 at 07:59 +0800, Arne Ruhnau wrote:
> Hi, should be fixed thanks. Arne
> 
> > On Feb 23, 2024, at 2:24 AM, Adam D. Barratt
> >  wrote:
> > 
> > Control: tags -1 + moreinfo
> > 
> > On Wed, 2024-02-21 at 23:45 +, Macarne LLC wrote:
> > > Submission-Type: new
> > > Site: mirror.fra.macarne.com
> > 
> > Our automated checks found an issue with your mirror:
> > 
> > o The trace file at
> >  
> > http://mirror.fra.macarne.com/debian/project/trace/mirror.fra.macarn
> > e.com
> >  is missing some required information.
> > 
> >  We expect at least the Maintainer and Upstream-mirror values to be
> > filled in,
> >  and your trace file is missing one or both of them.
> > 
> > 
> > Please fix that and let us know once it's done.
> > 
> > Regards,
> > 
> > Adam
> 

Bug#1067505: libc-bin: iconv: misleading error "illegal input sequence"

[Frank Heckenbach]

Package: libc-bin
Version: 2.36-9+deb12u4
Severity: normal
File: /usr/bin/iconv

% printf '\xc3\xa4' | iconv -futf8 -tascii
iconv: illegal input sequence at position 0

- First, according to the FSF's own coding standards
  (https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html),
  it should be "invalid" instead of "illegal" since this byte sequence is not
  "prohibited by law".

- The input sequence is not even invalid. It's correct UTF-8 for U+00E4.
  The actual problem is that this character is not representable in the output
  charset. The message gives no indication about this.

- I tried to report it upstream, but that's also broken. According to
  https://www.gnu.org/software/libc/manual/html_node/Reporting-Bugs.html, bugs
  should be reported at https://www.gnu.org/software/libc/bugs.html, but this
  page redirects to https://www.gnu.org/savannah-checkouts/gnu/libc/index.html
  which does not mention reporting bugs.

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc-bin depends on:
ii  libc6  2.36-9+deb12u4

Versions of packages libc-bin recommends:
ii  manpages  6.03-2

libc-bin suggests no packages.

-- debconf-show failed

Bug#1067504: python3-numba: Can not be installed.

[Elizabeth Loss-Cutler-Hull]

Package: python3-numba
Version: 0.59.0+dfsg-1
Severity: serious

In Debian sid, python3-numba currently depends on python3-numpy (< 1:1.25) and 
python3-numpy (>= 1:1.22.0).

However the currently available version of python3-numpy is 1:1.26.4+ds-6, 
rendering python3-numba uninstallable.

Regards,
Elizabeth.

Bug#1067503: ITP: golang-github-crc-org-crc -- Helper tool for running containers

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-crc-org-crc
  Version : 2.34.0-1
  Upstream Author : CRC Runs Containers
* URL : https://github.com/crc-org/crc
* License : Apache-2.0
  Programming Lang: Go
  Description : Helper tool for running run containers.

New dependency of podman 5.0

Bug#1066828: xz-utils: worse compression ratio should be announced in NEWS.Debian

[Vincent Lefevre]

On 2024-03-14 00:35:53 +0100, Vincent Lefevre wrote:
> Since this affects what the user gets and is some kind of regression,
> this should be announced in NEWS.Debian, IMHO.

As an example of how this can affect the user, this introduced a
serious bug in pristine-tar:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063252
(what is expected here can also be expected by the end user for
his own needs...)

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

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Dmitry Shachnev]

Hi,

On Fri, Mar 22, 2024 at 03:30:55PM +0100, Holger Wansing wrote:
> Ok, I see.
> So, we will need to get sphinx-rtd-theme-common installed on all debian.org
> website mirrors, and it will just work (?) ...

From your earlier message it seemed to me like you are using the build
tree in your deploy process, not the built package.

That is why I suggested not running dh_sphinxdoc, however my suggestion
applied only to your deploy procedure. The package which is being uploaded
to Debian archive should still use dh_sphinxdoc.

If you are using the built package and installing it on the remote server,
then yes, install sphinx-rtd-theme-common and you should be good.

Actually, I would move ${sphinxdoc:Depends} from Recommends to Depends,
because the documentation is mostly unusable without the static files.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library

[bret curtis]

Hello Matt,

On Sun, Mar 10, 2024 at 11:00 PM  wrote:

> Thanks Bret for your work to package this. I've been keeping an eye on
> upstream
> and this ITP for a while.
>

I'm glad someone is! I appreciate it.


> One thing I noticed is that upstream integrated their own fork [1] of
> glslang
> directly into the build [2] as of 1.0.3 [3]. Their reasoning was that:
>

Indeed, I created an issue to track this and Robert is aware of the
situation. AnyOldName3 and myself are working together with upstream
glslang that would make it findable and work correctly via cmake so that
cmake itself would not have to carry its own vulkan and glslang files. [1]


> I believe this approach would violate Debian Policy on vendored
> dependencies,
> which are already available in glslang-dev.
>

Agreed and I've held off pushing this further until I could get
vulkanscenegraph package to build against system glslang. It's actually
much worse that that, it will try to pull in the glslang code during cmake
configuration time, which is not allowed during buildd.


> I see a few options:
>
> 1) We work with upstream to unvendor the dependency
>

We are already doing this. :) The trickle down should be happening now.  [2]


> 2) We disable the shader compiler part of vsg
>

Please no; while this would get the package into Debian faster it would be
useless for OpenMW, or specifically the Vulkan work we are doing there
which makes use of VSG's glslang.


> 3) We patch the build to depend on Debian's glslang package
>

If we can't wait for 1 to trickle down into Debian's repo; this is a way
forward. I have a branch I've been working on that would resolve that.  [3]

What are your thoughts?

Cheers,
Bret

[1] https://github.com/vsg-dev/VulkanSceneGraph/issues/1035
[2]
https://vulkan.lunarg.com/issue/home?limit=10;q=;mine=false;org=false;khronos=false;lunarg=false;indie=false;status=new,open
[3] https://github.com/psi29a/VulkanSceneGraph/pull/5

Bug#618332: rxvt-unicode: screen contents not restored when detaching a "screen" session

[Vincent Lefevre]

Control: forwarded -1 https://savannah.gnu.org/bugs/?65506

On 2024-03-22 15:59:31 +0100, Vincent Lefevre wrote:
> Actually it still occurs in rxvt-unicode 9.31-3 from Debian/unstable.
> I might have done something wrong.

and I've just reported the bug upstream (GNU Screen).

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

Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded

[Carsten Schoenert]

Hi Guido,

Am 22.03.24 um 09:35 schrieb Guido Günther:
...

I got pointed here by Amin.
As mentioned, pristine-tar can handle multi-block xz images so this is
not an issue. Further xz-utils v5.6.0+ (currently in unstable/ testing)
is using multi threaded compression by default.


ahh, that would explain why my last work on kicad-packages3d and in 
detail the pristine-tar commit did not take the usual hour and did take 
only about 10-15min! :-)



So this *might* be considered fixed. >

Thanks a lot for the follow up. Carsten can you confirm with TB if this works as
expected?


I need to check this again and in detail, because I had recently some 
issues as the expected hash ids were different while working with gbp 
import and later gbp buildpackage on some package from the kicad 
universe. But I think these problems are currently related to the t64 
transition.


The last work on TB at the start of the work did work flawless.

@Guido
Please poke me again latest 2 weeks in case I don't have give feedback 
until then.


--
Mit freundlichen Grüßen
Carsten Schönert

Bug#987013: Release goal proposal: Remove Berkeley DB

[Marco Moock]

On Sat, 4 Feb 2023 08:50:29 +0100 Paul Gevers  wrote:

> > Remove Berkeley DB (finally)
> 
> Sure. But I agree with several readers of this bug that there should
> be a plan. We shouldn't kill it until the users are able to sanely
> move away from it. I doubt that will happen automatically, so
> somebody needs to organize it.

Is there a reason against switching to this fork under the old license?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010965

There are still applications using bdb by default and that means there
should be tools to read and edit them for the next years to support a
migration.

Bug#1067440: Compression makes searching packages very slow

[Laurențiu Nicola]

Thanks for the quick fix, I can confirm it's much faster now:

# apt 2.7.13, trixie
$ time apt search librust-
real0m30.185s
user0m28.286s
sys 0m1.729s

# apt 2.7.14, trixie
$ time apt search librust-
real0m0.640s
user0m0.490s
sys 0m0.035s

And sorry for the empty subject, it was my first time using bugs.debian.org. It 
told me to add comments by sending an email to the bug address and I didn't 
know whether to copy-paste the original subject. It's not like I can manually 
set In-Reply-To and References from my email client, so it would have been 
broken anyway.

Bug#1067493: [INTL:sv] Swedish strings for uif debconf

[Anders Jonsson]

Hi Martin,
this fixes one typo in the translation (inkommand -> inkommande)


Regards,
Anders# Translation of uif debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the XX package.
#
# Martin Bagge , 2008, 2024
msgid ""
msgstr ""
"Project-Id-Version: sv\n"
"Report-Msgid-Bugs-To: u...@packages.debian.org\n"
"POT-Creation-Date: 2022-05-06 19:27+0200\n"
"PO-Revision-Date: 2024-03-22 13:18+0100\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#: ../templates:1001
msgid "don't touch"
msgstr "rör inte"

#. Type: select
#. Choices
#: ../templates:1001
msgid "workstation"
msgstr "arbetsstation"

#. Type: select
#. Choices
#: ../templates:1001
msgid "debian-edu-router"
msgstr "debian-edu-router"

#. Type: select
#. Description
#: ../templates:1002
msgid "Firewall configuration method"
msgstr "Metod för konfigurering av brandväggen"

#. Type: select
#. Description
#: ../templates:1002
msgid ""
"Please choose whether the firewall should be configured now with a simple "
"\"workstation\" setup, given a specialized Debian Edu Router configuration, "
"or left unconfigured so that you can manually edit /etc/uif/uif.conf."
msgstr ""
"Ange om du vill att brandväggen ska ställas in som en enkel "
"\"arbetsstation\", som en specialutformad Debian Edu Router eller lämnas "
"helt orörd så att du själv kan redigera /etc/uif/uif.conf."

#. Type: string
#. Description
#: ../templates:2001
msgid "Trusted DNS hostnames:"
msgstr "Värdnamn i DNS att lita på:"

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"In workstation mode, you can specify some DNS hostnames to be globally "
"trusted. All incoming traffic coming from these will be allowed. Multiple "
"entries must be separated with spaces."
msgstr ""
"I läget för arbetsstation kan du ange några DNS-baserade värdnamn att lita "
"på. All inkommande trafik från dessa kommer att tillåtas. Separera "
"värdnamnen med mellanslag."

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"Hostnames provided here must be resolvable to both IPv4 and IPv6 addresses."
msgstr "Värdnamnen måste gå att nå både över IPv4 och IPv6."

#. Type: string
#. Description
#: ../templates:2001
msgid "Example: trusted-host-v4-and-v6.mydomain.com"
msgstr "Exempel: trusted-host-v4-och-v6.example.com"

#. Type: string
#. Description
#: ../templates:3001
msgid "Trusted IPv4 hosts and/or networks:"
msgstr "Ange IPv4-värdar eller nätverk att lita på:"

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"In workstation mode, you can specify some IPv4 hosts or networks to be "
"globally trusted. All incoming traffic coming from these will be allowed. "
"Multiple entries must be separated with spaces."
msgstr ""
"I läget för arbetsstation kan du ange några IPv4-värdar eller nätverk att "
"lita på. All inkommande trafik från dessa kommer att tillåtas. Separera "
"värdnamnen med mellanslag."

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"If you want to trust DNS hostnames that only resolve to an IPv4 address, "
"please enter them here."
msgstr ""
"Om du vill lita på värdnamn i DNS som enbart går att nå via en IPv4-adress "
"så ska dessa anges här."

#. Type: string
#. Description
#: ../templates:3001
msgid "Example: 10.1.0.0/16 trusted-host-v4-only.mydomain.com 192.168.1.55"
msgstr "Exempel: 198.51.100.0/24 trusted-host-v4-only.example.com 192.0.2.242"

#. Type: string
#. Description
#: ../templates:4001
msgid "Trusted IPv6 hosts and/or networks:"
msgstr "Ange IPv6-värdar eller nätverk att lita på:"

#. Type: string
#. Description
#: ../templates:4001
msgid ""
"In workstation mode, you can specify some IPv6 hosts or networks to be "
"globally trusted. All incoming traffic coming from these will be allowed. "
"Multiple entries must be separated with spaces."
msgstr ""
"I läget för arbetsstation kan du ange några IPv6-värdar eller nätverk att "
"lita på. All inkommande trafik från dessa kommer att tillåtas. Separera "
"värdnamnen med mellanslag."

#. Type: string
#. Description
#: ../templates:4001
msgid ""
"If you want to trust DNS hostnames that only resolve with an IPv6 address, "
"please enter them here."
msgstr ""
"Om du vill lita på värdnamn i DNS som enbart går att nå via en IPv6-adress "
"så ska dessa anges här."

#. Type: string
#. Description
#: ../templates:4001
msgid "Example: 2001:1234:ab::1 fe80::1"
msgstr "Exempel: 2001:db8:ab::1 fe80::1"

#. Type: boolean
#. Description
#: ../templates:5001
msgid "Allow ping?"
msgstr "Tillåt ping?"

#. Type: boolean
#. Description
#: ../templates:5001
msgid ""
"Normally an Internet host should be reachable with \"pings\" (ICMP Echo "
"requests). Rejecting this option will disable this, which might be somewhat "
"confusing when analyzing network problems."
msgstr ""
"Normalt är ett värdsystem på 

Bug#1067490: tracker.debian.org: Display release-team blocks more prominently

[Raphael Hertzog]

Hi,

top-posting and leaving quite some context because the main point of my
message is to actually share your bug report to the release team.
If I remember correctly, tracker.debian.org is not doing any fancy
treatment. We are just turning some YAML into HTML:
https://release.debian.org/britney/excuses.yaml

We copy the lines from "excuses" as-is so if you want to change the order
here, it needs to happen on the britney side.

Feel free to reassign this to release.debian.org or any other suitable
package if you want.

Have a nice day!

On Fri, 22 Mar 2024, Guillem Jover wrote:
> Currently when a package is blocked by a release-team block hint, that
> appears at the end of the "Issues preventing migration" list, which
> can easily be missed if there are also lots of autopkgtest issues,
> (see the current dpkg tracker page).
[...]
> The block seems like the most important information there, because
> even if everything else gets solved that still requires active action
> by the release-team. So I think it would be better to place it as the
> first item, also so that it does not get drown by autopkgtest entries
> that can be many. Also perhaps the autopkgtest entries should be
> nested? As in:
> 
> ,---
> ∙ ∙ Status for autopkgtest:
> ∙ ∙ ∙ ceilometer/blocked-on-ci-infra: i386: Ignored failure
> ∙ ∙ ∙ chrony/4.5-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ 
> (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, 
> ppc64el: Pass, s390x: Pass
> ∙ ∙ ∙ dash/0.5.12-6: amd64: Pass, arm64: Pass, armel: Regression or new test 
> ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, 
> ppc64el: Pass, s390x: Pass
> ∙ ∙ ∙ dpkg/1.22.6: amd64: Pass, arm64: Pass, armel: Pass, armhf: Pass, i386: 
> Pass, ppc64el: Pass, s390x: Pass
> ∙ ∙ ∙ gsocket/1.4.41-1: amd64: Pass, arm64: Pass, armel: Regression or new 
> test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: 
> Pass, ppc64el: Pass, s390x: Pass
> ∙ ∙ ∙ lintian/2.117.0: amd64: Regression or new test ♻ (reference ♻), arm64: 
> Regression or new test ♻ (reference ♻), armel: Regression or new test ♻ 
> (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: 
> Regression or new test ♻ (reference ♻), ppc64el: Regression or new test ♻ 
> (reference ♻), s390x: Regression or new test ♻ (reference ♻)
> `---
> 
> Which would remove repetition and make it visually easier to see?
> 
> (This has come up recently, I think multiple times, as I've got multiple
> private queries, and some public ones, where it looks like people missed
> the main reason for why dpkg is not migrating.)
> 
> (Also as an aside, perhaps autopkgtest entries that are all-pass,
> should appear in the “Additional info” part instead?)
> 
> Thanks,
> Guillem
> 

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1066856: apt: please update the URLs in the man pages

[Wesley Schwengle]

Hi,

> In the apt-cache(8) man page:
> 
> http://www.research.att.com/sw/tools/graphviz/ gives a "Page Not Found"
> error.
> 
> http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html should be
> changed to
> https://www.rw.cdl.uni-saarland.de/people/sander/private/html/gsvcg1.html

I fixed these URI's in git, see merge commit 
1c1d8b26f067e7a1f7740718c0ded84ec8a386cb and i

I didn't put closes: #number in one of the commit messages. Anyways, its fixed
and released in apt 2.7.14. Thanks for reporting the bug.

Cheers,
Wesley

Bug#1063653: anope: Please ship new upstream version

[Sadie Powell]

Please update this package to 2.0.15 (not 2.1.3, thats the dev branch) asap.

The currently shipped version contains a few security issues which should be 
addressed sooner rather than later.

~ Sadie

Bug#618332: rxvt-unicode: screen contents not restored when detaching a "screen" session

[Vincent Lefevre]

On 2024-03-22 15:09:17 +0100, Vincent Lefevre wrote:
> The bug no longer occurs in rxvt-unicode 9.31-3 from Debian/unstable,
> but it still occurs in rxvt-unicode 9.30-2 from Debian 12 (stable).

Actually it still occurs in rxvt-unicode 9.31-3 from Debian/unstable.
I might have done something wrong.

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

Bug#1067426: Package sponsorship request Qucs-S

[Tobias Frost]

Control: tags -1 moreinfo

Hi Vadim,

On Thu, Mar 21, 2024 at 04:56:43PM +0300, Vadim Kuznetsov wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> I am looking for a sponsor for my package "qucs-s":
> 
> * Package name : qucs-s
>    Version : 24.1.0-1
>    Upstream contact : Vadim Kuznetsov 
> * URL : https://github.com/ra3xdh/qucs_s
> * License : GPL-2.0
> * Vcs : https://github.com/ra3xdh/qucs_s.git
>    Section : electronics|

Some pointers to get started with packaging for Debian,
so that it can be included in Debian:
https://mentors.debian.net/intro-maintainers/

As you are upstream: 
https://wiki.debian.org/UpstreamGuide

I've had a brief view at the debian/ directory on your repository,
and there will be a bit work required to make your package suitable
for inclusion into Debian, for example you'll need a debian/copyright
file. I didn't look into further details, but I suggest to upload your
package to mentors.debian.net, as this has already some QA built in and
will help you to identify problems with your package, for example from
the linitian tool.

Then, when ready, remove the "moreinfo" tag from this bug report to get 
a proper review of the package.

You'll also need to file a ITP bug (use "reportbug wnpp" to get a
template). ITP stands for "Itent to Package" and declares that *you*
want to package and maintain your package. 

(RFP as mentioned by Peter stands for Request To Package, that means you
ask if someone else wants to package and maintain it, however, that
needs someone volunteering, so it might never happen.)apt

-- 
Cheers,
tobi

Bug#619648: cron.daily doesn't execute scheduled scripts

[Lin Qigang]

Control: tags 1053873 + moreinfo


I can reproduce this issue. While scripts in my personal crontab that are run
by cron are executed fine, the ones owned by anacron don't seem to be executed
although the syslog suggests otherwise.


If you could provide your anacrontab and logs, it would be helpful.


For example, a line starting with @daily does not work (i.e. run by anacron)
but when changing it to @hourly it does -- this time cron seems to take over.


Anacron only supports the @monthly period_name at this time [1], so I 
would not expect it behave well with @daily or @hourly. It would be a 
nice feature to add @daily and @weekly to Anacron though.


[1] https://manpages.debian.org/unstable/anacron/anacrontab.5.en.html

--
Lance Lin
GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7


OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067502: ITP: nsdiff -- generate nsupdate script from DNS zone differences

[Daniel Gröber]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Daniel Gröber 
X-Debbugs-Cc: d...@darkboxed.org
Severity: wishlist

* Package name: nsdiff
  Version : 1.85
  Upstream Contact: Tony Finch 
* URL : https://dotat.at/prog/nsdiff/
* License : 0BSD OR MIT-0
  Programming Lang: Perl
  Description : generate nsupdate script from DNS zone differences

The nsdiff program compares two versions of a DNS zone, and outputs
the differences between them as a script for use with the nsupdate.

This provides an elegant way to merge (hand written) static zone files
into otherwise dynamic zones.

nsdiff supports comparing on-disk zone-files and retreiving both sides
via standard AXFR zone transfer, optionally autenticated with a TSIG
key.

Always happy to have co-maintainers but I will maintain this package
myself.

--Daniel

Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’

[Sebastian Ramacher]

On 2024-03-22 10:35:06 -0400, Ben Westover wrote:
> Sebastian,
> 
> I can't seem to reproduce this on an armhf chroot, VM, or actual hardware
> (all unstable). When were you last able to reproduce this? It's possible
> (since unstable has changed rapidly in recent days) that the problem was
> something external that fixed itself between then and now.

I reproduced the issues a minute ago with current unstable. Please check
the versions in your build with the linked build log in the initial
mail.

Cheers
-- 
Sebastian Ramacher

Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’

[Ben Westover]

Sebastian,

I can't seem to reproduce this on an armhf chroot, VM, or actual 
hardware (all unstable). When were you last able to reproduce this? It's 
possible (since unstable has changed rapidly in recent days) that the 
problem was something external that fixed itself between then and now.


--
Ben Westover


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067497: openstreetmap-carto-common: "openstreetmap-carto-common.install" does not include directory "style"

[Sebastiaan Couwenberg]

Control: tags -1 pending

This is fixed in git.

Kind Regards,

Bas

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

Bug#1067501: libhipsolver-doc: missing Breaks+Replaces: libhipsolver-dev (<< 5.5.1-4~)

[Andreas Beckmann]

Package: libhipsolver-doc
Version: 5.5.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../libhipsolver-doc_5.5.1-4_all.deb ...
  Unpacking libhipsolver-doc (5.5.1-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libhipsolver-doc_5.5.1-4_all.deb (--unpack):
   trying to overwrite 
'/usr/share/doc/libhipsolver-dev/examples/example_basic.c', which is also in 
package libhipsolver-dev 5.5.1-3
  Errors were encountered while processing:
   /var/cache/apt/archives/libhipsolver-doc_5.5.1-4_all.deb

There are
  Breaks+Replaces: libhipsolver-dev (<< 5.5.1-3~)
which are insufficient to match the last version still shipping the files
in the -dev package.

cheers,

Andreas

Bug#1062486: kf5-messagelib: NMU diff for 64-bit time_t transition

[Benjamin Drung]

Source: kf5-messagelib
Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.

Thanks!


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

Kernel: Linux 6.5.0-26-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru kf5-messagelib-22.12.3/debian/changelog 
kf5-messagelib-22.12.3/debian/changelog
--- kf5-messagelib-22.12.3/debian/changelog 2023-06-27 12:09:30.0 
+
+++ kf5-messagelib-22.12.3/debian/changelog 2024-03-22 14:26:18.0 
+
@@ -1,3 +1,10 @@
+kf5-messagelib (4:22.12.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1062486
+
+ -- Benjamin Drung   Fri, 22 Mar 2024 14:26:18 +
+
 kf5-messagelib (4:22.12.3-2) unstable; urgency=medium
 
   * Add upstream patch to search also for subkeys (Closes: #1037363).
diff -Nru kf5-messagelib-22.12.3/debian/control 
kf5-messagelib-22.12.3/debian/control
--- kf5-messagelib-22.12.3/debian/control   2023-06-27 11:20:47.0 
+
+++ kf5-messagelib-22.12.3/debian/control   2024-03-22 14:26:18.0 
+
@@ -4,7 +4,7 @@
 Maintainer: Debian Qt/KDE Maintainers 
 Uploaders: Sandro Knauß ,
Patrick Franz ,
-Build-Depends: cmake (>= 3.16~),
+Build-Depends: dpkg-dev (>= 1.22.5), cmake (>= 3.16~),
debhelper-compat (= 13),
extra-cmake-modules (>= 5.99.0~),
git,
@@ -74,7 +74,7 @@
 Multi-Arch: same
 Depends: libkf5identitymanagement-dev (>= 22.12.3~),
  libkf5libkleo-dev (>= 4:22.12.3~),
- libkf5messagecomposer5abi1 (= ${binary:Version}),
+ libkf5messagecomposer5abi1t64 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends},
 Description: KDE PIM messaging library, composer devel files
@@ -83,7 +83,9 @@
  .
  This package is part of KDE PIM module.
 
-Package: libkf5messagecomposer5abi1
+Package: libkf5messagecomposer5abi1t64
+Replaces: libkf5messagecomposer5abi1
+Breaks: libkf5messagecomposer5abi1 (<< ${source:Version})
 X-Debian-ABI: 1
 X-CMake-Target: KF5MessageComposer
 Architecture: any
@@ -96,13 +98,13 @@
  message composing facilities.
  .
  This package is part of KDE PIM module.
-Provides: ${ABI:VirtualPackage},
+Provides: ${t64:Provides}, ${ABI:VirtualPackage},
 
 Package: libkf5messagecore-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: libkf5messagecore5abi1 (= ${binary:Version}),
+Depends: libkf5messagecore5abi1t64 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends},
 Description: KDE PIM messaging library, core devel files
@@ -111,7 +113,9 @@
  .
  This package is part of KDE PIM module.
 
-Package: libkf5messagecore5abi1
+Package: libkf5messagecore5abi1t64
+Replaces: libkf5messagecore5abi1
+Breaks: libkf5messagecore5abi1 (<< ${source:Version})
 X-Debian-ABI: 1
 X-CMake-Target: KF5MessageCore
 Architecture: any
@@ -124,14 +128,14 @@
  message handling facilities.
  .
  This package is part the KDE PIM module.
-Provides: ${ABI:VirtualPackage},
+Provides: ${t64:Provides}, ${ABI:VirtualPackage},
 
 Package: libkf5messagelist-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends: libkf5akonadi-dev (>= 4:22.12.3~),
- libkf5messagelist5abi1 (= ${binary:Version}),
+ libkf5messagelist5abi1t64 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends},
 Description: KDE PIM messaging library, message list devel files
@@ -141,7 +145,9 @@
  .
  This package is part of KDE PIM module.
 
-Package: libkf5messagelist5abi1
+Package: libkf5messagelist5abi1t64
+Replaces: libkf5messagelist5abi1
+Breaks: libkf5messagelist5abi1 (<< ${source:Version})
 X-Debian-ABI: 1
 X-CMake-Target: KF5MessageList
 Architecture: any
@@ -154,14 +160,14 @@
  e-mail message lists with extensive filtering, grouping and useful features.
  .
  This package is part of the KDE PIM module.
-Provides: ${ABI:VirtualPackage},
+Provides: ${t64:Provides}, ${ABI:VirtualPackage},
 
 Package: libkf5messageviewer-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends: libkf5messagecore-dev (= ${binary:Version}),
- libkf5messageviewer5abi1 (= ${binary:Version}),
+ libkf5messageviewer5abi1t64 (= ${binary:Version}),
  libkf5mimetreeparser-dev (= ${binary:Version}),
  libkf5pimcommon-dev (>= 4:22.12.3~),
  ${misc:Depends},
@@ -173,7 +179,9 @@
  .
  This package is part of KDE PIM module.
 
-Package: libkf5messageviewer5abi1

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Holger Wansing]

Hi,

Dmitry Shachnev  wrote (Fri, 22 Mar 2024 16:04:14 +0300):
> On Fri, Mar 22, 2024 at 01:46:48PM +0100, Holger Wansing wrote:
> > [...]
> > Anyway, the symlink points to some path inside the package build path, here:
> > /srv/debian-policy/debian-policy-4.6.2.1/debian/debian-policy/usr/share/sphinx_rtd_theme_static/css/theme.css
> > 
> > and that path does not exist.
> > Same in the debian-policy binary package.
> 
> This is expected. The path in the build tree is relative in a way that when
> a package is built and installed, it becomes working.

Ok, I see.
So, we will need to get sphinx-rtd-theme-common installed on all debian.org
website mirrors, and it will just work (?) ...

> The symlink is generated relative per Policy 10.5. And I think that even if
> dh_sphinxdoc generated it as absolute, dh_link would later change it to
> relative.
> 
> If you are trying to rely on something that is in the build directory, you
> have to turn relative symlinks into absolute ones on your own. Or just don't
> call dh_sphinxdoc, then you will get normal files.

... or we switch away from dh_sphinxdoc.
But there was already a hint, why this is a bad idea.
Will need to be evaluated...



Thanks for your time, guys!

Holger


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

Bug#1067500: libbiosoup-dev: ships /usr/include/meson.build

[Andreas Beckmann]

Package: libbiosoup-dev
Version: 0.11.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

your package ships /usr/include/meson.build which is an overly generic
name and causes file conflicts with other packages doing the same
mistake.


Andreas

Bug#1067499: libconsensuscore-dev: ships /usr/include/meson.build

[Andreas Beckmann]

Package: libconsensuscore-dev
Version: 1.1.1+dfsg-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

your package ships /usr/include/meson.build which is an overly generic
name and causes file conflicts with other packages doing the same
mistake.


Andreas

Bug#1067498: lintian: overly generic filename /usr/include/meson.build

[Andreas Beckmann]

Package: lintian
Severity: normal

Please complain about the overly generic filename

  /usr/include/meson.build

Candidates for testing:

libbiosoup-dev 0.11.0-1
libconsensuscore-dev 1.1.1+dfsg-4

Andreas

Bug#618332: rxvt-unicode: screen contents not restored when detaching a "screen" session

[Vincent Lefevre]

Control: found -1 4.8.0-6
Control: found -1 4.9.0-4
Control: found -1 4.9.1-1

On 2011-03-14 12:56:42 +0100, Vincent Lefevre wrote:
> The screen contents are not restored when detaching a "screen" session.
> To reproduce the problem:
> 
> 1. Run rxvt-unicode.
> 2. Run some commands, just to generate contents in the screen.
> 3. Run the "screen" utility.
> 4. Detach the "screen" session ([Cmd key] d), or simpler: terminate
>the shell (this will close the session and quit screen).
> 
> The bug: The contents one had before running "screen" are not restored.
> 
> I don't have this problem with xterm, aterm or gnome-terminal.

The bug no longer occurs in rxvt-unicode 9.31-3 from Debian/unstable,
but it still occurs in rxvt-unicode 9.30-2 from Debian 12 (stable).

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

Bug#1051647: please ship a fd(1) binary

[Markus Koller]

Severity: normal

Hello there,

Would love this too. Some tooling looks for an `fd` binary and
won't find an `fd` alias.

Another problem is that the shell completions for bash/zsh shipped
with the package don't work, since they define a `_fd` completion
function.

You can work around it with either `alias fd=fdfind` or
`alias _fdfind=_fd`, but it would be nice not to have to.

Raising the severity to normal because of this (first time doing
that, not sure if it will actually work :))

Thanks,
Markus

Bug#1067497: openstreetmap-carto-common: "openstreetmap-carto-common.install" does not include directory "style"

[Thomas]

Package: openstreetmap-carto-common
Version: 5.7.0-1
Severity: important
Tags: newcomer
X-Debbugs-Cc: fisc...@unix-ag.uni-kl.de

Hello,

The Git repository of openstreetmap-carto [1] contains a directory
called "style" with various files that are necessary to work with
openstreetmap-carto, e.g. if one wants to use this Debian project
package instead of pulling from Git if following the Switch2OSM
instructions for Debian 12 [2].

This directory is missing from openstreetmap-carto-common.install, where
other 'data' directories like "symbols" are included. This bug can be
easily fixed by adding "style" below "symbols" in a similar manner.

[1] https://github.com/gravitystorm/openstreetmap-carto/
[2] 
https://switch2osm.org/serving-tiles/manually-building-a-tile-server-debian-12/

Another minor issue that can be fixed as you touch the package: In
"rules" there is this "chmod -x" invocation referring to an upstream bug
report from 2021. This problem has been fixed upstream and the chmod is
no longer necessary. Simplifies code ...


-- 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-18-amd64 (SMP w/2 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 openstreetmap-carto-common depends on:
ii  curl   7.88.1-10+deb12u5
ii  debconf [debconf-2.0]  1.5.82
ii  fonts-dejavu-core  2.37-6
ii  fonts-noto-cjk 1:20220127+repack1-1
ii  fonts-noto-hinted  20201225-1
ii  fonts-noto-unhinted20201225-1
ii  fonts-unifont  1:15.0.01-2
ii  gdal-bin   3.6.2+dfsg-1+b2
ii  mapnik-utils   3.1.0+ds-3+b1
ii  python33.11.2-1+b1
ii  unzip  6.0-28

openstreetmap-carto-common recommends no packages.

openstreetmap-carto-common suggests no packages.

-- debconf information excluded

Bug#1029826: (no subject)

[Marco Moock]

Update on this:
The issue was the way I started the application.
I run sol & in xterm and then Hit Ctrl+D.
That makes STDOUT unavailable and that seems to cause that schema
exception.

-- 
kind regards
Marco

Send unsolicited bulk mail to 17109193364mu...@cartoonies.org

Bug#1067496: Vertical splits no longer delineated by default

[Josh Triplett]

Package: neovim
Version: 0.9.5-6
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

After upgrading to the new version of neovim, the highlight
`WinSeparator` (which links to `VertSplit`) no longer has any visible
setting by default. In previous versions, there was an inverse-video bar
between windows; now there's only a black bar the same color as normal
text background, which makes the windows blend together.

I've worked around this by setting `highlight VertSplit cterm=inverse
gui=inverse`, but I think the default should have at least *some*
delineation between split windows.

Thank you.

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

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

Versions of packages neovim depends on:
ii  libc6 2.37-15
ii  libluajit2-5.1-2  2.1-20230410-1
ii  libmsgpackc2  4.0.0-3+b1
ii  libtermkey1   0.22-1
ii  libtree-sitter0   0.20.8-2+b1
ii  libunibilium4 2.1.0-3+b1
ii  libuv1t64 1.48.0-1.1
ii  libvterm0 0.3.3-3
ii  lua-luv   1.48.0-2-2
ii  neovim-runtime0.9.5-6

Versions of packages neovim recommends:
pn  python3-pynvim  
ii  wl-clipboard2.2.1-1
pn  xxd 

Versions of packages neovim suggests:
pn  ctags
ii  vim-scripts  20210124.2

-- no debconf information

Bug#1067495: ITS: persepolis

[Boyuan Yang]

Source: persepolis
Version: 3.0.1-1.1
Severity: important
X-Debbugs-CC: deb...@nixoeen.com

Dear package persepolis maintainer in Debian,

After looking into the package you maintain (persepolis, 
https://tracker.debian.org/pkg/persepolis), I found that this package
received no maintainer updates in the past 6 years and was not in good
shape. The follow-up bug report at https://bugs.debian.org/924204 received
no further response in the last 4 years. As a result, I am filing an ITS
(Intent to Salvage) request against your package according to section 5.12
in Debian's Developers' Reference [1].

My current plan is to refresh packaging and package the latest upstream
version.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Apr 12, 2024) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Dmitry Shachnev]

On Fri, Mar 22, 2024 at 01:46:48PM +0100, Holger Wansing wrote:
> [...]
> Anyway, the symlink points to some path inside the package build path, here:
> /srv/debian-policy/debian-policy-4.6.2.1/debian/debian-policy/usr/share/sphinx_rtd_theme_static/css/theme.css
> 
> and that path does not exist.
> Same in the debian-policy binary package.

This is expected. The path in the build tree is relative in a way that when
a package is built and installed, it becomes working.

The symlink is generated relative per Policy 10.5. And I think that even if
dh_sphinxdoc generated it as absolute, dh_link would later change it to
relative.

If you are trying to rely on something that is in the build directory, you
have to turn relative symlinks into absolute ones on your own. Or just don't
call dh_sphinxdoc, then you will get normal files.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#619648: cron.daily doesn't execute scheduled scripts

[Bastian Venthur]

Package: anacron
Version: 2.3-39+b1
Followup-For: Bug #619648
X-Debbugs-Cc: vent...@debian.org

Dear Maintainer,

I can reproduce this issue. While scripts in my personal crontab that are run
by cron are executed fine, the ones owned by anacron don't seem to be executed
although the syslog suggests otherwise.

For example, a line starting with @daily does not work (i.e. run by anacron)
but when changing it to @hourly it does -- this time cron seems to take over.


Cheers,

Bastian


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

Kernel: Linux 6.7.9-amd64 (SMP w/16 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 anacron depends on:
ii  libc6  2.37-15.1

Versions of packages anacron recommends:
ii  cron [cron-daemon]  3.0pl1-188

Versions of packages anacron suggests:
ii  exim4-daemon-light [mail-transport-agent]  4.97-6+b1
ii  powermgmt-base 1.37
ii  rsyslog [system-log-daemon]8.2402.0-1+b1

-- no debconf information

Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Andrey Rakhmatullin]

On Fri, Mar 22, 2024 at 01:46:48PM +0100, Holger Wansing wrote:
> Anyway, the symlink points to some path inside the package build path, here:
> /srv/debian-policy/debian-policy-4.6.2.1/debian/debian-policy/usr/share/sphinx_rtd_theme_static/css/theme.css
You are looking at relative symlinks not in their final locations, which
isn't useful and also is expected for every relative symlink that is
packaged.

-- 
WBR, wRAR


signature.asc
Description: PGP signature