Re: qemu-arm-static: bsd-user/arm/target_syscall.h: #define TARGET_HW_MACHINE_ARCH "armv6" // what of armv7?
On 2018-Nov-12, at 20:58, Kyle Evans wrote: > On Mon, Nov 12, 2018 at 10:41 PM Mark Millard wrote: >> >> 11.x: >> o 11.2-STABLE armv6 BANANAPI >> o 11.2-STABLE armv6 BEAGLEBONE >> o 11.2-STABLE armv6 CUBIEBOARD >> o 11.2-STABLE armv6 CUBIEBOARD2 >> o 11.2-STABLE armv6 CUBOX-HUMMINGBOARD >> o 11.2-STABLE armv6 RPI-B >> o 11.2-STABLE armv6 RPI2 >> o 11.2-STABLE armv6 PANDABOARD >> o 11.2-STABLE armv6 WANDBOARD >> >> 12.x+ (I got the list from a 13.0 snapshot announcement): >> o 13.0-CURRENT armv6 RPI-B >> o 13.0-CURRENT armv7 BANANAPI >> o 13.0-CURRENT armv7 BEAGLEBONE >> o 13.0-CURRENT armv7 CUBIEBOARD >> o 13.0-CURRENT armv7 CUBIEBOARD2 >> o 13.0-CURRENT armv7 CUBOX-HUMMINGBOARD >> o 13.0-CURRENT armv7 RPI2 >> o 13.0-CURRENT armv7 PANDABOARD >> o 13.0-CURRENT armv7 WANDBOARD >> o 13.0-CURRENT armv7 GENERICSD >> >> So as of 12.x+ most are armv7 --as are most new ones >> expected to be. >> >> As stands, in my amd64 -> armv7 13.0 cross-build activity, >> uname -p and the like under the chroot context are >> returning armv6 instead of armv7 unless I override via >> a UNAME_p definition. >> >> This appears to trace back to: bsd-user/arm/target_syscall.h >> and its: >> >> #define TARGET_HW_MACHINE "arm" >> #define TARGET_HW_MACHINE_ARCH "armv6" >> >> and lack context sensitivity, such as to the FreeBSD version >> that it is in use under. >> > > Indeed, I opened this a couple of hours ago: > https://github.com/seanbruno/qemu-bsd-user/pull/70 -- It turns out > this is basically wrong, though I'm not sure immediately how to > rectify. I don't think we can reasonably decide at compile-time what > this should look like since all 32-bit ARM are shoved into this one > target, so perhaps the right answer is that armv6 and armv7 need to > split off from arm.arm and we use a check like the one in the above > PR. CC'ing imp for a wisdom drop. Looks like poudriere-devel is defining UNAME_p and UNAME_m to cause the right results for its port 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: qemu-arm-static: bsd-user/arm/target_syscall.h: #define TARGET_HW_MACHINE_ARCH "armv6" // what of armv7?
On Mon, Nov 12, 2018 at 10:41 PM Mark Millard wrote: > > 11.x: > o 11.2-STABLE armv6 BANANAPI > o 11.2-STABLE armv6 BEAGLEBONE > o 11.2-STABLE armv6 CUBIEBOARD > o 11.2-STABLE armv6 CUBIEBOARD2 > o 11.2-STABLE armv6 CUBOX-HUMMINGBOARD > o 11.2-STABLE armv6 RPI-B > o 11.2-STABLE armv6 RPI2 > o 11.2-STABLE armv6 PANDABOARD > o 11.2-STABLE armv6 WANDBOARD > > 12.x+ (I got the list from a 13.0 snapshot announcement): > o 13.0-CURRENT armv6 RPI-B > o 13.0-CURRENT armv7 BANANAPI > o 13.0-CURRENT armv7 BEAGLEBONE > o 13.0-CURRENT armv7 CUBIEBOARD > o 13.0-CURRENT armv7 CUBIEBOARD2 > o 13.0-CURRENT armv7 CUBOX-HUMMINGBOARD > o 13.0-CURRENT armv7 RPI2 > o 13.0-CURRENT armv7 PANDABOARD > o 13.0-CURRENT armv7 WANDBOARD > o 13.0-CURRENT armv7 GENERICSD > > So as of 12.x+ most are armv7 --as are most new ones > expected to be. > > As stands, in my amd64 -> armv7 13.0 cross-build activity, > uname -p and the like under the chroot context are > returning armv6 instead of armv7 unless I override via > a UNAME_p definition. > > This appears to trace back to: bsd-user/arm/target_syscall.h > and its: > > #define TARGET_HW_MACHINE "arm" > #define TARGET_HW_MACHINE_ARCH "armv6" > > and lack context sensitivity, such as to the FreeBSD version > that it is in use under. > Indeed, I opened this a couple of hours ago: https://github.com/seanbruno/qemu-bsd-user/pull/70 -- It turns out this is basically wrong, though I'm not sure immediately how to rectify. I don't think we can reasonably decide at compile-time what this should look like since all 32-bit ARM are shoved into this one target, so perhaps the right answer is that armv6 and armv7 need to split off from arm.arm and we use a check like the one in the above PR. CC'ing imp for a wisdom drop. ___ 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"
qemu-arm-static: bsd-user/arm/target_syscall.h: #define TARGET_HW_MACHINE_ARCH "armv6" // what of armv7?
11.x:
o 11.2-STABLE armv6 BANANAPI
o 11.2-STABLE armv6 BEAGLEBONE
o 11.2-STABLE armv6 CUBIEBOARD
o 11.2-STABLE armv6 CUBIEBOARD2
o 11.2-STABLE armv6 CUBOX-HUMMINGBOARD
o 11.2-STABLE armv6 RPI-B
o 11.2-STABLE armv6 RPI2
o 11.2-STABLE armv6 PANDABOARD
o 11.2-STABLE armv6 WANDBOARD
12.x+ (I got the list from a 13.0 snapshot announcement):
o 13.0-CURRENT armv6 RPI-B
o 13.0-CURRENT armv7 BANANAPI
o 13.0-CURRENT armv7 BEAGLEBONE
o 13.0-CURRENT armv7 CUBIEBOARD
o 13.0-CURRENT armv7 CUBIEBOARD2
o 13.0-CURRENT armv7 CUBOX-HUMMINGBOARD
o 13.0-CURRENT armv7 RPI2
o 13.0-CURRENT armv7 PANDABOARD
o 13.0-CURRENT armv7 WANDBOARD
o 13.0-CURRENT armv7 GENERICSD
So as of 12.x+ most are armv7 --as are most new ones
expected to be.
As stands, in my amd64 -> armv7 13.0 cross-build activity,
uname -p and the like under the chroot context are
returning armv6 instead of armv7 unless I override via
a UNAME_p definition.
This appears to trace back to: bsd-user/arm/target_syscall.h
and its:
#define TARGET_HW_MACHINE "arm"
#define TARGET_HW_MACHINE_ARCH "armv6"
and lack context sensitivity, such as to the FreeBSD version
that it is in use under.
So it seems that most 12.x+ use needs to define UNAME_p to
actually have armv7 in uname output and the like.
I noticed this by trying a armv7 buildworld under a
chroot and it reported:
make[1]: "/usr/src/Makefile.inc1" line 577: To cross-build, set TARGET_ARCH.
This was because of Makefile.inc1 and its:
.if make(buildworld)
BUILD_ARCH!=uname -p
.if ${MACHINE_ARCH} != ${BUILD_ARCH}
.error To cross-build, set TARGET_ARCH.
.endif
.endif
in which it compared armv7 != armv6 and
stopped the build. As it sees things under
qemu-arm-static, only armv6 is a native
buildworld, the rest are cross-builds.
Ports could be choosing inappropriately based on
armv6 being reported in/for armv7 contexts.
Should ports normally see armv6 instead of armv7 on
FreeBSD 12.x+ for some reason? Or would this better be
changed to armv7 as the default for such contexts?
Should documentation report on the issue and how
to handle it when the default is inappropriate?
===
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: sendmail from ports + blacklistd - no further luck?,Re: sendmail from ports + blacklistd - no further luck?
>> define(`confUSE_BLACKLIST', `true’) >> >> in .mc. I'll give that a try, thanks. > > Ok, that doesn't do anything to the .cf file, so I have now inserted the > definition into sendmail.cf directly (which is uncool since my . cf > files are generated automatically). We'll see. If you don't want to edit sendmail.cf directly, you can specify the '-O UseBlacklist' flag for sendmail command argument. i.e. add 'sendmail_flags="-L sm-mta -bd -q30m -O UseBlacklist"' to the /etc/rc.conf and do /etc/rc.d/sendmail restart. -- Masachika ISHIZUKA ___ 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: pkg falls behind port version - how do ports become pkg's?
--On 12 November 2018 at 16:20:52 + Matthew Seaman wrote: Hi - thanks for your reply, and detailed info on ports / pkg behind the scenes! If it's 'quarterly' (which is the default) then you'll not get an update until the beginning of the next quarter -- which would be the start of January 2019. The exception to this is when there's a security fix for the package in question, which should appear within a day or so. Ok - all the systems here are on quarterly. I've just switched one to 'latest' - and, indeed - mysql56-server pkg installed is 5.6.42 - which appears to address the 30+ CVE's that 5.6.41 has tagged against it. Nope. Official packages are built on the official package building cluster. I'd guess that's the mythical Poudriere? ;) The certainly aren't built by random port maintainers who may be of particularly uncertain provenance and are not absolutely guaranteed to have your best interests at heart.[*] From what I can see mysql56-server in quarterly really does need updating to fix the CVE's - so who am I best emailing to ask if mysql56-server/client could be updated on security grounds? Thanks again, -Karl ___ 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: FreeBSD 11.2-RELEASE (64bit) databases/mariadb103-server
On 2018-11-12 19:13, Leander Schäfer wrote: Hello, databases/mariadb103-server doesn't want to build any more. I use poudriere to build own local package repositories. It seems like one of the two last updates broke databases/mariadb103-server port for me: - 12 Nov 2018 16:58:52 or - 10 Nov 2018 14:11:46 https://www.freshports.org/databases/mariadb103-server/ My make.conf looks like this: DEFAULT_VERSIONS+=php=71 DEFAULT_VERSIONS+=pgsql=9.6 DEFAULT_VERSIONS+=mysql=8.0 DEFAULT_VERSIONS+=samba=4.8 DEFAULT_VERSIONS+=python=2.7 python2=2.7 python3=3.6 DEFAULT_VERSIONS+=ssl=openssl The options of databases/mariadb103-server are left default except GSSAPI_NONE. OPTIONS_FILE_SET+=CONNECT_EXTRA OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=WSREP OPTIONS_FILE_UNSET+=LZ4 OPTIONS_FILE_UNSET+=LZO OPTIONS_FILE_UNSET+=SNAPPY OPTIONS_FILE_UNSET+=ZSTD OPTIONS_FILE_SET+=INNOBASE OPTIONS_FILE_UNSET+=MROONGA OPTIONS_FILE_UNSET+=OQGRAPH OPTIONS_FILE_UNSET+=ROCKSDB OPTIONS_FILE_SET+=SPHINX OPTIONS_FILE_SET+=SPIDER OPTIONS_FILE_UNSET+=TOKUDB OPTIONS_FILE_UNSET+=ZMQ OPTIONS_FILE_UNSET+=MSGPACK OPTIONS_FILE_UNSET+=GSSAPI_BASE OPTIONS_FILE_UNSET+=GSSAPI_HEIMDAL OPTIONS_FILE_UNSET+=GSSAPI_MIT OPTIONS_FILE_SET+=GSSAPI_NONE [...] --- storage/connect/CMakeFiles/connect.dir/all --- [ 87%] Building CXX object storage/connect/CMakeFiles/connect.dir/ha_connect.cc.o cd /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/storage/connect && /usr/local/libexec/ccache/c++ -DFORCE_INIT_OF_VARS -DGZ_SUPPORT -DHAVE_CONFIG_H -DHUGE_SUPPORT -DLIBXML2_SUPPORT -DLINUX -DMARIADB -DMYSQL_DYNAMIC_PLUGIN -DNOCRYPT -DODBC_SUPPORT -DUBUNTU -DUNIX -DVCT_SUPPORT -DXMAP -DZIP_SUPPORT -Dconnect_EXPORTS -I/wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/include -I/wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/sql -I/wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/pcre -I/usr/local/include -I/usr/local/include/libxml2 -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -Wl,-z,relro,-z,now -fstack-protector --param=ssp-buffer-size=4 -fno-rtti -Wall -Wmissing-declarations -Wno-unused-function -Wno-unused-variable -Wno-unused-value -Wno-parentheses -Wno-strict-aliasing -Wno-implicit-fallthrough -fpermissive -fexceptions -fPIC -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -D_FORTIFY_SOURCE=2 -DDBUG_OFF -fPIC -o CMakeFiles/connect.dir/ha_connect.cc.o -c /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/storage/connect/ha_connect.cc --- extra/mariabackup/CMakeFiles/mariabackup.dir/all --- /usr/bin/ld: mariabackup: hidden symbol `_Z31fil_space_verify_crypt_checksumPhRK11page_size_tmm' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [extra/mariabackup/mariabackup] Error code 1 make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 1 error make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 *** [extra/mariabackup/CMakeFiles/mariabackup.dir/all] Error code 2 make[2]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 --- storage/innobase/CMakeFiles/innobase.dir/all --- Scanning dependencies of target innobase A failure has been detected in another branch of the parallel make make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 *** [storage/innobase/CMakeFiles/innobase.dir/all] Error code 2 make[2]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 --- plugin/metadata_lock_info/CMakeFiles/metadata_lock_info.dir/all --- c++: warning: -Wl,-z,relro,-z,now: 'linker' input unused [-Wunused-command-line-argument] --- storage/blackhole/CMakeFiles/blackhole.dir/all --- c++: warning: -Wl,-z,relro,-z,now: 'linker' input unused [-Wunused-command-line-argument] --- storage/federatedx/CMakeFiles/federatedx.dir/all --- c++: warning: -Wl,-z,relro,-z,now: 'linker' input unused [-Wunused-command-line-argument] --- storage/test_sql_discovery/CMakeFiles/test_sql_discovery.dir/all --- A failure has been detected in another branch of the parallel make make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 *** [storage/test_sql_discovery/CMakeFiles/test_sql_discovery.dir/all] Error code 2 make[2]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 --- plugin/qc_info/CMakeFiles/query_cache_info.dir/all --- A failure has been detected in another branch of the parallel make make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 --- storage/spider/CMakeFiles/spider.dir/all --- c++: warning: -Wl,-z,relro,-z,now: 'linker' input unused [-Wunused-command-line-argument] --- plugin/qc_info/CMakeFiles/query_cache_info.dir
Re: FYI: ports head -r484783 poudriere-devel with qemu-arm-static: sometimes hangs between a cc (wait) and its child ld (uwait)
On 2018-Nov-12, at 05:54, Kyle Evans wrote: > On Sun, Nov 11, 2018 at 9:11 PM Mark Millard wrote: >> >> [I still can not produce the problem below on demand. >> It seems racy with no fixed context producing the >> problem as far as which port is building. But the >> general structure of what hangs is the same each >> time so far.] >> >> The following is just an FYI for the other >> qemu-arm-static tied problem that I regularly run into. >> I do not have much useful information so far. It is >> not clear how I'd get such information. >> > > Hi, > > Just so we're clear- in what kind of time frame did you start > observing this hang? Unfortunately, I did no qemu-user-static use after 2018-Feb-6 until 2018-10-26. My list activity reported the problem for the first time on Oct. 26 and I had updated before using qemu-arm-static on the 26th. Looks like back on Feb. 6 I was using: qemu-user-static-2.11.50.g20171215_3 Looks like back on Oct. 26 I was using: qemu-user-static-2.11.50.g20180622_1 I'm now using qemu-user-static-2.11.50.g20181011 . For reference: The Feb cross build logs for Feb 6 show things like: =>> Building ports-mgmt/poudriere-devel build started at Tue Feb 6 17:39:36 PST 2018 port directory: /usr/ports/ports-mgmt/poudriere-devel package name: poudriere-devel-3.2.99.20180202_2 building for: FreeBSD FBSDFSSDjailVariant 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M arm maintained by: bdrew...@freebsd.org Makefile ident: $FreeBSD: head/ports-mgmt/poudriere-devel/Makefile 461075 2018-02-06 16:33:15Z brd $ Poudriere version: 3.2.99.20180202_2 Host OSVERSION: 1200054 Jail OSVERSION: 1200054 The amd64 (host) logs before that show for qemu-user-static: =>> Building emulators/qemu-user-static build started at Sun Feb 4 11:22:59 PST 2018 port directory: /usr/ports/emulators/qemu-user-static package name: qemu-user-static-2.11.50.g20171215_3 building for: FreeBSD FBSDFSSDjailVariant 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M amd64 maintained by: sbr...@freebsd.org Makefile ident: $FreeBSD: head/emulators/qemu-user-static/Makefile 441455 2017-05-22 13:17:38Z linimon $ Poudriere version: 3.2.99.20180202_1 Host OSVERSION: 1200054 Jail OSVERSION: 1200054 (I normally keep the system source code the same across TARGET_ARCH's, with some exceptions for powerpc families.) Oct. 26 shows for qemu-user-static: =>> Building emulators/qemu-user-static build started at Fri Oct 26 13:55:50 PDT 2018 port directory: /usr/ports/emulators/qemu-user-static package name: qemu-user-static-2.11.50.g20180622_1 building for: FreeBSD FBSDFSSDjailVariant 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #1 r339076:339432M: Mon Oct 22 17:48:28 PDT 2018 markmi@FBSDFSSD:/usr/obj/amd64_clang_alt/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG amd64 maintained by: sbr...@freebsd.org Makefile ident: $FreeBSD: head/emulators/qemu-user-static/Makefile 441455 2017-05-22 13:17:38Z linimon $ Poudriere version: 3.2.99.20180511 Host OSVERSION: 1200084 Jail OSVERSION: 1200063 The armv7 jail context would also be based on the same system source, mostly -r339076 source. Currently for qemu-user-static I'm at: =>> Building emulators/qemu-user-static build started at Sun Nov 11 14:52:52 PST 2018 port directory: /usr/ports/emulators/qemu-user-static package name: qemu-user-static-2.11.50.g20181011 building for: FreeBSD FBSDFSSDjailVariant 13.0-CURRENT FreeBSD 13.0-CURRENT amd64 maintained by: sbr...@freebsd.org Makefile ident: $FreeBSD: head/emulators/qemu-user-static/Makefile 441455 2017-05-22 13:17:38Z linimon $ Poudriere version: 3.2.99.20181024 Host OSVERSION: 133 Jail OSVERSION: 133 === 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: FreeBSD 11.2-RELEASE (64bit) databases/mariadb103-server
I am not clear if it is the same error as in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233135 If it is, it is fixed few moments ago with https://svnweb.freebsd.org/ports?view=revision&revision=484810 ___ 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 11.2-RELEASE (64bit) databases/mariadb103-server
Hello, databases/mariadb103-server doesn't want to build any more. I use poudriere to build own local package repositories. It seems like one of the two last updates broke databases/mariadb103-server port for me: - 12 Nov 2018 16:58:52 or - 10 Nov 2018 14:11:46 https://www.freshports.org/databases/mariadb103-server/ My make.conf looks like this: DEFAULT_VERSIONS+=php=71 DEFAULT_VERSIONS+=pgsql=9.6 DEFAULT_VERSIONS+=mysql=8.0 DEFAULT_VERSIONS+=samba=4.8 DEFAULT_VERSIONS+=python=2.7 python2=2.7 python3=3.6 DEFAULT_VERSIONS+=ssl=openssl The options of databases/mariadb103-server are left default except GSSAPI_NONE. OPTIONS_FILE_SET+=CONNECT_EXTRA OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=WSREP OPTIONS_FILE_UNSET+=LZ4 OPTIONS_FILE_UNSET+=LZO OPTIONS_FILE_UNSET+=SNAPPY OPTIONS_FILE_UNSET+=ZSTD OPTIONS_FILE_SET+=INNOBASE OPTIONS_FILE_UNSET+=MROONGA OPTIONS_FILE_UNSET+=OQGRAPH OPTIONS_FILE_UNSET+=ROCKSDB OPTIONS_FILE_SET+=SPHINX OPTIONS_FILE_SET+=SPIDER OPTIONS_FILE_UNSET+=TOKUDB OPTIONS_FILE_UNSET+=ZMQ OPTIONS_FILE_UNSET+=MSGPACK OPTIONS_FILE_UNSET+=GSSAPI_BASE OPTIONS_FILE_UNSET+=GSSAPI_HEIMDAL OPTIONS_FILE_UNSET+=GSSAPI_MIT OPTIONS_FILE_SET+=GSSAPI_NONE [...] --- storage/connect/CMakeFiles/connect.dir/all --- [ 87%] Building CXX object storage/connect/CMakeFiles/connect.dir/ha_connect.cc.o cd /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/storage/connect && /usr/local/libexec/ccache/c++ -DFORCE_INIT_OF_VARS -DGZ_SUPPORT -DHAVE_CONFIG_H -DHUGE_SUPPORT -DLIBXML2_SUPPORT -DLINUX -DMARIADB -DMYSQL_DYNAMIC_PLUGIN -DNOCRYPT -DODBC_SUPPORT -DUBUNTU -DUNIX -DVCT_SUPPORT -DXMAP -DZIP_SUPPORT -Dconnect_EXPORTS -I/wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/include -I/wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/sql -I/wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/pcre -I/usr/local/include -I/usr/local/include/libxml2 -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -Wl,-z,relro,-z,now -fstack-protector --param=ssp-buffer-size=4 -fno-rtti -Wall -Wmissing-declarations -Wno-unused-function -Wno-unused-variable -Wno-unused-value -Wno-parentheses -Wno-strict-aliasing -Wno-implicit-fallthrough -fpermissive -fexceptions -fPIC -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -D_FORTIFY_SOURCE=2 -DDBUG_OFF -fPIC -o CMakeFiles/connect.dir/ha_connect.cc.o -c /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10/storage/connect/ha_connect.cc --- extra/mariabackup/CMakeFiles/mariabackup.dir/all --- /usr/bin/ld: mariabackup: hidden symbol `_Z31fil_space_verify_crypt_checksumPhRK11page_size_tmm' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [extra/mariabackup/mariabackup] Error code 1 make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 1 error make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 *** [extra/mariabackup/CMakeFiles/mariabackup.dir/all] Error code 2 make[2]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 --- storage/innobase/CMakeFiles/innobase.dir/all --- Scanning dependencies of target innobase A failure has been detected in another branch of the parallel make make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 *** [storage/innobase/CMakeFiles/innobase.dir/all] Error code 2 make[2]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 --- plugin/metadata_lock_info/CMakeFiles/metadata_lock_info.dir/all --- c++: warning: -Wl,-z,relro,-z,now: 'linker' input unused [-Wunused-command-line-argument] --- storage/blackhole/CMakeFiles/blackhole.dir/all --- c++: warning: -Wl,-z,relro,-z,now: 'linker' input unused [-Wunused-command-line-argument] --- storage/federatedx/CMakeFiles/federatedx.dir/all --- c++: warning: -Wl,-z,relro,-z,now: 'linker' input unused [-Wunused-command-line-argument] --- storage/test_sql_discovery/CMakeFiles/test_sql_discovery.dir/all --- A failure has been detected in another branch of the parallel make make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 *** [storage/test_sql_discovery/CMakeFiles/test_sql_discovery.dir/all] Error code 2 make[2]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 --- plugin/qc_info/CMakeFiles/query_cache_info.dir/all --- A failure has been detected in another branch of the parallel make make[3]: stopped in /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.10 --- storage/spider/CMakeFiles/spider.dir/all --- c++: warning: -Wl,-z,relro,-z,now: 'linker' input unused [-Wunused-command-line-argument] --- plugin/qc_info/CMakeFiles/query_cache_info.dir/all --- *** [plugin/qc_info/CMakeFiles/query_ca
Re: Problem with VBox-ose 5.2.20 and 5.2.22
On 18. 11. 10., Nilton Jose Rizzo wrote: > Problem with compiling VirtualBox-ose 5.2.22 > > > @cc -c -O2 -g -pipe -O2 -mtune=generic -fno-omit-frame-pointer > -fno-strict-aliasing -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN > -DRT_USE_VISIBILITY_DEFAULT -fPIC -Wno-sign-compare > -Werror-implicit-function-declaration -m64 > -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/src/recompiler/Sun/crt > -I/usr/ualBox-5.2.22/src/recompiler/exec.c > kBuild: Compiling VBoxRemPrimary - > /usr/ports/emulators/virtualbox-ose/work/Virt > ualBox-5.2.22/src/recompiler/translate-all.c > In file included from > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22 > /src/recompiler/cpu-exec.c:30: > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/src/recompiler/target > -i386/exec.h:41:38: error: > register 'r14' unsuitable for global register variables on this target > register struct CPUX86State *env asm(AREG0); > ^ > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/src/recompiler/dyngen > -exec.h:81:15: note: > expanded from macro 'AREG0' > #define AREG0 "r14" > ^ > kBuild: Compiling VBoxRemPrimary - > /usr/ports/emulators/virtualbox-ose/work/Virt > ualBox-5.2.22/src/recompiler/host-utils.c > > > My box: > > root@valfenda:/usr/ports/emulators/virtualbox-ose # uname -a > FreeBSD valfenda 13.0-CURRENT FreeBSD 13.0-CURRENT r340249 VALFENDA amd64 > root@valfenda:/usr/ports/emulators/virtualbox-ose # > > root@valfenda:/usr/ports/emulators/virtualbox-ose # svnlite info . > Path: . > Working Copy Root Path: /usr/ports > URL: svn://svn.freebsd.org/ports/head/emulators/virtualbox-ose > Relative URL: ^/head/emulators/virtualbox-ose > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 484572 > Node Kind: directory > Schedule: normal > Last Changed Author: jkim > Last Changed Rev: 484559 > Last Changed Date: 2018-11-09 21:54:01 -0200 (sex, 09 nov 2018) Probably devel/kBuild was built *without* GCC option. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: pkg falls behind port version - how do ports become pkg's?
On 12/11/2018 14:58, Karl Pielorz wrote: How long does it usually take for an updated port (e.g. mysql56-server which in ports is at 5.6.42) to be available as a pkg? (pkg under FBSD 11.2 is currently 5.6.41). Which branch are you trcking in your pkg(8) config? If it's 'latest', then you'll get the updated mysql after about 1-3 days assuming there aren't any problems with that port of any of its dependencies. If it's 'quarterly' (which is the default) then you'll not get an update until the beginning of the next quarter -- which would be the start of January 2019. The exception to this is when there's a security fix for the package in question, which should appear within a day or so. Use 'pkg -vv' to examine your config settings, particularly the 'url' field under 'Repositories' towards the end of that output. I had previously thought all of this was mostly automated behind-the-scenes "magic" kind of stuff - but four weeks after the MySQL port was updated the pkg isn't yet :( - so I'm guessing it's not really that magic, and does involve human time & effort? :) No, packages are automatically built, and usually show up within a few days. It involves human time and effort when things go wrong, but that's primarily from the maintainers of the ports in question, and not usually the pkg-builder admins. Are ports turned into pkg's by the maintainers? - Is it done as-and-when - or is there some kind of 'every x days / once per quarter' kind of thing? Nope. Official packages are built on the official package building cluster. The certainly aren't built by random port maintainers who may be of particularly uncertain provenance and are not absolutely guaranteed to have your best interests at heart.[*] Cheers, Matthew [*] The requirements for becoming a port maintainer are no more stringent than: * Having a working e-mail address * Expressing a willingness to maintain a port * Being able to generate a diff and attach it to a Bugzilla ticket. It's down to ports committers to verify that there's nothing untoward about what they commit to the ports. The requirements on authenticating/identifying yourself when becoming a ports committer are rather stricter than for a port maintainer. ___ 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"
pkg falls behind port version - how do ports become pkg's?
Hi All, How long does it usually take for an updated port (e.g. mysql56-server which in ports is at 5.6.42) to be available as a pkg? (pkg under FBSD 11.2 is currently 5.6.41). I had previously thought all of this was mostly automated behind-the-scenes "magic" kind of stuff - but four weeks after the MySQL port was updated the pkg isn't yet :( - so I'm guessing it's not really that magic, and does involve human time & effort? :) Are ports turned into pkg's by the maintainers? - Is it done as-and-when - or is there some kind of 'every x days / once per quarter' kind of thing? Thanks, -Karl ___ 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: Broken port qmail-tls, upstream dead
Hi!
> On 12.11.18 07:20, Kurt Jaeger wrote:
>
> > Which feature breaks ?
>
> Relaying after auth with client certs. The patch manually resets
> openssl's ssl context state to trigger a second handshake after reneg
> and those fields are now opaque in openssl.
>
> > Patches can be applied conditionally (e.g. only for 12).
> > If you provide the patch in a way that fixes the build only for 12 ?
>
> Any pointers for that?
Put the 12er patch into files/extra-patch-fbsd12
and add this to the Makefile:
.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 120
EXTRA_PATCHES=extra-patch-fbsd12
.endif
> > Migrate to exim 8-) ? If upstream is dead, maybe it's a signal
> > to migrate away ?
> Well netqmail is well and kicking, it's just that the tls implementation
> is a little rough arund the edges and needs some brushing ;)
Yes, I would not want to migrate, either 8-)
--
p...@opsec.eu+49 171 31013722 years 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: FYI: ports head -r484783 poudriere-devel with qemu-arm-static: sometimes hangs between a cc (wait) and its child ld (uwait)
On Sun, Nov 11, 2018 at 9:11 PM Mark Millard wrote: > > [I still can not produce the problem below on demand. > It seems racy with no fixed context producing the > problem as far as which port is building. But the > general structure of what hangs is the same each > time so far.] > > The following is just an FYI for the other > qemu-arm-static tied problem that I regularly run into. > I do not have much useful information so far. It is > not clear how I'd get such information. > Hi, Just so we're clear- in what kind of time frame did you start observing this hang? Thanks, Kyle Evans ___ 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: Broken port qmail-tls, upstream dead
On 12.11.18 07:20, Kurt Jaeger wrote: > Which feature breaks ? Relaying after auth with client certs. The patch manually resets openssl's ssl context state to trigger a second handshake after reneg and those fields are now opaque in openssl. > Patches can be applied conditionally (e.g. only for 12). > If you provide the patch in a way that fixes the build only for 12 ? Any pointers for that? > Migrate to exim 8-) ? If upstream is dead, maybe it's a signal > to migrate away ? Well netqmail is well and kicking, it's just that the tls implementation is a little rough arund the edges and needs some brushing ;) erdgeist ___ 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: sendmail from ports + blacklistd - no further luck?,Re: sendmail from ports + blacklistd - no further luck?
>>> Can someone confirm (or disprove) that the current version of Sendmail >>> from ports (8.15.2_5), explicitly compiled with the blacklistd flag, has >>> stopped feeding offending IPs (e.g. those failing do_auth) to blacklistd >>> since Jan 3? >> Hello. >> >> I used sendmail+tls+sasl2-8.15.2_3 for a long time. >> That works fine. >> >> Recently, I upgrade to sendmail-8.15.2_13 and this is not working >> without UseBlacklist option in sendmail.cf. >> I think you must add 'O UseBlacklist=True' in your sendmail.cf. > > Interesting. Can you tell me how you found that information? It is not > listed in cf/README (neither port nor base). I'm assuming it's > > define(`confUSE_BLACKLIST', `true’) > > in .mc. I'll give that a try, thanks. I found by 'man 8 sendmail' and /UseBlacklist. I think this change was done after https://reviews.freebsd.org/D13475. -- Masachika ISHIZUKA ___ 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: sendmail from ports + blacklistd - no further luck?
On 12-11-2018 11:56, Dutch Daemon - FreeBSD Forums Administrator wrote: > define(`confUSE_BLACKLIST', `true’) > > in .mc. I'll give that a try, thanks. Ok, that doesn't do anything to the .cf file, so I have now inserted the definition into sendmail.cf directly (which is uncool since my . cf files are generated automatically). We'll see. signature.asc Description: OpenPGP digital signature
Re: sendmail from ports + blacklistd - no further luck?
On 12-11-2018 11:51, Dutch Daemon - FreeBSD Forums Administrator wrote: > On 12-11-2018 11:22, Masachika ISHIZUKA wrote: > >>> Can someone confirm (or disprove) that the current version of Sendmail >>> from ports (8.15.2_5), explicitly compiled with the blacklistd flag, has >>> stopped feeding offending IPs (e.g. those failing do_auth) to blacklistd >>> since Jan 3? >> Hello. >> >> I used sendmail+tls+sasl2-8.15.2_3 for a long time. >> That works fine. >> >> Recently, I upgrade to sendmail-8.15.2_13 and this is not working >> without UseBlacklist option in sendmail.cf. >> I think you must add 'O UseBlacklist=True' in your sendmail.cf. > Interesting. Can you tell me how you found that information? It is not > listed in cf/README (neither port nor base). I'm assuming it's > > define(`confUSE_BLACKLIST', `true’) > > in .mc. I'll give that a try, thanks. > BTW, this has been in my .mc ever since blacklistd was ported: define(`conf_sendmail_ENVDEF', `-DUSE_BLACKLIST') define(`conf_sendmail_LIBS', `-lblacklist') but it just stopped working. signature.asc Description: OpenPGP digital signature
Re: sendmail from ports + blacklistd - no further luck?
On 12-11-2018 11:22, Masachika ISHIZUKA wrote: >> Can someone confirm (or disprove) that the current version of Sendmail >> from ports (8.15.2_5), explicitly compiled with the blacklistd flag, has >> stopped feeding offending IPs (e.g. those failing do_auth) to blacklistd >> since Jan 3? > Hello. > > I used sendmail+tls+sasl2-8.15.2_3 for a long time. > That works fine. > > Recently, I upgrade to sendmail-8.15.2_13 and this is not working > without UseBlacklist option in sendmail.cf. > I think you must add 'O UseBlacklist=True' in your sendmail.cf. Interesting. Can you tell me how you found that information? It is not listed in cf/README (neither port nor base). I'm assuming it's define(`confUSE_BLACKLIST', `true’) in .mc. I'll give that a try, thanks. signature.asc Description: OpenPGP digital signature
Re: sendmail from ports + blacklistd - no further luck?
> Can someone confirm (or disprove) that the current version of Sendmail > from ports (8.15.2_5), explicitly compiled with the blacklistd flag, has > stopped feeding offending IPs (e.g. those failing do_auth) to blacklistd > since Jan 3? Hello. I used sendmail+tls+sasl2-8.15.2_3 for a long time. That works fine. Recently, I upgrade to sendmail-8.15.2_13 and this is not working without UseBlacklist option in sendmail.cf. I think you must add 'O UseBlacklist=True' in your sendmail.cf. -- Masachika ISHIZUKA ___ 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: sendmail blacklistd on 12.0
> I'm using ports/mail/sendmail with blacklistd. > > In 11.2R, it is working good without UseBlacklist option in > sendmail.cf. > After upgrading from 11.2R to 12.0-BETA[34], blacklistd for > sendmail is not working without UseBlacklist option in sendmail.cf. > > Is there any change of behavior of APPENDDEF(`conf_sendmail_ENVDEF', > `-DUSE_BLACKLIST') in files/site.config.m4.blacklistd between > 11.2R and 12.0-BETAs ? Sorry. It seems that is not behavior of 11.2R and 12.0-BETAs. I found the following mail. | Subject: sendmail from ports + blacklistd - no further luck? | From: freebsd-po...@bengrimm.net | To: freebsd-ports@freebsd.org | Date: Tue, 16 Jan 2018 19:20:59 +0100 | | Can someone confirm (or disprove) that the current version of Sendmail | from ports (8.15.2_5), explicitly compiled with the blacklistd flag, has | stopped feeding offending IPs (e.g. those failing do_auth) to blacklistd | since Jan 3? I used sendmail+tls+sasl2-8.15.2_3 on 11.2R and this worked without UseBlacklist option. Then I upgraded to 12.0-BETA3 and sendmail-8.15.2_12 that is not working without UseBlacklist option. -- Masachika ISHIZUKA ___ 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"
