Bug#1073255: Package name for gpgme QT5/QT6 devel packages
Hello Patrick, I am currently in the process of packaging gpgme 1.23.2. The packaging will feature * Split off QT bindings from generic libgpgmepp-dev. * Also package QT6 bindings. I am not quite sure about the package names though, we will have libqgpgme15t64 (QT5 bindings) and libqgpgmeqt6-15 (QT6) as runtime packages. I currently have used libqgpgme-dev (QT5) (by simply following Rene's draft in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863149#15 and libqgpgmeqt6-dev, which seems odd. How about libqgpgmeqt5-dev/libqgpgmeqt6-dev? Is there some kind of (informal) policy I should follow or a better addess to ask? TIA, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1077842: smifb2-dkms: module fails to build for Linux 6.10: error: implicit declaration of function 'vmalloc'
Package: smifb2-dkms Version: 2.3.0.9.g20b8ef5-1 Severity: important Tags: upstream smifb2-dkms fails to build a module for Linux 6.10 in experimental: /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_drv.c: In function 'smi_vram_suspend': /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_drv.c:234:27: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration] 234 | sdev->vram_save = vmalloc(vram_size << 20); | ^~~ | kvmalloc /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_drv.c:234:25: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 234 | sdev->vram_save = vmalloc(vram_size << 20); | ^ /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_drv.c:244:17: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration] 244 | vfree(sdev->vram_save); | ^ | kvfree /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c: In function 'smi_driver_load': /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c:399:25: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration] 399 | cdev->regsave = vmalloc(1024); | ^~~ | kvmalloc /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c:399:23: warning: assignment to 'struct smi_750_register *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 399 | cdev->regsave = vmalloc(1024); | ^ /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c: In function 'smi_driver_unload': /var/lib/dkms/smifb2/2.2.3.4.g1828e79/build/smi_main.c:447:9: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration] 447 | vfree(cdev->regsave); | ^ | kvfree Andreas
Bug#1077840: falcosecurity-scap-dkms: module fails to build for Linux 6.10: error: implicit declaration of function 'fd_is_open'
Package: falcosecurity-scap-dkms
Version: 0.15.1-4
Severity: important
Tags: upstream
falcosecurity-scap-dkms fails to build a module for Linux 6.10 in experimental:
DKMS make.log for scap-0.15.1 for kernel 6.10-amd64 (x86_64)
Sat Aug 3 06:54:49 UTC 2024
make: Entering directory '/usr/src/linux-headers-6.10-amd64'
[configure-kmod] Including
/var/lib/dkms/scap/0.15.1/build//configure/DEVNODE_ARG1_CONST/Makefile.inc
/var/lib/dkms/scap/0.15.1/build//configure/CLASS_CREATE_1/Makefile.inc
/var/lib/dkms/scap/0.15.1/build//configure/ACCESS_OK_2/Makefile.inc
[configure-kmod] Setting HAS_DEVNODE_ARG1_CONST flag
[configure-kmod] Setting HAS_CLASS_CREATE_1 flag
[configure-kmod] Setting HAS_ACCESS_OK_2 flag
CC [M] /var/lib/dkms/scap/0.15.1/build/main.o
CC [M] /var/lib/dkms/scap/0.15.1/build/dynamic_params_table.o
CC [M] /var/lib/dkms/scap/0.15.1/build/fillers_table.o
CC [M] /var/lib/dkms/scap/0.15.1/build/flags_table.o
CC [M] /var/lib/dkms/scap/0.15.1/build/ppm_events.o
CC [M] /var/lib/dkms/scap/0.15.1/build/ppm_fillers.o
CC [M] /var/lib/dkms/scap/0.15.1/build/event_table.o
CC [M] /var/lib/dkms/scap/0.15.1/build/syscall_table64.o
CC [M] /var/lib/dkms/scap/0.15.1/build/ppm_cputime.o
CC [M] /var/lib/dkms/scap/0.15.1/build/ppm_tp.o
CC [M] /var/lib/dkms/scap/0.15.1/build/syscall_ia32_64_map.o
/var/lib/dkms/scap/0.15.1/build/ppm_cputime.c:353:10: warning: no previous
prototype for 'nsec_to_clock_t' [-Wmissing-prototypes]
353 | uint64_t nsec_to_clock_t(uint64_t x)
| ^~~
/var/lib/dkms/scap/0.15.1/build/main.c: In function 'drop_nostate_event':
/var/lib/dkms/scap/0.15.1/build/main.c:1653:22: error: implicit declaration of
function 'fd_is_open'; did you mean 'finish_open'?
[-Werror=implicit-function-declaration]
1653 | !fd_is_open(close_fd, fdt)
| ^~
| finish_open
/var/lib/dkms/scap/0.15.1/build/main.c: At top level:
/var/lib/dkms/scap/0.15.1/build/main.c:2829:5: warning: no previous prototype
for 'scap_init' [-Wmissing-prototypes]
2829 | int scap_init(void)
| ^
/var/lib/dkms/scap/0.15.1/build/main.c:2992:6: warning: no previous prototype
for 'scap_exit' [-Wmissing-prototypes]
2992 | void scap_exit(void)
| ^
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:509:14: warning: no previous
prototype for 'ppm_get_mm_exe_file' [-Wmissing-prototypes]
509 | struct file *ppm_get_mm_exe_file(struct mm_struct *mm)
| ^~~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:550:15: warning: no previous
prototype for 'ppm_get_mm_counter' [-Wmissing-prototypes]
550 | unsigned long ppm_get_mm_counter(struct mm_struct *mm, int member)
| ^~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:728:5: warning: no previous
prototype for 'accumulate_argv_or_env' [-Wmissing-prototypes]
728 | int accumulate_argv_or_env(const char __user * __user *argv,
| ^~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:874:6: warning: no previous
prototype for 'ppm_is_upper_layer' [-Wmissing-prototypes]
874 | bool ppm_is_upper_layer(struct file *exe_file){
| ^~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:2269:5: warning: no previous
prototype for 'f_sys_send_e_common' [-Wmissing-prototypes]
2269 | int f_sys_send_e_common(struct event_filler_arguments *args, int *fd)
| ^~~
/var/lib/dkms/scap/0.15.1/build/ppm_fillers.c:2405:5: warning: no previous
prototype for 'f_sys_recv_x_common' [-Wmissing-prototypes]
2405 | int f_sys_recv_x_common(struct event_filler_arguments *args, int64_t
*retval)
| ^~~
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249:
/var/lib/dkms/scap/0.15.1/build/main.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [/usr/src/linux-headers-6.10-common/Makefile:1959:
/var/lib/dkms/scap/0.15.1/build] Error 2
make: *** [/usr/src/linux-headers-6.10-common/Makefile:252: __sub-make] Error 2
make: Leaving directory '/usr/src/linux-headers-6.10-amd64'
Andreas
Bug#1077839: rtpengine-kernel-dkms: module fails to build for Linux 6.10: error: too few arguments to function 'ip_route_output'
Package: rtpengine-kernel-dkms Version: 11.5.1.25-1 Severity: important Tags: upstream rtpengine-kernel-dkms fails to build a module for Linux 6.10 in experimental: DKMS make.log for rtpengine-11.5.1.25 for kernel 6.10-amd64 (x86_64) Sat Aug 3 06:54:45 UTC 2024 make: Entering directory '/usr/src/linux-headers-6.10-amd64' CC [M] /var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.o /var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.c: In function 'send_proxy_packet4': /var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.c:4023:14: error: too few arguments to function 'ip_route_output' 4023 | rt = ip_route_output(net, dst->u.ipv4, src->u.ipv4, tos, 0); | ^~~ In file included from /usr/src/linux-headers-6.10-common/include/net/ip.h:30, from /usr/src/linux-headers-6.10-common/include/net/ip6_checksum.h:27, from /var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.c:5: /usr/src/linux-headers-6.10-common/include/net/route.h:157:30: note: declared here 157 | static inline struct rtable *ip_route_output(struct net *net, __be32 daddr, | ^~~ make[2]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: /var/lib/dkms/rtpengine/11.5.1.25/build/xt_RTPENGINE.o] Error 1 make[1]: *** [/usr/src/linux-headers-6.10-common/Makefile:1959: /var/lib/dkms/rtpengine/11.5.1.25/build] Error 2 make: *** [/usr/src/linux-headers-6.10-common/Makefile:252: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-6.10-amd64' Andreas
Bug#1077838: openvpn-dco-dkms: module fails to build for Linux 6.10: error: expected declaration specifiers or '...' before string constant
Package: openvpn-dco-dkms Version: 0.0+git20231103-1 Severity: important Tags: upstream sid trixie openvpn-dco-dkms fails to build a module for Linux 6.10 in experimental: DKMS make.log for ovpn-dco-0.0+git20231103 for kernel 6.10-amd64 (x86_64) Sat Aug 3 06:54:37 UTC 2024 /var/lib/dkms/ovpn-dco/0.0+git20231103/build/gen-compat-autoconf.sh /var/lib/dkms/ovpn-dco/0.0+git20231103/build/compat-autoconf.h make -C /lib/modules/6.10-amd64/build M=/var/lib/dkms/ovpn-dco/0.0+git20231103/build PWD=/var/lib/dkms/ovpn-dco/0.0+git20231103/build REVISION=0.0+git20231103 CONFIG_OVPN_DCO_V2=m INSTALL_MOD_DIR=updates/modules make[1]: Entering directory '/usr/src/linux-headers-6.10-amd64' CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/main.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/bind.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/crypto.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/ovpn.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/peer.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/sock.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/stats.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/netlink.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/crypto_aead.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/pktid.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/tcp.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/udp.o In file included from /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/crypto.h:16, from /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/addr.h:13, from /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/peer.h:13, from /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/ovpn.h:14, from /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/main.c:12: /var/lib/dkms/ovpn-dco/0.0+git20231103/build/include/uapi/linux/ovpn_dco.h:14:22: error: expected declaration specifiers or '...' before string constant 14 | #define OVPN_NL_NAME "ovpn-dco-v2" | ^ /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/main.c:263:26: note: in expansion of macro 'OVPN_NL_NAME' 263 | MODULE_ALIAS_GENL_FAMILY(OVPN_NL_NAME); | ^~~~ make[4]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco/main.o] Error 1 make[4]: *** Waiting for unfinished jobs make[3]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:490: /var/lib/dkms/ovpn-dco/0.0+git20231103/build/drivers/net/ovpn-dco] Error 2 make[2]: *** [/usr/src/linux-headers-6.10-common/Makefile:1959: /var/lib/dkms/ovpn-dco/0.0+git20231103/build] Error 2 make[1]: *** [/usr/src/linux-headers-6.10-common/Makefile:252: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.10-amd64' make: *** [Makefile:59: all] Error 2 Andreas
Bug#1077837: openafs-modules-dkms: module fails to build for Linux 6.10: error: 'vmalloc' undeclared
Package: openafs-modules-dkms Version: 1.8.12~pre1-1 Severity: important Tags: upstream fixed-upstream Control: forwarded -1 http://git.openafs.org/?p=openafs.git;a=commit;h=658942f2791fad5e33ec7542158c16dfc66eed39 openafs-modules-dkms fails to build a module for Linux 6.10 in experimental: CC [M] /var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.o /var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.c: In function 'linux_alloc_init': /var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.c:212:37: error: 'vmalloc' undeclared (first use in this function); did you mean 'mm_alloc'? 212 | (void *)vmalloc, local_free); | ^~~ | mm_alloc /var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.c:212:37: note: each undeclared identifier is reported only once for each function it appears in make[5]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: /var/lib/dkms/openafs/1.8.12pre1/build/src/libafs/MODLOAD-6.10-amd64-SP/osi_alloc.o] Error 1 Andreas
Bug#1077835: zfs-dkms: module fails to build for Linux 6.10
Package: zfs-dkms Version: 2.2.4-2 Severity: important Tags: upstream zfs-dkms fails to build a module for Linux 6.10 in experimental: *** ZFS Version: zfs-2.2.4-2 *** Compatible Kernels: 3.10 - 6.8 Andreas
Bug#1077834: dm-writeboost-dkms: module fails to build for Linux 6.10: error: 'struct block_device' has no member named 'bd_inode'
Package: dm-writeboost-dkms Version: 2.2.17-0.2 Severity: important Tags: upstream sid trixie Control: forwarded -1 https://github.com/akiradeveloper/dm-writeboost/issues/256 # CC [M] /var/lib/dkms/dm-writeboost/2.2.17/build/dm-writeboost-target.o x86_64-linux-gnu-gcc-13 -Wp,-MMD,/var/lib/dkms/dm-writeboost/2.2.17/build/.dm-writeboost-target.o.d -nostdinc -I/usr/src/linux-headers-6.10-common/arch/x86/include -I./arch/x86/include/generated -I/usr/src/linux-headers-6.10-common/include -I./include -I/ usr/src/linux-headers-6.10-common/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/usr/src/linux-headers-6.10-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-6.10-common/include/linux/compiler-version.h -include /us r/src/linux-headers-6.10-common/include/linux/kconfig.h -include /usr/src/linux-headers-6.10-common/include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-6.10-common/= -std=gnu11 -fshort-wchar -funsigned-char -fno-common -fno- PIE -fno-strict-aliasing -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=branch -fno-jump-tables -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mc model=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all -fpatchable-function-entry=16,16 -fno-delete -null-pointer-checks -O2 -fno-allow-store-data-races -fstack-protector-strong -ftrivial-auto-var-init=zero -fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -falign-functions=16 -fstrict-flex-arrays=3 -fno-strict-overflow -fno-stack- check -fconserve-stack -Wall -Wundef -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Werror=strict-prototypes -Wno-format-security -Wno-trigraphs -Wno-frame-address -Wno-address-of-packed-member -Wmissing-declarations -Wmissin g-prototypes -Wframe-larger-than=2048 -Wno-main -Wno-dangling-pointer -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-overflow -Wno-array-bounds -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -Werror=date-time -Werror=incompatible-pointer-ty pes -Werror=designated-init -Wenum-conversion -Wextra -Wunused -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-packed-not-aligned -Wno-format-overflow -Wno-format-truncation -Wno-stringop-truncation -Wno-override-init -Wno-missing-field-initiali zers -Wno-type-limits -Wno-shift-negative-value -Wno-maybe-uninitialized -Wno-sign-compare -Wno-unused-parameter -g -DMODULE -DKBUILD_BASENAME='"dm_writeboost_target"' -DKBUILD_MODNAME='"dm_writeboost"' -D__KBUILD_MODNAME=kmod_dm_writeboost -c -o /var/lib/ dkms/dm-writeboost/2.2.17/build/dm-writeboost-target.o /var/lib/dkms/dm-writeboost/2.2.17/build/dm-writeboost-target.c /var/lib/dkms/dm-writeboost/2.2.17/build/dm-writeboost-target.c: In function 'dm_devsize': /var/lib/dkms/dm-writeboost/2.2.17/build/dm-writeboost-target.c:119:37: error: 'struct block_device' has no member named 'bd_inode' 119 | return i_size_read(dev->bdev->bd_inode) >> 9; | ^~ /var/lib/dkms/dm-writeboost/2.2.17/build/dm-writeboost-target.c:120:1: error: control reaches end of non-void function [-Werror=return-type] 120 | } | ^ cc1: some warnings being treated as errors make[3]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: /var/lib/dkms/dm-writeboost/2.2.17/build/dm-writeboost-target.o] Error 1 The corresponding Linux commit is 203c1ce0bb063d1620698e39637b64f2d09c1368 "RIP ->bd_inode" in v6.10-rc1. Andreas
Bug#1077671:
Attached is the patch I'm proposing for ubuntu. Let me know if you
would like a Salsa PR as well.
From d454f62c73e069199e4a706dcd50be580f06e5c7 Mon Sep 17 00:00:00 2001
From: Sam James
Date: Sun, 5 Nov 2023 22:17:02 +
Subject: [PATCH] libpkgconf: fix -Walloc-size
GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
libpkgconf/personality.c:260:11: warning: allocation of insufficient size '1' for type 'pkgconf_cross_personality_t' {aka 'struct pkgconf_cross_personality_'} with size '48' [-Walloc-size]
libpkgconf/queue.c:46:33: warning: allocation of insufficient size '1' for type 'pkgconf_queue_t' {aka'struct pkgconf_queue_'} with size '16' [-Walloc-size]
libpkgconf/client.c:164:33: warning: allocation of insufficient size '1' for type 'pkgconf_client_t' {aka 'struct pkgconf_client_'} with size '120' [-Walloc-size]
libpkgconf/path.c:105:14: warning: allocation of insufficient size '1' for type 'pkgconf_path_t' {aka 'struct pkgconf_path_'} with size '24' [-Walloc-size]
libpkgconf/path.c:237:22: warning: allocation of insufficient size '1' for type 'pkgconf_path_t' {aka 'struct pkgconf_path_'} with size '24' [-Walloc-size]
libpkgconf/tuple.c:239:34: warning: allocation of insufficient size '1' for type 'pkgconf_tuple_t' {aka 'struct pkgconf_tuple_'} with size '24' [-Walloc-size]
libpkgconf/dependency.c:133:13: warning: allocation of insufficient size '1' for type 'pkgconf_dependency_t' {aka 'struct pkgconf_dependency_'} with size '44' [-Walloc-size]
libpkgconf/dependency.c:472:17: warning: allocation of insufficient size '1' for type 'pkgconf_dependency_t' {aka 'struct pkgconf_dependency_'} with size '44' [-Walloc-size]
libpkgconf/fragment.c:146:22: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '24' [-Walloc-size]
libpkgconf/fragment.c:195:22: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '24' [-Walloc-size]
libpkgconf/fragment.c:356:14: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '24' [-Walloc-size]
libpkgconf/pkg.c:422:13: warning: allocation of insufficient size '1' for type 'pkgconf_pkg_t' {aka 'struct pkgconf_pkg_'} with size '188' [-Walloc-size]
libpkgconf/client.c:164:33: warning: allocation of insufficient size '1' for type 'pkgconf_client_t' {aka 'struct pkgconf_client_'} with size '224' [-Walloc-size]
libpkgconf/personality.c:260:11: warning: allocation of insufficient size '1' for type 'pkgconf_cross_personality_t' {aka 'struct pkgconf_cross_personality_'} with size '96' [-Walloc-size]
libpkgconf/dependency.c:133:13: warning: allocation of insufficient size '1' for type 'pkgconf_dependency_t' {aka 'struct pkgconf_dependency_'} with size '80' [-Walloc-size]
libpkgconf/dependency.c:472:17: warning: allocation of insufficient size '1' for type 'pkgconf_dependency_t' {aka 'struct pkgconf_dependency_'} with size '80' [-Walloc-size]
libpkgconf/path.c:105:14: warning: allocation of insufficient size '1' for type 'pkgconf_path_t' {aka 'struct pkgconf_path_'} with size '48' [-Walloc-size]
libpkgconf/path.c:237:22: warning: allocation of insufficient size '1' for type 'pkgconf_path_t' {aka 'struct pkgconf_path_'} with size '48' [-Walloc-size]
libpkgconf/queue.c:46:33: warning: allocation of insufficient size '1' for type 'pkgconf_queue_t' {aka 'struct pkgconf_queue_'} with size '32' [-Walloc-size]
libpkgconf/tuple.c:239:34: warning: allocation of insufficient size '1' for type 'pkgconf_tuple_t' {aka 'struct pkgconf_tuple_'} with size '48' [-Walloc-size]
libpkgconf/fragment.c:146:22: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '48' [-Walloc-size]
libpkgconf/fragment.c:195:22: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '48' [-Walloc-size]
libpkgconf/fragment.c:356:14: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '48' [-Walloc-size]
libpkgconf/pkg.c:422:13: warning: allocation of insufficient size '1' for type 'pkgconf_pkg_t' {aka 'struct pkgconf_pkg_'} with size '360' [-Walloc-size]
```
The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```
So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
doing anything wrong.
The only exception there is for argv which I fixed while at it.
Signed-off-by: Sam James
---
libpkgconf/argvsplit.c | 2 +-
libpkgconf/client.c | 2 +-
libpkgconf/dependency.c | 4 ++--
libpkgconf/fragment.c| 8
libpkgconf/path.c| 4 ++--
libpkgconf/personality.c | 2 +-
libpkgconf/pkg.c | 4 ++--
libpkgconf/queue.c | 2 +-
libpkgconf/tuple.c | 4 ++--
9
Bug#1075034: goocanvas-2.0: ftbfs with GCC-14
Control: tags 1075034 + patch On Wed, 03 Jul 2024 12:28:59 + Matthias Klose wrote: > [This bug is targeted to the upcoming trixie release] > > The package fails to build in a test rebuild on at least amd64 with > gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The > severity of this report will be raised before the trixie release. > The attached patch makes the build work again. /Andreas Rönnquist gus...@debian.org From: =?utf-8?q?Andreas_R=C3=B6nnquist?= Date: Thu, 1 Aug 2024 17:06:30 +0200 Subject: Fix casting to GooCanvasItemModelSimple --- src/goocanvasitemsimple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/goocanvasitemsimple.c b/src/goocanvasitemsimple.c index 19b3424..7095fd4 100644 --- a/src/goocanvasitemsimple.c +++ b/src/goocanvasitemsimple.c @@ -1536,7 +1536,7 @@ goo_canvas_item_simple_set_model (GooCanvasItemSimple *item, goo_canvas_item_simple_free_data (item->simple_data); g_slice_free (GooCanvasItemSimpleData, item->simple_data); - item->model = g_object_ref (model); + item->model = (GooCanvasItemModelSimple*)g_object_ref (model); item->simple_data = >model->simple_data; if (accessibility_enabled)
Bug#546997: listadmin: please support running a spam checker locally
Hi Noël, in our bug of the day initiative this bug showed up as one of the randomly picked bugs[1]. I'd like to hear your opinion about this package. This package has lost some kind of popularity but its clearly used according to popcon[2]. There was no new upstream version for quite some time but according to tracker[3] there seems to be some issue with either upstream download page or upstream web site which I did not checked. It seems the bugs open against this package[4] show that some upstream features might be missing and it might turn out you became silently upstream without knowing. Could you give some hint for the bug of the day team what might be the proper way to deal with the package? We might volunteer to create some repository inside salvage-team for you if you think its worth keeping this package inside Debian. However, if you think this might be a candidate for removal from Debian, you might like to do so (or give us permission to do so). Lucky to have met you again at DebConf Andreas. [1] http://blends.debian.net/botd/botd.html [2] https://qa.debian.org/popcon-graph.php?packages=listadmin_vote=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1 [3] https://tracker.debian.org/pkg/listadmin [4] https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=listadmin -- https://fam-tille.de
Bug#1077266: glx-diversions: does not divert libGLX.so
On 27/07/2024 16.20, Drew Parsons wrote: glx-diversions diverts /usr/lib/x86_64-linux-gnu/libGL.so to /etc/alternatives/glx--libGL.so-x86_64-linux-gnu which can be controlled by update-glx --config glx. The libGL.so.* diversion is only relevant for the no longer supported legacy drivers up to 418.* that still exist in sid. These are the version where nvidia shipped vendor specific libGL.so.*. Newer drivers use glvnd, thus the alternatives are pointing to the diverted libglvnd libraries, not to vendor libraries. libGLX.so.* only comes with libglvnd, so there was no point to include that into the diversions. (But as long as we keep the legacy drivers in sid (there are still users needing them for legacy ahrdware), we cannot get rid of the diversions. I think this explains why the nvidia drivers are not working in OFFLOAD (optimus) mode, e.g. That must have some other cause. $ __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only glxinfo name of display: :0 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 152 (GLX) Minor opcode of failed request: 24 (X_GLXCreateNewContext) Value in failed request: 0x0 Serial number of failed request: 50 Current serial number in output stream: 51 I suspect this error would not occur if libGLX.so was diverted (given an alternative) to libGLX_nvidia.so.0 (handled by update-glx --config glx, ultimately /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 from libglx-nvidia0) libGLX_nvidia.so.0 is not a replacement for libGLX.so.*, it is rather an implementation that can be loaded by the libglvnd libGLX.so.0 For what it's worth, nvidia now provides a fully supported open source kernal module, nvidia-open-kernel-dkms, so the nvidia driver is essentially no longer non-free. Please help them complete this change of policy by supporting use of the driver. Only the kernel module has source available, all other driver components are closed source and thus non-free. Andreas
Bug#1077688: WebCam of ThinkPad T14s AMD G3 (174f:1812) does not work since kernel 6.9.1
Package: src:linux Version: 6.9.7-1~bpo12+1 Severity: normal X-Debbugs-Cc: amai...@gmx.de The devices /dev/video* and /dev/media* have been disappeared since update to linux-6.9.7 from backports. Bisecting with various kernels shows that the problem has been appeared with kernel 6.9.1 first and still present in 6.10 kernels -- Package-specific info: ** Version: Linux version 6.9.7+bpo-amd64 (debian-ker...@lists.debian.org) (x86_64-linux-gnu-gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1~bpo12+1 (2024-07-03) ** Command line: root=/dev/mapper/euclid--vg-root ro quiet splash rd.luks.uuid=luks-5f04508b-61cf-49ca-9a59-85820d5778d6 rd.luks.options=discard resume=/dev/mapper/euclid--vg-root resume_offset=8298496 initcall_blacklist=acpi_cpufreq_init amd_pstate=active amdgpu.dcdebugmask=0x10 systemd.machine_id=87bb64cdf99a4fd4adbe941f0d245912 ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: LENOVO product_name: 21CQCTO1WW product_version: ThinkPad T14s Gen 3 chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: R22ET70W (1.40 ) board_vendor: LENOVO board_name: 21CQCTO1WW board_version: ThinkPad ** Loaded modules: bnep snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ctr ccm michael_mic btusb btrtl btintel btbcm btmtk bluetooth uinput xt_CHECKSUM sha3_generic jitterentropy_rng xt_MASQUERADE drbg ansi_cprng xt_conntrack ecdh_generic ecc ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat nft_chain_nat nf_nat qrtr_mhi nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 cpufreq_conservative nvme_fabrics nf_tables libcrc32c nfnetlink bridge stp llc wireguard libchacha20poly1305 chacha_x86_64 poly1305_x86_64 curve25519_x86_64 libcurve25519_generic libchacha ip6_udp_tunnel udp_tunnel uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videodev videobuf2_common mc binfmt_misc nls_ascii nls_cp437 vfat fat snd_acp6x_pdm_dma snd_soc_acp6x_mach snd_soc_dmic snd_sof_amd_rembrandt snd_sof_amd_acp snd_sof_pci snd_sof_xtensa_dsp snd_sof qrtr snd_sof_utils ath11k_pci snd_pci_ps snd_amd_sdw_acpi soundwire_amd soundwire_generic_allocation ath11k intel_rapl_msr amd_atl snd_ctl_led intel_rapl_common snd_soc_core snd_hda_codec_realtek edac_mce_amd qmi_helpers snd_hda_codec_generic snd_compress kvm_amd snd_pcm_dmaengine mac80211 snd_hda_scodec_component snd_hda_codec_hdmi soundwire_bus snd_hda_intel snd_intel_dspcfg snd_rpl_pci_acp6x ledtrig_audio snd_intel_sdw_acpi kvm libarc4 snd_hda_codec snd_pci_acp6x snd_hda_core snd_pci_acp5x rapl snd_hwdep think_lmi cfg80211 snd_rn_pci_acp3x thinkpad_acpi firmware_attributes_class snd_pcm psmouse nvram snd_timer thunderbolt snd_acp_config platform_profile wmi_bmof pcspkr snd_soc_acpi mhi snd snd_pci_acp3x soundcore k10temp i2c_piix4 rfkill ac fan joydev evdev amd_pmc button acpi_tad loop efi_pstore configfs ip_tables x_tables ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm drm_exec gpu_sched hid_multitouch drm_suballoc_helper hid_generic drm_buddy drm_display_helper crc32_pclmul xhci_pci nvme crc32c_intel i2c_hid_acpi xhci_hcd i2c_hid drm_kms_helper nvme_core hid ghash_clmulni_intel sha512_ssse3 sha512_generic t10_pi ucsi_acpi drm sha256_ssse3 typec_ucsi cec crc64_rocksoft_generic usbcore sp5100_tco crc64_rocksoft roles sha1_ssse3 ccp typec crc_t10dif watchdog rc_core crct10dif_generic video crct10dif_pclmul crc64 crct10dif_common usb_common battery wmi serio_raw dm_mod msr parport_pc ppdev lp parport efivarfs autofs4 aesni_intel crypto_simd cryptd ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Root Complex [1022:14b5] (rev 01) Subsystem: Lenovo Family 17h-19h PCIe Root Complex [17aa:50b4] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge [1022:14b7] (rev 01) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge [1022:14ba] (prog-if 00 [Normal decode]) Subsystem: Lenovo Family 17h-19h PCIe GPP Bridge [17aa:50b4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
Bug#1072625: nvidia-cuda-toolkit: switch to llvm 17
Control: severity -1 important On 30/07/2024 11.56, Emilio Pozuelo Monfort wrote: On Wed, 05 Jun 2024 12:32:03 +0200 Emilio Pozuelo Monfort wrote: nvidia-cuda-toolkit currently uses llvm 15, but that version is going to be removed as we also have 16, 17 and 18 in sid. Please switch to a newer version. Bumping to RC as it is our goal to remove LLVM 15 from trixie. Downgrading since this is only an alternative dependency (among many other old versions no longer in the archive). Andreas
Bug#1077678: xtrx-dkms: module fails to build for Linux 6.10: error: 'struct uart_state' has no member named 'xmit'
Package: xtrx-dkms Version: 0.0.1+git20190320.5ae3a3e-3.5 Severity: important Tags: upstream xtrx-dkms fails to build a module for Linux 6.10 in experimental: DKMS make.log for xtrx-0.0.1+git20190320.5ae3a3e-3.5 for kernel 6.10-cloud-amd64 (x86_64) Tue Jul 23 20:43:21 UTC 2024 make: Entering directory '/usr/src/linux-headers-6.10-cloud-amd64' CC [M] /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.o /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.c: In function 'xtrx_uart_do_tx': /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.c:472:28: error: 'struct uart_state' has no member named 'xmit' 472 | xmit = >state->xmit; |^~ /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.c:473:13: error: implicit declaration of function 'uart_circ_empty'; did you mean 'uart_lsr_tx_empty'? [-Werror=implicit-function-declaration] 473 | if (uart_circ_empty(xmit)) | ^~~ | uart_lsr_tx_empty /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.c:480:25: error: invalid use of undefined type 'struct circ_buf' 480 | c = xmit->buf[xmit->tail] & 0xff; | ^~ /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.c:480:35: error: invalid use of undefined type 'struct circ_buf' 480 | c = xmit->buf[xmit->tail] & 0xff; | ^~ /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.c:484:21: error: invalid use of undefined type 'struct circ_buf' 484 | xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1); | ^~ /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.c:484:35: error: invalid use of undefined type 'struct circ_buf' 484 | xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1); | ^~ /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.c:490:13: error: implicit declaration of function 'uart_circ_chars_pending' [-Werror=implicit-function-declaration] 490 | if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) | ^~~ cc1: some warnings being treated as errors make[2]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build/xtrx.o] Error 1 make[1]: *** [/usr/src/linux-headers-6.10-common/Makefile:1959: /var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.5/build] Error 2 make: *** [/usr/src/linux-headers-6.10-common/Makefile:252: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-6.10-cloud-amd64' This seems to be caused by Linux commit 1788cf6a91d9fa9aa61fc2917afe192c23d67f6a tty: serial: switch from circ_buf to kfifo Andreas
Bug#1077671: pkgconf: armhf DEP8 failure due to gcc warning
Package: pkgconf Version: 1.8.1-3 Severity: normal Dear Maintainer, pkgcong's autopkgtests are currently failing[1] on armhf: 222s testsuiteFAIL stderr: libpkgconf/client.c: In function 'pkgconf_client_new': 1830 That warning is issued at: 96s libpkgconf/client.c: In function 'pkgconf_client_new': 527 96s libpkgconf/client.c:162:47: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args] 528 96s 162 | pkgconf_client_t *out = calloc(sizeof(pkgconf_client_t), 1); 529 96s | ^~~~ 530 96s libpkgconf/client.c:162:47: note: earlier argument should specify number of elements, later size of each element 531 98s CC libpkgconf/pkg.lo There are plenty of other warnings after this one. What's a bit puzzling is that it only happens on armhf. 1. https://ci.debian.net/packages/p/pkgconf/unstable/armel/49390534/
Bug#1077626: glusterfs: brick segfaults
Package: glusterfs
Version: 11.1-4
Severity: normal
Dear Maintainer,
in Ubuntu we got a bug report[1] on glusterfs 11.1-4 (which was in
sync with debian), that it would segfault under certain conditions on
a user's system.
The reporter tracked the problem down to an upstream PR that
introduced it, and then to another PR that fixed it:
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295
This bug report and supporting data was good enough for the Ubuntu SRU
process, which was completed successfully.
I suppose debian users could be affected as well, so I'm filing this
bug here with the patch that was used in the Ubuntu update.
1. https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843
Description: Fix stack overflow in __inode_destroy
A recursive call to inode_unref was introduced when support for inode-level
namespaces was added. This results in a stack overflow under certain
conditions leading to brick SEGFAULTs. This patch removes the recurisve call
to inode_unref. This was fixed upstream but is yet to be included in a
release.
.
glusterfs (11.1-4ubuntu1) noble; urgency=medium
.
* Fix stack overflow in __inode_destroy (LP: #2064843)
Origin: upstream, https://github.com/gluster/glusterfs/commit/da2391dacd3483555e91a33ecdf89948be62b691
Bug: https://github.com/gluster/glusterfs/issues/4295
Bug-Ubuntu: https://launchpad.net/bugs/2064843
Author: Mohit Agrawal
Reviewed-By: Xavi Hernandez
Reviewed-By: Amar Tumballi
Reviewed-By: Bryce Harrington
Last-Update: 2024-05-08
---
--- glusterfs-11.1.orig/libglusterfs/src/inode.c
+++ glusterfs-11.1/libglusterfs/src/inode.c
@@ -351,9 +351,19 @@ __inode_ctx_free(inode_t *inode)
static void
__inode_destroy(inode_t *inode)
{
-inode_unref(inode->ns_inode);
-__inode_ctx_free(inode);
+inode_table_t *table = NULL;
+inode_t *ns_inode = inode->ns_inode;
+
+if (ns_inode) {
+table = ns_inode->table;
+pthread_mutex_lock(>lock);
+{
+__inode_unref(ns_inode, false);
+}
+pthread_mutex_unlock(>lock);
+}
+__inode_ctx_free(inode);
LOCK_DESTROY(>lock);
// memset (inode, 0xb, sizeof (*inode));
GF_FREE(inode);
Bug#1076665: .desktop shortcuts added to toolbars no longer work
On Tue, 30 Jul 2024 20:06:08 +0800 Michael Deegan wrote: > Package: geeqie > Version: 1:2.4-2+b2 > Followup-For: Bug #1076665 > > Okay, after a more thorough upgrade to trixie, I observed...no change! > > I however realise that I missed an important detail in my original report > (sorry! ). Plugins launched from the Plugins menu work fine, however I > added a couple of extremely frequently-used plugins to the main Toolbar, and > it is *these* buttons that stopped working (in addition to their icon being > replaced with the name of the desktop file). > > Also, there *is* a system-supplied desktop file for Darktable (and a bunch > of other apps), in /usr/share/applications/. > As you most probably have noticed, I have forwarded this bug upstream, and I have found the commit [1] that looks like it is the cause of the problem, and it seems like it is part of the coming (sooner or later) migration to GTK4, which if I am not mistaken doesn't have a toolbar implementation, which means that if the functionality is to be kept, it needs to be implemented in another way. I don't know really if the toolbar will be kept, or what the plan is, and this could be a reason that this hasn't been moved forward more. I probably could simply revert the commit in the Debian package, but I want to see what upstream says in response to the forwarded bug before taking any further steps. /Andreas gus...@debian.org 1: https://github.com/BestImageViewer/geeqie/commit/f1c1ccb94e55253651cc2219ec8d63130d90203d
Bug#1076665: .desktop shortcuts added to toolbars no longer work
On Tue, 30 Jul 2024 20:06:08 +0800 Michael Deegan wrote: > Package: geeqie > Version: 1:2.4-2+b2 > Followup-For: Bug #1076665 > > Okay, after a more thorough upgrade to trixie, I observed...no change! > > I however realise that I missed an important detail in my original report > (sorry! ). Plugins launched from the Plugins menu work fine, however I > added a couple of extremely frequently-used plugins to the main Toolbar, and > it is *these* buttons that stopped working (in addition to their icon being > replaced with the name of the desktop file). > > Also, there *is* a system-supplied desktop file for Darktable (and a bunch > of other apps), in /usr/share/applications/. > No worries! - As you can see above, I can reproduce. (The mail from me seems to have arrived to this bug in a improper order though so it might be a but confusing). And sorry for not understanding you properly earlier, it indeed looks like a proper bug. Investigating, it looks like it worked properly in the bookworm version (2.0.1 something), but not after this, I will investigate further and see if I can find a proper fix or where it broke. (or if it already reported upstream, there's quite a lot of bug reports to wade through there... :) best /Andreas gus...@debian.org
Bug#1076665: .desktop shortcuts added to toolbars no longer work
On Tue, 30 Jul 2024 09:59:25 +0800 Michael Deegan wrote: > Package: geeqie > Followup-For: Bug #1076665 > > Rightio. FWIW I've mixed stable and testing on and off for a couple of > decades, and rarely experience trouble with it, but it's quite reasonable > if you'd rather not deal with any extra corner cases that result. I'll > try again with all packages from the same release, hopefully in the next > few days. > > Also, you can't find the darktable plugin, because I made it myself, from > within geeqie's own plugin editor. :P The plugin therefore lives in > ~/.config/geeqie/applications/, which I hope geeqie would have no trouble > finding! > > I do prefer to not build my own packages these days, if I can help it (hence > mixed releases instead of a bunch of packages I have to manually keep up to > date). > Alright, I can reproduce the bug on an unstable - it works just fine in both the menu, and if you use the plugin-menu when right-clicking the image, but not if adding a toolbar that should do the same thing. Sorry for not understanding what you meant earlier, this indeed looks like a proper bug. (I blame not using the toolbar at all for a long time previously). /Andreas gus...@debian.org
Bug#1076665: .desktop shortcuts added to toolbars no longer work
if;image/x-canon-cr3;image/x-exr;image/aces;image/heif;image/heic;image/jp2;image/jxl;image/webp;image/qoi;image/fits Icon=darktable # StartupWMClass=darktable # X-Unity-IconBackgroundColor=#252525 -------- /Andreas gus...@debian.org
Bug#1077512:
Did you paste the correct logs? Because they show you were using ubuntu packages, not debian ones.
Bug#1075229: lmemory: ftbfs with GCC-14
On Wed, 03 Jul 2024 12:35:05 + Matthias Klose wrote:
>
> [This bug is targeted to the upcoming trixie release]
>
> Please keep this issue open in the bug tracker for the package it
> was filed for. If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
>
Control: tags 1075229 + patch
The attached patch seems to fix this.
/Andreas Rönnquist
gus...@debian.org
From: =?utf-8?q?Andreas_R=C3=B6nnquist?=
Date: Mon, 29 Jul 2024 14:55:22 +0200
Subject: Use const struct direct in file_select
---
list.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/list.c b/list.c
index 65359cd..109b0d1 100644
--- a/list.c
+++ b/list.c
@@ -8,7 +8,7 @@
/* local prototypes */
-int file_select (struct direct *entry);
+int file_select (const struct direct *entry);
GSList *
lmem_dir_list (GSList * file_list, gchar * directory_name)
@@ -56,7 +56,7 @@ lmem_dir_list (GSList * file_list, gchar * directory_name)
}
int
-file_select (struct direct *entry)
+file_select (const struct direct *entry)
{/* ignore . and .. entries */
if ((strcmp (entry->d_name, ".") == 0) ||
(strcmp (entry->d_name, "..") == 0))
Bug#1076665: .desktop shortcuts added to toolbars no longer work
tags 1076665 + moreinfo thanks Hi As mentioned in my previous mail to this bugreport, the information that I requested is required to handle it - if that isn't provided I will close it, since I cannot reproduce this. And a darktable plugin seems to not come from the debian package, it doesn't seem to be provided with the debian geeqie package. Without further information I will close this bug report. best /Andreas andr...@ronnquist.net gus...@debian.org
Bug#1073960: RFS: libmobi/0.12+dfsg-1 [RC] -- Tools for handling Mobipocket/Kindle ebook format documents
On 2024-07-26 Tobias Frost wrote: [...] > - usually d/changelog's purpose is to document the changes to the Debian > *packaging*, not to document upstream changes. See Policy 4.6. (You've got > your upstream changelog, that is where your upstream changes shoudl got to. > In this case I'd write the changelog as: > libmobi (0.12+dfsg-1) unstable; urgency=medium > * New upstream release. (Closes: #1073331) [...] Hello, FWIW I think that would only be a proper changelog entry if #1073331 was a "please package new upstream version"-bug. I would go for 8X-- * New upstream release. + Builds with libxml >= 2.12. Closes: #1073331 8X------ 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#1077217: adv-17v35x-dkms: module fails to build for Linux 6.10: error: 'struct uart_state' has no member named 'xmit'
s prototype for 'serialadv_spi_read_slave' [-Wmissing-prototypes] 2068 | int serialadv_spi_read_slave(struct uart_adv_port *up, unsigned char *p_data) | ^~~~ /var/lib/dkms/adv-17v35x/5.0.7.0/build/adv17v35x.c:2098:6: warning: no previous prototype for 'serialadv_spi_start' [-Wmissing-prototypes] 2098 | void serialadv_spi_start(struct uart_adv_port *up) | ^~~ /var/lib/dkms/adv-17v35x/5.0.7.0/build/adv17v35x.c:2110:6: warning: no previous prototype for 'serialadv_spi_stop' [-Wmissing-prototypes] 2110 | void serialadv_spi_stop(struct uart_adv_port *up) | ^~ /var/lib/dkms/adv-17v35x/5.0.7.0/build/adv17v35x.c:2131:5: warning: no previous prototype for 'serialadv_get_boardID' [-Wmissing-prototypes] 2131 | int serialadv_get_boardID(struct uart_adv_port *up, short unsigned int *p_boardID) | ^ /var/lib/dkms/adv-17v35x/5.0.7.0/build/adv17v35x.c:2221:6: warning: no previous prototype for 'init_adv_uart_struct' [-Wmissing-prototypes] 2221 | void init_adv_uart_struct(void) | ^~~~ /var/lib/dkms/adv-17v35x/5.0.7.0/build/adv17v35x.c:2254:5: warning: no previous prototype for 'serialadv_register_port' [-Wmissing-prototypes] 2254 | int serialadv_register_port(struct uart_port *port, unsigned short deviceid, | ^~~ /var/lib/dkms/adv-17v35x/5.0.7.0/build/adv17v35x.c:2530:6: warning: no previous prototype for 'serialadv_unregister_port' [-Wmissing-prototypes] 2530 | void serialadv_unregister_port(int index, int line) | ^ /var/lib/dkms/adv-17v35x/5.0.7.0/build/adv17v35x.c:2547:6: warning: no previous prototype for 'pciserial_remove_ports' [-Wmissing-prototypes] 2547 | void pciserial_remove_ports(struct serial_private *priv) | ^~ cc1: some warnings being treated as errors make[2]: *** [/usr/src/linux-headers-6.10-common/scripts/Makefile.build:249: /var/lib/dkms/adv-17v35x/5.0.7.0/build/adv17v35x.o] Error 1 make[1]: *** [/usr/src/linux-headers-6.10-common/Makefile:1959: /var/lib/dkms/adv-17v35x/5.0.7.0/build] Error 2 make: *** [/usr/src/linux-headers-6.10-common/Makefile:252: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-6.10-cloud-amd64' This seems to be caused by Linux commit 1788cf6a91d9fa9aa61fc2917afe192c23d67f6a tty: serial: switch from circ_buf to kfifo Andreas
Bug#1077216: librem-ec-acpi-dkms: module fails to build for Linux 6.10: error: 'struct acpi_driver' has no member named 'owner'
Package: librem-ec-acpi-dkms
Version: 0.9.2-1
Severity: important
Tags: upstream
librem-ec-acpi-dkms file to build a module for Linux 6.10:
DKMS make.log for librem_ec_acpi-0.9.2 for kernel 6.10-rt-amd64 (x86_64)
Tue Jul 23 20:25:08 UTC 2024
make: Entering directory '/usr/src/linux-headers-6.10-rt-amd64'
CC [M] /var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.o
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.c:782:10: error:
'struct acpi_driver' has no member named 'owner'
782 | .owner = THIS_MODULE,
| ^
In file included from
/usr/src/linux-headers-6.10-common-rt/arch/x86/include/asm/mem_encrypt.h:15,
from
/usr/src/linux-headers-6.10-common-rt/include/linux/mem_encrypt.h:17,
from
/usr/src/linux-headers-6.10-common-rt/arch/x86/include/asm/processor-flags.h:6,
from
/usr/src/linux-headers-6.10-common-rt/arch/x86/include/asm/irqflags.h:5,
from
/usr/src/linux-headers-6.10-common-rt/include/linux/irqflags.h:18,
from
/usr/src/linux-headers-6.10-common-rt/include/linux/spinlock.h:59,
from
/usr/src/linux-headers-6.10-common-rt/include/linux/mmzone.h:8,
from
/usr/src/linux-headers-6.10-common-rt/include/linux/gfp.h:7,
from
/usr/src/linux-headers-6.10-common-rt/include/linux/slab.h:16,
from
/usr/src/linux-headers-6.10-common-rt/include/linux/resource_ext.h:11,
from
/usr/src/linux-headers-6.10-common-rt/include/linux/acpi.h:13,
from
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.c:16:
/usr/src/linux-headers-6.10-common-rt/include/linux/init.h:180:21: warning:
initialization of 'char' from 'struct module *' makes integer from pointer
without a cast [-Wint-conversion]
180 | #define THIS_MODULE (&__this_module)
| ^
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.c:782:18: note: in
expansion of macro 'THIS_MODULE'
782 | .owner = THIS_MODULE,
| ^~~
/usr/src/linux-headers-6.10-common-rt/include/linux/init.h:180:21: note: (near
initialization for 'librem_ec_driver.class[0]')
180 | #define THIS_MODULE (&__this_module)
| ^
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.c:782:18: note: in
expansion of macro 'THIS_MODULE'
782 | .owner = THIS_MODULE,
| ^~~
/usr/src/linux-headers-6.10-common-rt/include/linux/init.h:180:21: error:
initializer element is not computable at load time
180 | #define THIS_MODULE (&__this_module)
| ^
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.c:782:18: note: in
expansion of macro 'THIS_MODULE'
782 | .owner = THIS_MODULE,
| ^~~
/usr/src/linux-headers-6.10-common-rt/include/linux/init.h:180:21: note: (near
initialization for 'librem_ec_driver.class[0]')
180 | #define THIS_MODULE (&__this_module)
| ^
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.c:782:18: note: in
expansion of macro 'THIS_MODULE'
782 | .owner = THIS_MODULE,
| ^~~
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.c:780:46: warning:
missing braces around initializer [-Wmissing-braces]
780 | static struct acpi_driver librem_ec_driver = {
| ^
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.c:780:46: warning:
missing braces around initializer [-Wmissing-braces]
make[2]: *** [/usr/src/linux-headers-6.10-common-rt/scripts/Makefile.build:249:
/var/lib/dkms/librem_ec_acpi/0.9.2/build/librem_ec_acpi.o] Error 1
make[1]: *** [/usr/src/linux-headers-6.10-common-rt/Makefile:1959:
/var/lib/dkms/librem_ec_acpi/0.9.2/build] Error 2
make: *** [/usr/src/linux-headers-6.10-common-rt/Makefile:252: __sub-make]
Error 2
make: Leaving directory '/usr/src/linux-headers-6.10-rt-amd64'
This should be caused by upstream commit
cc85f9c05bba23eb525497b42ac5b74801ccbd87
ACPI: drop redundant owner from acpi_driver
Andreas
Bug#1077214: evdi-dkms: module fails to build for Linux 6.10: error: implicit declaration of function 'vmap'
Package: evdi-dkms Version: 1.14.2+dfsg-1 Severity: important Tags: upstream evdi-dkms fails to build a module for Linux 6.10 in experimental: DKMS make.log for evdi-1.14.2+dfsg for kernel 6.10-rt-amd64 (x86_64) Tue Jul 23 20:25:05 UTC 2024 make: Entering directory '/usr/src/linux-headers-6.10-rt-amd64' CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_platform_drv.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_platform_dev.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_sysfs.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_modeset.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_connector.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_encoder.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_drm_drv.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_fb.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_gem.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_painter.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_params.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_cursor.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_debug.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_i2c.o CC [M] /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_ioc32.o /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_gem.c: In function 'evdi_gem_vmap': /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_gem.c:319:25: error: implicit declaration of function 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration] 319 | obj->vmapping = vmap(obj->pages, page_count, 0, PAGE_KERNEL); | ^~~~ | kmap /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_gem.c:319:23: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 319 | obj->vmapping = vmap(obj->pages, page_count, 0, PAGE_KERNEL); | ^ /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_gem.c: In function 'evdi_gem_vunmap': /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_gem.c:355:17: error: implicit declaration of function 'vunmap'; did you mean 'kunmap'? [-Werror=implicit-function-declaration] 355 | vunmap(obj->vmapping); | ^~ | kunmap cc1: some warnings being treated as errors make[2]: *** [/usr/src/linux-headers-6.10-common-rt/scripts/Makefile.build:249: /var/lib/dkms/evdi/1.14.2+dfsg/build/evdi_gem.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/usr/src/linux-headers-6.10-common-rt/Makefile:1959: /var/lib/dkms/evdi/1.14.2+dfsg/build] Error 2 make: *** [/usr/src/linux-headers-6.10-common-rt/Makefile:252: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-6.10-rt-amd64' This might be a missing #include Andreas
Bug#1077212: ddcci-dkms: module fails to build for Linux 6.10
Package: ddcci-dkms Version: 0.4.4-2 Severity: important Tags: upstream ddcci-dkms fails to build a module for Linux 6.10 in experimental: DKMS make.log for ddcci-0.4.4 for kernel 6.10-rt-amd64 (x86_64) Tue Jul 23 20:25:02 UTC 2024 make: Entering directory '/var/lib/dkms/ddcci/0.4.4/build' make -C "ddcci" make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.4/build/ddcci' make -C "/lib/modules/6.10-rt-amd64/build" M="/var/lib/dkms/ddcci/0.4.4/build/ddcci" modules make[2]: Entering directory '/usr/src/linux-headers-6.10-rt-amd64' CC [M] /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.o /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.c:1831:27: error: 'I2C_CLASS_SPD' undeclared here (not in a function); did you mean 'I2C_CLASS_HWMON'? 1831 | .class = I2C_CLASS_SPD, | ^ | I2C_CLASS_HWMON make[4]: *** [/usr/src/linux-headers-6.10-common-rt/scripts/Makefile.build:249: /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.o] Error 1 make[3]: *** [/usr/src/linux-headers-6.10-common-rt/Makefile:1959: /var/lib/dkms/ddcci/0.4.4/build/ddcci] Error 2 make[2]: *** [/usr/src/linux-headers-6.10-common-rt/Makefile:252: __sub-make] Error 2 make[2]: Leaving directory '/usr/src/linux-headers-6.10-rt-amd64' make[1]: *** [Makefile:38: ddcci.ko] Error 2 make[1]: Leaving directory '/var/lib/dkms/ddcci/0.4.4/build/ddcci' make: *** [Makefile:28: ddcci] Error 2 make: Leaving directory '/var/lib/dkms/ddcci/0.4.4/build' This is caused by Linux commit e61bcf42d290e73025bab38e0e55a5586c2d8ad5 i2c: Remove I2C_CLASS_SPD Andreas
Bug#1076721: NMU of gdebi
On Tue, 23 Jul 2024 16:39:10 +0200 Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?= wrote: > Hi > > I would like to NMU gdebi, fixing #926633 and #1076721 - would anyone > have anything against this? > > debdiff attached. (Simply fixing the findall regexp to > > c = findall(r"\[(\S)/\S\]", msg)[0].lower() > > There's no up to date vcs (or not up to date) other than the bazaar - > right? And I of course discovered that that findall command is available in another place. New debdiff attached that fixes it in both places. /Andreas gus...@debian.org gdebi_nmu9.debdiff Description: Binary data
Bug#1076721: NMU of gdebi
That regexp is of course in another spot in the source too, I have refreshed my NMU and have a debdiff for both places. See attachment. I will upload it to delayed/10 most probably today if there's no objections. best /Andreas gus...@debian.org gdebi_nmu9.debdiff Description: Binary data
Bug#1076721: NMU of gdebi
Hi I would like to NMU gdebi, fixing #926633 and #1076721 - would anyone have anything against this? debdiff attached. (Simply fixing the findall regexp to c = findall(r"\[(\S)/\S\]", msg)[0].lower() There's no up to date vcs (or not up to date) other than the bazaar - right? best /Andreas gus...@debian.org gdebi_nmu.debdiff Description: Binary data
Bug#1065416: requesting input on recent posts to #1065416
Hi all, Am Tue, Jul 23, 2024 at 04:10:46PM +0900 schrieb Sean Whitton: > On Sat 20 Jul 2024 at 01:01pm +02, Matthias Klose wrote: > > > - I am accepting the offer given in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#108 > > to take over the linux-libc-dev package. > > I will start working on that at DebCamp and DebConf. > > This is a significant point of agreement. Bastian, how about we revert > your changes for the time being, to give Matthias time to do this work? Since leader@d.o was involved: I personally consider this a good solution as well. Kind regards Andreas. -- https://fam-tille.de
Bug#1076759: debhelper: Please provide policy checker plugins
Package: debhelper
Version: 13.16
Severity: wishlist
Hi Niels,
as some (extremely late) follow up to our discussion[1] about lintian
and the fact that its checking binary artefacts at a way to late stage
I'd like to propose some solution of checking policy issues early.
I could perfectly imagine to have some first "lintian-like" step after
dh_clean, checking for instance spelling errors in debian/* or issues
in d/copyright.
I could similarly imagine some dh_* plugin after dh_install to check
several things as well that do not require a readily built package.
Kind regards and thanks for all your work on debhelper
Andreas.
[1] https://lists.debian.org/debian-devel/2024/05/msg00162.html
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debhelper depends on:
ii autotools-dev20220109.1
ii dh-autoreconf20
ii dh-strip-nondeterminism 1.14.0-1
ii dpkg 1.22.6
ii dpkg-dev 1.22.6
ii dwz 0.15-1+b1
ii file 1:5.45-3
ii libdebhelper-perl13.16
ii libdpkg-perl 1.22.6
ii man-db 2.12.1-2
ii perl 5.38.2-5
ii po-debconf 1.0.21+nmu1
debhelper recommends no packages.
Versions of packages debhelper suggests:
ii dh-make 2.202402
-- no debconf information
Bug#1076721: gdebi gives a SyntaxWarning invalid escape sequence when run
Control: tags -1 + patch
On Mon, 22 Jul 2024 16:12:31 +0200 Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?=
wrote:
> Package: gdebi
> Version: 0.9.5.7+nmu7
> Severity: minor
>
> Dear Maintainer,
>
> gdebi gives a warning when run in the terminal (simply using gdebi as
> the command):
>
> /usr/bin/gdebi:113: SyntaxWarning: invalid escape sequence '\S'
> c = findall("[[(](\S+)/\S+[])]", msg)[0].lower()
>
> (and the help output after as expected).
>
Patch fixing this attached changing the findall command to
c = findall(r"\[(\S)/\S\]", msg)[0].lower()
which seems to work for me.
/Andreas
gus...@debian.org
diff --git a/gdebi b/gdebi
index bee0b8d..1b64709 100755
--- a/gdebi
+++ b/gdebi
@@ -110,7 +110,7 @@ if __name__ == "__main__":
sys.stdout.flush()
res = sys.stdin.readline()
try:
-c = findall("[[(](\S+)/\S+[])]", msg)[0].lower()
+c = findall(r"\[(\S)/\S\]", msg)[0].lower()
except IndexError:
c = "y"
if res.lower().startswith(c):
Bug#1076742: sphinxsearch: FTBFS with abseil 20230802: -std=c++11 unsupported
Source: sphinxsearch Version: 2.8.2-1 Severity: serious sphinxsearch/experimental cannot be built with abseil 20230802 (sphinxsearch/sid is not affected): /usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less than C++14 are not supported." but sphinxsearch builds with -std=c++11 ... [ 25%] Building CXX object src/CMakeFiles/libsphinx.dir/sphinxquery.cpp.o cd /build/sphinxsearch-2.8.2/obj-i686-linux-gnu/src && /usr/bin/c++ -DBUILD_WITH_CMAKE -DDATADIR=\"/var/lib/manticore\" -DHAVE_CONFIG_H -DHAVE_GLOBALALIASES_H -DHAVE_WSREP -DNDEBUG -D_FILE_OFFSET_BITS=64 -I/usr/include/mariadb -I/usr/include/mariadb/mysql -I /usr/include/postgresql -I/build/sphinxsearch-2.8.2/obj-i686-linux-gnu/config -g -O2 -ffile-prefix-map=/build/sphinxsearch-2.8.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -Wall -g -O3 -fn o-rtti -std=c++11 -I/usr/include/mariadb -I/usr/include/mariadb/mysql -MD -MT src/CMakeFiles/libsphinx.dir/sphinxquery.cpp.o -MF CMakeFiles/libsphinx.dir/sphinxquery.cpp.o.d -o CMakeFiles/libsphinx.dir/sphinxquery.cpp.o -c /build/sphinxsearch-2.8.2/src/sphi nxquery.cpp ... Andreas
Bug#1076721: gdebi gives a SyntaxWarning invalid escape sequence when run
Package: gdebi
Version: 0.9.5.7+nmu7
Severity: minor
Dear Maintainer,
gdebi gives a warning when run in the terminal (simply using gdebi as
the command):
/usr/bin/gdebi:113: SyntaxWarning: invalid escape sequence '\S'
c = findall("[[(](\S+)/\S+[])]", msg)[0].lower()
(and the help output after as expected).
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.9-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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 gdebi depends on:
ii gdebi-core 0.9.5.7+nmu7
ii gir1.2-gtk-3.0 3.24.43-1
ii gir1.2-vte-2.91 0.75.92-1
ii pkexec 124-3
ii python3 3.12.4-1
ii python3-gi 3.48.2-1+b1
Versions of packages gdebi recommends:
pn libgtk2-perl
ii lintian 2.117.0
ii shared-mime-info 2.4-5
gdebi suggests no packages.
-- no debconf information
Bug#1076683: rust-web-doc: missing Conflicts: rust-mozilla-doc
Package: rust-web-doc Version: 1.70.0+dfsg1-7~deb12u2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts fileconflict Hi, during a test with piuparts I noticed your package fails to upgrade from 'bullseye'. It installed fine in 'bullseye', then the upgrade to 'bookworm' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../rust-web-doc_1.70.0+dfsg1-7~deb12u2_all.deb ... Unpacking rust-web-doc (1.70.0+dfsg1-7~deb12u2) ... dpkg: error processing archive /var/cache/apt/archives/rust-web-doc_1.70.0+dfsg1-7~deb12u2_all.deb (--unpack): trying to overwrite '/usr/share/doc/rust-doc/html/rust-logo-32x32-blk.png', which is also in package rust-mozilla-doc 1.63.0+dfsg1-2~deb11u1 (this is the only conflicting file) cheers, Andreas rust-mozilla-doc=1.63.0+dfsg1-2~deb11u1_rust-web-doc=1.70.0+dfsg1-7~deb12u2.log.gz Description: application/gzip
Bug#1076681: python3-csvkit,csvkit: both ship /usr/share/man/man1/csv*.1.gz
Package: python3-csvkit,csvkit Version: 2.0.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts fileconflict Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite each others files. >From the attached log (scroll to the bottom...): Preparing to unpack .../csvkit_2.0.1-1_all.deb ... Unpacking csvkit (2.0.1-1) ... dpkg: error processing archive /var/cache/apt/archives/csvkit_2.0.1-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man1/csvclean.1.gz', which is also in package python3-csvkit 2.0.1-1 Errors were encountered while processing: /var/cache/apt/archives/csvkit_2.0.1-1_all.deb The following files are shipped in both packages: usr/share/man/man1/csvclean.1.gz usr/share/man/man1/csvcut.1.gz usr/share/man/man1/csvformat.1.gz usr/share/man/man1/csvgrep.1.gz usr/share/man/man1/csvjoin.1.gz usr/share/man/man1/csvjson.1.gz usr/share/man/man1/csvlook.1.gz usr/share/man/man1/csvpy.1.gz usr/share/man/man1/csvsort.1.gz usr/share/man/man1/csvsql.1.gz usr/share/man/man1/csvstack.1.gz usr/share/man/man1/csvstat.1.gz usr/share/man/man1/in2csv.1.gz usr/share/man/man1/sql2csv.1.gz cheers, Andreas python3-csvkit=2.0.1-1_csvkit=2.0.1-1.log.gz Description: application/gzip
Bug#1076679: parlatype-common: missing Breaks+Replaces: parlatype (<< 4)
Package: parlatype-common Version: 4.2-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails. >From the attached log (scroll to the bottom...): Preparing to unpack .../parlatype-common_4.2-1_all.deb ... Unpacking parlatype-common (4.2-1) ... dpkg: error processing archive /var/cache/apt/archives/parlatype-common_4.2-1_all.deb (--unpack): trying to overwrite '/usr/share/locale/ar/LC_MESSAGES/parlatype.mo', which is also in package parlatype 3.1-3.1+b1 Errors were encountered while processing: /var/cache/apt/archives/parlatype-common_4.2-1_all.deb The conflicting files are usr/share/locale/ar/LC_MESSAGES/parlatype.mo usr/share/locale/ca/LC_MESSAGES/parlatype.mo usr/share/locale/cs/LC_MESSAGES/parlatype.mo usr/share/locale/de/LC_MESSAGES/parlatype.mo usr/share/locale/en_AU/LC_MESSAGES/parlatype.mo usr/share/locale/en_GB/LC_MESSAGES/parlatype.mo usr/share/locale/es/LC_MESSAGES/parlatype.mo usr/share/locale/fi/LC_MESSAGES/parlatype.mo usr/share/locale/fr/LC_MESSAGES/parlatype.mo usr/share/locale/he/LC_MESSAGES/parlatype.mo usr/share/locale/hu/LC_MESSAGES/parlatype.mo usr/share/locale/id/LC_MESSAGES/parlatype.mo usr/share/locale/it/LC_MESSAGES/parlatype.mo usr/share/locale/ja/LC_MESSAGES/parlatype.mo usr/share/locale/kab/LC_MESSAGES/parlatype.mo usr/share/locale/ku/LC_MESSAGES/parlatype.mo usr/share/locale/lt/LC_MESSAGES/parlatype.mo usr/share/locale/ms/LC_MESSAGES/parlatype.mo usr/share/locale/nb_NO/LC_MESSAGES/parlatype.mo usr/share/locale/nl/LC_MESSAGES/parlatype.mo usr/share/locale/pl/LC_MESSAGES/parlatype.mo usr/share/locale/pt/LC_MESSAGES/parlatype.mo usr/share/locale/pt_BR/LC_MESSAGES/parlatype.mo usr/share/locale/ru/LC_MESSAGES/parlatype.mo usr/share/locale/sk/LC_MESSAGES/parlatype.mo usr/share/locale/sr/LC_MESSAGES/parlatype.mo usr/share/locale/sv/LC_MESSAGES/parlatype.mo usr/share/man/man1/parlatype.1.gz usr/share/parlatype/asr/de.sphinx.bartsch.voxforge.asr usr/share/parlatype/asr/en.sphinx.debian.asr cheers, Andreas parlatype=3.1-3.1+b1_parlatype-common=4.2-1.log.gz Description: application/gzip
Bug#1076664: RFS: netplug/1.2.9.2-5 [RC] -- network link monitor daemon
On 2024-07-21 Pali Rohár wrote: > Hello, sorry, but I currently do not have time to start fixing others > issues. I focused on the issue which Vincent reported that recent > iproute2 package upgrade completely broke the netplug package. [...] OK, fair enough, I will take a look. cu Andreas
Bug#1076665: .desktop shortcuts added to toolbars no longer work
On Sun, 21 Jul 2024 19:46:25 +0800 Michael Deegan wrote: > Package: geeqie > Version: 1:2.4-2+b2 > Severity: normal > > Since updating to 2.4, my convenient shortcuts for throwing images at > darktable etc no longer work. > > Instead of the application's icon, only the name of the plugin (eg. > 'org.darktable.darktable.desktop') is shown. When clicking on the button, > nothing happens except for a console message: > >(geeqie:1144975): Gtk-CRITICAL **: 19:18:01.553: gtk_action_activate: > assertion 'GTK_IS_ACTION (action)' failed > Thanks for your report - First and foremost. Please don't mix stable with testing/unstable. You are running geeqie from testing/unstable, but on Debian 12 - this is not supported. Geeqie 1:2.4-2+b2 is built against the packages in testing/unstable, so I don't know if it would work on stable or not. If you want to run geeqie 2.4 on stable, build it yourself, but then don't report the bugs on the Debian BTS, because you are running stuff that isn't from Debian. I'm inclined to simply close this report, just because of this, but in this case the cause of the problem COULD simply be that it seems to look for the plugins in the wrong place. Where do you have that org.darktable.darktable.desktop file? is it in /usr/share/geeqie/applications or in /usr/local/share/geeqie/applications - which would in it's turn imply that you have mixed also Debian packages with a locally built geeqie. (Which is _another_ source of problems that you can run into). /Andreas Rönnquist gus...@debian.org
Bug#1073960: RFS: libmobi/0.12+dfsg-1 [RC] -- Tools for handling Mobipocket/Kindle ebook format documents
On 2024-07-11 Phil Wyett wrote: [...] > Summary... > I believe libmobi is ready for sponsorship/upload. Could a Debian > Developer (DD) with available free time, please review this package > and upload if you feel it is ready. [...] Hello, comparing 0.12+dfsg-1 with the version currently in the archive I found these changes: diff -Nru libmobi-0.11+dfsg/debian/changelog libmobi-0.12+dfsg/debian/changelog --- libmobi-0.11+dfsg/debian/changelog 2024-02-28 15:13:08.0 +0100 +++ libmobi-0.12+dfsg/debian/changelog 2024-06-17 13:34:25.0 +0200 @@ -1,9 +1,22 @@ -libmobi (0.11+dfsg-1.1) unstable; urgency=medium +libmobi (0.12+dfsg-1) unstable; urgency=medium + + * New upstream release. [...] +libmobi (0.11+dfsg-1.1) experimental; urgency=medium * Non-maintainer upload. - * Rename libraries for 64-bit time_t transition. Closes: #1062420 + * Rename libraries for 64-bit time_t transition. - -- Benjamin Drung Wed, 28 Feb 2024 14:13:08 + + -- Steve Langasek Thu, 01 Feb 2024 09:58:53 + [...] diff -Nru libmobi-0.11+dfsg/debian/control libmobi-0.12+dfsg/debian/control --- libmobi-0.11+dfsg/debian/control2024-02-28 15:13:08.0 +0100 +++ libmobi-0.12+dfsg/debian/control2024-06-17 13:34:25.0 +0200 @@ -1,8 +1,8 @@ Source: libmobi Priority: optional Maintainer: Bartek Fabiszewski -Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), zlib1g-dev, libxml2-dev -Standards-Version: 4.6.0 +Build-Depends: debhelper-compat (= 13), zlib1g-dev, libxml2-dev i.e. afaict some of the changes in the t64 transition were reverted (added Build-Dependency and actually uploaded changelog version). Could you please change this, Bartek? - Thanks! cu Andreas
Bug#1076643: cyrus-imapd: BerkeleyDB related cruft?
Source: cyrus-imapd Version: 3.10.0~beta2-1 Severity: wishlist Hello, afaik cyrus-imapd stopped using BerkeleyDB a couple of releases ago. However cyrus-imapd still build-depends on libdb-dev and there is BerkeleyDB related code in debian/rules and other places. Is this still active or is dead code? Thanks for doublechecking. cu Andreas
Bug#1076506: [Pkg-utopia-maintainers] Bug#1076506: polkitd: Strange polkit related error upgrading to bookworm
Am Sat, Jul 20, 2024 at 03:52:25PM +0200 schrieb Michael Biebl: > (please leave the moreinfo tag present until we actually have useful > information to further investigate this) OK. > Am 20.07.24 um 14:58 schrieb Andreas Tille: > > This doesn't show any problem. Are you sure you ran this command on a system > showing this failure? It **WAS** showing the problem. As I said my action (as per the forum suggested) fixed the problem. > Or have you manually worked around this in the mean time This is what I wanted to express. > Thanks for the bash trace, but this doesn't show any problem. > > See my remark above. You obviously need to run this on a system showing the > problem not where it has been worked around already. > > Or better yet, provide concise steps how this can be reproduced. I guess installing a bullseye system with LXDE (which seems to rely on policykit somehow - when I tried to remove policykit those lxde packages would have been deleted as well) and upgrade to bookworm. There might be a chance to ask the people on the forum about the issue. I'm obviously not the only one who observed it. In future I will have to upgrade more such similar systems. If I meet the error again I will report *before* fixing. Sorry, I can't deal with this any more now until August since I prepare to leave for DebConf. Kind regards Andreas. -- https://fam-tille.de
Bug#1076506: [Pkg-utopia-maintainers] Bug#1076506: polkitd: Strange polkit related error upgrading to bookworm
Control: tags -1 - moreinfo Hi again, Am Wed, Jul 17, 2024 at 06:15:06PM +0200 schrieb Michael Biebl: > > > > Can you attach the output of > > > > SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/polkit.conf > > > > for the system where you get this failure. > > > > > > # SYSTEMD_LOG_LEVEL=debug systemd-sysusers > > > /usr/lib/sysusers.d/polkit.conf > > > SELinux enabled state cached to: disabled > > > Failed to open '/usr/lib/sysusers.d/polkit.conf', ignoring: No such > > > file or directory > > > > SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/polkitd.conf > > > > please (note the 'd') # SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/polkitd.conf SELinux enabled state cached to: disabled Group polkitd already exists. User polkitd already exists. > Ideally also include the output of "dpkg-reconfigure" with > /var/lib/dpkg/info/polkitd.postinst having a "set -x" added right at the > top. See end of this mail. > The usual spiel. Hope this helps now. Please note: I will not have any access to this laptop for the next two weeks. Kind regards Andreas. # dpkg-reconfigure polkitd 2>&1 | tee > output # cat output + set -e + getent passwd polkitd + user_changed= + command -v systemd-sysusers + systemd-sysusers polkitd.conf + dpkg --compare-versions 122-3 lt 122-3~ + id -g polkitd + [ 134 = 65534 ] + set_perms polkitd root 700 /etc/polkit-1/rules.d + USER=polkitd + GROUP=root + MODE=700 + FILE=/etc/polkit-1/rules.d + dpkg-statoverride --list /etc/polkit-1/rules.d + chown polkitd:root /etc/polkit-1/rules.d + chmod 700 /etc/polkit-1/rules.d + set_perms polkitd root 700 /usr/share/polkit-1/rules.d + USER=polkitd + GROUP=root + MODE=700 + FILE=/usr/share/polkit-1/rules.d + dpkg-statoverride --list /usr/share/polkit-1/rules.d + chown polkitd:root /usr/share/polkit-1/rules.d + chmod 700 /usr/share/polkit-1/rules.d + set_perms polkitd root 700 /var/lib/polkit-1 + USER=polkitd + GROUP=root + MODE=700 + FILE=/var/lib/polkit-1 + dpkg-statoverride --list /var/lib/polkit-1 + chown polkitd:root /var/lib/polkit-1 + chmod 700 /var/lib/polkit-1 + set_perms root root 4755 /usr/lib/polkit-1/polkit-agent-helper-1 + USER=root + GROUP=root + MODE=4755 + FILE=/usr/lib/polkit-1/polkit-agent-helper-1 + dpkg-statoverride --list /usr/lib/polkit-1/polkit-agent-helper-1 + chown root:root /usr/lib/polkit-1/polkit-agent-helper-1 + chmod 4755 /usr/lib/polkit-1/polkit-agent-helper-1 + [ -z ] + [ -n ] + [ configure = configure ] + update-xmlcatalog --sort --add --type public --id -//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN --package polkitd --local /usr/share/xml/polkit-1/catalog.xml + update-xmlcatalog --sort --add --type system --id http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd --package polkitd --local /usr/share/xml/polkit-1/catalog.xml + update-xmlcatalog --sort --add --type public --id -//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN --package polkitd --root + update-xmlcatalog --sort --add --type system --id http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd --package polkitd --root + [ configure = configure ] + command -v systemd-tmpfiles + [ -x /usr/bin/systemd-tmpfiles ] + systemd-tmpfiles --create polkitd.conf + dpkg-maintscript-helper rm_conffile /etc/pam.d/polkit-1 122-2~ -- configure 122-3 + dpkg-maintscript-helper rm_conffile /etc/polkit-1/localauthority.conf.d/50-localauthority.conf 121+compat0.1-1~ -- configure 122-3 + dpkg-maintscript-helper rm_conffile /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf 121+compat0.1-1~ -- configure 122-3 + dpkg-maintscript-helper rm_conffile /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf 121+compat0.1-1~ -- configure 122-3 + dpkg-maintscript-helper rm_conffile /etc/polkit-1/rules.d/40-debian-sudo.rules 121~ polkitd-javascript -- configure 122-3 + dpkg-maintscript-helper rm_conffile /etc/polkit-1/rules.d/40-ubuntu-admin.rules 121~ polkitd-javascript -- configure 122-3 + dpkg-maintscript-helper rm_conffile /etc/polkit-1/rules.d/50-default.rules 121~ polkitd-javascript -- configure 122-3 + [ configure = configure ] + [ -z ] + [ -d /run/systemd/system ] + systemctl --system daemon-reload + [ -n 122-3 ] + deb-systemd-invoke try-restart polkit.service + [ -e /etc/pam.d/polkit-1.dpkg-bak ] + dpkg --compare-versions 122-3 lt 0.109-1 + [ -d /run/systemd/system ] + exit 0 -- https://fam-tille.de
Bug#968451: libgcrypt20-dev not multi-arch installable
Control: tags -1 pending On 2020-08-15 Christian Klein wrote: > Package: libgcrypt20-dev > Version: 1.8.6-2 > Severity: important > libgcrypt20-dev is not multi-arch installable. It's not only the > missing multi- arch:same field, but the package also ships various > files that are different an different architectures. > One thing is that the -dev package ships "/usr/bin/libgcrypt-config", > which contains arch-specific information. However, it also ships a > handful of helper binaries under "usr/bin", namely "dumpsexp", > "hmac256" and "mpicalc". > WINE is in the process of switching to libgcrypt, and this bug makes > compiling recent versions problematic. Hello, FYI I have made the necessary changes (hopefully) and made an upload targetting experimental. Since this adds a new binary package for the helper binaries it needs to pass NEW queue which involves manual approval by ftp-master, so it might take a couple of days to actually be available. cu Andreas https://ftp-master.debian.org/new/libgcrypt20_1.11.0-3.html -- `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#1076568: dpkg: no longer evaluates variables in DEB_CPPFLAGS_MAINT_APPEND
Package: dpkg Version: 1.22.7 Severity: important X-Debbugs-Cc: Graham Inggs I suspect dpkg 1.22.7 to cause a regression when building nvidia-cuda-toolkit, e.g. https://buildd.debian.org/status/fetch.php?pkg=nvidia-cuda-toolkit=amd64=12.1.1-2=1721290167=0 debian/rules has DEB_BUILD_MAINT_OPTIONS = hardening=+all DEB_CPPFLAGS_MAINT_APPEND= -I$(CURDIR)/nvidia-cuda-tree-$(DEB_HOST_ARCH)/cuda_cudart/include DEB_LDFLAGS_MAINT_APPEND = -pthread include /usr/share/dpkg/architecture.mk include /usr/share/dpkg/buildflags.mk include /usr/share/dpkg/pkg-info.mk and the build log now contains /bin/sh: 1: CURDIR: not found /bin/sh: 1: DEB_HOST_ARCH: not found (and a subsequent failure since some header could not be found) which makes me suspect that the variables in DEB_CPPFLAGS_MAINT_APPEND are no longer evaluated and passed on into sh context. (If I'm not using DEB_CPPFLAGS_MAINT_APPEND correctly, please suggest what I should do instead) Andreas
Bug#1076458:
I updated the patch[1] in salsa with the latest changes from upstream[2]. 1. https://salsa.debian.org/debian/freeradius/-/merge_requests/11 2. https://github.com/FreeRADIUS/freeradius-server/pull/5375
Bug#1076506: [Pkg-utopia-maintainers] Bug#1076506: polkitd: Strange polkit related error upgrading to bookworm
Control: tags -1 - moreinfo Am Wed, Jul 17, 2024 at 05:26:20PM +0200 schrieb Michael Biebl: > > > Hope this helps > > > > Not really. What we need is the failure messages for the polkitd package. > > Can you attach the output of > SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/polkit.conf > for the system where you get this failure. # SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/polkit.conf SELinux enabled state cached to: disabled Failed to open '/usr/lib/sysusers.d/polkit.conf', ignoring: No such file or directory I also add some `cd /var/log; grep polkit *log` output to this mail to let you see what versions where installed before and after the upgrade. Hope this is better help now Andreas. -- https://fam-tille.de auth.log:Jul 17 11:06:02 HOSTNAME polkitd(authority=local): Registered Authentication Agent for unix-session:3 (system bus name :1.52 [lxpolkit], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8) auth.log:Jul 17 11:06:05 HOSTNAME pkexec: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=1001) auth.log:Jul 17 11:06:16 HOSTNAME polkitd(authority=local): Operator of unix-session:3 FAILED to authenticate to gain authorization for action org.blueman.rfkill.setstate for system-bus-name::1.62 [/usr/bin/python3 /usr/bin/blueman-applet] (owned by unix-user:trinh) auth.log:Jul 17 11:48:29 HOSTNAME dbus-daemon[620]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=621 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.freedesktop.PolicyKit1.Authority" member="CheckAuthorization" error name="(unset)" requested_reply="0" destination="org.freedesktop.PolicyKit1" (uid=0 pid=624 comm="/usr/libexec/polkitd --no-debug ") auth.log:Jul 17 11:48:29 HOSTNAME dbus-daemon[620]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=621 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.freedesktop.PolicyKit1.Authority" member="CheckAuthorization" error name="(unset)" requested_reply="0" destination="org.freedesktop.PolicyKit1" (uid=0 pid=624 comm="/usr/libexec/polkitd --no-debug ") auth.log:Jul 17 11:48:29 HOSTNAME dbus-daemon[620]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=621 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.freedesktop.PolicyKit1.Authority" member="CheckAuthorization" error name="(unset)" requested_reply="0" destination="org.freedesktop.PolicyKit1" (uid=0 pid=624 comm="/usr/libexec/polkitd --no-debug ") auth.log:Jul 17 11:48:29 HOSTNAME dbus-daemon[620]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=621 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.freedesktop.PolicyKit1.Authority" member="CheckAuthorization" error name="(unset)" requested_reply="0" destination="org.freedesktop.PolicyKit1" (uid=0 pid=624 comm="/usr/libexec/polkitd --no-debug ") auth.log:Jul 17 11:48:29 HOSTNAME dbus-daemon[620]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=621 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.freedesktop.PolicyKit1.Authority" member="CheckAuthorization" error name="(unset)" requested_reply="0" destination="org.freedesktop.PolicyKit1" (uid=0 pid=624 comm="/usr/libexec/polkitd --no-debug ") auth.log:Jul 17 11:48:29 HOSTNAME dbus-daemon[620]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=621 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.freedesktop.PolicyKit1.Authority" member="CheckAuthorization" error name="(unset)" requested_reply="0" destination="org.freedesktop.PolicyKit1" (uid=0 pid=624 comm="/usr/libexec/polkitd --no-debug ") auth.log:Jul 17 11:48:29 HOSTNAME dbus-daemon[620]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=621 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.freedesktop.PolicyKit1.Authority" member="CheckAuthorization" error name="(unset)" requested_reply="0" destination="org.freedesktop.PolicyKit1" (uid=0 pid=624 comm="/usr/libexec/polkitd --no-debug ") auth.log
Bug#1076506: [Pkg-utopia-maintainers] Bug#1076506: polkitd: Strange polkit related error upgrading to bookworm
Am Wed, Jul 17, 2024 at 04:08:40PM +0200 schrieb Michael Biebl: > > https://forums.debian.net/viewtopic.php?t=156286 > > Maybe a duplicate of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074789 I do not think so. > Do you remember the exact error messages? The error messages where *exactly* the ones as in the forum thread: dpkg: dependency problems prevent configuration of polkitd-pkla: polkitd-pkla depends on polkitd (>= 121+compat0.1); however: Package polkitd is not configured yet. I tried to manually install polkitd-pkla but always got that error message which I simply had thrown into a search engine and ended up in that forum thread, which helped me upgrading the box and gave it out of my hands again. Hope this helps Andreas. -- https://fam-tille.de
Bug#858970:
Hello, >> readdir ordering is probably bad. I think that's essentially random on a >> lot of file systems, and I'm not sure it's even guaranteed to be stable. >> Is there any chance we could get that fixed in Heimdal before we start to >> rely on it? > > I filed https://github.com/heimdal/heimdal/issues/1252 showing the problem I suppose the handling of .d directories in the archive varies a lot. Some might have explicit ordering, others (like heimdal) not. The "normal" way we would be using this include mechanism is to add a new section, add something to an existing section, or perhaps override something. Always thinking about what's in the main config file. This seems like it would work with the current patches, without surprises. Having multiple snippets trying to override each other seems like a bad idea in the first place. But it could happen, and that's where the readdir() ordering becomes problematic. We could consdier this ordering an open bug, and move forward, with the expectation that it would be fixed someday. But we might end up in the same place as this bug here, which was filed in 2017 and we still don't have an upstream release with a fix 7 years later.
Bug#1076506: polkitd: Strange polkit related error upgrading to bookworm
Package: polkitd Severity: important Hi, sorry for the extremely weak bug report since I do not have access to the machine in question any more but it should be reported anyway. Today I upgaded some laptop I maintain for someone else from bullseye to bookworm. I was running into exactly the same problem as dscribed here: https://forums.debian.net/viewtopic.php?t=156286 and the suggested solution adduser --system --group polkitd adduser root polkitd dpkg --configure polkitd dpkg --configure -a worked for me as well. It seems the lxde environment needs polkitd which I can hardly reproduce on my own hardware since I do not use it here. So sorry again for the weak bug report but I think this issue is serios enough to make some noise about. With better information I would have set severity to serious since it breaks upgrades. Kind regards and thanks for maintaining polkitd Andreas. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-18-arm64 (SMP w/2 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages polkitd depends on: ii adduser 3.134 ii dbus [default-dbus-system-bus] 1.14.10-1~deb12u1 ii libc6 2.36-9+deb12u4 pn libduktape207 ii libexpat1 2.5.0-1 ii libglib2.0-02.74.6-2 ii libpam-systemd [logind] 252.22-1~deb12u1 ii libpam0g1.5.2-6+deb12u1 pn libpolkit-agent-1-0 pn libpolkit-gobject-1-0 ii libsystemd0 252.22-1~deb12u1 ii systemd [systemd-sysusers] 252.22-1~deb12u1 ii xml-core0.18+nmu1 polkitd recommends no packages. Versions of packages polkitd suggests: pn polkitd-pkla
Bug#1076458: freeradius: replace radsecret script with bash
Hi Bernhard, On Tue, Jul 16, 2024 at 7:05 PM Bernhard Schmidt wrote: > > Hi Andreas, > > > Upstream also suggested[2] that we could just remove the radsecret > > script, since it's not used by anything else, but I rather not deviate > > from upstream that much if we can. > > Same here. Have you considered to submit the replacement upstream? I > will gladly cherry-pick the change as soon as it has been merged > upstream. Since it is somewhat security sensitive I would rather not > deviate from upstream here (the great Debian OpenSSL debacle comes to mind). I totally understand. The patch went through a quick security review[1] in ubuntu, from which I got a minor change (see the comment for details). I also just proposed[2] this to upstream. 1. https://bugs.launchpad.net/ubuntu/+source/libconvert-base32-perl/+bug/2073269/comments/6 2. https://github.com/FreeRADIUS/freeradius-server/pull/5375
Bug#1076245: lintian-brush: hangs and when killed leaved lock in Git repository
Am Tue, Jul 16, 2024 at 12:33:25PM + schrieb Jelmer Vernooij: > Yeah, I have managed to. > > This appears to be some weird issue in the reqwest crate used in > upstream-ontologist, which causes it to hang. > > Seems similar to > https://stackoverflow.com/questions/73805971/reqwest-post-request-freezes-after-random-amount-of-time Thank you for tracking this down (and all yor work on lintian-brush in general!) Do you see any chance to release some fixed version soon? Kind regards Andreas. -- https://fam-tille.de
Bug#911189: gpgme-json packaging
On 2024-07-14 Sébastien Noel wrote: [...] > You are the first person of the "debian gpg team" (i saw "team upload" > in the changelog on your latest upload, so i supposed you are part of > it) to react to this bug in 5 years. > I will not lie, I'm (like others) pissed off by this situation, where > we (= the people asking for a change in the debian package) are ignored > like a pile of poop on the sidewalk. > Over the years, 2 merge request or patches have been provided: > - https://salsa.debian.org/debian/gpgme/-/merge_requests/2 > - https://salsa.debian.org/twolife/gpgme/-/commits/gpgmejson > I think we have done our part. But all we got was... nothing! > Not a review, not even a word. Just plain ignore. > This is insulting. > What are we supposed to do ? > What do YOU want us to do for this to advance ? > More code/MR ? > More begging ? Good morning Sébastien, I can understand your unhappiness but sadly cannot do much alleviate it. Regarding my role in team: I am limiting myself to changes that do not include policy choices. I cannot take the responsibility of being the main maintainer. Adding another binding which requires another piece of specialized knowledge to maintain it clearly is a policy change, so I will not do it. 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#1073255: Qt 6 bindings for gpgme
On 2024-07-16 Patrick Franz wrote: > On Sat, 22 Jun 2024 15:09:02 +0200 Andreas Metzler > [...] >> I have updated the packaging draft, adding the upstream change for Qt >> 5 and Qt 6 include split 09827ffc7745e7dc4275f1c6e46531a959be1f71. >> I think this is basically ready for experimental. > I see there is good progress on salsa. Do you have any estimate when you > plan to upload it to experimental and/or unstable ? Hello Patrick, I am sorry I cannot give you an estimate there. I will not upload without approval/review by the main maintainters. An upload would go to experimental first. Splitting of the qt devel packages (#863149) will require an intermediate upload to unstable with just adding a Provides: libqgpgme-dev to libgpgmepp-dev, followed by changing all packagages (build)-depending on QT gpgme to add a (build)-dep on the new package name. Only once that is finished gpgme with qt5/6-dev as separate packages could be uploaded to unstable. cu Andreas
Bug#1076458:
I updated the bash script with a count of 13 bytes instead of 12, due
to the analysis done on [1].
Here is the new version:
#!/bin/bash
data=$(dd if=/dev/urandom bs=1 count=13 2>/dev/null| base32 | tr 'A-Z' 'a-z')
echo ${data:0:4}-${data:4:4}-${data:8:4}-${data:12:4}-${data:16:4}
I'm about to submit a salsa PR as well.
1. https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/2073269/comments/6
Bug#1076458: freeradius: replace radsecret script with bash
Package: freeradius
Version: 3.2.5+dfsg-2
Priority: normal
Dear Maintainer,
freeradius is now shipping a perl script called radsecret, which adds
two new perl dependencies to the package: libconvert-base32-perl and
libcrypt-urandom-perl[1]
In Ubuntu, those two packages are in Universe, and since freeradius is
in main, we cannot depend on those. We could start the process to move
them to main, but since the radsecret script is relatively simple,
here is a bash replacement for your consideration:
#!/bin/bash
data=$(dd if=/dev/urandom bs=1 count=12 2>/dev/null| base32 | tr 'A-Z' 'a-z')
echo ${data:0:4}-${data:4:4}-${data:8:4}-${data:12:4}-${data:16:4}
Upstream also suggested[2] that we could just remove the radsecret
script, since it's not used by anything else, but I rather not deviate
from upstream that much if we can.
1. https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/2073269
2. https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/2073269/comments/2
Bug#1076312: /usr/bin/filezilla: Illegal instruction generated on startup
On Mon, 15 Jul 2024 15:28:40 + John Scott wrote: > Andreas wrote: > > the sse4.1 requirement seems to have been added as a workaround for > > some other problem specifically on the i386 architecture, but I > > will investigate and try to provide a fix. > > Let me know if you want a hand or for me to look over anything: I > know a thing or two about GCC, in particular with building cross > toolchains with it. Also note that since the build flags are injected > in both Bookworm and Trixie/Sid, you'll probably need to work on two > fixes. > > The alleged GCC bug may have been fixed in newer GCC 13 uploads. If > that's the case, I can help you bisect to set an appropriate build > dependency on a fixed version. If no fixed GCC 13 appears to be > packaged, the GCC maintainers could probably apply a patch to > Bookworm and Trixie/Sid, and then a tight build dependency would save > the day. > > I'll leave you to doing what you've got to do, but I'm here. > -- You might have seen the thread I started on debian-devel [1], where they think that this is really a problem in filezilla which should be fixed. From the minor tests I have done, filezilla (without the msse4.1 patch applied) builds fine on gcc-14 on i386 (and all other arches), which however isn't even in unstable yet. I have of course also tested also building with the gcc in unstable (13) on i386 without the patch, and there filezilla doesn't build. The fix in gcc-14 seems to be this: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9a19fa8b616f83474c35cc5b34a3865073ced829 But I of course understand that it most probably is a big investment to get something like this into stable. (oh, why did I adopt this package... ;) /Andreas 1: https://lists.debian.org/debian-devel/2024/07/msg00240.html
Bug#1076314: qiime hard-codes python 3.11 without depending on it
Hi Matthias, Am Tue, Jul 16, 2024 at 12:52:56PM +0200 schrieb Matthias Klose: > > Just to let me understand correctly: Its definitely a mistake to > > (Build-)Depend: python3-all. However, am I understand you correctly > > that (Build-)Depend from python3.11 could save the packag in testing? > > Upstream has announce support for Python3.12 in autumn - so this will > > probably be solved before the freeze. But your bug report is not fully > > clear to me. > > $ fgrep -r 3.11 . > ./debian/changelog: * d/rules: Only build for Python 3.11 until upstream > catches up with > ./debian/changelog:3.11 > ./debian/tests/run-unit-test:QIIMETEST= python3.11 -m pytest > ./debian/tests/control:Depends: @, python3-pytest, python3.11 > > yes, but python3-all doesn't depend on python3.11 anymore. We are trying to > *remove* 3.11 from testing/unstable, not keeping it. I perfectly understood that python3.11 will be removed from testing (and that it should be happen rather sooner than later which will consequently remove the qiime packages as well (if dependencies will be set correctly as you requested in this bug report). What I want to understand is, whether its sensible to fix the dependencies of those packages now (for say the next three months or so) and whether you consider this a fix of this bug report or not. > why do you have the explicit test dependency on 3.11, and not using > python3-all there as well, looping over all supported python3 versions? Please note that as long I'm DPL I should not be included formally into this "you/we". I more or less stalled my packaging work inside the Debian Med team (and BTW, it works quite good thanks to the strong team). I understood Michael in a way that he wants to restore python3-all once the autumn release of qiime will be issued. > It would be much better to prepare for 3.13 in the autumn time frame. That's > most likely the (only) version that we'll ship with trixie. Thank you for the hint. I hope changes between 3.12 and 3.13 are not that extraordinary complex like from 3.11 to 3.12. Kind regards and thank you for your work on all Python3 releases Andreas. -- https://fam-tille.de
Bug#1076314: qiime hard-codes python 3.11 without depending on it
Hi Matthias, Am Sun, Jul 14, 2024 at 10:57:14AM +0200 schrieb Matthias Klose: > Package: src:qiime > Version: 2024.5.0-1 > Severity: serious > Tags: sid trixie > > * Only build for Python 3.11 until upstream catches up with Python > 3.12. > > dear debian-med, please don't do that. It doesn't help to hide problems, > using 3.11, but not reflecting this in the dependencies. If a package > doesn't have support for 3.12, then it gets removed from testing. Just to let me understand correctly: Its definitely a mistake to (Build-)Depend: python3-all. However, am I understand you correctly that (Build-)Depend from python3.11 could save the packag in testing? Upstream has announce support for Python3.12 in autumn - so this will probably be solved before the freeze. But your bug report is not fully clear to me. Kind regards Andreas. -- https://fam-tille.de
Bug#1076312: /usr/bin/filezilla: Illegal instruction generated on startup
On Mon, 15 Jul 2024 15:28:40 + John Scott wrote: > Andreas wrote: > > the sse4.1 requirement seems to have been added as a workaround for > > some other problem specifically on the i386 architecture, but I > > will investigate and try to provide a fix. > > Let me know if you want a hand or for me to look over anything: I > know a thing or two about GCC, in particular with building cross > toolchains with it. Also note that since the build flags are injected > in both Bookworm and Trixie/Sid, you'll probably need to work on two > fixes. > > The alleged GCC bug may have been fixed in newer GCC 13 uploads. If > that's the case, I can help you bisect to set an appropriate build > dependency on a fixed version. If no fixed GCC 13 appears to be > packaged, the GCC maintainers could probably apply a patch to > Bookworm and Trixie/Sid, and then a tight build dependency would save > the day. > > I'll leave you to doing what you've got to do, but I'm here. > -- Thank you very much - you can most likely expect to get more mail from me. :) Very much appreciated! best /Andreas
Bug#1076312: /usr/bin/filezilla: Illegal instruction generated on startup
On Sun, 14 Jul 2024 18:59:06 +0100 jon bird wrote:
> On Sun, 14 Jul 2024 14:45:33 +0200
> Andreas Rönnquist wrote:
>
> [...]
> > >>
> > >This is on a fairly elderly Celeron laptop running LXQt. I half
> > >wondered if the processor is too old - for info, o/p of
> > >/proc/cpuinfo:
> >
> > Thanks - that looks indeed like it might be the problem - however,
> > some debugging would help out to pinpoint it exactly.
> > >
> [...]
>
> Appears to be around here (I also pulled down the source as well):
>
> Program received signal SIGILL, Illegal instruction.
> 0xb7e804c3 in (anonymous namespace)::get_option_registry () at
> ./src/engine/optionsbase.cpp:74 74 {
> (gdb) list
> 69 std::vector options_;
> 70 std::map>
> name_to_option_;
> 71 };
> 72
> 73 std::pair
> get_option_registry()
> 74 {
> 75 static option_registry reg;
> 76 return std::make_pair(std::ref(reg),
> fz::scoped_lock(reg.mtx_));
> 77 }
> 78 }
>
> And looks to be sat on a "pinsrd" instruction.
>
> (gdb) disassemble /s
> Dump of assembler code for function (anonymous
> namespace)::get_option_registry(): Address range 0xb7e804a0 to
> 0xb7e805ad: ./src/engine/optionsbase.cpp:
> 74 {
>0xb7e804a0 <+0>: push %ebp
>0xb7e804a1 <+1>: mov%esp,%ebp
>0xb7e804a3 <+3>: push %edi
>0xb7e804a4 <+4>: mov%eax,%edi
>0xb7e804a6 <+6>: push %esi
>0xb7e804a7 <+7>: call 0xb7db5a3d <__x86.get_pc_thunk.si>
>0xb7e804ac <+12>:add$0x9abd0,%esi
>0xb7e804b2 <+18>:push %ebx
>0xb7e804b3 <+19>:sub$0x1c,%esp
>0xb7e804b6 <+22>:lea0x1ca4(%esi),%eax
>0xb7e804bc <+28>:movd %eax,%xmm0
>0xb7e804c0 <+32>:mov%eax,-0x1c(%ebp)
> => 0xb7e804c3 <+35>:pinsrd $0x1,%eax,%xmm0
>0xb7e804c9 <+41>:movq %xmm0,-0x28(%ebp)
>
> Looks to be something that only arrived with SSE4.1. Whereas that dump
> of cpuinfo shows that mine only has SSE2. So that answers that one then.
>
> Rgs,
It is indeed a problem in the filezilla package - I will investigate
it, the sse4.1 requirement seems to have been added as a workaround for
some other problem specifically on the i386 architecture, but I will
investigate and try to provide a fix. My guess is that it will work
just to remove the sse4.1 requirement, but it will need to be tested.
best
/Andreas
Bug#1076312: /usr/bin/filezilla: Illegal instruction generated on startup
On Sun, 14 Jul 2024 12:45:06 +0100 jon bird wrote: >Hi Andreas, > >On Sun, 14 Jul 2024 13:16:02 +0200 >Andreas Rönnquist wrote: > >> On Sun, 14 Jul 2024 09:45:19 +0100 >> jon wrote: >[...] > >> >> Thanks for your report - Are you saying that you get "Illegal >> instruction" when running from the command line? - Could you please >> provide the full command-line output? >> >That's literally all that comes out on the command line: > >jon@lapdog:~$ filezilla >Illegal instruction >jon@lapdog:~$ > >> Also, which desktop environment are you on? - I have tested on amd64 >> Xfce and Gnome and cannot reproduce there, and cannot reproduce on >> i386 Gnome either. >> >This is on a fairly elderly Celeron laptop running LXQt. I half >wondered if the processor is too old - for info, o/p of /proc/cpuinfo: Thanks - that looks indeed like it might be the problem - however, some debugging would help out to pinpoint it exactly. > >And if it helps, backtrace from gdb: > >Program received signal SIGILL, Illegal instruction. >0xb7e804c3 in ?? () from >/lib/i386-linux-gnu/libfzclient-private-3.63.0.so (gdb) bt >#0 0xb7e804c3 in () at >/lib/i386-linux-gnu/libfzclient-private-3.63.0.so #1 0xb7e83c82 in >register_options(std::initializer_list) () >at /lib/i386-linux-gnu/libfzclient-private-3.63.0.so >#2 0xb7dede0e in () at >/lib/i386-linux-gnu/libfzclient-private-3.63.0.so #3 0xb7fcfb43 in >call_init (env=0xb2ac, argv=0xb2a4, argc=1, l=) >at ./elf/dl-init.c:74 #4 call_init (l=, argc=1, >argv=0xb2a4, env=0xb2ac) at ./elf/dl-init.c:26 #5 0xb7fcfc3b >in _dl_init (main_map=, argc=1, argv=0xb2a4, >env=0xb2ac) at ./elf/dl-init.c:121 #6 0xb7fe64f0 in >_dl_start_user () at /lib/ld-linux.so.2 > Thanks - that can be helpful - however, could you please install the debug-symbols for the filezilla packages which would give more information - simplest is probably to get the packages directly here: http://debug.mirrors.debian.org/debian-debug/pool/main/f/filezilla/filezilla-dbgsym_3.63.0-1+deb12u3_i386.deb http://debug.mirrors.debian.org/debian-debug/pool/main/libf/libfilezilla/libfilezilla34-dbgsym_0.41.0-2_i386.deb or you can add the debug repos to your sources.list like described in the wiki here: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols And then install them using apt (filezilla-dbgsym and libfilezilla34-dbgsym). Either of these methods should give a more detailed backtrace which makes it easier to pinpoint the problem. Thank you for your help. /Andreas andr...@ronnquist.net gus...@debian.org
Bug#1076312: /usr/bin/filezilla: Illegal instruction generated on startup
On Sun, 14 Jul 2024 09:45:19 +0100 jon wrote: > * What led up to the situation? > >Attempt to run filezilla from application menu, did not appear to start. > > * What exactly did you do (or not do) that was effective (or > ineffective)? > >Attempt to run from command line > > * What was the outcome of this action? > >Illegal instruction > > * What outcome did you expect instead? > >Application start > >Kernel ring buffer shows the following: > >traps: filezilla[1431] trap invalid opcode ip:b7d934c3 sp:bfcf0480 error:0 in >libfzclient-private-3.63.0.so[b7cb5000+128000] > Thanks for your report - Are you saying that you get "Illegal instruction" when running from the command line? - Could you please provide the full command-line output? Also, which desktop environment are you on? - I have tested on amd64 Xfce and Gnome and cannot reproduce there, and cannot reproduce on i386 Gnome either. /Andreas gus...@debian.org
Bug#1076245: lintian-brush: hangs and when killed leaved lock in Git repository
Hi Jelmer, Am Sat, Jul 13, 2024 at 02:13:24PM + schrieb Jelmer Vernooij: > > This is not only true for this specific package but for *all* packages > > I tried in the last couple of weeks. > > It looks like it's an issue with one of the fixers that seems to hang. I > think there's three things we need to do here: I'm not comfortable with the technical details - so if you say so ... sounds reasonable. > * Add timeouts for fixers This could be a first means to solve the issue. > * Handle Ctrl+C more gracefully This makes sense in any case. > * Fix the actual hanging fixer The optimal solution but the first one would be OK for me. Can you reproduce the issue at your side? Kind regards Andreas. -- https://fam-tille.de
Bug#1010062: RFA: autogen -- automated text file generator
On 2024-02-18 Andreas Metzler wrote: [...] > Please note that autogen is nearing EOL. It is also pretty complicated > internally (guile, C code, shell scripting). I will probably look into > submitting bug reports against rdeps so they know they need to move on. Hello, I have now submitted bugs against the packages build-depending on it (except for the gcc-9 packages which are scheduled for removal). https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=ametzler%40debian.org=autogen-eol 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#1076268: ocserv: Unused build-dependency on GNU autogen
Source: ocserv Version: 1.2.4-1 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, afaict ocserv's build-dependency on GNU autogen is unused. Quoting ChangeLog: | commit 760199a33c624f07a9612e62a6b38c66e4962bbb | Author: Nikos Mavrogiannopoulos | Date: Sun Jan 14 16:54:27 2018 +0100 | | doc: man-pages are modified to be generated using ronn | | That eliminates the need for autogen and also combines | doc/sample.config and manpage contents. Now the doc/sample.config | is the primary config documentation location. | | Signed-off-by: Nikos Mavrogiannopoulos cu Andreas
Bug#1076267: heroes: Build-Depends on GNU autogen
Source: heroes Version: 0.21-19 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Hell, heroes build-depends on GNU autogen, which has reached EOL and IMHO is unlikely to be revived. heroes's usage of autogen seems to be atypical. - It does not use the option parser or the doc-generation. I cannot reccomend a replacement for the specific use case. 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#1076266: libsndfile: Build-Depends on GNU autogen
Source: libsndfile Version: 1.13-1 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Hell, libsndfile build-depends on GNU autogen, which has reached EOL and IMHO is unlikely to be revived. libsndfile's usage of autogen seems to be atypical. - It does not use the option parser or the doc-generation. I cannot reccomend a replacement for the specific use case. 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#1076258: complexity: Build-Depends on GNU autogen
Source: complexity Version: 1.13-1 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, complexity build-depends on GNU autogen, which has reached EOL and IMHO is unlikely to be revived. The best replacement for autogen's AutoOpts part I know (but I do not know everything) is the toolchain gnutls upstream built for their conversion: 1. One-time onversion of .def to json with https://gitlab.com/dueno/parse-autogen and some handholding. 2. Build-time generation from json input of option-parser and docs with https://gitlab.com/gnutls/cligen (python). (cligen is not yet packaged for Debian, gnutls upstream uses a git submodule.) 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#1076257: cross-toolchain-base-ports: Unused build-dependency on GNU autogen
Source: cross-toolchain-base-ports Version: 65 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, afaict cross-toolchain-base-ports's build-dependency on GNU autogen is unused. I have searched for "autogen" in buildlog and the only matches besides package installation were multiple instances of | Now at patch go-testsuite.diff | : # only needed when we have changes, and currently fails with autogen 5.18 | : #cd /<>/gcc/src/fixincludes && ./genfixes | sync Which is commented and autogen 5.18 was uploaded to Debian about 11 years ago. I am submittimg this now because autogen is EOL and if you still were actually using it a replacement would need to be found. cu Andreas
Bug#1076256: cross-toolchain-base-mipsen: Unused build-dependency on GNU autogen
Source: cross-toolchain-base-mipsen Version: 28 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, afaict cross-toolchain-base-mipsen's build-dependency on GNU autogen is unused. I have searched for "autogen" in buildlog and the only matches besides package installation were multiple instances of | Now at patch go-testsuite.diff | : # only needed when we have changes, and currently fails with autogen 5.18 | : #cd /<>/gcc/src/fixincludes && ./genfixes | sync Which is commented and autogen 5.18 was uploaded to Debian about 11 years ago. I am submittimg this now because autogen is EOL and if you still were actually using it a replacement would need to be found. cu Andreas
Bug#1076243: tcpreplay: Build-Depends on GNU autogen
On 2024-07-13 Christoph Biedl wrote: [...] > About Debian, I personally don't quite like the idea of using git > submodules for a Debian package, they are just another form of a code > copy. Otherwise, how big is this autogen story? I counted 15 build > dependencies on autogen so I would have expected some mass bug-filing. Hello Christoph, I am currently checking the build-deps and submitting bug-reports one by one. I started with tcpreplay since it has an active upstream and is not some gigantic package like cross-toolchain-base. ;-) > For example, is there a specific reason the complexity package did not > get such a bug report? This would help assessing whether it was worth > packaging cligen. Although in my opinion it was worth if even just one > package can benefit from it. From two on, I'd strongly recommend it. Well reasoned. 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#1076255: cross-toolchain-base: Unused build-dependency on GNU autogen
Source: cross-toolchain-base Version: 69 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, afaict cross-toolchain-base's build-dependency on GNU autogen is unused. I have searched for "autogen" in amd64 buildlog and the only matches besides package installation were multiple instances of | Now at patch go-testsuite.diff | : # only needed when we have changes, and currently fails with autogen 5.18 | : #cd /<>/gcc/src/fixincludes && ./genfixes | sync Which is commented and autogen 5.18 was uploaded to Debian about 11 years ago. I am submittimg this now because autogen is EOL and if you still were actually using it a replacement needs to be found. cu Andreas
Bug#1076254: gcc-arm-none-eabi: Unused build-dependency on GNU autogen
Source: gcc-arm-none-eabi Version: 15:13.2.rel1-2 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, afaict gcc-arm-none-eabi's build-dependency on GNU autogen is unused. I have searched for "autogen" in amd64 buildlog in vain and also did a test build on barriere.d.o without autogen. Perhaps this used to be required or is the b-d only required in special circumstances? cu Andreas
Bug#1076252: gcc-or1k-elf: Unused build-dependency on GNU autogen
Source: gcc-or1k-elf Version: 1.0.7 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, afaict gcc-or1k-elf's build-dependency on GNU autogen is unused. I have searched for "autogen" in amd64 buildlog in vain and also did a test build on barriere.d.o without autogen. Perhaps this used to be required or is the b-d only required in special circumstances? cu Andreas
Bug#1076129: tao-json: FTBFS: add support for loongarch64
Control: tags -1 help Hi, Am Thu, Jul 11, 2024 at 03:46:30PM +0800 schrieb zhangdandan: > Source: tao-json > Version: 0.0+git20200604.f357d72-2 > Severity: normal > Tags: patch > User: debian-loonga...@lists.debian.org > Usertags: loong64 Thanks a lot for your patch. While I currently stalled my packaging work drastically, patches have high priority. I've applied it in Git and updated it to the new upstream version. Unfortunately this version does not build for other reasons as you can see in Salsa CI[1]. Thus tagging the bug help and CC the great Debian Med team who took over lots of my packaging duties. I guess its a low hanging fruit to fix this but I currently do not have the capacity to track this down. Kind regards Andreas. PS: It would be great if the patch would be forwarded upstream once it has proven to work. When doing so asking upstr [1] https://salsa.debian.org/med-team/tao-json/-/jobs/5964128 -- https://fam-tille.de
Bug#1076250: gcc-xtensa: Unused build-dependency on GNU autogen
Source: gcc-xtensa Version: 14 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, afaict gcc-xtensa's build-dependency on GNU autogen is unused. I have searched for "autogen" in amd64 buildlog in vain and also did a test build on barriere.d.o without autogen. Perhaps this used to be required or is the b-d only required in special circumstances? cu Andreas
Bug#1076243: tcpreplay: Build-Depends on GNU autogen
On 2024-07-13 Christoph Biedl wrote: > Andreas Metzler wrote... [...] >> 2. Build-time generation from json input of option-parser and docs with >> https://gitlab.com/gnutls/cligen (python). > That bit leaves me a bit in confusion - for a build-time job I'll need > cligen via a build dependency - but AFAICS that program is not packaged > in Debian¹. Including a code copy, nope. So perhaps gnutls should ship it > as it's already in the sources there? I happen to know at least some > gnutls Debian maintainers are reading this :) [...] Hello Christoph, GnuTLS includes cligen as a GIT submodule which works very well for them. Is this also an option for tcprelay? Otherwise I can give packaging cligen as a separate source package a shot. 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#1076246: sndfile-tools: Unused build-dependency on GNU autogen
Source: sndfile-tools Version: 1.5-3 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, afaict sndfile-tools' build-dependency on GNU autogen is unused: ametzler@argenau:/tmp/sndfile-tools-1.5$ grep -ril autogen debian/control debian/copyright_hints cu Andreas
Bug#1076245: lintian-brush: hangs and when killed leaved lock in Git repository
Package: lintian-brush Version: 0.155 Severity: grave Justification: renders package unusable Hi, I'm currently do not use lintian-brush extensively currently (since I reduced my packaging work in DPL) term but *always* when using it hangs. Not even some ^C in terminal kann bring back some prompt I have to kill the process manually or close the terminal. After this some lock files are remaining in the Git repository which need to be manually removed. Latest example https://salsa.debian.org/med-team/tao-json tao-json(master) $ lintian-brush 88/153 ^C^C^C^C^C This is not only true for this specific package but for *all* packages I tried in the last couple of weeks. Kind regards Andreas. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.23.7 ii libc62.38-14 ii libgcc-s114.1.0-3 ii liblzma5 5.6.2-2 ii libpython3.11t64 3.11.9-1 ii libssl3t64 3.2.2-1 ii python3 3.12.2-1 ii python3-breezy 3.3.6-1+b1 ii python3-debian 0.1.49 ii python3-debmutate0.68 ii python3-distro-info 1.7 ii python3-dulwich 0.21.6-1+b1 ii python3-iniparse 0.5-2 ii python3-iso8601 1.0.2-1 ii python3-levenshtein 0.25.1-3 ii python3-psycopg2 2.9.9-1+b1 ii python3-pyinotify0.9.6-2 ii python3-ruamel.yaml 0.18.6+ds-3 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.12.5-1 ii python3-tqdm 4.66.4-1 ii python3-upstream-ontologist 0.1.37-1 Versions of packages lintian-brush recommends: ii debhelper 13.16 ii decopy0.2.4.8-0.1 ii dos2unix 7.5.2-1 ii gpg 2.2.43-7 ii lintian 2.117.0 ii ognibuild 0.0.20-1 ii python3-bs4 4.12.3-1 ii python3-docutils 0.20.1+dfsg-3 ii python3-lxml 5.2.1-1 ii python3-markdown 3.6-1 Versions of packages lintian-brush suggests: ii brz-debian 2.8.79 ii git-buildpackage 0.9.34 ii gnome-pkg-tools0.22.9 ii po-debconf 1.0.21+nmu1 ii postgresql-common 261 -- no debconf information
Bug#1076243: tcpreplay: Build-Depends on GNU autogen
Source: tcpreplay Version: 4.4.4-1 Severity: normal User: ametz...@debian.org Usertags: autogen-eol Good morning, tcpreplay build-depends on GNU autogen, which has reached EOL and IMHO is unlikely to be revived. The best replacement for autogen's AutoOpts part I know (but I do not know everything) is the toolchain gnutls upstream built for their conversion: 1. One-time onversion of .def to json with https://gitlab.com/dueno/parse-autogen and some handholding. 2. Build-time generation from json input of option-parser and docs with https://gitlab.com/gnutls/cligen (python). 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#1075900: Exim4 in Debian can't deliver to DANE secured Mailservers
On 2024-07-07 Wolfgang wrote: [...] > Problem occurs in sending mails to a DANE protected MX, under certain > conditions. [...] Hello, I have read through all the messages on exim-user and afaict the whole issue was diagnosed as not using DANE at all for lack of dnssec. 4cbe872a-da6f-491a-b3b5-15ba29317...@wizmail.org From: Jeremy Harris: | 12:41:19 21110 host mx06.et.lindenberg.one [85.215.77.84] MX=16 dnssec=no | ^ zovpxavwdvxo4...@chardros.imrryr.org by Viktor Dukhovni: | But does glibc strip the AD bit when processing the response? Do you | have "options trust-ad" in /etc/resolv.conf? As another datapoint lists.gentoo.org also has a '2 1 1' TLSA record and I can successfully deliver there with successfull dane certificate valdation there (CV=dane in the logline). That is with a DNS resolver that does dnssec, the respective changes to glibc resolver configuration, and on exim's side dns_dnssec_ok. 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#1076164: nvidia-cuda-toolkit: CVE-2024-0102
Source: nvidia-cuda-toolkit Version: 4.0.13-1 Severity: important Tags: security upstream X-Debbugs-Cc: Debian Security Team https://nvidia.custhelp.com/app/answers/detail/a_id/5548 CVE-2024-0102 NVIDIA CUDA Toolkit for all platforms contains a vulnerability in nvdisasm, where an attacker can cause an out-of-bounds read issue by deceiving a user into reading a malformed ELF file. A successful exploit of this vulnerability might lead to denial of service. CVE IDs Addressed Affected Products Platform or OS Affected Versions Updated Version CVE-2024-0102 NVIDIA CUDA Toolkit Windows, Linux All versions up to and including CUDA Toolkit 12.5U1CUDA Toolkit 12.6 Andreas
Bug#858970:
Hi,
On Tue, Jul 9, 2024 at 3:35 PM Russ Allbery wrote:
>
> Andreas Hasenack writes:
>
> > Heimdal's ktb5.conf manpage (with the patches applied):
>
> >Files and directories may be included by absolute path.
> > Including a directory causes all files in the directory to be included
> > as if each file had been included sep‐
> >arately, but only files whose names consist of alphanumeric,
> > hyphen, and underscore are included, though they may also end in
> > '.conf'.
>
> > Heimdal doesn't mention ordering, so it's readdir() ordering, whatever that
> > is:
>
> > +if ((d = opendir(dname)) == NULL)
> > +return errno;
> > +
> > +while ((entry = readdir(d)) != NULL) {
> > (...)
>
> readdir ordering is probably bad. I think that's essentially random on a
> lot of file systems, and I'm not sure it's even guaranteed to be stable.
> Is there any chance we could get that fixed in Heimdal before we start to
> rely on it?
I filed https://github.com/heimdal/heimdal/issues/1252 showing the problem
In heimdal, listing the directory and processing each file is done in
one function, there is no prior list of files to be ordered. MIT
kerberos creates a list first (maybe it doesn't support nesting, so
it's easier to create a list first).
Bug#858970:
Hi,
On Tue, Jul 9, 2024 at 2:23 PM Russ Allbery wrote:
>
> Andreas Hasenack writes:
>
> > If I include it via this krb5.conf:
> > [libdefaults]
> > includedir /etc/krb5.conf.d
> > default_realm = LOWTECH
>
> > default realm is LXD.
>
> > If I include it like this:
> > [libdefaults]
> > default_realm = LOWTECH
> > includedir /etc/krb5.conf.d
>
> > Then default realm is LOWTECH.
>
> Do both MIT and Heimdal use the same order (first seen wins)? I hope so,
> otherwise this is going to be tricky.
A quick test exactly like above with MIT kerberos 1.20.1 showed the
same result, i.e., first one wins.
Still on this topic, the unit tests added to heimdal also use the
include statement at the top, outside any section.
>
> > I think it's best to have the includedir at the very top, outside any
> > section. Seems to be the least surprising.
>
> I think that's right. That means that fragments will override anything in
> the base /etc/krb5.conf, which feels correct to me. We should add a
> prominent comment to the top of the default /etc/krb5.conf that explains
> this, as well as a NEWS.Debian entry.
>
> Do both MIT and Heimdal sort the fragments alphabetically before including
> them, so that there's some predictable order for which fragments override
> each other? We'll want to document the ordering.
The krb5.conf manpages document it.
MIT:
The krb5.conf file can include other files using either of the
following directives at the beginning of a line:
include FILENAME
includedir DIRNAME
FILENAME or DIRNAME should be an absolute path. The named file
or directory must exist and be readable. Including a directory
includes all files within the directory
whose names consist solely of alphanumeric characters, dashes,
or underscores. Starting in release 1.15, files with names ending in
".conf" are also included, unless
the name begins with ".". Included profile files are
syntactically independent of their parents, so each included file must
begin with a section header. Starting in
release 1.17, files are read in alphanumeric order; in previous
releases, they may be read in any order.
Heimdal's ktb5.conf manpage (with the patches applied):
Files and directories may be included by absolute path.
Including a directory causes all files in the directory to be included
as if each file had been included sep‐
arately, but only files whose names consist of alphanumeric,
hyphen, and underscore are included, though they may also end in
'.conf'.
Heimdal doesn't mention ordering, so it's readdir() ordering, whatever that is:
+if ((d = opendir(dname)) == NULL)
+return errno;
+
+while ((entry = readdir(d)) != NULL) {
(...)
MIT also does opendir/readdir, but at the end calls qsort to order the list:
https://github.com/krb5/krb5/blob/47371f6db423e7dba29afe696282ddfc0b92a81c/src/util/support/dir_filenames.c#L130
Bug#858970:
> And, to reply to another question from before, if I put the includedir > directive inside a section, for example, inside [libdefaults], that's > invalid because it expects all entries in sections to be key=pair > values: > root@o-heimdal:~# head /etc/krb5.conf -n 4 > > [libdefaults] > includedir /etc/krb5.conf.d > default_realm = LOWTECH > > root@o-heimdal:~# verify_krb5_conf > verify_krb5_conf: krb5_config_parse_file: open /root/.krb5/config: No > such file or directory > verify_krb5_conf: krb5_config_parse_file: /etc/krb5.conf:3: missing = Oh, my mistake, that was with unpatched heimdal. With patched heimdal, it allows that includedir inside a section. And indeed there are questions of ordering and overrides then, to be better understood. This config snippet: [libdefaults] default_realm = LXD If I include it via this krb5.conf: [libdefaults] includedir /etc/krb5.conf.d default_realm = LOWTECH default realm is LXD. If I include it like this: [libdefaults] default_realm = LOWTECH includedir /etc/krb5.conf.d Then default realm is LOWTECH. I think it's best to have the includedir at the very top, outside any section. Seems to be the least surprising.
Bug#858970:
At the moment, heimdal's verify_krb5_conf is already not happy with krb5.conf shipped by bin:krb5-config: # verify_krb5_conf verify_krb5_conf: krb5_config_parse_file: open /root/.krb5/config: No such file or directory verify_krb5_conf: /libdefaults/ccache_type: unknown entry verify_krb5_conf: /libdefaults/rdns: unknown entry verify_krb5_conf: /realms/1TS.ORG/kdc: Temporary failure in name resolution (kerberos.1ts.org) verify_krb5_conf: /realms/1TS.ORG/admin_server: Temporary failure in name resolution (kerberos.1ts.org) ^C (remove 1TS.ORG and try again) # verify_krb5_conf verify_krb5_conf: krb5_config_parse_file: open /root/.krb5/config: No such file or directory verify_krb5_conf: /libdefaults/ccache_type: unknown entry verify_krb5_conf: /libdefaults/rdns: unknown entry root@o-heimdal:~# echo $? 1 I can grab a ticket, though: root@o-heimdal:~# kinit andreas andreas@LOWTECH's Password: root@o-heimdal:~# But if I add the includedir line, without support in heimdal, it breaks immediately: root@o-heimdal:~# mkdir /etc/krb5.conf.d root@o-heimdal:~# sed -r -i '1 i\includedir /etc/krb5.conf.d\n' /etc/krb5.conf root@o-heimdal:~# kinit andreas kinit: krb5_parse_name_flags: unable to find realm of host o-heimdal root@o-heimdal:~# root@o-heimdal:~# head /etc/krb5.conf -n 4 includedir /etc/krb5.conf.d [libdefaults] default_realm = LOWTECH Oddly enough, verify_krb5_conf is now happier: root@o-heimdal:~# verify_krb5_conf verify_krb5_conf: krb5_config_parse_file: open /root/.krb5/config: No such file or directory verify_krb5_conf: krb5_config_parse_file: /etc/krb5.conf:1: binding before section root@o-heimdal:~# echo $? 0 This was all with the normal heimdal package, not the patched one. And, to reply to another question from before, if I put the includedir directive inside a section, for example, inside [libdefaults], that's invalid because it expects all entries in sections to be key=pair values: root@o-heimdal:~# head /etc/krb5.conf -n 4 [libdefaults] includedir /etc/krb5.conf.d default_realm = LOWTECH root@o-heimdal:~# verify_krb5_conf verify_krb5_conf: krb5_config_parse_file: open /root/.krb5/config: No such file or directory verify_krb5_conf: krb5_config_parse_file: /etc/krb5.conf:3: missing =
Bug#858970: please add /etc/krb5.conf.d
Hi,
On Tue, Jul 9, 2024 at 11:55 AM Russ Allbery wrote:
>
> Andreas Hasenack writes:
>
> > I opened #1074775[1] to backport the heimdal patches that add include
(...)
> The change is not entirely trivial, however. Here are some things that
> come to mind that we probably need a plan for how to handle:
>
> 1. For already-configured systems, should we add the include directive to
>the existing krb5.conf file? Presumably the answer is yes, or the
Presumably yes, but we have to indeed think about it. Normal dpkg conf
prompts will apply here, unless we do something (smart?) in postinst.
update: just saw the krb5-config postinst, it indeed tries to handle
many cases, and this would be another one.
>migration is going to be rather difficult. Is there a correct place in
>the krb5.conf file to add the include so that we get the correct
>semantics for whether fragments override the main file or vice versa?
The included file needs to have the section specified, and the
includedir directive lives at the top without a section of its own,
that's how I have seen it being used so far (in MIT kerberos).
>Are we going to break anyone's system by suddenly including the
>fragments? We'll at least need a NEWS.Debian entry; maybe we also need
>a debconf warning in some situations?
There are two breakage possibliities here:
a) It's quite possible some users already have a
/etc/krb5.conf.d/foo.conf file that has been ignored so far, and will
now be included. That could lead to unexpected behavior, yes.
b) if old heimdal is installed, and confronted with a krb5.conf that
has a includedir line outside of a section (like, first line), it will
fail to parse the file and break ("binding before section" error).
That's what I've seen in my testing. I haven't tried inclusions from
other parts of krb5.conf.
> 2. With the current logic, it's not possible to guarantee that the include
>directive has been added, since krb5-config by design doesn't touch a
>krb5.conf file that's a symlink. That means it's possible to have the
>latest version of everything installed and still not respect the
>configuration fragments. Do we just live with this? I'm nervous about
We could grep for include/includedir in krb5.conf, be it a symlink or
not? What is the scenario where /etc/krb5.conf is a symlink, are some
sites doing that?
>moving critical configuration into a fragment when we can't guarantee
>that the fragment is loaded. In the libpam-krb5 case, this can lead to
>a security vulnerability.
I see, so for example you will want to create a configuration snippet
to address #756880, but aren't sure if that file will even be included
because krb5.conf might not have the includedir directive.
Note we can now also include specific files, without it having to be a
whole directory, if this helps.
>
> 3. How do dependencies work? This change to krb5-config will require a
>particular version of Heimdal, since earlier versions don't support
>include (and will this break Kerberos entirely if the include is
>present?). But krb5-config can't depend on any specific Kerberos
>implementation, so I don't know how to represent this as a dependency.
I was thinking about a breaks, as in, new krb5-config would break old heimdal.
>And what dependency should a package that wants to use included
>fragments have to ensure that those included fragments are loaded?
Some virtual provides perhaps? Too much?
Bug#1072277: kleopatra: Searches for libassuan with libassuan-config
Control: tags 1 fixed-upstream On 2024-05-31 Andreas Metzler wrote: > Source: kleopatra > Version: 4:22.12.3-2 > Severity: important > User: ametz...@debian.org > Usertags: libassuan-config-removal > kleopatra relies on libassuan-config to locate libassuan. > libassuan-config is scheduled for removal and will be dropped in > the next major libassuan release. Please use pkg-config/pkgconf instead. [...] This seems to be fixed upstream. https://invent.kde.org/pim/kleopatra/-/commit/a17fc1b29d7c03a8b9e84f0e4b849fb9f2ebbc57 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#1076013: purple-lurch: diff for NMU version 0.7.0-2.1
Package: purple-lurch
Version: 0.7.0-2
Severity: normal
Tags: patch pending
[Replace XX with correct value]
Dear maintainer,
I've prepared an NMU for purple-lurch (versioned as 0.7.0-2.1) and
uploaded it to sid.
Regards.
--
`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 purple-lurch-0.7.0/debian/changelog purple-lurch-0.7.0/debian/changelog
--- purple-lurch-0.7.0/debian/changelog 2023-07-13 11:30:41.0 +0200
+++ purple-lurch-0.7.0/debian/changelog 2024-07-09 14:27:06.0 +0200
@@ -1,3 +1,11 @@
+purple-lurch (0.7.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add missing prototype to fix ftbfs. Closes: #1066710
+ * Use pkg-config to locate libgcrypt. Closes: #1071952
+
+ -- Andreas Metzler Tue, 09 Jul 2024 14:27:06 +0200
+
purple-lurch (0.7.0-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru purple-lurch-0.7.0/debian/patches/add_missing_prototype.diff purple-lurch-0.7.0/debian/patches/add_missing_prototype.diff
--- purple-lurch-0.7.0/debian/patches/add_missing_prototype.diff 1970-01-01 01:00:00.0 +0100
+++ purple-lurch-0.7.0/debian/patches/add_missing_prototype.diff 2024-07-09 14:09:04.0 +0200
@@ -0,0 +1,47 @@
+Description:
+ TODO: Put a short summary on the line above and replace this paragraph
+ with a longer explanation of this change. Complete the meta-information
+ with other relevant fields (see below for details). To make it easier, the
+ information below has been extracted from the changelog. Adjust it or drop
+ it.
+ .
+ purple-lurch (0.7.0-2.1) UNRELEASED; urgency=medium
+ .
+ * Non-maintainer upload.
+ * Add missing prototype to fix ftbfs. Closes: #1066710
+Author: Andreas Metzler
+Bug-Debian: https://bugs.debian.org/1066710
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: (upstream|backport|vendor|other), (|commit:)
+Bug:
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: (no|not-needed|)
+Applied-Upstream: , (|commit:)
+Reviewed-By:
+Last-Update: 2024-07-09
+
+--- purple-lurch-0.7.0.orig/test/test_lurch_util.c
purple-lurch-0.7.0/test/test_lurch_util.c
+@@ -9,6 +9,9 @@
+ #include "../src/lurch.h"
+ #include "../src/lurch_util.h"
+
++/* declared in src/lurch_util.c */
++extern void lurch_util_axc_log_func(int level, const char * msg, size_t len, void * user_data);
++
+ void __wrap_purple_debug_error(const char * category, const char * format, ...) {
+ function_called();
+ }
+@@ -213,4 +216,4 @@ int main(void) {
+ };
+
+ return cmocka_run_group_tests_name("lurch_util", tests, NULL, NULL);
+-}
+\ No newline at end of file
++}
diff -Nru purple-lurch-0.7.0/debian/patches/libgcrypt-pkgconfig.diff purple-lurch-0.7.0/debian/patches/libgcrypt-pkgconfig.diff
--- purple-lurch-0.7.0/debian/patches/libgcrypt-pkgconfig.diff 1970-01-01 01:00:00.0 +0100
+++ purple-lurch-0.7.0/debian/patches/libgcrypt-pkgconfig.diff 2024-07-09 14:09:04.0 +0200
@@ -0,0 +1,32 @@
+Description: Use pkg-config to locate libgcrypt
+Author: Andreas Metzler
+Bug-Debian: https://bugs.debian.org/1071952
+Last-Update: 2024-07-09
+
+--- a/Makefile
b/Makefile
+@@ -2,11 +2,10 @@
+ #
+ CC ?= gcc
+
+ PKG_CONFIG ?= pkg-config
+ XML2_CONFIG ?= xml2-config
+-LIBGCRYPT_CONFIG ?= libgcrypt-config
+
+ MKDIR = mkdir
+ MKDIR_P = mkdir -p
+ INSTALL = install
+ INSTALL_LIB = $(INSTALL) -m 755
+@@ -36,11 +35,11 @@ LIBSIGNAL_PROTOCOL_CFLAGS = $(shell $(PK
+ LIBSIGNAL_PROTOCOL_LDFLAGS = $(shell $(PKG_CONFIG) --cflags libsignal-protocol-c)
+
+ XML2_CFLAGS ?= $(shell $(XML2_CONFIG) --cflags)
+ XML2_LDFLAGS ?= $(shell $(XML2_CONFIG) --libs)
+
+-LIBGCRYPT_LDFLAGS ?= $(shell $(LIBGCRYPT_CONFIG) --libs)
++LIBGCRYPT_LDFLAGS ?= $(shell $(PKG_CONFIG) --libs libgcrypt)
+
+ USE_DYNAMIC_LIBS=libsignal-protocol-c libaxc libomemo
+ USE_DYNAMIC_LIBS:=$(shell pkg-config --exists $(USE_DYNAMIC_LIBS) && \
+ echo '$(USE_DYNAMIC_LIBS)')
+
diff -Nru purple-lurch-0.7.0/debian/patches/series purple-lurch-0.7.0/debian/patches/series
--- purple-lurch-0.7.0/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ purple-lurch-0.7.0/debian/patches/series 2024-07-09 14:09:04.0 +0200
@@ -0,0 +1,2 @@
+add_missing_prototype.diff
+libgcrypt-pkgconfig.diff
signature.asc
Description: PGP signature
Bug#858970:
I opened #1074775[1] to backport the heimdal patches that add include and includedir support, filed a couple of salsa PRs[2][3] with tests, and they were merged. Once there is a new upload of heimdal, we can consider making this change in kerberos-configs then. What do you think? 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074775 2. https://salsa.debian.org/debian/heimdal/-/merge_requests/3 3. https://salsa.debian.org/debian/heimdal/-/merge_requests/4
Bug#1076012: libxslt: diff for NMU version 1.1.35-1.1
Package: libxslt Version: 1.1.35-1 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for libxslt (versioned as 1.1.35-1.1) and uploaded it to sid. Regards 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 libxslt-1.1.35/debian/changelog libxslt-1.1.35/debian/changelog --- libxslt-1.1.35/debian/changelog 2022-07-15 15:29:07.0 +0200 +++ libxslt-1.1.35/debian/changelog 2024-07-09 13:56:17.0 +0200 @@ -1,3 +1,11 @@ +libxslt (1.1.35-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add missing #include to fix FTFBS. Closes: #1073312 + * Use pkg-config to locate libgcrypt. Closes: #1071937 + + -- Andreas Metzler Tue, 09 Jul 2024 13:56:17 +0200 + libxslt (1.1.35-1) unstable; urgency=medium * Team upload. diff -Nru libxslt-1.1.35/debian/patches/0010_missing_include.diff libxslt-1.1.35/debian/patches/0010_missing_include.diff --- libxslt-1.1.35/debian/patches/0010_missing_include.diff 1970-01-01 01:00:00.0 +0100 +++ libxslt-1.1.35/debian/patches/0010_missing_include.diff 2024-07-09 13:32:41.0 +0200 @@ -0,0 +1,34 @@ +Description: Add missing #include to fix FTFBS. +Author: Andreas Metzler +Bug-Debian: https://bugs.debian.org/1073312 +Applied-Upstream: 1.39, https://gitlab.gnome.org/GNOME/libxslt/-/commit/b7f824f613a0da3e6cefc5dc558ff597eb6545b4 +Last-Update: 2024-07-09 + +--- a/libxslt/extensions.c b/libxslt/extensions.c +@@ -10,10 +10,11 @@ + */ + + #define IN_LIBXSLT + #include "libxslt.h" + ++#include + #include + #include + + #include + #include +--- a/libexslt/date.c b/libexslt/date.c +@@ -36,10 +36,11 @@ + #include + #include + + #include "exslt.h" + ++#include + #include + #include + + #ifdef HAVE_ERRNO_H + #include diff -Nru libxslt-1.1.35/debian/patches/0011_libgcrypt_pkgconfig.diff libxslt-1.1.35/debian/patches/0011_libgcrypt_pkgconfig.diff --- libxslt-1.1.35/debian/patches/0011_libgcrypt_pkgconfig.diff 1970-01-01 01:00:00.0 +0100 +++ libxslt-1.1.35/debian/patches/0011_libgcrypt_pkgconfig.diff 2024-07-09 13:56:17.0 +0200 @@ -0,0 +1,42 @@ +Description: Use pkg-config to locate libgcrypt. +Author: Andreas Metzler +Bug-Debian: https://bugs.debian.org/1071937 +Last-Update: 2024-07-09 + +--- a/configure.ac b/configure.ac +@@ -368,31 +368,16 @@ case $host in + dnl crypto libraries + WITH_CRYPTO=1 + CRYPTO_TESTDIR=crypto + ;; + *) +-AC_PATH_TOOL(LIBGCRYPT_CONFIG, libgcrypt-config, no) +-if test "$LIBGCRYPT_CONFIG" != "no" ; then +- LIBGCRYPT_VERSION=`$LIBGCRYPT_CONFIG --version` +- if test VERSION_TO_NUMBER(echo $LIBGCRYPT_VERSION) -lt VERSION_TO_NUMBER(echo "1.1.42") +- then +-LIBGCRYPT_CFLAGS="" +-LIBGCRYPT_LIBS="" +-echo 'gcrypt library version < 1.1.42 - Crypto extensions will not be available.' +- else +-LIBGCRYPT_CFLAGS=`$LIBGCRYPT_CONFIG $libgcrypt_config_args --cflags` +-LIBGCRYPT_LIBS=`$LIBGCRYPT_CONFIG $libgcrypt_config_args --libs` ++PKG_CHECK_MODULES(LIBGCRYPT, [libgcrypt >= 1.1.41], + AC_DEFINE(HAVE_GCRYPT, 1, [Define if gcrypt library is available.]) + echo 'Crypto extensions will be available.' + WITH_CRYPTO=1 +-CRYPTO_TESTDIR=crypto +- fi +-else +- LIBGCRYPT_CFLAGS="" +- LIBGCRYPT_LIBS="" +- echo 'Crypto extensions will not be available. Install libgcrypt and reconfigure to make available.' +-fi ++CRYPTO_TESTDIR=crypto, ++ echo 'Crypto extensions will not be available. Install libgcrypt >=1.1.41 and reconfigure to make available.') + esac + fi + AC_SUBST(WITH_CRYPTO) + AC_SUBST(CRYPTO_TESTDIR) + AC_SUBST(LIBGCRYPT_CFLAGS) diff -Nru libxslt-1.1.35/debian/patches/series libxslt-1.1.35/debian/patches/series --- libxslt-1.1.35/debian/patches/series 2022-04-09 14:38:57.0 +0200 +++ libxslt-1.1.35/debian/patches/series 2024-07-09 13:56:17.0 +0200 @@ -3,3 +3,5 @@ 0003-remove-plugin-in-xslt-config.patch 0004-do-not-clean-manpage.patch 0005-Drop-libdir-and-static-linking-information-from-xslt.patch +0010_missing_include.diff +0011_libgcrypt_pkgconfig.diff signature.asc Description: PGP signature
Bug#1071933: libccrtp: diff for NMU version 2.0.9-4.1
Control: tags 1071933 + patch
Control: tags 1071933 + pending
Dear maintainer,
I've prepared an NMU for libccrtp (versioned as 2.0.9-4.1) and
uploaded it to unstable.
Regards.
diff -Nru libccrtp-2.0.9/debian/changelog libccrtp-2.0.9/debian/changelog
--- libccrtp-2.0.9/debian/changelog 2024-05-03 20:35:11.0 +0200
+++ libccrtp-2.0.9/debian/changelog 2024-07-09 13:14:07.0 +0200
@@ -1,3 +1,12 @@
+libccrtp (2.0.9-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Delete outdated (and renamed) copy of libgcrypt.m4 and use upstream macro
+instead to fix FTBFS against libgcrypt without libgcrypt-config.
+Closes: #1071933
+
+ -- Andreas Metzler Tue, 09 Jul 2024 13:14:07 +0200
+
libccrtp (2.0.9-4) unstable; urgency=medium
* Team upload.
diff -Nru libccrtp-2.0.9/debian/patches/15_delete_outdated_libgcrypt_m4_macro.diff libccrtp-2.0.9/debian/patches/15_delete_outdated_libgcrypt_m4_macro.diff
--- libccrtp-2.0.9/debian/patches/15_delete_outdated_libgcrypt_m4_macro.diff 1970-01-01 01:00:00.0 +0100
+++ libccrtp-2.0.9/debian/patches/15_delete_outdated_libgcrypt_m4_macro.diff 2024-07-09 13:14:07.0 +0200
@@ -0,0 +1,117 @@
+Description: Delete outdated (and renamed) copy of libgcrypt.m4 to fix FTBFS
+ against libgcrypt without libgcrypt-config.
+Author: Andreas Metzler
+Bug-Debian: https://bugs.debian.org/1071933
+Last-Update: 2024-07-09
+
+--- libccrtp-2.0.9.orig/m4/libgcrypt_local.m4
/dev/null
+@@ -1,108 +0,0 @@
+-dnl Autoconf macros for libgcrypt
+-dnl Copyright (C) 2002, 2004 Free Software Foundation, Inc.
+-dnl
+-dnl This file is free software; as a special exception the author gives
+-dnl unlimited permission to copy and/or distribute it, with or without
+-dnl modifications, as long as this notice is preserved.
+-dnl
+-dnl This file is distributed in the hope that it will be useful, but
+-dnl WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+-dnl implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+-
+-
+-dnl AM_PATH_LIBGCRYPT([MINIMUM-VERSION,
+-dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
+-dnl Test for libgcrypt and define LIBGCRYPT_CFLAGS and LIBGCRYPT_LIBS.
+-dnl MINIMUN-VERSION is a string with the version number optionalliy prefixed
+-dnl with the API version to also check the API compatibility. Example:
+-dnl a MINIMUN-VERSION of 1:1.2.5 won't pass the test unless the installed
+-dnl version of libgcrypt is at least 1.2.5 *and* the API number is 1. Using
+-dnl this features allows one to prevent build against newer versions of libgcrypt
+-dnl with a changed API.
+-dnl
+-AC_DEFUN([AM_PATH_LIBGCRYPT_CCRTP],
+-[ AC_ARG_WITH(libgcrypt-prefix,
+-AC_HELP_STRING([--with-libgcrypt-prefix=PFX],
+- [prefix where LIBGCRYPT is installed (optional)]),
+- libgcrypt_config_prefix="$withval", libgcrypt_config_prefix="")
+- if test x$libgcrypt_config_prefix != x ; then
+- if test x${LIBGCRYPT_CONFIG+set} != xset ; then
+-LIBGCRYPT_CONFIG=$libgcrypt_config_prefix/bin/libgcrypt-config
+- fi
+- fi
+-
+- AC_PATH_PROG(LIBGCRYPT_CONFIG, libgcrypt-config, no)
+- tmp=ifelse([$1], ,1:1.2.0,$1)
+- if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
+- req_libgcrypt_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
+- min_libgcrypt_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
+- else
+- req_libgcrypt_api=0
+- min_libgcrypt_version="$tmp"
+- fi
+-
+- AC_MSG_CHECKING(for LIBGCRYPT - version >= $min_libgcrypt_version)
+- ok=no
+- if test "$LIBGCRYPT_CONFIG" != "no" ; then
+-req_major=`echo $min_libgcrypt_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
+-req_minor=`echo $min_libgcrypt_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
+-req_micro=`echo $min_libgcrypt_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
+-libgcrypt_config_version=`$LIBGCRYPT_CONFIG --version`
+-major=`echo $libgcrypt_config_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
+-minor=`echo $libgcrypt_config_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
+-micro=`echo $libgcrypt_config_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
+-if test "$major" -gt "$req_major"; then
+-ok=yes
+-else
+-if test "$major" -eq "$req_major"; then
+-if test "$minor" -gt "$req_minor"; then
+- ok=yes
+-else
+- if test "$minor" -eq "$req_minor"; then
+- if test "$micro" -ge "$req_micro"; then
+- ok=yes
+-
Bug#1075943: Bug#1075945: opencl-clang-15: Please upgrade to llvm-toolchain-18
Control: tag -1 wontfix On 08/07/2024 09.14, Sylvestre Ledru wrote: Source: opencl-clang-15 As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -18. We already have opencl-clang-18 and spirv-llvm-translator-18 for that. This package depends on 15. given the -15 in the title, you are following upstream versions too. Maybe ask for a removal of opencl-clang-15 Once llvm-toolchain-15 is ready to be removed, opencl-clang-15 and spirv-llvm-translator-15 should be removed with it. Andreas
Bug#1070905: collectd: diff for NMU version 5.12.0-18.1
Control: tags 1070905 + patch Control: tags 1070905 + pending Dear maintainer, I've prepared an NMU for collectd (versioned as 5.12.0-18.1) and uploaded it to unstable. Regards Andreas diff -Nru collectd-5.12.0/debian/changelog collectd-5.12.0/debian/changelog --- collectd-5.12.0/debian/changelog 2024-04-20 00:49:01.0 +0200 +++ collectd-5.12.0/debian/changelog 2024-07-07 18:42:43.0 +0200 @@ -1,3 +1,12 @@ +collectd (5.12.0-18.1) unstable; urgency=medium + + * Non-maintainer upload. + * Invoke ./configure with --with-libgcrypt=/usr GCRYPT_LIBS=-lgcrypt +to sidestep ./configure's reliance on libgcrypt-config to locate +libgcrypt. Closes: #1070905 + + -- Andreas Metzler Sun, 07 Jul 2024 18:42:43 +0200 + collectd (5.12.0-18) unstable; urgency=medium * [e3c9674] add .gitignore to ignore swp files diff -Nru collectd-5.12.0/debian/.gitignore collectd-5.12.0/debian/.gitignore --- collectd-5.12.0/debian/.gitignore 2024-04-20 00:49:01.0 +0200 +++ collectd-5.12.0/debian/.gitignore 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -*.swp diff -Nru collectd-5.12.0/debian/rules collectd-5.12.0/debian/rules --- collectd-5.12.0/debian/rules 2024-04-20 00:49:01.0 +0200 +++ collectd-5.12.0/debian/rules 2024-07-07 18:42:43.0 +0200 @@ -57,7 +57,9 @@ --without-libstatgrab \ --disable-static \ --disable-silent-rules \ - --enable-all-plugins + --enable-all-plugins \ + --with-libgcrypt=/usr \ + GCRYPT_LIBS=-lgcrypt # java doesn't link on i386. (see blocking bug for #1057712) ifeq ($(DEB_HOST_ARCH),i386) signature.asc Description: PGP signature
Bug#1071951: poldi: diff for NMU version 0.4.2+git20161115.553060d-1.4
Control: tags 1071951 + pending
Dear maintainer,
I've prepared an NMU for poldi (versioned as 0.4.2+git20161115.553060d-1.4) and
uploaded it to sid. Please feel free to tell me if I
should delay it longer.
Regards.
--
`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 poldi-0.4.2+git20161115.553060d/debian/changelog poldi-0.4.2+git20161115.553060d/debian/changelog
--- poldi-0.4.2+git20161115.553060d/debian/changelog 2024-05-25 01:20:00.0 +0200
+++ poldi-0.4.2+git20161115.553060d/debian/changelog 2024-07-07 16:03:11.0 +0200
@@ -1,3 +1,11 @@
+poldi (0.4.2+git20161115.553060d-1.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Delete outdated local copy of libgcrypt.m4 which relies on
+libgcrypt-config. (Closes: #1071951)
+
+ -- Andreas Metzler Sun, 07 Jul 2024 16:03:11 +0200
+
poldi (0.4.2+git20161115.553060d-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru poldi-0.4.2+git20161115.553060d/debian/patches/05-delete-outdated-libgcrypt.m4.diff poldi-0.4.2+git20161115.553060d/debian/patches/05-delete-outdated-libgcrypt.m4.diff
--- poldi-0.4.2+git20161115.553060d/debian/patches/05-delete-outdated-libgcrypt.m4.diff 1970-01-01 01:00:00.0 +0100
+++ poldi-0.4.2+git20161115.553060d/debian/patches/05-delete-outdated-libgcrypt.m4.diff 2024-07-07 16:03:05.0 +0200
@@ -0,0 +1,116 @@
+Description: Delete outdated local copy of libgcrypt.m4 which relies on libgcrypt-config.
+Author: Andreas Metzler
+Bug-Debian: https://bugs.debian.org/1071951
+Last-Update: 2024-07-07
+
+--- poldi-0.4.2+git20161115.553060d.orig/m4/libgcrypt.m4
/dev/null
+@@ -1,108 +0,0 @@
+-dnl Autoconf macros for libgcrypt
+-dnl Copyright (C) 2002, 2004 Free Software Foundation, Inc.
+-dnl
+-dnl This file is free software; as a special exception the author gives
+-dnl unlimited permission to copy and/or distribute it, with or without
+-dnl modifications, as long as this notice is preserved.
+-dnl
+-dnl This file is distributed in the hope that it will be useful, but
+-dnl WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+-dnl implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+-
+-
+-dnl AM_PATH_LIBGCRYPT([MINIMUM-VERSION,
+-dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
+-dnl Test for libgcrypt and define LIBGCRYPT_CFLAGS and LIBGCRYPT_LIBS.
+-dnl MINIMUN-VERSION is a string with the version number optionalliy prefixed
+-dnl with the API version to also check the API compatibility. Example:
+-dnl a MINIMUN-VERSION of 1:1.2.5 won't pass the test unless the installed
+-dnl version of libgcrypt is at least 1.2.5 *and* the API number is 1. Using
+-dnl this features allows to prevent build against newer versions of libgcrypt
+-dnl with a changed API.
+-dnl
+-AC_DEFUN([AM_PATH_LIBGCRYPT],
+-[ AC_ARG_WITH(libgcrypt-prefix,
+-AC_HELP_STRING([--with-libgcrypt-prefix=PFX],
+- [prefix where LIBGCRYPT is installed (optional)]),
+- libgcrypt_config_prefix="$withval", libgcrypt_config_prefix="")
+- if test x$libgcrypt_config_prefix != x ; then
+- if test x${LIBGCRYPT_CONFIG+set} != xset ; then
+-LIBGCRYPT_CONFIG=$libgcrypt_config_prefix/bin/libgcrypt-config
+- fi
+- fi
+-
+- AC_PATH_PROG(LIBGCRYPT_CONFIG, libgcrypt-config, no)
+- tmp=ifelse([$1], ,1:1.2.0,$1)
+- if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
+- req_libgcrypt_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
+- min_libgcrypt_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
+- else
+- req_libgcrypt_api=0
+- min_libgcrypt_version="$tmp"
+- fi
+-
+- AC_MSG_CHECKING(for LIBGCRYPT - version >= $min_libgcrypt_version)
+- ok=no
+- if test "$LIBGCRYPT_CONFIG" != "no" ; then
+-req_major=`echo $min_libgcrypt_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
+-req_minor=`echo $min_libgcrypt_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
+-req_micro=`echo $min_libgcrypt_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
+-libgcrypt_config_version=`$LIBGCRYPT_CONFIG --version`
+-major=`echo $libgcrypt_config_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
+-minor=`echo $libgcrypt_config_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
+-micro=`echo $libgcrypt_config_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
+-if test "$major" -gt "$req_major"; then
+-ok=yes
+-else
+-if test "$major" -eq "$req_major"; then
+-if test "$minor" -gt "$req_minor"; then
+-
Bug#1071862: gfsecret: diff for NMU version 0.5.0-2.1
Control: tags 1071862 + pending
Dear maintainer,
I've prepared an NMU for gfsecret (versioned as 0.5.0-2.1) and
uploaded it to sid.
Regards.
diff -Nru gfsecret-0.5.0/debian/changelog gfsecret-0.5.0/debian/changelog
--- gfsecret-0.5.0/debian/changelog 2023-12-03 16:20:38.0 +0100
+++ gfsecret-0.5.0/debian/changelog 2024-07-07 15:51:49.0 +0200
@@ -1,3 +1,11 @@
+gfsecret (0.5.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Delete outdated copy of libgcrypt.m4 which requires libgcrypt-config.
+Closes: #1071862
+
+ -- Andreas Metzler Sun, 07 Jul 2024 15:51:49 +0200
+
gfsecret (0.5.0-2) unstable; urgency=medium
* debian/control: Bump Standards-Version to 4.6.2 (no changes needed)
diff -Nru gfsecret-0.5.0/debian/patches/0003-Delete-outdated-libgcrypt.m4.diff gfsecret-0.5.0/debian/patches/0003-Delete-outdated-libgcrypt.m4.diff
--- gfsecret-0.5.0/debian/patches/0003-Delete-outdated-libgcrypt.m4.diff 1970-01-01 01:00:00.0 +0100
+++ gfsecret-0.5.0/debian/patches/0003-Delete-outdated-libgcrypt.m4.diff 2024-07-07 15:51:49.0 +0200
@@ -0,0 +1,175 @@
+Description: Delete outdated libgcrypt.m4 which requires libgcrypt-config.
+Author: Andreas Metzler
+Bug-Debian: https://bugs.debian.org/1071862
+Last-Update: 2024-07-07
+
+--- gfsecret-0.5.0.orig/m4/libgcrypt.m4
/dev/null
+@@ -1,167 +0,0 @@
+-# libgcrypt.m4 - Autoconf macros to detect libgcrypt
+-# Copyright (C) 2002, 2003, 2004, 2011, 2014, 2018 g10 Code GmbH
+-#
+-# This file is free software; as a special exception the author gives
+-# unlimited permission to copy and/or distribute it, with or without
+-# modifications, as long as this notice is preserved.
+-#
+-# This file is distributed in the hope that it will be useful, but
+-# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+-# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+-#
+-# Last-changed: 2018-11-13
+-
+-
+-dnl AM_PATH_LIBGCRYPT([MINIMUM-VERSION,
+-dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
+-dnl Test for libgcrypt and define LIBGCRYPT_CFLAGS and LIBGCRYPT_LIBS.
+-dnl MINIMUN-VERSION is a string with the version number optionalliy prefixed
+-dnl with the API version to also check the API compatibility. Example:
+-dnl a MINIMUN-VERSION of 1:1.2.5 won't pass the test unless the installed
+-dnl version of libgcrypt is at least 1.2.5 *and* the API number is 1. Using
+-dnl this features allows to prevent build against newer versions of libgcrypt
+-dnl with a changed API.
+-dnl
+-dnl If a prefix option is not used, the config script is first
+-dnl searched in $SYSROOT/bin and then along $PATH. If the used
+-dnl config script does not match the host specification the script
+-dnl is added to the gpg_config_script_warn variable.
+-dnl
+-AC_DEFUN([AM_PATH_LIBGCRYPT],
+-[ AC_REQUIRE([AC_CANONICAL_HOST])
+- AC_ARG_WITH(libgcrypt-prefix,
+-AC_HELP_STRING([--with-libgcrypt-prefix=PFX],
+- [prefix where LIBGCRYPT is installed (optional)]),
+- libgcrypt_config_prefix="$withval", libgcrypt_config_prefix="")
+- if test x"${LIBGCRYPT_CONFIG}" = x ; then
+- if test x"${libgcrypt_config_prefix}" != x ; then
+-LIBGCRYPT_CONFIG="${libgcrypt_config_prefix}/bin/libgcrypt-config"
+- fi
+- fi
+-
+- use_gpgrt_config=""
+- if test x"${LIBGCRYPT_CONFIG}" = x -a x"$GPGRT_CONFIG" != x -a "$GPGRT_CONFIG" != "no"; then
+-if $GPGRT_CONFIG libgcrypt --exists; then
+- LIBGCRYPT_CONFIG="$GPGRT_CONFIG libgcrypt"
+- AC_MSG_NOTICE([Use gpgrt-config as libgcrypt-config])
+- use_gpgrt_config=yes
+-fi
+- fi
+- if test -z "$use_gpgrt_config"; then
+-if test x"${LIBGCRYPT_CONFIG}" = x ; then
+- case "${SYSROOT}" in
+- /*)
+- if test -x "${SYSROOT}/bin/libgcrypt-config" ; then
+- LIBGCRYPT_CONFIG="${SYSROOT}/bin/libgcrypt-config"
+- fi
+- ;;
+- '')
+- ;;
+- *)
+- AC_MSG_WARN([Ignoring \$SYSROOT as it is not an absolute path.])
+- ;;
+- esac
+-fi
+-AC_PATH_PROG(LIBGCRYPT_CONFIG, libgcrypt-config, no)
+- fi
+-
+- tmp=ifelse([$1], ,1:1.2.0,$1)
+- if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
+- req_libgcrypt_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
+- min_libgcrypt_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
+- else
+- req_libgcrypt_api=0
+- min_libgcrypt_version="$tmp"
+- fi
+-
+- AC_MSG_CHECKING(for LIBGCRYPT - version >= $min_libgcrypt_version)
+- ok=no
+- if test "$LIBGCRYPT_CONFIG" != "no" ; then
+-req_major=`echo $min_libgcrypt_version | \
+- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
+-r
