Bug#1068850: GnuPG signature verify emits “SignatureVerifyError: 0”
Package: dput Version: 0.12 Severity: normal When verifying a GnuPG-signed file, ‘dput’ can sometimes emit a confusing error: = […] Checking signature on .changes gpg: ../build-area/foo_1.2_source.changes: Error checking signature from F9B46AAC84420C82: SignatureVerifyError: 0 Checking signature on .dsc gpg: ../build-area/foo_1.2.dsc: Error checking signature from F9B46AAC84420C82: SignatureVerifyError: 0 […] = The program continues, but this message is misleading when the signature is actually valid. If there is no problem with the signature, no message like this should be emitted; if there is a problem with the signature, the message should clearly state what it is. -- \ “The history of Western science confirms the aphorism that the | `\ great menace to progress is not ignorance but the illusion of | _o__)knowledge.” —Daniel J. Boorstin, historian, 1914–2004 | Ben Finney signature.asc Description: PGP signature
Bug#772204: Package upload repository policy
On 08-Apr-2024, Osamu Aoki wrote: > * Adjust message to address rejection condition and repository policy Where (what URL) can I find the current repository policy, with enough precision to implement a conformant upload program? -- \ “It is wrong to think that the task of physics is to find out | `\ how nature *is*. Physics concerns what we can *say* about | _o__) nature…” —Niels Bohr | Ben Finney signature.asc Description: PGP signature
Bug#1021392: dput: Ambiguity when dput thinks package is already uploaded
Control: severity -1 minor Control: merge 941784 -1 On 07-Oct-2022, Moritz Schlarb wrote: > This bit me recently You're not alone; bug#941784 describes this same behaviour. I'm merging this report with that one. -- \ “Very few things happen at the right time, and the rest do not | `\ happen at all. The conscientious historian will correct these | _o__) defects.” —Mark Twain, _A Horse's Tale_ | Ben Finney signature.asc Description: PGP signature
Bug#772204: dput: .orig.tar.gz for non -1 package for security-master
Control: severity -1 minor Control: tags -1 - moreinfo Control: merge 706607 -1 On 28-Aug-2016, Ben Finney wrote: > Is this behaviour the same problem reported in [bug#706607], or is that a > separate problem? On the assumption that bug#706607 reports the same problem, I am merging this bug report with that one. If there is a change needed, that is not covered by the report in bug#706607 (and that I did not parse correctly from this bug report), please feel free to describe it separately in a new bug report. -- \ “Progress might have been all right once, but it's gone on too | `\long.” —Ogden Nash | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1063889: Parse package version string using ‘python3-debian’ class ‘debian.debian_support.Version’
On 14-Feb-2024, Ben Finney wrote: > The ‘dput.source_check’ function currently uses a custom regex pattern for > parsing a package version string. This pattern differs in some ways from > the official Debian Policy definition of a version string. Thanks to Christoph Berg (‘myon’) for the motivation to report this bug. -- \ “We jealously reserve the right to be mistaken in our view of | `\ what exists, given that theories often change under pressure | _o__) from further investigation.” —Thomas W. Clark, 2009 | Ben Finney signature.asc Description: PGP signature
Bug#1063889: Parse package version string using ‘python3-debian’ class ‘debian.debian_support.Version’
Package: dput Version: dput Severity: minor The ‘dput.source_check’ function currently uses a custom regex pattern for parsing a package version string. This pattern differs in some ways from the official Debian Policy definition of a version string. Instead of custom parsing, re-write the check to use the functionality provided by the ‘python3-debian’ package. In ‘debian.debian_support’ is a ‘Version’ class whose constructor parses a package version string into the defined structure of a Debian package version. This will introduce a “Depends: python3-debian” relationship to this package. -- \ “He that would make his own liberty secure must guard even his | `\ enemy from oppression.” —Thomas Paine | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1061783: apprise fails its autopkg tests with Python 3.12
Howdy Andreas, On 07-Feb-2024, Andreas Tille wrote: > Hi Ben, > > I noticed that apprise version 0.5.1-4 has a bug since its autopkgtest > fails with Python3.12. I'd happily fix packages in Debian Python Team > but your package is not team maintained. Do you have any reason for > this? The package metadata for ‘apprise’ tells me its maintainer is: Maintainer: Debian Python Team http://deb.debian.org/debian/pool/main/a/apprise/apprise_1.7.2-1.dsc> so I think you might have the information mixed up? You are talking about “version 0.5.1-4”, so maybe you are referring to a different package? -- \ “Speech is human, silence is divine, yet also brutish and dead: | `\ therefore we must learn both arts.” —Thomas Carlyle, 1830 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1054726: python-daemon: FTBFS: ValueError: ("Missing 'Version:' header and/or PKG-INFO file at path: /<>/python_daemon.egg-info/PKG-INFO", python-daemon [unknown version] (/<
Control: notfound -1 python-daemon/3.0.1-1.1 Control: reassign -1 dh-python Control: found -1 dh-python/6.20231025 Control: retitle -1 dh-python: Packages FTBFS because of missing metadata Control: fixed -1 dh-python/6.20231204 Control: fixed -1 dh-python/6.20231223 On 16-Dec-2023, s3v wrote: > I've just checked your package does build fine in a sid chroot > environment and reproducible-builds confirms that Thank you. When I build in an up-to-date ‘unstable’ (where ‘dh-python’ is at version “6.20231223”), I also get a successful build from source today. > it was built against dh-python/6.20231025 but the current version in sid is > dh-python/6.20231204. I can reproduce the failure with this commit reverted Agreed, this bug was in ‘dh-python’ and is now fixed. -- \ “I was stopped by the police for speeding; they said ‘Don't you | `\ know the speed limit is 55 miles an hour?’ I said ‘Yeah I know, | _o__) but I wasn't going to be out that long.’” —Steven Wright | Ben Finney signature.asc Description: PGP signature
Bug#1055824: python3-rich: violates Python package metadata with dependency package 'python3-markdown-it' 3.0.0-2
Control: tags -1 + upstream patch
On 12-Nov-2023, Ben Finney wrote:
> Either:
>
> * The upstream version constraint needs to be relaxed by the upstream
> project, to allow ‘python3-rich’ version “3.0.0-2” to satisfy the
> dependency.
This is the resolution indicated by the upstream code base. In versions
starting at “13.4.2”, the upstream project declares dependencies that allow
‘markdown-it-py’ version “3.0.0” also.
https://github.com/Textualize/rich/commit/f232e9d95bbe4747f12459d5935cfa2a42c08069>
This can be applied with a simple patch:
=
diff --git old/pyproject.toml new/pyproject.toml
--- old/pyproject.toml
+++ new/pyproject.toml
@@ -30,7 +30,7 @@
typing-extensions = { version = ">=4.0.0, <5.0", python = "<3.9" }
pygments = "^2.14.0"
ipywidgets = { version = ">=7.5.1,<9", optional = true }
-markdown-it-py = "^2.1.0"
+markdown-it-py = ">=2.1.0"
[tool.poetry.extras]
jupyter = ["ipywidgets"]
=
or by upgrading Debian's ‘rich’ package source, to upstream's version
“13.4.2” or later.
--
\ “You can never entirely stop being what you once were. That's |
`\ why it's important to be the right person today, and not put it |
_o__) off until tomorrow.” —Larry Wall |
Ben Finney
signature.asc
Description: PGP signature
Bug#1055824: python3-rich: violates Python package metadata with dependency package 'python3-markdown-it' 3.0.0-2
On 12-Nov-2023, Sandro Tosi wrote: > > The inconsistent constraints need to be resolved; > > no they dont. debian uses apt not pip to install packages. The ‘pip’ command-line tool can also query which packages Python knows are installed, and that uses the database derived from Python package metadata. So, the Python metadata installed by the Debian package needs to be consistent with the dependencies. > from a packaging perspective, what matter is "does rich work?" and since > the answer is "yes" In the aspect of Python giving the correct answer from a query using ‘pip’, it isn't working. This is because the query is not of the Debian package database, but the Python metadata. This can be resolved by making the Debian dependencies and the Python metadata declared dependencies, consistent. Please address this so that the Python standard ‘pip’ tool can get the correct information from the Python metadata installed by these Debian packages. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney signature.asc Description: PGP signature
Bug#1055824: python3-rich: violates Python package metadata with dependency package 'python3-markdown-it' 3.0.0-2
Package: python3-rich Version: 13.3.1-2 Severity: normal Howdy, The Debian binary package ‘python3-rich’ declares: Depends: python3-markdown-it with no version constraint. On this machine, the dependency is satisfied by the only available version ‘python3-markdown-it’ version “3.0.0-2”. The Python metadata installed by the Debian ‘python3-rich’ package declares a constrained version range for that corresponding dependency: Requires-Dist: markdown-it-py (>=2.1.0,<3.0.0) This results in the Python ‘pip’ package dependency graph reporting (correctly) that its version constraints are not satisfied by the installed packages: INFO: pip is looking at multiple versions of rich to determine which version is compatible with other requirements. This could take a while. ERROR: Could not find a version that satisfies the requirement markdown-it-py<3.0.0,>=2.1.0 (from rich) (from versions: none) The inconsistent constraints need to be resolved; the Python package metadata dependency declarations need to be satisfied when the Debian package is installed. Either: * The upstream version constraint needs to be relaxed by the upstream project, to allow ‘python3-rich’ version “3.0.0-2” to satisfy the dependency. or * The Debian package needs to constrain its dependency on ‘python3-rich’ to match upstream's declared constraints. -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-rich depends on: ii python3 [python3-supported-min] 3.11.4-5+b1 ii python3-markdown-it 3.0.0-2 ii python3-pygments 2.15.1+dfsg-1 ii python3-typing-extensions4.7.1-2 python3-rich recommends no packages. python3-rich suggests no packages. -- no debconf information
Bug#1055769: blag: add dependency “Suggests” for documentation
Source: blag Version: 2.2.0 Severity: minor Dear Maintainer, Working with the ‘blag’ package requires understanding how it works and what it does. Please set a “Suggests: blag-doc” dependency to the binary package ‘blag’. This will present the suggestion to administrators choosing which packages to install. -- \“There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | Ben Finney signature.asc Description: PGP signature
Bug#1053384: RFP: elpa-gdscript-mode -- Emacs mode for editing GDScript program code
Package: wnpp Severity: wishlist * Package name: emacs-gdscript-mode Version : 1.4.0 Upstream Contact: xiliuya * URL : https://github.com/godotengine/emacs-gdscript-mode * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs mode for editing GDScript program code This package installs an Emacs major mode for editing code in the GDScript programming language. It gives syntax highlighting and indentations. The GDScript language is the native programming language for writing scripts in the Godot game engine. -- \ “The only tyrant I accept in this world is the still voice | `\ within.” —Mohandas K. Gandhi | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#802284: git-buildpackage: should assemble overlay before issuing 'debian/rules' commands
Control: found -1 git-buildpackage/0.9.32 Control: block 1045476 by -1 Control: block 1046726 by -1 Control: block 1047140 by -1 Control: block 1047269 by -1 Control: block 1047406 by -1 Control: block 1047672 by -1 Control: block 1048821 by -1 Control: summary -1 0 Git-BuildPackage should assemble the package source as an overlay, *before* calling ‘debuild -S’ or ‘debian/rules clean’ or anything else which requires the source assembled in that directory. For the benefit of readers of the blocked bug reports: Bug#802284 describes the behaviour that Git-BuildPackage is incorrectly attempting to run ‘debian/rules clean’ before it has assembled a source working tree for building. On 19-Oct-2015, Guido Günther wrote: > […] just setting the cleaner to /bin/true works around this […] In many packages I have followed this advice while waiting for this bug to be fixed. It has worked around the issue until now. However, there are now several bugs reported that are *caused* by setting the ‘cleaner’ to a no-op. I am marking this bug as blocking resolution of those bugs. -- \ “Are you pondering what I'm pondering?” “I think so, Brain, but | `\why would anyone want a depressed tongue?” —_Pinky and The | _o__) Brain_ | Ben Finney signature.asc Description: PGP signature
Bug#802284: git-buildpackage: should assemble overlay before issuing 'debian/rules' commands
Control: found -1 git-buildpackage/0.9.32 Control: block 1045476 by -1 Control: block 1046726 by -1 Control: block 1047140 by -1 Control: block 1047269 by -1 Control: block 1047406 by -1 Control: block 1047672 by -1 Control: block 1048821 by -1 Control: summary -1 0 Git-BuildPackage should assemble the package source as an overlay (when “overlay” is specified), *before* calling ‘debuild -S’ or ‘debian/rules clean’ or anything else which requires the source assembled in that directory. For the benefit of readers of the blocked bug reports: Bug#802284 needs to be resolved, by having Git-BuildPackage not attempt to run ‘debian/rules’ until the source working tree is assembled correctly. Currently it attempts to run ‘debian/rules clean’ in a tree that does not yet have the upstream source, so the build fails. On 19-Oct-2015, Guido Günther wrote: > […] just setting the cleaner to /bin/true works around this […] I have followed this advice in many packages as a workaround for this bug. Now though, there are a number of bugs in those packages that are *caused* by making the 'clean' command a no-op. I am marking this bug as blocking resolution of those reports. -- \ “Probably the earliest flyswatters were nothing more than some | `\sort of striking surface attached to the end of a long stick.” | _o__) —Jack Handey | Ben Finney signature.asc Description: PGP signature
Bug#1041586: src:pyethash: Migrate away from obsolete ‘distutils’
Source: pyethash Version: 0.1.27-2 Severity: important Tags: upstream Forwarded: https://github.com/ethereum/ethash/issues/141 The upstream source uses the Python ‘distutils’ module. In Python 3.10 and 3.11, Distutils has been formally marked as deprecated. Code that imports ‘distutils’ will no longer work from Python 3.12. The upstream source needs to migrate to modern Python build tools. -- \ “If you don't fail at least 90 percent of the time, you're not | `\aiming high enough.” —Alan Kay | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1041240: Extracting AutoPkgTest smoke test code to separate package
Control: block 1040846 by -1 Control: block 1040848 by -1 Control: block 1040849 by -1 Control: block 1040850 by -1 Control: block 1040851 by -1 Control: block 1040852 by -1 Control: block 1040853 by -1 Control: block 1040854 by -1 The new package ‘python3-package-smoke-test’ contains a single-installation version of the Python code for these AutoPkgTests. It allows maintaining and improving that code in one place, not spread among many packages. When this package is in Debian, I will be able to update dependent packages to use this for their AutoPkgTest implementation. -- \ “Wrinkles should merely indicate where smiles have been.” —Mark | `\Twain, _Following the Equator_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1041240: ITP: python-package-smoke-test -- simple import test for Python packages
Package: wnpp Owner: Ben Finney Severity: wishlist * Package name: python-package-smoke-test Version : 1.0 Upstream Author : Ben Finney * URL or Web page : https://pypi.org/project/package-smoke-test/ * License : GPL-3+ Description : simple import test for Python packages This library implements a set of simple verification tests for an installed Python distribution, or an installed Python module. -- \“It is undesirable to believe a proposition when there is no | `\ ground whatever for supposing it true.” —Bertrand Russell, _The | _o__) Value of Scepticism_, 1928 | Ben Finney signature.asc Description: PGP signature
Bug#944757: endless-sky: please package Endless Sky 0.9.10
On 26-Nov-2022, Damyan Ivanov wrote: > There are more (minor) problems with the copyright summary. I will create > issues/PRs about them for easier tracking (one already created - #7711). Upstream issue #7711 has been closed as resolved, by merging some changes to the copyright information. https://github.com/endless-sky/endless-sky/pull/7881> Does that resolve the copyright issues for this Debian bug report? What remains to be done before we can release an updated package? -- \ “We can't depend for the long run on distinguishing one | `\ bitstream from another in order to figure out which rules | _o__) apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 | Ben Finney signature.asc Description: PGP signature
Bug#733061: Bug#734435: notmuch-emacs: Emacs cannot load package notmuch
Control: fixed -1 elpa-notmuch/0.37-1 Control: fixed -1 emacsen-common/3.0.5 On 03-Jun-2023, Nicholas D Steeves wrote: > Ben Finney writes: > > > This still occurs for me with ‘notmuch-emacs’ 0.17-3, and > > ‘emacsen-common’ 2.0.7. > > It seems to me that this was fixed somewhere along the way. Would you > please confirm this bug is fixed and/or go ahead and close it? Yes, the behaviour no longer occurs when I install ‘elpa-notmuch’ version 0.37-1 with Emacs ‘emacsen-common’ version 3.0.5. I'm marking those versions as fixing this bug. Let's hear from the other reporters before deciding whether to close this reports. -- \ “A politician is an animal which can sit on a fence and yet | `\ keep both ears to the ground.” —Henry L. Mencken | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1028499: RM: pysha3 -- ROM; FTBFS, Bug#1028498
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: pys...@packages.debian.org Control: affects -1 + src:pysha3 The source package ‘pysha3’ fails to build on Debian with the supported Python 3.11 version. This is detailed in Debian bug#1028498 https://bugs.debian.org/1028498>. The package is unmaintained upstream. Fixing the bug appears to require significant changes in the underlying C library code. The package is a library for applications, and has no reverse dependencies in Debian “unstable”. I (the package maintainer) hereby request removal of package ‘pysha3’ from Debian. -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1028498: pysha3: FTBFS, “error: lvalue required as left operand of assignment”
Source: pysha3
Version: 1.0.2-5
Severity: serious
Tags: upstream ftbfs
Justification: Policy 4.9, FTBFS
Howdy,
When attempting to build the package from source using the Python 3.11
development libraries, this package fails to build. The relevant build
process output is:
=
running build_ext
building '_pysha3' extension
creating build/temp.linux-x86_64-cpython-311
creating build/temp.linux-x86_64-cpython-311/Modules
creating build/temp.linux-x86_64-cpython-311/Modules/_sha3
x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
-DPY_WITH_KECCAK=1 -I/usr/include/python3.11 -c Modules/_sha3/sha3module.c -o
build/temp.linux-x86_64-cpython-311/Modules/_sha3/sha3module.o
Modules/_sha3/sha3module.c: In function ‘PyInit__pysha3’:
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:744:5: note: in expansion of macro ‘init_sha3type’
744 | init_sha3type("sha3_224", _224type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:745:5: note: in expansion of macro ‘init_sha3type’
745 | init_sha3type("sha3_256", _256type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:746:5: note: in expansion of macro ‘init_sha3type’
746 | init_sha3type("sha3_384", _384type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:747:5: note: in expansion of macro ‘init_sha3type’
747 | init_sha3type("sha3_512", _512type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:749:5: note: in expansion of macro ‘init_sha3type’
749 | init_sha3type("keccak_224", _224type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:750:5: note: in expansion of macro ‘init_sha3type’
750 | init_sha3type("keccak_256", _256type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:751:5: note: in expansion of macro ‘init_sha3type’
751 | init_sha3type("keccak_384", _384type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:752:5: note: in expansion of macro ‘init_sha3type’
752 | init_sha3type("keccak_512", _512type);
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:754:5: note: in expansion of macro ‘init_sha3type’
754 | init_sha3type("shake_128", );
| ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of
assignment
734 | Py_TYPE(type) = _Type; \
| ^
Modules/_sha3/sha3module.c:755:5: note: in expansion of macro ‘init_sha3type’
755 | init_sha3type("shake_256", );
| ^
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
E: pybuild pybuild:388: build: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py build
=
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
\ “Marriage is a wonderful institution, but who would want to |
`\live in an institution
Bug#1028494: pysha3: FTBFS, expects Python header file ‘pystrhex.h’ removed in Python 3.11
Control: retitle -1 pysha3: FTBFS, expects Python header file ‘pystrhex.h’ removed in Python 3.11 Control: forwarded -1 https://github.com/tiran/pysha3/issues/15 Control: tags -1 + upstream confirmed Thanks Adrian, On 12-Jan-2023, Adrian Bunk wrote: > In file included from Modules/_sha3/sha3module.c:20: > Modules/_sha3/backport.inc:78:10: fatal error: pystrhex.h: No such file or > directory >78 | #include "pystrhex.h" This is reported at the upstream project as a known bug https://github.com/tiran/pysha3/issues/15>. Fortunately, the code base already has a fallback local implementation of the function, and upstream have already fixed this bug by using that local implementation unconditionally. I will incorporate that change in a new Debian release of this package. -- \ “Anyone who believes exponential growth can go on forever in a | `\finite world is either a madman or an economist.” —Kenneth | _o__) Boulding, 1973 | Ben Finney signature.asc Description: PGP signature
Bug#1028107: sigil: versioned dependency on 'sigil-data' is too strict
Package: sigil
Version: 1.9.20+dfsg-1
Severity: important
Justification: renders some versions uninstallable
The binary ‘sigil’ package has a strict versioned dependency on
‘sigil-data’, “Depends: sigil-data (= ${source:Version})”.
This allows precisely one Debian release and will forbit installation if
that version of ‘sigil-data’ is not available.
This causes the package to be uninstallable when, for example, a recompiled
package is released. (Hence the “Severity: important” for this bug report.)
Debian currently has ‘sigil’ version “1.9.20+dfsg-1+b1”, which cannot
install because it “Depends: sigil-data (= 1.9.20+dfsg-1+b1)”, which does
not exist.
Instead, the dependency should be relaxed. Is there a good reason to
version this dependency?
If a version is needed, can it be relaxed to “1.9.20+dfsg~” or similar?
--
\ “Two paradoxes are better than one; they may even suggest a |
`\ solution.” —Edward Teller |
_o__) |
Ben Finney
signature.asc
Description: PGP signature
Bug#840160: RFP: mullvad-client -- client for VPN service Mullvad
On 06-Jan-2023, Rock Storm wrote: > A long time ago you requested/volunteered to package the Mullvad client > app. Did you get anywhere with it? I did not; the bug report #840160 was correctly retitled to an RFP and I no longer intend to create or maintain that package. > May I know what were the issues (if any) why this app never made it into > the archive? At the time of declaring the ITP, I was in private communication with the Mullvad developers. They told me the code was ready to be published as free software "soon" and that they'd be getting back to me when it was ready. They did not contact me again, and I don't know anything more from them. > I thought of packaging and had a look at the app's code on GitHub and it > looks quite a complex app now written in languages I'm not familiar with > (yet). So any insights would be appreciated. I wish you luck! It would be good to get the Mullvad VPN client in shape for Debian. -- \ “The greater the artist, the greater the doubt; perfect | `\ confidence is granted to the less talented as a consolation | _o__) prize.” —Robert Hughes | Ben Finney signature.asc Description: PGP signature
Bug#1027992: towncrier: Remove temporary files created during build
Control: retitle -1 towncrier: Remove temporary files created during build
Control: tags -1 + pending
On 05-Jan-2023, Chris Lamb wrote:
> This is because the testsuite generates a bunch of Python modules with
> nondeterminstic contents, which then get installed into the binary
> package.
Thanks. Specifically, these are created by Twisted Trial and then left
behind as cruft.
> Patch attached that cleans these up after running the tests.
Since the files are created during PyBuild's operation, I prefer to
instruct PyBuild how to clean it up.
I have applied this change:
=
modified debian/changelog
@@ -4,6 +4,7 @@ towncrier (21.9.0-3) UNRELEASED; urgency=medium
* Declare Build-Depends for architecture-independent packages.
* Remove a Lintian override for documentation files in wrong directory.
The files should in fact not be in the package; Lintian is correct.
+ * Remove cruft from the build directory left there by Twisted Trial.
--
modified debian/rules
@@ -17,6 +17,10 @@ export PYBUILD_INSTALL_ARGS = \
export http_proxy = http://127.0.1.1:9/
export https_proxy = ${http_proxy}
+# Twisted Trial creates temporary Python modules and doesn't clean up.
+twisted_trial_cruft = ${MAIN_PYTHON_PACKAGE}.test.*
+export PYBUILD_AFTER_TEST = rm -r "{build_dir}"/${twisted_trial_cruft}
+
␌
%:
dh $@ --with python3 --buildsystem=pybuild
=
--
\ “Pinky, are you pondering what I'm pondering?” “Well, I think |
`\so, Brain, but I can't memorize a whole opera in Yiddish.” |
_o__) —_Pinky and The Brain_ |
Ben Finney
signature.asc
Description: PGP signature
Bug#1026375: recutils: Installs startup handler for Emacs Lisp files that are no longer installed
Howdy Sven, On 19-Dec-2022, Sven Wick wrote: > I am not a Emacs user myself, > but try to make the package working well for everybody. Likewise, I am a user but not skilled at the packaging of Emacs files in Debian. > I will take a look at it and fix it... If I understand correctly (probably I don't!), that configuration file is needed only when the package installs Emacs Lisp files. Does the package install any Emacs Lisp files now? If not, probably that configuration file can simply be removed. But I don't know if there is some versioned migration (e.g. clean up of existing files?) that needs to happen. -- \ “The Things to do are: the things that need doing, that you see | `\ need to be done, and that no one else seems to see need to be | _o__) done.” —Richard Buckminster Fuller, 1970-02-16 | Ben Finney signature.asc Description: PGP signature
Bug#1026375: recutils: Installs startup handler for Emacs Lisp files that are no longer installed
Package: recutils Version: 1.9-1 Severity: normal Howdy, The Debian release “1.9-1” of ‘recutils’ correctly notes that the Emacs Lisp files (‘ob-rec.el’, ‘rec-mode.el’) are no longer installed. But the package continues to install Emacs startup code which expects the ‘rec-mode.el’ as part of the package: = debian/recutils.emacsen-startup […] (cond ((not (file-exists-p "/usr/share/emacs/site-lisp/rec-mode.el")) (message "recutils removed but not purged, skipping setup")) […] = The package should cleanly install and not cause Emacs to expect ELisp files that are not installed. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages recutils depends on: ii libc6 2.36-6 ii libgcrypt20 1.10.1-3 ii libreadline8 8.2-1.2 ii librec1 1.9-1 recutils recommends no packages. recutils suggests no packages. -- no debconf information -- \ “It is the fundamental duty of the citizen to resist and to | `\ restrain the violence of the state.” —Noam Chomsky, 1971 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1024148: python3-coverage: Python 3.11 support incomplete due to ignored error during build
Howdy Stefano, On 16-Nov-2022, Debian Bug Tracking System wrote: > > forwarded 1024148 https://github.com/nedbat/coveragepy/issues/1367 > Bug #1024148 [python3-coverage] python3-coverage: Python 3.11 support > incomplete due to ignored error during build > Set Bug forwarded-to-address to > 'https://github.com/nedbat/coveragepy/issues/1367'. Thank you for finding the existing upstream bug report, and recording this metadata. On 16-Nov-2022, Stefano Rivera wrote: > I've prepared an NMU for python-coverage (versioned as 6.2+dfsg1-2.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I should delay > it longer. Yes, please delay that; in investigating this bug report I saw (as you have, by now) that upstream's current version “6.5.0” addresses this bug. I am working to package and release that for Debian. -- \ “Nothing is so common as to imitate one's enemies, and to use | `\ their weapons.” —Voltaire, _Dictionnaire Philosophique_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1023080: lists.debian.org: Add a 'pkg-sourcehut' mailing list
Package: lists.debian.org Severity: wishlist X-Debbugs-Cc: de...@laxalde.org Howdy list masters, This request is for the addition of a mailing list for the Debian SourceHut Packaging Team. Name: pkg-sourcehut (The naming convention might dictate a different name, such as ‘debian-pkg-sourcehut’.) Synopsis: Debian packaging team for the SourceHut development forge Description: Discussion of Debian packages for installing the SourceHut development forge on Debian. This is the primary discussion forum for the Debian SourceHut Packaging Team. SourceHut is a development forge with many services to help software projects; see https://sourcehut.org/. Ths Debian SourceHut Packaging Team works to make packages to install SourceHut to run on a Debian host. Category: Development Subscription policy: open Post policy: open Web Archive: yes
Bug#955763: python3-coverage: Entry point error on some supported Python versions
Control: tags -1 - moreinfo + confirmed
Control: retitle -1 python3-coverage: Entry point error on some supported
Python versions
Control: found -1 python3-coverage/6.2+dfsg1-2
Control: summary -1 0
The upstream install script does not handle all Debian supported
Python versions.
This is caused by the hard-coding of only the default Python
interpreter during installation of console scripts. The result is that
any other Python version does not have a working entry point:
$ python3-coverage --version
Coverage.py, version 6.2 with C extension
Full documentation is at https://coverage.readthedocs.io
$ python3.9-coverage --version
Coverage.py, version 6.2 with C extension
Full documentation is at https://coverage.readthedocs.io
$ python3.10-coverage --version
Traceback (most recent call last):
File "/usr/bin/python3.10-coverage", line 33, in
sys.exit(load_entry_point('coverage==6.2', 'console_scripts',
'python3.10-coverage')())
File "/usr/bin/python3.10-coverage", line 25, in
importlib_load_entry_point
return next(matches).load()
StopIteration
On 04-Apr-2020, Uwe Hermann wrote:
> Adding the following line to
> /usr/lib/python3/dist-packages/coverage-4.5.2.egg-info/entry_points.txt
> seems to fix it:
>
> python3.8-coverage = coverage.cmdline:main
That would get a command that runs, yes; but it does not specifically
target Python 3.8 as intended.
Instead, the installation procedure needs to be changed so that it
specifically installs console scripts with each correct Python
interpreter shebang line.
--
\ “Earth gets its price for what Earth gives us.” —James Russell |
`\Lowell |
_o__) |
Ben Finney
signature.asc
Description: PGP signature
Bug#1014182: bug script fails
Control: retitle -1 ‘dput --print’ fails: “No package or host has been provided” Control: tags -1 + confirmed On 01-Jul-2022, Ben Hutchings wrote: > The last command in the bug script is "dput --print", which no longer > works and exits with return code 64. Ah okay, I misunderstood. The error message from that command (executed within the Reportbug script) is: No package or host has been provided, see dput -h and the exit status from DPut is 64, which tells Reportbug the script failed. -- \ “I was the kid next door's imaginary friend.” —Emo Philips | `\ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1012086: Merge request available to fix this bug
Control: tags -1 + patch I have created a merge request to address this bug and others. https://salsa.debian.org/debian/devscripts/-/merge_requests/265> The merge request is clean against the current HEAD of the Git repository for ‘devscripts’. The changes address these bugs: Bug#1012086: debsign: Bash completion has incorrect handling for version option Bug#1012156: debsign: Bash command completion fails to match existing files Bug#1012158: debsign: Bash command completion not handling arguments for some existing options -- \“There are only two ways to live your life. One is as though | `\ nothing is a miracle. The other is as if everything is.” | _o__) —Albert Einstein | Ben Finney signature.asc Description: PGP signature
Bug#1012158: debsign: Bash command completion not handling arguments for some existing options
Package: devscripts Version: 2.22.1 Severity: normal The Bash command completion defined for ‘debsign’ does not correctly handle the required arguments for some existing options. The ‘-r’, ‘-m’, ‘-p’, ‘-a’, ‘-t’, ‘--debs-dir’ options each require an argument to follow. The command completion does not handle these specially, and will provide completions for an option or filename, which is incorrect for these options. Instead, when completing the word following one of these options, the completion options should generate completions specifically tailored (where feasible) to the expected argument type. -- \ “Programs must be written for people to read, and only | `\incidentally for machines to execute.” —Abelson & Sussman, | _o__) _Structure and Interpretation of Computer Programs_ | Ben Finney signature.asc Description: PGP signature
Bug#1012156: debsign: Bash command completion fails to match existing files
Package: devscripts Version: 2.22.1 Severity: normal The definition of command completion for the ‘debsign’ file path argument, fails to match existing directories: $ ls ../build-area/foo_1.5-3* ../build-area/foo_1.5-3.debian.tar.gz ../build-area/foo_1.5-3.diff.gz ../build-area/foo_1.5-3.dsc ../build-area/foo_1.5-3_source.changes $ debsign ../bui → (no completion) $ debsign ../build-area/foo_ → ../build-area/foo_1.5-3 Both these attempts to use command completion should result in matches. -- \ “Whatever you do will be insignificant, but it is very | `\important that you do it.” —Mohandas K. Gandhi | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1012086: debsign: Bash completion has incorrect handling for version option
Package: devscripts Version: 2.22.1 Severity: normal The Bash completion for the ‘debsign’ command is incorrectly defined. It incrrectly recognises a ‘-version’ option that does not exist; and fails to recognise the real ‘--version’ option. $ debsign -ve → debsign -version debsign: invalid option -- 'v' $ debsign --ve → (no completion)
Bug#1010904: jquery-at.js: replace node-gulp-util build dependency with node-fancy-log
Control: summary -1 0 Control: tags -1 - patch The ‘gulp-util’ source fails to build in Debian; that package will drop its ‘util’ module and dependent packages are advised to migrate to other libraries. For ‘jquery-at.js’, the API ‘util.log’ needs a replacement. On 12-May-2022, Pirate Praveen wrote: > Control: tags -1 patch > > Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010895 for > details about removing node-gulp-util from the archive Thanks for the report. As far as I can determine, the relevant infromation for this package is: * Debian ‘node-gulp-util’ is dropping its ‘util’ module. * The ‘jquery-at.js’ source package uses ‘util.log’, which will no longer be provided by ‘node-gulp-util’. * The ‘node-fancy-log’ Debian package provides a ‘fancylog’ API which is a sufficient replacement. > I have sent a merge request with a patch > https://salsa.debian.org/debian/pkg-jquery-at.js/-/merge_requests/2 Thank you; that merge request does not contain the changes needed. I have posted a review on that merge request. Meanwhile I will work on implementing a fix for this bug. -- \ “Now Maggie, I’ll be watching you too, in case God is busy | `\ creating tornadoes or not existing.” —Homer, _The Simpsons_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#783396: python3-irc: New upstream version 20.0.0
Control: block -1 by 1010782 1010783 1010784 Control: noowner 1010782 Control: noowner 1010783 Control: noowner 1010784 -- \ “Compulsory unification of opinion achieves only the unanimity | `\of the graveyard.” —Justice Roberts in 319 U.S. 624 (1943) | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#783396: python3-irc: new upstream version depends on more unpackaged Python libraries
Control: submitter 1010782 ! Control: submitter 1010783 ! Control: submitter 1010784 ! On 10-May-2022, Ben Finney wrote: > I am creating new WNPP bug reports for the dependencies that are not > yet in Debian. -- \ “My girlfriend has a queen sized bed; I have a court jester | `\ sized bed. It's red and green and has bells on it, and the ends | _o__) curl up.” —Steven Wright | Ben Finney signature.asc Description: PGP signature
Bug#783396: python3-irc: New upstream version 20.0.0
Control: block -1 1010782 1010783 1010784 Control: summary 1010782 Upstream source for this package is published at https://pypi.org/project/jaraco.logging/ Control: outlook 1010782 Control: summary 1010783 Upstream source for this package is published at https://pypi.org/project/jaraco.stream/ Control: outlook 1010783 Control: summary 1010784 Upstream source for this package is published at https://pypi.org/project/rst.linker/ Control: outlook 1010784 On 10-May-2022, Ben Finney wrote: > I am creating new WNPP bug reports for the dependencies that are not > yet in Debian. Those dependencies will need to be packaged before this bug can be fixed. -- \ “Yesterday I parked my car in a tow-away zone. When I came back | `\ the entire area was missing.” —Steven Wright | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#783396: python3-irc: new upstream version depends on more unpackaged Python libraries
Control: outlook -1 0 Control: retitle -1 python-irc: New upstream version 20.0.0 Control: clone -1 -2 Control: retitle -2 RFP: python3-jaraco.logging -- Functions to integrate argparse with logging — Python 3 Control: reassign -2 wnpp Control: clone -1 -3 Control: retitle -3 RFP: python3-jaraco.stream -- Functions for handling streaming data — Python 3 Control: reassign -3 wnpp Control: clone -1 -4 Control: retitle -4 RFP: python3-sphinx-rst-linker -- Sphinx extension for custom URL replacement — Python 3 Control: reassign -4 wnpp The recent upstream versions depend on additional Python libraries that are not yet packaged in Debian. On 03-May-2020, Iain Learmonth wrote: > I just went to hack on something with the python3-irc package, but it > turns out that Debian is 10 versions behind. Thanks for asking. This is tracked in Debian bug#783396. > Is there some reason that we've held back the version of python3-irc? As described in that bug report, many new dependencies have arisen for the upstream ‘irc’ library in recent versions. > Can I help? I am creating new WNPP bug reports for the dependencies that are not yet in Debian. -- \ “I lost a button-hole.” —Steven Wright | `\ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1010651: debmake: add dependency “Suggests” for documentation
Control: tags -1 + patch On 06-May-2022, Ben Finney wrote: > Please set a “Suggests: debmake-doc” dependency to the binary > package ‘debmake’. The branch ‘wip/issue/1010651/dependency-for-documentation’ https://salsa.debian.org/bignose/debmake/-/commits/wip/issue/1010651/dependency-for-documentation> addresses this bug. The branch currently merges cleanly to the ‘main’ branch. -- \ “If you can do no good, at least do no harm.” —_Slapstick_, | `\ Kurt Vonnegut | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1010651: debmake: add dependency “Suggests” for documentation
Package: debmake Version: 4.3.2-1.1 Severity: minor Dear Maintainer, Working with the ‘debmake’ package requires understanding how it works and what it does. Please set a “Suggests: debmake-doc” dependency to the binary package ‘debmake’. This will present the suggestion to administrators choosing which packages to install. -- \ “Dare to be naïve.” —Richard Buckminster Fuller, personal motto | `\ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#745763: license-problem-non-free-RFC: False positive when describing license conditions
Control: retitle -1 license-problem-non-free-RFC: False positive when describing license conditions On 26-Apr-2014, Lisandro Damián Nicanor Pérez Meyer wrote: > On Sunday 27 April 2014 02:13:04 Bastien ROUCARIES wrote: > > Moreover in this case lintian is right because this file describe > > the license used by some of qt4-x11 code. For instance how can I > > programatically check if README license text apply to whole > > project or to only the README file* ? > > No, lintian is not right because it is pointing to the wrong file. Here's another example: https://salsa.debian.org/bignose/pkg-python-irc/-/blob/main/debian/README.source#L102> The mention of the RFC includes the copyright notice from that RFC, for the purpose of explaining why the RFC is *not* part of the Debian package. So Lintian should not raise a tag for that; it is a false positive. Please refine the Lintian check so that it does not catch documents which *describe* license conditions and do not *claim* those conditions on the package. -- \ “Know what I hate most? Rhetorical questions.” —Henry N. Camp | `\ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#740893: libjs-jquery-hotkeys: Incompatible ABI changes in library
Control: affects -1 - python-coverage On 25-May-2017, Ben Finney wrote: > Until the ‘libjs-jquery-hotkeys’ package resolves bug#740893, the > ‘python-coverage’ packages should not use that library. > > I will patch the ‘python-coverage’ source so it omits any use of > that library. This was done in Debian release “4.3.4+dfsg.1-1” of ‘python-coverage’. As of version 6.2, the Coverage.py code makes no use of that library. Debian includes this change as of release “6.2+dfsg1-1”. Now that every version of ‘python-coverage’ in Debian since “buster” has removed this library as a dependency, I am altering this bug report to record that it no longer affects ‘python-coverage’. -- \ “Faith, n. Belief without evidence in what is told by one who | `\ speaks without knowledge, of things without parallel.” —Ambrose | _o__) Bierce, _The Devil's Dictionary_, 1906 | Ben Finney signature.asc Description: PGP signature
Bug#740893: libjs-jquery-hotkeys: Incompatible ABI changes in library
Control: retitle -1 libjs-jquery-hotkeys: Incompatible ABI changes in library Control: tags -1 + upstream Control: summary -1 0 Some users of this library expect the ABI from ‘jeresig’ source, while the currently packaged library is from the ‘tzuryby’ source with an incompatible ABI. On 09-Apr-2017, Ben Finney wrote: > On 06-Apr-2017, Philipp Hahn wrote: > > > So "coverage_html.js" uses the 'jeresig' API to pass the hotkey > > via "data", while the 'tzuryby' API "jquery.hotkeys.js" expects is > > via 'namespace'. > > That's good investigation, thank you for that. > > > So all of them use the "jeresig" API, but 'libjs-jquery-hotkeys' > > packages the "tzuryby" API. > > We get differing results, so I'd like to better understand before > choosing how to resolve this. I am altering this bug report to describe the root problem to be addressed. -- \ “I used to think that the brain was the most wonderful organ in | `\ my body. Then I realized who was telling me this.” —Emo Philips | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#440253: Please package inform 7
On 30-Apr-2022, Diane Trout wrote: > As an update it appears that Inform7 was fully open sourced under > the artistic public license with redistribution of derived works > permission included. > > From https://github.com/ganelson/inform > "As from the first date of this repository becoming public, 28 April > 2022, the Package is placed under the Artistic License 2.0." That does seem clear; the full text at that URL (a couple of paragraphs) seems at first read to grant the necessary permissions for free software. Great news, thank you! -- \ “Earth gets its price for what Earth gives us.” —James Russell | `\Lowell | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1010459: RFA: pyrlp
Package: wnpp Severity: normal Control: affects -1 src:pyrlp The ‘pyrlp’ Debian package needs attention and maintenance from someone who makes real use of the library. -- \ “To have the choice between proprietary software packages, is | `\ being able to choose your master. Freedom means not having a | _o__)master.” —Richard M. Stallman, 2007-05-16 | Ben Finney signature.asc Description: PGP signature
Bug#1010241: libdebian-source-perl: Incorrect case sensitivity in Debian::Control::Stanza::new for field names
Package: libdebian-source-perl Version: 0.116 Severity: normal When parsing a Debian control stanza to an internal data structure, Debhelper uses ‘Debian::Control::Stanza’. The ‘new’ function attempts to match each field name to those names known for Debian control file stanzas. The matching is incorrectly case-sensitive. It should accept valid variations such as ‘VCS-Git’ and ‘VCS-Browser’, but instead it crashes: Invalid field given (VCS_Git) at /usr/share/perl5/Debian/Control.pm line 122. The matching should be case-insensitive, understanding ‘vcs-git’ and ‘VCS-Git’ and ‘Vcs-Git’ and ‘vcs-Git’ to all be the same field name. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libdebian-source-perl depends on: ii dpkg 1.21.7 ii dpkg-dev 1.21.7 ii libapt-pkg-perl 0.1.40+b1 ii libarray-unique-perl 0.08-2.1 ii libclass-accessor-perl0.51-1 ii liblist-moreutils-perl0.430-2 ii libparse-debcontrol-perl 2.005-4.1 ii libsub-install-perl 0.928-1.1 ii libtie-ixhash-perl1.23-2.1 ii libwww-mechanize-perl 2.06-1 ii libwww-perl 6.62-1 ii perl 5.34.0-4 libdebian-source-perl recommends no packages. libdebian-source-perl suggests no packages. -- no debconf information -- \ “He was the mildest-mannered man / That ever scuttled ship or | `\ cut a throat.” —“Lord” George Gordon Noel Byron, _Don Juan_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#944194: dput: Authenticated HTTP request raises AttributeError in Python >= 3.7
Control: tags -1 + confirmed pending
Control: retitle -1 dput: Authenticated HTTP request raises AttributeError in
Python >= 3.7
Control: summary -1 0
The ‘AuthHandlerHackAround’ class has fallen behind recent Python
implementation of ‘urllib.request.Request’ API. This causes users
expecting that API to crash with AttributeError.
On 05-Nov-2019, TQ Hirsch wrote:
> Uploading to hsg (via http to localhost:8123):
> Uploading thequux-apt-config_2019.11.02.dsc: need authentication.
> Traceback (most recent call last):
> File "/usr/bin/dput", line 11, in
> load_entry_point('dput==1.0.3', 'console_scripts', 'execute-dput')()
> File "/usr/share/dput/dput/dput.py", line 1156, in main
> files_to_upload, debug, 0, progress=progress)
> File "/usr/share/dput/dput/methods/http.py", line 154, in upload
> url, res.msg, pwman).get_auth_headers()
> File "/usr/share/dput/dput/methods/http.py", line 82, in get_auth_headers
> ah.http_error_401(self, None, 401, None, self.resp_headers)
> File "/usr/lib/python3.7/urllib/request.py", line 1025, in http_error_401
> url = req.full_url
> AttributeError: 'AuthHandlerHackAround' object has no attribute 'full_url'
The Python ‘urllib.request’ module is attempting to use an API not
implemented on ‘AuthHandlerHackAround’. I have implemented the changed
API on that fake class, and it will be part of the next ‘dput’ release.
Thank you for the report and analysis of the issue.
--
\ “Whatever a man prays for, he prays for a miracle. Every prayer |
`\ reduces itself to this: “Great God, grant that twice two be not |
_o__) four.”” —Ivan Turgenev |
Ben Finney
signature.asc
Description: PGP signature
Bug#976884: UDD: bug report title mangled to mojibake from valid UTF-8
Control: retitle -1 UDD: bug report title mangled to mojibake from valid UTF-8 On 08-Dec-2020, Felix Lechner wrote: > I had a very similar issue in Lintian's database a few weeks ago. It > was caused by uploading (properly UTF-8 encoded) JSON to Postgres. > The Perl driver DBD::Pg encoded the data again and picked the 7-bit > clean escape sequences according to RFC4627, which is what I believe > you are seeing. They are further described here: > > https://metacpan.org/pod/JSON::PP#ascii > > My solution was to disable the automatic decoding layer in DBD::Pg > via 'pg_enable_utf8 => 0'. It mirrors how I handle encoding > elsewhere (i.e. explicitly and without PerlIO, Bug#972878) and works > great […] Is the issue within DBD::Pg — should that Perl module default to expecting UTF-8 text like most of the rest of Debian? As another example, bug#1009426 has the valid UTF-8 title xkcdpass: FTBFS: test case raises “TypeError: … missing 1 required positional argument: 'self'” which is rendered correctly in bugs.debian.org web pages. But UDD renders it as: RC bug marked as done but still affects unstable: #1009426: xkcdpass: FTBFS: test case raises â��TypeError: â�¦ missing 1 required positional argument: 'self'â�� -- \ “Injustice is relatively easy to bear; what stings is justice.” | `\ —Henry L. Mencken | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1010191: xkcdpass: Option ‘--wordlist’ help text fails to mention the wordfile is ignored if missing
Control: tags -1 + upstream Control: forwarded -1 https://github.com/redacted/XKCD-password-generator/issues/147 Control: severity -1 minor On 20-Apr-2019, Ben Finney wrote: > I suspect this is because the program silently skips a specified > wordfile if it does not exist. The documentation for ‘--wordlist’ does not describe this behaviour. I have created an upstream bug report for this. -- \“I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.” —Douglas Adams | Ben Finney signature.asc Description: PGP signature
Bug#926696: xkcdpass: Should notify user when wordlist file not found
Control: tags -1 - moreinfo upstream Control: severity -1 wishlist On 20-Apr-2019, Ben Finney wrote: > I suspect this is because the program silently skips a specified > wordfile if it does not exist. It then has a set of wordfiles that > includes the defaults, but does not include the one you specified. Yes, this is definitely how the ‘--wordlist’ behaviour is defined: it specifies a wordlist file to use, but if the file does not exist it silently defaults to the built-in wordlist. (The documentation for the ‘--wordlist’ option does not describe that behaviour. I have created bug report #1010191 to change the documentation.) So this bug report is effectively a “Severity: wishlist” request to change that behaviour. I am modifying this bug report accordingly. -- \ “Very few things happen at the right time, and the rest do not | `\ happen at all. The conscientious historian will correct these | _o__) defects.” —Mark Twain, _A Horse's Tale_ | Ben Finney signature.asc Description: PGP signature
Bug#1010138: RFA: gandi-cli
Package: wnpp Severity: normal Control: affects -1 src:gandi-cli The ‘gandi-cli’ Debian package needs attention and maintenance from someone who makes real use of the Gandi.net service provider and can benefit from this command-line utility. -- \ “I call him Governor Bush because that's the only political | `\ office he's ever held legally.” —George Carlin, 2008 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1009426: xkcdpass: FTBFS: test case raises “TypeError: … missing 1 required positional argument: 'self'”
Control: tags -1 + confirmed upstream Control: forwarded -1 https://github.com/redacted/XKCD-password-generator/issues/138 Control: retitle -1 xkcdpass: FTBFS: test case raises “TypeError: … missing 1 required positional argument: 'self'” Control: summary -1 0 The upstream test suite has a buggy test case that is raising TypeError in recent Python versions. On 12-Apr-2022, Lucas Nussbaum wrote: > Relevant part (hopefully): > > […] > >dh_auto_test -O--buildsystem=pybuild > > I: pybuild base:239: python3.10 setup.py test > > running test > > […] > > > > == > > ERROR: test_entropy_printout_valid_input > > (tests.test_xkcdpass.TestEntropyInformation) > > -- > > TypeError: TestEntropyInformation.test_entropy_printout_valid_input() > > missing 1 required positional argument: 'self' > > > > -- > > Ran 9 tests in 0.189s > > > > FAILED (errors=1) > > […] I have described this error in the test case in the upstream issue https://github.com/redacted/XKCD-password-generator/issues/138>. -- \ “For every complex problem, there is a solution that is simple, | `\ neat, and wrong.” —Henry L. Mencken | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1006348: lintian: Tag improbable-bug-number-in-closes condition considers 7-digit bug numbers improbable
Control: block -1 by 1003272 Control: tags -1 + confirmed pending On 23-Feb-2022, Felix Lechner wrote: > Due to a new override format, which remained pending due to my > extremely critical commitment elsewhere, the change remains > unreleased. > > I hope to get to Bug#1003272 tomorrow or on Friday, with a release > soon after that. Thank you. I'm now recording that in the metadata for this bug report. -- \ “If you are unable to leave your room, expose yourself in the | `\window.” —instructions in case of fire, hotel, Finland | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1006348: lintian: Tag improbable-bug-number-in-closes condition considers 7-digit bug numbers improbable
On 24-Feb-2022, Ben Finney wrote:
> Currently the tag's condition matches all bug numbers 100 or
> higher:
>
> =
> W: xkcdpass: improbable-bug-number-in-closes 1006311
> =
>
> The maximum bug number should be increased to allow likely bug numbers
> for some number of years into the future.
I'm not clear on why this occurs. The relevant code appears to be in
‘lib/Lintian/Check/Debian/Changelog.pm’:
=
for my $bug (@{$latest_entry->Closes}) {
$self->pointed_hint('improbable-bug-number-in-closes',
$latest_pointer, $bug)
if $bug < $FIRST_ARCHIVED_BUG_NUMBER
|| $bug >= $OUT_OF_REACH_BUG_NUMBER;
}
=
where ‘$OUT_OF_REACH_BUG_NUMBER’ is defined in the same file:
=
const my $OUT_OF_REACH_BUG_NUMBER => 1_500_000;
=
Yet, with Lintian version 2.111.0, I get the tag raised for bug
numbers lower than that.
=
$ lintian --version
Lintian v2.111.0
$ lintian
[…]
W: xkcdpass: improbable-bug-number-in-closes 1006311
=
--
\ “Pity the meek, for they shall inherit the earth.” —Donald |
`\ Robert Perry Marquis |
_o__) |
Ben Finney
signature.asc
Description: PGP signature
Bug#1006348: lintian: Tag improbable-bug-number-in-closes condition considers 7-digit bug numbers improbable
Package: lintian Version: 2.111.0 Severity: normal Tags: patch The Debian bug tracker is well into 7-digit bug numbers now, so the ‘improbable-bug-number-in-closes’ condition should permit them. Currently the tag's condition matches all bug numbers 100 or higher: = W: xkcdpass: improbable-bug-number-in-closes 1006311 = The maximum bug number should be increased to allow likely bug numbers for some number of years into the future. I propose this change: - modified data/changelog-file/bugs-number @@ -1,4 +1,4 @@ -# before 50004 but were removed not archived +# Before 50004, bugs were removed not archived. min-bug = 50004 -# a bug number likely for in future -max-bug = 100 \ No newline at end of file +# A bug number likely far in the future. +max-bug = 200 - -- \“Kill myself? Killing myself is the last thing I'd ever do.” | `\—Homer, _The Simpsons_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1006347: lintian: Tag ‘improbable-bug-number-in-closes’ description inaccurate
Package: lintian Version: 2.111.0 Severity: minor Tags: patch The description for Lintian tag ‘improbable-bug-number-in-closes’ currently reads: The most recent changelog closes a bug numbered less than 2000. While this is distantly possible, it's more likely a typo or a placeholder value that mistakenly wasn't filled in. That implies the tag will not match any bug number 2000 or higher. That description is inaccurate and misleading. The condition currently matches any bug number < 50004 (so, higher than the 2000 described); and matches any bug number > 100 (the description does not mention any upper limit). I suggest this change to the description, to accurately represent the condition: - modified checks/changelog-file.desc @@ -268,9 +268,10 @@ Ref: devref 6.3.4 Tag: improbable-bug-number-in-closes Severity: normal Certainty: possible -Info: The most recent changelog closes a bug numbered less than 2000. - While this is distantly possible, it's more likely a typo or a - placeholder value that mistakenly wasn't filled in. +Info: The most recent changelog closes a bug report with a number that + is very low or very high. While this is distantly possible, it's more + likely a typo, or a placeholder value that was mistakenly left + unchanged. Tag: wrong-bug-number-in-closes Severity: normal - An improvement might be to have the description include the current values from the data file ‘data/changelog-file/bugs-number’, but I don't know whether Lintian tag descriptions can be dynamically populated that way. -- \“Technology is neither good nor bad; nor is it neutral.” | `\ —Melvin Kranzberg's First Law of Technology | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#926696: xkcdpass: Should notify user when wordlist file not found
On 29-Apr-2019, lanquil wrote: > Since the user explicitly specifies the language to use, I suppose > the best answer would be an error, with maybe detailed suggestions > to help the user make the program find a suitable word file. Thank you. Alright, I will keep this bug report open until this is fixed. -- \ “I got a postcard from my best friend, it was a satellite | `\ picture of the entire Earth. On the back he wrote, ‘Wish you | _o__) were here’.” —Steven Wright | Ben Finney signature.asc Description: PGP signature
Bug#926696: xkcdpass: Option --wordfile ita-wiki gives English output
Control: clone -1 -2 Control: retitle -1 xkcdpass: Should notify user when wordlist file not found Control: severity -1 minor Control: tags -1 = upstream confirmed moreinfo Control: retitle -2 xkcdpass: Wordlist ‘ita-wiki’ described but not included Control: severity -2 normal Control: tags -2 = confirmed pending On 09-Apr-2019, Lanquil wrote: > Using xkcdpass with: > xckdpass -w ita-wiki > gives English output instead of Italian This is because the wordlist is not found. The upstream program should be improved to give some notification to the user. Do you think the program should fail with an error, or merely warn that a different wordlist will be used? > -w fin-kotus > -w spa-mich > -w ger-anlx > Are instead working as expected. Those are described in the documentation and included. The ‘ita-wiki’ wordlist is also described, but is not included; this is a separate bug in the Debian package. -- \ “The good thing about science is that it's true whether or not | `\ you believe in it.” —Neil deGrasse Tyson, 2011-02-04 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#972868: xkcdpass: TAB-completion after --wordfile completes at directories
Control: tags -1 + confirmed pending On 25-Oct-2020, Jonas Smedegaard wrote: > When in a bash shell typing "xkcdpass --wordfile /us" and hitting > TAB, it completes to "xkcdpass --wordfile /usr ". > > I would expect it to instead expand to "xkcdpass --wordfile /usr/" > to indicate that files exist within that directory but (missing a > space) the expansion is incomplete because the option takes a file > as argument. This results from the completion function failing to request “filename processing” on the ‘--wordfile’ parameter when completing it. I'll correct this in the next release. -- \ “Fox News gives you both sides of every story: the President's | `\ side and the Vice President's side.” —Steven Colbert, 2006-04-29 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#863293: libjs-jquery-atwho: consider providing node-at.js
Control: retitle -1 libjs-jquery-atwho: consider providing node-at.js Control: tags -1 - confirmed Control: tags -1 + moreinfo On 17-Aug-2019, Ben Finney wrote: > I'm confused; this bug report (bug#863255) is closed as resolved. Bug#863293, on the other hand, is still being discussed, so I'm altering the control fields accordingly. Is the package name requested ‘node-at.js’, or ‘note-atwho’, or something else? -- \ “Time flies like an arrow. Fruit flies like a banana.” —Groucho | `\ Marx | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#864795: RFP: brave-browser -- web browser with privacy and micropayment features
On 26-Jan-2022, Nilesh Patra wrote: > Oops, looks like this was always an RFP That's right :-) > apologies for the noise :) I hope you can find someone interested to package this. -- \“Are you pondering what I'm pondering, Pinky?” “Sure, Brain, | `\ but how are we going to find chaps our size?” —_Pinky and The | _o__) Brain_ | Ben Finney signature.asc Description: PGP signature
Bug#1003700: python-coverage: autopkgtest fails - pypy-coverage no longer built
Control: tags -1 + confirmed pending On 14-Jan-2022, Ben Finney wrote: > Nothing in the Debian packaging (nor in the upstream) makes any > reference to ‘pypy-coverage’. […] My mistake, I failed to open the correct repository. The bug is in the Autopkgtest control file. Thanks. -- \ “Contentment is a pearl of great price, and whosoever procures | `\it at the expense of ten thousand desires makes a wise and | _o__) happy purchase.” —J. Balguy | Ben Finney signature.asc Description: PGP signature
Bug#1003700: python-coverage: autopkgtest fails - pypy-coverage no longer built
On 13-Jan-2022, Stefano Rivera wrote: > https://ci.debian.net/packages/p/python-coverage/unstable/amd64/ > > E: Unable to locate package pypy-coverage > module-scripts FAIL badpkg > blame: python-coverage Looking at the test log, the failure is traceable to: autopkgtest [02:39:33]: test module-scripts: preparing testbed Reading package lists... Building dependency tree... Reading state information... Correcting dependencies...Starting pkgProblemResolver with broken count: 1 Starting 2 pkgProblemResolver with broken count: 1 Investigating (0) autopkgtest-satdep:amd64 < 0 @iU K Nb Ib > Broken autopkgtest-satdep:amd64 Depends on pypy-coverage:amd64 < none @un H > Removing autopkgtest-satdep:amd64 because I can't find pypy-coverage:amd64 Nothing in the Debian packaging (nor in the upstream) makes any reference to ‘pypy-coverage’. What is causing ‘autopkgtest-satdep’ to declare that dependency? -- \ “Crime is contagious… if the government becomes a lawbreaker, | `\ it breeds contempt for the law.” —Justice Louis Brandeis | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#969617: src:python-coverage: New upstream version 6.2
Control: retitle -1 src:python-coverage: New upstream version 6.2 Version 6.2 is released as of 2021-11-26 https://coverage.readthedocs.io/en/6.2/changes.html#version-6-2-2021-11-26>. Since version 5.1, some significant changes are in version 6.2: * Support Python versions 3.6 – 3.11. * Data collection is thread-safe. * The HTML report has been redesigned. * Emit messages describing where Coverage.py is writing its files. * Settings ‘skip_covered’ and ‘skip_empty’ can be specified separately for HTML report. * The report commands now have options ‘--precision’, ‘--sort’, ‘--no-skip-covered’. * The report skips branches if the source and destination line are not executed. * The report skips third-party packages. * The ‘combine’ command has new option ‘--keep’. * New ‘source_pkgs’ setting to specify only package names. * More consistent (machine-parseable) output for text report. * Support for Python 3.10 ‘match’/‘case’ syntax. * Environment variable ‘COVERAGE_RUN’ set when running code with Coverage.py. * Deprecate the ‘annotate’ feature. -- \ “Ocean, n. A body of water occupying about two-thirds of a | `\ world made for man — who has no gills.” —Ambrose Bierce, _The | _o__)Devil's Dictionary_, 1906 | Ben Finney signature.asc Description: PGP signature
Bug#998677: bash: Segfault when starting gnome-session
On 06-Nov-2021, Ben Finney wrote: > When I invoke GDB on the core dump, this is the session: > > = > $ coredumpctl gdb > […] >PID: 45094 (bash) >UID: 1000 (bignose) >GID: 1000 (bignose) > Signal: 11 (SEGV) > Timestamp: Sat 2021-11-06 23:01:32 AEDT (54s ago) > Command Line: -/bin/bash -c $'/usr/bin/gnome-session -l ' > Executable: /usr/bin/bash > […] > #62 0x55c7801d075b execute_command_internal (bash + > 0x4a75b) > #63 0x55c780222bd9 parse_and_execute (bash + 0x9cbd9) After a lot of narrowing down what in this user's session could cause Bash to segmentation fault, I've found that this makes the difference: * When the user's home directory contains ‘$HOME/.gnomerc’, the Bash segmentation fault occurs. The content of ‘$HOME/.gnomerc’ is: = # $HOME/.gnomerc # Roaming profile: User specific configuration for GNOME session. . ~/.profile = which simply “sources” the user's shell profile script. This file (and the ‘$HOME/.profile’) has been present for years with the same content, without incident on previous Gnome or Bash versions. * When the user's home directory does not contain ‘$HOME/.gnomerc’, the user login works fine, as it did a month ago. So the Gnome session is (I assume) invoking that script, which in turn sources the ‘$HOME/.profile’ script; and somehow that causes Bash to segfault. This same ‘$HOME/.profile’ script is large and somewhat sensitive; but it should never cause Bash to crash, and never does cause it to crash when logging in outside Gnome. -- \ “In any great organization it is far, far safer to be wrong | `\ with the majority than to be right alone.” —John Kenneth | _o__) Galbraith, 1989-07-28 | Ben Finney signature.asc Description: PGP signature
Bug#998677: bash: Segfault when starting gnome-session
(bash + 0x48f91) #44 0x55c7801d0bb5 execute_command (bash + 0x4abb5) #45 0x55c7801d276b n/a (bash + 0x4c76b) #46 0x55c7801cde39 execute_command_internal (bash + 0x47e39) #47 0x55c7801d0bb5 execute_command (bash + 0x4abb5) #48 0x55c7801ce181 execute_command_internal (bash + 0x48181) #49 0x55c780222bd9 parse_and_execute (bash + 0x9cbd9) #50 0x55c780221f96 n/a (bash + 0x9bf96) #51 0x55c780222165 source_file (bash + 0x9c165) #52 0x55c78022d319 source_builtin (bash + 0xa7319) #53 0x55c7801cafe4 n/a (bash + 0x44fe4) #54 0x55c7801d075b execute_command_internal (bash + 0x4a75b) #55 0x55c7801d0bb5 execute_command (bash + 0x4abb5) #56 0x55c7801ce181 execute_command_internal (bash + 0x48181) #57 0x55c780222bd9 parse_and_execute (bash + 0x9cbd9) #58 0x55c780221f96 n/a (bash + 0x9bf96) #59 0x55c780222165 source_file (bash + 0x9c165) #60 0x55c78022d319 source_builtin (bash + 0xa7319) #61 0x55c7801cafe4 n/a (bash + 0x44fe4) #62 0x55c7801d075b execute_command_internal (bash + 0x4a75b) #63 0x55c780222bd9 parse_and_execute (bash + 0x9cbd9) GNU gdb (Debian 10.1-2) 10.1.90.20210103-git […] Reading symbols from /usr/bin/bash... (No debugging symbols found in /usr/bin/bash) [New LWP 45094] Core was generated by `-/bin/bash -c /usr/bin/gnome-session -l '. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f50286a577d in _int_malloc (av=av@entry=0x7f50287daba0 , bytes=bytes@entry=32) at malloc.c:4148 4148malloc.c: No such file or directory. (gdb) = -- \“When in doubt tell the truth. It will confound your enemies | `\ and astound your friends.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#998677: bash: Segfault when starting gnome-session
On 06-Nov-2021, Bernhard Übelacker wrote: > If possible you could install systemd-coredump. > Then after such a crash "coredumpctl list" shows maybe > the crashing bash process. > If it is the last "coredumpctl gdb" might be able to > show a backtrace of the crash or even the command line > parameters. Thank you, I was hoping for exactly this kind of response to give specific steps to diagnose the fault further. I will try these commands and report more. -- \ “You can never entirely stop being what you once were. That's | `\ why it's important to be the right person today, and not put it | _o__) off until tomorrow.” —Larry Wall | Ben Finney signature.asc Description: PGP signature
Bug#998677: bash: Segfault when starting gnome-session
Package: bash Version: 5.1-3+b2 Severity: important When starting ‘gnome-session’ as some users, a child ‘bash’ process exits with a segmentation fault: = Nov 6 17:25:29 malva wireplumber[16259]: SPA handle 'api.bluez5.enum.dbus' could not be loaded; is it installed? Nov 6 17:25:29 malva wireplumber[16259]: PipeWire's BlueZ SPA missing or broken. Bluetooth not supported. Nov 6 17:25:29 malva org.gnome.Shell.desktop[24306]: The XKEYBOARD keymap compiler (xkbcomp) reports: Nov 6 17:25:29 malva org.gnome.Shell.desktop[24306]: > Warning: Unsupported maximum keycode 708, clipping. Nov 6 17:25:29 malva org.gnome.Shell.desktop[24306]: > X11 cannot support keycodes above 255. Nov 6 17:25:29 malva org.gnome.Shell.desktop[24306]: Errors from xkbcomp are not fatal to the X server Nov 6 17:25:29 malva gsd-media-keys[20189]: Unable to get default source Nov 6 17:25:33 malva wireplumber[1833]: SPA handle 'api.bluez5.enum.dbus' could not be loaded; is it installed? Nov 6 17:25:33 malva wireplumber[1833]: PipeWire's BlueZ SPA missing or broken. Bluetooth not supported. Nov 6 17:25:33 malva gsd-media-keys[20189]: Unable to get default source Nov 6 17:25:33 malva gsd-media-keys[20189]: Unable to get default sink Nov 6 17:25:41 malva kernel: [ 3136.022986] bash[24319]: segfault at 7ffc42b7b310 ip 55ebc8c809fd sp 7ffc42b7b2d0 error 6 in bash[55ebc8c74000+bb000] Nov 6 17:25:41 malva kernel: [ 3136.022994] Code: c0 48 8d 9c 24 d0 01 00 00 4c 8d 44 24 40 31 c0 c7 05 7f 36 0f 00 00 00 00 00 4d 89 c7 48 89 dd c7 05 83 36 0f 00 fe ff ff ff <66> 89 44 24 40 c7 44 24 08 00 00 00 00 48 89 1c 24 4c 89 44 24 10 Nov 6 17:25:41 malva gdm3: Gdm: GdmDisplay: Session never registered, failing = The kernel reports a segmentation fault in a ‘bash’ process. This causes ‘gdm3’ to exit with “Session never registered, failing”. The user cannot log in to their Gnome session. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bash depends on: ii base-files 12 ii debianutils 4.11.2 ii libc62.32-4 ii libtinfo66.2+20201114-4 Versions of packages bash recommends: ii bash-completion 1:2.11-4 Versions of packages bash suggests: pn bash-doc -- no debconf information
Bug#991076: python3-coverage should have libjs-jquery* in Depends instead of Recommends
Control: retitle -1 python3-coverage should have libjs-jquery* in Depends instead of Recommends On 13-Jul-2021, Christian Boltz wrote: > Package: python3-coverage (Assuming this is the package that should be mentioned in the title of this bug report, I've retitled to match.) > After some searching, I found out that I need to install some > additional packages: > libjs-jquery libjs-jquery-throttle-debounce libjs-jquery-isonscreen > libjs-jquery-tablesorter Right. Those are in Recommends, so will be installed by default. > They are already listed under "Recommends:", but since the coverage > module is not very useful if it can't generate html reports, please list > them under "Depends:" instead of "Recommends:". People who choose to disable the default installation of Recommends packages, are assumed to want a package to declare in Depends only the minimum packages that will make this package work. The Python coverage system can be used for its main purpose without ever generating any HTML reports; I think that satisfies Recommends instead of Depends for the HTML support. -- \ “I knew things were changing when my Fraternity Brothers threw | `\ a guy out of the house for mocking me because I'm gay.” | _o__) —postsecret.com, 2010-01-19 | Ben Finney signature.asc Description: PGP signature
Bug#986318: allowing the Debian build system to optimise compilation
Control: retitle -1 inform6-compiler: Set CFLAGS to optimise performance of resulting program On 03-Apr-2021, Nathanael Nerode wrote: > I retested and realized that most of the benefits come not from > -flto, but simply from -O2 (or the nearly-equivalent -Og if you want > better debugging information). Thank you for narrowing down the beneficial change. > No optimization flags seem to be used per default during the > construction of the currently installed package, much to my > surprise. This is a surprise. It is probably related to the baroque set of arms-length upstream packaging of the Inform 6 code base. Can we make use of the Debian build system for this? Like you, I would expect that a sensible compiler configuration is detected and applied by the Debian build system. Is some change to the upstream Makefile needed? -- \ “If sharing a thing in no way diminishes it, it is not rightly | `\ owned if it is not shared.” —Augustine of Hippo (354–430 CE) | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#837371: new upstream version corrects function definition
Control: tags -1 pending Control: block -1 by 986317 On 11-Sep-2016, Ben Finney wrote: > This indicates an existing problem (functions should be explicitly > declared) that was not being reported by some earlier compiler > versions. Now that this upstream issue is corrected, with the release of version “6.34”, this bug report will be resolved by a Debian package of that new version. -- \ “I have never imputed to Nature a purpose or a goal, or | `\anything that could be understood as anthropomorphic.” —Albert | _o__)Einstein, unsent letter, 1955 | Ben Finney signature.asc Description: PGP signature
Bug#984754: towncrier: Include an install-time (autopkgtest) test suite
Control: owner -1 Sérgio Cipriano On 08-Mar-2021, Ben Finney wrote: > The Debian package should include an install-time test suite to be > run by ‘autopkgtest’. There might be a set of useful examples for the ‘towncrier’ command, which could be converted to an autopkgtest suite for this Debian package. Otherwise we may need to compose those tests using, I guess, example files from the project documentation? -- \ “A ‘No’ uttered from deepest conviction is better and greater | `\ than a ‘Yes’ merely uttered to please, or what is worse, to | _o__) avoid trouble.” —Mohandas K. Gandhi | Ben Finney signature.asc Description: PGP signature
Bug#984753: towncrier: Manual page needed for 'towncrier(1)'
On 08-Mar-2021, Ben Finney wrote: > We need to obtain (or write) a manual page to install as ‘towncrier(1)’. The absence of a proper Unix manual page for ‘towncrier(1)’ is a bug upstream. We will likely need to write the manual page ourselves. The content will contain much of the same information from the command's help output, but needs to also properly populate all the typical sections of a Unix manual page; see the manual page ‘man(1)’. -- \“The priesthood have, in all ancient nations, nearly | `\ monopolized learning.” —John Adams, _Letters to John Taylor_, | _o__) 1814 | Ben Finney signature.asc Description: PGP signature
Bug#984753: Writing a manual page in ‘roff’ markup (was: Bug#984753: towncrier: Manual page needed for 'towncrier(1)')
Control: owner -1 Sérgio Cipriano Thanks to Sergio for accepting ownership of this bug report. On 08-Mar-2021, Ben Finney wrote: > We need to obtain (or write) a manual page to install as ‘towncrier(1)’. For writing a manual page, I recommend reading about the archaic markup language “roff” and how to write it effectively. https://linuxconfig.org/writing-manual-pages-on-linux> This markup language has significant downsides: It is comparatively old and there are much better markup languages today; and it is used for almost nothing else but Unix manual pages. So it is often tempting to write a manual page in some other markup language and convert that to roff. I advise against that, though, for two reasons. One: The Unix manual system is very well integrated with the specifics of roff markup. No modern popular markup language has these specific quirks, and it can be very annoying to write well-formatted manual pages in any other markup language. Two: Though roff is quirky and has questionable design choices, it is quite easy to learn and use, within the limitations of a Unix manual page. Bonus third reason: There are good examples of manual pages written directly in roff, that you can crib from when writing a new one. I offer as an example, the three manual pages included in the Debian ‘dput’ package. Get their source code, see the ‘doc/man/’ directory for the manual page source files. -- \ “Don't worry about what anybody else is going to do. The best | `\ way to predict the future is to invent it.” —Alan Kay | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#984754: towncrier: Include an install-time (autopkgtest) test suite
Package: src:towncrier Version: 19.2.0-1 Severity: wishlist Tags: newcomer The Debian package should include an install-time test suite to be run by ‘autopkgtest’. See https://wiki.debian.org/ContinuousIntegration/autopkgtest> for information about Debian's use of autopkgtest. -- \ “Courage is not the absence of fear, but the decision that | `\ something else is more important than fear.” —Ambrose Redmoon | _o__) | Ben Finney
Bug#984753: towncrier: Manual page needed for 'towncrier(1)'
Package: towncrier Version: 19.2.0-1 Severity: minor Tags: newcomer upstream The package installs a command ‘towncrier’ without a corresponding manual page. We need to obtain (or write) a manual page to install as ‘towncrier(1)’. -- \“The Bermuda Triangle got tired of warm weather. It moved to | `\ Alaska. Now Santa Claus is missing.” —Steven Wright | _o__) | Ben Finney
Bug#927454: ITP: towncrier -- compiler for project news file
On 05-Mar-2021, Sergio Durigan Junior wrote: > How are you? Thanks for asking. I'm not great, but it's all relative; pretty much everyone has had a bad 12 months more more. Hope you're well. > I'm writing to check on the status of the towncrier package. I > noticed that you have an apparently complete package on > https://salsa.debian.org/bignose/pkg-towncrier, but it hasn't been > uploaded and I can't find why. One of many things that slipped aside in 2020. > I have a friend (who is also my namesake) who is interested in > having towncrier in the archive. Maybe you can give us/him some > pointers on the current status of the package so that he can help > you with it? Thank you for the prompt. I will get back onto this and bring it up to date. -- \ “I was stopped by the police for speeding; they said ‘Don't you | `\ know the speed limit is 55 miles an hour?’ I said ‘Yeah I know, | _o__) but I wasn't going to be out that long.’” —Steven Wright | Ben Finney signature.asc Description: PGP signature
Bug#867280: dput: mentors.debian.net should allow UNRELEASED packages
Control: tags -1 - patch + moreinfo On 05-Jul-2017, Tom Fitzhenry wrote: > mentors.debian.net allows UNRELEASED packages[0], but the mentors.debian.net > block in /etc/dput.cf does not allow UNRELEASED packages. For the mentors.debian.net queue, it seems best to strictly limit the target distributions to only those that are correct for that queue. Would this be appropriate: allowed_distributions = (UNRELEASED|experimental|unstable) -- \“I have a microwave fireplace in my house. The other night I | `\ laid down in front of the fire for the evening in two minutes.” | _o__) —Steven Wright | Ben Finney signature.asc Description: PGP signature
Bug#950626: dcut: Detect which queue commands will be rejected by server, before writing them
Control: severity -1 wishlist Control: retitle -1 dcut: Detect which queue commands will be rejected by server, before writing them Control: tags -1 + moreinfo Control: outlook -1 0 The channel to upload commands to the server has no way for those errors to come back to the ‘dcut’ program as it runs. Is this something the uploading program can detect, without connection to the server? How, exactly? On 04-Feb-2020, Ben Finney wrote: > Control: tags -1 + moreinfo > > On 04-Feb-2020, Mark Brown wrote: > > I would expect that dcut would detect any errors that will not be > > being reported by ftp-master. > > My understanding is that the channel to upload commands to the > server has no way for those errors to come back to the ‘dcut’ > program as it runs. Is this something the uploading program can > detect? As described, this is not an error in ‘dcut’ operation so I'm adjusting severity to show this is a hoped-for feature. I'm setting the outlook on this report to invite feedback if someone can specify exactly what behaviour would implement this feature. -- \ “If sharing a thing in no way diminishes it, it is not rightly | `\ owned if it is not shared.” —Augustine of Hippo (354–430 CE) | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#960901: Buffer is a built-in node function
Control: found -1 webpack/4.43.0-6 On 16-Jun-2020, Ben Finney wrote: > On 18-May-2020, Pirate Praveen wrote: > > https://salsa.debian.org/js-team/node-clone/-/blob/master/clone.js#L109 > > I think we may need to embed older version of buffer module in > > node-libs-browser > > Okay. I assume that is information for the ‘node-libs-browser’ > maintainer, I think as a user I can't affect that. Pirate, can you open a new bug report if necessary? I don't understand the above information enough to know even whether an additional bug report is required, or what it would report. > > For this particular case you can try embedding buffer module > > version 4.x as browsers need an equivalent module to features > > present only in node. > > This looks like advice for me to work around the problem. What do I > need to do? How do I (as a user of Webpack) “embed buffer module > version 4.x”? What does that suggestion mean, and who should take action to make it happen? -- \ “It is the fundamental duty of the citizen to resist and to | `\ restrain the violence of the state.” —Noam Chomsky, 1971 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#799666: m17n-db: Global settings enable unexpected input methods
Control: retitle -1 m17n-db: Global settings enable unexpected input methods Control: owner -1 ! Control: tags -1 + upstream Control: found -1 m17n-db/1.8.0-3 On 29-Jan-2016, Harshula wrote: > I've added Kenichi (upstream) to this email thread. You can discuss it > directly with him. Kenichi, I assume you have now had the opportunity to read this email discussion (Debian bug#799666 https://bugs.debian.org/799666>). The bug in global settings – unexpected input methods are default enabled which mess up keyboard input without explanation – continues with ‘m17n-db’ version 1.8.0. What further information do you need to revert this change so that the database by default enables *no* input methods except those explicitly selected? -- \ “For fast acting relief, try slowing down.” —Jane Wagner, via | `\ Lily Tomlin | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#960901: Buffer is a built-in node function
Howdy Pirate, On 18-May-2020, Pirate Praveen wrote: > For this particular case you can try embedding buffer module version > 4.x as browsers need an equivalent module to features present only > in node. This looks like advice for me to work around the problem. What do I need to do? How do I (as a user of the Debian package of Webpack) “embed buffer module version 4.x”? In other words, how does this advice help the user of Webpack to build a code base that references the ‘buffer’ built-in function? -- \ “I disapprove of what you say, but I will defend to the death | `\ your right to say it.” —Evelyn Beatrice Hall, _The Friends of | _o__) Voltaire_, 1906 | Ben Finney signature.asc Description: PGP signature
Bug#969617: python-coverage: New upstream version 5.2.1
Source: python-coverage Version: 5.1+dfsg.1-1 Severity: wishlist Version 5.2.1 is released as of 2020-07-23 https://coverage.readthedocs.io/en/coverage-5.2.1/changes.html#version-5-2-1-2020-07-23>. Since version 5.1, some significant changes are in version 5.2.1: * The HTML report is redesigned: there is now a dark mode, the code text is larger, and system sans serif fonts are used. * The coverage report and coverage html commands now accept a ‘--precision’ option to control the number of decimal points displayed. * The coverage report command now accepts a ‘--sort’ option to specify how to sort the results. * The coverage report and coverage html commands now accept a ‘--no-skip-covered’ option to negate ‘--skip-covered’. * The ‘--skip-empty’ option is now available for the XML report. -- \ “I like to fill my bathtub up with water, then turn the shower | `\ on and pretend I'm in a submarine that's been hit.” —Steven | _o__) Wright | Ben Finney signature.asc Description: PGP signature
Bug#937665: Waiting for Python 2-depending reverse dependencies
Control: unblock -1 by 933750 Control: tags -1 + pending Control: outlook -1 0 We will ignore the remaining reverse-dependencies. This release will break those reverse-dependencies, but they have already lost other Python dependencies which drop Python 2 support. On 17-Aug-2020, Jann Haber wrote: > paleomix was removed from testing in May for not supporting Python > 3. Since then, the following b-ds of paleomix have already been > dropped: python-nose, python-flexmock, python-pysam and > python-setproctitle - so it is already impossible to be build from > source in sid. That convinces me, then. I will remove that block on this bug report, and proceed with the Coverage 5.1 packaging. Thanks for investigating and documenting what you found. -- \ “I bought some batteries, but they weren't included; so I had | `\to buy them again.” —Steven Wright | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#937665: Waiting for Python 2-depending reverse dependencies
Control: block 967200 by -1 On 17-Aug-2020, Ben Finney wrote: > The updated package is ready, and waiting for reverse-dependencies (as > described in bug reports blocking this one) to drop Python 2 support. -- \ “I have a map of the United States; it's actual size. It says | `\‘1 mile equals 1 mile’. Last summer, I folded it.” —Steven | _o__) Wright | Ben Finney signature.asc Description: PGP signature
Bug#937665: Waiting for Python 2-depending reverse dependencies
Control: forcemerge -1 967200 Control: block -1 by 933750 Control: outlook -1 0 The updated package is ready, and waiting for reverse-dependencies (as described in bug reports blocking this one) to drop Python 2 support. On 16-Aug-2020, Jann Haber wrote: > It seems like, there are no more rdeps of python-coverage now. Not > sure about pypy-coverage. Yes, I see no reverse dependencies for Python 2 ‘pypy-coverage’: $ aptitude search '~Dpypy-coverage' But one remaining for Python 2 ‘python-coverage’: $ aptitude search '~Dpython-coverage' p paleomix So, it seems we are waiting for ‘paleomix’ to drop Python 2 support. I am recording bug#933750 as a blocker for bug#933750. -- \ “When I wake up in the morning, I just can't get started until | `\ I've had that first, piping hot pot of coffee. Oh, I've tried | _o__)other enemas...” —Emo Philips | Ben Finney signature.asc Description: PGP signature
Bug#960901: Buffer is a built-in node function
Howdy Pirate, On 18-May-2020, Pirate Praveen wrote: > For this particular case you can try embedding buffer module version > 4.x as browsers need an equivalent module to features present only > in node. This looks like advice for me to work around the problem. What do I need to do? How do I (as a user of the Debian package of Webpack) “embed buffer module version 4.x”? -- \ “Even if the voices in my head are not real, they have pretty | `\ good ideas.” —anonymous | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#659348: LibreJS updates
On 20-Jul-2020, John Scott wrote: > I've been making a little bit of progress on this. Thank you for the update, and for continuing to make progress on this. -- \ “To punish me for my contempt of authority, Fate has made me an | `\ authority myself.” —Albert Einstein, 1930-09-18 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#965048: elpa-magithub: Dependency on deprecated ‘magit-popup’ causes warning, should migrate to ‘transient’
Package: elpa-magithub
Version: 0.1.7-2
Severity: important
Tags: upstream
When using current Magit (release “2.99.0.git0957.ge8c7bd03-1” from
Debian) while Magithub is installed, Magit repeatedly interrupts with
a warning:
Warning (magit): Magit no longer uses Magit-Popup.
It now uses Transient.
See https://emacsair.me/2019/02/14/transient-0.1.
However your configuration and/or some third-party package that
you use still depends on the `magit-popup' package. But because
`magit' no longer depends on that, `package' has removed it from
your system.
If some package that you use still depends on `magit-popup' but
does not declare it as a dependency, then please contact its
maintainer about that and install `magit-popup' explicitly.
[…]
(the full text is from function ‘magit--magit-popup-warning’ in
‘/usr/share/emacs/site-lisp/elpa-src/magit-2.99.0/magit-obsolete.el’.)
The interruption is often enough that the Magit user interface becomes
effectively unusable, hence this bug is “Severity: important”.
This warning occurs on my system is because Magithub has a dependency
on ‘magit-popup’, but does not declare it in a way that the Emacs
package manager can detect. A debugging backtrace shows:
=
Debugger entered--entering a function:
* magit--magit-popup-warning()
magit-define-popup-action(magit-dispatch-popup 72 "Magithub"
magithub-dispatch-popup 33)
(progn (magit-define-popup-action (quote magit-dispatch-popup) 72 "Magithub"
(function magithub-dispatch-popup) 33) (define-key magit-status-mode-map "H"
(function magithub-dispatch-popup)))
(lambda nil (progn (magit-define-popup-action (quote magit-dispatch-popup) 72
"Magithub" (function magithub-dispatch-popup) 33) (define-key
magit-status-mode-map "H" (function magithub-dispatch-popup()
eval-after-load-helper("/usr/share/emacs/site-lisp/elpa/magit-2.99.0/magit.elc")
run-hook-with-args(eval-after-load-helper
"/usr/share/emacs/site-lisp/elpa/magit-2.99.0/magit.elc")
do-after-load-evaluation("/usr/share/emacs/site-lisp/elpa/magit-2.99.0/magit.elc")
require(magit)
byte-code("\300\301!\210\302\303\304\305\306\307%\210\310\311\312\313\314DD\315\306\303\316\317\320\321&\011\207"
[require magit custom-declare-group magit-extras nil "Additional functionality
for Magit." :group magit-extensions custom-declare-variable
magit-gitk-executable funcall function #f(compiled-function () #) "The Gitk executable." :set-after (magit-git-executable) :type
string] 10)
autoload-do-load((autoload "magit-extras" "Like `next-line' but with
Magit-specific shift-selection.\n\nMagit's selection mechanism is based on the
region but selects\nan area that is larger than the region. This causes
`next-line'\nwhen invoked while holding the shift key to move down one
line\nand thereby select two lines. When invoked inside a hunk body\nthis
command does not move point on the first invocation and\nthereby it only
selects a single line. Which inconsistency you\nprefer is a matter of
preference.\n\n(fn ARG TRY-VSCROLL)" t nil) magit-next-line)
command-execute(magit-next-line)
=
According to the warning message:
=
* If you use `magit-popup' to define your own popups but do not
modify any of Magit's old popups, then you have to install
`magit-popup' explicitly. (You can also migrate to Transient,
but there is no need to rush that.)
=
So according to that, either of those resolutions would be sufficient
to avoid this breakage.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages elpa-magithub depends on:
ii elpa-ghub+ 0.3-5
ii elpa-git-commit 2.99.0.git0957.ge8c7bd03-1
ii elpa-magit 2.99.0.git0957.ge8c7bd03-1
ii elpa-markdown-mode 2.4-1
ii elpa-s 1.12.0-3
ii emacsen-common 3.0.4
Versions of packages elpa-magithub recommends:
ii emacs 1:26.3+1-2
ii emacs-gtk [emacs] 1:26.3+1-2
elpa-magithub suggests no packages.
-- no debconf information
--
\“If you go to a costume party at your boss's house, wouldn't |
`\ you think a good costume would be to dress up like the boss's |
_o__) wife? Trust me, it's not.” —Jack Handey |
Ben Finney
signature.asc
Description: PGP signature
Bug#955107: python3-sphinxcontrib.spelling: Uses obsolete API ‘Sphinx.info’
Control: reassign -1 python3-sphinxcontrib.spelling
Control: retitle -1 python3-sphinxcontrib.spelling: Uses obsolete API
‘Sphinx.info’
Control: found -1 python3-sphinxcontrol.spelling/4.2.0-2
Control: fixed -1 python3-sphinxcontrol.spelling/4.3.0-1
On 27-Mar-2020, Lucas Nussbaum wrote:
> > […]
> > python3 -m sphinx -N -bhtml doc/ \
> > doc/_build/html/
> > Running Sphinx v2.4.3
> >
> > Exception occurred:
> > File "/usr/lib/python3/dist-packages/sphinxcontrib/spelling/__init__.py",
> > line 11, in setup
> > app.info('Initializing Spelling Checker')
> > AttributeError: 'Sphinx' object has no attribute 'info'
> > The full traceback has been saved in /tmp/sphinx-err-bejv2u3v.log, if you
> > want to report the issue to the developers.
This was caused by the ‘sphinxcontrib.spelling’ module.
I believe the recent Debian release ‘python3-sphinxcontrol.spelling’
version “4.3.0-1” corrects this bug.
--
\ “If you see an animal and you can't tell if it's a skunk or a |
`\ cat, here's a good saying to help: ‘Black and white, stinks all |
_o__) right. Tabby-colored, likes a fella.’” —Jack Handey |
Ben Finney
signature.asc
Description: PGP signature
Bug#955763: python3-coverage: Error when calling python3.8-coverage
Control: tags -1 + moreinfo On 04-Apr-2020, Uwe Hermann wrote: > Adding the following line to > /usr/lib/python3/dist-packages/coverage-4.5.2.egg-info/entry_points.txt > seems to fix it: > > python3.8-coverage = coverage.cmdline:main That should automatically be generated during the package build on any system where Python 3.8 is a Debian supported Python 3 version. Does this still occur? If it does, what does ‘py3versions --supported’ report? -- \ “No wonder I'm all confused; one of my parents was a woman, the | `\ other was a man.” —Ashleigh Brilliant | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#961470: src:python-coverage: New upstream version 5.1
On 10-Jul-2020, Pierre-Elliott Bécue wrote: > All deps are now in the archive, do you have an estimate about when > you could have this new release of coverage in Debian? Thanks for notifying me of the dependencies. I'm working on the packaging this week, should have an update soon. -- \“I knew it was a shocking thing to say, but … no-one has the | `\right to spend their life without being offended.” —Philip | _o__) Pullman, 2010-03-28 | Ben Finney signature.asc Description: PGP signature
Bug#960901: Buffer is a built-in node function
On 16-Jun-2020, Ben Finney wrote: > On 18-May-2020, Pirate Praveen wrote: > > For this particular case you can try embedding buffer module > > version 4.x as browsers need an equivalent module to features > > present only in node. > > This looks like advice for me to work around the problem. What do I > need to do? How do I (as a user of Webpack) “embed buffer module > version 4.x”? Is this upstream issue related, does it have a solution? https://github.com/webpack/webpack/issues/6913>. From that issue: > This is because the mode ESM is applied to the Buffer polyfill. You > must use include or exclude to only set the type for your source. That discusses how to alter the code which uses “buffer”. I don't see how to apply this to code which merely uses Webpack to bundle libraries together. -- \ “Compulsory unification of opinion achieves only the unanimity | `\of the graveyard.” —Justice Roberts in 319 U.S. 624 (1943) | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#960901: Buffer is a built-in node function
On 18-May-2020, Pirate Praveen wrote: > https://salsa.debian.org/js-team/node-clone/-/blob/master/clone.js#L109 > I think we may need to embed older version of buffer module in > node-libs-browser Okay. I assume that is information for the ‘node-libs-browser’ maintainer, I think as a user I can't affect that. > For this particular case you can try embedding buffer module version > 4.x as browsers need an equivalent module to features present only > in node. This looks like advice for me to work around the problem. What do I need to do? How do I (as a user of Webpack) “embed buffer module version 4.x”? -- \ “It is forbidden to steal hotel towels. Please if you are not | `\ person to do such is please not to read notice.” —hotel, | _o__) Kowloon, Hong Kong | Ben Finney signature.asc Description: PGP signature
Bug#961470: src:python-coverage: New upstream version 5.1
Control: retitle -1 src:python-coverage: New upstream version 5.1 Control: severity -1 wishlist Control: block -1 by 961348 On 24-May-2020, Pierre-Elliott Bécue wrote: > It lacks two dependencies for being built, that I've packaged and > which are in NEW. Thank you for acting to package the new dependencies. I have now marked this bug report (for version 5.1 of Coverage.py) blocked by the remaining missing dependency, ‘sphinx-tabs’. > Would you agree with me doing a NMU or could you take care of it? I > can upload my changes in your salsa repo in a specific branch if you > wish. I have a partial implementation now, waiting on the dependencies to appear before I can progress. -- \ “There is no reason anyone would want a computer in their | `\ home.” —Ken Olson, president, chairman and founder of Digital | _o__)Equipment Corp., 1977 | Ben Finney signature.asc Description: PGP signature
Bug#960901: webpack: Resolver falsely detects phantom ‘buffer’ import in ‘clone’ library
Package: webpack
Version: 4.43.0-1
Severity: normal
When I create a minimal project that imports the ‘clone’ library,
Webpack reports that it cannot resolve an import of ‘buffer’:
=
ERROR in /usr/share/nodejs/clone/clone.js
Module not found: Error: Can't resolve
'./../../../../tmp/app-using-clone.AIFQnn/buffer' in '/usr/share/nodejs/clone'
@ /usr/share/nodejs/clone/clone.js 1:0-58
@ ./source/main.js
=
There is no attempt in that library to import ‘buffer’. The path in
the error message should never be used and is not present in the
‘clone’ library.
The ‘clone’ library is the ‘/usr/share/nodejs/clone/clone.js’
installed from Debian.
Webpack is not reporting correctly where it is finding this import. So
it is not clear, from that error message, what is causing Webpack to
detect a ‘buffer’ name that it then cannot resolve.
Here is a demonstration of how I invoked the above error:
=
$ dpkg-query --list node-clone | grep '^i'
ii node-clone 2.1.2-2 all deep cloning of objects and arrays
$ cd $(mktemp --tmpdir --directory 'app-using-clone.XX')
$ mkdir source/
$ cat > source/main.js
"use strict";
import clone from 'clone';
$ cat > webpack-config.js
"use strict";
const path = require('path');
const rootDir = path.resolve(__dirname);
const sourceDir = path.resolve(rootDir, 'source');
const buildDir = path.resolve(rootDir, 'build');
module.exports = {
mode: 'development',
entry: {
app: path.resolve(sourceDir, 'main.js'),
},
output: {
path: buildDir,
filename: 'app.js',
},
resolve: {
modules: [
sourceDir,
'/usr/share/javascript',
'/usr/share/nodejs',
],
},
};
$ webpack --config webpack-config.js
Hash: eceaa9ff3519c5b14efb
Version: webpack 4.43.0
Time: 111ms
Built at: 18/05/2020 1:09:24 pm
Asset Size Chunks Chunk Names
app.js 12.1 KiB app [emitted] app
Entrypoint app = app.js
[../../usr/share/nodejs/clone/clone.js]
/usr/share/nodejs/clone/clone.js 7.12 KiB {app} [built]
[./source/main.js] 42 bytes {app} [built]
ERROR in /usr/share/nodejs/clone/clone.js
Module not found: Error: Can't resolve
'./../../../../tmp/app-using-clone.AIFQnn/buffer' in
'/usr/share/nodejs/clone'
@ /usr/share/nodejs/clone/clone.js 1:0-58
@ ./source/main.js
$
=
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages webpack depends on:
ii node-ajv 6.10.2-1
ii node-ajv-keywords 3.4.1-1
ii node-anymatch 3.1.1+~2.1.1-1
ii node-debbundle-acorn [node-acorn] 6.2.1+ds+~cs11.24.3-3
ii node-enhanced-resolve 4.1.0-4
ii node-esrecurse 4.2.1-1
ii node-estraverse4.2.0-1
ii node-findup-sync 4.0.0-3
ii node-interpret 1.0.1-1
ii node-json-parse-better-errors 1.0.2-2
ii node-libs-browser 2.2.1-3
ii node-loader-runner 2.3.0-2
ii node-loader-utils 1.2.3-1
ii node-memory-fs 0.4.1-2
ii node-micromatch4.0.2+repack-3
ii node-mkdirp0.5.1-2
ii node-neo-async 2.6.1-3
ii node-resolve-cwd 2.0.0-2
ii node-schema-utils 1.0.0-2
ii node-supports-color6.1.0-2
ii node-tapable 1.0.0-4
ii node-uglifyjs-webpack-plugin 1.3.0-6
ii node-watchpack 1.6.0-2
ii node-webassemblyjs 1.9.0+dfsg-4
ii node-webpack-sources 1.1.0-2
ii node-yargs 15.3.0-1
ii nodejs 10.20.1~dfsg-1
webpack recommends no packages.
webpack suggests no packages.
-- no debconf information
--
\“Politics is not the art of the possible. It consists in |
`\ choosing between the disastrous and the unpalatable.” —John |
_o__)Kenneth Galbraith, 1962-03-02 |
Ben Finney
signature.asc
Description: PGP signature
Bug#922420: got an unexpected keyword argument 'bg'
Control: summary -1 This may be fixed already, need submitter to re-test. Howdy Enrico, On 15-Feb-2019, Enrico Zini wrote: > It looks like --background has been added to the command line parser, > but not to the function arguments to which the command line parser > result is sent. The code changes from version “1.2” → “1.4” includes a bunch of changes related to the ‘--background’ option. The change log unfortunately does not describe what behaviour change this is meant to have. So maybe, though upstream has not described any change to this effect, the bug has been fixed? Can you try again with version “1.5-1”, now in Debian? -- \ “No wonder I'm all confused; one of my parents was a woman, the | `\ other was a man.” —Ashleigh Brilliant | _o__) | Ben Finney signature.asc Description: PGP signature
