Bug#969505: RFS: age/1.0.0~beta4-1 [ITP] -- simple, modern and secure encryption tool
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "age": * Package name: age Version : 1.0.0~beta4-1 Upstream Author : Filippo Valsorda * URL : https://github.com/FiloSottile/age * License : ISC, BSD-3-clause, Expat * Vcs : https://salsa.debian.org/go-team/packages/age Section : utils It builds those binary packages: age - simple, modern and secure encryption tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/age/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/age/age_1.0.0~beta4-1.dsc Changes for the initial release: age (1.0.0~beta4-1) UNRELEASED; urgency=medium . * Initial release (Closes: #966315). Regards, -- Johan Fleury signature.asc Description: OpenPGP digital signature
Bug#964862: git-revice/0.6.0: pylint warning prevent Debian packaging
Hi Nika,
pylint complains since version 2.6 about some 'raise' keywords in
git-revise that are not re-raising the original exceptions. These
issues currently prevent the release of the Debian package for
git-revise/0.6.0:
> ...
> lint run-test: commands[0] | pylint gitrevise
> * Module gitrevise.merge
> gitrevise/merge.py:207:12: W0707: Consider explicitly re-raising using the
> 'from' keyword (raise-missing-from)
> gitrevise/merge.py:225:12: W0707: Consider explicitly re-raising using the
> 'from' keyword (raise-missing-from)
> * Module gitrevise.utils
> gitrevise/utils.py:73:8: W0707: Consider explicitly re-raising using the
> 'from' keyword (raise-missing-from)
> gitrevise/utils.py:89:12: W0707: Consider explicitly re-raising using the
> 'from' keyword (raise-missing-from)
>
> --
> Your code has been rated at 9.96/10 (previous run: 9.96/10, +0.00)
>
> ERROR: InvocationError for command
> /tmp/autopkgtest.SDfHIM/tree/.tox/lint/bin/pylint gitrevise (exited with code
> 4)
> ...
>
Can you please review the patch (attached or [1]) and possible consider
adoption? Shall I open a github issue/pull-request for that?
Looking forward for your feedback.
Kind regards,
Nicolas
[1] https://github.com/fjasle/git-revise -b satisfy-pylint26-raise-missing-from
--
epost: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
From 09ff90ded38e20a6d99ca86263332eb2a0515800 Mon Sep 17 00:00:00 2001
From: Nicolas Schier
Date: Thu, 3 Sep 2020 11:25:28 +0200
Subject: [PATCH] Satisfy pylint raise-missing-from warnings
Add 'from' to re-raise exceptions. Since version 2.6, pylint complains
about four raise-missing-from issues:
gitrevise/merge.py:207:12: W0707: Consider explicitly re-raising using the 'from' keyword (raise-missing-from)
gitrevise/merge.py:225:12: W0707: Consider explicitly re-raising using the 'from' keyword (raise-missing-from)
gitrevise/utils.py:73:8: W0707: Consider explicitly re-raising using the 'from' keyword (raise-missing-from)
gitrevise/utils.py:89:12: W0707: Consider explicitly re-raising using the 'from' keyword (raise-missing-from)
Simply adding the 'from' satisfies pylint.
Signed-off-by: Nicolas Schier
---
gitrevise/merge.py | 4 ++--
gitrevise/utils.py | 8 +---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/gitrevise/merge.py b/gitrevise/merge.py
index 9e0348d..30ff1c1 100644
--- a/gitrevise/merge.py
+++ b/gitrevise/merge.py
@@ -204,7 +204,7 @@ def merge_blobs(
print(f"Conflict applying '{labels[2]}'")
print(f" Path: '{path}'")
if input(" Edit conflicted file? (Y/n) ").lower() == "n":
-raise MergeConflict("user aborted")
+raise MergeConflict("user aborted") from err
# Open the editor on the conflicted file. We ensure the relative path
# matches the path of the original file for a better editor experience.
@@ -222,6 +222,6 @@ def merge_blobs(
# Was the merge successful?
if input(" Merge successful? (y/N) ").lower() != "y":
-raise MergeConflict("user aborted")
+raise MergeConflict("user aborted") from err
return Blob(current.repo, merged)
diff --git a/gitrevise/utils.py b/gitrevise/utils.py
index 1395f6e..b3155e8 100644
--- a/gitrevise/utils.py
+++ b/gitrevise/utils.py
@@ -70,7 +70,7 @@ def edit_file_with_editor(editor: str, path: Path) -> bytes:
cmd = ["sh", "-c", f'{editor} "$@"', editor, path.name]
run(cmd, check=True, cwd=path.parent)
except CalledProcessError as err:
-raise EditorError(f"Editor exited with status {err}")
+raise EditorError(f"Editor exited with status {err}") from err
return path.read_bytes()
@@ -85,8 +85,10 @@ def get_commentchar(repo: Repository, text: bytes) -> bytes:
pass
try:
return chars[:1]
-except IndexError:
-raise EditorError("Unable to automatically select a comment character")
+except IndexError as err:
+raise EditorError(
+"Unable to automatically select a comment character"
+) from err
if commentchar == b"":
raise EditorError("core.commentChar must not be empty")
return commentchar
--
2.28.0
signature.asc
Description: PGP signature
Re: RFH: Debian derivatives census
On Thu, 2020-09-03 at 10:04 +0800, Paul Wise wrote: > Hi all, Hello Pabs! > I'm looking for collaborators on the Debian derivatives census. The > census involves a mixture of social and technical work as well as > following different information feeds to find new Debian derivatives > and passing information to other Debian teams and folks. > > https://wiki.debian.org/Derivatives/Census > I believe the census is valuable to Debian and to derivatives I would like to say that we find it incredibly valuable for PureOS and I've seen the Derivatives Census as an excellent source of information both for outreach and to understand the Debian ecosystem as it were. Thank you pabs for all your work on this. > and that > it helps build mutually beneficial connections between us and the > wider > community of Free Software distributions. Derivatives bring new > people, > perspectives and projects to Debian, conference sponsorship and more. > Derivatives benefit from collaboration with Debian through learning > from our community, increased exposure to the Debian audience and of > course our software distribution and services. I would like to add that I've recently learned that the Derivatives Census can help determine programmatically the delta between Debian and a Derivative (if things are correctly configured.) For a distribution such as ours which aims for binary compatibility and wants to stay as close to Debian as possible, this is extremely valuable. > I'm looking for folks who are not very involved in Debian and would > like to increase their involvement. I feel that is our responsibility to contribute back to Debian (which we try to do) everything we can and I think that contributing time and effort is the least we can do. > The current codebase involves Make, > Python, SQL, Shell and small amounts of Perl but if you don't know > these yet I'll be happy to help you learn enough that you can > contribute. In addition to the census codebase itself, work on the > census can involve working on the codebases of other Debian services, > such as the Debian Package Tracker. > > https://wiki.debian.org/Derivatives/Integration > https://wiki.debian.org/Derivatives > https://tracker.debian.org/ The Debian package tracker will be of particular interest to me because of the ability to understand the delta from Debian to a derivative. I'm more than happy to contribute in any way I can and will review those URLs to find some low-hanging fruit to get me started. Is there are preferred channel for communication? Is the mailing list preferred over IRC? > The census service is currently disabled until the patch part of the > service is refactored to use a database instead of YAML so that > loading > metadata about the patches doesn't use all the RAM on the machine. I > haven't had the spoons to tackle this issue just yet. > > https://wiki.debian.org/Glossary#spoons Debian lore! Thanks, I didn't know about spoons. :-) Regarding RAM and CPUs, I have a VM running Bullseye at Linode which we can use for Gitlab runners or the like. Perhaps this will be of use? It is currently used to run diffoscope over an ISO built by debootstrap to determine reproducibility of the ISO; http://dev.jeremiahfoster.com/pureos-9.0-images.html I realize that Debian already has plenty of CPU cycles and would rather have more spoons but I thought I'd mention it. :-) Thanks again pabs et. al.! - Jeremiah signature.asc Description: This is a digitally signed message part
Paris 2021 conferene
Not for you? We apologize and press '{{unsubscribelink}}'me from this list There is time until the conference"movement"( Body - Cognition) at the
Sorbonne, Paris. But you can already submit
your abstractor simply register and reserve your place
see details:www.movementis.com
Bug#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys
On Thursday, September 3, 2020 4:09:59 AM EDT Ansgar wrote: > If it is a command-line utility the choice of language for its > implementation doesn't matter to users and probably shouldn't be part > of a package's name It's both a command-line utility and a library, albeit a library applications are unlikely to depend on. To the submitter, thanks for packaging solo-python! I'd been watching the wnpp bug and the package works well for me and looks great. I've identified a minor upstream issue pertaining to not allowing solo to be run as root doing 'solo key rng feedkernel', but that's for them to tackle: https://github.com/solokeys/solo-python/issues/96 signature.asc Description: This is a digitally signed message part.
Bug#965370: RFS: wand/0.6.2-1 -- Python interface for ImageMagick library (Python 3)
søn. 2. aug. 2020 kl. 18:45 skrev Adam Borowski : > > On Mon, Jul 20, 2020 at 01:17:13PM +, Håvard Flaget Aasen wrote: > > * Package name: wand > >Version : 0.6.2-1 > > > Changes since the last upload: > > > >* New upstream version 0.6.2 > >* Set upstream metadata fields: Bug-Submit. > >* Update salsa CI > > - Watch all variations of reprotest. > >* Use spaces rather than tabs in d/copyright > >* Rebase patches > >* flask sphinx theme is now in the upstream repository > > - Remove patch and lintian-override > > Alas, it fails to build; during tests: > > === FAILURES > === > test_artifacts > > > def test_artifacts(): > with Image(filename='rose:') as img: > img.artifacts['key'] = 'value' > assert 'date:create' in img.artifacts > assert img.artifacts['key'] == 'value' > assert img.artifacts['novalue'] is None > > assert len(img.artifacts) > 0 > E AssertionError: assert 0 > 0 > E+ where 0 = len( 0x7f064a3ce760>) > E+where = > .artifacts > > tests/image_properties_test.py:51: AssertionError > === warnings summary > === > .pybuild/cpython3_3.8_wand/build/tests/color_test.py::test_user_error > /<>/.pybuild/cpython3_3.8_wand/build/wand/color.py:113: > OptionWarning: unrecognized color `not_a_color' @ > warning/color.c/GetColorCompliance/1057 > self.raise_exception() > > -- Docs: https://docs.pytest.org/en/latest/warnings.html > = 1 failed, 538 passed, 7 skipped, 3 deselected, 2 xfailed, 1 warnings in > 16.48 seconds = > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. > ⠈⠳⣄ > Thanks for the review. I'm not entirely sure why this test failed, it was succeeding when I uploaded it. It also looks like the current version in Debian fails for the same test. I uploaded a new version, and ended up disabling the testsuite during build. This is the same testsuite that I enabled in the last release. When the package gets uploaded I will reopen bug [#761325] The autopkgtest is still active and seems to be more reliable. Håvard [#761325] https://bugs.debian.org/761325
Bug#969459: RFS: python-jsbeautifier/1.13.0-1 -- JavaScript unobfuscator and beautifier
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-jsbeautifier": * Package name: python-jsbeautifier Version : 1.13.0-1 Upstream Author : Liam Newman, Einar Lielmanis, et al. * URL : https://github.com/beautify-web/js-beautify * License : MIT * Vcs : https://salsa.debian.org/debian/python-jsbeautifier Section : python It builds those binary packages: jsbeautifier - JavaScript unobfuscator and beautifier python3-jsbeautifier - JavaScript unobfuscator and beautifier (python3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-jsbeautifier/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-jsbeautifier/python-jsbeautifier_1.13.0-1.dsc Changes since the last upload: python-jsbeautifier (1.13.0-1) unstable; urgency=medium . * New upstream version 1.13.0 * Rebase patch * Bump debhelper to 13 Regards, Håvard
Re: RFH: Debian derivatives census
On Thu, 2020-09-03 at 10:04 +0800, Paul Wise wrote: > I'm looking for folks who are not very involved in Debian and would > like to increase their involvement. The current codebase involves Make, > Python, SQL, Shell and small amounts of Perl but if you don't know > these yet I'll be happy to help you learn enough that you can > contribute. In addition to the census codebase itself, work on the > census can involve working on the codebases of other Debian services, > such as the Debian Package Tracker. I'd love to join! What do I do? I can (mostly) hold my own in those languages. -- []'s, Francisco M Neto www.fmneto.com 3E58 1655 9A3D 5D78 9F90 CFF1 D30B 1694 D692 FBF0 signature.asc Description: This is a digitally signed message part
Bug#969446: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth).
Control: close 969445 Control: tags -1 +moreinfo Hi Nick, Thanks for your interest in getting software into Debian. Some comments: * Since you submitted two duplicated RFS requests, I am closing one of them to make sure that there are no duplications. * I reviewed the package you provided and found that you only provided the binary package (.deb) for amd64 architecture, which is not acceptable at this moment. In order to make the software into Debian, you will have to provide the source package (.dsc file and related source tarballs) so that Debian can review the source code of such software as well as build the binary packages for other officially- supported architectures (i386, arm* etc.). Please follow the instruction texts in https://mentors.debian.net/intro-maintainers/ and prepare your Debian source package properly. Please fix the problems mentioned above and let people know when it's ready again by replying your RFS report at https://bugs.debian.org/969446 . -- Thanks, Boyuan Yang On Thu, 03 Sep 2020 02:43:22 + Nick Strauss < nick.stra...@rocketmail.com> wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear Mentor/Maintainer, > > Package name: vguitar > Version : 2.5 > Upstream Author : > URL : http://nick-strauss.com > License : GPL > > apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AB406C34 > add to /etc/apt/sources.list.d > deb [ arch=amd64 ] http://apt.nick-strauss.com/apt/debian jessie main > apt-get install vguitar > > vguitar --help > man vguitar > > -- System Information: > Debian Release: 8.4 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'oldstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.55-1-pve (SMP w/2 CPU cores) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) signature.asc Description: This is a digitally signed message part
Re: RFH: Debian derivatives census
> > I'm looking for folks who are not very involved in Debian and would > like to increase their involvement. The current codebase involves Make, > Python, SQL, Shell and small amounts of Perl but if you don't know > these yet I'll be happy to help you learn enough that you can > contribute. In addition to the census codebase itself, work on the > census can involve working on the codebases of other Debian services, > such as the Debian Package Tracker. > > https://wiki.debian.org/Derivatives/Integration > https://wiki.debian.org/Derivatives > https://tracker.debian.org/ > > The census service is currently disabled until the patch part of the > service is refactored to use a database instead of YAML so that loading > metadata about the patches doesn't use all the RAM on the machine. I > haven't had the spoons to tackle this issue just yet. > Hi This project sounds interesting, and I would like to avail myself to help/learn as much as possible. I know some basics in Python, SQL, and shell, but not Perl. Hope to be able to help in some way. Regards Sicelo
Bug#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys
On 03.09.20 at 10:09 Ansgar wrote: > If it is a command-line utility the choice of language for its > implementation doesn't matter to users and probably shouldn't be part > of a package's name for the same reason Policy recommends scripts in > PATH not including a `.sh` or `.py` suffix[1]. Thanks, I know, but it's the name upstream chose (there is a package called 'solo' on pypi already) so I decides to not change it. The cli itself is called 'solo' anyways. Best, Philip
Bug#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys
Hi, On Thu, 2020-09-03 at 10:03 +0200, Philip Rinn wrote: > It builds those binary packages: > > solo-python - command line interface for SoloKeys I don't have time to review the package, just one small notice: If it is a command-line utility the choice of language for its implementation doesn't matter to users and probably shouldn't be part of a package's name for the same reason Policy recommends scripts in PATH not including a `.sh` or `.py` suffix[1]. Ansgar [1]: https://www.debian.org/doc/debian-policy/ch-files.html#scripts
Bug#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "solo-python": * Package name: solo-python Version : 0.0.26-1 Upstream Author : SoloKeys * URL : https://github.com/solokeys/solo-python * License : Apache-2.0 or Expat * Vcs : https://salsa.debian.org/rinni/solo-python Section : utils It builds those binary packages: solo-python - command line interface for SoloKeys To access further information about this package, please visit the following URL: https://mentors.debian.net/package/solo-python/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/solo-python/solo-python_0.0.26-1.dsc Changes for the initial release: solo-python (0.0.26-1) unstable; urgency=low . * Initial release (closes: #958565). My main driver to package this is to have more support for 2FA security keys available in Debian. I own two of those keys and they are very nice devices for general 2FA but they can actually do much more e.g. they will gain OpenPGP functionality in the future. I'm aware that the package will not build reproducible at the moment due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969352 - I hope we will be able to solve this issue before the freeze. I also asked upstream to sign their releases and will ask them to include a manpage. Best, Philip
Bug#969445: sponsorship-requests: vguitar-2.6 [ITP} -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth).
Package: sponsorship-requests Severity: wishlist Dear Mentor/Maintainer, Package name: vguitar Version : 2.5 Upstream Author : URL : http://nick-strauss.com License : GPL apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AB406C34 add to /etc/apt/sources.list.d deb [ arch=amd64 ] http://apt.nick-strauss.com/apt/debian jessie main apt-get install vguitar vguitar --help man vguitar -- System Information: Debian Release: 8.4 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.55-1-pve (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
