Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
On May 13, 2024 8:13:06 PM UTC, Julian Gilbey wrote: >On Wed, Apr 03, 2024 at 03:58:21PM -0400, Jeremy Bícha wrote: >> I noticed one package affected by this issue, prettytable, has >> switched to a fork, pytest-lazy-fixtures (note the s at the end of the >> name). >> >> Would someone like to package this for Debian to fix several packages >> failing to build? >> >> https://github.com/dev-petrov/pytest-lazy-fixtures >> >> Thank you, >> Jeremy Bícha > >Dear all affected by pytest-lazy-fixture: pytest-lazy-fixtures is now >in testing and unstable; in many cases, it can be used as a drop-in >replacement for pytest-lazy-fixture (though not all, it turns out). > >I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from >Debian unstable. Please transition all the rdepends first. Asking before that's done just creates more work for everyone. Scott K
Re: Launchpad: Merge of Accounts Requested
On March 18, 2024 9:19:21 AM UTC, Dominik George wrote: >Hi, > >>FYI: This message got delivered at the public mailing list >>debian-python@lists.debian.org. To me it looks like someone if trying to find >>a loophole in launchpad and plans to abuse the system. > >Thanks for reaching out to them. > >While at it, I'd also question why Canonical is scraping public repositories >and creating user accounts for the scraped addresses. > >Yes, I know why they do it, but for me, it is another example of bad >collaboration practice, on top of everything else to be said about Ubuntu (or >more precisely, its owners). > >It's also small things that impose burdens on others, and if they think they >need to fork Debian, copy packages from it (to put behind a paywall >afterwards), then they certainly could do that without spoofing Debian people >and team addresses. > >Disclaimer: I am assuming good faith in this specific case, but not in >Canonical and Ubuntu in general. > It's not from scraping. It's from the maintainer field in packages that they import from Debian. This probably isn't the place to have that argument. I have raised this with them before. The first time was probably over a decade ago. Scott K
Re: Launchpad: Merge of Accounts Requested
On March 17, 2024 8:49:02 PM UTC, Gregor Riepl wrote: >> Someone has asked us to merge one of your Launchpad >> accounts with another. >> >> If you go ahead, this will merge the account called >> 'Debian Python Modules Team (debian-python)' into the account >> 'johnfrandes12'. >> >> To confirm you want to do this, please follow >> this link: > >This looks extremely fishy - and I also wonder why someone used a public >mailing list address to register a Launchpad account? > It's an automatically created account based on the maintainer address in imported packages. Nothing really related to us in Debian. The account merger request was really from Launchpad. It was either fishy or a mistake. I declined it when I saw the message on the team's behalf. Scott K
Re: Maintenance of python-resolvelib and python-commentjson
On March 15, 2024 11:11:21 PM UTC, Bo YU wrote: >Hi! > >On Sat, Mar 16, 2024 at 1:18 AM Scott Kitterman wrote: >> >> On Friday, March 15, 2024 10:55:34 AM EDT Stefano Rivera wrote: >> > Hi Scott (2024.03.15_13:31:40_+) >> > >> > > I originally packaged python-resolvelib for pip and python-commentjson so >> > > we could run python-resolvelib's tests. Pip is no longer using the >> > > packaged version. It's currently used by pdm and ansible-core. >> > >> > However pip does still use resolvelib (albeit vendored). I make an >> > effort to keep all pip's vendored dependencies in Debian so that we are >> > familiar with them and track their security issues. >> > >> > So, I'll add myself as an uploader of resolvelib. >> >> Thanks. I've removed myself. Commentjson is required for the resolvelib >> tests (and nothing else). Do you want to do that one too? >Would you mind me to take it? I would like to add myself as one of the >uploaders before Stefano answers this. I certainly don't mind. It's up for grabs for anyone on the team. Scott K
Re: Maintenance of python-tomlkit
Great. Thanks, I've already removed myself from uploaders in git. Feel free to add yourself and go for it. Scott K On March 15, 2024 6:03:47 PM UTC, Emmanuel Arias wrote: >Hi Scott, > >I can take it. > > >cheers, >Emmanuel Arias > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ eam...@debian.org > ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: FA9DEC5DE11C63F1 > ⠈⠳⣄ > > >On Fri, Mar 15, 2024 at 2:50 PM Scott Kitterman >wrote: > >> This is another one I don't use anymore where I'm the sole uploader. >> >> It's got a fair number of rdepends, most notably poetry. Any takers >> before I >> orphan it? >> >> Scott K
Maintenance of python-tomlkit
This is another one I don't use anymore where I'm the sole uploader. It's got a fair number of rdepends, most notably poetry. Any takers before I orphan it? Scott K signature.asc Description: This is a digitally signed message part.
Re: Maintenance of python-resolvelib and python-commentjson
On Friday, March 15, 2024 10:55:34 AM EDT Stefano Rivera wrote: > Hi Scott (2024.03.15_13:31:40_+) > > > I originally packaged python-resolvelib for pip and python-commentjson so > > we could run python-resolvelib's tests. Pip is no longer using the > > packaged version. It's currently used by pdm and ansible-core. > > However pip does still use resolvelib (albeit vendored). I make an > effort to keep all pip's vendored dependencies in Debian so that we are > familiar with them and track their security issues. > > So, I'll add myself as an uploader of resolvelib. Thanks. I've removed myself. Commentjson is required for the resolvelib tests (and nothing else). Do you want to do that one too? Scott K signature.asc Description: This is a digitally signed message part.
Re: Maintenance of python-cryptography
On March 15, 2024 3:47:25 PM UTC, Thomas Goirand wrote: >On 3/15/24 13:52, Scott Kitterman wrote: >> >> >> On March 15, 2024 7:19:16 AM UTC, Thomas Goirand wrote: >>> On 3/14/24 08:52, Andreas Tille wrote: >>>> I would have prefered to >>>> read constructive arguments instead of silent leaving the team (in the >>>> sense of not informing the team mailing list about the leave). >>> >>> Me too. But I'm not surprised. >> >> I didn't have a list, I'm glad someone went through and made one. >> >> Yes, he might have handled his departure from the team differently, but I >> found the entire discussion about changing the team policy on setting the >> maintainer very off putting. I haven't talked to him about it beyond making >> sure he was aware of the discussion, so I don't know why he handled it the >> way he did, but I can easily imagine he was quite frustrated. >> >> Frankly, I think statements like the above aren't particularly consistent >> with the project CoC and have me thinking again about if this is the kind of >> team I care to be involved with. > >Which part? The one where I am saying that I'm not surprised? That in no way >should be taken badly, or as an attack on him. Let me explain then. > >I too, would prefer if Sandro didn't leave, even if I had difficult moments >when communicating with him. I stated it already, I did appreciate his >contribution to the team, and to the project at large. > >Though it's a fact that I was not surprised, because you mentioned it. We knew >in advance it could happen. Looking backward, it seems it was inevitable, >unfortunately. > >I'd be very sad to see you go as well, please stay. > >> While the way he left the team is on him, the fact that it even came up is >> 100% on the people pushing this change. > >I do not agree. It came up because what it was generating (frustration, flames >about "rogue uploads", you name it...) had to be addressed. > My level of frustration is not declining. I suggest to you that the source of the emails about rogue uploads were the rogue uploads. I think that not following the rules and then complaining that people called you on not following the rules has an obvious source. This was an avoidable own goal on the team's part because, in my judgement, there was too little openness to diversity of opinions on how to do things. Scott K
Maintenance of python-resolvelib and python-commentjson
I originally packaged python-resolvelib for pip and python-commentjson so we could run python-resolvelib's tests. Pip is no longer using the packaged version. It's currently used by pdm and ansible-core. I am the sole uploader for both these packages and intend to orphan them, but if someone else once to take them over, please do so. I have included the ansible-core maintainer in cc: since this most directly affects them. Please speak up if you are interested. Scott K signature.asc Description: This is a digitally signed message part.
Re: Maintenance of python-cryptography
On March 15, 2024 7:19:16 AM UTC, Thomas Goirand wrote: >On 3/13/24 18:34, Scott Kitterman wrote: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064979 >> >> Would some of you who are pushing so hard to change the policy for Uploaders/ >> Maintainer in the team please step up and take over this package. It really >> needs updated to the new upstream release (blocking both aioquic and >> dnspythong for me, I don't know about others). >> >> I haven't done a comprehensive check, but I think morph asked for all the >> leaf >> packages he was maintaining in the team to be removed from the archive and is >> removing himself from uploaders/maintainer on others. >> >> You all made this mess. Please clean it up. > >Absolutely not. Sandro did. There's btw absolutely no reason to declare a >package as "orphan" if it is supposed to be team maintained. It's also a very >bad behavior to do this silently, without telling the team about it, or taking >part of the thread. I very much regret things are happening this way, but I >don't think the rest of the team should be held responsible. > >If you have the list of the packages matching what you are saying, please do >share. > >On 3/14/24 08:52, Andreas Tille wrote: >> I would have prefered to >> read constructive arguments instead of silent leaving the team (in the >> sense of not informing the team mailing list about the leave). > >Me too. But I'm not surprised. I didn't have a list, I'm glad someone went through and made one. Yes, he might have handled his departure from the team differently, but I found the entire discussion about changing the team policy on setting the maintainer very off putting. I haven't talked to him about it beyond making sure he was aware of the discussion, so I don't know why he handled it the way he did, but I can easily imagine he was quite frustrated. Frankly, I think statements like the above aren't particularly consistent with the project CoC and have me thinking again about if this is the kind of team I care to be involved with. While the way he left the team is on him, the fact that it even came up is 100% on the people pushing this change. I don't think there's any evidence that some other reason is the cause. Also, for packages which are team maintained, but only have one uploader, orphaning is exactly the correct thing to do when that person gives up the package. A human uploader is required. Similarly, it's the maintainer's call if a package should be removed or if it can remain maintained by QA. While I agree more communication would have better, those are entirely appropriate actions for a team maintained package with a single uploader. Scott K
Re: Maintenance of python-cryptography
On Wednesday, March 13, 2024 1:34:14 PM EDT Scott Kitterman wrote: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064979 > > Would some of you who are pushing so hard to change the policy for > Uploaders/ Maintainer in the team please step up and take over this > package. It really needs updated to the new upstream release (blocking > both aioquic and dnspythong for me, I don't know about others). > > I haven't done a comprehensive check, but I think morph asked for all the > leaf packages he was maintaining in the team to be removed from the archive > and is removing himself from uploaders/maintainer on others. > > You all made this mess. Please clean it up. Actually, it looks like python-cryptography still has one uploader, but morph was doing work on the package, it's complicated, and could use more help, not less. Pyopenssl, on the other hand, is now unmaintained (no human uploader). Scott K signature.asc Description: This is a digitally signed message part.
Maintenance of python-cryptography
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064979 Would some of you who are pushing so hard to change the policy for Uploaders/ Maintainer in the team please step up and take over this package. It really needs updated to the new upstream release (blocking both aioquic and dnspythong for me, I don't know about others). I haven't done a comprehensive check, but I think morph asked for all the leaf packages he was maintaining in the team to be removed from the archive and is removing himself from uploaders/maintainer on others. You all made this mess. Please clean it up. Scott K signature.asc Description: This is a digitally signed message part.
Re: Suggesting change in DPT policy
On March 3, 2024 6:12:09 AM UTC, Andreas Tille wrote: >Hi Christian, > >Am Sat, Mar 02, 2024 at 11:48:57PM +0100 schrieb Christian Kastner: >> On 2024-03-02 23:11, Andreas Tille wrote: >> > I'm curious why you believe I didn't care. I likely would have reverted >> > my change if I didn't have more urgent matters to attend to. >> > Re-uploading a package just to revert the Maintainer and Uploader is >> > lower on my priority list than fixing other RC bugs. >> >> To add another perspective: what if reverting is not about "fixing" the >> package again, but a courtesy or sign of respect towards the person that >> was upset by this action. Wouldn't that change the priority entirely? > >Thanks for pointing this out. I agree I failed here. I hope to not >fail the same way in future again since in this very case I can't fix >this any more. > >The lesson I hopefully learned now is that this kind of failures seems >to put other arguments I gave for a policy change in the shadow at least >for those team members I would love to reach for a constructive >discussion. Thanks both for your response and for Christian for doing a much better job than I managed trying to communicate this. Scott K
Re: Suggesting change in DPT policy
On March 2, 2024 8:29:47 PM UTC, Andreas Tille wrote: >Hi Jeroen, > >Am Thu, Feb 29, 2024 at 08:48:33PM +0100 schrieb Jeroen Ploemen: >> ... > >Julian had sensibly commented on this and had added interesting >questions I'm keen on hearing your answers. > >> As for the inclusion of codes of conduct or similar wording, >> documenting common sense just feels unnecessary. While being on the >> receiving end of a compliment for bug-squashing work is certainly >> nice, the lack thereof isn't a measure of disrespect. > >Julien also commented on this. Despite I never thought to spent so much >time on the bug that triggered the discussion I consider it important >enough to clarify some misunderstandings which obviously were caused by >the mails I wrote about this. > >As a non-native speaker, I am actively working on improving my >communication skills. I would appreciate it if you could point out which >part of my messages led you to believe that I felt disrespected. My >intention was simply to provide some insight into why the task someone >scheduled for me was not high on my priority list during my spare time. > >To summarize the visible facts: > > 2023-12-12 serious bug #1058177 was filed, solution for this kind of >bugs is simple for maintainers comfortable with Python 3.12 > > 2023-12-22 closed with changelog >[ Andreas Tille ] >* Set DPT maintainer >* Replace SafeConfigParser deprecated in Python3.12 > Closes: #1058177 >* Transparently skip test_bad_pagebuilder instead of ignoring test suite > errors > > --> I confirm "Set DPT mainter" was in conflict with DPT policy since > I just forgot about that very detail and considered it some > unintended oversight. I will not do this again as long as this > policy is not changed > > Response in Salsa comment[1] > > Sandro Tosi: @tille please explain why you think this is appropriate > > Andreas Tille: In all teams I know policy says the team address should be put > as Maintainer. After checking DPT policy again again I realise it gives both > options with different meanings. Sorry about that and feel free to revert. > > Sandro Tosi: @tille you made the mistake, so you do the reverting and the > uploading to rectify it. > > >Comment: That seems fair. If my real-life boss had asked, I would have >done it, considering he pays me for it. Fortunately, my day job boss >knows how to motivate me better. I wouldn't had brought this up on my >own behalf. I just went into more detail to explain why I did not fixed >my mistake immediately. As a volunteer, I have the freedom to choose >which tasks to prioritize. A little kindness in communication can >significantly impact my priorities. I wasn't expecting a "thank you for >fixing the bug," but I believe it's unrealistic for Sandro to expect me >to follow such commands as a volunteer. (Fun fact: I was throwing the >last two paragraphs into a LLM and besides fixing my paragraph several >changes where suggested to Sandro's quote.) > > >sphinxtesters (0.2.3-4) unstable; urgency=medium > > * Revert attempt by a rogue developer to hijack this package > > -- Sandro Tosi Sun, 14 Jan 2024 01:25:23 -0500 > > >I wonder how the attribute 'rogue' is supported by the discussion above, >nor where the intention to hijack the package is inferred from. > > >sphinxtesters (0.2.3-5) unstable; urgency=medium > > * orphan > > -- Sandro Tosi Thu, 29 Feb 2024 01:55:25 -0500 > > >I admit the last upload makes the initial request to revert the >Maintainer change questionable. I also confirm that I have experienced >worse things before than giving me the attribute "rogue" or blaming >me about bad intentions. Fine for me I developed some thick skin >meanwhile. > >> I cannot recall >> any discussion on the team's IRC channel or mailing list crossing >> that line. > >If you cannot recall anything that crossed the line I intended to draw >explicitly in our policy through my MR[2], I am curious to know where, >in your opinion, this falls in relation to our goal of 'striving to >create a kind and inviting atmosphere among team members.' If it would >be only about me, I would simply move on (which I did until there was >another point of friction with no public traces). But it does concern >fostering a welcoming team environment. In my view, this crosses the >line, and I am grateful to have been part of teams where such incidents >were not tolerated. > >Kind regards >Andreas. > >[1] >https://salsa.debian.org/python-team/packages/sphinxtesters/-/commit/d8b1083db26c753c8a76dd91b7e91f3ef98c0515#note_450676 >[2] >https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/21 > It's possible I am misunderstanding you here (languages are hard even when they are your first), but if I am not, I think you are not really seeing things from the correct perspective. Here's my summary of what I understand your argument to be: I did not follow the team policy and
Re: Suggesting change in DPT policy
On Wednesday, February 28, 2024 3:21:12 AM EST Andreas Tille wrote: > Hi, > > Louis-Philippe (just quoting below in case you might have missed it) is > repeating the importance that anyone who thinks my suggestion (MR[1]) is > a bad idea make themselves heard. I'm hereby adding those maintainers > who have more than 5 packages that are affected and did not yet raised > their opinion in To: field. > > udd=> SELECT * FROM (select maintainer, count(*) from sources where > uploaders like '%team+pyt...@tracker.debian.org%' and release = 'sid' group > by maintainer order by maintainer) tmp WHERE count > 5; maintainer > | count > -+- > -- Debian PaN Maintainers > | 7 > Jeroen Ploemen |16 > Piotr Ożarowski |23 > Sandro Tosi |82 > Scott Kitterman | 7 > Vincent Bernat |15 > (6 rows) > > Debian PaN is another team which might need extra discussion but I think > the intention is clear and Scott has raised his opinion before[2]. > > Kind regards > Andreas. > > [1] > https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/ > 20 [2] https://lists.debian.org/debian-python/2024/02/msg00060.html I used to use this a lot more than I do now. Currently I only use it for packages where I'm also the or a upstream developer, so it generally makes more sense to do non-packaging changes there. This did cause me to go back and check and I found one I had missed when I was changing this previously. I've just uploaded vrfydmn with DPT as maintainer. Looking at your list, I note that it includes team members that have been very active in team wide work, not just on their own packages. I think it would be contrary to the spirit of Debian and working together if we changed the rules and they felt they had to leave the team. Scott K signature.asc Description: This is a digitally signed message part.
Re: Suggesting change in DPT policy
On February 28, 2024 9:54:55 AM UTC, Thomas Goirand wrote: >On 2/28/24 00:54, Scott Kitterman wrote: >> It's self-induced. I mean if it's demotivating to have people point out >> that you didn't follow the policy, then you can solve that all by yourself >> by following the policy. If I take your argument to its logical conclusion, >> all of Debian's rules can be demotivating when people ignore them, so we >> should get rid of them all so your feelings are safe. > >The way you're wording it, it feels like we on purpose didn't follow what was >written in the policy. That's not the case. > >The point you're missing here, is that this policy is not obvious at all, and >it's easy to either not understand it, or not know about it. That seems rather tangential to the question at hand. In the cases you cited the people in question both knew about and understood the policy. I agree that I am not really following your logic. Andreas' explanation makes more sense to me, but it's neither here nor there as you don't need to convince me. My only concern is that we not cause people to leave the team over this change. I'm personally ambivalent about it. Scott K
Re: Suggesting change in DPT policy
On February 28, 2024 7:08:14 AM UTC, Andreas Tille wrote: >Hi Scott, > >Am Tue, Feb 27, 2024 at 11:54:01PM + schrieb Scott Kitterman: >> It's self-induced. I mean if it's demotivating to have people point out >> that you didn't follow the policy, then you can solve that all by yourself >> by following the policy. If I take your argument to its logical conclusion, >> all of Debian's rules can be demotivating when people ignore them, so we >> should get rid of them all so your feelings are safe. > >I agree that it was my mistake to not follow team policy. I should not >have done this and I apologized for this. I should have written this >e-mail first to change a policy that does not fit my experiences in >other teams as well as what obviously several contributors consider >inappropriate. To solve this I started this discussion and meanwhile >created a MR[1]. > >The demotivating part was the wording to point me to the policy. I >addressed this with the words "I wonder whether I should propose another >change to the policy about maintaining a kind and polite language inside >the team - but that's a different thing." in my initial mail[2]. > >To make sure this will really clear I added the proposed change in a >second MR[3] containing the following diff: This makes more sense to me. It is completely understandable that how things are communicated affects how people feel about them. This is a difficult thing to get right. I have experienced similar demotivating conversations in Debian myself. Everyone in Debian is already bound by the code of conduct already, so it seems redundant to add it here again. While I agree with the principle you are trying to address, I think this change unnecessarily clutters the DPT document and we should not make it. Scott K
Re: Suggesting change in DPT policy
On February 27, 2024 11:42:33 PM UTC, Thomas Goirand wrote: >On 2/27/24 19:32, Scott Kitterman wrote: >> I suspect that packages will be removed from team maintenance as a result >> though and I think that's a bad idea. > >If a package isn't in the team, any DD can ask for permission from the >maintainer before an upload. So, what's the difference, with a package that is >"is in the Python team", but nobody from the team can upload without prior >approval from the current maintainer? It simply doesn't make sense. > >So at the end, if packages get "removed from the team", it's a good thing: it >clarifies the situation. > >Andreas has been the biggest uploader of packages for many years (by the >number of upload per year), and working a lot on Python stuff. It feels wrong >we both fell in the "upload not granted: you should have read the team's >policy better" mistake, and I do not wish others also receive this kind of >demotivating message anymore. > It's self-induced. I mean if it's demotivating to have people point out that you didn't follow the policy, then you can solve that all by yourself by following the policy. If I take your argument to its logical conclusion, all of Debian's rules can be demotivating when people ignore them, so we should get rid of them all so your feelings are safe. Scott K
Re: Suggesting change in DPT policy
On February 27, 2024 2:27:35 PM UTC, Scott Talbert wrote: >On Tue, 27 Feb 2024, Thomas Goirand wrote: > >> On 2/27/24 09:05, Andreas Tille wrote: >>> Hi, >>> >>> I became more deeply involved into DPT since 2022 as a consequence of >>> the suggestion for transfering several Debian Med/Science packages to >>> DPMT[1][2]. I happily followed this suggestion and moved >30 packages >>> from the Blends teams to DPT. I was happy with this move since it makes >>> sense. >>> >>> Recently we received lots of testing removal warnings in those Blends >>> teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So >>> I did what I usually do in those teams: I dedicated quite some time in >>> team wide bug hunting. That way I squashed about 50 bugs on packages >>> where I was not in Uploaders. When doing so I usually run >>> routine-update on the package which basically streamlines packaging to >>> latest standards including calling Janitor tools which are so far >>> accepted inside DPT. >>> >>> I probably should have reviewed the DPT policy on Maintainership[3] more >>> carefully. In other teams, it's common for the Maintainer to be set to >>> the team, so I assumed it was just an oversight when I made this >>> change[4] when touching the package to fix RC bug #1058177. However, I >>> I was pointed immediately about the fact that I was mistaken according >>> to the current DPT policy. I apologize for this. However, the wording >>> of the comment on my commit was discouraging, especially considering I >>> was a volunteer who had fixed a critical bug. Because of this, I >>> decided to focus my efforts on fixing other critical bugs for the >>> moment. If the comment had started with a 'Thanks for fixing the >>> critical bug, but...' I likely would have corrected my mistake quickly. >>> The lack of respect from my teammate simply made me prioritize my time >>> on other issues that are more visible to our users. I wonder whether I >>> should propose another change to the policy about maintaining a kind and >>> polite language inside the team - but that's a different thing. >>> >>> While I applied the patch for another RC bug (#1063443) after >2 weeks >>> which triggered a RC bug in reportbug I remembered the "keep the >>> maintainer" policy. But I kept on doing Janitor like changes since >>> finally the package is maintained in a team where Janitor is accepted. >>> When doing so I failed the phrase "please contact the Maintainer for the >>> green light." I apoligize for this again. The response was another >>> volunteer-demotivating private mail (thus no quote) which also was >>> lacking the "Thanks for fixing"-phrase and degrading my changes as >>> "frivolous". >>> >>> So far what happened (seen from my possibly biased perspective). >>> >>> Why do I like to change the policy? >>> >>> The current wording provides some means to stop volunteer team members >>> helping out moving forward to speed up migrations and fix Debian wide >>> dependencies. It hides team maintained packages from a common BTS >>> view. When pointing my browser to >>> https://bugs.debian.org/team+pyt...@tracker.debian.org >>> I currently see 1339 open bugs (calculated by [UDD1]). This hides >>> another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work >>> around this flaw I used an UDD query to find relevant Python3.12 bugs. >>> >>> When I think twice about the wording >>> Team in Uploaders is a weak statement of collaboration.[3] >>> I personally consider it a statement of *no* collaboration (which fits >>> the wording of the responses I've got). >>> >>> How can a team member for instance find another RC bug #1009424? Just >>> from reading the bug report it is pretty easy to fix but does not >>> feature any response in BTS. I came across this while looking into >>> Cython 3.0 bugs. The same source package (basemap) that had the open >>> Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug >>> (#1009424) that stayed unattended for 22 months? We all know volunteers >>> have limited time and I do not want to blame anybody in the team to not >>> care promptly about RC bugs. But what else is the sense of a packaging >>> team than stepping in situations for long standing RC bugs and RC bugs >>> tagged patch? >>> >>> This kind of situation wouldn't occur in teams where collaboration is >>> strong and communication is effective. My motivation to address these >>> long-ignored critical bugs diminishes when the maintainer opts for >>> "weak" cooperation and lacks respectful communication with potential >>> helpers. I see no difference to simply do a NMU. >>> >>> I've checked the current situation who is actually using the DPT team as >>> Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages >>> some of these "Maintainers" are other teams and lots of the persons >>> listed as Maintainer are known to be MIA. This means the packages are >>> de-facto not maintained
Re: Packages Up For Grabs
On Wednesday, January 3, 2024 5:22:38 PM EST Scott Kitterman wrote: > On Saturday, September 23, 2023 3:26:05 PM EST Scott Kitterman wrote: > > I'm the only human upload for the following packages that I no longer > > intend to maintain. Please let me know if you are interesting in taking > > over the package. If no one steps up, if a package has rdepends I'll > > orphan it (since a human uploader is required) and if it doesn't, i'll > > ask to have it removed: > > > > aiodns (technically there's one other uploader, but they've been inactive > > for years) > > appdirs > > django-anymail > > django-impersonate > > django-maintenancemode > > django-organizations > > django-wkhtmltopdf > > pdfkit > > pycares (also technically has another uploader that's deeply inactive) > > > > There will be another list, but I'm currently short of motivation to > > complete the email about my lack of motivation, so that's it for now. > > I never saw any responses to this and looking in git, no one seems to have > stepped up. I've decided to keep aiodns and pycares for now, but I'll start > orphaning the others in the near future. Also, I only packaged python- > sparkpost as a dependency of django-anymail, so I'll orphan that one too. > > Once that's done, I'll see about another list. If anyone wants to keep any > of these in the team, please speak up now. These are all orphaned now: django-anymail django-impersonate django-maintenancemode django-organizations django-wkhtmltopdf pdfkit python-sparkpost Scott K signature.asc Description: This is a digitally signed message part.
Bug#1063348: O: pdfkit
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Control: affects -1 src:pdfkit I am no longer interested in this package and no else in the Debian Python Team expressed interest it taking it over, so orphaning. The package itself is in reasonable shape. Upstream includes the following warning in the Git version of the package README: This library has been deprecated to match the wkhtmltopdf project status. Scott K
Bug#1063317: O: django-anymail
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Control: affects -1 src:django-anymail I'm no longer interested in the package and no one from the Debian Python Team expressed interest in it, so orphaning. I've updated the package to the current upstream and updated for the switch to hatchling, so that package is in good shape for now. Upstream is moderately active. Scott K
Bug#1063171: O: python-sparkpost
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Control: affects -1 src:python-sparkpost I'm no longer interested in the package (it was only packaged to support django-anymail, which is also about to be orphaned). This is an interface to a proprietary mail service. The company was acquired in 2021 and nothing has happened with the package upstream since then. The package itself is in reasonably good condition. There is one Python 3.12 related issue that will be addressed in the upload that orphans the package. Scott K
Bug#1063033: O: django-wkhtmltopdf
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Control: affects -1 src:django-wkhtmltopdf I no longer use this package and no one in the Debian Python Team expressed any interest in it, so orphaning. At this time, the package is in reasonably good shape and does not generally require a lot of attention. It's not clear if upstream is dead or moving slowly. Scott K
Bug#1061447: O: django-maintenancemode
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Control: affects -1 src:django-maintenancemode Orphaning the package on behalf of the Debian Python Team as the sole uploader (no one else on the team expressed interest in taking over and I no longer use the package). The package itself is in reasonable shape. Upstream is mostly dean, so if you take over this package, expect to have to do more than just package new upstream releases. Scott K
Bug#1060463: O: django-impersonate -- Django module for superusers to impersonate accounts
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Control: affects -1 src:django-impersonate Orphaning the package on behalf of the Debian Python Team as the sole uploader (no one else on the team expressed interest in taking over and I no longer use the package). Currently the package is in good shape. There is a new upstream release available, which I will include in the upload that changes the maintainer to Debian QA Group. Scott K
Bug#1060406: O: django-organizations -- Django groups and multi-user account management module
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Control: affects -1 src:django-organizations Orphaning the package on behalf of the Debian Python Team as the sole uploader (no one else on the team expressed interest in taking over and I no longer use the package). Currently the package is in good shape. There is a new upstream release available, which I will probably include in the upload that changes the maintainer to Debian QA Group. Scott K
Re: Packages Up For Grabs
On Saturday, September 23, 2023 3:26:05 PM EST Scott Kitterman wrote: > I'm the only human upload for the following packages that I no longer intend > to maintain. Please let me know if you are interesting in taking over the > package. If no one steps up, if a package has rdepends I'll orphan it > (since a human uploader is required) and if it doesn't, i'll ask to have it > removed: > > aiodns (technically there's one other uploader, but they've been inactive > for years) > appdirs > django-anymail > django-impersonate > django-maintenancemode > django-organizations > django-wkhtmltopdf > pdfkit > pycares (also technical has another uploader that's deeply inactive) > > There will be another list, but I'm currently short of motivation to > complete the email about my lack of motivation, so that's it for now. I never saw any responses to this and looking in git, no one seems to have stepped up. I've decided to keep aiodns and pycares for now, but I'll start orphaning the others in the near future. Also, I only packaged python- sparkpost as a dependency of django-anymail, so I'll orphan that one too. Once that's done, I'll see about another list. If anyone wants to keep any of these in the team, please speak up now. Scott K signature.asc Description: This is a digitally signed message part.
Packages Up For Grabs
I'm the only human upload for the following packages that I no longer intend to maintain. Please let me know if you are interesting in taking over the package. If no one steps up, if a package has rdepends I'll orphan it (since a human uploader is required) and if it doesn't, i'll ask to have it removed: aiodns (technically there's one other uploader, but they've been inactive for years) appdirs django-anymail django-impersonate django-maintenancemode django-organizations django-wkhtmltopdf pdfkit pycares (also technical has another uploader that's deeply inactive) There will be another list, but I'm currently short of motivation to complete the email about my lack of motivation, so that's it for now. Scott K signature.asc Description: This is a digitally signed message part.
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On September 17, 2023 9:48:38 PM UTC, Thomas Goirand wrote: >Scott & everyone, > >On 9/16/23 19:04, Scott Kitterman wrote: >> It's pretty relevant to your question. If you had instead updated the >> existing packages from the new upstream, no transition would be needed. > >I'm not entirely sure that no transition is needed, no. The major version was >bumped to version 5, and I have no clue if this represent some >incompatibility. This needs to be tested at least (see below). > >> Did you check with the existing maintainers to see what they thought? > >Hum ... why do you think I've opened this thread? > >> As is usually the case in Debian, I think the answer is you work with the >> maintainers to figure out the best solution. Ignoring them and hijacking >> the packages is not the right answer. > >Ditto. > >Plus I really dislike that you write the word "hijacking". That's not at all >my intention, and /me opening this thread proves it. > >Anyways, let's try to be more productive... I thought it was kind of obvious >why I did things the way I did, but let me try to be more explicit. > >It is my understanding that "pysnmp4" doesn't match "pysnmp-lextudio" released >as version 5.0.20. We could rename the binary as "python3-pysnmp" (ommiting >the "4"), and have a transition package, yes. But I have no confidence that >they are drop-in replacements (I just don't know yet...). > >The packages that I maintain do need the lextudio modules *now* (OpenStack >moves fast, I cannot afford to wait 6 months), so I thought it was faster to >address the current situation first with my uploads, so I can offer a >continuity of what I already packaged (ie: Ironic and other OpenStack stuff). >Though believe me, I want to do the things properly, and I have no intention >of hijacking anyone's work. If someone wants to work on this with me, we can >move the 4 new lextudio packages back in the team, of course. I have already >too many packages under my responsibility, I'd love to have others working on >them. Then I can act on the OpenStack part of things quickly once we agree on >the way to go. > >So let me ask once more the persons involved and/ore volunteering on this: >what's your suggestion? There's actually 2 paths (and yes, I had the 2 paths >in mind before Scott suggested replacing the older packages): > >1/ We get the lextudio packages replace the older packages like Scott >suggested. This would be a transition anyways, since we're moving to version 5 >and there's a year of commits. If we're to do like this, then we need to make >sure that: >- the lextudio replacing packages are staged in experimental first, and look >at the pseudo-excuse >- the reverse dependencies have meaningful autopkgtest, otherwise uploading to >experimental first is pointless, and then 2/ below becomes the best solution > >2/ The other possibility, is what I suggested and envisioned first, by >uploading the lextudio packages: open 9 bugs, and let maintainers switch to >the new packages. This is IMO the safest path, as it wont create any breakage, >though we'd have conflicting packages for a while, which can be annoying. We >got to make sure the transition finishes quickly enough then (meaning, >probably make the bugs RC after some time, so we make sure we can remove the >older pysnmp/asn1 packages before Trixie freeze). > >I don't think 2/ is an inferior way of doing things. I am still convinced that >I did the right way, that uploading the *-lextudio packages was correct, so >that current maintainers of reverse dependencies can at least test and see if >everything goes well with the new packages, without destroying them. I also >continue to have OpenStack packages working this way, and I'm not destroying >reverse dependencies carelessly. > >Please share your thoughts on how to do it, >Cheers, > >Thomas Goirand (zigo) > I think if you propose to maintain these packages as part of the Debian Python Team, then it's not a hijack, but that is not what you are doing. I'd suggest that if you don't like the word, then don't hijack the packages. Perhaps new packages are needed, but it's usual to have the conversation first. Openstack moves fast isn't a good excuse to skip collaboration. Scott K
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On September 16, 2023 4:48:46 PM UTC, Thomas Goirand wrote: >On 9/15/23 14:03, Scott Kitterman wrote: >> Why did you hijack this from the Python team instead of just working with the >> existing maintainers to update the existing packages from the new upstream >> location? >> >> Scott K > >Thanks for replying to the original question ... :) > >If the current maintainer was interested, they had plenty of time to work on >this (it's been nearly a year that lextudio took over). It doesn't seem to be >the case unfortunately. > >If someone wants to take over my work, please do (and write in this thread >saying you're working on it...), it's not too late. I take care of too many >packages already, I'd love if someone stepped in. > It's pretty relevant to your question. If you had instead updated the existing packages from the new upstream, no transition would be needed. Did you check with the existing maintainers to see what they thought? Were they even aware of the new upstream work (it's happened to me before that I was unaware of such a switch)? As is usually the case in Debian, I think the answer is you work with the maintainers to figure out the best solution. Ignoring them and hijacking the packages is not the right answer. Scott K
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On Friday, September 15, 2023 3:38:05 AM EDT Thomas Goirand wrote: > Hi, > > As you may know, the upstream author for pysnmp passed away last year. > As a result, the whole suite was forked by "lextudio". I packaged it, > and the result is this list of source packages: > > python-pyasn1-lextudio > python-pyasn1-modules-lextudio > python-pysmi-lextudio > python-pysnmp-lextudio > > Appart from the OpenStack packages, here's the list of reverse > dependencies for the old python3-pysnmp4 binary package: > > * patator > * pdudaemon > * pysmi > * snimpy > * changeme > * python3-snimpy > * python3-pysnmp4-apps > * python3-pysnmp4-mibs > * snmpsim > > My plan is to file bugs against these packages, asking to transition to > the newer packages. We're just below the threshold for asking > debian-devel about mass bug-filling, so I figured out I would only send > a mail to the Python list. Do you guys approve my plan? Should we make > transition dummy packages? > > Also to Adam Cécile: can you make your pull request against the new > Salsa repository? Why did you hijack this from the Python team instead of just working with the existing maintainers to update the existing packages from the new upstream location? Scott K signature.asc Description: This is a digitally signed message part.
Re: DebConf 23: Python BoF
On Sunday, September 10, 2023 1:23:12 AM EDT Stefano Rivera wrote: > We have scheduled a Python BoF at DebConf23: > https://debconf23.debconf.org/talks/27-python-bof/ > It will be on Sep 16 (Sat): at 10:30 local time (05:00 - 05:45 UTC) > > I started getting together an agenda in: > https://pad.dc23.debconf.org/p/27-python-bof > Please help me to build it out. As of today (assuming my count approach worked correctly), there are 5,118 source packages in Debian that B-D/B-D-I dh-python. Of those, only 813 B-D/B- D-I pybuild-plugin-pyproject. I think it's very premature to be considering something at 20% usage for any kind of default. I don't think it's a good idea in any case. The only advantage I can see is that people would not have to add pybuild-plugin-pyproject to B-D/B-D-I anymore. If the build backend is anything other than setuptools, people will still have to add that, so I don't see much of an advantage here. In cases where both setup.py and pyproject.toml are provided, these packages might start to FTBFS. On the disadvantage side, any package that does use setuptools has a pyproject.toml that has not been migrated by the maintainer (packages with both setup.py and pyproject.toml are not rare) will be automatically switched with unpredictable results. The best case scenario is nothing changes. I don't really see a lot of upside here. Let's not. We have lintian checks to let maintainers know they can update to the newer system. I think that's sufficient. Scott K signature.asc Description: This is a digitally signed message part.
Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Friday, August 18, 2023 9:33:48 AM EDT Andreas Tille wrote: > Hi Scott, > > Am Fri, Aug 18, 2023 at 01:15:18PM + schrieb Scott Kitterman: > > On August 18, 2023 1:04:26 PM UTC, Andreas Tille wrote: > > >> In Debian terms, it's not the preferred form for modification, so it's > > >> not source. In this regard DFSG goes farther than some software > > >> licenses.> > > > >I think the point Jeroen wanted to make is that these are actually > > >source file archives which "by chance" are featuring a .whl extension > > >rather than a .zip extension. > > > > A wheel is not the preferred form for modification. They're not wheels by > > chance at all. > Yes, thanks to Jeroen's hint I realised this as well and I agree that > this is a nasty way to hide the fact that the files are actually source > archives. They aren't. > However, you confirmed yourself that future_fstrings is an exception and > comes with source and thus does not violate DFSG. The only difference > I personally can see is that the archives are just hiding what they are. > We could simply add do some >for whl in *.whl ; do ln -s $whl $(basename .whl).zip ; done > and we have source archives that are obviously what they are. > > > From a DFSG perspective, > > Hmmm, the only thing where I can draw a violation of the DFSG is that > there are no d/copyright entries for the source code that is hidden > inside these *.whl files. Otherwise its "just" duplicated code (in most > cases) which is definitely not nice but IMHO not a violation of DFSG. > The disagreement here is that Python wheels aren't source. DFSG #2 requires the source be present and these aren't it. If you look at the WAF entry in the FTP team reject FAQ, this is similar. The FTP team view has long been that DFSG #2 means the actual preferred form for modification. > > the most straightforward approach is to build-depend on the relevant > > Debian packages and build any needed wheels from that. > Do avoid source code duplication I'm willing to do that. Yes, I > perfectly agree that its pretty ugly (I'm just a bit unsure about > the DFSG violation). I'm wondering whether a simple > >zip whl.zip /path/to/python/files ; mv whl.zip whl.whl > > will be something that can replace the current packages. I think > we also need to patch the tests to fit the version numbers (if > we do not want to cheat and simply use the version numbers of the > original whl files to avoid patching). Perhaps, but there are nuances to the wheel format. Please use Wheel to generate them. > > It won't necessarily get you the same version as upstream uses, but it's > > definitely DFSG compliant. > We also might symlink our resulting whl files with the version number > pdm upstream might expect in their tests. The question is, whether all > this effort might break the tests in some way and we might end up with > endless patching by at the same time loosing the chance to discuss with > upstream. But it might be time to discuss the issue with upstream > anyway. Perhaps. If it were me, what I'd do is locate the missing tarballs and stash them in debian/missing-sources/ and worry about more complex solutions later. Once you're done that, you've met DSFG #2 and there's no need to strip the wheels from the binary. It's not super maintainable, but it will allow you to focos on getting the tests working as upstream ships them without any Debian customizations that might cause Debian specific failures. Scott K signature.asc Description: This is a digitally signed message part.
Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 18, 2023 1:04:26 PM UTC, Andreas Tille wrote: >Hi Scott, > >Am Tue, Aug 15, 2023 at 02:18:35PM + schrieb Scott Kitterman: >> >They are zip files containing python source code. It is possible to include >> >compiled C extensions in wheels, but I checked and these wheels are all pure >> >python, so no binary blobs are included. >> >> In Debian terms, it's not the preferred form for modification, so it's not >> source. In this regard DFSG goes farther than some software licenses. > >I think the point Jeroen wanted to make is that these are actually >source file archives which "by chance" are featuring a .whl extension >rather than a .zip extension. A wheel is not the preferred form for modification. They're not wheels by chance at all. From a DFSG perspective, the most straightforward approach is to build-depend on the relevant Debian packages and build any needed wheels from that. It won't necessarily get you the same version as upstream uses, but it's definitely DFSG compliant. Scott K
Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 15, 2023 1:51:54 PM UTC, Jeroen Dekkers wrote: >On Tue, 15 Aug 2023 15:08:11 +0200, >Scott Kitterman wrote: >> >> On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: >> > Hi Scott, >> > >> > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: >> > >> > > those are all binary without source. That's a problem. >> > >> > Given your role as ftpmaster you definitely have more experience than I >> > in this field. I personally was thinking more in the line of binary >> > data we can not avoid in some cases. This is a bit in the line with >> > Rdata decision[1] where those binary data files are documented in >> > debian/README.source. >> > >> > My point is just: If we remove those data files (which are IMHO harmless >> > since these are not executd but used as input in tests - please correct >> > me if I'm wrong) we can not test the package. Removing the files >> > prevents testing and thus we can not know whether the package we deliver >> > will work. I've actually shown that not all tests are working but >> > stopped investigating this further. >> >> Even if they are used as data (I didn't check), they are, in fact, binary >> blobs of code by our definition and that requires the corresponding source. > >They are zip files containing python source code. It is possible to include >compiled C extensions in wheels, but I checked and these wheels are all pure >python, so no binary blobs are included. In Debian terms, it's not the preferred form for modification, so it's not source. In this regard DFSG goes farther than some software licenses. Scott K
Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: > Hi Scott, > > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: > > >Before I upload I'd like to ask for reviewing this patch and opinions > > >about the test suite errors. While these possibly occure in previous > > >versions (which I did not tested) we might consider ignoring just the > > >failing tests. I need to admit that I did not went through the list of > > >single failures - may be there is a chance of easy fixes for some of > > >them. I simply wanted to discuss the reintroduction of the artifacts > > >and my patch first. > > > > With the exception of future_fstrings > > I think there is also the souce for demo included. > > > those are all binary without source. That's a problem. > > Given your role as ftpmaster you definitely have more experience than I > in this field. I personally was thinking more in the line of binary > data we can not avoid in some cases. This is a bit in the line with > Rdata decision[1] where those binary data files are documented in > debian/README.source. > > My point is just: If we remove those data files (which are IMHO harmless > since these are not executd but used as input in tests - please correct > me if I'm wrong) we can not test the package. Removing the files > prevents testing and thus we can not know whether the package we deliver > will work. I've actually shown that not all tests are working but > stopped investigating this further. Even if they are used as data (I didn't check), they are, in fact, binary blobs of code by our definition and that requires the corresponding source. > > It's probably okay if you add the corresponding source somewhere in the > > package. > We probably have some source packages inside Debian - may be in > different versions. I need to admit that I intended to do a "quick fix > of a simple bug that affects some Debian Med packages" but realised that > I'm possibly opening a can of worms. The simplest solution to fulfill > my needs would be probably to revert my change to run the tests and be > done. However, I'm not sure whetherr this is in the interest of the > users of this package. I'm absolutely not able time-wise to povide > sources and reconstruct all those *.whl files *and* in addition track > down the test suite errors. This is a team package and if the team > decides we should go without testing I can do an according upload. > However, my prefered path would to document the issue of some binary > data properly an test what upstream expects to be tested. i think this is definitely more complicated than you want to take on casually. I don't think it's required to actually rebuild the wheels. If you provide the source, the DFSG is happy. You have to be able to rebuild it, but you aren't required to do it. It might, however, be simpler in the long run to just depend on those packages and build wheels from those (a Debian binary package has enough in it generally to build a wheel from it). I agree it'd be better in the long run to run the tests, but that may be more than you want to take on right now. Scott K signature.asc Description: This is a digitally signed message part.
Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 14, 2023 12:28:30 PM UTC, Andreas Tille wrote: >Control: tags -1 pending > >Hi, > >I've fixed the issue reported in this bug[1]. > >In addition I've took the chance to upload pdm to its latest upstream >version. When doing so I realised that build time tests are basically >ignored. This was mainly due to the removal of artefacts that are used >for testing. I admit I do not see any reason to remove those data >files - in Debian R team this kind of data files which is just used for >testing is accepted. Thus I took the freedom to re-introduce these >files and was running the tests in d/rules. Unfortunately there is >quite a number of tests failing > > 54 failed, 620 passed, 1 xfailed, 3 rerun in 228.94s (0:03:48) > > >(see Salsa CI[2]) > >I'd like to stress that to run those tests at all I needed a patch[3] >since BaseProvider can't be simply imported from findpython. > >Before I upload I'd like to ask for reviewing this patch and opinions >about the test suite errors. While these possibly occure in previous >versions (which I did not tested) we might consider ignoring just the >failing tests. I need to admit that I did not went through the list of >single failures - may be there is a chance of easy fixes for some of >them. I simply wanted to discuss the reintroduction of the artifacts >and my patch first. > With the exception of future_fstrings those are all binary without source. That's a problem. It's probably okay if you add the corresponding source somewhere in the package. I do think it's odd that pdm would need poetry-core in its test suit. Scott K
Re: Naming of python binary packages
On Friday, August 11, 2023 10:49:00 AM EDT Stefano Rivera wrote: > My vote would be strongly towards maintaining the status quo of the > policy-defined names. > > I don't see any strong argument for changing this. Fully agreed. In addition to the reasons you listed, renaming a lot of packages would require a trip through New. I think we have enough backlog there without renaming a bunch of packages for a not very good reason. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043255: RM: pep517 -- ROM; Obsolete, replaced by python-pyproject-hooks
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Python-pyproject-hooks has replaced pep517, so it should be removed once there are no more reverse Build-Depends. Most packages have been updated and bugs have been filed for the three remaining. Scott K
Re: Maintenance of gtts (python3-gtts)
Given the (lack of) maintenance on the package, I am pretty confident we don't have anyone in Debian that really knows it (I am willing to be pleasantly surprised). The gtts upload I did migrated to Testing last night, so I'll leave the rest of it to you. Thanks, Scott K On Monday, August 7, 2023 9:27:05 AM EDT Emmanuel Arias wrote: > Hello Scott, > > I don't use it, but seems an interested project. I can work on it, but > it would be great if you have a maintainer that already know the project. > > Cheers, > Emmanuel > > On Sun, Aug 06, 2023 at 05:23:53PM -0400, Scott Kitterman wrote: > > The gtts package is, at least nominally, maintained by the Debian Python > > Team, but has no human uploader. As a practical matter, I think someone > > should either adopt it (add themselves to uploaders) or we should > > formally orphan the package so we aren't pretending. > > > > It has two rdepends: > > > > Reverse-Depends > > === > > * dialect [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el] > > * mnemosyne > > > > I personally track mnemosyne, even though it's not team maintained, > > because i have an interest in the package. I noticed it was going to be > > removed from Testing because of a FTBFS bug in gtts, so I fixed gtts by > > updating it to the current upstream release. Looking at the upload > > history, it's been this way for awhile. > > > > One consequence of it not being actually maintained is that we released > > bookworm with a non-functional gtts package (see #1030290). If anyone had > > been paying attention to the package, they would have noticed that should > > have been an RC bug (it is now) and it would have either been fixed or > > removed. > > > > The package is now in not awful shape in Unstable (and barring surprises > > Testing later today), but it could still use some work. The major > > immediate task for a potential maintainer would be working with the > > Stable Release Managers to get bookworm fixed. > > > > If you're interested in the package and wiling to watch over it, please > > let me know via email. If I don't hear back, I'll assume no one is > > interested and orphan it in a week or two. > > > > Thanks, > > > > Scott K signature.asc Description: This is a digitally signed message part.
Maintenance of gtts (python3-gtts)
The gtts package is, at least nominally, maintained by the Debian Python Team, but has no human uploader. As a practical matter, I think someone should either adopt it (add themselves to uploaders) or we should formally orphan the package so we aren't pretending. It has two rdepends: Reverse-Depends === * dialect [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el] * mnemosyne I personally track mnemosyne, even though it's not team maintained, because i have an interest in the package. I noticed it was going to be removed from Testing because of a FTBFS bug in gtts, so I fixed gtts by updating it to the current upstream release. Looking at the upload history, it's been this way for awhile. One consequence of it not being actually maintained is that we released bookworm with a non-functional gtts package (see #1030290). If anyone had been paying attention to the package, they would have noticed that should have been an RC bug (it is now) and it would have either been fixed or removed. The package is now in not awful shape in Unstable (and barring surprises Testing later today), but it could still use some work. The major immediate task for a potential maintainer would be working with the Stable Release Managers to get bookworm fixed. If you're interested in the package and wiling to watch over it, please let me know via email. If I don't hear back, I'll assume no one is interested and orphan it in a week or two. Thanks, Scott K signature.asc Description: This is a digitally signed message part.
Re: Updating python-build/getting rid of pep517
On August 2, 2023 1:23:15 PM UTC, "Éric Araujo" wrote: >Le 02/08/2023 à 00:09, Scott Kitterman a écrit : >> * pdm (update to new version, needs pyproject-hooks) >>[pdm-pep517 can probably go away too] > >pdm-pep517 was renamed to pdm-backend, which will still be needed by Python >packages who want to use it as a build backend. (It does not depend on >pyproject-hooks.) > Thanks, Is there anything blocking updating pdm? Scott K
Re: Updating python-build/getting rid of pep517
On August 2, 2023 1:34:32 PM UTC, Scott Talbert wrote: >On Wed, 2 Aug 2023, Scott Kitterman wrote: > >> On Tuesday, August 1, 2023 7:36:38 PM EDT Scott Talbert wrote: >>> On Tue, 1 Aug 2023, Scott Kitterman wrote: >>>>> On Tue, 1 Aug 2023, Scott Kitterman wrote: >>>>>> The pep517 package has been renamed pyproject-hooks upstream: >>>>>> >>>>>> https://github.com/pypa/pyproject-hooks >>>>>> >>>>>> It looks like we need this to update python-build to the latest version >>>>>> (which we should definitely do sooner rather than later). >>>>>> >>>>>> Is anyone up for packaging this? >>>>>> >>>>>> Once it's in the archive we ought to make sure all current users of >>>>>> pep517 >>>>>> are switched so we can remove it this cycle. >>>>> >>>>> I'll go ahead and start packaging it. >>>> >>>> Excellent. PEP517 has a few users that will need to be ported/updated: >>> Initial packaging done, on its way into NEW. >>> >> And it's in Unstable now, so it would be good if people could start updating >> the relevant team packages. I filed #1042869 for the one package not in DPT. >> >> * python-build (update to new version, needs pyproject-hooks) > >I took care of python-build already as a team upload. > >Scott T. Thanks. I just did check-manifest. Scott K
Re: Updating python-build/getting rid of pep517
On Tuesday, August 1, 2023 7:36:38 PM EDT Scott Talbert wrote: > On Tue, 1 Aug 2023, Scott Kitterman wrote: > >> On Tue, 1 Aug 2023, Scott Kitterman wrote: > >>> The pep517 package has been renamed pyproject-hooks upstream: > >>> > >>> https://github.com/pypa/pyproject-hooks > >>> > >>> It looks like we need this to update python-build to the latest version > >>> (which we should definitely do sooner rather than later). > >>> > >>> Is anyone up for packaging this? > >>> > >>> Once it's in the archive we ought to make sure all current users of > >>> pep517 > >>> are switched so we can remove it this cycle. > >> > >> I'll go ahead and start packaging it. > > > > Excellent. PEP517 has a few users that will need to be ported/updated: > Initial packaging done, on its way into NEW. > And it's in Unstable now, so it would be good if people could start updating the relevant team packages. I filed #1042869 for the one package not in DPT. * python-build (update to new version, needs pyproject-hooks) * pdm (update to new version, needs pyproject-hooks) [pdm-pep517 can probably go away too] * poetry-core (update to new version, does use either anymore) * check-manifest (does not list pep517 as a requirement, just drop?) * py7zr (update to new version, does use either anymore) If anyone doesn't have time to update a package for which they are the uploader/maintainer, please reply to the list so someone else can do a team upload. Scott K signature.asc Description: This is a digitally signed message part.
Re: Updating python-build/getting rid of pep517
On Tuesday, August 1, 2023 6:22:26 PM EDT Scott Talbert wrote: > On Tue, 1 Aug 2023, Scott Kitterman wrote: > > The pep517 package has been renamed pyproject-hooks upstream: > > > > https://github.com/pypa/pyproject-hooks > > > > It looks like we need this to update python-build to the latest version > > (which we should definitely do sooner rather than later). > > > > Is anyone up for packaging this? > > > > Once it's in the archive we ought to make sure all current users of pep517 > > are switched so we can remove it this cycle. > > I'll go ahead and start packaging it. Excellent. PEP517 has a few users that will need to be ported/updated: Reverse-Depends === * python3-build (update to new version, needs pyproject-hooks) * python3-pdm (update to new version, needs pyproject-hooks) [pdm-pep517 can probably go away too] Reverse-Testsuite-Triggers == * poetry-core (update to new version, does use either anymore) Reverse-Build-Depends = * check-manifest (does not list pep517 as a requirement, just drop?) * pdm * poetry-core * py7zr (update to new version, does use either anymore) * python-build * sniffles (update to new version, does use either anymore) Looks like no porting will be needed, just updating. With the exception of sniffles, these are all maintained in the Debian Python Team, so this ought to be eminently doable. Scott K signature.asc Description: This is a digitally signed message part.
Updating python-build/getting rid of pep517
The pep517 package has been renamed pyproject-hooks upstream: https://github.com/pypa/pyproject-hooks It looks like we need this to update python-build to the latest version (which we should definitely do sooner rather than later). Is anyone up for packaging this? Once it's in the archive we ought to make sure all current users of pep517 are switched so we can remove it this cycle. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1040556: ITP: aioquic -- Library for the QUIC network protocol in Python
Package: wnpp Severity: wishlist Owner: Scott Kitterman X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: aioquic Version : 0.9.21 Upstream Author : Jeremy Lainé * URL : https://github.com/aiortc/aioquic * License : BSD 3-Clause Programming Lang: Python Description : Library for the QUIC network protocol in Python Library for the QUIC network protocol in Python. It features a minimal TLS 1.3 implementation, a QUIC stack and an HTTP/3 stack. . QUIC was standardised in RFC 9000 and HTTP/3 in RFC 9114. aioquic is regularly tested for interoperability against other QUIC implementations. This is needed as a dependency for dnspython to support DoQ (DNS over QUIC). I intend to maintain this in the Debian Python Team
Bug#1040553: ITP: pylsqpack -- Python wrapper around the ls-qpack library
Package: wnpp Severity: wishlist Owner: Scott Kitterman X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: pylsqpack Version : 0.3.17 Upstream Author : Jeremy Lainé * URL : https://github.com/aiortc/pylsqpack * License : BSD 3-Clause Programming Lang: Python Description : Python wrapper around the ls-qpack library Wrapper around the ls-qpack library. It provides Python Decoder and Encoder objects to read or write HTTP/3 headers compressed with QPACK. This is a dependency for aioquic, which is needed to support DoQ (DNS over QUIC) in dnspython. I intend to maintain this in the Debian Python Team
Moving from appdirs to platformdirs
It would be nice if we could reduce/eliminate use of appdirs during the Trixie development cycle. It's unmaintained and superseded by platformdirs. As far as I can tell, platformdirs is API compatible with appdirs, except the import path is different. As a result, switching does need some changes in the upstream code. This point in the development cycle is a good time to work with upstream to have them make the change upstream. I did this this week with xml2rfc, it was pretty painless, and will be included in the next release. As we approach the freeze, then I think we should shift to working on Debian specific changes. There's a list below of the affected packages (all of them, not just Debian Python packages). I don't intend to do a MBF now, but may do so later in the year (when hopefully the list will be shorter). Scott K Reverse-Testsuite-Triggers == * mu-editor * pyspectral * python-ironicclient * python-mbed-ls * python-openstacksdk * satpy Reverse-Build-Depends = * datalad * defcon * genx * git-phab * glean-parser * intake * mu-editor * nuitka * nvchecker * ofxstatement * ofxstatement-plugins * openlp * openmotor * pako * platformdirs * plover * pyspectral * python-cobra * python-datacache * python-easydev * python-fissix * python-fs * python-lsp-rope * python-mbed-ls * python-requests-cache * python-rply * python-ulmo * pytoolconfig * rope * satpy * snakemake * telegram-send * xml2rfc * yowsup Reverse-Build-Depends-Indep === * pydoctor * python-ironicclient * python-miio * python-openstacksdk * python-os-faults * python-smstrade * subliminal * urlwatch Reverse-Recommends == * python3-profitbricks Reverse-Depends === * crossgrader * git-phab * glean-parser * mu-editor * nuitka * nvchecker * ofxstatement * ofxstatement-plugins * openlp * openmotor * plover * printrun-common * pronsole * ptpython * pydoctor * python3-cobra * python3-datacache * python3-datalad * python3-easydev * python3-etesync * python3-fissix * python3-fs * python3-genx * python3-intake * python3-ironicclient * python3-libpysal * python3-mbed-ls * python3-miio * python3-openstacksdk * python3-os-faults * python3-pako * python3-pantalaimon * python3-pycuda * python3-pyopencl * python3-pyspectral * python3-pytools * python3-requests-cache * python3-rply * python3-satpy * python3-smstrade * python3-subliminal * python3-ulmo * python3-yowsup * snakemake * sqlfluff * telegram-send * urlwatch * xml2rfc signature.asc Description: This is a digitally signed message part.
Future of django-redis-sessions and django-simple-redis-admin
I recently removed myself from the django-reids package uploaders because I no longer have an interest in it. It's still actively maintained by Michael Fladischer (thanks). There are also django-redis-sessions and django-simple-redis-admin. I packaged these for reasons that are no longer relevant for me and intend to either orphan them or have them removed (I haven't decided) at some point in the Trixie cycle. I've removed myself from uploaders in git, so if you are interested in these packages staying in Debian generally and in the Debian Python Team specifically, please add yourself to uploaders and upload away. If you aren't a DD and need a sponsor, I can do that, at least for the initial upload. Scott K signature.asc Description: This is a digitally signed message part.
Re: Python pybuild system & setup.cfg
On Thursday, March 23, 2023 5:07:56 PM EDT Étienne Mollier wrote: > Hi Hilmar, > > Preuße, Hilmar, on 2023-03-23: > > I'm a little bit lost, by building the pssh package. The upstream author > > released a new version, which changed the build system. Before I had a > > setup.py in the root directory, now there is a pyproject.toml and a > > setup.cfg file, the setup.py is gone. The debian/rules file calls the dh > > sequencer: > > > > DESTDIR=debian/tmp > > > > %: > > dh $@ --buildsystem=pybuild > > > > The build fails right at the beginning, with: > > > > dh clean --buildsystem=pybuild > > > >dh_auto_clean -O--buildsystem=pybuild > > > > I: pybuild base:240: python3.11 setup.py clean > > python3.11: can't open file '/<>/setup.py': [Errno 2] No > > such file or directory > > E: pybuild pybuild:388: clean: plugin distutils failed with: exit > > code=2: python3.11 setup.py clean > > > > The content of the pyproject.toml is: > > > > [build-system] > > requires = ["setuptools"] > > build-backend = "setuptools.build_meta" > > > > The build Deps I use until now are: > > > > Build-Depends: debhelper-compat (= 13), > > > > python3, > > python3-setuptools, > > dh-sequence-python3 > > > > I don't know what needs to be changed to convince debhelper to use the > > setup.cfg instead of setup.py. My wild guess is that I have to change my > > BD's but I don't know what needs to be added/removed. > > offpunk upstream made a similar move recently. I added the > following packages to build dependencies: > * flit > * pybuild-plugin-pyproject > > Hope this helps, Since setuptools is the build system identified in pyproject.toml, flit isn't needed for this package. Adding pybuild-plugin-pyproject to build depends should be sufficient. Scott K signature.asc Description: This is a digitally signed message part.
Re: Joining the team! Again with policy acceptance.
On Sunday, March 5, 2023 12:51:59 PM EST Scarlett Moore wrote: > Hi! > My name is Scarlett Moore, I have been working on https://salsa.debian.org/ > mycroftai-team which consists of many python packages relating to voice AI. > Mycroft is no more, but forked. I would like to move these packages to the > python umbrella so as to be useful everywhere and of course consistency, > team maintained. I will of course continue maintaining and not dump them > here, I will also help elsewhere as needed. > I have read and accept > https://salsa.debian.org/python-team/tools/python-modules/blob/master/polic > y.rst My salsa ID is @sgmoore. > Thank you for your consideration, > Scarlett Welcome to the team. Scott K signature.asc Description: This is a digitally signed message part.
Re: Python 3.10 in bookworm
On February 5, 2023 5:22:33 PM UTC, Julian Gilbey wrote: >On Sun, Feb 05, 2023 at 02:41:08PM +, Stefano Rivera wrote: >> Hi Julian (2023.02.05_10:38:23_+) >> >> > Why is the current intention not to ship the python3.10 package in >> > bookworm? >> >> Because we aim to have a single Python release supported in every stable >> release. > >I am not suggesting that we revert to having Python 3.10 as a >"supported version" (that would be a whole separate discussion); I am >suggesting that we keep just the Python 3.10 interpreter and >python3.10-venv in bookworm, so that users can use it to run a virtual >environment if they need to do so. That would narrow the impact, but it's not free either. The interpreter packages often need post-release support from the maintainer and the security team. Someone would also have to triage all the bug reports associated with Debian user expectations for a Python version in Debian not being met. Scott K
Re: Bug#791635 python-policy: Please require namespacing source python module packages
Do we really have to have this argument again? Let's not. Please wontfix and let's move on. Personally, I maintain 25 packages in the team that would need renaming. I'm not sure how many total there are, but they'd all have to go through New again. It'd be much simpler just to drop DPT or myself from uploaders and ignore this, so that's probably the path I would take. Regardless, I don't think this is an appropriate use of FTP Team time/energy. Also, as I've said before on this topic, every packaging rule is a barrier to entry for new contributors. We really shouldn't add things that aren't needed. Scott K On January 29, 2023 12:57:37 AM UTC, Guillem Jover wrote: >Control: reopen -1 >Control: reassign -1 python3 > >[ Sorry, resending, as the bug was archived so it ignored all the > control commands. ] > >This got closed due to the python-defaults package being removed from >sid, reopening and reassigning where python-policy seems to be located >now. > >On Tue, 2022-12-27 at 23:29:30 +, Debian Bug Tracking System wrote: >> Date: Tue, 7 Jul 2015 03:11:06 +0200 >> From: Guillem Jover >> To: sub...@bugs.debian.org >> Subject: python-policy: Please require namespacing source python module >> packages >> Message-ID: <20150707011106.ga12...@gaara.hadrons.org> >> User-Agent: Mutt/1.5.23 (2014-03-12) >> X-Spam-Status: No, score=-6.6 required=4.0 tests=BAYES_00,FROMDEVELOPER, >> RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham autolearn_force=no >> version=3.4.0-bugs.debian.org_2005_01_02 >> >> Source: python-defaults >> Source-Version: 2.7.9-1 >> Severity: wishlist >> >> Hi! >> >> Given recent ITP discussions [0] about lack of namespacing on python >> module source package names, I think it would be really good to fix >> this at the source, by mandating it in the python-policy. Attached is >> a proposal wording. >> >> [0] #748383: ITP: bash8; #745347: ITP: releases; #790399: ITP: structlog >> >> Thanks, >> Guillem > >> === modified file 'debian/python-policy.sgml' >> --- debian/python-policy.sgml2015-02-27 23:09:27 + >> +++ debian/python-policy.sgml2015-07-06 19:58:13 + >> @@ -513,7 +513,9 @@ >>to use this prefix for all packages with public modules as they may >>be used by other packages in the future. Python 3 modules must be >>in a separate binary package prefixed with python3- to >> - preserve run time separation between python and python3. >> + preserve run time separation between python and python3. When the >> + source package only produces python module binary packages, it must >> + also be prefixed with python-. >> >>The binary package for module foo should preferably be named >>python-foo, if the module name >> > >Thanks, >Guillem >
Re: Old generated binary dependencies after renaming psycopg
On January 17, 2023 11:01:45 PM UTC, Tomasz Rybak wrote:
>On Tue, 2023-01-17 at 09:20 +, Julian Gilbey wrote:
>> On Tue, Jan 17, 2023 at 09:08:01AM +0100, Tomasz Rybak wrote:
>> > Hello.
>> > After fixing #1016031 "psycopg3: binary package name should be python3-
>> > psycopg"
>> > (I renamed package names, full changes:
>> > * python3-psycopg3 -> python3-psycopg
>> > * python3-psycopg3-pool -> python3-psycopg-pool
>> > * python-psycopg3-doc -> python3-psycopg-doc)
>> > I tried to rebuild reverse dependencies,
>> > i.e. pgcli and python3-pgspecial.
>> > Rebuild went without problems, new packages are the same
>> > as old ones, but their binary packages still depend on python3-
>> > psycopg3,
>> > even though they build-depend on python3-psycopg.
>>
>> Nope, pgcli does not build-depend on it, rather it explicitly
>> specifies Depends: python3-psycopg3. Likewise, python-pgspecial
>> specifies the same Depends (though it also has a Build-Depends:
>> python3-psycopg3). These packages will need their dependencies
>> updating. (You might also consider making python3-psycopg Provides:
>> python3-psycopg3 and likewise for the other two binary packages for
>> bookworm.)
>>
>
>No, this is not the problem.
>I checked (rebuilt packages with) different variants - with and
>without python3-psycopg[3] as explicit dependency. In all the cases
>dependency for python3-psycopg3 comes from ${python3:Depends}
>via pgcli/debian/pgcli.substvars which contains
>python3:Depends=python3-cli-helpers, python3-click, python3-configobj,
>python3-pendulum, python3-pgspecial, python3-prompt-toolkit, python3-
>psycopg3, python3-pygments, python3-setproctitle, python3-sqlparse (>=
>0.3), python3:any.
>
>When python3-psycopg is in Depends in debian/control, it just gets
>added - so binary package's Depends contains it twice (once
>python3-psycopg3 from ${python3:Depends, once python3-psycopg
>mentioned explicitly; in case of pgcli the second one is versioned).
>
>Sample line from control file for pgcli, which contains both
>python3-psycopg and python3-psycopg3:
>Depends: python3-cli-helpers, python3-pendulum, python3-pgspecial (>=
>2), python3-pkg-resources, python3-prompt-toolkit (>= 3.0), python3-
>psycopg (>= 3.0.14), python3-sqlparse (>= 0.3), python3-tabulate,
>python3-terminaltables, python3-click, python3-configobj, python3-
>psycopg3, python3-pygments, python3-setproctitle, python3:any
>
>I tried to analyze dh_python3, but could not understand where exactly
>fills it in list of (additional) dependencies. They are generated
>somewhere between dh_python3, dhpython/pydist.py,
>and dhpython/depends.py (all files belong to package dh-python
>and are in /usr/share/dh-python).
>
>So - any tips how to fix it would be really helpful.
You'll need to add a py3dist-overrides file in /debian. The details are in the
dh-python or pybuild documentation. I don't recall where.
Scott K
Re: Policy Proposal python3-supported-(min|max) virtual packages
On January 14, 2023 7:51:47 PM UTC, Stefano Rivera wrote: >Hi Scott (2023.01.14_19:34:59_+) >> >dh_python3 would have been able to generate >> >python3-tomli | python3-min-version (>= 3.11) >> > >> >instead of >> >python3-tomli | python3 (>> 3.11) >> > >> >Then, once python3.10 was dropped from supported, python3 would >> >Provides: python3-min-version (= 3.11), python3-max-version (= 3.11) >> >> And python3-min-version is a virtual package, so dpgk doesn't need any >> special knowledge to do the right thing, right? I think that's reasonable. > >Yeah. > >> Typically though doesn't the python interpreter package provide modules that >> are now incorporated? If python3.11 provides python3-tomli, won't that mess >> this up? > >I can't recall how this was done historically, but the git history of >python3 and python3-defaults doesn't show any provides like that. The >only one I can see is python3-profiler, which is provided by python3, >not python3.X. > Thanks for checking. I definitely recall it for Python2, but if it's not a Python3 thing, then I think it's good. It would probably be beneficial to have the policy statement have a MUST NOT to say not to do it in the future as that would break this. Scott K
Re: Policy Proposal python3-supported-(min|max) virtual packages
On January 14, 2023 7:12:33 PM UTC, Stefano Rivera wrote: >Hi Scott (2023.01.14_17:22:42_+) >> Take the example in #1027947. If this proposal had been in place >> already, what would he have been the generated dependency and how >> would it have worked? > >dh_python3 would have been able to generate >python3-tomli | python3-min-version (>= 3.11) > >instead of >python3-tomli | python3 (>> 3.11) > >Then, once python3.10 was dropped from supported, python3 would >Provides: python3-min-version (= 3.11), python3-max-version (= 3.11) > >The >= vs >> isn't particularly relevant here. At the moment python3 (>> 3.11) >effectively means >= 3.11, because it's always 3.11.something-something. And python3-min-version is a virtual package, so dpgk doesn't need any special knowledge to do the right thing, right? I think that's reasonable. Typically though doesn't the python interpreter package provide modules that are now incorporated? If python3.11 provides python3-tomli, won't that mess this up? Scott K
Re: Policy Proposal python3-supported-(min|max) virtual packages
On January 14, 2023 5:08:17 PM UTC, Stefano Rivera wrote: >I have proposed a policy change that would permit dh_python3 to generate >dependencies that apply to all currently-supported Python 3 versions: > >https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/13 > >Please review it and give me feedback. > >Matthias: I'm CCing you, because you had concerns when I mentioned this >on IRC. But I hadn't provided a clear description of what I was >proposing. Does this sound like something that works? I read it. I'm not sure I understand how it would work. Take the example in #1027947. If this proposal had been in place already, what would he have been the generated dependency and how would it have worked? Scott K
Re: python-avro: FTBFS: AssertionError: 'reader type: null not compatible with writer type: int' not found in {'reader type: SchemaType.NULL not compatible with writer type: SchemaType.INT'}
On Thursday, December 29, 2022 4:13:20 PM EST Andreas Tille wrote:
> Control: tags -1 help
>
> Hi,
>
> I wonder whether someone might suggest a fix for
>
>
> ==
> FAIL: test_schema_compatibility_type_mismatch
> (avro.test.test_compatibility.TestCompatibility.test_schema_compatibility_t
> ype_mismatch)
> --
> Traceback (most recent call last):
> File
> "/build/python-avro-1.11.1+dfsg/.pybuild/cpython3_3.11_avro/build/avro/test
> /test_compatibility.py", line 1039, in
> test_schema_compatibility_type_mismatch self.assertIn(message,
> result.messages)
> AssertionError: 'reader type: null not compatible with writer type: int' not
> found in {'reader type: SchemaType.NULL not compatible with writer type:
> SchemaType.INT'}
>
> --
> Ran 421 tests in 8.358s
>
> FAILED (failures=1, skipped=3)
>
>
> Otherwise I will probably exclude Python3.11 from the build to fix this bug.
That's not an actual solution. If you close the bug on this basis it will
hide the issue and make it appear we are more ready to move to Python 3.11 as
the default (and probably only) Python version for Bookworm.
I didn't look at the actual code. Typically when something comes up Null is
means that something was not found. I would look at the code where SchemaType
is determined to see how it might come up with no SchemaType.
Scott K
signature.asc
Description: This is a digitally signed message part.
Re: How do you create entry-points for Python applications?
On December 19, 2022 6:27:55 AM UTC, c.bu...@posteo.jp wrote: >Dear Scott, > >thanks for the reply. > >Am 19.12.2022 06:25 schrieb Scott Kitterman: >> Pybuild using the pyproject plugin will build a wheel and >> then install the necessary files in the package using the installer >> module. The entry point scripts are in the wheel, just like an >> upstream built wheel. > >Do I get that correct? >The entry scripts (their content and their location) is the same installing a >package via pip and apt? > >In that case I'm right trying to make the "pip install" process as correct as >possible to save resources for the distro maintainers. There are exceptions, but generally that is correct. >> Your best bet is to find a package in the archive that's similar and >> see how it was done. > >That is why I'm asking here. ;) Hopefully someone will chime in with a good example. The only package I maintain that I can think of at the moment with entrypoints and project.toml is too complicated to be a good example. Scott K
Re: How do you create entry-points for Python applications?
On December 19, 2022 5:13:27 AM UTC, c.bu...@posteo.jp wrote: >Am 18.12.2022 23:03 schrieb Danial Behzadi دانیال بهزادی: >> AFAIK Debian helper for Python handles this > >;) Yes, but how? > >Does it ignore the pip-default-entry-point-scripts? Does it create its own >script? >Do you have to explicit write a script? You don't. Pybuild using the pyproject plugin will build a wheel and then install the necessary files in the package using the installer module. The entry point scripts are in the wheel, just like an upstream built wheel. Your best bet is to find a package in the archive that's similar and see how it was done. Scott K
Re: python-tesserocr: flaky autopkgtest
On December 18, 2022 4:47:39 PM UTC, Scott Talbert wrote: >On Sun, 18 Dec 2022, Malik Mlitat wrote: > >> >> Hello DPT, >> >> I have updated the package python-tesserocr [1] to skip the flaky test to >> fix the issue below. >> >> I need a maintainer please to upload the new release version 2.5.2-2 to >> the Debian archive. >> >> >> [1] https://salsa.debian.org/python-team/packages/python-tesserocr > >Uploaded. But the ftp-master server is down, so it's unclear when that will >be fixed (and hopefully the uploads that are occurring now will be processed?). They will. The upload queue lives on another box and uploads will stay there and be processed for accept once Fasolo is back. Scott K
Re: on the lack of a `python-` prefix for source packages
On December 12, 2022 2:43:48 AM UTC, Sandro Tosi wrote: >> >> My proposal as stated at the top is to start from now on to prepend >> >> `python` to all NEW source packages in DPT, with the option to rename >> >> existing packages at a later date. >> >> >> >> What are other team members' opinions on this? >> > >> > For packages that on contain a python module/extension, I think it's not >> > horrible, but I don't see why it's better to diverge from upstream naming. >> >> I tend to agree with Sandro on for this use case. > >True, i was mostly referring to modules, as that's the most numerous >type of packages we have > >> > For packages that contain or are primarily applications, I don't think >> > it's a good idea. >> >> Ditto on that one, I don't feel having "python-supysonic" would be a >> good naming scheme... > >please note that would be just for source packages, the user-facing >ones can still be `supysonic` as that's what you expect to install > >On Sun, Dec 11, 2022 at 8:53 PM Scott Kitterman wrote: >> What problem are you trying to solve? > >no problem specifically, i just feel that having a consistent scheme >would benefit Debian and then team. If it's a case where multiple languages would likely have a package with similar naming, I can see it's a good thing to be clear. When we already don't use the same name as upstream in the binary (what upstream has python3- in the package name?), I think there's value in using the exact upstream name for the source package. As an example, I maintain dkimpy (also the upstream name) which has the python3-dkim binary package. If this were a new package that would follow your proposed rule, what would the source package be named? If it's python-dkim, that would follow your proposal, but a new user that knew the upstream name would find nothing if they searched for it. Python-dkimpy would solve that, but seems redundant. I don't see how having an additional rule is helpful. I think every rule we add makes it more complicated for new contributors, so we should be careful to avoid adding new ones without good reason (and it wouldn't hurt to revisit old ones and ditch things that have outlived their usefulness). Scott K
Re: on the lack of a `python-` prefix for source packages
On December 12, 2022 1:24:35 AM UTC, Sandro Tosi wrote: >Proposal: the DPT will start adding a `python-` prefix to NEW source >packages names, unless the upstream project already contains it > >AFAICT all other major languages ecosystems packaging teams use a >(semi?)mandatory tag to identify their source packages (results below >from a very quick look at Sources, top results only): > >prefix: golang, rust, r, node, ruby, haskell, php, ocaml, python (on a >voluntary basis), and others >prefix+suffix: perl > >At the beginning, I remember being in favor of the current status quo >in DPT, where each maintainer can choose to add `python-` if they feel >like it, or just use the upstream name. > >Thru the years, i've grown more uncomfortable with this situation and >i think the fact we dont mandate a `python` prefix in the team source >packages names (and thus guiding the rest of the python packagers >within Debian towards a common style) is detrimental to Debian as a >whole, and we should change it. > >My proposal as stated at the top is to start from now on to prepend >`python` to all NEW source packages in DPT, with the option to rename >existing packages at a later date. > >What are other team members' opinions on this? For packages that on contain a python module/extension, I think it's not horrible, but I don't see why it's better to diverge from upstream naming. For packages that contain or are primarily applications, I don't think it's a good idea. What problem are you trying to solve? Scott K
Re: Different behavior of package with pyproject.toml
On December 4, 2022 3:42:15 PM UTC, Ole Streicher wrote: >Hi Scott, > >thanks for the hint. > >Scott Kitterman writes: >> My first guess is that in some circumstances setuptools is doing the >> installing >> and in others it's the dh-python pyproject plugin (using the installer >> module). Looking at the build log on buildd.d.o, I can see that build is >> using the plugin/installer. >> >> I think it would be useful to stop the build right before the install step >> starts [1], manually unpack the wheel (it's a zip file) and see if it has >> all >> the files in it. If it does, then plugin/build is doing the right thing and >> it's an issue with either the plugin or the installer module. > >I couldn't manage this; however when looking into the log, I see > >-8<- > dh_auto_build -O--buildsystem=pybuild >I: pybuild plugin_pyproject:107: Building wheel for python3.11 with "build" >module >I: pybuild base:240: python3.11 -m build --skip-dependency-check >--no-isolation --wheel --outdir >/builds/debian-astro-team/asdf-astropy/debian/output/source_dir/.pybuild/cpython3_3.11 > >/usr/lib/python3/dist-packages/setuptools/config/pyprojecttoml.py:108: >_BetaConfiguration: Support for `[tool.setuptools]` in `pyproject.toml` is >still *beta*. > warnings.warn(msg, _BetaConfiguration) >running bdist_wheel >running build >running build_py >creating build >creating build/lib >creating build/lib/asdf_astropy >copying asdf_astropy/_version.py -> build/lib/asdf_astropy >[... no asdf_astropy/io files here ...] >* Building wheel... >Successfully built asdf_astropy-0.3.0-py3-none-any.whl >I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.11 with >"installer" module >-8<- > >So I would suspect that it is already the build does something wrong >here. Which package is that? pybuild-plugin-pyproject? python3-installer Scott K
Re: Different behavior of package with pyproject.toml
On Saturday, December 3, 2022 11:19:06 AM EST Ole Streicher wrote: > Hi, > > I need some help with a package that switched to using pyproject.toml > only. The package is asdf-astropy, and the problem I have that it does > not package all Python files recursively: for example astropy_asdf.io > files are missing (as seen in unstable now). > > https://tracker.debian.org/pkg/asdf-astropy > https://salsa.debian.org/debian-astro-team/asdf-astropy > > What I do not understand is that this happens "sometimes": > > * when I build the package in a clean schroot with "debuild", files in > subpackages are missing (but no error message in the log) > > * when I install git, then a debuild results in a complete package > > * when I cut the command from the build log [1], the copy process > always happens completely, independent of whether git was installed or > not > > * when I use pbuilder, files of subpackages are never package, with our > without git in the build dependencies > > [1] python3.11 -m build --skip-dependency-check --no-isolation --wheel > --outdir .pybuild/cpython3_3.11 > > Since the package "sometimes" is built correctly, I think that upstream > did it right; however I have no idea where the problem could be. Does > anyone have an idea? My first guess is that in some circumstances setuptools is doing the installing and in others it's the dh-python pyproject plugin (using the installer module). Looking at the build log on buildd.d.o, I can see that build is using the plugin/installer. I think it would be useful to stop the build right before the install step starts [1], manually unpack the wheel (it's a zip file) and see if it has all the files in it. If it does, then plugin/build is doing the right thing and it's an issue with either the plugin or the installer module. Since the build stage uses setuptools as part of it's build process, I thing it's most likely an installer issue. I recently found the installer module doesn't correctly handle flit data files, but I was able to work around that with appropriate .install files. Scott K [1] pybuild plugin_pyproject:118: Unpacking wheel built for python3.10 with "installer" module signature.asc Description: This is a digitally signed message part.
Re: Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too
On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote: > Hi Scott, > > On 01/12/2022 02:16, Scott Kitterman wrote: > > Package: lintian > > Version: 2.115.3 > > Severity: normal > > X-Debbugs-Cc: debian-python@lists.debian.org > > > > The missing-prerequisite-for-pyproject-backend check appears to only > > look for the prerequisite packages in Build-Depends, but since they > > aren't needed for clean, they could be in Build-Depends-Indep, leading > > to false positives. > > > > Scott K > > I contemplated filing a similar the other day but in writing it up, I > realised that lintian was correct. Policy requires that the 'clean' > target be functional with only the Build-Depends (and Build-Conflicts) > satisfied, and pybuild + the build-backend dependencies are involved in > the cleaning step. Not always. At least with the package I ran into this on, clean works fine without them. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too
Package: lintian Version: 2.115.3 Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org The missing-prerequisite-for-pyproject-backend check appears to only look for the prerequisite packages in Build-Depends, but since they aren't needed for clean, they could be in Build-Depends-Indep, leading to false positives. Scott K
Re: How to deal with cross-dependant packages
On November 28, 2022 4:51:23 PM UTC, Andreas Tille wrote: >Hi, > >I'd like to update python-thinc for the Debian Science team. The new >version needs srsly which needs catalogue[1] which in turn needs >srsly[2]. Do you see any means to solve this cross-dependency? > >Kind regards > Andreas. > >[1] >https://salsa.debian.org/python-team/packages/python-srsly/-/blob/master/requirements.txt >[2] >https://salsa.debian.org/python-team/packages/python-catalogue/-/blob/master/requirements.txt Your initial build for upload to new is done locally. Build them both locally and upload to New at the same time. Once they are in the archive, those binaries are available to do the second build on the buildds. At that point it's all bootstrapped and should be fine. Scott K
Re: Python 3.11, bytecode and new internals
On Monday, November 21, 2022 12:25:05 PM EST Scott Kitterman wrote: > On November 21, 2022 5:02:57 PM UTC, "Louis-Philippe Véronneau" wrote: > >On 2022-11-21 02 h 08, Julian Gilbey wrote: > >> I'm just flagging this up here, with a question about how we should > >> proceed. Certainly we are not ready to make Python 3.11 the default > >> Python version!! > > > >This is a concern I share and I think I've been pretty vocal about it. > > > >I feel the state of python packages for Bookworm with 3.10 was pretty good > >and it seemed reasonable to prioritize stability for our next stable > >release :) > > > >It's very frustrating to work on packaging python libraries and apps for a > >whole release cycle, just to see all that work put in the bin at the last > >minute because upstream doesn't support 3.11... > > > >I've been told the current 3.11 transition was a test, and if it was clear > >too many important things were broken and couldn't be fixed, we would roll > >back and release using 3.10. > Looks like you can add #1024521 to the list. This one is fixed. Scott K signature.asc Description: This is a digitally signed message part.
Re: Python 3.11, bytecode and new internals
On November 21, 2022 5:02:57 PM UTC, "Louis-Philippe Véronneau" wrote: >On 2022-11-21 02 h 08, Julian Gilbey wrote: >> I'm just flagging this up here, with a question about how we should >> proceed. Certainly we are not ready to make Python 3.11 the default >> Python version!! > >This is a concern I share and I think I've been pretty vocal about it. > >I feel the state of python packages for Bookworm with 3.10 was pretty good and >it seemed reasonable to prioritize stability for our next stable release :) > >It's very frustrating to work on packaging python libraries and apps for a >whole release cycle, just to see all that work put in the bin at the last >minute because upstream doesn't support 3.11... > >I've been told the current 3.11 transition was a test, and if it was clear too >many important things were broken and couldn't be fixed, we would roll back >and release using 3.10. > Looks like you can add #1024521 to the list. Scott K
Re: pyyaml 6
On Wednesday, November 2, 2022 5:26:35 AM EST Scott Kitterman wrote: > On November 2, 2022 8:35:35 AM UTC, Gordon Ball wrote: > >On 19/10/2022 22:30, Gordon Ball wrote: > >> On 09/10/2022 21:39, Gordon Ball wrote: > >>> On 07/10/2022 01:13, Timo Röhling wrote: > >>>> Hi Gordon, > >>>> > >>>> * Gordon Ball [2022-10-07 00:10]: > >>>>> * Upload to unstable and see what breaks? > >>>>> * Request an archive rebuild with this version and see what breaks? > >>>>> * File bugs against all likely affected packages with a fixed date for > >>>>> an upload? > >>>>> * Wait until after the freeze? > >>>> > >>>> Considering that PyYAML has been issuing a YAMLLoadWarning since > >>>> version 5.1 (i.e. September 2019), I would expect that many (most?) > >>>> reverse dependencies have been fixed, and anything that still breaks > >>>> is probably in dire need of maintenance anyway. > >>> > >>> Yes, that's a good point. > >>> > >>> I've done some more investigation of reverse-depends and looking for > >>> likely bad patterns with codesearch.d.n, and the set of packages which > >>> A) appear to contain plain `yaml.load(f)` or equivalent, where `yaml` is > >>> pyyaml and B) actually depend or build-depend on `python3-yaml` is > >>> smaller than I feared. This is what I came up with: > >>> > >>> ``` > >>> ansible # confirm - in ansible_collections/community/general/plugins > >>> buildbot # confirm - in porttostable > >>> ceph # confirm, in civetweb/third_party/duktape, src/test/crimson > >>> docker-compose # confirm, in tests > >>> dose3 # confirm, in scripts > >>> elasticsearch-curator # confirm, in test/unit > >>> etm # confirm, in etmTk/data > >>> ganeti # confirm, in qa, test/py > >>> gnocchi # confirm, in gnocchi/gendoc > >>> gr-dab # confirm, in python/app > >>> jeepyb # confirm, in cmd/notify_impact > >>> knitpy # confirm, in knitpy > >>> labgrid # confirm, in remote/coordinator > >>> lecm # confirm, in lecm/configuration > >>> lirc # confirm, in lirc/database > >>> lqa # confirm, in lqa_api/job > >>> open-adventure # confirm, in tests > >>> owslib # confirm, in ogcapi > >>> policyd-rate-limit # confirm, in config, tests > >>> python-aptly # confirm, in publisher > >>> python-canmatrix # confirm, in canmatrix/formats/yaml > >>> python-multipart # confirm, in multipart/tests > >>> python-pybedtools # confirm, in test, contrib > >>> python-seqcluster # confirm, in install > >>> python-tempestconf # confirm, in config_tempest/profile > >>> qcat # confirm, in adapters > >>> qcengine # confirm, in config > >>> refstack-client # confirm, in refstack_client > >>> relatorio # confirm, in templates/chart > >>> ripe-atlas-tools # confirm, in tools/settings > >>> ros-genpy # confirm, in test > >>> ros-rosinstall # confirm, in test, src/rosinstall > >>> ros-rosinstall-generator # confirm, in test, src/rosinstall_generator > >>> spades # confirm, in assembler/src/test/teamcity, > >>> assembler/src/projects/mts, assembler/src/spades_pipeline > >>> xrstools # confirm, in WIZARD > >>> zlmdb # confirm, in _database > >>> ``` > >>> > >>> I don't know if all these codepaths are actually ever reached, or tests > >>> ever run, so the packages won't necessarily break (or the breakage is > >>> very minor, such as a single community plugin in ansible). I don't > >>> guarantee there are no omissions from the list though. > >>> > >>> There is a significantly longer list of packages which appear to contain > >>> a use of yaml.load _somewhere_, but it is usually in some > >>> maintainer/release script, or an optional path somewhere, and the > >>> package itself doesn't [build-]depend on python3-yaml. > >> > >> I've filed bugs for (most) of the packages listed above (some were > >> dropped on review because they weren't in main, or the affected file > >> appeared to be unused at build time and not installed). I've had a > >> couple of acknowledgements/fixes already. > >> > >> A number of affected package look very sparsely used and/or maintained, >
Re: pyyaml 6
On November 2, 2022 8:35:35 AM UTC, Gordon Ball wrote: >On 19/10/2022 22:30, Gordon Ball wrote: >> On 09/10/2022 21:39, Gordon Ball wrote: >>> On 07/10/2022 01:13, Timo Röhling wrote: Hi Gordon, * Gordon Ball [2022-10-07 00:10]: > * Upload to unstable and see what breaks? > * Request an archive rebuild with this version and see what breaks? > * File bugs against all likely affected packages with a fixed date for > an upload? > * Wait until after the freeze? Considering that PyYAML has been issuing a YAMLLoadWarning since version 5.1 (i.e. September 2019), I would expect that many (most?) reverse dependencies have been fixed, and anything that still breaks is probably in dire need of maintenance anyway. >>> >>> Yes, that's a good point. >>> >>> I've done some more investigation of reverse-depends and looking for >>> likely bad patterns with codesearch.d.n, and the set of packages which >>> A) appear to contain plain `yaml.load(f)` or equivalent, where `yaml` is >>> pyyaml and B) actually depend or build-depend on `python3-yaml` is >>> smaller than I feared. This is what I came up with: >>> >>> ``` >>> ansible # confirm - in ansible_collections/community/general/plugins >>> buildbot # confirm - in porttostable >>> ceph # confirm, in civetweb/third_party/duktape, src/test/crimson >>> docker-compose # confirm, in tests >>> dose3 # confirm, in scripts >>> elasticsearch-curator # confirm, in test/unit >>> etm # confirm, in etmTk/data >>> ganeti # confirm, in qa, test/py >>> gnocchi # confirm, in gnocchi/gendoc >>> gr-dab # confirm, in python/app >>> jeepyb # confirm, in cmd/notify_impact >>> knitpy # confirm, in knitpy >>> labgrid # confirm, in remote/coordinator >>> lecm # confirm, in lecm/configuration >>> lirc # confirm, in lirc/database >>> lqa # confirm, in lqa_api/job >>> open-adventure # confirm, in tests >>> owslib # confirm, in ogcapi >>> policyd-rate-limit # confirm, in config, tests >>> python-aptly # confirm, in publisher >>> python-canmatrix # confirm, in canmatrix/formats/yaml >>> python-multipart # confirm, in multipart/tests >>> python-pybedtools # confirm, in test, contrib >>> python-seqcluster # confirm, in install >>> python-tempestconf # confirm, in config_tempest/profile >>> qcat # confirm, in adapters >>> qcengine # confirm, in config >>> refstack-client # confirm, in refstack_client >>> relatorio # confirm, in templates/chart >>> ripe-atlas-tools # confirm, in tools/settings >>> ros-genpy # confirm, in test >>> ros-rosinstall # confirm, in test, src/rosinstall >>> ros-rosinstall-generator # confirm, in test, src/rosinstall_generator >>> spades # confirm, in assembler/src/test/teamcity, >>> assembler/src/projects/mts, assembler/src/spades_pipeline >>> xrstools # confirm, in WIZARD >>> zlmdb # confirm, in _database >>> ``` >>> >>> I don't know if all these codepaths are actually ever reached, or tests >>> ever run, so the packages won't necessarily break (or the breakage is >>> very minor, such as a single community plugin in ansible). I don't >>> guarantee there are no omissions from the list though. >>> >>> There is a significantly longer list of packages which appear to contain >>> a use of yaml.load _somewhere_, but it is usually in some >>> maintainer/release script, or an optional path somewhere, and the >>> package itself doesn't [build-]depend on python3-yaml. >>> >> >> I've filed bugs for (most) of the packages listed above (some were dropped >> on review because they weren't in main, or the affected file appeared to be >> unused at build time and not installed). I've had a couple of >> acknowledgements/fixes already. >> >> A number of affected package look very sparsely used and/or maintained, and >> I doubt are likely to be fixed. However, of the packages above, only two >> have autopkgtests which fail on experimental migration, so I wouldn't be >> surprised if some are not already broken by other past changes. >> >> I propose to wait ~2 weeks until the beginning of November and upload pyyaml >> 6 to unstable then. >> > >pyyaml 6 has now landed in unstable. About half the bugs I filed have been >resolved, and there is only one package (ganeti) with autopkgtests blocking >migration. > There were two more, but I retried the migration reference jobs and they failed (which makes them no longer block since they are no longer a regression). Ganeti can't currently be fixed since it's unbuildable. It's only due to an archive hiccup that it's even in Testing. I was planning on asking the Release Team to ignore it, so pyyaml can transition (worst case it's stuck until ganeti gets removed from Testing in a week and a half). Scott K
Bug#1023299: ganeti-testsuite: yaml.load in testsuite needs to specify loader
Source: ganeti-testsuite Version: 3.0.2-1 Severity: serious Tags: upstream ftbfs Justification: fails to build from source X-Debbugs-Cc: debian-python@lists.debian.org Previously yaml.load did not require a loader to be specified: load(stream, Loader=None) Now it does (starting in pyyaml 6.0): load(stream, Loader) Ganeti-testsuit uses yaml.load without specifying a loader, which now causes a test failure in unstable. Due to ganeti not being buildable currently, it's not possible to fix this at the moment. Note: Using FTBFS as a tag since that's the closest thing we have to a test failure that would prevent migration. Scott K
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 3:31:47 PM EDT PICCA Frederic-Emmanuel wrote: > > I dont think it should do that, so we need to investigate. Where > > can I find the updated packaging? > > I did not push the change right now, I will push once I solve this issue :). > > my opinion is that I should force via PYBUILD_SYSTEM=distutils > > Fred If that works, I think it's fine, but I don't think it should be necessary. Let me know once you push the package and I'll see if there's a pybuild issue. Scott K signature.asc Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 3:02:00 PM EDT PICCA Frederic-Emmanuel wrote: > >It looks to me like the current pyproject.toml file for pyfai is not > >sufficient> > > to build the package, so I would tempted to keep what you have now. > > Due to the presence of this file, pybuild try to build using the "new way" > instead of building with setup.py. > > I do not know if other package are in this state, but if produce an FTBFS. > > Cheers I don't think it should do that, so we need to investigate. Where can I find the updated packaging? Scott K signature.asc Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 2:48:12 PM EDT Scott Kitterman wrote: > On Tuesday, November 1, 2022 2:42:22 PM EDT PICCA Frederic-Emmanuel wrote: > > > As far as I can see, the package doesnt ship any files in > > > /usr/bin. > > > Why do you need to build man pages (Im assuming thats what > > > thats for? More generically, what problem did that step in the > > > process solve thats not solved now? > > > > this is for the pyfai package which I need to update > > > > https://salsa.debian.org/science-team/pyfai > > I see. I was confused by the subject saying this was about xrayutilities > still. I'll have a look. > > Scott K It looks to me like the current pyproject.toml file for pyfai is not sufficient to build the package, so I would tempted to keep what you have now. For another package (weasyprint) where I have to build the man page from Sphinx documentation myself, I use this to build it: override_dh_installman: PYTHONPATH=.:$PYTHONPATH sphinx-build -b man docs debian dh_installman Then weasyprint.manpages has: debian/weasyprint.1 Their build_man command has a lot of moving parts, so pyfai may br more complicated. AScott K signature.asc Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 2:42:22 PM EDT PICCA Frederic-Emmanuel wrote: > > As far as I can see, the package doesnt ship any files in /usr/bin. > > Why do you need to build man pages (Im assuming thats what > > thats for? More generically, what problem did that step in the > > process solve thats not solved now? > > this is for the pyfai package which I need to update > > https://salsa.debian.org/science-team/pyfai I see. I was confused by the subject saying this was about xrayutilities still. I'll have a look. Scott K signature.asc Description: This is a digitally signed message part.
Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 11:15:59 AM EDT PICCA Frederic-Emmanuel wrote:
> thanks for your help.
>
> I have one more question
>
> I have this command from the previous build
>
> {interpreter} setup.py build_man
>
> how can I translate this with the new build systeme ?
As far as I can see, the package doesn't ship any files in /usr/bin. Why do
you need to build man pages (I'm assuming that's what that's for? More
generically, what problem did that step in the process solve that's not solved
now?
Scott K
signature.asc
Description: This is a digitally signed message part.
Bug#1023211: RM: dirtbike -- ROM; Obsolete, no longer used for any Debian Python packages
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org We used to use this back when we debundled pip's embedded dependencies. We don't do that anymore (no longer supported upstream), so dirtbike is not needed. It is unmaintained upstream and likely to be a problem over time since its design is inherently fragile. Scott K
Re: build package xrayutilities - wheel and pip with setuptools
On Monday, October 31, 2022 1:26:03 PM EDT Carsten Schoenert wrote: > Hello Frederic, > > Am 31.10.22 um 08:57 schrieb PICCA Frederic-Emmanuel: > >> I can build the package basically doing these modifications and by > >> adding the additional B-D package Scott did mention. Simply let > >> dh_sphinxdoc build the documentation and adding the additional needed > >> package dependencies. > > > > [your patch] > > > > In your proposition you removed the arch/indep split, is it on purpose ? > > yes, building the Sphinx based documentation doesn't need to be done > that (to me fragile) way. debhelper is smart enough to do the right > things in the correct order if you tell it to use the sphinxdoc module. Agreed. More generally, use of setup.py is being deprecated in favor of the pyproject.toml based interface with the various Python build systems (including setuptools). The approach Carsten is recommending is recommending is not only more robust, it is more future proof. At some point your upstream will probably stop including the setup.py and you don't want to depend on it if you don't need to (and you don't). Scott K signature.asc Description: This is a digitally signed message part.
Re: wheel and pip with setuptools
On October 29, 2022 10:07:13 PM UTC, picca wrote:
>Hello, I try to fix an FTBFS in the python-xrayutilities package.
>When I try to build it, I get this error message., I do not understand why I
>need to add a build dependency to python3-wheel.Is it something missing in the
>dependency of python3-setuptools or python3.10 ?
>
>thanks for your help
>
>Frederic
>
>
>
>dh clean --buildsystem=pybuild
>dh_auto_clean -O--buildsystem=pybuild
>install -d /<>/debian/.debhelper/generated/_source/home
>pybuild --clean -i python{version} -p 3.10
>I: pybuild base:240: python3.10 setup.py clean
>/usr/lib/python3/dist-packages/setuptools/installer.py:27:
>SetuptoolsDeprecationWarning: setuptools.installer is deprecated. Requirements
>should be satisfied by a PEP 517 installer.
>warnings.warn(
>WARNING: The wheel package is not available.
>/usr/bin/python3.10: No module named pip
>Traceback (most recent call last):
>File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 82, in
>fetch_build_egg
>subprocess.check_call(cmd)
>File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
>raise CalledProcessError(retcode, cmd)
>subprocess.CalledProcessError: Command '['/usr/bin/python3.10', '-m', 'pip',
>'--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpq9o0m_9e',
>'--quiet', 'h5py']' returned non-zero exit status 1.The above exception was
>the direct cause of the following exception:
>
Adding pybuild-plugin-pyproject to build-depends should solve it. It looks
like it is trying to do the new pyproject.toml style build without all the
necessary parts in place.
Scott K
Bug#1021964: ITP: python-noseofyeti -- Module to create Python codec for tests using RSpec inspired DSL
Package: wnpp Severity: wishlist Owner: Scott Kitterman X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-noseofyeti Version : 2.3.1 Upstream Author : Stephen Moore * URL : https://github.com/delfick/nose-of-yeti * License : MIT Programming Lang: Python Description : Module to create Python codec for tests using RSpec inspired DSL This is a project creates a custom Python codec that lets you write your tests using an RSpec inspired DSL (i.e. describe and it blocks). . It uses the fact that you can register a codec that is able to modify a Python file before executing it. Using this when Python imports a file with a particular encoding as the first line of the file it will be intercepted and potentially rewritten into something else before the import continues. . nose-of-yeti uses this technique to translate from the DSL it defines, into Python classes and functions that then will be executed by your test framework of choice. I plan to maintain this package as part of the Debian Python team. It is needed to run the tests for python-dict2xml, which are now provided in the upstream tarball.
Re: pybuild-autopkgtest (was: Notes from the DC22 Python Team BoF)
On July 26, 2022 2:50:19 PM UTC, Antonio Terceiro wrote: >On Mon, Jul 25, 2022 at 09:04:27AM +0100, Julian Gilbey wrote: >> On Sat, Jul 23, 2022 at 07:52:19PM +0200, Louis-Philippe Véronneau wrote: >> > == pybuild improvements == >> > >> > getting the autopkgtest MR in would be great >> > >> > https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27 >> > >> > We need people to test this MR some more, although it seems fairly mature. >> > >> > It might be a good idea to have a line in d/control to let us migrate from >> > the existing autopkgtests running unit tests to the new automated MR. >> >> I've been looking at this a bit more. I'm not sure what this last >> paragraph means: the new "automated" autopkgtest will only be run if >> the maintainer explicitly adds: >> >> Testsuite: autopkgtest-pkg-pybuild >> >> to debian/control (see the autodep8 MR at >> https://salsa.debian.org/ci-team/autodep8/-/merge_requests/27/diffs - >> it will never automatically detect a pybuild package). >> And a maintainer would presumably only add that if they are also >> removing their existing debian/tests/control (or want to run the >> pybuild tests in addition). >> >> An alternative would be for the autodep8 patch to try to determine >> whether to run pybuild-autopkgtest. One approach could be: >> >> if the package would run autopkgtest-pkg-python: >> if debian/control does not contain an override_dh_auto_test stanza: >> run pybuild-autopkgtest >> >> Note, though, that if autodep8 is called, it will run all of the >> detected tests. (At least that is what I believe happens from reading >> /usr/bin/autodep8; I haven't double-checked this.) So, for example, >> if a package specifies >> >> Testsuite: autopkgtest-pkg-python >> >> it will also run the autopkgtest-pkg-pybuild suite as it will be >> detected as being a Python package, and vice versa. That is a >> possible reason *not* to use the above suggestion, as it would >> potentially run pybuild-autopkgtest even if not desired. > >I think the notes did not capture the consensus correctly. The point was >that it should be possible to automate updating the `Testsuite:` field >to run tests with pybuild-autopkgtest, and that we should probably do >that across team packages with the help of some scripting. I suppose this is fine as long as whoever does it fixes all the resulting RC bugs. Scott K
Re: Help for python-subby needed
On Tuesday, February 1, 2022 6:01:22 AM EST Andreas Tille wrote:
> Am Sat, Jan 29, 2022 at 01:50:22AM +0500 schrieb Andrey Rahmatullin:
> > On Fri, Jan 28, 2022 at 09:48:00PM +0100, Andreas Tille wrote:
> > > Hi,
> > >
> > > I need python-subby as a new dependency for some Debian Med package.
> > >
> > > Unfortunately it does not build easily[1]:
> > >dh_auto_build -O--buildsystem=pybuild
> > >
> > > E: pybuild pybuild:367: build: plugin flit failed with: Neither
> > > [project] nor [tool.flit.metadata] found in pyproject.toml E: pybuild
> > > pybuild:367: build: plugin flit failed with: Neither [project] nor
> > > [tool.flit.metadata] found in pyproject.toml dh_auto_build: error:
> > > pybuild --build -i python{version} -p "3.10 3.9" returned exit code 13>
> > It indeed uses poetry, not flit, but you have export PYBUILD_SYSTEM=flit.
>
> Where can I find an example how to use poetry?
Add build-depends on pybuild-plugin-pyproject.
Drop build-depends on flit.
Drop the "export PYBUILD_SYSTEM=flit" line in d/rules.
The poetry build-depends I'm a little uncertain on. Subby has:
> [build-system]
> requires = ["poetry>=0.12"]
> build-backend = "poetry.masonry.api"
What I recall seeing is:
> [build-system]
> requires = ["poetry>=0.12"]
> build-backend = "poetry.core.masonry.api"
I am not familiar enough to know if that means that you need python3-poetry
(which you have) or if the upstream pyproject.toml is wrong and you need
poetry-core. Maybe someone else knows or you can experiment.
That should get you close.
Scott K
signature.asc
Description: This is a digitally signed message part.
Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian
On Tuesday, January 18, 2022 3:17:31 AM EST Neil Williams wrote: > On Mon, 17 Jan 2022 12:47:44 -0500 > > Louis-Philippe Véronneau wrote: > > Hey folks, > > > > I'm following up on bug #1001677 [1] on the DPT's list to try to reach > > consensus, as I think the Lintian tags that were created to fix this > > bug are not recommending the proper thing. > > > > As a TL;DR for those of you who don't want to read the whole BTS > > thread, jdg saw that a bunch of packages were using `py3versions -r` > > in autopkgtests, and this fails when there's no X-Python3-Version > > variable in d/control. > > > > The fix that Lintian now proposes for packages that use `py3versions > > -r` in autopkgtests is to set X-Python3-Version. > > > > 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. > > Just as a general point, can I ask that - especially in a TL;DR - that > long option names are used or the context of each option is included as > the difference between -r and -s is not obvious from this email & not > everyone on the list uses py3versions routinely. TIL py3versions has long option names ... -d, --defaultprint the default python3 version -s, --supported print the supported python3 versions -r, --requested print the python3 versions requested by a build; the argument is either the name of a control file or the value of the X-Python3-Version attribute -i, --installed print the installed supported python3 versions Scott K signature.asc Description: This is a digitally signed message part.
Re: Cleaning up the Salsa DPT landing page
On Monday, January 17, 2022 12:59:53 PM EST Louis-Philippe Véronneau wrote: > On 2022-01-17 12 h 31, Scott Kitterman wrote: > > On Monday, January 17, 2022 12:20:59 PM EST Louis-Philippe Véronneau wrote: > >> Hey folks, > >> > >> The merger between the DPMT and the PAPT into a single entity has been > >> pretty successful IMO and I think it's time to cleanup the Salsa DPT > >> landing page. > >> > >> Looking at https://salsa.debian.org/python-team, I would propose the > >> following: > >> > >> 1. Delete the empty DPMT sub-group at > >> https://salsa.debian.org/python-team/modules > >> > >> 2. Delete the empty PAPT sub-group at > >> https://salsa.debian.org/python-team/applications > > > > I don't have an opinion on #3 and #4. > > I mostly care about #3 in #4 :P > > > Might it be better to leave these with a description that explains where > > they went? There's lots of things that refer to DPMT/PAPT and I don't > > think all the packages have been uploaded with the correct Vcs-* data > > yet. It doesn't hurt to leave them there and if they explain where to > > look instead, I think the chances of someone being confused later are > > reduced. > > The following lintian tags flag packages using the old Vcs-* data: > > https://lintian.debian.org/tags/old-papt-vcs (11 packages) > https://lintian.debian.org/tags/old-dpmt-vcs (431 packages) > > Those packages have been fixed in git though, as Ondřej ran a script to > fix all of them a while ago already. > > Someone correct me if I'm wrong, but I don't think keeping empty dirs > does anything to the Salsa redirects though. I don't know, but I wasn't primarily thinking about people working internal to Debian (who might look at lintian output). I was more thinking about users (both ours and downstream). 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. I think this is much less relevant for #3 and #4 since they are more internally focused so some expectation that people will keep up with changes is more reasonable. Scott K Scott K
Re: Cleaning up the Salsa DPT landing page
On Monday, January 17, 2022 12:59:53 PM EST Louis-Philippe Véronneau wrote: > On 2022-01-17 12 h 31, Scott Kitterman wrote: > > On Monday, January 17, 2022 12:20:59 PM EST Louis-Philippe Véronneau wrote: > >> Hey folks, > >> > >> The merger between the DPMT and the PAPT into a single entity has been > >> pretty successful IMO and I think it's time to cleanup the Salsa DPT > >> landing page. > >> > >> Looking at https://salsa.debian.org/python-team, I would propose the > >> following: > >> > >> 1. Delete the empty DPMT sub-group at > >> https://salsa.debian.org/python-team/modules > >> > >> 2. Delete the empty PAPT sub-group at > >> https://salsa.debian.org/python-team/applications > > > > I don't have an opinion on #3 and #4. > > I mostly care about #3 in #4 :P > > > Might it be better to leave these with a description that explains where > > they went? There's lots of things that refer to DPMT/PAPT and I don't > > think all the packages have been uploaded with the correct Vcs-* data > > yet. It doesn't hurt to leave them there and if they explain where to > > look instead, I think the chances of someone being confused later are > > reduced. > > The following lintian tags flag packages using the old Vcs-* data: > > https://lintian.debian.org/tags/old-papt-vcs (11 packages) > https://lintian.debian.org/tags/old-dpmt-vcs (431 packages) > > Those packages have been fixed in git though, as Ondřej ran a script to > fix all of them a while ago already. > > Someone correct me if I'm wrong, but I don't think keeping empty dirs > does anything to the Salsa redirects though. I don't know, but I wasn't primarily thinking about people working internal to Debian (who might look at lintian output). I was more thinking about users (both ours and downstream). 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. I think this is much less relevant for #3 and #4 since they are more internally focused so some expectation that people will keep up with changes is more reasonable. Scott K Scott K signature.asc Description: This is a digitally signed message part.
Re: Cleaning up the Salsa DPT landing page
On Monday, January 17, 2022 12:20:59 PM EST Louis-Philippe Véronneau wrote: > Hey folks, > > The merger between the DPMT and the PAPT into a single entity has been > pretty successful IMO and I think it's time to cleanup the Salsa DPT > landing page. > > Looking at https://salsa.debian.org/python-team, I would propose the > following: > > 1. Delete the empty DPMT sub-group at > https://salsa.debian.org/python-team/modules > > 2. Delete the empty PAPT sub-group at > https://salsa.debian.org/python-team/applications I don't have an opinion on #3 and #4. Might it be better to leave these with a description that explains where they went? There's lots of things that refer to DPMT/PAPT and I don't think all the packages have been uploaded with the correct Vcs-* data yet. It doesn't hurt to leave them there and if they explain where to look instead, I think the chances of someone being confused later are reduced. Scott K signature.asc Description: This is a digitally signed message part.
New python-nacl
I've just uploaded the new (version 1.5.0) python-nacl to experimental to give rdepends a chance to test. Being a python extension there's not a formal transition for this, but I wanted to do some testing first, so I thought I'd put it in experimental so others can too. Scott K signature.asc Description: This is a digitally signed message part.
Re: DPT repositories checks/"violations" report
On Monday, January 3, 2022 3:13:23 PM EST Louis-Philippe Véronneau wrote: > On 2022-01-03 01 h 30, Scott Kitterman wrote: > > > Since this is all about team Git repositories, someone should just fix > > them (modulo the one about using pypi, which I think we mostly agree > > isn't something someone unfamiliar with the package can 'fix'). > > But that doesn't prevent future errors from popping up and doesn't make > maintainers aware of their errors (so they can learn from it). > > I think the "perfect" solution would be to have an automated tool (aka > janitor) fixing these automatically, but this would require more work. The first step if we think these things should be the standard for team repositories is to document it. Personally, I would look here: https://wiki.debian.org/Python/GitPackaging#Creating_new_repositories At least for me, a good explanation of what to do in the documentation would be much more valuable than a bug report. Approximately all of the team repositories I've created are "wrong" because I followed the documentation. Scott K signature.asc Description: This is a digitally signed message part.
Re: DPT repositories checks/"violations" report
On Sunday, January 2, 2022 7:50:02 PM EST Louis-Philippe Véronneau wrote: > On 2021-12-12 01 h 23, Sandro Tosi wrote: > > >> 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 > > > Is there a reason why we shouldn't just file bugs in the BTS? I get it's > not the perfect tool for that, but it would certainly help reach the > maintainers. > > Using a common usertag would also make it easier to find and fix these > issues en masse ;) Since this is all about team Git repositories, someone should just fix them (modulo the one about using pypi, which I think we mostly agree isn't something someone unfamiliar with the package can 'fix'). Scott K signature.asc Description: This is a digitally signed message part.
Re: New pybuild plugin for PEP-517 pyproject.toml projects
On December 29, 2021 11:33:26 PM UTC, Michel Alexandre Salim wrote: >Hi Stefano, > >On Wed, Dec 29, 2021 at 10:17:57PM +, stefa...@debian.org wrote: >> Hi debian-python (2021.12.17_23:52:14_+) >> > - Build-depend on `dh-python-pep517` as well as any build tools >> > specified by upstream in pyproject.toml (in build-system.requires) >> > such as python3-setuptools, flit, or python3-poetry-core >> >> At upstream's suggestion, this is renamed to pybuild-plugin-pyproject. >> We're providing dh-python-pep517 for compatibility, but hope to drop it >> ASAP. >> >Is there a way to see what packages currently build-depend on this? > >This does not seem to be supported: >$ apt-rdepends -r --build-depends dh-python-pep517 >E: Reverse build-dependencies are not supported In the ubuntu-dev-tools package, reverse-depends -b $PACKAGE. Scott K
Re: Packaging request for pygrib
Not a fool, just learning. Debian is complicated and the best way to learn is to dive in and try things. As long as you learn along the way, it's all good. Scott K On December 28, 2021 11:46:49 PM UTC, Kyle Lawlor-Bagcal wrote: >Oh, I see. That is indeed the same package. I don't think there is any >work to do then. I'm just a fool who didn't know how to search well >enough ;-) > >$ sudo apt-cache show python3-grib >Package: python3-grib >Architecture: amd64 >Version: 2.0.4-2build2 >Priority: optional >Section: universe/python >Source: pygrib >Origin: Ubuntu >Maintainer: Ubuntu Developers >Original-Maintainer: Alastair McKinstry >Bugs: https://bugs.launchpad.net/ubuntu/+filebug >Installed-Size: 1130 >Depends: libc6 (>= 2.4), libeccodes0 (>= 2.16.0), libeccodes-data, >python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3 (<< 3.9), >python3 (>= 3.8~), python3:any, python3-pyproj, libeccodes-dev, >libgrib2c-dev >Recommends: python-grib-doc >Breaks: python-grib (<< 2.0.0-1), python-grib-doc (<< 2.0.0-2) >Replaces: python-grib (<< 2.0.0-1), python-grib-doc (<< 2.0.0-2) >Filename: pool/universe/p/pygrib/python3-grib_2.0.4-2build2_amd64.deb >Size: 305204 >MD5sum: de8d54eaaa0cd448b2aa8b35e6b15d3a >SHA1: 343647462ced180a318e18d63b99808135eb5632 >SHA256: 74b23dbda57b1f2ab01af66935a62666066c04f8996a4b46e16572d4b2c88370 >Homepage: https://github.com/jswhit/pygrib >Description-en: Python 3 module for reading and writing GRIB files > Python 3 module for reading and writing GRIB (editions 1 and 2) files. > GRIB is the World Meterological Organization standard for > distributing gridded data. The module is a Python 3 interface > to the GRIB API C library from the > European Centre for Medium-Range Weather Forecasts (ECMWF). > . > This package also contains the cnvgrib1to2, grib_list, grib_repack, and > cnvgrib2to1 scripts. >Description-md5: 914b7563eb5a65791173632367a72e64 >
Re: Packaging request for pygrib
On December 28, 2021 11:34:01 PM UTC, Kyle Lawlor-Bagcal wrote: >On 12/28/21 6:18 PM, Scott Kitterman wrote: >> For The Debian Python team, if the team is listed as the maintainer for an >> existing package, then you can go ahead. If an individual is listed at >> Maintainer and the team is listed in Uploaders, then you should check with >> the >> identified maintainer before doing stuff. >> >> For new packages, you don't need to wait for permission to prepare the >> package. > >Thanks Scott. I assume that this is the place to look for that info: > >https://tracker.debian.org/teams/python/+table/general/ > >I'm not seeing the pygrib package there, so I can start working. > There's an existing package of that name maintained outside the team: https://tracker.debian.org/pkg/pygrib Assuming it's the same package, you should contact the maintainer about contributing. Scott K
Re: Packaging request for pygrib
On Tuesday, December 28, 2021 6:14:20 PM EST Kyle Lawlor wrote: > On Tue, Dec 28, 2021 at 5:59 PM, Geert Stappers > wrote: > > https://wiki.debian.org/Packaging > > > Geert Stappers > Could not resist to ignore the "tell me how to do it", settled for a short > reply. Thank you for the link, I will pursue this and reach out when I have > questions or progress to share. > > -- > Silence is hard to parse For The Debian Python team, if the team is listed as the maintainer for an existing package, then you can go ahead. If an individual is listed at Maintainer and the team is listed in Uploaders, then you should check with the identified maintainer before doing stuff. For new packages, you don't need to wait for permission to prepare the package. Scott K signature.asc Description: This is a digitally signed message part.
Use of flit as a build-backend in pybuild
The versions of pybuild in stable, testing, and unstable all support flit as a build-backend for packages built upstream using flit. You can tell if your package is built using flit if it has a pyproject.toml file and it contains a paragraph like: [build-system] requires = ["flit_core >=3.2.0,<4"] build-backend = "flit_core.buildapi" Of the packages I've looked at, they either have no setup.py at all or a very rudimentary generated setup.py. Although the generated setup.py will work, it's only going to provide limited Python metadata for the package. Under the hood, using flit provides a nicer package. To use the flit backend for pybuild all you should need to do is add flit to build-depends and drop whichever of python3-setuptools or python3-distutils you are using now. Flit will be autodetected (and you will see it mentioned in the build log). Flit 3.0 is the lowest version in Debian, so if the requires version is 3.0 or less, then an unversioned build-depends on flit is appropriate. For the example above it would be: flit >= 3.2.0 There is one issue at present, currently if upstream provides optional depends in PEP 621 metadata (there is a [project.optional-dependencies] paragraph in the pyproject.toml) these optional dependencies are added to the binary depends through the python3:Depends expansion variable. I expect this to be fixed in the next dh-python upload. In the meantime this can be disabled by: override_dh_python3: dh_python3 --no-guessing-deps As I'm going through updating my packages, I'm finding flit use is much more common than I was expecting. You may be able to use this more than you thought. I certainly am. Scott K signature.asc Description: This is a digitally signed message part.
Re: DPT repositories checks/"violations" report
On November 27, 2021 6:01:08 AM UTC, Sandro Tosi wrote: >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. I don't think the pypi tarball "issue" should be presumed to be a problem at all. I wasn't paying attention to Debian when that discussion happened, but in my experience there was a lot wrong with the idea. A properly constructed sdist is exactly what we want to build a package from. That's almost never found on GitHub. Scott K
Re: Downgrading dnspython back to 1.16.0 to fix Eventlet
On Thursday, February 4, 2021 4:49:21 AM EST Thomas Goirand wrote: > On 2/2/21 7:46 PM, Thomas Goirand wrote: > > Both Eventlet and DNSPython are monkey patching the standard SSL library > > in potentially conflicting ways > > After checking, that's *NOT* the case. Though Eventlet is doing > monkey-patching of dnspython, in a possible not-compatible with 2.x. > > Anyways, looks like this small patch fixes Eventlet with dnspython 2: > > https://github.com/tipabu/eventlet/commit/2f9b7969f9a66a75e72908454246b88bf5 > 7fe58a > > I've uploaded Debian release 0.26.1-5, and when it reaches the mirrors, > I'll try again to make OpenStack work, and see how it goes. If it fixes > everything, then we're good to go. Otherwise, my questioning about > downgrading dnspython to 1.16.0 still stand. I'll let you know. > > Cheers, > > Thomas Goirand (zigo) > > P.S: Thanks to Tim Burke for this patch If Eventlet is monkey patching DNSPython and it doesn't work, I think that's totally Eventlet's problem. Hopefully your patch works. I do not think downgrading DNSPython for this is a good idea. Scott K signature.asc Description: This is a digitally signed message part.
