Re: Python independant binary extensions
Le jeudi 29 juin 2006 à 22:09 +0200, Mike Hommey a écrit : > 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 ? 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/. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Python independant binary extensions
On Fri, 30 Jun 2006, Josselin Mouette wrote: > > Don't you think it'd be nice to add support to python-support and > > python-central for that case ? > > 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/. Having the same .so for python 2.3 and python 2.4 doesn't mean that it will work on python 2.5. So if you put it in the all directory, I would still suggest to have symlink in the versioned directory and to use that as reference as usual. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: News from the python policy transition
On 6/29/06, Sam Morris <[EMAIL PROTECTED]> wrote: On Thu, 29 Jun 2006 16:25:17 +0200, Pierre Habouzit wrote: > Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit : >> So you don't have any excuse to not update your packages any more. >> About 60% of the Python modules have already been updated, but 109 >> are left to be done: >> http://bugs.debian.org/from:[EMAIL PROTECTED] >> >> The bugs have been filled two weeks ago, it is now time to NMU the >> remaining packages where the maintainer didn't gave any update plan >> in the bug report. We need your help for that. > > I've done 16 of them already. that has also fixed 2 RC bugs as a side > effect (uninstallability bugs). > > 7 other person like me, and it's old story ! I noticed the original list didn't include the python-gmenu package. The source package (gnome-menus) produces some regular machine code packages as well as the python module package. Perhaps there are others like this? The gnome-menus bug is #373435, i dunno if there are others without the bugs, but you're welcome to redo the scan and let us know. thanks, -- stratus
Re: Python independant binary extensions
Le vendredi 30 juin 2006 à 15:48 +0200, Raphael Hertzog a écrit : > > I can add the handling of this case by putting them e.g. > > in /usr/lib/python-support/python-foo/all/. > > Having the same .so for python 2.3 and python 2.4 doesn't mean that it > will work on python 2.5. > > So if you put it in the all directory, I would still suggest to have > symlink in the versioned directory and to use that as reference as usual. This is exactly what I thought when wondering how to implement it. It has the advantage to only change pysupport-movemodules and not update-python-modules. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
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
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. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
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: RFS: gaupol, chardet, sqlalchemy
Piotr Ozarowski ([EMAIL PROTECTED]): > I'm looking for sponsor for my 3 packages: > * gaupol (python app., new upstream) > * chardet (python module, not yet in Debian - more info below) > * sqlalchemy (python module, second NMU - see [1] for more info) gaupol and chardet are already uploaded (thanks to stratus) with sqlalchemy I will wait for QA's permission to hijack first -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpRP83d5q10i.pgp Description: PGP signature
[HELP] new policy with a compiled python program and generic python plugin module
Hi, I'm converting one of my package (commit-tool) to the new policy. I was thinking it will be easy, but I found several difficulties. I'm able to deal with them so that I will be conformed to the new policy, but I would like to do the Right Things. Here is the situation. My package has mainly one program "gct". This is a compiled python script (ie it begins with #!/usr/bin/python but it has binary blobs few lines latter). It is built from the upstream source (several python source files) with the help of an upstream program builder (a python script called buildMain.py). It seems that "gct" can be built with any version of python (python2.3, python2.4, ...), but it must run with the same version it has been built. So, if I build "gct" with the current python version, I have sereral choice : A) manually choose a python version and hardcode what is needed: - replace the first line by "#!/usr/bin/python2.3" and hardcode a dependency on python2.3 - (use a build-depend on python2.3 and patch the build system to use python2.3) or (use a build-depend on python (>=2.3), python (<<2.4) and do not patch the build system) B) try to use the default python version present at built time B1) using /usr/bin/python - let the first line of gct to be "#!/usr/bin/python" - generate a depend on python (>=current), python (<=current), python (<
Re: [HELP] new policy with a compiled python program and generic python plugin module
Le ven 30 juin 2006 21:03, Vincent Danjean a écrit :
> Hi,
>
> I'm converting one of my package (commit-tool) to the new policy.
> I was thinking it will be easy, but I found several difficulties.
> I'm able to deal with them so that I will be conformed to the new
> policy, but I would like to do the Right Things.
>
> [...]
> So, I would be glad to get help/comments/advices on this, in
> particular on the way to generate dependencies for my B (B1 or B2)
> proposal.
you need to compile the public modules for every python version.
and the private module + gct only for /usr/bin/python (beeing python2.3
currently).
that is made by installing the modules to be compiled into every:
usr/lib/$python/site-packages/$(package)/
for each python in $(shell pyversions -r).
for the rest, just use the standard mechanism of your package to install
the package, and if there is private modules, pass it to
dh_py{central,support}.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpKPFWOA2FoU.pgp
Description: PGP signature
Re: [HELP] new policy with a compiled python program and generic python plugin module
Le vendredi 30 juin 2006 à 21:03 +0200, Vincent Danjean a écrit : > I'm converting one of my package (commit-tool) to the new policy. > I was thinking it will be easy, but I found several difficulties. > I'm able to deal with them so that I will be conformed to the new > policy, but I would like to do the Right Things. > > Here is the situation. > My package has mainly one program "gct". This is a compiled python > script (ie it begins with #!/usr/bin/python but it has binary blobs few > lines latter). > It is built from the upstream source (several python source > files) with the help of an upstream program builder (a python script > called buildMain.py). > > It seems that "gct" can be built with any version of python > (python2.3, python2.4, ...), but it must run with the same version > it has been built. I think you should patch the package so that the binary blob is put in a .py module that you can import. Then, you can build this .py once for each python version, install it in /usr/lib/pythonX.Y/site-packages, after which it can be handled by python-support. (It will detect that they are different for the different python versions and put them in separate directories.) Cheers, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HELP] new policy with a compiled python program and generic python plugin module
Le sam 1 juillet 2006 00:19, Pierre Habouzit a écrit :
> Le ven 30 juin 2006 21:03, Vincent Danjean a écrit :
> > Hi,
> >
> > I'm converting one of my package (commit-tool) to the new policy.
> > I was thinking it will be easy, but I found several difficulties.
> > I'm able to deal with them so that I will be conformed to the new
> > policy, but I would like to do the Right Things.
> >
> > [...]
> > So, I would be glad to get help/comments/advices on this, in
> > particular on the way to generate dependencies for my B (B1 or B2)
> > proposal.
>
> you need to compile the public modules for every python version.
> and the private module + gct only for /usr/bin/python (beeing
> python2.3 currently).
>
> that is made by installing the modules to be compiled into every:
>
> usr/lib/$python/site-packages/$(package)/
>
> for each python in $(shell pyversions -r).
>
> for the rest, just use the standard mechanism of your package to
> install the package, and if there is private modules, pass it to
> dh_py{central,support}.
forget it... sorry I should have read more carefully
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpOstLk9jkdq.pgp
Description: PGP signature
