Nag mail..... Fwd: [package - 103amd64-quarterly][net/ceph-devel] Failed for ceph-devel-w.v2017.2.14 in build
Hi I'm regularly spammed by this mail. Which I guess that it is due to the quartly snapshoted ports copy. And that contains a missing patch that disables builing this port on 10.x So am I going to be spammed until end of Q2, or is there actually a way to get this port upgraded to the current Makefile? As this email suggests? Thanx, --WjW Forwarded Message Subject: [package - 103amd64-quarterly][net/ceph-devel] Failed for ceph-devel-w.v2017.2.14 in build Date: Fri, 14 Apr 2017 05:36:26 GMT From: pkg-fall...@freebsd.org To: w...@digiware.nl CC: pkg-fall...@freebsd.org You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: w...@digiware.nl Last committer: anto...@freebsd.org Ident: $FreeBSD: branches/2017Q2/net/ceph-devel/Makefile 437432 2017-04-01 12:00:27Z antoine $ Log URL: http://beefy2.nyi.freebsd.org/data/103amd64-quarterly/438400/logs/ceph-devel-w.v2017.2.14.log Build URL: http://beefy2.nyi.freebsd.org/build.html?mastername=103amd64-quarterly&build=438400 Log: >> Building net/ceph-devel build started at Fri Apr 14 04:55:59 UTC 2017 port directory: /usr/ports/net/ceph-devel building for: FreeBSD 103amd64-quarterly-job-21 10.3-RELEASE-p18 FreeBSD 10.3-RELEASE-p18 amd64 maintained by: w...@digiware.nl Makefile ident: $FreeBSD: branches/2017Q2/net/ceph-devel/Makefile 437432 2017-04-01 12:00:27Z antoine $ Poudriere version: 3.1.17-9-gf49c6f78 Host OSVERSION: 1200020 Jail OSVERSION: 1003000 Job Id: 21 ---Begin Environment--- SHELL=/bin/csh OSVERSION=1003000 UNAME_v=FreeBSD 10.3-RELEASE-p18 UNAME_r=10.3-RELEASE-p18 BLOCKSIZE=K MAIL=/var/mail/root STATUS=1 SAVED_TERM= MASTERMNT=/usr/local/poudriere/data/.m/103amd64-quarterly/ref PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin POUDRIERE_BUILD_TYPE=bulk PKGNAME=ceph-devel-w.v2017.2.14 OLDPWD=/ PWD=/usr/local/poudriere/data/.m/103amd64-quarterly/ref/.p/pool MASTERNAME=103amd64-quarterly SCRIPTPREFIX=/usr/local/share/poudriere USER=root HOME=/root POUDRIERE_VERSION=3.1.17-9-gf49c6f78 SCRIPTPATH=/usr/local/share/poudriere/bulk.sh LIBEXECPREFIX=/usr/local/libexec/poudriere LOCALBASE=/usr/local PACKAGE_BUILDING=yes POUDRIEREPATH=/usr/local/bin/poudriere ---End Environment--- ---Begin OPTIONS List--- ---End OPTIONS List--- --CONFIGURE_ARGS-- --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- MAKE=gmake PYTHON="/usr/local/bin/python2.7" XDG_DATA_HOME=/wrkdirs/usr/ports/net/ceph-devel/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/net/ceph-devel/work HOME=/wrkdirs/usr/ports/net/ceph-devel/work TMPDIR="/tmp" SHELL=/bin/sh CONFIG_SHELL=/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- XDG_DATA_HOME=/wrkdirs/usr/ports/net/ceph-devel/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/net/ceph-devel/work HOME=/wrkdirs/usr/ports/net/ceph-devel/work TMPDIR="/tmp" NO_PIE=yes WITHOUT_DEBUG_FILES=yes WITHOUT_KERNEL_SYMBOLS=yes SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing" CPP="cpp" CPPFLAGS="" LDFLAGS=" -fstack-protector" LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -fstack-protector -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-- CMAKE_BUILD_TYPE="release" PYTHON_INCLUDEDIR=include/python2.7 PYTHON_LIBDIR=lib/python2.7 PYTHON_PLATFORM=freebsd10 PYTHON_PYOEXTENSION=pyo PYTHON_SITELIBDIR=lib/python2.7/site-packages PYTHON_SUFFIX=27 PYTHON_VER=2.7 PYTHON_VERSION=python2.7 PYTHON2="" PYTHON3="@comment " OSREL=10.3 PREFIX=%D LOCALBASE=/usr/local RESETPREFIX=/usr/local PORTDOCS="" PORTEXAMPLES="" LIB32DIR=lib DOCSDIR="share/doc/ceph" EXAMPLESDIR="share/examples/ceph" DATADIR="share/ceph" WWWDIR="www/ceph" ETCDIR="etc/ceph" --End PLIST_SUB-- --SUB_LIST-- PREFIX=/usr/local LOCALBASE=/usr/local DATADIR=/usr/local/share/ceph DOCSDIR=/usr/local/share/doc/ceph EXAMPLESDIR=/usr/local/share/examples/ceph WWWDIR=/usr/local/www/ceph ETCDIR=/usr/local/etc/ceph --End SUB_LIST-- ---Begin make.conf--- USE_PACKAGE_DEPENDS=yes BATCH=yes WRKDIRPREFIX=/wrkdirs PORTSDIR=/usr/ports PACKAGES=/packages DISTDIR=/distfiles /usr/local/etc/poudriere.d/make.conf # XXX: We really need this but cannot use it while 'make checksum' does not # try the next mirror on checksum failure. It currently retries the same # failed mirror and then fails rather then trying another. It *does* # try the next if the size is mismatched though. #MASTER_SITE_FREEBSD=yes # Build ALLOW_MAKE_JOBS_PACKAGES with 2 jobs MAKE_JOBS_NUMBER=2 /usr/ports/Mk/Scripts/ports_env.sh ARCH=amd64 CONFIGURE_MAX_CMD_LEN=262144 HAVE_COMPAT_IA32_KERN=YES OPSYS=FreeBSD OSREL=10.3 OSVERSION=1003000 PYTHONBASE=/usr/local UID=0 _JAVA_O
net/openmpi fails to compile with default settings
>> Building net/openmpi build started at Fri Apr 14 08:28:00 UTC 2017 port directory: /usr/ports/net/openmpi building for: FreeBSD 11rel0amd64-local-crayon2-job-01 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 amd64 maintained by: dan...@freebsd.org Makefile ident: $FreeBSD: head/net/openmpi/Makefile 437439 2017-04-01 15:23:30Z gerald $ Poudriere version: 3.1.14 Host OSVERSION: 1100122 Jail OSVERSION: 1100122 (...) ompi_datatype_module.c:281:44: warning: implicit declaration of function 'OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE' is invalid in C99 [-Wimplicit-function-declaration] ompi_predefined_datatype_t ompi_mpi_aint = OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT); ^ ompi_datatype_module.c:281:86: error: use of undeclared identifier 'INT64_T' ompi_predefined_datatype_t ompi_mpi_aint = OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT); ^ ompi_datatype_module.c:281:95: error: use of undeclared identifier 'AINT' ompi_predefined_datatype_t ompi_mpi_aint = OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT); ^ 1 warning and 2 errors generated. gmake[3]: *** [Makefile:1733: ompi_datatype_module.lo] Error 1 No one has reported this yet but I don't believe I am the first one to see this since lots of ports depend on this openmpi. Am I missing something? Grzegorz ___ 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: net/openmpi fails to compile with default settings
>Makefile ident: $FreeBSD: head/net/openmpi/Makefile 437439 Builds fine for me at the same ports revision: ===>>> The following actions were performed: Re-installation of openmpi-1.10.6_1 Re-installation of openmpi2-2.0.2_4 However, I use a custom /etc/make.conf: # cat /etc/make.conf DEVELOPER=yes DEFAULT_VERSIONS=gcc=7 FFLAGS+= -O2 -pipe -march=bdver2 -mtune=bdver2 FFLAGS+= -funroll-loops --param max-unroll-times=4 -ftree-vectorize FFLAGS+= -g I'll try now will all default options, most importantly default GCC, lang/gcc, which is now gcc-5.4.0. I guess you are using all the default options, right? >see this since lots of ports depend on this openmpi. Am I missing something? Is this true? I think most ports needing MPI default to MPICH. Anton ___ 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: net/openmpi fails to compile with default settings
No, with default GCC I still cannot reproduce your build failure. Here's my build log: http://eis.bris.ac.uk/~mexas/openmpi1-2.text # pkg info -xd openmpi openmpi-1.10.6_1: slurm-wlm-16.05.9_1 gcc-5.4.0 libltdl-2.4.6 hwloc-1.11.1 openmpi2-2.0.2_4: slurm-wlm-16.05.9_1 munge-0.5.12 gcc-5.4.0 libltdl-2.4.6 libevent-2.1.8 hwloc-1.11.1 Perhaps your enviroment is not clean? Anton ___ 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: net/openmpi fails to compile with default settings
On 14/04/2017 09:47, Anton Shterenlikht wrote: No, with default GCC I still cannot reproduce your build failure. Here's my build log: http://eis.bris.ac.uk/~mexas/openmpi1-2.text # pkg info -xd openmpi openmpi-1.10.6_1: slurm-wlm-16.05.9_1 gcc-5.4.0 libltdl-2.4.6 hwloc-1.11.1 openmpi2-2.0.2_4: slurm-wlm-16.05.9_1 munge-0.5.12 gcc-5.4.0 libltdl-2.4.6 libevent-2.1.8 hwloc-1.11.1 Perhaps your enviroment is not clean? Anton ___ 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" Thanks Anton for looking into this. Port lang/gcc also failed when I selected the BOOTSTRAP option. Then I deselected it and now gcc-5.4.0 builds fine either with GRAPHITE enabled or disabled. I am using poudriere to build. How can my environment be not clean? I don't know which ports default to MPICH. For me failed openmpi blocks 141 ports: [00:05:53] >> [01][00:04:13] Finished build of net/openmpi: Failed: build [00:05:55] >> [01][00:04:15] Skipping build of graphics/ImageMagick: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of x11-fm/thunar: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of audio/alsa-plugins: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of editors/openoffice-4: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of archivers/ark: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/avidemux: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/avidemux-cli: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/avidemux-plugins: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/avidemux-qt4: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of sysutils/baloo: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of sysutils/baloo-widgets: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of graphics/blender: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of editors/calligra: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of audio/chromaprint: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of www/chromium: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of audio/clementine-player: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of x11-fm/doublecmd: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/dvdauthor: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of audio/espeak: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of graphics/evince: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/ffmpeg: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/ffmpeg0: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/ffmpegthumbnailer: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of multimedia/ffms2: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of math/fftw3: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of math/fftw3-float: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of sysutils/filelight-kde4: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of www/firefox: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of audio/fluidsynth: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of audio/freealut: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of graphics/frei0r-plugins: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of graphics/frei0r-plugins-opencv: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of graphics/gegl: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of graphics/gimp: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of graphics/gimp-app: Dependent port net/openmpi failed [00:05:55] >> [01][00:04:15] Skipping build of print/gimp-gutenprint: Dependent port net/openmpi failed [00:05:55]
Re: net/openmpi fails to compile with default settings
>I don't know which ports default to MPICH. For me failed openmpi blocks >141 ports: > >[00:05:53] >> [01][00:04:13] Finished build of net/openmpi: Failed: >build >[00:05:55] >> [01][00:04:15] Skipping build of graphics/ImageMagick: >Dependent port net/openmpi failed This is strange. It shouldn't depend on openmpi: $ pkg info -xd ImageMagick|grep mpi $ pkg info -xr openmpi openmpi-1.10.6_1: openmpi2-2.0.2_4: $ I have 723 packages installed, including lots of ports from your list, e.g. firefox, chromium, ImageMagick. None require openmpi. In fact the only reason I built openmpi is to check the MPI performance against MPICH. I mostly use pkg, with occasional use of the ports tree directly, when I need non-default options. Perhaps there is something different in poudriere. I think you need somebody more experienced to advise. Anton ___ 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"
audio/logitechmediaserver fails to compile
Hi —
This is FreeBSD 11.0-STABLE #0 r316610.
IIRC, starting with the recent upgrade to ...
poudriere> clang --version
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on
LLVM 4.0.0)
... audio/logitechmediaserver fails to compile (poudriere run):
gmake[2]: Entering directory
'/wrkdirs/usr/ports/audio/logitechmediaserver/work/slimserver-vendor-14cc392/CPAN/icu/source/i18n'
[...]
uspoof.cpp:369:22: error: ordered comparison between pointer and zero
('int32_t *' (aka 'int *') and 'int')
if (position > 0) {
^ ~
1 warning and 1 error generated.
gmake[2]: *** [../config/mh-bsd-gcc:41: uspoof.ao] Error 1
gmake[2]: Leaving directory
'/wrkdirs/usr/ports/audio/logitechmediaserver/work/slimserver-vendor-14cc392/CPAN/icu/source/i18n'
gmake[1]: *** [Makefile:119: all-recursive] Error 2
gmake[1]: Leaving directory
'/wrkdirs/usr/ports/audio/logitechmediaserver/work/slimserver-vendor-14cc392/CPAN/icu/source'
make failed
Any ideas on how to fix this?
Thanks in advance,
Michael
___
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: Nag mail..... Fwd: [package - 103amd64-quarterly][net/ceph-devel] Failed for ceph-devel-w.v2017.2.14 in build
On 4/14/17 6:33 PM, Willem Jan Withagen wrote: > Hi > > I'm regularly spammed by this mail. > Which I guess that it is due to the quartly snapshoted ports copy. > And that contains a missing patch that disables builing this port on 10.x > > So am I going to be spammed until end of Q2, or is there actually a way > to get this port upgraded to the current Makefile? As this email suggests? > > Thanx, > --WjW > The committer (CC'd) that made the change (r438104) in HEAD should have merged the change to the quarterly branch. Over to you Mokhi [1] http://svnweb.freebsd.org/changeset/ports/438104 ___ 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"
default named.conf in bind ports and slaving from f-root
Hello,
Cloudflare deployed a bunch (74 apparently) of new f-root dns
servers, which do not permit AXFR like the other f-root instances
do.
Since our bind ports default configs suggest slaving . and arpa
from f-root this is a big problem in the cases where anycast
routing makes your requests hit one of the new Cloudflare
servers.
The new f-root servers appeared around two weeks ago. The
result for affected users is a nonfunctional name server when
their copy of the root zone expire. See the thread in [1] for
more info.
A good alternative could be to change named.conf to use
lax.xfr.dns.icann.org and iad.xfr.dns.icann.org as
described in [2]. My named.conf now looks like this:
-
zone "." {
type slave;
file "/usr/local/etc/namedb/slave/root.slave";
masters {
192.0.32.132; // lax.xfr.dns.icann.org
2620:0:2d0:202::132;// lax.xfr.dns.icann.org
192.0.47.132; // iad.xfr.dns.icann.org
2620:0:2830:202::132; // iad.xfr.dns.icann.org
};
notify no;
};
zone "arpa" {
type slave;
file "/usr/local/etc/namedb/slave/arpa.slave";
masters {
192.0.32.132; // lax.xfr.dns.icann.org
2620:0:2d0:202::132;// lax.xfr.dns.icann.org
192.0.47.132; // iad.xfr.dns.icann.org
2620:0:2830:202::132; // iad.xfr.dns.icann.org
};
notify no;
};
-
Any thoughts before I open a PR?
And what do we do about the number of running bind servers
on freebsd machines out there that are currently slaving root
from an f-root server? A simple routing change can render the
servers useless.
Best regards,
Thomas Steen Rasmussen
[1]
https://lists.dns-oarc.net/pipermail/dns-operations/2017-April/016171.html
[2] http://www.dns.icann.org/services/axfr/
___
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: LLVM port(s) take very long time to package
On Wed, Apr 12, 2017 at 12:06:42PM +0200, Michael Gmelin wrote: > > On 12. Apr 2017, at 11:37, Alexey Dokuchaev wrote: > > ... > > Other alternative to PKG_NOCOMPRESS=1 could be PKGSUFFIX=.tbz (pkg-static > > create -f tbz ...), will play with that as well. > > I don't think bzip will buy you much in terms of performance, Surprisingly, it actually did: $ time make package PKG_SUFX=.tbz ===> Building package for llvm40-4.0.0_2 565.215u 5.316s 9:34.18 99.3% 7899+502k 1+3020io 0pf+0w ^^^ Single-threaded bzip2 was faster than multi-threaded xz, at the expense of larger package of course: $ ls -s1 llvm40-4.0.0_2.t* 386752 llvm40-4.0.0_2.tbz 286816 llvm40-4.0.0_2.txz > supporting something like lz4 would be useful. Or, like vsevolod@ had mentioned, Zstandard. But I'm afraid it would take some time before we'd arrive there. ./danfe ___ 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: LLVM port(s) take very long time to package
> On 14. Apr 2017, at 16:22, Alexey Dokuchaev wrote: > > On Wed, Apr 12, 2017 at 12:06:42PM +0200, Michael Gmelin wrote: >>> On 12. Apr 2017, at 11:37, Alexey Dokuchaev wrote: >>> ... >>> Other alternative to PKG_NOCOMPRESS=1 could be PKGSUFFIX=.tbz (pkg-static >>> create -f tbz ...), will play with that as well. >> >> I don't think bzip will buy you much in terms of performance, > > Surprisingly, it actually did: > > $ time make package PKG_SUFX=.tbz > ===> Building package for llvm40-4.0.0_2 > 565.215u 5.316s 9:34.18 99.3% 7899+502k 1+3020io 0pf+0w >^^^ > Single-threaded bzip2 was faster than multi-threaded xz, at the expense > of larger package of course: > > $ ls -s1 llvm40-4.0.0_2.t* > 386752 llvm40-4.0.0_2.tbz > 286816 llvm40-4.0.0_2.txz >> Interesting, I'll tried that on our high-frequency builders. -m ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: default named.conf in bind ports and slaving from f-root
Hi,
I'm busy right now, could you open a PR so that I don't loose and forget
this ?
Le 14/04/2017 à 14:37, Thomas Steen Rasmussen a écrit :
> Hello,
>
> Cloudflare deployed a bunch (74 apparently) of new f-root dns
> servers, which do not permit AXFR like the other f-root instances
> do.
>
> Since our bind ports default configs suggest slaving . and arpa
> from f-root this is a big problem in the cases where anycast
> routing makes your requests hit one of the new Cloudflare
> servers.
>
> The new f-root servers appeared around two weeks ago. The
> result for affected users is a nonfunctional name server when
> their copy of the root zone expire. See the thread in [1] for
> more info.
>
> A good alternative could be to change named.conf to use
> lax.xfr.dns.icann.org and iad.xfr.dns.icann.org as
> described in [2]. My named.conf now looks like this:
>
> -
>
> zone "." {
> type slave;
> file "/usr/local/etc/namedb/slave/root.slave";
> masters {
> 192.0.32.132; // lax.xfr.dns.icann.org
> 2620:0:2d0:202::132;// lax.xfr.dns.icann.org
> 192.0.47.132; // iad.xfr.dns.icann.org
> 2620:0:2830:202::132; // iad.xfr.dns.icann.org
> };
> notify no;
> };
> zone "arpa" {
> type slave;
> file "/usr/local/etc/namedb/slave/arpa.slave";
> masters {
> 192.0.32.132; // lax.xfr.dns.icann.org
> 2620:0:2d0:202::132;// lax.xfr.dns.icann.org
> 192.0.47.132; // iad.xfr.dns.icann.org
> 2620:0:2830:202::132; // iad.xfr.dns.icann.org
> };
> notify no;
> };
>
> -
>
> Any thoughts before I open a PR?
>
> And what do we do about the number of running bind servers
> on freebsd machines out there that are currently slaving root
> from an f-root server? A simple routing change can render the
> servers useless.
>
>
> Best regards,
>
> Thomas Steen Rasmussen
>
>
> [1]
> https://lists.dns-oarc.net/pipermail/dns-operations/2017-April/016171.html
>
> [2] http://www.dns.icann.org/services/axfr/
>
>
>
--
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: default named.conf in bind ports and slaving from f-root
On 04/14/2017 04:51 PM, Mathieu Arnold wrote: Hi, I'm busy right now, could you open a PR so that I don't loose and forget this ? Sure thing, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218656 /Thomas ___ 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: audio/logitechmediaserver fails to compile
Michael Grimm writes:
> uspoof.cpp:369:22: error: ordered comparison between pointer and zero
> ('int32_t *' (aka 'int *') and 'int')
> if (position > 0) {
> ^ ~
> 1 warning and 1 error generated.
>
> Any ideas on how to fix this?
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218407
___
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: audio/logitechmediaserver fails to compile
Jan Beich wrote:
> Michael Grimm writes:
>> uspoof.cpp:369:22: error: ordered comparison between pointer and zero
>> ('int32_t *' (aka 'int *') and 'int')
>>if (position > 0) {
>> ^ ~
>> 1 warning and 1 error generated.
>>
>> Any ideas on how to fix this?
>
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218407
Thanks! I did google for an issue with logitechmediaserver, but I didn't search
for icu instead :-(
Regards,
Michael
___
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: LibreSSL + Heimdal Problem
On 2017-04-13 13:43, Rafael Henrique da Silva Faria wrote: Hi everyone, I'm trying to compile Heimdal with LibreSSL on a server, but there is a odd problem. Actually, I'm updating a working server, updated the LibreSSL version, and tried to recompile all dependent ports with "portmaster -fr libressl", but it stops on Heimdal. The make stops on this linking: /usr/bin/ld: warning: libcrypto.so.38, needed by /usr/local/lib/heimdal/libhcrypto.so.4, not found (try using -rpath or -rpath-link) But when the make checks the depends, it looks for an other lib: ===> heimdal-7.1.0_2 depends on file: /usr/local/lib/libcrypto.so.41 - found root@cenpe heimdal # pkg which /usr/local/lib/libcrypto.so.41 /usr/local/lib/libcrypto.so.41 was installed by package libressl-2.5.3 root@cenpe heimdal # pkg which /usr/local/lib/libcrypto.so.38 /usr/local/lib/libcrypto.so.38 was not found in the database root@cenpe heimdal # pkg info | grep heimdal heimdal-7.1.0_2Popular BSD-licensed implementation of Kerberos 5 root@cenpe heimdal # /usr/local/bin/openssl version LibreSSL 2.5.3 There is anything that I need to do to change the lib that Heimdal is looking for? I already have tried to recompile all ports (portmaster -fa), but it always stops on Heimdal. I don't know if the problem is with Heimdal or LibreSSL, because I can't recompile OpenSSH-Portable on this machine too. It stops on configure: checking OpenSSL header version... not found configure: error: OpenSSL version header not found. All started after updating LibreSSL to the latest version. root@cenpe openssh-portable # freebsd-version -ku 11.0-RELEASE-p8 11.0-RELEASE-p8 root@cenpe openssh-portable # uname -a FreeBSD cenpe.fclar.unesp.br 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 06:55:27 UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Please, let me know if I need to give some more information. Thanks in advance. -- Rafael Henrique da Silva Faria Hi Rafael, Sounds to me like portmaster isn't processing dependencies correctly here. The installed heimdal still depends on the old libcrypto whilst you have the new one on your system. Does it fail during build of a spcific port? You may want to first rebuild heimdal before other ports. pkg delete -f heimdal first, then build/install it again. If you still have the old package you could extract the old libs from libressl 2.4 and put them in /usr/local/lib temporarily. Sometimes you can also circumvent the issue by symlinking libcrypto.so.38 to libcrypto.so.41 but that is real hackish. Cheers, Bernard. ___ 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"
spamassassin port install error
# make -C /usr/ports/mail/spamassassin/ install ===> Options unchanged ===> Installing for spamassassin-3.4.1_10 ===> spamassassin-3.4.1_10 depends on package: p5-Encode-Detect>=0 - found ===> spamassassin-3.4.1_10 depends on package: p5-HTML-Parser>=3.46 - found ===> spamassassin-3.4.1_10 depends on package: p5-HTTP-Date>=0 - found ===> spamassassin-3.4.1_10 depends on package: p5-Net-DNS>=0.63 - found ===> spamassassin-3.4.1_10 depends on package: p5-NetAddr-IP>=4.010 - found ===> spamassassin-3.4.1_10 depends on package: p5-Net-IDN-Encode>=0 - found ===> spamassassin-3.4.1_10 depends on package: p5-Net-LibIDN>=0 - found ===> spamassassin-3.4.1_10 depends on package: p5-URI>=0 - found ===> spamassassin-3.4.1_10 depends on package: re2c>=.12.0 - found ===> spamassassin-3.4.1_10 depends on package: p5-IO-Socket-SSL>=0 - found ===> spamassassin-3.4.1_10 depends on package: gnupg1>=1.4.7 - found ===> spamassassin-3.4.1_10 depends on package: p5-IO-Socket-SSL>=0 - found ===> spamassassin-3.4.1_10 depends on package: p5-Mail-DKIM>=0.37 - found ===> spamassassin-3.4.1_10 depends on package: p5-Crypt-OpenSSL-RSA>=0.26_1 - found ===> spamassassin-3.4.1_10 depends on package: p5-Mail-SPF>=0 - found ===> spamassassin-3.4.1_10 depends on file: /usr/local/lib/libcrypto.so.9 - found ===> spamassassin-3.4.1_10 depends on file: /usr/local/bin/perl5.20.1 - found ===> Checking if spamassassin already installed actual-package-depends: dependency on /usr/local/bin/perl5.20.1 not registered (normal if it belongs to base) ===> Registering installation for spamassassin-3.4.1_10 pkg-static: Unable to access file /usr/ports/mail/spamassassin/work/stage/usr/local/share/man/man1/sa-awl.1.gz:No such file or directory pkg-static: Unable to access file /usr/ports/mail/spamassassin/work/stage/usr/local/share/man/man1/sa-compile.1.gz:No such file or directory pkg-static: Unable to access file /usr/ports/mail/spamassassin/work/stage/usr/local/share/man/man1/sa-learn.1.gz:No such file or directory pkg-static: Unable to access file /usr/ports/mail/spamassassin/work/stage/usr/local/share/man/man1/sa-update.1.gz:No such file or directory pkg-static: Unable to access file /usr/ports/mail/spamassassin/work/stage/usr/local/share/man/man1/spamassassin-run.1.gz:No such file or directory pkg-static: Unable to access file /usr/ports/mail/spamassassin/work/stage/usr/local/share/man/man1/spamassassin.1.gz:No such file or directory pkg-static: Unable to access file /usr/ports/mail/spamassassin/work/stage/usr/local/share/man/man1/spamc.1.gz:No such file or directory pkg-static: Unable to access file /usr/ports/mail/spamassassin/work/stage/usr/local/share/man/man1/spamd.1.gz:No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/mail/spamassassin *** Error code 1 Stop. make: stopped in /usr/ports/mail/spamassassin ___ 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"
graphics/opencv2 orphaned. Where from here
Thanks for the work on opencv, but PLEASE put something in UPDATING when you make changes that impact large numbers of ports. I see opencv2 as orphaned, so I can't stay there. Do I reset the origin of opencv2 to opencv? Or will I need to delete all of them and rebuild everything? Please put information in UPDATING to give us poor users some idea of how to proceed. I really would rathe rnot have to re-install all of those ports if there is no reason. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On Thu, 13 Apr 2017, Pedro Giffuni wrote: > I didn’t want to get into this but the problem is that as part of it's > build/bootstrapping process, GCC historically takes system headers > and attempts to “fix” them. I am unsure the fixes do anything at all > nowadays but the effect is that the compiler tends to take snapshots > of the system headers when it is built. cdefs.h is used by all the > system headers so changes in cdefs.h have good chances affecting > such builds but any change are likely to cause similar trouble. > > In the case of gcc-aux, it appears the compilation is based on a > bootstrap compiler which already carries outdated headers. > A workaround, suggested by gerald@ the last time a similar issue > happened was to run for install-tools/fixinc.sh. I think that may > regenerate the headers and let the build use updated headers. > Ultimately gcc-aux needs maintainer intervention and using > outdated headers will break sooner or later: especially on -current. Indeed, thanks for the analysis/background, Pedro! I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, and perhaps John (as the maintainer of that port) has plans to update it? Let me copy him. Gerald PS: John, if you have an update, happy to help and apply that for you. ___ 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: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On Sat, 15 Apr 2017 09:30:49 +1000 (AEST) Gerald Pfeifer wrote: > On Thu, 13 Apr 2017, Pedro Giffuni wrote: > > I didn't want to get into this but the problem is that as part of > > it's build/bootstrapping process, GCC historically takes system > > headers and attempts to "fix" them. I am unsure the fixes do > > anything at all nowadays but the effect is that the compiler tends > > to take snapshots of the system headers when it is built. cdefs.h > > is used by all the system headers so changes in cdefs.h have good > > chances affecting such builds but any change are likely to cause > > similar trouble. > > > > In the case of gcc-aux, it appears the compilation is based on a > > bootstrap compiler which already carries outdated headers. > > A workaround, suggested by gerald@ the last time a similar issue > > happened was to run for install-tools/fixinc.sh. I think that may > > regenerate the headers and let the build use updated headers. > > Ultimately gcc-aux needs maintainer intervention and using > > outdated headers will break sooner or later: especially on > > -current. > > Indeed, thanks for the analysis/background, Pedro! > > I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, > and perhaps John (as the maintainer of that port) has plans to update > it? Let me copy him. > > Gerald > > PS: John, if you have an update, happy to help and apply that for you. Hi Gerald, it was suggested multiple times that the whole fixinc step is ultimately harmful and serves no useful purpose and probably should be disabled in built packages outright. Is there a reason not to do it? Even Redhat appears to do the slimming in their rpms: mv $FULLPATH/include-fixed/syslimits.h $FULLPATH/include/syslimits.h mv $FULLPATH/include-fixed/limits.h $FULLPATH/include/limits.h for h in `find $FULLPATH/include -name \*.h`; do if grep -q 'It has been auto-edited by fixincludes from' $h; then rh=`grep -A2 'It has been auto-edited by fixincludes from' $h | tail -1 | sed 's|^.*"\(.*\)".*$|\1|'` diff -up $rh $h || : rm -f $h fi done -- Alexander Kabaev pgpzeAwZ9onkU.pgp Description: Цифровая подпись OpenPGP
Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
Alexander Kabaev kabaev at gmail.com on Sat Apr 15 00:20:40 UTC 2017 wrote: . . . > it was suggested multiple times that the whole fixinc step is > ultimately harmful and serves no useful purpose and probably should be > disabled in built packages outright. Is there a reason not to do it? > Even Redhat appears to do the slimming in their rpms: > > mv $FULLPATH/include-fixed/syslimits.h $FULLPATH/include/syslimits.h > mv $FULLPATH/include-fixed/limits.h $FULLPATH/include/limits.h > for h in `find $FULLPATH/include -name \*.h`; do > if grep -q 'It has been auto-edited by fixincludes from' $h; then > rh=`grep -A2 'It has been auto-edited by fixincludes from' $h | > tail -1 | sed 's|^.*"\(.*\)".*$|\1|'` diff -up $rh $h || : > rm -f $h > fi > done I'll note that: http://www.linuxfromscratch.org/lfs/view/7.1/chapter06/gcc.html reports as one of its steps (quote): The fixincludes script is known to occasionally erroneously attempt to "fix" the system headers installed so far. As the headers up to this point are known to not require fixing, issue the following command to prevent the fixincludes script from running: sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in (End quote) So seems that disabling fixinc.sh's use is fairly common when the headers are known to "not require fixing" (i.e., are known to already be gcc compliant). === Mark Millard markmi at dsl-only.net ___ 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: graphics/opencv2 orphaned. Where from here
Kevin Oberman writes: > Thanks for the work on opencv, but PLEASE put something in UPDATING when > you make changes that impact large numbers of ports. I see opencv2 as > orphaned, so I can't stay there. graphics/opencv has only 28 consumers which isn't that "large". I didn't document the rename in r438490 because: - no manual/special steps required (for pkg, poudriere and, probably, synth) - r423216 wasn't documented as well - partial upgrades were never supported (e.g. /quarterly packages + /head ports) - PORTREVISION was bumped to help tools that don't (or incompletely) respect MOVED > Do I reset the origin of opencv2 to opencv? Yes. > Or will I need to delete all of them and rebuild everything? No but it'd work as well. > Please put information in UPDATING to give us poor users some idea of > how to proceed. I really would rathe rnot have to re-install all of > those ports if there is no reason. Does "pkg upgrade" not work? If portmaster is such a special snowflake that requires multiplying copypasta in UPDATING for every rename that has > 1 consumer it should be documented it in the Porter's Handbook. Another issue with portmaster is it makes committers (over)think skipping PORTREVISION bumps like in 20170411 or 20150919 is safe only to screw up pkg-upgrade(8) as changed ABI doesn't propagate to consumers. ___ 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: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer wrote: > On Thu, 13 Apr 2017, Pedro Giffuni wrote: >> I didn’t want to get into this but the problem is that as part of it's >> build/bootstrapping process, GCC historically takes system headers >> and attempts to “fix” them. I am unsure the fixes do anything at all >> nowadays but the effect is that the compiler tends to take snapshots >> of the system headers when it is built. cdefs.h is used by all the >> system headers so changes in cdefs.h have good chances affecting >> such builds but any change are likely to cause similar trouble. >> >> In the case of gcc-aux, it appears the compilation is based on a >> bootstrap compiler which already carries outdated headers. >> A workaround, suggested by gerald@ the last time a similar issue >> happened was to run for install-tools/fixinc.sh. I think that may >> regenerate the headers and let the build use updated headers. >> Ultimately gcc-aux needs maintainer intervention and using >> outdated headers will break sooner or later: especially on -current. > > Indeed, thanks for the analysis/background, Pedro! > > I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, > and perhaps John (as the maintainer of that port) has plans to update > it? Let me copy him. [As I have a prior E-mail exchange with John M. indicating that he was not intending to be the lang/gcc6-aux maintainer, I avoid spamming him with this material: I've removed him from the CC list in this reply. I can send the material to him if I see evidence of his wanting it.] Just FYI: [Previously: temporarily adding __nonnull and __nonnull_all back into into my local head FreeBSD variant got problems with: __vm_ooffset_t and __vm_pindex_t no longer existing and also the same pid_t issue indicated below.] I tried using [on a Pine64+ 2GB aarch64 system]: # /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarch64-aux-freebsd12.0/6.3.1/install-tools/mkheaders /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and __vm_pindex_t. I then built via portmaster -CDK usage. Various header issues did go away but the build of lang/gcc6-aux still stopped with: In file included from /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:20:0: ./config.h:556:15: error: two or more data types in declaration specifiers #define pid_t int ^ I'm guessing that the define for pid_t in config.h resulted in something like: typedef ??? pid_t; that turned into something like a: typedef ??? int; for the error listed above. There were also implicit-declaration warnings: /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c: In function 'simple_object_internal_read': /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:75:21: warning: implicit declaration of function 'read' [-Wimplicit-function-declaration] ssize_t got = read (descriptor, buffer, size); ^~~~ /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c: In function 'simple_object_internal_write': /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:119:23: warning: implicit declaration of function 'write' [-Wimplicit-function-declaration] ssize_t wrote = write (descriptor, buffer, size); ^ The implicit-declaration warnings for read and write may well also not be expected/desirable. It may be that more than a script run is needed to make things be appropriate. === Mark Millard markmi at dsl-only.net ___ 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: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
> On Apr 14, 2017, at 19:53, Mark Millard wrote: > > On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer wrote: > >> On Thu, 13 Apr 2017, Pedro Giffuni wrote: >>> I didn’t want to get into this but the problem is that as part of it's >>> build/bootstrapping process, GCC historically takes system headers >>> and attempts to “fix” them. I am unsure the fixes do anything at all >>> nowadays but the effect is that the compiler tends to take snapshots >>> of the system headers when it is built. cdefs.h is used by all the >>> system headers so changes in cdefs.h have good chances affecting >>> such builds but any change are likely to cause similar trouble. >>> >>> In the case of gcc-aux, it appears the compilation is based on a >>> bootstrap compiler which already carries outdated headers. >>> A workaround, suggested by gerald@ the last time a similar issue >>> happened was to run for install-tools/fixinc.sh. I think that may >>> regenerate the headers and let the build use updated headers. >>> Ultimately gcc-aux needs maintainer intervention and using >>> outdated headers will break sooner or later: especially on -current. >> >> Indeed, thanks for the analysis/background, Pedro! >> >> I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, >> and perhaps John (as the maintainer of that port) has plans to update >> it? Let me copy him. > > [As I have a prior E-mail exchange with John M. indicating that > he was not intending to be the lang/gcc6-aux maintainer, I > avoid spamming him with this material: I've removed him from > the CC list in this reply. I can send the material to him if I > see evidence of his wanting it.] > > Just FYI: > > [Previously: temporarily adding __nonnull and __nonnull_all > back into into my local head FreeBSD variant got problems > with: __vm_ooffset_t and __vm_pindex_t no longer existing and > also the same pid_t issue indicated below.] > > > I tried using [on a Pine64+ 2GB aarch64 system]: > > # > /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarch64-aux-freebsd12.0/6.3.1/install-tools/mkheaders > /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap > > to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and __vm_pindex_t. > > I then built via portmaster -CDK usage. Various header issues > did go away but the build of lang/gcc6-aux still stopped with: > > In file included from > /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:20:0: > ./config.h:556:15: error: two or more data types in declaration specifiers > #define pid_t int > ^ > > I'm guessing that the define for pid_t in config.h resulted > in something like: > > typedef ??? pid_t; > > that turned into something like a: > > typedef ??? int; > > for the error listed above. > > There were also implicit-declaration warnings: > > /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c: > In function 'simple_object_internal_read': > /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:75:21: > warning: implicit declaration of function 'read' > [-Wimplicit-function-declaration] > ssize_t got = read (descriptor, buffer, size); > ^~~~ > /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c: > In function 'simple_object_internal_write': > /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:119:23: > warning: implicit declaration of function 'write' > [-Wimplicit-function-declaration] > ssize_t wrote = write (descriptor, buffer, size); > ^ > > The implicit-declaration warnings for read and write may well > also not be expected/desirable. > > It may be that more than a script run is needed to make > things be appropriate. Is there a reason why you need ada support (that seems to be the only real reason for installing gcc6 vs gcc6-aux)? gcc6-aux uses a snapshot of gcc6 with custom options. Thanks! -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On 2017-Apr-14, at 6:54 PM, Mark Millard wrote:
> Alexander Kabaev kabaev at gmail.com on Sat Apr 15 00:20:40 UTC 2017
> wrote:
> . . .
>
>> it was suggested multiple times that the whole fixinc step is
>> ultimately harmful and serves no useful purpose and probably should be
>> disabled in built packages outright. Is there a reason not to do it?
>> Even Redhat appears to do the slimming in their rpms:
>>
>> mv $FULLPATH/include-fixed/syslimits.h $FULLPATH/include/syslimits.h
>> mv $FULLPATH/include-fixed/limits.h $FULLPATH/include/limits.h
>> for h in `find $FULLPATH/include -name \*.h`; do
>> if grep -q 'It has been auto-edited by fixincludes from' $h; then
>>rh=`grep -A2 'It has been auto-edited by fixincludes from' $h |
>> tail -1 | sed 's|^.*"\(.*\)".*$|\1|'` diff -up $rh $h || :
>>rm -f $h
>> fi
>> done
>
> I'll note that:
>
> http://www.linuxfromscratch.org/lfs/view/7.1/chapter06/gcc.html
>
> reports as one of its steps (quote):
>
> The fixincludes script is known to occasionally erroneously attempt
> to "fix" the system headers installed so far. As the headers up to
> this point are known to not require fixing, issue the following
> command to prevent the fixincludes script from running:
>
> sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in
>
> (End quote)
>
> So seems that disabling fixinc.sh's use is fairly common when
> the headers are known to "not require fixing" (i.e., are known
> to already be gcc compliant).
Hmm. Looking around I found a more overall script. For the
context that I tried it in the command was:
#
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarch64-aux-freebsd12.0/6.3.1/install-tools/mkheaders
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap
In other words:
bootstrap/libexec/gcc/*/*/install-tools/mkheaders
is the script and looking on the web I find other references
to using such as well. So I doubt that is all that special
to gcc6-aux, although some of the content of the example
might well be.
It in turn uses fixinc.sh script(s).
The mkheaders core loop looked like:
for ml in `cat ${itoolsdatadir}/fixinc_list`; do
sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`
multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`
subincdir=${incdir}${multi_dir}
. ${itoolsdatadir}/mkheaders.conf
if [ x${STMP_FIXINC} != x ] ; then
TARGET_MACHINE="${target}" target_canonical="${target}" \
MACRO_LIST="${itoolsdatadir}/macro_list" \
/bin/sh ./fixinc.sh ${subincdir} \
${isysroot}${SYSTEM_HEADER_DIR} ${OTHER_FIXINCLUDES_DIRS}
rm -f ${subincdir}/syslimits.h
if [ -f ${subincdir}/limits.h ]; then
mv ${subincdir}/limits.h ${subincdir}/syslimits.h
else
cp ${itoolsdatadir}/gsyslimits.h ${subincdir}/syslimits.h
fi
fi
cp ${itoolsdatadir}/include${multi_dir}/limits.h ${subincdir}
done
This code provides context to fixinc.sh and deals with limits.h
as well. So:
http://www.linuxfromscratch.org/lfs/view/7.1/chapter06/gcc.html
was not turning everything off.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: www/firefox, UPDATING, and "This platform lacks a functioning sem_open implementation..."
David Wolfskill writes: > In case it helps someone else, I had encountered the symptoms cited in > UPDATING entry 20170411, but the UPDATING entry didn't exist at the > time. > > So I poked around, and discovered that -- in my case -- the thing that > was apparently causing the problem was that lang/python27 had been built > with "SEM=off". > > So I re-built lang/python27 after enabling its SEM option; that > done, www/firefox built without further incident. > > (Checking the svn log for lang/python27/Makefile, it seems that SEM > had been changed to "default on" in r361735, 2014-07-14 00:20:40 > -0700. I had no known reason to change the setting at that time) I've filed bug 218641 to avoid documenting the issue in UPDATING. ac_cv_* usage implies users should not disable POSIX semaphores if the platform provides those. r230031 described some limitations of the previous implementation on FreeBSD 5.0-8.4. PTH was removed in r363790, so the only way to make "multiprocessing" usable is via SEM. ___ 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: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On 2017-Apr-14, at 8:07 PM, Ngie Cooper (yaneurabeya) wrote: > Is there a reason why you need ada support (that seems to be the only > real reason for installing gcc6 vs gcc6-aux)? gcc6-aux uses a snapshot of > gcc6 with custom options. > Thanks! > -Ngie I got to lang/gcc6-aux indirectly: I saw the ports checkin notice and github information for ports-mgmt/synth indicating that native aarch64 support was now in place/possible. When I looked at what pkg would provide it was older. So on a Pine64+ 2GB [an aarch64 context] I did an svnlite update for /usr/ports and then tried to build ports-mgmt/synth . Synth is written in ada and so indirectly then attempts a lang/gcc6-aux build if it is not already in place. [gcc5-aux likely would not support aarch64.] I've no direct interest in lang/gcc6-aux or ada as stands. But indirectly such is involved in what I wanted to explore. I've seen material quoted from a exp-run that reported that about 54(?) ports were then blocked by lang/gcc6-aux not building. (So some problems might not be aarch64 specific despite my example context: the "54" material was likely not for an aarch64 context.) === Mark Millard markmi at dsl-only.net ___ 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: graphics/opencv2 orphaned. Where from here
Am 15.04.2017 um 01:04 schrieb Kevin Oberman: > Thanks for the work on opencv, but PLEASE put something in UPDATING when > you make changes that impact large numbers of ports. I see opencv2 as > orphaned, so I can't stay there. > > Do I reset the origin of opencv2 to opencv? Or will I need to delete all of > them and rebuild everything? Please put information in UPDATING to give us > poor users some idea of how to proceed. I really would rathe rnot have to > re-install all of those ports if there is no reason. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 As a user of portmaster, all I had to do, was: portmaster -o graphics/opencv-core opencv2-core-2.4.13.1_1 portmaster -o graphics/opencv opencv2-2.4.13.1_6 portmaster -o graphics/py-opencv py27-opencv2-2.4.13.1_1 ___ 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"
