date:20230721

Hi xibowen,

在 2023-07-21星期五的 20:26 +0800，xibowen写道：
> Hi, thanks for reply.
> I'm xibowen. This is my other email address.Please reply this email if you
> have some problem.
> I have fixed issues in the latest package which have uploaded in mentors.
> URL:https://mentors.debian.net/package/ukui-app-widget/
> Please reply to me if you have any more questions about this package.

I did not see any fix on this issue. You are claiming that QtSingleApplication
to be copyrighted by Kylin Company, which is wrong and very unacceptable
because the original author's information as shown at
https://github.com/qtproject/qt-solutions/tree/master/qtsingleapplication/src
was wrongfully stripped
in 
https://gitee.com/openkylin/ukui-app-widget/commit/ed94e7233e3ca37256b5cee166f82a6feba5179c
. This is a red flag of being unprofessional when working in OSS community.
Can you work with upstream to correct this issue?

The git commit author of ed94e723 is CC-ed as well.

Besides, I don't understand upstream commit 2e15e13. Can you explain why you
revert version 4.x to 1.0.1?

> In addition, We have another package which need you assist with. This
> package is more important for us that many packages is depend on it.
> package name: libkysdk-applications
> URL:https://mentors.debian.net/package/libkysdk-applications/ 
> I hope you can process this package when you have any time.

Let's handle ukui-app-widget first.

Thanks,
Boyuan Yang


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

Bug#1034668: Please update to new upstream release 3.22.3 in experimental

2023-07-21 Thread Nilesh Patra

Hi,

On Thu, 27 Apr 2023 19:59:38 +0530 Pirate Praveen  
wrote:
> With a newer libabsl-dev from 
> https://people.debian.org/~praveen/new/pool/main/a/abseil/, the error 
> changed to
> 
> CMake Error at cmake/tests.cmake:97 (target_link_libraries):
>  Target "tests" links to:
> 
>absl::scoped_mock_log
> 
>  but the target was not found. Possible reasons include:

Tl;dr: I targeted the version "3.23.4" of protobuf and could get it
building taking[0] changes as reference. Patch attached.

This seems to be an issue with abseil itself which is currently
unfixed[1]. The workaround suggested is to add in
"ABSL_BUILD_TESTING=ON" and "BUILD_TESTING=ON" options to cmake flags.

Now, the release of abseil in experimental seems to be doing that, but
only for the static library and not the shared library, because it needs
googltest for the same, and googletest does not vendor any shared
library because the SO lib is not maintained properly upstream[2] and
hence trying to enable the above options for abseil for shared object
compilation chokes with a dh_shlibdeps error shouting that it also
needs a so lib for gtest. The maintainer of abseil has implemented the
same for shared lib in this commit[3] and has explained with a solid reasoning, 
and you
were involved (as a reporter) in a bug too, regarding the same.

The reason why you get the above issue (as far as i understand) is
because protobuf tries to link with abseil in a shared lib form, and
I found it non-trivial to change that to fit all usecases.
Since this was a test-only thing, the best way for now is to disable
the tests for now until this is fixed properly in abseil.

This was straightforward was to add "-Dprotobuf_BUILD_TESTS=OFF" to
configure options.

Now, I had to do multiple changes to get it working. I'm mentioning them
incase that helps you/someone else who looks at it:

* Refreshed the existing patches
* Added in -Dprotobuf_BUILD_TESTS=OFF -DBUILD_SHARED_LIBS=ON to get
  shared lib building as well.
* There's no need of any `-D` in front of dh_auto_build since this
  translates into a `make` command (which fails with -D), removed that.
* Saw some bazel stuff failing, had to add a B-D on bazel-bootstrap and
  also set HOME to /tmp for the descriptior_proto bash script so it
  builds fine in sbuild.
* The build proceeded forward but choked at python build. Turns out due
  to buildsystem change, binaries are no longer available at src/ but in
  obj-* dir. Added a patch to setup.py to link against that dir.
* Now the build moved but choked at ruby's build. Turns out it isn't
  sensible to add entire ruby/ext/google/protobuf_c to d/clean. Adding 4 files
  is enough.
* Now the java part of the build failed. Here, d/p/no_javax.patch has to
  be updated to remove more instances of javax and @Nullable annotation.
* In addition to this change, the java build xml expected protoc binary
  to be in src/ but it changed to obj-$(DEB_HOST_MULTIARCH) so had to
  copy it to src/ before build and removed it after build was done (sort
  of a hack).
* Now the python testsuite choked, has to change LD_LIBRARY_PATH to new
  location. Also needed a B-D on numpy. Had to exclude a generator_test
  here which looked syntactically incorrect to me.
* After this, the install step failed, because no static libs are being
  built. I've removed them from install files for now, because fixing
  them would mean a lot of work in either d/rules or patching cmake.
* Installed some .cmake files for libprotobuf. There is also a compiled
  lib for third_party/utf8_range but I suppose we don't need it. So
  overrided dh_missing to ignore that.

After doing all of this, protobuf finally built. All in all, I had to
look at multiple languages and buildsystems to get this working.

**NB1:** The static libs are not present in the protobuf lib at the moment
because this changed after the build system changed, and needs some work to get 
both shared
and static libs enabled and it's 5 in the morning and
I'm too tired and sleepy to work on it. For gitlab's usecase, static libs are 
*probably*
not needed.

**NB2:** bazel buildsystem probably downloads some stuff off the
internet for this package (I did not check in depth) so the debian way
of doing it would be to either package the stuff it needs or download
copies beforehand and use that in build.

PS: Sponsor me a party/dinner when?

[0]: https://people.debian.org/~praveen/new/pool/main/p/protobuf/
[1]: https://github.com/abseil/abseil-cpp/issues/1407
[2]: https://github.com/google/googletest/issues/2184
[3]: 
https://salsa.debian.org/debian/abseil/-/commit/136c2572f4d6e6ab8ae02f74d691634874458184
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034908#48

Best,
Nilesh
commit d3abfec3189ca5188fafe09f3003138027774422
Author: Nilesh Patra 
Date:   Sat Jul 22 00:15:06 2023 +0530

New version update

diff --git a/debian/changelog b/debian/changelog
index 338446c..03edb4e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9

Bug#1037707: keyman: ftbfs with GCC-13

Hi Eberhard,

Are you going to work on this issue?

Thanks,
Boyuan Yang


On Wed, 14 Jun 2023 09:26:08 + Matthias Klose  wrote:
> Package: src:keyman
> Version: 16.0.139-4
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
> 
> [This bug is targeted to the upcoming trixie release]
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
> severity of this report will be raised before the trixie release.
> 
> The full build log can be found at:
>
http://qa-logs.debian.net/2023/05/22/logs/keyman_16.0.139-4_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 13, either set CC=gcc-13 CXX=g++-13 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-13/porting_to.html
> 
> [...]
> ../../../src/kmx/kmx_processevent.h:58:27: error: ‘PKMX_BYTE’ has not been
declared
>    58 |   KMX_BOOL VerifyKeyboard(PKMX_BYTE filebase, size_t sz);
>   |   ^
> ../../../src/kmx/kmx_processevent.h:59:27: error: ‘PKMX_BYTE’ has not been
declared
>    59 |   KMX_BOOL VerifyChecksum(PKMX_BYTE buf,  size_t sz);
>   |   ^
> ../../../src/kmx/kmx_processevent.h:60:27: error: ‘PKMX_BYTE’ has not been
declared
>    60 |   PKMX_WCHAR StringOffset(PKMX_BYTE base, KMX_DWORD offset);
>   |   ^
> ../../../src/kmx/kmx_processevent.h:60:43: error: ‘KMX_DWORD’ has not been
declared
>    60 |   PKMX_WCHAR StringOffset(PKMX_BYTE base, KMX_DWORD offset);
>   |   ^
> ../../../src/kmx/kmx_processevent.h:62:27: error: ‘PKMX_BYTE’ has not been
declared
>    62 |   LPKEYBOARD CopyKeyboard(PKMX_BYTE bufp, PKMX_BYTE base);
>   |   ^
> ../../../src/kmx/kmx_processevent.h:62:43: error: ‘PKMX_BYTE’ has not been
declared
>    62 |   LPKEYBOARD CopyKeyboard(PKMX_BYTE bufp, PKMX_BYTE base);
>   |   ^
> ../../../src/kmx/kmx_processevent.h:85:45: error: ‘KMX_DWORD’ has not been
declared
>    85 |   PKMX_WCHAR  GetSystemStore(LPKEYBOARD kb, KMX_DWORD SystemID);
>   | ^
> ../../../src/kmx/kmx_processevent.h:89:25: error: ‘KMX_DWORD’ has not been
declared
>    89 |   KMX_BOOL IsCapsLockOn(KMX_DWORD modifiers);
>   | ^
> ../../../src/kmx/kmx_processevent.h:90:20: error: ‘KMX_DWORD’ has not been
declared
>    90 |   void SetCapsLock(KMX_DWORD , KMX_BOOL capsLockOn,
KMX_BOOL force = FALSE);



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

Bug#1041588: bug#64773: grep 3.11 -r on 100000+ files fails with "Operation not supported"

2023-07-21 Thread Paul Eggert

To fix just this bug (as opposed to the other Gnulib-related bugs that 
may be lurking) try applying the attached Gnulib patch to a grep 3.11 
tarball.

Closing the debbugs.gnu.org bug report, as the bug has been fixed upstream.From d4d8abb39eb02c555f062b1f83ffcfac999c582f Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Fri, 5 May 2023 12:02:49 +0200
Subject: [PATCH] dirfd: Fix bogus override (regression 2023-04-26).

Reported by Bjarni Ingi Gislason  in
.

* m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change.
---
 ChangeLog   | 7 +++
 m4/dirfd.m4 | 6 +-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index aaffe12fc1..5f01a52535 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-05-05  Bruno Haible  
+
+	dirfd: Fix bogus override (regression 2023-04-26).
+	Reported by Bjarni Ingi Gislason  in
+	.
+	* m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change.
+
 2023-05-04  Bruno Haible  

 	c32swidth: Add tests.
diff --git a/m4/dirfd.m4 b/m4/dirfd.m4
index d1ee2c7f61..7968b1287c 100644
--- a/m4/dirfd.m4
+++ b/m4/dirfd.m4
@@ -1,4 +1,4 @@
-# serial 27   -*- Autoconf -*-
+# serial 28   -*- Autoconf -*-

 dnl Find out how to get the file descriptor associated with an open DIR*.

@@ -40,10 +40,6 @@ AC_DEFUN([gl_FUNC_DIRFD],
 HAVE_DIRFD=0
   else
 HAVE_DIRFD=1
-dnl Replace only if the system declares dirfd already.
-if test $ac_cv_have_decl_dirfd = yes; then
-  REPLACE_DIRFD=1
-fi
 dnl Replace dirfd() on native Windows, to support fdopendir().
 AC_REQUIRE([gl_DIRENT_DIR])
 if test $DIR_HAS_FD_MEMBER = 0; then
-- 
2.39.2

Bug#1041677: RM: cadabra -- RoQA; RC-buggy; depends on gtk2; low popcon


Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:cadabra

Please remove cadabra. It is RC-buggy which will not be resolved, 
depends on gtk2, and has a low popcon. The new upstream version is 
available as cadabra2.

Bug#1041676: sensible-utils: remove meaningless ;

2023-07-21 Thread srp9zv+1gdqujzkl06dk

Package: sensible-utils
Severity: normal
Control: tags -1 patch

Dear Maintainer,

The file sensible-browser.in in salsa contains a meaningless ; after the last 
command:
exit 1;

In sh, a ; at the end doesn't do anything.

I attach a patch to fix that. I claim no copyright on this, do whatever you 
want with it.

---
 sensible-browser.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sensible-browser.in b/sensible-browser.in
index 0c5cb56..20fc6a6 100644
--- a/sensible-browser.in
+++ b/sensible-browser.in
@@ -41,4 +41,4 @@ fi
 
 echo "Couldn't find a suitable web browser!" >&2
 echo "Set the BROWSER environment variable to your desired browser." >&2
-exit 1;
+exit 1
--

Bug#1041675: lintian: missing-dep-for-interpreter does not recognize lua5.4 as lua

2023-07-21 Thread Phil Hagelberg

Package: lintian
Version: 2.116.3
Severity: normal
X-Debbugs-Cc: p...@hagelb.org

Hello!

I have a package which declares a dependency on "lua5.4 | lua" and is
compatible with every version of Lua which is included in Debian. When
I build my package, lintian complains:

E: fennel: missing-dep-for-interpreter lua (does not satisfy lua:any | 
lua40:any | lua50:any | lua5.1:any | lua5.2:any) [usr/bin/fennel]

It appears to treat earlier versions of Lua as satisfying this
dependency, but not 5.3 and 5.4. Changing the dependency to "lua5.2 |
lua" makes the error go away, but I would prefer not to do this as 5.2
is missing a lot of nice-to-have features.

The repository https://salsa.debian.org/technomancy-guest/fennel branch 
"debian/131-prep" can be used to demonstrate this problem.

In addition, lintian should probably not be recommending lua40 (removed in
2011) or lua50 (removed in 2021).

thanks,
Phil

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

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

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.22
ii  dpkg-dev1.21.22
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.22
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.003+ds-1
ii  libsereal-encoder-perl  5.003+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.16-1
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzop1.04-2
ii  man-db  2.11.2-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-5
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.1-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1030394: reassign bug to correct package

2023-07-21 Thread Nicholas D Steeves

reassign 1030394 dh-elpa
retitle 1030394 dh-elpa: elpa-csv-mode 1.20 not cleaned up
tags 1030394 - moreinfo - unreproducible
thanks

These bugs are the same type as #1040787.  Thus far, the only trigger
that we've been able to identify is a dist-upgrade (or full-upgrade)
from bullseye to bookworm.  I ran these in a 'su -' environment on real
machines.  It may be that the actual trigger condition is
buster2bullseye2bookworm.  #1040690, which is currently filed against
emacs-el (with an "affects dh-elpa") appears to have the most activity
as well as user-confirmed reproducibility.

Note that this is a disruptive bug to users, who are having to resort to
heavy-handed methods.

To all affected users: Do you remember if you ever manually installed an
affected elpa-package from sid/unstable or from testing?  I'm curious if
this might be part of the trigger condition.  Likewise, do you remember
if you installed dh-elpa from backports?  While I think both of these
cases are unlikely to have caused problems, one might as well be
thorough!

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1041674: fakeroot: compiling fakeroot looks to have a race condition not generating wrapped.h

2023-07-21 Thread Rudi Heitbaum

Package: fakeroot
Version: 1.32.1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: r...@heitbaum.com

Dear Maintainer,

* What led up to the situation?

build of 1.32.1 on local build host was fine. on the CI build host it
fails.

https://github.com/LibreELEC/actions/actions/runs/5623416630/job/1523806

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

as per the actions run - you can see that it is inconsistent.

the build log is as below:

<<< fakeroot:host seq 43 <<<
UNPACK fakeroot
APPLY PATCH (common)
packages/devel/fakeroot/patches/fakeroot-001-disable-docs-tests.patch
patching file configure.ac
Hunk #1 succeeded at 744 (offset 147 lines).
patching file Makefile.am
Hunk #1 succeeded at 1 with fuzz 2.
FIXCONFIG
/build/build.LibreELEC-H3.arm-12.0-devel/build/fakeroot-1.32.1/
BUILD fakeroot (host)
TOOLCHAIN configure
autoreconf: export WARNINGS=
[039/278] [FAIL] build fakeroot:host
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I build-aux
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'build-aux'.
libtoolize: copying file 'build-aux/libtool.m4'
libtoolize: copying file 'build-aux/ltoptions.m4'
libtoolize: copying file 'build-aux/ltsugar.m4'
libtoolize: copying file 'build-aux/ltversion.m4'
libtoolize: copying file 'build-aux/lt~obsolete.m4'
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: aclocal --force -I build-aux
autoreconf: running:
/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/bin/autoconf --force
configure.ac:428: warning: AC_CHECK_FUNCS($WRAPPED): you should use literals
/build/build.LibreELEC-H3.arm-12.0-devel/build/autoconf-2.71/lib/autoconf/functions.m4:117:
AC_CHECK_FUNCS is expanded from...
configure.ac:428: the top level
configure.ac:497: warning: AC_CHECK_FUNCS($WRAPPED): you should use literals

The following log for this failure is available:
/build/build.LibreELEC-H3.arm-12.0-devel/.threads/logs/43.log

/build/build.LibreELEC-H3.arm-12.0-devel/build/autoconf-2.71/lib/autoconf/functions.m4:117:
AC_CHECK_FUNCS is expanded from...
configure.ac:497: the top level
autoreconf: running:
/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:10: installing './compile'
configure.ac:7: installing './missing'
Makefile.am: installing './depcomp'
autoreconf: Leaving directory '.'
Executing (host):
/build/build.LibreELEC-H3.arm-12.0-devel/build/fakeroot-1.32.1/configure
--host=x86_64-linux-gnu --build=x86_64-linux-gnu
--prefix=/build/build.LibreELEC-H3.arm-12.0-devel/toolchain
--bindir=/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/bin
--sbindir=/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/sbin
--sysconfdir=/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/etc
--libexecdir=/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/lib
--localstatedir=/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/var
--disable-static --enable-shared --with-gnu-ld
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports the include directive... yes (GNU style)
checking for x86_64-linux-gnu-gcc...
/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/bin/host-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether
/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/bin/host-gcc accepts -g...
yes
checking for /build/build.LibreELEC-H3.arm-12.0-devel/toolchain/bin/host-gcc
option to enable C11 features... none needed
checking whether
/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/bin/host-gcc understands -c
and -o together... yes
checking dependency style of
/build/build.LibreELEC-H3.arm-12.0-devel/toolchain/bin/host-gcc... gcc3
checking how to run the C preprocessor... cpp
checking whether make sets $(MAKE)... (cached) yes
checking how to print strings... printf
checking for a sed that does not

Bug#1041346: RM: https-everywhere -- ROM; obsolete;major browsers offer native support;

2023-07-21 Thread Markus Koschany

debian-parl and boxer-data have been updated in unstable thus nothing in Debian
references https-everywhere anymore. It should be ready to be removed now.


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

Bug#1041653: meson: Drop gtk-sharp2* build deps

2023-07-21 Thread Jussi Pakkanen

On Fri, 21 Jul 2023 at 20:42, Bastian Germann  wrote:

> Please drop gtk-sharp2 and gtk-sharp2-gapi from Build-Depends.
> The package builds without them and this will help getting rid of gtk-sharp2 
> and eventually gtk2.

This will be fixed in the next point release upload at the latest.

Bug#1041524: logcheck: badly handles "rsyslog + journalctl" checking

2023-07-21 Thread Richard Lewis

On Fri, 21 Jul 2023 at 09:57, Thomas Parmelan  wrote:
>
> Le jeudi 20 juillet 2023 à 21:43, d'après
> Richard Lewis  :

> With the default configuration and without my patch I get this in the
> report, which is really not easy to read because of the huge difference
> in timestamp formatting (and also, there's no way this can be sorted
> correctly):
>
> 2023-07-20T21:10:16.791208+02:00 silk fetchmail[2839]: mailbox selection 
> failed
> Jul 20 21:10:16 silk fetchmail[2839]: mailbox selection failed
>
> With my patch to use "journalctl -o short-iso-precise", I get this
> (a little better):
>
> 2023-07-20T21:10:16.790956+0200 silk fetchmail[2839]: mailbox selection failed
> 2023-07-20T21:10:16.791208+02:00 silk fetchmail[2839]: mailbox selection 
> failed
>
> And when adding the missing ':' I get this:
>
> 2023-07-20T21:10:16.790956+02:00 silk fetchmail[2839]: mailbox selection 
> failed
> 2023-07-20T21:10:16.791208+02:00 silk fetchmail[2839]: mailbox selection 
> failed
>
> I initially thought that it would also enable me, by using SORTUNIQ=1,
> to only have one report instead of a double report for each event (one
> from rsyslog and one from journalctl), but in fact I now think that is
> not possible because as you can see above, both rsyslog and journal
> appear to use their own timestamp values which are slightly different,
> so even with the same formatting they are different and cannot be
> treated by "sort -u".

Thank-you, i understand now.

I suppose the timestamp difference is because the journal 'gets' the
message, and then forwards it to rsyslog which then creates its own
timestamp,
so even if systemd and rsyslog would agree a common format, this will
always be an issue.

Personally, i would just tell rsyslog to use the less precise format,
(or stop using rsyslog entirely).

Instead of changing journal lines to add the colon you could perhaps
try and delete all the decimals after the . , which would (usually?)
make them identical to the journal timestamps.

This might be overkill, but we could make the pre-processing of log
files be more customisable, so the user could choose whatever mangling
of timestamps, whitespace and/or sorting they want.

ie make it so that in logcheck.conf there are variables
PRE_PROCESS_LOG_ENTRIES="sed -e s/[[:space:]]$g/ -e "
POST_PROCESS_LOG_ENTRIES="sort -k1,3 -u"
# and/or set JOURNALCTL_OPTS=(-o iso-whatever)

and then logcheck could use eval,
eval $PRE_PROCESS_LOG_ENTRIES logoutput > logputput.1
eval $POST_PROCESS_LOG_ENTRIES logoutput > logputput.1

then people can do arbitrary mangling of timestamps or whatever. This
would avoid over-complicating the logic in logcheck at the expense of
requiring the user to write the sed/sort lines

> One sample of it that I recall was an error event in a Perl program that
> led it to log several lines of Perl code (in the same log message). Once
> it had passed through logcheck's sort treatment it was obviously
> unusable :)

i also get multiple lines from sbuild (although i just wrote local
rules to match each fragment)

> > >   - handle SORTUNIQ correctly even when using ISO_TIMESTAMPS
> >
> > i didnt understand this bit of the patch (copied below):- it seems to
> > have a lot of repetition, and introduce a call to 'uniq', but only
> > sometimes:
> >
> > (i also wonder why anything is better than just 'sort -u' regardless
> > of timestamp format): can you explain what the issue is that is being
> > solved?
>
> I think i tried at the time (this was a few months ago) to use
> SORTUNIQ=1 (it it set to 0 by default), I don't recall exactly, but you
> are right, this is not correct. The logic was initially to use 'sort -u'
> or only 'sort' and I wrongly transformed it to 'sort -u' or 'sort |
> uniq' which I agree is total nonsense. Sorry about that.
>
> The sort key selection probably still needs to be adjusted though. When
> using ISO_TIMESTAMPS, the whole timestamp is in the first field so '-k
> 1' should be used. If not using ISO_TIMESTAMPS, the original behaviour
> of "-k 1,3" is used (I don't understand it though: that would be the
> month and then the hh:mm::ss parts?).

It's sorting on fields one to three which are the 'Mmm DD HH:MM:SS'
bit in the old-style timestamp:
so (except for around midnight!) this sorts in date order, but not
change the order of messages.

(i dont know  -u is not included!)

Bug#1041673: ITP: r-cran-renv -- GNU R project environments

2023-07-21 Thread Andreas Tille

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-renv -- GNU R project environments
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-renv
  Version : 1.0.0
  Upstream Author : Kevin Ushey,
* URL : https://cran.r-project.org/package=renv
* License : MIT
  Programming Lang: GNU R
  Description : GNU R project environments
 A dependency management toolkit for R. Using 'renv', you can create
 and manage project-local R libraries, save the state of these libraries to
 a 'lockfile', and later restore your library as required. Together, these
 tools can help make your projects more isolated, portable, and reproducible.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-renv

Bug#1041672: RFS: hintview/1.3.1-1 [ITP] -- Program to view HINT files

2023-07-21 Thread Hilmar Preusse

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : hintview
   Version  : 1.3.1-1
   Upstream contact : Martin Ruckert 
 * URL  : https://hint.userweb.mwn.de/hint/hintview.html
 * License  : MIT/X
 * Vcs  : https://github.com/debian-tex/hintview
   Section  : text

The source builds the following binary packages:

  hintview - Program to view HINT files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hintview/hintview_1.3.1-1.dsc

Changes for the initial release:

 hintview (1.3.1-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1041668)

Regards,
-- 
  Hilmar Preusse

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1041588: grep -r fails with "Operation not supported"

Control: tags -1 + pending

El 21/07/23 a las 19:46, Vincent Lefevre escribió:
> Control: tags -1 patch
> 
> On 2023-07-21 19:38:08 +0200, Vincent Lefevre wrote:
> > Indeed, it's a bundled gnulib. I was surprised because there is
> > no "gnulib" directory. Actually these are just files under the m4
> > directory. The bug is in "m4/dirfd.m4". I can see
> > 
> >   if test $ac_cv_func_dirfd = no && test $gl_cv_func_dirfd_macro = no; then
> > HAVE_DIRFD=0
> >   else
> > HAVE_DIRFD=1
> > dnl Replace only if the system declares dirfd already.
> > if test $ac_cv_have_decl_dirfd = yes; then
> >   REPLACE_DIRFD=1
> > fi
> > 
> > where the last 4 lines
> > 
> > dnl Replace only if the system declares dirfd already.
> > if test $ac_cv_have_decl_dirfd = yes; then
> >   REPLACE_DIRFD=1
> > fi
> > 
> > need to be removed to match the upstream gnulib fix.
> 
> And I could check that the corresponding attached patch makes
> the error disappear.

Thank you! Patch and autopkgetst inclucded. As long as I can confirm the
autopkgtest works, I upload the fixed version.

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1041671: charliecloud: [INTL:sv] Swedish strings for charliecloud debconf

2023-07-21 Thread Peter Kvillegård

Package: charliecloud
Version: 0.31-1
Severity: wishlist
Tags: patch l10n
X-Debbugs-Cc: q...@sdfeu.org

Dear Maintainer,

please copy the attachment into debian/po/sv.po
# Translation of charliecloud_0.31-1 debconf template to Swedish.
# Copyright (C) 2014–2022 Triad National Security, LLC and others
# This file is distributed under the same license as the charliecloud package.
# Peter Kvillegård , 2023.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: charliecloud_0.31-1\n"
"Report-Msgid-Bugs-To: charliecl...@packages.debian.org\n"
"POT-Creation-Date: 2020-07-05 14:56+0200\n"
"PO-Revision-Date: 2023-07-17 19:54+0200\n"
"Last-Translator: Peter Kvillegård \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: note
#. Description
#: ../charliecloud-common.templates:1001
msgid "Unprivileged user namespaces are disabled in the running kernel"
msgstr "Oprivilegierade användarnamnrymder är inaktiverade i den körande "
"kärnan"

#. Type: note
#. Description
#: ../charliecloud-common.templates:1001
msgid ""
"To use Charliecloud unprivileged user namespaces need to be enabled. This is "
"done by running the following commands as root:"
msgstr ""
"För att använda Charliecloud behöver oprivilegierade användarnamnrymder "
"vara aktiverade. Detta görs genom att utföra följande kommandon som root:"

#. Type: note
#. Description
#: ../charliecloud-common.templates:1001
msgid ""
"echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/00-local-userns."
"conf"
msgstr ""
"echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/00-local-userns."
"conf"

#. Type: note
#. Description
#: ../charliecloud-common.templates:1001
msgid "systemctl restart procps"
msgstr "systemctl restart procps"

Bug#1041670: sensible-pager.1: some remarks and editorial fixes for the manual

2023-07-21 Thread Bjarni Ingi Gislason

Package: sensible-utils
Version: 0.0.20
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the man page.

The patch is in the attachment.

-..-.

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"echo .kern 0 | groff -man -Z - " instead of "nroff -man"

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual, the following
must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint sensible-pager.1":

mandoc: sensible-pager.1:7:2: WARNING: skipping paragraph macro: br at the end 
of SH
mandoc: sensible-pager.1:17:84: STYLE: input text line longer than 80 bytes: 
Documentation of beh...

-.-.

Use the correct macro for the font change of a single argument or
split the argument into two.

9:.BR sensible-pager

-.-.

"[" and "]", showing optional arguments to options, should be typeset in roman.

6:.BR sensible-pager " [OPTIONS...]"

-.-.

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

Kernel: Linux 6.3.7-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information
--- sensible-pager.12023-07-21 20:35:00.0 +
+++ sensible-pager.1.new2023-07-21 20:39:23.0 +
@@ -3,10 +3,10 @@
 .SH NAME
 sensible-pager \- sensible paging
 .SH SYNOPSIS
-.BR sensible-pager " [OPTIONS...]"
-.br
+.B sensible-pager
+.RI [ OPTIONS... ]
 .SH DESCRIPTION
-.BR sensible-pager
+.B sensible-pager
 makes sensible decisions on which pager to call.
 Programs in Debian can use this script
 as their default pager, or emulate their behavior.
@@ -14,6 +14,6 @@ as their default pager, or emulate their
 Documentation of the PAGER variable in
 .BR environ (7)
 .SH "STANDARD"
-Documentation of behavior of sensible-utils under a debian system is available 
under
-section 11.4 of debian-policy usually installed under
+Documentation of behavior of sensible-utils under a debian system is
+available under section 11.4 of debian-policy usually installed under
 /usr/share/doc/debian-policy (you might need to install debian-policy)

Bug#1041669: sensible-editor.1: some remarks and editorial fixes for the manual

2023-07-21 Thread Bjarni Ingi Gislason

Package: sensible-utils
Version: 0.0.20
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes in a patch for the man pages.

The patch is in the attachment.

-.-.

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"echo .kern 0 | groff -man -Z -" instead of "nroff -man"

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.


Change two HYPHEN-MINUSES (code 0x055, 2D) to an em-dash (\(em),
if one is intended.  An en-dash is usually surrounded by a space,
while an em-dash is used without spaces.
"man" (1 byte characters) transforms an en-dash (\(en ) to one
HYPHEN-MINUS,
and an em-dash to two HYPHEN-MINUSES without considering the space
around it.
If "--" are two single "-" (end of options) then use "\-\-".

sensible-editor.1:31:- see environ(7)
sensible-editor.1:34:- see environ(7)
sensible-editor.1:39:- see select-editor(1)
sensible-editor.1:42:- see editor(1), update-alternatives(1)

-.-.

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

21:.I --verbose

-.-.

Use the correct macro for the font change of a single argument or
split the argument into two.

11:.BR sensible-editor

-.-.

Use \(en for a dash (en-dash) between space characters, not a minus
(\-) or a hyphen (-), except in the NAME section.

sensible-editor.1:31:- see environ(7)
sensible-editor.1:34:- see environ(7)
sensible-editor.1:39:- see select-editor(1)
sensible-editor.1:42:- see editor(1), update-alternatives(1)

-.-.

The name of a man page is set in bold type and the section in roman (see
man-pages(7)).

42:- see editor(1), update-alternatives(1)
60:sensible-browser(1), sensible-pager(1), select-editor(1), environ(7),
61:editor(1), update-alternatives(1)

-.-.

Name of a manual is set in bold, the section in roman.
See man-pages(7).

31:- see environ(7)
34:- see environ(7)
39:- see select-editor(1)
42:- see editor(1), update-alternatives(1)
61:editor(1), update-alternatives(1)

-.-.

"[" and "]", showing optional arguments to options,
should be typeset in roman.

6:.BR sensible-editor " [OPTIONS...]"

-.-.

Inhibit hyphenation for "EDITOR=sensitive-editor" and
"update-alternatives".


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

Kernel: Linux 6.3.7-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information
--- sensible-editor.1   2023-07-21 11:51:13.0 +
+++ sensible-editor.1.new   2023-07-21 12:11:36.0 +
@@ -3,12 +3,13 @@
 .SH NAME
 sensible-editor \- launch sensibly chosen text editor
 .SH SYNOPSIS
-.BR sensible-editor " [OPTIONS...]"
+.B sensible-editor
+.RI [ OPTIONS... ]
 .SH DESCRIPTION
 .BR sensible-editor " makes sensible decisions on which editor to call.
 Programs in Debian can invoke this script to get a good default editor.
 .PP
-.BR sensible-editor
+.B sensible-editor
 looks for an appropriate choice of editor in a series
 of places, and uses the first candidate that works.
 It starts by checking environment variables,
@@ -18,7 +19,7 @@ with a series of hard-coded command name
 .PP
 Variables will be skipped if unset or null, but may include extra
 whitespace-separated parameters such as a
-.I --verbose
+.B \-\-verbose
 flag.
 Once sensible-editor has a candidate commandline, it will try to run
 it (passing on the arguments it was given as the files to be edited).
@@ -28,18 +29,22 @@ or was not found (exit code 127), it tri
 The specific candidates sensible-editor tries, in order, are:
 .IP \(bu 2
 .B $VISUAL
-- see environ(7)
+\(en see
+.BR environ (7)
 .IP \(bu 2
 .B $EDITOR
-- see environ(7)
+\(en see
+.BR environ (7)
 .IP \(bu 2
 .B $SENSIBLE_EDITOR
 .IP \(bu 2
 .B $SELECTED_EDITOR
-- see select-editor(1)
+\(en see
+.BR select-editor (1)
 .IP \(bu 2
 .B editor
-- see editor(1), update-alternatives(1)
+\(en see
+.BR editor "(1), " update-alternatives (1)
 .IP \(bu 2
 .B nano
 .IP \(bu 2
@@ -54,11 +59,15 @@ defaults.
 .SH BUGS
 This command takes precautions against launching itself in an infinite loop
 if a user sets
-.B EDITOR=sensible-editor
+.B \%EDITOR=sensible-editor
 but indirect loops are still possible.
 .SH "SEE ALSO"
-sensible-browser(1), sensible-pager(1), select-editor(1), environ(7),
-editor(1), update-alternatives(1)
+.BR sensible-browser (1),
+.BR sensible-pager (1),
+.BR select-editor (1),
+.BR environ (7),
+.BR editor (1),
+.BR \%update-alternatives (1)
 .SH "CONFORMS TO"
 The behavior

Bug#1041668: ITP: hintview -- Program to view HINT files

2023-07-21 Thread Hilmar Preusse

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

* Package name: hintview
  Version : 1.3.1
  Upstream Contact: Martin Ruckert 
* URL : https://hint.userweb.mwn.de/
* License : MIT/X
  Programming Lang: C
  Description : Program to view HINT files

 The HINT file format is an alternative to the DVI or PDF format
 that was designed specifically for on screen reading of documents.
 Especially on mobile devices, reading DVI or PDF documents can be
 cumbersome.
 .
 Mobile devices are available in a large variety of sizes but are
 typically not large enough to display documents formated for
 letter-size paper. To compensate for the limitations of a small
 screen, users are used to alternate between landscape (few long
 lines) and portrait (more short lines) mode. The HINT format
 supports variable and varying screen sizes leveraging the ability
 of TEX to format a document for (almost) arbitrary values of
 \hsize and \vsize.

Why and how to maintain the package:
 - Currently the hitex program is included in Debian and one
   can create hint files. Hence it is highly useful to have
   a program, to display these kind of files.
 - I'm a member of the Debian TeX Task force and I'll
   maintain in the team. I'm a DM, once I got the upload permits
   I can care of the package myself.

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1041296: ffmpeg: Undocumented build dependency on libunwind-dev

On 2023-07-17 20:46:35 -0400, Ted wrote:
> Hello,
> 
> Kudos for the fast reply. Here is my log. This is a reproduction on a
> different machine.
> 
> I have no potential clues for this cause. I will reply again with a build
> log for a command that uses no funny cflags.

The issue is:

pkg-config --exists --print-errors libplacebo >= 4.192.0
Package libunwind was not found in the pkg-config search path.
Perhaps you should add the directory containing `libunwind.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libunwind', required by 'libplacebo', not found

But, libplacebo (nor any if it's dependencies) requires libunwind. Did
you build any of those yourself?

Cheers
-- 
Sebastian Ramacher

Bug#1041590: nvidia-installer-cleanup install fail

2023-07-21 Thread Andreas Beckmann


On 21/07/2023 06.41, Terrance Hendrik wrote:

Unpacking nvidia-installer-cleanup (20220217+3) ...
Setting up nvidia-installer-cleanup (20220217+3) ...
dpkg: error processing package nvidia-installer-cleanup (--configure):
  installed nvidia-installer-cleanup package post-installation script
subprocess returned error exit status 30


This sounds like debconf couldn't display a question.

Did you customize the debconf priority on this system? Or do you use 
something like DEBIAN_FRONTEND=noninteractive ?


Have you ever had the nvidia driver installed from the .run installer on 
this machine?


Andreas

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

2023-07-21 Thread Brad King

On Fri, Jul 21, 2023 at 2:37 PM Brad King wrote:
> The behavior change came from this CMake merge request:
> * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8538
> because the distutils variant is deprecated.

This is now under discussion in an upstream CMake issue:

* https://gitlab.kitware.com/cmake/cmake/-/issues/25113

Thanks,
-Brad

Bug#990070: irssi: -actcolor parameter for /highlight is not always respected

2023-07-21 Thread Judit Foglszinger

forwarded 990070 https://github.com/irssi/irssi/issues/1479
thanks

Hi,

forwarded this to upstream, let's see :)


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

Bug#1041667: transition: ffmpeg

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: ffm...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:ffmpeg
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ffmpeg.html
Control: block -1 by 1041356 1041375 1041376 1041377 1041378 1041379 1041380 
1041382 1041400 1041401 1041402 1041492 104193 1041504 1041505 1041506 1041507 
1041636 1041637 1041666 1041664 1041665

Tracking bug for the ffmpeg 6.0 transition. I intend to upload ffmpeg
6.0 after the Qt 5 transition is done.

Cheers
-- 
Sebastian Ramacher

Bug#928046: dosbox: input issues under Wayland (some keys not behaving)

2023-07-21 Thread Patrick Frank

Package: dosbox
X-Debbugs-Cc: foss.conn...@kaffeeschluerfer.com
Version: 0.74-3-4+b1
Severity: normal

Hello,

it is true that the config option "usescancodes=false" affects the problem
of keys not functioning as expected, but only by ~50% in combination with
"keyboardlayout=de". You can get only one of both halfs of the special
keys. Very curious for me - either you get the ":" char or the arrow keys
and the "-" char. So it locks me out of several use cases. At least when
you install / configure they keyboard layout "German" and the system
language "English".


-- System Information:

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/12 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 dosbox depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9
ii  libgcc-s112.2.0-14
ii  libgl1   1.6.0-1
ii  libpng16-16  1.6.39-2
ii  libsdl-net1.21.2.8-6+b1
ii  libsdl-sound1.2  1.0.3-9+b2
ii  libsdl1.2debian  1.2.15+dfsg2-8
ii  libstdc++6   12.2.0-14
ii  libx11-6 2:1.8.4-2+deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

Bug#1041647: Stepping back and checking basics

Power-off reboot fixed the issue, so can mark this bug report as invalid 
or similar.


$ vainfo
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 22.3.6 for VERDE (, LLVM 
15.0.6, DRM 2.50, 6.5.0-rc2+debian+tj+)

vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileNone   : VAEntrypointVideoProc

$ journalctl --dmesg --grep 'radeon|gpu'
Jul 21 20:13:53 sunny kernel: [drm] radeon kernel modesetting enabled.
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: vgaarb: deactivate 
vga console
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: No more image in the 
PCI ROM
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: VRAM: 2048M 
0x - 0x7FFF (2048M used)
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: GTT: 2048M 
0x8000 - 0x

Jul 21 20:13:53 sunny kernel: [drm] radeon: 2048M of VRAM memory ready
Jul 21 20:13:53 sunny kernel: [drm] radeon: 2048M of GTT memory ready.
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: 
radeon/verde_pfp.bin
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: 
radeon/verde_me.bin
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: 
radeon/verde_ce.bin
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: 
radeon/verde_rlc.bin
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: 
radeon/verde_mc.bin
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: 
radeon/verde_smc.bin

Jul 21 20:13:53 sunny kernel: [drm] radeon: dpm initialized
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: 
radeon/TAHITI_uvd.bin
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: 
radeon/TAHITI_vce.bin
Jul 21 20:13:53 sunny kernel: [drm] GART: num cpu pages 524288, num gpu 
pages 524288

Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: WB enabled
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 
0 use gpu addr 0x8c00
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 
1 use gpu addr 0x8c04
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 
2 use gpu addr 0x8c08
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 
3 use gpu addr 0x8c0c
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 
4 use gpu addr 0x8c10
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 
5 use gpu addr 0x00075a18
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 
6 use gpu addr 0x8c18
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 
7 use gpu addr 0x8c1c
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: radeon: MSI limited 
to 32-bit

Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: radeon: using MSI.
Jul 21 20:13:53 sunny kernel: [drm] radeon: irq initialized.
Jul 21 20:13:53 sunny kernel: [drm] Radeon Display Connectors
Jul 21 20:13:53 sunny kernel: [drm] Initialized radeon 2.50.0 20080528 
for :0a:00.0 on minor 0

Jul 21 20:13:53 sunny kernel: fbcon: radeondrmfb (fb0) is primary device
Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: [drm] fb0: 
radeondrmfb frame buffer device

Jul 21 20:13:53 sunny kernel: [drm] amdgpu kernel modesetting enabled.
Jul 21 20:13:53 sunny kernel: amdgpu: Ignoring ACPI CRAT on non-APU system
Jul 21 20:13:53 sunny kernel: amdgpu: Virtual CRAT table created for CPU
Jul 21 20:13:53 sunny kernel: amdgpu: Topology: Add CPU node

Bug#1041647: Stepping back and checking basics

After a walk and a think I sensibly stepped back and realised Xorg.0.log 
reports problems and with that clue so does the kernel (but I hadn't 
noticed!). I *suspect* this may be related to having kexec-ed into the 
current kernel. I'm going to try a poweroff restart after this report:


$ grep -E 'DRI|rendering' /var/log/Xorg.0.log
[60.448] (==) RADEON(0): DRI3 disabled
[60.448] (WW) RADEON(0): Direct rendering disabled
[60.510] (II) Initializing extension DRI3
[60.510] (II) AIGLX: Screen 0 is not DRI2 capable
[60.852] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[60.852] (II) Initializing extension XFree86-DRI
[60.852] (II) Initializing extension DRI2


Jul 14 14:52:59 sunny kernel: [drm:r600_ring_test [radeon]] *ERROR* 
radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)
Jul 14 14:52:59 sunny kernel: radeon :0a:00.0: disabling GPU 
acceleration


$ uname -r
6.4.3+debian+tj+

Bug#1041663: RM: monobristol -- RoQA; RC-buggy; depends on gtk2; low popcon


Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:monobristol

Please remove monobristol. It is RC-buggy and was not contained in several releases. It depends on 
gtk2 and has a low popcon.

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

2023-07-21 Thread Brad King

On Fri, Jul 21, 2023 at 11:21 AM Sebastiaan Couwenberg wrote:
> On bookworm distutils is still used which returns:
...
> On sid sysconfig is used which results:

The behavior change came from this CMake merge request:

* https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8538

because the distutils variant is deprecated.

> To get the right path for the Debian python3 interpreter,
> you need to add 'deb_system':

With distutils a generic `plat_specific=True` option was enough
to get each platform's preferred behavior.  Does every client
of Python's sysconfig need to have a big dispatch block that
looks up the host platform and memorizes platform-specific
arguments?  A similar concern was raised here:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998739#22

but never resolved.

As a side note, adding `DEB_PYTHON_INSTALL_LAYOUT=deb`
to the environment resolves this locally.

-Brad

Bug#1041662: RM: tangerine -- RoQA; depends on gtk2; not in bookworm


Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:tangerine

Please remove tangerine. It is dead upstream and depends on gtk2. Nobody cared to make its 
dependencies fit for bookworm, so it was not released.

Bug#1041658: RM: box64 [amd64] -- RoQA; NBS

2023-07-21 Thread Johannes Schauer Marin Rodrigues

Jeremy, you are way ahead of me! :D

Quoting Jeremy Bícha (2023-07-21 19:53:31)
> Package: ftp.debian.org
> X-Debbugs-Cc: bo...@packages.debian.org
> Affects: src:box64
> 
> Please remove box64 from amd64 because it is no longer built there
> because the purpose of the package is to be able to run amd64 binaries
> on other architectures.
> 
> box64 has no reverse dependencies and was only accepted into Unstable this 
> week.

yes, please do exactly as Jeremy suggested.

Thank you!

signature.asc
Description: signature

Bug#1041661: src:python-gnuplotlib: fails to migrate to testing for too long: uploader built binaries


Source: python-gnuplotlib
Version: 0.39-1
Severity: serious
Control: close -1 0.40-1
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:python-gnuplotlib has been trying to 
migrate for 31 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=python-gnuplotlib



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041660: src:sccache: fails to migrate to testing for too long: Build Depends no longer exist


Source: sccache
Version: 0.4.0~~pre8-8
Severity: serious
Control: close -1 0.5.4-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:sccache has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable can't 
migrate because one of its build dependencies no longer exists.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=sccache



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041659: src:vnlog: fails to migrate to testing for too long: uploader built arch:all binaries


Source: vnlog
Version: 1.34-2
Severity: serious
Control: close -1 1.35-1
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:vnlog has been trying to migrate for 31 
days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=vnlog



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041658: RM: box64 [amd64] -- RoQA; NBS

2023-07-21 Thread Jeremy Bícha

Package: ftp.debian.org
X-Debbugs-Cc: bo...@packages.debian.org
Affects: src:box64

Please remove box64 from amd64 because it is no longer built there
because the purpose of the package is to be able to run amd64 binaries
on other architectures.

box64 has no reverse dependencies and was only accepted into Unstable this week.

Thanks,
Jeremy Bicha

Bug#1041657: src:asmjit: fails to migrate to testing for too long: FTBFS on armel, armhf and mips64el


Source: asmjit
Version: 0.0~git20221210.5b5b0b3-1
Severity: serious
Control: close -1 0.0~git20230427.3577608-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:asmjit has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build from source on armel, armhf and mips64el where it built 
successfully in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=asmjit



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041656: ikiwiki: Please add a cli tool to register a user

2023-07-21 Thread eingousef

Package: ikiwiki
Version: stable
Severity: wishlist
X-Debbugs-Cc: eingousef+debb...@rhizogen.es.eu.org

Dear Maintainer,

Currently there are two ways to setup a wiki :

  1. the classic setup ( https://ikiwiki.info/setup/ ) is
 user-friendly but no so great if you want to perform the wiki
 setup in an automated, idempotent way, and doesn't allow to
 install a wiki on an already existing git repository,

  2. the setup by hand ( https://ikiwiki.info/setup/byhand/ ) which is
 easier to turn into an idempotent task and allows to install a
 wiki on an already existing git repo.

The second way, however, is incomplete : the task to add an user (in
particular, the admin of the wiki), which is present in the classic
setup, is absent.

I presume one could register a user automatically with an HTTP
request, but this requires the web server to be set up and the web
frontend of the wiki to actually be accessible before the user is
created.

Would it be possible to have a standalone script to register a user,
similarly to what the classic setup script does ?

The script would take the user name and the user e-mail address as
arguments, possibly the password as well (or prompt for it if you
think it's more secure), and create/modify the .ikiwiki/userdb file
accordingly.

Regards,


-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (980, 'stable-updates'), (980, 'stable'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'oldstable'), (90, 
'experimental'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages ikiwiki depends on:
ii  libhtml-parser-perl 3.81-1
pn  libhtml-scrubber-perl   
pn  libhtml-template-perl   
ii  libjson-perl4.1-1
ii  libmarkdown22.2.7-2
ii  libtext-markdown-discount-perl  0.16-1
ii  liburi-perl 5.17-1
ii  libyaml-libyaml-perl0.86+ds-1
ii  perl5.36.0-7

Versions of packages ikiwiki recommends:
ii  clang-13 [c-compiler]1:13.0.1-11+b2
ii  clang-14 [c-compiler]1:14.0.6-12
ii  darcs2.16.5-1
ii  gcc [c-compiler] 4:12.2.0-3
ii  gcc-10 [c-compiler]  10.4.0-7
ii  gcc-11 [c-compiler]  11.3.0-12
ii  gcc-12 [c-compiler]  12.2.0-14
ii  gcc-9 [c-compiler]   9.3.0-22
ii  git [git-core]   1:2.39.2-1.1
ii  git-core 1:2.11.0-3+deb9u7
pn  libauthen-passphrase-perl
ii  libc6-dev [libc-dev] 2.36-9
pn  libcgi-formbuilder-perl  
ii  libcgi-pm-perl   4.55-1
pn  libcgi-session-perl  
ii  libcrypt-ssleay-perl 0.73.06-2+b1
pn  libgravatar-url-perl 
pn  liblwpx-paranoidagent-perl   
ii  libmail-sendmail-perl0.80-3
pn  libnet-openid-consumer-perl  
pn  librpc-xml-perl  
pn  libterm-readline-gnu-perl
ii  libtimedate-perl 2.3300-2
ii  libxml-simple-perl   2.25-2
ii  mercurial6.3.2-1
ii  subversion   1.14.2-4+b2

Versions of packages ikiwiki suggests:
pn  dvipng 
ii  file   1:5.44-3
ii  gettext0.21-12
ii  ghostscript10.0.0~dfsg-11
ii  graphviz   2.42.2-7+b3
ii  libfile-mimeinfo-perl  0.33-1
pn  libhighlight-perl  
ii  libhtml-tree-perl  5.07-3
pn  libimage-magick-perl | perlmagick  
ii  liblocale-gettext-perl 1.07-5
pn  libmagickcore-extra
ii  libmailtools-perl  2.21-2
pn  libnet-amazon-s3-perl  
pn  libnet-inet6glue-perl  
pn  libsearch-xapian-perl  
ii  libsort-naturally-perl 1.03-4
pn  libsparkline-php   
ii  libtext-csv-perl   2.02-2
pn  libtext-multimarkdown-perl 
pn  libtext-textile-perl   
pn  libtext-typography-perl
pn  libtext-wikicreole-perl
pn  libtext-wikiformat-perl
pn  libxml-feed-perl   
ii  libxml-writer-perl 0.900-2
pn  po4a   
pn  polygen
ii  python33.11.2-1+b1
ii  python3-docutils   0.19+dfsg-6
pn  texlive
pn  tidy   
pn  viewvc | gitweb | viewcvs  
pn  xapian-omega

Bug#1041655: src:aflplusplus: fails to migrate to testing for too long: unresolved RC issues


Source: aflplusplus
Version: 4.04c-4
Severity: serious
Control: close -1 4.07c-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1038760

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:aflplusplus has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build from source as reported in bug #1038760.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=aflplusplus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041647: Further gdb debugging (more #2)


After solving the relative path issue I now have better info:

(gdb) s
__vaDriverInit_1_17 (ctx=0x555702b0) at 
../src/gallium/frontends/va/context.c:123

123if (!ctx)
(gdb) n
126drv = CALLOC(1, sizeof(vlVaDriver));
(gdb) n
127if (!drv)
(gdb) n
130switch (ctx->display_type) {
(gdb) n
142   drv->vscreen = vl_dri3_screen_create(ctx->native_dpy, 
ctx->x11_screen);

(gdb) n
143   if (!drv->vscreen)
(gdb) n
144  drv->vscreen = vl_dri2_screen_create(ctx->native_dpy, 
ctx->x11_screen);

(gdb) s
vl_dri2_screen_create (display=0xd370, screen=0) at 
../src/gallium/auxiliary/vl/vl_winsys_dri.c:375

375 {
(gdb) n
385xcb_generic_error_t *error = NULL;
(gdb) n
394scrn = CALLOC_STRUCT(vl_dri_screen);
(gdb) n
395if (!scrn)
(gdb) n
398scrn->conn = XGetXCBConnection(display);
(gdb) n
399if (!scrn->conn)
(gdb) n
402xcb_prefetch_extension_data(scrn->conn, _dri2_id);
(gdb) n
404extension = xcb_get_extension_data(scrn->conn, _dri2_id);
(gdb) n
405if (!(extension && extension->present))
(gdb) n
408dri2_query_cookie = xcb_dri2_query_version (scrn->conn,
(gdb) n
411dri2_query = xcb_dri2_query_version_reply (scrn->conn, 
dri2_query_cookie, );

(gdb) n
412if (dri2_query == NULL || error != NULL || 
dri2_query->minor_version < 2)

(gdb) n
496free(dri2_query);
(gdb) p dri2_query
$1 = (xcb_dri2_query_version_reply_t *) 0x555f26a0
(gdb) p dri2_query->minor_version
$2 = 0
(gdb) n
497free(error);
(gdb) n
500FREE(scrn);
(gdb) n
501return NULL;
(gdb) n
__vaDriverInit_1_17 (ctx=0x555702b0) at 
../src/gallium/frontends/va/context.c:145

145   if (!drv->vscreen)
(gdb) n
231FREE(drv);
(gdb) n
232return VA_STATUS_ERROR_ALLOCATION_FAILED;
(gdb) n
va_openDriver (dpy=dpy@entry=0x55570140, driver_name=out>) at ./va/va.c:535

535 if (VA_STATUS_SUCCESS == vaStatus) {
(gdb) n
583 va_errorMessage(dpy, "%s init failed\n", 
driver_path);

(gdb) n
libva error: /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so init failed
584 dlclose(handle);

Bug#1041611: dmidecode --dump-bin segfaults

2023-07-21 Thread Jörg Frings-Fürst

forwarded 1041611 http://savannah.nongnu.org/bugs/index.php?64456
thanks

Hello Jan,


thank you for spending your time helping to make Debian better with this bug
report.

I have forward your bug to upstream.

CU
Jörg



-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.


Am Freitag, dem 21.07.2023 um 12:42 +0200 schrieb Jan Nordholz:
> Package: dmidecode
> Version: 3.5-1
> 
> Hi,
> 
> dmidecode --dump-bin segfaults on 64-bit architectures because  does
> not provide a declaration for fdopen() in ANSI mode, so the returned pointer
> is implicitly truncated to int:
> 
> [...]
> x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/tmp/dmidecode-3.5=. -fstack-
> protector-strong -Wformat -Werror=format-security -fPIE -Wdate-time -
> D_FORTIFY_SOURCE=2 -Os -ansi -c dmidecode.c -o dmidecode.o
> dmidecode.c: In function ‘dmi_table_dump’:
> dmidecode.c:5427:11: warning: assignment to ‘FILE *’ from ‘int’ makes pointer
> from integer without a cast [-Wint-conversion]
>  5427 | f = fdopen(fd, "wb");
>   |   ^
> [...]
> 
> Cheers,
> 
> Jan




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

Bug#1041588: grep -r fails with "Operation not supported"

Control: tags -1 patch

On 2023-07-21 19:38:08 +0200, Vincent Lefevre wrote:
> Indeed, it's a bundled gnulib. I was surprised because there is
> no "gnulib" directory. Actually these are just files under the m4
> directory. The bug is in "m4/dirfd.m4". I can see
> 
>   if test $ac_cv_func_dirfd = no && test $gl_cv_func_dirfd_macro = no; then
> HAVE_DIRFD=0
>   else
> HAVE_DIRFD=1
> dnl Replace only if the system declares dirfd already.
> if test $ac_cv_have_decl_dirfd = yes; then
>   REPLACE_DIRFD=1
> fi
> 
> where the last 4 lines
> 
> dnl Replace only if the system declares dirfd already.
> if test $ac_cv_have_decl_dirfd = yes; then
>   REPLACE_DIRFD=1
> fi
> 
> need to be removed to match the upstream gnulib fix.

And I could check that the corresponding attached patch makes
the error disappear.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -Naurd grep-3.11-orig/m4/dirfd.m4 grep-3.11/m4/dirfd.m4
--- grep-3.11~/m4/dirfd.m4	2023-04-29 11:03:00.0 +0200
+++ grep-3.11/m4/dirfd.m4	2023-07-21 19:40:41.345044696 +0200
@@ -40,10 +40,6 @@
 HAVE_DIRFD=0
   else
 HAVE_DIRFD=1
-dnl Replace only if the system declares dirfd already.
-if test $ac_cv_have_decl_dirfd = yes; then
-  REPLACE_DIRFD=1
-fi
 dnl Replace dirfd() on native Windows, to support fdopendir().
 AC_REQUIRE([gl_DIRENT_DIR])
 if test $DIR_HAS_FD_MEMBER = 0; then

Bug#1041654: support for desktop file spec 1.5

2023-07-21 Thread Knop, Alexander

Package: desktop-file-utils

Version: 0.26-1

Due to lack of support for Desktop file specifications using version 1.5, 
desktop files are seen as invalid:

$ desktop-file-validate 
Applications/squashfs-root/org.keepassxc.KeePassXC.desktop
Applications/squashfs-root/org.keepassxc.KeePassXC.desktop: error: value "1.5" 
for key "Version" in group "Desktop Entry" is not a known version
Applications/squashfs-root/org.keepassxc.KeePassXC.desktop: hint: value item 
"Security" in key "Categories" in group "Desktop Entry" can be extended with 
another category among the following categories: Settings, or System
Applications/squashfs-root/org.keepassxc.KeePassXC.desktop: error: file 
contains key "SingleMainWindow" in group "Desktop Entry", but keys extending 
the format should start with "X-"


This was fixed in an upstream commit in 2022: 
https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/commit/56d220dd679c7c3a8f995a41a27a7d6f3df49dea


It seems this Debian package needs to include the upstream patches

Bug#1041552: HFS/HFS+ are insecure

2023-07-21 Thread Matthew Garrett

On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:

> Unless somebody has a better idea then then my plan is to ship in the 
> next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist 
> directive to prevent automatically loading some file system modules.

I think this would break any existing fstab entries that reference hfs 
and hfsplus, and the convenient way to integrate Linux boot with x86 
Macs is certainly to have an hfsplus EFI partition so this may be a 
legitimate use-case. It also means that anyone who has a need to use one 
of these filesystems in a static manner is vulnerable to automount 
attacks using them.

Completely untested, but I think something along the lines of:

SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"

in a udev fragment should work? Any static fstab or mount units should 
still work, but it should disable udisks automounting regardless of the 
desktop agent involved, even if the fs modules are already loaded.

Bug#1041588: grep -r fails with "Operation not supported"

On 2023-07-21 13:08:11 -0400, Boyuan Yang wrote:
> BTW: Is grep 3.11-1 using Debian-packaged gnulib anywere? I did not
> see a build-dependency in
> https://sources.debian.org/src/grep/3.11-1/debian/control/ .
> 
> * If grep is indeed using it, please include the build-dep explicitly.
> 
> * If not, your current grep issue is unrelated to Debian-packaged gnulib and
> you will need further debugging.

Indeed, it's a bundled gnulib. I was surprised because there is
no "gnulib" directory. Actually these are just files under the m4
directory. The bug is in "m4/dirfd.m4". I can see

  if test $ac_cv_func_dirfd = no && test $gl_cv_func_dirfd_macro = no; then
HAVE_DIRFD=0
  else
HAVE_DIRFD=1
dnl Replace only if the system declares dirfd already.
if test $ac_cv_have_decl_dirfd = yes; then
  REPLACE_DIRFD=1
fi

where the last 4 lines

dnl Replace only if the system declares dirfd already.
if test $ac_cv_have_decl_dirfd = yes; then
  REPLACE_DIRFD=1
fi

need to be removed to match the upstream gnulib fix.

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

Bug#1035546: python3-pip: pip install ignores explicit --prefix=/usr (even with --root)

2023-07-21 Thread Stefano Rivera

Control: forwarded -1 https://github.com/pypa/pip/issues/10978

Hi Martin (2023.05.05_13:03:43_+0200)
> I also tried --prefix=/opt which then gets me /opt/local/{bin,lib}. So this
> behaviour directly contradicts the --help documentation:
...
> So this "/local" thing is both sticky and hard to avoid..

Yeah, the cause of this is our posix_local sysconfig scheme.

Ideally pip should have a --scheme argument. At least in Debian, where
we have multiple schemes interacting with each other, that could make
sense.

Or pip could use some knowledge of Debian's schemes to select
posix_prefix / posix_local as appropriate...

This all gets messy, I'm afraid.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1041653: meson: Drop gtk-sharp2* build deps


Source: meson
Version: 1.2.0-1

Please drop gtk-sharp2 and gtk-sharp2-gapi from Build-Depends.
The package builds without them and this will help getting rid of gtk-sharp2 
and eventually gtk2.

Bug#1041647: Further gdb debugging (more)

The mesa-va-drivers-dbgsym package seems to have incorrect (relative to 
build) paths stored which prevents gdb showing the source lines when it 
has the path to the mesa-22.6.3 source, however by blindly stepping and 
then looking at the source it narrows down the cause:


(gdb) s
126 in ../src/gallium/frontends/va/context.c
(gdb) s
__libc_calloc (n=n@entry=1, elem_size=elem_size@entry=4208) at 
./malloc/malloc.c:3629

3629./malloc/malloc.c: No such file or directory.
(gdb) s
3637in ./malloc/malloc.c
(gdb) finish
Run till exit from #0  __libc_calloc (n=n@entry=1, 
elem_size=elem_size@entry=4208) at ./malloc/malloc.c:3637
0x76a69893 in __vaDriverInit_1_17 (ctx=0x555702b0) at 
../src/gallium/frontends/va/context.c:126

126 ../src/gallium/frontends/va/context.c: No such file or directory.
Value returned is $1 = (void *) 0x555f1370
(gdb) n
127 in ../src/gallium/frontends/va/context.c
(gdb) n
130 in ../src/gallium/frontends/va/context.c
(gdb) n
142 in ../src/gallium/frontends/va/context.c
(gdb) n
143 in ../src/gallium/frontends/va/context.c
(gdb) n
144 in ../src/gallium/frontends/va/context.c
(gdb) n
145 in ../src/gallium/frontends/va/context.c
(gdb) n
231 in ../src/gallium/frontends/va/context.c
(gdb) n
232 in ../src/gallium/frontends/va/context.c
(gdb) n
va_openDriver (dpy=dpy@entry=0x55570140, driver_name=out>) at ./va/va.c:535

535 if (VA_STATUS_SUCCESS == vaStatus) {
(gdb) n
583 va_errorMessage(dpy, "%s init failed\n", 
driver_path);



Line 230-233 is:

error_screen:
   FREE(drv);
   return VA_STATUS_ERROR_ALLOCATION_FAILED;
}

which will be jumped to early if:

   case VA_DISPLAY_X11:
  drv->vscreen = vl_dri3_screen_create(ctx->native_dpy, 
ctx->x11_screen);

  if (!drv->vscreen)
 drv->vscreen = vl_dri2_screen_create(ctx->native_dpy, 
ctx->x11_screen);

  if (!drv->vscreen)
 drv->vscreen = vl_xlib_swrast_screen_create(ctx->native_dpy, 
ctx->x11_screen);

  break;
...
   }
   if (!drv->vscreen)
  goto error_screen;

Bug#1041647: Further gdb debugging


Using

export LIBVA_MESSAGING_LEVEL=2; export LIBVA_DRIVER_NAME=radeonsi; gdb 
--directory . --directory ../libva-2.17.0 --directory ../mesa-22.3.6 
--args /usr/bin/vainfo


I've stepped through vainfo and focused on va_openDriver() which
eventually leads to:

(gdb) n
libva info: Found init function __vaDriverInit_1_17
502 struct VADriverVTable *vtable = ctx->vtable;
(gdb) n
503 struct VADriverVTableVPP *vtable_vpp =
ctx->vtable_vpp;
(gdb) n
504 struct VADriverVTableProt *vtable_prot =
ctx->vtable_prot;
(gdb) n
507 if (!vtable) {
(gdb) n
508 vtable = calloc(1, sizeof(*vtable));
(gdb) n
509 if (!vtable)
(gdb) n
512 ctx->vtable = vtable;
(gdb) n
514 if (!vtable_vpp) {
(gdb) n
515 vtable_vpp = calloc(1, sizeof(*vtable_vpp));
(gdb) n
516 if (vtable_vpp)
(gdb) n
517 vtable_vpp->version =
VA_DRIVER_VTABLE_VPP_VERSION;
(gdb) n
521 ctx->vtable_vpp = vtable_vpp;
(gdb) n
523 if (!vtable_prot) {
(gdb) n
524 vtable_prot = calloc(1, sizeof(*vtable_prot));
(gdb) n
525 if (vtable_prot)
(gdb) n
526 vtable_prot->version =
VA_DRIVER_VTABLE_PROT_VERSION;
(gdb) n
530 ctx->vtable_prot = vtable_prot;
(gdb) n
532 if (init_func && VA_STATUS_SUCCESS == vaStatus)
(gdb) n
533 vaStatus = (*init_func)(ctx);
(gdb) s
535 if (VA_STATUS_SUCCESS == vaStatus) {
(gdb) p vaStatus
$4 = 2
(gdb) n
583 va_errorMessage(dpy, "%s init failed\n",
driver_path);

Bug#1041588: Info received (grep 3.11 -r on 100000+ files fails with "Operation not supported")

Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64773
Control: tags -1 + upstream


signature.asc
Description: PGP signature

Bug#1041588: grep -r fails with "Operation not supported"

Hi!

El 21/07/23 a las 11:02, Boyuan Yang escribió:
> Hi,
> 
> On Fri, 21 Jul 2023 10:39:54 +0200 Vincent Lefevre  wrote:
> > Control: severity -1 grave
> > Control: tags -1 - moreinfo
> > Control: retitle -1 grep -r on 10+ files fails with "Operation not
> supported"
> > 
> > On 2023-07-20 23:43:45 -0300, Santiago Ruano Rincón wrote:
> > > El 21/07/23 a las 04:06, Vincent Lefevre escribió:
> > > > On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote:
> > > > > There is a major regression in grep 3.11-1: I now get an error
> > > > > 
> > > > > cventin:~/Mail> grep -r xxxyyyzzz oldarc
> > > > > grep: oldarc/cur: Operation not supported
> > > > 
> > > > And no such issue with grep from the upstream git.
> > > 
> > > How are you compiling it?
> > 
> > $ ./bootstrap
> > $ ./configure --prefix=$HOME/opt/grep
> > $ make
> > $ make install
> > 
> > > My intuition is this comes from gnulib.
> > 
> > Yes, as in my next message, I said that the error disappeared
> > with the commit that updated gnulib (and did nothing else).
> > 
> > > But a reproducer is needed to confirm.
> > > 
> > > Tagging with moreinfo, and downgrading the severity since I cannot
> > > reproduce it myself:
> > [...]
> > > Please, feel free to bump the severity back again if you are able to
> > > find out a way to reproduce it.
> > 
> > One needs at least 10 files in the directory (9 is not enough).
> > With 10 empty files:
> > 
> > $ mkdir test-dir && for i in `seq 10` ; do : > test-dir/$i ; done
> > $ grep -r x test-dir
> > grep: test-dir: Operation not supported
> 
> Debian gnulib package maintainer here. I briefly checked grep source code,
> and it seems that grep is using the bundled gnulib and not using the packaged
> gnulib. Not 100% sure.

It indeed currently uses a bundled gnulib.

> 
> Whether to use the bundled gnulib is up to the packager's decision. Anyway,
> let me know if I could help.

I suppose we could give the packaged gnulib a try. Patches welcome ;-)

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1041651: bc does not speak german (2023-07-21)

2023-07-21 Thread olaf

Package: bc
Version: 1.07.1-3+b1
Severity: normal

Dear Maintainer,

the translation of the program description into German suggests that
bc can handle the German numeric keyboard. This is not the case, bc
uses only the dot as decimal separator, no comma. The translation is
therefore counterproductive and should be removed.


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

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

Versions of packages bc depends on:
ii  libc6 2.36-9
ii  libreadline8  8.2-1.3

bc recommends no packages.

bc suggests no packages.

-- debconf-show failed

Bug#1041588: grep 3.11 -r on 100000+ files fails with "Operation not supported"

Dear grep developers,

I am forwarding this gnulib bug that affects grep 3.11. Full bug report
can be found at https://bugs.debian.org/1041588

El 21/07/23 a las 10:39, Vincent Lefevre escribió:
> Control: severity -1 grave
> Control: tags -1 - moreinfo
> Control: retitle -1 grep -r on 10+ files fails with "Operation not 
> supported"
> 
> On 2023-07-20 23:43:45 -0300, Santiago Ruano Rincón wrote:
> > El 21/07/23 a las 04:06, Vincent Lefevre escribió:
> > > On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote:
> > > > There is a major regression in grep 3.11-1: I now get an error
> > > > 
> > > > cventin:~/Mail> grep -r xxxyyyzzz oldarc
> > > > grep: oldarc/cur: Operation not supported
> > > 
> > > And no such issue with grep from the upstream git.
> > 
> > How are you compiling it?
> 
> $ ./bootstrap
> $ ./configure --prefix=$HOME/opt/grep
> $ make
> $ make install
> 
> > My intuition is this comes from gnulib.
> 
> Yes, as in my next message, I said that the error disappeared
> with the commit that updated gnulib (and did nothing else).

Indeed. Our mails crossed.

> 
> > But a reproducer is needed to confirm.
> > 
> > Tagging with moreinfo, and downgrading the severity since I cannot
> > reproduce it myself:
> [...]
> > Please, feel free to bump the severity back again if you are able to
> > find out a way to reproduce it.
> 
> One needs at least 10 files in the directory (9 is not enough).
> With 10 empty files:
> 
> $ mkdir test-dir && for i in `seq 10` ; do : > test-dir/$i ; done
> $ grep -r x test-dir
> grep: test-dir: Operation not supported

Thank you, Vincent. I confirm with 9 files grep works as expected.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1041588: grep -r fails with "Operation not supported"

Hi,

在 2023-07-21星期五的 19:00 +0200，Vincent Lefevre写道：
> On 2023-07-21 17:22:11 +0200, Vincent Lefevre wrote:
> > The best solution would be to fix gnulib on the Debian side, IMHO.
> > I wonder whether other packages are affected too.
> [...]
> > So, if I understand correctly, the fix in gnulib appeared between
> > these two commits. But I don't see which change could affect the
> > result. I could try to investigate.
> 
> This was fixed in the following commit:
> 
> 
> commit d4d8abb39eb02c555f062b1f83ffcfac999c582f
> Author: Bruno Haible 
> Date:   2023-05-05 12:02:49 +0200
> 
>     dirfd: Fix bogus override (regression 2023-04-26).
>     
>     Reported by Bjarni Ingi Gislason  in
>     .
>     
>     * m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change.
> 
> diff --git a/ChangeLog b/ChangeLog
> index aaffe12fc1..5f01a52535 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,10 @@
> +2023-05-05  Bruno Haible  
> +
> +   dirfd: Fix bogus override (regression 2023-04-26).
> +   Reported by Bjarni Ingi Gislason  in
> +  
> .
> +   * m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change.
> +
>  2023-05-04  Bruno Haible  
>  
>     c32swidth: Add tests.
> diff --git a/m4/dirfd.m4 b/m4/dirfd.m4
> index d1ee2c7f61..7968b1287c 100644
> --- a/m4/dirfd.m4
> +++ b/m4/dirfd.m4
> @@ -1,4 +1,4 @@
> -# serial 27   -*- Autoconf -*-
> +# serial 28   -*- Autoconf -*-
>  
>  dnl Find out how to get the file descriptor associated with an open DIR*.
>  
> @@ -40,10 +40,6 @@ AC_DEFUN([gl_FUNC_DIRFD],
>  HAVE_DIRFD=0
>    else
>  HAVE_DIRFD=1
> -    dnl Replace only if the system declares dirfd already.
> -    if test $ac_cv_have_decl_dirfd = yes; then
> -  REPLACE_DIRFD=1
> -    fi
>  dnl Replace dirfd() on native Windows, to support fdopendir().
>  AC_REQUIRE([gl_DIRENT_DIR])
>  if test $DIR_HAS_FD_MEMBER = 0; then
> 
> 
> In the bug-gnulib discussion:
> 
>   https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00046.html
> 
> Bernhard Voelker says:
> > Gnulib commit 3f0950f65abb (2023-04-26) not only lead to build time
> > issues, but also made e.g. coreutils' rm(1) fail:
> > 
> > $ mkdir d && (cd d && seq 40 | xargs touch )
> > 
> > $ rm -rf d
> > rm: traversal failed: d: Operation not supported
> > 
> > I can confirm that this gnulib commit d4d8abb39eb0 fixes the issue again.
> 
> This is the same kind of error.
> 
> But I can see:
> 
> gnulib (20230615+stable-1) unstable; urgency=medium
> 
>   * QA upload.
>   * New upstream snapshot from stable branch stable-202301.
> 
>  -- Boyuan Yang   Tue, 20 Jun 2023 14:58:32 -0400
> 
> I've just rebuilt grep 3.11-1 with "debuild -i -us -uc -b",
> but I still get the same issue with it. I'm wondering what
> "stable branch stable-202301" means.

Looking at https://git.savannah.gnu.org/gitweb/?p=gnulib.git , gnulib
upstream is now providing stable branches that only include important
fixes. In Debian's package, I was tracking the stable-202301 branch.
It is likely that this bugfix was not backported onto it.

Anyway, I will look into it and see whether it affects Stable and Sid.
Since gnulib upstream also opened stable-202307 branch, I will likely
switch gnulib in Sid onto that branch, which should have included the
fix that grep now needs.

BTW: Is grep 3.11-1 using Debian-packaged gnulib anywere? I did not
see a build-dependency in
https://sources.debian.org/src/grep/3.11-1/debian/control/ .

* If grep is indeed using it, please include the build-dep explicitly.

* If not, your current grep issue is unrelated to Debian-packaged gnulib and
you will need further debugging.


Thanks,
Boyuan Yang


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

Bug#1041650: libopencv-dev: license in /usr/share/licenses

2023-07-21 Thread michel

Package: libopencv-dev
Version: 4.6.0+dfsg-12
Severity: minor
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,


you put the license in /usr/share/licenses the Arch way, it's the only package 
doing that.

Bug#1041588: grep -r fails with "Operation not supported"

On 2023-07-21 17:22:11 +0200, Vincent Lefevre wrote:
> The best solution would be to fix gnulib on the Debian side, IMHO.
> I wonder whether other packages are affected too.
[...]
> So, if I understand correctly, the fix in gnulib appeared between
> these two commits. But I don't see which change could affect the
> result. I could try to investigate.

This was fixed in the following commit:


commit d4d8abb39eb02c555f062b1f83ffcfac999c582f
Author: Bruno Haible 
Date:   2023-05-05 12:02:49 +0200

dirfd: Fix bogus override (regression 2023-04-26).

Reported by Bjarni Ingi Gislason  in
.

* m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change.

diff --git a/ChangeLog b/ChangeLog
index aaffe12fc1..5f01a52535 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-05-05  Bruno Haible  
+
+   dirfd: Fix bogus override (regression 2023-04-26).
+   Reported by Bjarni Ingi Gislason  in
+   .
+   * m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change.
+
 2023-05-04  Bruno Haible  
 
c32swidth: Add tests.
diff --git a/m4/dirfd.m4 b/m4/dirfd.m4
index d1ee2c7f61..7968b1287c 100644
--- a/m4/dirfd.m4
+++ b/m4/dirfd.m4
@@ -1,4 +1,4 @@
-# serial 27   -*- Autoconf -*-
+# serial 28   -*- Autoconf -*-
 
 dnl Find out how to get the file descriptor associated with an open DIR*.
 
@@ -40,10 +40,6 @@ AC_DEFUN([gl_FUNC_DIRFD],
 HAVE_DIRFD=0
   else
 HAVE_DIRFD=1
-dnl Replace only if the system declares dirfd already.
-if test $ac_cv_have_decl_dirfd = yes; then
-  REPLACE_DIRFD=1
-fi
 dnl Replace dirfd() on native Windows, to support fdopendir().
 AC_REQUIRE([gl_DIRENT_DIR])
 if test $DIR_HAS_FD_MEMBER = 0; then


In the bug-gnulib discussion:

  https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00046.html

Bernhard Voelker says:
| Gnulib commit 3f0950f65abb (2023-04-26) not only lead to build time
| issues, but also made e.g. coreutils' rm(1) fail:
|
| $ mkdir d && (cd d && seq 40 | xargs touch )
|
| $ rm -rf d
| rm: traversal failed: d: Operation not supported
|
| I can confirm that this gnulib commit d4d8abb39eb0 fixes the issue again.

This is the same kind of error.

But I can see:

gnulib (20230615+stable-1) unstable; urgency=medium

  * QA upload.
  * New upstream snapshot from stable branch stable-202301.

 -- Boyuan Yang   Tue, 20 Jun 2023 14:58:32 -0400

I've just rebuilt grep 3.11-1 with "debuild -i -us -uc -b",
but I still get the same issue with it. I'm wondering what
"stable branch stable-202301" means.

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

Bug#1041649: udisks2: udisksd report errors Error getting 'loop0' information: Failed to get status of the device loop0

2023-07-21 Thread in . cognito35

Package: udisks2
Version: 2.10.0-3
Severity: normal
X-Debbugs-Cc: in.cognit...@arcor.de

Dear Maintainer,

   * What led up to the situation?

Upgrade of package udisks2 from 2.9.4-4 to 2.10.0-3.

More precisely, unattended-upgrade did the following batch:

--
Packages that were upgraded:
 anacron bsdextrautils bsdutils fdisk libavif15 libblkid1 libcdr-0.1-1
 libexttextcat-2.0-0 libexttextcat-data libfdisk1 libmount1
 librubberband2 libselinux1 libsemanage-common libsemanage2 libsepol2
 libsmartcols1 libudisks2-0 libuuid1 media-types mount rfkill udisks2
 util-linux util-linux-extra util-linux-locales

Packages that were auto-removed:
 libblockdev-part-err2 libblockdev-part2 libblockdev-fs2
 libblockdev-loop2 libblockdev2 gdisk libparted-fs-resize0
 libblockdev-swap2
--

Plus the installation of the libblockdev*3 replacements of those packages
that got auto-removed.

   * What was the outcome of this action?

Getting below errors in the journal, both during boot and when mounting a
loop device.  Other than errors being reported everything seems to work
normally.  This system comes without a desktop environment and has a
APT::Install-Recommends == false setting.

Here the journal during startup with a bunch of these messages:

--
[   21.131297] sappc1 udisksd[968]: Error getting 'loop0' information: Failed 
to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
[   21.131460] sappc1 udisksd[968]: Error getting 'loop1' information: Failed 
to get status of the device loop1: No such device or address 
(g-bd-loop-error-quark, 1)
[   21.131618] sappc1 udisksd[968]: Error getting 'loop2' information: Failed 
to get status of the device loop2: No such device or address 
(g-bd-loop-error-quark, 1)
[   21.131768] sappc1 udisksd[968]: Error getting 'loop3' information: Failed 
to get status of the device loop3: No such device or address 
(g-bd-loop-error-quark, 1)
[   21.131922] sappc1 udisksd[968]: Error getting 'loop4' information: Failed 
to get status of the device loop4: No such device or address 
(g-bd-loop-error-quark, 1)
[   21.132156] sappc1 udisksd[968]: Error getting 'loop5' information: Failed 
to get status of the device loop5: No such device or address 
(g-bd-loop-error-quark, 1)
[   21.132340] sappc1 udisksd[968]: Error getting 'loop6' information: Failed 
to get status of the device loop6: No such device or address 
(g-bd-loop-error-quark, 1)
[   21.132481] sappc1 NetworkManager[984]:   [1689929537.4442] 
bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
[   21.132512] sappc1 systemd[1]: Started NetworkManager.service - Network 
Manager.
[   21.132531] sappc1 udisksd[968]: Error getting 'loop7' information: Failed 
to get status of the device loop7: No such device or address 
(g-bd-loop-error-quark, 1)
--

Here the journal corresponding to a (loop mount, loop unmount) cycle:

--
[27502.382864] foobar kernel: loop0: detected capacity change from 0 to 2097152
[27502.287538] foobar udisksd[968]: Set up loop device /dev/loop0 (backed by 
/media/usb/Documents/data00.vol)
[27515.952475] foobar udisksd[968]: Deleted loop device /dev/loop0 (was backed 
by /media/usb/Documents/data00.vol)
[27515.953535] foobar udisksd[968]: No longer watching loop device /dev/loop0
[27515.957314] foobar udisksd[968]: Error getting 'loop0' information: Failed 
to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
[27515.958549] foobar udisksd[968]: Error getting 'loop0' information: Failed 
to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
[27519.987721] foobar kernel: loop0: detected capacity change from 0 to 2097152
[27519.896150] foobar udisksd[968]: Set up loop device /dev/loop0 (backed by 
/media/usb/Documents/data00.vol)
[27528.280587] foobar udisksd[968]: Unlocked device /dev/loop0 as /dev/dm-6
[27528.359394] foobar udisksd[968]: Mounted /dev/dm-6 at /media/data00 on 
behalf of uid 1000
[27538.533501] foobar systemd[1]: media-data00.mount: Deactivated successfully.
[27538.533798] foobar udisksd[968]: Cleaning up mount point /media/data00 
(device 253:6 is not mounted)
[27538.535520] foobar udisksd[968]: Unmounted /dev/dm-6 on behalf of uid 1000
[27538.753368] foobar kernel: dm-6: detected capacity change from 2064384 to 0
[27538.616470] foobar udisksd[968]: Removing unlocked-crypto-dev entry {uint64 
64774, {'crypto-device': , 'dm-uuid': 
, 'unlocked-by-uid': }} because 
/dev/dm-6 now has another dm-uuid (NULL)
[27538.617060] foobar udisksd[968]: Removing unlocked-crypto-dev entry {uint64 
64774, {'crypto-device': , 'dm-uuid': 
, 'unlocked-by-uid': }} because

Bug#967750: smuxi: depends on deprecated GTK 2


And it would allow dropping messagingmenu-sharp from the archive.

Bug#1041489: ocsinventory-reports: version inconsistency between GUI and perl libraries

2023-07-21 Thread Krzysztof Jastrzębski


W dniu 19.07.2023 o 18:27, Krzysztof Jastrzębski pisze:

Package: ocsinventory-reports
Version: 2.8.1+dfsg1+~2.11.1-1
Severity: important

[...]
This makes the 2.8.1+dfsg1+~2.11.1-1 package useless and I am not sure 
if after the activity of the agents the database was not disintegrated 
and does not need to be restored from the backup.


I can confirm that inconsistency between ocsinventory-server and 
ocsinventory-reports perl libraries versions, completely disintegrates 
database, after first GUI use and first inventory done by agent.
First step is a2disconf ocsinventory-*.conf, comment out the crontabs on 
all agents and save the last good database dump for later recovery.
Final one, is maybe to purge server and reports packages and install 
from upstream source (2.12.0 has some PHP8 fixes; perl libs go to 
/usr/local).

Restoring database from last good backup is necessary.

--
Pozdrawiam Krzysztof Jastrzębski <><
krzysztof[at]jastrzebscy[dot]pl http://www.jastrzebscy.pl/

Bug#1041646: cinnamon: depends on typelib from unmaintained caribou

Source: cinnamon
Severity: important
Tags: upstream trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1041623 by -1
Control: block 1041641 by -1

cinnamon used to have a dependency on caribou, an experimental on-screen
keyboard from GNOME, which was removed in 2013:

>   * Remove caribou as dependency. (LP: #1106062)
(ref: )

but a dependency on at least its GObject-Introspection bindings was
reinstated in the next version, because cinnamon crashed on startup if
gir1.2-caribou-1.0 wasn't installed:

>   * Add missing dependency to gir1.2-caribou-1.0.
> (Fixes LP: #1106062 and LP: #1126721)
(ref: ,)
  )

I don't know whether the Caribou on-screen keyboard is shown in-process
by cinnamon, or whether cinnamon is talking to it via D-Bus or some other
IPC mechanism. If it's used via IPC, then that's not actually going to work
unless caribou itself happens to be installed (there is no dependency that
would make that happen, as far as I can see).

cinnamon seems to use caribou via Python and PyGI, so it should be
straightforward to make this dependency optional via a try:/except
ImportError: block, which would allow the dependency to be reduced to
a Suggests or nothing at all. GNOME Shell had similar handling for the
Telepathy framework for a while, although in JS rather than Python:
code to use it still existed, but it was runtime-optional.

The reason I'm raising this is that caribou was archived upstream
(#1041641) and depends on the unmaintained clutter-1.0 framework
(#1041623), so any bugs in it are not going to be fixed any more unless
someone (presumably from the cinnamon community) takes over the
responsibility for its upstream maintenance. In the absence of an upstream
maintainer, I don't think caribou should be included in trixie.

smcv

Bug#1041644: smuxi: FTBFS (source pkg): cli-common-dev missing


I am uploading a NMU to fix this. The debdiff is attached.
As I am also including the latest git change and dropping two dependencies, I 
am delaying by 10 days.diff -Nru smuxi-1.1/debian/changelog smuxi-1.1/debian/changelog
--- smuxi-1.1/debian/changelog  2021-02-12 18:54:21.0 +0100
+++ smuxi-1.1/debian/changelog  2023-07-21 18:06:31.0 +0200
@@ -1,3 +1,14 @@
+smuxi (1.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Drop notify and gtkspell (part of #967750)
+  * Move cli-common-dev to Build-Depends (Closes: #1041644)
+
+  [ Debian Janitor ]
+  * Remove constraints unnecessary since buster
+
+ -- Bastian Germann   Fri, 21 Jul 2023 18:06:31 +0200
+
 smuxi (1.1-1) unstable; urgency=low
 
   * The "From Hong Kong with Love" upload
diff -Nru smuxi-1.1/debian/control smuxi-1.1/debian/control
--- smuxi-1.1/debian/control2021-02-12 18:54:21.0 +0100
+++ smuxi-1.1/debian/control2023-07-21 18:06:31.0 +0200
@@ -7,31 +7,29 @@
 Build-Depends:
  debhelper (>= 7.0.50),
  dh-autoreconf,
+ cli-common-dev,
 Build-Depends-Indep:
  autoconf,
  automake,
  autopoint,
  autotools-dev,
- cli-common-dev (>= 0.5.7),
  gettext,
  gtk-sharp2-gapi,
  intltool,
  libdbus-glib2.0-cil-dev | libdbus-glib1.0-cil-dev | 
libndesk-dbus-glib1.0-cil-dev,
  libdbus2.0-cil-dev | libdbus1.0-cil-dev | libndesk-dbus1.0-cil-dev,
  libgio2.0-cil-dev | libglib2.0-dev,
- libglade2.0-cil-dev (>= 2.8),
- libglib2.0-cil-dev (>= 2.8),
- libgtk2.0-cil-dev (>= 2.8),
- libgtkspell-dev (>= 2.0.9),
+ libglade2.0-cil-dev,
+ libglib2.0-cil-dev,
+ libgtk2.0-cil-dev,
  liblog4net-cil-dev,
  libnunit-cil-dev,
  libmessagingmenu-cil-dev,
- libnini-cil-dev (>= 1.1),
- libnotify-cil-dev,
+ libnini-cil-dev,
  lsb-release,
- mono-devel (>= 2.6),
+ mono-devel,
  mono-runtime-boehm,
- mono-xbuild (>= 2.6),
+ mono-xbuild,
  pkg-config,
  tzdata,
 Standards-Version: 3.9.8
@@ -64,7 +62,6 @@
 Package: smuxi-engine
 Architecture: all
 Replaces:
- smuxi (<< 0.5.25),
  smuxi-engine-irc (<< 0.8.10.2),
  smuxi-engine-twitter (<< 0.8.10.2),
  smuxi-engine-xmpp (<< 0.8.10.2),
@@ -114,7 +111,6 @@
 Package: smuxi-frontend-gnome
 Architecture: all
 Replaces:
- smuxi (<< 0.5.25),
  smuxi-frontend-gnome-irc (<< 0.8.10.2),
 Breaks:
  smuxi-frontend-gnome-irc (<< 0.8.10.2),
diff -Nru smuxi-1.1/debian/rules smuxi-1.1/debian/rules
--- smuxi-1.1/debian/rules  2021-02-12 18:54:21.0 +0100
+++ smuxi-1.1/debian/rules  2023-07-21 18:02:48.0 +0200
@@ -14,8 +14,6 @@
--enable-engine-xmpp \
--enable-frontend-gnome \
--disable-frontend-stfl \
-   --with-notify \
-   --with-gtkspell \
--with-db4o=included \
GMCS=/usr/bin/mono-csc MCS=/usr/bin/mono-csc

Bug#1041645: firmware-iwlwifi: Intel AX210 reports "WRT: Invalid buffer destination" after upgrade to version 74 ucode

2023-07-21 Thread in . cognito35

Package: firmware-iwlwifi
Version: 20230515-3
Severity: normal
X-Debbugs-Cc: in.cognit...@arcor.de

Dear Maintainer,

   * What led up to the situation?

Upgrade of package firmware-iwlwifi to version 20230515-3, which provided
iwlwifi-ty-a0-gf-a0-74.ucode.

   * What was the outcome of this action?

Getting three errors "WRT: Invalid buffer destination" reported during
system startup, without (seemingly) any other adverse consequences - WiFi
connectivity continues to be fine.

Here is some context from the journal:

--
[   19.538343] foobar kernel: Bluetooth: hci0: Found device firmware: 
intel/ibt-0041-0041.sfi
[   19.538370] foobar kernel: Bluetooth: hci0: Boot Address: 0x100800
[   19.538371] foobar kernel: Bluetooth: hci0: Firmware Version: 98-13.23
[   19.559826] foobar kernel: iwlwifi :a6:00.0: Detected Intel(R) Wi-Fi 6 
AX210 160MHz, REV=0x420
[   19.559900] foobar kernel: thermal thermal_zone13: failed to read out 
thermal zone (-61)
   [...]
[   19.571169] foobar kernel: iwlwifi :a6:00.0: WRT: Invalid buffer 
destination
[   19.577171] foobar kernel: input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[   19.582482] foobar kernel: input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input17
[   19.582570] foobar kernel: input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input18
[   19.582668] foobar kernel: input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input19
   [...]
[   21.189038] foobar udisksd[968]: Acquired the name org.freedesktop.UDisks2 
on the system message bus
[   21.21] foobar kernel: iwlwifi :a6:00.0: WRT: Invalid buffer 
destination
[   21.233365] foobar kernel: Bluetooth: hci0: Waiting for firmware download to 
complete
[   21.233369] foobar kernel: Bluetooth: hci0: Firmware loaded in 1655297 usecs
[   21.233429] foobar kernel: Bluetooth: hci0: Waiting for device to boot
[   21.216489] foobar systemd[1]: Stopping cups.service - CUPS Scheduler...
   [...]
[   21.532687] foobar NetworkManager[984]:   [1689929537.8442] device 
(wlp166s0): set-hw-addr: set MAC address to F2:29:0A:EA:CE:55 (scanning)
[   21.558864] foobar kernel: bridge: filtering via arp/ip/ip6tables is no 
longer available by default. Update your scripts to load br_netfilter if you 
need this.
[   21.571379] foobar kernel: iwlwifi :a6:00.0: WRT: Invalid buffer 
destination
[   21.734656] foobar kernel: iwlwifi :a6:00.0: WFPM_UMAC_PD_NOTIFICATION: 
0x1f
[   21.734702] foobar kernel: iwlwifi :a6:00.0: WFPM_LMAC2_PD_NOTIFICATION: 
0x1f
[   21.734727] foobar kernel: iwlwifi :a6:00.0: WFPM_AUTH_KEY_0: 0x80
[   21.734744] foobar kernel: iwlwifi :a6:00.0: CNVI_SCU_SEQ_DATA_DW9: 0x0
[   21.821932] foobar NetworkManager[984]:   [1689929538.1335] failed to 
open /run/network/ifstate
[   21.827288] foobar NetworkManager[984]:   [1689929538.1389] device 
(lo): state change: disconnected -> prepare (reason 'none', sys-iface-state: 
'external')
--

lspci output:

--
[~]$ lspci | grep -i network
a6:00.0 Network controller: Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz 
(rev 1a)
--

   * What outcome did you expect instead?

No errors, as in previous firmware versions.

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1041644: smuxi: FTBFS (source pkg): cli-common-dev missing


Source: smuxi
Version: 1.1-1

Build-Depends misses the cli-common-dev, which is only included in 
Build-Depends-Indep.
Therefore, building the source package only fails:

dh: error: unable to load addon cli: Can't locate Debian/Debhelper/Sequence/cli.pm in @INC (you may 
need to install the Debian::Debhelper::Sequence::cli module) (@INC contains: /etc/perl 
/usr/local/lib/i386-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 
/usr/lib/i386-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl-base 
/usr/lib/i386-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at (eval 4) line 1.

Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers

2023-07-21 Thread Ben Hutchings

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ker...@lists.debian.org, 
Steve Dickson , Chuck Lever III 

* Package name: ktls-utils
  Version : 0.9
  Upstream Contact: kernel-tls-handsh...@lists.linux.dev
* URL : https://github.com/oracle/ktls-utils
* License : GPLv2
  Programming Lang: C
  Description : TLS handshake utilities for in-kernel TLS consumers

In-kernel TLS consumers need a mechanism to perform TLS handshakes on
a connected socket to negotiate TLS session parameters that can then
be programmed into the kernel's TLS record protocol engine.

This package of software provides a TLS handshake user agent that
listens for kernel requests and then materializes a user space socket
endpoint on which to perform these handshakes. The resulting
negotiated session parameters are passed back to the kernel via
standard kTLS socket options.

This will be maintained by the kernel team.

Bug#1041642: dh_missing: Doesn't work if used in $(CURDIR)

2023-07-21 Thread Daniel Leidert

Package: debhelper
Version: 13.11.4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have a native package source from which I build multiple binary packages. The
files are organized as they would be on the target system with their full
destination path. As an example, the souirce directory contains:

./usr/share/applications/foo.desktop

Now I want to make sure that all files become part of a package and I don't
miss to ship any source files. I have multiple .install files in debian/ for
each package. There isn't any Makefile involved, nor do I install all files
into a temporary location first. I just want to make sure that all files,
except for the debian/ directory, are part of a package.

If I run:

dh_missing -XREADME.md -Xdebian/ --fail-missing

I don't get any error, even if I missed a file. This can be easily verified by
just removing one of the -X switches. It should throw an error then, but it
doesn't. But if I add the source directory like:

dh_missing -XREADME.md -Xdebian/ --sourcedir=$(CURDIR) --fail-missing

I get an error for all files, even if they are part of a package. The weird
part is that debhelper then says:

As an example, you might want to replace:
 * usr/share/applications/foo.desktop
with:
 * usr/share/applications/foo.desktop

Note that both paths are the same. Also, there is a .install file installing
usr/share/applications/foo.desktop.

This might be a cornercase, but I find it quite weird that it isn't working and
I could really use this. Is that a bug or a feature request?

Regards, Daniel


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
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 debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.1-1
ii  dpkg 1.21.22
ii  dpkg-dev 1.21.22
ii  dwz  0.15-1
ii  file 1:5.44-3
ii  libdebhelper-perl13.11.4
ii  libdpkg-perl 1.21.22
ii  man-db   2.11.2-2
ii  perl 5.36.0-7
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202301

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmS6rjYACgkQS80FZ8KW
0F0WQQ//Y9WCIzZBOiOPGt6CN57N4l08JE3K0kIt/RqyT8Tif7mVSlvNsih4mV9R
G0i44C2s6RVOJ7LB8bPW3UYH2Jj3VO2I7RbNUc6TSCZ0cH4b5/l3OwktzvAh39AZ
L7zV6rgNfCLFVuy6MCyEGp01k88uE2yYX5swCMlf7vhoD+8N2a0otdyAU0RhlrXe
TQEcsZ3qhwNHU7QIyBrJZSA6Vzg0txrL9+z6mROAo5i0Qyk6f5CFV2PkgPpoU5Xh
6nw8N6C06ScSkbIF28O9WjI8VeI//RRoXZIjAxj8nDpxBLPt1qEGR08x2X5fW+2M
wE+9zb1iKPWzHD/8GsZ6BW4SEYktc6L8UsuprIvHi1d0o493rfGXgCVFF3xuJwGi
LuFfJIkPvL8CesVwYmI4rcL3ttF74LatoI9UxwnlLJLtErMX4FhTmQQwU1s6b1bl
yljR6QycPEZRhqCijO2reP2exMD1MsPkDyRIFSW6u3JKVWr6+Kz0uLsZIFBWGKFm
KgcsZcKk0Cf9K/mGOqvPe7Qb5LydWlZ8rub/Du0aW8T1kiSF1UrleGZgaXt3Ujy9
rDKIGmEZ05zKg6/1O0eHfD4bXJv/QIp+Js5TBNnJMkRMk77LB9AQo90NQBgLuX0y
MLaWIf2RthtcJ0quPoQ/wS1bPVJszusb20N9ySYkzHNfeV5i0Gc=
=L/9u
-END PGP SIGNATURE-

Bug#1041641: caribou: no longer maintained upstream

Source: caribou
Severity: important
Tags: upstream wontfix trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
X-Debbugs-Cc: cinna...@packages.debian.org

caribou is no longer maintained:

> Caribou is not under active development anymore.
> — https://wiki.gnome.org/Projects/Caribou

> Archived project! Repository and other project resources are read-only
> — https://gitlab.gnome.org/Archive/caribou

It also depends on the unmaintained clutter-1.0 framework (#1041623).
It is not clear to me whether it ever reached a fully-usable status:

> This is an early release intended for people to preview the UI
> interaction. Caribou is not currently usable as a primary text input
> application.
> — https://wiki.gnome.org/Projects/Caribou

The only package in Debian that depends on it is cinnamon.

If cinnamon needs this package for its onscreen keyboard, then someone
from the cinnamon community will need to take responsibility for its
upstream maintenance.

Alternatively, if cinnamon doesn't need this feature or can use some
replacement, then caribou should be removed during the Debian 13 cycle.

smcv

Bug#1041597: [PATCH] qemu-user-static: binfmt not matching MIPS ELFs with NaN2008 bit set

2023-07-21 Thread Xinhui Yang

Hi Michael,

On Fri, 21 Jul 2023 13:25:44 +0300 Michael Tokarev  wrote:
> 21.07.2023 11:30, Xinhui Yang wrote:
> > Package: qemu-user-static
> > Version: 1:8.0.3+dfsg-2
> >
> > QEMU 8.0 brings support for NaN2008 ELF executables[1] for userland
> > emulation. A modification on binfmt side is required to adapt this
> > change.
> >
> > [1]:
https://gitlab.com/qemu/qemu/-/commit/450cb7ec2c5fda51b9650ca25e59ac9deeb60d1b
>
> Thank you for the patch and the efforts!
> It's difficult to diff hex numbers.
>
> Can you please check of this change:
>
>
https://salsa.debian.org/qemu-team/qemu/-/commit/2b2a0014644d4f0a7dc6641cf321e47e91634333
>
> works for you?
>
> it is based on a upstream change to binfmt registration which I forgot
to include.
> But I'm not certain I get it all right, - there might be some
cut-n-paste mistake.
>
> I *think* it includes your change plus a bit more.
>

Yes, after filing this bug I tested the binfmt support script shipped
with QEMU. It worked fine, I can run both NaN2008 and Release 6 ELFs,
since it can cover a bit more ELFs of the same machine or architecture.

>
> (I need to think about switching to using upstream qemu-binfmt-register.sh
> (which is based on debian/binfmt-install but with furhter enhancements)).
>

I would like to suggest it too, since QEMU now have a binfmt solution,
which could save a lot of work for downstream distros, as distros would
no longer have to ship binfmt configurations themselves.

Thanks,
Xinhui

Bug#1041535: transition: libcamera 0.1.0

Control: tags -1 confirmed

On 2023-07-20 15:11:48 +0200, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> Please schedule a transition slot for libcamera 0.1.0.
> 
> The auto-generated ben tracker looks good:
> https://release.debian.org/transitions/html/auto-libcamera.html
> 
> The unique reverse dep (pipewire 0.3.74-1) builds fine with the
> new libcamera in experimental.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1041518: transition: openstructure

Control: tags -1 confirmed

On 2023-07-20 10:18:56 +0300, Andrius Merkys wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I would like to request a transition slot for openstructure
> (experimental -> unstable) due to soname bump. Current ben tracker [1]
> is OK.
> 
> openstructure has a single reverse dependency, promod3, which also has to
> undergo a transition of its own, but since it is a leaf package I suppose I
> can transition them together. The updated promod3 is also waiting in
> experimental.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1041640: RM: sdb -- RoQA; unpackaged upstream versions; unmaintained dependency; low popcon


Source: sdb
Severity: serious

Please consider removing sdb. It depends on the unmaintained nrefactory.
If nobody reacts within a month I am going to file the RM bug.

Bug#1041639: RM: mono-debugger-libs -- RoQA; unpackaged upstream changes; unmaintained dependency


Source: mono-debugger-libs
Severity: serious

Please consider removing mono-debugger-libs. It depends on the unmaintained 
nrefactory.
If nobody reacts within a month I am going to file the RM bug.

Bug#1040334: facet-analyser - build-depends on conflicting packages

2023-07-21 Thread Roland Mas


Le 04/07/2023 à 17:53, Steven Robbins a écrit :

On Tuesday, July 4, 2023 10:03:27 A.M. CDT Peter Green wrote:

Package: facet-analyser
Version: 0.0~git20221121142040.6be10b8+ds1-3
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same
release" User: debian...@lists.debian.org
Usertags: edos-uninstallable
x-debbugs-cc: s...@debian.org

facet-analyser build-depends on both python3-paraview and
libinsighttoolkit5-dev

unfortunately, libinsighttoolkit5-dev recently added a dependency on
libvtk9-dev which depends on python3-vtk9 which conflicts with
python3-paraview.

I am not familiar enough with the packages in question to know what the
most appropriate way to untangle this is.

That's curious.  I don't know either.  My questions are: why do python3-vtk9
and python3-paraview conflict, and could the issue be solved another way?


I think it's because python3-paraview uses its own vtk9, see #982601 and 
#654839.


Roland.

Bug#1041597: [PATCH] qemu-user-static: binfmt not matching MIPS ELFs with NaN2008 bit set

2023-07-21 Thread Cyan

Hi Michael,

On Fri, 21 Jul 2023 13:25:44 +0300 Michael Tokarev  wrote:
> 21.07.2023 11:30, Xinhui Yang wrote:
> > Package: qemu-user-static
> > Version: 1:8.0.3+dfsg-2
> > 
> > QEMU 8.0 brings support for NaN2008 ELF executables[1] for userland
> > emulation. A modification on binfmt side is required to adapt this
> > change.
> > 
> > [1]: 
> > https://gitlab.com/qemu/qemu/-/commit/450cb7ec2c5fda51b9650ca25e59ac9deeb60d1b
> 
> Thank you for the patch and the efforts!
> It's difficult to diff hex numbers.
> 
> Can you please check of this change:
> 
>   
> https://salsa.debian.org/qemu-team/qemu/-/commit/2b2a0014644d4f0a7dc6641cf321e47e91634333
> 
> works for you?
> 
> it is based on a upstream change to binfmt registration which I forgot to 
> include.
> But I'm not certain I get it all right, - there might be some cut-n-paste 
> mistake.
> 
> I *think* it includes your change plus a bit more.
>

Yes, after filing this bug I tested the binfmt support script shipped
with QEMU. It worked fine, I can run both NaN2008 and Release 6 ELFs,
since it can cover a bit more ELFs of the same machine or architecture.

>
> (I need to think about switching to using upstream qemu-binfmt-register.sh
> (which is based on debian/binfmt-install but with furhter enhancements)).
>

I would like to suggest it too, since QEMU now have a binfmt solution,
which could save a lot of work for downstream distros, as distros would
no longer have to ship binfmt configurations themselves.

Thanks,
Xinhui

Bug#1041638: bugs.debian.org: the b.d.o mail sofware doesn't parse the "To:" header correctly, generating incorrect addresses

Package: bugs.debian.org
Severity: important

For bug 1041631, I replied to a mail, and the headers were:

To: "Preuße, Hilmar" 
Cc: 1041...@bugs.debian.org

with the "To:" encoded as:

To: =?iso-8859-1?Q?Preu=DFe=2C?= Hilmar 

This is correct and can be visible at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041631;mbox=yes;msg=15

But in the copy from
lists-bugs=1041...@bendel.debian.org, the "To:" became:

To: =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org,
?= Hilmar 

which is completely wrong!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041631;msg=15
is not correct either:

To: Preuße, Hilmar 

where the quotes (needed due to the unencoded comma) are missing.

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

Bug#967750: smuxi: depends on deprecated GTK 2


Control: severity -1 important

Am 21.07.23 um 17:18 schrieb Bastian Germann:

How about dropping smuxi-frontend-gnome entirely? It has a low enough popcon.
Upstream does not seem to move towards gtk3 anytime soon.


Also, this would allow dropping notify-sharp soon which nobody cared to 
trivially fix for bookworm.

Bug#1041635: RM: tasque -- RoQA; depends on gtk2; dead upstream


Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:tasque

Please remove tasque. It is dead upstream and depends on gtk2. Nobody cared to make its dependencies 
fit for bookworm, so it was not released.

Bug#1041588: grep -r fails with "Operation not supported"

On 2023-07-21 11:02:10 -0400, Boyuan Yang wrote:
> Debian gnulib package maintainer here. I briefly checked grep source code,
> and it seems that grep is using the bundled gnulib and not using the packaged
> gnulib. Not 100% sure.
> 
> Whether to use the bundled gnulib is up to the packager's decision. Anyway,
> let me know if I could help.

The best solution would be to fix gnulib on the Debian side, IMHO.
I wonder whether other packages are affected too.

BTW, the grep commit that updated the bundled gnulib:

diff --git a/gnulib b/gnulib
index c2a5953..2e671b8 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit c2a5953f179814dd0f4b7e627aae9a009181ed6a
+Subproject commit 2e671b84c8ec5426aee37f4a6656d531929ee430

So, if I understand correctly, the fix in gnulib appeared between
these two commits. But I don't see which change could affect the
result. I could try to investigate.

Knowing the real problem would allow one to make sure that this
is not a bug that is temporarily hidden.

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

Bug#1041634: WIKI: the DebianDate wiki macro is not working properly.

2023-07-21 Thread d3vf4n

Package: wiki.debian.orgX-Debbugs-CC: 
debian-...@lists.debian.org,deb...@tchung.org
Hello, I want to report on the DebianDate macro of the Debian wiki not working 
correctly.

The DebianDate macro  is supposed 
to return the release date of a supplied suite of Debian. But it returns the 
release date of the stable version of Debian (12.0), no matter what the 
argument is (stable, oldstable, oldoldstable).
Apparently this was first noticed by Thomas Chung when updating the wiki's 
front page  in mid-june.

This macro helps having the release dates for different versions always 
up-to-date, thus it is annoying, and error prone, to have to replace it by a 
hardcoded date. Again see the wiki's front page for an example of that.

The source code of the macro is at a repository 

 owned by PaulWise.

Just for the record, and to make crystal clear what the problem is, here is a 
simple example of the error: edit any page of the wiki and paste the following 
lines. 

<>, <>, <>

<>, <>, 
<>

the output will be

2023-06-10, 2023-06-10, 2023-06-10
bookworm, bullseye, buster


Best regards.

--
Enviat amb Tutanota.

Bug#967750: smuxi: depends on deprecated GTK 2


How about dropping smuxi-frontend-gnome entirely? It has a low enough popcon.
Upstream does not seem to move towards gtk3 anytime soon.

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

2023-07-21 Thread Sebastiaan Couwenberg


Changes between bookworm and sid:

cmake 3.25.1:

 ``Python_SITELIB``
   Third-party platform independent installation directory.

   Information returned by

``distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False)``
   or else ``sysconfig.get_path('purelib')``.
 ``Python_SITEARCH``
   Third-party platform dependent installation directory.

   Information returned by

``distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=False)``
   or else ``sysconfig.get_path('platlib')``.

cmake 3.27.0:

 ``Python_SITELIB``
   Third-party platform independent installation directory.

   Information returned by ``sysconfig.get_path('purelib')``.
 ``Python_SITEARCH``
   Third-party platform dependent installation directory.

   Information returned by ``sysconfig.get_path('platlib')``.

On bookworm distutils is still used which returns:

 >>> distutils.sysconfig.get_python_lib(
 plat_specific=False,
 standard_lib=False,
 )
 '/usr/lib/python3/dist-packages'

On sid sysconfig is used which results:

 >>> sysconfig.get_path('platlib')
 '/usr/local/lib/python3.11/dist-packages'

To get the right path for the Debian python3 interpreter,
you need to add 'deb_system':

 >>> sysconfig.get_path('platlib', 'deb_system')
 '/usr/lib/python3/dist-packages'

Kind Regards,

Bas

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

Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH

2023-07-21 Thread Bas Couwenberg

Source: cmake
Version: 3.27.0-1
Severity: serious
Tags: upstream
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

FindPython.cmake in 3.27 returns the wrong Python_SITEARCH path which breaks 
the qgis build:

 -- Python site-packages: /usr/local/lib/python3.11/dist-packages

This was:

 -- Python site-packages: /usr/lib/python3/dist-packages

Kind Regards,

Bas

Bug#1041588: grep -r fails with "Operation not supported"

Hi,

On Fri, 21 Jul 2023 10:39:54 +0200 Vincent Lefevre  wrote:
> Control: severity -1 grave
> Control: tags -1 - moreinfo
> Control: retitle -1 grep -r on 10+ files fails with "Operation not
supported"
> 
> On 2023-07-20 23:43:45 -0300, Santiago Ruano Rincón wrote:
> > El 21/07/23 a las 04:06, Vincent Lefevre escribió:
> > > On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote:
> > > > There is a major regression in grep 3.11-1: I now get an error
> > > > 
> > > > cventin:~/Mail> grep -r xxxyyyzzz oldarc
> > > > grep: oldarc/cur: Operation not supported
> > > 
> > > And no such issue with grep from the upstream git.
> > 
> > How are you compiling it?
> 
> $ ./bootstrap
> $ ./configure --prefix=$HOME/opt/grep
> $ make
> $ make install
> 
> > My intuition is this comes from gnulib.
> 
> Yes, as in my next message, I said that the error disappeared
> with the commit that updated gnulib (and did nothing else).
> 
> > But a reproducer is needed to confirm.
> > 
> > Tagging with moreinfo, and downgrading the severity since I cannot
> > reproduce it myself:
> [...]
> > Please, feel free to bump the severity back again if you are able to
> > find out a way to reproduce it.
> 
> One needs at least 10 files in the directory (9 is not enough).
> With 10 empty files:
> 
> $ mkdir test-dir && for i in `seq 10` ; do : > test-dir/$i ; done
> $ grep -r x test-dir
> grep: test-dir: Operation not supported

Debian gnulib package maintainer here. I briefly checked grep source code,
and it seems that grep is using the bundled gnulib and not using the packaged
gnulib. Not 100% sure.

Whether to use the bundled gnulib is up to the packager's decision. Anyway,
let me know if I could help.

Thanks,
Boyuan Yang


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

Bug#1041270: dynarmic: broke ABI without SONAME bump

2023-07-21 Thread Andrea Pappacoda

> Hi Sebastian, thanks for your report. I've uploaded a new version with 
> a possible fix on Mentors, you can find it at 
> . I've also attached a 
> debdiff for your convenience.
> 
> Feel free to upload it to unstable if you find this solution 
> reasonable. Since this is only a soname change, without any actual 
> library change, I believe that uploading to experimental first is 
> unnecessary.
> 
> If it doesn't look right to you, I'll be happy to hear your feedback :)

My previous solution was broken since it introduced a new package with
the same contents as the older libdynarmic6 package, causing an unpack
error. Luckly upstream has merged my patch and tagged a new release,
so I simply updated to the new upstream version, getting rid of the file
conflict and bumping the ABI.

I don't have access to my private OpenPGP keys right now, so I can't upload
the new release on Mentors, but I'll attach a debdiff nonetheless containing
the 6.5.0-1 release. You can also find it on Salsa at
.

dynarmic_6.5.0+ds-1.debdiff
Description: Binary data

Bug#1041631: texlive-xetex: CreationDate in the generated PDF file is incorrect by 1 hour in some timezones

On 2023-07-21 16:36:21 +0200, Preuße, Hilmar wrote:
> On 21.07.2023 16:28, Vincent Lefevre wrote:
> > The "CreationDate:" field in the generated PDF file is incorrect by
> > 1 hour in the Europe/Paris CEST timezone (= UTC + 2).
> > 
> I've uploaded TL2023 to experimental. Are you willing to test if the issue
> is solved there?
> 
> Beware: the package is not complete yet, there is not context package being
> compatible to texlive-binaries.

Sorry, I've just noticed that I forgot to include the test.tex file.
Here is it (this is the simplest one as possible):

\documentclass{article}
\begin{document}
.
\end{document}

If you installed TL2023 on one of your machines, could you try to
reproduce the bug after "export TZ=Europe/Paris", for instance?

Otherwise, I can try (but it will be a bit complex to upgrade the
packages to experimental and downgrade again after the test).

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

Bug#1041631: texlive-xetex: CreationDate in the generated PDF file is incorrect by 1 hour in some timezones

2023-07-21 Thread Preuße


On 21.07.2023 16:28, Vincent Lefevre wrote:

Hi,


The "CreationDate:" field in the generated PDF file is incorrect by
1 hour in the Europe/Paris CEST timezone (= UTC + 2).

I've uploaded TL2023 to experimental. Are you willing to test if the 
issue is solved there?


Beware: the package is not complete yet, there is not context package 
being compatible to texlive-binaries.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041631: texlive-xetex: CreationDate in the generated PDF file is incorrect by 1 hour in some timezones

Package: texlive-xetex
Version: 2022.20230122-3
Severity: normal

The "CreationDate:" field in the generated PDF file is incorrect by
1 hour in the Europe/Paris CEST timezone (= UTC + 2).

Example:

$ export LC_ALL=C
$ date && xelatex test.tex && pdfinfo test.pdf | grep Date:
Fri Jul 21 16:09:39 CEST 2023
This is XeTeX, Version 3.141592653-2.6-0.94 (TeX Live 2022/Debian) 
(preloaded format=xelatex)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2022-11-01> patch level 1
L3 programming layer <2023-01-16>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2022/07/02 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xetex.def)
(./test.aux) (/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd) [1]
(./test.aux) )
Output written on test.pdf (1 page).
Transcript written on test.log.
CreationDate:Fri Jul 21 15:09:40 2023 CEST

It looks like as if it were the winter time (UTC + 1).

Same issue in the Europe/London and America/New_York timezones.
For instance:

$ export TZ=Europe/London
$ export LC_ALL=C
$ date && xelatex test.tex && pdfinfo test.pdf | grep Date:
2023-07-21T15:22:17 BST
This is XeTeX, Version 3.141592653-2.6-0.94 (TeX Live 2022/Debian) 
(preloaded format=xelatex)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2022-11-01> patch level 1
L3 programming layer <2023-01-16>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2022/07/02 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xetex.def)
(./test.aux) (/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd) [1]
(./test.aux) )
Output written on test.pdf (1 page).
Transcript written on test.log.
CreationDate:Fri Jul 21 14:22:18 2023 BST

But the behavior is correct for America/Guyana and
America/Argentina/Buenos_Aires.

This could possibly be related to the daylight saving time.

Note that pdflatex does not have any issue.

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 3539 2023-07-11 16:10:44 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2022-10-12 23:25:33 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2023-04-09 11:54:45 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2023-04-09 11:54:45 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2022-10-13 13:39:43 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2023-04-09 11:54:45 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2023-04-09 11:54:45 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5130 2023-07-04 13:03:08 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2015-09-03 02:24:29 mktex.cnf
-rw-r--r-- 1 root root 475 2022-10-13 13:39:43 texmf.cnf

Bug#1041630: gnome-shell-extension-weather: depends on unmaintained clutter-1.0

Source: gnome-shell-extension-weather
Version: 119-1
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs clutter
Control: block 996690 by -1

This package depends on gir1.2-clutter-1.0 from clutter-1.0, which is
no longer maintained upstream (and has been effectively unmaintained
for a while).

Confusingly, mutter/gnome-shell contain a fork of clutter, also named
"Clutter" in APIs, which *is* maintained. If the only places this Shell
extension refers to "Clutter" are in a GNOME Shell extension, then it
does not need to depend on gir1.2-clutter-1.0, and the dependency can
be removed.

If this extension contains independent helper programs that run outside
Shell's execution environment, and *those* import Clutter, then they
should be ported from GTK 3 and Clutter to GTK 4 and libadwaita.
 has a bit more
information on this. However, from a quick glance at codesearch.debian.net,
I don't think that's actually the case.

Thanks,
smcv

Bug#1041629: gnome-shell-extension-gsconnect: depends on unmaintained clutter-1.0