FreeBSD_HEAD-tests - Build #1611 - Unstable
FreeBSD_HEAD-tests - Build #1611 - Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1611/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1611/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1611/console Change summaries: No changes The failed test cases: 2 tests failed. FAILED: usr.sbin.fstyp.fstyp_test.cd9660 Error Message: atf-check failed; see the output of the test for details FAILED: usr.sbin.fstyp.fstyp_test.cd9660_label Error Message: atf-check failed; see the output of the test for details ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Buildworld ccache support
Why not cc me or even send this re: to the original thread?
On 10/20/2015 6:32 AM, Juan Ramón Molina Menor wrote:
> Hi!
>
> I’m certainly doing it wrong, because CCACHE does not kick in after
> applying the patch and modifying make.conf. CCACHE stats ('ccache -z'
> followed by 'ccache -s') remain at zero during buildworld while they
> used to reflect the cache miss/hits before.
>
> # cat /etc/make.conf
> WITH_CCACHE_BUILD=
>
> # svn diff /usr/src/share/mk/local.init.mk
> Index: /usr/src/share/mk/local.init.mk
> ===
> --- /usr/src/share/mk/local.init.mk (revision 289627)
> +++ /usr/src/share/mk/local.init.mk (working copy)
> @@ -38,3 +38,37 @@
> HOST_CFLAGS+= -DHOSTPROG
> CFLAGS+= ${HOST_CFLAGS}
> .endif
> +
> +# Handle ccache after CC is determined. If CC is at some specific path
> then
> +# we must prepend the ccache wrapper. Otherwise we can just prepend
> PATH with
> +# the wrapper location, which is a more safe solution since it avoids
> spaces
> +# and compiler type guessing based on filename.
> +LOCALBASE?=/usr/local
> +CCACHE_WRAPPER_PATH?= ${LOCALBASE}/libexec/ccache
> +CCACHE_PATH?= ${LOCALBASE}/bin/ccache
> +.if defined(WITH_CCACHE_BUILD) && !defined(NOCCACHE) && \
> +${CC:M*ccache*} == "" && exists(${CCACHE_PATH})
> +# Handle compiler changes properly. This avoids needing to use the
> 'world'
> +# wrappers.
> +CCACHE_COMPILERCHECK?= content
> +.export CCACHE_COMPILERCHECK
> +.if ${CC:M/*} == ""
> +# Can use PATH.
> +PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
> +.export PATH
> +.else
> +# Must prepend CC.
> +CC:= ${CCACHE_PATH} ${CC}
> +CXX:= ${CCACHE_PATH} ${CXX}
> +CPP:= ${CCACHE_PATH} ${CPP}
> +.if defined(HOST_CC)
> +HOST_CC:= ${CCACHE_PATH} ${HOST_CC}
> +.endif
> +.if defined(HOST_CXX)
> +HOST_CXX:= ${CCACHE_PATH} ${HOST_CXX}
> +.endif
> +.if defined(HOST_CPP)
> +HOST_CPP:= ${CCACHE_PATH} ${HOST_CPP}
> +.endif
> +.endif
> +.endif # WITH_CCACHE_BUILD
>
> If I recover the old make.conf, CCACHE works again for a buildworld.
>
> # cat /etc/make.conf.old
> .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
> .if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
> CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
> CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
> .endif
> .endif
>
> Maybe I misconfigured CCACHE when I first installed it?
>
This doesn't check for a value of WITH_CCACHE_BUILD, just being defined
is enough.
I've been fixing some subtle bugs such as in the lib32 build, but
overall I've had ccache -s growing while using the patch. If you
already have ccache in CC it won't apply it.
Are you building head from head or some other configuration?
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
FreeBSD_HEAD-tests - Build #1612 - Fixed
FreeBSD_HEAD-tests - Build #1612 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1612/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1612/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1612/console Change summaries: No changes ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Buildworld ccache support
Hi Bryan. Why not cc me or even send this re: to the original thread? I’m not used to mailing lists etiquette, sorry. I thought receiving two copies of the same message would bother you. Now I realize there are digests and maybe other less direct methods for message delivery. Best regards, Juan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Buildworld ccache support
Why not cc me or even send this re: to the original thread?
On 10/20/2015 6:32 AM, Juan Ramón Molina Menor wrote:
Hi!
I’m certainly doing it wrong, because CCACHE does not kick in after
applying the patch and modifying make.conf. CCACHE stats ('ccache -z'
followed by 'ccache -s') remain at zero during buildworld while they
used to reflect the cache miss/hits before.
# cat /etc/make.conf
WITH_CCACHE_BUILD=
# svn diff /usr/src/share/mk/local.init.mk
Index: /usr/src/share/mk/local.init.mk
===
--- /usr/src/share/mk/local.init.mk (revision 289627)
+++ /usr/src/share/mk/local.init.mk (working copy)
@@ -38,3 +38,37 @@
HOST_CFLAGS+= -DHOSTPROG
CFLAGS+= ${HOST_CFLAGS}
.endif
+
+# Handle ccache after CC is determined. If CC is at some specific path
then
+# we must prepend the ccache wrapper. Otherwise we can just prepend
PATH with
+# the wrapper location, which is a more safe solution since it avoids
spaces
+# and compiler type guessing based on filename.
+LOCALBASE?=/usr/local
+CCACHE_WRAPPER_PATH?= ${LOCALBASE}/libexec/ccache
+CCACHE_PATH?= ${LOCALBASE}/bin/ccache
+.if defined(WITH_CCACHE_BUILD) && !defined(NOCCACHE) && \
+${CC:M*ccache*} == "" && exists(${CCACHE_PATH})
+# Handle compiler changes properly. This avoids needing to use the
'world'
+# wrappers.
+CCACHE_COMPILERCHECK?= content
+.export CCACHE_COMPILERCHECK
+.if ${CC:M/*} == ""
+# Can use PATH.
+PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
+.export PATH
+.else
+# Must prepend CC.
+CC:= ${CCACHE_PATH} ${CC}
+CXX:= ${CCACHE_PATH} ${CXX}
+CPP:= ${CCACHE_PATH} ${CPP}
+.if defined(HOST_CC)
+HOST_CC:= ${CCACHE_PATH} ${HOST_CC}
+.endif
+.if defined(HOST_CXX)
+HOST_CXX:= ${CCACHE_PATH} ${HOST_CXX}
+.endif
+.if defined(HOST_CPP)
+HOST_CPP:= ${CCACHE_PATH} ${HOST_CPP}
+.endif
+.endif
+.endif # WITH_CCACHE_BUILD
If I recover the old make.conf, CCACHE works again for a buildworld.
# cat /etc/make.conf.old
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif
Maybe I misconfigured CCACHE when I first installed it?
This doesn't check for a value of WITH_CCACHE_BUILD, just being defined
is enough.
I've been fixing some subtle bugs such as in the lib32 build, but
overall I've had ccache -s growing while using the patch. If you
already have ccache in CC it won't apply it.
Are you building head from head or some other configuration?
HEAD from HEAD, updated regularly in /usr/src with SVN. Following the
standard procedure for updating described in /usr/src/UPDATING. ccache
installed as explained by the package message. Nothing special, really.
I’ll take some time when possible to recheck all the settings and be
back to you.
Best regards,
Juan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Buildworld ccache support
On 10/21/2015 1:44 PM, Juan Ramón Molina Menor wrote:
> +.if ${CC:M/*} == ""
> +# Can use PATH.
> +PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
These lines in particular did have problems that I fixed recently.
- It would potentially add /usr/local/libexec/ccache into PATH multiple
times in sub-makes (I think, it may have been my own PATH confusing me).
This would still use ccache.
- It would consider the '-isystem /usr/obj/...' used for LIB32MAKE to
match on '${CC:M/*}' which is intended to see if the compiler itself
starts with a /. In this case of building during build32 ccache was not
used.
I have since added 'env CCACHE=1' to CC and an .info ${PATH} near this
code to see if it is working and it sure seems to be working in all of
the build. This does suggest that using the PATH method may not be good
as it leads to confusion about whether it is used or not.
I have seen ccache stats get really messed up before. They seemed stuck
to me earlier. I had updated ccache in ports recently and had been
building Poudriere using my global ccache dir. Outside of the jail I
still had the older ccache. This may have led to it messing up my cache
and stats. Once I upgraded ccache in the host and cleaned the cache it
seemed to resume incrementing the counters.
I've also since removed the CCP handling from the patch as I found that
ccache just records a stat and bails out in that case.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: [CFT] Buildworld ccache support
On 10/21/2015 3:13 PM, Bryan Drewery wrote:
> On 10/21/2015 1:44 PM, Juan Ramón Molina Menor wrote:
>> +.if ${CC:M/*} == ""
>> +# Can use PATH.
>> +PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
>
> These lines in particular did have problems that I fixed recently.
>
> - It would potentially add /usr/local/libexec/ccache into PATH multiple
> times in sub-makes (I think, it may have been my own PATH confusing me).
> This would still use ccache.
> - It would consider the '-isystem /usr/obj/...' used for LIB32MAKE to
> match on '${CC:M/*}' which is intended to see if the compiler itself
> starts with a /. In this case of building during build32 ccache was not
> used.
>
> I have since added 'env CCACHE=1' to CC and an .info ${PATH} near this
> code to see if it is working and it sure seems to be working in all of
> the build. This does suggest that using the PATH method may not be good
> as it leads to confusion about whether it is used or not.
>
> I have seen ccache stats get really messed up before. They seemed stuck
> to me earlier. I had updated ccache in ports recently and had been
> building Poudriere using my global ccache dir. Outside of the jail I
> still had the older ccache. This may have led to it messing up my cache
> and stats. Once I upgraded ccache in the host and cleaned the cache it
> seemed to resume incrementing the counters.
>
> I've also since removed the CCP handling from the patch as I found that
> ccache just records a stat and bails out in that case.
>
Subtle changes in the environment or make command line could not use the
cache too. Some of my recent changes in the build system may have caused
no cache to be used in the next build.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: is building kernel in /sys/amd64/conf depreciated in 11 ?
John wrote this message on Tue, Oct 20, 2015 at 17:40 +0100: > as subject - is building kernel in /sys/amd64/conf depreciated? > > I can get a modified kernel to build and install in /usr/src but not > in /sys/amd64/conf. I always used to be able to do this in there, then > again I either used -RELEASE or -STABLE. I used to do it like this: > > 1. cd /sys/amd64/conf > 2. cp GENERIC MYKERNEL > 3. [make changes to MYKERNEL and save] > 4. config MYKERNEL > 5. cd ../compile/MYKERNEL > 6. make cleandepend && make depend && make > > This fails *every time* during make. It fails at this point: > > Make[1]: "/storage/usr/ports/Mk/bsd.port.mk" line 1204: UNAME_r > (11.0-CURRENT) and OSVERSION () do not agree on major version number. You're trying to build a 11-CURRENT kernel on a 10-something userland from the looks of it, and that has never been supported, it may work, but when it doesn't, FreeBSD won't fix it... If you do like building kernels the above way, you can do: cd /usr/src make kernel-toolchain make buildenv # which launches a shell cd /amd64/conf ... traditional build method ... The kernel-toolchain/buildenv builds the tools and sets up the environment just like buildkernel does for the kernel compiles... Or you need to update your compile box's userland to match the kernel version that you're building... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The kern.ipc.somaxconn limit revisited.
On 2015-10-13 01:32, White Knight wrote: On 2015-10-10 02:47, Adrian Chadd wrote: I think it's worth upping to an int type, so we can eventually up it to > 64k. Please do submit diffs for revie.w :) I'll work on the patch this week, thank you. I have submitted a bug report, with a patch for review, at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203922 I chose the arbitrary limit of 1431655765 in order to prevent an overflow (on systems where u_int is 32bit). I'm somewhat unsure if my changes to struct xsctp_inpcb are ok. Is it better to use the reserved fields? And if I don't, like in my patch, is it better to shorten the reserved fields accordingly? I decided not to touch other parts of the netstat formatted output, mostly to keep the patch short and to the point. Please comment and let me know what else needs to be changed. Are there other userland programs that touch the xsocket and xsctp_inpcb interfaces than netstat? -- White Knight I'm not from 2ch.net, I just work there. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: is building kernel in /sys/amd64/conf depreciated in 11 ?
On Tue, Oct 20, 2015 at 11:55:04PM -0400, Benjamin Kaduk wrote: Why is your kernel build pulling in bsd.port.mk? Please post src.conf and make.conf. [make.conf] MALLOC_PRODUCTION=yes WITH_CCACHE_BUILD=yes MAKE_JOBS_NUMBER=16 [src.conf] PORTS_MODULES=x11/nvidia-driver This is not exactly an answer to your question, but buildkernel has been the preferred way to build a kernel for at least four major releases. The manual-config method has limped along because enough of the old-guard of committers has it in finger memory, but manual-config has been excised from the handbook for quite some time. It answers my question ;) Though never a commiter, I have been using FreeBSD as a server OS since 2.0.5 and as a desktop since 2.1.7 so your comment about old-guard applies to me for sure ;) I'll recompile the newer way in future. Thanks for the info. -- John ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
env functionality of config(5) has no effect?
Hi, I'm trying to include some loader tunables in the kernel, via the "env" functionality described in config(5). When I look at the compiled kernel binary with strings(1), I see that the tunables are compiled in. However, they don't seem to take any effect when booting the kernel, and they also don't show up when running kenv(1) after boot. Any ideas? Thanks, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
