Re: Updating Flask to 3.x?
Hi, Am 26.12.23 um 15:24 schrieb Carsten Schoenert: I've uploaded first python-werkzeug https://qa.debian.org/excuses.php?experimental=1=python-werkzeug and a day later flask with a newer version >= 3.0.0. https://qa.debian.org/excuses.php?experimental=1=flask I focused the past days within my free time to fix issues related to python-werkzeug. Some of the packages a I touched had also impact to the broken QA packages in the flask package. So far it looks not that bad, currently there are three packages left for python-werkzeug. flask-dance For this package I wasn't able to fix the broken CI tests, fixing the broken import which is shown on the QA output is mostly easy, but afterwards there are some more other broken tests that will require some help by upstream. Raising a issue within the GitHub issue tracker is still needed. For now I postponed this, if someone wants to take action on this please go ahead. onionshare open3d These packages have currently no version in testing for some time. Both will also require help from upstream I guess. pytest-httpbin Should be obsolete soon, I uploaded a newer version to unstable that will fix the broken tests. The amount of broken packages due the flask 3.0.0 upload is a bit greater and I haven't looked much at these packages yet. My guess is that most of these packages can be "fixed" by preparing uploads with newer versions. I wanted to give a update on the current state. Since my last email about this topic a lot fixes and uploading of packages did happen by various people and contributors, thank you all for working on the build or test issues! For now it's look quite good to me. There are currently three packages left that showing build or test issues while package build. The details can be found on the URLS from my previous email.^^^ python-werkzeug triggers (still) a autopkgtest failure for onionshare. flask is provoking autopkgtest failure for ironic-inspector[2] and bepasty [3]. bepasty is fixed upstream and will get fixed in Debian once the newer version (not yet released) will enter Debian. So we mainly have basically two packages left, I might will find some time and look again into onionshare. ironic-inspector is maintained by the Openstack maintainers and I'm not familiar enough to check if a newer version would fix the current test issues. [1] https://ci.debian.net/packages/o/onionshare/unstable/amd64/41943542/ [2] https://ci.debian.net/packages/i/ironic-inspector/unstable/amd64/41962520/ [3] https://ci.debian.net/packages/b/bepasty/unstable/amd64/41942909/ -- Regards Carsten
Bug#1061394: ITP: langtable -- Python 3 library for guessing locale defaults
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org Control: affects -1 src:langtable Owner: jeremy.bi...@canonical.com Package Name: langtable Version: 0.0.64 Upstream Author: Mike Fabian License: GPL-3+ Programming Lang: Python 3 Description: Python 3 library for guessing locale defaults langtable is a Python 3 library that guesses reasonable defaults for locale, keyboard, territory, etc. based on the information already known. Other Info -- This package will be maintained by the Debian Python team. Packaging is at https://salsa.debian.org/python-team/packages/langtable langtable is a proposed build dependency for the gnome-desktop library Thanks, Jeremy Bícha
Broken entrypoints package: actually a pybuild issue?
Hi,
I found the source of the breakage for the entrypoints package: its
tests/samples/ directory contains a few files describing mock Python
packages, and the tests consist in running functions on those and check
the answers match what is expected.
Alas, something (and I suspect pybuild) removes the *.egg-info
directories there, so of course results don't match.
I see two ways out:
(1) configure something so tests/samples/ doesn't get touched ;
(2) patch the tests to adapt them to the modified directories.
Solution (2) is pretty fast, pretty easy and extremely dirty: it will
need an update for each upstream change and that basically means the
tests don't actually test anything.
Solution (1) is much more reliable, but I neither know if it's possible
nor how - can someone lend a hand?
Thanks!
J.Puydt
PS: the patch would be that ugly:
Description: fix bug #1052826 (broken tests)
Author: Julien Puydt
Forwarded: not needed
--- entrypoints.orig/tests/test_entrypoints.py
+++ entrypoints/tests/test_entrypoints.py
@@ -19,31 +19,31 @@
def test_iter_files_distros():
result = entrypoints.iter_files_distros(path=sample_path)
-# the sample_path has 4 unique items so iter_files_distros returns
4 tuples
-assert len(list(result)) == 4
+# the sample_path has 3 unique items so iter_files_distros returns
3 tuples
+assert len(list(result)) == 3
# testing a development, egg aka installed with pip install -e .
# these don't have version info in the .egg-info directory name
# (eg dev-0.0.1.egg-info)
path_with_dev = [osp.join(samples_dir, 'packages4')]
result = entrypoints.iter_files_distros(path=path_with_dev)
-assert len(list(result)) == 1
+assert len(list(result)) == 0
# duplicate dev versions should still return one result
path_with_dev_duplicates = path_with_dev * 2
result =
entrypoints.iter_files_distros(path=path_with_dev_duplicates)
-assert len(list(result)) == 1
+assert len(list(result)) == 0
def test_get_group_all():
group = entrypoints.get_group_all('entrypoints.test1',
sample_path)
print(group)
-assert len(group) == 5
-assert {ep.name for ep in group} == {'abc', 'rew', 'opo', 'njn'}
+assert len(group) == 3
+assert {ep.name for ep in group} == {'abc', 'rew', 'njn'}
def test_get_group_named():
group = entrypoints.get_group_named('entrypoints.test1',
sample_path)
print(group)
-assert len(group) == 4
+assert len(group) == 3
assert group['abc'].module_name == 'foo'
assert group['abc'].object_name == 'abc'
Re: Bug#1043240: transition: pandas 1.5 -> 2.1
On Mon, Jan 22, 2024 at 08:50:55PM +, Rebecca N. Palmer wrote: > On 22/01/2024 11:51, Julian Gilbey wrote: > > Please could we wait until the "Python 3.12 is a supported version" > > transition is completed? > > How are you defining that? python3-defaults 3.11.6+ in testing? (I was > previously told 3.12-supporting pandas and numpy in testing, which has > happened. I don't think any of these 25 packages are on > https://qa.debian.org/excuses.php?package=python3-defaults , but I haven't > checked carefully, and at least influxdb-python and tqdm do have what I > suspect are Python 3.12 related issues.) https://release.debian.org/transitions/html/python3.12-add.html We're nearly there (the transition page says it's 99% done), and when this transition is complete, then python3-defaults 3.11.6+ will be able to migrate to testing. I don't fully understand the problem with transitions, but there was a request to hold back with significant upgrades until a python3.12-supporting python3-defaults has reached testing. > > Adding another 25 or so RC bugs at this > > point will just slow down that transition. > > What exactly do you want not done until then? Just not uploading pandas > 2.x to unstable, or is it also a problem to have these bugs marked as RC in > the BTS? (In all 22 cases that are in testing at all, the bug is also > present in the version in testing, so it being RC shouldn't block > migration.) Yes - please don't upload it to unstable yet. Uploading to experimental is fine. > > (Unless pandas 1.5 is > > preventing the transition, that is.) > > It isn't. Good! Julian
