Current problem reports assigned to freebsd-python@FreeBSD.org

[FreeBSD bugmaster]

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

f ports/189666 python devel/py-demjson: unfetchable due to rerolled tarball
o ports/189642 python [PATCH] www/py-Flask-FlatPages: stage
f ports/189475 python [UPDATE] net/py-netifaces to 0.10.3
o ports/189270 python [new port] graphics/py-pygal, python svg graph plottin
o ports/189182 python [MAINTAINER] databases/py-pylibmc: update to 1.3.0
f ports/189131 python databases/py-bsddb3 - fails to build with python3.x
o ports/189129 python [MAINTAINER UPDATE] textproc/py-regex update to versio
o ports/188964 python [PATCH] graphics/py-stl: Fix WWW URL in pkg-descr
o ports/188930 python [maintainer update] games/py-mnemosyne (2.3)
o ports/188894 python [PATCH] databases/py-swift: update to 1.13.1
o ports/188681 python Updated port security/py-ecdsa
o ports/188327 python math/py-numpy: Numpy is broken
o ports/188251 python lang/python: bdb48 dependency leak in all python
o ports/188250 python [Patch] update port www/py-selenium to 2.41.0
o ports/188114 python math/py-numpy is broken on 9.2-STABLE
f ports/187956 python [PATCH] devel/py-bcdoc: update to 0.12.2
o ports/187413 python [NEW PORT] devel/py-python-statsd
o ports/187412 python [NEW PORT] devel/py-daemons
o ports/187393 python databases/py-firebirdsql: update to 0.9.2
o ports/186881 python New port: print/py-preppy ReportLab's templating syste
f ports/186866 python [patch] print/py-reportlab2 Update from 2.5 to 2.7
o ports/186842 python [Maintainer Update] devel/py-robotframework-ride 1.2.3
o ports/186201 python [NEW PORT] www/py-calendarserver: Calendar and Contact
o ports/186162 python [NEW PORT] www/py-django-ldapdb: Support for django mo
o ports/185884 python [patch] Miscellaneous ports fixes for python 3
o ports/184954 python Installation checks prevent multiple python ports bein
o ports/178301 python [patch] lang/python27: SEM option is inconsistent
f ports/178242 python bsd.python.mk injection of @exec easy_install to PLIST
o ports/170788 python lang/python27: PyQT applications crash Python 2.7 (cor
o ports/168640 python [PATCH]: prevent checksum mismatches for compiled pyth
o ports/167368 python [bsd.python.mk] [patch] Python version propagation bre

31 problems total.

___
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/189666: devel/py-demjson: unfetchable due to rerolled tarball

[Bartłomiej Rutkowski]

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

From: =?utf-8?Q?Bart=C5=82omiej_Rutkowski?= 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: ports/189666: devel/py-demjson: unfetchable due to rerolled tarball
Date: Mon, 12 May 2014 14:17:35 +0100

 Wiadomo=C5=9B=C4=87 napisana przez Edwin Groothuis  w =
 dniu 11 maj 2014, o godz. 15:40:
 
 > Maintainer of devel/py-demjson,
 >=20
 > Please note that PR ports/189666 has just been submitted.
 >=20
 > If it contains a patch for an upgrade, an enhancement or a bug fix
 > you agree on, reply to this email stating that you approve the patch
 > and a committer will take care of it.
 >=20
 > The full text of the PR can be found at:
 >http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/189666
 >=20
 > --=20
 > Edwin Groothuis via the GNATS Auto Assign Tool
 > ed...@freebsd.org
 
 Please, use following distinfo to update the port:
 
 SHA256 (demjson-2.0.tar.gz) =3D =
 0674e69c4ab6ff7f51cc307c0313933fc0d7349870f14a630e6c1adcd7456313
 SIZE (demjson-2.0.tar.gz) =3D 191423
 
 =
 http://poudriere.ithil.palantiri.org:8080/latest-per-pkg/py27-demjson/2.0/=
 
 
 Kind regards,
 Bartek Rutkowski=
___
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 cannot satisfy libgfortran dependency on libgcc_s/GCC_4.6.0 [WAS: Re: py27-pandas-0.13.1_1 conflict with py27-MySQLdb-1.2.3_4]

[John W. O'Brien]

On 5/8/14 11:33 PM, Irjohn Junus wrote:
> Hi John,
> 
> No worries and yes I'm still having the problem.
> 
> I remember seeing this message:
> ===>>> pkg-message for gcc-4.7.3_1
> To ensure binaries built with this toolchain find appropriate versions
> of the necessary run-time libraries, you may want to link using
> 
>   -Wl,-rpath=/usr/local/lib/gcc47
> 
> after upgrading gcc port a few days ago, which is described in your link
> [0]. Do I issue this command as root? Need advice here, thanks.
> 
> Regards,
> Irjohn
> 
> 
> On Fri, May 9, 2014 at 10:42 AM, John W. O'Brien  > wrote:
> 
> On 4/18/14 8:45 AM, Irjohn Junus wrote:
> > Dear All,
> >
> > I'm running 9.1-RELEASE and today just after freebsd-update to p11 and
> > updating ports to the latest found out that pandas won't import after
> > MySQLdb is imported first. Strangely, it will import no problem if
> > MySQLdb is imported after:
> 
> Hi Irjohn,
> 
> Sorry for the long delay. Are you still having this problem?
> 
>  import MySQLdb
>  import pandas as pd
> > /lib/libgcc_s.so.1: version GCC_4.6.0 required by
> > /usr/local/lib/gcc47/libgfortran.so.3 not found
> [...]
> > Traceback (most recent call last):
> [...]
> >   File
> "/usr/local/lib/python2.7/site-packages/numpy/linalg/linalg.py",
> > line 29, in 
> > from numpy.linalg import lapack_lite, _umath_linalg
> > ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by
> > /usr/local/lib/gcc47/libgfortran.so.3 not found
> 
> It looks like this thread [0], these commits [1] [2], and this PR [3]
> are related.
> 
> [0]
> 
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2014-April/001149.html
> 
> [1] https://svnweb.freebsd.org/ports?view=revision&revision=351167
> 
> [2] https://svnweb.freebsd.org/ports?view=revision&revision=351159
> 
> [3] https://www.freebsd.org/cgi/query-pr.cgi?pr=185902

Irjohn,

This is just a little out of my depth, so I'm going to talk through it
out loud while I investigate. Presumably somebody more knowledgeable
than I will step in to correct me if I get something wrong.

First off, there are a few open PRs ([0], [1]) on math/py-numpy, both of
which seem to have been triggered when ports started using GCC 4.7 by
default [2].

What I know from reading gcc(1) is that "-Wl," passes 
to the linker, and from ld(1) is that "-rpath=" embeds  in
the output file so that the runtime linker knows where to look for
shared objects. It makes sense why this would help resolve the traceback
you reported because one thing (linalg.py + ??? + libgfortran.so.3) is
looking for another thing (libgcc_s.so.1), finds it, yet remains
unsatisfied. Setting the rpath in the right place in the former will
help it find the right one of the latter.

I dug a little more to learn how to find out what rpath is embedded in a
given file. It turns out that readelf(1) with the "-d" option to show an
ELF file's dynamic section is just the ticket. Here is some output from
my system.

$ cd /usr/local/lib/gcc47
$ readelf -d libgfortran.so.3 | grep RPATH
 0x000f (RPATH)  Library rpath:
[/usr/local/lib/gcc47]
$ cd /usr/local/lib/python2.7/site-packages/numpy/linalg
$ readelf -d {_umath_linalg.so,lapack_lite.so} | grep RPATH
 0x000f (RPATH)  Library rpath:
[/usr/local/lib/gcc47]
 0x000f (RPATH)  Library rpath:
[/usr/local/lib/gcc47]

In fact, this tool will also tell you which shared objects a file needs.

$ readelf -d {_umath_linalg.so,lapack_lite.so} | grep libgfortran
 0x0001 (NEEDED) Shared library:
[libgfortran.so.3]
 0x0001 (NEEDED) Shared library:
[libgfortran.so.3]

So this line of python

>>> from numpy.linalg import lapack_lite, _umath_linalg

tries to load two binary shared objects, both of which require libgfortran.

Moving right along. If everything goes as it should, how is numpy
supposed to learn the correct rpath? Time to dive into
math/py-numpy/Makefile and the ports machinery.

In math/py-numpy, I find "USES=fortran" and some fishy business in the
pre-configure target involving GCCLIBDIR. The former is pretty
interesting because it pulls in /usr/ports/Mk/Uses/fortran.mk to set all
kinds of useful things, including

FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin

It also sets FC=gfortran${_GCC_VER}; a fact I can use to further probe
the GCCLIBDIR funny business in the numpy port. During the pre-configure
target, ports determines GCCLIBDIR like this:

$ gfortran47 -print-file-name=libgfortran.so \
| sed -e s/libgfortran.so//
/usr/local/lib/gcc47/