Re: lowercase requirement for py-ports (Re: svn commit: r405240 - in head/devel: . py-PyLD)

On 04.01.2016 11:38, Kubilay Kocak wrote: > Agreed, its just not a 'current practice' thing that makes that relevant :) True. But insisting on changes of current practice needs a good reason. > How does the figure change only including py-* ports? The share drops from 25% to 9.5%: % awk -F\| '

Re: numpy would not load: libgcc_s vs. libgfortran

On 04.01.2016 14:34, Olivier Duchateau wrote: > Can you post the complete backtrace? > Well, here goes: ___ ERROR at setup of TestAPI.test_can_post_image Traceback (most recent call last): File "/spare/usr/

Re: numpy would not load: libgcc_s vs. libgfortran

On 04.01.2016 16:31, Olivier Duchateau wrote: > After all it's perhaps Numpy's problem, but nobody reported this issue. Well, I decided to try figuring this out myself and got the following error from a very simply one line script consisting of "import numpy;": Traceback (most recent call last

SOLVED: numpy would not load: libgcc_s vs. libgfortran

On 04.01.2016 16:29, Mikhail T. wrote: > ImportError: > /opt/lib/python2.7/site-packages/numpy/core/multiarray.so: Undefined > symbol "cblas_cdotc_sub" Ok, the above went away, when I rebuilt all of the Fortran-using dependencies of numpy with gfortran5. Don't know, if the

Re: SOLVED: numpy would not load: libgcc_s vs. libgfortran

On 04.01.2016 18:59, Olivier Duchateau wrote: >> > I wonder, if this has something to do with my setting PYTHONPATH -- I >> > need the not-yet-installed mediagoblin packages to be found in ${WRKSRC} >> > by the tests. What is the proper way of to do this? > You can add module (and submodules) with

Re: SOLVED: numpy would not load: libgcc_s vs. libgfortran

On 05.01.2016 05:41, Konstantin Belousov wrote: > Some shared object in your process is linked to libgcc_s.so.1, and does not > have the DT_RPATH set. You might try to verify this by procstat -v and > seeing /lib/libgcc_s.so.1 loaded. ... Yes, I think so. But it is not a bug -- that (unknown yet)

libreoffice-5.3.5.2 would not build for me with Python-2.7

I have python=3.6 in my DEFAULT_VERSIONS, but both 2.7 and 3.6 are installed. While trying to build libreoffice, the build attempted to use 2.7 and I kept getting the compiler errors like this: pyuno_util.cxx:43:18: error: no matching function for call to 'PyUnicodeUCS2_FromUnicode' un

Having trouble with USES=python

689139a0fa65813caf54ea5457727c6b48b432_GH0.tar.gz) = 185690 57677d168a5ec21bdf22c9501f075a8f echo x - Makefile sed 's/^X//' >Makefile << 'b67911656ef5d18c4ae36cb6741b7965' X# Created by: Mikhail T. X# $FreeBSD$ X XPORTNAME= scudcloud XPORTVERSION= 2017.09.12

Re: Having trouble with USES=python

So, it being in STAGEDIR is not enough for it to be installed?.. -- Sent from mobile device, please, pardon shorthand. 12 вер. 2017 р. о 21:22 Shane Ambler написав(ла): > As you are using autoplist the file list is generated based on data in > setup.py, like "package_data". You should patch set

Re: [lini...@freebsd.org: ports/170946: [patch] mark certain ports broken on ARM]

On 23.08.2012 19:27, Mark Linimon wrote: ge...@freebsd.org devel/nspr m...@aldan.algebra.com devel/qmake off...@freebsd.org devel/icu po...@freebsd.org lang/tcl86 I'd give a shot at repairing the above four, if I had access to an ARM system... None are present on the current list

Re: [lini...@freebsd.org: ports/170946: [patch] mark certain ports broken on ARM]

On 23.08.2012 21:47, Eitan Adler wrote: NOT and ONLY are meant for ports which by definition will never work another arch (think x86info). In this case the ports are just broken. That's a fine distinction, that makes little sense to me -- the total number of ports, which can not ever work on so

Question about a new Python port

Hello! Attached is a shar for a new port -- of the bencode-module . Everything is fairly straightforward about it, except: 1. Just like devel/py-setuptools is creates/updates the site-packages/easy-install.pth. However, using the same method of cleanin

lowercase requirement for py-ports (Re: svn commit: r405240 - in head/devel: . py-PyLD)

On 04.01.2016 10:23, Kubilay Kocak wrote: > https://wiki.freebsd.org/Python/PortsPolicy [...] Feedback very welcome. > Well, you asked for it... I propose removing the lowercase-requirement. Instead, the portname should match the capitalization found in PyPi. This will better match the current prac

Re: lowercase requirement for py-ports (Re: svn commit: r405240 - in head/devel: . py-PyLD)

On 04.01.2016 11:04, Kubilay Kocak wrote: > No discussion archive Well, if it is not a result of a discussion arriving to a consensus, then, perhaps, the rule is not as hard, is it? What are you reasons behind it? > also PyPI is case insensitive Ah, good to know. Perhaps, that's because Python has

numpy would not load: libgcc_s vs. libgfortran

Hi! I built py-numpy only a few weeks ago with default config options (I think). I'm trying to port some numpy-using software now and its self-tests fail with the following error: ... import numpy File "/opt/lib/python2.7/site-packages/numpy/__init__.py", line 180, in

narrowed down troubles with devel/gobject-introspection

Ok, some Python script somewhere is trying to do chflags on a file under ~/.cache. On this system, my home directory is NFS-mounted and the chflags fails. This should not be a fatal error, but it is... CC-ing Python-maintainers... Yours, -mi Mikhail T. написав(ла): > Building devel/gobj

Re: narrowed down troubles with devel/gobject-introspection

On 07.03.2010 20:21, Joe Marcus Clarke wrote: The recommended workaround for gobject-introspection is to symlink ~/.cache/g-ir-scanner to /dev/null, or some locally mounted directory. Thanks, I built the port as `root', whose home is local. But, in general, a build, that uses anything outsid