Bug#706146: root-plugin-math-minuit2: Missing headers for Minuit2
Hi Lifeng, I am yet another person missing Minuit2 headers and therefore I would like to support Bastian's request. My motivation for the request resembles Bastian's: I am trying to build a program which contains a class inheriting from ROOT::Minuit2::FCNBase and Minuit2 is not the only ROOT dependency of the program. Cheers, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#898209: charliecloud: Change service by systemd in po-debconf
On 28.05.2018 22:53, Alban Vidal wrote: > I have sent the merge request. > > https://salsa.debian.org/hpc-team/charliecloud/merge_requests/2 Dear Alban, thank you very much. I merged it a few minutes ago. Peter
Bug#898209: charliecloud: Change service by systemd in po-debconf
On 27.05.2018 21:23, Alban Vidal wrote:> If you whant, i can update by myself and create merge request. Dear Alban, how could I decline such a kind offer? :-) Please feel free to perform the update and create a merge request. Cheers, Peter
Bug#898209: charliecloud: Change service by systemd in po-debconf
Dear Alban, thanks for providing this patch which I gladly applied. Shall I simply go ahead and do the "translations" of "systemctl restart procps" in the various po files myself (to avoid bothering the translators with such a straightforward change) or would that interfere with the workflow of the language teams? Best regards, Peter On 08.05.2018 20:26, Alban Vidal wrote: > Package: charliecloud > Version: 0.2.3-2 > Severity: wishlist > Tags: patch > > Dear mainteners, > > I suggest to change the following lines in po-debconf for systemd. > > Current: > service procps restart > > Proposal: > systemctl restart procps > > Best regards, > > Alban Vidal
Bug#906186: charliecloud: [INTL:de] initial German debconf translation
Dear Helge, thanks for your translation. Looking through your po file, two questions came to my mind: 1. It seems to me that there is a typo in your email address. Both in the fourth line of the file and in the Last-Translator field there are three l at the end of the domain name whereas in the sender field of this email there are only two l. Could you double-check this, please. 2. I do not want to interfere with the work of the German language team but I wonder whether there is a hyphen missing between "nicht" and "privilegierte". I am not a language expert but I wonder whether - without hyphen - there is the danger of misunderstanding the first sentence in the following way: "Privilegierte Benutzernamensräume sind im laufenden Kernel nicht deaktiviert." This interpretation would be confusing. That is just my two cents. If you prefer to keep the translation the way it is right now, I am happy to commit it unchanged. Peter
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
Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Hi Nick, thank you very much for taking the time to review the packaging and providing such detailed and helpful feedback. On 10.11.19 00:02, Nick Morrott wrote: > Thank you for your work in packaging python-pyjsparser. Out of > curiosity, what are you using to be build your package? My primary motivation for packaging python-pyjsparser is to be able to bump the version of Charliecloud: https://tracker.debian.org/pkg/charliecloud Version 0.10 of Charliecloud adds new dependencies, including lark-parser which in turn depends on python-js2py which in turn depends on python-pyjsparser. > I checked out the package and built it - your work looks good, and the > build was successful. I then ran it through lintian, Debian's package > linting tool which you should get into the habit of using before > uploading to salsa (and once you're a DM/DD, also before uploading to > the archive). I have configured my sbuild setup in such a way that it always runs lintian after builds. But thanks to your feedback I noticed that I was running lintian with a too high display threshold such that the only lintian feedback I received was "I: Lintian run was successful." and "Lintian: pass" despite of the issues you discovered. I have tweaked the lintian options in my ~/.sbuildrc now. Hopefully I will not miss similar issues in the future. > * d/control > - no Rules-Requires-Root field [lintian] Fixed. > - the extended package description should probably include details > about the library's key features/support [lintian] Done. > * d/copyright > - the only copyright dates I can see in the source are 2014-2015 Judging from the source files, you are right. Judging from the git commit history I see commits between 2015 and 2019. What is a better guideline for copyright years: copyright notices in the source or the git history? Maybe it would be best to combine both information which would yield 2014-2019. Once I know what should be used, I will update the copyright file accordingly. > - you can add the Upstream-Contact field to the header Done. > * d/rules > - pybuild can provide verbose output with "export PYBUILD_VERBOSE=1" Added. > * d/upstream/metadata > - please add and complete this file - there are plenty of examples > in the team's salsa project [lintian] Done. > * d/watch > - +1 for asking upstream to version their releases on github Thanks! Let's see what happens. > - the additional (commented) scaffolding inserted into the file by > dh-make can be removed to leave only the version line and the URL to > check [lintian] The idea behind leaving the Github lines as comment was that I could easily switch to following Github tags/releases provided that upstream decides to publish them for future releases. But since the "" string triggers the lintian complaint and replacing this placeholder would be just guessing until upstream actually provides releases on Github, I removed all comments related to this. This also makes lintian happier. :-) > - as this is a version 4 watch file, we can take advantage of new > variable substitutions for the version and extension fields, so that > the URL to check would look like: > > https://pypi.debian.net/pyjsparser/pyjsparser@ANY_VERSION@@ARCHIVE_EXT@ Very convenient variables. Changed accordingly. > * upstream changelog > - there is no upstream changelog To my knowledge upstream does not provide such a file. > * documentation/examples > - There is no documentation at all, aside from the simple example in > the README. Perhaps this snippet could be installed as an example when > installing the package? Done (although I am not sure whether the way I implemented it is the recommended way to do it). Suggestions how to improve the code are welcome. > * tests > - there are no tests to run at build time (and therefore no > autopkgtests to run for continuous integration whenever the package's > dependencies are updated). Looking at the github repo there seems to > be a significant testsuite that should really be available in the > Debian source package to take advantage of autopkgtest. [lintian] The testsuite available on Github requires js2py which is not in the Debian archive yet (thus the testsuite introduces a circular dependence: pyjsparser <-> js2py). js2py is the next package on my to-package list (see above). I see two options to move forward: 1. Wait for js2py being packaged and provide autopkgtests for pyjsparser once js2py is available. 2. Install js2py using pip for the test. None is really nice in my opinion. Which option do you prefer? > I hope you find this useful - if you have any questions don't hesitate > to ask the team (the Python list is visible and archived, IRC may get > a quicker answer...). I'm a new DD and there are likely some things > that the more experienced members of the team will notice. Yes, your feedback was definitely very helpful and allowed me to learn new things. Thanks, Peter
Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Dear Python team, I prepared packaging for python-pyjsparser (ITP bug #943785) on https://salsa.debian.org/python-team/modules/python-pyjsparser It provides a fast JavaScript parser written in Python. It would be great if a DD could review the code, provide feedback and (if everything looks OK) upload it. Thanks, Peter
Bug#941657: Needed too
Hi Thomas, On 27.10.19 09:10, Thomas Andrejak wrote: > I'm also interested. I need it to bump version of Prewikka. nice to hear. > If you want, we can co-maintain the package You are welcome as co-maintainer. I pushed what I have right now to salsa such that you can get an idea what the present status is: https://salsa.debian.org/python-team/modules/python-lark-parser It seems that you are not yet a member of the Debian Python Modules Team. Information on the team (including how to join) is available on https://wiki.debian.org/Teams/PythonModulesTeam Getting lark-parser into Debian requires more work than packaging lark-parser itself. That is why this bug is blocked by #943783 which in turn is blocked by #943785. Progress on #943785 can be tracked here: https://salsa.debian.org/python-team/modules/python-pyjsparser My work on #943783 is presently slowed down by a problem with a js2py unit test error [0]. After some necessary clean-up I will push my js2py packaging work in progress to https://salsa.debian.org/python-team/modules/python-js2py Peter [0] https://github.com/PiotrDabkowski/Js2Py/issues/185
Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Hi Nick, have you already found time to look into the revised packaging described in [0] and [1]? Cheers, Peter [0] https://lists.debian.org/debian-python/2019/11/msg00048.html [1] https://lists.debian.org/debian-python/2019/11/msg00106.html
Bug#943644: dnsviz: graphs for queries involving DNAME records do not work
Package: dnsviz Version: 0.8.0-1 Severity: normal Dear maintainers, trying to produce graphs for queries involving DNAME records results in the following error: Traceback (most recent call last): File "/usr/bin/dnsviz", line 108, in main() File "/usr/bin/dnsviz", line 105, in main mod.main(args) File "/usr/lib/python2.7/dist-packages/dnsviz/commands/graph.py", line 308, in main name_obj = OfflineDomainNameAnalysis.deserialize(name, analysis_structured, cache, strict_cookies=strict_cookies) File "/usr/lib/python2.7/dist-packages/dnsviz/analysis/online.py", line 943, in deserialize a._deserialize_related(d) File "/usr/lib/python2.7/dist-packages/dnsviz/analysis/online.py", line 1003, in _deserialize_related self.add_query(Q.DNSQuery.deserialize(query, bailiwick_map, default_bailiwick, cookie_jar_map, default_cookie_jar, cookie_standin, cookie_bad), detect_ns, detect_cookies) File "/usr/lib/python2.7/dist-packages/dnsviz/analysis/online.py", line 497, in add_query self.queries[key].add_query(query, bailiwick_map, default_bailiwick) File "/usr/lib/python2.7/dist-packages/dnsviz/query.py", line 1277, in add_query self._aggregate_response(server, client, response, self.qname, self.rdtype, self.rdclass, bailiwick) File "/usr/lib/python2.7/dist-packages/dnsviz/query.py", line 849, in _aggregate_response self._aggregate_answer(server, client, response, is_referral, qname, rdtype, rdclass) File "/usr/lib/python2.7/dist-packages/dnsviz/query.py", line 881, in _aggregate_answer synthesized_cname_info = rrset_info.create_or_update_cname_from_dname_info(synthesized_cname_info, server, client, response, rdclass) File "/usr/lib/python2.7/dist-packages/dnsviz/response.py", line 1066, in create_or_update_cname_from_dname_info return self.insert_into_list(synthesized_cname_info, self.cname_info_from_dname, server, client, response, rdclass) TypeError: insert_into_list() takes exactly 6 arguments (7 given) A simple reproducer is: dnsviz probe www.hrz.uni-bonn.de | dnsviz graph -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dnsviz depends on: ii dns-root-data 2019031302 ii libjs-jquery 3.3.1~dfsg-3 ii libjs-jquery-ui1.12.1+dfsg-5 ii libjs-jquery-ui-theme-redmond 1.12.1+dfsg-1 ii libjs-raphael 2.1.0-1 ii python 2.7.16-1 ii python-dnspython 1.16.0-1 ii python-libnacl 1.6.1-4 ii python-m2crypto0.31.0-4 ii python-pygraphviz 1.5-1 dnsviz recommends no packages. dnsviz suggests no packages. -- no debconf information
Bug#943783: ITP: python-js2py -- JavaScript to Python translator
Package: wnpp Severity: wishlist Owner: Peter Wienemann Package name: python-js2py Version : 0.66 Upstream Author : Piotr Dabkowski URL : https://github.com/PiotrDabkowski/Js2Py License : MIT Programming Lang: Python Description : JavaScript to Python translator Js2Py provides a JavaScript to Python translator and a JavaScript interpreter written in Python. It is a dependency of python-lark-parser (see #941657). This package will be team-maintained by the Debian Python Modules Team.
Bug#943785: ITP: python-pyjsparser -- Fast JavaScript parser written in Python
Package: wnpp Severity: wishlist Owner: Peter Wienemann Package name: python-pyjsparser Version : 2.7.1 Upstream Author : Piotr Dabkowski URL : https://github.com/PiotrDabkowski/pyjsparser License : MIT Programming Lang: Python Description : Fast JavaScript parser written in Python pyjsparser is a fast JavaScript parser written in Python. It is a dependency of python-js2py (see #943783). This package will be team-maintained by the Debian Python Modules Team.
Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Hi Nick, On 11.11.19 20:01, Peter Wienemann wrote: * d/copyright - the only copyright dates I can see in the source are 2014-2015 Judging from the source files, you are right. Judging from the git commit history I see commits between 2015 and 2019. What is a better guideline for copyright years: copyright notices in the source or the git history? Maybe it would be best to combine both information which would yield 2014-2019. Once I know what should be used, I will update the copyright file accordingly. I asked on IRC how to handle this situation. The answer was: Use the copyright years from the copyright notices in the source. I have just pushed a commit with the corresponding change to salsa. Peter
Bug#941657: ITP: python-lark-parser -- Parsing library for Python
Package: wnpp Severity: wishlist Owner: Peter Wienemann Package name: python-lark-parser Version : 0.7.7 Upstream Author : Erez Shinan URL : https://github.com/lark-parser/lark License : MIT Programming Lang: Python Description : Parsing library for Python lark-parser is a parsing library for Python which allows to parse any context-free grammar. It has implemented the following parsing algorithms: Earley, LALR(1) and CYK. lark-parser has become a dependency of the Charliecloud package since version 0.10 and is thus needed to bump the Charliecloud version. This package will be team-maintained by the Debian Python Modules Team.
Bug#941657: python-lark-parser -- Change of plans?
Hi Thomas, On 30.10.19 21:07, Peter Wienemann wrote: > Getting lark-parser into Debian requires more work than packaging > lark-parser itself. That is why this bug is blocked by #943783 which in > turn is blocked by #943785. > > Progress on #943785 can be tracked here: > > https://salsa.debian.org/python-team/modules/python-pyjsparser > > My work on #943783 is presently slowed down by a problem with a js2py > unit test error [0]. After some necessary clean-up I will push my js2py > packaging work in progress to > > https://salsa.debian.org/python-team/modules/python-js2py > > Peter > > [0] https://github.com/PiotrDabkowski/Js2Py/issues/185 after a discussion with upstream [0] and a lack of feedback on the js2py issue [1] I tend to go forward without the Nearley conversions in lark-parser and consequently stop the efforts to get pyjsparser and js2py into Debian. Would that be fine for your use case, too? Best regards, Peter [0] https://github.com/lark-parser/lark/issues/501 [1] https://github.com/PiotrDabkowski/Js2Py/issues/185
Bug#948237: ITP: dnstwist -- domain name permutation engine
Hi Scott, On 05.01.20 21:17, Scott Kitterman wrote: > Upstream contains an embedded copy of the Public Suffix List (PSL): > > https://github.com/elceef/dnstwist/blob/master/database/effective_tld_names.dat > > In Debian, this is provided in the publicsuffix package: > > https://salsa.debian.org/debian/publicsuffix/blob/debian/master/public_suffix_list.dat > > Although renamed, it's the same file. Please use the PSL from publicsuffix > rather than the embedded copy. It'll be more up to date. thanks for your hint. I wasn't aware of this. I guess the same holds for the GeoIP.dat file which seems to be provided by the geoip-database package in Debian. Peter
Bug#941657: RFS: python-lark
Dear DDs, I prepared packaging for the parsing library python-lark (ITP bug #941657). It is needed to bump the versions of prewikka [0] and charliecloud [1]. The git repository is available on https://salsa.debian.org/python-team/modules/python-lark It would be great if someone could review the code, provide feedback and - once everything looks fine - upload it. Thanks, Peter [0] https://tracker.debian.org/pkg/prewikka [1] https://tracker.debian.org/pkg/charliecloud
Bug#941657: name change: python-lark-parser -> python-lark
Hi Thomas, I am including the Python team to tap their expertise. For those not familiar with the topic: We are referring to https://github.com/lark-parser/lark which is not in the Debian archive yet (packaging work is still ongoing). On 29.12.19 23:10, Thomas Andrejak wrote: > Why changing the name ? it's named lark-parser in pypi. >From the beginning I felt uncertain how to call the source package: python-lark-parser or python-lark. > Moreover, in pypi, there already is a "lark" module which is not lark-parser When filing the ITP bug I decided to choose python-lark-parser for exactly this reason although upstream seems to call its software simply "Lark" in most places. Later I became aware of https://bugs.debian.org/945823 which says: "use the name you import in preference to the name from the PKG-INFO". That is why I decided to change the name to python-lark. But given the PyPI name clash this is certainly not optimal either. So this seems to be a particular unfortunate case. Any advice is welcome! Peter > Le sam. 28 déc. 2019 à 05:03, Peter Wienemann <mailto:foss...@posteo.de>> a écrit : > > Following the suggestions in > > https://bugs.debian.org/945823 > > I have changed the name from python-lark-parser to python-lark. > > The new repository URL is > > https://salsa.debian.org/python-team/modules/python-lark > > Peter
Bug#941657: name change: python-lark-parser -> python-lark
Hi Simon, thanks for your helpful input. On 30.12.19 18:04, Simon McVittie wrote: > There are two options: > > * If "lark" on PyPI is a dead project, or otherwise something that is never > going to be useful to package in Debian for some reason, then perhaps it's > safe for the lark parser to claim the python3-lark name. The last commit happened six years ago. It might be dead but I am not sure. > * Otherwise, if its PyPI name is lark-parser, then I would personally > recommend asking the upstream developer to rename the module you import > to lark_parser (or maybe larkparser if that's preferred), and packaging > it as python3-lark-parser (or python3-larkparser), optionally with > compatibility glue to make "import lark" continue to work (which might not > get packaged in Debian). I opened a corresponding issue: https://github.com/lark-parser/lark/issues/505 Peter
Bug#948237: ITP: dnstwist -- domain name permutation engine
Package: wnpp Severity: wishlist Owner: Peter Wienemann Package name: dnstwist Version : 20190706 Upstream Author : Marcin Ulikowski URL : https://github.com/elceef/dnstwist License : Apache-2.0 Programming Lang: Python Description : Domain name permutation engine For a given domain name, dnstwist generates a list of similarly looking domains and performs DNS queries for each of them (A, , NS and MX). For MX records it checks whether there is an active mail server which could intercept misdirected emails. Moreover it estimates webpage similarity based on fuzzy hashes. This functionality might be helpful in discovering typosquatters, phishing sites or otherwise fraudulent services and corporate espionage. This package will be team-maintained by the Debian Security Tools Team.
Bug#941657: name change: python-lark-parser -> python-lark
Following the suggestions in https://bugs.debian.org/945823 I have changed the name from python-lark-parser to python-lark. The new repository URL is https://salsa.debian.org/python-team/modules/python-lark Peter
Bug#958327: charliecloud: cannot use ch-run
Hi Christophe, On 20.04.20 17:05, Christophe Trophime wrote: > Trying to run a test example with some mount directory (ie ch-run -h > SRC:DST -w ./feelpp-v0.108-focal/ -- pwd) > I end up with error like: ch-run[190638]: error (charliecloud.c:553) > Same behaviour without -h nor -w options this looks like this upstream issue: https://github.com/hpc/charliecloud/issues/649 (i. e. a UID lookup failure). Peter
Bug#948237: RFS: dnstwist
Dear DDs, I prepared packaging for the domain name permutation engine "dnstwist" (ITP bug #948237). The git repository is currently available at https://salsa.debian.org/wiene-guest/dnstwist It would be great if someone could review the code, provide feedback and - once everything looks fine - transfer the repository to the security tools team area and upload the package. Thanks, Peter
Bug#971279: ITP: sphinx-markdown-tables -- Sphinx extension for rendering markdown tables
Package: wnpp Severity: wishlist Owner: Peter Wienemann Package name: sphinx-markdown-tables Version : 0.0.15 Upstream Author : Ryan Fox URL : https://github.com/ryanfox/sphinx-markdown-tables License : GPL-3.0 Programming Lang: Python Description : Sphinx extension for rendering markdown tables While Sphinx supports markdown thanks to the recommonmark extension, the latter does not cover tables. The sphinx-markdown-tables extension remedies this shortcoming. This package will be team-maintained by the Debian Python Team.
Bug#961860: make: Broken symlinks: /usr/bin/gmake, /usr/share/man/man1/gmake.1.gz
Package: make Version: 4.3-1 Severity: normal Dear maintainer, piuparts reports the following problem: ERROR: WARN: Broken symlinks: /usr/bin/gmake -> /make (make) /usr/share/man/man1/gmake.1.gz -> /make.1.gz (make) Peter -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#961974: gpg-agent: package purging leaves files on system
Package: gpg-agent Version: 2.2.20-1 Severity: normal Dear maintainer, running piuparts on the package results in the following error: ERROR: FAIL: Package purging left files on system: /etc/systemd/user/ not owned /var/lib/systemd/deb-systemd-user-helper-masked/ not owned Peter -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#965964: ITP: geant4 -- physics simulation toolit from CERN
Hi Stephan, On 21.07.20 16:42, Stephan Lachnit wrote: > Package name: geant4 > Version : 10.6.2 > Upstream Author : CERN > URL : http://geant4.web.cern.ch/ > License : a custom (MIT-like) license but looks DFSG compliant according to [0] the Geant4 license is not DFSG compliant. Peter [0] https://wiki.debian.org/DebianScience/Geant4
Bug#967059: lintian: Do not issue package-contains-no-arch-dependent-files for packages with arch-dependent dependencies
Package: lintian Version: 2.86.0 Severity: normal Dear Lintian maintainers, Lintian issues the tag package-contains-no-arch-dependent-files on packages without "Architecture: all" if they only contain architecture-independent files (at least this is my understanding). That is fine unless they have architecture-dependent dependencies (i. e. arch-dependent "Depends:" entries). In the latter case making the package architecture-dependent is required to implement architecture-dependent dependencies even though the package contents is purely architecture-independent (see Debian Policy Manual section 7.1). Best regards, Peter -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
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#965964: ITP: geant4 -- physics simulation toolit from CERN
Hi Stephan, On 24.07.20 15:11, Stephan Lachnit wrote: > The relevant part of the license [1] mentioned on the wiki page is: > >> 5. You may not include this software in whole or in part in any patent >> or patent application in respect of any modification of this software >> developed by you. > > I don't see how this doesn't comply with the DFSG. > It doesn't limit derived works, it doesn't discriminate anyone, > and it isn't specific to Debian or any other software product. in my layperson's view this is a violation of DFSG clause 6: "The license must not restrict anyone from making use of the program in a specific field of endeavor." Best regards Peter
Bug#988689: ITP: 7zip -- 7-Zip file archiver
Hi Hiroshi, On 18.05.21 02:07, YOKOTA Hiroshi wrote: * Package name: 7zip Version : 21.02 Upstream Author : Igor Pavlov * URL : https://www.7-zip.org/ * License : LGPL with "unRAR license restriction" ( https://www.7-zip.org/license.txt ) Programming Lang: C, C++, Asm Description : 7-Zip file archiver 7-Zip is a file archiver with a high compression ratio. is this different from https://tracker.debian.org/pkg/p7zip Best regards, Peter
Bug#984444: questionable dependency on python3-pip
On 03.03.21 20:05, Matthias Klose wrote: Package: parsero Version: 0.0+git20140929.e5b585a-4 Severity: important questionable dependency on python3-pip. The httplib3 dependency is satisfied by the Debian package dependency. There's no need to have the python3-pip dependency. I opened a MR with a fix here: https://salsa.debian.org/pkg-security-team/parsero/-/merge_requests/1 Peter
Bug#1000889: python-commentjson: Package clean-up validation fails
Source: python-commentjson Version: 0.8.3-2 Severity: normal Hi, trying to rebuild python-commentjson including a package clean-up validation as described in [0], I obtain the following pre-build post-build diff: diff /tmp/file-list.pre-build /tmp/file-list.post-build --- 11,12c11,12 < /<>/commentjson.egg-info/PKG-INFO regular file 2219 0f1c5ca8641d550fdee87e7e6980895a28c5815c6521435a744f0b004e726283 < /<>/commentjson.egg-info/SOURCES.txt regular file 878 f65faa48583845bc6e069485bd647a3a0e7e946fe613dab7a4400c9463cb6163 --- > /<>/commentjson.egg-info/PKG-INFO regular file 1720 > e66e7eae63a9ea8c4b2839050789826f5423cf90a4f8b6f2c5a03e9c893bd290 > /<>/commentjson.egg-info/SOURCES.txt regular file 888 > c0054a110491ebe0cc3bd0dba41e37b1613d40e906b6a83b06ed91ab98f2af30 15c15 < /<>/commentjson.egg-info/requires.txt regular file 26 5c8784bc8ef3b2673e59933e934b590cd62c00546b1f6cb4663c2a914af235a0 --- > /<>/commentjson.egg-info/requires.txt regular file 26 > 7349d535d30cf547fee17cf3ec760402cf31f118d72f986cf5a5bf83558dd276 E: Command 'diff /tmp/file-list.pre-build /tmp/file-list.post-build' failed to run. Best regards, Peter [0] https://wiki.debian.org/sbuild#Validate_package_cleanup -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1006499: sshfs-fuse: Package clean-up validation fails
Source: sshfs-fuse Version: 3.7.1+repack-2 Severity: normal Hi, trying to rebuild sshfs-fuse including a package clean-up validation as described in [0], I obtain the following pre-build post-build diff: diff /tmp/file-list.pre-build /tmp/file-list.post-build --- 43c43 < /<>/test directory 260 --- > /<>/test directory 300 44a45,56 > /<>/test/.pytest_cache directory 120 > /<>/test/.pytest_cache/.gitignore regular file 37 > 3ed731b65d06150c138e2dadb0be0697550888a6b47eb8c45ecc9adba8b8e9bd > /<>/test/.pytest_cache/CACHEDIR.TAG regular file 194 > ffacb1561d9688b9d9b5e06f3ffa10814a03c2a6f892d7bea3e7fef62599eb23 > /<>/test/.pytest_cache/README.md regular file 295 > 27a7071ba39c9ef4054eaf99bc59e3f0aa328a62166f426e6549ef923ade7533 > /<>/test/.pytest_cache/v directory 60 > /<>/test/.pytest_cache/v/cache directory 80 > /<>/test/.pytest_cache/v/cache/nodeids regular file 810 > 864895f6c02636aa7eefcaf0dc06a13ce07f612f79d7802adf6e8dc3ea1c2353 > /<>/test/.pytest_cache/v/cache/stepwise regular file 2 > 4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945 > /<>/test/__pycache__ directory 100 > /<>/test/__pycache__/conftest.cpython-39-pytest-6.2.5.pyc > regular file 2886 > 331ef1aa4660614df6f4780e423d6148f1ec5ab776ca778634a2ad6ff90063af > /<>/test/__pycache__/test_sshfs.cpython-39-pytest-6.2.5.pyc > regular file 32510 > 9395f19862e5adfcdaa0ffdfd66e9669b18f6635962ee0fbbc83df215214f99e > /<>/test/__pycache__/util.cpython-39.pyc regular file 3224 > 233b0498f1877dfe7d3c2dcccd2ad04696788e8bac03bf523c70283ee5c5f045 E: Command 'diff /tmp/file-list.pre-build /tmp/file-list.post-build' failed to run. Best regards, Peter [0] https://wiki.debian.org/sbuild#Validate_package_cleanup -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-amd64 (SMP w/12 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1005038: oidc-agent: Backport for bullseye
Source: oidc-agent Version: 4.2.6-1 Severity: wishlist Dear maintainer, it would be nice if you could provide a backport of oidc-agent for bullseye. Many thanks, Peter -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-amd64 (SMP w/12 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
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#1054897: lintian: Also warn about later switches to date-based versioning schemes
Package: lintian Version: 2.116.3 Severity: wishlist Dear maintainers, at present Lintian only emits the tag "new-package-uses-date-based-version-number" if - a date-based versioning scheme is used for the latest changelog entry and - the number of changelog entries is one. I think it would be better to emit it if - a date-based versioning scheme is used for the latest changelog entry and - the number of changelog entries with a date-based versioning scheme is one. One might also consider adapting the tag name to reflect the change of logic. The background of this request is a discussion on the security tools mailing list [0] which made me aware that the present rule set offers a loophole. Best regards, Peter [0] https://lists.debian.org/debian-security-tools/2023/10/msg9.html
Bug#1053355: python3-docutils: Generated man page leads to groff warning "TE macro called with TW register undefined"
Package: python3-docutils Version: 0.19+dfsg-7 Severity: normal Dear maintainers, lintian issues the following warning for the ch-run man page of the charliecloud-runtime package: W: charliecloud-runtime: groff-message an.tmac::676: warning: tbl preprocessor failed, or it or soelim was not run; table(s) likely not rendered (TE macro called with TW register undefined) [usr/share/man/man1/ch-run.1.gz:1] This man page is built using sphinx-build which in turn uses python3-docutils to generate the man page. Therefore I think that the underlying issue is caused by python3-docutils. This issue was already discussed on debian-devel and after applying the patch suggested on [0] the warning disappears when calling LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 -Z /usr/share/man/man1/ch-run.1.gz >/dev/null But unfortunately new warnings show up: troff::598: warning [p 7, 2.2i, div '3tbd3,0', 0.0i]: cannot adjust line troff::602: warning [p 7, 2.2i, div '3tbd3,2', 0.0i]: cannot adjust line troff::606: warning [p 7, 2.2i, div '3tbd4,0', 0.0i]: cannot adjust line troff::610: warning [p 7, 2.2i, div '3tbd4,2', 0.0i]: cannot adjust line Best regards, Peter [0] https://lists.debian.org/debian-devel/2023/08/msg00220.html
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#1047444: t50: Fails to build source after successful build
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/t50/-/merge_requests/1
Bug#1049683: t50: Fails to build binary packages again after successful build
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/t50/-/merge_requests/1
Bug#1047290: statsprocessor: Fails to build source after successful build
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/statsprocessor/-/merge_requests/1
Bug#1045031: dhcpig: Fails to build source after successful build
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/dhcpig/-/merge_requests/2
Bug#1048895: john: Fails to build source after successful build
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/john/-/merge_requests/2
Bug#1049223: sleuthkit: Fails to build source after successful build
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/sleuthkit/-/merge_requests/4
Bug#1049710: sleuthkit: Fails to build binary packages again after successful build
Control: tags -1 + patch See https://salsa.debian.org/pkg-security-team/sleuthkit/-/merge_requests/4
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#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#1023700: cryptsetup: Option fido2-device unknown
Package: cryptsetup Version: 2:2.5.0-6 Severity: normal Dear maintainer, inspired by [0] I am trying to unlock a LUKS volume using a FIDO2 token on a system running bookworm/testing using systemd 252-2. The relevant line in /etc/crypttab looks like this: rootfs /dev/nvme0n1p3 noneluks,discard,fido2-device=auto After running systemd-cryptenroll --fido2-device=auto /dev/nvme0n1p3 and adding the "fido2-device=auto" option in /etc/crypttab, I obtain the following warning during updating the initramfs image: cryptsetup: WARNING: rootfs: ignoring unknown option 'fido2-device' As a result, it comes as no surprise that unlocking the volume using the FIDO2 token does not work as desired. Best regards, Peter [0] https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html
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#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#1041809: groff-base: man pages cause troff warning "cannot select font 'C'"
Package: groff-base Version: 1.23.0-2 Severity: normal Dear Maintainer, I see troff warnings "cannot select font 'C'" for several man pages. Here are the corresponding Lintian warnings for two examples from different packages: W: python3-lark: groff-message troff::1032: warning: cannot select font 'C' [usr/share/man/man7/lark.7.gz:28] [more similar lines] and W: charliecloud-builders: groff-message troff::1066: warning: cannot select font 'C' [usr/share/man/man1/ch-image.1.gz:15] [more similar lines] This issue looks similar to https://bugs.debian.org/1040975 Best regards, Peter
Bug#1035883: general: TMOUT and autologout are set to 3600, but logout occurs much earlier
Dear Jim, On 10.05.23 17:01, Jim Anderson wrote: I realize that auto logout is a general security feature, but in my case, I have a secrure environment where only my wife and I have access to my computer. I strong prefer to NOT have my computer auto logout for 10 hours, allowing me to leave my computer in the evening and return to it in the morning without haveing to log on. I have the enrivonment variables TMOUT and autologout both set to 36000, or 10 hours, but these are not honored by the system. from what does your computer log you out when it logs you out: A graphical user session or a shell session? TMOUT only controls the time-out of shell sessions. Best regards, Peter
Bug#1049319: ssldump: Fails to build source after successful build
Control: tags -1 + patch See https://lists.debian.org/debian-security-tools/2023/11/msg1.html
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#1055833: charliecloud: autopkgtest fails in unstable, blocks other packages migration
Dear Luca, On 2023-11-12 13:20:16 +0100, Luca Boccassi wrote: Source: charliecloud Version: 0.35-4 Severity: important charliecloud's autopkgtest is failing in unstable, and it is blocking iproute2's migration as they are tested together: https://ci.debian.net/data/autopkgtest/testing/s390x/c/charliecloud/39798421/log.gz thanks for your bug report. I hope that this issue is fixed by 0.35-5 which I uploaded shortly before your bug report: https://tracker.debian.org/news/1477982/accepted-charliecloud-035-5-source-into-unstable/ I will keep this bug open until we know for sure. Best regards, Peter
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#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#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#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#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#1073849: ITP: python-imapclient -- easy-to-use Python IMAP client library
Package: wnpp Severity: wishlist Owner: Peter Wienemann X-Debbugs-Cc: debian-de...@lists.debian.org Package name: python-imapclient Version : 3.0.1 Upstream Author : Menno Smits URL : https://github.com/mjs/imapclient License : BSD-3-Clause Programming Lang: Python Description : Easy-to-use Python IMAP client library IMAPClient is a high-level Python library to access mailboxes via the IMAP protocol. It relieves the user of many low-level tasks like parsing server responses, encoding of unicode strings used as folder names, optional translation of timestamps into local time of the client and more. The information is delivered in handy Python data structures that can be easily used for further processing. To help with code development or for quick inspections IMAPClient also offers easy-to-use interactive sessions. This package will be maintained under the umbrella of the Debian Python Team.
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#1074476: sploitscan: HTML export yields: 'dict object' has no attribute 'cvssV3_1'
Package: sploitscan Version: 0.9.1-3 Severity: normal Dear Maintainer, trying to create an HTML export of the sploitscan results yields the following error message: $ sploitscan -e html CVE-2024-3094 [...] Error exporting to HTML: 'dict object' has no attribute 'cvssV3_1' Best regards, Peter
Bug#1075817: paramspider: SyntaxWarning: invalid escape sequence '\/'
Package: paramspider Version: 1.0.1-1 Severity: minor Dear Maintainer, upon installation of paramspider I receive the following syntax warning: $ apt install paramspider [...] Setting up paramspider (1.0.1-1) ... /usr/lib/python3/dist-packages/paramspider/main.py:124: SyntaxWarning: invalid escape sequence '\/' log_text = """ Best regards, Peter
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
