Re: Stackless Python
Ethan Glasser-Camp writes: > Hi guys, > > I asked on #debian-python a few days ago about the odds of Stackless > being packaged. MadCoder, speaking unofficially, told me that this > question would be better to ask on this list, and suggested I do some > research about the compatibility between Stackless and vanilla > CPython. I went to the Stackless mailing list and asked some questions > and I think the answer is: "If Stackless isn't binary compatible, it > is considered a bug in Stackless." > > Here is the thread I started: > > http://www.stackless.com/pipermail/stackless/2006-August/001876.html > > .pyc files should be compatible (compiler and interpreter are not > changed by Stackless). > > Stackless is 100% compatible with pure Python code. > > There has been an occurrence of a C extension (PyQT) not being binary > compatible, but this is a rare case, and the Stackless people are > interested in resolving the bug if it can be reproduced. long time ago, stackless was distributed as a patch to python. is this still the case? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Manoj Srivastava writes: > policy document. The current version, and future updates, are to be > found at http://www.golden-gryphon.com/software/manoj-policy/ unreachable, comments for the posted text follow > 1.1. Categorization of Python software > >Program/script > > This consists of software directly called by an end user of >external program, and is independently interpreted by the Python >interpreter. Usually starts with the magic bytes #!, with the >interpreter being /usr/bin/python* or /usr/bin/env python*. > >Modules > > This is code included in python "programs/scripts", and not >invoked directly (serving as library modules in compiled >languages). > > Modules can be categorized under two orthogonal criteria: firstly, based >on the whether or not they are implemented purely in python, like so: > >Pure Python Module > > These are python source code, to be interpreted by the Python >interpreter just like program/script code is, and may work across >many versions of Python. > >Extension Module > > Extensions are C code compiled and linked against a specific >version of the libpython library, and so can only be used by one >version of Python. There should be no reason to link the extension against the python library. Usually many extensions which are developed upstream on Windows do link by default to libpython. Other extensions linking against libpython are those with build infrastructure maybe predating distutils. python-semanage is an example (and should not link using -z defs). Another thing to mention here is a "Python package", a directory containing an __init__.py file plus modules and extensions. > Another way of categorizing modules is based on whether or not they are >available for use by third party scripts/modules. > >Public > > Public modules are available for use in other Python scripts or >modules using the import directive. They are installed in one of >the directories: > > /usr/lib/pythonX.Y > > This directory is reserved for official python > modules. No other package apart from upstream > official Python modules should install modules in > this directory. > > /usr/lib/pythonX.Y/site-packages > > This is where most add-on modules live. Often, > packages do not directly install modules here, but > instead use utility packages like python-central and > python-support to byte compile and install modules as > needed. > > /var/lib/python-support/pythonX.Y > > Packages using python-support actually have their > packages linked in from this directory, but no > package should directly install modules there > directly. See the documentation for python-support > for details. maybe shorten that to "all directories in sys.path"; not sure if an explicit list of directories is needed. > Packages may install public Python modules in directories >specific to Python packaging utilities -- which specify the >directories under which such modules should be droppped, and the >the structure of these directories is defined by the utilities >themselves. Please note that these directories are not in the path >for Python, and are not available for modules to be imported from. >At the time of writing, such uility specific directories include: ^^ > >/usr/share/pycentral >/usr/share/python-support These location are tool specific and should not be referenced explicitely in the packaging scripts (debian/rules) > 2. Goals of the new Python policy > > The new policy is designed to reduce the load on people packaging python >modules when one of the following events occur, and, by the dint of doing >so, ease the transition that occur as new Python versions are introduced, >old ones removed, and as the default version of Python changes, with >minimal impact on the target system. In case of the following events: No, not the whole design goal. Although the document is titled "developer's view", the other goals should be mentioned as well. These are meant to work around processes in debian which are currently suboptimal, but unlikely to change. - The need to support more than one version of a python runtime or to support different implementations was seen. It takes a while until applications
Re: handling packages built supporting the "current" python revision
Alexandre Fayolle writes: > Hi, > Am I expected to upload an unchanged 0.2.0-3 package so that it will get > rebuilt with python2.4 as the default python version, or is something > going to happen automatically, for instance a binary only NMU ? a binaryNMU should be sufficient; if you know that the package can be binNMU'ed (i.e. no too strict dependencies between arch/indep packages), please send a mail to -release. We should file binNMU requests for other packages as well. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
removing python2.3
With zope2.8 removed, the last package depending on python2.3 is gone, so we are technically able to drop the support for python2.3. As currently some packages have reverse dependencies on python2.3, removing python2.3 without any other action, would open new RC reports which doesn't seem to be appropriate at this point. The following issues should be fixed before: 1) removing packages only needed for python2.3: python-fixedpoint (replaced by decimal) python-cjkcodecs python-iconvcodecs (maybe) decompyle (2.3 only) 2) fixing packages having hardcoded dependencies on 2.3: i.e. optcomplete, will need a rebuild, of the archive / part of the archive to identify those packages. 3) removing the rdepends from packages (likely to be packages using the versioned interpreter name) vegastrike subterfugue serpento rekall python2.3-lasso (not yet converted?) python2.3-dictdlib (not yet converted?) python-zodb python-wxgtk2.4 python-quixote python-pypoker-eval python-pymetar python-poker2d python-poker2d python-poker-network python-plplot python-nautilus python-metakit python-libhamlib2 pycocuma papaya lodju libhk-kdeclasses7 knoda k3d gnome-mud ghextris gaby duplicity dcgui crossfire-server capisuite bacula-sd bacula-fd bacula-director-sqlite3 bacula-director-sqlite bacula-director-pgsql bacula-director-mysql - some package have to be updated to drop 2.3 support; I put updated packages at deb http://people.debian.org/~doko/python ./ If more packages are needed for testing the removal of python2.3, I'll add these to this archive. - rebuild extension packages to drop 2.3 extensions. 2 and 3 can be done now and would be a prerequisite for the python2.3 removal. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python 2.3
Thomas Bushnell BSG writes: > On Wed, 2006-12-20 at 19:51 -0800, Steve Langasek wrote: > > On Tue, Dec 19, 2006 at 11:17:03AM -0800, Thomas Bushnell BSG wrote: > > > The python team has apparently decreed that python 2.3 will not be in > > > etch. This forces every package to use the new version. Surely it is > > > too late in the release cycle to be risking regressions in this way? > > > > The python team has expressed concern about the security supportability of > > python2.3 in etch. Extension packages built with the current version of > > python-all-dev and friends already have no support for python2.3; shipping > > python2.3 in stable for the benefit of a handful of reverse dependencies is > > a genuine concern, particularly when those reverse-deps work just fine with > > python 2.4. > > And yet, this isn't the only case. Users actually use the programs in > Debian, not just other parts of Debian. Why is python 2.3 some sort of > security nightmare? And what suddenly happened to make it one? python2.3 doesn't get attention by upstream anymore. there was a 2.3.6 release to address a security related issue (which is addressed for sarge and current testing), but even for the 2.4 series no new upstream bug fix releases are announced for the future. If you ask why 2.5 isn't the default for etch: by the time upstream versions were frozen for etch we didn't have new upstream releases for packages depending on 2.5. it's still difficult at this point of time (Dec 2006) to make 2.5 the default and rely on upstream releases for depending packages. An explicitely stated goal of the release team was to reduce the number of supported python versions for the next stable release. We did include three python versions for sarge (2.[123]). To reduce that count we do have to drop 2.3 (prefering 2.5 over 2.3). > What about users who are depending on Python 2.3? Do they just lose? yes. and even if the transition to the new default version was late, you do loose. > It seems to me that for things like this, our releases should always > have the next-oldest version as an option for those users. No. there is no reason to do so. The two reasons we did come up with the support of more than one python version are: - some applications are very late to adopt a new python upstream version (the last version to provide compatibility with 2.4 was zope2.x). Debian currently doesn't have a process of freezing packages for a release besides the toolchain. - the inability to manage the transition of packages from unstable to testing. If you do want to work around the current migration process from unstable to testing you have to support the python version in testing and unstable. Every proposal to just support one python version in Debian bares any sense of Debian reality. To conclude, the support of multiple python versions is not meant at all as an excuse for lazy debian maintainers depending on python for not following upstream python development. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
Alexandre Fayolle writes: > On Tue, Jan 02, 2007 at 03:20:10PM +0100, Loïc Minier wrote: > > Hi, > > > > On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: > > > I tried to do some development using Etch's python2.5, but it fails to > > > import pygtk and gtk modules and this is a regression IIRC. v2.4 works > > > fine. > > > > "pyversions --supported" only returns python2.4, so the source package > > does not build the 2.5 flavor. Either patch pygtk's debian/rules or > > patch pyversions and rebuild pygtk. > > Happy new year everyone. > > Am I the only one with a mixed feeling about this? I mean, we spent time > last spring updating our packages to use the new Python policy, write > nice loops in debian/rules to build for all versions specified by > `pyversions -r -v`. Now we would need to tweak the Makefile again and > clutter it with a hardcoded "2.5" in the list even though this version is > requested debian/control (or in some other place if you chose the other > way without XS-Python-Version). > > I have to admit that I am a bit disapointed by this, to say the least. > Why are we shipping python2.5 in etch if we don't ship the python > extension modules people expect to find (PIL, mx.DateTime, Numeric...) When etch/sid went into UVF after the 2.5 release, many depending packages and extensions were not yet usable/buildable for 2.5. Adding 2.5 was not considered an option after talking with the release team (Andreas Barth), because it would have introduced a lot of RC reports, which either needed to be fixed by new upstream versions or disabling 2.5 support for this extension. Explicitely adding support for 2.5 on a per package base doesn't introduce these extra RC failures during our release process at the cost of having the burden on the package maintainer, not the release team. Looking at mx and numeric, support for 2.5 can be added, but for example PIL explicitely states in the 1.1.6 release notes that this version adds complete support for 2.5. Maybe support for 2.5 for all extensions looks possible now, but at the time of the UVF it wasn't. You might want to create a python-etch repository and rebuild all extensions where possible to support 2.5, and add new upstream versions where necessary. Once done, propose the versions in this repository to the release team, but I doubt it will be allowed into etch. Mixed feeling yes, but IMO unavoidable with our release schedule for etch. Matthias
Re: python2.5 fails to import pygtk and gtk modules
Loïc Minier writes: > On Tue, Jan 02, 2007, Pierre Habouzit wrote: > > or do that "the clean way": edit /usr/share/python/debian_defaults > > This is slightly better indeed. My personal taste wouldn't allow me to > edit a file under /usr, but I suppose a diversion would achieve a > similar job. > > It would be nice to override this with /etc/python/debian_config. no, this leads to build environments producing differing packages depending on the configuration.
preparing for python2.5 / python -dbg packages
The current python2.4 and python2.5 package in testing and unstable are ready for the transition to python 2.5 as the default python version. However many packages still need updates for python 2.5, either as a rebuild to build an extension module for 2.5, or to fix a problem with python2.5. To ease the migration of these packages to testing, these packages should be fixed first and migrate to testing before we make python 2.5 the default python version. We still keep support for python 2.4 in the archive, because some packages do not work yet with 2.5 (zope2.x being the most important one). There is no release date for python 2.6 yet. Looking at release intervals we may see a 2.6 release before the lenny release, but looking at the speed that third party code is adopted for a new python upstream release it seems to be unlikely to make 2.6 the default python version for lenny. Still hoping to drop support for 2.4 once a zope2.x version supporting 2.5 is released... Some python 2.5 compatibility patches can be found at http://packages.qa.debian.org/ in the Ubuntu diff, if a fix was applied in an upload to Ubuntu; in most cases I didn't file an explicit bug in the BTS. Please email me if you want help in extracting/applying the patch for the Debian package. Since sarge we do build pythonX.Y-dbg packages, which hold the python interpreter build --with-pydebug. Extensions need to be rebuilt to be loadable with this debug build. Some extension modules have been rebuilt for Ubuntu feisty to support the debug interpreter build. A short build description and a list of packages can be found at [1]. I will file wishlist bug reports to package these for Debian as well. Matthias [1] https://wiki.ubuntu.com/PyDbgBuilds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
Ondrej Certik writes: > On Dec 5, 2007 8:10 PM, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > > On 05/12/07 at 13:37 +0100, Bernd Zeimetz wrote: > > > >> 1. Why is there the build-conflict in the first place? This is the > > > >> question to original maintainers (Marco, Alexandre, Jose, Matthias) > > > > > > > > I added the build-conflict because without it, dpkg-shlibdeps would > > > > make them depend exclusively on blas and lapack, instead of depending > > > > on the virtual package (because all other packages provide blas and > > > > lapack) > > > > > > The packages should not be installed on the buildds anyway, so I think > > > ti shoudl work without build-conflicts. > > > > There's no garantee about which packages are *not* installed on the > > buildds, since packages are not uninstalled after builds. > > Build-conflicts is the good way to solve that. > > So would do you suggest? Just to wait until python-numpy gets build on > buildbots? Or do you suggest to take some action (which)? :) help getting refblas3, lapack3 and atlas getting built with gfortran, fix the shlibs lines in these packages and then rebuild the python-numpy package. If you're interested, please join the debian-toolchain list or have a look at the archives. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: python docs in contrib?
Sanghyeon Seo writes:
> 2007/12/17, Tshepang Lekhonkhobe <[EMAIL PROTECTED]>:
> > > > Hi,
> > > > I was surprised to find python2.{4,5}-doc in contrib and wondered why?
> > > it needs latex2html to build.
> > Are there any free near-equivalents?
>
> There are, like hevea and tth, but as Python documentation says, "The
> application of LaTeX2HTML to the Python documentation has been heavily
> tailored".
>
> I don't think anyone tried (or dared) to build Python documentation
> with hevea or other replacements.
python2.6 doesn't need the latex2html b-d anymore.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian 4.1 and Python 2.5
> From: =?utf-8?q?Adri=C3=A1n_Ribao_Mart=C3=ADnez?= <[EMAIL PROTECTED]> > To: debian-python@lists.debian.org > Subject: Debian 4.1 and Python 2.5 > Date: Wed, 13 Feb 2008 21:40:26 +0100 > > Hello, I'd like to know if Python 2.5 will be the default version of python > in Debian 4.1. > > Thank you. Yes. If outstanding issues are solved; people want make you believe that NMUs are enough to complete the transition. What needs to be done: - Look for code which frees memory with PyMem_DEL, which was allocated with PyObject_NEW (must use PyObject_Del instead). Have done this for a few modules. Care to search the archive and do the rest? - Make some packages build for all supported python versions, so that the transition is manageable. Done this wxwidgets2.6. Done this for subversion (but the package maintainers says that the package dependencies und b-d's are neglectable, just java, db, ruby, python, apache, neon, and else). Maybe somebody from the release team could argue with the package maintainer... There were no activities after my mail from http://lists.debian.org/debian-release/2008/01/msg00227.html I'll try to address these, but please don't expect those to be done before Feb 23/24. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian 4.1 and Python 2.5
Marc 'HE' Brockschmidt writes: > Matthias Klose <[EMAIL PROTECTED]> writes: > > Yes. If outstanding issues are solved; people want make you believe > > that NMUs are enough to complete the transition. What needs to be > > done: > > > > - Look for code which frees memory with PyMem_DEL, which was > >allocated with PyObject_NEW (must use PyObject_Del instead). > >Have done this for a few modules. Care to search the archive > >and do the rest? > > Just did that and gave the list to doko, bugs should be filed > soonish. 62 packages look like they might be affected, but some of them > are false positives. these can now be seen at http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=goal-python2.5;[EMAIL PROTECTED] > > - Make some packages build for all supported python versions, so > >that the transition is manageable. Done this wxwidgets2.6. Done > >this for subversion (but the package maintainers says that the > >package dependencies und b-d's are neglectable, just java, db, > >ruby, python, apache, neon, and else). Maybe somebody from the > >release team could argue with the package maintainer... > > Looks like subversion would really profit from this, will prod the > maintainer about it. thanks. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
handling /usr/local/lib/python2.x/site-packages in sys.path
Currently Debian's python has /usr/local/lib/python2.x/site-packages in sys.path allowing for installation of local modules. Barry did point out that this conflicts with a python installation, where /usr/local is the default prefix, and the system python gets modules from the local installation. Some suggestions were made to fix this: - add an env var to not include /usr/local/lib/python2.x/site-packages when the env var is set. Keeps standard behaviour without modifications and allows people to remove it from sys.path. But requires the user to know about that option. - add another path (e.g. /usr/local/python/lib2.x/site-packages), and remove the /usr/local/lib/python2.x/site-packages path after the next release. Does provide an upgrade path, but doesn't solve the probem immediately. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Python developers, make your packaging concerns known (was: Current distutils-sig discussion on package management)
Ben Finney writes: > Ben Finney <[EMAIL PROTECTED]> writes: > > > The Python distutils-sig group is currently discussing the topic of > > package management, how setuptools interacts with package managers, > > and what changes are desirable as a result. > > > > http://mid.gmane.org/[EMAIL PROTECTED]> > > [...] > > > > I urge anyone who's had problems getting Python setuptools and > > Debian package management working together, to join this discussion > > so that your issues can be considered in whatever changes ensue. > > To reiterate: This discussion is happening *now*. If ever you have > looked at Python packaging (e.g. distutils or setuptools) and said > "no, *no*, NO!", then this is the time to get involved so that changes > can be made for the better. > > I have no knowledge of *what* the problems are; I only know that there > are people in this group who persistently complain about how Python's > current packaging practices are broken with respect to Debian > packaging. the discussion on the python-dev and distutils-sig ML's is about packaging of eggs, not Python packaging in general. You can find a more complete thread on the python-dev ML, and a summary of the BoF discussion in the python.org wiki. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs that'll block python 2.5
Raphael Hertzog writes: > On Tue, 15 Apr 2008, Adeodato Sim
Re: should numpy be built with atlas?
Ondrej Certik writes: > On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose <[EMAIL PROTECTED]> wrote: > > Package: python-numpy > > Version: 1:1.1.0-2 > > Severity: serious > > > > python-numpy now has an unconditional dependency on libatlas3gf-base, > > needing the "specialized" atlas libraries as a runtime > > dependency. Users still should have the option to use the standard > > blas and lapack libs instead of the untested/unmaintained atlas > > libraries in debian. > > Hi Matthias, > > I changed that on a request from a user: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489253 > > so should we revert this change? I.e. should numpy not be built with > atlas support? This will make it quite slow in Debian. > > CCing to debian python as well to get more opinions on this. afaiu this has nothing to do if blas/lapack or atlas are used; apparently _dotblas.so is not built when just using blas/lapack. this seems to be the real bug which we should fix. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should numpy be built with atlas?
[EMAIL PROTECTED] writes: > On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose <[EMAIL PROTECTED]> wrote: > > Package: python-numpy > > Version: 1:1.1.0-2 > > Severity: serious > > > > python-numpy now has an unconditional dependency on libatlas3gf-base, > > needing the "specialized" atlas libraries as a runtime > > dependency. Users still should have the option to use the standard > > blas and lapack libs instead of the untested/unmaintained atlas > > libraries in debian. > > The problem is that the new (>1.0) numpy building system needs ATLAS > at compile time to enable fast matrix-multiplication. If ATLAS is not found > at compile time, numpy.core._dotblas.so is not built and slow matrix > multiplication is used even if the end user has ATLAS installed. In the old > numpy _dotblas.so was always compiled using refblas and the end user > would still have had the option of using ATLAS. I'm not sure I understand > why ATLAS is now needed at compile time, but look here: > http://scipy.org/scipy/numpy/ticket/667 > and here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464784 > > I think python-numpy should stay as it is now and a bug-wishlist should be > reported to the atlas package to encourage packaging of the new stable > version (3.8.2). Filing a ticket on numpy trac may help, but the fate of > ticket 667 seems to indicate that there's no will of fixing this bug > upstream... thanks for the update. Looking at the blas package, I see that the cblas library is included in libblas3. So it looks like the numpy check is wrong, testing for a package name, and not for a feature. This seems to explain why it did work in etch, and this should be fixed in python-numpy. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pyinstall: A New Hope
> I'd be interested to know people's experiences with trying it out for > packaging Python distributions for Debian. how would it help? a Python distribution is a set of source/binary packages which we do package separately. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: numpy 1.2.1, switching to git?
Bernd Zeimetz writes: > Cyril Brulebois wrote: > > Tristan Seligmann (20/12/2008): > >> My personal preference ordering would probably be: > >> > >> hg, bzr, svn, git > > > > git, FD, * > > +1 :) > > > http://whygitisbetterthanx.com I only trust my own comparsion without any date and version numbers. And honestly I don't care about a checkin of the usual 2-5 files taking half a second longer. What annoys me most with git is the steep learning curve and the non-intuitive UI, therefore I do prefer bzr over hg over svn over others. Matthias Not a member of the modules team, just listed as uploader of some of the packages. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
Ondrej Certik schrieb: > Hi, > > I finally packaged the newest uptream and committed all fixes into our > svn repo for numpy. Kumar (or others), do you think you could please > test the package? numpy becomes big. see https://launchpad.net/bugs/309215. In the past the parts depending on external numeric libraries were splitted out into a separate package, but the package structure now makes it difficult to keep this split. Please consider splitting out a python-multiarray (seems to be straightforward, maybe keep it in its own name space) or a python-numpy-core/-base package (unsure where to make the split). > There is a problem with documentation, that it depends on sphinx-0.5, > which is currently only in experimental. And also upstream doesn't > have it in the tarball. I originally fixed that by > adding a new target into debian/rules, that downloaded the upstream > tgz, unpacked, eported the doc/ directory from upstream svn and then > packaged it again. But since it still doesn't build in pure sid, I > rather fixed the build with the current upstream tarball. As long as you can fulfill the dependencies with build dependencies all should be ok. However python itself now uses sphinx from the sphinx trunk. very nice :-/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Presentation and some questions/remarks about numpy/scipy packages
David Cournapeau schrieb: > Hi, > > I am a developer of numpy and scipy, and I would be interested in > helping numpy/scipy debian packages to be better on both Debian and > Ubuntu. As a user of both Debian and Ubuntu, and one of the main > developer working on build issues for numpy/scipy while not a build issue, the modularity for an install is painful. numpy is too big (including it's dependencies) to be installed on a CD (Ubuntu live CD/alternate CD), however it is required by some other packages, which are itself not packaged in a modular way: pygtk requires for some obscure (couldn't find code using this) the multiarray extension and depends on it (although an exception is thrown at runtime if the extension is not found). while pygtk could be better packaged, you could do the same with numpy by splitting out some sub-packages. Unfortunately splitting out python subpackages is not that easy: Having numpy/core/multiarray.so in it's own binary package would require packaging python-multiarray with the files: numpy/__init__.py numpy/core/__init__.py numpy/core/multiarray.so with the __init__.py files being empty files. Installing on top of this the python-numpy package would require to replace (divert) the __init__.py files with the __init__.py files as found in numpy (packaging tools like dpkg and rpm don't allow overwriting of files without special care). Consider that I additionally might want to split out stuff only needed at runtime (splitting out distutils, tests and include) and legacy stuff (numarray, numeric), I have to add more variants of __init__.py files and maintainance becomes harder. What I really want is to be able to ship independent subpackages as it's own package. Having e.g. the multiarray extension in a subpackage seems to be worse than having it as a toplevel module or in its own namespace. Background in https://bugs.launchpad.net/bugs/309215 Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Piotr Oz.arowski schrieb: >> - 2.5 is superseded by 2.6; currently there doesn't seem to be >>a reason to ship 2.5 and modules for 2.5 with the next stable >>release. The upstream 2.5 maintainance branch doesn't see bug >>fixes anymore, only security releases will be made from this >>branch. > > What about a smooth upgrade path for those who use Python2.5 for their (3rd > party) applications? I think Python 2.6 should be default in Squeeze and > Python > 2.4&2.5 in supported. always having the default version of the stable release included in the next release would mean that Debian releases keep up with Python release, or we would end up shipping more than two 2.x versions. Same if 2.7 gets released in time. >> The path /usr/lib/pythonX.Y/site-packages is not found on sys.path >> anymore. > > is "local/" missing in this path or do you want to simply rename site-packages > into dist-packages? /usr/local/lib/pythonX.Y/site-packages isn't found in sys.path as well. >> About the name: Discussed this with Barry Warsaw and Martin v. Loewis, >> and we came to the conclusion that using the same directory name for >> both locations would be the most consistent way. >> >> This change should make the request to conditionalize the inclusion of >> /usr/local/lib/pythonX.Y/site-packages into sys.path obsolete. > > if I understand this correctly, local installations (including ez_install > ones) > will use /usr/local/.../site-packages and the ones used by administrators (who > know about --install-layout=deb) /usr/local/.../dict-packages, and the > site-packages will not be in default sys.path, right? No, /usr/local/lib/pythonX.Y/site-packages will only be used if you install your own python, and use this interpreter to call setup.py install. When using the python (>= 2.6) provided by Debian without to call setup.oy install --install-layout=deb, the installation will go to /usr/local/lib/pythonX.Y/dist-packages, without --install-layout it will go to /usr/lib/pythonX.Y/dist-packages. > If yes, then although I love the idea of "solving" the `sudo easy-install > MyModule` really annoying issue (last time I raised it here[1], see also > Christoph's "Why you should not use easy_install carelessly on Debian"[2]), > what's a purpose of having local site-packages if installing there will have > no > effect. Or do you want to keep it for local *Python* interpreter > installations? It is not kept, it is the standard site-packages for "local *Python* interpreter installations". > I really like the idea of using the same location for both tools, please note > that you'll have to change pycentral to use something like /usr/lib/pyshared > (for Python extensions) where is the advantage of having a /usr/lib/pyshared? > yes, that's a problem, but I think we should do it step by step, first: > all packages should ship .py and .so files in the same directories (so that > dpkg can handle conflicts again), then we'll think about using common entry in > sys.path (and/or merging helper tools or making it possible to choose one of > them to do all the stuff) I can agree on "later", if it does mean "for squeeze". >> The disadvantage of this approach is the limitation to a specific set >> of python versions (the package will have a dependency of the form >> "python (<< X.Y)", which we already have for architecture dependent >> packages containing extensions. This would add this kind of >> dependency to all architecture independent python-* modules and then >> requires an upload of these packages for each python transition as >> well. Afaics this would not affect a transition or a set of >> transitions to testing, because no new dependencies on new versions of >> shared libraries are introduced during these uploads. This approach >> certainly has an impact on the ftp archive and its mirrors, but I >> can't say if this would be an issue or not. > > I don't like python (<< X.Y) dependencies, it's so... old-policy like. > Not a good idea, IMHO well, just "not liking" is a weak argument. >> - The removal of a python version will cause the need for massive >>rebuilds. because many python extensions currently have >>dependencies of the form pythonX.Y-foo. There is nothing what >>can be done now for the upcoming removal, but those dependencies >>should not be there by default. This is 2.4 of the python policy, >>but many packages tend to ignore that. > > python-support supports namespace packages and it does it good. I didn't want > it to be enabled by default but since Joss provided a way to disable it (see > #459468) I think it's OK. > > python-central should implement the same behaviour, IMHO As I did write above, the support for namespace packages should be implemented using diversions. It's ok to generate these by a packaging helper. > Just one more issue: what about "current" issue? Although I protested when > others wanted to remove it, now I agree it's useless. All packages that
Re: Python related changes for unstable/squeeze
Ondrej Certik schrieb: > Hi Matthias, > > thanks for all the work you do. I have one question: > >> - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, >> but will prepare 3.1 packages for experimental and upload those >> to unstable with the final release or a late release candidate. >> The 3.1 release is planned for April 2009. > > It would really help if Debian had python3.0, becuase it would help > me, as upstream, to port my software. Currently I have to compile > python3.0 from the ubuntu source package. If ubuntu can have it, why > not Debian? I will provide packages on people.debian.org, which should help for the upstream work. python-3.0 is very short lived and I do want to avoid an unnecessary transition. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fwd: SONAME for python modules is bad?
On 25.07.2009 05:47, Matthew Johnson wrote: On Sat Jul 25 11:28, Mathieu Malaterre wrote: On Fri, Jul 24, 2009 at 7:45 PM, Max Bowsher wrote: ... It would be extremely nice too if all wrap language would adopt the same convention. So that toolkit such as VTK/ITK/GDCM wrapping their interface into multiple languages (namely: Tcl, Python, Java, C#) could simply decide: (1) Allow SONAME (2) Use a directory convention libfoo-$SOVERSION/$NAME.so for packaging mutiple modules. It is unclear to me what you are trying to standardize. How does one install multiple version of the same python/java/cli module ? (speaking for Java) At the moment, you don't. Wrong. It's already done, including a version in the file name and having a symlink to an unversioned jar. It should be possible to do something similiar with jni bindings. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new dh_python proposal
On 03.08.2009 19:16, Piotr Ożarowski wrote:
Just a follow-up the clear some things up:
* about the -common package (i.e. pysupport namespace issue):
- it's not a must, if one package can act as namespace provider,
there's no need to provide another one, of course,
- being able to list all files provided by packages is something we
really want to have
packaging the zope tree by choosing existing packages to include the __init__.py
files did work well. Afaik there's no other package in debian not shipping
files, and then creating these.
* dh_python[1] will try to avoid moving files to pyshared if
package supports only one Python version (f.e. the latest one)
* py{,3}compile will support -X/--exclude option
I maintain one module that uses site-packages to keep templates with
.py files inside and although I patched it to move these files outside
site-packages, I know that not every maintainer will want to do that,
so -X will disable byte compilation of files for given directory/file
* about lack of XS-Python-Version and debian/pyversions
- if available, both previous places will be used to get
minimum/maximum required Python version, it will complicate
detection of packages that need binNMU, so I want to drop both of
them at some point,
- dh/cdbs/dh_python will get minimum/maximum required Python versions
from Build-Depends{,-Indep} and/or python-all's Depends.
If one will need to build depend on newer version of
python{,-all,-dev} (due to some Debian specific changes) - tools
will ignore versioned dependencies that include dash sign or use the
lower one if two different dependencies are provided
(f.e. "Build-Depends: python-all-dev (>= 2.5.8), python-all-dev (>= 2.4)"
will be equivalent of "XS-Python-Version:>=2.4")
Why move this attribute from an explicit place to an implicit one? Encoding all
stuff in dependencies isn't that obvious. Indeed we do create new attributes
like Homepage, which were included before in the description.
* how to detect which package needs binNMU?
I think parsing Build-Depends{,-Indep}, Contents file and Depends
header will be enough to detect such packages, i.e. packages that:
- Build-Depends{,-Indep} on python-all{,-dev}
AND there's no<=X.Y) | pythonX.Y-dev" or
"python-dev (<=X.Y) | pythonX.Y" and Depend on
pythonX.Y
(i.e. "python (>=X.Y) | pythonX.Y" will NOT be in Depends)
[arch:all packages with hardcoded shebang due to default python not
being good enough]
- Build-Depends{,-Indep} on "python" or "python (>=X.Y) | pythonX.Y"
and there's no rtupdate script in binary package
[private modules without hardcoded shebang]
will need binNMU once new Python version will be added to the
supported ones
Is it really worth adding semantics to the build dependency/dependency fields
and instead removing the explicit information about version information?
> Advantages:
> * a lot less opportunities to break a system while installing / upgrading
>Python packages,
> * no more problems with packages that provide the same namespace and use
>different helper tool,
> * Python modules available out of the box (think about daemons),
I appreciate these goals and I'm fine to provide a wrapper for dh_pycentral if
the new dh_python implements these goals.
Matthias
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [kob...@debian.org: The future of Zope{2, 3} and Plone in Debian and Ubuntu]
On 02.07.2009 13:05, Jonas Meurer wrote: On 23/06/2009 Fabio Tranchitella wrote: Were you aware that we've renumbered the releases and inserted a less ambitious Plone 4, which should be in beta by the end of the year? It will run on (and require) Zope 2.12. Plone is finally joining the modern Python world. :-) I don't exclude to support Zope 2.x again in Debian and Ubuntu, but I really think that in this moment dropping the packages is the best solution: we will finally be able to drop python2.4. why not wait for zope2.12 with python2.5/2.6 support, upload that one to debian/unstable and afterwards file a request for removal for zope2.10/zope2.11/python2.4? I believe that a zope2.12 release candidate will be published within the next month, given that a beta2 has already been published on 27. of may. That way we would have a zope2 release available in debian/unstable all the time would. The zope2.12 release candidate was released last week. I updated the packaging in the zope team repository. An upload still requires some work, because some modules still need to be packaged. These are: Acquisition DateTime ExtensionClass Persistence RestrictedPython tempstorage zLOG zope.container zope.contentprovider zope.contenttype zope.deferredimport zope.formlib zope.lifecycleevent zope.pagetemplate zope.processlifetime zope.sendmail zope.sequencesort zope.site zope.size zope.structuredtext zope.tal zope.tales zope.testbrowser [zope-functional-testing] (UNRELEASED?) zope.viewlet zope.app.form zope.app.publication zope.app.publisher zope.app.schema All other zope dependencies are available as modular zope packages in unstable. Please have a look how these are packaged, and start packaging. As an interim solution it could be useful to include the still missing modules in the zope2.12 package until all these are packaged. The good news is that the schooltool project already did package a lot of these, so you "only" need updates to recent upstream versions, and an update from python-vanguardistas to python-van.pydeb (Brian might give more help on this). I know that not the whole zope team is interested in these additional modules, so I'm CCing the zope2.x uploaders directly to get involved with the packaging. I do not want to wait with the removal of python2.4 from unstable for too long, I think a short time without zope2.x in unstable is ok, while having three python2.x versions is too much. But it looks like zope2.12 based on python2.5 or python2.6 is doable for squeeze. Matthias [1] https://edge.launchpad.net/~schooltool-owners/+archive/ppa/+index?field.series_filter=jaunty&batch=200 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [kob...@debian.org: The future of Zope{2, 3} and Plone in Debian and Ubuntu]
On 20.09.2009 16:45, Jonas Meurer wrote: if i got it right then packaging the dependencies as seperate packages isn't an option for zope2.12, we'll have to include them within the zope2.10 source tarball. the reason for that is, that zope2.12 requires particular versions of the dependencies, and doesn't build even if minor versions aren't correct. this is the usual answer from an upstream with more than 50 dependencies. From my experience this based on the fact that upstream only wants to test and certify one configuration, and doesn't take responsibility for anything else. On the other hand a distribution tries to minimize the duplicate code in its distribution, and applies patches to packages to make these work. Look at OpenOffice, eclipse, etc. zope is not different. It's up to you as a packager to decide what you can maintain, and where you do want to duplicate sources. I do not want to wait with the removal of python2.4 from unstable for too long, I think a short time without zope2.x in unstable is ok, while having three python2.x versions is too much. But it looks like zope2.12 based on python2.5 or python2.6 is doable for squeeze. i didn't know that packaging zope2.12 is that timeconsuming at the time that i proposed to wait with removing python2.4 from unstable. so no objections against removal of pyhton2.4/zope2.10/zope2.11 from my side any longer. ok, I'll file a request for removal next week; zope2.x was the last package absolutely needing python2.4. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python-central NMU (python2.6 related)
Fyi, I replaced your NMU with my merge from Ubuntu, which already had these changes. I may have missed the "indentation problems", please file separate bug reports for these. Matthias On 03.11.2009 16:07, Piotr Ożarowski wrote: Hi Matthias, You uploaded new python-central package that fixed one indentation error in pycentral.py (which is ok, this bug had Severity=important in BTS). Since my NMU of python-central was still waiting in DELAYED (queue was disabled by ftpmasters) at that time, it didn't make it into unstable. Please let me know if it was just a coincidence and I can upload my changes again (I assume that if you would want to reject it, you'd add a comment over a month ago when I sent you my patch or you'd upload a new version before Thursday, when my 0.6.11+nmu1 was supposed to be uploaded to unstable). If it's ok with you, I'll upload my changes again this Thursday. Please note that when python-central will be fixed, we will be almost ready for your upload of python2.6 to unstable - the only remaining changes will be python-central based packages that do not define XB-Python-Version - let me know if you want me to change python-central to detect such packages and fix it in pycentral instead - I'll send you a patch. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new dh_python proposal
On 15.01.2010 14:19, Luca Falavigna wrote:
* broken modules that use __file__ incorrectly will work without problems,
OK, I'd still warn loudly if that happens, though.
there are other cases where some modules/extensions do encode paths in generated
"config" files, like sip and the qt/kde bindings. to avoid such problems it's
safe to call setup.py install with --install-layout=deb to have the files in the
final installation location.
* user installs new pythonX.Y package:
- bytecompile related symlinks (pycompile -V X.Y) - no need for a list of
files to compile at this point - all .py files in
/usr/lib/pythonX.Y/{site,dist}-packages will have to be byte-compiled,
Suppose I have foo package installed, then I install pythonX.Y, so
symlinks will be byte-compiled for X.Y. What happens if I remove foo
package? Will byte-compiled files for X.Y be removed as well?
that's my understanding. byte-compiled files shouldn't exist for a python
runtime which is currently not installed on the system, and there shouldn't
exist byte-compiled files on the system without a corresponding source file (at
least in the public site directory).
byte compilation will not fail as it was already tested at build time,
What about cases when code is no longer supported in a given Python
release? I think of "except YourFavouriteException, e:" code with 3.1
(but feel free to use a better example), byte-compilation will fail.
the source code for python3 is almost always different compared to python2.x,
although the transformation can be done automatically by the new distribute
tools on installation time. Adding another copy of python (source) code into the
same package would enlarge the package, so it would be the best to have a
separate binary package python3-* (which could be built from the same source
package).
Matthias
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new dh_python proposal
On 15.01.2010 14:27, Jakub Wilk wrote: * Piotr Ożarowski , 2010-01-15, 11:58: * maintainer script will byte compile .pyc files for all provided symlinks / private directories if given Python version is installed (dpkg -L output will be used to detect which files need byte compilation, directories without __init__.py file will be skipped), IOW, you want to skip modules that are not a part of a package? Why? which files would that be? Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new dh_python proposal
On 15.01.2010 11:58, Piotr Ożarowski wrote: * no need for helper in Depends and Build-Depends - I want dh_python and pycompile/pyclean to be shipped in python packages, agreed. once these helper tools are mature for unstable/experimental, please add yourself as an uploader to python-defaults. I assume this is work which will land in squeeze. I'll see to change dh_pycentral to generate the installation scripts based on pycompile/pyclean such that no more runtime dependency on python-central is needed anymore. It would help in having to touch each source for the dh_pycentral/dh_python replacement. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ongoing Python Transition: related FTBFSes
On 28.01.2010 12:50, Cyril Brulebois wrote: Scott Kitterman (17/12/2009): I believe that we are getting close to uploading Python 2.6 to Unstable and dropping Python 2.4 as a supported Python version. If we finish preparations in the next week, are there any ongoing transitions a python2.6/python- defaults upload would entangle that would cause the release team to want the uploads to be delayed? Hi, I'm not sure it's the proper thread to mention this, but from a quick look, it sounds like related. FWIW, here are some FTBFSes I've reported lately, which look due to this transition: #567226: pysvn that's a wrong report, pycxx needs binNMUed, then the package does build. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#524176: AM_PATH_PYTHON should honor python's idea about the site directory
On 23.03.2010 21:21, Jonathan Wiltshire wrote: Hi, Do you have any indication of when this bug will be closed? It's currently holding up the (proper) fixes for several bugs key to the Python 2.6 transition, that we want to get over and done as soon as possible. We can make ugly patches, but fixing this bug would reduce the work needed to merely binNMUing the affected packages, if I have understood it correctly. it is fixed upstream in automake 1.11 (and in Debian), so you could use this version; I doubt that it will allow more binNMUs, as autoconf isn't called during the build for many packages. Matthias -- 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/4ba94202.7020...@debian.org
Python3 experimental packages with destination squeeze
In experimental you'll find a set of packages for Python3 python3.1 3.1.2+20100909-1 python3.2 3.2~a2-4 python3-defaults 3.1.2-10 python-defaults 2.6.6-2 distribute 0.6.14-3 The python3.2 package has the PEP's 3147 (PYC Repository Directories) [1] and 3149 (ABI version tagged .so files) [2] implemented, which allows installation of .so and .py[co] files for different python versions in one directory. The above packages do use a common directory as the site directory for "public" packages (/usr/lib/python3/dist-packages). distutils and distribute/setuptools are patched to install into this site directory by default when using the --install-layout=deb option. dh_python3 knows how to handle these locations. When building packages, a build dependency on a minimum version 3.1.2-10~ for one of the python3-* packages is needed. The part of PEP 3149 for looking up .so files with the ABI version is backported to python3.1. Currently there are only a few packages in the archive depending on python3, some of which already use the new location, I'd like to see the rest of the packages converted too, so that these few packages can ship with squeeze. * beaker 1.5.4-3 * mako0.3.4-4 * sqlalchemy 0.6.4-2 * markupsafe 0.11-2 * jinja2 2.5.2-3 * distribute 0.6.14-2 * pycxx 6.2.0-3 * gearman-interface * lxml2.2.8-1 * python3-httplib2 * python-slimmer * pyyaml * python-bsddb3 4.8.3-2 * python-apt (python3-apt binary package is missing) Packages mentioned here with version numbers are already updated, in experimental, in NEW, or being uploaded (Scott will care about pyaml, Piotr will care about the remaining ones, I'll contact the python-apt maintainers about the python-apt split). A small howto for packaging with python3 can be found here [3]. There is a freeze exception/pre-approval granted by the release team [4] for new "popular" binary python3-* packages as long as these are built from the same source and don't introduce new upstream versions. Squeeze is the first Debian release with a supported python3 and so it is important for long term consistency and reliability to get the ABI stuff in this release for python3.1. If we can get it here, we can assume all Debian releases support it. python3.2 3.2~a2 is not proposed for squeeze and only available in experimental to demonstrate the coexistence of different python3 versions. Scott Kitterman Piotr Ożarowski Barry Warsaw Matthias Klose [1] http://python.org/dev/peps/pep-3147/ [2] http://python.org/dev/peps/pep-3149/ [3] http://lists.debian.org/debian-python/2010/09/msg00020.html [4] http://lists.debian.org/debian-release/2010/09/msg00747.html -- 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/4c900ade.2080...@debian.org
python transition incomplete
There still around 50 packages depending, recommending or suggesting python2.5, without explicitly build-depending on python2.5 or python2.5-dev. A large chunk of these seem to be release critical, especially those which depend on python python2.6 (libpython2.6) and python2.5. Another chunk of packages apparently has wrong shebang lines explicitly using python2.5, which might night be release critical in many cases, but nevertheless should be fixed. Please don't just binNMU, this was apparently already done in the past without watching the build results. The list attached includes packages from experimental too. I'll file bug reports next week. The easier solution would be to remove python2.5 from the list of supported python versions and rebuild. (Sending email to the maintainers mentioned below) Matthias grass 6.4.0~rc6+42329-2 kaa-imlib2 0.2.3+svn4046-1 libopensync-plugin-python 0.36-2 pyscard 1.6.12-1 pyside 0.4.0-2 shiboken 0.4.0-1~exp1 bitbake 1.8.18-2 bobo 0.2.2-2 cheetah 2.4.2.1-1 foolscap 0.5.0+dfsg-1 gnome-python-extras 2.25.3-5 gnuradio 3.2.2.dfsg-1 gozerbot 0.9.1.3-4 gstreamer0.10-rtsp 0.10.5-2 ldns 1.6.6-1 libavg 1.0.1-1 libbuffy-bindings 0.11+nmu1 libcap-ng 0.6.4-1 libmimic 1.0.4-2 libopensync-plugin-python 0.22-2 nwsclient 1.6.4-3 obmenu 1.0-1 opensync 0.39-4 player 3.0.1+dfsg-1.1 plplot 5.9.5-4 pykcs11 1.2.2-1 pyliblo 0.8.1-2 pypoker-eval 138.0-1 pyscard 1.6.10-2 pytagsfs 0.9.2-2 python-iplib 1.1-2 qtiplot 0.9.8-1 radare 1:1.5.2-3 salome 5.1.3-9 samba4 4.0.0~alpha8+git20090912-1 scim-python 0.1.13~rc1-3 serna-free 0.svn270-3 simpleparse 2.1.0a1-5 subvertpy 0.7.3-1 syslog-summary 1.14-1 twisted-calendarserver 8.2.0.svn27622-2 xchat 2.8.8-1 xdelta3 0y.dfsg-1 zc.buildout 1.4.3-1 zconfig 2.7.1-4 zdaemon 2.0.4-3 zodb 1:3.9.4-1 zope.testing 3.8.3-4 autodocktools 1.5.4.cvs.20100912-1 mgltools-vision 1.5.4.cvs.20100912-1 Davide Puricelli (evo) xchat Loic Dachary (OuoU) pypoker-eval Adam C. Powell salome (U) Rahul Amaram twisted-calendarserver Sebastien Bacher gnome-python-extras Michael Banck libopensync-plugin-python (U) opensync Luciano Bello libmimic Vincent Bernat simpleparse (U) Joachim Breitner serna-free Pierre Chifflier libcap-ng Jeremie Corbier kaa-imlib2 (U) Sargis Dallakyan autodocktools (U) mgltools-vision (U) LI Daobing scim-python (U) Debian Games Team libtuxcap Debian GIS Project grass Debian GNOME Maintainers gnome-python-extras (U) Debian Med Packaging Team autodocktools mgltools-vision Debian Multimedia Maintainers pyliblo Debian Python Modules Team cheetah (U) foolscap pykcs11 (U) pyscard (U) pyside shiboken simpleparse Debian Qt/KDE Maintainers kdebindings Debian Science Maintainers salome Debian Science Team qtiplot Debian/Ubuntu Zope Team bobo zc.buildout zconfig zdaemon zodb zope.testing Sebastian Dröge gstreamer0.10-rtsp (U) Dirk Eddelbuettel nwsclient Free Ekanayaka pyliblo (U) Arnaud Fontaine cheetah Freevo Debian Dream Team kaa-imlib2 Bdale Garbee gnuradio Gudjon I. Gudjonsson qtiplot (U) Steinar H. Gunderson samba4 (U) Christoph Haas python-iplib IME Packaging Team scim-python IV salome (U) Matthias Jahn libopensync-plugin-python Michael Janssen player Matthias Klose zope.testing (U) martin f krafft libbuffy-bindings (U) Noèl Köthe samba4 (U) Steve Langasek samba4 (U) Georg W. Leonhardt kaa-imlib2 (U) Francesco Paolo Lovergine grass (U) Jan Lübbe bitbake Maintainers of GStreamer packages gstreamer0.10-rtsp (U) Jeremy Malcolm gozerbot Torsten Marek kdebindings (U) Bart Martens xchat (U) A Mennucc1 xdelta3 Michael Meskes kdebindings (U) Jaromír Mikeš pyliblo (U) Steffen Moeller autodocktools (U) mgltools-vision (U) Emilio Pozuelo Monfort gnome-python-extras (U) Josselin Mouette gnome-python-extras (U) David Palacio kdebindings (U) David Paleino syslog-summary Stephan Peijnik foolscap (U) Christian Perrier samba4 (U) Python Applications Packaging Team pytagsfs (U) Didier Raboud pyside (U) shiboken (U) Sebastian Reichel gstreamer0.10-rtsp radare Andrew Ross plplot Ludovic Rousseau pykcs11 pyscard Miriam Ruiz libtuxcap (U) Samba Debian Maintainers samba4 Ritesh Raj Sarraf pytagsfs David Smith pykcs11 (U) Ondřej Surý ldns Brian Sutherland bobo (U) zc.buildout (U) zconfig (U) zdaemon (U) zodb (U) zope.testing (U) Andreas Tille mgltools-vision (U) qtiplot (U) Fabio Tranchitella bobo (U) zc.buildout (U) zconfig (U) zdaemon (U) zodb (U) zope.testing (U) Alessio Treglia pyliblo (U) Davide Truffa obmenu Modestas Vainius kdebindings (U) Jelmer Vernooij samba4 (U) subvertpy Sune Vuorela kdeb
Re: Wheezy plans
On 23.10.2010 13:26, Julian Andres Klode wrote: On Fr, 2010-10-22 at 14:18 -0400, Barry Warsaw wrote: On Oct 22, 2010, at 07:52 PM, Julian Andres Klode wrote: Tell that the Arch people: http://www.archlinux.org/news/python-is-now-python-3/ Yep, they switched /usr/bin/python to Python 3.X I heard that Gentoo has done it too, but I have not verified that. Gentoo uses Python 2 by default as far as I can tell. Wasn't the upstream plan to use /usr/bin/python3 as the executable name in order to not break (almost) every Python script out there? If I understand it[1] correctly, the conclusion at PyCon 2009 was: /usr/bin/python => Python 2.X /usr/bin/python3 => Python 3.X (and maybe later) And that's what Debian, Ubuntu, openSUSE and Fedora do; and thus likely what SLED and RHEL will do. [1] http://www.tummy.com/journals/entries/jafo_20090405_125203 Yes, this is still the upstream plan, and there was no use case for a python2 executable. Matthias -- 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/4cc5b419.2010...@debian.org
Re: Packaging pypy
On 11/28/2011 09:25 PM, Stefano Rivera wrote: > Of course, it would have to be packaged as a separate Python stack, > again. Although it would be interesting to allow modules to be built for > alternate Python implementations, but that's not a trivial project... maybe for binary packages, but there is no reason why a pypy extension couldn't be built from the same source packages. Could you summarize why it needs to be a separate stack? -- 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/4ed4ce3e.1070...@debian.org
Re: Packaging pypy
On 11/29/2011 09:56 AM, Maciej Fijalkowski wrote: > For what is worth, the .py files (but not the .pyc files) can be > shared among pypy and cpython. IMO, patching pypy to lookup e.g. .pycp files before .pyc files would be appropriate for Debian (already doing something like this for .so files in 2.x). Not sure if backporting pep 3147 would be worth it. > However some packages have different > installation process for pypy and not pypy build (for example building > optional C extensions or not). that should be handled in the packaging. Matthias -- 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/4ed4dbf6.2070...@debian.org
Re: Future of python2.6 in Debian
On 01/04/2012 01:58 PM, Luca Falavigna wrote: > Hi, > > I was pointed at ordereddict package in the NEW queue, which is a > backport of OrderedDict object, also available in stock python2.7. please reject it for now. > After switching python-defaults to python2.7, I'm not sure we > discussed whether to keep python2.6 for Wheezy or not. > In theory, we should be able to get rid of python2.6 in time for the > release (I'd likely be able to act as a driver for the task, as I did > for python2.4 and python2.5 tear-down). 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. Matthias -- 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/4f04536a.6020...@debian.org
Re: Numpy & dh_python2
On 16.03.2012 02:15, Thomas Kluyver wrote: After some trial and error, I've got it building python3-numpy (leaving python-support in place for Python 2) - a patch is attached. I've checked that I can install and import the built package. Changes and suggestions are welcome, and I expect there are better ways to do bits of it. I'm away for the weekend, so it'll be a few days before I can work on it again. For now, I've ignored the dh_numpy and ABI/API versions, but I guess we'll want to make Py3 versions of them. thanks for the patch. I'll upload it next week, re-adding myself as an uploader, apparently silently removed. Matthias -- 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/4f6333db.6080...@debian.org
Re: Numpy & dh_python2
On 16.03.2012 14:29, Jakub Wilk wrote: * Matthias Klose , 2012-03-16, 13:36: re-adding myself as an uploader, apparently silently removed. Well, from my IRC log (2011-08-27): 22:43 < jwilk> morph_: Out of interest, did you ask the former Numpy co-maintainers if they are ok with removing them from Uploaders? :> 22:43 < morph_> jwilk: of course 22:43 < jwilk> Did they reply? 22:43 < morph_> jwilk: no all of them, I gave 2 weeks of time to do that (Presumably "no all" is a typo for "none".) Also, you surely received this mail, which is quite explicit: http://lists.debian.org/debian-devel-changes/2011/09/msg01361.html how would I get this email, if I am removed from the uploaders? -- 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/4f642539.5070...@debian.org
PIL/python-imaging becomes a python package and gets Python3 support
zen forg John T. Nogatch wsjt (U) Jonathan Thomas openshot Jordi Mallach nml (U) Julien BLACHE eikazo Julien Danjou mbot Julien Lavergne screenlets Julien Valroff rapid-photo-downloader Kamal Mostafa wsjt (U) Kartik Mistry fontypython gwibber Kevin Coyner htmlgen photon Kilian Krause mumble-django (U) Koichi Akabe qr-tools Kouhei Maeda actdiag blockdiag nwdiag seqdiag Krzysztof Klimonda mcomix Kumar Appaiah pkpgcounter (U) Laszlo Boszormenyi (GCS) cinnamon (U) Lior Kaplan hocr (U) Loic Minier moovida-plugins-bad (U) pigment-python (U) Ludovic Rousseau plucker Luis Uribe python-uniconvertor (U) Maintainers of GStreamer packages moovida-plugins-bad pigment-python Mark Purcell hplip (U) martin f. krafft python-docutils (U) Martin Pitt calibre (U) Mathieu Malaterre pylibtiff (U) Matthew Johnson fretsonfire (U) Matthias Klose python-reportlab Matthijs Kooijman nml Mediawiki Maintenance Team mediawiki-extensions Michael Banck bkchem (U) Michael Fladischer sorl-thumbnail (U) Michael Hanke psychopy (U) pydicom (U) pyepl (U) Michael Hanke pysurfer (U) Michael Schutte python-docutils (U) Michael Ziegler mumble-django (U) Michal Čihař lazygal pyaimt pyicqt Miguel Landaeta xpra (U) Miriam Ruiz calibre fretsonfire (U) snowballz (U) NeuroDebian Team psychopy pydicom pyepl pysurfer Nicolas Bourdaud cinnamon Olivier Aubert advene (U) Olivier Sallou pycaptcha (U) Olivier Sallou mobyle (U) Ondrej Certik python-scipy (U) sympy (U) Patrick Ringl pyicqt (U) Paul van Tilburg moovida-plugins-bad (U) pigment-python (U) Peter Pentchev snowballz (U) Philipp Huebner photofilmstrip (U) Picca Frédéric-Emmanuel asymptote (U) guiqwt (U) Piotr Ożarowski griffith phatch (U) Python Applications Packaging Team didjvu (U) ibid lazygal (U) ocrfeeder phatch pkpgcounter pyaimt (U) pyicqt (U) screenlets (U) trac-diavisview trac-wikiprint xpra Romain Beauxis mediawiki-extensions (U) Romain Bignon weboob Ruben Molina asymptote (U) Sam Morris pymsnt Sandro Tosi basemap (U) Scott Kitterman stepic Sebastien Delafond mitmproxy Shachar Shemesh hocr (U) Stani M phatch (U) Stefan Alfredsson cfv Stefan van der Walt skimage Stefano Rivera ibid (U) python-aalib (U) Steve M. Robbins svgtoipe (U) Stuart Prescott pyx TANIGUCHI Takaki simple-image-reducer streamtuner2 (U) Team XBMC xbmc Thorsten Glaser mediawiki-extensions (U) Tiago Bortoletto Vaz python-pyo (U) Till Kamppeter hplip (U) Tzafrir Cohen hocr (U) Ulises Vitulli nikola (U) Varun Hiremath python-enable (U) python-scipy (U) Vincent Bernat soya soya-doc Vincent Cheng exaile W. Martin Borgert ocrfeeder (U) pisa (U) trac-diavisview (U) trac-wikiprint (U) Yaroslav Halchenko impressive psychopy (U) pydicom (U) pyepl (U) pysurfer (U) skimage (U) Zlatan Todoric paprass أحمد المحمودي (Ahmed El-Mahmoudy) xpra (U) -- 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/5117d0b7@debian.org
Re: PIL/python-imaging becomes a python package and gets Python3 support
Am 11.02.2013 17:16, schrieb Barry Warsaw:
> On Feb 11, 2013, at 05:05 PM, Piotr Ożarowski wrote:
>
>> how about replacing python-imaging with python-pil in all packages that
>> do not need compat code (anymore) - this way all packages that are still
>> "broken" will have python-imaging as a dependency
>
> +1
>
> One minor question, should it be python{,3}-pillow?
probably, because the egg is called pillow. However introducing the pillow name
for the fork, which may be not permanent, doesn't sound like a good idea (the
current packages do provide the pillow names). I'll stick to the original names
for now.
Matthias
--
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/51195f44.1080...@debian.org
Re: How does team maintenace of python module works?
Am 14.02.2013 21:54, schrieb Thomas Kluyver: > On 14 February 2013 20:29, Barry Warsaw wrote: > >> I look at the switch to dh_python2 as an example. > > > I don't think it's a particularly good example, though. Lots of packages > continue to use the older helpers, and not due to a lack of time - attempts > to move away from the deprecated helpers still seem to meet considerable > resistance. this is your interpretation. pycentral is deprecated for a long time [1]. There are reasons to limit ourself to exactly one third-party directory [2], so maybe that should be the broader goal for jessie. > That causes problems when newcomers don't want to learn > deprecated packaging methods, and aren't allowed to update packages to use > the recommended helper. Agreed, so why not helping with it? Again, why not helping here? > Back on the VCS question, I fear that the 'all or nothing' road will circle > back to 'nothing' for a long time. I think that we should allow some > packages to live in git without forcing a complete migration, so individual > maintainers can use the VCS they're more comfortable with. Most open source > programmers have at least a basic familiarity with both, so it shouldn't be > such an obstacle to working on other packages. > > We wouldn't be the only team doing this - Debian Games Team, for example, > use both git and svn for packaging: > http://wiki.debian.org/Games/VCS Now you did point out one discrepancy, which hinders newcomers, and you do want to introduce another one? Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pycentral-deprecation;users=debian-python@lists.debian.org [2] https://lists.debian.org/debian-devel/2013/02/msg00109.html -- 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/511d6b25.10...@debian.org
Re: How does team maintenace of python module works?
Am 20.02.2013 00:53, schrieb Piotr Ożarowski: > [Barry Warsaw, 2013-02-19] >> So I still think it comes down to, them that does the work gets to >> decide, but there *is* work to do. It's clear we don't want multiple >> vcses. So I think you have an opportunity to convince us by: >> >> * Doing a test migration and putting a test repo up so we can play with >> it and see what it's like. >> >> * Figure out whether full-source or debian/ only works better (maybe give >> us both repos so we can play with them and discuss the pros and cons >> from actual working examples). >> >> * Put together draft policy and documentation to describe a workflow for >> team maintenance of packages under git, including branching, pull >> requests, code review, quilt integration, package building, etc. >> >> * Work out how upstreams that are under other vcses would work. >> >> * Provide a plan for a smooth flag day transition if/when consensus is >> reached. >> >> * Gather feedback, fix problems, rinse and repeat. >> >> Once people are comfortable with how a git-based team repository would >> work, I suspect you'll find more consensus to switch. > > +1 can we limit the packages in this ppa to those using dh_python[23] and those supporting python3? Matthias -- 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/512416b2.5030...@debian.org
Re: How does team maintenace of python module works?
Am 20.02.2013 09:31, schrieb Thomas Goirand: > On 02/20/2013 12:38 PM, Scott Kitterman wrote: >> On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote: >>> The idea to use "git archive" was mostly from Julien Danjou. It's >>> very nice because that way, we can use xz compression, instead >>> of what upstream provides (that is, github .zip or .tar.gz, which >>> isn't the best). >> See devref 6.7.8. This not an appropriate reason to not use the upstream >> tarball. >> >> Scott K > Thanks Scott, but I believe I know what I'm doing. No, I don't think so. > This wasn't the > only reason I stated, it's only one of the consequences. > > What upstream considers "release tarballs" are *not* what Github > provides anyway (it is a little bit more complex than this). So there would be no way anymore to build using upstream tarballs? This doesn't sound appropriate to force on a whole team. I don't think that many of the people that voted are aware of your implicit changes (no release tarballs, including upstream source in the VCS) by moving to git. Matthias -- 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/51248fdf.4010...@debian.org
Re: python3 and /usr/share
Am 20.02.2013 15:38, schrieb Olе Streicher: > Hi, > > I am trying to create packages for Python3 for the source package > [1]. Following the guide [2], I get some success. However, the packages > for Python2 and Python3 differ significantly: in the Python2 package, > all machine independent data go into /usr/share/, while the Python3 > package contains everything under /usr/lib/python3. Having /usr/share/pyshared in Python2 is an implementation detail. This is never used on sys.path directly. > Is this intentional, or shall I change something in the rules to get a > proper layout? I've investigated some other python3 packages, they all > put everything in /usr/lib/python3/. This is correct. > However, this seems to contradict the FHS? What is the way to go here? No, the FHS doesn't make any statement about code in /usr/share. Matthias -- 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/5124e393.8010...@debian.org
Re: Python plans for Jessie?
Am 06.05.2013 19:45, schrieb Tshepang Lekhonkhobe: > On Mon, May 6, 2013 at 5:34 PM, Barry Warsaw wrote: >> * Python 3.4 beta 1 is currently scheduled for November 23, 2013. What >> should >> our plans be related to 3.4? My current thinking is that we could support >> 3.4 but not make it the default. > > Why not make 3.4 default and get rid of 3.3 as well? It will be > released before Mar 2014[1], which should be months before Jessie > freeze. this is something to decide once 3.4 is feature complete, a test rebuild was done, and fixes for build failures are uploaded to the archive. So do you volunteer doing that? Matthias -- 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/5187ef78.4020...@debian.org
Re: On robustness of maintainer scripts
Am 13.05.2013 19:21, schrieb Steve Langasek:
> On Sat, May 11, 2013 at 12:29:07AM +0200, Piotr Ożarowski wrote:
>> [Jakub Wilk, 2013-05-10]
>>> postinst
>> [...]
>>> Proposed solution: 1) Wait until #671711 is fixed. 3) Make pycompile a
>>> shell script that does only two simple things: - write options it was
>>> called with to a file, say, /var/lib/python/pyX.Ycompile.todo; - use
>>> dpkg-trigger to trigger pythonX.Y.
>
>> why not generate maintainer scripts without pycompile at all? I wanted to
>> delegate as much as possible to interpreter packages, but your idea with
>> temp. files is even better - maintainer scripts can look like this:
>
>> | touch /usr/lib/pythonX.Y/dist-packages/namespace/__init__.py¹ | touch
>> /usr/lib/pythonX.Z/dist-packages/namespace/__init__.py¹
namespace packages aren't an issue anymore in python3, and for python2 it
would be better to ship these files into separate binary packages. these
aren't that many, and it would be much better for the robustness. nothing to
do anymore about these in maintainer scripts.
>> | dpkg -L | grep \.py$ | while read file | do |echo "${file}"
>> >> /var/lib/python/pyX.Ycompile.todo | echo "${file}" >>
>> /var/lib/python/pyX.Zcompile.todo | done
>
> The disadvantage is that the more logic is included directly in the
> maintainer scripts, the harder it is to fix any bugs with that logic
> because every package that includes the buggy behavior needs to be fixed.
> Even if that's only a simple rebuild with an updated version of dh_python2,
> it's quite costly to do that over all the affected packages in the
> archive.
>
> So from a robustness standpoint, it would be preferable if this logic
> could be encapsulated, if not in pycompile (for the reasons described),
> then at least in a trigger.
If it needs to be encapsulated, then it should be in the pythonx.y
packages shipping the interpreters, even if it does mean to duplicate these
scripts up to two times.
My hope was that most of the code for pycompile would end up in py_compile.py,
and the pycompile script would rely on that. But that didn't happen.
Depending on the complexity of the resulting pycompile, it could be inlined in
maintainer scripts, but it doesn't have to be.
> For my part, I'm having a hard time understanding why any of the proposed
> changes here are warranted. Yes, there are corner cases where the current
> maintainer scripts will fail, but the "real-world failures" included in
> Jakub's original mail seem to reduce to bug #680930 (which I think it was
> reasonable to fix by changing the interpreter package's linkage) and bug
> #671711 (which is an obviously unacceptable bug in dpkg that needs to be
> fixed). The other bugs, such as bug #706758, seem to map to these
> directly (i.e., it's fixable by applying the same change for bug #680930 to
> the python2.6 package in wheezy - currently this fix has only been applied
> for python2.7); and I don't think that any problem that requires a command
> like this in a minimal reproducer case:
>
> # dpkg --force-depends -r libssl0.9.8
>
> ... should seriously be considered a high priority, and be allowed to
> dictate the design of the interpreter handling.
>
> Relying on packages to be usable when unpacked-but-not-configured is
> fragile. But I am not convinced that the proposed cures are not worse
> than the disease.
>
> Certainly if we want to continue using pythonX.Y from maintainer scripts
> the way we do currently, great care would need to be taken to ensure
> they're usable when unpacked - which means a committment to either not add
> new library dependencies to the interpreter or ensure new library deps are
> listed in pre-depends instead of depends. Yet I think this should be
> entertained as an alternative to increasing the amount of code duplicated
> across hundreds of maintainer scripts.
python2.7-minimal shouldn't get any more dependencies on libraries. Now the
version in unstable depends on libc6, libgcc1, zlib1g. The libgcc1 dependency
comes from a linker bug when built with -flto and is dropped once linked with
ld 2.23.x. zlib is needed in the interpreter for the zip file support. From
what I can see, it would be hard to drop. libc6 is interesting in that the
update to 2.17 causes #708831, which I now worked around by making libc6 a
pre-dependency. I don't think this is specific for python2.7-minimal, and will
be exposed by other packages as well, as long as some essential packages like
coreutils and perl are rebuilt against the new libc6.
Afaicr, adding trigger support in some helpers did introduce its own set of
upgrade issues, but this might be safe, if no helpers use triggers to generate
and update symlink farms.
I don't share the opinion on the severity of #709198, and how it should be
fixed, if we are going this route of keeping the python interpreter working
during upgrades.
The dependency of python2.7-minimal on libpython2.7-minimal looks safe to me,
I don't t
Re: Remove python 2.7.3-13 (experimental)?
Am 11.06.2013 08:18, schrieb Arnaud Fontaine: > Hello, > > No reply so I guess it should be ok. Therefore, I will request the > removal of python from experimental. please wait until the upload in NEW reaches unstable, and then it will be removed automatically. -- 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/51b6ce18.5020...@debian.org
Re: setuptools 0.7
On 06/29/13 16:53, Thomas Kluyver wrote: > On 22 May 2013 16:28, Barry Warsaw wrote: > >> I think we should consider switching back to setuptools once 0.7 is >> released >> (defined as "available on PyPI), since this will clearly be the future of >> this >> component. We may have some fallout to deal with in other packages >> (e.g. virtualenv) that depend on this, and clearly setuptools/distribute >> is a >> central part of our stack. But it seems like now is a good time to shake >> that >> out for Jessie. >> > > PyPI now has the re-merged setuptools at version 0.7.4 - are we still > planning to package this as a new version of python-setuptools? yes, but not before python 3.3 as the defaults enters testing. one thing after the other. -- 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/51d0baaa.8050...@debian.org
Re: Inconsistency in source package naming for python modules
Am 10.07.2013 16:30, schrieb Stuart Prescott: > 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. > > Rules for packaging things are normally there to solve problems of > interoperability and to assist QA efforts. Which of these is it going to > help? > >> Never the less, I think we should collectively decide what to do, rather >> than continuing the mess, with everyone having its own rule. > > What mess? If there is a perceived mess, why is that a problem in any case? > How does it help to make a new rule? Who does it help? What problem does > this solve? Why is any intellectual energy being spent on this at all? energy? maybe. but intellectual? > It looks exceedingly like a rule for the sake of having a rule. It will be > an exceedingly complicated rule in that it will have to cover python > modules, python applications and other libraries that offer python bindings > all separately. It will have to be accompanied an explanation of why so many > packages don't follow it because they were uploaded prior to the rule > existing. Basically... unless we are going to force every existing source > package to change name to comply with this rule there is no point in having > it (and no-one has advocated renaming source packages as is useless work for > everyone). It is good to have a naming schema for binary packages, however it is easy to get from there to the name of the source package. I think I got some bug reports to include the upstream source name into the short package description when it doesn't match the module name, so that it can be found by apt-cache -n search. But again, no need for a policy here. Matthias -- 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/51dd84a6.8020...@debian.org
Re: PEP 453 affects Debian packaging of Python packages
Am 18.09.2013 09:48, schrieb Julien Cristau: > On Wed, Sep 18, 2013 at 09:38:57 +0200, Paul Wise wrote: > >> We don't do "private copies" or "bundled copies" in Debian, so I guess >> the right way to go for Debian is to have python depend on python-pip >> and python3 depend on python3-pip? >> > We don't do dependency loops without a good reason either (and no, this > isn't one). Make it Recommends if you like, though I'd question the > value of even that. the pep doesn't require that but only recommends it, but also points to the hint given by the command-not-found handler which package to install if the command cannot be found. Also the platform package manager should be the preferred way to install packages, not pip, so even a Recommends is a bit strange. Matthias -- 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/523981c9.8020...@debian.org
Re: PEP 453 affects Debian packaging of Python packages
Am 19.09.2013 00:36, schrieb Scott Kitterman: > > > Paul Tagliamonte wrote: >> On Wed, Sep 18, 2013 at 05:41:52PM +0200, Piotr Ożarowski wrote: >>> ok, I forgot to add ";)", but... >> >> Sure, but let's be more careful - I don't want people quoting "Debian >> Python" people telling people they're going to purge pip from the >> archive... >> >> It's all too often I hear people complain about Debian at PyCon, and >> I'm >> getting sick and tired of it. to be fair, they complain about any system shipped python. > Hostile proposals like this don't exactly help build peace, love, and > understanding. so calling the proposal hostile builds peace, love, and understanding? >>> Don't get me wrong, I think pip has some valid use cases (f.e. inside >>> virtalenv), I even recommend it sometimes, but forcing us to use it >>> instead of our (much better) tools / breaking things we carefully >>> prepared for our users is just not acceptable. >> >> I don't disagree, but this isn't a reason to hate on pip. This is a >> reason to tell the people who wrote this proposal we'd likely not >> comply, but leave it as an installable component for development work. sure, and telling it in this way doesn't raise anyone's blood pressure. > If I understood the proposal correctly, security is to be bolted on later. > Given the global threat environment, I am against introducing a new code > installation mechanism that is not cryptographically verified. It might enter > the archive once that's fixed, but I think not before. so security stays at the same level as before. If you think you have to add something to the pep, then do it and work together with the pep maintainers. Be prepared to spend some time, to work with and understand the windows and macosx ports and the different installers / python distributions. Do you want to do this? Write a pep about integration with system packaging, and submit it, and implement it. Looking at something similar in the Java world you'll find this difficult to get a broad consensus, see the more than once delayed jsr277. The only thing I can see in this thread is that a lot of pressure/opposition is built up on the Debian side, and I currently cannot see why exactly. pip installs (when using the system python) should go to /usr/local, if not then pip should be patched. Maybe give a warning, or require an extra option to run as --yes-run-as-root, or maybe give a hint installing the deb package. Matthias -- 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/523a32fa.7000...@debian.org
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
Am 22.01.2014 08:28, schrieb Thomas Goirand: > On 01/22/2014 12:24 PM, Barry Warsaw wrote: >> Do you really think that it's unfeasible for git proponents on this team to >> find the necessary resources to plan an orderly en mass transition? It might >> indeed be so, we're all busy. But let's hopefully all agree that the end >> goal >> is to have all team-maintained packages in the same vcs. > > I can't answer this question, as I can't speak for the others, and I > don't have time myself. sure, so you are proposing something which you don't want to finish, just pursuing a rather selfish interest of using git yourself. You did try this with the debian-java team as well. > Well, if we decide to move slowly things to Git, then the packages that > will stay in the SVN repo will be those largely unmaintained... and these will be magically maintained when converted to Git? please don't be silly. unmaintained packages are not a property of the used VCS. And you said you don't have time to spend on these yourself. > http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org > > The only reason they are maintained within the OpenStack team is because > I don't want to be forced to use SVN, and I think it's safer than in > collab-maint where so many people have commit access (which means they > can rm -rf...). apparently these were first needed for openstack. so it seems to make sense to maintain these over there. Matthias -- 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/52dfadf0.9080...@debian.org
preparing for Python 3.4
Python 3.4 beta2 is in testing, the python3-setuptools package is able to handle 3.4 builds. I am planning to go on with 3.4 as a supported Python 3 version some time in February (targeting not later than Feb 9, release date of the first 3.4 release candidate). This should be doable without too many issues. The ones I found are now user tagged in the Debian bug tracker. http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-python@lists.debian.org;tag=python3.4 There are a few issues triggered by the new version, but most issues seem to be packaging issues to handle more than one supported python version. Plus dh-python should be updated before 3.4 becomes a supported version. The 3.4 release is planned for March 16, so it shouldn't be too much of a surprise to make 3.4 the default for the next Debian release, and hopefully be able to drop 3.3. Matthias -- 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/52e55af5.1040...@debian.org
Re: Making packaging Python modules fun again
Am 27.01.2014 00:14, schrieb Nicolas Dandrimont: > - Adding Python 3 support when upstream has it I think this should make it into the python policy. Matthias -- 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/52e67a05.8010...@debian.org
Re: preparing for Python 3.4
Am 26.01.2014 19:59, schrieb Matthias Klose: > Python 3.4 beta2 is in testing, the python3-setuptools package is able to > handle > 3.4 builds. I am planning to go on with 3.4 as a supported Python 3 version > some time in February (targeting not later than Feb 9, release date of the > first > 3.4 release candidate). This should be doable without too many issues. The > ones I found are now user tagged in the Debian bug tracker. > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-python@lists.debian.org;tag=python3.4 > > There are a few issues triggered by the new version, but most issues seem to > be > packaging issues to handle more than one supported python version. > > Plus dh-python should be updated before 3.4 becomes a supported version. the first 3.4 release candidate is now in testing, and jchristau is scheduling binNMU for python 3.4 as a supported python version [1]. experimental has python3-defaults packages pointing to 3.4 as the default. I added issues to [2] showing some packaging issues. The most common thing is a generated dependency on python3.x, because a package contains a file/binary with a python3.x shebang. In most cases this should be replaced with a python3 shebang, which can be done with dh_python3 --shebang=/usr/bin/python3. But why not automate this? dh_python3 looks at the b-d's, and if it doesn't find a b-d on python3-all-dev or libpython-all-dev, then it should be safely replaced. Even for packages with a b-d on python-all-dev, in most cases a python3 shebang should be the correct default. Same thing for python2.7, maybe not that important, because nobody cares and we have only one version available. So change dh_python? Or at least add some lintian warning for a dependency on a specific python version? As a side note, I'm currently preparing Ubuntu 14.04 for python 3.4 as the default (with a lot of help from others). You can see the current status at [3]. Matthias [1] https://release.debian.org/transitions/html/python3.4.html [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.4;users=debian-python@lists.debian.org [3] http://people.canonical.com/~ubuntu-archive/transitions/html/python3.4.html -- 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/53068e18.3020...@debian.org
Re: Python 3.4 and ensurepip (rehashed, long)
Am 21.03.2014 13:23, schrieb Piotr Ożarowski:
[Barry Warsaw, 2014-03-19]
TL;DR: Let's re-enable the ensurepip module in Python 3.4, and possibly
address some usability issues. We should descend en masse on Montreal and
stage a revolt at Pycon. :)
IMO our ensurepip.py should look similar to this:
| try:
| from pip import *
| except ImportError:
| raise Exception('Please ask administrator to install python3-pip package.'
| ' Note that installing packages system-wide using pip is'
| ' considered harmful, please do not report Python related'
| ' bugs in Debian bugtracker if you decide to do that.')
IMO we should warn users that they can^W will break their systems and
`sudo pip install ...` should raise an exception if
--i-will-not-blame-debian option is not enabled.
the option name is not longer than --single-version-externally-managed, that
seems to be wrong.
FTR:
After a while (10th time I was asked to clean after pip?) the very first
thing I look for in tracebacks someone sends me is... ".egg" or
"/usr/local" paths, seriously! It simply started annoying me and I hate
every single upstream that recommends using sudo irresponsibly.
There are two issues here:
- there are cases where you want to install extra packages to be
used by the system python3. These should never be installed into
/usr/lib/python3/dist-packages,
but into /usr/local/lib/python3.x/dist-packages.
python3-pip should be patched to do that, and we should work with
upstream to do that as well and not to mess up the system python.
It might be good to have a mode for pip that tells you that a
requirement can be fulfilled by a system package.
Same thing for python2.7 and python-pip.
- whether to use python3-pip or a freshly downloaded pip. When using
pip to install for the system python3, maybe try to use the shipped
python3-pip. I have no opinion if another pip is downloaded and
installed into for environments created by venv or virtualenv. Some
package builds use virtual environments, but the population of these
has to be satisfied by package build dependencies anyway.
Matthias
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/532c3e68.50...@debian.org
Re: Getting rid of python-support?
Am 30.04.2014 17:31, schrieb Luca Falavigna:
> Hi,
>
> python-central is gone (\o/) and python-support usage is slowly
> decreasing in the archive:
> http://lintian.debian.org/tags/dh_pysupport-is-obsolete.html
>
> Do you think it would be the right time to prepare a mass bug filing
> asking to convert to dh_python{2,3}?
that would be good. However before we start this, I'd like to make sure that we
get rid of /usr/share/pyshared as well. With PEP 404 [1] reconfirmed this year
at PyCon we can safely remove the symlink farm.
Matthias
http://legacy.python.org/dev/peps/pep-0404/
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53612c4e.5050...@debian.org
Re: Bug #732703 and fixing ensurepip/pyvenv
Am 07.05.2014 10:16, schrieb Piotr Ożarowski:
> [Barry Warsaw, 2014-05-07]
>> Generating the wheels during package build is pretty easy I think. You just
>> B-D on python*-wheel (which just got approved from NEW) and then if the
>> package uses setuptools, you just add something like:
>>
>> python3 setup.py bdist_wheel -d \
>> debian/python-foo-wheels/usr/share/python-wheels
>> dh_installdirs -ppython-foo-wheels usr/share
>>
>> after you've added the python-foo-wheels binary package. (Exact package
>> names, directory paths, etc. TBD, but these are what I've picked for my
>> experiments.)
>
> this will double the size of python{,3}-* packages in our archive and
> force us to update thousands of source packages.
>
> What do wheels have that our binary packages do not have? Aren't they
> just a zipped .py files? I'm probably missing something, but why can't
> we zip `dpkg -L python-foo | grep /dist-packages`'s output at runtime
> (when someone python3 -m ensirepips something)?
as long as wheels are limited to zip files and can't reference files on the file
system, these should not be included into the distro. compared to eggs this is
a regression.
pip is a specical case here, because we want to mimic the wheel packages which
come with python upstream. these can't be shipped in the debian python source
package, but they are needed to make the pyvenv command work. so we have to
construct these out of the debian supplied packages, and best in a form that
these cannot be broken by updates in the venv, i.e. re-vendorized.
Matthias
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536a0912.4020...@debian.org
Re: ${python:Depends} to enable dh_python2, ${python3:Depends} - dh_python3?
Am 07.05.2014 12:17, schrieb Piotr Ożarowski:
> dh_python2 ignores python3-* packages, dh_python3 ignores python-*
> packages, but in all other packages both of them will try to handle .py
> files. To avoid possible unnecessary dependencies or shebang rewrites,
> debhelper's -N (--no-package) or -p (--package) options should be used.
>
> Should I change dh_python* behaviour to ignore all binary packages that
> do not have appropriate ${python:Depends} template in Depends?
how many packages will fail to build, or will produce non working packages with
this change?
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536a0973.1020...@debian.org
favouring Python3 in the Debian policy
Attached is a proposed change to the Debian Python policy to focus on Python3 within the distribution. The intent is to document and start a large journey towards one Python stack in Debian. This is unlikely to happen for jessie+1, but we should state the plan now so that it doesn't come later as a surprise. Matthias === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml 2013-05-22 02:12:02 + +++ debian/python-policy.sgml 2014-05-07 14:34:24 + @@ -32,7 +32,7 @@ Scott Kitterman sc...@kitterman.com - version 0.9.4.2 + version 0.9.5 This document describes the packaging of Python within the @@ -42,8 +42,7 @@ - Copyright © 1999, 2001, 2003, 2006, 2009, 2010, 2011, 2012 - Software in the Public Interest + Copyright © 1999-2014 Software in the Public Interest This manual is free software; you can redistribute it and/or @@ -74,6 +73,57 @@ + + On the move to Python3 + + Debian currently supports two Python stacks, one for Python2 + and one for Python3. The long term goal for Debian is to + reduce this to one stack, dropping the Python2 stack at some + time. + http://legacy.python.org/dev/peps/pep-0404/"; + name="PEP 404"> states that no more major Python2 releases + are planned, although the last released major version 2.7 + will see some extended support, documented in + http://legacy.python.org/dev/peps/pep-0466/"; + name="PEP 466">. + + + Packages in Debian should use Python3 if Python3 is + supported. New packages should use Python3 from the initial + upload, new upstream versions for existing packages should + use Python3 if the new upstream version supports it. + + + + + + Applications should use Python3, and should not be + packaged for Python2 as well. + + + + + Python libraries should be always packaged for Python3 + if supported. Python2 libraries should be packaged, if + applications dound in the reverse dependencies are not + yet supported by Python3. + + + + + Existing Python2 libraries should not be dropped before + the last reverse dependency is removed. + + + + + + Python3 (3.1) was released in June 2009, and is available in + the Debian 6.0 (squeeze) release (3.1), and in the Debian 7 + (wheezy) release (3.2). + + + Python Packaging @@ -117,7 +167,10 @@ The set of currently supported python versions can be found in - /usr/share/python/debian_defaults. This file is in + /usr/share/python/debian_defaults, the set of + currently supported python3 versions can be found + in /usr/share/python3/debian_defaults. These + files are in Python ConfigParser format and defines four variables in its DEFAULT section: default-version which is the current default Python runtime, supported-versions which is the set of runtimes
Re: favouring Python3 in the Debian policy
Am 07.05.2014 17:27, schrieb Barry Warsaw: >> + >> + >> + >> + Applications should use Python3, and should not be >> + packaged for Python2 as well. >> + > > Maybe also that system scripts written in Python should be Python 3 and not > Python 2. I'd add the clarity just because I'm not sure folks think of such > system scripts as "applications". proposing a separate item. Command line scripts, packaging tools, tools used by Debian outside the archive, etc. should use Python3, and should not be packaged for Python2. >> + >> + >> + >> + Python libraries should be always packaged for Python3 >> + if supported. Python2 libraries should be packaged, if >> + applications dound in the reverse dependencies are not > > s/dound/found/ fixed. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536a9469.9090...@debian.org
Re: favouring Python3 in the Debian policy
Am 07.05.2014 23:01, schrieb Steve Langasek: > On Wed, May 07, 2014 at 10:15:37PM +0200, Matthias Klose wrote: >> Am 07.05.2014 17:27, schrieb Barry Warsaw: >>>> + ++ + Applications >>>> should use >>>> Python3, and should not be + packaged for Python2 as well. + >>>> > >>> Maybe also that system scripts written in Python should be Python 3 and >>> not Python 2. I'd add the clarity just because I'm not sure folks >>> think of such system scripts as "applications". > >> proposing a separate item. > >> Command line scripts, packaging tools, tools used by Debian outside >> the archive, etc. should use Python3, and should not be packaged for >> Python2. > > I don't think scripts "outside the archive" are in scope for the python > policy; thas was "tools outside the archive". Debian has some infrastructure written in Python. I don't know if all of this is packaged and available in the archive. > and I don't think this is what Barry was referring to. I think he meant > python commandline programs, which some people may not think of as being > "applications"? sure, is "commandline programs" clearer than "Command line scripts"? > FWIW, while I think getting the python policy to recommend Python3 is a > good step forward, I think it's more important that we make sure the base > system is leading by example. As described on debian-devel[1], there seem > to be some porting blockers before we can migrate from python to python3 in > the standard install. This is independent. Getting these issues fixed is a dead-end for any other migration of packages to Python3 (well, maybe except for OpenStack). There is no reason for package maintainers to convert to Python3 for other packages. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536aa8fc.7030...@debian.org
Re: favouring Python3 in the Debian policy
Am 07.05.2014 16:45, schrieb Matthias Klose: > Attached is a proposed change to the Debian Python policy to focus on Python3 > within the distribution. The intent is to document and start a large journey > towards one Python stack in Debian. This is unlikely to happen for jessie+1, > but > we should state the plan now so that it doesn't come later as a surprise. this is what I committed and uploaded in 2.7.6-1. Should cover all feedback from this thread. Matthias === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml 2013-05-22 02:12:02 + +++ debian/python-policy.sgml 2014-05-12 10:21:25 + @@ -32,7 +32,7 @@ Scott Kitterman sc...@kitterman.com - version 0.9.4.2 + version 0.9.5 This document describes the packaging of Python within the @@ -42,8 +42,7 @@ - Copyright © 1999, 2001, 2003, 2006, 2009, 2010, 2011, 2012 - Software in the Public Interest + Copyright © 1999—2014 Software in the Public Interest This manual is free software; you can redistribute it and/or @@ -74,6 +73,58 @@ + + On the move to Python 3 + + Debian currently supports two Python stacks, one for Python 2 + and one for Python 3. The long term goal for Debian is to + reduce this to one stack, dropping the Python 2 stack at some + time. + http://legacy.python.org/dev/peps/pep-0404/"; + name="PEP 404"> states that no more major Python 2 releases + are planned, although the last released major version 2.7 + will see some extended support, documented in + http://legacy.python.org/dev/peps/pep-0466/"; + name="PEP 466">. + + + Packages in Debian should use Python 3 if Python 3 is + supported. New packages should use Python 3 from the initial + upload, new upstream versions for existing packages should + use Python 3 if the new upstream version supports it. + + + + + + Programs should use Python 3, and should not be packaged + for Python 2 as well. Python 3 should be used for the + packaging if the packaging scripts use Python. + + + + + Python libraries should be always packaged for Python 3 + if supported. Python 2 libraries should be packaged, if + applications found in the reverse dependencies are not + yet supported by Python 3. + + + + + Existing Python 2 libraries should not be dropped before + the last reverse dependency is removed. + + + + + + Python 3 (3.1) was released in June 2009, and is available in + the Debian 6.0 (squeeze) release (3.1), and in the Debian 7 + (wheezy) release (3.2). + + + Python Packaging @@ -117,7 +168,10 @@ The set of currently supported python versions can be found in - /usr/share/python/debian_defaults. This file is in + /usr/share/python/debian_defaults, the set of + currently supported python3 versions can be found + in /usr/share/python3/debian_defaults. These + files are in Python ConfigParser format and defines four variables in its DEFAULT section: default-version which is the current default Python runtime, supported-versions which is the set of runtimes
proposing to track Python 3 issues
While there are many issues, and not all of these are even fixed upstream, I think it makes sense to track issues about Python 2 usage, and where it can be converted / replaced by Python 3. Even if an upstream doesn't plan to support Python 3 in the future, it makes sense to tag such an issue 'upstream wontfix', and maybe close it. Omitting stacks like django or openstack might be useful, otoh such issues can be used to track needed Python 3 updates packages in dependencies. Proposing to usertag issues with debian-python@lists.debian.org/python3 Does somebody already has an initial list of packages where to start from? Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/537231e0.50...@debian.org
removal of /usr/{lib,share}/pyshared
dh_python2 in unstable, dh-python (1.20140511-1) and python-defaults (2.7.6-1)
now don't create symlinks to /usr/{lib,share}/pyshared anymore, but install
directly to /usr/lib/python2.7/dist-packages. There are a lot of packages
affected, so maybe the complete removal cannot be done in time for the jessie
release. There are different kind of fixes needed:
- A package references pyshared in the packaging, and needs a
sourceful upload. I hope bug reports for all of these should
already be filed.
- A package not using pysupport and building architecture dependent
packages should be binNMU'd.
- A package not using pysupport and only building architecture
independent packages needs a sourceful no-change upload.
- A package using pysupport should be converted to a dh_python2/pybuild.
This was already proposed as a release goal, but I didn't see any
updates yet.
I would like to start pinging maintainers frist, then filing bug reports once
the final python3 version is in testing and a few of these issues are already
resolved in the archive.
Proposing to usertag issues with debian-python@lists.debian.org/pyshared-removal
Matthias
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53723418.2050...@debian.org
wheel support for Debian?
Issue #748299 asks about adding wheel support for setuptools. I know about the special case for pip and it's dependencies, however I would like to see to have wheel support addressed first before applying such a patch. - should we add wheels everywhere? I don't think we should, but I'd like to state this somewhere, like in the python policy. - where to put wheels? /usr/share/python-wheels is an ad-hoc decision which was never proposed. I'm aware about "universal" wheels but I'd like to clarify where wheels should be located. Do we need /usr/share/python/wheels, and/or /usr/share/python3/wheels? - naming of wheel packages. It's good to see wheels packaged in a separate binary package. However there is no proposal how to name these packages. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53753abd.4000...@debian.org
Re: wheel support for Debian?
Am 16.05.2014 10:48, schrieb Piotr Ożarowski: > If I provide a script that generates .whl file out of Debian binary > package, would that make more sense than these -wheels packages? > > python3.X-venv could simply depend on required packages and run this > script (with a list of required dependencies) when someone creates new > venv. You can also pre-generate them in python3.X-venv's postinst but > then a dpkg trigger is needed to regenerate them when one of > dependencies is upgraded. I think it is much more stable to pre-generate and ship these. some packages could break for some time when these packages are updated to new versions. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/537939dc.2010...@debian.org
Re: wheel support for Debian?
Am 16.05.2014 00:32, schrieb Barry Warsaw: > My thoughts... > > On May 16, 2014, at 12:07 AM, Matthias Klose wrote: > >> - should we add wheels everywhere? I don't think we should, >> but I'd like to state this somewhere, like in the python policy. > > Agreed, we should not add wheels everywhere. I would like to keep it very > limited to exactly the (small) set of packages we need to devendorize > ensurepip, recursively. If some other devendorizing task in the future > requires the use of wheels, then we have a framework in place, but I would > like to actively discourage their use. > > I do plan to propose an update to policy stating this, but I haven't gotten to > that yet. I will of course post the proposed update here first. > >> - where to put wheels? /usr/share/python-wheels is an ad-hoc >> decision which was never proposed. I'm aware about "universal" >> wheels but I'd like to clarify where wheels should be located. >> Do we need /usr/share/python/wheels, and/or /usr/share/python3/wheels? > > I proposed /usr/share/python-wheels here: > > https://lists.debian.org/debian-python/2014/05/msg00025.html > > but it's a detail that was probably easily lost in the wall of text. I didn't > see any objections to that specifically though. We could change it if > something clearly better is proposed, although it would necessitate some new > uploads and updated quilt patches. > > For the current use case, we only need pure-Python wheels, and in fact Python > can't currently import extension modules from zips, so architecture dependent > wheels wouldn't work anyway. Universal wheels (Python 2 and 3 compatible) are > used because that's what the ensurepip machinery already uses. it's just as > easy to create universal wheels, and all the packages we currently care about > *are* bilingual, so using them here reduces the upstream delta. Since I don't > view the building of wheel packages as general purpose, I think it's fine to > just put them in a shared directory. > > In other words, non-universal wheels YAGNI. I would like to avoid different wheel directories in /usr/share, so if the name of the wheel encodes the python version, then they probably can live in the same directory. The plural for the dir name goes along with the one for "-packages" for python packages. >> - naming of wheel packages. It's good to see wheels packaged >> in a separate binary package. However there is no proposal >> how to name these packages. > > That was also proposed in the above referenced message. Suggestions welcome, > but I think python-foo-wheels is as good as anything (it's pretty > self-descriptive ;). The GNUstep apps are packaged as .app, so why not use .wheel? then even python-wheel.wheel becomes clear ... and it's the singular. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53794365.10...@debian.org
Re: wheel support for Debian?
Am 19.05.2014 12:19, schrieb Piotr Ożarowski: > please at least unpack these wls files so that admins don't have to > figure out what to do with them if they want to apply a patch from > upstream no, you don't gain anything by this. we don't unpack jar files either. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5379e091.5060...@debian.org
Re: wheel support for Debian?
Am 19.05.2014 13:19, schrieb Jakub Wilk: > * Matthias Klose , 2014-05-19, 12:44: >> we don't unpack jar files either. > > Fortunately, we don't have to mimic all the Java misfeatures. fine, then please come back after changing the policy to ship unpacked .a files. Call it misfeature or not, but I didn't see you involved upstream defining the wheel format. So please either get involved upstream, or stop complaining about these formats, where these are needed in the distribution. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/537b6c55.50...@debian.org
Re: python3 celery
Am 14.07.2014 08:25, schrieb Jan Dittberner: > On Mon, Jul 14, 2014 at 02:09:36PM +1000, Brian May wrote: python-pika > depends on Twisted which is Python 2 only, upstream supports Python 2 only > too. The Pika documentation has a statement "Currently pika only supports > Python 2.6 and 2.7. Work to support 3.3+ is underway." Twisted has some support for Python3, see twisted/python/dist3.py in the twisted 14.0 sources. I packaged a twisted-py3 building a python3-twisted-experimental, which I didn't yet upload to Debian. For now you can get it from https://launchpad.net/ubuntu/+source/twisted-py3. If this is good enough for pika, I'll upload that to unstable as well. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c3cb30.6080...@debian.org
Re: Bug#755757: transition: wxpython3.0
Am 23.07.2014 03:38, schrieb Olly Betts: > Package: release.debian.org Severity: normal User: > release.debian@packages.debian.org Usertags: transition Control: block > -1 by 734799 > > This is a follow-on from the wxwidgets3.0 transition. The wxwidgets2.8 > source package actually contains the wxpython source, which has an embedded > copy of wxwidgets. This has become unworkable as the wxpython releases now > lag the corresponding wxwidgets releases by many months, so for 3.0 we're > splitting the source packages. > > The intention is to eliminate wxwidgets2.8 (and hence wxpython 2.8) before > releasing jessie - the last upstream release (2.8.12) was over 3 years ago, > and there's very little upstream interest in bugs in it now. are you saying that around 80 packages will be removed for jessie just because wxpython isn't yet ported to 3.0? > This should be a "smooth transition", as the packages for wxpython 2.8 and > 3.0 are co-installable. Maybe I misunderstand something but I wouldn't call this "smooth". Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53cfa62b.5030...@debian.org
Re: Bug#755757: transition: wxpython3.0
Am 23.07.2014 15:07, schrieb Olly Betts: > On Wed, Jul 23, 2014 at 02:10:19PM +0200, Matthias Klose wrote: >> Am 23.07.2014 03:38, schrieb Olly Betts: >>> The intention is to eliminate wxwidgets2.8 (and hence wxpython 2.8) before >>> releasing jessie - the last upstream release (2.8.12) was over 3 years ago, >>> and there's very little upstream interest in bugs in it now. >> >> are you saying that around 80 packages will be removed for jessie just >> because wxpython isn't yet ported to 3.0? > > I don't really understand the question - wxPython 3.0.0.0 was released > in late 2013, and packages for it are in the NEW queue. > > I'm not suggesting we remove around 80 packages, but that we move them > from using wxPython 2.8 to wxPython 3.0. As with any large transition, > it's possible that we'll find a few candidates for removal in the > process, but that's not the aim of the transition. > >>> This should be a "smooth transition", as the packages for wxpython 2.8 and >>> 3.0 are co-installable. >> >> Maybe I misunderstand something but I wouldn't call this "smooth". > > Are you perhaps mixing up wxPython 3.0 and Python 3.x? It is the case > that neither wxPython 2.8 nor wxPython 3.0 support Python 3.x, but > that's irrelevant to this transition. > > In this context, "smooth transition" just means that packages can be > switched one by one, rather than having to try to coordinate uploads > of ~80 different packages. no, I'm not mixing wxPython 3.0 and Python 3.x. Asking what will happen with packages depending on wxPython 2.8 and which cannot be converted to 3.0. the lack of Python3 support in wxpython 3.0 is disappointing, but such is life. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53cfb98f.60...@debian.org
Re: python-pandocfilters_1.2.1-1_amd64.changes ACCEPTED into unstable, unstable
Am 28.07.2014 um 14:00 schrieb Debian FTP Masters: > > > Accepted: > > Format: 1.8 > Date: Mon, 30 Jun 2014 10:04:06 +0200 > Source: python-pandocfilters > Binary: python-pandocfilters python3-pandocfilters > Architecture: source all > Version: 1.2.1-1 > Distribution: unstable > Urgency: low > Maintainer: Debian Python Team > Changed-By: Sebastian Humenda please can we avoid using debian-python@lists.debian.org as a maintainer list for packages? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d641b0.9080...@debian.org
Re: Django 1.7 preparations
Am 07.08.2014 um 23:48 schrieb Raphael Hertzog: > Hi, > > I rebuilt all reverse deps of python-django and I tagged confirmed all the > associated bugs where the package failed to build with python-django 1.7 > and I sent the relevant extract of the build log... a lot of django packages are still built with python-support. would it be possible to switch to dh_python too when moving to 1.7? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e49476.5060...@debian.org
python3- packages must not depend on python packages and vice versa
Seen this in pycurl (#757694), but if this is something which occurs more often, then I think we should prepare for a policy update and/or a lintian warning. Maybe it is not yet possible to avoid one stack entirely, but we should not create artificial dependencies. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e79ac7.2070...@debian.org
Re: Bug#758013: s3ql autopkg test regression
Control: severity -1 important > That's a bug in the test (race condition) rather than in the program. > It's fixed upstream. Nikolaus, I find this kind of attitude rather disturbing. If you don't care about the autopkg tests, and if you are not ready to fix these but rather wait for the fixes from upstream (and maybe new bugs), then I think it's better to drop the autopkg tests. And replying to the bug report without replying to the maintainer is at least odd. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f30be5.7080...@debian.org
Re: Bug#758013: s3ql autopkg test regression
Am 20.08.2014 um 06:52 schrieb Nikolaus Rath: > If someone cares deeply about this, the necessary patch is at > https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/. > > > I did not add it to the debian package yet because I considered it a > minor issue that I did not want to bug my sponsor with. But if some DD > wants to sponsor a new upload right away to get this fixed, I'm happy to > update the package in SVN. sure, I can do this. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f47510.7000...@debian.org
Re: Python applications: private dirs and PYTHONPATH issue
Am 11.09.2014 um 10:30 schrieb Piotr Ożarowski:
> [Andreas Tille, 2014-09-11]
>> pkg_resources.DistributionNotFound: pil>=1.1.7
>
> python{,3}-pil provides Pillow egg-info
> Matthias: should python-imaging provide pil.egg.info file (for older
> libraries/applications like dicompyler?
I don't mind for python-imaging, but we shouldn't add that for python3, not
having packages for that in older releases.
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5411618f.8070...@debian.org
Re: Status of pythondialog in Debian
Am 17.10.2014 um 17:03 schrieb Barry Warsaw: > Hi Florent, > > On Oct 17, 2014, at 04:17 PM, Florent Rougon wrote: > >> As the upstream maintainer of pythondialog, I feel a bit concerned about >> its status in Debian, in particular about what is going to go into >> jessie. In short, I'd rather see the package removed from Debian than >> stay in the current status. > > Please note that this is not a team-maintained package. We could do a > non-maintainer upload of it, but I'd rather see either 1) Adam, the current > maintainer CC'd here, update the package, or 2) have Adam move the package to > the Debian Python team, where we could collectively maintain it going > forward. see #673962. while it is ITA, there is no action, and it should be orphaned again. Or adopt it. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54413093.30...@debian.org
Re: Building Python without SSLv3 breaks requests
On 11/19/2014 12:45 AM, Yannick Roehlly wrote: Hi, The building of Python 2 without SSLv3 support breaks requests: import requests Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 68, in _attach_namespace(urllib3, 'requests.packages') File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 63, in _attach_namespace module = __import__(name) File "/usr/lib/python2.7/dist-packages/urllib3/contrib/pyopenssl.py", line 73, in ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD, AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3' and maybe other packages or software (for instance, a local install of Vim's YouCompleteMe embedding it's own Python requests does not work). Should bugs be reported against the broken packages or should the SSLv3 disabling in Python 2 be done with corrections? without the patch, the python2.7 autopkg tests fail. see http://ci.debian.net/packages/p/python2.7/unstable/amd64/ I'll wait for the -12 results. I think it would be better to test for this attribute first before using it. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546c435d.9040...@debian.org
Re: Adoption of Slides (Python-based Slide Maker)
Hi, I won't have the time to do that, CCing debian-python. You may want to ask for a sponsor there, or even join the python-modules team. Matthias On 02/06/2015 06:23 AM, Riley Baird wrote: > Hi Matthias, > > A couple of years ago, you orphaned the "slides" package. I'd like to > adopt it, but since I'm not a DD, I can't upload the package. Would you > be interested in sponsoring my uploads? > > You can get the new version of the package with this command: > dget -x > http://mentors.debian.net/debian/pool/main/s/slides/slides_1.0.1-14.dsc > > For your reference, the changelog entry is: > * New maintainer (closes: #623271). > * Upgraded to Debhelper 9/pybuild > * Bumped standards version to 3.9.6 > * Added Vcs and Homepage fields to d/control > * Changed dependencies > * Added DEP-5 copyright > * Extended the description of slides-doc > * Updated source format to "3.0 (quilt)" > -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54dc1874.9050...@debian.org
Re: dh_python2 extension rename breaking module loading
On 02/11/2015 04:04 PM, Michael Crusoe wrote: > Hello, > > I'm working on the packaging of the khmer project[0] with the debian-med > team[1] and we've run into an odd problem: dh_python2 renames the Python > extension shared library from `_khmermodule.so` to a version with a > mutliarch triplet: `_khmermodule.x86_64-linux-gnu.so`. This breaks module > loading: "ImportError: No module named _khmer". The interpreter doesn't look up the old "module" name with the multiarch suffix. Best thing would be to rename it manually (removing the "module" substring. Of course dh_python2 could do that as well. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54dc6a6d.7050...@debian.org
Re: Debian and .pth files
On 03/23/2015 02:38 PM, Barry Warsaw wrote: > On Mar 23, 2015, at 11:25 AM, Piotr Ożarowski wrote: > >> I can change that and remove them in first dh-python's Stretch upload if >> there's an agreement to do that. > > +1. pth files are evil. If stuff breaks because of their removal, we'll have > plenty of time to fix them. well, they are needed at least in Debian, because some python packaging helper introduced a separate site directory. Let's remove that helper first. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55104f52.60...@debian.org
Re: PyCon BoF: Stretch goals for cPython, PyPy & CFFI
On 04/13/2015 11:07 PM, Donald Stufft wrote: > >> On Apr 13, 2015, at 4:17 PM, Stefano Rivera wrote: >> >> Matthias and I are planning to have a Debian Python BoF at PyCon, >> tomorrow afternoon. I think lunch is 2pm, so 3pm? >> >> Meet outside the cPython sprint room? >> >> Matthias wants to discuss general stretch goals for Python in Debian. >> I want to make concrete plans for py3k packages that are compatible with >> multiple interpreters. >> >> > > Does this mean PyPy too? It’d be great to have a (not just specific to Debian) > standard for how to mark a binary for a particular Python that gracefully > handles > other interpreters too. Right now we have the de facto standard of binary, > binaryX, > and binaryX.Y but that really only sanely handles CPython. can we do that in a separate session? I'm not keen on introducing another hierarchy like /usr/lib/pypy2/dist-packages, and a hierarchy of pypy-* and pypy3-* packages. This is an issue for dependency tracking (for Debian packages), and multiarch able packages. I feel that deserves some more preparation, and time. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/552c3eb1.20...@debian.org
Re: PyCon BoF: Stretch goals for cPython, PyPy & CFFI
On 04/14/2015 01:20 AM, Scott Kitterman wrote: > What is a /usr/bin/python launcher? #! /bin/sh python=$(shuffle /usr/bin/python2 /usr/bin/python3) exec $python "$@" I agree it's not perfect, there should be a preference depending on the number of '2' and '3' digits in the date, when you're trying to execute it. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/552c57e6.6010...@debian.org
Re: Python 2 d-d-a proposal
On 04/15/2015 10:27 PM, Paul Tagliamonte wrote: > Heyya d-p, > > I'd like to send an email to d-d-a asking that project to consider no > longer creating new Debian tools in Python 2. > > I'd like this to have the endorsement of the team, so, does anyone object to > me asking people to not write new tools in Python 2 only (prefer alternative > deps or porting), and only use Python 2 in very special curcumstances or > for legacy codebases (perhaps a pitch to move to Python 3), along with a > note that we plan to deprecate Python 2 when upstream support is gone > (2020), which puts us on track for two cycles (Buster) > > > I'll make note of a team which should exist to help with such porting, > (I'm up to help with this) that was one of the items that came out of > the PyCon chit-chat. I got the sense from the room that this would be > OK, but just checking if anyone here has a substantive objection. > > If not, I'll send that out later on today/tomorow. sure, please could you also propose not to accept new packages which are Python3 compatible upstream, but use Python2 in the packaging? Same thing for modules when Python3 is supported upstream, but only the Python2 module is packaged. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/552ed301.9030...@debian.org
Re: image-file-in-usr-lib
On 05/11/2015 04:08 AM, Ben Finney wrote: > "Paul R. Tagliamonte" writes: > >> That or symlink them in from /usr/share ;) > > Yes, that works too (and I've done it in my packages): > > Use ‘dh_install’ to install the non-program files to the correct > location under ‘/usr/share/foopackage/’, and then create symlinks in the > program directories where the program is looking. > > The non-program files are in the right location, the program can > continue to be ignorant of the filesystem layout, and you didn't have to > patch any code. there are some discussions on the distutils SIG where to move certain types of files. It would be nice if somebody with a distro point of view could look at these discussions and engage. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55500fde.1090...@debian.org
Re: pybuild (Re: image-file-in-usr-lib)
On 05/11/2015 09:03 AM, Ole Streicher wrote: > Ben Finney writes: >> Ole Streicher writes: >> Installing the non-program files to ‘/usr/share/foopackage/images/’ (for >> example) is simple enough, using ‘dh_install’. > > I am using pybuild, and I am wondering why it doesn't do this > automatically (maybe with some help)? > > Generally: pybuild seem to install all files into /usr/lib/? As far as I > understand the FHS [1], architecture independent files should go to > /usr/share. But, almost all python files (except maybe compiled .so > extensions) are architecture independent? > > * .py sources > * .pyc bytecode > * .egg-info The FHS never talks about putting *code* into /usr/share. So pybuild is right from my point of view to put it in /usr/lib. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55507195.9010...@debian.org
Re: Filesystem layout choices in Distutils
On 05/11/2015 04:27 AM, Ben Finney wrote: > Matthias Klose writes: > >> there are some discussions on the distutils SIG where to move certain >> types of files. > > Can you please show a URL to a specific discussion you think would > benefit from a Debian contribution? https://mail.python.org/pipermail/distutils-sig/2015-April/026114.html https://mail.python.org/pipermail/distutils-sig/2015-April/026136.html https://mail.python.org/pipermail/distutils-sig/2015-April/026244.html -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55507257.4060...@debian.org
python-*-dbg packages should not be stripped
The packages built for the Python debug interpreters should not be stripped. Usually this has to be done on a per package basis, however when converting to the pybuild system, this is easily missed. It is now documented in [1], but I assume a lot of packages just strip the -dbg packages. Maybe lintian should warn about python -dbg package, - when the extension for the debug interpreter is stripped. - when the -dbg package doesn't contain the debug information for the normal extension build. [1] https://wiki.debian.org/Python/LibraryStyleGuide#Building_python_-dbg_packages -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55800079.3060...@debian.org
Re: Getting ready for Python 3.5
On 06/30/2015 12:04 AM, Barry Warsaw wrote: >> At the same time - are there plans to upload python3-defaults with enabled >> support for Python 3.5? > > Yes, but atm, there's no eta. wrong. it's in experimental. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5591c213.7040...@debian.org
Re: Removing some python3-* packages
On 07/09/2015 12:25 PM, Robert Collins wrote: > On 3 July 2015 at 08:29, Scott Kitterman wrote: > >> I think dropping these duplicates is the only thing that makes sense. For >> reference, I dropped python3-ipaddr once python3.2 was gone (because 3.3 has >> ipaddress, which does the same thing). > > Where its a dupe sure. > > unittest2, traceback2, linecache2, mock are not duplicates of the > functionality in 3.4 - they are backports of things in 3.5 (to all > pythons). And they will shortly have more than 3.5 itself has in it, > as they are rolling backports: what lands in 3.6 will go into them. So > I don't think removing them makes sense. I think it does. You are confusing here your role as an upstream Python author, as a third party upstream developer and as a Debian developer. As an upstream Python author you are actively forking the Python standard library. I don't think I read any PEP about these forks. As a third party upstream developer (I assume openstack in this case) you want to provide a way to port this stack to Python3. Having these modules available for Python2 makes sense, but using these modules for Python3 is just a lazy way. As a Debian developer you are duplicating code, and no, I don't think that providing this code under a different name is different enough to rectify distribution of this code in Debian. In the past, the use of modules added in the standard library was handled like: try: import except ImportError: import as >From my point of view this should be done with your python3 modules as well. As a service to the community you could provide appropriate snippets like the above as well. maybe adjusted for different Python versions. Further, if your forks gain popularity, there's no way out to remove these at some time, because people will rely on these forks, having no way out of using these modules, obsoleting the versions in the standard library, and people will be stuck with your forks. So please remove the python3 versions at least for Debian. I will definitely ask for their removal, and will add appropriate Conflicts/Replaces once 3.5 becomes the default in Debian. Matthias
Re: trying to solve the pytango FTBFS with gcc5
On 09/06/2015 04:24 PM, Scott Kitterman wrote: > On Sunday, September 06, 2015 08:23:37 AM PICCA Frederic-Emmanuel wrote: >> Hello, guyes, >> >> I am working on this bug report[1], and I would like your opinion. >> this package depends on the tango library which was rebuilt with gcc5 and >> updated for the libstdc++6 transition. >> >> Now as you can see in the bug report, pytango FTBFS with a missing symbol. >> and indeed the missing symbol correspond to a c++11 string. >> >> I would like to understand why pytango expect old abi string instead of the >> new c++11 even if during the build -std=cxx01 is given to gcc. For >> information the files are in fact c++ files. >> >> I also tryed with c++11 and I got the same error. >> >> So I do not understand what is going on. >> Is there something special done by distutil when compiling an extension ? >> is it a problem with gcc (the C compiler) which doesn not use correctly the >> -std:cxx flag when compiling c++ files ? >> >> any help would be appreciate. >> >> thanks >> >> Frederic >> >> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797284 > > The old abi is explicitly set by line 261 of setup.py. no. the libstdc++ ABI is unrelated to the C++ standard used for the build. the symbol is defined: $ objdump -T /usr/lib/x86_64-linux-gnu/libtango.so|grep _ZN5Tango11DeviceProxy14get_corba_nameB5cxx11Eb 002ce1a0 gDF .text 0388 Base _ZN5Tango11DeviceProxy14get_corba_nameB5cxx11Eb so find out why _PyTango.so doesn't find it.
Re: I've been removed from the Python team
kindergarten ... On 30.09.2015 21:41, Thomas Goirand wrote: Hi, Piotr decided to remove me from the Python team. Those who don't agree (especially admins) please voice your concern. It is my view that this is an over reaction and that it should be reverted. Thomas Goirand (zigo)
Re: Request to join
On 07.10.2015 11:46, Piotr Ożarowski wrote: [Jan-Pascal van Best, 2015-10-07] I look forwarded to working with you on Python packaging. If I'm accepted into the team, I'll upload the packaging work up to now to oh, best join request so far! do you call him by name or value? ;)
Re: dh-python (pybuild + dh_py*) documentation
On 26.10.2015 12:36, Piotr Ożarowski wrote: there are manpages: pybuild¹, dh_python3² / dh_python2³ / dh_pypy⁴ there's a wiki page⁵ with examples, there's even /usr/share/doc/dh-python/README.PyDist⁶ and a talk⁷ about pybuild during DebConf... but people still tell me dh-python's documentation sucks so... talks and mailing list discussions are forgotten. How can I improve it? Do you need more detailed description of options? Do you need more examples? Or maybe I should hide most of options, the "corner case" ones? I focus on making things work out of the box, if possible, and make it very customizable so that weird corner cases are possible as well - this means there are a lot of options, is this the problem? Can you be more specific about what's missing? Agreed on the high level overview. Maybe somebody could come up with a table of contents, and then people can start filling that? There was at least one comment from a book author ;) I'd like to see a section with examples too, maybe even referencing particular packages, which show good practice for a given use case, or which demonstrate some feature. Please don't hide things. When I see something in a build log, I'd like to be able to reproduce it. pybuild writes these "I: ..." messages, but these are still incomplete. It would be good to see directory changes and other side effects like setting of env vars and written config files as well. I found these missing while looking at #803242. However asking you on irc usually helps ;) Having these build logs a bit more verbose won't hurt. The #803242 is exposed by having packages built with multiple python versions, so maybe it would have been found by a testsuite, or some autopkg tests. A testsuite for the pybuild features would be very nice to have. Matthias
