Re: www/py-html5lib with FLAVOR=py27 failed to build
Hi, Yasuhito On Mon, 27 Jul 2020 14:03:21 +0900, Yasuhito FUTATSUKI wrote: > > In article <20200727.112301.1619120197420987885.y...@utahime.org> > y...@utahime.org writes: > > > From: KIRIYAMA Kazuhiko > > Subject: www/py-html5lib with FLAVOR=py27 failed to build > > Date: Sat, 25 Jul 2020 15:17:04 +0900 > > > > > www/py-html5lib with FLAVOR=py27 had failed to build: > > > > I tried `cd /usr/ports/www/py-html5lib; make FLAVOR=py27 install` with > > following conditions, > > > > OS: 11.4-RELEASE, 12.1-RELEASE and 13-CURRENT r363475 (amd64) > > Ports tree: head r543492 > > > > And in all cases it compeletes without any error. > > > > Do you have any non-default setting about options or something related > > to ports build? > > www/py-html5lib@py27 run depends on devel/py-six@py27. > devel/py-six@py27 test depends on devel/py-pytest@py27. > devel/py-pytest@py27 test depends on devel/py-hypothesis@py27. > devel/py-hypothesis dropped py27 support on r538898. > > So it can't be built with test. I guess it is the reason. You are right !!! I've downgraded devel/py-hypothesis to r531478 (actually 522099 <= revision < 538898) and tried to build www/py-html5lib with FLAVOR=py27. Then package-recursive www/py-html5lib succesfully done ! And then package-recursive www/chromium had been done perfectly and all packages could be made !!! root@jdtpkxb:~ # svnlite log /usr/ports/devel/py-hypothesis : (snip) : r538898 | amdmi3 | 2020-06-16 00:37:32 +0900 (Tue, 16 Jun 2020) | 10 lines - Update to 5.16.0 Note that though this drops python2 support, py-hypothesis is only currently used in TEST_DEPENDS, so this should not affect any package building. PR: 246821 Submitted by: amdmi3 Approved by:maintainer timeout (sunpoet, 2 weeks) : (snip) : root@jdtpkxb:~ # I think amdmi3@'s decision had been wrong. Anyway I'm appreciate Mr.Johan Hendriks, Mr.Kevin Oberman, Mr.Jonathan Chen, Mr.Yasuhiro KIMURA, Mr.Yasuhito FUTATSU and Mr.Stefan E9fer. And I'm proud of ports community that help each other and keep feel free for Open Source philosophy. Thanks. --- Kazuhiko Kiriyama ___ 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: Chromium (& derivatives) and Python 2.7
## Adriaan de Groot (adr...@freebsd.org): > The Chromium build system -- and as a consequence, also QtWebEngine -- still > uses Python 2.7. This is going to be a real problem about six months down the > line, and I have no idea how upstream is going to deal with it. I've heard > there are patches buried deep within the chocolate factory, but not from > reliable sources. They have https://bugs.chromium.org/p/chromium/issues/detail?id=942720 but some of the blockers on that aren't really public. Given the number of commits and blockers on that, I'd guess this is not a quick weekend project... That's all I got (sorry if you already, *ahem* googled that), Christoph -- Spare Space ___ 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"
postfix-current marked erroneously broken for 12.1-STABLE and OpenSSL 1.1.1g
Hi, postfix-current has been marked broken recently: BROKEN_FreeBSD_11= error: OpenSSL-1.1.1 is the minimum supported version My system: root> uname -v FreeBSD 12.1-STABLE r363443 CUSTOM root> openssl version OpenSSL 1.1.1g 21 Apr 2020 root> grep openssl /usr/local/etc/poudriere.d/stable-make.conf DEFAULT_VERSIONS+= ssl=openssl The patch applied fixed it for me, but I am not sure whether it fixes it in all thinkable combinations of OSVERION and openssl version, though. Regards, Michael Makefile-postfix-curretn.patch Description: Binary data ___ 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"
libusb & API versions
I'm wondering about libusb, because the libusb in base is missing a bunch of "current" API, and the API version number doesn't match Linux (upstream?) idea of what was available in historical versions. tl;dr: would a libusb port make any sense? Is updating libusb in base feasible? Background: - KDE Plasma currently displays nothing useful in the System Information panel about USB devices. This is because it reads data from files in /sys .. and doesn't expect to find the source code of the operating system there. - Switching to libusb is an obvious improvement: libusb supports a dozen OS'es, with backends for NetBSD, OpenBSD, Solaris .. and not FreeBSD, for whatever reason, but we have our own libusb in base anyway. - *Current* upstream libusb has at least these two things that original version 1.0 libusb from 2010 or so didn't have: - libusb_device *libusb_get_parent(libusb_device *) - LIBUSB_SPEED_SUPER_PLUS - Our libusb.h defines an API version #define LIBUSB_API_VERSION 0x01000102 - libusb upstream introduced libusb_get_parent in v1.0.12 - libusb upstream introduced LIBUSBX_API_VERSION in v1.0.13, as 0x01000100 - much later LIBUSBX_API_VERSION was renamed LIBUSB_API_VERSION But it comes down to this: the API_VERSIONs don't match up with the available functionality; libusb 2.0 was though-about in 2012 or so, but never gained any traction. Our libusb has things for the apparently abandoned 2.0 API, but nothing for the continued evolution of the 1.0 API. Any recommendations? I'd like to avoid patches upstream, but if things need to be rewritten to match our libusb, so be it. [ade] signature.asc Description: This is a digitally signed message part.
Chromium (& derivatives) and Python 2.7
The Chromium build system -- and as a consequence, also QtWebEngine -- still uses Python 2.7. This is going to be a real problem about six months down the line, and I have no idea how upstream is going to deal with it. I've heard there are patches buried deep within the chocolate factory, but not from reliable sources. QtWebEngine is an even specialer case, since it's an LTS and also the last LTS in the Qt5 series, and I have real doubts about upstream -- The Qt Company -- being able or willing to deal with Python 2.7 deprecation there. Has anyone in FreeBSD tried to port the stuff over? I got about an hour or two into the porting process (making configure accept Python 3 is easy, but there's all these wretched code-generating scripts) and hit a brick wall of templating engines doing sensible Python 2.7 things. [ade] signature.asc Description: This is a digitally signed message part.
Not enough jobserver tokens when compiling www/firefox
Experiments with compiling www/firefox on a Pi3 running -current have finally stalled with: gmake[1]: INTERNAL: Exiting with 1 jobserver tokens available; should be 2! Updating /usr/ports doesn't seem to make a difference, changing the limit in /etc/make.conf from 2 to 3 changes the message to: gmake[1]: INTERNAL: Exiting with 1 jobserver tokens available; should be 3! so /etc/make.conf is being read correctly. The last entries in the log file are: gmake[4]: Nothing to be done for 'target-objects'. gmake[4]: Leaving directory '/usr/ports/www/firefox/work/.build/dom/filesystem' gmake[4]: Leaving directory '/usr/ports/www/firefox/work/.build/toolkit/library/rust' gmake[3]: Leaving directory '/usr/ports/www/firefox/work/.build' gmake[2]: Leaving directory '/usr/ports/www/firefox/work/.build' gmake[1]: Leaving directory '/usr/ports/www/firefox/work/.build' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Ports are at 543527, uname -a reports r362742. Thanks for reading and any suggestions! 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: www/py-html5lib with FLAVOR=py27 failed to build
On 27/07/2020 4:34 pm, Kubilay Kocak wrote: ). > > The strategy, plan and execution for deprecation of Python 2.7 and the > guidelines for deprecation and removal of Python 2.7 ports was not > coordinated with, discussed with or executed by the Python team, as it > should have been. > > The issues associated with this as well as the impact it has had on the > team, maintainers and and users has already been reported to core as one > set of example symptoms that form part of a broader report. > > Python is more than happy to address the issues associated with that > plan. I encourage and welcome interested developers, users, maintainers > who want to participate in improve the situation to join #freebsd-python > on freenode. > > > -- > koobs > @Python > > > > ___ > 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" > Thank-you Stefan I couldn't agree more. I use security/w3af for web scanning and have pursued upstream, but it was zapped from the ports infrastructure around March. Koobs sharing the perspective of @python is very much appreciated. I recall a time when changes to a "port" was the responsibility of the maintainer. Unfortunately python2.7 dependent ports are removed or scheduled to be removed outside the actual python2.7 EOL window, which is rather inexplicable. The EOL tyranny is significantly detrimental to FreeBSD's reputation as many well used, and in some cases necessary ports do not have an upgrade to 3.X plan. And yes, we should apply pressure upstream, but taking the ports away isn't "user" friendly; sans there being a significant security issue. :) I lament new users who decide to build ports only to find that they've been removed or marked broken due to download relocation. I would've thought that a FreeBSD distribution site would retain and contribute to FreeBSD being a pleasurable experience. Sadly I digress. ___ 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"
