Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, Apr 12, 2006 at 12:41:13AM +0200, Jeroen van Wolffelaar wrote: > So, because there were no objections to the python 2.1/2.2 removal, > I'll be proceeding with that. Done now, I'd like to announce this, together with some warning about default python version changes, if they're going to happen soon (best to not to have multiple separate announcements if they can be joined). It'll be a bit (about 24h) before a dropped python2.1 & python2.2 will reach the mirrors, and impact should be reasonably limited, so otoh, it isn't totally required. So, any opinion on the -defaults change, esp. from Matthias of course, is very welcomed. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 01:49:52PM +0200, Matthias Klose wrote: > Jeroen van Wolffelaar writes: > > The first freezes are already closing in fast, > > did I miss something? There's no update since > http://lists.debian.org/debian-devel-announce/2005/10/msg4.html We're roughly 16 weeks from the python freeze, including the debconf period and the summer holiday period (for the northern hemisphere, that is). During these mere 16 weeks, python 2.1 & 2.2 needs to be dropped, the default moved to 2.4, and the plan is to overhaul the python policy/infrastructure. We can use all of those weeks to get settled over each of those issues, and many more that are important for the release. Having 4 (or maybe even 5) python versions would be a release blocker, and the two oldest ones can be removed without any serious direct consequences, and simply would provide a better urge for people to fix up their packages. Several people already asked for removal, sponsoring, and I noticed some more packages simply getting fixed over the weekend. So, because there were no objections to the python 2.1/2.2 removal, I'll be proceeding with that. Regarding 2.4, I'd really like to get started with it asap, and having the policy stuff happening in parallel. Are there any objections/reasons to *not* do so in like a week from now, starting with a simple upload of python-defaults? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
Matthias Klose wrote: > Jeroen van Wolffelaar writes: > > The first freezes are already closing in fast, > > did I miss something? There's no update since > http://lists.debian.org/debian-devel-announce/2005/10/msg4.html Yes. At least the January, 3rd one (http://lists.debian.org/debian-devel-announce/2006/01/msg1.html) --- snip --- [...] Our time line still is: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] The good news is that we are on track to reach this goal. [...] --- snip --- Regards, Rene signature.asc Description: Digital signature
Re: New python maintenance team
Gustavo Franco ([EMAIL PROTECTED]): > the status of pyenchant ? It's a gaupol dependency, right ? Sounds > like a "python-modules" valid candidate. There is an ITP bug reported against this package (package itself is available at mentors.debian.net), but it is little old - there are 2 new upstream versions. I'll ask author if he still wants to maintain it. -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpA1XEImfCJn.pgp Description: PGP signature
Re: New python maintenance team
On Tue, 11 Apr 2006, Piotr Ozarowski wrote: > > But I would really like turbogears maintained within "python-modules" since > > it's mainly good glue between several general-purpose Python modules. > > Does gaupol [1] qualify? It is rather standalone application than a > python module but I would be glad to join the group. A standalone application doesn't make sense in this project called "python-modules". However if you're looking for an alioth project where you could do co-maintenance of an application without creating a dedicated project, you can consider http://alioth.debian.org/projects/collab-maint http://wiki.debian.org/CollaborativeMaintenance Alternatively, you can decide to create a "python-apps" Alioth project if you really think that it makes sense to maintain collaboratively (unrelated) python applications. 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: New python maintenance team
On 4/11/06, Piotr Ozarowski <[EMAIL PROTECTED]> wrote: > Raphael Hertzog ([EMAIL PROTECTED]): > > Yeah, "pkg-python" would be just core python. But "python-modules" is more > > general purpose. > > > > > Just want to make sure I understand the thread, python package projects, > > > like pkg-turbogears are to remain separate? > > > > But I would really like turbogears maintained within "python-modules" since > > it's mainly good glue between several general-purpose Python modules. > > Does gaupol [1] qualify? It is rather standalone application than a > python module but I would be glad to join the group. > Hi Piotr, The simple rule is that if i can "import gaupol" and it will be really useful for any other python application (packaged or not), it could be into the team. I think that "gaupol" itself don't qualify, but what's the status of pyenchant ? It's a gaupol dependency, right ? Sounds like a "python-modules" valid candidate. Thanks, -- stratus
Re: New python maintenance team
Raphael Hertzog ([EMAIL PROTECTED]): > Yeah, "pkg-python" would be just core python. But "python-modules" is more > general purpose. > > > Just want to make sure I understand the thread, python package projects, > > like pkg-turbogears are to remain separate? > > But I would really like turbogears maintained within "python-modules" since > it's mainly good glue between several general-purpose Python modules. Does gaupol [1] qualify? It is rather standalone application than a python module but I would be glad to join the group. [1] http://home.gna.org/gaupol/ http://debian.pox.one.pl/gaupol_0.4.0-1_all.deb -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpfpxZZr67yQ.pgp Description: PGP signature
Re: New python maintenance team
On Tue, 11 Apr 2006, Bob Tanner wrote: > > OK, thanks to everyone who volunteered so far. There's already a > > pkg-python Alioth project and an associated SVN repository. Right now it's > > empty but Matthias will start using it this week-end (if all goes well). > > This is just for core python right? Yeah, "pkg-python" would be just core python. But "python-modules" is more general purpose. > Just want to make sure I understand the thread, python package projects, > like pkg-turbogears are to remain separate? But I would really like turbogears maintained within "python-modules" since it's mainly good glue between several general-purpose Python modules. (But it's up to you in the end.) 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: Python-modules policy document + announce
On Tue, 11 Apr 2006, Matthias Klose wrote: > Raphael Hertzog writes: > > Hello everybody, > > > > I completed the documentation of the python-modules alioth project. > > > > Please check out: > > http://python-modules.alioth.debian.org/python-modules-policy.html > > maybe add a layout for the svn structure? What do you mean ? The "layout" of the svn is documented in the pkg-perl documentation that we point to. I don't see the need to document again the same thing. http://pkg-perl.alioth.debian.org/subversion.html#2__repository_anatomy 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: Python-modules policy document + announce
On 4/11/06, Bob Tanner <[EMAIL PROTECTED]> wrote: > Raphael Hertzog wrote: > > > Hello everybody, > > > > I completed the documentation of the python-modules alioth project. > > How does this new project effect existing projects like pkg-turbogears? > Good question. You can keep with pkg-turbogears (btw, what's the status?) and we (python-modules) shouldn't touch "your stuff" or if all the pkg-turbogears group members agree we can merge our efforts. Btw, i've just asked about turbogears in #debian-python (irc.oftc.net) and found the ITP and the alioth group. :-) -- stratus
Re: Python-modules policy document + announce
Raphael Hertzog wrote: > Hello everybody, > > I completed the documentation of the python-modules alioth project. How does this new project effect existing projects like pkg-turbogears? -- Bob Tanner <[EMAIL PROTECTED]> | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New python maintenance team
Raphael Hertzog wrote: >> Who would be interested to help ? > > OK, thanks to everyone who volunteered so far. There's already a > pkg-python Alioth project and an associated SVN repository. Right now it's > empty but Matthias will start using it this week-end (if all goes well). This is just for core python right? Just want to make sure I understand the thread, python package projects, like pkg-turbogears are to remain separate? -- Bob Tanner <[EMAIL PROTECTED]> | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python-modules policy document + announce
Raphael Hertzog writes: > Hello everybody, > > I completed the documentation of the python-modules alioth project. > > Please check out: > http://python-modules.alioth.debian.org/python-modules-policy.html maybe add a layout for the svn structure? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdbs to remove *.pyc on clean?
On Mon, Apr 10, 2006 at 06:59:04PM +0200, Peter Eisentraut wrote:
> I have a question on the bug report #252134 "cdbs: python-distutils.mk
> should remove .pyc files on clean". It seems that python setup.py
> clean actually creates a number .pyc files itself, and quite a number
> of packages therefore have code along the lines of
> clean::
> find . -name '*.pyc' -exec rm '{}' ';'
> in them. I'm considering adding exactly that line to cdbs. The
> question is whether that is too far reaching. I'm not an expert on the
> issue, but it seems unlikely that an upstream tarball or a clean source
> package should contain .pyc files. So it seems OK to me. Does anyone
> think this change would be a bad idea, or does anyone perhaps have a
> better solution for this bug?
.pyc files are not source files, and changes to them can't be represented in
patches, so the worst case is that this will generate the "ignoring deletion
of foo" warning.
So I think removing all .pyc files in the clean target should be fine. The
only possible issue would be if there was a .pyc file in the package which
can't be built from source, because removing such a file would break
idempotency of the build->clean->build cycle; but that could only happen
with non-free packages.
--
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/
signature.asc
Description: Digital signature
