Re: moving py-setuptools in ports broke the installed port, or am I missing something?
On Fri, Mar 17, 2017 at 10:02 AM, Jason de Cordoba wrote: > Hey there, > > Portmaster broke again from a moved port > You can try: pkg set -n py27-setuptools27:py27-setuptools pkg set -o devel/py-setuptools27:devel/py27-setuptools (from /usr/ports/UPDATING) Cheers, Antoine ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: USE_PYTHON=concurrent
On Tue, Mar 31, 2015 at 9:39 PM, David Naylor wrote:
> On Tuesday, 31 March 2015 20:47:38 Roland Smith wrote:
>> On Mon, Mar 30, 2015 at 09:14:40PM +0200, David Naylor wrote:
>> > Hi,
>> >
>> > I am investigating converting my ports to concurrent however I am not sure
>> > how concurrent is supposed to work:
>> >
>> > I looked in /usr/ports/Mk and only found a documentation reference to
>> > 'concurrent'. Setting USE_PYTHON=concurrent doesn't appear to actually
>> > change any behaviour.
>> >
>> > Please could you explain this for me?
>>
>> From “/usr/ports/Mk/Uses/python.mk”:
>>
>> concurrent - Indicates that the port can be installed for
>> different python versions at the same time. The port
>> is supposed to use a unique prefix for certain
>> directories using USES=uniquefiles:dirs (see the
>> uniquefiles.mk Uses for details about the
>> directories), if set to yes. Binaries receive an
>> additional suffix, based on ${PYTHON_VER}.
>>
>> The values for the uniquefiles USES are set as
>> follows:
>>
>> UNIQUE_PREFIX= ${PYTHON_PKGNAMEPREFIX}
>> UNIQUE_SUFFIX= -${PYTHON_VER}
>>
>> If the port is installed for the current default
>> python version, scripts and binaries in
>>
>> ${PREFIX}/bin
>> ${PREFIX}/sbin
>> ${PREFIX}/libexec
>>
>> are linked from the prefixed version to the
>> prefix-less original name, e.g.
>> bin/foo-2.7 --> bin/foo.
>>
>> So it seems that any port that only installs modules in
>> “/usr/local/lib/pythonX.Y/site-packages/” could be labeled as concurrent
>> as-is.
>>
>> If your port wants to put things in DOCSDIR, EXAMPLESDIR, DATADIR, WWWDIR or
>> ETCDIR, you should add “USES=uniquefiles:dirs” to your port's Makefile.
>>
>> Also read “/usr/ports/Mk/Uses/uniquefiles.mk”.
>
> Thank you for your explanation, to confirm:
>
> So 'concurrent' shouldn't actually change any logic, but act as a flag for a
> build tool at actually build multiple versions of the port based on available
> and supported python versions? (However one might need to use uniquefiles to
> prevent file conflicts with the multiple packages from this port.)
Hi,
No, it isn't used as a flag for build tools.
USE_PYTHON=concurrent or USES=uniquefiles should be used to install
simultaneously a port for 2 versions of python, when those 2
installations would conflict otherwise (e.g. would install files with
the same name in ${PREFIX}/bin or same directory name for ${DOCSDIR}).
Ports that only install in ${PREFIX}/lib/pythonX.Y don't need anything.
Cheers,
Antoine
___
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"
Re: python waf bypasses _MAKE_JOBS number
On Fri, Jan 9, 2015 at 5:52 PM, Sean Bruno wrote:
> Marcus:
>
> The thing that I would like "fixed" is python waf ignoring the fact
> that it should not try and detect the number of CPUs on the system.
>
Let me rephrase the problem, there are some problems in some
individual ports using waf.
Those ports do not respect ${MAKE_JOBS_NUMBER}, especially when
MAKE_JOBS_NUMBER=1.
This breaks qemu which is not multi job friendly (people using qemu
have DISABLE_MAKE_JOBS=yes which sets MAKE_JOBS_NUMBER to 1).
Cheers,
Antoine
___
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"
Re: /usr/ports/devel/py-gobject3: typo?
On Tue, Nov 25, 2014 at 9:02 AM, Marcus von Appen wrote: > Yes, it looks like DEPENDS_ARGS is the culprit here. The conditionals > within the configure script of pygobject3-common can run into > situations, where they do not override PYTHON_VERSION properly. > > We have two ways around that: > > - override PYTHON_VERSION in the individual ports, which break that way > - quickly done > - has to be done on a port-per-port basis > - adds another "hack" to maintain per port > - rename PYTHON_VERSION in the ports infrastructure to something else > - more clean approach(?) > - not done quickly > - may affect users using PYTHON_VERSION actively > - may need other ports to receive additional changes > - needs a full exp-run (without isolations, so poudriere is a no-op) > > As workaround, I'd go with the first option for now. Depending on how > the gnome stuff evolves, we may need to look into option two as well. Hi, I think we have to rename the variable passed in DEPEND_ARGS to something else, as PYTHON_VERSION affects negatively all ports using autoconf to detect python. Cheers, Antoine ___ 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"
Re: svn commit: r371567 - in head/lang/python34: . files
On Mon, Oct 27, 2014 at 12:54 PM, Dmitry Sivachenko wrote:
> Author: demon
> Date: Mon Oct 27 12:54:04 2014
> New Revision: 371567
> URL: https://svnweb.freebsd.org/changeset/ports/371567
> QAT: https://qat.redports.org/buildarchive/r371567/
>
> Log:
> Update to version 3.4.2.
> Two deleted patches were integrated upstream.
>
> Reviewed by: koobs in D967
>
> Deleted:
> head/lang/python34/files/patch-issue21166
> head/lang/python34/files/patch-issue21704
> Modified:
> head/lang/python34/Makefile
> head/lang/python34/distinfo
> head/lang/python34/files/patch-Makefile.pre.in
> head/lang/python34/files/patch-Modules-_ctypes-libffi-configure
> head/lang/python34/pkg-plist
Hi,
This fails to build on i386 (_ctypes/libffi error)
Cheers,
Antoine
>
> Modified: head/lang/python34/Makefile
> ==
> --- head/lang/python34/Makefile Mon Oct 27 12:49:22 2014(r371566)
> +++ head/lang/python34/Makefile Mon Oct 27 12:54:04 2014(r371567)
> @@ -2,8 +2,7 @@
> # $FreeBSD$
>
> PORTNAME= python34
> -PORTVERSION= 3.4.1
> -PORTREVISION= 5
> +PORTVERSION= 3.4.2
> CATEGORIES=lang python ipv6
> MASTER_SITES= PYTHON
> MASTER_SITE_SUBDIR=ftp/python/${PORTVERSION}
>
> Modified: head/lang/python34/distinfo
> ==
> --- head/lang/python34/distinfo Mon Oct 27 12:49:22 2014(r371566)
> +++ head/lang/python34/distinfo Mon Oct 27 12:54:04 2014(r371567)
> @@ -1,2 +1,2 @@
> -SHA256 (python/Python-3.4.1.tar.xz) =
> c595a163104399041fcbe1c5c04db4c1da94f917b82ce89e8944c8edff7aedc4
> -SIZE (python/Python-3.4.1.tar.xz) = 14125788
> +SHA256 (python/Python-3.4.2.tar.xz) =
> 1c6d9682d145c056537e477bbfa060ce727f9edd38df1827e0f970dcf04b2def
> +SIZE (python/Python-3.4.2.tar.xz) = 14223804
>
> Modified: head/lang/python34/files/patch-Makefile.pre.in
> ==
> --- head/lang/python34/files/patch-Makefile.pre.in Mon Oct 27 12:49:22
> 2014(r371566)
> +++ head/lang/python34/files/patch-Makefile.pre.in Mon Oct 27 12:54:04
> 2014(r371567)
> @@ -6,13 +6,17 @@
> # Submitted by: antoine@ (r358029)
> # TODO: Upstream
>
> ./Makefile.pre.in.orig 2014-05-19 05:19:39.0 +
> -+++ ./Makefile.pre.in 2014-06-15 12:12:17.0 +
> -@@ -70,18 +70,15 @@
> +--- Makefile.pre.in.orig 2014-10-08 12:18:14.0 +0400
> Makefile.pre.in2014-10-19 12:37:14.0 +0400
> +@@ -70,23 +70,20 @@
> OPT= @OPT@
> BASECFLAGS= @BASECFLAGS@
> BASECPPFLAGS= @BASECPPFLAGS@
> -CONFIGURE_CFLAGS= @CFLAGS@
> + # CFLAGS_NODIST is used for building the interpreter and stdlib C
> extensions.
> + # Use it when a compiler flag should _not_ be part of the distutils CFLAGS
> + # once Python is installed (Issue #21121).
> + CONFIGURE_CFLAGS_NODIST=@CFLAGS_NODIST@
> -CONFIGURE_CPPFLAGS= @CPPFLAGS@
> -CONFIGURE_LDFLAGS=@LDFLAGS@
> # Avoid assigning CFLAGS, LDFLAGS, etc. so users can use them on the
> @@ -20,6 +24,7 @@
> # values.
> -PY_CFLAGS=$(BASECFLAGS) $(OPT) $(CONFIGURE_CFLAGS) $(CFLAGS)
> $(EXTRA_CFLAGS)
> +PY_CFLAGS=$(BASECFLAGS) $(OPT) $(CFLAGS) $(EXTRA_CFLAGS)
> + PY_CFLAGS_NODIST=$(CONFIGURE_CFLAGS_NODIST) $(CFLAGS_NODIST)
> # Both CPPFLAGS and LDFLAGS need to contain the shell's value for setup.py
> to
> # be able to build extension modules using the directories specified in the
> # environment variables
> @@ -30,7 +35,7 @@
> NO_AS_NEEDED= @NO_AS_NEEDED@
> LDLAST= @LDLAST@
> SGI_ABI= @SGI_ABI@
> -@@ -1065,12 +1062,6 @@
> +@@ -1080,12 +1077,6 @@
> else true; \
> fi
> (cd $(DESTDIR)$(BINDIR); $(LN) -s python$(VERSION)$(EXE)
> python3$(EXE))
> @@ -43,7 +48,7 @@
> -rm -f $(DESTDIR)$(BINDIR)/python3-config
> (cd $(DESTDIR)$(BINDIR); $(LN) -s python$(VERSION)-config
> python3-config)
> -rm -f $(DESTDIR)$(LIBPC)/python3.pc
> -@@ -1333,6 +1324,12 @@
> +@@ -1348,6 +1339,12 @@
> $(INSTALL_SCRIPT) $(srcdir)/install-sh $(DESTDIR)$(LIBPL)/install-sh
> $(INSTALL_SCRIPT) python-config.py $(DESTDIR)$(LIBPL)/python-config.py
> $(INSTALL_SCRIPT) python-config
> $(DESTDIR)$(BINDIR)/python$(LDVERSION)-config
>
> Modified: head/lang/python34/files/patch-Modules-_ctypes-libffi-configure
> ==
> --- head/lang/python34/files/patch-Modules-_ctypes-libffi-configure Mon
> Oct 27 12:49:22 2014(r371566)
> +++ head/lang/python34/files/patch-Modules-_ctypes-libffi-configure Mon
> Oct 27 12:54:04 2014(r371567)
> @@ -1,11 +1,11 @@
> ./Modules/_ctypes/libffi/configure.orig2013-05-15 20:32:57.0
> +0400
> -+++ ./Modules/_ctypes/libffi/configure 2013-05-18 10:56:03.0 +0400
> -@@ -6889,
Re: svn commit: r369447 - head/math/py-numpy
On Wed, Oct 1, 2014 at 11:17 PM, Thierry Thomas wrote: > Le mer 1 oct 14 à 22:53:45 +0200, Antoine Brodin > écrivait : > >> And those 2: >> >> http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369680/logs/errors/wspr-3.00.r2511_8.log >> http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369680/logs/errors/wsjt-9.1.r2511_5.log >> >> Are you sure it's no a bug in numpy? >> Manually adding -shared to all those ports doesn't look too right. > > I'm wondering too... This is rather strange, and I cannot explain why > this failure appears now. > > For sure numpy was broken before my patch: it was impossible to use it > without setting LD_LIBRARY_PATH to the libfortran directory. But I don't > understand how it could be related to this missing '-shared'. > > In the meantime we also upgraded Gcc from 4.7 to 4.8, and this produces > also new failures, e.g. with cad/kicad: it was OK with 4.7 but does not > compile anymore with 4.8. Hi, The failures are not related to the gcc 4.7 -> gcc 4.8 switch (I did the exp-run) Cheers, Antoine ___ 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"
Re: svn commit: r369447 - head/math/py-numpy
On Wed, Oct 1, 2014 at 9:13 PM, Thierry Thomas wrote: > Le mer 1 oct 14 à 19:55:09 +0200, Antoine Brodin > écrivait : > >> Hi, > > Hello, > >> 2 others: >> >> http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369680/logs/errors/py27-obspy-0.9.2_2.log >> http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369680/logs/errors/py27-pymc-2.3_2,1.log > > Same cause, same remedy! > > I have tested the two attached patches, and they fix the issue. And those 2: http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369680/logs/errors/wspr-3.00.r2511_8.log http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369680/logs/errors/wsjt-9.1.r2511_5.log Are you sure it's no a bug in numpy? Manually adding -shared to all those ports doesn't look too right. Cheers, Antoine ___ 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"
Re: svn commit: r369447 - head/math/py-numpy
On Tue, Sep 30, 2014 at 10:59 AM, wrote: > Selon Dmitry Sivachenko le mar 30 sep 10:40:46 2014 : > >> I committed your fix for py-scipy and py-symeig port, I also verified >> several other py-numpy-dependent ports: they have no such an issue. Hi, 2 others: http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369680/logs/errors/py27-obspy-0.9.2_2.log http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369680/logs/errors/py27-pymc-2.3_2,1.log Cheers, Antoine > > > Thanks Dmitry! > > -- > Th. Thomas. ___ 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"
Re: svn commit: r369447 - head/math/py-numpy
On Mon, Sep 29, 2014 at 9:09 PM, Dmitry Sivachenko wrote: > > On 29 сент. 2014 г., at 17:53, Antoine Brodin wrote: > >> On Sun, Sep 28, 2014 at 12:40 PM, Dmitry Sivachenko >> wrote: >>> Author: demon >>> Date: Sun Sep 28 10:40:54 2014 >>> New Revision: 369447 >>> URL: http://svnweb.freebsd.org/changeset/ports/369447 >>> QAT: https://qat.redports.org/buildarchive/r369447/ >>> >>> Log: >>> Fix >>> ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by >>> /usr/local/lib/gcc48/libgfortran.so.3 not found >>> error when importing numpy module. >>> >>> PR: 188114 >>> Patch by Thierry Thomas >>> >>> Modified: >>> head/math/py-numpy/Makefile >> >> Hi, >> >> This change breaks science/py-scipy >> >> http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369506/logs/errors/py27-scipy-0.14.0_4.log >> > > > Thanks for noticing. I informed Thierry and will investigate by myself too. > Thierry reports he successfully built py-scipy on 10/stable, so this problem > occurs only under some conditions. math/py-symeig too, error log at http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369506/logs/errors/py27-symeig-1.5_1.log (for both, -shared is missing) Cheers, Antoine ___ 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"
Re: svn commit: r369447 - head/math/py-numpy
On Sun, Sep 28, 2014 at 12:40 PM, Dmitry Sivachenko wrote:
> Author: demon
> Date: Sun Sep 28 10:40:54 2014
> New Revision: 369447
> URL: http://svnweb.freebsd.org/changeset/ports/369447
> QAT: https://qat.redports.org/buildarchive/r369447/
>
> Log:
> Fix
> ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by
> /usr/local/lib/gcc48/libgfortran.so.3 not found
> error when importing numpy module.
>
> PR: 188114
> Patch by Thierry Thomas
>
> Modified:
> head/math/py-numpy/Makefile
Hi,
This change breaks science/py-scipy
http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369506/logs/errors/py27-scipy-0.14.0_4.log
Cheers,
Antoine
>
> Modified: head/math/py-numpy/Makefile
> ==
> --- head/math/py-numpy/Makefile Sun Sep 28 10:38:02 2014(r369446)
> +++ head/math/py-numpy/Makefile Sun Sep 28 10:40:54 2014(r369447)
> @@ -3,7 +3,7 @@
>
> PORTNAME= numpy
> PORTVERSION= 1.8.1
> -PORTREVISION= 3
> +PORTREVISION= 4
> PORTEPOCH= 1
> CATEGORIES=math python
> MASTER_SITES= http://docs.scipy.org/doc/${PORTNAME}/:doc \
> @@ -23,6 +23,7 @@ RUN_DEPENDS= nosetests:${PORTSDIR}/devel
>
> USES= fortran python
> USE_PYTHON=concurrent distutils py3kplist
> +LDFLAGS+= -shared
>
> OPTIONS_DEFINE=ATLAS SUITESPARSE DOCS
> OPTIONS_DEFAULT= SUITESPARSE
> @@ -48,14 +49,12 @@ PLIST_FILES+= man/man1/f2py.1.gz
> .endif
>
> post-extract:
> - @${CP} ${DISTDIR}/numpy-ref-${PORTVERSION}.pdf ${WRKDIR}
> - @${CP} ${DISTDIR}/numpy-user-${PORTVERSION}.pdf ${WRKDIR}
> + ${CP} ${DISTDIR}/numpy-ref-${PORTVERSION}.pdf ${WRKDIR}
> + ${CP} ${DISTDIR}/numpy-user-${PORTVERSION}.pdf ${WRKDIR}
>
> post-patch:
> - @${REINPLACE_CMD} -e "s+%%FC%%+${FC}+"
> ${WRKSRC}/numpy/distutils/fcompiler/gnu.py
> - @${CP} ${FILESDIR}/site.cfg ${WRKSRC}/site.cfg
> -# ignore LDFLAGS from env, as it overrides internal flags (e.g. -shared) for
> some reason
> - @${REINPLACE_CMD} -e "s|'LDFLAGS'|None|"
> ${WRKSRC}/numpy/distutils/fcompiler/__init__.py
> + ${REINPLACE_CMD} -e "s+%%FC%%+${FC}+"
> ${WRKSRC}/numpy/distutils/fcompiler/gnu.py
> + ${CP} ${FILESDIR}/site.cfg ${WRKSRC}/site.cfg
>
> GCCLIBDIR_CMDS=${FC} -print-file-name=libgfortran.so|${SED} -e
> s/libgfortran.so//
>
>
___
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"
Re: svn commit: r369166 - head/lang/cython
On Sun, Sep 28, 2014 at 2:27 AM, Kubilay Kocak wrote: > On 26/09/2014 2:50 AM, Antoine Brodin wrote: >> On Wed, Sep 24, 2014 at 11:06 AM, Bartek Rutkowski wrote: >>> Author: robak >>> Date: Wed Sep 24 09:06:41 2014 >>> New Revision: 369166 >>> URL: http://svnweb.freebsd.org/changeset/ports/369166 >>> QAT: https://qat.redports.org/buildarchive/r369166/ >>> >>> Log: >>> lang/cython: update 0.20.2 -> 0.21 >>> >>> - Convert to USES=python >>> >>> PR: 193643 >>> Submitted by: Viltaly Magerya >>> Approved by: mentors (implicit) >> >> Hi, >> >> It seems that 2 ports are failing to build after this change: >> http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369213/logs/errors/py27-kivy-1.8.0_1.log >> http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369213/logs/errors/py27-tables-3.0.0_4.log >> >> Cheers, >> >> Antoine >> ___ >> 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" >> > > Create an issue report and assign to committer if no response is > received here, thanks! Hi, In such situation, we mark the ports BROKEN, we don't create issue for each individual port. So if nobody wants to fix, I will mark BROKEN and done. Antoine (portmgr hat on) ___ 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"
Re: svn commit: r369166 - head/lang/cython
On Wed, Sep 24, 2014 at 11:06 AM, Bartek Rutkowski wrote: > Author: robak > Date: Wed Sep 24 09:06:41 2014 > New Revision: 369166 > URL: http://svnweb.freebsd.org/changeset/ports/369166 > QAT: https://qat.redports.org/buildarchive/r369166/ > > Log: > lang/cython: update 0.20.2 -> 0.21 > > - Convert to USES=python > > PR: 193643 > Submitted by: Viltaly Magerya > Approved by: mentors (implicit) Hi, It seems that 2 ports are failing to build after this change: http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369213/logs/errors/py27-kivy-1.8.0_1.log http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369213/logs/errors/py27-tables-3.0.0_4.log Cheers, Antoine ___ 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"
Re: svn commit: r361263 - in head: . Mk
On Tue, Jul 8, 2014 at 6:14 PM, Marcus von Appen wrote:
> Author: mva
> Date: Tue Jul 8 16:14:33 2014
> New Revision: 361263
> URL: http://svnweb.freebsd.org/changeset/ports/361263
> QAT: https://qat.redports.org/buildarchive/r361263/
>
> Log:
> Support for installations based on the easy_install setup.py target has
> been removed from the Ports framework for Python software. The
> PYEASYINSTALL_* knobs and support for USE_PYDISTUTILS=easy_install have
> been removed.
>
> Phabric: D299
> With hat: python@
Hi,
There is a regression after this commit, more than 200 python modules
that use USE_PYDISTUTILS=yes but don't use autoplist orphan their
egginfo.
Cheers,
Antoine
>
> Modified:
> head/CHANGES
> head/Mk/bsd.python.mk
> head/Mk/bsd.sanity.mk
>
> Modified: head/CHANGES
> ==
> --- head/CHANGESTue Jul 8 16:09:29 2014(r361262)
> +++ head/CHANGESTue Jul 8 16:14:33 2014(r361263)
> @@ -10,6 +10,14 @@ in the release notes and/or placed into
>
> All ports committers are allowed to commit to this file.
>
> +20140708:
> +AUTHOR: m...@freebsd.org
> +
> + Support for installations based on the easy_install setup.py target has
> + been removed from the Ports framework for Python software. The
> + PYEASYINSTALL_* knobs and support for USE_PYDISTUTILS=easy_install have
> + been removed.
> +
> 20140623:
> AUTHOR: b...@freebsd.org
>
>
> Modified: head/Mk/bsd.python.mk
> ==
> --- head/Mk/bsd.python.mk Tue Jul 8 16:09:29 2014(r361262)
> +++ head/Mk/bsd.python.mk Tue Jul 8 16:14:33 2014(r361263)
> @@ -78,8 +78,8 @@ Python_Include_MAINTAINER=python@FreeBS
> #for ${PYTHON_PKGNAMEPREFIX}.
> #
> # PYTHON_VERSION - Version of the python binary in your ${PATH}, in the
> -#format "python2.0". Set this in
> your makefile in case you
> -#want to build extensions with an
> older binary.
> +#format "python2.0". Set this in
> your makefile in case
> +#you want to build extensions with
> an older binary.
> #default: depends on the version of
> your python binary
> #
> # PYTHON_VER - Version of the python binary in your ${PATH}, in the
> @@ -90,12 +90,12 @@ Python_Include_MAINTAINER= python@FreeBS
> #the format "python2.7".
> #
> # PYTHON2_DEFAULT_VERSION
> -# - Version of the default python2
> binary in your ${PATH}, in
> -#the format "python2.7".
> +# - Version of the default python2
> binary in your ${PATH},
> +#in the format "python2.7".
> #
> # PYTHON3_DEFAULT_VERSION
> -# - Version of the default python3
> binary in your ${PATH}, in
> -#the format "python3.2".
> +# - Version of the default python3
> binary in your ${PATH},
> +#in the format "python3.2".
> #
> # PYTHON_MAJOR_VER - Python version major number. 2 for python-2.x,
> #3 for python-3.x and so on.
> @@ -154,16 +154,17 @@ Python_Include_MAINTAINER=python@FreeBS
> #default: setup.py
> #
> # PYDISTUTILS_AUTOPLIST
> -# - Automatically generates the
> packaging list for a port that uses
> -# distutils or setuptools
> (easy_install) when defined.
> -# requires: USE_PYDISTUTILS
> +# - Automatically generates the
> packaging list for a port
> +#that uses distutils when defined.
> +#requires: USE_PYDISTUTILS
> #
> # PYTHON_PY3K_PLIST_HACK
> -# - Automatically generates Python 3.x
> compatible __pycache__ entries
> -# from a Python 2.x packaging list
> when defined. Use this for ports that
> -# do *not* use standard Python
> packaging mechanisms such as distutils
> -# or setuptools, and support *both*
> Python 2.x and 3.x. Not needed when
> -# PYDISTUTILS_AUTOPLIST is defined.
> +# - Automatically generates Python 3.x
> compatible
> +#
Re: python3 meta port and python34
On Mon, Jun 2, 2014 at 5:34 PM, Antoine Brodin wrote:
> Hi there,
>
> I see that the default version of python 3 has been switched to 3.4.
> There are a few issues with the python3 meta port:
>
> /usr/local/bin/python-shared3@ -> python-shared3.4
> /usr/local/bin/python-shared3-config@ -> python-shared3.4-config
> /usr/local/bin/python3@ -> python3.4
> /usr/local/bin/python3-config@ -> python3.4-config
> /usr/local/bin/python3.4*
> /usr/local/bin/python3.4m*
> /usr/local/bin/python3.4m-config*
I'm also wondering how ${PYTHON_CMD}-config (from bsd.python.mk) can
work with version 3.4
Cheers,
Antoine
___
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"
python3 meta port and python34
Hi there, I see that the default version of python 3 has been switched to 3.4. There are a few issues with the python3 meta port: /usr/local/bin/python-shared3@ -> python-shared3.4 /usr/local/bin/python-shared3-config@ -> python-shared3.4-config /usr/local/bin/python3@ -> python3.4 /usr/local/bin/python3-config@ -> python3.4-config /usr/local/bin/python3.4* /usr/local/bin/python3.4m* /usr/local/bin/python3.4m-config* Cheers, Antoine ___ 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"
bsd.python.mk patch for review
Hi there,
Currently default python versions are inconsistent:
- python 3.3 is the default python3 version
- python 3.4 is preferred over python 3.3 when a port needs a python
version in a specific range
The patch below should address this, please review/test.
Cheers,
Antoine
Index: Mk/bsd.python.mk
===
--- Mk/bsd.python.mk(revision 352778)
+++ Mk/bsd.python.mk(working copy)
@@ -289,7 +289,7 @@
But you specified ${_PYTHON_VERSION}
.else
.undef _PYTHON_VERSION
-.for ver in ${_PYTHON_ALLBRANCHES}
+.for ver in ${PYTHON2_DEFAULT} ${PYTHON3_DEFAULT} ${_PYTHON_ALLBRANCHES}
__VER=${ver}
.if !defined(_PYTHON_VERSION) && \
!(!empty(_PYTHON_VERSION_MINIMUM) && ( \
Index: Mk/bsd.python.mk
===
--- Mk/bsd.python.mk(revision 352778)
+++ Mk/bsd.python.mk(working copy)
@@ -289,7 +289,7 @@
But you specified ${_PYTHON_VERSION}
.else
.undef _PYTHON_VERSION
-.for ver in ${_PYTHON_ALLBRANCHES}
+.for ver in ${PYTHON2_DEFAULT} ${PYTHON3_DEFAULT} ${_PYTHON_ALLBRANCHES}
__VER= ${ver}
.if !defined(_PYTHON_VERSION) && \
!(!empty(_PYTHON_VERSION_MINIMUM) && ( \
___
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"
Re: Make python27 build as an unprivileged user
On Fri, Apr 4, 2014 at 12:51 AM, Julio Merino wrote: > On Thu, Apr 3, 2014 at 3:30 PM, Antoine Brodin wrote: >> koobs' new python34 port (not committed yet) packages fine as non >> root, so it seems doable. > > Sorry but I don't see how that's relevant. Python 3.4 is a much more > modern package than 2.7 and many things may have changed in its build > infrastructure. > > Yes, fixing the root cause is doable for sure, and I agree with you > that, ideally, this should be properly fixed. But: I don't think it's > worth our time considering that: 1) this is for the "old" 2.x branch > and 2) some knowledgeable people have already tried and failed at > doing so. > > As things currently are, the python27 package is broken when building > from ports as non-root. (Which by the way is annoying for > architectures without prebuilt packages; I have found this problem > under powerpc64!) > > What I'm proposing is that we trivially workaround the problem by > *temporarily* defining NEED_ROOT and later investigating the failure. > Doing the former does not preclude the latter, but at least fixes the > obvious bug. > > I don't want to put words on your mouth, but what I think you are > proposing is that we leave the package broken for an arbitrary > (possibly infinite) amount of time until someone decides to track and > fix the root cause. If you are offering to investigate this relatively > soon as the maintainer that's perfect though. > > So up to you really! If you do not agree with the workaround, I will > at least file a PR for proper tracking. Try attached patch. Cheers, Antoine Allow staging python27 as a regular user: - when compiling, don't compile the running command otherwise it fails to compile modules imported by the running command Sorry [Errno 13] Permission denied: '/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/getopt.pyc' Sorry [Errno 13] Permission denied: '/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/py_compile.pyc' Sorry [Errno 13] Permission denied: '/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/struct.pyc' Sorry [Errno 13] Permission denied: '/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/getopt.pyo' Sorry [Errno 13] Permission denied: '/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/py_compile.pyo' Sorry [Errno 13] Permission denied: '/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/struct.pyo' - ranlib before installing read only Index: lang/python27/files/patch-Makefile.pre.in === --- lang/python27/files/patch-Makefile.pre.in (revision 350060) +++ lang/python27/files/patch-Makefile.pre.in (working copy) @@ -1,6 +1,6 @@ ./Makefile.pre.in.orig 2013-04-06 18:02:34.0 +0400 -+++ ./Makefile.pre.in 2013-04-07 22:30:19.0 +0400 -@@ -281,9 +281,9 @@ +--- ./Makefile.pre.in.orig 2013-11-10 07:36:41.0 + ./Makefile.pre.in 2014-04-04 09:16:00.0 + +@@ -285,9 +285,9 @@ ## # AST @@ -12,3 +12,28 @@ AST_C=$(AST_C_DIR)/Python-ast.c AST_ASDL= $(srcdir)/Parser/Python.asdl +@@ -1006,12 +1006,12 @@ + $(DESTDIR)$(LIBDEST)/distutils/tests ; \ + fi + PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ +- $(PYTHON_FOR_BUILD) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \ ++ $(PYTHON_FOR_BUILD) -B -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \ + -d $(LIBDEST) -f \ + -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \ + $(DESTDIR)$(LIBDEST) + PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ +- $(PYTHON_FOR_BUILD) -Wi -tt -O $(DESTDIR)$(LIBDEST)/compileall.py \ ++ $(PYTHON_FOR_BUILD) -B -Wi -tt -O $(DESTDIR)$(LIBDEST)/compileall.py \ + -d $(LIBDEST) -f \ + -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \ + $(DESTDIR)$(LIBDEST) +@@ -1089,8 +1089,8 @@ + if test "$(SO)" = .dll; then \ + $(INSTALL_DATA) $(LDLIBRARY) $(DESTDIR)$(LIBPL) ; \ + else \ ++ $(RANLIB) $(LIBRARY) ; \ + $(INSTALL_DATA) $(LIBRARY) $(DESTDIR)$(LIBPL)/$(LIBRARY) ; \ +- $(RANLIB) $(DESTDIR)$(LIBPL)/$(LIBRARY) ; \ + fi; \ + else \ + echo Skip install of $(LIBRARY) - use make frameworkinstall; \ ___ 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"
Re: Make python27 build as an unprivileged user
On Thu, Apr 3, 2014 at 9:24 PM, Julio Merino wrote: > On Thu, Apr 03, 2014 at 09:06:03PM +0200, Antoine Brodin wrote: >> On Thu, Apr 3, 2014 at 9:01 PM, Julio Merino wrote: >> > Hello, >> > >> > I needed the patch below to be able to build python27 when using ports as >> > an unprivileged user. It is a bit too coarse-grained, but I think ports >> > does not offer a finer-grained mechanism to indicate that only the staging >> > phase needs root. >> > >> > (Note that pkgsrc marks all python packages as requiring root for the >> > stage phase... and I suppose it's because of the same problem I >> > encountered.) >> > >> > What do you think? (If you think this is OK, I'll need an explicit >> > approval >> > to commit.) >> >> Hi, >> >> It's better to understand and fix the cause of the failure as non-root >> than putting NEED_ROOT. > > pkgsrc has had the "need root" requirement in place for _years_ and people > have tried to fix it before. For these reasons, I don't think it's a trivial > thing to do this and I certainly do not have the time to investigate it at > the moment. koobs' new python34 port (not committed yet) packages fine as non root, so it seems doable. Cheers, Antoine ___ 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"
Re: Make python27 build as an unprivileged user
On Thu, Apr 3, 2014 at 9:01 PM, Julio Merino wrote: > Hello, > > I needed the patch below to be able to build python27 when using ports as > an unprivileged user. It is a bit too coarse-grained, but I think ports > does not offer a finer-grained mechanism to indicate that only the staging > phase needs root. > > (Note that pkgsrc marks all python packages as requiring root for the > stage phase... and I suppose it's because of the same problem I encountered.) > > What do you think? (If you think this is OK, I'll need an explicit approval > to commit.) Hi, It's better to understand and fix the cause of the failure as non-root than putting NEED_ROOT. Cheers, Antoine (with hat: portmgr) ___ 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"
Python and clang 3.4
Hi there,
Clang 3.4 was imported in head 3 days ago.
A few python extensions are broken because clang now refuses flags it
doesn't know.
For instance -R is not recognized, which breaks py-sqlite3, py-ldap2
and a few others.
Some failure logs are available at
http://package21.nyi.freebsd.org/bulk/head-default-baseline/2014-02-18_15h22m08s/logs/errors/py27-sqlite3-2.7.6_3.log
and
http://package21.nyi.freebsd.org/bulk/head-default-baseline/2014-02-18_15h22m08s/logs/errors/py27-ldap2-2.4.13.log
Below is a possible fix for python27:
Index: lang/python27/Makefile
===
--- lang/python27/Makefile (revision 345118)
+++ lang/python27/Makefile (working copy)
@@ -3,7 +3,7 @@
PORTNAME= python27
PORTVERSION= 2.7.6
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES=lang python ipv6
MASTER_SITES= PYTHON
MASTER_SITE_SUBDIR=${PYTHON_MASTER_SITE_SUBDIR}
Index: lang/python27/files/patch-Lib__distutils__unixccompiler.py
===
--- lang/python27/files/patch-Lib__distutils__unixccompiler.py (revision 0)
+++ lang/python27/files/patch-Lib__distutils__unixccompiler.py (working copy)
@@ -0,0 +1,11 @@
+--- ./Lib/distutils/unixccompiler.py.orig 2013-11-10
07:36:40.0 +
./Lib/distutils/unixccompiler.py 2014-02-19 15:41:48.0 +
+@@ -228,6 +228,8 @@
+ if sys.platform[:6] == "darwin":
+ # MacOSX's linker doesn't understand the -R flag at all
+ return "-L" + dir
++elif sys.platform[:7] == "freebsd":
++return "-Wl,-rpath=" + dir
+ elif sys.platform[:5] == "hp-ux":
+ if self._is_gcc(compiler):
+ return ["-Wl,+s", "-L" + dir]
Cheers,
Antoine
___
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"
Re: shebang problem with python, Was: [REL - head-i386-default][databases/postgresql-libpqxx] Failed for postgresql-libpqxx-4.0.1 in build
On Thu, Feb 13, 2014 at 8:22 PM, Palle Girgensohn wrote:
> Hi python@ and bapt@,
>
> I'm usnure how to fix this problem.
>
> postgresql-libpqxx needs python (shebang:ed) during the build process, and
> this is defined in the port using
>
> USE_PYTHON_BUILD= yes
> USES= gmake shebangfix
> SHEBANG_FILES= ${WRKSRC}/tools/splitconfig
>
>
> The shebangfix alters #!/usr/bin/python in tools/splitconfig to
> #!/usr/local/bin/python...
>
> But USE_PYTHON_BUILD only installs the python2 symlink, not the python
> symlink, so /usr/local/bin/python does not get installed in a clean room
> environment.
>
> I believe the port is agnostic to the version of python, so I don't want to
> enforce a specific version of python just for this port's build, but the
> build process does not automatically install the lang/python meta port.
>
> How is this supposed to work?
Hi,
You can use python_CMD= ${PYTHON_CMD} (currently installed python file name)
Since it's only a build dependency and the splitconfig file is not
packaged this shouldn't be a problem.
Cheers,
Antoine
___
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"
