Re: pkgsrc python default version -> 3.7
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 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? > > > > The logic for searching for a util-linux style libuuid (as opposed to > > the DCE standard uuid) isn't OS specific. if it doesn't pick it up it > > probably doesn't like something about it... > > > > it looks for util_generate in uuid/uuid. > > Solaris man pages list the following, so no util_generate > > INTERFACES >The shared object libuuid.so.1 provides the public interfaces > defined below. See Intro(3) for additional information on shared > object inter- faces. > >uuid_clearuuid_compare >uuid_copy uuid_generate >uuid_generate_random uuid_generate_time >uuid_is_null uuid_parse >uuid_time uuid_unparse > > FILES >/lib/libuuid.so.1 shared object > >/lib/64/libuuid.so.164-bit shared object Sorry, that's a typo, it looks for uuid_generate
Re: pkgsrc python default version -> 3.7
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 thing. > > > > Solaris seems to have its own libuuid, can python use that instead? > > The logic for searching for a util-linux style libuuid (as opposed to > the DCE standard uuid) isn't OS specific. if it doesn't pick it up it > probably doesn't like something about it... > > it looks for util_generate in uuid/uuid. Solaris man pages list the following, so no util_generate INTERFACES The shared object libuuid.so.1 provides the public interfaces defined below. See Intro(3) for additional information on shared object inter- faces. uuid_clearuuid_compare uuid_copy uuid_generate uuid_generate_random uuid_generate_time uuid_is_null uuid_parse uuid_time uuid_unparse FILES /lib/libuuid.so.1 shared object /lib/64/libuuid.so.164-bit shared object
Re: pkgsrc python default version -> 3.7
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 that instead? The logic for searching for a util-linux style libuuid (as opposed to the DCE standard uuid) isn't OS specific. if it doesn't pick it up it probably doesn't like something about it... it looks for util_generate in uuid/uuid.
Re: pkgsrc python default version -> 3.7
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?
Re: pkgsrc python default version -> 3.7
I'm not sure it's a good idea to apply that patch, though. fixing util-linux is probably the right thing.
Re: pkgsrc python default version -> 3.7
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 packages? Not that I care that
> > much about Python, but it seems you can't build anything without
> > installing Perl and Python as well.
>
> it can handle non libuuid-uuid implementation, too.
> but it will try to link libuuid if it's available.
>
> maybe we want:
>
> Index: Makefile
> ===
> RCS file: /cvsroot/pkgsrc/lang/python37/Makefile,v
> retrieving revision 1.8
> diff -u -r1.8 Makefile
> --- Makefile 30 Apr 2019 04:49:38 - 1.8
> +++ Makefile 3 May 2019 10:15:08 -
> @@ -4,6 +4,7 @@
>
> PKGNAME= python37-${PY_DISTVERSION}
> CATEGORIES= lang python
> +PKGREVISION= 1
>
> MAINTAINER= pkgsrc-us...@netbsd.org
> HOMEPAGE=https://www.python.org/
> @@ -170,13 +171,22 @@
> ${DESTDIR}${PREFIX}/lib/libpython3.7.sl.1.0
> .endif
>
> +.if ${OPSYS} == "FreeBSD" || ${OPSYS} == "OpenBSD" ||
> \
> + ${OPSYS} == "DragonFly" || ${OPSYS} == "SunOS" || \
> + ${OPSYS} == "NetBSD" || ${OPSYS} == "Darwin"
> ||\
> + ${OPSYS} == "AIX"
> +# uuid functionality in libc, avoid detecting libuuid if installed
> +BUILDLINK_TRANSFORM+=rm:-luuid
> +.else
> +.include "../../devel/libuuid/buildlink3.mk"
> +.endif
> +
> BUILDLINK_DEPMETHOD.readline=build
>
> .include "../../archivers/bzip2/buildlink3.mk"
> .include "../../archivers/xz/buildlink3.mk"
> .include "../../devel/gettext-lib/buildlink3.mk"
> .include "../../devel/libffi/buildlink3.mk"
> -.include "../../devel/libuuid/buildlink3.mk"
> .include "../../devel/readline/buildlink3.mk"
> .include "../../devel/zlib/buildlink3.mk"
> BUILDLINK_API_DEPENDS.openssl+= openssl>=1.0.2
>
OK if there is no hard requirement for libuuid, let me try without it
and I'll let you know how far I get.
Re: pkgsrc python default version -> 3.7
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...
Re: pkgsrc python default version -> 3.7
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 can't build anything without installing
> Perl and Python as well.
it can handle non libuuid-uuid implementation, too.
but it will try to link libuuid if it's available.
maybe we want:
Index: Makefile
===
RCS file: /cvsroot/pkgsrc/lang/python37/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile30 Apr 2019 04:49:38 - 1.8
+++ Makefile3 May 2019 10:15:08 -
@@ -4,6 +4,7 @@
PKGNAME= python37-${PY_DISTVERSION}
CATEGORIES=lang python
+PKGREVISION= 1
MAINTAINER=pkgsrc-us...@netbsd.org
HOMEPAGE= https://www.python.org/
@@ -170,13 +171,22 @@
${DESTDIR}${PREFIX}/lib/libpython3.7.sl.1.0
.endif
+.if ${OPSYS} == "FreeBSD" || ${OPSYS} == "OpenBSD" || \
+ ${OPSYS} == "DragonFly" || ${OPSYS} == "SunOS" || \
+ ${OPSYS} == "NetBSD" || ${OPSYS} == "Darwin" || \
+ ${OPSYS} == "AIX"
+# uuid functionality in libc, avoid detecting libuuid if installed
+BUILDLINK_TRANSFORM+= rm:-luuid
+.else
+.include "../../devel/libuuid/buildlink3.mk"
+.endif
+
BUILDLINK_DEPMETHOD.readline= build
.include "../../archivers/bzip2/buildlink3.mk"
.include "../../archivers/xz/buildlink3.mk"
.include "../../devel/gettext-lib/buildlink3.mk"
.include "../../devel/libffi/buildlink3.mk"
-.include "../../devel/libuuid/buildlink3.mk"
.include "../../devel/readline/buildlink3.mk"
.include "../../devel/zlib/buildlink3.mk"
BUILDLINK_API_DEPENDS.openssl+=openssl>=1.0.2
Re: pkgsrc python default version -> 3.7
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 will be built > with it, rather than Python 2.7. > Packages with no Python 3.x support will continue to be built with > Python 2.7. > > Problems are not likely to occur as many developers have been using > this default for a while. > Let me know if there are any problems still. > > To undo this change, if you have a need for it, add this line to your > /etc/mk.conf: > PYTHON_VERSION_DEFAULT=27 > > For binary packages named pyXX-packagename, a python 2.7 will still be > built (py27-packagename), as well as all the other python versions > available. 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 can't build anything without installing Perl and Python as well. ===> Building for libuuid-2.32.1 /opt/pkg/bin/bmake all-recursive Making all in po CC lib/libuuid_la-randutils.lo In file included from lib/randutils.c:29: /usr/include/sys/random.h:71:12: error: conflicting types for 'random_get_bytes' extern int random_get_bytes(uint8_t *dbuf, size_t dlen); ^~~~ In file included from lib/randutils.c:19: ./include/randutils.h:14:13: note: previous declaration of 'random_get_bytes' was here extern void random_get_bytes(void *buf, size_t nbytes); ^~~~ *** [lib/libuuid_la-randutils.lo] Error code 1 bmake[2]: stopped in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 1 error bmake[2]: stopped in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 *** [all-recursive] Error code 1 bmake[1]: stopped in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 1 error bmake[1]: stopped in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 *** [all] Error code 2 bmake: stopped in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 1 error bmake: stopped in /opt/pkgbuild/objects/devel/libuuid/work/util-linux-2.32.1 *** Error code 2 Stop. bmake[4]: stopped in /opt/pkgbuild/pkgsrc/devel/libuuid *** Error code 1 Stop. bmake[3]: stopped in /opt/pkgbuild/pkgsrc/devel/libuuid *** Error code 1 Stop. bmake[2]: stopped in /opt/pkgbuild/pkgsrc/lang/python37 *** Error code 1 Stop. bmake[1]: stopped in /opt/pkgbuild/pkgsrc/devel/glib2-tools *** Error code 1 Stop. bmake: stopped in /opt/pkgbuild/pkgsrc/wm/windowmaker
Re: pkgsrc python default version -> 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 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 of it. Roy Adam already mentioned wanting to get rid of 3.4. I think that's reasonable. I think we should leave 3.6. I've heard at least one person mentioning they don't want to rush to 3.7 (on a HPC setup supporting many users that run their own python scripts). Definitely keep 3.6 in the tree for a while.?? Having 3.7 as default will encourage moving forward, but we'll probably hit a few issues that we can work around by using 3.6 for now.
Re: pkgsrc python default version -> 3.7
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 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 of it. > > Roy I would like to remove Python 3.4, if there is no objection. But I would keep 3.5, and 3.6 for the time being. Kind regards, Adam
Re: pkgsrc python default version -> 3.7
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, 3.5 and 3.6 then? > 3.4 fails at least to build on netbsd-current due to an openssl conflict by > the looks of it. > > Roy Adam already mentioned wanting to get rid of 3.4. I think that's reasonable. I think we should leave 3.6. I've heard at least one person mentioning they don't want to rush to 3.7 (on a HPC setup supporting many users that run their own python scripts).
Re: pkgsrc python default version -> 3.7
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 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 of it. Unfortunately, last I saw, "misc/libreoffice" is stuck at nothing later than python36, claiming "PYTHON_VERSIONS_INCOMPATIBLE= 27 37" Also, if one doesn't want the overhead of pkgsrc openssl on netbsd-7, python36 is as far as you can go. I suppose once netbsd-7 is EOL that won't be an issue. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: pkgsrc python default version -> 3.7
>> 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 of it. > > Roy I would like to remove Python 3.4, if there is no objection. But I would keep 3.5, and 3.6 for the time being. Kind regards, Adam
Re: pkgsrc python default version -> 3.7
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 openssl conflict by the looks of it. Roy
