Re: Debian Python Team Join Request: Jason Blackwell
Hi Jason, Louis-Philippe Véronneau writes: > On 2024-09-09 16:16, Jason Blackwell wrote: >> Hi all, >> >> I would like to join the Debian Python Team to help maintain the >> pmbootstrap package to start. I have interest in working on other >> packages as well once I get the process down. >> >> I would like to tackle this bug first: https://bugs.debian.org/cgi-bin/ >> bugreport.cgi?bug=1079785 >> >> Followed by: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069772 >> >> If approved, I will work to consolidate these merge requests and make >> changes directly to the branches for the 2.3.1 pmbootstrap update as >> recommended on #debian-python. >> >> https://salsa.debian.org/python-team/packages/pmbootstrap/-/ >> merge_requests/1 >> https://salsa.debian.org/python-team/packages/pmbootstrap/-/ >> merge_requests/2 >> https://salsa.debian.org/python-team/packages/pmbootstrap/-/ >> merge_requests/3 >> >> Salsa login: @blackwell https://salsa.debian.org/blackwell >> >> I have read https://salsa.debian.org/python-team/tools/python-modules/ >> blob/master/policy.rst and I accept the terms. >> >> Please let me know if there is any other information I can provide, or >> if you have ideas on other packages/things that I can assist with. >> >> Regards, >> >> Jason Blackwell >> >> >> >> Background: >> >> https://www.linkedin.com/in/blackwelljason/ >> >> https://github.com/blackwellops/ >> >> Commits for Fedora pmbootstrap 2.3.1 update: https:// >> src.fedoraproject.org/rpms/pmbootstrap/ >> c/613271ac8c52aa5d3ba03ba472b53e26ebe2451b?branch=rawhide >> >> Current Maintainer for pmbootstrap on Gentoo GURU: https://github.com/ >> gentoo/guru/blob/master/dev-util/pmbootstrap/metadata.xml >> > > Welcome to the team :) P.S. Wow, impressive introduction and statement of intent! :) Cheers, Nicholas signature.asc Description: PGP signature
[2to3 and fissix] Re: Python3.12 and a half
Alexandre Detiste writes: > Hi, > > Would it be possible to remove 2to3 from Python3.12 without waiting for 3.13 ? > > I see in the meantime a new usage was brought back. > > I'll check if this "slimit" package can be easily switched to python3-fissix; > which is a 2to3 fork that is already used to keep python3-nose > artificially alive. For the record, python3-fissix is a backport of the latest available 2to3, not a fork. I communicated with upstream about its future a couple of years ago, and the long-term plan at that time was that fissix would either: 1. Cease to exist when 2to3 was eventually dropped (both were planned even back then), or else 2. Possibly migrate to something else but maintain legacy interfaces 3. Someone else actually forks 2to3 from Python 3.12, and fissix begins to depend on that fork. Has anyone heard anything about the second or third cases? Regards, Nicholas signature.asc Description: PGP signature
Re: Moving default branch after project creation
Julian Gilbey writes: > On Wed, Aug 07, 2024 at 08:27:33PM +0300, Alexandru Mihail wrote: >> Hi, I've recently created >> https://salsa.debian.org/python-team/packages/psrecord following >> previous ITP. The main branch was set to main and I'd like to move it >> to DEP compliant debian/master and delete the main branch. > > The candidate DEP-14 (https://dep-team.pages.debian.net/deps/dep14/) > currently reads: > > In Debian this means that uploads to unstable and experimental > should be prepared either in the debian/latest branch or > respectively in the debian/unstable and debian/experimental > branches. > > I'm not sure where you got debian/master from? FYI debian/master was DEP14: Changes 2014-11-05: Initial draft by Raphaël Hertzog. 2016-11-09: Extended version mangling to troublesome dots -- Ian Jackson. 2020-11-29: * Replace /master with /latest * Recommend / over / for the devel branch * For native packages, require the default branch to be a devel branch * Minor typo fixes and cosmetic changes * Promote DEP to State: CANDIDATE Last edited Fri, 08 Mar 2024 12:33:22 + https://dep-team.pages.debian.net/deps/dep14/ It's certain that there are many packages that follow DEP14 DRAFT rather than CANDIDATE. An alternative interpretation is that DEP14 strong recommends (ie "should use", "should be", "we recommend") /latest rather than /master. Thus, /master is arguably still more DEP14 than not. We've also seen the proliferation of /main development branches that fulfil all of the technical objectives of DEP14, and I would consider them to also be DEP14. As an aside, I'm curious what the undocumented 2024 edit was. Best, Nicholas signature.asc Description: PGP signature
Re: OK to create a new package in "python-team/packages/"
Carsten Schoenert writes: > Am 15.03.24 um 08:31 schrieb c.bu...@posteo.jp: > >> On the long run it is my goal to make the package [1] ready for official >> upload. But I suspect this is a long way. So on short view that repo >> will be for practicing only. Am I allowed to create such a repo in my >> position? Christian, have you filed an ITP (intent to package) yet? If not, please do so as soon as you can. https://wiki.debian.org/ITP > There is no need to start any packaging work within the Salsa group of > the DPT. You can start any work within your namespace and move the > package to any other group later if needed and appropriate. > > And within your namespace you can e.g. do force pushing if you feel you > need to, within team space that's a no go. > +1 Carsten, that's my recommendation too, same rationale, and I'd add that starting a project in personal namespace is zero risk. 1. You have a remote backup of your work. 2. You can do whatever you want with it (ie make branches and/or tags of experiments that may or may not work out, squash, rebase, force push--as noted--etc.) 3. So it's lower stress and builds confidence faster than working directly in a team-managed namespace imho. 4. Moving the repo during the sponsorship procedure can be a reassuring milestone. 5. Doing Debian development "in the open" is sometimes an uncomfortable adjustment, and staging work in personal namespace is a more gentle path. Regards, Nicholas signature.asc Description: PGP signature
Re: Review of package dunamai
Louis-Philippe Véronneau writes: > Hmm, whatever? It's really a matter of personal preferences. I tend to > be lazy and not want to build on experimental because the sbuild script > is more tedious... :) > Can I interest you in testing a wrapper script that I've been thinking about sharing for a while now? Basically it does a bunch of safety checks and convenience things, then builds for the right distro, then tags if the build was successful. Thus far it's based on a gbp paradigm, but some people on debian-backports said it would be nice if it could take source packages as input. Long-term, I'm not convinced that it would be a good fit for devscripts or git-build-package, since it's something in between. As you noted, experimental is its own case, as are backports, stable updates, security uploads, and I also don't like to think sbuild incantations. Maybe I should call the script dtrt-build? ;) Cheers, Nicholas signature.asc Description: PGP signature
Re: pybuild now supports meson
Stefano Rivera writes: > Hi Simon (2023.08.02_18:23:31_+) >> On Wed, 02 Aug 2023 at 17:44:24 +, Stefano Rivera wrote: >> > The latest upload of dh-python to unstable (6.20230802) includes a >> > meson plugin, so pybuild can easily build a package multiple times for >> > all supported Python modules. >> >> I don't think this is necessarily appropriate for a lot of the packages >> in the dd-list: many of them don't install any public Python modules, >> only private Python modules for internal use (often only for their >> tests). It seems better for those to keep using Meson directly, to match >> upstream expectations and give their maintainers full control over their >> build options. > > Make sense. Is there a better method for fuzzing these modules with CI--as an early warning system for new Python releases? Would it be useful to activate the meson dh-python plugin somewhere like reprobuilds, DebCI, or Salsa CI, while leaving it deactivated on buildds? Cheers, Nicholas
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
Carsten Schoenert writes: > There is a private list there such information *can* be given, again, > there is no rule that I need to do this. > There are options if some other DD believes a package is needing an > update, that process is called NMU (non maintainer upload). Or if you > think the other maintainer isn't doing his work in a time able manner, a > DD can salvage a package. > But these options are only doable by DDs! And that for a reason. > Yes, a new contributor requires a DD for sponsored uploads; however, new contributors are not discriminated against when salvaging a package. "Thanks to this [salvaging] process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten." https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging While it's true that no one can force anyone to do anything in Debian, it's also true that if someone salvages a chronically ignored package, that is a consequence of not having taken care of it, and then not having replied to the ITS bug for a month. All this assumes both good faith, and that new contributors educate themselves sufficiently well to submit upload candidates on debian-mentors (and file RFS) that sufficiently improves on the status quo of a neglected or forgotten package. It's important to note that the value expressed by this policy is that consistent, periodic (or better) long-term contributions are valued in Debian. It's also important to highlight that this value is attainable as a Debian Maintainer (uploading a set of approved packages), or as a Debian Contributor who requires a sponsor for all uploads. Best, Nicholas signature.asc Description: PGP signature
Re: Python 3.11 for bookworm?
Sandro Tosi writes: > thoughts from a concerned maintainer > Sandro, thank you for writing this email. > > it seems this email advocates for a "let's wing it"[1] type of transition. > > [1] https://en.wiktionary.org/wiki/wing_it > > It appears there has been little work in preparing the work to > introduce python3.11 from its maintainer, instead that works has been > pushed downstream to maintainers. > > if we continue with the plan as described above, several python > libraries/applications maintainers will be left with the short end of > the stick and deal with an unknown amount of issues (upstream fixes > not available, not ready and or/ not released, rushed, etc) with less > than a month from the beginning of the transition freeze[2] > Agreed. At a bare minimum, complete data from ratt (Rebuild All The Things) should be required at this point. > [2] https://release.debian.org/bullseye/freeze_policy.html > > [2] also highlights at the very beginning "Plan your changes for > bullseye", this change appears as if it was not planned and we should > be skeptical to proceed without further (and in advance) understanding > of the impact it may have on Bullseye. > 100% +1 I'm especially concerned about how a clear plan was not communicated to other teams--whose work will be broken by the proposed transition, were an exception to be granted. Debian is not a paragon of community if it makes late, unannounced changes that result in a yet-undetermined number of projects being dropped from bookworm's release. If Python 3.11 as the only supported version is a release goal, then the freeze schedule would need to be modified. Regards, Nicholas signature.asc Description: PGP signature
Convert dephell and bowler ITPs to RFPs
submitter 962574 ! retitle 962574 RFP: dephell -- project management for Python noowner 962574 submitter 941054 ! retitle 941054 RFP: python-bowler -- safe code refactoring for modern Python projects noowner 941054 thanks I have not found the time to make meaningful progress on Dephell and its dependency Bowler, so am converting these ITPs to RFPs. Please feel free to take them over. Best, Nicholas signature.asc Description: PGP signature
Re: [Pkg-privacy-maintainers] Bug#1007165: Bug#1007165: please import upstream v21.1.0
Antoine Beaupré writes: > I'm working on uploading v22 right now. > Thank you Antoine! signature.asc Description: PGP signature
Re: xlsxwriter: How to change homepage url
Hi Christian, c.bu...@posteo.jp writes: > Dear Emmanuel, > > Am 15.09.2021 21:36 schrieb Emmanuel Arias: >> Looking in the salsa repo [0], it is very old. And that shouldn't >> happen. I >> can updated to the last unstable version tonight/tomorrow. > > Just to improve my knowledge about Debian processes: What does it mean > to update the salsa repo to the current upstream? Is it the same as > create a new package? Or is it just one step into creating a new > package? > I didn't look at the packages in question, but as a matter of team policy, the Debian Python Team uses git-buildpackage repositories, with pristine-tar, and a repo's layout is as follows: 1. Pristine-tar branch (upstream tarball is imported here) 2. Upstream branch (upstream tarball is unpacked here) 3. Debian packaging branch (name varies) * https://dep-team.pages.debian.net/deps/dep14/ is the standardisation effort the DPT has adopted. * another key phrase is a "patches unapplied" packaging branch. `gbp import-orig --pristine-tar --uscan` downloads the latest tarball and puts it in #1, then unpacks it to #2, then creates an upstream/new_version tag on this upstream branch, then merges that tag to #3. One then needs update the version of the current changelog entry (if UNRELEASED), or create a new one with `dch -v$new_upstream_version-1`. Finally, one may need to use `gbp pq` to import, rebase, and export an existing quilt patch series onto the new upstream release. https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#git-procedures https://wiki.debian.org/Python/FAQ https://wiki.debian.org/Python/GitPackaging Other teams/individuals have different policies and practises. 'hope that helps! Regards, Nicholas signature.asc Description: PGP signature
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
Hi Jeremy! Wow, you've given me a lot to think about. Thank you :-) Yes, I agree with you that my MR doesn't adequately address the much more heterogeneous reality. (and is also indelicate, lacks nuance, etc) I'll take a day or two to think about this, and also to take into account what everyone else has written before making revisions for v2. If I do it right now my work won't be rigorous enough, nor fair to the contributions others have made to this thread. If nothing else it will require careful outlining... Maybe the heading should be: How to choose a source for the tarball (and why this can be difficult) == ;-) Take care, Nicholas signature.asc Description: PGP signature
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
Hi Simon,
Simon McVittie writes:
> On Fri, 25 Jun 2021 at 16:42:42 -0400, Nicholas D Steeves wrote:
>> I feel like there is probably consensus against the use of PyPi-provided
>> upstream source tarballs in preference for what will usually be a GitHub
>> release tarball
>
> This is not really consistent with what devref says:
>
> The defining characteristic of a pristine source tarball is that the
> .orig.tar.{gz,bz2,xz} file is byte-for-byte identical to a tarball
> officially distributed by the upstream author
>
> —
> https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#best-practices-for-orig-tar-gz-bz2-xz-files
>
> Sites like Github and Gitlab that generate tarballs from git contents
> don't (can't?) guarantee that the exported tarball will never change -
I agree 100%
> I'm fairly sure `git archive` doesn't try to make that guarantee - so it
> seems hard to say that the official source code release artifact is always
> the one that appears as a side-effect of the upstream project's git hosting
> platform.
>
Also agreed 100%. This line of inquiry is actually why I think using
upstream tags is best, but even then it's possible upstream will delete
the tag and push a new one. Does PyPi provide immutable releases? If
so, yes, I agree there's a strong argument to be made for using PyPi vis
à vis DevRef within a DPT context where upstream git tags (and history)
are not merged :-)
> That doesn't *necessarily* mean that the equivalent of a `git archive`
> is always the wrong thing (and indeed there are a lot of packages where
> it's the only reasonably easily-obtained thing that is suitable for our
> requirememnts), but I don't think it's as simple or clear-cut as you
> are implying.
>
Also agreed 100%, but I've learned people often look at comprehensive
proposals as tldr, so I wanted to try a discussion-based approach ;-)
> devref also says:
>
> A repackaged .orig.tar.{gz,bz2,xz} ... should, except where impossible
> for legal reasons, preserve the entire building and portablility
> infrastructure provided by the upstream author. For example, it is
> not a sufficient reason for omitting a file that it is used only
> when building on MS-DOS. Similarly, a Makefile provided by upstream
> should not be omitted even if the first thing your debian/rules does
> is to overwrite it by running a configure script.
>
> I think devref goes too far on this - for projects where the official
> upstream release artifact contains a significant amount of content we
> don't want (convenience copies, portability glue, generated files, etc.),
> checking the legal status of everything can end up being more work than
> the actual packaging, and that's work that isn't improving the quality of
> our operating system (which is, after all, the point).
>
I agree, and will support a proposal to modify DefRef to this end,
because as far as I know the source tarballs in our archive aren't part
of a secondary project to archive upstream tarballs as-released (eg: a
kind of "ark" or source-bank, like a seed-bank, for DFSG software)...but
maybe that is a secondary objective?
> However, PyPI sdist archives are (at least in some cases) upstream's
> official source code release artifact, so I think a blanket recommendation
> that we ignore them probably goes too far in the other direction.
>
> I'd prefer to mention both options and have "use your best judgement,
> like you have to do for every other aspect of the packaging" as a
> recommendation :-)
>
So far the text I've been able to come up with to address this is
something like:
In some cases PyPI sdist archives may be the most appropriate
upstream source tarball (then your "use your best judgement..."
as a conclusion) :-)
It would be really nice to include technical reasons that describe cases
where PyPI is more appropriate, but I don't know any. My experience in
Debian thus far has been that "what most closely fulfils Debian ideals"
is always preferable to upstream preference. Yes, that's arguably
insular, but I thought there was consensus on this.
And yes, I agree moderate is better, but I must sadly confess ignorance
to the technical reasons why PyPI is sometimes more appropriate.
Without technical reasons it seems like a case of ideological compromise
(based on the standards I've been mentored to and the feedback I've
received over the years).
Thanks!
Nicholas
signature.asc
Description: PGP signature
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
Hi Scott, Scott Talbert writes: > On Fri, 25 Jun 2021, Jeremy Stanley wrote: > [snip] > I tend to agree about PyPI being the official releases for a lot of > projects. "GitHub tarballs" also tend to include other undesirable stuff > for distribution like upstream CI/CD configuration files, etc. > Would you please expand on "etc"? It seems like it would be reasonable to exclude CI/CD files via the watch file for the similar reasons to excluding an upstream-provided debian/ subdir. Thanks! Nicholas signature.asc Description: PGP signature
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
Hi Jeremy, Thank you for your comments, reply follows inline: Jeremy Stanley writes: > On 2021-06-25 16:42:42 -0400 (-0400), Nicholas D Steeves wrote: >> I feel like there is probably consensus against the use of PyPi-provided >> upstream source tarballs in preference for what will usually be a GitHub >> release tarball, so I made an MR to this effect (moderate recommendation >> rather than a "must" directive): >> >> >> https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/16 >> >> Comments, corrections, requests for additional information, and >> objections welcome :-) I'm also curious if there isn't consensus by >> this point and if it requires further discussion > > I work on a vast ecosystem of Python-based projects which consider > the sdist tarballs they upload to PyPI to be their official release > tarballs, because they encode information otherwise only available > in revision control metadata (version information, change history, > copyright holders). The proposal is somewhat akin to saying that a > tarball created via `make dist` is unsuitable for packaging. > A recommendation is non-binding, and the intent of this proposal is to say that the most "sourceful" form of source is the *most* suitable for Debian packages. The inverse of this is that `make dist` is less suitable for Debian packages. Neither formulation of this premise applies to a scope outside of Debian. In other words, just because a particular form of source packaging and distribution is not considered ideal in Debian does not in any comment on its suitability for other purposes. Would you prefer to see a note like "PyPi is a good thing for the Python ecosystem, but sdists are not the preferred form of Debian source tarballs"? It's also worth mentioning that upstream's "official release" preference is not necessarily relevant to a Debian context. Take for example the case where upstream exclusively supports a Flatpak and/or Snap package... > "GitHub tarballs" (aside from striking me as a blatant endorsement > of a wholly non-free software platform) lack this metadata, being > only a copy of the file contents from source control while missing > other relevant context Git would normally provide. "GitHub [and Gitlab!] tarballs" are fairly well understood, and it takes fewer words to talk about them than to write about integrating a merging or rebasing tag-based workflow (possibly with excluded files with a merge driver) in a team that has standardised on git-buildpackage. I might have out-of-date info, btw. Would it still upset the DSA if DPT packages' watch files polled using the lightweight git driver? I also prefer to have upstream git history :-) Thinking about an ideal solution, and the interesting PBR case, I remember that gbp is supposed to be able to associate gbp tags with upstream commits (or possibly tags), so maybe it's also possible to do this: 1. When gbp import-orig finds a new release 2. Fetch upstream remote as well 3. Run PBR against the upstream release tag 4. Stage this[ese] file[s] 5. Either append them to the upstream tarball before committing to the pristine-tar branch, or generate the upstream tarball from the upstream branch (intent being that the upstream branch's HEAD should be identical to the contents of that tarball) 6. Gbp creates upstream/x.y tag 7. Gbp merges to Debian packaging branch. Cheers, Nicholas signature.asc Description: PGP signature
[RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
Hi Team! I feel like there is probably consensus against the use of PyPi-provided upstream source tarballs in preference for what will usually be a GitHub release tarball, so I made an MR to this effect (moderate recommendation rather than a "must" directive): https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/16 Comments, corrections, requests for additional information, and objections welcome :-) I'm also curious if there isn't consensus by this point and if it requires further discussion Cheers, Nicholas signature.asc Description: PGP signature
Bug#984561: Pre-approval for uploading vorta/0.7.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Dear Release Team,
With the exception of added translations (the bulk of the changes),
six small features added by samuel-w ("papercut" class bugs), and
commits irrelevant to the Debian package, all of the changes to
yet-to-be-uploaded vorta/0.7.5-1 since 0.7.1-4 have been to polish and
stabilise Vorta in time for Debian Bullseye. Locking/race/thread
safety issues were found along the way, and this release will close
#978105 and #983265.
Unfortunately we were a few days late due to difficulties tracking
down CI failures on armhf (and scarcity of free time). I have since
learned how to use porterboxes and qemu virtualised arm, and have
confirmed 10 runs of self-tests pass on able.debian.org, and 10 runs
of formal autopkgtests in virtualised armhf. All this time, Manuel,
the upstream maintainer was eager to learn how I was discovering these
issues, and how to replicate the test-bed, and our correspondences
make up the beginnings of a
Testing-my-upstream-Application-on-Debian-HOWTO.
Working with Manuel to stabilise Vorta has been the most inspiring and
fulfilling Debian work I've done this year, and I hope that you will
consider making an unblock exception for an upstream who has gone
above and beyond to prepare their software for its first release in
Debian stable. How many of our upstreams took the initiative to learn
to QA against a local virtualised DebCI instance, virtualised on
armhf?
It's a couple of days late, the commit list looks long, and there are
a half-dozen commits that aren't targetted fixes. I understand these
count against my case, and I trust you will consider the
community-building and technical benefits of allowing the 0.7.5
release to be part of Bullseye. I believe 0.7.5 is of significantly
higher quality than 0.7.1, and that this is the release we want in
Bullseye.
Debdiff and commit shortlog provided below, and I've additionally
attached diffs between the upstream source (with Debian patches
applied) of each Debian unstable release made (none which migrated to
testing).
= DEBDIFF =
debdiff vorta_0.7.1-4_all.deb vorta_0.7.5-1_all.deb
Files in second .deb but not in first
-
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.5.egg-info/PKG-INFO
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.5.egg-info/dependency_links.txt
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.5.egg-info/entry_points.txt
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.5.egg-info/requires.txt
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.5.egg-info/top_level.txt
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta/assets/icons/eject.svg
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta/assets/icons/ellipsis-v.svg
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta/assets/icons/eye-slash.svg
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta/assets/icons/eye.svg
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta/assets/icons/icon.svg
-rw-r--r-- root/root /usr/lib/python3/dist-packages/vorta/borg/break_lock.py
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta/borg/info_archive.py
-rw-r--r-- root/root /usr/lib/python3/dist-packages/vorta/borg/info_repo.py
-rw-r--r-- root/root /usr/lib/python3/dist-packages/vorta/borg/rename.py
-rw-r--r-- root/root /usr/lib/python3/dist-packages/vorta/i18n/qm/vorta.gl.qm
-rw-r--r-- root/root /usr/lib/python3/dist-packages/vorta/i18n/qm/vorta.ru.qm
-rw-r--r-- root/root /usr/lib/python3/dist-packages/vorta/i18n/qm/vorta.sv.qm
-rw-r--r-- root/root /usr/lib/python3/dist-packages/vorta/keyring/kwallet.py
Files in first .deb but not in second
-
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.1.egg-info/PKG-INFO
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.1.egg-info/dependency_links.txt
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.1.egg-info/entry_points.txt
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.1.egg-info/requires.txt
-rw-r--r-- root/root
/usr/lib/python3/dist-packages/vorta-0.7.1.egg-info/top_level.txt
-rw-r--r-- root/root /usr/lib/python3/dist-packages/vorta/borg/info.py
Control files: lines which differ (wdiff format)
Installed-Size: [-802-] {+1003+}
Version: [-0.7.1-4-] {+0.7.5-1+}
= COMMIT SHORT LOG =
af2d6a9 (HEAD, tag: v0.7.5, master) Bump version to v0.7.5, update translations
c66b102 Use json mode to list archive files. By @rblenis (#885)
bd3c479 Add untranslated strings. By @samuel-w (#902)
f7533b7 Disable codecov comments (#904)
6d8ad90 Allow to fully disable using the system keychain. (#898)
824707c Fix issue with unassigned self.handle (#899)
84c3d3c (tag: v0.7.4) B
Re: Questions around the python-policy document
Hi Fabrice, Fabrice BAUZAC-STEHLY writes: > Hello Debian-Python, > > I have a few questions regarding the Python Policy: > https://www.debian.org/doc/packaging-manuals/python-policy/ > > - Is there a Debian package for reading it offline? (apparently not) > > - Who maintains this document: is it the Policy team, the Python team? > > - Where is the source code? I could not find it on salsa... > apt-file search python-policy Then identify the package it comes from and "debcheckout" that package. Other answers can be found there :-) Regards, Nicholas signature.asc Description: PGP signature
Re: Merging the PAPT and the DMPT
Ondrej Novy writes: > Hi, > > po 21. 9. 2020 v 13:04 odesílatel Ondrej Novy napsal: > >> Todo: >> >>- send debian-devel-announce (i will) >>- mass-commit vcs+maintainer change >> >> > done. > > Thanks to all who helped me with these. > Yes, thank you! And I'm sure maintainers with lots of packages are even more appreciative than myself :-) Best, Nicholas signature.asc Description: PGP signature
Re: Merging the PAPT and the DMPT
Hi, Dmitry Shachnev writes: > Hi Ondrej! > > On Mon, Sep 14, 2020 at 09:59:00AM +0200, Ondrej Novy wrote: >> Hi, >> >> I prepared scripts for: >> >>- cloning ACLs from modules+applications subgroups to newly created >>packages subgroup >>- transferring all project from modules+applications to packages subgroup >>- tested on one project: >>https://salsa.debian.org/python-team/packages/alembic >> >> It looks like old web URLs works just fine: >> https://salsa.debian.org/python-team/modules/alembic > > I think it's better to update Vcs fields in all packages to point to the > new location, not one that redirects. > > Probably also update Maintainer/Uploader fields with the new team name/email. > Are there plans to do this team-wide (for team email in Maintainer) in one fell swoop, or will this be a per-maintainer task? Thanks, Nicholas signature.asc Description: PGP signature
Re: Joining PAPT
Hi Taowa, Taowa Munene-Tardif writes: > Hello, > > I am taking over membernator, currently maintained by pollo. To this > end, I'd like to be granted access to the team to allow me to > effectively do so. I am taowa on Salsa. > > I have read and agree to the Python Applications Packaging Team > Policy [1], > Sorry for the belated reply. Just wanted to send to a note to say it's cool to hear you're working on packages now, and also this: Welcome to the team! Cheers, Nicholas signature.asc Description: PGP signature
Re: Bug#962574: ITP: dephell -- project management for Python
Hi Scott, devel, and Python team, Nicholas D Steeves writes: > Control: block -1 by 962574 > > Tomlkit seems to be required for self-tests. > Thank you for taking care of tomlkit so quickly! I wish I had more time and energy to make faster progress with DepHell. Today I discovered it appears to require packaging 14 dephell-.* modules, listed here: https://pypi.org/search/?q=dephell so it's going to be a while (months) before I complete this ITP (which blocks my solution for converting pyproject.toml to setup.py for fissix and thus Bowler). If anyone would like to help out with the dephell-.* dependencies to speed this process along, please go ahead, and let me know if you'd like a comaintainer/second Uploader. Failing that, I'll get to it as soon as I can :-) Best, Nicholas signature.asc Description: PGP signature
Re: Offer to help with packaging
Hi Pablo, Pablo Mestre writes: > El 7/1/20 a las 10:58 PM, Nicholas D Steeves escribió: >> Awesome, thank you :-) I expect it will be a popular package too! > [.] >> If you're committed to packaging python lsp, then set yourself as the >> owner of #96360[5], and retitle it, replacing "RFP" with "ITP". > Yes, I committed to packaging >> If the absence of a python-jsonrpc-server package is a blocker for >> #963605, and you want to work on it, then file an ITP for >> python-jsonrpc-server, set yourself as owner, and also set up a blocks >> relationship between the two bugs. > > You mean > > Control: block 946035 by -1 This blocks the spyder bug with the new bug, and is generally used from the email that creates a new bug. Hint: #963605 contains an example Cheers, Nicholas signature.asc Description: PGP signature
Re: Offer to help with packaging
Hi Pablo, Pablo Mestre writes: > Im working on python-language-server Awesome, thank you :-) I expect it will be a popular package too! > but looks like also depends on python-jsonrpc-server and I dont find > any solution on Debian repositories. > > Any suggestion? > If you're committed to packaging python lsp, then set yourself as the owner of #96360, and retitle it, replacing "RFP" with "ITP". If the absence of a python-jsonrpc-server package is a blocker for #963605, and you want to work on it, then file an ITP for python-jsonrpc-server, set yourself as owner, and also set up a blocks relationship between the two bugs. Tools for doing this more conveniently are "bts" from devscripts, and "reportbug" for filing the ITP. IIRC bts requires an MTA (mail transport agent) and for this I'd recommend msmtp-mta, because most people find it easier to configure authentication with it than with Postfix, Exim, etc. If you'd like to do it manually for now, see: https://www.debian.org/Bugs/server-control If you use cont...@bugs.debian.org, please CC the bug's email. It's also possible to reply to a bug with this magic control server header: Control: command -1 arguments "-1" is a convenient alias for the bug number. For more info, see the man bts(1), the server-control documentation, and Developer's Reference: https://www.debian.org/doc/manuals/developers-reference/ Cheers, Nicholas signature.asc Description: PGP signature
Bug#962574: ITP: dephell -- project management for Python
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Package name: dephell Version : 0.8.3 Upstream Author : Gram URL : http://www.example.org/ License : MIT (declared, but probably Expat) Programming Lang: Python Description : project management for Python DepHell Project management for Python * Format agnostic: supports setup.py, requirements.txt, Pipfile, poetry. DepHell converts between them at any time. * All-in-one-solution: manage dependencies, virtual environments, tests, CLI tools, packages; generate configs; show licenses for dependencies; assist with security audits; get download statistics from PyPI; search packages, and much more. * Smart dependency resolution: manages dependencies, resolves, and enables locking of dependencies that pip missed. * Asyncio based: optimised network and filesystem requests. * Multiple environments: facilitates the use of multiple environments per project. * Release tools: provides build, test, version upgrade, and upload helpers. When I imported the latest version of Fissix, I discovered that it had migrated to pyproject.toml. I asked #debian-python about what the status of Debian tooling is for this format, and had a good discussion with ScottK. My immediate motivation for packaging DepHell is to convert Fissix's pyproject.toml to setup.py to expedite the completion of its ITP. I also wonder if it might be useful within a dh_python context. It's highly likely this software will be useful to the general Python developer community, and I plan to maintain it in either the DPMT or PAPT, as appropriate. Please comment on this! If anyone on the DPMT or PAPT would like to comaintain this package, please let me know, and I'll add you to Uploaders without delay. I will require a sponsor for the initial upload. Regards, Nicholas
Re: PEP-517/PEP-518 Support In Debian
Hi Scott, Thank you for the quick reply! Scott Kitterman writes: > On Thursday, June 4, 2020 7:39:59 PM EDT Nicholas D Steeves wrote: >> Scott Kitterman writes: >> > On Monday, April 13, 2020 5:18:53 AM EDT Dmitry Shachnev wrote: >> >> Hi Scott! >> >> >> >> On Sun, Apr 12, 2020 at 06:31:57PM -0400, Scott Kitterman wrote: >> >> > This being roughly the mid-point in the development cycle, I thought it >> >> > might be good to see where we are in terms of future Python packaging >> >> > developments. >> >> > >> >> > As I understand it, PEP-517 and PEP-518 are 'the future'. >> >> While importing the latest release of Fissix (a grammar parser used by >> Bowler) I found that it had a pyproject.toml but no setup.py. >> >> >> > I took a look at the presence of pyproject.toml files in the Debian >> >> > archive. There are currently 99 packages. Of those, only 28 specify a >> >> > 'build-backend', which is required by 517/518 to be useful for building >> >> > a >> >> > package. >> >> > >> >> > 25 specify: build-backend = "setuptools.build_meta" (including >> >> > setuptools) >> >> > 3 specify: build-backend = "flit_core.buildapi" (including flit) >> >> >> >> pyqt5 and pyqt5webengine specify: build-backend = "sipbuild.api". >> >> Is there existing documentation around if/how build-backend can be used >> to work around the absence of setup.py? >> >> > So they do. They didn't show up in my codesearch.d.n results, that makes >> > me wonder what else I missed. If anyone has an idea of a better way to >> > track this, please speak up. >> > >> >> > If build-backend is not specified, the build system has to fall back to >> >> > setup.py. >> >> > >> >> > I've recently package flit (just arrived in Testing) and written a flit >> >> > plugin for pybuild that's pending review for merging[1]. I also >> >> > packaged >> >> > pep517 for our pip package, so that's available to support future >> >> > Debian >> >> > tool development in this area. >> > >> > P1otr merged the flit plugin a little while ago, so it'll be in the next >> > dh- python upload. >> >> I think this is probably what is needed to unblock work on fissix (and >> thus Bowler), because its Makefile has: >> >> python -m pip install -r requirements.txt >> python -m pip install -r requirements-dev.txt >> python -m flit install --symlink >> >> [snip] >> >> Any advise for existing workarounds would be appreciated. So far the >> only idea I've had is writing or generating a setup.py, and then adding >> it as a quilt patch. > > That is probably the best approach for now. > Thank you for the ACK :-) > Ultimately we have two choices: > > 1. Add per-backend capability into pybuild as I have done with flit. > Depending on how many of them there are, this may or may not be a reasonable > approach. > > 2. Use the pep517 module with pip in our package build system. I think > Fedora has gone this direction. > > I prefer #1 because we want to produce a traditional bdist, not wheels, but > we'll have to do the work. I don't think we want an impenetrable morass of > zip files in /usr/lib/python3/dist-packages. > I also prefer #1. Here's an idea for reducing the work, and more importantly reducing the Debian-specific investment in time: Dephell (from the author of Poetry?) claims to support: egginfo, sdist, wheel, pip, piplock, pipfile, pipfilelock, poetry, poetrylock, already installed system-wide packages, plus setup.py, flit, conda, and pyproject. More interestingly it claims to be able to convert between formats, eg: dephell deps convert --from=pyproject.toml --to=setup.py Within a Debian packaging context this seems like it would be useful, because packages whose upstreams change formats could continue to use their existing rules file with the addition of a 'dephell deps convert' step. It seems like it might fit well with DPMT Policy, in that we could recommend conversion to a particular format, for use with a particular buildsystem, for uniformity of packaging. Finally, if that conversion capability works well then an effect is that Debian packaging is effectively decoupled from upstream buildsystem changes, and this seems like a good thing. Downside: Their installation instructions (curl -L dephell.org/install | python3) make me wonder if there is a fundamental cultural difference that would make this a no-go. tldr: Could integrating Dephell into dh_python solve these challenges once and for all? Regards, Nicholas signature.asc Description: PGP signature
Re: PEP-517/PEP-518 Support In Debian
Hi, Scott Kitterman writes: > On Monday, April 13, 2020 5:18:53 AM EDT Dmitry Shachnev wrote: >> Hi Scott! >> >> On Sun, Apr 12, 2020 at 06:31:57PM -0400, Scott Kitterman wrote: >> > This being roughly the mid-point in the development cycle, I thought it >> > might be good to see where we are in terms of future Python packaging >> > developments. >> > >> > As I understand it, PEP-517 and PEP-518 are 'the future'. >> > While importing the latest release of Fissix (a grammar parser used by Bowler) I found that it had a pyproject.toml but no setup.py. >> > I took a look at the presence of pyproject.toml files in the Debian >> > archive. There are currently 99 packages. Of those, only 28 specify a >> > 'build-backend', which is required by 517/518 to be useful for building a >> > package. >> > >> > 25 specify: build-backend = "setuptools.build_meta" (including setuptools) >> > 3 specify: build-backend = "flit_core.buildapi" (including flit) >> >> pyqt5 and pyqt5webengine specify: build-backend = "sipbuild.api". > Is there existing documentation around if/how build-backend can be used to work around the absence of setup.py? > So they do. They didn't show up in my codesearch.d.n results, that makes me > wonder what else I missed. If anyone has an idea of a better way to track > this, please speak up. > >> > If build-backend is not specified, the build system has to fall back to >> > setup.py. >> > >> > I've recently package flit (just arrived in Testing) and written a flit >> > plugin for pybuild that's pending review for merging[1]. I also packaged >> > pep517 for our pip package, so that's available to support future Debian >> > tool development in this area. > > P1otr merged the flit plugin a little while ago, so it'll be in the next dh- > python upload. > I think this is probably what is needed to unblock work on fissix (and thus Bowler), because its Makefile has: python -m pip install -r requirements.txt python -m pip install -r requirements-dev.txt python -m flit install --symlink [snip] Any advise for existing workarounds would be appreciated. So far the only idea I've had is writing or generating a setup.py, and then adding it as a quilt patch. Thanks, Nicholas signature.asc Description: PGP signature
Bug#960767: RFP: python-pressagio -- Pressagio text prediction system
Package: wnpp Severity: wishlist Control: block 721192 by -1 Package name: python-pressagio Version : 0.1.6 Upstream Author : Peter Bouda URL : https://github.com/Poio-NLP/pressagio https://pressagio.readthedocs.io License : Apache-2.0 Programming Lang: Python Description : Pressagio text prediction system Pressagio is a library that predicts text based on n-gram models. For example, you can send a string and the library will return the most likely word completions for the last token in the string. . Pressagio is a pure Python port of the presage library: https://presage.sourceforge.io . Pressagio is part of the Poio project: https://www.poio.eu . [very quickly skimming the source suggests that it requires sqlite, and also that it could benefit from some enhance-user-friendliness work for the initial per-user setup...unless that would fall under the domain of applications that use this library] -- Uberwriter/Apostrophe appears to require this library, and that is the reason for this RFP (or weak ITP). I'm willing to do the packaging work if someone would like to comaintain, and I'd prefer not to be the only person responsible. DPMT is an option, but it's better to [also] have someone who is interested in seeing a specific piece of software succeed :-) Regards, Nicholas
Re: Python Wheel Related Policy Change
Hi, Scott Kitterman writes: > On Thursday, April 30, 2020 5:49:20 PM EDT Stefano Rivera wrote: >> Hi Scott (2020.04.30_20:33:59_+) >> >> > > That seems reasonable, although if we're going down that road, it >> > > probably makes no sense for any of them to be universal. >> > >> > If we were talking about maintaining this for multiple release cycles with >> > lots of version divergence, I would agree. Let's not do more than we have >> > to until python2 is gone (whether it is before bullseye or after). >> >> I suspect pypy (2.7) will probably be around post-bullseye, unless >> somebody funds pypy to migrate rpython to python 3. >> >> But yeah, we can change strategy later, if appropriate. > > Well, we have also talked about pypy vendoring as much of the python2.7 > package as it needs to build itself so we don't have to support it in the > archive as an active interpreter, but that's a different discussion. > I think that discussion must have been before I joined the team :-) It's only recently that I became aware of pypy, and I assumed it had been discounted because it weakened the argument (and/or was bad for morale) for the py2 removal initiative we saw in 2019. I can't remember if it was on reddit or stackoverflow, but apparently people are considering pypy 2.7 as a solution to their py2 technical debt. It makes sense that a vendoring/bootstrapping/dfsg-compliance issue was the reason the avenue wasn't explored in Debian, and I'm happy to hear that this was the reason pypy wasn't explored as an alternative--and not my assumption. Thanks, Nicholas signature.asc Description: PGP signature
Re: Request to join the PAPT (already a member of DPMT)
Stefano Rivera writes: > Hi Nicholas (2020.01.28_00:03:37_+) >> I'd like to join the PAPT, since the PAPT is the best place for an RFP >> that I've chosen to work on. I am already a member of the DPMT, so have >> already accepted Team Policy, and of course have accepted remaining in >> compliance with its changes. > > Added, welcome to the other side of the team. > Thank you Stefano! :-) Regards, Nicholas signature.asc Description: PGP signature
Request to join the PAPT (already a member of DPMT)
Hi, I'd like to join the PAPT, since the PAPT is the best place for an RFP that I've chosen to work on. I am already a member of the DPMT, so have already accepted Team Policy, and of course have accepted remaining in compliance with its changes. My Salsa login is "sten-guest" Regards, Nicholas signature.asc Description: PGP signature
Re: dh_python3 sets shebang to Python 2 -- is this a bug?
Hi, Andreas Henriksson writes: > I've personally seen some upstream use 'python' in shebang with the > intention of meaning 'works with either python2 or python3', Yes, this has worked thus far, and it will definitely work in cases where `which python` is a symlink to python3 within a virtual environment. > but in debian it seems people have always assumed unversioned > (/usr/bin/)python always means python *2*. I don't think this is an assumption. Debian adheres to PEP 394, which until recently said that /usr/bin/python is supposed to be Python 2, for backwards compatibility. When I discovered this I felt increased trust in Debian and its developers for doing the sensible and standardised thing, rather than what some other distributions have done. To everyone involved, thank you! This also made me proud to be part of such a community :-) https://www.python.org/dev/peps/pep-0394/ I believe that it was on 26-Jun-2019 of this year that PEP 394 was modified to allow /usr/bin/python to be py3, because py2 EOL frees up this path. IMHO that change was premature and should have been deferred until the actual EOL. > I guess the tools are written in the latter sense here, rewriting the > shebang from python -> python2 explicitly unless you override it > Yeah, this is a tricky point. Per PEP 394 (until py2 EOL), this is the correct approach, but now it may make more sense to change this to "python -> python3", because if this breaks a package, tough luck, we're in a python3-only world. eg: packages in the archive should already have the shebang override, and NEW py2 packages will be rejected by ftpmasters. Cheers, Nicholas signature.asc Description: PGP signature
Re: python-requests: adding a documentation package python-requests-doc
Hi Fabrice, Fabrice BAUZAC-STEHLY writes: > Hello Daniele, > > Daniele Tricoli writes: > >> Please next time can you assign it to me? I should reveive some sort of >> notification I hope! :) > > Sure, will do. > > I have updated the merge request. > > For d/changelog, I used "debchange -i" which for some reason chose > "2.22.0-2.1", I've changed it to "2.22.0-3" as it seems to better match > the existing practice. > Debchange/dch chooses upstream_version-x.y (NMU Debian revision) when one's email address is in neither the Maintainer nor the Uploaders fields. Dch --team will do the right thing for the Debian revision; that said, the "* Team upload" line it generates shouldn't be used if one of the Uploaders (or Maintainer for weak team attributed package) will be finalising the changelog and uploading. 'no idea whether or not that's the case here, btw. I've filed #947961 against devscripts in the hopes that someone will enhance dch's behaviour for team-maintained packages. > Thanks a lot and a happy new year! > Thank you, happy New Year to you too! :-D Cheers, Nicholas signature.asc Description: PGP signature
Re: Future of Trac in Debian
Hi, Sandro Tosi writes: > Hello everyone, > i'd like to discuss the future of Trac in Debian. as we all know, Trac > is still python2, and while there are plans to port it to python3 > (https://trac.edgewall.org/ticket/12130) that port is not there yet, > and it may take quite some time to reach a state it can be tested, let > alone released. > > What should we do in the meantime? bin:trac has 30 reverse > dependencies (its plugins/addons) and all of them collectively are > likely forceing several other python2 packages to stay in Debian > because they depend on them. > > I know it may sound hard, but is it now time to remove trac from > Debian, and ideally re-introduce it back when it's being ported to > py3k? At that upstream issue gwync writes that he might have to drop Trac in Fedora if there isn't a py3 test release "before Fedora 32 is GA". I'm not sure what "GA" means, but given their release schedule here: https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html and it looks like they'll be dropping py2 on 2020-01-01, and thus Trac. IMHO one of the Debian Trac uploaders should post to the #12130 Trac ticket informing them of our plan. Is there a concrete plan yet? eg: We intend to remove Python 2 from Debian by 31 January, and because we are a conservative and slow moving distribution we are slowly working are way through thousands of application dependency chains to remove applications that do not support Python 3, rather than breaking everything at once by simply removing the interpreter on New Year's Day. If we were not removing packages now we could not meet this objective. . We would like to continue distribute Software-X in Debian, so is there a Python 3 port we can package that is ready for testing today? -- Which is to say, I think the question of "remove now" is contingent on that question. If there is zero hope of a py3 port in a testable state by py2 EOL, then it's ok to drop now, but we need to do more to maintain good relationships with upstreams. Best, Nicholas signature.asc Description: PGP signature
Bug#944989: ITP: python-fissix -- backport of lib2to3, supporting the latest Python3 grammars, with enhancements
Package: wnpp Severity: wishlist Package name: python-fissix Version : 19.2b1 Upstream Author : John Reese URL : https://github.com/jreese/fissix License : PSF Programming Lang: Python Description : backport of lib2to3, supporting the latest Python3 grammars, with enhancements Fissix is a backport of lib2to3, a CST (concrete syntax tree) implementation, that supports various features and grammars that are more up-to-date than the latest upstream CPython version. It is the parser that Bowler uses to make safe, large scale code modifications and smart refactoring. It supports source written in both Python 2 and 3. As noted Fissix is a dependency of Bowler, and I am packaging Bowler because Rope isn't well maintained upstream, because Parso/Jedi do not yet support refactoring, and because Elpy (the Emacs Python IDE) has been hoping to move away from Rope for many years now. I plan to maintain it on the DPMT, I will need a sponsor for the initial upload, and I would very much appreciate a co-maintainer who has advanced Python expertise! Regards, Nicholas
Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack
Brian May writes: > Stéphane Blondon writes: > >> Perhaps there is a doubt how to read it? >> - do not (remove python-foo-doc or rename it to python3-foo-doc) >> - (do not remove python-foo-doc) or (rename it to python3-foo-doc) >> >> Would it be better if we remove the indentation and use this sentence(?): >> if documentation is in python-foo-doc, do not move it > > Myself, I read it as the first option. > > I would personally use: > > - Do not remove python-foo-doc and do not rename it to python3-foo-doc. > > Or maybe even expand as two bullet points: > > - Do not remove python-foo-doc. > - Do not rename it to python3-foo-doc. > > I think this makes it very explicit what was intended. +1. I also read it as (do (not (remove python-foo-doc) or (not (rename to python3-foo-doc. In natural language that "or" should be a "nor", but breaking it into two negated bullet points may be clearer to those whose first language doesn't possess a negative list operator. Cheers, Nicholas signature.asc Description: PGP signature
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
Hi Thomas and Python Team, Thomas Goirand writes: > For example, today I looked into removing Python 2 from python-cogent. > Running sixer on all files lead to a huge log of problems to solve by > hand. There's no upstream support for Python 3 on that one. > > For this kind of package, I see no way out except: > - Upstream works on Python 3 support > - Someone in Debian makes the effort > > But in both cases, it's going to take a very long time. Do we really > want to get stuck on these packages for like forever, or would it feel > ok to raise the severity to serious, so that the package gets > auto-removed and then we can work on removing Python 2 from its > dependencies? It seems to me that a fair and conservative solution is to send an announcement once a month that all Python 2 packages will have an RC bug filed against them on 1 January 2020. I work on the Calibre package, and depend on it for my daily work. I do not believe that its reverse deps should be removed before 1 Jan 2020. As far as the maximum number of announcements, how about: the first announcement ASAP, the second one 1 Nov, then 1 Dec. Lets CC this announcement to devel, -python, -med, and any other teams with a significant number of Python packages. The issue is similar to global warming. People will hide their head in the sand singing "nah nah nah, it's not real, I don't have to deal with it" until a tipping point occurs. Honestly part of me wonders if RedHat/IBM is going to maintain Python 2, like they did with Java. https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support Barring that hypothetical possibility, I still think the right thing to do is file RC bugs the 1 of January. What happens then? My guess is upstreams start containerising their py2 software and someone will write a helper script like py2-zombie-flatpack. Cheers, Nicholas signature.asc Description: PGP signature
Re: pylint and pylint3
Hi Fred, On Tue, Aug 27, 2019 at 07:29:06PM +, PICCA Frederic-Emmanuel wrote: > Hello it seems that the pylint package does not provide pylint3 anymore > (since 21h ;) > But the spyder package still require pylint3 and pylint when installint > spyder or spyder3. > this is why the next taurus will FTBFS. > > So is it something expected and the spyder package should be fixed, or a bug > in the pylint package ? > > Cheers > > Fred ScottK and I discussed this type of case on #debian-python. The Python 3 variant of the package should begin provide the /usr/bin/foo wrapper script interface when the Python 2 package is dropped. This really ought to be codified somewhere, and I'm not sure that the DPMT wiki page is visible enough or will be consulted by maintainers when dropping the Python 2 variant of their packages. Cheers, Nicholas signature.asc Description: PGP signature
Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1
Package: sponsorship-requests Severity: normal Justification: necessary for to update the bpo for Calibre Dear mentors, I am looking for a sponsor for my package "python-css-parser" Package name: python-css-parser Version : 1.0.4-1~bpo9+1 Upstream Author : Christof Hoeke, Walter Doerwald, and Kovid Goyal URL : https://github.com/ebook-utils/css-parser License : LGPL-3+ Section : python It builds these binary packages: python-css-parser - CSS related utilities (parsing, serialization, etc) for Python 2 python3-css-parser - CSS related utilities (parsing, serialization, etc) for Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-css-parser Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-css-parser/python-css-parser_1.0.4-1~bpo9+1.dsc Regards, Nicholas
Re: Re add my account?
Hi Andreas, On Fri, Feb 08, 2019 at 11:52:55AM +0100, Andreas Noteng wrote: >Hello, I am a DM who have not been active for a few years, but I can still >se my name in the list of DMs. Now coming back I see that quite a few >things have changed. Most noteably our packages has moved to GIT it seems. >Looks like I don't have access to this new host. How would I proceed to >gain access and update my long neglected packages? >My alioth username was anoteng-guest >-- >Andreas Noteng I'm a *very* recent member to the team, but: Off the topic of my head, you'll need to check that your unexpired gpg key is still on the DM keyring, register for a salsa account (presumably anoteng-guest), read and accept both https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst and also read & accept relevant pages on the wiki such as https://wiki.debian.org/Python/LibraryStyleGuide#Style_Guide_for_Packaging_Python_Libraries. Then send an email to this list with your salsa account name, the list of your team-maintained packages, mention you confirmed your GPG key is up-to-date on the DM keyring, and say that you read accepted those articles on team standards. Oh, that email is to request that anoteng-guest be added to the salsa team. P.S. Everyone is super busy right now, so I would anticipate a long delay for a reply...but maybe not :-) Cheers, Nicholas signature.asc Description: PGP signature
Re: Update of ipython3 to latest upstream
Hi Christoph, On Fri, Feb 01, 2019 at 06:49:15PM +0100, Jan Christoph Terasa wrote: > Hi, > > the soft freeze of buster is approaching fast, will there be a chance to get > a more recent (latest?) version of upstream ipython3 (https://ipython.org/) > into buster, or at least into sid? ipython3 is still on v5.8, which is the > last one supporting python2. I guess this is since currently both versions > are handled by the same source package, so the adoption of the newest > upstream version needs a redesign of the way ipython2/3 is currently > packaged for Debian? v5.8 is more than one year old by now, and there have > been very useful additions since then. I currently install it via pip3 on my > work systems, but I'd love to get it through the usual Debian packaging. > > If any help is needed on this issue I might see what I can do about this, > but I have never packaged anything for Debian, so I have no experience with > that. > I agree, that would be nice to have! My suspicion is that it's too late for this, because a NEW src:python3-ipython might be considered a large/disruptive change post 12 Jan 2019, but I could be wrong. Here is the output from apt-cache rdepends python3-ipython on sid: Reverse Depends: ipython3 python3-caffe-cuda python3-yt python3-sagenb-export python3-skbio python3-randomize python3-pweave python3-line-profiler python3-fluids python3-pyraf python3-pprofile python3-nbconvert python3-nb2plots python3-jupyter-console python3-itango python3-ipywidgets androguard python3-ipykernel python3-glue python3-caffe-cpu Sorry, I don't have time to make sure the rdeps wouldn't break before the soft freeze. Worst case scenario is that the new ipython3 would be a good candidate for buster-backports. Kind regards, Nicholas signature.asc Description: PGP signature
Bug#920775: RFS: python-css-parser/1.0.4-1 [ITP]
Package: sponsorship-requests Severity: normal Justification: new required dep for Calibre Dear mentors, I am looking for a sponsor for my package "python-css-parser". It will be maintained on the Debian Python Modules Team. I hope that it can clear NEW before 12 Feb, because the Christmas Kobo firmware update requires a newer Calibre, and a newer Calibre requires python-css-parser. Package name: python-css-parser Version : 1.0.4-1 Upstream Author : Kovid Goyal (maintainer of fork), Christof Hoeke (orig) URL : https://github.com/ebook-utils/css-parser License : LGPL-3.0 and Apache 2.0 Section : python It builds these binary packages: python-css-parser - CSS related utilities (parsing, serialization, etc) for Python 2 python3-css-parser - CSS related utilities (parsing, serialization, etc) for Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-css-parser Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-css-parser/python-css-parser_1.0.4-1.dsc Alternatively, clone this repository: git clone https://salsa.debian.org/python-team/modules/python-css-parser.git Thank you, Nicholas
Re: P.S. Requesting to join team and for sponsorship of python-css-parser
On Mon, Jan 28, 2019 at 10:33:09AM +0100, Ondrej Novy wrote: >Hi, >st 16. 1. 2019 v 7:35 odesÃlatel Nicholas D Steeves >napsal: > > > I'd like to finally join the DPMT > >welcome :) Thank you Ondřej! Cheers, Nicholas signature.asc Description: PGP signature
Re: P.S. Requesting to join team and for sponsorship of python-css-parser
On Tue, 15 Jan 2019 at 17:30, Nicholas D Steeves wrote: > > Dear Python team, > > I'd like to finally join the DPMT, and am requesting sponsorship of a > new package. That package is python-css-parser. > > I've been collaborating with Norbert Preining for a year on Calibre, > and Calibre's most recent release requires css-parser, a fork of > css-utils. > > g...@salsa.debian.org:sten-guest/python-css-parser.git > https://salsa.debian.org/sten-guest/python-css-parser > > Please let me know if there's anything I can do to improve it. > > Regards, > Nicholas P.S. I have read and accepted https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst and have also read relevant pages on the wiki such as https://wiki.debian.org/Python/LibraryStyleGuide#Style_Guide_for_Packaging_Python_Libraries I also maintain elpy, an Emacs IDE for Python, and the package would benefit from the insights of more experienced Python developers--particularly with respect to what approach to virtualenvs should be encouraged on Debian systems. signature.asc Description: PGP signature
Requesting to join team and for sponsorship of python-css-parser
Dear Python team, I'd like to finally join the DPMT, and am requesting sponsorship of a new package. That package is python-css-parser. I've been collaborating with Norbert Preining for a year on Calibre, and Calibre's most recent release requires css-parser, a fork of css-utils. g...@salsa.debian.org:sten-guest/python-css-parser.git https://salsa.debian.org/sten-guest/python-css-parser Please let me know if there's anything I can do to improve it. Regards, Nicholas signature.asc Description: PGP signature
Re: Bug#902629: missing required versioned dependency on python-lxml may cause FTBFS
On Fri, Jun 29, 2018 at 06:08:52AM +0900, Norbert Preining wrote: > Hi Nicholas, > > > I've already fixed this in g...@salsa.debian.org:debian/html5-parser.git > > > > If it's possible to fix the FTBR on i386 in sid, then that fix seems > > like it ought to included into the proposed 0.4.4-2 upload. Sadly I > > don't know why it's occurring so can't fix it. > > I am not sure what is the problem on i386, does the current 0.4.4-2 not > build there? It builds for i386, but fails to build reproducibly. It might just be a transient error. https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/html5-parser.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/html5-parser.html However it currently FTBFS for arm64 (maybe transient error, or maybe the cause is elsewhere): https://tests.reproducible-builds.org/debian/unstable/arm64/index_FTBFS.html > Should I upload 0.4.4-2? Upside: will allow the backport to build. Downside: https://tracker.debian.org/pkg/html5-parser states "This package is part of the ongoing testing transition known as python3.7. Please avoid uploads unrelated to this transition, they would likely delay it and require supplementary work from the release managers." Fixing the FTBFS on arm64 would definitely justify an upload, but I'm not sure if my additions and updates are sufficient. CCing the Python Team to find out. Cheers, Nicholas signature.asc Description: PGP signature
Bug#872183: RFP: importmagic -- Python library for finding unresolved symbols and managing imports
Package: wnpp Severity: wishlist * Package name: importmagic Version : 0.1.7 Upstream Author : Alec Thomas * URL : https://github.com/alecthomas/importmagic * License : BSD-2-Clause Programming Lang: Python Description : Python library for finding unresolved symbols and corresponding imports The goal of this package is to be able to automatically manage imports in Python. To that end it can: . * Build an index of all known symbols in all packages. * Find unresolved references in source, and resolve them against the index, effectively automating imports. * Automatically arrange imports according to PEP8. . It was originally written for the Sublime Text 2 Python Import Magic plugin. I became aware of importmagic while investigating the dependencies for Bug#861174. I believe it would be a valuable addition to Debian because it facilitates migration from Sublime Text to a free software IDE. Additionally it sounds like it would be very convenient for Python programmers! Unfortunately I am not qualified to maintain it, and hope that someone on the Python Modules Team would be willing to care care of importmagic. Importmagic should have an "Enhances: elpa-elpy" added at some point after elpa-elpy is uploaded. If replying from debian-python@lists.debian.org please take care to insure this bug is in the recipients list. Sincerely, Nicholas
