from:"\- \-"

Source: zsh
Version: 5.9-6
Severity: wishlist
Tags: patch

While looking for upstream fixes for zsh compatibility with gcc 14,
I noticed that the source package uses git:// and http:// URLs in
debian/upstream/metadata, which do not authenticate the identity of the
remote server and so are vulnerable to man-in-the-middle attacks. Please
replace them with their equivalent https:// URLs, for example by applying
the attached patch.

Thanks,
smcv
>From 047ed307dab5b74451570da93f59f465da5a3ccc Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 3 Aug 2024 16:39:08 +0100
Subject: [PATCH] d/upstream/metatata: Use secure URLs

The http and anonymous git protocols do not authenticate the identity
of the server, making them vulnerable to man-in-the-middle attacks.
Replace them with authenticated equivalents.

zsh.sourceforge.net redirects to zsh.sourceforge.io, so presumably
that address is now considered canonical.
---
 debian/upstream/metadata | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/upstream/metadata b/debian/upstream/metadata
index c1bf49f68..9d905fd60 100644
--- a/debian/upstream/metadata
+++ b/debian/upstream/metadata
@@ -2,13 +2,13 @@
 ---
 # https://wiki.debian.org/UpstreamMetadata
 Bug-Submit: mailto:zsh-work...@zsh.org
-Changelog: http://zsh.sourceforge.net/releases.html
+Changelog: https://zsh.sourceforge.io/releases.html
 Contact: zsh-work...@zsh.org
 Security-Contact: zsh-secur...@zsh.org
-FAQ: http://zsh.sourceforge.net/FAQ/
+FAQ: https://zsh.sourceforge.io/FAQ/
 Name: Z shell
 Homepage: https://www.zsh.org/
-Homepage: http://zsh.sourceforge.net/
-Repository: git://git.code.sf.net/p/zsh/code
+Homepage: https://zsh.sourceforge.io/
+Repository: https://git.code.sf.net/p/zsh/code
 Repository-Browse: https://sourceforge.net/p/zsh/code/ci/master/tree/
-Documentation: http://zsh.sourceforge.net/Doc/
+Documentation: https://zsh.sourceforge.io/Doc/
-- 
2.45.2

Bug#1075708: zsh: FTBFS with GCC-14

Control: tags -1 + patch

On Sat, 03 Aug 2024 at 17:56:30 +0100, Simon McVittie wrote:
> Unfortunately, while [the patch I sent earlier] fixes the issue that
> Matthias reported, it
> doesn't seem to be a complete solution to making zsh build successfully:
> there are at least two other reasons why it fails to build from source
> with `debuild -B`, described below.

> Hang during build-time tests

> missing files: obj/Src/Modules/*.h

Applying the attached patch, in addition to the one I sent earlier, seems
to be enough to get a successful build on a porterbox by fixing both of
the new issues that I mentioned.

This is from upstream, but I found it by looking at Arch Linux's patchset;
thanks are due to Christian Hesse, one of Arch's zsh maintainers.

I believe both
52383-Avoid-incompatible-pointer-types-in-terminfo-global.patch
(commit ab4d62eb975a4c4c51dd35822665050e2ddc6918 upstream) and
50641-use-int-main-in-test-C-codes-in-configure.patch
(commit 4c89849c98172c951a9def3690e8647dae76308f upstream)
are necessary.

smcv
From: Nicholas Vinson 
Date: Wed, 21 Sep 2022 09:22:11 +0900
Subject: 50641: use 'int main()' in test C-codes in configure

Origin: upstream, commit:ab4d62eb975a4c4c51dd35822665050e2ddc6918
Bug-Debian: https://bugs.debian.org/1075708
---
 aczsh.m4 | 64 -
 configure.ac | 94 ++--
 2 files changed, 72 insertions(+), 86 deletions(-)

diff --git a/aczsh.m4 b/aczsh.m4
index d2a47ba..27cc260 100644
--- a/aczsh.m4
+++ b/aczsh.m4
@@ -44,6 +44,7 @@ AC_DEFUN(zsh_64_BIT_TYPE,
 #include 
 #endif
 
+int
 main()
 {
   $1 foo = 0; 
@@ -118,7 +119,6 @@ AC_TRY_COMMAND($DLLD -o conftest1.$DL_EXT $LDFLAGS $DLLDFLAGS conftest1.o $LIBS
 AC_TRY_COMMAND($CC -c $CFLAGS $CPPFLAGS $DLCFLAGS conftest2.c 1>_MESSAGE_LOG_FD) &&
 AC_TRY_COMMAND($DLLD -o conftest2.$DL_EXT $LDFLAGS $DLLDFLAGS conftest2.o $LIBS 1>_MESSAGE_LOG_FD); then
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
-#include 
 #ifdef HPUX10DYNAMIC
 #include 
 #define RTLD_LAZY BIND_DEFERRED
@@ -146,29 +146,30 @@ char *zsh_gl_sym_addr ;
 #define RTLD_GLOBAL 0
 #endif
 
+int
 main()
 {
 void *handle1, *handle2;
 void *(*zsh_getaddr1)(), *(*zsh_getaddr2)();
 void *sym1, *sym2;
 handle1 = dlopen("./conftest1.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle1) exit(1);
+if(!handle1) return(1);
 handle2 = dlopen("./conftest2.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle2) exit(1);
+if(!handle2) return(1);
 zsh_getaddr1 = (void *(*)()) dlsym(handle1, "${us}zsh_getaddr1");
 zsh_getaddr2 = (void *(*)()) dlsym(handle2, "${us}zsh_getaddr2");
 sym1 = zsh_getaddr1();
 sym2 = zsh_getaddr2();
-if(!sym1 || !sym2) exit(1);
-if(sym1 != sym2) exit(1);
+if(!sym1 || !sym2) return(1);
+if(sym1 != sym2) return(1);
 dlclose(handle1);
 handle1 = dlopen("./conftest1.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle1) exit(1);
+if(!handle1) return(1);
 zsh_getaddr1 = (void *(*)()) dlsym(handle1, "${us}zsh_getaddr1");
 sym1 = zsh_getaddr1();
-if(!sym1) exit(1);
-if(sym1 != sym2) exit(1);
-exit(0);
+if(!sym1) return(1);
+if(sym1 != sym2) return(1);
+return(0);
 }
 ]])],[zsh_cv_shared_$1=yes],
 [zsh_cv_shared_$1=no],
@@ -200,7 +201,6 @@ AC_TRY_COMMAND($DLLD -o conftest1.$DL_EXT $LDFLAGS $DLLDFLAGS conftest1.o $LIBS
 AC_TRY_COMMAND($CC -c $CFLAGS $CPPFLAGS $DLCFLAGS conftest2.c 1>_MESSAGE_LOG_FD) &&
 AC_TRY_COMMAND($DLLD -o conftest2.$DL_EXT $LDFLAGS $DLLDFLAGS conftest2.o $LIBS 1>_MESSAGE_LOG_FD); then
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
-#include 
 #ifdef HPUX10DYNAMIC
 #include 
 #define RTLD_LAZY BIND_DEFERRED
@@ -228,19 +228,19 @@ char *zsh_gl_sym_addr ;
 #define RTLD_GLOBAL 0
 #endif
 
-
+int
 main()
 {
 void *handle1, *handle2;
 int (*fred1)(), (*fred2)();
 handle1 = dlopen("./conftest1.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle1) exit(1);
+if(!handle1) return(1);
 handle2 = dlopen("./conftest2.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle2) exit(1);
+if(!handle2) return(1);
 fred1 = (int (*)()) dlsym(handle1, "${us}fred");
 fred2 = (int (*)()) dlsym(handle2, "${us}fred");
-if(!fred1 || !fred2) exit(1);
-exit((*fred1)() != 42 || (*fred2)() != 69);
+if(!fred1 || !fred2) return(1);
+return((*fred1)() != 42 || (*fred2)() != 69);
 }
 ]])],[zsh_cv_sys_dynamic_clash_ok=yes],
 [zsh_cv_sys_dynamic_clash_ok=no],
@@ -276,7 +276,6 @@ AC_TRY_COMMAND($DLLD -o conftest1.$DL_EXT $LDFLAGS $DLLDFLAGS conftest1.o $LIBS
 AC_TRY_COMMAND($CC -c $CFLAGS $CPPFLAGS $DLCFLAGS conftest2.c 1>_MESSAGE_LOG_FD) &&
 AC_TRY_COMMAND($DLLD -o conftest2.$DL_EXT $LDFLAGS $DLLDFLAGS conftest2.o $LIBS 1>_MESSAGE_LOG_FD); then
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
-#include 
 #ifdef HPUX10DYNAMIC
 #include 
 #define RTLD_LAZY BIND_DEFERRED
@@ -304,17 +303,18 @@ char *zsh_gl_sym_addr ;
 #define RTLD_GLOBAL 0
 #endif
 
+int
 main()
 {
 void

Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building

On Sat, 03 Aug 2024 at 09:28:06 +0200, Niels Thykier wrote:
> Helmut Grohne:
> > Writing tests is a bit non-trivial. Whilst Ubuntu has pioneered an
> > autopkgtest extension for cross architecture testing, this does not seem
> > to be available in Debian. Testing the native case is rather boring in
> > my view. As for manual testing, I verified that :amd64 (natively), :i386
> > (without installing qemu), and :armhf (qemu) work as expected on amd64.
> 
> It would be boring to test the native flow, but it would still assert that
> the code minimally works. Therefore, I think we should have that test case.

If we want packages like gobject-introspection to be able to rely on using
the cross-exe-wrapper unconditionally, then it's important that it's
reliable in the trivial case (build arch = host arch), so I think automated
test coverage for that trivial case would still be worth having.

For cross-architecture autopkgtest, reviewing the latest revision of
Ubuntu's autopkgtest MR is on my list, but my list is not short. I spent
some time on reviewing earlier versions of that MR, and my conclusion at
the time was that they weren't ready, but hopefully the latest version is
in a better state.

smcv

Bug#1073960: RFS: libmobi/0.12+dfsg-1 [RC] -- Tools for handling Mobipocket/Kindle ebook format documents

2024-08-03 Thread Bartek Fabiszewski

On Fri, 2 Aug 2024 11:00:07 +0200 Gianfranco Costamagna 
 wrote:
> sponsored, thanks you all!

Thank you!

Best,
Bartek

Bug#1077868: vips: link to jemalloc ?

2024-08-03 Thread Jérémy Lal

Source: vips
Version: 8.15.2-1
Severity: wishlist

Hi,

it seems vips and/or sharp perform better with jemalloc:

https://github.com/libvips/libvips/issues/1064
https://github.com/lovell/sharp/issues/955
https://github.com/lovell/sharp/issues/2607
https://github.com/libvips/libvips/blob/master/doc/Developer-checklist.md#linux-memory-allocator

Upstream doesn't require it because they want to keep their software compatible 
with other platforms.
Maybe the vips debian package could link to jemalloc when possible.
pkg-config --libs jemalloc

Not sure it's worth the trouble, but at least some debian packages are using 
jemalloc.

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

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

Bug#1075708: zsh: FTBFS with GCC-14

On Wed, 03 Jul 2024 at 12:50:04 +, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13.
...
> ../../../Src/Modules/termcap.c:45:14: error: conflicting types for 
> ‘boolcodes’; have ‘char *[]’
>45 | static char *boolcodes[] = {
>   |  ^
> In file included from ../../Src/zshterm.h:1,
>  from ../../../Src/zsh_system.h:932,
>  from ./../../Src/zsh.mdh:15,
>  from ./termcap.mdh:15,
>  from ../../../Src/Modules/termcap.c:38:
> /usr/include/term.h:783:56: note: previous declaration of ‘boolcodes’ with 
> type ‘const char * const[]’
>   783 | extern NCURSES_EXPORT_VAR(NCURSES_CONST char * const ) boolcodes[];
>   |^

Please consider applying the attached patch, taken from upstream git.
gcc 14 also produces several compiler warnings which I think would be
useful to look into, but those don't break the build and hopefully don't
indicate serious bugs.

I tried compiling this in my usual build environment (sbuild inside
an amd64 Debian 12 VM) and on the amd64 porterbox barriere, and the
dh_auto_build step finishes successfully.

Unfortunately, while this patch fixes the issue that Matthias reported, it
doesn't seem to be a complete solution to making zsh build successfully:
there are at least two other reasons why it fails to build from source
with `debuild -B`, described below.

`debuild -A` (Architecture: all only) does succeed with the attached
patch.

Hang during build-time tests

During dh_auto_test, the test hangs for a significant time, with no
obvious CPU load, and this output:

>debian/rules override_dh_auto_test-arch
> make[1]: Entering directory '/home/smcv/zsh'
> if dpkg-architecture -qDEB_BUILD_ARCH_OS | grep -qv hurd; then \
> HOME="/home/smcv/zsh/obj/testhome" ZTST_verbose=1 dh_auto_test -B 
> obj; \
> fi
> cd obj && make -j4 test "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1
> make[2]: Entering directory '/home/smcv/zsh/obj'
> cd Test ; make check
> make[3]: Entering directory '/home/smcv/zsh/obj/Test'
> if test -n "ld"; then \
>   cd .. && DESTDIR= \
>   make MODDIR=`pwd`/Test/Modules install.modules > /dev/null; \
> fi
> if test -z "$ZTST_handler"; then \
>   ZTST_handler=runtests.zsh; \
> fi; \
> if ZTST_testlist="`for f in ../../Test/*.ztst; \
>do echo $f; done`" \
>  ZTST_srcdir="../../Test" \
>  ZTST_exe=../Src/zsh \
>  ../Src/zsh +Z -f ../../Test/$ZTST_handler; then \
>  stat=0; \
> else \
>  stat=1; \
> fi; \
> sleep 1; \
> rm -rf Modules .zcompdump; \
> exit $stat
> ../../Test/A01grammar.ztst: starting.
> Running test: Test skipping if ZTST_test_skip is set

This is reproducible on barriere.

I see that there is already a patch applied,
debian/patches/further-mitigate-test-suite-hangs.patch.
Perhaps it will be necessary to further further mitigate test-suite hangs...

Or perhaps the affected tests could be skipped without harming coverage
too much?

missing files: obj/Src/Modules/*.h
==

If I skip the build-time tests with DEB_BUILD_OPTIONS=nocheck, instead
I get this build failure:

>dh_install
> dh_install: warning: Cannot find (any matches for) "obj/Src/Modules/*.h" 
> (tried in ., debian/tmp)
>
> dh_install: warning: zsh-dev missing files: obj/Src/Modules/*.h
> dh_install: error: missing files, aborting

This is also reproducible on barriere. I don't know what has changed to
stop these headers from being generated.

I'm sorry I couldn't fully fix the build of this package, but I hope the
patch I attached is a useful step in the right direction.

smcv
From: Florian Weimer 
Date: Fri, 8 Dec 2023 21:58:07 +0100
Subject: 52383: Avoid incompatible pointer types in terminfo global variable
 checks

Origin: upstream, commit:https://sourceforge.net/p/zsh/code/ci/4c89849c98172c951a9def3690e8647dae76308f/
Bug-Debian: https://bugs.debian.org/1075708
---
 configure.ac | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index f810052..928b467 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1771,27 +1771,27 @@ if test x$zsh_cv_path_term_header != xnone; then
   fi

   AC_MSG_CHECKING(if boolcodes is available)
-  AC_LINK_IFELSE([AC_LANG_PROGRAM([[$term_includes]], [[char **test = boolcodes; puts(*test);]])],[AC_DEFINE(HAVE_BOOLCODES) boolcodes=yes],[boolcodes=no])
+  AC_LINK_IFELSE([AC_LANG_PROGRAM([[$term_includes]], [[char **test = (char **)boolcodes; puts(*test);]])],[AC_DEFINE(HAVE_BOOLCODES) boolcodes=yes],[boolcodes=no])
   AC_MSG_RESULT($boolcodes)

   AC_MSG_CHECKING(if numcodes is available)
-  AC_LINK_IFELSE([AC_LANG_PROGRAM([[$term_includes]], [[char **test = numcodes; puts(*test);]])],[AC_DEFINE(HAVE_NUMCODES) numcodes=yes],[numcodes=no])
+

Bug#1077863: base-files: libx32 is not checked in preinst

2024-08-03 Thread Santiago Vila


forwarded 1077863 Helmut Grohne 
forwarded 1077866 Helmut Grohne 
thanks

El 3/8/24 a las 17:29, Chris Hofstaedtler escribió:

debian/preinst gained a check for the /lib* symlinks. I think a
copy-paste error slipped in. Please consider the patch below.


Thanks for the report and also for the x-debbugs-cc.
I'm therefore marking this and the other bug as being already "forwarded".

Helmut: Ok to apply this patch now? The current version in unstable
is only two days old in its way to testing, and I guess that the other
bug might take more than five days to be analyzed and fixed.

(Maybe I'll update some lintian override here and there
while we are at it)

Thanks.

Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?

Paul Gevers:

Hi,

On 03-08-2024 11:55, Niels Thykier wrote:
Since the non-free is entirely opt-in and you had to be very active
about opt'ing in as a admin, this seem fine. With the change to
non-free-firmware now being enabled by d-i by default, we now have
non-free-firmware packages installed by default that can use this
opt-out and for me, that changes the game a bit.

I totally agree.

I have not checked whether all non-free-firmware is auto-buildable

It would be good if we had the answer to this question, because changing
britney2 to do the check for all binaries is trivial [1], and adding a
hint explicitly for those that aren't auto-buildable seems maintainable
(there are currently only 15 sources in non-free-firmware in sid).

Paul

[1]
https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/policy.py?ref_type=heads#L1543

Had a quick look at the testing `Sources` file for non-free-firmware. We
are 10/15 on `Autobuild: yes` with remaining 5 not having the header.

No clue whether they could get that or we have to compromise already
here. Though, even if they can, there is also the aspect of whether we
are ready to commit to all new firmware being `Autobuild: yes`. I
figured `d-boot` might have an opinion on that (which is why I have
CC'ed them on this bug).

The 5 that are not `Autobuild: yes` would be:

atmel-firmware
bluez-firmware
dahdi-firmware
live-tasks-non-free-firmware
midisport-firmware

(as far as my wetware was able to eyeball)

Best regards,
Niels

Bug#1077817: chirp: Reading from Quansheng causes logout

2024-08-03 Thread Hilary Snaden


Hi, thanks for the prompt response.

I meant the Python wheel package from chirpmyradio.com, dated 20240706, 
using the instructions there (pipx).


My Quanshengs still have their factory firmware, I didn't want to try 
alternatives until I had a backup, and the memories the way I want them.


On 2024-08-03 14:20, Dave Hibberd wrote:

Hi there, thanks for the bug! I’ll replicate it this afternoon and upload the 
latest one as there’s been a few updates to that driver since the last upload 
[1].

When you say the current version installed by python, do you mean installed via 
`pip3 install chirp`?

Are you running the regular firmware or another like egzumer?

[1] 
https://chirp.danplanet.com/projects/chirp/repository/github/changes/chirp/drivers/uvk5.py?rev=master

Cheers,

--
   Hibby
   Debian Developer
   Packet Radioist
   MM0RFN


On 2 Aug 2024, at 19:05, Hilary Snaden  wrote:

Package: chirp
Version: 1:20240413-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: hilary.sna...@zoho.com

Dear Maintainer,

Attempting to read the contents of two Quansheng UV-K5(8) transcievers has 
causes logout, using the Debian package version and the current version 
installed from Python, and on two different laptops running Debian. The 
software still works normally with older Baofeng transcievers.

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

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

Versions of packages chirp depends on:
ii  python3   3.12.3-1
ii  python3-requests  2.32.3+dfsg-1
ii  python3-serial3.5-2
ii  python3-six   1.16.0-7
ii  python3-yattag1.15.2-1
ii  wxpython-tools4.2.1+dfsg-4

Versions of packages chirp recommends:
ii  python3-suds  1.1.2-1

chirp suggests no packages.

-- no debconf information

Bug#1077852: plfit-doc contains a /CONTRIBUTORS.txt

2024-08-03 Thread Santiago Vila


tags 1077852 + patch
thanks

El 3/8/24 a las 14:24, Jochen Sprickerhof escribió:

the plfit-doc contains a CONTRIBUTORS.txt in the root directory. I guess
it should be in /usr/share/doc/plfit/ or somewhere.


Big oops! I'm surprised that ftpmasters do not have a lintian check to reject
something like that. Maybe file-in-unusual-directory is too weak and
we need another check like file-in-root-directory.

Anyway, trivial patch attached.

Jerome: I leave this to you, since you are the usual uploader,
but if you prefer, I could fix this via Team Upload.

Thanks.
diff --git a/debian/plfit-doc.install b/debian/plfit-doc.install
index 30493f8..2231586 100644
--- a/debian/plfit-doc.install
+++ b/debian/plfit-doc.install
@@ -1,4 +1,4 @@
 test/*.h test/*.c debian/adhoc/examples/tests/* 
usr/share/doc/plfit/examples/tests
 test/*.py debian/adhoc/examples/pytests/* usr/share/doc/plfit/examples/pytests
 doc/THANKS usr/share/doc/plfit
-CONTRIBUTORS.txt
+CONTRIBUTORS.txt usr/share/doc/plfit

Bug#1003395: plfit FTBFS on s390x

2024-08-03 Thread Santiago Vila


close 1003395 0.9.5+ds-1
thanks

Hello.

This was fixed upstream and there is apparently no need to apply
any patch anymore.

I've written the long explanation in the github issue:

https://github.com/ntamas/plfit/issues/38

TLDR: It was fixed by the line in src/CMakeLists.txt saying this:

target_link_libraries(plfit ${MATH_LIBRARY})

Cc:ing all relevant parties.

Thanks.

Bug#1077867: etcd: autopkgtest issues: appears flaky and fails on amd64 since August 2023


Source: etcd
Version: 3.4.23-4
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on ci.d.n 
since August 2023 and seems to fail randomly on several other 
architectures too. Can you please investigate the situation and fix it? 
I copied some of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/e/etcd/testing/amd64/49786214/

884s === RUN   TestAuthority/Size:_3,_Scenario:_"https://address[:port];
884s ctl_v3_grpc_test.go:146:
884s 	Error Trace: 
/tmp/autopkgtest-lxc.0vhkw0u4/downtmp/build.vZi/src/_build/src/go.etcd.io/etcd/tests/e2e/ctl_v3_grpc_test.go:146
884s 				 
/tmp/autopkgtest-lxc.0vhkw0u4/downtmp/build.vZi/src/_build/src/go.etcd.io/etcd/tests/e2e/ctl_v3_grpc_test.go:112
884s 				 
/tmp/autopkgtest-lxc.0vhkw0u4/downtmp/build.vZi/src/_build/src/go.etcd.io/etcd/tests/e2e/ctl_v3_grpc_test.go:154

884s
/usr/lib/go-1.22/src/runtime/asm_amd64.s:1695
884sError:  Should be true
884s 	Test: 
TestAuthority/Size:_3,_Scenario:_"https://address[:port];
884s 	Messages:   	Got "2024-07-30 09:28:41.880058 I | http2: 
decoded hpack field header field \":authority\" = \"127.0.0.1:2\"" 
expected suffix "http2: decoded hpack field header field \":authority\" 
= \"127.0.0.1:20005\""

884s ctl_v3_grpc_test.go:146:
884s 	Error Trace: 
/tmp/autopkgtest-lxc.0vhkw0u4/downtmp/build.vZi/src/_build/src/go.etcd.io/etcd/tests/e2e/ctl_v3_grpc_test.go:146
884s 				 
/tmp/autopkgtest-lxc.0vhkw0u4/downtmp/build.vZi/src/_build/src/go.etcd.io/etcd/tests/e2e/ctl_v3_grpc_test.go:112
884s 				 
/tmp/autopkgtest-lxc.0vhkw0u4/downtmp/build.vZi/src/_build/src/go.etcd.io/etcd/tests/e2e/ctl_v3_grpc_test.go:154

884s
/usr/lib/go-1.22/src/runtime/asm_amd64.s:1695
884sError:  Should be true
884s 	Test: 
TestAuthority/Size:_3,_Scenario:_"https://address[:port];
884s 	Messages:   	Got "2024-07-30 09:28:41.897491 I | http2: 
decoded hpack field header field \":authority\" = \"127.0.0.1:2\"" 
expected suffix "http2: decoded hpack field header field \":authority\" 
= \"127.0.0.1:20010\""

884s --- FAIL: TestAuthority (40.15s)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077864: gnome-core: lower dependency to gnome-themes-extra

2024-08-03 Thread Jeremy Bícha

On Sat, Aug 3, 2024 at 11:36 AM Patrice Duroux  wrote:
> gnome-themes-extra is described as 'Adwaita GTK 2 theme - engine'
> and it would be nice to be able to remove some unused GTK 2 packages
> without removing gnome-core itself.

I guess we could have libgtk2.0-0t64 Recommend gnome-themes-extra
instead. It can't be a Depends there without causing a circular
dependency.

I agree that ideally a new Debian 13 install should not install gtk2.
(gtk2 is still used by the Debian Installer though.)

Thank you,
Jeremy Bícha

Bug#1077866: base-files: need workaround for incorrect /lib64 symlink

Package: base-files
Version: 13.4
X-Debbugs-CC: hel...@subdivi.de

It was discovered that some versions of systemd and systemd-nspawn
install a /lib64 symlink [1], pointing to /usr/lib/. This is
wrong.

Regardless of systemd doing the wrong thing here, the preinst check
fails when the wrong link exists.

base-files might need to apply a workaround, possibly fixing up the
symlink.

Most reports of this problem were about arm64 systems, but it is
unclear (to me) if the problem is really limited to such systems.

A discussion about what to do for base-files would be good, thus
filing this bug.

Chris


[1] https://github.com/systemd/systemd/issues/33919

Bug#1077804: adduser autopkgtest assumes backslash is a valid char

* Marc Haber  [240803 15:20]:
> On Fri, Aug 02, 2024 at 05:18:54PM +0200, Chris Hofstaedtler wrote:
> > in #1076619 it was reported that usernames ending with backslashes
> > break useradd/usermod/userdel, etc (from src:shadow).
> > Allowing backslashes was a Debian patch. To fix #1076619,
> > backslashes are now forbidden. However, adduser's autopkgtests
> > assume that backslashes are good to use.
> 
> Is that change in the allowed user names backed by policy?

ISTM we don't have a policy for that.

> We allow backslashes in adduser to cater for some samba corner
> cases where a user named domain\user is needed.
> 
> I am kind of concerned that this tightening of src:shadow's allowed usr
> name character ranges breaks actual use cases.

Some time ago I surveyed the patches other distros apply to shadow,
and none seem to patch the quite restrictive upstream check.

> > Please stop using backslashes.
> 
> Will do but are you sure you're doing the right thing here?

Honestly, no.

src:shadow is in a quite bad state and upstream is at the start of a
long journey of cleaning that up. Until this is done, it seems
anything we do downstream has a good chance of exposing latent bugs.

I think the checks in shadow's user* tools can be bypassed by
passing --badname. Maybe the broken tests in adduser should do that
instead of being dropped.

(IMO, users passing --badname can keep any breakage.)

> Should src:adduser also adapt the regexes that define allowed characters
> in user names?

I think it would be great to align on the check from shadow
upstream. Currently it is documented as:

 * User/group names must match BRE regex:
 *[a-zA-Z0-9_.][a-zA-Z0-9_.-]*$\?
 *
 * as a non-POSIX, extension, allow "$" as the last char for
 * sake of Samba 3.x "add machine script"
 *
 * Also do not allow fully numeric names or just "." or "..".

That seems reasonable to me.

Let me know what you think.

Best,
Chris

Bug#1077865: rust-impl-trait-for-tuples: autopkgtest regression: thread 'fail' panicked at /usr/share/cargo/registry/trybuild-1.0.91/src/run.rs:101:13:


Source: rust-impl-trait-for-tuples
Version: 0.2.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails since around 
mid June 2024. Can you please investigate the situation and fix it? I 
copied some of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/r/rust-impl-trait-for-tuples/testing/amd64/49859746/

 97s running 1 test
 97s  Locking 6 packages to latest compatible versions
 97s   Adding syn v1.0.109 (latest: v2.0.68)
 97sCompiling proc-macro2 v1.0.85
 97sCompiling syn v1.0.109
 97sCompiling unicode-ident v1.0.12
 98s Checking quote v1.0.36
103sCompiling impl-trait-for-tuples v0.2.2 
(/usr/share/cargo/registry/impl-trait-for-tuples-0.2.2)
106s Checking impl-trait-for-tuples-tests v0.0.0 
(/tmp/tmp.vh5cL6OSce/target/tests/trybuild/impl-trait-for-tuples)

106s Finished `dev` profile [unoptimized + debuginfo] target(s) in 8.87s
106s
106s
106s test tests/fail/custom_trait_bound_invalid.rs ... mismatch
106s
106s EXPECTED:
106s 
106s error: Invalid trait bound: unexpected token
106s   --> tests/fail/custom_trait_bound_invalid.rs:14:40
106s|
106s 14 | #[tuple_types_custom_trait_bound(Custom, Clone)]
106s|^
106s
106s error[E0277]: the trait bound `(Impl, Impl): Test` is not satisfied
106s   --> tests/fail/custom_trait_bound_invalid.rs:32:12
106s|
106s 32 | test::<(Impl, Impl)>();
106s| the trait `Test` is not implemented 
for `(Impl, Impl)`

106s|
106s note: required by a bound in `test`
106s   --> tests/fail/custom_trait_bound_invalid.rs:30:12
106s|
106s 30 | fn test() {}
106s| required by this bound in `test`
106s
106s error[E0277]: the trait bound `(Impl, Impl, Impl): Test` is not 
satisfied

106s   --> tests/fail/custom_trait_bound_invalid.rs:33:12
106s|
106s 33 | test::<(Impl, Impl, Impl)>();
106s|^^ the trait `Test` is not 
implemented for `(Impl, Impl, Impl)`

106s|
106s note: required by a bound in `test`
106s   --> tests/fail/custom_trait_bound_invalid.rs:30:12
106s|
106s 30 | fn test() {}
106s| required by this bound in `test`
106s 
106s
106s ACTUAL OUTPUT:
106s 
106s error: Invalid trait bound: unexpected token
106s   --> tests/fail/custom_trait_bound_invalid.rs:14:40
106s|
106s 14 | #[tuple_types_custom_trait_bound(Custom, Clone)]
106s|^
106s
106s error[E0277]: the trait bound `(Impl, Impl): Test` is not satisfied
106s   --> tests/fail/custom_trait_bound_invalid.rs:32:12
106s|
106s 32 | test::<(Impl, Impl)>();
106s| the trait `Test` is not implemented 
for `(Impl, Impl)`

106s|
106s help: this trait has no implementations, consider adding one
106s   --> tests/fail/custom_trait_bound_invalid.rs:1:1
106s|
106s 1  | trait Test {
106s| ^^
106s note: required by a bound in `test`
106s   --> tests/fail/custom_trait_bound_invalid.rs:30:12
106s|
106s 30 | fn test() {}
106s| required by this bound in `test`
106s
106s error[E0277]: the trait bound `(Impl, Impl, Impl): Test` is not 
satisfied

106s   --> tests/fail/custom_trait_bound_invalid.rs:33:12
106s|
106s 33 | test::<(Impl, Impl, Impl)>();
106s|^^ the trait `Test` is not 
implemented for `(Impl, Impl, Impl)`

106s|
106s help: this trait has no implementations, consider adding one
106s   --> tests/fail/custom_trait_bound_invalid.rs:1:1
106s|
106s 1  | trait Test {
106s| ^^
106s note: required by a bound in `test`
106s   --> tests/fail/custom_trait_bound_invalid.rs:30:12
106s|
106s 30 | fn test() {}
106s| required by this bound in `test`
106s 
106s note: If the actual output is the correct output you can bless it 
by rerunning

106s   your test with the environment variable TRYBUILD=overwrite
106s
106s test tests/fail/trait_bound_not_added.rs ... ok
106s test tests/fail/tuple_impls_less_than_minimum_does_not_exists.rs ... ok
106s
106s
106s test fail ... FAILED
106s
106s failures:
106s
106s  fail stdout 
106s thread 'fail' panicked at 
/usr/share/cargo/registry/trybuild-1.0.91/src/run.rs:101:13:

106s 1 of 3 tests failed

Bug#1077864: gnome-core: lower dependency to gnome-themes-extra

2024-08-03 Thread Patrice Duroux

Package: gnome-core
Version: 1:46+2
Severity: wishlist

Dear Maintainer,

gnome-themes-extra is described as 'Adwaita GTK 2 theme - engine'
and it would be nice to be able to remove some unused GTK 2 packages
without removing gnome-core itself.

Thanks,
Patrice


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

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

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme46.0-1
ii  at-spi2-core  2.52.0-1
ii  baobab46.0-1
ii  dconf-cli 0.40.0-4+b2
ii  dconf-gsettings-backend   0.40.0-4+b2
ii  eog   45.3-1
ii  evince46.3.1-1
ii  evolution-data-server 3.53.2-1
ii  fonts-inter-variable  4.0+ds-2
ii  gdm3  46.2-1
ii  gkbd-capplet  3.28.1-1+b1
ii  glib-networking   2.80.0-1
ii  gnome-backgrounds 46.0-1
ii  gnome-bluetooth-sendto46.0-1
ii  gnome-calculator  1:46.1-1
ii  gnome-characters  46.0-1
ii  gnome-console 46.0-1
ii  gnome-contacts46.0-2
ii  gnome-control-center  1:46.3-1
ii  gnome-disk-utility46.0-1+b3
ii  gnome-font-viewer 46.0-1
ii  gnome-keyring 46.1-2
ii  gnome-logs45.0-1
ii  gnome-menus   3.36.0-1.1+b2
ii  gnome-online-accounts 3.50.2-1
ii  gnome-session 46.0-5
ii  gnome-settings-daemon 46.0-5
ii  gnome-shell   46.3.1-4
ii  gnome-shell-extensions46.2-3
ii  gnome-software46.3-1
ii  gnome-sushi   46.0-1
ii  gnome-system-monitor  46.0-1
ii  gnome-terminal3.52.2-1
ii  gnome-text-editor 46.3-1
pn  gnome-themes-extra
ii  gnome-user-docs   46.1-1
ii  gnome-user-share  47~alpha-1
ii  gsettings-desktop-schemas 47~beta-1
ii  gstreamer1.0-packagekit   1.3.0-1
ii  gstreamer1.0-plugins-base 1.24.6-1
ii  gstreamer1.0-plugins-good 1.24.6-1
ii  gvfs-backends 1.54.2-2
ii  gvfs-fuse 1.54.2-2
ii  libatk-adaptor2.52.0-1
ii  libcanberra-pulse 0.30-17
ii  libglib2.0-bin2.81.1-3
ii  libpam-gnome-keyring  46.1-2
ii  libproxy1-plugin-gsettings0.5.7-1
ii  libproxy1-plugin-webkit   0.5.7-1
ii  librsvg2-common   2.58.0+dfsg-1
ii  nautilus  46.2-3
ii  pipewire-audio1.2.2-1
ii  sound-theme-freedesktop   0.8-3
ii  system-config-printer-common  1.5.18-3
ii  system-config-printer-udev1.5.18-3
ii  totem 43.0-3+b1
ii  tracker   3.7.3-2
ii  xdg-desktop-portal-gnome  46.2-3
ii  yelp  42.2-1+b2
ii  zenity4.0.2-1

Versions of packages gnome-core recommends:
ii  chromium [gnome-www-browser] 127.0.6533.88-1
ii  firefox [gnome-www-browser]  128.0.3-2
ii  fonts-cantarell  0.303.1-2
ii  libproxy1-plugin-networkmanager  0.5.7-1
ii  low-memory-monitor   2.1-2+b1
ii  network-manager-gnome1.36.0-1

Versions of packages gnome-core suggests:
ii  gnome  1:46+2

-- no debconf information

Bug#1077038: ipwatchd: introduces aliased file /lib/systemd/system/ipwatchd.service (DEP17)

2024-08-03 Thread YunQiang Su

在 2024-08-03星期六的 13:31 +0200，Michael Biebl写道：
> On Thu, 25 Jul 2024 14:05:44 +0200 Helmut Grohne 
> wrote:
> > Package: ipwatchd
> > Version: 1.3.0-1+nmu1
> > Severity: serious
> > Justification: do not introduce aliased files into trixie
> > X-Debbugs-Cc: YunQiang Su 
> > User: helm...@debian.org
> > Usertags: dep17m2
> > Filename: /lib/systemd/system/ipwatchd.service
> > 
> > Hi,
> > 

I am planing to upload a new version with this debdiff.
Any idea?
diff -Nru ipwatchd-1.3.0/debian/changelog ipwatchd-1.3.0/debian/changelog
--- ipwatchd-1.3.0/debian/changelog	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/changelog	2024-08-03 23:10:58.0 +0800
@@ -1,3 +1,14 @@
+ipwatchd (1.3.0-1+nmu2) unstable; urgency=medium
+
+  * Build-depends on dh-sequence-movetousr to install systemd service to
+/usr/lib instead of /lib.  Closes: #1077038.
+  * Rewrite debian/rules with debhelper 7 override style.
+  * Pre-Depends on ${misc:Pre-Depends} instead of hardcoded
+init-system-helpers (>= 1.66).
+  * Refresh patch with -p ab --no-timestamps --no-index. 
+
+ -- YunQiang Su   Sat, 03 Aug 2024 23:10:58 +0800
+
 ipwatchd (1.3.0-1+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ipwatchd-1.3.0/debian/control ipwatchd-1.3.0/debian/control
--- ipwatchd-1.3.0/debian/control	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/control	2024-08-03 23:07:12.0 +0800
@@ -2,13 +2,13 @@
 Section: net
 Priority: optional
 Maintainer: Jaroslav Imrich 
-Build-Depends: debhelper-compat (= 13), libpcap-dev, libnet1-dev
+Build-Depends: debhelper-compat (= 13), dh-sequence-movetousr, libpcap-dev, libnet1-dev
 Standards-Version: 3.9.2
 Homepage: http://ipwatchd.sf.net
 
 Package: ipwatchd
 Architecture: linux-any
-Pre-Depends: init-system-helpers (>= 1.66)
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: IP conflict detection tool
  IPwatchD is a simple daemon that analyses all incoming ARP packets in order
diff -Nru ipwatchd-1.3.0/debian/patches/fix-cflags.diff ipwatchd-1.3.0/debian/patches/fix-cflags.diff
--- ipwatchd-1.3.0/debian/patches/fix-cflags.diff	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/patches/fix-cflags.diff	2024-08-03 23:10:58.0 +0800
@@ -1,7 +1,5 @@
-Index: ipwatchd-1.3.0/src/Makefile
-===
 ipwatchd-1.3.0.orig/src/Makefile
-+++ ipwatchd-1.3.0/src/Makefile
+--- a/src/Makefile
 b/src/Makefile
 @@ -1,8 +1,8 @@
  # IPwatchD - IP conflict detection tool for Linux
  # Copyright (C) 2007-2018 Jaroslav Imrich 
diff -Nru ipwatchd-1.3.0/debian/rules ipwatchd-1.3.0/debian/rules
--- ipwatchd-1.3.0/debian/rules	2024-07-14 17:59:30.0 +0800
+++ ipwatchd-1.3.0/debian/rules	2024-08-03 23:03:12.0 +0800
@@ -1,60 +1,19 @@
 #!/usr/bin/make -f
-# -*- makefile -*-
+include /usr/share/dpkg/buildtools.mk
 
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
-export DEB_BUILD_MAINT_OPTIONS=hardening=+all
-
-build: build-stamp
-
-build-stamp: 
-	dh_testdir
-	CPPFLAGS=`dpkg-buildflags --get CPPFLAGS` \
-	CFLAGS="`dpkg-buildflags --get CFLAGS` $$CPPFLAGS" \
-	LDFLAGS=`dpkg-buildflags --get LDFLAGS` \
-	CC=$(DEB_HOST_GNU_TYPE)-gcc \
-	   $(MAKE) -C src
-	touch $@
-
-# Added just to remove lintian warning debian-rules-missing-recommended-target
-build-arch build-indep: build
-
-clean: 
-	dh_testdir
-	dh_testroot
-	rm -f build-stamp configure-stamp
+export DH_VERBOSE = 1
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export CC
+
+%:
+	dh $@
+
+override_dh_auto_clean:
 	$(MAKE) -C src distclean
-	dh_clean 
 
-install: build
-	dh_testdir
-	dh_testroot
-	dh_prep  
-	dh_installdirs
+override_dh_auto_build:
+	CFLAGS="$(CFLAGS) $(CPPFLAGS)" $(MAKE) -C src
+
+override_dh_auto_install:
 	$(MAKE) -C src DESTDIR=$(CURDIR)/debian/ipwatchd install
-	# Remove upstream manpages causing lintian error manpage-not-compressed-with-max-compression
-	rm $(CURDIR)/debian/ipwatchd/usr/share/man/man1/ipwatchd-script.1.gz
-	rm $(CURDIR)/debian/ipwatchd/usr/share/man/man5/ipwatchd.conf.5.gz
-	rm $(CURDIR)/debian/ipwatchd/usr/share/man/man8/ipwatchd.8.gz
-
-binary-indep: install
-
-binary-arch: install
-	dh_testdir
-	dh_testroot
-	dh_installchangelogs 
-	dh_installdocs
-	dh_installman debian/ipwatchd.8 debian/ipwatchd.conf.5 debian/ipwatchd-script.1
-	dh_installinit
-	dh_link
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_shlibdeps
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
 
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure

Bug#1077863: base-files: libx32 is not checked in preinst

Package: base-files
Version: 13.4
X-Debbugs-CC: hel...@subdivi.de

Hi,

debian/preinst gained a check for the /lib* symlinks. I think a
copy-paste error slipped in. Please consider the patch below.

Chris


--- debian/preinst~ 2024-08-03 17:27:23.517818410 +0200
+++ debian/preinst  2024-08-03 17:27:30.797464260 +0200
@@ -3,7 +3,7 @@
 
 if [ "$1" = "install" ] || [ "$1" = "upgrade" ]; then
   msg=
-  for d in bin lib lib32 lib64 libo32 lib64 sbin; do
+  for d in bin lib lib32 lib64 libo32 libx32 sbin; do
 if [ -L "$DPKG_ROOT/$d" ]; then
   if [ "$(readlink "$DPKG_ROOT/$d")" != "usr/$d" ]; then
 msg="/$d is a symbolic link and not pointing at usr/$d exactly"

Bug#1077862: RM: murano-tempest-plugin -- ROM; EOL, buggy

2024-08-03 Thread Thomas Goirand

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: murano-tempest-plu...@packages.debian.org
Control: affects -1 + src:murano-tempest-plugin

Hi,

Murano isn't maintained anymore, and therefore, src:murano-tempest-plugin
should be removed from Debian as well. Please RM it.

Cheers,

Thomas Goirand (zigo)

Bug#1074357: freeorion: The connection to the server has been lost - libpython3.12.so.1.0 segfault

2024-08-03 Thread Davide Prina

Package: freeorion
Version: 0.5+git20230820-4+b3
Followup-For: Bug #1074357
X-Debbugs-Cc: davide.pr...@null.net

Dear Maintainer,

I have done some extra search.

# apt install coredumpctl
# ulimit -c unlimited
$ freeorion

I have the segfault

$ coredumpctl list
TIME   PID  UID  GID SIG COREFILE EXE   
SIZE
Sat 2024-07-20 12:41:44 CEST 19100 1000 1000 SIGSEGV none 
/usr/lib/freeorion/freeoriond-

$ coredumpctl info 19100
   PID: 19100 (freeoriond)
   UID: 1000 ($USER)
   GID: 1000 ($USER)
Signal: 11 (SEGV)
 Timestamp: Sat 2024-07-20 12:41:44 CEST (4min 11s ago)
  Command Line: $'"/usr/lib/freeorion/freeoriond"' --resource.path 
$'"/usr/share/games/freeorion/default"' --singleplayer --skip-checksum
Executable: /usr/lib/freeorion/freeoriond
 Control Group: /user.slice/user-1000.slice/session-2.scope
  Unit: session-2.scope
 Slice: user-1000.slice
   Session: 2
 Owner UID: 1000 ($USER)
   Boot ID: ea5ca9be3c614627978d041b2a262108
Machine ID: 157daffcbe2f71ce501fefa64b374535
  Hostname: $HOSTNAME
   Storage: none
   Message: Process 19100 (freeoriond) of user 1000 terminated abnormally 
without generating a coredump.


If I try to use gdb with this I get:

Coredump entry has no core attached (neither internally in the journal nor
externally on disk).


I have try to get some info, but the coredump was never generated. I also 
slow down freeorion and used gdb, but the segfault process go to zombi
state immediatly and I cannot get any info.


I see that also on Ubuntu there is the same bug open:
https://bugs.launchpad.net/ubuntu/+source/freeorion/+bug/2065925


I have found, with lsof, that the log files are not in .config/freeorion/
directory, but they are in .local/share/freeorion/freeorion.log and the
log don't have any more info than my previous report.



I have fount that if I download the 3.11.9-1 package from shapshost
https://snapshot.debian.org/archive/debian/20240410T203634Z/pool/main/p/python3.11/libpython3.11t64_3.11.9-1_amd64.deb

and replace the libpython3.12.so.1.0 library with the libpython3.11.so.1.0 
one the game work correctly


I have also try to set logs to debug and than trace for the freeorion server
but I don't have any more interesting info.
With debug option for freeoriond there are few line that are present also
with 3.11 python library. With strace it generate big log files, but I
haven't see anything.

Ciao
Davide


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

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

Versions of packages freeorion depends on:
ii  freeorion-data   0.5+git20230820-4
ii  libboost-filesystem1.83.01.83.0-3+b2
ii  libboost-iostreams1.83.0 1.83.0-3+b2
ii  libboost-locale1.83.01.83.0-3+b2
ii  libboost-log1.83.0   1.83.0-3+b2
ii  libboost-python1.83.0 [libboost-python1.83.0-py312]  1.83.0-3+b2
ii  libboost-serialization1.83.0 1.83.0-3+b2
ii  libboost-thread1.83.01.83.0-3+b2
ii  libc62.39-6
ii  libfreetype6 2.13.2+dfsg-1+b4
ii  libgcc-s114-20240330-1
ii  libglew2.2   2.2.0-4+b1
ii  libopenal1   1:1.23.1-4+b1
ii  libopengl0   1.7.0-1+b1
ii  libpng16-16t64   1.6.43-5
ii  libpython3.12t64 3.12.4-3
ii  libsdl2-2.0-02.30.5+dfsg-1
ii  libstdc++6   14-20240330-1
ii  libvorbis0a  1.3.7-2
ii  libvorbisfile3   1.3.7-2

freeorion recommends no packages.

freeorion suggests no packages.

-- no debconf information

Bug#1077861: src:python-csb43: fails to migrate to testing for too long: autopkgtest regression


Source: python-csb43
Version: 0.9.2+dfsg-1
Severity: serious
Control: close -1 0.10.0+dfsg-1
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:python-csb43 has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
fails its own autopkgtest.


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=python-csb43



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077860: src:r-cran-tmb: fails to migrate to testing for too long: triggers autopkgtest issues


Source: r-cran-tmb
Version: 1.9.11-2
Severity: serious
Control: close -1 1.9.13-1
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:r-cran-tmb has been trying to migrate for 
32 days [2]. Hence, I am filing this bug. The version in unstable causes 
autopkgtest failure in r-cran-glmmtmb.


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=r-cran-tmb



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077859: src:rocm-hipamd: fails to migrate to testing for too long: uploader built arch:all binaries


Source: rocm-hipamd
Version: 5.7.1-3
Severity: serious
Control: close -1 5.7.1-4
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:rocm-hipamd has been trying to migrate for 
32 days [2]. Hence, I am filing this bug. The upload of the version in 
unstable included binaries built by the uploader for arch:all which we 
can't successfully binNMU on the infrastructure, while at the same time 
we don't allow binaries not build by the buildds. Normally I would 
upload a no-change-source-only NMU to DELAYED/15 together with filling 
the bug, but there's currently an RC bug open, so I'll refrain from 
doing that.


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=rocm-hipamd



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

Hi all,

Have we decided how this package will be moving forward?

Regards

Phil


On Sun, 21 Jul 2024 16:31:05 +0900 Daichi Fukui
 wrote:
> Hi Daniel,
> 
> Thank you for the guide.
> It's been weeks since we talked with each other in the last month.
> 
> I now understand that there are some ways for the maintenance.
> I will consider which maintenance approach to choose.
> 
> > Do you have any preference among the git workflows in Debian? .. yet ;-)
> I agree with you.
> The "only debian/ dir in git" approach for this package should be replaced.
> 
> >Hold off on uploading a new package to mentors with the metadata changes,
I
> >don't have the focus right now but I'm sure to have more review comments
> >once I get around to it ;)
> Thank you for taking time to review this draft package.
> I'd appreciate it if you have some further comments and share them with me.
> 
> Best,
> Fukui
> 
> On Sat, 29 Jun 2024 at 01:39, Daniel Gröber  wrote:
> >
> > Hi Daichi,
> >
> > On Sun, Jun 16, 2024 at 04:08:26PM +0900, Daichi Fukui wrote:
> > > > Daichi, I'd be happy to sponsor this upload in principle (once it
passes
> > > > review) but only if you're interested in taking care of blktrace
going
> > > > forward.
> > >
> > > Yes, I'm interested in taking care of blktrace and have a plan to
address
> > > a different issue, that is #1069862.  I appreciate it if you could
> > > sponsor this upload.
> > >
> > > > Firstly, apologies Daichi, if you wish adopt this package and
maintain
> > > > it moving forward, like Daniel, I would be happy to assist and
support
> > > > you as needed if requested.
> > >
> > > Yes, I would like to adopt the blktrace package and hopefully get
> > > assistance for that if you don't mind.
> >
> > Alright. If you want to adopt it we should fixup the maintainer/uploader
> > metadata. Since bas agreed to the takeover you can just go ahead and
> > implement it yourself in d/control. Whether to leave Dmitry in Uploaders
> > (which would represent co-maintanance) is your call as maintainer now.
> >
> > Overall you can basically choose one of the following maintanance
> > approaches:
> >
> >   1) Be responsible for dealing with everything yourself. You are in
> >  Maintainers and there's no Uploaders,
> >   2) Have a select set of people (maint+uploaders) be collectively
> >  responsible or
> >   3) Collaborative maintainance across all of Debian. i.e. anyone can
> >  upload (we call this NMU) at will. You'd add yourself to the
> >  [LowThresholdNmu] list in that case
> >
> > [LowThresholdNmu]: https://wiki.debian.org/LowThresholdNmu
> >
> > Currently blktrace is packaged in git using the "only debian/ dir in git"

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Threads: https://www.threads.net/@kathenasorg

--








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

Bug#1077764: Ruling request on os-release specification implementation

On Fri, 2 Aug 2024 at 21:29, Helmut Grohne  wrote:
>
> Hi Luca,
>
> On Fri, Aug 02, 2024 at 01:43:04AM +0100, Luca Boccassi wrote:
> > 1) The os-release specification must be adhered to, and it must be
> > possible to tell the difference between testing vs unstable, and each
> > must be correctly identified by the respective metadata
>
> Given the state of discussion, I think it is fairly evident that we do
> not have consensus for the need to distinguish testing and unstable. We
> have people arguing in favour and we have people arguing against that.
> This is a point of disagreement.

I'm not sure "consensus for the need" is the right term here? People
obviously _do_ what I am speaking of. There might not be consensus
that's it's a good idea to do it, but it still happens, and it will
continue to happen, regardless of what is decided here. People do need
to distinguish it, whether the TC rules that it should be easy to do
so like in any other distro, or whether it rules that it will continue
to require annoying Debian-specific kludges, won't change this fact.

> > 2) Testing and unstable can continue to remain indistinguishable, and
> > both be erroneously identified as trixie
>
> Isn't there the third option of adhering to the os-release specification
> without making testing and unstable distinguishable? I did not see this
> ranked in your preference. Do you see it as even worse than the status
> quo?

There isn't such option. Adhering to the specification means
identifying them separately, given they can be built separately, ran
separately, managed separately. So the option you are referring to is
for the opposite: _not_ adhering to the specification, and yes, that
is an option.

Well, I guess there could be yet another option: stop making it
possible to create either testing or unstable images separately in the
first place, just like you cannot create a stable-proposed image.

> > Sorry but I do not think that is an accurate representation. First of
> > all, the implementation of the spec is bugged, period - it's not about
> > being pedantic about it, it's about being completely incompatible: sid
> > is identified as trixie, and that is just plain wrong, and there's no
> > room for interpretation, no matter how one might try to bend it. You
> > might say that you don't _care_ that the implementation is buggy, you
> > might even say that it is worth, nay _good_ it to leave it buggy - but
> > buggy it is, if I create a sid image, it will never in a million years
> > be trixie, and yet it says it's trixie.
>
> I think it has become abundantly clear that your view on this does not
> represent consensus of discussion participants. It is not as black and
> white as you paint it. Simon compared unstable to Ubuntu's proposed
> pocket. It also happens that testing and unstable share the same pool
> hierarchy and the vast majority of packages. On the other hand, Devuan
> operates as an overlay repository to be added on top of a Debian
> repository. I don't think it matters that Ubuntu's proposed is
> implemented as a partial distribution overlaid onto another as that's
> what other derivatives (that do update their os-release file) do as
> well.

Sure, there's no consensus on the solution, that's obvious otherwise I
would not have needed to open this in the first place, right? There
are some things that require opinions to converge - should this bug be
fixed? - and there are some things that just are - people create and
manage and run sid and trixie images independently, the implementation
of the spec in sid is buggy. These last two statements do not need
consensus, they are facts. Deciding what to do based on those facts
requires consensus on the solution to adopt, if any.
The example of Ubuntu's proposed pocket is wrong as already mentioned,
from the point of view of the os-release specification, which is what
matters here. You cannot create an ubuntu-proposed image without the
full release, so os-release is not concerned with it, and doesn't
mandate anything in particular. os-release concerns images that have a
lifecycle and their identification. Trixie has a lifecycle: it started
as a development release, it will be declared stable and start
receiving security support, it will move to ELTS, it will go EOL. sid
will not do any of these things, its lifecycle is entirely and
completely separate, it will always be sid, it will never be security
supported, it will never go EOL, and it is a rolling release. Once
more for those at the back: the _content_ is irrelevant, it can be
fixed, it can change a lot, it can be the same as different releases,
it can be partially the same, it can be completely different, it
doesn't matter one bit. The lifecycle is what matters for os-release.
This is an extremely important distinction and it is crucial here,
because this is what os-release is about, and this bug is about
os-release and its implementation, not about generic ideas. As already
mentioned many times, this bug is

Bug#1075633: wasmedge: ftbfs with GCC-14

2024-08-03 Thread Reinhard Tartler



I noticed this package is listed as low-NMU. As such, I'm taking the
liberty of uploading the following patch as NMU to sid:


3 files changed, 28 insertions(+)
debian/changelog |  7 +++
.../patches/don-t-fail-on-unknown-gcc-warnings.patch | 20 
debian/patches/series|  1 +

modified   debian/changelog
@@ -1,3 +1,10 @@
+wasmedge (0.13.5+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with gcc-14, Closes: #1075633
+
+ -- Reinhard Tartler   Sat, 03 Aug 2024 11:02:05 -0400
+
 wasmedge (0.13.5+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
new file   debian/patches/don-t-fail-on-unknown-gcc-warnings.patch
@@ -0,0 +1,20 @@
+From: Reinhard Tartler 
+Date: Sat, 3 Aug 2024 10:46:50 -0400
+Subject: don't fail on unknown gcc warnings
+
+---
+ cmake/Helper.cmake | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/cmake/Helper.cmake b/cmake/Helper.cmake
+index f9cdcf2..126e93f 100644
+--- a/cmake/Helper.cmake
 b/cmake/Helper.cmake
+@@ -39,7 +39,6 @@ else()
+ 
+   if(NOT WASMEDGE_PLUGIN_WASI_NN_GGML_LLAMA_CUBLAS)
+ list(APPEND WASMEDGE_CFLAGS
+-  -Werror
+   -Wno-error=pedantic
+ )
+ if(CMAKE_CXX_COMPILER_ID MATCHES "GNU" AND CMAKE_CXX_COMPILER_VERSION 
VERSION_GREATER 13)
new file   debian/patches/series
@@ -0,0 +1 @@
+don-t-fail-on-unknown-gcc-warnings.patch

Bug#947800: dh-python: pybuild copying of testfiles loses directory structure

2024-08-03 Thread Colin Watson

On Fri, Aug 19, 2022 at 05:04:40PM +0200, Stefano Rivera wrote:
> Hi Scott (2019.12.31_00:47:02_+0200)
> > When a file or directory such as a/b/c.txt is listed in 
> > pybuild.testfiles, when it is copied to the build directory, the 
> > directory structure portion is lost.  Tests expect certain data files to 
> > exist in certain location so this makes it hard to use the 
> > pybuild.testfiles feature.  It seems that pybuild.testfiles should 
> > retain the original directory structure of the listed files.
> 
> Not necessarily. It's quite common to have e.g. src/tests and you don't
> want the src directory in the temporary build dir.
> 
> I suspect we may need an optional destination path for each entry to
> implement this without breaking things.
> 
> I did some review of the archive, most pybuild.testfiles users naming a
> top-level directory in the source package, and this seems to give them
> what they want.

I run into this quite frequently when trying to convert packages to
autopkgtest-pkg-pybuild.  For packages that use unittest, tests tend not
to be in a top-level test/ or tests/ directory; it's also not entirely
uncommon for their own directory structure to matter, for example
because they import other test files.  In such cases I tend to end up
using workarounds like
https://salsa.debian.org/python-team/packages/py-macaroon-bakery/-/commit/e81e544e776fd853ca396655865a3a859c49a79c,
but it's definitely cumbersome.

An optional destination path might work, or perhaps instead a separate
option that specifies the path from which entries are copied and strips
that when constructing the path in the temporary build directory.

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

Bug#1016126: freeipa-server required libndr.so.1 and it's present only on Debian stable version

2024-08-03 Thread Michael Tokarev


On Wed, 27 Jul 2022 16:30:20 + Lucas Castro  wrote:

Package: freeipa-server
Version: 4.9.8-1+exp1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: lu...@gnuabordo.com.br

Dear Maintainer,

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

   * What led up to the situation?

I tried to install freeipa-server just for testing environment.
The environment is Debian fresh installation in lxc container.

Installation ends up with an error when it try to create the REALM 
kdb5_util: Unable to load requested database module 'ipadb.so': plugin symbol 'kdb_function_table' not found while creating database '/var/lib/krb5kdc/principal'


So I investigated the library required by ipadb.so 
ldd /usr/lib/x86_64-linux-gnu/krb5/plugins/kdb/ipadb.so
 it's noticed libndr.so.1 is required and not present. 
 The required library is present by samba-libs on Debian bullseye, the
 stable version by now. 

 Unstable and Sid version install libndr.so.2 in turn. 


This is an old issue.

libndr comes from samba, and there, it is NOT a public library.

However, several packages started using it, notable freeipa and sssd.
I knew about sssd, but didn't know about freeipa.

In debian bookworm, libndr was just one of many libraries in samba-libs
package.  Upstream freely bumps soname of this library.  And we never
noticed such updates, - when you build package with libndr from
bookworm, its dependency records "samba-libs (>= bookworm-version)",
which is obviously satisfyable with samba-libs from trixie with
libndr.so.2 or .3, - which is obviously wrong, since the package
needs libndr.so.1.

Later, with more recent samba versions, I made it more or less separate,
so if a package actually uses libndr, it gets recorded the correct
dependency.  And a more recent samba might break such package, requiring
it to be rebuilt.

So today, just a rebuild of freeipa with current samba-libs (samba-dev)
will get the dependencies correctly.  However, I can't retrospectively
rebuild freeipa in bookworm with correct deps (esp. since samba in
bookworm wont generate these deps anyway).

I guess I can add Breaks: freeipa (<= bookworm) to more recent samba-libs
to fix this.

/mjt

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

On Wed, 31 Jul 2024 10:05:08 -0400 Boyuan Yang  wrote:
> On Sun, 12 May 2024 15:05:05 -0300 Lucas Castro 
wrote:
> > Sorry for top posting.
> > 
> > The debian/control was modified to append Git fields, Cvs-Git and 
> > Cvs-Browser.
> > 
> > Git repository is following the DEP-14 as suggested, I really 
> > appreciated that workflow.
> > 
> > Changelog was improved. It reflects the all debian package modification 
> > right now.
> > 
> > There's something to do yet, about the gbp as Daniel had mentioned, All 
> > things about debian branch and upstream branch for debian git.
> > 
> > 
> > I had uploaded the package to mentors,
> > 
> >  https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc
> > 
> > The package can be checked from the git repository too, the following uri
> > 
> > Vcs-Browser: https://git.gnuabordo.com.br/foolsm.git
> > Vcs-Git: https://git.gnuabordo.com.br/foolsm.git
> > 
> > The debian/latest, debian/trixie and debian/unstable branches, all of 
> > them reflect debian package.
> > 
> > I'm maintain all those branch right now, and all of them is identical. 
> > I'm thinking about to delete the unstable.
> > 
> > I'll maintain just the debian/latest for development, debian/ for 
> > backports, security and propose-update and mentioned on DEP-14.
> > 
> > 
> > Thanks,
> > 
> > Lucas Castro
> 
> I am picking up this leftover work. I think everything is fine now
> except for https://bugs.debian.org/1054086 , which is overdue and must
> be fixed. Once you prepare a new version that no longer installs files
> under /lib/, please notify me and I can sponsor the upload.
> 
> Thanks,
> Boyuan Yang

Hi Boyuan,

If you are taking this package, could you take ownership and mark as pending
on the Bug Tracking System (BTS).

Details on this are near the bottom of the link below.

https://mentors.debian.net/sponsors/rfs-howto/

Regards

Phil

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Threads: https://www.threads.net/@kathenasorg

--








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

Bug#1077366: FTBFS: protoc-gen-go: unable to determine Go import path for "rpc.proto"

2024-08-03 Thread Reinhard Tartler

Hi,

I took the liberty of uploading the proposed change above as an NMU to the 
archive.

This is following the procedure outlined at
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

 * Upload fixing only release-critical bugs older than 7 days, with no
   maintainer activity on the bug for 7 days and no indication that a
   fix is in progress: 0 days


Please let me know if you have any questions or concerns.

Best,
-rt

Bug#1077779: google-guest-agent: FTBFS due to grpc transition

2024-08-03 Thread Reinhard Tartler



I took the liberty of uploading the patch below to the DELAYED/5-days queue.
Please let me know if you need me to cancel or reschedule this upload.

2 files changed, 8 insertions(+), 1 deletion(-)
debian/changelog | 7 +++
debian/control   | 2 +-

modified   debian/changelog
@@ -1,3 +1,10 @@
+google-guest-agent (2026.00-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build against google/protobuf@v1.5, Closes: #109
+
+ -- Reinhard Tartler   Sat, 03 Aug 2024 10:32:11 -0400
+
 google-guest-agent (2026.00-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
modified   debian/control
@@ -14,7 +14,7 @@ Build-Depends: debhelper-compat (= 13),
golang-google-cloud-dev,
golang-github-googlecloudplatform-guest-logging-go-dev,
golang-google-grpc-dev,
-   golang-goprotobuf-dev
+   golang-github-golang-protobuf-1-5-dev
 Standards-Version: 4.6.0
 Vcs-Browser: https://salsa.debian.org/cloud-team/google-guest-agent
 Vcs-Git: https://salsa.debian.org/cloud-team/google-guest-agent.git

Bug#1074092: vim: Annoying visual bell in insert mode when pageing after upgrade to trixie

2024-08-03 Thread Helge Kreutzmann

Am Sun, Jun 23, 2024 at 11:19:33AM -0400 schrieb James McCoy:
> On Sun, Jun 23, 2024 at 08:37:59AM GMT, Helge Kreutzmann wrote:
> > Up until bookworm no visual bell was shown in vim on the console
> > with my configuration. Now in insert mode (only), when paging an annoying 
> > visual
> > bell is shown.
> > 
> > This is *not* occuring with --clean but from the Debian changes I
> > could not derive which settings fault it is. 
> 
> I would suggest first comparing the output of ":set" with "vim --clean"
> and "vim". That should help narrow down which options differ from the
> defaults and may affect this behavior.

Thanks.

vim --clean
  background=dark helplang=de incsearch nolangremap 
  mouse=nvi   ruler   scrolloff=5 ttimeout  
  viminfofile=NONE
  display=truncatehistory=200 langnoremap   noloadplugins   
  nrformats=bin,hex   scroll=37   showcmd ttimeoutlen=100   
  wildmenu
  backspace=indent,eol,start
  fileencodings=ucs-bom,utf-8,default,latin1


vim:
  autoindent  backspace=indenthelplang=de incsearch 
  ruler   shiftround  shortmess=nxtToOS   smartcase 
  smarttabvisualbell  wildmenu
  background=dark   nofoldenable  ignorecase  laststatus=2  
  scroll=36   shiftwidth=4showmatch   smartindent   
  softtabstop=4   wildignore=*.swp
  cinoptions=t0,(0,u0
  cpoptions=aABceFsJ
  fileencodings=ucs-bom,utf-8,default,latin1
  formatoptions=tcq2l
  formatprg=fmt -cu -w70
  listchars=eol:$,tab:>-,trail:_
  printoptions=paper:a4
  statusline=%<%f%y%m%r%=%l,%c%V %P
  
suffixes=.bak,~,.swp,.o,.info,.aux,.log,.dvi,.bbl,.blg,.brf,.cb,.ind,.idx,.ilg,.inx,.out,.toc
  viminfo='1000,f1,"500,:50,@10,/100


> > As this is a (minor) regression, I'm reporting this. And if you have
> > any suggestion how to find out which setting this causes (except for
> > bisecting) I would be happy :-))
> 
> You could bisect your config by placing the "finish" command in your
> vimrc at various points to see what introduces the behavior.

Thanks, this made it easy.

It is the option "visualbell" which causes this behaviour. Until 
bookworm paging worked in in insert mode with this option but without
visual bell, now it does.

Is this a delibarate feature change?

Greetings

   Helge

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


signature.asc
Description: PGP signature

Bug#1061087: RFS: bash-unit/2.3.1-1 [ITP] -- bash_unit - bash unit testing

Control: tags -1 + moreinfo

Martin,

I will do a full review here to tell us where we are.

Preamble...

Thank you for taking the time to prepare this package and your contribution
to the Debian project.

The review below is for assistance. This review is offered to help package
submitters to Debian mentors inorder to improve their packages prior to
possible sponsorship into Debian. There is no obligation on behalf of the
submitter to make any alterations based upon information provided in the
review.

Review...

1. Build:

  * pbuilder [1]: Good
  * sbuild [2]: Good

2. Lintian [3]: Issue

I: bash-unit source: override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS
[debian/rules:8]
N: 
N:   The debian/rules file for this package has an override_dh_auto_test
target
N:   that does not appear to check DEB_BUILD_OPTIONS against nocheck.
N:   
N:   As this check is not automatically performed by debhelper(1), the
N:   specified testsuite is run regardless of another maintainer using the
N:   nocheck build option.
N:   
N:   Please add a check such as:
N:   
N:override_dh_auto_test:
N:ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
N:./run-upstream-testsuite
N:endif
N:   
N:   Lintian will ignore comments and other lines such as:
N:   
N:# Disabled
N:: Disabled
N:echo "Disabled"
N:mkdir foo/
N:ENV=var dh_auto_test -- ARG=value
N:   
N:   This check is not required in Debhelper compat level 13 or greater (see
N:   Bug#568897).
N: 
N:   Please refer to debian/rules and DEB_BUILD_OPTIONS (Section 4.9.1) in
the
N:   Debian Policy Manual and
N:   https://wiki.debian.org/BuildProfileSpec#Registered_profile_names for
N:   details.
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: debian/rules

3. Licenses [4]: Issue

philwyett@ks-solo:~/Development/builder/debian/mentoring/bash-unit-2.3.1$ lrc
-t
: Versions: recon 1.14  check 3.3.9-1

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

GPL-3   | GPL-3+   bash_unit

4. Watch file [uscan --force-download]: Good

5. Build Twice [sudo pbuilder build --twice .dsc]: Issue

 dpkg-source --after-build .
dpkg-buildpackage: info: full upload (original source is included)
dpkg-genchanges: info: including full source code in upload
dpkg-buildpackage: info: source package bash-unit
dpkg-buildpackage: info: source version 2.3.1-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Martin Dosch 
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
 debian/rules clean
dh clean
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building bash-unit using existing ./bash-
unit_2.3.1.orig.tar.gz
dpkg-source: warning: file bash-unit-2.3.1/bash_unit.1 has no final newline
(either original or modified version)
dpkg-source: info: local changes detected, the modified files are:
 bash-unit-2.3.1/bash_unit.1
dpkg-source: info: Hint: make sure the version in debian/changelog matches
the unpacked source tree
dpkg-source: info: you can integrate the local changes with dpkg-source --
commit
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/bash-unit_2.3.1-1.diff.2Nfb3n
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package
I: unmounting dev/ptmx filesystem
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
I: cleaning the build env 
I: removing directory /var/cache/pbuilder/build/79861 and its subdirectories

6. Reproducible builds [5]: Issue

# Running tests in ./tests/test_doc.sh
ok ✓ test_block_01
ok ✓ test_block_02
ok ✓ test_block_03
ok ✓ test_block_04
ok ✓ test_block_05
ok ✓ test_block_06
ok ✓ test_block_07
ok ✓ test_block_08
ok ✓ test_block_09
ok ✓ test_block_10
ok ✓ test_block_11
ok ✓ test_block_12
ok ✓ test_block_13
ok ✓ test_block_14
ok ✓ test_block_15
ok ✓ test_block_16
ok ✓ test_block_17
ok ✓ test_block_18
ok ✓ test_block_19
ok ✓ test_block_20
ok ✓ test_block_21
ok ✓ test_block_22
not ok ✗ test_block_23
# out> --- /tmp/113554/expected_output232024-08-04
04:19:43.058185145 +1400
# out> +++ /tmp/113554/test_output232024-08-04 04:19:43.058185145 +1400
# out> @@ -1 +1 @@
# out> -environment: line 1: _ps: command not found
# out> +environment: ligne 1: _ps: käsku ei ole
# test_doc.sh:27:test_block_23()
ok ✓ test_block_24
ok ✓ test_block_25
ok ✓ test_block_26
ok ✓ test_block_27
ok ✓ test_block_28
# Running tests in ./tests/test_tap_format
ok ✓ test_assertion_message_is_tap_formatted
ok ✓ test_bash_unit_accepts_tap_format_option
ok ✓ test_bash_unit_rejects_invalid_format
ok ✓ test_multi_lines_assertion_message_is_tap_formatted
ok ✓ test_tap_format_for_failing_test_with_stdout_stderr_outputs
ok ✓ test_tap_format_for_one_failing_test
ok ✓

Bug#1077038: ipwatchd: introduces aliased file /lib/systemd/system/ipwatchd.service (DEP17)

2024-08-03 Thread YunQiang Su

在 2024-08-03星期六的 13:31 +0200，Michael Biebl写道：
> On Thu, 25 Jul 2024 14:05:44 +0200 Helmut Grohne 
> wrote:
> > Package: ipwatchd
> > Version: 1.3.0-1+nmu1
> > Severity: serious
> > Justification: do not introduce aliased files into trixie
> > X-Debbugs-Cc: YunQiang Su 
> > User: helm...@debian.org
> > Usertags: dep17m2
> > Filename: /lib/systemd/system/ipwatchd.service
> > 
> > Hi,
> > 
> > your last upload added /lib/systemd/system/ipwatchd.service, which
> > is an
> > aliased location. We should not add any aliased files to trixie at
> > this
> > time hence filing at rc severity. Please move the unit to /usr. A
> > simple
> > way is adding dh-sequence-movetousr to Build-Depends. Consider
> > doing the
> > move in the upstream build system instead or relying on pkgconf
> > --variable systemdsystemunitdir systemd to provide the target
> > location.
> 
> 
> I also noticed, that the package added a Pre-Depends on 
> init-system-helpers (>= 1.66) without a proper explanation why.
> 

lintian warned about that when I didn't add it.

> Also, you probably should call dh_installsystemd as part of
> debian/rules 

Yes. I guess that we should switch debian/rules to the style of
override_..

> (dh does this automatically for you), to ensure that the service is 
> properly enabled and (re)started.
> 
> Regards,
> Michael

Bug#1075718: Subject: Re: Bug#1075718: libvirt-clients: virsh domif-setlink fails to update state

2024-08-03 Thread Robert


Hi,

I encountered the same bug, just that also the first invocation failed.
So I could not bring up the network at all.

I found the following workaround, in case anybody else also struggles 
with this:


- Execute command with argument "--print-xml", e.g.
   virsh domif-setlink ViRogue up --print-xml > domif-up.xml
- Edit domif-up.xml and fix double "state" tags in "link" entry
- Apply XML to running VM, e.g.
  virsh update-device ViRogue domif-up.xml --live


Thank you!

Bug#1068724: RFS: gensync/2.0.5-1 [ITP] -- a library for efficient synchronization of data over a network.

Hi Kevin,

This package is languishing with no updates of late. Are you working on the
package and an update will be due shortly?

Regards

Phil

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Threads: https://www.threads.net/@kathenasorg

--








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

Bug#1069620: RFS: lua-mode/20231023~git-1 -- Emacs major-mode for editing Lua programs

Hi all,

Do we have a consensus as yet on the versioning?

Regards

Phil


On Sat, 11 May 2024 10:29:56 -0700 Xiyue Deng  wrote:
> Hi Tobias,
> 
> Tobias Frost  writes:
> 
> > Hi Xiyue,
> >
> > when packaging a git snapshot, I feel this should be indicated in the
> > upstream version that it is based on the old one, something like
> > +
> >
> > In your case I'd 20210802+git20231023 as upstream version.
> >
> > Long time ago I did something like that for dhewm3, you 
> > can see the watch file here:
> >
https://salsa.debian.org/games-team/dhewm3/-/blob/debian/1.5.0+git20181221+dfsg-1/debian/watch?ref_type=tags
> >
> > (not marking moreinfo, as other people might see that differently.)
> 
> Thanks for your comments!  I actually also thought about this but ended
> up not following that idea because it will end up with 3 different
> versions based on dates:
> 
> * 20210802 which is the last tagged version[1],
> * 20221027 which is specified in the upstream source[2] and will end up
> in the installed elpa package directory but was never tagged, and
> * 20231023 which is the date of the latest upstream commit[3] when
> sending this email.
> 
> I think 20210802+git20231023. follows the current practice but
> will be *very* confusing when user will find that the package is
> installed at /usr/share/emacs/site-lisp/elpa/lua-mode-20221027.  I chose
> 20231023~git as a compromise just to avoid having too many dates there,
> which is still possible to upgrade to 20231023 should that be tagged one
> day.  I think the next choice could be 20221027+git20231023. just
> so there is one less date to deal with.
> 
> Wdyt?
> 
> [1] https://github.com/immerrr/lua-mode/tags
> [2] https://github.com/immerrr/lua-mode/blob/master/lua-mode.el#L15
> [3]
https://github.com/immerrr/lua-mode/commit/d074e4134b1beae9ed4c9b512af741ca0d852ba3
> 
> >
> > --
> > tobi
> >
> > On Sun, Apr 21, 2024 at 10:02:48AM -0700, Xiyue Deng wrote:
> >> Package: sponsorship-requests
> >> Severity: normal
> >> 
> >> Dear mentors,
> >> 
> >> I am looking for a sponsor for my package "lua-mode":
> >> 
> >>  * Package name : lua-mode
> >>    Version  : 20231023~git-1
> >>    Upstream contact : immerrr 
> >>  * URL  : https://github.com/immerrr/lua-mode
> >>  * License  : GPL-3+
> >>  * Vcs  : https://salsa.debian.org/emacsen-team/lua-mode

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Threads: https://www.threads.net/@kathenasorg

--








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

Bug#1077858: rust-debian-analyzer FTBFS: error[E0277]: the trait bound `Result: Tree` is not satisfied

2024-08-03 Thread Adrian Bunk

Source: rust-debian-analyzer
Version: 0.158.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=rust-debian-analyzer=0.158.3-1

...
error[E0277]: the trait bound `Result: 
Tree` is not satisfied
  --> src/publish.rs:72:26
   |
72 | check_clean_tree(wt, _tree(), subpath).unwrap();
   |   the trait `Tree` is not 
implemented for `Result`
   |
   = help: the following other types implement trait `Tree`:
 AppliedPatches
 MemoryTree
 PreviewTree
 RevisionTree
 WorkingTree
   = note: required for the cast from `` to ` Tree`
...

Bug#1077857: python3-pylxd outdated and linked to abandoned repo

2024-08-03 Thread Hadmut Danisch


Package: python3-pylxd

Hi,

python3-pylxd does not match LXD's api anymore and does not support many 
functions of LXD (when using the Package in Ubuntu). E.g. projects are 
not supported.



Reason: python3-pylxd is still based on

https://github.com/lxc/pylxd

while the repo has moved to


https://github.com/canonical/pylxd/


Either update or drop the outdated package.


regards

Hadmut

Bug#1077817: chirp: Reading from Quansheng causes logout

2024-08-03 Thread Dave Hibberd

Hi there, thanks for the bug! I’ll replicate it this afternoon and upload the 
latest one as there’s been a few updates to that driver since the last upload 
[1].

When you say the current version installed by python, do you mean installed via 
`pip3 install chirp`?

Are you running the regular firmware or another like egzumer?

[1] 
https://chirp.danplanet.com/projects/chirp/repository/github/changes/chirp/drivers/uvk5.py?rev=master

Cheers,

--
  Hibby
  Debian Developer
  Packet Radioist
  MM0RFN

> On 2 Aug 2024, at 19:05, Hilary Snaden  wrote:
> 
> Package: chirp
> Version: 1:20240413-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: hilary.sna...@zoho.com
> 
> Dear Maintainer,
> 
> Attempting to read the contents of two Quansheng UV-K5(8) transcievers has 
> causes logout, using the Debian package version and the current version 
> installed from Python, and on two different laptops running Debian. The 
> software still works normally with older Baofeng transcievers.
> 
> -- System Information:
> Debian Release: trixie/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.9.12-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages chirp depends on:
> ii  python3   3.12.3-1
> ii  python3-requests  2.32.3+dfsg-1
> ii  python3-serial3.5-2
> ii  python3-six   1.16.0-7
> ii  python3-yattag1.15.2-1
> ii  wxpython-tools4.2.1+dfsg-4
> 
> Versions of packages chirp recommends:
> ii  python3-suds  1.1.2-1
> 
> chirp suggests no packages.
> 
> -- no debconf information
>

Bug#1077599: apt: use sopv for OpenPGP signature verification

2024-08-03 Thread Daniel Kahn Gillmor

On Tue 2024-07-30 06:16:00 -0400, Daniel Kahn Gillmor wrote:
>> What's missing from sopv are mechanisms for specifying crypto
>> policies, such as allowed hashes, allowed crypto algorithms, and
>> allowed key sizes. I'm not sure if there's stuff I'm missing.

I think we'd be putting apt pretty deep in the crypto weeds if we try to
set those rules in apt itself.  Rather, apt should depend on a sopv
implementation that makes reasonable choices about what kinds of
cryptography is acceptable for signing.

>> What we found out here is that verifying the key algorithm and size
>> during signature verification is a bit annoying, they only work with
>> errors.
>> 
>> Imagine you have two keys, one weak and one strong. You never get a
>> warning about the weak key until you see a signature from it.

even then, i don't think you'd want to see a warning.  A weak signature
should be treated the same as no signature; it doesn't validate,
regardless of where it came from.

>> That's suboptimal because it means only errors really add security, as
>> otherwise an attacker may replace the data with one signed with a
>> compromised weak key and if an update runs in the background you might
>> not even notice.

Dealing with a weak key shouldn't be hard: we just use an OpenPGP
validator that only accepts strong keys.

Dealing with a compromised key is more challenging; we want to be able
to explicitly *exclude* a certificate when we know it to be compromised.
The simplest thing there is just to remove the certificate from the
filesystem, i think.

>> We also need status communicated:
>>
>>   fingerprints of keys that are unknown
>>   uids and fingerprints of expired keys such that we can display them

Why do we want to display them?  those sorts of warnings are footguns to
most admins: they see them as a warning that they need to fix, and they
go and hunt down the unknown key and "install" it to clear the warning.

I agree that there are use cases for debugging tools, but i think the
core part of apt should focus on a simple signature checker that just
does the right thing and fails appropriately when not on the happy
path.  Admins in the debugging case can bring different tools to bear.

apt can simplify; let the OpenPGP implementation do the work!

   --dkg

signature.asc
Description: PGP signature

Bug#1077804: adduser autopkgtest assumes backslash is a valid char

2024-08-03 Thread Marc Haber

On Fri, Aug 02, 2024 at 05:18:54PM +0200, Chris Hofstaedtler wrote:
> in #1076619 it was reported that usernames ending with backslashes
> break useradd/usermod/userdel, etc (from src:shadow).
> Allowing backslashes was a Debian patch. To fix #1076619,
> backslashes are now forbidden. However, adduser's autopkgtests
> assume that backslashes are good to use.

Is that change in the allowed user names backed by policy? We allow
backslashes in adduser to cater for some samba corner cases where a user
named domain\user is needed.

I am kind of concerned that this tightening of src:shadow's allowed usr
name character ranges breaks actual use cases.

> Please stop using backslashes.

Will do but are you sure you're doing the right thing here?

Should src:adduser also adapt the regexes that define allowed characters
in user names?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1077760: [Pkg-javascript-devel] Bug#1077760: pkg-js-tools: please allow to run a hook before testing

2024-08-03 Thread Yadd


On 8/1/24 18:34, Bastien Roucariès wrote:

Package: pkg-js-tools
Version: 0.15.22
Severity: important

Dear Maintainer,

Could you run an hook like pre-test in tests that will run something like for
instance regenerating certicate.

It will avoid a lot a failure and manual work

I can work arround using d/rules for build but not for test

Bastien


Hi,

do you have an idea on how to do this ? For now I insert my pre-test 
into the debian/tests/pkg-js/test file (which is run with `sh -e`)

Bug#1077764: Ruling request on os-release specification implementation

On Sat, 3 Aug 2024 at 12:39, Sebastian Ramacher  wrote:
>
> On 2024-08-03 12:20:09 +0200, Paul Gevers wrote:
> > Hi
> >
> > On 03-08-2024 11:58, Luca Boccassi wrote:
> > > > On the use of tpu:
> > > > Personally, until now I fail to see enough value of being able to
> > > > distinguish unstable and testing to give the package carrying
> > > > /etc/os-release a permanent exception via tpu.
> > >
> > > Thanks for chiming in - assuming for a moment that it is decided that
> > > the change will be implemented, do you see any technical obstacles in
> > > using t-p-u as proposed?
> >
> > The biggest reason I know against using tpu is that it currently isn't
> > receiving the same amount of testing (be it automatic (autopkgtest,
> > piuparts, in the future reproducibility) or human) as unstable-to-testing
> > migrations receive. For the automatic part, that's obviously a solvable
> > problem (and already on my todo list for YEARS), but currently not the case.
> > It also *always* requires human intervention by the Release Team. Another
> > issue issue with tpu is that binNMU'ing is more difficult (I assume that's
> > probably not very often relevant in the current case). I recall there are
> > more issues with tpu, but I have forgotten them. When I find them, I'll add
> > them.
>
> To add to that: tpu is used for exceptional cases only. Cases where we
> deem the result of the upload more important than the additional
> work required of a release team member. Cases where we deem RC bugs
> potentially introduced by missing QA for tpu uploads less severe than
> the issue we are trying to fix in testing. Essentially, if it is not a
> critical bug (think xz incident critical), going through tpu during non-freeze
> time never happens.
>
> For a package that is part of the essential set, having all the QA tools
> checking the consequences of the inclusion of this a package is really
> essential. Skipping out on QA checks for an essential packages that
> would normally run for typical unstable to testing migration puts even
> more pressure on the release team to make sure that accepting the
> package from tpu does not severly break testing.
>
> (As side note: in essentially all cases where I handled tpu uploads
> (that I remember) during non-freeze time, it was more effort to untangle
> unstable so I have asked maintainers explicitly to perform tpu uploads.)

In the generic case, sure, I see all of that making perfect sense.
This though is about one very specific and narrow case: an arch: all
package with a single, fixed and inert text file, that differs by one
line. No maintainer scripts that run on install/upgrades and could
fail, no programs that run on install, no dependencies that might not
be available or installable, one reverse dependency for one cycle to
ensure installation in existing images and then it will be removed.
And it's one upload at the beginning of a cycle, and then it stays
as-is for 2 years until the next, so there is no continued effort nor
need to watch it. At each cycle there is a lot of work to do to
prepare the next testing pocket I imagine - creating new aliases and
whatnot, so in the context of that and compared to the size of that
work, this appears to me as a minor addition, no? Which is not to say
it's nil or doesn't require any effort ofc. The QA effort I see is:
diffoscope old.deb new.deb and verify the difference is only in the
changelog entry and the VERSION_CODENAME= field. For this specific and
precise use case, do you see the requirement for any other QA effort
on top of this, and if so could you please clarify what it would
entail?

> Also, we have been pushing to keep testing and unstable as close as
> possible. Packages not migrating for some time are considered RC buggy
> to reduce the difference and where Paaul is thankfully filing the
> corresponding bugs. Going through tpu would essentially introduce a
> package that is auto-RC buggy in the essential set with consequences: it
> causes even more divergence for autopkgtests in testing (reference
> tests), in testing + pinned packages from unstable for migration checks
> and in unstable. That would cause potentially even more work (for the RT
> and maintainers) to figure out why some test is failing in one
> configuration and not the other.

I deal with fairly complex autopkgtest in debci all the time, for
systemd and related packages. The differences between testing and
unstable at any given time are so massive due to things like the
kernel having a fast development and upload cycle with lots of point
releases, a one line difference in one text file seems extremely minor
compared to the mountain of other things that are ongoing at any given
time. For example, right now literally everything is broken and has
been for months due to a kernel bug that makes it impossible to do
autopkgtest with a qemu guest. Do you have any specific indication for
this exact use case of t-p-u, rather than the generic issues with
t-p-u, that you

Bug#1077856: google-guest-agent: build-depends uninstallable

Source: google-guest-agent
Version: 2026.00-6
Severity: serious
X-Debbugs-CC: golang-google-cl...@packages.debian.org

Since some upload of golang-google-cloud-dev or such, google-guest-agent
cannot be built anymore, because its build-depends conflict with
each other.

I haven't noticed this for 2026.00-6.1, because this situation
came to be _while_ my upload was in DELAYED/n.

Chris

Bug#1077855: jami FTBFS

2024-08-03 Thread Adrian Bunk

Source: jami
Version: 20231201.0~ds2-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/jami.html

...
media/media_io_handle.cpp: In constructor 
'jami::MediaIOHandle::MediaIOHandle(std::size_t, bool, io_readcallback, 
io_writecallback, io_seekcallback, void*)':
media/media_io_handle.cpp:40:77: error: invalid conversion from 
'io_writecallback' {aka 'int (*)(void*, unsigned char*, int)'} to 'int 
(*)(void*, const uint8_t*, int)' {aka 'int (*)(void*, const unsigned char*, 
int)'} [-fpermissive]
   40 | ctx_ = avio_alloc_context(buf, buffer_size, writeable, opaque, 
read_cb, write_cb, seek_cb);
  | 
^~~~
  | 
|
  | 
io_writecallback {aka int (*)(void*, unsigned char*, int)}
In file included from /usr/include/x86_64-linux-gnu/libavformat/avformat.h:319,
 from media/libav_deps.h:30,
 from media/media_io_handle.cpp:21:
/usr/include/x86_64-linux-gnu/libavformat/avio.h:404:25: note:   initializing 
argument 6 of 'AVIOContext* avio_alloc_context(unsigned char*, int, int, void*, 
int (*)(void*, uint8_t*, int), int (*)(void*, const uint8_t*, int), int64_t 
(*)(void*, int64_t, int))'
  404 |   int (*write_packet)(void *opaque, const uint8_t *buf, 
int buf_size),
  |   
~~^
...
media/media_decoder.cpp: In member function 'jami::MediaDemuxer::Status 
jami::MediaDemuxer::decode()':
media/media_decoder.cpp:349:40: error: 'const struct AVInputFormat' has no 
member named 'read_header'
  349 | auto ret = inputCtx_->iformat->read_header(inputCtx_);
  |^~~
...

Bug#1077854: libcurl4t64: SIGPIPE leaks in some cases

2024-08-03 Thread Raphaël Halimi


Package: libcurl4t64
Version: 8.9.1-1
Severity: critical
Affects: transmission-daemon transmission-gtk

Dear maintainers,

Please look at the upstream bug :

https://github.com/curl/curl/issues/14344

On my system, this makes transmission-gtk crash unexpectedly after a 
short time, without any error message.


According to [1], it also affects transmission-daemon.

[1] https://github.com/transmission/transmission/issues/7035

Setting severity to critical because it affects other packages (and to 
trigger apt-listbugs for people who use it).


Regards,

--
Raphaël Halimi

Bug#1077850: murano-tempest-plugin: no longer maintained upstream

Control: clone -1 -2
Control: retitle -2 murano-tempest-plugin: no longer maintained upstream
Control: severity -2 important
Control: tags -2 = upstream wontfix
Control: user debian...@lists.debian.org
Control: usertags -2 + unmaintained-upstream

On Sat, 03 Aug 2024 at 14:05:50 +0200, Alexandre Detiste wrote:
> I also see that this project has been archived upstream.

> https://opendev.org/openstack/murano-tempest-plugin
> 
> "This project is no longer maintained."

I think that fact deserves its own bug report, independent of whether it
uses deprecated Python libraries.

As with the similar bugs I've reported for unmaintained GNOME and SDL
libraries, I'm tagging the cloned bug as upstream and wontfix, because
it will continue to be unmaintained upstream until/unless upstream action
is taken, therefore won't be fixed by Debian (unless a Debian contributor
becomes its new upstream maintainer, but that's an upstream action).

smcv

Bug#1073705: ifupdown-extra: diff for NMU version 0.33+nmu3

Control: tags 1073705 + pending


Dear maintainer,

I've prepared an NMU for ifupdown-extra (versioned as 0.33+nmu3) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ifupdown-extra-0.33+nmu2/debian/changelog ifupdown-extra-0.33+nmu3/debian/changelog
--- ifupdown-extra-0.33+nmu2/debian/changelog	2024-03-25 21:05:07.0 +0100
+++ ifupdown-extra-0.33+nmu3/debian/changelog	2024-08-03 14:37:24.0 +0200
@@ -1,3 +1,10 @@
+ifupdown-extra (0.33+nmu3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd unit into /usr/lib (DEP17). (Closes: #1073705)
+
+ -- Chris Hofstaedtler   Sat, 03 Aug 2024 14:37:24 +0200
+
 ifupdown-extra (0.33+nmu2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru ifupdown-extra-0.33+nmu2/debian/dirs ifupdown-extra-0.33+nmu3/debian/dirs
--- ifupdown-extra-0.33+nmu2/debian/dirs	2016-05-28 23:26:20.0 +0200
+++ ifupdown-extra-0.33+nmu3/debian/dirs	2024-08-03 14:36:51.0 +0200
@@ -3,4 +3,4 @@
 etc/network
 etc/network/if-pre-up.d
 etc/network/if-up.d
-lib/systemd/system/
+usr/lib/systemd/system/
diff -Nru ifupdown-extra-0.33+nmu2/debian/rules ifupdown-extra-0.33+nmu3/debian/rules
--- ifupdown-extra-0.33+nmu2/debian/rules	2018-02-06 23:52:59.0 +0100
+++ ifupdown-extra-0.33+nmu3/debian/rules	2024-08-03 14:37:08.0 +0200
@@ -24,7 +24,7 @@
 	install -m755 if-up-scripts/static-routes  $(CURDIR)/debian/ifupdown-extra/etc/network/if-up.d/20static-routes
 	install -m755 if-up-scripts/check-gateway  $(CURDIR)/debian/ifupdown-extra/etc/network/if-up.d/30check-gateway
 	# Serviced Unit file
-	install -m644 debian/networking-routes.service $(CURDIR)/debian/ifupdown-extra/lib/systemd/system/
+	install -m644 debian/networking-routes.service $(CURDIR)/debian/ifupdown-extra/usr/lib/systemd/system/
 
 override_dh_installinit:
 	dh_installinit

Bug#1077852: plfit-doc contains a /CONTRIBUTORS.txt

2024-08-03 Thread Jochen Sprickerhof

Package: plfit-doc
Version: 0.9.6+ds-1
Severity: normal

Hi,

the plfit-doc contains a CONTRIBUTORS.txt in the root directory. I guess
it should be in /usr/share/doc/plfit/ or somewhere.

Cheers Jochen


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

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

Bug#1073255: Package name for gpgme QT5/QT6 devel packages

2024-08-03 Thread Andreas Metzler

Hello Patrick,

I am currently in the process of packaging gpgme 1.23.2. The packaging
will feature
* Split off QT bindings from generic libgpgmepp-dev.
* Also package QT6 bindings.

I am not quite sure about the package names though, we will have
libqgpgme15t64 (QT5 bindings) and libqgpgmeqt6-15 (QT6) as runtime
packages. I currently have used libqgpgme-dev (QT5) (by simply following
Rene's draft in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863149#15
and libqgpgmeqt6-dev, which seems odd. How about
libqgpgmeqt5-dev/libqgpgmeqt6-dev?

Is there some kind of (informal) policy I should follow or a better
addess to ask?

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1077850: murano-tempest-plugin depends on deprecated telnetlib

2024-08-03 Thread Alexandre Detiste

Source: murano-tempest-plugin
Version: 2.7.0-2
Severity: important
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear Maintainer,

murano-tempest-plugin (ab)uses telnetlib to do some port knocking.

telnetlib has been removed from Python 3.13

I also see that this project has been archived upstream.

Greetings


https://opendev.org/openstack/murano-tempest-plugin

"This project is no longer maintained."


https://sources.debian.org/src/murano-tempest-plugin/2.7.0-2/murano_tempest_tests/tests/functional/common/utils.py/?hl=21#L21

@classmethod
def verify_connection(cls, ip, port):
"""Try to connect to specific ip:port with telnet.

:param ip: Ip that you want to check
:param port: Port that you want to check
:return: :raise RuntimeError:
"""
tn = telnetlib.Telnet(ip, port)
tn.write('GET / HTTP/1.0\n\n')
try:
buf = tn.read_all()
LOG.debug('Data:\n {data}'.format(data=buf))
if len(buf) != 0:
tn.sock.sendall(telnetlib.IAC + telnetlib.NOP)
return
else:
raise RuntimeError('Resource at {0}:{1} not exist'.
   format(ip, port))
except socket.error as e:
LOG.error('Socket Error: {error}'.format(error=e))

Bug#1077849: parlatype-libreoffice-extension: Homepage points to spam site

2024-08-03 Thread Bastian Germann


Source: parlatype-libreoffice-extension
Version: 3.1.1-2
Severity: important

Please let the Homepage point to 
https://github.com/gkarsay/parlatype-libreoffice-extension
instead of the spam site that it points to currently.

Bug#1077764: Ruling request on os-release specification implementation

2024-08-03 Thread Sebastian Ramacher

On 2024-08-03 12:20:09 +0200, Paul Gevers wrote:
> Hi
> 
> On 03-08-2024 11:58, Luca Boccassi wrote:
> > > On the use of tpu:
> > > Personally, until now I fail to see enough value of being able to
> > > distinguish unstable and testing to give the package carrying
> > > /etc/os-release a permanent exception via tpu.
> > 
> > Thanks for chiming in - assuming for a moment that it is decided that
> > the change will be implemented, do you see any technical obstacles in
> > using t-p-u as proposed?
> 
> The biggest reason I know against using tpu is that it currently isn't
> receiving the same amount of testing (be it automatic (autopkgtest,
> piuparts, in the future reproducibility) or human) as unstable-to-testing
> migrations receive. For the automatic part, that's obviously a solvable
> problem (and already on my todo list for YEARS), but currently not the case.
> It also *always* requires human intervention by the Release Team. Another
> issue issue with tpu is that binNMU'ing is more difficult (I assume that's
> probably not very often relevant in the current case). I recall there are
> more issues with tpu, but I have forgotten them. When I find them, I'll add
> them.

To add to that: tpu is used for exceptional cases only. Cases where we
deem the result of the upload more important than the additional
work required of a release team member. Cases where we deem RC bugs
potentially introduced by missing QA for tpu uploads less severe than
the issue we are trying to fix in testing. Essentially, if it is not a
critical bug (think xz incident critical), going through tpu during non-freeze
time never happens.

For a package that is part of the essential set, having all the QA tools
checking the consequences of the inclusion of this a package is really
essential. Skipping out on QA checks for an essential packages that
would normally run for typical unstable to testing migration puts even
more pressure on the release team to make sure that accepting the
package from tpu does not severly break testing.

(As side note: in essentially all cases where I handled tpu uploads
(that I remember) during non-freeze time, it was more effort to untangle
unstable so I have asked maintainers explicitly to perform tpu uploads.)

Also, we have been pushing to keep testing and unstable as close as
possible. Packages not migrating for some time are considered RC buggy
to reduce the difference and where Paaul is thankfully filing the
corresponding bugs. Going through tpu would essentially introduce a
package that is auto-RC buggy in the essential set with consequences: it
causes even more divergence for autopkgtests in testing (reference
tests), in testing + pinned packages from unstable for migration checks
and in unstable. That would cause potentially even more work (for the RT
and maintainers) to figure out why some test is failing in one
configuration and not the other.

But keeping all of that aside, I don't see any label that could be
included as a static file in a package that would be correct due to the
duality of testing. trixie is defined by what we release on release day.
Labelling it trixie before that would be wrong as there are cases where
creating a "trixie" image before release will not end up with a trixie
image as produced after the release (just install something that is
later removed from testing). It would be labelled incorrectly as trixie
if users created it with testing or as testing + unstable. Any users may
add experimental to the mix as testing + sid + experimental which would
also be mislabelled.

Without checking the apt configuration (including the
Default-Release setting) and its sources configuration, there are always
cases where the label is incorrect during our typical release process
(and even then priorities may make it impossible to label properly).
Labelling testing as $selected_release_name/sid is a good enough
and more importantly an established compromise to label what will
become the next release up to the freeze.

So far I do not see a good enough reason to side-step typical migration
flow from unstable to testing for a label for testing that won't be
correct for one or another use case.

Cheers
-- 
Sebastian Ramacher

Bug#1077848: pudb: please update to 2024.1.2 to remove usage of telnetlib

2024-08-03 Thread Alexandre Detiste

Source: pudb
Version: 2022.1.3-1
Severity: important
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear Maintainers,

The telnetlib module has been removed from Python3.13.

Usage of this module has already been removed upstream.

https://github.com/inducer/pudb/pull/626

pudb/remote.py:import telnetlib as tn
pudb/remote.py:raw_sock_file.write(tn.IAC + tn.WILL + tn.SGA)
pudb/remote.py:assert resp == tn.IAC + tn.DO + tn.SGA
pudb/remote.py:raw_sock_file.write(tn.IAC + tn.WILL + tn.ECHO)
pudb/remote.py:assert resp == tn.IAC + tn.DO + tn.ECHO

Greetings,

Alexandre

Bug#1077038: ipwatchd: introduces aliased file /lib/systemd/system/ipwatchd.service (DEP17)

2024-08-03 Thread Michael Biebl


On Thu, 25 Jul 2024 14:05:44 +0200 Helmut Grohne  wrote:

Package: ipwatchd
Version: 1.3.0-1+nmu1
Severity: serious
Justification: do not introduce aliased files into trixie
X-Debbugs-Cc: YunQiang Su 
User: helm...@debian.org
Usertags: dep17m2
Filename: /lib/systemd/system/ipwatchd.service

Hi,

your last upload added /lib/systemd/system/ipwatchd.service, which is an
aliased location. We should not add any aliased files to trixie at this
time hence filing at rc severity. Please move the unit to /usr. A simple
way is adding dh-sequence-movetousr to Build-Depends. Consider doing the
move in the upstream build system instead or relying on pkgconf
--variable systemdsystemunitdir systemd to provide the target location.



I also noticed, that the package added a Pre-Depends on 
init-system-helpers (>= 1.66) without a proper explanation why.


Also, you probably should call dh_installsystemd as part of debian/rules 
(dh does this automatically for you), to ensure that the service is 
properly enabled and (re)started.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076498: Vampire: The Masquerade - Bloodlines crashes on launch

2024-08-03 Thread Antoine Le Gonidec

It has been reported upstream that the following patch update from
wine-staging does get rid of the reported crash:
https://github.com/wine-staging/wine-staging/commit/b98458cad

source: https://bugs.winehq.org/show_bug.cgi?id=56711#c9


pgpK3uPAHlFpB.pgp
Description: Signature digitale OpenPGP

Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?


Hi,

On 03-08-2024 11:55, Niels Thykier wrote:
Since the non-free is entirely opt-in and you had to be very active 
about opt'ing in as a admin, this seem fine. With the change to 
non-free-firmware now being enabled by d-i by default, we now have 
non-free-firmware packages installed by default that can use this 
opt-out and for me, that changes the game a bit.


I totally agree.

I have not checked 
whether all non-free-firmware is auto-buildable


It would be good if we had the answer to this question, because changing 
britney2 to do the check for all binaries is trivial [1], and adding a 
hint explicitly for those that aren't auto-buildable seems maintainable 
(there are currently only 15 sources in non-free-firmware in sid).


Paul

[1] 
https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/policy.py?ref_type=heads#L1543




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077764: Ruling request on os-release specification implementation

On Sat, 3 Aug 2024 at 11:20, Paul Gevers  wrote:
>
> Hi
>
> On 03-08-2024 11:58, Luca Boccassi wrote:
> >> On the use of tpu:
> >> Personally, until now I fail to see enough value of being able to
> >> distinguish unstable and testing to give the package carrying
> >> /etc/os-release a permanent exception via tpu.
> >
> > Thanks for chiming in - assuming for a moment that it is decided that
> > the change will be implemented, do you see any technical obstacles in
> > using t-p-u as proposed?
>
> The biggest reason I know against using tpu is that it currently isn't
> receiving the same amount of testing (be it automatic (autopkgtest,
> piuparts, in the future reproducibility) or human) as
> unstable-to-testing migrations receive. For the automatic part, that's
> obviously a solvable problem (and already on my todo list for YEARS),
> but currently not the case. It also *always* requires human intervention
> by the Release Team. Another issue issue with tpu is that binNMU'ing is
> more difficult (I assume that's probably not very often relevant in the
> current case). I recall there are more issues with tpu, but I have
> forgotten them. When I find them, I'll add them.

Thank you. For this particular case: there would be 2 uploads for
every cycle, one at the end to add version numbers (this already
happens, no?), one at the beginning to change the VERSION_CODENAME. I
think from the point of view of requiring manual labour it should be
pretty lightweight compared to the current workload of managing
stable-p-u, at 2 uploads to review once every ~2 years, right?

For the binNMU side, this would be an Architecture: all package, so it
doesn't apply I think, right? It wouldn't be subject to any binary
transition for library bumps or things like that. In the current
proposal I am putting forward it's a binary arch: all with a single
fixed arch-independent text file in /usr/lib/ and a single fixed
symlink in /etc/ to the file in /usr/lib, no maintainer scripts
whatsoever, no dependencies.

Bug#1077847: ironseed: flaky autopkgtest: savegames: times out after 5 minutes

Source: ironseed
Version: 0.4.0-5
Severity: important
User: debian...@lists.debian.org
Usertags: flaky
X-Debbugs-Cc: debian...@lists.debian.org
Control: affects -1 + src:libsdl2

The ironseed autopkgtest 'savegames' intermittently fails on
ci.debian.net, which the testing migration infrastructure assumes is
a regression in a package that was upgraded, preventing packages like
libsdl2 from migrating to testing until the ironseed autopkgtest is
retried. For example, please see:

https://ci.debian.net/packages/i/ironseed/testing/amd64/49933956/
https://ci.debian.net/packages/i/ironseed/testing/amd64/49922715/
https://ci.debian.net/packages/i/ironseed/testing/amd64/49534951/

A sample log:

 55s autopkgtest [23:42:32]: test savegames: [---
355s timeout: sending signal TERM to command ‘xvfb-run’
355s X connection to :99 broken (explicit kill or server shutdown).
355s sha256sum: /home/debci/.local/share/ironseed/save1/CONTACTS.DTA: No such 
file or directory
355s /home/debci/.local/share/ironseed/save1/CONTACTS.DTA: FAILED open or read
355s sha256sum: /home/debci/.local/share/ironseed/save1/EVENTS.DTA: No such 
file or directory
355s sha256sum: /home/debci/.local/share/ironseed/save1/LOGS.DTA: No such file 
or directory
355s sha256sum: /home/debci/.local/share/ironseed/save1/PENDING.DTA: No such 
file or directory
355s sha256sum: WARNING: 4 listed files could not be read
355s /home/debci/.local/share/ironseed/save1/EVENTS.DTA: FAILED open or read
355s /home/debci/.local/share/ironseed/save1/LOGS.DTA: FAILED open or read
355s /home/debci/.local/share/ironseed/save1/PENDING.DTA: FAILED open or read
356s autopkgtest [23:47:33]: test savegames: ---]

If this test is known to be unreliable, please mark it with
"Restrictions: flaky" so that it doesn't stop other packages from
migrating.

Thanks,
smcv

Bug#1077764: Ruling request on os-release specification implementation

On Fri, 2 Aug 2024 at 21:06, Sam Hartman  wrote:
>
> > "Luca" == Luca Boccassi  writes:
>
> Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie  wrote:
> >>
> >> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> >> > To further clarify why the status quo with
> >> VERSION_CODENAME=trixie in > sid is really bad: it used to be
> >> that if you had "debian" mentioned in > os-release but no other
> >> version identifying fields, you knew you were > on testing OR
> >> unstable and you'd have to deploy horrendous hacks to > attempt
> >> and figure out which of the two it was really.
> >>
> >> OK, I think this is progress:
> >>
> >> What is the scenario / use-case in which it becomes necessary to
> >> distinguish between those two suites?
> >>
> >> To put that another way, what external piece of software needs to
> >> change its behaviour, dependent on whether you are running
> >> testing (of an unspecified datestamp) or unstable (of an
> >> unspecified datestamp)?
> >>
> >> Or perhaps you are thinking of a scenario in which a *person*
> >> needs to change their behaviour, dependent on whether they are
> >> running testing or unstable?
>
> Luca> Are the examples I provided at:
>
> Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
> Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5
>
> Not to me.
> I read what I think is the examples you linked from both bug reports.
> I didn't dig too far into the github links you provided though.
> What I see from your mail is that people want to distinguish unstable
> from testing and have created various hacks to do so.
>
> What I do not see is a compelling explanation of why Debian as a project
> wants to encourage that distinction.
> I agree that people doing a thing is evidence that it has value to those
> people.
> But I do not think you provided an explanation of what that value is.
>
> If it were easy to distinguish testing from unstable, why would I want
> to do that?

I don't see any of this being about "encouraging", because, as
mentioned in a previous mail, this is already how things work, and it
doesn't need any encouraging. It's about simply recognizing that this
is how everything already works, and changing 5 characters in a text
file that will have no repercussion on how these are used. Because
once again, I can do:

debootstrap trixie foo
debootstrap sid bar

foo and bar are different images, with different policies and
different lifecycles.
foo is currently in development, will freeze and then become stable
and security supported, and then move to LTS, and then be EOL. It is a
development-to-stable-to-eol image.
bar will continue being a development image, will never freeze, will
never become security supported, will never become LTS, will never be
EOL. It is a rolling image.

These details are what os-release is about, if you read the spec,
there are tons of fields about lifecycle management of an image, with
support and so on.

I am not describing a proposal here, I am describing how things work
and have always worked.

If you are asking me _why_ other people use the above how they use
them, well, I don't know? Unfortunately I left my Cerebro helmet in my
other coat. What I can do is show that it happens, it's always
happened, and it will very likely continue to happen. And what I am
highlighting is that we are the only distro that makes it hard to do
it, and I am highlighting that a specification (that I am one of the
owners of) is implemented incorrectly since it says A is B. And I am
asking to fix it so that A says it's A instead, and B continues to say
it's B as it does today.

I can say why _I_ do it though: because I regularly build and manage
multiple images, and I can correctly identify all of them based on
standard distro-agnostic tooling, but not Debian unstable, which is
the _only_ exception that requires annoying kludges to be used.

Bug#1077764: Ruling request on os-release specification implementation


Hi

On 03-08-2024 11:58, Luca Boccassi wrote:

On the use of tpu:
Personally, until now I fail to see enough value of being able to
distinguish unstable and testing to give the package carrying
/etc/os-release a permanent exception via tpu.


Thanks for chiming in - assuming for a moment that it is decided that
the change will be implemented, do you see any technical obstacles in
using t-p-u as proposed?


The biggest reason I know against using tpu is that it currently isn't 
receiving the same amount of testing (be it automatic (autopkgtest, 
piuparts, in the future reproducibility) or human) as 
unstable-to-testing migrations receive. For the automatic part, that's 
obviously a solvable problem (and already on my todo list for YEARS), 
but currently not the case. It also *always* requires human intervention 
by the Release Team. Another issue issue with tpu is that binNMU'ing is 
more difficult (I assume that's probably not very often relevant in the 
current case). I recall there are more issues with tpu, but I have 
forgotten them. When I find them, I'll add them.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077846: rust-gdk4: autopkgtest regression: cannot find function `gdk_display_get_dmabuf_formats` in crate `ffi`

Source: rust-gdk4
Version: 0.8.2-6
Severity: serious
Justification: https://release.debian.org/testing/rc_policy.txt 6a
User: debian...@lists.debian.org
Usertags: needs-update

rust-gdk4 is failing tests on ci.debian.net, with lots of errors like:

343s error[E0425]: cannot find function `gdk_display_get_dmabuf_formats` in 
crate `ffi`
343s --> src/auto/display.rs:129:33
343s  |
343s 129  | 
from_glib_none(ffi::gdk_display_get_dmabuf_formats(self.as_ref().to_glib_none().0))
343s  | ^^ 
help: a function with a similar name exists: `gdk_display_get_default_seat`
343s  |
343s ::: /usr/share/cargo/registry/gdk4-sys-0.8.2/src/lib.rs:4105:5

This is building against librust-gdk4-sys-dev 0.8.2-4 in the
autopkgtest environment. Does it perhaps need a versioned dependency on
librust-gdk4-sys-dev (>= 0.8.2-7) to get access to GTK 4.14.x features?

When testing a proposed migration, ci.debian.net takes all dependencies
from testing, unless a versioned dependency explicitly requires the
version from unstable. In this case the versioned dependency on GTK 4
means we get that from unstable:

 17s Get:167 http://deb.debian.org/debian unstable/main amd64 libgtk-4-common 
all 4.14.4+ds-8 [2,490 kB]
 17s Get:168 http://deb.debian.org/debian unstable/main amd64 libgtk-4-1 amd64 
4.14.4+ds-8 [3,109 kB]
 18s Get:169 http://deb.debian.org/debian unstable/main amd64 gir1.2-gtk-4.0 
amd64 4.14.4+ds-8 [212 kB]
 ...
 19s Get:298 http://deb.debian.org/debian unstable/main amd64 libgtk-4-dev 
amd64 4.14.4+ds-8 [981 kB]

and obviously we get the package under test from unstable, too:

 21s Get:425 http://deb.debian.org/debian unstable/main amd64 librust-gdk4-dev 
amd64 0.8.2-6 [72.5 kB]

but everything else comes from testing.

If a new gtk4 upload is needed for some other reason before this all
migrates, we might also want to give it a Breaks on
librust-gdk4-dev (<< 0.8.2-6~), librust-gdk4-sys-dev (<< 0.8.2-7~)
to stop the testing migration infrastructure from wasting its time
testing the new GTK against the old Rust bindings (which we already know
doesn't work).

smcv

Bug#1077844: pkg-perl-tools: Last upload seems to be wrong

2024-08-03 Thread gregor herrmann

Control: affects 1074038 + pkg-perl-tools
Control: reassign 1077844 devscripts,qa.debian.org 2.23.7
Control: merge 1074038 1077844

On Sat, 03 Aug 2024 10:52:37 +0200, Étienne Mollier wrote:

> Control: affects 1074038 + 1077844
> Control: block 1077844 by 1074038
> 
> Thanks Frederic-Emmanuel!  For what it's worth, this:
> 
> > Last upload
> > ===
> > Uploads for orange-canvas-core:
> > 0.1.31-3 to unstable: Roland Mas  on Tue, 15 Aug 2023 
> > 13:20:27 +
> […]
> > the version in unstable is 0.2.1-3 but the last reported
> > version is 0.1.31-3 whcih is the testing verion.
> 
> seems related to #1074038 affecting who-uploads in
> devscripts, but I haven't checked closely yet.

I'd say, it's not related to #1074038 but it actually _is_ #1074038
:)

dpt-prepare is just a shell script which here simply calls
who-uploads, and there's nothing we can do, now or in the future,
about the outdated output on the pkg-perl-tool side.


Cheers,
gregor, trying to reassign and merge

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


signature.asc
Description: Digital Signature

Bug#1077764: Ruling request on os-release specification implementation

On Sat, 3 Aug 2024 at 10:51, Paul Gevers  wrote:
>
> Hi,
>
> [Release Team member hat on, but I only voice my opinion as a member].
>
> On the use of tpu:
> Personally, until now I fail to see enough value of being able to
> distinguish unstable and testing to give the package carrying
> /etc/os-release a permanent exception via tpu.

Thanks for chiming in - assuming for a moment that it is decided that
the change will be implemented, do you see any technical obstacles in
using t-p-u as proposed?

> On Debian version numbers:
> I my view we only assign version numbers the moment we release. You can
> see that reflected in the symlink layout of debian/dists and in the
> trixie/Release file.

Understood, thanks for providing that additional information - then as
mentioned in another reply, I am changing the request from what it was
originally stated in the initial email that opened the bug, and I do
not request that version numbers be added to testing. The
implementation I am then requesting to rule on is defined in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43 and, in
practice, results only in a change to unstable, testing's content will
remain as it currently is, with no change at all.

Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?


Package: release.debian.org
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net,debian-b...@lists.debian.org

Hi,

Historically, we have had a major opt-out for non-free in regards to 
Policy. One of these opt-outs are that the package does not have to be 
auto-built on Debian buildds.


Since the non-free is entirely opt-in and you had to be very active 
about opt'ing in as a admin, this seem fine. With the change to 
non-free-firmware now being enabled by d-i by default, we now have 
non-free-firmware packages installed by default that can use this 
opt-out and for me, that changes the game a bit.


In my book, ideally, we would require all non-free-firmware to be build 
on buildds to have it be closer aligned with main since it is now 
installable by default, where we do not want to trust maintainer build 
packages (which also makes our contributors less of a target for 
build-time backdoors).
  Though, license requirements might prevent that (I have not checked 
whether all non-free-firmware is auto-buildable), so a second runner up 
for me would be to have Britney enforce non-free(-firmware) was built on 
a buildd if the source has `Autobuild` set to `yes`. This would at least 
close the gap as much as possible.


Best regards,
Niels

Bug#1071438: uscan: no longer finds tarballs hosted on gitlab

2024-08-03 Thread Rebecca N. Palmer

A fix is to use the downloadurlmangle option, i.e. this line in d/watch 
(based on David Steele's solution for git*hub* in #1019696):


That's not enough: it was able to notice that there was a new upstream 
available, but not to actually update to it.  This works:


version=4
opts="uversionmangle=s/-([ab])/~$1/g,dversionmangle=auto,repacksuffix=+dfsg,downloadurlmangle=s#tags/([0-9.]+)#archive/$1/openpyxl-$1.tar.gz#g,filenamemangle=s#tags/([0-9.]+)#openpyxl-$1.tar.gz#g" 
\

https://foss.heptapod.net/openpyxl/openpyxl/-/tags .*/tags/@ANY_VERSION@

Bug#1077764: Ruling request on os-release specification implementation


Hi,

[Release Team member hat on, but I only voice my opinion as a member].

On the use of tpu:
Personally, until now I fail to see enough value of being able to 
distinguish unstable and testing to give the package carrying 
/etc/os-release a permanent exception via tpu.


On Debian version numbers:
I my view we only assign version numbers the moment we release. You can 
see that reflected in the symlink layout of debian/dists and in the 
trixie/Release file.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072992: pycryptodome: FTBFS: cannot find -lasan and -lubsan on loong64, sparc64 and other architectures

2024-08-03 Thread yokota

Hello PyCryptodome maintainers,

I was added FTBFS fix for Debian bug 1069534, 1072992, 1045521 to
Debian salsa repository.
https://salsa.debian.org/python-team/packages/pycryptodome/-/merge_requests/2

Please examine the merge request.

--
YOKOTA Hiroshi

Bug#1050693: sphinx: unreproducible output if the same function has two entries in the table of contents

2024-08-03 Thread Rebecca N. Palmer


Control: found -1 7.3.7-4

The pandas reprotest logs on salsa-ci are usually incomplete, because 
two builds of pandas is over the log size limit. 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pandas.html 
does have a complete log, which does still show this issue (search for 
'current active' - it is currently in pandas.Flags.html, but which files 
are affected probably changes randomly on each build).


I have not yet investigated what causes it - thanks for the hints.

Bug#1077764: Ruling request on os-release specification implementation

On Sat, 3 Aug 2024 at 05:23, Sean Whitton  wrote:
>
> Hello,
>
> Luca is the upstream maintainer of the specification, but whether and
> how the specification as published applies to Debian is not simply up to
> his assertion.

To be really really precise, what I asserted is that the
implementation is currently buggy in unstable, which is technically
correct. I then _ask_ for a ruling to change the implementation. As
already mentioned many times in other mails, one is perfectly allowed
to say "this bug should not be fixed", "this bug's severity is nil",
but not to say "this bug does not exist". To repeat the same example,
if os-release was a program asserting on the state, it would run
correctly on testing, and it would crash when run in unstable. One can
say it's wrong that it crashes and one wants the state to remain
as-is, but one can't say it doesn't crash, because it is a fact that
it does, not an opinion. Both of these things can happen at the same
time and be both true: the TC rules that the os-release file in
unstable will remain as-is, and os-release implementation in Debian is
buggy. A bug report can be closed by an upload that changes something,
or by a close+wontfix.

> The TC is being asked to override how Santiago has determined the
> specification applies to Debian.
> The Release Team's opinion is as relevant as Santiago's, I think.

Everybody is welcomed to chime in at any time, and I have already said
so on RT's IRC channel the other day just after opening this bug.
On the matter of formal ownership however, I want to highlight that,
as you can see in various replies detailing the precise technical
solution that could possibly be implemented, there are _no changes to
testing_ being proposed here, in case what you are worried about here
is ownership of testing and changes to it. The only change would be in
unstable, and as far as I understand (I might be wrong, please correct
me) RT owns testing and [old]stable, not unstable. If you want to
ensure the owner of the relevant area is directly involved, then
perhaps it's the FTP team that should be, since as far as I understand
they are the owners of unstable (might be wrong here too)? Again,
everyone's welcome to chime in at any time, just trying to clarify
who's responsible for what here.

> Here is how it seems to me:
>
>   - the specification applies cleanly to our stable releases, and we
> want to support it, so we ship the appropriate metadata
>
>   - it applies to testing during the later stages of the freeze, and
> indeed we ship correct metadata at that time
>
>   - it does not apply to testing the rest of the time, and it never
> applies to unstable.  We ship metadata, but only as a side-effect of
> our process for preparing stable releases.
>
> If this is right, then the goal should not be to ship correct metadata
> in testing and unstable, because that's impossible.
> The goal should simply be to make whatever we ship in testing and
> unstable relatively unobtrusive to users.

If I understand correctly what you mean by "apply" here, and you mean
in terms of the specification and what it is meant for, then as one of
the owners of the spec I can say with certainty that the spec applies
to testing and unstable, at any time. There is nothing incompatible
with the way testing and unstable exist, are created, handled,
maintained, used or anything else, and they are nothing "special"
compared to other distributions, other than in the fact that the spec
is not implemented correctly in unstable. There should not be any
doubt on any of this, solely from the point of view of what the
specification is for and what its goals are. One can of course
disagree on whether it should be implemented as such and where, which
is what is happening right now.
If you mean it in terms of what is currently implemented in Debian,
then that's also inaccurate: the spec is currently correctly
implemented in testing, where it says VERSION_CODENAME=trixie at all
times. It is incorrectly implemented in unstable, since also there it
says VERSION_CODENAME=trixie, which makes it buggy, as sid is
obviously not trixie, and that's the main change I am asking to
implement. I'll note again that it is perfectly ok to omit VERSION_ID
until release time, and in one of the replies I am clarifying that, if
there are reasons to leave it out, it is ok to do so, and I am not
asking the CTTE to overrule that.

Also, speaking as someone who has worked on image building tools for
many years, the current state is extremely intrusive for users, and
that's why I am trying to fix it.

> Possibly it's less obtrusive to always ship "trixie" in both testing and
> unstable, rather than the special "trixie/sid" value.  Or maybe not.
> Santiago doesn't think so; it would be good to hear why, in this bug.
>
> I'd also like to note, in response to Luca, that it's misleading to say
> that it's a frankendebian to have packages from sid installed on a
> testing system, because that's

Bug#1077844: pkg-perl-tools: Last upload seems to be wrong

2024-08-03 Thread Étienne Mollier

Control: affects 1074038 + 1077844
Control: block 1077844 by 1074038

Thanks Frederic-Emmanuel!  For what it's worth, this:

> Last upload
> ===
> Uploads for orange-canvas-core:
> 0.1.31-3 to unstable: Roland Mas  on Tue, 15 Aug 2023 
> 13:20:27 +
[…]
> the version in unstable is 0.2.1-3 but the last reported
> version is 0.1.31-3 whcih is the testing verion.

seems related to #1074038 affecting who-uploads in
devscripts, but I haven't checked closely yet.

Hope this helps,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/0, please excuse my verbosity
   `-on air: Dream Theater - Hell's Kitchen-Lines in the Sa…


signature.asc
Description: PGP signature

Bug#1077844: pkg-perl-tools: Last upload seems to be wrong

2024-08-03 Thread Picca Frédéric-Emmanuel

Package: pkg-perl-tools
Version: 0.79
Severity: normal
X-Debbugs-Cc: pi...@debian.org

Dear Maintainer,

When preparing one of my package, I did

orange-canvas-core$ dpt prepare

gbp pull

gbp:info: Fetching from default remote for each branch
gbp:info: Branch 'upstream' is already up to date.
gbp:info: Branch 'pristine-tar' is already up to date.
gbp:info: Branch 'master' is already up to date.

Bugs

None \o/

rmadison

orange-canvas-core | 0.1.31-3  | testing | source
orange-canvas-core | 0.2.1-3   | buildd-unstable | source
orange-canvas-core | 0.2.1-3   | unstable| source

grep-excuses

Excuse for orange-canvas-core

  • Migration status for orange-canvas-core (0.1.31-3 to 0.2.1-2): BLOCKED: 
Maybe temporary, maybe blocked but Britney is missing information (check below)
  • Issues preventing migration:
  □ Not built on buildd: upload info for arch all binaries not found, a new 
source-only upload is needed to allow migration
  □ Too young, only 1 of 2 days old
  □ Build-Depends(-Arch): orange-canvas-core python-requests-cache (not 
considered)
  □ Depends: orange-canvas-core python-requests-cache (not considered)
  • Additional info:
  □ Piuparts tested OK - 
https://piuparts.debian.org/sid/source/o/orange-canvas-core.html
  □ autopkgtest for orange-canvas-core/0.2.1-2: amd64: Pass, arm64: Pass, 
armel: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: Pass
  □ Waiting for reproducibility test results on amd64 - info ♻
  □ Waiting for reproducibility test results on arm64 - info ♻
  □ Waiting for reproducibility test results on armhf - info ♻
  □ Reproducible on i386 - info ♻
  □ Required age reduced by 3 days because of autopkgtest
  • Depends: orange-canvas-core python-requests-cache

Excuses generated on: Sat Aug 3 08:05:46 2024 UTC

Last upload
===
Uploads for orange-canvas-core:
0.1.31-3 to unstable: Roland Mas  on Tue, 15 Aug 2023 
13:20:27 +

Popcon
==

Key package?

✘ orange-canvas-core is no key package

CI (amd64)
==
  suite   |date | version  | status
--+-+--+
 testing  | 2024-08-01 10:56:59 | 0.1.31-3 |   ✔
 unstable | 2024-07-28 12:33:29 | 0.1.31-3 |   ✔

New upstream release?
=
None \o/

Git diff against last Debian tag

None \o/

the version in unstable is 0.2.1-3 but the last reported version is 0.1.31-3 
whcih is the testing verion.

I think that this is wrong.

Cheers

Fred


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages pkg-perl-tools depends on:
ii  curl 8.9.1-1
ii  debhelper13.16
ii  devscripts   2.23.7
ii  dh-make-perl 0.125
ii  git  1:2.45.2-1
ii  git-buildpackage 0.9.34
ii  libdatetime-perl 2:1.65-1+b1
ii  libdebian-source-perl0.125
ii  libdpkg-perl 1.22.11
ii  libgit-repository-perl   1.325-3
ii  libgitlab-api-v4-perl0.27-1
ii  libipc-run-perl  20231003.0-2
ii  libjson-xs-perl  4.030-2+b3
ii  libpath-tiny-perl0.146-1
ii  libproc-invokeeditor-perl1.13-3
ii  librt-client-rest-perl   1:0.72-1
ii  libtry-tiny-perl 0.31-2
ii  libutf8-all-perl 0.024-3
ii  lintian  2.118.0
ii  openssh-client [ssh-client]  1:9.8p1-1
ii  perl 5.38.2-5
ii  pristine-tar 1.50+nmu2
ii  quilt0.68-1

Versions of packages pkg-perl-tools recommends:
ii  autodep8  0.28+nmu1
ii  autopkgtest   5.37
ii  cme   1.040-1
ii  libarray-utils-perl   0.5-3
ii  libconfig-model-dpkg-perl 3.005
ii  libconfig-model-perl  2.154-1
ii  libdebian-copyright-perl  0.2-6
ii  libfile-slurp-perl.32-2
ii  libmime-lite-perl 3.033-2
ii  libmodule-inspector-perl  1.05-3
ii  libnet-github-perl

Bug#1076496: transition: java-common

2024-08-03 Thread Graham Inggs

Control: tags -1 confirmed

Hi Matthias

On Wed, 17 Jul 2024 at 17:18, Matthias Klose  wrote:
> updating from OpenJDK 17 to OpenJDK 21, as discussed in
> https://lists.debian.org/debian-java/2024/07/msg1.html

>From the list of bugs filed [1], only four packages are not already
fixed, pending, or tagged 'patch'.  Of these, three are not in
testing, and one is fixed in Salsa, but not tagged.

Please go ahead.

Regards
Graham


[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java21;users=debian-j...@lists.debian.org

Bug#1076078: mt7921e: Unable to connect to wireless network after hibernate

2024-08-03 Thread pablo joubert

Package: src:linux
Version: 6.9.12-1
Followup-For: Bug #1076078

Dear Maintainer,

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

I encounter the same behavior than this bug, except that I use suspend instead
of hibernate. The issue is the same, the mt7921e module fails to be up

The solution I found to get back access to the wifi is to remove the module and
insert it after waking up. 

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


-- Package-specific info:
** Version:
Linux version 6.9.12-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.3.0-3) 13.3.0, GNU ld (GNU Binutils for 
Debian) 2.42.90.20240720) #1 SMP PREEMPT_DYNAMIC Debian 6.9.12-1 (2024-07-27)

** Command line:
BOOT_IMAGE=/vmlinuz-6.9.12-amd64 root=/dev/mapper/holothurie--vg-root ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:

[   58.640372] mt7921e :06:00.0: Message 00020007 (seq 15) timeout
[   58.641132] mt7921e :06:00.0: PM: dpm_run_callback(): 
pci_pm_resume+0x0/0xf0 returns -110
[   58.641154] mt7921e :06:00.0: PM: failed to resume async: error -110
[   58.721447] mt7921e :06:00.0: Failed to get patch semaphore
[   58.722076] mt7921e :06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x000a address=0xffc08780 flags=0x]
[   61.968668] mt7921e :06:00.0: Message 0010 (seq 13) timeout
[   61.968681] mt7921e :06:00.0: Failed to get patch semaphore
[   65.040490] mt7921e :06:00.0: Message 46ed (seq 14) timeout
[   65.040513] [ cut here ]
[   65.040516] Hardware became unavailable upon resume. This could be a 
software issue prior to suspend or a hardware issue.
[   65.040567] WARNING: CPU: 12 PID: 3530 at net/mac80211/util.c:1826 
ieee80211_reconfig+0x9c/0x14f0 [mac80211]
[   65.040674] Modules linked in: ctr ccm snd_seq_dummy snd_hrtimer snd_seq 
snd_seq_device qrtr cmac algif_hash algif_skcipher af_alg bnep sunrpc btusb 
btrtl btintel btbcm btmtk bluetooth sha3_generic jitterentropy_rng drbg 
ansi_cprng ecdh_generic ecc uvcvideo binfmt_misc videobuf2_vmalloc uvc 
videobuf2_memops videobuf2_v4l2 videodev nls_ascii nls_cp437 vfat fat 
videobuf2_common mc mt7921e mt7921_common amd_atl intel_rapl_msr 
intel_rapl_common mt792x_lib mt76_connac_lib snd_sof_amd_rembrandt amdgpu 
snd_sof_amd_acp mt76 snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_ctl_led 
mac80211 snd_hda_codec_realtek snd_sof_utils snd_pci_ps snd_amd_sdw_acpi 
snd_hda_codec_generic soundwire_amd soundwire_generic_allocation edac_mce_amd 
snd_hda_scodec_component snd_soc_core snd_hda_codec_hdmi kvm_amd snd_hda_intel 
snd_compress snd_intel_dspcfg snd_intel_sdw_acpi libarc4 joydev 
snd_pcm_dmaengine ledtrig_audio kvm snd_hda_codec soundwire_bus cfg80211 
snd_hda_core snd_rpl_pci_acp6x thinkpad_acpi snd_hwdep snd_pci_acp6x rapl 
snd_pcm
[   65.040830]  snd_pci_acp5x nvram snd_timer think_lmi platform_profile 
ucsi_acpi snd_rn_pci_acp3x firmware_attributes_class snd snd_acp_config 
typec_ucsi wmi_bmof ccp snd_soc_acpi sp5100_tco hid_sensor_accel_3d typec 
soundcore snd_pci_acp3x hid_sensor_trigger watchdog hid_sensor_iio_common roles 
k10temp industrialio_triggered_buffer kfifo_buf rfkill ac industrialio button 
evdev hid_multitouch serio_raw
[   65.040886] mt7921e :06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x000a address=0xffc02300 flags=0x]
[   65.040889]  amdxcp
[   65.040891]  drm_exec gpu_sched drm_buddy drm_suballoc_helper 
drm_display_helper cec rc_core drm_ttm_helper ttm drm_kms_helper i2c_algo_bit 
msr parport_pc ppdev lp parport efi_pstore configfs nfnetlink efivarfs 
ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt 
dm_mod crc32_pclmul i2c_hid_acpi xhci_pci i2c_hid nvme hid_sensor_hub 
crc32c_intel hid_generic xhci_hcd nvme_core drm t10_pi ghash_clmulni_intel 
crc64_rocksoft_generic usbcore sha256_ssse3 psmouse crc64_rocksoft sha1_ssse3 
crc_t10dif crct10dif_generic crct10dif_pclmul crc64 i2c_piix4 amd_sfh 
usb_common video crct10dif_common battery hid wmi sha512_ssse3 sha512_generic 
aesni_intel crypto_simd cryptd
[   65.041022] CPU: 12 PID: 3530 Comm: kworker/u64:35 Not tainted 6.9.12-amd64 
#1  Debian 6.9.12-1
[   65.041030] Hardware name: LENOVO 21B9CTO1WW/21B9CTO1WW, BIOS R1TET45W (1.24 
) 02/23/2024
[   65.041035] Workqueue: async async_run_entry_fn
[   65.041046] RIP: 0010:ieee80211_reconfig+0x9c/0x14f0 [mac80211]
[   65.041125] Code: 02 00 00 41 c6 87 ad 05 00 00 00 4c 89 ff e8 9b 8e fb ff 
41 89 c5 85 c0 0f 84 ff 02 00 00 48 c7 c7 a8 c4 4f c1 e8 64 9f 68 e6 <0f> 0b eb 
2d 84 c0 0f 85 95 01 00 00 c6 87 ad 05 00 00 00 e8 6c 8e
[   65.041129] RSP: 0018:9d5e4ca2bce8 EFLAGS: 00010282
[   65.041134] RAX:  RBX: 8ce206b90538 RCX: 0027
[   65.041138] RDX: 8ce4df021708 RSI: 0001 RDI: 8ce4df021700
[   65.041141] RBP:  R08:  R09: 0003
[   65.041144] R10: 9d5e4ca2bab8 R11:

Bug#1077843: popularity-contest: Have separate column for "installed but no atime"


Package: popularity-contest
Version: 1.77
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net

Hi,

The popularity-contest provides the columns `Inst`, `Vote`, `Old`, 
`Recent` and `No Files`.


I feel it would be interesting to see how many are `Old` because the 
system has disabled `atime` on its mount point (either directly or 
because the mount point is read-only). For these systems, you can 
basically never get a `Vote` - at least you will see a `Recent` as I 
understand the current logic.


Therefore, I would like to see popularity-contest track whether the 
mount points would ever update its atime (the mount flags I know of that 
are relevant are `noatime` or `ro`[1]) when popularity-contest tracks 
whether it should count a given file as giving a Vote.


I see this proposal as an alternative to #87619 that does not rely on a 
new dependency (/etc/mtab, /proc/mounts, or `mount` can all provide the 
data)


As far as privacy concerns, it may warrant a configuration toogle. I 
have a minor preference for it being opt-out, but opt-in would be fine 
for me as well.


Best regards,
Niels

[1]: As I understand it, `nodiratime` and `relatime` would both be 
non-issues as programs would still get some `atime` access.

Bug#1077842: smifb2-dkms: module fails to build for Linux 6.10: error: implicit declaration of function 'vmalloc'

Package: smifb2-dkms
Version: 2.3.0.9.g20b8ef5-1
Severity: important
Tags: upstream

smifb2-dkms fails to build a module for Linux 6.10 in experimental:

/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_drv.c: In function 
'smi_vram_suspend':
/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_drv.c:234:27: error: implicit 
declaration of function 'vmalloc'; did you mean 'kvmalloc'? 
[-Werror=implicit-function-declaration]
  234 | sdev->vram_save = vmalloc(vram_size << 20);
  |   ^~~
  |   kvmalloc
/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_drv.c:234:25: warning: 
assignment to 'void *' from 'int' makes pointer from integer without a cast 
[-Wint-conversion]
  234 | sdev->vram_save = vmalloc(vram_size << 20);
  | ^
/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_drv.c:244:17: error: implicit 
declaration of function 'vfree'; did you mean 'kvfree'? 
[-Werror=implicit-function-declaration]
  244 | vfree(sdev->vram_save);
  | ^
  | kvfree
/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c: In function 
'smi_driver_load':
/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c:399:25: error: implicit 
declaration of function 'vmalloc'; did you mean 'kvmalloc'? 
[-Werror=implicit-function-declaration]
  399 | cdev->regsave = vmalloc(1024);
  | ^~~
  | kvmalloc
/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c:399:23: warning: 
assignment to 'struct smi_750_register *' from 'int' makes pointer from integer 
without a cast [-Wint-conversion]
  399 | cdev->regsave = vmalloc(1024);
  |   ^
/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c: In function 
'smi_driver_unload':
/var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c:447:9: error: implicit 
declaration of function 'vfree'; did you mean 'kvfree'? 
[-Werror=implicit-function-declaration]
  447 | vfree(cdev->regsave);
  | ^
  | kvfree


Andreas

Bug#1077841: build error for kernel 6.10.2

2024-08-03 Thread Harald Dunkel

Package: nvidia-kernel-dkms
Version: 545.23.06-1

nvidia-kernel-dkms doesn't build for upstream's 6.10.2 kernel:

:
/var/lib/dkms/nvidia-current/545.23.06/build/nvidia/os-mlock.c: In function 
'nv_follow_pfn':
/var/lib/dkms/nvidia-current/545.23.06/build/nvidia/os-mlock.c:36:12: error: 
implicit declaration of function 'follow_pfn'; did you mean 'follow_pte'? 
[-Wimplicit-function-declaration]
   36 | return follow_pfn(vma, address, pfn);
  |^~
  |follow_pte
make[3]: *** [scripts/Makefile.build:244: 
/var/lib/dkms/nvidia-current/545.23.06/build/nvidia/os-mlock.o] Error 1
:

AFAIU this problem has been fixed for NVidia's kernel module version
550.107.02.

Regards
Harri

Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building


Helmut Grohne:

Hi Simon and Niels,

(fixed Cc address for architecture-properties maintainers)

On Thu, Aug 01, 2024 at 05:26:04PM +0100, Simon McVittie wrote:

[...]


I talked to Niels off list and he was vaguely positive about riding on
architecture-properties. He had some concerns about the bus factor that
this work might impose on architecture-properties. Guillem also
indicated that he wants to give feedback though not right now.

To me this is sufficient to prototype an implementation. I'm attaching a
patch for architecture-properties that hopefully gets most of the
details right (thanks to Simon's design feedback). If you prefer
reviewing it on salsa, go
https://salsa.debian.org/debian/architecture-properties/-/merge_requests/1

I request that we give people at least one week to reply before
uploading this. I appreciate feedback from Niels as to how acceptable he
finds this contribution.


I think I am good to go on this one. I would rely on someone else to 
keep up with the "hacks" required to detect emulations if the current 
check stops working and I would not use my self directly, so the tests 
mentioned below would be relevant or we do consumer based testing.


Those are the limitations I currently see. The code looks like it would 
be relatively stable and small enough that I can throw it directly at 
the C compiler maintainers if it ever ICEs or miscompiles.



[...]

Writing tests is a bit non-trivial. Whilst Ubuntu has pioneered an
autopkgtest extension for cross architecture testing, this does not seem
to be available in Debian. Testing the native case is rather boring in
my view. As for manual testing, I verified that :amd64 (natively), :i386
(without installing qemu), and :armhf (qemu) work as expected on amd64.



It would be boring to test the native flow, but it would still assert 
that the code minimally works. Therefore, I think we should have that 
test case. It would at the very least catch miscompiles where the 
c-program just SEGVs due to a miscompile.


For the non-native case, I think we could emulate that by playing with 
PATH and use that to mock `readlink` into an `echo /usr/bin/qemu` if we 
wanted to test the detection. I think that could also be used to trigger 
at least one of the error cases by having the mocked `readlink` return 
non-zero?


If we could get proper non-native tests as well, that would surely be 
better.



In the event that dpkg gains the Provides suggested by Simon, we can
delete both native-architecture and native-architecture-is.

Helmut


Sounds good to me.

Best regards,
Niels

Bug#1077840: falcosecurity-scap-dkms: module fails to build for Linux 6.10: error: implicit declaration of function 'fd_is_open'

Package: falcosecurity-scap-dkms
Version: 0.15.1-4
Severity: important
Tags: upstream

falcosecurity-scap-dkms fails to build a module for Linux 6.10 in experimental:

DKMS make.log for scap-0.15.1 for kernel 6.10-amd64 (x86_64)
Sat Aug  3 06:54:49 UTC 2024
make: Entering directory '/usr/src/linux-headers-6.10-amd64'
[configure-kmod] Including 
/var/lib/dkms/scap/0.15.1/build//configure/DEVNODE_ARG1_CONST/Makefile.inc 
/var/lib/dkms/scap/0.15.1/build//configure/CLASS_CREATE_1/Makefile.inc 
/var/lib/dkms/scap/0.15.1/build//configure/ACCESS_OK_2/Makefile.inc
[configure-kmod] Setting HAS_DEVNODE_ARG1_CONST flag
[configure-kmod] Setting HAS_CLASS_CREATE_1 flag
[configure-kmod] Setting HAS_ACCESS_OK_2 flag
  CC [M]  /var/lib/dkms/scap/0.15.1/build/main.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/dynamic_params_table.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/fillers_table.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/flags_table.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/ppm_events.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/ppm_fillers.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/event_table.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/syscall_table64.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/ppm_cputime.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/ppm_tp.o
  CC [M]  /var/lib/dkms/scap/0.15.1/build/syscall_ia32_64_map.o
/var/lib/dkms/scap/0.15.1/build/ppm_cputime.c:353:10: warning: no previous 
prototype for 'nsec_to_clock_t' [-Wmissing-prototypes]
  353 | uint64_t nsec_to_clock_t(uint64_t x)
  |  ^~~
/var/lib/dkms/scap/0.15.1/build/main.c: In function 'drop_nostate_event':
/var/lib/dkms/scap/0.15.1/build/main.c:1653:22: error: implicit declaration of 
function 'fd_is_open'; did you mean 'finish_open'? 
[-Werror=implicit-function-declaration]
 1653 | !fd_is_open(close_fd, fdt)
  |  ^~
  |  finish_open
/var/lib/dkms/scap/0.15.1/build/main.c: At top level:
/var/lib/dkms/scap/0.15.1/build/main.c:2829:5: warning: no previous prototype 
for 'scap_init' [-Wmissing-prototypes]
 2829 | int scap_init(void)
  | ^
/var/lib/dkms/scap/0.15.1/build/main.c:2992:6: warning: no previous prototype 
for 'scap_exit' [-Wmissing-prototypes]
 2992 | void scap_exit(void)
  |  ^
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:509:14: warning: no previous 
prototype for 'ppm_get_mm_exe_file' [-Wmissing-prototypes]
  509 | struct file *ppm_get_mm_exe_file(struct mm_struct *mm)
  |  ^~~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:550:15: warning: no previous 
prototype for 'ppm_get_mm_counter' [-Wmissing-prototypes]
  550 | unsigned long ppm_get_mm_counter(struct mm_struct *mm, int member)
  |   ^~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:728:5: warning: no previous 
prototype for 'accumulate_argv_or_env' [-Wmissing-prototypes]
  728 | int accumulate_argv_or_env(const char __user * __user *argv,
  | ^~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:874:6: warning: no previous 
prototype for 'ppm_is_upper_layer' [-Wmissing-prototypes]
  874 | bool ppm_is_upper_layer(struct file *exe_file){
  |  ^~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:2269:5: warning: no previous 
prototype for 'f_sys_send_e_common' [-Wmissing-prototypes]
 2269 | int f_sys_send_e_common(struct event_filler_arguments *args, int *fd)
  | ^~~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:2405:5: warning: no previous 
prototype for 'f_sys_recv_x_common' [-Wmissing-prototypes]
 2405 | int f_sys_recv_x_common(struct event_filler_arguments *args, int64_t 
*retval)
  | ^~~
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: 
/var/lib/dkms/scap/0.15.1/build/main.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [/usr/src/linux-headers-6.10-common/Makefile:1959: 
/var/lib/dkms/scap/0.15.1/build] Error 2
make: *** [/usr/src/linux-headers-6.10-common/Makefile:252: __sub-make] Error 2
make: Leaving directory '/usr/src/linux-headers-6.10-amd64'

Andreas

Bug#1077839: rtpengine-kernel-dkms: module fails to build for Linux 6.10: error: too few arguments to function 'ip_route_output'

Package: rtpengine-kernel-dkms
Version: 11.5.1.25-1
Severity: important
Tags: upstream

rtpengine-kernel-dkms fails to build a module for Linux 6.10 in experimental:

DKMS make.log for rtpengine-11.5.1.25 for kernel 6.10-amd64 (x86_64)
Sat Aug  3 06:54:45 UTC 2024
make: Entering directory '/usr/src/linux-headers-6.10-amd64'
  CC [M]  /var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.o
/var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.c: In function 
'send_proxy_packet4':
/var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.c:4023:14: error: too few 
arguments to function 'ip_route_output'
 4023 | rt = ip_route_output(net, dst->u.ipv4, src->u.ipv4, tos, 0);
  |  ^~~
In file included from /usr/src/linux-headers-6.10-common/include/net/ip.h:30,
 from 
/usr/src/linux-headers-6.10-common/include/net/ip6_checksum.h:27,
 from /var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.c:5:
/usr/src/linux-headers-6.10-common/include/net/route.h:157:30: note: declared 
here
  157 | static inline struct rtable *ip_route_output(struct net *net, __be32 
daddr,
  |  ^~~
make[2]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: 
/var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.o] Error 1
make[1]: *** [/usr/src/linux-headers-6.10-common/Makefile:1959: 
/var/lib/dkms/rtpengine/11.5.1.25/build] Error 2
make: *** [/usr/src/linux-headers-6.10-common/Makefile:252: __sub-make] Error 2
make: Leaving directory '/usr/src/linux-headers-6.10-amd64'


Andreas

Bug#1077838: openvpn-dco-dkms: module fails to build for Linux 6.10: error: expected declaration specifiers or '...' before string constant

Package: openvpn-dco-dkms
Version: 0.0+git20231103-1
Severity: important
Tags: upstream sid trixie

openvpn-dco-dkms fails to build a module for Linux 6.10 in experimental:

DKMS make.log for ovpn-dco-0.0+git20231103 for kernel 6.10-amd64 (x86_64)
Sat Aug  3 06:54:37 UTC 2024
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/gen-compat-autoconf.sh 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/compat-autoconf.h
make -C /lib/modules/6.10-amd64/build 
M=/var/lib/dkms/ovpn-dco/0.0+git20231103/build 
PWD=/var/lib/dkms/ovpn-dco/0.0+git20231103/build REVISION=0.0+git20231103 
CONFIG_OVPN_DCO_V2=m INSTALL_MOD_DIR=updates/modules
make[1]: Entering directory '/usr/src/linux-headers-6.10-amd64'
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/main.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/bind.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/crypto.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/ovpn.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/peer.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/sock.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/stats.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/netlink.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/crypto_aead.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/pktid.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/tcp.o
  CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/udp.o
In file included from 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/crypto.h:16,
 from 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/addr.h:13,
 from 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/peer.h:13,
 from 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/ovpn.h:14,
 from 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/main.c:12:
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/include/uapi/linux/ovpn_dco.h:14:22:
 error: expected declaration specifiers or '...' before string constant
   14 | #define OVPN_NL_NAME "ovpn-dco-v2"
  |  ^
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/main.c:263:26:
 note: in expansion of macro 'OVPN_NL_NAME'
  263 | MODULE_ALIAS_GENL_FAMILY(OVPN_NL_NAME);
  |  ^~~~
make[4]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/main.o] Error 
1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:490: 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco] Error 2
make[2]: *** [/usr/src/linux-headers-6.10-common/Makefile:1959: 
/var/lib/dkms/ovpn-dco/0.0+git20231103/build] Error 2
make[1]: *** [/usr/src/linux-headers-6.10-common/Makefile:252: __sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.10-amd64'
make: *** [Makefile:59: all] Error 2


Andreas

Bug#1077837: openafs-modules-dkms: module fails to build for Linux 6.10: error: 'vmalloc' undeclared

Package: openafs-modules-dkms
Version: 1.8.12~pre1-1
Severity: important
Tags: upstream fixed-upstream
Control: forwarded -1 
http://git.openafs.org/?p=openafs.git;a=commit;h=658942f2791fad5e33ec7542158c16dfc66eed39

openafs-modules-dkms fails to build a module for Linux 6.10 in experimental:

  CC [M]  
/var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.o
/var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.c:
 In function 'linux_alloc_init':
/var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.c:212:37:
 error: 'vmalloc' undeclared (first use in this function); did you mean 
'mm_alloc'?
  212 | (void *)vmalloc, local_free);
  | ^~~
  | mm_alloc
/var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.c:212:37:
 note: each undeclared identifier is reported only once for each function it 
appears in
make[5]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: 
/var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.o]
 Error 1


Andreas

Bug#1077836: latexdiff: processing 13-page document takes indefinite time (11 hours so far)

2024-08-03 Thread Manny

Package: latexdiff
Version: 1.3.2-1
Severity: important
Tags: upstream
X-Debbugs-Cc: frederik.tilm...@gfz-potsdam.de, 
debbug.latexd...@sideload.33mail.com

This was executed:

  $ latexdiff report_old.tex report_new.tex > report_diff.tex

After 11 hours the process is still running hard with CPU pegged
around 99% according to /top/. CPU fan is running which also indicates
hard work is being done. There is no output to indicate how much
progress has been made.

When compiled, the document yields 13 pages in PDF form. I do not
imagine that 11+ hours is reasonable for that volume. Bug fixes and
enhancements are needed.

 ① There is likely some kind of faulty logic such as an endless loop
 ② A progress indicator is needed
 ③ A detailed debug log is needed
 ④ Periodic assessments should be made throughout the processing as to
whether reasonable progress is being made. If an hour is spent on a
normal sized paragraph, the tool should abort and perhaps give an
indication of which segment of text is exceeding time
thresholds. This should be configurable but many users don’t know
what to expect so there should be a reasonable default.

I’ve seen latexdiff take forever in past executions and had to give up
and kill it. The document latexdiff struggles with at the moment is a
bilingual document that uses parcolumns to produce a left and right
column.

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

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

Versions of packages latexdiff depends on:
ii  perl  5.36.0-7+deb12u1

Versions of packages latexdiff recommends:
ii  texlive-latex-base 2022.20230122-3
ii  texlive-latex-extra2022.20230122-4
ii  texlive-latex-recommended  2022.20230122-3
ii  texlive-plain-generic  2022.20230122-4

Versions of packages latexdiff suggests:
ii  git  1:2.39.2-1.1

-- no debconf information

Bug#1077835: zfs-dkms: module fails to build for Linux 6.10