Re: Please fix Debian bug 1032091 "py7zr: CVE-2022-44900"
> Debian "py7zr" package has security issue CVE-2022-44900, > and this issue affects Debian "calibre" package because "calibre" depends > this "py7zr" module. > https://tracker.debian.org/pkg/py7zr > > Please examine Debian bug report 1032091, and fix this issue. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032091 > > Debian release system will auto-remove these packages from testing > distribution > on Wed 12 Apr 2023. feel free to provide a patch to fix it. upgrading to newer upstream releases is prohibitive given the increasing amount of additional/frivolous dependencies upstream decided to rely on. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: uploading paramiko 3.0.0
On Mon, Feb 6, 2023 at 5:02 PM Pierre-Elliott Bécue wrote: > > Hans-Christoph Steiner wrote on 06/02/2023 at 22:35:44+0100: > > > paramiko 3.0.0 was released two weeks ago. Any reason to not upload > > it now? It would be nice to get into bookworm. why didnt you ask the maintainers of paramiko for their opinion? > > paramiko is a key package. The hard freeze is in a month. Uploading a > new major release right now could break a lot of things that depend > on it and create a mess right before the freeze. > > In particular, ganeti, which is used a lot by DSA, and ansible which is > used by a lot of people. > > I'd advise against such an upload except if someone makes sure that it > wouldn't break anything sensitive. agreed (which is also a good coincidence since i'd rather spend this little time left to update/fix other pkgs anyway) -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Shouldn't packages maintained by DPT be found in salsa.d.o/python-team ?
On Wed, Jan 18, 2023 at 10:37 AM Andreas Tille wrote: > > Hi, > > when looking at bug #1026525 I intended to checkout mitmproxy thanks, i was about to do the same (due to the implication to uvicorn and the rest of the async packages depending on it) > and realised > > $ apt showsrc mitmproxy | grep -e ^Vcs -e ^Maintainer 2>/dev/null > Maintainer: Debian Python Team > Vcs-Browser: https://salsa.debian.org/debian/mitmproxy > Vcs-Git: https://salsa.debian.org/debian/mitmproxy.git > > I would have expected that the package can be found under > > https://salsa.debian.org/python-team > > Am I missing something? nope, this is a mistake that needs to be fixed if the package is to stay in the team, ie move it to the dpt project in salsa. > Sebastien / Andrej are you aware of this bug which blocks a couple > of Python modules (python-uvicorn, python-scrapy) looks like Seb no longer wishes to work on this package tho: https://salsa.debian.org/debian/mitmproxy/-/commit/350c5a0d304c1c88c531c7b734eb6cd18e77cd00 -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Python 3.11 for bookworm?
thoughts from a concerned maintainer On Wed, Dec 21, 2022 at 1:24 PM Matthias Klose wrote: > > while we have not an 100% agreement to go ahead, I think we should aim for > 3.11. > > The following steps would be: > > - accept the current python3-defaults into > testing (adding 3.11 as supported) > - ask for a transition slot to upload (see #1026825) > python3-defaults with 3.11 as the default > - start the no-change NMUs > - file bug reports. > - fix issues > - let 3.11 as default migrate to testing. > > If things don't go as planned, we could default back to 3.10. Mostly that > would > be no-change uploads, however in the case of a 3.11 specific fix that doesn't > work for 3.10, these fixes would need reverting. I have no idea who many of > these we will introduce with this transition. > > Also we might want to ask for some freeze exceptions for third party > libraries, > that we can't fix before the feature freeze, unfortunately at this point we > cannot say which and how many packages would be affected. from expressions like * "If things don't go as planned" * "no idea who many of these we will introduce with this transition." * "cannot say which and how many packages would be affected" 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] [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. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: bumping python3-multiplex to v0.6 assistance
i just uploaded multiplex_0.6.0-1 it's gonna reach the archive soon
On Mon, Dec 19, 2022 at 5:39 PM Marcel Partap
wrote:
>
> Hi deb-py,
> to simultanously write images of our debian-based live distro
> https://github.com/fsfw-dresden/usb-live-linux to USB pen drives, I've
> managed to create a tool using the multiplex python library requiring version
> 0.6 which is not yet updated in debian. I tried applying the upstream v0.6
> commit onto the repo from salsa but trying to build it, I get an error:
>
> > dpkg-source: error: can't build with source format '3.0 (quilt)': no
> > upstream tarball found at ../multiplex_0.6.0.orig.tar.{bz2,gz,lzma,xz}
>
> Also, is it enough to just replace the existing debian/setup.py with
> following line:
>
> > import setuptools; setuptools.setup()
>
> If anyone could help move this forward, we'd appreciate and there shall be
> bounty.
>
> Best Regards
> Marcel
>
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
Re: on the lack of a `python-` prefix for source packages
> >> My proposal as stated at the top is to start from now on to prepend > >> `python` to all NEW source packages in DPT, with the option to rename > >> existing packages at a later date. > >> > >> What are other team members' opinions on this? > > > > For packages that on contain a python module/extension, I think it's not > > horrible, but I don't see why it's better to diverge from upstream naming. > > I tend to agree with Sandro on for this use case. True, i was mostly referring to modules, as that's the most numerous type of packages we have > > For packages that contain or are primarily applications, I don't think it's > > a good idea. > > Ditto on that one, I don't feel having "python-supysonic" would be a > good naming scheme... please note that would be just for source packages, the user-facing ones can still be `supysonic` as that's what you expect to install On Sun, Dec 11, 2022 at 8:53 PM Scott Kitterman wrote: > What problem are you trying to solve? no problem specifically, i just feel that having a consistent scheme would benefit Debian and then team. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
on the lack of a `python-` prefix for source packages
Proposal: the DPT will start adding a `python-` prefix to NEW source packages names, unless the upstream project already contains it AFAICT all other major languages ecosystems packaging teams use a (semi?)mandatory tag to identify their source packages (results below from a very quick look at Sources, top results only): prefix: golang, rust, r, node, ruby, haskell, php, ocaml, python (on a voluntary basis), and others prefix+suffix: perl At the beginning, I remember being in favor of the current status quo in DPT, where each maintainer can choose to add `python-` if they feel like it, or just use the upstream name. Thru the years, i've grown more uncomfortable with this situation and i think the fact we dont mandate a `python` prefix in the team source packages names (and thus guiding the rest of the python packagers within Debian towards a common style) is detrimental to Debian as a whole, and we should change it. My proposal as stated at the top is to start from now on to prepend `python` to all NEW source packages in DPT, with the option to rename existing packages at a later date. What are other team members' opinions on this? Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Python 3.11, bytecode and new internals
On Mon, Nov 21, 2022 at 12:03 PM Louis-Philippe Véronneau wrote: > > On 2022-11-21 02 h 08, Julian Gilbey wrote: > > I'm just flagging this up here, with a question about how we should > > proceed. Certainly we are not ready to make Python 3.11 the default > > Python version!! > > This is a concern I share and I think I've been pretty vocal about it. > > I feel the state of python packages for Bookworm with 3.10 was pretty > good and it seemed reasonable to prioritize stability for our next > stable release :) > > It's very frustrating to work on packaging python libraries and apps for > a whole release cycle, just to see all that work put in the bin at the > last minute because upstream doesn't support 3.11... this, 100 times > I've been told the current 3.11 transition was a test, and if it was > clear too many important things were broken and couldn't be fixed, we > would roll back and release using 3.10. why are we running a "test" this close to the release? *who* are we running this test for? who made this decision (i figure RT gave the go ahead, but still)? is there any searchable source for this claim? Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Help needed: numpy FTBFS with newer setuptools
> export SETUPTOOLS_USE_DISTUTILS=stdlib > > in debian/rules does make it build for me. Do you consider that a fix? thanks! that worked indeed -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Help needed: numpy FTBFS with newer setuptools
Hello, with the recent upload of setuptools/65.3.0 (and following) in unstable, numpy FTBFS[1]. The reason is that numpy build system (both used internally and by other packages) customizes setuptools/distutils. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020135 Upstream is unwilling[2] to continue patching their build system in response to setuptools changes. While there may be merit in their position, this leaves Debian in a state where numpy is unbuildable, and the freeze is approaching. [2] https://github.com/numpy/numpy/issues/21114 I tried to look at addressing this problem myself, but i had no luck, so i'm here to ask for the help of the wider python team to address this issue. A build log from my machine is available here[3] (error is at the end of the page, as usual). [3] https://paste.debian.net/1259001/ My plan would be, once this is addressed, to package the latest 1.23.4 in experimental, ask for an archive rebuild and later upload 1.23.x to unstable in time for the freeze. This plan is currently on hold due to [1]. Thanks in advance for your help! -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: module mailcap to be removed -- how to replace ?
> Python 3.11 marks "mailcap" for removal in 3.13. The > documentation speaks about "mimetypes" being a replacement, > of sorts. > > However, I can't really see how "mimetypes" helps in > replacing the functionality of "mailcap". > > Put another way: what is the suggested way of replacing that > module in existing code ? The use case is "find the viewer > for any kind of file (mimetype), as long as the system > knows". Given this decision has been made at the upstream python level, you should be asking on their support channel how they plan for current code migration (which is 2 years away). https://www.python.org/about/help/ could be a good start. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
> Well but that's the whole point of automated testing. There's no *need* > to do it locally if it's already done by Salsa for you. What is already > automated and working pretty well is: > > - amd64 build > - i386 build > - source build > - autopkgtest > - blhc > - lintian > - piuparts > - reprotest > - arm64 crossbuild > > That's a pretty time consuming list of things to go through for a human! > > The only work left to be done on your machine is a binary build to see > if the packages look good, perhaps some specific manual testing [1], > source build and upload. Isn't that better? sure its better, now let's assume something in those tests fails: how do you debug it and fix it? you still need to repeat it locally = you wasted time. In conclusion, you're no only proposing a technical change (add CI to all our packages), but also a workflow change (push to salsa before an upload). experience dictates that's never a good idea, and in such an heterogeneous team like ours, it's simply not gonna give the fruits you think it will. I still think it's a waste of time, and addition of emails that we're going to simply ignore (or not receive at all, if you're not subscribed to tracker.d.o, wihch is suspect is the vast majority of team members), but if the majority of the core contributors want it, sure go ahead -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
> Am 20.09.22 um 16:13 schrieb Emanuele Rocca: > > Salsa CI is useful because it automatically performs binary/source builds, > > arm64 crossbuilds, and it runs various pretty important tests such as > > lintian, > > piuparts, reproducible build testing, and more. It also runs autopkgtest in > > LXC. > > quite most of these steps I usually need to do locally before I do any > upload of packages. So I see no real gain to run any pipeline by > default, for me this would be just burning energy in CPU cycles just for > "because we can". exactly this. the vast majority of the team members (based on the commits email i receive) are uploading the package to the archive at the same time as they are pushing a full set of changes to salsa (and sometimes only *after* the package has been ACCEPTED); in this case CI runs too late, and it has 0 benefit for that specific upload. For future ones? maybe, but that's to be proven, and the burden of proof is on the proponent. Someone with upload rights still need to verify (and build!) a package locally, so what would be the advantage of this CI for our packages, given only a very very tiny number of MRs are submitted i could see the benefit for projects that receive external contributions and/or are released out-of-sync with such contributions (say dh-python) but for /packages/, as Carsten said, it's a waste of CPU time to enable CI, IMO -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
On Tue, Sep 20, 2022 at 4:33 AM Emanuele Rocca wrote: > On 19/09 02:14, Sandro Tosi wrote: > > what would the team get out of doing this? > > The way I see it, CI on Salsa is so useful that it should be enabled by > default unless there are good reasons not to. the way i worded my initial question was so that you could list the reasons that make it so useful, in detail: so would you like to do? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
> I was wondering if it would make sense to enable CI/CD on Salsa for all > projects owned by the Debian Python Team, or if there's any concern > about scaling issues in terms of pipeline workers (or anything else > really). what would the team get out of doing this? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Auto-handling of closed bugs - how does it work?
> It's a salsa webhook: > https://wiki.debian.org/Salsa/Doc#Dealing_with_Debian_BTS_from_commit_messages > > We don't have tooling that automatically configures all the repos, but > when we migrated to salsa, we set them all up for tagpending, and > posting to #debian-python-changes on IRC shameless plug, i fixed most of the packages in our repo to have the proper wehbooks using https://github.com/sandrotosi/dpt-repos-check/blob/main/dpt-fix-integrations-webhooks.py (and now automation is available in pypi2deb, when you let it create the repo on salsa) -- consider new packages wont get the right setup old webhooks, etc I should probably run it more periodically -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian
> I wonder whether you are able to reproduce the issue at your side since > in one of your last mails you asked whether the new version might have > fixed the issue. This might implicitly mean it works for you since I > assume you fired up the command line at your side as well. it never worked. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian
> No, the problem persists:
>
> $ py2dsp -v pystow
> D: py2dsp py2dsp:156: version: 3.20220707
> D: py2dsp py2dsp:157: ['/usr/bin/py2dsp', '-v', 'pystow']
> /usr/bin/py2dsp:163: DeprecationWarning: There is no current event loop
> loop = asyncio.get_event_loop()
> D: py2dsp py2dsp:44: args: Namespace(verbose=True, quiet=False,
> root='/tmp/result', clean=False, build=False, application=False,
> profile=None, github=None, distribution='UNRELEASED', revision='0~py2deb',
> message='converte0~py2deb', name='pystow')
> E: py2dsp py2dsp:167: 'releases'
> Traceback (most recent call last):
> File "/usr/bin/py2dsp", line 165, in
> loop.run_until_complete(main(args))
> File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in
> run_until_complete
> return future.result()
> File "/usr/bin/py2dsp", line 74, in main
> fname = yield from download(name, version=version, destdir=args.root)
> File "/usr/share/pypi2deb/pypi2deb/pypi.py", line 124, in download
> release = details['releases'].get(version, {})
> KeyError: 'releases'
this seems to be related to
https://discuss.python.org/t/backwards-incompatible-change-to-pypi-json-api/17154
, although they say /pypi//json (what py2dsp uses to gather
the latest released verison) still contains the releases key, what i
noticed is that endpoint now returns 2 concatenated jsons, and aiohttp
json() (quite understandably) returns the latest one, which does not
contain releases.
appreciate if you can log a bug via reportbug
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian
> Before I've sent my mail I also checked Git HEAD which was no change. there was: https://salsa.debian.org/python-team/tools/pypi2deb/-/commit/f9eda106f1514a1fff83fb3a8324817a91489879 > Are you sure thet the package version 3.20220721 contains the correct > executables? yes, i simply forgot to bump the internal version; what really matters is: does the last release fix the problem you were having? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian
> $ py2dsp -v pystow
> D: py2dsp py2dsp:156: version: 3.20220707
> D: py2dsp py2dsp:157: ['/usr/bin/py2dsp', '-v', 'pystow']
> /usr/bin/py2dsp:163: DeprecationWarning: There is no current event loop
> loop = asyncio.get_event_loop()
> D: py2dsp py2dsp:44: args: Namespace(verbose=True, quiet=False,
> root='/home/andreas/debian-maintain/salsa/python-team/packages/0_prospective/result',
> clean=False, build=False, application=False, profile=None, github=None,
> distribution='UNRELEASED', revision='0~py2deb', message='converte0~py2deb',
> name='pystow')
> E: py2dsp py2dsp:167: 'releases'
> Traceback (most recent call last):
> File "/usr/bin/py2dsp", line 165, in
> loop.run_until_complete(main(args))
> File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in
> run_until_complete
> return future.result()
> File "/usr/bin/py2dsp", line 74, in main
> fname = yield from download(name, version=version, destdir=args.root)
> File "/usr/share/pypi2deb/pypi2deb/pypi.py", line 124, in download
> release = details['releases'].get(version, {})
> KeyError: 'releases'
a fix for this was available in the git repo but not released, i took
care of that with version 3.20220721 that has just been ACCEPTED.
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
Re: List of packages of Python team that have no autopkgtest
On Tue, Jul 19, 2022 at 4:27 AM Thomas Goirand wrote: > > On 7/19/22 07:59, Andreas Tille wrote: > > Hi Zigo, > > > > you asked me for a list of packages without autopkgtest sorted by popcon > > value as we create it for Debian Med team also for Python team. I've > > simply added it to the Debian Med dir for simplicity - feel free to take > > over the code (or suggest some better place). Here ist the list > > > > > > https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/python-team-tests.txt > > > > which is created by the script I'm using for Debian Med and Debian > > Science[1]. It will be refreshed by a daily cron job. > > > > Hope this helps > > It does help a lot. Thanks a lot for this. please be aware there is an almost complete solution (+Antonio in CC) to automatically have autopkgtests based on debian/rules and pybuild setup of tests (same way cli switches/skips/etc during build applied to autpkgtests). So if a package is currently missing autopkgtests i'd refrain from start add them in bulk as they may get it "for free" in the imminent future. regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian
Hello, Piotr has kindly moved pypi2deb to salsa[1] and given me access to the project so i was able to merge my changes and release[2] a new version of this tool in Debian. [1] https://salsa.debian.org/python-team/tools/pypi2deb [2] https://tracker.debian.org/news/1343951/accepted-pypi2deb-320220707-source-into-unstable/ My goal is to make py2dsp (contained in pypi2deb) the default tool used to create Python packages in Debian (like many other language-specific tools already do f.e. for go, rust, npm, etc). The new release contains several enhancements that should cover many of the packaging needs, in particular: * the ability to package directly from a github project url * create the salsa project in the DPT group Please let me know if you think something is missing, or should be expanded/fix, you can also open bugs against the package or directly MR to the salsa project. Should we start advertising this tool in other locations, like the python policy, guidelines, wiki, etc? what do y'all think? Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
archive rebuild for pytest from experimental
Hello Lucas, the Debian Python Team is in the process of updating pytest to a new upstream release. Given the substantial number of packages depending on it, we'd like to leverage the mass rebuild infrastructure to build the reverse dependencies against pytest/7.1.2-1 in experimental. I've opened a MR for adding the new mode at https://salsa.debian.org/lucas/collab-qa-tools/-/merge_requests/22 and you can find attached the package list. Thanks a lot in advance! Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi pytest.pkglist Description: Binary data
Re: Updating pytest
> Sandro: you managed the numpy transition, it seems. What is involved > in something like this? I would imagine something like: > > (1) Upload pytest 7.x to experimental i took care of this just now, uploading pytest/7.1.2 to experimental (and i've messed up the branches on salsa, so i've committed my changes to `experimental2`) > (2) Arrange with Lucas to test build all rdeps against the > experimental version of pytest (by which I mean: all packages which > require python3-pytest as a (recursive) build-dependency) I'll take care of this soon, likely after pytest has been built on a buildd host (so will be either later today EST or tomorrow) > (3) File bugs (with patches where possible) against all packages which > either FTBFS with the experimental pytest or which fail their > autopkgtest suite with the experimental pytest. Presumably these bugs > would have a usertag associated with them so they can be easily > monitored. that's something usually Lucas can automate, but he'll provided a set of failed/successful logs for us to look at. > (4) After an appropriate time period, prepare NMUs for remaining bugs. > > (5) Once all bugs are closed, upload to unstable. > > I could certainly do (1) and help with (3)-(5) if someone else can do > (2) and help with (3)-(5). > > Best wishes, > >Julian -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Updating pytest
> > I think this page includes debci results for experimental: > > > > https://release.debian.org/britney/pseudo-excuses-experimental.html > > > > It shows what would happen when migrating experimental to unstable. > > Oh wow, thanks! That's perfect. So we can upload the new pytest to > experimental and see what happens... please be aware that that is a very partial view, in particular only showing reverse dependencies with (meaningful) autopkgtests, which means there could be hidden gigantic breakages not detected by that page which will wreak havoc in unstable. I would consider pytest a "core" python package, and so a complete rdeps rebuild is appropriate, i suggest having a look at https://salsa.debian.org/lucas/collab-qa-tools/-/blob/master/modes/numpy-exp and then contacting Lucas to get access to the AWS rebuild machinery. > Anyone willing to go for it? I thought you were volunteering for it? :) jokes aside, i think preparing the new pytest upstream release for experimental may be the "easiest" part of this ordeal. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Updating pytest
> I would suggest ratt-rebuilding all reverse dependencies. Could that be > done? there order of thousands rdeps, i dont think it's fair to ask any individual contributor the time and resources to check that via ratt. Something i've done in the past (f.e. with numpy and matplotlib) is leveraging Lucas' archive rebuild infrastructure to run a rebuild the rdeps with a new package, usually uploaded in experimental. I think a service should be provided to developers/maintainers to test their packages against their rdeps, but it's not there yet (i prepared an initial plan for it, but never got to actually implement it). Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: python-catalogue: AttributeError: type object 'EntryPoint' has no attribute '_from_text'
> > I dont think it's a problem per se, but i also want to understand if > > the time debian-python@ dedicates to solve your issues is well spent. > > I'd say it is well spent. > > Andreas is herding a lot of cattle for Debian (as in > packages, or people, or mentees). He's inventor of Debian > Blends, leader of Debian Med, (co-|team-|sole-)maintainer for > a lot of packages (neither of which releases him of due > diligance, though). > > I also know him personally. > > I am sure his way of going about those Python tracebacks > shows, indeed, a lack of Python knowledge, and of time, but > bears neither laziness nor ill will nor entitlement syndrome. I dont necessarily subscribe to the notion that debian-python is essentially a help desk for people too busy to learn python (anyone can always do less, and learn more; quality beats quantity in Debian), but apparently people disagree with me on this, so i'll refrain from bringing this up again. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Should we allow Janitor to commit directly to all DPT packages?
Piotr, Stefano, Bernd, Scott, Ondrey, as owners of the DPT salsa team ( https://salsa.debian.org/groups/python-team/packages/-/group_members?sort=access_level_desc) can you approve (or deny) this request, and so give access to Janitor to directly commit to all our repos, instead of filing MRs? thanks! On Thu, Feb 17, 2022 at 12:39 PM Sandro Tosi wrote: > Hello all, > the question is essentially all in the subject line, and my answer is yes. > > I receive notifications for all MRs opened against DPT packages, and > Janitor's are always pretty much ready to merge as is, and so i think > we should let Janitor commit directly to the team packages. > > Jelmer is in CC (not sure if he's subscribed), in case he wants to > chime in on the implication of this discussion. > > Regards, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: python-catalogue: AttributeError: type object 'EntryPoint' has no attribute '_from_text'
Andreas, > > Any hint would be welcome > > See: https://github.com/explosion/catalogue/issues/27 > > TLDR: skip that test on Python 3.10 for now. this seemed an easy enough issue that, with some common and expected due diligence, you could have figured it out yourself: checking upstream issue tracker and in general google for an error is something i would say any maintainer is expected to do. since it's not the first time you write to this list with a traceback or error, asking for help, and the answer from here is generally pretty straight-forward, i'm wondering why you were not able to find the solution directly? some of your previous emails are really python 101 questions. If it's because you have too many things on your plate, it's one thing, if it's python knowledge is another, but it seems a pattern that only you engage in. I dont think it's a problem per se, but i also want to understand if the time debian-python@ dedicates to solve your issues is well spent. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: I want to join the DPT
> Sorry again. I recheck the #1007025 [0], it should be RFP tag. > This is my misspelt in the first request email. > So I think I can go to to work it :-) OMG you're right! i guess morning coffee hadnt kicked in when first replying. I would still contact anarcat before starting any work, because they may already have started the packaging effort and you two can collaborate. It's also possible nothing was done and so you can start from scratch. if you need help, you can let this mailing list know, or if you're comfortable using IRC, you can ask questions in #debian-python on the OFTC network Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: I want to join the DPT
> >> My salsa account is vimerbf(but I do not know why it hint me > >> @vimerbf-guest) > >> > >> I have read the document: [1] and understand and follow it. > > > >according to > >https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team > >you need to clarly state that you are accepting the policy, and that > >statement is missing in your email. > I have read the policy [0] and accept it. > Is that OK? And you said "missing my email", How to add it? you just did with the line above :) > >> If there are any question please let me know. > > > >it looks like you may want to spend a bit more time gettingused to how > >to collaborate in debian, and on our procedures: 2 simple and well > >documented activities (ITP and joining this team) were not fully > >grasped by you at the time you wrote this email. > > > >We are happy to welcome you when ready to join and in the meantime > >help if you need further clarifications, but there may be other forums > >better suited to novices. > Yeah, The first time to join DPT is fail and I have to spend more time > to collaborate with Debian. But this is not change my mind to contribute > Debian as a ~8 year user. i wouldnt consider this a failure, part of welcoming new contributors is also telling them if they need to understand some procedures better, and so be more effective. And by no mean my reply was meant to discourage you from contributing to Debian, and i see you're still determined to do so, which is great! Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: I want to join the DPT
Hello Bo, > My name is Bo, and want to contribute to Debian. And I > noticed the ITP[0] and want to help package it. Because > python is my one of favorite program language also :-) an ITP means someone else is already working on that package, so that may not be the right first package for you. did you reach out to the person that opened that bug report? You may also want to look into getting more knowledgeable on how debian development works > My salsa account is vimerbf(but I do not know why it hint me @vimerbf-guest) > > I have read the document: [1] and understand and follow it. according to https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team you need to clarly state that you are accepting the policy, and that statement is missing in your email. > If there are any question please let me know. it looks like you may want to spend a bit more time gettingused to how to collaborate in debian, and on our procedures: 2 simple and well documented activities (ITP and joining this team) were not fully grasped by you at the time you wrote this email. We are happy to welcome you when ready to join and in the meantime help if you need further clarifications, but there may be other forums better suited to novices. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Bug#1006663: ITP: python-pyrcb2 -- A powerful asynchronous IRC bot library
> I need it to properly package an IRC bot designed for the > DPT itself. please share your ideas for such bot here, before installing it the irc channels, thanks -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Salsa python-team write access for tiledb-py ?
> I however do not have enough powers to add you into > the team. that's good, because we have a procedure in place that perspective team members need to follow to join the team: https://wiki.debian.org/Teams/PythonTeam/HowToJoin and https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team -- Dirk, if you're interested, please follow that guide Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Should we allow Janitor to commit directly to all DPT packages?
> I admit I'm hesitating a bit for different reasons. While I agree that > direct commits are better than MRs I found several DPT packages with > very sensible changes in Git but no uploads following these. For > instance fixing VCS fields and Maintainer name should be followed by an > according upload to make those changes visible to users and developers > of the *packages* in Debian. > > In the Debian Med team for instance we do those automatic changes before > uploading a package - say when upgrading to new upstream versions or > fixing some bugs. Than we run the Janitor scripts and other automatic > changes which is all done in routine-update. I personally find this > workflow more convenient. That way Debian Med team (as well as pkg-r > team) are blacklisted for Janitor to not have competing changes inside > the package. thanks for bringing the perspective of how things are done in the Med team, but it feels none of the points you mentioned nor the specific Med team workflow apply here, or are relevant to just let Janitor commit directly to our packages. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Should we allow Janitor to commit directly to all DPT packages?
Hello all, the question is essentially all in the subject line, and my answer is yes. I receive notifications for all MRs opened against DPT packages, and Janitor's are always pretty much ready to merge as is, and so i think we should let Janitor commit directly to the team packages. Jelmer is in CC (not sure if he's subscribed), in case he wants to chime in on the implication of this discussion. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Bug#1005043: lintian: check that Python version numbers are not 0.0.0
> Or export SETUPTOOLS_SCM_PRETEND_VERSION. > https://github.com/pypa/setuptools_scm#environment-variables > > pybuild does this for you. i dont remember the exact details, but sometimes that doesnt work: even just building the source package (which runs dh clean, which invokes setup.py clean) the build fails because "something something SCM something". It could be the specific package is doing things in a funky way but that's my experience at least -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Please make a separate package for mistune 2.x
> I'd like other python team member's opinion on this, and I'm not eager > to maintain that legacy package, as I tend to not want to maintain > obsolete software. Still, I can do the initial work of creating it. i wouldnt expect much maintenance needed tho: 0.8.4 is essentially dead upstream, so it will only need to be kept around until its rdeps are ported to mistune 2.x the proposal is "okay", it has the downside of requiring the current rdeps to be updated to point to the new binary package name for the old mistune, but it leaves the namespace open for mistune 2 to take over python3-mistune bin pkg -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian
> I think the proper fix would be to ask people to move away from > `py3versions -r` if there is no X-Python3-Version, and use`py3versions > -s` instead. > > As such, I think we should ask the Lintian maintainers to: > > 1. Change the desc for tag declare-requested-python-versions-for-test to > > The specified test attempts to query the Python versions > requested by your sources with the command py3versions > --requested but your sources do not actually declare those > versions with the field X-Python3-Version. > . > Please query all supported Python versions with the command > py3versions --supported in your test instead. > > 2. Change the desc for tag query-requested-python-versions-in-test to > > The specified test queries all supported Python versions with > the command py3versions --supported but your sources > request a specific set of versions via the field > X-Python3-Version. > . > Please delete the field X-Python3-Version, as it is not needed. +1 > AFAIU, the only valid use of X-Python3-Version would be a package that > fails to build on an older but currently supported version of Python > (let's say 3.9) but builds on the newer version (say 3.10). I think such > use cases are pretty rare though. maybe https://www.debian.org/doc/packaging-manuals/python-policy/#specifying-supported-versions would need to be updated to clarify that the optional field is meant to be used in exceptional circumstances (and state what they are explicitly) and we generally expect the field to be absent. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Cleaning up the Salsa DPT landing page
> If they apt source their debian/control > will have the obsolete Vcs-Browser information. I think there should at least > be a tombstone there for them to understand where the team went. since we moved these repos within salsa, they are actually being redirected to the right repo location. I took a random package that still uses the all address: https://salsa.debian.org/python-team/modules/webpy and if i browse it, i get redirected to https://salsa.debian.org/python-team/packages/webpy with a window stating: Project 'python-team/modules/webpy' was moved to 'python-team/packages/webpy'. Please update any links and bookmarks that may still have the old path. so it looks like even if downstreams have the old url, it will be redirected to the right place and modules|apps can be removed -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Update packages to recent version
> I intend to package paperless-ng. > > Many of its dependencies are packaged in Debian but in an older version. > You can see the list at > https://salsa.debian.org/mechtilde/paperless-ng/-/wikis/home how did you come up with the list of packages that require updates? i just checked one, uvicorn, and upstream requires 0.15.0 https://github.com/jonaswinkler/paperless-ng/blob/master/requirements.txt#L95 which is already in the archive, and still it's in your list of packages that needs to be updated. are you sure that list is accurate? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Transfering packages from Debian Med to DPT (Was: Please enable me transfering python-bioblend to Debian Med team)
> > > Sandro, do you have any other packages in mind? > > > > too many to scan by-eyes only, so i planned on running some queries on > > UDD to figure some other package out, but the udd-mirror is down, so > > i'm going to provide a list (if any) later on. > > In general we are open to hand over general packages that are not > directly touching the medical / biological field to competent hands. So > just ping me and I'll try to respond as quick as possible. with UDD-mirror U now, i was able to generate the below list. This is in no way a request to move them, just a potential source of data for your consideration arcp 0.2.1-3 python3-arcp : (Archive and Package) URI parser and generator enlighten 1.7.2-1 python3-enlighten : console progress bar module for Python3 python3-enlighten-doc : console progress bar module for Python3 (documentation) python3-enlighten-examples : console progress bar module for Python3 (examples) h5sparse 0.1.0-4 python3-h5sparse : Scipy sparse matrix in HDF5 indexed-gzip 1.6.4-1 python3-indexed-gzip : fast random access of gzip files in Python pyrle 0.0.33-2 python3-pyrle : run length arithmetic in Python python-anndata 0.7.8-2 python3-anndata : annotated gene by sample numpy matrix python-avro 1.10.2+dfsg-1 python3-avro : Apache Avro serialization system (Python 3 library) python-ciso8601 2.2.0-1 python3-ciso8601 : fast ISO8601 date time parser for Python written in C python-colormap 1.0.4-2 python3-colormap : ease manipulation of matplotlib colormaps and color codecs (Python 3) python-colormath 3.0.0-1.1 python3-colormath : Abstracts common color math operations (Python 3 version) python-cooler 0.8.11-1 python3-cooler : library for a sparse, compressed, binary persistent storage python3-cooler-examples : library for a sparse, compressed, binary persistent storage (examples) python-depinfo 1.7.0-1 python3-depinfo : retrieve and print Python 3 package dependencies python-duckpy 3.2.0-2 python3-duckpy : simple Python library for searching on DuckDuckGo python-easydev 0.12.0+dfsg-1 python3-easydev : common utilities to ease the development of Python packages (Python 3) python-etelemetry 0.2.0-4 python3-etelemetry : lightweight Python3 client to communicate with the etelemetry server python-fitbit 0.3.1-2 python-fitbit-doc : FitBit REST API Client Implementation - Documentation python3-fitbit : FitBit REST API Client Implementation - Python 3 python-hdmedians 0.14.2-3 python3-hdmedians : high-dimensional medians in Python3 python-leidenalg 0.8.8-1 python3-leidenalg : Python3 implementation of the Leiden algorithm in C++ python-lzstring 1.0.4-1.1 python3-lzstring : LZ-based compression algorithm for Python (Python 3 version) python-matplotlib-venn 0.11.6-2 python3-matplotlib-venn : Python 3 plotting area-proportional two- and three-way Venn diagrams python-multipletau 0.3.3+ds-3 python-multipletau-doc : documentation for multipletau Python module python3-multipletau : multiple-tau algorithm for Python3/NumPy python-multisplitby 0.0.1-4 python3-multisplitby : Python3 module to create iterables split on arbitrary separators python-ncls 0.0.63+ds-1 python3-ncls : datastructure for interval overlap queries python-pipdeptree 2.2.0-2 python3-pipdeptree : display dependency tree of the installed Python 3 packages python-pyflow 1.1.20-3 python3-pyflow : lightweight parallel task engine for Python python-pynndescent 0.5.2+dfsg-1 python3-pynndescent : nearest neighbor descent for approximate nearest neighbors python-pypubsub 4.0.3-5 python3-pubsub : Python 3 publish-subcribe library python-sinfo 0.3.1-2 python3-sinfo : print different version information for loaded modules python-spectra 0.0.11-3 python3-spectra : Easy color scales and color conversion for Python (Python 3 version) python-stdlib-list 0.8.0-4 python3-stdlib-list : List of Python Standard Libraries (2.6-7, 3.2-9) python-streamz 0.6.3-1 python3-streamz : build pipelines to manage continuous streams of data python-stubserver 1.1-2 python3-stubserver : mock tester of external web dependencies for Python python-tinyalign 0.2-5 python3-tinyalign : numerical representation of differences between strings python-typechecks 0.1.0+ds-2 python3-typechecks : express constraints on types python-upsetplot 0.6.0-2 python3-upsetplot : Draw Lex et al.'s UpSet plots with Pandas and Matplotlib python-wdlparse 0.1.0-2 python3-wdlparse : Workflow Description Language (WDL) parser for Python python-wordcloud 1.8.1+dfsg-2 python3-wordcloud : little word cloud generator in Python python-xopen 1.2.1-3 python3-xopen : Python3 module to open compressed files transparently smart-open 5.2.1-3 python3-smart-open : utils for streaming large files sorted-nearest 0.0.31+dfsg-1 python3-sorted-nearest : Cython helper library for pyranges sphinxcontrib-autoprogram 0.1.7-1
Re: Transfering packages from Debian Med to DPT (Was: Please enable me transfering python-bioblend to Debian Med team)
> Thus I moved mypy now and moved it to DPT[2]. Feel free to add yourself > to Uploaders and upload with the new location. thanks! > Sandro, do you have any other packages in mind? too many to scan by-eyes only, so i planned on running some queries on UDD to figure some other package out, but the udd-mirror is down, so i'm going to provide a list (if any) later on. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Please enable me transfering python-bioblend to Debian Med team
Andreas, On Wed, Dec 22, 2021 at 1:42 PM Andreas Tille wrote: > > Am Wed, Dec 22, 2021 at 06:13:32PM +0100 schrieb Pierre-Elliott Bécue: > > > > Andreas Tille wrote on 21/12/2021 at 15:43:11+0100: > > > > > Ping? Could any admin of Debian Python Team help out? We can simply > > > recreate the repository in Debian Med and move on ... but that might > > > be confusing for users who will find two clones in differen teams. > > > Thank you, Andreas. > > > > I'm sorry but pressuring to take over a package is not really fine. If > > you're not happy with the time it takes for an answer, you can try to > > fill an ITS and if the procedure goes to its end then you may take over. > > Please note: The people involved are the same. We are members of > both teams but consider the Debian Med team more appropriate. We > are simply missing the permissions to do the move properly. since you're talking about the appropriate team to maintain a given package (and it seems debian-med may be more suited for bioblend), are you also going to move all non-bio/med python packages from debian-med to dpt? because that's the more appropriate place for things like mypy. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: DPT repositories checks/"violations" report
> I'm in the process of writing a tool to uniform the repo configuration > in python-team/package > > - add integration: Emails on push > - remove integration Irker > - add webhook: KGB (or edit to remove all the extra parameters set, > which are the default values anyway) > - add webhook: tagpending the tool is now ready: https://github.com/sandrotosi/dpt-repos-check/blob/main/dpt-fix-integrations-webhooks.py > I'll write back here when i think it's ready for review and request > authorization to run it. can any admin check if the changes look sane (i've run a test run on ~25 repos) and that i'm allowed to run this across the whole `packages` subgroup on salsa? > I think there's still one point we need to figure out: how to make > these remarks known to the packages maintainers, instead of all of > them just being in a text file. This is still an open point, and i welcome ideas Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: DPT repositories checks/"violations" report
> When we did the migration to git, there weren't good tools for managing > the setup of the salsa repos (hooks, etc.) yet. I'd assume those exist > now, we should check in with what other teams are doing. That stuff can > all be fixed in one run of a tool, I'd assume. yeah i figured that much, and that made sense at that time. I modified [1] to automatically create the salsa repo enabling both KGB and tagpending webhooks, but the `salsa` tool doesnt support setting integrations, so that will need to be fixed later on. [1] https://github.com/sandrotosi/pypi2deb/tree/morph I'm in the process of writing a tool to uniform the repo configuration in python-team/package - add integration: Emails on push - remove integration Irker - add webhook: KGB (or edit to remove all the extra parameters set, which are the default values anyway) - add webhook: tagpending I'll write back here when i think it's ready for review and request authorization to run it. I think there's still one point we need to figure out: how to make these remarks known to the packages maintainers, instead of all of them just being in a text file. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: sphinxext-opengraph build with tests.
Hello Chiara, > I have committed to salsa a new version of sphinxext-opengraph running tests > at the build time. > There are no updates on upstream. > > It's not urgent, but if someone want to check my solution (as this is my > first using autopkgtest)... i dont think that's how you should run autopkgtests: they are supposed to run against the installed package (the way you set them up is essentially equivalent to how they run during build). For an example of what that means, you can have a look at (shameless plug): https://salsa.debian.org/python-team/packages/httpx/-/tree/debian/master/debian/tests > Also, Sandro do you mind letting me know if this is worth a new package > version 0.5.0-2? I will update changelog accordingly if needed. it is my opinion that every time you make a change to a package, you should also add a relevant entry in debian/changelog, describing what the change is, and the updated d/changelog should be included in the same commit introducing the change (as oppose to write debian/changelog all at once before an upload). With that said, yes a -2 would be nice, and once autopkgtest is fixed i think it would appropriate to upload the package, without waiting for a new upstream release. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Request to join the team
Hello Yago, > I am the current maintainer of python-tabulate [1], and would like to > join the team as I believe it makes more sense for the package to be > under its roof. The goal is to prevent issues should I be unavailable > in the future, but I will try continue maintaining it within the team > for now. you only maintain this package, you have not uploaded it in more than 3.5 years, and that package received 3 NMUs in the last 2 years; how can you reassure that you're going to actually take care of this package moving it to DPT, instead of letting the team essentially maintain it? Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
DPT repositories checks/"violations" report
Hello, while working on something else[1], i noticed how many of the repositories in the DPT salsa group are in poor shape: * missing branches * changes not pushed to salsa * general misalignment in configuration/setup/organization * many other small nuances [1] https://github.com/sandrotosi/debian-python-team-tracker That makes it hard to make mass work as in [1], so I thought it would be interesting to have a tool to evaluate the amount of issues our repos have, and identify such "violations" so that they can be addressed. That information is now available at [2]. [2] https://github.com/sandrotosi/dpt-repos-check/blob/main/violations.txt please take the content with caution, as it's still an early, raw draft (i spot-checked some of the reported issues, but there could be bugs/issues) and it contains data that can be outdated (see below re caching); the fact that the report indicates only 43 repos are without violations is a bit disarming, but i think the tool tries to err on the side of verbosity and pedantry, with 2 level of violations (ERROR and WARNING) to mark which ones are the most important that require immediate attention vs the nice-to-have ones. The checks are under-documented, although they should be somehow self-explanatory. While the current format is just a text file, I plan on getting it converted to markdown, although I'm still not sure how to convey that amount of information effectively. The report is extremely intensive to generate, as it needs to make 10+ API calls to salsa.d.o for each repository, and it gets throttled quite early in the run (i got away in dev by installing a cache, so that i could test it without hitting salsa every time, but that makes some info stale); for that reason, and if we decide is valuable to generate it periodically, i don't expect to be able to run it more than once a month (maybe once a week? TBD). Comments, critics and improvements are welcome. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: sphinxext-opengraph_0.4.2-1_amd64.changes ACCEPTED into unstable, unstable
On Tue, Nov 23, 2021 at 10:40 PM Chiara Marmo wrote: > > Dear Sandro, > > thank you very much for your answer and your sponsoring. > >> If you want it to be sponsored, >> please add a new entry to debian/changelog with a "source only >> upload"-like text, set the suite to `unstable` (so not UNRELEAED as >> it's usually created by default), commit and git push and let this >> list know (or you can reach out to me privately, that's fine too). > > > Done. > >> The sponsor usually takes care of git tagging and uploading to the archive. > > > I have untagged. please note you removed a valid tag, which was for version 0.4.2-1 (the one that just got accepted from NEW), I've restored it. since you never tagged the new -2 (because there was no new entry in the changelog at that time) there was no tag to be removed. Anyway, i've uploaded 0.4.2-2 to unstable, thanks for your contribution to Debian! There's also a new upstream release, 0.5.0, which would be nice for you to package Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: sphinxext-opengraph_0.4.2-1_amd64.changes ACCEPTED into unstable, unstable
i can sponsor this package, but... > The package is tagged and ready for upload at > https://salsa.debian.org/python-team/packages/sphinxext-opengraph ... that doesnt appear to be the case. If you want it to be sponsored, please add a new entry to debian/changelog with a "source only upload"-like text, set the suite to `unstable` (so not UNRELEAED as it's usually created by default), commit and git push and let this list know (or you can reach out to me privately, that's fine too). The sponsor usually takes care of git tagging and uploading to the archive. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Status of python-charset-normalizer in Debian
On Sun, Nov 14, 2021 at 8:52 PM Stefano Rivera wrote: > > Hi Sandro (2021.11.15_01:05:12_+) > > > I filed https://github.com/Ousret/charset_normalizer/issues/138 > > > upstream. > > > > In the interest of moving things along, and while we wait for upstream > > action on it, should we Files-Excluded: data/ , re-import the upstream > > tarball, and disable tests/test_cli.py and > > tests/test_full_detection.py (which appear to be the only 2 test files > > using the data directory)? > > +1 to that. the conversation continued on #debian-ftp, where we came to the understanding the REJECT was due to a misunderstanding of how some Licenses information were reported, so i've just reuploaded python-charset-normalizer as-is from the git repository Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Status of python-charset-normalizer in Debian
> FWIW: $ grep charset-normalizer /srv/ftp-master.debian.org/log/2021-11 > 20211106022017|clean-queues|dak|move file to > morgue|Incoming/REJECT|python-charset-normalizer_2.0.6-1_amd64.changes|/srv/ftp-master.debian.org/morgue/queues/2021/11/06 oh, didnt know we could search for that, thanks > So, looks like it got a reject. > My guess would be due to data/sample* > > I filed https://github.com/Ousret/charset_normalizer/issues/138 > upstream. In the interest of moving things along, and while we wait for upstream action on it, should we Files-Excluded: data/ , re-import the upstream tarball, and disable tests/test_cli.py and tests/test_full_detection.py (which appear to be the only 2 test files using the data directory)? Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Status of python-charset-normalizer in Debian
Hello Dominik, can you update the DPT on the status of python-charset-normalizer? it used to be in NEW, but now i cant find it there and it's not in the archive. This package is needed at least by httpx, which cannot be upgraded to its latest version, thus preventing a growing set of packages to be upgraded, many of them becoming RC and in danger of being removed from testing. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Question on installing packages via the Python APT library
python-apt is not written nor maintained by this team, but rather (from https://tracker.debian.org/pkg/python-apt) by the APT Dev team and in particular by Julian Andres Klode (both in CC): please continue the discussion with them On Sun, Nov 7, 2021 at 6:21 PM Hunter Wittenborn wrote: > > Hi! I'm currently working on a project that's going to be using the Python > APT library to handle some package installation, but I've got a question on > how exactly a certain thing is working: > > I've gotten everything up to the actual installation of packages done (up to > the point of calling 'DepCache.commit()', but once I get to the 'commit()' > stage I can't figure out how to control the output of the 'commit()' call in > a way I'm wanting. > > Going with the two classes that are specified for the 'commit()' function, I > currently have the following implemented (I haven't exactly figured out what > to put in each one yet, as I'm still trying to figure out all how this step > works): > > acquire_progress: > https://gist.github.com/hwittenborn/56fa689b86396a904155e4b1b5be817a > install_progress: > https://gist.github.com/hwittenborn/0eb762abdfeb96e2c1cbf4f5b6a975f3 > > The 'tap.message' library being used inside both of those classes is just a > message system for my program, they don't do anything particularly important > that would affect anything at all. > > The acquire_progress stage *appears* to be working fine, though the packages > I downloaded were quite small so I didn't really get a chance to see if it > just did some weird stuff like with install progress; > > The problem with install_progress is that it's exiting my program, and then > proceeding with installing packages, as if it starts installing packages in > the background. How exactly should I go about waiting for it to finish though? > > On a side note, I'm seeing this text whenever it (presumably) gets to the > install part: > > """ > custom fork found > got pid: 31873 > got pid: 0 > got fd: 4 > """ > > Is there any way I can hide that? I'm thinking it's from the 'fork()' call in > the install_progress class, but the Python APT documentation is recommending > not changing that [1], so I wasn't really sure. > > [1]: > https://apt-team.pages.debian.net/python-apt/library/apt.progress.base.html#apt.progress.base.InstallProgress.fork > > Thanks, anything helps! > > --- > Hunter Wittenborn > hun...@hunterwittenborn.com > https://github.com/hwittenborn > > > > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Build an initial Debian source package with py2dsp from a GitHub project
couple of features recently introduced that may interest people: - rudimental support for autopkgtests: autodep8 + a stub for developers to setup autopkgstests for unittests - salsa repo creation, if SALSA_TOKEN is available in ~/.devscripts; this also setup the KGB webhook to post in #d-p-changes I'm definitely no expert in autopkgtests, so if there's something to improve, lemme know. On Sun, Apr 25, 2021 at 12:22 AM Sandro Tosi wrote: > > Hello, > recently i've been making some enhancements to py2dsp (part of > pypi2deb[1] ); for those who dont know what that is, py2dsp is a tool > that, given a PyPI project, will create an (initial) Debian source > package. > > [1] https://packages.qa.debian.org/p/pypi2deb.html > > I've just finished a patch that extend py2dsp to fetch the upstream > tarball from GitHub instead; nowadays this is my preferred source for > upstream tarballs, given it contains all the project files (not only > the one published on pypi via sdist, often missing important files > like tests, or doc sources, etc). > > it's currently available at the git branch at [2] (there's a PR open at [3]): > > [2] https://github.com/sandrotosi/pypi2deb/tree/morph > [3] https://github.com/p1otr/pypi2deb/pull/27 > > once you cloned/checkout that branch, you can run: > > $ ./py2dsp --profile dpt --distribution unstable --revision 1 --github > https://github.com/USER/PROJECT > > alternatively, you can specify an additional argument ``, > if PROJECT is not the source name you want to use in Debian: > > $ ./py2dsp --profile dpt --distribution unstable --revision 1 --github > https://github.com/USER/PROJECT > > and it will create the source package in the `result/` directory. > > Let me know if you find this useful and if there are > issues/enhancement you'd like to see added/fixed. > > Regards, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: python-anyio not building?
> I don't get why python-anyio is stuck ; I certainly didn't upload it > without trying to build it, and I just tried again and there was no > issue : > https://buildd.debian.org/status/package.php?p=python-anyio > > Does someone have a clue what is happening? it's marked as installed now, which means it was built properly (i think tracker/pts will take some time to reflect that in the excuses block) -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: request to join python-team/packages group on salsa
> I sometimes need to add or make updates to python packages. Currently, I > just uploaded a newer upstream version of httpbin and I'd like to push > the changes to the git repository, which resides in python-team/packages. httpbin has been orphaned, so it appears as if this repo should be moved from the python-team to the debian namespace (only admins can do that). please let us know if you still want to join the team. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group
> That's an upstream bug then, and upstream should fix that and ship a complete > source tarball. > > I always submit pull requests updating MANIFEST.in and until now, all > upstreams have accepted them. and that will require an upstream new release, which does not help when you want/need to package the current one. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group
> One note: I'd consider watching for PyPI instead of GitHub. there was actually a recent discussion on this list, discouraging from using PyPI in favor of github, since GH tarball usually contains docs, tests, and other files useful when building from source, usually not included in tarball released to users, ie pypi -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Potential issue with numpy
Please do report bugs in the BTS when there's a problem with a package On Wed, Sep 29, 2021 at 10:32 AM Andreas Tille wrote: > > Hi, > > in the issue I filed against nipype I was asked to try to rebuild numpy > and see whether this might make a diffence. So I tried > > dget http://deb.debian.org/debian/pool/main/n/numpy/numpy_1.19.5-1.dsc > cd numpy-1.19.5 > > and have rebuild it in a recent pbuilder environment. This ends up in > > DISTUTILS.rst.txt:386: WARNING: Unparseable C cross-reference: '/**end > repeat1**/' > Invalid C declaration: Expected identifier in nested name. [error at 0] > /**end repeat1**/ > ^ > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 280, in > build_main > app.build(args.force_all, filenames) > File "/usr/lib/python3/dist-packages/sphinx/application.py", line 337, in > build > self.builder.build_update() > File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line > 293, in build_update > self.build(to_build, > File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line > 357, in build > self.write(docnames, list(updated_docnames), method) > File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line > 531, in write > self._write_serial(sorted(docnames)) > File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line > 541, in _write_serial > self.write_doc(docname, doctree) > File "/usr/lib/python3/dist-packages/sphinx/builders/html/__init__.py", > line 626, in write_doc > self.docwriter.write(doctree, destination) > File "/usr/lib/python3/dist-packages/docutils/writers/__init__.py", line > 78, in write > self.translate() > File "/usr/lib/python3/dist-packages/sphinx/writers/html.py", line 70, in > translate > self.document.walkabout(visitor) > File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in > walkabout > if child.walkabout(visitor): > File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in > walkabout > if child.walkabout(visitor): > File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in > walkabout > if child.walkabout(visitor): > [Previous line repeated 1 more time] > File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 206, in > walkabout > visitor.dispatch_visit(self) > File "/usr/lib/python3/dist-packages/sphinx/util/docutils.py", line 477, in > dispatch_visit > method(node) > File "/usr/lib/python3/dist-packages/sphinx/writers/html5.py", line 417, in > visit_literal_block > highlighted = self.highlighter.highlight_block( > File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 149, in > highlight_block > lexer = self.get_lexer(source, lang, opts, force, location) > File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 127, in > get_lexer > lexer = lexer_classes[lang](**opts) > TypeError: 'NumPyLexer' object is not callable there's a new sphinx version in unstable (4.2.0), likely other pieces of the infrastructure around numpy and its doc need updating. The fact we dont have access to the build log makes it hard to pin point the issue. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: RFS: still looking for sponsor for new version of sentry-python (#990519)
Hello Eberhard, On Tue, Sep 28, 2021 at 12:10 PM Eberhard Beilharz wrote: > > Hi, > > I'm still looking for someone who'd be able and willing to upload the > new version of sentry-python (1.4.2). did you contact the current maintainer about this? Adding William to the recipients list > The version currently available in > Debian (0.13.2) is not compatible with the latest version of the Sentry > server and thus breaks any software that depends on the 1.x version. > > Or what is missing that prevents someone from moving this forward? > > Thanks, > Eberhard > > > https://mentors.debian.net/package/sentry-python/ > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990519 This package repository is hosted on the Debian Python Team salsa group, at https://salsa.debian.org/python-team/packages/sentry-python while you're proposing an upload outside of this setup via Mentors. It's usually inappropriate to seek outside sponsors for team-maintained packages, because that tends to leave the canonical git repo outdated, forcing people to do extra work to reconcile history. Please submit a MR for the upstream, pristine-tar, and master branches (one MR for each branch) with your changes on salsa, and we can review them. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
On Tue, Sep 21, 2021 at 5:00 PM Antonio Terceiro wrote: > > On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote: > > > That's because gbp does not use pristine-tar by default, and > > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to > > > fix that. > > > > I dont think this is the right approach: the default options to work > > on DPT packages should be in gbp default config file (or in another, > > global, config file), and not live in each and every package > > debian/gbp.conf file; it is already inconsistently maintained with > > several packages having uncommon settings that will take precedence > > over the default ones. > > I agree with you in theory; my global gbp.cons enables pristine-tar. > > However, having it duplicated in every package means we as a team work > consistently regardless of people's global configuration, not at all, right now we dont have a *consistent* debian/gbp.conf in each package, everyone writes their own and it's currently a mess. what when we decide to add a new option, or change the value of an existing one? DPT currently has ~2500 packages: how do you maintain consistency in all of them? > and that's one > less detail people need to get just right to be able to contribute > effectively. > > Also, one's global configuration might not apply to all the packages > they contribute to; it's easier for everyone if gbp just does the > right thing based on per-package configuration than expecting people to > remember to switch their defaults, or to pass options explicitly. please refer to https://lists.debian.org/debian-python/2021/09/msg00065.html for how i see this being implemented. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
On Mon, Sep 20, 2021 at 11:21 AM Andrey Rahmatullin wrote: > On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote: > > > That's because gbp does not use pristine-tar by default, and > > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to > > > fix that. > > I dont think this is the right approach: the default options to work > > on DPT packages should be in gbp default config file (or in another, > > global, config file), and not live in each and every package > > debian/gbp.conf file; > What's the mechanism to put these options there for everyone who works on > a DPT package? that's a great question! i dont think a technical solution currently exists. > Or do you mean just working with whatever is shipped with > gbp? that wont work, but there could be a solution if we request a new feature in gbp. According to man 5 gbp.conf, there is either a global configuration file, a per user file or a per repo/branch. In order to support different workflows (for different teams, f.e.), this is not sufficient. But it could work if gbp.conf supported something similar to gitconfig includeIf: in my ~/.gitconfig i have ``` [includeIf "gitdir:~/deb/"] path = ~/.gitconfig-deb ``` (~/deb is where i keep all my Debian work), and that means that if the CWD is part of the ~/deb/ tree, git will also include ~/.gitconfig-deb which contains Debian-specific configs, like the @d.o mail address. Now, we'd also need a single location to store the team-specific gbp.conf, and we already have a repo thta would fit: https://salsa.debian.org/python-team/tools/packages , which currently contains files useful to work on the entire team packages. This is useful in my specific workflow, which is suspect is rather unusual, but here how it goes: * i checked https://salsa.debian.org/python-team/tools/packages in ~/deb/python (this could be anywhere) * run ./checkout -a to checkout all team packages (or ./checkout ... for only a subset) * use `mr` (via .mcrconfig) to work on _m_ultiple _r_epositories (mr) this repo could also contain a team-specific gbp.conf file we could use. Admittedly, we probably only need a handful of options, pristine-tar = True is only one that comes to mind (be aware this file will need to be compatible with *all* repos currently in the team, so setting the debian branch etc, wont work, until all repos are uniform). I'm going to file a feature request for the includeIf-like feature for gbp Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
> That's because gbp does not use pristine-tar by default, and > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to > fix that. I dont think this is the right approach: the default options to work on DPT packages should be in gbp default config file (or in another, global, config file), and not live in each and every package debian/gbp.conf file; it is already inconsistently maintained with several packages having uncommon settings that will take precedence over the default ones. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Python3 -dbg packages
> Now filed as > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pydbg-removal;users=debian-python@lists.debian.org why "Severity: serious"? none of them violates the policy: https://www.debian.org/Bugs/Developer#severities; please adjust to normal or important. thanks -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: How should learning to program in Python be approached, if learning objectives are sought to be customised?
Rajib, thanks for your enthusiasm in learning python, but please note this mailing list is dedicated to "Discussion of issues related to Python on Debian systems with a stress on packaging standards. Therefore relevant for maintainers of Python related packages.", while it appears you have general Python questions unrelated to packaging. so please look for help with them on a Python support channel as reported at https://www.python.org/about/help/ Regards, Sandro On Sun, Sep 5, 2021 at 7:24 AM Susmita/Rajib wrote: > > Thank you, Ms. Causey and Mr. van Baal-Ilić, for your posts. > > I am retaining the same subject line to avoid cluttering of my subsequent > posts. > > It appears that the Python books by Zed A Shaw are diversifying, > spreading out. From Learn Python The Hard Way, Addison-Wesley, 2013 > ed., to Learn Python 3 the Hard Way, Addison-Wesley, 2017 to Learn > More Python 3 the Hard Way, Addison-Wesley, 2017. > > So Python 3 and More Python 3 should be appropriate. But I begin to > suspect authors who try to replicate their 'success with one book' > with more number of similar books. > > My query regarding a huge repository for Python like the Oracle Java > repository, including example codes, structured information and object > library still remains unattended. > > Did any software/IT company like Oracle take up the responsibility to > erect such a meticulous construct bit by bit, or are such construct > yet to materialise? > > I have been using Bluefish to edit html files (simple edits), so I am > conversant with Bluefish editor. I also have the information regarding > Pycharm. So all set. > > Just waiting for the last mile information, as asked in this post > above and the earlier one with threat ref. > .../debian-python/2021/08/msg00033.html > > Best > Rajib > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Plan to upload all packages still using Alioth in Maintainer/Uploaders
> After the upcoming release of bullseye, I plan to start uploading all > packages that currently use Alioth to migrate them to Tracker (along > with the other pending changes in the git repos). progress for this work is now tracked at https://github.com/sandrotosi/debian-python-team-tracker Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Plan to upload all packages still using Alioth in Maintainer/Uploaders
Hello, a long time ago, we decided to stop using Alioth for the team email address in Maintainer/Uploaders fields, and onovy mass-committed this change to our repo; several of our packages (736, according to [1]) are still using Alioth. [1] https://lintian.debian.org/tags/python-teams-merged Alioth is no longer maintained (or at the very least, our 2 mailing lists), and the amount of spam received through it is way too high to be sustainable. After the upcoming release of bullseye, I plan to start uploading all packages that currently use Alioth to migrate them to Tracker (along with the other pending changes in the git repos). I understand it's possible an upload exists in experimental that fixes it, so i'll try and check for that; it's also likely that if a package is still using Alioth, their maintainer is longer interested in the package, but i dont think now it's the time for a mass purge. I also understand some of these packages will have the team as Uploaders and, according to our Policy, i should contact the physical person doing the upload beforehand, but i think that would slow down this process and i'm ready to deal with the consequences of not following the Policy to the letter. Please let me know if you prefer me to act differently. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Jupyter team?
On Tue, May 18, 2021 at 12:29 PM Roland Mas wrote: > I just created a topic on discourse to announce my effort. the link is https://discourse.jupyter.org/t/debian-packaging-effort/9240 for those who want to follow -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Asking for help Poetry
On Sat, May 8, 2021 at 9:56 PM Emmanuel Arias wrote: > On 5/8/21 10:37 PM, Sandro Tosi wrote: > > On Mon, Mar 15, 2021 at 10:29 AM Emmanuel Arias wrote: > >> On Mon, Mar 15, 2021 at 4:22 AM Sandro Tosi wrote: > >>>> * poetry-core failing https://ci.debian.net/packages/p/poetry-core/ > >>> are you handling this failure? > > looks like this is fixed in git: do you need a sponsor? > Yes, please. Thanks! sounds good, i'll have a look at this package soon and let you know > >>>> * python-cleo in review > >>>> https://salsa.debian.org/python-team/packages/cleo I hope finished this > >>>> week > > stefanor uploaded it a few days ago > Yes. > >>>> * poetry still in progress > >>>> https://salsa.debian.org/python-team/packages/poetry -> need help and > >>>> reviews > > for this one it looks like you imported a new upstream release a week > > ago: is there something we can help/check about poetry? > > I've just push some advances. Currently, I'm working on tests, if you > want to take a look. maybe just ask here (or directly to me) if you have questions and what's failing/needs work, so we dont duplicate work > We need new upstream release for python-httpretty (for tests), that I > upload to mentors [0]. @zigo ask me about test that this new upstream > release doesn't break > cloud-init and python3-scciclient (I would like to take a look to ratt > for that). ratt is pretty great, and rather simple to use: - setup a sbuild schroot for unstable - build a binary package from the source you're working on - `ratt _amd64.changes` and then you'll get on screen the results for each package + a directory with the build results and logs https://github.com/Debian/ratt keep in mind it rebuilds packages sequentially, so it can take some time if the number of reverse deps is high. > Perhaps a good help from a more experienced person would be check if all > is ok with DFSG,that's my biggest concern. for which package specifically? while it's boring and long work, it's also rather trivial: look at every single file (yep, all of them) from the upstream source, and document their copyright and license in d/copyright -- happy to answer questions if you have something specific in mind about this Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Asking for help Poetry
On Mon, Mar 15, 2021 at 10:29 AM Emmanuel Arias wrote: > On Mon, Mar 15, 2021 at 4:22 AM Sandro Tosi wrote: >> >> > * poetry-core failing https://ci.debian.net/packages/p/poetry-core/ >> >> are you handling this failure? looks like this is fixed in git: do you need a sponsor? >> > * python-cleo in review https://salsa.debian.org/python-team/packages/cleo >> > I hope finished this week stefanor uploaded it a few days ago >> > * poetry still in progress >> > https://salsa.debian.org/python-team/packages/poetry -> need help and >> > reviews for this one it looks like you imported a new upstream release a week ago: is there something we can help/check about poetry? Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Build an initial Debian source package with py2dsp from a GitHub project
> > this solution also underestimates the in-progress migration towards
> > poetry and pyproject.toml, where `python3 setup.py sdist` is not
> > available.
>
> Where does the metadata come from for projects using these things?
that'd be pyproject.toml AFAIUI
the point i wanted to make is that it would require to implement a
parser for setup.{py,cfg} and pyproject.toml, plus some way to decide
which one to use in case a project supports both (it happens) and how
to override the selection in case one system is available and outdated
(it happens).
All of this is done by PyPI already, and the fact a project exists on
GH but not on PyPI it's either because it's such a niche project or
it's still under heaving development, that working on a solution
*right now* is not a good use of our time.
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
Re: Build an initial Debian source package with py2dsp from a GitHub project
> Right and thus I am wondering if we could work through this, somehow? > That is, $something fetches the tarball, runs sdist or whatever, and > then the py2dsp magic. > > P.S. I know this sounds a little ambitious but I believe this would > really help, too. i do not plan to implement such a feature. this solution also underestimates the in-progress migration towards poetry and pyproject.toml, where `python3 setup.py sdist` is not available. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Build an initial Debian source package with py2dsp from a GitHub project
On Wed, May 5, 2021 at 2:58 PM Andrey Rahmatullin wrote: > > On Thu, May 06, 2021 at 12:08:06AM +0530, Utkarsh Gupta wrote: > > However, I am running into an issue (or I guess I am just not doing it > > correctly). > > Whilst trying to package from the g/h source > > (https://github.com/keylime/keylime), it fails like this: > > http://paste.debian.net/1195339/ > > > > Am I missing something? > As far as I can see, the change is only about getting the tarball, it > still needs metadata from PyPI. that's correct, the package still needs to be on PyPI, as that's the place where py2dsp obtains most of the package metadata -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Build an initial Debian source package with py2dsp from a GitHub project
> > > or git repository (a directory) that one has already downloaded. > > > > i dont see how starting from a git repo is useful, can you expand? > > instead of generating a .dsc first and then importing it into a git > repository, it's more logical to me to import an upstream tarball into a > git repository first (gbp import-orig), and then generate the debian > packaging on top of that. py2dsp does that for you: it creates a git repo, along with a source package, with the DPT settings (note i used the `--profile dpt`) ready to be pushed to salsa (the repo creation on salsa is still manual) Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Build an initial Debian source package with py2dsp from a GitHub project
> It would be useful if it could also be run against a tarball this is already supported (but in general by py2dsp and in the context of --github), f.e.: $ ./py2dsp --profile dpt --distribution unstable --revision 1 --gh https://github.com/indygreg/python-zstandard ./zstandard_0.14.1.orig.tar.gz uses the locally available zstandard_0.14.1.orig.tar.gz tarball (which is not the latest available on gh) to create the source pkg with the github customizations > or git repository (a directory) that one has already downloaded. i dont see how starting from a git repo is useful, can you expand? Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Build an initial Debian source package with py2dsp from a GitHub project
Hello, recently i've been making some enhancements to py2dsp (part of pypi2deb[1] ); for those who dont know what that is, py2dsp is a tool that, given a PyPI project, will create an (initial) Debian source package. [1] https://packages.qa.debian.org/p/pypi2deb.html I've just finished a patch that extend py2dsp to fetch the upstream tarball from GitHub instead; nowadays this is my preferred source for upstream tarballs, given it contains all the project files (not only the one published on pypi via sdist, often missing important files like tests, or doc sources, etc). it's currently available at the git branch at [2] (there's a PR open at [3]): [2] https://github.com/sandrotosi/pypi2deb/tree/morph [3] https://github.com/p1otr/pypi2deb/pull/27 once you cloned/checkout that branch, you can run: $ ./py2dsp --profile dpt --distribution unstable --revision 1 --github https://github.com/USER/PROJECT alternatively, you can specify an additional argument ``, if PROJECT is not the source name you want to use in Debian: $ ./py2dsp --profile dpt --distribution unstable --revision 1 --github https://github.com/USER/PROJECT and it will create the source package in the `result/` directory. Let me know if you find this useful and if there are issues/enhancement you'd like to see added/fixed. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Asking for help Poetry
> * poetry-core failing https://ci.debian.net/packages/p/poetry-core/ are you handling this failure? > * python-cleo in review https://salsa.debian.org/python-team/packages/cleo I > hope finished this week > * poetry still in progress > https://salsa.debian.org/python-team/packages/poetry -> need help and reviews what kind of help do you need here? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Asking for help Poetry
Hello Emmanuel, > From the missing dependencies we have: > * poetry-core in NEW [0] > * pastel in NEW need for clikit [1] > * pylev in NEW need for clikit [2] > * crashtest has RFS need for clikit [3] > * clikit is ready on salsa but waiting for crashtest before RFS [4] > * cleo ready but waiting for clikit [5] > * shellingham not ready nor ITP yet. > * poetry some advances on salsa [6] > > For experience in the other packages (pylev, paste, etc) and for > recommendation of DDs, > poetry package use upstream github repository where we have important things > like > tests. I was looking and exist lot of setup.py that makes me think that we > will need > repack the upstream package. > > I will continue working on it but after my reset week, I will be offline > until 9 january can you provide a status update on poetry packaging? more and more upstreams are moving (or planning) to poetry, so having it available asap is definitely important. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#985035: ITP: pydata-sphinx-theme -- Bootstrap-based Sphinx theme from the PyData community
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org Owner: Sandro Tosi * Package name: pydata-sphinx-theme Version : 0.5.0 Upstream Author : Joris Van den Bossche * URL : https://github.com/pydata/pydata-sphinx-theme * License : BSD Programming Lang: Python Description : bootstrap-based Sphinx theme from the PyData community Binary package names: python3-pydata-sphinx-theme originally developed for the pandas docs, work is being done to make this more generic and more easily extensible to suit the needs of the different projects; noteworthy project using this theme: . * Pandas: https://pandas.pydata.org/docs/ * NumPy: https://numpy.org/devdocs/ * Bokeh: https://docs.bokeh.org/en/dev/ * JupyterHub and Binder: https://docs.mybinder.org/, http://z2jh.jupyter.org/en/latest/, https://repo2docker.readthedocs.io/en/latest/, https://jupyterhub-team-compass.readthedocs.io/en/latest/ * Jupyter Book beta version uses an extension of this theme: https://beta.jupyterbook.org * Fairlearn: https://fairlearn.github.io/master/quickstart.html
Bug#984847: ITP: ppmd -- PPMd compression/decompression library
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-python@lists.debian.org Owner: Sandro Tosi * Package name: ppmd Version : 0.3.3 Upstream Author : miur...@linux.com * URL : https://github.com/miurahr/ppmd * License : LGPLv2+ Programming Lang: Python Description : PPMd compression/decompression library Binary package names: python3-ppmd PPM(Prediction by partial matching) is a compression algorithm which has several variations of implementations. PPMd is the implementation by Dmitry Shkarin. It is used in the RAR and by 7-Zip as one of several possible methods. . ppmd, aka. ppmd-cffi, is a python bindings with PPMd implementation by C language. The C codes are derived from p7zip, portable 7-zip implementation. ppmd-cffi support PPMd ver.H and PPMd ver.I. this is a new dependency of py7zr
Bug#982577: ITP: geventhttpclient -- http client library for gevent
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-python@lists.debian.org Owner: Sandro Tosi * Package name: geventhttpclient Version : 1.4.5 Upstream Author : Antonin Amand * URL : http://github.com/gwik/geventhttpclient * License : LICENSE-MIT Programming Lang: Python Description : high performance, concurrent HTTP client library for Python using gevent geventhttpclient uses a fast http parser, written in C, originating from nginx, extracted and modified by Joyent. . geventhttpclient has been specifically designed for high concurrency, streaming and support HTTP 1.1 persistent connections. More generally it is designed for efficiently pulling from REST APIs and streaming APIs like Twitter's. . Safe SSL support is provided by default. geventhttpclient depends on the certifi CA Bundle. This is the same CA Bundle which ships with the Requests codebase, and is derived from Mozilla Firefox's canonical set. this is a dependency of locust
Bug#982509: ITP: flask-basicauth -- HTTP basic access authentication for Flask
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-python@lists.debian.org Owner: Sandro Tosi * Package name: flask-basicauth Version : 0.2.0 Upstream Author : Janne Vanhala * URL : https://github.com/jpvanhal/flask-basicauth * License : BSD Programming Lang: Python Description : HTTP basic access authentication for Flask Binary package names: python3-flask-basicauth Flask-BasicAuth is a Flask extension that provides an easy way to protect certain views or your whole application with HTTP `basic access authentication`_. this is a dependency of locust
Bug#982508: ITP: locust -- Developer friendly load testing framework
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-python@lists.debian.org Owner: Sandro Tosi * Package name: locust Version : 1.4.3 Upstream Author : Carl Byström, Jonatan Heyman * URL : https://locust.io/ * License : MIT Programming Lang: Python Description : Developer friendly load testing framework Binary package names: python3-locust Locust is an easy to use, scriptable and scalable performance testing tool. You define the behaviour of your users in regular Python code, instead of using a clunky UI or domain specific language. This makes Locust infinitely expandable and very developer friendly. . Features: . * Write user test scenarios in plain-old Python -- If you want your users to loop, perform some conditional behaviour or do some calculations, you just use the regular programming constructs provided by Python. Locust runs every user inside its own greenlet (a lightweight process/coroutine). This enables you to write your tests like normal (blocking) Python code instead of having to use callbacks or some other mechanism. Because your scenarios are âjust pythonâ you can use your regular IDE, and version control your tests as regular code (as opposed to some other tools that use XML or binary formats). * Distributed & Scalable - supports hundreds of thousands of users -- Locust makes it easy to run load tests distributed over multiple machines. It is event-based (using gevent), which makes it possible for a single process to handle many thousands concurrent users. While there may be other tools that are capable of doing more requests per second on a given hardware, the low overhead of each Locust user makes it very suitable for testing highly concurrent workloads. * Web-based UI -- Locust has a user friendly web interface that shows the progress of your test in real-time. You can even change the load while the test is running. It can also be run without the UI, making it easy to use for CI/CD testing. * Can test any system -- Even though Locust primarily works with web sites/services, it can be used to test almost any system or protocol. Just write a client for what you want to test, or explore some created by the community.
Re: Python louvain packages naming confusion.
+Steffen explicitly, given the team is not in Maintainer nor Uploaders > How about renaming the current python3-louvain package to > python3-community-louvain using a normal transition package. that's incorrect: src:python-louvain builds a module called `community` (that includes also a cli tool), so the resulting binary package should either be `python3-community` or `community` where the cli is the main product and the module is installed in /usr/share/ to support it. > Then I can submit the other louvain package using a binary package name > of python3-louvain-igraph. this is incorrect too: (perspective) src:louvain (or src:louvain-igraph, as the upstream called their repo) builds a module called `louvain` so the resulting binary package should be `python3-louvain` eventually conflicting with the existing package (<< current-version-in-sid) src:python-louvain is in a pretty bad shape: it received a single upload in late 2018, it has an RC bug since a *day* after that upload, and it has never been in testing: tbh i dont consider this package to be maintained/targeting any stable release, so i believe you can "take over" the namespace given you seem to show interest in maintaining https://github.com/vtraag/louvain-igraph Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Joining DPT
> I would like to join DPT, I already maintain several packages under the DPT > umbrella how is this possible (maintaining packages in DPT without being a member)? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Joining the team
> > Added! > > > > Happy package maintenance :) > > Thanks <3 please name the project as the source package name, not "Easy Ansi" https://salsa.debian.org/python-team/packages/easy-ansi; also src:python-easy-ansi, the python- prefix is not strictly required -- anyhow, the salsa project name should match what source package name you decide to set. please fix Easy Ansi -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: diskcache: ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found
> I injected a new tarball drained from Github. It seems to need lots of > not yet packaged - I have no idea how to cope with this. i dont understand what you're trying to say here; if it's that diskcache requires modules/packages not present in debian yet, it's simple: you need to package those packages first or find someone else to do that. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: diskcache: ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found
Andreas, did you read the error before asking for help? i mean, it's literally right there On Mon, Jan 25, 2021 at 11:47 AM Andreas Tille wrote: > ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found and that's because https://github.com/grantjenks/python-diskcache/blob/master/tox.ini is not included in the pypi package (and, independently, the reason i start packaging tarballs from github, it's just easier than getting half baked pypi tarballs). It is not the first time you ask for help for trivial issues. you may want to look into why that's the case. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Status of https://debian-python.readthedocs.io/en/latest/
Hello, it looks like Barry (correct me if i'm wrong) set up https://debian-python.readthedocs.io/en/latest/ but it has not been updated in a while. Do we know what's the status of this website, if we want to continue to maintain it, or instead we should just consolidate onto https://www.debian.org/doc/packaging-manuals/python-policy/ ? Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#977936: ITP: python-multipart -- streaming multipart parser for Python
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: python-multipart Version : 0.0.5 Upstream Author : Andrew Dunham <> * URL : http://github.com/andrew-d/python-multipart * License : Apache Programming Lang: Python Description : streaming multipart parser for Python Binary package names: python3-python-multipart this is a dependency for fastapi (and its tests)
Re: Joining the team
On Mon, Nov 23, 2020 at 6:50 PM Thomas Goirand wrote: > > On 11/23/20 10:10 PM, Sandro Tosi wrote: > >>> First, an apology: it seems I misremembered being in the team, and > >>> uploaded to > >>> NEW a bunch of packages with the team in `Uploaders`. > >> > >> Please put the team as Maintainer, and yourself as Uploaders. > > > > why? that's not a requirement: > > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership > > Because joining a team, putting packages in them, and enforcing strong > ownership, is not logic at all. that's your opinion, and the policy disagrees with you. this team welcomes everyone that is willing to follow our policies and its rules. > I know you like to do this way, but this > shouldn't be what we advise for new comers. that's also what nicoo prefers, given he chose exactly that way for maintaining his packages. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Joining the team
> > First, an apology: it seems I misremembered being in the team, and uploaded > > to > > NEW a bunch of packages with the team in `Uploaders`. > > Please put the team as Maintainer, and yourself as Uploaders. why? that's not a requirement: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: [Python-modules-team] Bug#954381: marked as done (python3-kubernetes: New upstream version available)
>* Use git to generate upstream tarball, as the PyPi module doesn't include > the test folder. Using the gen-orig-xz in debian/rules, as using the > repack function of debian/watch doesn't make sense (why downloading a > tarball that would be later on discarded? I'm open to a better solution > which would be uscan compatible though...). Switch d/watch to the github > tag therefore. you can track the github project instead of pypi (man uscan has the details); this is was i'm doing recently, as most of the time PyPI releases dont have all the files we need (tests, or test data, or documentation, or a combination of that) -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Looking for information about the Python Team
> I'm looking for information about the work done by the Python Team for a > talk to encourage the Cuban python community to collaborate in Debian. why do you want to encourage people to contribute to a team you're not part of, to which you never contributed to (at least that i could quickly find), and of which you virtually know nothing about? > Where can I find information about: > - When the Python Team was created > - Number of active members (approximately) > - Number of packages under the responsibility of Python Team (approximately) > - Requirements to be a member of the Python Team > - Any other information of interest you can start from ttps://wiki.debian.org/Python -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Newcomers project: DPMT/PAPT pristine-tar verification
attached the dd-list of the packages missing the pristine-tar branch (some may have been moved/removed, but these are actual repos in DPT) On Fri, Jul 10, 2020 at 12:38 AM Sandro Tosi wrote: > Hello, > i would like to propose a project to make sure our teams (DPMT/PAPT) > repos are using pristine-tar properly. > > The checks i have in mind for now, are: > > * pristine-tar branch must exist, if not -> it's a bug > * pristine-tar + upstream branch must produce the same tarball as > downloaded from the archive, if not -> it's a bug > * bonus point: fix the repo if it doesn't generate the right tarball > and or the branch is missing. > * bonus point: make this into a service that runs regularly (not > strictly necessary to be limited to us) > > i guess we should have a brief discussion about additional checks > and/or procedures before "assigning" it to a volunteer. let's say up > to 2 weeks of discussion, and during the same period volunteers can > nominate themselves. > > I marked this project as newcomers as it doesn't require to be a DD/DM > to work on it, you just need a salsa account and access to our teams. > a handy tool to retrieve all our repos is at > > https://salsa.debian.org/python-team/tools/python-modules > https://salsa.debian.org/python-team/tools/python-apps > > that contains a config file for `mr` and a `checkout` script to fetch > the repos registered in that config file. > > Please feel free to discuss this project now :) > > Regards, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi Alastair McKinstry fparser jpy (U) usagestats Ana Custura python-offtrac Andrej Shadura pydenticon (U) pyrsistent (U) pyte python-ewmh (U) python-h2 (U) python-libguess (U) python-minimock (U) python-phonenumbers (U) python-urlobject (U) txacme (U) txsni (U) waitress (U) Andrej Shadura gtimelog (U) Andrew Shadura python-wheezy.template (U) Antoine Beaupré pymeeus (U) python-internetarchive python-spake2 Balasankar C vim-autopep8 Bastian Venthur pipenv (U) Benjamin Drung pyrundeck (U) Brian May factory-boy (U) Corey Bryant python-requests-mock (U) Daniel Kahn Gillmor py-postgresql (U) python-xdo (U) David da Silva Polverari pem Debian OpenStack python-etcd3 python-requests-mock python-sphinxcontrib.apidoc Debian Python Apps Team s3ql (U) Debian Python Modules Team aiowsgi autopep8 (U) black codespell derpconf django-session-security django-stronghold factory-boy fail2ban flask-assets flask-caching jpy milksnake netifaces patiencediff pikepdf power pydenticon pydle pykwalify pymeeus pyrsistent python-altair python-distutils-extra python-ewmh python-h2 python-injector python-libguess python-lz4 (U) python-lzo python-minimock python-offtrac (U) python-pathtools python-pcl python-phonenumbers python-plaster python-plaster-pastedeploy python-requests-ntlm python-urlobject python-wheezy.template python-xdo sireader (U) stardicter subvertpy txacme txsni vim-autopep8 (U) waitress wsgiproxy2 Debian Python Modules Team aiohttp-wsgi gevent-websocket py-postgresql Debian Python Team black pyrundeck Denis Danilov fortran-language-server (U) Dmitry Smirnov python-lz4 python-lzo (U) Federico Ceratto django-stronghold (U) Gaudenz Steinlin sireader Georg Faerber codespell (U) Gilles Dubuc derpconf (U) gustavo panizzo python-pathtools (U) Harlan Lieberman-Berg python-requests-ntlm (U) Jean-Michel Vourgère django-session-security (U) Jelmer Vernooij aiowsgi (U) flask-assets (U) flask-caching (U) milksnake (U) patiencediff (U) pydle (U) subvertpy (U) wsgiproxy2 (U) Jochen Sprickerhof python-pcl (U) Johan Fleury pykwalify (U) Johannes Tiefenbacher discodos (U) Jonathan Carter feed2toot flask-caching (U) power (U) s-tui toot Marcelo Jorge Vieira derpconf (U) yanc Mario Izquierdo (mariodebian) netifaces (U) Martin Pitt python-distutils-extra (U) Martin Wimpress python-injector (U) Maximiliano Curia python-intbitset Mehdi Abaakouk python-lzo (U) Michal Čihař stardicter (U) Mike Gabriel python-injector (U) Neil Williams black (U) Nicolas Dandrimont python-plaster (U) python-plaster-pastedeploy (U) Nikolaus Rath s3ql Peter Spiess-Knafl codespell (U) Python Applications Pack
Re: What is the new maintainer address for Python team?
> New/correct address is: > Maintainer: Debian Python Team Was this discussed somewhere? i cant find references in the ml -- thanks -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: can we disable the bounce kicker? Re: confirm
To these days, this is still happening! can we finally get rid of this? Piotr, it looks like you're the admin of the mailing list, can you take care of it please? thanks! On Mon, Jun 11, 2018 at 5:44 AM Ondrej Novy wrote: > > Hi, > > 2018-06-10 1:35 GMT+02:00 Sandro Tosi : >> >> this is still happening, and it looks like more frequently than before >> - can we please disable this option once and for all? > > > +1. Please. > >> >> >> On Sat, Sep 10, 2016 at 9:46 AM Sandro Tosi wrote: >> > I'm sure i'm not the only member using gmail, which bounces spam > > > me too. > > -- > Best regards > Ondřej Nový > > Email: n...@ondrej.org > PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: [Python-modules-team] python-uflash_1.2.4+dfsg-3_source.changes ACCEPTED into unstable
argggh removed the wrong address, adding Nick On Fri, Jul 31, 2020 at 1:27 PM Sandro Tosi wrote: > > >* d/control: > > - Mark package python3-uflash-doc as M-A: foreign > > This -doc package doesnt follow the policy, of having a python- prefix > and not a python3- prefix -- please fix -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
