Re: Summary of python transition problems
- Original Message From: Colin Watson <[EMAIL PROTECTED]> To: debian-python@lists.debian.org Cc: debian-release@lists.debian.org Subject: Summary of python transition problems Date: 29/09/03 10:49 Hi, > > (cc'ed to -release for general information) > > Hi folks, > > Here's a summary of the problems currently blocking python2.3 from > testing. It may be slightly incomplete, but I think I've got most of > them. > > > Missing builds > == > > * newt: hppa > Is this an error /out of date? From the archive, it appears that hppa is up-to-date on newt for both sarge and sid. If you know of any problems with python-newt, I'd like to hear of them. > > Cheers, > > -- > Colin Watson [EMAIL PROTECTED] > > Regards, Alastair > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > > Message sent using UebiMiau 2.7.2
Re: Best practice for test(s) directories?
On 14 Jul 2008, at 23:50, Ondrej Certik wrote: On Tue, Jul 15, 2008 at 12:28 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote: Hi Kibi! On Mon, Jul 14, 2008 at 20:13, Cyril Brulebois <[EMAIL PROTECTED]> wrote: Hi folks, I'm wondering whether there's a preferred place where to drop the test(s) directory. I don't really know whether to choose /usr/share/python-support/$package/test(s) or /usr/share/$package/test(s). Since it isn't really needed for the module to correctly work, I'd be tempted to keep it out of python-support's paths, and to keep it under /usr/share/$package instead, but what do you think? Well, since tests are something not needed for the module to work and they provide a sort of documentation of the module itself, I usually install them as examples under /usr/share/doc/$pkg/examples (as suggested by Piotr and/or Bernd, IIRC). Just my 2 cc :) Tests can be useful for checking that code that depends on a package still works; ie if package app depends on module foo, then package app might put its tests in /usr/share/tests/app. When foo changes, you can run the tests as a regression check. This was the idea behind the abortive debian-test project. Some day I may resuscitate it. The tests shouldn't go in a binary package, but perhaps a debug package if it extsts. Alastair Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Regards, Alastair -- Alastair McKinstry , <[EMAIL PROTECTED]> http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: (forw) Re: Future of python2.6 in Debian (python-newt)
Hi,
Thanks to Christian for forwarding this. python-newt uses a depends line
that generates:
amckinstry@debian:~/deb-packages/newt/newt-0.52.14/debian$ cat
python-newt.substvars
python:Versions=2.6, 2.7
python:Provides=python2.6-newt, python2.7-newt
python:Depends=python2.7 | python2.6, python (>= 2.6), python (<< 2.8),
python (>= 2.6.6-7~)
shlibs:Depends=libc6 (>= 2.1.3), libc6 (>= 2.3.6-6~), libnewt0.52,
libpython2.6 (>= 2.6), libpython2.7 (>= 2.7), libslang2 (>= 2.0.7-1)
misc:Depends=
The ${python:Depends} is fine, but ${shlibs:Depends} generates
dependencies on libpython that are superfluous,
as well as the necessary libslang, libnewt dependencies. I _could_ drop
the ${shlibs:Depends} and replace it with
just 'libnewt0.52', (the libc and libslang dependencies will be pulled
in from it), but I suspect it would be best
to somehow tell debhelper that I don't need libpython*.
Any ideas?
please CC: me in any response as I'm not currently subscribed to
debian-python
regards
Alastair McKinstry
Original Message
Subject:(forw) Re: Future of python2.6 in Debian (python-newt)
Date: Sun, 8 Jan 2012 08:00:05 +0100
From: Christian PERRIER
To: mckins...@debian.org
Hi Alastair,
In case you hadn't noticed
- Forwarded message from Axel Beckert -
Date: Sun, 8 Jan 2012 03:20:01 +0100
From: Axel Beckert
To: Matthias Klose
Cc: debian-python@lists.debian.org, Debian Release
Subject: Re: Future of python2.6 in Debian
Organization: The Debian Project
X-Mailing-List: archive/latest/50451
X-CRM114-Status: Good ( pR: 999.99 )
Hi,
JFYI:
Matthias Klose wrote:
> see
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python2.6-removal;users=debian-python@lists.debian.org,
> the only blocker is packaging of zope2.13. feedback from the zope2 packagers
> is
> outstanding.
There's one issue which is not listed there but into which I ran into on
i386 recently:
python-newt depends on libpython-2.6 since very recently only and only
on some architectures. Noticed it, because it wants to pull in
python2.6 again. See also http://packages.debian.org/sid/python-newt
Regards, Axel
--
,''`. | Axel Beckert , http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120108022001.gc27...@sym.noone.org
** CRM114 Whitelisted by: From: Axel Beckert **
- End forwarded message -
--
Re: Add pydap (python-dap) to Debian Science Meteorology packages
Hi, I will add it to the blend in svn. I should also add it to the list of packages to port to python3 ... http://wiki.debian.org/DebianScienceMetPython3 Best regards Alastair On 05/07/2013 16:24, Mike Neish wrote: > Hi, > > While perusing the "meteorology" tasks, I noticed the "pydap" package > was listed as being of interest, but unavailable. However, there is > an official Debian pydap package available: > http://packages.debian.org/search?keywords=python-dap > The source package is "pydap", but the binary package is > "python-dap". Maybe this name change is why it's not being detected > in the blend? > > Thanks, > Mike > > -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d6e988.5010...@sceal.ie
Re: Inconsistency in source package naming for python modules
FWIW, I think the current scheme works best. I manage a bunch of packages that have python wrappers; the package then pretty much _has_ to follow the current scheme, eg. Source package: silo Bin packages: libsilo0 libsilo-dev python-silo python3-silo (coming). A policy on renaming the source package isn't likely to change silo, etc. and so a greater inconsistency follows. regards Alastair On 10/07/2013 07:58, Thomas Goirand wrote: > On 07/08/2013 10:10 PM, Scott Kitterman wrote: >> There is no policy on this either way, so there's no "mistake". > Well, the mistake is precisely to have no rule, IMO. > > On 07/08/2013 11:37 PM, Barry Warsaw wrote: >> Hopefully, it will become more and more common to have at least >> python-X and python3-X. With that in mind, many of our source >> packages that are producing a single binary package today should >> hopefully be producing two or more binary packages tomorrow. > Never the less, I think we should collectively decide what to do, rather > than continuing the mess, with everyone having its own rule. > > Thomas > > -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51dd0912.30...@sceal.ie
Re: Python coding help: Has anybody seen this syntax
This is a python3 syntax change; in python3 you can pass an optional metaclass for a class, which you can't do in python2, IIRC. Code works for me in Python3, not python 2.7.6 regards Al On 13/02/2014 16:37, Andreas Tille wrote: > class YAMLObjectMetaclass(type): > """ > The metaclass for YAMLObject. > """ > def __init__(cls, name, bases, kwds): > super(YAMLObjectMetaclass, cls).__init__(name, bases, kwds) > if 'yaml_tag' in kwds and kwds['yaml_tag'] is not None: > cls.yaml_loader.add_constructor(cls.yaml_tag, cls.from_yaml) > cls.yaml_dumper.add_representer(cls, cls.to_yaml) > > class YAMLObject(metaclass=YAMLObjectMetaclass): > """ > An object that can dump itself to a YAML stream > and load itself from a YAML stream. > """ -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fcf79c.4070...@sceal.ie
Re: Getting ready for Python 3.5
I'd recommend we build python3-numpy against Python 3.5 for experimental. Of my packages in the list that FTBFS, I think all of them fail on numpy (some on cython), while numpy builds fine against Python 3.5. We can test the transition in experimental. regards Alastair On 23/06/2015 16:38, Barry Warsaw wrote: > [Apologies for the cross-posting! -BAW] > > For Ubuntu 15.10 (Wily Werewolf), we want to make Python 3.5 the default > Python 3 version. It's currently undecided whether we will keep Python 3.4 as > a supported version, but a lot of that depends on how easily an archive port > to Python 3.5 goes. Ideally, we'd be able to make the switch to 3.5 now ahead > of the planned 16.04 LTS release. > > As part of this work, we've done a partial test rebuild of packages in the > archive that depend in some way on Python 3. For now, this is an x86 only > partial rebuild in a PPA. In this PPA, we have Python 3.5 as the default > Python 3 version, with 3.4 still enabled. > > You can see the results so far here: > > https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault/+packages > > TL;DR: of 1065 uploads, we have ~64% success rate. Some caveats: > > * These are i386 and amd64 only, so we're still in the dark about other >architectures. > > * These are build tests only. While many builds do run the package's test >suite, not all packages have test suites, or not all are enabled. Also, we >are not running what are called DEP-8 tests, which are various additional >smoketests that are run after the package is built, on the built package >(e.g. install the package and all its dependencies in a chroot and see if >it can be imported in both Python 2 and 3). > > * Some failures are due to dependency build order, so a simple rebuild may >succeed. > > * Some failures may not be new. Because a lot of packages don't get new >uploads for every new Ubuntu version, they may be failing to build for >reasons unrelated to Python 3.5. > > * We may have missed some packages which declare their build dependencies in >a way that got past our rather simplistic filter. > > Our plan is get the success rate up on the PPA, filing and fixing bugs > upstream where possible, then to set up a full archive test rebuild, again > with 3.5 as default and 3.4 as enabled, to see what other failures may occur. > This full archive rebuild will include all the other architectures, and it's > possible packages will build on x86 but fail on some other platform. We're > also planning on setting up a QA stack to run the DEP-8 tests for packages > that have them. > > In the meantime, you can help! > > I've started a wiki page listing the backward compatibility breaks I've found > so far. Feel free to add to this, or look into the linked issues. Contribute > to the wiki or the linked issues. > > https://wiki.python.org/moin/PortingToPy3k/34to35 > > Build and install Python 3.5 from source and run your package's test suite in > a virtual environment or in tox. (tox 2.1 supports Python 3.5 but it isn't > yet available in Debian/Ubuntu - no worries, install tox in a virtualenv and > use *that* to run your test suite.) > > Create a chroot with the py35asdefault PPA enabled, and do some porting there. > Here's a good guideline on how to use a PPA. > > https://help.launchpad.net/Packaging/PPA > https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault > > Examine the build failures and see if you can identify or fix the problem. > Start with the package details page > > https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault/+packages > > and drill down into the console logs for specific failures by clicking on the > 'amd64' or 'i386' links next to any big red X you see, then clicking on the > 'buildlog' link. E.g. > > http://tinyurl.com/pnpjtv6 > > Scroll down near the bottom, which is where the failure will most likely be > evident. > > Release new versions of your packages with Python 3.5 support to PyPI so the > Debian maintainers and Ubuntu developers can begin to upload compatible > versions. If you're a developer for other Linux distros or platforms, let's > work together! (As is often the case, we'll trail blaze on Ubuntu and push > the results upstream to Debian as much as possible.) > > Follow up here on any of the CC'd mailing lists, email me directly, or ping me > on IRC (nick 'barry' on python-dev, ubuntu-release @ freenode, debian-python @ > OFTC). > > Python 3.5 is in beta, with a final release scheduled for September 2015 (see > PEP 478). There's still plent
Bug#815893: ITP: python-jpy -- Bi-directional Python-Java bridge
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: python-jpy Version : 0.8 Upstream Author : Brockmann Consult GmbH * URL : http://www.brockmann-consult.de * License : Apache Version 2 Programming Lang: Java, Python Description : Bi-directional Python-Java bridge jpy is a bi-directional Java-Python bridge which you can use to embed Java code in Python programs or the other way round.
Bug#841277: ITP: usagestats -- Python module to collect usagestats from users
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: usagestats Version : 0.5 Upstream Author : Rene Rampin * URL : https://github.com/remram44/usagestats * License : Apache-2 Programming Lang: Python Description : Python module to collect usagestats from users This is a module to collect anonymous Usage statistics of code. It is a dependency of vistrails (already packaged in Debian) for 2.2.4 onwards.
Bug#843244: python-setuptools: setuptools causes packages to FTBFS
Package: python-setuptools Version: 28.7.1-1 Severity: serious Justification: Causes packages to FTBFS Latest setuptools causes packages (eg. iapws) to break. e.g. IAPWS: dh_auto_clean python setup.py clean -a Traceback (most recent call last): File "setup.py", line 1, in from setuptools import setup File "/usr/lib/python2.7/dist-packages/setuptools/__init__.py", line 10, in from setuptools.extern.six.moves import filter, filterfalse, map File "/usr/lib/python2.7/dist-packages/setuptools/extern/__init__.py", line 1, in from pkg_resources.extern import VendorImporter File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2994, in @_call_aside File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2980, in _call_aside f(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3007, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 649, in _build_master ws = cls() File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 642, in __init__ self.add_entry(entry) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 698, in add_entry for dist in find_distributions(entry, True): File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1993, in find_on_path if len(os.listdir(fullpath)) == 0: OSError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/tdparser-1.1.6.egg-info' dh_auto_clean: python setup.py clean -a returned exit code 1 -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-setuptools depends on: ii python-pkg-resources 5.5.1-1 pn python:any python-setuptools recommends no packages. python-setuptools suggests no packages. -- no debconf information
Bug#864778: ITP: fparser -- Python parser for the Fortran language
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: fparser Version : 0.0.4 Upstream Author : Rupert Ford * URL : https://github.com/stfc/fparser * License : BSD-like Programming Lang: Python Description : Python parser for the Fortran language The fparser package is a Python implementation of a Fortran 66/77/90/95/2003 language parser. Currently fparser actually includes two different implementations; the first, “fparser”, supports Fortran 66/77/90 (plus some extensions — see fparser) but only parses down to the level of individual lines of code, i.e. not the content of the Fortran expressions themselves. The second, “fparser2”, also has support for Fortran 2003 and is able to parse Fortran expressions. It is however, less mature than fparser. This package is a dependency of the Psyclone Domain-Specific Language (DSL) for weather codes in Fortran, which I am packaging (and using)
Bug#864817: ITP: psyclone -- Domain-specific compiler for Finite Difference/Volume/Element Earth-system models in Fortran
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: psyclone Version : 1.4.1 Upstream Author : Rupert Ford * URL : https://github.com/stfc/PSyclone * License : BSD-3-Clause Programming Lang: Python Description : Domain-specific compiler for Finite Difference/Volume/Element Earth-system models in Fortran PSyclone is a code generation system that generates appropriate code for the PSyKAl code structure developed in the GungHo project. This is a Fortran-to-fortran code generator; the GungHo project is the next-generation weather model from the UK Met Office and STFC.
Request to join the Debian Python Team
Hi I am hereby requesting to join the Debian Python Modules Team. I'm maintainer of the fparser python module(s), xarray and others. regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#941087: ITP: ansimarkup -- Produce colored terminal text with an xml-like markup
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: ansimarkup Version : 1.4.0 Upstream Author : Georgi Valkov * URL : https://github.com/gvalkov/python-ansimarkup * License : BSD-3-Clause Programming Lang: Python3 Description : Produce colored terminal text with an xml-like markup This is a python3 module to produce colored terminal texty with an XML-like markup. This is a dependency of the latest version of 'cylc', already in Debian.
Re: Bug#972213: boost1.71: Please indicate some way which python versions you support
On 15/10/2020 08:13, Giovanni Mascellani wrote: Hi, Il 14/10/20 15:52, Alastair McKinstry ha scritto: I maintain the package "ecflow" which uses libboost-python-dev. Now with the transition to python3.9, ecflow will support (where possible) multiple python versions. Currently it supports python3.8 but not python3.9 ; this may be fixed in a binNMU or next version, but I cannot tell whether my failure to build python3.9 support for ecflow is due to missing py3.9 support in boost, or a bug in my packaging. BTW, a binNMU was just requested to add Python 3.9 support. Can some mechanism be added to enable tracability ? In general, Boost supports all the Python versions currently supported by the Python team, except that someone has to file a binNMU for them to appear once a new Python version is packaged. To check which Python versions are supported by a specific package version, it is enough to check the content of the libboost-python1.71.0 package (replace 1.71.0 with future versions where applicable): $ dpkg -L libboost-python1.71.0 | grep libboost_python /usr/lib/x86_64-linux-gnu/libboost_python38.so.1.71.0 /usr/lib/x86_64-linux-gnu/libboost_python39.so.1.71.0 (until yesterday you did not have the python39 variant) Does this answer your question? Giovanni. Not really. This is probably better discussed on debian-python. The point was that there is a lack of a good mechanism to see which packages provide py39 support, etc. In principle my package ecflow just needs a rebuild after the boost is rebuilt, but tracking if this actually works, or add a particular dependency to enable automatic rebuild/tracking. Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Re: Bug#972213: boost1.71: Please indicate some way which python versions you support
On 16/10/2020 09:19, Drew Parsons wrote:
On 2020-10-16 14:43, Giovanni Mascellani wrote:
Hi,
Il 16/10/20 02:53, Drew Parsons ha scritto:
Would it make sense to use the Built-Using [1] header?
...
[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
The precise web page you are linking hints that this use of Built-Using
would be improper:
"This field should be used only when there are license or DFSG
requirements to retain the referenced source packages. It should not be
added solely as a way to locate packages that need to be rebuilt against
newer versions of their build dependencies".
Ah yes, I had a feeling there were more reasons to not prefer this
method!
That said, I forgot to mention that the Python versions Boost is
compiled against is also tracked in the package names provided by
libboost-python1.71.0, which are currently libboost-python1.71.0-py38
and libboost-python1.71-py39.
Is this better? More in general, there can be dozens of ways to
advertise which Python versions are used to build Boost.Python, but it
is not clear to me how this information should be consumed.
That sounds like a useful approach.
The ecflow build could access the provided versions via
dpkg -s libboost-python${BOOST_VERSION} | grep Provides
That works.
Code can be added that the package fails to rebuild if it can't get the
necessary provides.
Thanks
Alastair
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
Joining Python-team
Hi I wish to apply to join the Python team. I have a number of packages I wish to maintain under the team: * fparser - Fortran parser in Python * jpy - Java-Python bridge * python-tz : Timezone package * usagestats: small package to collect usage stats from users My salsa / DD login is "mckinstry" I have read https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst <https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst> and will adhere to it. Best regards Alastair -- Alastair McKinstry,,,https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Re: Packaging request for pygrib
Hi, and happy new Year I'm the maintainer of pygrib in Debian. I'm sorry for being late to the thread, but I see you found the package. I hope it works for you; do you need it to be in Debian Python ? Regards Alastair On 28/12/2021, 05:36, "Geert Stappers" wrote: On Tue, Dec 28, 2021 at 12:14:37AM +, Kyle Lawlor-Bagcal wrote: > Hello! > > I would like to request a python package for pygrib: > > 1. https://jswhit.github.io/pygrib/installing.html Text from https://jswhit.github.io/pygrib/index.html Pygrib High-level python interface to ECCODES library for GRIB file IO. Text from https://weather.gc.ca/grib/what_is_GRIB_e.html GRIB is a file format for the storage and transport of gridded meteorological data, such as Numerical Weather Prediction model output. > 2. https://github.com/jswhit/pygrib > > I'm not sure what this would entail, but it would be great to be able to > install it as "apt install python3-pygrib". ;-) > I'm also new to this list so please let me know of etiquette or other > info I should provide. Think "I among friends". Share ideas and ask for doing things together. Know that best way to get things done is by start doing. > I'm not a maintainer on this project. I'm just a casual user. It is OK to break the consensus "Somebody else should do it" Regards Geert Stappers Learned today that grib is not a misspelled grub. ( Text from https://www.gnu.org/software/grub/ GNU GRUB is a Multiboot boot loader. Briefly, a boot loader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the operating system kernel software (such as the Hurd or Linux). The kernel, in turn, initializes the rest of the operating system (e.g. GNU). ) -- Silence is hard to parse
Re: Be part of time-python
Hi As maintainer of python-tz I should probably be involved, but missed the original email. What is the plan, and where is the original email? Best regards Alastair (mckins...@debian.org) On 10/07/2022 01:45, Nilson Silva wrote: Hello Following the time-python policy instructions: I request to join the team in order to help the team maintain the packages they are responsible for. I currently have the following packages under the care of the team: 1. read https://www.debian.org/doc/packaging-manuals/python-policy/index.html 2. Current packages under the team: 1. https://salsa.debian.org/python-team/packages/pyment 2. https://salsa.debian.org/python-team/packages/python-ansible-compat 3. https://salsa.debian.org/python-team/packages/python-dirq my login:@nilsonfsilva Mu name: Josenilson Ferreira da Silva. I await your opinion. Nilson F. Silva -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@sceal.ie, im: @sceal.ie:mckinstry
Fwd: change in the extention importation with 3.11
On 06/12/2022 13:47, picca wrote:
Hello, I am trying to fix this bug
I'm debugging something similar,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024911
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024859
I find the error message not very informative...
:~/$ python3.11
Python 3.11.0+ (main, Nov 4 2022, 09:23:33) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
import scitbx_linalg_ext
Traceback (most recent call last):
File "", line 1, in
SystemError: initialization of scitbx_linalg_ext raised unreported
exception
The problem is that python is catching a C/C++ exception.
You can debug with:
gdb /usr/bin/python3.11
...
(gdb) catch throw
(gdb) run
import scitbx_linalg_ext
...
I would like your opinion and some help in order to fix this or at
least understand what is going on.
ther extension was build with boost_python, maybe something is wrong
also with boost_python and Python3.11.
I do not know if other packages using boost_python are affected like this.
thanks for considering
Frederic
Both cctbx and ecflow are breaking on generating new enums.
A simple test case is:
```
#include
using namespace boost::python;
// enum has flags 0x42000, no traversefunction set
class CheckPt {
public:
/// NEVER - the check pt file is never saved
/// ON_TIME - the check pt file is saved periodically. specified by
checkPtInterval.
/// ALWAYS - the check pt file is saved after any state change
/// UNDEFINED - Internal use only
enum Mode { NEVER, ON_TIME, ALWAYS, UNDEFINED};
};
void inc_enum () {
enum_("CheckPt",
"CheckPt is enum that is used to control check pointing in
the `ecflow_server`_\n\n"
"- NEVER : Switches of check pointing\n"
"- ON_TIME: `check point`_ file is saved periodically,
specified by checkPtInterval. This is the default.\n"
"- ALWAYS : `check point`_ file is saved after any state
change, *not* recommended for large definitions\n"
"- UNDEFINED : None of the the above, used to provide
default argument\n"
)
.value("NEVER", CheckPt::NEVER)
.value("ON_TIME",CheckPt::ON_TIME)
.value("ALWAYS", CheckPt::ALWAYS)
.value("UNDEFINED", CheckPt::UNDEFINED)
;
}
char const *greet()
{
return "Hello world\n";
}
BOOST_PYTHON_MODULE(wrapper)
{
def ("greet", greet);
inc_enum();
}
```
What appears to be happening is a change in python3.11:
https://docs.python.org/ja/3.11/whatsnew/3.11.html
The PyType_Ready() function now raises an error if a type is
defined with the Py_TPFLAGS_HAVE_GC flag set but has no traverse
function (PyTypeObject.tp_traverse). (Contributed by Victor
Stinner in bpo-44263.)
and indeed, the enum types are created without a traverse function but
with the HAVE_GC flag set.
It doesn't at first glance look like the code for boost1.80 is different.
A Python/boost expert is now needed.
Regards
Alastair McKinstry
mckins...@debian.org
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Re: change in the extention importation with 3.11
On 06/12/2022 16:13, PICCA Frederic-Emmanuel wrote: There is a fix from the upstream around enum. https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013 Fix enum_type_object type on Python 3.11 The enum_type_object type inherits from PyLong_Type which is not tracked by the GC. Instances doesn't have to be tracked by the GC: remove the Py_TPFLAGS_HAVE_GC flag. The Python C API documentation says: "To create a container type, the tp_flags field of the type object must include the Py_TPFLAGS_HAVE_GC and provide an implementation of the tp_traverse handler." https://docs.python.org/dev/c-api/gcsupport.html The new exception was introduced in Python 3.11 by: python/cpython#88429 an opinion ? I'd favour that being added to boost1.74. It would fix my ecflow bug (#1024911). A minor (?) fix also needed for Swig wrapping too (#1024555) -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1061366: python3.12: Python3.12 segfaults on python-xarray testsuite
Package: python3.12 Version: 3.12.1-2 Severity: serious Justification: 4 X-Debbugs-Cc: debian-python@lists.debian.org Python3.12 segfaults on the unittest suite for python-xarray (2024.01.0, head of tree in debian/latest) Unfortunately I cannot get a core dump yet to be more specific; this is on arm64 at least. -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1063521: ITP: pymbolic -- Easy Expression Trees and Term Rewriting library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: pymbolic Version : 2022.2 Upstream Contact: Andreas Klöckner * URL : https://github.com/inducer/pymbolic * License : MIT/X Programming Lang: Python Description : Easy Expression Trees and Term Rewriting library I am packaging this as Pymbolic is a small expression tree and symbolic manipulation library. Two things set it apart from other libraries of its kind: * Users can easily write their own symbolic operations, simply by deriving from the builtin visitor classes. * Users can easily add their own symbolic entities to do calculations with. Pymbolic currently understands regular arithmetic expressions, derivatives, sparse polynomials, fractions, term substitution, expansion. It automatically performs constant folding, and it can compile its expressions into Python bytecode for fast(er) execution. It is not expected to be a replacement for Sympy, which is more complex.
Re: Join the Debian Python Modules Team
Raphael Hertzog wrote: Hello, A few weeks ago the Debian Python Modules Team has been created to collaboratively maintain packages of Python modules. The upcoming changes are a good opportunity to invite all maintainers of python modules to join the team : - python 2.1 and 2.2 have been dropped from unstable [4] - python 2.4 will shortly be the default python version - the packaging will probaly evolve to facilitate transitions - python 2.5 alpha has been published The team will work very much like the Debian Perl Group[1] and the goals are similar except that we're going to work on python modules ;-) Hi, I'm the maintainer of newt, a console-UI toolkit that includes the python-newt package. So I've joined the list ... You can add me to the alioth developers, though I don't expect to be making commits. Congrats for the work to date; time to check if python-newt will work with 2.5 ... Regards Alastair McKinstry <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-xarray test failures
Hi Julian Upload to unstable done. Regards Alastair On 24/04/2025 07:37, Julian Gilbey wrote: Hi Alastair, It seems to be fine in experimental (though it is only debci-tested on amd64 and arm64), so please do go ahead and upload -4 to unstable. You don't need to request an unblock at this stage; see https://release.debian.org/testing/freeze_policy.html#soft Best wishes, Julian On Mon, Apr 21, 2025 at 03:39:21PM +0100, Alastair McKinstry wrote: H Anathanu A patch to fix this has just been uploaded. Once it is safely tested in experimental, I'll request an unblock. There was somehow a buggy -2 upload that missed the actual patch in d/rules Best regards Alastair On 19/04/2025 11:56, Ananthu C V wrote: Hi Alastair, python-xarray currently reports several test failures[0]. If the package migrates to testing, it'd fix #1100293[1] which otherwise could cause a lot of AUTORM. The test failures are on the 32bit archs (armel, armhf, and i386), as well as s390x. The failures on 32bit archs don't look serious to me as they look like either intended for 64bit, or false negatives. In that regard, I have a patch that'd disable those failing tests conditionally on 32bit archs[2]. I can't, however, push it to the team repo since it looks like the changes for the previous upload (as well as the debian tags for the last two uploads) was not pushed. If my patch seems reasonable to you, I can push it and do a team upload once you push your changes to the repo, or add an MR if you'd prefer that. As for the test failures on s390x, that comes from uninstallable build-depends which tracks down to magics++ not building on s390x[3] (and other archs). So either that needs to be fixed, or python-xarray and rdeps have to drop s390x. [0] https://ci.debian.net/packages/p/python-xarray/ [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100293 [2] https://salsa.debian.org/weepingclown/python-xarray/-/commit/23bb201a0ac7ddab59e368cd342516d90ef8e47a [3] https://buildd.debian.org/status/package.php?p=magics%2B%2B -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie @amckins...@mastodon.ie Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff Julian -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie @amckins...@mastodon.ie Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Re: python-xarray test failures
Thank you, Apologies I've been away and connectivity (and responsiveness) was intermittent. Regards Alastair On 28/04/2025 07:16, Julian Gilbey wrote: I've just uploaded -4 to unstable, which is identical to -3 in experimental but with a new changelog entry: python-xarray (2025.03.1-4) unstable; urgency=medium * Team upload * Push to unstable -- Julian Gilbey Mon, 28 Apr 2025 06:43:27 +0100 Best wishes, Julian On Fri, Apr 25, 2025 at 03:00:12PM +1000, Stuart Prescott wrote: Hi Alastair Thanks for working on these failing tests. I'm not sure that the uploads are going where you intend, however: $ grep ^python-xarray debian/changelog | head -2 | tac python-xarray (2025.03.1-2) experimental; urgency=medium python-xarray (2025.03.1-3) unstable; urgency=medium $ rmadison -s unstable,experimental python-xarray python-xarray | 2025.03.1-2 | unstable | source python-xarray | 2025.03.1-3 | experimental | source that is, the upload for unstable went to experimental, and the upload for experimental went to unstable. (btw I think this is the sort of thing that lintian will point out if you run it against the .changes file) That also means that these changes haven't fixed the underlying issue: CI for 2025.03.1-2 is still failing on multiple architectures (and there are no changes in 2025.03.1-3). regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie @amckins...@mastodon.ie Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Re: python-xarray test failures
H Anathanu A patch to fix this has just been uploaded. Once it is safely tested in experimental, I'll request an unblock. There was somehow a buggy -2 upload that missed the actual patch in d/rules Best regards Alastair On 19/04/2025 11:56, Ananthu C V wrote: Hi Alastair, python-xarray currently reports several test failures[0]. If the package migrates to testing, it'd fix #1100293[1] which otherwise could cause a lot of AUTORM. The test failures are on the 32bit archs (armel, armhf, and i386), as well as s390x. The failures on 32bit archs don't look serious to me as they look like either intended for 64bit, or false negatives. In that regard, I have a patch that'd disable those failing tests conditionally on 32bit archs[2]. I can't, however, push it to the team repo since it looks like the changes for the previous upload (as well as the debian tags for the last two uploads) was not pushed. If my patch seems reasonable to you, I can push it and do a team upload once you push your changes to the repo, or add an MR if you'd prefer that. As for the test failures on s390x, that comes from uninstallable build-depends which tracks down to magics++ not building on s390x[3] (and other archs). So either that needs to be fixed, or python-xarray and rdeps have to drop s390x. [0] https://ci.debian.net/packages/p/python-xarray/ [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100293 [2] https://salsa.debian.org/weepingclown/python-xarray/-/commit/23bb201a0ac7ddab59e368cd342516d90ef8e47a [3] https://buildd.debian.org/status/package.php?p=magics%2B%2B -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie @amckins...@mastodon.ie Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
