Re: Python conflict on RPI2
On Fri, Apr 12, 2019 at 09:47:54PM -0700, bob prohaska wrote: > > Is there any hope of simply replacing python27 with python36? The > goal at hand is merely to compile a working version of firefox. > In general, no. Python 2.7 and 3.6 are incompatible. -- Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python conflict on RPI2
On Sat, Apr 13, 2019 at 02:07:28AM +, Tatsuki Makino wrote: > Steve Kargl wrote on 2019/04/13 10:49: > > > > pkg info | grep py > py.txt > > pkg delete -f py27-setuptools-40.8.0 > > install 3.6 > > re-install python27 > > > > > > py27-cython and py27-sphinx are also cause. > Probably, pkg query -e %\#r\ =\ 0 -g %n py27-\* ports/packages can be > deleted in advance. > Indeed, there's quite a bit of stale material to remove. I tried pkg delete -f py27-\* and it offered to remove many py27-* packages and a few that didn't match by name. Since I can afford to break things on this host I accepted the offer and await the outcome with interest. I'm still rather baffled as to what's going on. One of the first things tried was to deinstall python27, expecting the removal of all traces that might conflict with installing python36. Clearly that didn't happen. Have I got something misconfigured? Or, is this expected behavior for ports? Thanks for writing! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python conflict on RPI2
On Sat, Apr 13, 2019 at 04:09:13AM +0200, Jan Beich wrote: > bob prohaska writes: > > > In tinkering with compiling firefox on an RPI2 attempts to use > > portmaster fail with > > > > ===> Registering installation for py36-setuptools-40.8.0_1 > > Installing py36-setuptools-40.8.0_1... > > pkg-static: py36-setuptools-40.8.0_1 conflicts with > > py27-setuptools-40.8.0 (installs files into the same place). > > Problematic file: /usr/local/bin/easy_install > > *** Error code 70 > > Reinstall py27-setuptools first. When PYTHON_DEFAULT is changed it > requires rebuilding USE_PYTHON=concurrent (or USES=uniquefiles) > consumers in order to make symlinks point to the new default. Is there any hope of simply replacing python27 with python36? The goal at hand is merely to compile a working version of firefox. Thanks for your help! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python conflict on RPI2
On Fri, Apr 12, 2019 at 06:49:40PM -0700, Steve Kargl wrote: > > pkg info | grep py > py.txt > pkg delete -f py27-setuptools-40.8.0 > install 3.6 > re-install python27 Looks like that's working. I'm still baffled where the py27-setuptools-40.8.0 came from. And, it seems there're a few other py27-related packages that'll have to be deleted manually. Thank you very much! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python conflict on RPI2
bob prohaska writes: > In tinkering with compiling firefox on an RPI2 attempts to use > portmaster fail with > > ===> Registering installation for py36-setuptools-40.8.0_1 > Installing py36-setuptools-40.8.0_1... > pkg-static: py36-setuptools-40.8.0_1 conflicts with > py27-setuptools-40.8.0 (installs files into the same place). > Problematic file: /usr/local/bin/easy_install > *** Error code 70 Reinstall py27-setuptools first. When PYTHON_DEFAULT is changed it requires rebuilding USE_PYTHON=concurrent (or USES=uniquefiles) consumers in order to make symlinks point to the new default. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python conflict on RPI2
Steve Kargl wrote on 2019/04/13 10:49: > On Fri, Apr 12, 2019 at 06:45:41PM -0700, bob prohaska wrote: >> In tinkering with compiling firefox on an RPI2 attempts to use >> portmaster fail with >> >> ===> Registering installation for py36-setuptools-40.8.0_1 >> Installing py36-setuptools-40.8.0_1... >> pkg-static: py36-setuptools-40.8.0_1 conflicts with py27-setuptools-40.8.0 >> (installs files into the same place). Problematic file: >> /usr/local/bin/easy_install >> *** Error code 70 >> >> I've tried things like deleting the problematic file, and compiling python36 >> separately, to no effect. What else is worth trying? >> >> Thanks for reading, >> >> bob prohaska >> > > pkg info | grep py > py.txt > pkg delete -f py27-setuptools-40.8.0 > install 3.6 > re-install python27 > > py27-cython and py27-sphinx are also cause. Probably, pkg query -e %\#r\ =\ 0 -g %n py27-\* ports/packages can be deleted in advance. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python conflict on RPI2
On Fri, Apr 12, 2019 at 06:45:41PM -0700, bob prohaska wrote: > In tinkering with compiling firefox on an RPI2 attempts to use > portmaster fail with > > ===> Registering installation for py36-setuptools-40.8.0_1 > Installing py36-setuptools-40.8.0_1... > pkg-static: py36-setuptools-40.8.0_1 conflicts with py27-setuptools-40.8.0 > (installs files into the same place). Problematic file: > /usr/local/bin/easy_install > *** Error code 70 > > I've tried things like deleting the problematic file, and compiling python36 > separately, to no effect. What else is worth trying? > > Thanks for reading, > > bob prohaska > pkg info | grep py > py.txt pkg delete -f py27-setuptools-40.8.0 install 3.6 re-install python27 -- Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Python conflict on RPI2
In tinkering with compiling firefox on an RPI2 attempts to use portmaster fail with ===> Registering installation for py36-setuptools-40.8.0_1 Installing py36-setuptools-40.8.0_1... pkg-static: py36-setuptools-40.8.0_1 conflicts with py27-setuptools-40.8.0 (installs files into the same place). Problematic file: /usr/local/bin/easy_install *** Error code 70 I've tried things like deleting the problematic file, and compiling python36 separately, to no effect. What else is worth trying? Thanks for reading, bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[PATCH]: databases/mongodb40 update to latest release
Index: databases/mongodb40/Makefile === --- databases/mongodb40/Makefile (revision 498768) +++ databases/mongodb40/Makefile (working copy) @@ -2,7 +2,7 @@ PORTNAME= mongodb DISTVERSIONPREFIX= r -DISTVERSION= 4.0.6 +DISTVERSION= 4.0.8 PORTREVISION= 1 CATEGORIES= databases net MASTER_SITES= https://fastdl.mongodb.org/src/ \ Index: databases/mongodb40/distinfo === --- databases/mongodb40/distinfo (revision 498768) +++ databases/mongodb40/distinfo (working copy) @@ -1,3 +1,3 @@ -TIMESTAMP = 1549337164 -SHA256 (mongodb-src-r4.0.6.tar.gz) = 34165ef42c7199c438e1706fef515cbde012d6a884406d102082d39eab72c235 -SIZE (mongodb-src-r4.0.6.tar.gz) = 49511958 +TIMESTAMP = 1553817480 +SHA256 (mongodb-src-r4.0.8.tar.gz) = 83e694405b72002588a64275be00bf1e36e12f5955451171645f45cb3f16f251 +SIZE (mongodb-src-r4.0.8.tar.gz) = 49841488 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 11:18:50PM +0200, Dima Pasechnik wrote:
>
> So there is more "software bureaucracy" here than just applying one patch.
>
% cd /usr/ports/lang
% svn status
A python27/files/patch-Modules___mathmodule.c
A python35/files/patch-Modules___mathmodule.c
A python36/files/patch-Modules___mathmodule.c
% svn diff python27/files/patch-Modules___mathmodule.c \
python35/files/patch-Modules___mathmodule.c \
python36/files/patch-Modules___mathmodule.c > py.diff
% cat py.diff
Index: python27/files/patch-Modules___mathmodule.c
===
--- python27/files/patch-Modules___mathmodule.c (nonexistent)
+++ python27/files/patch-Modules___mathmodule.c (working copy)
@@ -0,0 +1,38 @@
+--- ./Modules/mathmodule.c.orig2019-04-12 10:00:28.51846 -0700
./Modules/mathmodule.c 2019-04-12 10:01:24.846412000 -0700
+@@ -71,7 +71,7 @@
+ static const double sqrtpi = 1.772453850905516027298167483341145182798;
+
+ static double
+-sinpi(double x)
++_freebsd_ports_are_broken_sinpi(double x)
+ {
+ double y, r;
+ int n;
+@@ -270,7 +270,7 @@
+integer. */
+ if (absx > 200.0) {
+ if (x < 0.0) {
+-return 0.0/sinpi(x);
++return 0.0/_freebsd_ports_are_broken_sinpi(x);
+ }
+ else {
+ errno = ERANGE;
+@@ -294,7 +294,7 @@
+ }
+ z = z * lanczos_g / y;
+ if (x < 0.0) {
+-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
++r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
+ r -= z * r;
+ if (absx < 140.0) {
+ r /= pow(y, absx - 0.5);
+@@ -366,7 +366,7 @@
+ (x-0.5)*(log(x+lanczos_g-0.5)-1);
+ }
+ else {
+-r = log(pi) - log(fabs(sinpi(absx))) - log(absx) -
++r = log(pi) - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
log(absx) -
+ (log(lanczos_sum(absx)) - lanczos_g +
+ (absx-0.5)*(log(absx+lanczos_g-0.5)-1));
+ }
Index: python35/files/patch-Modules___mathmodule.c
===
--- python35/files/patch-Modules___mathmodule.c (nonexistent)
+++ python35/files/patch-Modules___mathmodule.c (working copy)
@@ -0,0 +1,38 @@
+--- ./Modules/mathmodule.c.orig2019-04-12 14:35:01.873406000 -0700
./Modules/mathmodule.c 2019-04-12 14:35:42.751667000 -0700
+@@ -67,7 +67,7 @@
+ static const double logpi = 1.144729885849400174143427351353058711647;
+
+ static double
+-sinpi(double x)
++_freebsd_ports_are_broken_sinpi(double x)
+ {
+ double y, r;
+ int n;
+@@ -296,7 +296,7 @@
+integer. */
+ if (absx > 200.0) {
+ if (x < 0.0) {
+-return 0.0/sinpi(x);
++return 0.0/_freebsd_ports_are_broken_sinpi(x);
+ }
+ else {
+ errno = ERANGE;
+@@ -320,7 +320,7 @@
+ }
+ z = z * lanczos_g / y;
+ if (x < 0.0) {
+-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
++r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
+ r -= z * r;
+ if (absx < 140.0) {
+ r /= pow(y, absx - 0.5);
+@@ -390,7 +390,7 @@
+ r += (absx - 0.5) * (log(absx + lanczos_g - 0.5) - 1);
+ if (x < 0.0)
+ /* Use reflection formula to get value for negative x. */
+-r = logpi - log(fabs(sinpi(absx))) - log(absx) - r;
++r = logpi - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
log(absx) - r;
+ if (Py_IS_INFINITY(r))
+ errno = ERANGE;
+ return r;
Index: python36/files/patch-Modules___mathmodule.c
===
--- python36/files/patch-Modules___mathmodule.c (nonexistent)
+++ python36/files/patch-Modules___mathmodule.c (working copy)
@@ -0,0 +1,38 @@
+--- ./Modules/mathmodule.c.orig2019-04-12 09:23:42.32935 -0700
./Modules/mathmodule.c 2019-04-12 09:24:37.977029000 -0700
+@@ -67,7 +67,7 @@
+ static const double logpi = 1.144729885849400174143427351353058711647;
+
+ static double
+-sinpi(double x)
++_freebsd_port_are_broken_sinpi(double x)
+ {
+ double y, r;
+ int n;
+@@ -296,7 +296,7 @@
+integer. */
+ if (absx > 200.0) {
+ if (x < 0.0) {
+-return 0.0/sinpi(x);
++return 0.0/_freebsd_port_are_broken_sinpi(x);
+ }
+ else {
+ errno = ERANGE;
+@@ -320,7 +320,7 @@
+ }
+ z = z * lanczos_g / y;
+ if (x < 0.0) {
+-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
++r = -pi / _freebsd_port_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
+ r -= z * r;
+ if (absx < 140.0) {
+ r /= pow(y, absx - 0.5);
+@@ -390,7 +390,7 @@
+ r += (absx - 0.5) * (log(absx + lanczos_g - 0.5) - 1);
+ if (x < 0.0)
+ /* Use reflection
PR 23672 - java/eclipse update
Hi, Are there any committers willing to take on: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236792 The current maintainer has been unresponsive, I'd like to adopt the port. The port QA will take a bit of time, the build takes ~20mins on a decent machine. Additionally, the source download can be finicky as git.eclipse.org appears to time out every now and then. Cheers. -- Jonathan Chen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 10:29 PM Steve Kargl wrote: > > On Fri, Apr 12, 2019 at 10:14:19PM +0200, Dima Pasechnik wrote: > > On Fri, Apr 12, 2019 at 9:57 PM Steve Kargl > > > > > > Doesn't matter what the python developer have done. > > > > Thanks, I see that you really appreciate my work... > > > > Your work is appreciated as much as my last 3 years of efforts > to get a trivially stupid patch acknowledged by python@freebsd. > > Why is it so harder for python@freebsd to do > > svn add files/patch-Modules___mathmodule.c > svn commit files/patch-Modules___mathmodule.c > FreeBSD has at least 4 active branches of Python, I gather (different "flavors" of one meta-port, lang/python, see https://www.freebsd.org/doc/en/books/porters-handbook/flavors-auto-python.html)). They are sufficiently different (at least Python 2.7 and Python 3.7 are sufficiently different to require different patches). So there is more "software bureaucracy" here than just applying one patch. And https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232792 has just one patch attached. I am not sure how to create patches for flavored ports. Dima > ? > > -- > Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 10:14:19PM +0200, Dima Pasechnik wrote: > On Fri, Apr 12, 2019 at 9:57 PM Steve Kargl > > > > Doesn't matter what the python developer have done. > > Thanks, I see that you really appreciate my work... > Your work is appreciated as much as my last 3 years of efforts to get a trivially stupid patch acknowledged by python@freebsd. Why is it so harder for python@freebsd to do svn add files/patch-Modules___mathmodule.c svn commit files/patch-Modules___mathmodule.c ? -- Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 9:57 PM Steve Kargl wrote: > > On Fri, Apr 12, 2019 at 09:19:30PM +0200, Dima Pasechnik wrote: > > On Fri, Apr 12, 2019 at 6:29 PM Steve Kargl > > wrote: > > > > > > On Fri, Apr 12, 2019 at 09:17:42AM -0700, Steve Kargl wrote: > > > > > > > > % find . -name math\* > > > > ./work/Python-3.6.8/Doc/library/math.rst > > > > ./work/Python-3.6.8/Modules/mathmodule.c > > > > ./work/Python-3.6.8/Lib/test/math_testcases.txt > > > > ./work/stage/usr/local/lib/python3.6/test/math_testcases.txt > > > > > > > > > > Well, this one is easy to fix. I've sent this patch for 2 to 3 > > > years now. I've opened a PR about it. Someday you guys might > > > actually fix this, because I will contacting core to get my > > > commit bit back. > > > > > This one is fixed in Python 3.7: > > https://github.com/python/cpython/blob/3.7/Modules/mathmodule.c > > via this commit: > > https://github.com/python/cpython/commit/4e6646fef5d2cc53422e4eca0b18201ed5a5c4b6 > > > > It is also fixed in Python 2.7. > > See https://github.com/python/cpython/pull/12027 for details. > > Doesn't matter what the python developer have done. Thanks, I see that you really appreciate my work... Indeed, the fix in Python 2.7 branch did not make it into 2.7.16 release of Python 2, so it will only be in the next Python 2 release. Anyhow, FreeBSD Python maintainers can cherry-pick the relevant upstream commits. Dima ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 09:19:30PM +0200, Dima Pasechnik wrote:
> On Fri, Apr 12, 2019 at 6:29 PM Steve Kargl
> wrote:
> >
> > On Fri, Apr 12, 2019 at 09:17:42AM -0700, Steve Kargl wrote:
> > >
> > > % find . -name math\*
> > > ./work/Python-3.6.8/Doc/library/math.rst
> > > ./work/Python-3.6.8/Modules/mathmodule.c
> > > ./work/Python-3.6.8/Lib/test/math_testcases.txt
> > > ./work/stage/usr/local/lib/python3.6/test/math_testcases.txt
> > >
> >
> > Well, this one is easy to fix. I've sent this patch for 2 to 3
> > years now. I've opened a PR about it. Someday you guys might
> > actually fix this, because I will contacting core to get my
> > commit bit back.
> >
> This one is fixed in Python 3.7:
> https://github.com/python/cpython/blob/3.7/Modules/mathmodule.c
> via this commit:
> https://github.com/python/cpython/commit/4e6646fef5d2cc53422e4eca0b18201ed5a5c4b6
>
> It is also fixed in Python 2.7.
> See https://github.com/python/cpython/pull/12027 for details.
Doesn't matter what the python developer have done. A patch is
still required to build lang/python27. Here's yet another
copy of the patch.
--- ./Modules/mathmodule.c.orig 2019-04-12 10:00:28.51846 -0700
+++ ./Modules/mathmodule.c 2019-04-12 10:01:24.846412000 -0700
@@ -71,7 +71,7 @@
static const double sqrtpi = 1.772453850905516027298167483341145182798;
static double
-sinpi(double x)
+_freebsd_ports_are_broken_sinpi(double x)
{
double y, r;
int n;
@@ -270,7 +270,7 @@
integer. */
if (absx > 200.0) {
if (x < 0.0) {
-return 0.0/sinpi(x);
+return 0.0/_freebsd_ports_are_broken_sinpi(x);
}
else {
errno = ERANGE;
@@ -294,7 +294,7 @@
}
z = z * lanczos_g / y;
if (x < 0.0) {
-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
+r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
r -= z * r;
if (absx < 140.0) {
r /= pow(y, absx - 0.5);
@@ -366,7 +366,7 @@
(x-0.5)*(log(x+lanczos_g-0.5)-1);
}
else {
-r = log(pi) - log(fabs(sinpi(absx))) - log(absx) -
+r = log(pi) - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
log(absx) -
(log(lanczos_sum(absx)) - lanczos_g +
(absx-0.5)*(log(absx+lanczos_g-0.5)-1));
}
--
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 6:29 PM Steve Kargl
wrote:
>
> On Fri, Apr 12, 2019 at 09:17:42AM -0700, Steve Kargl wrote:
> >
> > % find . -name math\*
> > ./work/Python-3.6.8/Doc/library/math.rst
> > ./work/Python-3.6.8/Modules/mathmodule.c
> > ./work/Python-3.6.8/Lib/test/math_testcases.txt
> > ./work/stage/usr/local/lib/python3.6/test/math_testcases.txt
> >
>
> Well, this one is easy to fix. I've sent this patch for 2 to 3
> years now. I've opened a PR about it. Someday you guys might
> actually fix this, because I will contacting core to get my
> commit bit back.
>
This one is fixed in Python 3.7:
https://github.com/python/cpython/blob/3.7/Modules/mathmodule.c
via this commit:
https://github.com/python/cpython/commit/4e6646fef5d2cc53422e4eca0b18201ed5a5c4b6
It is also fixed in Python 2.7.
See https://github.com/python/cpython/pull/12027 for details.
I've just asked whether upstream will consider backporting this to
Python 3.5 and 3.6.
If not, it would need to be done in FreeBSD only.
>
>
> --- work/Python-3.6.8/Modules/mathmodule.c.orig 2019-04-12 09:23:42.32935
> -0700
> +++ work/Python-3.6.8/Modules/mathmodule.c 2019-04-12 09:24:37.977029000
> -0700
> @@ -67,7 +67,7 @@
> static const double logpi = 1.144729885849400174143427351353058711647;
>
> static double
> -sinpi(double x)
> +_freebsd_ports_are_broken_sinpi(double x)
> {
> double y, r;
> int n;
> @@ -296,7 +296,7 @@
> integer. */
> if (absx > 200.0) {
> if (x < 0.0) {
> -return 0.0/sinpi(x);
> +return 0.0/_freebsd_ports_are_broken_sinpi(x);
> }
> else {
> errno = ERANGE;
> @@ -320,7 +320,7 @@
> }
> z = z * lanczos_g / y;
> if (x < 0.0) {
> -r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
> +r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
> lanczos_sum(absx);
> r -= z * r;
> if (absx < 140.0) {
> r /= pow(y, absx - 0.5);
> @@ -390,7 +390,7 @@
> r += (absx - 0.5) * (log(absx + lanczos_g - 0.5) - 1);
> if (x < 0.0)
> /* Use reflection formula to get value for negative x. */
> -r = logpi - log(fabs(sinpi(absx))) - log(absx) - r;
> +r = logpi - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
> log(absx) - r;
> if (Py_IS_INFINITY(r))
> errno = ERANGE;
> return r;
>
> --
> Steve
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Loopy Makefile?
Had the weirdest thing happen when trying to build x11/mate - it got stuck doing the same thing over and over. I'll restart and see if it happens again: [lots more of this:] ===> vala-0.40.11,1 depends on package: graphviz>=0 - not found ===> graphviz-2.40.1_8 depends on executable: gmake - found ===> graphviz-2.40.1_8 depends on executable: bison - found ===> graphviz-2.40.1_8 depends on package: pkgconf>=1.3.0_1 - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/gnome-mime-data-2.0.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/sm.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/ice.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xinerama.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xi.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xrandr.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xcursor.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xfixes.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xrender.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xau.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xdmcp.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xaw7.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xpm.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xmu.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xt.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/sm.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/ice.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xau.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xdmcp.pc - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/xp.pc - found ===> graphviz-2.40.1_8 depends on shared library: libltdl.so - found (/usr/local/lib/libltdl.so) ===> graphviz-2.40.1_8 depends on shared library: libpng.so - found (/usr/local/lib/libpng.so) ===> graphviz-2.40.1_8 depends on shared library: libfreetype.so - found (/usr/local/lib/libfreetype.so) ===> graphviz-2.40.1_8 depends on shared library: libfontconfig.so - found (/usr/local/lib/libfontconfig.so) ===> graphviz-2.40.1_8 depends on shared library: libexpat.so - found (/usr/local/lib/libexpat.so) ===> graphviz-2.40.1_8 depends on shared library: libgd.so - found (/usr/local/lib/libgd.so) ===> graphviz-2.40.1_8 depends on shared library: libgts.so - found (/usr/local/lib/libgts.so) ===> graphviz-2.40.1_8 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so) ===> graphviz-2.40.1_8 depends on shared library: libatk-1.0.so - found (/usr/local/lib/libatk-1.0.so) ===> graphviz-2.40.1_8 depends on shared library: libcairo.so - found (/usr/local/lib/libcairo.so) ===> graphviz-2.40.1_8 depends on shared library: libgconf-2.so - not found ===> gconf2-3.2.6_5 depends on executable: msgfmt - found ===> gconf2-3.2.6_5 depends on executable: gmake - found ===> gconf2-3.2.6_5 depends on package: pkgconf>=1.3.0_1 - found ===> gconf2-3.2.6_5 depends on file: /usr/local/bin/intltool-extract - found ===> gconf2-3.2.6_5 depends on executable: g-ir-scanner - found ===> gconf2-3.2.6_5 depends on shared library: libdbus-glib-1.so - found (/usr/local/lib/libdbus-glib-1.so) ===> gconf2-3.2.6_5 depends on shared library: libpolkit-gobject-1.so - found (/usr/local/lib/libpolkit-gobject-1.so) ===> gconf2-3.2.6_5 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so) ===> gconf2-3.2.6_5 depends on shared library: libatk-1.0.so - found (/usr/local/lib/libatk-1.0.so) ===> gconf2-3.2.6_5 depends on shared library: libdconf.so - not found ===> dconf-0.28.0 depends on package: vala>=0.18.1 - not found ===> vala-0.40.11,1 depends on package: graphviz>=0 - not found ===> graphviz-2.40.1_8 depends on executable: gmake - found ===> graphviz-2.40.1_8 depends on executable: bison - found ===> graphviz-2.40.1_8 depends on package: pkgconf>=1.3.0_1 - found ===> graphviz-2.40.1_8 depends on file: /usr/local/libdata/pkgconfig/gnome-mime-data-2.0.pc - found ===> graphviz-2.40.1_8 depends on file:
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 09:17:42AM -0700, Steve Kargl wrote:
>
> % find . -name math\*
> ./work/Python-3.6.8/Doc/library/math.rst
> ./work/Python-3.6.8/Modules/mathmodule.c
> ./work/Python-3.6.8/Lib/test/math_testcases.txt
> ./work/stage/usr/local/lib/python3.6/test/math_testcases.txt
>
Well, this one is easy to fix. I've sent this patch for 2 to 3
years now. I've opened a PR about it. Someday you guys might
actually fix this, because I will contacting core to get my
commit bit back.
--- work/Python-3.6.8/Modules/mathmodule.c.orig 2019-04-12 09:23:42.32935
-0700
+++ work/Python-3.6.8/Modules/mathmodule.c 2019-04-12 09:24:37.977029000
-0700
@@ -67,7 +67,7 @@
static const double logpi = 1.144729885849400174143427351353058711647;
static double
-sinpi(double x)
+_freebsd_ports_are_broken_sinpi(double x)
{
double y, r;
int n;
@@ -296,7 +296,7 @@
integer. */
if (absx > 200.0) {
if (x < 0.0) {
-return 0.0/sinpi(x);
+return 0.0/_freebsd_ports_are_broken_sinpi(x);
}
else {
errno = ERANGE;
@@ -320,7 +320,7 @@
}
z = z * lanczos_g / y;
if (x < 0.0) {
-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
+r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
r -= z * r;
if (absx < 140.0) {
r /= pow(y, absx - 0.5);
@@ -390,7 +390,7 @@
r += (absx - 0.5) * (log(absx + lanczos_g - 0.5) - 1);
if (x < 0.0)
/* Use reflection formula to get value for negative x. */
-r = logpi - log(fabs(sinpi(absx))) - log(absx) - r;
+r = logpi - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
log(absx) - r;
if (Py_IS_INFINITY(r))
errno = ERANGE;
return r;
--
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: "libicuuc.so.61" not found, required by "libephymisc.so" on RPi2
On Fri, Apr 12, 2019 at 05:59:20PM +0200, Kurt Jaeger wrote: > Hi! > > > Try this messy workaround: > > cd /usr/local/lib > ls -l libicuuc* > > Then symlink the available libicuuc.so.NN to the requested: > > ln -s libicuuc.so.NN libicuuc.so.61 > That worked, thank you! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 09:11:12AM -0700, Steve Kargl wrote: > cd /usr/ports/lang/python36 > make && make install > > ===> Installing for python36-3.6.8_2 > ===> Checking if python36 is already installed > ===> Registering installation for python36-3.6.8_2 > pkg-static: Unable to access file > /usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/_asyncio.so:No > such file or directory > pkg-static: Unable to access file > /usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/math.so:No > such file or directory > *** Error code 74 > > Stop. > make[1]: stopped in /usr/ports/lang/python36 > *** Error code 1 > > Stop. > make: stopped in /usr/ports/lang/python36 > > ? > % find . -name _async\* ./work/Python-3.6.8/Modules/_asynciomodule.c ./work/Python-3.6.8/Modules/clinic/_asynciomodule.c.h ./work/Python-3.6.8/PCbuild/_asyncio.vcxproj.filters ./work/Python-3.6.8/PCbuild/_asyncio.vcxproj ./work/Python-3.6.8/build/lib.freebsd-13.0-CURRENT-amd64-3.6/_asyncio_failed.so ./work/Python-3.6.8/build/temp.freebsd-13.0-CURRENT-amd64-3.6/usr/ports/lang/python36/work/Python-3.6.8/Modules/_asynciomodule.o ./work/stage/usr/local/lib/python3.6/lib-dynload/_asyncio_failed.so % find . -name math\* ./work/Python-3.6.8/Doc/library/math.rst ./work/Python-3.6.8/Modules/mathmodule.c ./work/Python-3.6.8/Lib/test/math_testcases.txt ./work/stage/usr/local/lib/python3.6/test/math_testcases.txt ? -- Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Default python is 3.6?
cd /usr/ports/lang/python36 make && make install ===> Installing for python36-3.6.8_2 ===> Checking if python36 is already installed ===> Registering installation for python36-3.6.8_2 pkg-static: Unable to access file /usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/_asyncio.so:No such file or directory pkg-static: Unable to access file /usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/math.so:No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/lang/python36 *** Error code 1 Stop. make: stopped in /usr/ports/lang/python36 ? -- Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: "libicuuc.so.61" not found, required by "libephymisc.so" on RPi2
On Fri, Apr 12, 2019 at 08:32:57AM -0700, bob prohaska wrote: > Can anybody tell me how to fix an error reported by www/epiphany on an RPi2, > "libicuuc.so.61" not found, required by "libephymisc.so" with the system > at 11.2-STABLE #2 r345473 and ports at 498696 ? > > Both epiphany and icu are up to date, there was no deliberate deletion > of old libraries but apparently it happened anyway. > > Thank for reading, and any guidance! > % cat /etc/libmap.conf includedir /usr/local/etc/libmap.d libicudata.so.63 libicudata.so.64 libicui18n.so.63 libicui18n.so.64 libicuio.so.63 libicuio.so.64 libicutu.so.63 libicutu.so.64 libicuuc.so.63 libicuuc.so.64 Choose your numbers accordingly. -- Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: "libicuuc.so.61" not found, required by "libephymisc.so" on RPi2
Hi! > Can anybody tell me how to fix an error reported by www/epiphany on an RPi2, > "libicuuc.so.61" not found, required by "libephymisc.so" with the system > at 11.2-STABLE #2 r345473 and ports at 498696 ? > > Both epiphany and icu are up to date, there was no deliberate deletion > of old libraries but apparently it happened anyway. > > Thank for reading, and any guidance! Try this messy workaround: cd /usr/local/lib ls -l libicuuc* Then symlink the available libicuuc.so.NN to the requested: ln -s libicuuc.so.NN libicuuc.so.61 -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
"libicuuc.so.61" not found, required by "libephymisc.so" on RPi2
Can anybody tell me how to fix an error reported by www/epiphany on an RPi2, "libicuuc.so.61" not found, required by "libephymisc.so" with the system at 11.2-STABLE #2 r345473 and ports at 498696 ? Both epiphany and icu are up to date, there was no deliberate deletion of old libraries but apparently it happened anyway. Thank for reading, and any guidance! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: python 3 subprocess performance
В Fri, 12 Apr 2019 12:41:53 +0200
Dima Pasechnik пишет:
> > > > В Thu, 11 Apr 2019 17:32:42 +0200
> > > > Jan Bramkamp пишет:
> > > >
> > > > > The reason is that that python does something stupid (tm). It
> > > > > tries to close all file descriptors (except a few whitelisted
> > > > > ones) up to the maximum file descriptor number. It does this
> > > > > by asking the kernel for the maximum possible number and
> > > > > closing everything it doesn't want to keep. Some time later
> > > > > someone came up with an optimization (read the open file
> > > > > descriptors from /dev/fd). All of this pain and suffering is
> > > > > caused by good old Ulrich Drepper braindamage:
> > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=10353.
> > > > >
> > > > > Most Linux distros have lower default file descriptor limits
> > > > > than FreeBSD making this workaround less painful. The correct
> > > > > solution would be to teach python3 about closefrom(2).
> > > >
> > > > Thank you for hint and testing!
> > > >
> > > > Indeed the problem is in closing more than 400,000 file
> > > > descriptors in loop. It seems that all current versions of
> > > > Python are affected. Python2 uses False as default value for
> > > > the close_fds parameter of the Popen constructor, so this issue
> > > > is mostly not visible. Python3 has changed this default to True.
> > > >
> > > > As Jan Bramkamp suggested, I've wrote simple patch to fix an
> > > > issue (see attached file). It seems the problem has gone.
> > >
> > > The attachment has been stripped out. Could you paste the diff
> > > into the message?
> >
> > Yes, sure.
> >
> > --- Modules/_posixsubprocess.c.orig 2018-12-24
> > 00:37:14.0 +0300 +++ Modules/_posixsubprocess.c
> > 2019-04-12 09:25:21.549389000 +0300 @@ -235,11 +235,15 @@
> > _close_fds_by_brute_force(long start_fd, }
> > start_fd = keep_fd + 1;
> > }
> > +#if defined(__FreeBSD__)
> > +closefrom(start_fd);
> > +#else
> > if (start_fd <= end_fd) {
> > for (fd_num = start_fd; fd_num < end_fd; ++fd_num) {
> > close(fd_num);
> > }
> > }
> > +#endif
> > }
> >
> > > If this is a Python issue, shouldn't this be reported upstream, on
> > > https://bugs.python.org ?
> >
> > May be. Rather, it is a FreeBSD-specific optimization.
>
> Well, closefrom() is also available in Darwin (a.k.a. MacOSX :-)),
> OpenBSD and NetBSD. (It's not documented in current MacOSX, but it is
> there, I just checked)
> Anyway, FreeBSD Python maintainers will ask for an upstream PR.
>
> I can do such a PR is noone else is willing to...
This would be good. Thanks!
--
Alexander Zagrebin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: python 3 subprocess performance
On Fri, Apr 12, 2019 at 9:46 AM Alexander Zagrebin wrote:
>
> В Fri, 12 Apr 2019 09:36:13 +0200
> Dima Pasechnik пишет:
>
> > On Fri, Apr 12, 2019 at 9:11 AM Alexander Zagrebin
> > wrote:
> > >
> > > В Thu, 11 Apr 2019 17:32:42 +0200
> > > Jan Bramkamp пишет:
> > >
> > > > The reason is that that python does something stupid (tm). It
> > > > tries to close all file descriptors (except a few whitelisted
> > > > ones) up to the maximum file descriptor number. It does this by
> > > > asking the kernel for the maximum possible number and closing
> > > > everything it doesn't want to keep. Some time later someone came
> > > > up with an optimization (read the open file descriptors
> > > > from /dev/fd). All of this pain and suffering is caused by good
> > > > old Ulrich Drepper braindamage:
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=10353.
> > > >
> > > > Most Linux distros have lower default file descriptor limits than
> > > > FreeBSD making this workaround less painful. The correct solution
> > > > would be to teach python3 about closefrom(2).
> > >
> > > Thank you for hint and testing!
> > >
> > > Indeed the problem is in closing more than 400,000 file descriptors
> > > in loop. It seems that all current versions of Python are affected.
> > > Python2 uses False as default value for the close_fds parameter of
> > > the Popen constructor, so this issue is mostly not visible.
> > > Python3 has changed this default to True.
> > >
> > > As Jan Bramkamp suggested, I've wrote simple patch to fix an issue
> > > (see attached file). It seems the problem has gone.
> >
> > The attachment has been stripped out. Could you paste the diff into
> > the message?
>
> Yes, sure.
>
> --- Modules/_posixsubprocess.c.orig 2018-12-24 00:37:14.0
> +0300 +++ Modules/_posixsubprocess.c 2019-04-12
> 09:25:21.549389000 +0300 @@ -235,11 +235,15 @@
> _close_fds_by_brute_force(long start_fd, }
> start_fd = keep_fd + 1;
> }
> +#if defined(__FreeBSD__)
> +closefrom(start_fd);
> +#else
> if (start_fd <= end_fd) {
> for (fd_num = start_fd; fd_num < end_fd; ++fd_num) {
> close(fd_num);
> }
> }
> +#endif
> }
>
> > If this is a Python issue, shouldn't this be reported upstream, on
> > https://bugs.python.org ?
>
> May be. Rather, it is a FreeBSD-specific optimization.
Well, closefrom() is also available in Darwin (a.k.a. MacOSX :-)),
OpenBSD and NetBSD. (It's not documented in current MacOSX, but it is
there, I just checked)
Anyway, FreeBSD Python maintainers will ask for an upstream PR.
I can do such a PR is noone else is willing to...
Dima
>
> --
> Alexander Zagrebin
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ sysutils/freefilesync | 9.8 | 10.11 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: python
Please excuse the top-post - I have only one sentence to add: I have tried to reproduce the issue with print/hplip by installing a QT4 flavored version from before the port update, and updating that port the new the non-flavor version with portmaster, which worked without issue - so I'm not able to test any fix to portmaster, currently ... Regards, STefan Am 11.04.19 um 09:29 schrieb Stefan Esser: > Am 11.04.19 um 00:03 schrieb ajtiM via freebsd-ports: >> Hi! >> >> With portmaster I try to update todays ports and python default is >> version 3.7 which is okay for me but not for hplip: >> ===>>> All >> >> hplip-3.17.11_3 (5/43) >> >> ===>>> Returning to dependency check for print/hplip >> ===>>> Dependency check complete for print/hplip >> >> ===>>> All >> hplip-3.17.11_3 (5/43) >> >> ===> hplip-3.17.11_4 FLAVOR is defined (to py27) while this port does >> not have FLAVORS.. >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/ports/print/hplip > > This is a bad effect caused by the removal of FLAVORs from an > installed port. > > Since the previous revision of this port required a flavor, it > will be updated with that same flavor passed as a parameter to > the build process. The build could just ignore the irrelevant > flavor, but that is not what the ports system does ... > > In this particular case the removal of QT4 is the cause. The > port used to support flavors "qt4" and "qt5" and to fix this > issue for portmaster, entries in MOVED should exist that make > upgrades use print/hplip without flavor, whether the qt4 or > qt5 version was installed. > > I plan to add code to portmaster to verify that a FLAVOR that > is to be used for a port still applies, before starting to > build it. > > But it is not obvious to me what to do for all of the cases > that exist: > > 1) FLAVORS removed from the port -> build without flavors > > 2) Specific FLAVOR removed from the port -> build with default >flavor (?) > > Anyway, for the time being you'll have to deinstall the port > (use "pkg delete -f hplip" to prevent recursive deletion of > dependent ports) and then re-install it with portmaster (which > will build it without flavor, then. > > Another possibility is to remove the "flavor" annotation > registered for this port in the PKGDB, then portmaster will > upgrade the port without providing a FLAVOR to the build ... > > I'll see that I fix this problem in portmaster, but it will take > some time ... > > Regards, STefan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: python 3 subprocess performance
В Fri, 12 Apr 2019 09:36:13 +0200
Dima Pasechnik пишет:
> On Fri, Apr 12, 2019 at 9:11 AM Alexander Zagrebin
> wrote:
> >
> > В Thu, 11 Apr 2019 17:32:42 +0200
> > Jan Bramkamp пишет:
> >
> > > The reason is that that python does something stupid (tm). It
> > > tries to close all file descriptors (except a few whitelisted
> > > ones) up to the maximum file descriptor number. It does this by
> > > asking the kernel for the maximum possible number and closing
> > > everything it doesn't want to keep. Some time later someone came
> > > up with an optimization (read the open file descriptors
> > > from /dev/fd). All of this pain and suffering is caused by good
> > > old Ulrich Drepper braindamage:
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=10353.
> > >
> > > Most Linux distros have lower default file descriptor limits than
> > > FreeBSD making this workaround less painful. The correct solution
> > > would be to teach python3 about closefrom(2).
> >
> > Thank you for hint and testing!
> >
> > Indeed the problem is in closing more than 400,000 file descriptors
> > in loop. It seems that all current versions of Python are affected.
> > Python2 uses False as default value for the close_fds parameter of
> > the Popen constructor, so this issue is mostly not visible.
> > Python3 has changed this default to True.
> >
> > As Jan Bramkamp suggested, I've wrote simple patch to fix an issue
> > (see attached file). It seems the problem has gone.
>
> The attachment has been stripped out. Could you paste the diff into
> the message?
Yes, sure.
--- Modules/_posixsubprocess.c.orig 2018-12-24 00:37:14.0
+0300 +++ Modules/_posixsubprocess.c 2019-04-12
09:25:21.549389000 +0300 @@ -235,11 +235,15 @@
_close_fds_by_brute_force(long start_fd, }
start_fd = keep_fd + 1;
}
+#if defined(__FreeBSD__)
+closefrom(start_fd);
+#else
if (start_fd <= end_fd) {
for (fd_num = start_fd; fd_num < end_fd; ++fd_num) {
close(fd_num);
}
}
+#endif
}
> If this is a Python issue, shouldn't this be reported upstream, on
> https://bugs.python.org ?
May be. Rather, it is a FreeBSD-specific optimization.
--
Alexander Zagrebin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: python 3 subprocess performance
On Fri, Apr 12, 2019 at 9:11 AM Alexander Zagrebin wrote: > > В Thu, 11 Apr 2019 17:32:42 +0200 > Jan Bramkamp пишет: > > > The reason is that that python does something stupid (tm). It tries to > > close all file descriptors (except a few whitelisted ones) up to the > > maximum file descriptor number. It does this by asking the kernel for > > the maximum possible number and closing everything it doesn't want to > > keep. Some time later someone came up with an optimization (read the > > open file descriptors from /dev/fd). All of this pain and suffering is > > caused by good old Ulrich Drepper braindamage: > > https://sourceware.org/bugzilla/show_bug.cgi?id=10353. > > > > Most Linux distros have lower default file descriptor limits than > > FreeBSD making this workaround less painful. The correct solution > > would be to teach python3 about closefrom(2). > > Thank you for hint and testing! > > Indeed the problem is in closing more than 400,000 file descriptors in > loop. It seems that all current versions of Python are affected. > Python2 uses False as default value for the close_fds parameter of > the Popen constructor, so this issue is mostly not visible. > Python3 has changed this default to True. > > As Jan Bramkamp suggested, I've wrote simple patch to fix an issue (see > attached file). It seems the problem has gone. The attachment has been stripped out. Could you paste the diff into the message? If this is a Python issue, shouldn't this be reported upstream, on https://bugs.python.org ? Dima > > -- > Alexander Zagrebin > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: python 3 subprocess performance
В Thu, 11 Apr 2019 17:32:42 +0200 Jan Bramkamp пишет: > The reason is that that python does something stupid (tm). It tries to > close all file descriptors (except a few whitelisted ones) up to the > maximum file descriptor number. It does this by asking the kernel for > the maximum possible number and closing everything it doesn't want to > keep. Some time later someone came up with an optimization (read the > open file descriptors from /dev/fd). All of this pain and suffering is > caused by good old Ulrich Drepper braindamage: > https://sourceware.org/bugzilla/show_bug.cgi?id=10353. > > Most Linux distros have lower default file descriptor limits than > FreeBSD making this workaround less painful. The correct solution > would be to teach python3 about closefrom(2). Thank you for hint and testing! Indeed the problem is in closing more than 400,000 file descriptors in loop. It seems that all current versions of Python are affected. Python2 uses False as default value for the close_fds parameter of the Popen constructor, so this issue is mostly not visible. Python3 has changed this default to True. As Jan Bramkamp suggested, I've wrote simple patch to fix an issue (see attached file). It seems the problem has gone. -- Alexander Zagrebin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
