zlib missing issue - bookworm
Anyone know how to fix this. I have tried purging and reinstalling python3, no luck with that. apt install on zlib stuff shows I already have current installed. also I installed mutagen module and it's in python3 module directory. But I get a module not found because I am assuming I need to run in an venv. And you see from below the issue there. I found link on the web that showed installing pip on bookworm and the output showed zlib getting linked in. purging pip and reintalling does not show zlib being included. as user: python3 -m venv virtual-env Error: Command '['/home/mjkuhn/PYTHON/virtual-env/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1. as root: python3 -Im ensurepip --upgrade --default-pip Traceback (most recent call last): File "/usr/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/local/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/local/lib/python3.7/ensurepip/__main__.py", line 5, in sys.exit(ensurepip._main()) File "/usr/local/lib/python3.7/ensurepip/__init__.py", line 204, in _main default_pip=args.default_pip, File "/usr/local/lib/python3.7/ensurepip/__init__.py", line 117, in _bootstrap return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "/usr/local/lib/python3.7/ensurepip/__init__.py", line 27, in _run_pip import pip._internal zipimport.ZipImportError: can't decompress data; zlib not available debian-python@lists.debian.org ~
Re: Report on the situation of python2.5 in Debian
On Fri, Oct 05, 2007 at 08:04:27PM +0200, Josselin Mouette wrote: > Please note that they can all be binNMUed after python2.5 has become the > default, but all of them will have to migrate to testing at once. We > must make this list shorter unless we want this transition to recall bad > memories to the release team. Well, then, that's not going to happen before the toolchain gets fixed on mips, because of > Here is the list: (...) > xulrunner Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Check license and copyright of files in entire tree (was: Proposed new package, bugs-everywhere_0.0.193-1.1)
On Mon, Apr 21, 2008 at 11:27:18PM +1000, Ben Finney wrote: > Emilio, and everyone: a reminder to please continue following > http://www.debian.org/MailingLists#codeofconduct>. In particular, > please don't send individual copies of messages also sent to the list, > since I haven't asked for that. > > > Emilio Pozuelo Monfort <[EMAIL PROTECTED]> writes: > > > Ben Finney wrote: > > > Good catch. I'll have to gather the copyright notices properly > > > from the whole tree. > > > > Have a look at `licensecheck -R *` (in case you haven't yet), very > > useful script for these purposes. > > Indeed, I wasn't aware of that. In this case, it's even more useful > for me to run: > > $ licensecheck --recursive --copyright . Just don't forget that it will skip a lot of file types by default. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: #510782 - python-excelerator: debian/copyright fails to mention copyright for antlr.py
On Sun, Jan 11, 2009 at 05:42:28PM +0100, Wouter van Heyst wrote: > > Only that pyExcelerator is rather obsoleted by xlwt. Unforunately, that > isn't packaged, it should be. xlwt is packaged and is in the NEW queue: http://ftp-master.debian.org/new/xlwt_0.7.0-2.html stew signature.asc Description: Digital signature
Re: Untrusted search path vulnerabilities
On Thu, Nov 18, 2010 at 07:04:07PM +0800, Paul Wise wrote: > > On Wed, Nov 17, 2010 at 22:58, Jakub Wilk wrote: > >> A number of packages in the archive sets the PYTHONPATH environment > >> variable > >> in an insecure way. They do something like: > >> > >> PYTHONPATH=/spam/eggs:$PYTHONPATH > >> > >> This is wrong, because if PYTHONPATH were originally unset or empty, > >> current > >> working directory would be added to sys.path. > > I wonder if this class of vulnerabilities (inc the LD_LIBRARY_PATH > ones) could be automatically warned about by lintian. I wonder if this wouldn't be our duty to remove the possibility of these vulnerabilities at all. Who relies on these PATH variables features to include the current directory instead of adding "." ? Why don't we fix python, ld.so and other stuff doing the same such that empty entries are skipped ? Mike -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118111750.ga31...@glandium.org
Bug#700842: ITP: python-wsgilog -- WSGI logging and event reporting middleware
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: python-wsgilog Version : 0.3 Upstream Author : L. C. Rees * URL : http://pypi.python.org/pypi/wsgilog/ * License : BSD Programming Lang: Python Description : WSGI logging and event reporting middleware Supports logging events in WSGI applications to STDOUT, time rotated log files, email, syslog, and web servers. Also supports catching and sending HTML-formatted exception tracebacks to a web browser for debugging. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130218095251.5769.8233.report...@minobo.das-netzwerkteam.de
Request to Join Project Python Modules Packaging Team from Mike Neish (neishm-guest)
I would like to join the Python Modules Packaging Team in order to apply a patch for the "pydap" package (bug 709376). Thanks, Mike -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b64feb.1090...@atmosp.physics.utoronto.ca
Re: Request to Join Project Python Modules Packaging Team from Mike Neish (neishm-guest)
* Sandro Tosi, 2013-06-21, 08:37: Sandro, are you okay with me adding Mike to the team, so the he can commit the patch? sorry for the late reply; sure go ahead, Welcome to the team, Mike! :) does Mike need a sponsor for the upload? I believe he does. -- Jakub Wilk Thanks, Jakub and Sandro! I have the patch ready to commit, but I don't have permission to write directly into the repository (I think it's because I'm not in the 'scm_python-modules' group on the server). Maybe this is where I need to find a sponsor for the patch? :) I would be adding the following files to the 'pydap/trunk' directory: debian/patches/series debian/patches/fix-namespace_packages.patch I haven't touched debian/changelog, though. There's already an unreleased version (2.2.6.7-2) by Jakub, so I wasn't sure whether to (A) Append my change to that entry, (B) Create a new (also unreleased) entry under 2.2.6.7-3, or (C) Let the maintainers edit and sign off on the changelog. So, I'm going with (C) for now :) Thanks, Mike
Re: Request to Join Project Python Modules Packaging Team from Mike Neish (neishm-guest)
On 13-06-21 04:28 PM, Jakub Wilk wrote: You are in this group as far as I can tell: $ ssh svn.debian.org getent group scm_python-modules | tr , '\n' | grep neishm neishm-guest Please make sure you're using the correct host (svn.debian.org, NOT alioth.debian.org; the latter has only read-only copies of the repositories). Thanks! That's exactly what I was doing wrong. I had followed the instructions for "developers" on the Python Modules alioth page (https://alioth.debian.org/scm/?group_id=30714), which pointed me to the alioth.debian.org server. Maybe this is where I need to find a sponsor for the patch? :) No, you need a sponsor only to upload the package to the archive. Gotcha. I haven't touched debian/changelog, though. There's already an unreleased version (2.2.6.7-2) by Jakub, so I wasn't sure whether to (A) Append my change to that entry, (B) Create a new (also unreleased) entry under 2.2.6.7-3, or (C) Let the maintainers edit and sign off on the changelog. (A') Use dch(1), which should do the right thing. :) Reminds me of a saying about idiot-proof programs :) I used "dch -a" to append my change into the existing changelog. Hopefully that's doing the right thing. The patch has been uploaded to pydap/trunk. Thanks, Mike -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51c4bcaa.6080...@atmosp.physics.utoronto.ca
Help needed with src:pkg click when building against Python 3.10
Hi all (esp. doko and Colin), (pls Cc: me when replying, thanks) (mail resent, now with debian-python ML in Cc:, please reply to this mail, so discussion ends on the list, thanks) as part of my work for the UBports Foundation, I am currently working on getting software components of Ubuntu Touch to Debian. One of those comment is the src:pkg click (one of Colin's former upstream projects). We see various test failures recently when running unit tests of click against Python 3.10. It seems that something regarding file descriptor inheritance in subprocess calls has changed between Python 3.9 and Python 3.10 which I fail to pinpoint exactly. At the end of the mail you find a build log excerpt where you can see that the unit test script loops over python3.9 and python3 (aka python3.10 in unstable) when running the unit tests. Whereas tests under python3.9 succeed (first block of test results), tests under python3(.10) fail (second block of test results). The reported errors all resemble this pattern: ``` test_install (click_package.tests.test_install.TestClickInstaller) ... b'ERROR:root:[\'dpkg\', \'--force-not-root\', \'--force-bad-path\', \'--force-architecture\', \'--instdir\', \'/tmp/click9a_gafth/root/test-package/1.0\', \'--admindir\', \'/tmp/click9a_gafth/root/test-package/1.0/.click\', \'--path-exclude\', \'*/.click/*\', \'--log\', \'/tmp/click9a_gafth/root/.click/log\', \'--no-triggers\', \'--install\', \'/tmp/click9a_gafth/fake-package.click\'] failed with exit_code 1:\ndpkg-split: error: failed to read archive \'/tmp/click9a_gafth/fake-package.click\': Bad file descriptor\ndpkg: error processing archive /tmp/click9a_gafth/fake-package.click (--install):\n subprocess dpkg-split returned error exit status 2\nErrors were encountered while processing:\n /tmp/click9a_gafth/fake-package.click\n\nTraceback (most recent call last):\n File "/<>/click_package/tests/gimock.py", line 497, in run_in_subprocess\nyield partial(helper, lib_path, rpreloads), preloads\n File "/<>/click_package/tests/test_install.py", line 476, in test_install\ninstaller.install(path)\n File "/<>/click_package/install.py", line 462, in install\n package_name, package_version, old_version = self._unpack(\n File "/<>/click_package/install.py", line 416, in _unpack\n fn(command,\n File "/usr/lib/python3.10/subprocess.py", line 420, in check_output\nreturn run(*popenargs, stdout=PIPE, timeout=timeout, check=True,\n File "/usr/lib/python3.10/subprocess.py", line 524, in run\nraise CalledProcessError(retcode, process.args,\nsubprocess.CalledProcessError: Command \'[\'dpkg\', \'--force-not-root\', \'--force-bad-path\', \'--force-architecture\', \'--instdir\', \'/tmp/click9a_gafth/root/test-package/1.0\', \'--admindir\', \'/tmp/click9a_gafth/root/test-package/1.0/.click\', \'--path-exclude\', \'*/.click/*\', \'--log\', \'/tmp/click9a_gafth/root/.click/log\', \'--no-triggers\', \'--install\', \'/tmp/click9a_gafth/fake-package.click\']\' returned non-zero exit status 1.\n' ERROR ``` The core information in above error output is: ``` dpkg-split: error: failed to read archive '/tmp/click9a_gafth/fake-package.click': Bad file descriptor dpkg: error processing archive /tmp/click9a_gafth/fake-package.click (--install): subprocess dpkg-split returned error exit status 2 ``` I am suspecting some FD handover in click's install.py for being the point where something fails, but I am unsure. And why does fail in Python 3.10, but not in 3.9? https://gitlab.com/ubports/core/click/-/blob/main/click_package/install.py#L397 Also I found a comment by Colin that might be related (but why only with Python 3.10??): https://gitlab.com/ubports/core/click/-/blob/main/preload/clickpreload.c#L298 Does anyone have a spontaneous idea what might be causing the observed test failures under Python 3.10? Maybe someone can point me to a commit in Python upstream where things in subprocess might have started to change? Any help is greatly appreciated!!! Thanks, Mike ``` make check-local make[3]: Entering directory '/<>' set -e; for python in python3.9 python3; do \ $python setup.py test; \ done /usr/lib/python3/dist-packages/setuptools/dist.py:493: UserWarning: Normalizing '0.5.0-6' to '0.5.0.post6' warnings.warn(tmpl.format(**locals())) running test WARNING: Testing via this command is deprecated and will be removed in a future vers
Re: Help needed with src:pkg click when building against Python 3.10
Hi All, On So 29 Mai 2022 08:52:21 CEST, Mike Gabriel wrote: We see various test failures recently when running unit tests of click against Python 3.10. It seems that something regarding file descriptor inheritance in subprocess calls has changed between Python 3.9 and Python 3.10 which I fail to pinpoint exactly. The issue has been resolved by Marius: https://gitlab.com/ubports/core/click/-/merge_requests/7 (silly version comparison flaw...). Case closed, thanks! Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpkTiVsdhwRO.pgp Description: Digitale PGP-Signatur
Re: Joining the Debian Python Team
Hi all, hi Daniel, On Di 30 Jan 2024 11:12:14 CET, Daniel Teichmann wrote: Hey, I wanna join the debian-python packaging team. I've got Mike Gabriel, who will be my teacher guiding me through my way to become a Debian Maintainer. I already have got a bit of experience with Debian Packaging (especially in the Debian Edu realm). You can see that on my salsa profile. I am online in the #debian-python IRC channel too, you can ping me there, if you have questions. Why you want to join the team: e.g. maintain your current packages within the team, help maintain some specific packages, etc. I intend to package https://github.com/dscripka/openWakeWord. Your Salsa login. https://salsa.debian.org/dzatoah A statement that you have read https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst and that you accept it. I read it, understood it and accepted it. Greeting, dzatoah Seconding Daniel's request. Thx + Greets, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpwrh1SQbqt7.pgp Description: Digitale PGP-Signatur
Re: Experimental Python 1.5.2c1 packages available
On Wed, Apr 14, 1999 at 04:07:29PM +0200, Gregor Hoffleit wrote: > 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 ? I just grab the ps files off www.python.org whenever I want to print it. I don't use info or pdf unless it's the only choice available. I'm worried about package proliferation. It's already impossible to do "dpkg -l python\*" without getting more than a screenful. My net connection is fast enough that 700K + 450K is not a concern. However, if enough people need these formats and have slow or expensive connections, then we should provide them. But for ps, it doesn't seem necessary. Just explain in README.debian where to download them from and how to print them. Most people will delete the files after printing them anyway, and installing and uninstalling a package rather than just deleting five files is rather more work. -- -Mike Orr, [EMAIL PROTECTED]
Re: Zope in Potato ?
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. -- -Mike Orr, [EMAIL PROTECTED] -or- [EMAIL PROTECTED] (permanent: [EMAIL PROTECTED]) http://mso.oz.net/ English * Esperanto * Russkiy * Deutsch * Espan~ol
question on packaging of python applications
Hi, I recently created a debian file for my project (see http://subterfugue.org), and discovered just now why including .pyc and .pyo files directly doesn't work optimally. Looking at other packages which contain python code, it looks like there are several slightly different variations on how this is being done. There seem to differences in exactly which states (configure, etc) cause compilation, and which states, if any, cause removal of *.py[co] files. Is there any sort of policy for this? Or lacking that, is there a particular package I ought to use as a good model? Thanks, --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann
Re: question on packaging of python applications
Bastian Kleineidam <[EMAIL PROTECTED]> writes: > >I recently created a debian file for my project (see http://subterfugue.org), > >and discovered just now why including .pyc and .pyo files directly doesn't > >work optimally. > Where is the problem? Python bytecode should be platform > independent! So it is safe to include .pyc and .pyo files. There is no > need to compile them at configure time. The problem is that in order to have the compiled versions used, they must be newer than the corresponding source (.py file). But if you just include them as files, they'll be unpacked with virtually identical but arbitrarily differing timestamps. So, for example, foo.pyc might be just slightly older than foo.py, in which case python will recompile foo.py on each and every load (since foo.pyc isn't writable by normal users). As for being platform independent, yes, this is true. I assume the reason for compiling, though, is to pick up and match the exact version of python that the user has on their machine (they might even have their own custom version). > >Is there any sort of policy for this? Or lacking that, is there a particular > >package I ought to use as a good model? > I recommend the Distutils (included in Python 2.0 as a module). > Then you can use "python setup.py install --root=`pwd`/debian/tmp" > in your rules file and the .pyc and .pyo files are generated > automatically. > Look at my own program at http://linkchecker.sourceforge.net/ Hmm. Well, I was under the impression that distutils didn't support debian. It doesn't really, but I see what you're doing. Unfortunately, my project isn't compatible with distutils because distutils assumes that all modules in the root package will be in the same directory (which isn't true for my project). Anyway, it seems like there ought to be a policy about installing or not installing the compiled files. Right now, to me, it looks like they should be generated at install time... --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann
Re: question on packaging of python applications
[EMAIL PROTECTED] (Jérôme Marant) writes: > Bastian Kleineidam <[EMAIL PROTECTED]> writes: > > > >I recently created a debian file for my project (see > > >http://subterfugue.org), > > >and discovered just now why including .pyc and .pyo files directly doesn't > > >work optimally. > > Where is the problem? Python bytecode should be platform > > independent! So it is safe to include .pyc and .pyo files. There is no > > need to compile them at configure time. > There is no need to include .pyc and .pyo in packages as python programs > can work without at first use. Yes, but normal users typically cannot create .pyc files, of course. > Moreover, this makes packages bigger. Quite true. > That is why most of us prefer to follow Gregor Hoffleit's method > (see postinst and prerm samples in /usr/share/doc/python-base) > i.e py are compiled at postinst time and revoed at prerm time. Yes, most of the packages look like this. But as I mentioned, there are differences, and I wonder if some of the differences aren't subtle mistakes. --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann
Re: question on packaging of python applications
Rob Tillotson <[EMAIL PROTECTED]> writes: > Then we have no choice, all Python packages will have to depend on a > specific version of Python and be installed under that version's > library, no matter how the .pycs are supplied. Okay, but I'm thinking that not all .pycs should necessarily go in /usr/lib/pythonX.X (or whatever). I was thinking that generally useful python code should go in those directories, but that code that's really only useful as part of a particular application should go under /usr/lib/ somewhere. (That's what I did for 'subterfugue'.) Does that make sense? --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann
Re: Bug#82088: Request build against tcl/tk8.3
[Cc list trimmed a bit; my apologies if you're getting copies and don't want to] On Sat, Jan 13, 2001 at 08:56:19PM +0100, Gregor Hoffleit <[EMAIL PROTECTED]> spake forth: > 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 ;-). 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. > 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. Yes, you'd need separate source packages I think... -- Mike Markley <[EMAIL PROTECTED]> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 Another war ... must it always be so? How many comrades have we lost in this way? ... Obedience. Duty. Death, and more death ... - Romulan Commander, "Balance of Terror", stardate 1709.2
RFS: tpg - Toy Parser Generator - a parser generator for python
Greetings, I'm looking for a sponsor for my tpg package. I tried asking on debian-mentors but was unable to generate any interest, so I thought I might try here. * Package name: tpg Version : 3.0.4 Upstream Author : Christophe Delord <[EMAIL PROTECTED]> * URL : http://christophe.delord.free.fr/en/tpg/ * License : GPL Description : Toy Parser Generator - a parser generator for python Toy Parser Generator is a lexical and syntactic parser generator for Python. This generator was born from a simple statement: YACC is too complex to use in simple cases (calculators, configuration files, small programming languages.languages. . Despite its name, tpg is not a toy. It's a fully featured parser generator that concentrates on flexibility rather than speed. I'd appriciate any feedback of course. my packages are here: deb http://vireo.org/debian/tpg binary/ deb-src http://vireo.org/debian/tpg source/ thanks, stew signature.asc Description: This is a digitally signed message part
Re: when and why did python(-minimal) become essential?
On Sat, Jan 21, 2006 at 02:21:34PM -0600, Joe Wreschnig <[EMAIL PROTECTED]> wrote: > Python is the "official" language of Ubuntu. If we want to merge work > they're doing (Anthony Towns mentioned their work on boot speed, for > example) it's a good idea to structure our Python like theirs is. This > (...) Boot speed and python does not really sound a match... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 26, 2006 at 04:12:35PM +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le samedi 21 janvier 2006 à 21:52 +0100, Mike Hommey a écrit : > > On Sat, Jan 21, 2006 at 02:21:34PM -0600, Joe Wreschnig <[EMAIL PROTECTED]> > > wrote: > > > Python is the "official" language of Ubuntu. If we want to merge work > > > they're doing (Anthony Towns mentioned their work on boot speed, for > > > example) it's a good idea to structure our Python like theirs is. This > > > (...) > > > > Boot speed and python does not really sound a match... > > Surprisingly, python is often faster than perl for the same task. Boot speed and perl does not really sound a match either. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 08:38:57PM +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > Hello, > > the Python team has agreed on a new policy [1]. As we want to do the > python 2.4 transition now, we need to make sure the packages match the > policy. This will limit the amount of broken packages when python2.4 will > become the default and will smooth this transition. > > So please check in the list at the end of this mail if you're concerned, > and if yes, please update your packages following these instructions: > http://wiki.debian.org/DebianPython/NewPolicy > http://people.debian.org/~piman/python-policy/ Maybe I'm dumb or something, but I don't get what "If the public modules installed differ between python versions and if they can't be shared, you should set the following environment variable when invoking dh_pycentral." is supposed to mean. Please Cc: me, I'm not subscribed. Mike PS: Anyways, there's one package you didn't list because it's in NEW, which WON'T be merged as required by the new policy: python2.x-xpcom, provided by xulrunner. The reason is simple: different installations for different python versions CAN'T coexist without breaking each other. PPS: I'll take care of libxml2 and libxslt as soon as I understand what I'm supposed to change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 09:55:08PM +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > When you install some python extensions (.so), it is common that they come > with > associated .py files (modules). Those .py files usually are the same in > /usr/lib/python2.3 and /usr/lib/python2.4, that's why python-central will > keep only one copy of them in /usr/share/pycentral and symlink them back into > /usr/lib/python2.[34]/ ... > > However if the .py installed in /usr/lib/python2.3 is different from the > one installed in /usr/lib/python2.4, then you can't share it between both > versions (and you need the DH_PYCENTRAL="nomove" variable). That what's I > meant. Feel free to fix the wording in the wiki if you have a better way > to express it. Okay, it sounds clearer said like that. Stupid question: why doesn't pycentral autodetect if files are different or not ? I don't actually see a reason why DH_PYCENTRAL need to be set... > > PS: Anyways, there's one package you didn't list because it's in NEW, > > which WON'T be merged as required by the new policy: python2.x-xpcom, > > provided by xulrunner. > > The reason is simple: different installations for different python > > versions CAN'T coexist without breaking each other. > > OK, then indicate "current" in XS-Python-Version and support only the > current version in python-xpcom (make sure to generate the provides > field). What about people who want to use pyxpcom with modules that aren't available with the current python ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, 13 Jun 2006 at 16:10:48 -0500, Joe Wreschnig wrote: > On Tue, 2006-06-13 at 22:05 +0200, Mike Hommey wrote: > > What about people who want to use pyxpcom with modules that aren't > > available with the current python ? > > But a user couldn't install more than one such module at a time, since > the packages are mutually exclusive. It seems far better to me to just > force everyone to use one version and avoid the issue. > > Or, fix pyxpcom, which sounds horribly broken. It's not broken, actually. There are 2 different things in pyxpcom: - a python binding to load and use xpcom components - an xpcom component to load and use python written components (pyloader). The problem is that if you launch the python binding, it will also load the pyloader component. If this component doesn't use the same python version as the binding you're using, you're pretty much fscked. Maybe there would be a way not to load the pyloader component if loaded from an incompatible python version... Mike PS: Please CC me, I'm not subscribed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Python independant binary extensions
Hi all, I'm currently working on getting libxml2 (and later libxslt) to the new policy, and actually noticed something interesting: -rw-r--r-- root/root273888 2006-06-29 22:02 ./usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so -rw-r--r-- root/root273888 2006-06-29 22:02 ./usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so Same size AND same content. After some discussions on #debian-python, I added stuff in debian/rules so that if the binary extensions are identical, I'd replace the dup with a symbolic link. I'm still building for all versions as suggested on #d-p in case the python includes change in some ways. Don't you think it'd be nice to add support to python-support and python-central for that case ? Cheers, Mike PS: Please Cc me, I'm not subscribed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
On Thu, Jun 29, 2006 at 10:09:20PM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm currently working on getting libxml2 (and later libxslt) to the new > policy, and actually noticed something interesting: > -rw-r--r-- root/root273888 2006-06-29 22:02 > ./usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so > -rw-r--r-- root/root273888 2006-06-29 22:02 > ./usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so > > Same size AND same content. A bit more information on that: Before dh_strip: -rwxr-xr-x 1 root root 770117 Jun 29 20:31 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so -rwxr-xr-x 1 root root 770117 Jun 29 20:31 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so md5sums: 7a59735cc2928d873051ec02ec918fa9 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so a23dffbdd649938b80b4cad250dd71cc debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so After dh_strip: -rwxr-xr-x 1 root root 273888 Jun 29 21:05 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so -rwxr-xr-x 1 root root 273888 Jun 29 21:05 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so md5sum: 417dad3c9d4def4e10cf57470d5d0296 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so 417dad3c9d4def4e10cf57470d5d0296 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so So, if python-support/python-central would deal with that it would need to be done after dh_strip... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
On Fri, Jun 30, 2006 at 04:16:40PM +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Python-support already checks the md5sums of the files to install, but > it excludes the .so because files are moved to /usr/share and it would > violate the FHS. I also thought this would never happen. > > I can add the handling of this case by putting them e.g. > in /usr/lib/python-support/python-foo/all/. What if, let's say, python 2.3 and 2.4 versions are identical, but 2.5 is different ? Also, don't forget the files are different until they are stripped. So the basis for differenciation shouldn't be an md5sum... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
On Fri, Jun 30, 2006 at 06:43:22PM +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le vendredi 30 juin 2006 à 17:38 +0200, Mike Hommey a écrit : > > On Fri, Jun 30, 2006 at 04:16:40PM +0200, Josselin Mouette <[EMAIL > > PROTECTED]> wrote: > > > Python-support already checks the md5sums of the files to install, but > > > it excludes the .so because files are moved to /usr/share and it would > > > violate the FHS. I also thought this would never happen. > > > > > > I can add the handling of this case by putting them e.g. > > > in /usr/lib/python-support/python-foo/all/. > > > > What if, let's say, python 2.3 and 2.4 versions are identical, but 2.5 > > is different ? > > > > Also, don't forget the files are different until they are stripped. So > > the basis for differenciation shouldn't be an md5sum... > > It's kind of chicken-and-egg problem. If dh_pysupport is run before > dh_strip, it won't detect this similarity. If it is run after dh_strip, > it won't be possible to use dh_strip --dbg-package as gdb wouldn't be > able to find the symbols at their final location. > > If the case is sporadic enough, I guess we should just let go or handle > the case by hand. If it is not, I can try to modify python-support so > that it moves files in /usr/lib/debug as well, but it's kind of ugly. Or you could compare all ELF sections except .debug.* or something along these lines. Or strip in a temporary directory, but that'd mean the stripping work would be done twice... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
FWIW, here is what i got for python-libxslt1: the files are the same size, but are different. I was wondering how different they could be and it's quite stunning, actually: [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ hexdump -C python2.3/libxsltmod.so > /tmp/2.3 [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ hexdump -C python2.4/libxsltmod.so > /tmp/2.4 [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ diff /tmp/2.* 1808c1808 < 7140 08 8b 45 ec 89 04 24 e8 e8 d9 ff ff 8b 76 18 39 |..E...$..v.9| --- > 7140 08 8b 45 ec 89 04 24 e8 e8 d9 ff ff 8b 76 18 3b |..E...$..v.;| Yep, there's only one *bit* of difference. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
On Sun, Jul 02, 2006 at 12:55:27PM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote: > FWIW, here is what i got for python-libxslt1: the files are the same size, > but are different. I was wondering how different they could be and it's > quite stunning, actually: > [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ hexdump -C > python2.3/libxsltmod.so > /tmp/2.3 > [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ hexdump -C > python2.4/libxsltmod.so > /tmp/2.4 > [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ diff /tmp/2.* > 1808c1808 > < 7140 08 8b 45 ec 89 04 24 e8 e8 d9 ff ff 8b 76 18 39 > |..E...$..v.9| > --- > > 7140 08 8b 45 ec 89 04 24 e8 e8 d9 ff ff 8b 76 18 3b > > |..E...$..v.;| > > > Yep, there's only one *bit* of difference. It's even worse. There's *no* real difference. [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ objdump -d python2.3/libxsltmod.so > /tmp/2.3 [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ objdump -d python2.4/libxsltmod.so > /tmp/2.4 [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ diff /tmp/2.3 /tmp/2.4 2c2 < python2.3/libxsltmod.so: ファイル形式 elf32-i386 --- > python2.4/libxsltmod.so: ファイル形式 elf32-i386 3596c3596 < 714f: 39 7d f0cmp%edi,0xfff0(%ebp) --- > 714f: 3b 7d f0cmp0xfff0(%ebp),%edi Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
current python-only packages and new policy
Hi, I'm writing because the New Policy is not very verbose on building a package for only the current version of python. First, why would i need to build-dep on python-all-dev when python-dev is enough ? Second, why would i need to use python-central or python-support when there's only one supported version of python ? Mike PS: Please Cc me, I'm not subscribed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
