On Fri, May 03, 2019 at 12:48:42PM +0100, Sad Clouds wrote:
> On Fri, 3 May 2019 11:32:32 +
> co...@sdf.org wrote:
>
> > On Fri, May 03, 2019 at 12:10:30PM +0100, Sad Clouds wrote:
> > > On Fri, 3 May 2019 11:02:49 +
> > > co...@sdf.org wrote:
> > >
> > > > I'm not sure it's a good idea
On Fri, 3 May 2019 11:32:32 +
co...@sdf.org wrote:
> On Fri, May 03, 2019 at 12:10:30PM +0100, Sad Clouds wrote:
> > On Fri, 3 May 2019 11:02:49 +
> > co...@sdf.org wrote:
> >
> > > I'm not sure it's a good idea to apply that patch, though.
> > > fixing util-linux is probably the right
On Fri, May 03, 2019 at 12:10:30PM +0100, Sad Clouds wrote:
> On Fri, 3 May 2019 11:02:49 +
> co...@sdf.org wrote:
>
> > I'm not sure it's a good idea to apply that patch, though.
> > fixing util-linux is probably the right thing.
>
> Solaris seems to have its own libuuid, can python use
On Fri, 3 May 2019 11:02:49 +
co...@sdf.org wrote:
> I'm not sure it's a good idea to apply that patch, though.
> fixing util-linux is probably the right thing.
Solaris seems to have its own libuuid, can python use that instead?
I'm not sure it's a good idea to apply that patch, though.
fixing util-linux is probably the right thing.
On Fri, 3 May 2019 10:17:03 +
co...@sdf.org wrote:
> On Fri, May 03, 2019 at 07:30:54AM +0100, Sad Clouds wrote:
> > This totally fails on SPARC Solaris 11.3, due to util-linux where
> > random_get_bytes() conflicts with Solaris own function. Why does
> > Python depend on all these Linux
libuuid is a mess. I can't tell how many different variants of the the
library exists. we apparently know how to pick up the OS X one as a
builtin always, because we will look for uuid_generate on uuid.h.
but in this case, it doesn't need uuid_generate...
On Fri, May 03, 2019 at 07:30:54AM +0100, Sad Clouds wrote:
> This totally fails on SPARC Solaris 11.3, due to util-linux where
> random_get_bytes() conflicts with Solaris own function. Why does Python
> depend on all these Linux packages? Not that I care that much about
> Python, but it seems you
On Wed, 24 Apr 2019 22:31:36 +
co...@sdf.org wrote:
> Hi folks,
>
> The default Python version in pkgsrc is now 3.7, in preparation for
> the coming end of life date of Python 2.7 (the previous default) at
> the end of this year.
>
> This means any package that can be built with Python 3.7
On 2019-04-25 11:08, co...@sdf.org wrote:
On Thu, Apr 25, 2019 at 04:43:24PM +0100, Roy Marples wrote:
On 24/04/2019 23:31, co...@sdf.org wrote:
The default Python version in pkgsrc is now 3.7, in preparation for
the coming end of life date of Python 2.7 (the previous default) at
the end of
I have no objections at all. And yes, keeping 3.6 is also a good move; at least
from my little corner of the planet.
On 4/25/19, 12:02 PM, "Adam" wrote:
>> The default Python version in pkgsrc is now 3.7, in preparation for
>> the coming end of life date of Python 2.7 (the previous
On Thu, Apr 25, 2019 at 04:43:24PM +0100, Roy Marples wrote:
> On 24/04/2019 23:31, co...@sdf.org wrote:
> > The default Python version in pkgsrc is now 3.7, in preparation for
> > the coming end of life date of Python 2.7 (the previous default) at
> > the end of this year.
>
> Can we punt 3.4,
On Thu, 25 Apr 2019 16:43:24 +0100, Roy Marples wrote:
> On 24/04/2019 23:31, coypu%sdf.org@localhost wrote:
> > The default Python version in pkgsrc is now 3.7, in preparation for
> > the coming end of life date of Python 2.7 (the previous default) at
> > the end of this year.
> Can we punt
>> The default Python version in pkgsrc is now 3.7, in preparation for
>> the coming end of life date of Python 2.7 (the previous default) at
>> the end of this year.
>
> Can we punt 3.4, 3.5 and 3.6 then?
> 3.4 fails at least to build on netbsd-current due to an openssl conflict by
> the looks
On 24/04/2019 23:31, co...@sdf.org wrote:
The default Python version in pkgsrc is now 3.7, in preparation for
the coming end of life date of Python 2.7 (the previous default) at
the end of this year.
Can we punt 3.4, 3.5 and 3.6 then?
3.4 fails at least to build on netbsd-current due to an
Hi folks,
The default Python version in pkgsrc is now 3.7, in preparation for
the coming end of life date of Python 2.7 (the previous default) at
the end of this year.
This means any package that can be built with Python 3.7 will be built
with it, rather than Python 2.7.
Packages with no Python
16 matches
Mail list logo
