Bug#1040433: ITA: anki

2024-03-04 Thread Laurin Hagemann
Control: retitle -1 ITA: anki - flashcard learning program, has migrated to 
Rust/Python/JavaScript combination
Control: owner -1 !

Hey,

I'm adopting the package. @Mae, @Christian: feel free to contact me if you want 
to work on anki packaging as well.

Kind regards, 
Laurin



Bug#1065134: dwarves: Please package new upstream release and confirm contact info

2024-03-04 Thread Thomas Girard

Hello,

On 02/03/2024 09:28, Domenico Andreoli wrote:

Besides, upstream is introducing a PKG-MAINTAINERS file to
indicate the package maintainers in different distros. According to
https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=554c5e6a2736e0b6108077c7697637f6542dd2ed
 ,
Domenico Andreoli is added as the person of contact. Please review
the info and confirm with upstream if needed.


I will.


Could you please remove me from Uploaders? I don't have time for Debian 
at the moment.


Thanks,
Regards,

Thomas



Bug#1065394: debootstrap Sid failed to run due to libuuid1t64 and libuuid1 coexist

2024-03-04 Thread MichaIng

Hi Steven,

indeed that might be part of the issue, since libuuid1 "Provides: 
libuuid1t64 (= 2.39.3-9)", hence an exact version of libuuid1t64 which 
is not in repos. debootstrap otherwise might be able to solve the 
libuuid1t64 dependency by installing libuuid1 only.


Interesting is that libuuid1 and libuuid1t64 have "Replaces:" on each 
other already. So debootstrap seems not to be able to deal with this 
native dpkg file replacement feature?


However, while indeed libuuid1t64 requires an upload and debootstrap 
might not perfectly resolve all dependencies/replaces stuff, the main 
issue is the conflicting double-dependency of e2fsprogs on both libuuid 
package variants.


This has been introduced by a non-maintainer patch for the transition to 
(64-bit) time_t libraries, these *t64 packages are all about. Since this 
was a week ago, and I do not see any maintainer reaction in the 
meantime, there is a high chance that this conflict has not been 
recognised at all. Hence I re-assigned this bug report where it belongs to.


Best regards,

Micha



Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-03-04 Thread Bastian Blank
Control: tags -1 moreinfo

On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely
> However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.

So you claim that /usr/DEB_HOST_GNU_TYPE/include is critical part of the
API for this package name?  If you think so, please provide evidence.

This path is in violation of the Debian policy, so can't be provided by
linux-libc-dev.

Bastian

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!



Bug#1065437: debos: Build on arm64

2024-03-04 Thread Colin Watson
Source: debos
Version: 1.1.3-1
Severity: wishlist
Tags: patch

Since fakemachine now builds on arm64 as well as amd64, it should be
possible to build debos on arm64 too.  I've only build-tested this
patch, but I think it should work given that debos is tested upstream on
arm64.

Note that qemu-system-x86 provides qemu-system-amd64, so the substvar
here shouldn't change behaviour on amd64; this was simpler than
computing a custom substvar in debian/rules.

diff --git a/debian/control b/debian/control
index ed69af8..12d3ef8 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ XS-Go-Import-Path: github.com/go-debos/debos
 Testsuite: autopkgtest-pkg-go
 
 Package: debos
-Architecture: amd64
+Architecture: amd64 arm64
 Built-Using:
  ${misc:Built-Using},
 Recommends:
@@ -38,7 +38,7 @@ Recommends:
  dosfstools,
  e2fsprogs,
  fdisk,
- linux-image-amd64,
+ linux-image-${Arch},
  mount,
  ovmf,
  parted,
@@ -49,7 +49,7 @@ Recommends:
 Depends:
  busybox | busybox-static,
  debootstrap,
- qemu-system-x86,
+ qemu-system-${Arch},
  qemu-user-static,
  systemd-container,
  ${misc:Depends},

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]



Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-04 Thread Simon McVittie
Copying context from elsewhere in the thread, Sam Hartman wrote:
> Are there solutions in the space of having glib2.0-0 continue to exist
> as a package depended on by glib2.0-0t64 or depending on the new library
> allowing you to replace the postrm?

to which I replied:

If libglib2.0-0 continues to exist, then packages that expect the affected
entry points to have 32-bit time_t will still have their dependencies
satisfied, but then when they call the affected entry points, they will
crash, because their time_t is not the same size as GLib's. So as far
as I can see, this is functionally equivalent to reverting the rename:
to be correct, it would have to be accompanied by versioned Breaks on
every package that calls into the affected entry points.

On Mon, 04 Mar 2024 at 08:46:52 -0700, Sam Hartman wrote:
> > "Matthew" == Matthew Garrett  writes:
> Matthew> I would like some further
> Matthew> analysis of Sam's proposal, though - I don't think there's
> Matthew> any advantage in undoing the existing solution, but if it
> Matthew> would work then it's maybe a more straightforward solution
> Matthew> for any similar issues in future?
> 
> Unfortunately, I think Simon's response to me is definitive.
> Ultimately if the old package exists, it will continue to satisfy
> dependencies.
> That's exactly what we don't want in the time_t transition.

I think the one thing we could do in this direction would be to mitigate
problems like this one *on architectures unaffected by the transition*
(in this case, 64-bit plus i386) by having this situation:

Package: libglib2.0-0
Architecture: amd64 arm64 i386 s390x (etc.)
Depends: libglib2.0-0t64 (>= ${binary:Version})
Description: empty transitional package

Package: libglib2.0-0t64
Architecture: any
Breaks: libglib2.0-0 (<< ${binary:Version})
Replaces: libglib2.0-0 (<< ${binary:Version})
Description: GLib library

I think this would have made upgrades significantly more smooth on the
non-armel, non-armhf architectures, as well - but perhaps I'm missing an
important reason why the 64-bit time_t transition team have chosen not to
do this (and perhaps it's not even possible).

Nothing we do in this direction would help armel and armhf, so there would
still be a problem here to be solved (and probably we would not have found
out about this particular bug until much, much later, when an armel or
armhf GUI user did the upgrade and encountered the bug).

This is obviously only going to help if "most" architectures are
unaffected by the transition. If our next such transition involves
genuinely breaking ABI on the more widely-used architectures, then I
don't see any way to make it less painful. Perhaps this is a sign that
we should try hard to only have transitions shaped like this one if
there is no alternative.

smcv



Bug#916475: ghdl: various suggestions to simplify the packaging

2024-03-04 Thread Nicolas Boulenguez
Source: ghdl
Followup-For: Bug #916475

Hello.
0001 is unchanged.
0002 is stripped from unwanted spaces<->tabulations changes.
>From 93ac475b1389fb875094c14a4977f64d8c1f74fd Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 1 Oct 2023 01:14:25 +0200
Subject: [PATCH 1/2] Delegate computation of Built-Using to dh-builtusing

---
 debian/control | 7 ---
 debian/rules   | 9 -
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/debian/control b/debian/control
index 585ee55e..545c44b4 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Debian Electronics Team 
 Build-Depends: debhelper-compat (= 13),
dh-ada-library (>= 8.1),
+   dh-sequence-builtusing,
gnat-12, gcc-12, g++-12,
gcc-12-source ,
libisl-dev (>= 0.14) ,
@@ -80,7 +81,7 @@ Description: VHDL compiler/simulator (mcode backend)
 Package: ghdl-gcc
 Architecture: any
 Build-Profiles: 
-Built-Using: ${Built-Using-GCC}
+Built-Using: ${dh-builtusing:gcc-S-source}
 Depends: ghdl-common (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends},
 	gcc, zlib1g-dev
 Description: VHDL compiler/simulator (GCC backend)
@@ -122,7 +123,7 @@ Description: VHDL compiler/simulator (tools)
 
 Package: libghdl-3-0-0
 Architecture: any
-Built-Using: ${Built-Using-GCC}
+Built-Using: ${dh-builtusing:gcc-S-source} 
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Multi-Arch: same
 Description: VHDL compiler/simulator (shared library)
@@ -135,7 +136,7 @@ Description: VHDL compiler/simulator (shared library)
 
 Package: libghdl-dev
 Architecture: any
-Built-Using: ${Built-Using-GCC}
+Built-Using: ${dh-builtusing:gcc-S-source} 
 Depends: libghdl-3-0-0 (= ${binary:Version}), ${misc:Depends}
 Multi-Arch: same
 Description: VHDL compiler/simulator (library development files)
diff --git a/debian/rules b/debian/rules
index 5821f85d..138b8581 100755
--- a/debian/rules
+++ b/debian/rules
@@ -95,15 +95,6 @@ override_dh_strip:
 	dh_strip -N libghdl-3-0-0
 	dh_strip -p libghdl-3-0-0 --dbgsym-migration='libghdl-2-0-0'
 
-override_dh_gencontrol:
-ifneq ($(filter gcc,$(BACKENDS)),)
-	dh_gencontrol -- -VBuilt-Using-GCC="$(shell dpkg-query -f '$${Source} (= $${Version})' -W gcc-$(DEB_GNAT_VERSION)-source)"
-else
-	dh_gencontrol
-endif
-
-
-
 configure-llvm-stamp configure-mcode-stamp: configure-%-stamp:
 	$(announce)
 	mkdir -p $(BUILDDIR)/$*
-- 
2.39.2

>From 9fd880fea151ef73266938f65f423003f9d8f36b Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 5 Oct 2023 14:39:35 +0200
Subject: [PATCH 2/2] test driver: move error reporting to a separate procedure

---
 debian/tests/ghdl-tests | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/debian/tests/ghdl-tests b/debian/tests/ghdl-tests
index 871d594b..9ef0a66d 100755
--- a/debian/tests/ghdl-tests
+++ b/debian/tests/ghdl-tests
@@ -6,15 +6,19 @@ set -C -e -f -u
 # Debian yet.
 TESTS="sanity gna vests synth vpi vhpi"
 
-test $# = 2
+error() {
+echo >&2 "$0: $1"
+exit 1
+}
+
+test $# = 2 || error "bad argument count: $#"
 
 case "$2" in
 gcc|llvm|mcode)
 	BACKEND=$2
 	;;
 *)
-	echo >&2 "Invalid backend specification"
-	exit 1
+	error "invalid backend specification: $2"
 esac
 
 case "$1" in
@@ -27,8 +31,7 @@ case "$1" in
 	GHDL=/usr/bin/ghdl-$BACKEND
 	;;
 *)
-	echo >&2 "Invalid test environment specification"
-	exit 1
+	error "invalid test environment specification: $1"
 esac
 
 # Copy testsuite into $RUNDIR to execute there, so that no cleanup is necessary
@@ -50,6 +53,5 @@ if ./testsuite.sh $TESTS -- --keep-going; then
 elif test $BACKEND = llvm; then
 echo "Tests for backend llvm failed (but ignored for now)."
 else
-echo >&2 "Tests for backend $BACKEND failed."
-exit 1
+error "tests for backend $BACKEND failed."
 fi
-- 
2.39.2



Bug#1065323: petsc: bad Provides in libpetsc64-real3.19t64, libpetsc64-complex3.19t64 and libpetsc-real3.19t64

2024-03-04 Thread Drew Parsons
Source: petsc
Followup-For: Bug #1065323

petsc has a complex set of symlink farms since it needs to enable
multiple alternative build profiles.

I'll implement the patch in a way that doesn't let t64 get in the way
of updating subsequently (to 3.20 in the near future).

Drew



Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-04 Thread Sam Hartman
> "Matthew" == Matthew Garrett  writes:

Matthew> I agree with the conclusions drawn here, but feel that it's
Matthew> possibly worth making a stronger general statement that
Matthew> policy should never prevent the implementation of a
Matthew> well-considered simple solution. I would like some further
Matthew> analysis of Sam's proposal, though - I don't think there's
Matthew> any advantage in undoing the existing solution, but if it
Matthew> would work then it's maybe a more straightforward solution
Matthew> for any similar issues in future?

Unfortunately, I think Simon's response to me is definitive.
Ultimately if the old package exists, it will continue to satisfy
dependencies.
That's exactly what we don't want in the time_t transition.

I think we might revisit this when we come to a discussion of how our
tools could provide us more flexibility to make issues like usrmerge and
time_t transition easier in the future.



Bug#1065436: cyrus-sasl2 accesses resources from the network during the build

2024-03-04 Thread Matthias Klose

Package: src:cyrus-sasl2
Version: 2.1.28+dfsg1-4
Severity: serious
Tags: sid trixie

cyrus-sasl2 accesses resources from the network during the build, as 
seen on the Ubuntu buildds:


https://launchpadlibrarian.net/717319176/buildlog_ubuntu-noble-amd64.cyrus-sasl2_2.1.28+dfsg1-4ubuntu1_BUILDING.txt.gz

make[4]: Entering directory '/<>/build-heimdal'
test x".." = x"." || \
(cd .. && tar cf - --mode=gu+w docsrc) | tar xf -
/usr/bin/sphinx-build -d docsrc/.doctrees -n -q -D today=2024-03-03 -b 
cyrman ./docsrc ./man

WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://www.cyrusimap.org/objects.inv' not 
fetchable due to : 
HTTPSConnectionPool(host='www.cyrusimap.org', port=443): Max retries 
exceeded with url: /objects.inv (Caused by 
NameResolutionError("0x7feab01de450>: Failed to resolve 'www.cyrusimap.org' ([Errno -2] Name 
or service not known)"))



the Debian build log doesn't show this error message, so this sphinx 
inventory is fetched from the website during the build.




Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

2024-03-04 Thread Nicolas Boulenguez
Package: dpkg-dev
Followup-For: Bug #872381

This new version, based on c881a5a8,
* splits protection from double inclusion and dpkg_datadir generation
  into separate commits
* fixes an error in DEB_BUILD_OPTION_PARALLEL
* removes a few dubious optimizations (like checking if dpkg_datadir
  is already computed in default.mk).
* removes non-ASCII characters from comments
>From e29be20064687eee52fa9b6c1ee1cb722867d590 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Mon, 29 Jul 2019 14:38:32 +0200
Subject: [PATCH 01/10] scripts/mk: protect scripts from double inclusion

Two such double inclusions already happen when default.mk is parsed.
---
 scripts/mk/architecture.mk | 5 +
 scripts/mk/buildapi.mk | 5 +
 scripts/mk/buildflags.mk   | 6 ++
 scripts/mk/buildopts.mk| 5 +
 scripts/mk/buildtools.mk   | 5 +
 scripts/mk/default.mk  | 5 +
 scripts/mk/pkg-info.mk | 5 +
 scripts/mk/vendor.mk   | 5 +
 8 files changed, 41 insertions(+)

diff --git a/scripts/mk/architecture.mk b/scripts/mk/architecture.mk
index c11cada16..2ffcee287 100644
--- a/scripts/mk/architecture.mk
+++ b/scripts/mk/architecture.mk
@@ -2,6 +2,9 @@
 # DEB_BUILD_* variables that dpkg-architecture can return. Existing values
 # of those variables are preserved as per policy.
 
+ifndef dpkg_architecture.mk_included
+dpkg_architecture.mk_included :=
+
 dpkg_lazy_eval ?= $$(or $$(value DPKG_CACHE_$(1)),$$(eval DPKG_CACHE_$(1) := $$(shell $(2)))$$(value DPKG_CACHE_$(1)))
 
 dpkg_architecture_setvar = export $(1) ?= $(call dpkg_lazy_eval,$(1),dpkg-architecture -q$(1))
@@ -9,3 +12,5 @@ dpkg_architecture_setvar = export $(1) ?= $(call dpkg_lazy_eval,$(1),dpkg-archit
 $(foreach machine,BUILD HOST TARGET,\
   $(foreach var,ARCH ARCH_ABI ARCH_LIBC ARCH_OS ARCH_CPU ARCH_BITS ARCH_ENDIAN GNU_CPU GNU_SYSTEM GNU_TYPE MULTIARCH,\
 $(eval $(call dpkg_architecture_setvar,DEB_$(machine)_$(var)
+
+endif
diff --git a/scripts/mk/buildapi.mk b/scripts/mk/buildapi.mk
index 668e325c8..ba6b43543 100644
--- a/scripts/mk/buildapi.mk
+++ b/scripts/mk/buildapi.mk
@@ -1,5 +1,8 @@
 # This Makefile fragment (since dpkg 1.22.0) handles the build API.
 
+ifndef dpkg_buildapi.mk_included
+dpkg_buildapi.mk_included :=
+
 # Default API level when not set.
 DPKG_BUILD_API ?= $(shell dpkg-buildapi)
 
@@ -7,3 +10,5 @@ DPKG_BUILD_API ?= $(shell dpkg-buildapi)
 # complexity given no integer operators, given that we currently have to
 # fetch the build API level anyway.
 dpkg_build_api_ge = $(shell test "$(DPKG_BUILD_API)" -ge "$(1)" && echo yes)
+
+endif
diff --git a/scripts/mk/buildflags.mk b/scripts/mk/buildflags.mk
index 4b8a3d8c4..02baa53f2 100644
--- a/scripts/mk/buildflags.mk
+++ b/scripts/mk/buildflags.mk
@@ -28,6 +28,10 @@
 # You can also export them in the environment by setting
 # DPKG_EXPORT_BUILDFLAGS to a non-empty value.
 #
+
+ifndef dpkg_buildflags.mk_included
+dpkg_buildflags.mk_included :=
+
 # This list is kept in sync with the default set of flags returned
 # by dpkg-buildflags.
 
@@ -77,3 +81,5 @@ $(foreach flag,$(DPKG_BUILDFLAGS_LIST),\
 ifdef DPKG_EXPORT_BUILDFLAGS
   export $(DPKG_BUILDFLAGS_LIST)
 endif
+
+endif
diff --git a/scripts/mk/buildopts.mk b/scripts/mk/buildopts.mk
index c9519..6787da76f 100644
--- a/scripts/mk/buildopts.mk
+++ b/scripts/mk/buildopts.mk
@@ -5,6 +5,11 @@
 #
 #   DEB_BUILD_OPTION_PARALLEL: the argument for the parallel=N option.
 
+ifndef dpkg_buildopts.mk_included
+dpkg_buildopts.mk_included :=
+
 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
   DEB_BUILD_OPTION_PARALLEL = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
 endif
+
+endif
diff --git a/scripts/mk/buildtools.mk b/scripts/mk/buildtools.mk
index 933fdcfaa..08914c463 100644
--- a/scripts/mk/buildtools.mk
+++ b/scripts/mk/buildtools.mk
@@ -25,6 +25,9 @@
 # The variables are not exported by default. This can be changed by
 # defining DPKG_EXPORT_BUILDTOOLS.
 
+ifndef dpkg_buildtools.mk_included
+dpkg_buildtools.mk_included :=
+
 dpkg_datadir = $(srcdir)/mk
 include $(dpkg_datadir)/architecture.mk
 
@@ -74,3 +77,5 @@ $(eval $(call dpkg_buildtool_setvar,AR,ar))
 $(eval $(call dpkg_buildtool_setvar,RANLIB,ranlib))
 $(eval $(call dpkg_buildtool_setvar,PKG_CONFIG,pkgconf))
 $(eval $(call dpkg_buildtool_setvar,QMAKE,qmake))
+
+endif
diff --git a/scripts/mk/default.mk b/scripts/mk/default.mk
index 0b2fd4aca..b791f98a5 100644
--- a/scripts/mk/default.mk
+++ b/scripts/mk/default.mk
@@ -1,6 +1,9 @@
 # This Makefile fragment (since dpkg 1.16.1) includes all the Makefile
 # fragments that define variables that can be useful within debian/rules.
 
+ifndef dpkg_default.mk_included
+dpkg_default.mk_included :=
+
 dpkg_datadir = $(srcdir)/mk
 include $(dpkg_datadir)/architecture.mk
 include $(dpkg_datadir)/buildapi.mk
@@ -11,3 +14,5 @@ include $(dpkg_datadir)/buildflags.mk
 include $(dpkg_datadir)/buildopts.mk
 include $(dpkg_datadir)/pkg-info.mk
 include $(dpkg_datadir)/vendor.mk
+
+endif
diff --git 

Bug#1064840: dh-ada-library: Tests will fail after glibc DEP17 migration

2024-03-04 Thread Nicolas Boulenguez
Source: dh-ada-library
Followup-For: Bug #1064840
Control: tags -1 + pending

Hello.
A fix is committed [1] and will be part of the pending t64/gnat-13
transition.
[1] 
https://salsa.debian.org/debian/dh_ada_library/-/commit/d40951e34b40f8e9c63e961546a8a4093746857d
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065309



Bug#1063721: spip: has stopped working, complains about PHP version being ‘too recent’

2024-03-04 Thread David Prévot
control: severity -1 serious
control: found -1 4.1.15+dfsg-1

Hi,

Le Sun, Feb 11, 2024 at 07:30:39PM +0100, Axel a écrit :
> Package: spip
> Version: 4.1.9+dfsg-1+deb12u4
> Severity: important
[…]
> after the upgrade, I could not log in to my site anymore. […] …/ecrire shows:
> 
> “This installation will probably fail, or damage your site. PHP version 8.2.7 
> too recent (maximum = 8.1.99)”

Ouch, thanks for the feedback, I was able reproduce the issue on a new
install (it also breaks on new installation…), I assume changing
_PHP_MAX to 8.2.99 in /usr/share/spip/ecrire/inc_version.php should
allow one to workaround this issue.

Regards,

taffit


signature.asc
Description: PGP signature


Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)

2024-03-04 Thread Axel Beckert
Source: aptitude
Version: 0.8.13-5
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: a...@debian.org, z...@debian.org

Citing from https://buildd.debian.org/status/package.php?p=aptitude:

BinNMU changelog for aptitude on amd64, arm64, armel, armhf, i386, mips64el, 
ppc64el, riscv64, s390x, alpha, hppa, hurd-i386, ia64, loong64, m68k, powerpc, 
ppc64, sh4, sparc64 and x32:

Rebuild for time_t

Tail of log for aptitude on armel:

/usr/include/cppunit/TestAssert.h:161:6: note: candidate: ‘template 
void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&)’
  161 | void assertEquals( const T& expected,
  |  ^~~~
/usr/include/cppunit/TestAssert.h:161:6: note:   template argument 
deduction/substitution failed:
../../tests/test_misc.cc:187:5: note:   deduced conflicting types for parameter 
‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
  187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
  | ^
make[3]: *** [Makefile:869: test_misc.o] Error 1
make[3]: Leaving directory '/<>/build/tests'
make[2]: *** [Makefile:1169: check-am] Error 2
make[2]: Leaving directory '/<>/build/tests'
/bin/sh: 1: ./cppunit_test: not found
make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary-arch] Error 2

Tail of log for aptitude on armhf:

/usr/include/cppunit/TestAssert.h:161:6: note: candidate: ‘template 
void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&)’
  161 | void assertEquals( const T& expected,
  |  ^~~~
/usr/include/cppunit/TestAssert.h:161:6: note:   template argument 
deduction/substitution failed:
../../tests/test_misc.cc:187:5: note:   deduced conflicting types for parameter 
‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
  187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
  | ^
make[3]: *** [Makefile:869: test_misc.o] Error 1
make[3]: Leaving directory '/<>/build/tests'
make[2]: *** [Makefile:1169: check-am] Error 2
make[2]: Leaving directory '/<>/build/tests'
/bin/sh: 1: ./cppunit_test: not found
make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary-arch] Error 2

Given the time and the architectures failing, this is probably related
to dpkg switching on -Werror=implicit-function-declaration on these
architectures (see https://bugs.debian.org/1065371 and a good summary
of a similar case in https://bugs.debian.org/1065431 against lintian).

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 13.2.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.4
  libsigc++ version: 2.12.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20240113
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffc0a3eb000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f8fca645000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f8fc9e0)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f8fca1c6000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f8fca191000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f8fca188000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f8fca084000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f8fc9c8a000)
libboost_iostreams.so.1.83.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7f8fca06a000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f8fc9a0)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f8fc960)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8fc9921000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f8fca03b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8fc941e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8fc9c85000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f8fc9c8)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8fc9c61000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f8fc990e000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8fc98d1000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f8fc98ab000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f8fc935d000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f8fc9878000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f8fc927b000)
libgcrypt.so.20 => 

Bug#1065434: spice-vdagent: Automatic window resize not working XFCE and MATE desktops (Cinnamon works correctly)

2024-03-04 Thread Richard Maher
Package: spice-vdagent
Version: 0.22.1-4+b1
Severity: important
X-Debbugs-Cc: po42st+deb12...@gmail.com

Dear Maintainer,

* What led up to the situation?
Installed Debian Bookworm 12.5 XFCE VM within Debian 12.4 + Proxmox 8.1.4 XFCE
workstation. On the VM installed spice-vdagent. Noticed that the Debian VM's
desktop would not automatically resize to the client screen size on boot or to
the client window size if running in a window after rebooting VM. Checked
settings of client machines Virtual Machine Viewer 11. Auto resize is set.
Checked spice-vdagent was running on the VM with "sudo systemctl status spice-
vdagent", it was. Checked that the copy and paste between the client OS and VM
was functional. It was.

* What exactly did you do (or not do) that was effective (or ineffective)?
Opened the VM XFCE display settings from the graphical XFCE desktop. Noticed
that a VM window resize or switch to full screen was being picked up by the VM
display settings manager but was not being selected and activated
automatically. The pictoral "Virtual-1" window representation would change
shape however the display settings "Resolution" drop down box would become
blank. On selecting the "Resolution" drop down box, the display window setting
required is shown at the very top of the list with an asterix (*) against it.
Selecting this option and then apply correctly resizes the desktop resolution
to match the VM window size. However this behavior should be automatic and not
require user intervention.

The issue was googled. Indication that the issue was affecting MATE but not
Cinnamon desktops was found. MATE and Cinnamon desktops were also installed
into a cloned instance of the VM to test. This was confirmed. Cinnamon works
correctly and auto resizes. MATE does not and also was found to not take on the
settings into the Display manager unlike XFCE.

The affected test VM was updated to Trixie and the same tests carried out
again. The same behaviour was found as with Bookworm 12.5.

The logs available for spice-vdagent were searched for within the Gnome Logs
application. Errors were found with each resizing the VM display window:

14:06:31 spice-vdagent:error message: Cannot invoke method; proxy is for
the well-known name without an owner, and proxy was constructed with the
G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
14:06:31 spice-vdagent:error message: Cannot invoke method; proxy is for
the well-known name without an owner, and proxy was constructed with the
G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
14:06:31 spice-vdagent: display: failed to call GetCurrentState from mutter
over DBUS
14:06:31 spice-vdagent:error message: Cannot invoke method; proxy is for
the well-known name without an owner, and proxy was constructed with the
G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
14:06:31 spice-vdagent: display: failed to call GetCurrentState from mutter
over DBUS

* What was the outcome of this action?
Automatic window resize not working XFCE and MATE desktops (Cinnamon works
correctly)

* What outcome did you expect instead?

Automatic window resizing.


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

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

Versions of packages spice-vdagent depends on:
ii  init-system-helpers  1.66
ii  libasound2   1.2.10-3
ii  libc62.37-15
ii  libdbus-1-3  1.14.10-4
ii  libdrm2  2.4.120-2
ii  libglib2.0-0 2.78.4-1
ii  libgtk-3-0   3.24.41-1
ii  libpciaccess00.17-3
ii  libsystemd0  255.3-2
ii  libx11-6 2:1.8.7-1
ii  libxinerama1 2:1.1.4-3
ii  libxrandr2   2:1.5.2-2+b1

spice-vdagent recommends no packages.

spice-vdagent suggests no packages.

-- no debconf information



Bug#1064617: Passwords should not be changed frequently

2024-03-04 Thread Diederik de Haas
On Monday, 4 March 2024 10:43:59 CET Holger Wansing wrote:
> >Regarding the password advice, I ended up concluding that it's pretty
> >unlikely that anything we say at this point will have any effect on
> >people's behaviour, but then I'm probably just an old cynic. Also, I
> >failed when trying to come up with a wording which I was happy with,
> >which is why I ended up discarding the advice entirely.
> >
> >If we want to keep the password advice in then I think what you wrote is
> >(mostly) OK, although I think it implies that one should be choosing a
> >single "password" (although, not a word in any normal sense), which
> >could be argued to steer people away from the perfectly decent xkcd
> >approach of using several dictionary words. Saying "Password or
> >Passphrase" at least once would probably address that.
> 
> Ok, makes it a bit longer, but it could be worth it.

https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to 
remember URL and we'd have all the space we need to give proper advise?

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


Bug#1065216: r-base: recent libc6-dev change causes the xdr feature to be dropped

2024-03-04 Thread Dirk Eddelbuettel


On 1 March 2024 at 23:36, Aurelien Jarno wrote:
| Source: r-base
| Version: 4.3.3-1
| Severity: serious
| Tags: ftbfs
| Justification: fails to build from source (but built successfully in the past)
| User: debian-gl...@lists.debian.org
| Usertags: libtirpc-dev
| 
| Dear maintainer,
| 
| Starting with glibc 2.31, support for NIS (libnsl library) has been
| moved to a separate libnsl2 package. In order to allow a smooth
| transition, a libnsl-dev, which depends on libtirpc-dev, has been added
| to the libc6-dev package.
| 
| The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1
| NMU, as part of the 64-bit time_t transition. This causes the xdr
| feature of r-base to be dropped, I am not sure it is something to care
| about.
| 
| Therefore please either:
| - Add libtirpc-dev as build dependency

I'll do that. We don't have that much little vs big endian out there anymore
but it is a feature that was long supported so it should remain supported.

Dirk

| - Disable the xdr feature support explicitly so that it does not depend
|   on the packages installed on the system.
| 
| Regards
| Aurelien

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#1065433: nagios4: Nagios sents wrong UP messages of hosts, that are NOT UP

2024-03-04 Thread Roland Christanell
Package: nagios4
Version: 4.4.6-4
Severity: important
X-Debbugs-Cc: li...@christanell.info

Dear Maintainer,

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

   * What led up to the situation?
- I installed nagios on a fresh debian12 vm, and everything seems to 
work fine. But when I'm checking the nagios logfile, I find multiple (~50/sec) 
entries, which report a Host UP that never went up.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
- I tryied to install it on new VMs multiple times, but the result 
stays the same. The strange thing it works perfect on the same Hardware when I 
use 'debian11'. I even tryied to install it on new servers, because I thougt 
maybe the old ones are not powerfull enaugh(we have ~1 Hosts and services 
on this instance)
   * What was the outcome of this action?
- Nothing, I was not able to solve the probelm.
   * What outcome did you expect instead?
- I thougt it would work fine, as with debain11, because the new 
servers are much more powerfull.

*** End of the template - remove these template lines ***


-- 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=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 nagios4 depends on:
ii  nagios4-cgi 4.4.6-4
ii  nagios4-common  4.4.6-4
ii  nagios4-core4.4.6-4

nagios4 recommends no packages.

Versions of packages nagios4 suggests:
pn  nagios-nrpe-plugin  

-- no debconf information



Bug#999931: virtuoso-opensource: depends on obsolete pcre3 library

2024-03-04 Thread Yavor Doganov
Hi Andreas,

On Wed, 28 Feb 2024 18:36:04 +0200,
Andreas Beckmann wrote:
> On Wed, 20 Dec 2023 21:18:20 +0200 Yavor Doganov  wrote:
> > Please find attached a patch;
> 
> Thanks for the patch, I uploaded it to Debian and so far noone
> complained ;-)

Thanks!  Complaints usually come a bit later...
 
> But the patch doesn't apply cleanly on newer virtuoso-opensource
> versions, there are actually changes in pcre usage in
> libsrc/Wi/sqlbif.h that require adjustments.

Right; there's a new function.

> Could you take a look again and update the patch?

Attached is a patch (commit made to the try-7.2.12 branch) that
updates pcre2.patch so that it applies cleanly and restores the
build-dependency on libpcre2-dev.

> I've never worked with (any version of) pcre (from the programmer
> persepective,

Likewise, I'm a complete novice here.  It would be nice to finish this
transition, though.
>From 82b97264413540aa72d96297a93a6fd24f56adc2 Mon Sep 17 00:00:00 2001
From: Yavor Doganov 
Date: Mon, 4 Mar 2024 16:29:34 +0200
Subject: [PATCH] pcre2.patch: Update for the new upstream release

---
 debian/changelog   |   4 +
 debian/control |   2 +-
 debian/patches/pcre2.patch | 152 -
 debian/patches/series  |   2 +-
 4 files changed, 107 insertions(+), 53 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 907e89fc6..a566f67f2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
 virtuoso-opensource (7.2.12+dfsg-0.1) UNRELEASED; urgency=medium
 
+  [ Andreas Beckmann ]
   * Non-maintainer upload.
   * New upstream release.
 
+  [ Yavor Doganov ]
+  * debian/patches/pcre2.patch: Update for the new upstream release.
+
  -- Andreas Beckmann   Wed, 28 Feb 2024 15:19:59 +0100
 
 virtuoso-opensource (7.2.5.1+dfsg1-0.6) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 5fd05fab9..db9b573c4 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Build-Depends: debhelper-compat (= 13),
gperf,
libldap2-dev,
libmagickwand-dev,
-   libpcre3-dev,
+   libpcre2-dev,
libreadline-dev,
libssl-dev,
libtirpc-dev,
diff --git a/debian/patches/pcre2.patch b/debian/patches/pcre2.patch
index 98c06be51..104c1abc9 100644
--- a/debian/patches/pcre2.patch
+++ b/debian/patches/pcre2.patch
@@ -2,12 +2,12 @@ Description: Port to PCRE2.
 Bug-Debian: https://bugs.debian.org/31
 Author: Yavor Doganov 
 Forwarded: no
-Last-Update: 2023-12-20
+Last-Update: 2024-03-04
 ---
 
 --- virtuoso-opensource.orig/libsrc/Wi/Makefile.am
 +++ virtuoso-opensource/libsrc/Wi/Makefile.am
-@@ -559,7 +559,7 @@
+@@ -563,7 +563,7 @@
$(libwi_base_la_sources)
  
  libwi_la_CFLAGS  = $(libwi_base_la_cflags)
@@ -18,7 +18,7 @@ Last-Update: 2023-12-20
  libwi_odbc_la_SOURCES += \
 --- virtuoso-opensource.orig/libsrc/Wi/bif_regexp.c
 +++ virtuoso-opensource/libsrc/Wi/bif_regexp.c
-@@ -30,7 +30,8 @@
+@@ -31,7 +31,8 @@
  
  // Debian maintainer: replaced by external PCRE
  // #include "util/pcrelib/pcre.h"
@@ -28,7 +28,7 @@ Last-Update: 2023-12-20
  
  /*
 typedef struct rx_query_s {
-@@ -66,15 +67,16 @@
+@@ -65,16 +66,17 @@
  typedef struct compiled_regexp_s
  {
int refctr;
@@ -42,14 +42,16 @@ Last-Update: 2023-12-20
  
 -int32 c_pcre_match_limit_recursion = 500;
 -int32 c_pcre_match_limit = 10;
+-int32 pcre_max_cache_sz = 2;
 +static pcre2_match_context *match_ctxt = NULL;
 +
 +uint32 c_pcre_match_limit_recursion = 500;
 +uint32 c_pcre_match_limit = 10;
- int32 pcre_max_cache_sz = 2;
++uint32 pcre_max_cache_sz = 2;
  int32 pcre_rnd_seed;
  
-@@ -97,6 +99,23 @@
+ id_hashed_key_t
+@@ -96,6 +98,23 @@
  }
  
  void
@@ -73,7 +75,7 @@ Last-Update: 2023-12-20
  release_compiled_regexp (id_hash_t *c_r, compiled_regexp_t *data)
  {
int delete_data;
-@@ -112,9 +131,7 @@
+@@ -111,9 +130,7 @@
if (!delete_data)
  return;
if (NULL != data->code)
@@ -84,7 +86,7 @@ Last-Update: 2023-12-20
dk_free (data, sizeof (compiled_regexp_t));
  }
  
-@@ -137,10 +154,11 @@
+@@ -136,10 +153,11 @@
  }
  
  static compiled_regexp_t *
@@ -99,9 +101,9 @@ Last-Update: 2023-12-20
regexp_key_t key;
compiled_regexp_t **val = NULL;
compiled_regexp_t tmp, *new_val;
-@@ -156,46 +174,18 @@
+@@ -155,46 +173,18 @@
  }
-   HT_LEAVE (c_r);
+   HT_UNLOCK (c_r);
dbg_printf (("regex compiling (%s) with options %x ...\n", pattern, 
options));
 -  tmp.code = pcre_compile (pattern, options, , , 0);
 +  tmp.code = pcre2_compile ((PCRE2_SPTR) pattern, strlen (pattern),
@@ -149,9 +151,9 @@ Last-Update: 2023-12-20
new_val->code = tmp.code;
 -  new_val->code_x = tmp.code_x;
new_val->refctr = 1;
-   HT_ENTER (c_r);
+   HT_WRLOCK (c_r);
pcre_cache_check (c_r);
-@@ -302,18 +292,18 @@
+@@ -301,18 +291,18 @@
  }
  
  
@@ -175,7 +177,7 @@ Last-Update: 2023-12-20
  /*
  #define PCRE_EXTENDED   0x0008
  

Bug#1065432: lazarus: cannot build with qt6

2024-03-04 Thread Peter B

Source: lazarus
Version: 3.0+dfsg1-8
Severity: normal
X-Debbugs-Cc: pe...@pblackman.plus.com

Dear Maintainer,

Cannot build packages with
  'lazbuild --ws=qt6'
Builds fail with
  '/usr/bin/ld.bfd: cannot find -lQt6Pas: No such file or directory'

Probably needs a libqt6pas package.

See
https://gitlab.archlinux.org/archlinux/packaging/packages/qt6pas/-/blob/main/PKGBUILD?ref_type=heads


Regards,
Peter


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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

2024-03-04 Thread Jonathan Corbet
Salvatore Bonaccorso  writes:

> Hi,
>
> Ben Hutchings reported in https://bugs.debian.org/1064035 a problem
> with the kernel-doc builds once 3080ea5553cc ("stddef: Introduce
> DECLARE_FLEX_ARRAY() helper") got applied in 5.10.210 (as
> prerequisite of another fix in 5.10.y):
>
>> The backport of commit 3080ea5553cc "stddef: Introduce
>> DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
>> introduced a syntax error:
>> 
>> Global symbol "$args" requires explicit package name (did you forget to 
>> declare "my $args"?) at ./scripts/kernel-doc line 1236.
>> Global symbol "$args" requires explicit package name (did you forget to 
>> declare "my $args"?) at ./scripts/kernel-doc line 1236.
>> Execution of ./scripts/kernel-doc aborted due to compilation errors.
>> 
>> This doesn't stop the documentation build process, but causes the
>> documentation that should be extracted by kernel-doc to be missing
>> from linux-doc-5.10.
>> 
>> We should be able to fix this by eithering backport commit
>> e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
>> into variables" or replacing /$args/ with /([^,)]+)/.
>> 
>> Ben.
>
> What would be prefered here from stable maintainers point of view?
> AFAICS e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
> expressions into variables") won't apply cleanly and needs some
> refactoring. The alternative pointed out by Ben would be to replace
> the /$args/ with  /([^,)]+)/.

Hmm...this is the first I see of any of this...

The latter fix seems like the more straightforward of the two.  The only
concern might be if there are other kernel-doc backports that might run
afoul of the same problem, hopefully not.

But this makes me wonder if there are other stable kernels that are
affected as well.  I guess that, despite all of the testing being done
on stable updates, nobody is testing the docs build?

Thanks,

jon



Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

2024-03-04 Thread Greg Kroah-Hartman
On Fri, Mar 01, 2024 at 01:31:10PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> Ben Hutchings reported in https://bugs.debian.org/1064035 a problem
> with the kernel-doc builds once 3080ea5553cc ("stddef: Introduce
> DECLARE_FLEX_ARRAY() helper") got applied in 5.10.210 (as
> prerequisite of another fix in 5.10.y):
> 
> > The backport of commit 3080ea5553cc "stddef: Introduce
> > DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
> > introduced a syntax error:
> > 
> > Global symbol "$args" requires explicit package name (did you forget to 
> > declare "my $args"?) at ./scripts/kernel-doc line 1236.
> > Global symbol "$args" requires explicit package name (did you forget to 
> > declare "my $args"?) at ./scripts/kernel-doc line 1236.
> > Execution of ./scripts/kernel-doc aborted due to compilation errors.
> > 
> > This doesn't stop the documentation build process, but causes the
> > documentation that should be extracted by kernel-doc to be missing
> > from linux-doc-5.10.
> > 
> > We should be able to fix this by eithering backport commit
> > e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
> > into variables" or replacing /$args/ with /([^,)]+)/.
> > 
> > Ben.
> 
> What would be prefered here from stable maintainers point of view?
> AFAICS e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
> expressions into variables") won't apply cleanly and needs some
> refactoring. The alternative pointed out by Ben would be to replace
> the /$args/ with  /([^,)]+)/.

I'll take a patch that does either, your call :)

thanks,

greg k-h



Bug#1065431: lintian: autopkgtests fail due to implicit definition of memcpy

2024-03-04 Thread Chris Hofstaedtler
Source: lintian
Version: 2.117.0
Severity: serious

dpkg has turned on -Werror=implicit-function-declaration on some
archs (compare #1065371 and the earlier bug requesting this). This
in turn causes lintian's autopkgtests to fail on armel, armhf and
maybe others, like this:

https://ci.debian.net/packages/l/lintian/testing/armel/43531737/

gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/tmp/autopkgtest-lxc.kznc_8xn/downtmp/autopkgtest_tmp/build-and-evaluate-test-packages/packages/checks/libraries/embedded/binaries-embedded-libs/binaries-embedded-libs-1.0=.
 -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -o 
libbz2 libbz2.c
In file included from libpng.c:2:
hardening-trigger.h: In function 'e':
hardening-trigger.h:3:3: error: implicit declaration of function 'memcpy' 
[-Werror=implicit-function-declaration]

Indeed hardening-trigger.h has a call to memcpy but neglects to
include .

Please fix this.

If dpkg reverts turning on the option, this bug obviously becomes
less severe, but its still a bug.

Chris



Bug#1065430: ITP: phosh-wallpapers -- Phosh Wallpapers and other artwork

2024-03-04 Thread Guido Günther
Package: wnpp
Severity: wishlist
Owner: Guido Günther 

* Package name: phosh-wallpapers
  Version : 0.37.0
  Upstream Contact: Guido Günther 
* URL : https://gitlab.gnome.org/guidog/phosh-wallpapers
* License : GPL, CC-BY-SA-4
  Description : Phosh Wallpapers and other artwork

This package contains the current wallpapers and plymouth theme.



Bug#1065429: dpkg -s: spurious error "dpkg-query: error: --status needs a valid package name"

2024-03-04 Thread Vincent Lefevre
On 2024-03-04 13:47:00 +0100, Vincent Lefevre wrote:
> I get the following error:
> 
> cventin:~> dpkg -s libc6-dev
> dpkg-query: error: --status needs a valid package name but 'libc6-dev' is 
> not: ambiguous package name 'libc6-dev' with more than one installed instance

Wrong copy-paste (to match what is given below), but this is the
same error:

cventin:~> dpkg -s libnsl-dev
dpkg-query: error: --status needs a valid package name but 'libnsl-dev' is not: 
ambiguous package name 'libnsl-dev' with more than one installed instance

> while this is a valid package name: with an "apt" command, I get:
> 
> The following packages were automatically installed and are no longer 
> required:
>   libnsl-dev libnsl-dev:i386 libnsl2:i386 libtirpc-dev libtirpc-dev:i386
>   ^^
>   libtirpc3:i386
> [...]
> 
> The package name is listed above.

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



Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

2024-03-04 Thread Bastian Blank
On Mon, Mar 04, 2024 at 11:28:12AM +, Luca Boccassi wrote:
> > But we where talking about kernel modules.
> There are kernel modules using BPF stuff? Never seen one, do you have
> an example?

No idea, but they get linked BTF information, so you could use them.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown



Bug#1062218: libaio: NMU diff for 64-bit time_t transition

2024-03-04 Thread Guillem Jover
Hi!

On Sun, 2024-03-03 at 23:00:00 +0100, Guillem Jover wrote:
> On Thu, 2024-02-29 at 02:35:16 +0100, Guillem Jover wrote:
> > Control: tags -1 - pending
> 
> > On Wed, 2024-01-31 at 19:36:09 +, Steve Langasek wrote:
> > > Source: libaio
> > > Version: 0.3.113-5
> > > Severity: serious
> > > Tags: patch pending
> > > Justification: library ABI skew on upgrade
> > > User: debian-...@lists.debian.org
> > > Usertags: time-t
> > 
> > > Please find the patch for this NMU attached.
> > > 
> > > If you have any concerns about this patch, please reach out ASAP.  
> > > Although
> > > this package will be uploaded to experimental immediately, there will be a
> > > period of several days before we begin uploads to unstable; so if 
> > > information
> > > becomes available that your package should not be included in the 
> > > transition,
> > > there is time for us to amend the planned uploads.
> > 
> > Unfortunately I just realized this patch is not enough. :/ This library
> > emits direct syscalls, so these are going to be broken with the time_t
> > size change, the syscalls need to be updated. I'm checking how to best
> > fix this, perhaps even via dual-ABI, to avoid the transition
> > altogether, but let's see.
> > 
> > I guess this might have been missed for other packages that that emit
> > direct syscalls and are not using the time64 variants for those
> > already.
> 
> Just as a status update, I've got most of this working, but upstream
> does not tend to be very responsive, so I think I'll do a proper
> SONAME bump with my proposed changes for the dual-ABI, to avoid any
> potential clashes with anything that gets upstream, and to make a
> revert easier, by reusing the t64 library names. And then once/if this
> gets merged upstream I can revert that and simply do the proper
> dual-ABI on the old SONAME and package names, as if nothing had
> happened (except for the required rebuilds).
> 
> Hopefully I can have something for upload today or tomorrow, hoping
> that this delay up to now, does not block too many things. :/

I've got all the upstream changes now ready, except that there's still
one test case failing, something wrong with the sigset_t type. I've run
out of time trying to track this down, but I've pushed what I have on
the pu/time64 branch, and will continue later today.

Thanks,
Guillem



Bug#1065429: dpkg -s: spurious error "dpkg-query: error: --status needs a valid package name"

2024-03-04 Thread Vincent Lefevre
Package: dpkg
Version: 1.22.5
Severity: important

I get the following error:

cventin:~> dpkg -s libc6-dev
dpkg-query: error: --status needs a valid package name but 'libc6-dev' is not: 
ambiguous package name 'libc6-dev' with more than one installed instance

while this is a valid package name: with an "apt" command, I get:

The following packages were automatically installed and are no longer required:
  libnsl-dev libnsl-dev:i386 libnsl2:i386 libtirpc-dev libtirpc-dev:i386
  ^^
  libtirpc3:i386
[...]

The package name is listed above.

"apt-cache show libc6-dev" also lists this package.

-- Package-specific info:

-- 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 dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b2
ii  libc62.37-15
ii  liblzma5 5.6.0-0.2
ii  libmd0   1.1.0-2
ii  libselinux1  3.5-2
ii  libzstd1 1.5.5+dfsg2-2
ii  tar  1.35+dfsg-3
ii  zlib1g   1:1.3.dfsg-3+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.7.12
pn  debsig-verify  

-- no debconf information

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



Bug#1064950: AW: AW: Bug#1064950: apache2: (Legacy?) "Depends: apache2-data (= ${source:Version})," in debian/control breaks binNMU builds.

2024-03-04 Thread Warlich, Christof
Sebastian Ramacher wrote:
> Christof Warlich wrote:
> > If this assumption is true, then why is the Debian build system (i.e. 
> > dpkg-buildpackage) not smart enough to simply ignore an existing +bX 
> > extension for Architecture: all binary packages? IMHO, this would simplify 
> > matters, as it would have avoided the pitfall that I stumbled into 
> > altogether.
> 
> binNMUs are handled a layer above. sbuild will pass the correct options to 
> dpkg-buildpackage to build binNMUs. If you are interested in having binNMU 
> builds for your own infrastructure, you'll probably need to take a look at 
> the sbuild source to see how it is implemented.

Ok, so I'd better start using sbuild instead. Again, thanks for the valuable 
info and your time.



Bug#1060318: [Pkg-opencl-devel] The right bug is this one #1060318

2024-03-04 Thread Andreas Beckmann

On 04/03/2024 11.21, Picca Frédéric-Emmanuel wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060318#10


Unfortunately I cannot reproduce that by rebuilding 2.0.0+dfsg-1 from 
sid (git has nothing newer) in sid or testing pbuilder chroots on amd64.


Andreas



Bug#1065428: librocsolver-doc: missing Breaks+Replaces: librocsolver-dev (<< 5.5.1-5~)

2024-03-04 Thread Andreas Beckmann
Package: librocsolver-doc
Version: 5.5.1-5~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts file-conflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

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 .../librocsolver-doc_5.5.1-5~exp1_all.deb ...
  Unpacking librocsolver-doc (5.5.1-5~exp1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/librocsolver-doc_5.5.1-5~exp1_all.deb (--unpack):
   trying to overwrite 
'/usr/share/doc/librocsolver-dev/examples/example_basic.c', which is also in 
package librocsolver-dev 5.5.1-4
  Errors were encountered while processing:
   /var/cache/apt/archives/librocsolver-doc_5.5.1-5~exp1_all.deb


cheers,

Andreas


librocsolver-dev=5.5.1-4_librocsolver-doc=5.5.1-5~exp1.log.gz
Description: application/gzip


Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Can't connect to Active Directory with openssl

2024-03-04 Thread Kurt Roeckx
Hi,

It's unclear to me what you're reporting as error. The connection seems to be 
working. The verification of the certificate seems to fail. It seems you have 
your own CA, but the CA is not trusted because it's not in the certificate 
store.

Kurt

Bug#1063308: transition: libvterm

2024-03-04 Thread James McCoy
On Mon, Feb 05, 2024 at 10:54:12PM -0500, James McCoy wrote:
> libvterm doesn't have a stable API/ABI yet, so although the SONAME
> didn't change, this is a breaking update.
> 
> There are 3 packages which use libvterm:
> * pangoterm: I've filed #1063196 to RM the package, so it shouldn't
>   block
> * emacs-libvterm: It supports building against either 0.1 or 0.3, so it
>   just needs a binNMU
> * neovim: 0.7.2 (in unstable) only supports 0.1, but 0.9.5 (in
>   experimental) supports 0.3.
> 
> Ben file:
> 
> title = "libvterm 0.1 -> 0.3";
> is_affected = .build-depends ~ "libvterm-dev";
> is_good = .depends ~ /libvterm0 \(>= 0\.[23]/;
> is_bad = .depends ~ /libvterm0 \(>= 0\.1/;

This was ACKed on IRC, so I've uploaded libvterm and neovim.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB



Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-03-04 Thread Bastian Blank
On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote:
> On 04.03.24 11:29, Bastian Blank wrote:
> > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
> > 
> > Please be a bit more precise, there are no symlinks in this directory.
> > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h
> > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h
> > | # find /usr/alpha-linux-gnu/include/ -type l
> > | #
> yes, that is the problem. the cross gcc expects these headers in
> /usr/alpha-linux-gnu/include, not in the header location for the host.

Please show your problem with a log, my crystal ball is broken.

arm-linux-gnueabihf-cpp-13 tells me:

| #include <...> search starts here:
|  /usr/lib/gcc-cross/arm-linux-gnueabihf/13/include
|  
/usr/lib/gcc-cross/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/include
|  /usr/include/arm-linux-gnueabihf
|  /usr/include
| End of search list.

So clearly /usr/include/arm-linux-gnueabihf is used.

Regards,
Bastian

-- 
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3



Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space

2024-03-04 Thread Andreas Beckmann
Control: forwarded -1 
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/issues/2397


On 03/03/2024 20.52, Paul Gevers wrote:

Source: spirv-llvm-translator-14
Version: 14.0.0-10



Since a couple of days, our workers on s390x are dying because some test
is filling up all disk space. Several days ago, I wrongly suspected 

One of the suspects started to be spirv-llvm-translator-14, so I ran its 
autopkgtest manually, while logging disk use every 10 seconds (I started 
slightly delayed because I monitored the wrong partition first). As you 
can see below, during the test it grows from 17 GB (at the end) to its 
peak at 179 GB. That's not acceptable on our infrastructure. One file I 
happened to spot on the way was 
build/test/test_output/DebugInfo/Generic/Output/two-cus-from-same-file.ll.tmp:

-rw-r--r-- 1 root root  41G Mar  3 19:18 two-cus-from-same-file.ll.tmp

I have added spirv-llvm-translator-14 to our reject-list on s390x.

As this seems to be a rather new issue, I'm wondering if it's due to:
* Add build-needed autopkgtest for spirv-headers compat check.


Probably.

The buildds report disk usage when building spirv-llvm-translator-* 
between 400MB and 600MB on all architectures except s390x, ppc64, 
sparc64, i.e. all the big-endian ones, where it's slightly above 40GB 
(which very vell corresponds to the file you spotted).
This started with 14.0.0-2 (i.e. 14.0.0-1 was around 500MB on s390x, 
too) which had "* Enable build-time tests, ignore failures on !amd64."


So maybe I should skip the build-time tests on big-endian altogether.

Failure rates:
amd64: 0%
i386: <1%
ppc64el: <2%
most: <10%
s390x: >60%
ppc64: >60%

(Upstream seems to test the testsuite only on amd64, 
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/issues/1964)


Andreas



Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

2024-03-04 Thread Luca Boccassi
On Mon, 4 Mar 2024 at 10:32, Bastian Blank  wrote:
>
> On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote:
> > Yes precisely, the bpf program source can just include vmlinux.h and it
> > should build and run as expected.
>
> But we where talking about kernel modules.
>
> Bastian

There are kernel modules using BPF stuff? Never seen one, do you have
an example?



Bug#1059786: cross-toolchain-base: Migrating linux-libc-dev

2024-03-04 Thread Matthias Klose

Control: tags -1 - patch

The headers have to be provided in the /usr//include location.

Currently, that is not possible, because linux-libc-dev provides the 
linux-libc-dev-cross-* packages, without providing these headers in the 
old locations.


The assumption to include the headers for the target from the header 
location of the host is wrong.




Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-03-04 Thread Matthias Klose

Control: unmerge 1059786 -1
Control: reassign -1 linux-libc-dev
Control: found -1 6.7.7-1
Control: severity -1 serious

On 04.03.24 11:22, Bastian Blank wrote:

Control: reassign -1 cross-toolchain-base
Control: forcemerge 1059786 -1

On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:

linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
do that completely


This is #1059786.  This lacks a response from you.  So I'm merging
those.


No it is not. Re-assigning and resetting the severity.

Without the headers available at the /usr//include location, I 
consider this a hijack of the linux-libc-dev-cross-* packages.


I'll reply to the c-t-b issue separately.

Matthias



Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-03-04 Thread Matthias Klose

On 04.03.24 11:29, Bastian Blank wrote:

On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:

However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.


Please be a bit more precise, there are no symlinks in this directory.

| # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h
| linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h
| # find /usr/alpha-linux-gnu/include/ -type l
| #


yes, that is the problem. the cross gcc expects these headers in 
/usr/alpha-linux-gnu/include, not in the header location for the host.




Bug#1065424: Acknowledgement (Can't connect to Active Directory with openssl)

2024-03-04 Thread Maciej Bogucki

Hi,

I have just attached pcap file.

$ tcpdump -r nsd-sdproxy1.pcap  -X -s 0 -n
reading from file nsd-sdproxy1.pcap, link-type EN10MB (Ethernet)
11:59:10.332867 IP 192.168.92.85.35072 > 192.168.92.95.ldaps: Flags [S], 
seq 2384244703, win 64240, options [mss 1460,sackOK,TS val 271242346 ecr 
0,nop,wscale 7], length 0

    0x:  4500 003c 0f2e 4000 4006 f188 c0a8 5c55 E..<..@.@.\U
    0x0010:  c0a8 5c5f 8900 027c 8e1c afdf   ..\_...|
    0x0020:  a002 faf0 3a34  0204 05b4 0402 080a :4..
    0x0030:  102a d46a   0103 0307    .*.j
11:59:10.333043 IP 192.168.92.95.ldaps > 192.168.92.85.35072: Flags 
[S.], seq 3935569972, ack 2384244704, win 8192, options [mss 
1460,nop,wscale 8,sackOK,TS val 145289471 ecr 271242346], length 0

    0x:  4500 003c 6bf3 4000 8006 54c3 c0a8 5c5f E..11:59:10.333067 IP 192.168.92.85.35072 > 192.168.92.95.ldaps: Flags [.], 
ack 1, win 502, options [nop,nop,TS val 271242346 ecr 145289471], length 0

    0x:  4500 0034 0f2f 4000 4006 f18f c0a8 5c55 E..4./@.@.\U
    0x0010:  c0a8 5c5f 8900 027c 8e1c afe0 ea94 0835 ..\_...|...5
    0x0020:  8010 01f6 3a2c  0101 080a 102a d46a :,...*.j
    0x0030:  08a8 f0ff    
11:59:10.333626 IP 192.168.92.85.35072 > 192.168.92.95.ldaps: Flags 
[P.], seq 1:298, ack 1, win 502, options [nop,nop,TS val 271242346 ecr 
145289471], length 297

    0x:  4500 015d 0f30 4000 4006 f065 c0a8 5c55 E..].0@.@..e..\U
    0x0010:  c0a8 5c5f 8900 027c 8e1c afe0 ea94 0835 ..\_...|...5
    0x0020:  8018 01f6 3b55  0101 080a 102a d46a ;U...*.j
    0x0030:  08a8 f0ff 1603 0101 2401 0001 2003 0355 $..U
    0x0040:  a446 d682 d587 54c0 91fe b515 72a4 0510 .FT.r...
    0x0050:  777b 661e 465f 6e52 532d 0252 51ff 0820 w{f.F_nRS-.RQ...
    0x0060:  8674 935b db74 b74d 20ec 9f7c 8e7e f905 .t.[.t.M...|.~..
    0x0070:  c284 3483 34cb d782 bb0d 5ab5 5711 a826 ..4.4.Z.W..&
    0x0080:  003e 1302 1303 1301 c02c c030 009f cca9 .>...,.0
    0x0090:  cca8 ccaa c02b c02f 009e c024 c028 006b .+./...$.(.k
    0x00a0:  c023 c027 0067 c00a c014 0039 c009 c013 .#.'.g.9
    0x00b0:  0033 009d 009c 003d 003c 0035 002f 00ff .3.=.<.5./..
    0x00c0:  0100 0099 000b 0004 0300 0102 000a 0016 
    0x00d0:  0014 001d 0017 001e 0019 0018 0100 0101 
    0x00e0:  0102 0103 0104 0023  0016  0017 ...#
    0x00f0:   000d 002a 0028 0403 0503 0603 0807 .*.(
    0x0100:  0808 0809 080a 080b 0804 0805 0806 0401 
    0x0110:  0501 0601 0303 0301 0302 0402 0502 0602 
    0x0120:  002b 0009 0803 0403 0303 0203 0100 2d00 .+-.
    0x0130:  0201 0100 3300 2600 2400 1d00 20fd 5f22 3.&.$._"
    0x0140:  ef9b ae99 bbed f2de 8b77 b8ec d2b9 ecd3 .w..
    0x0150:  1461 dbda f4f6 8056 7b55 9c20 45 .a.V{U..E
11:59:10.333901 IP 192.168.92.95.ldaps > 192.168.92.85.35072: Flags 
[R.], seq 1, ack 298, win 0, length 0

    0x:  4500 0028 6bf4 4000 8006 54d6 c0a8 5c5f E..(k.@...T...\_
    0x0010:  c0a8 5c55 027c 8900 ea94 0835 8e1c b109 ..\U.|.5
    0x0020:  5014  b85e     P^
$


Pozdrawiam serdecznie
Maciej Bogucki

On 4.03.2024 11:21, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1065424: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065424.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian OpenSSL Team 

If you wish to submit further information on this problem, please
send it to 1065...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.


nsd-sdproxy1.pcap
Description: application/vnd.tcpdump.pcap


Bug#1065427: python3-werkzeug has unnecessary libjs-jQuery dependency

2024-03-04 Thread Nils Kattenbeck
Package: python3-werkzeug
Version: 2.2.2-3

As of Version 2 of Werkzeug the jQuery dependency which was previously
used for the debugger is no longer needed. However, it is still listed
as a dependency of the Debian package. As a consequence the installed
size is nearly doubled.

It seems like the Files-Excluded setting was already updated (as
Debian used to remove the bundled jQuery version and add libjs-jQuery)
but the dependency on libjs-jQuery still exists.

Salsa commit updating the Files-Excluded:
https://salsa.debian.org/python-team/packages/python-werkzeug/-/commit/1d55463c59b821f2a9b91803994d5d7c228dc365
Upstream PR where jQuery got removed, this was shipped in v2.0.0:
https://github.com/pallets/werkzeug/pull/1857



Bug#1065426: RM: papi-examples [all] -- ROM; switched from arch:all to arch:any

2024-03-04 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Please remove the cruft arch:all package papi-examples from sid and
experimental, it had to be turned into an arch:any package since the
generated build system for the examples contains arch dependent paths
etc.

papi  | 7.1.0-3   | unstable   | source
papi  | 7.1.0-5   | unstable   | source
papi-examples | 7.1.0-3   | unstable   | all
papi-examples | 7.1.0-5   | unstable   | amd64, arm64, i386, mips64el, 
ppc64el
papi  | 7.1.0-4   | experimental | source
papi-examples | 7.1.0-4   | experimental | all

Thanks

Andreas



Bug#1065284: lucene++: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lucene++-3.0.9/debian/changelog lucene++-3.0.9/debian/changelog
--- lucene++-3.0.9/debian/changelog 2024-02-29 00:10:42.0 +1300
+++ lucene++-3.0.9/debian/changelog 2024-03-04 23:42:22.0 +1300
@@ -1,3 +1,11 @@
+lucene++ (3.0.9-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065284)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 23:42:22 +1300
+
 lucene++ (3.0.9-3) unstable; urgency=medium
 
   * Upload to sid
diff -Nru lucene++-3.0.9/debian/control lucene++-3.0.9/debian/control
--- lucene++-3.0.9/debian/control   2024-02-29 00:09:37.0 +1300
+++ lucene++-3.0.9/debian/control   2024-03-04 23:42:21.0 +1300
@@ -2,7 +2,8 @@
 Priority: optional
 Maintainer: Łukasz 'sil2100' Zemczak 
 Uploaders: Gianfranco Costamagna 
-Build-Depends: cmake,
+Build-Depends: dpkg-dev (>> 1.22.5),
+   cmake,
debhelper-compat (= 13),
libboost-date-time-dev,
libboost-filesystem-dev,


Bug#1065279: libcanberra: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libcanberra-0.30/debian/changelog libcanberra-0.30/debian/changelog
--- libcanberra-0.30/debian/changelog   2024-02-29 09:08:28.0 +1300
+++ libcanberra-0.30/debian/changelog   2024-03-04 23:41:54.0 +1300
@@ -1,3 +1,11 @@
+libcanberra (0.30-12.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065279)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 23:41:54 +1300
+
 libcanberra (0.30-12) unstable; urgency=medium
 
   * Stop using debian/control.in and dh-sequence-gnome
diff -Nru libcanberra-0.30/debian/control libcanberra-0.30/debian/control
--- libcanberra-0.30/debian/control 2024-02-29 09:08:28.0 +1300
+++ libcanberra-0.30/debian/control 2024-03-04 23:41:54.0 +1300
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: Jeremy Bícha , Josselin Mouette 
, Laurent Bigonville , Marco Trevisan 
(Treviño) , Sjoerd Simons 
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>> 1.22.5),
+   debhelper-compat (= 13),
libltdl-dev | libltdl7-dev (>= 2.2.6),
libasound2-dev [linux-any],
libvorbis-dev,


Bug#1065278: gtkmm3.0: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gtkmm3.0-3.24.8/debian/changelog gtkmm3.0-3.24.8/debian/changelog
--- gtkmm3.0-3.24.8/debian/changelog2024-02-29 09:04:43.0 +1300
+++ gtkmm3.0-3.24.8/debian/changelog2024-03-04 23:41:24.0 +1300
@@ -1,3 +1,11 @@
+gtkmm3.0 (3.24.8-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065278)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 23:41:24 +1300
+
 gtkmm3.0 (3.24.8-3) unstable; urgency=medium
 
   * Use upstream patch to fix GdkRGBA test on i386
diff -Nru gtkmm3.0-3.24.8/debian/control gtkmm3.0-3.24.8/debian/control
--- gtkmm3.0-3.24.8/debian/control  2024-02-29 09:04:43.0 +1300
+++ gtkmm3.0-3.24.8/debian/control  2024-03-04 23:41:24.0 +1300
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: Jeremy Bícha 
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>> 1.22.5),
+   debhelper-compat (= 13),
doxygen,
graphviz,
libgtk-3-dev (>= 3.24.0),


Bug#1065265: glade: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru glade-3.40.0/debian/changelog glade-3.40.0/debian/changelog
--- glade-3.40.0/debian/changelog   2024-02-28 15:41:41.0 +1300
+++ glade-3.40.0/debian/changelog   2024-03-04 23:38:30.0 +1300
@@ -1,3 +1,11 @@
+glade (3.40.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065265)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 
23:38:30 +1300
+
 glade (3.40.0-4) unstable; urgency=medium
 
   * Release to unstable (Closes: #1062127)
diff -Nru glade-3.40.0/debian/control glade-3.40.0/debian/control
--- glade-3.40.0/debian/control 2024-02-28 15:41:41.0 +1300
+++ glade-3.40.0/debian/control 2024-03-04 23:38:30.0 +1300
@@ -6,8 +6,9 @@
 Section: gnome
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Emilio Pozuelo Monfort , Laurent Bigonville 
, Marco Trevisan (Treviño) , Michael Biebl 

-Build-Depends: at-spi2-core ,
+Uploaders: Emilio Pozuelo Monfort , Jeremy Bícha 
, Laurent Bigonville , Marco Trevisan 
(Treviño) , Michael Biebl 
+Build-Depends: dpkg-dev (>> 1.22.5),
+   at-spi2-core ,
dbus ,
debhelper-compat (= 13),
dh-sequence-gir,
diff -Nru glade-3.40.0/debian/control.in glade-3.40.0/debian/control.in
--- glade-3.40.0/debian/control.in  2024-02-28 15:41:41.0 +1300
+++ glade-3.40.0/debian/control.in  2024-03-04 23:38:30.0 +1300
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: @GNOME_TEAM@
-Build-Depends: at-spi2-core ,
+Build-Depends: dpkg-dev (>> 1.22.5),
+   at-spi2-core ,
dbus ,
debhelper-compat (= 13),
dh-sequence-gir,


Bug#1065356: Issues in man pages of cron

2024-03-04 Thread Georges Khaznadar
Hello Helge,

Helge Kreutzmann a écrit :

> > > Secondly we translators see the manpages in the neutral po format,
> > > i.e. converted and harmonized, but not the original source (be it man,
> > > groff, xml or other). So we cannot provide a true patch (where
> > > possible), but only an approximation which you need to convert into
> > > your source format.
> > 
> > The original format for Debian's manpages regarding cron is groff.

Would the translators' work become easier if the manpages were rewritten
in some higher-level language than groff? I must admit that I am not at
ease with groff sources, and that I use weird hacks when modifying such
or such part of a manpage when some feature of cron or crontab is
changed.

The source in groff format often contains very short lines, where more
context would be necessary to grasp the sense.

So, please tell me whether it would be useful to rewrite the three
manpages in XML format? 

This would mean writing sensible paragraphs, with lines of seventy or
more characters, containing simple text and elements marked by tags like
 or , which
convey more sense than the bare bold/italics directives available in
groff.

> That's usual, but po4a transforms this in a more friendly format for
> us translators.

Here is what I understood so far, from the first e-mail you sent me
yesterday, and from the enlightenments provided by the second one:

  Each report chunk is divided in two parts, a list of issues and a
  context string, which I describe below in some wild meta-language
  using square brackets:

  -
  Man page: [source file]
  Issue #n: [incorrect format] → [fixed format]
  ...

  "[some context, extracted by po4a from the source file]"
  "..."
  --
  -

Please can you confirm or infirm that the interpretation above can be
trusted?

> I think most of the report boils down that you update the patches by
> using .B instead of .I or sometimes .BI

This is a particular consequence of a more general guideline, to follow
recommendations provided by `man man-pages`. I would feel more at ease
if this compliance was ensured by an automated process fed by a source
file with high-level syntactic markup.

> P.S. And since there is probably little changes in cron nowadays, most
>  likely few if none further reports from my side…

I began to maintain cron two years ago, and lowered the bug report count
by approximately one half (regarding reports in bugs.debian.org). Some
reports entailed creating new features, and modifying the manuals
accordingly. I fear that the fifty remaining bug reports will slowly,
but surely involve future changes in man pages, so rewriting them in a
high-level language would probably make future changes more consistent.

Please can you consider this proposition? I would rewrite an XML source
for the manpage crontab.1, and send it; then you run your tools
(probably po4a), and send me a feedback to tell me whether I introduced
more inconsistencies than the count of fixes.

Thank you in advance for your response.

Best regards,   Georges



signature.asc
Description: PGP signature


Bug#1065277: gtkmm2.4: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gtkmm2.4-2.24.5/debian/changelog gtkmm2.4-2.24.5/debian/changelog
--- gtkmm2.4-2.24.5/debian/changelog2024-02-29 04:22:27.0 +1300
+++ gtkmm2.4-2.24.5/debian/changelog2024-03-04 23:40:46.0 +1300
@@ -1,3 +1,11 @@
+gtkmm2.4 (1:2.24.5-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065277)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 
23:40:46 +1300
+
 gtkmm2.4 (1:2.24.5-5) unstable; urgency=medium
 
   [ Jeremy Bícha ]
diff -Nru gtkmm2.4-2.24.5/debian/control gtkmm2.4-2.24.5/debian/control
--- gtkmm2.4-2.24.5/debian/control  2024-02-29 04:22:27.0 +1300
+++ gtkmm2.4-2.24.5/debian/control  2024-03-04 23:40:46.0 +1300
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: Emilio Pozuelo Monfort , Jeremy Bícha 

-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>> 1.22.5),
+   debhelper-compat (= 13),
libgtk2.0-dev (>= 2.24.0),
libglibmm-2.4-dev (>= 2.27.93),
libpangomm-1.4-dev (>= 2.27.1),


Bug#1065272: orc: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru orc-0.4.34/debian/changelog orc-0.4.34/debian/changelog
--- orc-0.4.34/debian/changelog 2024-02-29 01:51:27.0 +1300
+++ orc-0.4.34/debian/changelog 2024-03-04 23:40:36.0 +1300
@@ -1,3 +1,11 @@
+orc (1:0.4.34-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065272)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 23:40:36 +1300
+
 orc (1:0.4.34-4) unstable; urgency=medium
 
   * Team upload
diff -Nru orc-0.4.34/debian/control orc-0.4.34/debian/control
--- orc-0.4.34/debian/control   2024-02-29 01:51:27.0 +1300
+++ orc-0.4.34/debian/control   2024-03-04 23:40:36.0 +1300
@@ -4,7 +4,8 @@
 Maintainer: Maintainers of GStreamer packages 
 Uploaders: Sebastian Dröge ,
Sjoerd Simons 
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>> 1.22.5),
+   debhelper-compat (= 13),
meson,
pkg-config,
gtk-doc-tools


Bug#1065271: gsound: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gsound-1.0.3/debian/changelog gsound-1.0.3/debian/changelog
--- gsound-1.0.3/debian/changelog   2024-02-29 03:29:46.0 +1300
+++ gsound-1.0.3/debian/changelog   2024-03-04 23:40:14.0 +1300
@@ -1,3 +1,11 @@
+gsound (1.0.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065271)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 
23:40:14 +1300
+
 gsound (1.0.3-3) unstable; urgency=medium
 
   * Stop using debian/control.in and dh-sequence-gnome
diff -Nru gsound-1.0.3/debian/control gsound-1.0.3/debian/control
--- gsound-1.0.3/debian/control 2024-02-29 03:29:46.0 +1300
+++ gsound-1.0.3/debian/control 2024-03-04 23:40:14.0 +1300
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: Jeremy Bícha , Laurent Bigonville 

-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>> 1.22.5),
+   debhelper-compat (= 13),
dh-sequence-gir,
gtk-doc-tools,
libcanberra-dev,


Bug#1065252: glibmm2.68: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru glibmm2.68-2.78.1/debian/changelog glibmm2.68-2.78.1/debian/changelog
--- glibmm2.68-2.78.1/debian/changelog  2024-02-28 15:49:12.0 +1300
+++ glibmm2.68-2.78.1/debian/changelog  2024-03-04 23:35:03.0 +1300
@@ -1,3 +1,11 @@
+glibmm2.68 (2.78.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065252)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 23:35:03 +1300
+
 glibmm2.68 (2.78.1-2) unstable; urgency=medium
 
   * Release to unstable (Closes: #1062137)
diff -Nru glibmm2.68-2.78.1/debian/control glibmm2.68-2.78.1/debian/control
--- glibmm2.68-2.78.1/debian/control2024-02-28 15:49:12.0 +1300
+++ glibmm2.68-2.78.1/debian/control2024-03-04 23:35:03.0 +1300
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: Jeremy Bícha , Michael Biebl 
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>> 1.22.5),
+   debhelper-compat (= 13),
doxygen,
glib-networking ,
graphviz,


Bug#1065425: Does not upgrade from libpam0t64

2024-03-04 Thread Christoph Berg
Package: libpam0g
Version: 1.5.3-6
Severity: serious

On my sid system, libpam0g doesn't get upgraded because apt thinks the
libpam0t64 package is good enough:

$ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

$ apt-cache policy libpam0t64
libpam0t64:
  Installed: 1.5.3-4
  Candidate: 1.5.3-4
  Version table:
 *** 1.5.3-4 100
100 /var/lib/dpkg/status

$ apt-cache policy libpam0g
libpam0g:
  Installed: (none)
  Candidate: 1.5.3-6
  Version table:
 1.5.3-6 500
500 http://deb.debian.org/debian sid/main amd64 Packages
 1.5.2-9.1+b1 -1
100 /var/lib/dpkg/status

Christoph



Bug#1065269: glibmm2.4: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru glibmm2.4-2.66.6/debian/changelog glibmm2.4-2.66.6/debian/changelog
--- glibmm2.4-2.66.6/debian/changelog   2024-02-28 15:45:03.0 +1300
+++ glibmm2.4-2.66.6/debian/changelog   2024-03-04 23:39:52.0 +1300
@@ -1,3 +1,11 @@
+glibmm2.4 (2.66.6-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065269)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 23:39:52 +1300
+
 glibmm2.4 (2.66.6-3) unstable; urgency=medium
 
   * Stop using debian/control.in and dh-sequence-gnome
diff -Nru glibmm2.4-2.66.6/debian/control glibmm2.4-2.66.6/debian/control
--- glibmm2.4-2.66.6/debian/control 2024-02-28 15:45:03.0 +1300
+++ glibmm2.4-2.66.6/debian/control 2024-03-04 23:39:52.0 +1300
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: Jeremy Bícha 
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>> 1.22.5),
+   debhelper-compat (= 13),
doxygen,
glib-networking ,
graphviz,


Bug#1065260: gegl: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-04 Thread Michael Hudson-Doyle
Dear maintainer,

Please find attached a patch to add the dependency on dpkg-dev for the
time_t transition.  This patch is being uploaded to unstable.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gegl-0.4.48/debian/changelog gegl-0.4.48/debian/changelog
--- gegl-0.4.48/debian/changelog2024-02-28 15:37:42.0 +1300
+++ gegl-0.4.48/debian/changelog2024-03-04 23:38:29.0 +1300
@@ -1,3 +1,11 @@
+gegl (1:0.4.48-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build depedency on dpkg-dev (>= 1.22.5) for time_t transition.
+(Closes: #1065260)
+
+ -- Michael Hudson-Doyle   Mon, 04 Mar 2024 23:38:29 +1300
+
 gegl (1:0.4.48-2) unstable; urgency=medium
 
   * Release to unstable (Closes: #1062066)
diff -Nru gegl-0.4.48/debian/control gegl-0.4.48/debian/control
--- gegl-0.4.48/debian/control  2024-02-28 15:37:42.0 +1300
+++ gegl-0.4.48/debian/control  2024-03-04 23:38:29.0 +1300
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: Emilio Pozuelo Monfort , Jeremy Bícha 
, Josselin Mouette 
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>> 1.22.5),
+   debhelper-compat (= 13),
dh-sequence-gir,
dh-sequence-gnome,
gir1.2-babl-0.1-dev,


Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

2024-03-04 Thread Bastian Blank
On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote:
> Yes precisely, the bpf program source can just include vmlinux.h and it
> should build and run as expected.

But we where talking about kernel modules.

Bastian

-- 
Vulcans never bluff.
-- Spock, "The Doomsday Machine", stardate 4202.1



Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-03-04 Thread Bastian Blank
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.

Please be a bit more precise, there are no symlinks in this directory.

| # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h 
| linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h
| # find /usr/alpha-linux-gnu/include/ -type l
| #

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown



Bug#1065343: closed by Bo YU (Re: #1065343: libuuid1t64 overwrite)

2024-03-04 Thread griera
On Mon, 4 Mar 2024 10:45:41 +0100
Chris Hofstaedtler  wrote:

> > debootstrap still has issue:
> > 
> > ```
> > ...
> > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists
> > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to 
> > ‘libuuid.so.1.3.0’: File exists
> > tar: Exiting with failure status due to previous errors
> > 
> > ```
> > 
> > Anyone's help in assessing when this issue(t64 transition break debootstrap 
> > on sid) will be resolved would be appreciated!
> 
> There is nothing we can do now, that is not already on the todo list
> of the people working on the transition.
> 
> Just be patient. It is, after all, unstable.
> 
> I'm told that other chroot-creation tools might not have this
> problem (i.e. mmdebstrap).

Thank you very much! I have already been able to install with:

$ sudo mmdebstrap sid /srv/chroot/sid

Regards.

> 
> Chris
> 



Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-03-04 Thread Bastian Blank
Control: reassign -1 cross-toolchain-base
Control: forcemerge 1059786 -1

On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely

This is #1059786.  This lacks a response from you.  So I'm merging
those.

Bastian

-- 
There are always alternatives.
-- Spock, "The Galileo Seven", stardate 2822.3



Bug#1065362: Need for kea-msg-compiler

2024-03-04 Thread Quentin Armitage
Paride,

Many thanks for your response.

So far as I can tell the only use of the kea-dev package is for building hooks. 
Hooks should
include some logging output, and without kea-msg-compiler the message sources 
cannot be
built. This essentially make the current kea-dev package not usable.

Bug #1065361 (kea-dev: cfg_globals.h is missing) also renders the current 
kea-dev to all
intents and purposes unusable, so I think it would be really helpful to have an 
updated kea-
dev package adding both kea-msg-compiler and cfg_globals.h for Bookworm.

Quentin Armitage


Bug#1065424: Can't connect to Active Directory with openssl

2024-03-04 Thread Maciej Bogucki

Package: openssl
  Version: 3.0.11-1~deb12u2


  When I invoke `/usr/bin/openssl s_client -connect 192.168.92.95:636`


root@nsd-sdproxy1:~# cat /etc/debian_version
12.5
root@nsd-sdproxy1:~#

root@nsd-sdproxy1:~# uname -a
Linux nsd-sdproxy1 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 
(2024-02-01) x86_64 GNU/Linux
root@nsd-sdproxy1:~#


I have the latest patches installed.


Telnet works

root@nsd-sdproxy1:~# telnet  192.168.92.95 636
Trying 192.168.92.95...
Connected to nsd-ad.
Escape character is '^]'.


from latest rocky linux it is ok

[bogucki@nsd-ansible ~]$ /usr/bin/openssl  s_client -connect 192.168.92.95:636
CONNECTED(0003)
Can't use SSL_get_servername
depth=0 CN = dc1.dev.it
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = dc1.dev.it
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = dc1.dev.it
verify return:1
---
Certificate chain
 0 s:CN = dc1.dev.it
   i:DC = it, DC = dev, CN = dev-DC1-CA
---
Server certificate
-BEGIN CERTIFICATE-
MIIFtDCCBJygAwIBAgITHQIpIoHQZ/LB4jANBgkqhkiG9w0BAQUF
ADA+MRIwEAYKCZImiZPyLGQBGRYCaXQxEzARBgoJkiaJk/IsZAEZFgNkZXYxEzAR
BgNVBAMTCmRldi1EQzEtQ0EwHhcNMjMxMjIwMjIzNDUyWhcNMjQxMjE5MjIzNDUy
WjAVMRMwEQYDVQQDEwpkYzEuZGV2Lml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAuNy00MrsJl16YwJ7aBq3qKQkGKiWwIpJPIhnSxs+oSWHyXnPzElh
3YybHYSFmVhCioqgv9AacMEQUfgzanURMdDRetOMfnYD0TyfMM9FHcV+U3QR7XRc
gd9V+7V04Pp/tJzfatOljiZ32OIf+RpuOOzaAs7K2sPu7C9asoJvT292SWl6A+D/
I6y2ugaKpLfqQaJ3DD11u+Zyfsg+ynAvWrxOhWG1+ImHQShDuhzDZFaVnypw0HvA
Exm57lIsLGSYpecPCxN1x4dKQ0FgKfruH6S/IuAdY49WOjB8qDEg5dQFr85zYbZd
MyKqUN5e82v2Dy9cM/WBWC+M8DVsf75dQwIDAQABo4IC0jCCAs4wLwYJKwYBBAGC
NxQCBCIeIABEAG8AbQBhAGkAbgBDAG8AbgB0AHIAbwBsAGwAZQByMB0GA1UdJQQW
MBQGCCsGAQUFBwMCBggrBgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAweAYJKoZIhvcN
AQkPBGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFl
AwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUr
DgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUfBtL8l6VeeYQ7A98ffO89tTy72Iw
HwYDVR0jBBgwFoAU1YtlfOHW2JxHTtoslbmjPW0fmlUwgb8GA1UdHwSBtzCBtDCB
saCBrqCBq4aBqGxkYXA6Ly8vQ049ZGV2LURDMS1DQSxDTj1kYzEsQ049Q0RQLENO
PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy
YXRpb24sREM9ZGV2LERDPWl0P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz
ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCBtwYIKwYBBQUHAQEE
gaowgacwgaQGCCsGAQUFBzAChoGXbGRhcDovLy9DTj1kZXYtREMxLUNBLENOPUFJ
QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m
aWd1cmF0aW9uLERDPWRldixEQz1pdD9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0
Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA2BgNVHREELzAtoB8GCSsGAQQB
gjcZAaASBBDswipFcEo8QJ4wa+MD1ObxggpkYzEuZGV2Lml0MA0GCSqGSIb3DQEB
BQUAA4IBAQAsfoVcCK8W+IF2S70g96BNolfDj2fUJXDYU+T1cDMEo0nMT/Bmczj1
zI/leMKbHwJJIgZF6XDtZadv+AJtkjA9TBlvgJsLDVoD+Zr3u9tZ2uWbkPkvBEP2
4WD6ioij6w/WJZ4/ZLk654mPN4e59cd2QdaPlFJzXMmF04qBkAio7/OV/eStJA+m
NRj1c/7FvKMssMp8P++AG6bENRFEz8Syu4Bjhma69PR0c+1ElLwc/uZgaROSTvf5
6ZYoKvniP0B+r+tnHjuF1H72eDJV9TjL4/I00M+Qt1nsoms06A/GwrUfk6+gGsge
WN7jgiktT3hZ/xexMOFSWaWUK5/vc6Cp
-END CERTIFICATE-
subject=CN = dc1.dev.it

issuer=DC = it, DC = dev, CN = dev-DC1-CA

---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: 
RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1
Shared Requested Signature Algorithms: 
RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1
Peer signing digest: SHA1
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2020 bytes and written 467 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES128-SHA256
Session-ID: 281C89A8FE3766C77054BA467FB88A4AFE62F9B52D478E6840B5B29F2787
Session-ID-ctx:
Master-Key: 
2A4EBD468A173EA25C9217F586BE7D91206D0D367D75F44118205118DEE042B5B804292F3FEFD020A19EC6034F86B19C
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1709547310
Timeout   : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: yes
---




--
Pozdrawiam serdecznie
Maciej Bogucki


Bug#1065423: vlc-plugin-pipewire uninstallable in unstable after vlc time_t transition

2024-03-04 Thread Sebastian Ramacher
On 2024-03-04 11:06:53 +0100, Christian Klein wrote:
> Package: vlc-plugin-pipewire
> Version: 3-3
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: dvl...@gmail.com
> 
> vlc-plugin-pipewire depends on vlc-plugin-abi-3-0-0f. However, after the 
> time_t
> transition, the libvlccore9 package provides vlc-plugin-abi-3-0-0ft64.
> Due to this, the package can no longer be installed.
> 
> A simple rebuild of the package will likely already fix the problem.
> I wonder why this didn't happen automatically during the transition without 
> any
> manual intervention. Maybe the fact that the package depends on libvlccore9
> twice - once directly and once via vlc-plugin-abi-3-0-0f - causes this.

We are not yet there to schedule the archive wide rebuilds. The time_t
transition will take some time to complete. Please have some patience.

Closing as this bug does not require an action from the maintainer.

Cheers
-- 
Sebastian Ramacher



Bug#1065423: vlc-plugin-pipewire uninstallable in unstable after vlc time_t transition

2024-03-04 Thread Christian Klein
Package: vlc-plugin-pipewire
Version: 3-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: dvl...@gmail.com

vlc-plugin-pipewire depends on vlc-plugin-abi-3-0-0f. However, after the time_t
transition, the libvlccore9 package provides vlc-plugin-abi-3-0-0ft64.
Due to this, the package can no longer be installed.

A simple rebuild of the package will likely already fix the problem.
I wonder why this didn't happen automatically during the transition without any
manual intervention. Maybe the fact that the package depends on libvlccore9
twice - once directly and once via vlc-plugin-abi-3-0-0f - causes this.


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

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

Versions of packages vlc-plugin-pipewire depends on:
ii  libc6 2.38-6
ii  libpipewire-0.3-0t64 [libpipewire-0.3-0]  1.0.3-1.1
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]   3.0.20-1+b2

vlc-plugin-pipewire recommends no packages.

vlc-plugin-pipewire suggests no packages.

-- no debconf information



Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

2024-03-04 Thread Colm Buckley
As per the discussion in
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 - once
vmlinux.h is included with linux-headers, the warning about cmd_btf_ko etc.
should be harmless, as that file should already be available (ie: there's
no need to generate it again as part of kernel build). Am I missing
something else? I confess I have only a very small amount of experience
with BPF code; I played with building a few modules, but I don't use it
regularly.

Colm


Bug#1065343: closed by Bo YU (Re: #1065343: libuuid1t64 overwrite)

2024-03-04 Thread Chris Hofstaedtler
> debootstrap still has issue:
> 
> ```
> ...
> tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists
> tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to 
> ‘libuuid.so.1.3.0’: File exists
> tar: Exiting with failure status due to previous errors
> 
> ```
> 
> Anyone's help in assessing when this issue(t64 transition break debootstrap 
> on sid) will be resolved would be appreciated!

There is nothing we can do now, that is not already on the todo list
of the people working on the transition.

Just be patient. It is, after all, unstable.

I'm told that other chroot-creation tools might not have this
problem (i.e. mmdebstrap).

Chris



Bug#1064617: Passwords should not be changed frequently

2024-03-04 Thread Holger Wansing
Hi,

Am 4. März 2024 06:17:31 MEZ schrieb Philip Hands :
>I found that there were some phrases that I was avoiding for various
>reasons, a couple of which I see you've used, so I'll say why I was avoiding
>them and see if I have a persuasive argument for doing so.
>
>"allow/deny login/access as root":
>
>  The problem here is that not having a password for root only prevents
>  one from getting direct access to root by using a password. Indirect
>  access is still available via sudo, and direct access is still
>  available via key bassed ssh.  I was also avoiding saying things like
>  "disable the root account" for the same reason.
>
>  This is why I ended up with the phrasing:
>
> direct password-based logins to 'root'.

Ok, seems fair. I would change to that then.

>
>"using the 'sudo' command":
>
>  This I was avoiding becuase it might give the impression that one MUST
>  use sudo, whereas most people will actually get their root acces via a
>  GUI prompting them for their own pasword (because it's checked that
>  they're in the sudo group) when doing things like unlocking their
>  network or printer settings. I thought it was worth mentining the
>  'sudo' group explicitly because that gives something to search for if
>  they want to find out more, but telling people they need to use the
>  sudo command seemed like a step too far.

Correct so far. Maybe a bit more technical and therefore probably
not the easiest choice for newbies, but I have no problem using that.

>Regarding the password advice, I ended up concluding that it's pretty
>unlikely that anything we say at this point will have any effect on
>people's behaviour, but then I'm probably just an old cynic. Also, I
>failed when trying to come up with a wording which I was happy with,
>which is why I ended up discarding the advice entirely.
>
>If we want to keep the password advice in then I think what you wrote is
>(mostly) OK, although I think it implies that one should be choosing a
>single "password" (although, not a word in any normal sense), which
>could be argued to steer people away from the perfectly decent xkcd
>approach of using several dictionary words. Saying "Password or
>Passphrase" at least once would probably address that.

Ok, makes it a bit longer, but it could be worth it.

I will prepare a new patch with above.


Holger


-- 
Sent from /e/ OS on Fairphone3



Bug#1065408: isc-kea: [INTL:pt] Portuguese translation - debconf messages

2024-03-04 Thread Paride Legovini
On 2024-03-04 01:30, Américo Monteiro wrote:
> Updated Portuguese translation for isc-kea's debconf messages
> Translator: Américo Monteiro 

Hello Américo and thanks for the translation. Did you have the
translation proofread by anybody from debian-l10n-portuguese?
That's normally done via RFR requests ([1] is a random example),
but we would be happy with any other review process.

Cheers,

Paride

[1] https://lists.debian.org/debian-l10n-portuguese/2023/11/msg00011.html



Bug#1065362: kea-dev: kea-message-compiler is missing from kea-dev package and is needed for building message files

2024-03-04 Thread Paride Legovini
Control: tags -1 + pending

On 2024-03-03 13:14, Quentin Armitage wrote:
>   kea-dev should be updated to include
>   /usr/bin/kea-message-compiler 

Hello Quentin and thanks for this bug report. I have a branch up which enables
building kea-msg-compiler. Salsa CI is currently broken so I didn't open a
MR yet, but it will come soon.

The change will land in the current Debian development release (and so in
the next stable release, Trixie). I am not sure the fix is suitable for
an update to Debian stable, given that it is more of a feature request
than of a bug fix. OTOH, given that the fix consists in adding a component
that was not present before, the the regression potential is very little.
I'll ask what the other Kea maintainers think. In any case first we need
to fix the devel release.

--
Paride



Bug#1039443: python3-paramiko: please package v3.2.0 an remove python3-six dependency

2024-03-04 Thread Santiago Ruano Rincón
On Thu, 8 Feb 2024 23:55:38 -0300 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= 
 wrote:
> Control: retitle: -1 python3-paramiko: please package v3.4.0 an remove 
> python3-six dependency
> Control: block #1059006 by -1
> 
> On Mon, 26 Jun 2023 01:49:36 +0200 Alexandre Detiste 
>  wrote:
> > Package: python3-paramiko
> > Version: 2.12.0-2
> > Severity: normal
> > 
> > Hi,
> > 
> > Please uplaod the new version to complete the Py2->3 conversion.
> > 
> > https://bitprophet.org/blog/2021/02/25/byethon2/
> > 
> > You might also close these two Py2 related bugs at the same time:
> > 
> >   #800386  obnam: UnicodeDecodeError python exception during backup
> >   #947470  paramiko: [Py3] TypeError: a bytes-like object is required,
> >not 'str' in pkey.write_private_key()
> > 
> > Greetings,
> > 
> 
> Dear paramiko maintainers,
> 
> v3.4.0 was released on Dec 18 2023. It especially fixes the Terrapin
> Attack (CVE-2023-48795).
> Do you need/want any help on this? (maybe under the Python Team
> umbrella)

I've started packaging 3.4.0 in the wip/debian/3.4.0 branch.

cheers,

  -- S


signature.asc
Description: PGP signature


Bug#1065422: kamailio: Please use /bin/bash

2024-03-04 Thread Matthias Urlichs
Package: kamailio
Version: 5.6.3-2
Severity: normal
X-Debbugs-Cc: sm...@smurf.noris.de

# /usr/sbin/kamdbctl
-e \E[37;31mERROR: could not load the script in 
/usr/lib/x86_64-linux-gnu/kamailio//kamctl/kamdbctl.sqlite for database engine 
SQLITE
-e \E[37;31mERROR: database engine not loaded - tried 'SQLITE'

This is supposed to be red. Unfortunately /bin/sh links to /bin/dash whose
built-in "echo" doesn't support the "-e" flag, nor threse escape codes.

Please use #!/bin/bash in the Kamailio shell scripts.
Alternately, use /bin/echo instead of the built-in one.


-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (750, 'stable'), (700, 'testing'), (650, 'oldstable'), (600, 
'oldoldstable'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 
'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf

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

Versions of packages kamailio depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u4
ii  libncurses66.4-4
ii  libpcre2-8-0   10.42-1
ii  libpcre3   2:8.39-15
pn  libreadline7   
ii  libreadline8   8.2-1.3
ii  libstdc++6 14-20240201-3
ii  libtinfo6  6.4-4
ii  lsb-base   11.6
pn  python 
ii  python33.11.2-1+b1
ii  sysvinit-utils [lsb-base]  3.06-4

kamailio recommends no packages.

Versions of packages kamailio suggests:
pn  kamailio-berkeley-modules   
pn  kamailio-cpl-modules
pn  kamailio-ldap-modules   
pn  kamailio-lua-modules
pn  kamailio-mono-modules   
pn  kamailio-mysql-modules  
pn  kamailio-perl-modules   
pn  kamailio-postgres-modules   
pn  kamailio-presence-modules   
pn  kamailio-python-modules 
pn  kamailio-python3-modules
pn  kamailio-radius-modules 
pn  kamailio-redis-modules  
pn  kamailio-snmpstats-modules  
pn  kamailio-tls-modules
pn  kamailio-unixodbc-modules   
pn  kamailio-xml-modules
pn  kamailio-xmpp-modules   
pn  stun-server | turn-server   



Bug#1064041: linux-image-6.1.0-18-amd64: Resuming from suspend keyboard unresponsive (but sysrq OK , touchpad OK) on dell latitude 3340

2024-03-04 Thread Jacques

Hi Salvatore

Le 03/03/2024 à 16:25, Salvatore Bonaccorso a écrit :


Ok that is great to hear. So firstmost: Then this iwill be fixed in
the next upload for bookworm, as we do a rebase to at least 6.1.80.

Alternatively if we know which was the fixing commit that would be
helpful as well now, since we know 6.1.80 fixes the issue. Otherwise
we simply close later once the upload has happened.

Regards,
Salvatore



Here are the results of my tests on the various upstream kernels.

The problem appeared with kernel 6.1.74 and has been corrected in kernel 
6.1.78.



If possible, can we leave the bug report open until the next version of 
bookworm is released, to allow other users to find the workaround by 
adding the atkbd.reset option to the machine boot:


edit in /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet atkbd.reset"

followed by the command:
sudo update-grub

Best regards

Jacques



Bug#1065421: extrepo-offline-data: Gitlab GPG key is expired

2024-03-04 Thread Maximilian Stein
Package: extrepo-offline-data
Version: 1.0.4
Severity: normal

Dear Maintainer,

The GPG key of the Gitlab repository is expired since March 1st.

The new one can be downloaded at [1].

Best
Maximilian

[1]: https://packages.gitlab.com/gpg.key



Bug#1065420: RFS: ocaml-linenoise/1.5-1 [ITP] -- Lightweight readline alternative with OCaml

2024-03-04 Thread Bo YU
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "ocaml-linenoise":

 * Package name : ocaml-linenoise
   Version  : 1.5-1
   Upstream contact : Edgar Aroutiounian 
 * URL  : https://github.com/ocaml-community/ocaml-linenoise
 * License  : BSD-2-Clause
 * Vcs  : https://salsa.debian.org/vimerbf-guest/ocaml-linenoise
   Section  : ocaml

The source builds the following binary packages:

  liblinenoise-ocaml - Lightweight readline alternative with OCaml (runtime)
  liblinenoise-ocaml-dev - Lightweight readline alternative with OCaml 
(development)

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

  https://mentors.debian.net/package/ocaml-linenoise/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/ocaml-linenoise/ocaml-linenoise_1.5-1.dsc

Changes for the initial release:

 ocaml-linenoise (1.5-1) UNRELEASED; urgency=low
 .
   * Initial release. (Closes: #1064586)

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature


Bug#1065419: ITP: sail-ocaml -- Sail architecture definition language

2024-03-04 Thread Bo YU
Package: wnpp
Severity: wishlist
Owner: Bo YU 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: sail-ocaml
  Version : 0.17.1
  Upstream Contact: rems-project 
* URL : https://github.com/rems-project/sail
* License : BSD-2-Clause
  Programming Lang: OCaml 
  Description : Sail architecture definition language with OCaml

Sail is a language for describing the instruction-set architecture (ISA) 
semantics of processors. Sail aims to provide a engineer-friendly, 
vendor-pseudocode-like language for describing instruction semantics. It is 
essentially a first-order imperative language, but with lightweight dependent 
typing for numeric types and bitvector lengths, which are automatically checked 
using Z3.

Given a Sail definition, the tool will type-check it and generate 
documentation, executable emulators (in C and OCaml), theorem-prover 
definitions (for Isabelle, HOL4, and Coq), and definitions to integrate with 
our RMEM and isla-axiomatic tools for concurrency semantics. The Isla engine 
provides SMT-based symbolic evaluation for Sail models, and the Islaris 
verification tool integrates Isla output with the Iris program logic to support 
proof about binary code in Coq. Not all models are integrated with all tools - 
see the most recent papers and models for descriptions of the current state.

>>>--
This is a denpendency of sail-riscv[0] and I will maintain it under
Debian OCaml team.

[0]: https://github.com/riscv/sail-riscv
-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature


Bug#1064955: signature is fixed now

2024-03-04 Thread Matthias Förste
Hello

and just for the record: the clamav signature file was apparently
updated (the previous version had a trailing newline) but not the gpg
signature. I contacted sanesecurity about it and they fixed the gpg
signature.

Cheers
-- 
  Matthias Förste

  gnupg encrypted messages are welcome - key ID: 0F51DA21
  gnupg fingerprint: 590C 5DF1 C3B8 D072 555B  54F5 9363 2C80 0F51 DA21

  internet & unix support
  Heiko Schlittermann
  Tannenstraße 2 - 01099 Dresden
  Web: http://www.schlittermann.de/
  Tel.: +49 351 8029981
  Fax:  +49 351 8029983


signature.asc
Description: PGP signature


Bug#1065418: dglob man page: typo "de" → "the"

2024-03-04 Thread Jakub Wilk

Package: debian-goodies
Version: 0.88.1
Severity: minor
Tags: patch

--
Jakub Wilk
diff --git a/dglob.pod b/dglob.pod
index 6a483b3..e304b21 100644
--- a/dglob.pod
+++ b/dglob.pod
@@ -24,3 +24,3 @@ this behavior (see L<"OPTIONS">).
 If you use dglob with the B<-f> option, all files in the matched packages
-are listed instead of their names. If you do not use de B<-a> switch,
+are listed instead of their names. If you do not use the B<-a> switch,
 only existing, plain (i.e. no symlinks, directories or other special ones)


Bug#1065417: ITP: omd -- omd-ocaml

2024-03-04 Thread Bo YU
Package: wnpp
Severity: wishlist
Owner: Bo YU 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: omd
  Version : 2.0.0 
  Upstream Contact: a...@recoil.org 
* URL : https://github.com/ocaml/omd
* License : ISC
  Programming Lang: OCaml
  Description : extensible Markdown library and tool in "pure OCaml"

Omd is an OCaml library designed to parse, manipulate, and print Markdown into 
different formats. In addition to the library, a command-line tool omd is 
included to easily convert markdown into HTML.

Omd aims for compliance with the CommonMark standard. We are currently 
compliant with 0.30 of the ComonMark spec.

--->>

This is a denpendency of sail[0].

[0]: https://github.com/rems-project/sail

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature


<    1   2