Re: Launchpad: Merge of Accounts Requested
Someone has asked us to merge one of your Launchpad accounts with another. If you go ahead, this will merge the account called 'Debian Python Modules Team (debian-python)' into the account 'johnfrandes12'. To confirm you want to do this, please follow this link: This looks extremely fishy - and I also wonder why someone used a public mailing list address to register a Launchpad account?
Re: sentry-python
Hi Eberhard, Is anyone working on updating sentry-python <https://tracker.debian.org/pkg/sentry-python> to prevent autoremoval due to #1058422 <https://bugs.debian.org/1058422>? I did some debugging/testing, because this bug affects our Cura packages, but I didn't get very far. The root of the problem is a change in the Python 3.12 logging library: https://docs.python.org/3/library/logging.html#logrecord-attributes > Changed in version 3.12: taskName was added. The unit tests in Debian's sentry-sdk can't cope with that. However, it seems like upstream has already done the work to fix Python 3.12 compatibility: https://github.com/getsentry/sentry-python/issues/2480 So, it should suffice to upgrade to at least 1.34.0 (or better yet, the latest 1.x release). Regards, Gregor
Re: Recommended way of installing system-wide python application and libraries
As far as how to do this within an existing cmake project, unfortunately, there doesn't seem to be a clear/easy way. The only cmake example I can think off of the top of my head is cvc5. It still uses setup.py though, so not a great future-looking example (and I had to patch it to build the Python bindings in Debian): https://github.com/cvc5/cvc5/blob/main/src/api/python/CMakeLists.txt We've been using cmake + pybuild very successfully for packaging the various Cura components: https://salsa.debian.org/3dprinting-team/cura/-/blob/master/debian/rules https://salsa.debian.org/3dprinting-team/cura-engine/-/blob/master/debian/rules https://salsa.debian.org/3dprinting-team/uranium/-/blob/master/debian/rules etc. Cura is a mix of Python and C++, so a pure Python tools approach wouldn't have worked well. Upstream used cmake exclusively in the past, and that worked very well together with pybuild. Unfortunately, they recently introduced a new build environment based on conan, which is why we haven't managed to package new Cura versions yet. The best solution right now is probably: https://scikit-build-core.readthedocs.io It's specifically designed for combining CMake + Python. I don't know how well this is supported in Debian so far.
Re: pybuild and optional dependencies
How can I teach pybuild that I really want xraylarch[larix] ? I don't know if there's a mechanism that can add optional dependencies automatically, but the easiest way would be to just add them to the Depends: ... or the Recommends: ... list of the respective package in debian/control.
Request for getting added to the team
Hi all, herewith I request getting added to the Debian Python Team. The reason for this is that I'd like to package Darker [0] and possibly more libraries and applications in the future. My Salsa login is "gdstr" [1]. I have read the Debian Python Team Policy [2] and accept it. Kind regards [0] https://github.com/akaihola/darker [1] salsa.debian.org/gdstr [2] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst -- Gregor
Python module installation with cmake
Hi,
I'm looking for help with a regression in cmake 3.27, that is currently
producing incorrect module installation paths for the Python package
Uranium: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042157
Uranium's cmake script uses the cmake variable Python_SITELIB to
determine the installation path for Python modules, and that used to
work correctly up until cmake 3.26.
In 3.27, the value of this variable has changed, and it now points to
/usr/local, which seems wrong to me. Furthermore, it includes the full
Python version, which also doesn't look right:
In 3.26.4-4, Python_SITELIB is /usr/lib/python3/dist-packages, and the
documentation[1] says:
> Information returned by
distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False)
or else sysconfig.get_path('purelib').
In 3.27.1-1, it's /usr/local/lib/python3.11/dist-packages, coming from[2]:
> Information returned by sysconfig.get_path('purelib').
There don't seem to be any other useful cmake variables that could be
used. The relevant cmake script parts look like this:
if(NOT DEFINED Python_SITELIB_LOCAL)
set(Python_SITELIB_LOCAL
"${Python_SITELIB}"
CACHE PATH "Local alternative site-package location to
install Uranium" FORCE)
endif()
install(DIRECTORY UM DESTINATION "${Python_SITELIB_LOCAL}")
I do think this is a regression in cmake, but perhaps something was
wrong with the script in the first place and only showed up now?
Can someone help with sorting this issue out?
Thanks,
Gregor
[1] https://cmake.org/cmake/help/v3.26/module/FindPython.html
[2] https://cmake.org/cmake/help/v3.27/module/FindPython.html
Re: how to properly split up into python3-foo and foo-util package?
5) Not really 100% Debian related, but in the Python sdist,... should that contain the debian/*? No, and the upstream source shouldn't contain debian/ anyway, as the life cycles of packaging and upstream sources should be separate even if the person doing both is the same. This would then be a "native" package, and it's not recommended to use this package format in most cases: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#native While it can happen that a developer maintains the Debian packages for their own software, they also have to consider other dpkg-based distributions, such as Ubuntu. Maintaining the Debian changelog for both in the same upstream repository isn't a lot of fun.
Re: Bug#1038883: dolfin: autopkgtest failure due to bytes as docstring
your package fails the autopkgtest with the new pytest 7.3 because python/test/unit/function/test_function_space.py uses a bytes object (b""" literal) as module docstring, and pytest crashes while looking for the "PYTEST_DONT_REWRITE" marker. This does sound like a serious bug in pytest, though. If it can't process the docstring, it should ignore it, not crash. But I don't quite get why it would choke on a byte string, if it's just looking for a token? As far as I understand, using a bytes() object as docstring violates PEP-257, which is why I am filing this as a dolfin bug and not a pytest regression. I have Cc'd the debian-python mailing list for a second opinion, but I believe this bug should be resolved by getting rid of the erroneous "b" prefix. PEP-257 says: > If you violate these conventions, the worst you’ll get is some dirty > looks. But some software (such as the Docutils docstring processing > system PEP 256, PEP 258) will be aware of the conventions, so > following them will get you the best results. FWIW, I think this should be fixed in both pytest and the affected package. Unless there is a specific reason for the byte string, it should be replaced with a regular string.
Re: Lintian info message "hardening-no-bindnow" with vanilla debian/rules
I: python3-pyxdameraulevenshtein: hardening-no-bindnow [usr/lib/python3/dist-packages/pyxdameraulevenshtein.cpython-310-x86_64-linux-gnu.so] and there is nothing about CFLAGS or the like in the setup.py file. So if having this hardening flag enabled is a good thing, it should probably be enabled somewhere within the pybuild system, rather than every individual package with an extension file doing it. Hardening is generally a good thing, but can break code in subtle ways. I suppose that's why it was decided that enabling it by default in Debian was deemed too risky. Enabling it is quite easy, though: Just add export DEB_BUILD_MAINT_OPTIONS = hardening=+all near the top of your d/rules file. Some build systems may require additional flags, as documented here: https://wiki.debian.org/Hardening Also, note that hardening-no-bindnow is an Informational message, so not strictly something that needs to be acted upon: https://lintian.debian.org/tags/hardening-no-bindnow YMMV.
Re: Advice wanted: handling weird vendoring situation
> So the solution I'm currently in the process of trying is to copy the > version from the oldest supported Python version at Debian package > build time. We'll see how this goes > >> Perhaps they have a maintenance script for updating the vendored >> dependencies? You could use that to find out how to reverse the changes, >> or start from a clean slate? > > Unlikely; some of their vendored dependencies date back to Python 2.5! In that case, I think this is the issue that must be solved first: Ensuring that their code is compatible with the *latest* published version, and vendoring the system version at build time. Not a good solution, since it will still leave the system vulnerable when one of the dependencies gets a security update, but better than shipping a static version that might have numerous issues and will no longer receive any patches. The alternative would be that they take full responsibility for their vendored code, but then it will be much harder to detect when they're affected by a vulnerability.
Re: Advice wanted: handling weird vendoring situation
> I realise now that this "nice" solution won't work, as the standard > library code says: > > import socketserver > > so modifying sys.path will just change the value of > sys.modules["socketserver"]. However, the vendored code instead loads > this module to sys.modules["_pydev_imps._pydev_SocketServer"] or > something like that, deliberately avoiding interfering with > sys.modules["socketserver"]. It seems to me that the "correct" solution would be to motivate upstream not to vendor anything in their source tree. If they really need vendoring to avoid compatibility issues with various environments, they should do so only when building releases. It still wouldn't solve the problem of incompatible system modules, but at least it would make it clearer which versions they require and why. Perhaps they have a maintenance script for updating the vendored dependencies? You could use that to find out how to reverse the changes, or start from a clean slate?
Re: Fixing pytest-twisted ^W Updating twisted
> Ignoring the autopkgtest for now Lintian is complaining about empty
> binary packages for python3-twisted-{bin,dbg}. Are they needed anymore?
> OTOH it's looking not that bad and a lot of the messages should be easy
> to fix.
> X: python3-twisted: library-package-name-for-application usr/bin/cftp3
usr/bin/trial3 usr/bin/conch3 usr/bin/pyhtmlizer3 usr/bin/twist3
usr/bin/mailmail3 usr/bin/twistd3 usr/bin/tkconch3 usr/bin/ckeygen3
Sounds to me like these binaries should go into the python3-twisted-bin
package, and that it shouldn't be empty after all.
Maybe you're missing a python3-twisted-bin.install file?
Re: Why is isal limited to just three archs?
> Did you look into the source package? isal is written in assembly > language... That doesn't seem quite right. The readme states: > other: > > Compiler: Portable base functions are available that build with most C > compilers. And it does look like there are corresponding .c implementations, at least for some of the functions. Not sure about source or binary compatibility, though.
Re: How should learning to program in Python be approached, if learning objectives are sought to be customised?
> Please also advise: where could I have such repositories like such > huge oracle java object and code repository? I think what most people use as a source for Python packages is PyPi: https://pypi.org/ And there is excellent tooling around it. Personally, I prefer pipenv for application dependency management, but there are other tools. PyCharm can work with pipenv and virtualenv natively: https://www.jetbrains.com/help/pycharm/pipenv.html Minor tip, install pipenv with apt and not with pip: sudo apt install pipenv
Re: How can I override module name in autopkgtest-pkg-python
> autopkgtest [19:46:36]: test autodep8-python3: set -e ; for py in > $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with > $py:" ; $py -c "import cython_blis; print(cython_blis)" ; done > autopkgtest [19:46:36]: test autodep8-python3: [--- > Testing with python3.9: > Traceback (most recent call last): > File "", line 1, in > ModuleNotFoundError: No module named 'cython_blis' > autopkgtest [19:46:37]: test autodep8-python3: ---] > > > The actual module that needs to be importet is just blis. How can > I teach autodep8-python3 the correct module name? Simply write a suitable debian/tests/control file that uses import blis; print(blis) instead of import cython_blis; print(cython_blis) See here for an example: https://salsa.debian.org/3dprinting-team/libarcus/-/blob/master/debian/tests/control Although, it looks like this sort of trivial autopkgtest is now considered "superficial" and will no longer reduce the time until a package is autopromoted to testing.
Re: Bug#835340: Bug#938076: python-pymetar: Python2 removal in sid/bullseye
On Tue, 09 Feb 2021 19:56:10 +0100, Mattia Rizzolo wrote: > > I don't feel confident uploading this NMU myself but I'd like to see > > python-pymetar in bullseye. > Very quickly looking at the filter diff for debian/*, that looks just > fine. Cool, thanks! > But it's too late for bullseye. Without an autopkgtest (which I'm not > going to write myself not knowing the package), this will go over the > 12th, and as such won't be due to the freeze policy. Hm, right. Well, bad luck … > > Is this something the Debian Python Team could take over? > I'll keep a tab open to review and sponsor the nmu (but anybody feel > free to beat me). Thanks, much appreciated. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Simon and Garfunkel: Homeward Bound signature.asc Description: Digital Signature
Re: Bug#938076: python-pymetar: Python2 removal in sid/bullseye
On Sun, 19 Jul 2020 03:46:12 +0200, gregor herrmann wrote: > Control: tag 835340 + patch > Control: tag 938076 + patch > > On Fri, 30 Aug 2019 07:45:06 +, Matthias Klose wrote: > > > Your package either build-depends, depends on Python2, or uses Python2 > > in the autopkg tests. Please stop using Python2, and fix this issue > > by one of the following actions. > > I looked into preparing an NMU with the new upstream release in order > to fix #835340 and #938076. > > Find attached the full debdiff and the filtered debdiff with only the > debian/* files. > > I tried to find a balance between doing all necessary changes and not > completely overhauling the packaging. It seems that the resulting > binary package works, both the commandline script and the module in > ipython3, but as I'm not a python person I'd welcome reviews and > suggestions for improvement. I don't feel confident uploading this NMU myself but I'd like to see python-pymetar in bullseye. Is this something the Debian Python Team could take over? Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Rolling Stones signature.asc Description: Digital Signature
Re: Packaging a python module when already using cmake buildsystem
> It has a setup.py and uses SetupTools and DistUtils so I was hoping to > add --with Python3 and hope that a lot of magic would be done by pybuild. > However as I'm already using cmake as the build system I can't stick > pybuild in there. We use both pybuild and cmake for a couple of SIP packages: https://salsa.debian.org/3dprinting-team/libarcus However, in this case, upstream doesn't provide a setup.py at all, so cmake is used automatically. I do believe that you can force the use of cmake by adding a "--with cmake" - have you tried that?
Re: Issues when reading mailboxes from alioth-lists.debian.net
> File "/usr/lib/python3.8/mailbox.py", line 781, in get_message
> msg.set_from(from_line[5:].decode('ascii'))
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 37:
> ordinal not in range(128)
> Exit code: 1
>
> IMHO it is a bug if those mailboxes can't be read. Am I missing
> something?
I would humbly suggest that the Python2 version is silently ignoring an
encoding error here.
RFC 4155 states that the "default" mbox format is strictly 7-bit-safe
(usually ASCII), but mboxes may also be in a "local" format with
different or even mixed encodings.
Since mailbox only seems to accepts the "default" mbox format, then it's
very well possible that the Alioth mboxes are *not* in this format,
strictly speaking.
Re: Best practice on how to package a python module along with a c++ program
>> I'm packaging a c++ program (horizon-eda) which also contains a >> python module written in c++. Upstream's Makefile has a target 'pymodule' >> and 'make pymodule' creates horizon.so in the build directory. >> According to upstream this has to be copied іnto python's sys.path > > The preferred mechanism would be to install the .so file into: > > usr/lib/python3.X/dist-packages/ (where X is the python3 version you are > building with) "horizon.so" isn't multi-arch safe, so please ensure it gets a suitable filename on installation. All CPython modules I can find on my system use one of these forms: /usr/lib/python3/dist-packages/package.cpython-38-x86_64-linux-gnu.so /usr/lib/python3/dist-packages/package/module.cpython-38-x86_64-linux-gnu.so /usr/lib/python3.8/dist-packages/package/module.cpython-38-x86_64-linux-gnu.so I assume this would normally be done by distutils, or is it handled by dh_python3 automatically?
Re: where should we put private libraries
>> You should consider /usr/lib// if you want to make your >> package multiarch-safe. > > And what about ? > > /usr/lib// > > whcih one is better ? Have a look at the Debian policy at https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs It explicitly mentions: > Applications may also use a single subdirectory under > /usr/lib/triplet.
Re: where should we put private libraries
> so my question is how can I solve this error. > I thought about adding rpath to these libraries in order to move then > under a private location /usr/lib/. But for this I need to add > an rpath to all the extensions which use these libraries. You should consider /usr/lib// if you want to make your package multiarch-safe. See: https://wiki.debian.org/Multiarch/Implementation#What_does_the_end_result_look_like.3F
Re: Non-migration of cssutils
> If fixing those FTBFS is not on the table, I think you could just let it > be, and have it go out and then back in. Tricks like pinging the bug to > delay the autorm will likely backfire since it might very well be that > very same bug that is also removing calibre. At the same time, > bothering the release team for such minor matters feels somewhat > exaggerated. It doesn't look like these test failures on non-x86 will go away by themselves, though. Somebody will have to figure out what's wrong and fix them eventually. This only affects calibre itself and not the reverse deps, of course.
python3-arcus only builds for python 3.8 despite pybuild
Hi, arcus is having some build/test issues related to Python 3.7 and 3.8: https://salsa.debian.org/3dprinting-team/libarcus/-/jobs/512109 In the built artifact, there is only a SIP module for python3.8, but autopkgtest only only installs python3.7: https://salsa.debian.org/3dprinting-team/libarcus/-/jobs/512103/artifacts/file/debian/output/python3-arcus_4.4.1-1+salsaci_amd64.deb arcus is built like this: dh $@ --buildsystem=pybuild --with python3 --with sip3 Does someone have an idea why pybuild doesn't produce python3.7 and 3.8 modules, and why autopkgtest only installs python3.7 for the test dependency? Regards, Gregor
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
Oh, and by the way, I just saw this: https://github.com/kovidgoyal/calibre/blob/master/README.python3 Perhaps a working Py3 port is not so far off after all.
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
> As of now, calibre is not of sufficient quality to be part of a Debian release > and until it drops all Python2 requirements, it must be considered RC buggy. Is your quality argument based on the Calibre author's shenanigans? https://www.reddit.com/r/linux/comments/9wodtq/calibre_wont_migrate_to_python_3_author_says_i_am/ And in particular: https://bugs.launchpad.net/calibre/+bug/1714107 One thing to consider here is the relatively large user base of Calibre that doesn't know much or care about the Python 2 deprecation. They will simply perceive dropping Calibre as a bad move on Debian's side and rush towards other packages of significantly lower quality. PPAs, Snap and the like do more harm than keeping compatibility in some way for the time being. While I agree that Debian should not put up with stubborn developers, I also don't agree that end users should take the fall for Debian maintainer's decisions. Perhaps a middle ground has to be found until a viable Py3 fork of Calibre is available, or someone steps up and writes Py3 compatibility patches without dropping Py2 support? This here seems like a good starting to achieve what Calibre's author wants: https://github.com/plone/Products.CMFPlone/issues/2184#issuecomment-359445243 Though, in the long run, somebody will have to convince Kovid that writing Py3 code is worthwhile... Or take over maintenance.
Re: Streamlining the use of Salsa CI on team packages
> I am not a fan of pointing to a moving target with the "include" statement: > > include: > - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml > - > https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml > > "master" will change, and that can break CI jobs where nothing in the > local repo has changed. It does have pros and cons. The good: Additional build/verification steps or even automatic deployment can be added by the Salsa team at some point without requiring changes to each repository. The bad: As you mentioned, a moving target can be bad and cause inadvertent build failures and other issues that are out of the hands of maintainers. The ugly: Pulling in external scripts always bears a certain risk. They may go away at some point or cause potentially dangerous side effects. However, I do think that a standardised CI pipeline is very useful. Consider that the buildd infrastructure also uses a standardised build process that packages cannot simply get away from. If this process is replicated on Salsa, with an external script or not, people will quickly get a "glimpse" of what would happen on buildd. The need to manually adapt the CI script every time something changes in the buildd process is a heavy burden to bear and will easily lead to people "forgetting" to update their scripts. That kind of defeats the purpose. Also, consider that the Salsa CI pipeline is not an absolute source of truth, but a tool for developers and maintainers to quickly spot issues with their packages. If an autobuild fails, it's not the end of the world. It just means you have to go check what's going on.
Re: Ayuda para instalar python 3.7
> Para poder instalar py3.7 por default, tendrías que descargarlo desde > https://www.python.org/downloads/ > y ejecutar ```./configure && make && make install``` Alternatively, if you are patient, buster will become stable very soon. It comes with Python 3.7 by default.
ITP: python-hvac -- Python 2/3 client for HashiCorp Vault
Package: wnpp Severity: wishlist Owner: Gregor Riepl * Package name: python-hvac Version : 0.6.2 Upstream Author : Ian Unruh * URL : https://github.com/ianunruh/hvac * License : Apache-2.0 Programming Lang: Python Description : Python 2/3 client for HashiCorp Vault HashiCorp Vault API client for Python 2/3. This package is useful for Ansible, as it allows accessing Vault credentials directly from Playbooks. I intend to maintain this package together with the DPMT. The Debian repository is here: https://salsa.debian.org/python-team/modules/hvac Please review and upload to Debian if the package fits the necessary criteria. Thank you!
Re: RFS: mwic 0.7.4-1
> autopkgtest (debian/tests/) is a form of as-installed testing, which takes > the packages that were built, installs them in a relatively complete and > realistic environment (typically a lxc container or a qemu/kvm virtual > machine) and runs further tests there. Sometimes these tests just repeat > the build-time test coverage, but often they can make use of the ability > to do things that wouldn't work at build-time, like contacting Internet > services, running things as root, or relying on system services. This > often gives them better test coverage. Wow, that's even better! Thanks for the clarification. I guess I should use this feature more. :) signature.asc Description: OpenPGP digital signature
Re: RFS: mwic 0.7.4-1
> In case I've misunderstood you, and you're referring to unit tests > shipped debian/tests/*, than yes, I agree. :) As far as I understand, these tests are executed by the package builder after the upstream build script has finished. They're meant as a sort of integration test, i.e. "does this package run on Debian". There's even a Lintian tag for them: https://lintian.debian.org/tags/testsuite-autopkgtest-missing.html (which, I think, is a bit overzealous) signature.asc Description: OpenPGP digital signature
RFS: hvac/0.5.0-1
Hi, I'd like to request sponsorship for the hvac Python module. Source package: hvac Packages: python-hvac, python3-hvac Version 0.5.0-1 Upstream: https://github.com/ianunruh/hvac Salsa: https://salsa.debian.org/python-team/modules/hvac Mentors: https://mentors.debian.net/package/hvac This package contains a client library for interacting with Hashicorp Vault. It is particularly useful for Ansible, and this is also the reason why I packaged Python 2 and 3 versions (Ansible does not support Python 3 yet). I will gladly accept maintainership, but as a non-DD, support from the team is appreciated. Please review and upload the package. Thanks, Greg
New package python-hvac / Joining the team
Hello, I'd like to join the DPMT to maintain a Debian package for hvac, a Python module that allows accessing Hashicorp Vault secrets remotely. The upstream project can be found here: https://github.com/ianunruh/hvac And the Debian package repository I created is here: https://github.com/onitake/debian-hvac I tried to follow the guidelines at http://python-modules.alioth.debian.org/policy.html closely, and I intend to keep doing that for further work on this package (or other Python packages). My Alioth login is: onitake-guest If the DPMT would prefer not to take on additional members, I ask for sponsorship of this package and maintenance by the team. The package would be very useful for accessing vault secrets from Ansible, as there is a built-in lookup module that depends on python-hvac: https://docs.ansible.com/ansible/devel/plugins/lookup/hashi_vault.html This is also the reason why I included a Python 2 package build - Ansible has not been fully converted to Python 3 yet. Thank for your consideration, Gregor signature.asc Description: OpenPGP digital signature
Re: KGB bot #debian-python -> #debian-python-changes
On Thu, 08 Sep 2016 10:32:45 +0300, Martín Ferrari wrote: > >> please move KGB bot from #debian-python channel to > >> #debian-python-changes > > Done for KGB-0. > Done! Done as well. Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Beatles signature.asc Description: Digital Signature
Re: Bug#634190: O: python-kinterbasdb -- Python DB API 2.0 extension for Firebird and Interbase
On Wed, 28 Sep 2011 12:01:03 +0300, Damyan Ivanov wrote: > I have prepared an updated python-kinterbasdb package in > collab-maint's Git[0]. > > [0] > http://anonscm.debian.org/gitweb/?p=collab-maint/python-kinterbasdb.git > > My target is the fix for #643473 (FTBFS with firebird-dev from firebird > 2.5), but since the package is orphaned, I moved on to bring it > somewhat up to date. I've now made a QA upload from this git repo and pushed to collab-maint, in order to get the RC bug fixed. > I don't want to take over maintenance, since I am not a Python person > and delving into python policy will not be very productive. Same here :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Ry Cooder: Billy The Kid signature.asc Description: Digital signature
Re: Where to install non-debianized python modules?
Corey Wright wrote: >> More info is available in "Installing Python Modules", available at /usr/ >> share/doc/python/html/inst/ if you install the python-doc package, or >> online at <http://docs.python.org/inst/inst.html>. > > specifically see section "3.2 Alternate installation: Unix (the prefix > scheme)" > http://docs.python.org/inst/alt-install-windows.html#SECTION00032 > which recommends the command Sam suggested (e.g. "/usr/bin/python setup.py > install --prefix=/usr/local"). Thanks to Sam and Corey! -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Facultywww: http://www.bfro.uni-lj.si/MR/ggorjan Zootechnical Department blog: http://ggorjan.blogspot.com Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale fax: +386 (0)1 72 17 888 Slovenia, Europetel: +386 (0)1 72 17 861 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Where to install non-debianized python modules?
Hello! I am a total newbie to Python and I am confused with installation of non-debianized python modules? I am trying to install PyPedal[1] module. It has several dependencies and I have found most of them as debian packages for which I am really grateful to you folks! I am left with a list of three modules that are not debianized i.e.: pythondoc, testoob and PyPedal. How should these be installed so that I will not mess up my Debian installation? If I simply use the following wget http://puzzle.dl.sourceforge.net/sourceforge/pypedal/PyPedal-2.0.0b21.tar.gz ## This should be now general tar -xzvvf PyPedal-* cd PyPedal-* python setup.py install I will end up with messing the system stuff. Which flag should I use --home, --debian, --prefix, ... to properly separate local installation. I appologize if this is trivial, but I was not able to find any relevant info on the web. Thank you! [1]http://pypedal.sourceforge.net/ -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Facultywww: http://www.bfro.uni-lj.si/MR/ggorjan Zootechnical Department blog: http://ggorjan.blogspot.com Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale fax: +386 (0)1 72 17 888 Slovenia, Europetel: +386 (0)1 72 17 861 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[no subject]
Mit freundlichen Grüßen Gregor Rosmanek Infracor Gmbh Logistik / Gütereingang Tel.: 02365 / 494405 Fax : 02365 / 496530 eMail : gregor. rosmanek@ infracor.de
[VAC] 18/05-31/05 Alicante, Spain
Hi, I will be away from my email from 18 May until 31 May. If something urgent occurs with one of my packages, please NMU. In the case of Python, Matthias Klose <[EMAIL PROTECTED]> is your preferred contact of course. Gregor PS: I will be in Alicante, Spain during that time (perhaps with visits to Valencia and Barcelona). If somebody would like to arrange a key signing, feel free to send me an email until this Friday. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: math.exp bug on alpha?
* Bastian Kleineidam <[EMAIL PROTECTED]> [020111 11:41]: > On Thu, Jan 10, 2002 at 09:28:30PM +0300, Mikhail Sobolev wrote: > > On Thu, Jan 10, 2002 at 06:29:58PM +0100, Bastian Kleineidam wrote: > > > On Thu, Jan 10, 2002 at 05:25:43PM +, Luigi Ballabio wrote: > > > > on alpha debian, python 2.1.1-8: > > > > > > > Works for me, no aborts. (i386, python 2.1.1-8) > > Just compare the platform... :) > I did. So its a platform specific bug. Cf. http://bugs.debian.org/106421. Gregor
Re: python2.1 and MySQLdb
* Rick Pasotto <[EMAIL PROTECTED]> [011226 18:11]: > I just apt-get upgraded my python and the MySQLdb module now > gives the following error: > > Python 2.1.1 (#1, Nov 11 2001, 18:19:24) > [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 > Type "copyright", "credits" or "license" for more information. > >>> from MySQLdb import * > Traceback (most recent call last): > File "", line 1, in ? > AttributeError: 'MySQLdb' module has no attribute 'Date' > >>> Strange, I don't get this error with the packages currently in woody: freefly:9> dpkg -l python2.1 python2.1-mysqldb python2.1-egenix-mxdatetime ii python2.1 2.1.1-7An interactive object-oriented scripting lan ii python2.1-mysq 0.9.1-3A Python interface for MySQL No packages found matching python2.1-egenix-mxdatetime. freefly:10> python2.1 Python 2.1.1+ (#1, Dec 30 2001, 17:17:30) [GCC 2.95.4 20011223 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from MySQLdb import * >>> With python2.1-egenix-mxdatetime installed, it works as well. Could you tell me which versions of the package you have installed ? Do you have python2-egenix-mxdatetime installed ? Gregor
Re: Packaging decompyle - policy question
* Ben Burton <[EMAIL PROTECTED]> [02 19:20]: > > > c) A wrapper that auto-detects the format of the .pyc file and calls the > > according variant (detection of the .pyc format should be pretty easy, > > it's just a magic number, cf. /usr/share/misc/magic). > > Hm, I'll try and find some documentation on how to extract the version > information. > > > > If there are several packages then each package will literally contain a > > > single script and a symlink to a man page and would depend on > > > decompyle-common which contains the actual decompyle itself. This seems > > > a bit of an overkill. But on the other hand I don't want to provide > > > binaries that people can't run (if the appropriate python version is not > > > installed) and I don't want decompyle to depend on *every* version of > > > python in debian. > > > > Umm, are you talking about a *binary* or an *script* ? If binaries, how > > big are they ? > > Oops, I mean scripts. Very small. > > > Would it really be an issue to include three of them in a > > single package ? > > No, my problem was with placing them in *separate* packages (decompyleX.Y), > each containing about ten lines of material plus a copyright and changes > file. The problem being package bloat. Have a look at Python/import.c in the Python source tree. The algorithm for computing the magic is pretty simple (and will start to fail for the first version in 2002 ;-): /* Magic word to reject .pyc files generated by other Python versions */ /* Change for each incompatible change */ /* The value of CR and LF is incorporated so if you ever read or write a .pyc file in text mode the magic number will be wrong; also, the Apple MPW compiler swaps their values, botching string constants */ /* XXX Perhaps the magic number should be frozen and a version field added to the .pyc file header? */ /* New way to come up with the magic number: (YEAR-1995), MONTH, DAY */ #define MAGIC (60717 | ((long)'\r'<<16) | ((long)'\n'<<24)) Also, here's a snippet from my /etc/magic file: 0 lelong 0x0a0d4e99Python bytecode, magic 1997-01-21 (>=1.5.2) 0 lelong 0x0a0dc687Python bytecode, magic 2000-08-23 (>=2.0.1) 0 lelong 0x0a0deb2aPython bytecode, magic 2001-02-02 (>=2.1.1a1) 0 lelong 0x0a0ded2d Python bytecode, magic 2001-07-17 (>=2.2a2) (I.e., take the first four bytes of the pyc file and read them as 'long' in little endian format.) AFAICS, this should suffice for all versions we have in the distribution. Gregor
Re: Packaging decompyle - policy question
* Ben Burton <[EMAIL PROTECTED]> [02 18:22]: > > Hi. So I'm packaging decompyle which decompiles a .pyc bytecode file and > converts it back to python source. > > Thing is, decompyle needs to be run with the same version of python that was > used to create the bytecode. > > So the question arises as to what should go in /usr/bin. Options I see are: > > a) A wrapper script /usr/bin/decompyle which takes an addition argument > specifying the python version to run and calls the real decompyle with that > version of python (and defaulting to the default version of python); > > b) A series of binaries /usr/bin/decompyle1.5, /usr/bin/decompyle2.1, etc > with the additional /usr/bin/decompyle that uses the default debian version > of python. Hmm, how about an third option: c) A wrapper that auto-detects the format of the .pyc file and calls the according variant (detection of the .pyc format should be pretty easy, it's just a magic number, cf. /usr/share/misc/magic). The doesn't resolve the original problem, but then you could issue a message to the user that he needs to install an according Python version. In the end, this case should be pretty rare, since in most cases, it seems to be a reasonable expectation that a user has an according Python version on the system. > I'm leaning towards option (b), but this then leads to the issue of how the > binaries should be packaged. Should there be a single package decompyle > which provides all of these binaries? Or should there be packages > decompyle1.5, decompyle2.1, etc.? > > If there are several packages then each package will literally contain a > single script and a symlink to a man page and would depend on > decompyle-common which contains the actual decompyle itself. This seems a > bit of an overkill. But on the other hand I don't want to provide binaries > that people can't run (if the appropriate python version is not installed) > and I don't want decompyle to depend on *every* version of python in debian. Umm, are you talking about a *binary* or an *script* ? If binaries, how big are they ? Would it really be an issue to include three of them in a single package ? If you include that autodetection stuff, I would say go on and ship them into a single package (since the user gets a meaningful message if something doesn't work due to the lack of the correct Python version). Gregor
Re: Python-2.1 becoming Debian's default Python version
* Florian Weimer <[EMAIL PROTECTED]> [011107 16:08]: > Gregor Hoffleit <[EMAIL PROTECTED]> writes: > > >> > Python 1.6.1 is essentially the same as Python 1.6, with a few minor > >> > bug fixes, and with a different license that enables later versions > >> > to be GPL-compatible. > >> > >> The license claims to be GPL compatible, but according to the FSF, it > >> isn't, because of the choice-of-law clause. > > ^^^ > > > > Can you provide any proof for this claim ? > > > >>From http://www.gnu.org/licenses/license-list.html: > > > > The License of Python 1.6a2 and earlier versions. > > This is a free software license and is compatible with the GNU > > GPL. Please note, however, that newer versions of Python are > > under other licenses (see below). > > > > The License of Python 2.0.1, 2.1.1, and newer versions. > > This is a free software license and is compatible with the GNU > > GPL. Please note, however, that intermediate versions of Python > > (1.6b1, through 2.0 and 2.1) are under a different license (see > > below). > > You have to follow the "see below" link on this page. Sorry, I guess I was misinterpreting you. I think we do agree that the License of Python 2.1.1, according to the FSF, is compatible with the GPL ? (That was my point, and I think I was prejudicating you ;-) Now for Python 1.6.1. The 'see below' in the second paragraph links to this (refering to 'intermediate versions of Python (1.6b1, through 2.0 and 2.1)': The License of Python 1.6b1 and later versions, through 2.0 and 2.1. This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the State of Virginia, in the USA, and the GPL does not permit this. This section is incorrect, in that Python 1.6.1 has yet another different license. It should read something like The License of Python 1.6b1 and later versions, through 2.0 and 2.1, but excluding 1.6.1 and derivatives thereof. Then, there should be another section The License of Python 1.6.1 and derivatives thereof since this license is different from the license license of 1.6. In fact the modification between 1.6 and 1.6.1 (which was made possible by CNRI) was the major step in making the release of 2.0.1 and 2.1.1 possible. OTOH, I wonder if B. Kuhn would be glad to list *four* different Python licenses on that page ? ;-) Gregor
Re: Python-2.1 becoming Debian's default Python version
* Florian Weimer <[EMAIL PROTECTED]> [011107 15:04]: > Neil Schemenauer <[EMAIL PROTECTED]> writes: > > > It's probably better to check if you're unsure rather than speculate or > > guess. From the 2.1.1 LICENCE file: > > > > Python 1.6.1 is essentially the same as Python 1.6, with a few minor > > bug fixes, and with a different license that enables later versions > > to be GPL-compatible. > > The license claims to be GPL compatible, but according to the FSF, it > isn't, because of the choice-of-law clause. ^^^ Can you provide any proof for this claim ? >From http://www.gnu.org/licenses/license-list.html: The License of Python 1.6a2 and earlier versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that newer versions of Python are under other licenses (see below). The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that intermediate versions of Python (1.6b1, through 2.0 and 2.1) are under a different license (see below). Gregor
Re: lintian and new python policy
* Ben Burton <[EMAIL PROTECTED]> [011029 15:46]: > > > > Also, someone else reported that lintian complains against > > > Depends: python (>= 2.1), python (<< 2.2) > > > > This is a lintian bug. It's not bothering to notice that one's a less-than > > and the other's a greater-than. > > Btw, isn't this Depends line problematic anyway? I could have python 1.5 > and 2.2 simultaneously installed and the depends would be satisfied > without achieving what the maintainer really wants (i.e. python 2.1). "python" is a real package, no virtual one. I.e. at any given time, there is only one package "python" on a system (neither python1.5 nor python2.1 will provide "python"). Gregor
(2nd try) Final draft of Python Policy (hopefully ;-)
I've put a version 0.3.6 of the Python Policy Draft on http://people.debian.org/~flight/python/. The version is still a little bit rough and sometimes incomplete, but it already gives a good outline of the Python packaging system we are installing just now. Please have a look at the document, and post all fundamental problems you have with the content. If nobody find fundamental show-stoppers that render this unusable, we're going to submit it to Debian Policy very soon. Gregor
Final draft of Python Policy (hopefully ;-)
I've put a version 0.3.6 of the Python Policy Draft on http://people.debian.org/~flight/python/. The version is still a little bit rough and sometimes incomplete, but it already gives a good outline of the Python packaging system we are installing just now. Please have a look at the document, and post all fundamental problems you have with the content. If nobody find fundamental show-stoppers that render this unusable, we're going to submit it to Debian Policy very soon. Gregor
Re: What should we do now?
* Anthony Towns [011023 17:22]: > On Tue, Oct 23, 2001 at 02:42:42PM +0200, Gregor Hoffleit wrote: > > Just to make the discussion a little bit more focussed: I think several > > issues were mixed up in my original mail: > > Sounds like a plan. > > > (1) For once, #!/usr/bin/env has it's problems. Scripts that use > > "#!/usr/bin/env python" are more fragile than scripts without. > > > > (2) Another issue is "python" vs. "python1.5". It's a separate question > > whether scripts need to be strictly coupled to a specific Python > > version. > > > > Regarding (1): If you ask me how common the situation is that people > > install local Python versions in /usr/local, then I will ask you how > > common it is that it's reasonable that a script provided by a Debian > > package will benefit from using #!/usr/bin/env ? > > Well, how about you answer the question instead? > > It's reasonable for Debian scripts to use #!/usr/bin/env because any > harm that could be caused is both rare and easily avoidable, and because > that's what many upstream scripts use. AFAICS. Certainly that's not a fair statistic, but if I grep through my /usr/bin, there are 12 scripts using some kind of "#!/usr/bin/env python", but 79 scripts using something like "#!/usr/bin/python" (in /usr/local/bin, the ratio is 2 for /usr/bin/env and 4 for /usr/bin/python). That's consistent with my observations: The common idiom in the Python community is "#!/usr/local/bin/python", /usr/bin/env is only rarely used. That means most Python scripts have to be modified anyway. It's just the question whether we should replace #!/usr/local/bin/python with "#!/usr/bin/env python" or with "#!/usr/bin/python". > (I don't really care if you want to encourage people to not use > /usr/bin/env, though) > > Regarding (2): Making the dependency explicit (by using > > /usr/bin/python1.5) is just playing safe. > > It's not merely playing safe though. It's also creating a strict > dependency that will bite you later (by making transitions to python X.Y++ > require significantly more changes, by having packages break needlessly > when those changes aren't made). > > > As far as I can see, if we hadn't the legacy of the existing packages > > and installations, and if versioned dependencies would work on all > > systems in all situations, we could come up with a quite clean setup: > > python-base et al. could be empty packages (virtual packages wouldn't > > work!), and other packages could depend on them (e.g. "Depends: > > "python-base (>= 2.0), python-gtk" for a package that need at least > > Python 2.0 or better. Still in this case, what could you do if Python > > 2.3 broke that script ?) > > There're two possible solutions, obviously: either you assume in advance > that scripts will work with new versions of python and allow them to be > installed together, or you assume they don't and forbid them from being > installed together. > > I think that's a correct statement: I can't see any other possibilities > being even logically consistent. > > If you assume that scripts will work with new versions of python, > you end up with the result that occassionally your assumption will be > wrong for some scripts, and you'll have some possible partial upgrades > that'll break. This isn't a cardinal sin. > > OTOH, if you assume that scripts *won't* work, you're committing > yourselves and a bunch of other people to going through whole bunches of > Python code checking that it works, and twiddling bits to note that fact. > > The only question is whether the (presumable) handful of bugs every year or > two due to the former is worth the (presumable) whole lot of effort involved > in the latter. > > The easiest way to handle the latter, IMO, is to add a: > > Depends: python-base (<< .) > > to the package, where . is the most recent version of python that > it works with. > > Note that this allows you to use a package on multiple versions of python > (so if woody were to release with python 1.5 and 2.0, your package could > conceivably Depend: python-base (>= 2.0), python-base (<< 2.3), and you > won't have to make further changes when Debian packages for 2.1 or 2.2 come > out), unlike #!pythonX.Y, which is much more restrictive. Just to make sure we have the same thing in mind: At this point, python-base is no virtual package provided by some real pythonX.Y-base package, but it's a real package, right ? This would
Re: What should we do now?
* Anthony Towns [011023 09:07]: > On Tue, Oct 23, 2001 at 01:31:50AM -0400, David M. Cooke wrote: > > At some point, Anthony Towns wrote: > > > Again, _why_ does this matter? Who does this? Is it even remotely common? > > > That people would even consider installing another version of python in > > > /usr/local surely just points to a problem with the Debian packaging, no? > > Well, I do it for one. > > And is there some reason you can't call them /usr/local/python2.1-opt, say? > > Or is there some reason you can't just install all the modules you otherwise > have installed? Just to make the discussion a little bit more focussed: I think several issues were mixed up in my original mail: (1) For once, #!/usr/bin/env has it's problems. Scripts that use "#!/usr/bin/env python" are more fragile than scripts without. (2) Another issue is "python" vs. "python1.5". It's a separate question whether scripts need to be strictly coupled to a specific Python version. Regarding (1): If you ask me how common the situation is that people install local Python versions in /usr/local, then I will ask you how common it is that it's reasonable that a script provided by a Debian package will benefit from using #!/usr/bin/env ? Regarding (2): Making the dependency explicit (by using /usr/bin/python1.5) is just playing safe. As far as I can see, if we hadn't the legacy of the existing packages and installations, and if versioned dependencies would work on all systems in all situations, we could come up with a quite clean setup: python-base et al. could be empty packages (virtual packages wouldn't work!), and other packages could depend on them (e.g. "Depends: "python-base (>= 2.0), python-gtk" for a package that need at least Python 2.0 or better. Still in this case, what could you do if Python 2.3 broke that script ?) But we haven't an ideal situation, so we have to fight with that kind of legacy. But maybe it brings us to the core of the problem: As far as I can tell our principal problem is that there's a large set of existing packages (from slink, potato) that have wrong dependencies (like unversioned "Depends: python-base" for packages that depend on Python 1.5.2) that would be (erronously) satisfied if we just continued to use python-base and so on. One way to resolve this is to include a huge list of conflicts in python-base et al. Another way to resolve this is to drop these package names, perhaps in favour of some other package names. IMHO, in the current, messed up situation, scripts and packages that play safe in explicitely stating a Python version have the big advantage that they will lead to these kinds of problems with underspecified dependencies. It's much the same reasoning why libraries have a number in them that will be increased for incompatible API changes. AFAICS, with the setup you are suggesting you can never warranty that kind of robustness. Gregor
Re: What should we do now?
* Neil Schemenauer <[EMAIL PROTECTED]> [011022 17:47]: > Anthony Towns wrote: > > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote: > > > Say, you would install 2.1.2 in /usr/local. > > > > How about we just say "Don't install other versions of python in > > /usr/local" ? > > Please no. Making this work properly is not hard. Besides, if the > magic is "#!/usr/bin/env python" then we would have to say "don't > install other versions of python in your path". Exactly. IMHO this is a no-go, we should not restrict our users in that way. Furthermore, would there be any reason at all for using "#!/usr/bin/env" in Debian scripts ? I don't see any. Btw, cf. the discussion thread on python-dev that I started by asking that kind of question. The tendency was that in general every Python application is guaranteed to work only on a specific Python version. Mailman 2.0 only runs on Python 1.5.2. Mailman 2.1 runs on Python 2.0. Zope 2.2 runs on Python 1.5.2. Zope 2.4 runs on Python 2.1. Every other combination is just a lucky coincidency (cf. the python-dev archives at http://mail.python.org/pipermail/python-dev/ for the full discussion). I don't see any reason why we should actively work towards enabling a user to override the intended version, with the potential damage of breaking scripts. If the maintainer of a script is really aware of a legitimate reason for doing this, he is welcome to use /usr/bin/env. Gregor
Re: What should we do now?
* Jérôme Marant <[EMAIL PROTECTED]> [011017 08:31]: > Matthias Klose <[EMAIL PROTECTED]> writes: > Quoted from Gregor: > > " > Python package maintainers should then change their packages to build > python1.5-* and python2.1-* packages (python2.0 if needed), and make > them depend on python1.5-base etc. That would remove the need for > versioned dependencies. > " > > What is the exact policy? > > Should all executable scripts begin with #!/usr/bin/env python1.5 (for 1.5) > and #!/usr/bin/env python2.1 (for 2.1)? For the sake of the consistency of the Debian system, I would say that all scripts in Debian packages currently should not use /usr/bin/env, but instead provide the direct path to the executable (i.e. #!/usr/bin/python1.5 etc.). Otherwise, you might break up all the carefully provided package dependencies by installing a new Python version in /usr/local: Say, you would install 2.1.2 in /usr/local. Now if /usr/local/bin would precede /usr/bin in your path, then "#!/usr/bin/env python2.1" would call up 2.1.2. Still, if a script would depend on something like "python2.1-base, python2.1-imaging", it would break in this case, since python2.1-imaging isn't available in this 2.1.2 installation. Therefore, the most reliable way currently is to use #!/usr/bin/pythonX.Y in all Debian-provided scripts. Gregor
Re: Updated experimental packages
* Neil Schemenauer <[EMAIL PROTECTED]> [010907 00:33]: > I see now that the python2 packages made it into unstable. This is a > mistake IMHO. The Perl guys tryed this and it didn't work. Also, the > name should have been python2.1 not python2. What problem does naming > the packages "python2" solve? It seems like a big pain for everyone > for no gain. Note that the python2 packages are, at this time, legacy. They were created at the time where Python 2.0 was incompatible with the GPL, and it was a hack to provide Python 1.5.2, which was GPL compatible, as well as 2.0, which was not. Cf. README.why-python2 for a more detailed explanation. Gregor
Re: Experimental Python packages
* Neil Schemenauer <[EMAIL PROTECTED]> [010906 16:27]: > Gregor Hoffleit wrote: > > Have you looked at my experimental Python packages, at > > http://people.debian.org/~flight/python/snapshot/ ? I haven't yet tried > > your packages, but it sounds like you started from scratch ? > > No, I based them on your python and python2 packages. I've made quite a > few bug fixes to them so you might want to do a diff between them an > your packages. You'll have to ignore all the s/python2/python/ changes. Ok, thanks for the effort! In the experimental packages, the biggest difference is the modified build setup in ./debian/., which should make it much easier to package new upstream versions like 2.2. Gregor
Re: Experimental Python packages
* Neil Schemenauer <[EMAIL PROTECTED]> [010906 16:01]: > Carey Evans wrote: > > I've had a look at these packages myself. Can you tell us what stage > > they're at, i.e. what still needs to be done, what problems you know > > about and what you want to hear about? > > I thought my first message explained that. Mostly the Depends, > Conflicts, Replaces, Provides information. I've made some progress in > this area. I'll try to upload new packages today. Carey is talking about my packages, Neil. He referred to my mail pointing at http://people.debian.org/~flight/python/snapshot. Gregor
Re: Experimental Python packages
* Neil Schemenauer <[EMAIL PROTECTED]> [010906 01:05]: > Before I spend too much time on this, is there a problem with this > approach? It seems to be much simpler than using versioned packages for > everything Python related. I'm especially interested in Gregor's > opinion since he maintains a lot of these packages. Have you looked at my experimental Python packages, at http://people.debian.org/~flight/python/snapshot/ ? I haven't yet tried your packages, but it sounds like you started from scratch ? Gregor
Re: Intent for NMU of python-2.1 packages
* Jérôme Marant <[EMAIL PROTECTED]> [010904 11:18]: > Matthias Klose <[EMAIL PROTECTED]> writes: > > ... > > in June (2.1) and July (2.1.1). Gregor (the python-1.5 and python-2.0 > > maintainer) has put experimental packages at > > http://people.debian.org/~flight/python and was asking for help > > regarding the packaging (20010801). Jérôme Marant answered (20010803), > > but since this date nothing happened. I intend to do a NMU of > > python2.1 based on Gregor's experimental packages that can coexist > ... > > Do you know what happened to Gregor since 20010801? I periodicaly > had a look to his page at debian.org but nothing happened since then. > Did you contact him? Do you have his agreement for the NMU? > What do you plan to do about the idle package? I'm still alive, I'm not lost ;-) I'm just back from a ten day vacation after several weeks of intense real world work, which will continue until the mid of September. I'm +2 on uploading the python2.1 packages into unstable. All I wanted to do was a little bit cosmetic cleanup, and (and that was the stumbling point due to lack of time), some kind of documentation included in the packages. Matthias, have you already done some work on these packages ? Could you forward your modifications to me ? Also, I'm +1 on uploading the python1.5 packages into unstable. That means they would replace the existing python-* packages. And that's the problem where I was stuck. The dependencies of the current experimental python1.5 packages aren't good enough to allow an easy upgrade from potato or earlier. AFAICS, I would have to include empty transitional packages for almost all python-* packages built from the python source. That's butt ugly IMHO. Furthermore, it's my current impression that we have to orphan all python-* packages in order to get a clean upgrade path! There are many packages with broken dependencies in potato (i.e. packages that install stuff in /usr/lib/python1.5, but don't have a versioned dependency on Python 1.5). Therefore, any future python-base package either has to be compatible with stuff in /usr/lib/python1.5, or has to list all those broken packages as conflicts. Either is ugly. Therefore I think we have to get rid of all the problem-ridden package names, i.e. at least python-base and python-tk, perhaps even python-dev. I don't see any other solution. Please provide me with feedback if I should make this radical transition. I would then go on and upload python1.5 and python2.1 (perhaps even a python2.0 source package to ease the migration). The existing python (and python2) packages would be removed by this upload (the packages built from python.orig.tar.gz, that is). Python package maintainers should then change their packages to build python1.5-* and python2.1-* packages (python2.0 if needed), and make them depend on python1.5-base etc. That would remove the need for versioned dependencies. At a later point, we could implement a kind of registry like the emacsen have, so that third-party packages could build only one python-* package, that registers itself with all existing pythons. How does that sound ? Gregor
Python upgrade: need help regarding package renaming
Hi, I'm struggling with a simple case of 'What-APT-Does-Is-Not-What-I-mean' while preparing the dependencies for the Python upgrade: In potato, we had packages python-base and idle (and a variety of other python-* packages). Now these packages will be renamed python1.5-base and idle-python1.5 (and python1.5-* resp.). For some reason, I will provide an empty transitional packages python-base, that depends on python1.5-base (that's necessary since a lot of other potato packages have versioned dependencies on python-base). Now how do I set Depends/Replaces/Conflicts/Provides so that in case of an "apt-get install python-base", (a) if somebody has installed idle and python-base: the idle package will be removed, and the new python-base, python1.5-base and idle-python1.5 packages will be installed. (b) if somebody has installed python-base, but no idle: the new python-base and python1.5-base packages will be installed (but no idle-python1.5). The Packages file at http://people.debian.org/~flight/python/snapshot/Packages.gz contains the first of several trials I made, but to no avail. I also tried to make idle-python1.5 "Replace: idle", and/or to "Provide: idle", but to no avail: apt-get always will remove idle, but not install the new idle-python1.5. I have no idea why. I don't want to make another empty transitional package "idle" if it's not necessary. Certainly providing such an package would resolve that problem, but that's ugly. Gregor
New experimental python1.5 packages
I have uploaded an improved version (1.5.2-17.0.1) of the python1.5 packages to people.debian.org: http://people.debian.org/~flight/python/snapshots/python1.5/ Again, the packages are not intended for public consumption. The major change is the introduction of empty transitional packages python-base, python-tk and python-dev that are necessary to provide an smooth upgrade path from potato. Rationale: There are many Python packages with buggy dependencies in potato. Whenever a package installs stuff in a version dependent directory like /usr/lib/python1.5/site-packages, it must have a dependency on that specific Python version (something like "python-base (>= 1.5), python-base (<= 1.6)" in that case). Most packages in potato, though, only have "python-base (>= 1.5)". Therefore, we have to drop the python-base package for future Python revisions. Gregor
Re: python2.1 et al.
* Radovan Garabik <[EMAIL PROTECTED]> [010726 18:49]: > On Thu, Jul 26, 2001 at 05:24:04PM +0200, Gregor Hoffleit wrote: > > Then, we still have to agree on a strategy how to set up the > > dependencies, in order to make the upgrade work in an intuitive way. > > > > For maintainers of Python extension modules, this would mean that they > > would have to build one package for each included Python version, e.g. > > python1.5-mysqldb, python2.0-mysqldb and python2.1-mysqldb. > > > > Is there a reason for python1.5 existance _other_ then supporting > older application? If not, I'd propose to have packages named > python1.5-foo for python1.5, and python-foo for current > version of python (i.e. 2.1), and for packages that do not care about > python version. You will have to do some work anyway for each new feature release, if you're maintainer of a Python extension package. When I release 2.1.1 packages, you'll have to change your packages in order to somehow make the stuff available under /usr/lib/python2.1/site-packages. According to python-dev, there are *no* serious Python things that do not care about the Python version. > (Personally, I'd HATE to 1) rename my package whose upstream > name is python-utmp, 2) maintain two versions of it. > Ok, I'll probalby have to... ) Another problem would be that every time a new feature version of Python is released (i.e. 2.1, 2.2), *I* have to rename the packages of the current Python version from python to pythonX.Y ;-). More important, the names python-base, python-tk etc. are already used in dependencies of potato packages. There are many Python extension modules in potato that have a dependency like "python-base (>= 1.5)", but install stuff in /usr/lib/python1.5/site-packages. If we ship python-base and python-tk 2.1.1-1 in woody, then a simple "apt-get install python-base python-tk" will render all these packages unusable. Seriously, as I wrote, I don't subscribe to that extreme pessimism that I felt on python-dev. I think we can come up with a solution like the emacsen setup that makes it possible and easy to write a package python-utmp that registers and installs for all installed Python versions. But, I'm afraid, we will have to use something like a registry. There's a discussion on the Distutils SIG as well about a Package DB (which I haven't followed). That sounds like something that might help us, too. But I'm afraid it's way too late to implement this for woody. Instead, for woody I would try to find a setup that's mostly neutral, that should mean it leaves us much room to move. That seems to be the case for the python1.5/python2.1(/python2.2) naming scheme, and that's why I would prefer it. > > There would be no python-* packages in woody!!! > > Why (even considering your proposal above)? If there is a package called > python-foo, which is pure python and works with both 1.5 and 2.1, should > there be 2 packages made of it? (different only in names) But how would a package look that works with 1.5 as well as 2.1 ? Would you install the stuff in /usr/lib/python2.1/site-packages, and use symlinks for all .py files in /usr/lib/python2.1/site-packages ? Or would you duplicate the .py files in both site-packages trees ? New problems arise when I would create (experimental) packages of Python 2.2a1 for developers, so that we have three different versions at the same time. The feedback from python-dev was that it's indeed possible that
Re: python2.1 et al.
Cyrille, I's sure you don't mind quoting your mail in debian-python: * Cyrille Chepelov <[EMAIL PROTECTED]> [010726 21:10]: > Le jeu, jui 26, 2001, à 05:24:04 +0200, Gregor Hoffleit a écrit: > > It's been much too long since I posted the last status report. I'm > > swamped with all kinds of real world work, and wasn't really able to > > keep up in time with the discussion. > > > > Reading the discussion, I thought that in order to consolidate a Python > > policy, it might help to collect the information in a Wiki. I tried to > > setup a ZWiki, and started to fill in a few statements. You can enter > > the ZWiki from this URL: > > > > http://people.debian.org/~flight/python/policy/ > > Too bad there's no DocBook-aware Wiki system... Well, there's no DocBook-aware Wiki yet, but then, ZWiki uses mostly StructuredText. The ZopeBook is written in StructuredText, too (http://sourceforge.net/cvs/?group_id=21038), and they have a script that renders that StructuredText into DocBook (cf. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/zope-book/Book/StructuredText/). At least it should be possible to export the Wiki's pages in DocBook format. OTOH, it's questionable if that would make up a pleasant document to read ;-) > I've added there a pointer to the experiment I made in Bordeaux at the > beginning of the month, which is the result of long talks between me and > Moshe Zadka. I had been waiting for Gregor's first impression on it before > talking about it on the list, I guess this is about the right time. To be honest, I got the idea to set up a Wiki while reading your python-policy-experiments draft. I noticed that there are a few things in that are quite controverse I guess, and a Wiki might be a better place than a mailing list to collect feedback about the single issues. > How are we going to work ? Shall I paste the text of the Bordeaux text into > ZWiki nodes, and re-format them back into DocBook later ? Hmm, if you have a little bit time to spend, then perhaps have a look at the stuff mentioned above. With a little bit work, it might be possible to augment ZWiki with an DocBook export button (or even a PDF rendering FWIW). Then yes, please feel free to put the stuff into the Wiki. I have no idea if the Wiki will work for us, but it's worth a try I guess. Gregor
python2.1 et al.
It's been much too long since I posted the last status report. I'm swamped with all kinds of real world work, and wasn't really able to keep up in time with the discussion. Reading the discussion, I thought that in order to consolidate a Python policy, it might help to collect the information in a Wiki. I tried to setup a ZWiki, and started to fill in a few statements. You can enter the ZWiki from this URL: http://people.debian.org/~flight/python/policy/ Up to now, that Wiki lacks memberships functions, i.e. you can only post anonymously. If somebody gives me a quick tutorial how to add membership functions to a ZWiki site in ten minutes, I'll do that. Until then, please include your name in all comments. If you're not used to Wiki sites, feel free to look at http://dev.zope.org/. They are using wikis for all discussions about Zope development. The ZWiki site, zwiki.org, seems to be down at the moment. Regarding the packaging: I'm working on the 2.1.1 packages. I'm currently changing the build environment in debian/, so that templates are used for most control files. That makes it very easy to package stuff under names as python2.1-base etc., and still, with one change in debian/rules, the packages build as python-base etc. That's an very necessary step to make maintenance of multiple Python versions easier. A snapshot of Python 2.1.1 (python2.1-*) and Python 1.5.2 builds (python1.5-*) using the new system can be previewed in http://people.debian.org/~flight/python/snapshot/ The 2.1.1 packages in fact are already installable; the 1.5.2 packages don't install, since the dependencies are not yet set up in order to make an upgrade from the python 1.5.2 packages. Still, all packages are buggy (2.1.1 fails five regrtests!), and only intended as preview. Since time is now very pressing (yes, I know, that's my fault), I'm afraid we won't be able to make the big jump to a halfway perfect solution for all the discussed problems. >From the discussion, the most pressing problem is how we tackle the upgrade of potato python-* packages, especially when they have incomplete/incorrect dependencies. While I still think it's necessary that we find a solution how a Python extension package can install and register itself for a variety of different Python versions, I haven't seen a solution that's clean and obvious, easy and robust to implement and that's something we won't regret in a few months. My proposal for woody: Python 1.5.2 is renamed to python1.5-*. Python 2.1.1 will be shipped as python2.1-*. Do we need python2.0-* as well ? Then, we still have to agree on a strategy how to set up the dependencies, in order to make the upgrade work in an intuitive way. For maintainers of Python extension modules, this would mean that they would have to build one package for each included Python version, e.g. python1.5-mysqldb, python2.0-mysqldb and python2.1-mysqldb. There would be no python-* packages in woody!!! With that setup, we could use our existing, well-tested system, and still would resolve a few critical problems that we're currently facing due to the ambigous package names python-*. In a later future, I'd like to set up a robust system that makes it possible to provide python-* packages that work for all installed Python versions. Maybe like the emacsen system. Gregor
Re: Status report on python2 transition
rovided by python-x.y-base and > managed by alternatives.) > - This "figuring out" will have to be done by each python-x.y-* > and each modules package on install and remove too. > - Remove this cruft in the postrm. > > (*) Rename this to something better if you like. > > The main disadvantage is that people compiling binary-linked library > modules will need multiple Pythons installed; of course, unless some > magic API fix comes along, they would anyway. > > It also doesn't include any way to accomodate locally-built Pythons, > unless they are built and installed as debs. This may or may not be a > problem (some people may want to track CVS). > > I think this covers all of the important issues though. It may be > needlessly complex, but it does support users having whatever Pythons > they want installed and should allow most things to work. I have a pretty good feeling with this solution. Sounds pretty dumb, but the missing key point in my thoughts was the virtual package "python-X.Y-base" (perhaps python-X.Y is better ?). I just didn't get it, and always thought about ugly solutions involving multiple versioned dependencies. But, as Carey Evans already mentioned, we have to make up a solution for the existing potato packages that have incomplete dependencies (like "python-base (>= 1.5.2-1)") for the case where a user just tries "apt-get install python-base" with woody. If Python 2.1.1 would include a python-base package, these (buggy) potato packages wouldn't get upgraded. OTOH, I don't want to include a long list of conflicts with a python-base 2.1.1 package. Gregor
Re: python 'release21-maint' branch GPL with changed license
On Sat, Jul 07, 2001 at 07:08:51PM +0200, Matthias Klose wrote: > Looking at > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/LICENSE?only_with_tag=release21-maint > you see that the changed license is in the python-2.1 maintanance > branch as well. What about python packages based on this branch? I has > the advantage of a recent version which can go into woody. I guess this answers that question: On Wed, Jul 04, 2001 at 01:31:21PM +0200, Gregor Hoffleit wrote: > First of all the good news: You have managed to talk me into making the > big step, and going right to the 2.1.1 CVS branch. Thomas Wouters > (release czar for Python 2.1.1) assured me that 2.1.1 will be released > before the freeze, and Guido heavily supported that. For more information, read that "Status report on python2 transition" thread. Gregor
lintian: Should check dependencies for python packages
Package: lintian Version: 1.20.13 Severity: normal Lintian should include a check for correct dependencies of Python extension packages. The rule is like follows: Any package that installs stuff in /usr/lib/pythonX.Y/site-packages must have a dependency on: python-base >= X.Y, python-base << X.(Y+1) Thanks, Gregor
Re: Status report on python2 transition
On Thu, Jul 05, 2001 at 05:33:37PM +0200, Gregor Hoffleit wrote: > On Thu, Jul 05, 2001 at 07:56:57AM -0700, Neil Schemenauer wrote: > > > That's our current setup (well-behaved packages should have a dependency > > > on "python-base >= 1.5, python-base << 1.6"). Look at the mess we're now > > > running into, now that we want to upgrade this to Python 2.1.1. All > > > packages have to be recompiled at once. > > > > What's a "well-behaved package"? Extension modules depend on the > > version of Python that they were compiled against. If you upgrade the > > interpreter you must upgrade the extensions. How are you planning on > > avoiding this? I guess I missed your point here. Binary extensions certainly need to be rebuilt once for every Python feature version. Pure Python packages not necessarily would need to be rebuilt (if the code was cross-version compatible). That was the point of my original inquiry on python-dev. Possible solutions for cross-version compatible code would be installation in a version-neutral directory (e.g. /usr/lib/python/site-packages) and either adding this to sys.path (has been depreciated in python-dev) or somehow arranging symlinks into the actual versioned site-package directories. In this case, we would have to setup something comparable to the Debian emacsen's registration system. Gregor
Re: Status report on python2 transition
On Thu, Jul 05, 2001 at 07:56:57AM -0700, Neil Schemenauer wrote: > Gregor Hoffleit wrote: > > Sorry ? What problems do you have installing Python 2.1 in /usr/local on > > a Debian system ? > > Sometimes /usr/local/bin/python is used instead of /usr/bin/python. For > example, dput uses "#!/usr/bin/env python". Also, its postinst script it > does: > > python -c 'from compileall import main;main()' -q $DIR > > which fails if a stock distribution of compileall is used (it doesn't > support -q). I've seen other packages do this as well. Ok, I see. The postinst problem is my fault; the scripts certainly should use an explicit path to a well-known python installation that does support this. I just browsed /usr/bin and /usr/sbin, and indeed there are plenty of scripts that use "#!/usr/bin/env python". If we consider the possibility that somebody installs non-compatible Python versions in the path, then these are bugs in that packages. Thanks for pointing this out! I guess we really, really need a Debian Python policy that mentions all these things. > > That's our current setup (well-behaved packages should have a dependency > > on "python-base >= 1.5, python-base << 1.6"). Look at the mess we're now > > running into, now that we want to upgrade this to Python 2.1.1. All > > packages have to be recompiled at once. > > What's a "well-behaved package"? Extension modules depend on the > version of Python that they were compiled against. If you upgrade the > interpreter you must upgrade the extensions. How are you planning on > avoiding this? Binary extension modules depend on the version of Python that they were compiled against (a different micro version should be ok, AFAIK). Pure Python extension modules not necessarily depend on the version of Python they were packaged for. There's a tricky situation wrt. byte-compilation in postinst, but currently, this shouldn't hurt us (since on upgrading python-base, site-packages is re-byte-compiled by an compileall.py call). s/not well-behaved/buggy/: Any binary Python extension package that doesn't depend on 'python-base >= X.Y, python-base << X.Y+1' is buggy (a few weeks ago I asked in debian-python for volunteers that filed bug reports against those packages; don't know about the current status, though). A pure Python extension package that installs stuff in /usr/lib/pythonX.Y and doesn't have this dependency is also buggy. A pure Python extension package that installs stuff in site-python doesn't need a versioned dependency. Gregor
Re: Status report on python2 transition
On Thu, Jul 05, 2001 at 07:13:54AM -0700, Neil Schemenauer wrote: > Gregor Hoffleit wrote: > > Until now I had the impression that in general it's not necessary to > > have more than one Python version on your machine at the same time > > (except perhaps you're a Python core developer). Feedback from > > python-dev though was that it's definitely necessary to allow and > > support multiple concurrent versions of Python even on production > > machines. > > This doesn't imply that Debian has to support multiple concurrent > versions of Python _packages_. To me, it means Debian should play > nicely if you want to install other versions of Python in /usr/local or > wherever. Currently it does not. Sorry ? What problems do you have installing Python 2.1 in /usr/local on a Debian system ? > > For one, I've changed my mind and accepted that there's a need to > > support multiple concurrent Python versions in Debian. > > Woody should have one core Python package (python-base_2.1.1-X). > Extension modules should have a versioned dependency on the interpreter > (ie. "python (= X.Y)"). Pure Python packages should only have a > dependency on "python" or perhaps "python (>= X.Y)". That's our current setup (well-behaved packages should have a dependency on "python-base >= 1.5, python-base << 1.6"). Look at the mess we're now running into, now that we want to upgrade this to Python 2.1.1. All packages have to be recompiled at once. Gregor
Status report on python2 transition
First of all the good news: You have managed to talk me into making the big step, and going right to the 2.1.1 CVS branch. Thomas Wouters (release czar for Python 2.1.1) assured me that 2.1.1 will be released before the freeze, and Guido heavily supported that. Now for the bad news: I don't have any conclusive plan how to manage transitions for future Python feature releases, like 2.2, 2.3 and so on. Until now I had the impression that in general it's not necessary to have more than one Python version on your machine at the same time (except perhaps you're a Python core developer). Feedback from python-dev though was that it's definitely necessary to allow and support multiple concurrent versions of Python even on production machines. If we're going to support this in Debian regularly, then it get's even much more complicated than with our current setup of python-* and python2-*. Please have a look at the python-dev archives for the full discussions: http://mail.python.org/pipermail/python-dev/2001-July/015715.html The discussion -- - Python has now a reliable, well-behaved version numbering policy: - feature releases: may introduce new features, may change the bytecode format. The minor (middle) version number changes (e.g. 1.5.2 -> 1.6, 2.0 -> 2.1). - micro-versions: bug fixes only, bytecode format can't vary. Only the micro component of the version number changes (e.g. 1.5.1 -> 1.5.2 or 2.0 -> 2.0.1). - site-python is depreciated; Python code should go into a version specific directory (originally I thought I might use site-python for all packages--would make Python updates very much easier): Greg Ward <[EMAIL PROTECTED]>: > Oh yeah, another thing I vaguely recall from the pre-Distutils-0.1 > era: Guido doesn't (didn't?) like site-python and wanted to > deprecate it. ... > BTW, I'm skeptical about keeping .py and .pyc code in a > non-Python-version-specific directory (ie. site-python). Debian's > bytecode-recompilation at installation time scheme sounds cool, but the > desire/need to have multiple Python versions available kind of nixes it. "Fred L. Drake, Jr." <[EMAIL PROTECTED]>: > Another reason not to use site-python is that it is actually still > hard to write cross-version Python code -- there are enough > differences that any substantial volume of code (and in Python, you > don't need many KLoC to get substantial code!) is bound to encounter > a few, especially if you get used to using only Python 2.0+ -- it's > easy to get used to features like string methods, list > comprehensions, and augmented assignment! The site-packages > directory was introduced to avoid the deficiencies of the > site-python directory. Guido van Rossum <[EMAIL PROTECTED]>: > Indeed, /usr/local/lib/python./site-packages/ is > where site packages should go. - Support for multiple concurrent Python versions on the same system is necessary: "Barry A. Warsaw" <[EMAIL PROTECTED]>: > GH> Seriously, does anybody (besides the Python developers) feel a > GH> need to have multiple Python versions on the same system ? > > Yes, definitely as both a Zope and Mailman developer I need > multiple Python versions. But I suspect even normal users of the > system will need multiple versions. Different Python-based apps are > requiring their users to upgrade Python on their own schedule, so > multiple versions will still be required. "Fred L. Drake, Jr." <[EMAIL PROTECTED]>: > Another excellent reason to support multiple versions! As more > widely distributed applications are written using Python and don't > want to include the interpreter, this becomes a more noticable > issue. - If we want to support concurrent Python versions and still don't want to have multiple packages for each Python extension, a setup like the Debian Emacsen system might be a solution: Thomas Wouters <[EMAIL PROTECTED]>: > None are compatible. This might change, but I don't think so -- I > think the CVS tree already has a different bytecode magic than 2.1, > though I haven't checked. Perhaps what Gregor wants is a set of > symlinks in each python version's site-packages directory, to a > system-wide one, and a 'register-python-version' script like the > emacs/xemacs stuff has that adds those symlinks. That way, the > .pyc/.pyo versions would remain in the version-specific directory. Conclusions --- I have no final conclusion what that means for our Debian Python policy. For one, I've changed my mind and accepted that there's a need to support multiple concurrent Python versions in Debia
Re: Python 2.0.1; transition plans for woody
On Mon, Jun 25, 2001 at 05:42:30PM +0200, Radovan Garabik wrote: > On Mon, Jun 25, 2001 at 05:21:39PM +0200, Gregor Hoffleit wrote: > > > > With the default setup, stuff in /usr/lib/python1.5/site-packages would be > > ignored by 2.0.1. In order to make the transition easier, we might decide > > to append /usr/lib/python1.5/site-packages to the sys.path, though: > > > > Almost all pure Python modules that are currently installed in the > > python1.5 directory will work with 2.0.1; Python 2.0.1 is almost completely > > backwards compatible, and one might consider all remaining problems bugs in > > the potato packages. > > > > Binary modules in /usr/lib/python1.5/site-packages won't work. > > > > well, some time ago I symlinked some modules from python1.5 to python2.0 > (binary ones) and surprisingly they worked (python just printed warning > message about incompatible API) That's interesting, I never tried that. Indeed, it seems to work. I'm not yet clear whether this is a good or a bad thing. Gregor
Re: Python 2.0.1; transition plans for woody
On Mon, Jun 25, 2001 at 05:37:36PM +0200, Radovan Garabik wrote: > I agree, but... why not wait until python 2.1.1 is released? > (or, if we just discuss things a bit, it will be > released before any action is taken and we can jump right > to it :-)) > > You still need to modify packages when going from > 2.0.1 to 2.1.1 I'm afraid that if we wait for 2.1.1, it will be to late to make the complete transition for woody. You're right, though, that with the current setup of the packages, 2.1.1 again will make a small transition necessary. We have to discuss the policy of dependencies and paths for the Python packages at some point. Gregor
Re: Python 2.0.1; transition plans for woody
On Tue, Jun 26, 2001 at 12:47:28AM +1000, Anthony Towns wrote: > On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote: > > This would mean that I upload new versions of the Python packages: > > (1) python2 (python2-base etc.) would be removed > > (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16 > > (3) A new set of legacy packages python15 (python152 ???) for those who > > think that they depend on the old version 1.5.2. > > The transition would not be simple, though. > > How does this affect upgrades? > > Will potato packages that depend on python work with python 2.0.1 packages > in general? What about ones that put stuff in /usr/lib/python1.5? If not, > what will you do to ensure partial upgrades work correctly? If so, that may > give us an easy out for transitioning the python2 packages. We have an option here: With the default setup, stuff in /usr/lib/python1.5/site-packages would be ignored by 2.0.1. In order to make the transition easier, we might decide to append /usr/lib/python1.5/site-packages to the sys.path, though: Almost all pure Python modules that are currently installed in the python1.5 directory will work with 2.0.1; Python 2.0.1 is almost completely backwards compatible, and one might consider all remaining problems bugs in the potato packages. Binary modules in /usr/lib/python1.5/site-packages won't work. > > Nearly all Python packages (to be exact: those who install things in > > /usr/lib/python1.5, those who build binary extension modules, and those who > > link with libpython1.5) would have to be modified and rebuilt. Those > > packages that provide both python2-* and python-* versions would have to be > > modified to instead build python-* and python15-* versions; the dependencies > > of those packages would need closer inspection. > > There are only a dozen or so packages in unstable/i386 that have versioned > depends on python2 related stuff; anything else should be able to be > handled with provides:. IMHO that's the most pressing problem, and has to be inspected carefully: Packages that have unversioned depends on python or python-base, but do in fact depend on Python 1.5.2. They would break after an upgrade to > > What do you think ? > > If you can make upgrades work; if you can not break too many > people's testing or unstable systems; and if you can get everything > rewritten/rebuilt relatively quickly, I'd say it's worth doing. A first try at an transition plan: (1) I upload python 2.0.1-1. python-base 2.0.1-1 provides 'python', 'python2' and 'python2-base'. /usr/lib/python1.5/site-packages will be appended to the sys.path. A bug will be filed against the archive to remove the python2 package. Most 'python-*' packages will continue to work in this setup. python2-* packages should continue to work as well. python-* Packages with binary extension modules will break. (2) python-* packages that broke should be rebuilt against the Python 2.0.1 package as fast as possible. Aggressive NMUs should be allowed here after a few days. (3) Bugs should be filed against all remaining packages that install stuff in /usr/lib/python1.5. They should be rebuilt against Python 2.0.1. Finally, no woody package should install stuff in /usr/lib/python1.5. I'm pretty sure that I miss some crucial points with this plan, though. Please correct me where due. My impression is that during a transition period, unstable's Python packages will be quite unstable. Still, rebuilding the packages should be a very simple thing in most cases, so the only crucial thing is that either maintainer act quickly, or we're going on NMU aggressively. One remaining problem is how to handle partial upgrades of a potato system: To handle this well, python-base 2.0.1-1 would have to include a list of conflicts against all potato packages that won't work with the new python packages (I guess in the end that's about a dozen packages). Gregor
Python 2.0.1; transition plans for woody
Hi, Python 2.0.1 is out, finally with a GPL compatible license. Zope 2.3.3 works fine with Python 2.0; I'm not aware of any problems with Debian packages wrt. Python 2.x. That nullifies all reasons for the existance of dual Python packages in Debian (cf. /usr/share/doc/python2/README.why-python2) IMHO this is the point where we should make a big step, and enforce a quick transition of the archive to Python 2.0.1. This would mean that I upload new versions of the Python packages: (1) python2 (python2-base etc.) would be removed (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16 (3) A new set of legacy packages python15 (python152 ???) for those who think that they depend on the old version 1.5.2. The transition would not be simple, though. Nearly all Python packages (to be exact: those who install things in /usr/lib/python1.5, those who build binary extension modules, and those who link with libpython1.5) would have to be modified and rebuilt. Those packages that provide both python2-* and python-* versions would have to be modified to instead build python-* and python15-* versions; the dependencies of those packages would need closer inspection. Still I think it is much preferable to make this transition before the release of woody; when we release woody with python2-* packages this will be a big unnecessary burden for the next release; when we make the migration now, only people who are using unstable might be hurt during the transition process. What do you think ? Gregor
Re: python-2.1 for unstable?
On Sun, Jun 03, 2001 at 07:06:09PM +0200, Florian Weimer wrote: > Gregor Hoffleit <[EMAIL PROTECTED]> writes: > >>> This is probably correct, but it is completely irrelevant in our case. >>> Some parts of Python 2.1 are still covered by the GPL-incompatible >>> CNRI license, so Python 2.1 as a whole is not GPL compatible. >> >> I'm glad to correct you, but according to Guido and Eben, that's not the >> case. The only remaining problem with the CNRI license was the >> choice-of-law clause. Apparently Eben said to Guido that for GPL >> compatibility only the choice-of-law in the topmost license on the stack >> matters, and that's the PSF license. I'm no lawyer, so don't ask me why. > > This means that you can incorporate GPLed code whose copyright is > owned by the FSF into Python, but other copyright owners might still > ask you not to do this. This reminds me of the ipfilter license blowup (cf. http://lwn.net/2001/0524/#ipfilter), where the ipfilter author appearently claimed that a standard BSD license doesn't permit modification of the code. Certainly it's not unthinkable that people use the GPL for their own code, but don't agree with the FSF that this new Python license is compatible with the GPL. I would tend to think, though, that the vast majority of authors of GPL code will agree with the interpretation of Moglen and RMS. Therefore I can't see your point here. Gregor
Experimental Python 2.1 packages, release plans
I have uploaded experimental Python 2.1 packages. Grab them at http://people.debian.org/~flight/python2/ The packages are completely untested. I had to re-implement the building of the shared library (just finished), the remainder of the packages is mostly unchanged. In a few hours, I will leave to Illinois for two weeks. Thomas Wouters currently is preparing the Python 2.1.1 maintenance release, which will be the first GPL compliant release of Python 2.x (provided nothing desastrous happens). At the same time, Moshe Zadka is working on a 2.0.1 release, which will also be GPL compatible. Quoting Thomas: "Another couple of weeks at least, before a release candidate. It also depends on Moshe; if he actually releases 2.0.1 anytime soon, I'll hold off on 2.1.1 a bit longer." A few days ago, I quoted from ajt's release schedule. Now if either Python 2.0.1 or 2.1.1 would be out before July 1, I would like to try and make a hard migration: Python 1.5.2 would be re-packaged as python1.5, and the then-GPL-compliant would be packaged under the name python. As a consequence, nearly all Python packages would have to be re-packaged. The goal should be to provide a smooth migration from potato to woody. This would involve a quite work-intensive period for the maintainers, but IMHO for the user it would be the best solution. I wouldn't like to start this migration, though, before Python 2.x is really GPL compliant. I don't like to release python-* packages with woody which are encumbered by license problems. I.e. I don't want to release woody with 2.0 or 2.1 as python-*, and I would prefer to release woody with python 2.0.1 and python1.5 1.5.2 over releasing woody with python2 2.1 and python 1.5.2. Now the problems start if neither 2.0.1 nor 2.1.1 would be ready in time. If it's obious early that the won't be ready in time, we could start to migrate the python2 packages to Python 2.1. Anyway, while I'm away, perhaps someone could start to audit the packages that depend on Python, and file bugs for all packages that don't have a correct, explicit versioned dependency on python-base like Depends: python-base (>= 1.5), python-base (<< 1.6) or Depends: python2-base (>= 2.0), python2-base (<< 2.1) Gregor
Python 2.0.1 release schedule ?
Hi Moshe, I'm trying to lay out a schedule for the Debian Python packages in woody. My plan would also depend on the release date of Python 2.0.1. Thomas Wouters wrote: "Another couple of weeks at least, before a release candidate. It also depends on Moshe; if he actually releases 2.0.1 anytime soon, I'll hold off on 2.1.1 a bit longer." Do you think 2.0.1 might be out before July 1 ? IMHO this is the last date at which we could start a migration of the python2-* packages to the name python-* (the python-* 1.5.2 packages would be renamed python1.5-*, just for completeness). Gregor
Re: python-2.1 for unstable?
On Thu, May 24, 2001 at 01:02:29PM +0200, Florian Weimer wrote: > Gregor Hoffleit <[EMAIL PROTECTED]> writes: > > > I talked to RMS, Eben Moglen and GvR. The bad news: According to RMS+Moglen, > > the license used in Python 2.1 still is not yet compatible with the GPL. The > > good news: The PSF decided to drop the choice of law clause. A modified > > license is in CVS, and, according to Guido, will be used for the maintenance > > releases 2.0.1 and 2.1.1. The bright news: Moglen himself told me that the > > license text in CVS is compatible with the GPL. > > This is probably correct, but it is completely irrelevant in our case. > Some parts of Python 2.1 are still covered by the GPL-incompatible > CNRI license, so Python 2.1 as a whole is not GPL compatible. I'm glad to correct you, but according to Guido and Eben, that's not the case. The only remaining problem with the CNRI license was the choice-of-law clause. Apparently Eben said to Guido that for GPL compatibility only the choice-of-law in the topmost license on the stack matters, and that's the PSF license. I'm no lawyer, so don't ask me why. I have sent the file python/dist/src/LICENSE from CVS to Eben Moglen (which contains the complete stack of licenses), and he replied: "Yes, you can say that I have advised you that if this is the license for Python 2.1.1 it would be a GPL-compatible release." Eben Moglen is the legal advisor of the FSF, so I think we could take his word for granted: If Python 2.1.1 will be released under the license currently in CVS, then it will be compatible with the GPL, according to the judgement of the FSF. Gregor
Re: python-2.1 for unstable?
Sorry guys for the silence. I had to go through upgrading my hardware, upgrading my line setup to a new provider with a flat fee, and finally, some real world work kept me busy. On Mon, May 21, 2001 at 10:35:15PM +0200, Tom Cato Amundsen wrote: > On 21 May 2001 20:57:34 +0200, Matthias Klose wrote: > > > I really would like to see 2.1 in the next Debian release. I'd like to > > ask Gregor (the maintainer) for an upload schedule, so that other > > maintainers can rely on this to get their packages ready for the next > > release as well. Are there still license issues which will be resolved > > in upcoming releases? Should we skip 2.1 and hope that 2.2 gets > > I don't think 2.1 is much better than 2.0 when it comes to GPL > compatibility. But the roumurs say that there will be a 2.1.1 release that > is fixes this and a few other bugs. I think the new (2.1.1) license was > blessed by rms... Sorry, I don't remember where I read this. Here's a quick update: I talked to RMS, Eben Moglen and GvR. The bad news: According to RMS+Moglen, the license used in Python 2.1 still is not yet compatible with the GPL. The good news: The PSF decided to drop the choice of law clause. A modified license is in CVS, and, according to Guido, will be used for the maintenance releases 2.0.1 and 2.1.1. The bright news: Moglen himself told me that the license text in CVS is compatible with the GPL. Guido asked for our release plan. He'd like to inform the release managers of 2.0.1 and 2.1.1, and seemed to be quite interested to make sure that the next release of Debian will contain a fixed version: On Tue, May 08, 2001 at 04:32:13PM +0200, Gregor Hoffleit wrote: > On Tue, May 08, 2001 at 09:48:38AM -0500, Guido van Rossum wrote: > > That would be great! When should 2.1.1 be out in order for it to be > > the default version? If I have a specific date I can put some > > pressure on the folks responsible for assembling the release! > > The earlier, the better, is all I can say ;-) > > > According to our release manager, Anthony Towns <[EMAIL PROTECTED]>, the > critical dates for the next release or like this: > > > * Policy goes into debugging mode on 1st June, and no further > > changes may be made after about 20th June. > > > > * Base packages must have all release-critical bugs fixed by > > 1st July, and no further changes may be made after about 20th Jul$> > > > * Boot-floppies, standard packages, task packages, and packages > > included in tasks or in boot-floppies need all their > > release-critical bugs fixed by 1st August, and no further > > release-critical bugs fixed by 1st August, and no further > > changes may be made to them after about 20th August. > > > > * The remaining packages (optional, extra) need their > > release-critical bugs fixed by 1st September, and no further > > changes may be made to them after about 20th September. > > > > * We release early to mid October. > > > > Again this is still fairly optimistic, and not necessarily going to > > happen. (Hi Slashdot.) > > > Looks like plenty of time, but due to the big tree of dependencies, the > timeframes are still quite tight. > > python is now a 'standard' package in Debian. Therefore I should not make > any critical changes on the default Python packages after August 1. > Currently, the 'default' Python packages are built from Python 1.5.2. A > problem is that it would take some time of preparation after the release of > Python 2.1.1 to change the default Python to 2.1.1 (coordinating uploads of > packages with new dependencies, testing of the dependencies, etc. pp.). > > > Given that the above dates all hold true: If Python 2.1.1 is out by July 1, > it should be possible to include it as default Python version in the next > release. (And, it would be ready in time for the European Python Meeting in > Bordeaux ;-). > > If it's out by mid-September, it still could be included, but only as second > choice. Python 1.5.2 would then be default. > > > Still, I would very much appreciate if it was released earlier, since that > would allow for a much smoother transition and for a better testing.
Re: usr/share/apps/konsole/python*.desktop
On Thu, Apr 26, 2001 at 03:21:32PM -0600, Bruce Sass wrote: > Here are a couple of files I've found useful and would like to see > included in the python*-base packages... Hi Bruce, would you mind to file an "wishlist" bug report for this ? Just to make sure that I won't forget it. Gregor
Re: Python 2.1 out
On Thu, Apr 19, 2001 at 10:04:24AM +0200, Florian Weimer wrote: > D-Man <[EMAIL PROTECTED]> writes: > > > On Wed, Apr 18, 2001 at 10:25:52PM +0200, Florian Weimer wrote: > > | Steve Purcell <[EMAIL PROTECTED]> writes: > > | > > | > Licenses aside, there are the same technical issues with Python 2.1 > > | > as with Python 2.0. > > | > > | Python 2.1 seems to print some diagnostic messages during run-time; > > | this might affect scripts which are invoked in cron jobs. > > > > Are you sure they aren't warnings regarding code that will not work as > > expected in future versions? > > Yes, I think so. But that doesn't make them less annoying. ;-) Could you mail an example of such a message ? Gregor
Re: Python 2.1 out
On Wed, Apr 18, 2001 at 08:26:00AM -0700, Sean 'Shaleh' Perry wrote: > > On 18-Apr-2001 Gregor Hoffleit wrote: > > On Tue, Apr 17, 2001 at 03:33:45PM +0200, Vasko Miroslav wrote: > >> as Python 2.1 is out, there is no need to keep Python2 and Python152 > >> in Debian, I think. > >> > >> it looks like 2.1 has GPL-compatible license (it has, in fact, three > >> licenses) > > > > Thanks for pointing out the changes in LICENSE. Since there wasn't any big > > noise lately, I thought they had postponed any actions after 2.1. > > > > last I checked it only helped derivatives of python, not python itself. Pardon me, but then couldn't we just release a derivative of Python, e.g. "Dython", change a few things, so that it is a true derivative, and then this might be compatible with the GPL ? I don't understand this... The LICENSE file in 2.1 seems to imply that the license issues with the FSF could be settled, but I'm currently trying to get a word from RMS on this. Gregor
Re: Python 2.1 out
On Tue, Apr 17, 2001 at 03:33:45PM +0200, Vasko Miroslav wrote: > as Python 2.1 is out, there is no need to keep Python2 and Python152 > in Debian, I think. > > it looks like 2.1 has GPL-compatible license (it has, in fact, three > licenses) Thanks for pointing out the changes in LICENSE. Since there wasn't any big noise lately, I thought they had postponed any actions after 2.1. Short analysys: While Python 2.0 was based on the Python 1.6 codebase (which had a license that was incompatible with the GPL according to the FSF), Python 2.1 is now based on Python 1.6.1, which has a modified license. According to RMS the 1.6.1 license allows derived works which are compatible with the GPL. I'm not completely sure, though, if the license of this derived work (Python 2.1) already is accepted by the FSF as compatible with the GPL. The interesting part seems to be paragraph (7) of the new PSF license. I'll send a mail to RMS and ask for his comment. Gregor > and code-breakage features like nested scopes are disabled by default. > > am I right? > what do you think?
Somebody interested in packaging Jython ?
Hi, the BTS still holds my ITP to package JPython (nowadays called Jython). Jython is an implementation of the Python language in pure Java, see http://www.jython.org/. As much as I'm interested in the issues involved with a painless coexistence of C-Python and Jython on Debian, I haven't really had time, though, to track the state of Java on Debian, and therefore I'm lacking many clues on how to package Jython for Debian in the best way. Perhaps there's an volunteer somewhere who'd like to give Jython a look and start packaging it. I think since we still have no Python policy, the final packaging should be coordinated with the C-Python packages, so that we can re-use as much of the Python library as possible (I don't like to have jython variants of pure Python packages, adding to the python- and python2- variants we're already forced to have). Gregor
Re: RFC: python-base, debconf and py/pyc files
On Sat, Mar 24, 2001 at 08:25:57AM +0200, Moshe Zadka wrote: > On Fri, 23 Mar 2001, Gregor Hoffleit <[EMAIL PROTECTED]> wrote: > > > currently, our Python packages mostly ship .py files and compile them into > > ..pyc files at run time in order to save space in the debs. > > > > There's no reason, though, to keep the .py files on machines that only > > deploy software[1] > > Yes there is --- tracebacks look awful without .py's. > Fact is, loading of only .pyc's isn't officially supported by Python. > (the official Guido position is "Python is an open-source language. I'm > not going to waste my time *helping you* not distribute source") Ok, that argument bought me. I still see some cases where removing .py files is reasonable (if space is very tight), but with these things in mind, it's certainly nothing which should be encouraged by the packages. > I do think we need somewhere where all the .pyc's are "registered", so when > a new version of Python comes along, it can recompile them, since pycs > are not compatible across versions. That's an interesting point. The obvious solution would be to add strict dependencies (something like "Depends: python2-base (>= 2.0), python-base (< 2.1)"). This way, a new version of a package had to be installed if a new upstream version of python2-base was installed, and subsequently the .pyc/.pyo would get rebuilt for this package. I realize only now that this is a major issue when installing two versions of Python in parallel. Gregor
RFC: python-base, debconf and py/pyc files
Hi, currently, our Python packages mostly ship .py files and compile them into .pyc files at run time in order to save space in the debs. There's no reason, though, to keep the .py files on machines that only deploy software[1] I wonder if I should debconf-ify python-base and add an debconf option that sets a system-wide policy about how to deal with .py/.pyc files. That could be one of: * install both .py and .pyc files * install only .pyc files * install only .py files The postinst scripts of the various python packages would then enforce this policy according to the global debconf option. Packages could also provide private debconf options to override this. Any comments ? Gregor [1] The iPAC Python packages contain a completely stripped-down version of the Python packages.
Re: 4Suite in Debian ?
On Wed, Feb 28, 2001 at 09:00:38AM -0800, Sean 'Shaleh' Perry wrote: > > On 28-Feb-2001 Jérôme Marant wrote: > > > > Hi, > > > > Would you think great to have 4Suite (http://www.4suite.org) in Debian ? > > As 4DOM was included in Python-xml, we could simply remove it from 4Suite > > add a dependency instead. > > > > I looked into packaging it for narval. However, the version of xml it wants > versus what is in Debian were conflicting at the time. I no longer have the > time to work on this, so feel free. Yep, please go ahead. I remember that some time ago somebody else volunteered, but appearently, it didn't get off. Gregor PS: How about the various XML tools by Lars Marius Garshol (http://www.garshol.priv.no/download/), e.g. xmlproc, pysp, XSA etc. ? And the stuff by Geir O. Grønmo (http://www.infotek.no/~grove/), xmarch, tmproc and GPS ? I'm not enough into XML to evaluate if they could have a broader audience, but they looked interesting to me. Or are they somehow superceded by the recent PyXML releases ?
Removal of python-zlib package
I'd like to warn you that I'm going to merge the contents of python-zlib into python-base. python-zlib is very small, and since zlib1g is now 'standard' anyway, it won't introduce a significant penalty to the python-base package. I noticed that task-python-dev, task-python-bundle and routeplanner have unversioned dependencies on python-zlib, and that palm-doctoolkit has a versioned dependency on python-zlib (>= 1.5.2-4). The new python-base (>= 1.5.2-13) will provide python-zlib. I guess it's your decision if and how you modify the dependencies on that packages (e.g. remove python-zlib and depend on python-base (>= 1.5.2-13)). Thanks, Gregor
Re: [Python-Dev] Re: Python 2.0 in Debian
On Fri, Feb 16, 2001 at 04:24:03PM +0100, M.-A. Lemburg wrote: > Gregor Hoffleit wrote: > > Is there any reason for you to include this choice of law clause anyway, if > > you don't live in Virginia ? > > I have to make the governing law the German law since that is where > my company is located. The text from my version is: > > """ > This License Agreement shall be governed by and interpreted in all > respects by the law of Germany, excluding conflict of law > provisions. It shall not be governed by the United Nations Convention > on Contracts for International Sale of Goods. > """ Well, I guess that beyond my legal scope (why is it reasonable to exclude that UN Convention ?), and certainly it gets quite off-topic on this list. Is it really necessary to make a choice of law, and how does it help you? (I mean, the GPL, the X11 license, BSD-like licenses, the Apache license and the old Python license all work without such a clause). AFAIK, RMS and his lawyer say that any restriction on the choice of law is incompatible with the GPL, therefore I don't see how you could include such a clause in the license and still make it compatible with the GPL. If you're interested in some opinions from Debian, would you mind to send a mail to debian-legal@lists.debian.org and ask there for comments ? Have you considered mailing to [EMAIL PROTECTED] and ask them for their opinion ? > > Does anyone know of the wording of the new 1.6.1 license ? I didn't even knew there will be a 1.6.1 release. Will there be a change in the license ? Gregor
Re: Python 2.0 in Debian
On Fri, Feb 16, 2001 at 03:34:07PM +0100, M.-A. Lemburg wrote:
> Here's the "problem" I have: I want to put my code under a license
> similar to the Python 2 license (that is including the choice of
> law clause which caused all this trouble).
Why don't you simply remove the first sentence of this clause ("This License
Agreement shall be governed by and interpreted in all respects by the law of
the State of Virginia, excluding conflict of law provisions.") ?
Is there any reason for you to include this choice of law clause anyway, if
you don't live in Virginia ?
Gregor
> Since some of my code is already being used by GPL-software
> out there,I would like to add some kind of extra-clause to
> the license which permits the GPL-code authors to the new versions
> as well.
>
> This is somewhat similar to the problem that Python2 has with the GPL;
> don't know how CNRI is going to change the license for 1.6.1, but I
> want to include something similar in my license.
Re: Python 2.0 in Debian (was: Re: [Python-Dev] PEPS, version control, release intervals)
On Fri, Feb 16, 2001 at 01:51:14PM +0100, M.-A. Lemburg wrote: > Gregor Hoffleit wrote: > > > > If somebody could give me a legal advice that the Python license is in fact > > compatible with the GPL, and if this was accepted by the guys at > > debian-legal@lists.debian.org, I would happily adopt this opinion and that > > would make (b) go away as well. > > > > Until this happens, I think the best way for Debian to handle this situation > > (clearly not perfect!) is to use a per-case judgement--if there's GPL code > > in a package, ask the author if it's okay to use it with Python2 code. If he > > says alright, go on with packaging. > > Say, what kind of clause is needed in licenses to make them explicitly > GPL-compatible without harming the license conditions in all other > cases where the GPL is not involved ? Hmm, during the great KDE confusion (KDE was GPL, and Qt was not compatible with the GPL), it was suggested that the authors of the KDE code should add this clause to their license boiler plate (cf. http://www.debian.org/News/1998/19981008): `This program is distributed under the GNU GPL v2, with the additional permission that it may be linked against Troll Tech's Qt library, and distributed, without the GPL applying to Qt'' (By the way, even the FSF uses a similar clause in the glibc license. The glibc license is the usual pointer to the GPL plus this clause: "As a special exception, if you link this library with files compiled with a GNU compiler to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License.") If you add something similar to your GPL code, that should work for the Python license, too. Evidently (cf. the URL above for an elaboration), the problem is that only the copyright holder of the code can add this clause. Your code with be perfectly compatible with pure GPL code, and it would be compatible with Python2 code. It would not be possible, though, to mix in some other pure GPL code, and link that with Python2 code--since the pure GPL code's license doesn't permit that. Silly, not ?? ;-) Gregor
Python 2.0 in Debian (was: Re: [Python-Dev] PEPS, version control, release intervals)
On Mon, Feb 05, 2001 at 04:45:57PM -0500, Andrew Kuchling wrote: > A more critical issue might be why people haven't adopted 2.0 yet; > there seems little reason is there to continue using 1.5.2, yet I > still see questions on the XML-SIG, for example, from people who > haven't upgraded. Is it that Zope doesn't support it? Or that Red > Hat and Debian don't include it? This needs fixing, or else we'll > wind up with a community scattered among lots of different versions. Sorry, I only got aware of this discussion when I read the recent python-dev summary. Here's the official word from Debian about this: Debian's unstable tree currently includes both Python 1.5.2 as well as 2.0. Python 1.5.2 things are packaged as python-foo-bar, while Python 2.0 is available as python2-foo-bar. It's possible to install either 1.5.2 or 2.0 or both of them. I have described the reasons for this dual packaging in /usr/share/doc/python2/README.why-python2 (included below): it's mainly about (a) backwards compatibility and (b) the license issue (the questionable GPL compatibility of the new license). The current setup shows a preference for the Python 1.5.2 packages: python1.5.2 is linked to /usr/bin/python, while python2.0 is linked to /usr/bin/python2; a simple upgrade won't install Python 2.0, but will stick with Python 1.5.2. Furthermore, python-base is now a "standard" package in Debian woody (will be installed by default on most systems!), while python2-base is only "optional". I made this setup to enforce maintainers of other packages to check if their package was compatible with Python 2.0, and--important as well--if they thought that the license of their package was compatible with the new Python license. (a) is clearly only a temporary issue (with Zope being a big point currently) and will go away over the time. (b) is much more difficult, and won't simply vanish over time. I know that most of you guys are fed up with license discussions. Still, I dare to bring this back to your attentions: Most people seem to ignore the fact that the FSF considers the new Python license incompatible with the GPL--the FSF might be wrong in fact, but I think it's not a fair way of dealing with licenses to simply *ignore* their words. If somebody could give me a legal advice that the Python license is in fact compatible with the GPL, and if this was accepted by the guys at debian-legal@lists.debian.org, I would happily adopt this opinion and that would make (b) go away as well. Until this happens, I think the best way for Debian to handle this situation (clearly not perfect!) is to use a per-case judgement--if there's GPL code in a package, ask the author if it's okay to use it with Python2 code. If he says alright, go on with packaging. If he says nogo (as the FSF did for readline), do away with the package (therefore python2-base doesn't include readline support). Gregor README.why-python2: -- Why python2 ? - Why are the Debian packages of Python 2.x called python2-base etc. instead of simply replacing the old python-base packages of version 1.5.2 ? Debian provides two sets of Python packages: - python-base etc. provides Python 1.5.2 - python2-base etc. provides Python 2.x. There are two major reasons for this: 1.) The transition from Python 1.5.2 to 2.0 is not completely flawless. There are a few incompatible changes in 2.0 that tend to break applications. E.g. Zope 2.2.5 is not yet prepared to work with Python 2.0. By providing both packages for Python 1.5.2 (python-*) and Python 2.0 (python2-*), the transition is much easier. 2.) The license of Python 2.0 has been changed, and restricted in some ways. According to the FSF, the license of Python 2.x is incompatible with the conditions of the General Public License (GPL). According to the FSF, the license of Python 2.x doesn't grant the licensee enough freedoms to use such code in a derived work together with code licensed under the GPL--this would result in a violation of the GPL. Other parties deny that this is indeed a violation of the GPL. Debian uses a significant portion of GPL code for which the FSF owns the copyright. In order to avoid legal conflicts over this, the python2-* packages are set up in a way that no GPL code will be used by default. It's the duty of maintainers of other packages to check if their license if compatible with the Python 2.x license, and then to repackage it accordingly (cf. python2/README.maintainers for hints). Jan 11, 2001 Gregor Hoffleit <[EMAIL PROTECTED]> Last modified: 2000-01-11
Re: Bug#82088: Request build against tcl/tk8.3
Hi Mike, On Sat, Jan 13, 2001 at 01:44:36PM -0800, Mike Markley wrote: > You may want to hold off on that for a few days while I work out the strange > bug that's preventing tcl8.3 from building only on m68k. That bug is the > principal reason that tcl8.3 and tk8.3 aren't yet in testing, but Roman has > promised an account on kullervo to try to figure it out. are you making any progress on this thing ? I should upload a new revision of the Python packages, and I'm wondering what to do about this. Gregor
Re: Bug#82088: Request build against tcl/tk8.3
On Sat, Jan 13, 2001 at 04:41:09AM -0600, Gordon Sadler wrote: > Package: python2-tk > Version: N/A; reported 2001-01-13 > Severity: normal > > I haven't installed these from unstable yet. But I have had python1.52 > and python2 from p.d.o/~flight, both downloaded as source and rebuilt > locally with tcl/tk8.3. > > Now that python2 is coming into unstable, is there any reason we can't > finally update to tcl/tk8.3? It doesn't take much work, change the > Setup file to point to correct lib dir, _tkinter.c, and tkappinit.c . > > Would be very appreciated, it's annoying to keep multiple versions of > libraries around without good cause. I'm all open for this, but I don't know what is best. Python 1.5.2 currently is built with Tcl/Tk8.0, since back in June I was told by both Fredrik Lundh (Tkinter) as well as our Tk maintainer David Engel, that using 8.0 would be the safest bet. Now I just saw that, starting with Python 1.6, Misc/NEWS says that we're now prepared for Tcl/Tk 8.2 and 8.3; I hadn't noticed that before. What makes me a little bit unsure is that Tcl/Tk8.3 isn't yet in testing, but only in unstable. This means that python2 will sit in unstable until tk8.3 moves to testing. Also, the vast majority of packages using Tk in sid still depend on tk8.0 (60 packages), compared to tk8.2 (19 packages) and tk8.3 (18 packages). Anyway, I guess I'll build the next package revision with Tcl/Tk8.3. I'm also working on backporting Tkinter from Python 1.6a2 to the python-tk package in order to make the transition complete (and in order to resolve me from the task of installing/deinstalling the correct tk8.x-dev packages each time I'm building python or python2 ;-). Or does somebody think it's worthwhile to provide python2-tk8.x packages ? Since the tk8.0-dev and tk8.3-dev still seem to conflict, the building of the packages would be the biggest problem. Gregor
Preliminary python2 packages for Debian woody
Hi, I completed a set of preliminary packages of python2 for Debian woody. A big warning: They are nearly completely untested, and they aren't yet suitable for release. Please provide me with feedback so that the final packages will be more stable. Your friendly apt line for the python2 packages: deb http://people.debian.org/~flight/python2 ./ Noteworthy things: - The packages are called python2-base, python2-dev etc.pp. - They won't replace the existing python packages (Python 1.5.2), they can be installed alongside each other. - The new packages won't satisfy any dependencies of existing packages that depend on Python. This is intentional. (I beg the maintainers of those packages to make that the license is compatible with the new Python license, i.e. no GPL code is used, or they have the explicit permission of the author of the GPL code). - Readline support, python-gdbm and python-mpz have been removed, since they involve GPL code owned by the FSF. - The SSL module will be packaged separately, since it has to go into non-US. Please report any problems or suggestions to me. Gregor -- Gregor HoffleitMedia Supervision Software Consulting GmbH [EMAIL PROTECTED] Georg-Friedrich-Händel-Str. 13 www.mediasupervision.de 69214 Eppelheim / HD www.fitforweb.de +49 (0) 6221-769723 Fax: -769705
Re: Any dpkg-python document?
Sorry, no. I didn't work on the documentation. Gregor On Tue, Sep 05, 2000 at 09:40:19AM +0200, Matthias Klose wrote: > Milan Zamazal writes: > > >>>>> "CHC" == Choi He Chul <[EMAIL PROTECTED]> writes: > > > > CHC> dpkg-python packages is installed to /usr/lib/site-python/dpkg > > CHC> . > > > > CHC> So. I can't import other directorys. > > > > CHC> I must copy that files to my work dircetory when I want use it? > > > > I think the `__init__.py' file is missing in /usr/lib/site-python/dpkg. > > This is not the only bug in the package. Should I do NMU? > > > > BTW, if `dpkg-scriptlib' still has no maintainer, I'd consider to take > > over its Python part, once we have a Python interpreter with a GPL > > compatible license. > > in 1998 I convertedthe scripts to use the re module and the package > format. Unfortunately I don't have this code anymore. You may ask > Gregor (flight); I think he added some documentation for the modules. -- [ Gregor Hoffleit<[EMAIL PROTECTED]> ] [ Friedr.-Ebert-Anl. 53b <[EMAIL PROTECTED]> ] [ 69117 Heidelberg <[EMAIL PROTECTED]> ] [ Germany (49) 6221 22186 ]
Re: Packaging of more zope products
On Thu, Feb 17, 2000 at 11:39:06AM +0100, Christian Leutloff wrote: > for ZOPE exists many many so called products that extends the > functionality. Some are already available for Debian: zope-mysqlda, > zope-pygresqld, zope-siteacces, zope-tinytable. Are there any plans to > pack more of the available products? Are there any reasons why it > hasn't happened so far (except nobody wants to do the work)? Time (missing, that is) is certainly one reason. Another reason I didn't package any other things is that I hoped to come up with a generic zproducttodeb tool (cf. gtkthemetodeb) that would help packaging this stuff. IMHO a problem with packaging Zope products is that most of them currently are very small, and packaging each of them introduces a quite a big overhead. Recently, there was a discussion on the Zope list about "Zope packs"--sounded like a generic package format for Zope products--if there was a decent solution for this, I'd certainly prefer this about manually packaging each single product. Then, somebody from zope.org/Members wrote a script to package a big number of Zope products in a single .deb file. Gregor
Bug: Signal processing in 1.5.2 and Python (readline, LinuxThreads etc al.)
Hi, I just wanted to draw your attention to a bug report I submitted into the Python BTS (Bug #196; currently available as http://www.python.org/python-bugs/incoming?id=196;user=guest). I describe that the combination of Python 1.5.2, LinuxThreads and readline support has strange effects to the signal handling of the interpreter. I tested various combinations of 1.5.1, 1.5.2, different glibc's, GNU Pth instead of LinuxThread's pthreads and tried to find a pattern. The most obvious observation of this problem certainly is that a Python 1.5.2 interpreter on Debian 2.2 systems will exit if you press Control-C on the command line, while you would expect a KeyboardInterrupt exception. Moving the readline module out of the way, *or* compiling the interpreter without thread support or with Pth threads will cure this a little bit, but still there are strange effects. Perhaps you're interested in browsing the report and trying this with different Linux and different Unix flavors. Please don't hesitate to send me your results. Maybe somebody can give me a hint where to look for the bad guy. Candidates seem to be LinuxThreads, GNU readline, the Python readline module and the Python thread support, but I'm lost where to look for the bug. Gregor pgpnCW6zGZjvj.pgp Description: PGP signature
Re: RFC: New package "python"
On Wed, Jan 12, 2000 at 04:00:01PM -0500, David Coe wrote: > This sounds like a task package to me, too, but maybe I misunderstand > what you said; would it include anything besides the dependencies? > > Also note that we still have (well, recently had, at least) some packages > which depend on 'python': > > Package: bg5ps > Package: pythondoc > Package: sketch > > If what you suggest is just a task package, I'll add it to the > forthcoming task-python-* collection; I agree it's a nice idea to get > all the official python pieces via one package. Ok, maybe we better go with task-python, although I still like the idea of a real python package--IMHO it's a little bit more intuitive than task-python, and if the name is still free, why shouldn't we use it. The packages depending on "python" would be no big very problem. In the worst case, they would have to be changed to depend on python-base if they don't need the additional bells in whistles installed by python, and this is a good solution anyway. Finally, and perhaps most important, a real "python" package would make versioned dependencies possible: Something like "python (>=1.5.2)" currently simple doesn't work, and you have to simulate it with e.g. "python-base (>=1.5.2), python-gdbm (>=1.5.2)". Please do the task-python* packages anyway! Gregor pgpHbrSuQDyde.pgp Description: PGP signature
Re: Boot-Floppies: task-python packages
David, are you still working on these task-python* packages ? It would be nice if we could get them into potato. Gregor On Tue, Oct 26, 1999 at 06:03:10AM +, David Coe wrote: > I'm building the task-python packages, have a few questions, and would > like your suggestions for improvements... I'll get these uploaded this > week, after incorporating your suggestions. Thanks. pgptlar9SJa3H.pgp Description: PGP signature
RFC: New package "python"
I'd like to hear your comments about a change which may or may not make it into potato: Currently "python" is an virtual package only, provided by python-base. I'd like to turn "python" into a real package with the upcoming new revision of the Python packages: Package: python Source: python Depends: python-base, python-dev, python-gdbm, python-mpz, python-tk, idle, python-zlib, python-examples Suggests: python-doc, python-elisp Description: An interpreted, interactive, OO language (full distribution) This package installs the complete Python distribution as availble from www.python.org, featuring e.g. . - Tkinter, a platform-indepedent GUI toolkit, based on Tk - IDLE, a Python integrated development environment, written in Tkinter - the environment for building Python extensions in C . If you don't need all of these, don't use this package, but only python-base. I.e. this package would install in all packages that are included in the Python distribution, drawing in the necessary dependencies if not yet installed (libgdbmg1, libgmp2, zlib1g, tcl8.0, tk8.2). Therefore a newbie user can select "python" and will get a typical Python installation. Experienced users can strip down the system by using "python-base". I'm not sure about python-tk and idle, though, since they depend on X11 at last. As well arguable are the packages that are now in Suggests (elisp depends on an emacsen), should I include python-doc in the Depends ? Comments ? Gregor pgpgHTCGMik9P.pgp Description: PGP signature
