Re: Please install /usr/bin/python2
On Sun, Sep 15, 2013 at 11:34 AM, Scott Kitterman wrote: > OK. I think that convinces me it's widely enough spread we ought to fix this > for Wheezy. I'll take it up with the release managers as it's their > decision, not mine. Bug filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723182 - Kerrick -- 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/CANaWP3x4oUtXSKSodVtu+2Xe_LH=yyknopykk1gdveso8ey...@mail.gmail.com
Re: Please install /usr/bin/python2
On Sep 16, 2013, at 10:16 AM, anatoly techtonik wrote: >As a Python developer I couldn't care less for the "default Python" >stuff as long as my scripts use proper shebang. python for 2/3 >compatible stuff, python2 for 2.x only and python3 where needed. If you're distributing software intended to be used on a wide range of OSes and you're building your distributions with non-OS tools, then I think this is fine and Debian (starting with Jessie) will let you do this. So there's no problem needing fixing. >The Debian python policy should require that. This is an upstream >recommendation that Debian wrongly didn't pay attention to, choosing to >complain about inevitable natural processes instead. Again, I think it's no big deal that the Debian tools use /usr/bin/python in the shebang for Python 2 scripts. Debian tools and policy are about building great software for *Debian* and its derivatives, not for building cross platform scripts. If you're looking for cross-platform support look upstream, at setuptools, pip, virtualenv, and that ecosystem. -Barry -- 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/20130916103743.7d6645b1@anarchist
Re: Please install /usr/bin/python2
On Sep 15, 2013, at 06:05 PM, Steve Langasek wrote: >And *once that happens*, we can discuss resurrecting /usr/bin/python and >pointing it to python3. It should not change until then. Python 2.7 will have an upstream lifetime of many years even from now. The current thinking (I wouldn't even call it a "plan" at this point) is that we transition 2.7 into security-only source-only mode around the Python 3.5 time frame. A rough approximation puts that around Summer/Fall 2015. After that, I'm confident that 2.7 will get upstream security fixes for at least 3 more years. So really, you're talking about EOL'ing 2.7 no earlier than 2018. (Contrast that with 2.6 which I will gladly drive the final nail in next month. ;) >> See PEP 394 http://www.python.org/dev/peps/pep-0394/>. > >It's not the first or last time that an upstream has made a poor >recommendation that Debian rightly ignores. Please note that I think there's been some confusion about PEP 394, which recent rewording has hopefully clarified. This PEP is *not* recommending that /usr/bin/python point to Python 3, it simply acknowledges that some distributions have done this. In fact, the PEP explicitly recommends that "/usr/bin/python refer to the same target as python2" (yes, "for the time being" but still). Probably the most controversial bit in the PEP for this group is the recommendation that "python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3". IMHO, having scripts (as opposed to libraries) be bilingual is rather silly, so take this recommendation with a grain of salt, but for maximum portability with other OSes, use python2 or python3 explicitly. And yay, you'll be able to do that starting in Jessie although the build-tools won't support 'python2' in shebang lines. That doesn't seem like such a big deal to me because the build tools are specifically for building packages intended to work on Debian, not for building cross platform scripts. -Barry signature.asc Description: PGP signature
[PATCH] Support :any architecture qualifiers for multiarch
(CCing debian-python in case anyone is wondering what those spurious
entries for Python packages in update_excuses.html are about.)
Multiarch adds a Depends: foo:any syntax, permitted only if the target
of the dependency is "Multi-Arch: allowed" [1]. This has been supported
by dpkg and apt for some time and is now safe to use in unstable.
However, britney does not yet understand it. dh-python recently started
using this syntax [2], and as a result we're seeing lots of this kind of
thing in excuses:
i18nspector/i386 unsatisfiable Depends: python3:any (>= 3.2.3-3~)
I've fixed this for Ubuntu's britney instance with the following patch.
I'm afraid I haven't had a chance to rebase it on top of Debian or to
test it there, but that should hopefully not be very much work, and
certainly easier than recreating all this from scratch ...
[1]
https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-architecture_package_relationships
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722045
=== modified file 'britney.py'
--- britney.py 2013-09-09 11:37:52 +
+++ britney.py 2013-09-16 13:25:37 +
@@ -230,14 +230,15 @@ FAKESRC = 4
SOURCE = 2
SOURCEVER = 3
ARCHITECTURE = 4
-# PREDEPENDS = 5 - No longer used by the python code
+MULTIARCH = 5
+# PREDEPENDS = 6 - No longer used by the python code
# - The C-code needs it for alignment reasons and still check it
#but ignore it if it is None (so keep it None).
-DEPENDS = 6
-CONFLICTS = 7
-PROVIDES = 8
-RDEPENDS = 9
-RCONFLICTS = 10
+DEPENDS = 7
+CONFLICTS = 8
+PROVIDES = 9
+RDEPENDS = 10
+RCONFLICTS = 11
class Britney(object):
@@ -546,6 +547,7 @@ class Britney(object):
pkg,
version,
get_field('Architecture'),
+get_field('Multi-Arch'),
None, # Pre-depends - leave as None for the C-code
deps,
', '.join(final_conflicts_list) or None,
@@ -1042,7 +1044,7 @@ class Britney(object):
binaries = self.binaries[suite][arch][0]
for pkg in binaries:
output = "Package: %s\n" % pkg
-for key, k in ((SECTION, 'Section'), (ARCHITECTURE,
'Architecture'), (SOURCE, 'Source'), (VERSION, 'Version'),
+for key, k in ((SECTION, 'Section'), (ARCHITECTURE,
'Architecture'), (MULTIARCH, 'Multi-Arch'), (SOURCE, 'Source'), (VERSION,
'Version'),
(DEPENDS, 'Depends'), (PROVIDES, 'Provides'),
(CONFLICTS, 'Conflicts')):
if not binaries[pkg][key]: continue
if key == SOURCE:
@@ -1138,12 +1140,19 @@ class Britney(object):
# for every package, version and operation in the block
for name, version, op in block:
+if ":" in name:
+name, archqual = name.split(":", 1)
+else:
+archqual = None
+
# look for the package in unstable
if name in binaries[0]:
package = binaries[0][name]
-# check the versioned dependency (if present)
+# check the versioned dependency and architecture qualifier
+# (if present)
if op == '' and version == '' or
apt_pkg.check_dep(package[VERSION], op, version):
-packages.append(name)
+if archqual is None or (archqual == 'any' and
package[MULTIARCH] == 'allowed'):
+packages.append(name)
# look for the package in the virtual packages list and loop on
them
for prov in binaries[1].get(name, []):
@@ -1151,7 +1160,9 @@ class Britney(object):
package = binaries[0][prov]
# A provides only satisfies an unversioned dependency
# (per Policy Manual §7.5)
-if op == '' and version == '':
+# A provides only satisfies a dependency without an
+# architecture qualifier (per analysis of apt code)
+if op == '' and version == '' and archqual is None:
packages.append(prov)
return (len(packages) > 0, packages)
=== modified file 'lib/britney-py.c'
--- lib/britney-py.c2012-10-22 12:43:51 +
+++ lib/britney-py.c2013-09-16 12:28:15 +
@@ -107,22 +107,28 @@ static PyObject *dpkgpackages_add_binary
pyString = PyList_GetItem(value, 5);
if (pyString == NULL) return NULL;
if (pyString != Py_None) {
+pkg->multiarch = PyString_AsString(pyString);
+} else pkg->multiarch = NULL;
+
+pyString = PyList_GetItem(value, 6);
+if (pyString == NULL) return NULL;
+if (pyString != Py_None) {
pkg->depends[0] = read_dep_andor(PyString_AsString(pyString));
} else pkg->depends[0] = NULL;
-pyString = PyList_GetItem(value, 6);
+pyString = PyList_GetItem(value, 7);
if (pyString == NULL) return NULL;
if (pyString != Py_N
Re: Please install /usr/bin/python2
On Sep 15, 2013, at 01:24 PM, anatoly techtonik wrote: >I mean that generally it is hard to say what problems people face when >trying to make the code running on both Python 3 and Python 2. My own >experience shows that testing both is very burdensome no matter if you >port app or start from scratch. Generally you should keep in mind all >differences between both languages and that alone already hard. YMMV of course, but the way I'd put it is that sometimes it's easy and sometimes it's damn near impossible. ;) If you're writing from scratch and target 2.7 and 3.3 (let's say) from the start, then I think it's generally not that hard, assuming of course your dependencies are available in both. Most, though not all, of the stdlib stuff that comes for free with 3.3 is available in some form or another in 2.7. Yes, you have to keep in mind the language differences, and maybe your code really requires some of the new features, but most code doesn't I suspect. Porting existing code can be harder, but often is not that difficult, and more and more popular code bases are getting ported all the time. If your favorite thing isn't available, write patches. These days, I think it's a black mark for an upstream to refuse good Python 3 porting patches. Most critical of all is: be clear in your bytes vs. strings model and you're probably closer to the "easy" side of the scale. -Barry -- 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/20130916100321.263801b8@anarchist
Re: How to help with sphinx 1.2?
* Dmitry Shachnev , 2013-09-14, 13:56: So that is the showstopper? I thought I've seen other Debian packages based on development releases, so I thought maybe b1 would have a chance of making it out of experimental... Yes, I don't like the idea of having beta releases in unstable. I don't like it either. Anyway, here's a list of bugs you might want to fix before uploading Sphinx 1.2 (beta or not) to unstable: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-modules-t...@lists.alioth.debian.org;tag=sphinx1.2 https://bitbucket.org/birkenfeld/sphinx/issue/1185 -- Jakub Wilk -- 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/20130916115151.ga6...@jwilk.net
Best Lifestyle Estate - Northern Suburbs
Your email program does not support HTML. To view an online version of this email, please click the link below. http://marketing.omnimatrix.co.za/new/en_send_preview_iframe2.aspx?SID=14&NewsletterID=552946&SiteID=46586&EmailID=23071270&HitID=1379312687868 To unsubscribe, click the link below. http://marketing.omnimatrix.co.za/RWCode/subscribe.asp?SID=14&SiteID=46586&Email=debian-python@lists.debian.org&HitID=1379312687868
Re: Please install /usr/bin/python2
On Mon, Sep 16, 2013 at 4:05 AM, Steve Langasek wrote: > On Sun, Sep 15, 2013 at 09:53:41PM +1000, Ben Finney wrote: >> Lachlan writes: > >> > i'm not an expert by any means but i fail to see how this is an issue? > >> In short: Debian is not the only Unix-like system where Python is >> installed, and consistency across operating systems is valuable. > > Yes, it is, which is what makes the Arch devs' change to make things > *inconsistent* by pointing /usr/bin/python to python3 an unforgivable > screwup. > > /usr/bin/python is an interface for python2. Having this change over time > to point to something incompatible, such as python3, is Evil Bad Wrong. We > are now in the situation that we have to ship /usr/bin/python2 for > compatibility with scripts originating from Arch, but that in no way implies > that /usr/bin/python should be changed to python3. Repurposing > /usr/bin/python should only happen following an intervening release in which > python2 is not shipped *at all*. > >> > -Everyone wrote scripts for python 2.x using /usr/bin/python > >> And eventually Python 2 will be long obsolete. > > And *once that happens*, we can discuss resurrecting /usr/bin/python and > pointing it to python3. It should not change until then. That's a wrong strategy. The scripts should be patched to use right version of Python, and they could not be patched until Debian doesn't provide right version for them, i.e. python2. >> > -With python3, scripts were written specifically for python3 using >> > /usr/bin/python3 > >> Not all of them, and the expectation is that more and more systems will >> assume “/usr/bin/python” is the current version of Python. > > Who expects that? Arch is negligible. Debian and Ubuntu are not going to > make this change. What other OSes are making the ill-conceived change to > /usr/bin/python? Windows never did the conversion. It just came natural for this 'poorly designed OS' to rewrite Python binaries with the latest installed. You could never expect to find Python of required version on this platform. Probably it was one of the reasons why virtualenv was born. >> See PEP 394 http://www.python.org/dev/peps/pep-0394/>. > > It's not the first or last time that an upstream has made a poor > recommendation that Debian rightly ignores. > > Enabling /usr/bin/python2 compatibility benefits our users, yes. Promoting > its use, or making /usr/bin/python incompatible with the many existing > scripts running on older Debian releases, does not. As a Python developer I couldn't care less for the "default Python" stuff as long as my scripts use proper shebang. python for 2/3 compatible stuff, python2 for 2.x only and python3 where needed. The Debian python policy should require that. This is an upstream recommendation that Debian wrongly didn't pay attention to, choosing to complain about inevitable natural processes instead. Take it easy. -- anatoly t. -- 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/CAPkN8x+s=t5BZZzZogGhEFux=5ixmzuckl9ay1uo6nntaab...@mail.gmail.com
