On Apr 15, 2015, at 09:05 AM, Ben Finney wrote:
>I use the “merge when building the source package” workflow, where the
>upstream source is a tarball outside the working tree, not part of the
>Debian packaging VCS at all.
>
>See ‘git-buildpackage(1)’, the ‘--git-overlay’ option.
>
>Is that still a
On Apr 15, 2015, at 09:34 AM, Barry Warsaw wrote:
>>Is that still a wholly compatible workflow with what is being proposed?
>
>I think so, but I haven't played with --git-overlay.
Oops, I misread. To be clear, I think the patch regimes are not compatible
with --git-overlay, but I could be wrong.
On Wed, Apr 15, 2015 at 09:05:06AM +1000, Ben Finney wrote:
> Paul Tagliamonte writes:
> > All present felt strongly that we should always use pristine upstream
> > tarballs as released by upstreams, with pristine-tar.
>
> I'm glad of the former. I don't use ‘pristine-tar’, though.
>
> I use the
Hi Scott (2015.04.15_02:17:18_+0200)
> >Consensus seems to be "give it a shot" and try to see what works.
> >There are no pypy apps, so this isn't an issue yet.
>
> What is the "it" that's to be given a shot? I see two choices there?
Give python3 + pypy3 shared dist-packages a shot.
> Did you di
Hi Paul (2015.04.15_16:53:04_+0200)
> > See ‘git-buildpackage(1)’, the ‘--git-overlay’ option.
> >
> > Is that still a wholly compatible workflow with what is being proposed?
>
> I have this workflow as well, and this would even work really well with
> our current svn repos, but folks in the room
Hi Scott (2015.04.15_02:17:18_+0200)
> >Upstream Python's direction for Python paths is in favor of explicitly
> >numbered
> >/usr/bin/python2 and /usr/bin/python3. In support of this, rough
> >consensus in
> >the room is that /usr/bin/python should likely be removed *entirely*
> >from
> >shebangs
Hi Scott (2015.04.15_17:19:39_+0200)
> Since these pypy extension packages are new and there are no applications, I
> think it would make a lot of sense to limit this to PY3. It makes things
> much
> simpler technically. We should not recreate the symlink farm we used to have
> for python.
>
On Wednesday, April 15, 2015 04:54:45 PM Stefano Rivera wrote:
> Hi Scott (2015.04.15_02:17:18_+0200)
>
> > >Consensus seems to be "give it a shot" and try to see what works.
> > >There are no pypy apps, so this isn't an issue yet.
> >
> > What is the "it" that's to be given a shot? I see two cho
On April 15, 2015 11:17:52 AM EDT, Stefano Rivera wrote:
>Hi Scott (2015.04.15_02:17:18_+0200)
>> >Upstream Python's direction for Python paths is in favor of
>explicitly
>> >numbered
>> >/usr/bin/python2 and /usr/bin/python3. In support of this, rough
>> >consensus in
>> >the room is that /usr/bi
On April 15, 2015 11:24:30 AM EDT, Stefano Rivera wrote:
>Hi Scott (2015.04.15_17:19:39_+0200)
>> Since these pypy extension packages are new and there are no
>applications, I
>> think it would make a lot of sense to limit this to PY3. It makes
>things much
>> simpler technically. We should no
On Apr 15, 2015, at 12:24 PM, Scott Kitterman wrote:
>Maybe I'll mellow over time, but currently my thinking is that if there's an
>upload to point /usr/bin/python at a python3, it will be immediately followed
>by one where I remove myself from being maintainer. It's an idea that can
>only cause p
Heyya d-p,
I'd like to send an email to d-d-a asking that project to consider no
longer creating new Debian tools in Python 2.
I'd like this to have the endorsement of the team, so, does anyone object to
me asking people to not write new tools in Python 2 only (prefer alternative
deps or porting)
On Wednesday, April 15, 2015 02:16:58 PM Barry Warsaw wrote:
> On Apr 15, 2015, at 12:24 PM, Scott Kitterman wrote:
> >Maybe I'll mellow over time, but currently my thinking is that if there's
> >an upload to point /usr/bin/python at a python3, it will be immediately
> >followed by one where I remo
On Wednesday, April 15, 2015 04:27:51 PM Paul Tagliamonte wrote:
> Heyya d-p,
>
> I'd like to send an email to d-d-a asking that project to consider no
> longer creating new Debian tools in Python 2.
>
> I'd like this to have the endorsement of the team, so, does anyone object to
> me asking peop
On Wed, Apr 15, 2015 at 3:27 PM, Paul Tagliamonte
wrote:
> Heyya d-p,
>
> I'd like to send an email to d-d-a asking that project to consider no
> longer creating new Debian tools in Python 2.
>
> I'd like this to have the endorsement of the team, so, does anyone object
> to
> me asking people to
Perfect, thanks, Ian! I'll get a ML for a Python 3 porting SWAT team
together once we make sure no one has a sane technical reason to avoid
this so soon (I don't think there's any)
Thanks, Ian! Excited to work with you!
Paul
On Wed, Apr 15, 2015 at 4:35 PM, Ian Cordasco
wrote:
> On Wed, Apr 15
On 2015-04-15 16:27, Paul Tagliamonte wrote:
> I'd like to send an email to d-d-a asking that project to consider no
> longer creating new Debian tools in Python 2.
Makes sense.
I try to use Py3 whenever possible. Sometimes some libs are still
missing, mainly when upstream is not very active. My
Hi Scott (2015.04.15_22:42:26_+0200)
> P.S. It would be nice if there would be a PEP that says to never ever do
> this. I know it would make Arch have a sad, but they'll get over it.
I think everyone wants to make Arch sad. In retaliation for them making
us sad. Apparently there were many confu
On 04/15/2015 10:27 PM, Paul Tagliamonte wrote:
> Heyya d-p,
>
> I'd like to send an email to d-d-a asking that project to consider no
> longer creating new Debian tools in Python 2.
>
> I'd like this to have the endorsement of the team, so, does anyone object to
> me asking people to not write n
On Wednesday, April 15, 2015 11:07:13 PM Matthias Klose wrote:
> On 04/15/2015 10:27 PM, Paul Tagliamonte wrote:
> > Heyya d-p,
> >
> > I'd like to send an email to d-d-a asking that project to consider no
> > longer creating new Debian tools in Python 2.
> >
> > I'd like this to have the endorse
On Wednesday, April 15, 2015 11:00:53 PM Stefano Rivera wrote:
> Hi Scott (2015.04.15_22:42:26_+0200)
>
> > P.S. It would be nice if there would be a PEP that says to never ever do
> > this. I know it would make Arch have a sad, but they'll get over it.
>
> I think everyone wants to make Arch s
I'll add a note about that, and talk with the ftpteam to see if we can
implement that policy in NEW.
Mails on the thread seem positive so far, I'll post this to d-d-a when I
get home from YUL to DC tonight.
On Apr 15, 2015 5:07 PM, "Matthias Klose" wrote:
> On 04/15/2015 10:27 PM, Paul Tagliamo
I was saying the same thing in my head, but as i thought about it, if the
cpython maint team (hi doko) wants it, I don't see why not :)
I phrased it in such a way in my mail that I feel comfortable sending my
draft and then working out details without setting ftpteam policy first
On Apr 15, 2015 6
On Apr 15, 2015, at 04:42 PM, Scott Kitterman wrote:
>Then I don't understand why the whole s/python/python2// plan in the shebangs
>helps anything. As long as both exist, it's a no-op.
Partly this is to begin to educate users to stop using /usr/bin/python, which
has unclear semantics across th
I am happy to help porting things. I did it for a number of non trivial
packages and happy to do more. It's very soothing experience and better
than knitting & sudoku.
On 15 Apr 2015 2:29 pm, "Paul Tagliamonte" wrote:
> Heyya d-p,
>
> I'd like to send an email to d-d-a asking that project to cons
On Apr 15, 2015, at 04:27 PM, Paul Tagliamonte wrote:
>I'd like this to have the endorsement of the team
Looks like you don't need my +1 but I'll give it anyway. :)
>I'll make note of a team which should exist to help with such porting,
>(I'm up to help with this)
I'm up for helping too, of cou
Paul Tagliamonte writes:
> I'll make note of a team which should exist to help with [porting
> packages to Python 3 compatibility], (I'm up to help with this) that
> was one of the items that came out of the PyCon chit-chat.
I have recent experience making code bases Python 2 and Python 3
compat
On April 15, 2015 8:00:22 PM EDT, Barry Warsaw wrote:
>On Apr 15, 2015, at 04:42 PM, Scott Kitterman wrote:
>
>>Then I don't understand why the whole s/python/python2// plan in the
>shebangs
>>helps anything. As long as both exist, it's a no-op.
>
>Partly this is to begin to educate users to sto
It's worth mentioning that in virtualenvs and conda envs, where there can
only be one version of Python installed, 'python' refers to that whether it
is Python 3 or 2. So it's already not a safe assumption that 'python'
always means Python 2, even if you discount Arch.
On 15 April 2015 at 21:04, S
The odds of system management scripts I wrote a decade ago and haven't touched
since living in a virtualenv is approximately zero. The issue with switching
where /usr/bin/python points to python3 is to avoid problems on systems. I
don't think virtualenv is relevant. In any case, if you're usi
On Thu, Apr 16, 2015 at 4:48 AM, Scott Kitterman wrote:
> You might also ask Debian teams using Python in the Debian infrastructure to
> review their packaged dependencies and identify any that aren't available for
> Python3. We'll need to know that soon so we can work on porting
> dependencies/f
In addition to the Python 3 related work:
Port service dependencies to Python 3.
Port service code-bases to Python 3.
We also need to:
Port Django based services to Django 1.7
Port services based on Pylons (deprecated) to something else like Django:
snapshot.debian.org
debexpo (mentors.debian.
32 matches
Mail list logo
