Bug#1081700: dcut: incorrect set of “Supported commands” in ‘dcut’ help output
Package: dput Version: 1.2.2 Severity: minor The help output from ‘dcut --help’ lists “Supported commands”: $ dcut --help Usage: dcut [options] [host] command [, command] […] Supported commands: mv, rm That set of commands is inaccurate. As documented by the FTP-master team https://salsa.debian.org/ftp-team/dak/-/raw/master/tools/debianqueued-0.9/Queue.README> the correct set of supported commands is: cancel reschedule rm The ‘dcut --help’ output should accurately report this set of commands. -- \ “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#1010138: Remove gandi-cli from Debian
Control: retitle 1010138 O: gandi-cli -- command-line interface for Gandi service Control: severity 1079776 normal Control: retitle 1079776 RM: gandi-cli -- RoM; rc-buggy Control: reassign 1079776 ftp.debian.org No one has come forward with Intent To Adopt this package. I am hereby declaring it Orphaned. (Thank you to Franck Sauerbeck for responding promptly to clarify intention.) Meanwhile, with a Release-Critical bug report (bug#922420) and currently no prospect of a release to correct that, I am requesting removal of this package from Debian. This package has no reverse dependencies in Debian. -- \ “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#1010138: RFA or ITA: gandi-cli?
Control: tags 1010138 + moreinfo Howdy Franck, Thank you for expressing interest in adopting the ‘gandi-cli’ package (bug#1010138). Have you managed to assemble a new release? I see the bug report is still a “request for adoption” (you have not changed it to “intent to adopt” the package). Note that the package currently has a release-critical bug (bug#922420) which ideally should be resolved in a new Debian release, possibly working with upstream if the bug is in upstream code. There is now a proposal (bug#1079776) to remove this package from Debian. If you are no longer interested in becoming package maintainer for ‘gandi-cli’, I will begin the process to remove it from Debian. -- \ “Are you thinking what I'm thinking, Pinky?” “Uh... yeah, | `\ Brain, but where are we going to find rubber pants our size?” | _o__) —_Pinky and The Brain_ | Ben Finney signature.asc Description: PGP signature
Bug#1077488: sphinx-code-tabs: A new source-only upload is needed for testing migration
On 29-Jul-2024, Boyuan Yang wrote: > As shown on https://tracker.debian.org/pkg/sphinx-code-tabs , your package > was uploaded with binary arch:all package and cannot migrate to Debian > Testing. Do I understand correctly that: * The only way for a package to be accepted through NEW queue (because it is entering Debian for the first time) is to do a binary upload. * If successful, that upload will enter Debian ‘unstable’. * Because that upload was a binary upload, it cannot enter Debian ‘testing’. Is any of that incorrect? How is a NEW upload meant to migrate to Debian ‘testing’? -- \ “It's a great idea to come in unencumbered by dogma but you | `\can't also be unencumbered by evidence.” —Darren Saunders, | _o__) 2015-12-02 | Ben Finney signature.asc Description: PGP signature
Bug#1076298: src:dput: fails to migrate to testing for too long: uploader built arch:all binary
On 14-Jul-2024, Paul Gevers wrote: > You should only upload the source, not the arch:all binary. ‘dput’ version 1.2.2, as a source-only upload, is now in “unstable”. https://tracker.debian.org/news/1545700/accepted-dput-122-source-into-unstable/> The build logs show success for the “all” architecture https://buildd.debian.org/status/package.php?p=dput> which I think is all that's needed? Is that correct? Is that sufficient to migrate the package to “testing” and automatically close this bug report (bug#1076298)? -- \ “Whenever you read a good book, it's like the author is right | `\ there, in the room talking to you, which is why I don't like to | _o__) read good books.” —Jack Handey | Ben Finney signature.asc Description: PGP signature
Bug#1076298: src:dput: fails to migrate to testing for too long: uploader built arch:all binary
On 15-Jul-2024, Paul Gevers wrote: > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#uploading-a-package Thank you (everyone in this discussion) for enduring my frustration. That section in the Developer's Reference does seem clear. Certainly clearer than I recall from a few years ago. I'll spend some time with it, and try to purge my mind of outdated ad hoc half-remembered policies :-) -- \ “Why doesn't Python warn that it's not 100% perfect? Are people | `\ just supposed to “know” this, magically?” —Mitya Sirenef, | _o__) comp.lang.python, 2012-12-27 | Ben Finney signature.asc Description: PGP signature
Bug#1076359: org-roam-doc: Section should be “doc”
Control: tags -1 + patch On 15-Jul-2024, Ben Finney wrote: > The package ‘org-roam-doc’ installs primarily documentation, not > executable programs or libraries. It should not be in the “editors” > section. > > Please set the field “Section: doc” on this package. I have addressed this change in a new branch https://salsa.debian.org/bignose/org-roam/-/tree/wip/issue/1076359/correct-section-for-documentation-package> in my personal fork repository. (Salsa does not appear to offer me a way to make a merge request for that branch.) > Then, because the package is already in Debian with a different section, > you need to submit a request to override the existing section > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#override-file>. > > Mark that new bug report as blocked by this one, to indicate the reliance > between them. That step will still need to be taken, ideally by the package maintainer when they know the package is ready. -- \ “Nature hath given men one tongue but two ears, that we may | `\ hear from others twice as much as we speak.” —Epictetus, | _o__) _Fragments_ | Ben Finney signature.asc Description: PGP signature
Bug#1076359: org-roam-doc: Section should be “doc”
Package: org-roam-doc Version: 2.2.2-3 Severity: minor Dear Maintainer, The section “editors” is for packages that install text editors and word processing applications. The package ‘org-roam-doc’ installs primarily documentation, not executable programs or libraries. It should not be in the “editors” section. Please set the field “Section: doc” on this package. Then, because the package is already in Debian with a different section, you need to submit a request to override the existing section https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#override-file>. Mark that new bug report as blocked by this one, to indicate the reliance between them. -- \ “Do unto others twenty-five percent better than you expect them | `\ to do unto you. (The twenty-five percent is [to correct] for | _o__)error.)” —Linus Pauling's Golden Rule | Ben Finney signature.asc Description: PGP signature
Bug#1076298: src:dput: fails to migrate to testing for too long: uploader built arch:all binary
On 14-Jul-2024, Chris Hofstaedtler wrote: > TTBOMK the rules currently are: source-only uploads are perfectly fine > and desirable. In a few exceptional cases, binaries must be provided; > these are (at least): introduction of new source package (= "NEW"), > introduction of new binary package (= "binNEW"), upload of a non-free > package that is not auto-built. > > > > > Where can I read more to understand what went wrong here and how to > > > > not have a package blocked this way? > > > > > > https://lists.debian.org/debian-devel-announce/2019/07/msg2.html > > > second section. > > > > Oh, I had interpreted that differently: that the binary packages would > > not migrate, but that the source package would be re-built and *that* > > would migrate to testing. > > > > You mentioned that the build daemons do not build “Architecture: all” > > packages? Is that a temporary fault, or is it intentional? > > The buildds can build "Architecture: all" packages. However, large > parts of our infrastructure and customs are not prepared to deal > with rebuilds of "Architecture: all" packages, so this is not done. > > I'll point out that any rebuilds on buildds also change the version > number, e.g. by appending +b1 (or higher). Thank you both. I can guarantee that this complex knowledge will not stick, and I can't find it laid out anywhere obvious (e.g. the FTP masters site) to find for authoritative reference later. Are these rules and conditions and branching instructions, for when and what to upload with a package release, explicitly and clearly laid out, in an obvious place (not a paragraph addressing a single release in a mailing list discussion) for any Debian developer to find? If not, it seems these confusions and delays and blocked migrations are far more likely to continue indefinitely. -- \“Beware of bugs in the above code; I have only proved it | `\ correct, not tried it.” —Donald Knuth, 1977-03-29 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1076169: ITP: sphinx-code-tabs -- Sphinx extension to add selectable tabs for code blocks
Control: owner -1 ! Control: retitle -1 ITP: sphinx-code-tabs -- Sphinx extension to add selectable tabs for code blocks I have begun the work of packaging version “0.5.5” for Debian. -- \ “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#1076298: src:dput: fails to migrate to testing for too long: uploader built arch:all binary
On 14-Jul-2024, Paul Gevers wrote: > You should only upload the source, not the arch:all binary. Thank you, I'll do that. But I'm still concerned about a couple of issues this raises: That admonition appears to conflict with a different policy I'd learned: The package upload should include a built binary package, to demonstrate that it *can* build and to lower the incidence of uploads that are destined to fail to build from source. Has that policy been rescinded? If not, how is it compatible with the advice you cited? > > Where can I read more to understand what went wrong here and > > how to not have a package blocked this way? > > https://lists.debian.org/debian-devel-announce/2019/07/msg2.html > second section. Oh, I had interpreted that differently: that the binary packages would not migrate, but that the source package would be re-built and *that* would migrate to testing. You mentioned that the build daemons do not build “Architecture: all” packages? Is that a temporary fault, or is it intentional? > As stated in my bug report, this can't be fixed by a rebuild (the > infrastructure doesn't support arch:all binNMUs), so it needs a version > bump. Thank you again, I hope to understand better if you can also answer the questions above. -- \ “Computer perspective on Moore's Law: Human effort becomes | `\ twice as expensive roughly every two years.” —anonymous | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1076298: src:dput: fails to migrate to testing for too long: uploader built arch:all binary
Howdy Paul, On 13-Jul-2024, Paul Gevers wrote: > Your package is only blocked because the arch:all binary package(s) > aren't built on a buildd. Unfortunately the Debian infrastructure doesn't > allow arch:all packages to be properly binNMU'ed. What, as a package uploader (and maintainer), should I do differently to avoid this? Where can I read more to understand what went wrong here and how to not have a package blocked this way? The binary package is (IIUC) correctly marked “Architecture: all”, so it seems right that is what was uploaded. Yet you say this is what caused the migration to block? Can I simply re-build in a different way, and upload again, without the change of package version? -- \ “Isn't it enough to see that a garden is beautiful without | `\ having to believe that there are fairies at the bottom of it | _o__) too?” —Douglas Adams | Ben Finney signature.asc Description: PGP signature
Bug#1076168: blocked on missing dependency ‘sphinx-code-tabs’
Control: block -1 by 1076169 Control: outlook -1 0 Recent upstream versions have Sphinx extension ‘sphinx-code-tabs’ as a build dependency. Until that is packaged, this new version is blocked in Debian. This new upstream version (and any version later than 7.2.7) required that Sphinx extension packaged in Debian. The request for that package is Debian bug#1076169. -- \ “I can picture in my mind a world without war, a world without | `\ hate. And I can picture us attacking that world, because they'd | _o__) never expect it.” —Jack Handey | Ben Finney signature.asc Description: PGP signature
Bug#1076169: RFP: sphinx-code-tabs -- Sphinx extension to add selectable tabs for code blocks
Package: wnpp Severity: wishlist Package name: sphinx-code-tabs Version : 0.5.5 Upstream Contact: Thomas Gläßle URL : https://github.com/coldfix/sphinx-code-tabs License : Unlicense https://spdx.org/licenses/Unlicense.html Programming Lang: Python Description : Sphinx extension to add selectable tabs for code blocks This is an extension for the Sphinx documentation system. It adds a `tabs` directive for creating a widget with multiple tabs, allowing the user to switch between them. The individual tabs can be code blocks or general content. This can be used to e.g. show a snippet in multiple languages, display instructions for alternative platforms, or switch between code and output. -- \“Sane people have an appropriate perspective on the relative | `\ importance of foodstuffs and human beings. Crazy people can't | _o__) tell the difference.” —Paul Z. Myers, 2010-04-18 | Ben Finney signature.asc Description: PGP signature
Bug#1076168: src:python-coverage: upstream version “7.6.0” released
Source: python-coverage Version: 7.2.7+dfsg1-1 Severity: wishlist Howdy, The upstream project released version “7.6.0” on 2024-07-11. There have been many improvements since the latest Debian package release (“7.2.7+dfsg1-1”). https://coverage.readthedocs.io/en/latest/changes.html#version-7-6-0-2024-07-11> -- \ “A cynic is a man who, when he smells flowers, looks around for | `\ a coffin.” —Henry L. Mencken | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1073040: dput: Fails when processing ssh_config_options value: AttributeError: 'list' object has no attribute 'split'
Control: tags -1 + pending On 16-Jun-2024, Harald Dunkel wrote: > I did a brief test using dput built from > https://salsa.debian.org/debian/dput/-/merge_requests/15 . > > Works for me. Thank you. I have merged these changes and they will be in the next package release, to fix this bug. -- \“Conscience is the inner voice that warns us somebody is | `\ looking.” —Henry L. Mencken | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1073280: RM: Ok to remove project ? dead upstream, depends on nose, no rdeps left
On 15-Jun-2024, Alexandre Detiste wrote: > Nothing depends on [the Python ‘lockfile’ package] anymore. > Would you be OK to remove it already now ? Yes, thank you. ‘lockfile’ can be removed from Debian. -- \ “To label any subject unsuitable for comedy is to admit | `\ defeat.” —Peter Sellers | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1072857: proposed changes confirmed fix
Control: tags -1 + pending On 15-Jun-2024, Martin Dosch wrote: > I started new, applied the patch and rebuilt > dput and now it works: […] So the patch seems to work. :) Great, thank you for verifying this. I will get these changes into the package to fix this bug. -- \ “Religions have contrived to make it impossible to disagree | `\ with them critically, without being rude.” —Daniel Dennett, | _o__) _The Four Horsemen_, 2008-05-20 | Ben Finney signature.asc Description: PGP signature
Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:
On 14-Jun-2024, Martin Dosch wrote: > I am also affected by this bug. I have not added any dput config and > therefore nowhere specified a delay so it must be a faulty default > config: At https://salsa.debian.org/debian/dput/-/merge_requests/14> is a merge request proposing to fix this bug. Before merging, I need confirmation from someone experiencing this bug, that the resulting package does indeed fix the bug. Can you try the resulting Dput package, and confirm whether it corrects the behaviour in your case? -- \ “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#1073040: dput: Fails when processing ssh_config_options value: AttributeError: 'list' object has no attribute 'split'
On 14-Jun-2024, Christoph Berg wrote: > Re: Ben Finney > > At https://salsa.debian.org/debian/dput/-/merge_requests/15> is a > > merge request proposing to fix this bug. > > > > Can you try the resulting Dput package, and confirm whether it corrects > > the behaviour in your case? > > I don't think I have any ssh options set - it was already failing on > the default case. I'd say just upload and I'll report back if it's > still failing. Before uploading a version that claims to fix the bug, I'll need confirmation the bug is in fact fixed. Can you try the modified program and confirm the bug is fixed in that modified version? -- \ “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#1073040: dput: Fails when processing ssh_config_options value: AttributeError: 'list' object has no attribute 'split'
On 12-Jun-2024, Ben Finney wrote: > On 11-Jun-2024, Christoph Berg wrote: > > > File "/usr/share/dput/dput/dput.py", line 1152, in > > upload_files_via_method_scp > > line.strip() for line in ssh_config_options.split("\n")) > > > > AttributeError: 'list' object has no attribute 'split' > > This is a bug in recently refactored code, thank you for finding it. I will > correct that and get you to confirm the fix. At https://salsa.debian.org/debian/dput/-/merge_requests/15> is a merge request proposing to fix this bug. Can you try the resulting Dput package, and confirm whether it corrects the behaviour in your case? -- \ “I like to skate on the other side of the ice.” —Steven Wright | `\ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1072857: dput: Fails when processing ssh_config_options value: AttributeError: 'list' object has no attribute 'split'
Control: clone -1 -2 Control: retitle -2 dput: Fails when processing ssh_config_options value: AttributeError: 'list' object has no attribute 'split' Control: tags -2 + confirmed Control: severity -2 severe On 11-Jun-2024, Christoph Berg wrote: > Uploading to ssh-upload [DELAYED/0-day] (via scp to ssh.upload.debian.org): > Traceback (most recent call last): > File "/usr/bin/dput", line 33, in > sys.exit(load_entry_point('dput==1.2', 'console_scripts', > 'execute-dput')()) > > ^^ > File "/usr/share/dput/dput/dput.py", line 1548, in main > upload_files( > File "/usr/share/dput/dput/dput.py", line 1267, in upload_files > upload_func( > File "/usr/share/dput/dput/dput.py", line 1152, in > upload_files_via_method_scp > line.strip() for line in ssh_config_options.split("\n")) > > AttributeError: 'list' object has no attribute 'split' This is a bug in recently refactored code, thank you for finding it. I will correct that and get you to confirm the fix. -- \ “All progress has resulted from people who took unpopular | `\ positions.” —Adlai Stevenson | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:
Control: tags -1 + patch On 09-Jun-2024, Martin-Éric Racine wrote: > Incorrect delayed argument: ValueError: delayed days value must be a decimal > integer: At https://salsa.debian.org/debian/dput/-/merge_requests/14> is a merge request proposing to fix this bug. Can you try the resulting Dput package, and confirm whether it corrects the behaviour in your case? -- \ “An idea isn't responsible for the people who believe in it.” | `\ —Donald Robert Perry Marquis | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:
Control: tags -1 confirmed On 09-Jun-2024, Martin-Éric Racine wrote: > I did not specify any delayed queue, so I am perplexed as to what > produced this. This occurs regardless of whether the configuration file specifies a value for ‘delayed’. Confirming this is a bug which needs to be fixed. Thank you for the report. -- \ “Computer perspective on Moore's Law: Human effort becomes | `\ twice as expensive roughly every two years.” —anonymous | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:
Howdy Martin-Éric, On 09-Jun-2024, Martin-Éric Racine wrote: > Incorrect delayed argument: ValueError: delayed days value must be a decimal > integer: > > I did not specify any delayed queue, so I am perplexed as to what > produced this. You did not specify a command-line option for the delayed queue; but your configuration file does specify a value. > - -- /home/perkelix/.dput.cf -- […] > [DEFAULT] > login = * > method = ftp > hash = md5 > allow_unsigned_uploads = 0 > allow_dcut = 0 > distributions = > allowed_distributions = (?!UNRELEASED) > run_lintian = 0 > run_dinstall = 0 > check_version = 0 > scp_compress = 0 > default_host_main = > post_upload_command = > pre_upload_command = > ssh_config_options = > passive_ftp = 1 > progress_indicator = 0 > delayed = > […] So, that configuration section overrides default behaviour and specifies empty-string values for many options that would otherwise have no value defined. This means that, for example, the ‘delayed’ option, which has no value by default, instead has a value of an empty text string. This does not specify a decimal integer value, so you get the error seen. I recommend removing any options from that ‘DEFAULT’ section that incorrectly specify an empty string where you don't want that. -- \“That's the essence of science: Ask an impertinent question, | `\and you're on the way to the pertinent answer.” —Jacob | _o__) Bronowski, _The Ascent of Man_, 1973 | Ben Finney signature.asc Description: PGP signature
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”
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.” —Henry L. Mencken | _o__) | Ben Finney signature.asc Description: PGP signature
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
d_internal (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