Re: Python conflict on RPI2
On 13/04/2019 12:09 pm, 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. As an additional followup to Jans comment, see the original bugzilla report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226634 comment 10 onward ___ 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 12/04/2019 8:41 pm, Dima Pasechnik wrote:
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
Hi Dima,
Issue exists for this:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221700
Pending *upstreamable* patches for lang/python*, that we can carry
locally until released.
___
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: ports/lang major version updates outside of OS version updates
On Sat, Apr 13, 2019 at 10:59:41PM +0200, Dima Pasechnik wrote: > On Sat, Apr 13, 2019 at 10:41 PM Steve Kargl > > > > How about taking the patch in my previous email, apply > > to your tree (any port committer can take the patch), > > and actually commit it! > > > > This isn't rocket science. APPLY THE PATCH AND COMMIT! > > I don't have commit access to python FreeBSD port (or any port, in fact). > --- if I had said access it would have been done months ago... > There is nothing you can do :( I have jsut sent an email to freebsd-core requesting that I have be commit bit restored. I will commit my sinpi implementation. This will break lang/python27, lang/python35, and lang/python36, and by extension all ports that depend on one of these ports. It will hopefully mobilize someone from python@freebsd to act. -- 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"
Anyone wants to finish the Kingsoft WPS Office port
Hi guys; While I am a fan of the native tools, some competition is always good :). I have heard many good things of Kingsoft WPS Office, which is freely available for linux and apparently the WPS community fixed the CentOS issues that were stopping this from working on the linuxulator. I started a port but I have no time to finish it, plus linux ports are not my cup of tea. Perhaps anyone feels like giving it a spin it? https://people.freebsd.org/~pfg/ports/linux-wps-office.tgz Enjoy, Pedro. ___ 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: ports/lang major version updates outside of OS version updates
On Sat, Apr 13, 2019 at 10:41 PM Steve Kargl wrote: > > On Sat, Apr 13, 2019 at 08:49:43PM +0200, Dima Pasechnik wrote: > > On Sat, Apr 13, 2019 at 8:01 PM Steve Kargl > > > > > > My patches have absolutely nothing to do with making > > > 3.6 the default python version. > > > > > > I have added functions to libm that are included in > > > two ISO standards. This causes a name conflict with > > > sinpi() in python. My patches trivially rename > > > python's sinpi() to avoid the conflict. For some reason > > > beyond the comprehension of mortal man, python@freebsd > > > refuses to add the patches to the port. > > > > they asked for these patches to be upstreamed, and I did it, so these > > patches now are in not yet released upstream python 2 and python 3 > > branches. > > Backporting them to python@freebsd is totally trivial. > > > > What else can be done here? > > How about taking the patch in my previous email, apply > to your tree (any port committer can take the patch), > and actually commit it! > > This isn't rocket science. APPLY THE PATCH AND COMMIT! I don't have commit access to python FreeBSD port (or any port, in fact). --- if I had said access it would have been done months ago... 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: ports/lang major version updates outside of OS version updates
On Sat, Apr 13, 2019 at 08:49:43PM +0200, Dima Pasechnik wrote: > On Sat, Apr 13, 2019 at 8:01 PM Steve Kargl > > > > My patches have absolutely nothing to do with making > > 3.6 the default python version. > > > > I have added functions to libm that are included in > > two ISO standards. This causes a name conflict with > > sinpi() in python. My patches trivially rename > > python's sinpi() to avoid the conflict. For some reason > > beyond the comprehension of mortal man, python@freebsd > > refuses to add the patches to the port. > > they asked for these patches to be upstreamed, and I did it, so these > patches now are in not yet released upstream python 2 and python 3 > branches. > Backporting them to python@freebsd is totally trivial. > > What else can be done here? How about taking the patch in my previous email, apply to your tree (any port committer can take the patch), and actually commit it! This isn't rocket science. APPLY THE PATCH AND COMMIT! -- 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: [PATCH]: databases/mongodb40 update to latest release
Hi! > 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 Thanks, committed. -- 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"
Re: ports/lang major version updates outside of OS version updates
On Sat, Apr 13, 2019 at 8:01 PM Steve Kargl wrote: > > On Sat, Apr 13, 2019 at 07:35:25AM -0700, Roger Marquis wrote: > > >> 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. > > > > You sure about that Dima? Whether one or several the patching doesn't > > appear to be complicated or difficult to maintain. > > > > > On Fri, Apr 12, 2019 at 02:58:22PM -0700, Steve Kargl wrote: > > > For those people following along in the mailing list, Dima > > > sent me a private reply that took this thread off the list. > > > I am done trying to help fix the python ports. > > > > Thanks for the good work Steve. > > > > Many of us are still wondering why this change was made outside of a > > major OS version update. Wouldn't that have prevented the build bug > > which started this thread? > > > > Considering the incompatibilities between python 2.X and 3.x (which > > Guido has admitted was a mistake) please consider this a ports policy > > request to require significant lang/* version updates be predicated on > > equally significant OS version updates. > > > > My patches have absolutely nothing to do with making > 3.6 the default python version. > > I have added functions to libm that are included in > two ISO standards. This causes a name conflict with > sinpi() in python. My patches trivially rename > python's sinpi() to avoid the conflict. For some reason > beyond the comprehension of mortal man, python@freebsd > refuses to add the patches to the port. they asked for these patches to be upstreamed, and I did it, so these patches now are in not yet released upstream python 2 and python 3 branches. Backporting them to python@freebsd is totally trivial. What else can be done here? I can add these patches to the bug tracker... 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" ___ 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: ports/lang major version updates outside of OS version updates
On Sat, Apr 13, 2019 at 07:35:25AM -0700, Roger Marquis wrote: > >> 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. > > You sure about that Dima? Whether one or several the patching doesn't > appear to be complicated or difficult to maintain. > > > On Fri, Apr 12, 2019 at 02:58:22PM -0700, Steve Kargl wrote: > > For those people following along in the mailing list, Dima > > sent me a private reply that took this thread off the list. > > I am done trying to help fix the python ports. > > Thanks for the good work Steve. > > Many of us are still wondering why this change was made outside of a > major OS version update. Wouldn't that have prevented the build bug > which started this thread? > > Considering the incompatibilities between python 2.X and 3.x (which > Guido has admitted was a mistake) please consider this a ports policy > request to require significant lang/* version updates be predicated on > equally significant OS version updates. > My patches have absolutely nothing to do with making 3.6 the default python version. I have added functions to libm that are included in two ISO standards. This causes a name conflict with sinpi() in python. My patches trivially rename python's sinpi() to avoid the conflict. For some reason beyond the comprehension of mortal man, python@freebsd refuses to add the patches to the port. -- 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: PR 23672 - java/eclipse update
Hi! While test-building java/eclipse in poudriere from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236792 I run into this problem: During the build, git is used to create a local git repo. This works in current, because the build inside poudriere runs as root and therefore, this works: git init git config --global user.email "ecli...@freebsd.org" git config --global user.name "Eclipse" git add . It fails on 12.0 and 11.2, because the build is run as user nobody with home: /nonexistent error: could not lock config file /nonexistent/.gitconfig: No such file or directory error: could not lock config file /nonexistent/.gitconfig: No such file or directory Any hints how I can force git to use existing directory as $HOME so that git does not fail ? -- 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"
Re: ports/lang major version updates outside of OS version updates
On Sat, 13 Apr 2019 07:35:25 -0700 (PDT), Roger Marquis stated: >>> 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. > >You sure about that Dima? Whether one or several the patching doesn't >appear to be complicated or difficult to maintain. > >> On Fri, Apr 12, 2019 at 02:58:22PM -0700, Steve Kargl wrote: >> For those people following along in the mailing list, Dima >> sent me a private reply that took this thread off the list. >> I am done trying to help fix the python ports. > >Thanks for the good work Steve. > >Many of us are still wondering why this change was made outside of a >major OS version update. Wouldn't that have prevented the build bug >which started this thread? > >Considering the incompatibilities between python 2.X and 3.x (which >Guido has admitted was a mistake) please consider this a ports policy >request to require significant lang/* version updates be predicated on >equally significant OS version updates. > >Roger Marquis There is a fallacy in that reasoning. If a major software version was released in the infancy of a new OS version release, a considerable amount of time could ensue before a new OS version was released with the new software version. Any OS which is not flexible or robust enough to accept and work with newer software is doing its user base a disservice. At the very least,the OS authors should be able to release a minor version bump to the OS in order to allow it to accommodate the newer software. -- Carmel ___ 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"
ports/lang major version updates outside of OS version updates
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. You sure about that Dima? Whether one or several the patching doesn't appear to be complicated or difficult to maintain. On Fri, Apr 12, 2019 at 02:58:22PM -0700, Steve Kargl wrote: For those people following along in the mailing list, Dima sent me a private reply that took this thread off the list. I am done trying to help fix the python ports. Thanks for the good work Steve. Many of us are still wondering why this change was made outside of a major OS version update. Wouldn't that have prevented the build bug which started this thread? Considering the incompatibilities between python 2.X and 3.x (which Guido has admitted was a mistake) please consider this a ports policy request to require significant lang/* version updates be predicated on equally significant OS version updates. Roger Marquis ___ 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: > 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? www/firefox requires both and will do so for years in future because "there isn't a compelling reason to port code that isn't being actively updated." https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg24187.html > The goal at hand is merely to compile a working version of firefox. If you need handholding use poudriere. Most ports/ committers and the package cluster uses that, so any bustage uncovered is usually a bug. poudriere builds in a pristine environment, so the above conflict wouldn't happen. After r498530 easy_install symlink would be moved from py27-setuptools to py36-setuptools package. ___ 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 02:58:22PM -0700, Steve Kargl wrote: > 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 For those people following along in the mailing list, Dima sent me a private reply that took this thread off the list. I am done trying to help fix the python ports. -- 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"
