[RFS] RadioTray
Dear Python Team, I am looking for a sponsor for RadioTray. RadioTray was removed from official Debian repository, because it required python 2. During this time I was working on porting it to python 3. But I did not made it in time and also it seems the old developer abandoned the program. At least the original repository is no longer available. So I put the repository back on github under: https://github.com/Borim7/radio-tray RadioTray is running now with python3 and works reliable. Currently it is available via Ubuntu PPA: https://launchpad.net/~borim/+archive/ubuntu/radiotray but it would be great, if RadioTray will get back into the official Debian repository. I have already written a mail to the old Debian maintainer Elías Alejandro Año Mendoza, but did not get an answer. Is here someone, who is willing to sponsor RadioTray? Regards, Matthias
Re: [RFS] RadioTray
Hallo, thanks for the hints. I have checked through all bugs, which are referenced in the removal log for radiotray. The reason of removal and most other bugs are fixed during porting radiotray to python 3, or are not longer reproducible. The details are documented at: https://github.com/Borim7/radio-tray/issues/7 In the instructions from "Reintroducing packages" one point is to update or reopen old bugs. Should this also be done, although the radiotray package is still removed? I hesitate to do it, because it is a little bit weird to open bug reports for something, that is no longer part of Debian. Regards Matthias Am 05.01.22 um 05:15 schrieb Paul Wise: > On Tue, 2021-12-28 at 18:37 +0100, Matthias wrote: > >> but it would be great, if RadioTray will get back into the official >> Debian repository. > > Please note the extra steps required when reintroducing packages: > > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs > >> Is here someone, who is willing to sponsor RadioTray? > > If you don't get a response here, filing an RFS can sometimes work: > > https://mentors.debian.net/sponsors/rfs-howto/ >
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
rted by the source package (XS-Python-Version or >debian/pyversions) is either the specific version of Python supported, or >"all" [40][10], if there are no specific restrictions based on Python >version. > > If a single version of Python is supported, then the versions supported ^ singular! >by the binary package (XB-Python-Version field or the file .versions) is >set to that version (copied from XS-Python-Version). >If the current version is not supported, this field it set to the >minimum version actually supported by the module. what do you mean? >If the current version is supported (or >there are no restrictions on the version of python supported), then this >field is set to the current version. > 3.6. Public pure Python Module > > Public modules should be packaged with a name of python-foo, where foo >is the name of the module. Such a package should support the current >Debian Python version, and more if possible. > > There are two kinds of public pure Python modules, the most common being >the variety that live in unversioned public module directories, and, in >rare cases, pure python modules that live in versioned public module >directories. The latter is usually the case when the pure Python module >imports an public extension module from the same directory, and thus the >public extension and pure python modules must be in the same directory. >Otherwise, pure python modules should live in an unversioned public module >directory. What is the intention of that paragraph? I would understand /usr/lib/site-python as "unversioned public module directory", and /usr/lib/pythonX.Y/site-packages as "versioned public module directory", but these terms are not defined, and you do seem to have a different understanding. > Depending on the packaging utility used, the modules live in either >/usr/share/python-central or in /usr/share/python-support/$package. that is wrong. 1) there's nothing wrong having these still in /usr/lib/pythonX.Y/site-packages. 2) please avoid naming of these directories in the document. these should be considered private directories for the tools. For the case of pycentral, you can get the directory name using "pycentral pycentraldir ". > Official pure Python modules generally live in a different set of official? >directories than unofficial ones, but are otherwise treated exactly like >other public pure Python Module which live in unversioned directories as >detailed below. [skipping 3.6.x] for review >-- > > 3.6.1. Byte compiling > > In the common case of pure Python modules in unversioned public module >directories, tools exist to help byte compile the pure Python modules for >all versions of Python installed on the target system. In case of pure >Python modules in versioned public module directories, byte compilation is >up to the package scripts. maybe that's not the best place to mention /etc/python/debian_config, but scripts byte-compiling files should honor the byte-compile property. packages should only byte-compile the files belonging to the package, or else error message for byte-compilations are reported for random packages. 3.8 missing: Packages using embedded python interpreters (libapache2-pythonX.Y, which should not be collapsed as libapache2-python), vim, and maybe other packages. > 4.1.1. rtupdate script invocation > > 1. in the pre-installation phase of the python package, the package >supplied scripts are called with the parameter: pre-rtupdate runtime> > > A failure in any script results in the failure of the >pre-installation script of the python package. > >[42]Note Whether or not all scripts are run, or the process aborts > at the first failure, is still under flux > >Since such a failure of a script would leave all packages whose >pre-rtupdate has been run in a dangling state, a bug in a pre-rtupdate >will always be a critical bug. Be very very careful when working on a >pre-rtupdate script. I'm adding a "failed-pre-rtupdate" hook for the next upload, which is run, if the pre-rtupdate hook fails (to allow the package to go to a sane state again). I do have a different view on raising build and support information to the Packages/Sources files; in other cases the document clarifies things well. IMO the current section 3.6 makes things more confusing than they are (at least for me). Would it be helpful to add paragraphs starting with "Example:" in sections where they are useful? I.e. most package maintainers won't need the rtupdate scripts, and therefore could skip reading when they don't need these scripts. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
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 depend > on it (Python applications mostly) should use private directories and thus not > pollute the global namespace (we should add this to the Python policy, IMO) "current" is also useful to only provide a public module for just the default version. I'm unsure what you mean with when talking about the above mentioned "issue" 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
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
Bug#669404: ITP: alembic -- lightweight database migration tool for SQLAlchemy
Package: wnpp Severity: wishlist Owner: "Matthias Kümmerer" * Package name: alembic Version : 0.3.1 Upstream Author : Mike Bayer * URL : https://bitbucket.org/zzzeek/alembic * License : MIT Programming Lang: Python Description : lightweight database migration tool for SQLAlchemy Alembic is a new database migration tool, written by the author of SQLAlchemy. A migration tool offers the following functionality: . * Can emit ALTER statements to a database in order to change the structure of tables and other constructs * Provides a system whereby "migration scripts" may be constructed; each script indicates a particular series of steps that can "upgrade" a target database to a new version, and optionally a series of steps that can "downgrade" similarly, doing the same steps in reverse. * Allows the scripts to execute in some sequential manner. -- 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/20120419162405.20471.73090.report...@klio.matthias-k.org
PIL/python-imaging becomes a python package and gets Python3 support
[ targeted for jessie, not for wheezy ] PIL/python-imaging didn't see any updates for a long time; this did now change with the "PIL friendly" Pillow fork, introducing support for Python3. Pillow is now installed as a python package, not using the PIL approach anymore to install many toplevel modules. To keep the current packages working, python-imaging now depends on python-imaging-compat which again provides the old toplevel modules (at least those documented in the PIL reference manual). When packages will be fixed, the dependency will be dropped, and hopefully before the jessie release the python-imaging-compat package can be removed again. The python-imaging-compat package is only available for Python2, not for Python3. If your source package builds a python- package, please consider packaging a python3- package as well. If PIL is the missing Python3 bit for your application, please consider building it using Python3. Fixes should be easy and made in a way that works with both the old PIL modules and the new Pillow egg/package: import Image should become try: from PIL import Image except ImportError: import Image As an alternative, add a dependency on python-imaging-compat, however this will stop working once this compat package is removed again. Packages were uploaded to experimental, currently waiting in NEW. Until then, download these from deb http://people.debian.org/~doko/tmp/PIL ./ There are 126 source packages needing updates. The list of packages and maintainers is attached below. I'll file bug reports later (user: d...@debian.org, tag: pillow). Please report any other issues to the python-imaging packages. Matthias A Mennucc1 freevo (U) Agustin Henze nikola Alberto Garcia ocrfeeder (U) Alexandre Fayolle python-scipy (U) Andreas Noteng python-easygui Andreas Putzo gpsdrive (U) Andreas Tille dicompyler (U) last-align (U) Andreas Wenning python-uniconvertor (U) Andreas Wenning python-uniconvertor Andres Mejia xbmc (U) Andrew O. Shadura twms Angel Abad glue Anton Gladky yade (U) Arnaud Quette moovida-plugins-bad (U) pigment-python (U) Barry deFreese snowballz (U) Barry deFreese fretsonfire (U) tpclient-pywx (U) Baruch Even hocr (U) Ben Finney python-docutils (U) Bernhard Reiter ocrfeeder (U) pysolfc (U) Carl Fürstenberg plastex Charles Plessy last-align (U) Chow Loong Jin remuco Chris Lamb rst2pdf Christian Hammers fofix-dfsg Christian Marillat gourmet Christoph Berg pycocuma Christopher Baines fgo Dafydd Harries glitch numm Daniel Kahn Gillmor python-qrencode trac-odtexport Daniel Leidert (dale) bkchem (U) gausssum (U) Daniel Stender didjvu Daniel Watkins python-django-filebrowser Daniele Tricoli circuits (U) David Andel uligo David Cournapeau python-scipy (U) David Martínez Martí (mainkey) soya (U) David Martínez Martí fretsonfire (U) David Paleino tilecache (U) Debian Games Team fretsonfire pysolfc snowballz tpclient-pywx Debian GIS Project gpsdrive grass tilecache Debian Hams group wsjt Debian Hebrew Packaging Team hocr Debian HPIJS and HPLIP maintainers hplip Debian Med Packaging Team dicompyler last-align mobyle pylibtiff Debian Multimedia Maintainers advene python-pyo streamtuner2 Debian Python Modules Team aafigure (U) basemap circuits gamera (U) pisa plastex (U) pycaptcha python-aalib python-django-feincms (U) python-django-filebrowser (U) python-docutils python-easygui (U) python-enable python-reportlab (U) python-scipy python-scrapy python-trml2pdf python-uniconvertor (U) sorl-thumbnail soya (U) sphinx (U) stepic (U) sympy Debian QA Group xmms2tray Debian Science Maintainers guiqwt yade Debian Science Team svgtoipe Debian VoIP Team mumble-django Debichem Team bkchem gausssum Dmitry Nezhevenko djblets Dmitry Smirnov xpra (U) Emfox Zhou comix mcomix (U) Emilien Klein nautilus-image-manipulator Emilio Pozuelo Monfort phatch (U) Filip Chabik gwibber (U) Francesco Namuri virtualbricks Francesco Paolo Lovergine gpsdrive (U) grass (U) Freevo Debian Dream Team freevo Gabriel Falcão Gonçalves de Moura python-sponge Georg W. Leonhardt freevo (U) Georges Khaznadar expeyes sympy (U) Giovanni Mascellani wotsap Gürkan Sengün photofilmstrip Hubert Chathi asymptote Ignace Mouzannar python-scrapy (U) Igor Stroh python-reportlab (U) Jakub Wilk aafigure gamera python-docutils (U) sphinx Janos Guljas python-django-feincms Jari Aalto oboinus Jens Göpfert photofilmstrip (U) Jerome Alet pkpgcounter (U) Jerome Kieffer pyfai python-fabio John Goer
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
ut 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 think it needs to be raised to a pre-dependency. 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/519b990e.1080...@debian.org
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
Request to join the DPMT
Hi everyone, i prepared an update to the package python-pisa [1] and would like to join the DPMT to commit the changes to the subversion. At the moment i use a temporary git repository at alioth[2]. My alioth account name is matthias-guest. best wishes, Matthias [1] http://packages.qa.debian.org/p/pisa.html [2] http://anonscm.debian.org/gitweb/?p=users/matthias-guest/pkg-python-pisa-temp.git;a=summary signature.asc Description: PGP signature
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: /usr/bin/django-admin in python-django
Hi,
Karsten Hilbert:
> Writing '''' would make the first quote escape the second.
>
Not escape, but …
> Or some such :-)
>
To make this more explicit:
foo=''' '
echo This is Shell code
exec python $0
' '''
print("This is Python")
So to Python, you have a (multiline, hence the triple-quote) string which
contains of a space and a single quote, a linefeed, random text, and the
reverse linefeed-singlequote-space combo.
To the shell, $foo is a single space.
In fact, I would do this slightly differently:
#!/bin/sh
# -*- coding: utf-8 -*-
shell_code=''' '
echo This is Shell
exec python $0
python_code='''
## ONLY use DOUBLE quotes ‹"› after this line
print("This is Python")
# End of Python code. Do not modify this line. #'
This way, "dash -n $SCRIPT" will ignore the Python code
(since it's a string) and not report a syntax error.
--
-- Matthias Urlichs
--
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/20140721095510.ga15...@smurf.noris.de
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: Help needed to test packages with Django 1.7
Hi,
Barry Warsaw:
> >- beautifulsoup
>
> Would it be better to port to dependencies to beautifulsoup4 which is already
> Python 3 compatible upstream and available in Debian as python{,3}-bs4? The
> upstream docs claim it's pretty compatible, albeit with some deprecated
> (non-PEP 8 compliant) names.
>
Agreed. In fact I'd recommend that bs3's reverse dependencies get converted
to bs4 before the release (and then drop bs3 from the archive) if possible.
--
-- Matthias Urlichs
--
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/20140806101704.gb15...@smurf.noris.de
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: When packaging a library, should I prevent its test suite from being packaged
Hi, Konstantin Khomoutov: > have discovered the tests attempt to connect to a MySQL instance on > the localhost, and authenticate there as the user "root" using no > password. I would file an Upstream bug for this. They should use a "test" user with a "test_PACKAGENAME" database, and make the mysql credentials overrideable (via environment or whatever). Requiring (a) root (b) without a password (c) on localhost (presumably) is a bad idea on all three counts. -- -- Matthias Urlichs -- 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/20140910090429.ga21...@smurf.noris.de
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: Fwd: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1
Hi,
Scott Kitterman:
> This kind of nonsense is a great reason to stay with svn.
>
Nah. It's a great reason to teach the tool in question to be *way* more
reasonable. Who needs a single email per commit? Esp. since the number of
actual commits will go way up with increased git usage – feature branches
are easy in git, and more granular commits are a great way to help with
tracking down exactly which change introduced a regression.
An hourly or daily "look what has been committed today" cron job which
sends an email summary is more than sufficient, extremely fast when it
doesn't have to do anything, and ten lines of non-looping shell script;
"git log" has enough options to do any format you want.
Semi-tested proof-of-concept:
#!/bin/sh
BRANCH=${1:-master}
LOG_OPTS="--simplify-merges"
DEST="python-comm...@whatever.com.invalid"
LAST="$(git config commitmail.$BRANCH.last)"
if [ -z "$LAST" ] ; then echo "First call, not emitting anything">&2 ; exit ; fi
HEAD="$(git rev-parse $BRANCH)"
if [ -z "$HEAD" ] ; then echo "Branch '$BRANCH' unknown!">&2 ; exit 1; fi
git config commitmail.$BRANCH.last $HEAD
if [ "$LAST" = "$HEAD ] ; then echo "Nothing changed, exiting">&2 ; exit ; fi
git log $LOG_OPTS $LAST..$HEAD | mail -s "Changes on $BRANCH until $(date)"
$DEST
#echo "mailed log of $(git log --oneline | wc -l) changesets"
exit 0
--
-- Matthias Urlichs
--
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/20140924061450.ga6...@smurf.noris.de
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
Hi, Charles Plessy: > https://github.com/mhagger/git-multimail/ > Looking at that code, IMHO it should be sufficient to add the arguments '--' and 'debian' to all calls of "git revlist". -- -- Matthias Urlichs -- 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/20141010111332.ga3...@smurf.noris.de
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: Using pristine-tar
Hi, Charles Plessy: > Pristine-tar is much about preparing a package update while not having access > to the Debian archive at the same time. Two' invokations of git-archive will > not necessary generate byte-identical tarballs. Two invocations of pristine-tar will not, either, if you happen to use a different version of tar than the one used to prepare the pristine-tar entry. I'd rather record the .orig.tar.?z's exact size and hash(es). -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: About requests.packages.urllib3 in Debian
Hi, Daniele Tricoli: > Due to #753578 I added a stub (technically I just used a symlink) to make > import requests.packages.urllib3 works. I'd add a stub _file_ which just contains "from urllib3 import *". -- -- Matthias Urlichs signature.asc Description: Digital signature
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: Kivy packages at Debian
Hi, Vincent Cheng: > there does seem to be major differences that may make syncing > this more trouble than it's worth (e.g. package names; getting them in > sync means adding a mess of breaks+replaces relationships and regular > testing to ensure a smooth upgrade path between Ubuntu<->PPA). > Strictly speaking PPAs aren't officially supported to begin with, so > the easy way out would be to just say that the Ubuntu packages aren't > compatible with upstream-provided PPA packages... > So why not ask Upstream (or whoever provides the PPAs) to switch to the Debian/Ubuntu version of debian/*? -- -- Matthias Urlichs signature.asc Description: Digital signature
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
