Re: Butchered python configuration ...
+ itsovermyhead (Wed, 29 Apr 2009 20:45:38 +1200): You're a fruit cake aren't you mate? Why didn't you post this to the list? - just into to sending creepy little emails If you call somebody names a third time, I'll ask the listmasters to ban you from the lists. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating unmanaged Python l ibrary extension from ‘python-central’ to ‘python-support’
+ Ben Finney (Wed, 15 Apr 2009 20:19:55 +1000): * Copy the file from ‘writers/manpage.py’ into ‘usr/lib/$(shell pyversions -d)/site-packages/docutils/writers/.’. If I omit this step, there is no indication that the modules should be in the ‘docutils/writers/’ system library directory. You’re not qualifying the destination directory. Do you mean debian/tmp/usr/lib/...? In that case, just use debian/pkgname/usr/lib... instead, and skip the dh_install step. * Tell ‘dh_install’ to install ‘usr/lib/python*/site-packages/docutils/writers/’. If I omit this step, ‘dh_pysupport’ ignores the module and it doesn't end up in the package at all. * Tell ‘dh_pysupport’ to do its thing. I would love to collapse the first two steps somehow, but none of my experiments have led to ‘dh_pysupport’ actually finding and installing the module to the right place. See above. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating unmanaged Python l ibrary extension from ‘python-central’ to ‘python-support’
+ Ben Finney (Wed, 15 Apr 2009 21:21:01 +1000): * Copy the file from ‘writers/manpage.py’ into ‘usr/lib/$(shell pyversions -d)/site-packages/docutils/writers/.’. If I omit this step, there is no indication that the modules should be in the ‘docutils/writers/’ system library directory. You’re not qualifying the destination directory. Do you mean debian/tmp/usr/lib/...? I'm not sure what you mean by “qualify”; all the directory names (including the ones you suggest?) are relative, if that's what you mean. No, with “qualify” I don’t mean “make absolute”, of course. But when talking about a path when packaging, it’s very relevant if it’s debian/tmp/usr/lib/foo, or debian/foo/usr/lib/foo. Writing usr/lib/foo alone misses very important information. Except that, in this case, it was really usr/lib/foo, which is just... well, unusual. I'm cribbing from Cyril Brulebois's suggestion, which puts the module in ‘usr/lib/$(shell pyversions -d)/site-packages/docutils/writers/’ and has that directory specified to ‘dh_install’. In that case, just use debian/pkgname/usr/lib... instead, and skip the dh_install step. That does work, thank you. This goes against the suggestions earlier that ‘dh_install’ is the right tool; I'm curious as to why you advise the opposite. dh_install would have been the tool of choice for this task, except that your destination directory is not a static string: it depends on the output of some command. Because of this, it can’t be sensibly used for this. (If pysupport looked in some directory which does not embed the version number, that’d be another story; but I don’t know about that.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package names for docutils writers
* Michael Schutte [Sat, 21 Mar 2009 10:26:12 +0100]: This is how I understand the problem: python-central writes to /usr/lib/python*/site-packages, while python-support uses /var/lib/python-support/python*. Python finds docutils/__init__.py in one directory and doesn’t look for modules starting with “docutils.” anywhere else. That’s correct. Happens as well with Bazaar packages, and any other packages shipping submodules in different source packages, really. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Splitting of the gnome-python* source packages - MBF
Clement Lorteau northern_lig...@users.sourceforge.net gtkvncviewer I filed #518000 a while ago about this, heh. But the bug report needs updating to say that python-gconf exists on its own, and that gtkvncviewer should depend on that instead of python-gnome2. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bzr lightweight checkout, bzr shallow branches, and git
* Paul Wise [Tue, 03 Mar 2009 11:30:13 +0900]: On Tue, Mar 3, 2009 at 1:37 AM, Adeodato Simó d...@net.com.org.es wrote: 3. Git == Git has shallow clones, created with the --depth option for git-clone. This cut-offs the history of the project past a certain point, but the result is lacking: mainly, you cannot push your changes back. (You can do local commits however, and you can create patches for this in the normal Git workflow.) This is wrong, you most certainly *can* push from a shallow clone to a full clone. I think you cannot (yet) push to a shallow clone though (haven't tried it myself). Thanks for pointing that out: I stand corrected, it seems to work indeed. (Which is awesome, and makes Git's standing on this comparison much better IMHO.) I was guiding myself from the documentation, not having used shallow clones myself. From git-clone(1): A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it) [...] ^ Can you confirm whether my reading of the underlined part was correct in assuming it meant you couldn't push from a shallow clone to a full clone? I'll mail upstream about this. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bzr lightweight checkout, bzr shallow branches, and git
* Adeodato Simó [Tue, 03 Mar 2009 12:04:00 +0100]: I'll mail upstream about this. Joey Hess beat me to it two weeks ago: http://thread.gmane.org/gmane.comp.version-control.git/110100 The only answer was: AFAIK, it will work in simple cases, but isn't guaranteed to work. Which is a pity, but I think the docs should be updated to explain it better. I'll follow-up to the thread. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org In my opinion, the most fruitful and natural play of the mind is in conversation. I find it sweeter than any other action in life; and if I were forced to choose, I think I would rather lose my sight than my hearing and voice. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bzr lightweight checkout, bzr shallow branches, and git
* Ondrej Certik [Mon, 02 Mar 2009 11:07:25 -0500]: I have never used stacked branches, but are you sure you can only branch the repository data related to a subset of the working tree only ? My understanding is that bzr stacked branches are useful to avoid downloading the whole history, but that you still need to get the whole project. I think it would be very difficult to support the usual features of DVCS without it ? If you don't want the project history, then you can use lightweight checkouts, which are essentially equivalent to SVN checkouts (you get a local working copy, but no local branch or repository). Ah, so you basically only get the local working copy, but *no* bzr repository, right? Well, with git, you can get this over the web interface, so we may write a simple (Python:) script to download this for you from the commandline. Maybe someone did this already. No, that interpretation is not correct. I'm going to explain the three involved concepts, in hopes that it will be useful for this discussion, or for future instances of this discussion. I'll (concisely) explain Bazaar's lightweight checkouts, Bazaar's stacked branches, and what Git has to offer in this area. 1. Lightweight checkouts A Bazaar lightweight checkout is conceptually the same as a SVN checkout: you get a working copy with the latest version of the project, you can use `log` and `diff` to examine history (over the network), you can use `diff` and `status` to see your changes, and you can use `commit`, but comitting commits directly to the remote repo, rather than locally. You can also create a lightweight checkout of a read-only location (most likely http://), the same as you can create a read-only SVN checkout (most likely svn://). Lightweight checkouts are useful for people who don't want to download the whole history, *and* do not want/need to make commits offline. 2. Stacked branches === A stacked branch in Bazaar is a mechanism to create a full-fledged working copy (meaning, a copy where you can perform all Bazaar operations, including offline commits), but without the need to download all history. The difference with a lightweight checkout is that the lightweight checkout keeps *no* local state, and always acts directly in the remote location (like SVN). A stacked branch is a regular branch, and can keep local commits; it just know to fetch data from the network *on demand* (I have no idea if the fetched data is cached or not, but my guess would be that it is not). Stacked branches are useful for people who want to use Bazaar as a DVCS, but who prefer not to download the whole history of the project, paying network trips as a price. I can confirm that stacked branches *are not* about doing checkouts of parts of a project. That's called partial checkout, and it's a completely different beast altogether. 3. Git == Git has shallow clones, created with the --depth option for git-clone. This cut-offs the history of the project past a certain point, but the result is lacking: mainly, you cannot push your changes back. (You can do local commits however, and you can create patches for this in the normal Git workflow.) As far as I know, Git doesn't have a mechanism to create full-fledged repositories with only part of the history, referencing other remote repositories for missing data. With my Git user hat on, this is clearly a technically inferiority of Git vs Bazaar. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org In my opinion, the most fruitful and natural play of the mind is in conversation. I find it sweeter than any other action in life; and if I were forced to choose, I think I would rather lose my sight than my hearing and voice. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bzr lightweight checkout, bzr shallow branches, and git
* Guy Hulbert [Mon, 02 Mar 2009 12:47:45 -0500]: On Mon, 2009-02-03 at 17:37 +0100, Adeodato Simó wrote: As far as I know, Git doesn't have a mechanism to create full-fledged repositories with only part of the history, referencing other remote repositories for missing data. With my Git user hat on, this is clearly a technically inferiority of Git vs Bazaar. This was a design decision that Linus made right at the beginning. In his opinion, it makes Git technically superior to Bazaar. There is a google video available where he explains the design. Do you have a technical reference for Bazaar ... or even a rebuttal to Linus's claims ? I'm not claiming that Git's design is overall inferior than Bazaar's. In fact, I quite much like it. I'm just saying that Bazaar can provide full-fledged branches that don't physically contain all history data, and Git cannot, and in my view that's a disadvantage and an inferiority *in that particular point*. Whether Linus just says that it's not possible to achieve such functionality with the current Git model, but that such model has enough other advantages to be worth it, or whether he says that not supporting that functionality is actually a feature, I don't know, nor something I recall hearing about back when I watched the Google video. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Removing w32 specific Python code from a package
* Stephan Peijnik [Fri, 27 Feb 2009 10:07:40 +0100]: On Thu, 2009-02-26 at 16:27 +0100, Adeodato Simó wrote: * Stephan Peijnik [Thu, 26 Feb 2009 15:46:58 +0100]: Now as python-pyglet needs to be repacked because it is not entirely free anyways I thought I could get rid of this problem by simply removing the w32-specifics when repackaging the dfsg version of the tarball. What about just not installing into the .deb the windows-specific files? I file a bug-report upstream and asked them to fix that in their setup.py. Maybe I could remove that code in the build target of debian/rules. Is that what you suggested? More in the binary, but something like that, yes: setup.py install rm -f debian/python-pyglet/usr/share/.../bad.py ... -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The first step on the road to wisdom is the admission of ignorance. The second step is realizing that you don't have to blab it to the world. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Removing w32 specific Python code from a package
* Stephan Peijnik [Thu, 26 Feb 2009 15:46:58 +0100]: Now as python-pyglet needs to be repacked because it is not entirely free anyways I thought I could get rid of this problem by simply removing the w32-specifics when repackaging the dfsg version of the tarball. What about just not installing into the .deb the windows-specific files? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Martirio - Amor masoca -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: doubt about license
* Pietro Battiston [Tue, 03 Feb 2009 21:47:53 +0100]: Hello, Pietro, thanks for noticing this. Please forgive my ignorance, but why does package python-openid, which has an Apache license (with some boilerplate not filled at the end, I think) in LICENSE file, report LGPL in debian/copyright? Googling a little, I couldn't understand if such a migration is legally plausible (I don't think so, but I'm not an expert). But even if it was, what is the reason? Such migration is indeed not possible at all, and the copyright file in the Debian package is bogus. This is a serious bug according to Debian standards. I've reported it as #514064. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org He who has not a good memory should never take upon himself the trade of lying. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
* Michael Hanke [Mon, 26 Jan 2009 06:37:13 +0100]: I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. % zcat /org/ftp.debian.org/ftp/dists/lenny/*/source/Sources.gz | grep-dctrl -FBuild-Depends python-sphinx -ns package pymvpa python-django On sid there are a few more: jinja2 matplotlib mpmath pymvpa python-django python-django-treebeard python-pysqlite2 python-tempita python-webob rpy2 webtest -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: remote-hellanzb-gui
* Arnaud Fontaine [Fri, 02 Jan 2009 16:09:46 +0100]: You could get rid [...] of debian/docs as cdbs already installs the files listed. «Explicit is better than implicit.» (Maybe not on -mentors, but surely on -python. ;-) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Anjani - No One After You -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python 3.0 ?
* Piotr Ożarowski [Sat, 27 Dec 2008 23:08:25 +0100]: $ dget -x https://launchpad.net/ubuntu/jaunty/+source/python3.0/3.0-0ubuntu1/+files/python3.0_3.0-0ubuntu1.dsc $ cd python* $ debuild JFTR, the Ubuntu jaunty binaries work well in unstable. There are also metapackages available, python3 and python3-minimal, that give you /usr/bin/python3 (for she-bangs, eg.). -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Mankind are very odd creatures: one half censure what they practice, the other half practice what they censure; the rest always say and do as they ought. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509697: Python 2.5, ctypes, and binutils
Regarding #509697 (python 2.5 providing ctypes, and ctypes using objdump), I don't think it's reasonable to make python2.5 depend on binutils, just for the purpose of one of the modules in the standard library. One option would be to add binutils to Recommends or Suggest, but that does not ensure packages that Depend: python-ctypes will work. Maybe python should stop Providing: python-ctypes, and python-ctypes should depend on python (= 2.5) | python2.4 instead of just python2.4 (plus the recently added a dependency on binutils). This way binutils will get pulled only when a package that depends on python-ctypes is installed. (This does not solve, however, packages that are being smart and are depending on python (= 2.5) | python-ctypes. But maybe those packages should stop doing that.) If this is the way to go, then for squeeze it means that, if the ctypes source package is to disappear, it should be created as a dummy package (from python-defaults instead?), if only to contain the binutils depends/recommends. Comments welcome. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When all is summed up, a man never speaks of himself without loss; his accusations of himself are always believed; his praises never. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFR] urlwatch
* Piotr Ożarowski [Thu, 18 Dec 2008 22:46:36 +0100]: [Adeodato Simó, 2008-12-18] * Piotr Ożarowski [Thu, 18 Dec 2008 22:06:35 +0100]: You can even install it as /usr/share/urlwatch/urlwatch.py (but still symlink it without the extension) - this way you'll have additional .pyc file which will speed urlwatch a little bit AFAIK, .pyc files are only for imported modules, and never for executed scripts. They are certainly not created by default, and strace does not show them being used either. that's why I wrote to install it as /usr/share/urlwatch/urlwatch.py (note the additional extension). Yes, I got that. You mean: /usr/bin/urlwatch - /usr/share/urlwatch/urlwatch.py But even with that, strace does not show that a /usr/share/urlwatch/urlwatch.pyc file would get used when invoking urlwatch. (Plus you wouldn't want .pyc files in /usr/share/package anyway AFAIK.) lots of packages are installing .py files into /usr/share/something (IMHO all Python applications should do this and thus not pollute global namespace) and pycentral/pysupport handles it fine. Oh, sure. I (1) agree applications should put files un /usr/share/name, and (2) I meant you wouldn't want .pyc files there as in if you don't use pycentral of pysupport, sorry for the confusion. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conference is a gathering of important people who singly can do nothing but together can decide that nothing can be done. -- Fred Allen -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: seeking advice for xcb-proto packaging
* Julien Cristau [Tue, 04 Nov 2008 18:43:28 +0100]: Hi, Hello Julien, xcb-proto upstream installs a few python files[1], which are then used at build time by libxcb[2]. Using the upstream build system, these files get installed to $prefix/lib/python2.5/site-packages/xcbgen, and that path is set in xcb-proto.pc's pythondir variable. The libxcb build then uses that variable to look for xcbgen[3,4]. Now that seems bad to me, because it means the python version gets hardcoded in the pkgconfig file, and when we switch to python 2.6 c_client.py will still look in the python2.5 dir, and presumably find the .pyc files there. Can anyone here suggest a way to fix this, either by working around it in the packaging or as a patch that I could send upstream? python is very much an unknown beast to me, so hopefully you'll have some ideas :) Note that none of this is in the debian xcb-proto and libxcb packages yet, but I'm looking at packaging the next version and this issue is sort of blocking progress. Let's go one step at a time: (1) You should of course use python-central or python-support so that the xcbgen Python package is always available for all installed python versions. Hope that was your intention. :-) (2) If you do that, then AFAICS no more meddling is strictly required for things to work: the -p argument of c_client.py only appends the given path to the list of directories Python searchs for modules. Since it is appended at the end, the correct directory will be searched first. (3) The fact that xcb-proto.pc hardcodes a Python path is, uhm, bad. xcb-proto instalation script should take care of installing the Python files somewhere importable (e.g. the $prefix/lib/python2.5/... path you mentioned), and assume the 'import xcbgen' statement in c_client.py will work in any system with xcb-proto installed (the -p flag could still be supported, that's orthogonal). Putting a Python path in the .pc file means xcb-proto has to be recompiled whenever the default Python version changes. Maybe somebody on the list can take care of educating upstream about this, if this analysis is correct, which I believe it is. Was that clear enough? :-) [1] http://cgit.freedesktop.org/xcb/proto/tree/xcbgen [2] http://cgit.freedesktop.org/xcb/libxcb/tree/src/c_client.py [3] http://cgit.freedesktop.org/xcb/libxcb/tree/configure.ac#61 [4] http://cgit.freedesktop.org/xcb/libxcb/tree/src/Makefile.am#265 -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The true teacher defends his pupils against his own personal influence. -- Amos Bronson Alcott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian lenny update : nxutils.so: undefined symbol: __gxx_personality_v0
* oc-spam66 [Thu, 23 Oct 2008 17:07:21 +0200]: If I understand well, you managed to compile a working version of python-matplotlib. Will you release it for lenny ? (the current version is still 0.98.1-1+lenny1.1, which does not work) Yes, it will be released for lenny. In fact such version is ready, but it's not in lenny due to some internal issues. The upload is at the moment in a suite called lenny-proposed-updates. You would be able to install it if you add this to your sources.list: deb http://your.mirror.org/debian unstable main HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conference is a gathering of important people who singly can do nothing but together can decide that nothing can be done. -- Fred Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian lenny update : nxutils.so: undefined symbol: __gxx_personality_v0
* Adeodato Simó [Thu, 23 Oct 2008 17:48:18 +0200]: The upload is at the moment in a suite called lenny-proposed-updates. You would be able to install it if you add this to your sources.list: deb http://your.mirror.org/debian unstable main Or you can fetch it from: http://ftp.de.debian.org/debian/pool/main/m/matplotlib/python-matplotlib_0.98.1-1+lenny3_i386.deb (Or, if you don't use i386, your architecture.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Hay quien sueña con la alquimia que haga del vicio virtud -- Luis Eduardo Aute, Giraluna -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs that'll block python 2.5
* Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]:
On lun, 2008-04-14 at 22:57 +0200, Adeodato Simó wrote:
Finally, and quite importantly, there is what to do with modules that
have been added to the standard library in 2.5 (ctypes, celementtree,
wgsiref). These use either pycentral or pysupport, and since they mark
themselves as for python 2.5 only, the dependency generated is on
python ( 2.5), rendering them uninstallable.
The solution is really simple, just add them to python’s Provides: list.
That's a good point, but that's about rdepends only, and orthogonal to these
packages being uninstallable.
Anyway, FTR, all three packages have been uploaded like this:
python-wsgiref (0.1.2-3) unstable; urgency=medium
.
* Replace ${python:Depends} with python (2.5) | python2.4,
python-support (=0.6.4) as python-support generates wrong dependencies
(and makes this package uninstallable with python2.5 set as default)
celementtree (1.0.5-10) unstable; urgency=low
.
- don't use ${python:Depends} in depens fields so
that the package can coexist with python = 2.5 (Closes: #475897)
ctypes (1.0.2-3) unstable; urgency=medium
.
* Change all to 2.5 in XS-Python-Version and let python-central
generate dependencies, add python2.4 to Depends (closes: #475906)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Carlos Berlanga - Septiembre
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bugs that'll block python 2.5
Hello guys. Yesterday about 100 binNMUs (per arch) were scheduled to rebuild stuff against the new default python version. amd64 and others seem to have attempted them all already, so I took a peek at what failed, and tagged the existing bugs (or submitted new ones) with the goal-python2.5 usertag. So, you can find a list of the 9 FTBFSes that need attention here (these are not 7 days old yet, but patches would be always welcome): http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=goal-python2.5;[EMAIL PROTECTED] There is also in that list a couple trivial uploads that'll be needed (#476170 and #476173, though a proper patch for #476173 would be nice). Finally, and quite importantly, there is what to do with modules that have been added to the standard library in 2.5 (ctypes, celementtree, wgsiref). These use either pycentral or pysupport, and since they mark themselves as for python 2.5 only, the dependency generated is on python ( 2.5), rendering them uninstallable. This means that these three packages either are to be dropped, or (preferably) fixed so that they can provide modules for python 2.4 (which will still be supported for lenny), yet be co-installable with python=2.5. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org «Ara que ets la meva dona, te la fotré fins a la melsa, bacona!» -- Terenci Moix, “Chulas y famosas” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pycentral does not bytecompile for new supported versions?
Hi. (Please CC me on replies.) I have a doubt with respect how pycentral behaves when new supported versions are added to /usr/share/python/debian_defaults. Recently 2.5 was added to supported-versions, and I was expecting that somehow packages using pycentral with appropriate Python-Version headers would make themselves available under /usr/lib/python2.5/site-packages, but this does not happen. However, if I reinstall any of those packages, they do appear there. This seems like inconsistent to me. Is this the intended behavior? FTR, from my observations, python-support makes modules available for all installed python versions independently if they are in supported-versions or not. Any insight appreciated. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When all is summed up, a man never speaks of himself without loss; his accusations of himself are always believed; his praises never. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Version: 0.9-1 * Brian May [Sun, 27 Aug 2006 17:43:24 +1000]: Robert Could you please run 'bzr upgrade' while using bzr Robert 0.9rc1. If my guess at your situation is right this will Robert take a while to run, but correct your performance issues. Did I do something wrong? [EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. Adeodato No. You just need to upgrade your bzrtool package to 0.9 Adeodato as well. I had 0.9 installed already when doing this: ii bzrtools0.9.0-1 Collection of tools for bzr Hm. I'd say that you have .pyc files left in: /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools Can you check, please? Also, do you remember having root bzr as root? bzrtools 0.9 does not put files under /usr/lib/python2.4, since it uses python-support; and its maintainer scripts for 0.9 did not bytecompile the modules, so the most plausible explanation for .pyc files in /usr/lib/python2.4 is having run bzr 0.8 as root. To debian-python: this is presumably a bug in bzrtools? So what is going wrong? Anyway, I tried the revert operation again with 0.9-2. Memory usage was still high (205meg at one point), but bounded - much better. The operation successfully completed this time. Adeodato Sounds acceptable to close ##380412, then? Yes, sounds good to me. Done, thanks. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Los Caramelos - Cherry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
* Brian May [Mon, 28 Aug 2006 13:22:55 +1000]: Adeodate Also, do you remember having root Adeodato bzr as root? Huh? Sorry, that should have read: do you remember having *run* bzr as root. It's the most likely cause for those .pyc files to be there, since bzrtools did not. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The total accumulated knowledge of all the men that ever walked the Earth on the topic of women can fit in the period at the end of this sentence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#383958: lintian: python-script-but-no-python-dep error with python-support
* Russ Allbery [Sun, 20 Aug 2006 17:30:39 -0700]:
Please don't rely on transitive dependencies. It's just a lurking bug
waiting to happen. Your package contains a Python script which requires a
Python interpreter. It should therefore depend on the package that
provides the Python interpreter. Unless python-support is defined to
provide a Python interpreter, it's not the correct package to depend on
for that purpose.
In general, for every interface, system service, or binary that your
package uses, you should depend directly on the package that provides that
interface, system service, or binary unless that package is essential, and
not assume that some other dependency will provide it for you. Time and
again, transitions in Debian have proven that such assumptions break over
time and suddenly make packages RC-buggy. Yes, sometimes it's very
unlikely that such a transition will happen, but I think it's better as a
general rule to be sure.
JFTR, the bug is solely in python-support, and not in the package
lacking the dependency: although not advertised in the description
(which is user-oriented), python-support also takes care at build time
of generating a list of needed dependencies and placing it in the
${python:Depends} substvar.
With this, it's reasonable to expect for it to provide a correct list of
such dependencies, which should include python for packages shiping
scripts invoking /usr/bin/python.
Thanks,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Mirafiori - Cinco minutos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-repack warnings: what effect?
* Pierre Habouzit [Mon, 24 Jul 2006 17:11:14 +0200]: just FYI, it's not mandatory [XB-Python-Version], one can use debian/pyversions instead (with python-support). Hm. I can see how debian/pyversions can substitute XS-Python-Version (both are available only at build time), but I fail to see how it can substitute XB-Python-Version which is presumably needed at install time. (I'm not very familiar with how pycentral works, though.) I agree that having Python-Version in binary packages is dislikeable. Out of curiosity, Matthias, would be a DEBIAN/pyversions file able to provide the same information to pycentral? Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Hooverphonic - Human Interest -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-repack warnings: what effect?
* Matthias Klose [Tue, 25 Jul 2006 00:56:29 +0200]: I agree that having Python-Version in binary packages is dislikeable. Out of curiosity, Matthias, would be a DEBIAN/pyversions file able to provide the same information to pycentral? ^^^ just looking at the Packages (and the Sources) files. Yeah, I knew this was the reason for putting the info in the headers, I understand that. But I was only asking if pycentral itself would have enough with DEBIAN/pyversions, which is different from implying that I'd rather have pycentral use D/pv at the cost of losing the benefits of having that info in the Packages file. ;-) I assume the answer to this question is yes, yes? Now, I have a sequence of events that have left me puzzled: - After writing the above, I intended to ask why XB-Python-Version was necessary in the Packages file, if that information was already in Sources via XS-Python-Version. - But then I thought: d'oh, obvious: XB-P-V must be an _expanded_ version of XS-P-V, with a plain list of python version the package was built for, and this is much easier to parse than an expresion with = and , plus only with XS-P-V you can't know e.g. if a binNMU after dropping 2.3 was successful or not. - But after that, I quickly discover that my assumption is wrong, and the archive contains a number of binary packages whose Python-Version header contains [=], and it's in fact the same as P-V in the source package. With this, I'm puzzled, since I fail to understand what information you can obtain from Packages.gz that you can't from Sources.gz? (The point of this exercise being that it'd be incredibly great if Python-Version would be only present in source packages, and not in binaries, which contain DEBIAN/pyversions instead.) Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Massive Attack - Group Four -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Missing Provides in python-crypto and others
* Matthias Klose [Mon, 19 Jun 2006 09:54:27 +0200]:
I prepared a python-crypto NMU to fix this, but before uploading I
had a look
please do, please fix the rules file as well.
Except that I can't see what's missing in the rules file, sorry. Other
than that, I left the .changes file signed last night, just adding
Provides: ${python:Provides}.
Raphael's rationale leaving these out was, that in most cases the
provides are not needed for arch-indep packages with a Python-Version:
all and would need an extra upload if we add or drop a supported
Python version. This decision should be made by the maintainer
(including a Provides fields), so the debhelper tools should generate
it even for binary-indep packages.
Ah, surely makes sense, thanks for the explanation.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Múm - K-half noise
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Missing Provides in python-crypto and others
Hi, I noticed that python-crypto had undergone the new Python Policy transition thanks to a NMU from Matthias Klose [1]. However, I could not update to this version, since python2.4-paramiko Depends: python2.4-crypto, but the new python-crypto package does not provide it. [1] http://packages.qa.debian.org/p/python-crypto/news/20060616T020207Z.html I thought such Provides field was mandatory under the new policy, and although I failed to find this requirement in the policy itself [2], it's set pretty straightforwardly in item #5 of the NewPolicy wiki page [3]. [2] http://people.debian.org/~piman/python-policy/python-policy.txt [3] http://wiki.debian.org/DebianPython/NewPolicy I prepared a python-crypto NMU to fix this, but before uploading I had a look at the archive and saw that several other packages seem to suffer the same, which made me doubt of myself having understood the issue correctly. (I'm attaching a list of those I found; I left out python-twisted-*, and others that my grep-dctrl search may have missed). Can somebody clear the issue for me? Thanks. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Nightmares on Wax - 'Les Nuits' Package: python-albatross Version: 1.33-3 Conflicts: python2.3-albatross ( 1.33-3), python2.4-albatross ( 1.33-3) Python-Version: all Provides: Package: python-cherrypy Version: 2.2.1-3 Conflicts: python2.4-cherrypy2.1 (= 2.1.1-1), python2.3-cherrypy2.1 (= 2.1.1-1) Python-Version: all Provides: Package: python-crypto Version: 2.0.1+dfsg1-1.1 Conflicts: python2.3-crypto, python2.4-crypto Python-Version: 2.4, 2.3 Provides: Package: python-cxx Version: 5.3.5-2 Conflicts: python2.3-cxx, python2.4-cxx Python-Version: 2.3, 2.4 Provides: Package: python-formencode Version: 0.5.1-2 Conflicts: python2.3-formencode ( 0.5.1), python2.4-formencode ( 0.5.1) Python-Version: 2.4, 2.3 Provides: Package: python-gadfly Version: 1.0.0-10 Conflicts: python-kjbuckets ( 1.0.0-9), python2.3-gadfly, python2.4-gadfly Python-Version: all Provides: Package: python-htmltmpl Version: 1.22-10 Conflicts: python2.3-htmltmpl ( 1.22-8), python2.4-htmltmpl ( 1.22-8) Python-Version: all Provides: Package: python-kjbuckets Version: 1:1.0.0-10 Conflicts: python2.3-kjbuckets, python2.4-kjbuckets Python-Version: all Provides: Package: python-numarray Version: 1.5.1-4 Conflicts: python2.3-numarray, python2.4-numarray, python-numarray-ext ( 1.5.1-3) Python-Version: 2.4, 2.3 Provides: Package: python-numarray-ext Version: 1.5.1-4 Conflicts: python2.3-numarray-ext, python2.4-numarray-ext Python-Version: 2.4, 2.3 Provides: Package: python-optcomplete Version: 1.2-5 Conflicts: python2.3-optcomplete ( 1.2-5), python2.4-optcomplete ( 1.2-5), optcomplete-common ( 1.2-5) Python-Version: all Provides: Package: python-sqlobject Version: 0.7.0-3 Conflicts: python2.3-sqlobject, python2.4-sqlobject Python-Version: all Provides: Package: xbel-utils Version: 0.8.4-5 Conflicts: xbel-utils-0.6 Python-Version: all Provides: Package: xmldiff Version: 0.6.8-2 Conflicts: python2.3-xmldiff Python-Version: 2.3 Provides:
