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.
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
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
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: 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
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
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: 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.
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.
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, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#864778: ITP: fparser -- Python parser for the Fortran language
Package: wnpp Severity: wishlist Owner: Alastair McKinstry <mckins...@debian.org> * Package name: fparser Version : 0.0.4 Upstream Author : Rupert Ford <rupert.f...@stfc.ac.uk> * 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#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#841277: ITP: usagestats -- Python module to collect usagestats from users
Package: wnpp Severity: wishlist Owner: Alastair McKinstry <mckins...@debian.org> * Package name: usagestats Version : 0.5 Upstream Author : Rene Rampin <remiram...@gmail.com> * 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#815893: ITP: python-jpy -- Bi-directional Python-Java bridge
Package: wnpp Severity: wishlist Owner: Alastair McKinstry <mckins...@debian.org> * 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.
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 plenty of time to fix or adjust to issues we find but there are a ton of packages, so all help is greatly appreciated. Let's make Python 3.5 the easiest upgrade ever. Cheers, -Barry -- Alastair McKinstry, alast...@sceal.ie, mckins...@debian.org, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 , alast...@sceal.ie , mckins...@debian.org 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: 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 , alast...@sceal.ie , mckins...@debian.org 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: 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]
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]
