I want to maintain security/pssh
Hello, I'd like to take maintainership of security/pssh if no objections ___ 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: I want to maintain security/pssh
Hi, Please submit a patch with some improvements of the current port and resetting the MAINTAINERSHIP to your email address in our bugzilla. Kind Regards, Moin > On 23 Jul, 2020, at 14:25, Pavel Timofeev wrote: > > Hello, I'd like to take maintainership of security/pssh if no objections > ___ > 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" signature.asc Description: Message signed with OpenPGP
Re: Why lang/gcc9 depends native-binutils ?
> The GNU Binutils are a collection of binary tools. The main ones are: > * ld - the GNU linker. > * as - the GNU assembler. > Most of these programs use BFD, the Binary File Descriptor library, to do > low-level manipulation. Many of them also use the opcodes library to assemble > and disassemble machine instructions. > This port may be used as a replacement for the system binutils and support > features from the latest versions of GCC. > For cross-compilation, see the devel/cross-binutils port. > WWW: https://www.gnu.org/software/binutils/ > Mark Millard This prompted me to run "svn up" on FreeBSD ports tree. But I found no devel/cross-binutils, you had my hopes up. There is a cross/cross-binutils in (NetBSD) pkgsrc. DESCR shows The cross-binutils pkg is used only by the other `cross' pkgs. The binutils provides various binary manipulation utilities as well as the GNU linker. (The assembler is bundled with each individual cross pkg.) Tom ___ 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"
cannot install apache24
fresh ports tree FreeBSD serwer.dgs 12.1-STABLE FreeBSD 12.1-STABLE puchar amd64 any idea? ===> Building for apache24-2.4.43 --- all-recursive --- Making all in srclib --- all-recursive --- Making all in os --- all-recursive --- Making all in unix --- all-recursive --- --- unixd.lo --- /usr/local/share/apr/build-1/libtool --silent --mode=compile cc-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasi ng -DLIBICONV_PLUG -I. -I/usr/ports/www/apache24/work/httpd-2.4.43/os/unix -I/usr/ports/www/apache24/work/httpd-2.4.43/include -I /usr/local/include/apr-1 -I/usr/include -I/usr/local/include -I/usr/local/include/db5 -I/usr/ports/www/apache24/work/httpd-2.4.43/module s/aaa -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/cache -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/core -I/usr/ports/ww w/apache24/work/httpd-2.4.43/modules/database -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/filters -I/usr/ports/www/apache24/work /httpd-2.4.43/modules/ldap -I/usr/ports/www/apache24/work/httpd-2.4.43/server -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/logger s -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/lua -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/proxy -I/usr/ports/www/apa che24/work/httpd-2.4.43/modules/http2 -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/session -I/usr/ports/www/apache24/work/httpd-2 .4.43/modules/ssl -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/test -I/usr/ports/www/apache24/work/httpd-2.4.43/server -I/usr/por ts/www/apache24/work/httpd-2.4.43/modules/md -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/arch/unix -I/usr/ports/www/apache24/wor k/httpd-2.4.43/modules/dav/main -I/usr/ports/www/apache24/work/httpd-2.4.43/modules/generators -I/usr/ports/www/apache24/work/httpd-2.4. 43/modules/mappers -prefer-non-pic -static -c unixd.c && touch unixd.lo unixd.c:245:25: error: variable has incomplete type 'union semun' union semun ick; ^ unixd.c:245:19: note: forward declaration of 'union semun' union semun ick; ^ 1 error generated. *** [unixd.lo] Error code 1 make[5]: stopped in /usr/ports/www/apache24/work/httpd-2.4.43/os/unix 1 error make[5]: stopped in /usr/ports/www/apache24/work/httpd-2.4.43/os/unix *** [all-recursive] Error code 1 make[4]: stopped in /usr/ports/www/apache24/work/httpd-2.4.43/os/unix 1 error make[4]: stopped in /usr/ports/www/apache24/work/httpd-2.4.43/os/unix *** [all-recursive] Error code 1 make[3]: stopped in /usr/ports/www/apache24/work/httpd-2.4.43/os ___ 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: I want to maintain security/pssh
чт, 23 июл. 2020 г. в 11:33, Muhammad Moinur Rahman : > Hi, > > Please submit a patch with some improvements of the current port and > resetting the MAINTAINERSHIP to your email address in our bugzilla. > > Kind Regards, > Moin > > > On 23 Jul, 2020, at 14:25, Pavel Timofeev wrote: > > > > Hello, I'd like to take maintainership of security/pssh if no objections > > > Done! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248208 ___ 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: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)
On 2020-Jul-22, at 21:02, Mark Millard wrote: > On 2020-Jul-22, at 17:16, Mark Millard wrote: > >> On 2020-Jul-22, at 14:11, Jan Beich wrote: >> >>> Mark Millard via freebsd-ppc writes: >>> ../src/util/u_atomic.c:38:1: error: cannot redeclare builtin function '__sync_add_and_fetch_8' __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val) ^ ../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a builtin with type 'long long (volatile long long *, long long, ...)' ../src/util/u_atomic.c:38:1: error: definition of builtin function '__sync_add_and_fetch_8' __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val) ^ ../src/util/u_atomic.c:51:1: error: cannot redeclare builtin function '__sync_sub_and_fetch_8' __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val) ^ ../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a builtin with type 'long long (volatile long long *, long long, ...)' ../src/util/u_atomic.c:51:1: error: definition of builtin function '__sync_sub_and_fetch_8' __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val) ^ ../src/util/u_atomic.c:64:1: error: cannot redeclare builtin function '__sync_val_compare_and_swap_8' __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t newval) ^ ../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' is a builtin with type 'long long (volatile long long *, long long, long long, ...)' ../src/util/u_atomic.c:64:1: error: definition of builtin function '__sync_val_compare_and_swap_8' __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t newval) ^ 6 errors generated. >>> >>> Try replacing files/patch-i386 with >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464 >>> On i386 (clang) one can sometimes avoid -latomic by bumping -march >>> (FreeBSD 11.4/12.2/13.0 defaults to i686) but powerpc (gcc) probably >>> can't use __sync* with 64-bit types without -latomic, making Meson >>> define MISSING_64BIT_ATOMICS to use src/util/u_atomic.c >> >> The context was head (so system-clang instead of >> gcc 4.2.1). But, looking in the logs, it seems to >> have used an odd mix of system-clang and devel/lvm80 >> materials: >> >> . . . >> Project name: mesa >> Project version: 19.0.8 >> Using 'CC' from environment with value: 'cc' >> Using 'CFLAGS' from environment with value: '-O2 -pipe -g >> -fstack-protector-strong -fno-strict-aliasing ' >> Using 'LDFLAGS' from environment with value: ' >> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong ' >> Using 'CPPFLAGS' from environment with value: '' >> Using 'CXX' from environment with value: 'c++' >> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g >> -fstack-protector-strong -fno-strict-aliasing ' >> Using 'LDFLAGS' from environment with value: ' >> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong ' >> Using 'CPPFLAGS' from environment with value: '' >> Using 'CC' from environment with value: 'cc' >> Using 'CFLAGS' from environment with value: '-O2 -pipe -g >> -fstack-protector-strong -fno-strict-aliasing ' >> Using 'LDFLAGS' from environment with value: ' >> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong ' >> Using 'CPPFLAGS' from environment with value: '' >> C compiler for the host machine: cc (clang 10.0.1 "FreeBSD clang version >> 10.0.1 (g...@github.com:llvm/llvm-project.git >> llvmorg-10.0.1-rc2-0-g77d76b71d7d)") >> C linker for the host machine: cc ld.lld 10.0.1 >> Using 'CXX' from environment with value: 'c++' >> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g >> -fstack-protector-strong -fno-strict-aliasing ' >> Using 'LDFLAGS' from environment with value: ' >> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong ' >> Using 'CPPFLAGS' from environment with value: '' >> C++ compiler for the host machine: c++ (clang 10.0.1 "FreeBSD clang version >> 10.0.1 (g...@github.com:llvm/llvm-project.git >> llvmorg-10.0.1-rc2-0-g77d76b71d7d)") >> C++ linker for the host machine: c++ ld.lld 10.0.1 >> Host machine cpu family: ppc >> Host machine cpu: powerpc >> . . . >> llvm-config found: YES (/usr/local/bin/llvm-config80) 8.0.1 >> Run-time dependency LLVM (modules: amdgpu, asmparser, bitreader, bitwriter, >> engine, ipo, mcdisassembler, mcjit, native) found: YES 8.0.1 >> . . . >> cc . . . -DHAVE_LLVM=0x0800 -DMESA_LLVM_VERSION_PATCH=1 . . . -c >> ../src/util/u_atomic.c >> . . . >> >> >> The system-clang devel/llvm80 mix seems to be at >> least declaring __sync_add_and_fetch_8 , >> __sync_sub_and_fetch_8 , and >> __sync_val_compare_and_swap_8 as builtin, >> possibly implicitly. >> >> At this point I'm unclear if: >> >> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464 >> >> is relevant. The system-clang and devel/llvm80 mix >> just does not seem the right kind of thing to be >> doing in the buil
Re: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)
On 2020-Jul-23, at 09:25, Mark Millard wrote: > > On 2020-Jul-22, at 21:02, Mark Millard wrote: > >> On 2020-Jul-22, at 17:16, Mark Millard wrote: >> >>> On 2020-Jul-22, at 14:11, Jan Beich wrote: >>> Mark Millard via freebsd-ppc writes: > ../src/util/u_atomic.c:38:1: error: cannot redeclare builtin function > '__sync_add_and_fetch_8' > __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val) > ^ > ../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a builtin > with type 'long long (volatile long long *, long long, ...)' > ../src/util/u_atomic.c:38:1: error: definition of builtin function > '__sync_add_and_fetch_8' > __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val) > ^ > ../src/util/u_atomic.c:51:1: error: cannot redeclare builtin function > '__sync_sub_and_fetch_8' > __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val) > ^ > ../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a builtin > with type 'long long (volatile long long *, long long, ...)' > ../src/util/u_atomic.c:51:1: error: definition of builtin function > '__sync_sub_and_fetch_8' > __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val) > ^ > ../src/util/u_atomic.c:64:1: error: cannot redeclare builtin function > '__sync_val_compare_and_swap_8' > __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t > newval) > ^ > ../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' is a > builtin with type 'long long (volatile long long *, long long, long long, > ...)' > ../src/util/u_atomic.c:64:1: error: definition of builtin function > '__sync_val_compare_and_swap_8' > __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t > newval) > ^ > 6 errors generated. Try replacing files/patch-i386 with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464 On i386 (clang) one can sometimes avoid -latomic by bumping -march (FreeBSD 11.4/12.2/13.0 defaults to i686) but powerpc (gcc) probably can't use __sync* with 64-bit types without -latomic, making Meson define MISSING_64BIT_ATOMICS to use src/util/u_atomic.c >>> >>> The context was head (so system-clang instead of >>> gcc 4.2.1). But, looking in the logs, it seems to >>> have used an odd mix of system-clang and devel/lvm80 >>> materials: >>> >>> . . . >>> Project name: mesa >>> Project version: 19.0.8 >>> Using 'CC' from environment with value: 'cc' >>> Using 'CFLAGS' from environment with value: '-O2 -pipe -g >>> -fstack-protector-strong -fno-strict-aliasing ' >>> Using 'LDFLAGS' from environment with value: ' >>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong ' >>> Using 'CPPFLAGS' from environment with value: '' >>> Using 'CXX' from environment with value: 'c++' >>> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g >>> -fstack-protector-strong -fno-strict-aliasing ' >>> Using 'LDFLAGS' from environment with value: ' >>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong ' >>> Using 'CPPFLAGS' from environment with value: '' >>> Using 'CC' from environment with value: 'cc' >>> Using 'CFLAGS' from environment with value: '-O2 -pipe -g >>> -fstack-protector-strong -fno-strict-aliasing ' >>> Using 'LDFLAGS' from environment with value: ' >>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong ' >>> Using 'CPPFLAGS' from environment with value: '' >>> C compiler for the host machine: cc (clang 10.0.1 "FreeBSD clang version >>> 10.0.1 (g...@github.com:llvm/llvm-project.git >>> llvmorg-10.0.1-rc2-0-g77d76b71d7d)") >>> C linker for the host machine: cc ld.lld 10.0.1 >>> Using 'CXX' from environment with value: 'c++' >>> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g >>> -fstack-protector-strong -fno-strict-aliasing ' >>> Using 'LDFLAGS' from environment with value: ' >>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong ' >>> Using 'CPPFLAGS' from environment with value: '' >>> C++ compiler for the host machine: c++ (clang 10.0.1 "FreeBSD clang version >>> 10.0.1 (g...@github.com:llvm/llvm-project.git >>> llvmorg-10.0.1-rc2-0-g77d76b71d7d)") >>> C++ linker for the host machine: c++ ld.lld 10.0.1 >>> Host machine cpu family: ppc >>> Host machine cpu: powerpc >>> . . . >>> llvm-config found: YES (/usr/local/bin/llvm-config80) 8.0.1 >>> Run-time dependency LLVM (modules: amdgpu, asmparser, bitreader, bitwriter, >>> engine, ipo, mcdisassembler, mcjit, native) found: YES 8.0.1 >>> . . . >>> cc . . . -DHAVE_LLVM=0x0800 -DMESA_LLVM_VERSION_PATCH=1 . . . -c >>> ../src/util/u_atomic.c >>> . . . >>> >>> >>> The system-clang devel/llvm80 mix seems to be at >>> least declaring __sync_add_and_fetch_8 , >>> __sync_sub_and_fetch_8 , and >>> __sync_val_compare_and_swap_8 as builtin, >>> possibly implicitly. >>> >>> At this point I'm unclear if: >>> >>> https://gitlab.freedesktop.o
Can't compile firefox (was: Can't compile rust-cbindgen)
On 2020-07-20 11:09, George Mitchell wrote: > Running on 11.3-RELEASE-p11, amd64, ports tree at 542641 (head branch). > For some reason, firefox depends on devel/rust-cbindgen. I don't know > what that is, but it fails thus: > [...] That problem has gone away with a ports tree updated to 542958*. But now I have a problem compiling firefox 79.0 (which was also present in 78.0.2). The build log is at https://m5p.com/failed-firefox-build.txt and seems to me that it is using devel/libepoll-shim without including "-lepoll-shim" in the link command line. Help! -- George * - Mk/Uses/qt.mk, devel/qt5, and */qt5-* are at revision 541317 to avoid the openssl base vs ports morass. I'm noting this for accuracy even though I don't think that firefox uses any qt code at all. signature.asc Description: OpenPGP digital signature
Re: Can't compile firefox (was: Can't compile rust-cbindgen)
On 2020-07-23 17:37, George Mitchell wrote: > On 2020-07-20 11:09, George Mitchell wrote: >> Running on 11.3-RELEASE-p11, amd64, ports tree at 542641 (head branch). >> For some reason, firefox depends on devel/rust-cbindgen. I don't know >> what that is, but it fails thus: >> [...] > > That problem has gone away with a ports tree updated to 542958*. But > now I have a problem compiling firefox 79.0 (which was also present in > 78.0.2). The build log is at https://m5p.com/failed-firefox-build.txt > and seems to me that it is using devel/libepoll-shim without including > "-lepoll-shim" in the link command line. Help! -- George > > * - Mk/Uses/qt.mk, devel/qt5, and */qt5-* are at revision 541317 to > avoid the openssl base vs ports morass. I'm noting this for accuracy > even though I don't think that firefox uses any qt code at all. > I "fixed" this by turning on the OPTIMIZED_CFLAGS option, which I turned off somewhere in ancient history (meaning before last Thursday, the way my memory works). Sorry for the noise. I filed bug 248232 so someone can look at this at some point. -- george signature.asc Description: OpenPGP digital signature
Ready for commit PRs
Hi, ClamnAV build fix for latest version: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247792 Squid update to 4.12: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247397 Thanks, Franco ___ 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"