Bug#1070821: Turns out to be flaky tests

2024-05-11 Thread Reinhard Tartler
Control: Severity -1 important
Control: Retitle -1 testsuite is flaky

Looking at the build failures, there appears to be at least two tests that
are flaky.

One being in daemon/logger:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-3/engine/daemon/logger/copier_test.go/#L261-L265

The other one manifesting as a segfault:

=== FAIL: daemon TestExecSetPlatformOpt (0.00s)
panic: runtime error: invalid memory address or nil pointer
dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x2424ce6]

goroutine 101 [running]:
testing.tRunner.func1.2({0x26d8820, 0x4032710})
/usr/lib/go-1.22/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
/usr/lib/go-1.22/src/testing/testing.go:1634 +0x377
panic({0x26d8820?, 0x4032710?})
/usr/lib/go-1.22/src/runtime/panic.go:770
+0x132github.com/docker/docker/daemon.(*Daemon).execSetPlatformOpt.WithRlimits.func1({0x30820c0?,
0x413aba0?}, {0x0?, 0x0?}, 0x0?, 0xc000a49810)

/<>/_build/src/github.com/docker/docker/daemon/oci_linux.go:46
+0x46github.com/docker/docker/daemon.(*Daemon).execSetPlatformOpt(0xc000aa1d88,
0xc000aa1b40, 0xc000aa1998?, 0xc000aa1970)

/<>/_build/src/github.com/docker/docker/daemon/exec_linux.go:54
+0x503github.com/docker/docker/daemon.TestExecSetPlatformOpt(0xc000a77a00)

/<>/_build/src/github.com/docker/docker/daemon/exec_linux_test.go:26
+0x155
testing.tRunner(0xc000a77a00, 0x2aaeba0)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/usr/lib/go-1.22/src/testing/testing.go:1742 +0x390


Source code here:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-3/engine/daemon/oci_linux.go/#L46


not sure what makes them trigger.  Maybe machines got faster and it is
easier to trigger these issues? Not sure how to go about this, besides
removing the two tests in question.


-- 
regards,
Reinhard


Bug#1070964: nbd@.service should depend on modprobe@nbd.service

2024-05-11 Thread Rob Leslie
Package: nbd-client
Version: 1:3.24-1.1
Severity: normal
File: /lib/systemd/system/nbd@.service

Dear Maintainer,

It seems that since nbd-client depends on the nbd kernel module to function, the
nbd@.service unit should ensure this is loaded, e.g.:

[Unit]
Requires=modprobe@nbd.service
After=modprobe@nbd.service


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

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

Versions of packages nbd-client depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u7
ii  libgnutls303.7.9-2+deb12u2
ii  libnl-3-2003.7.0-0.2+b1
ii  libnl-genl-3-200   3.7.0-0.2+b1

nbd-client recommends no packages.

nbd-client suggests no packages.

-- Configuration Files:
/etc/nbdtab changed [not included]

-- debconf information excluded



Bug#1022540: build-essential: please add riscv64 support

2024-05-11 Thread Bo YU

Hi,

On Wed, Sep 13, 2023 at 12:59:02PM +0200, Matthias Klose wrote:
the package won't migrate, afaiu. we have to have a testing pocket 
first. I don't want to upload a package which is not able to migrate.


Maybe you have noticed testing for riscv64 which has been created, so
could you add support riscv64 for this package? IIUC, Helmut needs it to
setup crossbuild for riscv64 also.

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature


Bug#1065926: Moving python-docker 5.0.3-1 to Python 3.12 will result in breaking changes

2024-05-11 Thread A. Karl Kornel

Hello!

I came across this bug as I was writing up Ubuntu bug 2061929.  
Unfortunately, python-docker 5.0.3-1 will break if Python3 moves to 
3.12.  There are at least two different issues:


• python-docker 5.0.3 relies on code from distutils, at runtime.  The 
workaround for this is to rewrite the code, or to instead rely on 
python3-setuptools.


• python-docker uses the requests & urllib3 modules in ways that break 
in newer versions.  The breakage is in how the docker module talks to 
local Docker daemons through a UNIX socket.  The only way to resolve 
this is a code change.


There may be other breakages with python-docker 5.x and Python 3.12; I 
cannot say for certain.


I came across this with Ubuntu 24.04, because they moved python3 to 
3.12.  More details, along with possible patches, can be found in 
https://bugs.launchpad.net/ubuntu/+source/python-docker/+bug/2061929


--
~ Karl Kornel



Bug#1070963: webkit2-sharp: FTBFS: ‘WebKitWebViewBase’ {aka ‘struct _WebKitWebViewBase’} has no member named ‘parentInstance’

2024-05-11 Thread Santiago Vila

Package: src:webkit2-sharp
Version: 2.10.9+git20160917-1.1
Severity: serious
Control: close -1 2.10.9+git20160917-1.1+rm
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
dh build --parallel --with autoreconf --with cli
dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
   dh_update_autotools_config -O--parallel
   dh_autoreconf -O--parallel
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:7: installing './compile'
configure.ac:3: installing './config.guess'
configure.ac:3: installing './config.sub'
configure.ac:4: installing './install-sh'
configure.ac:4: installing './missing'
Makefile.am: installing './INSTALL'
doc/Makefile.am:13: warning: addprefix -assembly:, $(ASSEMBLIES: non-POSIX 
variable name
doc/Makefile.am:13: (probably a GNU make extension)
sources/Makefile.am:24: warning: foreach profile,$(PROFILES: non-POSIX variable 
name
sources/Makefile.am:24: (probably a GNU make extension)
sources/Makefile.am:25: warning: foreach profile,$(PROFILES: non-POSIX variable 
name
sources/Makefile.am:25: (probably a GNU make extension)
sources/Makefile.am:26: warning: foreach profile,$(PROFILES: non-POSIX variable 
name
sources/Makefile.am:26: (probably a GNU make extension)
sources/Makefile.am:63: warning: '%'-style pattern rules are a GNU make 
extension
sources/Makefile.am:73: warning: '%'-style pattern rules are a GNU make 
extension
sources/Makefile.am:78: warning: '%'-style pattern rules are a GNU make 
extension
sources/Makefile.am:12: warning: variable 'CUSTOM_SOURCES' is defined but no 
program or
sources/Makefile.am:12: library has 'CUSTOM' as canonical name (possible typo)
sources/Makefile.am:11: warning: variable 'GEN_SOURCES' is defined but no 
program or
sources/Makefile.am:11: library has 'GEN' as canonical name (possible typo)
sources/glue/Makefile.am:11: warning: 'INCLUDES' is the old name for 
'AM_CPPFLAGS' (or '*_CPPFLAGS')
sources/glue/Makefile.am: installing './depcomp'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure --parallel -- --prefix=/usr --libdir=/usr/lib
dh_auto_configure: warning: Compatibility levels before 10 are deprecated 
(level 9 in use)
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking --prefix=/usr --libdir=/usr/lib
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump

Bug#1070962: ruby2.7: FTBFS: failing tests

2024-05-11 Thread Santiago Vila

Package: src:ruby2.7
Version: 2.7.4-1+deb11u1
Severity: serious
Control: close -1 2.7.5-1+rm
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o 
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} + -o 
-type l -printf "symlink  %p
" > debian/autoreconf.before
grep -q ^XDT_ configure.ac
autoreconf -f -i
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o 
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} + -o 
-type l -printf "symlink  %p
" > debian/autoreconf.after
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
cp /usr/share/misc/config.guess tool
cp /usr/share/misc/config.sub tool

[... snipped ...]

[20840/21142] Test_SPrintf#test_format_integer(%#+0.d) = 0.00 s
[20841/21142] Test_SPrintf#test_format_integer(%#+05.d) = 0.00 s
[20842/21142] Test_SPrintf#test_format_integer(%#+05d) = 0.00 s
[20843/21142] Test_SPrintf#test_format_integer(%#+0d) = 0.00 s
[20844/21142] Test_SPrintf#test_format_integer(%+-05.0d) = 0.00 s
[20845/21142] Test_SPrintf#test_format_integer(%+-0d) = 0.00 s
[20846/21142] Test_SPrintf#test_format_integer(%.0d) = 0.00 s
[20847/21142] Test_SPrintf#test_format_integer(%5.0d) = 0.00 s
[20848/21142] Test_SPrintf#test_format_integer(%5d) = 0.00 s
[20849/21142] Test_SPrintf#test_format_integer(%d) = 0.00 s
[20850/21142] Test_SPrintf#test_inspect = 0.00 s
[20851/21142] Test_SPrintf#test_quote = 0.00 s
[20852/21142] Test_SPrintf#test_snprintf_count = 0.00 s
[20853/21142] Test_SPrintf#test_string_prec = 0.00 s
[20854/21142] Test_SPrintf#test_to_str = 0.00 s
[20855/21142] Test_StForeachUnpack#test_st_foreach_check_unpack = 0.00 s
[20856/21142] Test_StForeachUnpack#test_st_foreach_unpack = 0.00 s
[20857/21142] Test_StrEncAssociate#test_dummy_encoding_index_CP50220 = 0.03 s
[20858/21142] Test_StrEncAssociate#test_dummy_encoding_index_CP50221 = 0.03 s
[20859/21142] Test_StrEncAssociate#test_dummy_encoding_index_IBM037 = 0.03 s
[20860/21142] Test_StrEncAssociate#test_dummy_encoding_index_ISO_2022_JP = 0.03 
s
[20861/21142] Test_StrEncAssociate#test_dummy_encoding_index_ISO_2022_JP_2 = 
0.03 s
[20862/21142] Test_StrEncAssociate#test_dummy_encoding_index_ISO_2022_JP_KDDI = 
0.03 s
[20863/21142] Test_StrEncAssociate#test_dummy_encoding_index_UTF_16 = 0.03 s
[20864/21142] Test_StrEncAssociate#test_dummy_encoding_index_UTF_32 = 0.03 s
[20865/21142] Test_StrEncAssociate#test_dummy_encoding_index_UTF_7 = 0.03 s
[20866/21142] Test_StrEncAssociate#test_frozen = 0.00 s
[20867/21142] Test_StrSetLen#test_capacity_equals_to_new_size = 0.00 s
[20868/21142] Test_StrSetLen#test_non_shared = 0.00 s
[20869/21142] Test_StrSetLen#test_shared = 0.00 s
[20870/21142] Test_StringCStr#test_embed = 0.09 s
[20871/21142] Test_StringCStr#test_embedded_from_heap = 0.00 s
[20872/21142] Test_StringCStr#test_frozen = 1.52 s
[20873/21142] Test_StringCStr#test_long = 0.08 s
[20874/21142] Test_StringCStr#test_rb_str_new_frozen_embed = 0.00 s
[20875/21142] Test_StringCStr#test_shared = 0.08 s
[20876/21142] Test_StringCStr#test_wchar_aset = 0.00 s
[20877/21142] Test_StringCStr#test_wchar_chomp! = 0.00 s
[20878/21142] Test_StringCStr#test_wchar_chop! = 0.00 s
[20879/21142] Test_StringCStr#test_wchar_delete! = 0.00 s
[20880/21142] Test_StringCStr#test_wchar_embed = 0.61 s
[20881/21142] Test_StringCStr#test_wchar_long = 0.61 s
[20882/21142] Test_StringCStr#test_wchar_lstrip! = 0.00 s
[20883/21142] Test_StringCStr#test_wchar_replace = 0.00 s
[20884/21142] Test_StringCStr#test_wchar_rstrip! = 0.00 s
[20885/21142] Test_StringCStr#test_wchar_squeeze! = 0.00 s
[20886/21142] Test_StringCStr#test_wchar_sub! = 0.00 s
[20887/21142] Test_StringCStr#test_wchar_tr! = 0.00 s
[20888/21142] Test_StringCStr#test_wchar_tr_s! = 0.00 s
[20889/21142] Test_StringCapacity#test_capacity_embedded = 0.00 s
[20890/21142] Test_StringCapacity#test_capacity_frozen = 0.00 s
[20891/21142] Test_StringCapacity#test_capacity_fstring = 0.00 s
[20892/21142] Test_StringCapacity#test_capacity_normal = 0.00 s
[20893/21142] Test_StringCapacity#test_capacity_shared = 0.00 s
[20894/21142] Test_StringCapacity#test_io_read = 0.00 s
[20895/21142] Test_StringCapacity#test_literal_capacity = 0.00 s
[20896/21142] Test_StringCapacity#test_s_new_capacity = 0.00 s
[20897/21142] Test_StringCoderange#test_ascii8bit = 0.00 s
[20898/21142] Test_StringCoderange#test_usascii = 0.00 s
[20899/21142] Test_StringCoderange#test_utf8 = 0.00 s
[20900/21142] Test_StringEllipsize#test_longer = 0.00 s
[20901/21142] Test_StringEllipsize#test_negative_length = 0.00 s
[20902/21142] Test_StringEllipsize#test_nonascii = 0.00 s
[20903/21142] 

Bug#1070960: dnprogs: FTBFS: linux/netfilter_decnet.h: No such file or directory

2024-05-11 Thread Santiago Vila

Package: src:dnprogs
Version: 2.65
Severity: serious
Control: close -1 2.65+rm
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
test -f debian/rules
make prefix=/usr RELEASE=true BUILDING_DEB=true
make[1]: Entering directory '/<>'
make[2]: Entering directory '/<>/include'
make[2]: Leaving directory '/<>/include'
make[2]: Entering directory '/<>/libdnet'
gcc -g -O2 -ffile-prefix-map=/<>/libdnet=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -fsigned-char -Wstrict-prototypes -Wall 
-Wno-unused -Wno-uninitialized -I../libdap -I../include -DVERSION=\"2.62\" -D_XOPEN_SOURCE 
-D_BSD_SOURCE -D_GNU_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSHADOW_PWD 
-DDNETUSE_DEVPTS -O2 -Wl,-z,relro -DSYSCONF_PREFIX=\"\" -c -o dnet_htoa.o dnet_htoa.c
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:25,
 from dnet_htoa.c:19:
/usr/include/features.h:187:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are 
deprecated, use _DEFAULT_SOURCE" [-Wcpp]
  187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use 
_DEFAULT_SOURCE"
  |   ^~~
dnet_htoa.c: In function ‘dnet_htoa’:

[... snipped ...]

sethost.c:371:25: warning: pointer targets in passing argument 1 of 
‘getnodebyname’ differ in signedness [-Wpointer-sign]
  371 |  if ( (np=getnodebyname(nodename)) == NULL)
  | ^~~~
  | |
  | unsigned char *
In file included from sethost.c:28:
../include/netdnet/dnetdb.h:31:53: note: expected ‘const char *’ but argument 
is of type ‘unsigned char *’
   31 | extern  struct  nodeent  *getnodebyname(const char *name);
  | ^~~~
sethost.c: In function ‘ct_setup_link’:
sethost.c:538:46: warning: pointer targets in passing argument 1 of ‘strlen’ 
differ in signedness [-Wpointer-sign]
  538 |  accessdata.acc_accl  = strlen(accessdata.acc_acc);
  |~~^~~~
  |  |
  |  unsigned char *
In file included from sethost.c:15:
/usr/include/string.h:385:35: note: expected ‘const char *’ but argument is of 
type ‘unsigned char *’
  385 | extern size_t strlen (const char *__s)
  |   ^~~
sethost.c: In function ‘ct_read_req’:
sethost.c:936:18: warning: pointer targets in passing argument 1 of 
‘ct_echo_prompt’ differ in signedness [-Wpointer-sign]
  936 |   ct_echo_prompt([bufptr]);
  |  ^~~~
  |  |
  |  unsigned char *
sethost.c:862:34: note: expected ‘char *’ but argument is of type ‘unsigned 
char *’
  862 | static void ct_echo_prompt(char *c)
  |~~^
sethost.c: In function ‘ct_write_req’:
sethost.c:1045:42: warning: pointer targets in passing argument 1 of 
‘ct_echo_prompt’ differ in signedness [-Wpointer-sign]
 1045 |if (i < end_of_prompt) ct_echo_prompt([i]);
  |  ^~
  |  |
  |  unsigned char *
sethost.c:862:34: note: expected ‘char *’ but argument is of type ‘unsigned 
char *’
  862 | static void ct_echo_prompt(char *c)
  |~~^
sethost.c:1046:28: warning: pointer targets in passing argument 1 of 
‘ct_echo_input_char’ differ in signedness [-Wpointer-sign]
 1046 |else ct_echo_input_char([i]);
  |^~
  ||
  |unsigned char *
sethost.c:257:38: note: expected ‘char *’ but argument is of type ‘unsigned 
char *’
  257 | static void ct_echo_input_char(char *c)
  |~~^
sethost.c: In function ‘main’:
sethost.c:1832:14: warning: pointer targets in assignment from ‘char *’ to 
‘unsigned char *’ differ in signedness [-Wpointer-sign]
 1832 | nodename = argv[optind];
  |  ^
sethost.c: At top level:
sethost.c:155:13: warning: ‘debug’ is static but used in inline function 
‘set_short’ which is not static
  155 | {   if (debug == 2) { printf(" Entered inline void 
set_short...\n");}
  | ^
sethost.c: In function ‘ct_preinput_proc’:
sethost.c:741:9: warning: ignoring return value of ‘write’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
  741 | write(ttyfd,"\n*output off*\n",14);
  | ^~
sethost.c:743:9: warning: ignoring return value of ‘write’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
  743 | 

Bug#1070961: git-sizer: FTBFS: failing tests

2024-05-11 Thread Santiago Vila

Package: src:git-sizer
Version: 1.3.0+dfsg-1
Severity: serious
Control: close -1 1.5.0-3
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
dh build --buildsystem=golang --with=golang --builddirectory=_build
   dh_update_autotools_config -O--buildsystem=golang -O--builddirectory=_build
   dh_autoreconf -O--buildsystem=golang -O--builddirectory=_build
   dh_auto_configure -O--buildsystem=golang -O--builddirectory=_build
   dh_auto_build -O--buildsystem=golang -O--builddirectory=_build
cd _build && go install -trimpath -v -p 2 github.com/github/git-sizer 
github.com/github/git-sizer/counts github.com/github/git-sizer/git 
github.com/github/git-sizer/isatty github.com/github/git-sizer/meter 
github.com/github/git-sizer/sizes
internal/unsafeheader
internal/cpu
runtime/internal/atomic
runtime/internal/sys
internal/bytealg
runtime/internal/math
internal/race
sync/atomic
unicode
runtime
unicode/utf8
encoding
math/bits
math
internal/testlog
unicode/utf16
github.com/github/git-sizer/isatty
internal/nettrace
runtime/cgo
internal/reflectlite
sync
internal/singleflight
math/rand
errors
sort
io
strconv
bytes
internal/oserror
syscall
reflect
internal/syscall/unix
time
encoding/binary
internal/fmtsort
internal/poll
encoding/base64
internal/syscall/execenv
strings
os
bufio
fmt
path/filepath
io/ioutil
context
os/exec
vendor/golang.org/x/net/dns/dnsmessage
encoding/json
encoding/hex
github.com/github/git-sizer/counts
github.com/github/git-sizer/git
github.com/github/git-sizer/meter
encoding/csv
flag
net
compress/flate
hash
hash/crc32
compress/gzip
text/tabwriter
runtime/pprof
github.com/spf13/pflag
github.com/github/git-sizer/sizes
github.com/github/git-sizer
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
cd _build/src/github.com/github/git-sizer && git init
hint: Using 'master' as the name for the initial branch. This default branch 
name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch 
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m 
Initialized empty Git repository in 
/<>/_build/src/github.com/github/git-sizer/.git/
PATH="/<>/_build/bin:${PATH}" dh_auto_test
cd _build && go test -vet=off -v -p 2 github.com/github/git-sizer 
github.com/github/git-sizer/counts github.com/github/git-sizer/git 
github.com/github/git-sizer/isatty github.com/github/git-sizer/meter 
github.com/github/git-sizer/sizes
=== RUN   TestExec
--- PASS: TestExec (0.01s)
=== RUN   TestBomb
=== PAUSE TestBomb
=== RUN   TestTaggedTags
=== PAUSE TestTaggedTags
=== RUN   TestFromSubdir
=== PAUSE TestFromSubdir
=== RUN   TestSubmodule
=== PAUSE TestSubmodule
=== CONT  TestBomb
=== CONT  TestSubmodule
--- PASS: TestBomb (0.04s)
=== CONT  TestFromSubdir
--- PASS: TestFromSubdir (0.03s)
=== CONT  TestTaggedTags
=== CONT  TestSubmodule
git_sizer_test.go:320:
Error Trace:git_sizer_test.go:320
Error:  Received unexpected error:
exit status 128
Test:   TestSubmodule
Messages:   adding submodule
--- FAIL: TestSubmodule (0.08s)
--- PASS: TestTaggedTags (0.02s)
FAIL
FAILgithub.com/github/git-sizer 0.103s
=== RUN   TestCount32
--- PASS: TestCount32 (0.00s)
=== RUN   TestCount64
--- PASS: TestCount64 (0.00s)
=== RUN   TestMetric
--- PASS: TestMetric (0.00s)
=== RUN   TestBinary
--- PASS: TestBinary (0.00s)
=== RUN   TestLimits32
--- PASS: TestLimits32 (0.00s)
=== RUN   TestLimits64
--- PASS: TestLimits64 (0.00s)
PASS
ok  github.com/github/git-sizer/counts  0.004s
?   github.com/github/git-sizer/git [no test files]
?   github.com/github/git-sizer/isatty  [no test files]
?   github.com/github/git-sizer/meter   [no test files]
?   github.com/github/git-sizer/sizes   [no test files]
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 2 
github.com/github/git-sizer github.com/github/git-sizer/counts 
github.com/github/git-sizer/git github.com/github/git-sizer/isatty 
github.com/github/git-sizer/meter github.com/github/git-sizer/sizes returned exit code 1
make[1]: *** [debian/rules:11: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:


Bug#1068775: sbuild-qemu: fails to work, if piuparts is requested, but not installed on the host

2024-05-11 Thread Francesco Poli
On Sat, 13 Apr 2024 14:50:05 +0200 Francesco Poli wrote:

[...]
> On Fri, 12 Apr 2024 19:57:23 +0200 Johannes Schauer Marin Rodrigues
> wrote:
[...] 
> > Quoting Francesco Poli (wintermute) (2024-04-11 00:13:51)
[...]
> > > Why does sbuild-qemu insist that piuparts be installed on the *host*
> > > system?
> > 
> > Because it needs to be installed on the host. In the same way as autopkgtest
> > needs to be on the host. What can sbuild improve?
> 
> My point is that sbuild{,-qemu} should install piuparts inside the build
> environment (chroot or VM guest system) and run it from within the
> build environment, if this is possible.

If this is possible for piuparts, could you please explain why
sbuild-qemu does not do so?

Otherwise, if this is not possible, could please explain why?

> 
> Does sbuild{,-qemu} do so for lintian?
[...]

I checked: sbuild-qemu (temporarily) installs lintian inside the build
environment and runs it from within the build environment.
I think this is the best strategy, especially for lintian, as I have
previously explained.
That reinforces my opinion that the same strategy should probably be
followed for piuparts, as well...


Anyway, I am having issues in running piuparts, even after installing
it on the host.

I tried to run

  $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm

with the following configuration file:

  $ cat ~/.sbuildrc 
  $source_only_changes = 1;
  $autopkgtest_require_success = 1;
  $lintian_require_success = 0;
  $piuparts_require_success = 1;
  $run_autopkgtest = 1;
  $run_lintian = 1;
  $run_piuparts = 1;
  $build_dir = "$HOME/.cache/sbuild/build";
  
  # don't remove this, Perl needs it:
  1;

It builds the package successfully, but, once it reaches the piuparts
step, sudo asks for my (host system) regular user's password.
My understanding is that it should not need to use sudo, since it should
use the QEMU virtual machine image (where it has root access).
Is that right? Or am I misunderstanding something?

The same thing happens at the autopkgtest step, where, again, sudo asks
for my regular user's password. Once again, this should not be needed:
autopkgtest should use the QEMU virtual machine as a testbed.
At least, when I manually run autopkgtest, I can use the QEMU virtual
machine and no password is asked for.

I tried to modify the configuration file:

  $ cat ~/.sbuildrc
  $source_only_changes = 1;
  $run_lintian = 1;
  $lintian_require_success = 0;
  $run_piuparts = 1;
  $piuparts_root_args = '';
  $piuparts_require_success = 1;
  $run_autopkgtest = 1;
  $autopkgtest_root_args = '';
  $autopkgtest_require_success = 1;
  $build_dir = "$HOME/.cache/sbuild/build";
  
  # don't remove this, Perl needs it:
  1;

It no longer asks for passwords, but fails to run piuparts:

  piuparts
  

  You need to be root to use piuparts.

  E: Piuparts run failed.

And it also fails to run autopkgtest:

  autopkgtest
  ---
  
  autopkgtest [19:56:04]: starting date and time: 2024-05-11 19:56:04+0200
  [...]
  autopkgtest [19:56:05]: test unit_test: preparing testbed
  autopkgtest [19:56:05]: ERROR: "sh -ec
type apt-ftparchive >/dev/null 2>&1 || DEBIAN_FRONTEND=noninteractive 
apt-get install -y apt-utils 2>&1
(cd /tmp/autopkgtest.jrHchc/binaries; apt-ftparchive packages . > Packages; 
apt-ftparchive release . > Release)
printf 'Package: *\nPin: origin ""\nPin-Priority: 1002\n' > 
/etc/apt/preferences.d/90autopkgtest
echo "deb [ trusted=yes ] file:///tmp/autopkgtest.jrHchc/binaries /" 
>/etc/apt/sources.list.d/autopkgtest.list
if [ "x`ls /var/lib/dpkg/updates`" != x ]; then
  echo >&2 "/var/lib/dpkg/updates contains some files, aargh"; exit 1
fi
apt-get --quiet --no-list-cleanup -o 
Dir::Etc::sourcelist=/etc/apt/sources.list.d/autopkgtest.list -o 
Dir::Etc::sourceparts=/dev/null update 2>&1
cp /var/lib/dpkg/status /tmp/autopkgtest.jrHchc/1-apt-update.out
" failed with stderr "sh: 4: cannot create 
/etc/apt/preferences.d/90autopkgtest: Permission denied
  "
  autopkgtest [19:56:05]: Binaries: resetting testbed apt configuration
  Reading package lists...
  E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission 
denied)
  E: Unable to lock directory /var/lib/apt/lists/
  [...]
  E: Autopkgtest run failed.

It seems to me that autopkgtest is not using the QEMU virtual machine
as testbed, or am I wrong?


Why isn't all this working out of the box?
Is there any missing setting in ~/.sbuildrc ?
If this is the case, why isn't sbuild-qemu passing those needed options
by default?

Please explain.
Thanks for your time!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp1PXbWEgVnH.pgp
Description: PGP signature


Bug#1070909: llvm-toolchain-18: FTBFS on riscv64: dh_install: warning: llvm-18-linker-tools missing files: usr/lib/llvm-18/lib/LLVMgold.so

2024-05-11 Thread Aurelien Jarno
control: tag -1 + patch

On 2024-05-11 19:50, Aurelien Jarno wrote:
> On 2024-05-11 15:46, Sebastian Ramacher wrote:
> > Source: llvm-toolchain-18
> > Version: 1:18.1.5-2
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the 
> > past)
> > X-Debbugs-Cc: sramac...@debian.org
> > 
> > riscv64 is now a release architecture and llvm-toolchain-18 built
> > previously.
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-18=riscv64=1%3A18.1.5-2=1715249422=0
> > 
> >debian/rules override_dh_install
> > make[1]: Entering directory '/<>'
> > dh_install -p libpolly-18-dev usr/lib/llvm-18/lib/cmake/polly/*.cmake 
> > usr/lib/llvm-18/lib/cmake/polly
> > rm -rf debian/tmp/usr/lib/llvm-18/lib/cmake/polly/*.cmake
> > dh_install --fail-missing 
> > dh_install: warning: Please use dh_missing --list-missing/--fail-missing 
> > instead
> > dh_install: warning: This feature will be removed in compat 12.
> > dh_install: warning: Cannot find (any matches for) 
> > "usr/lib/llvm-18/lib/LLVMgold.so" (tried in ., debian/tmp)
> > 
> > dh_install: warning: llvm-18-linker-tools missing files: 
> > usr/lib/llvm-18/lib/LLVMgold.so
> > dh_install: error: missing files, aborting
> > make[1]: *** [debian/rules:1432: override_dh_install] Error 255
> 
> I believe this should be fixed by the following patch. I have launched a
> local build and I will confirm that when it is done.

The build finished, I confirm that the patch fixes the issue.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net



Bug#1060004: upgrade androguard

2024-05-11 Thread Alexandre Detiste
Hi,

I've packaged python-mutf8, the other package needed to upgrade androgard
is the apkTool.

I've no deep idea what mutf8 does, co-maintenance is welcome.

Greetings

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060004

https://wiki.debian.org/SummerOfCode2024/ApprovedProjects/AndroidSDKToolsInDebian

-- Forwarded message -
De : Debian FTP Masters 
Date: sam. 11 mai 2024 à 18:00
Subject: python-mutf8_1.0.6-1_amd64.changes ACCEPTED into unstable
To: Alexandre Detiste , Debian Python Team <
team+pyt...@tracker.debian.org>


Thank you for your contribution to Debian.



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 08 May 2024 16:34:46 +0200
Source: python-mutf8
Binary: python3-mutf8 python3-mutf8-dbgsym
Architecture: source amd64
Version: 1.0.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team ,
Changed-By: Alexandre Detiste 
Description:
 python3-mutf8 - encoders and decoders for the MUTF-8 character encoding
Closes: 1070772
Changes:
 python-mutf8 (1.0.6-1) unstable; urgency=medium
 .
   * Initial upload (Closes: #1070772)
Checksums-Sha1:
 b3b0ebb0f31451511a154d0102c68a35ea1bf9c8 2125 python-mutf8_1.0.6-1.dsc
 5cda9ab1b0c437cfe17cb73aa1ea47630a7629b2 9520
python-mutf8_1.0.6.orig.tar.gz
 aa522618530a243aeebb8e923bb1a0fe01def279 2060
python-mutf8_1.0.6-1.debian.tar.xz
 541749f7359327f5ee149dec9b7a4dbc09a5287b 8484
python-mutf8_1.0.6-1_amd64.buildinfo
 3e083fd866e4ccac70908b7bf3ccdcf5eb7d0ab4 20712
python3-mutf8-dbgsym_1.0.6-1_amd64.deb
 917fc2cb21ab40386c38cf05e580ecb871712bf7 9432
python3-mutf8_1.0.6-1_amd64.deb
Checksums-Sha256:
 723b95736ad1c77cfaa4f9ab71cedff35a50b6f00147352175de21c3dc8af3bb 2125
python-mutf8_1.0.6-1.dsc
 c7a86f00bc8d313b9ce184375c944bf5be771127283d82a8d2becf33cc84e1c7 9520
python-mutf8_1.0.6.orig.tar.gz
 2c9cb19f826978b6308ef0b565b0f1c25936625eb2cf556ab17b066cea2a5bc0 2060
python-mutf8_1.0.6-1.debian.tar.xz
 2b441b25ccefcda0ff4e24671237e6e90f1d5af43d67bb2d88d99ef3c5efec84 8484
python-mutf8_1.0.6-1_amd64.buildinfo
 cde86a8c56c2ca0415aeb8f311f49d9128c262936a75df0c0959c3a0152dba67 20712
python3-mutf8-dbgsym_1.0.6-1_amd64.deb
 dc004b20586aef430d894d101de94fc0e0fd3e5b091a4f9933a4c655ea9039b0 9432
python3-mutf8_1.0.6-1_amd64.deb
Files:
 810aace08dd8597879e59cc434cb674c 2125 python optional
python-mutf8_1.0.6-1.dsc
 8f59d7d495376e1b45b6ca1b7cb816cb 9520 python optional
python-mutf8_1.0.6.orig.tar.gz
 5532c4759ebb196a85bf5aaef2c056d2 2060 python optional
python-mutf8_1.0.6-1.debian.tar.xz
 ff74e03b44022ca348ed1ee70060869b 8484 python optional
python-mutf8_1.0.6-1_amd64.buildinfo
 c0915f2a94d64a8d96760ec1861b2757 20712 debug optional
python3-mutf8-dbgsym_1.0.6-1_amd64.deb
 94edfc29c2a599c1d3c59fd610bb0568 9432 python optional
python3-mutf8_1.0.6-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEj23hBDd/OxHnQXSHMfMURUShdBoFAmY77VIRHHRjaGV0QGRl
Ymlhbi5vcmcACgkQMfMURUShdBqRRRAAoGPiyovV1mfQwyAZwNarNsBggR2vWZ3Q
MV/fdCX2CSG+qqPVhRJHVs4Gjg1b0bEmAlA1XYwODlap5BJvmFqyoCXWJIsek9Iw
Vu0GHsqCMQkZDlyStnRM5ADNLRoIV4zUz9G8Q7Vz2qPn2n5ICfse214Wn5qCyhOB
uC537bINBff1OO+jvLYopf3eiv3Fjs8Ct3VOCbkTvnwwPvBvI+dXO8RaqwwwbiJn
qQ4U8K/COK66udb24pW8N6YP9zvZ5ggrnPYDuJ2wkVQEVPq+L7S+HfIKu8Zdl9ob
PKLJev57N9LNk5hc0UnFl8BW/PN/mUn9jTCMr5IQbi9qg3l1LHvyL2ILB1mQKXvI
3MU1UcnXeL46vTnCPQKqMd7K3cCMQA0tc9yrfNNl/s8V9gHborDG7cmWMGAuUhn5
6Mp5o9AZ24CaFEa2NQapdfvkEgB2h9/5+iPciZLDCVJOwod5cR5t+4xmPIdmCEh3
YhhgSQuW/lMmnhfdQJe/dZ65D8I70FI48KLlLec3RV3TPJUas4X0ZyyBaezxf1Mo
01spa6yNhcnhUmrY1MamGbQ5sWRPZAxj/uBVUKZ26dXNFz/N8Y0YGJE5TO7+indr
iEDd607mOWhtuEcght2k/H0f94zJ81xQCYbrkw4CiuOkAy8km+zfd/oQsuSWp0bR
vvDh+tHiRrI=
=umWv
-END PGP SIGNATURE-


noname
Description: PGP signature


Bug#1070959: /usr/lib/riscv64-linux-gnu/libapt-pkg.so.6.0.0: apt: riscv64: sun20i-d1: http(s): unhandled signal 4 code 0x1 in libapt-pkg.so.6.0.0

2024-05-11 Thread scpcom
Package: libapt-pkg6.0t64
Version: 2.9.2
Severity: important
File: /usr/lib/riscv64-linux-gnu/libapt-pkg.so.6.0.0
X-Debbugs-Cc: scp...@gmx.de

Dear Maintainer,

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

   * What led up to the situation?

When I run apt-get update on Allwinner D1 Nezha hardware I get the following 
errors:

[ 1610.448999] http[1575]: unhandled signal 4 code 0x1 at 0x003fa43ee5f8 in 
libapt-pkg.so.6.0.0[3fa4326000+19c000]
[ 1610.459512] CPU: 0 PID: 1575 Comm: http Not tainted 6.6.29+sun20i #sun20i
[ 1610.466313] Hardware name: Allwinner D1 Nezha (DT)
[ 1610.471109] epc : 003fa43ee5f8 ra : 003fa43ee5f8 sp : 
003fc95c63d0
[ 1610.478337]  gp : 002ae3eca800 tp : 003fa35a0780 t0 : 
000a
[ 1610.485563]  t1 : b8fa9f1e0b81022a t2 : 0064 s0 : 
002ae95abe00
[ 1610.492789]  s1 :  a0 : 002ae95a5f80 a1 : 

[ 1610.500014]  a2 : 002ae9565020 a3 :  a4 : 
0001
[ 1610.507239]  a5 : 0001 a6 : 002ae95a1590 a7 : 
144ef8bcb0a5ab57
[ 1610.514465]  s2 : 003fa3df9618 s3 : 002ae3eca0a0 s4 : 

[ 1610.521691]  s5 : 002ae959bda0 s6 : 002ae3eca0a0 s7 : 
003fc95c6d48
[ 1610.528917]  s8 : 003fc95c6d58 s9 : 003fc95c6690 s10: 
002ae9582730
[ 1610.536144]  s11: 003fa44ffd18 t3 : 003fa3d167cc t4 : 
003a
[ 1610.543371]  t5 : 0001 t6 : 005c
[ 1610.548688] status: 00024020 badaddr: 833f cause: 
0002
[ 1610.563819] https[1574]: unhandled signal 4 code 0x1 at 0x003fa5b155f8 
in libapt-pkg.so.6.0.0[3fa5a4d000+19c000]
[ 1610.574420] CPU: 0 PID: 1574 Comm: https Not tainted 6.6.29+sun20i #sun20i
[ 1610.581307] Hardware name: Allwinner D1 Nezha (DT)
[ 1610.586102] epc : 003fa5b155f8 ra : 003fa5b155f8 sp : 
003fd7b3b3c0
[ 1610.593329]  gp : 002ac54c6800 tp : 003fa4cc6780 t0 : 
000a
[ 1610.600554]  t1 : b8fa9f1e0b81022a t2 : 0064 s0 : 
002ad80d4e40
[ 1610.607780]  s1 :  a0 : 002ad80cefc0 a1 : 

[ 1610.615006]  a2 : 002ad808e018 a3 :  a4 : 
0001
[ 1610.622233]  a5 : 0001 a6 : 002ad80d2bc0 a7 : 
6fd82bd679d27ec2
[ 1610.629458]  s2 : 003fa5796618 s3 : 002ac54c60a0 s4 : 

[ 1610.636686]  s5 : 002ad80d5540 s6 : 002ac54c60a0 s7 : 
003fd7b3bd38
[ 1610.643912]  s8 : 003fd7b3bd48 s9 : 003fd7b3b680 s10: 
002ad80ab730
[ 1610.651138]  s11: 003fa5c26d18 t3 : 003fa56b37cc t4 : 
003a
[ 1610.658363]  t5 : 0001 t6 : 005c
[ 1610.663680] status: 00024020 badaddr: 833f cause: 
0002

The problem seems to exists since mid 2023.
On Ubuntu 23.04 there is no error.
I got the error on Ubuntu 23.10, 24.04 and latest Debian unstable.
The error only shows up on the real hardware and not inside a chroot 
(qemu-user-static riscv64 image on amd64 hardware).

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

I build apt 2.9.2 from sources on Ubuntu 23.04 and installed the resulting 
libapt-pkg6.0t64 deb on Debian unstable which temporairly solved the problem.

It looks like a toolchain issue and apt may not be the only affected packge (I 
have seen the same "unhandled signal 4 code 0x1" on libvte)

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


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

Kernel: Linux 6.6.29+sun20i (SMP w/1 CPU thread)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libapt-pkg6.0t64:riscv64 depends on:
ii  libbz2-1.0   1.0.8-5.1
ii  libc62.38-10
ii  libgcc-s114-20240429-1
ii  libgcrypt20  1.10.3-2+b1
ii  liblz4-1 1.9.4-2
ii  liblzma5 5.6.1+really5.4.5-1
ii  libstdc++6   14-20240429-1
ii  libsystemd0  255.5-1
ii  libudev1 255.5-1
ii  libxxhash0   0.8.2-2+b1
ii  libzstd1 1.5.5+dfsg2-2+b1
ii  zlib1g   1:1.3.dfsg+really1.3.1-1

Versions of packages libapt-pkg6.0t64:riscv64 recommends:
ii  apt  2.9.2

libapt-pkg6.0t64:riscv64 suggests no packages.

-- no debconf information



Bug#1065325: morph's abandoned packages (list)

2024-05-11 Thread Alexandre Detiste
Yes do please.

Le sam. 11 mai 2024 à 20:51, Nilesh Patra  a écrit :
>
> Quoting Alexandre Detiste :
> >  I would pick-up matplotlib I guess, I have some special connection to it,
> >  It was one the packages that enabled me to escape
> >  my horrible SAS-Insitute powered previous job/life.
> >
> >  It's a big one.
> >
> >  Help is appreciated, I already cherry picked some commits from Ciel's PR.
>
> Would you consider to add me in as an Uploader (co-maintainer) alongside you?
>
> I am a Debian Developer.
>
> Best,
> Nilesh



Bug#1064003: patch for c-t-b build

2024-05-11 Thread Aurelien Jarno
Hi,

On 2024-05-05 20:57, Helmut Grohne wrote:
> Control: tags -1 + patch
> 
> Hi Matthias,
> 
> I'm attaching a patch for the c-t-b FTBFS. Note that due to the
> glibc/2.38 upload c-t-b has become completely uninstallable. Hence, a
> timely upload is appreciated. Due to linux-libc-dev currently providing
> the -$arch-cross packages, we have to remove the Build-Conflicts or make
> rename the Provides on linux-libc-dev. I'm ok with both approaches and
> offer dropping the conflict here.

Thanks for working on that. Note that glibc 2.38-9 switched the compiler
to gcc 13, so your patch needs a small update. Please find it attached.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
diff -Nru cross-toolchain-base-68/debian/changelog 
cross-toolchain-base-68+nmu1/debian/changelog
--- cross-toolchain-base-68/debian/changelog2023-10-31 08:50:26.0 
+
+++ cross-toolchain-base-68+nmu1/debian/changelog   2024-05-04 
07:23:39.0 +
@@ -1,3 +1,16 @@
+cross-toolchain-base (68+nmu1) UNRELEASED; urgency=medium
+
+  [ Helmut Grohne ]
+  * Non-maintainer upload.
+  * Build using linux 6.7. Closes: #1064003, #1067370.
+  * Build using glibc 2.38.
+  * Remove linux-libc-dev-ARCH-cross from GLIBC_BUILD_CONFLICTS.
+
+  [ Aurelien Jarno ]
+  * Build using gcc 13.
+
+ -- Helmut Grohne   Sat, 04 May 2024 09:23:39 +0200
+
 cross-toolchain-base (68) unstable; urgency=medium
 
   * Build using linux 6.5.8. Closes: #1042118.
diff -Nru cross-toolchain-base-68/debian/control 
cross-toolchain-base-68+nmu1/debian/control
--- cross-toolchain-base-68/debian/control  2023-10-31 08:50:26.0 
+
+++ cross-toolchain-base-68+nmu1/debian/control 2024-05-04 07:23:39.0 
+
@@ -9,9 +9,9 @@
 Build-Depends: binutils-multiarch,
   dpkg (>= 1.21.17), rdfind, symlinks, lsb-release,
   binutils-source (>= 2.41-6~),
-  glibc-source (>= 2.37-3~),
-  gcc-12-source (>= 12.3.0-11~), g++-12 (>= 12.3.0-11~),
-  linux-source-6.5 (>= 6.5.8), linux-libc-dev (>= 6.5.8),
+  glibc-source (>= 2.38),
+  gcc-13-source (>= 13), g++-13 (>= 13),
+  linux-source-6.7 (>= 6.7.0), linux-libc-dev (>= 6.7.0),
   autoconf (>= 2.69), autoconf2.69, autogen,
   automake, bison (>= 1:2.3), chrpath, debhelper-compat (= 13),
   dpkg-dev (>= 1.15.3.1), fakeroot, file, flex,
@@ -27,7 +27,7 @@
   libjansson-dev, pkg-config,
 Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl,
   binutils-x86-64-linux-gnu [!amd64], binutils-i686-linux-gnu [!i386], 
binutils-s390x-linux-gnu [!s390x], binutils-powerpc64le-linux-gnu [!ppc64el], 
binutils-aarch64-linux-gnu [!arm64], binutils-arm-linux-gnueabihf [!armhf], 
binutils-arm-linux-gnueabi [!armel], binutils-riscv64-linux-gnu [!riscv64],
-  libc6-amd64-cross, linux-libc-dev-amd64-cross, libc6-i386-cross, 
linux-libc-dev-i386-cross, libc6-s390x-cross, linux-libc-dev-s390x-cross, 
libc6-ppc64el-cross, linux-libc-dev-ppc64el-cross, libc6-arm64-cross, 
linux-libc-dev-arm64-cross, libc6-armhf-cross, linux-libc-dev-armhf-cross, 
libc6-armel-cross, linux-libc-dev-armel-cross, libc6-riscv64-cross, 
linux-libc-dev-riscv64-cross,
+  libc6-amd64-cross, libc6-i386-cross, libc6-s390x-cross, libc6-ppc64el-cross, 
libc6-arm64-cross, libc6-armhf-cross, libc6-armel-cross, libc6-riscv64-cross,
   libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386]
 
 Package: linux-libc-dev-amd64-cross
diff -Nru cross-toolchain-base-68/debian/rules 
cross-toolchain-base-68+nmu1/debian/rules
--- cross-toolchain-base-68/debian/rules2023-10-31 08:50:26.0 
+
+++ cross-toolchain-base-68+nmu1/debian/rules   2024-05-04 07:23:39.0 
+
@@ -61,11 +61,11 @@
 CROSS_GNU_TYPE   = $(call _gnu_type,${CROSS_ARCH})
 CROSS_PKG_GNU_TYPE = $(subst _,-,$(call _gnu_type,${CROSS_ARCH}))
 
-MIN_VER_GLIBC  := 2.37-3~
-MIN_VER_LINUX  := 6.5.8
-MIN_VER_GCC:= 12.3.0-11~
+MIN_VER_GLIBC  := 2.38
+MIN_VER_LINUX  := 6.7.0
+MIN_VER_GCC:= 13
 MIN_VER_BINUTILS   := 2.41-6~
-VER_GCC_BASE   := 12
+VER_GCC_BASE   := 13
 libgcc_base:= gcc-s
 
 DEB_VER_LINUX  := $(shell apt-cache policy linux-libc-dev | awk '/^ \*\*\*/ 
{print $$2}')
@@ -110,7 +110,7 @@
 
 # FIXME: No conflict for the host == cross case ...
 BINUTILS_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),binutils-$(subst 
_,-,$(call _gnu_type,$(a))) [!$(a)]$(,))
-GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,) 
linux-libc-dev-$(a)-cross$(,))
+GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,))
 
 # taken from gcc packaging
 define unpack_tarball


Bug#1070958: ITP: golang-github-chzyer-test -- Go library designed to enhance testing capabilities

2024-05-11 Thread Francisco Vilmar Cardoso Ruviaro
Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org, 
vil...@debian.org

* Package name: golang-github-chzyer-test
  Version : 1.0.0
  Upstream Contact: Chzyer 
* URL : https://github.com/chzyer/test
* License : Expat
  Programming Lang: Go
  Description : Go library designed to enhance testing capabilities

  A Go library designed to enhance testing capabilities.
  It provides advanced features for writing and managing
  test cases, aiming to improve the efficiency and
  comprehensiveness of software testing.
  .
  Features:
   * Advanced testing mechanisms.
   * Easy integration with existing Go projects.
   * Improved test case management.



Bug#1070957: nghttp3: Stable backports for nghttp3 and ngtcp2

2024-05-11 Thread Samuel Henrique
Source: nghttp3
Severity: wishlist
X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org

Hello Sakirnth,

This is another issue related to HTTP3 support for curl.

If we push the newer nghttp3 and ngtcp2 packages to stable-backports, we will
be able to enable HTTP3 in curl there too.

I would like to upload the current packages we have on testing (for both
nghttp3 and ngtcp2) to stable-bpo, so they can clear the NEW queue (it might
take a while). Then once the updated packages hit testing, I can update them on
bpo and unblock http3 for curl there.

Do you see any issues with this or have a preference on not following this
approach?

Regards,

--
Samuel Henrique 



Bug#1070914: Update

2024-05-11 Thread Olivia May
Hello Maintainer,

Update: I figured out why firefox was hanging, because pipewire was not 
running. When I added pipewire to my Xsession file, firefox esr starts with no 
issue. Still kinda weird that it hangs, maybe its not supposed to do that?

Thank you,
Olivia


Bug#1070956: octave-fits FTBFS with Octave 9.1.0

2024-05-11 Thread Adrian Bunk
Source: octave-fits
Version: 1.0.7-7
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/fetch.php?pkg=octave-fits=amd64=1.0.7-7%2Bb4=1715454563=0

...
g++ -c -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-I/usr/include/octave-9.1.0/octave/.. -I/usr/include/octave-9.1.0/octave  
-pthread -fopenmp -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection  -Wall   save_fits_image_multi_ext.cc 
-o /tmp/oct-bxJQR8.o
save_fits_image_multi_ext.cc: In function ‘octave_value_list 
Fsave_fits_image_multi_ext(const octave_value_list&, int)’:
save_fits_image_multi_ext.cc:140:60: error: passing ‘const NDArray’ as ‘this’ 
argument discards qualifiers [-fpermissive]
  140 | double * datap = const_cast( image.fortran_vec() );
  |   ~^~
In file included from 
/usr/include/octave-9.1.0/octave/../octave/Array-util.h:31,
 from /usr/include/octave-9.1.0/octave/../octave/MSparse.h:31,
 from 
/usr/include/octave-9.1.0/octave/../octave/MatrixType.h:33,
 from /usr/include/octave-9.1.0/octave/../octave/mx-base.h:33,
 from /usr/include/octave-9.1.0/octave/../octave/Matrix.h:34,
 from /usr/include/octave-9.1.0/octave/../octave/oct.h:33,
 from save_fits_image_multi_ext.cc:19:
/usr/include/octave-9.1.0/octave/../octave/Array.h:666:20: note:   in call to 
‘T* Array::fortran_vec() [with T = double; Alloc = 
std::allocator]’
  666 |   OCTARRAY_API T * fortran_vec ();
  |^~~
save_fits_image.cc: In function ‘octave_value_list Fsave_fits_image(const 
octave_value_list&, int)’:
save_fits_image.cc:132:58: error: passing ‘const NDArray’ as ‘this’ argument 
discards qualifiers [-fpermissive]
  132 |   double * datap = const_cast( image.fortran_vec() );
  | ~^~
In file included from 
/usr/include/octave-9.1.0/octave/../octave/Array-util.h:31,
 from /usr/include/octave-9.1.0/octave/../octave/MSparse.h:31,
 from 
/usr/include/octave-9.1.0/octave/../octave/MatrixType.h:33,
 from /usr/include/octave-9.1.0/octave/../octave/mx-base.h:33,
 from /usr/include/octave-9.1.0/octave/../octave/Matrix.h:34,
 from /usr/include/octave-9.1.0/octave/../octave/oct.h:33,
 from save_fits_image.cc:19:
/usr/include/octave-9.1.0/octave/../octave/Array.h:666:20: note:   in call to 
‘T* Array::fortran_vec() [with T = double; Alloc = 
std::allocator]’
  666 |   OCTARRAY_API T * fortran_vec ();
  |^~~
make[1]: *** [Makefile:9: save_fits_image_multi_ext.oct] Error 1


Bug#1070079: nghttp3: Update to 1.1.0 or newer

2024-05-11 Thread Samuel Henrique
Hello Sakirnth,

> I am good and I hope you too.

All good on my side too :)

> On 4/29/24 22:24, Samuel Henrique wrote:
> > So maybe it even makes sense to get the latest releases for the transition.
>
> I agree. I normaly do both nghttp3 and ngtcp2 the same time, therefore I
> didn't want to block the t64 transition. Since ngtcp2 was a reverse
> dependency of affected packages. I will try to upload the latest version
> this weekend to experimental.

Cool, I've already done a test build of curl and spotted no issues, but I will
only upload it to experimental once ngtcp2 is also there (curl requires at
least 1.2.0, latest is 1.5.0).

> > Would you be interested in any kind of help for this?
>
> Thanks, I will let you know this weekend. Probably in testing the
> rebuild of Wireshark with the new version of nghttp3.

Sounds good, just let me know.

> > If you would like, we could also put the package under the curl team. We are
> > not a "real team" in the sense that we don't gate contributions, that's 
> > just to
> > make it more easy and clear that people should feel free to do team-uploads.
>
> Yes, that would be good. Given that I can put ngtcp2 also under the curl
> team.

Awesome!

Have a nice weekend!

--
Samuel Henrique 



Bug#1037258: curl -I (HEAD request) fails with HTTP/2 against a Debian Apache instance

2024-05-11 Thread Samuel Henrique
I've requested help from upstream on curl-library:
https://curl.se/mail/lib-2024-05/0020.html

It looks like the regression is partially back on the 8.7.1 as well:
 > HTTP/2 200
> expires: Fri, 01 Jan 1980 00:00:00 GMT
> pragma: no-cache
> cache-control: no-cache, max-age=0, must-revalidate
> x-content-type-options: nosniff
> x-frame-options: sameorigin
> referrer-policy: no-referrer
> x-xss-protection: 1
> permissions-policy: interest-cohort=()
> strict-transport-security: max-age=15552000
> vary: Accept-Encoding
> x-clacks-overhead: GNU Terry Pratchett
> content-type: text/plain
> date: Sat, 11 May 2024 19:33:28 GMT
> server: Apache
>
> curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

I get both the payload and the error.

Regards

--
Samuel Henrique 



Bug#1070954: trapperkeeper-metrics-clojure: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:trapperkeeper-metrics-clojure
Version: 1.3.1-2
Severity: serious
Control: close -1 1.5.0-5
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with javahelper --with maven_repo_helper
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
cd debian && ln -sf /usr/share/maven-repo .
make[1]: Leaving directory '/<>'
   jh_linkjars
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
lein pom debian/pom.xml
Wrote /<>/debian/pom.xml
lein jar
Warning: specified :main without including it in :aot.
Implicit AOT of :main will be removed in Leiningen 3.0.0.
If you only need AOT for your uberjar, consider adding :aot :all into your
:uberjar profile instead.
Compiling 2 source files to /<>/target/classes
Warning: The Main-Class specified does not exist within the jar. It may not be 
executable as expected. A gen-class directive may be missing in the namespace 
which contains the main method, or the namespace has not been AOT-compiled.
Created /<>/target/trapperkeeper-metrics-1.3.1.jar
Warning: The Main-Class specified does not exist within the jar. It may not be 
executable as expected. A gen-class directive may be missing in the namespace 
which contains the main method, or the namespace has not been AOT-compiled.
Created /<>/target/test/trapperkeeper-metrics-1.3.1-test.jar
# symlink so we don't need a version in debian/*.poms
cd target && ln -sf trapperkeeper-metrics-1.3.1.jar trapperkeeper-metrics.jar
cd target/test && ln -sf trapperkeeper-metrics-1.3.1-test.jar 
trapperkeeper-metrics-test.jar
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
lein test

lein test puppetlabs.metrics-test

lein test puppetlabs.trapperkeeper.services.metrics.metrics-core-test

lein test puppetlabs.trapperkeeper.services.metrics.metrics-service-test
2024-05-11 18:04:47,783 WARN  [p.t.s.m.metrics-service] The v1 metrics endpoint 
is deprecated and will be removed in a future release. Use the v2 endpoint 
instead.
2024-05-11 18:04:48,332 WARN  [p.t.s.m.metrics-service] The v1 metrics endpoint 
is deprecated and will be removed in a future release. Use the v2 endpoint 
instead.

lein test :only 
puppetlabs.trapperkeeper.services.metrics.metrics-service-test/metrics-service-with-tk-auth

ERROR in (metrics-service-with-tk-auth) (Alert.java:131)
Uncaught exception, not in assertion.
expected: nil
  actual: javax.net.ssl.SSLHandshakeException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: validity check failed
 at sun.security.ssl.Alert.createSSLException (Alert.java:131)
sun.security.ssl.TransportContext.fatal (TransportContext.java:360)
sun.security.ssl.TransportContext.fatal (TransportContext.java:303)
sun.security.ssl.TransportContext.fatal (TransportContext.java:298)
sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts 
(CertificateMessage.java:654)
sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate 
(CertificateMessage.java:473)
sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume 
(CertificateMessage.java:369)
sun.security.ssl.SSLHandshake.consume (SSLHandshake.java:392)
sun.security.ssl.HandshakeContext.dispatch (HandshakeContext.java:443)
sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run 
(SSLEngineImpl.java:1076)
sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run 
(SSLEngineImpl.java:1063)
java.security.AccessController.doPrivileged (AccessController.java:-2)
sun.security.ssl.SSLEngineImpl$DelegatedTask.run (SSLEngineImpl.java:1010)
org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask 
(SSLIOSession.java:288)
org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake 
(SSLIOSession.java:356)
org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady 
(SSLIOSession.java:541)
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady 
(AbstractIODispatch.java:120)
org.apache.http.impl.nio.reactor.BaseIOReactor.readable 
(BaseIOReactor.java:162)
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent 
(AbstractIOReactor.java:337)
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents 
(AbstractIOReactor.java:315)
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute 
(AbstractIOReactor.java:276)
org.apache.http.impl.nio.reactor.BaseIOReactor.execute 
(BaseIOReactor.java:104)
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run 
(AbstractMultiworkerIOReactor.java:591)
java.lang.Thread.run (Thread.java:829)
Caused by: sun.security.validator.ValidatorException: PKIX path validation 
failed: java.security.cert.CertPathValidatorException: validity 

Bug#1070953: ruby-sinatra: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:ruby-sinatra
Version: 2.0.8.1-2
Severity: serious
Control: close -1 3.0.5-3
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --buildsystem=ruby --with ruby
   dh_update_autotools_config -O--buildsystem=ruby
   dh_autoreconf -O--buildsystem=ruby
   dh_auto_configure -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -O--buildsystem=ruby
dh_ruby --test
   create-stamp debian/debhelper-build-stamp
   dh_testroot -O--buildsystem=ruby
   dh_prep -O--buildsystem=ruby
   dh_auto_install -O--buildsystem=ruby
dh_ruby --install /<>/debian/tmp
   dh_ruby --install

┌──┐
│ Install files│
└──┘

install -d /<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby
install -D -m644 /<>/lib/sinatra/images/500.png 
/<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby/sinatra/images/500.png
install -D -m644 /<>/lib/sinatra/images/404.png 
/<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby/sinatra/images/404.png
install -D -m644 /<>/lib/sinatra/show_exceptions.rb 
/<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby/sinatra/show_exceptions.rb
install -D -m644 /<>/lib/sinatra/indifferent_hash.rb 
/<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby/sinatra/indifferent_hash.rb
install -D -m644 /<>/lib/sinatra/main.rb 
/<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby/sinatra/main.rb
install -D -m644 /<>/lib/sinatra/base.rb 
/<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby/sinatra/base.rb
install -D -m644 /<>/lib/sinatra/version.rb 
/<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby/sinatra/version.rb
install -D -m644 /<>/lib/sinatra.rb 
/<>/debian/ruby-sinatra/usr/lib/ruby/vendor_ruby/sinatra.rb

┌──┐
│ Install Rubygems integration metadata│
└──┘

generating gemspec at 
/<>/debian/ruby-sinatra/usr/share/rubygems-integration/all/specifications/sinatra-2.0.8.1.gemspec
dh_installchangelogs -pruby-sinatra /<>/CHANGELOG.md upstream

┌──┐
│ Install files│
└──┘

install -d /<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby
install -D -m644 /<>/sinatra-contrib/lib/sinatra/capture.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/capture.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/reloader.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/reloader.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/content_for.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/content_for.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/contrib/setup.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/contrib/setup.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/contrib/all.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/contrib/all.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/contrib/version.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/contrib/version.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/webdav.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/webdav.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/required_params.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/required_params.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/engine_tracking.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/engine_tracking.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/contrib.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/contrib.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/config_file.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/config_file.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/extension.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/extension.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/respond_with.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/respond_with.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/namespace.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/namespace.rb
install -D -m644 /<>/sinatra-contrib/lib/sinatra/runner.rb 
/<>/debian/ruby-sinatra-contrib/usr/lib/ruby/vendor_ruby/sinatra/runner.rb

Bug#1070952: ros-vcstools: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:ros-vcstools
Version: 0.1.42-3
Severity: serious
Control: close -1 0.1.42-7
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
/<>/setup.py:3: DeprecationWarning: the imp module is deprecated 
in favour of importlib; see the module's documentation for alternative uses
  import imp
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py build
/<>/setup.py:3: DeprecationWarning: the imp module is deprecated 
in favour of importlib; see the module's documentation for alternative uses
  import imp

[... snipped ...]

6 files updated, 0 files merged, 0 files removed, 0 files unresolved
ok
test_checkout_into_subdir_without_existing_parent (test.test_hg.HGClientTest) 
... updating to branch default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
ok
test_checkout_specific_version_and_update (test.test_hg.HGClientTest) ... 
updating to branch default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
pulling from /tmp/tmp18ac112f/remote
searching for changes
no changes found
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
pulling from /tmp/tmp18ac112f/remote
searching for changes
no changes found
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
pulling from /tmp/tmp18ac112f/remote
searching for changes
no changes found
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
pulling from /tmp/tmp18ac112f/remote
searching for changes
no changes found
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
ok
test_get_current_version_label (test.test_hg.HGClientTest) ... updating to 
branch default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
0 files updated, 0 files merged, 5 files removed, 0 files unresolved
pulling from /tmp/tmp18ac112f/remote
searching for changes
no changes found
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
pulling from /tmp/tmp18ac112f/remote
searching for changes
no changes found
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ok
test_get_environment_metadata (test.test_hg.HGClientTest) ... ok
test_get_remote_version (test.test_hg.HGClientTest) ... updating to branch 
default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
abort: destination '/tmp/tmp18ac112f/local' is not empty
pulling from /tmp/tmp18ac112f/remote
searching for changes
no changes found
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
pulling from /tmp/tmp18ac112f/remote
searching for changes
no changes found
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ok
test_get_type_name (test.test_hg.HGClientTest) ... ok
test_get_url_by_reading (test.test_hg.HGClientTest) ... updating to branch 
default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
ok
test_get_url_nonexistant (test.test_hg.HGClientTest) ... ok
marked working directory as branch test_branch
(branches are permanent and global, did you want a bookmark?)
updating to branch default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
testStatusUntracked (test.test_hg.HGDiffStatClientTest) ... ok
test_diff (test.test_hg.HGDiffStatClientTest) ... ok
test_diff_relpath (test.test_hg.HGDiffStatClientTest) ... ok
test_get_version_modified (test.test_hg.HGDiffStatClientTest) ... ok
test_hg_diff_path_change_None (test.test_hg.HGDiffStatClientTest) ... ok
test_status (test.test_hg.HGDiffStatClientTest) ... ok
test_status_relpath (test.test_hg.HGDiffStatClientTest) ... ok
marked working directory as branch test_branch
(branches are permanent and global, did you want a bookmark?)
updating to branch default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
test_export_repository (test.test_hg.HGExportRepositoryClientTest) ... ok
marked working directory as branch test_branch
(branches are permanent and global, did you want a bookmark?)
updating to branch default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
test_get_branches (test.test_hg.HGGetBranchesClientTest) ... pulling from 
/tmp/tmpuikleq_q/remote
searching for changes
no changes found
fixed.txt already tracked!
pulling from /tmp/tmpuikleq_q/remote
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 0 changes to 0 files
new changesets 422f3e5d8335
(run 'hg update' to get a 

Bug#1070951: rbac-client-clojure: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:rbac-client-clojure
Version: 0.9.4-2
Severity: serious
Control: close -1 1.1.4-3
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with javahelper --with maven_repo_helper
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
cd debian && ln -sf /usr/share/maven-repo .
make[1]: Leaving directory '/<>'
   jh_linkjars
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
lein pom debian/pom.xml
Wrote /<>/debian/pom.xml

[... snipped ...]

sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run 
(SSLEngineImpl.java:1063)
java.security.AccessController.doPrivileged (AccessController.java:-2)
sun.security.ssl.SSLEngineImpl$DelegatedTask.run (SSLEngineImpl.java:1010)
org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask 
(SSLIOSession.java:288)
org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake 
(SSLIOSession.java:356)
org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady 
(SSLIOSession.java:541)
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady 
(AbstractIODispatch.java:120)
org.apache.http.impl.nio.reactor.BaseIOReactor.readable 
(BaseIOReactor.java:162)
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent 
(AbstractIOReactor.java:337)
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents 
(AbstractIOReactor.java:315)
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute 
(AbstractIOReactor.java:276)
org.apache.http.impl.nio.reactor.BaseIOReactor.execute 
(BaseIOReactor.java:104)
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run 
(AbstractMultiworkerIOReactor.java:591)
java.lang.Thread.run (Thread.java:829)
Caused by: java.security.cert.CertPathValidatorException: validity check failed
 at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate 
(PKIXMasterCertPathValidator.java:135)
sun.security.provider.certpath.PKIXCertPathValidator.validate 
(PKIXCertPathValidator.java:224)
sun.security.provider.certpath.PKIXCertPathValidator.validate 
(PKIXCertPathValidator.java:144)
sun.security.provider.certpath.PKIXCertPathValidator.engineValidate 
(PKIXCertPathValidator.java:83)
java.security.cert.CertPathValidator.validate (CertPathValidator.java:309)
sun.security.validator.PKIXValidator.doValidate (PKIXValidator.java:364)
sun.security.validator.PKIXValidator.engineValidate (PKIXValidator.java:275)
sun.security.validator.Validator.validate (Validator.java:264)
sun.security.ssl.X509TrustManagerImpl.validate 
(X509TrustManagerImpl.java:313)
sun.security.ssl.X509TrustManagerImpl.checkTrusted 
(X509TrustManagerImpl.java:276)
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted 
(X509TrustManagerImpl.java:141)
sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts 
(CertificateMessage.java:632)
sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate 
(CertificateMessage.java:473)
sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume 
(CertificateMessage.java:369)
sun.security.ssl.SSLHandshake.consume (SSLHandshake.java:392)
sun.security.ssl.HandshakeContext.dispatch (HandshakeContext.java:443)
sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run 
(SSLEngineImpl.java:1076)
sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run 
(SSLEngineImpl.java:1063)
java.security.AccessController.doPrivileged (AccessController.java:-2)
sun.security.ssl.SSLEngineImpl$DelegatedTask.run (SSLEngineImpl.java:1010)
org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask 
(SSLIOSession.java:288)
org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake 
(SSLIOSession.java:356)
org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady 
(SSLIOSession.java:541)
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady 
(AbstractIODispatch.java:120)
org.apache.http.impl.nio.reactor.BaseIOReactor.readable 
(BaseIOReactor.java:162)
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent 
(AbstractIOReactor.java:337)
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents 
(AbstractIOReactor.java:315)
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute 
(AbstractIOReactor.java:276)
org.apache.http.impl.nio.reactor.BaseIOReactor.execute 
(BaseIOReactor.java:104)
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run 
(AbstractMultiworkerIOReactor.java:591)
java.lang.Thread.run (Thread.java:829)
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Sun Jan 01 
21:11:45 UTC 2023
 at sun.security.x509.CertificateValidity.valid (CertificateValidity.java:277)

Bug#1070950: pysph: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:pysph
Version: 1.0~b0~20191115.gite3d5e10-4
Severity: serious
Control: close -1 1.0~b1-5
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
/usr/lib/python3/dist-packages/Cython/Compiler/Main.py:369: FutureWarning: 
Cython directive 'language_level' not set, using 2 for now (Py2). This will 
change in a later release! File: /tmp/tmp_p5oyha8/check_omp.pyx
  tree = Parsing.p_module(s, pxd, full_module_name)
/tmp/tmp_p5oyha8/check_omp.c: In function ‘__Pyx_InitGlobals’:
/tmp/tmp_p5oyha8/check_omp.c:1230:1: warning: ‘PyEval_InitThreads’ is 
deprecated [-Wdeprecated-declarations]
 1230 | PyEval_InitThreads();
  | ^~
In file included from /usr/include/python3.9/Python.h:145,

[... snipped ...]

test simple_reduction.py failed with returncode 1

_ DumpLoadTestCase.test_dump_and_load_work_in_parallel _

self = 

@mark.parallel
def test_dump_and_load_work_in_parallel(self):

  run_parallel_script.run(

filename='check_dump_load.py', nprocs=nprocs, path=path
)

pysph/parallel/tests/test_parallel.py:114:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

filename = 'check_dump_load.py', args = [], nprocs = 2, timeout = 30.0
path = '/<>/.pybuild/cpython3_3.9/build/pysph/parallel/tests'

def run(filename, args=None, nprocs=2, timeout=30.0, path=None):
"""Run a python script with MPI or in serial (if nprocs=1).  Kill 
process
if it takes longer than the specified timeout.

Parameters:

---
filename - filename of python script to run under mpi.
args - List of arguments to pass to script.
nprocs - number of processes to run (1 => serial non-mpi run).
timeout - time in seconds to wait for the script to finish running,
else raise a RuntimeError exception.
path - the path under which the script is located
Defaults to the location of this file (__file__), not curdir.

"""

if args is None:
args = []
file_path = abspath(join(path, filename))
cmd = [sys.executable, file_path] + args
if nprocs > 1:
cmd = ['mpiexec', '-n', str(nprocs)] + cmd

print('running test:', cmd)

process = Popen(cmd, stdout=PIPE, stderr=PIPE)

timer = Timer(timeout, kill_process, [process])
timer.start()
out, err = process.communicate()
timer.cancel()
retcode = process.returncode
if retcode:
msg = 'test ' + filename + ' failed with returncode ' + str(retcode)
print(out.decode('utf-8'))
print(err.decode('utf-8'))
print('#'*80)
print(msg)
print('#'*80)

  raise RuntimeError(msg)

E   RuntimeError: test check_dump_load.py failed with returncode 1

pysph/tools/run_parallel_script.py:54: RuntimeError
- Captured stdout call -
running test: ['mpiexec', '-n', '2', '/usr/bin/python3.9', 
'/<>/.pybuild/cpython3_3.9/build/pysph/parallel/tests/check_dump_load.py']

--
There are not enough slots available in the system to satisfy the 2
slots that were requested by the application:

  /usr/bin/python3.9

Either request fewer slots for your application, or make more slots
available for use.

A "slot" is the Open MPI term for an allocatable unit where we can
launch a process.  The number of slots available are defined by the
environment in which Open MPI processes are run:

  1. Hostfile, via "slots=N" clauses (N defaults to number of
 processor cores if not provided)
  2. The --host command line parameter, via a ":N" suffix on the
 hostname (N defaults to 1 if not provided)
  3. Resource manager (e.g., SLURM, PBS/Torque, LSF, etc.)
  4. If none of a hostfile, the --host command line parameter, or an
 RM is present, Open MPI defaults to the number of processor cores

In all the above cases, if you want Open MPI to default to the number
of hardware threads instead of the number of processor cores, use the
--use-hwthread-cpus option.

Alternatively, you can use the --oversubscribe option to ignore the
number of available slots when deciding the number of processes to
launch.
--


Bug#1070949: puppetlabs-http-client-clojure: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:puppetlabs-http-client-clojure
Version: 1.2.0-2
Severity: serious
Control: close -1 2.1.1-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with javahelper --with maven_repo_helper
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
cd debian && ln -sf /usr/share/maven-repo .
make[1]: Leaving directory '/<>'
   jh_linkjars
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
lein pom debian/pom.xml
Wrote /<>/debian/pom.xml
lein i18n make
Running 'make i18n'
lein jar
Compiling 44 source files to /<>/target/classes
Created /<>/target/http-client-1.2.0.jar
Created /<>/target/sources/http-client-1.2.0-sources.jar
# symlinks so we don't need a version in debian/*.poms
cd target && ln -sf http-client-1.2.0.jar http-client.jar
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
lein test

lein test com.puppetlabs.http.client.impl.java-client-test

lein test com.puppetlabs.http.client.impl.metrics-unit-test

lein test puppetlabs.http.client.async-plaintext-test

lein test puppetlabs.http.client.async-unbuffered-test

lein test puppetlabs.http.client.gzip-request-test

lein test puppetlabs.http.client.metrics-test

lein test puppetlabs.http.client.sync-plaintext-test

lein test puppetlabs.http.client.sync-ssl-test

lein test :only puppetlabs.http.client.sync-ssl-test/sync-client-test-from-pems

ERROR in (sync-client-test-from-pems) (PersistentSyncHttpClient.java:52)
Uncaught exception, not in assertion.
expected: nil
  actual: com.puppetlabs.http.client.HttpClientException: Error executing http 
request
 at com.puppetlabs.http.client.impl.PersistentSyncHttpClient.request 
(PersistentSyncHttpClient.java:52)
com.puppetlabs.http.client.Sync.request (Sync.java:69)
com.puppetlabs.http.client.Sync.get (Sync.java:121)

puppetlabs.http.client.sync_ssl_test$fn__30229$fn__30232$fn__30233$fn__30236$fn__30239$fn__30240.invoke
 (sync_ssl_test.clj:45)

puppetlabs.http.client.sync_ssl_test$fn__30229$fn__30232$fn__30233$fn__30236$fn__30239.invoke
 (sync_ssl_test.clj:40)
clojure.core$with_redefs_fn.invokeStatic (core.clj:7519)
clojure.core$with_redefs_fn.invoke (core.clj:7503)

puppetlabs.http.client.sync_ssl_test$fn__30229$fn__30232$fn__30233$fn__30236.invoke
 (sync_ssl_test.clj:33)

puppetlabs.trapperkeeper.testutils.logging$call_with_additional_log_appenders.invokeStatic
 (logging.clj:120)

puppetlabs.trapperkeeper.testutils.logging$call_with_additional_log_appenders.invoke
 (logging.clj:112)

puppetlabs.trapperkeeper.testutils.logging$call_with_log_appenders.invokeStatic 
(logging.clj:142)
puppetlabs.trapperkeeper.testutils.logging$call_with_log_appenders.invoke 
(logging.clj:132)

puppetlabs.trapperkeeper.testutils.logging$call_with_log_event_listeners$set_up__19797.invoke
 (logging.clj:185)

puppetlabs.trapperkeeper.testutils.logging$call_with_log_event_listeners$set_up__19797$fn__19802$fn__19803.invoke
 (logging.clj:189)
clojure.lang.AFn.applyToHelper (AFn.java:154)
clojure.lang.AFn.applyTo (AFn.java:144)
clojure.core$apply.invokeStatic (core.clj:667)
clojure.core$apply.invoke (core.clj:662)

puppetlabs.trapperkeeper.testutils.logging$call_with_log_event_listeners$set_up__19797$fn__19802.invoke
 (logging.clj:187)
puppetlabs.trapperkeeper.testutils.logging$call_with_started.invokeStatic 
(logging.clj:50)
puppetlabs.trapperkeeper.testutils.logging$call_with_started.invoke 
(logging.clj:48)
puppetlabs.trapperkeeper.testutils.logging$call_with_started.invokeStatic 
(logging.clj:53)
puppetlabs.trapperkeeper.testutils.logging$call_with_started.invoke 
(logging.clj:48)
clojure.lang.Var.invoke (Var.java:388)

puppetlabs.trapperkeeper.testutils.logging$call_with_log_event_listeners$set_up__19797.invoke
 (logging.clj:187)

puppetlabs.trapperkeeper.testutils.logging$call_with_log_event_listeners.invokeStatic
 (logging.clj:190)

puppetlabs.trapperkeeper.testutils.logging$call_with_log_event_listeners.invoke 
(logging.clj:177)
puppetlabs.http.client.sync_ssl_test$fn__30229$fn__30232$fn__30233.invoke 
(sync_ssl_test.clj:32)
puppetlabs.trapperkeeper.testutils.logging$call_with_log_level.invokeStatic 
(logging.clj:85)
puppetlabs.trapperkeeper.testutils.logging$call_with_log_level.invoke 
(logging.clj:74)
puppetlabs.http.client.sync_ssl_test$fn__30229$fn__30232.invoke 
(sync_ssl_test.clj:32)
clojure.core$with_redefs_fn.invokeStatic (core.clj:7519)
clojure.core$with_redefs_fn.invoke (core.clj:7503)
puppetlabs.http.client.sync_ssl_test$fn__30229.invokeStatic 
(sync_ssl_test.clj:32)
puppetlabs.http.client.sync_ssl_test/fn (sync_ssl_test.clj:31)

Bug#1070948: pocl: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:pocl
Version: 1.6-5
Severity: serious
Control: close -1 3.1-3+deb12u1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with pkgkde_symbolshelper --buildsystem=cmake
   dh_update_autotools_config -O--buildsystem=cmake
   dh_autoreconf -O--buildsystem=cmake
   debian/rules execute_before_dh_auto_configure
make[1]: Entering directory '/<>'
test ! -d include/CL || mv -v include/CL include/_CL
renamed 'include/CL' -> 'include/_CL'
test ! -d include/OpenCL || mv -v include/OpenCL include/_OpenCL
renamed 'include/OpenCL' -> 'include/_OpenCL'
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'

[... snipped ...]

make  -f tests/regression/CMakeFiles/test_barrier_before_return.dir/build.make 
tests/regression/CMakeFiles/test_barrier_before_return.dir/build
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /<> 
/<>/tests/regression /<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu/tests/regression 
/<>/obj-x86_64-linux-gnu/tests/regression/CMakeFiles/test_locals.dir/DependInfo.cmake --color=
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
make[3]: Nothing to be done for 
'tests/regression/CMakeFiles/test_barrier_before_return.dir/build'.
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
[ 98%] Built target test_barrier_before_return
make  -f tests/regression/CMakeFiles/test_infinite_loop.dir/build.make 
tests/regression/CMakeFiles/test_infinite_loop.dir/depend
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make  -f tests/regression/CMakeFiles/test_locals.dir/build.make 
tests/regression/CMakeFiles/test_locals.dir/build
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /<> 
/<>/tests/regression /<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu/tests/regression 
/<>/obj-x86_64-linux-gnu/tests/regression/CMakeFiles/test_infinite_loop.dir/DependInfo.cmake --color=
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
make[3]: Nothing to be done for 
'tests/regression/CMakeFiles/test_locals.dir/build'.
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
[ 98%] Built target test_locals
make  -f tests/regression/CMakeFiles/test_issue_231.dir/build.make 
tests/regression/CMakeFiles/test_issue_231.dir/depend
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make  -f tests/regression/CMakeFiles/test_infinite_loop.dir/build.make 
tests/regression/CMakeFiles/test_infinite_loop.dir/build
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /<> 
/<>/tests/regression /<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu/tests/regression 
/<>/obj-x86_64-linux-gnu/tests/regression/CMakeFiles/test_issue_231.dir/DependInfo.cmake --color=
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
make[3]: Nothing to be done for 
'tests/regression/CMakeFiles/test_infinite_loop.dir/build'.
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
[ 98%] Built target test_infinite_loop
make  -f tests/regression/CMakeFiles/test_issue_757.dir/build.make 
tests/regression/CMakeFiles/test_issue_757.dir/depend
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make  -f tests/regression/CMakeFiles/test_issue_231.dir/build.make 
tests/regression/CMakeFiles/test_issue_231.dir/build
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /<> 
/<>/tests/regression /<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu/tests/regression 
/<>/obj-x86_64-linux-gnu/tests/regression/CMakeFiles/test_issue_757.dir/DependInfo.cmake --color=
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
make[3]: Nothing to be done for 
'tests/regression/CMakeFiles/test_issue_231.dir/build'.
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
[ 98%] Built target test_issue_231
make  -f tests/regression/CMakeFiles/test_early_return.dir/build.make 
tests/regression/CMakeFiles/test_early_return.dir/depend
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make  -f tests/regression/CMakeFiles/test_issue_757.dir/build.make 
tests/regression/CMakeFiles/test_issue_757.dir/build
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /<> 
/<>/tests/regression /<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu/tests/regression 
/<>/obj-x86_64-linux-gnu/tests/regression/CMakeFiles/test_early_return.dir/DependInfo.cmake --color=
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
make[3]: Nothing to be done for 
'tests/regression/CMakeFiles/test_issue_757.dir/build'.
make[3]: Leaving directory 

Bug#1070947: openconnect: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:openconnect
Version: 8.10-2
Severity: serious
Control: close -1 9.01-3
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
configure.ac:121: installing './compile'
configure.ac:8: installing './missing'
Makefile.am: installing './depcomp'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- \
--disable-dsa-tests \
--htmldir=/usr/share/doc/openconnect/html \
--with-gnutls \
--without-gnutls-version-check \
--with-vpnc-script=/usr/share/vpnc-scripts/vpnc-script
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --disable-dsa-tests 
--htmldir=/usr/share/doc/openconnect/html --with-gnutls 
--without-gnutls-version-check 
--with-vpnc-script=/usr/share/vpnc-scripts/vpnc-script
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '924' is supported by ustar format... yes
checking whether GID '924' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether make supports nested variables... (cached) yes
configure: Applying feature macros for GNU build
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for fdevname_r... no
checking for statfs... yes
checking for getline... yes
checking for strcasestr... yes
checking for strndup... yes
checking for asprintf... yes
checking for vasprintf... yes
checking for supported compiler flags...  -Wall -Wextra 
-Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter 
-Werror=pointer-to-int-cast -Wdeclaration-after-statement 
-Werror-implicit-function-declaration -Wformat-nonliteral -Wformat-security 
-Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wnested-externs 
-Wpointer-arith -Wwrite-strings
checking For memset_s... no
checking for explicit_memset... no
checking for explicit_bzero... yes
checking For localtime_r... yes
checking for socket... yes
checking for inet_aton... yes
checking for IPV6_PATHMTU socket option... yes
checking for __android_log_vprint... no
checking for __android_log_vprint in -llog... no
checking for nl_langinfo... yes
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for iconv... yes
checking for working iconv... yes
checking for iconv declaration...
 extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, 
char * *outbuf, size_t *outbytesleft);
checking for msgfmt... /usr/bin/msgfmt
checking for functional NLS support... yes
checking for gnutls... yes
checking for gnutls_system_key_add_x509... yes
checking for gnutls_pkcs11_add_provider... yes
checking for p11-kit-1... yes
checking for tss library... no
checking for libtasn1... yes
checking for tss2-esys tss2-mu... yes

Bug#1070946: node-ytdl-core: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:node-ytdl-core
Version: 3.4.2+dfsg+~cs3.10.3-2
Severity: serious
Control: close -1 4.11.2+dfsg+~cs4.10.8-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
mkdir node_modules
mkdir -p ./node_modules/\@types
ln -s /usr/share/nodejs/\@types/node ./node_modules/\@types/
ln -s ../html-entities node_modules/html-entities
ln -s ../m3u8stream node_modules/m3u8stream
ln -s ../miniget node_modules/miniget
mkdir -p m3u8stream/node_modules
ln -s ../../miniget m3u8stream/node_modules/miniget
ln -s ../../debian/build_modules/\@types/sax node_modules/\@types/sax
   dh_auto_build --buildsystem=nodejs
Found debian/nodejs/miniget/build
cd ./miniget && sh -ex ../debian/nodejs/miniget/build
+ set -e
+ set -x
+ mkdir -p node_modules/@types
+ ln -s ../../../debian/build_modules/@types/sax node_modules/@types/sax
+ tsc -p tsconfig.build.json
+ rm -rf node_modules
No build command found, searching known files
Found debian/nodejs/m3u8stream/build
cd ./m3u8stream && sh -ex ../debian/nodejs/m3u8stream/build
+ set -e
+ set -x
+ mkdir -p node_modules/@types
+ ln -s ../../../debian/build_modules/@types/sax node_modules/@types/sax
+ tsc -p tsconfig.build.json
src/index.ts(28,20): error TS2430: Interface 'Stream' incorrectly extends 
interface 'PassThrough'.
  The types returned by 'end(...)' are incompatible between these types.
Type 'void' is not assignable to type 'this'.
  'this' could be instantiated with an arbitrary type which could be 
unrelated to 'void'.
src/index.ts(45,18): error TS2352: Conversion of type 'PassThrough' to type 
'Stream' may be a mistake because neither type sufficiently overlaps with the 
other. If this was intentional, convert the expression to 'unknown' first.
  Types of property 'on' are incompatible.
Type '{ (event: "close", listener: () => void): PassThrough; (event: "data", listener: (chunk: any) => void): PassThrough; 
(event: "end", listener: () => void): PassThrough; (event: "readable", listener: () => void): PassThrough; (event: 
"error", listener: (err: Error) => void): PassThrough; (event: string | symbol, liste...' is not comparable to type '{ (event: 
"progress", progress: Progress, totalSegments: number, downloadedBytes: number): Stream; (event: string | symbol, listener: (...args: any) => 
void): Stream; }'.
  Types of parameters 'event' and 'event' are incompatible.
Type '"progress"' is not comparable to type '"close"'.
dh_auto_build: error: cd ./m3u8stream && sh -ex 
../debian/nodejs/m3u8stream/build returned exit code 2
make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/bullseye/

About the archive rebuild: The build was made on virtual machines
of type m6a.large and r6a.large from AWS, using sbuild and a
reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.



Bug#1070945: node-recast: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:node-recast
Version: 0.20.4-2
Severity: serious
Control: close -1 0.21.1-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
mkdir node_modules
cp -rL /usr/share/nodejs/ast-types ./node_modules/
mkdir -p ./node_modules/\@babel
cp -rL /usr/share/nodejs/\@babel/parser ./node_modules/\@babel
mkdir -p ./node_modules/\@babel
cp -rL /usr/share/nodejs/\@babel/types ./node_modules/\@babel
cp -rL /usr/share/nodejs/source-map ./node_modules/
cp -rL /usr/share/nodejs/tslib ./node_modules/
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/esprima ./node_modules/\@types
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/estree ./node_modules/\@types
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/mocha ./node_modules/\@types
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/node ./node_modules/\@types
cp: cannot copy cyclic symbolic link '/usr/share/nodejs/@types/node/tsc3.6'
dh_auto_configure: error: cp -rL /usr/share/nodejs/\@types/node 
./node_modules/\@types returned exit code 1
make: *** [debian/rules:4: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/bullseye/

About the archive rebuild: The build was made on virtual machines
of type m6a.large and r6a.large from AWS, using sbuild and a
reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.



Bug#1070944: node-multiparty: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:node-multiparty
Version: 4.2.2-2
Severity: serious
Control: close -1 4.2.3-2
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
   dh_auto_build --buildsystem=nodejs
No build command found, searching known files
   dh_auto_test --buildsystem=nodejs
mkdir -p node_modules
ln -s ../. node_modules/multiparty
/bin/sh -ex debian/tests/pkg-js/test
+ mocha --bail --check-leaks test/


  multiparty
fixture tests
  content-type
✓ charset
✓ charset-last
✓ custom
✓ custom-equal-sign
  encoding
✓ menu_seperator.png
✓ beta-sticker-1.png
✓ blank.gif
✓ binaryfile.tar.gz
✓ plain.txt
  filename
1) empty


  9 passing (2s)
  1 failing

  1) multiparty
   fixture tests
 filename
   empty:
 Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is 
called; if returning a Promise, ensure it resolves. (/<>/test/test.js)
  at Test.Runnable._timeoutError 
(/usr/share/nodejs/mocha/lib/runnable.js:432:10)
  at Timeout. (/usr/share/nodejs/mocha/lib/runnable.js:244:24)
  at listOnTimeout (internal/timers.js:554:17)
  at processTimers (internal/timers.js:497:7)



dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/bullseye/

About the archive rebuild: The build was made on virtual machines
of type m6a.large and r6a.large from AWS, using sbuild and a
reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.



Bug#1070942: node-jest: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:node-jest
Version: 26.6.3+repack+~cs64.44.39-3
Severity: serious
Control: close -1 29.3.1~ds1+~cs70.48.25-2
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
Found debian/nodejs/additional_components
Adding component(s): packages/babel-jest, packages/babel-plugin-jest-hoist, 
packages/babel-preset-jest, packages/diff-sequences, packages/expect, 
packages/jest, packages/jest-changed-files, packages/jest-circus, 
packages/jest-cli, packages/jest-config, packages/jest-console, 
packages/jest-core, packages/jest-create-cache-key-function, 
packages/jest-diff, packages/jest-docblock, packages/jest-each, 
packages/jest-environment, packages/jest-environment-jsdom, 
packages/jest-environment-node, packages/jest-fake-timers, 
packages/jest-get-type, packages/jest-globals, packages/jest-haste-map, 
packages/jest-jasmine2, packages/jest-leak-detector, 
packages/jest-matcher-utils, packages/jest-message-util, packages/jest-mock, 
packages/jest-phabricator, packages/jest-regex-util, packages/jest-repl, 
packages/jest-reporters, packages/jest-resolve, 
packages/jest-resolve-dependencies, packages/jest-runner, 
packages/jest-runtime, packages/jest-serializer, packages/jest-snapshot, 
packages/jest-source-map, packages/jest-test-result, 
packages/jest-test-sequencer, packages/jest-transform, packages/jest-types, 
packages/jest-util, packages/jest-validate, packages/jest-watcher, 
packages/jest-worker, packages/pretty-format, packages/test-utils
mkdir node_modules
ln -s /usr/share/nodejs/ansi-regex ./node_modules/
ln -s /usr/share/nodejs/anymatch ./node_modules/
mkdir -p ./node_modules/\@babel
ln -s /usr/share/nodejs/\@babel/core ./node_modules/\@babel/
ln -s /usr/share/nodejs/\@babel/generator ./node_modules/\@babel/
ln -s /usr/share/nodejs/\@babel/traverse ./node_modules/\@babel/
ln -s /usr/share/nodejs/\@babel/types ./node_modules/\@babel/
ln -s /usr/share/nodejs/callsites ./node_modules/
ln -s /usr/share/nodejs/camelcase ./node_modules/
ln -s /usr/share/nodejs/chalk ./node_modules/
ln -s /usr/share/nodejs/chokidar ./node_modules/
ln -s /usr/share/nodejs/deepmerge ./node_modules/
ln -s /usr/share/nodejs/detect-newline ./node_modules/
ln -s /usr/share/nodejs/emittery ./node_modules/
ln -s /usr/share/nodejs/execa ./node_modules/
ln -s /usr/share/nodejs/is-generator-fn ./node_modules/
ln -s /usr/share/nodejs/leven ./node_modules/
ln -s /usr/share/nodejs/make-error ./node_modules/
ln -s /usr/share/nodejs/pirates ./node_modules/
ln -s /usr/share/nodejs/slash ./node_modules/
ln -s /usr/share/nodejs/source-map ./node_modules/
ln -s /usr/share/nodejs/strip-ansi ./node_modules/
ln -s /usr/share/nodejs/strip-bom ./node_modules/
ln -s /usr/share/nodejs/typescript ./node_modules/
ln -s /usr/share/nodejs/type-fest ./node_modules/
mkdir -p ./node_modules/\@types
ln -s /usr/share/nodejs/\@types/babel__code-frame 
./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/babel-types ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/braces ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/chai ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/ci-info ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/co ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/color-name ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/convert-source-map 
./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/exit ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/fast-json-stable-stringify 
./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/fb-watchman ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/graceful-fs ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/istanbul-lib-coverage 
./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/merge-stream ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/minimatch ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/minimist ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/node ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/normalize-package-data 
./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/parse5 ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/prompts ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/prop-types ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/resolve ./node_modules/\@types/
ln -s 

Bug#1070943: node-jschardet: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:node-jschardet
Version: 2.2.1+dfsg+~1.3.0-1
Severity: serious
Control: close -1 3.0.0+dfsg+~1.4.0-2
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
mkdir node_modules
mkdir -p ./node_modules/\@babel
cp -rL /usr/share/nodejs/\@babel/parser ./node_modules/\@babel
mkdir -p ./node_modules/\@babel
cp -rL /usr/share/nodejs/\@babel/types ./node_modules/\@babel
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/istanbul-lib-coverage 
./node_modules/\@types
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/istanbul-lib-report 
./node_modules/\@types
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/node ./node_modules/\@types
cp: cannot copy cyclic symbolic link '/usr/share/nodejs/@types/node/tsc3.6'
dh_auto_configure: error: cp -rL /usr/share/nodejs/\@types/node 
./node_modules/\@types returned exit code 1
make: *** [debian/rules:15: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/bullseye/

About the archive rebuild: The build was made on virtual machines
of type m6a.large and r6a.large from AWS, using sbuild and a
reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.



Bug#1070941: node-htmlparser2: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:node-htmlparser2
Version: 6.0.0-5
Severity: serious
Control: close -1 8.0.1-4
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
mkdir node_modules
cp -rL /usr/share/nodejs/domelementtype ./node_modules/
cp -rL /usr/share/nodejs/domhandler ./node_modules/
cp -rL /usr/share/nodejs/domutils ./node_modules/
cp -rL /usr/share/nodejs/dom-serializer ./node_modules/
cp -rL /usr/share/nodejs/entities ./node_modules/
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/istanbul-lib-coverage 
./node_modules/\@types
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/node ./node_modules/\@types
cp: cannot copy cyclic symbolic link '/usr/share/nodejs/@types/node/tsc3.6'
dh_auto_configure: error: cp -rL /usr/share/nodejs/\@types/node 
./node_modules/\@types returned exit code 1
make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/bullseye/

About the archive rebuild: The build was made on virtual machines
of type m6a.large and r6a.large from AWS, using sbuild and a
reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.



Bug#1070940: node-follow-redirects: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:node-follow-redirects
Version: 1.13.1-1+deb11u1
Severity: serious
Control: close -1 1.15.2+~1.14.1-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
   dh_auto_build --buildsystem=nodejs
No build command found, searching known files
   dh_auto_test --buildsystem=nodejs
mkdir -p node_modules
ln -s ../. node_modules/follow-redirects
/bin/sh -ex debian/tests/pkg-js/test
+ mocha


  follow-redirects
✓ http.get with string and callback - redirect (41ms)
✓ http.get with URL object and callback - redirect
✓ http.get with options object and callback - redirect
✓ http.get with string and callback - no redirect
✓ http.get with options object and callback - no redirect
✓ http.get with host option and callback - redirect
✓ http.get with response event
✓ should return with the original status code if the response does not 
contain a location header
✓ should emit connection errors on the returned stream
✓ should emit socket events on the returned stream
✓ should emit connect events on the returned stream
1) emits an error on redirects with an invalid location
✓ should destroy responses
✓ should honor query params in redirects
✓ should allow aborting
✓ should provide connection
✓ should provide flushHeaders
✓ should provide getHeader
✓ should provide removeHeader
✓ should provide setHeader
✓ should provide setNoDelay
✓ should provide setSocketKeepAlive
✓ should provide setTimeout
✓ should provide socket
✓ should wait for an explicit call to end
✓ errors on write after end
✓ should support writing into request stream without redirects
✓ should support writing into request stream with redirects
✓ should support piping into request stream without redirects
✓ should support piping into request stream with redirects
✓ should support piping into request stream with explicit Content-Length 
without redirects
✓ should support piping into request stream with explicit Content-Length 
with redirects
setTimeout
  ✓ clears timeouts after a successful response
  ✓ clears timeouts after an error response
  ✓ sets a timeout when the socket already exists
  ✓ should timeout on the final request
  ✓ should include redirect delays in the timeout
  ✓ overrides existing timeouts
should obey a `maxRedirects` property
  ✓ which defaults to 21 (52ms)
  ✓ which can be set globally
  ✓ set as an option on an individual request
the trackRedirects option
  when not set
✓ should not track redirects
  when set to true
✓ should track redirects
when the client passes an header named Authorization
  ✓ ignores it when null
when the client passes an header named Cookie
  ✓ ignores it when null
should switch to safe methods when appropriate
  when redirecting with status code 300
✓ should reuse GET
✓ should reuse HEAD
✓ should reuse POST
✓ should reuse PUT
✓ should reuse DELETE
  when redirecting with status code 301
✓ should reuse GET
✓ should reuse HEAD
✓ should switch from POST to GET
✓ should reuse PUT
✓ should reuse DELETE
  when redirecting with status code 302
✓ should reuse GET
✓ should reuse HEAD
✓ should switch from POST to GET
✓ should reuse PUT
✓ should reuse DELETE
  when redirecting with status code 303
✓ should reuse GET
✓ should reuse HEAD
✓ should switch from POST to GET
✓ should switch from PUT to GET
✓ should switch from DELETE to GET
  when redirecting with status code 307
✓ should reuse GET
✓ should reuse HEAD
✓ should reuse POST
✓ should reuse PUT
✓ should reuse DELETE
should error on an unsupported protocol redirect
  ✓ (http -> about)
should obey a `maxBodyLength` property
  ✓ which defaults to 10MB
  ✓ set globally, on write
  ✓ set per request, on write
  ✓ set globally, on end
  ✓ set per request, on end
writing invalid data
  ✓ throws an error
when switching from POST to GET
  ✓ should drop the entity and associated headers
when redirecting to a different host while the host header is set
  ✓ uses the new host header
when the client passes an Authorization header
  ✓ keeps the header when redirected to the same host
  ✓ keeps the header when redirected to the same host via header
  ✓ drops the header when redirected to a different host
  ✓ drops the header when redirected from a different host via header
when 

Bug#1070939: node-domutils: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:node-domutils
Version: 2.4.4-5
Severity: serious
Control: close -1 3.0.1-3
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
mkdir node_modules
cp -rL /usr/share/nodejs/domhandler ./node_modules/
cp -rL /usr/share/nodejs/dom-serializer ./node_modules/
cp -rL /usr/share/nodejs/domelementtype ./node_modules/
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/node ./node_modules/\@types
cp: cannot copy cyclic symbolic link '/usr/share/nodejs/@types/node/tsc3.6'
dh_auto_configure: error: cp -rL /usr/share/nodejs/\@types/node 
./node_modules/\@types returned exit code 1
make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/bullseye/

About the archive rebuild: The build was made on virtual machines
of type m6a.large and r6a.large from AWS, using sbuild and a
reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.



Bug#1070938: minilla: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:minilla
Version: 3.1.11-1
Severity: serious
Control: close -1 3.1.21-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
perl Build.PL --installdirs vendor --config "optimize=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config 
"ld=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z,relro"
Creating new 'Build' script for 'Minilla' version 'v3.1.11'
   dh_auto_build
perl Build
cp lib/Minilla/Release/MakeDist.pm blib/lib/Minilla/Release/MakeDist.pm
cp lib/Minilla/Logger.pm blib/lib/Minilla/Logger.pm
cp lib/Minilla/Release/CheckUntrackedFiles.pm 
blib/lib/Minilla/Release/CheckUntrackedFiles.pm
cp lib/Minilla/Release/RewriteChanges.pm 
blib/lib/Minilla/Release/RewriteChanges.pm

[... snipped ...]

1..1
ok 2 - empty unsupported
1..2
ok
hint: Using 'master' as the name for the initial branch. This default branch 
name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch 
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m 
hint: Using 'master' as the name for the initial branch. This default branch 
name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch 
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m 
hint: Using 'master' as the name for the initial branch. This default branch 
name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch 
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m 
t/project/xsutil.t ...
# Subtest: No xsutil
Writing lib/Acme/Foo.pm
Writing Changes
Writing t/00_compile.t
Writing .travis.yml
Writing .gitignore
Writing LICENSE
Writing cpanfile
[H3Bx01YJbK] $ git init
Initialized empty Git repository in /tmp/H3Bx01YJbK/.git/
[H3Bx01YJbK] $ git add .
[H3Bx01YJbK] $ git commit -m initial import
[master (root-commit) b52b4e9] initial import
 8 files changed, 485 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 .travis.yml
 create mode 100644 Changes
 create mode 100644 LICENSE
 create mode 100644 cpanfile
 create mode 100644 lib/Acme/Foo.pm
 create mode 100644 minil.toml
 create mode 100644 t/00_compile.t
ok 1
1..1
ok 1 - No xsutil
# Subtest: Use XSUtil with default value
Writing lib/Acme/Foo.pm
Writing Changes
Writing t/00_compile.t
Writing .travis.yml
Writing .gitignore
Writing LICENSE
Writing cpanfile
[RAjO_JCtZp] $ git init
Initialized empty Git repository in /tmp/RAjO_JCtZp/.git/
[RAjO_JCtZp] $ git add .
[RAjO_JCtZp] $ git commit -m initial import
[master (root-commit) 02e6b0a] initial import
 8 files changed, 487 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 .travis.yml
 create mode 100644 Changes
 create mode 100644 LICENSE
 create mode 100644 cpanfile
 create mode 100644 lib/Acme/Foo.pm
 create mode 100644 minil.toml
 create mode 100644 t/00_compile.t
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
1..6
ok 2 - Use XSUtil with default value
# Subtest: Use XSUtil with specify value
Writing lib/Acme/Foo.pm
Writing Changes
Writing t/00_compile.t
Writing .travis.yml
Writing .gitignore
Writing LICENSE
Writing cpanfile
[owSiMOY8Za] $ git init
Initialized empty Git repository in /tmp/owSiMOY8Za/.git/
[owSiMOY8Za] $ git add .
[owSiMOY8Za] $ git commit -m initial import
[master (root-commit) ceabbc9] initial import
 8 files changed, 492 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 .travis.yml
 create mode 100644 Changes
 create mode 100644 LICENSE
 create mode 100644 cpanfile
 create mode 100644 lib/Acme/Foo.pm
 create mode 100644 minil.toml
 create mode 100644 t/00_compile.t
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
1..6
ok 3 - Use XSUtil with specify value
1..3
ok
hint: Using 'master' as the name for the initial branch. This default branch 
name
hint: is subject to change. To configure the initial branch name to use in 

Bug#1070937: magit: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:magit
Version: 2.99.0.git0957.ge8c7bd03-1
Severity: serious
Control: close -1 3.3.0-2
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
dh build --with elpa
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
make info
make[2]: Entering directory '/<>'
make[3]: Entering directory '/<>/Documentation'
Generating magit.info
Generating magit-section.info
Generating dir
make[3]: Leaving directory '/<>/Documentation'
make[2]: Leaving directory '/<>'
do not run make
make[1]: Leaving directory '/<>'
   debian/rules override_dh_elpa_test
make[1]: Entering directory '/<>'
make test
make[2]: Entering directory '/<>'
Loading /<>/t/magit-tests.el (source)...
Cannot determine Magit’s version (error "/<>/lisp/magit.el" repo 
static elpa dirname)
Running 18 tests (2024-05-11 17:45:29+, selector ‘t’)
   passed   1/18  magit--with-safe-default-directory (0.009992 sec)
Keeping test directory:
  /tmp/magit-saF5VM/
Test magit-get backtrace:
  signal(magit-git-error ("clone of '/tmp/magit-saF5VM/remote' into su
  (condition-case err (let* ((vnew #'(lambda ( _))) (old (symbol-
  (let ((dir (file-name-as-directory (make-temp-file "magit-" t))) (pr
  (lambda nil (let ((dir (file-name-as-directory (make-temp-file "magi
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name magit-get :documentation nil :body (l
  ert-run-or-rerun-test(#s(ert--stats :selector t :tests [... ... ...
  ert-run-tests(t #f(compiled-function (event-type  event-args) #
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  (progn (load-file "t/magit-tests.el") (ert-run-tests-batch-and-exit)
  eval((progn (load-file "t/magit-tests.el") (ert-run-tests-batch-and-
  command-line-1(("-L" "./lisp" "-L" "/usr/share/emacs/site-lisp/elpa-
  command-line()
  normal-top-level()
Test magit-get condition:
(magit-git-error "clone of '/tmp/magit-saF5VM/remote' into submodule path 
'/tmp/magit-saF5VM/super/repo' failed (in /tmp/magit-saF5VM/super/)")
   FAILED   2/18  magit-get (0.338541 sec)
   passed   3/18  magit-get-boolean (0.133298 sec)
   passed   4/18  magit-get-{current|next}-tag (0.356463 sec)
   passed   5/18  magit-list-{|local-|remote-}branch-names (0.166981 sec)
   passed   6/18  magit-process:match-prompt-match-non-first-prompt (0.93 
sec)
   passed   7/18  magit-process:match-prompt-nil-when-no-match (0.72 sec)
   passed   8/18  magit-process:match-prompt-non-nil-when-match (0.77 sec)
   passed   9/18  magit-process:match-prompt-preserves-match-group (0.83 
sec)
   passed  10/18  magit-process:match-prompt-suffixes-prompt (0.86 sec)
   passed  11/18  magit-process:password-prompt (0.89 sec)
   passed  12/18  magit-process:password-prompt-observed (0.000574 sec)
   passed  13/18  magit-status:file-sections (0.399825 sec)
   passed  14/18  magit-status:log-sections (0.411145 sec)
   passed  15/18  magit-toplevel:basic (0.146376 sec)
Keeping test directory:
  /tmp/magit-aytT6R/
Test magit-toplevel:submodule backtrace:
  signal(magit-git-error ("clone of '/tmp/magit-aytT6R/remote' into su
  (condition-case err (let* ((vnew #'(lambda ( _))) (old (symbol-
  (let ((dir (file-name-as-directory (make-temp-file "magit-" t))) (pr
  (let ((find-file-visit-truename nil)) (let ((dir (file-name-as-direc
  (lambda nil (let ((find-file-visit-truename nil)) (let ((dir (file-n
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name magit-toplevel:submodule :documentati
  ert-run-or-rerun-test(#s(ert--stats :selector t :tests ... :test-map
  ert-run-tests(t #f(compiled-function (event-type  event-args) #
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  (progn (load-file "t/magit-tests.el") (ert-run-tests-batch-and-exit)
  eval((progn (load-file "t/magit-tests.el") (ert-run-tests-batch-and-
  command-line-1(("-L" "./lisp" "-L" "/usr/share/emacs/site-lisp/elpa-
  command-line()
  normal-top-level()
Test magit-toplevel:submodule condition:
(magit-git-error "clone of '/tmp/magit-aytT6R/remote' into submodule path 
'/tmp/magit-aytT6R/super/repo' failed (in /tmp/magit-aytT6R/super/)")
   FAILED  16/18  magit-toplevel:submodule (0.152125 sec)
   passed  17/18  magit-toplevel:tramp (0.788010 sec)
   passed  18/18  magit-utils:add-face-text-property (0.93 sec)

Ran 18 tests, 16 results as expected, 2 unexpected (2024-05-11 17:45:32+, 
3.134105 sec)

2 unexpected results:
   FAILED  magit-get
   FAILED  magit-toplevel:submodule

make[2]: *** [Makefile:109: test] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:24: override_dh_elpa_test] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:14: build] Error 2
dpkg-buildpackage: 

Bug#1070936: libmateweather: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:libmateweather
Version: 1.24.1-1+deb11u1
Severity: serious
Control: close -1 1.26.0-1.1+deb12u2
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --parallel --without autoreconf
   dh_update_autotools_config
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
# upstream tarball is without configure. autogen.sh will create it
NOCONFIGURE=1 ./autogen.sh
/usr/bin/mate-autogen
checking for autoreconf >= 2.53...
  testing autoreconf... found 2.69
checking for pkg-config >= 0.14.0...
  testing pkg-config... found 0.29.2
checking for gtk-doc >= 1.0...

[... snipped ...]

/usr/bin/msgmerge --update  --lang=mr mr.po libmateweather.pot
 done.
.../usr/bin/msgmerge --update  --lang=ms ms.po 
libmateweather.pot
. done.
/usr/bin/msgmerge --update  --lang=nb nb.po libmateweather.pot
... done.
.../usr/bin/msgmerge --update  --lang=nds nds.po 
libmateweather.pot
. done.
/usr/bin/msgmerge --update  --lang=ne ne.po libmateweather.pot
... done.
.../usr/bin/msgmerge --update  --lang=nl nl.po 
libmateweather.pot
. done.
/usr/bin/msgmerge --update  --lang=nn nn.po libmateweather.pot
 done.
 done.
/usr/bin/msgmerge --update  --lang=nso nso.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=oc oc.po libmateweather.pot
 done.
... done.
/usr/bin/msgmerge --update  --lang=or or.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=pa pa.po libmateweather.pot
 done.
 done.
/usr/bin/msgmerge --update  --lang=ps ps.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=pl pl.po libmateweather.pot
... done.
. done.
/usr/bin/msgmerge --update  --lang=pt pt.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=pt_BR pt_BR.po libmateweather.pot
... done.
. done.
/usr/bin/msgmerge --update  --lang=ro ro.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=ru ru.po libmateweather.pot
.. done.
. done.
/usr/bin/msgmerge --update  --lang=rw rw.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=si si.po libmateweather.pot
... done.
. done.
/usr/bin/msgmerge --update  --lang=sk sk.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=sl sl.po libmateweather.pot
 done.
 done.
/usr/bin/msgmerge --update  --lang=sq sq.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=sr sr.po libmateweather.pot
 done.
 done.
/usr/bin/msgmerge --update  --lang=sr@latin s...@latin.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=sv sv.po libmateweather.pot
... done.
/usr/bin/msgmerge --update  --lang=ta ta.po libmateweather.pot
 done.
/usr/bin/msgmerge --update  --lang=te te.po libmateweather.pot
... done.
 done.
/usr/bin/msgmerge --update  --lang=th th.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=tr tr.po libmateweather.pot
... done.
 done.
/usr/bin/msgmerge --update  --lang=ug ug.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=uk uk.po libmateweather.pot
 done.
... done.
/usr/bin/msgmerge --update  --lang=ur ur.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=uz uz.po libmateweather.pot
 done.
... done.
/usr/bin/msgmerge --update  --lang=vi vi.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=wa wa.po libmateweather.pot
 done.
... done.
/usr/bin/msgmerge --update  --lang=xh xh.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=yo yo.po libmateweather.pot
 done.
... done.
/usr/bin/msgmerge --update  --lang=zh_CN zh_CN.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=zh_HK zh_HK.po libmateweather.pot
... done.
 done.
/usr/bin/msgmerge --update  --lang=zh_TW zh_TW.po libmateweather.pot
/usr/bin/msgmerge --update  --lang=zu zu.po libmateweather.pot
.. done.
. done.
rm -f af.gmo && /usr/bin/msgfmt -c --statistics --verbose -o af.gmo af.po
rm -f am.gmo && /usr/bin/msgfmt -c --statistics --verbose -o am.gmo am.po
af.po: 165 translated messages, 18 untranslated messages.
am.po: 174 translated messages, 9 untranslated messages.
rm -f ar.gmo && /usr/bin/msgfmt -c --statistics --verbose -o ar.gmo ar.po
rm -f as.gmo && /usr/bin/msgfmt -c --statistics --verbose -o as.gmo as.po
as.po: 165 translated messages, 18 

Bug#1070934: libgit-repository-perl: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:libgit-repository-perl
Version: 1.324-2
Severity: serious
Control: close -1 1.325-3
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z,relro"
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Git::Repository
Writing MYMETA.yml and MYMETA.json
   dh_auto_build
make -j2
make[1]: Entering directory '/<>'
cp lib/Test/Git.pm blib/lib/Test/Git.pm
cp lib/Git/Repository/Plugin.pm blib/lib/Git/Repository/Plugin.pm
cp lib/Git/Repository/Command.pm blib/lib/Git/Repository/Command.pm
cp lib/Git/Repository/Tutorial.pod blib/lib/Git/Repository/Tutorial.pod
cp lib/Git/Repository.pm blib/lib/Git/Repository.pm
Manifying 5 pod documents
make[1]: Leaving directory '/<>'
   dh_auto_test
make -j2 test TEST_VERBOSE=1
make[1]: Entering directory '/<>'
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" 
"undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.t
t/00-compile.t .
1..4
ok 1 - Git/Repository.pm loaded ok
ok 2 - Git/Repository/Command.pm loaded ok
ok 3 - Git/Repository/Plugin.pm loaded ok
ok 4 - Test/Git.pm loaded ok
ok
#
# Versions for all modules listed in MYMETA.json (including optional ones):
#
# === Configure Requires ===
#
# Module  Want Have
# ---  
# ExtUtils::MakeMaker  any 7.44
#
# === Build Requires ===
#
# Module  Want Have
# ---  
# ExtUtils::MakeMaker  any 7.44
#
# === Test Requires ===
#
# Module   Want Have
# --- - 
# ExtUtils::MakeMaker   any 7.44
# File::Pathany 2.16
# File::Specany 3.78
# IO::Handleany 1.42
# IPC::Open3any 1.21
# Test::Moreany 1.302175
# Test::Requires::Git 1.0051.008
# constant  any 1.33
# lib   any 0.65
# overload  any 1.31
#
# === Test Recommends ===
#
# Module Want Have
# --  
# CPAN::Meta 2.120900 2.150010
#
# === Runtime Requires ===
#
# Module Want Have
# - - 
# Carpany 1.50
# Cwd any 3.78
# Exporterany 5.74
# File::Spec  any 3.78
# File::Spec::Functions   any 3.78
# File::Temp  any   0.2309
# Git::Version::Compare 1.0011.004
# IO::Handle  any 1.42
# Scalar::Utilany 1.55
# System::Command   1.1181.121
# Test::Builder   any 1.302175
# namespace::cleanany 0.27
# strict  any 1.11
# warningsany 1.47
#
t/00-report-prereqs.t ..
1..1
ok 1
ok
# Testing _is_git with /usr/bin/git from /<>
# Testing _is_git with ../../../usr/bin/git from /<>
t/05-try_git.t .
1..36
ok 1 - _is_git( this-command-unlikely-to-even-exist-or-be-git ) fails with bad 
git command
ok 2 - run() fails with bad git command
ok 3 - ... with expected error message
ok 4 - _is_git( /<>/this-command-unlikely-to-even-exist-or-be-git 
) fails with bad git command
ok 5 - run() fails with bad git command
ok 6 - ... with expected error message
ok 7 - _is_git( ../this-command-unlikely-to-even-exist-or-be-git ) fails with 
bad git command
ok 8 - run() fails with bad git command
ok 9 - ... with expected error message
ok 10 - _is_git( /usr/bin/perl ) fails with bad git command
ok 11 - run() fails with bad git command
ok 12 - ... with expected error message
ok 13 - _is_git( git ) fails with bad git command
ok 14 - run() fails with bad git command
ok 15 - ... with expected error message
ok 16 - _is_git( t ) fails with bad git command
ok 17 - run() fails with bad git command
ok 18 - ... with expected error message
ok 19 - _is_git( /usr/bin/git )
ok 20 - _is_git( ../../../usr/bin/git )
ok 21 - real -> /usr/bin/git
ok 22 - symlink to git
ok 23 - link -> target
ok 24 - dangling symlink
ok 25 - link -> target/
ok 26 - symlink to a dir
ok 27 - sub/link -> /usr/bin/git
ok 28 - symlink to git
ok 29 - real -> /usr/bin/git
ok 30 - symlink to git
ok 31 - link -> target
ok 32 - dangling symlink
ok 33 - link -> target/
ok 34 - symlink to a dir
ok 35 - sub/link -> 

Bug#1070935: libical3: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:libical3
Version: 3.0.9-2
Severity: serious
Control: close -1 3.0.16-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with gir --buildsystem=cmake --no-parallel
   dh_update_autotools_config -O--buildsystem=cmake -O--no-parallel
   dh_autoreconf -O--buildsystem=cmake -O--no-parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DGOBJECT_INTROSPECTION=true -DICAL_GLIB_VAPI=true
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix 
Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DGOBJECT_INTROSPECTION=true -DICAL_GLIB_VAPI=true ..
-- The C compiler identification is GNU 10.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features

[... snipped ...]

DTSTART:19761004T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19760930T23Z;BYDAY=1FR;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19770505T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19770501T00Z;BYDAY=1SU;BYMONTH=5
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19770905T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19770831T23Z;BYDAY=1TH;BYMONTH=9
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19780506T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19780501T00Z;BYDAY=1MO;BYMONTH=5
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19780906T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19780831T23Z;BYDAY=1FR;BYMONTH=9
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19830413T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19830409T00Z;BYDAY=2SA;BYMONTH=4
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19831005T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19830930T23Z;BYDAY=1SA;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19840408T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19840409T00Z;BYDAY=2MO;BYMONTH=4
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19841007T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19840930T23Z;BYDAY=1MO;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19860218T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19860216T00Z;BYDAY=3SU;BYMONTH=2
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19861010T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19861008T23Z;BYDAY=2TH;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19870303T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19870301T00Z;BYDAY=1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19871026T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19871030T23Z;BYDAY=-1SA;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19880319T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19880315T00Z;BYDAY=3TU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19881028T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19881030T23Z;BYDAY=-1MO;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19890329T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19890331T00Z;BYDAY=-1FR;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19891006T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19890930T23Z;BYDAY=1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19900407T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19900401T00Z;BYDAY=1SU;BYMONTH=4
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19900929T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19900929T23Z;BYDAY=-1SU;BYMONTH=9
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19910401T00
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19910331T22Z;BYDAY=1MO;BYMONTH=4
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19911001T00
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19910930T21Z;BYDAY=1TU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19920410T00
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;UNTIL=19920407T22Z;BYDAY=2WE;BYMONTH=4
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EET
DTSTART:19921003T00
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;UNTIL=19920930T21Z;BYDAY=1TH;BYMONTH=10

Bug#1070933: khal: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:khal
Version: 1:0.10.3-1
Severity: serious
Control: close -1 1:0.10.5-1.1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
dh build --with python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:232: /usr/bin/python3 setup.py build
running build
running build_py
creating /<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/exceptions.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/__init__.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/__main__.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/parse_datetime.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/configwizard.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/icalendar.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/utils.py -> /<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/controllers.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/terminal.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/version.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/cli.py -> /<>/.pybuild/cpython3_3.9_khal/build/khal
copying khal/calendar_display.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal
creating /<>/.pybuild/cpython3_3.9_khal/build/khal/ui
copying khal/ui/base.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/ui
copying khal/ui/__init__.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/ui
copying khal/ui/editor.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/ui
copying khal/ui/colors.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/ui
copying khal/ui/widgets.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/ui
copying khal/ui/calendarwidget.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/ui
creating /<>/.pybuild/cpython3_3.9_khal/build/khal/khalendar
copying khal/khalendar/exceptions.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/khalendar
copying khal/khalendar/khalendar.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/khalendar
copying khal/khalendar/__init__.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/khalendar
copying khal/khalendar/vdir.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/khalendar
copying khal/khalendar/backend.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/khalendar
copying khal/khalendar/event.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/khalendar
creating /<>/.pybuild/cpython3_3.9_khal/build/khal/settings
copying khal/settings/exceptions.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/settings
copying khal/settings/__init__.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/settings
copying khal/settings/utils.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/settings
copying khal/settings/settings.py -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/settings
copying khal/settings/khal.spec -> 
/<>/.pybuild/cpython3_3.9_khal/build/khal/settings
PYTHONPATH=. python3 -m sphinx -b man doc/source /<>/doc/_build/man
Running Sphinx v3.4.3
making output directory... done
loading intersphinx inventory from 
/usr/share/doc/python3-doc/html/objects.inv...
building [mo]: targets for 0 po files that are out of date
building [man]: all manpages
updating environment: [new config] 40 added, 0 changed, 0 removed
reading sources... [  2%] changelog
reading sources... [  5%] configure
reading sources... [  7%] faq
reading sources... [ 10%] feedback
reading sources... [ 12%] hacking
reading sources... [ 15%] index
reading sources... [ 17%] install
reading sources... [ 20%] license
reading sources... [ 22%] man
reading sources... [ 25%] news
reading sources... [ 27%] news/30c3
reading sources... [ 30%] news/31c3
reading sources... [ 32%] news/callfortesting
reading sources... [ 35%] news/khal01
reading sources... [ 37%] news/khal0100
reading sources... [ 40%] news/khal011
reading sources... [ 42%] news/khal02
reading sources... [ 45%] news/khal03
reading sources... [ 47%] news/khal031
reading sources... [ 50%] news/khal04
reading sources... [ 52%] news/khal05
reading sources... [ 55%] news/khal06
reading sources... [ 57%] news/khal07
reading sources... [ 60%] news/khal071
reading sources... [ 62%] news/khal08
reading sources... [ 65%] news/khal081
reading sources... [ 67%] news/khal082
reading sources... [ 70%] news/khal083
reading sources... [ 72%] news/khal084
reading sources... [ 75%] news/khal09
reading sources... [ 77%] news/khal091
reading sources... [ 80%] news/khal092
reading sources... [ 82%] news/khal093
reading sources... [ 85%] news/khal094
reading sources... [ 87%] news/khal095
reading sources... [ 90%] news/khal096
reading sources... [ 92%] 

Bug#1070932: horizon: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:horizon
Version: 3:18.6.2-5+deb11u2
Severity: serious
Control: close -1 3:23.0.0-5+deb12u1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
make: pyversions: No such file or directory
py3versions: no X-Python3-Version in control file, using supported versions
dh build --buildsystem=python_distutils --with python3,sphinxdoc
   dh_update_autotools_config -O--buildsystem=python_distutils
   dh_autoreconf -O--buildsystem=python_distutils
   dh_auto_configure -O--buildsystem=python_distutils
dh_auto_configure: warning: Please use the third-party "pybuild" build system 
instead of python-distutils
dh_auto_configure: warning: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
make[1]: pyversions: No such file or directory
py3versions: no X-Python3-Version in control file, using supported versions
echo "Do nothing..."
Do nothing...
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
make[1]: pyversions: No such file or directory
py3versions: no X-Python3-Version in control file, using supported versions
# We should add --compilemessages when the .mo are removed.
set -e ; set -x ; for i in 3.9 ; do \
http_proxy=127.0.0.1:9 https_proxy=127.0.0.9:9 \
HTTP_PROXY=127.0.0.1:9 HTTPS_PROXY=127.0.0.1:9 \
PYTHONPATH=/<>/debian/tmp/usr/lib/python3/dist-packages 
PYTHON=python$i python$i -m coverage run -a -m pytest horizon/test/ -n $(nproc --all) -v 
--ds=horizon.test.settings -m "not selenium and not integration" ; \
PYTHONPATH=/<>/debian/tmp/usr/lib/python3/dist-packages 
PYTHON=python$i python$i -m coverage run -a -m pytest openstack_dashboard -v 
--ds=openstack_dashboard.test.settings -m "not selenium and not integration" ; \
PYTHONPATH=/<>/debian/tmp/usr/lib/python3/dist-packages 
PYTHON=python$i python$i -m coverage run -a -m pytest openstack_auth/tests -n $(nproc --all) -v 
--ds=openstack_auth.tests.settings -m "not selenium and not integration" ; \
done
+ nproc --all
+ http_proxy=127.0.0.1:9 https_proxy=127.0.0.9:9 HTTP_PROXY=127.0.0.1:9 
HTTPS_PROXY=127.0.0.1:9 
PYTHONPATH=/<>/debian/tmp/usr/lib/python3/dist-packages 
PYTHON=python3.9 python3.9 -m coverage run -a -m pytest horizon/test/ -n 2 -v 
--ds=horizon.test.settings -m not selenium and not integration
= test session starts ==
platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0 -- 
/usr/bin/python3.9
cachedir: .pytest_cache
Django settings: horizon.test.settings (from command line option)
rootdir: /<>, configfile: tox.ini
plugins: django-3.5.1, forked-1.3.0, xdist-2.2.0
gw0 I / gw1 I

[gw0] linux Python 3.9.2 cwd: /<>

[gw1] linux Python 3.9.2 cwd: /<>

[gw0] Python 3.9.2 (default, Feb 28 2021, 17:03:44)  -- [GCC 10.2.1 20210110]

[gw1] Python 3.9.2 (default, Feb 28 2021, 17:03:44)  -- [GCC 10.2.1 20210110]
gw0 [201] / gw1 [201]

scheduling tests via LoadScheduling

horizon/test/unit/test_base.py::HorizonTests::test_dashboard
horizon/test/unit/test_base.py::HorizonTests::test_horizon_test_isolation_1
[gw1] [  0%] PASSED 
horizon/test/unit/test_base.py::HorizonTests::test_horizon_test_isolation_1
horizon/test/unit/test_base.py::HorizonTests::test_index_url_name
[gw0] [  0%] PASSED horizon/test/unit/test_base.py::HorizonTests::test_dashboard
horizon/test/unit/test_base.py::HorizonTests::test_horizon_test_isolation_2
[gw0] [  1%] PASSED 
horizon/test/unit/test_base.py::HorizonTests::test_horizon_test_isolation_2
[gw1] [  1%] PASSED 
horizon/test/unit/test_base.py::HorizonTests::test_index_url_name
horizon/test/unit/test_base.py::HorizonTests::test_lazy_urls
horizon/test/unit/test_base.py::HorizonTests::test_panel_without_slug_fails
[gw1] [  2%] PASSED 
horizon/test/unit/test_base.py::HorizonTests::test_panel_without_slug_fails
horizon/test/unit/test_base.py::HorizonTests::test_public
[gw0] [  2%] PASSED horizon/test/unit/test_base.py::HorizonTests::test_lazy_urls
horizon/test/unit/test_base.py::HorizonTests::test_panels
[gw0] [  3%] PASSED horizon/test/unit/test_base.py::HorizonTests::test_panels
horizon/test/unit/test_base.py::HorizonTests::test_registry
[gw1] [  3%] PASSED horizon/test/unit/test_base.py::HorizonTests::test_public
horizon/test/unit/test_base.py::HorizonTests::test_registry_two_dashboards
[gw0] [  4%] PASSED horizon/test/unit/test_base.py::HorizonTests::test_registry
horizon/test/unit/test_base.py::HorizonTests::test_registry_without_registerable_class_attr_fails
[gw1] [  4%] PASSED 
horizon/test/unit/test_base.py::HorizonTests::test_registry_two_dashboards
horizon/test/unit/test_base.py::HorizonTests::test_required_permissions
[gw0] [  5%] PASSED 

Bug#1070930: haskell-githash: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:haskell-githash
Version: 0.1.4.0-1
Severity: serious
Control: close -1 0.1.6.3-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
test -x debian/rules
mkdir -p "."
CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
make_setup_recipe
Running ghc --make Setup.hs -o debian/hlibrary.setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking debian/hlibrary.setup ...
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
configure_recipe
Running debian/hlibrary.setup configure --ghc -v2 
--package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
--libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
--builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
--haddockdir=/usr/lib/ghc-doc/haddock/githash-0.1.4.0/ --datasubdir=githash 
--htmldir=/usr/share/doc/libghc-githash-doc/html/ --enable-library-profiling 
--enable-tests
Using Parsec parser
Configuring githash-0.1.4.0...
Dependency base >=4.9.1 && <5: using base-4.13.0.0
Dependency bytestring -any: using bytestring-0.10.10.1
Dependency directory -any: using directory-1.3.6.0
Dependency filepath -any: using filepath-1.4.2.1
Dependency process -any: using process-1.6.9.0
Dependency template-haskell -any: using template-haskell-2.15.0.0
Dependency base >=4.9.1 && <5: using base-4.13.0.0
Dependency bytestring -any: using bytestring-0.10.10.1
Dependency directory -any: using directory-1.3.6.0
Dependency filepath -any: using filepath-1.4.2.1
Dependency githash -any: using githash-0.1.4.0
Dependency hspec -any: using hspec-2.7.1
Dependency process -any: using process-1.6.9.0
Dependency template-haskell -any: using template-haskell-2.15.0.0
Dependency temporary -any: using temporary-1.3
Dependency unliftio -any: using unliftio-0.2.13
Source component graph:
component lib
component test:githash-spec dependency lib
Configured component graph:
component githash-0.1.4.0-EWMeWIEd1YXHyyDgK1gfq1
include base-4.13.0.0
include bytestring-0.10.10.1
include directory-1.3.6.0
include filepath-1.4.2.1
include process-1.6.9.0
include template-haskell-2.15.0.0
component githash-0.1.4.0-7CJF4xJqfu0EZYEwxaRJDG-githash-spec
include base-4.13.0.0
include bytestring-0.10.10.1
include directory-1.3.6.0
include filepath-1.4.2.1
include githash-0.1.4.0-EWMeWIEd1YXHyyDgK1gfq1
include hspec-2.7.1-5JvuKFX0Z3iFazfgnEEvF6
include process-1.6.9.0
include template-haskell-2.15.0.0
include temporary-1.3-AvsKTkX8AtqCfWF6w2go8V
include unliftio-0.2.13-5Ul6qtX6De7516Jlsz3Mou
Linked component graph:
unit githash-0.1.4.0-EWMeWIEd1YXHyyDgK1gfq1
include base-4.13.0.0
include bytestring-0.10.10.1
include directory-1.3.6.0
include filepath-1.4.2.1
include process-1.6.9.0
include template-haskell-2.15.0.0
GitHash=githash-0.1.4.0-EWMeWIEd1YXHyyDgK1gfq1:GitHash
unit githash-0.1.4.0-7CJF4xJqfu0EZYEwxaRJDG-githash-spec
include base-4.13.0.0
include bytestring-0.10.10.1
include directory-1.3.6.0
include filepath-1.4.2.1
include githash-0.1.4.0-EWMeWIEd1YXHyyDgK1gfq1
include hspec-2.7.1-5JvuKFX0Z3iFazfgnEEvF6
include process-1.6.9.0
include template-haskell-2.15.0.0
include temporary-1.3-AvsKTkX8AtqCfWF6w2go8V
include unliftio-0.2.13-5Ul6qtX6De7516Jlsz3Mou
Ready component graph:
definite githash-0.1.4.0-EWMeWIEd1YXHyyDgK1gfq1
depends base-4.13.0.0
depends bytestring-0.10.10.1
depends directory-1.3.6.0
depends filepath-1.4.2.1
depends process-1.6.9.0
depends template-haskell-2.15.0.0
definite githash-0.1.4.0-7CJF4xJqfu0EZYEwxaRJDG-githash-spec
depends base-4.13.0.0
depends bytestring-0.10.10.1
depends directory-1.3.6.0
depends filepath-1.4.2.1
depends githash-0.1.4.0-EWMeWIEd1YXHyyDgK1gfq1
depends hspec-2.7.1-5JvuKFX0Z3iFazfgnEEvF6
depends process-1.6.9.0
depends template-haskell-2.15.0.0
depends temporary-1.3-AvsKTkX8AtqCfWF6w2go8V
depends unliftio-0.2.13-5Ul6qtX6De7516Jlsz3Mou
Using Cabal-3.0.1.0 compiled by ghc-8.8
Using compiler: ghc-8.8.4
Using install prefix: /usr
Executables installed in: /usr/bin
Libraries installed in:
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/githash-0.1.4.0-EWMeWIEd1YXHyyDgK1gfq1
Dynamic Libraries installed in:
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4
Private executables installed in:
/usr/lib/x86_64-linux-ghc-8.8.4/githash-0.1.4.0
Data files installed in: /usr/share/githash
Documentation installed in:

Bug#1070931: healpix-java: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:healpix-java
Version: 3.60+ds-4
Severity: serious
Control: close -1 3.60+ds-5
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with javahelper
   dh_update_autotools_config
   dh_autoreconf
   jh_linkjars
   debian/rules override_jh_build
make[1]: Entering directory '/<>'
jh_build
warning: [options] bootstrap class path not set in conjunction with -source 7
1 warning
Creating destination directory: "debian/_jh_build.javadoc/api/"
cd debian/_jh_build.javadoc/api/jquery && \
rm *.css *.js && \
rm -r external images && \
(for filename in /usr/share/javascript/jquery/* 
/usr/share/javascript/jquery-ui/*; do ln -s $filename; done)
rm: cannot remove 'images': No such file or directory
make[1]: *** [debian/rules:11: override_jh_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/bullseye/

About the archive rebuild: The build was made on virtual machines
of type m6a.large and r6a.large from AWS, using sbuild and a
reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.



Bug#1070929: golang-github-streadway-amqp: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:golang-github-streadway-amqp
Version: 0.0~git20200716.e6b33f4-2
Severity: serious
Control: close -1 0.0~git20200716.e6b33f4-3
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --buildsystem=golang --with=golang
   dh_update_autotools_config -O--buildsystem=golang
   dh_autoreconf -O--buildsystem=golang
   dh_auto_configure -O--buildsystem=golang
   dh_auto_build -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install -trimpath -v -p 2 
github.com/streadway/amqp
internal/unsafeheader
internal/cpu
runtime/internal/atomic
runtime/internal/sys
internal/bytealg
runtime/internal/math

[... snipped ...]

  00 00 4e 20   |..N |

shared_test.go:40: server reading 2

shared_test.go:45: server read:
  00 0a |..|

shared_test.go:40: server reading 1

shared_test.go:57: client write 20:
  01 00 00 00 00 00 0c 00  0a 00 1f 00 0b 00 00 4e  
|...N|
0010  20 00 0a ce   | ...|
shared_test.go:52: client writing 16
shared_test.go:45: server read:
  ce|.|

shared_test.go:40: server reading 7

shared_test.go:45: server read:
  01 00 00 00 00 00 08  |...|

shared_test.go:40: server reading 2

shared_test.go:45: server read:
  00 0a |..|

shared_test.go:40: server reading 2

shared_test.go:45: server read:
  00 28 |.(|

shared_test.go:40: server reading 1

shared_test.go:45: server read:
  01|.|

shared_test.go:40: server reading 1

shared_test.go:45: server read:
  2f|/|

shared_test.go:40: server reading 1

shared_test.go:45: server read:
  00|.|

shared_test.go:40: server reading 1

shared_test.go:45: server read:
  00|.|

shared_test.go:40: server reading 1

shared_test.go:57: client write 16:
  01 00 00 00 00 00 08 00  0a 00 28 01 2f 00 00 ce  
|..(./...|
shared_test.go:45: server read:
  ce|.|

shared_test.go:52: server writing 7

shared_test.go:45: client read:
  01 00 00 00 00 00 05  |...|

shared_test.go:40: client reading 4096

shared_test.go:57: server write 7:
  01 00 00 00 00 00 05  |...|
shared_test.go:52: server writing 5
shared_test.go:45: client read:
  00 0a 00 29 00|...).|

shared_test.go:40: client reading 4096

shared_test.go:57: server write 5:
  00 0a 00 29 00|...).|
shared_test.go:52: server writing 1
shared_test.go:45: client read:
  ce|.|

shared_test.go:40: client reading 4096

shared_test.go:52: client writing 13
shared_test.go:57: server write 1:
  ce|.|
shared_test.go:40: server reading 7
shared_test.go:45: server read:
  01 00 01 00 00 00 05  |...|

shared_test.go:40: server reading 2

shared_test.go:45: server read:
  00 14 |..|

shared_test.go:40: server reading 2

shared_test.go:45: server read:
  00 0a |..|

shared_test.go:40: server reading 1

shared_test.go:45: server read:
  00|.|

shared_test.go:40: server reading 1

shared_test.go:57: client write 13:
  01 00 01 00 00 00 05 00  14 00 0a 00 ce   
|.|
shared_test.go:45: server read:
  ce|.|

shared_test.go:52: server writing 7

shared_test.go:45: client read:
  01 00 01 00 00 00 08  |...|

shared_test.go:40: client reading 4096


Bug#1070928: git-buildpackage: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:git-buildpackage
Version: 0.9.22
Severity: serious
Control: close -1 0.9.30
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
dh build --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:232: /usr/bin/python3 setup.py build
running build
running build_py

[... snipped ...]

Doctest: tests.doctests.test_GitRepository.test_merge ... ok
Doctest: tests.doctests.test_GitRepository.test_pull ... ok
Doctest: tests.doctests.test_GitRepository.test_fetch ... ok
Doctest: tests.doctests.test_GitRepository.test_create_bare ... ok
Doctest: tests.doctests.test_GitRepository.test_nonexistent ... ok
Doctest: tests.doctests.test_GitRepository.test_create_noperm ... ok
Doctest: tests.doctests.test_GitRepository.test_checkout ... ok
Doctest: tests.doctests.test_GitRepository.test_gc ... ok
Doctest: tests.doctests.test_GitRepository.test_grep_log ... ok
Doctest: tests.doctests.test_GitRepository.test_is_ff ... ok
Doctest: tests.doctests.test_GitRepository.test_update_ref ... ok
Doctest: tests.doctests.test_GitRepository.test_make_tree ... ok
Doctest: tests.doctests.test_GitRepository.test_update_submodules ... ok
Doctest: tests.doctests.test_GitRepository.test_get_merge_base ... ok
Doctest: tests.doctests.test_GitRepository.test_status ... ok
Doctest: tests.doctests.test_GitRepository.test_cmd_has_feature ... ok
Doctest: tests.doctests.test_GitRepository.test_set_user_name_and_email ... ok
Doctest: tests.doctests.test_GitRepository.test_set_config_and_get_config ... ok
Doctest: tests.doctests.test_GitRepository.test_git_dir ... ok
Doctest: tests.doctests.test_GitVfs.test_read ... ok
Doctest: tests.doctests.test_GitVfs.test_binary_read ... ok
Doctest: tests.doctests.test_GitVfs.test_content_manager ... ok
Doctest: tests.doctests.test_PristineTar.test_create ... ok
Doctest: tests.doctests.test_PristineTar.test_empty_repo ... ok
Doctest: tests.doctests.test_PristineTar.test_commit_dir ... ok
Doctest: tests.doctests.test_PristineTar.test_create_tarball ... ok
Doctest: tests.doctests.test_PristineTar.test_pristine_tar_commit ... ok
Doctest: tests.doctests.test_PristineTar.test_pristine_tar_commit_with_sig ... 
ok
Doctest: tests.doctests.test_PristineTar.test_pristine_has_commit ... ok
Doctest: tests.doctests.test_PristineTar.test_pristine_tar_checkout ... ok
Doctest: tests.doctests.test_PristineTar.test_pristine_tar_checkout_with_sig 
... ok
Doctest: tests.doctests.test_PristineTar.test_pristine_tar_verify ... ok
Doctest: tests.doctests.test_PristineTar.test_pristine_tar_checkout_nonexistent 
... ok
Doctest: tests.doctests.test_create_remote_repo.test_build_remote_script ... ok
Doctest: 
tests.doctests.test_create_remote_repo.test_build_remote_script_template_dir 
... ok
Doctest: tests.doctests.test_create_remote_repo.test_build_remote_script_bare 
... ok
Doctest: tests.doctests.test_create_remote_repo.test_parse_url ... ok
testHelp (tests.01_test_help.TestHelp) ... ok
test_upstream_source_type (tests.02_test_upstream_source_tar_unpack.TestUnpack) 
... ok
test_upstream_source_unpack 
(tests.02_test_upstream_source_tar_unpack.TestUnpack) ... ok
test_upstream_source_unpack_filtered 
(tests.02_test_upstream_source_tar_unpack.TestUnpack) ... ok
test_upstream_source_unpack_no_filter 
(tests.02_test_upstream_source_tar_unpack.TestUnpack) ... ok
Check if we picked up the epoch correctly (#652366) ... ok
Guess the new version from the upstream tag using a mangled tag format ... ok
Guess the new version from the upstream tag ... ok
Guess with clashing upstream- and non-upstream-tag ... ok
Guess with existing -0... releases ... ok
test_no_changelog 
(tests.03_test_dch_guess_version.TestGuessVersionFromUpstream) ... ok
Test empty repo for submodules ... ok
Add some dummy data ... ok
Add some dummy data ... ok
Add a submodule ... ERROR
Check for submodules ... FAIL
Check for submodules list of  (name, hash) ... ERROR
Dump the repository and check if files exist ... FAIL
Create an upstream tarball ... ok
Create an upstream zip archive ... FAIL
Check the contents of the created tarfile ... FAIL
Add a second submodule with name containing whitespace ... ERROR
Check for submodules list of  (name, hash) ... FAIL
test_guess_comp_type_auto_bzip2 (tests.05_test_detection.TestDetection) ... ok
test_guess_comp_type_bz (tests.05_test_detection.TestDetection) ... ok
test_guess_comp_type_bz2 (tests.05_test_detection.TestDetection) ... ok
test_guess_comp_type_bzip2 (tests.05_test_detection.TestDetection) ... ok
test_guess_comp_type_gz (tests.05_test_detection.TestDetection) ... ok

Bug#1070926: dput-ng: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:dput-ng
Version: 1.33
Severity: serious
Control: close -1 1.35+deb12u1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with bash-completion,python3,sphinxdoc --buildsystem pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:232: /usr/bin/python3 setup.py build
running build
running build_py
creating /<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/exceptions.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/command.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/__init__.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/uploader.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/overrides.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/logger.py -> /<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/dsc.py -> /<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/profile.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/changes.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/util.py -> /<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/core.py -> /<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/interface.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/hook.py -> /<>/.pybuild/cpython3_3.9_dput/build/dput
copying dput/config.py -> /<>/.pybuild/cpython3_3.9_dput/build/dput
creating /<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
copying dput/hooks/__init__.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
copying dput/hooks/checksum.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
copying dput/hooks/distribution.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
copying dput/hooks/gpg.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
copying dput/hooks/deb.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
copying dput/hooks/lintian.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
copying dput/hooks/distro_info_checks.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
copying dput/hooks/impatient.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/hooks
creating /<>/.pybuild/cpython3_3.9_dput/build/dput/configs
copying dput/configs/__init__.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/configs
copying dput/configs/dputcf.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/configs
copying dput/configs/dputng.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/configs
creating /<>/.pybuild/cpython3_3.9_dput/build/dput/commands
copying dput/commands/breakthearchive.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands
copying dput/commands/__init__.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands
copying dput/commands/dm.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands
copying dput/commands/upload.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands
copying dput/commands/cancel.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands
copying dput/commands/reschedule.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands
copying dput/commands/rm.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands
creating /<>/.pybuild/cpython3_3.9_dput/build/dput/commands/contrib
copying dput/commands/contrib/__init__.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands/contrib
copying dput/commands/contrib/debomatic.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/commands/contrib
creating /<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
copying dput/uploaders/ftp.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
copying dput/uploaders/__init__.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
copying dput/uploaders/secure_sftp.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
copying dput/uploaders/sftp.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
copying dput/uploaders/http.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
copying dput/uploaders/local.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
copying dput/uploaders/scp.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
copying dput/uploaders/ftps.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/uploaders
creating /<>/.pybuild/cpython3_3.9_dput/build/dput/interfaces
copying dput/interfaces/__init__.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/interfaces
copying dput/interfaces/cli.py -> 
/<>/.pybuild/cpython3_3.9_dput/build/dput/interfaces
make -C docs html
make[2]: Entering directory '/<>/docs'
sphinx-build -b html -W -d _build/doctrees   . _build/html
Running Sphinx v3.4.3
making output directory... done
building [mo]: targets for 0 po files that are 

Bug#1070925: docker.io: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:docker.io
Version: 20.10.5+dfsg1-1+deb11u2
Severity: serious
Control: close -1 20.10.24+dfsg1-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --buildsystem=golang --with=bash-completion,golang 
--builddirectory=_build
   dh_update_autotools_config -O--buildsystem=golang -O--builddirectory=_build
   dh_autoreconf -O--buildsystem=golang -O--builddirectory=_build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
mkdir -pv /<>/_build/src/github.com/docker/cli
mkdir: created directory '/<>/_build'
mkdir: created directory '/<>/_build/src'
mkdir: created directory '/<>/_build/src/github.com'
mkdir: created directory '/<>/_build/src/github.com/docker'
mkdir: created directory '/<>/_build/src/github.com/docker/cli'
mkdir -pv /<>/_build/src/github.com/docker/docker

[... snipped ...]

ok  github.com/docker/docker/volume/mounts  0.017s  coverage: 67.0% of 
statements
ok  github.com/docker/docker/volume/service 0.128s  coverage: 73.1% of 
statements
ok  github.com/docker/docker/pkg/plugins33.617s coverage: 76.6% of 
statements
?   github.com/docker/docker/pkg/plugins/pluginrpc-gen/fixtures [no 
test files]
?   
github.com/docker/docker/pkg/plugins/pluginrpc-gen/fixtures/otherfixture
[no test files]
?   github.com/docker/docker/pkg/signal/testfiles   [no test files]
?   github.com/docker/docker/pkg/symlink[no test files]
?   github.com/docker/docker/pkg/term   [no test files]
?   github.com/docker/docker/plugin/executor/containerd [no test files]
?   github.com/docker/docker/profiles/apparmor  [no test files]
?   github.com/docker/docker/rootless   [no test files]
?   github.com/docker/docker/rootless/specconv  [no test files]
?   github.com/docker/docker/runconfig/opts [no test files]
?   github.com/docker/docker/testutil/daemon[no test files]
?   github.com/docker/docker/testutil/environment   [no test files]
?   github.com/docker/docker/testutil/fakecontext   [no test files]
?   github.com/docker/docker/testutil/fakegit   [no test files]
?   github.com/docker/docker/testutil/fakestorage   [no test files]
?   github.com/docker/docker/testutil/fixtures/load [no test files]
?   github.com/docker/docker/testutil/fixtures/plugin   [no test files]
?   github.com/docker/docker/testutil/fixtures/plugin/basic [no test files]
?   github.com/docker/docker/testutil/registry  [no test files]
?   github.com/docker/docker/testutil/request   [no test files]
?   github.com/docker/docker/volume [no test files]
?   github.com/docker/docker/volume/service/opts[no test files]
?   github.com/docker/docker/volume/testutils   [no test files]

=== Skipped
=== SKIP: builder/dockerfile TestDispatch (0.00s)
evaluator_test.go:29: os.Getuid() != 0: skipping test that requires root

=== SKIP: builder/dockerfile TestEmptyDockerfile (0.00s)
internals_test.go:72: os.Getuid() != 0: skipping test that requires root

=== SKIP: builder/dockerfile TestSymlinkDockerfile (0.00s)
internals_test.go:72: os.Getuid() != 0: skipping test that requires root

=== SKIP: builder/dockerfile TestDockerfileOutsideTheBuildContext (0.00s)
internals_test.go:72: os.Getuid() != 0: skipping test that requires root

=== SKIP: builder/dockerfile TestNonExistingDockerfile (0.00s)
internals_test.go:72: os.Getuid() != 0: skipping test that requires root

=== SKIP: builder/remotecontext TestCloseRootDirectory (0.00s)
tarsum_test.go:140: os.Getuid() != 0: skipping test that requires root

=== SKIP: builder/remotecontext TestHashFile (0.00s)
tarsum_test.go:140: os.Getuid() != 0: skipping test that requires root

=== SKIP: builder/remotecontext TestHashSubdir (0.00s)
tarsum_test.go:140: os.Getuid() != 0: skipping test that requires root

=== SKIP: builder/remotecontext TestRemoveDirectory (0.00s)
tarsum_test.go:140: os.Getuid() != 0: skipping test that requires root

=== SKIP: container TestStateRunStop (0.00s)
state_test.go:32: DM - disabled unreliable test

=== SKIP: daemon TestRootMountCleanup (0.00s)
daemon_linux_test.go:183: root required

=== SKIP: daemon TestContainerInitDNS (0.00s)
daemon_test.go:147: root required

=== SKIP: daemon TestGetBlkioWeightDevices (0.00s)
daemon_unix_test.go:394: root required

=== SKIP: daemon TestGetBlkioThrottleDevices (0.00s)
daemon_unix_test.go:394: root required

=== SKIP: daemon TestExecSetPlatformOpt (0.00s)
exec_linux_test.go:18: requires AppArmor to be enabled

=== SKIP: daemon TestExecSetPlatformOptPrivileged (0.00s)
exec_linux_test.go:38: requires AppArmor to be enabled

=== SKIP: daemon TestTmpfsDevShmNoDupMount (0.00s)
oci_linux_test.go:66: os.Getuid() != 0: skipping 

Bug#1070924: django-axes: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:django-axes
Version: 5.4.3-1
Severity: serious
Control: close -1 5.39.0-2
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
install -d /<>/debian/.debhelper/generated/_source/home
pybuild --configure --test-pytest -i python{version} -p 3.9
I: pybuild base:232: python3.9 setup.py config
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
pybuild --build --test-pytest -i python{version} -p 3.9
I: pybuild base:232: /usr/bin/python3 setup.py build
running build
running build_py
creating /<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/exceptions.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/backends.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/__init__.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/admin.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/utils.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/signals.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/decorators.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/checks.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/apps.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/middleware.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/models.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/conf.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/helpers.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
copying axes/attempts.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes
creating 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/management
copying axes/management/__init__.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/management
creating /<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_management.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/base.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/__init__.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_signals.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_logging.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/urls.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_decorators.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_handlers.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_admin.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_login.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_middleware.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_checks.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_utils.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_attempts.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/urls_empty.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_helpers.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_backends.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/test_models.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
copying axes/tests/settings.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/tests
creating /<>/.pybuild/cpython3_3.9_django-axes/build/axes/handlers
copying axes/handlers/base.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/handlers
copying axes/handlers/__init__.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/handlers
copying axes/handlers/proxy.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/handlers
copying axes/handlers/database.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/handlers
copying axes/handlers/test.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/handlers
copying axes/handlers/cache.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/handlers
copying axes/handlers/dummy.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/handlers
creating 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/migrations
copying axes/migrations/0005_remove_accessattempt_trusted.py -> 
/<>/.pybuild/cpython3_3.9_django-axes/build/axes/migrations
copying 

Bug#1070923: dateutils: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:dateutils
Version: 0.4.5-1.1
Severity: serious
Control: close -1 0.4.10-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
dh build --no-parallel
   dh_update_autotools_config -O--no-parallel
   dh_autoreconf -O--no-parallel
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o 
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} + -o 
-type l -printf "symlink  %p
" > debian/autoreconf.before
grep -q ^XDT_ configure.ac
autoreconf -f -i
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'

[... snipped ...]

PASS: dgrep.036.clit
PASS: dgrep.037.clit
PASS: dgrep.038.clit
PASS: dgrep.039.clit
PASS: dgrep.040.clit
PASS: dgrep.041.clit
PASS: dgrep.042.clit
PASS: dgrep.043.clit
PASS: dround.001.clit
PASS: dround.002.clit
PASS: dround.003.clit
PASS: dround.004.clit
PASS: dround.005.clit
PASS: dround.006.clit
PASS: dround.007.clit
PASS: dround.008.clit
PASS: dround.009.clit
PASS: dround.010.clit
PASS: dround.011.clit
PASS: dround.012.clit
PASS: dround.013.clit
PASS: dround.014.clit
PASS: dround.015.clit
PASS: dround.016.clit
PASS: dround.017.clit
PASS: dround.018.clit
PASS: dround.019.clit
PASS: dround.020.clit
PASS: dround.021.clit
PASS: dround.022.clit
PASS: dround.023.clit
PASS: dround.024.clit
PASS: dround.025.clit
PASS: dround.026.clit
PASS: dround.027.clit
PASS: dround.028.clit
PASS: dround.029.clit
PASS: dround.030.clit
PASS: dround.031.clit
PASS: dround.032.clit
PASS: dround.033.clit
PASS: dround.034.clit
PASS: dround.035.clit
PASS: dround.036.clit
PASS: tseq.01.clit
PASS: tseq.02.clit
PASS: tseq.03.clit
PASS: tseq.04.clit
PASS: tseq.05.clit
PASS: tseq.06.clit
PASS: tseq.07.clit
PASS: tseq.08.clit
PASS: tseq.09.clit
PASS: tseq.10.clit
PASS: tseq.11.clit
PASS: tseq.12.clit
PASS: tseq.13.clit
PASS: tseq.14.clit
PASS: tseq.15.clit
PASS: tseq.16.clit
PASS: tseq.17.clit
PASS: tseq.18.clit
PASS: tseq.19.clit
PASS: tdiff.001.clit
PASS: tdiff.002.clit
PASS: tdiff.003.clit
PASS: tdiff.004.clit
PASS: tdiff.005.clit
PASS: tdiff.006.clit
PASS: tdiff.007.clit
PASS: tdiff.008.clit
PASS: tdiff.009.clit
PASS: tdiff.010.clit
PASS: tdiff.011.clit
PASS: tdiff.012.clit
PASS: tdiff.013.clit
PASS: tadd.001.clit
PASS: tadd.002.clit
PASS: tadd.003.clit
PASS: tadd.004.clit
PASS: tadd.005.clit
PASS: tadd.006.clit
PASS: tadd.007.clit
PASS: tadd.008.clit
PASS: tadd.009.clit
PASS: tadd.010.clit
PASS: tadd.011.clit
PASS: tgrep.001.clit
PASS: tgrep.002.clit
PASS: tgrep.003.clit
PASS: ttest.001.clit
PASS: ttest.002.clit
PASS: ttest.003.clit
PASS: ttest.004.clit
PASS: ttest.005.clit
PASS: ttest.006.clit
PASS: ttest.007.clit
PASS: tconv.001.clit
PASS: tconv.002.clit
PASS: tconv.003.clit
PASS: tconv.004.clit
PASS: tconv.005.clit
PASS: tconv.006.clit
PASS: tconv.007.clit
PASS: tconv.008.clit
PASS: tconv.009.clit
PASS: tconv.010.clit
PASS: tconv.011.clit
PASS: tconv.012.clit
PASS: tconv.013.clit
PASS: tconv.014.clit
PASS: tround.001.clit
PASS: tround.002.clit
PASS: tround.003.clit
PASS: tround.004.clit
PASS: tround.005.clit
PASS: tround.006.clit
PASS: dtconv.001.clit
PASS: dtconv.002.clit
PASS: dtconv.003.clit
PASS: dtconv.004.clit
PASS: dtconv.005.clit
PASS: dtconv.006.clit
PASS: dtconv.007.clit
PASS: dtconv.008.clit
PASS: dtconv.009.clit
PASS: dtconv.010.clit
PASS: dtconv.011.clit
PASS: dtconv.012.clit
PASS: dtconv.013.clit
PASS: dtconv.014.clit
PASS: dtconv.015.clit
PASS: dtconv.016.clit
PASS: dtconv.017.clit
PASS: dtconv.018.clit
PASS: dtconv.019.clit
PASS: dtconv.020.clit
PASS: dtconv.021.clit
PASS: dtconv.022.clit
PASS: dtconv.023.clit
PASS: dtconv.024.clit
PASS: dtconv.025.clit
PASS: dtconv.026.clit
PASS: dtconv.027.clit
PASS: dtconv.028.clit
PASS: dtconv.029.clit
PASS: dtconv.030.clit
PASS: dtconv.031.clit
PASS: dtconv.032.clit
PASS: dtconv.033.clit
PASS: dtconv.034.clit
PASS: dtconv.035.clit
PASS: dtconv.036.clit
PASS: dtconv.037.clit
PASS: dtconv.038.clit
PASS: dtconv.039.clit
PASS: dtconv.040.clit
PASS: dtconv.041.clit
PASS: dtconv.042.clit
PASS: dtconv.043.clit
PASS: dtconv.044.clit
PASS: dtconv.045.clit
PASS: dtconv.046.clit
PASS: dtconv.047.clit
PASS: dtconv.048.clit
PASS: dtconv.049.clit
PASS: dtconv.050.clit
PASS: dtconv.051.clit
PASS: dtconv.052.clit
PASS: dtconv.053.clit
PASS: dtconv.054.clit
PASS: dtconv.055.clit
PASS: dtconv.056.clit
PASS: dtconv.057.clit
PASS: dtconv.058.clit
PASS: dtconv.059.clit
PASS: dtconv.060.clit
PASS: dtconv.061.clit
PASS: dtconv.062.clit
PASS: dtconv.063.clit
PASS: dtconv.064.clit
PASS: dtconv.065.clit
PASS: dtconv.066.clit
PASS: dtconv.067.clit
PASS: dtconv.068.clit
PASS: dtconv.069.clit
PASS: dtconv.070.clit
PASS: 

Bug#1070922: datalad: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:datalad
Version: 0.14.0-1
Severity: serious
Control: close -1 0.18.1-2
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules build
dh build --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
# cheap fake of an installed datalad, so we get .egg-info with entry points
/usr/bin/make bin
make[2]: Entering directory '/<>'
mkdir -p bin
PYTHONPATH="bin:" python3 setup.py develop --install-dir bin
running develop
running egg_info

[... snipped ...]

return t(*(arg + (filename,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 752, in _wrap_with_tempfile
return t(*(arg + (filename,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 752, in _wrap_with_tempfile
return t(*(arg + (filename,)), **kw)
  [Previous line repeated 2 more times]
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/distribution/tests/test_publish.py",
 line 292, in test_publish_recursive
origin_sub2.config.set(
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/config.py", line 
813, in set
self._run(to_options(replace_all=force) + [var, value],
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/config.py", line 
735, in _run
out = self._runner.run(self._config_cmd + args, **kwargs)
  File "/<>/.pybuild/cpython3_3.9_datalad/build/datalad/cmd.py", 
line 409, in run
raise CommandError(
datalad.support.exceptions.CommandError: CommandError: 'git --git-dir= config 
--local receive.denyCurrentBranch updateInstead' failed with exitcode 128 [err: 
'fatal: --local can only be used inside a git repository']

==
ERROR: datalad.distribution.tests.test_publish.test_publish_with_data
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 1100, in _wrap_with_testrepos
t(*(arg + (uri,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 752, in _wrap_with_tempfile
return t(*(arg + (filename,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 752, in _wrap_with_tempfile
return t(*(arg + (filename,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 752, in _wrap_with_tempfile
return t(*(arg + (filename,)), **kw)
  [Previous line repeated 2 more times]
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/distribution/tests/test_publish.py",
 line 470, in test_publish_with_data
sub1 = GitRepo(opj(src_path, 'subm 1'), create=False)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/support/repo.py", 
line 154, in __call__
instance = type.__call__(cls, *new_args, **new_kwargs)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/support/gitrepo.py",
 line 912, in __init__
raise NoSuchPathError(path)
datalad.support.exceptions.NoSuchPathError: 
/tmp/datalad_temp_test_publish_with_data2ikbbugq/subm 1

==
ERROR: datalad.support.tests.test_annexrepo.test_AnnexRepo_add_submodule
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 1962, in _wrap_skip_if_adjusted_branch
return func(*args, **kwargs)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 752, in _wrap_with_tempfile
return t(*(arg + (filename,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/tests/utils.py", 
line 752, in _wrap_with_tempfile
return t(*(arg + (filename,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/support/tests/test_annexrepo.py",
 line 1790, in test_AnnexRepo_add_submodule
top_repo.add_submodule('sub', name='sub', url=source_path)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/support/gitrepo.py",
 line 2898, in add_submodule
self.call_git(cmd)
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/support/gitrepo.py",
 line 2197, in call_git
out, _ = self._call_git(args, files,
  File 
"/<>/.pybuild/cpython3_3.9_datalad/build/datalad/support/gitrepo.py",
 line 2138, in _call_git
res = runner.run(
  File "/<>/.pybuild/cpython3_3.9_datalad/build/datalad/cmd.py", 
line 409, in run
raise 

Bug#1070921: cpuinfo: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:cpuinfo
Version: 0.0~git20200612.63b2545-2
Severity: serious
Control: close -1 0.0~git20220617.082deff-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary -Scmake
   dh_update_autotools_config -O-Scmake
   dh_autoreconf -O-Scmake
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- \
-DGOOGLETEST_SOURCE_DIR=/usr/src/googletest/ \
-DCPUINFO_BUILD_BENCHMARKS=OFF \
-DCPUINFO_LIBRARY_TYPE=shared \
-DCPUINFO_LOG_LEVEL=error \
-DCMAKE_SKIP_RPATH=ON
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix 
Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DGOOGLETEST_SOURCE_DIR=/usr/src/googletest/ -DCPUINFO_BUILD_BENCHMARKS=OFF 
-DCPUINFO_LIBRARY_TYPE=shared -DCPUINFO_LOG_LEVEL=error -DCMAKE_SKIP_RPATH=ON ..
-- The C compiler identification is GNU 10.2.1
-- The CXX compiler identification is GNU 10.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY


-- Build files have been written to: /<>/obj-x86_64-linux-gnu
make[1]: Leaving directory '/<>'
   dh_auto_build -O-Scmake
cd obj-x86_64-linux-gnu && make -j2 "INSTALL=install 
--strip-program=true" VERBOSE=1
make[1]: Entering directory '/<>/obj-x86_64-linux-gnu'
/usr/bin/cmake -S"/<>" -B"/<>/obj-x86_64-linux-gnu" 
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start "/<>/obj-x86_64-linux-gnu/CMakeFiles" 
"/<>/obj-x86_64-linux-gnu//CMakeFiles/progress.marks"
make  -f CMakeFiles/Makefile2 all
make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
make  -f deps/clog/CMakeFiles/clog.dir/build.make 
deps/clog/CMakeFiles/clog.dir/depend
make  -f CMakeFiles/cpuid-dump.dir/build.make CMakeFiles/cpuid-dump.dir/depend
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd "/<>/obj-x86_64-linux-gnu" && /usr/bin/cmake -E cmake_depends "Unix Makefiles" "/<>" "/<>/deps/clog" 
"/<>/obj-x86_64-linux-gnu" "/<>/obj-x86_64-linux-gnu/deps/clog" 
"/<>/obj-x86_64-linux-gnu/deps/clog/CMakeFiles/clog.dir/DependInfo.cmake" --color=
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd "/<>/obj-x86_64-linux-gnu" && /usr/bin/cmake -E cmake_depends "Unix Makefiles" "/<>" "/<>" 
"/<>/obj-x86_64-linux-gnu" "/<>/obj-x86_64-linux-gnu" "/<>/obj-x86_64-linux-gnu/CMakeFiles/cpuid-dump.dir/DependInfo.cmake" 
--color=
Dependee "/<>/obj-x86_64-linux-gnu/deps/clog/CMakeFiles/clog.dir/DependInfo.cmake" is 
newer than depender 
"/<>/obj-x86_64-linux-gnu/deps/clog/CMakeFiles/clog.dir/depend.internal".
Dependee "/<>/obj-x86_64-linux-gnu/CMakeFiles/cpuid-dump.dir/DependInfo.cmake" is newer 
than depender "/<>/obj-x86_64-linux-gnu/CMakeFiles/cpuid-dump.dir/depend.internal".
Dependee "/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeDirectoryInformation.cmake" is newer 
than depender "/<>/obj-x86_64-linux-gnu/CMakeFiles/cpuid-dump.dir/depend.internal".
Dependee "/<>/obj-x86_64-linux-gnu/deps/clog/CMakeFiles/CMakeDirectoryInformation.cmake" 
is newer than depender 
"/<>/obj-x86_64-linux-gnu/deps/clog/CMakeFiles/clog.dir/depend.internal".
Scanning dependencies of target clog
Scanning dependencies of target cpuid-dump
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make  -f deps/clog/CMakeFiles/clog.dir/build.make 
deps/clog/CMakeFiles/clog.dir/build
make  -f CMakeFiles/cpuid-dump.dir/build.make CMakeFiles/cpuid-dump.dir/build
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
[  2%] Building C object deps/clog/CMakeFiles/clog.dir/src/clog.c.o
[  2%] Building C object CMakeFiles/cpuid-dump.dir/tools/cpuid-dump.c.o
/usr/bin/cc  -I"/<>/include" -I"/<>/src" -g -O2 

Bug#1070920: coq: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:coq
Version: 8.12.0-3
Severity: serious
Control: close -1 8.16.1+dfsg-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with ocaml,python3
   debian/rules build
make[1]: Entering directory '/<>'
dh build --with ocaml,python3
   dh_update_autotools_config
   dh_autoreconf
   dh_ocamlinit
   debian/rules override_dh_auto_configure
make[2]: Entering directory '/<>'
./configure -arch Linux -prefix /usr -mandir /usr/share/man -configdir /etc/xdg/coq -browser 
"/usr/bin/x-www-browser %s &" -with-doc no
You have OCaml 4.11.1. Good!
You have OCamlfind 1.8.1. Good!

[... snipped ...]

TEST  micromega/bug_11191b.v
CHECK micromega/bug_11191b.v
TEST  micromega/bug_11270.v
CHECK micromega/bug_11270.v
TEST  micromega/bug_11436.v
CHECK micromega/bug_11436.v
TEST  micromega/bug_12210.v
CHECK micromega/bug_12210.v
TEST  micromega/bug_9162.v
CHECK micromega/bug_9162.v
TEST  micromega/evars_loops_in_8_10_fixed_8_11.v
CHECK micromega/evars_loops_in_8_10_fixed_8_11.v
TEST  micromega/example.v
CHECK micromega/example.v
TEST  micromega/example_nia.v
CHECK micromega/example_nia.v
TEST  micromega/heap3_vcgen_25.v
CHECK micromega/heap3_vcgen_25.v
TEST  micromega/non_lin_ci.v
CHECK micromega/non_lin_ci.v
TEST  micromega/qexample.v
CHECK micromega/qexample.v
TEST  micromega/rexample.v
CHECK micromega/rexample.v
TEST  micromega/rsyntax.v
CHECK micromega/rsyntax.v
TEST  micromega/square.v
CHECK micromega/square.v
TEST  micromega/zomicron.v
CHECK micromega/zomicron.v
TEST  modules/plik.v
CHECK modules/plik.v
TEST  modules/Nat.v
CHECK modules/Nat.v
TEST  modules/Demo.v
CHECK modules/Demo.v
TEST  modules/PO.v
CHECK modules/PO.v
TEST  modules/Przyklad.v
CHECK modules/Przyklad.v
TEST  modules/SeveralWith.v
CHECK modules/SeveralWith.v
TEST  modules/Tescik.v
CHECK modules/Tescik.v
TEST  modules/WithDefUBinders.v
CHECK modules/WithDefUBinders.v
TEST  modules/cumpoly.v
CHECK modules/cumpoly.v
TEST  modules/errors.v  (-impredicative-set)
CHECK modules/errors.v
TEST  modules/fun_objects.v  (-impredicative-set)
CHECK modules/fun_objects.v
TEST  modules/grammar.v
CHECK modules/grammar.v
TEST  modules/ind.v
CHECK modules/ind.v
TEST  modules/injection_discriminate_inversion.v
CHECK modules/injection_discriminate_inversion.v
TEST  modules/mod_decl.v
CHECK modules/mod_decl.v
TEST  modules/modeq.v  (-top modeq)
CHECK modules/modeq.v
TEST  modules/modul.v  (-top modul)
CHECK modules/modul.v
TEST  modules/nested_mod_types.v
CHECK modules/nested_mod_types.v
TEST  modules/obj.v
CHECK modules/obj.v
TEST  modules/objects.v
CHECK modules/objects.v
TEST  modules/objects2.v
CHECK modules/objects2.v
TEST  modules/pliczek.v
CHECK modules/pliczek.v
TEST  modules/polymorphism.v
CHECK modules/polymorphism.v
TEST  modules/polymorphism2.v
CHECK modules/polymorphism2.v
TEST  modules/pseudo_circular_with.v
CHECK modules/pseudo_circular_with.v
TEST  modules/resolver.v
CHECK modules/resolver.v
TEST  modules/sig.v
CHECK modules/sig.v
TEST  modules/sub_objects.v
CHECK modules/sub_objects.v
TEST  modules/subtyping.v
CHECK modules/subtyping.v
TEST  stm/Nijmegen_QArithSternBrocot_Zaux.v
CHECK stm/Nijmegen_QArithSternBrocot_Zaux.v
TEST  stm/arg_filter_1.v  (-async-proofs-tac-j 1)
CHECK stm/arg_filter_1.v
TEST  stm/classify_set_proof_mode_9093.v  (-async-proofs on -noinit)
CHECK stm/classify_set_proof_mode_9093.v
TEST  stm/delayed_restrict_univs_9093.v  (-async-proofs on)
CHECK stm/delayed_restrict_univs_9093.v
TEST  coqdoc/Record.v
TEST  coqdoc/binder.v
TEST  coqdoc/bug11194.v
TEST  coqdoc/bug11353.v  (-g)
TEST  coqdoc/bug12742.v
TEST  coqdoc/bug5648.v
TEST  coqdoc/bug5700.v
TEST  coqdoc/links.v
TEST  ssr/absevarprop.v
CHECK ssr/absevarprop.v
TEST  ssr/abstract_var2.v
CHECK ssr/abstract_var2.v
TEST  ssr/autoclean.v
CHECK ssr/autoclean.v
TEST  ssr/bang_rewrite.v
CHECK ssr/bang_rewrite.v
TEST  ssr/binders.v
CHECK ssr/binders.v
TEST  ssr/binders_of.v
CHECK ssr/binders_of.v
TEST  ssr/case_TC.v
CHECK ssr/case_TC.v
TEST  ssr/case_TC2.v
CHECK ssr/case_TC2.v
TEST  ssr/case_TC3.v
CHECK ssr/case_TC3.v
TEST  ssr/case_polyuniv.v
CHECK ssr/case_polyuniv.v
TEST  ssr/caseview.v
CHECK ssr/caseview.v
TEST  ssr/congr.v
CHECK ssr/congr.v
TEST  ssr/deferclear.v
CHECK ssr/deferclear.v
TEST  ssr/delayed_clear_rename.v
CHECK ssr/delayed_clear_rename.v
TEST  

Bug#1070919: compyle: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:compyle
Version: 0.7-2
Severity: serious
Control: close -1 0.8.1-4
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py build
running build
running build_py
creating /<>/.pybuild/cpython3_3.9_compyle/build/compyle
copying compyle/ast_utils.py -> 
/<>/.pybuild/cpython3_3.9_compyle/build/compyle

[... snipped ...]

E   pyopencl._cl.RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE 
- clBuildProgram failed: BUILD_PROGRAM_FAILURE - clBuildProgram failed: 
BUILD_PROGRAM_FAILURE
E
E   Build on :
E
E   error: unknown target CPU 'generic'
E
E   (options: -I /usr/lib/python3/dist-packages/pyopencl/cl)
E   (source saved as /tmp/tmp_oyjksbc.cl)

/usr/lib/python3/dist-packages/pyopencl/__init__.py:579: RuntimeError
 TestParallelUtilsJIT.test_scan_works_with_external_func_opencl 

func = 
args = (,)
kwargs = {'ary': }
key = ('gintp', .input_f 
at 0x7f95841ecb80>, .output_f at 0x7f957f8b1dc0>, 
'a+b', 'opencl', False, ...)

@my_decorator
def _deco(func, *args, **kwargs):
# by Michele Simionato
# http://www.phyast.pitt.edu/~micheles/python/
key = key_func(*args, **kwargs)
try:

  return func._memoize_dic[key]  # pylint: disable=protected-access

E   KeyError: ('gintp', .input_f at 0x7f95841ecb80>, 
.output_f at 
0x7f957f8b1dc0>, 'a+b', 'opencl', False, True)

/usr/lib/python3/dist-packages/pytools/__init__.py:621: KeyError

During handling of the above exception, another exception occurred:

self = 

def test_scan_works_with_external_func_opencl(self):
importorskip('pyopencl')

  self._test_scan_with_external_func(backend='opencl')


compyle/tests/test_parallel.py:119:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
compyle/tests/test_parallel.py:712: in _test_scan_with_external_func
scan(ary=a)
compyle/parallel.py:1242: in __call__
self.scan(**kwargs)
compyle/profile.py:48: in wrapper
return method(*args, **kwargs)
compyle/jit.py:526: in __call__
c_func = self._generate_kernel(**kwargs)
:2: in _generate_kernel
???
/usr/lib/python3/dist-packages/pytools/__init__.py:628: in _deco
result = func(*args, **kwargs)
compyle/jit.py:514: in _generate_kernel
return self._generate(declarations=declarations)
compyle/parallel.py:902: in _generate
return self._generate_opencl_kernel(declarations=declarations)
compyle/parallel.py:1095: in _generate_opencl_kernel
knl = GenericScanKernel(
/usr/lib/python3/dist-packages/pyopencl/scan.py:1130: in __init__
self.finish_setup()
/usr/lib/python3/dist-packages/pyopencl/scan.py:1187: in finish_setup
self._finish_setup_impl()
/usr/lib/python3/dist-packages/pyopencl/scan.py:1284: in _finish_setup_impl
candidate_scan_info = candidate_scan_gen_info.build(
/usr/lib/python3/dist-packages/pyopencl/scan.py:887: in build
program = cl.Program(context, self.scan_src).build(options)
/usr/lib/python3/dist-packages/pyopencl/__init__.py:531: in build
self._prg, was_cached = self._build_and_catch_errors(
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 
build_func = . at 0x7f958409d0d0>
options_bytes = b'-I /usr/lib/python3/dist-packages/pyopencl/cl'
source = '\n#define local_barrier() barrier(CLK_LOCAL_MEM_FENCE);\n\n#define 
WITHIN_KERNEL /* empty */\n#define KERNEL __kernel...   {\n
psc_interval_results[psc_GID_0] = psc_partial_scan_buffer[psc_interval_end - 
1];\n}\n}\n'

def _build_and_catch_errors(self, build_func, options_bytes, source=None):
try:
return build_func()
except _cl.RuntimeError as e:
msg = str(e)
if options_bytes:
msg = msg + "\n(options: %s)" % options_bytes.decode("utf-8")

if source is not None:

from tempfile import NamedTemporaryFile
srcfile = NamedTemporaryFile(mode="wt", delete=False, 
suffix=".cl")
try:
srcfile.write(source)
finally:
srcfile.close()

msg = msg + "\n(source saved as %s)" % srcfile.name

code = e.code

routine = e.routine

err = _cl.RuntimeError(

_cl._ErrorRecord(
msg=msg,
code=code,
routine=routine))

# Python 3.2 outputs the whole list 

Bug#1070918: check-manifest: FTBFS in bullseye

2024-05-11 Thread Santiago Vila

Package: src:check-manifest
Version: 0.46-1
Severity: serious
Control: close -1 0.49-1
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary
dh binary --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py build
running build
running build_py
copying check_manifest.py -> 
/<>/.pybuild/cpython3_3.9_check-manifest/build
   dh_auto_test -O--buildsystem=pybuild
I: pybuild pybuild:284: cp /<>/tests.py 
/<>/.pybuild/cpython3_3.9_check-manifest/build
I: pybuild base:232: cd 
/<>/.pybuild/cpython3_3.9_check-manifest/build; python3.9 -m nose 
-v --exclude=test_build_sdist
test_get_vcs_files (tests.TestBzr) ... ok
test_get_vcs_files_added_but_uncommitted (tests.TestBzr) ... ok
test_get_vcs_files_deleted_but_not_removed (tests.TestBzr) ... SKIP: this 
cosmetic feature is not supported with bzr
test_get_vcs_files_empty (tests.TestBzr) ... ok
test_get_vcs_files_in_a_subdir (tests.TestBzr) ... ok
test_get_vcs_files_nonascii_filenames (tests.TestBzr) ... ok
test_terminal_encoding_cp0 (tests.TestBzrTerminalCharsetDetectionOnNewPythons) 
... SKIP: 'oem' codec not available on Python before 3.6
test_terminal_encoding_cp0 (tests.TestBzrTerminalCharsetDetectionOnOldPythons) 
... ok
test_terminal_encoding_not_known 
(tests.TestBzrTerminalCharsetDetectionOnOldPythons) ... ok
test_terminal_encoding_stdin_known 
(tests.TestBzrTerminalCharsetDetectionOnOldPythons) ... ok
test_terminal_encoding_stdout_known 
(tests.TestBzrTerminalCharsetDetectionOnOldPythons) ... ok
test_MANIFEST_in_does_not_need_to_be_added_to_be_considered 
(tests.TestCheckManifest) ... ok
test_all_is_well (tests.TestCheckManifest) ... ok
test_bad_ideas (tests.TestCheckManifest) ... ok
test_extra_ignore (tests.TestCheckManifest) ... ok
test_forgot_to_git_add_anything (tests.TestCheckManifest) ... ok
test_ignore_bad_ideas (tests.TestCheckManifest) ... ok
test_missing_source_files (tests.TestCheckManifest) ... ok
test_not_python_project (tests.TestCheckManifest) ... ok
test_python_from_path (tests.TestCheckManifest) ... ok
test_relative_pathname (tests.TestCheckManifest) ... ok
test_relative_python (tests.TestCheckManifest) ... ok
test_setup_py_does_not_need_to_be_added_to_be_considered 
(tests.TestCheckManifest) ... ok
test_suggestions (tests.TestCheckManifest) ... ok
test_suggestions_all_unknown_patterns (tests.TestCheckManifest) ... ok
test_suggestions_create (tests.TestCheckManifest) ... ok
test_suggestions_some_unknown_patterns (tests.TestCheckManifest) ... ok
test_suggestions_update (tests.TestCheckManifest) ... ok
test_read_config_no_config (tests.TestConfiguration) ... ok
test_read_manifest (tests.TestConfiguration) ... ok
test_read_manifest_no_manifest (tests.TestConfiguration) ... ok
test_read_pyproject_config_extra_ignores (tests.TestConfiguration) ... ok
test_read_pyproject_config_ignore_bad_ideas (tests.TestConfiguration) ... ok
test_read_pyproject_config_no_option (tests.TestConfiguration) ... ok
test_read_pyproject_config_no_section (tests.TestConfiguration) ... ok
test_read_pyproject_config_override_ignores (tests.TestConfiguration) ... ok
test_read_setup_config_extra_ignores (tests.TestConfiguration) ... ok
test_read_setup_config_ignore_bad_ideas (tests.TestConfiguration) ... ok
test_read_setup_config_no_option (tests.TestConfiguration) ... ok
test_read_setup_config_no_section (tests.TestConfiguration) ... ok
test_read_setup_config_override_ignores (tests.TestConfiguration) ... ok
test_detect_git_submodule (tests.TestGit) ... ok
test_get_vcs_files (tests.TestGit) ... ok
test_get_vcs_files_added_but_uncommitted (tests.TestGit) ... ok
test_get_vcs_files_deleted_but_not_removed (tests.TestGit) ... ok
test_get_vcs_files_empty (tests.TestGit) ... ok
test_get_vcs_files_in_a_subdir (tests.TestGit) ... ok
test_get_vcs_files_nonascii_filenames (tests.TestGit) ... ok
test_get_versioned_files_with_git_submodules (tests.TestGit) ... ERROR
test_get_versioned_files_with_git_submodules_with_git_index_file_set 
(tests.TestGit) ... ERROR
test_get_vcs_files (tests.TestHg) ... ok
test_get_vcs_files_added_but_uncommitted (tests.TestHg) ... ok
test_get_vcs_files_deleted_but_not_removed (tests.TestHg) ... ok
test_get_vcs_files_empty (tests.TestHg) ... ok
test_get_vcs_files_in_a_subdir (tests.TestHg) ... ok
test_get_vcs_files_nonascii_filenames (tests.TestHg) ... ok
test_default_excludes_egg_info (tests.TestIgnoreList) ... ok
test_default_excludes_egg_info_in_a_subdirectory (tests.TestIgnoreList) ... ok
test_default_excludes_pkg_info (tests.TestIgnoreList) ... ok
test_exclude_doest_apply_to_directories (tests.TestIgnoreList) ... ok

Bug#1067842: transition: octave-9

2024-05-11 Thread Graham Inggs
Hi Sébastien

On Sat, 11 May 2024 at 08:48, Sébastien Villemot  wrote:
> Thanks. Uploaded and built on all release architectures.

binNMUs underway!

Regards
Graham



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-05-11 Thread Petter Reinholdtsen
[Salvatore Bonaccorso]
> Note that if you are confident that the upload is accepted as it, you
> *could* already upload according to the improved workflow. *But* given
> the uncertainity if SRM want you to have the version changed I would
> wait for their ack.

I do not feel that confident, but I do feel some surprise that it should
take two months to get feedback from the release managers.

I'll give it another week and close this proposal and move on if I do
not hear any conclusion.

-- 
Happy hacking
Petter Reinholdtsen



Bug#1070917: pycurl: Please revert back to the GnuTLS libcurl, for HTTP3 support

2024-05-11 Thread Samuel Henrique
Source: pycurl
Version: 7.45.3-2
Severity: wishlist
X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org

Hello Scott,

On the latest upload of pycurl, the libcurl variant used to link against was
switched from GnutTLS to OpenSSL.

The request came from #1065007
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065007) but I don't think
there were any valid reasons for the switch documented on the request.

We are about to enable HTTP3 on the GnutTlS libcurl, and it's very unlikely
that we will get HTTP3 support for the OpenSSL libcurl before the next stable
release.

If you revert the change back to GnutTLS, then pycurl will have support for
HTTP3 very soon, otherwise it won't get it until after the next stable release.

I also have plans on moving curl (the CLI) to the GnutTLS libcurl so we can get
HTTP3 support on the curl command for the next stable release.

For reference, this table lists the options which would be missing from GnuTLS,
compared to OpenSSL (some of them are OpenSSL-specific so GnuTLS is not really
missing): https://curl.se/libcurl/c/tls-options.html

Curl upstream has shown interest in helping increase the compatibility for
GnutTLS, so we can open a feature request for any option there that's mising. I
believe it won't be an issue to revert back to GnuTLS because that's what the
package was using before the latest upload.

Regards,

--
Samuel Henrique 



Bug#1070916: apt-src: [INTL:nl] Dutch translation for the apt-src package's documentation

2024-05-11 Thread Frans Spiesschaert
 
 
Package: apt-src 
Severity: wishlist 
Tags: l10n patch 
 
 
 
 
Dear Maintainer, 
 
 
Please find attached a Dutch translation for the apt-src package's 
documentation. A draft has been posted to the debian-l10n-dutch mailing
list allowing for review. 
Please add it to your next package revision. 
It should be put as "man/po/nl.po" in your package build tree. 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip


Bug#1065325: morph's abandoned packages (list)

2024-05-11 Thread Nilesh Patra
Quoting Alexandre Detiste :
>  I would pick-up matplotlib I guess, I have some special connection to it,
>  It was one the packages that enabled me to escape
>  my horrible SAS-Insitute powered previous job/life.
>  
>  It's a big one.
>  
>  Help is appreciated, I already cherry picked some commits from Ciel's PR.

Would you consider to add me in as an Uploader (co-maintainer) alongside you?

I am a Debian Developer.

Best,
Nilesh


signature.asc
Description: PGP signature


Bug#1070915: hiredict: Circular build dependency with redict

2024-05-11 Thread Adrian Bunk
Source: hiredict
Version: 1.3.1-1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: Debian Redict Maintainers , 
Maytham Alsudany 
Control: affects -1 src:redict

https://buildd.debian.org/status/package.php?p=redict=sid
https://buildd.debian.org/status/package.php?p=hiredict=sid

Circular build dependencies are a pain since they require
bootstrapping on every single architecture.

I would suggest to drop the buildtime test in hiredict,
and run it as autopkgtest instead.



Bug#1070914: firefox-esr version 115.10.0esr-1~deb12u1 hangs, even with `-safe-mode` option.

2024-05-11 Thread Olivia May
Package: firefox-esr
Version: 115.10.0esr-1~deb12u1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: olivia@tuta.io

Dear Maintainer,

I'm using devuan daedalus with openrc, using an unforked firefox-esr package
(meaning it's identical to the debian package). When I try to start firefox-
esr, it hangs. I'm using gnome 1:43+1. I tried to use -safe-mode and gdb and it
still hanged. I haven't tested this on debian.

Thank you,
Olivia


-- Package-specific info:

-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.7-0.5~deb12u1
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u7
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.10-1~deb12u1devuan1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1+deb12u2
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libx11-xcb1  2:1.8.4-2+deb12u2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.3-1devuan1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.6-0+deb11u1
ii  libavcodec59  7:5.1.4-0+deb12u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20.1-2+deb12u1
pn  pulseaudio 

-- no debconf information



Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)

2024-05-11 Thread Samo Pogačnik
Dne 06.05.2024 (pon) ob 15:02 +0200 je Daniel Gröber napisal(a):
> 
> Hmm. I'm not sure I like the idea of abusing libexec in this
> way. Technically speaking it's for "internal binaries that are not intended
> to be executed directly by users or shell scripts" this is clearly not the
> case here.
> 
> Looking over [git-* packages] to see what other packages do I see most git
> addons are in fact installed into /usr/bin.
> 
> [git-* packages]: 
> 
https://packages.debian.org/search?searchon=contents=git-=filename=stable=any
> 
> Notable exception: git-absorb is still in lib/git-core and has [Bug#985775]
> which seems like it may be relevant to our problem. Have a read of it when
> you get the chance. Some snippets "Git changed the gitexecdir directory"
> maybe that change is what broke completion from git-core?  "... git-absorb
> works but git's bash completion doesn't suggest absorb" So they are aware
> of the completion issue already.
> 
> [Bug#985775]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985775

I also believe, this bug indicates the same problem. Unfortunately nothing have
changed since 2021. A reference to a git change in the bug report indicates that
one can add completion commands like:
git config --global completion.commands subrepo
I've tested that and it works, however i am not a fan of this solution, while
automatic detection of /usr/bin/git-* is available.

> 
> Anyway. I think the right solution here is to patch git-subrepo. IMO what's
> in git-subrepo.d really belongs in /usr/share/git-subrepo OR could just be
> concatenated into the main git-subrepo script, hmm. Bonus points for
> forwarding this bug and patch upstream.
> 

I prepared another change regarding git bash-completion integration using
"/usr/bin" and "/usr/share" in a similar way as some other packages (i.e. dcut,
dput, lintian, ...).

And yes it may be worth asking upstream how do they feel about the problem. For
now i've avoided touching upstream code, but if you prefer i can try to rework
the change in upstream code and produce first patch for the package.

--Samo



Bug#1070913: x52pro: Add Appstream metainfo announcing HW support

2024-05-11 Thread Petter Reinholdtsen
Package: x52pro
Version: 0.1.1-2.3
Tags: patch

Here is a patch for bmusb to add Appstream metainfo XML announcing the
hardware handled by this package.  I was a bit unsure if it should be
attached to the library or -dev package, but concluded that the library
package seem more useful for endusers as it have a utility available.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the USB
IDs are discovered.

diff --git a/debian/at.hasenleithner.plasma.x52pro.metainfo.xml 
b/debian/at.hasenleithner.plasma.x52pro.metainfo.xml
new file mode 100644
index 000..d501a6a
--- /dev/null
+++ b/debian/at.hasenleithner.plasma.x52pro.metainfo.xml
@@ -0,0 +1,23 @@
+
+
+  at.hasenleithner.plasma.x52pro
+  MIT
+  libx52pro0
+  MFD and LED library for Saitek X52pro joysticks
+  
+The library libx52pro is designed to support MFD and LED found
+on Saitek X52 and X52pro joystick.  Library does not deal with the
+HID part of the joystick since this feature is already fully
+supported by the Linux kernel 2.6.x.  This package include the
+x52output utility.
+  
+  
+System
+  
+  
+usb:v06A3p0255d*
+usb:v06A3p075Cd*
+usb:v06A3p0762d*
+usb:v06A3p0BACd*
+  
+
diff --git a/debian/libx52pro0.install b/debian/libx52pro0.install
index 9c7e8b7..43f97bd 100644
--- a/debian/libx52pro0.install
+++ b/debian/libx52pro0.install
@@ -1,2 +1,3 @@
 usr/lib/lib*.so.*
 usr/bin/x52output
+debian/at.hasenleithner.plasma.x52pro.metainfo.xml usr/share/metainfo

-- 
Happy hacking
Petter Reinholdtsen



Bug#1070912: libuv1: latest upload reverts time_t transition

2024-05-11 Thread Adrian Bunk
Source: libuv1
Version: 1.48.0-2
Severity: serious

The latest upload reverts the the time_t transition
rename from libuv1 to libuv1t64.



Bug#1070909: llvm-toolchain-18: FTBFS on riscv64: dh_install: warning: llvm-18-linker-tools missing files: usr/lib/llvm-18/lib/LLVMgold.so

2024-05-11 Thread Aurelien Jarno
On 2024-05-11 15:46, Sebastian Ramacher wrote:
> Source: llvm-toolchain-18
> Version: 1:18.1.5-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> riscv64 is now a release architecture and llvm-toolchain-18 built
> previously.
> 
> https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-18=riscv64=1%3A18.1.5-2=1715249422=0
> 
>debian/rules override_dh_install
> make[1]: Entering directory '/<>'
> dh_install -p libpolly-18-dev usr/lib/llvm-18/lib/cmake/polly/*.cmake 
> usr/lib/llvm-18/lib/cmake/polly
> rm -rf debian/tmp/usr/lib/llvm-18/lib/cmake/polly/*.cmake
> dh_install --fail-missing 
> dh_install: warning: Please use dh_missing --list-missing/--fail-missing 
> instead
> dh_install: warning: This feature will be removed in compat 12.
> dh_install: warning: Cannot find (any matches for) 
> "usr/lib/llvm-18/lib/LLVMgold.so" (tried in ., debian/tmp)
> 
> dh_install: warning: llvm-18-linker-tools missing files: 
> usr/lib/llvm-18/lib/LLVMgold.so
> dh_install: error: missing files, aborting
> make[1]: *** [debian/rules:1432: override_dh_install] Error 255

I believe this should be fixed by the following patch. I have launched a
local build and I will confirm that when it is done.

diff -Nru llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in 
llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in
--- llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in
2024-04-29 11:11:01.0 +0200
+++ llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in
2024-05-11 19:31:14.0 +0200
@@ -2,4 +2,4 @@
 
 usr/lib/llvm-@LLVM_VERSION@/lib/libLTO.so.@LLVM_VERSION@.1
 [!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMPolly.so
-[!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so
+[!powerpc !powerpcspe !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so
diff -Nru llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in 
llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in
--- llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in  
2024-03-06 09:19:46.0 +0100
+++ llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in  
2024-05-11 19:33:50.0 +0200
@@ -1,3 +1,3 @@
 #!/usr/bin/dh-exec
 
-[!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so 
usr/lib/bfd-plugins/LLVMgold-@LLVM_VERSION@.so
+[!powerpc !powerpcspe !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so 
usr/lib/bfd-plugins/LLVMgold-@LLVM_VERSION@.so

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net



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

2024-05-11 Thread Xiyue Deng
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
>>Section  : lisp
>> 
>> The source builds the following binary packages:
>> 
>>   elpa-lua-mode - Emacs major-mode for editing Lua programs
>> 
>> To access further information about this package, please visit the following 
>> URL:
>> 
>>   https://mentors.debian.net/package/lua-mode/
>> 
>> Alternatively, you can download the package with 'dget' using this command:
>> 
>>   dget -x 
>> https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20231023~git-1.dsc
>> 
>> Changes since the last upload:
>> 
>>  lua-mode (20231023~git-1) unstable; urgency=medium
>>  .
>>* Sync to latest upstream snapshot (d074e41)
>>* Drop the patch applied upstream and reorder the remaining patch
>>* Update upstream license to GPL-3+ following upstream change
>>* Add a missing upstream copyright holder
>> 
>> Regards,
>> -- 
>> Xiyue Deng
>> 

-- 
Xiyue Deng



Bug#1070911: RFP: kicad-packages3d-generator -- generate 3D models for kicad from the commandline

2024-05-11 Thread Matthias Geiger
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-electronics-de...@alioth-lists.debian.net, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: kicad-packages3d-generator
  Version : 6.0.9
  Upstream Contact: KiCad EDA project
* URL : 
https://gitlab.com/kicad/libraries/kicad-packages3D-generator
* License : GPL-3+
  Programming Lang: Python
  Description : generate 3D models for kicad from the commandline

kicad-packages3d-generator allows users that are not skilled in CAD tools to
create a 3d model for a part from a yaml file defining the 3d properties
of the part. I used this to contribute a 3d model for a part I needed. 
- From a quick glance some python libraries seem to be missing.
 
This would make a nice addition to Debian imo.

best, 

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmY/qA8VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1fgkP/0wiSiT+ksJRpX+3iDyf07KmDklF
889BiJAGvnNfrLbHnWAzq/KVErWYPUgfWOK7LRpCPsqkyafG/KGQJQgyrTU7l91q
N7A1rH+H5hqSuoX6q3lN0xyrr9T4GmCJ7lRELIQ/QSUYgCwpTVsl70CM5eS4RKDK
d95Nz5rkncYGAI6IW15eR8RMXuvgewAO6dylSbvvI0t3p6ALok3IGV3scCtBy1dJ
IcaoM8K3luBa77p6WKf1k73xkuDAglzhalE4uU35F5y0wG3MX8VuSChhkHxlgcM6
oOGFm1Ua9241J7bGJtjYgfarsZZRpI0PiTs5qSQAijluzMf/CM6Kymt5ubI1Ojs2
VxAr8p0a4GvRAKkNpxgCyT9s0pSzKYZegJoaqgUQw5Kc0mt2i/ZnmqgkeFYJ/XMo
Go6GPxSOv/mjpQdw3ggkJN5z7uUw+2nyb228pC/5MU6Bx8azqDJ4rTrClB/krnzw
aQtRH1zujDrC7NpmFnzobNmEq+PzJI8ShFdILDt6Q/vvfF01dBSPGKqU08bUyAqx
GYnkXjbn8JBbBN57XA+Gcxsm9MzXED9djIou1MkZOCJWRWonmPMsjYLfEqeEK4NO
NU5KtYoOLae4QvNJhnV1y6vDO4IGWz7yT2MyN5bN4MA8liKDzS1m1JOPJkceOOrM
/X7LnLZidNhrYMZs
=OnqV
-END PGP SIGNATURE-



Bug#1070853: strace: test failures on 32bit with 64bit time_t

2024-05-11 Thread Bo YU

Hi,
On Sat, May 11, 2024 at 12:21:05AM +0300, Adrian Bunk wrote:

Control: retitle -1 strace: test failures on 32bit

The tests also fail on i386, so do not seem to be related to time_t.


Thanks for working on this. I will report this to upstream.


--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature


Bug#714589:

2024-05-11 Thread Andreas Metzler
On 2024-05-10 Andreas Metzler  wrote:
[...]
> However that was quite painful. codesearch.debian.net lists 78 packages
> matching libgcrypt-config. I suspect the majority will be using the
> macros from libgcrypt.m4 and therefore already use gpgrt-config but
> I also suspect that about a quarter of these either do not or do not or
> do not use/autoupdate the current libgcrypt.m4

Hello,

I have taken a peek, but will stop for now. The new version of
AM_PATH_LIBGCRYPT() does not work without libgcrypt-config unless
AM_PATH_GPG_ERROR() is used before. There are many rdeps that do not use
libgpg-error. I have asked upstream on how to move on from here.

https://dev.gnupg.org/T7114

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#1061515: transition: ace

2024-05-11 Thread Sudip Mukherjee
On Mon, 6 May 2024 at 13:06, Sudip Mukherjee  wrote:
>
> On Sat, 4 May 2024 at 08:44, Sebastian Ramacher  wrote:
> >
> > Control: tags -1 confirmed
> >
> > On 2024-01-25 19:47:27 +, Sudip Mukherjee wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > X-Debbugs-Cc: sudipm.mukher...@gmail.com
> > > Control: affects -1 + src:ace
> > >
> > >
> > > Hi,
> > >
> > > Small transition with only two affected packages: diagnostics, ivtools,
> > > Both of them builds fine with ace 7.1.3+dfsg-1 in experimental.
> > >
> > > The autogenerated ben tracker looks good. Please consider 'ace' for
> > > transition.
> > > Thanks in advance.
> >
> > Please go ahead.
>
> Thanks. Uploaded to unstable now.

"ace" has now migrated to testing.



-- 
Regards
Sudip



Bug#1070787: coq-corn: produces empty binary

2024-05-11 Thread julien . puydt
Hi,

Le jeudi 09 mai 2024 à 09:45 +0200, Gianfranco Costamagna a écrit :
> Source: coq-corn
> Version: 8.19.0-1
> Severity: serious
> 
> Hello, looks like there are at least two issues:
> 1) fta directory was stripped on tarball import, not sure how and
> why, because the upstream repo still contains it
> (this makes autopkgtest fail)
> 
> 2) the produced binary package looks empty
> 
> https://packages.debian.org/sid/amd64/libcoq-corn/filelist
> /usr/share/doc/libcoq-corn/changelog.Debian.gz
> /usr/share/doc/libcoq-corn/copyright
> /var/lib/coq/md5sums/libcoq-corn.checksum
> 
> For sure changes in configure.sh are a possible culprit

What happened?

I ran "uscan -v" in my ~/Debian/ocaml/ directory. At one point coq-
corn's tarball got downloaded as 8.19.0.tar.gz and symlinked to coq-
corn_8.19.0.tar.gz ; then later coq-math-classes' tarball got
downloaded as 8.19.0.tar.gz and symlinked to coq-math-
classes_8.19.0.tar.gz (they use the same version as the latest Coq they
target...).

The end result is that the final 8.19.0.tar.gz was really the coq-math-
classes tarball, but there were two symlinks to it! So when I imported
the tarballs (gbp import-orig ../correct-package-source-
name_8.19.0.tar.gz) and updated the packages, I ended up with the wrong
sources in the coq-corn directory! And since the Debian packages for
both look pretty much the same, I didn't notice anything amiss when
compiling.

That is really stupid ; perhaps I should file a bug report against
uscan because it's a sort of race condition...

In any case, thanks for the report, I'll fix the mess!

Cheers,

J.Puydt



Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

2024-05-11 Thread Reinhard Tartler
Thanks for looking into this,

On Sat, May 11, 2024 at 6:00 AM Faidon Liambotis 
wrote:

> Control: tags -1 confirmed
>
> On Wed, May 08, 2024 at 03:10:40AM +0300, Eugen Stan wrote:
> > I followed the guide to run wasm images on my system and it failed with
> > errors.
> >
> > I believe the issue is that podman looks for crun-wasm binary by default.
> > I failed to configure podman to use crun instead of crun-wasm.
> > I created a simbolic link named crun-wasm:
> >
> > sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm
>
> Ouch! You're right. This worked when I enabled WasmEdge in crun, but
> was changed upstream at some point since.
>
> Apparently Fedora/RedHat ship a "crun-wasm" package, which contains a) this
> symlink, b) a dependency on WasmEdge.
>
> In Debian, the main "crun" package has a Suggests on libwasmedge0.
>
> I see three paths forward:
> 1) We do the same, creating a new (almost) empty package.
> 2) We ship a /usr/bin/crun-wasm symlink in the crun package.
> 3) We patch podman to use /usr/bin/crun instead of, or in addition to,
> /usr/bin/crun-wasm.
>
> I don't particularly love option (1). I'm split between options (2) and
> (3), not loving either.
>
> Thoughts?
>

I think we should do either 1 or 2 to minimize divergence with upstream. My
preference would be 2 to enable an out-of-the box experience.

Is there any reason to not have that symlink installed by default in the
`crun` package?


-- 
regards,
Reinhard


Bug#1023047: Re:

2024-05-11 Thread erebion
Went doing other things, came back, opened wsjtx again and noticed audio 
input works. No crashes so far. (what the?!)


Not sure what the hell is going on, but maybe I have magic hands. :p

Or maybe the config was broken and opening again wrote a new config?

For now I cannot get the issue back, but others with the same issue: 
Maybe try removing the config and starting with a new config, maybe 
something changed..?


erebion

On 11.05.24 16:20, erebion wrote:

Oh, and looking at logs, kernel says:

kernel: traps: wsjtx[110457] general protection fault ip:7fa7cc1071ee 
sp:7ffe8c52a530 error:0 in libQt5Gui.so.5.15.10[7fa7cc0e2000+4ef000]


erebion



--
erebion

Matrix: @erebion:erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the aforementioned 
languages.



OpenPGP_0x8EAF40326E02AE7D.asc
Description: OpenPGP public key
BEGIN:VCARD
VERSION:4.0
N:;erebion;;;
FN:erebion
EMAIL;PREF=1:ereb...@erebion.eu
IMPP:matrix:u/erebion:erebion.eu
URL:https://erebion.eu
TZ:Europe/Berlin
END:VCARD


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#940960: ITP: linenoise -- Minimal replacement for readline

2024-05-11 Thread Jeremy Sowden
On 2024-05-05, at 07:33:30 +0800, Maytham Alsudany wrote:
> Any progress on getting linenoise packaged? This is urgently needed to
> devendor linenoise in the redict package (a new fork of redis).
> 
> If you've lost interest, I'm happy to take over this ITP.

I can't speak for Blair, but I transferred ownership of the ITP bug to
him, because I didn't have a use-case for linenoise, so if you want to
take it on, that's fine by me.

I've had a quick look at the upstream project and it doesn't seem
entirely dead, which had been a concern.  There isn't a lot of activity,
but some commits are being made.  No response to my PR, however. :) I've
updated my Salsa repo to the latest upstream snapshot and given the
packaging a polish:

  https://salsa.debian.org/azazel/linenoise

HTH,

J.


signature.asc
Description: PGP signature


Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

2024-05-11 Thread Eugen Stan

Hi,

I tried to configure podman to use crun-wasm and failed.

There seems to be 11 references in the org 
https://github.com/search?q=org%3Acontainers%20crun-wasm=code .


So the safer option would be to package crun-wasm IMO.

Asked for more information in the issue 
https://github.com/containers/crun/issues/1468 .


I would add the symlink. Other programs might look for the binary.
Looking at the references to crun-wasm I think having a crun-wasm 
package that:

- depends on crun and wasmedge
- creates a symlink to crun

does not sond so bad.
On the other hand, maintaining an extra package does not sound that nice 
either.



Regards,
Eugen

La 11.05.2024 12:55, Faidon Liambotis a scris:

Control: tags -1 confirmed

On Wed, May 08, 2024 at 03:10:40AM +0300, Eugen Stan wrote:

I followed the guide to run wasm images on my system and it failed with
errors.

I believe the issue is that podman looks for crun-wasm binary by default.
I failed to configure podman to use crun instead of crun-wasm.
I created a simbolic link named crun-wasm:

sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm


Ouch! You're right. This worked when I enabled WasmEdge in crun, but
was changed upstream at some point since.

Apparently Fedora/RedHat ship a "crun-wasm" package, which contains a) this
symlink, b) a dependency on WasmEdge.

In Debian, the main "crun" package has a Suggests on libwasmedge0.

I see three paths forward:
1) We do the same, creating a new (almost) empty package.
2) We ship a /usr/bin/crun-wasm symlink in the crun package.
3) We patch podman to use /usr/bin/crun instead of, or in addition to,
/usr/bin/crun-wasm.

I don't particularly love option (1). I'm split between options (2) and
(3), not loving either.

Thoughts?

Faidon


--
Eugen Stan

+40770 941 271  / https://www.netdava.com



Bug#1069693: ppp >=2.5.0 breaks network-manager-fortisslvpn

2024-05-11 Thread James Cowgill
Control: tags -1 patch upstream

Hi,

On Sat, 11 May 2024 00:58:03 +0200 Maurizio Avogadro 
wrote:
> Some more info gathered this afternoon.
> 
> It seems that network-manager-fortisslvpn also makes a mess with the routing 
> table after the connection has been established.
> 
> I could easily get a working VPN by adding
> 
> ipcp-accept-remote
> 
> to /etc/ppp/options and manually launching openfortivpn; such setting also 
> allowed NetworkManager to accept the IP address supplied by the counterpart 
> (it 
> was the default until ppp v2.4.9), but in this case the connection didn't 
> work 
> until I deleted a rule in the routing table which routed the IP address of 
> the 
> remote gateway through the ppp0 interface (!).
> 
> A duplicate default route through the main physical network interface was 
> created too and the spawned pppd process didn't exit after the connection has 
> been terminated and had to be killed manually: none of these issues happened 
> when openfortivpn was launched manually.

I also did a little investigation yesterday on this as well as #1070343.
There are many upstream issues in both the openfortivpn GitHub and
network-manager Gitlab instances related to this.

To sum up what I think is happening (gathered from various issues):
* During PPP IPCP negotiation the Fortinet server requests it's link IP
address to be the same as it's public IP address. This doesn't make any
sense to me - the link address inside the PPP session should be a
private 10.x address. Maybe there's some reason it does this that I
don't understand...
* pppd configures this address on the ppp device using the
SIOCSIFDSTADDR ioctl. The kernel internally adds a route to the routing
table because it knows it can use this link to get to that IP (lol).
* Pre ppp-2.4 this didn't matter because pppd forcefully used the
address supplied on the command line which is a 169.x address. In this
case the kernel adds a route to a dummy IP which didn't affect anything.
* ppp-2.5 started enforcing the remote IP on the command line matched
the IP sent over IPCP. This initially broke negotiation until
"ipcp-accept-remote" was added, but this option breaks things in another
way by allowing pppd to configure the server supplied IP as the peer
address in the kernel and create a bad route.
* openfortivpn has a hack to workaround this - after pppd is up it
manually removes the route from the routing table. The network-manager
plugin doesn't do this.

I ended up writing a patch which does something similar in the
network-manager plugin - it manually invokes the SIOCSIFDSTADDR ioctl on
the ppp device to switch the peer address to a new fake address. This
seems to work to remove the bad route. Doing this feels really hacky
though and I'm kind of hesitant to upload it unless approved by upstream!

Note if you're testing this patch, you also need the fix for #1070343 in
openfortivpn as well to make it work (or manually set ipcp-accept-remote).

Having done this I'm very tempted to just switch to OpenConnect which
seems to work ok. It has its own ppp implementation which doesn't seem
to set the peer address in the kernel at all (and may just ignore the
server's IPCP requests - I have not checked) and so avoids these issues.

JamesFrom 416b65c3f23d795707ed122f06c54eebd515bc3b Mon Sep 17 00:00:00 2001
From: James Cowgill 
Date: Sat, 11 May 2024 13:59:17 +0100
Subject: [PATCH] Modify PPP peer address to avoid wrong route

---
 src/nm-fortisslvpn-service.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/src/nm-fortisslvpn-service.c b/src/nm-fortisslvpn-service.c
index e4433d5..cdfada4 100644
--- a/src/nm-fortisslvpn-service.c
+++ b/src/nm-fortisslvpn-service.c
@@ -37,6 +37,11 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 
 #include "nm-fortissl-properties.h"
@@ -313,14 +318,39 @@ handle_set_state (NMDBusFortisslvpnPpp *object,
 	return TRUE;
 }
 
+static void
+hack_ppp_peer(const char *tundev)
+{
+	struct ifreq req;
+	int fd, ret;
+
+	_LOGI ("FORTISSLVPN Modifying PPP peer address to avoid incorrect host route");
+
+	memset(, 0, sizeof(req));
+	strlcpy(req.ifr_name, tundev, sizeof(req.ifr_name));
+	req.ifr_dstaddr.sa_family = AF_INET;
+	inet_aton("169.254.0.1", &((struct sockaddr_in*)(_dstaddr))->sin_addr);
+
+	fd = socket(AF_INET, SOCK_STREAM, 0);
+	ret = ioctl(fd, SIOCSIFDSTADDR, );
+	if (ret)
+		_LOGW ("FORTISSLVPN Failed to set PPP peer address, errno = %d", errno);
+	close(fd);
+}
+
 static gboolean
 handle_set_ip4_config (NMDBusFortisslvpnPpp *object,
GDBusMethodInvocation *invocation,
GVariant *arg_config,
gpointer user_data)
 {
+	const char *tundev;
+
 	_LOGI ("FORTISSLVPN service (IP Config Get) reply received.");
 
+	if (g_variant_lookup(arg_config, NM_VPN_PLUGIN_CONFIG_TUNDEV, "", ))
+		hack_ppp_peer(tundev);
+
 	nm_vpn_service_plugin_set_ip4_config (NM_VPN_SERVICE_PLUGIN (user_data), 

Bug#1023047:

2024-05-11 Thread erebion

Oh, and looking at logs, kernel says:

kernel: traps: wsjtx[110457] general protection fault ip:7fa7cc1071ee 
sp:7ffe8c52a530 error:0 in libQt5Gui.so.5.15.10[7fa7cc0e2000+4ef000]


erebion

--
erebion

Matrix: @erebion:erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the aforementioned 
languages.



OpenPGP_0x8EAF40326E02AE7D.asc
Description: OpenPGP public key
BEGIN:VCARD
VERSION:4.0
N:;erebion;;;
FN:erebion
EMAIL;PREF=1:ereb...@erebion.eu
IMPP:matrix:u/erebion:erebion.eu
URL:https://erebion.eu
TZ:Europe/Berlin
END:VCARD


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1023047: (no subject)

2024-05-11 Thread erebion

Hello,

I just have had another look and I had noticed that selecting "default" 
for audio input leads to a segfault:


And this is what I got when I selected an ALSA input:

ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dsnoop.c:578:(snd_pcm_dsnoop_open) unable to initialize slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dsnoop.c:578:(snd_pcm_dsnoop_open) unable to initialize slave
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
[1]    106253 segmentation fault  wsjtx

This is what I got when I selected "pulse" for the input:

ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dsnoop.c:578:(snd_pcm_dsnoop_open) unable to initialize slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dsnoop.c:578:(snd_pcm_dsnoop_open) unable to initialize slave
[1]    106631 segmentation fault  wsjtx

I know it says ALSA, but I really did select pulse!

I've also noticed that the input meter in wsjtx briefly shoots up to max 
before it crashes. At least that might be an indication that it gets 
audio before crashing, idk.


I then loaded two kernel modules to try out whether they were missing:

sudo modprobe snd-pcm-oss
sudo modprobe snd-mixer-oss

And then /dev/dsp appeared, but wsjtx still crashed with a segfault 
without any error messages. I am in the audio group and can access the 
device file just fine with other software.


I even got the same error when I selected "pipewire" for the input:

ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dsnoop.c:578:(snd_pcm_dsnoop_open) unable to initialize slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dsnoop.c:578:(snd_pcm_dsnoop_open) unable to initialize slave
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dsnoop.c:578:(snd_pcm_dsnoop_open) unable to initialize slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dsnoop.c:578:(snd_pcm_dsnoop_open) unable to initialize slave
[1]    108774 segmentation fault  wsjtx
wsjtx  5,03s user 1,21s system 10% cpu 1:02,24 total

This makes me believe that wsjtx always tries to access ALSA stuff when 
it should be using something else OR that the error message is simply wrong.


Please not that it does not matter what I select for output, it will not 
crash. I will just not get output on some settings, even though I should.


However, I got the following when I had selected "pipewire" as output 
and manually removed the input from the config (as it crashes otherwise 
and GUI does not allow not having an input), there's nothing set to 
ALSA, but it still has ALSA errors:


ALSA lib pcm.c:8740:(snd_pcm_recover) underrun occurred
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dmix.c:1012:(snd_pcm_dmix_open) unable to initialize slave
ALSA lib pcm_direct.c:1337:(snd1_pcm_direct_initialize_slave) unable to 
install hw params

ALSA lib pcm_dmix.c:1012:(snd_pcm_dmix_open) unable to initialize slave

So... There seems to be audio output now with "pipewire" or "default" 

Bug#1069964: debian-installer: Debian LXQt ISO loads all unnecessary proprietary firmware even with firmware=never parameter

2024-05-11 Thread baptx
Hello, on https://forums.debian.net/viewtopic.php?p=798356#p798356, it was
mentioned that we should use the parameter live-installer/enable=false on a
Debian Live ISO in order to recognize the firmware=never parameter.
Ideally, if the parameter firmware=never is not recognized, it should
include the parameter live-installer/enable=false or the installation
should ask the user if they want proprietary firmware.
On https://forums.debian.net/viewtopic.php?p=799106#p799106, it was
confirmed that free firmware is also skipped when using the firmware=never
parameter.
It would be useful to have a parameter like firmware=free to include only
free firmware or make firmware=never include free firmware.
Let me know if I should create a new bug report or if it can be handled in
this report also.


On Sat, 27 Apr 2024 at 22:36, Cyril Brulebois  wrote:

> Hi,
>
> Thanks for the report but wow, that's way too many topics.
>
> baptx  (2024-04-27):
> > The following issue is based on the discussion I created on
> > https://forums.debian.net/viewtopic.php?t=159027 where you can find
> > attached the content of /var/log/installer/syslog which was generated
> > on a virtual machine with virt-manager when installing
> > debian-live-12.5.0-amd64-lxqt.iso with the firmware=never parameter
> > (the problem was also present on my real computer when I tested with a
> > previous version debian-live-12.0.0-amd64-lxqt.iso). I also attached
> > the result of the vrms command after using firmware=never parameter.
>
> vrms is irrelevant.
>
> > To compare, you can also find attached another installer syslog
> > without using firmware=never parameter, which also contains the line
> > "hw-detect: skipping check-missing-firmware as requested by the
> > caller" and looks like a bug.
>
> No, it's not. See check on CHECK_MISSING_FIRMWARE in hw-detect.
>
> > The firmware=never parameter did not work at all when using the LXQt
> > ISO file (maybe the problem also happens on ISO files with other
> > desktop environments), the non-free firmware packages were installed.
>
> That would be a bug in debian-live then, not in debian-installer. Cc-ing
> accordingly.
>
> > And with the LXQt ISO file, the graphical expert install as well as
> > the text expert install did not ask me if I want the non-free firmware
> > packages, they were installed automatically.
>
> > I noticed the firmware=never parameter only worked with the netinst
> > ISO file.
>
> Well, that's been added for use by debian-installer. What debian-live
> does or doesn't do with it is outside our control.
>
> > For the automatic detection of needed non-free firmware packages, it
> > only worked with the netinst ISO file as well (the LXQt ISO file
> > installed all non-free firmware packages). But even with netinst ISO
> > file, it seems it is only guessing the non-free firmware packages
> > needed since several were not needed to make my laptop work correctly
> > (firmware-realtek, firmware-sof-signed) when installed on my real
> > computer instead of a virtual machine.
>
> The lookup is based on what devices are seen during the installation
> process. If the relevant kernel modules list firmware files, we try to
> match them to firmware packages, and queue their installation. Unless
> firmware=never was used of course. That doesn't mean they are absolutely
> required for those devices to work. There is just no way to know for
> sure.
>
> > It would also be useful to have the firmware=never parameter added in
> > a menu in the normal graphical installation (for people who don't want
> > the complexity of the expert installation), since it is more
> > convenient to have it in a menu and also avoids mistakes when typing
> > firmware=never (I accidentally typed firmzare due to my AZERTY
> > keyboard and the QWERTY input).
>
> Menu maintenance (esp. across architectures, BIOS vs. UEFI, etc.) is a
> huge mess already, it might happen but I'm not holding my breath here.
>
> > It would be a good idea to warn the user if the entered parameter /
> > value does not exist, to avoid unwanted results like installing
> > non-free firmware.
>
> There's no absolute list to check against, so that cannot be done.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>


Bug#1070907: python-stdnum: please drop the suggests on SimpleSoap

2024-05-11 Thread Arthur de Jong
On Sat, 2024-05-11 at 14:26 +0200, Alexandre Detiste wrote:
> Please drop the suggests on python3-pysimplesoap;
> this package would soon be dropped from Debian
> altogheter.

The next upload will drop the suggest (which already was a fallback for
zeep).

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



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


Bug#1070909: llvm-toolchain-18: FTBFS on riscv64: dh_install: warning: llvm-18-linker-tools missing files: usr/lib/llvm-18/lib/LLVMgold.so

2024-05-11 Thread Sebastian Ramacher
Source: llvm-toolchain-18
Version: 1:18.1.5-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

riscv64 is now a release architecture and llvm-toolchain-18 built
previously.

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-18=riscv64=1%3A18.1.5-2=1715249422=0

   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install -p libpolly-18-dev usr/lib/llvm-18/lib/cmake/polly/*.cmake 
usr/lib/llvm-18/lib/cmake/polly
rm -rf debian/tmp/usr/lib/llvm-18/lib/cmake/polly/*.cmake
dh_install --fail-missing 
dh_install: warning: Please use dh_missing --list-missing/--fail-missing instead
dh_install: warning: This feature will be removed in compat 12.
dh_install: warning: Cannot find (any matches for) 
"usr/lib/llvm-18/lib/LLVMgold.so" (tried in ., debian/tmp)

dh_install: warning: llvm-18-linker-tools missing files: 
usr/lib/llvm-18/lib/LLVMgold.so
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:1432: override_dh_install] Error 255

Cheers
-- 
Sebastian Ramacher



Bug#1070910: llvm-toolchain-18: autopkgtest fails on amd64

2024-05-11 Thread Sebastian Ramacher
Source: llvm-toolchain-18
Version: 1:18.1.5-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://ci.debian.net/packages/l/llvm-toolchain-18/testing/amd64/46304375/#S6

150s # Builds the test application
150s clang++-$VERSION -std=c++20 \
150s-nostdinc++ \
150s-isystem /usr/lib/llvm-$VERSION/include/c++/v1/ \
150s-L /usr/lib/llvm-$VERSION/lib \
150s-fmodule-file=std=std.pcm \
150s-fmodule-file=std.compat=std.compat.pcm \
150sstd.pcm \
150sstd.compat.pcm \
150s-lc++ \
150sfoo.cpp
151s 
151s # Runs the test application
151s # The output should be
151s #   Hello modular world
151s #   Hello compat modular world
151s ./a.out
151s Hello modular world
151s Hello compat modular world
151s 
151s if test ! -f /usr/lib/llvm-$VERSION/include/cxxabi.h; then
151s echo "Install libc++abi-$VERSION-dev";
151s exit -1;
151s fi
151s 
151s # Force the usage of libc++abi
151s clang++-$VERSION -stdlib=libc++ -lc++abi foo.cpp -o o
151s foo.cpp:1:1: error: unknown type name 'import'
151s 1 | import std;
151s   | ^
151s foo.cpp:2:1: error: unknown type name 'import'
151s 2 | import std.compat;
151s   | ^
151s foo.cpp:2:11: error: expected ';' after top level declarator
151s 2 | import std.compat;
151s   |   ^
151s   |   ;
151s foo.cpp:5:3: error: 'std' is not a class, namespace, or enumeration
151s 5 |   std::cout << "Hello modular world\n";
151s   |   ^
151s foo.cpp:2:8: note: 'std' declared here
151s 2 | import std.compat;
151s   |^
151s foo.cpp:6:5: error: no 
member named 'printf' in the global namespace
151s 6 |   ::printf("Hello compat modular world\n");
151s   |   ~~^
151s 5 errors generated.
151s autopkgtest [23:36:28]: test command1: ---]

Cheers

-- 
Sebastian Ramacher



Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)

2024-05-11 Thread Lorenzo
Control: tags -1 -moreinfo

Hi,

On Sat, 11 May 2024 10:24:31 +0200
Tobias Frost  wrote:

> On Tue, Apr 16, 2024 at 09:39:58AM +0200, Lorenzo wrote:
> > Control: block -1 by 1067525
> > 
> > this fix need to go to unstable because elogind 255.4.1 is already
> > there, but runit-services depends on runit > 2.1.2-56 (unstable is
> > at 2.1.2-54) so 1067525 needs to be uploaded first or together with
> > this one, otherwise runit-services is not installable
> 
> Ok, just saw that one.
> Please note that this fact must be stated in d/changelog, something
> like "Upload to unstable."
> 

I've update the changelog mentioning the upload to unstable.

updated links:

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

dget -x
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.2.dsc

git repo:
https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads

Thanks,
Lorenzo



Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

2024-05-11 Thread Lorenzo
Hi,

On Sat, 11 May 2024 10:52:33 +0200
Martin Steigerwald  wrote:

[...]
> 
> In case it is helpful for you I could post a step to step guide for a 
> minimal Incus setup and/or at least some pointers.

yes this would be useful

> 
> > > > > I just wonder why stage 2 contains /usr/local bin
> > > > > directories. I think that should not be the case. Shall I
> > > > > report this as a different issue?
> > > > 

[...]

> I do think this discussion belongs into a different bug report
> though. I am willing to open a low priority report about this and
> include the previous relevant discussion to it, so it does not get
> lost and you can take your time to ponder about it. There is no need
> to rush it.

fine for me, feel free to proceed

> 
> Have a great weekend!

Thanks :)
Lorenzo



Bug#1070410: golang-github-pion-webrtc.v3 accesses the internet during build

2024-05-11 Thread Nilesh Patra
On Sat, May 11, 2024 at 02:18:40PM +0200, Santiago Vila wrote:
> Hi.
> 
> Have you tried tcpdump while the tests are running?
> 
> I see a DNS query for stun.l.google.com, which is also
> somewhere in the code.

That is only for peer connection tests. A bunch of other tests should not fail
imho.

> I believe DNS queries count
> as "internet access" and are not allowed.

Uhm, fine. For now I will disable the testsuite and upload, don't have more time
to investigate. Thanks for helping me out.

> 
> Thanks.
Best,
Nilesh


signature.asc
Description: PGP signature


Bug#1070908: RM: pysimplesoap - dead upstream, better alternative: zeep

2024-05-11 Thread Alexandre Detiste
Source: pysimplesoap
Version: 1.16.2-7
Severity: normal
X-Debbugs-Cc: Arthur de Jong , Bastian Germann 
, Bastian Venthur 

Dear Maintainers,

pysimplesoap should be removed after it's last
reverse dependencies have been taken care of.

https://venthur.de/2024-05-08-new-python-debianbts-in-experimental.html

It is now in half-orphaned state;
if that bothers someone I can adopt it.

python3-pysimplesoap
Reverse Depends:
  Depends: python3-debianbts (>= 1.16.2-5) -> ok in experimental
  Depends: r4d -> looks easy to patch
  Suggests: python3-stdnum -> #1070907 but will first try zeep



Bug#1070907: python-stdnum: please drop the suggests on SimpleSoap

2024-05-11 Thread Alexandre Detiste
Source: python-stdnum
Version: 1.20-1
Severity: normal

Dear Maintainer,

Please drop the suggests on python3-pysimplesoap;
this package would soon be dropped from Debian
altogheter.

(upstream does not need any change)

I pinged r4d too.

Greetings


https://venthur.de/2024-05-08-new-python-debianbts-in-experimental.html

  # The SOAP feature is only required for a number of online tests
  # of numbers such as the EU VAT VIES lookup, the Dominican Republic
  # DGII services or the Turkish T.C. Kimlik validation.
  'SOAP': ['zeep'],  # recommended implementation
  'SOAP-ALT': ['suds'],  # but this should also work
  'SOAP-FALLBACK': ['PySimpleSOAP'],  # this is a fallback

root@quieter:~# apt rdepends python3-pysimplesoap 
python3-pysimplesoap
Reverse Depends:
  Dépend: python3-debianbts (>= 1.16.2-5)
  Dépend: r4d
  Suggère: python3-stdnum


Bug#1070839: r-cran-data.table: autopkgtest regression on i386

2024-05-11 Thread Andreas Tille
Control: tags -1 upstream
Control: forwarded -1 https://github.com/Rdatatable/data.table/issues/6133



Bug#1070410: golang-github-pion-webrtc.v3 accesses the internet during build

2024-05-11 Thread Santiago Vila

Hi.

Have you tried tcpdump while the tests are running?

I see a DNS query for stun.l.google.com, which is also
somewhere in the code. I believe DNS queries count
as "internet access" and are not allowed.

Thanks.



Bug#1070906: ecryptfs-utils: mount fails with "No such file or directory" after user switch with sudo -i -u ...

2024-05-11 Thread Tobias Rupf
Package: ecryptfs-utils
Version: 111-6
Severity: normal
Tags: patch

Dear Maintainer,

ecrypts-mount-private is failing when starting a user session via sudo (and
probably other methods where no password is required for login, e.g. ssh with
keyfile)

Error message is: "mount: No such file or directory" and home directory is not
mounted.

Reason is that the user keyring is not linked to the session keyring.
see also here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870126#15

Easy fix is to add a file into /etc/profile.d which does this linking, a one-
liner in it is sufficient:
keyctl link @u @s

After this small change ecryptfs-mount-private is working as intended.

This shouldn't raise any safety concerns as all is done with normal user
permissions, the same is done by su (resp. pam) automatically. If the user
keyring is already linked this additional command will do nothing and doesn't
do any harm.

So please include a file in the package which does this fix.


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

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

Versions of packages ecryptfs-utils depends on:
ii  gettext-base0.21-12
ii  keyutils1.6.3-2
ii  libc6   2.36-9+deb12u4
ii  libecryptfs1111-6
ii  libgpgme11  1.18.0-3+b1
ii  libkeyutils11.6.3-2
ii  libpam-runtime  1.5.2-6+deb12u1
ii  libpam0g1.5.2-6+deb12u1
ii  libtspi10.3.15-0.3

ecryptfs-utils recommends no packages.

Versions of packages ecryptfs-utils suggests:
ii  cryptsetup  2:2.6.1-4~deb12u2
ii  rsync   3.2.7-1

-- no debconf information



Bug#1070905: collectd: Please use pkg-config instead of libgcrypt-config to locate libgcrypt

2024-05-11 Thread Andreas Metzler
Source: collectd
Version: 5.12.0-18
Severity: normal
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Please switch from using libgcrypt-config to pkg-config to locate
libgcrypt. libgcrypt-config will be dropped in the next libgcrypt major
release.

(Please do not switch from collectd's handwritten detection code to
AM_PATH_LIBGCRYPT() unless you invoke AM_PATH_GPG_ERROR() first. The
former rcurrently requires the latter to work without libgcrypt-config.
Just go for pkg-config instead.)

cu Andreas


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

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.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
-- 
`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#1070888: PLEASE IGNORE

2024-05-11 Thread Rene Engelhard

Hi,

Am 11.05.24 um 13:45 schrieb Emmanuel Charpentier:
In fact, both submission worked, but the second is but a duplicate of 
the first.


My apologies for the noise...


No problem, I already merged them. :)

 (Intestestingly 1070888 only made it to the BTS and not to the mailing 
list where 1070887 
 did...)



Regards,


Rene



Bug#1070904: bitlbee: Please use pkg-config instead of libgcrypt-config to locate libgcrypt

2024-05-11 Thread Andreas Metzler
Package: bitlbee
Version: 3.6-1.4
Severity: normal
Tags: patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

Please switch from using libgcrypt-config to pkg-config to locate
libgcrypt. libgcrypt-config will be dropped in the next libgcrypt major
release.

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'
diff -Nru bitlbee-3.6/debian/changelog bitlbee-3.6/debian/changelog
--- bitlbee-3.6/debian/changelog	2024-03-23 22:05:25.0 +0100
+++ bitlbee-3.6/debian/changelog	2024-05-11 13:42:43.0 +0200
@@ -1,3 +1,11 @@
+bitlbee (3.6-1.5) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use pkgconf to locate libgcrypt, libgcrypt-config is scheduled for
+removal.
+
+ -- Andreas Metzler   Sat, 11 May 2024 13:42:43 +0200
+
 bitlbee (3.6-1.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru bitlbee-3.6/debian/patches/bitlbee_locate_gcrypt_with_pkg-config.diff bitlbee-3.6/debian/patches/bitlbee_locate_gcrypt_with_pkg-config.diff
--- bitlbee-3.6/debian/patches/bitlbee_locate_gcrypt_with_pkg-config.diff	1970-01-01 01:00:00.0 +0100
+++ bitlbee-3.6/debian/patches/bitlbee_locate_gcrypt_with_pkg-config.diff	2024-05-11 13:42:43.0 +0200
@@ -0,0 +1,38 @@
+Description: Use pkgconf to locate libgcrypt.
+ libgcrypt-config is scheduled for removal.
+Author: Andreas Metzler 
+Last-Update: 2024-05-11
+
+--- bitlbee-3.6.orig/configure
 bitlbee-3.6/configure
+@@ -402,8 +402,8 @@ detect_gnutls()
+ {
+ 	if $PKG_CONFIG --exists gnutls; then
+ 		cat <>Makefile.settings
+-EFLAGS+=$($PKG_CONFIG --libs gnutls) $(libgcrypt-config --libs)
+-CFLAGS+=$($PKG_CONFIG --cflags gnutls) $(libgcrypt-config --cflags)
++EFLAGS+=$($PKG_CONFIG --libs gnutls) $($PKG_CONFIG --libs libgcrypt)
++CFLAGS+=$($PKG_CONFIG --cflags gnutls) $($PKG_CONFIG --cflags libgcrypt)
+ EOF
+ 		ssl=gnutls
+ 		if ! $PKG_CONFIG gnutls --atleast-version=2.8; then
+@@ -762,15 +762,15 @@ fi
+ if [ "$otr" = 1 ]; then
+ 	# BI == built-in
+ 	echo '#define OTR_BI' >> config.h
+-	echo "EFLAGS+=$($PKG_CONFIG --libs libotr) $(libgcrypt-config --libs)" >> Makefile.settings
+-	echo "CFLAGS+=$($PKG_CONFIG --cflags libotr) $(libgcrypt-config --cflags)" >> Makefile.settings
++	echo "EFLAGS+=$($PKG_CONFIG --libs libotr) $($PKG_CONFIG --libs libgcrypt)" >> Makefile.settings
++	echo "CFLAGS+=$($PKG_CONFIG --cflags libotr) $($PKG_CONFIG --cflags libgcrypt)" >> Makefile.settings
+ 	echo 'OTR_BI=otr.o' >> Makefile.settings
+ elif [ "$otr" = "plugin" ]; then
+ 	# for some mysterious reason beyond the comprehension of my mortal mind,
+ 	# the libgcrypt flags aren't needed when building as plugin. add them anyway.
+ 	echo '#define OTR_PI' >> config.h
+-	echo "OTRFLAGS=$($PKG_CONFIG --libs libotr) $(libgcrypt-config --libs)" >> Makefile.settings
+-	echo "CFLAGS+=$($PKG_CONFIG --cflags libotr) $(libgcrypt-config --cflags)" >> Makefile.settings
++	echo "OTRFLAGS=$($PKG_CONFIG --libs libotr) $($PKG_CONFIG --libs libgcrypt)" >> Makefile.settings
++	echo "CFLAGS+=$($PKG_CONFIG --cflags libotr) $($PKG_CONFIG --cflags libgcrypt)" >> Makefile.settings
+ 	echo 'OTR_PI=otr.so' >> Makefile.settings
+ fi
+ 
diff -Nru bitlbee-3.6/debian/patches/series bitlbee-3.6/debian/patches/series
--- bitlbee-3.6/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ bitlbee-3.6/debian/patches/series	2024-05-11 13:42:43.0 +0200
@@ -0,0 +1 @@
+bitlbee_locate_gcrypt_with_pkg-config.diff


Bug#1070888: PLEASE IGNORE

2024-05-11 Thread Emmanuel Charpentier
This bug is a *duplicate* of 
[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070887](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070887)
 : the `reportbug` output led me to believe had *not* been submitted (and the 
acknowledgement was late), so I restarted `reportbug` and configured it to 
resend my report explicitly via `evolution`.

In fact, both submission worked, but the second is but a duplicate of the first.

My apologies for the noise...

--
Rmmanuel Charpentier




Bug#1070903: axc: Please use pkg-config instead of libgcrypt-config to locate libgcrypt

2024-05-11 Thread Andreas Metzler
Source: axc
Version: 0.3.7-1
Severity: normal
Tags: patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Please switch from using libgcrypt-config to pkg-config to locate
libgcrypt. libgcrypt-config will be dropped in the next libgcrypt major
release.

cu Andreas

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

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.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
-- 
`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'
Description: Use pkg-config to locate gcrypt
 libgcrypt-config is scheduled for removal.
Author: Andreas Metzler 
Origin: vendor
Last-Update: 2024-05-11

--- axc-0.3.7.orig/Makefile
+++ axc-0.3.7/Makefile
@@ -24,8 +24,8 @@ SQLITE3_LDFLAGS ?= $(shell $(PKG_CONFIG)
 SIGNAL_CFLAGS ?= $(shell $(PKG_CONFIG) --cflags libsignal-protocol-c)
 SIGNAL_LDFLAGS ?= $(shell $(PKG_CONFIG) --libs libsignal-protocol-c)
 
-LIBGCRYPT_CONFIG ?= libgcrypt-config
-LIBGCRYPT_LDFLAGS ?= $(shell $(LIBGCRYPT_CONFIG) --libs)
+LIBGCRYPT_CFLAGS ?= $(shell $(PKG_CONFIG) --cflags libgcrypt)
+LIBGCRYPT_LDFLAGS ?= $(shell $(PKG_CONFIG) --libs libgcrypt)
 
 
 SDIR = src


Bug#1070410: golang-github-pion-webrtc.v3 accesses the internet during build

2024-05-11 Thread Nilesh Patra
Quoting Jochen Sprickerhof :
>  golang-github-pion-webrtc.v3 attempts network access during build.
>  This is forbidden by Policy 4.9:

Are you sure about this? I don't think so.

I built this in an offline environment w/o any internet access and it builds 
just
OK. Furthermore I compared the logs with the one in buildd and I did not see
anything unusual.

>For packages in the main archive, required targets must not attempt
>network access, except, via the loopback interface, to services on the
>build host that have been started by the build.
>  
>  This can be tested with the sbuild unshare backend:

I tried building this in an offline setting, didn't use unshare backend. Does
the latter do anything differently?
 
>  === NAME  TestDataChannelParamters_Go
>  util.go:41: Unexpected routines on test end:
>  goroutine 34 [select]:
>  
> github.com/pion/interceptor/pkg/nack.(*GeneratorInterceptor).loop(0xc240a0,
>  {0x9f4b80, 0xc3ec30})
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/nack/generator_interceptor.go:139
>  +0x12d
>  created by 
> github.com/pion/interceptor/pkg/nack.(*GeneratorInterceptor).BindRTCPWriter 
> in goroutine 16
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/nack/generator_interceptor.go:74
>  +0x115
>  
>  goroutine 35 [select]:
>  
> github.com/pion/interceptor/pkg/report.(*ReceiverInterceptor).loop(0xc0001303c0,
>  {0x9f4b80, 0xc3ec30})
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/report/receiver_interceptor.go:97
>  +0x19c
>  created by 
> github.com/pion/interceptor/pkg/report.(*ReceiverInterceptor).BindRTCPWriter 
> in goroutine 16
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/report/receiver_interceptor.go:86
>  +0x115
>  
>  goroutine 36 [select]:
>  
> github.com/pion/interceptor/pkg/report.(*SenderInterceptor).loop(0xc000130420,
>  {0x9f4b80, 0xc3ec30})
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/report/sender_interceptor.go:98
>  +0x19c
>  created by 
> github.com/pion/interceptor/pkg/report.(*SenderInterceptor).BindRTCPWriter in 
> goroutine 16
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/report/sender_interceptor.go:87
>  +0x115

I don't see any of these failures either. Please comment?

Best,
Nilesh


signature.asc
Description: PGP signature


Bug#1070897: netcdf: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

2024-05-11 Thread Sebastiaan Couwenberg

Control: tags -1 pending

On 5/11/24 12:31 PM, Santiago Vila wrote:

--- debian/libnetcdf19t64.symbols (libnetcdf19t64_4.9.2_amd64)
+++ dpkg-gensymbolsbQjlfm    2024-05-08 16:50:08.612637064 +
@@ -2099,7 +2099,7 @@
   showopenobjects@Base 4.6.2
   simplenodematch@Base 4.3.3
   simplepathstring@Base 4.3.3
- strlcat@Base 4.6.0
+#MISSING: 4.9.2# strlcat@Base 4.6.0
   unattach@Base 4.3.3
   unmap@Base 4.3.3
   value@Base 4.1.3


glibc now provides this, mapserver also doesn't needs its own 
implementation any more (#1067651).


Kind Regards,

Bas

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



Bug#1070901: binary blob is a red herring

2024-05-11 Thread Manny
control: retitle 1070901 POP3 authentication failure and “error:0A00010B:SSL 
routines::wrong version number” (2 bugs)

After submitting this bug report, I picked up on the nuance
“=> Send SSL data”, which differs from “=> Send header”.

So whatever is happening with that SSL data may be unrelated to why
authentication is denied. We still likely have a bug but it’s
non-trivial to see what the issue is.



  1   2   >