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
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]
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]
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: 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
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
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
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
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
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: 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.
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: 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: 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.
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: 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.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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.
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: 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.
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: 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: 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?
Invitation to debian-python mailing list
Hi, I'd like to invite all of you to join the debian-python mailing list at lists.debian.org. There are a few issues regarding the Python base packages that I'd like to see resolved before the release of slink. This is the charter for debian-python: debian-python@lists.debian.org Description : Discussion of issues related to Python on Debian systems with an stress on packaging standards. Therefore relevant for maintainers of Python related packages. Moderated : no Subscription: open IMHO the current directory setup of Python is not very well suited for Debian. Major upgrades of Python are more troublesome than necessary, and we'll have to change things anyway with the FHS transition. We've already privately discussed this with Lorenzo and Matthias. I'd like to see these discussions be continued on debian-python, and I'd like to invite you (as maintainer of python-related packages) to participate, if you're interested. Other possible issues to be discussed are e.g. standards for naming Python add-on packages (the perl community seems to use lib*-perl, while we're using python-*). Since there are quite a few packages that only have been introduced since hamm or still are in the queue, we would now still have a chance to choose a common naming scheme (lib*-python, lib*-py, py-* ???). Then, I'd like to provide a better way to byte-compile the files in modules. Maybe we could have a look at emacsen's mechanism for registering e-lisp packages. In anticipation of JPython as an alternative Python interpreter, this might be indeed useful and necessary. In the end, I'd like to see the evolution of a policy for Python on Debian systems, with guidelines for maintainers of Python related packages and with hints for users of Python on Debian systems. To support this, I'll set up a web page on www.debian.org/~flight/python/. The page could contain information about the packages currently available, with an link from www.python.org. I hope I'll manage to post a first mail with a longer proposal to the list within the next few days. Gregor
Experimental slink python and jpython packages
Hi, I placed new experimental packages of python and jpython on my private web page, http://www.mathi.uni-heidelberg.de/~flight/debian-private/. Sorry that I still not managed to put together the proposal for a Debian Python policy. If you look at the packages, you'll get the idea for a few modifications that I'd like to make before the slink release: - removal of python-net and python-misc - instead, a new package python-lib - python-lib is Architecture: all; it's the architecture-independent part of python-1.5.1/Lib. - /usr/share/python instead of /usr/lib/python1.5 - /usr/lib/python1.5 has the architecture-dependent stuff like lib-dynload and config (this should probably be /usr/lib/python/). - sitecustomize should be a conffile and therefore live in /etc/python/. - Not yet done: Change Makefile.pre.in so that it installs in the correct places. - Not yet included, the code exists: Build a shared libpython. The layout with /usr/share/python and /usr/lib/python has many advantages for Debian, but also a few drawbacks: It makes it impossible to install two different Debian python versions at the same time (not possible yet with the current layout; do we really need this ???). It drives us away from the upstream python layout. Still I think the advantages (much easier upgrade paths; let the Debian packaging system handle versioned dependencies) are more important. Then, there's the question where and how to install Debian Python add-on packages. I'd like to adopt a mechanism similar to emacen-common, where every package registers itself with the system. The install-python program would byte-compile the files for the installed Python systems (i.e. with "python", with "python -O" and perhaps with "jpython"). IMHO this is much better than the current python /usr/lib/python1.5/compileall.py hack that will have to be updated with every new major release). Then, there's the question where to install Python add-on packages: e.g. /usr/share/site-python or /usr/share/python/site-packages (for architecture-independent files) or /usr/lib/python/site-packages or /usr/lib/site-python or even /usr/lib/python1.5/site-packages (for architecture-dependent or binary packages). Finally, how to handle "old-style" packages ? The snapshots are very much unfinished; the upgrade is not yet really working, and they'll certainly break some things. The JPython stuff is quite unfinished, too (sorry, I forgot to copy the orig file). You see that it depends on python-lib. In fact JPython is the very one reason that I'd like to have python-lib. With JPython, there are still a few copyright issues to resolve: - Guido and Jim Hugunin told me that they want JPython to be Open Source. - still the license has at least a few very unclear sentences: You have to notify CNRI if you distribute modified versions of JPython. I had a short discussion with Eric Raymond, and I understand that he would accept this clause as Open Source compatible if they e.g. included an e-mail address that this notification should be sent to. - JPython includes a non-free Java regex library, OROMatcher. This has been removed in this experimental package. Therefore, the package has no regex support. - JPython won't work yet with kaffe (kaffe is missing BigInt etc.) - To compile JPython, you need the non-free JavaCC (Java Compiler Compiler) package from SunSoft, a kind of Java lex. I don't know the consequences of this. Is this a reason not to include JPython in main ? Consequently, if we intended to switch over to this new directory layout, quite a few packages needed to be changed. Still, the changes would be mostly trivial. I really would like to introduce these changes with slink. Glad to hear any comments, Gregor
Grail (was: Re: Cancel (was grail))
Martin Schulze writes: > Martin Schulze wrote: > > I'd like to entirely cancel my last mail wrt grail. I saw it and > > removed it entirely. The licence is just fucked up. > > > > [..] > > this Agreement does not authorize Licensee to distribute copies of > > the Software to the public, perform and/or display the Software > > publicly, or otherwise make the Software accessible to the public. > > [..] > > An interested user told me that CNRI/NIST decided to leave the code > alone, after having used it as a testbed for network research and > might lighten the license. > > Although, this may look like some hickup, I contacted one of the CNRI > poeple. Depending on the answer I'll give it a try or inhume it. Cf. the JPython license, which also originated from the CNRI (Jim Hugunin). Guido told me that they are working on a CNRI standard license, that they are aware of some problems, and that a primary intention is to make this Open Source compliant. I don't remember what was the case with the Grail license, but with JPython, the unusual part of the license seems to be that they want to track somehow the use of their code (the license doesn't prohibit distribution or modification). I strongely hope that this will be resolved by CNRI, and that Grail will be released under relaxed conditions as well. > PS: I wonder if I'm the only one who writes to this list. I wonder if we are the only ones reading this list. Is it possible to see who is subscribed to the list ? Gregor
Re: Is there anybody out there? [Was Re: Grail (was: ...))]
On Thu, Sep 17, 1998 at 04:34:02PM +0200, Lorenzo M. Catucci wrote:
>
>
> On Thu, 17 Sep 1998, Gregor Hoffleit [...]
> >
> > I wonder if we are the only ones reading this list. Is it possible to
> > see who is subscribed to the list ?
> >
> `An interested user', at least... BTW, I'm pondering on both your latest
> posting arguments (Jpython and python policy), as I think that both
> deserve a careful answer, especially the latter, which is of most use to
> me by now... (I know, I'm just a bit egotic...)
>
> Just to let you know I'm hearing what goes here: do you really think
> someone would use a python without regexp? Just think about cgi, or better
> do a:
>
>
> $ egrep \\bre\(\|gex\)\\b /usr/lib/python/*.py|grep import|wc
>
> I see 46 lines, some of whose in important modules like {url,xmg,sgml}lib!
>
> And later will write on more important stuff, keep tuned!
You're right. Python without any regex support won't be much so fun. OTOH,
there are useful things that will work even without regex, and even
more important, this might be an incentive to start work on an open source
Java regex library.
Gregor
Re: Experimental slink python and jpython packages
On Mon, Oct 12, 1998 at 08:34:19PM +0200, Matthias Klose wrote: > Gregor Hoffleit writes: > > Hi, > > > > I placed new experimental packages of python and jpython on my private > > web page, http://www.mathi.uni-heidelberg.de/~flight/debian-private/. > > > > Sorry that I still not managed to put together the proposal for a Debian > > Python policy. If you look at the packages, you'll get the idea for a few > > modifications that I'd like to make before the slink release: > > > > - /usr/share/python instead of /usr/lib/python1.5 > > - /usr/lib/python1.5 has the architecture-dependent stuff like > > lib-dynload and config (this should probably be /usr/lib/python/). > > Back from my vacations, I am not yet up to date ... What was the date > of the code-freeze for slink? Is there time enough to convert all > other packages? Several threads on debian-devel hinted that the freeze will happen somewhere between one week ago and one week ahead. Although I asked two times on debian-devel when exactly it will happen, I got not a single reaction. We don't know a timeline for the freeze, and there was not very much reaction to the packages above. I guess that leaves us with two options: 1.) Play safe. Stick with the current scheme for slink. I'll upload a new revision 1.5.1-5 with minor fixes only (all official patches applied). 2.) Play risk. Adopt a new scheme similar to my proposal, e.g. - Remove python-net, python-misc; new package python-lib. This would break a few packages' dependencies; those had to be rebuilt. - perhaps new package python-common which manages add-on packages (cf. emacsen-common). Use could be optional; no package had to be rebuilt. Anyway, most python-related packages had to be rebuilt for slink if we choose 2; no major things, just fixing the postinst scripts AFAICS. This easily could be done as NMUs. This should be no problem; the real question is if we want to try this in slink. > > Then, there's the question where and how to install Debian Python add-on > > packages. I'd like to adopt a mechanism similar to emacen-common, where > > every package registers itself with the system. The install-python > > program would byte-compile the files for the installed Python systems > > (i.e. with "python", with "python -O" and perhaps with "jpython"). IMHO > > this is much better than the current python > > /usr/lib/python1.5/compileall.py hack that will have to be updated with > > every new major release). > > I like this idea (but I don't see what needs to be updated with the > current approach). This script shouldn't contain any location, but > information of architecture dependent and independent files. > > And: Shouldn't generated files be placed in /var/cache/python? Hmm. Maybe. FHS says about /var/cache: "5.2 /var/cache: Application cache data /var/cache -- Cache directories | +-- fonts Locally-generated fonts +-- manLocally-formatted manual pages +-- wwwWWW proxy or data cache +-- Package specific cache data /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlile /var/spool, the cached files can be deleted without data loss. The data should remain valid between invocations of the application and rebooting the system. Files located under /var/cache may be expired in an application specific manner, by the system administrator or both. The application should always be able to recover from manual deletion of files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories." (The files in /var/cache need not be shareable or architecture-independent, although this would be the case for python/jpython). Pretty much a description of .pyc, .pyo and $py.class files. Still, I wonder if it's reasonable apart from strict FHS compliance (the emacsen don't use /var/cache either for their .elc files) and if it's technically possible (we would have to put both /var/cache/python as well as /usr/share/python in PYTHONPATH, same site-package etc.). I won't have time this week to work on this stuff. If the freeze will be happening this week, I guess we'll have to choose 1). If there's a little more time (e.g. til end of October), I'd like to go with 2), if most of you agree. Gregor -- | Gregor Hoffleit admin MATHInet / contact HeidelNeXT | | MAIL: Mathematisches Institut PHONE: (49)6221 56-5771 | | INF 288, 69120 Heidelberg / Germany FAX: 56-3812 | | EMAIL: [EMAIL PROTECTED] (NeXTmail)|
Re: Experimental slink python and jpython packages
On Tue, Oct 13, 1998 at 04:13:40PM +0300, Arto Astala wrote: > > 2.) Play risk. Adopt a new scheme similar to my proposal, e.g. > > > > - Remove python-net, python-misc; new package python-lib. This would > > break a few packages' dependencies; those had to be rebuilt. > > Apart of other changes, isn't it possible (and reasonable) to > move from python-net & python-misc to python-lib if it has > replaces, conflicts, provides: python-net & python-misc ? > That way some of the changes could be done earlier, even if > there is no time for all of them. It should be possible, but it isn't: dpkg won't accept "Provides" with versioned dependencies. Dependencies like Depends: python-misc (>= 1.5), python-net (>= 1.5) won't be satisfied by a "Provides: python-misc". This is a bug/known problem in dpkg. So I guess I'll let python-lib provide python-net and python-misc, but it won't help for most packages. > > > And: Shouldn't generated files be placed in /var/cache/python? > > > > Hmm. Maybe. FHS says about /var/cache: > > > > "5.2 /var/cache: Application cache data > > > Pretty much a description of .pyc, .pyo and $py.class files. > > > > Still, I wonder if it's reasonable apart from strict FHS compliance > > (the emacsen don't use /var/cache either for their .elc files) and if > > it's technically possible (we would have to put both /var/cache/python > > as well as /usr/share/python in PYTHONPATH, same site-package etc.). > > This actually depends on how space friendly we want to be > for sys-admins. If we think that our cache can collect > large amount of rarely used stuff, then /var/cache is > the polite thing to do. If we think that this will not be > a problem then it is not needed. We can, naturally, offer > any other .pyc etc. purging mechanism instead, if needed. > > BTW, what happens if there is no writable dir for .pyc etc.? Without having inspected import.c in depth: If it imports a module, Python tries to find the module along PYTHONPATH. For every directory in PYTHONPATH, it looks for a source file (module.py), a compiled file (module.pyc resp. module.pyc) as well as a module/ subdirectory with a __init__.py file). If only a compiled file is found in a directory, it is loaded. If only a source file is found, it is loaded and parsed. Python then tries to write the compiled file into the same directory where the source was found. If this fails (e.g. since the directory is not writable), this is silently ignored (try "python -v" to see the error message). If both a source and a compiled file are found, the compiled file is checked for its validity (the source file must not be more recent). If it's valid, the compiled file is loaded. If it's invalid, the source is loaded and parsed, and Python tries to replace the compiled file with a new one, also silently ignoring error. [Btw, note that the order of the directories in PYTHONPATH takes the highest priority: If PYTHONPATH=/a:/b, and there's a /a/module.pyc, /b/module.py will never be loaded, even if it's more recent! Therefore, /b/module.py will never be compiled.] It's not reasonable to give anybody but root write-access to /var/cache/python, it would be a security hole. The "cache" would have to be maintained by some sort of root script. Therefore, either we had to be sure that the files in /var/cache/python are always up to date wrt to the sources in /usr/share/python, or we had to tweak Python/import.c to consider both directories at once, which is no good idea IMHO. Gregor
Decision made: traditional python setup for slink
Ok, now that I learned that the freeze is going to happen this Friday,
it's clear that the time is too short to make the transition to my
experimental Python setup.
Tomorrow I will upload a new set of python packages, 1.5.1-5, with all
official patches applied and a few new fixes included; there will be
no structural changes compared with the current 1.5.1-3.1, i.e. for
slink we will stick with /usr/lib/python1.5 etc.
Gregor
Bug: python-tk 1.5.1-5 depends on tkstep8.0
Sorry about this inconvenience. I just saw that python-tk from 1.5.1-5 depends on tkstep8.0, while it should depend on tk8.0. I'll correct this in a new upload in the next two or three days. In the meantime, you can also force configuration with "dpkg --force-depends --configure python-tk". Gregor
Re: Bug#28217: python-ldap: non-maintainer upload (alpha) diffs
[The current default Makefile.pre.in from /usr/lib/python1.5/config has the problem that for it uses a plain mkdir to create the DESTSHARED directory. In general, this works fine since DESTSHARED's parent (e.g. /usr/lib/python1.5/site-packages) already exists, but with Debian, `pwd`/debian/tmp/$DESTSHARED doesn't exist yet.] It's a pity, but Guido is eager to fix this problem upstream by using mkdir -p or a more recent install-sh. He doesn't want to introduce potential incompatibilities and wants to stick with the most simple tools. My first thought was to change Debian's Makefile.pre.in to cope with this, but I don't like the idea of fixing this problem by introducing incompatible differences between the upstream Makefile.pre.in and Debian's Makefile.pre.in: It may happen very well that a Python developer running Debian distributes the Debian Makefile.pre.in to the Python community and that it won't work outside Debian's Python. I'm afraid we'll have to work around this problem within the limits of debian/rules. That mean, Python packages using Makefile.pre.in should create the directory `pwd`/debian/tmp/usr/lib/python1.5/site-packages resp. DESTSHARED in debian/rules before running the "make install prefix=`pwd`/debian/tmp/usr". The upcoming Python package 1.5.1-6 contains a README.maintainers with a few hints for Python package maintainers. Gregor
Re: Zope Debian package?
Hi, since a few people asked: On Sat, Feb 13, 1999 at 11:19:16PM -0500, Christian Hudon wrote: > are you still working on a zope package for Debian? If yes, when is it > going to be out? I'd like to play with zope at the office, and so if you're > too busy I could build a zope package and upload it this week. at http://master.debian.org/~flight/zope/, there is a first try at packaging Zope-1.10pr1 for Debian (targetted for potato). The naming will change (1.10pr1>1.10 ;-), it has some rough edges, the docs are unfinished etc.pp., but it works well for me. zope-httpd is ZopeHTTPServer, readily configured to run via /etc/init.d (is this really a good idea ?). Expect to find a zserver package in the future as well. I'll announce when there is a real release to the greater public. Gregor
Experimental python 1.5.2b2 packages on master
Hi, I have finally put completed a first stage of experimental Python 1.5.2b2 packages. Since the packages don't have yet release quality, I have put them on master. News: - Python 1.5.2b2 - python built with shared library libpython1.5.so (this is highly experimental; I would welcome any comments) - apart from that, only small fixes compared to 1.5.1-7. Get them from this URL (I have a little of hope that the second line will work for apt): http://master.debian.org/~flight/python/ deb http://master.debian.org/~flight/python ./ (or http://www.mathi.uni-heidelberg.de/~flight/debian-private/python/) I intend to drop python-net and python-misc and merge them into python-base. python-base is already quite big (too big for a base package ?), so that wouldn't hurt. I wonder if I should start a big renaming in the prospect of the coming of a jpython package. Gregor -- | Gregor Hoffleit Mathematisches Institut, Uni HD| | [EMAIL PROTECTED] INF 288, 69120 Heidelberg, Germany | | (NeXTmail, MIME) (49)6221 54-5771fax 54-8312 | | "We will make windows invisible" |
Experimental Python 1.5.2b2 packages on master
I have prepared an experimental set of Python 1.5.2b2 packages with experimental shared library support. Please try and report any problems or suggestions to me! http://master.debian.org/~flight/python/ resp. for apt: deb http://master.debian.org/~flight/python ./ I plan to drop the python-net and python-misc packages and merge them with python-base. Any comments ? In anticipation of an jpython package, I think it might be reasonable to start a big package renaming (e.g. python-common depending on python-vm for a common framework, python-lib for the shareable Lib part, and python-bin resp. jpython-bin providing python-vm). Gregor
Experimental Python 1.5.2c1 packages available
I have put together a set of experimental Python 1.5.2c1 packages. To use them with apt, try the following line: deb http://master.debian.org/~flight/python ./ They are also available via plain http (this time, I included a proper index.html so that it should be possible to download them with recursive wget as well): http://master.debian.org/~flight/python/ New features: * Python 1.5.2 release candidate 1. * libpython1.5.so reworked. Please report any anomalities! If I don't get any negative feedback, the next potato packages will use a shared libpython for the first time in Debian history ;-) * break sketch 0.5.4. This is a problem with the new multi-threaded Tkinter and sketch' Pax modules. Sketch' author will try to fix this, in the meantime sketch will have to provide an alternative python-tk-nothreads package. Not yet: * The great package renaming. * jpython * python-doc 1.5.2. Is html enough, or should I also include python-doc-ps and python-doc-pdf. The next release of JPython will have a free license. Since there are some build dependencies on non-free software, JPython probably will go into contrib at first. Nevertheless, this will make it necessary to have a common python library package (python-lib ?). Again, any Gregor
Re: This license (JPython) acceptable ?
Following up on my recent inquiry about the JPython license, here is an update. Depending on the results of these issues, I will put the package into main, contrib or non-free. (1) License issues Judging from the repsonses, most of the license seems to be acceptable according to the terms of the DFSG. There's one clause (8.) which can be ignored by removing a third-party library from the packages (OROMatcher). The real problem seems to be 3.iii: 3. In the event Licensee, at its sole cost and expense, uses the Software to prepare a derivative work that is based on or incorporates the Software or any part thereof, and wants to make the derivative work available to the public for commercial or noncommercial purposes, or uses the software in this derivative form to provide a service to the public, then Licensee hereby agrees: (i) to indicate in any such work, in a prominently visible way, the specific modifications made to CNRI's Software; (ii) not to introduce deliberately any modifications where there is reason to believe they will be harmful to other users and their systems; and (iii) to notify CNRI of any release to the public of Licensee's derivative version, or any service offered to the public by Licensee based thereon. It is not obvious whether this is compatible with the DFSG. Therefore, I asked on the JPython list about the implications and intentions of this clause. I got responses from both Jim Hugunin and Guido van Rossum. Both told me that the intention of the license is clearly to make JPython Open Source compliant, and that they are aware of problems with 3.iii and are working to get rid of them. Then, I asked Eric Raymond on his position. He proposed dropping that notification requirement or at least including a clear statement on how this requirement can be fulfilled (e.g. an e-mail address for sending the notifications to). Judging from the discussions with Guido et al, I would think that we are completely safe if I add an statement to /usr/doc/jpython/copyright where I refer people that they can fulfill this requirement with sending a mail to [EMAIL PROTECTED] Would this be acceptable ? (2) Source issues In the upstream source, the Python grammar is included as input for JavaCC (Java Compiler Compiler). JavaCC compiles the grammar into .java source. Does this really make JPython go into contrib ? Or could I simply include the compiled .java files ? (3) Runtime issues kaffe is not yet able to run JPython, since kaffe lacks e.g. java.math.BigInteger. Therefore, JPython currently only works with jdk1.1. Does this make JPython go into contrib ? Or is this simply a bug in kaffe, so that JPython can be in main ? Gregor
Re: Experimental Python 1.5.2c1 packages available
On Tue, Apr 13, 1999 at 09:05:36AM -0700, Mike Orr wrote: > On Tue, Apr 13, 1999 at 01:35:02PM +0200, Gregor Hoffleit wrote: > > I have put together a set of experimental Python 1.5.2c1 packages. To use > > them with apt, try the following line: > > > > deb http://master.debian.org/~flight/python ./ > > Nope, for some reason dselect still thinks 1.5.1.999b2-1 is the current > version. My /etc/apt/sources.list looks like: Aaargh. Make that http://www.debian.org/~flight/python/ resp. (for apt access) deb http://www.debian.org/~flight/python ./ Sorry for the inconveniences! Gregor
Re: Experimental Python 1.5.2c1 packages available
On Wed, Apr 14, 1999 at 09:15:53AM +0200, Paul Stevens wrote:
>
> > I seem to remember there is now a complete info set, which I sure
> > would like to install for use within {x,}emacs, but I don't know how
> > many of debian/python users would find a need for it.
>
> I do. Please do include info docs.
I will.
Earlier python-doc packages already included info docs, but they had
been unavailable for 1.5.1, therefore they aren't included currently.
The docs are quite big (700k resp. 450k for html and info
gzipped). Is there support for splitting them in separate packages ?
Then, is there also a need for postscript resp. pdf packages ?
Gregor
Your opinion about bsddb and glibc2.1
I finally found the time to read the glibc2.1 documentation regarding the changes to the db interfaces. Now I'm left with a problem: In glibc2.1 (which is used in potato for all architectures ??), the old Berkeley DB code (aka db1) has been replaced with code from Sleepycat (aka db2). The internal formats of the db files are different, so you're not able to read a database file written by db1 with db2 and vice versa. The API for db2 has been changed as well (that's ), but db2 alternatively provides the old API, too (in ). The legacy db1 library is still available as . The Python bsddb module needs the old API, so we need to use either or . I guess we now have to decide if the bsddb module should use the old, backwards compatible format or the new format used employed by db2. There are tools to convert database files in the old format to the new format (db_dump), so that's an argument to use the new format. But then, the bsddb module had to be changed anyway to support the new API, therefore one could argue that it's better to work on a bsddb2 module anyway. Any opinions ? Gregor
Re: info docs (was Re: Experimental Python 1.5.2c1 packages available)
On Wed, Apr 14, 1999 at 07:03:09PM -0400, Joe Block wrote:
> Paul Stevens wrote:
> >
> > > I seem to remember there is now a complete info set, which I sure
> > > would like to install for use within {x,}emacs, but I don't know how
> > > many of debian/python users would find a need for it.
> >
> > I do. Please do include info docs.
>
> How about making the info docs a seperate package? That way, if you
> didn't install emacs you don't have to get the info docs - if disk is so
> tight you don't want emacs you probably don't want info docs.
Hmm, in this case, I'd suggest you don't install the HTML docs as
well, since they are >5MB installed (Debian's apache doesn't yet
handle .html.gz's transparently, if I could install them gzipped, that
would be down to 1.6MB), while the info files are only 500kB.
So I think the only valid case would be installing the info files
without the html ones.
Gregor
Second edition of experimental Python packages
There were two significant problems in the first round of the packages I announced yesterday, therefore an silent update: Again, http://www.debian.org/~flight/python/ or deb http://www.debian.org/~flight/python ./ First, I have removed the superfluous idle.1 man pages from all other packages. Then, a few packages were i386 although they really are architecture: all. If I don't get any negative feedback, these packages will make their way in potato early next week. To the package maintainers: Please be prepared to remove any dependencies on python-misc or python-net (or python-curses or python-bsddb), as they will be removed in the next release. Instead make the packages depend on python-base. Future directions: Once this has been established, I'm heading to split python-base into a binary package (python, python-base ?) and a library package (python-lib). Also, I tend to split python-lib in a small package with essentials (python-base ?), so that we have a small, minimal Python system (heading to move Python into base ;-)). Then, we are prepared for a jpython package, with dependencies on python-lib. As you see, this is not yet decided upon. Gregor
Re: Zope in Potato ?
On Wed, Jul 14, 1999 at 10:29:08AM -0700, Mike Orr wrote: > On Wed, Jul 14, 1999 at 10:07:47AM -0500, Debian Developer wrote: > > Anybody thinking of adding zope www.zope.org into Potato ? > > No, but it would be great if we did. I'm not enough of a programmer to > do this, though. This is my priority #2 task after pushing out the fixed python packages. I'll try to finally get out the package by the end of this week. I hoped Zope2 would be read for prime-time a little bit sooner, but since it's still in alpha, I guess I'll really have to go with Zope 1.10.3 or we won't get it in potato. Gregor
Python PAM module uploaded
Just in case you don't see the announcement: I've uploaded a Python PAM module, python-pam, to potato. This module allows you to access the PAM authentification services from a Python program. Since PAMification is a potential release goal, maintainers of Python packages that employ authentification mechanisms, such as mailman and zope, might be interested to try and add PAM support to their programs. Gregor
Re: Boot-Floppies: python task package
On Tue, Sep 14, 1999 at 08:59:46PM +0200, Martin Bialasinski wrote: > Section: devel > Priority: optional > Standards-Version: 2.4.0.0 > > Package: task-python > Version: 0.1 > Maintainer: Martin Bialasinski <[EMAIL PROTECTED]> > Depends: python-base, python-dev, python-misc, python-net, python-tk, > python-imaging-doc, python-numeric-tutorial, python-imaging, > python-imaging-tk, python-doc, python-examples, python-extclass, > python-gdbm, python-gdk-imlib, python-glade, python-gnome, python-gtk, > python-kjbuckets, python-mpz, python-mxdatetime, python-mxstack, > python-mxtexttools, python-mxtoolspython-pmw, python-rng, python-wpy, > python-xml, python-zlib, pythondoc, python-numeric, python-ldap > Architecture: all > Description: Python environment A small correction: Please remove python-misc and python-net. They have been merged back into python-base. It's certainly up for discussion if we really should include things like python-gtk, python-gdk-imlib, python-glade and python-gnome, since they introduce dependencies on non-usual libraries: I'd love to have them, but then task-python will force any user to install a whole range of gnome libraries! Gregor pgpPDYugbjQCU.pgp Description: PGP signature
Trouble with libapache-mod-python: Any volunteers ?
Hi, I keep getting grave bug reports on the libapache-mod-python module. I don't use this module myself anymore, and I don't have much time to spend on it nor do I have much experience with debugging Apache modules. If somebody is interested in taking over the package, or at least debugging it, please tell me. I'm afraid I'll have to orphan the package otherwise. Gregor pgpK9ZGo64zVl.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
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: 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: 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
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
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: 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 ?
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: 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
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?
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 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 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: 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
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
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
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
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
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 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
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: 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
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
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: 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
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
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: 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: 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 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
How to smoothly merge packages ?
Hi, I'd like to merge back some python packages (python-net, python-misc, python-bsddb and python-curses) into python-base. Now quite a lot third-party packages depend e.g. on python-net. What's the best method to ensure a smooth transition for both potato and people upgrading Python from slink, how do I have to set up the dependencies ? IIRC, during the big X11 package renaming, there was a need for some empty dummy packages. Should I use empty python-net etc. packages and urge the user to remove them when they are no longer necessary ? Or can I resolve the situation with "Replaces: python-net, ..." and/or "Provides: python-net, ..." and/or "Conflicts: python-net, ..." ? I'm a little bit lost in the actual consequences of those. Gregor
Re: How to smoothly merge packages ?
Ok, thanks for all the quick answers. Still, I'm running into strange
(IMHO) problems. I'm not sure if this is a bug in dpkg, or if I'm
simply not getting it right ;-):
I still I fail to remove two packages at once in favour of a third.
I moved the contents of python-{misc,net,bsddb,curses} back into
python-base.
For python-misc and python-net, I will provide empty, transitional
packages that satisfy versioned dependencies for existing packages. As
soon as these packages have changed their dependencies to python-base,
the dummy python-misc and python-net packages will be removed in favor
of unversioned Conflicts/Replaces/Provides in python-base.
But since no packages in potato nor slink have dependencies on
python-curses or python-bsddb, I'd like to drop them at once.
I tried this:
Package: python-base
Version: 1.5.2-4
Section: interpreters
Priority: optional
Architecture: i386
Depends: libc6 (>= 2.1), libncurses4 (>= 4.2-3.1),
libreadlineg2 (>=
2.1-12), libreadlineg2 (>= 2.1-13.3)
Conflicts: python (<< 1.5), mailman (<< 1.0b11-2), python-bsddb,
python-curses
Replaces: python (<< 1.5), python-bsddb, python-curses
Provides: python, python-net, python-misc, python-bsddb,
python-curses
Now dpkg would remove python-bsddb, but it fails to remove python-curses:
freefly:23> sudo dpkg -i python-base_1.5.2-4_i386.deb
dpkg: considering removing python-bsddb in favour of python-base ...
dpkg: yes, will remove python-bsddb in favour of python-base.
dpkg: regarding python-base_1.5.2-4_i386.deb containing python-base:
python-base conflicts with python-curses
python-curses (version 1.5.2-3) is installed.
dpkg: error processing python-base_1.5.2-4_i386.deb (--install):
conflicting packages - not installing python-base
Errors were encountered while processing:
python-base_1.5.2-4_i386.deb
If I switch the order of python-bsddb and python-curses in
python-base's Conflicts/Replaces/Provides fields, dpkg fails to remove
python-bsddb!
Depends: libc6 (>= 2.1), libncurses4 (>= 4.2-3.1),
libreadlineg2 (>= 2.1-12), libreadlineg2 (>= 2.1-13.3)
Conflicts: python (<< 1.5), mailman (<< 1.0b11-2), python-curses,
python-bsddb
Replaces: python (<< 1.5), python-curses, python-bsddb
Provides: python, python-net, python-misc, python-curses,
python-bsddb
freefly:31> sudo dpkg -i python-base_1.5.2-4_i386.deb
dpkg: considering removing python-curses in favour of python-base ...
dpkg: yes, will remove python-curses in favour of python-base.
dpkg: regarding python-base_1.5.2-4_i386.deb containing python-base:
python-base conflicts with python-bsddb
python-bsddb (version 1.5.2-3) is installed.
dpkg: error processing python-base_1.5.2-4_i386.deb (--install):
conflicting packages - not installing python-base
Errors were encountered while processing:
python-base_1.5.2-4_i386.deb
For the sake of completeness, this is dpkg -s python-{bsddb,curses}:
Package: python-bsddb
Status: install ok installed
Priority: optional
Section: interpreters
Installed-Size: 28
Maintainer: Gregor Hoffleit <[EMAIL PROTECTED]>
Source: python
Version: 1.5.2-3
Depends: python-base (= 1.5.2-3), libc6 (>= 2.1)
Package: python-curses
Status: install ok installed
Priority: optional
Section: interpreters
Installed-Size: 40
Maintainer: Gregor Hoffleit <[EMAIL PROTECTED]>
Source: python
Version: 1.5.2-3
Depends: python-base (= 1.5.2-3), libc6 (>= 2.1), libncurses4 (>=
4.2-3.1)
Experimental Python packages
I have prepared a new revision of Python packages. I would have uploaded them to master, but I'm running into problems with dpkg upgrading (apt seems to work fine). The packages are available via http: http://www.debian.org/~flight/python/ apt should also work: deb http://www.debian.org/~flight/python ./ Note that you won't be able to upgrade using dpkg unless you first remove python-curses and python-bsddb. apt should work anyway. The problem is that I have removed two packages (python-bsddb and python-curses), making python-base provide/conflict/replace them, but dpkg fails to upgrade: Whatever package is mentioned second in the fields, dpkg won't remove, while the first is no problem. I guess this is one of dpkg's thousand unfixed bugs, but is there any workaround to this problem ? Gregor
Re: Bug#41113: Proposal: Naming Conventions for modules
FYI: Alexander Reelsen filed bug#41113 against debian-policy, which is of interest for debian-java, debian-python as well as debian-perl: On Sun, Jul 11, 1999 at 11:10:22PM +0200, Alexander Reelsen wrote: > The following is a proposal to add some rules to the debian policy concerning > the naming conventions for modules, ie perl- and pythonmodules. > > Earlier, when I was not debianized that way I am now, I installed Perl/Tk > called perl-tk. Then, I tried to install Gtk-Perl (its current name, if I > remember right). I thought it was called perl-gtk, but it is/was called > libgtk-perl. Now I know, most modules are named libfoo-bar-perl and not > perl-foo-bar. > So, a few days ago I installed python and lots of modules. They have all got > the name naming scheme (at least those I installed), namely python-foo-bar. > That was the point in time I was completely confused. > > Long story, short proposal: > In my opinion we should get a stricter policy on this problem, else we will > lose the overview of all those modules (although most maintainers name the > modules after the standard scheme). It should be decided whether the modules > start with libfoo-bar-language or with language-foo-bar. Both is a bad mix. > Switching the programming language and the scheme of searching for modules is > IMHO not a solution and not the intention I think/hope. Currently, the Python maintainers have an implicit policy to use a naming scheme of python-foo-bar for all Python extension modules. If Alex proposal gains support, we may have to change this convention to something like libfoo-bar-python (as I don't think the Perl people would be glad to change their package names ;-). I'm not sure, but I think debian-java adopted a similar naming convention for their Java extensions; at least this is halfways true for the two packages I found in the archive (libpgjava and libgnu-regexp-java) and for the packages I saw discussed in the debian-java list. Personally, I don't not like libfoo-bar-python (nor do I like libfoo-bar-perl) for a few reasons (but perhaps you can convince me that a conversion still has more benefits than odds ;-): (1) Package names tend to get (too) long E.g. on a `dpkg -l "*-perl"', the "-perl" suffix is not visible for most packages. This will be worse for the longer string "-python". (2) We don't follow the conventions of the languages communities C extensions are called libraries. Python extensions are called modules. Perl extensions are called modules. Java extensions are called packages. Now why should genuine Python modules get a "lib" component in their package name ? (3) It makes it harder to find a package by its upstream name Many Python extensions follow an upstream naming scheme of python-foo. Converting this to libfoo-python makes is harder to locate these packages. AFAICS, Perl's convention regarding package names is a consequence of the Debian Policy for C libraries (Debian Policy 4.3 Shared libraries): C library files tend to have a name libfoo (e.g. for the sake of the linker's -lar option ;-). There's some good rationale behind this and it's in sync with the common practice. As a consequence, Debian policy mandates (4.3 Shared libraries) that packages included shared libraries have to follow the librarynamesoname convention (with optional packages librarynamesoname-dev and librarynamesoname-runtime), e.g. libgtk1.2 for Gtk 1.2.x. Now the rationale behind Perl's naming conventions is that Perl's Gtk module is closely related to the Gtk C library, aka libgtk. To stress this relation, the Perl package is called [libgtk]-perl in favor of something like perl-gtk. This sounds reasonable. Still, IMHO it doesn't make too much sense for genuine Perl extensions like libi18n-charset-perl, where there's no base package libi18n-charset that would motivate the "lib" prefix. The "-perl" suffix already identifies a package as an Perl extension module (like our current "python-" prefix or the "-java" suffix), therefore the "lib" prefix is somehow superfluous, and makes the name unneccessary long. What exactly is the benefit of the "lib" prefix and is it worth the odds ? As a starting point for discussions, I would propose those three alternatives for a Python modules' naming sub-policy: (1) Keep the current Python scheme: Stay with the upstream name if possible. A rule of thumb is "python-foo-bar" (i.e. pyfoo-bar will be python-foo-bar). (2) If the extension is just a wrapper/interface for an existing package foo-bar, we'll call it foo-bar-python. Therefore, pygtk would become libgtk-python (just like libgtk-perl). If the extension is a genuine Python module, call it python-foo-bar. (3) The current perl scheme: Call the package libfoo-bar-python. I guess the preferences of the Python maintainers are at (1). Still, perhaps we can discuss this and come to a more general solution that satisfies most concerns. Gregor
Do we prefer Tk8.0 or 8.2 ? (for python-tk, that is)
I have a quite urgent problem while polishing the new Python packages: Do we prefer our packages to use tk8.2 or on tk8.0 ? Python's Tkinter extension module (package python-tk) needs to be linked to libtk. I wonder if I should stay with libtk8.0 or switch to libtk8.2 for the final potato package, as wishlist bug #46705 suggests. A little bit more of half of the Tk packages in potato seem to use tk8.0, while the other half already uses tk8.2. Only three packages would need to be rebuilt after an switch to libtk8.2, so that's possible (python-imaging-tk, python-imaging-sane and sketch). I'm also thinking about providing two Tkinter packages, python-tk and python-tk8.2 (resp python-tk8.0 and python-tk). The problem with this is that the alternative package would have to be built from a pristine source package (tk8.0-dev and tk8.2-dev conflict), and that both packages either would have to conflict with each other, or I had to come up with some custom solution to make them coexist (renaming the module to _tkinter82, or using alternatives). Any opinions ? pgpVoQzM7PIWp.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
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: 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
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: 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
