Re: python-3.3

[Ruslan Makhmatkhanov]

Dmitry Sivachenko wrote on 19.12.2012 14:50:

Hello!

Would you mind if I commit patch sent by koobs@ to freebsd-python a while ago 
to introduce python version 3.3?

Thanks.


I think it should be committed if it's ok. I planning to work on this at 
this weekend, but as I said in past if somebody has a chance to do this 
earlier - please do.


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: python3 plist shim

[Ruslan Makhmatkhanov]

Hello,

I'm planning to apply this patch to Mk/bsd.python.mk soon. It's an 
nivit's solution from devel/py-virtualenv for changes, introduced in PEP 
3147 [1]. It will not affect default packages build, because packages 
are not yet building for python3 on cluster, but it will affect python 
ports, built with python3, that already has fix like that applied 
locally. I tested it with dozen of ports and everything seems fine. 
Local fixes will be removed right after this change. Please tell me if 
there is any objections or suggestions on this. Thanks.


[1] http://www.python.org/dev/peps/pep-3147/

--
Regards,
Ruslan

Tinderboxing kills... the drives.
Index: bsd.python.mk
===
--- bsd.python.mk   (revision 310860)
+++ bsd.python.mk   (working copy)
@@ -666,6 +666,23 @@
 
 .endif # defined(USE_TWISTED)
 
+.if ${PYTHON_REL} = 320
+# When Python version is 3.2+ we rewrite all the filenames
+# of TMPPLIST that end with .py[co], so that they conform
+# to PEP 3147 (see http://www.python.org/dev/peps/pep-3147/)
+PYMAGICTAG=${PYTHON_CMD} -c 'import imp; print(imp.get_tag())'
+add-plist-post:
+   @${AWK} '\
+   /\.py[co]$$/  !($$0 ~ / pc /) {id = match($$0, 
/\/[^\/]+\.py[co]$$/); if (id != 0) {d = substr($$0, 1, RSTART - 1); dirs[d] = 
1}; sub(/\.py[co]$$/,  . mt ); sub(/[^\/]+\.py[co]$$/, pc /); print; 
next} \
+   /^@dirrm / {d = substr($$0, 8); if (d in dirs) {print $$0 / 
pc}; print $$0; next} \
+   {print} \
+   END {if (sp in dirs) {print @dirrm  sp / pc}} \
+   ' \
+   pc=__pycache__ mt=$$(${PYMAGICTAG}) 
sp=${PYTHON_SITELIBDIR:S,${PYTHONBASE}/,,g} \
+   ${TMPPLIST}  ${TMPPLIST}.pyc_tmp
+   @${MV} ${TMPPLIST}.pyc_tmp ${TMPPLIST}
+.endif
+
 # XXX Hm, should I export some of the variables above to *_ENV?
 
 # If multiple Python versions are installed and cmake is used, it might
___
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: bsd.python.mk: python3 plist shim

[Ruslan Makhmatkhanov]

Marcus von Appen wrote on 23.01.2013 20:50:

Hi,

On, Wed Jan 23, 2013, Ruslan Makhmatkhanov wrote:



Hello,

I'm planning to apply this patch to Mk/bsd.python.mk soon. It's an
nivit's solution from devel/py-virtualenv for changes, introduced in PEP
3147 [1]. It will not affect default packages build, because packages
are not yet building for python3 on cluster, but it will affect python
ports, built with python3, that already has fix like that applied
locally. I tested it with dozen of ports and everything seems fine.
Local fixes will be removed right after this change. Please tell me if
there is any objections or suggestions on this. Thanks.


[...]

I still do not get what the patch should exactly do and I am too lazy to
refresh my awk skills and try it out myself. If that patch is just about
the [INSERT cpython-correct-XX].pyc stuff, there is no need for it in my
opinion.
Can you please provide details on what the patch does?

Cheers
Marcus


Yes, it does just that by adding __pycache__ directories with compiled 
and optimized bytecode into pkg-plist. This allows us to make packages 
for python 3.2+ successfully.


I can't explain more than that, because I treat that as some magic 
sequence for fixing py3 packages and that already applied locally in 
many ports, so it's time to just stop duplicating this pattern over the 
tree.


Why do you think this isn't needed? Do you prefer patching the python 
internals to get the 2.x behavior or what?


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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/lang/python26

[Ruslan Makhmatkhanov]

tom oakes wrote on 30.01.2013 08:54:

I recently did an upgrade from freebsd 8.2 to freebsd 8.3

I did a portsnap fetch ans portsnap update just before I got this error.


I tried doing a make in  the firefox port directory and got error of
packages not upto date. I did a portupgrade -R of  those packages, which
worked until I got an error suggesting I run pkgdb _F which I did twice,
accepting the default options.

Again doing a make in .../www/firefox upgrade firefox and got the folloe
error message:

===Verifying install for
/usr/local/lib/python2.6/site-packages/_sqlite3.so in
/usr/ports/databases/py-sqlite3
===  Found saved configuration for sqlite3-3.7.14.1
= Python-2.6.6.tar.xz is not in /usr/ports/lang/python26/distinfo.
= Either /usr/ports/lang/python26/distinfo is out of date, or
= Python-2.6.6.tar.xz is spelled incorrectly.
*** Error code 1

Stop in /usr/ports/databases/py-sqlite3.
*** Error code 1

Stop in /usr/ports/www/firefox.
*** Error code 1

Stop in /usr/ports/www/firefox.

I don't see what to try next!

Either  portsnap did not do its job, or something is wrong with the port.

Thanks
Tom Oakes   email eoakes@comcast,net


Hi,

your ports tree is not in sync somehow. You have fresh Mk/bsd.python.mk, 
but quite old lang/python26:


root@smeshariki4:/usr/ports/lang/python26 # make distclean
===  Cleaning for python26-2.6.8_4
===  Deleting distfiles for python26-2.6.8_4
root@smeshariki4:/usr/ports/lang/python26 # make fetch
= Python-2.6.8.tar.xz doesn't seem to exist in /usr/ports/distfiles/python.
= Attempting to fetch 
http://www.python.org/ftp/python/2.6.8/Python-2.6.8.tar.xz
Python-2.6.8.tar.xz   100% of 9112 kB 1064 kBps 
00m09s


Try to do `portsnap extract` and see if it helps.

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: ports/176375: [PATCH] sysutils/py-salt-api: fix build and removal

[Ruslan Makhmatkhanov]

The following reply was made to PR ports/176375; it has been noted by GNATS.

From: Ruslan Makhmatkhanov cvs-...@yandex.ru
To: Geoff Garside free...@geoffgarside.co.uk
Cc: bug-follo...@freebsd.org
Subject: Re: ports/176375: [PATCH] sysutils/py-salt-api: fix build and removal
Date: Sat, 23 Feb 2013 23:55:08 +0400

 Hi Geoff,
 
 Geoff Garside wrote on 23.02.2013 21:14:
 
  Number: 176375
  Category:   ports
  Synopsis:   [PATCH] sysutils/py-salt-api: fix build and removal
 
 [...]
 
  -BUILD_DEPENDS+= ${PYTHON_PKGNAMEPREFIX}salt:${PORTSDIR}/sysutils/py-salt
  +BUILD_DEPENDS+= salt:${PORTSDIR}/sysutils/py-salt
 
 it's ok to leave ${PYTHON_PKGNAMEPREFIX}, but it should be used like 
 this (note the version specification):
 
 BUILD_DEPENDS+=
${PYTHON_PKGNAMEPREFIX}salt0:${PORTSDIR}/sysutils/py-salt
 
 -- 
 Regards,
 Ruslan
 
 Tinderboxing kills... the drives.
___
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: databases/py-sqlite3 breaks due to update in libffi

[Ruslan Makhmatkhanov]

Hi,

Joseph A. Nagy, Jr wrote on 05.03.2013 11:43:

python@ CC'd as listed maintainer for py-sqlite3, please reply-all or
make sure I am CC'd in all responses as I'm not subscribed to python@.


I can't reproduce. I had libffi-3.0.11 and just updated it to 3.0.12. 
Then tried to build py-sqlite3 - no errors. Checked with pkg_libchk - no 
port that missing old libffi library. So I believe that you failed to 
follow UPDATING:20130128 in it's time.
Right now you may rebuild python to fix that, and check your installed 
ports with ``pkg_libchk -q'' (from sysutils/bsdadminscripts) to get the 
list of ports you need to rebuild.




=== www/firefox 2/3  py27-sqlite3-2.7.3_2 (14/14)

===  Cleaning for py27-sqlite3-2.7.3_3
===   py27-sqlite3-2.7.3_3 depends on file: /usr/local/sbin/pkg - found
===  Extracting for py27-sqlite3-2.7.3_3
= SHA256 Checksum OK for python/Python-2.7.3.tar.xz.
===  Patching for py27-sqlite3-2.7.3_3
===   py27-sqlite3-2.7.3_3 depends on file: /usr/local/bin/python2.7 -
found
===   py27-sqlite3-2.7.3_3 depends on shared library: sqlite3 - found
===  Configuring for py27-sqlite3-2.7.3_3
Traceback (most recent call last):
   File setup.py, line 36, in module
 import ctypes
   File /usr/local/lib/python2.7/ctypes/__init__.py, line 10, in module
 from _ctypes import Union, Structure, Array
ImportError: Shared object libffi.so.5 not found, required by
_ctypes.so
*** [do-configure] Error code 1

Stop in /usr/ports/databases/py-sqlite3.

=== make failed for databases/py-sqlite3
=== Aborting update

=== Update for py27-sqlite3-2.7.3_2 failed
=== Aborting update

=== Update for www/firefox failed
=== Aborting update

The last entry in /usr/ports/UPDATING regarding libffi is
20130128:
   AFFECTS: users of libffi
   AUTHOR j...@freebsd.org

   libffi has been updated to 3.0.11.  Please rebuild all ports that
   depends on it:

   If you use portmaster:
 portmaster -w -r libffi
   If you use portupgrade:
 portupgrade -fr devel/libffi
   If you use pkgng with binary packages:
 pkg install -fR devel/libffi

I don't recall even having libffi at that time, nor have I had problem
until now, though this problem wouldn't be solved by the update
instructions above.



--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: Fwd: py27-scriptaculous-1.8.1.1_2 failed on amd64 9

[Ruslan Makhmatkhanov]

Hi,

Martin Wilke wrote on 21.03.2013 13:34:



Begin forwarded message:


From: Portbuild user portbu...@freebsd.org
Subject: py27-scriptaculous-1.8.1.1_2 failed on amd64 9
Date: March 21, 2013 5:03:02 PM GMT+08:00
To: er...@freebsd.org, m...@freebsd.org

You can also find this build log at

  
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/a.9.20130321030640.pointyhat/py27-scriptaculous-1.8.1.1_2.log


Finally got it. This patch (against devel/py-TGScheduler) will fix the 
issue. Sorry for delay.


Wen, would you please approve the patch attached?

--
Regards,
Ruslan

Tinderboxing kills... the drives.
Index: Makefile
===
--- Makefile(revision 314836)
+++ Makefile(working copy)
@@ -1,12 +1,9 @@
-# Ports collection makefile for:   py-TGScheduler
-# Date created:Dec 16, 2011
-# Whom:Wen Hepingwenhep...@gmail.com
-#
+# Created by: Wen Heping wenhep...@gmail.com
 # $FreeBSD$
-#
 
 PORTNAME=  TGScheduler
 PORTVERSION=   1.6.3
+PORTREVISION=  1
 CATEGORIES=devel python
 MASTER_SITES=  CHEESESHOP
 PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
@@ -14,9 +11,16 @@
 MAINTAINER=w...@freebsd.org
 COMMENT=   Turbogears Scheduler
 
+BUILD_DEPENDS= 
${PYTHON_PKGNAMEPREFIX}dateutil=1.5:${PORTSDIR}/devel/py-dateutil
 RUN_DEPENDS=   
${PYTHON_PKGNAMEPREFIX}dateutil=1.5:${PORTSDIR}/devel/py-dateutil
 
 USE_PYTHON=yes
 USE_PYDISTUTILS=easy_install
 
+post-patch:
+   @${REINPLACE_CMD} -e 's,2.0dev,!=2.0,g' ${WRKSRC}/setup.py
+
+regression-test: build
+   @cd ${WRKSRC}  ${PYTHON_CMD} ${PYSETUP} test
+
 .include bsd.port.mk
___
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: Fwd: py27-scriptaculous-1.8.1.1_2 failed on amd64 9

[Ruslan Makhmatkhanov]

Martin Wilke wrote on 21.03.2013 13:34:



Begin forwarded message:


From: Portbuild user portbu...@freebsd.org
Subject: py27-scriptaculous-1.8.1.1_2 failed on amd64 9
Date: March 21, 2013 5:03:02 PM GMT+08:00
To: er...@freebsd.org, m...@freebsd.org

You can also find this build log at

  
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/a.9.20130321030640.pointyhat/py27-scriptaculous-1.8.1.1_2.log

building py27-scriptaculous-1.8.1.1_2 on gohan10.freebsd.org


Should be fixed in r314839.

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: can't compile py-ldap2

[Ruslan Makhmatkhanov]

Hi,

Len Conrad wrote on 21.03.2013 16:23:

building '_ldap' extension
cc -DNDEBUG -O2 -pipe -fno-strict-aliasing -O2 -pipe -DLDAP_DEPRECATED 
-fno-strict-aliasing -fPIC -DHAVE_TLS -DHAVE_LIBLDAP_R 
-DLDAPMODULE_VERSION=2.4.10 -IModules -I/usr/local/include 
-I/usr/local/include/sasl -I/usr/include -I/usr/local/include/python2.7 -c 
Modules/LDAPObject.c -o temp.freebsd-8.2-RELEASE-i386-2.7/Modules/LDAPObject.o
In file included from Modules/common.h:10,
  from Modules/LDAPObject.c:4:
/usr/local/include/python2.7/Python.h:166:17: error: pth.h: No such file or 
directory
error: command 'cc' failed with exit status 1
*** Error code 1

the same pkg in ftparchive for 8.2 is for python 2.6.

Any way to get this compiled?

thanks,
Len


Am I right that you disabled THREADS options when building python? If 
yes, try to enable it and reinstall python, then try to build py-ldap2.


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: ports/177195: [MAINTAINER] www/py-django-tastypie: update to 0.9.14

[Ruslan Makhmatkhanov]

The following reply was made to PR ports/177195; it has been noted by GNATS.

From: Ruslan Makhmatkhanov cvs-...@yandex.ru
To: William Grzybowski willia...@gmail.com
Cc: bug-follo...@freebsd.org
Subject: Re: ports/177195: [MAINTAINER] www/py-django-tastypie: update to
 0.9.14
Date: Thu, 21 Mar 2013 17:53:05 +0400

 William Grzybowski wrote on 21.03.2013 17:49:
 
  Number: 177195
  Category:   ports
  Synopsis:   [MAINTAINER] www/py-django-tastypie: update to 0.9.14
 
 [...]
 
  --- py-dateutil.patch begins here ---
  Index: Makefile
  ===
  --- Makefile (revision 313459)
  +++ Makefile (working copy)
  @@ -3424,6 +3424,7 @@
SUBDIR += py-dal
SUBDIR += py-darcsver
SUBDIR += py-dateutil
  +SUBDIR += py-dateutil2
SUBDIR += py-dbus
SUBDIR += py-decorator
SUBDIR += py-decoratortools
 
 Wrong patch, I believe :)
 
 -- 
 Regards,
 Ruslan
 
 Tinderboxing kills... the drives.
___
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: ports/177350: x11-toolkits/py-qt: [PATCH] fix provided from DragonFly Ports

[Ruslan Makhmatkhanov]

Hi John,

John Marino wrote on 25.03.2013 20:30:

The following reply was made to PR ports/177350; it has been noted by GNATS.

From: John Marino dr...@marino.st
To: bug-follo...@freebsd.org
Cc:
Subject: Re: ports/177350: x11-toolkits/py-qt: [PATCH] fix provided from 
DragonFly
  Ports
Date: Mon, 25 Mar 2013 17:26:17 +0100

   From that error log, I'd say there was a mistake applying the patch.
  There is no ANY definition in the compile line which the extra cxx
  flags are supposed to add.

  Yes, this patch is to be applied after the existing patch is applied.
   From that, you can of course regenerate a new single patch for configure.

  I think there is a misunderstanding about the nature of this PR.  py-qt
  builds on DragonFly Ports because I patched it.  It came up on the mail
  list that somebody wanted it fixed on FreeBSD.  I had the solution and I
  spent a couple of minutes writing a PR to let FreeBSD Ports developers
  know that.

  I never meant that these patches were a drop-in fix.  I didn't have the
  time to generate a patch and test in on FreeBSD.  I was leaving that up
  to the port maintainer.

  In any case, I'd double check the work because applying this patch on
  top of the existing patches *does* fix it on DragonFly and NetBSD.  The
  error in the log looks like the error I saw before any patch was
  applied, so that's why I think suspect the patch in this PR wasn't
  accurately applied.


Thank you for your efforts. This is what I'm trying to compile:
http://people.freebsd.org/~rm/py-qt.tgz

Would you please confirm, I merged it right?

PS. Unfortunately, this port is unmaintained, so in that case it's up to 
submitter to provide correct patch. But I had tried to and I fail :). So 
please help.


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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 2.7.4 Released (but I had touble updating the port)

[Ruslan Makhmatkhanov]

Pedro F. Giffuni wrote on 08.04.2013 08:08:

Hello guys;

There is a new bugfix release in the 27 series with hundreds of
bugfixes:
http://hg.python.org/cpython/file/9290822f2280/Misc/NEWS

I gave a try at updating the python27 port and it was rather easy to
get started (almost all patches apply cleanly) but I get this problem
  when building:

...
cc -c -fno-strict-aliasing -O2 -fno-strict-aliasing -pipe -march=nocona
-DNDEBUG -O2 -fno-strict-aliasing -pipe -march=nocona  -I. -IInclude
-I./../Include -fPIC -DPy_BUILD_CORE -o Python/Python-ast.o
Python/Python-ast.c
cc: Python/Python-ast.c: No such file or directory
cc: No input files specified
*** [Python/Python-ast.o] Error code 1

The file actually exists.

I went ahead and reported the issue upstream (Issue17649) but it is
irreproducible in their buildbot and the problem is not really theirs:
it looks like the hacks that we do to stop some modules from building
and the environment used to build the code out-of-tree don#x27;t get along
very well.

Perhaps someone here knows the port well enough to provide a fix?
I guess it should be possible to modify the makefile to skip generating
that file since it exists already but that#x27;s not very clean ;).

Regards,

Pedro.


As Marcus already said, the problem in changed path to AST_C_DIR (I also 
changed AST_H_DIR in the same way).


Here is the updated version by the way (pkg-plist changes is not yet 
included):

https://github.com/mexicarne/newpython/commit/7f03049da6883f1eb145a73e83c73be5fd6378a5


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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 2.7.4 Released (but I had touble updating the port)

[Ruslan Makhmatkhanov]

Ruslan Makhmatkhanov wrote on 08.04.2013 11:29:

Pedro F. Giffuni wrote on 08.04.2013 08:08:

Hello guys;

There is a new bugfix release in the 27 series with hundreds of
bugfixes:
http://hg.python.org/cpython/file/9290822f2280/Misc/NEWS

I gave a try at updating the python27 port and it was rather easy to
get started (almost all patches apply cleanly) but I get this problem
  when building:

...
cc -c -fno-strict-aliasing -O2 -fno-strict-aliasing -pipe -march=nocona
-DNDEBUG -O2 -fno-strict-aliasing -pipe -march=nocona  -I. -IInclude
-I./../Include -fPIC -DPy_BUILD_CORE -o Python/Python-ast.o
Python/Python-ast.c
cc: Python/Python-ast.c: No such file or directory
cc: No input files specified
*** [Python/Python-ast.o] Error code 1

The file actually exists.

I went ahead and reported the issue upstream (Issue17649) but it is
irreproducible in their buildbot and the problem is not really theirs:
it looks like the hacks that we do to stop some modules from building
and the environment used to build the code out-of-tree don#x27;t get
along
very well.

Perhaps someone here knows the port well enough to provide a fix?
I guess it should be possible to modify the makefile to skip generating
that file since it exists already but that#x27;s not very clean ;).

Regards,

Pedro.


As Marcus already said, the problem in changed path to AST_C_DIR (I also
changed AST_H_DIR in the same way).

Here is the updated version by the way (pkg-plist changes is not yet
included):
https://github.com/mexicarne/newpython/commit/7f03049da6883f1eb145a73e83c73be5fd6378a5


pkg-plist updated, so the port is ready, now doing runtime tests:
https://github.com/mexicarne/newpython/tree/master/lang/python27

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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 2.7.4 Released (but I had touble updating the port)

[Ruslan Makhmatkhanov]

Pedro F. Giffuni wrote on 08.04.2013 08:08:

Hello guys;

There is a new bugfix release in the 27 series with hundreds of
bugfixes:
http://hg.python.org/cpython/file/9290822f2280/Misc/NEWS


I just updated all the three python versions, that got newer versions:
- lang/python27: 2.7.3 - 2.7.4
- lang/python32: 3.2.3 - 3.2.4
- lang/python33: 3.3.0 - 3.3.1

This also includes docs update (lang/python-doc-html) and general clean-up.

I'm not sure what the procedure of updating python ports is and if it's 
require exp-run, so asking Martin to clarify that. Hope we can commit 
that after the freeze. Here is the updated ports:


https://github.com/mexicarne/newpython

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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 2.7.4 Released (but I had touble updating the port)

[Ruslan Makhmatkhanov]

Hi Martin,

Martin Wilke wrote on 08.04.2013 19:32:


I can do it yep.


Do you mean exp-run? Should I provide you with something else (may be 
you need a diff for the changes or it's ok to just point onto github 
repository)?



On Apr 8, 2013, at 11:14 PM, Ruslan Makhmatkhanov cvs-...@yandex.ru wrote:


Pedro F. Giffuni wrote on 08.04.2013 08:08:

Hello guys;

There is a new bugfix release in the 27 series with hundreds of
bugfixes:
http://hg.python.org/cpython/file/9290822f2280/Misc/NEWS


I just updated all the three python versions, that got newer versions:
- lang/python27: 2.7.3 - 2.7.4
- lang/python32: 3.2.3 - 3.2.4
- lang/python33: 3.3.0 - 3.3.1

This also includes docs update (lang/python-doc-html) and general clean-up.

I'm not sure what the procedure of updating python ports is and if it's require 
exp-run, so asking Martin to clarify that. Hope we can commit that after the 
freeze. Here is the updated ports:

https://github.com/mexicarne/newpython


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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 2.x Threading on FreeBSD

[Ruslan Makhmatkhanov]

Hi,

this change is included into an python update exp-run request:
http://www.freebsd.org/cgi/query-pr.cgi?pr=178506

Gabor Pali wrote on 21.04.2013 21:00:

Hi there,

Recently I ran into an issue where multi-threaded programs with
signals cannot be run correctly from a thread in Python 2.x with the
vanilla lang/python27 port, c.f. [1].  As I wrote in the corresponding
ticket, the possible cause for this is that threading has been patched
back in 2009 [2] so I recommended to use GNU pth instead.


[...]

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: python33-3.3.2 Parser/pgen: Permission denied

[Ruslan Makhmatkhanov]

Hi William,

jmore...@jmorenov.com.co wrote on 19.05.2013 05:09:



http://bugs.python.org/issue18008 [1]

Hi

I am reporting a bug
on: python33-3.3.2 Parser/pgen: Permission denied

Can you help on
this:

Thank's

William Moreno


Links:
--
[1]
http://bugs.python.org/issue18008


It seems using gmake, as was noted in upstream bug-report for 
issue18008, let this port to build. Please update your lang/python33 
port to SVN revision 318640 and let us know if it works to you.


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: r318575 - in head/math/py-numpy: . files

[Ruslan Makhmatkhanov]

John W. O'Brien wrote on 20.05.2013 23:40:


The attached patch should fix the bulk of the packing plist problems
between pre- and post-PEP-3147 caches. I've smoke tested these with py27
and py33. Improvements are welcome.

There is still one remaining problem, which is that the following are
only, it seems, installed under py27 but not under py33. If needed, I
should have some spare cycles later to track down the specific condition.


John, would you please common pattern for this that already used in the 
ports tree? Look at /usr/ports/databases/py-fdb/Makefile for example. 
It's as easy as adding this lines to port's Makefile:


.if ${PYTHON_REL} = 320
.include ${FILESDIR}/py3k-fix-pkg-plist.inc
.endif

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: r318575 - in head/math/py-numpy: . files

[Ruslan Makhmatkhanov]

Dmitry Sivachenko wrote on 21.05.2013 09:20:


On 21.05.2013, at 9:10, Ruslan Makhmatkhanov cvs-...@yandex.ru wrote:


John W. O'Brien wrote on 20.05.2013 23:40:


The attached patch should fix the bulk of the packing plist problems
between pre- and post-PEP-3147 caches. I've smoke tested these with py27
and py33. Improvements are welcome.

There is still one remaining problem, which is that the following are
only, it seems, installed under py27 but not under py33. If needed, I
should have some spare cycles later to track down the specific condition.


John, would you please common pattern for this that already used in the ports 
tree? Look at /usr/ports/databases/py-fdb/Makefile for example. It's as easy as 
adding this lines to port's Makefile:

.if ${PYTHON_REL} = 320
.include ${FILESDIR}/py3k-fix-pkg-plist.inc
.endif



Yes, that seems to be a proper solution.

As far as I remember it was an intention to add that into bsd.python.mk, so 
every single python-related port does not include this.
What is the status of this?

Thanks!


It was defined as a hack (by you in particular), so I put it aside for a 
while. Also, Marcus suggested more proper fix, but it's more complex 
(for me to understand). If there is consensus that we can you use this 
temporary, then I can prepare patch for yet another exp-run at the next 
week.


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: zope related code to be removed from bsd.python.mk

[Ruslan Makhmatkhanov]

Marcus von Appen wrote on 22.09.2013 13:12:

On, Sun Sep 22, 2013, Ruslan Makhmatkhanov wrote:


Marcus von Appen wrote on 22.09.2013 02:55:

Dear Zope maintainers,

I'd like to get rid of the zope related code in bsd.python.mk and think
about moving it into an own Uses file for zope. Thus all ports requiring
Zope would be converted to USES+= zope.

You can find the mk file itself at
http://people.freebsd.org/~mva/zope.mk.txt. It is a simple copy'n'paste
from bsd.python.mk with a small additional check for PYTHON_VERSION.

I'll have finished patching the relevant ports later for a review and
test. If there are any concerns, please let me know.

Cheers
Marcus


Good idea, Marcus. This is something that was in my todo. I'm now
preparing plone update, so let's do that right after that will be done.
I need about three days to finish.


Great! A complete patch that replaces USE_ZOPE with USES=zope on all
ports can be found at http://people.freebsd.org/~mva/uses_zope.patch.

Feel free to commit (after testing ;-) or integrate it with the plone
update at your convenience. Otherwise let's do this right after your
plone upgrade.

Cheers
Marcus


Just committed in r328002. Thanks a lot Marcus!

--
Regards,
Ruslan

T.O.S. Of Reality
___
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: [CFR] lang/python26 removal

[Ruslan Makhmatkhanov]

René Ladan wrote on 05.01.2014 15:57:

Hi,

lang/python26 expired a few days ago, so I patched Mk/bsd.pyton.mk to
exclude lang/python26 and patched the USE_PYTHON* lines of all ports
referring to Python  2.7. You must remove lang/python26 manually to not
break INDEX.

The patch is available at
http://people.freebsd.org/~rene/patches/python-to-27.diff
The bsd.python.mk patch itself is also here:
http://people.freebsd.org/~rene/patches/Mk__bsd.python.mk.diff

mat@ already gave an OK for the USE_PYTHON* bumps.

Does this patch and removing lang/python26 look OK to you?

I'm not on python@ , so please CC me.

Regards,
René


I'd say please go on with that. But there is two things there, that 
would be great to be fixed before commiting:

- value of 2 need to be used instead of 2.7 in USE_PYTHON in your patch
- there is remnants of 2.6 in lang/python-doc-html/distinfo that isn't 
covered by your patch.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: [CFR] lang/python26 removal

[Ruslan Makhmatkhanov]

René Ladan wrote on 06.01.2014 15:34:

2014/1/6 Ruslan Makhmatkhanov cvs-...@yandex.ru:

René Ladan wrote on 05.01.2014 15:57:


Hi,

lang/python26 expired a few days ago, so I patched Mk/bsd.pyton.mk to
exclude lang/python26 and patched the USE_PYTHON* lines of all ports
referring to Python  2.7. You must remove lang/python26 manually to not
break INDEX.

The patch is available at
http://people.freebsd.org/~rene/patches/python-to-27.diff
The bsd.python.mk patch itself is also here:
http://people.freebsd.org/~rene/patches/Mk__bsd.python.mk.diff

mat@ already gave an OK for the USE_PYTHON* bumps.

Does this patch and removing lang/python26 look OK to you?

I'm not on python@ , so please CC me.

Regards,
René



I'd say please go on with that. But there is two things there, that would be
great to be fixed before commiting:
- value of 2 need to be used instead of 2.7 in USE_PYTHON in your patch

This is because I converted -2.7 to 2.7 etc.  Are you saying that all
USE_PYTHON*=2.7 should be converted to USE_PYTHON*=2 and that
other USE_PYTHON* values are OK ?


I just looked at it again:

-2.7 and 2.7 should be converted to just `2'
2.x+ should be converted to just `yes' to keep it's current meaning

Will this `yes'-ports actually build with 3.x - that will be checked 
later for all the tree. I have plans for this.



- there is remnants of 2.6 in lang/python-doc-html/distinfo that isn't
covered by your patch.

Thanks, distinfo trimmed.



René


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: [CFR] lang/python26 removal

[Ruslan Makhmatkhanov]

René Ladan wrote on 06.01.2014 16:00:

2014/1/6 Ruslan Makhmatkhanov cvs-...@yandex.ru:

René Ladan wrote on 06.01.2014 15:34:


2014/1/6 Ruslan Makhmatkhanov cvs-...@yandex.ru:


René Ladan wrote on 05.01.2014 15:57:


Hi,

lang/python26 expired a few days ago, so I patched Mk/bsd.pyton.mk to
exclude lang/python26 and patched the USE_PYTHON* lines of all ports
referring to Python  2.7. You must remove lang/python26 manually to not
break INDEX.

The patch is available at
http://people.freebsd.org/~rene/patches/python-to-27.diff
The bsd.python.mk patch itself is also here:
http://people.freebsd.org/~rene/patches/Mk__bsd.python.mk.diff

mat@ already gave an OK for the USE_PYTHON* bumps.

Does this patch and removing lang/python26 look OK to you?

I'm not on python@ , so please CC me.

Regards,
René




I'd say please go on with that. But there is two things there, that would
be
great to be fixed before commiting:
- value of 2 need to be used instead of 2.7 in USE_PYTHON in your patch


This is because I converted -2.7 to 2.7 etc.  Are you saying that all
USE_PYTHON*=2.7 should be converted to USE_PYTHON*=2 and that
other USE_PYTHON* values are OK ?



I just looked at it again:

-2.7 and 2.7 should be converted to just `2'
2.x+ should be converted to just `yes' to keep it's current meaning

Will this `yes'-ports actually build with 3.x - that will be checked later
for all the tree. I have plans for this.


I'll redo the patch with the above two conversion rules and blame any
breakage on you :-p

Regards,
René


Ok). But please send it here for review).

--
Regards,
Ruslan

T.O.S. Of Reality
___
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: [CFR] lang/python26 removal

[Ruslan Makhmatkhanov]

René Ladan wrote on 07.01.2014 00:15:

On 01/06/2014 13:09, Ruslan Makhmatkhanov wrote:

René Ladan wrote on 06.01.2014 16:00:

2014/1/6 Ruslan Makhmatkhanov cvs-...@yandex.ru:

René Ladan wrote on 06.01.2014 15:34:


2014/1/6 Ruslan Makhmatkhanov cvs-...@yandex.ru:


René Ladan wrote on 05.01.2014 15:57:


Hi,

lang/python26 expired a few days ago, so I patched
Mk/bsd.pyton.mk to
exclude lang/python26 and patched the USE_PYTHON* lines of all ports
referring to Python  2.7. You must remove lang/python26 manually
to not
break INDEX.

The patch is available at
http://people.freebsd.org/~rene/patches/python-to-27.diff
The bsd.python.mk patch itself is also here:
http://people.freebsd.org/~rene/patches/Mk__bsd.python.mk.diff

mat@ already gave an OK for the USE_PYTHON* bumps.

Does this patch and removing lang/python26 look OK to you?

I'm not on python@ , so please CC me.

Regards,
René




I'd say please go on with that. But there is two things there,
that would
be
great to be fixed before commiting:
- value of 2 need to be used instead of 2.7 in USE_PYTHON in your
patch


This is because I converted -2.7 to 2.7 etc.  Are you saying that all
USE_PYTHON*=2.7 should be converted to USE_PYTHON*=2 and that
other USE_PYTHON* values are OK ?



I just looked at it again:

-2.7 and 2.7 should be converted to just `2'
2.x+ should be converted to just `yes' to keep it's current meaning

Will this `yes'-ports actually build with 3.x - that will be checked
later
for all the tree. I have plans for this.


I'll redo the patch with the above two conversion rules and blame any
breakage on you :-p

Regards,
René


Ok). But please send it here for review).


Sure: http://people.freebsd.org/~rene/patches/python-cleanup.diff

This patch looks (much) bigger than the previous patch but that is
because it includes the removal of lang/python26.

René


Sorry, I see no changes we discussed earlier. Wrong patch-file?

--
Regards,
Ruslan

T.O.S. Of Reality
___
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: ports/185959: [NEW PORT] www/py-django-auth-ldap: LDAP integration for django.contrib.auth

[Ruslan Makhmatkhanov]

The following reply was made to PR ports/185959; it has been noted by GNATS.

From: Ruslan Makhmatkhanov cvs-...@yandex.ru
To: Alexander Kriventsov a...@vl.ru, freebsd-gnats-sub...@freebsd.org
Cc:  
Subject: Re: ports/185959: [NEW PORT] www/py-django-auth-ldap: LDAP integration
 for django.contrib.auth
Date: Tue, 21 Jan 2014 12:12:47 +0400

 Alexander, would you please fix your submission a little bit?
 
 1. New ports should be stage-aware. For python ports it's quite easy do. 
 Just add PYDISTUTILS_AUTOPLIST=yes and remove NO_STAGE=yes from 
 Makefile. After that, you may also freely remove pkg-plist, because it's 
 contents will now be generated automatically.
 
 2. LICENSE=BSD - portlint warns about recent change in this area. Plain 
 BSD value in this knob is deprecated. It should look like 
 BSD[?]CLAUSE. I see on official site that the actual license of 
 django-auth-ldap is 2-clause BSD license, so you need to change it to 
 LICENSE=BSD2CLAUSE.
 
 Except of that, this new port is fine!
 
 -- 
 Regards,
 Ruslan
 
 T.O.S. Of Reality
___
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: Default PYTHON_PKGNAMEPREFIX and dropping PYTHON_PKGNAMESUFFIX

[Ruslan Makhmatkhanov]

Marcus von Appen wrote on 21.01.2014 14:48:

Dear all,

most python ports, which install into PYTHON_SITELIBDIR or PYTHON_LIBDIR
use an explicit PKGNAMEPREFIX assignment to mark the resulting packages as
related to a specific python version.
The porter's handbook also outlines that ports should stick to this practice.

I would like to force the usage of PYTHON_PKGNAMEPREFIX for ports, which use
distutils (and hence are always targeting a specific python version), by
implicitly setting PKGNAMEPREFIX=PYTHON_PKGNAMEPREFIX in bsd.python.mk. This
makes port Makefiles less error-prone and ensures that the ports stick to a
common naming scheme, when it comes to packages.

At the same time, I would like to deprecate and remove PYTHON_PKGNAMESUFFIX,
since it has no practical use or relevance other than creating an inconsistent
package naming scheme. Its original purpose (to be read in r91400) does not
hold true in my opinion, and I am explaining the reaon(s) for that (among
other things when it comes to naming python ports) at
http://www.sysfault.org/posts/freebsd-python-ports-pre-suffix.html.

If noone speaks up, I'll start with the necessary changes to the
infrastructure soon.

Cheers
Marcus


Like the suffix idea!
I just want to add, that it would be great to also automatically adjust 
DOCSDIR and EXAMPLESDIR with correct prefix to make docs/examples, 
installed by single port, but for different python version 
simultaneously. This will help to avoid conflicts.


Right now we have this (py-gnupg is just random python port):
# make -V DOCSDIR /usr/ports/security/py-gnupg
/usr/local/share/doc/gnupg

So right now it ever may conflict with gnupg docs, if I understand 
correctly. I think that correct dirname would be:

/usr/local/share/doc/py27-gnupg for python 2.7
and
/usr/local/share/doc/py33-gnupg for python 3.3

The same for examples.

--
Regards,
Ruslan

T.O.S. Of Reality
___
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

PYDISTUTILS_AUTOPLIST question

[Ruslan Makhmatkhanov]

Hi,

while PYDISTUTILS_AUTOPLIST works smoothly for majority of ports, there 
is the problem with some of them I come across yesterday. For example, 
there is the port devel/py-Products.PasswordResetTool. If I set there 
PYDISTUTILS_AUTOPLIST, and try to build, I got packaging error, because 
some of the files, that port provides, cannot be compiled (by design). 
While they are python code files, they are not supposed to be executed 
with python interpreter directly (they are kind of templates).


So, is there any possibility to:
a) Do not add compiled/optimized filenames to packing list, if the 
actual file fails to compile?
b) Make a hook, that allows to list file, that should not have 
corresponding *.pyc/*.pyo entries in the packing list?


Such thing is common for zope/plone-related ports, and I already asked 
upstream about this long time ago. They tell me to just ignore that and 
all was fine until such a tasty life-saver, which PYDISTUTILS_AUTOPLIST 
is, was introduced into the ports tree, that sadly cannot be used for 
this ports.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: PYDISTUTILS_AUTOPLIST question

[Ruslan Makhmatkhanov]

Marcus von Appen wrote on 26.01.2014 15:30:

On, Sun Jan 26, 2014, Ruslan Makhmatkhanov wrote:


Hi,

while PYDISTUTILS_AUTOPLIST works smoothly for majority of ports, there
is the problem with some of them I come across yesterday. For example,
there is the port devel/py-Products.PasswordResetTool. If I set there
PYDISTUTILS_AUTOPLIST, and try to build, I got packaging error, because
some of the files, that port provides, cannot be compiled (by design).
While they are python code files, they are not supposed to be executed
with python interpreter directly (they are kind of templates).

So, is there any possibility to:
a) Do not add compiled/optimized filenames to packing list, if the
actual file fails to compile?
b) Make a hook, that allows to list file, that should not have
corresponding *.pyc/*.pyo entries in the packing list?


If the port uses distutils, it should not matter, if you do not mess around in
the post-install targets yourself, since the file list will be taken from what
distutils records - we do not implement magic ourselves for distutils-aware
ports (well, a bit :-).
If this does not work properly for you, upstream might do something that
breaks the intended behaviour of distutils.

So, before fixing the symptom, I actually would like to find out, what exactly
they do on installation. Are all files properly recorded in ${_PYTHONPKGLIST}?
What errors do you get, what does the install target complain about, etc.etc.?

Cheers
Marcus



For example at install stage it fails with pwreset_constructURL.py file:

byte-compiling 
/usr/local/poudriere/ports/default/devel/py-Products.PasswordResetTool/work/stage/usr/local/lib/python2.7/site-packages/Products/PasswordResetTool/skins/PasswordReset/pwreset_constructURL.py 
to pwreset_constructURL.pyc
  File 
/usr/local/lib/python2.7/site-packages/Products/PasswordResetTool/skins/PasswordReset/pwreset_constructURL.py, 
line 14

return %s/passwordreset/%s % (host, randomstring)
SyntaxError: 'return' outside function

writing byte-compilation script '/tmp/tmpqmG0z8.py'
/usr/local/bin/python2.7 -O /tmp/tmpqmG0z8.py
  File 
/usr/local/lib/python2.7/site-packages/Products/PasswordResetTool/skins/PasswordReset/pwreset_constructURL.py, 
line 14

return %s/passwordreset/%s % (host, randomstring)
SyntaxError: 'return' outside function

removing /tmp/tmpqmG0z8.py

And here is what on package stage:
===  Building package for py27-Products.PasswordResetTool-2.0.15_1
pkg-static: 
lstat(/usr/local/poudriere/ports/default/devel/py-Products.PasswordResetTool/work/stage/usr/local/lib/python2.7/site-packages/Products/PasswordResetTool/skins/PasswordReset/pwreset_constructURL.pyc): 
No such file or directory
pkg-static: 
lstat(/usr/local/poudriere/ports/default/devel/py-Products.PasswordResetTool/work/stage/usr/local/lib/python2.7/site-packages/Products/PasswordResetTool/skins/PasswordReset/pwreset_constructURL.pyo): 
No such file or directory

*** Error code 1

Stop.
make: stopped in 
/usr/local/poudriere/ports/default/devel/py-Products.PasswordResetTool



As we can see *.pyc/*.pyo pkg-plist entries were generated for 
pwreset_constructURL.py despite the fact that byte-compiling had failed.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: PYDISTUTILS_AUTOPLIST question

[Ruslan Makhmatkhanov]

Marcus von Appen wrote on 26.01.2014 18:22:


As we can see *.pyc/*.pyo pkg-plist entries were generated for
pwreset_constructURL.py despite the fact that byte-compiling had failed.


Thanks - I just checked, what exactly happens within the record magic for
those cases. distutils (and thus setuptools, since it does not do anything
special in that area) just picks up the .py files and adds entries for
matching .pyc and .pyo files without actually checking, if those files
could be compiled successfully.
The code snippet (distutils/install_lib.py, _bytecode_filenames()) actually
needs to verify, if .pyc/.pyo files exist, since the bytecode compiler
function (distutils/util.py, byte_compile() in indirect mode)
does not break on errors, but silently proceeds.

Rather than adding a hack to bsd.python.mk to filter out such entries, I'd
like to see that issue fixed upstream: http://bugs.python.org/issue20397.
My current (quick'n'dirty) idea is to add a simple file existence verification
check into our currently supported versions.

Cheers
Marcus


Thank you for this. I though this is something under our control. Let's 
see what guys at python.org say.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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

math/py-numpy and WITH_FIXED_FENV

[Ruslan Makhmatkhanov]

Hello,

does anybody know if WITH_FIXED_FENV in math/py-numpy have any use 
beside the unsupported FreeBSD versions? It only set in this case:


.if (${OSVERSION} = 703100 || \
(${OSVERSION} = 80  ${OSVERSION} = 800502) || \
(${OSVERSION} = 90  ${OSVERSION} = 99))  \
(${ARCH} == i386 || ${ARCH} == amd64)
WITH_FIXED_FENV=yes
.endif

So, as for me, WITH_FIXED_FENV code may be safely trimmed from the 
Makefile, but I'm not sure if there is any situations where user of 
supported version of FreeBSD may explicitly set this variable for some 
reason.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: ports/186677: [UPDATE] math/py-numpy: update to 1.8.0,1

[Ruslan Makhmatkhanov]

Hi,

Johannes Meixner wrote on 13.02.2014 11:21:

Hi Ruslan,

on the numpy note:

I forgot to attach to that PR that all ports using Numpy
should be PORTREVISION-bumped to have them rebuilt with Numpy 1.8.
Could you bump everything that has RUN/LIB/BUILD_DEPENDS on
numpy (${NUMPY} shorthand), please?

Best regards,
Johannes


Doubt it's actually needs to be rebuilt. It's ever defined py-numpy 
dependency as BUILD_DEPENDS, because it's setup.py checks for numpy 
presence at setup_requires. Do not forget, that numpy consumers are just 
python softwares, so there is nothing to rebuild. Could you provide some 
examples of linking shared libraries with numpy in some port?


PS. As commit history for this port showing - numpy was always updated 
without portrevision bump for consumers.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: HEADS-UP and RFC - Adding setuptools as default RUN_DEPENDS

[Ruslan Makhmatkhanov]

Kubilay Kocak wrote on 13.02.2014 12:11:

Two days ago I updated virtualenv, transitioning it away from the
deprecated USE_PYDISTUTILS=easy_install to USE_PYDISTUTILS=yes as many
other ports have recently.

I thought nothing of it until the following report by Scott (cc'd):

http://lists.freebsd.org/pipermail/freebsd-python/2014-February/006592.html

The summary of that thread is:

a) Any python software that uses *console_scripts* needs the
pkg_resources module from setuptools at run time. This basically means
anything that installs a CLI utility.

b) Package-only users don't get setuptools installed when they install
the packages of the above ports, because =yes *doesnt* set a RUN_DEPENDS
on it.

This breaks console script invocation, with the following error:

Traceback (most recent call last):
   File /usr/local/bin/script-name, line 5, in module
 from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

Reproduction steps are:

1) Install port or package that uses console_scripts
2) If you installed the package, run the console script
3) If you installed the port
3.1) Run the console script
3.2) Remove py-setuptools
3.3) Run the console script again

Reproduced with: py-virtualenv (`virtualenv`), py-tox (`tox`) and
py-nose (`nosetests`)

We (python@) have now standardised on a consistent installation pattern
for all python software, whether pure-distutils or setuptools based, and
there are run-time requirements that are currently not being satisfied.

Attached is a patch moving RUN_DEPENDS+=setuptools from the
=easy_install only case, to the default case.

Patch review requested, other comments welcome.

./koobs


Speaking of myself, things are ok with this change.

--
Regards,
Ruslan

T.O.S. Of Reality
___
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: r346687 - head/www/py-pastescript

[Ruslan Makhmatkhanov]

Bryan Drewery wrote on 02.03.2014 23:14:

On 3/1/2014 12:05 PM, Martin Wilke wrote:

Author: miwi
Date: Sat Mar  1 18:05:46 2014
New Revision: 346687
URL: http://svnweb.freebsd.org/changeset/ports/346687
QAT: https://qat.redports.org/buildarchive/r346687/

Log:
   - Convert to autoplist
   - Stage support
   - Bump PORTREVISION

Deleted:
   head/www/py-pastescript/pkg-plist
Modified:
   head/www/py-pastescript/Makefile

Modified: head/www/py-pastescript/Makefile
==
--- head/www/py-pastescript/MakefileSat Mar  1 18:05:27 2014
(r346686)
+++ head/www/py-pastescript/MakefileSat Mar  1 18:05:46 2014
(r346687)
@@ -3,6 +3,7 @@

  PORTNAME= PasteScript
  PORTVERSION=  1.7.5
+PORTREVISION=  1
  CATEGORIES=   www python
  MASTER_SITES= CHEESESHOP
  PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}
@@ -18,8 +19,7 @@ BUILD_DEPENDS=${PYTHON_PKGNAMEPREFIX}ch
  RUN_DEPENDS:= ${BUILD_DEPENDS}

  USE_PYTHON=   yes
-USE_PYDISTUTILS=   easy_install
-PYDISTUTILS_NOEGGINFO= yes # XXX convert easy_install support to 
bsd.python.mk's
+USE_PYDISTUTILS=   yes
+PYDISTUTILS_AUTOPLIST= yes

-NO_STAGE=  yes
  .include bsd.port.mk



http://pb2.nyi.freebsd.org/bulk/91amd64-default-baseline/2014-03-01_21h00m44s/logs/errors/py27-turbomail-3.0.3_2.log

This causes new failure with py27-turbomail. PasteScript was installing
an egg but now is installing right into site-packages.

Old:

/usr/local/lib/python2.7/site-packages/PasteScript-1.7.5-py2.7.egg/tests/__init__.py

New:
 /usr/local/lib/python2.7/site-packages/tests/__init__.py

py27-turbomail also installs this file and depend on Pastescript which
conflicts and now fails to build.


python@: Why not stick to using the egg dirs? It is much safer to avoid
polluting global namespace.


I believe it's mostly upstream issue, because it should belong to f.e.
site-packages/PasteScript/tests/__init__.py instead. But easy_install 
installation may be keep'd for such a few problematic ports. The actual 
problem there - incogitant converting of ports. I think this couple of 
commits should be reverted until the issue will be fixed upstream.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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

python32 has expired

[Ruslan Makhmatkhanov]

Hello,

mind I remove expired python32?

--
Regards,
Ruslan

T.O.S. Of Reality
___
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: ports/lang/python27 ssl

[Ruslan Makhmatkhanov]

Hi Julian,

sadly I can't reproduce the behavior in poudriere (both mailman and 
dnspython are builds fine in 10.3 and 12.0), so it is something in your 
system environment. And as you correctly noted this is something that is 
controlled by Mk/* files, not the ports itself. Try to start the ports 
tree from scratch or just use a binary packages. You also can use 
poudriere for building personalized packages for your system.


PS. Can't say anything about ssl issue. I'm not using openssl from ports.

Julian H. Stacey wrote on 09/04/2016 17:29:

Hi pyt...@freebsd.org as MAINTAINER= of lang/python27/Makefile
Hi r...@freebsd.org as MAINTAINER= of dns/py-dnspython/Makefile

( PS please retain cc:  as I'm not a member of python@ )

I had to comment ssl out of /usr/ports/lang/python27/Makefile
USES=cpe ncurses pkgconfig readline ssl tar:xz
to force compile, else it complained it needed ssl from src/ &
recommended removing ssl from ports, but ports ssl is needed for webmail etc
Comments welcome ?


Also from starting point: cd mail/mailman; make install
ports/dns/py-dnspython fails

===>   Registering installation for py27-dnspython-1.14.0 as automatic
pkg-static: Plist error, directory listed as a file: 
lib/python2.7/site-packages/dnspython-1.14.0-py2.7.egg-info
*** Error code 74

dnspython-1.14.0-py2.7.egg-info
is not even listed so I spose it come from Mk/ or pkg ?
I reinstalled  ports/*/pkg but that did not help.

A solution welcome please.

Thanks,
Julian




--
Regards,
Ruslan

T.O.S. Of Reality
___
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"

Introducing python3 into user system

[Ruslan Makhmatkhanov]

Hi,

Python 2.7 will have no upstream support after 2020, and right now it no 
more getting new features. So I'd want to start poisoning^W  introducing 
python3 into user system via ports tree and here is what I suggest to 
start to do right now:


- if port has a build dependency upon python and it can be built both 
with python2 and python3, force it to build with python3
- if some standalone application can be running both with python2 and 
python3 and it have equivalent python3 dependencies, force it to be run 
with python3


We also need to explicitly mark python2-only ports to simplify switching 
to python3 as default at some point of time.


What you guys think about? If there is general consensus, we may enforce 
this via Porters Handbook.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: Introducing python3 into user system

[Ruslan Makhmatkhanov]

Gerhard Schmidt wrote on 10/17/2016 14:27:

Am 17.10.2016 um 12:39 schrieb Ruslan Makhmatkhanov:

Gerhard Schmidt wrote on 10/17/2016 11:07:

Am 16.10.2016 um 21:22 schrieb Ruslan Makhmatkhanov:

- if port has a build dependency upon python and it can be built both
with python2 and python3, force it to build with python3
- if some standalone application can be running both with python2 and
python3 and it have equivalent python3 dependencies, force it to be run
with python3


What do you mean by "force it"?.


I mean set USES=python3.3+ for such ports.


This will install python3.5 on this system regardless if there is a
working python2.x installation, which is exactly what is wrong. I am a
software developer who runs legacy systems on python2.7. Forcing ports
that are able to run with python2.7 to install python3.5 will most
probably break my systems. USES should always represent the minimum
requirement not something so feel is something it should use.


I'm not sure how it will break anything if conditions, listed in my 
initial message are complied. Would you please elaborate on that and 
provide an example of such a breakage? python3.5 and python2.7 can 
co-exist. And I just want to remind that we are talking only about 
standalone applications now, with no external dependencies, and also 
about ports that use python only at build phase.




Please do not break systems without a really good reason. This we can
discus in 4 years when support for python2 will end, but not until than.

Not everyone has the freedom to run only shine new software on shine new
systems.

Regards
  Estartu



As far I understand, we should do some preliminary work to make it 
happen. We can't turn 26k of ports to using python3 in one day at 1st of 
January 2020.



--
Regards,
Ruslan

T.O.S. Of Reality
___
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: Introducing python3 into user system

[Ruslan Makhmatkhanov]

Gerhard Schmidt wrote on 10/17/2016 11:07:

Am 16.10.2016 um 21:22 schrieb Ruslan Makhmatkhanov:

- if port has a build dependency upon python and it can be built both
with python2 and python3, force it to build with python3
- if some standalone application can be running both with python2 and
python3 and it have equivalent python3 dependencies, force it to be run
with python3


What do you mean by "force it"?.


I mean set USES=python3.3+ for such ports.


I agree python3 should be the default choice for all ports that can be
installed with both python 2 and 3 if there is no python on the system.
if python2 is already installed and python3 is not python2 should be
used to reduce possible incompatibilities between programs.

Regards
  Estartu


Please see my comments to Vlad's response. This does not involve python 
"libraries" and standalone ports that depend on such "libraries".


--
Regards,
Ruslan

T.O.S. Of Reality
___
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: Introducing python3 into user system

[Ruslan Makhmatkhanov]

Vlad K. wrote on 10/17/2016 13:04:

Hi all!


On 2016-10-17 09:47, Kubilay Kocak wrote:

On 17/10/2016 6:22 AM, Ruslan Makhmatkhanov wrote:


- if port has a build dependency upon python and it can be built
both with python2 and python3, force it to build with python3 - if
some standalone application can be running both with python2 and
python3 and it have equivalent python3 dependencies, force it to be
run with python3


This can be achieved now by setting DEFAULT_VERSIONS= python=3
python3=3.5. See https://wiki.freebsd.org/DEFAULT_VERSIONS


You may now omit python3=3.5, because 3.5 is default since r423986. And 
what I actually suggested is not to change default version to python 3.x 
overall in ports at this moment. I suggested to do that just for some 
ports, that have python as build-only or run-only dependency, if the 
software in question is capable to run with python3. This is only needed 
to increase involvement of python3 in ports tree and user system, so we 
can catch up any FreeBSD-specific problems at early rate.


This one is a good example: net/openpgm. It does not install any python 
libraries and does not need python to run. Python is just used in build 
process so nothing prevent us to build with python3 by default.




And if I misunderstood you correctly and you meant force it via port
itself, I don't think we have a mechanism for that and even if we did,
that'd be very bad.


What I actually meant is to utilize USES=python:3.3+ for such ports, to 
make it pick up default python3 version. And citing myself:


"""
- if some standalone application can be running both with python2 and 
python3 and it have equivalent python3 dependencies, force it to run 
with python3

"""

So if there are no equivalent py3 ports for dependencies, we do not 
change anything, for sure. Most of python libraries are not fall into 
this category also.



One such problem I've noticed is with shared dependencies. If port X can
work with 3, and port Y can only work with 2, and both have a common
dependency Z which can run both 2 and 3, Z won't be built for both,
it'll be built for DEFAULT_VERSION version, and if that's 3, it spells
trouble for Y. It'll build fine, but Y will fail at runtime.

Case in point was building py-sphinx and saltstack with Py3.5 set as
default. They both have a dependency that broke sphinx, iirc.

To fix this we desperately need variants. https://reviews.freebsd.org/D5563



We also need to explicitly mark python2-only ports to simplify
switching to python3 as default at some point of time.


Definitely. I've started doing that, and caught some. weechat was one of
them which has been fixed now. But, because of my build server
reorganization I had to stop with that for some time and will pick it up
again with a permanent, bi-weekly (twice a week) poudriere build of ALL
ports that USE= python, with a public poudriere status page so we can
track how it goes.




What you guys think about? If there is general consensus, we may
enforce this via Porters Handbook.


I'm not sure the PHB is the right place. When I get the continuous
poudriere build going, I'll post to the mailing lists announcing it,
with an intention to pretty please let's switch to py3 as soon as
possible. Also see next:


Ok, PHB was just an example. But it should be some "authoritative" place 
to encourage people to change their ports and to prevent adding of new 
ports without specific python version set (I still see many new ports 
added with just USES=python, while it may not build with python3 at all).


I also like koobs approach to formalize the roadmap, but right now I 
only can say that we can do the separation of python2-only ports till 
the end of the year. And maybe switch build-only ports to python3 by 
default. But I'm not yet sure what should be the next step.



I suggest we document something like a 'Road to Python 3 as Default'
page in the Python/ wiki outlining the goal (with timelines),
motivation, potential problems and possible alternative methods. Kind of
like a Python PEP.


Definitely. I was thinking about that, inspired by Bernard's LibreSSL
list of ports that fail, to have a list of ports that:

a) Have USE= python but fail on 3
b) Have USE= python:2 but are actually supported on 3


But I need to get that poudriere running with a public status page for
that.



--
Regards,
Ruslan

T.O.S. Of Reality
___
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: ipython 7.x and ipykernel 5.x

[Ruslan Makhmatkhanov]

Hi Steve,

Steve Wills wrote on 12/5/18 6:10 PM:

Hi,

Trying to update devel/py-jupyter_console and devel/py-qtconsole, I 
found that I need ipython 7.x and ipykernel 5.x. I already created 
devel/py-prompt_toolkit2 since prompt_toolkit 2.x is incompatible with 1.x.


Should I commit separate ports for devel/ipython7 and 
devel/py-ipykernel5 or do you have plans to update devel/ipython and 
devel/py-ipykernel? Note I already have devel/ipython7 and 
devel/py-ipykernel5 tested and working locally. But I thought we may 
prefer to just update rather than keep so many versions around. What's 
your preference?


Thanks,
Steve


devel/ipython is py3x only, so it's safe to update it to 7.x. We also 
have devel/ipython5 for py2x users.


As for jupyter update, I personally think that if upstream switched to 
python 3, we should do the same. But all the 2.x-only dependencies of 
ipython should be somehow fixed. If somebody embeds system-wide 
installed ipython into their 2.x application instead of using 
virtualenv, it's not the ports maintainers problem IMHO.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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"