Re: request for removal of my packages from the DPT namespace
*ping* *ping* *ping* On Thu, 23 May 2024 08:27:42 +0200 Jeroen Ploemen wrote: > *ping* *ping* > > > On Tue, 16 Apr 2024 11:21:51 +0200 > Jeroen Ploemen wrote: > > > *ping* > > > > > > On Tue, 19 Mar 2024 13:41:04 +0100 > > Jeroen Ploemen wrote: > > > > > Dear team admins, > > > > > > please delete the following packages from the DPT namespace on > > > salsa: > > > > > > cheetah > > > jaraco.classes > > > jaraco.collections > > > jaraco.context > > > jaraco.text > > > nfoview > > > ply > > > puremagic > > > python-autocommand > > > python-jaraco.functools > > > python-portend > > > python-rarfile > > > python-tempora > > > python-yenc > > > sabctools > > > sabnzbdplus > > > > > > > > > All of these have already been mirrored into my personal > > > namespace to keep a public VCS available, while gaining at > > > least some protection against ongoing policy violations. pgp_L3kwoMssb.pgp Description: OpenPGP digital signature
Re: request for removal of my packages from the DPT namespace
*ping* *ping* On Tue, 16 Apr 2024 11:21:51 +0200 Jeroen Ploemen wrote: > *ping* > > > On Tue, 19 Mar 2024 13:41:04 +0100 > Jeroen Ploemen wrote: > > > Dear team admins, > > > > please delete the following packages from the DPT namespace on > > salsa: > > > > cheetah > > jaraco.classes > > jaraco.collections > > jaraco.context > > jaraco.text > > nfoview > > ply > > puremagic > > python-autocommand > > python-jaraco.functools > > python-portend > > python-rarfile > > python-tempora > > python-yenc > > sabctools > > sabnzbdplus > > > > > > All of these have already been mirrored into my personal namespace > > to keep a public VCS available, while gaining at least some > > protection against ongoing policy violations. pgpfK4zsErNoZ.pgp Description: OpenPGP digital signature
Re: request for removal of my packages from the DPT namespace
*ping* On Tue, 19 Mar 2024 13:41:04 +0100 Jeroen Ploemen wrote: > Dear team admins, > > please delete the following packages from the DPT namespace on > salsa: > > cheetah > jaraco.classes > jaraco.collections > jaraco.context > jaraco.text > nfoview > ply > puremagic > python-autocommand > python-jaraco.functools > python-portend > python-rarfile > python-tempora > python-yenc > sabctools > sabnzbdplus > > > All of these have already been mirrored into my personal namespace > to keep a public VCS available, while gaining at least some > protection against ongoing policy violations. pgppk_g_DEJl0.pgp Description: OpenPGP digital signature
Re: request for removal of my packages from the DPT namespace
On Wed, 27 Mar 2024 00:33:15 +0100 Thomas Goirand wrote: > On 3/19/24 13:41, Jeroen Ploemen wrote: > > Dear team admins, > > > > please delete the following packages from the DPT namespace on > > salsa: > > > > cheetah > > jaraco.classes > > jaraco.collections > > jaraco.context > > jaraco.text > > nfoview > > ply > > puremagic > > python-autocommand > > python-jaraco.functools > > python-portend > > python-rarfile > > python-tempora > > python-yenc > > sabctools > > sabnzbdplus > > > > > > All of these have already been mirrored into my personal > > namespace to keep a public VCS available, while gaining at least > > some protection against ongoing policy violations. > Hi, > > Usually, you'd ask for one of the Salsa admins to actually *move* > the packages from one namespace to another, so that there's > redirections, rather than copying somewhere else and deleting. This > can be done by a simple ticket at: > > https://salsa.debian.org/salsa/support > > Or is it too late, and you already cloned, and don't want to bother? Thomas, thanks for getting back to me on this. I would have preferred to have redirects in place, but simply overlooked the possibility of the salsa overlords doing the moves after figuring out gitlab wouldn't let me move things out and the team admins in turn wouldn't be able to move anything into my namespace. I'll try to keep that in mind for next time; for now, please proceed with the deletion from the team namespace as I outright lack the time for another round of reorganising git repos for weeks to come. pgpyC069KPAIP.pgp Description: OpenPGP digital signature
request for removal of my packages from the DPT namespace
Dear team admins, please delete the following packages from the DPT namespace on salsa: cheetah jaraco.classes jaraco.collections jaraco.context jaraco.text nfoview ply puremagic python-autocommand python-jaraco.functools python-portend python-rarfile python-tempora python-yenc sabctools sabnzbdplus All of these have already been mirrored into my personal namespace to keep a public VCS available, while gaining at least some protection against ongoing policy violations. pgpe_6_ro4Wy1.pgp Description: OpenPGP digital signature
Re: Suggesting change in DPT policy
On Fri, 1 Mar 2024 07:21:57 + Julian Gilbey wrote: > These are really interesting points. Under the proposed system, I > presume that one could leave "privately maintained" packages within > the python-team area of salsa and still benefit from these automatic > changes without giving automatic permission to other developers to > make manual changes. Being part of the team is a relationship > between developers; it surely doesn't say anything about a specific > package's maintenance, just as one can ask questions on > debian-devel without saying "anyone can do anything to my packages > without asking me". As far as I can tell, the proposed change aims to remove that kind of flexibility: any package that currently lists the team as an uploader would have to pick between "team as maintainer" or "out" to be in compliance. > > That said, I'm very careful not to spend more time on volunteer > > efforts than I can afford to, and not looking to offload the full > > maintenance of any of my packages. Upstream involvement often > > gives me advance knowledge of upcoming releases, their > > compatibility issues and other quirks, which in turn helps avoid > > problems on the Debian end. I do not share the optimism that > > documenting such details somewhere in individual packages - as > > suggested elsewhere in this thread - would be effective to avoid > > trouble; more so considering that the inability to stick to a > > single, concise, and rather clear team policy is ultimately what > > triggered this whole discussion in the first place. > > I don't think it's a binary choice: "offload the full maintenance" > of a package versus "keep the full maintenance". As far as I > understand it, a package maintained by the team will typically have > a main person who does the day-to-day work on it (few people have > the time to start doing serious work on lots of other packages), > but anyone on the team could work on it. In the cases mentioned, > there are RC bugs in packages which have not been addressed in a > timely fashion and are holding up transitions or similar. In some > of "my" packages, other developers on the team have uploaded more > regular updates (thanks!). In most cases, updates are routine and > I'm very appreciative of it. I should probably have phrased that a bit differently than 'offload'. My packages simply never have RC bugs open for a long time and under normal circumstances don't require any team attention/intervention. Which is exactly why I prefer the "talk to me before making major changes" approach the current policy provides. Whatever extra time I have beyond that needed for my own packages mostly goes towards sponsorship, in part because that makes people feel their work is appreciated and encourages further contributions. > While documenting quirks might not fully avoid trouble, it's much > better than not documenting them. After all, this is detailed > knowledge of a package or collection of packages that has been > gained over time, and in addition to helping anyone stepping in to > do a team upload, documenting it will help whoever ends up taking > over the package one day (as well as helping the maintainer > themselves!). > > The question for your quirky packages then becomes: what does the > current team maintenance position offer that having the package > solely maintained by yourself would not provide? I can see very > little; anyone wanting to help with a package outside of the team > can still offer to do an NMU (and push their changes to salsa). Working directly in git is simply more convenient, lowers the bar for contributing, and subjects any contributions to the scrutiny of the CI pipeline. In addition, having team members familiar with python packages involved lowers risk vs. a drive-by NMU, no matter how well intended. pgpd0kYFIliI4.pgp Description: OpenPGP digital signature
Re: Suggesting change in DPT policy
On Tue, 27 Feb 2024 18:32:54 + Scott Kitterman wrote: > While I do take advantage of this for a few packages, I don't > personally care much either way. I suspect that packages will be > removed from team maintenance as a result though and I think that's > a bad idea. > > I'd prefer the current approach over people removing packages from > the team, so I think it's important that anyone who feels strongly > enough about this to do so, speak up. For me, the weaker collaboration option that the DPT provides is key to putting my packages under a team umbrella. As I find myself completely AFK for up to a month at a time for both work and private reasons, having a knowledgeable bunch of developers around with full access to my packages (VCS and CI included) is a definite plus, if only out of a strong sense of responsibility. The same goes for benefiting from the shared knowledge of the team, including routine fixes and similar minor changes being rolled out across all packages in the team. That said, I'm very careful not to spend more time on volunteer efforts than I can afford to, and not looking to offload the full maintenance of any of my packages. Upstream involvement often gives me advance knowledge of upcoming releases, their compatibility issues and other quirks, which in turn helps avoid problems on the Debian end. I do not share the optimism that documenting such details somewhere in individual packages - as suggested elsewhere in this thread - would be effective to avoid trouble; more so considering that the inability to stick to a single, concise, and rather clear team policy is ultimately what triggered this whole discussion in the first place. As for the inclusion of codes of conduct or similar wording, documenting common sense just feels unnecessary. While being on the receiving end of a compliment for bug-squashing work is certainly nice, the lack thereof isn't a measure of disrespect. I cannot recall any discussion on the team's IRC channel or mailing list crossing that line. pgpye0JS70SkC.pgp Description: OpenPGP digital signature
review for python-leather/0.4.0-1
hi Ileana,
I took a look at the python-leather package up for sponsorship in the
Python team. Some issues came up during review:
* possible unused build-deps on python3-six, -doc, dpkg-dev;
* build-dep on furo could be marked !nodoc;
* build-dep on sphinx-common is redundant, already a dependency of
python3-sphinx.
* examples are probably better installed into the documentation pkg.
* python3-leather suggests doc pkg with a build profile included
(""; copy/paste error?);
* doc package has a useless suggested dependency on itself.
* lintian hit: W: python3-colormap: debian-changelog-line-too-long
[usr/share/doc/python3-colormap/changelog.Debian.gz:7]
pgpXcJGr5BoCR.pgp
Description: OpenPGP digital signature
review for python-ciso8601/2.3.1-1
hi Lance, I took a look at the python-ciso8601 package, put up for sponsorship in the Python team. Just missed you on IRC, so sending comments by email instead: * copyright: + incorrect info for upstream (license file in sources states 2014, does not mention a "tomst"); + missing info for isocalendar.c, timezone.c (PSF resp. MIT, both with other copyright holders than Close.io). * autopkgtest: all defined tests only run for the default python version; please test with all supported Python versions. Otherwise looking good. Please re-add the package to the channel topic on IRC once the above issues have been addressed. pgp7SCIPrb2jv.pgp Description: OpenPGP digital signature
review for riscemu/2.2.5-1
hi Bo, I took a look at the riscemu package, put up for sponsorship in the Python team. Some (mostly minor) issues came up: * copyright: + upstream years are incorrect (license file, sources have 2021-2022 resp. 2023). + leftover boilerplate comments. + empty line (dot) at the start of the license paragraph. * control: + no need to mention -doc/-examples pkgs in the long description, that's what a suggested dependency is for. + tiny (< 10kB) examples package is probably best merged into the documentation package. * rules: + weird comment at the top of the file (leftover TODO?). + variables for doc and example dirs defined but not used? + documentation dir /usr/share/doc/riscemu-doc/; did you mean /usr/share/doc/riscemu/? * d/riscemu-examples.install used for examples; these should be handled by dh_installexamples instead. * lintian hit: W: riscemu: no-manual-page [usr/bin/riscemu]. pgpwzY4vnizLt.pgp Description: OpenPGP digital signature
review for astral/3.2-1
hi Ileana, I took a look at the astral package put up for sponsorship in the Python team. Some minor issues came up: * unused build-deps on requests, tz; * outdated copyright years for upstream, see src/astral/__init__.py; * entire paragraph for apache-2.0 license is only a filepath. Also notice there's no human maintainer or uploader listed, consider adding yourself if you have a direct interest in this package. pgpB7aYmq1_JX.pgp Description: OpenPGP digital signature
review for lazy-loader/0.3-1
Hi, I took a look at lazy-loader, up for sponsorship in the Python Team: * copyright: years outdated; * control: long description would benefit from some more details explaining what lazy loader is and does, e.g. a summary of [1]; * control: standards-version is slightly out-of-date; * watch: upstream uses signed tags for releases, please add the upstream key in the packaging and make uscan verify the signature. Since the watch file already uses git mode, you might only have to add the pgpmode=gittag option once the upstream key is in place for verification to work. Please re-add the package to the channel topic on IRC once the above issues have been fixed. [1]https://scientific-python.org/specs/spec-0001/ standards-version pgpMPxVbKJIGb.pgp Description: OpenPGP digital signature
review for python-sepaxml/2.6.1-1
hi Matthias, the package looks mostly fine on the technical side, with only some minor issues and suggestions for improvement of d/control and d/rules. The copyright file does need attention though, also in light of recent upstream commits that made significant changes. A fresh upstream release including these changes would be beneficial, if only to avoid confusion. copyright: * years? 2012-2013 in upstream license file vs -2022 in d/copyright; also see recent upstream changes that use 2017 instead as the starting point for their copyright claim [1]. * copyright for congressus apparently applies to more files, see [1]. * no info listed for the schema files in sepaxml/schemas/; you'll have to verify any third parties that may be involved haven't put restrictions on commercial use, development of software and/or services competing with their own, etc, in possible violation of the DFSG: see [2] and the third-party statements linked from [3]. control: * unused build-deps: isort, flake8? * please mark test-only build-deps as such (i.e. !nocheck). * long descr.: consider turning that list of standards into an actual list to improve readability. * long descr.: you may want to write out SEPA once upon first use, introducing the abbreviation; also makes it easier to find when users search for that. * long descr.: no need to mention the module is installed for Python 3 nowadays, that used to be a thing when Python 2 was still around and packages actually had to support both. rules: * "export PYBUILD_NAME=python-sepaxml" - is it? See [4]. autopkgtest: please include a non-trivial autopkgtest; for packages with a pytest-based tests such as this one, running the upstream test suite in an autopkgtest context is usually straightforward and these days can even be done automagically with pybuild-autopkgtest [5]. lintian hits: I: python3-sepaxml: capitalization-error-in-description python Python I: python3-sepaxml: capitalization-error-in-description-synopsis python Python [1]https://github.com/raphaelm/python-sepaxml/commit/04171a615eb4e056bb5e326d77879d3e0cfd3f12 [2]https://github.com/raphaelm/python-sepaxml/commit/b92f92f4bfd5de6ed31d3c1ef3b82f5d7c4bf9d8 [3]https://www.iso20022.org/terms-use [4]https://wiki.debian.org/Python/Pybuild#debian.2Frules [5]https://manpages.debian.org/testing/dh-python/pybuild-autopkgtest.1.en.html pgpUa4S4rJP0Q.pgp Description: OpenPGP digital signature
Re: New upstream version of sphinxext-opengraph
On Wed, 18 Jan 2023 14:45:41 -1000 Chiara Marmo wrote: > Dear list, > > A new upstream version of sphinxext-opengraph is available on salsa. Uploaded, thanks. pgpNhgurjV0RY.pgp Description: OpenPGP digital signature
Re: review for kivy/2.1.0-1
On Thu, 5 Jan 2023 01:17:40 -0800 Vincent Cheng wrote: > to the packaging, but otherwise I think this is ready for upload; > if Jeroen isn't planning on uploading kivy in the next day or so, My system has been resurrected, and I'm fine with the current state of the kivy packaging as well. I do share Vincent's concerns about adding a new binary pkg this close to the upcoming freeze though. pgpXa_369Tn82.pgp Description: OpenPGP digital signature
Re: review for kivy/2.1.0-1
hi Dean, thanks for making all those improvements. Only a couple of things remaining: * Copyright: try using standard license shortnames [1] where possible: Easing appears identical to BSD-3-clause; Khronos looks a lot like Expat. * Rules, lintian: are the files in kivy/tools/image-testsuite somehow used by or called from within kivy? The readme in there talks about generating image test suites for kivy's imageloaders. I don't know whether this is something end users of kivy normally do; if not, probably best to not install that directory at all rather than appease lintian with an override and that chmod in d/rules. [1]https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name pgpuQNxpWKzwR.pgp Description: OpenPGP digital signature
review for pytest-fail-slow/0.3.0-1
hi Ileana, I took a look at pytest-fail-slow, up for sponsorship in the Python team. Some repo issues: * It appears tags were not pushed, as there's no tags at all in the repo - not even for the imported upstream release - although the typical gbp workflow would handle that. * The upstream tarball produced by uscan differs from the pristine-tar data. Are you making use of the standard tools for importing new releases, e.g. 'gbp import-orig --pristine-tar --uscan' or similar? Then for the packaging itself (which is in pretty good shape): * changelog: please leave the release at UNRELEASED, cf. team policy. * control: + the binary pkg for a pytest plugin is commonly named python3-pytest-; + short description: Pytest plugin to [current description]? * upstream/metadata missing. * no autopkgtest? Should be a trivial yet *very* useful addition, providing early warning for things like compatibility issues with newer pytest releases before packages using the plugin start seeing failures. pgpn3NddLW6w2.pgp Description: OpenPGP digital signature
review for pygubu/0.27-1
hi Bo,
my comments for the pygubu package up for sponsorship in the Python
team:
* changelog: only a single entry is needed for an initial debian
release.
* copyright:
+ please remove the copyright statement at the start of the MIT
license paragraph so that it contains only the license terms;
+ tests/support.py appears to be based on [1] (i.e. from upstream
python, license info at [2])?
* control:
+ do you need python3-tk for any other purpose than running tests?
If not, mark as !nocheck;
+ "Description: Debian packaging for pygubu": you want to describe
pygubu itself here, not that it's packaged for Debian - every
package in the distribution is, after all.
* rules: the script at development/runtests.sh simply calls "python3
-m unittest" on the tests dir for the default python3 only, which
is not what you want. Consider letting pybuild (+pytest?) handle
things directly, for example by changing the override to something
like PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="xvfb-run -a
{interpreter} -m pytest -v tests" dh_auto_test.
* tests: you don't want to hardcode dependencies on an autopkgtest
that should be pulled in by the binary package.
There's a debian/.gitlab-ci.yml file but the CI isn't enabled in the
repository settings on salsa.
The binary package seems to be missing dependencies on tk, pil
(conditional import at src/pygubu/stockimage.py:124), as well as a
large number of tk-related modules used by the plugins (tkcalendar,
awesometkinter, customtkinter, tkintertable, tkintermapview, tksheet;
most of these don't seem to be packaged yet).
Have you done any functional testing on a (reasonably clean) debian
testing or unstable install?
[1]https://hg.python.org/cpython/file/b5ac5e25d506/Lib/lib-tk/test/runtktests.py
[2]https://hg.python.org/cpython/file/b5ac5e25d506/LICENSE
pgpZArB6DiIph.pgp
Description: OpenPGP digital signature
review for kivy/2.1.0-1
hi Dean, I reviewed the kivy package up for sponsorship in the Python team: * There's quite a few lintian hits [1], and most of those look legit. Please fix the correctly identified issues, and add overrides for any false positives. * In the changelog, you should mention this is a team upload; otherwise (with you not listed as either maintainer or uploader) it looks like an NMU. * The copyright file is missing many entries, including: doc/sources/.static/jquery.cookie.js:6: * Copyright (c) 2010 Klaus Hartl (stilbuero.de) doc/sources/.static/jquery-effects-core-and-slide.js:4: * Copyright 2011, AUTHORS.txt (http://jqueryui.com/about) doc/sources/.static/jquery-effects-core-and-slide.js:736: * Copyright 2001 Robert Penner kivy/lib/kivy_endian.h:3: Copyright (C) 1997-2018 Sam Lantinga kivy/lib/sdl2.pxi:1:#Copyright (c) 2010-2012, Gabriel Jacobo kivy/lib/libtess2/Source/...:** Copyright (C) [dates of first publication] Silicon Graphics, Inc. kivy/lib/libtess2/Include/tesselator.h:3:** Copyright (C) [dates of first publication] Silicon Graphics, Inc. kivy/tools/pep8checker/pep8.py:4:# Copyright (C) 2006-2009 Johann C. Rocholl kivy/tools/pep8checker/pep8.py:5:# Copyright (C) 2009-2014 Florent Xicluna kivy/tools/pep8checker/pep8.py:6:# Copyright (C) 2014-2016 Ian Lee Once fixed, simply add the package back to the RFS list in the IRC channel topic. [1] https://salsa.debian.org/python-team/packages/kivy/-/jobs/3617039 pgpiXRegg2c2B.pgp Description: OpenPGP digital signature
Re: librcsb-core-wrapper: (autopkgtest) needs update for python3.11: initialization of CorePyWrap raised unreported exception
On Thu, 8 Dec 2022 17:14:31 +0530 Nilesh Patra wrote: > > > SystemError: initialization of CorePyWrap raised unreported > > > exception autopkgtest [17:14:04]: test autodep8-python3 > Similar report is also filed for tagpy (Bug#1025201) -- could > someone please help in fixing these? Looks like https://lists.debian.org/debian-python/2022/12/msg00052.html pgp2bvp6RjRQr.pgp Description: OpenPGP digital signature
review for weresync/1.1.5-1
hi Ileana, took a look a the weresync package you put up for sponsopship in the Python team: * weird, probably unnecessary d/source/include-binaries that lists the upstream signing key; * autopkgtest: + runs in extracted source dir, might not test installed package; + only tests with the default python version rather than all supported releases; * missing dependency on gi gtk 3.0 (gir1.2-gtk-3.0) (imported at src/weresync/interface/gui.py:28). Also, for Python team packages, please keep the target release at UNRELEASED in accordance with team policy. The sponsor will set the target release before upload. pgpyvPj11QXYR.pgp Description: OpenPGP digital signature
Re: Review of Debian package pystray
hi Claudius, took a look at the pystray package up for sponsorship in the Python team. Overall it's in really good shape, still a few comments left though: * control: the long description is really short and mentions neither supported environment nor any other pystray features. * tests: + please loop over py3versions -s rather than -r; + both tests have the same test-name; + the upstream testsuite autopkgtest doesn't actually run any tests according to ci logs [1]; + for the upstream testsuite, you want to copy the test files to the $AUTOPKGTEST_TMP dir and run from there, to avoid testing the extracted sources rather than the installed package; + keeping the test commands/script in a separate file (rather than d/tests/control) tends to greatly increase readability for all but the smallest and most trivial autopkgtests. [1]https://salsa.debian.org/python-team/packages/pystray/-/jobs/3596337#L411 pgpgtW7j6XA5L.pgp Description: OpenPGP digital signature
Re: review for gtg/0.6-1
On Fri, 4 Nov 2022 16:07:56 +0100 François Mazen wrote: Thank you for making all those improvements. > > * copyright: > > + public domain without explanation detailing exactly what > > exemption the files in question have from default copyright > > restrictions. > > I don't know what do you expect here. The current description > contains "No copyright is claimed". What should I add? Copyright restrictions apply by default, so for something to be in the public domain requires some explicit statement to that effect by the copyright holder. While d/copyright says "No copyright is claimed" (which may or may not serve that purpose, depending on context) I cannot find that particular statement anywhere in the source. Where does it come from, who wrote it? (Or am I just overlooking something obvious?) > > * autopkgtests: > > + consider adding an autopkgtest based on the upstream > > testsuite. > > The upstream provides two test datasets but no associated tests for > the installed application. Should I write them myself? (would be > quite complex as it's a graphical interface) Tests don't necessarily have to be for the application as a whole, not to mention the existing 'smoke' and 'check-graphical-app' cover that part already. With the Debian CI triggering an autopkgtest run for gtg every time there's a change in a dependency, running an upstream testsuite that tests bits and pieces of code can still be useful for finding incompatibilities such changes may introduce. Also, testsuites based on pytest tend to be straightforward to turn into an autopkgtest, see for example [1] and [2]. I noticed on salsa that the updated d/rules tries to run the upstream testsuite during build but it errors out during test collection (and that error in turn doesn't trigger build failure). [1]https://salsa.debian.org/python-team/packages/puremagic/-/tree/master/debian/tests [2]https://salsa.debian.org/python-team/packages/nfoview/-/blob/debian/master/debian/tests/upstream-pytest pgp6BGta8qRei.pgp Description: OpenPGP digital signature
Re: New upstream version of sphinxext-opengraph 0.7.0
On Tue, 1 Nov 2022 12:33:59 -1000 Chiara Marmo wrote: > Dear list, > I have committed to salsa the new version of sphinxext-opengraph > [1]. If someone could have a look, that would be great. > Thanks! Looks like there's a newer upstream release, fixing bugs in 0.7.0? pgp8WgYblHIhF.pgp Description: OpenPGP digital signature
review for gtg/0.6-1
hi Francois, I took a look at the gtg package put up for sponsorship in the Python team: * changelog: + multiple entries for revisions that did enter the archive (0.3.1-2 through 4) appear to have gone missing? + there's about a dozen open bugs against the old package, yet only a single one gets closed. Did you review the outstanding bugs and check if any of them are fixed by the new upstream release and/or the revamped packaging? + it's team policy to keep the target distribution at UNRELEASED while a package is under review. + ITP bug not closed upon package reintroduction? * clean: consider converting the entries for deleting pycache stuff at depths other than 3 to also use globbing. * control: + long description should be extended. Assume the reader knows little or nothing about the application at all; what can it do, what makes it special, what services does it integrate with, and so on. Take a look at the upstream homepage if you need inspiration. + why list the old maintainer as uploader? + multiple missing dependencies for utilities called by script_pocketmod. + missing dep gir1.2-secret-1 (for the optional import of gi.repository.Secret in GTG/core/keyring.py) + missing dep for optional import of gi.repository.GnomeKeyring in GTG/core/keyring.py (though it seems that's not yet packaged in Debian so we might have to forego it for now). + missing dep gir1.2-pango-1.0 (for the unconditional import of Pango in GTG/gtk/browser/treeview_factory.py and other files; as well as PangoCairo in GTG/gtk/browser/cell_renderer_tags.py) + unused build-dep on itstool? + lots of build-deps only appear useful for testing; please mark those . * copyright: + public domain without explanation detailing exactly what exemption the files in question have from default copyright restrictions. + GTG/plugins/dev_console/* headers say LGPL, not GPL. + one Jean-François Fortin Tam is listed in the 'Files: *' paragraph, but only appears as a copyright holder in two files (GTG/core/info.py.in and a single translation). * docs: what purpose does a list of upstream authors serve as end user documentation? * patches: two out of three patches at first glance appear useful for inclusion upstream, yet all are marked 'Forwarded: not-needed'? * rules: + override_dh_auto_install starts by calling dh_auto_install; consider using execute_after_ instead of an override in such cases. + upstream testsuite (based on pytest) not run on build, why? * lintian: + X: gtg: executable-in-usr-lib usr/lib/python3/dist-packages/GTG/plugins/export/export_templates/script_pocketmod (wrong install location per FHS?) + X: gtg: executable-in-usr-lib usr/lib/python3/dist-packages/GTG/core/networkmanager.py (imported as a python module, file probably shouldn't be executable at all?) * autopkgtests: + please change directory to $AUTOPKGTEST_TMP before running test commands to ensure the test doesn't depend on anything from the extracted source pkg, see best practices at [1]. + consider adding an autopkgtest based on the upstream testsuite. * source: variables not properly quoted in 'script_pocketmod', cannot handle spaces (etc.) in the path of the source file; please patch. Once the above comments have been addressed, simply re-add the package to the IRC channel topic. Note: I didn't do any functional testing yet, in light of the need for significant changes to the current packaging. [1]https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices pgpmbgnj_P0OF.pgp Description: OpenPGP digital signature
Re: review for pipenv/2022.10.12-1
On Fri, 28 Oct 2022 16:46:51 +0300 Ileana Dumitrescu wrote: > > I did just notice the upstream release contains several other > > files worth considering for removal: a bunch of windows > > executables [1]. > > I agree and can remove those from the source tarball too. To do that > with the current upstream version in salsa though requires me to git > reset, re-import the 2022.10.25+ds upstream with updated > Files-Excluded, then add back the other commits. I have done that > locally but this requires a force push which is not allowed for the > debian branch since it is protected. You can avoid resetting or forcing anything by increasing the repacksuffix. As far as both git and the tooling are concerned, that makes it an all new upstream version without conflicts with the repo's current content, so pushing to git works just fine. First update the excluded files in d/copyright and commit that change, then run with the usual 'gbp import-orig --pristine-tar --uscan'. When gbp asks you for the upstream version, modify the +ds part to +ds2 and proceed with that. pgp2cYyiFNEPC.pgp Description: OpenPGP digital signature
Re: review for pipenv/2022.10.12-1
On Wed, 26 Oct 2022 17:29:59 +0300 Ileana Dumitrescu wrote: > Thank you for the feedback! I made changes as you suggested. There > is a new upstream version that I also included in the new package. Great! The copyright stuff is a chore on packages like this, so thanks alot for seeing that through. > Reading debian package policy I noticed that removing files from a > tarball for a repack (as Bastian suggested in bug #1019714) should > require a +ds suffix, so I packaged the new version with > 2022.10.25+ds-1. Please let me know if I did this incorrectly or if > this should not be done for this package. Indeed, a repacksuffix is used to indicate changes were made to an upstream release so that's perfectly fine this way. Typically, +dfsg is used to signal the source was repacked for DFSG compliance reasons and +ds when repacking for some other reason. I did just notice the upstream release contains several other files worth considering for removal: a bunch of windows executables [1]. > > + E: pipenv: python-traceback-in-manpage is a false positive, > please override. > > This did not show up in lintian with the new upstream version. It seems they revamped the manpage, although the new one also earns a lintian hit [1], this time about a bad (missing?) 'whatis' entry. Lintian seems to think the source for some html file is missing, but at first glance that hit may well be a false positive triggered by some bits of javascript. Unrelated to any of the above, I pushed some minor changes and enabled the CI on salsa. [1]https://salsa.debian.org/python-team/packages/pipenv/-/jobs/3434663 pgp5w4MKIi4xX.pgp Description: OpenPGP digital signature
review for pipenv/2022.10.12-1
hi Ileana,
I took a look at the package update you prepared and put up for
sponsorship in the Python team:
* leftover boilerplate comments and examples remain throughout the
packaging (control, rules, watch), please remove when unused.
* changelog: isn't #941447 also fixed by the new release? See
upstream's comment on https://github.com/pypa/pipenv/issues/4144
* copyright:
+ packaging year bumped for vent...@debian.org but his last
involvement actually does appear to have been in 2018; you
probably want to add yourself instead with a 2022 entry?
+ `grep -irn --exclude-dir=debian 'copyr.*\(19\|20\)[0-9]\{2\}' *`
turns up numerous copyright holders that are missing from
d/copyright.
* watch: filenamemangle introduces literal "" string into
the filename.
* lintian:
+ numerous hits for 'extra-license-file' and
'package-contains-documentation-outside-usr-share-doc', triggered
by license and readme files inside vendored libs; these files
could easily be removed during build.
+ E: pipenv: python-traceback-in-manpage is a false positive,
please override.
PS: I'm kind of surprised a package with this amount of vendoring
managed to survive the ftp masters' review. Apparently, sometimes
miracles do happen.
pgpiIaS9dS9qj.pgp
Description: OpenPGP digital signature
Re: review for python-ssdpy
On Mon, 3 Oct 2022 11:56:30 -0400 Ben Westover wrote: > Thanks, I didn't catch that since I use sbuild instead of pbuilder. > I have set the environment variable CI = true which should disable > those tests. Unfortunately, it doesn't. The change suggested below does make 'CI=true' take effect, but that still leaves a few failing tests not marked by upstream. Probably easiest to exclude those remaining troublemakers by instructing pybuild to set a pytest option, e.g. PYBUILD_TEST_ARGS = -k 'not ...'. --- a/debian/rules +++ b/debian/rules @@ -1,7 +1,6 @@ #! /usr/bin/make -f export PYBUILD_NAME = ssdpy -export CI = "true" # Skip tests which require network %: dh $@ --with python3,sphinxdoc --buildsystem=pybuild @@ -11,3 +10,7 @@ execute_after_dh_auto_build: execute_after_dh_auto_clean: rm -rf debian/html + +override_dh_auto_test: + # Skip tests which require network + CI=true dh_auto_test pgp3UsNZ2ufLA.pgp Description: OpenPGP digital signature
review for python-ssdpy
Hi Ben, * control: missing build-dep on python3-all? Needed to run the testsuite against all supported Python version rather than just the default one. * watch: regex "(\d\.\d.\d)" is overly specific, could easily miss upstream versions such as a hypothetical "1.5" or "1.4.10". Package ftbfs in pbuilder with errors in the testsuite; many of the failing tests are marked by upstream as incompatible with github ci, probably for similar reasons they fail in pbuilder, particularly assumptions regarding the availability and configuration of the network. See log at https://paste.debian.net/hidden/daadfbea/ pgpMZxZK9yepr.pgp Description: OpenPGP digital signature
Re: Bug#1007025: git-multimail 1.6.0 package review
On Thu, 22 Sep 2022 12:35:12 -0400 Antoine Beaupré wrote: > I think the simplest solution is not to rewrite the launcher, but to > rename it. So in debian/rules, you would simply do: > > override_dh_auto_install: > dh_auto_install > mv debian/git-multimail/usr/bin/git_multimail.py > debian/git-multimail/usr/bin/git-multimail Antoine, IIRC the git_multimail.py file upstream installs into /usr/bin is not a launcher but a full copy of the module as installed into /usr/lib/python3. The code in that file auto-detects whether it's run as a program. That resulted in two copies of that sizeable file in the package I reviewed back in June. Hence my suggestion - quoted in an earlier message by Bo - to replace the copy in /usr/bin with a tiny launcher, reducing the installed size of the package by almost half. pgpndg25pGdX0.pgp Description: OpenPGP digital signature
Re: New upstream version for numpydoc
On Sat, 3 Sep 2022 15:33:04 -1000 Chiara Marmo wrote: > I have opened merge requests on salsa for numpydoc [1] in order to > update to the last available upstream version 1.4.0 Any reason why you're no longer closing #1013376 when building your updated package against experimental seems to work just fine? pgpqIHZoXb5UC.pgp Description: OpenPGP digital signature
Re: sphinxext-opengraph 0.6.2 available for upload on salsa.
On Fri, 11 Mar 2022 12:42:48 -1000 Chiara Marmo wrote: > Dear list, > > a new version of sphinxext-opengraph (0.6.2) is available for > upload on salsa. Uploaded, thanks! pgph9YZjSJH6I.pgp Description: OpenPGP digital signature
Re: new upstream version (0.6.1) for sphinxext-opengraph
On Thu, 24 Feb 2022 14:35:05 -1000 Chiara Marmo wrote: > Dear list, > > a new version (0.6.1) of sphinxext-opengraph is ready for upload on > salsa [1]. Uploaded, thanks! pgpFolYaSjWEi.pgp Description: OpenPGP digital signature
Re: sphinxext-opengraph new upstream version and tests
On Sun, 2 Jan 2022 15:26:30 -1000 Chiara Marmo wrote: > Ready for upload? Uploaded with some minor changes. Thanks for your contribution. pgpSQMyHTArPC.pgp Description: OpenPGP digital signature
Re: sphinxext-opengraph new upstream version and tests
On Fri, 31 Dec 2021 17:25:34 -1000 Chiara Marmo wrote: > I think the configuration is better now, as the CI passed too. Using @builddeps@ may seem attractive at first, but is best reserved for autopkgtests that actually do a full build. In most other cases redundant extra stuff gets installed that's only needed at build time, such as dh-python and setuptools in this case. In addition, python packages that run tests at build time typically have the full set of module dependencies as build-deps that one also expects to find as deps on the (main) binary pkg. For such packages, using @builddeps@ causes dependencies of the package being tested to get duplicated as test deps, meaning any missing ones - for example resulting from a packaging or helper application bug - could easily be overlooked. After all, the autopkgtest would pass even for a severely broken binary package with all python deps missing. > Please let me know if the package is ready for the upload. The debhelper compat level could do with a bump to the current version. Other than that, things look fine. > Also, happy new year 2022 to all the people on the list! Indeed! pgpzP8eOm5RXv.pgp Description: OpenPGP digital signature
Re: sphinxext-opengraph new upstream version and tests
On Thu, 30 Dec 2021 14:27:09 -1000 Chiara Marmo wrote: > Dear list, Sandro, > > I have uploaded on salsa a new upstream version of > sphinxext-opengraph: > https://salsa.debian.org/python-team/packages/sphinxext-opengraph/ > > I have also modified the way how tests are run... but I'm still in > the process of understanding how autopkgtests works Enabling the CI on salsa for your package can be really helpful to verify things work as expected. As an added benefit, it also lowers the time and effort needed to review a package. Anyway, the current autopkgtest has a number of obvious flaws: * the binary package it's trying to test isn't actually installed at all because it's not listed as a test dependency; * the same goes for the supported python versions the test loops over (i.e. the necessary dependency on python3-all is missing). * on the other hand, dependencies of the package being tested (such as python3-sphinx) should not be duplicated as a test dependency; * within the control file, the field identifying tests in a separate file is called 'Tests', not 'Test-Command'. pgpok7AIgm01R.pgp Description: OpenPGP digital signature
Bug#985216: RFS: sabnzbdplus/2.3.6+dfsg-1+deb10u1 -- web-based binary newsreader with nzb support
Package: sponsorship-requests Severity: normal X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, Note that this update has been approved by the stable release managers, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984604 I am looking for a sponsor for my package "sabnzbdplus": * Package name: sabnzbdplus Version : 2.3.6+dfsg-1+deb10u1 Upstream Author : SABnzbd Team * URL : https://sabnzbd.org * License : GPL-2+ and others * Vcs : https://salsa.debian.org/python-team/applications/sabnzbdplus Section : contrib/net It builds those binary packages: sabnzbdplus - web-based binary newsreader with nzb support To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sabnzbdplus/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/contrib/s/sabnzbdplus/sabnzbdplus_2.3.6+dfsg-1+deb10u1.dsc Changes since the last upload: sabnzbdplus (2.3.6+dfsg-1+deb10u1) buster; urgency=medium . * Backport upstream security fixes to prevent code execution from the program's web interface through crafted settings. (CVE-2020-13124) Regards, -- jcfp pgpap78Dt6ZED.pgp Description: OpenPGP digital signature
