Re: Problem building py-cryptography
On 20/05/2021 2:17 pm, Simon Wright wrote:
On 20/05/2021 12:00 pm, Kubilay Kocak wrote:
On 20/05/2021 1:21 pm, Simon Wright wrote:
Hi all,
I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.
I tried removing the libressl dependency but that made no difference. Is
anyone else seeing this and can anyone point me in the right direction
to get this fixed please?
Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography
Hi Simon,
Is the issue reproducible without ccache?
Also, make.conf still shows:
DEFAULT_VERSIONS+=ssl=libressl
Thanks Kubs. When I tested I removed libressl, tried the build again and
it failed so I replaced libressl after the test.
Removing ccache (and with libressl) made no difference - still the same
error. I then removed the libressl dependency and I reran the build - no
ccache and no libressl - the build still failed, same error message.
Since no-one else has reported this I suppose it should be something in
my environment . . . . But what? :)
While the build error *with libressl* is known, matching that reported in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255241
Failing to build without libressl is unexpected.
Jump into the poudriere jail to confirm (or not) its libressl that's
being installed and used. Could be:
- Custom WRKDIRPREFIX?
- An overriding jail or set (-z) specific poudriere foo-make.conf?
Note, the OP build log contains:
[pkg.home.santos-wright.net] | | `-- Installing libressl-3.3.3...
[pkg.home.santos-wright.net] | | `-- Extracting libressl-3.3.3:
With defaults, base openssl will be used, and you wont see libressl as a
dependency in the build.
[1] build/temp.freebsd-13.0-RELEASE-amd64-3.8/_openssl.c:2172:19: error:
expected identifier or '('
static const long SSL_OP_NO_DTLSv1 = 0;
Regards,
Simon.
make.conf
WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite
Poudriere ports list:
devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql
___
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: Problem building py-cryptography
On 20/05/2021 12:00 pm, Kubilay Kocak wrote: On 20/05/2021 1:21 pm, Simon Wright wrote: Hi all, I've been unable to build security/py-cryptography for about 10 days now. The build in Poudriere under 12.2 and 13.0 fail with a "Bad_C++_code" error. I tried removing the libressl dependency but that made no difference. Is anyone else seeing this and can anyone point me in the right direction to get this fixed please? Below is my make.conf, list of poudriere-built ports and the full poudriere log for py-cryptography Hi Simon, Is the issue reproducible without ccache? Also, make.conf still shows: DEFAULT_VERSIONS+=ssl=libressl Thanks Kubs. When I tested I removed libressl, tried the build again and it failed so I replaced libressl after the test. Removing ccache (and with libressl) made no difference - still the same error. I then removed the libressl dependency and I reran the build - no ccache and no libressl - the build still failed, same error message. Since no-one else has reported this I suppose it should be something in my environment . . . . But what? :) Regards, Simon. make.conf WRKDIRPREFIX=/usr/tmp OPTIONS_SET=GECKO CUPS NOI4B=1 OPTIONS_SET+=NO-X11 CUPS_OVERWRITE_BASE=YES WITH_VIM_OPTIONS=yes DEFAULT_VERSIONS+=ssl=libressl bdb=5 VALID_CATEGORIES+=local SVN=svnlite Poudriere ports list: devel/git@lite dns/bind916 emulators/open-vm-tools@nox11 ftp/curl graphics/cairo local/vmserver-baseline mail/postfix print/hplip sysutils/facter sysutils/puppet6 sysutils/rsyslog8 sysutils/rubygem-puppetserver-ca www/apt-cacher-ng www/mod_log_sql ___ 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: Problem building py-cryptography
On 20/05/2021 1:21 pm, Simon Wright wrote: Hi all, I've been unable to build security/py-cryptography for about 10 days now. The build in Poudriere under 12.2 and 13.0 fail with a "Bad_C++_code" error. I tried removing the libressl dependency but that made no difference. Is anyone else seeing this and can anyone point me in the right direction to get this fixed please? Below is my make.conf, list of poudriere-built ports and the full poudriere log for py-cryptography Thanks, Simon Wright. Hi Simon, Is the issue reproducible without ccache? Also, make.conf still shows: DEFAULT_VERSIONS+=ssl=libressl make.conf WRKDIRPREFIX=/usr/tmp OPTIONS_SET=GECKO CUPS NOI4B=1 OPTIONS_SET+=NO-X11 CUPS_OVERWRITE_BASE=YES WITH_VIM_OPTIONS=yes DEFAULT_VERSIONS+=ssl=libressl bdb=5 VALID_CATEGORIES+=local SVN=svnlite Poudriere ports list: devel/git@lite dns/bind916 emulators/open-vm-tools@nox11 ftp/curl graphics/cairo local/vmserver-baseline mail/postfix print/hplip sysutils/facter sysutils/puppet6 sysutils/rsyslog8 sysutils/rubygem-puppetserver-ca www/apt-cacher-ng www/mod_log_sql ___ 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"
On aarch64: "sysutils/hpacucli dependency on misc/compat4x has wrong PKGNAME"
I was doing a poudriere pkgclean under: # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 and got a message: [00:07:18] Warning: sysutils/hpacucli dependency on misc/compat4x has wrong PKGNAME of 'compat4x-i386' but should be 'compat4x-aarch64' For reference: # cd /usr/ports # ~/fbsd-based-on-what-commit.sh branch: main merge-base: b309895b3544ffba9e8df8786062ec6013c752ff merge-base: CommitDate: 2021-05-17 06:32:36 + b309895b3544 (HEAD -> main, freebsd/main, freebsd/HEAD) x11-themes/kde-icons-black-and-white: add LICENSE, take MAINTAINER n545993 (--first-parent --count for merge-base) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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"
Problem building py-cryptography
Hi all, I've been unable to build security/py-cryptography for about 10 days now. The build in Poudriere under 12.2 and 13.0 fail with a "Bad_C++_code" error. I tried removing the libressl dependency but that made no difference. Is anyone else seeing this and can anyone point me in the right direction to get this fixed please? Below is my make.conf, list of poudriere-built ports and the full poudriere log for py-cryptography Thanks, Simon Wright. make.conf WRKDIRPREFIX=/usr/tmp OPTIONS_SET=GECKO CUPS NOI4B=1 OPTIONS_SET+=NO-X11 CUPS_OVERWRITE_BASE=YES WITH_VIM_OPTIONS=yes DEFAULT_VERSIONS+=ssl=libressl bdb=5 VALID_CATEGORIES+=local SVN=svnlite Poudriere ports list: devel/git@lite dns/bind916 emulators/open-vm-tools@nox11 ftp/curl graphics/cairo local/vmserver-baseline mail/postfix print/hplip sysutils/facter sysutils/puppet6 sysutils/rsyslog8 sysutils/rubygem-puppetserver-ca www/apt-cacher-ng www/mod_log_sql Poudriere build log: =>> Building security/py-cryptography build started at Thu May 20 10:58:41 PST 2021 port directory: /usr/ports/security/py-cryptography package name: py38-cryptography-3.3.2 building for: FreeBSD pkg.home.santos-wright.net 13.0-RELEASE FreeBSD 13.0-RELEASE amd64 maintained by: ko...@freebsd.org Makefile ident: Poudriere version: 3.3.99.20210303_2 Host OSVERSION: 1300139 Jail OSVERSION: 1300139 Job Id: 01 ---Begin Environment--- SHELL=/bin/csh OSVERSION=1300139 UNAME_v=FreeBSD 13.0-RELEASE UNAME_r=13.0-RELEASE BLOCKSIZE=K MAIL=/var/mail/root MM_CHARSET=UTF-8 LANG=C.UTF-8 STATUS=1 HOME=/root PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin LOCALBASE=/usr/local USER=root LIBEXECPREFIX=/usr/local/libexec/poudriere POUDRIERE_VERSION=3.3.99.20210303_2 MASTERMNT=/export/poudriere/data/.m/FreeBSD_13_amd64-default/ref LC_COLLATE=C POUDRIERE_BUILD_TYPE=bulk PACKAGE_BUILDING=yes SAVED_TERM=xterm-256color OUTPUT_REDIRECTED_STDERR=4 OUTPUT_REDIRECTED=1 PWD=/export/poudriere/data/.m/FreeBSD_13_amd64-default/ref/.p/pool OUTPUT_REDIRECTED_STDOUT=3 P_PORTS_FEATURES=FLAVORS SELECTED_OPTIONS MASTERNAME=FreeBSD:13:amd64-default SCRIPTPREFIX=/usr/local/share/poudriere OLDPWD=/export/poudriere/data/.m/FreeBSD_13_amd64-default/ref/.p SCRIPTPATH=/usr/local/share/poudriere/bulk.sh POUDRIEREPATH=/usr/local/bin/poudriere ---End Environment--- ---Begin Poudriere Port Flags/Env--- PORT_FLAGS= PKGENV= FLAVOR=py38 DEPENDS_ARGS= MAKE_ARGS= FLAVOR=py38 ---End Poudriere Port Flags/Env--- ---Begin OPTIONS List--- ---End OPTIONS List--- --MAINTAINER-- ko...@freebsd.org --End MAINTAINER-- --CONFIGURE_ARGS-- --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- PYTHON="/usr/local/bin/python3.8" XDG_DATA_HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38 XDG_CONFIG_HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38 HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38 TMPDIR="/tmp" PATH=/wrkdirs/usr/ports/security/py-cryptography/work-py38/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin SHELL=/bin/sh CONFIG_SHELL=/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib OPENSSLRPATH=/usr/local/lib XDG_DATA_HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38 XDG_CONFIG_HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38 HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38 TMPDIR="/tmp" PATH=/wrkdirs/usr/ports/security/py-cryptography/work-py38/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES LDSHARED="cc -shared" PYTHONDONTWRITEBYTECODE= PYTHONOPTIMIZE= PREFIX=/usr/local LOCALBASE=/usr/local CC="cc" CFLAGS="-O2 -pipe -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing " CPP="cpp" CPPFLAGS="" LDFLAGS=" -L/usr/local/lib -Wl,-rpath,/usr/local/lib -fstack-protector-strong " LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" --End MAKE_ENV-- --PLIST_SUB-- PYTHON_INCLUDEDIR=include/python3.8 PYTHON_LIBDIR=lib/python3.8 PYTHON_PLATFORM=freebsd13 PYTHON_SITELIBDIR=lib/python3.8/site-packages PYTHON_SUFFIX=38 PYTHON_EXT_SUFFIX=.cpython-38 PYTHON_VER=3.8 PYTHON_VERSION=python3.8 PYTHON2="@comment " PYTHON3="" OSREL=13.0 PREFIX=%D LOCALBASE=/usr/local RESETPREFIX=/usr/local LIB32DIR=lib DOCSDIR="share/doc/py38-cryptography" EXAMPLESDIR="share/examples/py38-cryptography" DATADIR="share/py38-cryptography" WWWDIR="www/py38-cryptography" ETCDIR="etc/py38-cryptography" --End PLIST_SUB-- --SUB_LIST-- PREFIX=/usr/local LOCALBASE=/usr/local DATADIR=/usr/local/share/py38-cryptography
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 2021-May-19, at 14:17, Mark Millard wrote: > On 2021-May-19, at 10:29, Mark Millard wrote: > >> bob prohaska fbsd at www.zefox.net wrote on >> Wed May 19 16:09:32 UTC 2021 : >> >>> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote: >>> >>> [portmaster background omitted] >>> If you want to give the attached port a try, it will install LUA and some >>> >>> >>> I tried ports-mgmt/portmaster, it got stuck the same as make. >>> Unless the new version behaves very differently I'm doubtful it'll >>> help. >>> >>> At the moment it looks like lxqt requires both python37 and python38. >>> The needs seem to arise at different stages of the build, so perhaps >>> they can be invoked, used and removed sequentially, but at this point >>> deleting python37 causes enough collateral damage to make further >>> progress impossible, or at least non-obvious. >>> >>> If the conflict is really limited to merely naming two versions of >>> /usr/local/bin/easy_install fixing the naming convention seems to be >>> the obvious answer. I remain baffled why something called "easy_install" >>> remains essential after installatiion. Unless of course it's not really >>> an installer. Even so, a more sensible naming scheme strikes me as helpful. >>> >>> It isn't apparent to me that something like poudriere can solve this sort >>> of problem either. If poudriere attempts to build lxqt in a single jail >>> it looks like the conflict will emerge within the jail. >> >> The FreeBSD port building servers use poudriere and are not having >> a problem. The problem is your messed up environment that already >> has the inappropriate mixed that poudriere and the package installers >> it makes would never produce. >> >> The following show lxqt (10 ports have that in their names) as >> attempted to be built (not skipped) and all were successful >> instead of any failing: > > It may not be obvious that I looked up builds on > ampere2.nyi.freebsd.org because that is the builder for > targeting arrch64 main [so: 14] builds. That is why the > url's below have: "mastername=main-arm64-default". > Thus the evidence includes aarch64 coverage. > >> Built with python37: >> Apr 20: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p338d8ba0f777_s5a89498d19 >> Apr 13: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c >> Apr 17: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f >> >> Built with python38: >> May 11: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e >> May 15: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab >> May 18: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c >> May 6: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0 >> >> These imply that all the prerequisite ports for the build >> were also built and working for doing so. >> >>> It'd have to >>> split the build between two or more jails and then merge the (compatible) >>> executables into a third jail for completion, AIUI. >> >> No such problems in a correctly configured system. >> You are stuck trying to get out of a incorrect >> system configuration. >> >> poudriere ignores your system configuration and uses >> its own separate one to do its builds. >> >>> At this point I'm stuck. >> >> So you had a poudriere failure? If so, report the details, >> such as publishing someplace the log file showing the >> failure. Otherwise, you are not stuck. >> >> Once poudriere has built the packages, you would set up >> pkg to use those builds and then force-(re)install all >> your ports to use the ones poudriere built. (Not just >> lxqt.) This would get all your ports back to being >> coherent with each other. >> >> Presuming a file listing the packages that you want >> to be sure are installed (not needing to list >> dependencies) and that that pkg has arleady been >> redirected to use the poudriere-built packages: >> >> # pkg delete -a >> # pkg install `cat file-listing-packages` >> >> Technically, I do not know if your environment is so >> messed up that pkg delete -a would fail. >> >> I'll note that if pkg instead still points to the >> FreeBSD servers (such as quarterly), the same 2 >> command sequence should re-establish those builds. >> > > I started a: > > # poudriere bulk -j13_0R-CA72 x11-wm/lxqt > > on one of the aarch64 systems that I have access to > (cortex-a72 with 4 cores). It reports (based on prior > history of other ports building that might overlap and > so avoid some things needing to be built this time): > > . . . > [00:00:25] Building 99 packages using 4 builders > . . . > [00:00:38] [03] [00:00:00] Building lang/rust | rust-1.52.1 > . . . > > so it looks like it will be hours from when
Re: Error reinstalling python 3.8.10 from ports
On 20/05/2021 1:54 am, Xavier Humbert wrote: Hi, I got trouble with python 3.8.10 at reinstall stage : ===> Registering installation for python38-3.8.10 pkg-static: Unable to access file /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No such file or directory pkg-static: Unable to access file /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_bisect.cpython-38.so:No such file or directory And a bunch of others (the whole lib-dynload directory actually) In fact those files are almost present : the are not named eg _asyncio.cpython-38.so , but asyncio.cpython-38*d*.so Where from comes this *d* letter, which is not in pkg-plist ? Cheers, Xavier d is the debug ABI suffix, added with DEBUG option is enabled. I recall an upstream discussion or issue on removing the use of ABI tags, but can't recall if it landed and if so what versions it was merge to. CC'ing committer of the latest lang/python38 update ___ 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 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 2021-May-19, at 10:29, Mark Millard wrote: > bob prohaska fbsd at www.zefox.net wrote on > Wed May 19 16:09:32 UTC 2021 : > >> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote: >>> >> >> [portmaster background omitted] >> >>> If you want to give the attached port a try, it will install LUA and some >> >> >> I tried ports-mgmt/portmaster, it got stuck the same as make. >> Unless the new version behaves very differently I'm doubtful it'll >> help. >> >> At the moment it looks like lxqt requires both python37 and python38. >> The needs seem to arise at different stages of the build, so perhaps >> they can be invoked, used and removed sequentially, but at this point >> deleting python37 causes enough collateral damage to make further >> progress impossible, or at least non-obvious. >> >> If the conflict is really limited to merely naming two versions of >> /usr/local/bin/easy_install fixing the naming convention seems to be >> the obvious answer. I remain baffled why something called "easy_install" >> remains essential after installatiion. Unless of course it's not really >> an installer. Even so, a more sensible naming scheme strikes me as helpful. >> >> It isn't apparent to me that something like poudriere can solve this sort >> of problem either. If poudriere attempts to build lxqt in a single jail >> it looks like the conflict will emerge within the jail. > > The FreeBSD port building servers use poudriere and are not having > a problem. The problem is your messed up environment that already > has the inappropriate mixed that poudriere and the package installers > it makes would never produce. > > The following show lxqt (10 ports have that in their names) as > attempted to be built (not skipped) and all were successful > instead of any failing: It may not be obvious that I looked up builds on ampere2.nyi.freebsd.org because that is the builder for targeting arrch64 main [so: 14] builds. That is why the url's below have: "mastername=main-arm64-default". Thus the evidence includes aarch64 coverage. > Built with python37: > Apr 20: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p338d8ba0f777_s5a89498d19 > Apr 13: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c > Apr 17: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f > > Built with python38: > May 11: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e > May 15: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab > May 18: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c > May 6: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0 > > These imply that all the prerequisite ports for the build > were also built and working for doing so. > >> It'd have to >> split the build between two or more jails and then merge the (compatible) >> executables into a third jail for completion, AIUI. > > No such problems in a correctly configured system. > You are stuck trying to get out of a incorrect > system configuration. > > poudriere ignores your system configuration and uses > its own separate one to do its builds. > >> At this point I'm stuck. > > So you had a poudriere failure? If so, report the details, > such as publishing someplace the log file showing the > failure. Otherwise, you are not stuck. > > Once poudriere has built the packages, you would set up > pkg to use those builds and then force-(re)install all > your ports to use the ones poudriere built. (Not just > lxqt.) This would get all your ports back to being > coherent with each other. > > Presuming a file listing the packages that you want > to be sure are installed (not needing to list > dependencies) and that that pkg has arleady been > redirected to use the poudriere-built packages: > > # pkg delete -a > # pkg install `cat file-listing-packages` > > Technically, I do not know if your environment is so > messed up that pkg delete -a would fail. > > I'll note that if pkg instead still points to the > FreeBSD servers (such as quarterly), the same 2 > command sequence should re-establish those builds. > I started a: # poudriere bulk -j13_0R-CA72 x11-wm/lxqt on one of the aarch64 systems that I have access to (cortex-a72 with 4 cores). It reports (based on prior history of other ports building that might overlap and so avoid some things needing to be built this time): . . . [00:00:25] Building 99 packages using 4 builders . . . [00:00:38] [03] [00:00:00] Building lang/rust | rust-1.52.1 . . . so it looks like it will be hours from when I started it before it will have finished, presuming that rust builds to completion. (Rust takes longer and uses more disk space and the like to build than any llvm* that I normally build.) I
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Wed May 19 16:09:32 UTC 2021 : > On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote: > > > > [portmaster background omitted] > > > If you want to give the attached port a try, it will install LUA and some > > > I tried ports-mgmt/portmaster, it got stuck the same as make. > Unless the new version behaves very differently I'm doubtful it'll > help. > > At the moment it looks like lxqt requires both python37 and python38. > The needs seem to arise at different stages of the build, so perhaps > they can be invoked, used and removed sequentially, but at this point > deleting python37 causes enough collateral damage to make further > progress impossible, or at least non-obvious. > > If the conflict is really limited to merely naming two versions of > /usr/local/bin/easy_install fixing the naming convention seems to be > the obvious answer. I remain baffled why something called "easy_install" > remains essential after installatiion. Unless of course it's not really > an installer. Even so, a more sensible naming scheme strikes me as helpful. > > It isn't apparent to me that something like poudriere can solve this sort > of problem either. If poudriere attempts to build lxqt in a single jail > it looks like the conflict will emerge within the jail. The FreeBSD port building servers use poudriere and are not having a problem. The problem is your messed up environment that already has the inappropriate mixed that poudriere and the package installers it makes would never produce. The following show lxqt (10 ports have that in their names) as attempted to be built (not skipped) and all were successful instead of any failing: Built with python37: Apr 20: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p338d8ba0f777_s5a89498d19 Apr 13: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c Apr 17: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f Built with python38: May 11: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e May 15: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab May 18: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c May 6: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0 These imply that all the prerequisite ports for the build were also built and working for doing so. > It'd have to > split the build between two or more jails and then merge the (compatible) > executables into a third jail for completion, AIUI. No such problems in a correctly configured system. You are stuck trying to get out of a incorrect system configuration. poudriere ignores your system configuration and uses its own separate one to do its builds. > At this point I'm stuck. So you had a poudriere failure? If so, report the details, such as publishing someplace the log file showing the failure. Otherwise, you are not stuck. Once poudriere has built the packages, you would set up pkg to use those builds and then force-(re)install all your ports to use the ones poudriere built. (Not just lxqt.) This would get all your ports back to being coherent with each other. Presuming a file listing the packages that you want to be sure are installed (not needing to list dependencies) and that that pkg has arleady been redirected to use the poudriere-built packages: # pkg delete -a # pkg install `cat file-listing-packages` Technically, I do not know if your environment is so messed up that pkg delete -a would fail. I'll note that if pkg instead still points to the FreeBSD servers (such as quarterly), the same 2 command sequence should re-establish those builds. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: Is there a way to subscribe to the commit messages for only ports you maintain?
On 2021-05-19 03:45, Willem Jan Withagen wrote:
On 18-5-2021 03:56, Chris wrote:
On 2021-05-17 18:17, Julian H. Stacey wrote:
Chris wrote:
On 2021-05-17 16:30, Jan Beich wrote:
> Chris writes:
>
>> I'd like to subscribe to the commit messages
>> ( dev-commits-ports-all )
>> but only receive messages that affect me -- the
>> ports I currently maintain. Is it possible? Or
>> am I just dreaming? ;-)
>
> No clue but I use Herald rules for something similar.
Thanks for the hints, Jan. :-)
Herald ? Nothing from
https://www.freebsd.org/cgi/ports.cgi?query=herald=all=all
...
https://en.wikipedia.org/wiki/Phabricator
...
https://cgit.freebsd.org/ports/tree/devel/phabricator/pkg-descr
I'd use /usr/ports/mail/procmail
https://lists.freebsd.org/pipermail/dev-commits-ports-all/2021-May/date.html
~/.procmailrc example:
:0 H
* ^Sender: owner-dev-commits-ports-...@freebsd.org
{
:0 H
* ^Subject: git: .+ sysutils/rubygem-bolt
| $RCVSTORE +dir_of_ports_you_might_maintain
:0 H
* ^Subject: git: .+ x11/xterm
| $RCVSTORE +another_dir_of_ports_you_might_maintain
}
or eg: # mkdir ~/Mail/your_ports
:0 H
* ^Sender: owner-dev-commits-ports-...@freebsd.org
* ^Subject: git: .+
(archivers/bzip|audio/pocketsphinx|audio/snd|comms/pr|comms/sms_client|databases/pgaccess|devel/c2mdoc|devel/compiz-bcop|devel/ecgi|devel/codeville|devel/frink|dns/dnscheckengine|dns/ldapdns|graphics/gdtclft|graphics/gimmage|graphics/repng2jpeg|graphics/urt|lang/picoc|net/beacon|net/openradius|net/spread|net/wackamole|net-im/mbpurple|sysutils/cdroot|sysutils/ffs2recov|sysutils/rsyncbackup|textproc/asm2html|textproc/smi|textproc/sansi|www/spreadlogd|www/ttf2eot|x11/wmblob|x11/xvt|x11-themes/kde-icons-graphite-rade8|x11-toolkits/iwidgets|x11-wm/icewm)
| $RCVSTORE +your_ports
Wow! Thanks Julian. You even did all my homework for me.! ;-)
In fact I think your re would even satisfy Herald.
Yup, this is a great example.
I had been wining about the same problem in private, but dit not even
realize that
this list is available.
Perhaps this piece of code and suggestion for commits-ports-all could go
into the
porters manual?
+1
I'm on discord. I'll post a comment and see how doc@ feels.
Great suggestion, Willem.
Thanks again for the example, Julian!
--Chris
--WjW
___
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: Error reinstalling python 3.8.10 from ports
On 19/05/2021 19:10, Gleb Popov wrote: Just a guess - are you building with WITH_DEBUG=yes ? Actually, no Xavier -- Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Senior Engineer https://www.amdh.fr ___ 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: Error reinstalling python 3.8.10 from ports
On Wed, May 19, 2021 at 6:55 PM Xavier Humbert wrote: > Hi, > > I got trouble with python 3.8.10 at reinstall stage : > > > ===> Registering installation for python38-3.8.10 > > pkg-static: Unable to access file > > > /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No > > > such file or directory > > pkg-static: Unable to access file > > > /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_bisect.cpython-38.so:No > > > such file or directory > And a bunch of others (the whole lib-dynload directory actually) > > In fact those files are almost present : the are not named eg > _asyncio.cpython-38.so , but asyncio.cpython-38*d*.so > > Where from comes this *d* letter, which is not in pkg-plist ? > Just a guess - are you building with WITH_DEBUG=yes ? ___ 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: port files/patch-*: PREFIX or LOCALBASE
On 2021-05-19 01:42, Nuno Teixeira wrote:
Hello,
I'm working in a port that have several files/patches like:
--- NsCDE/bin/nscde.orig2021-05-02 07:33:53 UTC
+++ NsCDE/bin/nscde
@@ -42,16 +42,11 @@ fi
# Set main NSCDE and FVWM variables. Most of the things later
# depends on this core variables.
export FVWM_USERDIR="${HOME}/.NsCDE"
-export NSCDE_ROOT=/opt/NsCDE
-export FVWM_DATADIR="${NSCDE_ROOT}/config"
+export NSCDE_ROOT=/usr/local
+export FVWM_DATADIR="/usr/local/etc/nscde"
(...)
What is more correct to substitute "/usr/local" as variable?
${PREFIX} or ${LOCALBASE}?
Right or wrong. I've always used ${PREFIX} with great success.
pkg(8) can assist you as well. Have a look at
make -DBATCH makeplist
to see what pkg thinks you mean.
HTH
--Chris
Thanks in advance,
eduardo
___
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 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote: > [portmaster background omitted] > If you want to give the attached port a try, it will install LUA and some I tried ports-mgmt/portmaster, it got stuck the same as make. Unless the new version behaves very differently I'm doubtful it'll help. At the moment it looks like lxqt requires both python37 and python38. The needs seem to arise at different stages of the build, so perhaps they can be invoked, used and removed sequentially, but at this point deleting python37 causes enough collateral damage to make further progress impossible, or at least non-obvious. If the conflict is really limited to merely naming two versions of /usr/local/bin/easy_install fixing the naming convention seems to be the obvious answer. I remain baffled why something called "easy_install" remains essential after installatiion. Unless of course it's not really an installer. Even so, a more sensible naming scheme strikes me as helpful. It isn't apparent to me that something like poudriere can solve this sort of problem either. If poudriere attempts to build lxqt in a single jail it looks like the conflict will emerge within the jail. It'd have to split the build between two or more jails and then merge the (compatible) executables into a third jail for completion, AIUI. At this point I'm stuck. Thanks for reading and your offer of 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: Error reinstalling python 3.8.10 from ports
On 19/05/2021 17:54, Xavier Humbert wrote: Hi, I got trouble with python 3.8.10 at reinstall stage : ===> Registering installation for python38-3.8.10 pkg-static: Unable to access file /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No such file or directory pkg-static: Unable to access file /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_bisect.cpython-38.so:No such file or directory And a bunch of others (the whole lib-dynload directory actually) In fact those files are almost present : the are not named eg _asyncio.cpython-38.so , but asyncio.cpython-38*d*.so Where from comes this *d* letter, which is not in pkg-plist ? A workaround is to edit pkg-plist and add this *d* Xavier -- Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Senior Engineer https://www.amdh.fr ___ 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"
Error reinstalling python 3.8.10 from ports
Hi, I got trouble with python 3.8.10 at reinstall stage : ===> Registering installation for python38-3.8.10 pkg-static: Unable to access file /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No such file or directory pkg-static: Unable to access file /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_bisect.cpython-38.so:No such file or directory And a bunch of others (the whole lib-dynload directory actually) In fact those files are almost present : the are not named eg _asyncio.cpython-38.so , but asyncio.cpython-38*d*.so Where from comes this *d* letter, which is not in pkg-plist ? Cheers, Xavier -- Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Senior Engineer https://www.amdh.fr ___ 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: Is there a way to subscribe to the commit messages for only ports you maintain?
On 18-5-2021 03:56, Chris wrote:
On 2021-05-17 18:17, Julian H. Stacey wrote:
Chris wrote:
On 2021-05-17 16:30, Jan Beich wrote:
> Chris writes:
>
>> I'd like to subscribe to the commit messages
>> ( dev-commits-ports-all )
>> but only receive messages that affect me -- the
>> ports I currently maintain. Is it possible? Or
>> am I just dreaming? ;-)
>
> No clue but I use Herald rules for something similar.
Thanks for the hints, Jan. :-)
Herald ? Nothing from
https://www.freebsd.org/cgi/ports.cgi?query=herald=all=all
...
https://en.wikipedia.org/wiki/Phabricator
...
https://cgit.freebsd.org/ports/tree/devel/phabricator/pkg-descr
I'd use /usr/ports/mail/procmail
https://lists.freebsd.org/pipermail/dev-commits-ports-all/2021-May/date.html
~/.procmailrc example:
:0 H
* ^Sender: owner-dev-commits-ports-...@freebsd.org
{
:0 H
* ^Subject: git: .+ sysutils/rubygem-bolt
| $RCVSTORE +dir_of_ports_you_might_maintain
:0 H
* ^Subject: git: .+ x11/xterm
| $RCVSTORE +another_dir_of_ports_you_might_maintain
}
or eg: # mkdir ~/Mail/your_ports
:0 H
* ^Sender: owner-dev-commits-ports-...@freebsd.org
* ^Subject: git: .+
(archivers/bzip|audio/pocketsphinx|audio/snd|comms/pr|comms/sms_client|databases/pgaccess|devel/c2mdoc|devel/compiz-bcop|devel/ecgi|devel/codeville|devel/frink|dns/dnscheckengine|dns/ldapdns|graphics/gdtclft|graphics/gimmage|graphics/repng2jpeg|graphics/urt|lang/picoc|net/beacon|net/openradius|net/spread|net/wackamole|net-im/mbpurple|sysutils/cdroot|sysutils/ffs2recov|sysutils/rsyncbackup|textproc/asm2html|textproc/smi|textproc/sansi|www/spreadlogd|www/ttf2eot|x11/wmblob|x11/xvt|x11-themes/kde-icons-graphite-rade8|x11-toolkits/iwidgets|x11-wm/icewm)
| $RCVSTORE +your_ports
Wow! Thanks Julian. You even did all my homework for me.! ;-)
In fact I think your re would even satisfy Herald.
Yup, this is a great example.
I had been wining about the same problem in private, but dit not even
realize that this list is available.
Perhaps this piece of code and suggestion for commits-ports-all could go
into the porters manual?
--WjW
___
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: port files/patch-*: PREFIX or LOCALBASE
(...)
# PREFIX- Where *this* port installs its files.
# Default: ${LINUXBASE} if USE_LINUX_PREFIX
is set,
# otherwise ${LOCALBASE}
# LOCALBASE - Where ports install things.
# Default: /usr/local
Nuno Teixeira escreveu no dia quarta, 19/05/2021 à(s)
09:42:
> Hello,
>
> I'm working in a port that have several files/patches like:
>
> --- NsCDE/bin/nscde.orig2021-05-02 07:33:53 UTC
> +++ NsCDE/bin/nscde
> @@ -42,16 +42,11 @@ fi
> # Set main NSCDE and FVWM variables. Most of the things later
> # depends on this core variables.
> export FVWM_USERDIR="${HOME}/.NsCDE"
> -export NSCDE_ROOT=/opt/NsCDE
> -export FVWM_DATADIR="${NSCDE_ROOT}/config"
> +export NSCDE_ROOT=/usr/local
> +export FVWM_DATADIR="/usr/local/etc/nscde"
> (...)
>
> What is more correct to substitute "/usr/local" as variable?
> ${PREFIX} or ${LOCALBASE}?
>
> Thanks in advance,
> eduardo
>
___
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"
port files/patch-*: PREFIX or LOCALBASE
Hello,
I'm working in a port that have several files/patches like:
--- NsCDE/bin/nscde.orig2021-05-02 07:33:53 UTC
+++ NsCDE/bin/nscde
@@ -42,16 +42,11 @@ fi
# Set main NSCDE and FVWM variables. Most of the things later
# depends on this core variables.
export FVWM_USERDIR="${HOME}/.NsCDE"
-export NSCDE_ROOT=/opt/NsCDE
-export FVWM_DATADIR="${NSCDE_ROOT}/config"
+export NSCDE_ROOT=/usr/local
+export FVWM_DATADIR="/usr/local/etc/nscde"
(...)
What is more correct to substitute "/usr/local" as variable?
${PREFIX} or ${LOCALBASE}?
Thanks in advance,
eduardo
___
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"
