Re: Updated dh_python to satisfy everybody
* Joe Wreschnig ([EMAIL PROTECTED]) [060620 07:35]: > What does it mean? This thread more or less started when Raphael updated > dh_python to change behavior based on the presence/absence of the > Python-Standards-Version field -- exactly analogous to what debhelper's > compat levels are. Well, I just considered it a cool idea to be able to track not only the "normal" policy, but also subpolicies. It is not too important either. What we definitly need (and here I agree with you) is some switch for dh_py - and that switch should be in debian/something. Keeping the standards-version is IMHO still a good idea, but nothing I'm going to fight for (especially as the use case is not as large, but it's more like "cool idea, btw"). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated dh_python to satisfy everybody
Le mar 20 juin 2006 06:49, Andreas Barth a écrit : > * Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:35]: > > On Mon, 19 Jun 2006, Raphael Hertzog wrote: > > > - uses "XS-Python-Standards-Version: 0.4" as reference field > > > to run in new policy mode. The presence of XS-Python-Version will > > > also trigger the new policy mode (this is for short-term > > > compatibility, it may be removed in the not too-distant future). > > > > Joe proposed on IRC to use "debian/pycompat" instead of a new > > field. It sounds very much debhelper-ish and I like it. > > It depends what the field means. > For me, the Standards-Version was mainly a marker to say "this > package is compatible to Version x.y of the policy" - which allows > not only debhelper to work on it, but also to search for old packages > etc. > This is incompatbile with debian/pycompat (at least, if you want > to do it efficient). well thanks to the lintian lab, grepping for debian/pycompats or export DH_PYCOMPAT in debian/rules *is* fast. efficient I don't really know, but at least a list of the packages using an obsolete dh_pyton compat level is indeed easy to find. hence I do think it's a better idea than the XS-P-S-V. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpAEjCGEebZ9.pgp Description: PGP signature
Re: Updated dh_python to satisfy everybody
On Tue, 20 Jun 2006, Andreas Barth wrote: > * Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:35]: > > On Mon, 19 Jun 2006, Raphael Hertzog wrote: > > > - uses "XS-Python-Standards-Version: 0.4" as reference field to run > > > in new > > >policy mode. The presence of XS-Python-Version will also trigger > > > the new > > >policy mode (this is for short-term compatibility, it may be > > > removed in > > >the not too-distant future). > > > > Joe proposed on IRC to use "debian/pycompat" instead of a new field. It > > sounds very much debhelper-ish and I like it. > > It depends what the field means. It means "run dh_python in the following compatibility mode" and nothing more. > > Several people have concerns with this Python-Standards-Version field > > because it may have implications further than dh_python. This > > debian/pycompat would solve that. > > These people should bring up their concerns here. I'll summarize what I heard: - Having P-S-V clutters the debian/control file exactly like P-V does. - Having P-S-V would encourage further backwards incompatible changes to the python packaging because we created an official way to track them. - P-S-V would right now only be used as boolean for dh_python, which means it's an overengineered solution to the current problem I was trying to solve. 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: Updated dh_python to satisfy everybody
On Tue, 2006-06-20 at 07:27 +0200, Andreas Barth wrote: > * Joe Wreschnig ([EMAIL PROTECTED]) [060620 07:14]: > > On Tue, 2006-06-20 at 06:49 +0200, Andreas Barth wrote: > > > * Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:35]: > > > > On Mon, 19 Jun 2006, Raphael Hertzog wrote: > > > > > - uses "XS-Python-Standards-Version: 0.4" as reference field to > > > > > run in new > > > > >policy mode. The presence of XS-Python-Version will also > > > > > trigger the new > > > > >policy mode (this is for short-term compatibility, it may be > > > > > removed in > > > > >the not too-distant future). > > > > > > > > Joe proposed on IRC to use "debian/pycompat" instead of a new field. It > > > > sounds very much debhelper-ish and I like it. > > > > > > It depends what the field means. > > > > > > For me, the Standards-Version was mainly a marker to say "this package > > > is compatible to Version x.y of the policy" - which allows not only > > > debhelper to work on it, but also to search for old packages etc. This > > > is incompatbile with debian/pycompat (at least, if you want to do it > > > efficient). > > > > debhelper does not use Standards-Version for this purpose. It doesn't > > use it at all, as far as I know. debhelper uses a DH_COMPAT environment > > variable or debian/compat file. > > because there haven't been any such drastic changes in the normal policy > as we had in the python policy - and, compat means something *very* > different. What does it mean? This thread more or less started when Raphael updated dh_python to change behavior based on the presence/absence of the Python-Standards-Version field -- exactly analogous to what debhelper's compat levels are. If it was just a tool for the RMs to track the migration, I'd not have a problem with it[0], but the current proposal is that it actually affects the package build. That's bad, and at odds with the way the rest of debhelper (and all existing packaging tools) work. [0] Except for the fact it's useless, because the presence/absence of a XS-Python-Version tells the same thing. Which I said before. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Updated dh_python to satisfy everybody
* Joe Wreschnig ([EMAIL PROTECTED]) [060620 07:14]: > On Tue, 2006-06-20 at 06:49 +0200, Andreas Barth wrote: > > * Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:35]: > > > On Mon, 19 Jun 2006, Raphael Hertzog wrote: > > > > - uses "XS-Python-Standards-Version: 0.4" as reference field to > > > > run in new > > > >policy mode. The presence of XS-Python-Version will also trigger > > > > the new > > > >policy mode (this is for short-term compatibility, it may be > > > > removed in > > > >the not too-distant future). > > > > > > Joe proposed on IRC to use "debian/pycompat" instead of a new field. It > > > sounds very much debhelper-ish and I like it. > > > > It depends what the field means. > > > > For me, the Standards-Version was mainly a marker to say "this package > > is compatible to Version x.y of the policy" - which allows not only > > debhelper to work on it, but also to search for old packages etc. This > > is incompatbile with debian/pycompat (at least, if you want to do it > > efficient). > > debhelper does not use Standards-Version for this purpose. It doesn't > use it at all, as far as I know. debhelper uses a DH_COMPAT environment > variable or debian/compat file. because there haven't been any such drastic changes in the normal policy as we had in the python policy - and, compat means something *very* different. Perhaps there is reason to use even both fields, I'm not arguing against pycompat (and lots of your reasons are correct). > X-Python-Standards-Version tried to overload one with the other. That's > a recipe for disaster. Besides, eventually Python policy will be merged > into real policy (hah hah, right) and then the field will exist only to > give tool implementation details. I doubt it will be ever merged in. I expect it will be rather become a real subpolicy. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated dh_python to satisfy everybody
On Tue, 2006-06-20 at 06:49 +0200, Andreas Barth wrote: > * Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:35]: > > On Mon, 19 Jun 2006, Raphael Hertzog wrote: > > > - uses "XS-Python-Standards-Version: 0.4" as reference field to run > > > in new > > >policy mode. The presence of XS-Python-Version will also trigger > > > the new > > >policy mode (this is for short-term compatibility, it may be > > > removed in > > >the not too-distant future). > > > > Joe proposed on IRC to use "debian/pycompat" instead of a new field. It > > sounds very much debhelper-ish and I like it. > > It depends what the field means. > > For me, the Standards-Version was mainly a marker to say "this package > is compatible to Version x.y of the policy" - which allows not only > debhelper to work on it, but also to search for old packages etc. This > is incompatbile with debian/pycompat (at least, if you want to do it > efficient). debhelper does not use Standards-Version for this purpose. It doesn't use it at all, as far as I know. debhelper uses a DH_COMPAT environment variable or debian/compat file. Not complying with the latest policy is a bug, regardless of what Standards-Version is declared. Not using the latest debhelper features is not a bug, as long as the package follows policy. Two fields for different purposes. X-Python-Standards-Version tried to overload one with the other. That's a recipe for disaster. Besides, eventually Python policy will be merged into real policy (hah hah, right) and then the field will exist only to give tool implementation details. Using X-PSV also misses the criticism of X[BS]-Python-Version, which is that dpkg's database should not be used for packaging tools in such a fashion (I'm not saying I agree with it -- but that's what Joss has said about X-PSV, and the fact that the new Python policy required a patch to dpkg I think gives it some legitimacy). To get rid of one while adding the other is dumb. Pierre Habouzit, the developer who suggested X-PSV, has told me in private that he agrees with my criticism, and is surprised that Raphael went ahead with using it before any discussion on the matter (besides a brief criticism from me, on the list, about why his intended purpose would be pointless). -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Updated dh_python to satisfy everybody
* Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:35]: > On Mon, 19 Jun 2006, Raphael Hertzog wrote: > > - uses "XS-Python-Standards-Version: 0.4" as reference field to run in > > new > >policy mode. The presence of XS-Python-Version will also trigger the > > new > >policy mode (this is for short-term compatibility, it may be removed > > in > >the not too-distant future). > > Joe proposed on IRC to use "debian/pycompat" instead of a new field. It > sounds very much debhelper-ish and I like it. It depends what the field means. For me, the Standards-Version was mainly a marker to say "this package is compatible to Version x.y of the policy" - which allows not only debhelper to work on it, but also to search for old packages etc. This is incompatbile with debian/pycompat (at least, if you want to do it efficient). > Several people have concerns with this Python-Standards-Version field > because it may have implications further than dh_python. This > debian/pycompat would solve that. These people should bring up their concerns here. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated python-support
* Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:20]:
> On Mon, 19 Jun 2006, Matthias Klose wrote:
> > Raphael Hertzog writes:
> > > What Josselin is criticizing is the fact that python-central heavily
> > > relies on the P-V field, it looks it up in /var/lib/dpkg/status and also
> > > uses /var/lib/dpkg/info/package.list to find out files to byte-compile.
> > > This is usage of internal interfaces of dpkg and it's also normal that
> > > people are reserved on this.
> >
> > /var/lib/dpkg/info/package.list is not used.
>
> Just a remark, extract from pycentral:
> > #lines = [s[:-1] for s in file('/var/lib/dpkg/info/%s.list' %
> > self.name).readlines()]
> > cmd = ['/usr/bin/dpkg-query', '-L', self.name]
>
> So it's _no more_ used (it's commented out) but it relies on dpkg-query -L
> instead.
Which *is* an official interface. And, I don't see anything wrong to read
internal files in a very early development face. So, nothing bad about
pycentral.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More updates for the policy
* Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:02]: > On Mon, 19 Jun 2006, Andreas Barth wrote: > > > I only know two reasons for those headers: > > > - python-central use them for its internal work > > > - it may help track a transition and discover which packages need to be > > > updated > > > > > > BTW, the syntax of the Python-Version field comes directly from > > > python-central and it has not been discussed if the current syntax is the > > > best needed to achieve the second point. > > > > Obviously, nobody hit by the second purpose (which includes me) has any > > issue with the current syntax. Otherwise, I would have said something. > > You expressed concerns on the syntax on IRC. Because the "," means "or" in > somes > cases like "2.1, 2.2" and it means "and" in some other cases ">= 2.2, << 2.5". This was never a concern about the usability for the second purpose. > Also if the field describes the list of python versions that the package > can work with, then the "current" value has no meaning... current exists > only to let the maintainer build only for the current python version. > Which is orthogonal to the meaning of the field. current means something and IMHO it's at the right place. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning Python packages
* Joe Wreschnig <[EMAIL PROTECTED]> [2006-06-19 12:48:22 -0500]: > I've orphaned feedparser and the GStreamer Python bindings (the 0.8 and > I've also put python-mutagen up for adoption. I'm upstream for this > to a regression in Pygame/SDL) or quodlibet please let me know. I would be interested in adopting any or all of feedparser, python-mutagen, quodlibet. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature
Re: Updated dh_python to satisfy everybody
On Tue, Jun 20, 2006 at 01:34:35AM +0200, Raphael Hertzog wrote: > On Mon, 19 Jun 2006, Raphael Hertzog wrote: > > - uses "XS-Python-Standards-Version: 0.4" as reference field to run in new > >policy mode. The presence of XS-Python-Version will also trigger the new > >policy mode (this is for short-term compatibility, it may be removed in > >the not too-distant future). > > Joe proposed on IRC to use "debian/pycompat" instead of a new field. It > sounds very much debhelper-ish and I like it. > > What do others people think ? Sounds better then introducing P-S-V to me, so I agree fully. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated dh_python to satisfy everybody
On Mon, 19 Jun 2006, Raphael Hertzog wrote: > - uses "XS-Python-Standards-Version: 0.4" as reference field to run in > new >policy mode. The presence of XS-Python-Version will also trigger the > new >policy mode (this is for short-term compatibility, it may be removed in >the not too-distant future). Joe proposed on IRC to use "debian/pycompat" instead of a new field. It sounds very much debhelper-ish and I like it. What do others people think ? Several people have concerns with this Python-Standards-Version field because it may have implications further than dh_python. This debian/pycompat would solve that. 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: Updated python-support
On Mon, 19 Jun 2006, Matthias Klose wrote:
> Raphael Hertzog writes:
> > What Josselin is criticizing is the fact that python-central heavily
> > relies on the P-V field, it looks it up in /var/lib/dpkg/status and also
> > uses /var/lib/dpkg/info/package.list to find out files to byte-compile.
> > This is usage of internal interfaces of dpkg and it's also normal that
> > people are reserved on this.
>
> /var/lib/dpkg/info/package.list is not used.
Just a remark, extract from pycentral:
> #lines = [s[:-1] for s in file('/var/lib/dpkg/info/%s.list' %
> self.name).readlines()]
> cmd = ['/usr/bin/dpkg-query', '-L', self.name]
So it's _no more_ used (it's commented out) but it relies on dpkg-query -L
instead.
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: More updates for the policy
On Mon, 19 Jun 2006, Andreas Barth wrote: > My impression was that we *did* a decision how to handle the > meta-information, and just didn't decide about the implementation. You can review the video of the BoF but I don't have time for that. > > common denominator that I have found on which both parties could agree. > > A Standards-Version-Header is definitly a good idea, I agree on that. Good. > However, I'd really like to see more information in the control-part - > like we see e.g. the maintainer or build-dependencies listed there > (without the real technical need, all that could be extracted from > debian/control as well). Then please ask people to use XS-Python-Version and XS-Python-Standards-Versions together. And over time, if it has technical merits, it will win. Today, you can perfectly use the new python-support with the X[SB]s-Python-Version fields but you can also use it without. > > I only know two reasons for those headers: > > - python-central use them for its internal work > > - it may help track a transition and discover which packages need to be > > updated > > > > BTW, the syntax of the Python-Version field comes directly from > > python-central and it has not been discussed if the current syntax is the > > best needed to achieve the second point. > > Obviously, nobody hit by the second purpose (which includes me) has any > issue with the current syntax. Otherwise, I would have said something. You expressed concerns on the syntax on IRC. Because the "," means "or" in somes cases like "2.1, 2.2" and it means "and" in some other cases ">= 2.2, << 2.5". Also if the field describes the list of python versions that the package can work with, then the "current" value has no meaning... current exists only to let the maintainer build only for the current python version. Which is orthogonal to the meaning of the field. > > I can easily find out packages which need to be updated for a python > > transition by looking for packages with a dependency "python (<< 2.X)". > > not necessarily, if we e.g. just add a new python suite - i.e. at the > start of a transition. Also, sometimes one wants to check what problems > will occur without doing the transition at the same time. Well, you're confused if I have "python (<< 2.5)" it means the package won't work with python2.5 right now and also that the extension (for arch: any packages) has not yet been compiled for python2.5. 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: More updates for the policy
On Mon, 19 Jun 2006, Floris Bruynooghe wrote: > On Mon, Jun 19, 2006 at 09:07:00PM +0200, Raphael Hertzog wrote: > > BTW, the syntax of the Python-Version field comes directly from > > python-central and it has not been discussed if the current syntax is the > > best needed to achieve the second point. > > This is a valid point. But if it is found to be a concern/problem and > there are good reasons to change it I'm sure that could be done. No because if you change the syntax, you will break packages using python-central... ie once python-central has been released within a stable release it will be almost impossible to change the syntax. Cheers, PS: Thanks for joining the discussion, we really need more opinions and fresh blood. :) -- 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: Updated dh_python to satisfy everybody
On Mon, 19 Jun 2006, Raphael Hertzog wrote:
> - pyversions needs to be modified to not fail if the field
> XS-Python-Version is not present. He should in that case
> use the information of the debian/pyversions file. I will
> hopefully soon provide a patch for this.
Here's a patch and the resulting pyversions script. For packages not using
XS-Python-Version, they can do "pyversions -r debian/pyversions" and get
the list of python packages to build with.
Matthias, I'd be glad if you could update the pyversions script with this
patch.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
=== modified file 'pyversions'
--- pyversions
+++ pyversions
@@ -116,6 +116,36 @@
else:
return ['python%s' % v for v in versions]
+def version_cmp(ver1,ver2):
+v1=[int(i) for i in ver1.split('.')]
+v2=[int(i) for i in ver2.split('.')]
+return cmp(v1,v2)
+
+def requested_versions_bis(vstring, version_only=False):
+versions = []
+py_supported_short = supported_versions(version_only=True)
+for item in vstring.split(','):
+v=item.split('-')
+if len(v)>1:
+if not v[0]:
+v[0] = py_supported_short[0]
+if not v[1]:
+v[1] = py_supported_short[-1]
+for ver in py_supported_short:
+try:
+if version_cmp(ver,v[0]) >= 0 and version_cmp(ver,v[1]) <=
0:
+versions.append(ver)
+except ValueError:
+pass
+else:
+if v[0] in py_supported_short:
+versions.append(v[0])
+versions.sort(version_cmp)
+if not version_only:
+versions=['python'+i for i in versions]
+return versions
+
+
def installed_versions(version_only=False):
import glob
supported = supported_versions()
@@ -192,10 +222,16 @@
elif opts.versions:
try:
if os.path.isfile(opts.versions):
-vs = extract_pyversion_attribute(opts.versions, 'Source')
+if opts.versions.find("pyversions") != -1:
+# Special case for dh_python "only" compatibility
+vs = file(opts.versions).readline().rstrip('\n');
+print ' '.join(requested_versions_bis(vs,
opts.version_only))
+else:
+vs = extract_pyversion_attribute(opts.versions, 'Source')
+print ' '.join(requested_versions(vs, opts.version_only))
else:
vs = opts.versions
-print ' '.join(requested_versions(vs, opts.version_only))
+print ' '.join(requested_versions(vs, opts.version_only))
except ValueError, msg:
print "%s: %s" % (program, msg)
sys.exit(1)
#! /usr/bin/python
import os, re, sys
try:
SetType = set
except NameError:
import sets
SetType = sets.Set
set = sets.Set
def parse_versions(vstring):
import operator
operators = { None: operator.eq, '=': operator.eq,
'>=': operator.ge, '<=': operator.le,
'<<': operator.lt
}
vinfo = {}
exact_versions = set([])
version_range = set(supported_versions(version_only=True))
relop_seen = False
for field in vstring.split(','):
field = field.strip()
if field == 'all':
vinfo['all'] = 'all'
continue
if field in ('current', 'current_ext'):
vinfo['current'] = field
continue
vinfo.setdefault('versions', set())
ve = re.compile('(>=|<=|<<|=)? *(\d\.\d)$')
m = ve.match(field)
try:
op, v = m.group(1), m.group(2)
if op in (None, '='):
exact_versions.add(v)
else:
relop_seen = True
filtop = operators[op]
version_range = [av for av in version_range if filtop(av ,v)]
except Exception:
raise ValueError, 'error parsing Python-Version attribute'
if 'versions' in vinfo:
vinfo['versions'] = exact_versions
if relop_seen:
vinfo['versions'] = exact_versions.union(version_range)
return vinfo
_supported_versions = None
def supported_versions(version_only=False):
global _supported_versions
if not _supported_versions:
if os.path.exists('/usr/share/python/debian_defaults'):
from ConfigParser import SafeConfigParser
config = SafeConfigParser()
config.readfp(file('/usr/share/python/debian_defaults'))
value = config.get('DEFAULT', 'supported-versions')
_supported_versions = [s.strip() for s in value.split(',')]
else:
cmd = ['/usr/bin/apt-cache', '--no-all-versions',
'show', 'python-all']
try:
import subprocess
p = subprocess
Re: More updates for the policy
On Mon, Jun 19, 2006 at 09:07:00PM +0200, Raphael Hertzog wrote: > BTW, the syntax of the Python-Version field comes directly from > python-central and it has not been discussed if the current syntax is the > best needed to achieve the second point. This is a valid point. But if it is found to be a concern/problem and there are good reasons to change it I'm sure that could be done. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Quick poll on what's best
On Mon, Jun 19, 2006 at 12:31:25PM -0500, Joe Wreschnig wrote: > On Mon, 2006-06-19 at 19:24 +0200, Raphael Hertzog wrote: > > Hello, > > > > as you may have read in the previous mail, the latest dh_python uses > > a "debian/pyversions" file to find out the Python versions that the > > packages supports but uses as fallback the XS-Python-Version field in > > order to not break compatibility with packages that have already been > > updated. > > > > For that I've written code in dh_python that re-creates the content of > > debian/pyversions from the XS-Python-Version field. However it's now quite > > clear that this XS-Python-Version field is only essential for > > python-central and as such keeping that compatbility code inside dh_python > > may be breaking the rule that dh_python tries to be agnostic (and which is > > the wish of Joey Hess also). > > So you're removing one of the control fields while adding yet another > one in your previous mail? I must concur, this is a radical change in the approach. Also it seems to undo the reason for taking out the X?-Python-Version fields. I don't quite understand why the X?-Python-Version fields first get agreed on by everyone at debconf and then they get removed again. AIUI there is a need for database somewhere that knows what Python versions a Python package can cope with. This means that as a (new) python version gets installed or removed a helper tool can make this available to this new version including byte-compiling (or delete the byte-compiled and symlinks to modules (the way current implementations are done) stuff). For extensions a bin-NMU would be required when a new Python version gets introduced and the rest would also be done by the helper tool. Once that is done a transition of the default Python version comes almost for free. Am I correct in assuming the above is what everyone agrees with or tries to achieve? (I know it's only a rough outline) So the discussion is whether to keep the version information of a package in it's control file (and thus dpkg's database) or inside the helper tools' module storage directory. I have never seen a list of the pro's and con's of these two databases for supported python versions (which this entire debate seems to be centred about), so here my attempt: /var/lib/dpkg/status: + Independent of helper tool. + All python version info easily found (grep-dctrl). + Natural place to describe package dependencies (IMHO) - Clutters dpkg database. - Is claimed to be fragile (why??) - Uses internal dpkg interface (which is already said not to be true). /usr/lib///.version: + Does not influence dpkg at all. - Scatters version information about. - Hides the information in the helper tool directory. IMHO it looks like using the X?-Python-Version headers in dpkg's database is better. This also makes the X-Python-Policy-Version header obsolete. I'm not sure why that came in, seems not needed and no one was asking for it. The only reason why I see it being used is for dh_python to detect a new-policy package. The debhelper 5.0.37.1 way of doing was better IMHO. The final difference between python-central and python-support seems to be where they keep the byte-compiled modules. This seems to be mostly a matter of taste, but I think many troubles (involving mainly new users and upstream again being annoyed at Debian for doing things so much different cf. python-dev) can be avoided by sticking to the standard python path (as Pycentral does) and not hide the files in /var like Pysupport. Strictly speaking the (byte-compiled) modules are not variable data after all. And during an install/remove /usr needs to be writable anyway. Floris (hoping for a fruitful discussion and not too much rushing about with code until a consensus is reached, this rushing about seems to cause more harm then it does good currently.) -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More updates for the policy
* Raphael Hertzog ([EMAIL PROTECTED]) [060619 21:08]: > On Mon, 19 Jun 2006, Andreas Barth wrote: > > We shouldn't have two vastly different ways to do it. > > Life would be best if we had already taken a decision... we know this but it > is > not going to happen until we have more experience with both python-central and > python-support. My impression was that we *did* a decision how to handle the meta-information, and just didn't decide about the implementation. > The common part is quite clear: > - everything in one python-foo > - the dependencies that have to be generated > > The new field is not part of the common part. For technical reasons, we > have to find a way to differentiate clearly between new policy and old > policy and for this the best approach suggested is the idea of Pierre > Habouzit, a Standards-Version field dedicated to Python. It's the smallest > common denominator that I have found on which both parties could agree. A Standards-Version-Header is definitly a good idea, I agree on that. However, I'd really like to see more information in the control-part - like we see e.g. the maintainer or build-dependencies listed there (without the real technical need, all that could be extracted from debian/control as well). > I only know two reasons for those headers: > - python-central use them for its internal work > - it may help track a transition and discover which packages need to be > updated > > BTW, the syntax of the Python-Version field comes directly from > python-central and it has not been discussed if the current syntax is the > best needed to achieve the second point. Obviously, nobody hit by the second purpose (which includes me) has any issue with the current syntax. Otherwise, I would have said something. > I can easily find out packages which need to be updated for a python > transition by looking for packages with a dependency "python (<< 2.X)". not necessarily, if we e.g. just add a new python suite - i.e. at the start of a transition. Also, sometimes one wants to check what problems will occur without doing the transition at the same time. You could equally well argue that we don't need build-dependencies listed - anybody who wants to build a package will need to download source anyways, and will find out. Neverthelesse, they have proven to be quite successfull. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning Python packages
* Joe Wreschnig ([EMAIL PROTECTED]) [060619 19:47]: > The Python policy SGML document is available at > http://people.debian.org/~piman/python-policy, I suggest someone with > more patience adopts it and finds a new canonical home for it. Please > give the first bullet point in the "Upgrade Procedure" checklist careful > thought before you decide to take this on. I decided to adopt this document. I'll hope to give it a living on the usual policy place soon enough - until that, it lives at http://people.debian.org/~aba/python-policy/ Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated python-support
* Josselin Mouette ([EMAIL PROTECTED]) [060619 13:49]: > Le lundi 19 juin 2006 à 13:28 +0200, Andreas Barth a écrit : > > > Calling /bin/false doesn't entirely break the system. > > > > It seems that you are unaware with the way dpkg works. If a package's > > postinst fails, the package is marked is unconfigured. Any dependent > > packages are also not configured after that. > > > > This is what happend, and this is what would happen with /bin/false as > > postinst also. > > This is not what happened. This is what happened technically. And as you couldn't understand that, I offered some in-sight explanaitions. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Quick poll on what's best
On Mon, 19 Jun 2006, Joe Wreschnig wrote: > So you're removing one of the control fields while adding yet another > one in your previous mail? I'm not removing it... I'm transfering responsibility of that field to python-central. I want dh_python to be used by everybody so that we have sane and consistent dependencies across the distribution. dh_python would not have been used by everybody if I kept its dependency on that XS-Python-Version field. So I looked for a new common denominator that could be used to know which policy version to follow and the nicest solution that I have found is the Python-Standards-Version field proposed recently. 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: More updates for the policy
Hi Andy, On Mon, 19 Jun 2006, Andreas Barth wrote: > We shouldn't have two vastly different ways to do it. Life would be best if we had already taken a decision... we know this but it is not going to happen until we have more experience with both python-central and python-support. > Either, XS-Python-Version is the right thing. Than it should be in > policy. > > Or there is another good mechanismn. Then it shouldn't be in policy. Policy should document usage. Right now we're starting to use python-central and python-support and we don't know which approach is best. So the policy shouldn't favor either approach but rather document what's common between both approaches. The common part is quite clear: - everything in one python-foo - the dependencies that have to be generated The new field is not part of the common part. For technical reasons, we have to find a way to differentiate clearly between new policy and old policy and for this the best approach suggested is the idea of Pierre Habouzit, a Standards-Version field dedicated to Python. It's the smallest common denominator that I have found on which both parties could agree. > The new dak headers were explicitly mentioned in Mexico, and there was > more than one reason to add them. What are those reasons? I only know two reasons for those headers: - python-central use them for its internal work - it may help track a transition and discover which packages need to be updated BTW, the syntax of the Python-Version field comes directly from python-central and it has not been discussed if the current syntax is the best needed to achieve the second point. I can easily find out packages which need to be updated for a python transition by looking for packages with a dependency "python (<< 2.X)". > If we want to drop them again, we really should discuss > them here, and speak about the reasons we had in Mexico to accept them. I welcome discussion as always. > And, I don't think that "they're no more required" right now - just > dh_python could live without them. And I really want further discussions > before jumping to conclusions. Right, and the dh_python change doesn't forbid maintainer to continue using XS-Python-Version as it will continue to work without problem. That's why I'll go forward with the change and we'll have more time for discussing what we want in the long term. 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: Orphaning Python packages
Hello Joe. I could be interested about adopting feedparser since I use it in a couple programs. Bad news are that I'm a really new mantainer and could need some initial help (no problem about looking for a sponsor). If you have no problems about that I'll adopt it and start working on it tonight. On Mon, 19 Jun 2006 12:48:22 -0500, Joe Wreschnig <[EMAIL PROTECTED]> wrote: > > I've orphaned feedparser and the GStreamer Python bindings (the 0.8 and > 0.10 versions). These are used by several packages, and so I hope > someone adopts them. feedparser is a pretty easy package, the GStreamer > ones aren't. I'm willing to answer questions about the packages (and > help whoever adopts the later with GStreamer in general) but I won't > sponsor uploads. -- --- Carlos Galisteo Jabber_Id::cgalisteo en jabber.org PGP_key::http://k-rolus.net/~cgalisteo/cgalisteo.gpg Key_Fingerprint::F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65 --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python2.4 packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc Dequènes (Duck) wrote: > Ron Johnson <[EMAIL PROTECTED]> writes: > >> python-flup is not an official package (yet?), so what's wrong >> with giving a bit of an ad-hoc work-around? > > Because we'll see again a young maintainer giving such advice to > his bugreporter like if it was a real solution in a proper Debian > system. > > So please help fixing the packaging instead of spreading such bad > knowledge. It was my original impression that he was a "regular user" having trouble with a non-standard package. That's why I gave such advice. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEluU2S9HxQb37XmcRAk6SAKCnIz1/uw6XyN1P+gwi7xUeSwKTRACeIbSv 6HUU+2gFluJXmfIuNe9vwmY= =VmJq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Orphaning Python packages
Hi everyone, I am no longer going to be involved in Python module packaging. I've orphaned feedparser and the GStreamer Python bindings (the 0.8 and 0.10 versions). These are used by several packages, and so I hope someone adopts them. feedparser is a pretty easy package, the GStreamer ones aren't. I'm willing to answer questions about the packages (and help whoever adopts the later with GStreamer in general) but I won't sponsor uploads. I've also put python-mutagen up for adoption. I'm upstream for this module, and intend to continue developing it. It's a simple package using distutils. If you're interested in maintaining it, let me know. I've not yet orphaned my Python applications. I may in the future; if you are interested in pydance (which doesn't run right now anyway, due to a regression in Pygame/SDL) or quodlibet please let me know. The Python policy SGML document is available at http://people.debian.org/~piman/python-policy, I suggest someone with more patience adopts it and finds a new canonical home for it. Please give the first bullet point in the "Upgrade Procedure" checklist careful thought before you decide to take this on. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: More updates for the policy
* Raphael Hertzog ([EMAIL PROTECTED]) [060619 19:31]: > a last remark/discussion. Given that the XS-Python-Version field is no > more required, I think it shouldn't be mentionned as part of the official > policy but only as example on how to implement the policy with the help of > python-central. > > I will update the wiki page as soon as the updated packages > reach unstable: http://wiki.debian.org/DebianPython/NewPolicy Sorry, but I really disagree very much. We shouldn't have two vastly different ways to do it. Either, XS-Python-Version is the right thing. Than it should be in policy. Or there is another good mechanismn. Then it shouldn't be in policy. But - it should be uniform across source packages. The new dak headers were explicitly mentioned in Mexico, and there was more than one reason to add them. If we want to drop them again, we really should discuss them here, and speak about the reasons we had in Mexico to accept them. And, I don't think that "they're no more required" right now - just dh_python could live without them. And I really want further discussions before jumping to conclusions. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
More updates for the policy
Hello, a last remark/discussion. Given that the XS-Python-Version field is no more required, I think it shouldn't be mentionned as part of the official policy but only as example on how to implement the policy with the help of python-central. I will update the wiki page as soon as the updated packages reach unstable: http://wiki.debian.org/DebianPython/NewPolicy 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: Quick poll on what's best
On Mon, 2006-06-19 at 19:24 +0200, Raphael Hertzog wrote: > Hello, > > as you may have read in the previous mail, the latest dh_python uses > a "debian/pyversions" file to find out the Python versions that the > packages supports but uses as fallback the XS-Python-Version field in > order to not break compatibility with packages that have already been > updated. > > For that I've written code in dh_python that re-creates the content of > debian/pyversions from the XS-Python-Version field. However it's now quite > clear that this XS-Python-Version field is only essential for > python-central and as such keeping that compatbility code inside dh_python > may be breaking the rule that dh_python tries to be agnostic (and which is > the wish of Joey Hess also). So you're removing one of the control fields while adding yet another one in your previous mail? No thanks, I'm done with this stupidity. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Updated dh_python to satisfy everybody
Coin, Raphael Hertzog <[EMAIL PROTECTED]> writes: > What still needs to be done: > - pyversions needs to be modified to not fail if the field > XS-Python-Version is not present. He should in that case > use the information of the debian/pyversions file. I will > hopefully soon provide a patch for this. > - all those changes need to be uploaded (tomorrow should be doable) And the CDBS class is updated and currently being tested. -- Marc Dequènes (Duck) pgpQWI1qUXQP3.pgp Description: PGP signature
Re: Python2.4 packages
Ron Johnson <[EMAIL PROTECTED]> writes: > python-flup is not an official package (yet?), so what's wrong with > giving a bit of an ad-hoc work-around? Because we'll see again a young maintainer giving such advice to his bugreporter like if it was a real solution in a proper Debian system. So please help fixing the packaging instead of spreading such bad knowledge. -- Marc Dequènes (Duck) pgpZM1p5jtCvB.pgp Description: PGP signature
Quick poll on what's best
Hello, as you may have read in the previous mail, the latest dh_python uses a "debian/pyversions" file to find out the Python versions that the packages supports but uses as fallback the XS-Python-Version field in order to not break compatibility with packages that have already been updated. For that I've written code in dh_python that re-creates the content of debian/pyversions from the XS-Python-Version field. However it's now quite clear that this XS-Python-Version field is only essential for python-central and as such keeping that compatbility code inside dh_python may be breaking the rule that dh_python tries to be agnostic (and which is the wish of Joey Hess also). So I wonder if I should move that code from dh_python to dh_pycentral and make dh_pycentral create the debian/pyversions file that would then be used by dh_python as external input. What do you think, would you do that or would you keep it in dh_python? 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]
Updated dh_python to satisfy everybody
Hi all,
given that nobody complained to my proposal of last evening, I went ahead
and implemented it.
I've updated dh_python (and the upcoming debhelper NMU 5.0.37.2) here:
http://people.debian.org/~hertzog/python/
Here's what has changed in this dh_python (taken from my debhelper
changelog):
* Update of dh_pyhton
- vastly refactored, easier to understand, and the difference
between old policy and new policy is easier to grasp
- it supports an -X option which can be used to not scan some files
- uses debian/pyversions as reference source of information for
dependencies but also parse the XS-Python-Version header as fallback.
- ${python:Versions}'s default value is XS-Python-Version's value
instead of "all" when the package doesn't depend on a
specific python version. Closes: #373853
- always generate ${python:Provides} and leave the responsibility to the
maintainer to not use ${python:Provides} if he doesn't want the
provides.
- uses "XS-Python-Standards-Version: 0.4" as reference field to run in new
policy mode. The presence of XS-Python-Version will also trigger the new
policy mode (this is for short-term compatibility, it may be removed in
the not too-distant future).
This means that the have to change the current text of the policy to enforce the
use of the "X-Python-Standards-Version" field. This field must contain the
version of the python policy that the package respects, and the current
version is "0.4".
Joe, can you do that please? I already documented that on the wiki page.
If you have that field, then dh_python can work without XS-Python-Version.
However if the field is present, it will still be used.
Joss is satisfied with this compromise and has updated his dh_pysupport
script to not mess with the dependencies and you can find the updated
package here:
http://malsain.org/~joss/deb/
What still needs to be done:
- pyversions needs to be modified to not fail if the field
XS-Python-Version is not present. He should in that case
use the information of the debian/pyversions file. I will
hopefully soon provide a patch for this.
- all those changes need to be uploaded (tomorrow should be doable)
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]
[Announce] stdeb - Python to Debian source package conversion utility
I would like to announce the initial public release of stdeb, which may
be found at http://stdeb.python-hosting.com/ . I send this email to the
debian-python list with a little hesitation because I know this utility
does not (yet) produce Debian source packages that adhere to Python
Python policy. However, I hope that people here will appreciate the
usefulness of such a tool and might help make it produce such packages.
The rest of this email is copied directly from the project web-page.
stdeb - Python to Debian source package conversion utility
==
stdeb_ ("setuptools debian") produces Debian source packages from
Python packages via a new distutils command, ``sdist_dsc``, which
produces a Debian source package of a Python package. Automatic
defaults are provided for the Debian package, but many aspects of the
resulting package can be customized via a configuration file.
.. _stdeb: http://stdeb.python-hosting.com/
News
2006-06-19: Version 0.1 Released. See the `download page`_.
Invocation
--
All methods eventually result in a call to the ``sdist_dsc`` distutils
command. You may prefer to do so directly::
python -c "import stdeb; execfile('setup.py')" sdist_dsc
Alternatively, two scripts are provided::
stdeb_run_setup [options] # calls "python setup.py sdist_dsc [options]"
py2dsc [options] mypackage-0.1.tar.gz # uses pre-built Python source
package
In all cases, a Debian source package is produced from unmodified
Python packages. The following files are produced:
* ``packagename_versionname.orig.tar.gz``
* ``packagename_versionname-debianversion.dsc``
* ``packagename_versionname-debianversion.diff.gz``
These can then be compiled into binary packages using the standard
Debian machinery (e.g. dpkg-buildpackage).
Download
Files are available at the `download page`_.
.. _download page: http://stdeb.python-hosting.com/wiki/Download
The subversion repository is available at
https://svn.stdeb.python-hosting.com/trunk
Background
--
For the average Python package, its source distribution
(python_package.tar.gz created with ``python setup.py sdist``)
contains nearly everything necessary to make a Debian source
package. This near-equivalence encouraged me to write this little
distutils extension, which executes the setup.py file to extract
relevant information. This process is made significantly easier
through the use of setuptools_.
.. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
setuptools is used because of the opportunities it provides, although
many of these features are currently un(der)-utilized. For example,
setuptools could make the job of "Debianizing" python console and gui
scripts much easier.
I wrote this initially to Debianize several Python packages of my own,
but I have the feeling it could be generally useful. It appears
similar, at least in theory, to easydeb_ and `Logilab's Devtools`_.
.. _easydeb: http://easy-deb.sourceforge.net/
.. _Logilab's DevTools: http://www.logilab.org/projects/devtools
Prerequisites
-
* Python_ 2.3 or greater
* setuptools_
* subprocess.py_ (included with Python 2.4, backwards compatible with
Python 2.3)
.. _Python: http://www.python.org/
.. _subprocess.py:
http://svn.python.org/view/python/trunk/Lib/subprocess.py?rev=46651&view=log
Customizing the produced Debian source package
--
stdeb will attempt to provide reasonable defaults, but these are only
guesses.
To customize the Debian source package produced, you may write config
files of the format understood by ConfigParser_. When building each
package, stdeb looks for the existance of a ``stdeb.cfg`` file in the
``.egg-info`` directory. You may specify an additional config file
with the command-line option --extra-cfg-file.
.. _ConfigParser: http://docs.python.org/lib/module-ConfigParser.html
Here's an example .cfg file which builds several packages::
[DEFAULT]
Debian-Version: 0ads1
[setuptools]
Source: python-setuptools
[numpy]
Source: python-numpy
Upstream-Version-Prefix: 0.9.8+
Build-Depends: python-dev, refblas3-dev, lapack3-dev
Build-Conflicts: atlas3-base, atlas3-base-dev
[matplotlib]
# matplotlib doesn't incorporate its SVN version number into
sdist-built tarballs.
# Therefore, if building the SVN version, substitute the version into the
# "Upstream-Version-Suffix" variable and use py2dsc.
# (For some reason, "debuild -sa" won't build matplotlib because tk.h
isn't found.)
Source: python-matplotlib
Upstream-Version-Suffix: .dev2500
Build-Depends: python-dev, python-numpy, python-numarray,
python-numeric, python-gtk2-dev, tk8.4-dev, libwxgtk2.4-dev
Depends: python-gtk2, python-numpy, python-numeric, python-numarray
Suggests: gs-gpl
[scipy]
Source: python-scipy
Upstream-Version-Prefix: 0.4.9+
Build-Depends: python-numpy
Depends: python-numpy
.. _numpy: http://scipy.org/NumPy
Using stdeb
Re: Python2.4 packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc Dequènes (Duck) wrote: > Coin, > > Ron Johnson <[EMAIL PROTECTED]> writes: > >> Making a symlink from python2.4 to python would probably do the >> trick. > > Are you root of the world and gonna do this ugly hack on every > computer on earth ??? > > Now please stop with the python symlinks, this has no common > sense ; you're giving bad ideas to users. On my Sid system: $ apt-cache search flup $ python-flup is not an official package (yet?), so what's wrong with giving a bit of an ad-hoc work-around? - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElsHtS9HxQb37XmcRAi0GAJ0Qoo1i19bnh3jr06V4TD0q9b6ICgCcDZDJ Ixo8uRjADjJj34mXNg6gMRs= =4Gdu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: New webpy for sponsored upload]
On Mon, Jun 19, 2006 at 04:13:52PM +0900, Kai Hendry wrote: > I am a little wary of the new lintian error rule to build depend on > python-all-dev|python-dev|python > > What should I be using in my package's case? Could someone clarify. I > have read the new policy, though perhaps I missed something. >From what I can see you need to build-depend on python-all (>= 2.3.5-10) as is explained in point 9 on w.d.o/DebianPython/NewPolicy under "Updating your packages". Unfortunately this will give you the lintian error which I think may need to be updated. You could avoid it by build depending on python-all, python. But ignoring it for now seems acceptable. Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated python-support
Raphael Hertzog writes: > Indeed but the number of postinst failures due to python-central have been > quite high recently. python-central is quite new and nobody helped > doko to test it... so it's self-evident that we would run into some > problems while it matures. doko has been very responsive in fixing > problems, so it wasn't that bad. > > What Josselin is criticizing is the fact that python-central heavily > relies on the P-V field, it looks it up in /var/lib/dpkg/status and also > uses /var/lib/dpkg/info/package.list to find out files to byte-compile. > This is usage of internal interfaces of dpkg and it's also normal that > people are reserved on this. /var/lib/dpkg/info/package.list is not used. According to the dpkg maintainers, /var/lib/dpkg/status is public enough to be used. tools like grep-dctrl use this file as well. So python-central does not use any internal interface for package installation and removal; /var/lib/dpkg/status is only used for runtime installation, removal and upgrade. software which doesn't get used is slightly less tested. Even the claim that python-support is well tested is fragile. See #373753. That's no ranting, both packages certainly contain more bugs. > > WTF? We discussed that in Mexico, we agreed on that in Mexico, and now > > you tell us that you just decided by yourself you don't want to follow > > the new policy any more? Is there any serious reason for it, or do you > > just feel like it? > > That field is only a part of the new policy, most of it stays the same and > the important part concerning the packaging still applies. > > Joss doesn't feel like using that field because it clutters the database, > and introduces unnecessary complexities in several places. The field doesn't serve the package maintainer alone; it helps RM to identify packages which need to be transitioned, to identify packages which need to be rebuilt for dropped or added runtimes. python-support doesn't need to use the field. I fail to see, how the simple presence of the field introduces "unnecessary complexities in several places" for python support, if python-support ignores it and dh_python manages the field. The field is not "python-central only"; python-central is one user, the other usage is getting information about the packages without looking at the contents of the package itself. I tried to explain why the dpkg database is the primary place to store the meta information. We certainly did clutter the database with the pythonX.Y packages. I really do not consider these extra 30bytes per package in favour of dropping 2/3 of the current python module and extension packages as clutter. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated python-support
Andreas Barth <[EMAIL PROTECTED]> writes: > Can't we have both? Actually, I think a policy is quite an important > tool because it shows definitly what one can expect from a package. Of > course, policy can be changed, but just ignoring policy is only breaking > expectations. And if you want to change policy, I'd rather expect a mail > like "proposed change to the python policy", then just breaking policy > in one of your packages (this is BTW the difference between changing > policy and breaking it). Please stop, there is no Python policy, even the Developer's page says it is a "proposed subpolicy", and currently it is still a draft. A policy is good when it enforces proper packaging decisions while leaving implementations free in what is not covered wy the policy. So please let us finish good and working technical solutions before freezing everything and calling it a "policy". During our work on tools we discovered many problems which resulted in huge changes of the draft, so the work on the draft would be finished when we are sure of what to enforce on all cases. Moreover, the policy should not enforce usage of a technical solution, this would break the competition between the two implementations. -- Marc Dequènes (Duck) pgpx4I9KUMzrN.pgp Description: PGP signature
Re: Updated python-support
Andreas Barth <[EMAIL PROTECTED]> writes: > I'm always all for improving things. I just don't see it as right > solution to break stuff and expectations. If one wants to improve > policy, IMHO the way to go is to send out a mail like "possible > improvements to policy". (And, BTW, I *definitly* don't like to repeat a > discussion we already had at debconf - I'm a strong believer in the "each > discussion only once"-approach. :) As the DebConf dicussion did not gathered all python maintainers, and as no real report of your discussion was dropped here, and as you are considering such discussions closed subjects while other python maintainers may wish to comment on, and as piman had so much pain to get information out of the participants, all you said here *IS* null, and the policy cannot be considered approved yet. I'm waiting for joss and buxy, which are in the way of solving all this correctly. As dh_python generated bad dependencies, and the first upload of the new cdbs class had mistakes too, we should consider a new start of the transition as soon as fixed tools are uploaded. -- Marc Dequènes (Duck) pgpvyJolBIlsl.pgp Description: PGP signature
Re: Updated python-support
On Mon, 19 Jun 2006, Andreas Barth wrote: > > * Automatic dependency generation in dh_pysupport, removing the > > need to run dh_python. > > You mean, this change breaks compatibility with the previous versions of > python-support? I strongly recommend to not make such a change. Joss agrees that dh_python should be responsible for the dependencies, we just need to find a common ground on how to do it. I posted my analysis and my proposal already. > > The last change is a source of strong disagreement between Raphaël and > > myself. Having seen the result of messing up with dpkg's database and > > control fields [0,1], > > Eh, I'm sure you can explain where somebody messed up with dpkg's > database? What you can see is "only" that some programs postinst failed > to run successfully. You can get the same results with just calling > /bin/false inside of postinst. Indeed but the number of postinst failures due to python-central have been quite high recently. python-central is quite new and nobody helped doko to test it... so it's self-evident that we would run into some problems while it matures. doko has been very responsive in fixing problems, so it wasn't that bad. What Josselin is criticizing is the fact that python-central heavily relies on the P-V field, it looks it up in /var/lib/dpkg/status and also uses /var/lib/dpkg/info/package.list to find out files to byte-compile. This is usage of internal interfaces of dpkg and it's also normal that people are reserved on this. > WTF? We discussed that in Mexico, we agreed on that in Mexico, and now > you tell us that you just decided by yourself you don't want to follow > the new policy any more? Is there any serious reason for it, or do you > just feel like it? That field is only a part of the new policy, most of it stays the same and the important part concerning the packaging still applies. Joss doesn't feel like using that field because it clutters the database, and introduces unnecessary complexities in several places. > > and I've done things the Debian way, with a debian/package.pyversions > > file, like helper scripts have always done. > > This is not enough, as we need to be able to extract information from > the control file. This is also important for the release team and QA > team's tools. You basically need to use the new python policy. We don't need to. It has been acknowledged by some people that it would make it easier to track packages. On the other hand, it's not that complicated to find packages depending on "python (<< 2.X)" which will obviously need an update for the python transition. > The policy is valid enough. Unfortunately, the python policy can only be enforced either if it's integrated in the main policy or if the release team decides to enforce it for whatever reason. My discussion with Steve Langasek however leads me to the conclusion that the RM will only enforce the most important new python packaging rules: arch:all must provide the modules to all supported python versions and arch:any must provide all the .so if possible. However the absence or presence of a header is unlikely to constitute a RC bug for the release team. Furthermore, the policy should always document the existing rather than force people into a given direction. So it's unlikely that it will be integrated in the main policy also. 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: Updated python-support
Le lundi 19 juin 2006 à 13:28 +0200, Andreas Barth a écrit : > > Calling /bin/false doesn't entirely break the system. > > It seems that you are unaware with the way dpkg works. If a package's > postinst fails, the package is marked is unconfigured. Any dependent > packages are also not configured after that. > > This is what happend, and this is what would happen with /bin/false as > postinst also. This is not what happened. Now, if you're just here to tell me how dpkg works, I don't think I want to discuss with you. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Updated python-support
Hi, * Marc Dequènes ([EMAIL PROTECTED]) [060619 13:17]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > > Don't you think it might be a good idea to explain the policy better if > > it is not understood correctly? (And you might remember that I did such > > suggestions for the policy already.) > > Even the CDBS class was not as easy to use as i wanted, this is obvious > the changes are wide and complicated. We should be able to improve this > a bit more. I'm always all for improving things. I just don't see it as right solution to break stuff and expectations. If one wants to improve policy, IMHO the way to go is to send out a mail like "possible improvements to policy". (And, BTW, I *definitly* don't like to repeat a discussion we already had at debconf - I'm a strong believer in the "each discussion only once"-approach. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated python-support
* Josselin Mouette ([EMAIL PROTECTED]) [060619 13:12]: > Le lundi 19 juin 2006 à 12:15 +0200, Andreas Barth a écrit : > > Don't you think it might be a good idea to explain the policy better if > > it is not understood correctly? > > If high-grade developers need explanations, you can't expect the policy > to be widely understood in the long term. If you change things, you need to explain the changes properly. That's nothing new. > > Also, please explain why you think "the python transition was going to a > > dead end". I cannot see it. > > Because it is being rushed for the sake of a single person, against the > opinion of almost all fellow developers, with a broken building system. Do you want to say "because you don't like the way it is done"? Why do you think it is a broken building system? Where did "almost all fellow developers" say that they disagree with the python transition? And, BTW, if you really think the current policy is so wrong, why didn't you say in Mexico that you cannot accept the change? > > You mean, after we all put time and energy into a discussion, agreed on > > some results, and put some more work into the results, you're just going > > to tell us that you will ignore all of that? That sounds like a rather > > large slap into people's faces. > > No, I'm telling you that I will ignore *part* of that. The broken part. You tell us that you make cherry-picking? That's not how policies work. They are written down so that all people can (and should) follow them, so that any package behaves the same way. > If it were only for me to decide, I would indeed ignore all of that, > because the old policy was better. Remember: the *whole* current > situation was created by Matthias Klose and only him. Please put your hate against Matthias aside for the moment. The whole current situation is a result that e.g. the release team didn't like the prior policy, because it enforced us to have thick python transitions. Compare e.g. http://lists.debian.org/debian-release/2005/06/msg00241.html > > A policy becomes also effective when violations of a policy lead to > > packages exclusion from the next stable release. > > So what? Do you want working packages, or do you want packages > conforming to a policy? Can't we have both? Actually, I think a policy is quite an important tool because it shows definitly what one can expect from a package. Of course, policy can be changed, but just ignoring policy is only breaking expectations. And if you want to change policy, I'd rather expect a mail like "proposed change to the python policy", then just breaking policy in one of your packages (this is BTW the difference between changing policy and breaking it). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated python-support
* Josselin Mouette ([EMAIL PROTECTED]) [060619 13:03]: > Le lundi 19 juin 2006 à 12:09 +0200, Andreas Barth a écrit : > > Eh, I'm sure you can explain where somebody messed up with dpkg's > > database? What you can see is "only" that some programs postinst failed > > to run successfully. You can get the same results with just calling > > /bin/false inside of postinst. > > Calling /bin/false doesn't entirely break the system. It seems that you are unaware with the way dpkg works. If a package's postinst fails, the package is marked is unconfigured. Any dependent packages are also not configured after that. This is what happend, and this is what would happen with /bin/false as postinst also. > > WTF? We discussed that in Mexico, we agreed on that in Mexico, and now > > you tell us that you just decided by yourself you don't want to follow > > the new policy any more? Is there any serious reason for it, or do you > > just feel like it? > > I told you in Mexico the XS-Python-Version field was not a good idea, > but made this concession so that we could agree. However concessions are > only good when made on both sides. What do you want to tell me with that? Do you want to say that you intended to break that concession after being back? (And BTW, why "concession"? I have the target to get as good as possible python packages, not to defend my special ideas.) > > > (No, this specific point doesn't conform to the new python policy, but > > > this policy is only a draft and I don't see a reason to stick to it > > > while it hasn't been widely implemented, especially when there are > > > better solutions.) > > > > The policy is valid enough. You must not violate it in such an way, and > > "that there are better solutions" is just your claim at the moment. > > This policy is poorly designed. Why didn't you say so in Mexico? (And "say so" includes saying in a way that makes us other stop assuming all people can at least live with the outcome of the discussion.) > Why do you think it can't be improved? Breaking and improving are different words. > > Please stop throwing shit on Matthias. Uploads of a package with a > > really silly mistake happen. Nobody wants them, nobody enjoys them, but > > they still happen. > > Packaging mistakes usually don't entirely break the user's system. This mistake didn't break the full system. It just prevented other packages being configured. And that happens when ... > This > is what happens when there's a bug in python-central, and this will > happen again. This turns "serious" bugs into "critical" ones. ... any package high up in the dependency chain has a bug in postinst. As a buildd maintainer, I have seen such issues more than once, unfortunatly. That's nothing special, it is just that python depends on python-central. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated python-support
Coin, Andreas Barth <[EMAIL PROTECTED]> writes: > Don't you think it might be a good idea to explain the policy better if > it is not understood correctly? (And you might remember that I did such > suggestions for the policy already.) Even the CDBS class was not as easy to use as i wanted, this is obvious the changes are wide and complicated. We should be able to improve this a bit more. > You mean, after we all put time and energy into a discussion, agreed on > some results, and put some more work into the results, you're just going > to tell us that you will ignore all of that? That sounds like a rather > large slap into people's faces. All this was started far too late and the release team is putting pressure on us (what i can fully understand, but some here may be responsible for this delay), leading to precipitation. Even the CDBS class was not tested enough before upload, and i'm now having another problem because my examples had a mistake many would have probably repeated. So i'm trying to find a solution, but this may lead to some FTBFS in the next upload. It's not we are not working enough, but this deadline was too short, clearly (i said it already). > A policy becomes also effective when violations of a policy lead to > packages exclusion from the next stable release. I guess we should see this as a threat. How BOFH-like behaviors of this kind is gonna help find solutions ? Now, Joss, Buxy and me are trying to find a solution off the list, where it seems only flames are coming. Stay tuned... -- Marc Dequènes (Duck) pgpVA0Giq4SjI.pgp Description: PGP signature
Re: Updated python-support
Le lundi 19 juin 2006 à 12:15 +0200, Andreas Barth a écrit : > Don't you think it might be a good idea to explain the policy better if > it is not understood correctly? If high-grade developers need explanations, you can't expect the policy to be widely understood in the long term. > Also, please explain why you think "the python transition was going to a > dead end". I cannot see it. Because it is being rushed for the sake of a single person, against the opinion of almost all fellow developers, with a broken building system. > You mean, after we all put time and energy into a discussion, agreed on > some results, and put some more work into the results, you're just going > to tell us that you will ignore all of that? That sounds like a rather > large slap into people's faces. No, I'm telling you that I will ignore *part* of that. The broken part. If it were only for me to decide, I would indeed ignore all of that, because the old policy was better. Remember: the *whole* current situation was created by Matthias Klose and only him. Everybody agreed to migrate to python2.4 before thinking of policy improvements calmly for etch+1. > > Is it really useful? (This is a real question.) Isn't it possible to > > follow it just as easily with a script, avoiding to put cruft where it > > doesn't belong? > > You could claim the same for all information in the source packages file > or the control file. Please don't play with words and show real examples. > A policy becomes also effective when violations of a policy lead to > packages exclusion from the next stable release. So what? Do you want working packages, or do you want packages conforming to a policy? Are you going to exclude dozens of packages just because they are lacking a control field nobody uses? Threats don't lead anywhere. I thought you'd know that. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Updated python-support
Le lundi 19 juin 2006 à 12:09 +0200, Andreas Barth a écrit : > * Josselin Mouette ([EMAIL PROTECTED]) [060618 11:13]: > > * Automatic dependency generation in dh_pysupport, removing the > > need to run dh_python. > > You mean, this change breaks compatibility with the previous versions of > python-support? I strongly recommend to not make such a change. Binary-package compatibility is not broken. Source-package compatibility can be broken in some cases, and I'm working with Raphaël Hertzog and Marc Dequènes to fix it. > Eh, I'm sure you can explain where somebody messed up with dpkg's > database? What you can see is "only" that some programs postinst failed > to run successfully. You can get the same results with just calling > /bin/false inside of postinst. Calling /bin/false doesn't entirely break the system. > WTF? We discussed that in Mexico, we agreed on that in Mexico, and now > you tell us that you just decided by yourself you don't want to follow > the new policy any more? Is there any serious reason for it, or do you > just feel like it? I told you in Mexico the XS-Python-Version field was not a good idea, but made this concession so that we could agree. However concessions are only good when made on both sides. > This is not enough, as we need to be able to extract information from > the control file. This is also important for the release team and QA > team's tools. You basically need to use the new python policy. If it is really useful, we can keep it in the packages. You should note that python-support *will* work with the control field. I have added an extra compatibility layer to parse it and convert it to a ".version" file. > > (No, this specific point doesn't conform to the new python policy, but > > this policy is only a draft and I don't see a reason to stick to it > > while it hasn't been widely implemented, especially when there are > > better solutions.) > > The policy is valid enough. You must not violate it in such an way, and > "that there are better solutions" is just your claim at the moment. This policy is poorly designed. Why do you think it can't be improved? Anyway, we can follow it for the moment and improve it later, but your reaction - especially the second mail with your stupid threats - doesn't make me want to work with you. > Please stop throwing shit on Matthias. Uploads of a package with a > really silly mistake happen. Nobody wants them, nobody enjoys them, but > they still happen. Packaging mistakes usually don't entirely break the user's system. This is what happens when there's a bug in python-central, and this will happen again. This turns "serious" bugs into "critical" ones. > And Matthias really puts lots of efforts into > Debian's python packages, and, I can say this, does it better than you > do. Matthias has put lots of efforts... after slowing down the development for months. While some efforts lead to very good improvements (like the .rtinstall files or the pyversions script), some only lead to a fragile packaging system that I cannot decently use nor recommend for python packages (python-central). -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Python2.4 packages
Coin, Ron Johnson <[EMAIL PROTECTED]> writes: > Making a symlink from python2.4 to python would probably do the trick. Are you root of the world and gonna do this ugly hack on every computer on earth ??? Now please stop with the python symlinks, this has no common sense ; you're giving bad ideas to users. -- Marc Dequènes (Duck) pgpapw7yhUmPA.pgp Description: PGP signature
Re: Updated python-support
* Josselin Mouette ([EMAIL PROTECTED]) [060618 23:56]: > Le dimanche 18 juin 2006 à 23:12 +0200, Raphael Hertzog a écrit : > > This sucks because: > > - you didn't voice any concern when I worked on dh_python > > - you have let me NMU debhelper for that dh_python and then you work > > against it > > For that, I have to be sorry. I didn't have enough time to work on > Debian at that moment, and realized later the python transition was > going to a dead end, when I read many complaints from skilled developers > telling me they didn't even understand what the "new policy" was about. Don't you think it might be a good idea to explain the policy better if it is not understood correctly? (And you might remember that I did such suggestions for the policy already.) Also, please explain why you think "the python transition was going to a dead end". I cannot see it. > > The new policy was consensual until now, even if people (you included) had > > made concessions so that we can go forward. > > And these concessions only lead to a broken design. I want to step back > on the unnecessary things so that we get a comprehensible and robust > python build system as soon as possible. You mean, after we all put time and energy into a discussion, agreed on some results, and put some more work into the results, you're just going to tell us that you will ignore all of that? That sounds like a rather large slap into people's faces. > > - the Python-Version field will be useless to accurately track which > > packages need to be updated > > Is it really useful? (This is a real question.) Isn't it possible to > follow it just as easily with a script, avoiding to put cruft where it > doesn't belong? You could claim the same for all information in the source packages file or the control file. > > - from a Policy-mandated field it becomes now a python-central > > field (since the python policy has no official weight yet, we can only > > go forward with a broad consensus) > > I think you are exaggerating the importance of the policy. A policy in > Debian becomes effective when most packages use it. This is even true > for the Policy with a big P. A policy becomes also effective when violations of a policy lead to packages exclusion from the next stable release. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updated python-support
* Josselin Mouette ([EMAIL PROTECTED]) [060618 11:13]: > * Automatic dependency generation in dh_pysupport, removing the > need to run dh_python. You mean, this change breaks compatibility with the previous versions of python-support? I strongly recommend to not make such a change. > The last change is a source of strong disagreement between Raphaël and > myself. Having seen the result of messing up with dpkg's database and > control fields [0,1], Eh, I'm sure you can explain where somebody messed up with dpkg's database? What you can see is "only" that some programs postinst failed to run successfully. You can get the same results with just calling /bin/false inside of postinst. > I don't want to use the XS-Python-Version field, WTF? We discussed that in Mexico, we agreed on that in Mexico, and now you tell us that you just decided by yourself you don't want to follow the new policy any more? Is there any serious reason for it, or do you just feel like it? > and I've done things the Debian way, with a debian/package.pyversions > file, like helper scripts have always done. This is not enough, as we need to be able to extract information from the control file. This is also important for the release team and QA team's tools. You basically need to use the new python policy. > (No, this specific point doesn't conform to the new python policy, but > this policy is only a draft and I don't see a reason to stick to it > while it hasn't been widely implemented, especially when there are > better solutions.) The policy is valid enough. You must not violate it in such an way, and "that there are better solutions" is just your claim at the moment. > [0] http://blog.technologeek.org/2006/06/17/27 Please stop throwing shit on Matthias. Uploads of a package with a really silly mistake happen. Nobody wants them, nobody enjoys them, but they still happen. And Matthias really puts lots of efforts into Debian's python packages, and, I can say this, does it better than you do. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- 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]
Re: Python2.4 packages
Steve Langasek ([EMAIL PROTECTED]): > > > There is no such package in unstable. It is certainly possible to *build* > > > a package against unstable which depends on python (>= 2.4), but such a > > > package is not installable in unstable right now and therefore unsuitable > > > for upload. > > > > You can build a python2.4-flup package, but a python-flup package is not > > > currently usable in Debian if it depends on python 2.4. > > > debhelper 5.0.37.1 had a bug and sometimes it generated python (>=2.4) > > dependency (see [1]), 5.0.37.2 works fine > > Which is completely irrelevant when the OP specified that python-flub *does > require* python 2.4 or later. In this case - yes. My point is that it was possible to build a package against unstable which depends on python (>= 2.4) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpCTP45Z79jA.pgp Description: PGP signature
Re: Python2.4 packages
On Mon, Jun 19, 2006 at 10:22:17AM +0200, Piotr Ozarowski wrote: > Steve Langasek ([EMAIL PROTECTED]): > > On Mon, Jun 19, 2006 at 04:49:10PM +0900, Kai Hendry wrote: > > > On 2006-06-19T09:45+0200 Matthias Klose wrote: > > > > flup was probably built with python as found in experimental. > > > It was built on unstable. > > By whom? > > There is no such package in unstable. It is certainly possible to *build* > > a package against unstable which depends on python (>= 2.4), but such a > > package is not installable in unstable right now and therefore unsuitable > > for upload. > > You can build a python2.4-flup package, but a python-flup package is not > > currently usable in Debian if it depends on python 2.4. > debhelper 5.0.37.1 had a bug and sometimes it generated python (>=2.4) > dependency (see [1]), 5.0.37.2 works fine Which is completely irrelevant when the OP specified that python-flub *does require* python 2.4 or later. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Re: Python2.4 packages
Steve Langasek ([EMAIL PROTECTED]): > On Mon, Jun 19, 2006 at 04:49:10PM +0900, Kai Hendry wrote: > > On 2006-06-19T09:45+0200 Matthias Klose wrote: > > > flup was probably built with python as found in experimental. > > > It was built on unstable. > > By whom? > > There is no such package in unstable. It is certainly possible to *build* > a package against unstable which depends on python (>= 2.4), but such a > package is not installable in unstable right now and therefore unsuitable > for upload. > > You can build a python2.4-flup package, but a python-flup package is not > currently usable in Debian if it depends on python 2.4. debhelper 5.0.37.1 had a bug and sometimes it generated python (>=2.4) dependency (see [1]), 5.0.37.2 works fine [1] http://lists.debian.org/debian-python/2006/06/msg00208.html -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpBm5L8rHmtw.pgp Description: PGP signature
Re: Python2.4 packages
On Mon, Jun 19, 2006 at 04:49:10PM +0900, Kai Hendry wrote: > On 2006-06-19T09:45+0200 Matthias Klose wrote: > > flup was probably built with python as found in experimental. > It was built on unstable. By whom? There is no such package in unstable. It is certainly possible to *build* a package against unstable which depends on python (>= 2.4), but such a package is not installable in unstable right now and therefore unsuitable for upload. You can build a python2.4-flup package, but a python-flup package is not currently usable in Debian if it depends on python 2.4. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Missing Provides in python-crypto and others
Adeodato Simó ([EMAIL PROTECTED]):
> 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.
${python:Provides} will be filled only for arch-dep packages
(f.e for packages with python extensions - .so files)
If any external package stil depends on python2.X-foo package,
maintainer should add "python2.X-foo" to Provides: header by hand
and remove it as soon as all external packages will depend on
python-foo only
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpukOh5709tM.pgp
Description: PGP signature
Re: Missing Provides in python-crypto and others
Adeodato =?utf-8?B?U2ltw7M=?= writes: > 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]. it's a bug in python-crypto, missing the Provides field. > 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. > 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). 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. Any binary-arch package missing the provides is wrong. Fixing python-kjbuckets and python-numarray-*. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python2.4 packages
On 2006-06-19T09:45+0200 Matthias Klose wrote: > flup was probably built with python as found in experimental. It was built on unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python2.4 packages
Kai Hendry writes: > http://hendry.iki.fi/debian/unstable/flup_0.2015-1_i386.changes > python-flup: Depends: python (>= 2.4) but 2.3.5-10 is to be installed > E: Unmet dependencies. Try #apt-get -f install# with no packages (or specify > a solution). > sam$ > > Do you know how I am supposed to get my "system" upto 2.4? flup was probably built with python as found in experimental. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python2.4 packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai Hendry wrote: > http://hendry.iki.fi/debian/unstable/flup_0.2015-1_i386.changes > > sam$ sudo dpkg -i python-flup_0.2015-1_all.deb > (Reading database ... 133811 files and directories currently installed.) > Preparing to replace python-flup 0.1968-1 (using > python-flup_0.2015-1_all.deb) ... > Unpacking replacement python-flup ... > dpkg: dependency problems prevent configuration of python-flup: > python-flup depends on python (>= 2.4); however: > Version of python on system is 2.3.5-10. > dpkg: error processing python-flup (--install): > dependency problems - leaving unconfigured > Errors were encountered while processing: > python-flup > sam$ sudo apt-get install python2.4 > Reading package lists... Done > Building dependency tree... Done > python2.4 is already the newest version. > You might want to run #apt-get -f install# to correct these: > The following packages have unmet dependencies. > python-flup: Depends: python (>= 2.4) but 2.3.5-10 is to be installed > E: Unmet dependencies. Try #apt-get -f install# with no packages (or specify > a solution). > sam$ > > Do you know how I am supposed to get my "system" upto 2.4? > > Flup in this case supposedly only functions properly on Python2.4 Making a symlink from python2.4 to python would probably do the trick. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElk+RS9HxQb37XmcRAsv5AKC7kH7A9uDInRNSB4u5rObxZHKiHACgh2DP Q6JF0rA3iQGdm/ju/hUCzEE= =qUB1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED]: Re: New webpy for sponsored upload]
http://hendry.iki.fi/debian/unstable/webpy_0.138-2_i386.changes I am a little wary of the new lintian error rule to build depend on python-all-dev|python-dev|python What should I be using in my package's case? Could someone clarify. I have read the new policy, though perhaps I missed something. - Forwarded message from Kai Hendry <[EMAIL PROTECTED]> - From: Kai Hendry <[EMAIL PROTECTED]> To: Fabio Tranchitella <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Sanghyeon Seo <[EMAIL PROTECTED]> Subject: Re: New webpy for sponsored upload Date: Sun, 18 Jun 2006 12:58:25 +0900 Reply-To: Kai Hendry <[EMAIL PROTECTED]> On 2006-06-17T11:31+0200 Fabio Tranchitella wrote: > It is not necessary, since you do not provide extensions but just > modules. I am little confused. python-feedparser doesn't provide extensions. Yet it has the python-all-dev (>= 2.3.5-7) builddep. "python extension: a .so file for use by python applications" from http://wiki.debian.org/DebianPython/NewPolicy In point 7 it says if "your package provides public extensions" you need python-all-dev. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Python2.4 packages
http://hendry.iki.fi/debian/unstable/flup_0.2015-1_i386.changes sam$ sudo dpkg -i python-flup_0.2015-1_all.deb (Reading database ... 133811 files and directories currently installed.) Preparing to replace python-flup 0.1968-1 (using python-flup_0.2015-1_all.deb) ... Unpacking replacement python-flup ... dpkg: dependency problems prevent configuration of python-flup: python-flup depends on python (>= 2.4); however: Version of python on system is 2.3.5-10. dpkg: error processing python-flup (--install): dependency problems - leaving unconfigured Errors were encountered while processing: python-flup sam$ sudo apt-get install python2.4 Reading package lists... Done Building dependency tree... Done python2.4 is already the newest version. You might want to run #apt-get -f install# to correct these: The following packages have unmet dependencies. python-flup: Depends: python (>= 2.4) but 2.3.5-10 is to be installed E: Unmet dependencies. Try #apt-get -f install# with no packages (or specify a solution). sam$ Do you know how I am supposed to get my "system" upto 2.4? Flup in this case supposedly only functions properly on Python2.4 Best wishes, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
