Bug#1072816: sploitscan: Configuration files installed in Python modules directory
Hi Nilson, I did not see your answer earlier since I was not subscribed to this bug (I am now). I am sorry for that. >> I also noticed that local changes in report_template.html are not >> preserved on package upgrades as required by Debian Policy 10.7.3. > To avoid mistaken corrections, could you clarify this point with a > practical example? Luckily Debian tooling comes to your help. dpkg will take care of it for all files installed below /etc. Thus if you change sploitscan packaging to install all configuration files under /etc/sploitscan, dpkg will do the rest and make sure local changes are preserved on package upgrades. You can find more information on this topic (including more complicated situations) on [0]. >> . Looking at the sploitscan code [1], I suppose that the link >> /usr/lib/python3/dist-packages/sploitscan/config.json -> >> /etc/sploitscan/config.json >> is not necessary (although I have not tested this). > > Will this answer your question? > https://github.com/xaitax/SploitScan/issues/23 This confirms what I saw in the code. If you have further questions, do not hesitate to ask. Best regards, Peter [0] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html
Bug#1072816: sploitscan: Configuration files installed in Python modules directory
Control: reopen -1 On 2024-06-08 12:44:25, Peter Wienemann wrote: sploitscan installs configuration files in the system Python modules directory: /usr/lib/python3/dist-packages/sploitscan/templates/report_template.html /usr/lib/python3/dist-packages/sploitscan/config.json As per Debian Policy 10.7.2 configuration files must reside in /etc (or in case of multiple configuration files it is suggested to put them in a subdirectory named after the package). Dear Maintainer, in my opinion version 0.9.1-3 does not provide a proper fix for the above issue. Now the situation looks like this: /usr/lib/python3/dist-packages/sploitscan/templates/report_template.html -> ../../../../../share/doc/sploitscan/templates/report_template.html /usr/lib/python3/dist-packages/sploitscan/config.json -> /etc/sploitscan/config.json From my point of view moving the report template (report_template.html) to the documentation directory (/usr/share/doc/sploitscan) is inappropriate. Putting example configuration files under /usr/share/doc/sploitscan is fine but putting a file that controls the behavior of the program under /usr/share/doc/sploitscan violates Debian Policy. I think this file is a configuration file in the sense of Debian Policy 10.7.1 rather than documentation and therefore must go into /etc or a subdirectory thereof. It seems that upstream has even arranged to put this file into this location [0]. I also noticed that local changes in report_template.html are not preserved on package upgrades as required by Debian Policy 10.7.3. In addition I found two minor issues: 1. Looking at the sploitscan code [1], I suppose that the link /usr/lib/python3/dist-packages/sploitscan/config.json -> /etc/sploitscan/config.json is not necessary (although I have not tested this). 2. The changelog entry closing this bug -- debian/sploitscan.install: Files moved to usr/share (Closes: #1072816) -- and the corresponding commit message [2] do not properly describe the actual change being performed. The change includes moving only a single file to usr/share, it moves another file to etc/sploitscan and in addition it removes the installation of yet another file. Best regards, Peter [0] https://salsa.debian.org/pkg-security-team/sploitscan/-/blob/605deb3647c2c43315e0cd6e83f447bd7fab35c2/sploitscan/sploitscan.py#L620 [1] https://salsa.debian.org/pkg-security-team/sploitscan/-/blob/605deb3647c2c43315e0cd6e83f447bd7fab35c2/sploitscan/sploitscan.py#L412 [2] https://salsa.debian.org/pkg-security-team/sploitscan/-/commit/ce316a01edd1bb6449424d3ad0227a59e07a7528
Bug#1072816: sploitscan: Configuration files installed in Python modules directory
Package: sploitscan Version: 0.9.1-1 Severity: serious Hi, sploitscan installs configuration files in the system Python modules directory: /usr/lib/python3/dist-packages/sploitscan/templates/report_template.html /usr/lib/python3/dist-packages/sploitscan/config.json As per Debian Policy 10.7.2 configuration files must reside in /etc (or in case of multiple configuration files it is suggested to put them in a subdirectory named after the package). Best regards, Peter
Bug#1060573: nitrokey-app: Please switch Build-Depends to systemd-dev
Hi, I looked into this issue and it seems to me that the build dependency on udev is outdated since handling udev rules was migrated to libnitrokey (see [0]). Therefore I think that an easy fix for this issue is to remove the build dependency on udev. Best regards, Peter [0] https://github.com/Nitrokey/nitrokey-app/commit/8b9480cae1dc5983a1b1e581b2de084cc08e3733
Bug#1067912: nitrokey-app: Update Build-Depends for the time64 library renames
Hi, I looked into this issue and it seems to me that the build dependency on libqt5concurrent5 is not necessary since it is already covered by qtbase5-dev. Thus I think that an easy fix for this issue is to remove libqt5concurrent5 from the build dependencies. Best regards, Peter
Bug#1067010: libsquashfuse-dev: Incompatible pointer types on 32-bit architectures
Package: libsquashfuse-dev
Version: 0.5.0-2
Severity: serious
Tags: ftbfs fixed-upstream
Affects: src:charliecloud
Dear Maintainer,
squashfuse suffers from an incompatible pointer type issue on 32-bit
architectures. Checking the latest build logs for armel, armhf and
i386 ([0], [1], [2]) one finds the following warning:
ll_main.c: In function ‘main’:
ll_main.c:164:41: warning: assignment to ‘void (*)(struct fuse_req *,
fuse_ino_t, uint64_t)’ {aka ‘void (*)(struct fuse_req *, long long unsigned
int, long long unsigned int)’} from incompatible pointer type ‘void (*)(struct
fuse_req *, fuse_ino_t, long unsigned int)’ {aka ‘void (*)(struct fuse_req *,
long long unsigned int, long unsigned int)’} [-Wincompatible-pointer-types]
164 | sqfs_ll_ops.forget = sqfs_ll_op_forget;
| ^
This incompatibility leads to an FTBFS issue for the charliecloud
package on 32-bit architectures (see e. g. [3]) since it is built
using the -Werror option.
It seems that this issue was fixed in upstream release 0.5.1 [4].
More background information on this issue can be obtained from the
corresponding Charliecloud upstream issue and PR ([5], [6]).
Best regards,
Peter
[0]
https://buildd.debian.org/status/fetch.php?pkg=squashfuse=armel=0.5.0-2%2Bb1=1707534165=0
[1]
https://buildd.debian.org/status/fetch.php?pkg=squashfuse=armhf=0.5.0-2%2Bb1=1707538322=0
[2]
https://buildd.debian.org/status/fetch.php?pkg=squashfuse=i386=0.5.0-2%2Bb1=1707537260=0
[3]
https://buildd.debian.org/status/fetch.php?pkg=charliecloud=armel=0.37-2=1710594551=log
[4]
https://github.com/vasi/squashfuse/commit/cb148fc1477ed676049b7891ebb6efc90b2c00ec
[5] https://github.com/hpc/charliecloud/issues/1858
[6] https://github.com/hpc/charliecloud/pull/1859
Bug#1065793: charliecloud: FTBFS on arm{el,hf}: ch_fuse.c:68:19: error: initialization of ‘void (*)(struct fuse_req *, fuse_ino_t, uint64_t)’ {aka ‘void (*)(struct fuse_req *, long long unsigned int,
Control: reopen -1 It seems that the patch uploaded with 0.37-2 does not fix this issue. See https://buildd.debian.org/status/fetch.php?pkg=charliecloud=armel=0.37-2=1710594551=log and https://buildd.debian.org/status/fetch.php?pkg=charliecloud=armhf=0.37-2=1710594414=log Therefore I reopen this bug. Best regards, Peter
Bug#1065793: marked as pending in charliecloud
Control: tag -1 pending
Hello,
Bug #1065793 in charliecloud reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/hpc-team/charliecloud/-/commit/5b9e616161bc9b2651081434b5fa5b017fdbc885
Add patch from upstream PR 1859 to fix FTBFS issue on arm{el,hf}
Closes: #1065793
(this message was generated automatically)
--
Greetings
https://bugs.debian.org/1065793
Bug#1024830: ERROR: Unable to connect to servers to test latency.
Hi, speedtest-cli 2.1.3-2 works for me on Bookworm. Best regards, Peter
Bug#1058286: marked as pending in ncrack
Control: tag -1 pending Hello, Bug #1058286 in ncrack reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/pkg-security-team/ncrack/-/commit/f4d07967032a4c9142532857b2d7b09f2ef7dc49 Allow zlib versions with two-part version number (Closes: #1058286) (this message was generated automatically) -- Greetings https://bugs.debian.org/1058286
Bug#1055833: marked as pending in charliecloud
Control: tag -1 pending Hello, Bug #1055833 in charliecloud reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/hpc-team/charliecloud/-/commit/80969006f62d9d5450bdfb8237512baba4d891d9 d/t/control: Skip autopkgtest on s390x (Closes: #1055833) This is a workaround for upstream issue https://github.com/hpc/charliecloud/issues/1773 (this message was generated automatically) -- Greetings https://bugs.debian.org/1055833
Bug#1054713: libsquashfuse-dev: needed headers (e.g. config.h) are not shipped
Control: affects -1 + src:charliecloud thanks Hi, this bug also affects charliecloud: - configure:6729: checking for squashfuse/ll.h configure:6729: gcc -c -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -std=c99 -Wall -I/usr/include -L/usr/lib -Wno-unused-command-line-argument -Werror -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5 In file included from /usr/include/squashfuse/dir.h:28, from /usr/include/squashfuse/squashfuse.h:28, from /usr/include/squashfuse/ll.h:28, from conftest.c:17: /usr/include/squashfuse/common.h:28:10: fatal error: config.h: No such file or directory 28 | #include "config.h" | ^~ compilation terminated. - Charliecloud users notice this as: - $ ch-run myimage.sqfs -- /bin/bash ch-run[7126]: error: this ch-run does not support internal SquashFS mounts (ch-run.c:202) - Best regards, Peter
Bug#1052732: notus-scanner: FTBFS: ModuleNotFoundError: No module named 'tomli'
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/notus-scanner/-/merge_requests/1
Bug#1042315: wfuzz: FTBFS: make: *** [debian/rules:8: clean] Error 25
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/wfuzz/-/merge_requests/1
Bug#1040628: marked as pending in Dnstwist
Control: tag -1 pending Hello, Bug #1040628 in Dnstwist reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/pkg-security-team/dnstwist/-/commit/761047d3414f7a98bb436ba2986bdf0844f9ba22 Add patch to adapt to changes in pillow 10.0.0 See https://github.com/elceef/dnstwist/issues/194 Closes: #1040628, LP: #2027963 (this message was generated automatically) -- Greetings https://bugs.debian.org/1040628
Bug#1031522: yt-dlp: Unable to extract uploader id
Package: yt-dlp Version: 2023.01.06-1 Severity: grave Tags: fixed-upstream Justification: renders package unusable Dear Maintainer, it seems that version 2023.01.06-1 of yt-dlp suffers from the issue described in: https://github.com/yt-dlp/yt-dlp/issues/6247 Upstream has provided a fix for this issue: https://github.com/yt-dlp/yt-dlp/commit/149eb0bbf34fa8fdf8d1e2aa28e17479d099e26b Best regards, Peter -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages yt-dlp depends on: ii python33.11.1-3 ii python3-brotli 1.0.9-2+b6 ii python3-certifi2022.9.24-1 ii python3-mutagen1.46.0-1 ii python3-pkg-resources 66.1.1-1 ii python3-pycryptodome 3.11.0+dfsg1-4 ii python3-websockets 10.4-1 Versions of packages yt-dlp recommends: ii ca-certificates 20211016 ii curl 7.87.0-2 ii ffmpeg 7:5.1.2-2 ii python3-pyxattr 0.8.0-1+b1 ii rtmpdump 2.4+20151223.gitfa8646d.1-2+b2 ii wget 1.21.3-1+b2 Versions of packages yt-dlp suggests: pn libfribidi-bin | bidiv ii mpv 0.35.1-1 pn phantomjs -- no debconf information
Bug#1031455: charliecloud: FTBFS: config.h:38: error: "PACKAGE_VERSION" redefined [-Werror]
Control: reassign -1 src:fuse3 Control: found -1 3.13.1-1 Control: forwarded -1 https://github.com/libfuse/libfuse/issues/729 Control: tags -1 + fixed-upstream Control: affects -1 src:charliecloud Dear Lucas, thanks for reporting this problem. It seems that the root cause of this FTBFS issue is a problem which was introduced by fuse3 3.13.1. A fix has been provided by upstream: https://github.com/libfuse/libfuse/commit/d7560cc9916b086bfe5d86459cc9f04033edd904 Best regards, Peter
Bug#1022526: python-ssdeep: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command
Dear Helmut, On 04.11.22 10:36, Helmut Grohne wrote: Would someone handle dnstwist, which is the only remaining dependency? I opened a corresponding upstream request: https://github.com/elceef/dnstwist/issues/170 Peter
Bug#1016251: python-lark: FTBFS: Handler for event 'source-read' threw an exception (exception: TableProcessor.__init__() missing 1 required positional argu
Control: reassign -1 src:sphinx-markdown-tables Control: found -1 0.0.15-3 Control: tags -1 + fixed-upstream Control: affects -1 src:python-lark thanks Dear Lucas, thanks for reporting this problem. It seems that the root cause of this FTBFS issue is a breaking change in python-markdown 3.4 which in turn requires changes in sphinx-markdown-tables which in turn is a build dependency of python-lark. More information on this issue can be found in the following sphinx-markdown-tables issue: https://github.com/ryanfox/sphinx-markdown-tables/issues/36 Best regards, Peter
Bug#968246: marked as pending in Dnstwist
Control: tag -1 pending Hello, Bug #968246 in Dnstwist reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/pkg-security-team/dnstwist/-/commit/a5667d4f0f14b67128e1913d7adc15b34fbbf209 d/tests/control: Allow stderr (closes: #968246) dnspython 2.0.0 introduces a deprecation warning on stderr because dns.resolver.Resolver.query() is replaced by dns.resolver.Resolver.resolve() Thanks to Scott Kitterman for reporting the issue and proposing a fix. (this message was generated automatically) -- Greetings https://bugs.debian.org/968246
Bug#968246: dnstwist: Autopkgtest failure due to depgrecation warning with dnspython 2.0.0
Hi Scott, On 11.08.20 17:54, Scott Kitterman wrote: > Unless you object, I'll probably do an NMU to do that since this will block > dnspython testing migration. I'll > post a diff to the bug before I do. that is fine with me. @Security tools team: I requested a review/upload of a new version of dnstwist last week [0]. Given Scott's planned NMU it might be good to hold off the upload of the new version until the NMU is acknowledged. Best regards, Peter [0] https://lists.debian.org/debian-security-tools/2020/08/msg0.html
Bug#926103: libifd-cyberjack6: driver breaks with pcsc-lite versions >= 1.8.21
Am 01.04.19 um 12:40 schrieb Frank Neuber: Dear Peter, this bug is fixed in SP13. The version in the debian repo is SP9 and quite old. http://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP13/pcsc-cyberjack_3.99.5final.SP13.tar.gz http://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP13/libifd-cyberjack6_3.99.5final.sp13_amd64_d09.deb Please let me know if it works for you. Dear Frank, thanks for the link to an up-to-date driver version. It actually fixes the described problem. Thanks, Peter
Bug#926103: libifd-cyberjack6: driver breaks with pcsc-lite versions >= 1.8.21
Package: libifd-cyberjack6 Version: 3.99.5final.sp09-1.1 Severity: grave Justification: renders package unusable Dear Maintainer, trying to change the PIN of an eID card using a ReinerSCT cyberJack RFID komfort device, I get the following error: Mar 31 14:31:54 hostname pcscd[21065]: 00400142 ifdwrapper.c:364:IFDStatusICC() Card not transacted: 612 Mar 31 14:31:54 hostname pcscd[21065]: 0035 eventhandler.c:336:EHStatusHandlerThread() Error communicating to: REINER SCT cyberJack RFID komfort The underlying cause seems to be the issue described on https://github.com/LudovicRousseau/PCSC/issues/22 and (in German) https://forum.reiner-sct.com/index.php?/topic/3728-failed_to_transmit_control_command_to_the_terminal Both references point to a patch for this problem. Peter -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 Versions of packages libifd-cyberjack6 depends on: ii libc6 2.28-8 ii libgcc1 1:8.3.0-2 ii libstdc++68.3.0-2 ii libusb-1.0-0 2:1.0.22-2 ii pcscd 1.8.24-1 libifd-cyberjack6 recommends no packages. Versions of packages libifd-cyberjack6 suggests: pn pcsc-tools
