>
> What I propose is to enable the concurrent behavior by default and to
> provide a feature to disable it when necessary.
silly question but why is it an option in the first place?
--
Eitan Adler
___
freebsd-python@freebsd.org mailing list
ut
hopefully someone should look at it soon.
--
Eitan Adler
___
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
On 20 April 2013 05:56, Chris Rees wrote:
> On 20 April 2013 04:48, Eitan Adler wrote:
>> What do you think of the following?
>>
>> This fixes issue with PYTHON_DEFAULT_VERSION=python3.3
>
newline at end of property
--
Eitan Adler
___
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Can anyone on this list please review the following. I am not certain
it is good advice.
commit 99d4cc9aff09ec7d11f812b76e32fb15ec342862
Author: Eitan Adler
Date: Wed Feb 27 17:07:34 2013 -0500
Advice using an origin prefix when PKGNAMEPREIX is set.
PR: docs/175564
e-mail to maintainer) and
> either convert it to use fresh python3-X or remove it.
There are non-ports users of python. Is keeping python3.1 harmful or
making it difficult to make other changes?
--
Eitan Adler
___
freebsd-python@freeb
.
>
>
> I just realized there is such a document:
> http://www.python.org/dev/peps/pep-0394/
>
> According to it:
>
> python2 will refer to some version of Python 2.x
> python3 will refer to some version of Python 3.x
> python should refer to the same target as python2
distinfo can change. The concern about different distinfos is only
when the distfiles are re-rolled, but the contents are not checked
against the original. There have been cases of compromised mirrors
hosting bogus or malicious content. So long as it "makes sense" to
change the distinfo no on
On 23 June 2012 00:50, Jesper Schmitz Mouridsen
wrote:
> Hello maintainers of python.
> /*--*/preventImports=["gi"])
> /+++/preventImports=[""])
Thanks for this, it fixes an issue I had too. Now the question is:
upstream issue or FreeBS
On 3 June 2012 14:29, Ruslan Mahmatkhanov wrote:
> Ok, will do next time. I didn't actually bother to ask in this case because
> I'm interested in this port and I'm in python@ :).
I missed the the second part. Sorry for the no
are treated exactly like individuals. Unless you ask first
please don't transfer ports around like this.
(note, I'm not speaking for python@)
--
Eitan Adler
___
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/free
4nvGSQ/tZjYaa9IoNYCc/13Jm9
aOl6zz8dqmREsImofb4BL4S77/bCaOKmQDuLaghgoOROKDZeeTQ3u1bxGhc9OFXT
M3sSMdva9A8ehF2XRqfyw8s1+kx0v/TvOWoWLWwGl8fhJGETMJ/Y4+myxqvUAsf+
RxWhXI0wKaGNzFbtCZ2xrnUxpBJeiE1Agr8rd/+yVbkQBPajAEnisGqzMKPhRqPi
E9fe8lgLB0xib5welCIV
=S2+D
-END PGP SIGNAT
On 21 April 2012 20:25, Eitan Adler wrote:
> If I had to guess freebsd-python takes all ports with py- and someone
> manually did a kick-aa on the port to force the PR over to you. The
> sequence of changes does seem a bit odd.
Actually, taking a slightly closer look: it seems the emai
ve (because I am actually
> the maintainer) although I sent the PR in the first place.
If I had to guess freebsd-python takes all ports with py- and someone
manually did a kick-aa on the port to force the PR over to you. The
sequence of changes
ghts.
>
>> Would defining locale_t and the related functions in xlocale.h if we are in
>> a mode where they are not normally exposed fix the problem?
>
> I think that this should work.
What about patching python to only define the POSIX macros iff glibc
is being used (and gett
15 matches
Mail list logo
