Re: Matplotlib 3.10.0 for trixie?
Hi, On 06/03/25 10:07 pm, Nilesh Patra wrote: > > > On 23/02/25 6:03 pm, Nilesh Patra wrote: >> >> >> On 23/02/25 05:19, Alexandre Detiste wrote: >>> There was a cyclic bootstrap relationship between this and ... Pandas (?) >>> in the Numpy transition that was handled swiftly in the Pandas side >>> but I thing we are a now far enough in Numpy transition the reopload >>> 3.8 to unstable with the accumulated fixes and start working >>> on 3.10 for experimental. >> >> I tried to upload the accumulated fixes, did not notice the tests were >> enabled >> and screwed up and had to do multiple uploads -- sorry for that. >> >> I've pushed changes for 3.10.0 to debian/experimental branch on salsa and >> uploaded >> to experimental as well. > > So a a bunch of things are failing with: > > ``` > ImportError: Cannot load backend 'TkAgg' which requires the 'tk' interactive > framework, as 'headless' is currently running > ``` > > I am unsure what it wrong here, and have raised a issue on github. This does > not look > like a packaging error to me but please review! Jay was very kind to investigate here and supplied w a patch[1] and a PR [2]. Unfortunately, I do not have the environment to repro this reliably, nor have my yubikey to actually upload this to experimental. @Alexandre or someone else, could you please help w validating the fix or upload a -3 to experimental? [1] https://github.com/matplotlib/matplotlib/commit/f45707d9e6111a83d2c741530cbff2be2c8005ff [2] https://github.com/matplotlib/matplotlib/issues/29713
Re: python3.10
On 2025-03-10 14:36, Andrey Rakhmatullin wrote: On Mon, Mar 10, 2025 at 07:06:57PM +0100, Christian BAYLE wrote: I just encountered recently a few venv that require 3.10 to work in at least 2 ai stable diffusion software, really difficult to package right now. Not sure what do you mean by venv but for local use you aren't required to use Python interpreters from the distribution and can e.g. use pyenv to install any other one. I was in fact about to suggest the same thing Andrey did here. For any local-use stuff which requires one or more Python versions beyond the system-installed Python version, this is my recommended solution to use pyenv and then have the local installs alongside Debian's installed Python. I also want to make a few things known about 'downstream' 'in Ubuntu that you refer to. The problem we see routinely 'downstream' is people try and change their Python version away from the system preferred Python version, thus breaking things. It happens way more than I'd like to admit (just look at Ask Ubuntu and the number of python errors we can attribute to User Error in this exact way), and usually I suggest pyenv [1] to allow userspace installations of Python isolated from system Python that works for those cases you need older versions. I do this routinely even downstream on other distros. In fact, wherever you are required to use *older* Python or *newer* Python than is available in your distro - Debian, Ubuntu, Mint, etc. - I always point at PyEnv as a solution. Thomas [1]: https://github.com/pyenv/pyenv
Re: Getting Ruff updated in time for the Trixie freeze?
Hi Carsten, Am 3/8/25 um 08:26 schrieb Carsten Schoenert: Hi, this is more a call for help than a generic question to the DPT. :-) Maybe someone of you have also some package that is depending on ruff or python3-ruff, especially on a more recent version to be available in Debian. And maybe you have some free time to have a look at the source package ruff to prepare a more recent version into the archive before the last days of the freeze will start. https://tracker.debian.org/pkg/ruff I'd really be interested. But I need some guidance. What's the best place to coordinate there, irc? Best Michael
python3.10
Hello, was wondering why there is no python3.10 in debian as i think there is one in ubuntu https://launchpad.net/ubuntu/+source/python3.10 didn't see an answer in the policy, maybe missed it. google didn'd help, except you find a lot of "Best way to install Python3.10" I just encountered recently a few venv that require 3.10 to work in at least 2 ai stable diffusion software, really difficult to package right now. Worth of packaging it ? It seems easy to simply download and build and use. Did I missed some reason ? Would it be difficult difficult? crossport ubuntu ? issues ? Thank you
Re: python3.10
Le 10/03/2025 à 19:36, Andrey Rakhmatullin a écrit : Every stable Debian release only contains one Python version, normally the newest one at the time when the release was made. Testing and unstable can contain two versions during the transition from the older one to the next one. Clear I just encountered recently a few venv that require 3.10 to work in at least 2 ai stable diffusion software, really difficult to package right now. Not sure what do you mean by venv but for local use you aren't required to use Python interpreters from the distribution and can e.g. use pyenv to install any other one. I mean that in many case projects suggest to do python3 -m venv venv ; . venv/bin/activate then : - the pip upgrade - pip install -r requirements_versions.txt but as far as i understand, the virtualenv can only be with the python3 version available on the system and many upstream have complex dependency that only work for 3.10 or 3.13 or .. not that i want to encourage the use of virtualenv instead of packaging, but it's often only way except heavier dockerizing, especially boring with GPU Worth of packaging it ? It seems easy to simply download and build and use. Simply providing a Python interpreter in Debian is not generally useful, and integrating it with the packaged modules is a lot of work which is also impossible for older Python versions. So no. You can package it locally if you want and if you don't expect it to work with any packaged modules. The idea would have it only for the virtualenv usage, not to have all packaged modules, none if possible A googling on 'installing python3.10 in debian bookworm' let me think, it's a bit current issue It's indeed amazing that the usual criticism about only old libs available i heard so many, plays in the other direction. I was surprised that python3.10 compiling from upstream tarball was so easy, but it's maybe i was lucky Cheers Christian
Re: python3.10
On Mon, Mar 10, 2025 at 07:06:57PM +0100, Christian BAYLE wrote: was wondering why there is no python3.10 in debian Every stable Debian release only contains one Python version, normally the newest one at the time when the release was made. Testing and unstable can contain two versions during the transition from the older one to the next one. I just encountered recently a few venv that require 3.10 to work in at least 2 ai stable diffusion software, really difficult to package right now. Not sure what do you mean by venv but for local use you aren't required to use Python interpreters from the distribution and can e.g. use pyenv to install any other one. Worth of packaging it ? It seems easy to simply download and build and use. Simply providing a Python interpreter in Debian is not generally useful, and integrating it with the packaged modules is a lot of work which is also impossible for older Python versions. So no. You can package it locally if you want and if you don't expect it to work with any packaged modules. -- WBR, wRAR signature.asc Description: PGP signature
Re: Getting Ruff updated in time for the Trixie freeze?
On Sat, Mar 08, 2025 at 09:26:28AM +0200, Carsten Schoenert wrote: this is more a call for help than a generic question to the DPT. :-) Maybe someone of you have also some package that is depending on ruff or python3-ruff, especially on a more recent version to be available in Debian. And maybe you have some free time to have a look at the source package ruff to prepare a more recent version into the archive before the last days of the freeze will start. https://tracker.debian.org/pkg/ruff I've talked with Jelmer while the MDC in Cambridge and the outcome was mostly the reason for not having a newer version is a lack of free time on his side to get a newer version into shape for an upload. If you look into the existing patch queue you will see a lot of patches that do patch out vendor-ed stuff. https://sources.debian.org/src/ruff/0.0.291%2Bdfsg1-4/debian/patches/ I haven't looked at this in detail the past weeks, but I guess this is still the critical part in upstream ruff to get it updated in Debian. There was a newer version (0.6.8) imported into the packaging tree a while ago, and maybe a good thing would be to finish this version first as for sure some other Rust related packaged will also need an update first before we could prepare the most recent version of ruff. The version in the archive currently is 0.0.291 while upstream has reached version 0.9.10 this week. @Jelmer If you have some further suggestions, wishes or remarks please spread them! :-) What is your suggestion, how to proceed at the moment? Let's coordinate on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068248 The bulk of the work is actually in updating/packaging the various (rust) dependencies for ruff. See that bug report for the current list. Help packaging those dependnecies would be great. Once we've done that, we can take another look at updating ruff itself. Cheers, Jelmer
Bug#1100042: ITP: python-casttube -- Interact with the YouTube Chromecast API
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-casttube Version : 0.2.1 Upstream Author : Uri Katz <4urik...@gmail.com> * URL : https://github.com/ur1katz/casttube * License : MIT Programming Lang: Python Description : Interact with the YouTube Chromecast API This library allows users to engage with the YouTube Chromecast API, enabling control over video playback on devices with Chromecast capabilities. It can initiate the playing of videos or playlists, manage queue operations such as adding and removing videos, and handle playback controls including play next and clearing the queue. This library communicates with a YouTube app running on a Chromecast device, requiring a screen ID for interactions. Leveraging this API, casttube provides functionality for controlling media displayed through Chromecast, making it possible to manage streaming directly from a programmatic interface. I plan to maintain this package as part of the Python team.
