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
Re: sphinxext-opengraph new version 0.5.0 ready for upload
On Mon, Nov 29, 2021 at 2:53 PM Chiara Marmo wrote: > > Dear list, Sandro, > > the 0.5.0 version of sphinxext-opengraph is on salsa ready for upload. I checked it, and it looks good to me so i've uploaded it, thanks for your contribution to Debian! For the next upload, it would be good to run tests at build-time, something that's currently not happening (and ideally add autopkgtest too) Thanks, -- 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
Re: [Python-modules-team] python-uflash_1.2.4+dfsg-3_source.changes ACCEPTED into unstable
>* 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
Granting `Janitor` direct access to our teams repos
Hello, I don't know the technicalities required to do that (nor i have permissions to do it myself anyway), but I'm wondering if we should grant direct access to our repos to the Janitor user. I don't think any of us checks those PRs in depth, and most of the time Jelmer comes in and bulk-merges them straight away (no complaints on that). So: let's just make that automatic? Thoughts? Regards, -- 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
On Sun, Jul 19, 2020 at 11:04 AM Raphael Hertzog wrote: > > Hi, > > On Fri, 10 Jul 2020, Sandro Tosi wrote: > > 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 would suggest that this would be a nice job for the janitor bot. > https://janitor.debian.net/ How would you suggest implementing this? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: RFH: Problemas with test process on python-jsonrpc-server
did you run the -v option, as suggested by the error? it may lead to what the problem is On Sat, Jul 18, 2020 at 7:03 PM Pablo Mestre wrote: > > Hi, > > Im trying to packages python-jsonrpc-server to solve the dependencies > for upgrade Python IDE Spyder. > > I get this issue with the test process and I dont find any solution at > the moment: > > https://github.com/palantir/python-jsonrpc-server/issues/43 > > The problem is only with python version 3.8 > > Any idea how i can solve this issue > > The salsa repo is > https://salsa.debian.org/elMor3no-guest/python-jsonrpc-server > > Thanks in advance > > Pablo > > -- 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: Request to join DPMT
Luca, > I have read and accept the policy.rst - if accepted, I will update the > branch policy of my modules to match the policy (mainly > s|debian/sid|debian/master|) and update the Maintainer field, > everything else already matches. In your request to join email, you agreed to accept and follow our policy, and adapt your packages to it. sadly that did not happen: all your packages lack both `upstream` and `pristine-tar` branches, and they still have `debian/sid` as main branch (which would be fine, but you said you'd change it). Please rectify the situation. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: mercurial switch to python3 in debian unstable - July 16th, 2020
> I guess a lot of things are unlocked now. I wonder how we can help > fixing what's remaining. I think i already took care of all the packages that got (recursively) freed up by switching mercurial to python3. > Please do share your thoughts on that. I guess one can always look at http://sandrotosi.me/debian/py2removal/index.html for some work regarding the py2removal effort -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: mercurial switch to python3 in debian unstable - July 16th, 2020
> If we dont hear otherwise, we plan to upload the python3 version of > mercurial in unstable on or around next Thursday, July 16th. mercurial/5.4.1-2 has just been uploaded to unstable, switching it to use python3. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: The python command in Debian
> It seems to be a little bit more controversial what should happen to the > python > command in the long term. Some people argue that python should never point to > python3, because it's incompatible, > however Debian will have difficulties to > explain that decision to users who start with Python3 and are not aware of > the 2 > to 3 transition. can you explain this point? i think if a new developer starts with python3 now (and i have plenty of examples at my company) they just use `python3` on the commandline, shebangs, venv, etc. I dont see the confusion we would create. > So yes, in the long term, Debian should have a python command > again. I dont think that's the right decision. PEP 0394 (https://www.python.org/dev/peps/pep-0394/) allows distribution not to ship `python` at all: https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors * If the python command is installed, it is expected to invoke either the same version of Python as the python3 command or as the python2 command. * Distributors may choose to set the behavior of the python command as follows: ** python2, ** python3, ** not provide python command, ** allow python to be configurable by an end user or a system administrator. > One solution could be not to ship the python command in bullseye, forcing > users > to adjust their local installations. it is my opinion that that's what we should do: not ship `python` at all and have users/packagers/developers use either python2 or python3 as needed, and not to reintroduce `python` at a later time. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: py2removal RC severity updates - 2019-12-22 17:36:38.269399+00:00
> src:dbus-python cannot drop its Python 2 support until all of the reverse > dependencies of python-dbus have done so (or been removed from testing, but > that's unlikely to happen while they include key packages like avahi, > jackd2 and pyqt5). this is now the case: bin:python-dbus has no more reverse dependencies (that are not RC and/or being removed from testing), see dak output: Checking reverse dependencies... # Broken Depends: dbus-python: python-dbus-dbg **Internal deps python-dbus-tests ladish: ladish ** removed from testing in May 2020 neard: neard-tools ** removed from testing in Dec 2019 wicd: wicd-daemon ** removed from testing in Oct 2019 So please proceed with drooping python-dbus as soon as possible. Currently python-dbus is the sole rdep of python-gi, which then could be dropped when python-dbus is gone. Let me know if you need help with this activity: i'm available to NMU or team upload src:dbus-python if that's preferred 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 Python Modules Team
> Imaging you are the person that wants to join this cool project. > You made some effort to apply for membership and sent in the request. > Then you wait humblely. Humble as you are, you wait another day. > On third day you start wondering "Is asking again expressing > that you care or is it pushing the people you want to join?" I did not see a single MR from all the people that requested to join the team in recent times (and i'm subscribed to MR notifications for both DPMT and PAPT), and i do know that you cannot submit an MR for new packages. Almost all those introductory mails mentioned "I want to maintain this new package *AND* [emphasis added] help with general maintenance" but those maintenance contributions never really came (neither before or after membership was granted, at least not at the level a person that cares so much would lead to expect). If they really want to contribute they can always submit MRs or patches to the bts, and/or prepare a NEW package in a temporary location if access is still not granted; but that didnt really happen. We dont really have a good process to accept new contributions (it mostly boils down to single individuals to review, merge, upload), but we also dont really that many to begin with. Geert, I personally find your approach towards the current members/admins pushy, so speaking exclusively for myself l I would suggest you to be mindful that, while I may believe you're trying to be helpful, you may come across differently than how you intended. Regards, -- 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] pychromecast_7.1.1-1_source.changes ACCEPTED into unstable
Andrej, the pristine-tar branch has not been updated (not sure if you didnt push it or it was not imported with the --pristine-tar option) On Sat, Jul 11, 2020 at 1:04 PM Debian FTP Masters wrote: > > > > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Sat, 11 Jul 2020 18:45:04 +0200 > Source: pychromecast > Architecture: source > Version: 7.1.1-1 > Distribution: unstable > Urgency: medium > Maintainer: Debian Python Modules Team > > Changed-By: Andrej Shadura > Changes: > pychromecast (7.1.1-1) unstable; urgency=medium > . >* Team upload. >* New upstream release. > Checksums-Sha1: > c890d7a377ea7484823065ac404870ec73d909c8 1897 pychromecast_7.1.1-1.dsc > 0bce73ca78cfa25e585c28b56cc4cdd5b647f5ac 57075 pychromecast_7.1.1.orig.tar.gz > 76f6076ac34b247501301e587018f392b48b0fb7 3516 > pychromecast_7.1.1-1.debian.tar.xz > Checksums-Sha256: > 783fbdd898819cbccedece2f6055879c3b96005dfe0c0454cdf4f2261b4f9f9a 1897 > pychromecast_7.1.1-1.dsc > e0113bca3323546b9affc0b9187afceb224682a4db66280017a469476b244631 57075 > pychromecast_7.1.1.orig.tar.gz > 2856c17018180eed9f7f5767c900100349a3cc7550b7785d3cecf59a7d49804a 3516 > pychromecast_7.1.1-1.debian.tar.xz > Files: > 97c18b1be74e9b6d7c86cf605a51bb3b 1897 python optional > pychromecast_7.1.1-1.dsc > 32726da37759a15deb4e199a31c6fb54 57075 python optional > pychromecast_7.1.1.orig.tar.gz > 3b55122a623accf5d90d79724d0e22ad 3516 python optional > pychromecast_7.1.1-1.debian.tar.xz > > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl8J7NUACgkQXkCM2RzY > OdLbCQf9HjNvz/dB4itbedQutgeeEEmgStSZdnWuqyiSP6tnd8qqu4wKRvDTEdZM > AAseqradRlL3cZpnbLeUMkuffOvcZf+rxSh1H+rhfjWPkGn1+rE8mRdB5A+lOAtK > MKlWiBs2VGuLrrF1phRkTIJxzBLdmBT1JGmfFWqTcEA66kOeCDtHAJJG4Y99lUMV > I5nL6J2odl6sN4BDhrkyCd7or6yP4ahG+9SiACp+Fw8nhHk2v3728S+HUTOSsbxh > 1boiiwEbt1T3MQ1MM0e+xMAGbL56EfTmpZsXwaBXjgFjQhSk/iH5j3F8pDNFEaVF > /d/BM61VF43XFu00s25lF+cCP8Ypqw== > =pYDM > -END PGP SIGNATURE- > > > Thank you for your contribution to Debian. > > ___ > Python-modules-team mailing list > python-modules-t...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Newcomers project: DPMT/PAPT git repos verification
Hello, i would like to propose a project to make sure our teams (DPMT/PAPT) repos are being used correctly; it has a broader set of requirements than the pristine-tar one (and so it's more complex), thus a separate message. The checks i have in mind for now, are: * packages in DPMT/PAPT need to have a repo in our teams, if not -> move them in our salsa team if somewhere else or remove DPMT/PAPT from M/U * packages no longer in our team (moved, orphaned, etc) needs to get their repo removed from our team * is the repo up-to-date with the archive? f.e. is the version in unstable the latest one released from this repo? * does the repo contain all the versions uploaded to the archive? * are tags up to date with the package releases? * is the content of debian/gbp.conf against our policies? * 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
Newcomers project: DPMT/PAPT pristine-tar verification
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
mercurial switch to python3 in debian unstable - July 16th, 2020
Hello, this email is to inform the maintainers of the reverse dependencies of mercurial of the plan to upload to unstable the python3 version next Thursday. We want to be extra-safe with the switch, hence this email. In To: to this email the maintainers mailing list + key other MLs and addresses, in Bcc: the real people listed in Maintainer/Uploaders of the involved packages, apologies if you received more than 1 copy of it. The full list of the packages, as produced by dak, is available at the bottom of this email. There has been a test rebuilt, via ratt, as part of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937009#142 and it doesnt look like there's any failure in the build process due to the switch (except for meson, which indirectly build-depends on python2 without listing it). Mercurial is also used as part of the normal operation of a program, and that cannot be tested automatically, nor via a rebuild. The python3 version of mercurial is available in experimental (5.4.1-1+exp1); if you could test it against your package to make sure it works as you intended, that would help the transition. Mercurial has an extensive test suite, which passes 100% with python3, so we dont expect any failure while using the `mercurial` command, but some interfaces/operations may have changed. If we dont hear otherwise, we plan to upload the python3 version of mercurial in unstable on or around next Thursday, July 16th. This effort will greatly benefit the broader effort of py2removal, by allowing the chain removal of several other packages. Regards, Sandro $ dak rm -Rn mercurial Will remove the following packages from unstable: mercurial |5.4.1-1 | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x mercurial-common |5.4.1-1 | all Maintainer: Python Applications Packaging Team --- Reason --- -- Checking reverse dependencies... # Broken Depends: git-remote-hg: git-remote-hg hg-git: mercurial-git hgsubversion: hgsubversion mercurial-buildpackage: mercurial-buildpackage mercurial-crecord: mercurial-crecord mercurial-extension-utils: mercurial-extension-utils mercurial-keyring: mercurial-keyring python-hgapi: python3-hgapi python-hglib: python3-hglib sphinx-patchqueue: python-sphinx-patchqueue # Broken Build-Depends: check-manifest: mercurial composer: mercurial devpi-common: mercurial git-remote-hg: mercurial golang-github-masterminds-vcs-dev: mercurial haskell-filestore: mercurial hg-git: mercurial (>= 4.8~) hgsubversion: mercurial (>= 5.2-1~) jags: mercurial meson: mercurial pepper: mercurial python-hgapi: mercurial python-hglib: mercurial (>= 1.9) reposurgeon: mercurial ros-rosinstall: mercurial ros-vcstools: mercurial ros-wstool: mercurial setuptools-scm: mercurial Dependency problem found.
Re: py2removal - make all leaf applications RC
> I propose to raise the severity of all leaf applications in 3 days, if > i dont hear any objections. This is now enabled and at the next run (in ~50 minutes) it will take effect. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
py2removal - make all leaf applications RC
Hello, Currently only leaf applications (ie something that doesnt start with `python-`) with popcon <= 1000 get their py2removal bug bumped to RC. I propose to raise the severity of all leaf applications in 3 days, if i dont hear any objections. The current list of applications, and their popcon, impacted by this is: gnumeric-plugins-extra, popcon = 1072 xchat, popcon = 1437 getmail, popcon = 1285 libapache2-mod-python, popcon = 3626 mysql-workbench, popcon = 1355 Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye
> > > Do you need any help in coordinating with the packaged extensions, > > > testing changes, preparing patches? a lot of time has passed since we > > > started asking about mercurial and python3 and it is becoming the only > > > reverse-dependency of several packages that could be removed if > > > mercurial switched to py3k. > > > > > Getting an uptodate list of extensions and their status wrt porting both > > upstream and in Debian would be useful. I've spent some time looking at > > hgsubversion a few weeks ago but there's a ton of work and I don't > > actually use it so I've kind of given up on that; I forget what the > > status is on others. > > will look into the rdeps of mercurial once 5.4.1-1+exp1 hits the archive I've rebuilt all rdeps of mercurial against the python3 version uploaded to unstable; results are: 2020/07/05 00:28:22 Build results: 2020/07/05 00:28:22 PASSED: salt 2020/07/05 00:28:22 PASSED: golang-github-masterminds-vcs-dev 2020/07/05 00:28:22 PASSED: pepper 2020/07/05 00:28:22 PASSED: python-hglib 2020/07/05 00:28:22 PASSED: git-remote-hg 2020/07/05 00:28:22 PASSED: haskell-filestore 2020/07/05 00:28:22 PASSED: composer 2020/07/05 00:28:22 PASSED: yotta 2020/07/05 00:28:22 PASSED: ros-rosinstall 2020/07/05 00:28:22 PASSED: check-manifest 2020/07/05 00:28:22 PASSED: jags 2020/07/05 00:28:22 PASSED: setuptools-scm 2020/07/05 00:28:22 PASSED: reposurgeon 2020/07/05 00:28:22 PASSED: devpi-common 2020/07/05 00:28:22 PASSED: firmware-microbit-micropython 2020/07/05 00:28:22 PASSED: python-hgapi 2020/07/05 00:28:22 PASSED: hgsubversion 2020/07/05 00:28:22 PASSED: ros-wstool 2020/07/05 00:28:22 PASSED: ros-vcstools 2020/07/05 00:28:22 FAILED: hg-git (see buildlogs/hg-git_0.8.12-1.2) 2020/07/05 00:28:22 FAILED: meson (see buildlogs/meson_0.54.3-1) (build logs and artifacts are at https://people.debian.org/~morph/mercurial_python3/ ) hg-git is RC and not in testing since mid-December, and meson is i think a real error, since without mercurial depending on python2 now the build fails to find that executable Tbh, i think it's time to just rip the bandaid and upload mercurial python3 to unstable, and deal with the consequences there (i volunteer to do so); you mentioned hgsubversion as a potential blocker: that package are popcon on 56, i dont believe such a minor package should hold progress with the py2removal effort (I've added debian-python@ to gather their input on this). I do understand the rebuild results are not conclusive on the python3 migration (after all hgsubversion rebuilds fine with py3k mercurial, which also raises the questions of why it b-d on it since it clearly doesnt use it, but i'm digressing), but i think it's better to just go ahead and upload the experimental version to unstable and see what's the impact there What do people think 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: Maintaining all of the testing-cabal packages under the OpenStack team
> Running the script shows that 279 reverse (build?) dependencies are > affected by mock. This clearly isn't something one wants to run on a > personal computer, and even less a test which one wants to run sequentially. > > Has any thought went into having some kind of runners running on a cloud > to run these tests, and maybe plug this into Salsa's CI to run it > automatically? > > I'd very much would love to set this up, at least as a first > experimentation on a bunch of package of the DPMT. i sent this some time ago do d-devel https://lists.debian.org/debian-devel/2020/03/msg00342.html it didnt get much traction -- 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: Maintaining all of the testing-cabal packages under the OpenStack team
> Is anyone from the team opposing to this? Yes, i'm against your proposal. > If so, please explain the > drawbacks if the OpenStack team takes over. 1. you're personally attacking Ondrej, who is one of the very few members of this team doing team-wide work, and that should be enough to reject it 2. this is clearly an hostile take-over (even if you frame it as a proposal), and that should be enough to reject it 3. you propose to only update those packages every 6 months, i dont find it appropriate: OS is *just* another software we package for Debian; is it complex? sure, but it's not special, and it doesnt warrant any special treatment. 4. you clearly want to have sole and absolute control of the packages in the openstack-team, because what would happen if a os-team member will upgrade one of those packages (in good faith) and things will break? will they get another "well done! :( " email from you? 4.1. You wonder why Ondrey "stopped caring" about OS, if that's the case, i could see why 5. consolidating packages *into* the DPMT/PAPT gives a lot of benefits, f.e. people basically got "free" handling of the py2removal process; moving packages out is actually detrimental for the python ecosystem (at least that's my opinion). Thomas, this is not the first time your temperament and aggressive behavior is causing some troubles, please reassess how you interact and work with other fellow contributors. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Future of PyPy (not PyPy3) in Debian
Hello all, it looks like i started a process that would require the removal of several PyPy (as in pypy-* depending on the `pypy` package) packages from the archive. I'm now wondering: what should we do with the entire pypy ecosystem? should we treat pypy-* packages like python-* ones and remove then as part of py2removal? do we need/want to track this effort with the same usertag? is there a (even if only hypothetical for now) programmed transition from pypy- to pypy3-? PS: if i made mistakes, just call me out, and i'll do my best to fix them or revert them; i have no problem in being told i did something wrong (let's keep the discussion in this thread on topic, so pypy etc) Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#962024: RFP: cppy -- collection of C++ headers which make it easier to write Python C extension modules
Package: wnpp Severity: wishlist * Package name: cppy Version : 1.1.0 Upstream Author : The Nucleic Development Team * URL : https://github.com/nucleic/cppy * License : BSD 3-Clause Programming Lang: Python Description : collection of C++ headers which make it easier to write Python C extension modules this is a new dependency for kiwisolver/1.2.0
Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes
> Any trick to avoid those errors in general? when i push i always do $ git push --all ; git push --tags i also have these in ~/.gitconfig [push] default = current followTags = true with should make the `git push --tags` unnecessary after `git push --all` (as tags will "follow" the diffs you're pushing) but it's stuck in my bash history so there it is > Anyways, it should be there now! indeed it's there -- thanks! -- 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] Processing of paramiko_2.7.1-1_source.changes
Antoine, you did not push the upstream branch. please do so, in order to keep the repo consistent On Mon, May 11, 2020 at 10:15 PM Debian FTP Masters wrote: > > paramiko_2.7.1-1_source.changes uploaded successfully to localhost > along with the files: > paramiko_2.7.1-1.dsc > paramiko_2.7.1.orig.tar.gz > paramiko_2.7.1-1.debian.tar.xz > paramiko_2.7.1-1_amd64.buildinfo > > Greetings, > > Your Debian queue daemon (running on host usper.debian.org) > > ___ > Python-modules-team mailing list > python-modules-t...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#960148: RFP: hstspreload -- Chromium HSTS Preload list as a Python package
Package: wnpp Severity: wishlist * Package name: hstspreload Version : 2020.5.5 Upstream Author : Seth Michael Larson * URL : https://github.com/sethmlarson/hstspreload * License : BSD-3 Programming Lang: Python Description : Chromium HSTS Preload list as a Python package It is used by httpx (althought it's not a hard requirement, but nice-to-have) Please consider package this under DPMT
Re: issues installing psutil with pip in virtual environment
> I am running into an issue installing psutil: pip3 install psutil, in a > virtual environment. I have upgraded my pip and setuptools with no > avail. I am getting this error: https://pastebin.com/2Xb7UN9g psutil is not pure python, and contains some extensions that need to be compiled, so your system needs to have a compiler, gcc, installed; since it's not you get "unable to execute 'x86_64-linux-gnu-gcc': No such file or directory" > Some have suggested installing the python3-dev package. Saying that I > require "header" files (don't know what those are). So this means > installing that package and creating a new venv, where those files are > available. Is there a way to make this install work without installing > that package? Is that package really necessary? Does this mean my you will necessarily need to install python3-dev > virtual environments are somehow subject to what libraries are > available in my system python installation? yes, in a similar way as they are dependent on the system interpreter to create and run the venv > Is there some pip > installabel package that provides these files? some packages on PyPI provide binary releases, but psutil looks like it doesnt for linux, so you need to compile it. alternatively you can install python3-psutil on your host and then "virtualenv --system-site-packages" to use the system-available modules. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
